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