Привет! Меня зовут Илья, я работаю в PIX Robotics больше 2 лет, и за это время мне удалось поучаствовать во многих проектах по внедрению технологий RPA и Task Mining, на которых я выступал сначала в качестве аналитика, а далее в качестве руководителя проекта. Проекты интересные, масштабные (может, расскажу о каких‑то в будущем), но, имея определенные познания и в анализе процессов, и в анализе данных, мне хотелось попробовать совместить эти две дисциплины в рамках одного проекта. И, благодаря запуску собственного решения класса Process Mining — PIX Аналитик процессов — такая возможность выпала очень скоро, в рамках проекта по анализу процесса продаж в нашей собственной компании, о котором и пойдет речь в этой статье.
Предпосылки проекта
Мы — компания PIX Robotics — помогаем сотням компаний повышать их операционную эффективность с помощью наших решений. Наша команда имеет большой опыт в роботизации бизнес‑процессов, но в то время проекты по процессному анализу были для нас в новинку. И, хотя мы работаем с партнёрами‑консультантами и интеграторами с многолетним опытом и глубокой экспертизой в Process Mining, нашей внутренней команде также было необходимо нарастить экспертизу, чтобы более эффективно проводить пресейл и развивать наш продукт.
А как быстрее всего научиться и получить обратную связь? Конечно, провести внутренний проект на одном из наших собственных процессов. Причем таком, который существенно влияет на всю компанию, а именно — сквозном процессе от регистрации лида до завершения сделки. Так мы получаем три в одном:
можем убедиться в работоспособности нашего продукта «на собственной шкуре»;
развиваем внутреннюю экспертизу в технологии Process Mining;
показываем ценность продукта внутри компании PIX тем, кто его непосредственно будет продвигать «в массы»: маркетинг и продажи.
Прежде чем углубляться в сам проект, давайте разберем, что такое Process Mining? Если кратко: это технология, которая восстанавливает цифровую модель процесса на основе логов из информационных систем. Эта модель отражает фактическое течение процесса, а не то, как он прописан в регламентах. И с ее помощью можно анализировать процесс в различных разрезах, находить скрытые связи, отклонения и, как следствие, возможности для улучшения.
Ход проекта
Шаг 1. Погружение в проблему
Прежде чем что‑то анализировать, нужно понять, как это работает.
В нашей компании лид проходит по воронке продаж следующим образом:
Лиды поступают из различных источников (веб‑сайт, мероприятия, почта, партнерский канал и т. д.), заводятся в СRM систему в автоматическом или ручном режиме и далее проходят валидацию и обработку сотрудниками отдела развития бизнеса (у нас они называются BDR). Если лид нецелевой или некачественный, то он дисквалифицируется, если же представляет интерес, то проходит необходимую квалификацию, в итоге которой создается потенциальная сделка. Сделку ведет выделенный аккаунт менеджер: проводится установочная встреча, по итогам которой Сделка переходит на стадию пресейла, затем коммита и финально — контрактования.
Чтобы понять потенциально узкие места, мы собрали обратную связь от бизнес-заказчиков проекта: отделов маркетинга и продаж.
Ключевой запрос маркетинга был связан с отсутствием прозрачности в процессе обработки лидов. Несмотря на действующий регламент, прописанные SLA не обеспечивали своевременного взаимодействия и быстрой реакции, что негативно влияло на управление воронкой.
Для отдела продаж также было важно выявить «узкие места» в воронке и понять, как усилить процесс и повысить его эффективность.
Здесь может возникнуть вопрос: у вас же есть CRM, которая фиксирует все этапы сделки, почему этой информации недостаточно? А я еще добавлю, что у нас также есть дашборды в PIX BI, где фиксируются все метрики. Так зачем подключать PIX Аналитик процессов?
Дело в том, что существующие инструменты — CRM и BI‑система — фиксируют итоговые метрики, такие как общее число лидов и конверсию в продажу, но не дают глубинного понимания процесса:
Сколько времени занимает путь от создания лида до закрытия сделки?
На каких этапах возникают задержки?
Как эффективность обработки зависит от канала привлечения?
На эти вопросы нам и предстояло найти ответ.
Шаг 2. Подготовка данных
Проект по внедрению технологии Process Mining начинается с восстановления фактической модели процесса на основе логов из информационных систем, в которых он протекает. В нашем случае процесс практически полностью протекал в CRM. В процессе было 2 ключевых объекта, по которым велось логирование: лид и сделка.
Мы получили выгрузки логов по обоим объектам, в которых отражались изменения статусов в воронке по обоим объектам. И здесь мы столкнулись с одной из стандартных проблем при проведении проекта с Process Mining — между нашими двумя объектами отсутствовал сквозной идентификатор.
В нашем случае проблему удалось решить достаточно просто: и к лиду, и к сделке, обязательно должна быть привязана компания‑клиент, которая является отдельной сущностью в системе. По ID компании клиента нам удалось связать таблицы по двум объектам, избежав потерь в данных. К сожалению, так бывает не всегда. Например, при отсутствии уникального ключа приходится искать альтернативные решения: связывать таблицы по косвенным данным (например, по дате) или формировать уникальный композитный ключ из нескольких полей (таких как дата, ФИО и сумма). В данной ситуации подобные действия не потребовались.
В результате у нас получился готовый сквозной журнал событий по процессу.
Что из себя представляет журнал событий в Аналитике процессов? Это таблица, в которой собраны история событий по всем экземплярам процесса за определенный период, атрибуты событий и атрибуты экземпляров.
Здесь мы столкнулись с проблемой, которую, увы, не удалось обойти — ограниченное логирование событий в CRM. Поскольку Process Mining работает с теми данными, которые фиксируются в системе, зачастую их оказывается недостаточно для решения аналитических задач. Поэтому приходится работать с тем, что есть.
В нашей CRM логировались только события, связанные с изменением статуса карточки (сделки/лида) в воронке. То есть переход сделки из статуса «пресейл» в «контрактование» можно было легко отследить. Однако многие события с важным для процесса контекстом (например, подключение к сделке специалиста пресейла) выражались в виде заполнения одного из полей в карточке. Такие события в системе не логировались, поэтому отследить их было невозможно.
Реализация логирования таких событий путём доработки CRM и стало первой рекомендацией по улучшению процесса, поскольку это было необходимо для полноценной аналитики.
В любом случае, дата‑сет был готов, модель процесса построена и мы приступили к её анализу.
Шаг 3. Анализ процесса
В проектах по анализу процессов не всегда понятно, что нужно искать. В принципе, это логично, потому что если бы мы знали (и были уверены), где есть проблема, то никакой Process Mining нам бы не был нужен. Так что в анализе мы руководствовались собственными идеями и здравым смыслом. Первая идея, которая у нас возникла: сравнить, как протекают успешные и проваленные сделки, чтобы выявить возможные закономерности.
Для анализа маршрута протекания процесса мы использовали Граф.
Граф процесса – классическая составляющая любого решения класса Process Mining. Он отражает путь каждого экземпляра процесса на одной визуализации. Как выглядел граф нашего процесса (с сильно анонимизированными данными) можно увидеть ниже.
Фильтруя граф, мы подробно изучили как протекают успешные сделки. Далее сравнили с тем, как протекают проваленные.
Результаты поразили наше воображение: закономерностей по маршруту прохождения процесса и её успешностью обнаружено не было :(
При этом мы заметили, что степень превышения SLA напрямую коррелирует с шансом, что сделка окажется проваленной. То есть, соблюдение SLA сейлом повышает шансы на то, что сделка закроется успешно и принесёт компании деньги. Иными словами, SLA работают.
Так что мы стали копать глубже и изучать метрики SLA по каждому шагу бизнес‑процесса. И тут мы увидели, что только треть лидов проходит квалификацию в рамках установленного SLA.
Как решение выбрали реализовать автоматизированную систему мониторинга соблюдения SLA по лидам и сделкам, с оповещением руководителя ответственного сейла либо BDR‑а. А чтобы у ответственных не было искушения передвинуть карточку назад в воронке, чтобы не нарушить SLA, мы заботливо предложили требовать для этого права администратора:)
Мы продолжили наши изыскания в анализе. Лиды в компанию приходят по различным каналам: из личных активностей сейлов, от компаний‑партнёров, с различных мероприятий, с вебсайта и др. С помощью PIX Аналитик процессов мы смогли быстро понять, какой канал приносит больше всего лидов, какие лиды имеют самую высокую конверсию и сумму сделки и на каких этапах случаются «отвалы». Что интересно — канал, который, казалось бы, приносил меньше всех лидов (4%), при этом давал наибольшую среднюю конверсию до успешной сделки, как и наибольшую среднюю сумму сделки. Также мы сделали много наблюдений, которые касаются эффективности участников сделки: сейлов, пресейлов, BDR-ов.
Многие из этих выводов не стали сюрпризом для наших бизнес-заказчиков. Однако, во-первых, подтвердили их гипотезы, что помогло быстрее вносить изменения в процессы и проводить новые мероприятия для генерации лидов и продаж. Во-вторых, анализ с помощью технологии process mining оказался гораздо быстрее, чем ранее эти гипотезы строились вручную или в полуавтоматическом режиме.
Заключение
Итак, проект занял один месяц, с учётом работы над ним в свободное от от клиентских активностей время.
За это время мы:
погрузились во все нюансы технологии Process Mining и научились быстро и эффективно пилотировать наше решение
нашли узкие места в реальном бизнес‑процессе компании, подтвердили часть гипотез коллег и инициировали реинжиниринг процесса с доработкой CRM
показали ценность технологии для самой суровой фокус‑группы — кто ежедневно общается с потенциальными клиентами
и, главное, доказали работоспособность нашего решения PIX Аналитик процессов.
Теперь мы планируем повторно применить технологию на нашем процессе, но в этот раз сделать не срез, а настроить постоянный мониторинг процесса, включая автоматический сбор, преобразование и обновление логов. Но это уже другая история.
