О клиенте

BestDoctor – это InsurTech-компания с собственной технологической IT-платформой и двумя экосистемами: «Здоровье» и «Страхование». В 2022 году компания привлекла раунд около 1 миллиарда рублей от группы российских инвесторов, став лидером инвестиций в российское цифровое здравоохранение. Стратегические партнеры BestDoctor: «Интеррос», Росбанк Страхование, Росбанк Страхование жизни.

Сайт: https://bestdoctor.ru/
Отрасль: страхование
Количество корпоративных клиентов: более 900

История

Рынок InsurTech и MedTech стремительно меняется. Так же быстро должны меняться и внутренние бизнес-процессы компании, если она хочет идти в ногу со временем. Если говорить о процессах продаж, то отделы продаж и андеррайтинга (андеррайтеры занимаются расчетом рисков и стоимости страховки) уже работали в amoCRM, а для автоматизации их работы использовалась система управления бизнес-процессами Camunda. К сожалению, эта система не позволяла быстро перестраивать и масштабировать процессы, а также тестировать новые гипотезы. Помимо этого пользователи время от времени могли сталкиваться с рядом проблем.

Технические проблемы в системе Camunda

• Масштабирование и изменение процессов требует больших вложений денег и времени. Даже на микроизменения может уходить от пяти дней.
• Смена статуса сделок осуществляется вручную. Бизнес-процессы выстроены на жестких ограничениях, поэтому в сделках нельзя автоматически менять статус на следующий, если не выполнены условия предыдущего.

Другие проблемы

• Риск блокировки в amoCRM: из-за нестабильной работы платформы и отсутствия балансировщика возможна блокировка от amoCRM, что приводит к остановке процессов.
• Трата времени на ручные операции, а не на полезное взаимодействие с клиентами: менеджеры использовали amoCRM как записную книжку, где приходилось вручную передвигать сделки по этапам, чтобы информация поступала другому отделу.
• Человеческий фактор: регулярные ошибки из-за недостаточной автоматизации.
• Двойная работа: приходилось дублировать заполнение информации о клиентах в amoCRM и в Яндекс.Таблице (техническое задание, скоринг и пр.).
• Отсутствие операционных метрик: аналитика велась только по бизнес-метрикам макроуровня напрямую из amoCRM, в то время как операционные метрики не собирали и не анализировали.

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

Таким образом, хотя до определенного момента система Camunda позволяла строить процессы, по мере развития бизнеса появилась необходимость в новых инструментах. Клиенту нужно было такое решение, которое позволит автоматизировать процессы с пользой для бизнеса, поэтому команда Интроверта предложила перестроить бизнес-процессы обоих отделов на базе BPM-платформы Sensei.

Что мы сделали

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

Чтобы учесть специфику клиента и не потерять текущие сделки в работе, внедрять проект решили на базе методологии «As Is – To Be». Рассмотрим подробнее этапы проекта по этой методологии. 

Этап 1. As Is: описание текущих бизнес-процессов

Шаг 1. Анализ текущих процессов с технической и логической точки зрения

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

Шаг 2. Проведение тестов в старой системе

Команда прогнала тестовые сделки в системе Camunda, чтобы посмотреть, как она работает, и выявила ряд ошибок.

Шаг 3. Интервью с руководителями подразделений

Опросили руководителей отделов продаж и андеррайтинга (андеррайтеры занимаются расчетом рисков и стоимости страховки). В ходе нескольких звонков уточнили логическую схему процессов: какие действия выполняются и в какой последовательности, когда общение с клиентами переходит из amoCRM в мессенджеры, какие данные отправляют в Excel и пр.

Шаг 4. Интервью с конечными пользователями

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

• Менеджеры занимаются не поточными, а экспертными продажами: вместо шаблонных рутинных действий они действуют каждый раз по-разному, исходя из своего понимания ситуации.
• В обработке сделок принимает участие большое количество лиц из разных отделов.
• Каждый отдел ведет свои сделки, т. е. по одному и тому же клиенту в системе могло быть несколько разных сделок от разных отделов.
• У каждого отдела – свой подход к работе в amoCRM и своя выверенная годами эффективная модель. В новом решении необходимо было сохранить эту модель и учесть особенности каждого отдела.

Важно: на этом этапе пожелания руководителей и менеджеров еще НЕ собираются. Здесь стоит другая цель: составить полную картину «здесь и сейчас».

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

Результат в Miro – схема, где зафиксировано следующее:

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

Блок-схема As Is в Miro

Шаг 5. Определение целевых департаментов

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

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

Шаг 6. Определение ключевых метрик

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

• Скорость взятия сделки в работу.
• Время нахождения сделки на каждом этапе.

Шаг 7. Формулирование цели проекта и составление плана работ

Совместно с клиентом мы зафиксировали цели проекта:

1. Создать с нуля и запустить важные процессы целевых отделов.
2. Актуализировать старые бизнес-процессы, существенно упростив их логику. Обеспечить возможность легкой и быстрой адаптации процессов к изменяющимся условиям.
3. Передать документацию и экспертизу IT-команде BestDoctor, чтобы она могла самостоятельно вносить изменения в процессы всего за 1 день.
4. Настроить сбор метрик из amoCRM в таблице с понятной визуализацией данных.
5. Не допустить блокировки или остановки процессов в ходе переноса ни на час.
6. Оптимизировать адаптацию и онбординг новых пользователей за счет расширенных форм, подсказок по заполнению полей, механизмов проверки, исключающих ошибки из-за человеческого фактора.

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

Пример диаграммы Ганта с этапами проекта и сроками выполнения работ

Этап 2. To Be: проектирование образа результата

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

Шаг 1. Определение операционных метрик департаментов

На этом этапе ввели новые операционные метрики для оценки работы менеджеров и согласовали подход к их интерпретации. По всем метрикам отрисовали дэшборды.

Пример дашборда с операционными метриками отдела

Шаг 2. Сбор требований к актуализации процессов

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

Шаг 3. Отрисовка схем в Miro и подготовка демо

Команда выстроила логику процессов продаж и согласовала ее с клиентом. Учли все пожелания клиента: где должна происходить автосмена статуса, где заполняются поля, какие ставятся задачи и с какими сроками и пр. После утверждения логики отрисовали и согласовали целевой макропроцесс To Be.

Далее команда построила демо-процессы продаж, продемонстрировала их тим-лидам и менеджерам, собрала обратную связь и внесла изменения еще ДО тестирования.

Результат в Miro – схема, где указано следующее:

• спроектированный новый макропроцесс «Продажи»;
• согласованные с клиентом ключевые метрики и подход к их сбору;
• адаптированные и полностью новые воронки;
• подпроцессы: быстрые победы, которые за короткий срок дают положительный прирост по метрикам.

Блок-схема To Be в Miro

Этап 3. Тестирование и пуско-наладка

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

Шаг 1. Отстройка эталонного макропроцесса продаж

При помощи конструктора бизнес-процессов в визуальном редакторе Sensei создали эталонный макропроцесс продаж в виде понятной блок-схемы. В схеме описали все возможные сценарии прохождения сделки по воронке. 

Шаг 2. Определение плана тестирования

Для успешного тестирования процессов важно подготовить хороший план с указанием основных этапов и сроков:

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

Подготовка к запуску должна быть тщательно продумана, поэтому на этот этап проекта изначально заложили больше двух недель.

Шаг 3. Создание фокус-группы и проведение тренинга для менеджеров

Важный этап в методологии запуска решения – создание фокус-группы. Это необходимо для обкатки новых процессов на выделенной части сотрудников и сбора первых метрик. Состав и профиль фокус-группы для тестирования процесса и сбора обратной связи выглядел так:

• Два опытных менеджера отдела продаж.
• Два новых менеджера отдела продаж.
• Все специалисты по поддержке продаж.

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

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

Шаг 4. Запуск теста

После проведения обучения участники фокус-группы приступили к работе с новым макропроцессом «Продажи». Для получения чистого результата на протяжении месяца фокус-группа работала параллельно и с платформой Sensei, и с платформой Camunda. Таким образом, сравнивались именно системы, а не менеджеры. Вся обратная связь оперативно бралась в работу: устранение ошибок и улучшение процесса реализовывались в течение одного дня.

Важно: На протяжении всего проекта аналитики проектной команды тесно взаимодействовали с IT-отделом BestDoctor для передачи компетенций, обмена опытом и решения возникающих проблем.

По окончании этапа клиент получил следующие результаты работ:

• обучающие видео по работе с процессами каждого отдела;
• текстовые инструкции по процессам;
• документация по внедренным кастомным решениям;
• схемы в Miro с подробным описанием всех выстроенных процессов.

Быстрые победы

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

Приоритизация сделок. Для визуализации приоритета сделок и определения дедлайна для взятия сделок в работу менеджером создали подпроцесс по типу «Светофор». Все создаваемые сделки проверяются по заранее установленным критериям для определения срочности их обработки. Например: красный цвет – горячий клиент, дедлайн для взятия в работу – два часа. Желтый цвет – средняя срочность, срок – неделя. Голубой цвет – холодный клиент, срок – 30 дней.

Приоритизация сделок «Светофор»

Контроль зависания сделки (время нахождения на этапе). Одна из причин упущения сделок – потеря коммуникации с клиентом. Для минимизации этого риска установили лимит времени нахождения сделки на разных этапах. Так, для взятых в работу сделок на этапе квалификации клиента определили лимит 7 дней с даты последней коммуникации. Это отличный инструмент контроля зависания сделки: когда сделка приближается к нарушению установленного лимита, менеджер по продажам (а на следующий день и тим-лид) получает уведомление.

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

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

Мелочь, а приятно

Любой переход на новую систему – это стресс для сотрудников. Порой предлагаемые изменения саботируются, так как работники видят в них скорее угрозу. Однако проектной команде удалось заручиться поддержкой менеджеров клиента благодаря тому, что она сделала немного больше, чем от нее ожидалось: простые доработки, которые даже не входили в объем проекта, существенно облегчили жизнь сотрудникам.

Аналитики заметили, что менеджеры регулярно заполняют скоринг в Яндекс.Таблицах, а для этого вручную переносят информацию из полей, ранее заполненных в amoCRM. В результате такой неавтоматизированной двойной работы какие-то данные теряются, какие-то искажаются. Команда решила разработать кастомное решение, чтобы перенести заполнение скоринга в amoCRM, упростив таким образом работу менеджеров и минимизировав человеческий фактор. Сотрудникам не только облегчили работу, но и предложили выбрать наиболее комфортное цветовое оформление новой формы. Победила фуксия:) 

Что может пойти не так

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

• необходимость вносить корректировки в процессы в ходе тестирования на фокус-группе на базе полученной обратной связи;
• отпуск руководителей и сотрудников клиента: на старте обязательно нужно уточнить график отпусков для правильного планирования встреч по «As Is – To Be» и обучению;
• необходимость кастомных доработок ввиду особенностей функционала клиентских систем.

Не обошлось без сложностей и на проекте с BestDoctor.

Большое число заинтересованных лиц. Текущие и целевые процессы приходилось уточнять и согласовывать с большим количеством сотрудников из разных отделов. На индивидуальных встречах каждый со своей стороны дополнял общую картину. Это крайне полезно для детальной проработки As Is и To Be, но требует много времени. 

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

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

Результаты

Коротко о тех результатах, которых нам удалось добиться в рамках проекта:

• Всего за три месяца разработали 53 процесса (47 процессов по работе менеджеров, 6 – по сбору метрик).
• Собрали аналитику в дэшбордах: по ключевым показателям зафиксирован рост.
• Запустили 3 подпроцесса, давших эффект в короткий срок («Быстрые победы»). 
• Не допустили ни одного падения системы Sensei благодаря функции Smart Balancer, которая позволяет самостоятельно снизить нагрузку на сервер и ускорить работу процессов.

А теперь давайте подробнее разберем эти результаты.

Результат по метрикам
Налажен сбор ключевых и операционных метрик в таблицы и их визуализация. Улучшения по ключевым метрикам к окончанию проекта:

• Сделки берутся в работу на 67% быстрее.
• Сделки в среднем проводят на каждом этапе на 17% меньше времени.

Для бизнеса

• Сокращение затрат на поддержку системы управления бизнес-процессами благодаря альтернативному инструменту в лице Sensei.
• Сокращение срока реализации решений, а соответственно и бюджета на эти работы.
• Получение доступа к достоверной аналитике для принятия информированных бизнес-решений.
• Появление возможности быстро тестировать различные гипотезы.

Для руководителей
Руководители получили новые инструменты контроля:

• Таблица, в которой четко видны упущения по менеджерам и этапам.
• Уведомления, если сотрудник закрыл сделку с критичной причиной отказа.
• Задача на проверку не критичного, но важного отказа. По критичным причинам настроены специальные уведомления (см. пункт выше), а по важным причинам ставится задача. Неважные причины не проверяются.
• Визуализация приоритизации сделок в amoCRM.

Для продавцов

• Переход на платформу Sensei существенно упростил работу для менеджеров отделов. Теперь менеджер выполняет свои задачи и заносит информацию в формы, а дальше работает уже система: двигает сделки по этапам, создает дочерние сделки, рассчитывает технические поля, переносит данные в связанные сделки, передает запросы в другие отделы и возвращает ответ. 
• Все отделы работают по процессам с контекстными задачами и вариантами выполнения, запусками определенных сценариев. 
• Настроены механики напоминаний о встречах и специальные уведомления, благодаря которым ускоряется переход к переговорам с клиентами и сокращается срок нахождения сделки на этапе расчета.
• Сотрудники тратят гораздо меньше времени и ресурсов на скоринг благодаря кастомным доработкам для рабочих процессов (нотификация Mattermost, хук для отправки информации в Яндекс.Таблицы, перенос скоринга для расчета коммерческих предложений в amoCRM, изменение вида расширенной формы).
• Пользователь получает верхнеуровневое представление о своей воронке благодаря наглядной визуализации приоритетов и расчету скоринга.