Задачи управления мастер-данными

Отсутствие должной координации между различными подразделениями ограничивает способность предприятий анализировать, отслеживать и управлять информацией о поставщиках, потребителях, сырье, используемых материалах и т.д. Этот недостаток призвана компенсировать новая ИТ-дисциплина — Master Data Management

Среди множества разнообразных корпоративных данных есть их специфическая категория, на которую приходится в среднем 15% от всего объема данных. Содержащаяся в них информация служит основанием для принятия бизнес-решений, поэтому их называют «основными», или «мастер-данными». Встречающийся перевод этого термина как «нормативно-справочная информация» нельзя признать точным, он ограничивает представление о мастер-данных. Это понятие намного шире, среди аналитиков бытует выражение: «Мастер-данные — это язык бизнеса». Однако до последнего времени сами мастер-данные и соответственно дисциплина управления мастер-данными (Master Data Management, MDM) оставались на периферии внимания руководителей ИТ-служб. Сейчас положение меняется, новые тенденции в системной архитектуре — к ним следует отнести прежде всего массированное наступление сервисо-ориентированных архитектур (Service-Oriented Architecture, SOA) — и усиление требований к прозрачности бизнеса и обеспечению отчетности актуализировали проблему управления основными данными и вывели MDM в одно из наиболее актуальных направлений развития ИТ.

О сложности данных

При взгляде на современные корпоративные информационные системы невольно на ум приходит высказывание песика Фафика, персонажа популярной в свое время рубрики в польском журнале «Пшекруй»: «Люди думают, что мы любим кости, а мы любим мясо!» Мудрый Фафик вспомнился в связи с тем, что плотью информационных систем являются данные, а вся эта аппаратно-программная инфраструктура — всего лишь поддерживающий ее скелет.

Очевидно, что пользователям требуются информация и сведения, содержащиеся в данных, а не серверы, системы хранения или приложения, но вместо этого ИТ-индустрия по традиции обычно навязывает нам эти самые «кости». Данные же обычно представляются чем-то совершенно очевидным, не заслуживающим особого рассмотрения, как нечто изначально понятное.

До тех пор пока данные оставались достаточно простыми и статичными, с таким их подчиненным положением по отношению к инфраструктуре можно было мириться. Удивительно, но в силу инерции мышления даже несколько лет назад, когда уже вовсю заговорили о взрывообразном росте объемов сохраняемых данных, когда системы хранения заняли центральное место, а серверы сместились на периферию внимания ИТ-специалистов, все равно почти никто не говорил о данных с содержательной точки зрения. Напротив, доминировали маркетинговые заклинания, гипнотизировавшие слушателей объемами данных и новыми единицами их измерения. В лучшем случае речь заходила об управлении жизненным циклом информации (Information Lifecycle Management, ILM); это, бесспорно, чрезвычайно важная совокупность технологий и процедур, которую, впрочем, никак нельзя признать управлением информацией, поскольку она служит исключительно целям оптимизации систем хранения, не более того.

Итогом более чем трех десятилетий отмеченного пренебрежительного отношения к данным стала сумбурность в организации информационной среды, появление не связанных между собой подсистем хранения, наличие раздельных репозитариев данных, содержащих ключевые сведения о потребителях, продуктах, поставщиках, партнерах, сотрудниках и т.д. В качестве метафоры для сложившейся ситуации часто используют образ стоящих порознь силосных башен (silo) — в данном случае «башен», хранящих данные. Это положение сохраняется и поныне, хотя проникновение Internet-технологий во все аспекты деятельности предприятий проявило с очевидностью то обстоятельство, что отдельные подсистемы и независимые массивы данных уже не могут существовать в изоляции. Повышение требований к динамике бизнеса еще более обостряет проблемы, вызываемые разрозненностью данных. Чтобы точнее соответствовать изменениям во внешней среде, предприятие должно лучше знать само себя, то есть иметь точное представление о происхождении и размещении основных данных, о том, в каком виде они существуют и насколько им можно доверять.

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

На фоне общей проблемы работы со сложными данными есть и более частная — проблема мастер-данных. Необходимость ее разрешения вызвана тем, что, как показывают исследования аналитиков из компании Aberdeen Group, руководители более чем 80% обследованных предприятий относят ее к числу наиболее приоритетных. Они хотели бы, чтобы мастер-данные не были разбросаны по множеству разных мест, а хранились бы централизованно.

Что такое Master Data Management

Предназначение MDM состоит в обеспечении целостного взгляда на основные компоненты бизнеса. Любой компании, как единому организму, требуется быть информированной о самой себе, ей необходимо знать свои источники информации, где и как информация размещена, кем, когда и как она потребляется, насколько ей можно доверять. К сожалению, каких-либо практических методов искусственного интеллекта или приемов работы с информацией, аналогичных переработке информации в человеческом мозге, не существует; не предвидится и их появление в обозримом будущем. Поэтому ИТ-специалистам на самом деле приходится иметь дело не с информацией, а с данными, представляющими или содержащими информацию. Почти повсеместно два понятия — «информация» и «данные» — отождествляют. Даже в Wikipedia (в ее англоязычной версии) можно найти такой пассаж: «Данные — синоним информации». Это суждение, по существу, глубоко ошибочно, данные всего лишь носитель информации, форма ее представления^*.

В реальной жизни требуются не общие рассуждения об информации, а решения, основанные на интуитивно понятных принципах, и MDM относится к их числу. Предприятия пришли к практической необходимости создавать средства для поддержки MDM в связи с принятием акта Сарбейнса—Оксли и ему подобных нормативных актов. Поэтому, как бы ни были совершенны теория и практика MDM, следует понимать, что это всего лишь инженерные решения, оперирующие данными, они достаточно грубо заменяют собой работу с информацией, но пока ничего другого придумать нельзя. Концепция MDM незамысловата, в конечном итоге это процесс оперирования данными, которые распределяются между различными подсистемами, доступными различным пользователям. В простейшем случае эти данные могут сливаться в один так называемый «эталонный», или «основной файл» (master file). Таким файлом может быть, например, файл клиентов, создаваемый и используемый различными отделами.

Иногда для MDM используется альтернативное название — управление справочными данными (Reference Data Management, RDM). Мастер-данные — это данные, содержащие ключевую информацию о бизнесе, в том числе о клиентах, о продуктах, о работниках, о технологиях и материалах. Мастер-данные специфичны тем, что относительно редко изменяются и по своей природе не являются транзакционными. В определенных случаях мастер-данные поддерживают транзакционные процессы и операции, но в большей степени они используются для аналитической деятельности и подготовки отчетов. Можно сказать, что мастер-данные определяют собственное «Я» предприятия, ими представлены все компоненты бизнеса, они являются целостным представлением предприятия. Можно даже допустить, что мастер-данные являются формой представления части корпоративного интеллектуального капитала, определяемого экспертами из аналитической компании Forrester Research как «знания, навыки и производственный опыт конкретных людей (человеческие авуары) и нематериальные активы, включающие в себя патенты, базы данных, программное обеспечение, товарные знаки и др., которые производительно используются в целях максимизации прибыли и других экономических и технических результатов».

С технологической точки зрения системы MDM можно рассматривать как еще одну группу приложений, существующую наряду с транзакционными системами (ERP и им подобные) и системами поддержки принятия решений (хранилища данных и средства бизнес-аналитики). Создание систем MDM требует координации с другими подсистемами, с тем чтобы объединить мастер-данные, разбросанные по этим подсистемам. MDM и хранилища данных аналитиками Cutter Consortium были названы «близкими родственниками, разделенными на два десятилетия». С момента создания компьютеров и до 80-х годов вычисления и данные не разделялись. Однако, когда появились СУБД таких компаний, как Sybase, Informix, IBM и Oracle, и одновременно стали развиваться децентрализованные вычисления, между данными и вычислениями сложилась заметная граница, данные оказались нестандартизованными, появление «вертикальных пакетов приложений» усилило децентрализацию. С помощью хранилищ, киосков и витрин данных предпринимались попытки каким-то образом консолидировать данные, чтобы собрать целостную картину. MDM — еще один шаг в этом направлении.

Для того чтобы реализовать систему MDM, существует множество стимулов:

• Создать «бизнес, ориентированный на клиента»; для этого следует извлекать данные из подсистем CRM и использовать средства бизнес-аналитики.
• Наладить эффективные контакты с партнерами по бизнесу; для этого требуется обеспечить обмен данными с ними, средствами MDM можно собрать соответствующие сведения, обеспечить их связанность и синхронность.
• Подготовить предприятие к формированию финансовой и юридической отчетности; технологии MDM способствуют эффективному решению этой задачи.
• Создать полноценные условия для внедрения SOA; наличие консолидированных мастер-данных помогает этому.

Рынок MDM существует на протяжении нескольких лет; за это время он развивался, но не слишком интенсивно. Переломной точкой стал 2006 год, когда по сравнению с предыдущим продажи технологий MDM по всему миру увеличились на 30%. В последующие годы прогнозируется интенсивный рост с темпом не менее 15% в год. По разным оценкам (а различаются они тем, что именно включается в категорию продуктов MDM), к 2011 году его размер составит от 1,5 млрд. долл. до 6 млрд. долл.

Для того чтобы оценить состав участников рынка, можно последовать рекомендации аналитиков компании Bloor Research и согласиться с делением архитектур MDM на три категории.

Master Registry. Этот подход к MDM предполагает наличие центрального реестра идентификаторов и ссылок на приложения, владеющие данными, попадающими в категорию мастер-данных. Его развивают компании Initiate Systems, Nimaya, Purisma и Sun Microsystems.

Master Repository. В этом случае создается основной репозитарий MDM, содержащий как идентификаторы и ссылки, так и собственно данные. В этом сегменте основными игроками являются компании Hyperion, IBM, Kalido, Siperian, Stratature и TIBCO.

Master Hub. Концентратор MDM лишает приложения права владения мастер-данными и создает собственный ресурс идентификаторов и транзакционных данных. К приверженцам этой идеологии относятся компании FullTilt, i2, Oracle, SAP и Siebel (теперь входит в состав Oracle).

Особенности работы с мастер-данными

Мастер-данные отличаются от обычных транзакционных данных меньшей изменяемостью и меньшими объемами. Компании не получают одновременно сотни новых клиентов, а перечни используемых материалов и комплектующих не меняются ежесекундно. Даже клиентские базы данных сетевых операторов существенно стабильнее, чем биллинговые системы. Но, с другой стороны, мастер-данные структурно намного сложнее, чем операционные данные. К примеру, представления о клиенте не могут быть выражены с математической точностью, поэтому в разных подразделениях могут использоваться различные сведения о клиентах. Кроме того, модель мастер-данных меняется гораздо чаще, чем модель операционных данных, поэтому подлинная сложность мастер-данных заключается не в них самих, а в описывающих их метаданных. Метаданные, описывающие мастер-данные, могут претерпевать от нескольких единиц до сотен изменений в месяц, отслеживать все эти изменения в стихийно сложившейся системе MDM практически невозможно. Решение проблемы сложности состоит в создании отдельной единой среды MDM, которая будет выполнять обе функции — и сбор, и представление данных для последующей обработки средствами бизнес-аналитики. Построение единой системы MDM является трудоемкой задачей, в крупной компании оно может занять несколько лет и может быть сопряжено со сложностями, вызванными наличием унаследованных приложений.

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

При федеративном подходе (рис. 1.) задача состоит в передаче и синхронизации изменений между элементами системы входа, с тем, чтобы обеспечить согласованность мастер-данных. Этот подход реализуется посредством концентратора мастер-данных (master data hub), который в соответствии с установленными правилами осуществляет асинхронный обмен данными. Основной предмет деятельности заключается в формулировании этих правил. Преимуществом этого подхода является невмешательство в действия существующих систем и сохранение контекста, а недостатком — то, что он эффективен лишь при относительно небольшом разнообразии мастер-данных и не выдерживает нагрузки при усложнении среды мастер-данных.

Интегрированное решение

(рис. 2) заключается в создании автономной системы MDM, способной самостоятельно собирать изменения в мастер-данных. В таком случае все эти данные хранятся в централизованном репозитарии. Данный подход обеспечивает наиболее полное и адекватное представление мастер-данных.

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

Мастер-данные в контексте других корпоративных данных и бизнес-процессов

Данные можно классифицировать по различным признакам — по их принадлежности, по организации, по актуальности и по многим другим. Очевидно, что одни и те же данные могут присутствовать в нескольких категориях одновременно [2].

• Частные данные — данные принадлежат одному человеку, ни с кем не разделяются, никто иной, кроме него самого, не осуществляет управление этими данными.
• Распределяемые данные — данные рабочих групп или предприятия в целом.
• Внутренние бизнес-данные — частные или распределенные данные, создаваемые и поддерживаемые работниками компании или внутренними приложениями.
• Внешние бизнес-данные — данные, поступающие от внешних организаций и приложений.
• Структурированные данные — наборы записей с фиксированной структурой полей, определенной внешней моделью данных.
• Квазиструктурированные данные — наборы записей с переменной структурой полей, определенной внешней моделью данных.
• Неструктурированные данные — наборы данных, не имеющие внешнего описания структуры полей.
• Текущие данные — последняя версия записи.
• Исторические данные — записи предыдущих версий.
• Зрелые данные — данные, уже не используемые в текущих транзакционных операциях.

Можно подойти к классификации данных с точки зрения бизнес-процессов (рис. 3). Полезно выделить основные типы бизнес-процессов — коллаборативные процессы, процессы планирования бизнеса, операционные транзакционные процессы, процессы работы с мастер-данными, процессы бизнес-аналитики. Объединение этих процессов легко представить средствами сервисо-ориентированных архитектур (Service-Oriented Architecture, SOA). Если эту концепцию предельно упростить, то можно сказать, что SOA — это способ сборки динамических, сложных прикладных систем из отдельно стоящих, автономных программных модулей. При условии независимости по данным для создания единой системы достаточно ограничиться «корпоративной сервисной шиной» (Enterprise Service Bus, ESB). Но реальное предприятие представляет собой единый производственный организм, его подразделения и средства автоматизации находятся во взаимной связи между собой. К примеру, производственные, административные, маркетинговые и другие подразделения находятся в процессе постоянного информационного обмена; поэтому приложения, автоматизирующие их работу, используют общие данные. По этой причине такие приложения не автономны и не независимы. Решением проблемы рассогласования данных может стать создание единой для всего предприятия «сервисной архитектуры данных» (Data Service Architecture, DSA). Чаще всего под DSA понимают введение дополнительного уровня в модель SOA; данный уровень стали называть «уровнем сервиса данных» (Data Service Level, DSL). Этот уровень обеспечивает абстракцию и интеграцию данных с точки зрения бизнес-сервисов; он обеспечивает целостный взгляд на корпоративные данные и интерфейс к данным, независимый от конкретных форм их хранения и представления. Реализовать уровень сервиса данных можно в виде так называемой «информационной сервисной шины» (Information Service Bus, ISB) по аналогии с корпоративной сервисной шиной.

Коллаборативные процессы складываются из задач и действий, выполняемых с участием людей, поэтому они в основном связаны с неструктурированными и полуструктурированными данными, такими как текстовые документы, электронные таблицы, презентации, отчеты, изображения, видеофайлы, электронные письма, Web-страницы и многое другое. Часть из перечисленного может входить в подмножество частных данных, а часть образует разделяемое «хранилище контента» (Content Data Store, CDS), где могут храниться как текущие, так и исторические данные. Наиболее актуальная задача, связанная с коллаборативными процессами, — работа с неструктурированными данными, а также использование таких Web-решений, как корпоративные блоги и wiki.

Процессы планирования бизнеса включают в себя стратегическое, тактическое и операционное планирование, а также бюджетирование и прогнозирование. В этих процессах используются как квазиструктурированные данные, так и данные, предоставляемые ERP-системами, совместно они образуют разделяемое «хранилище данных планирования» (Planning Data Store, PDS).

К операционным транзакционным процессам сводится большая часть приложений, чаще всего они имеют дело со структурированными данными, хранимыми в базах данных. Данные в «операционном хранилище» (Operational Data Store, ODS) модернизируются в асинхронном режиме по отношению к транзакционной обработке, поэтому между процессами и данными наблюдается определенная задержка.

Процессы бизнес-аналитики направлены на мониторинг, анализ, измерения основных показателей бизнеса, в них обычно используются исторические и зрелые данные, переданные в хранилища данных из транзакционных систем, но наметилась новая тенденция, предполагающая перенос в «корпоративное хранилище данных» (Enterprise Data Warehouse, EDW) еще и данных из процессов планирования. Существуют две основные школы хранилищ данных; основоположником одной является Билл Инмон, другой — Ральф Кимбалл.

Процессы управления мастер-данными в неявном виде существовали давно, они так или иначе поддерживались транзакционными процессами и хранились в ODS, затем они перемещались в корпоративные хранилища данных, где к ним применялись обычные методы бизнес-аналитики. Но в последние годы наметилась тенденция к выделению в самостоятельные сущности данного типа процессов, к хранению мастер-данных в отдельных хранилищах и к применению к ним самостоятельных методов бизнес-аналитики.

Вообще говоря, для работы с мастер-данными необходимо иметь две подсистемы, каждая из которых выполняет свою функцию. Одна служит для их создания и поддержания в актуальном состоянии, она собирает сведения о работниках, клиентах, продукта, фондах, поэтому ее называют «системой входа» (system of entry), вторая обеспечивает целостное представление накопленных мастер-данных, ее называют «системой записи» (system of record). В идеальном случае обе подсистемы являются частями одной среды, тогда можно исключить дублирование данных, обеспечить их высокое качество. Но в силу исторической традиции предприятия обычно такими средами не располагают, функцию первой подсистемы выполняют различные транзакционные приложения, поэтому для создания целостного интегрированного взгляда на вещи необходимо собирать данные из различных источников. Функция второй совмещена с общей системой бизнес-аналитики. В итоге складывается картина, показанная на рис. 4, где работа с мастер-данными мало отличается от работы с другими аналитическими данными и никак не учитывается их специфика. Подобная эволюционно сложившаяся система MDM имеет целый ряд ограничений.

MDM и SOA

После нескольких лет неумеренных восторгов по поводу потенциала SOA представители ведущих аналитических компаний синхронно пришли к единому мнению, что эта архитектура окажется малоэффективной, если ее внедрение не будет подкреплено средствами управления данными.

Аналитики Forrester Research утверждают: «Сама по себе SOA не даст никаких выгод, если не будет выработана технология управления данными. Системная рационализация, создаваемая в предположении, что отдельный сервис работает с отдельным типом записей, не может быть эффективной, поскольку данные остаются фрагментарными… Необходим специальный тип программного обеспечения промежуточного слоя — информационная матрица (information fabric)».

В Gartner предупреждают: «Вы не получите желаемого ускорения бизнеса от внедрения SOA, если не начнете с управления информацией. Вы попросту потеряете ваши инвестиции, если SOA не будет поддержана корпоративной информацией».

С ними соглашаются и в Aberdeen: «Внедряя композитные приложения и SOA, компании вкладывают миллиарды. Однако большая часть этих инвестиций уйдет впустую, если они не будут поддержаны действиями, связанными с интеграцией данных. Решающая роль в этом принадлежит технологиям Master Data Management, но наши исследования показывают, что компании обычно игнорируют это обстоятельство».

Из приведенных высказываний следует сделать вывод, что внедрение SOA не должно стать прикрытием для неуправляемой структуры данных. MDM — один из шагов в направлении, о котором говорят ведущие аналитики. Объединение MDM и SOA придает новый смысл эти новациям; только совместно MDM и SOA открывают возможность системного видения корпоративных данных.

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

• Взаимодействие между компонентами начинается с установления «контакта», в MDM это делается посредством интерфейсов, а в SOA — на основе описания сервисов.
• Возможность повторного использования в MDM основывается на единообразии представления данных, а в SOA осуществляется благодаря основополагающему сервисному принципу.
• «Обнаружение» в MDM обеспечивается наличием репозитария мастер-данных, а в SOA — реестра сервисов.
• Перенос системной сложности в инфраструктуру характерен и для MDM, и для SOA.

С технической точки зрения MDM и SOA могут пересекаться на уровне сервисов данных, реализуемых корпоративной информационной шиной.

Сервисы данных можно разделить на три категории. Enterprise Data Services осуществляют основную работу с данными, в частности они обеспечивают единственность копии распределенных данных, по аналогии с музыкальными дисками ее называют «золотой копией» (gold copy). Enterprise Metadata Services поддерживают работу с метаданными. Enterprise Data Platform Services обеспечивают управление, мониторинг и подготовку отчетов.

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

Трудное будущее MDM

Включение технологий MDM в существующую информационную инфраструктуру предприятия (приложения управления отношения с клиентами, планирования ресурсов предприятия, биллинговые системы и т.д.) представляет серьезную задачу, но первые внедрения показали, что есть еще более сложные проблемы. Их корни — в плохой организации данных. По мнению Data Warehousing Institute, эту причину назвали в качестве основной трудности свыше 83 обследованных предприятий. Авторы отчета считают, что предприятиям предстоит выполнить большой объем работ, связанных с согласованием представлений и характеристик таких, казалось бы, простых вещей, как «партнер» или «клиент», а также многих других компонентов мастер-данных. Для этого им необходимо создавать смешанные рабочие группы из ИТ-специалистов и представителей бизнес-подразделений. В этих группах обе категории специалистов должны работать совместно.

Литература

1. Luciano Florid, Is Semantic Information Meaningful Data? Philosophy and Phenomenological Research, Vol. LXX, No. 2, March 2005.
2. Colin White, The Enterprise Data Mountain, Master Data and Business Intelligence. Business Intelligence Network, www.b-eye-network.com.

---

^* Тем, кому интересно фундаментальное исследование различий между данными и информацией, можно рекомендовать статью Лучано Флориди [1]. Сегодня Флориди считается одним из самых авторитетных философов, занимающихся проблемами науки, технологий и этики, он признан родоначальником информационной философии. К величайшему сожалению, система взглядов Флориди и его предшественников (прежде всего Грегори Бейтсона), чрезвычайно интересна с познавательной точки зрения, но абсолютно непрактична и неприменима к материализованным данным. — Прим. автора.