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

Почему объединение данных не соответствует потребностям пользователей

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

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

• Еще одно хранилище данных. В отстутствии правильного планирования функционирования объединенной системы и использования данных мастер-хранилища, IT-отдел создает, по сути, еще одно хранилище данных, требующее наблюдения за собой, синхронизации и обслуживания. Без планирования использования в реальных бизнес процессах, затраты на плановое обслуживание будут рассматриваться как бесполезная трата ресурсов и бизнес подразделения, оплачивающие проект, прекратят финансирование.
• Отсутствие ввода данных пользователями. Консолидация рассматривается как техническая задача и, обычно, не принимается во внимание требования к данным со стороны пользователей и бизнес-подразделений. В результате, потенциальные пользователи неправильно обслуживаются хранилищем и будут избегать траты собственных ресурсов на адаптацию приложений.
• Отсутствие плана миграции. Основные ресурсы, выделенные на MDM, расходуются большей частью на строительство хранилища, часто мало что оставляя на работы по адаптации бизнес процессов, приложений и функций к новым условиям. Постфактум осознается, что требуются дополнительные ресурсы на анализ существующих приложений, определение точек соприкосновения объектов мастер-данных, ре-дизайн, разработку, внедрение изменений в существующие приложения. Но в этот момент может быть уже слишком поздно обращаться за дополнительным финансированием, что бы начать работу хранилища.
• Потеря данных. Алгоритмы, применяемые для связи, слияния, живучести данных при объединении множественных записей в единую “ золотую запись”,по своей природе, приводят к потере даных. Под живучестью понимается, что некоторые данные включаются в новую систему, в то время как остальные отбрасываются, обычно следуя правилам, определенным IT-персоналом. В ряде случаев применение такого сценария и потеря данных, ведут к негативным последствиям, которые влияют на качество бизнес процессов.
• Потеря значимости. Как предполагалось в предыдущем пункте, целевые критерии слияния и объединения задаются IT-персоналом, который определяет правила, игнорирующие семантическую значимость данных, заданных в контексте бизнес-процессов. Извечный вопрос определения понятия “клиент” показывает вариативность значений, связаных с общеупотребительными бизнес-терминами. Но когда несколько записей, определяющих понятие, объединяются в одну, то изменения контекста приводят к потере значений, заданных в оригинальных контекстах. Это определяет смысловой конфликт исходных и целевых данных.
• Несогласованность с процессами обработки данных на предприятии. MDM является таким же процессом управления уровня предприятия, что и   управление качеством данных (data quality management) и управление данными (data governance). Все эти организационные процессы управления данными должны быть скоординированы для создания синергетического эффекта. Часто, однако, MDM мероприятия изолированы внутри подразделений или групп, что приводит к невозможности получать выгоду от решения задач на базе существующих программ управления данными.
• Отсутствие руководства процессами. Отсутствие встроенных правил руководства бизнес-процессами приводит к несоответствиям, возникающим в подсистемах данных приложений, которые не попадают в мастер-хранилище. Например, бизнес-процесс, требующий поиск записи о клиенте, должен быть настроен таким образом, чтобы персонал, вводящий данные, смог найти правильную запись, не смотря на возможные ошибки, вместо того, чтобы создать новую (пусть и непреднамеренно) дублирующую запись о том же клиенте.
• Данные извне предприятия. Очень часто организации пользуются данными, которые формируются вне предприятия, управляются третьей стороной или собственным окружением. Этот тренд сохранится и в будущем, так как все большее распространение будут получать облачные приложения. Сложно, если вообще возможно, требовать пользоваться только данными, взятыми из мастер-хранилища, когда потребляющие данные приложения находятся вне зоны корпоративного административного контроля.
• Теневые IT. Такой инструментарий настольных компьютеров, как электронные таблицы, персональные базы данных, часто используются, игнорируя заданные политики в области данных и мастер-хранилище. Так как эти артифакты персональных данных часто попадают в производственные информационные потоки, то данная информация должна характеризоваться как данные, которые, возможно, не будут связаны с мастер-хранилищем и ассоциированными сервисами.
• Результатом реализации плана создания системы MDM, ориентированного на консолидацию данных, будет мастер-хранилище, на создание которого впустую были затрачены большинство средств и сил. Потраченные ресурсы, необходимые для переоснащения существующих производственных систем, выльются в те же бизнес-приложения, предоставляющие прежний функционал, с дополнительной выгодой от улучшения качества данных. Интеграция мастер-хранилища в обновленные или вновь купленные приложения предполагает потенциальные выгоды для координации работы предприятия, но они будут получены только после полного развертывания новых приложений.
• Решения о финансировании часто принимаются на основе восприятия ценности программы. И когда возникают подозрения в задержке возврата от инвестиций, работы часто замедляются или откладываются. Поэтому многие предприятия делают несколько подходов к созданию системы MDM, пока окончательно не разработают единый общий набор данных, приносящий прибыль компании.

По материалам: sas.com Изображение: Tim Morgan / Foter / CC BY