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

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

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

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

itSMF Russia 2012: “Линейки и градусники”: доклад Максима Зубахи

12 и 13 сентября в Москве пройдет третья всероссийская (и даже международная) конференция независимого форума по управлению ИТ-услугами itSMF Russia. Мы начинаем серию анонсов секции "Линейки и градусники", модератором которой, по сложившейся традиции, выступит заслуженный автор портала realitsm.ru Дмитрий Исайченко. Одним из главных докладчиков станет Максим Зубаха, Заместитель Директора ДИТ в банке "Санкт-Петербург". Максим расскажет о том, как метрики процессов ITSM применяются для решения насущных задач любого управленца. Речь пойдет о мотивации персонала, оценке результатов ИТ-подразделения и способах контроля и влияния на партнеров-контрагентов поставщика ИТ-услуг. Конечно же, тезисы доклада будут подкреплены реальными примерами из рабочей практики докладчика. Мы приглашаем всех…

Линейки и градусники

12 и 13 сентября в Москве пройдёт III-я Всероссийская конференция itSMF-Russia. Одна из тематических секций называется «Линейки и градусники», её модератором выступит Дмитрий Исайченко. Без лишнего пафоса, без надувания щёк и пространных разговоров о вечном (стратегии, сервисах, сервисной стратегии, стратегических сервисах и проч.) там будут обсуждаться вполне серьёзные и актуальные для большинства ИТ-руководителей вопросы измерения процессов и ИТ-услуг. Например, можно ли измерить пользу от реализации тех или иных процессов ITSM? каким образом система метрик может использоваться для контроля и стимулирования персонала? как эта система метрик развивается по мере появления новых управленческих задач? как планируются и применяются числовые показатели качества ИТ-услуг?…

Мировая статистика процессов INC, PRB и CHG

Компания Pink Elephant продолжает проект по сбору статистических данных о реальных значениях процессных метрик. Напомним, что ITIL рекомендует сравнивать организации, чтобы устранить имеющиеся недостатки в способностях по управлению процессами. Принять участие в опросе может любая компания, а результаты периодически публикуются в блоге  Pink Elephant. Сегодня появились обновлённые на июль 2012 года данные по процессам управления инцидентами, проблемами и изменениями. В опросе принимали участие организации из разных стран, различного размера и из разных отраслей. Некоторые выдержки из отчёта: На количество инцидентов в организации больше всего влияют (в порядке убывания значимости): размер организации, количество внутренних и внешних пользователей ИТ, длительность существования формального процесса управления инцидентами….

Недоступная доступность

На прошлой неделе, во время курса «Основы ITIL V3», мы разговорились со слушателями про доступность ИТ-услуг. Спор завязался вокруг тех сервисных инцидентов, в которых, в самом широком смысле, «виноват пользователь». Если конкретнее: считать ли ИТ-услугу недоступной, если пользователь просто не знает, как ею правильно воспользоваться? Ответ коллег был следующим. Услуга конечно же доступна, ведь у нас есть процессная модель управления, мы отлично взаимодействуем между собой, и все ИТ-компоненты работают слаженно. Нам за это платит заказчик. Он же платит своим сотрудникам, чтобы те делали свою работу используя компьютеры, а, следовательно, это он обязан их обучить всем аспектам рабочего процесса, и в…

Service Desk: ловушка переоценки

Около четырех месяцев назад Олег писал о том, как Service Desk всех спасает и выручает. Я тогда усомнился в том, что именно служба поддержки – главное достижение ITSM, и сейчас неожиданно наткнулся на любопытное рассуждение, высказанное Аале Роосом на схожую тему в группе Back2ITSM. Аале предлагает такую метафору (привожу с незначительными сокращениями): Предположим, вы приехали в другой город и поселились в гостинице. Все идет хорошо, вы входите в свой номер, садитесь на кровать – и тут она ломается и падает. Вы звоните администрации, тут же приходит мастер, чинит кровать, приносит вам извинения и бутылочку шампанского. Вас просят оценить его работу,…

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

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

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

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

Опросы: три в одном, ничего лишнего

Наш финский друг Aale Roos – не только ITSM-консультант и тренер, автор ITSMPortal.com и активный участник движения Back2ITSM. Будучи статистиком по образованию, он также помогает своим заказчикам создавать, проводить и анализировать опросы – пользователей, сотрудников ИТ-служб и вообще людей. Для этого он придумал подход, который назвал The 3 Question Survey Method. Как вы понимаете из названия, отличительной особенностью подхода является то, что в большинстве случаев опрос сводится к трем вопросам.  Три – потому что три измерения дают больше информации, чем одно или два, и в то же время большинству из нас непросто представить объект исследования, существующий в четырёх и более измерениях. …

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

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

Готовые метрики Управления Изменениями от Pink Elephant

Компания Pink Elephant ведёт занимательный проект – сбор статистических данных о реальных значениях процессных метрик. Принять участие в опросе может любая компания, а результаты периодически публикуются в блоге компании. Сегодня появились обновлённые данные по процессу управления изменениями.

“Шум” KPI

Немногим ранее Дима опубликовал свои мысли по поводу измерения Incident Management’а и придумал интересную метрику (https://realitsm.ru/2011/12/measuring-incident-management/). Как уже говорилось, выросла она не на пустом месте, а в результате реальной потребности заказчика – в организации задумались о системе оценки персонала ИТ. Показатель по нарушению сроков инцидентов должен был войти в эту систему, и заказчика очень не устраивало то, что фактически ответственность за нарушение срока падала на последнюю рабочую группу, которая участвовала в обработке инцидента. А так как показатели должны были влиять на зарплату сотрудников, то можете себе представить, с какой аккуратностью подходили к созданию метрик. Наличие в системе одного такого «несправедливого»…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;