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

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

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

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

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

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

Как ускорить решение инцидентов на 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-инцидентах как можно быстрее достигла первой линии поддержки. Эта информация должна включать в себя:     описание инцидента (что и когда произошло, когда ожидается решение) чтобы первая линия имела ответы на…

Запросы на обслуживание – кто кого обслуживает?

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

Реальные примеры описаний процессов: управление инцидентами

Мы подготовили еще один список документов, находящихся в открытом доступе, и полезных для самостоятельной организации процессов. Ранее мы уже говорили о процессах управления изменениями, управления уровнем услуг. На этот раз речь о процессе управления инцидентами. Многие организации уже не первый год имеют дело с этим процессом, поэтому вдвойне интересно посмотреть "а как другие решают проблемы, с которыми столкнулись мы". Возможно, вы найдете интересные для себя решения в приведенных ниже документах.  Описание процесса управления инцидентами Harvard University. Интересный экземпляр, с документе проработаны не только процедурные вопросы, но и политики, CSF, KPI.   Описание процесса управления major инцидентами Harvard University. Не менее любопытный документ,…

Кто такие VIP-ы и как их поддерживать?

Канадский эксперт и ITSM-консультант Райан Оджильви в своем блоге обсуждает вопрос VIP-поддержки и пытается понять, а нужно ли вообще выделять VIP-пользователей, как это делать и как же для них организовывать поддержку. Первое, на что обращает внимание Райан, это то, по какому принципу мы набираем людей в категорию VIP: Выбор может быть очень субъективным. Вполне возможно, что вы считаете VIP-ами всех сотрудников, начиная с какой-то определенной должности. Но всегда ли их запросы важнее, чем у других сотрудников, выполняющих ежедневные задачи бинеса. В некоторых случаях вы можете столкнуться с руководителем высшего звена, который скорее желал бы увидеть особый акцент сотрудников ИТ на влияющих…

ITSM. Руководство по измерению

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

Давка в очереди – как быть?

Виталий задал вопрос на нашей странице в Facebook: Посоветуйте, пожалуйста, как поступить? Есть несколько трудоемких заявок которые поступили практически в один момент (например, установка операционной системы или что-то похожее). У них у всех крайний срок в соответствии с SLA определен в течение 8 рабочих часов. Ситуация такова, что даже задействовав весь персонал, мы не укладываемся в крайний срок как минимум у нескольких заявок. Как должна быть организована работа в таком случае? Товарищи-практики управления инцидентами, поделитесь опытом решения подобных коллизий?

Инциденты и проблемы – два названия для трех объектов?

Роб Ингланд, известный так же как  IT Skeptic, завел в своем блоге интересную дискуссию . По его мнению, дебаты вокруг определений инцидента и проблемы никогда не закончатся, потому что их уже много лет подпитывает фундаментальный вопрос: у нас есть два процесса, которые пытаются выполнить три работы. Когда услуга нарушена, говорит Роб, мы имеем дело с тремя задачами в поддерже: 1) Общение с пользователями, с группами и персонально. Помогаем им, применяя обходные решения, чтобы вернуть возможность работать. 2) Восстановление услуги в нормальный режим работы. Иногда для этого нам может потребоваться только перезагрузка.. или перекомпиляция …или восстановление из архива. 3) Устранение причины сбоя. Это может быть неисправность, ошибка, неудачный патч, неправильная конфигурация, дезинформация, отсутствие обучения ……

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;