Про самый знаменитый процесс управления ИТ-услугами
На очередном курсе у крупного системного интегратора, слушатели смогли найти в ITIL V3 очередное противоречие. Их находкой хочу поделиться. Итак: два понятия.
Владимир спрашивает: И снова о проблемах… в продолжении последнего семинара Евгения Шилова. Утрировано рассмотрим ситуацию с ошибкой в книге ITILv3 2007. В Книге в двух местах дано разное определение термина проблема. Из-за этого на экзаменах люди допускают ошибки и не набирают соответствующий бал. Проблемой в данном случае является ошибка в книге. Инцидентом низкий бал на экзамене. Решением инцидента является апелляция, результатов экзамена. Обходным решением проблемы является исключение из экзамена вопросов связанных с ошибкой. Структурным решением является переиздание книг. Вопросы: Может ли проблем менеджмент предложить в качестве обходного решение каждый раз писать апелляцию (допустим раньше инцидент решался просто повторной сдачей экзамена…
Марина спрашивает: Подскажите, пжл, нужно ли разделять оперативное решение инцидента и полное решение инцидента? например: не формируется автоматически отчет (перестал работать функционал некой системы Х). например, пользователь может вручную создавать этот отчет (оперативное решение=обходной вариант), а исправление кода в системе Х (например, отчет не формируется из-за ошибки в коде) это уже полное решение инцидента? не смешиваются ли здесь понятия — решение проблемы?
Ситуация: 1. Очень большая доля обращений (порядка 60%) относится к вопросам, касающихся функционирования специфических ИТ-систем. 2. Компетенции первой линии точно не хватит, чтобы решить хотя бы малую часть из таких обращений. И даже не решить, а грамотно пообщаться с заявителем. 3. Порядка 70% обращений поступает через портал и e-mail, остальное – по телефону. 4. Очень небольшое количество человек на первой линии, и нет возможности добавить персонал (в том числе и за счёт организации распределённой первой линии со специализацией сотрудников). 5. Пользователи «натренированы» не звонить, а обращаться через портал или e-mail, более-менее грамотно описывать симптомы и прикладывать скриншоты . Решение: Позволить пользователям…
При организации процессов управления консультанты (как и все разумные люди ) пытаются следовать рекомендациям хороших практик. Но реальность очень часто отличается от того, о чем пишут в умных книгах. Так и в этот раз – жизнь состроила нам очередную «козью морду». В текущем проекте мы вдруг поняли, что на роль менеджера процесса управления проблемами подходящих кандидатов нет. Вернее, есть, но этот человек играет роль менеджера процесса управления инцидентами. И без него инцидентам будет плохо. Совмещение этих двух ролей не рекомендуется, и понятно почему. Однако, несмотря на все мои опасения, мы были вынуждены пойти на этот шаг. Менеджер двух процессов…
Сергей задаёт вопрос: Хотелось бы обсудить следующую задачу: Пусть мы имеем систему, которую используют 20 предприятий, общее количество пользователей 500, пусть на одном из предприятий 40 пользователей. Пусть система обслуживается с 9 до 18, время реакции 1 час, время закрытия типовой заявки на обслуживание 4 часа. Вопросы: 1 какой инфориации не хватает, чтобы можно было рассчитать количество единиц службы поддержки (КЕСП) 2. Как изменится КЕСП если указанное предприятие попросит уменьшить время реакции до 0,5 часа И общий вопрос — используются ли в практике управления услугами методы теории массового обслуживания? Спасибо.
В блоге Sunview's ITSM Lens Джефф Вейман опубликовал 10 причин неэффективности Help Desk в одной из двух главных его метрик – скорости решения заявок. Этот список главным образом описывает инструменты, которые мы можем контролировать, чтобы сэкономить как можно больше времени. Во многих случаях это приведёт к ускорению процессов, или, как минимум, ликвидации лишних телодвижений "сковывающих" работу. Многие инструменты будут успешно реализованы в гибком и легко настраиваемом ITSM-решении. Автоматизация обработки заявок применяется мало или не применяется вообще. Отчётность сложно составлять и модифицировать База данных известных ошибок не входит в состав ITSM-системы и используется редко SLA не используются в работе Help Desk, и…
Итак, задача. Есть две 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») нужна вторая метрика – результативности. О ней и поговорим в этой заметке. Традиционно одна из метрик управления инцидентами была посвящена контролю возвратов на доработку и рассчитывалась по формуле «доля инцидентов, возвращённых на доработку, от общего количества инцидентов, решённых за период». В чём недостатки такой метрики? Их (как минимум) два: её трудно связать с группой специалистов. В самом деле, после возврата на доработку инцидент фактически мог быть решён другой группой –…