Создаем реестр мастер-записей с альтернативными “версиями правды”

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

Создание реестра мастер-записей

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

Реестр готов, но наши пользователи почему-то еще не довольны новым централизованным произведением искусства. Оказывается, что качество данных реестра клиентов не достигает 100%, а скорость его обновления далека от режима онлайн. Все в порядке, нам не нужно ежесекундно отслеживать статус всех клиентов, тем более в едином хранилище данных, которое для этого не предназначено, мы хотим сохранить расходы компании в разумных пределах.

Рассмотрим следующий пример. В отдел продаж пришел клиент и принес необходимые документы, а данные там отличаются от нашего реестра мастер-записей. Отдел продаж долго думать не станет, оформит договор по предоставленным данным “как есть”. Но в едином хранилище в важном аналитическом отчете для руководства мы хотим привязать оформленный договор именно к мастер-записи. Тут нам придется в качестве временного решения до выяснения всех обстоятельств использовать данные отдела продаж как новую “версию правды” для MDM. Получается, что у нас возник новый источник для реестра – клиентская система отдела продаж, и пользователи как минимум в том же отделе, которым необходимы данные на основе данного источника. Когда возникает несколько “версий правды”, необходимо создавать инцидент по качеству данных и проводить его расследование. В случае выявления ошибки пользователем и до момента официального подтверждения этой ошибки от владельца/поставщика данных, пользователь для своей работы будет использовать нужное ему значение (свою версию).

Версионность

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

Кстати, если кому-то из пользователей в поле “Наименование клиента” требуется полное название клиента, а кому-то сокращенное или на английском языке, то это не вопрос MDM или “версий правды”, это значит что, ваша модель данных не предусматривает такую возможность и пора ее менять, добавив соответствующие атрибуты или справочник типов наименований клиентов.

Пусть пользователь для своей работы будет использовать нужное ему значение своей “версии правды”. Такие значения иногда называют “синонимом” и ведут в таблице синонимов, но это скорее альтернативное значение и для краткости далее будем называть его “альтернативой”.

Роли и порядок ведения реестра мастер-записей

Для ведения “версий правды” предлагается использовать следующие принципы:

• У пользователей по необходимым атрибутам, которые являются результатом алгоритма мастер-записи, должен быть доступ к вводу своих альтернатив. Такой пользователь выступает в роли модератора альтернативных значений.
• Альтернативы расчетных (производных) атрибутов считаются автоматически на основе первичных альтернатив. Этот принцип означает, что не нужно менять расчетные значения, необходимо заниматься алгоритмами или первичными данными.
• Альтернативы могут быть твердые и мягкие. В случае если оригинальное значение мягкой альтернативы изменилось, и оно отличается от текущей альтернативы, модератор альтернативы должен его вновь подтвердить. Твердая альтернатива всегда перекрывает оригинальное значение.
• Другие пользователи по желанию и договоренности могут использовать альтернативы выбранного модератора. При этом они сами могут выступать модераторами и делать альтернативу на альтернативу. Образуется ориентированное дерево (связный ациклический граф) альтернатив, где корнем является оригинальное значение атрибута. Уровень корня дерева равен 0 – в нем публикуется единая версия правды.
• Уровень листа дерева (конечной вершины графа) не должен быть больше 2.
• При этом первый модератор не несет ответственности за последующих модераторов, т.е. все конфликты должны разрешать последующие модераторы на более высоком уровне.