Еще не процесс
Продолжая тему предыдущего поста, является ли бизнес-процессом “Добыча нефти” или “Продвижение нового продукта”?
Опять-таки, ответ зависит от контекста. В контексте BPMN - однозначно нет. С точки зрения BPMN бизнес-процесс это конкретная последовательность действий, инициируемая определенным событием и завершающаяся тем или иным, но тоже конкретным результатом.
В BPMN нет места для аморфных вещей типа “Продвижение продукции”. Тут можно употребить термин “деятельность” или “семейство процессов”, но не “процесс”.
“Продвижение продукции” - семейство процессов, в число которых может входить, например, “Проведение ежегодной партнерской конференции”. Вот это уже вполне процесс с точки зрения BPMN: начало, понятная последовательность действий, результат - “конференция проведена” или “отказ от проведения конференции”.
Уже не процесс
Другая крайность - чрезмерная детализация, которая тоже приводит к исчезновению процесса.
Скажем, если поставить человеку задачу “купить хлеб к ужину”, то вопросов у исполнителя возникнуть не должно. Но если мы попытаемся детализировать эту задачу, дав ответы на вопросы “в какой супермаркет идти”, “что делать если супермаркет закрыт”, “что делать если не оказалось нужного ассортимента” и т.п., то в итоге нам придется объяснять в каком месте переходить улицу и с какой ноги вставать из кресла.
И получится у нас не процесс, потому что задать шаблон в такой постановке вряд ли удастся, а кейс - творческая задача, схему которой заранее определить невозможно. И это ситуация возникает всегда при все более глубокой детализации процесса.
Резюме
- На самом верхнем уровне процессного анализа мы имеем место с семействами процессов - это еще не процесс.
- Последовательная детализация процесса на определенном этапе приводит к тому, что имеем дело с кейсом - это уже не процесс.
Вообще все давно определено, и даже используется инструментами, такими как Adonis или signavio. Называется это “поток работ”. Поток - потому что в нем возникают, как бы вспыхивают события и обрабатывающие их процессы и при этом процессы между собой могут не иметь четкой связи. но весь этот пчелиный рой имеет общий вектор движения - добыча нефти. Обозначается это в виде диаграмм value added chain, горизонтальные это клиентно ориентированные потоки, а вертикальные домиком это общие такие как обслуживание ресурсов, кадры и пр. Мы можем делать диаграммы вложенные и вкладывать настолько глубоко пока не достигнем уровня, приемлемого для описанием нотацией BPMN.
Илья
Вообще-то value chain на русский переводится как цепочка создания ценности (не путать со стоимостью). И более точная, на мой взгляд, аналогия для нее - “машинка для создания денег”.
А поток работ по-английски workflow.
И я бы предложил оперировать не названиями продуктов, а названиями методологий, концепций или понятий.
В целом такие диаграммы называются VALUE chain. Принцип один - берем конечную потребительскую ценность и “разматываем” от нее в двух измерениях потоки - горизонтальные и вертикальные. Все в чем нуждаются потребители делает деньги. Без внутрисервисных вертикальных потоков горизонтальные работать не смогут.
Анатолий, спасибо за эту статью о процессах (обе части) - получилось кратко, но емко и точно.
Я не согласен лишь с последним разделом “Уже не процесс”, точнее с выводом о том, что процесс переходит в кейс именно при его последовательной детализации.
Приведенный пример про “сходить за хлебушком” подходит под иллюстрацию излишней детализации процесса, это действительно скорее задача, чем процесс. Но для кейса такая детализация так же чрезмерна, как и для процесса. Если уж сравнивать кейсы с процессами на этом примере, надо подниматься на вышестоящий уровень детализации.
Пусть это будет “организация ужина”. Для проекта у этой работы масштаб маловат, а вот для процесса или кейса - самое оно, тем более, что повторяемость ужинов очевидна, по крайней мере в целом. А а вот повторяемость в деталях и особенно в последовательности действий - это здесь совсем не факт, она должна зависеть от еще более высокого уровня - от вида деятельности (бизнеса, предприятия,…) в рамках которой эта работа выполняется.
Задача “купить хлеб к ужину” может быть включена как в процесс, так и в кейс, причем в кейсе это скорее будет просто “хлеб к ужину”, и не важно, где исполнитель задачи его достанет - купит, испечет, займет у соседей, … На мой взгляд, кейсы лучше, чем процессы, приспособлены к получению нужного результата в каждом экземпляре при меньшей степени их (экземпляров) повторяемости.
Владимир, спасибо за пример. Действительно, “ужин” более удачный пример кейса, чем “поход за хлебом” - тем, что тут явно просматривается больше одного исполнителя.
Я не хотел сказать, что кейс это обязательно следствие излишней детализации. Мысль была в том, что доведенная до абсурда детализация приводет к тому, что вместо процесса мы получаем кейс.
Если же говорить о взаимодействии процессов и кейсов в общем, то не менее распространенным является вариант, когда на верхнем уровне кейс, а на нижнем - процесс. Скажем, лечение больного - это кейс, а определенная процедура или анализ - процесс.
Анатолий, спасибо за ответ. Вот теперь я с вами согласен на все 100%.
Маленький вопрос по работе блога: можно ли подписаться на почтовые уведомления о комментариях?
По почте - нет, можно по RSS. См. иконки RSS внизу страницы (Контент, Комментарии) и иконку непосредственно под статьей - комментарии к данной статье. В качестве читалки рекомендую reader.google.com
Илья, прошу прощения за небольшой оффтоп, но где вы сталкивались с Адонисом? Я был руководителем процессной группы одного большого западного банка =), и, по имевшейся у нас информации, Адонис в России использовался только у нас. У нас была неверная информация?
Анатолий
согласен с выводами, в прошлой статье Вы все четко написали - это проект.
т.е. управлением проектами - это не управление бизнес-процессами. Проект имеет свойство разового характера. Процесс постоянного с многократным повторениями.