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

Теперь рассмотрим более сложную ситуацию: документы приходят в компанию обычной почтой по официальному почтовому адресу компании и попадают не напрямую на стол участнику того или иного процесса, а в общую канцелярию. » читать дальше

Рассмотрим процесс выдачи банковской карты клиенту:

Рис. 1. Выдача банковской карты с «пассивной» задачей «Выдать карту».

Обратим внимание на задачу «Выдать карту». Бизнес-сценарий: после того как карта изготовлена, клиент в течение 45 дней должен прийти в отделение банка и получить ее. Если считать, что в среднем клиент приходит за картой через 10 дней, и что отделение выдает по 100 карт в день, то у банковского клерка скопится очередь из 1000 задач. » читать дальше

Напомню, что дорожки (lane в BPMN 2.0, swimlane в BPMN 1.x) изображают исполнителей процесса.

Правила для дорожек:

1. Дорожки опциональны – диаграмма может обходиться без них.
2. Дорожки могут быть вложенными (иерархическими).
3. Семантика дорожек может быть любой, на усмотрение автора диаграммы – подразделение, роль, должность…
4. Встроенные подпроцессы (embedded subprocesses) не имеют пулов и, следовательно, не могут иметь дорожек.
5. Дорожки имеют отношение только к задачам, исполняемым людьми (user task) – автоматическим задачам (service task, script task), подпроцессам, развилкам, событиям все равно на какую дорожку вы их поместили.
6. Даже для задач, назначаемых людям, дорожки по сути является комментариями – реальный исполнитель задается в атрибутах модели для данной задачи.

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

Рис.1. BPMN-диаграмма с дорожками.

Однако, используя дорожки, вы лишаете себя возможности показать на магистральный путь процесса (happy path), что, возможно, является более ценным с точки зрения легкости восприятия схемы процесса:

Рис.2. BPMN-диаграмма, на которой показан магистральный путь процесса.

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

Дело в том, что существует универсальное правило, применимое к любой нотации, не только BPMN: число активностей на одном уровне диаграммы не должно превосходить 7-9. Иначе схему становится сложно воспринимать:

Рис.3. “Плоская” диаграмма с большим числом активностей сложна для понимания.

Соответственно, если процесс состоит из большего числа задач, его следует подвергнуть структурной декомпозиции – разбить на подпроцессы:

Рис.4. С помощью подпроцессов сложный процесс можно изобразить в виде простой диаграммы.

Однако в этом стиле моделирования для дорожек не остается места:

• На верхнем уровне остаются только подпроцессы, а дорожки относятся только к задачам, исполняемым людьми (правило 5).
• На схеме подпроцесса нет ни пула, ни дорожек (правило 4).

Точнее, правило 4 относится только к встроенным процессам, а в повторно-используемых процессах дорожки могут быть. Мне приходилось видеть диаграммы, в которых авторы использовали повторно-используемые подпроцессы вместо встроенных исключительно для того, чтобы иметь возможность изобразить дорожки. Это плохая практика – для структурной декомпозиции следует применять встроенные подпроцессы. Повторно-используемые подпроцессы привносят неоправданную дополнительную сложность, так как, в отличие от встроенных, они исполняются в собственном контексте данных.

Если вам так уж необходимо показать исполнителей на схеме встроенного подпроцесса, используйте BPMN-артефакт «группа»:

Рис.5. Исполнители во встроенном подпроцессе изображены группами.

Если вы взялись за достаточно сложный бизнес-процесс, то скорее рано, чем поздно вы столкнетесь с тем, что схема процесса разрослась и стала нечитаемой. Это значит, что пришла пора выполнить иерархическую декомпозицию - проще говоря, разбить процесс на подпроцессы. На BPMN распространяется старое правило: на одном уровне декомпозиции желательно иметь от 5 до 9 активностей.

Рассмотрим в качестве примера процесс заключения договора, состоящий из трех фаз:

1. согласование содержательных условий договора
2. согласование текста договора
3. подписание договора

Зачастую приходится встречать наивные процессные диаграммы типа следующей:

» читать дальше

Мы (Бизнес-Консоль) решили больше не предлагать потенциальным заказчикам пилотные проекты. Сразу говорюсь: идет о проектах PoC (Proof of Concept), которые мы в своей бизнес-практике называем «демонстрационными пилотами».

Сначала расскажу почему, потом – что взамен. » читать дальше

Определение 1: оркестровка (orchestration) - это диаграмма, показывающая последовательность выполнения активностей, координируемых из одного центра.

Примечания:

• Синонимами оркестровки являются поток работ (workflow) и, собственно, процесс.
• В BPMN оркестровка моделируется развернутым пулом (white-box pool), при этом на диаграмме могут опционально присутствовать внешние сущности, моделируемые свернутыми пулами (black-box pool).
• Формулировка “координируемых из одного центра” означает, что, даже если процесс на каком-то шаге распараллеливается, исполнение разных ветвей процесса остается координированным: они могут в дальнейшем синхронизироваться в сходящейся развилке, а процесс в целом завершится тогда, когда завершатся все ветви.

Определение 2: межпроцессное взаимодействие (collaboration) - это диаграмма, показывающая взаимодействие между потоками работ.

Примечания:

• В BPMN 1.x межпроцессное взаимодействие называлось хореографией (choreography). В BPMN 2.0 хореографией стал называться новый, отдельный вид диаграммы, а то, что раньше называлось choreography, теперь называется collaboration. Такие дела.
• На диаграмме межпроцессного взаимодействия отображается больше одного развернутого пула (white-box pool).
• Межпроцессное сообщение иногда сводят к обмену сообщениями (message), но в общем случае процессы могут взаимодействовать при помощи сообщений (message), сигналов (signal) и/или данных (data store, conditional event).
• Отдельные процессы на диаграмме межпроцессного взаимодействия исполняются в целом независимо, за исключением явно обозначенных точек синхронизации - отправки и получения сообщения/сигнала, записи/чтения данных.

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

Тут встречаются две крайности:

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

Рис.1 Антипаттерн “Сообщения вместо подпроцесса”

Обычные аргументы в пользу такой схемы:

• “Вызываемый процесс выполняется другим подразделением.” - Чтобы показать исполнителя, пользуйтесь дорожками (swimlane), а не пулами.
• “Вызываемый процесс можно использовать где-нибудь еще.” - Как и повторно-используемые (reusable) подпроцессы.
• “Явно видна связь между вызывающим и вызываемым процессом.” - Во-первых, развернутый подпроцесс не менее нагляден:

Рис.2 Развернутый подпроцесс

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

Рис.3 Свернутый подпроцесс

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

• когда поток управления доходит до подпроцесса, появляется токен в подпроцессе, а вызывающий процесс переходит в состояние ожидания
• когда подпроцесс завершается, вызывающий процесс продолжает работу

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

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

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

В следующей статье поделюсь опытом, как в ходе анализа выявлять независимые процессы.

Иво Величков заставил меня обратить внимание на разницу между BPMN 1.x и BPMN 2.0 в части моделирования обмена данных.

Обмен данными в BPMN 1.x моделируется при помощи объектов данных (Data Objects):

Рис. 1 Объекты данных в BPMN 1.x

Объект данных в рамках BPMN 1.x  - это артефакт, помогающий описывать процессы. При помощи ассоциации (association) его можно связать с задачей (task), потоком управления (control flow) или сообщением (message flow), при этом никакого воздействия на них он оказывать не будет.

Объектом данных можно изображать самые разнообразные объекты, физические или электронные. Например, мы имеем право изобразить объект данных вне пула и назвать его “база данных заказов”, чтобы смоделировать таким способом межпроцессное взаимодействие через данные.

Однако, как справедливо указал Иво, в рамках BPMN 2.0 приведенная выше диаграмма становится некорректной!

Дело в том, что в BPMN 2.0 объект данных привязан к контексту процесса: он изображается внутри процесса или подпроцесса и существует только в интервале времени от момента запуска экземпляра процесса  (подпроцесса) до его завершения. Соответственно, доступ к ним из другого внешнего процесса невозможен.

Для изображения персистентных данных, не привязанных к жизненному циклу процесса, в BPMN 2.0 служит хранилище данных (Data Store). Его и надо использовать для моделирования межпроцессного взаимодействия через данные в BPMN 2.0:

Рис. 2. Объекты и хранилища данных в BPMN 2.0

BPMN 2.0 различает единичные объекты данных и коллекции (collection) - последние помечаются специальным маркером. В нем также введены специальные обозначения для данных-входов и данных-выходов (Data Input, Data Output) и новые элементы - наборы входных и выходных данных (Input Sets, Output Sets).

BPMN 2.0 также определяет ассоциацию по данным (Data Association) в добавок к обычной ассоциации (Association), унаследованной из 1.x. Если обычная ассоциация, как и в BPMN 1.x, служит чисто для целей документирования, то ассоциация по данным является “исполняемой”: вы можете определить для нее на уровне атрибутов модели процесса входные и выходные данные и, опционально, трансформацию. Таким образом можно на уровне диаграммы описать манипуляции с данным при старте и завершении активности, отправке или получении сообщения. Изображаются на диаграмме ассоциации по данным так же, как и обычные - точечным пунктиром с V-образной стрелкой.

В спецификации BPMN 2.0 есть небольшое противоречие, относящееся к ассоциации по данным:

• На странице 221 говорится, что ассоциация по данным используется с объектами данных, причем хранилища данных при этом не упоминаются. Учитывая, что объекты данных обязаны принадлежать процессу, из этого можно сделать вывод, что ассоциация по данным не может пересекать за границы пула. Такое правило сделало бы вторую диаграмму некорректной - см. комментарий Иво Величкова.
• Но на стр. 208 спецификации совершенно определенно говорится, что хранилище данных может служить входом или выходом для ассоциаций по данным.

Так что я все же полагаю, что схема на рис.2 является корректной.

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

Это третья и завершающая часть исследования на тему управления кросс-функциональными процессами. Предыдущие части:

1. Вульгарное представление о кросс-функциональных бизнес-процессах
2. Кросс-функциональные паттерны

Во второй части мы рассмотрели два основных способа организации работы смежных участков в рамках кросс-функционального бизнес-процесса:

• Синхронный - подразделение-исполнитель приступает к работе сразу, как только поступил заказ из подразделения-заказчика. Технически реализуется одним процессом.
• Асинхронный - заказы накапливаются во входном буфере подразделения-исполнителя, затем с некоторой периодичностью извлекаются оттуда и обрабатываются. Технически может реализовываться двумя (в случае планирования единственного ресурса) или большим числом процессов.

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

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

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

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

Как же примирить эти точки зрения? Попробуем дать рекомендации по выбору оптимальной схемы работы,

» читать дальше

Спонсор одного из наших BPM-проектов как-то сказал в самом начале, когда мы только обсуждали возможный проект: “моим сотрудникам не нужно чтобы их контролировали, им нужно чтобы им помогали”. В тот момент я заспорил, но потом понял - он прав!

В самом деле: что мы имеем в виду, когда говорим о контроле за бизнес-процессами? И надо ли считать параноиками участников процесса, когда они подозревают, что на самом деле цель всей этой затеи - контролировать их самих?

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

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

Это сложные задачи. Реально сложные.

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

Пример:

• Небольшая торговая компания, специализирующаяся на товарах «с изюминкой» - гаджетах, прикольных подарках, дизайнерских аксессуарах для ванн и т.п.
• Группа процессов под названием «Управление ассортиментом»: несколько сотрудников постоянно мониторят интернет, ходят на выставки, заглядывают в магазины конкурентов - ищут новые идеи, бренды, новых поставщиков. С одной стороны, в силу специализации компании ассортимент должен постоянно пополняется модными штучками, а с другой - ассортимент не может быть слишком большим, его надо постоянно прореживать.
• Эти несколько человек ежемесячно оценивают до тысячи кандидатов на включение в ассортимент. Компания выработала трехступенчатое сито отбора: сначала экспертная экспресс-оценка, бракующая большинство идей. Затем переговоры с поставщиком, проработка логистики и оценка возможной прибыльности. Затем - раз в месяц - ранжирование идей, прошедших первую и вторую квалификацию, и отбор кандидатов на пробную закупку и реализацию с учетом имеющегося на данный момент бюджета на расширение ассортимента.
• Параллельно, также примерно раз в месяц, весь текущий ассортимент анализируется с точки зрения фактической продаваемости, разнообразия и т.д.

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

Что тут можно сделать, если идти по пути наименьшего сопротивления? Ну например, можно автоматизировать оценку кандидатов на включение в ассортимент - сделать процесс из пяти последовательных шагов:

1. узнать цены у поставщика
2. узнать условия поставки
3. оценить продаваемость
4. назначить рейтинг
5. принять решение о пробной закупке

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

Во вторых, какой в смысл в такой схеме, если все шаги выполняет один человек? Это ведь махровый микроменеджмент. Что, разве проблема тут в том, чтобы проконтролировать последовательность задач? Ясно ведь, что не в этом, а в том, чтобы уследить за сворой одновременно и асинхронно протекающих процессов: сотнями процессов, проходящими первый этап квалификации, десятками - второй, процессами отбора в и отсева из ассортиментами. А для этого нужно реализовать не workflow, а достаточно сложное межпроцессное взаимодействие.

Люди хотят не чтобы их контролировали под видом процессов, а чтобы им помогли контролировать действительно сложные процессы.

Если вы им это дадите - противодействия не будет, люди с благодарностью будут пользоваться BPM-системой. Проверено на практике.

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

Представьте себе, что у вас появился робот-помощник. Безотказный и безошибочный. Он возьмет на себя самую нудную, канцелярскую часть вашей работы. Например, вы сможете ему сказать:

• «Робот, проследи, чтобы это заявление попало на стол к кому положено.»
• «Робот, оформи по этим данным накладную и запиши его в БД бухгалтерии.»
• «Робот, дай мне знать, когда придет оплата по этому счету.»
• «Робот, когда производство планирует изготовить этот заказ?»
• «Робот, рассчитай рейтинг этого клиента по нашей стандартной методике.»
• «Робот, не спускай глаз с этого заказа, и если он застрянет, дай мне знать.»
• «Робот, дай мне все заявки на оплату на завтра и отсортируй их по контрагентам.»
• «Робот, что шеф говорил по поводу этой рекламации на прошлой неделе?»
• «Робот, клиент отказался от заказа - отзови его из производства, если еще не поздно.»

Кто, скажите мне, откажется от такого помощника?

К тому же BPM-робот безопасен, потому что он подчиняется законам - хотя и не тем, что у Айзимова.

Законы робототехники BPM:

1. Робот никогда не сможет сделать все то, что можете сделать вы.
2. Робот будет делать только часть того, что делаете вы.
3. Робот будет делать только ту часть вашей работы, которую вы сами не захотите делать.

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

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

В данной статье мы рассмотрим паттерны, характерные для кросс-функциональных процессов.

Воспользуемся следующим примером:

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

В простейшем виде процессная диаграмма может выглядеть так:

» читать дальше