Автор кейсаIQ DevЛоготип компании

Как мы объединили БД и обогатили Bitrix24 для B2B продаж

Заказчик
2 крупных федеральных интернет-магазина
Задача
Создать единую клиентскую базу юридических лиц (в Bitrix24) и обогатить ее данными из двух существующих баз данных (БД) интернет-магазинов для последующих продаж

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

Сегодня с нашим CTO  Владом Тимофеевым расскажем как мы обогатили данными  CRM-систему Bitrix24 и помогли продавать в сегменте B2B. 

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

Ключевая задача: создать единую клиентскую базу юридических лиц (в Bitrix24) и обогатить ее данными из двух существующих баз данных (БД) интернет-магазинов для последующих продаж. 

Для этого нужно:

  • получить необходимый набор данных
  • превратить их в сущности CRM Bitrix24, чтобы менеджеры смогли использовать их как для будущих сделок, так и для анализа за прошедший период

Для удобств назовем интернет-магазины А и В.

Для прозрачности работы - составили пошаговый план, в котором отразили важные этапы проекта. 

Шаг 1. Формирование идеального результата.

Шаг 2. Сбор информации. Погружение в инфраструктуру.

Шаг 3. Проектирование

Шаг 4. Выгрузка данных: извлечение, преобразование, загрузка 

Шаг 5. Тестирование и отладка

Шаг 6. Ввод в эксплуатацию 

Теперь подробнее о каждом шаге. 

Шаг 1. Формирование идеального результата

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

В Bitrix24 выделили три сущности,  с которыми будем работать: 

  • компания
  • контакт

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

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

Определили бизнес-требования для CRM Bitrix24:

  • выгружаются только действующие компании
  • нет дублей компаний

Шаг 2. Сбор информации. Погружение в инфраструктуру.

На этом этапе предстояло ответить на следующие вопросы:

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

Для полного представления об инфраструктуре мы встретились с каждым представителем интернет-магазина и обсудили важные детали:

  • как забирать данные для каждой сущности
  • в каком формате
  • как оперативно

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

В итоге мы получили полное представление об инфраструктуре обоих интернет магазинов и всю необходимую информацию. Можно приступать к написанию конструкторской документации (КД).

Шаг 3. Проектирование

 В конструкторской документации (КД) мы описали

  • способы интеграции
  • режимы работы выгрузки
  • способы валидации компаний
  • как “сырые” данные преобразовывать в сущности CRM 

Команда QA описала тест-кейсы. После согласования КД со всеми заинтересованными в ней участниками, техлид приступил к написанию спецификации. 

Итогом третьего шага стало:

  • согласованная конструкторская документация;
  • согласованная спецификация;
  • согласованные тест-кейсы;
  • декомпозиция задачи;
  • спланированные спринты

Шаг 4. Выгрузка данных: извлечение, преобразование, загрузка

О том, как выгружали данные, плюс немного технических моментов. 

Механизм

Для решения задачи необходимо реализовать два режима выгрузки данных:

  1. полная выгрузка данных – выгрузить данные за текущий и предыдущий годы;
  2. получение обновлений – мы периодически должны получать данные о новых компаниях из интернет-магазинов.

Объем данных:

В интернет магазине А - 75 000 контактов, 53 000 компаний

В интернет магазине В -  600 000 контактов, 125 000 компаний

 

За основу реализации взяли процесс ETL. 

ETL – аббревиатура Extract. Transform. Load. Дословно – Извлечение. Преобразование.Загрузка. 

Extract - Извлечение

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

Интернет-магазин А предоставил реплику базы данных (БД), на этапе выгрузки мы забирали пачку данных, обрабатывали её и сохраняли. Для получения обновлений реализовали запуск скрипта раз в сутки с фильтрацией по дате обновления для постоянного обогащения  CRM Bitrix24. 

Интернет-магазин B предоставил топик в kafka, откуда мы получали обновление в realtime, а для полной выгрузки нам передали json-файлы. 

Итого мы реализовали три метода получения данных: 

  • база данных (mysql);
  • kafka;
  • файлы

Transform - Преобразование

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

  • удаляли компании, которые приходили без ИНН
  • преобразовали кодировку Windows-1251 в UTF-8
  • преобразовали номера телефонов контактов в общий формат данных
  • удаляли лишние пробелы из текстовых полей

Отдельным блоком выделили валидацию компаний (нужны только действующие компании). Для реализации этого требования воспользовались сервисом ЕГРЮЛ, для получения данных о компании. Bitrix24 имеет готовый модуль “из коробки” для получения сведений из ЕГРЮЛ по ИНН.  

Но данные приходили “сырые”, мы должны были убедиться, что ИНН валидный перед тем, как сделать запрос в ЕГРЮЛ. Такой запрос стоил времени, на него уходило 0,4 сек, что уменьшало скорость обработки выгрузки.  

Для ИНН реализовали стандартную проверку на длину и символы: ИНН должен состоять из 10 или 12 цифр. А также реализовали проверку контрольных чисел: проверка, которая определяет корректность номера ИНН с помощью математической формулы. Данная формула - унифицированная для всех ИНН.  

По итогам проверки: в ЕГРЮЛ отправляются вопросы только с валидным ИНН, что сократило время выполнения скриптов на 30-40%.

Load - Загрузка

Теперь мы получили очищенные данные, и сохранили их в БД как сущности CRM: 

  • компании
  • контакты 

Данный шаг был одинаковым для 3 источников (БД, kafka, файлы) На этапе написания спецификации мы учли, что данный этап в нашей выгрузке будет повторятся и заранее определили формат и состав данных, с которым будем работать, и тем самым сократили объем ресурсов на реализацию. 

Реализацию разделили между разработчиками, задачу по загрузчику (Loader) поставили в приоритет, т.к. он общий для всех источников. Параллельно, второму разработчику, передали в работу с задачей выгрузки (extractor) из интернет-магазинов. Выгрузку из интернет-магазина А выполнили первой, и разработчик приступил к выгрузке обновлений из Kafka интернет-магазина Б. 

Первым релизом - выпущены выгрузка из интернет магазина А, с общим загрузчиком. 

Вторым релизом вышла выгрузка обновлений из интернет-магазина Б. 

Третьим вышла полная выгрузка исторических данных из интернет-магазина Б.  

Таким образом, даже на этапе разработки, мы непрерывно снабжали новыми данными менеджеров по продажам.

Шаг 5. Тестирование и отладка

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

Шаг 6. Ввод в эксплуатацию 

Полную выгрузку из интернет-магазинов запускали в ручном режиме. Для получения обновлений из магазина А установили регулярную задачу (cron-job), раз в сутки забирали свежие данные. Из магазина В, благодаря kafka получили обновления в realtime.

Завершение

Bitrix 24 была обогащена, нам удалось выгрузить более 170 000 действующих компаний, более 264 000 контактов  по обоим интернет-магазинам  

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

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

Отмечу, что в этом случае только благодаря коммуникациям “бизнес-разработчики-бизнес” удалось реализовать поставленные задачи, тк разработчики знают как быстро интегрироваться и как получить те или иные данные, но только при грамотно построенной коммуникации между бизнесом и разработчиком возможно достичь целей и остаться довольным своей работой. Ну и как в этом кейсе - получить данные для увеличения продаж. 

 

В карточку агентства

Письмо автору кейса

Пользуйтесь реальным опытом в IT и следите за успехами потенциальных подрядчиков и конкурентов
Подпишитесь на рассылку
Читайте также
Кейсы по теме#Товары народного потребления