Краткий ответ
Управление основными данными (Master Data Management – MDM) – это не хранилище, а соглашение. Это соглашение определяет, кто создает сущность, кто имеет право ее изменять, как идентифицировать две записи как одну и ту же сущность, и что происходит при расхождении данных в разных системах. Технология лишь обеспечивает соблюдение согласованных правил.
Распространенная ошибка – начинать с выбора инструмента. Организация, которая не определила, что такое "клиент", получит инструмент, который консолидирует ту же неопределенность, только быстрее и дороже.
Что относится к Master Data, а что нет
| Тип данных | Пример | Является Master Data |
|---|---|---|
| Основные данные (Master Data) | Клиент, продукт, поставщик, адрес | Да |
| Справочные данные (Reference Data) | Страны, валюты, отраслевые коды | Отдельное, более простое управление |
| Транзакционные данные (Transactional) | Заказ, счет, обращение (Case) | Нет |
| Аналитические данные (Analytical) | Сегментация, скоринг, прогноз | Нет – являются производными |
Это различие важно, поскольку каждый тип требует особого подхода к управлению. Справочные данные контролируются в небольшой таблице с одним владельцем; транзакционные данные остаются в системе, которая их создает; аналитические данные не должны становиться источником истины, поскольку они являются результатом вычислений, которые могут меняться.
Три стиля реализации
Registry – Управление только таблицей идентификаторов, связывающей записи в различных системах. Это дешево, быстро, не требует изменений в существующих системах, и обеспечивает единое представление для чтения. Почти всегда подходит в качестве первого шага.
Consolidation – Создание "золотой записи" (Golden Record) для целей отчетности и анализа, без обратной синхронизации данных в исходные системы. Подходит, когда основная проблема – дублирующаяся отчетность.
Centralized – Master Data становится обязательным источником истины, а системы потребляют данные из него. Это обеспечивает наибольшую ценность, но также предъявляет самые высокие требования к управлению данными и процессам утверждения. Организации, которые сразу переходят к этому стилю, обнаруживают, что у них нет ответственных лиц (Stewards) для его поддержания.
Практический подход – это постепенное масштабирование: Registry для одной сущности, а затем расширение – на основе доказанной ценности, а не грандиозного плана.
Survivorship: Правила, определяющие, что сохраняется
Ядром Golden Record являются правила Survivorship на уровне полей: для каждого поля определяется предпочтительный источник и резервное правило на случай, если предпочтительный источник пуст. При этом всегда сохраняются идентификаторы из исходных систем, чтобы можно было объяснить каждое значение.
Принцип, который помогает избежать споров: Golden Record не удаляет исходные записи и не претендует на их замену. Это слой, который ссылается на них. Это означает, что можно изменить правило и пересчитать данные – возможность, которой нет у тех, кто интегрировал все на стадии загрузки.
Дополнительные сведения о принятии решений о владении данными представлены в статьях Источник истины в организации и предшествующей ей Устранение дубликатов в Salesforce.
Stewardship: Роль, определяющая успешность
Любая система MDM генерирует очередь решений: совпадения, в которых система не уверена, запросы на создание новой сущности и противоречия между источниками. Если нет человека, выделяющего время на работу с этой очередью, она будет расти, пока ее не перестанут замечать.
Реальный объем: в средней организации это несколько часов в неделю на одну сущность, как правило, для сотрудника из бизнес-подразделения, а не из IT. Именно эти инвестиции определяют, будет ли MDM жить или превратится в "тихую инфраструктуру".
Сценарий: Производитель с тремя системами и одним клиентом
Промышленный производитель хранил данные о клиентах в трех системах: ERP, Salesforce и системе обслуживания. Одна и та же корпорация могла быть представлена как три разные сущности, и отчет "Доход на клиента" составлялся вручную в Excel раз в квартал.
Вместо полноценного проекта MDM организация начала с Registry: была создана таблица идентификаторов в Data 360, которая связала три записи с помощью ИНН и вторичного ключа, и только после этого был создан Golden Record для чтения. Salesforce не изменил свою структуру; он получил поле глобального идентификатора и представление "Вся активность по группе".
Результат через квартал: ручной отчет был отменен, а менеджеры по продажам впервые увидели кредитное покрытие на уровне группы – что привело к одному решению о ценообразовании, окупившему стоимость начального этапа. Расширение до Centralized рассматривалось только после того, как было доказано наличие ответственного Stewarda, который фактически обрабатывал очередь.
Распространенные риски и профилактические меры
| Риск | Как проявляется на практике | Превентивные меры |
|---|---|---|
| Начало с выбора инструмента | Объединенное хранилище, отражающее существующую неопределенность | Определения сущностей и ответственных перед выбором инструмента |
| Слишком много сущностей | Длительный проект без видимой ценности | Одна сущность до перехода в эксплуатацию, затем расширение |
| Отсутствие Stewarda | Очередь совпадений, которая растет и игнорируется | Должность с выделенным временем и SLA |
| Деструктивное слияние | Невозможно объяснить или восстановить значение | Сохранение исходных идентификаторов и возможность пересчета |
| Преждевременное Centralized | Все системы зависят от незрелой инфраструктуры | Начинать с Registry |
Как измерять успех
| Область | Что измерять | Частота проверки |
|---|---|---|
| Покрытие | Процент записей, связанных с глобальным идентификатором | Ежемесячно |
| Точность | Доля отмененных или исправленных связей | Ежемесячно |
| Очередь Stewardship | Количество открытых элементов и среднее время закрытия | Еженедельно |
| Бизнес-ценность | Отмененные ручные отчеты, решения на уровне группы | Ежеквартально |
Построение многоуровневой системы MDM осуществляется в рамках услуги по интеграции и работе с данными.
Контрольный список перед запуском MDM
- ☐ Выбрано до трех сущностей для первого этапа.
- ☐ Для каждой сущности существует письменное бизнес-определение.
- ☐ Выбран стиль реализации: Registry, Consolidation или Centralized.
- ☐ Определены надежные ключи идентификации для каждого источника.
- ☐ Написаны правила Survivorship на уровне полей.
- ☐ Исходные идентификаторы сохраняются и позволяют пересчитывать данные.
- ☐ Назначен Steward с выделенным временем и SLA.
- ☐ Определен процесс утверждения для создания новой сущности.
- ☐ Определен один показатель ценности для первого этапа.
- ☐ Принято решение о том, когда рассматривать выделенный инструмент.
Профессиональные ресурсы
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Интеграции и данные — https://hpi.pro/integrations-data