Отправляет email-рассылки с помощью сервиса Sendsay

Всё о документообороте

Рассылка закрыта

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Февраль 2014   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
15.02.2014
01:46:00
02:01:26
16
17
17.02.2014
11:31:15
18:01:30
18
19
20
21
22
23
24
25
25.02.2014
12:32:42
17:32:10
26
27
28
28.02.2014
13:31:46
18:31:55
Автор
Mikou

Статистика

750 подписчиков
+1 за неделю
←   Все выпуски   →

Запись блога "Контроль поручений как имитация процессного управления" от Анатолий Белайчук


Все о документообороте

Сайт рассылки
 



Запись блога "Контроль поручений как имитация процессного управления" от Анатолий Белайчук
2014-02-25 16:47 Анатолий Белайчук

Периодически к нам обращаются потенциальные заказчики с просьбой автоматизировать контроль поручений с помощью BPM.

Идея понятна: кто-то дает поручение, назначая срок, ответственного, ну и собственно содержание поручения. Достаточно легко разработать систему, которая автоматизирует контроль исполнения, напоминания о сроках, анализ статистики и т.п.

В любой процессной системе (т.е. BPMS) контроль поручений уже встроен. Нормативные сроки задач, возможность переназначения, делегирование на время планового отсутствия или административного вмешательства в случае непланового выбытия сотрудника из строя - все это доступно “из коробки”. При желании можно в схеме процесса можно предусмотреть и более изощренные вещи – таймеры, эскалации, отмены задач по событиям.

Но возникают две проблемы.

1. Кто будет раздавать поручения?

Проблема ведь не в контроле как таковом, а в том, как договориться о том, кто, что, в какой последовательности должен делать. Очевидно, разные подразделения вот так, за здорово живешь, поручений друг другу давать не смогут – “кто ты такой, чтобы давать мне поручения?”. Департамент А может считать, что оно дало поручение департаменту Б, но это не означает автоматически, что департамент Б принял его к исполнению.

Значит, поручения должен будет раздавать (или, по крайней мере, утверждать) “большой начальник”. Но большой начальник – это ценный ресурс, и использовать его для маршрутизации работ в рамках рутинных, но при этом критически важных для бизнеса процессов, таких, например, как выставление коммерческого предложения или выполнения договора, очевидно не эффективно.

Сравним с процессным управлением: это ведь в первую очередь не автоматизация, это готовность служб договариваться между собой о том, кто, что, в какой последовательности должен делать в интересах клиента. Ведь основные проблемы эффективности, как правило, возникают не внутри служб, а на стыках.

Парадигма контроля поручений вообще не рассматривает – кто, как, на каком основании, по каким правилам будет раздавать поручения. В упор не видит эту проблему. Хотя любому специалисту по процессному управлению известно, что алгоритмизировать раздачу поручений куда сложнее, чем контроль за их выполнением.

2. Откуда брать контекст?

Процессы (и поручения) существуют не в “безвоздушном пространстве”. Знать, что поручение выполнено, хорошо, но недостаточно. Исполнителю, чтобы эффективно справиться с поставленной задачей, надо дать входную информацию, собранную на предыдущих шагах – контекст процесса. В свою очередь, результат выполнения поручения – это не просто галочка “выполнено”, это данные – результаты проведенной работы и/или принятое решение. Процессные системы такой контекст обеспечивают – у каждого процесса есть набор атрибутов, и каждая задача связывается с определенными атрибутами на входе и на выходе.

Система контроля поручений контекстом вообще не интересуется – текст поручения, контрольный срок, исполнитель, отметка “выполнено – не выполнено”, все!

Следующий шаг – привязать к поручению контент в виде папки с документами Word или Excel, т.е. реализовать контроль поручений с помощью ECM-системы. Но если мы храним информацию не в структурированном виде (читай – не в СУБД), а в файлах MS Office, то а) надо быть готовым к ошибкам и противоречиям в информациии б) можно забыть об интеграции с автоматизированными системами (например, учетной). Все придется вводить повторно, умножая при этом число ошибок.

Вот почему, когда я слышу выражение “бизнес-процесс контроля поручений”, меня охватывает чувство сожаление, что у меня нет пистолета.

Не процессом единым

Не все и не всегда можно описать процессом – бывают ситуации, когда заранее предусмотреть все возможные варианты развития ситуации невозможно или попросту непрактично. Для таких ситуаций существует проектное управление и, в последнее время, кейс-менеджмент.

Проектное управление в контексте данной заметки – это управление поручениями плюс последовательность поручений плюс власть проектного менеджера, позволяющая эффективно решать проблемы, возникающие на стыках подразделений.

Это прогресс, конечно,- поручения раздает уже не “большой начальник”, а проектный менеджер, которому даны соответствующие полномочия. Однако, проектный менеджер - ресурс хоть и не столь дефицитный, как “большой начальник”, но тоже не дешевый. Там, где приходится иметь дело с непредсказуемой наперед деятельностью, выхода нет, но если речь идет о рутинных процессах, то использование квалифицированного специалиста с управленческими способностями и навыками в роли “движка” бизнес-процесса - явное расточительство.

Кроме того, проектное управление не обеспечивает контекста - предметные результаты работы сами по себе, галочки “выполнено – не выполнено” сами по себе.

В системах кейс-менеджмента (ACM) все в порядке с контекстом – данные они хранить умеют, но способность их справляться с проблемами на стыках между подразделениями вызывает сомнения. Возникает та же проблема, что и в контроле поручений: специалист подразделения А может назначить задачу сотруднику подразделения Б в рамках кейса К, но с чего тот побежит ее выполнять? Потому, что это важно для клиента? Не делайте мне смешно: “какой борщ, когда такие дела на кухне” (М.Жванецкий). Не случайно примеры кейс-менеджмента обычно не выходят за рамки одного подразделения.

Впрочем, эта проблема не выглядит неразрешимой: надо просто дополнить технические возможности систем кейс-менеджмента методологическими приемами проектного управления - назначить кейсу менеджера, обладающего необходимыми полномочиями (т.е. кнутом и пряником), регулярно проводить совещания и т.п.

Комментарий участника дискуссии

Если обратиться к такому гуру организационного менеджмента как Генри Минцберг, то он выделяет следующие пять способов координации работы:

●    непосредственный контроль (по вертикали);

●    взаимное согласование (по горизонтали);

●    стандартизация процедур/процессов;

●    стандартизация результатов;

●    стандартизация квалификации.

Вокруг этих пяти вариантов в мире менеджмента все и пляшет, по большому счету. И в зависимости от того, какой подход применяется в организации (а в крупных и даже не очень крупных организациях они могут сочетаться – как на разных уровнях, так и в разных частях организации), требуется разная автоматизация:

●    при непосредственном контроле – система контроля поручений;

●    при взаимном согласовании – бывает достаточно электронной почты, но вообще-то лучше ECM (хотя бы для фиксации протоколов согласования), плюс система проектного управления (т.к. в результате рождается масса взаимосвязанных задач, которые должны быть выполнены скоординированно);

●    при стандартизации процедур/процессов – кто угадает? :-)

●    при стандартизации результатов – ECM+ACM (которая позволяет накапливать результаты и рулить шагами по их получению в условиях неопределенности стандартизированной процедуры);

●    при стандартизации квалификации – HRM (неожиданно, да? :-) )

 

При этом по-честному известно, что:

●    непосредственный контроль – самый дорогой способ управления и самый негибкий, поэтому подходит только для небольших структур либо для верхнеуровневых решений, исполняемых на уровне стратегического апекса (т.е., опять же, в относительно небольшой структуре);

●    взаимное согласование – более дешевый (по соотношению стоимость/эффект) и гибкий вариант, но все равно существенно более дорогой, чем оставшиеся три варианта со стандартизацией.

Поэтому есть общая рекомендация: стандартизируйте все, что можете (только без фанатизма, а то некоторые увлекаются, и лежат потом никому не нужные псевдо-стандарты на полках или жестких дисках, а реальная работа строится по первым двум способам). А тем, что не можете стандартизировать, управляйте соответствующим образом с помощью подходящих для этого средств, без иллюзий, самообмана и подмены понятий.

Ну, и не стоит забывать, что проектное управление – это тоже система процессов/процедур (кто не верит – PMBoK в помощь), т.е. тоже поддается стандартизации и автоматизации соответствующими средствами. И контроль поручений, по большому счету, тоже можно загнать в процессную модель – т.е. само управление поручениями, а не тем, что с их помощью делается – она относительно не сложная, могу даже для разминки ее набросать. Хотя лично мне, по большому счету, для этого хватает функциональности задач в Outlook. В более тяжелых ситуациях – MS Project.

 
 



 
 
С пожеланиями успехов,
Михаил Кузьмин
  
В избранное