Не начинайте с проекта «синхронизируем всё со всем»
Допустим, руководитель спрашивает, сколько у компании активных клиентов. CRM (CRM) показывает 1 240, учётная система - 1 187, финансовая таблица - 1 151. Это условный пример: три отдела могут защищать свои числа, потому что один считает открытые сделки, другой - покупки за 90 дней, третий - действующие договоры. Исправный обмен сам по себе не сделает эти показатели одинаковыми
Шесть причин, из-за которых цифры расходятся
Для диагностики в этой статье используем авторскую рабочую схему из шести классов причин; паспорт показателя ниже — шаблон для воспроизводимого расчёта, а не универсальный стандарт MDM.
| Причина | Пример | Как проверить |
|---|---|---|
| Разное определение | «Активный клиент» означает открытый договор в одном отчёте и недавнюю покупку в другом | Сверить условия, по которым клиент попадает в показатель |
| Разный объект учёта | Компания, контакт и заказ считаются как равнозначные записи | Установить, что представляет одна строка и что именно нужно считать |
| Разные даты и границы периода | Один отчёт отбирает сделки по дате создания, другой - по дате оплаты | Согласовать дату события, начало и конец периода, часовую зону |
| Разные идентификаторы | Один клиент заведён дважды или имеет разные коды в системах | Проверить ключи, их соответствие и правила объединения дублей |
| Преобразования | Фильтр, ручная формула, округление или разный учёт возвратов меняют итог | Проследить расчёт и исключения от источника до отчёта |
| Разная свежесть данных | Один отчёт включает новые операции, в другой они ещё не загружены | Сравнить охваченный период и время последней полностью успешной загрузки |
Таблицу можно прокручивать по горизонтали
Причины могут сочетаться: например, часть клиентов задвоена, а часть оплат ещё не попала в отчёт. Поэтому метка «проблема интеграции» пока слишком широка - нужно установить, какие записи и на каком шаге изменили итог
Паспорт показателя: семь строк для воспроизводимого расчёта
Ниже - пример определения для обсуждения, а не универсальное правило активности клиента. В нём оплаченная поставка учитывается по дате отгрузки; частичная оплата сама по себе ещё не делает клиента активным
| Показатель | Активные клиенты |
|---|---|
| Определение | Юридические лица хотя бы с одной поставкой, отгруженной за 90 завершённых календарных дней перед датой расчёта и полностью оплаченной к моменту отсечения |
| Единица учёта | Уникальное юридическое лицо, а не контакт, договор или группа компаний |
| Первичный источник события | Документы отгрузки и связанные с ними подтверждённые оплаты в учётной системе |
| Идентификатор | Единый внутренний код юридического лица с таблицей соответствия кодам других систем |
| Преобразования | Исключаются тестовые, аннулированные и полностью возвращённые поставки; несколько подходящих поставок одного клиента считаются один раз |
| Момент отсечения и владелец | 00:00 выбранной даты расчёта по московскому времени; события на этой границе в период не входят. Определение и изменения согласует финансовый директор |
Таблицу можно прокручивать по горизонтали
Если бизнесу нужно другое определение - например, учитывать частичную оплату или активность всей группы компаний, - это стоит явно записать. Иначе люди будут обсуждать одно название, подразумевая разные расчёты
Если проблема системная и один факт редактируется в нескольких местах, следующий шаг — определить ответственный источник правды и правила разрешения конфликтов.
Идите от отчёта назад, пока не дойдёте до события
Совпадение общей суммы ещё не означает совпадение данных: пропуск одной операции может компенсироваться дублем другой. Поэтому итог сверяют вместе с составом записей
Порядок исправления важнее выбора платформы
- Согласовать определение показателя, единицу учёта и период
- Назначить источник для каждого факта: где подтверждается оплата, кто ведёт карточку клиента, где фиксируется отгрузка
- Сопоставить идентификаторы и установить правила объединения дублей
- Записать преобразования и момент отсечения, включая возвраты, отмены и поздние исправления
- Настроить обмен и контроль полноты обновления, чтобы успешный запуск задания не путали с успешной загрузкой всех данных
- Добавить регулярную сверку с объяснением допустимых различий и ответственным за остальные
Для справочников клиентов и других основных данных этот подход связан с управлением мастер-данными: согласованными записями без дублей, на которые опираются остальные системы. Microsoft описывает такой принцип в документации по MDM. Но справочник сам по себе не задаёт формулу выручки или границы отчётного периода - их нужно согласовать отдельно [1]
Источники и границы выводов
Шесть причин, паспорт показателя и порядок разбора - авторские рабочие инструменты. Числа клиентов и определение активности приведены как условные примеры, не как результаты диагностики клиента.
- Microsoft Learn: управление основными данными в Microsoft Purview - согласование основных записей, объединение дублей и стандартизация данных. Документация обновлена 24 апреля 2026 года; она не подтверждает частоту ошибок или универсальность предложенного здесь паспорта показателя
