Загрузил
janjira
Gigabaza
Gigabaza.ru
Поиск
Полнотекстовый поиск:
Где искать:
везде
только в названии
только в тексте
Выводить:
описание
слова в тексте
только заголовок
Рекомендуем ознакомиться
Конкурс проводится ежегодно с 2005 года, и за все эти годы в нем приняло участие
более 5 000 инноваторов со всех регионов страны. Вэтом году Конкурс представлен в
следующих номинациях
'Конкурс'
АО «Национальное агентство по технологическому развитию» приглашает
принять участие инноваторов и рационализаторов в ежегодном Национальном
конкурсе и...полностью>>
Задачи Конкурса: повышение конкурентоспособности выпускников юзгу на рынке
труда; развитие навыков самопрезентации, разработки индивидуальной карьерной
траектории и формирования личного портфолио
'Конкурс'
1.1. Настоящее Положение определяет порядок организации, методического
обеспечения и проведения внутривузовского конкурса «Лучший выпускник
ЮЗГУ-2016!...полностью>>
Регистрация Абонента с выпуском сертификата открытого ключа без выдачи
носителя ключевой информации для участия в электронных аукционах
'Документ'
с выпуском сертификата открытого ключа без выдачи носителя ключевой
информации для участия в электронных аукционах Услуга 31 417 0 3 83
379 700 Итог...полностью>>
Инструкция по настройке модема zte zxdsl 831 в режиме bridge
'Инструкция'
1. Подготовка модема к работе- Перед началом работы настоятельно
рекомендуется ознакомиться с руководством пользователя, прилагаемого к
модему.- Подкл...полностью>>
Техническое задание Система
Бизнес-планирования и
управленческой отчетности
Главная > Техническое задание
Сохрани ссылку в одной из сетей:
Информация о документе
Дата добавления:
Размер:
Доступные форматы для скачивания:
Скачать
Приложение № 5
к
Догово
ру №
от « »
2015 г.
Утверждаем:
Заказчик:
Исполнитель:
Руководитель службы информационных
технологий – советник Президента
ОАО «НК «Роснефть»
_______________ В.В. Никитин
М.П.
____________________
М.П.
Техническое задание
Система Бизнес-планирования и управленческой отчетности
Содержание
1. общие сведения об ис
1. наименование ис
Полное наименование Системы – Система бизнес-планирования и
управленческой отчетности на базе программного продукта Oracle
Hyperion Planning.
Условное обозначение Системы: СБПУО.
2. назначение
(наименование и код
автоматизируемого
бизнес-процесса)
Управление процессами бизнес-планирования и формирования
управленческой отчетности.
Плановые сроки начала и окончания работ В соответствии с
Календарным планом и условиями Договора
3. Порядок оформления и
предъявления заказчику
результатов работ
Оформление и предъявление Заказчику результатов работ по внедрению
и адаптации программного обеспечения Oracle Hyperion Planning , по
изготовлению и наладке отдельных средств (технических, программных,
информационных, методических описано в разделе Требования к
документированию настоящего ТЗ и должно выполняться в соответствии
с Календарным планом и условиями Договора.
4. Определения,
обозначения,
сокращения
GUI – визуальный графический интерфейс
OHP – Oracle Hyperion Planning – программное обеспечение,
предназначенное для информационно-аналитического сопровождения
процессов бюджетного управления.
OFA – Oracle Financial Analyzer
OHPS – Oracle Hyperion Planning System
БД – база данных
БП – бизнес-приложение
ВК – вычислительный комплекс
ГОСТ – государственный отраслевой стандарт
ИБ – информационная безопасность
ИБП – источник бесперебойного питания
ИКСО – Информационный ресурс КИС SAP «Интегрированная
корпоративная система отчетности ОАО «НК «Роснефть».
ИС – информационная система
Измерение – один справочник или совокупность нескольких
справочников, выступающая в роли аналитического признака для ввода,
хранения и отображения данных
КЗ – Контролируемая зона
Компания – группа юридических лиц различных организационноправовых форм, включая ОАО «НК «Роснефть», в отношении которых
последнее выступает в качестве основного или преобладающего
(участвующего) общества
Куб – многомерный массив данных, характеризуемый собственным
набором измерений, настройками плотности измерений и расчетами.
Каждое значение, хранимое в кубе, имеет n координат (и однозначно
определяется комбинацией n элементов измерений), где n – число
измерений куба
Модель – набор форм и правил, реализующих последовательность ввода
данных и расчета группы расходов
МЭ – Межсетевой экран
НСД – несанкционированный доступ
ОАО – открытое акционерное общество
ОГ – общество группы ОАО «НК «Роснефть»
ООО – общество с ограниченной ответственностью
ОПЭ – опытно-промышленная эксплуатация
ОС – операционная система
ПО – программное обеспечение
ПТС – программно-технические средства
Приложение – представление бюджетной модели либо ее части в OHP.
Представляет собой отдельный объект OHP, включающий в себя
несколько многомерных кубов с данными, собственную настройку прав
доступа пользователей, процесса согласования данных, формы ввода и
отчетности.
ПЭ – промышленная эксплуатация
ПЭВМ – персональная электронно-вычислительная машина
СанПиН – санитарные правила и нормы
СБПУО – система бизнес-планирования и управленческой отчетности
ОАО «Роснефть» на базе программного продукта Oracle Hyperion
Planning
СПД – сеть передачи данных
СТИ – системно-техническая инфраструктура
СТП – системно-техническая платформа
СУБД – система управления базами данных
ТЗ – техническое задание
2. назначение и цели создания
системы
1. Назначение системы
Система бизнес-планирования и управленческой отчетности
предназначена для повышения качества процессов сбора и
формирования управленческой отчетности.
2. Цели создания системы
Целью проекта является миграция системы бизнес-планирования и
управленческой отчетности с платформы Oracle Financial Analyzer на
платформу Oracle Hyperion Planning.
Задачами создания СБПУО на платформе Oracle Hyperion Planning
являются:
Уменьшение длительности и
трудоемкости процессов сбора
управленческой отчетности;
Повышение качества
принимаемых управленческих
решений;
Увеличение гибкости
применяемого аналитического
аппарата.
3. Характеристика объекта
автоматизации
Объектом автоматизации являются процессы бизнес-планирования и
формирования управленческой отчетности.
1. ОПИСАНИЕ ТЕКУЩЕЙ
СИТУАЦИИ
1. ОПИСАНИЕ
СУЩЕСТВУЮЩЕГО
БИЗНЕСПРОЦЕССА
Процессы сбора и обработки данных для формирования бизнес-плана и
управленческой отчетности включают в себя:
Сбор плановых и фактических
показателей;
Проверка, преобразование,
загрузка, хранение;
Анализ данных;
Выпуск бизнес-плана и
отчетности;
Согласование/утверждение
отчетности;
Организация процесса бизнеспланирования в центральном
аппарате.
2. ОПИСАНИЕ
СУЩЕСТВУЮЩЕЙ
ИНФОРМ.
СИСТЕМЫ /
ИНФРАСТРУКТУРЫ
На данный момент используется система бизнес-планирования и
управленческой отчетности на платформе Oracle Financial Analyzer
(OFA).
Основные задачи системы:
Хранение данных управленческой
отчетности и бизнеспланирования;
Генерация отчетов;
Предоставление интерфейса для
анализа данных.
2. Существующее
программное
обеспечение
Процесс бизнес-планирования и формирования управленческой
отчетности на текущий момент автоматизирован на базе программного
обеспечения Oracle Financial Analyzer (OFA).
3. Существующие проекты
ИКСО – Интегрированная корпоративная система отчетности – ИР
ИКСО КИС SAP. Целью ИР является обеспечение регулярного и
своевременного выпуска корпоративной отчетности.
4. Требования к системе
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 (работы,
проводимые в ручном режиме) –
по потребности, при условии
предварительного оповещения
пользователей
В случае наличия неисправностей в аппаратном либо программном
обеспечении Системы, препятствующих осуществлению одной или более
функций Системы, используется аварийный режим работы Системы.
При переходе в аварийный режим работы все конечные пользователи
Системы должны быть оповещены об этом, а также об интервале
времени необходимом для проведения аварийно-восстановительных
работ Системы.
В аварийном режиме работы Система может быть доступна
пользователям в ограниченном объеме.
2. Требования к
правам доступа и
ролям
пользователей
СБПУО должна обеспечивать возможность ведения и централизованного
администрирования единого списка пользователей, отражающего права
доступа пользователей к СБПУО.
Персонал Системы должен подразделяться на две группы:
1. Конечные пользователи Системы
– персонал Системы, объем задач
и ответственность которого
сводится к действиям в рамках
процесса формирования и анализа
управленческих данных.
2. Обслуживающий персонал
Системы – персонал Системы,
объем задач и ответственность
которого ограничивается
обеспечением доступности
функций Системы для конечных
пользователей
Совокупность выполняемых задач и ответственность определяется
ролью, установленной для конечного пользователя или обслуживающего
персонала Системы.
Права доступа группы пользователей к объектам системы должны быть
определены с помощью матрицы логических доступов, разрабатываемой
Заказчиком
В системе должны быть представлены следующие роли:
функциональный специалист
(пользователь);
администратор модели;
системный администратор;
администратор безопасности;
администратор технической
поддержки.
Описание ролей, определенных для конечных пользователей в Системе,
приведено в [Таблица ]:
Таблица . Роли конечных пользователей
№
Роль
п./п.
1
Функциональный
специалист
Краткое описание
Сотрудник Компании, вводящий / загружающий
финансовые данные в Систему и запускающий
стандартные расчёты.
Описание ролей обслуживающего персонала Системы приведено в
[Таблица ]
Таблица . Роли обслуживающего персонала
№
Роль
п./п.
1. Администратор
модели
Краткое описание
Сотрудник Компании, который изменяет настройки
программного обеспечения Hyperion Planning,
обусловленные изменениями моделью сбора данных и
формирования отчетности.
2. Системный
администратор
Сотрудник Компании, который отвечает в целом за
работоспособность серверов Системы и реляционной
СУБД и восстановление Системы, но не за настройки
программного обеспечения Hyperion Planning.
3. Администратор
безопасности
Сотрудник Компании, который выполняет в системе
действия по управлению правами доступа пользователей
(как для текущих, так и для новых пользователей
системы).
4. Администратор
технической
поддержки
Сотрудник Компании, который осуществляет поддержку
пользователей: регистрацию инцидентов, их обработку и
сопровождение.
Допускается присвоение нескольких ролей одному сотруднику.
Численность пользователей определяется количеством поименованных
лицензий и составляет 25 пользователей.
1.a.1.3Требования к квалификации персонала,
порядку его подготовки и контроля
знаний и навыков
Конечные пользователи Системы должны обладать начальным уровнем
компьютерной грамотности в следующих областях:
Навыки работы с операционными
системами Windows.
Умение пользоваться
прикладными программами,
входящими в состав Microsoft
Office.
Навыки работы с Microsoft
Internet Explorer.
Помимо начального уровня компьютерной грамотности конечные
пользователи Системы должны обладать следующими навыками и
знаниями (в зависимости от роли конечного пользователя):
Схема 2.Функциональный специалист:
o
Знание предметной области;
o
Навыки работы на уровне
пользователя со
следующими компонентами
Системы:
Oracle Hyperion
Planning;
Oracle Hyperion Smart
View;
Oracle Hyperion
Financial Reporting;
Oracle Hyperion Web
Analysis;
Обслуживающий персонал Системы должен обладать следующими
навыками и знаниями (в зависимости от роли обслуживающего
персонала):
1. Администратор модели:
o
знание структуры
настроенных приложений
Planning;
o
знание назначения и
структуры измерений;
o
навыки по внесению
изменений в измерения;
o
навыки по созданию и
изменению форм данных;
o
навыки создания расчетов в
модели: формулы, бизнесправила, написания формул
в Essbase;
o
навыки синхронизации
настроек Подсистемы
бюджетного управления
тестового и продуктивного
серверов;
o
навыки по настройке
отчетов:
o
в интерфейсе
SmartView с
подключением к
Essbase;
в интерфейсе Financial
Reporting Studio;
в интерфейсе Web
Analysis.
знание принципов работы
Essbase и процедур по
администрированию Essbase
(работа с лог-файлами,
реструктуризация);
2. Администратор безопасности:
o
знание принципов
ограничения прав доступа
Oracle Hyperion Planning;
o
знание интерфейса Shared
Services.
3. Администратор технической
поддержки:
o
навыки по созданию
запросов в службу
технической поддержки
интегратора на русском
языке и в службу
технической поддержки
вендора на английском
языке;
o
навыки работы с Системой
на уровне конечных
пользователей.
4. Системный администратор:
o
навыки по
администрированию
продуктивного и тестового
серверов СБПУО;
o
навыки по оптимизации
производительности и
параметров Oracle Hyperion
Planning;
o
навыки по резервному
копированию и
восстановлению данных
ESSBASE, MS SQL.
В рамках подготовки СБПУО к приемочному тестированию должны быть
запланированы и проведены мероприятия по подготовке персонала
СБПУО к работе с Системой.
3. показатели
назначения
СБПУО должна соответствовать следующим показателям назначения
[Таблица ]:
Таблица . Показатели назначения
№
Наименование задачи
п./п.
1
Длительности и трудоемкости процессов сбора
управленческой отчетности
2
Качество принимаемых управленческих решений
Уменьшение
Гибкость применяемого аналитического аппарата
Увеличение
3
Целевое значение
Увеличение
4. Требования к
надежности
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.
5. Требования
безопасности
Электроснабжение и силовое электрооборудование помещений для СПТ
необходимо выполнять по требованиям ПУЭ-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 к
персональным электронно-вычислительным машинам (ПЭВМ),
помещениям для работы с ПЭВМ, микроклимату, содержанию
аэроионов и вредных химических веществ в воздухе на рабочих местах,
оборудованных ПЭВМ, уровням шума и вибрации на рабочих местах,
освещению на рабочих местах, инфракрасному, ультрафиолетовому,
рентгеновскому и электромагнитному излучениям, уровням
электромагнитных полей на рабочих местах.
6. Требования к
эргономике и
технической
эстетике
Взаимодействие пользователей с прикладным программным
обеспечением, входящим в состав системы должно осуществляться
посредством визуального графического интерфейса (GUI). Интерфейс
системы должен быть понятным и удобным, не должен быть перегружен
графическими элементами и должен обеспечивать быстрое отображение
экранных форм. Навигационные элементы должны быть выполнены в
удобной для пользователя форме. Средства редактирования
информации должны удовлетворять принятым соглашениям в части
использования функциональных клавиш, режимов работы, поиска,
использования оконной системы. Ввод-вывод данных системы, прием
управляющих команд и отображение результатов их исполнения
должны выполняться в интерактивном режиме. Интерфейс должен
соответствовать современным эргономическим требованиям и
обеспечивать удобный доступ к основным функциям и операциям
системы.
Интерфейс должен быть рассчитан на преимущественное использование
манипулятора типа «мышь», то есть управление системой должно
осуществляться с помощью набора экранных меню, кнопок, значков и т.
п. элементов. Клавиатурный режим ввода должен использоваться
главным образом при заполнении и/или редактировании текстовых и
числовых полей экранных форм.
Все надписи экранных форм, а также сообщения, выдаваемые
пользователю (кроме системных сообщений) должны быть на русском
языке.
Система должна обеспечивать корректную обработку аварийных
ситуаций, вызванных неверными действиями пользователей, неверным
форматом или недопустимыми значениями входных данных. В
указанных случаях система должна выдавать пользователю
соответствующие сообщения, после чего возвращаться в рабочее
состояние, предшествовавшее неверной (недопустимой) команде или
некорректному вводу данных.
Экранные формы должны проектироваться с учетом требований
унификации:
Схема 3.Все экранные формы пользовательского интерфейса должны
быть выполнены в едином графическом дизайне, с одинаковым
расположением основных элементов управления и навигации;
Схема 4.Для обозначения сходных операций должны использоваться
сходные графические значки, кнопки и другие управляющие
(навигационные) элементы. Термины, используемые для обозначения
типовых операций (добавление информационной сущности,
редактирование поля данных), а также последовательности действий
пользователя при их выполнении, должны быть унифицированы;
Схема 5.Внешнее поведение сходных элементов интерфейса (реакция на
наведение указателя «мыши», переключение фокуса, нажатие кнопки)
должны реализовываться одинаково для однотипных элементов.
Система должна соответствовать требованиям эргономики и
профессиональной медицины при условии комплектования
высококачественным оборудованием (ПЭВМ, монитор и прочее
оборудование), имеющим необходимые сертификаты соответствия и
безопасности Росстандарта.
7. Требования к
эксплуатации,
техническому
обслуживанию,
ремонту и
хранению
компонентов
системы
Аппаратное и программное обеспечение СТП СБПУО должно
обеспечиваться гарантийной поддержкой производителя сроком не
менее 12 месяцев с даты начала постоянной эксплуатации.
Условия эксплуатации, параметры сетей электроснабжения серверного
оборудования СТП СБПУО должны соответствовать общим техническим
требованиям к средствам вычислительной техники, применяемым в
составе автоматизированных систем управления.
Ремонт технических средств СБПУО должен осуществляться
специализированными сервисными организациями, имеющими
аккредитацию производителей оборудования.
При возникновении неисправностей должно осуществляться
оперативное, в соответствии с требованиями п. Требования к надежности
Системно-технической платформы, обслуживание технических средств,
критичных для функционирования Системы.
Техническое регламентное обслуживание составных частей Системы
должно проводиться в соответствии с требованиями производителя
технического оборудования. Регламент обслуживания отдельных
технических средств должен быть определен в эксплуатационной
документации.
В процессе обслуживания СБПУО Заказчиком должны обеспечиваться:
1. выполнение требований к
надежности, изложенных в
настоящем ТЗ, в частности, к
требуемому времени
восстановления Системы после
сбоев, аварий и неисправностей;
2. выполнение требований
регламентов обслуживания и
ремонта ПТС, BT, принятых в
организации Заказчика в части
непротиворечащей п. Требования
к надежности Системнотехнической платформы;
3. предоставление доступа к СБПУО;
4. выполнение работ по учету и
управлению оборудованием,
системным ПО;
5. использование стандартного ПО
Oracle при обслуживании и
поддержке пользователей в
процессе эксплуатации Системы
для обеспечения:
своевременной инсталляции
обновлений ПО компании Oracle;
предоставления доступа
пользователям и управления их
учетными записями в
соответствии с установленным
порядком;
проактивной диагностики
ландшафта, элементов СТП, СУБД
и бизнес-процессов
пользователей;
выполнения работ по управлению
инцидентами, проблемами и
изменениями.
8. Требования к
защите
информации от
несанкционированн
ого доступа
Система должна удовлетворять всем требованиям регламентирующих
документов Компании по информационной безопасности для
возможности обработки информации максимальной категории
конфиденциальности – конфиденциальная информация.
Категория конфиденциальности информации, обрабатываемой в
информационной системе – конфиденциальная информация.
Информационная система должна обеспечивать защиту от
несанкционированного доступа (НСД) на уровне не ниже установленного
требованиями, предъявляемыми к классу защищенности 1Г АС по
классификации действующего руководящего документа Гостехкомиссии
России «Автоматизированные системы. Защита от
несанкционированного доступа к информации. Классификация
автоматизированных систем и требования по защите информации» 1992
г.
Уровень защищённости от несанкционированного доступа средств
вычислительной техники, обрабатывающих информацию, должен
соответствовать требованиям к классу защищённости 5 согласно
требованиям действующего руководящего документа Гостехкомиссии
России «Средства вычислительной техники. Защита от
несанкционированного доступа к информации. Показатели
защищенности от несанкционированного доступа к информации» 1992 г.
СБПУО должна обеспечивать возможность ведения и централизованного
администрирования единого списка пользователей, отражающего права
доступа пользователей к СБПУО.
Информационная система требует проведения процедуры оценки
соответствия требованиям безопасности информации.
Для защиты информации при ее передаче по каналам связи из одной АС
в другую необходимо использовать МЭ не ниже класса 4.
Если каналы связи выходят за пределы КЗ, необходимо использовать
защищенные каналы связи, защищенные волоконно-оптические линии
связи либо сертифицированные криптографические средства защиты.
Доступ к ИС должен осуществляться только с рабочих станций,
входящих в состав сегментов сети Компании, аттестованных для
обработки информации конфиденциального характера и/или
оборудованных персональными комплексами защиты информации
ПКЗИ-КТ.
Передача конфиденциальной информации (файлы с данными для
загрузки и т.п.) должна осуществляться с использованием ПО «ViPNet
«Деловая почта», входящего в состав ПКЗИ-КТ-ДП.
9. Требования по
сохранности
информации при
авариях
Средствами ВК СБПУО должна быть обеспечена гарантированная
сохранность всех данных, хранимых на серверах и системах хранения
СБПУО, в том числе, следующих типов:
1. прикладные данные:
исходные данные, включая все их
модификации (например,
результаты округления и расчета
показателей);
результирующая информация,
полученная в результате
обработки исходных данных.
2. системные данные:
системное программное
обеспечение и конфигурационные
наборы данных;
программное обеспечение,
таблицы, конфигурационные
файлы и журналы систем
управления базами данных
(СУБД);
журналы изменений Системы и
активности пользователей.
Для обеспечения сохранности данных при авариях в процессе
эксплуатации должна использоваться единая система управления
резервным копированием на базе сервера резервирования. Данная
система должна предусматривать минимизацию потерь информации в
случае отказа ПТС, в том числе по следующим причинам:
1. повреждение электропитания;
2. выход из строя
микропроцессорного
оборудования;
3. повреждение кабельной системы;
4. физическое повреждение
носителей информации,
находящихся в эксплуатации;
5. злоумышленные действия.
Сохранность информации в этих случаях должна обеспечиваться за счет:
1. централизованного хранения
информации на отказоустойчивом
оборудовании систем хранения
данных, резервного копирования
и восстановления данных СБПУО;
6. реализации принципа
избыточности хранения
информации;
7. программных решений по
обеспечению целостности баз
данных при сбоях в проведении
транзакций;
8. организации бесперебойного
электропитания серверов,
входящих в состав или
взаимодействующих с СБПУО.
Комплекс мер по обеспечению сохранности информации и ее
восстановлению должен включать в себя:
1. проведение регулярного
регламентного копирования баз
данных (БД);
9. проведение внепланового
резервного копирования БД;
10.хранение резервных копий в
разных помещениях с
техническими средствами
(серверами, активным сетевым
оборудованием и т.п.);
11. восстановление БД из резервных
копий;
12. исключение
несанкционированного доступа к
резервным копиям.
Резервные копии данных должны храниться до момента создания
следующих резервных копий того же назначения. Восстановление баз
данных с резервной копии должно осуществляться согласно
технологической инструкции.
10.Требования к
защите от
влияния внешних
воздействий
В помещениях с размещенными техническими средствами, на которых
функционирует СБПУО, должны обеспечиваться климатические
условия, определенные требованиями производителей используемых
технических средств.
Специальные требования по защите от влияния внешних воздействий не
предъявляются.
11. Требования к
патентной
чистоте
Проектные решения СБПУО должны отвечать требованиям по
патентной чистоте согласно действующему законодательству Российской
Федерации.
Используемое для построения СБПУО ПО сторонних производителей
должно быть обеспечено соответствующими лицензиями на его
использование. Программные и технические средства, приобретаемые у
сторонних производителей, должны сопровождаться документацией,
подтверждающей правомочность этих организаций поставлять данную
продукцию и сопровождаться лицензионным соглашением.
12. Дополнительные
требования
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. Бизнес-правила и формулы на
элементах должны быть
прокомментированы:
a. В начале каждого бизнесправила необходимо писать
его назначение, источники и
получатели данных в
терминах блоков модели и
форм ввода.
b. Перед каждым блоком
операторов FIX необходимо
описать назначение
нижеследующего блока.
c. Оператор FIX должен быть
построен по маске:
FIX (
Измерение1 /* Название
измерения1 */
Измерение2 /* Название
измерения2 */
Измерение3 /* Название
измерения3 */
)
a. Перед каждым оператором
IF необходимо описать его
назначение и перечислить
рассматриваемые варианты
b. Перед каждым сложным
расчетом необходимо
описать его назначение и
механизм реализации.
2. Бизнес-правила и функции
должны быть иерархически
выделены знаками табуляции или
пробелами:
a. Код внутри конструкции
Элемент() выделяется
табуляцией.
b. Код внутри каждого
оператора IF выделяется
дополнительной
табуляцией.
3. Комментарий к коду должен
отражать суть выполняемых
операций с точки зрения бизнеса.
5.a.1.6ТРЕБОВАНИЯ К ДОСТУПНОСТИ И
ПРОИЗВОДИТЕЛЬНОСТИ СИСТЕМЫ
Режим работы продуктивной системы – 24х7
Тестирование производительности системы будет проводиться на
примере формуляра в MS Excel. Предполагаемый размер формуляра это 700-1000 строк, 200-240 столбцов, 40-50 страниц. Тестирование
должно осуществляться на системе, содержащей данные за 3 года. Один
год - это 50 формуляров по 100 ОГ по 10 сценариям.
Требования к производительности компонентов системы приведены в
таблице ниже:
Операция
Максимальное
значение, мин.
Загрузка данных одного формуляра из файла
в формате CSV
3
Пересчет показателей формуляра в системе
5
Обновление (чтение) данных отчета в MS
Excel, соответствующего формуляру
Обновление (чтение) данных отчета в MS
Excel, соответствующего формуляру
Обновление (чтение) данных отчета в Web,
соответствующего формуляру
Копирование данных
0,25
Объем данных
операций
1 ОГ 1 формуляр 1
сценарий
1 ОГ 1 формуляр 1
сценарий
1 страница
Все страницы
5
1 страница
0,5
Все ОГ 1 формуляр 1
сценарий
60
5.a.1.7ТРЕБОВАНИЯ К ПЕРЕНОСУ
(МИГРАЦИИ) ДАННЫХ
Подрядчик должен обеспечить перенос данных из OFA в OHP как
конечных данных, так и всех рассчитанных элементов за последние два
года. Заказчик должен обеспечить выгрузку данных из OFA в требуемой
детализации по согласованному с Подрядчиком на этапе технического
проектирования формату. Заказчик должен передать Подрядчику
мэппинг между элементами систем.
2. Требования к
АВТОМАТИЗАЦИИ и
функциям (задачам),
выполняемым системой
1. Перечень функций
СБПУО
В Таблица перечислены основные функции создаваемой СБПУО и их
описание.
Таблица . Перечень функций, реализуемых в Системе
Код
Наименование
функции
Описание функции
1. Предоставление интерфейсов для работы с данными
1.
Загрузка
данных из
файлов формата CSV
или формата TXT с
полями фиксированной
длины
2.
Представление
данных
через формы ввода
3. данных, а также
Ввод
осуществление других
операций в СБПУО с
использованием Webбраузера
4. и просмотр
Ввод
данных с
использованием MS
Excel интерфейса
5.
Возможность
ввода
данных при разрыве
соединения с сервером
в интерфейсе MS Excel
Наличие механизма массовой обработки и загрузки
в СБПУО файлов формата CSV или формата TXT с
полями фиксированной длины, выгружаемых из
шаблонов MS Excel.
6.
Поддержка
специальных функций
ввода данных
СБПУО должна поддерживать следующие функции
при вводе данных:
корректировка значений (как в абсолютном,
так и в относительном выражении);
распределение вводимых данных;
копирование данных (как в рамках одной
формы, так и между формами);
копирование данных из/в MS Excel;
7.
Возможность
контроля
вводимых значений
В формах ввода могут быть реализованы проверки
на ввод некорректных значений. При вводе
некорректных значений возникают
предупреждающие сообщения, а ячейки на форме
ввода изменяют цвет фона.
Реализуются следующие виды проверки:
Возможность внесения плановых данных через
формы ввода, реализованные в СБПУО.
Должно быть реализовано удаленное подключение
к СБПУО для работы с финансовыми данными, а
также выполнения других операций с
использованием тонкого клиента (Web-браузера).
Должно быть реализовано удаленное подключение
к СБПУО для работы с финансовыми данными с
использованием интерфейса MS Excel.
При разрыве соединения пользователь СБПУО
должен иметь возможность ввести данные на
текущий срез, выбранный на форме ввода, и при
восстановлении подключения отправить эти
данные в СБПУО.
Код
Наименование
функции
Описание функции
• проверка расчетных ячеек на соответствие
определенному значению
• вывод дополнительных вспомогательных форм в
текущем окне
8.
Использование
функции
комментирования
данных
9.
Использование
функции drill-down по
иерархиям
10.
Использование
контекстного меню для
перехода на связанные
формы
11.
Автоматический
и
ручной запуск
расчетов при
представлении данных
СБПУО должна поддерживаться возможность
создавать комментарии для ячеек данных.
12.
Инструкции
к формам
ввода
При наличии важной технической информации по
работе с формой ввода, она может быть отражена в
инструкции к форме ввода или просмотра данных.
Остальная информация по работе с формами ввода
должна находиться в Инструкции пользователя.
Должен быть возможен drill-down по иерархиям
аналитических справочников, доступных на форме.
Должна быть возможность перехода по
контекстному меню из форм бюджетов в формы,
содержащие исходные данные для расчета
бюджета.
Должен быть реализован автоматический запуск
расчетов (по событию или расписанию) и запуск
расчетов по запросу пользователя. Расчеты,
логически связанные с формами ввода,
прикрепляются к формам ввода.
2. Сбор, хранение и обработка данных в необходимой детализации
1.
Детализация
данных
по справочникам
Данные должны детализироваться по элементам
справочников, используемых в модели бизнеспланирования и формирования управленческой
отчетности
2.
Организация
хранения
данных БД по
аналитическим кубам
3.
Возможность
хранения
в СБПУО
вспомогательной
информации
Для хранения финансовых данных в базе данных
должны быть организованы кубы данных.
СБПУО должна поддерживать централизованное
хранение вспомогательных документов. Документы
в хранилище загружаются пользователями СБПУО
или администратором.
Код
Наименование
функции
Описание функции
4.
Агрегация
данных по
иерархиям
справочников
Автоматический расчет значений узловых
элементов на основе значений дочерних элементов
по правилам иерархий. Должна поддерживаться
агрегация данных по альтернативным иерархиям.
5. данных по
Расчет
бюджетам
Автоматический расчет данных в соответствии с
алгоритмами модели бизнес-планирования и
формирования управленческой отчетности
6.
Консолидация
данных
с учетом долей
владения
7.
Обеспечение
целостности данных
для конечных
пользователей
Автоматический расчет консолидационных
значений с учетом долей владения.
8.
Историчность
справочников
СБПУО должна обеспечивать возможность
поддержания историчности справочников – для
возможности построения различных отчетов и
использования различных формульных механизмов
для отдельных наборов данных (например, для
разных сценариев).
9.
Возможность
планфакт анализа
СБПУО должна предоставлять проведения планфакт анализа, путём сопоставления фактических и
плановых данных
Конечные пользователи должны всегда видеть
только проверенный и полностью пересчитанный
набор данных. Процессы загрузки и пересчета
данных не должны влиять на корректность
отчетных данных, видимых пользователями.
3. Построение аналитических отчетов и предоставление инструментов для
анализа финансовых данных
1.
Формирование
итоговой отчетности
заданного формата
2.
Формирование
аналитической
отчётности и
возможность изменять
параметры отчета
Должны быть настроены формы презентационной
отчетности для основных бюджетов.
Должны быть настроены формы аналитической
отчётности.
На сформированных отчетах у пользователя
должна быть возможность менять срез данных,
сворачивать/разворачивать выведенные на таблицу
статьи по иерархии
У пользователей СБПУО, анализирующих данные,
должна быть возможность построения собственных
Код
Наименование
функции
Описание функции
аналитических отчетов, поддерживающих
следующие функции:
переходы по иерархиям;
создание аналитических вычислений;
ранжирование;
сортировка;
условное форматирование
Инструмент создания подобной аналитической
отчётности должен поддерживать различные
средства представления информации: таблицы,
диаграммы, изображения, аналитические карты,
интерактивные панели и пр.
3.
Возможность
использования
дополнительных
инструментов
формирования
отчётности
У пользователей СБПУО должна быть возможность
использования дополнительных инструментов
формирования аналитической отчётности с
помощью специального ad-hoc анализа.
4. Предоставление средств управления доступом к данным
1.
Поддержка
работы с
группами
пользователей
Права доступа к объектам СБПУО должен быть
организован на основе групп пользователей. В
СБПУО должна поддерживаться вложенность
групп и наследуемость прав доступа.
2.
Определение
функциональных
ролей пользователей
Доступ к функциям СБПУО должен
разграничиваться на основе функциональных ролей
пользователей (администратор модели,
стандартный пользователь, интерактивный
пользователь, финансовый контролёр и т.д.).
3.
Разграничение
доступа
к отдельным объектам
СБПУО
Должен быть организован доступ пользователей к
определенным объектам СБПУО стандартными
средствами ПО. Организация прав доступа должна
предусматривать следующие категории доступа:
доступ к логическим объектам системы:
формам, отчетам, папкам хранилища
данных;
доступ к запуску расчетов.
Код
Наименование
функции
4.
Разграничение
доступа
к данным
Описание функции
Доступ к данным СБПУО должен поддерживаться
на двух уровнях: доступ на чтение и доступ на
запись - и определяться путем разграничения
доступа к отдельным элементам справочников.
5. Предоставление инструментов администрирования и поддержки модели
1.
Обновление
аналитических
справочников
Должно поддерживаться редактирование
администратором модели аналитических
справочников с использованием стандартной
функциональности ПО.
2.
Встроенные
инструменты
администрирования
СБПУО должна иметь инструменты
централизованной настройки, доступные
администратору модели.
2. ПЕРЕЧЕНЬ
МОДЕЛЕЙ
Перечень моделей для миграции на новую платформу с примерным
количеством показателей и сложностью расчетных алгоритмов приведен
в
Таблица . Перечень
моделей
Наименование
модели
1. ВСЕМ Бизнесам
CAPEX
2. НПЗ (NPZ)
Экономика НПЗ
Пр-во НПЗ
(Мощности)
CAPEX-дет НПЗ
Баланс Масел
Товарный баланс
катализаторов
Примерное Примерное Примерное
количеств количеств количеств
о строк
о столбцов о листов
890
2
2
706
128
3
27
34
28
283
31
43
23
1
28
31
17
28
Детализация в
формуляре
1-П (пр-во
нефтепродуктов)_НП
З
3. НПО (NPO)
Экономика НПО
Пр-во НПО
Прочая деят. НПО
CAPEX-ext_НПО
Баланс НПО
4. НГД (NGD)
Экономика НГД
PL НГД
затраты НГД
транспорт НГД
ремонты НГД
энергия НГД
РЗП+Бенчмаркин
г
Геология НГД
Бурение НГД
Пр-во НГД
CAPEX-M НГД
CAPEX ТРИЗ НГД
ТБ НГД
Цел. прогр. НГД
Проч. деят. НГД
Механизированная
добыча НГД
Энергетика НГД
5. ГРР (GRR)
Экономика ГРР
PL ГРР
Затраты ГРР
План финансирования
ГРР
6. Сервис (SERVICE)
839
39
65
1500
110
170
320
630
50
14
14
72
250
15
1
1
1
14
2210
500
600
40
400
270
170
170
170
170
170
170
18
5
5
1
5
1
400
170
1
100
480
750
210
210
150
100
60
119
119
119
252
252
93
16
17
290
31
1
640
168
3
660
440
220
31
31
4-25
32
1
31 Проекты
80
31
1-50 Проекты
Экономика (сервис)
840
252
1-25
Пр-во (сервис)
7. Прочие доч.
общества (OTH_DO)
Экономика (прочие
ДО)
8. РН-Карт (Сервис
НПО)
1510
31
1
190
180
1
1-200 Месторождения
1-200 Месторождения
1-200 Месторождения
1-200 Месторождения
1-200 Месторождения
3-30
31
1
Филиалы/Контрагент
ы
Экономика (сервис
НПО)
1500
1
15
Все алгоритмы в новой платформе должны повторять алгоритмы с
мигриуемой платформы стандартными средствами OHP. В случае, если
алгоритмы не могут быть пренесены напрямую, тогда Подрядчик
должен предложить обходной вариант в ходе технического
проектирования Системы.
Реализованные на новой платформе вычисления должны обеспечивать
возможность расчета всех показателей и объектов, которые
использовались в старой системе (например, расчетные показатели
карточек, сводные объекты планирования по МСФО и др.).
3. ТРЕБОВАНИЯ К
ДАННЫМ
Хранение данных должно быть реализовано в многомерной модели
данных – кубах. Общий объем данных должен быть разделен на
несколько кубов, руководствуясь следующими принципами:
Оптимизация
производительности за счет
исключения из кубов
неиспользуемых измерений.
Каждый куб должен
характеризоваться своим набором
измерений;
Логическое разделение;
Разделение полномочий по
доступу к данным части модели
В таблице ниже приводится рекомендуемый перечень измерений с
краткими характеристиками, набором справочников, которые могут
входить в это измерение. Структура справочников будет уточнена на
этапе концептуального проектирования системы.
Таблица . Возможная
структура
справочников OHP
№
Наименование
Описание измерения
примерное
количество
элементов
1.Year (Год)
Обязательное измерение. Содержит
справочник лет, по которым будут
составляться бюджеты.
15
2.Period (Период)
Обязательное измерение. Содержит
справочник периодов для целей
планирования (планирование по кварталам
и месяцам).
17
3.Scen (Сценарий)
Обязательное измерение. Содержит
различные варианты сценариев (план, факт
и т.п.).
4
4.PeriodType (Тип
периода)
Используется вместо обязательного
измерения «Версия». Содержит два типа
просмотра данных по периодам –
периодический и накопленным итогом.
5
5.Unit
(Подразделение)
6.BU
Обязательное измерение. Содержит
справочник подразделений
1200
Дополнительное измерение. Содержит
справочник Бизнес-единиц
месторождений/инвестиционных программ
и т.д..
1000
Обязательное измерение. Содержит
справочник бюджетной модели. Статьи
рекомендуется группировать в иерархии
чтобы разделять статьи разных частей
модели.
Возможные узлы иерархии (перечень не
полный и подлежит уточнению при
внедрении Системы):
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)
4000
(Бизнесединица)
7.Account
(Показатели)
№
Наименование
Описание измерения
примерное
количество
элементов
SBAL (НПО, баланс)
PLND (НПО, производство)
PRPR (НПО, прочая деятельность.)
PLNP (НПЗ, производство)
PLOP (НГД, PL)
PLEL (НГД, PL)
PLRM (НГД, PL)
PLTR (НГД, PL)
BAL (НГД, ТБ)
BLPR (1-П)
PLLU (ГРР, экономика)
PLOP (ГРР, экономика)
CAP_F (ГРР, ПФ)
PLLU (ДЗО, экономика)
8.Prod
(Продукция)
Дополнительное измерение. Содержит
справочник групп продукции в следующих
иерархиях:
ACTD
GRM
NPZPRD
PRDC
SRV
CAP (capex-ext, capex-m)
100
9.Counterpart
(Контрагент)
10.
ServiceType
(Вид сервиса)
11.
LOB (Вид
бизнеса)
12.
STR (Участки,
затраты)
Дополнительное измерение. Содержит
справочник контрагентов.
100
Дополнительное измерение. Содержит
справочник видов сервиса.
TBD
Дополнительное измерение. Содержит
справочник видов бизнеса.
TBD
Дополнительное измерение. Содержит
справочник участков и типов затрат.
TBD
Предварительный состав приложений, кубов, а также использование
измерений в кубах, указан в Таблица . Возможная структура
справочников OHP.
Архитектура приложений, кубов, а также использование измерений в
кубах должна уточняться в процессе реализации модели.
Справочники системы предполагают их синхронизацию с
общекорпоративными справочниками, подробно изложенную в п. 4.2.4.
4. ТРЕБОВАНИЯ К
СПРАВОЧНИКАМ
Справочник 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. Запрещено использовать
следующие символы в именах и
псевдонимах:
a. двойные кавычки ( “ ” );
b. квадратные и фигурные скобки ( [
] { } );
c. обратные и прямые слеши ( \ / );
d. знаки табуляции ( ).
5. Имена и псевдонимы не должны
начинаться или заканчиваться
пробелом.
6. Имена и псевдонимы должны
начинаться либо с буквы
алфавита, либо с цифры.
7. Псевдонимы могут быть
изменены в любой момент в ходе
настройки системы или после
передачи в эксплуатацию.
Изменение имени любого
элемента после настройки модели
может привести к внесению
изменений в формы ввода, формы
отчетов, расчеты и другие
настройки OHP, где используется
переименовываемый элемент.
Предварительный список справочников и классификаторов для
гармонизации и синхронизации должен быть разработан, сопоставлен с
аналогичными в ИКСО и согласован на этапе концептуального
проектирования.
Заказчик должен передать Подрядчику справочники с учетом
перечисленных требований.
5. ТРЕБОВАНИЯ К
НАЛИЧИЮ
ОТЧЁТОВ
Подрядчик должен обеспечить настройку отчетов Oracle Hyperion
Planning по требованиям Заказчика.
Отчеты должны быть представлены в виде форматированных отчетов в
формате MS Excel. Отчеты должны быть построены на базе всех
разработанных моделей и должны поддерживать автоматическое
обновление данных.
Форматы отчетов будут переданы Подрядчику в виде Excel-документов.
Отчеты должны покрывать все настроенные модели.
Требования к количеству отчетов:
Отчеты, реализумые с помощью
инструмента Financial Reporting –
не более 20
Всего отчетов не более 50.
Требования к отчетам будут определены на этапе концептуального
проектирования.
3. Требования к видам
обеспечения
1. Требования к
информационному
обеспечению
системы
Состав, структура и способы организации данных в системе должны быть
определены на Этапе 1. «Реализация».
Доступ к данным должен быть предоставлен только авторизованным
пользователям с учетом их служебных полномочий.
СБПУО должна обеспечивать контроль физической целостности данных
в БД в части структур таблиц и связей между ними посредством
уникальности ключей и наличия полей, через которые осуществляется
связь одной таблицы с другими.
Технические средства, обеспечивающие хранение информации, должны
использовать современные технологии, позволяющие обеспечить
повышенную надежность хранения данных и оперативную замену
оборудования.
2. Требования к
лингвистическому
обеспечению
системы
Все прикладное программное обеспечение ИС для организации
взаимодействия с пользователем должно использовать русский язык.
3. Требования к
программному
обеспечению
системы
Используемое при разработке программное обеспечение и библиотеки
программных кодов должны иметь широкое распространение, быть
общедоступными и использоваться в промышленных масштабах.
Базовой программной платформой должна являться операционная
система MS Windows.
Функциональные возможности ПО должны обеспечивать реализацию
требований к функциям, выполняемым СБПУО.
Для реализации СБПУО должно быть использовано следующее ПО:
Основное ПО - Oracle Hyperion
(далее – Hyperion Planning);
Вспомогательное ПО.
Перечень Основного ПО приведен в [].
Таблица . Перечень основного ПО СБПУО
№
Наименование
Назначение
Роль в
архитектуре
«клиент-сервер»
1.Oracle
Hyperion EPM
Architect
11.1.2.4
2.Oracle Essbase
11.1.2.4
Инструмент для управления
приложениями Hyperion Planning
(создание и настройка приложений,
справочников и расчетов).
Серверная часть
Многомерная СУБД, предназначенная
для хранения данных в многомерной
модели.
Серверная часть
3.Essbase
Administration
Services
11.1.2.4
4.EAS Console
11.1.2.1
Серверная часть Essbase для управления
моделями данных и вычислениями.
Серверная часть
Клиентская часть Essbase для управления
моделями данных и вычислениями.
Для работы использует сервис Essbase
Administration Services.
Клиентская
часть
(администратор
модели)
5.Oracle
Hyperion
Planning
11.1.2.4
Основное программное обеспечение, с
которым взаимодействует пользователь.
Обеспечивает управление процессом
формирования отчетности, настройками
запросов к многомерной СУБД Essbase
для ввода/вывода данных.
Серверная часть
6.Oracle
Hyperion
Smart View
11.1.2.4
7.Oracle
Hyperion
Financial
Reporting
11.1.2.4
Клиентская часть для обеспечения
доступа к приложению Hyperion Planning
через MS Excel.
Клиентская
часть (все
пользователи)
Серверная часть обеспечивает
управление настройками запросов к
многомерной СУБД Essbase и к
реляционной СУБД для построения
печатных отчетов, а также предоставляет
средства их форматирования.
Клиентская часть используется для
построения отчетов.
Серверная часть
Клиентская
часть
(администратор
модели)
8.Oracle
Hyperion
Foundation
Services
11.1.2.4
Набор служб для управления
настройками безопасности, обеспечения
единой точки доступа к прикладному
уровню Подсистемы бюджетного
управления (через web-браузер),
обеспечения интеграции с продуктами
MS Office.
Серверная часть
№
Наименование
Назначение
Роль в
архитектуре
«клиент-сервер»
9.Oracle HTTP
Server
Веб-сервер, предназначенный для
обработки http-запросов от клиентских
частей программного обеспечения, кроме
EPM Architect и MS SSRS.
Серверная часть
10.
Oracle
WebLogic
11.1.2.4
11.
Web Analysis
11.1.2.4
App-сервер. Программный сервер для
развертывания Java-приложений.
Серверная часть
Обеспечивает управление настройками
запросов к многомерной СУБД Essbase, к
реляционной СУБД и к связанным
таблицам реляционных СУБД для
построения интерактивных отчетов,
включающих текст, таблицы, графики,
диаграммы, изображения.
Серверная часть
Состав вспомогательного ПО определяется требованиями вендора.
Источником указанных требований является документ Oracle Hyperion
EPM System Certification Release 11.1.2.1 Перечень необходимого
вспомогательного ПО Подсистемы бюджетного управления приведен в
Таблица .
Таблица . Перечень вспомогательного ПО СБПУО
№
Наименование
Назначение
Роль в
архитектуре
«клиент-сервер»
1.Windows Server 2008
R2 64x Standard
Edition
2.MS SQL Server 2008
R2
Операционная система.
Серверная часть
Реляционная СУБД,
предназначенная для хранения
настроек и метаданных Hyperion
Planning.
Серверная часть
3.Client MS SQL Server
2008
Клиентская часть для доступа к
СУБД, устанавливается на
серверах, где не установлена
реляционная СУБД или на
рабочих станциях системных
администраторов.
Клиентская
часть
(системный
администратор)
4.Java Development Kit
1.6.0 14+
Обеспечивает работу с EAS
Console через веб-интерфейс.
Клиентская
часть
(администратор
модели)
5.7-Zip или аналог
Программа архивирования
файлов.
Серверная часть
№
Наименование
Назначение
Роль в
архитектуре
«клиент-сервер»
6.MS Internet Explorer
7.x
MS Internet Explorer
8.x
MS Internet Explorer
9.x
Предназначен для обеспечения
доступа к приложениям Hyperion
Planning через Web.
Примечание: для корректной
работы в свойствах браузера
должны быть включены
следующие опции:
разрешение на выполнение
скриптов приложений Java;
запуск элементов ActiveX и
модулей подключения;
разрешение файлов cookie;
разрешение всплывающих окон.
Клиентская
часть
7.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.
Должен быть обязательно
установлен на клиентских
машинах. При необходимости
работы с приложениями
непосредственно с сервера,
должен быть установлен на
сервер.
Клиентская
часть (все
пользователи)
8.Acrobat Reader 11.0+
(актуальная,
используемая в
Компании версия)
Предназначен для обеспечения
работы с Hyperion Financial
Reporting.
Клиентская
часть (все
пользователи)
4. Требования к
техническому
обеспечению
Техническое обеспечение системы должно максимально и наиболее
эффективным образом использовать существующие у Заказчика
технические средства.
ВК СБПУО должен быть размещен в городе Москве на площадке,
предоставленной Заказчиком.
Технические средства должны быть объединены одной локальной сетью,
с пропускной способностью не менее 100 Мбит/с.
С целью обеспечения непрерывного процесса эксплуатации
продуктивной системы и консистентного обновления функциональности
СБПУО системный ландшафт должен включать в себя две среды для
каждой из компонент СБПУО:
1. Тестовая среда – предназначенная
для проведения тестирования
любых изменений в Системе после
ввода Системы в промышленную
эксплуатацию. Все функции
Системы реализуются в тестовой
среде в полном объеме. Функции
тестовой среды не представляют
ценности с точки зрения
конечных пользователей системы;
2. Продуктивная среда –
предназначенная для реализации
функций Системы для конечных
пользователей Системы. Среда не
предназначена для проведения
тестирования любых изменений в
Системе.
Технология виртуализации допустима для всех серверов Системы. При
использовании виртуализации должны быть обеспечены указанные
ниже параметры серверов. Для виртуализации вендор Oracle
рекомендует использовать VM Oracle. В случае использования ПО
VMware, возникают ограничения, связанные с поддержкой:
«устраняются только ошибки, для которых уже известно, что они могут
происходить на используемой ОС, либо может быть
продемонстрировано, что они не являются результатами работы на
VMware»1.
Рекомендуемые параметры серверов и распределение программного
обеспечения по ним приведены в [Таблица ]. Выделение двух серверов
многомерных баз данных позволит распределить нагрузку приложений
Essbase между данными серверами. Объединение служб Hyperion и
реляционной базы данных MS SQL Server никак не повлияет на
производительность, так как нагрузка на эти компоненты значительно
меньше, чем на модуль Essbase.
В ходе реализации проекта требования к параметрам серверов и ПО
могут быть скорректированы.
Таблица . Рекомендуемые параметры серверов
Назначение
сервера
Тестовый
сервер
Продуктивный
сервер
приложений и
реляционных
БД №1
Продуктивный
сервер
приложений и
реляционных
БД №2
ПО к установке на сервер
Минимальные
ключевые параметры
сервера
ОС: 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
Гб
ОС: 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)
ОС: Windows Server 2008 R2 64x
Enterprise Edition
БД: MS SQL Server 2008
Прикладное ПО:
Oracle HTTP Server
Oracle WebLogic
Oracle Foundation Services
Процессор: Intel Xeon,
16 ядер
RAM: 24 Гб
Дисковый массив: 100
ГБ (раздел #1, под ОС и
ПО Oracle) + 100 ГБ
(раздел #2, под файлы
реляционной базы данных
Назначение
сервера
ПО к установке на сервер
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
Продуктивный
сервер
многомерных
БД №1
Продуктивный
сервер
многомерных
БД №2
Минимальные
ключевые параметры
сервера
и хранилище отчетов
Hyperion) + 100 Гб (раздел
#3 - общий диск под
кластер MS SQL Server)
ОС: 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
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
Гб
5. состав и содержание работ
Состав работ по внедрению и адаптации программного обеспечения
Oracle Hyperion Planning и сроки их выполнения приведены в
Календарном плане к договору.
1. Требования к
организации работ.
Должны выполняться следующие требования:
Подрядчиком должна быть
организована Проектная группа
для выполнения работ.
Непосредственное управление
группой должно осуществляться
руководителем проекта от
Подрядчика, уполномоченным
решать все возникающие вопросы.
Внесение изменений в состав
Проектной группы возможно
только по согласованию с
Заказчиком.
Руководитель проекта от
Подрядчика должен готовить
еженедельный отчет,
включающий в себя, список работ,
выполненных за неделю,
планируемые работы, имеющиеся
риски и проблемы. По
необходимости, должен
производиться сбор Проектной
команды от Компании и
Проектной группы Подрядчика
для определения состояния
проекта и решения оперативных
вопросов.
По каждой встрече с
представителями Заказчика
Руководителем проекта от
Подрядчика должен составляться
фиксирующий документ
(Протокол встречи).
Руководитель проекта от
Подрядчика должен
документировать все изменения
требований к системе.
Проект осуществляется согласно
Методическим указаниям ОАО
«НК «Роснефть» «Оформление и
согласование документации КИС
по вводу ИС в промышленную
эксплуатацию/регистрации ИР
для промышленной
эксплуатации».
Руководитель проекта от
Подрядчика организует создание
документации согласно
указанным выше требованиям и
участвует в её согласовании.
Шаблоны документации и
информация о процессе
предоставляются Заказчиком.
Подрядчик обязуется выполнять
корпоративные стандарты
компании ОАО НК «Роснефть» по
охране и безопасности труда, а
также требования нормативных
документов Компании,
регламентирующих вопросы
информационной безопасности.
6. Порядок контроля и приемки
системы
1. Виды, состав, объем и
методы испытаний
системы
Критерием приемки работ должно являться успешное прохождение
приемочного тестирования и опытно-промышленной эксплуатации и
передача технической документации Заказчику.
Система должна пройти приемочное тестирование, последовательность
проведения и входные данные для которого должны быть подготовлены
на Этапе 1 «Реализация» и отражены в рабочем документе «Концепция
проведения тестирования».
Приемочное тестирование Системы должно проводиться в соответствии
с рабочим документом «Концепция проведения тестирования».
№ п.п.
Результат
Критерий приемки результата
Этап 1. Реализация
1
1.1.
Реализация функционала
2
Этап 2. Тестирование
2.1.
Устав проекта
План работ
Концептуальный дизайн
Спецификация на
настройку Доработанный технический
проект
Реестр отчетов и формуляров с
классификацией по инструментам
реализации
Регламент ведения основных данных
Концепция проведения тестирования
Тестовые сценарии (для видов
тестирования, определенных в
документе «Концепции проведения
тестирования»)
Тестирование системы
Протокол тестирования системы (для
видов тестирования, определенных в
документе «Концепции проведения
тестирования»)
Реестр и график устранения замечаний
(в случае выявления замечаний)
Протокол устранения замечаний (в
случае выявления замечаний).
Доработанный пакет документов
согласно методическим указаниям ОАО
«НК Роснефть» оформление и
3
Этап 3. Проведение ОПЭ
Опытно-промышленная
эксплуатация
3.1
согласование документации КИС по
вводу ИС в промышленную
эксплуатацию/регистрации ИР для
промышленной эксплуатации
(необходимость доработки будет
определена в процессе реализации).
Стратегия миграции данных.
Концепция поддержки пользователей в
период опытно-промышленной
эксплуатации
Протокол миграции исторических
данных
Журнал и протокол устранения
замечаний в период ОПЭ
2. Требования к
тестированию системы
Проведение тестирования должно удовлетворять следующим
требованиям:
в рамках предварительных
испытаний выполняются
следующие виды тестирования:
o
o
o
функциональное
тестирование;
интеграционное
тестирование;
нагрузочное тестирование;
функциональное
тестирование проводится
консультантами проектной
команды Подрядчика. Целью
функционального тестирования
является проверка общей
работоспособности каждого из
компонентов системы,
корректность и качество отдельно
выполняемых функций системы и
процесса в целом.
интеграционное
тестирование проводится
ключевыми пользователями с
поддержкой проектной команды
Подрядчика. Интеграционное
тестирование проводится после
проведения функционального
тестирования для проверки связи
между компонентами, а также
взаимодействия с различными
частями системы.
Ключевые пользователи проводят
тестирование в рамках своего
организационного и
функционального объема;
нагрузочное
тестирование проводится
проектной команды Подрядчика
при контроле техническими
специалистами ООО «РНИнформ» после завершения
функционального и
интеграционного тестирования.
Нагрузочное тестирование
проводится для определения
соответствия производительности
системы требованиям к времени
выполнения основных групп
функций путем эмулирования
(при необходимости)
специализированным
программным обеспечением
одновременной работы
заявленного числа пользователей
системы и взаимодействия со
смежными системами. Для
проведения нагрузочного
тестирования Заказчик (при
необходимости) предоставляет
программно-техническую среду.
По результатам нагрузочного
тестирования Подрядчик
формирует предложения по
оптимизации производительности
системы, а также могут быть
предъявлены требования о
необходимости внесения
корректировок в сделанные
настройки/разработки и о повторе
предварительных испытаний в тех
частях, к которым возникли
замечания при проведении
нагрузочного теста
детальные критерии приемки
результатов испытаний и
классификация ошибок
определяются в рамках
разработки концепции
проведения тестирования;
сценарии тестирования и тестовые
данные разрабатываются
Подрядчиком на фазе Реализации
функционала и согласуются с
Заказчиком. При проведении
предварительных испытаний
допустимо использование
тестовых наборов данных, не
содержащих информацию
ограниченного доступа;
для части сценариев
функционального и
интеграционного тестирования
может проводиться
автоматизированное
тестирование. При разработке
концепции проведения
тестирования должны быть
определены бизнес-процессы для
сценариев автоматизированного
тестирования. Для выбранных
сценариев разработаны скрипты,
покрывающие все особенности
выполнения процессов в
соответствии с концептуальным
дизайном. Результаты
автоматизированного
тестирования должны
контролироваться и
протоколироваться проектной
командой Подрядчика и
специалистами ООО «РНИнформ» при функциональном
тестировании, ключевыми
пользователями совместно с
проектной командой Подрядчика
– при интеграционном
тестировании;
к началу предварительных
испытаний должны быть
настроены роли и полномочия
пользователей. При проведении
предварительных испытаний
ключевые пользователи должны
руководствоваться
операционными инструкциями;
по окончании каждого вида
тестирования представители
Подрядчика и Заказчика
составляют протокол
тестирования системы;
по окончании тестирования
представители Подрядчика и
Заказчика составляют протокол, в
котором указывается возможность
перехода к опытной эксплуатации
системы и необходимые
доработки с учетом полученных в
ходе тестирования замечаний.
7. Требования к составу и
содержанию работ по
подготовке объекта
автоматизации к вводу
системы в действие
В ходе выполнения проекта на объекте автоматизации требуется
выполнить работы по подготовке к вводу системы в действие. При
подготовке к вводу в эксплуатацию ИС Заказчик должен обеспечить
выполнение следующих работ:
1. Определить подразделение и
ответственных должностных лиц,
ответственных за внедрение и
проведение приемочного
тестирования ИС;
Схема 6.Обеспечить присутствие пользователей на обучении работе с
системой, проводимом Исполнителем;
Схема 7.Обеспечить соответствие помещений и рабочих мест
пользователей системы в соответствии с требованиями, изложенными в
настоящем ТЗ;
Схема 8.Обеспечить выполнение требований, предъявляемых к
программно-техническим средствам, на которых должно быть
развернуто программное обеспечение ИС;
Схема 9.Совместно с Исполнителем подготовить план развертывания
системы на технических средствах Заказчика;
Схема 10.Провести приемочное тестирование и опытно-промышленную
эксплуатацию ИС.
8. Требования к
документированию
Состав и комплектность документации определяется Исполнителем и
согласовывается с Заказчиком ОАО «НК «Роснефть». Документация
СБПУО не должна противоречить руководящим и нормативным
документам федерального уровня, требованиям документов
ОАО «НК «Роснефть», а также требованиям настоящего ТЗ.
Состав проектной и эксплуатационной документации, выпускаемой по
результатам проведения работ, приведен в Таблица .
В процессе выполнения работ по внедрению и адаптации программного
обеспечения Oracle Hyperion Planning состав документации может
уточняться по согласованию между Исполнителем и Заказчиком
ОАО «НК «Роснефть».
Документация, указанная в Таблица , выпускается и утверждается в двух
экземплярах (первый – для Заказчика, второй – для
ИсполнителяИсполнителя).
Документация выпускается на бумажных носителях и электронных
носителях. Электронная копия комплекта документации передается на
CD-R диске (дисках). Диск должен быть защищен от записи; иметь
надпись с указанием изготовителя, даты изготовления, названия
комплекта. В корневом каталоге диска должен находиться текстовый
файл содержания. Состав и содержание диска должно соответствовать
комплекту документации. Каждый физический раздел комплекта (том,
книга, альбом графических изображений и т.п.) должен быть
представлен в отдельном каталоге диска файлом (группой файлов)
электронного документа. Название каталога должно соответствовать
названию раздела.
Таблица . Состав проектной и эксплуатационной документации
№
Название документа
Требования
к документу
Требуется;
Язык: русский
Требуется;
Язык: русский
Ответственный за
формирование/актуализацию
Подрядчик
1.
Устав проекта
2.
План работ
3.
Техническое задание
(настоящий документ)
Требуется;
Язык: русский
Подрядчик
Технический проект
Требуется
доработка;
Язык: русский
Требуется;
Язык: русский
Подрядчик
4.
Подрядчик
Подрядчик
5.
Концептуальный дизайн
6.
Реестр отчетов и
формуляров с
классификацией по
инструментам
реализации
Требуется;
Язык: русский
7.
Регламент ведения
основных данных
Требуется;
Язык: русский
Подрядчик, Заказчик
8.
Регламент
предоставления доступа
Требуется;
Язык: русский
Подрядчик
9.
Технический паспорт ИС
Требуется;
Язык: русский
Подрядчик
10.
Руководство
администратора
Требуется;
Язык: русский
Подрядчик
11.
Руководство
пользователя
Требуется;
Язык: русский
Подрядчик
12.
Концепция обучения
Требуется;
Язык: русский
Подрядчик
13.
График проведения
обучения
Требуется;
Язык: русский
Подрядчик
14.
Протоколы проведения
обучения
Требуется;
Язык: русский
Подрядчик
Руководство по
обеспечению
непрерывности бизнеса
Спецификация на
настройку/Спецификация
на разработку
Концепция проведения
тестирования
Тестовые сценарии (для
видов тестирования,
Требуется;
Язык: русский
15.
16.
17.
18.
Подрядчик
Требуется;
Язык: русский
Требуется;
Язык: русский
Требуется;
Язык: русский
Подрядчик
Подрядчик
Подрядчик
Подрядчик
№
19.
20.
21.
22.
23.
24.
25.
Название документа
определенных в
документе «Концепции
проведения
тестирования»)
Протокол тестирования
системы (для видов
тестирования,
определенных в
документе «Концепции
проведения
тестирования»)
Реестр и график
устранения замечаний (в
случае выявления
замечаний)
Протокол устранения
замечаний (в случае
выявления замечаний)
Стратегия миграции
данных
Протокол миграции
исторических данных
Журнал и протокол
устранения замечаний в
период ОПЭ
Концепция поддержки
пользователей в период
опытно-промышленной
эксплуатации
Требования
к документу
Ответственный за
формирование/актуализацию
Подрядчик
Требуется;
Язык: русский
Подрядчик
Требуется;
Язык: русский
Требуется;
Язык: русский
Требуется;
Язык: русский
Требуется;
Язык: русский
Требуется;
Язык: русский
Подрядчик
Подрядчик
Подрядчик
Подрядчик
Подрядчик
Требуется;
Язык: русский
9. Требования к подрядчику
Работы по проектированию и реализации системы защиты информации,
должны осуществляться подрядной (субподрядной) организацией,
удовлетворяющей нижеприведенным требованиям.
Исполнитель должен соответствовать требованиям, устанавливаемым в
соответствии с законодательством Российской Федерации к
организациям, осуществляющим поставки товаров, выполнение работ,
оказание услуг, являющихся предметом данного лота, включая
следующие лицензии, аттестаты и свидетельства:
• Лицензия на деятельность по
разработке и (или) производству
средств защиты
конфиденциальной информации
• Лицензия на деятельность по
технической защите
конфиденциальной информации.
• Лицензия на осуществление
разработки, производства
шифровальных
(криптографических) средств,
защищенных с использованием
шифровальных
(криптографических) средств
информационных и
телекоммуникационных систем
• Лицензия на осуществление
распространения шифровальных
(криптографических) средств
• Лицензия на осуществление
технического обслуживания
шифровальных
(криптографических) средств
Исполнитель обязан подтвердить свою квалификацию следующими
сертификатами сотрудников:
• CISSP (не менее 1 специалиста);
• CISA (либо эквивалентных: CEH,
OSCP) или BSI ISO 27001 Lead
Auditor (не менее 1 специалиста).
