Process Mining и Task Mining: как увидеть реальную операционку и убрать лишнее

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

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

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

Именно здесь полезны Process Mining и Task Mining. Первый восстанавливает фактический ход процесса по цифровым следам в корпоративных системах. Второй позволяет спуститься на уровень действий сотрудника и увидеть, что происходит внутри отдельной задачи.

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

У процесса почти всегда есть вторая версия

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

Это полезно, но у такого подхода есть ограничение.

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

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

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

Вместо мнений — фактические маршруты

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

Если эти события можно связать с конкретным экземпляром процесса и расположить во времени, получается журнал событий — event log. На его основе Process Mining восстанавливает фактическую последовательность выполнения процесса.

На схеме все может выглядеть просто:

заявка → проверка → согласование → выполнение.

Но данные показывают другие варианты:

заявка → проверка → возврат → исправление → повторная проверка → согласование → выполнение;

или:

заявка → проверка → дополнительное согласование → ожидание → повторное согласование → выполнение.

То есть Process Mining позволяет увидеть не то, как процесс задуман, а то, какие маршруты существуют в действительности, как часто они встречаются и сколько времени занимают.

Показательный пример — исследование, опубликованное в Applied Sciences. Авторы анализировали амбулаторный процесс детской офтальмологии в госпитале Коста-Рики. После подготовки данных в журнале событий осталось 1 814 случаев, 56 активностей и 385 вариантов процесса. Анализ выявил повторные действия, узкие места и расхождения с ожидаемой моделью. После этого исследователи построили три сценария симуляции, чтобы оценить возможные изменения.

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

В бизнесе происходит то же самое. Один «стандартный» order-to-cash, procure-to-pay или процесс обработки обращения может состоять из множества реальных маршрутов.

Между системными событиями тоже есть работа

У Process Mining есть естественная граница.

Предположим, система зафиксировала два события:

10:03 — документ получен.
10:17 — документ зарегистрирован.

Между ними прошло 14 минут.

Что происходило в это время?

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

Для сквозного процесса это один промежуток между двумя событиями.

Для сотрудника — целая цепочка действий.

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

Если упростить:

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

Не все нестандартное — лишнее

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

Но отклонение само по себе ничего не доказывает.

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

Поэтому искать стоит не просто отклонения, а устойчивые паттерны, которые требуют объяснения.

Например:

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

Здесь Process Mining и Task Mining особенно хорошо дополняют друг друга.

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

Данные находят паттерн. Причину все равно ищут люди

Это важное ограничение любого data-driven подхода.

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

Но причина не всегда видна в event log.

В июне 2026 года исследователи University of Münster представили на ECIS обзор роли человека в Process Mining. Авторы проанализировали 23 исследования и отдельно показали: именно пользователи интерпретируют процессные данные, превращают наблюдения в выводы и инициируют изменения.

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

А дальше уже нужно разбираться в причине.

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

Не стоит автоматизировать действие только потому, что оно ручное

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

Но здесь легко перепутать цель и средство.

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

Поэтому сначала стоит понять:

Почему эта операция появилась?
Как часто она выполняется?
В каких случаях?
Что происходит до нее и после?
Она действительно создает ценность или лишь компенсирует проблему другого участка?

И только потом выбирать решение.

Иногда ответ — автоматизировать.

Иногда — стандартизировать.

Иногда — изменить систему.

А иногда — просто убрать шаг.

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

Сначала увидеть. Потом улучшать

Process Mining и Task Mining не отменяют интервью, регламенты, BPMN-модели и экспертные сессии.

Они добавляют к ним то, чего часто не хватает, — фактическую картину работы.

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

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

А процессная экспертиза помогает объяснить, почему эти действия появились и что с ними делать.