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

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

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

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

Кто последний, тот и…

В редакцию портала поступил вопрос. Альберт, постоянный читатель и комментатор RealITSM, спрашивает: Коллеги, добрый день! Есть вопрос по определению ответственности по просрочкам в обращениях. Суть проблемы в следующем, в Service Desk настроено, что кто последний выполнил обращение, того и заявка в отчёте, но в случае же, если данное обращение просрочено, то просрочка также назначается на последнего исполнителя. На мой взгляд, это несправедливо, поскольку те сотрудники, по чьей вине обращение просрочено, избегают ответственности, передавая её на других исполнителей.  Поделитесь, пожалуйста, своими идеями по данному вопросу: кто как решает данный вопрос, какие есть алгоритмы определения ответственности по просроченным обращениям? Редакция портала знает, как…

Инциденты, проблемы и производительность

Наверняка вам встречалась ситуация, когда конечные пользователи недовольны производительностью приложения, а внутри ИТ происходит перекладывание ответственности за "тормоза". Ответственные за программное обеспечение обвиняют ответственных за оборудование и наоборот или говорят пользователю, что так и должно быть. В чем сложность данной ситуации? 1. Понятие "тормозит" весьма субъективно, для одного пользователя приемлемо подождать 5 минут, для другого – 1 минута ожидания, уже вечность. Операции тоже могут быть разными. Что делать: Зафиксировать, что есть нормальная производительность, то есть, что значит "не тормозит". При этом измерение должно производиться в терминах максимально понятных конечным пользователям, желательно, чтобы пользователи могли самостоятельно повторить операцию и оценить скорость ее выполнения….

Вопрос из зала: что делать с взаимосвязанными инцидентами?

Эльдар спрашивает у авторов и читателей нашего портала: Если пользователи начинают плодить заявки относящиеся к одной общей проблеме, будет ли правильным объединять их в одну?  Или же правильнее создание отдельной "главной" заявки и работать по ней, а по результатам закрывать заявки полученные от пользователей?  Поделитесь опытом, коллеги?

О пользе красивых порталов обслуживания

Театр начинается с вешалки. К.С. Станиславский   Ничто так не убеждает, как личный опыт. На днях мне в очередной раз довелось воспользоваться порталом гос. услуг. И вот мои впечатления. Портал мил. Структура его, в общем, понятна. Выбрать нужную услугу, пусть и не с первого раза, но вполне реально. После выбора услуги нас проведут через опрятную форму заполнения заявки, которая запросит все необходимые данные. Перед заполнением формы нам покажут краткое описание услуги (что-то типа внешней спецификации), которая сообщит нам, в чем заключается услуга и даже каковы нормативы на её предоставление (например, максимальное время в очереди в соответствующем учреждении). Правда, нормативов может…

Автоматическая функциональная эскалация?

Дальше действовать будем мы! Виктор Цой. В недавних обсуждениях с заказчиками опять всплыла тема автоматической функциональной эскалации заявки на следующие линии поддержки при окончании срока, отведённого на обработку на текущей линии. В нашей практике мы такое решение не использовали никогда. Попробую объяснить, почему: прежде всего, автоматическая функциональная эскалация возможно только в схеме с фиксированными маршрутами эскалации (иначе, пока не завершена диагностика на предыдущем шаге, просто неизвестно, куда эскалировать). А это само по себе нечастое явление; далее, если, например, специалист L2 работает с инцидентом, а он, тем временем, автоматически переназначен на L3, то как об этом узнает специалист L2 и бросит начатую…

Система определения приоритетов одной известной компании

В одной компании уже много лет действует такая система определения приоритетов неприятных событий (мы бы называли их инцидентами, наверное): Код Sev-5, самый низший, используется для относительно незначительных проблем, как правило технических. Такие проблемы можно и нужно решать в обычном рабочем порядке. То есть — не очень срочно, но сделать нужно. Код Sev-1, самый высший, присваивается срочным событиям, реакция на которые должна быть безотлагательной: запускаются все возможные системы оповещения ответственных сотрудников, приступить к устранению беды следует немедленно, о проблеме, её последствиях и героическом устранении будет доложено одному из топ-менеджеров компании, который не только выслушает, но и сделает орг.выводы и примет административные…

Отсутствие выделенных групп поддержки – каковы преимущества?

Многим нашим читателям знакома проблема взаимодействия команд разработки и эксплуатации. Зачастую, задача первых сводится к пропихиванию созданного решения в продуктивную среду, чтобы успеть к дедлайну проекта. Вторые, естественно, сопротивляются, поскольку им с "этим" жить, а "это", к сожалению, не полностью задокументировано, не оттестировано, не всегда совместимо с боевым окружением, не очень-то и производительно и т.д. Проблема решаема – командам эксплуатации нужно подключаться на этапе проектирования, где закладывать эксплуатационые требования, и в ходе разработки следить за претворением их в жизнь. А теперь представьте, что выделенной команды по эксплуатации/поддержке нет. Есть ли в этом смысл, и какие преимущества это может обеспечить? Своим опытом…

Как ускорить решение инцидентов на 40%?

Мы все время от времени сетуем на то, что, при всей своей разумности и логичности, ITSM страдает нехваткой числовых подтверждений пользы. Поэтому достижения, которые выражены в цифрах, всегда вызывают интерес. На днях один из наших заказчиков поделился с нами своим достижением: за полгода ему удалось сократить среднее время решения инцидентов на 40%. Достойный результат, не правда ли? Основа решения – организация такого способа обращения за техподдержкой, при котором существенно сокращается время на сбор информации по инциденту и на его маршрутизацию до нужной группы. Технически это было реализовано посредством некоторой программы, которая должна была постепенно вытеснить такие способы обращения в Service…

Как измерить портал самообслуживания

Директор по обучению и сертификации HDI, Rick Joslin в своей заметке «What is LZS?» рассказывал о метрике LZS (Инциденты, решаемые на 0 уровне – Level Zero Solvable), которая показывает долю инцидентов, решённых службой поддержки, которые могли бы быть решены пользователями самостоятельно с использованием портала самообслуживания. Предположим, вы запускаете такой портал. Известно, что если пользователи не могут решить свой вопрос с помощью портала самообслуживания, они вряд ли обратятся к нему снова. Метрика LZS помогает спрогнозировать эффективность портала самообслуживания с точки зрения пользователя, снизить риски неприятия и повысить вероятность повторного использования. После запуска портала, анализ инцидентов входящих в LZS, помогает выявлять возможности…

Вопрос из зала: KPI для параллельных работ

После выхода нашей книги "ITSM. Руководство по измерению", читатель Сергей, внимательно её изучающий, задаёт вопрос: Реализуем метрики согласно вашей замечательной книги Сейчас застопрорились на метрике TPI в рамках РГ (стр.39-42 книги формулы 8-10) Рассмотрим ситуацию в рамках выполнения обращения привлечены в рабочие группы. Они работают параллельно.  Пусть обращение хочу хорошую погоду (не придирайтесь — это пример) SLA (T) по обращению 8 часов 1 рабочая группа задача убрать снег 2 Рабочая  группа разогнать облака 1 Рабочая группа справилась в срок и все сделала за 2 часа 2 Рабочая группа справилась за 12 часов и нарушила срок Для РГ2 TPI = 0 А…

Checklist: 7 шагов по работе с major-инцидентами

Тема major-инцидентов уже поднималась на нашем портале, и неоднократно. Однако после недавней встречи с одним из заказчиков я решил вернуться к ней еще раз. Теперь в виде короткого чек-листа, который можно использовать для проверки дизайна и исполнения процессов управления инцидентами и непрерывностью. Итак: О возникновении major-инцидента в первую очередь, как правило, узнают профильные специалисты – сетевые инженеры, администраторы СУБД и прикладных систем. Нужно позаботиться о том, чтобы информация о major-инцидентах как можно быстрее достигла первой линии поддержки. Эта информация должна включать в себя:     описание инцидента (что и когда произошло, когда ожидается решение) чтобы первая линия имела ответы на…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM