Общее требования Заказчика.
Web-интерфейс для внутренних пользователей (для сотрудников/специалистов ИТ)
Костомизация интерфейсов инцидентов, изменений и др.
Возможность добавления дополнительных полей с различными типами данных/переменных
Возможность построения последовательности и автоматизации действий сотрудников HD в зависимости от сервиса и статусов элементов реализуемых процессов
Web-интерфейс для внешних пользователей (сотрудники компании или выделенные сотрудники от бизнес подразделений)
Возможность видения нескольких организаций в одной системе с настройкой реализуемых процессов под эти организации.
Гибкость бизнес-логики системы (возможность изменения бизнес-логики «из коробки» под бизнес-процессы Заказчика без дополнительных работ по доработке системы со стороны Исполнителя с привлечением программистов)
Масштабируемость до 16000 конечных пользователей и 250-300 ИТ пользователей, 12 000 устройств.
Отсутствие элементов программирования (C#,C++ и т.п.) при настройке системы после внедрения и ввода в промышленную эксплуатацию
Высокая работоспособность при одновременной работе минимумом 150 сессий для специалистов ИТ и 100 сессий для пользовательского портала
Расчет KPI по объёмам работ, простоям систем и т.д. например: суммирование по граничному критерию и получение отношения к общей сумме.
CMDB
Разделенные, скрытые от других ветки по разным направлениям (рабочие места, сервера, сетевое оборудование и т.д.)
Встроенные средства инвентаризации
Учет специфических активов (таких как Aerodoc)
Привязка КЕ (конфигурационной единицы) к пользователю/подразделению
Подведение нескольких КЕ под общий знаменатель (наличие связей). Пример: КЕ-сис. блок + КЕ-монитор + КЕ-принтер = КЕ-рабочее место
Средства интеграции с
Altiris
SAP
Active Directory
Orion
Кадровая система
Sabre
Настраиваемые коннекторы, дающие возможность обмена данными:
Базы данных MSSQL, Oracle, Firebird и др.
Webservices в обе стороны
Email в обе стороны (ориентированность на MS Exchange)
Единовременные/плановые выгрузкизагрузки данных в различных форматах, прежде всего CSV, HML
Интерфейсы с AD, позволяющие получать информацию по пользователю в заявку, работу, наряд
Процессы
Управление инцидентами
Возможность выстраивания параллельных/последовательных/смешанных процессов
Возможность выстраивания различных процессов для разных типов инцидентов
Графический редактор процессов
Возможность расчета времени/стоимости работ для подрядчиков и включения в отчётность
Расчет крайних сроков выполнения работ исходя из графиков рабочего времени подразделений/рабочих групп
Управление изменениями
Возможность выстраивания параллельных/последовательных/смешанных процессов
Возможность выстраивания различных процессов для разных типов изменений
Графический редактор процессов
Управление работ (в части регламентных/плановых работ)
Регистрация событий автоматически
- списком из файла по расписанию
- списком из системы по расписанию
- по событию из внешней системы
Каталог услуг
Различные критерии иерархического построения дерева услуг с ограничениями по доступу. Разделение сервисов на пользовательские и инфраструктурные. Связь сервисов и базы знаний.
Построение связей с CMDB
Система контроля взведенных событий на сервисы и работы. Например, сделать рассылку по недоступности сервисов в связи с проведением работ по внедрению.
Построение связей с Рабочими группами/исполнителями
Отчетность
Возможность поиска по всем полям, всех сущностей с применением логики и количественных значений
Формирование верхнеуровневой отчетности (для руководства ИТ и бизнес-подразделений)
Отчет от поиска до готовности делается без применения сторонних систем (Crystal Reports и др.)
Общие требования к функциональным возможностям подсистем
Все подсистемы должны обладать следующими функциональными возможностями:
Должна быть обеспечена возможность создания оповещений (т.н. Broadcasts) на группу/на всех сотрудников поддержки/на всех пользователей системы/др. Оповещения должны отображаться на главных консолях всех доступных подсистем;
Для каждой подсистемы должна быть возможность определения состава атрибутов и их обязательности;
Подсистемами должна поддерживаться многоуровневая категоризация;
Для объектов подсистем должен быть доступен функционал по созданию, редактированию и использованию шаблонов;
Должен быть доступен функционал встроенного полнотекстового поиска, не требующего установки стороннего ПО;
Должен быть доступен функционал по связыванию объектов и автоматическому заполнению атрибутов связанных записей на основе взаимосвязей между объектами;
В Системе должен быть встроенный графический редактор процессов;
Должна быть обеспечена возможность расчета времени/стоимости работ для подрядчиков;
Должна быть обеспечена возможность расчета крайних сроков выполнения работ, исходя из графиков рабочего времени подразделений/рабочих групп;
Должна быть обеспечена гибкость бизнес-логики подсистем (возможность изменения бизнес-логики «из коробки» под бизнес-процессы Заказчика без дополнительных работ по доработке системы со стороны Исполнителя);
Должна быть обеспечена возможность автоматической регистрации запросов и получения данных из других систем/файлов/баз данных (по расписанию или в результате интеграции систем);
Должна быть обеспечена возможность формирования и назначения заданий на работу, уведомления исполнителей и контроль выполнения заданий для процессов управления инцидентами, изменениями, запросами.
Строгое распределение возможностей исполнителей по ролям. Крайний срок заявок/нарядов/изменений не должен меняться исполнителем.
Должна быть реализована система автоматических действий системы по событиям (рассылки почтовых сообщений, формирования работ на ТО и регламенты и т.д.)
Подсистема управления инцидентами
В рамках процесса управления инцидентами должна быть автоматизирована деятельность по регистрации и обработке инцидентов. Подсистема управления инцидентами должна обладать следующими функциональными возможностями:
Регистрация заявок, поступающих из различных источников (телефон, почта, web-сервисы, др.);
Классификация и приоритезация заявок (через указание влияния и срочности);
Связывание заявок с другими КЕ (персоналом, единицами оборудования, объектами других приложений, др.);
Возможность связывания нескольких инцидентов для реализации их совместной обработки (например, с целью обработки и закрытия массовых инцидентов);
Автоматизация назначения заявок, согласно зонам ответственности рабочих групп;
Назначение и переназначение заявок на конкретных исполнителей или рабочие группы;
Создание в рамках решения заявок заданий на работы (групп заданий), назначение их на исполнителей и рабочие группы;
Наличие консоли инцидентов с возможностью фильтрации, сортировки и предварительного просмотра заявок пользователей;
Настройка уведомлений пользователя и ответственных сотрудников о событиях, связанных с инцидентом или заданием на работу по инциденту;
Ведение рабочего журнала (журнала активностей) по заявке с возможностью разграничения видимости сообщений (группы поддержки/все пользователи) и прикрепления к ним файлов произвольных форматов;
Возможность оценки заявки Инициатором перед ее закрытием;
Возврат заявки на доработку Инициатором, в случае его несогласия с качеством решения его инцидента;
Закрытие заявки в автоматическом режиме через определенный промежуток времени;
Поиск и формирование выборок среди доступных для просмотра заявок;
Хранение истории изменений по каждой заявке;
Возможность выстраивания параллельных/последовательных/смешанных процессов;
Возможность выстраивания различных процессов для разных типов инцидентов.
Где про ведение сервисов и привязка к сервисам?
Подсистема управления изменениями
Процесс управления изменениями отвечает за регистрацию и правильное проведение изменений на всех этапах жизненного цикла, от планирования, до согласования, исполнения и закрытия запроса на изменение. Подсистема управления изменениями должна обладать следующими функциональными возможностями:
Регистрация запросов на изменения;
Классификация и приоритезация запросов на изменения;
Связывание запросов на изменения с другими КЕ (персоналом, единицами оборудования, объектами других приложений, др.);
Согласование запросов на изменения на различных этапах обработки изменения ответственными лицами, настройка маршрутов согласования;
Автоматизация назначения запросов на изменения, согласно зонам ответственности рабочих групп;
Назначение и переназначение запросов на изменения на конкретных исполнителей или рабочие группы;
Создание в рамках решения запросов на изменения заданий на работы (групп заданий), назначение их на исполнителей и рабочие группы;
Наличие консоли изменений с возможностью фильтрации, сортировки и предварительного просмотра запросов;
Настройка уведомлений ответственных сотрудников о событиях, связанных с изменением или заданием на работу по изменению;
Ведение рабочего журнала (журнала активностей) по запросу на изменение с возможностью разграничения видимости сообщений (группы поддержки/все пользователи) и прикрепления к ним файлов произвольных форматов;
Наличие календаря изменений с возможностью просматривать изменения в различных представлениях (календарь/список событий/отрезок времени);
Поиск и формирование выборок среди доступных для просмотра запросов уполномоченными лицами;
Хранение истории по каждому запросу на изменения;
Возможность выстраивания параллельных/последовательных/смешанных процессов;
Возможность выстраивания различных процессов для разных типов изменений.
Подсистема управления запросами
Процесс управления запросами отвечает за регистрацию и обработку запросов пользователей. Подсистема управления запросами должна обладать следующими функциональными возможностями:
Наличие интуитивно-понятного web-интерфейса;
Наличие панели для вывода информации (т.н. Marketing Slides);
Разграничение доступа к шаблонам запросов на основе организационной и территориальной принадлежности пользователя;
Возможность создания запросов для другого лица;
Согласование шаблона запроса перед его публикацией на портале;
Согласование запроса, созданного пользователем, ответственными лицами, настройка маршрутов согласования;
Построение логики обработки запроса и порядка его выполнения (задание последовательности и типов создаваемых объектов, требуемых для выполнения запроса) должно осуществляться с помощью средств администрирования системы и иметь удобный и понятный графический интерфейс;
Разделение услуг на пользовательские и инфраструктурные;
Построение связей с CMDB;
Автоматическое назначение запросов на ответственные рабочие группы в зависимости от категории запроса, статуса пользователя, его территориальной и организационной принадлежности;
Возможность использования полнотекстового поиска на портале, как по запросам, так и по статьям базы знаний;
Ведение рабочего журнала (журнала активностей) по запросу с возможностью отправки сообщения в конечное приложение (в заявку, созданную на основании запроса пользователя и находящуюся в данный момент в активном статусе) и прикрепления к ним файлов произвольных форматов;
Настройка уведомлений пользователя и ответственных сотрудников о событиях, связанных с запросом;
Возможность переоткрытия запроса пользователем;
Настройка анкет для оценки удовлетворенности пользователя качеством оказанных ему услуг. При создании шаблона запроса у администратора должна быть возможность выбора наиболее подходящего шаблона анкеты;
Предоставление возможности пользователю оставить отзыв о портале или внести предложение;
Возможность оценки пользователем качества выполнения запроса (заполнение числовых или текстовых полей, возможность выбора оценки из предопределенного списка);
Гибкость настройки шаблонов уведомлений: возможность включения любых полей запроса в уведомление, возможность оформления уведомления в корпоративном стиле компании.
Схема (алгоритм) обработки запроса, а так же автоматические действия Системы в течении обработки запроса происходят исходя из сервиса (услуги), связанной с этим запросом
Отдельные алгоритмы прохождения запросов для VIP-пользователей и сервисов с ремаркой «Критичный»
Подсистема управления знаниями
Процесс управления знаниями отвечает за создание, пополнение и поддержание в актуальном состоянии полезных в работе статей. Кроме того, процесс обеспечивает постоянный и удобный доступ пользователей к базе знаний. Подсистема управления знаниями должна обладать следующими функциональными возможностями:
Регистрация, категоризация статей и назначение их на группу поддержки;
Возможность добавления таблиц, графиков и изображений в текст статьи;
Полнотекстовый поиск по статьям базы знаний;
Ведение журнала запросов на обновление статьи;
Возможность изменения статьи после ее публикации;
Согласование статей перед публикацией;
Определение популярности статьи (по количеству просмотров);
Возможность оценки статьи пользователем.
Удаление устаревших и мало используемых статаей
Подсистема управления конфигурациями
Процесс управления конфигурациями отвечает за учет конфигурационных единиц и связей между ними. В рамках данного процесса также производится контроль жизненного цикла конфигурационных единиц. Подсистема управления конфигурациями должна обладать следующими функциональными возможностями:
Ведение конфигурационной базы данных (CMDB);
Привязка КЕ (конфигурационной единицы) к пользователю/подразделению;
Создание конфигурационных единиц, состоящих из других конфигурационных единиц (Например, КЕраб.место = КЕсист.блок + КЕмонитор + КЕпринтер);
Предоставление смежным процессам и заинтересованным сотрудникам актуальной информации об элементах ИТ-инфраструктуры;
Сбор и поддержание в актуальном состоянии информации о наличии и статусе элементов ИТ-инфраструктуры на основании данных, получаемых от систем мониторинга, а также от других процессов;
Идентификация источника данных;
Нормализация данных;
Ведение базы лицензий и контрактов;
Привязка лицензий и контрактов к элементам конфигурационной базы;
Создание правил на формирование оповещений о необходимости продления поддержки или закупки дополнительных лицензий.
Поддержание процессов доукомплектования и разукомплектования КЕ в соответствии с корпоративным требованиями.
Подсистема управления уровнем услуг
Процесс управления уровнем услуг отвечает за контроль соблюдения условий SLA. Подсистема управления уровнем услуг должна обладать следующими функциональными возможностями:
Механизм контроля нормативов выполнения заявок с учетом установленного рабочего времени ответственных сотрудников подразделений;
Возможность гибкого определения и отслеживания нормативных сроков выполнения заявок в зависимости от выбранных значений классификаторов;
Механизм эскалации заявок (с автоматическим оповещением об эскалации всех заинтересованных лиц), запускаемый при нарушении установленных нормативов разрешения в целом, а также при нарушении нормативов нахождения заявки на промежуточных стадиях жизненного цикла;
Визуальное отображение соответствия заявки SLA в конечном приложении (например, светофор, значки, часы с обратным отсчетом).
Подсистема инвентаризации оборудования и программного обеспечения
Подсистема должна обеспечивать сбор информации об оборудовании и программном обеспечении компании и обладать следующими функциональными возможностями:
Инвентаризация аппаратного и программного обеспечения;
Мониторинг лицензий на программное обеспечение;
Автоматическая подстановка сведений о производителе, пакете, версии ПО или оборудования из базы данных;
Совместимость с BMC Remedy Atrium CMDB;
Настройка параметров сбора информации;
Настройка правил обновления существующих конфигурационных единиц.
Подсистема управления ПО
Подсистема должна обеспечивать возможность распространения корпоративного ПО, обновлений и патчей, а также обладать следующими функциональными возможностями:
Установка ПО, обновлений и патчей по расписанию или автоматически, при подключении к корпоративной сети;
Настройка правил распространения корпоративного ПО, обновлений, патчей;
Контроль установленного ПО на компьютере пользователя.
Доступ к удалённым (через интернет) ПК пользователей
Подсистема контроля соответствия политикам использования ПО
Подсистема контроля соответствия политикам использования ПО на подконтрольных устройствах предназначена для определения политик компании, сбора и анализа информации систем мониторинга на предмет соответствия данным политикам. Подсистема должна обладать следующими функциональными возможностями:
Настройка политик использования ПО;
Проведение анализа инфраструктуры на предмет соответствия заданным политикам;
Вывод информации о соответствии политикам на консоль в виде таблиц, графиков и диаграмм в режиме реального времени;
Формирование отчетов соответствия политикам использования ПО;
Совместимость с BMC Remedy Atrium CMDB.
Подсистема удаленного управления устройствами
Подсистема должна обеспечивать возможность удаленного подключения к устройствам и выполнения стандартных задач администрирования, в том числе: установку/удаление/обновление ПО, исправление сбоев, ошибок системы, произведение дополнительных настроек.
Подсистема отчетности
Подсистема должна обеспечивать возможность создания отчетов на основании данных, собранных в результате работы описанных выше подсистем, и обладать следующими функциональными возможностями:
Формирование верхнеуровневой отчетности (для руководства ИТ и бизнес-подразделений);
Формирование отчетности без использования сторонних систем (Crystal Reports и др.);
Построение интерактивных графиков и диаграмм;
Экспорт содержания отчетов во внешние системы и различные форматы файлов (doc, pdf, xls, csv, и др.);
Предоставление доступа к отчетности пользователям в соответствии с ролевой моделью доступа;
Построение отчетов со многими уровнями вложенности и возможностью детализации до отдельных событий или объектов системы;
Формирование и рассылка отчетов по расписанию, создание правил рассылки (еженедельно, ежемесячно и др.);
Предоставление пользователям интерфейса для самостоятельного создания отчетов из конструктора.
Дополнительные требования
Требования к механизму согласования
Механизм согласования должен обеспечивать следующие функциональные возможности:
Согласование через почту;
Назначение альтернативного согласующего на определенный период;
Формирование различных списков согласующих в зависимости от значений атрибутов объектов;
Добавление дополнительных согласующих в предопределенный список;
Наличие консоли согласования с перечнем всех заявок, которые необходимо согласовать, с возможностью их фильтрации, группового согласования и просмотра подробной информации;
Запрос дополнительной информации по заявке.
Требования к механизму оповещений
Механизм оповещений должен обеспечивать следующие функциональные возможности:
Настройка параметров оповещений в профиле сотрудника;
Создание, редактирование и отправка оповещений из системы вручную;
Настройка условий автоматической отправки оповещений.
Требования к представлениям
Пользователь системы должен иметь возможность адаптировать вид консоли под свои нужды. Система должна обеспечивать следующие варианты настройки:
Настройка вида домашней страницы (возможность вывода таблиц/графиков/диаграмм по доступным пользователю подсистемам);
Настройка консолей подсистем, в том числе установка фильтров по умолчанию, изменение состава и порядка выводимых в консоли столбцов;
Настройка состава и порядка отображения столбцов в результатах поиска.
Требования к интеграции с системами Заказчика
Система должна обеспечивать следующие возможности обмена данными:
Базы данных (MSSQL, Oracle, Firebird и др.);
Web-сервисы (как поставщик и потребитель);
Почта (получение и отправка по стандартным протоколам);
Единовременный/плановый импорт/экспорт данных в различных форматах.
В рамках Проекта необходимо обеспечить интеграцию Системы со следующими системами Заказчика:
Служба каталогов – Active Directory;
Система управления ИТ ресурсами – Altiris;
Система управления внутренними процессами – SAP;
Система Orion.
Кадровая система Аккорд
Более подробно информация по интеграции систем представлена в таблице (Таблица ).
Таблица - Требования к интеграции систем
№
|
Система
|
Данные
|
Тип обмена
|
Технология
|
|
Active Directory
|
|
Односторонний (AD -> Система)
или
Двусторонний
или
Односторонний (AD <- Система)
|
Пример:
LDAP запрос к DC (RPC)
или
Web сервис
или
Через DB
|
|
Altiris
|
Данные по парку ПК в домене MSK
|
Односторонний
|
|
|
SAP
|
Организационная структура и контакты пользователей
|
Односторонний
|
|
|
Orion
|
Данные по инцидентам в коллекции Orion
|
Односторонний
|
|
|
КИС Аккорд
|
Организационная структура и контакты пользователей
|
Односторонний
|
Из БД Oracle
| |
