Интеграция ERP и CRM: склад, заказы и производство рядом с воронкой

Клиент на телефоне, карта наготове, он уже решил купить. Остался один вопрос: «У вас есть пятьдесят штук на складе, и когда сможете отгрузить?» Менеджер смотрит на экран — а ответа там нет. Он звонит в бухгалтерию, потом на склад и произносит роковое: «Сейчас уточню и перезвоню». Это «перезвоню» и есть тот момент, когда сделка замедляется, а иногда тихо уходит к конкуренту. Интеграция ERP и CRM существует, чтобы закрыть именно этот разрыв: перенести данные о складе, заказах и производстве на тот экран CRM, в который менеджер и так смотрит.

В этой статье речь о том, как связать с CRM операционные данные, которые живут в ERP — будь то 1С, SAP или другая система учёта. Мы намеренно обходим стороной синхронизацию счетов: это отдельная тема. Здесь важны не деньги, а то, что менеджер может пообещать клиенту: что есть в наличии, когда отгрузят и где застрял текущий заказ.

Что интеграция ERP и CRM связывает, а что нет

ERP и CRM говорят об одном клиенте, но отвечают на разные вопросы. CRM спрашивает: «на каком этапе отношения, каков следующий шаг?» ERP спрашивает: «что на складе, что в производстве, что отгружено?» Интеграция — это перенос второго набора ответов на экран первого, чтобы менеджер мог говорить, не переключая вкладок и никому не звоня.

Здесь важно чёткое разделение. У ERP два лица: финансовая сторона — счета, взаиморасчёты, оплаты — и операционная — склад, заказы, производство, отгрузка. Синхронизация счетов и взаиморасчётов — отдельная дисциплина; о ней мы говорим в материале про интеграцию CRM с бухгалтерией. Эта же статья целиком об операционной стороне: о том, что нужно видеть менеджеру, чтобы уверенно дать обещание.

Разделение важно, потому что две стороны движутся с разной скоростью и требуют разной аккуратности. Счёт после выставления почти не меняется; остаток на складе меняется поминутно. Когда переносишь операционные данные, главная борьба идёт не за точность, а за свежесть — к этому вернёмся чуть позже.

Какие данные должны стоять рядом с воронкой

Соблазн — вывалить в CRM все поля из ERP. Это ошибка. Сорок технических полей на карточке товара менеджеру не помогут, а утопят его. Хорошая интеграция не переносит данные, а отбирает их. Ускоряют разговор с клиентом всего несколько полей:

• Доступный остаток. Не «сколько лежит на складе», а количество, которое действительно можно обещать после вычета зарезервированного и уже отданного под другие заказы.
• Открытые заказы и их статус. На каком этапе заказы этого клиента — подтверждён, собирается, отгружён частично?
• Статус производства и поставки. Если нет в наличии — когда появится; открыт ли заказ на производство, есть ли твёрдая дата от поставщика?
• Отгрузка и доставка. Ушла ли последняя отгрузка, каков номер накладной или трек-номер, какова ожидаемая дата доставки?

Есть ещё вопрос подачи. ERP хранит это на своём языке: «SKU-4471, склад-3: 0, склад-1: 47, рез. 12». Менеджер это не прочитает. Хорошая интеграция переносит цифру не как есть, а по-человечески: «до четверга можно обещать 35 штук». Перенести сырой код — почти то же самое, что не переносить ничего.

КарточкаCRMДоступный остатокОткрытые заказыСтатус производст…Отгрузка

«Остаток на складе» и «сколько можно обещать» — не одно и то же

Вот ловушка, в которую интеграции попадают чаще всего. Вытащить из ERP сырой «физический остаток» и показать его в CRM легко — и опасно. Допустим, на экране пятьдесят штук; но тридцать из них уже закреплены за другими заказами. Менеджер видит пятьдесят, обещает — а реально доступно двадцать. Обещание рушится, а вместе с ним трескается доверие.

Правильная цифра — это свободный (доступный) остаток: физический минус зарезервированное и отданное под открытые заказы. Если складов несколько, всё становится тоньше: на московском есть, на региональном нет — с какого и на какую дату вы обещаете? Какое поле вы тянете, «физический остаток» или «свободный», выглядит технической мелочью, но напрямую решает, сдержит ли менеджер своё слово.

И ещё вопрос каналов. Если из одного склада питаются и полевые продажи, и маркетплейсы, то единица, проданная на Ozon или Wildberries, должна уменьшать и цифру в CRM. Собрать заказы с маркетплейсов в одной CRM — тема сама по себе; но на стороне склада оба канала обязаны делить одну правду, иначе вы продадите один и тот же последний товар двум разным клиентам.

Если менеджеру всё ещё нужно звонить на склад, чтобы дать обещание, — интеграция ещё не закончена.

Как эти данные попадают в CRM

Есть три основных пути, и какой из них верный, зависит от вашей ERP и объёма.

• Готовый коннектор. У некоторых CRM и ERP есть готовая связка друг к другу; это самый быстрый путь, но его гибкость ограничена.
• Платформа автоматизации. Для лёгких задач промежуточный слой вроде Zapier или Make связывает две системы триггерами; какой из них вам ближе, мы разобрали в сравнении Zapier и Make.
• Прямой API. У 1С и SAP есть собственные механизмы обмена (веб-сервисы, HTTP-сервисы, OData); для тяжёлых задач в реальном времени это самый надёжный путь, но он требует разработки.

Есть и решение о частоте: реальное время или пакет раз в час либо в конце дня? Для счетов конца дня достаточно, но остаток меняется поминутно, и цифра, синхронизированная утром, к обеду может стать ложью. Поэтому для быстрых полей вроде склада либо работайте близко к реальному времени, либо показывайте рядом с каждой цифрой отметку «обновлено тогда-то». Выдавать несвежие данные за свежие хуже, чем не показывать ничего: они заставляют обещать с ложной уверенностью.

1ERP (1С / SAP)2Слой интеграции3Карточка CRM4Мгновенный ответ

Должны ли данные идти в обе стороны?

До сих пор весь разговор шёл от ERP к CRM — в сторону чтения. Для большинства компаний это правильное начало, а многим этого и достаточно. Когда же имеет смысл обратное — чтобы подтверждённое в CRM предложение автоматически создавало заказ в ERP?

Честный ответ: запись куда сложнее чтения. Прочитали неверную цифру — поправили. Записали неверную строку — и она падает в ERP настоящим заказом: остаток резервируется не так, производство запускается не туда, а разбирать всё приходится руками. Поэтому запись обратно разумно включать только после того, как процесс устоялся, сопоставление полей как следует протестировано, и в одной узкой точке — например, превращать в черновик заказа только предложение, дошедшее до статуса «согласовано».

Правило простое: сначала надёжно читайте, покончите с двойным вводом, дайте команде довериться системе. Запись добавляйте потом — когда ввод одного и того же дважды действительно начнёт причинять боль.

Когда за это не стоит браться вовсе

Будем честны: интеграция ERP и CRM нужна не каждому бизнесу. В нескольких случаях она приносит больше головной боли, чем пользы.

• Мало товаров. Если у вас пятнадцать позиций и команда и так наизусть знает, что есть на складе, интеграция создаст больше проблем, чем решит.
• Грязные данные в ERP. Если остатки не отражают реальность, перенос этой ошибки в CRM лишь ускорит её распространение. Сначала нормальная инвентаризация, потом интеграция.
• Редкие заказы. Если вы продаёте несколько крупных проектов в месяц, кто-то и так пристально ведёт по каждому склад и сроки; автоматизация здесь может не окупиться.

Общее правило: интеграция ускоряет уже существующий порядок, но не создаёт порядок там, где его нет. Лекарство от «мы точно не знаем, что на складе» — сначала не софт, а вменяемый учёт запасов. Если почва зыбкая, ускоренная перекачка данных только увеличит проблему.

С чего начать: поэтапное внедрение

Лучшие интеграции не связывают всё одним махом — они растут слой за слоем. Разумный порядок такой:

1. Сначала только доступный остаток. Выведите на карточку клиента лишь «сколько можно обещать», в режиме чтения. Одно это поле уже прекращает большинство «сейчас уточню и перезвоню».
2. Затем статус заказов. Добавьте открытые заказы и их этапы; звонков «что там с моим заказом?» станет заметно меньше.
3. Затем производство и сроки. Если вы работаете под заказ — скажем, мастерская, делающая мебель по индивидуальным размерам, — перенос срока в CRM избавляет менеджера от похода к планировщику при каждом вопросе.
4. Запись обратно — в последнюю очередь и по необходимости. Когда процесс устоится, добавьте превращение согласованного предложения в заказ в ERP.

Два момента решите сразу. Первое — права доступа: менеджер видит доступный остаток, но не себестоимость и не маржу — держите эти поля вне синхронизации. Второе — обработка ошибок: если обмен встанет на день, кто это заметит? Поле склада, которое тихо устаревает, опаснее отсутствующего, потому что на него никто не смотрит с подозрением. Бросить автоматическое сообщение в командный чат, когда заказ вышел из производства, — через интеграцию со Slack или Teams — практичный способ поддерживать эту видимость.

Наконец, когда данные обеих систем оказываются рядом, рождается богатый источник для анализа: какой товар за сколько продаётся и отгружается, какие обещанные сроки действительно выдерживаются? Если хотите отслеживать такие вопросы регулярно, перенос данных в хранилище данных и BI-инструмент — естественный следующий шаг.

Часто задаваемые вопросы

Суть интеграции ERP и CRM на самом деле не техническая, а человеческая: дать менеджеру возможность посмотреть клиенту в глаза и сказать: «да, есть; отгрузим в четверг». Достигается это не переносом всей ERP, а выводом нескольких правильных полей — доступный остаток, статус заказа, срок производства — с правильной свежестью и правильными правами. Когда CRM вроде Rocketly ставит эти операционные данные рядом с карточкой клиента, «сейчас уточню и перезвоню» уступает место обещанию, данному сразу — и сдержанному.