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

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

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

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

  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-инцидентов в правилах автоматической эскалации нужно делать исключение?

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

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

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

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

  • Юрий Ерин

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

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

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

  • Андрей

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM