Чего хотеть от MDM проекта?

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

В статье выделим 5 важных граней проекта MDM, в рамках каждой из них соотнесем стандартные ожидания заказчиков с реальными практическими результатами. А также предложим вам перечень вопросов, которые нужно задать себе прежде чем идти в проект, чтобы «заадекватить» собственные ожидания.

Обычно, когда идет речь о внедрении MDM системы, то первый ответ, который мы слышим на вопрос «для чего?» - это формирование единой системы с эталонными данными в рамках IT ландшафта, к которой подключение новых систем будет выполняться достаточно легко. При этом между старыми системами должно быть выстроено четкое соответствие их элементов НСИ эталонным элементам. А также в этой системе не будет дублей и «мы всей командой максимально постараемся сделать кристально чистые данные. Вот тогда и заживем»

В реальности эти ожидания разбиваются об ограничения, в которых приходится действовать командам при внедрении таких систем (ограничителями чаще всего бывают здравый смысл, сроки и бюджет):

• ограничение по составу данных, которые подлежат централизации
• ограничения внутри каждого домена данных, когда например, централизуется не весь справочник, а какая-то его общеприменимая часть (особенно такое встречается в холдингах, чтобы слона можно было съесть по частям)
• ограничения по раздаче, казалось бы, централизованных данных в системы-подписчики. Как пример, попробуйте отдать в старые УППшки, где у определенного круга пользователей настроены пачки отчетов на иерархию номенклатуры ее новую из MDM системы. Да даже на этапе первоначального заполнения явно будут вопросы, чью иерархию брать за основу в рамках большого исторически выстроенного IT ландшафта
• ограничения процесса нормализации данных. Здесь могут вмешиваться в такое благое начинание ограничения от старых систем-подписчиков, в которых какие-то учетные кейсы могли решаться исключительно за счет дублирования каких-то элементов. И как следствие – при внедрении MDM системы сначала с большой вероятностью придется собрать в единую картинку все наследие старых систем, чтобы обеспечить их выживаемость. Далее сформировать требования к новым системам, чтобы в них аналогичные кейсы можно было решать иначе, и дальше ждать, когда можно будет переходить к процессу нормализации данных после замены старых систем. Но для этого надо иметь хорошую дорожную карту развития MDM как рабочий инструмент и пользоваться ей.

Сформируем на старте проекта для себя понимание, как выстроим полочки, по которым разложим данные, и дальше, как по маслу, подключим все системы к MDM.

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

• созданные кастомные справочники грузополучателей в УППшках для решения своих локальных задач,
• ведение иерархического справочника «партнеры» (на одном справочнике совместить и контрагентов и точки доставки),
• контактная информация (как со стороны типовых продуктов), так и в некоторых импортных решениях, где это может быть частью общей адресной книги с номерами телефонов и почтовыми адресами.

В стандартах заполнения хотелось бы выделить 2 подвопроса:

1. утвержденный состав обязательных реквизитов для каждого сегмента данных
2. формат указания данных (наименований, адресов итд)

Концептуально оба вопроса логично прорабатывать на этапе выработки требований к модели.

Обычно ожидается, что по результату эти вопросы проработаны идеально и дальнейших изменений не потребуется.

Этап формирования требований и моделирования, конечно, прошел, но:

• По 1-му вопросу от параллельных проектов могут появляться предложения по обогащению реквизитного состава. Здесь как рекомендация – заранее смотреть в сторону глобальных идентификаторов, например которые относятся к различным ГИСам.
• По 2-му вопросу нюансы могут всплыть ближе к моменту наполнения начальных данных. Например, выяснится, что в одной из систем-источников адреса велись не в формате КЛАДРа/ФИАСа, а возможно в виде какой-то произвольной строки, которую пользователи заполняли как умели. Здесь какую-то часть проблем можно будет снизить за счет использования сторонних сервисов по обработке данных, например Dadata.