CC BY
57
УДК 004.4::004.6::330.142.211 Дата подачи статьи: 01.09.16
DOI: 10.15827/0236-235X.030.1.051 -060 2017. Т. 30. № 1. С. 51-60
ОБ ОДНОМ ПОДХОДЕ К РЕАЛИЗАЦИИ СИСТЕМЫ УПРАВЛЕНИЯ МАСТЕР-ДАННЫМИ ОБ АКТИВАХ
А.А. Сухобоков, к.т.н.., artem.sukhß[email protected] (Компания «САП СНГ», Космодамианская наб., 52/2, г. Москва, 115054, Россия); В.И. Строгонова, инженер, [email protected] (Компания «Оптимальное Управление», ул. Фестивальная, 22, корп. 6, г. Москва, 125581, Россия)
В статье рассматриваются возможности современных MDM-систем (систем Master Data Management) и перспективные направления разработки мультидоменных и мультивекторных MDM-систем. Показаны причины, по которым однодоменные системы управления мастер-данными об активах не нашли широкого применения в отличие от существующих систем управления мастер-данными о клиентах, поставщиках, продуктах, сотрудниках и других типах бизнес-объектов. Рассматриваются сложности совмещения различных представлений одних и тех же активов в системе управления мастер-данными об активах. Делается вывод, что, пока не будут разработаны и не начнут успешно внедряться однодоменные системы управления мастер-данными об активах, переносить эту предметную область в муль-тидоменные системы преждевременно.
Для решения описанных проблем предложена модель мастер-данных об активах, позволяющая совместить их различные представления. Эта модель включает множество независимых иерархий для различных представлений одного и того же парка активов, неиерархические связи, специфические для каждой предметной области, решетки связей, позволяющие переходить между разными представлениями одного и того же актива, набор классификаторов активов, классы в которых определяют наборы описывающих активы атрибутов, классификаторы связей активов, а также структурные и функциональные модели отдельных типов активов. Для реализации модели мастер-данных об активах разработана архитектура MDM-системы, а также предложен алгоритм проверки корректности межракурсных связей всей модели в целом.
Выдвинуты основные требования к инструментарию для разработки прототипа системы управления мастер-данными об активах: он должен одновременно обеспечивать функциональность графовой СУБД и графового энджина для выполнения сложных алгоритмов над графом в целом. Из двух существующих инструментов, отвечающих этим требованиям, для разработки выбран SAP HANA Graph.
Ключевые слова: MDM-система, система управления мастер-данными об активах, модель данных, архитектура системы, алгоритм проверки корректности связей, SAP HANA Graph.
Целями применения существующих систем управления мастер-данными (MDM-систем) являются формирование и поддержка консистентного, функционально полного и актуального представления основных данных, отражающих все нюансы структуры и деятельности предприятия. Наличие и поддержка такого единственного содержательного представления мастер-данных является критическим фактором для достижения бизнес-целей предприятия. MDM-системы представляют собой инструментарий для поддержки процессов управления мастер-данными в масштабе предприятия на основе принятых руководящих документов, политик и стандартов [i, 2]. С точки зрения принадлежности программных продуктов к прикладному или платформенному ПО MDM-системы входят в состав платформы и являются неотъемлемой частью комплекса систем управления информацией в масштабах предприятия (Enterprise Information Management) [3].
Системы управления мастер-данными об активах как подкласс систем управления мастер-данными
Ведущая мировая аналитическая компания Gartner традиционно ежегодно выпускает два независимых аналитических обзора по разным классам
МОМ-систем. Эта традиция была сохранена и в 2015 году [4, 5]. Системы управления мастер-данными об активах отдельно не рассматриваются в этих обзорах. Они относятся к широкому классу МОМ-систем с данными о предметах, и считается, что и на них распространяется обзор [4] (в отличие от МОМ-систем с данными о командах, на которые распространяется обзор [5]).
Согласно [4], комплексная стратегия управления мастер-данными охватывает множество предметных областей: клиенты, продукты, материалы, услуги, активы, персонал или команды, поставщики и финансы. Мастер-данные об активах, как и мастер-данные о продуктах, становятся все более критичными в связи с ростом числа публикаций и интереса к Интернету вещей (1оТ). Распространение 1оТ предполагает, что все больше устройств (вещей) обмениваются информацией. Многие из них находятся за пределами зоны действия используемых норм организации и управления информацией, в итоге теряется доверие к такой информации. Управление мастер-данными позволяет снять вопрос о доверии, обеспечить качество и конси-стентность данных об устройствах, а также данных, получаемых от этих устройств.
Рассматривая проблематику систем управления мастер-данными об активах, необходимо ответить на вопрос, что понимается под активом. Ответ не
всегда однозначен, и этот термин трактуется разными компаниями по-разному. Практически всегда в понятие активов включаются материальные активы (здания, сооружения, оборудование, земельные участки, строящиеся объекты и т.д.) и их составные части. Несколько реже в понятие включаются нематериальные активы - программные системы, БД, патенты, товарные знаки и т.д. Еще реже в российской практике [6] и более часто в западной в единое понятие активов включаются и финансовые активы - акции, облигации, займы, доли в совместных проектах, векселя и т.д.
Общая численность парка активов в крупных компаниях, таких как ОАО «РЖД», НК «Роснефть», может достигать нескольких десятков миллионов единиц. Основную часть такого большого парка (более 90 %), как правило, составляют материальные активы.
Обобщенно рассматривая системы управления мастер-данными об активах как некоторый подкласс МЭМ-систем о вещах, в [4] также уделяется много внимания перспективам работы МЭМ-сис-тем с данными более чем одной предметной области (применительно к теме данной статьи - не только с мастер-данными об активах). Наряду с доминирующими сейчас однодоменными МЭМ-сис-темами, предназначенными для работы с данными одной предметной области (например, с данными о клиентах или о продуктах), пока еще мало распространены, но быстро расширяются сегменты муль-тидоменных и мультивекторных МЭМ-систем. Мультидоменные системы предназначены для работы с данными нескольких предметных областей. Несмотря на то, что пользователи хотели бы иметь возможность работать с любыми предметными областями в любом месте и любым способом, существующие мультидоменные МЭМ-системы ориентированы на одну якорную область данных. В данный момент, согласно [4], мультидоменные МБМ-системы - это:
- МЭМ-системы для работы с одной предметной областью, имеющие расширенные ссылки на другие предметные области;
- МЭМ-системы для работы с одной предметной областью, в которые добавлено большое число атрибутов и иерархий, чтобы поддержать локальные бизнес-процессы или приложения;
- несколько одновременно установленных МЭМ-систем для разных предметных областей, часто от разных поставщиков, объединенных внешним интерфейсом.
Концепция мультивекторных МЭМ-систем расширяет понятие мультидоменных МЭМ-сис-тем. Помимо работы с разными предметными областями, мультивекторные МЭМ-системы должны работать в разных отраслях, при разных сценариях использования (проектирование структур, операционные или аналитические МЭМ-системы), для разных организационных структур (централизо-
ванная, федеративная, локализованная) и при разных сценариях внедрения MDM-системы (регистровая, консолидационная, в режиме сосуществования и централизованная). По прогнозу Gartner [4], мультивекторные MDM-системы сменят мультидоменные и однодоменные не ранее, чем через пять лет.
По мнению авторов, пока не будут реализованы и не докажут на реальных внедрениях свою работоспособность и эффективность однодоменные системы управления мастер-данными об активах, прогнозировать, что необходимые функциональные возможности по управлению мастер-данными об активах будут покрыты мультидоменными и мультивекторными MDM-системами, преждевременно. Только после того, как все необходимые механизмы будут отработаны на однодоменных системах, можно будет осуществить их перенос в мультидоменные системы.
Нерешенные проблемы управления мастер-данными об активах
В существующих корпоративных системах управления в нескольких модулях или подсистемах независимо ведутся мастер-данные о производственных фондах (активах), отражающие различные характеристики одних и тех же объектов. Даже когда разные приложения являются модулями единой ERP-системы, используется такой же подход [7, 8]. Примерная структура основных данных об активах в существующих системах управления крупными компаниями показана на рисунке 1 [9].
Технически это реализуется следующим образом: в разных прикладных подсистемах для ведения мастер-данных об активах используются собственные структуры различной сложности и независимые классификаторы объектов. Мастер-данные ведутся разрозненно, хотя и перечень объектов, и значительная доля описывающих объекты характеристик (в том числе паспортных и эксплуатационных) необходимы для работы нескольких приложений. Как следствие, возникает дублирование данных и появляются противоречия между различными представлениями данных. Кроме снижения качества данных, это также увеличивает издержки по сопровождению [9].
В действительности в корпоративных системах имеется намного больше подсистем, в которых используются мастер-данные об активах, чем показано на рисунке 1 [9]. В их число входят данные:
- об основных средствах (объектах бухгалтерского и налогового учета);
- об объектах недвижимости;
- об объектах технического обслуживания и ремонта оборудования;
- об объектах имущества (правовой аспект);
- об объектах подсистем мониторинга (пожарной безопасности, видеонаблюдения и др.);
Учет основных средств
Недвижимость / Управление имуществом
Техническое место 3
Единица оборудования 1 Единица оборудования 2
Рис. 1. Пример раздельного ведения мастер-данных об основных средствах, объектах недвижимости и оборудовании в разных модулях ERP-системы с организацией связей между ними
Fig. 1. An example of independent master data management on fixed assets, real estate objects and equipment in various modules of ERP system with links between them
- об объектах подсистем оперативного управления режимами работы оборудования непрерывных производств, транспорта и связи, коммунального хозяйства;
- об объектах различных MES и технологических систем управления производством;
- об объектах геоинформационных систем (визуализируемых на картах);
- об объектах генерации, передачи и потребления электроэнергии в подсистемах управления производством и потреблением электроэнергии;
- об объектах добычи, транспортировки и отпуска нефти, нефтепродуктов и газа в подсистемах управления добычей, транспортировкой и сбытом углеводородов;
- об обрабатывающих центрах и транспортных механизмах в системах технологической подготовки производства (CAM-системах);
- о складах, распределительных центрах и торговых точках в системах управления розничными сетями.
Перечислим основные причины, по которым системы управления мастер-данными об активах не нашли широкого применения в отличие от MDM-систем для других предметных областей [9].
1. В разных прикладных областях применяются различные принципы выделения активов. Например, в рамках бухгалтерского учета в одно основное средство могут быть объединены несколько рядом стоящих единиц оборудования, имеющих одинаковые правила начисления амортизации. При проведении ремонта и технического обслуживания выделяются объекты, имеющие разный порядок ремонта и обслуживания. В рамках имущественного учета выделяются объекты, которые независимо могут быть проданы или сданы в аренду, например одно волокно в пучке оптических волокон или оптоволоконном кабеле.
2. В разных приложениях, работающих с одним и тем же парком активов, используются различные иерархии вложенности объектов, причем различаются объекты как группирующих уровней, так и нижних уровней таких детализирующих иерархий.
3. При функционировании комплексных систем управления пользователям очень часто необходимо видеть смежные представления одного и того же актива. Например, из технологического представления необходимо видеть объекты технического обслуживания и ремонта. Из объектов технического обслуживания и ремонта необходимо
видеть основные средства, на которые будут списываться затраты. Из основных средств необходимо видеть соответствующие объекты имущества и т.д. Почти всегда пользователям необходимо видеть объекты нескольких разных представлений. Отсутствие взаимно однозначного соответствия между объектами нижнего уровня различных приложений приводит к появлению связей многие ко многим между объектами разных представлений, описывающими один и тот же актив. Как уже было показано ранее, одному основному средству может соответствовать множество объектов технического учета. Но также справедливо и обратное: одному объекту технического учета, например асфальтированной дороге, может соответствовать множество основных средств, если ее отдельные участки, не являющиеся единицами технического учета, строились (выкупались) по разным ценам или в разное время.
Отсутствие в настоящий момент на рынке системы управления мастер-данными об активах, способной преодолеть перечисленные сложности, подтверждается также обзорами аналитической компании Forester. В первом квартале 2016 года компания выпустила обзор [10], в котором выделила четыре класса MDM-систем и проанализировала продукты двенадцати компаний. Были выделены
- MDM-системы, обеспечивающие интеграцию данных и решающие стандартные задачи;
- мультидоменные MDM-системы и MDM-системы, поддерживающие множество представлений мастер-данных;
- контекстуальные MDM-системы, поддерживающие семантическое представление бизнес-данных;
- аналитические MDM-системы, интегрированные внутрь аналитических платформ.
Из четырех представленных классов MDM-сис-тем сформулированные проблемы должны решаться в группе мультидоменных MDM-систем и MDM-систем, поддерживающих множество представлений мастер-данных. В качестве лидеров этой группы выделены SAS, SAP и IBM. У этих компаний в настоящий момент нет MDM-систем, способных обеспечить управление мастер-данными об активах в описанном выше ключе.
Предлагаемая модель данных
Для совмещения нескольких разных представлений одного и того же парка активов предлагается модель данных, включающая произвольное число ракурсов представления активов. Каждый ракурс описывается некоторой иерархией, примерный вид которой представлен на рисунке 2.
Начиная с некоторых узлов дальнейшие связи обрываются, чтобы не увеличивать сложность рисунка. Число уровней иерархии может быть раз-
Ракурс активов компании
Заводы компании
Производственно-технические комплексы
Места монтажа оборудования
Единицы оборудования
Рис. 2. Пример иерархии объектов для описания одного ракурса мастер-данных об активах
Fig. 2. An example of object hierarchy for describing one master data view of assets
личным в разных ракурсах. Иерархическая структура ракурса отображает принадлежность (вхождение объектов в объекты более высокого уровня).
Разные ракурсы полиморфны между собой, то есть отсутствует взаимно однозначное соответствие между объектами разных ракурсов.
Каждый объект, представленный в иерархии, принадлежит к какому-то классу объектов. Класс определяет свойства (набор атрибутов) объекта. Классы объектов строятся на принципах полиморфизма и наследования. Они образуют иерархию классов, позволяя детально описывать тип и атрибуты (характеристики) каждого актива. Для каждого ракурса строится собственная система классификации объектов. Атрибуты объектов могут иметь широкий спектр типов: не только целое, вещественное, логический признак, текст, но и массив, множество, зависимость, график, таблица, документ и др.
Для описания одного и того же актива, представленного в разных ракурсах, могут использоваться атрибуты с одинаковым именем, однако значения этих атрибутов могут не совпадать.
Параллельные иерархии разных ракурсов (лес) провязаны на каждом уровне решетками связей для обеспечения переходов между разными ракурсами представления одного и того же актива. Пример такой решетки представлен на рисунке 3.
Решетки необязательно являются полными (то есть необязательно в них присутствуют все связи каждого объекта с каждым). Наличие связей между разными объектами зависит от семантики: нужно устанавливать соотношения между объектами этих ракурсов на данном уровне или нет.
На одном уровне иерархии любого из ракурсов располагается много объектов, каждый из которых связан со своей решеткой смежных объектов.
Решетки одного уровня могут частично совмещаться друг с другом. Это возникает из-за того, что в отдельных ракурсах один объект может соответствовать нескольким объектам другого ракурса, расположенным на одном уровне иерархии (например, одно основное средство может объединять не-
Рис. 3. Пример решетки связей, соединяющих один и тот же актив в разных ракурсах Fig. 3. An example of link grid connecting the same asset in different views
сколько единиц оборудования), и тогда решетки смежных объектов одного уровня могут частично соединяться в отдельных ракурсах.
Если рассматривать 3Б-модель графа мастер-данных, то решетки на разных уровнях необязательно будут абсолютно параллельными. В отдельных ракурсах один объект может соответствовать нескольким объектам другого ракурса, расположенным на разных уровнях иерархии, и тогда решетки смежных уровней могут соединяться в отдельных ракурсах.
В отдельных ракурсах между объектами имеются неиерархические связи, отражающие специфические отношения между объектами, свойственные этому ракурсу. Например, функциональное взаимодействие в процессе производства, логистический обмен товарами, соседнее территориальное расположение и др. Пример ракурса с такими связями между производственно-техническими комплексами представлен на рисунке 4.
Показанные на рисунке 4 неиерархические связи могут иметь собственную систему классов и наборы атрибутов, описывающие каждую связь. В ряде случаев неиерархические связи между объектами одного ракурса могут быть параметрическими, то есть возникающими только тогда, когда значения одного или нескольких атрибутов объекта соответствуют определенным условиям.
Помимо классов объектов, определяющих их тип, в модели данных могут присутствовать структурные и функциональные модели отдельных типов активов. Одним из назначений таких моделей является проверка правильности вводимых мастер-данных. Возможности использования структурных описаний для проверки правильности ввода данных об активах можно проиллюстрировать следующим простым примером. Структурная модель котельной включает обязательные компоненты: здание, установленный в нем котел и дымовую трубу. Если вновь введенный пользователем объект имеет
Ракурс активов компании Страны Регионы
Производственно-технические комплексы
Рис. 4. Пример неиерархических связей между объектами одного ракурса
Fig. 4. An example of non-hierarchical links between objects of one view
тип «котельная», но не содержит всех трех обязательных компонентов, пользователю выводится сообщение об ошибке. Функциональные модели могут проверять соответствие объекта его типу, используя значения атрибутов этого объекта и атрибутов других, связанных с ним объектов. Структурные и функциональные модели, используемые для проверки полноты и правильности вводимых мастер-данных, могут быть достаточно сложными.
Роль структурных и функциональных моделей в общем механизме управления мастер-данными об активах не ограничивается проверкой правильности вводимых данных. При описании технических ракурсов представления активов в ряде случаев используемая схема соединения компонентов определяет тип объекта, состоящего из этих компонентов. Точно так же тип объекта может зависеть от значений его атрибутов и применяемых функциональных моделей.
Архитектура системы управления мастер-данными об активах
Предлагаемая общая архитектура системы управления мастер--данными об активах представлена на рисунке 5.
Ядро системы поддерживает создание/модификацию и хранение в памяти информационной модели активов.
Каждый интерфейсный модуль обеспечивает взаимодействие с конкретным приложением или функциональным модулем ERP-системы. По запросам, поступающим от внешних приложений или модулей ERP, интерфейсный модуль осуществляет выгрузку запрошенного фрагмента мастер-данных об активах, относящихся к конкретному ракурсу мастер-данных, с которыми работает запрашивающий модуль. Помимо объектов данных конкретного ракурса, могут быть выгружены также иерархия, классификатор, сетевые связи, структурные и функциональные модели, относящиеся к объектам этого ракурса. Все объекты активов могут быть выгружены вместе с имеющимися связями с объектами других ракурсов.
Помимо выгрузки из системы управления мастер-данными, интерфейсные модули также могут обеспечивать загрузку обновленных или новых мастер-данных соответствующих ракурсов из приложений и модулей ERP в систему управления мастер-данными. Однако такая загрузка не обеспечивает использование загруженных данных в системе. Требуется последующее подтверждение загруженных данных от администратора мастер-данных.
Модуль диалогового интерфейса обеспечивает создание и корректировку мастер-данных администратором мастер-данных в режиме диалога. В том числе с его помощью подтверждаются мастер-дан-
Администратор мастер-данных
Рис. 5. Архитектура системы управления мастер-данными об активах Fig. 5. The architecture of MMDM of asset data solution
ные, загруженные интерфейсными модулями извне, или осуществляются корректировки этих данных, вносятся дополнительные связи и только потом дается разрешение на использование этих данных в системе.
Алгоритмические модули позволяют выполнить обработку всей модели мастер-данных в целом или отдельных ракурсов. С их помощью может выполняться проверка корректности имеющихся в системе мастер-данных или связей между объектами. Также с их помощью могут выполняться формирование новых ракурсов мастер-данных на основе имеющихся в системе данных других ракурсов и/или на основе внешних данных и другие операции над информационной моделью в целом. Инициирование работы алгоритмических модулей осуществляет администратор мастер-данных через модуль диалогового интерфейса.
Алгоритм проверки корректности межракурсных связей в единой модели активов
Для того чтобы единая модель активов была корректной, необходимо, чтобы в ней были корректными все связи. Для проверки структуры иерархий и неиерархических связей внутри ракурсов требуется использовать дополнительную семантическую информацию. В то же время проверку полноты и корректности всех решеток межракурсных связей можно выполнить, используя только тип объектов и существующую структуру связей без привлечения дополнительной информации о конкретных объектах. Для проверки полноты связей в решетке можно использовать шаблон, содержащий все необходимые связи, и каждую решетку можно сверить с этим шаблоном. Поскольку в больших компаниях неизбежно будет наблюдаться значительное разнообразие видов активов, большинство из которых не должно присутство-
Учет основных средств
Недвижимость / Управление имуществом
Основное средство Архитектурный объект
Единица оборудования
Техническое обслуживание и ремонт оборудования
Рис. 6. Простая решетка связей для одного и того же актива, представленного в трех ракурсах
Fig. 6. A simple grid for one asset presented in three views
вать во всех ракурсах, шаблон решетки не может быть единым, на практике должен использоваться некоторый набор правил, регламентирующих применение шаблонов для отдельных видов активов.
Однако наличие конечного множества используемых шаблонов решеток и сверка с ними фактических решеток связей не избавит от ситуации, когда связи между разными объектами требуемых типов перепутаны между собой. Для борьбы с этим явлением авторы предлагают специальный алгоритм, рассматриваемый далее.
Если предположить, что имеются всего три ракурса активов, решетка принимает вид, представленный на рисунке 6.
Проверка корректности всех связей решетки в этом случае осуществляется с помощью простого обхода: из каждого объекта необходимо пройти по кольцу связей в одном направлении, а потом в обратном. Если для всех объектов при проходе в обоих направлениях мы возвращаемся к первоначальному объекту, все связи в решетке корректны.
Обобщим этот подход для сложных многоракурсных структур описания активов. Для обхода всех объектов в иерархии каждого ракурса используем стек, показанный на рисунке 7.
Иерархия ракурса
Стек для обхода иерархии
Ракурс активов компании
Заводы компании
Производственно-технические комплексы
Места монтажа оборудования
Единицы оборудования
Объект уровня 1
Объект уровня 2
Объект уровня 3
Объект уровня 4
Объект уровня 5
Рис. 7. Применение стека для обхода объектов одного ракурса Fig. 7. The use of a stack to round one view objects
Стек для обхода всех колец решетки, начинающихся с одного объекта
Объект уровня 1
Объект уровня 2
Объект уровня 3
Объект уровня 4
Объект уровня 5
Объект уровня 6
Рис. 8. Применение стека для обхода всех колец одной решетки, начинающихся с одного объекта Fig. 8. The use of stack to round all rings of one grid starting from one object
В процессе проверки необходимо обойти все иерархические ракурсы, представленные в структуре активов, и запустить алгоритм проверки связей для каждого объекта.
Для обхода всех колец одной решетки, начинающихся с одного объекта, используем еще один стек, представленный на рисунке 8.
Пройдя по каждому из колец, необходимо вернуться к первоначальному объекту. Поскольку осуществляется перебор всех связей каждого объекта, автоматически будет реализован просмотр в прямом и обратном направлениях. Дополнительно программировать проход в обратном направлении не требуется.
Чтобы не проверять многократно одни и те же варианты колец связей, начиная с разных объектов, на время выполнения алгоритма вводится разметка связей. Если при обходе колец проходим по какой-то связи и для следующего перехода видим только одну связь, у которой нет отметки, или конец обхода кольца, то ставим на пройденной связи отметку. При дальнейшей проверке проходить по этой связи не нужно. В результате после обхода всех колец, начиная с объектов одного ракурса, если объекты другого ракурса не имеют допол-
нительных связей, которые еще не проверялись, обход этих объектов не потребует какого-либо обхода колец. Обобщенная блок-схема описанного алгоритма представлена на рисунке 9.
Использование полученных результатов при разработке прототипа системы управления мастер-данными об активах
Исходя из особенностей разработанной модели данных и алгоритма проверки корректности межракурсных связей, при разработке прототипа системы управления мастер-данными об активах сформулированы следующие основные требования к используемому инструментарию.
1. Инструментарий должен обладать возможностями работы с графовой БД [11]. Это обеспечит существенные преимущества при работе с графами за счет увеличения скорости разработки и сокращения объема кода при обходе цепочек связей по сравнению с традиционным SQL, а также будет требоваться меньше ресурсов для работы прототипа.
2. Инструментарий должен обладать возможностями графовых энджинов [12], выполняющих
Рис. 9. Обобщенная блок-схема алгоритма проверки целостности межракурсных связей в единой модели активов
Fig. 9. The generalized block diagram of the algorithm for verification links integrity between views of the single asset model
сложные алгоритмы над большим графом в целом, даже если его фрагменты хранятся на разных серверах кластера.
Этим требованиям соответствуют SAP HANA Graph [13] и Microsoft Graph Engine [14, 15], работающий на кластере серверов под управлением Microsoft Windows Server. Для использования Microsoft Graph Engine требуется специально конфигурировать кластер под решаемую задачу, в то время как SAP HANA Graph может работать на любой SAP HANA, установленной в режиме On-Premise. Поэтому для использования выбран SAP HANA Graph. Перед выполняемой в настоящее время разработкой прототипа системы управления мастер-данными об активах ставятся цели обеспечить поддержку разработанной модели данных, реализовать механизм проверки полноты межракурсных связей и разработанный алгоритм проверки корректности межракурсных связей.
Литература
1. Wolter R., Haselden K. The what, why, and how of master data management. 2006. URL: https://msdn.microsoft.com/en-us/li-brary/bb 190163 .aspx?f=255&MSPPError=-2147217396 (дата обращения: 29.07.2016).
2. Otto B., Schmidt A. Enterprise master data architecture: design decisions and options. URL: http://mitiq.mit.edu/ICIQ/ Documents/IQ%20Conference%202010/Papers/2B 1_Enterprise MasterDataArchitecture.pdf (дата обращения: 29.07.2016).
3. Barrenechea M.J., Jenkins T. Enterprise information management: the next generation of enterprise software. Open Text Corporation, Waterloo (Canada), 2013, 288 p.
4. Magic quadrant for master data management of product data solutions. Gartner, November 12, 2015, ID:G00271935.
5. Magic quadrant for master data management of customer data solutions. Gartner, November 11, 2015, ID:G00271783.
6. Система управления // Годовой отчет РАО «ЕЭС России». 2006. С. 26-30. URL: http://www.fsk-ees.ru/media/File/ stockholders/otchet/decisions/VOSA_otchet/RAO/03_RAO_GO_ 2006.pdf (дата обращения: 29.07.2016).
7. Equipment as units of tangible assets. URL: http://help.sap. com/saphelp_ppm400/helpdata/en/01/d545f84ab311d189740000e8 322d00/frameset.htm (дата обращения: 29.07.2016).
8. Creating an architectural object. URL: http://help.sap.com/ saphelp_erp60_sp/helpdata/en/fb/5ad0531d8b4208e10000000a174c b4/frameset.htm (дата обращения: 29.07.2016).
9. Система управления мастер-данными об активах. URL: http://optimalmngmnt.com/page34ru.htm (дата обращения: 29.07.2016).
10. The Forrester Wave™: Master Data Management, Q1 2016. Forester, March 16, 2016, 17 p.
11. Robinson I., Webber J., Eifrem E. Graph databases. O'Reilly Media, 2nd ed., 2015, 238 p.
12. Сакр Ш. Обработка больших объемов графовых данных: путеводитель по современным технологиям. URL: http:// www. ibm. com/developerworks/ru/library/os-giraph/index.html (дата обращения: 29.07.2016).
13. SAP HANA graph reference. URL: http://help.sap.com/ hana/SAP_HANA_Graph_Reference_en.pdf (дата обращения: 29.07.2016).
14. Shao B., Liu T.-Y., Ma W.-Y., Li Y. Graph engine, May 14, 2015. URL: https://www.microsoft.com/en-us/research/project/ graph-engine/ (дата обращения: 29.07.2016)
15. Graph engine. URL: http://www.graphengine.io/#summary (дата обращения: 29.07.2016).
Software & Systems
DOI: 10.15827/0236-235X.030.1.051-060
Received 01.09.16 2017, vol. 30, no. 1, pp. 51-60
ON AN APPROACH TO CONSTRUCT ASSET MASTER DATA MANAGEMENT SYSTEM
A.A. Sukhobokov1, Ph.D (Engineering), [email protected] V.I. Strogonova2, engineer, [email protected]
1 SAP CIS, Kosmodamianskaya Emb. 52/2, Moscow, 115054, Russian Federation
2 Optimal Management, LLC, Festivalnaya St. 22/6, Moscow, 125581, Russian Federation
Abstract. The paper describes capabilities of current MDM (Master Data Management) solutions and prospects of multidomain and multivector MDM solutions. The paper presents the reasons for which MDM of asset data solutions for single data domain are not used successfully in contrast to the existing MDM solutions for other data domains such as customers, suppliers, products, employees, etc. There are challenges of combining several different representations of the same assets in MDM of asset data solution. The conclusion shows that as long as relevant single-domain MDM of asset data solutions are not developed and not implemented successfully, it is too early to move this subject area to multidomain systems.
To solve the problems described above, the authors propose a model of assets master data, which enable to combine different representations. This model includes multiple independent hierarchies for different representations of the same assets, non-hierarchical links specific for each subject area, grids of links allowing to go between different representations of the same asset, a set of asset classifiers whose classes define sets of attributes for describing assets, classifiers of links between assets, as well as structural and functional models for individual asset types. In order to implement the proposed model of master data on assets, the authors have developed a special architecture of MDM of asset data solution, as well as an algorithm for checking the integrity of links between different representations across the whole data model.
Key requirements are defined to the tools for developing a prototype of MDM of asset data solution. It must provide the functionality of a graph DBMS and at the same time a graph engine to perform complex algorithm on the graph as a whole.
Keywords: MDM solution, master data management of asset data solution, data model, system architecture, links integrity checking algorithm, SAP HANA Graph.
1. Wolter R., Haselden K. The What, Why, and How of Master Data Management. Microsoft Corporation, November 2006. Available at: https://msdn.microsoft.com/en-us/library/bb190163.aspx?f=255&MSPPError=-2147217396 (accessed July 29, 2016).
2. Otto B., Schmidt A. Enterprise Master Data Architecture: Design Decisions and Options. Institute of Information Management, University of St. Gallen, 13 p. Available at: http://mitiq.mit.edu/ICIQ/Documents/IQ%20Conference%202010/ Papers/2B1_EnterpriseMasterDataArchitecture.pdf (accessed July 29, 2016).
3. Barrenechea M.J., Jenkins T. Enterprise Information Management: The Next Generation of Enterprise Software. Open Text Corporation, Waterloo Canada, 2013, 288 p.
4. Magic Quadrant for Master Data Management of Product Data Solutions. Gartner. November 12, 2015, ID:G00271935.
5. Magic Quadrant for Master Data Management of Customer Data Solutions. Gartner. November 11, 2015, ID:G00271783.
6. Management system. Annual report RAO UES, 2006, pp. 26-30. Available at: http://www.fsk-ees.ru/media/File/stock-holders/otchet/decisions/V0SA_otchet/RA0/03_RA0_G0_2006.pdf (accessed July 29, 2016) (in Russ.).
7. Equipment as Units of Tangible Assets. SAP Help Portal. Available at: http://help.sap.com/saphelp_ppm400/helpdata/ en/01/d545f84ab311d189740000e8322d00/frameset.htm (accessed July 29, 2016).
8. Creating an Architectural Object. SAP Help Portal. Available at: http://help.sap.com/saphelp_erp60_sp/helpdata/en/fb/ 5ad0531d8b4208e10000000a174cb4/frameset.htm (accessed July 29, 2016)
9. System of Asset Master Data Management. Optimal Management LLC, Available at: http://optimalmngmnt.com/ page34en.htm (accessed July 29, 2016).
10. The Forrester Wave™: Master Data Management, Q1 2016. Forester, March 16, 2016, 17 p.
11. Robinson I., Webber J., Eifrem E. Graph Databases. 2nd ed., O'Reilly Media Publ., 2015, 238 p.
12. Sakr S. Processing large-scale graph data: A guide to current technology. IBM. Available at: http://www.ibm.com/ developerworks/library/os-giraph/ (accessed July 29, 2016).
13. SAP HANA Graph Reference. SAP HANA Platform SPS 12, Document Version: 1.0 - 2016-05-11, 28 p. Available at: http://help.sap.com/hana/SAP_HANA_Graph_Reference_en.pdf (accessed July 29, 2016).
14. Shao B., Liu T.-Y., Ma W.-Y., Li Y. Graph Engine. Microsoft Research, 2015. Available at: https://www.microsoft. com/en-us/research/project/graph-engine/ (accessed July 29, 2016).
15. Graph Engine. Microsoft. Available at: http://www.graphengine.io/#summary (accessed July 29, 2016).
References
