Программные продукты и системы

Целями применения существующих систем управления мастер-данными (MDM-систем) являются формирование и поддержка консистентного, функционально полного и актуального представления основных данных, отражающих все нюансы структуры и деятельности предприятия. Наличие и поддержка такого единственного содержательного представления мастер-данных является критическим фактором для достижения бизнес-целей предприятия. MDM-системы представляют собой инструментарий для поддержки процессов управления мастер-данными в масштабе предприятия на основе принятых руководящих документов, политик и стандартов [1, 2]. С точки зрения принадлежности программных продуктов к прикладному или платформенному ПО MDM-системы входят в состав платформы и являются неотъемлемой частью комплекса систем управления информацией в масштабах предприятия (Enterprise Information Management) [3].

Системы управления мастер-данными об активах как подкласс систем управления мастер-данными

Ведущая мировая аналитическая компания Gartner традиционно ежегодно выпускает два неза- висимых аналитических обзора по разным классам MDM-систем. Эта традиция была сохранена и в 2015 году [4, 5]. Системы управления мастер-данными об активах отдельно не рассматриваются в этих обзорах. Они относятся к широкому классу MDM-систем с данными о предметах, и считается, что и на них распространяется обзор [4] (в отличие от MDM-систем с данными о командах, на которые распространяется обзор [5]).

Согласно [4], комплексная стратегия управления мастер-данными охватывает множество предметных областей: клиенты, продукты, материалы, услуги, активы, персонал или команды, поставщики и финансы. Мастер-данные об активах, как и мастер-данные о продуктах, становятся все более критичными в связи с ростом числа публикаций и интереса к Интернету вещей (IoT). Распространение IoT предполагает, что все больше устройств (вещей) обмениваются информацией. Многие из них находятся за пределами зоны действия используемых норм организации и управления информацией, в итоге теряется доверие к такой информации. Управление мастер-данными позволяет снять вопрос о доверии, обеспечить качество и консистентность данных об устройствах, а также данных, получаемых от этих устройств.

Рассматривая проблематику систем управления мастер-данными об активах, необходимо ответить на вопрос, что понимается под активом. Ответ не всегда однозначен, и этот термин трактуется разными компаниями по-разному. Практически всегда в понятие активов включаются материальные активы (здания, сооружения, оборудование, земельные участки, строящиеся объекты и т.д.) и их составные части. Несколько реже в понятие включаются нематериальные активы – программные системы, БД, патенты, товарные знаки и т.д. Еще реже в российской практике [6] и более часто в западной в единое понятие активов включаются и финансовые активы – акции, облигации, займы, доли в совместных проектах, векселя и т.д.

Общая численность парка активов в крупных компаниях, таких как OАО «РЖД», НК «Роснефть», может достигать нескольких десятков миллионов единиц. Основную часть такого большого парка (более 90 %), как правило, составляют материальные активы.

Обобщенно рассматривая системы управления мастер-данными об активах как некоторый подкласс MDM-систем о вещах, в [4] также уделяется много внимания перспективам работы MDM-сис­тем с данными более чем одной предметной области (применительно к теме данной статьи – не только с мастер-данными об активах). Наряду c доминирующими сейчас однодоменными MDM-сис­темами, предназначенными для работы с данными одной предметной области (например, с данными о клиентах или о продуктах), пока еще мало распространены, но быстро расширяются сегменты мультидоменных и мультивекторных MDM-систем. Мультидоменные системы предназначены для работы с данными нескольких предметных областей. Несмотря на то, что пользователи хотели бы иметь возможность работать с любыми предметными областями в любом месте и любым способом, существующие мультидоменные MDM-системы ориентированы на одну якорную область данных. В данный момент, согласно [4], мультидоменные MDM-системы – это:

-     MDM-системы для работы с одной предметной областью, имеющие расширенные ссылки на другие предметные области;

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

-     несколько одновременно установленных MDM-систем для разных предметных областей, часто от разных поставщиков, объединенных внешним интерфейсом.

Концепция мультивекторных MDM-систем расширяет понятие мультидоменных MDM-сис­тем. Помимо работы с разными предметными областями, мультивекторные MDM-системы должны работать в разных отраслях, при разных сценариях использования (проектирование структур, операционные или аналитические MDM-системы), для разных организационных структур (централизо- ванная, федеративная, локализованная) и при раз- ных сценариях внедрения MDM-системы (реги- стровая, консолидационная, в режиме сосуществования и централизованная). По прогнозу Gartner [4], мультивекторные MDM-сис­темы сменят мультидоменные и однодоменные не ранее, чем через пять лет.

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

Нерешенные проблемы управления мастер-данными об активах

В существующих корпоративных системах управления в нескольких модулях или подсистемах независимо ведутся мастер-данные о производственных фондах (активах), отражающие различные характеристики одних и тех же объектов. Даже когда разные приложения являются модулями единой ERP-системы, используется такой же подход [7, 8]. Примерная структура основных данных об активах в существующих системах управления крупными компаниями показана на рисунке 1 [9].

Технически это реализуется следующим образом: в разных прикладных подсистемах для ве- дения мастер-данных об активах используются собственные структуры различной сложности и независимые классификаторы объектов. Мастер-данные ведутся разрозненно, хотя и перечень объектов, и значительная доля описывающих объекты характеристик (в том числе паспортных и эксплуатационных) необходимы для работы нескольких приложений. Как следствие, возникает дублирование данных и появляются противоречия между различными представлениями данных. Кроме снижения качества данных, это также увеличивает издержки по сопровождению [9].

В действительности в корпоративных системах имеется намного больше подсистем, в которых используются мастер-данные об активах, чем показано на рисунке 1 [9]. В их число входят данные:

-     об основных средствах (объектах бухгалтерского и налогового учета);

-     об объектах недвижимости;

-     об объектах технического обслуживания и ремонта оборудования;

-     об объектах имущества (правовой аспект);

-     об объектах подсистем мониторинга (пожарной безопасности, видеонаблюдения и др.);

-     об объектах подсистем оперативного управления режимами работы оборудования непрерывных производств, транспорта и связи, коммунального хозяйства;

-     об объектах различных MES и технологических систем управления производством;

-     об объектах геоинформационных систем (визуализируемых на картах);

-     об объектах генерации, передачи и потребления электроэнергии в подсистемах управления производством и потреблением электроэнергии;

-     об объектах добычи, транспортировки и отпуска нефти, нефтепродуктов и газа в подсистемах управления добычей, транспортировкой и сбытом углеводородов;

-     об обрабатывающих центрах и транспортных механизмах в системах технологической подготовки производства (CAM-системах);

-     о складах, распределительных центрах и торговых точках в системах управления розничными сетями.

Перечислим основные причины, по которым системы управления мастер-данными об активах не нашли широкого применения в отличие от MDM-систем для других предметных областей [9].

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

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

3. При функционировании комплексных систем управления пользователям очень часто необходимо видеть смежные представления одного и того же актива. Например, из технологического представления необходимо видеть объекты технического обслуживания и ремонта. Из объектов тех- нического обслуживания и ремонта необходимо видеть основные средства, на которые будут списываться затраты. Из основных средств необходимо видеть соответствующие объекты имущества и т.д. Почти всегда пользователям необходимо видеть объекты нескольких разных представлений. Отсутствие взаимно однозначного соответствия между объектами нижнего уровня различных приложений приводит к появлению связей многие ко многим между объектами разных представлений, описывающими один и тот же актив. Как уже было показано ранее, одному основному средству может соответствовать множество объектов технического учета. Но также справедливо и обратное: одному объекту технического учета, например асфальтированной дороге, может соответствовать множество основных средств, если ее отдельные участки, не являющиеся единицами технического учета, строились (выкупались) по разным ценам или в разное время.

Отсутствие в настоящий момент на рынке системы управления мастер-данными об активах, способной преодолеть перечисленные сложности, подтверждается также обзорами аналитической компании Forester. В первом квартале 2016 года компания выпустила обзор [10], в котором выделила четыре класса MDM-систем и проанализировала продукты двенадцати компаний. Были выделены

-     MDM-системы, обеспечивающие интеграцию данных и решающие стандартные задачи;

-     мультидоменные MDM-системы и MDM-системы, поддерживающие множество представлений мастер-данных;

-     контекстуальные MDM-системы, поддерживающие семантическое представление бизнес-данных;

-     аналитические MDM-системы, интегрированные внутрь аналитических платформ.

Из четырех представленных классов MDM-сис­тем сформулированные проблемы должны решаться в группе мультидоменных MDM-систем и MDM-систем, поддерживающих множество представлений мастер-данных. В качестве лидеров этой группы выделены SAS, SAP и IBM. У этих компаний в настоящий момент нет MDM-систем, способных обеспечить управление мастер-данными об активах в описанном выше ключе.

Предлагаемая модель данных

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

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

Разные ракурсы полиморфны между собой, то есть отсутствует взаимно однозначное соответствие между объектами разных ракурсов.

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

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

Параллельные иерархии разных ракурсов (лес) провязаны на каждом уровне решетками связей для обеспечения переходов между разными ракурсами представления одного и того же актива. Пример такой решетки представлен на рисунке 3.

Решетки необязательно являются полными (то есть необязательно в них присутствуют все связи каждого объекта с каждым). Наличие связей между разными объектами зависит от семантики: нужно устанавливать соотношения между объектами этих ракурсов на данном уровне или нет.

На одном уровне иерархии любого из ракурсов располагается много объектов, каждый из которых связан со своей решеткой смежных объектов.

Решетки одного уровня могут частично совмещаться друг с другом. Это возникает из-за того, что в отдельных ракурсах один объект может соответствовать нескольким объектам другого ракурса, расположенным на одном уровне иерархии (например, одно основное средство может объединять не- сколько единиц оборудования), и тогда решетки смежных объектов одного уровня могут частично соединяться в отдельных ракурсах.

Если рассматривать 3D-модель графа мастер-данных, то решетки на разных уровнях необязательно будут абсолютно параллельными. В отдельных ракурсах один объект может соответствовать нескольким объектам другого ракурса, расположенным на разных уровнях иерархии, и тогда решетки смежных уровней могут соединяться в отдельных ракурсах.

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

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

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

Роль структурных и функциональных моделей в общем механизме управления мастер-данными об активах не ограничивается проверкой правильности вводимых данных. При описании технических ракурсов представления активов в ряде случаев используемая схема соединения компонентов определяет тип объекта, состоящего из этих компонентов. Точно так же тип объекта может зависеть от значений его атрибутов и применяемых функциональных моделей.

Архитектура системы управления мастер-данными об активах

Предлагаемая общая архитектура системы управления мастер-данными об активах представлена на рисунке 5.

Ядро системы поддерживает создание/модификацию и хранение в памяти информационной модели активов.

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

Помимо выгрузки из системы управления мастер-данными, интерфейсные модули также могут обеспечивать загрузку обновленных или новых мастер-данных соответствующих ракурсов из приложений и модулей ERP в систему управления мастер-данными. Однако такая загрузка не обеспечивает использование загруженных данных в системе. Требуется последующее подтверждение загруженных данных от администратора мастер-данных.

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

Алгоритмические модули позволяют выполнить обработку всей модели мастер-данных в целом или отдельных ракурсов. С их помощью может выполняться проверка корректности имеющихся в системе мастер-данных или связей между объектами. Также с их помощью могут выполняться формирование новых ракурсов мастер-данных на основе имеющихся в системе данных других ракурсов и/или на основе внешних данных и другие операции над информационной моделью в целом. Инициирование работы алгоритмических модулей осуществляет администратор мастер-данных через модуль диалогового интерфейса.

Алгоритм проверки корректности межракурсных связей в единой модели активов

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

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

Если предположить, что имеются всего три ракурса активов, решетка принимает вид, представленный на рисунке 6.

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

Обобщим этот подход для сложных многоракурсных структур описания активов. Для обхода всех объектов в иерархии каждого ракурса используем стек, показанный на рисунке 7.

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

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

Пройдя по каждому из колец, необходимо вернуться к первоначальному объекту. Поскольку осуществляется перебор всех связей каждого объекта, автоматически будет реализован просмотр в прямом и обратном направлениях. Дополнительно программировать проход в обратном направлении не требуется.

Чтобы не проверять многократно одни и те же варианты колец связей, начиная с разных объектов, на время выполнения алгоритма вводится разметка связей. Если при обходе колец проходим по какой-то связи и для следующего перехода видим только одну связь, у которой нет отметки, или конец обхода кольца, то ставим на пройденной связи отметку. При дальнейшей проверке проходить по этой связи не нужно. В результате после обхода всех колец, начиная с объектов одного ракурса, если объекты другого ракурса не имеют допол- нительных связей, которые еще не проверялись, обход этих объектов не потребует какого-либо об- хода колец. Обобщенная блок-схема описанного алгоритма представлена на рисунке 9.

Использование полученных результатов при разработке прототипа системы управления мастер-данными об активах

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

1. Инструментарий должен обладать возможностями работы с графовой БД [11]. Это обеспечит существенные преимущества при работе с графами за счет увеличения скорости разработки и сокращения объема кода при обходе цепочек связей по сравнению с традиционным SQL, а также будет требоваться меньше ресурсов для работы прототипа.

2. Инструментарий должен обладать возможностями графовых энджинов [12], выполняющих сложные алгоритмы над большим графом в целом, даже если его фрагменты хранятся на разных сер- верах кластера.

Этим требованиям соответствуют 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/library/bb190163.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/2B1_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/d545f84ab311d189740000e8322d00/frameset.htm (дата обращения: 29.07.2016).

8.     Creating an architectural object. URL: http://help.sap.com/ saphelp_erp60_sp/helpdata/en/fb/5ad0531d8b4208e10000000a174cb4/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).