Not a Process Yet
Following up the previous post - may we call a business processes things like “Oil Mining” or “New Product Promotion?”
Once again, the answer depends on the context. In BPMN they aren’t business processes, definitely. From BPMN perspective business process is a specific sequence of actions initiated by a specific event and ended by some specific result.
In BPMN there is no room for vague things like “Product Promotion”. You can use the term “activity” or “process family,” but not “process”.
E.g. “Product Promotion” is a family of processes that may include “Annual Partner Conference.” That’s a process from BPMN perspective: a start, a predictable sequence of tasks, results - “OK” or “Conference Cancelled.”
Not a Process Any Longer
The other extreme is reached with too much details and a process disappears.
For example if we assign a task “Buy Bread for Dinner,” it won’t confuse the assignee. Now if we try to get into details by giving answers to the questions “which supermarket to go to,” “what to do if the supermarket is closed,” “what to do if the favourite brand is not available,” etc. then we’d probably end up by explaininig where to cross the street on the way and which foot to make the first step with.
And it won’t be a process because it’d be impossible to define a template covering all possible obstacles. It’d be an unpredictable case. And it’d happen all the time if we get deep enough into the process details.
Conclusion
- At the highest level of a process analysis there is no processes yet, only process families.
- At the deepest level of process details there is no process any longer but cases without predefined templates.
Вообще все давно определено, и даже используется инструментами, такими как Adonis или signavio. Называется это “поток работ”. Поток - потому что в нем возникают, как бы вспыхивают события и обрабатывающие их процессы и при этом процессы между собой могут не иметь четкой связи. но весь этот пчелиный рой имеет общий вектор движения - добыча нефти. Обозначается это в виде диаграмм value added chain, горизонтальные это клиентно ориентированные потоки, а вертикальные домиком это общие такие как обслуживание ресурсов, кадры и пр. Мы можем делать диаграммы вложенные и вкладывать настолько глубоко пока не достигнем уровня, приемлемого для описанием нотацией BPMN.
Илья
Вообще-то value chain на русский переводится как цепочка создания ценности (не путать со стоимостью). И более точная, на мой взгляд, аналогия для нее - “машинка для создания денег”.
А поток работ по-английски workflow.
И я бы предложил оперировать не названиями продуктов, а названиями методологий, концепций или понятий.
В целом такие диаграммы называются VALUE chain. Принцип один - берем конечную потребительскую ценность и “разматываем” от нее в двух измерениях потоки - горизонтальные и вертикальные. Все в чем нуждаются потребители делает деньги. Без внутрисервисных вертикальных потоков горизонтальные работать не смогут.
Анатолий, спасибо за эту статью о процессах (обе части) - получилось кратко, но емко и точно.
Я не согласен лишь с последним разделом “Уже не процесс”, точнее с выводом о том, что процесс переходит в кейс именно при его последовательной детализации.
Приведенный пример про “сходить за хлебушком” подходит под иллюстрацию излишней детализации процесса, это действительно скорее задача, чем процесс. Но для кейса такая детализация так же чрезмерна, как и для процесса. Если уж сравнивать кейсы с процессами на этом примере, надо подниматься на вышестоящий уровень детализации.
Пусть это будет “организация ужина”. Для проекта у этой работы масштаб маловат, а вот для процесса или кейса - самое оно, тем более, что повторяемость ужинов очевидна, по крайней мере в целом. А а вот повторяемость в деталях и особенно в последовательности действий - это здесь совсем не факт, она должна зависеть от еще более высокого уровня - от вида деятельности (бизнеса, предприятия,…) в рамках которой эта работа выполняется.
Задача “купить хлеб к ужину” может быть включена как в процесс, так и в кейс, причем в кейсе это скорее будет просто “хлеб к ужину”, и не важно, где исполнитель задачи его достанет - купит, испечет, займет у соседей, … На мой взгляд, кейсы лучше, чем процессы, приспособлены к получению нужного результата в каждом экземпляре при меньшей степени их (экземпляров) повторяемости.
Владимир, спасибо за пример. Действительно, “ужин” более удачный пример кейса, чем “поход за хлебом” - тем, что тут явно просматривается больше одного исполнителя.
Я не хотел сказать, что кейс это обязательно следствие излишней детализации. Мысль была в том, что доведенная до абсурда детализация приводет к тому, что вместо процесса мы получаем кейс.
Если же говорить о взаимодействии процессов и кейсов в общем, то не менее распространенным является вариант, когда на верхнем уровне кейс, а на нижнем - процесс. Скажем, лечение больного - это кейс, а определенная процедура или анализ - процесс.
Анатолий, спасибо за ответ. Вот теперь я с вами согласен на все 100%.
Маленький вопрос по работе блога: можно ли подписаться на почтовые уведомления о комментариях?
По почте - нет, можно по RSS. См. иконки RSS внизу страницы (Контент, Комментарии) и иконку непосредственно под статьей - комментарии к данной статье. В качестве читалки рекомендую reader.google.com
Илья, прошу прощения за небольшой оффтоп, но где вы сталкивались с Адонисом? Я был руководителем процессной группы одного большого западного банка =), и, по имевшейся у нас информации, Адонис в России использовался только у нас. У нас была неверная информация?
Анатолий
согласен с выводами, в прошлой статье Вы все четко написали - это проект.
т.е. управлением проектами - это не управление бизнес-процессами. Проект имеет свойство разового характера. Процесс постоянного с многократным повторениями.