Формализация рабочих потоков перестала быть отдельной задачей одного подразделения: в любой организации есть процессы, которые проходят через несколько ролей и систем, и именно на стыках чаще всего теряются сроки и ответственность. На портале cio-navigator.ru вышел разбор Workflow: кто, что и когда должен сделать — в нём последовательно объясняется, как устроен поток работ, чем он отличается от BPM и какими классами систем его автоматизируют.
Как обычно подходят к описанию потока работ
Публикация начинается с простого тезиса: Workflow — это заранее определённый маршрут, по которому движется задача или документ внутри компании. Сотрудник видит только свой этап, нажимает «Согласовать» или «Выполнено», а система сама решает, кому передать работу дальше.
Отправная точка внедрения одна и та же почти всегда — процесс нужно прорисовать. В обзоре это разложено по шагам: процесс превращается в алгоритм, крупные этапы дробятся на подпроцессы, для каждого этапа назначаются исполнитель, срок и, при необходимости, согласующий. Только после этого схему имеет смысл переносить в информационную систему.
Отдельно объясняется разница между моделью и экземпляром: схема «Обработка входящего письма» — это модель, а каждое новое письмо запускает собственный экземпляр процесса. Из этого вытекает и тема версионности: при изменении регламента появляется новая версия, а уже запущенные экземпляры должны доигрываться по старым правилам. В крупных организациях перевод новых версий в продуктив связывают с практиками CI/CD.
На что опираться при сборе требований
Команде, которая готовит внедрение, разбор помогает сформулировать список проверочных вопросов. Ориентиры, которые прямо следуют из публикации:
- сколько подразделений участвует в процессе и как часто он повторяется — от этого зависит, нужен ли вообще формализованный поток работ;
- поддерживает ли система моделирование в нотации BPMN 2.0 и визуальную сборку маршрута;
- ведётся ли учёт статусов процесса — создан, выполняется, ожидает согласования, приостановлен, завершён, отклонён;
- как реализовано управление версиями процессов и их состояниями: черновик, тестирование, согласование, продуктивная и устаревшая версия;
- есть ли роли, права доступа, справочники, контроль сроков и журналы действий;
- насколько платформа умеет интегрироваться с другими корпоративными системами и запускать автоматические операции без участия человека.
Здесь же снимается частая путаница в терминах. Workflow — это конкретный исполняемый поток работ, а BPM — более широкая дисциплина управления процессами, включающая моделирование, исполнение, мониторинг, анализ и совершенствование. Поток работ логично рассматривать как часть BPM, а не как его синоним.
Как устроен обзор и что из него можно взять
Текст выстроен от понятий к инструментам. Сначала — перевод термина, суть, концепция и история развития подхода: от стандартизации операций в промышленном производстве до появления Workflow Management Coalition в 1993 году и превращения потока работ в базовый механизм BPM-, ECM-, CRM-, ITSM- и low-code-систем.
Затем разбираются области применения: маршрутизация документов, где задействованы СЭД, ECM и CSP-платформы; обработка заявок и обращений с опорой на Service Desk, ITSM и ESM; движение лида и сделки по воронке в CRM.
Каталожная часть разделена на три группы, и это удобно при первичном отборе:
- инструменты для моделирования и лёгкой автоматизации маршрутов — bpmn.io, Schemix, Forward BPM;
- полноценные BPM-платформы — ELMA365, Comindware, BPMSoft, Digital Q.BPM;
- западные решения, которым ищут замену, — Camunda, IBM Business Automation Workflow, Microsoft Power Automate, Appian, Nintex.
Ценно, что для зарубежных продуктов указан характер архитектуры: процессный движок для разработчиков, low-code-интеграция приложений или комплексная корпоративная платформа. Подбирать аналог логично по этому признаку, а не по формальному совпадению названия класса.
Что представляет собой портал
Издание cio-navigator.ru публикует разборы корпоративных ИТ-классов и обзоры отечественных платформ. Материалы связаны между собой перекрёстными ссылками на смежные темы — BPM, бизнес-процессы, нотации моделирования, low-code, — поэтому от общего понятия можно быстро перейти к более узкому.
Итоги и следующий шаг
Основной вывод разбора прагматичен: Workflow снимает зависимость процесса от памяти и присутствия конкретных сотрудников, но работает это только там, где маршрут заранее описан. Инструмент выбирается уже под масштаб задачи — для простого согласования полноценная BPM-платформа избыточна, для сквозных процессов всей организации отдельного конструктора маршрутов не хватит.
Разумный порядок действий для команды: описать два-три самых болезненных повторяющихся процесса, определить по ним ответственных и сроки, а затем сопоставить требования с классами решений из публикации.
