Портал №1 по управлению цифровыми
и информационными технологиями

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

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

Про самый знаменитый процесс управления ИТ-услугами

Правильная последовательность внедрения ITSM-процессов

В редакцию портала поступил вопрос: Добрый день, коллеги! Наша компания находится на этапе внедрения процессов ITSM. В качестве первоочередных к внедрению процессов остановились на 6: управление обращениями, управление инцидентами, управление запросами на обслуживание, управление изменениями, управление конфигурациями, управление проблемами. Возник спор: в какой последовательности внедрять процессы. Я считаю, что правильнее было бы сперва смоделировать и описать регламенты всех шести процессов, а уже после этого формировать требования для разработчиков системы автоматизации, автоматизировать и обучать персонал новым правилам работы, т.к. часть изменений в системе автоматизации по одному процессу затронет и другие. Коллеги придерживаются мнения, что внедрять каждый из процессов нужно последовательно. Подскажите, есть…

“Здесь играем, здесь не играем …”

Для оценки качества работы первой линии часто используются такие метрики как: «Доля обращений, решённых на первой линии (First Line Resolution – FLR)» и «Доля обращений, решённых в течение первого контакта (First Contact Resolution – FCR)». Причина их появления довольно очевидна – стремление увеличить количество обращений, разрешаемых на первой линии. В свою очередь, это должно привести к снижению стоимости обработки обращений за счёт использования более дешёвых ресурсов первой линии и повышению удовлетворённости пользователей за счёт сокращения времени обработки обращений (нет эскалации – нет потерь времени на реакцию). Применение этих метрик выглядит оправданным и легко реализуемым. В большинстве случаев расчёт предлагается производить по…

Поддержка искусственным интеллектом

В технической поддержке классификация запросов пользователей является важным этапом их обработки. От выбранной классификации, как правило, зависит маршрут и временные нормативы обработки запроса. Ошибки в классификации негативно сказываются на своевременности решения: во-первых, из-за потерь времени при переназначении запросов, во-вторых, из-за изменения временных нормативов при корректировке классификации. Однако корректная классификация в компаниях с большим входным потоком запросов и развитым классификатором – непростая задача, особенно если на входе у специалиста, выполняющего классификацию, вопрос пользователя в произвольной текстовой форме. В практике Cleverics в последние годы эта задача в основном решается внедрением сервисных порталов. Структурирование каталога запросов в максимально удобном для пользователя виде позволяет…

Провокация: есть мнение, что управлять инцидентами скоро будет не нужно!

Если следовать заметке The End of Incident Management (as we know it!) Дага Теддера (Doug Tedder), в обозримом будущем управлять инцидентами будут роботы, впрочем, как полагает редколлегия, и писать заметки на портале RealITSM. Как вы думаете, как скоро такое может произойти, и что же будут делать люди? Итак, можете ли вы представить себе ITSM без процесса управления инцидентами? По мнению автора заметки, при всей своей важности, управление инцидентами – один из наименее эффективных процессов в ITSM. Успех или неудача здесь зачастую зависят от человеческого фактора. От того, как клиент воспринимает конкретную проблему. От его настроения. От того, как прошло общение…

Границы ответственности инцидент-менеджера

В редакцию портала поступил вопрос: Добрый день всем! У меня с нашим проблем-менеджером возник спор, кто же все-таки должен контролировать решение ИТ-проблем? Он утверждает, что инцидент-менеджер, он же инициатор проблемы, должен вести непрерывный контроль за решением проблемы, при необходимости "пинать" инженеров или change-менеджемент, который решает проблему, так ли это? В моем понимании инцидент-менеджер безусловно является инициатором проблем, но далее он передает это на уровень проблем-менеджмента, и в его зоне остается лишь окончательная проверка и подтверждение устранения проблемы.

Книга “RealITSM: проверено временем” поступила в продажу

Купить книгу "RealITSM: проверено временем" теперь можно: в бумажном виде в книжном магазине itSMF; в электронном виде на сайте Cleverics. Как уже упоминалось, эта книга является сборником самых популярных и ярких авторских заметок, вышедших на портале RealITSM за шесть лет. Поэтому у неё сразу 12 профессиональных авторов. Инвентаризацию заботливо разложенных на пути к эффективному управлению ИТ грабель для вас провели: Агент реального ITSM в центре развития ITIL® 9 ITIL Expert 9 аккредитованных тренеров EXIN а также ITIL Practitioner, DevOps Master, Certified Information Systems Auditor (CISA) и обладатели целого ряда других регалий, на перечисление которых одной заметки не хватит. Благодаря такому количеству авторов читать книгу,…

Вопрос из зала: что делать с переклассификацией инцидентов

  В редакцию портала поступил вопрос: При решении инцидентов иногда возникают ситуации, когда зафиксированное ранее для инцидента влияние требуется изменить. Логичным в этом случае кажется и изменение срока решения инцидента. Хотел бы услышать мнения экспертов по поводу следующего способа изменения срока решения инцидента при изменении его (зафиксированного) влияния. Для упрощения возьмем следующую модельную ситуацию. Срок решения инцидента определяется его влиянием. Шкала влияния состоит из двух значение: 1 — за один час инцидента с таким влиянием бизнес теряет 1$ 2 — за один час инцидента с таким влиянием бизнес теряет 2$ Сроки решения инцидентов: 1 час — для инцидентов с влиянием 1 30 минут —…

Вопрос из зала: KPI и своевременность обработки инцидента

В редакцию портала поступил вопрос: Помогите разобраться с ситуацией просчета показателя KPI как своевременность обработки и поиску доли вины по просроченным инцидентам. На вашем ресурсе я уже изучил статью, но остался ряд вопросов. Представим ситуацию, когда был просрочен инцидент, и в процессе решения было несколько смен услуг и несколько смен групп ТП. SLA по услуге = OLA(Время 1ЛТП)+OLA(Гр ТП в зависимости от выбранной услуги). Допустим, инцидент по первоначальной услуге надо было решить в срок 10 дней. 1ая Гр ТП была занята или просто приступила к решению на 5ый день. В итоге было установлено, что услуга выбрана не та и проблема…

Что главное в управлении инцидентами

Joe the IT Guy, рассуждая на этой неделе в статье «Управление инцидентами – основы по-прежнему имеют значение» о том, как всё изменилось с момента зарождения ITSM, утверждает, что, несмотря на DevOps и прочие новые веяния, основы по–прежнему важны. Инциденты были, есть и будут. И с ними нужно работать. Или, как пишет Joe: «Управлению инцидентами – да! Потому, что инциденты по-прежнему происходят». Пытаясь сформулировать ключевые моменты в этом процессе, автор формулирует несколько утверждений, которые, возможно, помогут кому-то взглянуть на процесс  по-новому. По мнению эксперта, основа процесса заключена в двух вещах: Работать со сбоем только один раз Возможность задавать вопросы, не имея…

Нужен ли процесс “Управление запросами на обслуживание” процессу “Управление инцидентами”?

За последнее время несколько раз на курсах по ITIL(с) обсуждался вопрос использования процесса управления запросами на обслуживание (Request Fulfillment Management [RFF]) для решения задач, лежащих в области интересов других процессов из процессной модели ITIL. Последнее обсуждение было вчера (Да. В корпоративном формате мы проводим тренинги и в выходные). В качестве примера подобного обсуждения вопрос: «В каком процессе должен отрабатывать запрос на получение информации об инциденте, находящемся в работе (например, о текущем статусе инцидента)? В процессе «Управление инцидентами» [Incident Management , INC] или в RFF?» Сначала зафиксируем очевидное. Во-первых, источником информации (в т.ч. о текущем статусе) является, конечно же INC, поскольку…

Инциденты, требующие доработок ПО

Кажется, что процесс управления инцидентами – одна их немногих глав ITSM, в которой с точки зрения теории, да и практики не осталось пробелов. Было приятно удивиться, что некоторые вопросы организации столь знакомого процесса не имеют у меня готовых ответов. Может быть, они найдутся у тех, кто читает эти строки. Итак, процесс обеспечивает своевременность решения инцидентов. Инциденты регистрируются, решаются, закрываются. Не успели вовремя – просрочка и штраф группе поддержки, задержавшей решение (иногда всем группам пропорционально вкладу). Справедливо? Безусловно. Но что если инцидент не может быть устранен силами ИТ-подразделения и требует доработки ПО на стороне подрядчика? Книжный ответ простой: ИТ-подразделение несет ответственность и…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;