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