Управление данными закладывается в org

🌐 Также доступно на 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 главы Качество данных и управление ими, глава 5 курса Data Architect. Каждый модуль самостоятелен. Далее: Не пускать плохие данные

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

Когда люди слышат управление данными (data governance), они думают о совещаниях: комитеты, политики, стандарты, документ, объясняющий, кто что должен делать с данными. Все это может быть частью программы управления данными. Как архитектора меня интересует другой вопрос: где эта политика обеспечивается?

Если политика говорит, что поле может менять только финансовый отдел, что это обеспечивает? Если она говорит, что юридической записью клиента владеет ERP, что мешает кому-то в Salesforce ее изменить? Если она говорит, что бригады видят адрес получателя только для своих остановок и только в день доставки, что на самом деле делает это правдой? Если она говорит хранить это семь лет, что через семь лет отправит это в архив или удалит? Политика без точки обеспечения — это по большей части пожелание. Управление данными становится архитектурой, когда эти решения встроены в систему.

Управление данными никогда не завершено

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

Когда Salesforce стоит в основном особняком, управление данными означает чистить данные в одном месте. Когда это один узел в ландшафте из главы 4, все становится сложнее — и нужнее. Теперь клиент живет в Salesforce, в ERP, в хранилище, в системах партнеров, в Data 360. Кто им владеет? Кто может его менять? Какая копия авторитетна, какие атрибуты могут перемещаться, как долго они хранятся и кто отвечает, когда они неверны? Это не вопросы настройки. Это вопросы управления данными, которые становятся настройкой.

Владелец записи — не владелец данных

Начнем со слова владелец, потому что Salesforce его запутывает. Откройте организацию (Account) — и вы увидите поле Owner: скажем, торгового представителя. Владеет ли представитель данными клиента? Не обязательно. В Salesforce запись объекта, у которого есть владелец, принадлежит пользователю или очереди; владелец получает полный доступ и управляет назначением и общим доступом через иерархию ролей и правила общего доступа (Sharing and Record Access Features (opens in a new tab)). Это владение записью: механизм платформы.

Владелец данных — нечто другое: человек или подразделение, которое отвечает за данные как за бизнес-актив. Финансовый отдел может владеть юридической информацией о клиенте, операционный отдел — статусом доставки, отдел кадров — данными сотрудников. Salesforce даже дает место, чтобы это записать: поле классификации Data Owner (владелец данных) у каждого поля (Data Classification Metadata Fields (opens in a new tab)).

В Steve Trucking организацией розничного партнера может владеть менеджер по продажам, который ведет этого партнера. Но юридические реквизиты партнера находятся под управлением финансового отдела и ведутся в финансовой ERP. Продажам, обслуживанию, операционному отделу и партнерскому порталу — всем нужна эта организация; но ничто из этого не значит, что менеджер по продажам должен менять юридические реквизиты партнера после того, как их установил финансовый отдел. Я видел команды, которые смотрели на поле Owner и считали, что вопрос владения данными решен. Нет, не решен. Назначение записи — это не ответственность бизнеса.

Владелец, стюард, хранитель

Три роли управления данными, три разные работы.

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

Стюард данных поддерживает все в рабочем состоянии. Стюард близок к повседневному здоровью данных: следит за сигналами качества, разбирается с дубликатами, разрешает исключения, координирует исправления, поддерживает определения, замечает процесс, который раз за разом порождает плохие данные. У стюарда есть еще две задачи. Когда две команды расходятся во мнениях о том, что означает поле, кто им владеет или кто может его видеть, стюард выносит спор к владельцу и доводит решение до конца. И стюард развивает грамотность в работе с данными (data literacy): помогает людям, которые вводят и используют данные, понимать, что они означают и зачем существуют правила. Стюарду нужно больше, чем имя на схеме. Ему нужны время, видимость, процесс и полномочия добиваться исправления проблем. Иначе «стюард данных» становится чьей-то восьмой обязанностью, на которую смотрят раз в квартал.

Хранитель (custodian) управляет системой. Администраторы, платформенные команды, команды безопасности — все, кто эксплуатирует технологию, которая хранит и обрабатывает данные. Владелец говорит, что видеть данные могут только эти роли; хранитель эксплуатирует средства контроля, которые это обеспечивают. Названия важны меньше, чем ясность каждой зоны ответственности, а в небольшой организации один человек может совмещать две роли.

Как работает программа

Программы управления данными обычно бывают трех видов. Централизованная: одна команда пишет политики и стандарты для всех доменов. Это последовательно, но может стать узким местом, далеким от людей, которые делают работу. Федеративная (децентрализованная): каждый домен, например финансы, продажи или операционная деятельность, управляет своими данными в рамках нескольких общих правил. Это близко к работе, но определения между доменами расходятся. Гибридная: небольшая центральная команда владеет стандартами и общими определениями, а владельцы и стюарды доменов управляют своими данными. Большинство предприятий, которые я видел, в итоге оказываются где-то в гибридной модели. Для архитектора форма программы отвечает на один практический вопрос: кто утверждает политику, прежде чем я начну ее обеспечивать, и где живут общие определения?

Знать к экзамену. Знайте три способа вести программу управления данными — централизованный, федеративный (децентрализованный) и гибридный — и что каждый из них означает для того, кто устанавливает политику и где живут общие определения.

Пусть матрица RACI оправдывает свое место

Матрица RACI (кто исполняет — Responsible, кто отвечает — Accountable, с кем консультируются — Consulted, кого информируют — Informed) помогает, но не гигантская таблица, сделанная потому, что управление данными «требует ее». Я хочу, чтобы она отвечала на архитектурные вопросы, начиная с трех из главы 4 (Четыре вопроса за категориями): где данные создаются, где редактируются и где на них ссылаются? Часто это разные системы. Возьмем продукт: ERP его создает, Salesforce на него ссылается, портал его показывает, хранилище его анализирует. Теперь бизнес меняет значение «активного продукта». Где начинается изменение, кто его утверждает, как оно распространяется и какие копии доступны только для чтения? Если вы не можете ответить, у вас еще нет управления данными. У вас есть копии. Хорошая RACI вскрывает именно эту неоднозначность.

Управление данными должно стать механическим

Бизнес говорит, что юридическое название клиента может менять только финансовый отдел. Я не хочу, чтобы архитектурным ответом было «расскажем об этом на обучении». Обучение помогает, но это не обеспечение. Может быть, это доступ на уровне полей, правило проверки, поле, которое пишет только интеграция, или контролируемый процесс вместо прямого редактирования. Механизм зависит от требования, но он должен быть:

Политика управления данными	Решает владелец	Возможная точка обеспечения
Юридическими данными клиента владеет ERP	Финансовый отдел	Поля только для интеграции, разрешения, проверка
Персональные данные видят только те, кому это нужно	Конфиденциальность, безопасность	Общий доступ, разрешения, доступ к полям
Идентификаторы клиентов уникальны	Бизнес-владелец	Уникальный External ID, правила дубликатов
Управляемые записи не создаются вручную	Владелец данных	Разрешения, автоматизация, интеграция
У чувствительных данных есть установленный срок хранения	Конфиденциальность, юристы	Процесс хранения или удаления
Важные изменения должны быть доказуемы	Соответствие требованиям	История полей, журнал аудита
Источник данных остается узнаваемым	Владелец данных	Поле источника, метаданные о происхождении

Я намеренно говорю возможная точка обеспечения. Это не таблица для выбора функций. Это порядок мышления: какова политика, кто ею владеет и что в архитектуре делает ее правдой?

Click to enlarge

Владельцы устанавливают политику, архитекторы ее обеспечивают.

Не полагайтесь на хорошее поведение

«Никогда не меняйте ID клиента из ERP». Все это знают — пока кто-нибудь не изменит: случайно, через загрузку данных, через автоматизацию, через интеграцию, через агента. Если изменение повредит корпоративным данным, «пожалуйста, не надо» — это не контроль. Постройте контроль. Доверяй, но проверяй. Люди, интеграции, автоматизация и ИИ — все ошибаются, поэтому архитектура должна исходить из того, что рано или поздно что-нибудь попытается сделать то, что политика запрещает. Что тогда произойдет?

Управление данными пересекает границы систем

Вернемся к ландшафту. Клиентом владеет ERP; у Salesforce, хранилища и платформы клиентских данных есть копии; партнер получает их часть. К какой системе применяется политика? Ко всем. Salesforce может правильно блокировать изменение юридического названия, а интеграция позволит системе ниже по потоку его перезаписать. Salesforce может удалить персональные данные, которые все еще лежат в хранилище. Поле, классифицированное как чувствительное в Salesforce, может оказаться в неклассифицированном текстовом поле где-то еще. Управление данными не может остановиться на границе org, потому что данные там не останавливаются. Поэтому глава 4 и шла первой: ландшафт говорит вам, как далеко должно дотягиваться управление данными.

Управляйте достаточно, а не всем

Противоположная ошибка так же реальна. Мы понимаем, что управление данными важно, и закрываем все: никто не может создавать записи, каждое изменение требует утверждения. Данные под управлением, а работать никто не может. Управление данными означает соответствующий контроль для данных: жесткий для одних, мягкий для других. Некоторые записи можно создавать свободно, некоторые требуют утверждения; некоторые поля может редактировать почти кто угодно, некоторые — только интеграция. Следующий модуль переходит к практике именно в этом.

А поскольку управление данными никогда не завершено, обеспечению нужна обратная связь. Растет ли число дубликатов? Заполняются ли обязательные поля мусором? Падают ли интеграции, находят ли пользователи обходные пути, растут ли исключения, тратят ли стюарды весь день на одну проблему? Эти сигналы говорят вам, работает ли проект, а иногда — что нужно менять контроль или саму политику.

За пределами экзамена: что меняет ИИ. У управления данными появился новый потребитель — агент. Владелец данных по-прежнему решает, что и для чего можно использовать; архитектор по-прежнему делает это обеспечиваемым. Меняются скорость и масштаб. Агент читает, комбинирует управляемые данные и действует на их основе гораздо быстрее человека, поэтому политика, которая существует только в документе, защищает еще меньше.

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

• Кто отвечает за каждый важный домен данных и чем это отличается от владения записью.
• Кто является стюардом данных и кто эксплуатирует их как хранитель.
• Где в ландшафте важные данные создаются, редактируются, используются по ссылке и мастерятся.
• Какая точка обеспечения делает каждую важную политику механически верной.
• Как архитектура показывает, работает ли управление данными или начинает сдавать.

Когда я слышу требование управления данными, я его перевожу. «Этим владеет ERP». «Это могут видеть только эти люди». «Нам нужно доказать, кто это изменил». «Храните это семь лет». Каждый раз: покажите мне точку обеспечения. Архитектор не определяет политику. Мы проектируем систему, которая ее обеспечивает. Именно здесь управление данными перестает быть документом и становится архитектурой.

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

• Salesforce Help, Sharing and Record Access Features (opens in a new tab) (на английском, проверено 2026-10-14).
• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (на английском, проверено 2026-10-14).