Академический Документы
Профессиональный Документы
Культура Документы
Metrics
for IT Service
Management
Метрики
для управления
ИТ-услугами
Москва
2008
УДК 004 Издано при содействии IBS
ББК 32.97
Б89
Переводчик В. Первушина
Научные редакторы А. Белей, И. Копасов,
О. Чернова, В. Губер, А. Аболенцев
Редактор М. Суханова
Брукс П.
Б89 Метрики для управления ИТ-услугами / Питер Брукс ; Пер. с англ. —
М.: Альпина Бизнес Букс, 2008. — 283 с.
ISBN 978-5-9614-0647-4
Книга, адресованная в первую очередь ИТ-директорам, представляет собой
общее руководство по проектированию и реализации метрик для сервисных
ИТ-подразделений, работающих по стандартам отрасли. Автор берет за основу
структуру процессов ITIL и опирается на ряд принципов, сформулированных в
ITIL и стандарте ISO20000 (BS15000). Большое место отводится типичным
проблемам, связанным с правильным применением метрик, и возможным
путям их решения. Даются конкретные рекомендации по применению метрик
в процессах ITIL, ISO20000 (BS15000) и других. Приводимые в книге метрики
могут быть использованы и непосредственно, и в качестве отправной точки для
создания набора, отвечающего специфическим потребностям организации.
УДК 004
ББК 32.97
© ITSMF, 2006
© Издание на русском языке,
ISBN 978-5-9614-0647-4 (рус.) перевод, оформление.
ISBN 90-77212-69-8 (англ.) ООО «Альпина Бизнес Букс», 2008
Оглавление
Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Разработка метрик . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.1. Зачем разрабатывать метрики . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2. Принципы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.4. Разработка отдельных метрик. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.5. Разработка интегрированных наборов метрик . . . . . . . . . . . . . . . . 57
6.6. Примеры хороших и плохих метрик . . . . . . . . . . . . . . . . . . . . . . . . . 58
9. Интеграция метрик . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Петр Дубенсков,
заместитель директора департамента системных решений IBS
Введение
1.1. Задачи
Цели или задачи использования метрик в управлении ИТ-услуга-
ми (IT Service Management — ITSM) таковы.
1. Согласовывать деятельность ИТ-подразделения с зада-
чами бизнеса:
14 МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
1
Чрезвычайный план — предопределенный план действий в аварийных ситуациях, включа-
ющий процедуры резервного копирования и подготовку резервного оборудования для
преодоления чрезвычайной ситуации. — Прим. пер.
16 МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Клиент
В данной книге, используя слово «клиент», мы имеем в виду покупателя ус-
луги, независимо от того, является ли она внутренней или внешней. В этом
разделе речь идет о конечном потребителе, для которого должна осущест-
вляться вся деятельность предприятия. ИТ-организация выполняет вспомо-
Глава 1. ЧТО ТАКОЕ МЕТРИКИ? 19
Пользователь
Поскольку пользователи не участвуют в переговорах об условиях обслужи-
вания и не оплачивают его, они не являются прямыми покупателями ИТ.
Тем не менее это участники бизнеса, и их удовлетворенность жизненно важ-
на. Если пользователи недовольны тем, что им предоставляются услуги низ-
кого качества, подобного мнения станут придерживаться и клиенты.
Сотрудник
Сотрудники ИТ-подразделения отвечают за функционирование процессов
обслуживания. В свою очередь, ИТ-подразделение может обеспечить своему
персоналу хорошие условия работы, справедливую оценку и вознагражде-
ние. Если сотрудники не удовлетворены, предоставляемый ими уровень об-
служивания снижается вне зависимости от качества разработанных метрик.
Поэтому руководители ИТ-подразделений обязаны оценивать моральное
состояние своих подчиненных и реагировать на изменения, которые могут
оказать на него негативное воздействие.
Сотрудникам больше нравится, когда они ощущают, что их признают
участниками бизнеса. Важно также, чтобы они могли отождествлять себя
с работодателем, положительно относясь к компании и одобряя ее процес-
сы. Четкие и открытые метрики позволяют им понимать, в каких областях
подразделение функционирует успешно, а где требуются дополнительные
усилия. Эффективная коммуникация помогает сотрудникам своевременно
реагировать на проблемы и находить вдохновение для дальнейшей деятель-
ности.
Правление
Как участники бизнеса, высшие менеджеры и правление компании испыты-
вают специфическую потребность. В интересах процветания бизнеса их
необходимо заранее предупреждать обо всех потенциально серьезных инци-
дентах, чтобы можно было срочно предпринять корректирующие действия.
Открытая и прозрачная коммуникация с правлением в состоянии помочь
20 МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Требование Ежемесячный
клиента SLA OLA/UC CSF KPI отчет
Владелец Внутрифирменные
Метрики
процесса участники бизнеса
Программа улучшения
качества обслуживания
(SIP) Метрики
процесса
Запросы на изменения Отчеты об уровне сервиса;
KPI;
Соответствие SLA
Удовлетворенность;
Обратная связь
Внешние участники
бизнеса
1
Бенчмаркинг — процесс поиска новых и более совершенных процедур, осуществляемый
путем сравнения собственных процедур с наилучшими из тех, которые используют дру-
гие. — Прим. пер.
Глава 1. ЧТО ТАКОЕ МЕТРИКИ? 23
1
Перевод Бориса Заходера.
26 МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Если же нам, как Алисе, все равно, куда идти, то совершенно не важно,
что мы измеряем. Даже вообще не оценивая свое продвижение, мы все рав-
но куда-нибудь попадем. Но скорее всего не туда, куда нужно!
Таблица. 2.1
Пять методов координирования организационных мероприятий
и их аналоги при вождении автомобиля (по Минцбергу)
Метод координирования Аналогия при вождении автомобиля
Прямое руководство Начальник поручает водителю доставить пакет клиенту
сегодня к 17:00.
Подстраивание друг под друга Водители планируют свои перерывы, чтобы все автобусы
не оказались оставленными одновременно
Стандартизация методов работы Водителей учат действовать в соответствии с заранее
определенной процедурой
Стандартизация результатов Водители прибывают в пункт назначения с отклонением
от графика в пределах десяти минут
Стандартизация возможностей Водители имеют высшую категорию
2.4. Затраты
Проведение измерений может стоить массу денег. Одному консультанту по
управлению услугами посчастливилось сэкономить для компании несколько
миллионов фунтов стерлингов, закрыв отдел, где более ста сотрудников за-
нимались только составлением отчетов. Он выяснил, что все эти отчеты
проще и дешевле получать из других отделов.
Некая международная организация ежемесячно рассылала сборник своих
отчетов, называвшийся, по цвету обложки, «Синей книгой». В один из меся-
цев, чтобы проверить значимость отчетов, руководство решило их не рассы-
лать, а дождаться запросов. Поступил только один. Руководители были рады
узнать, что хоть один из двадцати получателей этого весьма дорогого сбор-
ника действительно в нем заинтересован, и захотели узнать причину. «Кни-
га очень нравится моей четырехлетней дочери, — объяснил он. — На оборо-
те каждой страницы можно рисовать картинки, а бумага очень хорошего
качества».
Отчеты представляют ценность только тогда, когда ими пользуются, а это
происходит при условии, что в них сообщается что-то интересное. Метрики
должны создаваться для оценки того, что действительно важно, и так, чтобы
результаты были представлены в четкой и простой форме. Для удоволетво-
рения потребностей большинства менеджеров в необходимой информации
будет вполне достаточно краткой сводки на одну страницу, размещенной на
веб-сайте, конечно, если потенциальные проблемы в ней понятно и четко
сформулированы. Прятать плохие новости в примечания в конце отчетов —
это подход, возможно, и срабатывающий для компаний, зарегистрированных
на фондовой бирже, но неприемлемый для ИТ.
Глава 2. ЗАЧЕМ НУЖНЫ МЕТРИКИ? 31
3.2. Процессы
Многие процессы не привязаны к одному конкретному отделу, а являются
сквозными и обеспечивают предоставление услуг на базе многих подразде-
лений и организаций. За такой процесс отвечает его владелец, и он должен
обладать достаточными полномочиями, чтобы полностью влиять на работу
метрик, и, если понадобиться, использовать свое служебное влияние, или
помощь руководства.
Глава 3. ОБЛАСТИ ПРИМЕНЕНИЯ МЕТРИК 35
5.1. Время
Частота измерений влияет на результаты. Отчеты о метриках
могут предоставляться каждый день, месяц, неделю, квартал
или год, и очень важно, чтобы временной интервал был выбран
правильно.
Было бы ошибкой принимать стратегические решения на
основе одного из ежедневных отчетов: нельзя исключить, что
его данные — аномалия. Аналогичным образом годовой отчет
позволяет выработать стратегию исправления ситуации, но не
тактические решения на следующую неделю для службы Service
Desk.
Важно понимать, что многие показатели, помимо частоты
измерения, характеризуют интервал времени, за который долж-
но смениться состояние процесса, — например, как быстро
проблема из «новой» превратится в «решенную». В таких случа-
ях нельзя просто фиксировать состояние через равные проме-
жутки времени — ведь если код остается прежним, это не дает
никакой дополнительной информации. Здесь измерение возмож-
но только тогда, когда что-то (как правило, некоторый процесс)
действительно изменяется.
5.2. Измерение
Чтобы управлять бизнесом, его нужно измерять. В коммерчес-
кой деятельности для этой цели выработано несколько четких и
конкретных показателей, общих для целого ряда отраслей:
44 МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
• доход;
• прибыль;
• объем продаж;
• доля рынка;
• норма окупаемости инвестиций (Return On Investment — ROI);
• объем производства;
• уровень запасов.
Метрики
процесса
+ KPI
Метрики
Состояния
Организации
процессов
Рис. 5.1. Общий сценарий процесса. Метрики могут фиксировать только изменения
состояния процесса. Чтобы они имели смысл, важно правильно определить процесс
Глава 5. КАК ИСПОЛЬЗОВАТЬ МЕТРИКИ 45
5.3. Контроль
Когда критерии выработаны, можно начинать контролировать измеряемую
часть процесса: узнать, кто отвечает за каждое из конкретных состояний
процесса и за переходы между ними, затем установить для подпроцессов
ориентиры, на основе которых будет оцениваться их эффективность. Обыч-
ные способы для этого — либо понаблюдать за показателями в течение од-
ного-двух периодов времени, чтобы получить таким образом представление
о нормальном ходе работы, либо сравнить данный подпроцесс с аналогич-
ным в своей или другой организации.
После установки ориентиров можно переговорить с владельцем подпро-
цесса, чтобы вместе с ним определить задачи по улучшению ситуации. Ин-
формация о продолжительности состояний позволяет также выявить те
подпроцессы, которые требуют больше всего времени и ресурсов, а значит,
обещают максимальный эффект от усовершенствования.
Чтобы получить правильный результат, необходимо учитывать, что не все
состояния равноценны. На диаграмме состояний процесса, показанной на
рис. 5.2, можно увидеть альтернативные пути.
П1 П3
П4
П2
П0 П6 П5
П8
П7
5.4. Цель
Контроль — это прекрасно. И все же, продолжая нашу аналогию с вож-
дением автомобиля, если вас до наступления сумерек ждут в Амстерда-
ме, а вы, проведя день за рулем, приезжаете в Париж, вас вряд ли за это
похвалят.
Чтобы управлять процессом, нужно понимать, к чему именно вы стреми-
тесь. В примере с проверкой кредитоспособности можно было бы, скажем,
пожелать, чтобы общая сумма безнадежных долгов не превышала 5% това-
рооборота, а время обработки заказа — восьми рабочих часов. С заданной
таким образом целью становится намного понятнее, какие именно процессы
нужно измерять.
Определив цель и соответствующие измерения, необходимо проверить
обоснованность принятых решений с помощью контрольного тестирования.
Затем следует оценить разрыв между целью и нынешним положением дел
(к примеру, долги составляют 10% товарооборота, а обработка заказа длится
двенадцать рабочих часов). Заключительный шаг — разработка плана по
преодолению разрыва путем усовершенствования процесса, а также, возмож-
но, за счет использования дополнительных ресурсов или даже аутсорсинга
некоторых частей процесса.
С этими решениями можно уже двигаться по направлению к цели, уста-
навливая для команд и владельцев подпроцессов промежуточные цели в
виде определенных показателей эффективности.
48 МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
5.5 Учет
В методиках, описывающих управление ИТ-услугами, в частности в ITIL,
ставится задача максимально тесной привязки этого управления к целям
конечного потребителя, которые часто (или даже как правило) носят фи-
нансовый характер. Обеспечению привязки посвящен специальный раздел
ITIL — управление финансами ИТ. Задействовав его на начальной стадии
разработки метрик, можно встроить в проект оценку ресурсоемкости.
Допустим, установлено, что затраты на одну заявку составляют сто условных еди-
ниц. Изначально это, по-видимому, очень грубая оценка, рассчитанная путем
деления расходов на службу Service Desk на количество обращений. Со временем
ее можно будет уточнить, предоставив управлению финансами информацию о
реальном времени работы согласно заданным процессным метрикам, KPI и SLA,
а также теоретическую базу для учета этих цифр.
В самом начале такая процедура способна помочь с выявлением SLA, которые
вносят незначительный вклад в выполнение бизнес-функции, но поглощают мно-
го ИТ-ресурсов. Разумеется, компания вполне может решить, что подобное рас-
пределение правильно, но в случаях, когда оно не является приоритетным, пере-
смотр «ресурсоемких» SLA позволит значительно сэкономить на расходах.
6.2. Принципы
6.2.1. SMART
Аббревиатура SMART (Specific, Measurable, Achievable, Realistic, Timely —
конкретный, измеримый, достижимый, реалистичный, своевременный) ис-
пользуется применительно ко многим бизнес-процессам. Это полезный на-
бор вопросов, которые следует задать по поводу любой метрики перед тем,
как ее внедрять.
Относится ли метрика к некоторому конкретному процессу или части
процесса? Если оценке подвергаются части двух разных процессов, есть
опасность, что ни один из их владельцев не будет считать себя ответственным
за достижение результатов.
Измерима ли метрика? Очень важно убедиться, что это базовое условие
выполнено. Если, допустим, вы решите измерить продолжительность разго-
воров клиентов со службой Service Desk, вам не удастся осуществить это без
коммутатора или офисной телефонной станции.
Глава 6. РАЗРАБОТКА МЕТРИК 51
6.2.2. KISS
Аббревиатура KISS (Keep It Simple Stupid — будь проще, дурачок!) не очень
удачна, но выраженный в ней принцип тем не менее важен. Если метрики
плохо разъяснены и способы их достижения недостаточно понятны, это от-
крывает дорогу для сопротивления, неприятия, разочарований и позволяет
легко находить оправдания, когда не выполнены требования.
Некоторым людям свойственно подходить ко всему аналитически. Это
очень полезно в ИТ, где сложные задачи требуют детального анализа. Од-
нако при разработке метрик существует опасность создания переусложнен-
ных формул для измерения сразу нескольких вещей. Пусть, например, у нас
есть метрика «среднее число инцидентов на проблему, с которой связан
запрос на изменение». Этот показатель можно понять, но о чем он нам
сообщает и как его улучшить? Нужно ли, чтобы увеличилось число запросов
на изменение для проблем с большим количеством инцидентов, или следу-
ет более дробно подразделять проблемы, чтобы с каждой было связано
меньше инцидентов? Совершенно неясно, почему это важно и что здесь
исправлять.
Лучше всего отступить на шаг и спросить себя, что в данном случае су-
щественно. Может быть, число инцидентов на проблему? Или значение,
придаваемое проблемам? Важны ли запросы на изменение сами по себе или
52 МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
как мера для оценки процесса решения проблемы? Ответив на эти вопросы,
вы, может быть, придете к выводу, что две-три простые метрики представ-
ляют собой лучшее решение, чем первоначальная сложная.
6.2.3. GQM
Метрики давно используются в управлении проектами по разработке при-
кладного ПО. Из этой сферы пришел метод выработки метрик, называемый
GQM (Goal, Question, Metric — цель, вопрос, метрика).
Он предусматривает определение высокоуровневых целей проекта (в уп-
равлении услугами это будут цели процесса). Для каждой из целей составля-
ется перечень вопросов, на которые будут даны ответы, если поставленные
цели достигнуты, а затем разрабатывается метрика для количественной
оценки результатов.
И хотя данный формальный метод нами не применялся, метрики в главах 7
и 8 разрабатываются сверху вниз. В начале каждого раздела определяется
цель процесса, затем перечисляются соответствующие ей метрики, а объяс-
нение каждой из метрик, по сути, представляет собой вопрос, утвердитель-
ный ответ на который означает, что цель достигнута.
6.2.4. MAPE
Метрики ITSM могут выдавать голые цифры, такие как столько-то тысяч
инцидентов, столько-то миллионов сетевых событий и т. д. Их сложно срав-
нивать, особенно если речь идет о разных организациях или процессах.
Часто имеет смысл переводить абсолютные показатели в проценты, чтобы
сделать их проще для понимания. Различные методы такого рода использу-
ются при прогнозировании тенденций в бизнесе.
Они могут применяться и в ИТ для планирования мощностей или оценки
будущих ресурсов. Например, потребуется ли в следующем году больше ква-
лифицированных сотрудников для службы Service Desk, и если да, то сколько
именно? Чтобы ответить на этот вопрос, необходимо разработать метрики
для измерения рабочей нагрузки, а кроме того, составить прогноз на сле-
дующий год. Для прогнозирования существует масса разных методов — от
прямой линейной экстраполяции до сложного моделирования, — но с каким
из них мы получим качественный и надежный результат?
Коэффициент MAPE (Mean Absolute Percentage Error — средняя абсолют-
ная ошибка в процентах) применяется в статистике для оценки достовер-
ности прогнозов. Скажем, можно сравнить по формуле для MAPE показате-
ли, получающиеся при выбранном вами способе прогнозирования, с сущест-
вующими историческими данными Service Desk за последние шесть месяцев.
Если MAPE низкий (менее 40%), прогноз, вероятно, достаточно надежен.
Формула для его расчета выглядит следующим образом:
Глава 6. РАЗРАБОТКА МЕТРИК 53
Доступность Мощность
Инциденты/
Клиент Service Desk Проблема Изменение
Информационно-
Поставщик коммуникационная Конфигурация Релиз
инфраструктура
Приложение
6.3. Требования
Для эффективной работы метрик нужны правильно разработанные про-
цессы. Со временем последние могут меняться, и это в действительности
необходимо в рамках процессов непрерывного улучшения качества функ-
ционирования ИТ-служб. Однако чем реже модифицируются основные
элементы, тем лучше. Такого рода преобразования требуют очень аккурат-
Глава 6. РАЗРАБОТКА МЕТРИК 55
Итак:
• разрабатывайте процессы таким образом, чтобы в них с самого начала
были включены нужные состояния;
• если выполнение процесса подвергается изменению, проследите за
полнотой информирования и переподготовки тех, кого это касается;
• не используйте всеобъемлющих статусов и категорий;
• отслеживайте и контролируйте применение статусов и категорий.
нию, такие опросы требуют денег и времени (в том числе отнимают время
у клиентов), и если они проводятся слишком часто, это вызывает раздра-
жение.
Поэтому опросы не могут удовлетворить потребность в своевременной
оценке эффективности процесса управления услугами. Метрики в этой
книге опираются на более «быструю» обратную связь, получаемую для
только что сделанной работы. К примеру, закрытие инцидента, проблемы
или релиза дает клиенту шанс прокомментировать степень собственной
удовлетворенности, а также высказать рекомендации по улучшению ра-
боты.
В некоторых процессах сложно определить подходящие контрольные
точки. Для них, возможно, понадобится придумать в той или иной степени
искусственный механизм, который все-таки обеспечит своевременную об-
ратную связь и таким путем решит проблему опросов. К примеру, удачным
решением могут стать еженедельные встречи по вопросам удовлетвореннос-
ти с менеджером «ключевого» процесса — по сути усеченный и более частый
опрос.
В нашей схеме метрики степень удовлетворенности клиентов оценива-
ется числом в интервале от 0 до 5, где 0 означает «совершенно не удовлет-
ворен», а 5 — «совершенно удовлетворен». Целевое значение — 4, опасный
уровень — ниже 3.
Что касается процесса управления конфигурациями, то здесь стоит отме-
тить, что на нашей диаграмме взаимоотношений (см. рис. 6.1) в качестве
«главного» клиента показано управление релизами. Вообще говоря, допус-
тимым выбором было бы и управление инцидентами, проблемами или из-
менениями — ведь все эти процессы тоже упоминаются в формулировке
целей управления конфигурациями. Однако управление релизами особенно
важно, так как оно отвечает за крупные изменения инфраструктуры, которые
обязательно должны быть правильно отражены в CMDB.
Обратите также внимание, что метрика на рис. 7.1 относится к одному
процессу, но сама состоит из трех подпроцессов. Таким путем обеспечивает-
ся измерение не только конечного результата в момент закрытия релиза, но
и важных промежуточных показателей во время его планирования и реали-
зации. Было бы неплохо изобрести и другие метрики удовлетворенности
клиента для различных контрольных точек, где участвует процесс. Но не все
так просто.
Так, слияние трех метрик может означать, что из-за одной ошибки в CMDB
сразу три по видимости отдельных показателя удовлетворенности окажутся
низкими. Наверняка владелец процесса воспримет это как несправедливость.
Однако есть способ избежать подобного эффекта. Если первая ошибка при-
водит к ошибке планирования, то после фиксации этого факта и получения
низкой оценки самое время исправить CMDB. Так мы избавимся от двух
других низких оценок, проделав фактически исключительно эффективную
Глава 7. СОЗДАНИЕ МЕТРИК НА ПРАКТИКЕ 65
1
Запрос на изменение — зафиксированное требование клиента на внесение изменений в
любые элементы конфигурации в инфраструктуре или внесение изменений в процедуры,
связанные с инфраструктурой. — Прим. пер.
Глава 7. СОЗДАНИЕ МЕТРИК НА ПРАКТИКЕ 67
яние. Например, если бы нам было необходимо узнать только число релизов,
мы могли бы не пользоваться возвращаемым значением степени удовлетво-
ренности, а просто пересчитать все состояния «полный анализ релиза».
Метрика удовлетворенности клиента, таким образом, полностью охваты-
вает весь процесс управления конфигурациями. На рисунке это обозначает-
ся двумя стрелками, ведущими от начала и от конца процесса к подпроцессу
измерения показателя.
На рис. 7.1 показаны три подпроцесса управления релизами:
• присвоение CI нового статуса;
• добавление CI в план релиза;
• полный анализ релиза.
Так как CI используются для документирования релиза, они перед обнов-
лением получают статус «предназначен для релиза», а после него — «обнов-
ляется с релизом». Именно по эффективности этого процесса и по отчетам о
состоянии релиза в ходе его реализации мы судим о качестве управления
конфигурациями.
Три названных подпроцесса управления релизами интересуют нас как те
точки, где используются CI (результат процесса управления конфигурация-
ми). Именно здесь владелец подпроцесса (или человек, которому делегиро-
вана эта задача) сможет оценить вклад в него со стороны управления кон-
фигурациями.
Удовлетворенность
клиента —
возвращаемое
значение
Подсостояния процесса
управления релизами,
Подсостояние используемые Подсостояние
в управлении Присвоить
процесса CI новый статус процесса
конфигурациями
8
Итоговый показатель = Σ PN × RN,
N=1
Таблица 7.1
Данные метрик
Фактическое
Приоритет/
Результат
значение
значение
значение
Опасное
Целевое
Метрика
Вес
Таблица 7.2
Подсчет метрик
Итоговый Предыдущий
Процесс Результат
показатель показатель
Управление конфигурациями + 0,71 + 0,68 + 0,03
Управление изменениями + 0,84 + 0,88 – 0,04
Управление уровнем обслуживания + 0,55 + 0,47 + 0,08
Управление финансами – 0,24 – 0,34 + 0,10
Таблица 7.3
Метрическая схема для управления конфигурированием
Возможные
Метрика Опасность Цель
значения
1. Степень удовлетворенности клиентов <3 4 0–5
2. Количество неиспользуемых лицензий > 10 5 Не ограничено
74 МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
• управлению доступностью;
• управлению информационной безопасностью.
Метрики для стратегических процессов управления услугами будут отно-
ситься к:
• оценке перспектив развития бизнеса;
• программе постоянного улучшения качества обслуживания (Service
Improvement Programme — SIP);
• управлению рисками;
• управлению документацией;
• компетентности, осведомленности, обучению (Competence, Awareness
and Training — CAT).
В заключительном подразделе перечислены метрики для управления про-
граммами и проектами.
Подробные описания всех метрик приводятся в приложениях, где дается
их определение, объяснение и обоснование. Номер приложения для каждого
процесса указан в скобках.
В приложениях для каждого процесса описываются его цели, формулиру-
ется назначение и указывается наиболее вероятный владелец, а затем пе-
речисляются конкретные задачи.
Каждой задаче соответствуют одна или более метрик, а каждой метри-
ке — ровно одна метрическая задача (та задача процесса, выполнение ко-
торой оценивается с помощью данной метрики). Метрики группируются по
задачам.
Приводимые в книге метрики — это примеры, и их можно модифициро-
вать в соответствии с моделями работы или наборами требований конкретных
организаций, опираясь на принципы, описанные в первых восьми главах.
Впрочем, не возбраняется использовать их и как есть. Примеры представлены
так, как их можно было бы реализовать в табличном процессоре. Многим
организациям будет удобнее автоматизировать сбор, построение графиков и
распространение метрик с помощью специализированных программ, баз
данных и веб-серверов. Но этот механизм не меняет природу самих метрик,
поэтому во всей книге используется табличный метод.
Таблицы, в которых описываются метрики для управления ИТ-услугами,
содержат следующие поля:
• Метрика — максимально простое описание метрики. Вслед за ним
приводятся в фигурных скобках {} используемые единицы.
• Описание — краткая характеристика метрики в дополнение к назва-
нию.
• Спецификация — краткое разъяснение, что и как измеряется.
• Обоснование — объяснение, чем полезна данная метрика и каково ее
значение.
Глава 8. СПЕЦИФИЧЕСКИЕ МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ 77
1
Центр получения прибыли — центр ответственности, для которого ведется обособленный
учет как затрат, так и доходов. Результаты его деятельности оцениваются на основе разно-
сти между доходами и расходами. — Прим. пер.
84 МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
1
Критический путь — самая длительная последовательность выполнения работ при реализа-
ции проекта, т. е. последовательность работ, показывающая минимально необходимое
время для завершения проекта. — Прим. пер.
9
Интеграция метрик
9.3. eTOM
Модель eTOM (enhanced Telecom Operations Map — расширенная карта
процессов телекоммуникационных компаний), используемая многими опе-
раторами связи как платформа предоставления услуг, основана на стандар-
тах управления сетями и концепции бизнес-процессов. Международная
ассоциация TeleManagement Forum выпустила множество документов с
описанием eTOM, а также подробную матрицу взаимосвязей между ITIL и
eTOM — соответствующий документ имеет шифр GB9211. Необходимо по-
нимать, что терминология, область действия и определения eTOM и ITIL
различаются, поэтому хотя ITIL и может использоваться для поддержки
1
http://www.tmforum.org/browse.asp?catID=2024&linkID=29248 — прямая ссылка на документ.
eTOM поддерживается на сайте www.tmforum.org. Зарегистрированные пользователи могут
скачать документ бесплатно, а незарегистрированные — за небольшую плату. — Прим. авт.
96 МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Таблица 9.1
Соответствие между eTOM и ITIL
eTOM ITIL
Управление качеством сервиса Доступность
Управление QoS (качеством обслуживания) / SLA для клиентов Уровень обслуживания
Обработка проблем Инцидент
Управление клиентским интерфейсом Служба Service Desk
Сервисная проблема / сбой в ресурсах Проблема
Конфигурирование и активация услуг / обеспечение услуг Конфигурация
ресурсами
9.4. COBIT
COBIT — это стандарт аудита, применяемый для проверки соответствия ИТ
действующему законодательству (например, закону Сарбейнса — Оксли).
Задачи контроля в COBIT хорошо согласуются с ITIL — при разработке стан-
дарта ITIL использовалась для определения категорий — и, как следствие,
с ISO20000.
Так же, как и в ITIL, отправной точкой COBIT является каталог услуг, на
основе которого оценивается качество сервиса. Показатели SLA и метрики
процессов дают подробную картину того, как контролируется управление
ИТ-услугами. Если компания применяет или планирует применять COBIT в
качестве механизма аудита, то при реализации управления ИТ-услугами ей
имеет смысл провести бенчмаркинг соответствующих процессов и их метрик,
используя в качестве эталона задачи контроля, определенные в COBIT. Тогда
для метрик, выбранных компанией, еще до внедрения будет гарантировано
соответствие требованиям аудита.
Рассмотрим высокоуровневые задачи контроля, относящиеся к монито-
рингу:
Глава 9. ИНТЕГРАЦИЯ МЕТРИК 97
M1 — мониторинг процессов;
M2 — оценка объективности внутреннего контроля;
M3 — получение независимых гарантий;
M4 — проведение независимого аудита.
Как видим, структура ISO20000 вполне с этим согласуется. Метрики, оп-
ределяемые и рассматриваемые в настоящей книге, непосредственно соот-
носятся с задачей M1.
Только что был приведен один из примеров соответствия между COBIT и
ITIL — подробному описанию этих соответствий (отвлекаясь от метрик)
посвящен ряд книг. Например, изданное нидерландским ITSM-форумом
(ITSMF-NL) «Управление ИТ — карманное руководство на основе COBIT»
(IT Governance — A Pocket Guide Based on COBIT) рекомендуется для следу-
ющего уровня детализации1.
Некоторые видели в COBIT замену ITIL, однако скорее здесь стоит гово-
рить о взаимодополнении. COBIT — в высшей степени стабильный метод
проектирования, и он приносит огромную пользу ИТ-аудиту. Лучше всего
рассматривать его как структуру поддержки аудиторов — наибольший вы-
игрыш дает проектирование метрик с учетом как аудита, так и операций.
Следует, впрочем, заметить, что в COBIT есть множество метрик, предна-
значенных для аудиторов, и с ними стоит ознакомиться, чтобы при проек-
тировании связывать новые метрики с уже существующими, обеспечивая
таким образом расширение процессов аудита.
1
На веб-сайте OGC есть интересная статья «Связывание COBIT, ITIL и ISO17799 во благо
бизнеса» (Aligning COBIT ®, ITIL® and ISO17799 for Business Benefit), адрес: http://www.itil.
co.uk/includes/ITIL-COBiT.pdf — Прим. авт.
98 МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
10.1. Мероприятия
Чтобы обеспечить успешное управление ИТ-услугами, под-
разделение должно заручиться поддержкой со стороны како-
го-либо представителя высшего руководства компании или,
в терминологии ITIL, «спонсора» (executive sponsor). Иначе
100 МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
1
В рамках текущего проекта по обновлению ITIL готовится переработанное издание этой
книги, которое будет называться «Реализация ITIL в малых масштабах» («ITIL small-scale
implementation»). — Прим. авт.
Глава 10. РЕАЛИЗАЦИЯ МЕТРИК 107
• работа может быть сезонной, тогда в определенное время года будут исполь-
зоваться малознакомые части ИТ-системы;
• может существовать проблема с предоставлением услуги, такие как:
— изменения, не протестированные должным образом;
— ПО, не синхронизированное с распределенной системой;
— сбой сети или компьютерной аппаратуры.
Как видим, метрики не независимы и интерпретировать их непросто; из того,
что показатель легко подсчитать, еще не следует, что он должен стать ключевым
в управлении ИТ-услугами.
Все метрики
Управление инцидентами
Управление изменениями
350
Управление релизами
Процент от целевого значения
Управление мощностями
150 Управление непрерывностью
предоставления ИТ-услуг
Управление доступностью
100
Программа по постоянному
улучшению услуг (SIP)
50 Метрики бизнес-перспективы
Управление безопасностью
0
Янв. Февр. Март Апр. Май Июнь Среднее Управление рисками
значение
Управление документацией
Месяц
Все метрики
Программа по постоянному
улучшению услуг
(SIP)
Управление документацией Управление операциями
Управление проблемами Управление релизами
Управление непрерывностью
предоставления ИТ-услуг Управление рисками
Целевое значение: 10
Возможные значения: 0–100
Миссия: служба Service Desk является единой точкой контакта для всех
звонков в ИТ-отдел. Она обеспечивает сфокусированное взаимодействие
пользователей и ИТ с тем, чтобы способствовать эффективному использо-
ванию ИТ-услуг, быстро восстанавливать их нормальное функционирова-
ние и предупреждать потенциальные сбои, давая советы пользователям.
Опасное значение: 15
Целевое значение: 5
Возможные значения: 0–100
Ограничения: Нет
Опасное значение: 20
Целевое значение: 10
Возможные значения: 999999
Ограничения: Нет
Опасное значение: 3
Целевое значение: 3
Возможные значения: 999999
Опасное значение: 0
Целевое значение: 0
Возможные значения: 999999
Опасное значение: 5
Целевое значение: 10
Возможные значения: 99999
Ограничения: Нет
Опасное значение: 90
Целевое значение: 95
Возможные значения: 999999
Опасное значение: 5
Целевое значение: 3
Возможные значения: 999999
Ограничения: Нет
Опасное значение: 80
Целевое значение: 85
Возможные значения: 0–100
Целевое значение: 10
Возможные значения: 999999
Целевое значение: 4
Возможные значения: 0–5
Целевое значение: 95
Возможные значения: 0–100
Целевое значение: 4
Возможные значения: 0–5
Целевое значение: 3
Возможные значения: 999999
Целевое значение: 4
Возможные значения: 0–5
Опасное значение: 60
Целевое значение: 75
Возможные значения: 0–100
Целевое значение: 3
Возможные значения: 0–100
Целевое значение: 5
Возможные значения: 999999
Ограничения: Нет
Опасное значение: 4
Целевое значение: 2
Возможные значения: 999999
Вводные курсы
• ИТ сервис-менеджмент. Вводный курс на основе ITIL (Foundations of
IT Service Management based on ITIL / IT Service Management, an
introduction — based on ITIL; на арабском, китайском, датском, не-
мецком, английском, французском, итальянском, японском, корей-
ском, голландском, португальском, русском и испанском языках)
• IT Servlces Procurement, an introduction based on ISPL (на английском и
голландском языках)
• Project Managemen based on Prince 2 (на голландском, английском и
немецком языках)
Kapманные руководства
• ISO/IEC20000, a pocket guide (на английском и немецком языках, преж-
нее название — BS15000 — a pocket guide)
• IT Services Procurement based on ISPL — a pocket guide (на английском
языке)
• IT Governance — a pocket guide based on COBIT (на английском и немец-
ком языках)
• IT Service CMM, a pocket guide (на английском языке)
• IT Service Management, een samenvatting (на голландском языке)
• IT Service Management from hell based on Not ITIL (на английском языке)
1
Настоящее издание.
Брукс Питер