Про автоматизацию бизнес-процессов (БП) написано много. В литературе, да и в интернете, хорошо описаны преимущества автоматизации повседневных рутинных процессов посредством Business Process Management (BPM), а также Workflow Management Systems (WMS).

Цель этой статьи — пойти дальше и рассмотреть, что же конкретно подразумевает под собой слово "Автоматизация" и почему увеличение требований к моделям процессов непременно приводит к увеличению сложности самой системы, и как с этим бороться.

В начале статьи остановлюсь на теоретических основах классификации БП по степени их устойчивости к изменениям и затем коснусь технического аспекта моделирования БП.

В середине статьи попытаюсь объяснить, почему системы получаются сложными, на примере похожих по звучанию понятий "Сложность" и "сложный", но имеющих разные смысловые значения.

В конце статьи приведу конкретные примеры борьбы со Сложностью на примере моделирования адаптивных БП.

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

Рисунок 1: степени устойчивости БП к изменениям [источник Vos 1997, S. 40]

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

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

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

Рисунок 2: технические концепции [источник Aalst u. a. 2005, S. 158]

Во избежание путаницы приведу основную идею каждой концепции:

— EAI – системы, в основе которых лежит принцип шины. Система должна быть подключена только к шине для доступа к другим сервисам.

— SOA – это сервисы, которые имеют интерфейсы согласно стандарту OASIS. Это обеспечивает упрощённый способ общения между сервисами.

— Case Management oder Adaptive Case Management (ACM) — поддерживают непредсказуемые сценарии. Эти системы эффективны для не повторяющихся и уникальных бизнес-сценариев.

— Ad-hoc-Workflow – процессы, в модель которых встроена возможность изменения потока работ "на лету" (также в уже запущенной инстанции процесса).

— Groupware – ПО для поддержки взаимодействия между людьми, совместно работающими над решением общих задач.

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

С категориями и инструментарием более-менее разобрались, остаётся разобраться с внешними факторами; вроде как всё правильно сделали — шуруп закручиваем отвёрткой, а гайки ключом, но что-то всё равно "туго" идёт. Может, вкручиваем шуруп в бетон или отвёртка прокручивается.

Почему одни процессы лёгкие, а другие бывают сложными при моделирования и реализации?

Возможно, кто-то сразу ответит: "… потому что разные требования к процессам. При возрастании требований к функционалу процессов, возрастает и их сложность".

Для начала необходимо разделить два понятия "сложный" (англ. complicated; нем. kompliziert, Kompliziertheit ) и "Сложность" (англ. Complex; нем. komplex, Komplexitat). Очень часто эти два термина принимают за одно и тоже, но между ними есть существенная смысловая разница.

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

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

Понятие "Сложность" — это скорее состояние системы, когда при известных компонентах конечный результат не предсказуем.

Примером "Сложности" служит футбол или оркестр. На футболе, при всех известных параметрах игроков и тактики, исход игры предсказывать невозможно. Как и в оркестре — результат зависит также ещё и от многих внешних составляющих. Так, например, звучание оркестра не зависит напрямую от партитуры и умения музыкантов, сюда добавляются такие факторы, как акустика помещения, электрическое усиление звука, сама публика и даже визуальное восприятие.
?
Другими словами:

Когда система (дело, проект — не зависит от контекста) вызывает Сложность, то для её преодоления потребуются новые знания, которые нужно будет понять (переосмыслить, принять, изменить точку наблюдения, измениться самому).

Когда система (дело, проект — не зависит от контекста) сложная, то потребуется приложить усилия с уже имеющимися знаниями.

Из вышеизложенного следует интересная формулировка работы проект-менеджера:

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

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

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

Этот пункт значительно актуален, если срок жизни инстанции БП > периода релиза модели БП. Другими словами, у меня появляется возможность поддерживать эволюцию данного бизнес-процесса "на лету" — без перезапуска инстанции БП.

Примером для такой модели БП может служить процесс погашения кредита в банке. Зачастую срок погашения кредита составляет примерно от 10 до 30 лет, соответственно срок жизни запущенной инстанции БП исчисляется десятками лет. За этот период изменений просто не избежать, даже хорошо продуманный БП не сможет учесть всех внешних факторов на будущие года вперёд, а в этом случае — десятилетия.

Согласно рис. 2 воспользуюсь принципом Ad-Hoc Workflow. Этот принцип хорошо подходит для задач, когда начальная модель БП известна и последующие изменения применяются как к запущенным, так и ко всем последующим инстанциям БП.

Сформулирую основные правила эволюции предьявляемые к Ad-Hoc процессам:

• Инстанция БП всегда запускается только в последней версии, запустить устаревшею версию БП невозможно (этим самым препятствуя попадания процесса в dead lock)
• Возможность параллельного существования нескольких версий одного и того же БП
• Переход к новой версии возможно запретить, таким образом давая возможность инстанции закончить первоначальный воркфлоу

Теперь можно перейти к структурному примеру изменения модели БП. Два самых распространённых сценариев при изменении модели БП следующие:

1. добавления нового task в модель
2. удаление существующего task из модели

Добавление нового Task

Необходимо добавить таск 3 в модель БП.

Принцип встраивания нового таска в модель показан на следующей схеме. В этом случае, токены из версии 1 перемещаются в соответствующие таски версии 2. Во второй версии БП токены из таска 1 попадают в разветвление и дальше по стандартному сценарию исполнения БП. После таска 2 процесс оканчивается, как и в предыдущей версии БП.

Пунктирные линии показывают перемещение токенов между версиями БП:

Удаление существующего Task

Необходимо удалить таск 2 из модели БП. Удаление происходит в три шага, версия 2 — промежуточная, конечная версия — версия 3.

Шаг 1: токены перемещаются из версии 1 в версию 2. Во второй версии таск 2 для новых инстанций уже недоступен. Инстанции, запущенные из версии 1, и которые уже начали выполнения таска 2, закончат его выполнение.

Шаг 2: в версии 2 таск 2 постепенно "отмирает", так как инстанций в версии 1 больше не запускаются и поток токенов в таск 2 из версии 1 прекратится ( второе правило эволюции БП).

Шаг 3: после полного "отмирания" таска 2, добавляется версия 3 — уже окончательная, без таска 2, который с уверенностью уже не потребуется.

(Пунктирные линии показывают перемещение токенов между версиями БП).

В этой статье был рассмотрен переход от "Сложности" при изменениях в модели БП к сложной задаче моделирования адаптируемых БП "на лету".

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

Также может быть полезна статья «Все что вы хотели узнать о BPM, но боялись спросить» sshikov, где автор описывает технические проблемы при реализации изменений модели БП.

При наличии времени, постараюсь ответить на комментарии, дополнения, а также критику в адрес идеи статьи.

Спасибо за внимание!