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

Зачем нужна категоризация?

Обсуждая тему эксплуатации услуг и сравнивая модели инцидентов и запросов на обслуживание, возник вопрос: а зачем нужна категоризация? И действительно, кому нужна эта информация? Как создать категоризатор и на что ориентироваться?

Общий подход к категоризации используемый процессами в поддержке предоставляемых услуг может быть не только полезен с точки зрения осмысления и обработки данных, но и в повышении производительности службы поддержки.

Категоризация является важным шагом многих процессов управления услугами.

Категоризация инцидентов.

Категоризация – это способ сортировки инцидентов по классам или категориям. В процессе управления инцидентами это дает нам возможность отслеживать аналогичные инциденты, связанные с продуктами и услугами, предоставляемыми бизнесу.

В управлении инцидентами, категоризация решает несколько основных задач:

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

По каким же принципам выстроить схему категоризации? Сколько уровней должно быть в ваших категориях?

Думаю, что правильный ответ будет таков: уровней должно быть не более, чем необходимо. 

Не существует единого подхода, который подходил бы для всех. Будет ли у вас многоуровневая схема категоризации, или вы ограничитесь парой (категория / подкатегория) зависит от вас и тех задач, которые вы собираетесь решить при помощи категоризатора.

Многоуровневая категоризация доступна в большинстве инструментов – обычно до трех или четырех уровней детализации. Например, инцидент может быть категоризирован, как показано на рисунке.

При определении категории верхнего уровня – локации, формируется подкатегория – услуга, на которую оказывает влияние инцидент. Затем, тип компонента услуги – система, далее, повышая детализацию – приложение. Низшим уровнем в категоризации обычно может являться конкретная конфигурационная единица (КЕ).

Если еще сотрудники службы поддержки способны категоризировать инцидент после его регистрации, то как быть пользователям, регистрирующим инцидент через портал самообслуживания? Ведь на портале не получится зарегистрировать обращение до тех пор, пока не будут заполнены все поля, в предложенной форме обязательные для заполнения. Да и не все пользователи смогут справиться с многоуровневой категоризацией, если она у вас именно такова.

Должна ли в таком случае быть категория “Другое”? Этот вопрос обычно бывает предметом дискуссий. Думаю, что это будет полезная категория для тех инцидентов, которые трудно соотнести с предложенной категоризацией.

Категоризация нужна не только в управлении инцидентами. Управление событиями также напрямую зависит от категоризации инцидентов.

Разработка инструментов и систем автоматизации, поддерживающих фильтрацию и корреляцию событий, помогут вам идентифицировать инциденты и выбрать необходимые действия, соответствующие решаемым задачам в рамках мониторинга и управления событиями.

Категоризация проблем

Управление проблемами практически невозможно достичь без хорошей категоризации. Например, вы анализируете отчеты, отражающие все инциденты, относящиеся к конкретной услуги или КЕ. Такие отчеты могут выявить закономерности между инцидентами при анализе возникающих тенденций.

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

Категоризация запросов на обслуживание

Категоризация является неотъемлемым шагом на этапе регистрации запросов на обслуживание. Она так же важна при определении типов, частоты запросов, тенденций обращений по услугам и определении, какие запросы чаще всего запрашиваются.

Вот примеры типичных категорий запросов:

  • По услуге – классификация запроса по услуге, частью которого он является. Например, запрос на создание новой учетной записи электронной почты пользователя может быть частью услуги электронной почты.
  • По видам деятельности – классификация запроса по виду деятельности, которую он выполняет. Примерами могут быть сброс пароля, установка на рабочем столе или замена картриджа принтера.
  • По типу – классификация запроса по типу запроса, например, информационный запрос или стандартное изменение.
  • По группе поддержки – классификация запроса, по группе поддержки, которая будет привлекаться для его выполнения.
  • По типу КЕ – классификация запроса по типам КЕ, на которые он влияет.

В качестве резюме

Разумная и достаточная категоризация – имеет ряд преимуществ:

– Распределение по категориям инцидентов помогает направлять их в нужную команду и тем самым экономить время на устранение неполадок и решение инфраструктурных и сервисных инцидентов.

– Использование категорий и подкатегорий также улучшает четкость и детализацию данных отчета.

– Понимание лежащих в основе данных позволяет организации принимать правильные решения при управлении услугами и определять возможности улучшения.

– Применение понятной категоризации на портале самообслуживания может улучшить наши услуги, повысить степень удовлетворенности клиентов, повысить нашу операционную эффективность и результативность. А это имеет смысл делать.

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

  • Сергей

    Ас если ещё и трудозатраты позволяет корректно разбрасывать – то совсем хорошо сравнивать как быстро решают те или иные “задачи” (категории) на разных площадках и здесь огромный задел для оптимизации.

  • Владимир Невский

    + категоризация по пользователям (заявителям/группам подразделений): иногда бывает так, что пользователь уже обращался с таким же или подобным обращением ранее. Бывают пользователи, которые генерят повышенное кол-во обращений.

  • Александр Пешков

    Добрый день, коллеги.
    Пытаюсь построить систему категоризации и вижу, что
    1. Действительно, для инцидентов и запросов категоризация должна выглядеть по разному, а вот проблемы нужно категоризировать так же как и инциденты.
    2. Наборы категорий, которые приведены в ITIL, говорят только о том, что нужно вырабатывать свою систему категоризации для каждого отдельного случая.

    Но чего мне не хватает, так это какого-то простого примера, скажем
    1. Система учета конфигураций
    1.1. Недоступна экранная форма
    1.1.1. Нет связи с сервером приложений
    1.1.2. Недоступны API сервера приложений
    1.1.3. Снижена производительность сервера приложений
    1.2. Не загружаются данные из БД в форму
    1.1.1. Нет связи с сервером БД
    1.1.2. Недоступны API сервера БД
    1.1.3. Снижена производительность сервера БД
    1.3. Не загружаются данные из формы в БД
    1.1.1. Нет связи с сервером БД
    1.1.2. Недоступны API сервера БД
    1.1.3. Снижена производительность сервера БД

    Здесь пример на три уровня, думаю, идея тут понятная.

    Коллеги, что думаете, так это или не так? Пожалуйста, покритикуйте меня и поправьте, где мимо?


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;