По сути, в любой организации существует 5 типов данных:
- Неструктурированные. Это данные, найденные в электронных письмах, PDF-документах, белых документах, журнальных статьях, порталах корпоративной интрасети, спецификациях продуктов, маркетинговой информации и т. д.
- Операционный. Это данные, связанные с продажами, поставками, счетами-фактурами, билетами на помощь, претензиями и другими денежными и неденежными взаимодействиями.
- Метаданные. Они представляют собой данные о других данных и могут находиться в формальном репозитории или в других различных формах, таких как XML-документы, определения отчетов, описания столбцов в базе данных, лог-файлы, соединения и файлы конфигурации.
- Иерархические данные. Иерархические данные хранят отношения между другими данными. Они могут храниться как часть системы бухгалтерского учета или отдельно в виде описаний реальных отношений, таких как организационные структуры компании или линейки продуктов. Иерархические данные иногда считаются супер-областью MDM, потому что это важно для понимания, а иногда и для выяснения отношений между основными данными.
- Учителя. Основные данные являются критическими данными бизнеса и обычно попадают в 4 группы: люди, вещи, места и концепции. Другие категории в этих группах называются предметными областями, доменными областями или типами сущностей. Например, в группе людей есть клиенты, сотрудники и продавцы. Внутри вещей есть продукты, детали, магазины и активы. Внутри концепций есть такие вещи, как контракты, гарантии и лицензии, и, наконец, внутри мест есть географические офисы и подразделения. Некоторые из этих доменных областей могут быть разделены. Клиент может продолжать сегментирование на основе стимулов и истории. У компании могут быть нормальные клиенты, но у нее также могут быть привилегированные и премиальные клиенты. Продукт также может быть сегментирован по секторам и отраслям. Такие требования, как жизненный цикл продукта, сильно отличаются от отрасли к отрасли. Детализация доменов по существу определяется величиной различий между атрибутами сущностей внутри них.
Зачем вам нужен MDM?
Поскольку они используются несколькими приложениями, ошибка в основных данных может привести к ошибкам во всех приложениях, которые ее используют. Например, неправильный адрес в Мастере клиентов может означать, что заказы, счета-фактуры и маркетинговая информация отправляются по неправильному адресу. Точно так же неправильная цена на мастер товаров может привести к катастрофе в продажах.
Типичная история ошибки в основных данных, которая приводит к катастрофе, может быть такой: клиент кредитной карты перемещается с одного адреса на другой. Клиент звонит в компанию и немедленно меняет свой платежный адрес. Однако проходят месяцы, и вы не получаете никаких счетов. Однажды клиент получает угрожающий телефонный звонок от отдела выставления счетов по кредитным картам с вопросом, почему он не оплачивает счета. Клиент проверяет, есть ли у них новый адрес, а отдел выставления счетов проверяет, что адрес в их системах правильный. Клиент запрашивает копию счетов-фактур для урегулирования своей учетной записи. Но еще через 2 недели после получения счета клиент снова звонит и обнаруживает, что его учетная запись перешла в отдел претензий на законных основаниях. Кроме того, он узнает, что, несмотря на то, что адрес в системе является правильным, платежный адрес имеет ошибку в одном из своих номеров, и что они, таким образом, отправляют счета-фактуры на неправильный адрес. После множества дополнительных телефонных звонков и писем между адвокатами счет решается, и компания кредитных карт теряет клиента навсегда. В этом случае основная копия данных была точной, но другая ее копия была ошибочной. Основные данные всегда должны быть правильными и последовательными.
Но даже если основные данные не имеют ошибок, немногие организации имеют только один основной набор данных. Многие компании растут за счет слияний и поглощений. Каждая компания, которую вы приобретаете, поставляется со своим собственным мастером клиентов, мастером предметов и так далее. Это было бы неплохо, если бы вы могли объединить новые основные данные с вашими текущими основными данными, но если приобретенная компания не находится в совершенно другом бизнесе, в далекой стране, есть большая вероятность, что некоторые клиенты и продукты появятся в обоих основных наборах данных с разными форматами и разными ключами базы данных. Если обе компании используют один и тот же идентификатор клиента, выяснение того, какие записи клиентов одинаковы, является простым делом, но это редко случается. В большинстве случаев номер клиента назначается программным обеспечением, которое создает основные записи, поэтому вероятность того, что один и тот же клиент или один и тот же продукт имеют один и тот же идентификатор в обеих базах данных, довольно удаленна.
Объединение основных данных может быть очень сложным. Один и тот же клиент может иметь разные имена, номера клиентов, адреса и номера телефонов в разных базах данных. Например, Франсиско Хименес может появиться как Фрэн Хименес, Франсиско Хименес или Фрэн Хименес. Комбинации баз данных и поисков не смогут решить эти различия. Может потребоваться сложный инструмент, который понимает псевдонимы, альтернативные орфографии и ошибки ввода. Этот инструмент, вероятно, также должен будет признать, что различные варианты имени могут быть разрешены, если все они приходят по одному адресу или имеют один и тот же номер телефона. Хотя создание чистого файла основных данных может быть сложной задачей, есть много преимуществ создания общего главного файла:
Один консолидированный счет экономит деньги и повышает удовлетворенность клиентов.
Отправка одной и той же маркетинговой информации клиенту, которая появляется в нескольких базах данных, несколько раз теряет деньги и раздражает клиента.
Прежде чем отправлять учетную запись клиента в компанию по управлению коллекциями, было бы неплохо узнать, должны ли вы больше денег в других частях компании или, что более важно, окажетесь ли вы самым важным клиентом другого подразделения или делегации.
Хранение одного и того же предмета с разными part numbers может не только привести к пустой трате денег и пространства на полках, но и потенциально привести к искусственному дефициту.
Недавние шаги к SOA и SaaS делают MDM критическим вопросом. Например, если вы создаете единую службу поддержки клиентов, которая взаимодействует с помощью четко определенных XML-сообщений, вы можете подумать, что определили уникальное представление для своих клиентов. Но если один и тот же клиент хранится в 5 базах данных с тремя разными адресами и 4 разными телефонными номерами, какие данные извлекает ваша служба поддержки клиентов?. Аналогичным образом, если вы решите подписаться на услугу CRM, предоставляемую через SaaS, поставщику услуг понадобится список клиентов для вашей базы данных. Какой из них вы собираетесь отправить?
Лучшие практики в MDM
Всякий раз, когда рассматривается новая дисциплина, такая как управление основными данными или MDM, естественно, что тот, кто хочет ее внедрить, ищет других людей или компании, которые уже это сделали.
Тем не менее, лучшие практики MDM все еще появляются, и нелегко найти много организаций, которые открыто говорят о своем опыте в MDM.
И весь этот секрет, связанный с успешными программами MDM, не помогает компаниям, которые ищут эти лучшие практики. Итак, давайте попробуем помочь, включая здесь 7 лучших практик, которые вы можете запустить для успеха вашего MDM.
Это включает в себя всю компанию. MDM должен быть обусловлен потребностями бизнеса, иначе он может стать просто еще одной базой данных, которая должна быть синхронизирована с остальными базами данных. Руководители бизнеса, а не только ИТ-персонал, должны продвигать этот процесс. Должна быть поддержка со стороны всех старших руководителей и менеджеров, а также конечных пользователей. Иногда трудно мотивировать организацию превзойти перспективу MDM, но первоначальная поддержка всей компании важна в долгосрочной перспективе. Если ключевые корпоративные цели связаны с проектом через сильный бизнес-кейс, это должна быть простая задача, чтобы продемонстрировать преимущества и вызвать энтузиазм.
Это позволяет достаточно времени для оценки и планирования. Планируйте не менее 3 месяцев оценки. Поговорите с клиентами и подготовьте пилотный проект с реальными образцами данных. Не стоит недооценивать время и знания, необходимые для разработки фундаментальных моделей данных. MDM является более сложным, чем люди думают в начале, поэтому важно начать использовать реальные данные для планирования в ближайшее время. ИТ-сотрудничество также является важной проблемой, поскольку некоторые компании испытывают задержки в проектах в ожидании разрешений и прав доступа к данным.