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

DQM — data quality management, управление качеством данных.
DQS — data quality system, система [управления] качеством данных.

Пример #1. Наверняка вам для работы понадобится список стран мира. На него будут ссылаться многие другие справочники: контрагенты и клиенты (страна регистрации), валюты (курс какой страны), ваша география (в какой стране и по какому адресу расположен офис).
Значит, любая сущность, которая содержит в себе страну мира (даже если вы в ней выбираете из двух-трёх стран) должна ссылаться на этот справочник. А сам справочник должен заполняться строго на основании официальных классификаторов, в случае РФ — это ОКСМ (общероссийский классификатор стран мира).
Если вы работаете на международном рынке, обратите внимание на нюанс: в разных странах разное представление о странах мира и их количестве. И речь не только про такие частично-признанные республики, как Абхазия или Южная Осетия. Например, около двадцати стран не признают существование Израиля и Китайской Народной Республики. Есть и точечные непризнания на территории СНГ, например, Армения не признаётся… Пакистаном.
Страны мира (в РФ это и ниже — ОКСМ), валюты (ОКВ), виды экономической деятельности (ОКВЭД), адреса (ФИАС), банки и их счета, клиенты и поставщики (ЕГРЮЛ и ЕГРИП) — эта и множество другой информации публикуется государственными органами практически всех стран в виде открытых API и сервисов, и она должна загружаться только таким образом.

Пример #2. Справочник контрагентов — юридических лиц и ИП, являющихся вашими клиентами или поставщиками (в компаниях уровня выше 5-6 — часто одновременно и тем, и тем).
Какой бы набор полей вы не решили добавить в справочник контрагентов в систему MDM, ваша цель такова: все данные должны заполняться автоматически, с поиском по одному из естественных полей. В случае контрагентов РФ — это наименование или ИНН.
Это не значит, что вы должны занести в свой справочник контрагентов все несколько миллионов записей из открытых данных. Но новые записи должны добавляться как раз на их основании. Базовые реквизиты можно взять с сайта налоговой. Если вас интересуют данные бухгалтерской отчётности или среднесписочной численности (например, в целях аналитики, развивать отношения с наиболее крупными клиентами) — берите их у Росстата (ссылка). Если у вас есть процедура проверки на благонадёжность — берите данные с сайтов соотв. служб с помощью своей ИТ-команды, либо есть вариант покупать уже подготовленные и выверенные данные у провайдеров (например, СПАРК-Интерфакс). Цена вопроса, сотни тысяч рублей в год, при ваших масштабах окупается за несколько месяцев.
Самое главное, что проблему неактуальных реквизитов и потенциально нежелательных контрагентов вы решите полностью. Правда, в каждой стране присутствия её нужно решать отдельно.

Пример #3. Физические лица, сотрудники вашей компании. Ошибки в паспортных данных, неправильные ФИО и дата рождения, СНИЛС. Сокрытая информация о судимости, просроченной задолженности перед госорганами, алиментах.
Список сотрудников почти всегда является мастер-данными в крупных компаниях. Как их сделать нормативкой? Самый простой способ — наладить интеграцию с порталом Госуслуг. Возможен также вариант авторизации на ваших сервисах через портал Госуслуг. Ключевое слово для поиска: ЕСИА. Нужно будет обзавестись рядом сертификатов, но при ваших масштабах и уровне развития это не составит проблем.
Естественным продолжением этой истории будет электронный кадровый документооборот — электронная трудовая книжка, электронные больничные и др., что значительно сэкономит трудозатраты у кадровиков. В пределе это позволит одному кадровику обслуживать не 200-300 сотрудников, а 1000+.
Также все сотрудники автоматом получают электронные ключи-подписи — и смогут использовать их как во внутренних бизнес-процессах, так и при документообороте с клиентами.
Информация о задолженностях, судимостях и т.д. доступна в открытом виде через API соотв. госслужб, интеграция с ними предельно простая, и позволит вашей компании закрыть сразу большое количество рисков.

Пример #4. — Хорошо, — скажете вы, — контрагенты и физлица — это просто. Но что делать с более бизнес-специфичными процессами и данными? Искать государственные классификаторы и другие гарантированные источники этой информации.
Попробуем разобрать точечный пример. У вас есть парк автомобилей. Не обязательно, что вы — служба такси, в любой достаточно крупной компании будет техника для служебных нужд. Вам нужно наладить учёт этих автомобилей, заправок и поездок, т.е. учёт расходов.
Создаём справочник автомобилей — это мастер-данные. Модель автомобиля, его нормы расхода топлива и характеристики выбираем из гос. классификатора моделей (не забывайте настроить регулярную интеграцию, чтобы данные не устаревали!)
Информацию о конкретном автомобиле заполняем строго по госномеру на основании подключаемого справочника (например, Автокод).
Откуда получить информацию, что конкретный водитель заправился на такую-то сумму в такой-то день? Оформить топливные карты (они стоят денег, но быстро окупят себя за счёт накопительной скидки) — и забирать данные у провайдера топливных карт в автоматическом режиме. Конечно, сам список топливных карт в этом случае станет мастер-данными, но вестись он будет автоматически, на основании данных провайдера.

Пример #5. Командировки сотрудников: билеты, гостиницы и прочие расходы.
Для билетов и гостиниц — пользоваться агрегаторами, все они позволяют, во-первых, значительно экономить на организации поездок (цены на билеты, гостиницы). Во-вторых, дают API со всей возможной информацией, вплоть до ЭДО. По всем прочим расходам — пользоваться электронными чеками, они уже принимаются везде. Т.е. человеческий фактор будет если не исключён, то сведён к минимуму.

Сунь-цзы учит, что лучшая битва — та, которую удалось избежать.

Пример #6. Строгая типизация. Если в справочнике используется тип данных “дата”, то структура даты должна быть максимально явной. Если вы решили сэкономить две секунды для операторов, и сделали шаблон вида “__.__.__” с подсказкой “день, месяц, год”, будьте уверены, что в первый же день появятся записи “18.04.21”, “21.04.18” и “04.18.21”.

Пример #7. Запрещённые символы в максимально широком списке полей, словарные проверки. Например, если речь идёт про образование (должность), и классификаторы специальностей не помогли, вы позволяете пользователю ввести данные в текстовом поле, пусть там будут запрещены точки, кавычки, отдельно стоящие чёрточки (список не полный). Пример информации, качество которой повышается: “доктор технических наук”, “д.т.н.”, “ДТН”, “д-р техн. наук” и т.д.

Пример #8. Пустое и неуказанное значение (NULL) — это два разных значения. Например, неуказанное высшее образование/отсутствие высшего образования, неуказанное отчество/отсутствие отчества — разница велика, и она должна быть зафиксирована в явном виде. Хороший пример реализации — сайты по продаже билетов справа от отчества размещают галочку “нет отчества”.
Кстати, про ФИО, и особенно про отчество. Если вы предполагаете работу с физическими лицами из стран Средней Азии или Ближнего Востока, кейсы с “ибн”, “бен”, “кызы”, “оглы” (и др.) могут стать критичными в вопросах качества данных, например, при поиске дубликатов. Аналогичная история с порядком употребления этих данных (“Джон Смит”, “Смит, Джон”) и с двойными именами (“Анна Мария”, “Анна-Мария”, “Джон Чарьлз Смит”). Также для многих не иметь фамилию — это нормально. А ещё, с точки зрения одних, “Наталья” и “Наталия” — разные имена, а с точки зрения других — одинаковые. А ещё есть “сэр”, “доктор”…
Имя человека, на самом деле, отличный пример. Правил и исключений в именах настолько много, что лучшим выходом из ситуации будет не изобретать собственный велосипед, а подключить одну из готовых библиотек, содержащих в себе заведомо большое количество кейсов.