Эскалированные заявки что такое
Эскалировать и эскалация проблемы — что это значит?
Каково значение слова «эскалировать»?
Данное понятие возникло в деловом общении со значением «восходить, наращивать, штурмовать» на основе латинского scala – лестница, английского escalate – нагнетать, обостряться.
Понятие используют в сферах юриспруденции, менеджмента, бизнес-технологий.
Глагол активно применяется в решении ситуаций, связанных с инцидентами, конфликтами, организационными проблемами.
Что значит эскалировать
Первоначально в широком употреблении было существительное «эскалация». Во время холодной войны часто использовали сочетание «эскалация конфликта».
Новостные ленты связывали это выражение с обострением военных ситуаций, наращиванием вооружений, усилением противоборства сторон.
Википедия, известная интернет-энциклопедия, трактует значение слова как «постепенное увеличение чего-либо». Известно, что эскалационный процесс приводит к усилению разнополюсных позиций.
Нагнетание ведет к невозможности сосуществования, рискам открытых столкновений с причинением вреда какому-либо участнику конфликта.
Жечь глаголом
Глагольные формы «эскалировать», «эскалироваться» появились сравнительно недавно.
Применение характерно для языковой среды в системе организации, управления.
Значение глагола в деловом общении обрело смысловые оттенки, связанные с движением наверх по линии развития, по иерархической лестнице. Важен контекст в употреблении слова для точной передачи смысла.
Существует два смысловых оттенка слова «эскалировать»:
Например, отправка документов не в то ведомство означает, что ожидать ответа, заключения по рассмотрению дела, не имеет смысла.
Что такое «эскалация проблемы»
В западных компаниях согласно внутренним регламентам эскалирование (эскалация) к руководству – обычная практика.
Менеджеры младших звеньев в рамках процедур на основе серьезности появившихся затруднений транслируют, или эскалируют проблемы менеджерам высокого уровня.
В результате ожидается подключение дополнительных ресурсов и новых возможностей для достижения цели.
В структурах с отсутствием внутреннего организационного порядка исполнители зачастую пытаются самостоятельно справиться с возникшими затруднениями. Стремление сотрудника быть успешным во всем, не обращаться за поддержкой, приводит к проявлению некомпетентности и потере репутации всей компании.
Эскалировать правильно
Задача успешного менеджера своевременно и грамотно эскалировать проблему.
Сбор сопутствующей информации, вариантов решения, демонстрация комплексных знаний – отражение высокой квалификации специалиста.
Заключение
Слово «эскалировать» вошло в речь вместе с регулированием процессов в работе персонала. Употребление глагола сигнализирует о том, что система управления качеством постепенно внедряется в жизнь предприятий и организаций.
Смотрите видео, в котором рассматривается эскалация конфликтов, характерная для российского бизнеса:
Что такое эскалация в управлении проектами и зачем она нужна?
Забавно, но довольно часто сталкиваюсь с вопросом «что такое эскалация» и «что значит эскалировать» несмотря на то, что это одно из самых базовых понятий как в управлении проектами, так и в менеджменте в целом. Поэтому этот пост (осторожно, спойлер!) будет полон достаточно банальных вещей об эскалации, если вы все об этом знаете – не открывайте. Я предупредила.
Итак, что такое эскалация? Википедия дает универсальное определение – это постепенное увеличение, усиление, расширение чего-либо (например, коррупции во власти, или эскалация войны); наращивание (вооружений и т. п.), распространение (конфликта и т. п.), обострение (положения и т. п.).
Красиво, но связать с управлением проектами сложно, а ведь все очень просто.
Эскалация – это «подъем наверх» конфликта или проблемы, которые вы не можете разрешить самостоятельно в рамках своей роли или своих полномочий.
В норме процесс выглядит так: участники проектной команды взаимодействуют друг с другом и в случае, если они не могут договориться между собой, или решить какую-то внешнюю проблему самостоятельно – они эскалируют вопрос на руководителя проекта. Если он может разрешить вопрос – он его разрешает, если нет – эскалирует выше.
Эскалация – это также один из основных инструментов, используемых в ходе управления рисками.
Мои правила эскалации:
Часто руководители проектов боятся самого слова «эскалация», почему-то считая, что в случае, если они вынесут проблему выше, они продемонстрируют свою некомпетентность, неумение управлять командой и проч. А зря, пока вы не генеральный директор – 100% влияния и власти у вас все равно не будет (да и в случае с генеральным директором тоже), а значит – ситуации, в которых понадобится эскалации, неизбежны. И лучше сделать это раньше, пока проекту не нанесен совсем уж большой урон.
Несмотря на все, сказанное выше, эскалация – это всего лишь один из множества инструментов для взаимодействия со стейкхолдерами проекта. Если вы хотите лучше работать со стейкхолдерами и уметь на них влиять – то посмотрите наш большой курс по управлению стейкхолдерами. Пакет шаблонов в подарок!
Правила эскалации для эффективного управления инцидентами
Наилучший сценарий при возникновении инцидента — когда дежурный инженер или SRE может устранить его быстро и без посторонней помощи.
Конечно, в реальной жизни так бывает не всегда. Иногда для устранения требуется большая команда, специальные знания или специалисты более высокой квалификации. Именно поэтому любой организации, в которой работает более двух технических специалистов, нужны план и правила эскалации инцидентов.
Что такое эскалация инцидента?
Эскалация инцидента — это то, что происходит, когда сотрудник не может устранить инцидент самостоятельно и должен передать это задание более опытному сотруднику или профильному специалисту.
Что такое правило эскалации?
Правила эскалации отвечают на вопрос о том, как организация обрабатывает такую передачу. В них указывается, кого необходимо уведомить при поступлении оповещения об инциденте, кому следует эскалировать инцидент, если первый исполнитель недоступен, кто должен взять на себя решение проблемы, если исполнитель не может решить ее самостоятельно, и как должна происходить передача (через службу поддержки? Напрямую от одного технического специалиста к другому? Через инструмент управления инцидентами?).
На первый взгляд эти вопросы кажутся простыми, но чем крупнее организация и сложнее технологическая экосистема, тем более подробными должны быть ответы. Например, ответ на вопрос о том, кого необходимо уведомить при поступлении оповещения об инциденте, может зависеть не только от того, кто из сотрудников находится на дежурстве и доступен, но и от уровня опасности инцидента, его продолжительности и т. д.
В некоторых компаниях можно сначала уведомлять одного дежурного, независимо от уровня опасности инцидента. В других компаниях имеет смысл оповестить об инциденте с уровнем опасности 3 младшего разработчика, а об инциденте с уровнем опасности 1 — более старшего по должности или специальную команду.
Аналогичным образом, в некоторых компаниях за эскалацию инцидента в случае необходимости может отвечать первый исполнитель. В других компаниях может запускаться автоматическая эскалация следующему по должности разработчику или специальной команде, если инцидент длится дольше определенного времени или начинает влиять на большее количество систем или пользователей.
Правила эскалации должны описывать не только то, как и кому компания эскалирует инциденты, но и особенности, зависящие от типа инцидента, уровня опасности, продолжительности и масштаба инцидента.
Процессы эскалации инцидентов
У компаний, следующих рекомендациям ITSM, в центре эскалации инцидентов обычно находится служба поддержки. Если первый исполнитель не может устранить инцидент, то возвращает его в службу поддержки, которая эскалирует проблему на соответствующую следующую линию защиты.
Другие компании, такие как Google, назначают ответственным за инциденты инженера SRE, который отвечает за все необходимые эскалации (а также приостанавливает выпуск новых версий, если инцидент вызывает превышение командой порогового значения для времени простоя, которое задано в SLA/SLO).
В третьих компаниях первым исполнителем может быть разработчик либо менеджер инцидентов, или же первых контактных лиц может быть несколько (особенно в случае оповещения об инциденте с высоким уровнем опасности), а эскалация может происходить через заранее определенные процессы внутри одной команды или между командами.
Независимо от того, проходит ли процесс эскалации через службу поддержки, выполняется инженером SRE или реализуется автоматически в системах отслеживания инцидентов, в правилах эскалации обычно используются маршруты трех типов.
Иерархическая эскалация
При иерархической эскалации инцидент передается команде или сотруднику в зависимости от их уровня квалификации или положения в организации.
Например, первый дежурный исполнитель может быть младшим разработчиком, недавно работающим в команде. Если в иерархической организации исполнитель не может решить проблему, он передает ее разработчику, более старшему по должности. Если этот разработчик также не может решить проблему, она снова передается более старшему разработчику по иерархии — и так до тех пор, пока проблема не будет решена.
Функциональная эскалация
При функциональной эскалации инцидент передается команде или сотруднику, лучше подготовленному для его устранения, с учетом его навыков или знания систем, а не должности.
Например, первым дежурным исполнителем может быть младший разработчик из команды, которая занимается серверной частью продукта X. Если он обнаружит, что основная проблема возникла из-за интеграции с продуктом Y, то может эскалировать инцидент другому младшему разработчику из команды по разработке продукта Y.
Автоматическая эскалация
Для команд, работающих с такими платформами, как Opsgenie, можно настроить правила, в соответствии с которыми система будет автоматически эскалировать инцидент, если основной дежурный не подтвердит или не закроет оповещение.
Команда может отдавать предпочтение тому или иному методу эскалации, но они не являются взаимоисключающими. Многие команды используют сочетание иерархической, функциональной и автоматической эскалации.
Матрица эскалации
Матрица эскалации — это документ или система, которые определяют, когда должна происходить эскалация и кто должен обрабатывать инциденты на каждом уровне эскалации.
Этот термин используется во многих отраслях. Отдел кадров может применять матрицу эскалации при решении внутренних проблем. Центры обработки вызовов могут использовать матрицу эскалации для решения проблем с обслуживанием клиентов. У команд ИТ и DevOps может быть несколько матриц, которые помогают инженерам понять, как и когда эскалировать инцидент.
Степень детализации матрицы во многом зависит от компании. Одни организации могут использовать простую иерархическую диаграмму, в соответствии с которой каждый разработчик при необходимости эскалирует инцидент сотруднику с более высоким уровнем квалификации. В других организациях могут применяться матрицы для конкретных ситуаций, которые определяют, к каким командам должны обращаться разработчики при различных типах инцидентов или различных уровнях опасности. Как и во многих других случаях, в управлении инцидентами не существует универсального ответа на вопрос о том, как разработать матрицу для организации.
Рекомендации по разработке правил эскалации
Рассматривайте правила эскалации как рекомендации, а не жесткий набор правил
Технологии развиваются, как и ваши команды. Компания Google предлагает следующее: если инженеры SRE считают, что конкретный случай требует другой стратегии эскалации, разрешите им использовать свое решение. Дело не в том, чтобы сформулировать жесткие правила, а в том, чтобы разработать рекомендации, применимые в большинстве ситуаций.
Регулярно проводите аудит графика дежурств
Есть ли пробелы в графике? Назначены ли на дежурство нужные сотрудники? Назначены ли на дежурство нужные сотрудники второй и третьей очереди? Ваши графики дежурств и правила эскалации должны работать как единый механизм, чтобы управление инцидентами было быстрым.
Установите продуманные пороговые значения для эскалации
Не все инциденты одинаково важны, а значит, не все инциденты могут и должны быть обработаны по одному и тому же правилу эскалации.
При незначительных инцидентах можно не оповещать дежурного инженера в нерабочее время. При серьезных инцидентах инженер, вероятно, понадобится независимо от времени суток. Если произошло несколько инцидентов, инженер должен определить, каким из них следует заняться в первую очередь и (или) нужно ли сразу эскалировать какой-либо инцидент другому инженеру.
Необходимо найти баланс между тем, чтобы обеспечить максимальное время безотказной работы систем, выполнить обещания SLA и достичь соглашений SLO, и тем, чтобы условия работы инженеров не приводили к выгоранию, перегруженности, недостатку сна и усталости от оповещений.
Установите четкие процессы эскалации
Должен ли разработчик, выполняющий эскалацию, обратиться к соответствующей команде или сотруднику напрямую или сделать это через службу технической поддержки? Нужно ли разработчику использовать определенную систему? Как будет отслеживаться эскалация? Что должен сделать первый исполнитель, чтобы гарантировать передачу инцидента следующему сотруднику?
Ваши правила должны давать четкие ответы на эти вопросы. Их необходимо довести до сведения всех дежурных разработчиков, чтобы эскалации проходили гладко и инциденты устранялись быстрее.
Составление графика дежурств с помощью Opsgenie
С помощью этого руководства вы научитесь настраивать график дежурств, использовать правила переадресации дежурств, настраивать оповещения о начале дежурства, а также изучите другие возможности Opsgenie.
Лучший подход к составлению графика дежурств
Эффективный график дежурств является ключом к поддержанию здоровой культуры. Изучите распространенные ошибки, типы графиков ротации и рекомендации по составлению графиков.
Что означает выражение: Эскалировано неверно?
Что означает выражение: Эскалировано неверно?
Ответы на вопрос:
Этот термин широко используют в западных компаниях в значении английского escalate: проще говорить «эскалировать», чем «рассказать о проблеме начальнику, пусть решит его на своем уровне».
То есть эскалировать по сути означает «закинуть на уровень выше, довести до тех, кто выше».
От слова escalator путем «обратного образования» был создан глагол escalate (`эскалировать’)
иноязычный лексика заимствованный газета
1. Беззубов А.Н. Введение в литературное редактирование: уч. пособие. СПб., 1997.
2. Кузьма А.Я., Неупокоева О.В., Фещенко Л.Г. Сборник упражнений по литературному редактированию: учебно-методич. пособие / под ред. Л.Г. Фещенко. СПб., 2003.
3. Майданова Л.М. Критика речи и литературное редактирование текстов СМИ: уч. пособие. 2-е изд., перераб. Екатеринбург, 2009.
4. Мучник Б.С. Основы стилистики и редактирования: уч. пособие. Ростов-на-Дону, 1997.
5. Накорякова К.М. Литературное редактирование: общая методика работы над текстом. Практикум. 3-е изд. М., 2002.
6. Накорякова К.М. Литературное редактирование: общая методика работы над текстом: уч. пособие. М., 2011.
7. Накорякова К.М. Литературное редактирование материалов массовой информации: уч. пособие. М., 1994.
8. Розенталь Д.Э. Справочник по русскому языку: правописание, произношение, литературное редактирование / Д.Э. Розенталь, Е.В. Джанджакова, Н.П. Кабанова. М. (любое изд.)
9. Сенкевич М.П. Культура радио- и телевизионной речи. М., 1997.
10. Сметанина С.И. Литературное редактирование для журналистов и специалистов по связям с общественностью. СПб., 2003.
11. Стилистика и литературное редактирование: практикум по курсу: уч. пособие / В.И. Максимов, Н.А. Фатеева, Е.В. Маркасова и др.; под ред. В.И. Максимова. М., 2004.
psilonsk
psilonskБлог об управлении проектами
Когда человек не может решить проблему на своем уровне управления, он передает ее на уровень выше. Это называется эскалацией.
Исполнитель эскалирует проблему менеджеру проекта или продукта. Или линейному руководителю.
Менеджер проекта эскалирует проблему спонсору или управляющему комитету. Или своему линейному руководителю. Или руководителю другого подразделения, если конфликт связан с работающим там сотрудником.
Если эскалация не помогает, подключают следующий уровень тех, кто принимает решения. И так до тех пор, пока проблема не решена.
Обычно передают административные, управленческие проблемы. Реже — технические.
Сотрудник другого подразделения профакапил срок, с менеджером не смогли договориться, вас сильно оскорбили, задача зависла, процессы ошибочны? Эскалируйте.
Чтобы эскалация работала, надо следовать нескольким простым правилам. Простым, но обязательным.
1. Эскалация — это инструмент управления. Прежде чем им пользоваться, надо убедиться, что на твоем уровне ты сделал все, что мог. И все, что должен был.
2. Эскалация — это инструмент управления. В плохом случае она как снежный ком: запустил и смотришь, как в процесс вовлекается все больше людей. К этому надо быть готовым, но лучше сначала проверить, правда ли пора эскалировать и надо ли.
3. Эскалация — это инструмент управления. Это не способ пожаловаться на кого-то и вылить на него ведро говна. Это способ решить проблему, когда все другие инструменты не работают. Этику, уважение к коллегам и здравый смысл никто не отменял. Обычно проще договориться. У вас в компании проще сразу эскалировать? Сочувствую.
4. Эскалация — это инструмент управления. Ей пользуются дозированно и последовательно. Не надо сразу бежать жаловаться к начальнику начальника вашего оппонента. За один раз — один шаг. А то наживете себе лишних недругов из тех, кого пропустили в своем порыве поиска истины. Оно вам надо?
5. Эскалация — это инструмент управления. Работает он с фактами, а не с домыслами. Желательно — с письменными фактами. Тогда вам тоже станет понятно: есть документированная проблема или чьи-то действия всего лишь не соответствуют вашим ожиданиям. Или, может, вам кто-то персонально не нравится? Это не повод для эскалации.
6. Эскалация — это инструмент управления. Ее не надо бояться. Менеджер не выглядит слабым, если эскалирует проблему. Он выглядит слабым, когда проблема неожиданно для всех всплывает, а о ней никто не знал.
7. Эскалация — это инструмент управления. Им надо уметь пользоваться. Чтобы уметь — надо учиться. И чтобы во время обучения люди не пострадали.