Периодически к нам обращаются потенциальные заказчики с просьбой автоматизировать контроль поручений с помощью BPM.
Идея понятна: кто-то дает поручение, назначая срок, ответственного, ну и собственно содержание поручения. Достаточно легко разработать систему, которая автоматизирует контроль исполнения, напоминания о сроках, анализ статистики и т.п.
В любой процессной системе (т.е. BPMS) контроль поручений уже встроен. Нормативные сроки задач, возможность переназначения, делегирование на время планового отсутствия или административного вмешательства в случае непланового выбытия сотрудника из строя - все это доступно “из коробки”. При желании можно в схеме процесса можно предусмотреть и более изощренные вещи - таймеры, эскалации, отмены задач по событиям.
Но возникают две проблемы.
1. Кто будет раздавать поручения?
Проблема ведь не в контроле как таковом, а в том, как договориться о том, кто, что, в какой последовательности должен делать. Очевидно, разные подразделения вот так, за здорово живешь, поручений друг другу давать не смогут - “кто ты такой, чтобы давать мне поручения?”. Департамент А может считать, что оно дало поручение департаменту Б, но это не означает автоматически, что департамент Б принял его к исполнению.
Значит, поручения должен будет раздавать (или, по крайней мере, утверждать) “большой начальник”. Но большой начальник - это ценный ресурс, и использовать его для маршрутизации работ в рамках рутинных, но при этом критически важных для бизнеса процессов, таких, например, как выставление коммерческого предложения или выполнения договора, очевидно не эффективно.
Сравним с процессным управлением: это ведь в первую очередь не автоматизация, это готовность служб договариваться между собой о том, кто, что, в какой последовательности должен делать в интересах клиента. Ведь основные проблемы эффективности, как правило, возникают не внутри служб, а на стыках.
Парадигма контроля поручений вообще не рассматривает - кто, как, на каком основании, по каким правилам будет раздавать поручения. В упор не видит эту проблему. Хотя любому специалисту по процессному управлению известно, что алгоритмизировать раздачу поручений куда сложнее, чем контроль за их выполнением.
2. Откуда брать контекст?
Процессы (и поручения) существуют не в “безвоздушном пространстве”. Знать, что поручение выполнено, хорошо, но недостаточно. Исполнителю, чтобы эффективно справиться с поставленной задачей, надо дать входную информацию, собранную на предыдущих шагах - контекст процесса. В свою очередь, результат выполнения поручения - это не просто галочка “выполнено”, это данные - результаты проведенной работы и/или принятое решение. Процессные системы такой контекст обеспечивают - у каждого процесса есть набор атрибутов, и каждая задача связывается с определенными атрибутами на входе и на выходе.
Система контроля поручений контекстом вообще не интересуется - текст поручения, контрольный срок, исполнитель, отметка “выполнено - не выполнено”, все!
Следующий шаг - привязать к поручению контент в виде папки с документами Word или Excel, т.е. реализовать контроль поручений с помощью ECM-системы. Но если мы храним информацию не в структурированном виде (читай - не в СУБД), а в файлах MS Office, то а) надо быть готовым к ошибкам и противоречиям в информациии б) можно забыть об интеграции с автоматизированными системами (например, учетной). Все придется вводить повторно, умножая при этом число ошибок.
Вот почему, когда я слышу выражение “бизнес-процесс контроля поручений”, меня охватывает чувство сожаление, что у меня нет пистолета.
Не процессом единым
Не все и не всегда можно описать процессом - бывают ситуации, когда заранее предусмотреть все возможные варианты развития ситуации невозможно или попросту непрактично. Для таких ситуаций существует проектное управление и, в последнее время, кейс-менеджмент.
Проектное управление в контексте данной заметки - это управление поручениями плюс последовательность поручений плюс власть проектного менеджера, позволяющая эффективно решать проблемы, возникающие на стыках подразделений.
Это прогресс, конечно,- поручения раздает уже не “большой начальник”, а проектный менеджер, которому даны соответствующие полномочия. Однако, проектный менеджер - ресурс хоть и не столь дефицитный, как “большой начальник”, но тоже не дешевый. Там, где приходится иметь дело с непредсказуемой наперед деятельностью, выхода нет, но если речь идет о рутинных процессах, то использование квалифицированного специалиста с управленческими способностями и навыками в роли “движка” бизнес-процесса - явное расточительство.
Кроме того, проектное управление не обеспечивает контекста - предметные результаты работы сами по себе, галочки “выполнено - не выполнено” сами по себе.
В системах кейс-менеджмента (ACM) все в порядке с контекстом - данные они хранить умеют, но способность их справляться с проблемами на стыках между подразделениями вызывает сомнения. Возникает та же проблема, что и в контроле поручений: специалист подразделения А может назначить задачу сотруднику подразделения Б в рамках кейса К, но с чего тот побежит ее выполнять? Потому, что это важно для клиента? Не делайте мне смешно: “какой борщ, когда такие дела на кухне” (М.Жванецкий). Не случайно примеры кейс-менеджмента обычно не выходят за рамки одного подразделения.
Впрочем, эта проблема не выглядит неразрешимой: надо просто дополнить технические возможности систем кейс-менеджмента методологическими приемами проектного управления - назначить кейсу менеджера, обладающего необходимыми полномочиями (т.е. кнутом и пряником), регулярно проводить совещания и т.п.
Привет, Анатолий!
Я думаю, что проблема может быть решена, если поручение (задача) будет выдаваться тем, кому нужен результат/результаты этой задачи.
Это своего рода “вытягивание” результатов.
Тогда можно сделать поручение конкретному сотруднику или выложить поручение на конкурс, типа, кто хочет и может поставить требуемый результат за
приемлемое время, деньги и т.п.
В тех организациях, которые этим интересуются, _никому_ничего_не_надо_. Да это и типично для больших организаций - все сидят по отделам, как в окопах, и отстреливаются друг от друга. Все на окладе. Кроме, может быть, продавцов, но они ничего не могут сделать, опять-таки, без заинтересованного участия тех, кто на окладе.
Вот классичекий пример: подготовка коммерческого предложения в бизнесе “проектирование под заказ”. Понятно, что ключевой основной процесс? Понятно, что чертовски кросс-функциональный?
Ситуация у типичного запущенного пациента: “это дело продаж, пусть они и суетятся”. Хотя очевидно, что без активного участия конструкторов, производственников и снабженцев продавцы ничего ну никак не могут сделать качественное КП, хоть расшибись.
И как тут сработает вытягивание? Продавцы будут предлагать деньги снабженцам, чтобы те скалькулировали во что обойдутся комплектующие? Супер. Цыганский табор, а не организация. Извините, если вульгаризировал Ваше предложение.
Мне понравилась заметка. От себя добавлю следующее: при автоматизации сквозного процесса, наоборот, стоит задача избавиться от взаимодействия типа “постановка задачи руководителем - отчет подчиненного”, т.к. взаимодействие такого рода - это априори потеря времени и работа, не добавляющая ценности (т.е. доп. затраты). В случае с автоматизацией процесса с помощью BPMS постановка задачи осуществляется процессной логикой, а отчетность исполнителя заменяется процессной аналитикой.
Анатолий, я хоть и из другого мира (ЕСМ), но, отчасти, соглашусь с Вами в том, что сам по себе процесс контроля за исполнением поручений это не бизнес-процесс организации, а в лучшем случае бизнес-процесс специализированного подразделения, которое контролирует исполнение этих поручений. НО, то что в СЭД (ЕСМ) системах понимается под BPM движками это лишь инструмент СЭД, (некий расширенный аналог электронной почты, нацеленный на функции управления документами) его внедрение направлено, в первую очередь, на организацию деятельности работников в отношении других документов, в том числе тех, которые содержат основания для того чтобы поручение было выполнено.
Если внедрение СЭД (ЕСМ) преследует кроме цели внедрения СЭД ещё и цель организации системы управлением взаимодействием работников то необходимость выполнять поручения закрепляется организационными методами, всякими регламентами взаимодействия, технологическими регламентами и т.д. а модуль BPM (управления взаимодействием) точно так же используется как транспорт. Конечно, это не BPM система пока не будут реализовываться конкретные алгоритмы бизнес-процессов.
Алексей (Коротков), мне понравилось Ваше “Если внедрение СЭД (ЕСМ) преследует кроме цели внедрения СЭД ещё и цель организации системы управлением…”. А как вообще целью внедрения чего бы то ни было может быть само внедрение? У меня это в голове не укладывается.
По поводу ECM, документооборота и разницы между ними я уже писал: http://mainthing.ru/ru/item/564/ В вашем мире бизнес-процессами называют очень странные вещи
Анатолий, спасибо за статью!
В данный момент сам по работе столкнулся с системой поручений и делегирования ответственности. Могу добавить, что все в своих окопах отдела страшно боятся ответственности и пытаются прикрыть бумажкой с подписью руководителя уязвимые места организма.
Вооот! Это же первично. Если с этим ничего не делать, то можно внедрять что угодно - значимого для бизнеса результата не будет.
Что безвредно, то и бесполезно.
Все понимают, что основная цель любой организации - удовлетворение потребностей клиентов, а у коммерческой ещё и получение за счёт этого прибыли, но это же не значит, что для достижении этой цели компании не ставят себе локальные цели и задачи, Внедрение СЭД тоже решает определённые цели, в данном случае за словосочетанием “внедрение СЭД (ЕСМ) преследует кроме цели”, понималось как раз “достижение целей проекта внедрения СЭД”. И если уточнится, то проект внедрения может включать 2 части собственно управление документами (Content Management) и управление взаимодействием (Workflow). Но когда прикладной внутриСЭДовский workflow начинают использовать как самостоятельное решение, то совершенно точно к нему и подходить нужно как к системе системе выполнения регламентных процессов, а не решать задачу автоматизации процессов через одокуменчивание и опорученивание процесса с тем чтобы его можно было потом реализовать в СЭД.
При этом я не знаю ни одной системы, в которой workflow движок вырос до самостоятельной BPM системы. Иностранцы обычно наоборот стараются хорошие BPM инструменты использовать с хорошими CMS и DMS средствами получая инфраструктурные и многофункциональные решения, на которых решаются и ЕСМ задачи, наши, видимо от бедности, стараются сшить семь шапок из одной лисы…
Интересная тема и актуальная для нашей компании. Контроль поручений как бизнес-процесс - бред. Именно так категорично. Использование электронной почты или TODO (встроенных в Lotus Notes и т.д.) решает этот вопрос но только в рамках прямых поручений, без создания базы знаний (файлы, документы, комментарии исполнителей и т.д.). ECM - это хорошо, но тут требуется методология и это начинает быть похожим на ACM, т.к. создается папка проблемы, как кейс и в ней идет накопление знаний по ее решению, но чтобы это стало базой знаний уже потребуется доработка ECM. BPM мы рассматривали как средство автоматизации данной деятельности и отказались именно по причине того, что это не процесс. Задача еще усложняется контролем исполнения, когда задача перепоручается далее и далее или разделяется на две подзадачи. В реальности получается, что контроль поручений необходим в рамках одного подразделения, но это только первый этап для создания и внедрения подобной системы. Результатом данного этапа будет электронное ведение поручений внутри разных подразделений и накопление базы знаний. Бизнес-результат - повышение эффективности исполнительной дисциплины. На втором этапе подразделения самостоятельно начинают (через своих шефов) давать поручения друг-другу. И…… мы получили СЭД. Все эти рассуждения к тому, что расширить СЭД - решает вопрос контроля поручений. НО возникает основной вопрос - а как от вертикального управления перейти к горизонтальному? Регламентацией и автоматизация “стабильных” бизнес-процессов. Контроль поручений является инструментом заменяющий не автоматизированный/не регламентированный бизнес-процесс - хаос. А автоматизировать хаос ……..
C контролем исполнения поручений всё просто. Ничто не противоречит высокому искусству BPM.
Каждое поручение - это минимальный бизнес-процесс из одной задачи.
Имеются субъект управления и объект управления.
Субъект поручает объекту выполнить задачу. Задача 1 (одна). 1 старт и 2 завершения - сделал или нет, и 1 таймер.
Контекст записывается в комментарии.
Польза - очевидна. Особенно в условиях формализованной структуры и остутствия желания работать.
Пример - в мае Президент пожаловался, что правительство РФ выполнило 72% его поручений.
При таком уровне исполнительной дисциплины вероятность исполнения бизнес-процесса из 4 задач в нашем правительстве составляет менее 20%. Поэтому нет никакого смысла формализовывать бизнес-процессы в таких организациях, как наше правительство. В других - может быть ещё хуже.
Руководители сами прекрасно понимают эту ситуацию, и хотят сначала наладить исполнительскую дисциплину.
Лично я готов ставить контроль исполнения поручений в любой организации, и буду только рад помочь людям.
Я сделаю это с любовью и надеждой на будущее.
В неповторяющихся и непредсказуемых делах, в отсутствии пока что на рынке зрелых ACM-систем - почему бы и нет. Я возражаю только против а) подмены контролем поручения полноценного процессного управления там, где последний применим, и б) использования для этого BPMS, т.к. специализированные средства класса problem tracking тут будут более эффективны.
Если обратиться к такому гуру организационного менеджмента как Генри Минцберг, то он выделяет следующие пять способов координации работы:
- непосредственный контроль (по вертикали);
- взаимное согласование (по горизонтали);
- стандартизация процедур/процессов;
- стандартизация результатов;
- стандартизация квалификации.
Вокруг этих пяти вариантов в мире менеджмента все и пляшет, по большому счету. И в зависимости от того, какой подход применяется в организации (а в крупных и даже не очень крупных организациях они могут сочетаться - как на разных уровнях, так и в разных частях организации), требуется разная автоматизация:
)
- при непосредственном контроле - система контроля поручений;
- при взаимном согласовании - бывает достаточно электронной почты, но вообще-то лучше ECM (хотя бы для фиксации протоколов согласования), плюс система проектного управления (т.к. в результате рождается масса взаимосвязанных задач, которые должны быть выполнены скоординированно);
- при стандартизации процедур/процессов - кто угадает?
- при стандартизации результатов - ECM+ACM (которая позволяет накапливать результаты и рулить шагами по их получению в условиях неопределенности стандартизированной процедуры);
- при стандартизации квалификации - HRM (неожиданно, да?
При этом по-честному известно, что:
- непосредственный контроль - самый дорогой способ управления и самый негибкий, поэтому подходит только для небольших структур либо для верхнеуровневых решений, исполняемых на уровне стратегического апекса (т.е., опять же, в относительно небольшой структуре);
- взаимное согласование - более дешевый (по соотношению стоимость/эффект) и гибкий вариант, но все равно существенно более дорогой, чем оставшиеся три варианта со стандартизацией.
Поэтому есть общая рекомендация: стандартизируйте все, что можете (только без фанатизма, а то некоторые увлекаются, и лежат потом никому не нужные псевдо-стандарты на полках или жестких дисках, а реальная работа строится по первым двум способам). А тем, что не можете стандартизировать, управляйте соответствующим образом с помощью подходящих для этого средств, без иллюзий, самообмана и подмены понятий.
Ну, и не стоит забывать, что проектное управление - это тоже система процессов/процедур (кто не верит - PMBoK в помощь), т.е. тоже поддается стандартизации и автоматизации соответствующими средствами. И контроль поручений, по большому счету, тоже можно загнать в процессную модель - т.е. само управление поручениями, а не тем, что с их помощью делается - она относительно не сложная, могу даже для разминки ее набросать. Хотя лично мне, по большому счету, для этого хватает функциональности задач в Outlook. В более тяжелых ситуациях - MS Project.
Дмитрий, спасибо что подвели столь основательный фундамент.
Анатолий, этот фундамент подвёл Минцберг, а я лишь сделал небольшую надстройку и адаптировал его к дискуссии.