From time to time we are approached by prospects requesting task control automation by BPM.
The idea is simple: someone assigns tasks by setting goals, responsibles and terms. It’s easy enough to develop a system automating terms control, due dates reminders, statistical analysis, etc.
Any decent process system (i.e. BPMS) features built-in task management. Task durations, notifications, delegation, on-the-fly reassignment in the event of unplanned leave are available out of the box. If necessary, the process scheme can implement more sophisticated things like timers, escalation or cancellation by external events.
But there are two problems.
1. Who assigns the task?
The core problem isn’t the control over task execution but mutual agreement on who should do what in what sequence. Different departments are not in position to make orders to each other. Department A may believe that it assigned a task to department B but it does not automatically mean that the department B accepted the task for execution.
Hence such assignation should me made (or at least approved) by the “big boss.” But the big boss is a valuable resource so using it for task assignation within routine yet critical business processes such as quotation or sale is terribly ineffective.
Let’s comparable with process management: it’s not the automation, it starts with the willingness of participants to agree about who, what, in what order should perform in the best interests of the client. The major performance issues typically occur not within department boundaries but between them.
The paradigm of task management does not consider who, how, on the basis of what rules assigns tasks, it’s beyond the scope. Yet any process practician knows that setting up task assignation rules (i.e. process scheme) is far more difficult than automate task execution control.
2. Where is the context?
Processes (and tasks) aren’t executed in a vacuum. It’s good to know that the task is assigned yet it’s not enough. The task performer also needs the input information which was typically gathered on the previous steps - the process context. The result of the task isn’t just the checkbox “Completed” - it’s the output information and/or decisions made. Process systems provide such context - each process instance has a set of attributes, and each task is associated with certain attributes as its input and output.
Basic task management system doesn’t care about the context; all it provides is informal text description of the task.
More advance approach links a task to a dedicated folder containing Word and/or Excel documents i.e. by utilizing ECM. But if we don’t store the information in a structured way (not in the database) then we should a) be prepared for errors, duplicates and inconsistencies in the data; forget about the integration with legacy systems (e.g., accounting) - multiple data entry, multiple errors.
That’s why when I hear “task management business process” I wish I had a gun.
Not processes alone
It isn’t always doable or practicable to consider our activities as processes. If it’s unpredictable or non-repeatable then we should better switch to the project management or to the case management.
Project management in the context of this post is the task management plus a sequence of tasks plus the power given to the project manager to resolve cross-functional issues.
This is progress of course comparing to the basic task management - now it isn’t the big boss who gives the orders but the project manager. Yet the project manager is also a valuable resource, although not as valuable as the big boss. There is no choice when we deal with the unpredictable activities but when it comes to routine processes, the use of qualified personnel with managerial abilities and skills as a process engine is the obvious waste.
Besides, the typical project management doesn’t provide the context: “Completed” checkboxes are managed by the project system while the data is spread among applications if not paper sheets.
The case management systems (ACM) are good in providing the context but their ability to cope with cross-functional issues is questionable. The same issue may arise: department A may assign a task to an employee of department B within the case C but are we sure the latter would accept it readily? It’s no surprise that most case management examples don’t go beyond a single department.
However it doesn’t seem to be a tough problem, the key is to combine the technological capabilities of ACM systems with methodological techniques of the project management - the case responsibility should be assigned to a project manager with adequate power, the case meeting should be performed on the regular basis, etc.
Привет, Анатолий!
Я думаю, что проблема может быть решена, если поручение (задача) будет выдаваться тем, кому нужен результат/результаты этой задачи.
Это своего рода “вытягивание” результатов.
Тогда можно сделать поручение конкретному сотруднику или выложить поручение на конкурс, типа, кто хочет и может поставить требуемый результат за
приемлемое время, деньги и т.п.
В тех организациях, которые этим интересуются, _никому_ничего_не_надо_. Да это и типично для больших организаций - все сидят по отделам, как в окопах, и отстреливаются друг от друга. Все на окладе. Кроме, может быть, продавцов, но они ничего не могут сделать, опять-таки, без заинтересованного участия тех, кто на окладе.
Вот классичекий пример: подготовка коммерческого предложения в бизнесе “проектирование под заказ”. Понятно, что ключевой основной процесс? Понятно, что чертовски кросс-функциональный?
Ситуация у типичного запущенного пациента: “это дело продаж, пусть они и суетятся”. Хотя очевидно, что без активного участия конструкторов, производственников и снабженцев продавцы ничего ну никак не могут сделать качественное КП, хоть расшибись.
И как тут сработает вытягивание? Продавцы будут предлагать деньги снабженцам, чтобы те скалькулировали во что обойдутся комплектующие? Супер. Цыганский табор, а не организация. Извините, если вульгаризировал Ваше предложение.
Мне понравилась заметка. От себя добавлю следующее: при автоматизации сквозного процесса, наоборот, стоит задача избавиться от взаимодействия типа “постановка задачи руководителем - отчет подчиненного”, т.к. взаимодействие такого рода - это априори потеря времени и работа, не добавляющая ценности (т.е. доп. затраты). В случае с автоматизацией процесса с помощью 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.
Дмитрий, спасибо что подвели столь основательный фундамент.
Анатолий, этот фундамент подвёл Минцберг, а я лишь сделал небольшую надстройку и адаптировал его к дискуссии.