Сначала собираем будущую модель целиком
Когда мы начинаем проект внедрения CRM, одна из первых задач — понять не только то, что клиенту необходимо сегодня, но и то, к какой системе он в итоге хочет прийти.
Именно поэтому до начала настройки мы проектируем архитектуру. Разбираем процессы компании, движение клиента, роли сотрудников, точки передачи ответственности, автоматизацию, аналитику, интеграции. По сути, сначала собираем будущую модель системы целиком.
Это важно по довольно простой причине. Если не знать конечную точку, CRM очень быстро начинает развиваться по принципу «понадобилось — добавили».
Сегодня понадобилось новое поле — создали. Завтра новый процесс — сделали отдельную воронку. Через месяц потребовался отчет — начали думать, откуда брать данные. Потом появилась интеграция, но оказалось, что существующая структура CRM для нее вообще не подходит.
Каждое отдельное решение при этом может быть вполне разумным. Проблема становится заметна позже, когда из сотни правильных локальных решений складывается неправильная система.
Поэтому нам важно заранее видеть конечную архитектуру.
Архитектура — это гипотеза
Но здесь возникает другая крайность.
Если мы спроектировали большую целевую систему, это совершенно не означает, что ее нужно целиком настроить и в один прекрасный понедельник включить сотрудникам.
Потому что архитектура — это наша гипотеза о том, как должна работать система. Пусть очень подробная, основанная на обследовании, разговорах с сотрудниками и анализе процессов, но всё равно гипотеза.
А потом появляется реальная работа.
Менеджеры начинают заводить клиентов. Руководитель пытается пользоваться отчетами. Через CRM проходят первые нестандартные ситуации. Выясняется, что какое-то поле заполнять неудобно, где-то не хватает информации, какой-то предусмотренный нами сценарий возникает раз в полгода, а ситуация, которую все считали редкой, встречается каждый день.
И вот здесь начинается настоящее внедрение.
Минимально жизнеспособная рабочая модель
Поэтому после проектирования целевой архитектуры мы стараемся двигаться через минимально жизнеспособную рабочую модель.
Не урезанную CRM «лишь бы работало», а минимальный набор процессов, данных и правил, которого уже достаточно, чтобы сотрудники могли нормально работать и чтобы мы начали получать настоящую информацию о поведении системы.
Запускаем.
Смотрим, как она едет.
Где сотрудники тормозят. Где процесс проходит нормально. Где появляются обходные пути. Какие данные действительно нужны руководителю. Какие автоматизации снимают работу, а какие только добавляют лишние действия.
И только после этого начинаем накладывать на первоначальную архитектуру реальность.
В этом месте нам как раз близок подход непрерывного совершенствования процессов: небольшое изменение, проверка результата, данные и следующий шаг. Не менять систему потому, что «кажется, так будет удобнее», а проверять изменения реальной эксплуатацией.
Архитектура остается картой проекта
При этом первоначальная архитектура никуда не исчезает.
Она остается картой проекта.
Мы по-прежнему понимаем, какие процессы должны появиться дальше, какую аналитику хотим получить, какие интеграции понадобятся, какие данные для этого необходимо начать собирать уже сегодня.
И вот это особенно важно.
Если мы знаем, что через несколько этапов руководителю понадобится определенный отчет, мы уже на первой версии CRM можем правильно заложить данные для него. Если понимаем, что впереди интеграция с 1С, заранее строим сущности так, чтобы потом не переделывать половину системы. Если знаем, что после первой продажи появится отдельный процесс работы с постоянными клиентами, учитываем это еще при проектировании первой сделки.
Из будущего в настоящее, из настоящего в будущее
Получается довольно интересный принцип.
Мы строим систему из будущего в настоящее, а внедряем — из настоящего в будущее.
Сначала понимаем конечную модель. Затем определяем минимальную рабочую точку старта. Запускаем ее в реальную эксплуатацию и дальше постепенно двигаемся к целевой архитектуре, проверяя каждое следующее решение реальным бизнесом.
И архитектура при этом тоже не становится священным документом, который запрещено менять.
Если реальная эксплуатация показывает, что первоначальное решение было неверным или бизнес за это время изменился, архитектура должна измениться вместе с ним. В этом и заключается смысл подхода непрерывного совершенствования: система развивается не хаотично, а последовательными изменениями, каждое из которых можно проверить и оценить.
Не две крайности, а третий вариант
Наверное, поэтому мы не очень верим ни в один из двух крайних подходов.
Первый — «давайте сейчас что-нибудь настроим, а дальше разберемся». Так довольно быстро появляется CRM, состоящая из исторических наслоений.
Второй — попытаться заранее придумать идеальную систему на следующие пять лет и сразу реализовать ее целиком. Такая CRM рискует оказаться прекрасно спроектированной системой для бизнеса, которого в реальности никогда не существовало.
Нам ближе третий вариант.
Понимать, куда идем. Сделать работающий первый шаг. Посмотреть, что произошло. Скорректировать движение. Сделать следующий.
Как должна внедряться CRM
Наверное, именно так и должна внедряться CRM.
Не как одна большая настройка, после которой проект считается законченным, а как управляемое развитие системы в заранее понятном направлении.
Потому что наша задача в конечном итоге не в том, чтобы идеально реализовать нарисованную архитектуру.
Наша задача — чтобы в результате получилась система, которая действительно работает в реальном бизнесе.
