Один источник истины для каждого атрибута

🌐 Также доступно на 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)

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

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

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

Вопрос, на который отвечает этот модуль: что на самом деле означает «единый источник истины»?

Есть фраза, которую я слышу постоянно: «Нам нужен единый источник истины». Хорошо. Для чего? Для клиента? Это недостаточно конкретно. Возьмем организацию (Account). Кто владеет названием клиента, адресом для счетов, кредитным лимитом, менеджером по работе с клиентом, уровнем поддержки, маркетинговыми предпочтениями? Эти ответы не указывают на одну и ту же систему. ERP может контролировать юридическое название, адрес для счетов и кредитный статус; Salesforce — ответственного за отношения и атрибуты продаж; еще одна платформа — согласия. Поэтому, когда мне говорят: «Salesforce — наш единый источник истины о клиенте», мой следующий вопрос: какой истины?

Истина принадлежит атрибуту

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

Атрибут	Авторитетная система
Юридическое название, адрес для счетов, ID клиента в ERP, кредитный лимит	ERP
Менеджер по работе с клиентом, флаг стратегического клиента, уровень сопровождения	Salesforce

Одна запись; истина распределена. Это нормально. Фраза «система записи = Salesforce» этого не описывает. А модель полномочий — описывает.

Где создается, редактируется, используется — и как быстро?

Когда я преподаю мастер-данные, я снова и снова возвращаюсь к одним и тем же вопросам для каждого важного элемента данных: где он создается, где редактируется, где используется по ссылке и какова задержка его изменений? Они быстро обнажают архитектуру. (Первые три вы встречали в главе 4, когда сортировали виды данных; здесь они делают свою настоящую работу.)

Возьмем актив. Клиент заказывает три велосипеда. В Salesforce есть возможность и ее позиции, и заказ уходит в ERP. ERP его выполняет, и именно там активы создаются: три велосипеда, три серийных номера, отправленные обратно в Salesforce. Через несколько месяцев клиент звонит по поводу одного из них, и поддержка ссылается на актив в обращении. Теперь кому-то нужно исправить атрибут. Какие из них Salesforce может редактировать, а какие принадлежат ERP, которая их создала? И когда ERP меняет один из них, как быстро Salesforce должен об этом узнать? Один актив, четыре вопроса, и ответы не одинаковы для всех полей.

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

Задержка — тоже часть истины. ERP меняет кредитный статус клиента в 10:00; Salesforce синхронизирует его по ночам; в 15:00 представитель смотрит в Salesforce. Значение неверное? Оно устаревшее. Если значение меняется раз в год и суточная задержка ничего не стоит, ночной синхронизации достаточно. Если оно решает, примете ли вы сегодня заказ на миллион долларов, — нет. Полномочия говорят, откуда приходит истина; задержка говорит, как быстро остальные должны узнать, что она изменилась. Два отдельных решения.

Система записи, взаимодействия, справочная

Здесь помогает словарь главы 4. Система записи (system of record) хранит авторитетную версию. Система взаимодействия — то место, где люди с ней работают. Справочная система поставляет данные, которые другая система использует, но которыми не владеет. Salesforce может быть системой взаимодействия для отношений с клиентом, а ERP — оставаться системой записи для его юридических и финансовых атрибутов. Это не слабость архитектуры; это и есть архитектура. Ошибка — делать вид, что одна система должна владеть всем, чтобы диаграмма выглядела проще.

Гибридная золотая запись

Это меняет смысл понятия «золотая запись». Глава 5 ввела эту идею, когда речь шла о том, как не пускать плохие данные; здесь она — сердце дизайна. Люди представляют себе одну волшебную запись, где каждое поле ведется в одном месте. Иногда дизайн именно такой. Но в Salesforce я чаще вижу гибрид: часть организации ведется в другой системе и копируется внутрь (юридическое название, номер клиента в ERP, адрес для счетов, кредитный статус), а часть существует только потому, что она нужна Salesforce (менеджер по работе с клиентом, стратегия по возможностям, уровень сопровождения, заметки об отношениях). Поля ERP приходят внутрь, чтобы люди могли ими пользоваться. Поля Salesforce никогда не уходят обратно, потому что ERP они не интересуют. Совершенно разумно — при условии, что все знают, где что.

Сделайте полномочия видимыми

Поэтому я делаю внешние полномочия очевидными в схеме. Если полем управляет SAP, оно получает префикс: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. Это та же идея, что и префикс erp_ в главе 4. Используйте имя системы, когда эти полномочия конкретны и стабильны, и общий префикс, когда смысл важнее сегодняшнего поставщика. Суть в том, чтобы через полгода человек, читающий модель, видел: это не просто еще одно поле Salesforce; этим значением владеет другая система. Не заставляйте людей заново открывать полномочия, разбирая интеграции задом наперед.

Постройте карту полномочий

Для важных мастер-данных мне нужна карта полномочий (authority map): для каждого ключевого атрибута — кто его создает, кто владеет бизнес-решением, какая система авторитетна и кто или что может его менять. Четыре разных вопроса:

Атрибут	Кто создает	Бизнес-владелец	Авторитетная система	Кто может менять
Юридическое название	Финансы	Финансы	ERP	Финансовый процесс
Кредитный лимит	Финансы	Финансы	ERP	Кредитный отдел
Менеджер по работе с клиентом	Отдел sales operations	Продажи	Salesforce	Руководство продаж
Уровень поддержки	Отдел service operations	Обслуживание	Salesforce	Руководство обслуживания
Согласие	Сам клиент	Отдел конфиденциальности	Платформа согласий	Клиент, утвержденный процесс

Обратите внимание: бизнес-владелец и авторитетная система — не одно и то же. Система не владеет политикой; ею владеют люди. Система хранит и обеспечивает результат. Это снова глава 5: владельцы устанавливают политику; архитекторы ее обеспечивают.

Click to enlarge

Один клиент. Много атрибутов. У каждого — один источник полномочий.

Полномочия меняются в течение жизненного цикла

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

Копия — это не полномочия

Мы копируем данные ERP в Salesforce, потому что они постоянно нужны людям. Это делает Salesforce удобной локальной копией, а не мастером, и архитектура должна вести себя соответственно: только чтение для пользователей, обновление через интеграцию, пометка источника, изменение только через запрос, проверка сверкой, когда копия расходится с оригиналом. Копия полезна. Полномочия никуда не переместились.

Доверию нужно больше, чем значение

«Адрес для счетов: Main Street, 123». Стоит ли ему доверять? Мне нужны сигналы доверия: откуда он пришел, когда его в последний раз подтверждали, какая система его предоставила и кто или что изменил его последним — человек, интеграция, агент? Теперь ERP говорит Main Street, 123, Salesforce — 125, а файл партнера — «123 Main St., Suite 200». Что из этого верно? Не отвечайте «берем самое свежее». Может быть. Но «самое свежее» — само по себе правило, которое предполагает, что тот, кто изменил значение последним, заслуживает победы. Это может быть правдой, а может быть ужасно. Этим займется модуль 3. Доверие возникает из полномочий и происхождения, а не из того, что нашлось заполненное поле.

Steve Trucking: чья это истина?

Розничный партнер присылает доставку, и в этой одной транзакции прячется несколько истин. Номер заказа у партнера — партнерский; Steve Trucking хранит его, чтобы сопоставлять обновления, но не становится его мастером. Статус доставки (прибыли, доставлено, установлено, исключение) — Steve Trucking; партнер его получает, но получение статуса не делает партнера авторитетным в том, что произошло на грузовике. А получатель — клиент партнера. Партнер предоставляет имя, адрес, телефон и примечания к доставке, потому что они нужны Steve Trucking для доставки. Это не делает Steve Trucking мастером идентичности этого человека, и именно это различие определяет дизайн получателя в контрольной точке.

Click to enlarge

Одна доставка, два источника полномочий.

Где живут данные и кто владеет их истиной — разные вопросы. Salesforce может хранить номер клиента из ERP, не владея им; Snowflake может хранить статус доставки, не будучи его операционным мастером; платформа клиентских данных может унифицировать идентичности, не владея каждым атрибутом. Агент может читать все три, и это уж точно не дает агенту права решать, что из этого истинно.

За пределами экзамена: что меняет ИИ. Агенты превращают полномочия по атрибутам в правило исполнения. Человек видит неправильный адрес для счетов и знает: «это приходит из SAP; здесь мне его менять не следует». Агент, которому сказали «обнови адрес для счетов клиента», этого не узнает, если мы это не заложим в дизайн. Ему нужна та же карта полномочий, что и архитектору: доступ к полю не делает это поле правильным местом для записи.

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

• Какая система авторитетна для каждого важного атрибута — вместо одной системы для всей записи.
• Где каждый атрибут создается, редактируется и используется по ссылке и как быстро должны распространяться его изменения.
• Кто устанавливает политику для каждого атрибута и какие люди, интеграции или агенты могут его менять.
• Как внешние полномочия отражаются в модели: префиксы имен, разрешения, поведение интеграций.
• Как полномочия смещаются в течение жизненного цикла, например когда потенциальный клиент становится клиентом под управлением ERP.

Единый источник истины не означает один org, одну ERP, одну MDM-платформу или одну гигантскую запись. Он означает, что для каждого элемента управляемой информации архитектура может сказать, где находится авторитетное значение, и каждая другая система благодаря этому знает, как себя вести. Это не единый источник истины. Это архитектура истины.

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

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