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

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

Поэтому я начну с того, что опишу типовые функциональные возможности, которыми должна обладать современная MDM-система.

Управление жизненным циклом мастер-данных:


Ключевая функциональность MDM-систем – это способность управлять мастер-данными на всем протяжении их жизненного цикла: от момента их определения до момента прекращения их использования.

Для этого MDM-система должна поддерживать следующие возможности:

  • Создание модели данных. В рамках создания модели данных определяются объекты мастер-данных, структуры их моделей и атрибуты. Принципиально важно обеспечить возможность гибкого создания и изменения модели данных на всем протяжении жизненного цикла объекта мастер-данных. В процессе ежедневной работы часто возникают ситуации, когда нужно быстро добавить недостающий атрибут или изменить существующую схему модели объекта мастер-данных. Выполнять эту задачу необходимо оперативно, в пользовательском режиме, без перепрограммирования и остановки системы.
  • Использование универсальных хранилищ данных. В отличие от, например, ERP-систем, данные MDM хранятся в специальных форматах, которые позволяют хранить данные одновременно в различных СУБД. Это обеспечивает быстрый доступ к данным в различных сценариях и дает возможность горизонтального масштабирования и кластеризации хранилищ данных. Типовым подходом считается разнесение информационных доменов по различным хранилищам данных.
  • Хранение кэшей «горячих» данных, размещаемых в памяти с активной подкачкой. Для обеспечения высокой скорости доступа к данным самые «горячие» данные загружаются в различные кэши в оперативной памяти. Специальные механизмы отслеживают изменяющуюся активность запроса данных и с помощью инструментов прогнозирования осуществляют оперативную актуализацию данных в кэшах.
  • Управление группировками и иерархиями объектов мастер-данных. Объединение объектов мастер-данных в группы или иерархии используется для решения множества прикладных задач, например, создания иерархии организаций, входящих в холдинг, или группировки товаров по какому-либо признаку и т.п.
  • Создание и управление взаимосвязями. Взаимосвязи существуют между объектами мастер-данных как внутри одного домена, так и между доменами. Например, можно установить несколько типов взаимосвязей между физическими лицами и организациями: физическое лицо может работать в организации, быть клиентом организации, быть поставщиком организации и т.д.
  • Версионирование и хранение истории изменений. Очень важно хранение исторической информации не только по самим объектам мастер-данных и атрибутам их моделей, но и по структуре моделей, взаимосвязям с другими объектами, иерархиями, группировками и т.д… Например, для принятия какого-либо решения может быть важно знать, что такое-то физическое лицо раньше было сотрудником такой-то организации. В идеальном случае история должна обеспечивать возможность отката состояния данных на любую выбранную точку восстановления.
  • Ведение таксономий. Для объектов мастер-данных могут быть определены различные таксономии. Например, для материально-технических ресурсов может быть задан один или несколько классификаторов: первый — группирующий элементы с точки зрения покупателя по товарным категориям, а второй – с точки зрения закупщика по поставщикам. От установленной таксономии могут зависеть наборы атрибутов модели того или иного элемента мастер-данных.
  • Обеспечение безопасности данных. MDM-система должна иметь инструменты по настройке и обеспечению разграничения доступа к данным как на уровне записей, так и на уровне атрибутов.
  • Проведение аудита. Должна быть возможность прослеживания истории всех изменений данных и моделей, кем и когда они были совершены.

Управление качеством


Некачественные данные сводят на «нет» весь эффект от централизации данных и их централизованного управления.

Для управления качеством данных в системе должны присутствовать следующие механизмы и инструменты:

  • Анализ и профилирование данных. Прежде чем приступать к каким-либо манипуляциям с данными, необходимо эти данные изучить. Автоматические механизмы анализа и профилирования данных позволяют грубо оценить качество данных, выявить ошибки в данных, выстроить стратегию их обработки. Для анализа данных без привязки к какой-то предметной области чаще всего применяются методы статистического анализа. Данный анализ позволяет выявить наличие и глубину проблем с полнотой данных (пропуски), «подозрительными» записями (экстремальные значения и выбросы по одному из атрибутов, записи, не попавшие ни в один кластер), непригодными без предварительной подготовки атрибутами для использования в методах машинного обучения (пропуски, выбросы, экстремальные значения, малая частота встреч некоторых уникальных значений и т.д.). Если проводить анализ с погружением в предметную область и анализируемые домены, то следует учитывать подтипы данных (упорядоченные и категориальные) и виды данных (непрерывные и дискретные) для каждого атрибута. Определив основные типы, подтипы и виды данных, возможно обоснованно анализировать рассчитанные статистические показатели и провести профилирование имеющихся данных, определить способы коррекции их значений, подготовить данные для использования современных методов моделирования.
  • Валидация, стандартизация, очистка и обогащение данных. Тут могут применяться такие простейшие механизмы как приведение значений к единому формату (например, телефонных номеров), удаление/замена случайных вкраплений символов «другого» алфавита, удаление лишних пробелов, замена сокращений и аббревиатур по словарю, исправление явных опечаток и т.д… Также могут применяться и более сложные механизмы на основе бизнес-правил, использования для очистки и обогащения внешних баз данных (например, баз данных адресов или юридических лиц).
  • Выявление дублирующихся сущностей мастер-данных. Одна из ключевых возможностей системы. Должны быть как механизмы дедубликации на основании четких бизнес-правил для структурированных данных (часто используются в домене Клиентов), так и различные сложные семантические механизмы с возможностью самообучения для слабоструктурированных и неструктурированных данных (часто используются в домене Номенклатуры).
  • Работа дата-стюардов (экспертов), занимающиеся полуавтоматической или ручной обработкой данных. Должны быть рабочие места, где удобно выполнять различные манипуляции с данными, которые невозможно было выполнить автоматически на более ранних этапах, или этапы, за которые несет ответственность лицо, принимающее решение. К работе дата-стюардов может относиться редактирование атрибутов, не поддающихся автоматической обработке, подтверждение дубликатов и выбор «выживающего» элемента или атрибута и т.д.
  • Оценка изменения качества данных с течением времени. Это возможность создания специализированных KPI по качеству данных и отслеживания их состояния во времени. На основе этих показателей можно строить политику мотивации подразделения НСИ в компаниях.

Интеграция и синхронизация информации


Задача интеграции и синхронизации информации между MDM-системой и прикладными системами, потребляющими мастер-данные, является одной из основных. Данные должны быть синхронизированы между всеми участниками взаимодействия. Часто эта функция обеспечивается не самой MDM-системой, а специализированной ESB или MQ-системой. В идеале, ESB-система должна быть построена на единой с MDM-системой технологической платформе, т.к. при этом обеспечивается максимальная интеграция между ними.

Для построения механизмов взаимодействия должны присутствовать следующие возможности:

  • Получение данных или изменений в данных из прикладных систем в синхронном и асинхронном режимах.
  • Распределение мастер-данных из MDM-системы по прикладным системам в синхронном и асинхронном режимах.
  • Передача различного рода событий из MDM-системы в прикладные системы. Например, о том, что какие-то данные устарели, и с каким-то клиентом мы уже не работаем, и данные о нем нужно удалить или отправить в архив.
  • Исправление ошибок синхронизации: отслеживание отправленных, но не полученных данных, повторная отправка, разрешение конфликтов в актуальности переданных данных и т.п.
  • Важно обеспечить взаимодействие в реальном времени для эффективного функционирования сквозных бизнес-процессов. Это особенно важно при операционном методе использования MDM (Operational MDM), когда прикладные системы могут пользоваться сервисами MDM в рамках единой бизнес-транзакции.

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

И все же, писать или покупать?


Если вы склоняетесь к реализации MDM-системы собственными силами, то оцените, какие из приведенных выше функций требуются вам не только сейчас, но и в будущем. Часто компании, которые идут по этому пути, начинают с реализации некого подобия центральной базы данных, в которую помещаются объекты мастер-данных в высокой степени готовности (вручную или с помощью пакетной загрузки) и из которой потом выгружаются мастер-данные в прикладные системы-подписчики. Часто такой подход называется «централизацией ввода справочников», который используется для обеспечения единой точки ввода справочной информации, т.е. фактически для упрощения ее ввода. В большинстве случаев на этом проекты, завязанные на самостоятельную разработку, заканчиваются, и дальнейшее развитие функционала не происходит из-за большей сложности реализации других возможностей MDM-систем. Строго говоря, такие результаты нельзя считать полноценным управлением мастер-данными. Тем не менее, некоторым компаниям, у которых не так много сущностей мастер-данных и невысокие требования к качеству данных, бывает достаточно и этого.

Если же вы не хотите ограничиваться простой «централизацией ввода справочников», то с высокой степенью вероятности вы захотите внедрить готовую MDM-систему. Тут вам предстоит непростой выбор MDM-системы, которая для вас лучше подходит.

Если касаться функциональности системы, то следует проводить анализ только после того, как вы уже более-менее представляете, какие задачи вы хотите решать с помощью MDM-системы: какие домены данных у вас есть, какой метод использования (method of use) и какой стиль внедрения (implementation style) вы выберете. Вот тут подробнее про это. Только после определения задач можно оценивать функциональность MDM-системы, т.к. не все MDM-системы одинаково хороши во всем разнообразии доменов/методов использования/стилей внедрения.

Кроме перечисленных выше функций, обратите особое внимание на следующие аспекты MDM-систем:

  • Поддержка доменов. Исторически многие MDM-системы развивали архитектуры с поддержкой какого-то одного домена, например, Клиентов. Такие системы часто плохо поддерживают другие домены и не специализируются на них. Например, принципы работы с данными домена Клиентов и с данными домена Продукции очень сильно отличаются. Поэтому категорически недостаточно проанализировать функционал системы на примере какого-то одного домена, нужно смотреть все.
  • Если у вас планируется внедрять коллективный метод использования (Collaborative method of use), то обратите внимание на удобство настройки бизнес-процессов и ролей пользователей. Это должно по возможности делаться без программирования, в параметрическом режиме, т.к. процессы и регламенты часто меняются.
  • Если же вы планируете внедрять операционный метод использования (Operational method of use) с максимальной автоматизацией функций обработки данных и с минимальным привлечением дата-стюардов, то нужно обратить внимание на наличие механизмов автоматической обработки и механизмов по настройке последовательности их использования, на наличие быстрых способов передачи данных между системами-источниками и MDM.

Также критически важно обратить внимание на производительность и отказоустойчивость предлагаемой вам системы. Без этих двух свойств любая MDM-функциональность будет бесполезна.

Вот некоторые пункты, которые нужно обязательно проверить:

  1. Попросите потенциального поставщика MDM смоделировать объект мастер-данных наибольшего объема и загрузить эти данные в MDM. Оцените скорость загрузки данных.
  2. Проведите разного рода поиски по загруженным данным: поиск по основным атрибутам, поиск по дополнительным атрибутам, нечеткий поиск по разным алгоритмам, полнотекстовый поиск. Оцените скорость поиска. Это очень важный базовый параметр. От скорости и качества поиска зависят многие другие функции системы и скорость их работы. Если на этом этапе наблюдается медленная работа системы, то дальше будет только хуже.
  3. Измените модель какого-либо объекта мастер-данных или ее атрибут. Оцените скорость реструктуризации информации и скорость откатки назад в случае непредвиденной ситуации.
  4. Проанализируйте время отклика системы на стандартные запросы в том режиме использования, который планируется к внедрению у вас в компании. Например, многие MDM-системы удовлетворительно работают в режиме Transactional Hub, когда все данные вводятся непосредственно в MDM и потом распределяются по системам-подписчикам, но при этом их производительности не хватает при работе в режиме Coexistence Hub, когда нужно очень быстро взаимодействовать между системами в двухстороннем режиме в реальном времени.
  5. Проанализируйте, какие интеграционные механизмы поддерживает MDM система и насколько это согласуется с теми системами, с которыми предполагается взаимодействовать. Проверьте легкость подключения новых систем-подписчиков и скорость их подключения. Также важна возможность изменять логику и маршруты получения и распространения данных без глубокой модификации всех систем и с минимальными простоями.

В любом случае процесс выбора пути – творческий процесс и невозможно предсказать все вопросы, которые возникнут, но я постарался описать основные, которые мне кажутся важными.

Максим Власов, директор по развитию

Комментарии (5)


  1. jakobz
    15.11.2017 10:07

    А можно где-нибудь посмотреть обзор существующих MDM-решений? А то все MDM, что гуглятся — они какие-то из прошлого: с десктопными UI, без возможности в демку потыкать или хоть на видео посмотреть. В уме сразу дорисовываются все эти ETL-и из квадратиков, стрелочек, и ODBC-адаптеров, километровые XML-конфигурации, «Java-апплеты не поддерживаются в вашем браузере»… Рынок действительно еще где-то там?


    1. AXELOT-IT Автор
      15.11.2017 10:39

      Ну обзор по MDM можно взять хоть Гартнеровский. По подходам к интерфейсной части, чаще всего в качестве среды настройки системы используют экосистему Eclipse, а для работы непосредственно пользователей (дата-стюардов) разрабатывают веб-интерфейс. Такая схема выглядит в целом довольно неплохо. Но есть и полностью web-based приложения, например, EBX5. Ну или 1С:MDM, если рассматривать наш рынок.


  1. AXELOT-IT Автор
    15.11.2017 10:38

    Ну обзор по MDM можно взять хоть Гартнеровский. По подходам к интерфейсной части, чаще всего в качестве среды настройки системы используют экосистему Eclipse, а для работы непосредственно пользователей (дата-стюардов) разрабатывают веб-интерфейс. Такая схема выглядит в целом довольно неплохо. Но есть и полностью web-based приложения, например, EBX5. Ну или 1С:MDM, если рассматривать наш рынок.


  1. SbWereWolf
    15.11.2017 20:12

    не очень понимаю за что у поста рейтинг "-2", намой вкус, большая удача, найти подобную статью в момент выбора «быть или не быть»


    1. AXELOT-IT Автор
      16.11.2017 18:08

      Спасибо за отзыв. Если честно, тоже не очень понимаю по какому принципу люди реагируют на ту или иную статью. Возможно эта тема вообще людям не очень близка, или просто не задумываются, что там может быть что-то сложное.