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

О моем инциденте замолвите слово…

Слушатели на последнем тренинге рассказали о том, как решен у них вопрос эскалации инцидентов в профильные группы ИТ.

Напомню вкратце, что проблема заключается в том, чтобы с одной стороны, сервис-деску не приходилось слишком много знать о доступности и возможностях 2 и 3 линий, чтобы отдавать инцидент прямо в руки самому «правильному» эксперту, а с другой – чтобы инцидент не застаивался «без глазу», не будучи назначен кому-то конкретному.

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

Выглядит у них это так:

  1. Сервис-деск диагностирует инцидент и эскалирует его в профильную команду (в зависимости от модели инцидента, категории, сервиса, местоположения и т.п.).
  2. Все участники команды получают на электронную почту отбивку с описанием инцидента.
  3. Тот участник команды, кто прочитал эту отбивку, и понял, что сможет справиться, назначает инцидент на себя, диагностирует, решает и т.д.
  4. Второй участник, который прочитал и понял, увидит, что задачка уже взята в работу, и перейдет к другим делам.

Тут остается один вопрос: «есть ли исключения из такого правила?».

Бывает же, что ни второй, ни десятый участники команды не захотели брать «вонючую» задачку, понадеявшись на соседа. Так вот – здесь обязанность «проталкивать» инцидент исполнителю возложена (и, как я понял, эта ветка процедур прописана в регламентах) на… инициатора инцидента! Представьте ту же последовательность с его стороны:

  1. Сервис-деск диагностирует инцидент и эскалирует его в профильную команду (в зависимости от модели инцидента, категории, сервиса, местоположения и т.п.).
  2. Инициатору приходит отбивка «Ваш инцидент назначен команде «Икс». Значит, думает он, надо скоро ждать отбивки «Ваш инцидент назначен специалисту».
  3. Инициатор ждёт.
  4. Инициатор ждёт.
  5. Инициатору надоело ждать, и он набирает телефонный номер начальника этой команды (он указан в первой отбивке).

Классно? Прямо как в ITIL Service Design (стр. 108):

… A true partnership should be developed between the IT service provider and the customer, so that a mutually beneficial agreement is reached …

Между поставщиком ИТ-услуг и заказчиком должно быть установлено партнерство, так, чтобы выгода от него была обоюдной.

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

Почему же в ITIL написано, что этой работой должен заниматься сервис-деск?

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

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

  • Dan

    Это шутка?

  • Спасение утопающих – дело рук самих утопающих. Аминь.

  • Anna Krylova

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

    Это рецепт явно не для всех, но это может работать для некрупных(в идеале до 500, максимум до 1000) компаний занимающихся разработкой ПО (т.е. пользователи обладают высокой квалификацией и сознательностью),

  • Grigory Kornilov

    Имхо вы даете пользователю возможность трактовать сроки "Инициатор ждёт / Инициатор ждёт ." и действовать по собственному усмотрению, влиять на деятельность IT.

    Попробуйте для несрочных заявок после первого "Инициатор ждёт" перенаправлять в авторежиме заявку на "начальника этой команды".

  • Pavel Solopov

    А что тут обсуждать? У людей схема работает, предприятие живо и успешно (если платят за тренинги по ITSM, то деньги есть) тут не обсуждать, а повторять надо. Это же тот самый Бест-практис! В отличии от ITIL.

  • Андрей

    Для своих клиентов при подобной схеме мы использовали возможности инструмента – для назначенного инцидента устанавливается нормативное время для перехода из статуса "назначен"  в статус "взят в работу"(он в него переходит, когда аналитик берет его на себя.). По истечении нормативного срока идет оповещение на руководителя группы и он уже предпринимает действия насильственного характра.

  • Кротов Алексей

    В таком случае ИТ-деп-т напоминает замечательную "гордую" птицу. Не понимаю, почему этим "пинком"должен быть инициатор, а не рук-тель группы, к-рый долже быть замотивирован на сроки реакции его отдела/группы в том числе.

  • Андрей

    > Инициатору приходит отбивка «Ваш инцидент назначен команде «Икс». Значит, думает он, надо скоро ждать отбивки«Ваш инцидент

    > назначен специалисту».

    > Инициатор ждёт.

    > Инициатор ждёт.

    > Инициатору надоело ждать, и он набирает телефонный номер начальника этой команды (он указан в первой отбивке).

     

    Инициатор чаще всего не будет даже читать/ вдаваться в детали "отбивок" 🙂 Если ему надоело, будет звонить в Service Desk.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM