Перевод 120 человек на одну CRM: первый год

Миграция CRM выглядит как программный проект. К третьему месяцу я уже понимал, что это поведенческий проект, в котором софт стоит посередине.

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

Запрос от COO звучал просто: одна система-источник правды до конца года. Первые 90 дней показали, что слово «просто» здесь лишнее.

Почему Bitrix24, а не «лучшие в каждой нише»

Серьёзно рассматривали три варианта: оставить три инструмента и склеить их интеграциями, переехать на amoCRM как операционное ядро или взять Bitrix24. У amoCRM сильнее воронка продаж и слабее рабочие процессы; у Bitrix24 шире поверхность процессов и слабее аналитика. Я был против интеграции по двум причинам.

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

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

Взяли Bitrix24. Из коробки покрылось примерно 80% всех трёх потоков. Оставшиеся 20%, особенно медтех-приём и работу с рецептами, мы достроили кастомными модулями.

Три волны, а не одним рывком

Мигрировали по доменам, не по гео и не по отделам. Порядок был осознанный:

Клиент-источник правды: кто, где, что покупал.
Жизненный цикл заказа: как заявка превращается в исполненный результат.
Клинические и пост-продажные точки: рецепты, гарантии, последующие действия.

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

Структура волн ещё и сделала каждый шаг обратимым. На пятницу четвёртой недели первой волны ежедневный отчёт коммерции из Bitrix не сошёлся с легаси. COO эскалировал к 21:00. За 90 минут откатились на легаси, и Маша, наш руководитель розничной операционки, отвела субботние смены на старом инструменте. К утру понедельника нашли причину: соединение в миграционном скрипте исключало заказы с флагом «демо», который в проде использовался по делу. Починили, прокатились, к вторнику снова на Bitrix. Мигрировали бы все три потока разом, тот же баг положил бы всю компанию на выходные.

Где я сжёг шесть недель

Одну ошибку запишу.

Модуль медтех-приёма мы переписывали дважды за первый год. Первая версия делалась по клиническому процессу, который мы задокументировали на второй неделе. В проде оказалось, что региональные клиники работают по четырём вариантам этого процесса, и вариация была критичной для комплаенса. Первая версия принуждала к одному варианту. Региональный медицинский руководитель отказался подписывать релиз на 16-й неделе. Пришлось переписывать с нуля на 18-24 неделе, параллельно с третьей волной.

Шесть недель работы инженеров, реальная стоимость. Урок скучный и важный: когда у домена есть регуляторная вариативность, полевое исследование не опционально. Я отнёсся к нему как к опциональному, потому что COO хотел к концу года, и за это команде должен. Извинился письменно на ретроспективе в декабре. Это поменяло оценку объёма третьей волны и план на второй год.

Чем стала система

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

Задачи, последующие действия, клинические напоминания: не отдельный таск-трекер. Записи в CRM, привязанные к аккаунту, видимые ответственному, и менеджерские дашборды строились на том же представлении, только с другим срезом.
Внутренние инструменты, которые мы построили (админка лояльности, процесс возвратов, эскалации) писали в Bitrix, а не в боковую базу. Второй источник правды мы целенаправленно не плодили.
Цикл «заказ-доставлено» упал с медианных 36 часов (три системы со склейкой) до 11 часов (единый процесс), измерено на одном и том же ассортименте товаров в феврале и в октябре.

Дашбордов получилось 60+. Это не предмет гордости, это шрам. С шестого по девятый месяц мы построили лишних: команда наконец увидела данные и расходилась. Около 20 во второй год удалили: никто не открывал.

Что было в понедельник после

В понедельник после закрытия третьей волны я сел с Машей и Полиной, и за одну сессию мы убили 14 дашбордов. Полина, два года склеивавшая отчёты по пятницам, ушла на сеньорную аналитическую роль внутри новой структуры. COO вернул себе пятничные вечера. Я получил аналитика, встроенного в инженерную команду со второго года. Это то, что я должен был сделать на первой неделе.

Это и есть настоящий конец консолидации CRM. Не дата миграции, не диаграмма архитектуры. Понедельник, когда люди, которые раньше воевали с системой, перестают воевать.