Классификация сервисных объектов от ИТ-скептика

Новозеландский эксперт Роб Ингланд давно ведет разработку методологии Basic Service Management. Кроме подхода к постоянному совершенствованию Tipu в BSM включено множество прикладных инструментов. Позавчера в этот свод знаний была добавлена классификация всех сервисных объектов, которые необходимо учитывать любому поставщику услуг.

Она такова:

  • Interactions
  • Responses

    • Action

      • Provisioning
      • Booking
      • Ordering
      • Change
      • Work
    • Support

      • Incident
      • Fault
      • Help
      • Advice
    • Input

      • Proposal
      • Suggestion
      • Feedback
      • Complaint
  • Problems
  • Interruptions
  • Взаимодействия (по телефону, электронной почте и т.д.)
  • Реплики сторон

    • Деятельность поставщика услуг

      • Предоставление (пользователям доступа к услугам)
      • Бронирование (ресурсов или времени)
      • Заказ (оборудования, билетов)
      • Изменение
      • Наряд на работу (малозначимое стандартное изменение)
    • Действия по поддержке (исправление, ремонт)

      • Инцидент (в услуге)
      • Сбой (в компонентах)
      • Помощь (по устранению последствий ошибок)
      • Консультации ("какую кнопку мне нажать?")
    • Реплики от пользователей

      • Запрос ( на проект)
      • Предложение (идеи, требования, запросы)
      • Отзыв (замечания, благодарности)
      • Жалоба (на то, как работает поставщик услуг)
  • Проблемы (корневые причины сбоев и инцидентов)
  • Прерывания (фактические промежутки простоя услуг)

Роб пишет:

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

Более подробно о классификации можно прочитать на сайте BSM.

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

Узнайте больше!

Комментарии и мнения

  1. Александр Жилинский

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

    У меня самого возникла необходимость полгода назад полностью пересмотреть классификацию раздела Support в рамках покорения вселенной и написания ITILvX (и избавиться наконец от Запрос на обслуживание \ Стандартное изменение). Получилось нечто похожее: Inc (Fault все-таки внутре), Standard request, Change request, Access request. Все это упирается в низлежащие процессы, но выглядит пока что хорошо.

    У Скептика Help\Advice зря, а так все ок — понятно и непротиворечиво.

    1. Дмитрий Исайченко

      «Получилось нечто похожее: Inc (Fault все-таки внутре)...

      С этим согласен (что внутри), см. www.realitsm.ru/2012/06/n...st/#comment-9961, второй абзац.

      ..., Standard request, Change request, Access request»

      Зависит от системы автоматизации — зачем используется классификация. В частности, это касается выделения стандартных запросов и запросов на изменение — попахивает Remedy/HPSM 🙂 А вот Access request успешно может трактоваться или как standard request, или как change request (в зависимости от конкретной организации). Чтобы выделить из общего потока, достаточно ввести классифицирующий признак (например, стандартный запрос или изменение категории «Запрос на доступ»). А зачем отдельный сервисный объект?

      1. Александр Жилинский

        Никак не зависит от системы автоматизации — т.к. пишется именно в рамках условной ITILvX (basic itsm, c++ itsm, etc), без привязки к системе автоматизации вообще (но с возможной будущей автоматизацией на любой хорошо кастомизируемой системе 😉

        Отдельный сервисный объект — т.к. отдельный процесс. С матрицей доступа и прочими блекджеками- чего нет в процессах, обрабатывающих запросы вида Str req, Chg req.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
17
Учебный курс:
Основы DevOps 
ДЕК
20
ДЕК
20