Прежде чем перейти непосредственно к системам управления мастер-данными, давайте определим, какого рода вообще бывают данные.
Ниже представлены 5 ключевых типов:
1. Метаданные (Metadata);
2. Референс-данные (Reference data);
3. Мастер-данные (Master data);
4. Транзакционные данные (Transactional data);
5. Исторические данные (Historical data).
Метаданные – это данные о данных. Они нужны для понимания и определения, какими данными оперирует предприятие. Метаданные определяют структуры, типы данных, доступы к ним и т.д. Существуют различные схемы для описания метаданных. Например, для описания структуры XML-документа может применяться XSD-схема, для описания веб-сервиса – WSDL-схема.
Референс-данные – это относительно редко меняющиеся данные, которые определяют значения конкретных сущностей, используемых при выполнении операций в рамках всего предприятия. К таким сущностям чаще всего относятся: валюты, страны, единицы измерения, типы договоров/счетов и т.д.
Мастер-данные – это базовые данные, которые определяют бизнес-сущности, с которыми имеет дело предприятие. К таким бизнес-сущностям обычно относятся (в зависимости от предметной отраслевой направленности предприятия) клиенты, поставщики, продукция, услуги, договора, счета, пациенты, граждане и т.п. Кроме информации непосредственно о той или иной мастер-сущности, в мастер-данные входят взаимосвязи между этими сущностями и иерархии. Например, с точки зрения поиска дополнительных возможностей продаж, может быть очень важно выявлять явные и неявные взаимосвязи между физическими лицами. Мастер-данные распространяются по всему предприятию и участвуют во всех бизнес-процессах. Обычно мастер-данные воспринимаются как ключевой нематериальный актив предприятия, т.к. от их качества и полноты зависит эффективность его работы. В России часто вместо термина «мастер-данные» используют термин «нормативно-справочная информация».
Транзакционные данные – это данные, которые образовались в результаты выполнения предприятием каких-либо бизнес-транзакций. Например, для коммерческого предприятия: продажи продуктов и услуг, закупки, поступления/списания денежных средств, поступления на склад и т.п. Обычно такие данные базируются в системе управления ресурсами предприятия (ERP) или других отраслевых системах. Естественно, транзакционные системы широко используют мастер-данные при выполнении транзакций.
Исторические данные – это данные, которые включают в себя исторические транзакционные и мастер-данные. Чаще всего такие данные аккумулируются в ODS и DWH системах и служат для решения различных аналитических задач и поддержки принятия управленческих решений.
Cистемы управления мастер-данными
Прежде чем перейти к системе управления мастер-данными, определим, что такое управление мастер-данными вообще.
Управление мастер-данными (Master Data Management, MDM) – дисциплина, которая работает с мастер-данными в целях создания «золотой записи», то есть целостного и всестороннего представления о мастер-сущности и взаимосвязях, эталона мастер-данных, который используются всем предприятием, а иногда и между предприятиями для упрощения обмена информацией.
Специализированные системы управления мастер данными (MDM-системы) автоматизируют все аспекты этого процесса и являются «авторитетным» источником мастер-данных масштаба предприятия. Часто MDM-системы управляют также и референс-данными.
Ситуация, когда MDM-система является единственным источником мастер-данных, все изменения вносятся в MDM-систему и только потом передаются в системы-потребители, называется «системой записей». Это идеальная ситуация для управления мастер-данными. Однако в реальной жизни все не так просто: MDM-система не всегда будет являться «системой записей». Из-за особенностей бизнес-процессов конкретного предприятия, технических сложностей конкретных систем и т.д., приходится создавать «копии» мастер-записей. Система, в которой содержится копия мастер-данных, называется «системой ссылок». Чтобы не терять управляемости, «система ссылок» обязательно должна находиться под управлением и синхронизироваться с «системой записей».
Три измерения MDM-систем
Рассмотрим MDM–систему в трех измерениях:
Обычно MDM-системы не внедряются «с наскоку», т.к. их внедрение – это сложный процесс последовательных преобразований масштаба всего предприятия, от ведения разрозненных данных до создания целостного всестороннего представления о мастер-сущности. Поэтому внедрение MDM-систем выполняется последовательно с постепенным приближением к целевому результату в трех указанных измерениях.
Рассмотрим подробнее эти измерения.
Домены
В контексте управления мастер-данными под доменом понимается конкретная область мастер-данных. Самые распространённые домены мастер-данных – это домен клиентов и домен продуктов. В западной литературе сложились устоявшиеся термины для управления мастер-данными в рамках этих доменов: Customer Data Integration (CDI) – для домена клиентов и Product Information Management (PIM) – для домена продуктов.
К CDI традиционно относятся не только клиенты, но и организации или физические лица, которые могут называться по-разному в зависимости от отрасли предприятия: клиенты, поставщики, банки, фонды, пациенты, граждане и т.д.
К PIM традиционно относятся: продукция, товары, материалы, услуги, работы и т.д.
Есть много общего в подходах к управлению мастер-данными CDI и PIM, но есть также и много отличий. Например, при дедубликации клиентских сущностей в большинстве случаев выполняется простой синтаксический анализ атрибутов сущностей и их сопоставление на основе вероятностных алгоритмов, в то время как в продуктовом домене проводится семантический/онтологический анализ атрибутов с подключением механизмов самообучения. Кроме того, в продуктовом домене у сущностей в зависимости от выбранной категории могут сильно различаться атрибуты (например, у ноутбуков свой набор атрибутов, а у стиральных машинок – свой). Все эти особенности различных доменов должны поддерживаться MDM-системами.
В последнее время имеет место тенденция создания мультидоменных MDM¬-систем с возможностью гибкой настройки структуры метаданных. Такая гибкость дает предприятию возможность описать мастер-данные конкретно под себя с учетом всех особенностей и нюансов, но при этом требует немалого времени и знаний, чтобы грамотно спроектировать и настроить такую систему. Также на рынке присутствуют системы с «жесткой» структурой мастер-сущностей, которые имеют уже корректно настроенные механизмы, но использование такой системы возможно только теми предприятиями, которые смогут подстроиться под нее. Обычно такие системы хорошо применимы для решения задачи управления мастер-данными в рамках какой-то узкой отрасли. По моему мнению, наиболее перспективными являются системы с гибкой моделью метаданных, но имеющие при этом преднастроенные для предприятий разных отраслей модели, которые можно быстро перенастраивать.
Методы использования
Методы использования MDM (Method of use) определяют то, для чего MDM система будет использоваться на предприятии. Иными словами, кто будет потребителем мастер-данных (естественно, их может быть несколько).
Основных методов использования три:
1. Аналитический (Analytical)
2. Операционный (Operational)
3. Коллективный (Collaborative)
Аналитический метод использования поддерживает бизнес-процессы и приложения, которые используют мастер-данные преимущественно для анализа эффективности бизнеса, предоставляют необходимые отчеты и выполняют аналитические функции. Часто это происходит посредством взаимодействия MDM с инструментами и продуктами BI. Обычно аналитическая MDM-система работает с данными только в режиме чтения, она не изменяет данные в системах-источниках, но занимается их очисткой и обогащением.
Операционный метод использования позволяет собирать, изменять и использовать мастер-данные в процессе выполнения бизнес-транзакций (операций) и служит для поддержки семантической согласованности мастер-данных в рамках этих операций внутри всех операционных приложений. Фактически, в этом случае MDM функционирует как OLTP-система, которая отрабатывает запросы от других операционных приложений или пользователей. Работа в таком режиме зачастую требует построения единого интеграционного ландшафта с использованием принципов сервис-ориентированной архитектуры (SOA) и применением инструментария сервисной шины предприятия (ESB). Идеально, если такие инструменты или входят непосредственно в MDM-систему, или являются ее продолжением (есть вендоры, которые имеют в своей линейке и MDM и ESB-решения, глубоко интегрированные между собой).
Коллективный метод использования позволяет создавать мастер-сущности в случаях, когда требуется коллективное взаимодействие между различными группами пользователей в процессе этого создания. Такое согласование обычно имеет сложные «ветвящиеся» бизнес-процессы, состоящие из различных автоматических и ручных задач. Ручные задачи выполняются различными специалистами по работе с данными (дата-стюардами) в порядке, определенном бизнес-процессом. Чаще всего коллективный метод использования применяется в продуктовом домене. Например, при создании нового продукта, когда существуют несколько ответственных за ввод разных данных, много ручной работы и финальное согласование. Важно, чтобы MDM-система позволяла настраивать произвольные бизнес-процессы для быстрой поддержки бизнес-процессов конкретного предприятия.
Стили внедрения
Обычно выделяют три основных стиля внедрения (implementation style):
1. Реестровый (registry);
2. Сосуществующий (coexistence);
3. Транзакционный (transactional).
Реестровый стиль внедрения предполагает создание источника мастер-данных как «системы ссылок» на нижестоящие источники данных. Реестровая MDM содержит только ключевые атрибуты, необходимые для идентификации и сопоставления сущностей. Реестровая MDM работает в режиме «только чтение», данные вводятся в системах-источниках и передаются в MDM для разрешения сущностей. Также в реестровой MDM могут храниться ссылки на источники неключевых данных, но сами эти данные обычно в MDM не передаются. Реестровый стиль внедрения обычно применяется в случае выбора операционного метода использования MDM (см. выше).
Сосуществующий стиль внедрения предполагает наличие распределенного ввода данных в нескольких источниках (бизнес-приложениях и MDM-системе). MDM-система в данном случае может являться «системой записей» только для части атрибутов. Тем не менее, в MDM-системе формируется полноценная мастер-сущность, изменения которой транслируются в другие системы (возможно, не все). Сосуществующий стиль внедрения довольно прост и часто применяется как первый шаг к следующему — транзакционному стилю, т.к. не требует глубокой переработки систем, взаимодействующих с MDM-системой.
Транзакционный стиль внедрения предполагает создание полноценной «системы записей», в которой хранятся все данные по мастер-сущностям. MDM-система в этом случае является «единственным источником правды» для всех систем-потребителей. Все операции по созданию и обработке данных выполняется на уровне MDM-системы. Ввод данных на уровне систем-потребителей запрещен. Такой подход обычно довольно сложен для внедрения, т.к. требует существенного изменения бизнес-процессов и систем-подписчиков.
Заключение
На практике, выбор той или иной стратегии внедрения MDM определяется многими факторами: целями предприятия в области управления мастер-данными, степенью зрелости предприятия, степенью готовности IT-инфраструктуры, наличием инвестиций на реализацию проекта и многими другими параметрами. Чтобы определиться со стратегией внедрения, нужно провести тщательный анализ всех этих факторов и составить подробное технико-экономическое обоснование проекта и детальный план-график с указанием фаз развития проекта. Но это уже другая обширная тема, требующая отдельного рассмотрения.
Одно можно сказать точно, что к внедрению MDM-системы нужно подходить очень взвешенно и поступательно. Большинство проектов внедрения MDM-систем проваливаются именно из-за недооценки сложности и объема изменений, с которыми приходится сталкиваться в MDM-проектах.
Максим Власов
Комментарии (33)
BigD
16.03.2017 22:55Хм, интересно обсудить классификацию.
Справочник валют (просто список) — это мастер-данные?
Курсы валют на каждый день — это мастер-данные?
Список стран, городов и регионов с некоторыми атрибутами — это мастер-данные?
Мэппинги наименований (например, мэппинг разных написаний SKU на сайтах магазинов с эталонным написанием) — а это?
Список рассылки получателей в привязке к регионам — а это?
Выгрузка списка сотрудников из HR (обновляемая автоматически) с некоторыми атрибутами (обновляемая вручную по этим сотрудникам) — а это?
Часто всё это запихивают в одну MDM систему, и не парятся.
AXELOT-IT
17.03.2017 13:00Обычно, валюты, страны, регионы и тому подобные классификаторы относят к референс-данным. При этом курсы валют, это уже мастер-данные. Поэтому действительно MDM-системы обычно управляют и референс и мастер-данными одновременно. И это правильно.
Magnetic_Air
17.03.2017 13:02Ну нагородили…
На мой взгляд, можно выделить всего 3 типа данных
1 Справочники — сущности
2 Документы — события изменения сущностей
3 Аналитические (отчеты) — вычисляемые данные для анализа
Т.е. справочники это основа, без которой ни документы ни отчеты не могут существовать.
Документы и Отчеты формируются на основе справочников и документов.
Таким образом Метаданные, Референс-данные и Мастер-данные — это справочники.
Транзакционные данные — Документы
И Исторические данные — Отчеты.AXELOT-IT
17.03.2017 13:12+1Во многом это вопрос терминологии. Ваша терминология близка к той, которую использует 1С в своей платформе 1С: Предприятие. Но там есть еще Перечисления, Регистры сведений, Регистры накопления, Регистры расчетов, Регистры бухгалтерии, Бизнес-процессы, Задачи и другие предметные сущности, которые можно отнести к тому или иному классу данных, представленных мной.
Есть еще один нюанс. Мастер-данные — это не обязательно только «справочники», на которые ссылаются «документы». В системе MDM часто хранят, например, сводные данные по оборотам по клиенту или по сделанным им заказам. А потом эти данные анализируют для выявления, например, предпочтений клиента в тех или иных продуктах или услугах.Magnetic_Air
17.03.2017 14:24Во многом это вопрос терминологии
Все верно, когда появляется новый термин, то, как правило, его смысл уже давно был кем-то описан ранее. А в теории важно только определить категории, его составляющие и зависимости, но главное не переусердствовать в этом.
Все-таки мы живем в мире, где видим объекты (Справочники), фиксируем события, которые с ними происходят и будут происходить (документы) и на этом основании можем анализировать, планировать и т.д.(Отчеты). А уже из этих «трех столпов» можно выделять категории, в зависимости от поставленных задач.VolCh
17.03.2017 14:39Объекты — это сущности, а справочники — значения. Со значениями событий не происходит. Одно значение может замениться на другое в какой-то сущности, но это будет событие изменения сущности, а не значения.
Magnetic_Air
17.03.2017 15:10Все зависит от поставленной задачи. Город тоже является объектом и у него есть свои значения, которые могут меняться, например, численность населения. Так же как и клиент может быть значением сущности товара
VolCh
17.03.2017 16:15Естественно. Если пишем систему управления административными единицами страны, то город полноценная сущность, а не справочник.
VolCh
17.03.2017 13:14Ну, я лично считаю, что справочник, например, стран и "справочник" клиентов — это очень разные типы данных. В конце-концов, страны могут вообще в хранилище не храниться, а быть захардкожены какой-нибудь хэш-картой в коде систем или подтягиваться для показа с какого-нибудь стороннего сервиса. Ну или заполняться/меняться миграцией базы и не иметь пользовательского интерфейса для создания/изменения/удаления.
В общем надо различать данные, которые меняются крайне редко и используются в основном только для заполнения по ссылке свойств других сущностей, и данные, создание, изменение и удаление которых являются сутью бизнес-процессов компании.
AXELOT-IT
17.03.2017 13:17Да, абсолютно верно. Поэтому и различаются референс-данные и мастер-данные.
Magnetic_Air
17.03.2017 14:56Ну, я лично считаю, что справочник, например, стран и «справочник» клиентов — это очень разные типы данных.
Конечно разные, также как и «резиновые сапоги» и «способность к левитации». Тут важно отталкиваться от поставленных задач и не углубляться в те процессы, которые в них не входят, а то придется писать программу взаимодействия объектов от начала сотворения Мира.
Важно понять, то, что это самостоятельные сущности (объекты), которые могут являться частью друг друга.
Вы также можете подтянуть справочник клиентов из Налоговой (гипотетически), но тут все дело в их количестве, хотя я не думаю что вы будете подтягивать населенные пункты всего Мира.
В общем надо различать данные, которые меняются крайне редко и используются в основном только для заполнения по ссылке свойств других сущностей, и данные, создание, изменение и удаление которых являются сутью бизнес-процессов компании.
Не спорю, но это уже категории базового объекта «Справочники» по жизненному циклу и их может быть сколько угодно, опять же — в зависимости от поставленных задач. Тогда как события создания, изменения и удаления сущностей будут регистрироваться Документами.VolCh
17.03.2017 18:20Грубо, одни и те же данные в зависимости от задачи могут быть как справочниками значений (часто вообще только для показа в UI), так и полноценными сущностями со своим жизненным циклом. Если в рамках единой системы предприятия (или даже сети систем сети предприятий) какие-то данные выступают исключительно как справочники значений (пускай иногда и пополняемые/изменяемые), то нигде в рамках этой системы или сети нет смысла приравнивать эти справочники к сущностям. Если же где-то выступают как значения, а где-то как сущности, то надо думать как лучше организовать связи и вообще.
Vlad_fox
17.03.2017 16:10Ниже представлены 5 ключевых типов:
откуда взята такая и почему именно такая типизация?AXELOT-IT
17.03.2017 16:34Это довольно устоявшаяся модель типизации MDM. Из наиболее полных книг на эту тему могу посоветовать:
https://www.amazon.com/MASTER-DATA-MANAGEMENT-GOVERNANCE/dp/0071744584/ref=sr_1_1?ie=UTF8&qid=1489757550&sr=8-1&keywords=MDM
https://www.amazon.com/Enterprise-Master-Data-Management-Information/dp/0132366258/ref=sr_1_2?s=books&ie=UTF8&qid=1489757596&sr=1-2&keywords=MASTER+DATA+MANAGEMENT
Первую из этих книг мы сейчас готовим к изданию на русском языке.
ALIron
17.03.2017 16:39=) это всего лишь мнение IBM который, в MDM не силен, мягко скажем.
AXELOT-IT
17.03.2017 16:45Ну у Gartner похожая классификация.
ALIron
17.03.2017 17:04Да Master и Reference у них стали управляться разными системами MDM — RDM.
Но это же маркетинг.
По факту получается что MDM&RDM — отраслевой стандарт.
А MDM&RDM&PDM(EDM) текущие требования рынка.AXELOT-IT
17.03.2017 17:39MDM&RDM по факту обычно управляется в одной системе. А вот PDM — это обычно отдельные системы. В этой части MDM обычно закрывают только PIM, и то не все. Например, Informatica MDM на PIM не особо специализируется, они больше на CDI.
ALIron
17.03.2017 18:05Да. Так было, но сейчас разделение «инженерного» и «экономического» контура стирается.
ALIron
17.03.2017 16:37Скорее всего отсюда.
http://booksite.elsevier.com/9780123743695/10steps_DataCategories.pdf
или
https://www.semarchy.com/semarchy-blog/backtobasics_data_classification/
В отрасли MDM принято такое разделение, но оно больше от потребности иметь классификацию и во многом притянуто.
Потому как
Ипотечный договор больше похож на Referencу, так как не меняется 25 лет.
Договор кредитной карты — на Master
Билет в автобусе (договор оказания транспортной услуги) — чистой воды Transactional.
Vlad_fox
17.03.2017 18:12спасибо за ссылки,
это не классификации/типизации а некоторые устойчивые, часто употребимые словосочетания, применяемые в области обработки оцифрованных бизнесс-данных.
напомнило — как-то в очередном приступе желания найти хорошую информацию о «информации» наткнулся на учебник по «информационным технологиям» какого-то вуза уровня губернии… открыл почитать, поскольку в других местах найти не удавалось, а вдруг этот Кулибин — Бруно что-то небанальное стоящее предложил
и… лучше б не открывал, аж стошнило от
— информация делится на цифровую и не цифровую, на важную и не важую, на срочную и не срочную… и так пол книги. надо чем-то N-часов по предмету мозги студентамзасратьнаполнить. чтоб эту ахинею поконспектировали, заучили и воспроизводили при опросах
ни понятие информации не раскрыто, ни закономерности ни одной, ни научных школ которые в этой области работают… ничего кроме воды
вышеприведенной классификации конечно достаточно, чтоб разделить предлагаемое ПО по сегментам для удобной продажи и для удобного дробления функций ИТ персонала для юзания.
не научный, чисто прикладной аспект. а так хотелось чего-то возвышенного и светлого…ALIron
20.03.2017 09:43Да прикладной, с научным дело сложнее он ближе к философии и применимость его часто спорна.
Поищу.
были пара авторефератов в Ленинке доступных без пароля, а так дисеров на эту тему «не много».
Что странно, так как уже затасканные bigdatы и прочие нейронки без этого не живут.
Так как «мусор на входе — мусор на выходе „
DarkOrion
18.03.2017 12:56А есть понимание, где заканчивается DWH и начинается MDM? Архитектурно, например.
ALIron
20.03.2017 09:38Архитектурно DWH — хранилище, а MDM — «струтктурилище» =)
Один хранит всё «как есть», а второй «как должно быть в идеальном мире».
Первый без второго живет, но плохо и DWH вынужден «на коленке» делать то что должен делать MDM.
Для себя я провел водораздел по Data Quality функционалу.
DWH не должен преобразовывать данные и содержать какие то правила их изменений.
Всё что ему нужно это обращаться или в DQ или напрямую в MDM с вопросом.
«Что это и есть ли у него связи?»
На примере.
В DWH данные о клиентских транзакциях из двух источников.
Установление связи между клиентами дело MDM. DHW получает таблицу кроссID (Xref) в которой учитываются и внутрисистемные дубли (один клиент заведен 2 раза в одной системе) и межсистемные дубли (один клиент в двух системах)
На основе этой таблицы DWH отдает BI информацию в «как есть» через призму «идеального мира MDM»Vlad_fox
21.03.2017 13:35ИМХО DWH более старый стек технологий, получающий данные из операционных систем в пакетном режиме с использованием устоявшегося набора ETL технологий (Data Quality туда входит в букву Т). Предоставляет бизнес сущности и факты их бизнес-активностей в согласованном, очищенном виде на следующий день(период дней) посл изменений. Смотрят в DWH как правило системы отчетности и бизнес-аналитики.
Но скорость бизнес-процессов возрастает. И вариант получить данные на следующий день уже часто не устраивает. Что еще хуже — бизнесс-данные нужны не только на уровне отчетов, а для обеспечения логики трансакций — в операционных процессах, онлайново.
и вот ИТ-индустрия родила стек технологий MDM — почти все то же что есть в хранилище, но
+ плюс получение данных из учетных и прочих инф. систем онлайн
+ плюс предоставление удобных апи для использования этих данных учетными и прочими инф. системами онлайн
— минус ведение фактов по бизнес сущностямALIron
21.03.2017 15:13Всё же DWH и MDM это сильно разные классы.
ETL можно и раз в минуту запускать выгружая произведенные операции.
Отчетность без фактов бизнес сущностей (транзакций) не собрать
MDM это больше про «общий язык» для систем. Маркетинговое — интеграция на уровне данных.
Отчетность использует MDM, но это один из побочных моментов «общего языка»
VolCh
Спасибо. Насколько велика и в каких нюнсах заключается разница между MDM и простым сервисом, выступающим единственным источником правды в рамках предприятия о тех же клиентах?
AXELOT-IT
В современные MDM, кроме непосредственно сервиса хранения мастер-данных (единственного источника правды) обычно входит целый набор сервисов: ETL-сервисы, сервисы управления качеством данных (профилирование, стандартизация, обогащение, дедубликация и т.д.), сервисы управления метаданными, сервисы управления доступом, сервисы для работы датастюардов (экспертов), сервисы управления иерархиями, сервисы поиска и многие другие.
VolCh
Грубо говоря, постепенно развивая простой сервис под требования бизнеса может оказаться, что нечаянно создали MDM? Причём некоторые из названных функций, в частности управление доступом и поиск входит в мало-мальски серьёзные сервисы изначально.
AXELOT-IT
Ну так часто бывает. Сначала задача кажется простой, поэтому по-быстрому слепили базу в SQL Server, а потом начали прикручивать туда разные фишечки. Вечная дилемма — выбрать что-то готовое или написать самим.
VolCh
Может и не кажется, понимаешь, что в итоге задача будет сложной, но действуют всякие MVP и прочие стратегии по ускорению выхода на рынок и минимизации начальных инвестиций.