Плохой, хороший, злой BPM

BPM расшифровывается как «Business Process Management» или «Управление бизнес-процессами». Как же много страхов, кошмаров и разнообразных мук заключено в этих трех буквах. Cейчас расскажу.

Для непричастных

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

С учетом графика отпусков и замещающих лиц. А как вы думали?

Также, этот процесс включает автоматические проверки данных сделки по внешним источникам, например — по базам проблемных контрагентов.

Часть внешних источников отдает результат проверки сразу, часть — с ощутимыми задержками: могут пройти часы или даже дни.

Вот чтобы автоматизировать такие процессы и был придуман BPM.

История

Да, это снова про «древнее чудище» из 80х:

Traditionally, BPMS has focused on delivering value by reducing costs and increasing efficiency. In its most humble beginnings, FileNet developed a digital workflow management system in the 1980’s designed to route scanned documents through a predefined process. This early system — later acquired by IBM — is often cited as the precursor to modern BPM Software, according to Frank J. Wyatt, Business Process Management and Workflow Automation and Project Management Tools writer.

Самый расцвет таких систем пришелся на конец 90х и начало 2000х.

В наше замечательное время, решение с BPM-движком — достаточно редкий зверь, который также как и серверы приложений, уступил свое место под солнцем.

«Уступил место» — не значит что все разработчики и решения BPM дружно накрылись простыней и поползли в сторону кладбища, нет.

Рассказывая про любую разработку надо подразумевать перспективу — будущее.

А у BPM как концепции его особо нет:

Новые проекты на BPM уже не создаются, а существующие решения сфокусированы на исправлении ошибок и поддержке.

Ныне прямой потомок идей BPM это nocode и lowcode платформы.

К сожалению в большинстве случаев никакими стандартами в таких решениях и не пахнет. Их ваяют кто во что горазд.

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

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

Классические примеры открытых решений это: Alfresco, JBPM, Pentaho. Хотя конечно свои BPM решения есть и у всех крупных вендоров: IBM, Oracle, Microsoft.

Работало оно чаще всего на каком-либо сервере приложений, который как концепция уже тоже ушел в прошлое.

Вот обзорное видео от проекта Camunda:

Как это выглядит в жизни:

Или вот так:

Среда моделирования бизнес-процессов:

Нахуа месье гармонь

Самая главная причина существования BPM — хоть какая-то формализация того бардака, который гордо зовется «бизнес-процессами» компании.

Именно для этого и создавали все эти BPM, BPMN, BPEL и среды выполнения, со всей их глубокой теоретической базой, книгами и сертификатами.

Это в теории.

На практике же все как обычно:

Не все можно формализовать и описать в виде бизнес-процесса, а то что можно — проще пустить мимо сложной системы.

Ну вы поняли.

Еще есть печальная реальность в виде ускорения всего вообще с времен святых 90х и ламповых 2000х — реалий бизнеса, жизни, всего:

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

Нет это не вы постарели, это информационные потоки ускорились.

Раз так в сто.

Вообщем ниже опишу некоторые из проблем, с которыми вы обязательно столкнетесь, если все же решите использовать BPM в 2023м году.

Проблема первая: сложность

Чтобы вы понимали — сие пишет человек с 20+ стажа в ИТ и не вылезающий из BSD годами.

Так что дело точно не в прокладке между клавиатурой и монитором.

Вообщем первое и самое важное — BPM это сложно.

Для вас, не для меня.

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

Причем в худшем смысле этого слова:

Чтобы начать пользоваться BPM-решением, будучи просто участником — тем самым нач.отдела с кнопкой согласования, придется изучать что такое «бизнес-процесс», «шаг процесса», «статус процесса» и так далее.

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

Это сильно отличается от подхода «немедленное действие»:

отправить матерное письмо, позвонить, открыть таблицу в Экселе.

К которой руководство давно привыкло, любит и умеет.

Проблема вторая: не натянуть сову на глобус

Далеко не все бизнес-процессы формализуемы — могут быть описаны в виде какой-то последовательности действий.

Но даже с формализованными и стабильными, на практике происходит отрыв от реальности:

Запустили процесс согласования сделки, через пять минут клиент сделку отменил, еще через десять — ваши менеджеры его уговорили и сделку нужно все же запускать в работу. А еще через полчаса оказалось что товара-то нет и сделку просто не получится завершить.

Что произойдет с BPM-процессом?

— Ручное закрытие, задним числом.

Надо понимать что BPM это автоматизированная бюрократия и одновременно учетная система, в которую постоянно нужно что-то вводить.

Поэтому «закрытие задним числом» будет применяться всегда, когда кто-то что ввести не успел.

Теперь представим стартап и рост клиентской базы в 200% каждый месяц. C частыми отказами от использования, которые тоже идут волнами.

В случае стартапа и взрывного роста клиентов — внедрение BPM будет фатальной ошибкой.

Вы с вашим BPM пойдете нах#й, чтобы не мешали людям работать.

Проблема третья: оно медленное и не масштабируется

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

Поэтому масштабировать BPM-решение горизонтально не получится, оно всегда централизованное.

Что вообщем-то и показывают всевозможные руководства по кластеризации BPM:

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

Еще одной важной особенностью BPM, вытекающей из самой концепции конечного автомата является то что:

BPM плохо подходит для автоматизации фоновых процессов, без шагов с участием человека (Human Task).

Почтовых рассылок, генерации отчетов, копирования данных — вот этого всего.

Потому что «Human Task» работает своеобразным мьютексом для процесса выполнения.

А его отсутствие — прямой аналог бесконечного цикла:

while(true) {}

Пример из jBPM:

При фиксации шага, в СУБД записывается все состояние процесса, включая несколько больших BLOB полей. Это может быть несколько мегабайт данных, единовременно, в одной транзакции, записываемых в несколько связанных таблиц.

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

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

Сотня таких процессов, запущенных одновременно и ваша база становится в позу любви №6.

Дважды я попадал на ситуацию, когда большая компания пыталась перевести на BPM какие-то чудовищные потоки данных:

речь шла о нескольких десятках тысяч BPM-процессов в день.

Каких именно: новых, старых, больших и маленьких, перезапускаемых повторно и останавливаемых вручную — при таких цифрах уже роли не играет.

Очевидно что покупать мейнфрейм — как максимум вертикального масштабирования, под BPM-сервер они были не готовы.

Ведь купить оборудование за $млн долларов это вам не консультантов слушать, это ответственный шаг. Могут дать п#зды акционеры.

Нынешнее состояние

На сегодняшний день, уже нет никакого смысла фокусироваться на BPM-решениях:

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

Плохо вписывается жестко централизованное решение в нынешние «облачные» реалии, что поделать.

Куда проще стало написать решение под реалии конкретной компании с нуля, зашив всю процессную логику внутрь, чем пытаться в очередной раз нанянуть сову на глобус — загоняя внутренний процесс компании в рамки BPMN и конкретной платформы.

В плане поддержки и дальнейшего сопровожения — уж точно.

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

Пишите, помогу.