Подходы к формированию каталога сервисов
Добавлено: 23 июл 2017, 15:30
Рассмотрим варианты:
1. Поддержка ПО #1
Состав услуги:
В данном случае можно детально расписать по типам обращений:
- сопровождение (всегда запрос на обслуживание)
- устранение неполадок (всегда инцидент)
- обновление / доработка (всегда запрос на изменение)
ИЛИ
Оставить единственный пункт "сопровождение", а категоризировать (агентом) по типу обращения
2. Поддержка ПО # 2
То же самое
И т.д.
Или вариант, когда в составе услуги к конкретному ресурсу не привязываемся, а пишем:
1. Поддержка прикладного ПО
По составу услуги те же варианты, что и выше.
Связь с конкретным ПО устанавливаем связью с конфигурационной единицей, которой и будет являться данное прикладное ПО.
Итого две дилеммы:
1. Стоит ли расписывать состав услуги относительно фиксированных типов обращений или в универсальной подуслуге определять тип обращения.
2. Детализировать услуги по конкретным ресурсам или исходить из укрупнённого определения услуги с привязкой к конкретным КЕ.
По факту для себя так и не определился однозначно какой подход лучше. It depends.
Лет 10 назад, когда впервые пришлось этим заняться, получился смешанный вариант. В итоге для услуг, оказываемых внутри организации был вариант с привязкой к КЕ и детализацией состава услуги, а для внешних клиентов услуга касалась конкретной системы с ещё более детально расписанным составом услуги.
Использовался Итилиум и там оба варианты были вполне органичны. И в плане поддержки каталога услуг, и в связях услуг с каталогом КЕ, и в интерфейсе сервисдеска, и в отчётности.
А как в OTRS?
Несомненно, нужно отталкиваться от реализованных процессов, но, когда они только выстраиваются, то не хотелось бы наткнуться на ограничения системы автоматизации.
1. Поддержка ПО #1
Состав услуги:
В данном случае можно детально расписать по типам обращений:
- сопровождение (всегда запрос на обслуживание)
- устранение неполадок (всегда инцидент)
- обновление / доработка (всегда запрос на изменение)
ИЛИ
Оставить единственный пункт "сопровождение", а категоризировать (агентом) по типу обращения
2. Поддержка ПО # 2
То же самое
И т.д.
Или вариант, когда в составе услуги к конкретному ресурсу не привязываемся, а пишем:
1. Поддержка прикладного ПО
По составу услуги те же варианты, что и выше.
Связь с конкретным ПО устанавливаем связью с конфигурационной единицей, которой и будет являться данное прикладное ПО.
Итого две дилеммы:
1. Стоит ли расписывать состав услуги относительно фиксированных типов обращений или в универсальной подуслуге определять тип обращения.
2. Детализировать услуги по конкретным ресурсам или исходить из укрупнённого определения услуги с привязкой к конкретным КЕ.
По факту для себя так и не определился однозначно какой подход лучше. It depends.
Лет 10 назад, когда впервые пришлось этим заняться, получился смешанный вариант. В итоге для услуг, оказываемых внутри организации был вариант с привязкой к КЕ и детализацией состава услуги, а для внешних клиентов услуга касалась конкретной системы с ещё более детально расписанным составом услуги.
Использовался Итилиум и там оба варианты были вполне органичны. И в плане поддержки каталога услуг, и в связях услуг с каталогом КЕ, и в интерфейсе сервисдеска, и в отчётности.
А как в OTRS?
Несомненно, нужно отталкиваться от реализованных процессов, но, когда они только выстраиваются, то не хотелось бы наткнуться на ограничения системы автоматизации.