На первом звонке клиент сказал: «Тут сайт и 1С, обмен заказами, думаю, пара недель». После discovery мы разложили процесс по шагам и увидели 12 статусов, 4 типа оплат, 3 юрлица, несколько складов и частичные возвраты. Само подключение к API заняло меньше трети работ, а итоговая оценка выросла в 2,3 раза.
Такая история повторяется часто. Бизнесу кажется, что нужно просто передать данные из А в Б, а по сути надо собрать рабочий процесс без ручных дыр, потерь заказов и споров по статусам.
Дороже всего не API, а то, как реально живет процесс
У заказа есть жизненный цикл, и каждая система описывает его по-своему. В одном месте «оплачен» - это финальный статус, в другом - цепочка из «счет выставлен», «деньги пришли», «документы проведены». Пока это не разложили на шаги, смета почти всегда выглядит слишком оптимистично.
У нас был проект для оптовой компании: сайт на Laravel 11, CRM и учетная система на стороне клиента. Сначала обсуждали только обмен заказами. Потом вскрылись резерв товара, ручная проверка менеджером, частичный возврат и автоматическая отправка документов. В итоге цепочка стала такой: сайт -> CRM -> ERP -> склад -> документы.
REST API обычно закрывает 30-40% реальной сложности. Остальное - правила переходов, маппинг полей, повторы, ошибки и ручные исключения.
На деле даже аккуратная документация не спасает, если нет тестовой среды, лимиты жесткие, а часть полей заполняется руками. Бюджет растет уже не из-за самого кода, а из-за обходных сценариев и проверок на пограничных случаях.
Смету двигают сценарии обмена, а не названия систем
Если грубо, цена интеграции складывается из числа сущностей и числа правил. Заказы, клиенты, остатки, цены, платежи, возвраты, акты - каждая сущность добавляет свою ветку логики и свой набор ошибок.
Один и тот же запрос «передавать заказы» может стоить очень по-разному:
- 40-80 часов - односторонний обмен по готовому REST API
- 150-300+ часов - двусторонний обмен с 1С, документами и сложными справочниками
- еще 20-60 часов - журнал событий, retry, idempotency, уведомления об ошибках
| Способ обмена | Старт | Где дорожает |
|---|---|---|
| REST API | дешевле | маппинг, лимиты, права |
| Webhooks | быстро | потеря событий, повторы |
| SOAP | средне/дорого | старая документация, сложные схемы |
| Файловый обмен | дешево на входе | ручные проверки, задержки |
| Очереди сообщений | дороже на старте | проектирование событий |
Когда интеграция резко дорожает?
Когда нужен real-time, несколько систем меняют одни и те же данные и нельзя терять события. В этот момент «просто обмен» превращается в отдельный слой логики, который нужно проектировать и поддерживать.
1С и связки CRM -> ERP ломают оценку быстрее всего
С 1С проблема обычно не в названии. Дорожают кастомная конфигурация, учет по юрлицам, документы, характеристики номенклатуры и складские правила, которые исторически завязаны на конкретную компанию. В одном проекте для дистрибьютора около 60% времени ушло на согласование правил: какие склады участвуют, как фильтровать по организациям, что делать с товарами без полных атрибутов.
Когда систем больше трех, прямые связи между всеми начинают мешать. Для таких схем мы обычно ставим отдельный слой интеграции на Node.js 20 + NestJS, Redis для коротких очередей и RabbitMQ, если потоков много и нельзя терять события. Смысл простой: если ERP или склад легли на полчаса, сайт не должен остановиться вместе с ними.
Нужен ли отдельный интеграционный слой сразу?
Не всегда. Если у вас сайт и одна внешняя система, иногда хватает аккуратного REST API. Но при связке CRM, ERP, склада, доставки и платежей такой слой быстро окупается, потому что кто-то должен держать правила в одном месте.
Самый дешевый старт потом часто обходится дороже
Я нормально отношусь к Make и n8n. Для быстрого запуска они полезны. Но был кейс у e-commerce компании, где связку сайта, CRM и склада собрали за 250 тыс. ₽, и на типовом потоке все работало.
Проблемы начались через несколько месяцев: возвраты, частичные оплаты, сезонная нагрузка. Сценарии размножились, правила разъехались по разным автоматизациям, при одном сбое рвалась вся цепочка. Мы переносили логику в отдельный сервис на Node.js 20 + NestJS, Redis и RabbitMQ. Грубо говоря, за быстрый старт заплатили дважды.
У нас был и свой промах. Несколько лет назад мы недооценили служебную обвязку, сделали интеграцию быстро, а потом клиент ловил дубли заказов при повторной отправке. С тех пор журнал событий и контроль идемпотентности идут в смете отдельной строкой всегда.
Нормальная оценка начинается с карты обмена
Если подрядчик сразу называет фикс, не посмотрев API, ограничения и тестовый контур, я бы насторожился. Рабочая оценка начинается с discovery на 5-15 рабочих дней. За это время можно понять, какие сущности ходят между системами, где критичен real-time, какие ручные операции все равно останутся и что считается успешной синхронизацией.
Смотрите, что полезно запросить до старта:
- сценарии обмена по шагам;
- границы работ и список допущений;
- отдельно запуск и отдельно поддержку после релиза.
До / После
До интеграции в одном проекте менеджеры переносили заказы вручную и сверяли остатки раз в день. После запуска нового слоя обмена подключение нового канала продаж сократилось на 35%, потому что статусы и события уже были приведены к одной модели.
Я бы не верил слишком красивой смете на старте - мы сами когда-то на этом обжигались. Перед запросом оценки соберите список систем, критичные сценарии и недопустимые ошибки: чем точнее эта карта, тем меньше вы платите за неизвестность. Самая дорогая часть интеграции - не код, а то, что бизнес не проговорил вслух.
