Предпосылки и задачи внедрения MDM на пищевом предприятии

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

Данные можно поделить на две группы: нормативно-справочная информация и транзакционные данные. Сегодня поговорим о первой группе. Разберем предпосылки и задачи внедрения MDM системы, а также варианты ее организации.

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

2. Одинаковые справочники в разных ИТ системах
Если данные заносятся децентрализовано, то в итоге мы запросто получим не консистентные данные.

3. Дублирование справочных данных
Меньшее из зол при введении одних и тех же данных в нескольких местах – это трата времени специалистов. Хуже то, что это неизбежно влечет за собой ошибки. И чем больше данных, тем больше ошибок.

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

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

6. Некорректные отчеты
Вопрос внедрения MDM появляется и становится все актуальнее, когда мы идем в усложнение ИТ ландшафта. Появляется потребность в единой системе, которая обеспечит достоверность справочных данных для дальнейшей обработки

1. Централизованная
Когда данные вносятся в централизованной системе управления НСИ. Вариант достаточно прагматичный, хорошо управляемый. Из минусов: приходится корректировать бизнес-процессы работы бизнеса в системах-подписчиках.

2. Аналитическая
Когда данные вносятся в приложениях. Вариант кажется более простой в реализации, чем предыдущий. Но на выходе там, где у нас отчеты, мы можем получить сильно искаженную картинку (например наличие дублей).

3. Гармонизированная
Когда данные могут заводиться как в приложениях, так и в централизованной системе управления НСИ. Этот вариант вроде бы лучше с точки зрения бизнес-пользователей, потому что пользователь может получить данные сразу в том приложении, в котором пользуется. Но с точки зрения проектируемых решений это сложно и дорого.

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

1. Механизм запуска заявок НСИ
Люди должны иметь возможность запускать заявки на новые элементы НСИ или на их изменение.

2. Настройка интерфейсов работы с заявками
Чтобы людям было удобно, поэтому мы продумываем варианты интерфейсов. При том это могут быть интерфейсы не только с точки зрения программной формы, но возможно даже какие-то Excel.

3. Настройка маршрутов согласования
Сам процесс с точки зрения бизнеса может быть достаточно сложный и ветвистый. За разные составные части реквизитного состава могут отвечать разные люди из группы экспертов (иногда в рамках предприятия/холдинга сложно чтобы 1 человек понимал все особенности в ИТ ландшафте). Для упрощения согласований нужен свой инструмент.

4. Механизм оповещений
Этот инструмент особенно важен для людей, которые ждут, что появится какой-то элемент НСИ, или для тех, кто отвечает за обогащение данных в системе. В MDM не всегда переносят 100% реквизитного состава. Часто туда забирают только какую-то золотую середину, а остальное необходимо потом обогащать в системах-подписчиках (информация, которая ведется локально и не требует централизации).

5. Механизм нормализации
Это как раз то, что ведет к повышению качества данных. Например, к исключению дублей, к обеспечению полноты данных.

6. Аудит данных
Мы должны понимать не только куда и как данные раздаются, а главное, кто, когда и почему захотел эти данные поменять. Важно при необходимости иметь возможность вернуться и разобраться.

7. Контроль доступа
Не все сотрудники должны иметь права на чтение/изменение данных. Особенно это важно, когда дело касается ФЗ 152 (закон о персональных данных).

Как выглядит последовательность шагов в проекте и какие грабли вас ждут на пути внедрения МДМ, и как их можно обойти, читайте в следующих выпусках.

Если вы узнали себя в предпосылках или задачах, которые я описал в статье, знайте, что мы можем помочь с их решением. Ну или хотя бы проконсультировать (за спрос денег не берем).
Оставляйте заявку в форме обратной связи ниже, и мы свяжемся с вами для проведения консультации.