Process Mining восстанавливает фактический ход бизнес-процесса по записям в информационных системах. Каждая заявка оставляет след: когда ее создали, кто проверил, когда согласовали. Анализ собирает эти события в маршрут и показывает, где работа задерживается, какие пути встречаются чаще всего и где заявки уходят на повторный круг.
Технология показывает, как процесс идет на самом деле, по данным из систем. Причины найденных задержек и повторов затем проверяют вместе с исполнителями.
Что такое Process Mining
Определение на примере заявки
Возьмем заявку на закупку. Сотрудник создает ее в системе, отдел закупок проверяет, финансовый отдел согласует, руководитель принимает решение. Каждое действие система записывает как событие: номер заявки, что сделали и когда.
Process Mining (в переводе «добыча процессов») связывает события одной заявки в цепочку, затем повторяет это для сотен и тысяч заявок. В результате получается карта фактических маршрутов: какой путь проходит большинство заявок, какие обходят правила, где они ждут дольше всего.
Какие вопросы можно решить
Анализ помогает ответить на конкретные вопросы:
- на каком этапе заявки задерживаются и насколько;
- сколько разных маршрутов встречается в процессе, который по регламенту должен быть один;
- как часто заявки возвращают на доработку и с какого этапа;
- где возникают повторные согласования;
- отличается ли ход процесса в разных филиалах или для разных типов заявок.
Технология показывает только то, что отражено в данных. Если часть работы идет по телефону или в мессенджере и не фиксируется в системе, Process Mining ее не увидит.
Чем Process Mining отличается от других подходов
Моделирование и BPM
Модель процесса описывает, как работа должна идти по правилам: кто участвует, в каком порядке, при каких условиях. Ее строят по интервью и документам, часто в нотации BPMN 2.0. Process Mining изучает фактические события и показывает, как работа шла на самом деле. Обычно оба подхода используют вместе: модель задает ожидаемый ход, анализ событий проверяет, совпадает ли с ним реальность.
BPM (Business Process Management) шире обоих. Это цикл управления бизнес-процессами: описание, автоматизация, контроль и улучшение. Process Mining в этом цикле отвечает за диагностику.
BI и Task Mining
BI-системы (Business Intelligence) показывают показатели: число заявок, средний срок, загрузку отделов. Некоторые BI-отчеты тоже строят маршруты, но обычно BI отвечает на вопрос «сколько», а Process Mining на вопрос «по какому пути шли заявки и где они ждали».
Task Mining исследует действия сотрудника на рабочем месте: какие окна открывает, что копирует, сколько времени тратит на ввод данных. Для этого нужен отдельный сбор данных с компьютеров, обычно с согласия сотрудников. Task Mining помогает найти рутину внутри одного шага, Process Mining показывает связи между шагами.
| Подход | Объект анализа | Источники данных | Результат | Ограничение |
|---|---|---|---|---|
| Process Mining | Фактический ход процесса | Журналы событий CRM, учетных систем, систем обращений | Карта маршрутов, задержки, повторы, отклонения | Видит только зарегистрированные события |
| Моделирование | Правила и ожидаемый ход работы | Интервью, регламенты, документы | Схема процесса AS-IS или TO-BE | Может расходиться с реальной работой |
| BI | Показатели и их динамика | Базы данных, отчеты, хранилища | Дашборды, сводные отчеты | Маршруты обычно не восстанавливает |
| Task Mining | Действия на рабочем месте | Данные с компьютеров сотрудников | Рутинные операции внутри шага | Отдельный сбор данных, вопросы доступа и согласия |
Какие данные нужны для анализа
Минимальный журнал событий
Журнал событий (event log) состоит из записей, в каждой из которых три обязательных поля:
- идентификатор случая: номер заявки, заказа или обращения, по которому события связываются;
- название действия: создание, проверка, согласование, возврат;
- время события: дата и время с точностью хотя бы до минуты.
Если нужно знать, сколько длилось само действие, понадобятся два события: начало и окончание. Иначе можно измерить только промежуток между соседними событиями, а он включает и работу, и ожидание.
Дополнительные поля
Для разбора причин полезны атрибуты: подразделение, тип заявки, сумма, результат, исполнитель. Их включают в выгрузку только при необходимости. Данные об исполнителях относятся к персональным, поэтому доступ к ним согласуют заранее, а в отчетах для широкого круга их лучше обезличить.
Проверка качества данных
Перед анализом журнал проверяют на типичные проблемы:
- дубли событий, например двойная запись при сохранении карточки;
- пропуски обязательных этапов;
- одинаковое время у нескольких событий, из-за чего порядок неизвестен;
- разные часовые пояса у филиалов;
- смена номера заявки при переходе между системами;
- события из нескольких систем, которые нужно связать по общему ключу.
Ошибки в журнале превращаются в ложные находки. Поэтому выборку из 10-20 случаев сверяют с реальными карточками до начала анализа.
Как работает Process Mining
Восстановление фактического маршрута
Алгоритм группирует события по идентификатору случая и сортирует их по времени. Получается последовательность действий для каждой заявки. Заявки с одинаковой последовательностью объединяют в вариант процесса. Затем все варианты накладывают на одну схему: на ней видно, какие переходы встречаются часто, а какие редко.
Сравнение с правилами
Проверка соответствия (conformance checking) сопоставляет фактические маршруты с согласованной моделью или списком правил. Она отвечает на вопросы: все ли обязательные проверки пройдены, соблюдается ли порядок, какие исключения допустимы. Без согласованной модели или правил отклонение определить нельзя: непонятно, с чем сравнивать.
Поиск задержек и повторов
По меткам времени считают ожидание между этапами, длительность всего случая и число возвратов. Затем сравнивают группы: заявки разных типов, сумм, подразделений.
Связь при этом еще не означает причину. Если крупные заявки согласуют дольше, причина может быть в сумме, в составе согласующих или в том, что их подают в конце месяца. Process Mining находит закономерность, а проверять причину нужно отдельно.
Пример анализа согласования закупки
Учебный журнал
Возьмем три условные заявки на закупку. Данные учебные, время указано по Москве.
| ID заявки | Действие | Дата и время | Подразделение | Результат |
|---|---|---|---|---|
| З-101 | Создание | 03.03, 09:10 | Склад | Заявка подана |
| З-101 | Проверка | 03.03, 11:40 | Закупки | Данные полные |
| З-101 | Согласование | 04.03, 10:05 | Финансы | Бюджет подтвержден |
| З-101 | Решение | 04.03, 15:20 | Руководитель | Одобрено |
| З-102 | Создание | 03.03, 10:00 | Производство | Заявка подана |
| З-102 | Проверка | 03.03, 14:30 | Закупки | Данные полные |
| З-102 | Возврат на доработку | 04.03, 09:15 | Финансы | Нет обоснования суммы |
| З-102 | Согласование | 05.03, 16:00 | Финансы | Бюджет подтвержден |
| З-102 | Решение | 06.03, 12:10 | Руководитель | Одобрено |
| З-103 | Создание | 04.03, 09:30 | ИТ | Заявка подана |
| З-103 | Проверка | 04.03, 10:15 | Закупки | Данные полные |
| З-103 | Согласование | 04.03, 13:00 | Финансы | Бюджет подтвержден |
| З-103 | Решение | 11.03, 17:45 | Руководитель | Одобрено |
Что видно по данным
Между созданием заявки и решением по ней прошло разное время:
- З-101: 1 день 6 часов 10 минут, маршрут без отклонений;
- З-102: 3 дня 2 часа 10 минут, один повторный круг из-за возврата на доработку;
- З-103: 7 дней 8 часов 15 минут, из них 7 дней 4 часа 45 минут прошли между согласованием и решением.
Две находки требуют проверки. Первая: финансовый отдел вернул заявку З-102, потому что в ней не было обоснования суммы, хотя закупки ее уже проверили. Возможно, при проверке не смотрят на это поле. Вторая: заявка З-103 неделю ждала решения руководителя. Причин может быть несколько: отпуск без замещения, заявка потерялась в общем списке или руководитель ждал дополнительных сведений, которые в систему не попали.
Промежуток в 7 дней показывает календарное время. Он включает выходные и ничего не говорит о том, сколько минут кто-то реально работал с заявкой.
Что предложить после проверки
Сначала причины подтверждают: смотрят еще 30-50 заявок за тот же период, обсуждают находки с сотрудниками закупок и финансов. Если причина подтвердилась, предложения могут быть такими: добавить проверку обоснования суммы на этапе закупок, настроить напоминание руководителю и правило замещения. Изменение согласуют с ответственным за процесс, затем повторяют измерение на сопоставимом периоде.
| Наблюдение | Возможная причина | Способ проверки | Действие после подтверждения | Показатель результата |
|---|---|---|---|---|
| Возврат с этапа согласования в финансах | Поле обоснования не проверяют на этапе закупок | Выборка возвратов за месяц, разговор с проверяющими | Сделать поле обязательным и добавить его в чек-лист проверки | Доля заявок с возвратом |
| Долгое ожидание решения | Отсутствие руководителя без замещения | Сверка с графиком отпусков и командировок | Правило замещения и напоминание через заданный срок | Время между согласованием и решением |
| Разный срок у филиалов | Разный состав согласующих или объем заявок | Сравнение маршрутов и числа заявок по филиалам | Единые правила маршрута для одинаковых типов заявок | Медианный срок по филиалам |
Чтобы анализировать процесс по событиям, система должна их фиксировать. Например, транспортная компания «ГардаТранс» перевела работу с заказами на BPMSoft: статусы заказа обновляются автоматически, изменения и комментарии сохраняются в системе.
Где применяется технология
Продажи, закупки и сервис
- Продажи. Вопрос: на каком этапе сделки зависают дольше всего и сколько из них возвращаются к согласованию цены. Источник событий: CRM, история смены этапов сделки.
- Закупки. Вопрос: сколько согласований проходит заявка и где ее чаще возвращают. Источник: система учета заказов или закупок.
- Сервис. Вопрос: сколько раз обращение передают между линиями поддержки до решения. Источник: система обращений.
Найденные проблемы становятся отправной точкой для оптимизации бизнес-процессов.
Когда подход не подойдет
Подход вряд ли даст результат, если:
- у случаев нет единого идентификатора и события нельзя связать между собой;
- значимая часть работы идет вне систем: по почте, телефону, на бумаге;
- событий слишком мало для выводов, например десяток заявок в месяц;
- процесс постоянно меняется, и маршруты за разные месяцы несравнимы.
Как провести пилотный проект
Выбрать процесс и цель
Пилот начинают с одного процесса и одной проблемы. Например: «заявки на закупку согласуют в среднем девять дней, нужно понять, где теряется время». Для пилота определяют границы процесса, источники данных, ответственного и критерий успеха. Анализ сразу всех процессов компании обычно тонет в подготовке данных.
Подготовить и проверить данные
Выгружают журнал за период, достаточный для выводов: обычно несколько месяцев. Затем сверяют выборку случаев с карточками в системе и обсуждают события с исполнителями. Сотрудники могут объяснить странности в данных: например, этап «проверка» в системе закрывают в конце дня пачкой.
Проверить находки и эффект
Находки формулируют как гипотезы, проверяют, затем внедряют согласованное изменение. Через сопоставимый период измерение повторяют на тех же правилах расчета. Только так можно оценить, дало ли изменение результат.
Ограничения и ошибки Process Mining
Неполный журнал и неверные выводы
Процесс виден только в пределах зарегистрированных событий. Если сотрудники отмечают этапы задним числом, время событий искажается: заявка «прошла проверку» в 18:00, хотя на деле ее проверили утром. Такие искажения выявляют при сверке с исполнителями.
Непроверенный эффект и доступ к данным
Универсальных процентов экономии от Process Mining нет: результат зависит от процесса, качества данных и того, какие изменения компания внесет. Оценивать эффект нужно повторным измерением.
Еще одна ошибка: превращать анализ процесса в рейтинг сотрудников. Если у одного исполнителя заявки идут дольше, причина может быть в типе заявок, которые ему распределяют. Выводы о людях без разбора контекста подрывают доверие к анализу и мотивируют сотрудников «улучшать» данные вместо процесса.
Как связать анализ с автоматизацией в BPMSoft
От найденной проблемы к изменению правил
Анализ журнала событий выполняют во внешнем инструменте Process Mining. В этой связке CRM и BPM-система нужны, чтобы процесс шел через систему и события фиксировались полно и одинаково. Когда каждый этап заявки проходит в системе, у компании появляются статусы, даты и история изменений по каждому случаю.
После анализа найденные изменения нужно перенести в работу: добавить обязательную проверку, правило маршрута или напоминание. В BPM-системе BPMSoft такие правила настраивают в процессе, а затем по тем же данным проверяют, изменились ли сроки и число возвратов.