Базовые допущения BPMN:
- Вся информация сохраняется
- У организации есть механизм назначения и передачи поручений
- К каждой задаче прилагается инструкция
- У задач есть нормативные сроки, а у организации - механизм их контроля
3. К каждой задаче прилагается инструкция
Эта рекомендация совсем простая: еще один способ упростить диаграмму – вовремя вспомнить, что к любой задаче можно прикрепить текстовое описание и/или инструкцию для исполнителя.
Это позволяет вместо вот такой схемы (взятой из студенческой работы на BPMN-тренинге) –
обойтись простой и изящной:
а все подробности приемки – как общаться с клиентом, что должно быть в документе, как регистрировать в ERP – опустить на уровень инструкций к задаче. В названии задач отразить только главные, конечные результаты цепочки активностей на данном участке.
Правда с этим не все согласятся – кто-то может сказать, что первая схема лучше, ведь она более детальная.
Прежде всего, надо разобраться с какой целью мы моделируем бизнес-процессы. Среди всего многообразия вариантов выделю два:
- Чтобы научить сотрудников выполнять свои обязанности.
- Чтобы повысить эффективность кросс-функциональных, сквозных процессов.
В первом случае лучше первый вариант схемы процесса, во втором – второй. Мне лично ближе второй вариант – объясню почему:
- В первом случае мы боремся с функциональной некомпетентностью сотрудника (в рассматриваемом процессе – сотрудника сервис-центра). Такая проблема конечно существует, но рисование схемы процесса – не единственный способ ее решения. Можно возложить обязанность по обучению на непосредственного руководителя, можно написать инструкцию, можно организовать базу знаний, можно записать видео-уроки… в конце концов, можно просто поднять зарплату и нанять более толкового сотрудника (как известно, толковому сотруднику инструкции и схемы не нужны, а бестолковому не помогают).
- Во втором случае исходная диспозиция другая: предполагается, что сотрудники организации функционально грамотны – каждый способен справиться с работой на своем участке. Но бизнес-процесс проходит через множество участков и настолько сложен и длителен, что необходимо предпринимать специальные усилия, чтобы он не застревал на стыках между подразделениями и был бы оптимально организован с точки зрения качества для клиента и эффективного использования ресурсов. И в этой ситуации альтернативы процессному управлению по существу нет – как показывает опыт, написание инструкций и повышение зарплаты не спасают.
Теоретически между двумя обозначенными целями – моделирование процедур на уровне отдельного рабочего места и моделирование сквозных бизнес-процессов – противоречия нет, а BPMN в принципе годится и для того, и для другого. Но на практике почему-то получается или одно, или другое: как только аналитик чересчур концентрируется на процедурных деталях, он теряет из виду «большую» картину. И наоборот: если начать проектировать процесс как сквозной (т.е. начинающийся и заканчивающийся на клиенте), то желание заниматься микроменеджментом как-то пропадает.
Еще одна причина, по которой мне больше импонирует вторая схема – ее большая устойчивость.
Есть такой эффект: любой процесс, если его слишком глубоко детализировать, превращается в кейс. Например, с задачей «Купить персик» справится любой. Но что если слишком увлечься детализацией?
- Милый, я, пожалуй, съела бы персик.
Малыш Мак-Гарри встал и надел пальто и шляпу. Он был серьезен, строен, сентиментален и сметлив.
- Ну что ж, - сказал он так хладнокровно, как будто речь шла всего лишь о подписании условий матча с чемпионом Англии. - Сейчас пойду принесу.
- Только ты недолго, - сказала новобрачная. - А то я соскучусь без своего гадкого мальчика. И смотри, выбери хороший, спелый.
У О.Генри в рассказе «Персики» дело в итоге закончилось тем, что полиция перевернула вверх дном притон Денвера Дика. Могла ли новобрачная предусмотреть такие расклады в схеме процесса? Очевидно нет. Какой отсюда вывод – нас спасет ACM? А может просто ограничиться задачей, доверив ее надежному исполнителю?
Даешь управление по целям вместо микроменеджмента!
Еще по теме:
Окончание следует…
Анатолий, здесь виден обычный конфликт между бизнес-процессом и технологическим процессом. Приведенные мной термины могут варьироваться, но суть их в том, что бизнес-процесс описывает взаимодействие между участниками, в то время как технологический указывает, каким образом получить требуемый результат. Т.е., описывая бизнес-процесс, задаемся вопросами “что делать”, “что и где брать”, “что и кому передавать”. Описывая технологический процесс, задаемся вопросом “КАК получить то, что нужно”. И эти два взгляда на один и тот же процесс тесно связаны, поскольку, моделируя взаимодействие, нужно быть уверенным, что каждый исполнитель в бизнес-процессе действительно сможет исполнить свой этап технологического процесса, т.е. взяв на входе то, что ему предоставили, получить на выходе то, что от него требуется. И неверие в то, что специалисты на местах способны исполнить свой технологический процесс, порождает то, что вместо моделирования бизнес-процесса, т.е. аспектов взаимодействия, начинают моделировать технологический процесс, т.е. аспект получения результата. Таким образом, вместо моделирования бизнес-процесса опускаемся на уровень ниже. Отсюда логичный вариант, как совместить и одно, и другое, если это очень требуется (хотя, согласен требуется это на самом деле не всегда, но иногда все-таки полезно): те задачи бизнес-процесса, в которых хочется детализировать технологический процесс средствами 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) Как правило, в ходе выполнения сервиса может потребоваться взаимодействие с вызвавшим его процессом. Мой вариант это предусматривает без прерывания выполнения сервисной задачи, а ваш - только путем ее прерывания с ошибкой и повторного входа заново, насколько я понимаю.
ОК, разобрались наконец - мы таки о разных вещах говорили. Если обслуживающий процесс взаимодействует с основным сложнее, чем на уровне вызов-результат, то Вы правы. Но я на такой сценарий не замахивался и не верю, что в такой постановке его можно отдать на откуп - слишком сложно для того, чтобы сделать такой сервис “на коленке”.