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

ITSM. Руководство по измерению

Каждый год мы с друзьями вместо похода в баню выпускаем книжки по управлению ИТ. Некоторые – смешные, некоторые – серьёзные. Некоторые мы пишем сами, некоторые – переводные. Но все – полезные (во всяком случае, мы очень стараемся).

Обложка книгиВ этом году книга будет серьёзной, и написали мы её сами. Она называется «ITSM. Руководство по измерению» и, как следует из названия, посвящена вопросам измерения процессов ITSM, а также оценки деятельности специалистов, подразделений и руководителей, вовлечённых в исполнение этих процессов.

В книге три главы. В первой мы обсуждаем базовые понятия и методику формирования структурированной системы оценки, основанной на измерении. Во второй, применяя данную методику, разрабатываем примеры метрик по наиболее часто встречающимся на практике процессам – управления инцидентами и запросами, проблемами, конфигурациями, изменениями, уровнем ИТ-услуг. Причём, в отличие от ряда других публикаций, мы не стремились перечислить как можно больше примеров. Напротив – мы преследовали цель, используя ограниченный набор метрик (5-10 штук на один процесс), сформировать целостную систему показателей, которая может быть использована руководителем для оценки и принятия решений. В третьей главе мы приводим примеры построения на основе процессных метрик панелей оперативного мониторинга (dashboards) и сбалансированных карт показателей – для контроля и оценки деятельности ИТ-организации.

В этой книге мы свели вместе, систематизировали и как можно более чётко изложили знания по измерению и оценке, которые активно копились в наших головах последние десять лет и особенно – в 2012-2014 годах. Книга основана на практике и написана для практиков. В том числе и поэтому она не просто содержит список метрик (используйте, как хотите), но обсуждает сложности, связанные с применением тех или иных метрик, их использование в качестве персональных KPI, некоторые технические вопросы, связанные с измерением.

Мы очень надеемся, что у нас получилось, и книга покажется вам интересной и полезной.

Сейчас книга находится на этапе вёрстки, в бумажном виде она пока не доступна. Но печать намечена на ноябрь, и книжный магазин itSMF уже открыл сбор предварительных заказов.

А если у вас есть вопросы к авторам, задавайте. Авторы здесь, и им не отвертеться от ответов 🙂

Комментариев: 22

  • Константин

    Скажите пожалуйста, будет ли эта книга доступна в электронном виде?

    • Василий Поляков

      Присоединяюсь к вопросу коллеги.

  • Константин, Василий, если бы мы писали и издавали книги про Гарри Поттера (для широкой аудитории читателей), мы бы обязательно это сделали. Но речь идёт об узкопрофессиональной литературе, которая представляет интерес для крайне ограниченного круга читалелей. Распространять такие книги в электронном формате нерационально – скорость утечки контента многократно возрастает, а целевая аудитория практически не расширяется. Поэтому у нас нет таких планов.

  • Andrey Prozorov

    А на рецензию книгу прислать можете? После прочтения опубликую обзор в своем блоге 80na20.blogspot.com 

    Аудитория блога: ИБ/ИТ специалисты, 1500-2000 просмотров в день. Много статьей про cobit5 и пр.

    • На бумаге можем. Бумажная копия должна появиться во второй половине ноября.

      • Andrey Prozorov

        Отлично! С нетерпением жду, метрики – тема интересная, дискуссионная

  • Юрий Николаевич

    Уважаеый Дмитрий!

    Поясните, пожалуйста, оценку и значение коэфф.продуктивности процесса управления проблемами: PPI. Если правильно понял,то отношение суммы новых и решенных проблем( N+C) к сумме открытых/нерешенных и решенных проблем (O+C) за период. Например, (1) N=20,C=80,O=20 =>PPI=1 и (2) N=80,C=20,O=80 => PPI=1. В 1 случае разрешено 80 проблем из 100, а во 2-ом только 20, но продуктивность одинакова?

    • В 1 случае разрешено 80 проблем из 100, а во 2-ом только 20, но продуктивность одинакова?

      Всё верно, кроме финального вопроса. Если внимательно посмотреть на Ваши примеры, то будет ясно, что в обоих случаях было решено 100% проблем, открытых на начало периода. Все проблемы, оставшиеся открытыми на конец периода – зарегистрированы в этом периоде. То есть в обоих случаях активно выполняется как решение, так и регистрация проблем. Поэтому PPI и равен 1. В обоих случаях. Что Вас смущает?

  • Юрий Николаевич

    Уважаемый Дмитрий!

    Возможно, все дело в дефинициях (как я их понимаю): N- кол-во новых, зарегистрированных, но нерешенных проблем; О- кол-во "старых" нерешенных проблем, а С- кол-во решенных проблем. За рассматриваемый период в (1) решено 80 проблем, осталось "старых" нерешенных 20 и добавилось новых нерешенных 20. Во (2) решено 20 проблем, осталось "старых" нерешенных проблем 80 и добавилось новых нерешенных проблем 80. Явно, случай (2) описывает худшую ситуацию, как по рещению (из "начальных" 100 проблем решено только 20), так и по динамике (добавилось новых проблем 80, что возможно характеризует не только решение и ПУП), а продуктивность в обоих случаях оценивается 1, что трактуется как одинаково успешное функционирование процесса управления проблемами (ПУП)?

     

     

    • Возможно, все дело в дефинициях

      Вот давайте с ними и разберемся. Согласно определению N – количество новых проблем, то есть зарегистрированных в отчётном периоде, но не решенных к его окончанию, O – количество проблем, открытых на конец отчётного периода. Следовательно N <= O, причём N = O только в том случае, если все незакрытые проблемы – новые. Следовательно в обоих приведённых Вами примерах все ранее зарегистрированные проблемы решены. А значит, Ваши выводы не верны.

    • Добавлю.

      За рассматриваемый период в (1) решено 80 проблем, осталось "старых" нерешенных 20 и добавилось новых нерешенных 20.

      В этом случае, согласно определениям, C = 80, N = 20, O = 40. PPI = 83%.

       Во (2) решено 20 проблем, осталось "старых" нерешенных проблем 80 и добавилось новых нерешенных проблем 80.

      Здесь C = 20, N = 80, O = 160. PPI = 56%.

      Явно, случай (2) описывает худшую ситуацию

      Именно так и получается.

  • Юрий Николаевич

    Уважаемый Дмитрий!

    Следуя Вашим пояснениям, достаточно зарегистрировать нерешенные проблемы и, не решая их, получим оценку продуктивности 1. Например, исходно: N=C=O=0, конечное состояние: C=0 (ничего не решили), N=O=100 – поступило сто новых проблем, которые зарегистрировали и оставили на следующий период => (N+C)/(C+O) =1, но ничего не решили. Наоборот, исходное состояние такое же, поступило 100 проблем, которые решили, следовательно, N=0 (т.к. они закрыты к окончанию периода),О=0 (ничего не оставили) =>(N+C)/(C+O) =1. По оценке такая продуктивность (=1) равнозначна?

    • Строго говоря, Вы правы. НО повышение KPI методом регистрации проблем без их решения сработает ровно 1 раз. Вряд ли это перспективная стратегия поведения. И, поскольку у процесса управления проблемами внутренние триггеры, это малый (гораздо меньший) вред по сравнению с метриками, которые стимулируют замалчивать проблемы.

      Мне кажется, намного бОльшая проблема с PPI заключается не в числах, а в том, что эта метрика не умеет различать полезную работу по решению проблем от очковтирательства. В самом деле, нетрудно зарегистрировать простейшую проблему, возможно не оказывающую значимого влияния на качество услуг, и сразу её решить. Поэтому в книге явно сказано, что объективная оценка процесса управления проблемами только по метрике PPI невозможна – нужно сопоставление значений PPI с IR, нужен анализ того, какие именно проблемы были решены, какое влияние это оказывает на потребителей услуг. То есть нужен мозг менеджера.

      Крайние сценарии, которые Вы приводите в качестве контрпримеров, легко вскрываются мозгом менеджера. Даже не очень большим.

  • Юрий Николаевич

    Уважаемы Дмитрий!

    Спасибо за разъяснение и характеристику мозга, но строго говоря, оценка продуктивности =1 может повторятся не 1 раз, а периодически, через интервал (период), в котором все нерешенные проблемы закрыты (например, (1) N=O=1,C=0; (2) N=O=0,C=1; (1); (2) и т.д.). Варианты последовательности могут быть разные. Предложение использовать показатель IR более характеризует, как Вы пишете: "…много ли у вас в организации инцидентов", что очень косвенно позволяет характеризовать управление проблемами. По Вашей практике PPI действительно давал корректные оценки ПУП?

    • строго говоря, оценка продуктивности =1 может повторятся не 1 раз, а периодически, через интервал (период), в котором все нерешенные проблемы закрыты 

      Честно говоря, я не припомню таких случаев на практике. Как правило, какое-то количество известных ошибок висит всегда, если это правда живой процесс. Но если бы это и случилось, регистрация проблем, с моей точки зрения, действительно являлась бы свидетельством активности процесса (ведь выявление проблем – одна из его активностей).

      Повторюсь, избавиться от таких вопросов очень просто – достаточно убрать из формулы операнд N, приведя её к виду C/(O+C). Но тогда каждая вновь регистрируемая проблема будет снижать значение метрики, что для управления проблемами, учитывая тот факт, что его триггеры являются внутренними по отношению к объекту управления, вряд ли целесообразно. Мы потеряем больше, чем приобретём.

      По Вашей практике PPI действительно давал корректные оценки ПУП?

      Как оценка конвейера, да. Но повторюсь – PPI не используется как единственная характеристика, достаточная для оценки всего процесса. Она просто характеризует обновляемость множества проблем, находящихся в обработке.

      Юрий Николаевич, если определение PPI кажется Вам настолько спорным, поделитесь, пожалуйста, какие метрики для PRB используете Вы?

  • Юрий Николаевич

    Уважаемый Дмитрий!

    К сожалению, "серебрянной пули" у меня нет. "Зависшие" проблемы с решением вне компетенции, команды/процесса пытаемся исключить из учета и KPI, но это не всегда убеждает руководство. Из-за этого интерес к предложенным Вами оценкам, почти "линейным" функциям и др. публикациям. Возможно, Вам встречались оценки, учитывающие как количество систем, так и их сложность, т.к. решение проблем, управление конфигурациями, управление изменениями и т.д. не только в учете/регистрации, но в большей степени оценка среды "порождения и исправления", в свою очередь, оцененных не "горлом и перстом".  Пока слабый аргумент и защита в словах  Е.С.Венцель: "Из двух крайностей: «математика без здравого смысла» и «здравый смысл без математики» предпочтение, безусловно, надо отдать второй".

    • Пока слабый аргумент и защита в словах  Е.С.Вентцель…

      Слова хорошие, спасибо, в копилку.

      Но вообще мне кажется, что представленная в книжке математика всё-таки не лешена толики здравого смысла. Более того, когда я писал про мозг менеджера, я ведь писал ровно о том же – о необходимости применять здравый смысл к оценке (не допускать подмены оценки самими числами).

  • Прозоров Андрей

    Приветствую! Спасибо за книгу, прям читал и перечитывал. Очень много полезного.

    Написал обзор в своем блоге и сделал краткую презентацию с основными идеями – http://80na20.blogspot.ru/2015/01/blog-post_12.html&nbsp;

  • Сергей

    Зависшие" проблемы с решением вне компетенции, команды/процесса пытаемся исключить из учета и KPI

     

    • Сергей

      На мой взгляд это не верное решение, в конце концов такие проблемы все равно надо решать, например привелечением сторонних специалистов…Я например считаю выводить из учета и KPI такие проблемы не верно. Их надо избегать, и соответственно иметь ресурсы (или запланировать ресуры) на их решение.

  • Иван

    Подскажите пожалуйста, где можно купить твердую версию книг: “ITSM. Руководство по измерению” и “Управление услугами на основе измерений”

    • Иван, здравствуйте. Покупать обе книги нет смысла, поскольку “Управление услугами на основе измерений” вобрала в себя все, что было в книжке “ITSM. Руководство по измерению” и добавила много нового. Продажи твёрдой копии книги “Управление услугами на основе измерений” начнётся после новогодних праздников в книжном магазине itSMF (http://www.itsmforum.ru/reference/itshop/).


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM