Всем привет. Сегодня поговорим о том, чего хотеть от проекта MDM, если вы его собираетесь начинать. Формирование культуры спроса на такие проекты на отечественном пространстве цифровизации еще в процессе, поэтому кому-то может потребоваться помощь, чтобы расчертить карту проекта, понять точки, на которые стоит обратить внимание. А кому-то перепровериться, чтобы понять, что все идет верным путем.
В статье выделим 5 важных граней проекта MDM, в рамках каждой из них соотнесем стандартные ожидания заказчиков с реальными практическими результатами. А также предложим вам перечень вопросов, которые нужно задать себе прежде чем идти в проект, чтобы «заадекватить» собственные ожидания.
В статье выделим 5 важных граней проекта MDM, в рамках каждой из них соотнесем стандартные ожидания заказчиков с реальными практическими результатами. А также предложим вам перечень вопросов, которые нужно задать себе прежде чем идти в проект, чтобы «заадекватить» собственные ожидания.
1. MDM система как единый источник НСИ
Ожидание
Обычно, когда идет речь о внедрении MDM системы, то первый ответ, который мы слышим на вопрос «для чего?» - это формирование единой системы с эталонными данными в рамках IT ландшафта, к которой подключение новых систем будет выполняться достаточно легко. При этом между старыми системами должно быть выстроено четкое соответствие их элементов НСИ эталонным элементам. А также в этой системе не будет дублей и «мы всей командой максимально постараемся сделать кристально чистые данные. Вот тогда и заживем»
Реальность
В реальности эти ожидания разбиваются об ограничения, в которых приходится действовать командам при внедрении таких систем (ограничителями чаще всего бывают здравый смысл, сроки и бюджет):
- ограничение по составу данных, которые подлежат централизации
- ограничения внутри каждого домена данных, когда например, централизуется не весь справочник, а какая-то его общеприменимая часть (особенно такое встречается в холдингах, чтобы слона можно было съесть по частям)
- ограничения по раздаче, казалось бы, централизованных данных в системы-подписчики. Как пример, попробуйте отдать в старые УППшки, где у определенного круга пользователей настроены пачки отчетов на иерархию номенклатуры ее новую из MDM системы. Да даже на этапе первоначального заполнения явно будут вопросы, чью иерархию брать за основу в рамках большого исторически выстроенного IT ландшафта
- ограничения процесса нормализации данных. Здесь могут вмешиваться в такое благое начинание ограничения от старых систем-подписчиков, в которых какие-то учетные кейсы могли решаться исключительно за счет дублирования каких-то элементов. И как следствие – при внедрении MDM системы сначала с большой вероятностью придется собрать в единую картинку все наследие старых систем, чтобы обеспечить их выживаемость. Далее сформировать требования к новым системам, чтобы в них аналогичные кейсы можно было решать иначе, и дальше ждать, когда можно будет переходить к процессу нормализации данных после замены старых систем. Но для этого надо иметь хорошую дорожную карту развития MDM как рабочий инструмент и пользоваться ей.
Вопросы для самодиагностики:
- Какие системы мы готовы взять в ближайший периметр MDM проекта?
- Какие данные мы видим централизуемыми в рамках IT ландшафта?
- Какие у нас будут критерии к составу данных в рамках одного домена?
- По каким правилам мы будем осуществлять нарезку внутри каждого справочника? (если он будет состоять из разных сегментов, которые надо по выделенным правилам маршрутизировать в рамках ландшафта)
- Каким образом сформулируем критерий достаточной чистоты данных в текущий момент, чтобы зафиксировать текущий результат?
2. Правила ведения НСИ (видение архитектуры)
Ожидание
Сформируем на старте проекта для себя понимание, как выстроим полочки, по которым разложим данные, и дальше, как по маслу, подключим все системы к MDM.
Реальность
С этой группой вопросов сталкиваются чаще всего уже в процессе внедрения, когда понимают, что подключение одной из систем как-то недостаточно хорошо укладывается в модель, которую придумали на старте. Кейс из области клиентского сервиса – ведение точек доставки. Если мы говорим про исторически выстроенный IT ландшафт, то можем встретить целый пучок вариантов, которые надо будет думать, как мирить между собой:
- созданные кастомные справочники грузополучателей в УППшках для решения своих локальных задач,
- ведение иерархического справочника «партнеры» (на одном справочнике совместить и контрагентов и точки доставки),
- контактная информация (как со стороны типовых продуктов), так и в некоторых импортных решениях, где это может быть частью общей адресной книги с номерами телефонов и почтовыми адресами.
Вопросы для самодиагностики:
- Что из себя эти данные архитектурно представляют в тех системах, которые попадают в рассматриваемый горизонт MDM проекта?
- Какие в этих системах взаимосвязи по этим данным? (как пример подчинение другому справочнику, иерархия в рамках одного и вхождение в состав какой-то более универсальной сущности)
- Какая система будет взята за основу для первоначальной миграции данных?
- Каким образом будет выполнено техническое решение по стыковке данных разной архитектуры, чтобы обеспечить целостность?
3. Стандарты заполнения
В стандартах заполнения хотелось бы выделить 2 подвопроса:
Концептуально оба вопроса логично прорабатывать на этапе выработки требований к модели.
- утвержденный состав обязательных реквизитов для каждого сегмента данных
- формат указания данных (наименований, адресов итд)
Концептуально оба вопроса логично прорабатывать на этапе выработки требований к модели.
Ожидание
Обычно ожидается, что по результату эти вопросы проработаны идеально и дальнейших изменений не потребуется.
Реальность
Этап формирования требований и моделирования, конечно, прошел, но:
- По 1-му вопросу от параллельных проектов могут появляться предложения по обогащению реквизитного состава. Здесь как рекомендация – заранее смотреть в сторону глобальных идентификаторов, например которые относятся к различным ГИСам.
- По 2-му вопросу нюансы могут всплыть ближе к моменту наполнения начальных данных. Например, выяснится, что в одной из систем-источников адреса велись не в формате КЛАДРа/ФИАСа, а возможно в виде какой-то произвольной строки, которую пользователи заполняли как умели. Здесь какую-то часть проблем можно будет снизить за счет использования сторонних сервисов по обработке данных, например Dadata.
Вопросы для самодиагностики:
- Требования каких систем и процессов в вашем IT ландшафте вошли в основу требований к централизуемому реквизитному составу?
- Не забыли ли посмотреть на данные через призму требований ГИСов?
- Все подключаемые приемники корректно примут форматы данных, спроектированные в MDM?
- Не приведет ли изменение какого-то формата указания данных к сбою текущих процессов? (печать этикеток, формирование отгрузочных документов и тд)