Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет бизнеса и менеджмента

Выпускная квалификационная работа

МАГИСТЕРСКАЯ ДИССЕРТАЦИЯ

по направлению подготовки Бизнес-информатика

образовательная программа «Бизнес-информатика»

Разработка методики интеграции ERP-систем и хранилища данных в нефтяной компании

Ендальцев Александр Владимирович

Научный руководитель

к. т. н., доцент. А.Ф. Моргунов

Москва

2020

Аннотация

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

Задачами, решаемыми в процессе развития архитектуры хранилища данных, являются

· Создание единой системы для обработки и хранения, необходимой для корпоративного управления компанией

· Исключение дублирования или множественной загрузки данных ранее загруженных в хранилище данных

· Обеспечение возможности анализировать данные на более детальном уровне, для гибкого анализа полученной агрегированной информации

· Улучшение процессов и уменьшение трудозатрат при подготовке данных, снижение трудозатрат на ручной ввод данных

Разработанная методика опробована в нефтяной компании. Использовано два сценария методики в зависимости от наличия в исходной ERP-системе модуля «аналитика». Методика может быть использована на других предприятиях нефтегазовой отрасли, и возможно, на других предприятиях, использующих системы SAP BW.

Данная работа содержит 4 таблицы, 25 рисунков, объем работы составляет 73 страницы.

Ключевые слова

SAP BI, ERP, LSA, отчетность, интеграция, хранилище данных, SAP, многомерная модель данных, витрина данных, OLAP, OLTP, инфокуб.

Оглавление

• Аннотация
• Оглавление
• Перечень сокращений
• Термины и определения
• Введение
• Глава 1. Работа с данными в нефтяной компании
• 1.1 Факторы, влияющие на интеграцию данных
• 1.2 Определение объема работ по созданию хранилища данных
• 1.2.1 Показатель 1 «Проектная мощность установок по переработке газа»
• 1.2.2 Показатель 2 «Объем отгрузки нефтепродуктов»
• 1.2.3 Показатель 3 «Количество сотрудников с инфекцией COVID-19»
• ГЛАВА 2. Создание условий для построения хранилища данных
• 2.1 Требования к системному ландшафту компании
• 2.1.1 Модель хранилища данных
• 2.1.2 Платформа для хранилища данных
• 2.1.3 Моделирование архитектуры LSA в системе SAP BW
• 2.1.4 Учет особенностей при построении хранилища данных
• 2.2 Практическая реализация хранилища данных
• 2.2.1 Передача данных по показателю 1 и 2
• 2.2.2 Сбор данных по показателю 1 и 2
• 2.3 Аудит данных перед передачей в хранилище
• 2.4 Хранилище данных для показателя 3
• 2.5 Формирование карт выгрузки
• ГЛАВА 3. Методика интеграции ERP-систем и хранилища данных
• 3.1 Методика интеграции
• 3.1.1 Интеграция при наличии SAP BW (первый сценарий)
• 3.1.2 Интеграция при отсутствии SAP BW (второй сценарий)
• 3.2 Оценка эффективности примененной методики
• Заключение
• Список использованной литературы
• Приложение 1
• Приложение 2

Перечень сокращений

АРМ	Автоматизированные рабочие места
ВК	Вычислительный комплекс
ГПЗ	Газоперерабатывающий завод
ДСО	Объект в системе, содержащий данные
ЖУВ	Жидкие углеводороды
ИД	Исходные данные
ИС	Информационная система
ЛВС	Локальная вычислительная сеть
ОДС	Объект в системе, содержащий данные
ПО	Программное обеспечение
ПЭ	Показатель эффективности
С/Ф	Счёт-фактура
УВ	Углеводороды
ХД	Хранилище данных
ABAP	Язык программирования
BEx	Инструмент построения запроса к объектам SAP BI
BW	Целевая система загрузки данных для отчета
BI-IP	Business Intelligence - Integrated Planning подмодуль
DIM	Таблица измерений
DSO	Объект в системе, содержащий данные
ERP	Исходная система, содержащая анализируемые данные
LSA	Layered Scalable Architecture масштабируемая архитектура хранилищ данных
MS Excel	Инструмент для работы с электронными таблицами
PSA	Persistent Staging Area, временная область хранения
RFC	Remote Function Call, технология позволяющая передавать информацию между интегрируемыми системами
SAP	Компания поставщик программного обеспечения
SAP BI	Набор инструментов для построения отчетности
SAP BW	Модуль SAP бизнес хранилище
SID	Таблица ключей, сгенерированных информационной системой

Термины и определения

№	Термин	Определение
1.	Хранилище данных	Единая, интегрированная система сбора, обработки и хранения информации, обеспечивающая поддержку процессов управления и формирование управленческой отчетности на показателях.
2.	Бизнес-процесс	Совокупность взаимосвязанных задач (работ), направленных на достижение определенной цели, создание определенного результата (продукта) путем преобразования потребляемых в ходе реализации процесса ресурсов
3.	Показатели эффективности	Показатели (преимущественно удельные и относительные), которые являются наиболее значимыми для оценки эффективности деятельности объектов мониторинга.
4.	Нормативно-справочная информация	Набор непротиворечивых, структурированных и унифицированных данных, описывающих ключевые условно-постоянные объекты, использование которых диктуется требованиями бизнес-процессов
5.	Витрина данных	Срез хранилища данных, представляющий собой массив тематической, узконаправленной информации, ориентированный, на информационную поддержку определенной группы бизнес-процессов, на пользователей одной рабочей группы
6.	Инфо-объект	Обобщающее название признаков и показателей в хранилище данных SAP BW
7.	Инфо-провайдер	Общее название объекта, который можно использовать для создания отчетов в Business Explorer (BEx). Представляет собой объекты (инфокубы; DSO-объекты; инфо-объекты) или ракурсы (мультипровайдеры, инфо-наборы и др.), являющиеся релевантными для системы отчетов. Инфо-провайдеры поставляют данные, которые можно анализировать с использованием запросов в системе Business Information Warehouse (SAP BW).
8.	Мультипровайдер	Логический ракурс физического хранения данных. Мультипровайдер объединяет данные из нескольких инфо-провайдеров и делает их доступными для использования в отчетах. Сам мультипровайдер не содержит данные, используя данные инфо-провайдеров, на которых он основан. Мультипровайдер можно создать из любой комбинации инфо-провайдеров
9.	Инфокуб	Один из типов инфопровайдеров. Инфокуб содержит автономную выборку данных (взятую из отчетности), например, для бизнес сферы. Выборка данных может быть извлечена с помощью запроса BEx. Инфокуб это набор корреспондирующих таблиц, созданных по схеме звезды: Большая фактическая таблица в центре с несколькими расширяющими таблицами вокруг.
10.	DSO-объект	Один из типов инфопровайдеров. DSO-объект содержит консолидированные и очищенные данные на базовом уровне. DSO-объект описывает консолидированную выборку из одного или нескольких инфоисточников. Состоит из ключа (например, номера документа или позиции) и поля данных, которые могут быть текстовыми (например, клиент)
11.	Атрибут	Информационное отображение свойства показателя, которое характеризуется названием, значением или перечнем (диапазоном) возможных значений
12.	SID	Суррогатный идентификатор, автоматически присваиваемый основным данным признаков, после загрузки и активации данных.

Введение

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

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

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

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

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

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

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

Для деятельности компании необходима методика, позволяющая, внедрить ИТ-решение, для оценки эффективности деятельности компании.

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

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

Целью данной работы является разработка методики интеграции ERP-систем и хранилища данных в нефтяной компании.

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

Задачи работы:

· определить факторы, влияющие на интеграцию данных в компании

· разработать сценарий создания хранилища данных на конкретном примере

· разработать структуру хранилища данных

· оценить показатели, для анализа которых будет использоваться хранилище данных

· сформировать методику на примере показателей

Метод исследования обобщение на основе решения прикладной задачи интеграции ERP-систем с хранилищем данных.

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

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

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

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

В случае если в ERP-системе не внедрен аналитический модуль или время разработки потока данных и необходимых объектов превышает время, отведенное на реализацию загрузки конкретного показателя, целесообразно загружать «сырые» данные в хранилище данных, с последующей обработкой этих данных при помощи объектов, созданных в хранилище данных и позволяющих произвести проверки в соответствии с требованиями нормативно справочной информацией (НСИ). Методика данного подхода реализована во втором сценарии.

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

Глава 1. Работа с данными в нефтяной компании

интеграция хранилище данные

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

В свою очередь выполнение самого запроса может занимать значительное время ввиду того, что информационная система в меньшей степени рассчитана на запись данных, чем на считывание. В некоторых случаях запрос к информационной системе может блокировать таблицы на запись и тогда работа в информационной системе остановится [7]. Для решения данной задачи, простым решением было бы создание зеркальной базы данный, с синхронизацией раз в сутки. И запрос для анализа данных в информационной системе можно было бы выполнять на копии, актуальной на вчерашний день, а операционная деятельность продолжалась бы на актуальной информационной системе. Такой подход имеет место, в случае, если информационная система содержит не много данных. Но в компании может быть несколько информационных систем, хранящих разнородные данные, тогда задача усложняется, необходимо иметь такое количество зеркальных систем для запросов пользователя, сколько есть в компании на текущий момент. Возникает вопрос о целесообразности такого мероприятия, ведь в несколько раз возрастают затраты на ежесуточное копирование данных, поддержку актуальности этих зеркальных систем. Непонятно что делать, в случае, когда копирование по какой-то причине не выполнилось. Это усложняет поддержку систем, и затрудняет возможность анализа данных, находящихся в каждой конкретной информационной системе. К тому же остается за рамками данных систем, запросы данные в которых хранятся в разных информационных системах, ведь не всегда удается точно знать находится ли необходимая информация в той или иной информационной системе.

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

1.1 Факторы, влияющие на интеграцию данных

Определим факторы, влияющие на интеграцию [9]:

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

Распределенность. Наличие географической рассредоточения места добычи нефти и места переработки находятся далеко друг от друга.

Гетерогенность. В различных отделах используются разные модули ERP-систем.

Наследственность. Невозможность полностью отказаться от старого аппаратного обеспечения.

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

Обусловленность. Системы ограничены привычками людей, которых необходимо обучить работе с новым функционалом.

Интерактивность. Пользователи системы ожидают быстрый отклик систем.

Мобильность. Возможность использования информации о показателях эффективность работы предприятия на мобильных устройствах.

Безопасность. Соответствие предлагаемой методике интеграции политике безопасности предприятия.

Высоконагруженность. Количество пользователей системы постоянно растет.

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

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

Задача: Интеграция информационных систем, уменьшение количества объектов, физически хранящих данные.

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

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

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

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

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

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

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

1.2 Определение объема работ по созданию хранилища данных

Для создания хранилища данных необходимо выполнить следующий объем работ, таких как:

· Создание рабочей группы

· Проведение обследования текущих информационных систем

· Разработка методологической модели

· Разработка технического задания

· Настройка информационной системы (хранилища данных)

· Обучение пользователей

· Проведение опытной эксплуатации

Цели внедрения хранилища данных:

· Перенос данных в структуры оптимальные для запросов

· Сбор данных из множества ERP-систем

· Снижение нагрузки на ERP- системы

· Возможность использовать OLAP - технологию для построения отчетов

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

1. Получение списка показателей необходимых к передаче в хранилище данных

2. Запрос в отдел методологии сертификата на конкретный показатель

3. Запрос в отдел, ответственный за внесение данных по показателю

4. Разработка алгоритма формирования показателя совместно с отделом методологии и отделом ответственным за предоставление данных по показателю в хранилище данных

a. Если алгоритм по показателю есть, то формирование требованию к написанию ABAP-программы, экстрактора, создания вспомогательных объектов в исходной системе

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

5. Сверка периодичности предоставления данных по показателю с сертификатом показателя, с информацией в отделе и, при необходимости корректировка сертификата показателя, по согласованию с отделом методологии

6. На форме ввода внесение или копирование данных из предварительно сформированных по утверждённому алгоритму значений по показателю

7. Пометка данных (блокировка на стороне исходной системы) к готовности к передаче в хранилище данных

8. Запуск периодической цепочки действий для выгрузки данных по показателю в витрину хранилища данных

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

Рассмотрим действия сотрудников отдела сопровождения исходной системы, в случае, когда алгоритм предоставлен и согласован со всеми заинтересованными подразделениями компании. Создание экстрактора/программы выгрузки данных из таблиц в исходной системе. Сознание внутренних объектов для реализации загрузки данных из программы выгрузки, создание необходимых трансформаций для загрузки данных в инфокуб «транзакционные показатели», проверка наличия мультипровайдера и при необходимости создание на нем уровня агрегации, включающего инфокуб «исходные данные». Создание функций планирования для реализации копирования данных из инфокуба «транзакционные показатели» в инфокуб «исходные данные». Генерация экспортного источника данных на инфокубе «исходные данные».

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

1. Тиражирование экспортного источника данных.

2. Загрузка данных один к одному во временную таблицу хранения.

3. Загрузка из временной таблицы хранения в объект хранения данных (ДСО)

4. Загрузка из объекта хранения через трансформацию с возможностью изменения и дообогащения данных в инфокубе «витрина»

5. Цепочка программ, реализованная на стороне хранилища данных в соответствии с графиком предоставления данных по показателю, проверяет наличие данных в витрине и забирает данные другие объекты хранения (ДСО, инфокуб) для отображения данных в отчетности и информационных панелях для руководства компании

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

Для продуктивной работы и выделения ответственного за некие части работ, выделим роли, список ролей и описание к ним приведены в Таблице 1

Таблица 1 Роли для ответственных за блоки работ

Роль	Описание
Методолог	Один на группу показателей
Архитектор	Планирование и контроль реализации архитектуры SAP BW
Специалист	Один на каждую функциональную область. Обеспечение надлежащего качества транзакционных данных.
Куратор данных	Для каждого объекта основных данных должен быть только один куратор. Данный куратор может отвечать за несколько объектов основных данных. Куратор производит аудит собранных данных подтверждает отправку в ХД

1.2.1 Показатель 1 «Проектная мощность установок по переработке газа»

Рассмотрим пример формирования на примере показателя 1 «Проектная мощность установок по переработке газа». Показатель формируется производственным отделом компании, что накладывает некоторые особенности на способ формирования показателя.

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

В исходной информационной системе при создании новой установки добавляется запись в таблицу в одной из ячеек этой записи указывается число, которое обозначает номинальную мощность установки. Получается, что в системе есть таблица со столбцами Завод, Установка и показателем - номинальная мощность, название таблицы «Установки». К таблице необходимо написать экстрактор (процедура/abap-запрос). Экстрактор возвращает все записи в таблице и загружает эти записи в инфокуб, находящийся в исходной системе. Инфокуб содержит данные обо всех установках, а также данные о том, на каком заводе расположена данная установка и мощность установки. Далее на этом инфокубе, генерируется экспортный источник данных. В целевой системе тиражируем источник данных.

1. В исходной системе на основе инфо-провайдера создаем экспортный источник

2. В целевой системе тиражируем источник

3. Загружаем данные во временную область хранения PSA (Persistent Staging Area)

4. Из PSA 1 к 1 все поля копируем в ODS - Объект хранения данных

5. Из ODS в инфокуб, через трансформацию

6. Над инфокубом строим мультикуб

7. Над мультикубом строим уровень агрегации

8. Над уровнем агрегации строим BEx-запрос

9. Вставляем запрос в книгу MS Excel

10. Форматируем представление запроса в книге

1.2.2 Показатель 2 «Объем отгрузки нефтепродуктов»

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

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

Реализация механизма дельта-загрузки данных через экстрактор для расчета показателя 2, выглядит следующим образом:

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

2. Во временную область загружаются данные экстрактора 1 к 1

3. Создается ДСО-объект для формирования дельта загрузки

4. Создается трансформация для загрузки из временной области хранения в ДСО-объект

5. Создается инфокуб для загрузки транзакционных данных из ДСО-объекта

6. Создается трансформация для загрузки из ДСО-объекта в инфокуб «транзакционные данные»

7. Данный инфокуб включается в мультикуб, содержащий инфокуб «исходные данные»

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

9. Для копирования данных из «транзакционного инфокуба» в инфокуб «исходные данные» создаются последовательности планирования BI-IP (Business Intelligence - Integrated Planning)

10. На стороне исходной системы формируется форма для проверки сформированного показателя 2 и блокирования показателя 2 для передачи в витрину данных

11. Создание цепочки копирования данных показателя 2 в витрину данных на стороне хранилища данных

1.2.3 Показатель 3 «Количество сотрудников с инфекцией COVID-19»

На примере сбора показателя 3 «Количество сотрудников с инфекцией COVID-19» рассмотрим вариант интеграции с ERP-системой, в которой не установлен модуль аналитики и данные хранятся непосредственно в транзакционной системе, там они заводятся вручную при введении данных о больничных сотрудников компании. В нефтяной компании руководством получено указание от государства, являющегося обладателем контрольного пакета акций компании, вести учет по количеству сотрудников с выявленным заболеванием. Особенностью данной ERP-системы, является обработка персональных данных сотрудников компании. Персональные данные сотрудников, хранящиеся в транзакционной системе, не должны передаваться в хранилище данных. Это основное требование информационной безопасности. Поэтому одним из допустимых вариантов является передача табельного номера сотрудника в хранилище данных. С учетом того, что нефтяная компания содержит несколько дочерних обществ, которые ведут кадровый учет персонала, в шаблонных транзакционных системах, сформированных по аналогии с транзакционной системой, но имеющее разное наполнение в связи с тем, что в компаниях работают разные люди. Получается, что данные необходимые для построения показателя 3, находятся в нескольких ERP- системах, построенных хоть и по шаблонному решению, но имеющего некоторые особенности в связи с особенностью ведения учета больничных листов от компании к компании. Руководство дочерних компаний может использовать разные подходы к организации ведения больничных в организации с учетом требований законодательства.

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

1. В исходной системе на основе таблиц пишем запрос и создаем экстрактор, возвращающий данные

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

3. Загружаем данные в PSA - Временную область хранения

4. На выходе уровня PSA создаем инфо источник

5. Создаем трансформацию с присвоением 1 к 1 «Штампирование»

6. На входе ODS создаем инфо источник

7. Загружаем поля в ODS - Объект хранения данных, оптимизированный для записи на уровень извлечения данных/корпоративной памяти

8. На выходе уровня извлечения создаем инфо источник

9. Создаем трансформацию между инфоисточниками, для проверки данных на качество «Фильтр качества»

10. На входе уровня гармонизации создаем инфо источник

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

12. На выходе уровня гармонизации создаем инфо источник

13. Создаем трансформацию для обогащения данными/обработки бизнес логики

14. На входе уровня распределения создаем инфо источник

15. Создаем стандартный DSO в котором происходит перегруппировка данных

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

17. Создаем трансформацию для агрегации и загружаем данные в инфокуб «Витрина данных»: агрегированные данные

18. Копируем данные в инфокуб агрегированные данные

19. Строим мультипровайдер, включающей инфокуб детальных данных, инфокуб агрегированные данные

20. Над мультикубом строим уровень агрегации

21. Над уровнем агрегации строим BEx-запрос

22. Вставляем запрос в книгу MS Excel, или другие инструменты визуализации данных

23. С использованием инструментов визуализации формируем отчет на информационной панели.

Глава 2. Создание условий для построения хранилища данных

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

В нефтяной компании большинство ERP-систем внедрено на основе программного обеспечения, поставляемого компанией SAP. Руководством компании принято решение, что хранилище данных будет основано на технологии SAP BW, доработанной с учетом российского законодательства. Основными инструментами аналитической обработки информации являются BEx-запросы, встроенные в книги MS Excel со специальной надстройкой для работы с инфокубами, основными объектами, хранящими предобработанную информацию для построения аналитических запросов. Инфокуб построен по усовершенствованной технологии схемы «звезда», когда содержится таблица фактов и множество таблиц измерений, в случае технологии SAP BW добавляется еще таблица, хранящая автоматически генерируемый системой суррогатный ключ, который используется для поиска значения в справочнике значений основных данных. Схематичное изображение связи таблиц по схеме «звезда» показано на Рис. 1. В инфокубе содержится таблица фактов (таблица F в терминах SAP), которая через таблицу измерения (DIM) связана с таблицей суррогатных ключей (SID), связанных со справочником аналитик.

Хранилище данных служит для принятия решений и представляет из себя некий неизменяемый набор данных с привязкой ко времени. Цель построения хранилища данных возможность поддержки принятия решений в нефтяной компании. Общая схема потока данных и хранилища данных в нем показана на Рис. 2.



Рис. 1. Схема звезда SAP BW и связь со справочником через SID [47]

Рис. 2. Место хранилища данных в системном ландшафте компании

Исходная система представляет из себя некий набор установленных и определенным образом сконфигурированных модулей. Каждый модуль сконцентрирован на конкретном виде задач и адаптирован под бизнес-процессы компании. Набор некоторых модулей в ERP-системе показан на Рис. 3

Рис. 3. Модули в ERP-системе

2.1 Требования к системному ландшафту компании

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

Все объекты хранилища должны иметь актуальную версию SAP BW, на момент написания работы это BW 7.5

Сами сервера должны содержать актуальную версию операционной системы, в нашем случае это MS Windows Server и базу данных, в нашем случае выбираем Oracle, как историческую базу данных большинства ERP-систем компании.

Сервера должны быть соединены с локальной вычислительной сетью компании.

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

При анализе текущей инфраструктуры компании выявлено несколько характеристик реализации ERP-систем:

· Одновременно используется несколько ERP-систем, с возможностью передачи данных между системами.

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

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

Панируется в рамках разработки методологии, выполнить действия по гармонизации данных в исходных системах или на отдельной витрине данных. Сама ситуация, требующая гармонизации данных, возникла в силу внедрения первоначального создания вертикально интегрированного решения (ВИР) силами сторонних подрядчиков. Планируется создание собственного центра компетенций BI, для консолидированного подхода к решению возникающих разногласий в ходе реализации интеграции в единое хранилище данных.

Задачами, решаемыми в процессе развития архитектуры хранилища данных, являются:

· Создание единой системы для обработки и хранения, необходимой для корпоративного управления компанией

· Исключение дублирования или множественной загрузки данных ранее загруженных в хранилище данных

· Обеспечение возможности анализировать данные на более детальном уровне, для гибкого анализа полученной агрегированной информации

· Улучшение процессов и уменьшение трудозатрат при подготовке данных, снижение трудозатрат на ручной ввод данных

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

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

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

Хранение и сбор данных, предполагается разделить для этого вводится три основных класса данных:

· сырые данные - это данные непосредственно хранящиеся в ERP-системах, из которых происходит выгрузка в хранилище.

· интегрированные данные - приведенные к единому формату, семантике и нормативно справочной информации (НСИ) используемой в хранилище данных

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

2.1.1 Модель хранилища данных

Целевая модель хранилища данных содержит пять слоев (уровней)

Слой 1: Слой извлечения

Слой 2: Слой корпоративной памяти

Слой 3: Слой гармонизации

Слой 4: Слой распределения

Слой 5: Слой планирования и отчетности

Слои хранилища данных необходимы для сохранения классов данных и последующего предоставления данных на уровне приложений. В Таблице 2 приведено краткое описание слоев в терминах LSA.

Таблица 2 Описание функций слоев в терминах LSA

Название	Описание функций
Слой извлечения	начальный уровень, для реализации технических функций. Данные загружаются из исходных ERP-систем, участвующих в интеграции с хранилищем данных. Загрузка данных без изменений позволяет устранить возможные ошибки данных на первом этапе.
Слой корпоративной памяти	содержит историческую информацию о данных, когда-либо загруженных в хранилище данных. Каждая запись хранится постоянно на этом уровне и гарантирует повторное использование записи повторно в будущем.
Слой гармонизации	предполагает очистку данных из различных источников. Предназначен для подготовки данных для интеграции, унифицированных под определенный формат и семантику хранилища данных.
Слой распределения	получает данные с уровня гармонизации и делает из доступными для бизнес-приложений. Этот слой считается «единой версией правды» для приложений. Это означает что каждая запись, отображающаяся в отчете, находится в хранилище.
Слой планирования и отчетности	конечный уровень хранилища данных необходим для построения отчетности, на основе отчетности можно производить необходимое планирование данных. Данный слой технически реализован таким образом, чтобы обеспечивалась высокая производительность при работе с отчетами.

Основными принципами построения архитектуры хранилища данных, являются подробные правила и рекомендации:

· Все объекты хранилища должны соответствовать максимальной версии текущего хранилища данных, там, где это возможно

· Инфопровайдер принадлежит только одному уровню

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

· При загрузке данных запрещено использовать данные из вышестоящих уровней

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

· Все запросы строятся только на мультипровайдерах

2.1.2 Платформа для хранилища данных

Для построения хранилища данных объектами являются Платформы, Данные, Приложения, Бизнес-процессы. Подробно рассмотрим Платформу для хранилища данных.

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

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

В состав Платформы должны входить:

Вычислительный комплекс (ВК), включающий системное программное обеспечение

Локальная вычислительная сеть (ЛВС) и узлы подключения к единой сети передачи данных компании.

Автоматизированные рабочие места (АРМ) для пользователей для работы с системой и специалистов технической поддержки, для обеспечения функционирования Платформы.

Техническая инфраструктура платформы состоит из следующих подсистем:

· хранение данных;

· обработка данных;

· передача данных;

· резервное копирование данных;

· мониторинг и управление.

Платформа функционирует в следующих режимах:

· штатный режим

· аварийный режим

· режим проведения регламентных работ

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

Для аварийного режима, только продуктивные системы.

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

...