Одним из важных блоков книги и курса 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, в книге «Управление услугами на основе измерений».
Управление инцидентами действительно существенно влияет на уровень удовлетворённости услугами. Поэтому об этом аспекте практики управления инцидентами стоит помнить. И соответствующим образом адаптировать систему измерения и оценки. Возможно, имеет смысл скорректировать назначение практики/процесса так, чтобы удовлетворённость пользователей присутствовала в нём явно.
Надо всегда ставить себя на место пользователя, тогда и будет понятно, что же нужно сделать, что бы пользователь был доволен.
Лучшая техническая поддержка – это та, про которую никто не ничего знает и удивляются, когда узнают, что в компании вообще есть такой отдел.