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

Фактически речь идет о двух способах решения задач:

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

Какое-то мутноватое получается объяснение, не так ли? Добавляет путаницы то, что английские “template” и “pattern” зачастую оба переводят как “шаблон”, и смысл при этом частично теряется.

Думая о том, как это можно объяснить “на пальцах”, нашел аналогию в шахматах:

• Дебюты из шахматных учебников - это шаблоны: учи и разыгрывай, в учебнике все расписано от стартовой позиции и на 20 ходов вперед.
• Типовые комбинации миттельшпиля - это паттерны. Например, “вилка” - это паттерн: увидел в позиции возможность ее сделать - делай, или угрожай, что сделаешь. Сдвоенные по вертикали ладьи - это паттерн, а сдвоенные пешки - это антипаттерн: если есть возможность, старайся избегать таких позиций. Но в учебнике нет и не может быть инструкции как, начав партию, сделать противнику вилку.

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

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

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

Паттерны в BPM - это типовые фрагменты процессов или межпроцессного взаимодействия (некоторые примеры).

Уместно спросить: от чего больше пользы? Мое мнение - от паттернов:

• Шаблоны специфичны (один процесс - один шаблон), паттерны универсальны. Хороший паттерн можно использовать в самых разных бизнес-процессах независимо от отраслевой специфики.
• Польза от шаблона на практике оказывается меньше ожидаемой. Как правило, позаимствовать удается только магистральный путь (happy path), а дьявол оказывается в деталях - в обходных путях, в обработке нештатных ситуаций.
• Эффект от использования правильного паттерна может быть очень большим. Например, в нашей практике был случай, когда процесс, изображенный на 6 склеенных друг с другом листах формата А4, за счет использования правильного паттерна удалось свести к изящной конструкции из 15 процессных шагов.
• Что касается антипаттерна, его польза в том, что в нужный момент он предостережет вас от ошибки. Цена ошибки теоретически может быть любой, и иногда реально большой.

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

Пример:

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

В рассматриваемом примере мы как минимум должны предусмотреть три варианта:

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

В BPMN специально для такой ситуации предусмотрена конструкция под названием “исключающая развилка, управляемая событиями” (exclusive event gateway):

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

К большому сожалению, поставщики BPMS склонны относиться к event gateway как к излишеству. Мне известно несколько систем, разработчики которых декларируют приверженность BPMN, но не поддерживают эту конструкцию.

Боюсь, это ошибка с их стороны - ведь задача обработки альтернативных сообщений никуда не денется! В отсутствие event gatway единственный путь - использовать параллельную развилку (parallel gateway). Но тут возникает проблема “гашения” остальных путей при приходе одного из сообщений, которую приходится решать при помощи искусственных конструкций в диаграмме и/или написания программного кода. Конечно, ни о визуальной наглядности процесса, ни о следовании стандарту речь при этом уже не идет.

Таким образом, рассматриваемый антипаттерн необычен тем, что источник его - не процессный аналитик, а разработчик BPMS. С другой стороны, в силах поставщиков BPMS сделать так, чтобы этот антипаттерн исчез - для этого им достаточно изменить свое отношение к поддержке event gateway.

Пока конкретная BPMS не поддерживает event gateway, нормально работать с сообщениями (message flow) в ней невозможно. Оркестровка в ней поддерживается, хореография - нет. На мой взгляд, такая система - это старый добрый workflow вне зависимости от наличия на нем лэйбла BPMN.

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

Пример 1: процесс заключения договора. Ближе к завершению процесса договор должен быть подписан с нашей стороны директором:

Хотя бы из уважения к директору дайте ему возможность не подписать договор - предусмотрите развилку (gateway) сразу за шагом “подписать договор”.

Пример 2: в процессе выполнения заказа клиента компания-посредник размещает заказ у партнера:

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

Тут возникает вопрос меры: с одной стороны, никто не отменял рекомендацию начать моделирование процесса с т.н. “happy path” - максимального гладкого варианта протекания процесса. И в happy path приведенные диаграммы вполне уместны.

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

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

BPM осваивает новую территорию, которую называют по-разному: dynamic processes, unstructured processes, knowledge worker processes, barely repeatable processes, case management. (На русский не перевожу - так как термины относительно новые, перевод только запутает дело.)

BPM сейчас достиг стадии зрелости, при которой управление повторяющимися и предсказуемыми процессами стало делом техники. Это позволяет уверенно решать задачи надежного исполнения процесса “ненадежными” сотрудниками - низкооплачиваемыми, с невысокой квалификацией и слабой мотивацией. Такие задачи на практике встречаются достаточно часто; особенно они характерны для государственных и полугосударственных организаций и для бизнеса, исповедующего экстенсивный путь развития.

Но только “особо одаренные” считают, что жестко структурировать можно любой процесс:

Оставляя в стороне крайности - полностью структурированные и полностью ситуативные (ad-hoc) процессы - получаем два варианта сочетания тех и других. Либо структурированный процесс обращается к ситуативному, либо наоборот:

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

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

• На конференции Гартнер BPM’2009 была озвучена следующая оценка: до 60% процессов в организации являются неструктурированными и как следствие, неконтролируемыми, неуправляемыми, невидимыми и не регулируемыми правилами. Эти 60% похожи на среднюю температуру по больнице, но “невидимость” этих процессов действительно может быть основной проблемой с точки зрения бизнеса.
• “Обращение к коллективному знанию будет двигать вперед неструктурированные процессы” - Джим Синур (Гартнер) предсказывает, что задействование технологий накопления знаний, отраслевых и социальных сетей приведет к новой волне фундаментальных изменений в BPM и BPMS. Еще один его пост на эту же тему: “Белые воротнички и неструктурированные процессы подходят друг к другу как сыр к вину“.
• То, как стремительно приобрели популярность социальные сети (те же “одноклассники”), подталкивает к мысли позаимствовать наработанные в них подходы для организации общения в рамках динамических процессов - см. доклад о спектре возможных применений social software в BPM на BPM-конференции в Ульме. Скажем, сталкиваясь с проблемой, я публикую вопрос в корпоративной сети (”помощь зала”). Его видят мои “френды” (в числе которых менеджер проекта и тим-лид). Автор лучшего ответа получает бонус.
• SAP предлагает использовать для совместной работы технологию Google Wave - но не для исполнения процесса, а для его проектирования. SAP Gravity представляет собой реализацию BPMN-редактора в среде Google Wave. Что касается исполнения, то надо понимать, что возможность проектирования процесса “на лету”, в ходе его исполнения, является важным аспектом динамичности, поэтому SAP создает задел не только для выявления, но и для исполнения динамических процессов.
• Oracle тоже говорит о collaborative BPM и dynamic BPM и при этом подчеркивает свою приверженность архитектуре SCA, позволяющей комбинировать различные процессные составляющие с бизнес-правилами, аналитикой и т.д. Что ж, учитывая, что за два года Oracle приобрел 50 компаний, продукты которых необходимо интегрировать, для них это особенно актуально.
• HandySoft, ActionBase и другие вендоры заявляют о поддержке динамических процессов в последних версиях своих продуктов.
• Самые авторитетные специалисты отрасли собираются, чтобы обсудить проблемы динамических процессов и в частности, их поддержку в BPMN.

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

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

Альтернативное название: “Микроменеджмент”.

Типичное затруднение первого BPM-проекта: “на какую глубину копать”, до какого уровня детализировать бизнес-процесс?

В одном из первых наших первых проектов мы занимались процессом под названием “Заказ по трехстороннему договору”. Суть дела:

• Имеется трехсторонний договор, по которому Покупатель приобретает товары у Производителя при посредничестве авторизованного партнера.
• Договор оформлен как рамочный: он оговаривает цены, условия и сроки, но не объемы закупок. Каждая закупка должна оформляться отдельным заказом, который уже содержит конкретные номенклатуры и количества и который после подписания влечет контрактные обязательства для всех сторон по договору.
• Задача управления процессом была поставлена партнером, что совершенно естественно, так как за логистику отвечал в основном он. При этом задача подключения к BPM-системе покупателя или производителя не ставилась. Т.е. процесс от начала до конца протекал как бы внутри организации партнера, но при этом в нем наличествовали такие шаги, как “отправить заказ на подпись поставщику” или “отгрузить товар заказчику”.

По-крупному процесс состоял из четырех этапов:

1. согласование заказа
2. подписание заказа
3. поставка товара
4. оплата и закрытие заказа

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

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

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

Избавлю вас от описания эволюции процесса и перейду сразу к схеме, к которой мы пришли в итоге:

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

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

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

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

Еще один часто задаваемый вопрос из форума.

Вопрос - В случае изменения шаблона бизнес-процесса (добавили/удалили активити) что происходит с реальными начатыми по этому шаблону (в предыдущей версии) бизнес-процессами? Что происходит в связи с этим с аналитикой?

Ответ - Большинство BPMS в такой ситуации завершат начатые экземпляры бизнес-процесса по старому шаблону, а новые будут создавать по новому. Это можно считать удовлетворительным решением только если изменение шаблона - плановое. Если же, как часто бывает, процесс зашел в тупик из-за того, что в шаблоне в данном месте не предусмотрели переход или развилку, то все что вам остается, это аварийно завершить данный экземпляр процесса и начать его снова по новому шаблону. Аналитика при этом накрывается.

Однако системы, которые позволяют модифицировать схему процесса “на лету”, существуют. Рекомендуемое чтение по теме:

• Статья Glen Smith из Appian на ebizq.net рассказывает почему важно иметь такую возможность с методологической точки зрения. Если над вами не довлеет жесткая необходимость выявить процесс до мельчайших деталей всех возможных исключений, то вы можете быстрее запустить его в эксплуатацию.
• Keith Svenson из Fujitsu обращает внимание на то, что изменение схему “на лету” принципиально очень сложно реализовать в системах, в которых для исполнения процесса используется BPEL. Fujtsu Interstage BPM позволяет вам отредактировать схему экземпляра процесса точно так же, как и схему шаблона, и при желании, сохранить полученную схему в качестве новой версии шаблона.

За информацией о последней версии конкретной BPMS обращайтесь к отчету BPTrends.

Если редактор бизнес-процессов (моделер) реализован в виде десктопного приложения (а именно так обстоит дело в большинстве систем), то это принципиально ограничивает возможность исправления процесса “на лету”. Если экземпляр процесса застрял, то необходимо иметь возможность оперативно, в онлайне исправить схему. То есть моделер должен быть реализован в виде тонкого клиента. К примеру, в Fujitsu Interstage имеется и десктопная версия моделера, и онлайновая в виде апплета.

В Oracle BPMS (aka BEA AquaLogic BPM aka Fuego) выбран другой путь. В палитре этой системы есть специальный “магический” активити, который может забрать на себя управление с любого активити и/или передать на любой активити. Это решает большую часть проблемы - отсутствие на схеме необходимого перехода.

Но не стоит полагаться только на инструментарий - надо грамотно проектировать схему процесса.

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

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

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

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

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

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

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

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

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

Определение:

• Процессом масштаба предприятия (”enterprise process”) или, что то же самое, сквозным (”end-to-end process”) называется бизнес-процесс, замкнутый по входу и выходу на внешнего заказчика и проходящий через более чем одно подразделение верхнего уровня.

Аксиома:

• Инициатива BPM окупится только если вы беретесь за сквозные процессы.

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

Типичные ошибки:

1. BPM-вендоры любят иллюстрировать возможности своих продуктов на вспомогательных процессах типа “Прием на работу” или “Отчет о командировочных расходах” и тем самым провоцируют заказчиков заниматься тем же самым. Для тренировки сгодится, но за подобными процессами просто слишком мало денег, чтобы оправдать затраты на проект масштаба компании. А иным проект BPM не может быть по определению.
2. Половина потенциальных клиентов предлагает заняться процессом “Заключение договора”. Тут с ценой вопроса все в порядке, но это, как бы сказать, не вполне процесс. Правильнее рассматривать его как фрагмент сквозного процесса “Продажа товара/услуги”. Ведь заказчика интересует конечный результат, т.е. показатели процесса в целом, и не факт, что именно этот фрагмент процесса критичен. (Такое сужение “рамки” и называется субоптимизацией.)
3. И совсем тяжелый случай: “Вот у нас тут есть процесс, мы его хорошо знаем и уже автоматизировали, давайте для сравнения сделаем его в BPM.” То есть давайте устроим соревнование лучшего с хорошим. Если вы хотите, чтобы ваш проект оценило руководство, вы обязаны не просто реализовать какой-то процесс в BPM, но добиться в результате этого существенного улучшения его показателей. Врядли вы этого добьетесь на процессе, с которым уже основательно поработали.

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

Применительно к позаказному производству, процесс ”От заказа до оплаты” укрупнено может состоять из подпроцессов получения аванса, производства, отгрузки, расчетов:

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

Но бизнес не работает по принципу “раз-два-три”!

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

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

Определения:

• Последовательность и логика выполнения задач в рамках одного процесса называется оркестровкой (”process orchestration”).
• Логика асинхронного, координируемого при помощи сообщений выполнения нескольких процессов называется хореографией (”process choreography”).

Теорема:

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

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

Часто встречающиеся попытки ограничиться в подобных задачах оркестровкой являются ничем иным, как использованием анти-паттерна, который я называю “Оркестровка сквозного процесса”.