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