Цифры между системами расходятся не потому, что “интеграция плохая” в общем смысле. Обычно у конкретной сущности нет единого владельца и определения: системы считают разные статусы, обновляются в разное время, не имеют общего ID или получают часть данных вручную
Шесть причин, из-за которых данные расходятся
автоматизация обработки данных работает только при согласованных данных. Поэтому интеграция CRM и управленческая отчётность нужно строить на понятном источнике, ID и правилах обновления
| Причина | Как выглядит | Что проверить |
|---|---|---|
| Разная семантика | В CRM “выручка” одна, в учёте другая | Определение показателя и момент признания |
| Разные статусы | Сделка закрыта, заказ ещё не проведён | Маппинг статусов между системами |
| Нет общего ID | Один клиент создан несколько раз | Уникальный идентификатор и правила дедупликации |
| Разное время обновления | Утром отчёты не совпадают, вечером сходятся | Расписание синхронизации и cut-off |
| Ручные изменения | Excel корректирует цифру после выгрузки | Кто меняет значение и почему |
| Разная гранулярность | CRM считает сделки, ERP - отгрузки | На каком объекте сравниваются данные |
Соберите lineage одной цифры
Не начинайте с “всех данных компании”. Возьмите один спорный показатель - например, количество оплаченных заказов - и разложите его по цепочке происхождения
| Поле | Master-система | Преобразование | Кто использует |
|---|---|---|---|
| ID клиента | CRM | Передаётся без изменения | Продажи, поддержка |
| ID заказа | Учётная система | Связывается с CRM deal ID | Финансы, операции |
| Статус оплаты | Учётная система | Преобразуется в paid/unpaid | Управленческий отчёт |
| Канал | CRM | Нормализуется по справочнику | Маркетинг, продажи |
Такой data lineage быстро показывает точку, где данные начинают расходиться. Иногда проблема вообще не в интеграции: две команды просто используют разные определения одного показателя
Как исправлять без гигантского data-проекта
- Назначьте master-систему для каждой ключевой сущности. Клиент, заказ, платёж, продукт и ответственный не должны иметь по три равноправных источника
- Зафиксируйте справочник статусов. Между системами нужен явный mapping, а не устная договорённость аналитиков
- Введите технические идентификаторы. Сопоставлять объекты по названию компании или телефону ненадёжно
- Уберите ручные корректировки из финального отчёта. Если корректировка нужна, она должна быть отдельным контролируемым событием
- Автоматизируйте проверки качества. Система может сама показывать записи без ID, конфликт статуса или несинхронизированное значение
Пример: “выручка CRM” против “выручки учёта”
В CRM менеджер может закрыть сделку как успешную после подписания договора. В бухгалтерской системе выручка появляется после другого события. Если сравнить эти цифры в один день без общего определения, они обязаны расходиться. Исправлять API здесь бессмысленно - сначала нужно решить, какой вопрос отвечает каждый отчёт
После этого автоматизация данных становится гораздо проще: вы не пытаетесь заставить две разные бизнес-логики выдавать одну цифру, а строите понятную трансформацию между ними
Какие данные нужны для проверки
Один спорный показатель и его бизнес-определение - первая точка, которую стоит зафиксировать до любых изменений. Рядом соберите ID объектов в каждой системе, а затем timestamps обновления, маппинг статусов и список ручных корректировок за период. Все значения должны относиться к одному типу потока и сопоставимому периоду, иначе сезонность и разный состав кейсов исказят вывод
- Один спорный показатель и его бизнес-определение
- ID объектов в каждой системе
- Timestamps обновления
- Маппинг статусов
- Список ручных корректировок за период
После исправления сделайте контрольную выборку не только в день запуска интеграции, но и на границе периода. Именно cut-off, отмены и поздние изменения часто возвращают расхождения, которые не видны на обычных тестовых данных
Сравнение доля записей без общего ID и число ручных сверок лучше делать на ограниченном типовом потоке: сначала снять базовую точку по «Один спорный показатель и его бизнес-определение» и «ID объектов в каждой системе», затем изменить один механизм и повторить замер. Так проще отделить эффект процесса от изменения спроса, состава команды или структуры входящего потока
Как проверить качество после исправления
Связка доля записей без общего ID, число ручных сверок, время до согласованного отчёта, количество конфликтов источника показывает, дошло ли улучшение до результата целиком. Одна красивая локальная метрика недостаточна: если скорость выросла ценой качества, backlog переместился дальше или экономия не превращается в usable capacity, гипотезу нужно пересчитать
Хотите найти, где именно расходятся данные?
Покажите один показатель и системы, из которых он собирается. Мы поможем пройти путь данных от источника до отчёта и определить, где нужна договорённость, интеграция или автоматическая проверка
Частые вопросы
Как выбрать единую master-систему?
Для каждой сущности выбирайте систему, где она создаётся и управляется в основном бизнес-процессе. Остальные системы должны получать идентификатор и необходимые атрибуты из неё
Нужно ли строить Data Warehouse, чтобы цифры сходились?
Не обязательно. Для ограниченного набора ключевых показателей часто достаточно master-data правил, единого ID, понятных трансформаций и автоматизированной синхронизации
Почему цифры расходятся даже при интеграции API?
API передаёт данные, но не исправляет разные определения, статусы, момент обновления и дубли объектов. Семантика процесса должна быть согласована отдельно
Как убрать ручные сверки между системами?
Сначала определить правила сопоставления и допустимые расхождения, затем автоматизировать match и выводить человеку только исключения
