- В CRM сделка уже выиграна, клиент ждет отгрузку. Почему склад говорит, что товара нет?
- Потому что продажи, учет и исполнение живут в разных системах.
- Значит, проблема не в «слабой CRM», а в том, что у бизнеса три версии реальности.
С таким вопросом к нам пришел оптовик: CRM у продаж, 1С у учета, таблицы у закупок. Потери шли не на лицензии, а на ручные сверки, пересогласования и сорванные обещания клиенту.
Где проходит граница между продажей и исполнением
Если упростить, CRM нужна для клиента и сделки. ERP - для того, чтобы заказ был исполнен: закупить, зарезервировать, отгрузить, провести оплату, посчитать себестоимость.
Когда CRM тянут до уровня учетной системы, менеджеры продают быстрее, чем компания способна выполнить заказ. Когда ERP делают основным рабочим местом продаж, менеджеры все равно уходят в Excel и мессенджеры.
У нас был проект в опте на Laravel 11, PostgreSQL 16 и связке с 1С. Продажи шли через CRM, но остатки менеджеры проверяли вручную. В итоге до 12% заказов в месяц уходили на пересогласование: товар уже зарезервирован, срок поставки сместился, клиенту нужно заново подтверждать условия.
| Зона | CRM | ERP | Что дает связка |
|---|---|---|---|
| Клиент | контакты, история, коммуникации | контрагент, договор, реквизиты | одна карточка без дублей |
| Заказ | заявка, этап сделки | резерв, исполнение, отгрузка | сквозной статус |
| Остатки | обещание менеджеру | фактический склад | актуальные данные |
| Оплата | напоминание, этап оплаты | платежи, долг, закрытие | меньше споров по счетам |
| Документы | шаблоны КП | счет, УПД, отгрузка | меньше ручных ошибок |
Когда одной CRM уже мало
Триггер здесь не размер компании, а операционная сложность. Я видел бизнес на 18 человек с несколькими складами, где без нормального учета процессы вязли, и компанию на 70 сотрудников, которой хватало CRM, бухгалтерии и календарей.
Обычно сигналами становятся:
- данные по заказу вводят дважды
- продажи, склад и финансы показывают разные цифры
- сроки обещают без проверки остатков или загрузки ресурсов
- себестоимость считают задним числом
- оплаты и отгрузки уточняют в чатах и по телефону
Отдельная история - сервисный бизнес с бронированием. У одной компании были CRM, календарь и внутренняя база, но не было общего контура. После интеграции через n8n ручные подтверждения сократились на 60-70%, а время обработки заявки - с 20 до 5 минут.
Если CRM тормозит, это еще не повод покупать ERP. Сначала стоит найти участок, где процесс рвется и начинает сжигать маржу.
Когда ERP будет лишней, а обмен через API уже окупится
Интеграция нужна не всем. Мы видели проекты, которые используют 20% возможностей системы и платят за весь контур.
Картина обычно выглядит так:
- микробизнес - CRM и точечные интеграции
- растущий SMB - CRM + учетная система + обмен заказами и оплатами
- сложная операционка - CRM + ERP + отдельный интеграционный слой
Для услуг без склада часто хватает amoCRM, бухгалтерии, телефонии и календаря. У нас был кейс: вместо тяжелой ERP собрали схему в 3 раза дешевле.
В e-commerce с 10 000+ SKU картина обратная. Без связи с учетом быстро начинаются оверсейлы: витрина показывает одно, склад знает другое, менеджер обещает третье. На старте здесь часто достаточно REST API, webhooks, Make, n8n или Albato. Такой сценарий можно проверить за 2-4 недели, а не уходить сразу в проект на полгода.
Где интеграция возвращает деньги
Считать стоит не «автоматизацию вообще», а конкретные точки потерь: клиент, заказ, остатки, оплата, документы.
Если менеджер тратит лишние 12 минут на один заказ, а заказов 40 в день, это 8 часов ручной работы ежедневно. При стоимости часа даже 800 ₽ бизнес теряет около 140 000 ₽ в месяц только на передаче данных.
На одном проекте в дистрибуции было так:
- до: обработка заказа 15-20 минут, ошибки в документах на каждой десятой отгрузке
- после: 3-5 минут на заказ, ошибок стало меньше примерно на 40%
Частая ошибка - сначала покупать «большую систему», а потом разбираться с процессом. Рабочий порядок другой: выбрать один маршрут денег, например путь заказа до отгрузки, и определить, где источник истины по клиенту, остаткам, оплате и финальному статусу.
Почему проекты ломаются еще до разработки
Самый частый сбой не в API, а в том, что отделы по-разному понимают статусы. Для продаж «подтвержден» значит «можно обещать клиенту», для склада - «еще рано резервировать», для финансов - «счета нет, заказа нет».
На проекте у поставщика оборудования мы делали интеграционный слой на Node.js 20 + NestJS. До старта разработки до 25% заказов требовали ручной проверки из-за расхождения статусов. После унификации справочников и правил обмена ручные уточнения снизились больше чем вдвое за 6 недель.
Order created in CRM
-> webhook
-> middleware
-> ERP
-> status back to CRM
Технически важны идемпотентность, логирование и повторные попытки отправки. Если продажи, склад и финансы живут в разных окнах, начинать нужно не с новой платформы, а с вопроса: в какой системе находится правда по заказу. Иначе снова получится не автоматизация, а те же три версии реальности, только дороже.
