Главное не результат, главное процесс

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

Анти-паттерн: “Оркестровка сквозного процесса”

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

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

Аксиома:

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

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

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

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

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

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

Пример диаграммы сквозного процесса в BPMN

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

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

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

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

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

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

Теорема:

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

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

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

22.12.08 | Статьи | , ,    

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

  1. AS 23.12.08 21:39
  2. Anatoly Belychook 23.12.08 22:36

    Alexander

    Please be less pedantic :) Or better ask BPMN standard body to be more precise :)

    Of course production goes after ordering - did I said the contrary here? The question is: whether an order fires production (in that case it may be implemented as a subprocess within the same pool) or production is triggered by some other event e.g. by a timer (then it’s another pool). My point is that novice BPM desingers tend to use former model but the latter is more realistic.

    Branches from a parallel gateway may go over other pools? I seriously doubt this. Not in BPMN. But you are right: parallel gateways do produce asynchronous threads.

    My favourite analogy to process choreography is threads programming in java.

  3. AS 24.12.08 13:40
  4. Anatoly Belychook 24.12.08 13:54

    Alexander

    Of course you diagrammed both choreography and orchestration. The words “branches may go” from your first post are misleading I’m afraid: most people would suppose you mean sequence flow. So it’s my turn to ask you be more accurate :)

  5. AS 26.12.08 12:50
  6. Anatoly Belychook 26.12.08 13:13

    Sorry Alexander, don’t understand you. I believe you get choreography as soon as you draw more than one pool and messages accross them. Please share your interpretation.

  7. AS 30.12.08 02:27
  8. Anatoly Belychook 30.12.08 13:51

    Alexander

    I follow Bruce Silver’s interpretation:
    * orchestration = single pool, sequence flow
    * choreography = communication between multiple pools, message flow

    BPMN 1.1 spec define choreography as “an ordered sequence of B2B message exchanges”. It’s close to your interpretation because B2B situation implies lesser predictability.

    Two interpretations diverge on multi-pool processes with pools representing different process instances, not different business entities. And this is exactly the subject of the original post. Under your interpretation, I should have call it “Single pool end-to-end process”. Not a bad idea may be, thank you for the input.

  9. Сергей 10.09.09 12:43

    Продажи - это не сквозной процесс, как мне кажется, а набор фрагментов различных процессов

  10. Anatoly Belychook 14.09.09 10:47

    Сергей, загляните вот сюда: http://mainthing.ru/ru/item/150/

  11. ISA 19.05.11 16:08

    Правильно ли я понимаю, что с выходом BPMN 2.0 в данной статье оркестровку надо заменить на межпроцессное взаимодействие (collaboration)?

  12. ISA 19.05.11 16:14

    Сделал опечатку, имел в виду:
    “… хореографию надо заменить на межпроцессное взаимодействие (collaboration)?”

  13. Anatoly Belychook 19.05.11 17:58

    Да, правильно.

А что вы думаете?

Captcha

Copyright © 2008-2016 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии