Содержание¶

Цели создания¶

Целью создания Synergy ITSM является реализация автоматизации следующих ключевых процессов:

Управление обращениями (инцидентами и заявками на обслуживание)
Управление проблемами
Управление уровнем услуг (SLA)
Управление знаниями
Управление конфигурациями
Управление изменениями
Управление доступом

Основные процессы, которые покрывает Synergy ITSM¶

Эксплуатация услуг (Service Desk)

SO01	Добавление и актуализация каталога сервисов	Минимизация времени реакции на обращение
SO03	Регистрация обращения от пользователя оператором	Минимизация времени реакции на инцидент или запрос на обслуживание
SO04	Регистрация обращения от пользователя на портале (самообслуживание)	Минимизация времени реакции на инцидент
SO08	Назначение исполнителя обращения	Минимизация времени исполнения обращения
SO09	Изменение текущего статуса исполнения обращения	Минимизация времени исполнения обращения
SO10	Закрытие обращения со сбором обратной связи от пользователя	Качество исполнения удовлетворяет пользователя
SO11	Формирование интерактивного отчета об исполнении обращений в разрезе сервисов (SLA)	Быстрое выявления нарушений исполнений, отклонения от SLA и локализация проблем
SO12	Формирование интерактивного отчета об исполнении обращений в разрезе сервисов (SLA) и исполнителей	Быстрое выявления нарушений исполнений, отклонения от SLA и локализация проблем
SO13	Регистрация проблемы	Сокращение затрат на устранение проблемы
SO16	Устранение проблемы	Повышение доступности и качества услуг
SO22	Регистрация запроса на получение, отзыв или ограничение прав доступа оператором или на портале (самообслуживание)	Минимизация времени получения прав доступа
SO23	Верификация запроса и предоставление доступа	Минимизация ошибок предоставления неправомерного доступа

Преобразование и внедрение услуг

ST01	Сбор и хранение знаний	Минимизация потерь знаний
ST02	Предоставление знаний в контексте активностей пользователей	Сокращения времени на оказание услуги
ST06	Создание запроса на изменение (RFC)	Реализация потребностей заказчиков с оптимизацией затрат
ST08	Утверждение изменения	Минимизация сбоев, остановок и простоев услуг
ST12	Планирование и управление конфигурациями	Сокращение организационных издержек
ST13	Идентификация конфигураций	Сокращение организационных издержек
ST15	Учет статусов конфигурационных единиц	Минимизация сбоев, остановок и простоев услуг
ST16	Интерактивный отчет о состоянии активов и инфраструктуры	Быстрое принятие управленческих решений

Проектирование услуг

SD01	Управление каталогом услуг	Актуальная, достоверная и целостная картина о доступных услугах, их деталях и статусах
SD02	Управление уровнями сервисов	Улучшение взаимодействия заказчиков и поставщиков услуг

Условные обозначения¶

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

ОС - операционная система;
ИС - информационная система;
Система - ИС «Synergy ITSM»;
НУЦ РК - Национальный удостоверяющий центр Республики Казахстан;
ЭЦП - Электронная цифровая подпись;
СЭД - Система электронного документооборота;
СУБД - система управления базами данных;
Справочник - перечень заранее определенных значений параметров объектов системы;
Форма - тип файла в Платформе, предназначенный для сбора и отображения структурированных данных;
Реестр - способ представления данных по Форме в табличном виде;
Запись - документ на основе Формы в Реестре.
Работа - объект системы, представляющий собой сформулированное автором требование выполнить действие за конечное время и возложенное на конкретного исполнителя (ответственного).
Приоритет - атрибут работы, определяющий важность её исполнения. Названия и параметры имеют возможность настройки.
Нагрузка - атрибут работы, определяющий время, выделенное на выполнение данной работы. Нагрузка может быть выражена в количестве часов в день, в количестве часов всего, в количестве рабочих дней, в проценте от рабочего времени. Данный параметр работы участвует в формулах расчета общей нагрузки пользователя и его эффективности.
Прогресс - атрибут работы, характеризующий процент её выполнения (от 0% до 100%).
Статус - атрибут работы, определяющий статус работы в системе:
- зависящий от прогресса ее исполнения и типа:
  
  «в работе»;
  
  «ожидание» (<100%);
  
  «завершена»;
  
  «согласовано»/ «не согласовано», «ознакомлен», «утверждено»/ «не утверждено» (=100%);
- не зависящий от прогресса:
  
  «удалена».
Маршрут - многократно используемый набор Работ и правил переходов, связанных последовательно и/или параллельно, направленных на достижение заранее определённого результата.
Фильтры работ - способ группировки работ в зависимости от их свойств и по отношению пользователя к работе (на исполнении, на контроле).
Согласование - работа, требующая в качестве своего завершения выбора одного из пунктов: согласовано или не согласовано, позволяющая также при выборе ввести комментарий.
Утверждение - работа, требующая в качестве своего завершения выбора одного из пунктов: утверждено или не утверждено, позволяющая также при выборе ввести комментарий.
Ознакомление - работа, требующая в качестве своего завершения выбора пункта: ознакомился.
Документ - именованный контейнер в Хранилище, содержащий реквизиты и файлы, а также их версии. Реквизиты содержат: Карточку документа (в зависимости от типа), Ход исполнения, Изменения в документе, Листы подписей.
Дочерний документ - документ, созданный на основании данного. Связь «основание - дочерний» отображается в карточке документа.
Основание документ - документ, на основании которого был создан данный. Связь «основание - дочерний» отображается в карточке документа.

Обращение (инцидент или заявка на обслуживание) - Документ (в терминах системы), позволяющий хранить структурированные данные об инциденте ( - незапланированном прерывании или снижении качества ИТ-услуги, сбои конфигурационной единицы) или заявке на обслуживание по утвержденной форме.
Проблема (запись о проблеме)- Документ (в терминах системы), позволяющий хранить структурированные данные о проблеме (-причине одного или нескольких инцидентов) по утвержденной форме.
Конфигурационная единица - Документ (в терминах системы), позволяющий хранить структурированные данные по утвержденной форме о любом компоненте или другом сервисном активе, которым необходимо управлять для того, чтобы предоставлять ИТ-услугу.
Соглашение об уровне услуг (SLA) - Документ (в терминах системы), позволяющий хранить структурированные данные о соглашении (целевые показатели уровня услуги, зоны ответственности сторон) по утвержденной форме.
Лицензия - Документ (в терминах системы), позволяющий хранить структурированные данные о лицензии по утвержденной форме.
Наряд - Документ (в терминах системы), позволяющий хранить структурированные данные о наряде (формальном запросе на выполнение определенной деятельности) по утвержденной форме.
Оценка сервиса - Документ (в терминах системы), позволяющий хранить структурированные данные об оценке качества предоставляемого сервиса по устранению инцидента.
Запись базы знаний - Документ (в терминах системы), позволяющий хранить структурированные данные (- точек зрения,идей, опыта, информации) по утвержденной форме.
Услуга(сервис) - Документ (в терминах системы), позволяющий хранить структурированные данные об услуге (описании желаемых результатов, ценовой политике, пакетах обслуживания и пр.) по утвержденной форме.
Спецификация услуги - Документ (в терминах системы), позволяющий хранить структурированные данные об услуге (сервисные условия, связанные внутренние и внешние IT сервисы, процедурные оценки, финансы) по утвержденной форме.
Карточка контакта - Документ (в терминах системы), позволяющий хранить структурированные данные о контакте (сотруднике организации) по утвержденной форме.
Карточка организации - Документ (в терминах системы), позволяющий хранить структурированные данные об организации по утвержденной форме.
Запрос на изменение (RFC) - (RFC - Request for changes). Документ (в терминах системы), позволяющий хранить структурированные данные о запросе (-формальном предложении на выполнение изменений) по утвержденной форме.
Запись об изменении (CR) - (CR - Change record). Документ (в терминах системы), позволяющий хранить структурированные данные об изменении по утвержденной форме. Прим. Запись об изменении (CR) может являться дочерним документом для запроса на изменение (RFC)

Требования к разработке ИС «Synergy ITSM»¶

Общие требования к Системе¶

3.1.1	Система должна поддерживать работу на следующих серверных операционных системах: Linux, BSD, Solaris (рекомендуется использовать ОС Debian GNU/Linux 6.0 (amd64).
3.1.2	Система должна поддерживать работу на реляционных СУБД и на noSQL СУБД.
3.1.3	Система не требует обязательного приобретения дополнительных компонентов (лицензии на ОС, на СУБД и т.п.).
3.1.4	Система поддерживает шифрование подключений с помощью протокола SSL (HTTPS).
3.1.5	Система должна поддерживать работу с распределённым хранилищем данных.
3.1.6	Система должна обеспечивать возможность распределенной работы и удаленного доступа к ресурсам и объектам.
3.1.7	Система должна поддерживать работу в архитектуре Internet/Intrаnet.
3.1.8	Система должна предоставлять Web-интерфейс, который не требует установки клиентской части. Система должна поддерживать интернет-браузеры Google Chrome, Mozilla Firefox актуальных версий.
3.1.9	Система должна предоставлять возможность реализовывать пользовательские интерфейсы, используя HTML и/или JavaScript.
3.1.10	Система должна предоставлять комплект средств разработки (Software Development Kit - SDK), включая: REST API; способы авторизации: сессионная, по логину и паролю, по ключам; события, возникающие в различных точках исполняемого кода при выполнении определённых условий; очереди сообщений; поддержку плагинов; JavaScript интерпретаторы.
3.1.11	Система должна предоставлять возможность администрирования организационной структуры, функциональных ролей и учетных записей пользователей.
3.1.12	Система должна предоставлять возможность регулирования доступа к объектам системы в соответствии с правами доступа пользователя.
3.1.13	Система должна предоставлять возможность создания, редактирования форм в визуальном редакторе форм.
3.1.14	Система должна предоставлять инструмент управления бизнес-процессами, поддерживающий нотацию BPMN.
3.1.15	Система должна предоставлять дизайнер бизнес-процессов. Создание и редактирование бизнес-процессов должно выполняться в рабочем пространстве дизайнера бизнес-процессов.
3.1.16	Система должна поддерживать версионность документов.
3.1.17	Система должна поддерживать выгрузку данных в виде файла Excel с возможностью фильтрации по данным на форме, а также настройки отображаемых полей.
3.1.18	Система должна предоставлять возможность создания, редактирования, удаления шаблонов отчетов по данным реестров в рамках пользователя.

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

3.2.1	Система должна предоставлять доступ пользователям к модулю “Управление обращениями (инцидентами и запросами на обслуживание)”.
3.2.2	Система должна предоставлять доступ пользователям к модулю “Управление проблемами”.
3.2.3	Система должна предоставлять доступ пользователям к модулю “Управление уровнем услуг (SLA)”.
3.2.4	Система должна предоставлять доступ пользователям к модулю “Управление знаниями”.
3.2.5	Система должна предоставлять доступ пользователям к модулю “Управление конфигурациями”.
3.2.6	Система должна предоставлять доступ пользователям к модулю “Управление изменениями”.
3.2.7	Система должна предоставлять доступ пользователям к модулю “Управление доступом”.
3.2.8	Система должна предоставлять доступ пользователям к модулю “Управление активами”.

Требования к модулю “Управление обращениями (инцидентами и заявками на обслуживание)”¶

3.2.1	Система должна поддерживать исполнение функций следующих ролей в рамках процесса “Управление обращениями (инцидентами и заявками на обслуживание)”: Инициатор обращения (автор) Оператор Исполнитель Менеджер сервиса
3.2.2	Система должна позволять создавать/редактировать/удалять обращение в соответствии с правами доступа.
3.2.3	Система должна позволять в описании обращения указывать:подробную информацию об авторе, детальное описание, классификацию (по услугам и SLA, типу запроса, приоритету инициатора), ранжирование (по важности/срочности), связи с услугами, проблемами, конфигурационными единицами и другими обращениями.
3.2.4	Система должна позволять пользователю с ролью Оператор указывать Исполнителя по обращению и сроков его исполнения.
3.2.5	Система должна позволять осуществлять маршрут исполнения обращения согласно текущему его статусу.
3.2.6	В Системе должен быть предусмотрен механизм расчета временных метрик обращения, автоматически определяемый по услуге, SLA, а также с учетом рабочего календаря;
3.2.7	В Системе должен быть предусмотрен возврат обращений “на доработку” с автоматическим приостановлением расчета временных метрик.
3.2.8	Система должна предусматривать назначения обращения определенному ответственному или группе, а также назначению ответственного в рамках выбранной группы. Система должна предусматривать возможность переназначения с группы на группу, на ответственного и т.д.
3.2.9	По завершению работ по обращению, система должна позволять вносить описание решения в запись об обращении, а также осуществлять оценку сервиса.
3.2.10	Система должна предусматривать возможность завершения обращения без необходимости вносить оценку, принятия инициатором.
3.2.11	Система должна предоставлять возможность перехода по всем связанным объектам (обращение - проблема- услуга - конфигурационная единица), а также возвращению необходимых значений в связанные объекты, при изменении статуса основного.
3.2.12	В Системе должна быть возможность выполнять информирование инициатора обращения (e-mail-уведомления) на всех этапах жизненного цикла обращения
3.2.13	Система должна позволять пользователю с соответствующими правами доступа просматривать список всех обращений, а также осуществлять поиск и фильтрацию по ключевым полям формы.
3.2.14	Система должна поддерживать интеграцию с электронной почтой на предмет получения записей об обращениях.
3.2.15	В системе должен быть предусмотрен механизм интеграции с порталом для регистрации обращений, а также просмотра статусов текущих обращений, поданных через портал.
3.2.16	Система должна предоставлять оператору и исполнителю данные по ранее зарегистрированным обращениям автора.
3.2.17	Система должна предоставлять возможность отправления обращения внешнему поставщику с расчетом времени завершения по SLA.
3.2.18	Система должна предоставлять возможность отображения конфигурационных единиц, связанных с автором обращения.
3.2.19	Система должна предоставлять возможность сотрудникам IT-службы добавлять к обращению комментарии как внутренние, так и общие.
3.2.20	Система должна предоставлять возможность направления обращения на согласование, а также согласование либо отклонение обращения с вводом комментария.
3.2.21	Система должна хранить данные результатах согласования на форме обращения.
3.2.22	Система должна предоставлять возможность указывать проблему, решение которого требуется для дальнейшего разрешения обращения. А также система должна автоматически возвращать обращение в работу исполнителя после завершения проблемы.
3.2.23	Портал самообслуживания должен предоставлять возможность просмотра информации о пользователе, должности, руководителе.
3.2.24	Портал самообслуживания должен предоставлять возможность просмотра и редактирования почтового адреса пользователя.
3.2.25	Портал самообслуживания должен предоставлять возможность изменения авторизационных данных: логина и пароля - с проверкой соответствия системным настройкам.
3.2.26	Система должна поддерживать возможность интеграции с системой мониторинга Zabbix, основываясь на интеграции с почтой.
3.2.27	Система должна позволять автоматически направлять обращения в очередь исполнителям на вторую линию.
3.2.28	Система должна предоставлять возможность закрывать обращения, которые находятся на доработке у инициатора больше 16 рабочих часов.
3.2.29	Система должна предоставлять возможность массово направлять обращения на очередь, на оценку, на доработку и на ожидание закрытия массового инцидента .
3.2.30	Система должна предоставлять возможность создания проблемы из обращения.
3.2.31	Система должна предоставлять возможность регистрировать обращения из снешних систем при помощи API.
3.2.32	Система должна предоставлять возможность создания запросов на изменение из обращений.
3.2.33	Система должна предоставлять возможность ручной смены приоритета обращения с автоматическим пересчетом сроков исполнения.

Требования к модулю “Управление проблемами”¶

3.3.1	Система должна поддерживать исполнение функций следующих ролей в рамках процесса “Управление проблемами”: Инициатор записи о проблеме(автор) Менеджер проблем Исполнитель Менеджер сервиса
3.3.2	Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа запись о проблеме.
3.3.3	Система должна позволять в описании проблемы указывать подробную информацию об авторе, отличать проблему от известной ошибки, детальное описание самой проблемы, а также указывать связи с сервисами, обращениями и другими проблемами.
3.3.4	Система должна позволять пользователю с ролью Менеджер проблем указывать Исполнителя по проблеме.
3.3.5	Система должна позволять осуществлять маршрут исполнения проблемы согласно текущему её статусу.
3.3.6	Система должна позволять осуществлять координацию реализации работ маршрута проблемы. А именно: контроль прогресса исполнения, комментирование, прикрепление вложений в виде файлов.
3.3.7	Система должна позволять пользователю с соответствующими правами доступа просматривать список всех проблем, а также осуществлять поиск и фильтрацию по ключевым полям формы.
3.3.8	Система должна позволять уведомлять определенных пользователей об изменении статуса проблемы посредством электронной почты.
3.3.9	Система должна позволять указывать связанные с проблемой обращения, решение которых зависит от текущей проблемы.

Требования к модулю “Управление уровнем услуг (SLA)”¶

3.4.1	Система должна поддерживать исполнение функций следующих ролей в рамках процесса “Управление уровнем услуг(SLA)”: Менеджер услуг (SLA).
3.4.2	Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа карточку сервиса по установленной форме с заполнением основной и подробной и информации, а также указанием данных по соглашению об уровне услуг для выбранных групп или пользователей.
3.4.3	Система должна позволять пользователю с соответствующими правами доступа просматривать список всех: Услуг А также осуществлять поиск и фильтрацию по ключевым полям данных форм.
3.4.4	Система должна позволять определять время разрешения проблемы в разрезе приоритетов по определенной услуге.
3.4.5	Система должна предоставлять возможность настраивать для сервиса обязательность добавления файлов на портале самообслуживания.

Требования к модулю “Управление знаниями”¶

3.5.1	Система должна поддерживать исполнение функций следующих ролей в рамках процесса “Управление знаниями”: Инициатор записи Базы знаний - любой пользователь системы, имеющий право доступа на создание записи в соответствующем реестре.
3.5.2	Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа запись базы знаний с заполнением основной и подробной информации по установленной форме.
3.5.3	Система должна позволять связывать запись базы знаний с зарегистрированными обращениями и проблемами в соответствующих реестрах.
3.5.4	Система должна позволять пользователю с соответствующими правами доступа просматривать список всех записей Базы знаний, а также осуществлять поиск и фильтрацию по ключевым полям данных форм.
3.5.5	Система должна позволять пользователю создавать запись в базе знаний на основе обращения или проблемы.
3.5.6	Система должна позволять автоматизировать процесс пересмотра и актуализации статей в базе знаний

Требования к модулю “Управление конфигурациями”¶

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

Требования к модулю “Управление изменениями”¶

3.7.1	Система должна поддерживать исполнение функций следующих ролей в рамках процесса “Управление изменениями”: Инициатор RFC - Любой сотрудник компании, являющийся автором и отправителем Заявки на изменение RFC Совет по изменениям (CAB) - группа пользователей, согласующими RFC или CR на разных этапах процесса. Исполнитель - Сотрудник, отвечающий за исполнение конкретной работы по плану реализации или плану отката CR
3.7.2	Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа запрос на изменение (RFC) с заполнением следующей основной информации о запросе. А также дополнительной информации, позволяющей классифицировать данный запрос по важности/срочности, связывать запрос на изменение (RFC) с касающимися его услугами.
3.7.3	Система должна позволять осуществлять процесс согласования запроса на изменения (RFC) с советом по изменения (CAB), а также с другими заинтересованными лицами.
3.7.4	Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа на основании запроса на изменение (RFC) запись об изменении CR: определять план реализации и план отката.
3.7.5	Система должна позволять осуществлять маршрут запроса на изменение согласно его текущему статусу.
3.7.6	Система должна позволять осуществлять маршрут изменения согласно его текущему статусу.
3.7.7	Система должна позволять пользователю с соответствующими правами доступа просматривать список всех запросов на изменения (RFC) и записей об изменении (CR), а также осуществлять поиск и фильтрацию по ключевым полям данных форм.
3.7.8	Система должна позволять уведомлять автора и группу пользователей, поддерживающих IT услугу, о смене статуса запроса на изменение посредством электронной почты.

Требования к модулю “Управление доступом”¶

3.8.1	Система должна поддерживать исполнение функций следующих ролей в рамках процесса “Управление доступом”: Инициатор - Любой сотрудник компании, являющийся автором и отправителем Заявки на права доступа Руководитель - Руководитель инициатора, согласующий заявку на права доступа Менеджер по правам доступа - Сотрудник, назначающий или отзывающий права доступа на ту или иную систему
3.8.2	Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа Заявку на права доступа по установленной форме.
3.8.3	Система должна позволять пользователю с соответствующими правами доступа просматривать список всех заявок на права доступа.
3.8.4	Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа роли к имеющимся системам по установленной форме
3.8.5	Система должна позволять пользователю с соответствующими правами доступа просматривать список всех ролей.
3.8.6	Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа Реестр прав доступа по установленной форме
3.8.7	Система должна позволять пользователю с соответствующими правами доступа просматривать список всех записей в реестре прав доступа.
3.8.8	В системе должен быть предусмотрен механизм интеграции с порталом для регистрации заявок на права доступа.
3.8.9	Система должна позволять руководителю согласовать или отклонять заявку на права доступа на портале самообслуживания.

Требования к модулю “Управление активами”¶

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