Что говорит о закрытии инцидентов ITIL

ITIL рекомендует закрывать инциденты на первой линии с помощью функции service desk.

Рекомендация почти дословно звучит так: «Службе service desk следовало бы удостовериться в том, что инцидент полностью исчерпан, пользователи удовлетворены и согласны с тем, что инцидент можно закрыть» (Service Operation 4.2.5.9).

Кроме этого, ITIL рекомендует службе service desk выполнить несколько процедур: 

• указать код закрытия

• выполнить опрос удовлетворенности пользователя

•  выполнить документирование закрытия инцидента

•  определить есть ли связь с текущей проблемой с целью избегания повторения инцидента

• формально закрыть инцидент (изменить статус на «закрыто»)

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

Несколько подводных камней

Рекомендация ITIL «закрывать инциденты» на первой линии, вполне понятна. Service desk , как владелец инцидентов, отслеживает жизненный цикл и пытается снизить влияние человеческого фактора на второй линии. А главное – экономия ресурсов. Имеется ввиду ситуация при которой пресекается попытка сотрудников на второй линии, формально закрыть инциденты, но при этом фактически по тем или иным причинам не устранить инцидент или выполнить недостаточный набор действий для того, чтобы полностью устранить инцидент.

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

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

О пользователях

Представьте, Вы сидите, работаете. Вдруг у Вас что-то перестало работать. Вы звоните в техподдержку и в дальнейшем, Вам, как пользователю будут неоднократно звонить ИТ-специалисты. Количество звонков будет разным, но если все заявки закрываются на первой линии, то количество звонков будет гарантированно выше чем в ситуации, когда часть заявок будет закрываться на второй линии. Как говорится «не отходя от кассы». Люди разные, кого-то это будет раздражать.

Разумеется, неадекватные люди встречаются и среди пользователей. Они могут грубить уже после первого звонка. Эти вещи остаются всегда «за скобками».

Закрытие заявок на второй линии, возможные варианты

Возникает вопрос, можно ли организовать закрытие заявок на второй линии?

А почему нет? Приведу свои доводы.

Во-первых, первая линия бывает разной квалификации (экспертная, общей квалификации и низкой квалификации). Этот фактор обязательно следует учитывать.

Во-вторых, надо принимать во внимание текущую специфику: общую численность персонала на обоих линиях поддержки, зрелость процесса и организации, количество ИТ систем, тип поставщика ИТ услуг и др факторы.

В-третьих, учитывать общую специфику бизнеса (критичность бизнес услуг, территориальную распределенность, ведение бизнеса в пределах одной или нескольких стран, клиентскую базу бизнеса и тд)

Напрашивается относительно простое решение: включить в SLA требования для пользователей, согласно которому они должны информировать ИТ о недобросовестном выполнении работы. В этом случае не понадобится закрывать заявки на первой линии и повторно «терзать» пользователей, докучая одними и теми же вопросами. Это шаг на уровне сервисного подхода. А второй шаг сделать на уровне процессного подхода: разработать метрики, которые позволяли бы отслеживать недобросовестную работу сотрудников и первой и второй линий в отношении закрытия инцидентов. Например, обязать линейных руководителей групп сотрудников на второй линии, просматривать записи о закрытых инцидентах с целью проверки корректности выполнения документирования и других процедур.

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

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

Не забыть о VIP пользователях. Необходимо вести актуальный учет данной категории пользователей и уделять больше внимания контролю при закрытии заявок используя ресурсы первой линии.

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

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

В любом случае, необходим баланс между рисками и управляемостью.

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

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую