Автоматическая функциональная эскалация?

Дальше действовать будем мы!
Виктор Цой.

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

  1. ne_opozdat_na_poezdпрежде всего, автоматическая функциональная эскалация возможно только в схеме с фиксированными маршрутами эскалации (иначе, пока не завершена диагностика на предыдущем шаге, просто неизвестно, куда эскалировать). А это само по себе нечастое явление;
  2. далее, если, например, специалист L2 работает с инцидентом, а он, тем временем, автоматически переназначен на L3, то как об этом узнает специалист L2 и бросит начатую работу – неясно (и что будет с его мотивацией добиваться результатов на своём уровне без эскалации – тоже неясно);
  3. если специалист L2 работу не бросил, L2 и L3 скоро начнут работать параллельно, не зная друг о друге (L2 еще работает, не зная про L3, а L3 предполагает, что L2 уже закончила работать и передала ответственность). То есть фактически функциональной эскалации и не произошло – ответственность не передана.

Из представленных соображений у меня создается впечатление, что единственный вариант, где такая эскалация может работать – это если время Ln истекло, а она не только не решила инцидент, но так и не приняла его в работу. Тогда теоретически можно протолкнуть инцидент дальше. Получается такая своего рода страховка от перегрузки Ln автоматическим привлечением Ln+1.

Однако на практике это предполагает, что специалисты всегда сначала аккуратно отмечают, что они взяли инцидент в работу и только потом, что они его решили. Жизнь, конечно, сложнее. Например, в случае major-инцидента навалится множество заявок, каждую из которых индивидуально принимать в работу просто бессмысленно – все они массово обработаются при закрытии инфраструктурного инцидента. А в случае с автоматической эскалацией все эти заявки сами «уедут» на Ln+1 (и далее по маршруту)? Или для major-инцидентов в правилах автоматической эскалации нужно делать исключение?

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

Коллеги, кто применял или рассматривал такой вариант? Доложите свои соображения, пожалуйста 🙂 Не терпится уже поставить все точки в нужных местах.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

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

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

  1. Юрий Ерин

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

    0
    0
    1. Дмитрий Исайченко Автор

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

      Да и все вопросы по условиям / критериям четкой передачи ответственности между Ln и Ln+1 остаются.

      0
      0
  2. Андрей

    По второму и третъему из приведенных пунктов можно сделать решение, используя возможности инструментов — автоматически оповещать ответственного из  L1 при передаче на L2, сам инцидент при этом пропадет из списка доступных для работы у L1, и так далее. Вопрос — зачем?. Нарушение нормативных сроков выполнения (как приема в работу, так и других) нельзя рассматривать как достаточное основание для автомаического переназначения на L2. Мы в случае нрушения сроков(вернее при приближении события нарушения срока) рекомендуем делать не функциональную эскалацию, а эскалацию на руководителя группы Lx. А вот он уже по результатам проведенного анализа выполняет эскалацию туда, куда следует. Часто нарушение сроков вызвано субъективными причинами (сам же руководитель послал сотрудника за пивом и тот не успел разобраться с инцидентом, на пример:))) ) и перенеправлять в таких случаях инциденты на другие уровни, где задействованы более квалифицированные и , следовательно, более дорогие ресурсы,  будет означать провоцирование конфликтов. Сотрудник на L2 прекрасно поймет причину, по которой на L1 так ничего и не сделали, но заставили его заниматься ерундой.

    0
    0

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

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

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

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

ДЕК
18
Учебный курс:
Основы DevOps
ДЕК
20
Учебный курс:
Основы ITIL (очно)