Автоматизация бизнес процессов: как описать процесс до выбора системы

Автоматизация бизнес процессов начинается не с выбора платформы, а с описания маршрута: где процесс стартует, из каких шагов состоит, кто отвечает за каждый шаг, по какому сигналу он запускается, где принимается решение и за какое время шаг обязан завершиться. Пока описания нет, система автоматизирует не процесс, а догадку о нём. Ниже разбор того, как разложить рабочий процесс на объект автоматизации: карточка, схема в нотации BPMN 2.0, роли и дорожки, триггеры, таблицы решений, нормативы времени.

Границы процесса: где он начинается и чем заканчивается

Первое, что фиксируется, это пара «стартовое событие и результат». Без неё спор о том, входит ли выставление счёта в процесс продажи, будет бесконечным. Формальная опора есть: ГОСТ Р ИСО 9001-2015 в пункте 4.4 требует для каждого процесса определить требуемые входы и ожидаемые выходы, последовательность и взаимодействие процессов, критерии и методы (включая мониторинг, измерения и показатели результатов деятельности), ресурсы, распределение обязанностей, ответственности и полномочий, риски и возможности, порядок оценки и улучшения. Восемь пунктов от a) до h) работают как готовый список полей описания.

Практическая формулировка: процесс «Обработка входящей заявки» начинается событием «заявка зарегистрирована в системе» и заканчивается одним из двух результатов, «оплата поступила» или «отказ зафиксирован с причиной». Всё, что до регистрации, относится к маркетинговому процессу, всё, что после оплаты, к исполнению обязательств. У процесса один владелец и один клиент, внутренний или внешний.

Шаг 1. Автоматизация бизнес процессов начинается с карточки процесса

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

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

Частота и время цикла нужны не для отчёта, а как основа приоритета: шаг, который выполняется дважды в месяц, редко окупает настройку.

Как снять процесс «как есть»: три источника данных

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

Третий источник формализован в классе инструментов process mining. Российский пример: Proceset разработки ООО «Инфомаксимум» (Саранск) восстанавливает фактический маршрут процесса по журналам событий информационных систем, а модуль task mining оценивает трудозатраты по действиям сотрудников за компьютером. Вендор указывает на свидетельство о государственной регистрации программы для ЭВМ Proceset, номер реестровой записи 5642 от 26.07.2019. Ценность источника в том, что он показывает фактический маршрут, а не задуманный: сколько раз заявка возвращалась на доработку, сколько ветвей существует, где скапливается очередь.

Если инструмента нет, минимальная замена это выгрузка из CRM за квартал с отметками времени по каждому статусу: медиана времени между статусами покажет узкое место.

Нотация BPMN 2.0: минимальный набор элементов

BPMN 2.0 это графическая нотация моделирования бизнес-процессов консорциума OMG. Спецификация версии 2.0 опубликована как документ formal/11-01-03 в декабре 2010 года, действующая редакция 2.0.2 датирована январём 2014 года. У нотации есть международный статус: стандарт ISO/IEC 19510:2013 идентичен OMG BPMN 2.0.1. Это означает, что схема, нарисованная по правилам, читается разработчиком, аналитиком и внешним подрядчиком одинаково, а файл BPMN 2.0 XML переносится между редакторами.

Полный словарь нотации избыточен для большинства задач, и это подтверждено исследованием. Michael zur Muehlen и Jan Recker в работе «How Much Language Is Enough?» разобрали выборку реальных BPMN-диаграмм и получили результат: регулярно используется менее 20% словаря языка, а средняя модель содержит около девяти разных конструкций.

Отсюда рабочий минимум: стартовое событие, задача, эксклюзивный шлюз (развилка «или-или»), поток управления, конечное событие, дорожка. Шести элементов хватает, чтобы маршрут стал однозначным. Три правила экономят время на переделках: у каждой ветки шлюза именованное условие, у задачи глагол плюс объект («проверить комплектность документов»), у процесса одно стартовое событие и столько конечных, сколько бывает исходов.

Дорожки, роли и триггеры: кто вступает и по какому сигналу

В BPMN пул обозначает участника процесса целиком (компания, контрагент, внешний сервис), а дорожки внутри пула обозначают роли: отдел, должность, робота. Задача, положенная на дорожку, автоматически получает исполнителя. Правило простое: у задачи ровно один исполнитель. Если на схеме появляется задача «согласовать» с двумя дорожками сразу, это не одна задача, а две.

Остальные роли разводятся матрицей RACI: кто выполняет, кто отвечает за результат, с кем консультируются, кого информируют. На схему попадает только первая, три другие уходят в карточку процесса, иначе диаграмма превращается в оргструктуру.

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

Точки решения: правила выносятся в таблицу, а не в схему

Развилка отвечает на вопрос «куда пойдёт поток», но не «по какому правилу». Когда в правиле три и более условий, схема становится нечитаемой. Для этого случая у OMG есть отдельная нотация DMN (Decision Model and Notation): графическое представление плюс язык выражений, предназначена для таблиц решений рядом с процессом. Действующая версия DMN 1.5 получила статус formal в августе 2024 года.

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

Отдельно фиксируется исключение: что делает процесс, если данных для решения нет. Ветка «данных недостаточно, задача уходит человеку» обязана быть на схеме, иначе она проявится в проде в виде зависшей заявки.

SLA: откуда берётся норматив времени на шаг

SLA это не «побыстрее». В ГОСТ Р ИСО/МЭК 20000-1-2021 соглашение об уровне сервисов определено как документированное соглашение между организацией и потребителем, определяющее сервисы и их согласованное функционирование. То есть норматив это цифра, о которой договорились и которую можно проверить.

Источников у цифры три. Первый это закон, и он не обсуждается. Например, статья 22 Закона РФ от 07.02.1992 № 2300-1 «О защите прав потребителей» даёт продавцу десять дней со дня предъявления требования на возврат уплаченной суммы, соразмерное уменьшение цены, возмещение расходов на исправление недостатков и возмещение убытков. Значит, шаг «рассмотреть претензию» не может иметь внутренний норматив длиннее этого срока, а с учётом времени на доставку решения он должен быть заметно короче. Второй источник это договор с клиентом или подрядчиком. Третий это факт из журнала: берётся медиана и 90-й процентиль фактического времени шага за квартал, и норматив ставится между ними, иначе он будет нарушаться с первого дня.

На схеме норматив выглядит как граничный таймер на задаче с веткой эскалации: не уложились, задача уходит руководителю. Без этой ветки SLA остаётся строчкой в документе.

Критерий готовности шага к автоматизации

Не каждый описанный шаг стоит отдавать машине. Шаг готов, когда сходятся шесть условий:

1. правило шага формулируется в виде «если, то», без оговорки «по ситуации»;
2. вход машиночитаемый: поле в системе, строка в таблице, файл фиксированного формата, а не устная договорённость;
3. у системы-источника есть способ отдать данные: API, вебхук, регулярная выгрузка;
4. перечислены исключения и для каждого назван маршрут (в том числе маршрут «человеку»);
5. результат шага измерим: статус изменился, документ создан, запись обновилась;
6. назван ответственный за ошибку робота, то есть человек, который получит сигнал и разберёт зависшую задачу.

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

Автоматизация информационного бизнеса: как описывается маршрут онлайн-школы

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

Шаг «рекламное касание» обязан содержать подшаг, продиктованный законом. Статья 18.1 Федерального закона от 13.03.2006 № 38-ФЗ «О рекламе» действует с 1 сентября 2022 года: реклама в интернете содержит пометку «реклама» и указание на рекламодателя или сайт с информацией о нём, а распространение допускается при условии присвоения оператором рекламных данных идентификатора рекламы, уникального цифрового обозначения для прослеживаемости. На схеме это отдельная задача «получить идентификатор до публикации», а не примечание мелким шрифтом.

Второе уязвимое место это стык «оплата поступила» и «доступ выдан». Здесь ставится SLA в минутах и граничный таймер: подтверждение платежа не пришло за оговорённое время, задача уходит человеку, а клиент получает сообщение, что заявка в работе. Третье это возвраты: ветка отмены с указанием, какие данные обнуляются и кто подтверждает решение.

Инструменты моделирования: чем рисовать схему

Условия по тарифам приведены по официальным страницам вендоров на 22 августа 2026 года.

Инструмент	Что даёт	Условия
bpmn-js и demo.bpmn.io	Редактор BPMN 2.0 в браузере, чтение и запись BPMN 2.0 XML	Бесплатно по лицензии bpmn.io, но водяной знак со ссылкой на bpmn.io обязан оставаться полностью видимым; лицензия распространяется на bpmn-js, dmn-js, form-js и cmmn-js
Camunda Desktop Modeler	Локальное проектирование BPMN-процессов, таблиц решений DMN и форм	Бесплатный десктопный инструмент, сборки для Windows, macOS (Intel и Apple Silicon) и Linux; стабильная версия 5.50.1 (август 2026)
Stormbpmn	Совместный BPMN 2.0 редактор в браузере, реестр процессов, оргструктура, проверка схем на ошибки	Тариф «Персональный» бесплатный: до 50 моделей процессов, 200 версий модели и 5 гостей; «Команда» 1200 ₽ в месяц (1500 ₽ без скидки); «Бизнес» 4720 ₽ в месяц; on-premise «Организация» от 990 000 ₽ в год
Business Studio	Семь нотаций в одном пакете: IDEF0, Процесс (Basic Flowchart), Процедура (Cross Functional Flowchart), BPMN 2.0, EPC, VAD, FAD	Коммерческая лицензия, актуальные условия на сайте вендора

IDEF0 описан в отечественном документе Р 50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования» и ложится на верхний уровень: какие функции есть у компании, что каждая получает на входе и отдаёт на выходе, чем управляется. Рабочая связка: верхний уровень в IDEF0, целевые процессы в BPMN 2.0, правила решений в DMN.

Что делать с описанным маршрутом дальше

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

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

Частые вопросы

Сколько элементов BPMN нужно выучить, чтобы описать процесс

Шести: стартовое событие, задача, эксклюзивный шлюз, поток, конечное событие, дорожка. Это согласуется с исследованием zur Muehlen и Recker: регулярно используется менее 20% словаря BPMN, а средняя модель обходится примерно девятью конструкциями.

Чем рисовать, если бюджета на инструмент нет

Три бесплатных варианта: demo.bpmn.io в браузере (водяной знак bpmn.io убирать нельзя), Camunda Desktop Modeler 5.50.1 для Windows, macOS и Linux, тариф «Персональный» в Stormbpmn с лимитом 50 моделей.

BPMN или IDEF0

IDEF0 (Р 50.1.028-2001) для верхнего уровня: функции, входы, выходы, управление. BPMN 2.0 (ISO/IEC 19510:2013 идентичен BPMN 2.0.1) для маршрута, который исполняет система. Они не конкурируют, а стоят на разных уровнях детализации.

Как понять, что шаг готов к автоматизации

Правило вида «если, то»; машиночитаемый вход; способ забрать данные из системы-источника (API, вебхук, выгрузка); перечисленные исключения с маршрутами; измеримый результат; названный человек, который разбирает ошибки робота. Не выполняется хотя бы одно, шаг остаётся у человека.

Откуда взять цифру SLA для шага

Из закона, договора или журнала. Статья 22 Закона РФ № 2300-1 «О защите прав потребителей» отводит десять дней на удовлетворение требований о возврате суммы, уменьшении цены и возмещении расходов. Договорной уровень описан в ГОСТ Р ИСО/МЭК 20000-1-2021 как документированное соглашение об уровне сервисов. Внутренний норматив берут между медианой и 90-м процентилем факта за квартал.