В данной статье мы рассмотрим процесс внедрения системы управления мастер-данными (MDM). Разберем, на какие шаги раскладывается задача.

Шаг 1. Формирование требований

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

Определение цели и критерия завершенности рассматриваемого этапа

Например, мы решили начинать с номенклатуры, или с клиентов. Цель — определить границы данных, которые мы централизуем (домены, справочники, сегменты).

Пример критерия завершенности: УТ и ERP подключены к MDM и получают централизованную информацию (контрагентов и номенклатуру готовой продукции) только из MDM. Остальным пользователям доступ на заведение данных в эти дочерние системы закрыт.

Определение доменов данных для централизации

Домены данных — это крупные области данных, которые мы далее будем рассматривать.

С точки зрения определения того, что мы будем включать, я бы рекомендовал смотреть на ближайший пул проектов (горизонт — год), и в работу брать именно те домены данных, которые будут касаться этих проектов. Делать эту задачу только для ИТ тяжеловато. Чтобы результаты проекта жили, обязательно должен быть спрос со стороны бизнеса и бизнес-потребитель.

Формирование перечня систем, подключаемых к MDM в рамках проекта

Здесь в первую очередь необходимо посмотреть на текущий ИТ-ландшафт:

  • определить точки входа НСИ;
  • понять, какие системы сейчас каскадом подключены к каким-то первоначальным системам, в которые заводится информация;
  • понять, как мы будем выстраивать интеграционные потоки. Будет ли это все по модели звезды? Или у нас где-то будет звезда, а дальше от нее будут запускаться каскады.

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

Формирование модели данных

Глядя на домены данных, которые мы определили вторым пунктом, надо понять, какие справочники, регистры будут входить в модель данных, которую мы собираемся централизовывать.

Когда мы говорим про номенклатуру или контрагентов, это не во всех ИС они могут быть реализованы как один справочник (например, в ИС может быть справочник клиентов и поставщиков). При этом с точки зрения здравого смысла надо забрать те данные, которые повторно использованы в других системах и их логично вести централизованно. А по тем, которые не подлежат централизации, договариваться, что их в рамках бизнес-процесса будут дополнять в системах-получателях.

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

Выделение источников данных для начального заполнения и обогащения

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

Например, в системе «А» у нас максимально широкий перечень номенклатуры, но оттуда мы можем взять только 20 реквизитов из 50 нужных. Остальные 30 у нас есть в смежных системах «В», «C» и «D», из которых мы и будем их забирать. Осталось только продумать план миграции.

Определение целевой схемы процессов согласования данных

Почему это важно? Потому что это, по сути, лицо проекта, которое взаимодействует потом с бизнесом.

У нас с вами есть две стороны:

  • Функциональные пользователи, у которых в принципе может формироваться потребность о том, чтобы была заведена какая-то карточка номенклатуры или новые точки доставки.
  • Команда экспертов по НСИ, которая заведует самим качеством данных. Им нужно иметь набор данных, чтобы по заявке от пользователя легко вводить их в систему и вычленять по ним дубли.

С точки зрения процесса взаимодействия с MDM это может быть вход через web-форму или интеграция с другой системой. Надо смотреть на конкретный кейс и выбирать наиболее удобную для пользователей схему. Ну и естественно там будут вопросы, связанные с оповещением бизнес пользователей о статусах заявок. Это очень важный аспект, потому что по нему потом будет также даваться оценка со стороны бизнеса — а как нам вообще с MDM-системой живется?

Шаг 2. Разработка

Макет MDM

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

Интеграции

Появление MDM-системы в принципе увеличивает количество интеграционных потоков. Причем на текущий момент уже все привыкли, что интеграции — это нормально. Главное — уметь их хорошо готовить.

Механизмы ограничения доступа пользователей в базах-подписчиках

Даже если мы имеем хороший квалифицированный персонал из бизнеса, мы все равно имеем дело с человеческим фактором.

Например, мы оповещаем людей, что подключили системы «А» и «В» к MDM-системе, и с сегодняшнего дня точки доставки вводить не надо. Все отлично ровно до того момента, пока люди от этом помнят.

Как только что-то потребовалось быстро получить или внести какую-то точку доставки, люди могут по старой памяти сделать это по старой схеме. Локально они свою проблему решат, а вот вы с точки зрения MDM-проекта получите определенное приключение. Вам потом эти данные надо мигрировать в основную MDM-систему, дальше понять, надо ли это объединять с какой-то другой карточкой, и если не надо, то раздать в другие системы, а если не надо, уже решать этот инцидент отдельно. Ограничение доступа пользователей в базах-подписчиках решает эту проблему.

Инструменты переноса данных

Один из шагов — это перенос данных из других систем. Из плана запуска нам становится понятно, из каких систем мы будем забирать первоначальные данные. Для этого могут быть использованы отдельные механизмы: разовые инструменты выгрузки и загрузки данных через различные форматы, либо интеграционные потоки, которые временно будут включены через корпоративную шину данных.

Инструменты нормализации

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

К инструментам нормализации мы обычно относим инструменты проверки полноты заполнения реквизитного состава по централизуемым данным, механизмы их обогащения, а также инструменты анализа дублей.

Рекомендую всем подходить к вопросам нормализации со здравым смыслом, потому что в гонке за качеством можно потратить очень много денег, а основная задача здесь — получить хороший результат с относительно понятными затратами.

Шаг 3. Подготовка к запуску

Здесь у нас получается, что уже в наличии есть готовая система, готовые данные к переносу и остается:

  • Обучение пользователей.
  • Начальное заполнение данных.
  • Обогащение/нормализация.

Желательно шаг 3 располагать максимально близко к шагу 4. Хочется минимизировать то время, когда у нас данные в MDM попали и при этом параллельно еще что-то может завестись в старых системах.

Шаг 4. Запуск

Он включает:

  • Подключение систем подписчиков.
  • Ограничение прав на прямое редактирование ЦНСИ в подписчиках.
  • Поддержка запуска и мониторинг.

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

Подведем итог

  • На выходе из проекта надо иметь НСИ хорошего качества.
  • Думайте о людях (кто пользуется MDM с двух сторон — эксперты и обычные пользователи).

Валерий Немцов, менеджер продукта интеграции компании “Константа”