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

Функциональная эскалация

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

Так вот можно выделить два принципиально различных способа функциональной эскалации: с произвольным маршрутом и с фиксированным маршрутом.

  • В случае произвольного маршрута специалист, отвечающий за обработку инцидента, выбирает следующий шаг эскалации самостоятельно, в зависимости от результатов диагностики. Например, инцидент, связанный с отказом информационной системы по результатам диагностики может быть назначен администраторам ЦОД или группе, отвечающей за сеть и так далее.
  • В случае фиксированного маршрута для каждой услуги заранее определяется состав линий поддержки, а также ответственность и полномочия каждой линии. Например, по прикладной системе цепочка может быть такова: L2 – отдел сопровождения прикладного ПО, L3 – бизнес-аналитики, L4 – разработчики. Ответственность, например, может распределяться следующим образом: L2 отвечает за диагностику на техническом уровне и привлечение (при необходимости) технарей-смежников (если система, например, не работоспособна по причине отказа одного из серверов). В случае, если по результатам диагностики установлено, что проблема именно в ПО, инцидент эскалируется на L3, которая отделяет ошибки ПО от некорректных требований к алгоритмам, ответственность за которые несут бизнес-подразделения. Если постановка была корректной, L3 эскалирует инцидент на L4. Важным моментом в такой схеме является то, что инцидент назначается только в пределах фиксированной цепочки L2-L3-L4. Если необходимо привлечение смежников, это выполняется либо отдельным инцидентом (для чего скорее всего понадобятся технические услуги в каталоге и OLA), либо заданием.

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

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

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

  • Анатолий Павлюченко

    (Украина) Телеком 1, Телеком 2,Телеком 3. 🙂
    Невозможно представить без фиксированного маршрута.
    Мне кажется, вопрос даже не в зрелости организации, а в допустимом времени реакции (и устранения). Маршруты нарабатываются очень быстро, необходима только фиксация де юре.

    • “Невозможно представить без фиксированного маршрута.”

      Анатолий, поясните, пжл, – почему “невозможно представить”. Я вот могу, запросто 🙂 Например, за счет чего такая схема сокращает время реакции?

    • Вот Вам ещё оно соображение к вопросу о верности тезиса “Невозможно представить без фиксированного маршрута”. Если бизнес-каталог сформирован от ИТ-систем, я реализацию с фиксированной цепочкой вполне могу представить (хотя и не считаю её неизбежной).
      Однако если мы представим другую ситуацию – например, каталог услуг сформирован от бизнес-процессов – то с фиксированной цепочкой всё сразу становится сложнее, ведь одна услуга будет зависеть от нескольких систем. L2 выделить ещё можно, но вот более глубокие линии всё же скорее будут специализироваться на конкретных решениях, поэтому у L2 для координации действий по восстановлению услуги должна быть возможность эскалации на различные профильные группы. Иначе мы рискуем быстро “скатиться” в вырожденный случай, когда за услуги номинально отвечает L1, а всех остальных привлекает только заданиями, потому что они отвечают только за свои функциональные области. Мне по-прежнему кажется, что это не самый лучший вариант (уже обсуждали: http://www.realitsm.ru/2010/11/vzaimodejstvie/).
      Что скажете?

      • Pavel Solopov

        У меня складывается ощущение, что в фиксированной схеме вы не предполагаете использование “условных операторов” и “ветвлений”. Это так?

        • Ветвлений – нет. Но возможно изменение цепочки при переклассификации обращения.

          • Pavel Solopov

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

            • Суммируя суть Ваших комментариев, получаем: обе схемы – хлам 🙂 Павел, откройте секрет, а Вы что используете?

              • Pavel Solopov

                Зачем же так кардинально. У каждого подхода есть плюсы и минусы. 🙂 Хотел вам ответить развернуто в формате отдельной статьи (в комментах не удобно большие тексты писать), да так и не нашёл времени. К тому же ответ надо начинать с определения граничных условий и фиксации понятий, дабы было понятно на какой основе дискутируем. Да и к тому же, судя по активности, тема кроме нас с вами мало кому интересна. 🙂
                Да как собственно и ITSM вообще. 🙂

  • Pavel Solopov

    Дмитрий, Вы уж извините, но я не про статистику. Я про формулировку. Точнее про вашу трактовку, мне кажется в такой трактовке эти два подхода не могут противопоставляться друг другу.
    В качестве примера для произвольной эскалации, Вы рассматриваете эскалацию на другие функцилнальные направления (прикладник на ЦОД или сетевиков). А рассматривая эскалацию фиксированную, рассматриваете эскалацию внутри одной функциональной группы, при этом эскалация на смежников происходит так же произвольно, как я понял.

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

    • “А рассматривая эскалацию фиксированную, рассматриваете эскалацию внутри одной функциональной группы, при этом эскалация на смежников происходит так же произвольно, как я понял.”

      Павел, нет, это не так. Читайте внимательней: “Важным моментом в такой схеме является то, что инцидент назначается только в пределах фиксированной цепочки L2-L3-L4. Если необходимо привлечение смежников, это выполняется либо отдельным инцидентом (…), либо заданием”.

      • Pavel Solopov

        Дмитрий, так ли принципиально, как мы привлекаем смежников, назначая рабочее задание, создавая новый инцидент или назначая на них имеющийся? Вопрос как мы принимаем решение какого смежника привлечь.
        Извините за навязчивость, но хотелось бы ещё раз вернуться к приведённым Вами описаниям маршрутов.
        В описании произвольного маршрута вы упоминаете только о том, как принимается решение о привлечении смежников, а именно “самостоятельно, в зависимости от результатов диагностики”.
        А как инцидент эскалируется внутри функционального направления по тем самым L2-L3-L4, о которых говорите в описании фиксированной схемы, ничего не говорите. Этих линий при произвольной схеме нет вообще или назначение по ним тоже осуществляется “самостоятельно, в зависимости от результатов диагностики”? В последнем случае не ясно зачем вообще выделять линии, тогда…

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

        Уж простите, опять же, мою занудность.

        • “А как инцидент эскалируется внутри функционального направления по тем самым L2-L3-L4, о которых говорите в описании фиксированной схемы, ничего не говорите”

          Как так “не говорите”? Там же целый кусок текста с примером того, как распределена ответственность и как выполняется эскалация?

          • Pavel Solopov

            Там же целый кусок текста
            В описании произвольного маршрута?

            • В произвольном маршруте L3-L4 вообще не нужны. Зачем они там, если мы назначаем на ту группу, которая может обработать, не зависимо от линий поддержки?

              • Pavel Solopov

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

                Не знаю конечно,
                но мне кажется, что для больших серьёзных систем, в поддержке которых задействовано много людей, такой подход не эффективен. Но это мои соображения, как теоретика. 🙂

              • Pavel Solopov

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

                • …а вот же чуть ниже Игорь Муратов очень хорошо написал по этому поводу: “Предполагается что инженеры достаточно грамотны чтобы произвести маршрутизацию проблемы в правильном направлении. Это позволяет сократить время обработки инцидента проводя его по наиболее быстрому маршруту.” Ну и дальше по тексту, собственно.
                  То есть риски, о которых вы говорите, в разной степени вероятны в разных организациях. И в некоторых – приемлемы.

                  • Pavel Solopov

                    Он же (Игорь) далее пишет:
                    “Единственное применение фиксированным связям я вижу если эскалация идет от Junior к Senior сотрудникам. Т.е. различия уровней не в функциях, а в наличии знаний либо широте полномочий.”

                    Не тут ли как раз речь про линии поддержки?

  • Igor Muratov

    Palm, Cloud Services
    Мы не используем фиксированные цепочки. Предполагается что инженеры достаточно грамотны чтобы произвести маршрутизацию проблемы в правильном направлении. Это позволяет сократить время обработки инцидента проводя его по наиболее быстрому маршруту.
    Единственное применение фиксированным связям я вижу если эскалация идет от Junior к Senior сотрудникам. Т.е. различия уровней не в функциях, а в наличии знаний либо широте полномочий. Таким образом, каждый уровень должен охватывать все возможные функции для решения проблемы и если их оказывается недостаточно то тогда производить эскалацию. Соответственно, все сложные инциденты автоматически получают некоторую задержку на первом уровне. Кроме того, привлечение смежников, а уж тем более генерация нового инцидента со своим SLA, гарантированно приводит к увеличению сроков.
    Для произвольной маршрутизации действительно характерно “зацикливание”, когда проблема застревает между двумя-тремя функциональными исполнителями. Это решается уже задействованием управленца который разруливает ситуацию в ручном режиме. Однако такие сбои происходят не очень часто и в целом не снижают эффективности.
    Вообще, я бы сказал что эти два метода применимы в разных ситуациях. При большом потоке простых проблем предпочтительней использовать фиксированные маршруты. Если же уровень сложности проблем выше среднего, стоит использовать более гибкую маршрутизацию.

  • Дима, мне в целом кажется, что ты недооцениваешь роль количества и сложности решаемых инцидентов при генерации системных решений (это же касается и твоей статьи о приоритетах).

    Здесь – “много тупых задач” намертво фиксированная маршрутизация с редким привлечением эскалации, “мало, но очень сложных задач” простая маршрутизация на группу, с привлечением квалифицированного эскперта чуть ли не сразу. А все, что посередине – ищем компромисс.

    • “Дима, мне в целом кажется, что ты недооцениваешь роль количества и сложности решаемых инцидентов при генерации системных решений”

      Поясни, пжл, что ты имеешь ввиду.

      • У тебя решение общее – делай так, а для разного количества и сложности поступающих объектов (не обязательно обращений\инцидентов даже) решения могут оказаться сильно разными.

        Например, для потока сложных, экспертных заявок 10-15 в месяц на 1 эксперта система приоритетов в SD вообще не нужна. С эскалацией аналогично, ну я вышел отписал.

        • Вышел = Выше 😀

        • “У тебя решение общее — делай так”

          Да нет, напротив – понимаю, что оба варианта имеют свою область применимости. В частности какое-то время назад отстаивал эту точку зрения у нас в компании, когда мы обсуждали функциональные расширения в очередном плановом релизе CleverENGINE (по итогам и родился этот пост).

          Что касается приоритетов – я согласен, что они нужны не всегда. У нас даже есть такие реализации процессов – без приоритетов. Но это реально редкий случай. И даже в этих редких случаях отсутствие приоритетов – скорее некоторое состояние управления, чем его отличительная черта. Например, в описанном тобой примере про экспертную поддержку приоритеты запросов друг относительно друга не нужны. Но приоритет запросов на поддержку относительно других плановых работ – важен. Разве что ресурсов с таким запасом, что на одного человека никогда не падает две задачи. Но это… Отпустите меня туда работать 🙂

          • Ну, я же не вижу – как там внутри у вас все обсуждается. Хотя был бы не против явно, обмен опытом всегда очень полезен 8)))

            • Pavel Solopov

              Предлагаю затребовать от клеверикса вести веб-трансляции всех внутренних обсуждений. 🙂

              • “Включаем камеру из камеры”, как говорили в прекрасном мультике про Незнайку на Луне 🙂


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM