Мы интегрировали 1С и CRM — и через год в отчетах пропало 30 млн. 5 ошибок интеграции, которые совершают почти все компании

Несколько лет назад к нам пришла компания из оптовой торговли. Ситуация выглядела странно. В CRM менеджеры видели оборот 420 млн рублей. В 1С бухгалтерия показывала 390 млн.

Разница — 30 миллионов. Никто не понимал, где ошибка. Начали разбираться, оказалось, проблема не в продажах и не в бухгалтерии. Проблема была в интеграции между 1С и CRM. Заказы менялись в обеих системах, дубли клиентов множились, часть данных переписывалась автоматически. И самое интересное — интеграция была сделана всего год назад и стоила компании несколько миллионов рублей.

За последние годы мы встретили десятки подобных историй. И почти всегда проблемы возникают из-за одних и тех же ошибок. Разберём их.

В большинстве компаний интеграция выглядит так:

CRM ↔ 1С

Данные просто передаются туда-обратно. На первый взгляд всё нормально. Но через некоторое время системы начинают переписывать данные друг друга.

Компания продаёт промышленное оборудование. Процесс выглядел так:
1 менеджер создает заказ в CRM
2 заказ попадает в 1С
3 бухгалтерия корректирует цену4 интеграция отправляет заказ обратно в CRM

Менеджер видит новую сумму и думает, что это ошибка. Он снова меняет цену. Через пару часов один заказ может быть перезаписан 6–7 раз. В итоге сотрудники начали писать цену в комментариях, потому что системе перестали доверять.

В интеграции всегда должен быть единственный источник данных.

Например:

CRM — клиенты — сделки — заказы

1С — финансы — документы — склад

Это простое правило экономит компаниям месяцы проблем.

Когда бизнес заказывает интеграцию, возникает естественная мысль: «Раз уж делаем интеграцию — пусть передаётся всё.»

Начинают синхронизировать:

Интеграция превращается в огромную схему.

Оптовая компания с каталогом 120 тысяч товаров.

Интеграция передавала:

— карточки товаров — характеристики — цены — остатки — акции — статусы

Каждое обновление занимало 45 минут.

В это время:

Когда интеграцию пересобрали, оставили только:

CRM → заказ1С → цены и остатки

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

Эта проблема появляется не сразу. Первые месяцы база выглядит нормально, потом постепенно появляются записи:

CRM считает, что это разные компании.

B2B-компания из строительной отрасли. Через год после запуска интеграции:

CRM — 48 000 клиентов

Реальных компаний — около 18 000.

То есть больше половины базы было дублями. Последствия:

— менеджеры не видели полную историю клиента — маркетинг не мог анализировать сегменты — отчеты по обороту были искажены.

Причина оказалась банальной. Интеграция не проверяла совпадения по ИНН. Любая новая заявка создавала нового клиента. Очистка базы заняла несколько месяцев.

Бизнес редко работает идеально. Клиенты:

— меняют состав заказа— просят скидки— меняют адрес доставки.

Но интеграции часто строят так, будто ничего этого не происходит.

Компания из e-commerce. Процесс был простой:
1 заказ создаётся в CRM
2 заказ отправляется в 1С
3 склад отгружает товар

Но часто происходило следующее:
Клиент менял заказ.
Менеджер редактировал сделку в CRM.
Интеграция не обновляла заказ в 1С.

В итоге:

— склад видел старую версию заказа
— отправлял неправильный товар
— компания получала возвраты.

После переработки интеграции добавили:

— контроль версий заказов
— синхронизацию изменений
— блокировку редактирования после оплаты.

Количество ошибок при отгрузке снизилось почти в 4 раза.

На старте у компании обычно есть:

— CRM
— 1С

Интеграцию делают напрямую. Но через год появляются:

— интернет-магазин
— маркетплейсы
— мобильное приложение
— BI-аналитика
— складские системы.

И начинается хаос.

Розничная сеть. Когда подключили маркетплейсы, оказалось, что каждая система должна интегрироваться со всеми остальными.

Количество интеграций росло как снежный ком.

3 системы → 3 интеграции
5 систем → 10 интеграций
7 систем → 21 интеграция

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

Например:

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

В итоге компания полностью изменила подход.

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

Теперь архитектура выглядела иначе.

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

Платформа брала на себя:

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

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

Почти все компании воспринимают интеграцию как техническую задачу. Но на самом деле это архитектура движения данных в бизнесе.

Если она сделана неправильно, появляются:

— расхождения в отчетах
— дубли клиентов
— ручные исправления
— Excel «на всякий случай».

И самое неприятное — руководитель начинает не доверять цифрам в системе. А это уже проблема не IT, а управления бизнесом.