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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Консалтинг
по управлению ИТ

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

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

Портал самообслуживания как катализатор позитивных изменений

Одна из частых проблем ИТ-поддержки заключается в высоком влиянии человеческого фактора при низком уровне зрелости ИТ-процессов. Рассмотрим практический случай. Я опишу в виде кейса опыт решения данной задачи, который был получен ещё до начала работы в Cleverics. Я считаю его удачным и применимым в других компаниях, поэтому хочу поделиться. Статья написана для того, чтобы продемонстрировать как создание портала самообслуживания может стимулировать позитивные изменения в работе внутреннего ИТ-подразделения компании. Ситуация и текущая проблематика до создания портала Несколько слов о компании: крупная промышленная компания географически распределенные подразделения количество пользователей — более 3000 внутреннее ИТ-подразделение с низким уровнем зрелости ИТ-процессов. Ситуация с первой линией:...

Контроль обработки инцидентов

В редакцию портала поступил вопрос: Хотел бы задать вопрос в студию о наболевшем. Ситуация следующая: рабочие группы обрабатывают заявки только через Таски (рабочие задания), ничего другого они не видят, хотя практическая возможность из Таска заглянуть в Инцидент или ЗнО\ЗнИ присутствует. Заказчику мы естественно «продаём» Инциденты и Запросы. Сейчас мне настойчиво «предлагают» отойти от схемы указания в Инц\ЗнО\ЗнИ группы поддержки (поле Группа назначения), потому как может быть несколько одновременно выполняемых Тасков (или ещё пор каким то причинам) да и сами группы работают только с Тасками. Т.е. увидеть в списке\перечне Инцидентов (например) кто сейчас за него отвечает возможности не будет и это...

Как управлять значительными инцидентами и нарушениями безопасности

Своими мыслями на этот счёт поделился Стюарт Рэнс, эксперт в области управления ИТ-услугами. Большинство инцидентов, с которыми имеет дело ИТ, относительно незначительны. Они могут быть важны для пользователей, которых затронули, но в большинстве случаев не представляют реальной угрозы для бизнеса. Команды технической поддержки, с которыми мне доводилось работать, в основном достаточно эффективно устраняют такие инциденты. Они в состоянии довольно быстро определить, что необходимо сделать, и отлично взаимодействуют с затронутыми пользователями. А поскольку таких инцидентов происходит довольно много, они учатся на собственном опыте. Они понимают, что инциденты являются источником информации для планирования мер по совершенствованию, и ведут проактивную работу по выявлению, приоритезации и...

Сочетание Cynefin и Swarming для лучшего управления инцидентами

Cynefin – интригующий фреймворк, он базируется на теории сложности и принципе, согласно которому разные ситуации требуют существенно разных подходов. Его создатель, Дейв Сноуден (Dave Snowden), кратко описывает это как «осознать сложность, чтобы действовать». Сноуден создал фреймворк в 1999 году, когда работал в IBM, а в 2003 опубликовал широко известную статью «Комплексные акты познания». Он оставил IBM в 2005 году, чтобы основать Cognitive Edge. Cynefin привлекает значительное внимание DevOps-сообщества. Модель также вызывает интерес у ITSM-профессионалов, особенно с учетом грядущей эволюции (или замены) привычных фреймворков, таких как ITIL. Этот всеобщий интерес к Cynefin напоминает аналогичную заинтересованность в Swarming, философии, которая отвергает привычные...

Управление инцидентами в бизнес-процессах компании

В редакцию портала поступил вопрос: Коллеги, всех приветствую. Хотел поднять тему внедрения управления услугами на уровне предприятия (Enterprise Service Management). На тему натолкнула статья Стюарта Рейнса Incident Management Isn’t Just For IT (оригинал optimalservicemanagement...isnt-just-for-it, перевод habrahabr.ru/post/347488/). Кому-нибудь приходилось участвовать в таком преобразовании процессов? С какими трудностями сталкивались? Известны случаи, когда инициатором таких проектов был именно ИТ и ИТ оставалось рулить процессами? На сколько успешно это было?

Service Desk 2018

Довольно часто для молодых ИТ-специалистов, входом в мир информационных технологий служит Service Desk. Сложившийся стереотип о простоте работы на позиции специалиста первой линии поддержки, а также низкого авторитета подразделения в целом, до сих пор ощущается при разговорах с собеседниками. Предлагаю немного разобраться в этом вопросе. Из ITIL® v3 2011 следует, что Service Desk — это функциональное подразделение, состоящее из специального персонала, отвечающего за различные виды обслуживания. Словарь терминов ITIL® на русском языке в редакции от 29 июля 2011 года трактует: Служба поддержки пользователей (Служба Service Desk) – единая точка контакта между поставщиком услуг и пользователями. Типичная служба поддержки пользователей управляет инцидентами, запросами...

Правильная последовательность внедрения 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-менеджемент, который решает проблему, так ли это? В моем понимании инцидент-менеджер безусловно является инициатором проблем, но далее он передает это на уровень проблем-менеджмента, и в его зоне остается лишь окончательная проверка и подтверждение устранения проблемы.

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM