ТТ SD - transneftenergo.transneft.rutransneftenergo.transneft.ru/.../2013432/tne_tt_servicede… · Web viewОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ

ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ «ТРАНСНЕФТЬЭНЕРГО»

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

на создание информационной системы

«УПРАВЛЕНИЯ ИНФОРМАЦИОННЫМИ ТЕХНОЛОГИЯМИ И СЕРВИСНЫМ ОБСЛУЖИВАНИЕМ, АВТОМАТИЗАЦИЯ ПРОЦЕССОВ И

СЛУЖБ SERVICE DESK»(ИС «SERVICE DESK»)

Москва, 2015 г.

ООО «Транснефтьэнерго»

Информационная система «Управление информационными технологиями и сервисным обслуживанием, автоматизация

процессов и служб Service Desk» (ИС «Service Desk»). Технические требования

Содержание1 Общие сведения..........................................................................................................11.1 Цели и задачи документа.................................................................................................................1

1.2 Наименование и реквизиты.............................................................................................................1

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

3 Обозначения и сокращения......................................................................................4

4 Общие сведения..........................................................................................................44.1 Рамки проекта....................................................................................................................................4

5 Требования к проекту................................................................................................45.1 Требования к результатам проекта...............................................................................................5

6 Назначения системы и цели внедрения.................................................................86.1 Назначение системы..........................................................................................................................8

6.2 Цель внедрения системы..................................................................................................................9

6.3 Задачи системы................................................................................................................................10

6.3.1 Задачи по разработке и формализации процессов и процедур...........................................10

6.3.2 Задачи по автоматизации разработанных процессов...........................................................10

6 Требования к системе..............................................................................................126.1 Общие требования к Системе.......................................................................................................12

6.1.1 Требования к Системе в целом.................................................................................................126.1.2 Требования к локализации Системы.......................................................................................146.1.3 Требования к прикладным характеристикам Системы..........................................................156.1.4 Соответствие нормативно-техническим требованиям...........................................................166.1.5 Функциональная архитектура Системы..................................................................................166.1.6 Требования к модулям Системы..............................................................................................176.1.7 Требования к обеспечению доступа к информации и ролям пользователей.......................256.1.8 Требования к численности и квалификации пользователей системы..................................266.1.9 Требования к режиму эксплуатации........................................................................................266.1.10 Требования к надежности.....................................................................................................266.1.11 Требования к информационной безопасности....................................................................276.1.12 Требования по сохранности информации при авариях.....................................................306.1.13 Требования к эргономике и технической эстетике............................................................31

6.2 Требования к развитию и объему внедрения системы............................................................31

6.2.1 Требования к объему внедрения..............................................................................................316.2.2 Требования к серверному оборудованию................................................................................31

7 Порядок создания, приемки и контроля системы.............................................327.1 Общие требования...........................................................................................................................32

7.2 Этапы и результаты работ по созданию Системы:...................................................................32

II




7.3 Требования к испытаниям Системы и ее составных частей..................................................34

7.3.1 Виды испытаний........................................................................................................................347.3.2 Место проведения испытаний..................................................................................................34

7.4 Мероприятия по обучению персонала.........................................................................................34

7.5 Мероприятия по организационному обеспечению...................................................................35

7.6 Требования к технической поддержке........................................................................................35

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

Приложение А Целевая архитектура системы..........................................................37

Приложение Б Предварительный перечень сводных отчетов...............................38

III




1 Общие сведения1.1 Цели и задачи документаНастоящий документ представляет собой технические требования Заказчика на

разработку информационной системы «Управление информационными технологиями и сервисным обслуживанием, автоматизация процессов и служб Service Desk» (ИС «Service Desk»).

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

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

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

1.2 Наименование и реквизитыПолное наименование системы – Информационная система «Управление

информационными технологиями и сервисным обслуживанием, автоматизация процессов и служб Service Desk».

Условное обозначение системы –ИС «Service Desk».Заказчик – ООО «Транснефтьэнерго».Исполнитель – определяется закупочной процедурой.

1




2 Термины и определенияВ настоящем документе применены следующие термины с соответствующими

определениями: 2.1 база знаний; БЗ: совокупность структурированной информации, накопленной

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

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

2.3 интерфейс: набор графических элементов (текстовых блоков, кнопок, ссылок и пр.), представленных на экране компьютера при работе с Системой.

2.4 изменение: добавление, модификация или удаление чего-либо, способного оказать влияние на ИТ Услуги.

2.5 инцидент: незапланированное прерывание ИТ-услуги или снижение качества ИТ услуги (ИЛИ сбой Конфигурационной Единицы, который еще не повлиял на услугу).

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

2.7 конфигурационная Единица; КЕ: любой компонент, который нуждается в управлении для того, чтобы предоставлять ИТ услугу.

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

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

2.10 ответственный, ответственный исполнитель: сотрудник отдела, который отвечает за запрос на данном этапе жизненного цикла запроса.

2.11 ответственный, ответственный отдел: отдел, который отвечает за запрос на данном этапе жизненного цикла запроса.

2.12 пользователь: юридическое или физическое лицо, пользующееся услугой на основании договора (соглашения) или внутреннего регламента.

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

2.14 права доступа: полномочия пользователя на выполнение определенных операций в системе (создание, чтение, изменение и удаление информации).

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

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

2.17 управление Запросами на обслуживание: процесс, отвечающий за управление жизненным циклом всех запросов на обслуживание.

2




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

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

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

2.21 управление Конфигурациями: процесс, отвечающий за управление информацией о Конфигурационных Единицах, необходимой для предоставления ИТ услуги, включая их Взаимоотношения.

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

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

2.24 управление Уровнем Услуг (SLM): процесс, отвечающий за обсуждение Соглашений об Уровне услуг, и гарантирующий их выполнение.

2.25 услуга, сервис: описанная совокупность средств, которая удовлетворяет одну или несколько потребностей пользователя, способствует достижению его бизнес-целей, а также воспринимается пользователем как согласованное единое целое.

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

2.27 CMDB: Configuration Management Data Base. База данных конфигурационных единиц, используемая для хранения информации об элементах ИТ-инфраструктуры на всем протяжении их жизненного цикла.

2.28 ITIL: Information Technology Infrastructure Library. Библиотека передового опыта по управлению информационными технологиями.

2.29 ITSM: Information Technology Service Management. Сервисный подход к предоставлению информационных технологий.

2.30 Kerberos: протокол сетевой аутентификации.2.31 KPI: Key Performance Indicators, показатели деятельности

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

2.32 LDAP: Lightweight Directory Access Protocol. Протокол доступа к службе каталогов.

2.33 MS Active Directory: LDAP-реализация службы каталогов.2.34 NTLM: NT LAN Manager. Протокол сетевой аутентификации.

3




2.35 OLA: Operation Level Agreement - Соглашение между поставщиком ИТ услуг и другой частью той же организации.2.36 SLA: Service Level Agreement - Соглашение об уровне предоставления услуг.2.37 Workflow (рабочий поток) - Настраиваемая последовательность действий или этапов по созданию/изменению/удалению объектов и их параметров, в также их взаимосвязей в информационной системе.

3 Обозначения и сокращенияВ настоящем документе применены следующие обозначения и сокращения:

Заказчик – ООО «Транснефтьэнерго»;

Проект – проект по построению единой системы поддержки процессов управления

ИТ;

Система – программный комплекс по автоматизации процессов управления ИТ;

Служба Каталогов – Microsoft Active Directory;

Специалист – сотрудник ИТ подразделения участвующий в поддержке и/или

предоставлении ИТ услуг;

4 Общие сведенияДля обеспечения гарантированного уровня предоставления и поддержки ИТ услуг

требуется создать единую систему поддержки процессов управления ИТ.

4.1 Рамки проектаВ рамках проекта должны быть разработаны и автоматизированы следующие

процессы ITIL: - Управление запросами на обслуживание;- Управление инцидентами;- Управление уровнем сервиса;Для реализации проекта предполагается выполнение следующих этапов работ:- Проведение аудита текущего состояния процессов управления ИТ;- Разработка регламентов и процессов управления ИТ на основе рекомендаций

ITIL/ITSM;- Внедрение программного комплекса, автоматизирующего разработанные

регламенты и процессы управления ИТ.

5 Требования к проектуВ рамках проекта должен быть исполнен необходимый комплекс мер для получения

продукта проекта, его успешной дальнейшей эксплуатации и развития:- Поставлено необходимое программное обеспечение;- Выполнены необходимые работы;

4




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

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

5.1 Требования к результатам проекта5.1.1 Общие требования к каждому внедряемому процессуВ результате внедрения каждого процесса управления ИТ должны быть получены

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

Специалистов);- Система настроена согласно разработанным регламентам процесса.5.1.2 Требования к процессу управления Инцидентами/запросами на

обслуживаниеПроцесс Управления Инцидентами/Запросами на обслуживание, должен включать в

себя следующие связанные элементы:- Управление Задачами на основании Инцидента/Запроса на обслуживание;- Взаимодействие с другими процессами.5.1.2.1 Общие требования к процессу Управления Инцидентами/ Запросами на

обслуживаниеПри реализации процесса Управления Инцидентами/Запросами на обслуживание,

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

предоставления и поддержки ИТ сервисов);- Определены и настроены в Системе контрагенты, предоставляющие внешние

сервисы;- Разработаны процедуры и настроены по следующим вариантам регистрации

инцидентов/запросов на обслуживание: Регистрация Пользователем; Регистрация сотрудником Службы Единого Заказчика; Регистрация сотрудником первой линии поддержки на основании

обращения Пользователя или сотрудника Службы Единого Заказчика; Регистрация Пользователем осуществляется одним из трех способов:

• Через web-портал;• Посредством почтового сообщения;

5




• Посредством телефонного обращения на первую линию поддержки.

- Разработан и настроен механизм информирования Пользователей и сотрудников Службы Единого Заказчика о ходе исполнения Инцидентов/Запросов на обслуживание;

- Определены и настроены категории Инцидентов/Запросов на обслуживание;- Разработаны и автоматизированы регламенты, по исполнению Инцидента/Запроса

на обслуживание;- Определена и настроена ролевая модель доступа к объектам Системы для

участников процесса;- При регистрации обращения, в зависимости от связанной ИТ услуги и категории

инцидента/запроса на обслуживание должны определяться обязательные для заполнения поля;

- Разработаны механизмы оптимизации работы с массовыми Инцидентами (вызванными единой причиной);

- Разработаны механизмы автоматического назначения на ответственную команду/Специалиста, в зависимости от атрибутов, заполненных при регистрации (с возможностью ручного назначения/переназначения);

- Определены и настроены механизмы оценки влияния Инцидента/Запроса на обслуживание (в разрезе сервисов и организационных масштабов);

- Разработаны механизмы управления Задачами при работе над Инцидентом/Запросом на обслуживание (возможность использовать преднастроенные последовательности Задач для типовых Инцидентов/Запросов на обслуживание);

- Возможность назначения Инцидента/Запроса на обслуживание как на функциональную команду, так и в персональную ответственность Специалисту;

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

Инцидента/Запроса на обслуживание;- Определены правила оповещения (события, круг заинтересованных лиц, и т.п.) и

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

связи) с Пользователем при устранении Инцидента/выполнения Запроса на обслуживание;

- Определены метрики процесса, настроены отчеты по метрикам процесса, как для внутреннего использования, так и для осуществления контроля предоставления и поддержки ИТ услуг сотрудниками Службы Единого Заказчика.

5.1.2.2 Требования к механизму управления ЗадачамиДолжны быть разработаны и настроены механизмы:- Назначения/переназначения Задач;

6




- Контроля исполнения Задач;- Управления приоритетами Задач;- Оповещения заинтересованных лиц о назначении/исполнении (или других

событиях) Задачи;- Иерархической эскалации по определенным условиям.5.1.2.3 Требования к взаимодействию с другими процессамиПри реализации процессов Управления Инцидентами/Запросами на обслуживание

должна быть разработана схема взаимодействия со смежными процессами управления ИТ:- Взаимодействие с процессом управления уровнем сервиса в части определения

приоритетов работы над Инцидентом/Запросом на обслуживание.- Определены другие предоставляемые/получаемые данные и логика

взаимодействия с процессом Управления Знаниями;5.1.3 Требования к процессу Управления Каталогом Сервисов/Уровнем

СервисаНа данном этапе внедрения процесс Управления Уровнем Сервиса ограничивается

проработкой сервисов, предоставляемых потребителям. При реализации процесса Управления Каталогом Сервисов/Уровнем Сервиса, должны

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

категоризация ИТ услуг;- Определен и настроен список предоставляемых ИТ услуг;- Определены и настроены виды Соглашений о предоставлении ИТ услуг;- Определены и настроены Соглашения по каждому пакету ИТ услуг для каждой

группы потребителей ИТ услуг (механизм должен позволять строить связи «многие ко многим»: одна Услуга может предоставляться по нескольким Соглашениям, также как по одному Соглашению может предоставляться несколько Услуг.);

- Для каждого сервиса определен и настроен набор параметров, характеризующих ИТ услугу, включая:

Наименование; Описание; Основные функции; Зависимость/влияние на другие сервисы; Варианты уровней предоставления;

- Разработана и настроена ролевая модель доступа к обслуживанию Каталога Сервисов/Соглашений по уровням сервисов;

- Определено нормативное время обработки запросов (Инцидентов, Запросов на обслуживание, Изменений, Событий);

- Разработан типовой шаблон документа «Соглашение об уровне сервиса», для заключения с ДЗО и филиалами;

7




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

- Определена и настроена ролевая модель доступа к объектам Системы для участников процесса;

- Разработаны и автоматизированы процедуры редактирования Каталога ИТ услуг;

- Разработаны и автоматизированы процедуры редактирования Соглашений об уровне ИТ услуг;

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

Управлению Уровнем Услуг и ключевым показателям эффективности процесса;- Настроены отчеты, на основании определенных ключевых показателей

эффективности процесса (приложение Б).- Определены метрики процесса для осуществления контроля предоставления и

поддержки ИТ услуг сотрудниками Службы Единого Заказчика;- Настроены отчеты для сотрудников Службы Единого Заказчика.

Итоговое количество и формат отчетов определяется на стадии проектирования.5.1.4 Требования к интеграциям с внешними подсистемамиПри реализации этапов проекта должны быть настроены интеграции Системы с

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

механизмов оповещений, а также механизмов приема/регистрации обращений, исходя из логики процессов

5.1.4.2 Требования к интеграции с кадровой системойИнтеграция с кадровой системой должна обеспечивать:

- Автоматизированное первичное наполнение и периодическую синхронизацию организационно-штатной структуры (настроенной в Системе) с учетными записями Пользователей;

5.1.4.3 Требования к интеграции с системой мониторингаИнтеграция с системой мониторинга ТНЭ должна обеспечивать функционирование

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

6 Назначения системы и цели внедрения6.1 Назначение системыСистема предназначена для автоматизации процессов эксплуатации ИТ-услуг,

предоставляемых для структурных подразделений ТНЭ.

8




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

6.2 Цель внедрения системыВнедрение системы должно обеспечивать основные цели:

1) Увеличение прозрачности бизнес-процессов Общества:- Автоматизированная классификация и маршрутизация обращений и инцидентов, в

том числе между линиями поддержки;- Обеспечение доступа специалистов всех линий поддержки к актуальной

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

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

- Сквозная автоматизация бизнес-процесса Общества Б08.00 «Информационные технологии»;

- Получение исходных данных для стратегического планирования;- Получение инструментов управления ИТ подразделениями;- Предоставление необходимых инструментов для успешного функционирования

Службы Единого Заказчика в ДЗО: механизма заказа услуг; механизма уведомлений и эскалации; отчетности по KPI, выполнению SLA и заказанным услугам; доступ к каталогу услуг;

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

2) Сокращение стоимости операций:- Уменьшение времени реагирования на обращения и инциденты;- Уменьшение времени поиска типовых и обходных решений обращений и

инцидентов;- Сокращение времени на построение сводной отчетности;- Автоматизация рутинных операций.

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

интерфейсу Системы для самостоятельного создания обращений в Службу

9




поддержки и отслеживания состояния обращений на всех этапах их жизненного цикла;

6.3 Задачи системыДля достижения указанных целей необходимо решать задачи:

- Разработка и формализация процессов и процедура предоставления и поддержки ИТ услуг;

- Автоматизация разработанных процессов.

6.3.1 Задачи по разработке и формализации процессов и процедур

- Сформировать список ИТ услуг, предоставляемых бизнес подразделениям;- Зафиксировать соглашения по уровню сервиса на предоставляемые услуги;- Организовать единую точку по приему всех видов обращений пользователей и

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

(формализовать процессы): Унифицировать типовые процессы (Выделить типовые запросы и

зафиксировать маршрут его прохождения); Разработать классификацию выполняемых работ; Зафиксировать нормативные трудозатраты и временные рамки при

осуществлении работ; Зафиксировать распределение обязанностей/ответственностей при

осуществлении поддержки; Зафиксировать порядок взаимодействия между специалистами при

поддержке ИТ услуг; Обеспечить своевременное привлечение специалистов более высокой

квалификации или с более высокими полномочиями (эскалация).

6.3.2 Задачи по автоматизации разработанных процессов

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

Контроля исполнения обращений пользователей; Контроля исполнения обязательств по предоставлению и поддержке

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

своевременное информирование пользователей о внедряемых изменениях и других работах;

Контроля фактического выполнения соглашения об уровне обслуживания;

10




Контроля качества выполнения работ по запросам (в том числе получения обратной связи от бизнес пользователей);

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

типовых решений и алгоритмов по возникающим запросам (работа с Базой Знаний).

Накопления и анализа информации для поиска «узких» мест и корневых проблем;

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

необходимости выполнения работ по запросам.- Настроить интеграцию Системы:

С кадровой системой/AD; С системой мониторинга Автоматизированной информационно-

измерительной системы коммерческого учета электроэнергии и Автоматизированной системы технического учета электроэнергии;

С почтовым сервером.

6.4

11




7 Требования к системе7.1 Общие требования к Системе 7.1.1 Требования к Системе в целом

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

а) Являться сертифицированным промышленным решением;б) Иметь ряд успешных внедрений в РФ;в) Должна иметь сертификат ITIL v.2011 по следующим процессам:

Управление инцидентами; Управление запросами на обслуживание; Управление проблемами; Управление запросами на изменение; Управление событиями; Управление знаниями; Управление каталогом услуг; Управление уровнем услуг; Управление сервисными активами и конфигурациями.

г) Быть обеспеченной профессиональной технической поддержкой через развитую партнерскую сеть на территории РФ;

д) Быть построена по технологии клиент-сервер с использованием трехуровневой архитектуры: уровень хранилища данных, уровень бизнес-логики, клиентское приложение. Информационный обмен между уровнем хранилища данных и уровнем бизнес-логики должен осуществляться по протоколу TCP/IP через корпоративную сеть. Информационный обмен между уровнем бизнес-логики и клиентским приложением должен осуществляться через корпоративную сеть. Серверная часть Системы должна использовать промышленную СУБД. Клиентское приложение должно функционировать на рабочих станциях (ПК) под управлением Microsoft Windows XP и выше;

е) В качестве клиентского приложения для личного кабинета клиента должен использоваться один из следующих браузеров: Internet Explorer не ниже версии 9, Google Chrome, Mozilla Firefox.

ж) Должна иметь возможность применения стандартных унифицированных решений, поставляемых производителем Системы;

7.1.1.1 Требование к лицензионному обеспечению

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

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

12




- В рамках работ по договору Исполнителем прикладное ПО должно быть укомплектовано необходимым количеством лицензий;

- Необходимые лицензии общесистемного ПО (ОС, Office), не входящие в Microsoft Enterprise Agreement, должны быть предоставлены Исполнителем в рамках договора по созданию Системы;

- Закупка лицензий на прикладное ПО должна быть осуществлена не ранее запуска Системы в эксплуатацию.

- Все лицензии на программные продукты должны быть оформлены на имя Заказчика в соответствии с требованиями законодательства РФ;

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

7.1.1.2 Требования к архитектуре

Архитектура программно-аппаратных решений должна обеспечивать:

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

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

дополнительных приложений на предлагаемой платформе.

7.1.1.3 Унификация, модульность, конфигурирование, масштабируемость

Система должна обеспечивать:- Модульный принцип построения Системы с учетом возможности расширения

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

для работы пользователей элементы, в том числе: ввод информации, запись информации, представление отчетов;

- Возможность оперативного доступа к информации на центральном сервере вне зависимости от территориального расположения места ввода или запроса информации;

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

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

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

13




- Увеличение числа пользователей Системы и изменение организационной структуры предприятия не должно влиять на производительность Системы;

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

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

7.1.1.4 Требования к модернизации

Система должна допускать следующую модернизацию:

- Развитие сетевого оборудования и архитектуры локальных вычислительных сетей;

- Замена компьютеров при условии соответствия новых компьютеров требованиям, определенным в документации на типовые и поставляемые программные средства;

- Централизованную установку дополнительных модулей и обновление версий Системы;

- Расширение функциональности Системы;

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

Критериями открытости служат:

- Четко специфицированные структуры базы данных и интерфейсов обмена данными;

- Поддержка технологии реализации интерфейсов взаимодействия с внешними системами на технологиях интерактивного обмена XML-сообщениями;

- Модульная структура программного обеспечения;

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

7.1.1.5 Требования к интерфейсам

Система должна обладать стандартным набором интерфейсов по интеграции с другими системами, эксплуатируемыми в Обществе, в том числе:

- Системой мониторинга Автоматизированной информационно-измерительной системы коммерческого учета электроэнергии и Автоматизированной системы технического учета электроэнергии;

- Почтовый сервер.

- Кадровая система.

14




7.1.2 Требования к локализации Системы

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

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

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

7.1.3.1 Модульность

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

Расширение функционала должно происходить без остановки основных бизнес-процессов.

7.1.3.2 Масштабируемость

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

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

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

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

7.1.3.3 Наглядность

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

- Конфигурация визуальных представлений (внешнего вида и наполнения экранных форм);

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

7.1.3.4 Системность

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

7.1.3.5 Персонализация

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

15




7.1.3.6 Единство графического представления

При проектировании и разработке пользовательских интерфейсов:

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

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

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

7.1.3.7 Быстродействие

Система должна обеспечивать высокую скорость выполнения операций при низких требованиях к аппаратному обеспечению и каналам связи (64 kB/s на пользователя, 1 MB/s на канал, время отклика сети 100 ms). Увеличение числа пользователей Системы и изменение организационной структуры Общества не должно влиять на производительность Системы.

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

- для операций навигации по экранным формам системы –5 сек;- для операций формирования справок и выписок – 10 сек.

7.1.4 Соответствие нормативно-техническим требованиям

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

- ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания;

- ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем;

- РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов».

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

В рамках подготовки Технического Задания перечень нормативно-технических требований может быть уточнен с учетом:

- Появления новых требований законодательства; - Требований законодательства, утративших действие;- Требований к документированию и методологии внедрения Информационных

систем, в зависимости от выбранного поставщика ПО.

16




7.1.5 Функциональная архитектура Системы

Функциональная архитектура Системы представлена в Приложении А.

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

1) Модуль личного кабинета пользователя;2) Модуль управления поддержкой пользователей и запросами (управление

инцидентами);3) Модуль управления конфигурациями и CMDB.4) Модуль управления изменениями.5) Модуль управления услугами и уровнем обслуживания.6) Модуль управления Базой Знаний (управление знаниями).7) Модуль управления проблемами (управление проблемами).8) Модуль управления организационной и ролевой структурой.9) Модуль обработки электронных писем.10) Модуль интеграции.11) Модуль отчетности.12) Модуль универсального импорта данных.13) Модуль управления правами.Перечень функций, реализуемых в данных модулях, должен быть уточнен на этапе

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

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

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

7.1.6 Требования к модулям Системы

7.1.6.1 Модуль личного кабинета пользователя

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

- просмотр и изменение данных о сотруднике: просмотр общей информации: ФИО, должность, руководитель, логин; редактирование контактной информации (для пользователей,

заведенных вручную); изменение пароля (для пользователей, заведенных «вручную»);

- регистрация запросов: регистрация запроса с использованием помощника; прикрепление файлов при регистрации запроса;

17




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

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

- просмотр информации о своих согласованиях, осуществление согласований: просмотр списка поступивших согласований; просмотр подробной информации о каждом согласовании; утверждение или отклонение работ, представленных для согласования,

согласно указанным срокам;

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

7.1.6.2 Модуль управления поддержкой пользователей и запросами (Управление Инцидентами)

Основной задачей, исполняемой модулем, является автоматизация подпроцессов: Взаимодействие с пользователями, Управление инцидентами.

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

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

- регистрацию запроса оператором с помощью web-приложения (тонкого клиента);- отображение оператору в момент регистрации информации об уже открытых

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

приходят в назначаемые почтовые ящики. Адреса назначаемых почтовых ящиков задаются в настройках Системы;

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

- использование классификаторов и справочников, для эффективного заполнения и модификации записей базы Запросов через карточки Запросов:

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

18




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

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

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

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

В части прохождения запросов модуль должен предоставлять:- средства для внесения дополнительной информации и изменения приоритета

Запроса на протяжении всего жизненного цикла Запроса (после его первичной регистрации до момента закрытия);

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

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

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

экранных формах запросов;- средства ведения списка комментариев по Запросу, с разделением комментариев на

внутренние (видимые сотрудникам) и общие (видимые, в том числе, самому пользователю).

В части контроля выполнения регламентов по Запросам модуль должен обеспечивать:

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

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

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

настройками (по событиям, по регламентным срокам).

19




В части закрытия Запросов Система должна обеспечивать: - при закрытии Запроса Система должна предоставлять возможность ввода описания

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

решений;

- автоматическое оповещение пользователей о завершении обработки их обращений с возможностью подтвердить или опровергнуть успешность решения непосредственно по электронной почте и через web-портал самообслуживания;

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

В части настройки workflow Запросов Система должна обеспечивать: - поддержку различных типов запросов, каждый из которых определяет маршрут

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

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

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

участие в ее решении;- возможность настройки функциональной и административной эскалации Запроса, в

соответствии с настроенными условиями эскалации;- автоматическая передача ответственности за Запрос при изменении состояния

Запроса;- выполнение определенной операции над несколькими выбранными объектами

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

приводит к инициации другого процесса.

В части работы с «нарядами на работы» Система должна обеспечивать: - создание и управление нарядами на работу, которые необходимо выполнить для

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

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

нарядов по разрешению Запроса;

20




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

В части работы с массовыми запросами и авариями Система должна обеспечивать:

- регистрацию системных сбоев по инициативе специалистов;- раздельную регистрацию обращений пользователей и системных сбоев, с

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

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

7.1.6.3 Модуль управления конфигурациями и CMDB

Модуль должен позволять автоматизировать процесс управления конфигурациями и строить структуру CMDB.

Подсистема должна предоставлять возможность:- вести учет ИТ-активов и конфигурационных единиц (КЕ), понимать их связи

и влияние друг на друга и на услуги;- распределять ролевую ответственность за сопровождение КЕ, автоматизируя часть

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

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

на обслуживание, управление проблемами, управление изменениями);- управления лицензиями, услугами, SLA, OLA, UC;- определения местоположения КЕ и ответственного за КЕ;- контроля остаточной стоимости КЕ;- контроля количества остатков КЕ для использования;- управления программным обеспечением и техническим обслуживанием;- отслеживания гарантийных сроков;- ведения истории всех связанных с КЕ инцидентов, запросов на обслуживание,

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

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

- настраиваемая модель доступа к информации в CMDB/CMS до параметра конкретной КЕ;

21




7.1.6.4 Модуль управления изменениями

Модуль должен позволять автоматизировать процесс управления изменениями.Модуль должен предоставлять возможность:- планировать предстоящие изменения;- проводить управляемые согласования изменений с заинтересованными сторонами;- контролировать ответственность за внедрение изменений;- вести учет затрат на подготовку и внедрение изменений;- анализировать результаты изменений.

Модуль должен обладать следующей функциональностью:

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

команду;- возможность планирования проведения поэтапного изменения;- расчет запланированного и реально потраченного времени;- анализ внедрения изменений;- возможность определения группы с фиксированным составом согласующих лиц;- контроль результатов согласований;- фиксация в системе итогового решения по согласованию изменения;- согласование изменений посредством e-mail или через портал

самообслуживания;- использование сложных согласований для важных изменений.

7.1.6.5 Модуль управления проблемами

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

- возможность хранить информацию о проблемах (список атрибутов проблемы будет определен на этапе проектирования);

- графическое представление жизненного циклов проблем в виде диаграмм на экранных формах проблем;

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

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

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

7.1.6.6 Модуль управления услугами и уровнем обслуживания

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

22




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

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

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

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

приоритета обслуживания и подразделений, ответственных за разрешения Запроса;

данные о нормативном времени разрешения Запроса, в зависимости от приоритета обслуживания, класса обслуживания (временном периоде оказания услуг) и критичности Запроса (степени влияния на оказание услуги);

данные о процедуре эскалации Запроса в зависимости от приоритета;

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

услуг с оборудованием, с помощью которого они предоставляются.

7.1.6.7 Модуль управления Базой Знаний (Управление Знаниями) и поиска

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

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

инцидентов;- управление, ввод, структурирование и предоставление хранящейся в модуле

информации;

7.1.6.8 Модуль управления организационной и ролевой структурой

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

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

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

сотрудниках, в них входящих;

23




- управление взаимоотношениями между отделами/группами в рамках обработки запросов;

- синхронизацию организационной структуры с внешними источниками, в том числе с MS Active Directory по протоколу LDAP.

7.1.6.9 Модуль обработки электронных писем

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

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

получения почты: IMAP, POP. Протоколы, используемые для отправки почты: SMTP;

- настройку периодической загрузки почты с одного или нескольких почтовых ящиков;

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

- возможность формировать логику обработки таким образом, что неопознанные обращения не регистрируются (при этом пользователю отправляется автоответ) или регистрируются с настройками «по умолчанию» и далее обрабатываются оператором;

- возможность отфильтровывать спам, используя списки белых/черных списков;- возможность прикрепления первоначального письмо пользователя в формате *.eml;- возможность прикрепления файлов, полученных в электронном письме, к запросу в

Системе. Возможность настроить правило, по которому будут обрабатываться только определенные расширения (Например: вложенные файлы формата jpg, gif, png, txt, htm и html прикрепляются к запросу, а электронные письма, содержащие файлы с другими расширениями, не регистрируются);

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

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

дата/время получения электронного обращения; дата/время обработки электронного обращения; электронный адрес отправителя; электронный адрес получателя; номер зарегистрированного запроса; причина отклонения электронного письма; статус обращения: не получено из-за внутренней ошибки/получено и

обработано/получено, но не обработано.

7.1.6.10 Модуль интегрирования

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

24




- WebService. Должен предоставляться доступ через WebService API к основным функциям ППО должно, а также должна иметься возможность доступа к внешним системам с использованием технологии WebService;

- передача данных между системами в режиме "запрос-ответ" по протоколу HTTP. По HTTP могут передаваться как XML-документы, так и произвольный текст или файлы;

- удаленный RPC-вызов метода через http, с передачей дополнительных параметров;- прямой доступ к БД из внешних систем на чтение;- прямой доступ к БД внешних систем. Поддерживаемые БД: MySQL, Postgres,

Oracle 9/10/11, MS SQL 2005/2008;- синхронизация Систем через промежуточную БД;- обмен файлами. В качестве файла, может выступать структурированный XML

оговоренного формата;- обмен данными по e-mail.

7.1.6.11 Модуль универсального импорта данных

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

- импорт данных об объектах Системы из внешнего источника формата .csv; - синхронизацию данных об объектах, хранящихся в Системе, с данными из

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

объектов из внешних файлов формата .csv; - формирование отчетов по результатам импорта и синхронизации данных.

7.1.6.12 Модуль управления правами

Модуль управления правами обеспечивает:- назначение пользователям набора ролей/профилей прав в Системе;- организация доступа в Систему для сотрудников, которым выданы реквизиты

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

ролями/профилями;- разграничение прав доступа к информации модулей в соответствии с

ролями/профилями.

7.1.6.13 Модуль отчетности

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

- конструктор построение отчетов с возможностью сохранения шаблонов.- использования внутренних средств построения отчетов по заданным шаблонам;- детализации отчета по временным периодам (год, месяц, сутки, час);- экспорта содержания отчетов в файлы Microsoft Excel и PDF.

25




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

7.1.7 Требования к обеспечению доступа к информации и ролям пользователей

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

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

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

7.1.8 Требования к численности и квалификации пользователей системы

Пользователями Системы являются:

- Со стороны исполнителей ТНЭ (общее количество рабочих мест – до 20):

Специалисты отдела администрирования и защиты информации.

Специалисты отдела информатизации.

Специалисты отдела технического обслуживания и эксплуатации.

- Со стороны клиентов специалисты ТНЕ и ОСТ (общее количество рабочих мест – без ограничений).

7.1.9 Требования к режиму эксплуатации

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

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

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

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

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

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

26




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

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

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

7.1.11 Требования к информационной безопасности

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

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

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

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

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

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

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

27




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

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

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

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

Обеспечение сетевой безопасности при взаимодействии с другими информационными системами должно отвечать требованиям отраслевого регламента, принятого в ОР-35.240.00-КТН-099-07.

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

На АРМ пользователей, подключаемых к ИС, должен быть выполнен следующий комплекс мер по их защите:

- исключение несанкционированной установки или реконфигурации системного, прикладного ПО и сетевой политики АРМ пользователей Системы;

- ограничение возможности физического доступа к АРМ пользователей с целью изменения их конфигурации;

- исключение несанкционированного доступа к ресурсам АРМ пользователей Системы, на котором обрабатывается защищаемая информация;

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

- исключение возможностей несанкционированного просмотра защищаемой информации с монитора АРМ, в том числе в отсутствие пользователя;

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

- исключение возможности бесконтрольного изменения режима подключения АРМ к вычислительным сетям, в том числе к сетям общего пользования;

- антивирусная защита АРМ пользователей Системы;- периодическое обновление операционных систем, прикладного ПО и средств

защиты информации от несанкционированного доступа;- ведение системного журнала аудита по основным событиям ИБ.

28




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

7.1.11.1 Требования к программному обеспечению

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

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

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

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

Должна осуществляться идентификация субъектов доступа при входе в Систему.Должна осуществляться аутентификация (проверка подлинности) субъекта при

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

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

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

ПО не должно требовать использования в штатном режиме работы пользователей съемных носителей информации. Все типовые операции обмена файлами должны быть автоматизированы. Место расположения объекта для выгрузки/загрузки должно быть настраиваемым и должно позволять загружать/выгружать файлы с ресурса сети, идентифицируемого IP-адресом или DNS-именем.

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

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

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

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

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

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

В параметрах регистрации должны быть указаны:- Дата и время события;- Вид события;

29




- Идентификатор пользователя.

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

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

7.1.11.2 Требования к работам по созданию и поддержке программного обеспечения

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

- Календарный план проекта;- Устав проекта;- Отчет об обследовании текущей практики управления ИТ и состоянии процессов;- Регламент процессов управления ИТ;- Каталог ИТ услуг;- Отчет об инсталляции Системы;- Техническое задание на настройку Системы;- Частное техническое задание на интеграцию с внешней базой хранения

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

Документация на ПО должна содержать:

- Описание реализованных защитных мер;- Перечень используемых протоколов/сервисов с указанием их назначения;- Перечень и описание предустановленных учетных записей, в том числе

технологических.

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

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

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

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

Должна быть обеспечена совместимость прикладного ПО с критичными 30




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

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

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

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

- Аварийное отключение питания;

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

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

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

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

деятельности;- Все сообщения об успешном выполнении или возникающих ошибках должны

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

7.2 Требования к развитию и объему внедрения системы7.2.1 Требования к объему внедрения

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

7.2.2 Требования к серверному оборудованию

7.2.2.1 Требования к продуктивному серверу ИС «Service Desk»:

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

- Сервер приложений:Многоядерные 64-разрядный процессоры – Intel Xeon серии 5500/5600/7400/7500,

AMD Six-Core AMD Opterontm Processor, Sun UltraSPARC IV+, T1, T2, Plus и выше.- Сервер СУБД:Многоядерные 64-разрядный процессоры – Intel Xeon серии 5500/5600, AMD Six-Core

AMD Opterontm Processor, Sun UltraSPARC IV+, T1, T2, Plus и выше. Объем ОЗУ – 12 Гб. 31




Дисковая подсистема: RAID 10, аппаратный RAID контроллер.-

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

Поставка серверного оборудования осуществляется Заказчиком.

32




8 Порядок создания, приемки и контроля системы8.1 Общие требования Приемочные испытания Системы должны быть проведены в соответствии с

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

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

8.2 Этапы и результаты работ по созданию Системы:Наименование

стадииСостав работ Результат работы

Длительность, дней

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

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

20

1.2. Разработка и согласование Технического задания

Утвержденное Заказчиком Техническое задание

23

2.Технорабочий проект

2.1.Разработка технорабочего проекта(ПР, ПЗ)

Утвержденный Заказчиком технорабочий проект.

20

3. Реализация и ввод в действие

3.1. Настройка программного обеспечения (ПО)

Настроенное в соответствии с техническим заданием программное обеспечение, установленное в среде разработки

60

3.2. Разработка регламентов процесса

Регламенты процессовМетодология классификации ИТ услугСоглашения о предоставления ИТ услуг

3

3.3. Разработка эксплуатационной документации

Руководство пользователя»;Руководство администратораРуководство куратора по ИБруководство по настройке Системы;Руководство по настройке Отчетов;Руководство по настройке универсального импорта;Описание структуры Базы

4

33




Наименование стадии

Состав работ Результат работыДлительность,

днейДанных Системы;Технологическое решение информационно-вычислительной инфраструктурыВидеоинструкции;

3.3. Подготовка тестовой среды у Заказчика

Тестовая среда, созданная на серверах Заказчика, включая разработанное ПО

3

3.4. Подготовка и демонстрация работоспособности системы на контрольном примере в тестовой среде

Протокол замечаний по итогам демонстрации

2

3.5. Доработка системы по результатам демонстрации

Протокол устранения замечаний по итогам демонстрации

2

3.6. Нормализация данных

Тестовая среда с разработанным ПО и загруженными нормализованными данными

21

3.7. Разработка Программы и методики испытаний

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

2

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

Документ «Программа обучения»;Протокол обучения.

5

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

Протокол предварительных испытаний;

5

3.10. Доработка системы по результатам тестирования

Протокол устранения замечаний;Акт ввода Системы в опытную эксплуатацию

5

3.11. Подготовка продуктивной среды к опытной

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

2

34




Наименование стадии

Состав работ Результат работыДлительность,

днейэксплуатации данные3.12. Опытная эксплуатация

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

30

3.13.Передача лицензий на прикладное программное обеспечение

Лицензии переданыСчет выставлен Исполнителем и оплачен Заказчиком

0

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

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

11

8.3 Требования к испытаниям Системы и ее составных частей8.3.1 Виды испытаний

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

8.3.2 Место проведения испытаний

Испытания Системы проводятся на территории Заказчика.

8.4 Мероприятия по обучению персонала

- Обучение пользователей осуществляется на территории Заказчика в г. Москва;- На этапе опытной эксплуатации должно быть проведено очное обучение

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

- На этапе опытной эксплуатации должно быть проведено очное обучение пользователей и администраторов Системы;

35




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

8.5 Мероприятия по организационному обеспечению

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

8.6 Требования к технической поддержке

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

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

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

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

8.7 Требования к документированиюРазрабатываемая Система должна сопровождаться полным комплектом

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

Комплект эксплуатационной документации представляется Заказчику Исполнителем в одном экземпляре в печатном виде, а также в электронном виде на машинных носителях. Электронный вид документов должен соответствовать формату редакторов Microsoft Word 2007, Visio 2007.

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

Документация в электронном виде предоставляется на оптическом носителе информации (компакт-диск CD+R либо DVD+R). Имена всех файлов должны соответствовать обозначениям документов. На каждый компакт-диск должна быть нанесена

36




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

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

С Системой должен поставляться стандартный комплект документации:- Интерактивная, контекстно-зависимая онлайн-справка пользователя на русском

языке;- Интерактивное описание структуры БД Системы со ссылками на объекты

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

функционала, поставляемого ПО;- Видеоинструкции.

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

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

ПО;- Сценарии и результаты тестирования наборов изменений стандартного

функционала, поставляемого ПО, выполненных в рамках проекта;- Регламент обслуживания.

37




Приложение АЦелевая архитектура системы

38




Приложение БПредварительный перечень сводных отчетов

1. Отчет по выполнению SLA в разрезе отделов/групп/сотрудников;

2. Отчёт по выполнению SLA в разрезе типов запросов;

3. Отчёт по закрытым просроченным запросам;

4. Отчёт по открытым просроченным запросам;

5. Отчет по открытым запросам, находящимся в зоне риска нарушения SLA;

6. Отчёт по срокам выполнения заявок подрядчиками/сотрудниками;

7. Процент простоя ИТ сервисов от общего времени эксплуатации в разрезах соглашений по услугам;

8. Отчёт по степени удовлетворённости Пользователей выполнением запросов;

9. Отчет по выполнению SLA в разрезе ИТ-услуг.

39

Documents

ТТ SD - transneftenergo.transneft.rutransneftenergo.transneft.ru/.../2013432/tne_tt_servicede… · Web viewОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ