Когда сайт, 1С и CRM подключены друг к другу, бизнес часто ждёт, что «всё само синхронизируется». На практике одна и та же цифра — цена, остаток или статус заказа — существует в трёх системах сразу, и у каждой своя версия правды. Ошибка обнаруживается не в момент настройки, а после первого реального заказа, когда клиенту уже нужно перезванивать.
Техническая связка сама по себе владельца данных не назначает. Это организационная задача, и закрывается она не диаграммой обмена, а матрицей владения.
Матрица владения вместо «синхронизировать всё»
Главный риск при подключении сайта сразу к 1С и CRM — не сам обмен, а два владельца одного поля. Цена обновляется в учётной системе, остаток приходит по расписанию выгрузки, а статус заявки правит менеджер вручную. Без правил такая схема заканчивается перезаписью чужих изменений.
Для каждого объекта — цены, остатка, статуса, контакта клиента — фиксируют пять вещей:
- где запись создаётся;
- какая система изменяет её первой;
- куда идут копии;
- какая задержка допустима;
- что делать при конфликте.
Формулировка «синхронизировать всё» такой матрицей не заменяется. Без неё интеграция работает ровно до первого спорного случая.
Каталог, витрина и история — три разные роли
В 1С обычно живут номенклатура, условия учёта и доступные остатки. Сайт показывает утверждённую витрину. CRM хранит историю коммуникаций, ответственного и этап обработки запроса.
Распределение зависит от процесса, но согласовать его нужно до разработки, а не во время приёмки. Отдельный подводный камень — цена, зависящая от договора, региона или объёма. Публичная карточка не должна выдавать устаревшую цифру: варианты — диапазон, запрос условий или авторизованная цена, но правило задаёт бизнес-владелец, а не разработчик.
Статусы не склеиваются в одну линейку
Статус обращения на сайте, статус сделки в CRM и статус заказа в 1С — не одно и то же, даже если названия похожи. Попытка свести их в единую линейку создаёт ложные переходы и мешает сотрудникам работать.
Полезнее описывать события: заявка принята, менеджер запросил данные, заказ подтверждён, отгрузка отражена в учёте. Для каждого события указывают систему-источник и то, что увидит клиент в кабинете или письме.
Задержки, ошибки и ручные правки
Обмен по расписанию не даёт мгновенного обновления. На сайте честно показывают, где пользователь видит остаток на момент выгрузки, а где получает подтверждение от менеджера.
Журнал интеграции должен содержать идентификатор объекта, время, направление, результат и текст технической ошибки — без персональных данных. И отдельное правило требуется для ручной правки: если его нет, следующая выгрузка молча перезапишет исправление.
Приёмка на данных, которые можно проверить
Тестовый набор включает новый товар, изменение цены, нулевой остаток, удалённую позицию, повторный обмен и заказ с несколькими товарами. Для каждого случая команда заранее знает ожидаемый результат в трёх системах. Приёмка проверяет и права: редактор сайта не должен менять учётные остатки, а менеджер CRM — публиковать характеристики без утверждённого процесса.
Сопоставление объектов строится на устойчивом идентификаторе — артикуле, ID варианта, договоре. Если системы связывают записи по названию или e-mail, обмен начнёт плодить дубли после первой же правки справочника.
Что взять с собой
Для связки 1С, сайта и CRM ключевой артефакт — матрица владения данными. С неё начинают проектирование, по ней проверяют обмен и по ней разбирают изменения после запуска. Ускорение выгрузки экономит меньше времени, чем одна проверка сопоставления идентификаторов.
Top comments (0)