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