Предыстория

В 2018 году мы начали разрабатывать CRM-систему, заточенную под сеть СТО. Разработка была масштабна, а цели — амбициозны: мы стремились учесть потребности всех участников процесса. Над проектом работали аналитики, программисты, тестировщики, настройщики Битрикс, дизайнеры и др. специалисты. Кроме того, работа продолжалась и после сдачи проекта. Я сейчас не только о поддержке системы — мы продолжали непрерывно улучшать ее, добавляли новые фичи, оптимизировали процессы.

И всё же, начав «за здравие», через 5 лет, в 2022 году, мы с заказчиком подошли к финалу известной поговорки. Эта статья про то, почему так получилось и какие уроки мы извлекли из этой истории.

Меня зовут Алексей Постригайло. Моя компания специализируется на системной интеграции и имеет 20-летний опыт реализации крупных проектов. В своих статьях я рассказываю о «закулисах» наших проектов.

Суть проекта

На старте проекта мы провели глубокий анализ потребностей всех заинтересованных сторон, смоделировали user-flow и выявили ключевые проблемы для каждого типа пользователей: автомобилистов, мастеров СТО, владельцев сервисов и представителей Заказчика. Проанализировав рынок CRM систем, мы пришли к выводу, что готовых полноценных решений для автосервисов нет — поэтому мы с заказчиком стартовали с чистого листа. За основу решили взять коробочный Битрикс.

Создавая специализированную CRM, мы моделировали идеальные сценарии работы и ставили конкретные вопросы типа «Что нужно владельцу СТО в момент приема клиента? Как мастеру быстро внести данные после ремонта?» Разработку и улучшение системы вели буквально «на лету», по классическому скраму: двухнедельными спринтами наращивали функционал и  регулярно анализировали обратную связь от заказчика.

Готовая система соответствовала запросам всех пользователей. Для клиентов функционировал сайт с современным дизайном и удобным интерфейсом: перечень услуг, цены, карта СТО, форма записи на ТО — все в одном месте. В дополнение к сайту мы разработали мобильное приложение для автомобилистов (о нем ниже). Для сотрудников СТО и представителей заказчика это была огромная кастомизированная CRM система с иерархией ролей, автоматизированным документооборотом, складским модулем для учета запчастей и расходников и другими кастомными функциями. CRM была полностью интегрирована с сайтом и мобильным приложением: обновление данных происходило в режиме реального времени.

Наше стремление создать “идеальную” CRM привело к тому, что от исходного Битрикса буквально осталось одно название — настолько много мы добавили кастомных модулей и функций.

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

По СТО

Автоматизация обработки заявок и документооборота

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

Мы также добавили инструменты для стандартизации отчетности — документы автоматически формировались по шаблонам. По нажатию кнопки генерировались акты, счета-фактуры и договоры, куда подтягивались данные клиента и реквизиты, занесенные в карточку СТО. Мы упростили процесс до двух кликов мышью: “Сформировать” → “Печать”. На выходе сотрудник получал нужную форму документа со всеми заполненными данными.

Иерархия ролей в системе

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

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

Многоканальный прием заявок

Мы стремились охватить все возможные сценарии взаимодействия с клиентами: автомобилисты могли записаться на ТО как при личном визите, так и через форму на сайте, мобильное приложение, горячую линию (где также можно было заказать обратный звонок и получить консультацию). Для таких сценариев потребовалась интеграция со смежными сервисами. В частности, мы добавили телефонию, чтобы звонки по умолчанию фиксировались в Битрикс, и полностью автоматизировали отправку e-mail и SMS-уведомлений с помощью роботов в карточках заявки и заказ-наряда.

Централизованная система учета запчастей и расходников

При первом приближении казалось очевидным решение на базе 1С, но, изучив процессы глубже, мы столкнулись с их разнородностью у разных СТО (кто-то уже использовал 1С, кто-то — другие системы, в т.ч. самописные). Тогда мы предложили другое решение: доработать штатный складской модуль в CRM. При этом подходе СТО могло интегрироваться как с системами заказчика, так и с уже используемыми в СТО решениями через API. Плюс мы избавляли заказчика от затрат на переобучение персонала и дополнительные лицензии 1С.

Обучение сотрудников работе в системе

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

По автомобилистам

Поскольку я сам автомобилист, на старте проекта я настоял на принципе: «Вся история ТО должна быть в одном месте».

В этом ключе мы и делали все кастомизации: владелец видел в мобильном приложении всю историю обслуживания своего авто, независимо от того, в каком именно СТО сети он обслуживался. Кроме того, система учитывала текущий пробег и автоматически формировала персонализированные рекомендации по следующему ТО. Наконец, в приложении можно было оперативно записаться на сервис, планировать визиты и отслеживать статус текущего заказа-наряда. Автомобилисты также получали SMS-уведомления о предстоящем ТО или о готовности автомобиля.

«Но и это еще не всё» (с). Мы сделали двойную привязку данных: к номеру телефона клиента и к VIN-коду автомобиля. Это позволяло при продаже автомобиля сохранять историю его обслуживания — новый владелец получал прозрачную картину всех проведенных работ. Сейчас таким уже мало кого удивишь, но шесть лет назад такой подход считался довольно инновационным.

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

По Заказчику

Для представителей Заказчика мы создали административный модуль с детализированными дашбордами, которые агрегировали данные по всем СТО сети в режиме реального времени. Система включала воронки конверсии заявок, KPI эффективности мастеров (время выполнения работ, количество обслуженных клиентов) и финансовые метрики по каждому сервису (средний чек, маржинальность услуг, динамика выручки).

Для оперативного реагирования на события в региональных СТО мы разработали многоуровневую систему уведомлений. Уведомления автоматически поступали при "зависших" заявках, а интеграция с телефонией позволяла дистанционно отслеживать качество обслуживания через прослушивание звонков. Это давало заказчику инструменты для глубокого анализа эффективности работы сети: например, почему из 10 заявок только 2 конвертировались в лиды? как работали сотрудники? как общались с клиентами?

Барьеры

Несмотря на всю «красоту», которую мы «навели» в CRM, система сильно «сплющилась» при столкновении с внешними факторами, которые на момент разработки были не так очевидны.

Первой проблемой стала низкая вовлеченность СТО. Дело в том, что для СТО система была, скорее, дополнительной опцией, чем обязательным договорным условием. Многие СТО использовали ее как источник лидов, но по воронке эти лиды дальше не проходили (т.е. в CRM их не было видно). Так мы сделали для себя вывод: даже идеальную систему нужно хотя бы немного организационно поддержать — прописать в регламентах, KPI или договорных обязательствах (остальные выводы - ниже).

Вторая проблема — в 2022 году у заказчика резко ужесточились внутренние регламенты ИБ. По новым требованиям предполагалось мгновенное внедрение всех обновлений используемого ПО. Это безусловно правильный подход, но есть нюанс — как я уже писал выше, мы с заказчиком настолько закастомизировали Битрикс, что исключили любую возможность безболезненно обновлять его  до последней версии.

Как быть? Перебрали разные варианты, и однозначно выходило, что для переезда в защищенный контур придется перерабатывать большую часть кастомизированных компонентов. Более того, переработка кода не гарантировала успешное прохождение внутренних проверок ИБ. Так или иначе, все это обошлось бы очень  дорого. Мы честно сообщили об этом заказчику и отметили, что считаем такой вариант решения нецелесообразным (хотя решать, конечно же, ему). Взамен мы предложили минималистичное решение — личный кабинет для СТО на базе админки сайта. Да, функционал будет сильно урезан — там не будет аналитики и сложных процессов, но зато требования ИБ будут соблюдены и проект продолжит развиваться.

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

Эпилог

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

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

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

  3. Не бросайте заказчика с проблемой наедине. Не больно немного «упасть» по заработку, больнее потерять доверие клиента.

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

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