Как глубокая кастомизация Битрикс стала риском для проекта

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

Меня зовут Алексей Постригайло, я старший партнер ИТ-интегратора "Энсайн". В статье разберу проект CRM для сети СТО, который мы развивали около 5 лет, а затем вынужденно сократили до более простого решения.

От отраслевой CRM к единой платформе

Разработка началась в 2018 году. За основу взяли коробочный Битрикс, но стандартной конфигурации было недостаточно.

Заказчику требовалась система, которая объединит работу станций, взаимодействие с автомобилистами и контроль всей сети. CRM связали с сайтом и мобильным приложением. Данные между ними обновлялись в реальном времени.

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

Система автоматически формировала документы, управляла расписанием мастеров, отправляла уведомления и помогала учитывать запчасти. Для сотрудников были предусмотрены разные роли и рабочие пространства.

В мобильном приложении клиент видел историю обслуживания автомобиля. Данные связывались с номером телефона и VIN-кодом. История сохранялась при смене владельца и была доступна сотрудникам другой станции сети.

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

Функционально система закрывала весь путь от записи клиента до анализа результата. Но между технической моделью и реальной работой сети возник разрыв.

CRM давала станции клиента, но не управляла дальнейшим процессом

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

На уровне конкретной станции задача была решена: новый клиент получен. На уровне сети заявка исчезала из общей воронки.

Заказчик не видел, приехал ли автомобилист, какие работы были выполнены и чем завершилось обращение. Аналитика становилась неполной, хотя исходные данные о заявке в CRM присутствовали.

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

Работа с обращением внутри CRM не была обязательным договорным условием. Она также не была жестко связана с показателями станции.

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

Внедрение в партнерской сети начинается с организационной модели

До разработки нужно определить не только пользовательские сценарии. Необходимо зафиксировать, какие данные партнер обязан внести, кто проверяет их полноту и что происходит при нарушении процесса.

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

Новая CRM конкурирует не только с другими системами. Она конкурирует с устоявшимся процессом.

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

В нашем проекте мы спроектировали сильный цифровой продукт, но недооценили необходимость организационно закрепить его использование.

Кастомизация решила текущие задачи, но усложнила обновления

Вторая проблема проявилась позже.

За несколько лет в Битрикс добавили большое количество специализированной логики. Система соответствовала процессам заказчика, но все сильнее отходила от стандартной платформы.

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

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

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

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

Экономика проекта изменилась. Вопрос уже звучал не как "можно ли сохранить CRM", а как "оправдывает ли действующий функционал стоимость полной переработки".

Почему мы предложили сократить систему

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

Мы предложили более простое решение: личный кабинет для СТО на базе административной части сайта.

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

Новая модель соответствовала изменившимся требованиям и позволяла развивать проект без восстановления всей накопленной сложности.

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

Что нужно учитывать в похожих проектах

Первое: использование CRM должно быть частью бизнес-процесса. Обучение и удобный интерфейс не заменяют регламенты, ответственность и договорные условия.

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

Третье: архитектуру нужно проверять не только на текущие требования. Важно понимать, как система будет переходить на новые версии и соответствовать будущим требованиям безопасности.

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

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

Здесь я обычно пишу про проекты, кейсы и ИТ-практику. А если хочется увидеть меня не только в рабочих текстах - приходите в мой тг https://t.me/alekseypostrigaylo. Там - сын, поездки, работа за кадром, личные наблюдения и попытка жить так, чтобы было что вспомнить.