Как объединить данные из двух бизнес-систем без потери управляемости?

Чтобы объединить данные из двух бизнес-систем без потери управляемости, сначала нужно определить, какие записи станут общими, кто отвечает за каждую из них и как будет проверен результат на одном живом процессе. Перенос файла или настройка обмена — только середина работы. Если начать с неё, компания быстро получает две версии одной правды.

Это случается после внедрения новой CRM, объединения подразделений, запуска учётной системы или появления отдельного интернет-канала продаж. В одной базе клиент записан как «ООО Север», в другой — как «Север, ООО», а в третьей у него два разных менеджера. Технически всё можно склеить. Управленчески вопрос сложнее: что теперь считать правильной записью?

Не объединяйте всё подряд

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

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

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

Назначьте источник для каждого факта

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

Удобное правило звучит просто: для каждого поля есть место, где оно считается исходным. Остальные системы получают копию и не переписывают её молча. Такой подход не требует немедленно строить центральный справочник, но уже защищает от бесконечной ручной сверки. Подробнее о выборе такой точки я разбирал в материале «Что такое единый источник данных и как выбрать его для компании?».

Проверьте совпадения до загрузки

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

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

Начните с одного рабочего маршрута

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

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

Если процесс ещё не имеет владельца, сначала стоит решить этот вопрос. Практический порядок описан в статье о назначении владельца процесса перед автоматизацией. Интеграция не заменяет ответственность за результат.

Что контролировать после запуска

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

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

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

Как не остановить работу в день переключения

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

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

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

Короткий чек-лист

1. Назовите 3–7 сущностей, которые должны стать общими первыми.
2. Для каждой определите источник и владельца изменения.
3. Отделите уверенные совпадения от спорных.
4. Прогоните один живой маршрут на копии или ограниченной группе.
5. Договоритесь, кто увидит ошибку и как вернёт данные в порядок.

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

Связанные вопросы

• Как выбрать единый источник данных для компании?
• Что делать с дублями клиентов перед переносом?
• Как проверить, что интеграция не теряет заказы?
• Кто должен отвечать за качество справочников?