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

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

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

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

Вопросы для самодиагностики:

1. Какие системы мы готовы взять в ближайший периметр MDM проекта?
2. Какие данные мы видим централизуемыми в рамках IT ландшафта?
3. Какие у нас будут критерии к составу данных в рамках одного домена?
4. По каким правилам мы будем осуществлять нарезку внутри каждого справочника? (если он будет состоять из разных сегментов, которые надо по выделенным правилам маршрутизировать в рамках ландшафта)
5. Каким образом сформулируем критерий достаточной чистоты данных в текущий момент, чтобы зафиксировать текущий результат?

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

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

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

Вопросы для самодиагностики:

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

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

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

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

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

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

Вопросы для самодиагностики:

1. Требования каких систем и процессов в вашем IT ландшафте вошли в основу требований к централизуемому реквизитному составу?
2. Не забыли ли посмотреть на данные через призму требований ГИСов?
3. Все подключаемые приемники корректно примут форматы данных, спроектированные в MDM?
4. Не приведет ли изменение какого-то формата указания данных к сбою текущих процессов? (печать этикеток, формирование отгрузочных документов и тд)

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

Реальность
В реальности самый классный и живой вариант, когда:

1. есть владелец данных (кто со стороны бизнеса готов предъявлять требования и потреблять результаты)
2. есть эксперт/команда экспертов, которые принимают решение о валидности заявки на НСИ
3. у экспертов есть автоматизированные помощники для дозаполнения данных ((например, сервис 1С:Контрагент), инструменты контроля дублей по параметрам заявки)
4. есть прозрачный маршрут согласования заявки

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

Вопросы для самодиагностики:

1. Есть ли понимание, что хорошая НСИ – это регулярный труд команды?
2. Предъявляемые требования к скорости обработки заявок на НСИ
3. Может ли 1 человек целиком отвечать за 1 справочник? За все справочники?
4. Какие рутинные операции рентабельно заменять автоматизированными помощниками проверок/заполнения на вашем масштабе?

Ожидание
Этот замечательный вопрос концептуально имеет 2 решения:

1. запуск 1 большим взрывом
2. постепенное подключение

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

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

Вопросы для самодиагностики:

1. Какой расчетный объем централизованных данных вы получите по каждому виду данных?
2. Вы настолько хорошо все отрепетировали, что запуск взрывом в вашей ситуации не повлечет экономических и репутационных последствий?
3. Выдержит ли команда разбор ошибок, чтобы обеспечить исполнимость критических процессов (например отгрузки) после запуска?

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