Что такое матрица эскалации

Философия SLA: что такое эскалация и зачем она нужна

В своей статье «Как написать хороший SLA», я поминал, что в SLA просто просится внести процедуру эскалации. Хочу сказать пару слов за эскалацию.

Эскалацию в IT, по-моему, мало кто понимает. В ITIL она как-то мутно определена. Соответственно и дальше, при попытках её внедрить, градус мутности только возрастает. Ни Гугл, ни Яндекс не помогают найти ничего вразумительного. Вместо того, чтобы объяснить эскалацию просто и понятно (как это сделаю я), авторы начинают вводить какие-то новые термины, указывать в чём различие между функциональной и иерархческой эскалацией (зачем вообще это?), вещать что-то про автоматическую эскалацию, ничего не объясняя и уводя в сторону. И при этом из контекста можно предположить, что эскалация — это то ли синоним передачи запроса другому исполнителю, то ли в другое подразделение, то ли привлечение дополнительных ресурсов, то ли повышение приоритета. А иногда я просто теряюсь понять смысл. Всё это вызывает лично у меня ощущение или «кручу-верчу, обмануть хочу», или банальной некомпетенции.

Особенно мило (не могу удержаться и не привести этот пример) выглядит автоматическая «эскалация» запроса на другой уровень поддержки, если (sic!) текущий исполнитель не успевает в заданный в SLA срок. То есть будучи исполнителем, принимаем запрос и держимся изо всех сил, ничего по нему не делаем, пока он не будет вот-вот уже почти просроченным, и… бац! — срабатывает автоматическая «эскалация», которая переназначает запрос на кого-то другого. Профит. Главное держать себя в руках и ничего не делать. Можно было бы от души посмеяться, но кое-где именно такую схему «эскалаций» и применяют, выдавая за лучшие практики IT!

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

Сначала развенчаю вышенаписанное, почему это не является эскалацией.

Эскалация не является переназначением запроса. Хотя бы по той простой причине, что переназначение запроса на другого исполнителя называется «переназначением запроса на другого исполнителя». А не эскалацией. И вообще переназначать запрос, если исполнитель уже приступил к работе, категорически нельзя. Единственный правильный способ передачи запроса, который я знаю, это когда новый исполнитель забирает запрос себе сам добровольно, и только после предварительного согласия текущего исполнителя. Потому что взял (дали) запрос — решай до победного конца. Да и разгребать последствия «за того парня» после переназначения — то ещё удовольствие. Событие это скорее форс-мажорное, чем обыденное. Тем более никаких автоматических переназначений. Иначе исполнители будут от работы бегать.

Также эскалация не является повышением приоритета. Потому что даже у не владеющего ситуацией (но владеющего логикой) человека тут же возникает вопрос, а как тогда эскалировать запросы самого высокого приоритета? И, если у нас всего четыре приоритета цифрами от 1 до 4, то эскалировать можно максимум три раза, меняя приоритет с 4 на 3, с 3 на 2 и с 2 на 1 и всё, да? Выглядит подозрительно и нелогично. И потом, если нам по третьему приоритету исполнитель не отвечает из отпуска, то почему по второму вдруг начнёт?

А чем же тогда эскалация является? Определение:

Эскалация — это процедура привлечения внимания к отдельному запросу, когда ход работы над запросом чем-то не устраивает

Вот именно так, а не иначе. Привлечь внимание. Невооружённым глазом видна связь с повышением приоритета — внезапно повышенный приоритет, как и другие подобные несуразные действия, привлечёт к себе внимание, так что такое поведение отчасти смахивает на эскалацию. Но только в том случае, если исполнитель не ушёл в отпуск. Ну и не забываем, что на несуразные действия одной стороны, другая может отреагировать симметрично. На любой ваш вопрос, так сказать, произвольный наш ответ. Так что более правильно понимать эскалацию именно как привлечение внимания. А там уже компетентный человек разберётся, повышать ли приоритет, привлекать ли дополнительную экспертизу или просто придать исполнителю нужное ускорение, вплоть до полной смены его состава. То есть с предыдущими потугами определить эскалацию данное определение согласуется.

Но данное определение уже лучше, потому что оно позволяет эскалировать запросы столько раз, сколько нужно, невзирая на конечное число приоритетов и уровней поддержки.

Идём дальше. У каждой эскалации должен быть повод. Другими словами, что-то не так с запросом, почему-то понадобилось привлекать к нему внимание. Этот повод инициатор обязан указать при эскалации. Без повода эскалаций не бывает. Вот типичные примеры причин для эскалации:

Если причиной эскалации являются сроки, то надо эти сроки указать и внятно изложить, почему этот срок важен, и что случится, если срок будет нарушен.

Причиной для эскалации не является:

и другие тому подобные ничего не значащие фразы.

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

Причина эскалации обычно излагается не техническим языком, нужно изложить где и чем проблема мешает бизнесу. Это так называемая бизнес-причина. Согласитесь, что мелкая техническая проблема может на самом деле доставить много неприятностей бизнесу и наоборот. Сравните:

Первая причина будет понятна только узкому кругу технических специалистов (причём зачастую только после длительного анализа), вторая же говорит каждому, что весь бизнес уже встал, а скоро ещё и на деньги попадёт.

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

Что должно случиться после того, как кто-то эскалировал запрос. Нужно рассмотреть эскалацию. Должен появиться исполнитель запроса или кто-то более компетентный (особенно, если причиной эскалации являются действия самого исполнителя) и внятно отреагировать. Под «внятно отреагировать» вообще говоря понимается следующее: проанализировать текущую ситуацию с запросом в свете причины эскалации и предложить инициатору план дальнейших действий, который устроит обе стороны и устранит причину эскалации. Далее действовать по этому плану. Рассмотрение эскалации должно быть оперативным, неотвратимым и качественным. Тут нельзя халтурить.

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

И тут мы уже плавно так подбираемся к вопросу, а зачем вообще нужны эскалации?

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

А вот зачем нужна эскалация исполнителю? И нужна ли? Этого исполнители часто не понимают, и потому не любят эскалации. А зря.

На первый взгляд кажется, что ситуация несимметрична. Для инициатора это возможность постучать кулаком по столу, и поскандалить, а исполнитель зачем-то должен на это подпрыгивать и реагировать. Причём подпрыгивать быстро и реагировать адекватно. Заняться ему что ли больше нечем?

Давайте посмотрим, что будет если эскалаций не существует. Если у инициатора есть повод для недовольства, то он будет ждать, ждать, ждать, пока терпение не лопнет. И тогда у нас скандал, ругань, кровь кишки жалобы на всё что можно припомнить до третьего колена, привлечение начальства, стрессы, нервы и прочие производственные ужасы. И если при этом ещё повод для недовольства в самом деле имеется, да и в прошлом огрехи были (как чаще всего и бывает ибо nobody’s perfect), то мало не покажется никому. Кроме того, во время таких разборок, становится очень сложно вернуться к конструктивным действиям по самому запросу. Инициатор не готов сотрудничать, не желает идти на компромиссы и чем-либо поступаться, решение требуется прямо сейчас и в лучшем виде, на блюдечке с голубой каёмочкой. А проблема обычно нетривиальная, ради тривиальных хай бы не поднимался. Разруливать такие скандалы ой как непросто.

Теперь рассматриваем, что будет в той же ситуации, если имеется хорошо настроенный и чётко работающий механизм эскалаций. Инициатор, вместо того, чтобы терпеть до последнего, проведёт эскалацию запроса сразу, как только осознает, что его что-то идёт не так. Причина эскалации будет изучена, ситуация рассмотрена, необходимые действия запланированы. Работы меньше не станет, это факт, но она останется в штатном режиме, а взаимодействие останется конструктивным. Если план не будет хорош, то скорее всего последует ещё одна эскалация, то есть ошибки неприятны, но не смертельны. Шанс исправиться будет максимальный. И даже если инициатор по какой угодно причине не воспользовался эскалацией, то вместо всего ужаса из предыдущего абзаца ситуация будет разрулена одним вопросом к самому инициатору (и, возможно, его руководителю): «что ж ты не эскалировал?»

Вот так и получается, что работающий механизм эскалации позволяет исполнителю гарантированно избегать жалоб на свою работу. Причём качественно и системно. Повторю ещё раз для лучшего запоминания и даже возьму в рамочку:

Работающий механизм эскалации позволяет исполнителю гарантированно избегать жалоб на свою работу

Мало? При эскалации инициаторы сами показывают, на какие запросы следует обратить особое внимание исполнителю. Причём заранее, до того, как рвануло, и именно в тот момент, когда сами готовы конструктивно поработать со своей стороны. Сами. Заранее. Конструктивно. Прямо праздник какой-то.

Всё ещё мало? Руководителю проекта (подразделения, отдела, группы) участие в эскалациях даёт понимание текущей ситуации на проекте и бесценную информацию для оценки работы подчинённых. Именно в тех обстоятельствах, где качества работы исполнителей проявляются как раз ярче всего. И руководителю известны все текущие потенциально конфликтные запросы. Известны на том уровне, на котором он сам участвует в эскалациях.

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

Источник

Управление инцидентами и проблемами — понятия и принципы

Введение

Управление ИТ-услугами (ITSM) включает работу с инцидентами и проблемами. По мере возрастания роли ИТ в компании растет и потребность в обеспечении хорошего уровня сервиса, обеспечении максимальной доступности ИТ-услуг. Бизнес-пользователь должен иметь возможность получить решение своих проблем, если они возникают, как можно быстрее, и работать в любое время. Реализация процессов управления инцидентами и проблемами нацелена именно на это. В данной статье мы описываем, как может быть устроена работа ИТ-службы в рамках управления инцидентами и проблемами. Это описание основано на предложениях ITIL и опыте наших клиентов.

Язык инцидентов и проблем

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

Инциденты

Инцидент — есть любое событие, которое не является частью стандартных операций сервиса и вызывает, или может вызвать, прерывание обслуживания или снижение качества сервиса.

Примерами инцидентов являются:

Проблемы

Проблема — есть неизвестная причина одного или более инцидентов.Одна проблема может породить несколько инцидентов.

Ошибки

Известная ошибка — есть инцидент или проблема, для которой выявлена причина и разработано решение по ее обходу или устранению. Ошибки могут выявляться в результате анализа жалоб пользователей или анализа систем.

Примеры ошибок включают:

Соотношение понятий управления инцидентами и проблемами показано на рисунке 1. Инциденты, проблемы и известные ошибки связаны в своего рода жизненный цикл: инциденты часто являются индикаторами проблем ⇒ выявление причины проблемы определяет ошибку ⇒ ошибки затем систематически исправляются.

Система ИнфраМенеджер – мощная российская система управления инцидентами и проблемами

Управление инцидентами

Управление инцидентами — есть деятельность по восстановлению нормального обслуживания с минимальными задержками и влиянием на бизнес-операции, являющаяся реактивным, сфокусированным на краткосрочную перспективу сервисом восстановления.

Она включает в себя:

Управление проблемами

Управление проблемами — есть деятельность по минимизации воздействия на бизнес проблем, которые вызываются ошибками в ИТ-инфраструктуре, по предотвращению повторения инцидентов, связанных с такими ошибками. Управление проблемами выявляет причины проблем, идентифицирует решения по их обходу или устранению.

Управление проблемами включает:

Контроль проблем

Цель контроля проблем — найти причину проблемы, выполнив следующие шаги:

Контроль ошибок

Контроль ошибок обеспечивает исправление проблем за счет следующих действий:

Анализ проблем

Цель анализа проблем состоит в улучшении процессов управления инцидентами и управления проблемами. Что достигается изучением качества результатов деятельности по устранению основных проблем и инцидентов.

Организационные роли и распределение ответственности

Наиболее часто встречаемой структурой системы поддержки является многоуровневая модель, в которой все возрастающий уровень технических возможностей применяется для решения инцидента или проблемы. Фактические роли и распределение ответственности, используемые в многоуровневой реализации системы поддержки, могут быть различными в зависимости от персонала, истории и политики конкретной организации. Тем не менее, следующее описание многоуровневой системы поддержки типично для многих организаций.

Первый уровень поддержки

Организация (подразделение), представляющая первый уровень поддержки обычно относится к оперативным службам. Как правило, она называется диспетчерской службой, Call Center, Help Desk, Service Desk.

Роли. Владелец процесса

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

Первая линия поддержки

Организация первого уровня поддержки предпринимает первую попытку разрешить вопрос с обслуживанием, о котором сообщил конечный пользователь.

Обязанности

Точная регистрация инцидентов. Первый уровень поддержки гарантирует, что информация об инциденте вносится в журнал системы. Для этого должно быть:

Владение каждым инцидентом. Как адвокат конечного пользователя первый уровень поддержки обеспечивает успешное разрешение каждого инцидента. При этом гарантируется своевременное решение вопросов за счет:

Первый уровень поддержки использует базу данных управления проблемами для сопоставления инцидентов известным ошибкам и применения ранее найденных способов разрешения инцидентов. Цель заключается в разрешении 80 процентов инцидентов. Остальные инциденты передаются (эскалируются) на второй уровень.

Непрерывное улучшение процесса управления инцидентами. Как владелец данного процесса первый уровень поддержки гарантирует улучшение при необходимости процесса посредством:

Способности и навыки

Навыки межличностного общения первостепенны. Персонал первого уровня поддержки вовлечен главным образом в расстановку приоритетов и управление проблемами. На этом уровне поддержки проводятся лишь незначительные технические изыскания. Способность применять «консервированные» решения. Персонал первого уровня должен уметь распознавать симптомы, применять поисковые инструменты для обнаружения ранее разработанных решений и помогать конечным пользователям в применении таких решений.

Второй уровень поддержки

Этот уровень также обычно относится к оперативным службам.

Обязанности

Способности и навыки

Третий уровень поддержки

Этот уровень поддержки обычно относится к группе разработки приложений и сетевой инфраструктуры.

Обязанности

Способности и навыки

Процессы

Можно выделить три основных процесса, связанных с управлением инцидентами и управлением проблемами:

Эти основные процессы присутствуют практически во всех передовых организациях, хотя могут иметь и другие названия.

Процесс управления инцидентами

Данный процесс сфокусирован на скорейшем восстановлении прерванного сервиса. В таблице 1 приведены основные параметры этого процесса, а на рисунке 1 показана диаграмма его работы.

Таблица 1. Параметры процесса

Типичные числовые параметры

Рисунок 1. Модель процесса

Процесс контроля проблем

Процесс контроля проблем сфокусирован на расстановке приоритетов, выделении и мониторинге усилий на определении причин проблем, способов их временного или постоянного устранения. Этот процесс может быть уподоблен управлению портфелем проектов, где каждая проблема суть проект, который должен управляться в рамках портфеля таких же проектов. Основные параметры проекта контроля проблем приведены в таблице 2.

Таблица 2. Параметры процесса управления проблемами

Типичные числовые параметры

Вход в процесс может поступать из нескольких источников. Обычно инциденты высокого уровня серьезности автоматически передаются процессу контроля проблем. В организациях с крепким вторым уровнем поддержки инциденты, передаваемые на третий уровень поддержки, также в плановом порядке направляются процессу контроля проблем. И, наконец, ежедневное совещание может перенаправить те или иные инциденты процессы контроля проблем. Процесс, реализующий контроль проблем, показан на рисунке 2.

Рисунок 2. Модель процесса контроля проблем

Фокус процесса контроля проблем направлен на определение причин. Состав участников анализа причин и длительность времени, необходимого для выполнения такого анализа зависит от самой проблемы. Можно считать правильными следующие утверждения:

После того как ресурсы выделены и расставлены приоритеты, фактическая механика определения причины может принимать различные формы. Хорошо зарекомендовали себя такие методы поиска причин как Анализ Кепнера и Трего, диаграммы Ишикавы, диаграммы Парето и прочее.

Процесс контроля ошибок

Контроль ошибок обеспечивает документирование способов преодоления неисправностей и оповещения о них (способах) персонала поддержки. К нему же относится поддержание связи с другими техническими и разрабатывающими организациями, также способствующее выявлению ошибок. Более того, контроль ошибок влияет на разработчиков с целью реализации исправлений известных ошибок. В таблице 3 приведены основные параметры процесса контроля ошибок. На рисунке 3 изображена модель процесса контроля ошибок.

Таблица 3. Параметры процесса управления ошибками

Типичные числовые параметры

Рисунок 3. Модель процесса контроля ошибок

Взаимодействия

Как правило, взаимодействия в данном процессе принимают одну из двух форм. Это либо сообщения о статусе инцидента или проблемы, которые предоставляются различным группам и/или отдельным лицам на основе утвержденных правил и шаблонов, либо сообщения о запросах, которые требуют от получателя определенных действий, обычно содержащих кроме фактического запроса/требования еще ссылку на инцидент, номер телефона пользователя или иную ссылку на него.

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

Для исправления этих недостатков автоматические возможности коммуникации дополняются, особенно в случае инцидентов высокого уровня важности, сообщениями составленными вручную.

Эскалация

Механизм эскалации помогает своевременно решить инцидент путем увеличения возможностей персонала, уровня усилий и приоритета, нацеленных на решение этого инцидента. Лучшие организации имеют хорошо определенные пути эскалации с временными рамками и ответственности ясно определенными на каждом шаге. Они используют средства управления инцидентами для автоматической передачи ответственности на все возрастающий уровень поддержки в соответствии с временными рамками и сложностью.

Временные рамки и ответственность в рамках эскалации сильно отличаются в зависимости от организации, промышленности и уровня сложности проблем. В передовых организациях проводятся переговоры с конечными пользователями для определения подходящих временных рамок и эскалации ответственности. Результат таких переговоров реализуются в виде соглашений об уровне сервиса, автоматизированных средств, списков, шаблонов.

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

Функциональная эскалация есть передача инцидента на более высокий уровень поддержки, когда знаний или опыта недостаточно или истек согласованный интервал времени. В передовых организациях определяется матрица уровней важности, основанная на степени влияния на бизнес, временных рамках разрешения инцидента и интервалах времени, в которые инцидент должен быть передан в более продвинутую группу. Таблица 4. представляет собой такую матрицу.

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

Источник

• ← Что такое матрица электронной книги
• Что такое матрицы и как их решать примеры →