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

· Предварительные испытания

· Опытная эксплуатация

· Приемочные испытания

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

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

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

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

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

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

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

Реализация данного уровня в хранилище данных, предполагает создание ДСО-объекта, оптимизированного для записи данных.

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

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

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

Как правило реализуется в виде стандартного ДСО-объекта.

Уровень планирования и отчетности, содержит объекты для построения BEx-запросов.

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

Перед внедрением проекта SAP BW, необходимо составить документ, регламентирующий правила наименования вновь создаваемых объектов в системе. Уникальное имя объекта системы должно позволять определять слой в хранилище данных, на котором используется данный объект. Пример наименования объектов в соответствии с архитектурой LSA описан в статье [19,20].

2.1.3 Моделирование архитектуры LSA в системе SAP BW

Для моделирования процесса загрузки транзакционных данных используется архитектура LSA, в SAP BW для реализации разделения слоев (уровней) модели данных используются инфоисточники и трансформации. На Рис. 4 показано расположение инфоисточников и трансформаций в потоке загрузки данных. Инфоисточник изолирует инфопровайдер, для возможности вставки трансформации, которая в зависимости от уровня хранилища является фильтром качества или выполняет обогащение данных или позволяет вставить код для дополнительной обработки данных в соответствии с правилами бизнес-логики.



Рис. 4. LSA инфоисточники

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

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

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

· Поле с отметкой о происхождении данных, метку исходной системы

· Поле с датой загрузки данных, заполненного на основе константы SY-DATUM в момент выполнения в среде SAP

· Поле с временем загрузки, на основе поля SY-UZEIT

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

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

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

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

2.1.4 Учет особенностей при построении хранилища данных

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

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

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

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

Рекомендации для целей данных

В соответствии с рекомендацией SAP для верного проектирования временных зависимостей в хранилище данных необходимо включать дополнительные зависимые объекты [21]. Например, в случае, когда ДСО-объект в соответствии со спецификацией на разработку содержит признак 0CALDAY, то он также должен содержать следующие инфо-объекты:

* 0CALDAY

* 0CALWEEK

* 0WEEKDAY1

* 0CALMONTH

* 0CALMONTH2

* 0CALQUARTER

* 0CALQUART1

* 0HALFYEAR

* 0CALYEAR

2.2 Практическая реализация хранилища данных

2.2.1 Передача данных по показателю 1 и 2

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

Рис.5. Поток данных от источника до уровня гармонизации

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

Копирование данных в инфокуб исходных показателей происходит последовательностью копирования, построенной на уровне агрегации ULV_F0102 «Показатель 1». Уровень агрегации содержит только необходимые аналитики для копирования данных на вышестоящий уровень. В признаках есть Версия данных, Инфо-провайдер, Объект мониторинга, Перерабатывающие комплексы, Показатели. Объекты показаны на Рис. 7



Рис. 6. ABAP код экстрактора для подсчета проектной мощности установок переработки УВ

Рис. 7. Уровень агрегации для копирования данных показателя 1

Разберем папку признаки на Рис. 7, описывающие показатель 1: Версия данных - признак, содержащий информацию о версии в которой происходит планирование, прогнозирование или передача фактических значений. Инфо-провайдер - признак, содержащий инфокуб из которого скопированы значения. Объект мониторинга - методологическое поле, показывающее принадлежность данного показателя к классу некоторых объектов. Перерабатывающие комплексы - это названия физических заводов, на которых находятся установки, осуществляющие переработку газообразных УВ. Показатели ХД на базе ПЭ - признак, содержащий методологический ключ, позволяющий однозначно идентифицировать данный показатель. В данной работе используется упрощенное наименование «Показатель 1», на самом деле это набор числовых комбинаций, разделенных точкой формата «#.###.#.#.###», где знак «#» цифра от 0 до 9 в зависимости от положения относительно точек позволяющий дополнительно классифицировать показатели, относящиеся к одному типу. Способ формирования значений - признак, влияющий на математический способ правил суммирования значений показателя в момент агрегирования. Статус данных - аналитика, являющаяся меткой для аудита данных, чтобы отличить проверенные ответственным пользователем данные «APP» от сохраненных данных пользователем «NEW». Тип данных - признак, содержащий информацию о том, что это за значение, например, план, факт или прогноз.

На Рис. 7 рассмотрим папку показатели: Величина показателя ХД содержит число, которое относится к мощности установок, собственно это число мы и передаем в хранилище данных и это же число будет отображаться в отчетности, показываться на информационных панелях для руководства компании. Значимость нуля - показатель, содержащий информацию о том, как отображать 0, имеет ли этот ноль значение для бизнеса и следует ли выводить это значение отдельной строкой в отчете. По умолчанию в базах данных и системах типа SAP BW строка, содержащая 0 как показатель, не должна выводиться в отчет это позволяет избежать вывода дополнительных строк в отчет, чтобы дополнительно отчет не «разрастался» строками, содержащими нулевые значения.

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

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

2.2.2 Сбор данных по показателю 1 и 2

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

В случае с показателем 1 данные вносятся в таблицы через интерфейс создания объектов процесса переработки. При появлении новой установки вместе с общими данными, такими как название, краткое наименование, класс объекта переработки в таблицы системы вносится информация по проектной мощности установки переработки. Интерфейс ведения мощности объектов показан на Рис. 8 приведены тестовые данные

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



Рис. 8 Интерфейс ведения мощности установки

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

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

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

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



Рис. 9. Графическое представление потока данных для загрузки из файла

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



Рис. 10. Поток данных для загрузки показателя 2

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

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

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

Для автоматизации сбора данных создана цепочка загрузки, шаги цепочки показаны на Рис.11 цепочка загрузки для актуализации показателя 2

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



Рис.11. Цепочка загрузки для актуализации данных показателя 2

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

Рис. 12 Поток данных в модуле "аналитика"

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

2.3 Аудит данных перед передачей в хранилище

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

Данный механизм реализован следующим образом: пользователь заходит в исходную систему и форму, содержащую необходимый показатель. Затем пользователь сверяет данные, сформированные исходной системой и в случае согласия с сформированным значением нажимает кнопку «Блокировать», в этот момент на уровне исходной системы происходит копирование данных из статуса «NEW» в статус «APP». Форма аудита показателя представлена на Рис. 11.

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

Рис. 13. Форма аудита показателя 1

Форма аудита содержит кнопки для управления статусом данных, передаваемых в хранилище. Рассмотрим описание основных влияющих на готовность к передаче в ХД значений, представленных на форме аудита. Итак, пользователь открыл форму с заданными параметрами, убедился в корректности отображаемых данных в ERP - системе, и если пользователь согласен с данными, автоматически сформированными в системе, то он нажимает кнопку «Копировать из» в этот момент происходит копирование данных из поля «Факт П1» в поле «Факт ХД». При этом данные физически находятся в системе источнике, но данным присваивается статус «NEW». На этом этапе для показателя 1 возможно ручное редактирование, например, в том случае, когда большая часть значений, предоставленных автоматически его устроила, а одно или два значения он желает ввести вручную с целью добавления информации, которой он обладает уже на этапе аудита данных. Возможность редактирования данных возможна только в статусе «NEW». Далее нажимается кнопка «Сохранить данные» данные сохраняются все еще в исходной системе. Если пользователь готов передать данные в ХД, то он нажимает кнопку «Блокировать в» в этот момент данным, отображенным в столбце «Факт ХД» присваивается статус «APP». Статус данных «APP» означает, что данные прошли аудит и готовы к передаче в ХД.

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

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

Рис. 14. Вкладка верифицированные показатели

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



Рис. 15. Цепочка загрузки из ERP-системы в хранилище данных

2.4 Хранилище данных для показателя 3

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



Рис. 16. Окно входа в ERP-систему

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



Рис. 17. Интерфейс ведения данных по показателю

1. Необходимо ввести табельный номер работника

2. Выбрать вкладку «Временные данные»

3. Выбрать инфо-тип «Местонахождение работника»

4. В области «Период» установить индикатор в положение «Период» и указать даты, за которые вводится местоположение работника

5. Нажать кнопку «Создать»

Далее открывается экран ввода местонахождения работника. На котором необходимо внести данные в предложенную форму. Экран ввода данных местонахождения работника показан на Рис. 16.



Рис. 18. Экран ввода данных местонахождение работника

В красной области на Рис. 16, необходимо заполнить предлагаемые поля, причем поле «Вид отсутствия» является обязательным. Список для данного поля является ограниченным, перечень всего справочника показан на Рис. 17.

Рис. 19. Допустимые значения справочника "Вид отсутствия"

1.1 Поле для ввода кода страны пребывания

1.2 Поле для ввода город местонахождения (необязательное поле)

1.3 Номер телефона заполняется в формате +79999999999

1.4 При необходимости вводится комментарий для описания ситуации (необязательное поле)

2. После ввода данных необходимо нажать кнопку в виде дискеты «Сохранить»

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

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

Физически в ERP-системе данные сохраняются в плоской таблице P9206 Виды отсутствия, которая содержит поля, приведенные в Таблице 3.

Таблица 3 Описание полей таблицы E070 (таблица экрана ведения P9206) Виды отсутствия

Поле	Название	Тип данных
AWART	Вид отсутствия	NUMC 2
LAND1	Код страны	CHAR 2
CITY	Город	CHAR 60
TELNR	Телефон	CHAR 12
COMM	Комментарий	CHAR 255
TEMPER	Температура	FLTP 8

На основании имеющихся данных напишем спецификацию на разработку экстрактора ZTABLEE070, который будет возвращать все записи в таблице E070 (таблица экрана ведения P9206) Виды отсутствия, а экстрактора назовем ZTABLEE070 Виды. Интерфейс создания экстрактора показан на Рис. 18

Рис. 20. Интерфейс просмотра экстрактора

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

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

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

На выходе источника данных создается инфоисточник и трансформация «штампирование». На уровне извлечения создается ДСО-объект оптимизированный для записи, который представляет из себя таблицу с определенным алгоритмом загрузки данных. Между трансформацией «штампирование» и ДСО-объектом создается инфоисточник. Далее на уровне корпоративной памяти создается второй ДСО-объект оптимизированный для записи в который копируются данные из ДСО-объекта с уровня извлечение данных. Тип ДСО-объекта показан на Рис. 19

В примере показателя 3 ДСО-объект на уровне корпоративной памяти будет иметь структуру полей, показанных на Таблице 3 аналогично структуре источника данных в исходной системе. На выходе из ДСО-объекта уровня корпоративной памяти инфоисточник с трансформацией «фильтр качества».



Рис. 21 ДСО-объект. Тип объекта хранилища - прямая запись

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

Следующий шаг -- это создание стандартного ДСО-объекта на уровне распределения данные, загружаемые в этот объект, проходят через трансформацию «Обогащение/Бизнес логика». В случае с показателем 3 обогащение может производится за счет привязки имени сотрудника к табельному номеру, выгружаемому из исходной системы. Таким образом, руководитель, имеющий полномочия на запуск отчета, содержащего информацию о количестве сотрудников с инфекцией COVID-19, может увидеть имя сотрудника и запросить дополнительную информацию о состоянии его здоровья.

Далее на уровне планирования и отчетности создается инфокуб «детальные данные» в который копируются данные с уровня распределения.

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

Копирование происходит через использование технологии интегрированного планирования. Создается последовательность планирования. Интерфейс создания последовательности планирования показан на Рис. 21

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



Рис. 22 Выбор последовательности планирования

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



Рис. 23 Просмотр кода функции планирования

2.5 Формирование карт выгрузки

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

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

* Инфо-провайдеры

* Мультипровайдеры

* Признаки

* Показатели

* Инфоисточник

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

· изменение системно-технических средств, повлекших изменений и технических характеристик каналов коммуникаций

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

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

· Регистрация через портал самообслуживания

· Регистрация через механизм, заложенный в системе SAP GUI

· Регистрация по электронной почте

· Регистрация по телефону

· Регистрация по почте

· Регистрация по факсу

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

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

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

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

Глава 3. Методика интеграции ERP-систем и хранилища данных

3.1 Методика интеграции

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

Таблица 4. Условные обозначения объектов

Обозначение	Описание
	Источник данных
	PSA (временная область хранения данных)
	Инфоисточник
	DSO-объект
	Трансформация
	Инфокуб
	Мультипровайдер
	Поток данных
	Включение инфопровайдеров в мультипровайдер
	Условная граница между уровнями многоуровневой масштабируемой архитектуры (LSA)
	Зона ответственности команды ХД на базе ПЭ
	Зона ответственности команды исходной системы

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

3.1.1 Интеграция при наличии SAP BW (первый сценарий)

Основные шаги интеграции, когда в исходной системе установлен модуль SAP BW

· Определение данных в исходной системе и списка показателей, передача которых планируется в целевую систему

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

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

ѕ Источник данных содержит все поля, доступные в исходной системе

ѕ Создание стандартного ДСО - объекта на уровне распределения

ѕ Не создавать инфоисточники между уровнем распределения и уровнем планирования и отчетности

ѕ Инфокуб с агрегированными данными должен содержать данные с требуемым уровнем гранулярности данный инфокуб является основой для последовательностей планирования BI-IP,

ѕ Создание мультипровайдера, для построения отчетности по переданному показателю эффективности, в этот мультипровайдер включить инфокуб с детальными данными

На Рис. 19, приведено графическое представление сценария, с учетом внедренного модуля SAP BW в исходной системе.



Рис. 24. Первый сценарий интеграции с учетом внедренного модуля SAP BW

3.1.2 Интеграция при отсутствии SAP BW (второй сценарий)

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

Основные шаги сценария интеграции при загрузке показателя 3

· Определение показателей для передачи в хранилище данных

· Выбор и настройка типа соединения RFC между исходной и целевой системой

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

· Создание в хранилище данных BW-объектов для потока данных загрузки с учетом разделения на уровни(слои) в целевой системе

ѕ LSA инфоисточники на входе и выходе из временной области хранения PSA

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

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

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

ѕ Не создавать инфоисточники между ДСО слоя распределения и инфокуба с детализированными данными для слоя планирования и отчетности

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

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

На Рис. 20 в графическом виде представлена методика загрузки данных по второму сценарию

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



Рис. 25. Второй сценарий интеграции, без модуля SAP BW в исходной системе

3.2 Оценка эффективности примененной методики

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

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

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

Заключение

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

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

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

Список использованной литературы

1. Советов Б.Я., Цехановский В.В., Чертовской В. Д. Базы данных: теория и практика. Учебник для бакалавров. - М.: Юрайт-Издат, 2012 - 463 с

2. НОУ ИНТУИТ| Управление развитием информационных систем - Электрон. журн. - Режим доступа: https://www.intuit.ru/studies/courses/532/388/info, свободный (дата доступа 05.03.2020)

3. Jan L.G. Dietz Enterprise Ontology Theory and Methodology. Springer

4. BW305 Построение запросов и анализ в SAP Business Warehouse 2011

5. Альтемер С. «Курс BW310 SAP BW - Организация корпоративных хранилищ данных SAP Net Weaver» Изд. SAP, Руководство для преподавателя, 2006. 567 с.

6. BW370 SAP BW - Интегрированное планирование 2011 Изд. SAP, 2006 479 c.

7. Грекул В. И., Исаев Е. А., Моргунов А. Ф. Информационные системы и средства поддержки коллективной работы. Издательская группа "Логос", 2019 - 535 с.

8. Степанов Д.Ю. Перспективные направления развития корпоративных информационных систем на примере программных решений компании SAP // Аспирант и соискатель. - 2013. - т.78, №6. - c.168-172. http://stepanovd.com/science/19-article-2013-1-prospect. (дата доступа 05.04.2020)

9. Шемсединов Т. Интеграция информационных систем Электрон. журн. - Режим доступа: свободный https://habr.com/ru/post/117468/ (дата доступа 05.04.2020)

10. Gartner «How to Define and Run a Successful Business Intelligence Competency Center», August 2007

11.Лондон Дж., Лондон К. Управление информационными системами. / Пер. с англ. под ред. Трутнева Д.Р. - СПб.: Питер. 2005

12. Кусов А.А Проблемы интеграции корпоративных информационных систем. // Управление экономическими системами: электронный журнал. - 2011 - т.28, №4

13. О'Лири Д. ERP-системы. - М.: Вершина. 2004.

14. Шеннон К. Работы по теории информации и кибернетики. - М.: Информационная литература. 1963.

15. Stepanov D.Yu., Bikashov I.D. Evolution of russian ERP-systems market // Fundamental problems of radioengineering and device construction - 2016. - vol.16, №1. - p.244-247. - http://stepanovd.com/science/35-article-2016-2-ruserp. (дата доступа 05.03.2020)

16. Олейник П.П. Корпоративные информационные системы: учебник для вузов. - СПб.: Питер, 2012 -175 с.

17. Тоноян С.А., Высочанский В.А. Методика проектирования корпоративного хранилища данных на базе платформы SAP Net Weaver Business Warehouse // Вестник МГТУ им. Н.Э. Баумана. Сер. Приборостроение. 2016. № 4. C. 33-48.

18. Хаупт Ж. Многоуровневая масштабируемая архитектура (LSA). SAP NetWeaver, RIG BI EMEA, 2009. 43 с.

...