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

• Инструментарий Enterprise Architecture (EA) предназначен для моделирования следующих аспектов корпоративной архитектуры:
  1. бизнес-архитектура - бизнес-цели, организационная структура, функции, процессы, роли и т.д.
  2. архитектура приложений - корпоративные системы и их интерфейсы
  3. архитектура данных - логическая и физическая
  4. технологическая инфраструктура - программно-аппаратное обеспечение и сети
• Инструментарий Business Process Analysis (BPA) в части моделирования является подмножеством EA, покрывая полностью или частично бизнес-архитектуру. Но, помимо моделирования, может содержать специализированные средства, например, имитационное моделирование бизнес-процессов или статистический анализ результатов исполнения.
• Business Process Management Suite (BPMS) в обязательном порядке включает моделирование бизнес-процессов, их исполнение (process engine, процессный “движок”) и мониторинг/анализ. Опционально может включать имитационное моделирование, движок бизнес-правил и многое другое.
• Некоторые вендоры используют для своих продуктов определение “BPM Software”. Обычно это означает, что система не дотягивает до BPMS - например, в ней нет исполняемого движка - но маркетинг хочет видеть в названии BPM.

Апологеты BPMS (я в том числе) верят в силу исполняемых бизнес-процессов, в принцип “what you model is what you run”. Соответственно, наличие процессного движка для них - необходимость, и EA инструментарием они обойтись не могут.

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

Как быть? Может это временные трудности, и через некоторое время либо BPMS дорастут до EA, либо EA включат функциональность BPMS?

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

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

1. изобразили BPMN-диаграмму средствами EA
2. дальше возможны два варианта:
   • если BPMS непосредственно исполняет BPMN, выполнили экспорт-импорт через XPDL
   • если BPMS поддерживает BPEL, выполнили трансляцию BPMN->BPEL

Например, нарисовали в ARIS - экспортировали в WebMethods. Или нарисовали в Casewise - транслировали в Oracle BPEL.

Схема простая, логичная, но… плохо работающая. Точнее, оба варианта работают только пока мы рассматриваем один проход: нарисовали - передали - исполнили. Но вспомним, что BPM - это ведь не однократная автоматизация процесса, а управление изменчивыми бизнес-процессами.

Что это означает на практике? После того, как схему процесса загрузили в BPMS, разработчик должен внести в нее правки и уточнения, необходимые для исполнения процесса движком. Но исходная схема процесса в EA тоже не остается неизменной - аналитик продолжает ее совершенствовать, ведь за это, собственно, мы и боролись! (Подробно эта проблематика рассмотрена в серии заметок на блоге Keith Swenson, начинающейся с “Model Strategy: Preserving vs. Transforming“. Русский перевод на bpms.ru.)

Таким образом, надо либо уметь передавать подробности физической реализации процесса в BPMS назад в EA и находить для них место в репозитарии (т.н. проблема “round-trip”), либо уметь объединять изменения, выполняемые в одной и в другой схемах (по образцу branch merging в системах контроля версий). Теоретически задача может быть и разрешима, но по факту за много лет решить ее не удалось. Будем ждать?

Предлагаю принять за аксиому, что:

1. водораздел между EA и BPMS есть и останется в обозримом будущем
2. удовлетворительной автоматической передачи артефактов между ними нет и в обозримом будущем не будет

Возникает вопрос: где следует проводить этот водораздел? Проводить его можно по-разному, так как инструментарии частично перекрывают друг друга. Очевидно, лучше там, где объем передаваемой информации будет минимальным.

Предложение: проводить его на уровне процесса -

• цепочка создания ценностей (value chain) и межпроцессное взаимодействие через события и/или данные моделируются средствами EA
• внутренняя логика процесса моделируется средствами BPMS

Тогда передавать из EA в BPMS придется только номенклатуру и интерфейсы процессов, а для этого автоматический экспорт-импорт не нужен, можно обойтись экспортом-импортом “через принтер”.

Бизнес-аналитик должен провести для себя красную черту: не использовать EA для моделирования бизнес-процесса при наличии BPMS.

Впрочем, для средств моделирования BPMN в EA тоже есть применение. Современные BPMS нацелены на моделирование внутренней логики процессов (оркестровка) и плохо подходят для моделирования межпроцессного взаимодействия (процессная хореография). Но одной оркестровкой можно решать только задачи уровня “автоматизации канцелярии”; как только вы поднимаетесь на уровень сквозных бизнес-процессов - т.е. процессов, за которыми стоят реальные деньги - вам не обойтись без хореографии. (См. на эту тему анти-паттерн “Оркестровка сквозного процесса”.)

Моделировать межпроцессное взаимодействие предлагается средствами EA, используя для этого т.н. “black box BPMN diagram” - технику моделирования, в которой каждый процесс отображается как пустой BPMN pool. Взаимодействие через сообщения моделируется при помощи message flow, взаимодействие через данные - при помощи association.

BPMN-диаграмма межпроцессного взаимодействия, создаваемая средствами EA, может выглядеть так:

Для каждого процесса на диаграмме вверху средствами BPMS создается BPMN-диаграмма, раскрывающая внутреннюю логику процесса:

Пример:

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этот контент доступен на языках: English.

Как в различных реализациях BPMN выглядит шаг процесса, выполняемый людьми? Чисто для иллюстрации возьмем процесс “От обращения до заказа” (Inquiry to Order) с шагами “Сделай это” (Do This, системный), “Согласуй договор” (Negotiate Contract, человеческий), “Сделай то” (Do That, системный) и смоделируем при помощи нескольких популярных инструментов.

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

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

В 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”).

Теорема:

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

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

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