В прошлом году к нам пришла оптовая компания с уже «готовой» интеграцией: сайт, Bitrix24, 1С и служба доставки. На схеме все выглядело прилично. На практике менеджеры каждый день вручную сверяли оплаты, остатки на сайте отставали на 2-3 часа, а директор видел три разные цифры по выручке. Я такое встречаю регулярно: пока никто не считает потери времени и ошибок, кажется, что система работает.
Системная интеграция нужна не в тот момент, когда захотелось «связать сервисы». Она нужна тогда, когда данные начинают мешать операционке, продажам и учету жить в одной реальности.
Первый признак - люди уже работают вместо системы
Самый понятный сигнал - сотрудники становятся ручным API. Они копируют заявки с сайта в CRM, проверяют оплату в банке, добивают поля в Excel, звонят на склад. Пока заказов 20 в день, это еще терпят. На 300 заказах в день даже 1-2 минуты ручной работы на заказ превращаются в 10-20 часов лишней операционки в сутки.
У нас был интернет-магазин на Laravel 11, Bitrix24 и 1С:УТ. До проекта статусы заказов обновлялись с задержкой 2-4 часа, менеджеры вели отдельную таблицу для спорных случаев. После нормальной синхронизации заказа, оплаты и отгрузки обновление стало идти за минуты, а число ошибок в заказах снизилось примерно на 38% за первый месяц.
До/после по одному из таких проектов:
- до - обработка заказа 7 минут, ручная сверка в трех окнах
- после - 1 минута, менеджер сразу видит актуальный статус
- до - остатки расходятся между сайтом и 1С
- после - один источник по номенклатуре и складу
Главный вопрос здесь один: где у вас правда
Когда бизнес просит «быстро связать сайт с CRM», мы почти всегда возвращаем разговор к другому вопросу. Какая система главная для клиента, заказа, товара, цены, оплаты и доставки. Если это не зафиксировано, дальше начинается обычный конфликт: в CRM одна цена, в 1С другая, на сайте третий остаток.
Если не определен источник истины, интеграция быстро превращается в спор отделов, а не в работу систем.
Обычно мы сначала собираем карту потока: откуда приходит событие, кто имеет право менять запись, что происходит при сбое, кто получает уведомление и какой SLA по исправлению.
| Поток | Как передаем | Что контролируем |
|---|---|---|
| Сайт -> CRM | webhook / API | дубль лида, источник |
| CRM -> 1С | API или очередь | заказ, цена, контрагент |
| 1С -> доставка | асинхронно | остатки, отгрузка, статус |
| Ошибки | retry + audit log | алерт и срок реакции |
На проекте в дистрибуции медоборудования карточки товаров меняли и в 1С, и в CRM, и частично на сайте. Из-за этого появлялись дубли, а менеджеры продавали то, чего уже не было на складе. Когда мы закрепили правила - номенклатура и остатки только из 1С, коммерческие поля из CRM, - цепочка перестала рассыпаться.
order_created
-> validate
-> send_to_crm
-> push_to_erp
-> confirm_status
-> log_result
Самая дорогая схема - наполовину автоматическая
Полностью ручной процесс хотя бы прозрачен. Частично автоматический опаснее: все уверены, что данные ходят сами, и перестают видеть слабые места.
Обычно это выглядит так:
- часть полей идет по API
- часть загружают из Excel
- часть менеджер меняет руками
- правила обмена знают два человека
Мы видели такой контур на e-commerce проекте под NDA. Там было 14 обменов между системами, но для бизнеса критичны оказались только 4 потока: заказ, оплата, остатки, отгрузка. После упрощения схемы инциденты снизились на 45%, а ежемесячная поддержка стала дешевле почти на 120 тыс. ₽.
Частая ошибка: пытаться передать сразу все поля и все сценарии.
Рабочий подход: сначала собрать надежный контур вокруг денег, склада и статусов, потом расширять обмен.
Ломается не API. Ломается дисциплина вокруг него
На практике проблемы почти всегда приземленные: грязные старые данные, дубли клиентов, отсутствие логов, жесткие прямые связи и обновления, которые никто не проверил на совместимость.
Я бы в первую очередь проверил вот что:
- есть ли очередь и повторная отправка
- можно ли безопасно принять одно и то же событие дважды
- видно ли в логах, где именно потерялся заказ
- кто узнает о сбое первым - система или клиент
Один кейс у нас не взлетел с первого раза. В B2B-продаже запчастей клиент настоял на прямой схеме: сайт на Node.js 20 + NestJS писал заказы сразу в ERP по API, без промежуточного слоя. Пока ERP отвечала быстро, все выглядело нормально. Под сезонной нагрузкой заказы начали теряться, потому что не было ни очереди, ни retry, ни понятного следа в логах. Позже мы добавили RabbitMQ, audit log и повторную доставку, и потери сократились почти до нуля.
Что выбирать, чтобы интеграция окупалась
Если нужна реакция сразу - лид, оплата, смена статуса, - я обычно выбираю API или webhook. Для отчетности и аналитики лучше работают ETL/ELT-сценарии: Airbyte, dbt, PostgreSQL 16, иногда ClickHouse, если данных много. Когда систем уже 5-6 и правила обмена начинают жить отдельно, нужен промежуточный слой с очередями, логами и контролем ошибок.
Окупаемость здесь считают очень приземленно: сколько ручных действий убрали, насколько быстрее проходит заказ, сколько ошибок исчезло, сколько стоит месяц поддержки после запуска. В ближайшие 6-12 месяцев выиграют компании, которые наведут порядок в источниках данных и мониторинге, а не те, кто просто добавит еще одну связку. Если о сбое первым узнает клиент, у вас пока нет интеграции - у вас есть дорогая иллюзия.
