Портал №1 по управлению цифровыми
и информационными технологиями

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

Новозеландский эксперт Роб Ингланд давно ведет разработку методологии 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.

Реестр ESM- и ITSM-систем в России 2024
Из чего выбирать и на что мигрировать

Комментариев: 8

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

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

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

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

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

      …, Standard request, Change request, Access request”

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

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

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

        • “Отдельный сервисный объект — т.к. отдельный процесс”

          Попадаешь на проблемы с переклассификацией, нет?

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

        • Наверняка ты это уже видел (вещь бородата), но всё-таки, на всякий случай, раз уж ты копаешь модель данных ITSM см. Charles T. Betz “A data architecture for IT Service Management”. Мне там не всё нравится, но для полноты посмотреть полезно.

  • И кто переводил, кстати? Почему resp\input – реплики?

    • Я. Это слово показалось самым подходящим для “records you need to track when supporting services”. “Реплика” – более конкретно, чем “Ответы” или “вход”, не так ли? Как бы вы перевели, Александр?


Добавить комментарий для Дмитрий ИсайченкоОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;