Основной вопрос процессного анализа средствами BPMN: чем мы собираемся заниматься - дирижировать или реагировать?

• Дирижировать – это значит обходиться только оркестровкой, т.е. одним пулом BPMN.
• Реагировать – это значит предусматривать события, инициируемые внешними сущностями, например контрагентом, государственным органом, внутренней службой с собственным ритмом или корпоративной системой.

Примеры

1. Ожидание оплаты заказчиком

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

Рис. 1.1. Низкая интенсивность – дирижируем

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

Если по-честному, получение аванса - это не задача, а событие. Мы узнаем о том, что счет оплачен, получив банковскую выписку. Переходим от дирижирования к реагированию:

Рис. 1.2. Высокая интенсивность – реагируем

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

2. Выбор поставщика

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

Рис. 2.1. Низкая интенсивность – дирижируем

Три экземпляра задачи “Получить предложение” будут висеть у исполнителя (скорее всего, у одного и того же) в течение пяти рабочих дней. Не беда.

Сценарий 2: большая организация, в которой одновременно проводится до 10 тендеров, до 10 поставщиков в каждом, а срок ответа на запрос - до 30 дней. Если следовать схеме на рис. 2.1, то 100 экземпляров задачи “Получить предложение” будут висеть в очереди у исполнителя (одного или нескольких) до 30 дней. Выполнить эту задачу исполнитель не может, так как от него ничего не зависит - когда поставщик пришлет документы, тогда и пришлет.

Переходим от дирижирования к реагированию - трактуем получение коммерческого предложения от поставщика не как задачу, а как событие:

Рис. 2.2. Высокая интенсивность – реагируем

Эта же пара паттернов и такой же выбор между дирижированием и реагированием возникают при моделировании процесса “Прием на работу” - конкурс кандидатов вместо конкурса поставщиков.

3. Заключение договора

Теперь взглянем на процесс закупки со стороны поставщика.

Сценарий 1: мы получили запрос коммерческого предложения от потенциального покупателя. При этом известно, что покупатель проводит тендер по четко определенной процедуре; в частности, в ней прописан срок принятия решения покупателем. Дирижируем:

Рис. 3.1. Тендер с фиксированным сроком – дирижируем

Сценарий 2 - “фабрика коммерческих предложений”: только 10% выставленных коммерческих предложений приводят к заказу, промежуток времени от выставления коммерческого предложения до заказа может измеряться месяцами. Если следовать схеме на рис. 3.1, то мы не сможем завершить процесс никогда, так как всегда будет оставаться вероятность того, что клиент все-таки надумает. И если мы завершим процесс даже через полгода, по закону подлости на следующий день клиент принесет заказ.

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

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

Рис. 3.2. “Фабрика коммерческих предложений” – реагируем

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

4. Выполнение заказа

Сценарий 1: мастерская по ремонту выполняет заказ клиента. Дирижируем:

Рис. 4.1. Приоритет качества – дирижируем

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

Рис. 4.2. Приоритет эффективности – реагируем

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

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

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

Само собой разумеется, для более-менее сложного процесса решение дирижировать или реагировать придется принимать не один, а много раз – для каждого фрагмента сквозного процесса. Так, задачу “Получить оплату” на рис. 4.1, 4.2, в свою очередь, можно реализовать через дирижирование или реагирование - рис. 1.1, 1.2.

5. Процессная интеграция корпоративных систем

Сценарий 1: сотрудник представил отчет о затратах, финансовый отдел его утвердил, отправили информацию в ERP. Дирижируем:

Рис. 5.1. Сбор данных в BPMS, хранение в ERP – дирижируем

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

Рис. 5.2. Функции за корпоративными системами, контроль сквозного процесса за BPMS – реагируем

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

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

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

Выводы

1. Дирижированием можно обойтись там, где:

• Никто не мешает «спокойно работать» – нет внешних сущностей. Другими словами, если речь идет о вспомогательном процессе, не взаимодействующем с внешним заказчиком.
• Качество процесса более важно, чем эффективность использования ресурсов.
• Интенсивность процесса мала – одновременно исполняется несколько экземпляров процесса, а не десятки, сотни или тысячи.

2. Если вы научились только дирижировать или если вендор/консультант продемонстрировали вам только умение дирижировать на вспомогательных процессах типа «Заявление на отпуск» или «Отчет о затратах», то вы узнали меньше половины того, что надо знать о процессном анализе с помощью BPMN. В этом случае вы рискуете столкнуться с неприятными сюрпризами в тот момент, когда перейдете от проекта PoC (Proof of Concept) к реальным задачам бизнеса, т.е. к основным бизнес-процессам. Впрочем об этом я уже писал.