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

Пауки для ИТ-руководителя

spider«Пауки», они же радарные диаграммы, весьма распространены в современном мире, в том числе в мире ИТ-менеджмента. Чаще всего ИТ-директор видит их в аудиторских заключениях, где они представляют сведения о зрелости процессов управления (обычно по шкале от 1 до 5). Иногда на этих диаграммах указывается не только текущий, но и целевой уровень зрелости процессов, что иллюстрирует величину разрывов между текущей и рекомендованной практикой управления. Однако, с моей точки зрения, такие диаграммы не являются основанием для принятия каких-либо решений и потому не несут заказчикам значимой ценности.

Идея, которая посетила нас относительно недавно, заключается в дополнении радара по уровню зрелости радаром по показателю результативности процессов. Подход к расчёту таких показателей по основным ITSM-процессам изложен в нашей книге (это некоторые наборы KPI плюс методика формирования сбалансированных карт показателей). Измерение результативности выполняется по шкале от 0 до 100%. К этой же шкале легко можно привести и показатели зрелости, а значит эти две оценки можно даже вывести на одном – общем радаре. Линия результативности показывает пользу процессов для организации, линия уровня зрелости характеризует уверенность в возможности получения этой пользы в текущих и изменяющихся условиях.

При этом упражнение gap-анализа приобретает новый смысл:

gaptable

Проводя аналогию с известной картинкой в книжках ITIL про то, что ценность услуг определяется совокупностью двух факторов – функциональностью (utility) и гарантией (warranty), можно говорить об анализе ценности процессов на основании двух факторов – результативности (аналог функциональности) и зрелости (аналог гарантии).

Как вам такая идея?

«VAP: Построение системы KPI для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

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

  • Юрий Ерин

    Приведение на диаграмме значений полезности и гарантии процессов – любопытная идея. Однако использование зрелости процесса как аналога гарантии, на мой взгляд, серьезный поворот в сознании :). Для развития идеи придется забыть про всякие кобит-памы, исы и др. 

  • Альберт

    Если только как частный случай для совсем простых процессов.

    • Почему? Разве результативность более сложных процессов невозможно оценить? Или для них это не требуется?

      • Альберт

        Результативность, да. А вот зрелость может быть неоднородной для сложных процессов.

  • Дмитрий

    Хорошая идея. Если развить дальше, то нужно придумать критерии результативности процессов и способ их оценки. При этом отличительной оценки будет то, что эти критерии нужно обсуждать строго с бизнесом и на языке бизнес-процессов, ни в коем случае не спрашивая ИТ.

    Прям даже вижу опросник, с короткими вопросами и ответами (бизнес-то читать не любит:), на подобие "какие аспекты работы ИТ критичны для Вашего бизнес-подразделения: скорость решения инцидентов, быстрая реализация изменений, стабильность качества оказания услуги.."

  • Justmag

    Дмитрий,
    видел такие диаграммы где надо и не надо
    знаю, что никто из руководителей их серьезно не рассматривает
    для практического применения, в чем предлагаете измерять зрелость и результативность ?

  • Justmag

    🙂

    относительно чего?

    • Зрелость относительно максимального уровня (т.е. 5). Результативность – подробно описано в нашей книжке (http://www.cleverics.ru/ru/subject-field/itsm-a-practical-guide-to-process-measurement). Не приобретая книгу можно познакомиться с идеями, послушав доклады с нашего мероприятия 25.11 (http://www.cleverics.ru/ru/subject-field/presentations/bookday-2014).

      • Justmag

        спасибо, интересное название, заинтересовало, прочту 
        однако, если шкала до 5, то причем тут % ?
        а пока у меня практический вопрос: какой из 2 процессов результативнее, если у них одинаковая оценка результативности (например, 4) и одинаковый уровнь зрелости (например, 5) ?

        • однако, если шкала до 5, то причем тут % ?

          На 5 можно поделить. И сразу получится процент 🙂

          какой из 2 процессов результативнее, если у них одинаковая оценка результативности (например, 4) и одинаковый уровнь зрелости (например, 5) ?

          Я бы сказал, что они одинаково результативны (пока игнорируя единицы измерения результативности). Но наверно Ваш вопрос с подвохом? Как у Пелевина про две совершенно разные песни, у которых одинаковы только мотив и слова.

          • justmag

            И да и нет…подвох подождет , сначала хочу разобраться 🙂

            т.е. мы имеем шкалу относительных единиц для каждого процесса по результативности и зрелости соответственно.

            Например, процессы Управление доступом и Управление изменениями имеют одинаковые значения результативности и зрелости.

            Как и со стандартными пауками, я думаю тут есть такая же логическая проблема.

            1. Сначала объясните мне, зачем данная методика зрелость-результативность? в каком случае ее предлагаете применять?

            2. Я согласен, с первым абзацем статьи, что " такие диаграммы не являются основанием для принятия каких-либо решений и потому не несут заказчикам значимой ценности". Золотые слова.

            2. Получив значения в %, т.е. поделив значения на 5, ничего по сути в пауках не поменяется. Так? Т.о., Зрелость как была бесполезной, так и осталась.

            3. Предполагаю, что измерение результативности будет не просто в %, а сначала в каких-то осмысленных единицах: метрах, рублях, тоннах, штуках, попугаях и т.п. И у каждого процесса набор таких измерений будет немного разный…

            Рассматривая %, Как руководитель поймет, какой из процессов критически важен (более ценный ?) для организации? а может процесс недооценен??

             

  • Владимир

    Идея хорошая. Книгу по KPI заказал 🙂

    Видел аудиторское заключение в пауках, где на одной шкале зрелость/удовлетворенность (как есть) и важность (как должно быть). Оценки выставляли Начальники подразделений. Соответственно, по пауку можно увидеть, где действительность наиболее приближена к идеалу, а где нужно ещё поработать. Понятно, что все оценки – субъективны. Но данные однородны.

    Результативность процесса (в %) – например, доступность ИТ-систем (в %): измеряем на основании процесса управления инцидентами и запросами пользователей. Тут с цифрами трудно спорить, есть простой сервисов –  маленькая доступность. Нет инцидентов/простоя – большая доступность. Например, доступность/результативность 98%, зрелость 4 балла – типа 80%. Что нам дает/может дать gap – анализ? 

  • justmag

    Пишу прямо – идея только гипотеза и нуждается в проверке.

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

    2. ITIL страдает такой же проблемой-слабая корреляция с реальным миром. Вы верите, что "ценность услуг определяется совокупностью двух факторов – функциональностью (utility) и гарантией (warranty)"? Это всегда так? Есть такое понятие triviality test. Предложите процесс с очень низкими затратами и вы увидите на практике, чем определяется ценность (услуги) процесса в большинстве случаев 🙂 , ну ладно т.к. я тоже не вел учет статистики, то пусть  во многих случаях. Это не единственный возможный пример отличия принципов ITIL от жизни.

    3.Согласен с автором, что "такие диаграммы не являются основанием для принятия каких-либо решений и потому не несут заказчикам значимой ценности", т.е. приблизительно =0. Добавляя к 0 нечто мы не добавляем ценности к анализу. Будет лучше Просто рассматривать результативность. Кстати, не ясно, а для чего вы эти улучшенные диаграмы хотите применять?  для приянтия каких решений?

    4. И последнее, по моему глубокому внутреннему убеждению, аудит должен быть объективным. Финансовые аудиторы не занимаются рисованием пауков. И это при том, что экономические модели так же не на 100 % коррелируют с реальностью. И руководители фирм  что-то видят в их отчетах для принятия решений…

    • 1. С этим я как раз согласен. Именно поэтому возникла мысль добавить на график вторую характеристику – результативность. В приведённом примере gap-анализа значения этих величин также оцениваются независимо (см. нижний левый и верхний правый квадранты), что было бы некорректно при наличии между ними причинно-следственной связи.

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

      3. Если рассматривать только результативность, Вы упускаете из виду риски, связанные с отсутствием контроля и развития процесса (а значит его нарушения и потери актуальности в результате перемен). Легко вспомнить массу примеров, когда такое упущение нежелательно – для ИТ-руководителя, для бизнес-руководителей, для акционеров. О том, какие решения можно принимать – опять же, смотри пример gap-анализа.

      4. Здесь я боюсь, что не полностью уловлил Вашу мысль. Но мне кажется, что мы опять ближе, чем Вам кажется. Ведь, как следует из названия заметки, я предлагаю этот инструмент не аудитору, а ИТ-директору. Что касается аналогии с финансовым аудитом, перед аудитором, насколько мне известно, не ставится задача выбора направлений развития системы управления. Его задача заключается в другом – определить наличие соответствий / несоответствий между реальным положением дел и отчётностью (предоставляемой акционерам, регуляторам, кредиторам, покупателям и другим заинтересованным сторонам). Поэтому пауки и не нужны. Наверно.

  • justmag

    Дмитрий, наконец-то понял что Вы хотели сказать двумя графиками (пауками).

    Относительные величины – не самый наглядный сметод представления результатов.

    Если есть реальные данные, цифры, то есть лучшие виды диаграмм и графиков. Пауки могут применяться когда нечего сказать…или надо о чем-то умолчать.

    А  упражнение gap-analisys в данном виде я интуитивно воспринимаю как раз для связанных между собой величин зрелости и результативности и мое замечание было именно о нем.  Вдумчивый читатель задасться вопросом о корреляции, раз рассматриваются только 2 показателя в таком виде. Иначе, логичнее простая таблица со столбцами слева-направо для зрелости и результативности, etc. или разные таблицы. Пример только 2х2, а что будет если это 10х10 или если рассмотреть не 2 а 5 зпоказателей? 

    По поводу самого понятия Зрелость я пожалуй продолжать не буду, кто как хочет, тот так им и воспользуется…. Тут все на совести руководителей 🙂  И все-таки думаю ничтожный параметр показывать на графике для принятия решений не стоит.

    Отличие финансового аудита отчасти в том, что от него ожидается абсолютное значение показателей в цифрах и его обоснование. Поэтому относительные % могут применяться только там где это действительно требуется и в презентациях. От ИТ-аудита на сегодня такого не ожидается. Я думаю, что руководитель не сам будет рисовать пауки, а для него будет делать аудитор или аналитик, возможно сторонний. Результаты аудита/анализа ложаться в основу выбора направления разития, изменений системы, инвестиций, планов, стратегий, и т.п. И в ИТ и  не в ИТ. Что руководителю нарисуют, то и будет использоваться для принятия решения. Считаю, что отчасти поэтому ИТ часто воспринимается как непознаваемый центр затрат. 🙂

    Когда ознакомлюсь с вашей книгой напишу тут небольшую статью – мое мнение о проблемах применения измерений в ИТ процессах.

    • Когда ознакомлюсь с вашей книгой напишу тут небольшую статью — мое мнение о проблемах применения измерений в ИТ процессах.

      Если подойти к теме конструктивно (ведь даже у самых сложных проблем есть или решения или способы снизить остроту), статья может получиться интересной. Для размещения такого материала, на мой взгляд, лучше всего подходит альманах ITSM – там уже не первый год нехватка хороших статей отечественных авторов. Сейчас как раз формируется контент альманаха за 2015 год.

      А мне будет интересно почитать 🙂


Добавить комментарий для АльбертОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM