В своей статье "Как написать хороший SLA", я поминал, что в SLA просто просится внести процедуру эскалации. Хочу сказать пару слов за эскалацию.
Эскалацию в IT, по-моему, мало кто понимает. В ITIL она как-то мутно определена. Соответственно и дальше, при попытках её внедрить, градус мутности только возрастает. Ни Гугл, ни Яндекс не помогают найти ничего вразумительного. Вместо того, чтобы объяснить эскалацию просто и понятно (как это сделаю я), авторы начинают вводить какие-то новые термины, указывать в чём различие между функциональной и иерархческой эскалацией (зачем вообще это?), вещать что-то про автоматическую эскалацию, ничего не объясняя и уводя в сторону. И при этом из контекста можно предположить, что эскалация — это то ли синоним передачи запроса другому исполнителю, то ли в другое подразделение, то ли привлечение дополнительных ресурсов, то ли повышение приоритета. А иногда я просто теряюсь понять смысл. Всё это вызывает лично у меня ощущение или "кручу-верчу, обмануть хочу", или банальной некомпетенции.
Особенно мило (не могу удержаться и не привести этот пример) выглядит автоматическая "эскалация" запроса на другой уровень поддержки, если (sic!) текущий исполнитель не успевает в заданный в SLA срок. То есть будучи исполнителем, принимаем запрос и держимся изо всех сил, ничего по нему не делаем, пока он не будет вот-вот уже почти просроченным, и… бац! — срабатывает автоматическая "эскалация", которая переназначает запрос на кого-то другого. Профит!.. Главное держать себя в руках и ничего не делать. Можно было бы от души посмеяться, но кое-где именно такую схему "эскалаций" и применяют, выдавая за лучшие практики IT!
Так что же такое эскалация, кому и зачем она нужна? Сейчас расскажу своё понимание, после которого Вы, как я надеюсь, полюбите эскалацию также, как и я. Держитесь крепче за стул.
Сначала развенчаю вышенаписанное, почему это не является эскалацией.
Эскалация не является переназначением запроса. Хотя бы по той простой причине, что переназначение запроса на другого исполнителя называется "переназначением запроса на другого исполнителя". А не эскалацией. И вообще переназначать запрос, если исполнитель уже приступил к работе, категорически нельзя. Единственный правильный способ передачи запроса, который я знаю, это когда новый исполнитель забирает запрос себе сам добровольно, и только после предварительного согласия текущего исполнителя. Потому что взял (дали) запрос — решай до победного конца. Да и разгребать последствия "за того парня" после переназначения — то ещё удовольствие. Событие это скорее форс-мажорное, чем обыденное. Тем более никаких автоматических переназначений. Иначе исполнители будут от работы бегать.
Также эскалация не является повышением приоритета. Потому что даже у не владеющего ситуацией (но владеющего логикой) человека тут же возникает вопрос, а как тогда эскалировать запросы самого высокого приоритета? И, если у нас всего четыре приоритета цифрами от 1 до 4, то эскалировать можно максимум три раза, меняя приоритет с 4 на 3, с 3 на 2 и с 2 на 1 и всё, да? Выглядит подозрительно и нелогично. И потом, если нам по третьему приоритету исполнитель не отвечает из отпуска, то почему по второму вдруг начнёт?
А чем же тогда эскалация является? Определение:
Эскалация — это процедура привлечения внимания к отдельному запросу, когда ход работы над запросом чем-то не устраивает
Вот именно так, а не иначе. Привлечь внимание. Невооружённым глазом видна связь с повышением приоритета — внезапно повышенный приоритет, как и другие подобные несуразные действия, привлечёт к себе внимание, так что такое поведение отчасти смахивает на эскалацию. Но только в том случае, если исполнитель не ушёл в отпуск. Ну и не забываем, что на несуразные действия одной стороны, другая может отреагировать симметрично. На любой ваш вопрос, так сказать, произвольный наш ответ. Так что более правильно понимать эскалацию именно как привлечение внимания. А там уже компетентный человек разберётся, повышать ли приоритет, привлекать ли дополнительную экспертизу или просто придать исполнителю нужное ускорение, вплоть до полной смены его состава. То есть с предыдущими потугами определить эскалацию данное определение согласуется.
Но данное определение уже лучше, потому что оно позволяет эскалировать запросы столько раз, сколько нужно, невзирая на конечное число приоритетов и уровней поддержки.
Идём дальше. У каждой эскалации должен быть повод. Другими словами, что-то не так с запросом, почему-то понадобилось привлекать к нему внимание. Этот повод инициатор обязан указать при эскалации. Без повода эскалаций не бывает. Вот типичные примеры причин для эскалации:
- недовольство ходом работ, требуется указать чем именно (пример: по критичной проблеме за неделю не было предпринято никаких действий)
- выявились новые существенные обстоятельства решаемой проблемы: изменились сроки, объём и другие характеристики решаемой проблемы, которые переводят проблему в новое качество (пример: повреждена не одна запись в БД, а много записей)
- вовлечена одна из VIP-персон (пример: директор департамента взял решение под личный контроль)
- другие существенные обстоятельства.
Если причиной эскалации являются сроки, то надо эти сроки указать и внятно изложить, почему этот срок важен, и что случится, если срок будет нарушен.
Причиной для эскалации не является:
- пользователь эскалировал запрос (а где, собственно, причина?)
- хочу решение прямо сейчас (почему не вчера? или завтра?)
- эскалировано (кем и по какой причине?)
и другие тому подобные ничего не значащие фразы.
Если внятной причины для эскалации инициатор не указал, то первым вопросом при разборе эскалации должна быть именно просьба указать причину. Ну у всех бывает, волновался человек, пропустил важное. Я серьёзно говорю, эскалации часто делают в жёстких стрессовых условиях. Но если причина так и не будет указана, то эскалацию следует закрыть, потому что отсутствует причина эскалации. Если не получается сформулировать внятную причину для эскалации, то это хороший повод задуматься, может и в самом деле не надо ничего эскалировать?
Причина эскалации обычно излагается не техническим языком, нужно изложить где и чем проблема мешает бизнесу. Это так называемая бизнес-причина. Согласитесь, что мелкая техническая проблема может на самом деле доставить много неприятностей бизнесу и наоборот. Сравните:
- техн., Повреждены несколько записей в таблице GL_JE_LINES, нужно устранить до 20 числа месяца.
- бизнес, Повредились проводки в ГК, невозможно закрыть период и предоставить бухгалтерскую и налоговую отчётность, вводить операции следующего периода, с 20 числа Налоговая начнёт начислять пени и штрафы.
Первая причина будет понятна только узкому кругу технических специалистов (причём зачастую только после длительного анализа), вторая же говорит каждому, что весь бизнес уже встал, а скоро ещё и на деньги попадёт.
Привести внятную причину эскалации — это отличный фильтр, который пропустит все случаи, когда действительно надо, и отсечёт большую часть неадеквата.
Что должно случиться после того, как кто-то эскалировал запрос. Нужно рассмотреть эскалацию. Должен появиться исполнитель запроса или кто-то более компетентный (особенно, если причиной эскалации являются действия самого исполнителя) и внятно отреагировать. Под "внятно отреагировать" вообще говоря понимается следующее: проанализировать текущую ситуацию с запросом в свете причины эскалации и предложить инициатору план дальнейших действий, который устроит обе стороны и устранит причину эскалации. Далее действовать по этому плану. Рассмотрение эскалации должно быть оперативным, неотвратимым и качественным. Тут нельзя халтурить.
Кстати, эскалировать может не обязательно инициатор запроса, иногда существенная информация может поступить от кого-то другого. Также для полноты картины замечу, что эскалация совсем не обязательно приводит к повышению приоритета или замене исполнителя, скорее даже обычно не приводит. Приоритет приводится в соответствие только при необходимости, если раньше промахнулись или обстоятельства поменялись. Также может оказаться, что весь план действий будет "продолжаем дальше в том же режиме", если эскалация была не по делу, или может оказаться, что в рамках эскалации приоритет как раз будет понижен. Конечно повышать приоритеты во время эскалаций приходится чаще, это действие требует оперативности и, возможно, других корректировок в работе над запросом, понизить же приоритет можно и штатным порядком. Главное в эскалации, что внимание было привлечено и повлекло за собой действия по устранению причины эскалации и наведению порядка. Рассмотрение эскалации также часто выступает в роли арбитража на проекте, если инициатор и исполнитель не могут договориться. Инициатор иногда хочет странного, а временами и невозможного.
И тут мы уже плавно так подбираемся к вопросу, а зачем вообще нужны эскалации?
С инициатором более или менее понятно. Инициатору запроса это возможность выразить своё неудовольствие и несогласие, а также решить любую нештатную ситуацию. Это хорошо согласуется с интуитивным пониманием слова "эскалация", что позволяет использовать эскалации, в том числе и рядовым пользователям IT-систем, они вполне грамотно и вовремя могут пользоваться эскалацией даже не читая никаких регламентов и инструкций.
А вот зачем нужна эскалация исполнителю? И нужна ли? Этого исполнители часто не понимают, и потому не любят эскалации. А зря.
На первый взгляд кажется, что ситуация несимметрична. Для инициатора это возможность постучать кулаком по столу, и поскандалить, а исполнитель зачем-то должен на это подпрыгивать и реагировать. Причём подпрыгивать быстро и реагировать адекватно. Заняться ему что ли больше нечем?
Давайте посмотрим, что будет если эскалаций не существует. Если у инициатора есть повод для недовольства, то он будет ждать, ждать, ждать, пока терпение не лопнет. И тогда у нас скандал, ругань, кровь кишки жалобы на всё что можно припомнить до третьего колена, привлечение начальства, стрессы, нервы и прочие производственные ужасы. И если при этом ещё повод для недовольства в самом деле имеется, да и в прошлом огрехи были (как чаще всего и бывает ибо nobody's perfect), то мало не покажется никому. Кроме того, во время таких разборок, становится очень сложно вернуться к конструктивным действиям по самому запросу. Инициатор не готов сотрудничать, не желает идти на компромиссы и чем-либо поступаться, решение требуется прямо сейчас и в лучшем виде, на блюдечке с голубой каёмочкой. А проблема обычно нетривиальная, ради тривиальных хай бы не поднимался. Разруливать такие скандалы ой как непросто.
Теперь рассматриваем, что будет в той же ситуации, если имеется хорошо настроенный и чётко работающий механизм эскалаций. Инициатор, вместо того, чтобы терпеть до последнего, проведёт эскалацию запроса сразу, как только осознает, что его что-то идёт не так. Причина эскалации будет изучена, ситуация рассмотрена, необходимые действия запланированы. Работы меньше не станет, это факт, но она останется в штатном режиме, а взаимодействие останется конструктивным. Если план не будет хорош, то скорее всего последует ещё одна эскалация, то есть ошибки неприятны, но не смертельны. Шанс исправиться будет максимальный. И даже если инициатор по какой угодно причине не воспользовался эскалацией, то вместо всего ужаса из предыдущего абзаца ситуация будет разрулена одним вопросом к самому инициатору (и, возможно, его руководителю): "что ж ты не эскалировал?"
Вот так и получается, что работающий механизм эскалации позволяет исполнителю гарантированно избегать жалоб на свою работу. Причём качественно и системно. Повторю ещё раз для лучшего запоминания и даже возьму в рамочку:
Работающий механизм эскалации позволяет исполнителю гарантированно избегать жалоб на свою работу
Мало? При эскалации инициаторы сами показывают, на какие запросы следует обратить особое внимание исполнителю. Причём заранее, до того, как рвануло, и именно в тот момент, когда сами готовы конструктивно поработать со своей стороны. Сами. Заранее. Конструктивно. Прямо праздник какой-то.
Всё ещё мало? Руководителю проекта (подразделения, отдела, группы) участие в эскалациях даёт понимание текущей ситуации на проекте и бесценную информацию для оценки работы подчинённых. Именно в тех обстоятельствах, где качества работы исполнителей проявляются как раз ярче всего. И руководителю известны все текущие потенциально конфликтные запросы. Известны на том уровне, на котором он сам участвует в эскалациях.
Вот и получается, что на самом деле исполнителю механизм эскалаций чуть ли не нужнее, чем инициатору. По-моему, ради такого стоит помучаться с оперативным и качественным рассмотрением эскалаций.
Всё ещё не эскалируете? Зря...
P.S. Изменил название статьи на более понятное
Комментарии (25)
AVX
12.10.2017 13:41Ещё бы вложить эти мысли в головы тех, кто принимает руководящие решения…
Спасибо, интересно и понятно!
bzq Автор
12.10.2017 13:56Да что тут вкладывать, скорее глаза открыть. Глядишь, после прочтения этой статьи кто-нибудь таки настроит у себя на проекте нормальный процесс эскалации. Плюшки-то за это очень даже вкусные. Не руководитель созреет, так рядовые сотрудники потребуют.
it2manager
12.10.2017 15:58Очень странно, что есть люди, понимающие эскалацию как — переназначением запроса :)
bzq Автор
12.10.2017 16:04Да, мне тоже. Но как тогда ещё можно понять устойчивое выражение «эскалировать на следующий уровень поддержки», кроме как передать запрос на решение куда-то-там? Они называют это функциональной эскалацией.
unicsoid
12.10.2017 18:01Часто в головах есть стереотип, что первый, кто берет на себя решение по вопросу — это «человек-роутер», у него нет знаний и он только перекидывает задачи. Поэтому и просят «следующий уровень».
Статья отличная, спасибо.
aragon_sp
12.10.2017 19:13Хорошая статья. Было бы здорово аналогичное увидеть по борьбе с неверными назначениями инцидента исполнителю(группе) и последующими переназначениями инцидента в процессе его решения.
bzq Автор
12.10.2017 19:37Не совсем понимаю, о какой проблеме с инцидентами идёт речь.
В моём понимании инцидент прилетает в HelpDesk и там его либо решают (если он стандартный, типа сброса пароля), либо отправляют на 2й уровень. HelpDesk отвечает за то, что правильно выберет группу поддержки 2го уровня. Либо инцидент сразу прилетает на 2й уровень, если его заводят сразу в трекере.
Дальше на входе всегда идёт какая-то фильтрация, чтобы сразу распознать ошибки назначения и переназначить инцидент. Когда инцидент берётся в работу, он уже не должен больше переназначаться. Я сторонник того, что на 3й уровень инцидент не отправляют, вместо этого заводят отдельный запрос. Так получается у всех участников свой чётко очерченый круг ответственности. И SLA легче писать, и следить за метриками.
Если неправильные назначения инцидентов являются проблемой, то их несложно посчитать и сделать метрикой в SLA.aragon_sp
13.10.2017 12:45HelpDesk отвечает за то, что правильно выберет группу поддержки 2го уровня.
В идеале да, и это соблюдается для типовых инцидентов. Но при появлении сложного инцидента он может быть назначен «созвучно описанию» — т.е. тем отделам со второй линии, на кого это больше похоже по функционалу. Зачастую (и по идеологии), на 1 линии сидят недорогие специалисты невысокой квалификации. Можно их конечно пытаться дисциплинировать метрикой, но…
Когда инцидент берётся в работу, он уже не должен больше переназначаться.
В идеале, да. Но как быть с инцидентами, которые затрагивают проблему в нескольких филиалах, за каждый филиал своя ответственная группа. Либо, когда в процессе решения инцидента выясняется, что сбой не там где изначально предполагали, нужно привлечение специалистов другого отдела. Можно заводить дочерний запрос — но по основному инциденту уже идёт время решения по его sla + sla на дочерний инцидент, это 100% превышение по времени = будет эскалация.bzq Автор
13.10.2017 13:47сбой не там где изначально предполагали, нужно привлечение специалистов другого отдела. Можно заводить дочерний запрос — но по основному инциденту уже идёт время решения по его sla + sla на дочерний инцидент, это 100% превышение по времени
Я предлагаю ставить инцидент на паузу, пока выполняется дочерний запрос. Потому что в текущей ситуации у Вас получается, что инцидент уже почти просрочен, а его надо решать по сути заново, и в таком виде инцидент улетает кому-то в другой отдел. Это подстава в чистом виде. Новый исполнитель будет наказан за не свою плохую работу.
Вообще организацию работ нужно продумывать заранее. Как предполагается поступать грамотно в этой ситуации в соответствии с действующими регламентами? Это типовая ситуация. Я подозреваю, что процедуры работы не очень хорошо продуманы, их надо оптимизировать.aragon_sp
13.10.2017 15:01Я предлагаю ставить инцидент на паузу, пока выполняется дочерний запрос
А как же SLA? Как объяснять бизнесу что мы тут сразу не разобрались и ваш запрос поставили на паузу? :)
Как предполагается поступать грамотно в этой ситуации в соответствии с действующими регламентами?
Такие инциденты разбираются вручную Старшим сервис-деск, оценивается время от взятия в работу первым до переадресации второму. Если переадресация происходит при оставшемся до конца решения времени <50% от всего времени отведённого на решение по SLA для данной категории инцидентов, то исполнителю задаются неприятные вопросы. Собственно, аппрувит запросы на переназначение Старший сервис деск. Но это ручной разбор, хочется от него уйти.bzq Автор
13.10.2017 16:07А как же SLA? Как объяснять бизнесу что мы тут сразу не разобрались и ваш запрос поставили на паузу?
Как SLA я в другой статье рассматривал.
И надо правильно расставлять акценты. Не «мы тут не разобрались», а наоборот, «мы тут разобрались основательно и нашли, что проблема куда глубже, чем казалась на первый взгляд. Для её решения привлечён такой-то отдел, который должен выполнить вот это за такое-то время.» Мой опыт показывает, что если поддержка честно пашет, то бизнес готов такое понимать.
А у Вас что происходит, если прилетает инцидент, который сразу видно, что невозможно решить за отведённое в SLA время?aragon_sp
13.10.2017 16:28А у Вас что происходит, если прилетает инцидент, который сразу видно, что невозможно решить за отведённое в SLA время?
Чтобы вот так было прямо сразу по прилёту понятно, такое бывает редко, и насколько я помню за последние несколько лет, это происходит только если в инцидент запихивают масштабные работы на несколько филиалов, это штатная ситуация, по ней действия прописаны в процессной инструкции — в таком случае по инциденту регистрируется несколько дочерних инцидентов пофилиально, и те уже в SLA попадают. А сам инцидент закрывают с пометкой «работы по вашему обращению будут продолжены в рамках {перечисление номеров дочерних инцидентов}». По сути, конечно, это уже изначально не должно было быть инцидентом (а заданием), и должно было быть сразу отклонено, но тут СД идёт на уступки и делает работу заявителя(бизнеса) сам.
NeverIn
12.10.2017 20:19Как правило эскалация бывает обусловлена недостаточной квалификацией для самостоятельного решения задачи. Проблема больше соответствия исполнителя занимаемой должности и / или распределения задач исполнителям.
bzq Автор
13.10.2017 13:57Как правило эскалация бывает обусловлена недостаточной квалификацией для самостоятельного решения задачи.
В моём понимании это не эскалация. Это маршрутизация. Если не по адресу прилетело, то запрос надо переназначить. Если пришло по адресу, а не хватает знаний, то привлекать внутреннюю экспертизу в помощь. Если внутри группы есть специализация, то должен быть и внутренний механизм, как задачи распределяются к подходящему исполнителю.
navion
12.10.2017 21:02Ваше определение совпадает с руководством по эскалации 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.
bzq Автор
13.10.2017 00:33Спасибо, не знал. Это интересно. Кстати, эскалации в Oracle Support тоже в том же ключе.
Rentable
13.10.2017 00:05Прохождение инцидента от первой линии техподдержки до третьей — В ITIL это называется функциональной эскалацией. По моему, ничего мутного в определении.
Эскалация — это процедура привлечения внимания к отдельному запросу, когда ход работы над запросом чем-то не устраивает
В приведённом мной примере вообще никакого отношения не имеет. Никто не привлекает ничьего внимания к запросу, в своей зоне ответственности/компетенции не решили — на следующий уровень передаётся. Каким образом запрос может устраивать или нет? С ним нужно работать.bzq Автор
13.10.2017 00:28Никто не привлекает ничьего внимания к запросу, в своей зоне ответственности/компетенции не решили — на следующий уровень передаётся. Каким образом запрос может устраивать или нет? С ним нужно работать.
Устраивает или не устраивает не запрос, а ход работ. То есть работы там ведутся, но меня это не устраивает. Если я могу сказать в терминах бизнеса, что меня не устраивает, то я эскалирую. Если не могу, то считаю это личными придирками и не эскалирую. Это с точки зрения инициатора.
А с точки зрения исполнителя, я по другому подхожу к организации работ. Если HelpDesk должен закрывать стандартные инциденты (например, сброс паролей), то с чего вдруг он эти запросы будет передавать на следующий уровень? Пусть выполняет свою работу. Если второй уровень должен решать все инциденты (кроме стандартных, которые решает HelpDesk), то пусть решает. И так далее.
В моём представлении инциденты до третьего уровня не доходят.
Rentable
13.10.2017 10:04Свой пример я привёл исходя «Процедуры по обработке технических претензий клиентов» в Ростелекоме. Внимательно изучив Ваши статьи я ещё больше стал недопонимать термин «эскалация», применяя новые знания к существующей Процедуре, которую мы используем каждый день.
Инцидент приходит на 1 ЛТП (линия техподдержки), оператор по заранее разработанной шпаргалке анализирует претензию и передаёт на 2 ЛТП (дословно в Процедуре — «Эскалация проблемы на 2 ЛТП») или, «Запрос коммерческой эскалации»
До 3 ЛТП доходит очень много инцидентов. Например, у абонента оборван провод и он самостоятельно не может это исправить. Понятно, что этот инцидент может урегулировать только 3ЛТП. Время жизни инцидента устанавливается SLA и равен, к примеру, 24 часа от время поступления заявки до её закрытия. Т.е. эскалация — в данном контексте подразумевает передачу инцидента в следующую зону ответственности согласно таблице (по сути с 1-ой ЛТП на 2- ую и далее 3 ЛТП).
Тем не менее, в этой Процедуре написано следующее:
Если Претензия не решена в установленный срок или существует риск нарушения сроков решения в установленные сроки (Приложение 1 настоящей Процедуры), 1ЛТП должен начать процедуру эскалации. В некоторых случаях, с целью соблюдения сроков решения Претензии эскалация проводится круглосуточно.
Эскалация проводится путём привлечения руководства к решению Претензии с соблюдением иерархического порядка (маршрута эскалации) согласно эскалационным данным и способом, указанными в Таблице эскалации, которая представлена в Приложении настоящей Процедуры.
1ЛТП может начать эскалацию в любой момент при наличии рисков несоблюдения сроков, установленных в Приложении 1 настоящей Процедуры.
О случаях, когда претензии передавались руководству мне неизвестны, возможно это что то очень глобальное или когда срок рассмотрения претензии перевалил за 50% отведённого времени SLA.
А вот это выдержка из Процедуры:
Эскалация – поэтапное информирование руководства заинтересованных подразделений в случае нарушения сроков решения Претензии.
Вот так всё запутано. Многие же понимают термин Эскалация, как Вы и подметили «свалить проблемы на другой отдел», в случае, если тот отдел на который «свалили» не согласен может вернуть обратно, у нас даже в системе есть галочка «вернуть обратно» :)bzq Автор
13.10.2017 11:46+1О, Ростелеком! Значит не показалось.
Я активно участвовал в формировании процедур поддержки их ERP-системы (которая OeBS R12), когда они запускались лет пять назад. Корпоративного маразма было очень много, бороться за здравый смысл было тяжело. Например, помню сказанное при мен определение, в чём разница между вторым и третьим уровнями поддержки. Цитирую почти дословно: «Ну когда попроще, то второй, а если псложнее, то третий!..» Я в результате написал там базовый набор регламентных документов: Регламент поддержки, Релизную политику, Регламент управления изменениями и ряд более мелких. Процедуру эскалации сделал сразу и хорошую, так как я был исполнителем и мне самому это было нужно. До сих пор сносно работает.
В Вашем случае вижу много благообразно выглядещей мути. Намеренно запутанное понятие эскалации, невнятное разделение ответственности по уровням поддержки и т.п. Так поступают, когда ориентируются не на результат, а на процесс. Олимпийский подход.
Так что сочуствую. Как рядовому исполнителю у Вас нет шансов улучшить ситуацию.
Rentable
13.10.2017 17:55А как бы с Вашей точки зрения выглядело бы продвижение инцидента от 1 до 3 уровня?
«Ну когда попроще, то второй, а если псложнее, то третий!..»
Попроще/посложней в моём понимании — это зона компетенций. Я бы не сказал, что 1 уровень простой, ведь на этом уровне закрывается около 50% инцидентов (оплата, просьба перегрузить и т.п.), 2 уровень работает с железом и имеет информацию по массовым авариям (впрочем информация о массовых авариях имеется и у 1 уровня, но они работают на всю Россию и требуется уточнение на 2 ой линии), 2 уровень может войти в оборудование оператора и клиентского, пообщаться с клиентом и закрыть инцидент. Ну, и 3 уровень, это когда требуется личное присутствие сотрудника оператора у абонента. Все уровни географически расположены в разных не то чтобы городах — регионах. По другому никак.bzq Автор
14.10.2017 21:16Да, согласен, смайликов не поставил. Про проще-сложнее — это же просто эпический маразм какой-то. Конечно у каждого уровня поддержки есть свои функции и свои обязанности. Какие именно — зависит от специфики работ. Вы вот явно пишете про работу с внешними клиентами, я чаще имею дело с внутренними IT-системами, но в каждом случае работа уровней поддержки должна быть чётко очерчена.
В типичном моём случае продвижение от 1?го до 3?го уровней поддержки выглядит так.
1?й уровень, он же HelpDesk, принимает обращения всех пользователей, заводит инциденты. Стандартные инциденты, на которые есть опросные карты (что спросить и что сделать при заданных ответах; например, сброс паролей), решаются. По всем остальным делается диспетчеризация на основе тех же опросных карт, и инцидент назначается на 2?й уровень поддержки. Если пользователи сами заводят инциденты через веб-интерфейс, то инцидент сразу идёт в соответствующую группу, чаще сразу на 2?й уровень. HelpDesk должен работать быстро, любое отклонение от стандартной ситуации — это перевод инцидента на 2-й уровень. Но HelpDesk должен или установить группу поддержки 2го уровня, или выслать сервиного инженера, чтобы тот разобрался на месте.
2?й уровень — функциональный. Здесь аналитики, хорошо знакомые с конкретной системой, исследуют действительно ли инцидент имеет место быть и решат его, если для этого достаточно имеющегося в системе функционала. Если выявлены ошибки в коде или повреждены данные, то 2?й уровень заводит запрос (дефект) к 3?му ровню поддержки.
3?й уровень поддержки — разработчики. Решают дефекты, они же баги в системе.
Если выясняется, что баг относится к коробочной версии продукта, на основе которого сделана система, то заводится запрос на поддержку вендору. Это может делать как 2?й, так и 3?й уровни поддержки, в зависимости от того, где был выявлен баг — в функционале или в коде. Вендора при этом можно рассматривать как 4?й уровень поддержки.
rd_nino
Ясное и чёткое разъяснение. С удовольствием прочитал. Спасибо за статью!
bzq Автор
И Вам спасибо за отзыв. Хорошее слово, оно и кошке приятно.