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

У компании есть регламент. Процесс описан в BPMN, определены ответственные, прописаны сроки на каждом шаге. На бумаге все выглядит логично и завершено. А на практике заявка проходит совсем другой путь. Она возвращается на дополнительное согласование, которого нет в схеме. Сотрудник вручную переносит данные из одной системы в другую, потому что интеграция между ними так и не была настроена. Часть операций вообще не попала в регламент просто потому, что их никто не описывал, а они все равно выполняются каждый день.

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

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

Почему регламент и реальный бизнес-процесс расходятся

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

Расхождения возникают по нескольким типичным причинам.

• Регламент устарел. Его написали два-три года назад, с тех пор изменились роли, состав команды, требования к качеству, а документ остался прежним.
• Изменились IT-системы. Внедрили новую CRM, обновили ERP, добавили модуль электронного документооборота. Маршрут задачи неизбежно поменялся, а описание процесса — нет.
• Появились обходные пути. Если официальный путь слишком долгий или неудобный, сотрудники находят более быстрый способ добиться результата, и он закрепляется как норма, хотя формально нигде не зафиксирован.
• Добавились дополнительные согласования. Часто это реакция на прошлый инцидент: что-то один раз пошло не так, и в процесс добавили ещё одну проверку «на всякий случай», без пересмотра регламента.
• Возникли ручные операции. Между системами, которые не связаны интеграцией, кто-то вручную копирует данные, сверяет цифры, формирует файлы.
• Появились разные варианты прохождения процесса. Один и тот же тип заявки может обрабатываться по-разному в зависимости от суммы, клиента, региона или просто от того, кто именно её ведёт.
• Существуют исключения. Реальная работа полна частных случаев, которые не укладываются в общую модель, но происходят регулярно.

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

Чем опасно расхождение между регламентом и фактическим процессом

Пока расхождение не выявлено, оно остается невидимым, именно поэтому опасным. Компания принимает решения, опираясь на картину «как должно быть», хотя на самом деле управляет чем-то другим.

Вот к чему это приводит на практике:

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

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

Какие расхождения встречаются чаще всего

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

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

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

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

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

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

Как анализировать бизнес-процессы: пошаговый алгоритм

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

Шаг 1. Определить, что именно анализируем

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

Шаг 2. Зафиксировать эталонный процесс

Здесь начинается основная работа. Источники данных бывают разными в зависимости от того, что доступно и что нужно понять:

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

Шаг 4. Построить фактическую картину процесса

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

Шаг 5. Сравнить модель и факт

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

Шаг 6. Найти причины

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

Шаг 7. Выбрать действие

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

Как Process Mining помогает увидеть фактический процесс

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

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

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

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

Здесь вступает в игру Task Mining — технология, которая показывает, что пользователь фактически делает за компьютером в процессе работы: какие приложения открывает, куда переключается, какие операции повторяет. Если Process Mining отвечает на вопрос «через какие статусы и этапы прошёл процесс», то Task Mining отвечает на вопрос «что конкретно делал человек, пока процесс находился на этом этапе».

Как понять, какое отклонение действительно нужно исправлять

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

Чтобы отделить значимые отклонения от несущественных, имеет смысл оценивать каждое минимум по нескольким критериям:

1. Частота: как часто оно встречается – единичный случай или устойчивый паттерн, повторяющийся в трети всех заявок;
2. Влияние на длительность: насколько сильно оно увеличивает общее время выполнения процесса;
3. Трудозатраты: сколько дополнительного ручного труда оно создает;
4. Влияние на качество: приводит ли к ошибкам или переделкам;
5. Стоимость ошибки: во что обходится компании последствие этого отклонения;
6. Влияние на SLA: приводит ли к нарушению согласованных сроков перед клиентом или партнером;
7. Риск для бизнеса: насколько критичны последствия, если отклонение не устранить.

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

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

Поэтому сначала нужно понять причину отклонения, и только затем выбирать один из вариантов действия:

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

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

Как PIX Процессы помогает увидеть реальную картину процесса

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

• PIX Процессная студия помогает описать и систематизировать процесс, то есть зафиксировать эталонную модель, ту самую точку отсчета из шага 2: как процесс должен быть устроен, кто его участники, в какой нотации он описан.
• PIX Монитор задач — инструмент класса Task Mining, который помогает исследовать фактическую работу пользователей за компьютером и находить скрытые ручные операции, которые не видны ни в одной корпоративной системе: перенос данных между окнами, повторные проверки, обходные пути.
• PIX Аналитик процессов. Инструмент класса Process Mining, который помогает анализировать фактическое прохождение процессов по данным корпоративных информационных систем: строит граф процесса, показывает реальные маршруты, узкие места, отклонения по времени и по составу шагов, зацикленности.

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

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

Чек-лист: соответствует ли ваш бизнес-процесс регламенту

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

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

Заключение

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

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

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