Технология проекта внедрения MDM-системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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