7.9 Управление мастер-данными и справочными данными

Обзор и мотивация

Спросите пять систем, сколько у организации клиентов, и вы получите пять разных чисел. Одна считает адреса электронной почты, другая договоры, третья входы в систему, а две расходятся в том, одна ли это компания, «Acme Corp» и «ACME Corporation». Управление мастер-данными (MDM) это дисциплина согласования основных сущностей, общих для вашего бизнеса, клиента, продукта, поставщика, сотрудника, места, в одну авторитетную версию, которой может доверять каждая система.

Начните с разбиения данных на три вида, потому что им нужно разное обращение. Мастер-данные описывают существительные вашего бизнеса: людей, места и вещи, на которые ссылаются многие процессы. Справочные данные это контролируемый словарь, который используют эти процессы: коды валют, коды стран, списки единиц измерения, категории продуктов. Транзакционные данные фиксируют глаголы: размещённый заказ, совершённый платёж, отправленную поставку. Мастер- и справочные данные меньше транзакций по объёму, но на них ссылаются везде, поэтому ошибка в них заражает всё ниже по течению.

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

Для корпораций, сверяющих системы, накопленные десятилетиями роста и поглощений, MDM это разница между связным видом клиента и постоянным налогом на сверку. Для государства ставки растут: гражданин, выступающий тремя разными людьми в трёх ведомствах, может получить отказ в пособии, быть обложен налогом дважды или потеряться между департаментами. Эта глава дополняет стратегию данных и управление данными (глава 7.1), задающую владение и политику; моделирование данных и семантический слой (глава 7.7), определяющее, что значат сущности; и качество данных и наблюдаемость (глава 7.8), держащие записи чистыми со временем.

Ключевые принципы

Разбейте ваши данные на мастер-, справочные и транзакционные; каждому нужно своё обращение.
Одна золотая запись на сущность реального мира, собранная намеренно, а не обнаруженная случайно.
Выбирайте стиль архитектуры MDM под ваши нужды контроля и задержки, а не моду.
Сопоставление и определение выжившего значения это бизнес-правила, поэтому записывайте их и позволяйте стюардам их настраивать.
Справочные данные общий словарь; версионируйте их и публикуйте как API.
Управление и стюардство двигатель MDM; программное обеспечение лишь инструмент.
Распространяйте золотые записи как события, чтобы нижестоящие системы оставались синхронизированными, а не устаревшими.
Измеряйте MDM улучшенными решениями и удалёнными дубликатами, а не загруженными записями.

Рекомендации

Сначала классифицируйте мастер-, справочные и транзакционные данные

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

Выбирайте стиль архитектуры MDM намеренно

Есть четыре распространённых стиля архитектуры, и правильный зависит от того, сколько власти вы можете централизовать и как быстро изменения должны распространяться. Стиль реестра оставляет данные в системах-источниках и строит только индекс сопоставленных идентификаторов, так что может ответить «эти пять записей один и тот же клиент», не перемещая данных; он дёшев и малорискован, но только для чтения, поэтому не может исправить источники. Стиль консолидации тянет копии в центральный узел и сливает их в золотые записи для отчётности, но не возвращает исправления, так что источники остаются неряшливыми. Стиль сосуществования идёт дальше: он синхронизирует очищенные значения обратно в системы-источники, так что источники улучшаются со временем, продолжая работать независимо. Стиль централизованного или транзакционного узла делает узел MDM самой системой записи, где сущности создаются и правятся напрямую, а все остальные системы потребляют из него; это даёт сильнейшую согласованность и контроль и труднее всего в принятии, потому что меняет место, где происходит работа. Многие организации переходят от реестра, доказывающего ценность, к сосуществованию по мере роста доверия и ведут более одного стиля по разным областям.

Сопоставляйте, сливайте и задавайте правила определения выжившего значения явно

Сердце MDM решение о том, когда две записи описывают одну и ту же вещь реального мира. Это связывание записей, редко столь простое, как точное совпадение ключа, потому что реальные данные полны опечаток, сокращений и пропущенных полей. Детерминированное сопоставление использует точные правила по выбранным полям (тот же налоговый идентификатор или тот же адрес электронной почты плюс почтовый индекс). Вероятностное сопоставление оценивает сходство по многим полям, используя приближённое сопоставление строк и веса, так что «Bob Smith, 12 Main St» и «Robert Smith, 12 Main Street» можно признать вероятным совпадением выше порога. Решение о том, какие записи относятся к одной сущности, называется разрешением идентичности и питает всё, от видов клиентов до обнаружения мошенничества.

Как только записи совпали, нужно решить, какие значения выживают в золотой записи. Эти правила определения выжившего значения бизнес-логика, поэтому делайте их явными: предпочитайте самое свежее значение для телефона, самое полное для адреса, самый доверенный источник для юридического имени. Задайте полосу порога, где совпадения сливаются автоматически, более низкую полосу, где они отклоняются автоматически, и среднюю полосу, где решает человек, и именно там живёт стюардство. Держите каждое слияние обратимым и журналируемым, потому что неверное слияние, сплавляющее двух настоящих клиентов, хуже пропущенного.

Воспринимайте справочные данные как версионируемый общий словарь

Справочные данные это общий словарь, на котором говорят ваши системы, а дрейфующий словарь вызывает молчаливое рассогласование: когда одна система использует код страны ISO «GB», а другая «UK», соединения отказывают, а подсчёты расходятся. Держите каждый справочный список в одном управляемом месте, публикуйте его для каждого потребителя и, что важно, версионируйте. Коды добавляются, выводятся, расщепляются и объединяются со временем, и если вы перезаписываете список на месте, вы ломаете исторические отчёты, которые были верны при старых кодах.

Воспринимайте справочный набор данных как API с контрактом. Публикуйте его с датами вступления в силу, чтобы потребитель мог спросить «какие коды регионов были действительны на эту дату», храните выведенные коды, а не удаляйте их, и записывайте соответствие, когда код меняет значение. Предпочитайте признанные внешние стандарты, где они существуют, например коды стран и валют ISO, потому что стандарты дают интероперабельность бесплатно и связаны с дисциплиной открытых стандартов из главы 3.8.

Моделируйте иерархии и связи, а не только плоские записи

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

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

Подключите золотые записи к семантическому слою и качеству данных

Золотые записи, производимые MDM, это заслуживающие доверия сущности, на которые ссылается семантический слой из главы 7.7, определяя метрики: «активные клиенты» что-то значат, только когда «клиент» однозначен. Питайте семантический слой вашими золотыми записями, чтобы каждая метрика считала одни и те же дедуплицированные разрешённые сущности.

MDM и качество данных (глава 7.8) две стороны одной монеты: проверки качества обнаруживают дубликаты, пустые значения и нарушения формата, которые затем разрешает MDM, а сопоставление MDM выявляет проблемы качества, пропущенные проверками. Ведите непрерывный мониторинг качества именно мастер-данных: доли дубликатов, распределения уверенности сопоставления, полноту ключевых полей и размер очереди рецензии, чтобы дрейф всплывал до того, как его увидят потребители.

Распространяйте золотые записи через события

Золотая запись, которую не видит ни одна нижестоящая система, никому не помогает. Сильнейший шаблон событийное распространение: когда сущность создана, слита или исправлена, узел MDM публикует событие изменения, а подписанные системы обновляют свою локальную копию. Это строится на событийно-ориентированной архитектуре и потоковых шаблонах главы 7.2, держа десятки систем согласованными без хрупких ночных пакетных синхронизаций, оставляющих всех на день устаревшими.

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

Назначьте стюардство и управление до инструментов

MDM терпит неудачу как технологический проект и преуспевает как проект управления. Критичная роль стюард данных, человек, подотчётный за качество и правила конкретной области, разрешающий неоднозначные совпадения, настраивающий правила определения выжившего значения и арбитрирующий, когда два отдела расходятся в том, что значит «поставщик». Стюарды обычно люди бизнеса с глубокими знаниями предметной области, а не инженеры, и им нужны реальные полномочия и выделенное время, потому что стюардство на полставки без мандата порождает именно тот дрейф, который MDM должно было остановить.

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

Компромиссы: плюсы и минусы

Стиль MDM	Плюсы	Минусы
Реестр (только индекс)	Дёшево, малорискованно, источники не тронуты	Только чтение; не может исправить данные источников
Консолидация (центральные копии)	Быстро чистые записи для аналитики	Источники остаются неряшливыми; нет обратной записи
Сосуществование (синхронизация обратно в источники)	Источники улучшаются; сбалансированный контроль	Больше интеграции; конфликты синхронизации для управления
Централизованный / транзакционный узел	Сильнейшая согласованность и контроль	Наивысшая цена; меняет место, где происходит работа
Детерминированное сопоставление	Предсказуемо, объяснимо, проверяемо	Пропускает опечатки, варианты и неряшливые данные
Вероятностное сопоставление	Ловит вариации реального мира	Требует настройки; ложные слияния при небрежности

Центральное напряжение в MDM между контролем и разрушением. Стили, дающие самые чистые и согласованные данные (сосуществование и централизованные узлы), как раз те, что сильнее всего вторгаются в то, как работают системы-источники и их владельцы, и это вторжение то место, где программы MDM застревают. Прагматичный путь заработать доверие малорискованным стилем и двигаться к более сильному контролю только там, где бизнес-обоснование ясно. Компромисс сопоставления идёт параллельно: детерминированные правила проверяемы, но хрупки, вероятностная оценка мощна, но требует стюардства и терпимости к редкому неверному слиянию. Большинство зрелых программ смешивают оба.

Вопросы для обсуждения с командой

Какие области мастер-данных на самом деле причиняют нам боль и ранжировали ли мы их по цене, а не берёмся за все сразу? Многие программы MDM рушатся под собственными амбициями, пытаясь освоить каждую сущность предприятия сразу и ничего не давая два года. Продуктивный ход найти одну-две области, где дублирование и конфликт стоят вам реальных денег или доверия, обычно клиент или продукт, и оценить эту цену: потраченные впустую рассылки, часы сверки, неверные числа выручки, замечания аудита. Принесите конкретные примеры одной сущности, появляющейся по-разному в ваших системах, и пусть это ранжирование скажет, где начать, потому что узкая измеримая победа строит доверие, нужное для расширения.
Кто владеет каждой областью мастер-данных и есть ли у наших стюардов полномочия и время, чтобы действительно делать работу? Инструменты MDM без наделённого полномочиями стюардства это машина без водителя, а самый частый режим отказа назначение стюарда на слайде без реального мандата и выделенных часов. Людям, разрешающим неоднозначные совпадения и улаживающим споры «что считается клиентом», нужны экспертиза в предметной области, полномочия принимать решения и защищённое время. Принесите вашу оргструктуру и спросите для вашей главной области, кто именно решает, что две записи один и тот же человек, и кто арбитрирует, когда продажи и финансы расходятся. Если вы не можете назвать этого человека и указать на его выделенное время, вы нашли пробел, который потопит программу.
Когда мы сливаем две записи в золотую, можем ли мы объяснить и отменить решение и откуда берутся выжившие значения? Правила определения выжившего значения бизнес-логика, которую большинство команд никогда не записывало, а значит слияния происходят по случайности порядка загрузки или умолчаниям инструмента, и неверное слияние, сплавившее двух настоящих клиентов, больно отменять. Принесите настоящую слитую запись и проследите каждое выжившее поле до источника и правила: почему этот адрес, почему это имя, почему этот телефон. Подтвердите, что каждое слияние журналируется и обратимо и что средняя полоса неуверенных совпадений идёт к человеку, а не сливается автоматически. Если вы не можете объяснить конкретную золотую запись, ваши стюарды не смогут защитить её перед аудитором или обиженным клиентом.
Какой стиль архитектуры MDM подходит каждой области, которую мы планируем осваивать, и можем ли мы защитить этот выбор перед разрушением, которое он налагает на владельцев систем-источников? Выбранный стиль решает, насколько вы можете очистить данные и насколько вторгаетесь в команды, владеющие источниками, а выбор по моде или предложению поставщика, а не по реальности контроля против разрушения, то, как программы застревают на полпути. Реестр дёшево доказывает ценность, но никогда не исправляет источник; централизованный узел даёт сильнейшую согласованность, но переносит место создания записей, что организационное изменение под видом технического. Принесите для каждой области-кандидата честную оценку того, сколько власти вы реально имеете над владельцами источников, насколько свежими должны быть нижестоящие копии и что обратная запись сломала бы в существующих рабочих процессах. В корпоративной и государственной среде добавьте цену миграции и управления изменениями при переносе системы записи, потому что команды, чья ежедневная работа переезжает, будут сопротивляться узлу, с которым их не консультировали, а застрявшее развёртывание сосуществования дороже скромного реестра, который запущен.
Как мы настраиваем пороги сопоставления и согласовали ли мы, какую долю ложных слияний и пропущенных совпадений можем терпеть в каждой области? Каждый вероятностный движок сопоставления меняет ложные слияния (сплавление двух настоящих сущностей) на пропущенные совпадения (оставление одной сущности расщеплённой), и баланс это бизнес-решение, а не умолчание, оставленное кем-то в инструменте. Задайте полосы автослияния и автоотклонения слишком широкими, и вы молча портите золотые записи; слишком узкими, и очередь рецензии растёт быстрее, чем стюарды успевают её разгребать. Принесите нынешнее распределение уверенности, размер и возраст очереди рецензии и образцы ошибок обоих видов, чтобы комната увидела реальную цену каждого направления. В государственной области идентичности склоняйтесь решительно к пропущенным совпадениям и рецензии человеком, потому что неверное слияние может лишить пособия или раскрыть данные одного гражданина другому, а цена апелляции и аудита этой ошибки затмевает цену дубликата, который стюард разрешит на следующей неделе.
Как нижестоящие системы узнают, что золотая запись изменилась, и насколько устаревшей может быть каждая, прежде чем решение пойдёт не так? Идеально разрешённая золотая запись, которую не потребляет ни одна система, дорогая таблица, а механизм распространения, будь то события изменения, API подписки или ночной пакет, тихо задаёт, насколько актуально каждое зависимое решение. Событийное распространение держит десятки потребителей почти в реальном времени, но требует идемпотентных потребителей и версионируемых событий; ночная синхронизация проще, но оставляет всех на день устаревшими, что может быть нормально для маркетингового списка и опасно для проверки мошенничества. Принесите список потребляющих систем, свежесть, действительно нужную каждой, и как потребитель, пропустивший обновление сегодня, восстанавливается. Для большой или государственной организации назовите, кто владеет контрактом для этих событий и как подписчик обнаруживает потерянное сообщение, потому что изменение сущности, молча не дошедшее до одного ведомства, воссоздаёт ту самую фрагментацию, ради устранения которой финансировали MDM.

Взгляд по секторам

Стартап. С горсткой инженеров и без запаса не покупайте платформу MDM. Освойте одну сущность, портящую ваши числа, обычно клиента, продублированного между самообслуживанием и продажами, заданием сопоставления в уже работающем у вас хранилище и одним человеком, еженедельно рецензирующим неуверенные совпадения. Держите каждое слияние журналируемым и обратимым, чтобы плохое правило стоило полдня, а не отношений с клиентом, и возвращайтесь к более тяжёлым инструментам, только когда очередь ручной рецензии перерастёт одного рецензента.

Малый бизнес. У вас нет стюарда данных и бюджета, поэтому воспринимайте это как решение «покупать, а не строить» и опирайтесь на стандарты, которые получаете бесплатно. Предпочитайте инструменты, уже дедуплицирующие контакты и говорящие на кодах стран и валют ISO, заказному узлу, который вы не можете сопровождать, и выберите одну область, обычно клиентов или продукты, где дубликаты стоят вам реальных денег. Назначьте подотчётность названному владельцу, пусть это доля недели одного человека, потому что словарь, дрейфующий без присмотра, тихо ломает ваши отчёты.

Крупная организация. Через дюжину систем ERP и CRM, накопленных поглощениями, работа это управление портфелем: ранжируйте области по цене их дублирования, поднимайте наделённых полномочиями стюардов в бизнесе и стандартизируйте правила определения выжившего значения и версионирование справочных данных, чтобы группы перестали заново решать ту же задачу сопоставления. Бюджетируйте интеграцию и постоянное стюардство явно, распространяйте золотые записи как версионируемые события, чтобы источники улучшались со временем, и управляйте MDM как измеряемой программой с долями дубликатов и метриками очереди рецензии, а не разовой очисткой.

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

Примеры

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

Крупная организация. Глобальный производитель вырос поглощениями и ведёт дюжину систем ERP и CRM, у каждой свои записи поставщиков, так что один поставщик выступает пятнадцатью способами, а компания не может вести переговоры как единый покупатель или видеть свои настоящие расходы. Она поднимает узел MDM в стиле сосуществования для областей поставщиков и продуктов, используя детерминированное сопоставление по налоговым и регистрационным идентификаторам плюс вероятностную оценку по названиям и адресам. Названные стюарды в закупках настраивают правила определения выжившего значения и разгребают очередь рецензии, а золотые записи публикуются как события изменения, текущие обратно в каждую ERP, так что очищенные данные улучшают источники. Консолидированная видимость расходов открывает лучшие условия контрактов, а налог на сверку, съедавший финансы каждый квартал, резко падает.

Государственный сектор. Национальное правительство хочет, чтобы ведомства воспринимали гражданина как одного человека, а не незнакомца у каждого окошка, соблюдая строгие юридические ограничения обмена данными. Оно строит централизованный узел мастер-данных для сущности человека, ключуемый на управляемый национальный идентификатор, со справочными данными, версионируемыми по дате вступления в силу, так что исторические записи остаются верными. Разрешение идентичности намеренно консервативно: неуверенные совпадения идут к обученным стюардам, а не автоматическим слияниям, потому что неверное слияние могло бы лишить кого-то пособия или раскрыть его данные, и каждое сопоставление журналируется для аудита и апелляции. Отдача в меньшем числе дублированных записей, меньшем мошенничестве от расщеплённых идентичностей и гражданине, которому не нужно доказывать, кто он, у каждой двери, в рамках стандартов интероперабельности главы 3.8.

Бизнес-обоснование: мотивы, ROI и TCO

Отдача от MDM приходит от устранения налога, который большинство организаций платит, не называя его. Дублирующие и конфликтующие записи стоят денег очевидными способами (потраченный впустую маркетинг одному человеку пять раз, ошибки доставки из-за устаревших адресов, упущенные скидки за объём) и менее очевидными (аналитики сверяют подсчёты, руководители решают по тихо неверным числам, аудиторы выставляют часы за распутывание, какая запись настоящая). Консолидированный вид поставщиков нередко окупает всю программу одними лучшими условиями контрактов.

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

Антипаттерны и ловушки

Объём «вскипятить океан»: освоение каждой области сразу, годы без результата и потеря спонсорства до первой победы.
Инструменты до управления: покупка платформы MDM до назначения стюардов и владельцев, так что у двигателя нет водителя.
Стюарды на полставки без полномочий: назначение стюардства на слайде без реального мандата или защищённого времени.
Молчаливое определение выжившего значения: слияние записей по умолчанию инструмента или порядку загрузки, без письменных правил и способа объяснить золотую запись.
Необратимые слияния: автослияние неуверенных совпадений без отмены, так что неверное сплавление двух настоящих сущностей становится постоянным ущербом.
Справочные данные, перезаписанные на месте: правка списков кодов без версионирования, ломающая каждый исторический отчёт, который был верен при старых кодах.
Золотые записи, которые никто не потребляет: построение безупречного узла, на который не подписана ни одна нижестоящая система, так что чистые данные никогда не достигают решений.
Изобретение стандартных кодов заново: чеканка собственных списков стран или валют, когда существуют стандарты ISO, и потеря интероперабельности без причины.

Модель зрелости

Уровень 1, Начальный: Мастер- и справочные данные неуправляемы. Одна сущность существует много раз без авторитетной версии, списки кодов расходятся, сопоставление ручное и реактивное, и проблемой никто не владеет, поэтому подсчёты основных сущностей расходятся, и никто не может сказать, какой верен.
Уровень 2, Развитие: Ключевые области признаны, и кто-то их дедуплицирует, нередко в хранилище для отчётности. Существует базовое детерминированное сопоставление, справочные списки собраны, и несколько человек выступают неформальными стюардами, но практика различается от команды к команде, источники остаются неряшливыми, а правила живут в головах людей, а не на бумаге.
Уровень 3, Стандартизация: MDM управляемая программа, применяемая последовательно по организации. У мастер-областей есть названные владельцы и наделённые полномочиями стюарды, правила сопоставления и определения выжившего значения документированы и принуждаются, золотые записи производятся и распространяются потребителям, а справочные данные версионируются и публикуются с датами вступления в силу, как API.
Уровень 4, Управление: Программа измеряется и контролируется относительно базовых значений. Доли дубликатов, распределения уверенности сопоставления, доли ложных слияний и пропущенных совпадений, полнота ключевых полей и размер и возраст очереди рецензии отслеживаются как метрики; пороги настраиваются по этим числам, а не на ощущение; а ценность MDM (точность выручки, экономия закупок, цена рецензии) количественно оценивается и сообщается владельцам по фиксированному ритму.
Уровень 5, Оркестрация: Золотые записи текут как версионируемые события почти в реальном времени, питают семантический слой и пользуются доверием по организации. Сопоставление непрерывно улучшается относительно измеренных результатов, освоение расширяется на новые области как повторяемая возможность, а MDM интегрировано с управлением и планированием рисков, так что программа адаптируется по мере сдвигов источников, стандартов и ландшафта сущностей.

Идеи для обсуждения

Если две ваши системы расходятся в том, сколько у вас клиентов, какая из них права и как вы это докажете?
Какая область мастер-данных принесла бы наибольшую измеримую победу, будучи освоена первой, и чего стоит эта победа?
Где вероятностное сопоставление помогло бы вам сегодня и комфортно ли вам с редким неверным слиянием, которое оно подразумевает?
Как вы версионируете справочные данные и что ломается в ваших исторических отчётах, когда код меняет значение?
Кто назван стюардом вашей важнейшей сущности и есть ли у него полномочия и время, чтобы действительно делать работу?
Когда золотая запись меняется, как об этом узнают нижестоящие системы и насколько устаревшими они могут быть, пока это не навредит?

Главные выводы

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

Источники и дополнительное чтение

David Loshin, Master Data Management
Alex Berson and Larry Dubov, Master Data Management and Data Governance
Dan Power, The Definitive Guide to Master Data Management
John Talburt, Entity Resolution and Information Quality
Peter Christen, Data Matching: Concepts and Techniques for Record Linkage, Entity Resolution, and Duplicate Detection
Ivan P. Fellegi and Alan B. Sunter, “A Theory for Record Linkage,” Journal of the American Statistical Association
DAMA International, DAMA-DMBOK: Data Management Body of Knowledge
Ralph Kimball and Margy Ross, The Data Warehouse Toolkit