Процессный паттерн: “Внутренний заказ”

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

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

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

Такое асинхронное взаимодействие процессов подразумевает наличие между ними буферов, в которых накапливаются задания, передаваемые от процесса-заказчика к процессу-исполнителю. В рассматриваемом примере это “Производственные заказы” и “Плановые остатки сырья и комплектующих”. Технически буфер может реализовываться по-разному: очередью сообщений, записями таблицы базы данных или объектами ERP-системы, находящимися в определенном состоянии. Естественно, внутреннее устройство буфера желательно скрыть, создав сервисы для работы с ним - добавления, просмотра, извлечения.

Современные BPMS позволяют и моделировать, и исполнять подобные схемы, и в этом их коренное преимущество перед традиционными workflow-системами. Другое дело, что аналитики осваивают такие схемы с большим трудом - см. например Bruce Silver, “BPMN to Requester: Get Outta My Pool”. Основная сложность тут не в нотации, а в развитии “асинхронного мышления”. Вы должны научиться вычленять из того, что бизнес преподносит вам как единый процесс, отдельные асинхронные процессы. Помогают разобраться в этом ответы на два вопроса: 1) с каким бизнес-объектом связан экземпляр процесса и 2) с какими событиями связаны начало и завершение экземпляра процесса.

Например, даже в таком относительно простом процессе, как прием сотрудника на работу, мы видим набор бизнес-объектов: 1) позицию штатного расписания, 2) заявку руководителя в кадровую службу о необходимости замещения вакантной позиции штатного расписания, 3) вакансию, объявленную по определенному каналу поиска кандидатов, 4) кандидат, 5) принятый сотрудник. Связаны они между собой не как 1:1, и их жизненные циклы не синхронны. Например, кандидаты присылают резюме, не заботясь о том, если ли у предприятия для них вакансия - дело кадровой службы оценить для какой вакансии (каких вакансий) его стоит рассматривать. Поэтому одним процессом вам врядли удастся обойтись; сколько их получится в итоге - зависит от конкретики вашего бизнеса.

Интересно, что прием на работу - это классический пример бизнес-процесса, который BPM-вендоры любят использовать для демонстрации своих продуктов. Но при этом они пытаются обойтись одним процессом! Видимо, такие демонстрации делают разработчики, а не консалтеры.

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

Комментарии (36)

Готов подписаться под каждым словом. Признаюсь, сам долго не понимал, к чему все эти асинхронные взаимодействия в BPMN, но жизнь научила.

Однако, хотелось бы двинуться дальше. Действительно возникают всякие буферы между процессами, которые должны хранить различные объекты. А процессы должны уметь писать-читать эти объекты. Но если делать соответствующие сервисы на Java или .Net - это история долгая и мучительная. Заявляю это на основании личного опыта - занимаеся этим 1,5 года вокруг TeamCenter. В то же время есть правильные высокоуровневые языки (Ruby, Python, Groovy,…), которые превращают все махинации с объектами в удовольствие. Только нет BPMS, написанных на Ruby, Python, Groovy… Вам такие не известны?

И некоторые сомнения по поводу терминологии.

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

Получается, что один процесс - это хореография. Много взаимодействующих асинхронных (оркестр!) - оркестровка.

А теорема без доказательства - это лемма.

Я думаю, тут вот какая аналогия: в оркестре всем управляет дирижер. Танец - это искусство вести партнера и подстраиваться под него. (Подразумевается, что танец в одиночку - это не танец.)

В продолжение этой заметки собираюсь поделиться своими соображениями о параллелях между синхронными-асинхронными делами и теорией ограничения Голдрата - оставайтесь на связи!

По поводу терминологии: термины хореография и оркестровка вполне корректны, на мой взгляд. По крайней мере, в английском языке их аналоги choreography and orchestration применяются именно в таких значениях в области BPM.

BPMN дает большую свободу при моделировании. Поэтому нельзя сказать, что есть “правильные” или “неправильные” модели. Я хочу дать некоторые комментарии по поводу модели BPMN: 1. Все действия в диаграмме названы существительными. По моему мнению, с методической точки зрения, значительно лучше именовать действия глаголами. Например, “Аванс”-”Получить аванс”, “Запуск в производство”-”Запустить в производство”, “Отгрузка”-”Отгрузить товары”. 2. Идея с асинхронными бизнес процессами корректна, но в терминах пулов BPMN она выражена не совсем правильно. Пулы предназначены для отображения участников бизнес процесса. Таким образом, пул “Приобретение комплектующих” может быть переименован в “Отдел закупок”. Пул “Производство” имеет корректное имя, если рассматривать его не как название бизнес процесса, а название подразделения. Пул “От заказа до оплаты” можно разделить на несколько пулов. Например, на бухгалтерию, которая получает аванс и занимается оплатой и расчетами, и отдел логистики, который отгружает товары. 3. Сообщение, которое посылается по окончанию производства (в пуле “Производство”) может обрабатываться отдельным событием (intermediate catching message event), которое нужно добавить после действия “Запуск в производство”. Это позволит визуально показать, что процесс ожидает получения этого сообщения. 4. Циклическое действие в пуле “Производство” может быть также заменено действием “Множественные экземпляры” (multiple instance activity). Это отразит, что действие выполняется для каждого объекта из множества.

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

Комментарии к комментарию Сергея: 1) Согласен, это стандартная рекомендация. Просто не хотелось загромождать диаграмму длинными названиями, это ведь всего лишь эскиз. 2) Вы ошибаетесь. Представление о том, что пулы - это участники процесса, является заблуждением. Впрочем весьма распространенным. Собственно, способствовать искоренению этого заблуждения было одной из целей данной заметки. См. заметку Брюса Силвера на эту тему http://www.brsilver.com/wordpress/2008/06/11/bpmn-to-requester-get-outta-my-pool/ “One of BPMN’s most important elements is unfortunately also the most misunderstood. It’s called a pool, a rectangular shape that serves as a container for a process. So in that sense a pool is synonymous with a process, and that’s as basic as you can get… One of the confusing things to business analysts who find the time to read the BPMN spec is that the spec says pools are used to distinguish process “participants.” But the spec means participants in the SOA sense, i.e. requester or provider, not in the sense of roles within the orchestration, like Manager and HR. Those are depicted as lanes within the internal process pool.” “Приобретение комплектующих” не следует переименовывать в “Отдел закупок”. Отдел закупок - это swimlane внутри этого процесса, наряду с прочими. 3) Считайте, что получатель сообщения находится внутри подпроцесса “Запуск в производство”. 4) Согласен, multiple instance на этой диаграмме были бы более уместны, спасибо за подсказку.

Иной, вы правы, идея “поиска одного, правильного алгоритма” ошибочна, как раз об этом я писал в заметке http://mainthing.ru/ru/item/131/. Здесь же речь идет о том, что необходимой гибкости можно достичь, разбив сквозной процесс на отдельные процессные компоненты. Эти компоненты как раз и будут инициироваться “разными источниками и с разной скоростью”.

я решил углубиться в документацию и обратился к спецификации BPMN (BPMN 1.2, впрочем это верно и для версий 1.0 и 1.1). В разделе 9.6.2 я нашел, что:

“A Pool represents a Participant in the Process. A Participant can be a specific business entity (e.g., a company) or can be a more general business role (e.g., a buyer, seller, or manufacturer).” то есть “Пул представляет участника в процессе. Участником может быть как конкретная бизнес единица (например, компания), так и бизнес роль в более абстрактном смысле (например, продавец, покупатель или производитель).”

далее переходим на определение понятия Participant в той же спецификации (Annex C: Glossary): “A Participant is a business entity (e.g., a company, company division, or a customer) or a business role (e.g., a buyer or a seller), which controls or is responsible for a business process. If Pools are used, then a Participant would be associated with one Pool.” то есть “Участник - это бизнес сущность (например, компания, подразделение или клиент) или бизнес роль (например, покупатель или продавец), которая контролирует или ответственна за бизнес процесс. При использовании пулов участник ассоциируется с одним пулом.”

Мне кажется, что спецификация достаточно однозначно определяет понятие участника, а следовательно мое заблуждение не лишено оснований

ОК, давайте заглянем в спецификацию BPMN 1.1, http://www.bpmn.org/Documents/BPMN%201-1%20Specification.pdf (Кстати, на bpmn.org есть только версии 1.0, 1.1 и RFP к версии 2.0.)

Раздел 7.1, “BPMN Scope”, подраздел “Abstract (Public) Processes” (стр.13):

“This represents the interactions between a private business process and another process or participant… Abstract processes are contained within a Pool and can be modeled separately or within a larger BPMN Diagram to show the Message Flow between the abstract process activities and other entities.”

Чуть ниже, подраздел “Types of BPD Diagrams” (стр. 14):

“Within and between these three BPMN sub-models, many types of Diagrams can be created. The following are the types of business processes that can be modeled with BPMN: o Detailed private business process with interactions to one or more external entities (or ‘Black Box’ processes) o Two or more detailed private business processes interacting o Detailed private business process relationship to Abstract Process o Detailed private business process relationship to Collaboration Process o Two or more Abstract Processes o Abstract Process relationship to Collaboration Process …”

Теперь вернемся к упомянутому Вами разделу 9.6, но только к самому его началу (стр. 86):

“BPMN uses the concept known as ’swimlanes’ to help partition and/organize activities. It is possible that a BPMN Diagram may depict more than one private process, as well as the processes that show the collaboration between private processes or Participants. If so, then each private business process will be considered as being performed by different Participants. Graphically, each Participant will be partitioned; that is, will be contained within a rectangular box called a ‘Pool.’ Pools can have sub-Swimlanes that are called, simply, ‘Lanes.’

Section 7.1.1, ‘Uses of BPMN,’ on page 12 describes the uses of BPMN for modeling private processes and the interactions of processes in B2B scenarios. Pools and Lanes are designed to support these uses of BPMN.”

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

Если серьезно, то спецификации BPMN всех версий не критиковал за противоречивость только ленивый, на них прямо-таки горит клеймо “design by committee”. По-видимому, можно трактовать и так, и эдак. Но я человек практики, и я на практике убедился, что трактовка пула как процесса позволяет создавать более ясные и логичные диаграммы. Поэтому за эту трактовку и агитирую.