В своей статье «Как написать хороший SLA» Я упомянул, что SLA просто требует процедуры эскалации.
Я хочу сказать несколько слов для эскалация .
«Масштабирование в ИТ, на мой взгляд, мало кто понимает. В ITIL это как-то расплывчато определено.
Соответственно, в дальнейшем при попытке его внесения степень помутнения только возрастает. Ни Гугл, ни Яндекс не помогают найти ничего вразумительного.
Вместо того, чтобы просто и понятно объяснить эскалацию (как это сделаю я), авторы начинают вводить какие-то новые термины, указывать на разницу между функциональной и иерархической эскалацией (зачем это вообще нужно?), говорить об автоматической эскалации, ничего не объясняя и не приводя прочь.
И в то же время из контекста можно предположить, что эскалация – это либо синоним передачи запроса другому исполнителю, либо в другой отдел, либо привлечение дополнительных ресурсов, либо повышение приоритета.
А иногда я просто затрудняюсь понять смысл.
Лично у меня все это вызывает ощущение либо «выкручиваюсь, хочу обмануть», либо банальной некомпетентности.
Особенно приятно (не могу не привести этот пример) автоматическая «эскалация» запроса на другой уровень поддержки, если (sic!) текущий подрядчик не укладывается в сроки, указанные в SLA. То есть, будучи исполнителем, мы принимаем просьбу и держимся изо всех сил, ничего с ней не делаем, пока она почти не просрочена, и.
бац! — срабатывает автоматическая «эскалация», которая переназначает запрос кому-то другому.
Прибыль!.
Главное — держать себя в руках и ничего не делать.
Можно было бы посмеяться от души, но кое-где именно такую схему «эскалации» применяют, выдавая за лучшие IT-практики! 
Так что же такое эскалация, кому она нужна и почему? Теперь я расскажу вам свое понимание, после чего, надеюсь, вы полюбите эскалацию так же, как и я.
Держитесь крепче за стул.
Для начала развенчу вышесказанное, почему Этот это не эскалация.
ЭМасштабирование не является перенаправлением запроса.
Хотя бы по той простой причине, что переназначение запроса на другого исполнителя называется «переназначение запроса на другого исполнителя».
Не эскалация.
Вообще категорически запрещено переназначать заявку, если исполнитель уже приступил к работе.
Единственный правильный способ передачи запроса, который мне известен, это когда новый исполнитель забирает запрос себе добровольно и только после предварительного согласия текущего исполнителя.
Потому что вы приняли (отдали) просьбу – решайте до победного конца.
А разбираться с последствиями «для того парня» после переназначения — то еще удовольствие.
Данное событие является скорее форс-мажорным событием, чем обычным.
Причем никаких автоматических переназначений.
В противном случае артисты сбегут с работы.
Кроме того, эскалация не является повышением приоритета.
Потому что даже у человека, не знающего ситуации (но знающего логику), сразу возникает вопрос: как тогда эскалировать запросы высшего приоритета? И, если у нас всего четыре приоритета с номерами от 1 до 4, то мы можем эскалировать максимум три раза, меняя приоритет с 4 на 3, с 3 на 2 и с 2 на 1 и всё, да? Это выглядит подозрительно и нелогично.
И потом, если подрядчик не отвечает нам по третьему приоритету из отпуска, то почему он вдруг начнет по второму? Что же такое эскалация? Определение:
Эмасштабирование — процедура привлечения внимания к отдельному запросу, когда ход работы над запросом по каким-либо причинам неудовлетворителен.Именно так, и не иначе.
Привлекать внимание.
Связь с повышением приоритета видна невооруженным глазом — внезапно повышенный приоритет, как и другие подобные абсурдные действия, привлечет внимание, поэтому отчасти такое поведение выглядит как эскалация.
Но только в том случае, если исполнитель не ушел в отпуск.
Ну и не забывайте, что на неловкие действия одной стороны другая может отреагировать симметрично.
На любой ваш вопрос, так сказать, наш ответ произволен.
Так что правильнее понимать эскалацию именно как привлечение внимания.
И тогда грамотный человек разберется, стоит ли повысить приоритет, привлечь дополнительную экспертизу или просто дать исполнителю необходимое ускорение, вплоть до полной смены его состава.
То есть это определение согласуется с предыдущими попытками дать определение эскалации.
Но это определение лучше, поскольку позволяет эскалировать запросы столько раз, сколько необходимо, независимо от конечного числа приоритетов и уровней поддержки.
Вперед, продолжать.
У каждой эскалации должна быть причина .
Другими словами, что-то было не так с запросом, на него зачем-то нужно было обратить внимание.
Эту причину инициатор должен указать при эскалации.
Без причины не бывает обострений.
Вот типичные примеры причин эскалации:
- недовольство ходом работы, нужно указать что именно (пример: по критической проблеме за неделю не было предпринято никаких действий)
- возникли новые существенные обстоятельства решаемой задачи: изменились сроки, объем и другие характеристики решаемой задачи, которые переводят проблему в новое качество (пример: повреждена не одна запись в базе данных, а множество записей)
- задействован один из VIP-персон (пример: директор департамента принимал решение под личным контролем)
- иные существенные обстоятельства.
Причиной эскалации не является:
- пользователь эскалировал запрос (и в чем именно причина?)
- Мне нужно решение прямо сейчас (почему не вчера? или завтра?)
- эскалация (кем и по какой причине?)
Если инициатор не указал четкой причины эскалации, то первым вопросом при анализе эскалации должна быть просьба указать причину.
Ну, со всеми бывает, человек волновался и упустил что-то важное.
Я говорю серьезно, эскалация часто происходит в тяжелых стрессовых условиях.
Но если причина не указана, эскалацию следует закрыть, поскольку причин для эскалации нет. Если вы не можете сформулировать четкую причину эскалации, то это хороший повод задуматься, а может, действительно и не нужно ничего эскалировать? Причина эскалации обычно указывается.
Нет Говоря техническим языком, нужно изложить, где и как проблема мешает бизнесу.
Это так называемая деловая причина.
Согласитесь, что небольшая техническая проблема на самом деле может принести бизнесу массу неприятностей, и наоборот. Сравнивать:
- тех.
, Несколько записей в таблице GL_JE_LINES повреждены и должны быть исправлены до 20 числа текущего месяца. - бизнес , Записи в книге учета повреждены, невозможно закрыть период и предоставить бухгалтерскую и налоговую отчетность, внести проводки за следующий период, с 20-го числа налоговая начнет начислять пени и штрафы.
Четкое объяснение причины эскалации — отличный фильтр, который пропустит все случаи, когда это действительно необходимо, и отсечет большую часть неуместных.
Что должно произойти после того, как кто-то эскалирует запрос.
Необходимо учитывать эскалацию.
Исполнитель запроса или кто-то более компетентный должен явиться (особенно, если причиной эскалации являются действия самого исполнителя) и четко отреагировать.
В целом, «реагировать четко» означает следующее: проанализировать текущую ситуацию с запросом с учетом причины эскалации и предложить инициатору план дальнейших действий , что удовлетворит обе стороны и устранит причину эскалации.
Продолжайте действовать по этому плану.
Рассмотрение эскалации должно быть быстрым, неотложным и качественным.
Здесь нельзя бездельничать.
Кстати, не обязательно инициатор запроса может перейти на эскалацию; иногда важная информация может исходить от кого-то другого.
Также для полноты картины отмечу, что эскалация не обязательно приводит к повышению приоритета или замене исполнителя; скорее, обычно это даже не приводит к этому.
Приоритет корректируется только в случае необходимости, если ранее были допущены ошибки или изменились обстоятельства.
Также может оказаться, что весь план действий будет «продолжать дальше в том же режиме», если эскалации не было, или может оказаться, что в рамках эскалации приоритет будет понижен.
Конечно, во время эскалаций необходимо чаще повышать приоритеты; данное действие требует оперативности и, возможно, других корректировок в работе над запросом, но снизить приоритет можно как обычно.
Главное в эскалации – чтобы было привлечено внимание и побуждено к действиям по устранению причины эскалации и наведению порядка.
Рассмотрение эскалации также часто действует как арбитраж по проекту, если инициатор и исполнитель не могут прийти к согласию.
Инициатор иногда хочет странного, а иногда и невозможного.
И здесь мы постепенно подходим к вопросу, а зачем вообще нужны эскалации? С инициатором более-менее понятно.
Это возможность для инициатора запроса выразить свое недовольство и несогласие, а также разрешить любую нештатную ситуацию.
Это хорошо согласуется с интуитивным пониманием слова «эскалация», позволяющим использовать эскалации, в том числе рядовым пользователям ИТ-систем; они вполне грамотно и своевременно могут воспользоваться эскалацией, даже не читая никаких регламентов и инструкций.
Но зачем исполнителю нужна эскалация? И нужно ли это? Исполнители часто этого не понимают, а потому не любят эскалации.
Но тщетно.
На первый взгляд кажется, что ситуация асимметрична.
Для инициатора это возможность стучать кулаком по столу и устроить дебош, а исполнителю почему-то приходится вскакивать и на это реагировать.
Причём быстро прыгайте и адекватно реагируйте.
Есть ли у него еще какие-нибудь дела? Посмотрим, что произойдет, если не будет эскалации.
Если у инициатора есть причина для недовольства, то он будет ждать, ждать, ждать, пока его терпение не иссякнет. И тут у нас скандал, ругань, кишечная кровь жалобы на все, что можно вспомнить до третьего поколения, причастность начальства, стрессы, нервы и прочие производственные ужасы.
И если при этом действительно есть повод для недовольства, и были ошибки в прошлом (как чаще всего бывает, потому что никто не идеален), то этого мало никому не покажется.
К тому же, во время таких разборок становится очень сложно вернуться к конструктивному действию по самому запросу.
Инициатор не готов сотрудничать, не хочет идти на компромисс или от чего-либо отказываться, решение требуется прямо сейчас и в лучшем виде, на блюдечке.
А проблема обычно нетривиальная, ради тривиальных я бы не стал ставить высокие баллы.
Разрешать подобные скандалы непросто.
Теперь рассмотрим, что будет в такой же ситуации, если будет отлаженный и отлаженный механизм эскалации.
Инициатор, вместо того, чтобы тянуть до последней минуты, будет эскалировать запрос, как только поймет, что что-то идет не так.
Будет изучена причина эскалации, рассмотрена ситуация и запланированы необходимые действия.
Работы станет не меньше, это факт, но она останется прежней, а взаимодействие останется конструктивным.
Если план нехороший, то, скорее всего, последует очередная эскалация, то есть ошибки неприятны, но не фатальны.
Шанс на улучшение будет максимальным.
И даже если инициатор по каким-либо причинам не применил эскалацию, то вместо всего ужаса из предыдущего пункта ситуация разрешится одним вопросом самому инициатору (а, возможно, и его руководителю): «почему не ты не нагнетаешь ситуациюЭ» Вот так и получается, что работающий механизм эскалации позволяет исполнителю гарантированно избежать претензий по поводу его работы.
Причём качественно и системно.
Повторю еще раз для лучшего запоминания и даже рамкой:
Работающий механизм эскалации позволяет подрядчику гарантированно избежать претензий по поводу его работы.Немного? При эскалации сами инициаторы указывают, на какие запросы подрядчику следует обратить особое внимание .
Причем заранее, пока оно не взорвалось, и именно в тот момент, когда они сами готовы конструктивно работать со своей стороны.
Сами.
Заранее.
Конструктивно.
Это как какой-то праздник.
Все еще недостаточно? Для руководителя проекта (подразделения, отдела, группы) участие в эскалациях дает понимание текущей ситуации по проекту и бесценную информацию для оценки работы подчиненных.
.
Именно в таких обстоятельствах наиболее ярко проявляется качество работы исполнителей.
И менеджер в курсе всех текущих потенциально конфликтных запросов.
Известен до того уровня, на котором он сам участвует в эскалациях.
Вот и получается, что на самом деле механизм эскалации нужен исполнителю едва ли не больше, чем инициатору.
На мой взгляд, ради этого стоит потерпеть с оперативным и качественным рассмотрением эскалаций.
Все еще не обостряется? Напрасно.
P.S. Изменил название статьи, чтобы было понятнее Теги: #sla #itil #ITSM #эскалация #на пальцах #ServiceDesk #Управление проектами
-
Трехцентровые Связи
19 Oct, 24 -
Рунет В Картинках. Новый Выпуск
19 Oct, 24
