Моделирование бизнес-процессов: методы, нотации и инструменты

Полгода назад аналитик описал в BPMN процесс согласования закупки: роли участников, этапы проверок и маршруты согласования. С тех пор финансовый контроль добавил проверку контрагентов, а заявки до 100 000 ₽ стали проводить по упрощенному маршруту. Рабочий порядок изменился, но схему и учебные материалы не обновили. В результате новых сотрудников продолжали обучать по прежним правилам.

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

Что такое моделирование бизнес-процессов

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

По данным опроса Deloitte Global Process Mining Survey 2025 (120+ организаций, опрос II–III квартала 2024 года), 48% компаний-респондентов уже анализируют процессы в масштабе всей организации по фактическим данным систем. Задача такого подхода — показать процесс целиком, найти узкие места и подготовить его к автоматизации. Он помогает поддерживать модель в актуальном состоянии.

Чем модель отличается от схемы и регламента

Модель, схема и регламент описывают один и тот же процесс с разной степенью строгости.

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

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

Модель объединяет строгость регламента и наглядность схемы. У каждого ее элемента одно значение, ее можно проверить на логические ошибки (недостижимые ветки, шаги без исполнителя) и декомпозировать по уровням детализации.

Цели и задачи моделирования

Компании моделируют процессы, чтобы достичь нескольких целей:

• Прозрачность. Модель делает процесс видимым: кто и за что отвечает, где передается ответственность между отделами, какие документы и данные перемещаются между шагами.
• Единый язык бизнеса и ИТ. Аналитик, заказчик и разработчик обсуждают одну и ту же диаграмму вместо пересказов на собственных терминах.
• Поиск проблем. На модели видны дубли функций, лишние согласования, разрывы ответственности и петли возвратов, которые в повседневной работе воспринимаются как норма.
• Оптимизация. Модель AS-IS («как есть») дает базу для сравнения, модель TO-BE («как должно быть») фиксирует целевое состояние и ожидаемый эффект.
• Подготовка к автоматизации. Внедрение BPMS, роботизация (RPA) и интеграции проектируются по модели — без нее автоматизация закрепляет хаос в коде.
• Обучение и регламентация. Регламенты пишут и обновляют по актуальной модели, а новые сотрудники осваивают процесс по диаграмме быстрее, чем по многостраничному тексту.

Когда пора моделировать процессы

Устойчивые сигналы выглядят так:

• Процесс проходит через три и более отделов, и никто не видит его целиком: каждый участник знает только свой участок и соседние.
• Сроки непредсказуемы: одна заявка согласуется за день, другая за месяц, и причину разброса объяснить некому.
• Знание о процессе живет в головах сотрудников: уход одного специалиста парализует работу участка.
• Планируется автоматизация, например, внедрение BPMS. Автоматизировать неописанный процесс означает закрепить его проблемы в коде.
• Компания растет или проходит слияние: практики разных команд нужно привести к общему знаменателю.
• Регулятор требует описанных процессов, например, для сертификации системы менеджмента качества.

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

Из чего состоит полноценная модель

Для базовой модели нужен следующий состав элементов:

• События старта и завершения. Что запускает процесс и что считается его результатом.
• Шаги и исполнители. Каждый шаг привязан к роли, у роли есть носитель в оргструктуре.
• Логика ветвлений. Очевидные условия, по которым процесс идет разными маршрутами.
• Входы и выходы шагов. Документы, данные и статусы, которые передаются между участниками.
• Метрики. Например, целевой срок цикла и точки его измерения.
• Паспорт модели. Версия, дата актуальности, автор и владелец: без них модель невозможно поддерживать.

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

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

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

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

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

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

В одном проекте можно сочетать несколько видов. Тогда процесс будет выглядеть так:

1. Компания начинает с функциональной карты: блок «Закупки» декомпозируется на выбор поставщика, согласование, оплату и приемку.
2. Сквозная модель в BPMN описывает согласование заявки от инициатора до подписанного договора: события, шлюзы по сумме, дорожки ролей.
3. Когда возникает вопрос «что будет, если поднять порог упрощенного маршрута», подключается имитация: модель прогоняют на историческом потоке заявок и смотрят, как изменится нагрузка на финансовый контроль.
4. Если под процесс дорабатывается СЭД, объектная модель в UML описывает состояния заявки для разработчиков.

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

Методы и методологии моделирования

Нотации выросли из двух школ системного анализа: структурной (SADT/IDEF) и объектной (UML).

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

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

Процессные методологии (например, ARIS с нотацией EPC) добавили к структурному взгляду время и события, объединив в архитектуре предприятия оргструктуру, данные, функции и процессы.

Выбор методологии на практике определяют три фактора:

• задача (аудит, оптимизация, автоматизация),
• аудитория моделей (правление, линейные руководители, разработчики),
• накопленный багаж.

Нотации и платформы: BPMN, IDEF0, EPC, UML и ARIS

Нотация — это соглашение о графическом языке модели, какие элементы она использует и как они соединяются. Разберем их подробно.

BPMN

BPMN (Business Process Model and Notation) — нотация процессного моделирования. Первая версия BPMN 1.0 вышла в мае 2004 года, версия 2.0 — в январе 2011 года. Актуальная редакция — BPMN 2.0.2.

Стандарт делит элементы нотации на пять базовых категорий:

• объекты потока (Flow Objects) — события (круг), активности (прямоугольник со скругленными углами) и шлюзы (ромб). Задача — самый распространенный вид активности; кроме нее есть подпроцессы;
• данные (Data) — объекты и хранилища данных;
• соединяющие элементы (Connecting Objects) — потоки управления, потоки сообщений и ассоциации;
• дорожки (Swimlanes) — пулы и дорожки внутри них. Чаще всего дорожка обозначает роль или подразделение, но стандарт этого не требует: ей можно разделить процесс по системам или этапам;
• артефакты (Artifacts) — группы и текстовые аннотации.

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

IDEF0

IDEF0 — нотация функционального моделирования. Она выросла из методологии SADT Дугласа Росса и была формализована в июне 1981 года по программе ICAM ВВС США. Модель состоит из функциональных блоков, у каждого — четыре типа связей: входы, выходы, управление (регламенты, стандарты) и механизмы (люди, системы).

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

EPC

EPC (Event-driven Process Chain, событийная цепочка процессов) — нотация, в которой процесс описывается чередованием событий и функций: «заявка поступила» (событие) → «проверить заявку» (функция) → «заявка проверена» (событие). Она появилась в 1992 году и стала ключевым элементом методологии ARIS, а SAP использовала ее для документирования процессов системы R/3.

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

UML

UML (Unified Modeling Language) — универсальный язык моделирования, спецификацию которого ведет OMG. Актуальная формальная версия UML 2.5.1 принята в декабре 2017 года.

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

• activity diagram — поток работ, то есть сам процесс;
• state machine diagram — жизненный цикл объекта, например, заявки (создана, согласована, оплачена);
• class diagram — структура данных и сущностей, с которыми работает процесс.

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

ARIS

ARIS (Architecture of Integrated Information Systems) — методология и одноименная платформа моделирования, созданные Августом-Вильгельмом Шеером. Она связывает оргструктуру, данные, функции и процессы в единую архитектуру предприятия, а процессы в ней описываются нотацией EPC. ARIS выбирают крупные организации, которым нужен репозиторий сотен моделей с контролем версий и связей, помимо самих диаграмм.

Сравнение нотаций: BPMN, IDEF0 или EPC

Как построить модель бизнес-процесса: этапы

Построение модели проходит семь этапов. Пропускать шаги не стоит, так как это снижает качество результата.

1. Определите границы процесса. Зафиксируйте событие старта и событие завершения, владельца процесса, участников и метрики: срок цикла, стоимость экземпляра, долю возвратов на доработку. Пример границ: «согласование закупки» начинается с созданной заявки и заканчивается подписанным договором. Без границ модель расползается на смежные процессы и не заканчивается.
2. Соберите данные. Работают три источника: регламенты и инструкции (как процесс задуман), интервью и наблюдение за исполнителями (как его помнят люди), выгрузки и журналы событий информационных систем (как он идет в цифрах). Регламенты закладывают скелет процесса, интервью наполняют его исключениями, данные систем вносят показатели. Расхождения фиксируйте отдельным списком.
3. Выберите нотацию и уровень детализации. Опирайтесь на задачу и аудиторию модели: карта для руководства и постановка на автоматизацию требуют разных языков и разной глубины. Зафиксируйте соглашения о моделировании: какие элементы используете, как именуете шаги, где граница детализации.
4. Постройте модель AS-IS. Опишите фактический ход процесса, включая обходные пути и неформальные договоренности, например, согласования голосом. Не описывайте сразу идеальную модель, иначе сравнивать целевую схему будет не с чем.
5. Провалидируйте модель с участниками. Протестируйте ее на реальных экземплярах процесса, включая нетиповые: срочную закупку, отклоненную заявку, возврат на доработку. Валидация показывает пропущенные ветки и лишние шаги.
6. Спроектируйте модель TO-BE. На основе подтвержденной AS-IS уберите дубли и лишние согласования, задайте SLA и автоматизируйте рутину. Каждое изменение сопровождайте оценкой эффекта: на сколько сократится цикл, сколько ручных операций уйдет. Спорные варианты проверьте имитационным моделированием.
7. Внедрите изменения и поддерживайте актуальность. Обновите регламенты и настройки систем, обучите участников, назначьте владельца модели и порядок пересмотра. Без этого шага схема не будет отражать реальность и помогать упростить работу.

От статичной модели к живой: процессная аналитика

У ручного моделирования и процессной аналитики (process mining) разные задачи, и подходы дополняют друг друга. Ручная модель нужна для проектирования, а процессная аналитика восстанавливает фактическую картину действующего процесса. Спрос на такие инструменты растет. По данным Сбера и «Технологий Доверия», российский рынок process mining в 2025 году вырос на 53% за год, технологию использует каждая третья крупная компания.

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

В портфеле VK Tech эту задачу решает VK Process Mining — модуль платформы VK Business Analytics. В VK Process Mining модель процесса AS-IS строится автоматически на основе журналов событий информационных систем: ERP, CRM, СЭД, учетных систем. Платформа сравнивает фактический ход процесса с эталонным регламентом, подсвечивает отклонения и узкие места, находит возможности для роботизации.

Рабочее место сотрудника тоже дает нужные данные. Для этого применяют модуль VK Task Mining — он собирает действия сотрудников за компьютером и складывает их в «цифровую модель рабочего дня» со всеми рутинными операциями.

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

Примеры применения по функциям

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

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

Логистика. Модель доставки описывает целевой маршрут от заказа до вручения с контрольными точками. Аналитика по данным систем управления складом и транспортом сравнивает перевозчиков по фактическим срокам, считает долю нарушений SLA и показывает, на каком этапе возвраты зависают дольше всего. Ручная модель TO-BE отвечает за редизайн маршрутов и договорные условия, инструмент аналитики следит, чтобы новые правила исполнялись на каждом плече доставки.

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

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

Заключение: с чего начать моделирование бизнес-процессов

Модель бизнес-процесса приносит пользу только пока отражает реальность — иначе превращается в формальность, оторванную от практики. Виды моделирования и нотации (BPMN, IDEF0, EPC, UML, ARIS) задают язык для описания процесса, но поддерживать актуальность вручную сложно и дорого.

Здесь на помощь приходит процессная аналитика: она строит модель AS-IS автоматически по данным систем. В VK Business Analytics это делает модуль VK Process Mining — сравнивает факт с регламентом и подсвечивает отклонения, а результаты попадают на общие BI-дашборды вместе с финансовыми показателями.