Вы сильно упростите себе работу над BPMN диаграммами и одновременно сделаете их более простыми и понятными, если примете следующие допущения:

  1. Вся информация сохраняется.
  2. У организации есть механизм назначения и передачи поручений.
  3. К каждой задаче прилагается инструкция.
  4. У задач есть нормативные сроки, а у организации — механизм их контроля.

Рассмотрим каждое допущение подробнее.

BPM-блог Анатолия Белайчука

Не спрашивайте, где и как сохраняются данные (атрибуты) процесса. Просто примите как данность, что данные процесса есть где хранить и что вы умеете это делать.

Например, в вашем распоряжении есть реляционная СУБД и вы умеете проектировать структуры данных – ваши специалисты знают, что такое третья нормальная форма, ER-диаграмма (диаграмма «сущность-связь»), SQL и т.п.

Конечно, полностью абстрагироваться от данных не получится – рано или поздно вам придется определиться и с этим. Но лучше поздно, чем рано: если стоящую перед вами сложную задачу можно разделить на две относительно независимые – в данном случае на задачу проектирования процесса и задачу проектирования данных – то это непременно надо делать, потому что так ее решать намного проще.

Пример: процесс «Тендер на закупку» –

Вопрос: на основании каких данных осуществляется выбор победителя?

Ответ: на основании предложений от поставщиков (и, вероятно, результатов их оценки), которые появляются как результат выполнения подпроцесса «Получить предложения от поставщиков».

Все, этого достаточно, работаем со схемой бизнес-процесса в предположении, что предложения, полученные от потенциальных поставщиков, где-то хранятся и доступны последующим задачам процесса. Как именно хранятся – в виде тендерных заявок, полученных в бумажном виде, в виде прайс-листа в формате Excel, полученного по электронной почте, в виде XML-документа, полученного через систему электронных торгов, или в виде таблиц реляционной БД – для работы над схемой процесса в общем-то не важно.

Если перед нами стоит задача не только описания, но и автоматизации этого процесса, то после того, как схема процесса готова, надо будет заняться схемой данных. Например, ER-диаграмма тендерного процесса в первом приближении может выглядеть так:

И в дальнейшем, когда процесс будет дорабатываться, параллельно будут вноситься изменения в схему данных. Но не надо объединять эти два аспекта в одной диаграмме – для проектирования данных есть хорошо зарекомендовавшие себя инструменты, а основное предназначение BPMN –проектирование процессной составляющей.

Хотя в BPMN есть объекты данных и хранилища данных, они выступают в роли «граждан второго сорта». Потоки управления в BPMN обязательны – без них диаграмма не будет корректной, а потоки данных опциональны.

Для некоторых аналитиков такой подход непривычен и даже может вызывать отторжение. Опыт работы в других нотациях подталкивает их к тому, чтобы обильно уснащать диаграммы объектами и потоками данных примерно в таком стиле:

Способствует ли объект данных «Заявка» лучшему пониманию схемы? На мой взгляд, нет: раз одна задача называется «Заполнить заявку», а другая – «Рассмотреть заявку», то и так понятно, что у процесса есть атрибут «Заявка».

Поэтому я пользуюсь объектами данных редко – только там, где они важны для понимания логики и в то же время не очевидны. Например, на BPMN-диаграмме можно показать, что в рамках задачи «Выполнить рейс» создается авансовый отчет по предоставленным водителем затратам:

Особый случай – межпроцессное взаимодействие. Здесь, в отличие от оркестровки, потоки данных существенно важны для понимания логики процесса:

Раз за разом на тренинги по BPMN студенты приносят диаграммы типа такой:

Нет, формально тут все правильно. И вообще, BPMN не навязывает какую-то определенную методологию, поэтому вы имеете полное право выбрать такой стиль моделирования.

Но у меня предложение: давайте сконцентрируемся на том, что надо делать, и не будем загромождать диаграмму паразитными активностями типа передать-получить. Ведь смотрите что получается: если быть последовательными, то на каждую «настоящую» задачу будет приходиться по две паразитных, т.е. число прямоугольников на диаграмме утроится — безрадостная перспектива.

Поэтому я предлагаю принять следующее базовое допущение: когда мы просто и незамысловато изображаем поток управления между двумя задачами —

то это подразумевает, что

  1. В компании есть какой-то механизм передачи задач между исполнителями. Неважно какой именно — это может быть BPMS, электронная почта, телефон, курьеры и лотки входящие-исходящие… да хоть пневмопочта. Так или иначе, если есть утвержденная схема процесса типа приведенной выше и отдел продаж свою задачу выполнил, то мы можем быть уверены, что «эстафетная палочка» процесса перейдет к бухгалтерии.
  2. В компании наличествует исполнительская дисциплина, которая подразумевает, что если есть утвержденная схема процесса, согласно которой, например, отделу продаж назначена задача «Составить калькуляцию», то задача будет выполнена. Нет ни у кого ни права, ни возможности сделать вид, что он не увидел задачу, или не понял, что она назначена ему, или решить ее не выполнять. Если это условие не выполняется, то мы имеем дело с недееспособной организацией — о каком вообще процессном управлении в этом случае можно говорить?

Тут необходимо пояснение: конечно же, когда дело дойдет до внедрения процесса — хоть с помощью BPMS, хоть без — вопросами назначения и передачи ответственности придется плотно заниматься: и договариваться об ответственности за каждую задачу, и разбираться с оргструктурой и каталогами пользователей (LDAP, AD), и (возможно) подтягивать исполнительскую дисциплину, и администрировать процесс в ходе ходе его выполнения — например, исполнитель может уволиться или заболеть, и у нас должны быть средства, чтобы, во-первых, вовремя обнаружить такую ситуацию, а во-вторых, в режиме ручного управления переназначить зависшую задачу исполнителю, может быть даже не предусмотренному утвержденной схемой.

Так что я не пытаюсь принизить значимость этого круга вопросов и тем более не призываю их игнорировать. Просто, как и с данными процесса, я предлагаю с целью упрощения решать задачи по отдельности, и на этапе проектирования схемы процесса от остальных задач абстрагироваться.

Закрывая тему, приведу пример из практики, когда задачи «передать-получить» имеет смысл показать на диаграмме: лизинговая компания пересылает техпаспорт автомобиля (предмета лизинга) в свой филиал во Владивостоке. Тут имеет смысл смоделировать задачу отправки техпаспорта с курьером, причем зафиксировать номер почтового отправления, дату и время, чтобы иметь возможность контролировать ее доставку.

Но для стандартной передачи «эстафетной палочки» процесса достаточно обычного потока управления, соединяющего две содержательные задачи, как показано выше.

Эта рекомендация совсем простая: еще один способ упростить диаграмму – вовремя вспомнить, что к любой задаче можно прикрепить текстовое описание и/или инструкцию для исполнителя.

Это позволяет вместо вот такой схемы (взятой из студенческой работы на BPMN-тренинге) –

обойтись простой и изящной:

а все подробности приемки – как общаться с клиентом, что должно быть в документе, как регистрировать в ERP – опустить на уровень инструкций к задаче. В названии задач отразить только главные, конечные результаты цепочки активностей на данном участке.

Правда, с этим не все согласятся – кто-то может сказать, что первая схема лучше, ведь она более детальная.

Прежде всего, надо разобраться с какой целью мы моделируем бизнес-процессы. Среди всего многообразия вариантов выделю два:

  1. Чтобы научить сотрудников выполнять свои обязанности.
  2. Чтобы повысить эффективность кросс-функциональных, сквозных процессов.

В первом случае лучше первый вариант схемы процесса, во втором – второй. Мне лично ближе второй вариант – объясню почему:

  • В первом случае мы боремся с функциональной некомпетентностью сотрудника (в рассматриваемом процессе – сотрудника сервис-центра). Такая проблема конечно существует, но рисование схемы процесса – не единственный способ ее решения. Можно возложить обязанность по обучению на непосредственного руководителя, можно написать инструкцию, можно организовать базу знаний, можно записать видео-уроки… в конце концов, можно просто поднять зарплату и нанять более толкового сотрудника (как известно, толковому сотруднику инструкции и схемы не нужны, а бестолковому не помогают).
  • Во втором случае исходная диспозиция другая: предполагается, что сотрудники организации функционально грамотны – каждый способен справиться с работой на своем участке. Но бизнес-процесс проходит через множество участков и настолько сложен и длителен, что необходимо предпринимать специальные усилия, чтобы он не застревал на стыках между подразделениями и был бы оптимально организован с точки зрения качества для клиента и эффективного использования ресурсов. И в этой ситуации альтернативы процессному управлению по существу нет – как показывает опыт, написание инструкций и повышение зарплаты не спасают.

Теоретически между двумя обозначенными целями – моделирование процедур на уровне отдельного рабочего места и моделирование сквозных бизнес-процессов – противоречия нет, а BPMN в принципе годится и для того, и для другого. Но на практике почему-то получается или одно, или другое: как только аналитик чересчур концентрируется на процедурных деталях, он теряет из виду «большую» картину. И наоборот: если начать проектировать процесс как сквозной (т.е. начинающийся и заканчивающийся на клиенте), то желание заниматься микроменеджментом как-то пропадает.

Еще одна причина, по которой мне больше импонирует вторая схема – ее большая устойчивость.

Есть такой эффект: любой процесс, если его слишком глубоко детализировать, превращается в кейс. Например, с задачей «Купить персик» справится любой. Но что если слишком увлечься детализацией?

— Милый, я, пожалуй, съела бы персик.

Малыш Мак-Гарри встал и надел пальто и шляпу. Он был серьезен, строен, сентиментален и сметлив.

— Ну что ж, — сказал он так хладнокровно, как будто речь шла всего лишь о подписании условий матча с чемпионом Англии. — Сейчас пойду принесу.

— Только ты недолго, — сказала новобрачная. — А то я соскучусь без своего гадкого мальчика. И смотри, выбери хороший, спелый.

У О.Генри в рассказе «Персики» дело в итоге закончилось тем, что полиция перевернула вверх дном притон Денвера Дика. Могла ли новобрачная предусмотреть такие расклады в схеме процесса? Очевидно нет. Какой отсюда вывод – нас спасет ACM? А может, просто ограничиться задачей, доверив ее надежному исполнителю?

Даешь управление по целям вместо микроменеджмента!

Стандартный вопрос: как показать на диаграмме, что задача должна быть выполнена за 2 часа?

Ответ: обычно это никак не надо изображать. Просто договоримся раз и навсегда, что:

  1. на уровне схемы процесса для любой задачи может быть задана нормативная продолжительность (у задачи есть соответствующий атрибут) и
  2. у организации есть какие-то способы контролировать соблюдение сроков.

Если процесс реализован в BPMS, то можно ожидать, что для контроля в нашем распоряжении будет, во-первых, динамическая отчетность BAM (Business Activity Monitoring), показывающая состояние дел в процессной системе сначала «с высоты птичьего полета», потом, через механизм drill-down, детализированное хоть до отдельного экземпляра процесса. Во-вторых, система предоставит возможность настроить автоматические напоминания о том, что задача назначена, просрочена или снята с исполнителя, которые будут отправляться по email исполнителю или его непосредственному руководителю (а скорее – обоим).

Если процесс исполняется без поддержки BPMS, то на контроль придется расходовать интеллектуальные ресурсы менеджмента – планерки, звонки, устные напоминания… К слову, избавление от этой нервотрепки – один из эффектов использования BPMS, который часто недооценивается.

Но и в том, и в другом случае контроль сроков – это не уровень процессного управления. Это уровень task management – управления поручениями. В конце концов, задачи могут приходить из процессов, из проектов, из процедур, реализованных в корпоративных системах, из кейсов или просто назначаться разово – вариантов много, но во всех у задачи должен быть нормативный срок и способы его контроля.

В принципе, смоделировать в BPMN стандартный контроль сроков исполнения задач достаточно легко –

Но если быть последовательными, мы должны к каждой содержательной задаче прицепить таймер и задачу «Разобраться с просрочкой». Вас такая перспектива радует? Меня – нет. Поэтому я и предлагаю считать, что это уровень управления задачами, а не процессами.

Задача просрочена? Предполагаем, что через систему контроля поручений и исполнитель, и руководство об этом узнает и примут соответствующие меры. В атрибутах задачи указываем нормативную продолжительность, больше на схеме ничего не показываем.

Заметим кстати, что в обычной ситуации превышения фактического срока над нормативным – это не криминал. Если в качестве нормативного срока мы установили среднее время выполнения задачи, то (при условии близости распределения времени выполнения к нормальному) он будет превышаться приблизительно в 50% случаев. И это не будет свидетельством недисциплинированности исполнителя. Просто мы установили напряженный норматив, и это лучше, чем завышать норматив для того, чтобы с комфортом в него укладываться.

Использовать таймеры надо только тогда, когда нам надо показать какие-то действия, отличные от рутинного контроля сроков.

Пример 1: подготовка коммерческого предложения. Если в запросе покупателя установлен жесткий срок подачи предложения, и мы в него не уложились, то продолжать работу над предложением смысла нет:

Пример 2: ожидание доставки. Если груз не пришел в установленный срок, надо связаться с транспортной компанией: