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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Консалтинг
по управлению ИТ

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

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

Наши ИТ-метрики — не сбалансированы!

Troy DuMoulin из компании Pink Elephant напоминает в своем блоге о необходимости использовать сбалансированные показатели при оценке процессов. И заодно — о возможности применять для этого методику Balanced ScoreCard (BSC).  Трой предлагает любопытную иллюстрацию, наглядно показывающую, что бывает, когда мы концентрируемся на одной Самой Главной Метрике и игнорируем остальные:  "Представьте, что вы заглядываете в кабину пилота нанятого вами самолета и видите, что перед пилотом — только один прибор. Вы интересуетесь у него (у пилота, не у прибора): — А отчего это у вас всего один прибор? Что он показывает?— Скорость полета! В этом полете наша главная цель — скорость. — Здорово. Скорость —...

Еще один отраслевой отчет от HDI

Недавно мы обсуждали отчет Help Desk Institute о работе служб поддержки в финансовом секторе. Сегодня объектом анализа стали образовательные учреждения.  Некоторые наблюдения:  в отличие от финансовых учреждений и от общей тенденции основной объем увеличения числа обращений стал следствием расширения спектра поддерживаемых услуг Лишь 34% участников опроса сумели выполнить план по FCR (средний план — 69,5%, средний факт — 62,6%) Как и в остальных отраслях, здесь уверены, что для успешной работы надо много инструментов; доля счастливчиков, имеющих желанные инструменты, ниже, чем в среднем по все отраслям. В частности, существенно  реже внедрены средства мониторинга и средства управления знаниями

Измеряем зрелость процессов ITSM?

Forrester research group в начале ноября заявила о выпуске модели для оценки зрелости процессов ITSM. Что внутри, неизвестно: "This document is not available for individual purchase.Please contact a sales representative for more information". Снаружи — такие слова: Модель позволяет организациям оценить текущий уровень зрелости процессов ITSM и спланировать необходимые шаги для достижения требуемого уровня". 

Результаты или отчеты?

Для выполнения многих задач, преимущественно проектного характера, в организациях создаются временные команды, в которые входят сотрудники разных функциональных групп. Что производят эти команды — результаты или отчеты? Интересные рассуждения о том, почему на практике верным оказывается второй ответ, приводит в своем блоге Ron Ashkenas. 

Статистика работы Service Desk в финансовых организациях

Help Desk Institute ежегодно публикует отчеты о состоянии дел в отрасли, предоставляя компаниям ориентиры для сравнения. Теперь такие отчеты публикуются по отраслям, и первый отраслевой отчет посвящен финансовым организациям, на очереди — образовательные, торговые, аутсорсинговые, высокотехнологичные компании и учреждения здравоохранения.  Вот некоторые интересные данные о финансовых институтах: Лишь 46% центров поддержки в таких организациях выполняют требования по доле решений на первой линии; Подавляющее большинство (84%) организаций выбрали электронную почту в качестве основного канала обращения за поддержкой, однако почти треть участников признали, что до 70% инцидентов в итоге эскалируются с использованием телефона. При том что 39% респондентов признают полезность онлайн-чата как средства...

Градусник, спидометр или GPS-система?

Отличная дискуссия про правильные градусники, основной вопрос которой — можно ли доверять субъективным метрикам, навела меня на более общую мысль — а зачем вообще измерять? Что мы измеряем? Какие решения и кем принимаются на основе измерений? Как эти решения реализуются, и смотрим ли мы на результат изменений, на новые измерения? Да, в каждом проекте при внедрении какого-либо процесса мы традиционно доходим до раздела "KPI", который честно заполняем вместе с заказчиком. Но мне кажется, что то, что мы в этот раздел напишем, не столь уж важно (хотя знаю что Дима, например, придумывает просто чумовые метрики для самых сложных ситуаций; это ж физик-теоретик, не...

Бывают ли правильные градусники?

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

Управление конфигурациями — не вещь, а практика

  ИТ-скептик опубликовал небольшую заметку об управлении конфигурациями и роли CMDB в этом процессе. Для удобства обсуждения мы публикуем ее полный перевод.  ITIL определеяет управление конфигурациями как предоставление информации, но затем на множестве страниц описывает его как сопровождение статичного хранилища данных, а не как активную деятельность по предоставлению информации заинтересованным в ней получателям. Давайте все же договоримся: управление конфигурациями – это процесс, а не вещь. («Процесс» – в  том вульгарном понимании этого слова, в котором его использует ITIL. Если вы не согласны с ним, замените «процесс» на «практику» или «деятельность».) Совершенствование управления конфигурациями – это совершенствование предоставления информации другим практикам...

Управление мощностями, как оно есть

На днях опять вспомнилась тема управления мощностями. Столько всего понакручено вокруг нее. Решил немного про это порассуждать. Например, выяснилось, что иногда под управлением мощностями понимают мониторинг ИТ-ресурсов ("всякие железяки"). В лучшем случае, с определением пороговых значений и правил реагирования на их нарушение. И тут появляются вопросы и типичные ошибки: 1. Откуда взяться требованиям к мониторингу? 2. Откуда взяться пороговым значениям?3. Как реагировать? Что значит для нас превышение того или иного порога? Бывает, что на эти вопросы отвечают так (конечно утрирую): "собираем все важное, пороги поставили разумные, если жахнет, то разберемся". При таком подходе, есть риски: 1. За грудой данных не увидеть...

Для идеального решения не хватает совсем немножко

Из рекламного слогана одной крупной компании с названием из трёх букв, занимающейся курьерскими перевозками: "Предлагаем идеальное решение независимо от масштабов вашей компании". Я читаю так: "Нам без разницы большие вы или маленькие, платить будете одинаково." Чтобы предлагаемое решение было идеальным, этой компании нужно всего-то ничего: сделать адекватными свои тарифы и научиться нормально работать в России, с её своеобразной таможней. А до тех пор такая реклама только веселит, но не побуждает к заказу услуг. Поэтому постоянный контракт на курьерскую доставку у нас совсем с другой компанией.

Маркетинговая пыль в глаза

Узнал что появилось новое выражение — "Reality distortion field". Может, новое только для меня, т.к. я раньше его не встречал, хотя собственно явление заметил давно. — Включай "Поле Искажения Реальности" как только меня представят публике. — Наш продукт — просто кусок дерева, но тем не менее каждому нужно минимум три штуки! — О, я как раз такая творческая личность. — А у меня уже рука отнялась! Шутки шутками, но поле-то работает. Иначе как Apple может при доле рынка мобильных телефонов 2,8% в натуральном выражении получать 39% прибыли в денежном? Больше, чем Nokia, Samsung и LG, вместе взятые.

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM