Автоматизация

Интеграции: CRM, почта, склад

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

В большинстве компаний уже стоит несколько систем: сайт с заявками, CRM, почта, учёт товара или услуг, бухгалтерия. Каждая работает нормально по отдельности. Проблема возникает на стыках — там, где данные должны переходить из одной в другую, а переходят через человека с буфером обмена. Разберём, где именно рвётся связь и что с этим делать.

Двойной ввод как симптом

Если сотрудник вводит одни и те же данные дважды — это не вопрос дисциплины, а отсутствующая интеграция. Признаки легко заметить со стороны:

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

Цена двойного ввода — не только потраченное время. Он гарантированно порождает расхождения: в одной системе телефон с опечаткой, в другой заказ отменён, а на сайте товар всё ещё в наличии. Дальше начинается работа с последствиями, которая обходится дороже самого ввода.

Отдельный эффект — потеря источника. Когда заявка переносится руками, метка кампании и идентификатор посетителя остаются в письме и до CRM не доходят. Это ломает сквозную аналитику на самом первом шаге.

Где обычно рвётся связь

Места, в которых обмен ломается, довольно однотипны.

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

Разные форматы. Телефон с плюсом и без, дата в двух вариантах, суммы с копейками и без, единицы измерения. На этапе тестов всё сходится, а на реальных данных из разных источников — нет.

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

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

Изменения на чужой стороне. Сервис обновил интерфейс обмена, поменял формат ответа или отозвал ключ доступа. Ваш код при этом не менялся — но перестал работать.

Синхронизация и её конфликты

Ключевой вопрос любой интеграции: в какую сторону идут данные и кто главный по каждому полю.

Односторонний обмен проще и надёжнее. Заявка с сайта уезжает в CRM, обратно ничего не возвращается — конфликтов нет. Двусторонняя синхронизация сложнее на порядок, потому что появляется случай, когда запись изменили в обеих системах между сеансами обмена.

Такие ситуации нужно решать заранее, а не разбирать по факту. Варианты:

  1. Назначить источник истины для каждого поля. Остатки — только из учётной системы, контактные данные — только из CRM, цена — только из прайса. Изменение в неглавной системе либо запрещается, либо перезаписывается.
  2. Считать победителем последнее изменение. Просто в реализации, но приводит к незаметной потере данных: чьё-то изменение молча исчезнет.
  3. Фиксировать конфликт и звать человека. Медленно, зато ничего не теряется. Уместно там, где цена ошибки высокая.

Второй важный вопрос — режим обмена. Обмен по событию (система сама сообщает об изменении) даёт актуальные данные почти сразу, но требует, чтобы принимающая сторона была доступна. Обмен по расписанию проще и устойчивее, но данные всегда немного отстают. Для остатков товара эта задержка может быть критичной, для отчётности — нет.

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

Интеграция без защиты от повторов и без правила разрешения конфликтов работает ровно до первого сетевого сбоя.

Что делать при сбое обмена

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

Что должно быть предусмотрено:

  • Журнал операций. Что пытались передать, когда, с каким результатом. Без журнала разбор инцидента превращается в гадание.
  • Очередь и повторные попытки. Неудачная передача не выбрасывается, а откладывается и повторяется с возрастающим интервалом.
  • Уведомление ответственному. Человек должен узнать о проблеме от системы, а не от клиента.
  • Ручной повтор. Возможность перезапустить конкретную операцию после того, как причину устранили.
  • Сверка. Периодическая проверка, что число записей и ключевые суммы в двух системах сходятся. Именно сверка ловит тихие расхождения, которые не дали ни одной ошибки.

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

Почему интеграция — не разовая работа

Связка систем живёт в изменяющейся среде. Меняются внешние сервисы, меняется ваш собственный процесс, добавляются новые поля, появляется новый склад или второе юридическое лицо. Интеграция, сданная и забытая, деградирует сама по себе.

Практически это значит, что у интеграции должны быть:

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

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

Чеклист перед стартом

  • Перечислены все системы и определено, какие данные между ними ходят.
  • Для каждого поля назначен источник истины.
  • Выбран общий ключ, по которому записи сопоставляются между системами.
  • Определён режим обмена: по событию или по расписанию, с какой периодичностью.
  • Описано поведение при конфликте и при повторной передаче.
  • Есть журнал, очередь повторов и уведомление ответственному при сбое.
  • Настроена регулярная сверка данных.
  • Известно, где хранятся ключи доступа и кто их продлевает.
  • В бюджете есть строка на сопровождение.

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