Измерение и оценка ИТ Archives – Страница 19 из 24

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

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

Роман Журавлёв, 26 марта 2012, последний комментарий 28 марта 2012

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

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

Вопрос из зала, 21 марта 2012, последний комментарий 13 марта 2018

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

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

Дмитрий Исайченко, 7 марта 2012, последний комментарий 14 марта 2012

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

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

Роман Журавлёв, 1 марта 2012, последний комментарий 1 марта 2012

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

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

Дмитрий Исайченко, 6 февраля 2012, последний комментарий 7 марта 2012

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

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

Новостной поток, 25 января 2012, последний комментарий 9 февраля 2021

“Шум” KPI

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

Михаил Тобурдановский, 23 января 2012, последний комментарий 2 февраля 2012

В защиту электронной почты

Компания Volkswagen объявила об изменении режима работы корпоративной почты: внутренние письма не будут приходить на Blackberry сотрудников в нерабочее время. Правда, только в Германии и только для членов профсоюза.Крупнейшая ИТ-компания Франции, ATOS, планирует полностью отказаться от внутренней электронной почты с 2014 года. Компания Henkel сообщила о том, что в период с Рождества до Нового года электронная почта будет использоваться во внутренней переписке только для экстренных случаев. Все это стало частью одной публикации BBC, хотя мне кажется, что эти три новости суть проявления очень разных тенденций. ATOS планирует использовать корпоративные социальные сети для внутренних коммуникаций. Мне кажется, что это отчасти дань…

Роман Журавлёв, 25 декабря 2011, последний комментарий 10 января 2012

Как сделать любое совещание бесконечным и бессмысленным

Несколько вредных советов из собственного опыта: Не готовьте повестку. Это позволит обсуждать множество вопросов, не имеющих отношения к заявленной теме. Времени уйдёт масса, зато все хорошо поговорят о наболевшем. Не назначайте докладчиков. Гораздо интереснее все вопросы обсуждать всем вместе – наверняка каждому найдётся что сказать. Особенно удобно, когда говорят одновременно несколько человек, это повышает активность и не даёт заснуть. Не принимайте решения. Намного дольше можно обсуждать способы, варианты, механизмы и нюансы; например, в ходе еженедельной оперативки можно спроектировать два-три процесса управления, ведь состав участников позволяет ставить себе такие амбициозные задачи, а совещание всё равно станет многочасовым. Чаще уходите в детали….

Олег Скрынник, 23 декабря 2011, последний комментарий 23 декабря 2011

На самом деле нет никакой ложки?

Некоторое время назад я предлагал обсудить различные аспекты оценки и измерения ИТ-процессов. Спасибо всем, кто высказался в обсуждении! Чуть позже я включил более-менее структурированное описание каждого направления оценки в свою колонку на itsmportal.com, посвящённую той же теме. В обсуждение колонки вступил Ян ван Бон, у которого, как обычно, нашлась в запасе пара слов. И вот она,эта пара слов: "Most important: there is no such thing as process maturity. Only organizations or functions of organizations can have a 'maturity'." Что в переводе на русский означает: "Не бывает у процессов зрелости. Зрелость бывает только одна – зрелость организации, в крайнем случае – какой-нибудь её функции."…

Роман Журавлёв, 20 декабря 2011, последний комментарий 27 ноября 2012

Измеряем Incident management

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

Дмитрий Исайченко, 17 декабря 2011, последний комментарий 27 декабря 2011

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

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

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