У бизнеса редко проблема в том, что «нет автоматизации». Обычно сайт, CRM, 1С, склад и доставка уже есть. Деньги уходят в другом месте - там, где между этими системами сидит человек и вручную чинит поток заказов, оплат и остатков.
Недавно мы считали экономику для оптовой компании: сайт на Laravel 11, amoCRM, 1С, складская система и два маркетплейса. Формально все было подключено. По сути заказ ехал по компании руками через Excel, почту и Telegram, а руководство потом разбиралось, почему в отчетах есть три версии одних и тех же цифр.
Ломается не софт, а переход между ним
Самый частый сценарий, который я вижу, выглядит одинаково: заказ пришел с сайта, менеджер переносит его в CRM, бухгалтер оформляет документы в 1С, склад отдельно сверяет остатки, BI потом показывает свою картину. Каждая система сама по себе может работать нормально. Сбой начинается на стыке.
Если у интернет-магазина 300 заказов в день, а на ручную обработку уходит хотя бы 2 минуты на заказ, это уже около 10 часов в день. Если вся цепочка занимает 7-9 минут, выходит больше 170 часов в месяц чистой операционки.
У дистрибутора автозапчастей мы увидели ровно это. Команда держала 4 операторов только на переносе статусов, оплат и отгрузок между маркетплейсами, CRM и 1С. Ручная склейка стоила примерно 380 тыс. ₽ в месяц, а интеграция критичного контура окупалась меньше чем за 1 квартал.
Во многих компаниях интеграция уже оплачена - просто не подрядчику, а операторам, ошибкам и задержкам.
Дорого стоит не API, а договоренность о данных
Когда говорят «там же просто подключиться к API», проект обычно еще даже не начался. На деле деньги уходят в правила: кто главный по клиентам, товарам, ценам и остаткам, что делать с дублями, отменами, частичной оплатой и повторной отправкой события.
С 1С это особенно заметно. На бумаге - «типовая конфигурация», внутри - годы доработок, свои справочники и логика скидок, которую никто не описал. В одном проекте для B2B-продаж мы делали обмен на Laravel 11 + PostgreSQL 16 почти 8 недель. Код занял меньше половины времени, остальное ушло на сверку данных, разбор исключений и тесты на реальных сценариях.
По сути это и есть master data в нормальном смысле: одна система отвечает за конкретный тип данных, остальные получают и используют. Если такой договоренности нет, интеграция быстро превращается в бесконечные правки.
| Подход | Что получает бизнес | Где начинается боль |
|---|---|---|
| Синхронный обмен | ответ сразу | сбой одной системы тянет вторую |
| Асинхронный через очередь | выше отказоустойчивость | нужен контроль ошибок |
| Прямые связи между системами | быстрый старт | после 4-5 систем поддержка резко дорожает |
| Интеграционный слой | изменения предсказуемы | старт дороже на 15-25% |
Мы обычно берем отдельный интеграционный слой, если систем уже несколько и каналы продаж будут расти. Старт дороже, но сопровождение потом спокойнее, а заказ не теряется бесследно, даже если одна из систем временно недоступна.
1. Заказ создан на сайте
2. Событие уходит в очередь
3. Обработчик проверяет idempotency key
4. Пишет заказ в ERP или 1С
5. Если ошибка - retry 3 раза
6. Если не получилось - в error queue и уведомление команде
Интегрировать стоит узкое место, а не весь хаос
Мы сами на этом обжигались. В одном e-commerce проекте среднего размера клиент хотел сразу связать сайт, CRM, склад, логистику и аналитику. Через три недели стало ясно, что логика возвратов и резервов на складе у него не описана даже на уровне регламента. Автоматический обмен просто начал тиражировать путаницу быстрее.
Это как раз тот случай, где у нас была своя ошибка: мы слишком рано пошли в широкий контур, хотя надо было сначала зафиксировать базовые правила процесса. После этого проект пришлось пересобрать по этапам.
Частая ошибка - автоматизировать весь процесс целиком, потому что «так правильнее». Рабочий подход другой: взять участок, где потери уже считаются в деньгах, - заказы, оплаты или остатки - и сначала стабилизировать его.
На другом проекте мы пошли именно так: Node.js 20 + NestJS, только контур заказов и остатков. Обновление остатков сократили до 90 секунд, число отмен из-за отсутствия товара упало на 34%. Все остальное клиент еще какое-то время вел руками, и для его масштаба это было нормальным решением.
Формула тут грубая, но рабочая:
- ручное время x стоимость часа x число операций
- плюс цена ошибок
- плюс потери из-за задержек
Если команда тратит 160 часов в месяц на перенос данных, а час стоит 1 500-2 500 ₽, только руками бизнес сжигает 240-400 тыс. ₽. И это без возвратов и потерянных заказов.
Хорошая интеграция видна по управляемости, а не по слову «подключили»
После запуска у руководителя должен быть ответ на три вопроса: что передано, что зависло, кто это исправляет. Если этого нет, интеграция красивая только на схеме.
У зрелого решения есть мониторинг, логирование, повторные попытки, SLA и защита от дублей. В проекте для сети поставщиков мы заложили очередь ошибок и панель контроля. В итоге 95% заказов попадали в учетную систему меньше чем за 1 минуту, а остальные не исчезали в пустоте - их было видно сразу.
Когда можно не делать большую интеграцию?
Если у вас мало операций, цена ошибки низкая и процесс меняется каждую неделю, хватит готового коннектора или сценария в Albato. Полноценный проект нужен там, где ручная работа уже стала постоянным налогом на рост.
Когда пора считать проект всерьез?
Когда 5-10 человек каждый день тратят по часу-два на переносы между CRM, 1С, складом и доставкой. В этот момент вопрос уже не технический - вы просто выбираете, кому платить за разрывы между системами.
Перед тем как заказывать интеграцию, не спрашивайте «сколько стоит связать CRM с 1С». Лучше спросить другое: сколько денег у вас уже уходит на людей, которые играют роль API. И сколько еще вы готовы платить за эту невидимую должность?
