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

Удовлетворённость инцидентами

Одним из важных блоков книги и курса ITIL® 4 Direct, Plan and Improve (DPI) является подход к формированию системы измерения и оценки. Совсем недавно мне повезло побывать у нас на этом курсе в качестве слушателя. При разборе модели планирования и оценки (Planning and evaluation model) одним из примеров для отработки применения модели была выбрана практика управления инцидентами (Incident Management). И когда после выполнения упражнения мы рассмотрели примеры KPI и PSF (Practice Success Factors, факторы успеха практики – «комплексные функциональные компоненты практики, необходимые для того, чтобы практика реализовывала своё назначение») из публикации «Incident Management ITIL4 Practice Guide», возникла дискуссия, которую я наблюдал не первый раз.

Интересно, что, даже если напомнить о том, что такое влияние есть, некоторые объясняют это влияние исключительно за счёт скорости решения инцидентов. То есть, если сервис-провайдер будет устранять инциденты быстрее, то и удовлетворённость пользователей будет выше. Это правда, но не вся. Ведь на удовлетворённость пользователей (вспомните, например, ваше последнее общение со службой поддержки 😉 ) влияют также то количество итераций в общении. При прочих равных чем меньше пользователю приходится общаться с поддержкой в рамках решения инцидента, тем лучше. Именно поэтому мы контролируем долю инцидентов, решенных с первого обращения (в идеале – «не кладя трубку») – FCR. Не менее важно, чтобы решение было качественным, не требующим переделки – контролируем долю инцидентов, которые были возвращены на доработку. Ну, и, конечно же, качество коммуникаций с пользователями. Культура общения, необходимый и достаточный уровень прозрачности (своевременность оповещений, проактивное информирование).

Таким образом в управлении инцидентами есть масса компонентов, которые заметно влияют на уровень удовлетворённости. Разумеется, это практика отвечает за удовлетворённость не единолично. Как бы прекрасно мы не решали инциденты, если качество услуг ниже требуемого/согласованного, уровень удовлетворённости будет низким. Но верно и обратное утверждение. Если сервис-провайдер не управляет этой стороной Incident Management, то серьёзные вложения в проектирование, разработку и внедрение услуг могут не дать желаемого уровня удовлетворённости.

Почему же об этом часто забывают?

Отчасти в этом, видимо, «виновата» формулировка назначения практики: «Минимизировать негативное влияние инцидентов, восстанавливая нормальную работу услуг как можно быстрее» («The purpose of the incident management practice is to minimize the negative impact of incidents by restoring normal service operation as quickly as possible» [2.1 Purpose and Description, Incident Management ITIL4 Practice Guide]). Явным образом из этой формулировки следует лишь требование к скорости решения инцидентов, с которой мы начали. Разумеется, в дальнейшем тексте публикации говорится и про удовлетворённость.

Кстати, аналогичная ситуация была и в ITIL предыдущей версии. Назначение процесса управления инцидентами звучит так: «Восстановление нормальной работы услуги в кратчайшие сроки и минимизация негативного влияния на работу бизнеса» [раздел 4.2.1.1 Purpose, книги Service Operation, ITIL v3]. Но среди ключевых задач есть и «поддержание удовлетворённости пользователей качеством ИТ-услуг» [раздел 4.2.1.2 Objectives, книги Service Operation, ITIL v3]
Похожую картину можно увидеть в COBIT, ISO 20000, в книге «Управление услугами на основе измерений».

Управление инцидентами действительно существенно влияет на уровень удовлетворённости услугами. Поэтому об этом аспекте практики управления инцидентами стоит помнить. И соответствующим образом адаптировать систему измерения и оценки. Возможно, имеет смысл скорректировать назначение практики/процесса так, чтобы удовлетворённость пользователей присутствовала в нём явно.

 

 

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

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

  • Евгений

    Надо всегда ставить себя на место пользователя, тогда и будет понятно, что же нужно сделать, что бы пользователь был доволен.

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

    • Евгений, спасибо за комментарий!
      Я в какой-то части мог бы согласиться, если бы Вы написали «Лучший сервис-провайдер», а не «Лучшая техническая поддержка». Т.е. если бы было написано «лучший сервис-провайдер – это сервис провайдер, про существование поддержки которого клиенту неизвестно», можно было что-то обсуждать. Даже в этом случае остаётся место для дискуссии, поскольку в некоторых случаях услуги, которые никогда не «ломаются», могут оказаться нецелесообразно дороже, чем услуги, которые таки иногда «ломаются», но быстро и качественно «чинятся».
      В случае же, если мы говорим про поддержку, мы уже предполагаем её существование. И обсуждаем, как сделать так, чтобы она работала хорошо. В этом контексте говорить о том, что хорошая поддержка – это поддержка, которую не видно, по-моему, странно.
      Итого, с тезисом «Надо всегда ставить себя на место пользователя, тогда и будет понятно, что же нужно сделать, что бы пользователь был доволен» вряд ли кто-то будет спорить. Но в остальном это фактическим подмена темы. С той, что заявлена в заметке «влияние практики управления инцидентами на обеспечение удовлетворённости пользователей» на тему «удовлетворённый пользователь». Темы связанные, но не тождественно равные.

      • Евгений

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

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

        • Да, есть такая история. В ITIL 4 тоже появилось понятие automated resolution, или self-healing (“самопочиняющиеся”) инциденты.
          Что, опять же, добавляет деталей в Incident Management, влияющих на удовлетворённость. Но не снимает вопрос с повестки.

  • Андрей другой

    На мой взгляд по-прежнему практически не уделяется внимания экономической составляющей всего этого дела. Т.е. как раньше в Советском союзе – создаваемая система должна соответствовать или превосходить лучшие зарубежные образцы – и ни слова о том, а за какую цену. Так и здесь – пользователь должен быть удовлетворен, а всегда ли экономически обоснован такой подход? Подробнее я об этом вот тут по рассуждал http://www.corisys.ru/images/documents/ITIL/sla_kpi.pdf

    • Андрей, спасибо за соображения!
      Не совсем понимаю, с каким именно тезисом заметки Вы полемизируете? В заметке не говорится о том, что «пользователь должен быть удовлетворен» любой ценой. В ней приведены рассуждения на тему: «Что-то часто при построении практики управления инцидентами люди забывают про эту задачу (обеспечение удовлетворённости)». Вопросы рациональности, хоть и не входят в заявленный охват заметки (она как и любая заметка не обо всём на свете), тем не менее неизбежно затрагиваются в тексте.
      Вообще, с тезисом об отсутствии внимания к экономической составляющей согласиться не могу, поскольку в нашей консалтинговой практике проектов по сервисной экономике довольно много. И рассказывали об этом неоднократно (вебинары, заметки на портале, доклады на конференциях – поисковый запрос «сервисная экономика Cleverics» выдаёт много ссылок). В общем, по моим наблюдениям, интерес организаций к этому вопросу довольно высокий.

      • Андрей другой

        Игорь, я не полемизирую с тезисом. Я говорю о приоритетах и на мой взгляд экономическая целесообразность заслуживает на много большего внимания. Более того – это на мой взгляд должно быть первичным, а уже потом удовлетворенность и т.д. Конечно с точки зрения удовлетворенности все захотят обслуживаться первым классом, вопрос – готовы ли они за это платить. в конечном счете сервисы предоставляются для достижения бизнес результатов, а не для того чтобы кто-то был удовлетворен. Но это сугубо мое личное мнение которым я решил поделиться:))

  • Антон

    Готов при 8×5 вскочить в 3 часа ночи субботы и удовлетворить пользователя (благо – все удаленно), но готов ли пользователь за это заплатить? Может ему это все-таки не так нужно до понедельника? Конечно, он будет в восторге, от того, что его не проигнорировали в нерабочее время, но стоит ли моя нервная система этого?

    • Антон, согласен, стоимость и уровень предоставления услуги должны соотноситься (если мы про устойчивые сервисные отношения).
      Только заметка совсем не об этом.


Добавить комментарий для Игорь ГутникОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;