Почему интеграция ERP с Salesforce терпит неудачу и как это исправить

Интеграции SAP и Salesforce чаще всего ломаются из-за бизнеса, а не из-за техники. Синхронизация идёт, но данные слишком старые для решения, которое принимает пользователь. Или две системы спорят, какая карточка клиента верна. Или за поток никто не отвечает, когда обновление его ломает. Исправляется это так: проектировать от решения пользователя назад, сначала навести порядок в данных, выбрать middleware под свой масштаб и закрепить за каждым потоком владельца и план на случай сбоя.

Эта статья для CIO, руководителей служб сопровождения продаж и интеграционных команд, которые подключают Salesforce к SAP. В ней четыре типовые причины сбоев, варианты интеграции, то, что нужно надёжной интеграции, и шаблон спецификации.

Я работал с компаниями, где даже часовое отставание между системами приводило к ошибкам в предложениях и потерянным сделкам. Обычно причина одна: никто не спросил, насколько свежими должны быть данные об остатках, чтобы менеджер мог по ним выставлять цену.

Интеграция может работать технически и при этом не работать коммерчески. Начинать нужно с этого различия.

Частота синхронизации не соответствует решению

Пакетная синхронизация подходит для части данных. Но не для складских остатков, доступных к обещанию клиенту, не для цен и не для статуса заказа, когда клиент ждёт ответа сразу.

Типичный сценарий сбоя: команда интеграции делает то, что технически удобно при данных объёмах, и задаёт интервалы пакетной выгрузки по техническим соображениям. Никто со стороны бизнеса не проверяет, подходит ли такая частота для решения, которое принимает пользователь.

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

1. 01Основные данные клиентовиз SAP в Salesforce, 24 часа
2. 02Прайс-листыиз SAP в Salesforce, 1 час
3. 03Наличие на складеиз SAP в Salesforce, 15 минут
4. 04Выигранная сделкаиз Salesforce в SAP, сразу
5. 05Статус заказаиз SAP в Salesforce, 15 минут
6. 06Счёт и оплатаиз SAP в Salesforce, 24 часа

Предложение, заказ и счёт сходятся

Несовпадения в качестве данных

Если название компании в Salesforce оформлено иначе, чем в основных данных клиента в SAP, каждая синхронизация порождает расхождения, которые приходится исправлять вручную.

Я работал с командами, которые каждую неделю тратили часы на сверку базовых данных о клиентах между Salesforce и ERP. Видел и проекты, где одно только сопоставление иерархий клиентов заняло недели, потому что две системы по-разному понимали, что такое «аккаунт». Системы годами велись по отдельности и разошлись так, что никто этих расхождений не описал.

Наведите порядок в данных до интеграции. Звучит очевидно. Но именно этот шаг пропускают чаще всего.

Архитектура не соответствует масштабу

Интеграция «точка-точка» работает, когда систем две, потоков немного, а процессы стабильны. Это самый дешёвый способ начать.

Она не масштабируется. Добавьте модуль SAP, новое бизнес-подразделение в Salesforce или третью систему, и связей станет намного больше. Каждую нужно отдельно поддерживать, тестировать и разбирать при сбоях.

Middleware (SAP Integration Suite, MuleSoft, Boomi или аналоги) даёт единый управляемый слой с централизованным мониторингом и обработкой ошибок. Цена вопроса: заранее придётся вложиться в архитектуру и управление. Компании, которые внедряют middleware, но не назначают ему конкретного владельца, получают те же проблемы, что и при «точка-точка», плюс платформу, которую никто не понимает.

Нет управления интеграциями

Каждый релиз Salesforce и каждый пакет поддержки SAP может сломать поток: изменения в API, новые правила валидации, изменённые поля, новые требования к аутентификации. Интеграции, которые построили и забыли, падают при первом обновлении, которое никто не прогнал через регрессионное тестирование. Это самый частый сбой после go-live, который я вижу.

SAP Integration Suite. Интеграционная платформа SAP на SAP BTP и естественный выбор, когда в ландшафте главную роль играет SAP. Она хорошо работает с IDocs, BAPIs, OData и форматами сообщений SAP и содержит готовый контент для типовых сценариев SAP. Сложным бизнес-процессам по-прежнему нужны собственные потоки интеграции и настоящие навыки интеграции. Если вы всё ещё на SAP PI/PO, учтите: его основная поддержка заканчивается в конце 2027 года, поэтому новые потоки Salesforce на нём строить не стоит. На RISE проверьте, какое право на SAP BTP уже включено в ваш контракт, прежде чем докупать ещё.

MuleSoft. Принадлежит Salesforce с 2018 года, у платформы широкая библиотека коннекторов, официальный коннектор для SAP S/4HANA и шаблоны-ускорители для процесса order-to-cash в SAP. Хорошо подходит, если лицензия у вас уже есть. Подвох для организаций, где SAP занимает много места: MuleSoft требует отдельной экспертизы, и команда, которая ведёт вашу программу SAP, скорее всего, не та, которой стоит проектировать архитектуру MuleSoft.

Boomi. Облачная интеграционная платформа (с 2021 года независимая от Dell) с коннекторами к SAP и Salesforce и более низким порогом входа, чем у MuleSoft. Разумный выбор для компаний среднего рынка, которым нужен управляемый middleware без стоимости и сложности MuleSoft.

API «точка-точка». Прямые вызовы REST или SOAP между Salesforce и SAP позволяют не платить за middleware. Но им нужны дисциплина в версионировании API, регрессионное тестирование на каждом релизе и команда, которая понимает обе системы. Для простых и стабильных случаев подходит. Для всего сложного это источник растущего технического долга.

Мой гайд по SAP CPI и Integration Suite подробнее разбирает платформу со стороны SAP, а обзор пяти CRM-систем для SAP сравнивает сами CRM.

1. Спецификация каждого потока: поля, направление, частота, сопоставление ключей и то, что происходит, когда две системы расходятся.
2. Явно продуманный сценарий сбоя. Что происходит с данными в пути, когда синхронизация падает? Сколько повторных попыток? Кто получает оповещение? Как выглядит ручное восстановление? Здесь большинство интеграций недопроработано.
3. Регрессионные тесты перед каждым обновлением. Salesforce выпускает три крупных релиза в год, а у SAP свои пакеты поддержки и обновления. Перед каждым из них должен запускаться автоматизированный набор тестов по критичным потокам.
4. Мониторинг с оповещениями. Тихий сбой хуже громкого. Ошибки, копившиеся несколько дней, исправлять гораздо труднее, чем те, что пойманы за минуты.
5. Владелец. Один человек, который знает, что делает интеграция, видит, когда она ломается, и имеет доступ и полномочия её починить.

Заполните по одной строке на каждый поток, прежде чем кто-то начнёт писать документ со спецификацией. Если в ячейке пусто, поток не готов к разработке. Значения ниже приведены для иллюстрации; свои согласуйте с теми, кто работает с данными.

Поток	Направление	Триггер и частота	Максимально допустимый возраст данных	Ведущая система	При сбое	Владелец
Основные данные клиентов	Из SAP в Salesforce	При изменении	24 часа	SAP	Повтор, затем оповещение стюарда данных	Владелец основных данных клиентов
Наличие на складе	Из SAP в Salesforce	По запросу или почти в реальном времени	15 минут	SAP	Показать пометку «уточните в операционном отделе»	Руководитель систем цепочки поставок
Прайс-листы и условия	Из SAP в Salesforce	При изменении	1 час	SAP	Блокировать предложение при устаревшей цене	Менеджер по ценообразованию
Выигранная сделка в заказ на продажу	Из Salesforce в SAP	При закрытии	Сразу	Salesforce до создания заказа, затем SAP	Поставить в очередь и оповестить службу сопровождения продаж	Руководитель службы сопровождения продаж
Статус заказа и поставки	Из SAP в Salesforce	При каждой контрольной точке	15 минут	SAP	Повтор, затем оповещение поддержки интеграции	Руководитель интеграции
Статус счёта и оплаты	Из SAP в Salesforce	Ежедневно	24 часа	SAP	Оповестить финансовые системы	Руководитель финансовых систем

Столбец «Максимально допустимый возраст данных» большинство команд так и не заполняет. Согласуйте его с пользователями, которые принимают решения, а не только с командой интеграции. Если вы уже отстаёте от графика, в материале про задержки в поставке SAP Integration Suite разобраны типичные причины.

Карточки клиентов не совпадают. Причина: основные данные клиентов в двух системах так и не выровняли. Решение: сверить их до go-live, сделать SAP ведущей системой для данных о клиентах и закрепить сопоставление в самой интеграции.

Статус заказа не обновляется в Salesforce. Причина: интеграция покрывает путь от предложения до заказа, но не обратные вызовы со статусами. Решение: отправлять обновления статуса из SAP SD обратно в Salesforce на каждой контрольной точке заказа.

Цены в предложениях отличаются от цен в счетах. Причина: цены ведутся в Salesforce вручную и расходятся с условиями ценообразования в SAP. Решение: сделать SAP мастером цен и загружать цены в Salesforce через интеграцию.

Интеграция ломается после обновления SAP. Причина: в плане обновления нет регрессионного тестирования интеграции. Решение: включать регрессионное тестирование интеграции в объём каждого обновления SAP.

Можно ли интегрировать Salesforce с SAP?

Да, через SAP Integration Suite, MuleSoft, Boomi, другие интеграционные платформы или напрямую через API. Типовые потоки: синхронизация основных данных клиентов, выигранная сделка в заказ на продажу, статус заказа и поставки обратно в Salesforce, цены в Salesforce для предложений, статус счетов и оплат. Синхронизация основных данных клиентов делается просто. Полный цикл от предложения до оплаты со сложным ценообразованием, множеством балансовых единиц и остатками в реальном времени: это уже серьёзный проект.

Salesforce относится к ERP или к CRM?

Это CRM. Она управляет воронкой продаж, возможностями, взаимодействием с клиентами, маркетингом и сервисом. Проводки в бухгалтерии она не делает и запасами не управляет. Финансами, закупками, запасами и производством управляет ERP, то есть SAP. При хорошей интеграции менеджер по продажам видит в Salesforce остатки и статус оплаты, а финансовая служба видит в SAP стоимость сделки.

Какова главная причина сбоев интеграций ERP и CRM?

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

Как поддерживать интеграцию ERP и Salesforce со временем?

Запускайте автоматизированные регрессионные тесты критичных потоков перед каждым релизом Salesforce и каждым обновлением SAP. Контролируйте каждый критичный поток с помощью оповещений, которые срабатывают при сбое, а не в итоговом отчёте в конце дня. Назначьте владельца, у которого есть доступ к мониторингу и который участвует в планировании изменений для обеих систем.

Когда стоит использовать SAP Integration Suite для интеграции с Salesforce?

Когда SAP является доминирующей системой, у вас есть доступ к SAP BTP, а потоки включают специфичный для SAP контент, например IDocs, BAPIs или форматы сообщений SAP. Это более слабый выбор, если вы уже много вложили в MuleSoft или Boomi, если у вашей команды нет навыков интеграции SAP или если SAP играет второстепенную роль в потоках, где в основном другие системы. Для новых программ RISE, где в объём входит Salesforce, это естественная отправная точка.

Сколько длится проект интеграции ERP и Salesforce?

Стандартный объём (синхронизация основных данных клиентов, путь от предложения до заказа и базовый статус заказа) на готовом контенте обычно занимает от 8 до 16 недель от определения объёма до go-live, при условии чистых данных и выделенного разработчика интеграции. Полный цикл от предложения до оплаты со сложным ценообразованием, несколькими юридическими лицами, управлением кредитами и остатками в реальном времени обычно занимает от 4 до 9 месяцев. Обычные причины превышения сроков: проблемы с данными, обнаруженные посреди проекта, и потоки, добавленные во время разработки. Поэтому оценку качества данных нужно провести до начала разработки.