Процессная аналитика (Process Mining) — это методология сбора и анализа информации о бизнес‑процессах. Она помогает составить реальную схему процессов, разобраться в их работе и найти узкие места, требующие вашего внимания. Также процессная аналитика помогает выявлять «нетипичные» пути прохождения и прогнозировать работу бизнес‑процессов.

Мы рассмотрим подробнее эту методологию и особенности её применения. А также на нескольких примерах из практики М.Видео‑Эльдорадо и Т1 покажем, чем процессная аналитика может быть полезна в компании.

Для чего нужна процессная аналитика

Сначала договоримся о терминах:

Бизнес‑процесс — это совокупность взаимосвязанных мероприятий или работ по созданию определённого продукта или услуги для потребителя.

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

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

• создание заявки;

• выбор розничного магазина для выполнения;

• сбор заказа в магазине;

• проверка качества, нет ли в заказе витринных образцов;

• передача заказа курьеру, которого заранее назначил партнёр‑перевозчик;

• доставка по адресу;

• личная передача заказа покупателю.

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

• Успешность доставки: сколько заказов получили покупатели. Если доставка неудачна, нужно знать причину.

• Своевременность выполнения: сколько заказов доставлено в срок. Чтобы контролировать эту метрику, нужно знать особенности работы партнёра‑перевозчика. Возможно, в каких‑то случаях целесообразно доставлять самостоятельно, чтобы не сорвать сроки.

• Качество обслуживания: насколько удовлетворены клиенты.

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

Всё это характеризует, насколько клиенты довольны работой компании.

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

Магазины и склады М.Видео‑Эльдорадо разбросаны по всей стране, они генерируют огромный массив данных. Бизнес‑процессы сложны и разветвлённы. В таких условиях традиционные методы анализа требуют слишком много времени и сил. Кроме того, в бизнес‑процессах компании участвуют данные в разных форматах из CRM, поддерживающих сервисов, от партнёров и др. Но благодаря процессной аналитике можно справиться с такими объёмами данных, эффективно выявлять закономерности и аномалии, которые невозможно обнаружить с помощью традиционных BI‑инструментов. Кроме того, эта методика позволяет обрабатывать информацию централизованно, освобождая аналитика от сбора данных вручную из разных систем, что повышает его скорость работы и осведомлённость.

Процессная аналитика работает только там, где процессы чётко определены: есть понятные этапы, правила и границы.

Планы и реальность процессов

При проектировании процесс задумывают максимально линейным и прозрачным, при этом ожидая, что все ключевые показатели эффективности (KPI) будут близки к полному выполнению. Например, как в случае с доставкой заказа:

Создана заявка → Заказ ожидает передачи в доставку → Назначен перевозчик → Назначен курьер → Заказ передан в доставку → Заказ отгружен курьеру → Курьер прибыл на место доставки → Заказ передан покупателю.

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

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

Как применяют процессную аналитику

Эту методику в М.Видео‑Эльдорадо используют более двух лет для решения таких задач:

• тестирование гипотез;

• мониторинг процессов в реальном времени;

• аналитика фактических процессов;

• повышение качества процессов;

• оптимизация ресурсов;

• аналитика ошибок и сбоев.

Рассмотрим эти способы применения на нескольких примерах.

Оптимизация подбора курьера

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

Начали выяснять причину долгого подбора курьера. Для этого составили подробный граф этапов:

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

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

Алгоритмы поменяли. Теперь магазин для формирования заказа подбирался автоматически, с учётом пробок на дорогах. Приоритет отдавался точкам, рядом с которыми больше доступных курьеров. «Сложным» магазинам оставляли заказы с редкими или уникальными позициями.

После А/Б‑тестирования выяснилось, что длительность подбора курьеров сократилась вдвое (в среднем до 12,75 минуты), а общая своевременность доставки по компании улучшилась на 5%.

Контроль уровня обслуживания

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

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

Изменили расчёт метрики «Своевременность доставки» с учётом логистической схемы партнёра, он подтвердил изменения. За две недели доработали интеграцию, и метрика стала рассчитываться корректно во всех системах компании.

Изменение срока доставки

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

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

Построили граф, на котором посмотрели, что могло повлиять на общее время доставки. Увидели зависимость по городам (везде свои условия найма).

По двум параметрам — региону и расстоянию — построили ещё один граф, чтобы понять, какие расстояния надо учитывать в исследовании. Получили три категории:

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

Помощь ИТ в управлении инцидентами

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

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

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

Повышение выкупаемости заказов

И последний пример: как анализировали причины низкой выкупаемости заказов.

Создавая систему доставки, в М.Видео‑Эльдорадо понимали, что если клиент получит в заказе витринный образец, то будет недоволен. Поэтому постарались свести количество таких случаев к минимуму: в первую очередь брали для заказов те складские остатки, которых больше указанных витринных образцов.

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

Проанализировали все заказы. Оказалось, что доля с витринными образцами гораздо выше ожидаемой: 5% вместо 0,5%. Начали изучать, какие сценарии приводят к отменам заказов, а какие — к выкупам. Заметили, что если колл‑центр менял магазин выдачи, чтобы клиент получил не витринные образцы, а новые товары, то выкупаемость сильно повышалась. Но процесс работы с такими заказами был усложнён, многие магазины не успевали их обрабатывать и люди отменяли заказы.

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

В каких‑то случаях длительность доставки могла возрасти, но это сочли небольшой платой. Выкупаемость заказов с витринными образцами выросла на 70%, а общая выкупаемость заказов — на 2,2%.

Интеграция процессной аналитики

Чтобы извлечь максимум пользы из этой методики, нужно много данных. Когда заказчик только начинал внедрять процессную аналитику, поставили сложную задачу: обновлять данные по заказам раз в пять минут. Звучит просто, если не учитывать объёмы: ежедневно один миллион активностей (всего 200 млн), 200 000 ежедневно обновляемых сценариев (всего 10 млн).

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

Поскольку загружать вышеописанные объёмы надо было раз в пять минут, нельзя было постоянно обращаться к какому‑то хранилищу. Данные есть только в промышленном контуре, и днём в него заходить нежелательно.

Другая сложность — источником данных является SAP CRM, имеющая очень сложную структуру базы данных, около 40 таблиц. И некоторые из них огромные. Это таблицы истории изменений, хранящие информацию по всем заказам и объектам в системе за несколько лет. Ещё есть очень большие справочники. Если обращаться в промышленную систему раз в пять минут, то одно лишь представление генерировалось бы минут 15, при этом система не могла бы работать.

Ещё одна трудность: заказчик хранил историю изменения не всех интересующих его атрибутов.

Начали продумывать возможное решение общей задачи. Сделали небольшую доработку в системе М.Видео‑Эльдорадо: когда происходит какое‑либо изменение в заказе, создаётся его полный слепок и отправляется в Kafka.

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

Получаемые Kafka слепки извлекали ETL‑решением — Pentaho. Это очень мощный инструмент, позволяющий разложить весь заказ на позиции. С его же помощью складывают все данные во временное хранилище на случай, если загрузка данных прервётся.

В Pentaho хотели сравнивать предыдущее состояние заказа с текущим, чтобы получать изменения необходимых нам полей: статусов, сумм, адреса доставки. Но получалось очень долго, потому что надо было получить данные из Kafka, потом получить старые заказы из базы данных. Минут 20 уходило на обработку 1000 заказов. Тогда решили формировать историю изменений на уровне БД. В качестве промежуточной базы данных использовали Postgres. В нём есть механизм триггера: он срабатывает, когда вставляют или обновляют какие‑то данные, сравнивает текущее состояние заказа со старым по интересующим полям и формирует историю изменений. И всё это очень быстро.

Советы бывалых

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

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

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

• В компании на этапе начала внедрения процессной аналитики уже должен быть заинтересованный сотрудник, который готов потреблять результат. Конкретный человек, а не роль, отдел или подразделение. Он должен быть очень энергичный, мотивированный. Знающий, зачем ему всё это нужно. Иначе проект будет внедрением ради внедрения, результатами пользоваться никто не будет.

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

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

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