Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

Принципы оптимальной классификации инцидентов

Принципы оптимальной классификации инцидентов

Стефан Манн (Stephen Mann), аналитик Forrester Research, в своем блоге рассуждает об оптимальной классификации инцидентов. Часто встречаются высказывания, что сложно найти передовые методы классификации инцидентов. Первое, что приходит на ум посмотреть в поисковиках. По англоязычным запросу «оптимальные методы классификации инцидентов» и «оптимальные методы категоризации инцидентов» Google выдает 21 миллион ссылок (хотя, нужно уточнить, не все из них относились к управлению ИТ услугами). Однако практический результат оказывается нулевым, т.к. ни в одной ссылке нет в свободном доступе  готовых советов или решений.

Удивительно, еще и то, что несмотря на разнообразие лучших (или хороших) практик управления ИТ услугами (в особенности практик использующих библиотеку ITIL),  на мой взгляд, классификация инцидентов — это та область, где успех,  достигаемый аккуратным документированием, действительно позволяет предотвращать сбои и неполадки.  

Так как многие организации начинают использовать лучшие практики ITSM или ITIL с управления инцидентами и организации службы Service Desk, составление надежной иерархической классификации инцидентов — это одна из первых задач с которой они сталкиваются.  Ровно та же самая задача возникает и тогда, когда организация выбирает один из имеющихся на рынке  ITSM-продуктов. Кроме того проблема классификации, затрагивает и те организации, которые начинают осознавать, что действующая у них иерархия инцидентов становится неэффективной. Итак, классификация инцидентов очень важна так, где же найти соответствующие лучшие практики?

Почему так мало стоящей информации? Некоторые говорят, что тут не может быть универсального для всех стандарта. Действительно, всех под одну гребенку тут выровнять не получится. Некоторые также могут возразить, что составление иерархической классификации инцидентов — способ дополнительного заработка для разработчиков инструментов и консультантов по ITSM. Однако в ITSM-консалтинге и так достаточно других более продуктивных возможностей для увеличения дохода от профессиональных услуг, зачем же тратить время на очередное «изобретение  велосипеда»?

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

Вот приблизительный список принципов:

  1. Иерархия должна составляться с учетом требований бизнеса, а не ИТ.
  2. Необходимо упростить перехват инцидентов, однако это не должно вредить последующей аналитической обработке базы данных, так как данные об инцидентах должны использоваться в анализе тенденций для процессов управления проблемами и непрерывного улучшения услуг, а также при подготовке разного рода отчетности и расчете интегральных показателей.
  3. Классификация должна упрощать рабочий процесс и сокращать жизненный цикл инцидентов.
  4. Старайтесь классифицировать факты, а не «симптомы».
  5. Слишком большое количество уровней классификации снижает скорость перехвата и способствует путанице в категориях,  особенно там, где начинают злоупотреблять функцией «другое». В большинстве случаев не требуется более трех уровней классификации. Чтобы полностью исключить случайности можно ввести в иерархию четвертый уровень.
  6. Подумайте, стоит ли придумывать более 10 подуровней для одной категории. Я уверен, что 10 подуровней более чем достаточно. 
  7. Следует минимально использовать значение «другое». Кто-то будет спорить, что к «неизвестному» может быть только один путь, но стоит ли тратить силы на прохождение трех уровней классификации, чтобы в итоге зарегистрировать инцидент, как «другой»? 
  8. Должны быть четкие правила, что и куда распределяется. Очевидно, что в классификации инцидентов избыточность и повторы идут только во вред.
  9. В процессе работы, не допускайте дополнение иерархии новыми категориями и подкатегориями.
  10. Коды закрытия могут добавить дополнительную ценность в вашу классификацию. В особенности при определении точности перехвата инцидента и анализе путей разрешения инцидентов.
  11. И наконец, постарайтесь учесть требования внутренних политик, а также индивидуальные мнения, чтобы создать систему, отвечающую нуждам многих пользователей.

Было бы интересно узнать, что вы думаете по этому поводу, оставляйте свои комментарии, делитесь опытом.

По материалам блога Стефана Манна

Дополнительные материалы

Комментарии (3)

Также рекомендуем