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

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

Аксиома:

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

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

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

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

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

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

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

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

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

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

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

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

Теорема:

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

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

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

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

Вообще-то я всегда считал, что BPM - это для тех, у кого “ERP уже есть, а счастья еще нет”. Но выяснилось, что во-первых, компаний, достигших нирваны полной автоматизации, как-то не видно. А во-вторых, продвинутые компании не желают автоматизировать то, что у них еще не автоматизировано, традиционными методами, а хотят сразу заложить в свою недостающую функциональность процессную составляющую. Я был бы последним, кто стал бы их в этом упрекать, но в итоге мы попадаем в проекты, в которых “в нагрузку” к процессной составляющей идет приличный кусок разработки более-менее традиционных корпоративных приложений. И большую часть времени наши разработчики и аналитики тратят не на бизнес-процессы, а на эти приложения! В принципе ничего страшного - мы этим занимаемся больше 15 лет - просто скучноватое это занятие по сравнению с работой над бизнес-процессами.

И на форуме sql.ru помнится были высказывания в таком духе, что мол BPMS - не панацея, потому что “все равно до фига руками делать”.

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

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

Вывод: не столько с BPMS хорошо, сколько без него плохо!