Четыре способа управлять мастер-данными

🌐 Также доступно на 28 языках

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Модуль 2 из 6 главы Мастер-данные и идентичность, глава 6 курса Data Architect. Каждый модуль самостоятелен. Назад: Один источник истины для каждого атрибута · Далее: Сопоставление, слияние и правила выживания

Вопрос, на который отвечает этот модуль: как организации управляют мастер-данными и какой стиль подходит?

Модуль 1 сказал, что полномочия назначаются атрибут за атрибутом. Теперь: что делать, когда эти атрибуты живут сразу в нескольких системах? Информация о клиенте в Salesforce, в ERP, в биллинге, в поддержке, может быть, в Data 360, может быть, в хранилище данных — и у каждой своя версия. Эту проблему пытается решить управление мастер-данными (MDM), и MDM — это не одна архитектура. Вы услышите о четырех шаблонах: реестр, консолидация, сосуществование и централизованная модель. Это не настройки продукта. Это четыре ответа на один вопрос: сколько полномочий у слоя мастеринга?

Начинайте с проблемы, а не с продукта

Люди слышат «MDM» и начинают присматривать MDM-продукт. Я бы начал с проблемы. Нам просто нужно знать, что несколько записей — это один и тот же клиент? Нам нужно одно объединенное представление для аналитики? Нам нужно решать, какие значения авторитетны, и отправлять их обратно в другие системы? Или мы хотим, чтобы одна центральная система создавала мастер-данные для всех? Очень разные требования, очень разные архитектуры.

Реестр: скажите мне, кто есть кто

Самый легкий шаблон. Реестр (registry) не заменяет источники. ERP хранит своего клиента, Salesforce — свою организацию, биллинг — своего клиента, а реестр выясняет, что эти записи представляют одну и ту же сущность: организация Salesforce 001…, клиент ERP SAP-43821 и клиент биллинга BILL-9127 относятся к одному клиенту. Источники остаются на месте и не перезаписываются. Теперь у вопроса «покажите мне все, что мы знаем об этом клиенте» есть ответ.

Но обратите внимание, на что реестр не отвечает. Salesforce говорит Main Street, 123, ERP — 125, биллинг — «123 Main St., Suite 200». Реестр знает, что они относятся друг к другу. Он не решает, какое из них должно измениться. Связывание — это не мастеринг.

По моему опыту, реестр — норма на проектах Salesforce, затем идут консолидация и сосуществование; чистое централизованное MDM встречается редко. Реестр распространен, потому что он неинвазивен. Вам не нужно перепроектировать каждую операционную систему, прежде чем получить пользу. Salesforce продолжает делать свое, ERP — свое, а вы добавляете слой идентичности. Это гораздо меньшее изменение, чем сказать каждой системе: «вы больше не управляете данными клиентов; теперь этим занимается новая центральная система».

Click to enlarge

Реестр отвечает: какие записи относятся к одной и той же сущности?

Консолидация: соберите данные вместе

Консолидация берет данные из нескольких источников и объединяет их в центральное представление — для отчетности, аналитики, сегментации, клиентской аналитики. Знакомый пример — хранилище данных: Salesforce отправляет клиента, ERP — финансовые данные, биллинг — платежи, и бизнес наконец может анализировать клиента сквозь все системы. Источники по-прежнему существуют и могут оставаться авторитетными. Направление важно: данные текут в консолидированную систему, которая обычно не отправляет обратно мастер-изменения. Лучшая картина клиента — без превращения в его операционный источник полномочий.

Реестр и консолидацию легко перепутать. Разница в том, что централизуется: реестр централизует идентичность («это относится друг к другу»); консолидация централизует больше данных («соберем атрибуты вместе, чтобы ими пользоваться»). Ни то ни другое не говорит: «эта центральная система теперь мастер, и каждое приложение должно принимать ее значения».

Click to enlarge

Консолидация собирает данные вместе, не отбирая владение у источников.

Сосуществование: решите и отправьте обратно

При сосуществовании (coexistence) слой мастеринга получает настоящие полномочия. Данные по-прежнему живут в нескольких операционных системах, но процесс MDM решает, каким будет мастер-значение, и публикует его обратно. У Salesforce, ERP и биллинга разные юридические названия; процесс MDM определяет управляемое и распространяет его во все три. Системы сосуществуют, но сходятся на мастер-значении.

Это гораздо более сильная форма MDM. Она не говорит «это относится друг к другу»; она говорит «для этого атрибута предприятие использует вот это значение». Для этого нужно больше, чем сопоставление: бизнес-правила, владение, правила выживания значений, двусторонняя интеграция, обработка ошибок и управление данными — ведь кто-то должен решить, почему побеждает одно значение.

Click to enlarge

Сосуществование не просто связывает записи. Оно решает, какими будут мастер-значения, и отправляет их обратно.

Централизованная модель: мастер создает истину

Самый сильный шаблон. При централизованном MDM управляемые мастер-данные создаются и сопровождаются в центральном мастере и распространяются всем остальным. Вместо того чтобы каждая система создавала своего клиента, а MDM потом их согласовывало, вы создаете управляемого клиента в мастере, а затем отправляете его в Salesforce, ERP и биллинг. Очень сильное управление и очень значительные изменения: существующие процессы создают собственных клиентов, у пользователей свои рабочие процессы, интеграции рассчитывают на локальное создание, а подразделения могут даже не сходиться в том, что такое клиент. Поэтому в ландшафтах Salesforce, которые я вижу, это редкость. Это может быть правильным. Но это гораздо большее решение, чем установка инструмента.

Click to enlarge

Централизованное MDM переносит создание и полномочия в мастер.

Все четыре рядом

Стиль	Что централизовано	Остаются ли источники?	Отправляет ли управляемые значения обратно?
Реестр	Идентичность и связи	Да	Обычно нет
Консолидация	Идентичность плюс объединенные данные	Да	Обычно нет
Сосуществование	Идентичность, данные и мастер-решения	Да	Да
Централизованная модель	Создание и полномочия	Да, как потребители	Да

Чем ниже по таблице, тем больше полномочий у слоя мастеринга — и тем больше обычно приходится меняться организации.

Знать к экзамену. Знайте четыре стиля внедрения MDM: реестр (связывает идентичности; источники сохраняют свои данные), консолидация (собирает данные вместе, обычно для анализа), сосуществование (решает, какими будут мастер-значения, и публикует их обратно в источники) и централизованная модель (мастер создает данные; источники их потребляют).

Поэтому нет никакого «централизованная модель самая зрелая, значит, всем надо к ней прийти». Выбирайте самый легкий шаблон, который решает проблему. Нужно знать, что записи относятся друг к другу? Думайте о реестре. Объединенное представление для аналитики? Консолидация. Управляемые значения, синхронизируемые обратно в несколько операционных систем? Сосуществование. Один процесс, который создает и контролирует мастер-данные для всех? Централизованная модель.

Где здесь Data 360?

Data 360 строит унифицированные профили по многим источникам, что очень похоже на MDM, и он действительно решает часть проблемы. Его разрешение идентичности сопоставляет исходные профили в унифицированную идентичность и сохраняет связи с исходными записями (Data 360 Architecture (opens in a new tab)). Это делает его ближе всего к реестру. Он также может показывать согласованные значения в унифицированном профиле. Но это не делает его централизованной системой золотых записей, которая переписывает источники. Унифицированное представление — не то же самое, что автоматически мастер-запись предприятия. Модуль 4 целиком посвящен этой разнице.

Общая модель — это не общая истина

Вы также услышите о канонической модели данных. Организация (Account) в Salesforce, бизнес-партнер в ERP и клиент в биллинге отображаются в одно согласованное корпоративное понятие — «Клиент» — с согласованными идентификаторами и атрибутами, чтобы каждой интеграции не приходилось понимать структуру всех остальных систем. Модель данных Data 360 — пример гармонизации источников в общие понятия. Но каноническая модель отвечает на вопрос как нам представлять это единообразно?, а MDM — на вопрос как нам идентифицировать это, управлять им и вести его как мастер-данные во всех системах? Отобразите все три системы идеально в одну структуру «Клиент» — и Salesforce все равно будет говорить Main Street, 123, а ERP — 125. Вы решили вопрос структуры, а не полномочий. Гармонизация и мастеринг не взаимозаменяемы.

Один бизнес, несколько шаблонов

Поэтому «Steve Trucking нужно MDM» — это не требование. Для чего? Розничные партнеры, распределительные центры, бригады, грузовики, получатели — это разные домены с разными полномочиями: розничные партнеры управляются в Salesforce и финансовой ERP, идентичность грузовиков приходит из FleetLink, каждого получателя предоставляет партнер для каждой доставки. Разные домены могут использовать разные шаблоны, а внутри домена у атрибутов могут быть разные источники полномочий. Так что не рисуйте прямоугольник с надписью MDM посреди диаграммы, считая вопрос решенным. Спросите, что этот прямоугольник делает.

Стиль меняет и интеграцию. Реестру нужны связи идентичности; консолидации — надежные входящие потоки; сосуществованию — данные в обоих направлениях; централизованной модели — распространение из мастера плюс средства контроля, которые не дают другим системам создавать конкурирующую истину. Чем больше полномочий, тем больше координации и тем сложнее обработка сбоев: что, если MDM меняет юридическое название, а ERP его отклоняет? Вот почему сосуществование и централизованная модель — не «реестр с дополнительными функциями». У них другие операционные обязанности.

MDM — это бизнес-решение

Самое важное: MDM по своей сути не технологическое решение. Это решение о полномочиях. Кто создает клиента, кто может его менять, кто решает, какое значение побеждает, какие системы должны его принимать, что происходит, когда они не согласны. Инструмент может воплотить эти решения; он не может заставить организацию о них договориться. Поэтому проект MDM может иметь отличную технологию и все равно провалиться: техническая команда решила задачу сопоставления, а бизнес так и не решил вопрос владения.

Общий урок, который я выучил на собственном горьком опыте: когда несколько систем являются мастерами одних и тех же данных, Salesforce не может согласовать то, в чем они сами не согласны. Когда у компании две ERP, я спрашиваю, как они поддерживают их синхронизацию. Если они не могут, то и Salesforce не сможет. Модуль 5 рассказывает эту историю (Один клиент, две ERP).

Что здесь решает архитектор

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

Когда кто-то рисует на диаграмме прямоугольник MDM, спросите, что он делает. Знает, какие записи относятся друг к другу? Объединяет их данные? Решает, какие значения побеждают? Отправляет эти решения обратно? Создает данные изначально? Ответы скажут вам, какая архитектура у вас на самом деле и где живут полномочия.

Дополнительно

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (на английском, проверено 2026-10-14).