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

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

1. MDM система как единый источник НСИ

Ожидание

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

Реальность

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

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

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

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

2. Правила ведения НСИ (видение архитектуры)

Ожидание

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

Реальность

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

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

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

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

3. Стандарты заполнения

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

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

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

Ожидание

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

Реальность

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

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

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

4. Процесс согласования заявок

Ожидание

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

Реальность

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

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

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

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

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

5. Подходы к запуску и подключению новых систем

Ожидание

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

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

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

Реальность

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

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

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

Заключение

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