Источник: https://futurebanking.ru/post/4029
В Сбере с помощью Process Mining за последние два года было проанализировано множество бизнес-процессов. Андрей Бугаенко, исполнительный директор по исследованию данных, рассказывает о группах задач, которые уже можно решить с помощью машинного обучения, проблемах, с которыми приходилось сталкиваться, и новых направлениях для разработки.
— Процессов в банке тысячи — как решить, каким из них заниматься в первую очередь? Как определить приоритетные направления для Process Mining (PM)?
А. Бугаенко: При выборе процессов для исследования используем три критерия:
- масштаб процесса (в приоритете массивные);
- наличие цифровых следов (без данных ничего не получится) и уровень цифровизации (чем детальнее логирование данных, тем лучше);
- наличие гипотез, подлежащих проверке (чем их больше на первом этапе, тем лучше).
— Какие задачи в Process Mining решаются с помощью машинного обучения?
А. Бугаенко: Сейчас для анализа процессов используем Python-библиотеку SberPM (в двух версиях — корпоративная для внутренних пользователей и бесплатная (open source) для внешних) и специализированную платформу SberProcessMining с мощным BI-функционалом.
Все задачи ML в PM, которые мы развиваем, условно можно разделить на пять групп.
1. Автоматический поиск кейсов неэффективности в процессах и аномалий (пожалуй, основное направление)
Конечно же, применяем и классический подход PM с майнерами (алгоритмы, которые позволяют преобразовать информацию из таблицы/лога данных в графический формат). Мы используем как стандартные наборы дата-майнеров (описанные, например, в книге “Process Mining: Data Science in Action”), так и собственные ноу-хау. В их числе параллельный майнер, который с максимальной чувствительностью выявляет параллельности в процессах, а также ML-майнер, отслеживающий влияние изменений одного этапа на процессы в другом.
Но мы продвинулись дальше.
У нас есть функционал, который позволяет автоматически обнаруживать неэффективности в бизнес-процессах, что экономит время работы аналитика процессов. Основной функционал «автоинсайтов» включает в себя две модели: одна находит аномалии в метриках процесса (длительность этапов, вероятность, дифференциалы времени и т. д.), вторая анализирует текстовую информацию. Обе модели в случае обнаружения аномалии выставляют специальные флаги, и по комбинации этих флагов мы можем идентифицировать тот или иной тип неэффективности. Сейчас мы умеем идентифицировать 14 типов неэффективности в процессах. Например: разные типы bottleneck, разные типы зацикленности, нестандартизованные этапы и т. д. В ближайшее время мы планируем перейти на одну мультимодальную модель с тремя модальностями: метрики, текст и графовые эмбеддинги.
Также для поиска неэффективности можно использовать факторный анализ. Предположим, при анализе процесса нам нужно посмотреть какой-то бенчмарк, сравнить процессы, например по регионам, сегментам или конкретным людям. Факторный анализ подсказывает, какой параметр сравнения является наиболее значимым для успеха или длительности процесса. Аналитику уже не нужно проверять бенчмарки по всем подряд факторам, а сразу можно смотреть только по «значимым».
Наконец, у нас вышла первая дата-версия «бота», способного самостоятельно провести комплексный анализ бизнес-процессов. Мы подгружаем данные в условную модель, «бот» анализирует их в процессе, находит неэффективность, рассчитывает потенциальный финансовый эффект от её устранения, формирует образ идеального процесса, готовит текстовое описание, презентацию, отрисовывает её и выдаёт пользователям презентацию по готовому исследованию.
2. Для автоматического поиска инсайтов должны быть подготовленные данные (журнал событий). И подготовка данных — это второе направление. Здесь мы решаем задачи:
— автоматического мэтчинга таблиц, если процесс протекает в нескольких АС;
— простановки «синтетических ID», если ID экземпляра процесса в логе отсутствует, но мы знаем, какими этапами процесс начинается и заканчивается;
— расчёта цифрового хронометража как для простановки на графе процесса, так и для внешнего использования, например в тарифных моделях;
— кластеризационной фильтрации выбросов в данных.
3. Анализ текстов. Полученные данные часто сопровождаются дополнительной текстовой информацией. Это может быть как комментарий сотрудника (например, когда документ возвращается на доработку) или клиента, так и комментарий, автоматически сгенерированный системой. На выходе получаем гигантскую таблицу с миллиардами записей, на проработку которой у аналитика уйдёт много времени и сил.
Что мы делаем, чтобы упростить аналитику жизнь? Все текстовые записи делим на кластеры на основе максимального сходства, по каждому кластеру выводим основной смысл (заголовок), решаем NLP-задачу «суммаризации». В итоге аналитику нужно прочитать уже не миллиарды записей, а десятки заголовков. Если он обнаруживает что-то аномальное или подозрительное, углубляется в изучение темы.
Ещё на этом направлении используются алгоритмы, которые помогают «схлопывать» похожие этапы в один. В логе данных возможна ситуация, когда процессу присваиваются разные наименования на одном и том же этапе. Например, «вход в систему», «вход в систему» с точкой, «вход в систему» с пробелом. Если мы внесём такие данные в лог, граф отрисует их как три отдельных этапа, хотя по факту он один. На корректировку может уйти уйма времени, так как названия этапов придётся менять вручную. Алгоритм вычисляет такие этапы, предлагает их «схлопнуть» и в случае согласия пользователя делает это сам.
Также для анализа текстов используется сентимент-анализ: записям выставляется коэффициент от 0 до 1, где 0 — максимально негативный отзыв/комментарий, 1 — максимально позитивный. Все отзывы, значения которых ближе к 0, имеет смысл отобрать и проанализировать.
4. Поиск оптимальной структуры процесса. Здесь мы используем подход Reinforcement Learning (с модификацией Auto Reinforcement Learning) — алгоритм, в задачи которого входит поиск оптимального пути в графе процесса.
Если граф процесса имеет структуру «спагетти» со множеством этапов, результатов, связей, то определить «глазами», как он должен проходить, практически невозможно. Мы подгружаем данные, и алгоритм должен пройти оптимальный путь от старта до финиша. Как, например, в компьютерных играх с лабиринтами или как при выборе наилучшей траектории для беспилотного автомобиля. После нахождения оптимального пути по графу процесса становится очевидно, какие этапы по сути лишние и в какой последовательности процесс должен проходить. Причём этот поиск подходит для разных ситуаций. Например:
— «агент» всегда попадает в этап, в который хочет;
— учитывается влияние «среды», которая может не дать ему попасть в нужный этап;
— эта вероятность может меняться при каждом шаге.
Также работает система имитационного моделирования «what-if-анализ», которая позволяет оценить, как изменятся метрики этапов процесса, если, например, какие-то этапы поменять местами либо какой-то этап удалить или добавить.
5. Ещё одно направление работы — это предиктивная аналитика и прогнозирование. Владельцы процесса часто интересуются, как будет выглядеть бизнес-процесс, например, через год при сохранении текущих трендов. Это позволяет увидеть неэффективности в процессе, которые ещё не появились, но с определённой вероятностью появятся.
— Какие методы машинного обучения оказались наиболее эффективными в PM?
А. Бугаенко: Мы используем большой стек ML-направлений, как классические методы (регрессии, включая time series, кластеризации), так и более продвинутые (дистиллированные трансформеры, LSTM, сиамские сети, RL). Широко применяем AutoML. Много и своих ноу-хау. Например, когда мы не смогли найти готовую библиотечку по AutoRL — написали свою.
— С какими проблемами вам приходилось сталкиваться при реализации проектов Process Mining?
А. Бугаенко: Я бы выделил три такие проблемы.
1. Проблема с данными из автоматизированных систем. Они могут быть неполными, находиться в разных таблицах, их может быть сложно объединить, надо вычищать и т. д. На это тратится много времени. Для решения этой проблемы развиваем направление использования ML при подготовке данных.
2. Для некоторых процессов не предусмотрены автоматизированные системы, в которых ведётся логирование. Например, юристы часто работают с текстовыми документами, а не с конкретной СRM- или ERP-системой. В этом случае можно использовать программу «Агент логирования» (Task Mining), которая устанавливается на компьютер и ведет лог действий сотрудника. Мы уже разработали собственную версию агента логирования, сейчас используем его внутри в пилотном режиме.
3. Предвзятое отношение к Process Mining. Внутри самого Сбера уже все подразделения понимают ценность Process Mining, так как и на практике убедились, насколько высок уровень отдачи при его применении. Однако во внешней среде ещё живы стереотипы, что PM — это инструмент для крупных компаний. Естественно, в крупных компаниях отдача от PM будет существенно больше, просто за счёт эффекта масштаба. И крупные компании и так уже это поняли и применяют PM. Но малый и средний бизнес тоже могут легко получить эффект от оптимизации процессов.
— Какие новые направления сейчас в разработке?
А. Бугаенко: Сейчас занимаемся разработкой моделей по распознаванию изображений для задач PM. Нередко перед аналитиками встаёт задача проверить, соответствуют ли данные в логе тому, что должно быть отрисовано в регламенте, схеме и т. д. Забрать данные из лога, преобразовать их в графы, а графы в BPM-нотацию мы уже можем. Оставалось отладить выгрузку данных из различных автоматизированных систем, поскольку форматы часто оказывались специфическими, а какие-то процессы были отрисованы в Power Point или графических редакторах. Не исключаю, что в каких-то компаниях схемы процессов вообще могут быть отрисованы от руки.
Модель, которую мы разрабатываем, сможет распознавать схемы бизнес-процессов в нотациях к BPMN и EPC и автоматически сопоставлять их с данными в логе. То есть любую картинку процесса (BPMN, EPC) можно будет автоматически сравнить с реальным процессом из логов с подсветкой, в чём и где зафиксированы отклонения.
— Что вы рекомендуете компаниям, которые подумывают о внедрении у себя Process Mining?
А. Бугаенко: Во-первых, Process Mining совершенно точно нужно внедрять, независимо от масштабов бизнеса. Крупные компании, конечно, получат большую value, но обнаруживать у себя аномалии полезно и МСБ.
Во-вторых, нужно примерно представить масштабы своих процессов и уровень их цифровизации. Если он пока не слишком высок, то следует формировать у себя стандарты логирования и/или прибегать к помощи «агентов логирования».
В-третьих, даже если у вас неполные логи или не оцифрованы все процессы, всё равно начинайте использовать PM, так как даже в данных, соответствующих только части процесса, вполне можно обнаружить какие-то неэффективности. Кроме того, это положит начало культуре Process Mining в организации.
