Что делать, если один отдел компании работает в Битрикс24, другой – в 1С, а данные о клиентах хранятся в третьей сторонней системе? Очевидно, страдать и прикладывать все силы, чтобы информация была хотя бы немного актуальной. Компания «Кореана» устала терпеть такую рассинхронизацию и путаницу, терять заявки и тратить время своих сотрудников на ручную сверку данных. Она обратилась к нам – в студию разработки LABA – для настройки интеграции всех своих систем. Теперь данные обновляются мгновенно, процессы автоматизированы, а сотрудники могут сосредоточиться на главном – качественном взаимодействии с клиентами. В этом кейсе мы подробно расскажем, как мы этого добились.
О компании
«Кореана» более 25 лет поставляет запчасти и оказывает услуги для автомобилей корейского производства: Chevrolet, Hyundai, Kia, Daewoo, SsangYong. В каталоге множество оригинальных и аналоговых деталей, доступных через сеть из более чем 70 магазинов и интернет-магазин с доставкой в 100 городов России. Компания является официальным дистрибьютором таких брендов, как Mando, Parts-Mall, Luzar и KRAFTTECH. Она предлагает гарантию на запчасти и проводит обслуживание в собственных техцентрах в Санкт-Петербурге и Москве. СТО «Кореана» выполняют ремонт любой сложности, используя глубокие знания особенностей корейских марок и современное оборудование: диагностические стенды, подъемники и 3D-стенды для регулировки развала-схождения.
Специалисты компании применяют три разные системы для управления клиентами: 1С:Автосервис, Битрикс24 и единую базу клиентов на MySQL. Каждая из них решает свои задачи.
1С:Автосервис | Битрикс24 | Единая база клиентов (ЕБК) |
В этой системе работают механики. Они ведут здесь технологические карты, оформляют заказ-наряды и планируют свои рабочие процессы. Например, когда клиент пригоняет автомобиль на ремонт, механики заводят карточку с описанием необходимых работ, фиксируют время на выполнение задач, фиксируют статус ремонта. Система помогает контролировать складские остатки запчастей и вести учет расходных материалов. | CRM-система, которая помогает менеджерам управлять клиентскими обращениями. Битрикс24 позволяет хранить подробную историю взаимодействий с каждым клиентом: от первого звонка до закрытия сделки. Менеджеры могут отслеживать статус заявки на каждом этапе воронки продаж, контролировать выполнение задач, устанавливать напоминания и не пропускать важные моменты в общении с клиентом. | Это место, где хранится вся информация о клиентах: контактные данные, история покупок, информация о договорах и многое другое. Несмотря на это база данных не взаимодействовала напрямую с 1С:Автосервис и Битрикс24. |
Прямого обмена данными между этими системами не было, что приводило к проблемам:
Потеря заявок. Заявка могла быть зафиксирована в Битрикс24, но не отразиться в 1С, и наоборот. Это приводило приводит к путанице и недопониманию между отделами.
Медленный обмен данными. Менеджеры не видели, что происходит с клиентом после передачи запроса техникам, а те, в свою очередь, не знали всю историю обслуживания клиента. Все эти данные нужно было уточнять вручную, а это долго и трудозатратно.
Сложности с анализом клиентского пути. Из-за отсутствия синхронизации было трудно отследить, как клиент движется по воронке продаж и как обрабатывается его заявка на каждом этапе.
Еще одна частная проблема была связана с тем, как заполнялись заявки на ремонт в 1С. Например, вместо того чтобы указать конкретного сотрудника СТО, который отвечает за заявку, система часто записывала название подразделения, как будто это человек. Это путало и мешало понять, кто именно должен заниматься клиентом. Сама заявка могла быть создана не только мастером сервиса, но и автоматическими системами вроде колл-центра или АТС. Также в системе часто появлялись дубликаты сотрудников. Например, когда человек переходил работать в другое подразделение, на него создавали новую карточку, но старая оставалась в системе. Есть и сотрудники, которые числятся сразу на нескольких ролях, например, как администратор и как мастер СТО, что тоже создавало путаницу.
Чтобы компания могла работать эффективнее, нам необходимо было интегрировать все три системы. Частные сложности также требовали решения – и мы принялись за дело.
Решение: сначала в общих чертах
Перед тем как нагружать вас техническими деталями, расскажем простыми словами, какой подход мы выбрали.
Мы создали для «Кореаны» сквозную интеграцию между системами через шину данных Apache Kafka для обмена информацией в режиме реального времени. Она позволяет избегать задержек и потерь информации (в случае, если какая-либо из информационных систем отвалится), создавая единое информационное пространство.
И вот как работает вся система. Мы отслеживаем два типа события – добавление и обновление сделок (заявок) в 1С и Битрикс24. Когда происходит одно из этих событий, система актуализирует данные пользователя во всех системах с помощью брокера сообщений на базе Apache Kafka.
Обмен информацией организован на основе статусов сделок и является двусторонним:
Клиент звонит в компанию. Обращение фиксируется в Битрикс24, и система проверяет, является ли клиент новым или текущим, по единой базе клиентов. Если карточка клиента отсутствует, создается новый лид. Если карточка уже существует, она обновляется в соответствии с деталями обращения и помещается на нужный этап воронки в специальном виджете Битрикс24.
Клиент обращается напрямую в техцентр. В этом случае мастер создает в 1С:Автосервис карточку клиента, и срабатывает интеграция, которая мгновенно помещает клиента на соответствующий этап воронки в CRM Битрикс24.
Одно из главных преимуществ такой интеграции – защита данных. Если одна из трех систем выходит из строя, данные не теряются, а сохраняются в брокере сообщений и отправляются в сервис-адресат, как только он снова станет доступен. Например, если менеджер по продажам зарегистрировал клиента в Битрикс24, а 1С в это время «отвалилась», брокер сохранит данные и позже направит их в 1С.
Как это работает: к техническим деталям
Звучит не так уж сложно, да? Посмотрим, изменят ли это впечатление технические подробности. Чтобы вы не запутались, мы разбили описание работы на 2 больших этапа – подготовка и собственно интеграция.
Этап 1. Подготовка: исправили ошибки с ответственными в 1С
Помните проблему с ответственными, которую мы описывали в начале кейса? Ее нужно было решить первой, иначе вся система будет работать некорректно.
Вместе с клиентом мы составили функциональные требования, где четко определили, как должна выглядеть заявка на ремонт. Мы прописали, как должны заполняться проблемные поля «Автор», «Ответственный» и «Подразделение», чтобы больше не было путаницы, а также прописали логику связи между конкретными техцентрами и их телефонными номерами, по которым обращаются клиенты.
Кроме того, мы разработали логику интеграции данных о сотрудниках в 1С и Битрикс24:
Сопоставление сотрудников через таблицу данных. Когда в системе 1С появляется новый сотрудник, техподдержка добавляет в его карточку ID, полученный из Битрикс24, и наоборот.
Автоматическая привязка к подразделению. Следующая задача после сопоставления данных – корректно определить, в каком подразделении он числится. Для этого система подтягивает информацию из 1С, где указано, к какому отделу или подразделению принадлежит сотрудник. Эта информация автоматически передается в Битрикс24, чтобы данные о структурной принадлежности всегда оставались актуальными.
Затем мы составили операционные требования для интеграции, схему и логику работы всей системы в Miro, а после – техническое задание, и согласовали все с клиентом.
Пришло время реализовывать интеграцию!
Этап 2. Выстроили интеграцию: компоненты системы и их взаимодействие
Разберём поэтапно.
Брокер сообщений
В качестве основы мы использовали Apache Kafka по требованию клиента. Он способен обрабатывать миллионы сообщений в секунду, что важно для средних и крупных бизнесов сервисных услуг. Когда создается или изменяется заявка на ремонт, данные отправляются в Kafka, откуда их забирает другой компонент системы, и, если необходимо, возвращают их обратно в Kafka с изменениями или дополнениями.
Битрикс24 → 1С
В процессе обмена передаются следующие данные:
номер сделки;
источник трафика;
фамилия ответственного;
адрес подразделения;
номер клиента (UID);
направление бизнеса;
идентификатор сделки (ID).
Логика обмена данными такова:
Получение идентификаторов. Сначала запускается скрипт, который для всех существующих клиентов в Битрикс24 получает идентификаторы из единой базы клиентов и записывает их в поле EBKID в карточке клиента.
Поиск заявки. При получении запроса система ищет заявку (сделку) по UID. Если заявка не найдена, создается новая.
Добавление клиента. Если в теле запроса присутствует EBKID, то есть клиент не новый, система ищет клиента по нему. Если EBKID отсутствует, добавляется новый клиент.
Сопоставление статусов. Далее происходит сопоставление статусов сделки через таблицу соотношения, и нужный статус записывается в принимающей системе. Про это расскажем отдельно чуть ниже.
Избежание перезаписи. Если входящие данные совпадают с данными в системе, перезапись не происходит. Это помогает избежать ненужных изменений.
Этот алгоритм наглядно представлен на схеме ниже:
Сопоставление статусов сделки
Это очень важный пункт алгоритма. Вот как работает сопоставление:
мы создали простую таблицу соотношения статусов, так как они называются по-своему в 1С и Битрикс24;
при каждом изменении сделки мы сверяем статусы по таблице и записываем нужный в принимающей системе.
На обеих платформах таблица сопоставления реализована по-разному:
На стороне 1С используется регистр сведений – специальная таблица, которая позволяет хранить и обрабатывать данные, обеспечивая быстрый доступ к информации.
На стороне Битрикс24 реализована таблица с помощью highload-блока
1С → Битрикс24
В рамках этого обмена передаются следующие данные:
когда статус заявки на ремонт изменяется в 1С, новый статус автоматически отправляется в Битрикс24 и обновляет соответствующую карточку сделки. При этом карточка переходит на следующий этап воронки продаж;
также передается сумма из 1С в Битрикс24, что позволяет иметь актуальную информацию о сделках.
При получении запроса из 1С система Битрикс24 сначала ищет сделку по уникальному идентификатору UID. Если заявка не найдена, создается новая.
На стороне 1С при создании события записи происходит проверка измененных данных. Если изменения обнаружены (например, по статусу или клиенту), информация записывается в топик в Apache Kafka.
Очереди для неотправленных данных
Согласитесь, любой сервис может неожиданно выйти из строя, и это настоящая проблема, особенно когда на кону реальные клиенты и продажи.
Чтобы избежать потери информации в случае падения одного из компонентов системы, мы разработали механизм очередей для неотправленных данных. Если 1С или Битрикс24 вдруг перестанут работать, неотправленные данные записываются в специальный регистр. Для автоматизации этого процесса мы создали скрипты, которые запускаются по расписанию с помощью Cron – планировщика задач для Битрикс24 и регламентных заданий для 1С.
Говоря проще, если менеджер передал в автосервис новый лид, когда 1С не работает, данные попадают в Kafka, а когда система восстановится, она заберет эти данные и обновит их. Аналогично, если Битрикс24 упадет, менеджер не получит новые заявки сразу, но они не потеряются и будут ждать в очереди Kafka.
Не без сложностей: работа в условиях изменений
Возможно, вы удивитесь, но до этого мы не работали с Apache Kafka. Интеграция на основе этой системы обмена сообщениями, по нашему опыту, встречается на практике довольно редко. Как правило, бизнес обходится стандартными модулями для интеграции. Несмотря на это, у нас не возникло никаких серьезных проблем с Kafka, хотя наш разработчик начал все с нуля, без готовых шаблонов и библиотек. Такой подход даже имел мощное преимущество – позволил лучше понять, как устроена система и как ее можно адаптировать под наши нужды.
Небольшие сложности возникли в коммуникации с клиентом, однако и их мы обернули на пользу проекту. Изначально мы планировали простую интеграцию через вебхуки, но затем выяснили, что это не оптимально. После обсуждений команда предложила использовать события и интеграцию через Kafka, хотя это решение не слишком популярно. Из-за этого оценка времени работы возросла, и нам пришлось пересмотреть функциональные требования. Мы поняли, что обмена информацией из двух полей недостаточно, требуется учитывать филиалы и другие аспекты. Кроме того, препятствиями стали легаси-системы и структура единой базы клиентов. Работа в условиях постоянных изменений – новый и интересный опыт для нас. Такое глубокое погружение в проект помогло учесть все тонкости бизнеса и предложить клиенту уникальное решение.
Итоги и преимущества интеграции LABA
Решили ли мы те проблемы, о которых говорили в начале? Да, и сделали даже больше. Сейчас всё подробно расскажем.
Итог 1. Мгновенная синхронизация данных
Вся информация о клиенте сейчас обновляется сразу во всех системах. Например, если тот решает дополнительно поменять масло в автомобиле после ремонта ходовой части, его переход на новый этап воронки происходит без участия менеджера, а ответственные сотрудники и необходимые расходники автоматически заносятся в карточку клиента. В любое время менеджер может связаться с клиентом по телефону или через рассылку, не теряя время на ручное обновление данных и уточнение деталей у сотрудников техцентра.
Итог 2. Быстрый обмен информацией
Стандартные решения имеют задержки в обмене данными от 15 до 30 минут. Это значит, что информация о наличии товаров на складе может быть устаревшей. Например, клиент может оформить заказ на товар, который был распродан 10 минут назад, просто информация об этом еще не подтянулась в системы учета. Поэтому менеджеру приходится отменять его заказ и извиняться. С мгновенным обменом информацией такие ситуации исключены. Все сотрудники компании «Кореана» всегда видят актуальный статус и другие детали заявок.
Итог 3. Упрощение бизнес-процессов
Интеграция автоматизировала множество рутинных задач: обработку заявок, актуализацию данных в карточке клиента, управление запасами запчастей. С помощью автоматического обмена данными сотрудники теперь могут сосредоточиться на более важных аспектах своей работы, таких как взаимодействие с клиентами, улучшение сервиса и повышение продаж.
Итог 4 (бонусный). Беспроблемное масштабирование
Многие компании до сих пор используют стандартные компоненты 1С и Битрикс24 для обмена данными. Эти инструменты действительно удобны в базовой конфигурации, однако имеют свои ограничения, когда дело доходит до обработки больших объемов данных или работы с нестандартными модулями.
Решение из этого кейса помогает компаниям легко адаптироваться к изменениям в объеме и характере данных, не требуя кардинальной перестройки своего IT-ландшафта. И вот за счет чего:
Распределенная архитектура | Партиционирование | Независимость |
Система может состоять из множества брокеров, объединенных в кластер. При увеличении объема данных или количества источников информации можно просто добавить больше брокеров, что позволяет обрабатывать дополнительные потоки данных. | Kafka использует механизм партиционирования, который позволяет разделить каждый поток данных (топик) на части (партиции) и распределить их по различным брокерам в кластере, что снижает нагрузку на отдельные узлы и позволяет параллельно обрабатывать информацию. | Брокер – это универсальный промежуточный слой, через который можно подключить любые системы. Вам не придется вносить серьезные изменения в существующую IT-инфраструктуру. |
Кому еще будет полезна такая интеграция
Подобное решение на основе шины данных станет настоящей находкой для любого бизнеса, где требуется точная и быстрая обработка большого количества заявок на услуги или товары, особенно если в системах учета настроены уникальные поля, а в 1С есть нестандартные модули.
Вот топ ниш, где подобное может буквально перевернуть бизнес-процессы.
Интернет-магазины. Особенно те, у кого множество заявок. Например, если одновременно поступает 5-10 заказов, без автоматизации данные могут теряться или обрабатываться с ошибками.
Автосервисы и магазины запчастей. Здесь на счету буквально каждый лид, необходимо точно и вовремя отслеживать клиентов, координировать работу менеджеров и техников. Интеграция 1С и Битрикс24 обеспечивает прозрачность процессов и помогает избежать потерь информации.
Если вам понравилось – у меня есть еще интересные истории в запасе. Мой телеграмм.
Но это лишь пара примеров! Интеграция будет полезна во множестве других сфер: от логистики до образовательных учреждений. Везде, где скорость и точность обработки данных критичны, она поможет избежать ошибок и повысить эффективность работы.
