Как объединить несколько систем в один контур

В большинства компаний информационная система не появляется за один день.

Сначала запускают сайт.

Потом появляется CRM.

Для бухгалтерии и учёта используется 1С.

Затем компания внедряет ERP.

На складе возникает отдельная система.

Для производства появляется собственное программное обеспечение.

Для отдельных задач сотрудники создают внутренние сервисы и таблицы.

Каждая система решает свою задачу, и на момент её появления это кажется вполне логичным.

Проблемы начинаются позже.

Клиент существует одновременно в CRM и ERP.

Товар есть в 1С, на сайте и на складе.

Заказ появляется на сайте, затем попадает в CRM, а после — в учётную систему.

Сотрудник меняет данные в одном месте, но в другом они остаются прежними.

В результате компания получает не единую информационную среду, а набор отдельных островов:

Задача интеграции в такой ситуации — не просто провести между ними несколько API-соединений.

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

Единый контур не означает одну систему

Это первое, что важно определить.

Единый информационный контур — это не ситуация, когда CRM, ERP, сайт и склад превращаются в одну программу.

Наоборот, системы могут оставаться разными.

Например:

У каждой системы остаётся собственная задача.

Единым становится не программное обеспечение, а движение информации.

Начинать нужно не с API

Когда перед проектной командой стоит задача «объединить системы», первая ошибка — сразу составлять список API.

Получается примерно:

Технические связи есть.

Но никто ещё не ответил на главный вопрос:

Поэтому сначала описывают бизнес-процессы.

Например:

А уже потом для каждого этапа определяют, какая система в нём участвует.

Карта ответственности важнее карты интеграций

Для каждого объекта нужно определить владельца.

Например:

Конкретное распределение зависит от бизнеса.

Главное — чтобы оно существовало.

Если одна и та же сущность может свободно изменяться в пяти системах, единый контур быстро превращается в систему конфликтов.

Например:

Это ещё не проблема.

Проблема возникает, если никто не знает, какое из этих значений является главным.

Один объект должен иметь устойчивую идентичность

При объединении систем практически сразу возникает вопрос идентификаторов.

В CRM клиент может иметь:

В ERP:

В 1С:

На сайте:

Если просто передавать эти значения между системами, очень легко потерять соответствие.

Поэтому появляется единый слой сопоставления:

Это позволяет понимать, что четыре технических записи относятся к одному клиенту.

То же самое необходимо для товаров, заказов, складских единиц, документов и других сущностей.

Почему нельзя связывать всё напрямую

Если систем три, прямые интеграции ещё можно поддерживать:

Но при добавлении новых компонентов количество связей начинает быстро расти.

Пусть есть шесть систем.

Если каждая система потенциально общается с каждой, архитектура становится похожей на клубок:

И проблема здесь не только в количестве соединений.

Каждая связь начинает содержать собственные:

Через несколько лет никто уже не знает, почему конкретное поле передаётся именно таким образом.

Интеграционный слой собирает хаос в управляемую архитектуру

Вместо десятков прямых соединений можно использовать промежуточный слой:

Теперь каждая система взаимодействует с контролируемым слоем.

Он знает:

Это уже не набор интеграций.

Это архитектура обмена.

Единая модель данных не означает одинаковые базы

Очень важно не перепутать эти понятия.

У ERP может быть собственная структура:

У сайта:

У складской системы:

Не нужно заставлять все три системы хранить одинаковые таблицы.

Вместо этого определяют общую бизнес-модель:

А затем каждая система получает только те данные, которые ей необходимы.

Нормализация становится критичной, когда систем много

Представим единицу измерения.

В одной системе:

В другой:

В третьей:

Для человека очевидно, что речь об одном.

Для автоматической системы — три разных значения.

То же самое происходит с:

Поэтому интеграционный контур должен содержать правила нормализации.

Например:

А уже конкретная система получает свой формат.

Справочники требуют особого внимания

Есть данные, которые выглядят незначительными, но способны ломать обмен.

Например, справочник способов оплаты.

В CRM:

В ERP:

На сайте:

Если не создать соответствие, данные начнут расходиться.

Поэтому для справочников часто создают отдельную таблицу mapping:

И это правило становится частью архитектуры, а не ручной договорённостью разработчиков.

Что делать со старыми системами

В реальном бизнесе редко бывает возможность сказать:

Чаще есть:

При этом старые системы продолжают выполнять критичные операции.

Поэтому интеграция должна учитывать legacy.

Иногда правильное решение выглядит так:

А не попытка переписать всё одновременно.

Адаптер позволяет изолировать старую систему

Допустим, старый сервис отдаёт XML:

А современные сервисы работают с JSON.

Необязательно заставлять всю архитектуру поддерживать старый формат.

Можно сделать адаптер:

Теперь устаревшая система остаётся на месте, но её особенности не распространяются на весь контур.

Типовые архитектурные решения становятся критичными при постепенной модернизации.

События помогают синхронизировать системы

Представим, что заказ изменился.

Вместо постоянного опроса можно передать событие:

А дальше:

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

Например, склад обновляет задание на комплектацию, CRM меняет статус сделки, а сайт показывает клиенту новое состояние заказа.

Так одна операция может запускать несколько процессов без жёсткой связи между всеми системами.

Но события не заменяют контроль

Событийная архитектура не означает, что можно забыть о сверках.

Даже надёжный обмен может столкнуться с:

Поэтому важно иметь возможность ответить:

Например:

Причина уже видна.

Без такого журнала поиск проблемы превращается в ручное расследование.

Очередь защищает контур от временных проблем

Если одна система недоступна, остальные не должны обязательно останавливать работу.

Например:

После восстановления:

Так система становится устойчивой к временным сбоям.

Для критичных операций это особенно важно.

Нужно разделять синхронные и асинхронные операции

Не всё должно ждать ответа другой системы.

Например, при открытии карточки клиента сотруднику может требоваться мгновенный ответ:

Здесь синхронный запрос логичен.

Но если нужно передать 20 000 изменений товаров, ждать каждую операцию отдельно бессмысленно.

Там лучше использовать:

Выбор механизма зависит от бизнес-требований.

Вопрос должен звучать не:

А:

«Насколько быстро данные должны стать доступными и что произойдёт, если получатель временно недоступен?»

Нельзя допускать бесконечного распространения изменений

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

Допустим:

CRM получила изменение и автоматически отправила его обратно:

ERP снова считает это новым изменением.

И начинается цикл:

Поэтому каждое событие должно иметь контекст:

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

Версии данных помогают решать конфликты

Иногда две системы изменяют один объект практически одновременно.

Например:

CRM изменила объект.

ERP тоже изменила объект.

Теперь нужно понять, какое изменение новее или приоритетнее.

Для этого может использоваться версия:

или временная метка, или другой механизм контроля.

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

Единый контур должен иметь наблюдаемость

Чем больше систем, тем меньше смысла в проверке отдельных серверов.

Нужно видеть состояние процесса целиком.

Например:

А по конкретному заказу:

Это уже мониторинг бизнес-процесса, а не просто мониторинг инфраструктуры.

Единый контур не должен означать единую точку отказа

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

Поэтому для критичных решений учитывают:

Например:

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

Безопасность становится сложнее с каждой новой системой

Каждая новая связь — это новый канал доступа.

Если есть:

то необходимо понимать:

Например, мобильному приложению инженера не обязательно давать доступ ко всей ERP.

Ему нужны только:

Минимально необходимый доступ значительно безопаснее полного доступа к системе.

Не каждый обмен должен быть двусторонним

Это ещё один важный архитектурный принцип.

Если ERP является владельцем цен, нет смысла позволять сайту менять их обратно.

Правильнее:

А не:

То же самое с остатками, статусами и другими данными.

Чем меньше двусторонних изменений, тем проще система.

Одно направление передачи часто намного надёжнее двухсторонней синхронизации.

Что делать, если одна система должна исчезнуть

При хорошей архитектуре замена одного компонента не должна означать переписывание всего контура.

Например:

Заменяем CRM:

Если контракт между системами сохранён, остальная архитектура почти не меняется.

Именно поэтому интеграционные контракты важнее конкретной реализации одного приложения.

Единый контур строят постепенно

Необязательно интегрировать сразу всё.

Более разумный подход:

Так можно постепенно объединять архитектуру, не останавливая действующий бизнес.

Почему попытка интегрировать всё сразу часто проваливается

Когда компания решает:

обычно недооцениваются старые зависимости.

Если просто соединить API, вся эта историческая сложность никуда не исчезнет.

Она перейдёт внутрь интеграции.

Поэтому перед объединением часто приходится сначала привести в порядок сами данные и правила работы с ними.

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

Если в исходной системе:

то после интеграции не появится автоматически один клиент.

Наоборот, проблема может распространиться на несколько систем.

Поэтому для критичных сущностей необходимы правила:

Иногда именно качество данных оказывается более сложной задачей, чем техническое соединение систем.

Как выглядит действительно связанный контур

В зрелой архитектуре путь данных можно проследить от начала до конца.

Например:

Ни один этап не существует отдельно.

Но и ни одна система не обязана знать всё обо всех остальных.

Именно в этом заключается зрелый единый контур.

Что получает бизнес после объединения систем

При правильно спроектированной архитектуре меняется не только техническая сторона.

А главное — данные начинают двигаться вместе с бизнес-процессом.

Итог

Объединить CRM, ERP, 1С, склад, сайт и внутренние сервисы в единый информационный контур — это не задача «подключить несколько API».

Сначала необходимо определить:

После этого архитектура начинает выглядеть совсем иначе:

Но настоящая ценность находится не в самой схеме.

Она в том, что за каждым соединением стоят понятные правила движения информации.

Хороший информационный контур делает системы не одинаковыми, а согласованными.

Каждая сохраняет свою специализацию, но бизнес получает единое информационное пространство, в котором данные последовательно проходят весь путь — от возникновения до конечного результата.

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

Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).