Basic BPMN Assumptions:
- All information is stored
- Organization has a mechanism of tasks assignation and transfer
- Every task is accompanied by appropriate instruction
- Every task has standard duration and there is a way to control it
3. Every task is accompanied by appropriate instruction
Another way to simplify the diagram: keep in mind that a text description and/or instruction can be attached to a task.
This lets replace the following diagram (taken from a student’s work at BPMN training) -
with simple one:
assuming all the details - how to communicate with the client, what should be in the document, how to deal with ERP - go to the task instructions. The task name refers to the final result of the activities chain.
Not everyone would accept this - some might say the first diagram is better because it’s more detailed.
First of all, why we model business processes? There are variety of possible answers but let’s focus on two:
- To help employees to perform their duties.
- To improve the effectiveness of cross-functional, end-to-end processes.
In the first case the first version of the process is better, in the second - the second. I choose the second option - let me explain why:
- In the first case we are fighting against functional incompetence of the employee. It’s certainly an issue but drawing process diagram is not the only solution. Another options are making the immediate boss responsible for the education, writing a comprehensive instructions, establishing a knowledge base, recording video lessons… after all, the company can simply raise salary and hire more talented staff (as we know, a smart employee doesn’t need instructions while a dumb one can’t use them).
- In the second case, the whole situation is different: it is assumed that employees are functionally capable - everyone can do his own job. But the business process goes through so many participants and is so complex and lengthy that special efforts are needed to prevent it from getting stuck between functions and to make it optimal in terms of quality for the customer and effective use of resources. In this case there is no real alternative to process management - nor written instruction neither salary increases can handle these issues.
Theoretically, two goals - modeling procedures at individual workplace level and modeling end-to-end business processes - don’t conflict and BPMN is suitable for both. But in practice, somehow either one is achieved or the other: if an analyst is too focused on the procedural details, he loses the “big” picture. Conversely, if one targets a big end-to-end process then interest in the micro-management somehow disappears.
Another reason why I prefer second scheme is better robustness.
Any process, if broken into details too much, becomes a case. For example, anyone can handle the task “Buy a peach”. But what if getting too deep into details?
“I think I would like a peach.”
Kid McGarry arose and put on his coat and hat. He was serious, shaven, sentimental, and spry.
“All right,” said he, as coolly as though he were only agreeing to sign articles to fight the champion of England. “I’ll step down and cop one out for you see?”
“Don’t be long,” said the bride. “I’ll be lonesome without my naughty boy. Get a nice, ripe one.”
In O.Henry’s “Little speck in garnered fruit” it ended with police turning Denver Dick’s place upside down. Could the bride foresee it in the process scheme? Obviously not. What conclusion should we make - maybe we should switch to ACM? Or just cut it down to a single task and reliable performer?
Let management by objectives rule instead of micro-management!
More on the matter:
To be continued…
Анатолий, здесь виден обычный конфликт между бизнес-процессом и технологическим процессом. Приведенные мной термины могут варьироваться, но суть их в том, что бизнес-процесс описывает взаимодействие между участниками, в то время как технологический указывает, каким образом получить требуемый результат. Т.е., описывая бизнес-процесс, задаемся вопросами “что делать”, “что и где брать”, “что и кому передавать”. Описывая технологический процесс, задаемся вопросом “КАК получить то, что нужно”. И эти два взгляда на один и тот же процесс тесно связаны, поскольку, моделируя взаимодействие, нужно быть уверенным, что каждый исполнитель в бизнес-процессе действительно сможет исполнить свой этап технологического процесса, т.е. взяв на входе то, что ему предоставили, получить на выходе то, что от него требуется. И неверие в то, что специалисты на местах способны исполнить свой технологический процесс, порождает то, что вместо моделирования бизнес-процесса, т.е. аспектов взаимодействия, начинают моделировать технологический процесс, т.е. аспект получения результата. Таким образом, вместо моделирования бизнес-процесса опускаемся на уровень ниже. Отсюда логичный вариант, как совместить и одно, и другое, если это очень требуется (хотя, согласен требуется это на самом деле не всегда, но иногда все-таки полезно): те задачи бизнес-процесса, в которых хочется детализировать технологический процесс средствами BPMN, а не простым текстовым описанием задачи, обозначать подпроцессом, описывая внутри этого подпроцесса технологическую схему. Чтобы понять, не провалились ли мы в своем моделировании на уровень техпроцесса, достаточно простой проверки: если подряд идут две задачи одного исполнителя без промежуточного ветвления или обмена артефактами (т.е. взаимодействия), то это уже уровень технологического процесса одного исполнителя.
К сожалению, в BPMN отсутствует способ выделить переход от уровня бизнес-процесса к уровню технологического - чтобы не репутать это с подпроцессом, когда мы на более нижнем уровне все еще продолжаем моделировать бизнес-процесс. Может быть, в следующую версию стандарта это включат (как бы это предложить? могу эту идею более полно развернуть). Ведь не секрет, что некоторые технологические схемы удобно обозначать в виде диаграммы, а не в виде текстового описания, и почему бы тогда не использовать ту же нотацию, но при этом четко обозначить водораздел между этими двумя уровнями.
Но, кстати, иногда бизнес-аналитику при моделировании бизнес-процесса нужно до какой-то степени самому разобраться в технологическом процессе, чтобы понять, как может быть устроен бизнес-процесс, а как не может в силу технологических ограничений.
Дмитрий
Предложенное Вами терминологическое деление мне нравится. Что касается внесения в стандарт - вряд ли, BPMN сознательно сделан методологически нейтральным. Внесите во внутренний стандарт моделирования.
И я согласен, что технологический уровень можно изобразить в виде подпроцесса. Только при этом возникают две опасности, на которые я указал: 1) такая деятельность иногда “засасывает” - на верхнем уровне проблемы посерьезнее, да и вмешиваться приходится во взаимоотношения между подразделениями, а следовательно их руководителями, что иногда чревато. Вот и возникает соблазн увлеченно заниматься микропроцессингом.
2) Схема получается более хрупкой - есть риск получить непредсказуемый кейс вместо подпроцесса. Вообще есть потенциально интересный подход к моделированию, когда все, что делается внутри подразделения, отдается на откуп его руководителю - как хочет, так и организует, при условии что выдерживает SLA. И процессный подход соблюден, и нет жесткости, в которой иногда упрекают BPM. Вот только на практике применить его пока не получалось.
Если все, что делается внутри подразделения, отдается на откуп его руководителя, лишь бы соблюдался SLA, то это не что иное как внутрисервисный подход к организации деятельности компании. Т.е. подразделения оказывают друг другу сервисы. И это вполне нормальная вещь (в т.ч. с помощью BPMN описывается замечательно, с моей точки зрения), до тех пор, пока каждый руководитель такого сервиса действительно выстраивает сервис так, чтобы соблюдался SLA. Например, ИТ-подразделение выстраивает свои сервисы в соответствии с ITIL - правда, ИТ-сервисы, как правило, не лежат в цепочке добавленной стоимости, а носят вспомогательный характер. Но вот подразделение, обеспечивающее внутреннюю логистику, запросто может работать по тому же принципу (даже могу привести пример, где именно это так и работает в логистике).
В таком подходе есть следующие особенности, из-за которых это не всегда работает - в особенности, в России:
), поскольку есть такой фреймворк по организации ИТ-сервиса, как ITIL, и ИТ-руководители в большей степени, чем другие, являются приверженцами процессного или сервисного подхода. С сервисами типа логистического или еще какого-то дела обстоят хуже, поскольку их владельцы хуже разбираются, как управлять деятельностью именно как сервисом.
1) Серис для процессов, которые его вызывают, представляется черным ящиком с определенными интерфейсами и установленным SLA. Т.е. вмешиваться в его устройство при построении вызывающих его процессов нельзя - иначе это будет уже не внутрисервисный подход.
2) Из п. 1 следует, что кто-то должен отдельно организовать бизнес-процессы самого сервиса. Обычно это отдают на откуп самому его владельцу. В случае с ИТ это работает (хотя тоже не всегда
3) Поскольку сервисный процесс - это всегда отдельный пул в терминах BPMN, возникает следствие из теории ограниченных систем, о котором вы сами много рассказывали: сглаживаются пики входной загрузки сервиса, но снижается удовлетворенность потребителя (в данном случае, внутреннего).
Так что вывод: это вполне рабочая модель, которая может работать в умелых руках, просто не всегда есть умелые руки, а также не всегда это то, что подходит в данном конкретном случае. Поэтому зачастую и может возникать такая экстремальная точка зрения: не работает.
А если вместо технологического подпроцесса получился кейс, то это уж точно указание бизнес-аналитику - не лезть в эти дебри. Представил себе технологический процесс на концептуальном уровне, убедился, что задача на уровне бизнес-процесса реализуема, т.к. есть некая концептуально понятная технология ее выполнения - не лезь глубже. Иначе придется стать глубоким специалистом в предметной области. А это невозможно - стать таким специалистом во всех аспектах работы компании. Поэтому я лично за то, чтобы детали техпроцессов прорабатывали технологи в каждом подразделении, а процессный аналитик только консультировался бы с ними, когда это необходимо.
>> указание бизнес-аналитику - не лезть в эти дебри
+100500
>> вмешиваться в его устройство при построении вызывающих его процессов нельзя - иначе это будет уже не внутрисервисный подход
Ну и что? Будет гибридный подход - в деятельность каких-то подразделений вмешиваемся, каких-то других - нет. Не вижу в этом трагедии.
>> дела обстоят хуже, поскольку их владельцы хуже разбираются, как управлять деятельностью именно как сервисом
Мне кажется, все не так страшно. Создавать фреймворк не требуется, требуется всего лишь организовать работу в рамках тех сервисов, явный заказ на которые пришел свыше - от сквозных бизнес-процессов. Все очень предметно, никаких абстракций, в которых, действительно, менеджеры в среднем не сильны.
>> сервисный процесс - это всегда отдельный пул в терминах BPMN
Почему? Я его вижу как подпроцесс. Вызывается синхронно. Никаких проблем.
>>>> вмешиваться в его устройство при построении вызывающих его процессов нельзя - иначе это будет уже не внутрисервисный подход
>> Ну и что? Будет гибридный подход - в деятельность каких-то подразделений вмешиваемся, каких-то других - нет. Не вижу в этом трагедии.
Я ж не говорю, что нужно применить одну и ту же логику взаимодействия для абсолютно всех процессов и подразделений. Например, зачастую внутренние ИТ-процессы представляются другим подразделениям именно в виде сервисов, в то время как другие бизнес-процессы могут быть организованы не в виде сервисов. Но если к конкретному процессу мы применяем внутрисервисный подход, то нужно делать это по всем правилам - т.е. с точки зрения взаимодействия с другими процессами он должен являться черным ящиком.
>>>> дела обстоят хуже, поскольку их владельцы хуже разбираются, как управлять деятельностью именно как сервисом
> Мне кажется, все не так страшно. Создавать фреймворк не требуется…
Речь не о том, чтобы абсолютно все сначала создавали некий абстрактный фреймворк, а потом еще и выстраивали свою деятельность в соответствии с ним. Я имел в виду, что ИТ такой фреймворк уже есть, многие ИТ-руководители с ним знакомы и руководствуют им при выстраивании ИТ-сервиса. А в других областях таких фреймворков может не быть, и там от руководителей требуется определенный талант, чтобы в отсутствие фреймворка (т.е. подсказки) создать хорошо функционирующий сервис. К сожалению, не часто это получается.
>>>> сервисный процесс - это всегда отдельный пул в терминах BPMN
>> Почему? Я его вижу как подпроцесс. Вызывается синхронно. Никаких проблем.
Вызывается синхронно, но исполняется не вполне синхронно. Т.е. вызывающий процесс дает заявку на сервис, эту заявку кто-то принимает синхронно по отношению к вызывающему процессу (если этот процесс не полностью автоматизирован), а дальше заявка на сервис ложится в базу заявок, сервис исполняет ее по своей логике (аналогия с паттерном производственного заказа), в процессе может произойти еще какое-то общение между сервисом и вызывающим процессом в случае каких-то нестандартных ситуаций, в конце сервис сообщает, что он завершил обработку заявки, и вызывающий процесс тогда продолжается. Т.е. все-таки ситуация отличается от той, когда мы просто вызываем подпроцесс, который полностью исполняется внутри определенного подразделения, и выстраивание которого отдается полностью на откуп его руководителю.
Я изобразил, что я имею в виду: https://docs.google.com/open?id=0B8N0PG6hk_54ajF3U09BaVkta28
Дмитрий
Можно и так как Вы изобразили, но я не вижу причин почему сервис не может вызываться синхронно, просто как подпроцесс. Заявки не накапливаются в буфере, а принимаются в работу незамедлительно, в темпе поступления.
Теоретически, можно вызывать сервис и синхронно, т.е. все его действия оказываются обернутыми в повторно вызываемый подпроцесс основного процесса. Но по факту, если выстраивание сервиса отдается на откуп руководителя каждого сервисного подразделения, то чаще всего образовывается именно такая картина, как я изобразил: синхронными в основном процессе остаются только подача заявки на сервис и получение уведомления основным процессом о завершении сервисной операции, плюс реакция на различные события, инициируемые из сервиса. Это происходит из-за того, что невозможно человеку, не являющемуся профессионалом в конструировании БП (а это большинство руководителей в России, к сожалению), абсолютно автономно построить свой подпроцесс так, чтобы он органично встроился в основной процесс - особенно в части реакции на промежуточные события, где все-таки идет взаимодействие с “вызывающим подразделением”, т.е. это перестает быть чисто внутренним делом сервисного подразделения. Поэтому и делается такое разграничение - к такому сервису с точки зрения основного процесса относиться можно только как к внешней сущности. Поэтому реализации подхода, когда в дереве подпроцессов, из которых состоит основной процесс, за выстраивание каждого подпроцесса автономно отвечает руководитель конкретного подразделения, и все это потом органично срастается в единый процесс, я еще не видел. И при текущей культуре менеджмента в России - не верю, что увижу в ближайшее время.
Дмитрий
Что-то мы друг друга не понимаем. Может о разных вещах говорим?
Пример: в рамках процесса подготовки коммерческого предложения технический отдел должен разработать эскизный проект решения, коммерческий - составить смету. Какие обертки, какие события, какая такая особая культура менеджмента? Ничего не понимаю.
Все просто как три копейки: сознательно отказываемся от детализации подпроцессов “разработать решение”, “разработать смету” и трактуем их как задачи, назначаемые соответствующим руководителям.
Пусть рулят как хотят, пусть руководитель управляет подпроцессом в ручном режиме. Да пусть даже в буфере задачи накапливают, как вы изобразили, если хотят - лишь бы SLA выполняли и ресурсов дополнительных для своих подразделений не требовали.
До тех пор, пока внутри задачи каждого такого подразделения отсутствует взаимодействие с другими, это внутренний технологический процесс этого подразделения, и туда, как мы ранее уже обсудили, при выстраивании БП лучше не заныривать глубоко. Взаимодействие внутри подразделения в рамках этого процесса при вашем подходе должен выстроить его руководитель - ну и пусть. Т.е. на самом-то деле это не совсем в чистом виде технологический процесс, но на определенном уровне абстракции мы можем его считать таковым - с точностью до границ подразделения, а не конкретного исполнителя. Я согласен, что можно применять такой подход, хотя в нем есть два “но”:
1) Через некоторое время руководитель подразделения замахается вручную дирижировать внутренним взаимодействием и либо потребует отстроить полноценный процесс, который будет протекать с его минимальным участием (или сделает это сам, если умеет), либо просто забьет, и сервис станет работать неуправляемо. Последнее неблаготворно скажется на соблюдении SLA, но в ряде компаний я наблюдал, как в такой ситуации на протяжении длительного времени от этого руководителя безуспешно требуют подтянуть SLA, а он либо не хочет, либо не умеет выстроить взаимодействие, а передать это бизнес-аналитикам идеология отношения как к сервису не позволяет. Замкнутый круг.
2) Как правило, в ходе выполнения сервиса может потребоваться взаимодействие с вызвавшим его процессом. Мой вариант это предусматривает без прерывания выполнения сервисной задачи, а ваш - только путем ее прерывания с ошибкой и повторного входа заново, насколько я понимаю.
ОК, разобрались наконец - мы таки о разных вещах говорили. Если обслуживающий процесс взаимодействует с основным сложнее, чем на уровне вызов-результат, то Вы правы. Но я на такой сценарий не замахивался и не верю, что в такой постановке его можно отдать на откуп - слишком сложно для того, чтобы сделать такой сервис “на коленке”.