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

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

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

Модель и реальная работа

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

Модель этого процесса фиксирует пять вещей:

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

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

Модель, схема и карта процессов

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

Когда компании нужно моделирование

Подготовка к улучшению и автоматизации

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

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

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

Обучение и согласование правил

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

• не определены условия решений, например при какой сумме нужно согласование;
• непонятно, какие данные нужны на каждом шаге;
• нет согласия участников с описанием;
• не описаны исключения: отказ, возврат, отсутствие сотрудника.

Что должно быть в модели процесса

Начало, завершение и результат

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

Действия и участники

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

Условия и исключения

Самая полезная часть модели описывает отклонения от основного пути:

• возврат на доработку при неполных данных;
• отказ при превышении лимита или нарушении правил;
• параллельное согласование, когда два отдела проверяют заказ одновременно;
• отсутствие согласующего и замещение.

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

Подходы и методы моделирования

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

Функции и последовательность действий

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

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

Имитационное моделирование

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

Простой учебный пример. Руководитель успевает согласовать 30 скидок в день, а приходит 40 запросов. Каждый день в очереди остается 10 запросов, за неделю из пяти рабочих дней их накопится 50. Имитация покажет, что изменится, если половину скидок разрешить менеджерам без согласования. Но если на практике запросы приходят неравномерно, а время согласования сильно зависит от суммы, без этих данных расчет окажется слишком оптимистичным.

Как выбрать подход

Начните с вопроса, который нужно решить:

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

Нотации и способы представления

BPMN, IDEF0 и другие языки

BPMN (Business Process Model and Notation) описывает потоковый подход: события, задачи, шлюзы-развилки и дорожки участников. Нотацию понимают и аналитики, и бизнес-пользователи, а многие BPM-системы умеют исполнять модели в BPMN. Подробно об элементах рассказано в руководстве по BPMN 2.0.

IDEF0 (Integration Definition for Function Modeling, стандарт функционального моделирования из семейства IDEF) описывает функциональный подход. Каждая функция изображается блоком, к которому подходят стрелки входа, управления, механизма и выхода. Нотация удобна для верхнеуровневого описания работ.

EPC (Event-driven Process Chain) описывает процесс как чередование событий и функций. Блок-схемы и диаграммы с дорожками (swimlane) проще всего читаются людьми без подготовки.

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

Текст, таблица и графическая схема

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

Что важно в инструменте

При выборе программы для моделирования оценивают:

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

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

Выбрать процесс и собрать факты

Определите цель: что нужно улучшить или подготовить к автоматизации. Затем задайте границы процесса и соберите факты:

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

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

На интервью с исполнителем помогают простые вопросы:

• Откуда к вам приходит работа и в каком виде?
• Что вы проверяете в первую очередь и что делаете, если данных не хватает?
• Кому передаете результат и как узнаете, что его приняли?
• Какие случаи идут не по обычному пути и как часто?
• Где вы чаще всего ждете других и сколько?

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

Описать текущее состояние AS-IS

Модель AS-IS («как есть») описывает текущую работу, включая обходные пути и исключения. Если менеджеры пересылают заявку руководителю в мессенджере, это тоже часть процесса. Готовую модель показывают участникам и подтверждают: каждый должен узнать свою работу.

Найти проблемы и предложить TO-BE

На модели AS-IS отмечают проблемы. Для каждой разделяют три вещи: наблюдение (заявки ждут согласования скидки по три дня), причину (руководитель согласует каждую скидку, даже минимальную) и предложение (скидки до определенного порога не требуют согласования). Модель TO-BE («как будет») описывает целевое состояние. Методы поиска и устранения проблем подробнее разобраны в статье про оптимизацию бизнес-процессов. Для каждого изменения указывают, за счет чего оно даст эффект и как это проверить.

Согласовать и применить модель

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

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

Пример модели согласования заказа

Текущая работа

Учебный процесс B2B-компании до изменений:

1. Менеджер получает заказ клиента по почте и вносит его в CRM.
2. Менеджер проверяет цену и наличие товара.
3. Если клиент просит скидку, менеджер отправляет запрос руководителю продаж по почте.
4. Руководитель согласует скидку или возвращает заказ менеджеру за недостающими данными.
5. Если клиент просит отсрочку, финансовый отдел после согласования скидки проверяет кредитный лимит.
6. При превышении лимита клиенту предлагают предоплату или отказывают.
7. Менеджер подтверждает заказ клиенту.
8. Заказ передают на склад.

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

Будущая работа

В модели TO-BE предлагаются три изменения:

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

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

Как проверить изменения

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

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

Похожую задачу решала «ВОЛМА», производитель строительных материалов: компания перенесла согласование коммерческих условий в BPMSoft, и ценовой запрос теперь идет по автоматическому маршруту согласования.

Как проверить качество модели

Проверка с участниками

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

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

Проверка полноты и уровня детализации

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

1. У процесса есть одно событие запуска и понятные события завершения.
2. Из каждой развилки выходят все возможные варианты с условиями.
3. Нет тупиков: каждый путь заканчивается результатом.
4. У каждого шага есть исполнитель.
5. Возвраты на доработку описаны: кто, куда и в какой срок.
6. Все шаги одного уровня детализации: рядом нет «согласовать договор» и «нажать кнопку».
7. Допущения и не описанные пути перечислены отдельно.

Ошибки при моделировании

Слишком общая или перегруженная схема

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

Желаемая работа вместо фактической

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

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

Как перейти от модели к автоматизации в BPMSoft

Что подготовить для настройки

Для настройки процесса в системе модели нужны конкретные данные:

• участники и их роли;
• условия всех развилок с точными значениями;
• данные и поля на каждом шаге;
• сроки и правила эскалации.

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

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

Частые вопросы о моделировании