Недавно в свете выпуска нового релиза CleverENGINE обсуждали внутри тему функциональной эскалации в управлении инцидентами. Этот, на первый взгляд, несложный вопрос на практике имеет очень важное значение, а принятые по нему решения определяют не только принципы разграничения ответственности за поддержку пользователей, но сказываются и на структуре каталога ИТ-услуг, и на содержании SLA.
Так вот можно выделить два принципиально различных способа функциональной эскалации: с произвольным маршрутом и с фиксированным маршрутом.
- В случае произвольного маршрута специалист, отвечающий за обработку инцидента, выбирает следующий шаг эскалации самостоятельно, в зависимости от результатов диагностики. Например, инцидент, связанный с отказом информационной системы по результатам диагностики может быть назначен администраторам ЦОД или группе, отвечающей за сеть и так далее.
- В случае фиксированного маршрута для каждой услуги заранее определяется состав линий поддержки, а также ответственность и полномочия каждой линии. Например, по прикладной системе цепочка может быть такова: L2 – отдел сопровождения прикладного ПО, L3 – бизнес-аналитики, L4 – разработчики. Ответственность, например, может распределяться следующим образом: L2 отвечает за диагностику на техническом уровне и привлечение (при необходимости) технарей-смежников (если система, например, не работоспособна по причине отказа одного из серверов). В случае, если по результатам диагностики установлено, что проблема именно в ПО, инцидент эскалируется на L3, которая отделяет ошибки ПО от некорректных требований к алгоритмам, ответственность за которые несут бизнес-подразделения. Если постановка была корректной, L3 эскалирует инцидент на L4. Важным моментом в такой схеме является то, что инцидент назначается только в пределах фиксированной цепочки L2-L3-L4. Если необходимо привлечение смежников, это выполняется либо отдельным инцидентом (для чего скорее всего понадобятся технические услуги в каталоге и OLA), либо заданием.
Вообще фиксированная эскалация потенциально может сократить «футбол», повысить точность назначения, особенно в крупных компаниях, с большим количеством функциональных групп, более чётко зафиксировать распределение обязанностей. С другой стороны, работоспособность такой схемы существенно зависит от точности классификации инцидентов по ИТ-услугам на первой линии, что в крупной компании при развитом каталоге ИТ-услуг обеспечить не так-то просто.
Поэтому любопытно, много ли компаний используют схему с фиксированным маршрутом эскалации и что это за компании? Поделитесь опытом, попробуем набрать статистику.
(Украина) Телеком 1, Телеком 2,Телеком 3. 🙂
Невозможно представить без фиксированного маршрута.
Мне кажется, вопрос даже не в зрелости организации, а в допустимом времени реакции (и устранения). Маршруты нарабатываются очень быстро, необходима только фиксация де юре.