Закрываем инциденты на второй линии, возможен ли такой сценарий?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

Узнайте больше!

Комментарии и мнения

  1. Андрей другой

    Это как раз тот случай, когда к ITIL надо относиться как к рекомендации, а не как к уставу. У нас в одной крупной компании было два процесса закрытия. Один для крупного предприятия и другой для московского офиса с випами. На предприятии инцидент закрывали исполнители (а это могла быть и первая и вторая линия)и оповещали юзверя почтой в которой была ссылка на страницу, где он мог высказаться по результатам или переоткрыть инцидент. С випами процесс шел как по ITIL — оповещение о решении инцидента, перезвон его высочеству и все прочие приседания. И только после всего политеса закрытие. Сделано так было по одной простой причине — у ServiceDesk с випами было от силы 10 инцидентов и заявок в день, а на предприятии на каждого диспетчера на первой линии более 30 инцидентов (заявки шли через портал самообслуживания без участия диспетчеров) в день. При этом было требования закрывать до 80% на первой линии. Т.е. времени на все формальные приседания по ITIL просто не было. Так что — ITIL конечно хорошо, но и о людях думать надо.:)))

    1. Ашот

      Требование закрывать 80% на первой как минимум странно: специалист априори менее компетентен, ограничен в правах и функционале.

      При достаточной зрелости, если инциденты будут только с оборудованием то % будет стремится к 0, разве это будет показателем того что 1й линия работает плохо?

      У нас 50% инцидентов закрывается на 2й линии и 10-15% rfs.

  2. Евгения

    У меня есть такой пример тоже.

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

    Конечно и 1я линия тоже закрывала инциденты.

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

  3. Сергей

    Доброго.

    На одном из предприятий (большая территориальная распределенность) строили схему где только 2-ая и последующие линии закрывали инциденты. 1-ая линия только регистрировала и маршрутизировала заявки.

    Такие схемы много где работают — а что именно интересует в организации подобной схемы?

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

    Конечно, нужно закрывать обращения на 2-3 линии (статус Решено — уведомление инициатору — Инициатор оценивает работу или отклоняет решение — статус Закрыто/в Работу или при отсутствии обратной связи от Инициатора: закрытие обращения через ~1 неделю). С приходом сервисов самообслуживания — можно существенно экономить на ресурсах ½ линии.

  5. Алексей

    У меня отдел совмещает в себе, и первую, и вторую линию, компания порядка 700 сотрудников. Времени звонить сотрудникам для взятия обратной связи нет, тем более что кто делает заявку, он же ее переводит в статус решена, я провожу уже закрытие заявки, после ее проверки. На самом деле все решается получением обратной связи у заявителей по почте, терроризировать их звонками совсем не обязательно, это позволяют сделать очень многие ITSM-системы. При переводе заявки в статус Решена приходит письмо со ссылкой, где сотрудник может оценить хорошо или плохо она выполнена и оставить комментарий. В случае плохо отзыва создается новая заявка, которую должен отработать руководитель и разобраться в ситуации.

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

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ФЕВ
21
Учебный курс:
CMDB, управление конфигурациями и активами (Осталось 3 места)
ФЕВ
25
МАР
4
Учебный курс:
Основы DevOps