sap mdm что это такое
SAP Master Data Management (SAP MDM)
Содержание
Компонент «Управление основными данными» (SAP Master Data Management, SAP MDM) позволяет обеспечить единство и целостность основных данных в рамках всего информационного ландшафта компании. Взаимодействуя с существующими информационными системами, распределенными по многочисленным структурным подразделениям, компонент «Управление основными данными» использует уже сделанные инвестиции в важные для бизнеса данные, одновременно, значительно сокращая затраты на ведение этих данных. Кроме этого, согласованность данных во всех системах компании позволяет ускорить выполнение бизнес-процессов.
Применительно реализации стратегических целей компании
Компонент «Управление основными данными» является основой для формирования целостной и согласованной информационной среды предприятия. Он предоставляет средства, обеспечивающие консолидацию данных, отслеживание изменений в них и распределение одних и тех же актуальных основных данных по всем разнородным корпоративным приложениям. Этот компонент позволяет оптимизировать процесс принятия решений, преобразовать скрытые издержки в прибыль и значительно снизить затраты на сопровождение ИТ-структуры компании.
Компонент «Управление основными данными» помогает:
Возможности и функции
Компонент «Управление основными данными» помогает интегрировать бизнес-процессы на протяжении всей расширенной цепочки создания добавленной стоимости. В число возможностей и функций этого компонента входит следующее:
Преимущества
Компонент «Управление основными данными» представляет собой инструмент, который помогает рентабельно управлять коллаборативным и гибким бизнесом, в основе которого лежат тесные взаимосвязи с деловыми партнерами. Использование компонента «Управление основными данными» предлагает следующие преимущества:
Что такое Мастер-Данные и зачем они нужны
Введение
(клик по картинке ведёт внутрь публикации)
Развиваясь, организации внедряют всё больше и больше информационных систем совершенно различных направлений: бухгалтерский учет, управление персоналом, управление складом etc. Системы живут и развиваются независимо друг от друга до того самого момента, как компании не потребуется взглянуть на свои данные целиком. Объемы данных уже достигают критической точки и выясняется, что сопоставить и сравнить данные вручную становится просто невозможно. Решения основанные на противоречивых и невыверенных данных ведут к управленческим ошибкам, а дубли и неактуальность данных к неверным бизнес решениям.
Конечно же проблема описанная выше не нова и сегодня мы обсудим классический способ решения — систему управления мастер-данными.
Что такое MDM
Master Data Management (сокращенно: MDM, МДМ, НСИ; варианты перевода: управление мастер-данными, нормативно-справочная информация) система — комплекс процессов, систем управления, стандартов и программ позволяющих единообразно работать с данными. Проще говоря, МДМ-система предоставляет целостный взгляд на все составляющие бизнеса, в том числе на источники данных, авторство, качество, полноту и на потенциальное использование данных. (Подробнее: Задачи управления мастер-данными)
(кликабельно)
Типы корпоративных данных: что такое справочные и транзакционные данные
Чтобы разобраться, чем являются и не являются мастер-данные разберем основные типы корпоративных данных.
(взято отсюда)
Неструктурированные данные — текст, почта, и другие данные, у которых нет формально определенной и описанной структуры.
Полуструктурированные — данные не имеющие определенной схемы (или имеющие переменную структуру), но тем не менее имеющие формальное описание в виде тегов и\или определенных маркеров. XML — пример, полуструктурированных данных.
Структурированные (транзакционные) данные — данные имеющие формально определенную схему.
Метаданные — это данные описывающие другие данные, например, схема базы данных клиентов, конфигурационный файл или шаблон отчета.
Мастер-данные — это данные, содержащие ключевую информацию о бизнесе, в том числе о клиентах, о продуктах, о работниках, о технологиях и материалах. Каждая из этих групп может разделяться на несколько предметных областей: в категорию люди входят клиент, продавец, поставщик. Так же может иметь набор правил валидации, которым должны удовлетворять данные.
Иногда в отдельную категорию выделяют иерархические данные — это данные, в которых хранятся отношения и взаимодействия между данными. Подробнее.
Пример, общей структуры мастер-данных и валидационных правил (кликабельно)
Зачем оно нужно?
Исторически многие системы хранения, анализа и визуализации данных развивались параллельно и не совместимы между собой. По мере роста компании интеграция данных становится всё более важной и во многих случаях критической задачей, согласно Microsoft уже компании среднего размера ощущают на себе последствия работы с разнородными данными.
Таким образом одной из задач МДМ-систем является синхронизация данных, что упрощает решение сопутствующих задач, как подготовка финансовой отчетности.
МДМ-система — это один из краеугольных камней в архитектуре бизнеса вместе с ERP и BI системами, позволяющий системам аналитики и ведения бизнеса иметь единое преставление о данных, независимо от источника и формы.
Рассмотрим несколько классических случаев, где необходимо использовать и внедрять систему управления мастер-данными.
Зоопарк ИТ-систем и консолидированная отчетность
Пусть в компании больше трех систем хранения-анализа данных. Заполняются они и развиваются независимо друг от друга. В какой-то момент появляется необходимость собрать консолидированную отчетность и необходимо синхронизировать нормативно-справочную информацию. Например, существуют компания Ромашка с оборотом в 1М и имеются две записи «Общ.огр. Ромашка» и «ООО Ромашка» в разных системах с оборотом 400к и 600к, без инструментов синхронизации, система создания отчетности не сумеет объединить записи.
Интеграция систем
Пусть имеется несколько 1С систем в отделениях компании и счета, выставленные ООО «Ромашка» необходимо выгрузить и проанализировать в CRM. Если в CRM заведены несколько дублей, например Ромашка и Общ. Огр. Ромашка, то встает вопрос к какой Ромашке в CRM эти счета привязать и есть ли среди этих Ромашек нужная?
Единая база контрагентов
Прежде всего создание единой базы необходимо, для качественной и достоверной информацию о контрагентах. Если клиент, уже подписавший контракт, получает дополнительные N звонков о необходимости выслать уже отправленные документы (т.к. «Общ.огр. Ромашка» и «ООО Ромашка» — синтаксически разные компании), то это негативно отражается на отношениях компании.
Очистка и нормализации данных
Описанные выше случаи — это задачи по очистке и нормализации данных (data cleaning and data quality).
Очистка и нормализация данных — это безусловно инструменты, цель — это повышение лояльности клиента (e.g. избегаем повторных звонков), создание отчетности (уверенность в корректности аналитики) и увеличение скорости выполнения задач (быстрее проходим цикл продаж).
Как правило, клиент приходит к необходимости внедрения системы управления НСИ. Например необходимость оперативного контроля над деятельностью предприятия может потребовать сбора консолидированной отчетности, что в свою очередь приведет к необходимости синхронизации НСИ в ИТ-система, что в свою очередь потребует внедрения системы управления НСИ.
Случаи из жизни
Четырнадцать 1С-ок
У одной компании N было четырнадцать 1С систем в филиалах и вот однажды им пришлось срочно предоставить отчетность о своей деятельности в какую-то там палату. Отсутствие единой отчетности грозило существенными проблемами и вот M сотрудников несколько недель вместе сводили и выверяли данные. А могли бы просто физически не успеть.
Клиент из Астрахани отправил фуры заказчику в другой регион, а обеспечение в пути оказывала компания Х, у которой не было МДМ-системы и единой базы контрагентов. Во время путешествия фуры проходили обслуживание в двух регионах — и по окончанию поездки компания Х выставила счет клиенту по этим регионам по стандартному прейскуранту без положенной скидки за объем, так как клиент был записан в этих двух регионах под чуть-чуть по-разному и система не сопоставила имена. Итог — дополнительные разбирательства и ухудшение деловых отношений.
Повторные звонки
Однажды клиенту позвонили шесть (!) раз после того, как контракт был подписан. Из-за подобной некомпетентности лояльность клиента и контракт были под угрозой.
Методы решения
Рассмотрим два наиболее популярных метода решения проблем, описанных выше.
Административное решение
Административный подход — сначала вычистить уже имеющиеся дубли в ИТ-системах, разработать систему кодировок, по которым можно сопоставить записи в справочниках разных ИТ-систем, и регламенты. Такой метод относительно прост, но имеет ряд недостатков – он не предотвратит рассинхронизацию НСИ в разных системах, а регламенты всегда можно обойти.
Внедрение MDM-системы
Технологический подход — использование системы обеспечивающей синхронизацию и единое представление данных. Как правило большинство крупных компаний внедряют различные версии MDM, когда ручная консолидация справочной информации и отчетности становится невозможной, а внедрение любой новой системы вынуждает изменять регламент и кодировки, только усиливая хаос.
Безусловно, единовременное введение МДМ-системы не решит все проблемы и по мере развития бизнеса, должна развиваться и МДМ-система, может даже измениться и сам тип МДМ системы (основные типы освещены ниже), однако, как показывает практика MDM является оптимальным бизнес решением в подобных случаях.
Типы МДМ-систем
Мы рассмотрим три основных типа MDM-систем — подробнее можно прочитать тут.
Централизованная система
Выбирается одна IT система, это может быть как уже имеющаяся IT-система, так и отдельная система управления НСИ. Справочные данные в этой системе будут считаться эталонными, вестись в ней и рассылаться в другие системы. При этом создание и редактирование справочных данных в других IT системах запрещается. Преимуществами такого подхода являются:
Аналитическая система
В аналитической системе НСИ все элементы НСИ создаются в клиентских системах, откуда отправляются в систему НСИ, где из этих элементов формируется запись справочника НСИ. Это позволяет быстро внедрять систему, внося минимальные изменения в клиентские системы.
Но так как НСИ в отдельно взятой IT-системе ни с чем не синхронизируется, то в самой IT-системе могут быть дубли и отчетность может расплыться, поэтому построение оперативной отчетности затруднено (про локальную отчетность также говорят, что она «грязная» — локальные записи НСИ могут не соответствовать записям в системе НСИ).
Гармонизированная система
Эта система вобрала в себя лучшее из централизованной и аналитической систем. Она позволяет заводить данные в IT-системах, и затем сопоставлять с уже заведенными, умеет искать потенциальные дубли, разрешать конфликты, связанные с одновременным изменением одних и тех же данных в разных IT-системах, синхронизировать НСИ в IT-системах. Таким образом не меняются и не нарушаются бизнес-процессы, минимизируются ручная работа по подготовке отчетности — то есть просто строиться локальная отчетность. Однако данные подход является наиболее дорогим, трудоёмким и требуют серьезной экспертизы для построения, а так же может потребовать модификации клиентских приложений.
Примеры реализации MDM-систем
Примером аналитической системы управления НСИ является Navicon SalesOut, а примером централизованной и гармонизированной – разные конфигурации Navicon MDM.
Индикаторы необходимости внедрения МДМ-систем
Ключевые: необходима интеграция различных систем и единая отчетность на основе этих данных.
Частные предпосылки внедрения на примере с одним из клиентов
Мастер-данные и управление ими. Что это такое и кому оно необходимо?
Постоянно сталкиваемся с тем, что в области MDM (Master Data Management) катастрофически отсутствуют понятные вводные материалы, позволяющие быстро разобраться что это, зачем и почему это важно. Попробуем это в меру сил исправить и объяснить языком бизнеса.
В этой области пока серьезный дефицит определенности, и даже Википедия, как ни странно, не вполне уверена что есть что. Поэтому будем объяснять своими словами и «на пальцах», с примерами.
Что есть что
Итак, все данные, которыми оперируют современные информационные системы, можно разделить на нормативно-справочную информацию, мастер-данные и транзакционные данные.
Нормативно-справочная информация (НСИ) или справочники и классификаторы — позволяют нам структурировать окружающий нас мир с целью его анализа. Как правило, справочники и классификаторы строятся в виде списков и деревьев. Например, мы распределяем все товары по товарным группам для того, чтобы ими было легче управлять. В мировой практике эту часть классифицируют как Reference Data, с соответствующим классом приложений и процессов – Reference Data Management.
Мастер-данные как правило отражают объекты реального мира, и их основные свойства, например: клиентов, товары, людей, офисы, транспортные средства. Их ключевое отличие от НСИ в том, что НСИ – это атрибуты, свойства, списки, и прочие плоскости классификации, но объекты, описываемые НСИ как правило не существуют в реальной жизни. Так, модель автомобиля – это элемент НСИ, а вот конкретный автомобиль с его свойствами – элемент мастер-данных.
Транзакционные данные – отражают наши действия с объектами мира (читай – объектами мастер-данных), события и взаимодействия. Мы в момент T отгрузили клиенту А товар Б в количестве Х и по цене Y. А потом в момент T1 получили с клиента А платеж на сумму Z, вот эти запись и будут транзакционными данными.
Если посмотреть на эти три группы, то мы увидим некоторую иерархию, отраженную на рисунке. НСИ используется для структурирования мастер-данных и транзакционных данных. Мастер-данные определяют структуру транзакционных данных. И только транзакционные данные являются конечным результатом цепочки.
Таким образом, НСИ структурируют как мастер-данные, так и непосредственно транзакционные данные. Мастер-данные структурируют транзакционные данные. В результате наши аналитические возможности в отношении транзакционных данных прямо зависят от того, на сколько пригодный для наших целей «каркас» из НСИ и мастер-данных нам удалось построить.
Естественно, что каждый из видов данных обладает своими особенностями, которые мы обязаны рассмотреть подробно.
Особенности НСИ
Ключевой особенностью НСИ является их относительная неизменность, т.е. НСИ выстраиваются изначально исходя из бизнес-целей либо из устойчивой объективной реальности мира (например, справочник организационных форм или моделей авто). Изменения в НСИ обычно происходят в соответствии с определенной процедурой, ведение НСИ возлагается на конкретное подразделение. Всякое изменение должно обязательно пройти по определенному процессу согласования, гарантирующему целостность НСИ.
Источниками изменений в НСИ являются изменения в окружающей действительности, например, иногда появляются новые страны или валюты. Либо, если речь идет о справочниках, построенных вокруг бизнес-целей, — изменения, связанные с изменениями в бизнес-целях, учетной политике, распределении ответственности по товарным группам и т.д..
Фактически, НСИ формируют базовые плоскости аналитики, в силу чего состав и структура НСИ может быть достаточно сложной, в том числе одни справочники могут использоваться в других в качестве атрибутов, формируя сложные структуры, реализующие множество аналитических плоскостей. Например, для целей маркетинга, производства, управления запасами и финансового учета могут применяться совершенно разные группировки товарных позиций и разные наборы признаков.
При достаточной централизации управления НСИ система справочников обычно стабильна и не подвержена «зашумлению». Однако, в компаниях с недостаточно интегрированными приложениями мы наблюдаем одну и ту же беду: НСИ нередко строятся отдельно в рамках каждого приложения исходя из «локальных» бизнес-целей, обеспечиваемых этим приложением. В итоге порождаются «параллельные» наборы НСИ, не сведенные в единую систему, что сильно осложняет формирование аналитических массивов.
В идеале, управление НСИ должно быть централизовано. Таким образом в составе ИТ-решения появляется система RDM (Reference Data Management), обеспечивающая техническую и организационную основу для правления НСИ, по отношению к которой все остальные приложения являются клиентами односторонней синхронизации НСИ – из RDM в приложения.
Особенности мастер-данных
Мастер-данные более «подвижны»: новые клиенты, новые товары, новые люди – все это движение прямо происходит из жизни компании.
Важнейшей особенностью мастер-данных является то, что именно здесь компания накапливает знания о предмете своей работы. Вся информация, появляющаяся по ходу времени о конкретном клиенте должна хозяйственно складываться, структурироваться и обновляться, включая всю историю изменений. То же самое касается любых мастер-данных. Не менее важно то, что мастер-данные определяют так же отношения между разными сущностями. Что является филиалом чего, кто является поставщиком каких товарные групп, какие транспортные средства принадлежат каким филиалам и т.д.
Однако степень контроля за изменениями мастер-данных существенно ниже, ибо записи и их обновления порождаются в самых разных подразделениях, в разное время, вносится разными людьми, а зачастую еще и в разных системах, составляющих сложный ИТ-ландшафт современной компании. В результате нередко в каждой системе хранится лишь какая-то часть информации об одной и той же сущности, в каждой системе ей присваивается собственный идентификатор. В итоге формирование комплексной аналитической картины осложняется, а в особо запущенных случаях становится и вовсе невозможным.
В силу этого мастер-данные сильно подвержены «зашумлению» в результате ошибок и создания дублирующих записей. Как правило с этим борются организационными мерами, правилами типа «не заводить товарную позицию если она уже есть» или «перед тем как завести клиента – провести поиск по текущей клиентской базе». Но когда разбросанность по прикладным системам накладывается на многообразие написаний и описаний, а это все на пределы человеческого внимания и старательности – то никакие оргмеры не помогают.
Результатом «зашумления» является потеря качества мастер-данных, которая влечет за собой разрушение аналитики, ибо какая может быть аналитика если транзакции относительно одного реального клиента привязаны к трем разным клиентским записям, сделанным в разное время в разных системах разными людьми?
Крупные компании с большой историей и сложной ИТ-инфраструктурой запросто могут иметь в своих системах 15..20 млн клиентских записей о юрлицах в то время как всего юрлиц в России менее 5 млн. И это вполне жизненный случай. Про качественную клиентскую аналитику говорить здесь уже не приходится.
Другой пример. Очень подвержены «зашумлению» товарные каталоги. В силу отсутствия единого уникального идентификатора и разнообразия написаний нередко оператор не в состоянии соотнести новые товары с уже учтенными в системе. В результате позиция, пылящаяся на складе будет еще раз закуплена только потому, что складским остаткам соответствует одна карточка товара, а в проектных спецификациях – другая, хотя физически – это один и тот же товар.
Особо следует отметить, что большинство прикладных систем не содержит в себе сколько ни будь эффективных механизмов управления качеством этих данных, ограничиваясь тривиальным поиском по подстроке, уповая на добросовестность оператора и его знание прикладной области. Поэтому проблема качества мастер-данных обычно встает тогда, когда вносимые искажения и неадекватность аналитики достигают впечатляющих размеров и видны, что называется, невооруженным глазом.
Особенности транзакционных данных
Транзакционные данные являются самыми динамичными из всех перечисленных типов и по сути порождаются прозрачно для большинства операторов в ходе понятных действий типа «отгрузить товар», «загрузить выписку из банка». Как правило каждый элемент транзакционных данных содержит некоторое количество ссылок на записи мастер-данных разных видов плюс дату и ряд чисел, характеризующих транзакцию.
Например, минимальный элемент транзакционных данных, порождаемых отгрузкой будет состоять из ссылки на клиента, ссылки на товарную позицию, количества и цены. В реальности транзакционные данные имеют чуть более сложную структуру, так, например, есть накладная и соответствующий элемент данных с указанием контрагента и даты, а есть ее строки, каждая из которых содержит товарную позицию, количество и цену. И тем не менее для целей анализа число транзакционных записей будет равно числу строк в накладной, а сама запись, соответствующая накладной, — не перестает быть транзакционными данными.
Следует отметить, что всевозможные учетные регистры, содержащие, например, текущие остатки – по сути являются не транзакционными данными, а разновидностью аналитического обобщения. Просто это обобщение техническими средствами поддерживается постоянно актуальным и имеет целью оптимизацию производительности. Важно то, что оно в любой момент может быть пересчитано из транзакционных данных и в этом его принципиальное отличие – оно вторично.
Важно то, что транзакционные данные как правило затрагивают интересы внешних контрагентов, и в силу этого нет особых проблем с контролем их качества: например, если оператор задвоил отгрузку – то это скажется на балансе с контрагентом, приведет к разночтениям, сверке и ошибка будет скорректирована. Таким образом, взаимный контроль между взаимодействующими контрагентами вкупе с аналитическими инструментами и сложившейся бизнес-практикой обеспечивают сравнительно высокое качество транзакционных данных
Почему мастер-данные требуют особого подхода?
Определившись с понятиями и рассмотрев особенности типов данных, мы вплотную подошли к вопросу: почему же управление мастер-данными выделяется в отдельную функцию в современных ИТ-архитектурах? К тому есть несколько причин:
Таким образом и появляется в ИТ-ландшафте отдельный элемент – система управления мастер-данными (MDM, Master Data Management) как отдельная функция, ИТ-сервис, который «дирижирует» всей совокупностью мастер-данных компании, обеспечивая все функциональные приложения едиными, целостными, актуальными и полными мастер-данными. В большинстве случаев взаимодействие между прикладными системами и MDM происходит через шину данных, сообщения или SOAP/REST API.
Парадокс в том, что любая компания, пытающаяся построить высокоуровневую аналитику автоматически приходит к неявному формированию мастер-данных даже в том случае, если она использует ETL-процедуры для «перегрузки» данных из нескольких учетных систем в одну аналитическую, ибо качественная аналитика принципиально невозможна без качественных мастер-данных. Вопрос лишь в том, насколько развитые алгоритмы сопоставления используют ETL-процесс, какого качества мастер-данный получаются в целевой аналитической системе.
Таким образом, обусловленная спецификой мастер-данных невозможность действительно качественно решить задачу управления ими в рамках отдельной прикладной системы умноженная на большое количество прикладных систем порождает отдельный домен ИТ – управление мастер-данными.
Что такое MDM и какие они бывают?
Итак, управление мастер-данными или MDM выкристаллизовывается как отдельная область знаний и класс продуктов. Однако, в сложившейся в англоязычной терминологии это общий класс продуктов и решений, в который включается, в частности, ряд прикладных решений и связанных с ними бизнес-процессов:
Нет сомнений, что при известной любви англоязычного мира к структурированию действительности, специализации и акронимам можно раскопать еще добрый десяток узких прикладных систем, которые по сути реализуют функционал управления мастер-данными в одной конкретной узкой области.
Формирующийся рынок MDM решений сегодня представлен большим количеством компаний, предлагающих решения очень разного качества. Все вендоры «первого эшелона» обозначили наличие в своем портфеле MDM решений или отдельно, или в составе своих систем. Однако, как и было сказано, большинство из них сосредоточено на другом функционале, поэтому качество реализации специфичного MDM функционала оставляет желать лучшего. В то же самое время множество небольших, но более сфокусированных на проблематике MDM компаний предлагает решения существенно более функциональные.
Нужен ли мне МДМ?
Итак, в каком случае Вам определенно стоит задуматься над внедрением MDM в свою ИТ-архитектуру? В первом приближении критерии следующие:
Последнее, что хотелось бы отметить в этом разделе – это то, что нет лучшего момента для внедрения МДМ, чем момент внедрения новых функциональных ИТ-систем или миграции с одних систем на другие. Ведь процесс внедрения подразумевает «очистку» накопленных данных и увязку систем между собой. Совмещая эти вещи мы одним выстрелом убиваем двух зайцев: повышаем качество данных в новой системе и одновременно сохраняем преемственность со старой, ведь MDM-система как раз и сшивает их между собой.
Куда катится MDM?
Чего следует ждать от этого направления? Каков вектор развития? Полагаем, что актуальными будут следующие тренды:
Заключение
Мы надеемся, что данный материал дал представление о том, что такое мастер-данные, что такое системы управления ими и зачем они нужны.
Определенно, для достаточно крупных организаций со сложным ИТ-ландшафтом MDM является совершенно необходимым элементом, позволяющим «склеить» воедино и сделать максимально полезными огромные, но сильно фрагментированные данные, упростить архитектуру, радикально снизить трудоемкость формирования бизнес-аналитики и одновременно существенно улучшить ее качество.