Комментарии 25
Ясное и чёткое разъяснение. С удовольствием прочитал. Спасибо за статью!
Ещё бы вложить эти мысли в головы тех, кто принимает руководящие решения…
Спасибо, интересно и понятно!
Спасибо, интересно и понятно!
Очень странно, что есть люди, понимающие эскалацию как — переназначением запроса :)
разумно
Хорошая статья. Было бы здорово аналогичное увидеть по борьбе с неверными назначениями инцидента исполнителю(группе) и последующими переназначениями инцидента в процессе его решения.
Не совсем понимаю, о какой проблеме с инцидентами идёт речь.
В моём понимании инцидент прилетает в HelpDesk и там его либо решают (если он стандартный, типа сброса пароля), либо отправляют на 2й уровень. HelpDesk отвечает за то, что правильно выберет группу поддержки 2го уровня. Либо инцидент сразу прилетает на 2й уровень, если его заводят сразу в трекере.
Дальше на входе всегда идёт какая-то фильтрация, чтобы сразу распознать ошибки назначения и переназначить инцидент. Когда инцидент берётся в работу, он уже не должен больше переназначаться. Я сторонник того, что на 3й уровень инцидент не отправляют, вместо этого заводят отдельный запрос. Так получается у всех участников свой чётко очерченый круг ответственности. И SLA легче писать, и следить за метриками.
Если неправильные назначения инцидентов являются проблемой, то их несложно посчитать и сделать метрикой в SLA.
В моём понимании инцидент прилетает в HelpDesk и там его либо решают (если он стандартный, типа сброса пароля), либо отправляют на 2й уровень. HelpDesk отвечает за то, что правильно выберет группу поддержки 2го уровня. Либо инцидент сразу прилетает на 2й уровень, если его заводят сразу в трекере.
Дальше на входе всегда идёт какая-то фильтрация, чтобы сразу распознать ошибки назначения и переназначить инцидент. Когда инцидент берётся в работу, он уже не должен больше переназначаться. Я сторонник того, что на 3й уровень инцидент не отправляют, вместо этого заводят отдельный запрос. Так получается у всех участников свой чётко очерченый круг ответственности. И SLA легче писать, и следить за метриками.
Если неправильные назначения инцидентов являются проблемой, то их несложно посчитать и сделать метрикой в SLA.
HelpDesk отвечает за то, что правильно выберет группу поддержки 2го уровня.В идеале да, и это соблюдается для типовых инцидентов. Но при появлении сложного инцидента он может быть назначен «созвучно описанию» — т.е. тем отделам со второй линии, на кого это больше похоже по функционалу. Зачастую (и по идеологии), на 1 линии сидят недорогие специалисты невысокой квалификации. Можно их конечно пытаться дисциплинировать метрикой, но…
Когда инцидент берётся в работу, он уже не должен больше переназначаться.В идеале, да. Но как быть с инцидентами, которые затрагивают проблему в нескольких филиалах, за каждый филиал своя ответственная группа. Либо, когда в процессе решения инцидента выясняется, что сбой не там где изначально предполагали, нужно привлечение специалистов другого отдела. Можно заводить дочерний запрос — но по основному инциденту уже идёт время решения по его sla + sla на дочерний инцидент, это 100% превышение по времени = будет эскалация.
сбой не там где изначально предполагали, нужно привлечение специалистов другого отдела. Можно заводить дочерний запрос — но по основному инциденту уже идёт время решения по его sla + sla на дочерний инцидент, это 100% превышение по времени
Я предлагаю ставить инцидент на паузу, пока выполняется дочерний запрос. Потому что в текущей ситуации у Вас получается, что инцидент уже почти просрочен, а его надо решать по сути заново, и в таком виде инцидент улетает кому-то в другой отдел. Это подстава в чистом виде. Новый исполнитель будет наказан за не свою плохую работу.
Вообще организацию работ нужно продумывать заранее. Как предполагается поступать грамотно в этой ситуации в соответствии с действующими регламентами? Это типовая ситуация. Я подозреваю, что процедуры работы не очень хорошо продуманы, их надо оптимизировать.
Я предлагаю ставить инцидент на паузу, пока выполняется дочерний запросА как же SLA? Как объяснять бизнесу что мы тут сразу не разобрались и ваш запрос поставили на паузу? :)
Как предполагается поступать грамотно в этой ситуации в соответствии с действующими регламентами?Такие инциденты разбираются вручную Старшим сервис-деск, оценивается время от взятия в работу первым до переадресации второму. Если переадресация происходит при оставшемся до конца решения времени <50% от всего времени отведённого на решение по SLA для данной категории инцидентов, то исполнителю задаются неприятные вопросы. Собственно, аппрувит запросы на переназначение Старший сервис деск. Но это ручной разбор, хочется от него уйти.
А как же SLA? Как объяснять бизнесу что мы тут сразу не разобрались и ваш запрос поставили на паузу?
Как SLA я в другой статье рассматривал.
И надо правильно расставлять акценты. Не «мы тут не разобрались», а наоборот, «мы тут разобрались основательно и нашли, что проблема куда глубже, чем казалась на первый взгляд. Для её решения привлечён такой-то отдел, который должен выполнить вот это за такое-то время.» Мой опыт показывает, что если поддержка честно пашет, то бизнес готов такое понимать.
А у Вас что происходит, если прилетает инцидент, который сразу видно, что невозможно решить за отведённое в SLA время?
А у Вас что происходит, если прилетает инцидент, который сразу видно, что невозможно решить за отведённое в SLA время?Чтобы вот так было прямо сразу по прилёту понятно, такое бывает редко, и насколько я помню за последние несколько лет, это происходит только если в инцидент запихивают масштабные работы на несколько филиалов, это штатная ситуация, по ней действия прописаны в процессной инструкции — в таком случае по инциденту регистрируется несколько дочерних инцидентов пофилиально, и те уже в SLA попадают. А сам инцидент закрывают с пометкой «работы по вашему обращению будут продолжены в рамках {перечисление номеров дочерних инцидентов}». По сути, конечно, это уже изначально не должно было быть инцидентом (а заданием), и должно было быть сразу отклонено, но тут СД идёт на уступки и делает работу заявителя(бизнеса) сам.
Как правило эскалация бывает обусловлена недостаточной квалификацией для самостоятельного решения задачи. Проблема больше соответствия исполнителя занимаемой должности и / или распределения задач исполнителям.
Как правило эскалация бывает обусловлена недостаточной квалификацией для самостоятельного решения задачи.
В моём понимании это не эскалация. Это маршрутизация. Если не по адресу прилетело, то запрос надо переназначить. Если пришло по адресу, а не хватает знаний, то привлекать внутреннюю экспертизу в помощь. Если внутри группы есть специализация, то должен быть и внутренний механизм, как задачи распределяются к подходящему исполнителю.
Ваше определение совпадает с руководством по эскалации Cisco TAC:
If you do not believe that adequate progress is being made or that the quality of Cisco service is satisfactory, we encourage you to escalate the problem to the appropriate level of management by asking for the TAC duty manager.
Прохождение инцидента от первой линии техподдержки до третьей — В ITIL это называется функциональной эскалацией. По моему, ничего мутного в определении.
В приведённом мной примере вообще никакого отношения не имеет. Никто не привлекает ничьего внимания к запросу, в своей зоне ответственности/компетенции не решили — на следующий уровень передаётся. Каким образом запрос может устраивать или нет? С ним нужно работать.
Эскалация — это процедура привлечения внимания к отдельному запросу, когда ход работы над запросом чем-то не устраивает
В приведённом мной примере вообще никакого отношения не имеет. Никто не привлекает ничьего внимания к запросу, в своей зоне ответственности/компетенции не решили — на следующий уровень передаётся. Каким образом запрос может устраивать или нет? С ним нужно работать.
Никто не привлекает ничьего внимания к запросу, в своей зоне ответственности/компетенции не решили — на следующий уровень передаётся. Каким образом запрос может устраивать или нет? С ним нужно работать.
Устраивает или не устраивает не запрос, а ход работ. То есть работы там ведутся, но меня это не устраивает. Если я могу сказать в терминах бизнеса, что меня не устраивает, то я эскалирую. Если не могу, то считаю это личными придирками и не эскалирую. Это с точки зрения инициатора.
А с точки зрения исполнителя, я по другому подхожу к организации работ. Если HelpDesk должен закрывать стандартные инциденты (например, сброс паролей), то с чего вдруг он эти запросы будет передавать на следующий уровень? Пусть выполняет свою работу. Если второй уровень должен решать все инциденты (кроме стандартных, которые решает HelpDesk), то пусть решает. И так далее.
В моём представлении инциденты до третьего уровня не доходят.
Свой пример я привёл исходя «Процедуры по обработке технических претензий клиентов» в Ростелекоме. Внимательно изучив Ваши статьи я ещё больше стал недопонимать термин «эскалация», применяя новые знания к существующей Процедуре, которую мы используем каждый день.
Инцидент приходит на 1 ЛТП (линия техподдержки), оператор по заранее разработанной шпаргалке анализирует претензию и передаёт на 2 ЛТП (дословно в Процедуре — «Эскалация проблемы на 2 ЛТП») или, «Запрос коммерческой эскалации»
До 3 ЛТП доходит очень много инцидентов. Например, у абонента оборван провод и он самостоятельно не может это исправить. Понятно, что этот инцидент может урегулировать только 3ЛТП. Время жизни инцидента устанавливается SLA и равен, к примеру, 24 часа от время поступления заявки до её закрытия. Т.е. эскалация — в данном контексте подразумевает передачу инцидента в следующую зону ответственности согласно таблице (по сути с 1-ой ЛТП на 2- ую и далее 3 ЛТП).
Тем не менее, в этой Процедуре написано следующее:
О случаях, когда претензии передавались руководству мне неизвестны, возможно это что то очень глобальное или когда срок рассмотрения претензии перевалил за 50% отведённого времени SLA.
А вот это выдержка из Процедуры:
Вот так всё запутано. Многие же понимают термин Эскалация, как Вы и подметили «свалить проблемы на другой отдел», в случае, если тот отдел на который «свалили» не согласен может вернуть обратно, у нас даже в системе есть галочка «вернуть обратно» :)
Инцидент приходит на 1 ЛТП (линия техподдержки), оператор по заранее разработанной шпаргалке анализирует претензию и передаёт на 2 ЛТП (дословно в Процедуре — «Эскалация проблемы на 2 ЛТП») или, «Запрос коммерческой эскалации»
До 3 ЛТП доходит очень много инцидентов. Например, у абонента оборван провод и он самостоятельно не может это исправить. Понятно, что этот инцидент может урегулировать только 3ЛТП. Время жизни инцидента устанавливается SLA и равен, к примеру, 24 часа от время поступления заявки до её закрытия. Т.е. эскалация — в данном контексте подразумевает передачу инцидента в следующую зону ответственности согласно таблице (по сути с 1-ой ЛТП на 2- ую и далее 3 ЛТП).
Тем не менее, в этой Процедуре написано следующее:
Если Претензия не решена в установленный срок или существует риск нарушения сроков решения в установленные сроки (Приложение 1 настоящей Процедуры), 1ЛТП должен начать процедуру эскалации. В некоторых случаях, с целью соблюдения сроков решения Претензии эскалация проводится круглосуточно.
Эскалация проводится путём привлечения руководства к решению Претензии с соблюдением иерархического порядка (маршрута эскалации) согласно эскалационным данным и способом, указанными в Таблице эскалации, которая представлена в Приложении настоящей Процедуры.
1ЛТП может начать эскалацию в любой момент при наличии рисков несоблюдения сроков, установленных в Приложении 1 настоящей Процедуры.
О случаях, когда претензии передавались руководству мне неизвестны, возможно это что то очень глобальное или когда срок рассмотрения претензии перевалил за 50% отведённого времени SLA.
А вот это выдержка из Процедуры:
Эскалация – поэтапное информирование руководства заинтересованных подразделений в случае нарушения сроков решения Претензии.
Вот так всё запутано. Многие же понимают термин Эскалация, как Вы и подметили «свалить проблемы на другой отдел», в случае, если тот отдел на который «свалили» не согласен может вернуть обратно, у нас даже в системе есть галочка «вернуть обратно» :)
О, Ростелеком! Значит не показалось.
Я активно участвовал в формировании процедур поддержки их ERP-системы (которая OeBS R12), когда они запускались лет пять назад. Корпоративного маразма было очень много, бороться за здравый смысл было тяжело. Например, помню сказанное при мен определение, в чём разница между вторым и третьим уровнями поддержки. Цитирую почти дословно: «Ну когда попроще, то второй, а если псложнее, то третий!..» Я в результате написал там базовый набор регламентных документов: Регламент поддержки, Релизную политику, Регламент управления изменениями и ряд более мелких. Процедуру эскалации сделал сразу и хорошую, так как я был исполнителем и мне самому это было нужно. До сих пор сносно работает.
В Вашем случае вижу много благообразно выглядещей мути. Намеренно запутанное понятие эскалации, невнятное разделение ответственности по уровням поддержки и т.п. Так поступают, когда ориентируются не на результат, а на процесс. Олимпийский подход.
Так что сочуствую. Как рядовому исполнителю у Вас нет шансов улучшить ситуацию.
Я активно участвовал в формировании процедур поддержки их ERP-системы (которая OeBS R12), когда они запускались лет пять назад. Корпоративного маразма было очень много, бороться за здравый смысл было тяжело. Например, помню сказанное при мен определение, в чём разница между вторым и третьим уровнями поддержки. Цитирую почти дословно: «Ну когда попроще, то второй, а если псложнее, то третий!..» Я в результате написал там базовый набор регламентных документов: Регламент поддержки, Релизную политику, Регламент управления изменениями и ряд более мелких. Процедуру эскалации сделал сразу и хорошую, так как я был исполнителем и мне самому это было нужно. До сих пор сносно работает.
В Вашем случае вижу много благообразно выглядещей мути. Намеренно запутанное понятие эскалации, невнятное разделение ответственности по уровням поддержки и т.п. Так поступают, когда ориентируются не на результат, а на процесс. Олимпийский подход.
Так что сочуствую. Как рядовому исполнителю у Вас нет шансов улучшить ситуацию.
А как бы с Вашей точки зрения выглядело бы продвижение инцидента от 1 до 3 уровня?
Попроще/посложней в моём понимании — это зона компетенций. Я бы не сказал, что 1 уровень простой, ведь на этом уровне закрывается около 50% инцидентов (оплата, просьба перегрузить и т.п.), 2 уровень работает с железом и имеет информацию по массовым авариям (впрочем информация о массовых авариях имеется и у 1 уровня, но они работают на всю Россию и требуется уточнение на 2 ой линии), 2 уровень может войти в оборудование оператора и клиентского, пообщаться с клиентом и закрыть инцидент. Ну, и 3 уровень, это когда требуется личное присутствие сотрудника оператора у абонента. Все уровни географически расположены в разных не то чтобы городах — регионах. По другому никак.
«Ну когда попроще, то второй, а если псложнее, то третий!..»
Попроще/посложней в моём понимании — это зона компетенций. Я бы не сказал, что 1 уровень простой, ведь на этом уровне закрывается около 50% инцидентов (оплата, просьба перегрузить и т.п.), 2 уровень работает с железом и имеет информацию по массовым авариям (впрочем информация о массовых авариях имеется и у 1 уровня, но они работают на всю Россию и требуется уточнение на 2 ой линии), 2 уровень может войти в оборудование оператора и клиентского, пообщаться с клиентом и закрыть инцидент. Ну, и 3 уровень, это когда требуется личное присутствие сотрудника оператора у абонента. Все уровни географически расположены в разных не то чтобы городах — регионах. По другому никак.
Да, согласен, смайликов не поставил. Про проще-сложнее — это же просто эпический маразм какой-то. Конечно у каждого уровня поддержки есть свои функции и свои обязанности. Какие именно — зависит от специфики работ. Вы вот явно пишете про работу с внешними клиентами, я чаще имею дело с внутренними IT-системами, но в каждом случае работа уровней поддержки должна быть чётко очерчена.
В типичном моём случае продвижение от 1‑го до 3‑го уровней поддержки выглядит так.
1‑й уровень, он же HelpDesk, принимает обращения всех пользователей, заводит инциденты. Стандартные инциденты, на которые есть опросные карты (что спросить и что сделать при заданных ответах; например, сброс паролей), решаются. По всем остальным делается диспетчеризация на основе тех же опросных карт, и инцидент назначается на 2‑й уровень поддержки. Если пользователи сами заводят инциденты через веб-интерфейс, то инцидент сразу идёт в соответствующую группу, чаще сразу на 2‑й уровень. HelpDesk должен работать быстро, любое отклонение от стандартной ситуации — это перевод инцидента на 2-й уровень. Но HelpDesk должен или установить группу поддержки 2го уровня, или выслать сервиного инженера, чтобы тот разобрался на месте.
2‑й уровень — функциональный. Здесь аналитики, хорошо знакомые с конкретной системой, исследуют действительно ли инцидент имеет место быть и решат его, если для этого достаточно имеющегося в системе функционала. Если выявлены ошибки в коде или повреждены данные, то 2‑й уровень заводит запрос (дефект) к 3‑му ровню поддержки.
3‑й уровень поддержки — разработчики. Решают дефекты, они же баги в системе.
Если выясняется, что баг относится к коробочной версии продукта, на основе которого сделана система, то заводится запрос на поддержку вендору. Это может делать как 2‑й, так и 3‑й уровни поддержки, в зависимости от того, где был выявлен баг — в функционале или в коде. Вендора при этом можно рассматривать как 4‑й уровень поддержки.
В типичном моём случае продвижение от 1‑го до 3‑го уровней поддержки выглядит так.
1‑й уровень, он же HelpDesk, принимает обращения всех пользователей, заводит инциденты. Стандартные инциденты, на которые есть опросные карты (что спросить и что сделать при заданных ответах; например, сброс паролей), решаются. По всем остальным делается диспетчеризация на основе тех же опросных карт, и инцидент назначается на 2‑й уровень поддержки. Если пользователи сами заводят инциденты через веб-интерфейс, то инцидент сразу идёт в соответствующую группу, чаще сразу на 2‑й уровень. HelpDesk должен работать быстро, любое отклонение от стандартной ситуации — это перевод инцидента на 2-й уровень. Но HelpDesk должен или установить группу поддержки 2го уровня, или выслать сервиного инженера, чтобы тот разобрался на месте.
2‑й уровень — функциональный. Здесь аналитики, хорошо знакомые с конкретной системой, исследуют действительно ли инцидент имеет место быть и решат его, если для этого достаточно имеющегося в системе функционала. Если выявлены ошибки в коде или повреждены данные, то 2‑й уровень заводит запрос (дефект) к 3‑му ровню поддержки.
3‑й уровень поддержки — разработчики. Решают дефекты, они же баги в системе.
Если выясняется, что баг относится к коробочной версии продукта, на основе которого сделана система, то заводится запрос на поддержку вендору. Это может делать как 2‑й, так и 3‑й уровни поддержки, в зависимости от того, где был выявлен баг — в функционале или в коде. Вендора при этом можно рассматривать как 4‑й уровень поддержки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Философия SLA: что такое эскалация и зачем она нужна