Различие между BPM и Workflow: не только технологии

Оригинал блога: mainthing.ru/ru/item/204

На блоге Gartner появилась заметка Janelle Hill «Do You Understand the Difference Between Workflow and BPM?». Как замечено в комментариях, это хороший ответ тем, кто считает, что «BPM - это Workflow на стероидах».

По мнению Gartner, идеальная BPMS реализует 10 технологий, из которых Workflow - всего лишь одна:

1. Процессный движок (Process Execution and State Management Engine) - компонента, реализующая Workflow.

2. Среда разработки, основанная на графических моделях (Model-Driven Development Environment). Но в workflow-системах тоже обычно есть графические средства моделирования. Менее мощные (обычно только оркестровка без хореографии), не следующие стандартам (BPMN), но есть. Получается не 1/10, а 2/10.

3. Управление документами и контентом (Document and Content Management). Спорно. На мой взгляд, есть структурированные данные, есть неструктурированный контент и есть процессы, и для управления ими придуманы, соответственно, DBMS, ECM и BPMS. Без необходимости границы лучше соблюдать, ничего не следует  делать «заодно» - ни управлять контентом в BPMS, ни управлять процессами в ECM. Мы же не включаем в BPMS управление данными, не дублируем DBMS - почему с контентом должно быть по-другому? 2/9.

4. Средства совместной работы пользователей и групп (User and Group Collaboration). Да, конечно, но рассматривать это как часть BPMS? А что, совместной работы вне процессов не бывает? Конечно, бывает, например, в проектах. Получается, для процессов свои средства совместной работы, а для проектов - свои? Абсурд. 2/8.

5. Средства интеграции (System Connectivity). Действительно, в BPMS работа, выполняемая людьми, работа с документами и действия, выполняемые автоматизированными системами, трактуются единообразно, без перекоса в сторону первых (что характерно для систем human workflow) или вторых (системы docflow). Кстати, пункты 3 и 4 я бы поместил сюда - в виде средств интеграции с системами управления контентом и средствами совместной работы.

6. Бизнес-события, бизнес-аналитика и мониторинг (Business Events, BI and BAM). Строго говоря, к BPMS относится только последнее, а первые два могут использоваться независимо.

7. Имитационное моделирование и оптимизация (Inline  and Offline Simulation and Optimization). Похоже, только Gartner знает, что они имеют в виду под «inline and offline», но по существу возражений нет.

8. Машина бизнес-правил (Business Rules Engine). В теории она может использоваться как единое хранилище глобальных переменных любой (лучше каждой) корпоративной системой. Но на практике в основном используется BPMS.

9. Средства управления и системное администрирование (System Management and Administration). В том или ином виде это есть в любой системе: 3/8.

10. Каталог-репозиторий процессных компонент (Process Component Registry/Repository). С одной стороны, в Workflow-системе тоже можно найти каталог процессов в том или ином виде. С другой стороны, репозиторий процессов в рамках BPMS, в отрыве от репозитория сервисов SOA, тоже не лучшая идея. 4/8.

Итоговый счет у меня получился не столь разгромный - 4:8, а не 1:10. Но сама идея подсчета очков порочна: на чашу весов BPM есть, что положить кроме технологий. Прежде чем сравнивать BPMS с Workflow, надо сказать, что BPM != BPMS. BPM - это:

1.  Методология: иерархия целей организации, цепочка создания ценностей, сквозные бизнес-процессы, выявление процессов, цикл непрерывного усовершенствования.

2.  Реализация: программа, понимаемая как серия проектов; гибкая разработка (agile).

3.  Технология (BPMS).

Если нет компетенции в методологии или реализации, проект BPM обречен даже с самой лучшей BPMS.

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

●  без средств быстрого прототипирования (технология) не будет эффективного выявления процессов (методология)

●  без гибкой разработки (реализация) не будет непрерывного усовершенствования (методология)

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

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

●  Непрерывное улучшение? Ерунда, надо тщательнее проектировать, а главное - тщательнее составлять требования!

●  Схема процесса? Настоящая программа - это код, а не «стрелки-квадратики».

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

●  Гибкая разработка? Наши пользователи не согласятся работать с системой, в которой нет всего что им нужно.

И поскольку Workflow - это только технология, то с ним им гораздо комфортнее, чем с непонятным, разрекламированным и переусложненным (с их точки зрения) BPM.

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

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

Возвращаясь к технологиям, я бы не сказал, что BPMS кладет Workflow на лопатки. Но это ему и не нужно, потому что тут есть еще один важный аспект: BPMS - это следующее поколение технологий. XML и Интернет, тонкий клиент, современные стандартные платформы (J2EE или .NET), стандартные нотации (BPMN, BPEL) вместо проприетарных. В быстро меняющемся мире ИТ даже относительно небольшое технологическое отставание фатально: если основная масса разработчиков начинает воспринимать какое-то направление как устаревшее, то оно достаточно быстро маргинализируется просто потому, что никто добровольно с ним работать не хочет. Поэтому нравятся вам Workflow-системы или нет - останутся жить только те из них, которые смогут влиться в мейнстрим: перейти на современную платформу, сменить нотацию, добавить недостающие функции из списка Gartner, т.е. превратиться в BPMS.