Поиск

Полнотекстовый поиск:
Где искать:
везде
только в названии
только в тексте
Выводить:
описание
слова в тексте
только заголовок

Рекомендуем ознакомиться

'Документ'
Целью данной работы является ознакомление с законами теплового излучения. Содержание работы состоит в получении зависимости энергии, излучаемой тверды...полностью>>
'Руководство'
Настоящее руководство предназначено для квалифицированного персонала, применяющего трехфазные зарядные устройства Hawker Powertech или LifePlus для за...полностью>>
'Документ'
Образовательные: учить выпускников формулировать проблемы текстов тематического блока «Литература, книги, чтение», коллекционировать аргументы; подгот...полностью>>
'Документ'
Типового Положения о школе - Постановление Правительства РФ от 19.03.2001 г. №196 "Об утверждении Типового положения об общеобразовательном учреждении...полностью>>

Главная > Техническое задание

Сохрани ссылку в одной из сетей:
Информация о документе
Дата добавления:
Размер:
Доступные форматы для скачивания:

Приложение № 5

к Договору №

от « » 2015 г.

Утверждаем:

Заказчик:

Исполнитель:

Руководитель службы информационных технологий – советник Президента

ОАО «НК «Роснефть»

_______________ В.В. Никитин

____________________

М.П.

М.П.

Техническое задание

Система Бизнес-планирования и управленческой отчетности

Содержание

  1. общие сведения об ис

    1. наименование ис

Полное наименование Системы – Система бизнес-планирования и управленческой отчетности на базе программного продукта Oracle Hyperion Planning.

Условное обозначение Системы: СБПУО.

    1. назначение (наименование и код автоматизируемого бизнес-процесса)

Управление процессами бизнес-планирования и формирования управленческой отчетности.

Плановые сроки начала и окончания работ В соответствии с Календарным планом и условиями Договора

    1. Порядок оформления и предъявления заказчику результатов работ

Оформление и предъявление Заказчику результатов работ по внедрению и адаптации программного обеспечения Oracle Hyperion Planning , по изготовлению и наладке отдельных средств (технических, программных, информационных, методических описано в разделе Требования к документированию настоящего ТЗ и должно выполняться в соответствии с Календарным планом и условиями Договора.

    1. Определения, обозначения, сокращения

GUI – визуальный графический интерфейс

OHP – Oracle Hyperion Planning – программное обеспечение, предназначенное для информационно-аналитического сопровождения процессов бюджетного управления.

OFA – Oracle Financial Analyzer

OHPS – Oracle Hyperion Planning System

БД – база данных

БП – бизнес-приложение

ВК – вычислительный комплекс

ГОСТ – государственный отраслевой стандарт

ИБ – информационная безопасность

ИБП – источник бесперебойного питания

ИКСО – Информационный ресурс КИС SAP «Интегрированная корпоративная система отчетности ОАО «НК «Роснефть».

ИС – информационная система

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

КЗ – Контролируемая зона

Компания – группа юридических лиц различных организационно-правовых форм, включая ОАО «НК «Роснефть», в отношении которых последнее выступает в качестве основного или преобладающего (участвующего) общества

Куб – многомерный массив данных, характеризуемый собственным набором измерений, настройками плотности измерений и расчетами. Каждое значение, хранимое в кубе, имеет n координат (и однозначно определяется комбинацией n элементов измерений), где n – число измерений куба

Модель – набор форм и правил, реализующих последовательность ввода данных и расчета группы расходов

МЭ – Межсетевой экран

НСД – несанкционированный доступ

ОАО – открытое акционерное общество

ОГ – общество группы ОАО «НК «Роснефть»

ООО – общество с ограниченной ответственностью

ОПЭ – опытно-промышленная эксплуатация

ОС – операционная система

ПО – программное обеспечение

ПТС – программно-технические средства

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

ПЭ – промышленная эксплуатация

ПЭВМ – персональная электронно-вычислительная машина

СанПиН – санитарные правила и нормы

СБПУО – система бизнес-планирования и управленческой отчетности ОАО «Роснефть» на базе программного продукта Oracle Hyperion Planning

СПД – сеть передачи данных

СТИ – системно-техническая инфраструктура

СТП – системно-техническая платформа

СУБД – система управления базами данных

ТЗ – техническое задание

  1. назначение и цели создания системы

    1. Назначение системы

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

    1. Цели создания системы

Целью проекта является миграция системы бизнес-планирования и управленческой отчетности с платформы Oracle Financial Analyzer на платформу Oracle Hyperion Planning.

Задачами создания СБПУО на платформе Oracle Hyperion Planning являются:

  • Уменьшение длительности и трудоемкости процессов сбора управленческой отчетности;

  • Повышение качества принимаемых управленческих решений;

  • Увеличение гибкости применяемого аналитического аппарата.

  1. Характеристика объекта автоматизации

Объектом автоматизации являются процессы бизнес-планирования и формирования управленческой отчетности.

    1. ОПИСАНИЕ ТЕКУЩЕЙ СИТУАЦИИ

      1. ОПИСАНИЕ СУЩЕСТВУЮЩЕГО БИЗНЕС-ПРОЦЕССА

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

  • Сбор плановых и фактических показателей;

  • Проверка, преобразование, загрузка, хранение;

  • Анализ данных;

  • Выпуск бизнес-плана и отчетности;

  • Согласование/утверждение отчетности;

  • Организация процесса бизнес-планирования в центральном аппарате.

      1. ОПИСАНИЕ СУЩЕСТВУЮЩЕЙ ИНФОРМ. СИСТЕМЫ / ИНФРАСТРУКТУРЫ

На данный момент используется система бизнес-планирования и управленческой отчетности на платформе Oracle Financial Analyzer (OFA).

Основные задачи системы:

  • Хранение данных управленческой отчетности и бизнес-планирования;

  • Генерация отчетов;

  • Предоставление интерфейса для анализа данных.

    1. Существующее программное обеспечение

Процесс бизнес-планирования и формирования управленческой отчетности на текущий момент автоматизирован на базе программного обеспечения Oracle Financial Analyzer (OFA).

    1. Существующие проекты

ИКСО – Интегрированная корпоративная система отчетности – ИР ИКСО КИС SAP. Целью ИР является обеспечение регулярного и своевременного выпуска корпоративной отчетности.

  1. Требования к системе

    1. требования к системе в целом

      1. требования к структуре и функционированию системы

1.a.1.1Требования к характеристикам взаимосвязей создаваемой системы со смежными системами
В рамках текущего проекта не предусмотрена прямая интеграция.
Под синхронизацией в рамках данного документа подразумевается ручная выгрузка (загрузка) из ИС (в ИС) данных оператором.
Необходимо обеспечить возможность ручной загрузки и выгрузки данных из/в СБПУО и ИР ИКСО КИС SAP в виде файлов формата CSV или формата TXT с полями фиксированной длины оператором загрузки. При этом необходимо обеспечить согласованность структур данных ИР ИКСО КИС SAP и СБПУО при выполнении работ по разработке моделей в системе СБПУО для последующего процесса интеграции.
С целью указанной интеграции также необходима синхронизация справочников СБПУО с корпоративными справочниками по набору синхронизируемых полей и форматам файлов обмена данными. Механизмы и процедуры синхронизации указанных справочников должны быть разработаны в ходе проекта, при этом интеграция предполагается с использованием загрузки/выгрузки файлов формата CSV или формата TXT с полями фиксированной длины оператором.

Должна быть предусмотрена возможность загрузки данных из файлов MS Excel установленной структуры. Требования к структуре данных, загружаемых в СБПУО, обусловлены функциональной моделью планирования и формирования управленческой отчетности. Детальные требования к структуре данных загружаемых в СБПУО должны быть определены на Этапе 1. «Реализация».

1.a.1.2Требования к режимам функционирования системы

Для Системы определены следующие режимы функционирования:

  • штатный режим – основной режим функционирования Системы, в котором конечным пользователям доступны все функции Системы;

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

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

  • с 04-00 до 07-00 (работы, проводимые в автоматическом режиме) – ежедневно

  • с 13-00 до 14-00 (работы, проводимые в ручном режиме) – по потребности, при условии предварительного оповещения пользователей

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

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

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

      1. Требования к правам доступа и ролям пользователей

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

Персонал Системы должен подразделяться на две группы:

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

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

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

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

В системе должны быть представлены следующие роли:

  • функциональный специалист (пользователь);

  • администратор модели;

  • системный администратор;

  • администратор безопасности;

  • администратор технической поддержки.

Описание ролей, определенных для конечных пользователей в Системе, приведено в [Таблица ]:

Таблица . Роли конечных пользователей

п./п.

Роль

Краткое описание

1

Функциональный специалист

Сотрудник Компании, вводящий / загружающий финансовые данные в Систему и запускающий стандартные расчёты.

Описание ролей обслуживающего персонала Системы приведено в [Таблица ]

Таблица . Роли обслуживающего персонала

п./п.

Роль

Краткое описание

Администратор модели

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

Системный администратор

Сотрудник Компании, который отвечает в целом за работоспособность серверов Системы и реляционной СУБД и восстановление Системы, но не за настройки программного обеспечения Hyperion Planning.

Администратор безопасности

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

Администратор технической поддержки

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

Допускается присвоение нескольких ролей одному сотруднику. Численность пользователей определяется количеством поименованных лицензий и составляет 25 пользователей.

1.a.1.3Требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков

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

  • Навыки работы с операционными системами Windows.

  • Умение пользоваться прикладными программами, входящими в состав Microsoft Office.

  • Навыки работы с Microsoft Internet Explorer.

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

Схема 2.Функциональный специалист:

    • Знание предметной области;

    • Навыки работы на уровне пользователя со следующими компонентами Системы:

      • Oracle Hyperion Planning;

      • Oracle Hyperion Smart View;

      • Oracle Hyperion Financial Reporting;

      • Oracle Hyperion Web Analysis;

Обслуживающий персонал Системы должен обладать следующими навыками и знаниями (в зависимости от роли обслуживающего персонала):

  1. Администратор модели:

    • знание структуры настроенных приложений Planning;

    • знание назначения и структуры измерений;

    • навыки по внесению изменений в измерения;

    • навыки по созданию и изменению форм данных;

    • навыки создания расчетов в модели: формулы, бизнес-правила, написания формул в Essbase;

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

    • навыки по настройке отчетов:

      • в интерфейсе SmartView с подключением к Essbase;

      • в интерфейсе Financial Reporting Studio;

      • в интерфейсе Web Analysis.

    • знание принципов работы Essbase и процедур по администрированию Essbase (работа с лог-файлами, реструктуризация);

  2. Администратор безопасности:

    • знание принципов ограничения прав доступа Oracle Hyperion Planning;

    • знание интерфейса Shared Services.

  3. Администратор технической поддержки:

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

    • навыки работы с Системой на уровне конечных пользователей.

  4. Системный администратор:

    • навыки по администрированию продуктивного и тестового серверов СБПУО;

    • навыки по оптимизации производительности и параметров Oracle Hyperion Planning;

    • навыки по резервному копированию и восстановлению данных ESSBASE, MS SQL.

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

      1. показатели назначения

СБПУО должна соответствовать следующим показателям назначения [Таблица ]:

Таблица . Показатели назначения

п./п.

Наименование задачи

Целевое значение

1

Длительности и трудоемкости процессов сбора управленческой отчетности

Уменьшение

2

Качество принимаемых управленческих решений

Увеличение

3

Гибкость применяемого аналитического аппарата

Увеличение

      1. Требования к надежности

2.a.1.1Общие требования к надежности

Требования к качеству и безопасности прикладного программного обеспечения (ПО) СБПУО:

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

  2. создаваемое прикладное ПО не должно зависеть от внутренних механизмов и внутренней структуры базового ПО, т.е. должно использовать только внешние интерфейсы базового ПО;

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

Аварийные ситуации, по которым регламентируются требования к показателям надежности Системы:

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

  2. сбой или прекращение электропитания серверного оборудования;

  3. отказ активного сетевого оборудования (коммуникационного оборудования вычислительного комплекса (ВК)).

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

2.a.1.2Требования к надежности Системно-технической платформы

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

  1. среднее/максимальное время восстановления работоспособности Системы после выхода из строя (сбоя) программно-аппаратного обеспечения – 24 часа;

  2. среднее/максимальное время замены элементов оборудования после их выхода из строя - 48/96 часов (не влекущее за собой увеличения среднего/максимального времени восстановления работоспособности Системы согласно пп. 1. данного пункта);

  3. продолжительность работы серверов СБПУО на аварийном энергоснабжении – 15 минут;

  4. суммарное допустимое время простоя – 24 часа в месяц.

Для обеспечения надежности технических средств СБПУО:

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

  2. должна быть обеспечена защита технических средств от кратковременных перебоев в электропитании с помощью источников бесперебойного питания (ИБП);

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

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

  5. активное сетевое оборудование, к которому подключаются критически важные компоненты СТП СБПУО, должно быть полностью дублировано;

  6. подключения критически важных компонентов СТП СБПУО к активному сетевому оборудованию должны быть также дублированы;

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

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

      1. Требования безопасности

Электроснабжение и силовое электрооборудование помещений для СПТ необходимо выполнять по требованиям ПУЭ-2003, ВСН-59-88, а также с учетом ГОСТ 13109-97, ГОСТ Р 51318.24-99, ГОСТ Р 50839 и других нормативных документов РФ по электромагнитной совместимости (ЭМС).

Для СТП сеть электропитания должна быть выделенной и помехозащищенной и выполнена по 5-проводной схеме с типом системы заземления TN-S (ГОСТ Р 50571.20-2000) в магистральной части и по 3-проводной схеме в групповой с использованием розеток с заземляющим контактом.

Помещение должно быть оборудовано средствами пожаротушения в соответствии с НПБ 110-03 автоматическими установками пожаротушения (АУПТ) и пожарной сигнализации (АУПС) и спроектировано в соответствии со СНиП 2.04.09-84. Категория зданий и помещений по взрывопожарной и пожарной опасности определяется в соответствии с НПБ 105-95.

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

Решения, принимаемые в Проекте, должны соответствовать требованиям Санитарных правил и норм (СанПиН) 2.2.2/2.4.1340-03 к персональным электронно-вычислительным машинам (ПЭВМ), помещениям для работы с ПЭВМ, микроклимату, содержанию аэроионов и вредных химических веществ в воздухе на рабочих местах, оборудованных ПЭВМ, уровням шума и вибрации на рабочих местах, освещению на рабочих местах, инфракрасному, ультрафиолетовому, рентгеновскому и электромагнитному излучениям, уровням электромагнитных полей на рабочих местах.

      1. Требования к эргономике и технической эстетике

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

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

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

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

Экранные формы должны проектироваться с учетом требований унификации:

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

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

Схема 5.Внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должны реализовываться одинаково для однотипных элементов.

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

      1. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

Аппаратное и программное обеспечение СТП СБПУО должно обеспечиваться гарантийной поддержкой производителя сроком не менее 12 месяцев с даты начала постоянной эксплуатации.

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

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

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

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

В процессе обслуживания СБПУО Заказчиком должны обеспечиваться:

  1. выполнение требований к надежности, изложенных в настоящем ТЗ, в частности, к требуемому времени восстановления Системы после сбоев, аварий и неисправностей;

  2. выполнение требований регламентов обслуживания и ремонта ПТС, BT, принятых в организации Заказчика в части непротиворечащей п. Требования к надежности Системно-технической платформы;

  3. предоставление доступа к СБПУО;

  4. выполнение работ по учету и управлению оборудованием, системным ПО;

  5. использование стандартного ПО Oracle при обслуживании и поддержке пользователей в процессе эксплуатации Системы для обеспечения:

  • своевременной инсталляции обновлений ПО компании Oracle;

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

  • проактивной диагностики ландшафта, элементов СТП, СУБД и бизнес-процессов пользователей;

  • выполнения работ по управлению инцидентами, проблемами и изменениями.

      1. Требования к защите информации от несанкционированного доступа

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

Категория конфиденциальности информации, обрабатываемой в информационной системе – конфиденциальная информация.

Информационная система должна обеспечивать защиту от несанкционированного доступа (НСД) на уровне не ниже установленного требованиями, предъявляемыми к классу защищенности 1Г АС по классификации действующего руководящего документа Гостехкомиссии России «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации» 1992 г.

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

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

Информационная система требует проведения процедуры оценки соответствия требованиям безопасности информации.

Для защиты информации при ее передаче по каналам связи из одной АС в другую необходимо использовать МЭ не ниже класса 4.

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

Доступ к ИС должен осуществляться только с рабочих станций, входящих в состав сегментов сети Компании, аттестованных для обработки информации конфиденциального характера и/или оборудованных персональными комплексами защиты информации ПКЗИ-КТ.

Передача конфиденциальной информации (файлы с данными для загрузки и т.п.) должна осуществляться с использованием ПО «ViPNet «Деловая почта», входящего в состав ПКЗИ-КТ-ДП.

      1. Требования по сохранности информации при авариях

Средствами ВК СБПУО должна быть обеспечена гарантированная сохранность всех данных, хранимых на серверах и системах хранения СБПУО, в том числе, следующих типов:

  1. прикладные данные:

  • исходные данные, включая все их модификации (например, результаты округления и расчета показателей);

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

  1. системные данные:

  • системное программное обеспечение и конфигурационные наборы данных;

  • программное обеспечение, таблицы, конфигурационные файлы и журналы систем управления базами данных (СУБД);

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

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

  1. повреждение электропитания;

  2. выход из строя микропроцессорного оборудования;

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

  4. физическое повреждение носителей информации, находящихся в эксплуатации;

  5. злоумышленные действия.

Сохранность информации в этих случаях должна обеспечиваться за счет:

  1. централизованного хранения информации на отказоустойчивом оборудовании систем хранения данных, резервного копирования и восстановления данных СБПУО;

  1. реализации принципа избыточности хранения информации;

  2. программных решений по обеспечению целостности баз данных при сбоях в проведении транзакций;

  3. организации бесперебойного электропитания серверов, входящих в состав или взаимодействующих с СБПУО.

Комплекс мер по обеспечению сохранности информации и ее восстановлению должен включать в себя:

  1. проведение регулярного регламентного копирования баз данных (БД);

  1. проведение внепланового резервного копирования БД;

  2. хранение резервных копий в разных помещениях с техническими средствами (серверами, активным сетевым оборудованием и т.п.);

  3. восстановление БД из резервных копий;

  4. исключение несанкционированного доступа к резервным копиям.

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

      1. Требования к защите от влияния внешних воздействий

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

Специальные требования по защите от влияния внешних воздействий не предъявляются.

      1. Требования к патентной чистоте

Проектные решения СБПУО должны отвечать требованиям по патентной чистоте согласно действующему законодательству Российской Федерации.

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

      1. Дополнительные требования

5.a.1.1ИСТОРИЧНОСТЬ

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

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

5.a.1.2ЗАГРУЗКА ДАННЫХ

Загрузку текстовых файлов, полученных из форм сбора данных от ОГ Заказчика в формате MS Excel, должна осуществлять с помощью Essbase Rule Files. Массовая (многопоточная) загрузка большого количества текстовых файлов должна быть реализована с помощью запускаемой из бизнес-правила Java-функции, которая загружает файлы в Систему из заданного репозитория через Rule Files.

Система должна обеспечивать возможность загрузки файлов в MS Excel с ведением пользователем мэппинга данных на структуру внутренней модели.

5.a.1.3КОНСОЛИДАЦИЯ ДАННЫХ С УЧЕТОМ ДОЛЕЙ ВЛАДЕНИЯ

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

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

5.a.1.4РАБОТА ПОЛЬЗОВАТЕЛЕЙ ЧЕРЕЗ СВОДНОЕ ПРИЛОЖЕНИЕ

В Системе должно быть реализовано сводное приложение. Данное приложение должно содержать все измерения со всеми элементами и не должно содержать данных. При обращении пользователя к этому приложению необходимые данные должны с помощью механизма Hyperion Essbase «Transparent Partition» динамически подтягиваться из приложений, в которых они физически хранятся, в запрошенный пользователем отчёт. При этом данные, запрошенные конечным пользователем для просмотра, должны браться с утверждённого сценария (для разных приложений утверждённый сценарий может быть различным), который задаётся администратором Системы в свойствах механизма Partition с помощью переменной.

5.a.1.5СОГЛАШЕНИЕ ОБ ОФОРМЛЕНИИ РАСЧЕТОВ

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

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

  1. Бизнес-правила и формулы на элементах должны быть прокомментированы:

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

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

    3. Оператор FIX должен быть построен по маске:

FIX (

Измерение1 /* Название измерения1 */

Измерение2 /* Название измерения2 */

Измерение3 /* Название измерения3 */

)

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

    2. Перед каждым сложным расчетом необходимо описать его назначение и механизм реализации.

  1. Бизнес-правила и функции должны быть иерархически выделены знаками табуляции или пробелами:

    1. Код внутри конструкции Элемент() выделяется табуляцией.

    2. Код внутри каждого оператора IF выделяется дополнительной табуляцией.

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

5.a.1.6ТРЕБОВАНИЯ К ДОСТУПНОСТИ И ПРОИЗВОДИТЕЛЬНОСТИ СИСТЕМЫ

Режим работы продуктивной системы – 24х7

Тестирование производительности системы будет проводиться на примере формуляра в MS Excel. Предполагаемый размер формуляра - это 700-1000 строк, 200-240 столбцов, 40-50 страниц. Тестирование должно осуществляться на системе, содержащей данные за 3 года. Один год  - это 50 формуляров по 100 ОГ по 10 сценариям.

Требования к производительности компонентов системы приведены в таблице ниже:

Операция

Максимальное значение, мин.

Объем данных операций

Загрузка данных одного формуляра из файла в формате CSV

3

1 ОГ 1 формуляр 1 сценарий

Пересчет показателей формуляра в системе

5

1 ОГ 1 формуляр 1 сценарий

Обновление (чтение) данных отчета в MS Excel, соответствующего формуляру

0,25

1 страница

Обновление (чтение) данных отчета в MS Excel, соответствующего формуляру

5

Все страницы

Обновление (чтение) данных отчета в Web, соответствующего формуляру

0,5

1 страница

Копирование данных

60

Все ОГ 1 формуляр 1 сценарий

5.a.1.7ТРЕБОВАНИЯ К ПЕРЕНОСУ (МИГРАЦИИ) ДАННЫХ

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

    1. Требования к АВТОМАТИЗАЦИИ и функциям (задачам), выполняемым системой

      1. Перечень функций СБПУО

В Таблица перечислены основные функции создаваемой СБПУО и их описание.

Таблица . Перечень функций, реализуемых в Системе

Код

Наименование функции

Описание функции

  1. Предоставление интерфейсов для работы с данными

Загрузка данных из файлов формата CSV или формата TXT с полями фиксированной длины

Наличие механизма массовой обработки и загрузки в СБПУО файлов формата CSV или формата TXT с полями фиксированной длины, выгружаемых из шаблонов MS Excel.

Представление данных через формы ввода

Возможность внесения плановых данных через формы ввода, реализованные в СБПУО.

Ввод данных, а также осуществление других операций в СБПУО с использованием Web-браузера

Должно быть реализовано удаленное подключение к СБПУО для работы с финансовыми данными, а также выполнения других операций с использованием тонкого клиента (Web-браузера).

Ввод и просмотр данных с использованием MS Excel интерфейса

Должно быть реализовано удаленное подключение к СБПУО для работы с финансовыми данными с использованием интерфейса MS Excel.

Возможность ввода данных при разрыве соединения с сервером в интерфейсе MS Excel

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

Поддержка специальных функций ввода данных

СБПУО должна поддерживать следующие функции при вводе данных:

  • корректировка значений (как в абсолютном, так и в относительном выражении);

  • распределение вводимых данных;

  • копирование данных (как в рамках одной формы, так и между формами);

  • копирование данных из/в MS Excel;

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

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

Реализуются следующие виды проверки:

• проверка расчетных ячеек на соответствие определенному значению

• вывод дополнительных вспомогательных форм в текущем окне

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

СБПУО должна поддерживаться возможность создавать комментарии для ячеек данных.

Использование функции drill-down по иерархиям

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

Использование контекстного меню для перехода на связанные формы

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

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

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

Инструкции к формам ввода

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

  1. Сбор, хранение и обработка данных в необходимой детализации

Детализация данных по справочникам

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

Организация хранения данных БД по аналитическим кубам

Для хранения финансовых данных в базе данных должны быть организованы кубы данных.

Возможность хранения в СБПУО вспомогательной информации

СБПУО должна поддерживать централизованное хранение вспомогательных документов. Документы в хранилище загружаются пользователями СБПУО или администратором.

Агрегация данных по иерархиям справочников

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

Расчет данных по бюджетам

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

Консолидация данных с учетом долей владения

Автоматический расчет консолидационных значений с учетом долей владения.

Обеспечение целостности данных для конечных пользователей

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

Историчность справочников

СБПУО должна обеспечивать возможность поддержания историчности справочников – для возможности построения различных отчетов и использования различных формульных механизмов для отдельных наборов данных (например, для разных сценариев).

Возможность план-факт анализа

СБПУО должна предоставлять проведения план-факт анализа, путём сопоставления фактических и плановых данных

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

Формирование итоговой отчетности заданного формата

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

Формирование аналитической отчётности и возможность изменять параметры отчета

Должны быть настроены формы аналитической отчётности.

На сформированных отчетах у пользователя должна быть возможность менять срез данных, сворачивать/разворачивать выведенные на таблицу статьи по иерархии

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

  • переходы по иерархиям;

  • создание аналитических вычислений;

  • ранжирование;

  • сортировка;

  • условное форматирование

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

Возможность использования дополнительных инструментов формирования отчётности

У пользователей СБПУО должна быть возможность использования дополнительных инструментов формирования аналитической отчётности с помощью специального ad-hoc анализа.

  1. Предоставление средств управления доступом к данным

Поддержка работы с группами пользователей

Права доступа к объектам СБПУО должен быть организован на основе групп пользователей. В СБПУО должна поддерживаться вложенность групп и наследуемость прав доступа.

Определение функциональных ролей пользователей

Доступ к функциям СБПУО должен разграничиваться на основе функциональных ролей пользователей (администратор модели, стандартный пользователь, интерактивный пользователь, финансовый контролёр и т.д.).

Разграничение доступа к отдельным объектам СБПУО

Должен быть организован доступ пользователей к определенным объектам СБПУО стандартными средствами ПО. Организация прав доступа должна предусматривать следующие категории доступа:

  • доступ к логическим объектам системы: формам, отчетам, папкам хранилища данных;

  • доступ к запуску расчетов.

Разграничение доступа к данным

Доступ к данным СБПУО должен поддерживаться на двух уровнях: доступ на чтение и доступ на запись - и определяться путем разграничения доступа к отдельным элементам справочников.

  1. Предоставление инструментов администрирования и поддержки модели

Обновление аналитических справочников

Должно поддерживаться редактирование администратором модели аналитических справочников с использованием стандартной функциональности ПО.

Встроенные инструменты администрирования

СБПУО должна иметь инструменты централизованной настройки, доступные администратору модели.

      1. ПЕРЕЧЕНЬ МОДЕЛЕЙ

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

Таблица . Перечень моделей

Наименование модели

Примерное количество строк

Примерное количество столбцов

Примерное количество листов

Детализация в формуляре

1. ВСЕМ Бизнесам 

 

 

 

 

CAPEX

890

2

2

 

2. НПЗ (NPZ)

 

 

 

 

Экономика НПЗ

706

128

3

 

Пр-во НПЗ (Мощности)

27

34

28

 

CAPEX-дет НПЗ

283

43

1

 

Баланс Масел

31

23

28

 

Товарный баланс катализаторов

31

17

28

 

1-П (пр-во нефтепродуктов)_НПЗ

839

39

65

 

3. НПО (NPO)

 

 

 

 

Экономика НПО

1500

50

15

 

Пр-во НПО

110

14

1

 

Прочая деят. НПО

170

14

1

 

CAPEX-ext_НПО

320

72

1

 

Баланс НПО

630

250

14

 

4. НГД (NGD)

 

 

 

 

Экономика НГД

2210

170

18

 

PL НГД

500

170

5

 

затраты НГД

600

170

5

 

транспорт НГД

40

170

1

 

ремонты НГД

400

170

5

 

энергия НГД

270

170

1

 

РЗП+Бенчмаркинг

400

170

1

 

Геология НГД

100

119

1-200

Месторождения

Бурение НГД

480

119

1-200

Месторождения

Пр-во НГД

750

119

1-200

Месторождения

CAPEX-M НГД

210

252

1-200

Месторождения

CAPEX ТРИЗ НГД

210

252

1-200

Месторождения

ТБ НГД

150

93

3-30

 

Цел. прогр. НГД

100

16

31

 

Проч. деят. НГД

60

17

1

 

Механизированная добыча НГД

290

31

1

 

Энергетика НГД

640

168

3

 

5. ГРР (GRR)

 

 

 

 

Экономика ГРР

660

31

32

 

PL ГРР

440

31

1

 

Затраты ГРР

220

4-25

31

Проекты

План финансирования ГРР

80

31

1-50

Проекты

6. Сервис (SERVICE)

 

 

 

 

Экономика (сервис)

840

252

1-25

Филиалы/Контрагенты

Пр-во (сервис)

1510

31

1

 

7. Прочие доч. общества (OTH_DO)

 

 

 

 

Экономика (прочие ДО)

190

180

1

 

8. РН-Карт (Сервис НПО)

 

 

 

 

Экономика (сервис НПО)

1500

1

15

 

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

Реализованные на новой платформе вычисления должны обеспечивать возможность расчета всех показателей и объектов, которые использовались в старой системе (например, расчетные показатели карточек, сводные объекты планирования по МСФО и др.).

      1. ТРЕБОВАНИЯ К ДАННЫМ

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

  • Оптимизация производительности за счет исключения из кубов неиспользуемых измерений. Каждый куб должен характеризоваться своим набором измерений;

  • Логическое разделение;

  • Разделение полномочий по доступу к данным части модели

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

Таблица . Возможная структура справочников OHP

Наименование

Описание измерения

примерное количество элементов

Year (Год)

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

15

Period (Период)

Обязательное измерение. Содержит справочник периодов для целей планирования (планирование по кварталам и месяцам).

17

Scen (Сценарий)

Обязательное измерение. Содержит различные варианты сценариев (план, факт и т.п.).

4

PeriodType (Тип периода)

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

5

Unit (Подразделение)

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

1200

BU

(Бизнес-единица)

Дополнительное измерение. Содержит справочник Бизнес-единиц месторождений/инвестиционных программ и т.д..

1000

Account (Показатели)

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

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

  • HRLN (HR)

  • CPLN (НГД, capex-ext)

  • CPLN (НПЗ, capex-дет)

  • CPLN (capex-m)

  • CAP (capex)

  • PLNU (Бурение)

  • PLNU (Геология)

  • PLNU (Производство)

  • PLEL_10 (НПЗ, PL)

  • PLLU_NPZ (НПЗ, PL)

  • PLLU (НГД, PL)

  • PLLU_SALE (НПО, PL)

  • PLLU, PLOP, PLEL (РН-Бурение, PL)

  • SBAL (НПО, баланс)

  • PLND (НПО, производство)

  • PRPR (НПО, прочая деятельность.)

  • PLNP (НПЗ, производство)

  • PLOP (НГД, PL)

  • PLEL (НГД, PL)

  • PLRM (НГД, PL)

  • PLTR (НГД, PL)

  • BAL (НГД, ТБ)

  • BLPR (1-П)

  • PLLU (ГРР, экономика)

  • PLOP (ГРР, экономика)

  • CAP_F (ГРР, ПФ)

  • PLLU (ДЗО, экономика)

4000

Prod (Продукция)

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

  • ACTD

  • GRM

  • NPZPRD

  • PRDC

  • SRV

  • CAP (capex-ext, capex-m)

100

Counterpart (Контрагент)

Дополнительное измерение. Содержит справочник контрагентов.

100

ServiceType (Вид сервиса)

Дополнительное измерение. Содержит справочник видов сервиса.

TBD

LOB (Вид бизнеса)

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

TBD

STR (Участки, затраты)

Дополнительное измерение. Содержит справочник участков и типов затрат.

TBD

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

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

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

      1. ТРЕБОВАНИЯ К СПРАВОЧНИКАМ

Справочник Unit (Подразделение) должен синхронизироваться с корпоративным справочником «Единый унифицированный периметр» (ЕУП) аналитика 95 информационного ресурса ИКСО КИС SAP.

Справочник BU (Бизнес-единица) должен синхронизироваться со справочником ИР ИКСО КИС SAP «97 Бизнес-единицы».

Справочник Counterpart (Контрагент) должен синхронизироваться с Корпоративным справочником контрагентов ИР ИКСО КИС SAP.

Механизмы и процедуры синхронизации указанных справочников должны быть разработаны в ходе проекта, при этом бесшовная интеграция с корпоративными справочниками и системами, в которых они ведутся, не предполагается. Справочники из необходимых систем должны загружаться в СБПУО с использованием файлов передачи данных в формате MS Excel или в формате CSV или TXT с полями фиксированной длины при участии оператора.

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

  1. Одно измерение может содержать несколько справочников модели, использование которых для описания данных одновременно не возможно;

  2. Для разделения справочников в одном измерении создаются отдельные иерархии;

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

Элементы всех измерений OHP должны обладать двумя обязательными атрибутами: имя элемента (неизменяемый код) и псевдоним (изменяемое название, с которым работают конечные пользователи системы).

На имена и описания элементов измерений OHP накладываются следующие ограничения:

  1. Максимальная длина имени и псевдонима любых элементов равна 80 символам.

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

  3. Запрещено использовать HTML-тэги в именах и псевдонимах.

  4. Запрещено использовать следующие символы в именах и псевдонимах:

  1. двойные кавычки ( “ ” );

  2. квадратные и фигурные скобки ( [ ] { } );

  3. обратные и прямые слеши ( \ / );

  4. знаки табуляции ( ).

  1. Имена и псевдонимы не должны начинаться или заканчиваться пробелом.

  2. Имена и псевдонимы должны начинаться либо с буквы алфавита, либо с цифры.

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

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

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

      1. ТРЕБОВАНИЯ К НАЛИЧИЮ ОТЧЁТОВ

Подрядчик должен обеспечить настройку отчетов Oracle Hyperion Planning по требованиям Заказчика.

Отчеты должны быть представлены в виде форматированных отчетов в формате MS Excel. Отчеты должны быть построены на базе всех разработанных моделей и должны поддерживать автоматическое обновление данных.

Форматы отчетов будут переданы Подрядчику в виде Excel-документов.

Отчеты должны покрывать все настроенные модели.

Требования к количеству отчетов:

  • Отчеты, реализумые с помощью инструмента Financial Reporting – не более 20

  • Всего отчетов не более 50.

Требования к отчетам будут определены на этапе концептуального проектирования.

    1. Требования к видам обеспечения

      1. Требования к информационному обеспечению системы

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

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

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

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

      1. Требования к лингвистическому обеспечению системы

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

      1. Требования к программному обеспечению системы

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

Функциональные возможности ПО должны обеспечивать реализацию требований к функциям, выполняемым СБПУО.

Для реализации СБПУО должно быть использовано следующее ПО:

  • Основное ПО - Oracle Hyperion (далее – Hyperion Planning);

  • Вспомогательное ПО.

Перечень Основного ПО приведен в [].

Таблица . Перечень основного ПО СБПУО

Наименование

Назначение

Роль в архитектуре «клиент-сервер»

Oracle Hyperion EPM Architect 11.1.2.4

Инструмент для управления приложениями Hyperion Planning (создание и настройка приложений, справочников и расчетов).

Серверная часть

Oracle Essbase 11.1.2.4

Многомерная СУБД, предназначенная для хранения данных в многомерной модели.

Серверная часть

Essbase Administration Services 11.1.2.4

Серверная часть Essbase для управления моделями данных и вычислениями.

Серверная часть

EAS Console 11.1.2.1

Клиентская часть Essbase для управления моделями данных и вычислениями.

Для работы использует сервис Essbase Administration Services.

Клиентская часть (администратор модели)

Oracle Hyperion Planning 11.1.2.4

Основное программное обеспечение, с которым взаимодействует пользователь. Обеспечивает управление процессом формирования отчетности, настройками запросов к многомерной СУБД Essbase для ввода/вывода данных.

Серверная часть

Oracle Hyperion Smart View 11.1.2.4

Клиентская часть для обеспечения доступа к приложению Hyperion Planning через MS Excel.

Клиентская часть (все пользователи)

Oracle Hyperion Financial Reporting 11.1.2.4

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

Клиентская часть используется для построения отчетов.

Серверная часть

Клиентская часть (администратор модели)

Oracle Hyperion Foundation Services 11.1.2.4

Набор служб для управления настройками безопасности, обеспечения единой точки доступа к прикладному уровню Подсистемы бюджетного управления (через web-браузер), обеспечения интеграции с продуктами MS Office.

Серверная часть

Oracle HTTP Server

Веб-сервер, предназначенный для обработки http-запросов от клиентских частей программного обеспечения, кроме EPM Architect и MS SSRS.

Серверная часть

Oracle WebLogic 11.1.2.4

App-сервер. Программный сервер для развертывания Java-приложений.

Серверная часть

Web Analysis 11.1.2.4

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

Серверная часть

Состав вспомогательного ПО определяется требованиями вендора. Источником указанных требований является документ Oracle Hyperion EPM System Certification Release 11.1.2.1 Перечень необходимого вспомогательного ПО Подсистемы бюджетного управления приведен в Таблица .

Таблица . Перечень вспомогательного ПО СБПУО

Наименование

Назначение

Роль в архитектуре «клиент-сервер»

Windows Server 2008 R2 64x Standard Edition

Операционная система.

Серверная часть

MS SQL Server 2008 R2

Реляционная СУБД, предназначенная для хранения настроек и метаданных Hyperion Planning.

Серверная часть

Client MS SQL Server 2008

Клиентская часть для доступа к СУБД, устанавливается на серверах, где не установлена реляционная СУБД или на рабочих станциях системных администраторов.

Клиентская часть (системный администратор)

Java Development Kit 1.6.0 14+

Обеспечивает работу с EAS Console через веб-интерфейс.

Клиентская часть (администратор модели)

7-Zip или аналог

Программа архивирования файлов.

Серверная часть

MS Internet Explorer 7.x

MS Internet Explorer 8.x

MS Internet Explorer 9.x

Предназначен для обеспечения доступа к приложениям Hyperion Planning через Web.

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

разрешение на выполнение скриптов приложений Java;

запуск элементов ActiveX и модулей подключения;

разрешение файлов cookie;

разрешение всплывающих окон.

Клиентская часть

MS Excel 2003 / 2007 SP2 / 2010

MS Word 2003 / 2007 SP2 / 2010

MS PowerPoint 2003 / 2007 SP2 / 2010

MS Outlook 2003 / 2007 SP2 / 2010

Предназначен для обеспечения работы с приложениями Hyperion Planning с использованием MS Office.

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

Клиентская часть (все пользователи)

Acrobat Reader 11.0+ (актуальная, используемая в Компании версия)

Предназначен для обеспечения работы с Hyperion Financial Reporting.

Клиентская часть (все пользователи)

      1. Требования к техническому обеспечению

Техническое обеспечение системы должно максимально и наиболее эффективным образом использовать существующие у Заказчика технические средства.

ВК СБПУО должен быть размещен в городе Москве на площадке, предоставленной Заказчиком.

Технические средства должны быть объединены одной локальной сетью, с пропускной способностью не менее 100 Мбит/с.

С целью обеспечения непрерывного процесса эксплуатации продуктивной системы и консистентного обновления функциональности СБПУО системный ландшафт должен включать в себя две среды для каждой из компонент СБПУО:

  1. Тестовая среда – предназначенная для проведения тестирования любых изменений в Системе после ввода Системы в промышленную эксплуатацию. Все функции Системы реализуются в тестовой среде в полном объеме. Функции тестовой среды не представляют ценности с точки зрения конечных пользователей системы;

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

Технология виртуализации допустима для всех серверов Системы. При использовании виртуализации должны быть обеспечены указанные ниже параметры серверов. Для виртуализации вендор Oracle рекомендует использовать VM Oracle. В случае использования ПО VMware, возникают ограничения, связанные с поддержкой: «устраняются только ошибки, для которых уже известно, что они могут происходить на используемой ОС, либо может быть продемонстрировано, что они не являются результатами работы на VMware»1.

Рекомендуемые параметры серверов и распределение программного обеспечения по ним приведены в [Таблица ]. Выделение двух серверов многомерных баз данных позволит распределить нагрузку приложений Essbase между данными серверами. Объединение служб Hyperion и реляционной базы данных MS SQL Server никак не повлияет на производительность, так как нагрузка на эти компоненты значительно меньше, чем на модуль Essbase.

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

Таблица . Рекомендуемые параметры серверов

Назначение сервера

ПО к установке на сервер

Минимальные ключевые параметры сервера

Тестовый сервер

ОС: Windows Server 2008 R2 64x Standard Edition

БД: MS SQL Server 2008

Прикладное ПО: Oracle EPM System (все компоненты)

Вспомогательное ПО:

  • MS IIS Web Server

  • 7-Zip или аналог

  • Adobe PDF Reader

Процессор: Intel Xeon, 4 ядра

RAM: 32 Гб

Дисковый массив: 200 Гб

Продуктивный сервер приложений и реляционных БД №1

ОС: Windows Server 2008 R2 64x Enterprise EditionБД: MS SQL Server 2008

Прикладное ПО:

  • Oracle HTTP Server

  • Oracle WebLogic

  • Oracle Foundation Services

  • Reporting and Analysis Framework

  • Reporting and Analysis Web Application

  • Oracle Hyperion Planning

  • Calculation Manager

  • Oracle Hyperion EPM Architect

  • Essbase Administration services

  • EAS Console

  • Provider Services

  • Financial Reporting

  • Web Analysis

Вспомогательное ПО:

  • MS IIS Web Server

  • 7-Zip или аналог

  • Adobe PDF Reader

Процессор: Intel Xeon, 16 ядер

RAM: 24 Гб

Дисковый массив: 100 ГБ (раздел #1, под ОС и ПО Oracle) + 100 ГБ (раздел #2, под файлы реляционной базы данных и хранилище отчетов Hyperion) + + 100 Гб (раздел #3 - общий диск под кластер MS SQL Server)

Продуктивный сервер приложений и реляционных БД №2

ОС: Windows Server 2008 R2 64x Enterprise Edition

БД: MS SQL Server 2008

Прикладное ПО:

  • Oracle HTTP Server

  • Oracle WebLogic

  • Oracle Foundation Services

  • Reporting and Analysis Framework

  • Reporting and Analysis Web Application

  • Oracle Hyperion Planning

  • Calculation Manager

  • Oracle Hyperion EPM Architect

  • Essbase Administration services

  • EAS Console

  • Provider Services

  • Financial Reporting

  • Web Analysis

Вспомогательное ПО:

  • MS IIS Web Server

  • 7-Zip или аналог

Adobe PDF Reader

Процессор: Intel Xeon, 16 ядер

RAM: 24 Гб

Дисковый массив: 100 ГБ (раздел #1, под ОС и ПО Oracle) + 100 ГБ (раздел #2, под файлы реляционной базы данных и хранилище отчетов Hyperion) + 100 Гб (раздел #3 - общий диск под кластер MS SQL Server)

Продуктивный сервер многомерных БД №1

ОС: Windows Server 2008 R2 64x Enterprise Edition

Прикладное ПО:

  • Essbase Server

Вспомогательное ПО:

  • 7-Zip или аналог

Процессор: Intel Xeon, 24 ядра (рекомендуется 2 x Intel® Xeon® Processor E5-2697 (12 ядер, 2.70 GHz)

RAM: 96 Гб

Дисковый массив: Дисковый массив: 100 ГБ (раздел #1, под ОС и ПО Oracle) + 800 ГБ (раздел #2, общий диск под кластер многомерной базы данных)

Продуктивный сервер многомерных БД №2

ОС: Windows Server 2008 R2 64x Enterprise Edition

Прикладное ПО:

  • Essbase Server

Вспомогательное ПО:

  • 7-Zip или аналог

Процессор: Intel Xeon, 24 ядра (рекомендуется 2 x Intel® Xeon® Processor E5-2697 (12 ядер, 2.70 GHz)

RAM: 96 Гб

Дисковый массив: Дисковый массив: 100 ГБ (раздел #1, под ОС и ПО Oracle) + 800 ГБ (раздел #2, общий диск под кластер многомерной базы данных)

Сервер резервного копирования

ОС: Windows Server 2008 R2 64x Standard Edition

Процессор: Intel Xeon, 2 ядра

RAM: 32 Гб

Дисковый массив: 400 Гб

  1. состав и содержание работ

Состав работ по внедрению и адаптации программного обеспечения Oracle Hyperion Planning и сроки их выполнения приведены в Календарном плане к договору.

    1. Требования к организации работ.

Должны выполняться следующие требования:

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

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

  • По каждой встрече с представителями Заказчика Руководителем проекта от Подрядчика должен составляться фиксирующий документ (Протокол встречи).

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

  • Проект осуществляется согласно Методическим указаниям ОАО «НК «Роснефть» «Оформление и согласование документации КИС по вводу ИС в промышленную эксплуатацию/регистрации ИР для промышленной эксплуатации». Руководитель  проекта от Подрядчика организует создание документации согласно указанным выше требованиям  и участвует в её согласовании. Шаблоны документации и информация о процессе предоставляются Заказчиком.

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

  1. Порядок контроля и приемки системы

    1. Виды, состав, объем и методы испытаний системы

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

Система должна пройти приемочное тестирование, последовательность проведения и входные данные для которого должны быть подготовлены на Этапе 1 «Реализация» и отражены в рабочем документе «Концепция проведения тестирования».

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

п.п.

Результат

Критерий приемки результата

1

Этап 1. Реализация

1.1.

Реализация функционала

  • Устав проекта

  • План работ

  • Концептуальный дизайн

  • Спецификация на настройку Доработанный технический проект

  • Реестр отчетов и формуляров с классификацией по инструментам реализации

  • Регламент ведения основных данных

  • Концепция проведения тестирования

  • Тестовые сценарии (для видов тестирования, определенных в документе «Концепции проведения тестирования»)

2

Этап 2. Тестирование

2.1.

Тестирование системы

  • Протокол тестирования системы (для видов тестирования, определенных в документе «Концепции проведения тестирования»)

  • Реестр и график устранения замечаний (в случае выявления замечаний)

  • Протокол устранения замечаний (в случае выявления замечаний).

  • Доработанный пакет документов согласно методическим указаниям ОАО «НК Роснефть» оформление и согласование документации КИС по вводу ИС в промышленную эксплуатацию/регистрации ИР для промышленной эксплуатации (необходимость доработки будет определена в процессе реализации).

  • Стратегия миграции данных.

  • Концепция поддержки пользователей в период опытно-промышленной эксплуатации

3

Этап 3. Проведение ОПЭ

3.1

Опытно-промышленная эксплуатация

  • Протокол миграции исторических данных

  • Журнал и протокол устранения замечаний в период ОПЭ

    1. Требования к тестированию системы

Проведение тестирования должно удовлетворять следующим требованиям:

  • в рамках предварительных испытаний выполняются следующие виды тестирования:

    • функциональное тестирование;

    • интеграционное тестирование;

    • нагрузочное тестирование;

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

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

Ключевые пользователи проводят тестирование в рамках своего организационного и функционального объема;

  • нагрузочное тестирование проводится проектной команды Подрядчика при контроле техническими специалистами ООО «РН-Информ» после завершения функционального и интеграционного тестирования. Нагрузочное тестирование проводится для определения соответствия производительности системы требованиям к времени выполнения основных групп функций путем эмулирования (при необходимости) специализированным программным обеспечением одновременной работы заявленного числа пользователей системы и взаимодействия со смежными системами. Для проведения нагрузочного тестирования Заказчик (при необходимости) предоставляет программно-техническую среду. По результатам нагрузочного тестирования Подрядчик формирует предложения по оптимизации производительности системы, а также могут быть предъявлены требования о необходимости внесения корректировок в сделанные настройки/разработки и о повторе предварительных испытаний в тех частях, к которым возникли замечания при проведении нагрузочного теста

  • детальные критерии приемки результатов испытаний и классификация ошибок определяются в рамках разработки концепции проведения тестирования;

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

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

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

  • по окончании каждого вида тестирования представители Подрядчика и Заказчика составляют протокол тестирования системы;

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

  1. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

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

  1. Определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение приемочного тестирования ИС;

Схема 6.Обеспечить присутствие пользователей на обучении работе с системой, проводимом Исполнителем;

Схема 7.Обеспечить соответствие помещений и рабочих мест пользователей системы в соответствии с требованиями, изложенными в настоящем ТЗ;

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

Схема 9.Совместно с Исполнителем подготовить план развертывания системы на технических средствах Заказчика;

Схема 10.Провести приемочное тестирование и опытно-промышленную эксплуатацию ИС.

  1. Требования к документированию

Состав и комплектность документации определяется Исполнителем и согласовывается с Заказчиком ОАО «НК «Роснефть». Документация СБПУО не должна противоречить руководящим и нормативным документам федерального уровня, требованиям документов ОАО «НК «Роснефть», а также требованиям настоящего ТЗ.

Состав проектной и эксплуатационной документации, выпускаемой по результатам проведения работ, приведен в Таблица .

В процессе выполнения работ по внедрению и адаптации программного обеспечения Oracle Hyperion Planning состав документации может уточняться по согласованию между Исполнителем и Заказчиком ОАО «НК «Роснефть».

Документация, указанная в Таблица , выпускается и утверждается в двух экземплярах (первый – для Заказчика, второй – для ИсполнителяИсполнителя).

Документация выпускается на бумажных носителях и электронных носителях. Электронная копия комплекта документации передается на CD-R диске (дисках). Диск должен быть защищен от записи; иметь надпись с указанием изготовителя, даты изготовления, названия комплекта. В корневом каталоге диска должен находиться текстовый файл содержания. Состав и содержание диска должно соответствовать комплекту документации. Каждый физический раздел комплекта (том, книга, альбом графических изображений и т.п.) должен быть представлен в отдельном каталоге диска файлом (группой файлов) электронного документа. Название каталога должно соответствовать названию раздела.

Таблица . Состав проектной и эксплуатационной документации

Название документа

Требования к документу

Ответственный за формирование/актуализацию

Устав проекта

Требуется; Язык: русский

Подрядчик

План работ

Требуется; Язык: русский

Подрядчик

Техническое задание (настоящий документ)

Требуется; Язык: русский

Подрядчик

Технический проект

Требуется доработка; Язык: русский

Подрядчик

Концептуальный дизайн

Требуется; Язык: русский

Подрядчик

Реестр отчетов и формуляров с классификацией по инструментам реализации

Требуется; Язык: русский

Подрядчик

Регламент ведения основных данных

Требуется; Язык: русский

Подрядчик, Заказчик

Регламент предоставления доступа

Требуется; Язык: русский

Подрядчик

Технический паспорт ИС

Требуется; Язык: русский

Подрядчик

Руководство администратора

Требуется; Язык: русский

Подрядчик

Руководство пользователя

Требуется; Язык: русский

Подрядчик

Концепция обучения

Требуется; Язык: русский

Подрядчик

График проведения обучения

Требуется; Язык: русский

Подрядчик

Протоколы проведения обучения

Требуется; Язык: русский

Подрядчик

Руководство по обеспечению непрерывности бизнеса

Требуется; Язык: русский

Подрядчик

Спецификация на настройку/Спецификация на разработку

Требуется; Язык: русский

Подрядчик

Концепция проведения тестирования

Требуется; Язык: русский

Подрядчик

Тестовые сценарии (для видов тестирования, определенных в документе «Концепции проведения тестирования»)

Требуется; Язык: русский

Подрядчик

Протокол тестирования системы (для видов тестирования, определенных в документе «Концепции проведения тестирования»)

Требуется; Язык: русский

Подрядчик

Реестр и график устранения замечаний (в случае выявления замечаний)

Требуется; Язык: русский

Подрядчик

Протокол устранения замечаний (в случае выявления замечаний)

Требуется; Язык: русский

Подрядчик

Стратегия миграции данных

Требуется; Язык: русский

Подрядчик

Протокол миграции исторических данных

Требуется; Язык: русский

Подрядчик

Журнал и протокол устранения замечаний в период ОПЭ

Требуется; Язык: русский

Подрядчик

Концепция поддержки пользователей в период опытно-промышленной эксплуатации

Требуется; Язык: русский

Подрядчик

  1. Требования к подрядчику

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

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

• Лицензия на деятельность по разработке и (или) производству средств защиты конфиденциальной информации

• Лицензия на деятельность по технической защите конфиденциальной информации.

• Лицензия на осуществление разработки, производства шифровальных (криптографических) средств, защищенных с использованием шифровальных (криптографических) средств информационных и телекоммуникационных систем

• Лицензия на осуществление распространения шифровальных (криптографических) средств

• Лицензия на осуществление технического обслуживания шифровальных (криптографических) средств

Исполнитель обязан подтвердить свою квалификацию следующими сертификатами сотрудников:

• CISSP (не менее 1 специалиста);

• CISA (либо эквивалентных: CEH, OSCP) или BSI ISO 27001 Lead Auditor (не менее 1 специалиста).

Допускается наличие одного специалиста имеющего оба сертификата: CISSP и CISA (или CEH, или OSCP, или BSI ISO 27001 Lead Auditor).

1 Перевод с англ. оригинального текста с официального сайта Oracle: “Oracle will only provide support for issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware” (Support Position for Oracle Products Running on VMware Virtualized Environments [ID 249212.1]).



Похожие документы:

  1. Бизнес-планирование и инвестирование учебник для экономических специальностей высших учебных заведений

    Учебник
    ... В БИЗНЕС-ПЛАНИРОВАНИИ 260 14. КОНТРОЛЛИНГ В СИСТЕМЕ БИЗНЕС-ПЛАНИРОВАНИЯ 278 ... раньше, а задание рассчитано на ... простых рисков: технических, управленческих, финансовых, экологических ... внутренней оперативной отчетности); анализ эффективности системы внутреннего ...
  2. Техническое задание настоящее техническое задание на оказание услуг в области управления ...

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

    Рабочая программа
    ... , технические и экологические. Дисциплина «Бизнес-планирование» ... организации системы бизнес-планирования в ... достижению заданной рентабельности. ... : бухгалтерская отчетность предприятия; ... Делегирование в системе управленческих действий. Бизнес-инжиниринг. ...
  4. Техническое задание Определение и согласование объемов и состава работ Определение состава отчетных документов

    Техническое задание
    ... постановке системы управленческого учета в Компании. 1. Разработка и согласование технического задания Подэтапы ... бизнес-модели управленческой отчетности компании и разработка «Положения об управленческой отчетности». Положение об управленческой отчетности ...
  5. Системы качества: Системы управления качеством1. Назначение, цели и задачи систем качества. Эволюция

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

Другие похожие документы..