Курсы в Москве

SCHEDULE Расписание курсов

ITILF Курс «Основы ITIL®»

COBIT5F «Основы COBIT 5»

OSA Курс «Service Desk и процессы оперативного управления ИТ-услугами в соответствии с ITIL®»

RCV Курс «Проведение изменений в ИТ в соответствии с ITIL®»

ITAM Курс «Управление ИТ-активами. Основы и практики»

PPO Курс «Оптимальное проектирование ИТ-услуг в соответствии с ITIL®: информационная безопасность, мощность, доступность, непрерывность»

ITHR Курс «Управление ИТ-персоналом»

COBIT ICS Курс «Система внутреннего контроля ИТ по модели COBIT(COBIT Internal Control System)»

SOA Курс «Управленческие инструменты организации отношений ИТ с бизнесом на основе ITIL®»

MALC Курс «Управление жизненным циклом услуг»

ITSS Курс «Управление стратегией ИТ-услуг на основе ITIL®»

ITILF Курс «Основы ITIL®» (Вечерний)

M_o_R Курс «Основы управления рисками по модели M_o_R®»

ITSO Курс «Эксплуатация услуг по модели ITIL®»

ITILF Курс «Основы ITIL®» (Вечерний)

ITPR Курс «Практика внедрения и адаптации рекомендаций ITIL®»

ITILF Курс «Основы ITIL®» Онлайн

ITILF Курс «Основы ITIL®» (Утренний)

OSA Курс «Service Desk и процессы оперативного управления ИТ-услугами в соответствии с ITIL®» Онлайн

RCV Курс «Проведение изменений в ИТ в соответствии с ITIL®» Онлайн

SOA Курс «Управленческие инструменты организации отношений ИТ с бизнесом на основе ITIL®» Онлайн

RCV Курс «Проведение изменений в ИТ в соответствии с ITIL®»

PRINCE2 Курс «Основы PRINCE2®»

PPO Курс «Оптимальное проектирование ИТ-услуг в соответствии с ITIL®: информационная безопасность, мощность, доступность, непрерывность»

SOA Курс «Управленческие инструменты организации отношений ИТ с бизнесом на основе ITIL®»

AWS Курс «Мастерская проектирования ИТ-решений»

ITMA Курс «Автоматизация управления ИТ»

ITSD Курс «Проектирование услуг по модели ITIL®»

ITST Курс «Преобразование услуг по модели ITIL®»

CSI Курс «Постоянное совершенствование услуг по модели ITIL® (ITIL Continual Service Improvement)»

Тренажер подготовки к экзамену ITIL Foundation
Страховой сертификат повторной сдачи экзамена
  • 31243

    Количество выданных сертификатов

  • 2754

    Количество проведенных игр и семинаров

Оценка работы процессов. Показатели и метрики

Для чего нужны метрики

Невозможно управлять тем, что нельзя измерить. Эта фраза встречается во многих руководствах по управлению ИТ, да и по любому менеджменту. Невозможно управлять производством без измерительных приборов, позволяющих вовремя принимать правильные решения и реагировать на изменяющуюся ситуацию. Подразделение ИТ – то же производство, сравнимое по сложности со средним заводом, и для управления им нужны соответствующие инструменты. Метрики процессов - инструменты управления. От того, как будет выстроена система метрик, зависит, насколько эффективно руководитель сможет управлять организацией.

Разница между метриками и показателями

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

Показатель – измеримый параметр достижения определенной цели. Для показателя должно быть определено целевое значение и желательная тенденция.

Классификация метрик

Деятельность любой ИТ организации можно разделить на три сегмента

Каждым из этих сегментов следует управлять и, следовательно, измерять.

Сервисные метрики

Показывают, как предоставляются наши сервисы. Эти метрики соответствуют параметрам сервисов согласованным в SLA. Именно изменение этих метрик в первую очередь чувствует на себе заказчик. Они формулируются в терминах, понятных заказчику, и должны коррелировать с субъективным восприятием заказчика.

Примеры таких метрик: время формирования отчета, количество клиентов, обслуженных в единицу времени и т.д.

Именно за значения сервисных метрик ИТ организация отвечает перед заказчиком.

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

Технологические метрики

Технологические метрики отражают здоровье инфраструктуры. К ним относятся текущая загрузка каналов связи, свободное дисковое пространство, количество сбоев в дисковом массиве и т.д. Контроль этих метрик чаще всего возлагается на системы мониторинга и управления событиями.

Процессные метрики и их классификация

Процессные метрики показывают эффективность работы внутренних процессов ИТ организации.

У любого процесса есть вход и выход, кроме того, процесс использует ресурсы и подвергается управляющим воздействиям.

Выстраивая систему метрик необходимо помнить об этих четырех составляющих и измерять каждую из них.

Метрики входа – измеряют нагрузку на процесс. Например, для процесса управления инцидентами количество инцидентов – метрика входа. Важно, что для менеджера процесса метрики входа – показатель исключительно информационный, на них нельзя влиять, а можно только реагировать.

Метрики выхода, или метрики результативности – показывают, насколько процесс достигает своей цели.

Метрики ресурсов показывают загрузку и достаточность ресурсов, используемых процессом.

Метрики управления показывают, насколько процесс управляем, эффективны управляющие воздействия.

В CobiT предложена своя классификация метрик: показатели результативности, показатели управляемости. Кроме того, для каждого процесса предложена модель зрелости.

Разложение метрик по четырем составляющим сопоставимо с классификацией метрик, предложенной в CobiT. Показатели результативности – метрики выхода, показатели рациональности – метрики ресурсов, зрелость процесса – метрика управляемости.

Очевидно, что, планируя целевые значения для различных метрик, следует балансировать их между собой. Потому что процесс может быть очень результативен и совсем нерационален и наоборот. Например, мы можем устранять все инциденты за полчаса, силами тысячи человек, или же справляться десятком человек, но устранять инциденты за месяц.

Отчетность корректирующие меры

Показатели не интересны сами по себе, они нужны для осуществления управленческих воздействий на процесс. Следовательно, ответственность за достижение целевых показателей должна быть возложена на руководство процесса и на сотрудников, назначенных на роли в процесс.

Должна быть выстроена система отчетности по показателям. Важно, чтобы на каждом уровне управления были представлены соответствующие показатели. Вряд ли директору по ИТ будет интересно анализировать статистику сбоев одного из дисковых массивов. Система отчетности должна быть выстроена таким образом, чтобы на каждом уровне, каждый менеджер контролировал и отвечал за 3-9 показателей. Большее количество трудно удерживать под постоянным контролем.

Вопросы мотивации

Зачастую показатели эффективности процесса используют для постановки личных целей и мотивации сотрудников. На первый взгляд, это логичное и правильное решение. Однако у человека, зарплата которого зависит от выполнения целевых значений, будет слишком велико искушение "подправить" показатели в свою пользу. Такая "правка" приводит к нарушению главного принципа использования показателей – объективности и достоверности, как если бы врач ставил диагноз и назначал лечение на основании неправильной информации о температуре пациента.

Как этого избежать? Можно создать развитую службу внутреннего аудита, которая гарантировала бы актуальность показателей. Но, зачастую, затраты на содержание такой службы неоправданны. Однозначного рецепта тут нет. Приходится искать разумный баланс между доверием и контролем.

Выстраивание системы показателей ИТ

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

Таким образом, первичны цели сервисов, параметры, зафиксированные в SLA. Цели процессов и показатели, их измеряющие, должны определяться путем декомпозиции этих параметров. Например, в SLA может быть зафиксирована целевая доступность сервиса. Очевидно, что на доступность сервиса влияют такие показатели как время устранения инцидентов, количество инцидентов, успешность проведения изменений и пр. Целевые значения этих показателей должны определяться из целевого значения доступности сервиса. Также понятно, что значимость каждого из этих показателей неодинакова и может меняться в зависимости от условий.

Исходя из значимости каждого показателя ему должен быть присвоен соответствующий вес.

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

На основании чего строить систему показателей?

Чем же руководствоваться при построении системы измерений для ИТ процессов?

В первую очередь, конечно, CobiT. В этой методологии предлагается процессная модель, состоящая из тридцати четырех процессов. Считается, что любая деятельности внутри организации ИТ может быть отнесена к одному из этих процессов. Для каждого процесса приведен набор показателей результативности и рациональности. Проблема в поверхностном и общем описании метрик. При использовании рекомендаций CobiT способы измерения целевые значения и алгоритмы расчета показателей придется продумывать самостоятельно.

Что касается ITIL®, то он более конкретен. В нем можно найти достаточно подробный перечень показателей для каждого процесса со способами их измерения и желательными тенденциями. Однако, в ITIL®, как известно, описаны не все возможные процессы ИТ. Например, за показателями процесса Разработки ПО придется обращаться к другим источникам.

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

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

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



Консультанты IT Expert

Подробнее эта тема обсуждается на следующих курсах:

Схожие вопросы затрагивались в следующих проектах:

Все проекты преобразований ИТ и реализации процессного управления.

Данная заметка отражает мнение автора, которое может не совпадать с уважаемыми первоисточниками (ITIL® v2, ITIL® v3, COBIT, MOF и проч.). Комментарии и предложения темы для следующей заметки можно отправлять на items@itexpert.ru.

Вверх

Закажите услугу обратный звонок, после чего наши менеджеры свяжутся с вами




CAPTCHA
*