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

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

Измерение и оценка ИТ

Всё о метриках, KPI, CSF, а также об измерении услуг, процессов, технологий. И про CleverKPI.

Оценка эффективности сотрудника ИТ-службы

В редакцию портала поступил вопрос: Уважаемые коллеги! Вопрос следующего свойства: По книге "ITSM. Руководство по измерению" успешно внедряем индикаторы для процессов Inc mng и rf (Service request) mng, выбрали 2 индикатора TPI и TCR, как сбалансированные. Вопрос в следующем: Как однозначно оценить "эффективность сотрудника"? Т.к. если сотрудник 1 решил за месяц 200 обращений — у него TCR 0.78 и TPI 0.80, а второй решил 10 обращений и у него оба индикатора равны 1 (Идеальный). В описании измерений процессов не нашёл информации как сие реализовать, чтоб было честно с точки зрения сотрудника 1.  Свой вариант: Ввести "нормирование" количества обращений, выполненых за период, но данный вариант не предусматривает…

“Здесь играем, здесь не играем …”

Для оценки качества работы первой линии часто используются такие метрики как: «Доля обращений, решённых на первой линии (First Line Resolution – FLR)» и «Доля обращений, решённых в течение первого контакта (First Contact Resolution – FCR)». Причина их появления довольно очевидна – стремление увеличить количество обращений, разрешаемых на первой линии. В свою очередь, это должно привести к снижению стоимости обработки обращений за счёт использования более дешёвых ресурсов первой линии и повышению удовлетворённости пользователей за счёт сокращения времени обработки обращений (нет эскалации – нет потерь времени на реакцию). Применение этих метрик выглядит оправданным и легко реализуемым. В большинстве случаев расчёт предлагается производить по…

DevOps в динамике – 2. Метрики

Продолжение заметки "DevOps в динамике". Одни из ключевых вопросов, которые стоят перед теми, кто строит карту показателей процесса, системы менеджмента или любого другого объекта управления: как убедиться в необходимости и достаточности набора метрик? как получить набор метрик, который даст наиболее точное представление о состоянии объекта управления? Коллеги Дмитрий Исайченко и Роман Журавлев в книге «ITSM. Руководство по измерению» в части разработки процессных метрик предлагают следующий подход: Установить назначение процесса Разработать метрики соответствия назначению Установить ключевые практики Разработать метрики ключевых практик … Назначения процессов широко известны, поэтому шаги 1-2 обычно не вызывают трудностей – что должны показывать метрики понятно, вопрос только в выборе правильной…

Измерение ITSM-процессов в денежном эквиваленте

В редакцию портала поступил вопрос: Добрый день. Прочитал книгу «Руководство по измерению» — всё понравилось, всё по делу! Но тема раскрыта в разрезе измерения самих процессов и их производительности. Теперь хочется научится переводить все это в деньги.  Нужны ответы на вопросы: «Сколько стоит один инцидент / запрос на обслуживание?», «Сколько стоит блокирующий инцидент (сбой)?», «Сколько стоят этапы работы: классификация запроса, переназначение, заполнение параметров после выполнения», «Какова средняя стоимость 1 часа работы по запросу для 1- 2- 3-линии». Подобные знания позволят намного эффективнее выбирать доработки и изменения для реализации.  Например у нас есть типовой ЗнО, и есть идеи по автоматизации его решения. Разработка обойдется в N…

Зачем доступность услуг считать в процентах?

Последнее время я все больше укрепляюсь в давно блуждающей в моей голове и довольно еретической мысли: классический показатель доступности малопригоден для измерения и оценки доступности ИТ-услуг в реальном мире. И в ряде случаев от него можно легко отказаться. Эти случаи касаются в первую очередь измерения доступности услуг типа «ИТ-обеспечение бизнес-процессов» (фактически речь идет об ИТ-доступности бизнес-процессов). Попробую обосновать и буду рад услышать возражения. Полагаю, всем читателям портала знакома формула: Availability = (AST – DT)/AST, где AST – согласованное время предоставления услуги, DT – сумма простоев за период. А также, вероятно, знакомы сложности ее применения: Первая сложность связана с обсуждением показателя. Доступность…

“До весны не будить!” Скидка 30% на книги Cleverics

Праздники ушли, осыпавшись еловыми иголками и оставив нас один-на-один с работой и метелью. Но у нас в Cleverics есть для вас прекрасное предложение, как скоротать унылые рабочие будни долгие зимние вечера. Мы решили снизить стоимость всех книг Cleverics в электронном виде на 30%, кроме вышедшей в декабре книги "Real ITSM: проверено временем". Если прямо сейчас начать читать по одной книге в неделю, как раз хватит до весны! Итак, в нашем предложении участвуют: "Введение в реальный ITSM" от Роба Ингланда (IT Skeptic). Управление ИТ-услугами, как оно происходит в реальном мире. По отзывам читателей: "Читать, смеяться и плакать". "Овладевая ITIL", Роба Ингланд (IT Skeptic). Трезвый взгляд на…

Измерение ITSM-процессов: как избежать “футбола”?

В редакцию портала поступил вопрос: Коллеги! Доброго времени суток! На данный момент решили применить метрики из книги "ITSM. Руководство по измерению". Для процесса управления инцидентами и запросами на обслуживание были выбраны 2 ключевые метрики — TPI и TCR, как и рекомендует книга) Вроде бы всё "сбалансировано", но есть один вопрос. В первой метрике мы смотрим на "степень вины" группы в просрочке обработки и решения. Во второй – насколько эффективно мы решаем обращения в рамках группы. И собственно вопрос: что мешает специалистам групп заняться "футболом" обращения в рамках первой метрики? Т.е. группа передаёт обращения дальше, чтобы минимизировать свою вину в возможной…

Книга “RealITSM: проверено временем” поступила в продажу

Купить книгу "RealITSM: проверено временем" теперь можно: в бумажном виде в книжном магазине itSMF; в электронном виде на сайте Cleverics. Как уже упоминалось, эта книга является сборником самых популярных и ярких авторских заметок, вышедших на портале RealITSM за шесть лет. Поэтому у неё сразу 12 профессиональных авторов. Инвентаризацию заботливо разложенных на пути к эффективному управлению ИТ грабель для вас провели: Агент реального ITSM в центре развития ITIL® 9 ITIL Expert 9 аккредитованных тренеров EXIN а также ITIL Practitioner, DevOps Master, Certified Information Systems Auditor (CISA) и обладатели целого ряда других регалий, на перечисление которых одной заметки не хватит. Благодаря такому количеству авторов читать книгу,…

Вопрос из зала: KPI и своевременность обработки инцидента

В редакцию портала поступил вопрос: Помогите разобраться с ситуацией просчета показателя KPI как своевременность обработки и поиску доли вины по просроченным инцидентам. На вашем ресурсе я уже изучил статью, но остался ряд вопросов. Представим ситуацию, когда был просрочен инцидент, и в процессе решения было несколько смен услуг и несколько смен групп ТП. SLA по услуге = OLA(Время 1ЛТП)+OLA(Гр ТП в зависимости от выбранной услуги). Допустим, инцидент по первоначальной услуге надо было решить в срок 10 дней. 1ая Гр ТП была занята или просто приступила к решению на 5ый день. В итоге было установлено, что услуга выбрана не та и проблема…

Распределение ИТ-затрат по ЦФО

Предлагаю вашему вниманию и обсуждению реальную задачу, над которой мы сейчас трудимся. Для дальнейшего изложения нужно ввести несколько определений. Они больше понятийные, так что не судите строго, если они покажутся вам недостаточно полными. Центр финансовой ответственности, далее ЦФО — одно или несколько организационных подразделений компании, отвечающие за финансовые результаты своей деятельности. Не усложняя, разделим ЦФО на две группы: зарабатывающие (Profit Center) и затратные (Cost Center). Основная услуга, далее ОУ — ИТ-услуга, непосредственно оказываемая одному или нескольким бизнес-подразделениям (ЦФО). Например, поддержка информационной системы Х. Это просто пример, не будем здесь обсуждать подходы к структурированию каталога ОУ (от бизнес-процессов, от информационных систем…

Ключевые практики управления доступностью и непрерывностью

Последнее время меня занимает вопрос оценки процесса управления доступностью и непрерывностью ИТ-услуг. И если с измерением результативности процесса, на мой взгляд, все более или менее понятно – она определяется степенью достижения согласованных показателей доступности и непрерывности услуг[1], то с измерением ключевых практик не все однозначно. Собственно, вопросы есть уже к списку ключевых практик, которые необходимы для реализации назначения процесса. Здесь необходимо сделать оговорку, что я рассматриваю вариант ISO/IEC 20000, согласно которому управление доступностью и непрерывностью совмещены. Однако суть упражнения не поменяется и при разделении процессов. С оглядкой на ITIL и COBIT5 Enabling Processes получается следующий список ключевых практик: Планирование доступности и непрерывности…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;