Интеграция систем: от передачи данных до управляемого обмена

Менеджер видит заказ в CRM, склад — резерв в WMS, финансы — сумму в ERP. Пока сведения переносят вручную, три системы описывают одну операцию по-разному. Интеграция систем устраняет не сам факт раздельного хранения, а разрыв между событиями, данными и ответственностью за их обработку.

Интеграция — это управляемый обмен между приложениями. Для каждого обмена определяют бизнес-объект, момент запуска, формат, получателя, правила контроля и восстановление после ошибки. API или файловая выгрузка — только транспорт.

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

Начинать нужно с бизнес-события

Фраза «соединить CRM с ERP» не задаёт проект. Полезное описание звучит конкретнее: после согласования заказа передать его актуальную версию в ERP, вернуть номер, сохранить связь идентификаторов и сообщить владельцу процесса, если обработка не завершилась.

Для каждого сценария ответьте на вопросы: что является источником истины; какое событие запускает обмен; допустима ли задержка; как распознать повтор; кто исправляет данные; как сверить итог.

Подходы к обмену

В одной архитектуре подходы сочетаются. Онлайн-проверка лимита может работать синхронно, а передача событий для аналитики — через очередь.

Один заказ — несколько состояний

Рассмотрим заказ клиента. CRM отвечает за коммерческую работу и хранит согласованные условия. ERP регистрирует финансовые и учётные данные, WMS подтверждает резерв и отгрузку, а процессная система координирует действия сотрудников. Интеграция не должна механически копировать всю карточку во все приложения. Она передаёт только тот срез, который нужен следующему участнику, и возвращает значимые изменения.

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

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

Паспорт обмена вместо устной договорённости

Паспорт связывает технический интерфейс с процессом и описывает, как команда поймёт, что обмен действительно завершён.

Данные требуют отдельного управления

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

Особое внимание нужно версиям. Если заказ изменился во время обработки, получатель должен понимать, применить ли новую версию, отклонить устаревшую или собрать изменения по порядку.

Границы ответственности

У интеграционного сценария обычно несколько владельцев. Бизнес-владелец определяет ожидаемый результат и допустимую задержку. Владелец данных отвечает за значение полей и справочники. Команда приложения гарантирует корректную обработку на своей стороне, а интеграционная команда — доставку, преобразование и наблюдаемость. Эти роли нельзя сводить к одному безымянному «ИТ».

При инциденте маршрутизация должна опираться на причину. Недоступный сервис получает техническая поддержка; неизвестный код подразделения — владелец справочника; заказ, нарушающий коммерческое правило, — ответственная роль процесса. Такая классификация сокращает пересылку заявок между командами и позволяет увидеть повторяющиеся дефекты источника.

Ошибки — штатная ветка процесса

Надёжная интеграция проектируется с ожиданием отказов. Сеть недоступна, формат изменился, справочник не содержит значения, ответ пришёл дважды. Для каждого класса ошибки задают автоматический повтор, карантин, уведомление или ручное исправление.

• не терять исходное сообщение и идентификатор операции;
• не создавать дубль при повторной доставке;
• отделять технический сбой от ошибки бизнес-правила;
• давать специалисту контекст и безопасный перезапуск;
• сверять количество и итоговые суммы между системами.

Показатели рабочего контура

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

Порядок внедрения

1. Составьте карту систем и владельцев.
2. Выберите критичные бизнес-события.
3. Опишите объекты и источник истины.
4. Сформируйте паспорт каждого обмена.
5. Спроектируйте ошибки и восстановление.
6. Проведите тесты нормального, повторного и аварийного сценариев.
7. Настройте мониторинг бизнес-результата.

Частые вопросы

Интеграция и миграция данных — одно и то же?

Нет. Миграция переносит набор данных, обычно однократно; интеграция поддерживает обмен при дальнейшей работе.

Всегда ли нужна интеграционная платформа?

Нет. Решение зависит от числа интерфейсов, требований к маршрутизации, мониторингу и повторному использованию.

Что такое идемпотентность?

Способность повторно обработать один запрос без появления второго бизнес-результата, например дублирующего заказа.

Какая система должна быть источником истины?

Это определяют отдельно для каждого объекта и этапа его жизненного цикла.

Можно ли интегрировать старую систему?

Да, если доступен устойчивый механизм обмена и понятны ограничения; иногда используют адаптер или контролируемый файловый канал.

Когда интеграция считается готовой?

После проверки обмена, мониторинга, восстановления, документации и назначения владельцев, а не после первого успешного запроса.

Похожие записи:

Итоги конференции CNews «Роботизация бизнес-процессов 2021» Нотация BPMN 2.0: ключевые элементы и описание 3 мифа о BPM и BPMS Почему данные – это НЕ новая нефть: пик экономики, основанной на применении искусственного интеллекта