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

Логотип компании
Чего хотеть от MDM-проекта?
Выделим пять важных граней проекта MDM и в рамках каждой из них соотнесем стандартные ожидания заказчиков с реальными результатами.

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

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

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

Ожидания

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

Реальность

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

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

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

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

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

Ожидания

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

Реальность

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

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

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

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

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

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

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

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

Ожидания

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

Реальность

Этап формирования требований и моделирования, конечно, прошел. Но по первому вопросу от параллельных проектов могут появляться предложения по обогащению реквизитного состава. Здесь как рекомендация – заранее смотреть в сторону глобальных идентификаторов, например тех, которые относятся к различным ГИСам.

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

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

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

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

Ожидания

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

Реальность

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

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

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

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

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

Ожидания

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

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

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

Реальность

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

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

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

Заключение

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

Читайте также
После падения в 2023 году мировой рынок микроэлектроники демонстрирует устойчивый рост, опираясь на государственную поддержку и высокие инвестиции в технологии. В России, в отличие от мирового тренда, драйвером роста становится активное участие государства и национальные программы, направленные на локализацию производства. IT-World изучил, какие факторы и вызовы формируют микроэлектронную индустрию сегодня и как развивается ее потенциал.

Опубликовано 27.12.2023

Похожие статьи