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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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