Покупать готовую MDM или разрабатывать свою?

Здесь я уже писал о том, что такое 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 система и насколько это согласуется с теми системами, с которыми предполагается взаимодействовать. Проверьте легкость подключения новых систем-подписчиков и скорость их подключения. Также важна возможность изменять логику и маршруты получения и распространения данных без глубокой модификации всех систем и с минимальными простоями.

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

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