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

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

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

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

Совмещение ролей

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

Вопрос из зала: Количество единиц службы поддержки

Сергей задаёт вопрос: Хотелось бы обсудить следующую задачу: Пусть мы имеем систему, которую используют 20 предприятий, общее количество пользователей 500, пусть на одном из предприятий 40 пользователей. Пусть система обслуживается с 9 до 18, время реакции 1 час, время закрытия типовой заявки на обслуживание 4 часа. Вопросы: 1 какой инфориации не хватает, чтобы можно было рассчитать количество единиц службы поддержки (КЕСП) 2. Как изменится КЕСП если указанное предприятие попросит уменьшить время реакции до 0,5 часа И общий вопрос — используются ли в практике управления услугами методы теории массового обслуживания? Спасибо.

Почему Help Desk долго решает заявки?

В блоге Sunview's ITSM Lens Джефф Вейман опубликовал 10 причин неэффективности Help Desk в одной из двух главных его метрик – скорости решения заявок. Этот список главным образом описывает инструменты, которые мы можем контролировать, чтобы сэкономить как можно больше времени. Во многих случаях это приведёт к ускорению процессов, или, как минимум, ликвидации лишних телодвижений "сковывающих" работу. Многие инструменты будут успешно реализованы в гибком и легко настраиваемом ITSM-решении. Автоматизация обработки заявок применяется мало или не применяется вообще. Отчётность сложно составлять и модифицировать База данных известных ошибок не входит в состав ITSM-системы и используется редко SLA не используются в работе Help Desk, и…

Процессная математика. Tension-метрики

Итак, задача. Есть две tension-метрики, из них необходимо сделать один общий KPI, который показывал бы, насколько удаётся исполнителю обеспечить баланс. Для примера возьмём предложенные метрики процесса управления инцидентами по своевременности (https://realitsm.ru/2011/12/measuring-incident-management) и результативности (https://realitsm.ru/2012/02/measuring-incident-management-2). О каком балансе речь? Можно иметь неплохие показатели своевременности, если сразу перекидывать входящие обращения на смежников (а там жизнь покажет, можно в фоне поразбираться, вдруг и правда вопрос к нам). Однако в этом случае обращения будут возвращаться и требовать повторной обработки. Можно, напротив, разбираться «от и до», не передавать обращения (не отмечать выполнение), пока не будет 100%-ной уверенности в том, что найдено лучшее решение и оно…

ИТ-поддержка топ-менеджеров – как правильно?

Самая обсуждаемая ITSM-статья последних дней: гостевая публикация Симона Морриса на портале itsmreview.com.  Симон рассуждает на важную для многих тему: как правильно организовать поддержку пользователей категории VIP? Существуют два совершенно разных взгляда на вопрос: Пуританский. Обслуживание важных персон на экстремально высоком уровне возможно только за счёт снижения качества предоставления услуг кому-то другому (иначе говоря, всем остальным пользователям). Поэтому допускать "VIP-сервиса" не следует. Прагматичный. Нам приходится отчитываться по уровню предоставления услуг перед бизнесом. Даже если по отчётам всё выглядит неплохо, недовольный топ-менеджер может поставить ИТ-службе неудовлетворительную оценку, на основании только личного негативного опыта. А может быть и наоборот: довольный тем, как обслужили его…

Безопасное управление инцидентами

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

Измеряем Incident Management. Часть 2

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

Измеряем Incident management

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

Разработка и эксплуатация

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

Service Desk снова всех спасает и выручает

В прошлую пятницу проводил игру Apollo-13. Как обычно, было интересно: это был корпоратив, поэтому все участники – из одной компании, однако никакого единства в команде не было. Если я правильно понимаю, в ходе реорганизации объединились несколько подразделений, плюс добавилось много "новичков", чему не очень рады "старички". Но сейчас не об этом… Традиционно в ходе игры делаешь множество наблюдений. В этот раз хочу поделиться вот каким: даже в условиях, скажем так, неэффективной ИТ-организации, первая линия может "вытянуть" качество предоставляемых ИТ-услуг и не уронить субъективную оценку пользователей об этом качестве. Пример: представим себе первую линию поддержки из двух с половиной человек (два…

Посчитаем срок решения инцидента?

Поступил очередной интересный вопрос от постоянного читателя. По согласованию с ним, мы выносим ситуацию на публичное обсуждение: Внедряем ServiceDesk в своей организации с 400+ пользователями, учитывая рекомендации ITILv3 Очереди не используются, в связи с малым количеством пользователей и сотрудников СТП (3 человека на тех поддержке), кроме этого есть программисты и аналитики в самом отделе. Количество инцидентов=100/месяц Столкнулся с показателями, не понятно, что считать за время решения инцидента в некоторых ситуациях: 1. Пользователь запросил для некой автоматизированной системы ввести некую "фичу". После анализа выяснилось что требуется доработка ПО, что займет 2 недели. Запрос передан программисту, который выполнил данный запрос. 2. Пользователь…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;