Добавить в коллекции Добавить в сохраненное
  1. Бизнес
  2. Менеджмент
  3. Управление персоналом

Метрики для управления ИТ-услугами

реклама 
Питер Брукс
Метрики
для
управления
ИТ-услугами
Москв
а
2008
Оглавление
Предисловие к русскому изданию ....................................... 9
Введение ................................................................................ 11
1. Что такое метрики?.......................................................... 13
1.1.
1.2.
1.3.
1.4.
1.5.
Задачи ............................................................................... 13
Связь ИГ и бизнеса ............................................................... 14
Почему метрики — это не SLA .............................................. 20
Метрики и KPI ........................................................................ 21
Метрики и бенчмаркинг ......................................................22
2. Зачем нужны метрики? ................................................... 25
2.1.
2.2.
2.3.
2.4.
2.5.
Метрики как инструмент .....................................................26
Метрики как средство управления...................................... 27
Метрики и инновации ........................................................... 29
Затраты ................................................................................. 30
Преимущества метрик .......................................................... 31
3. Области применения метрик.......................................... 33
3.1. Структурные подразделения.............................................. 34
3.2. Процессы ............................................................................34
4. Для кого предназначены метрики ................................. 37
4.1. Руководство компании ......................................................... 38
4.2. Менеджеры процесса ........................................................... 39
б
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
5. Как использовать метрики ............................................ 43
5.1. Время .................................................................................... 43
5.2. Измерение ............................................................................ 43
6. Разработка метрик ............................................................ 49
6.1.
6.2.
6.4.
6.5.
6.6.
Зачем разрабатывать метрики ........................................... 49
Принципы .............................................................................. 50
Разработка отдельных метрик ........................................... 56
Разработка интегрированных наборов метрик................... 57
Примеры хороших и плохих метрик .................................... 58
7. Создание метрик на практике ........................................61
8. Специфические метрики для управления
ИТ-услугами ............................................................................75
9. Интеграция метрик ..........................................................93
10. Реализация метрик ......................................................... 99
11. Постоянное совершенствование
с помощью метрик ........................................................ 115
A. Метрики для управления инцидентами ...................... 119
B. Метрики службы Service Desk ...................................... 129
C. Метрики для управления конфигурациями ................. 139
D. Метрики для управления изменениями ...................... 145
E. Метрики для управления релизами ............................. 153
ЕЛ. Метрики для поддержки приложений ................................. 159
Е.2. Метрики для разработки приложений ................................ 163
F. Метрики для управления операциями/
инфраструктурой ИКТ.................................................... 169
G. Метрики для управления уровнем сервиса ................ 175
Н. Метрики для управления проблемами ........................ 183
I.
Метрики управления финансами для ИТ-услуг ........... 193
Оглавление
J.
7
Метрики для управления мощностями .........................199
К. Метрики управления непрерывностью
предоставления
ИТ-услуг (IT Service Continuity - ITSC) ............................. 207
L.
Метрики управления доступностью ............................... 215
М. Метрики для управления
информационной безопасностью ............................... 225
N. Метрики для бизнес-планирования .............................. 233
N.1. Управление взаимоотношениями с бизнесом .................. 235
N.2. Управление взаимоотношениями с поставщиками.......... 236
N.3. Управление поставкой услуг ............................................. 239
N.4. Планирование, анализ и развитие.................................... 241
N.5 Взаимодействие, обучение и информирование ................. 242
О. Метрики для постоянно действующей
программы по улучшению услуг (SIP) ........................ 245
Р.
Метрики для управления рисками .............................. 253
Q. Метрики для управления документацией ................... 261
R.
Метрики компетентности, осведомленности
и обучения (CAT)
............................................................................................... 26
7
S.
Метрики для управления программами
и проектами
............................................................................................... 27
5
О библиотеке изданий по управлению ИТ-услугами ....... 281
Предисловие
к русскому изданию
В настоящее время принципы управления уровнем сервиса уже
широко используются во всем мире и стали стандартом де-факто
для многих российских предприятий. Опыт компании IBS показывает,
что все чаще и чаще от задачи простой автоматизации приема
заявок от пользователей ИТ-службы переходят к полноценной
организации своих процессов, реальному выстраиванию отношений с
бизнес-подразделениями на сервисных принципах, повышению
качества услуг.
Однако необходимо учитывать известный факт — нельзя
улучшить то, что нельзя измерить!
Универсальное правило, применимое ко всем сферам
деятельности: обратная связь в различных процессах базируется на
результатах измерений. Деятельность ИТ-службы не является
исключением и также должна оцениваться объективными
измеряемыми параметрами. Вот только что это за параметры,
сколько их должно быть, как часто их измерять, каковы в общем
критерии выбора параметров оценки деятельности ИТ-службы?
Во-первых, они должны быть конкретными, а не абстрактными.
Во-вторых, их не должно быть очень много, но их количество должно
быть достаточным. В-третьих, их выбор должен основываться на
целях и задачах, стоящих перед всей компанией и перед ИТслужбой. В-четвертых, они должны быть для сотрудников
мотивирующим фактором, отражающим качество их деятельности.
Неоценимую помощь в непростом выборе таких показателей
окажет читателю эта замечательная книга, вышедшая в серии
«Библиотека IBS».
С одной стороны, это довольно подробный и обширный
справочник с перечнем метрик и детальными разъяснениями. С
другой стороны, это еще и руководство к действию с большим
количеством примеров из реальной деятельности. Книга «Метрики
для управления ИТ-услугами» не просто методическое пособие по
выбору метрик, она может служить источником полез-
10
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
ных идей. Хочется надеяться, что читатель не только ознакомится с
ней на этапе создания своей системы оценки, но и будет время от
времени возвращаться к ней, чтобы переосмыслить существующий
набор KPI, взглянуть на ситуацию с разных сторон и точек зрения.
Вас не должен пугать большой список метрик. Все их
контролировать сложно, да и не нужно. Достаточно определиться с
перечнем, актуальным для данной компании в данное время. Не
нужно ждать, когда определится идеальный набор метрик для
контроля, — его составить невозможно. Более того, набор метрик не
является постоянным. Время идет, меняется компания, меняются
цели («чтобы двигаться, надо бежать в два раза быстрее»), меняется набор KPI.
Но мы уже забегаем вперед, не будем пересказывать книгу...
Петр Дубенсков,
заместитель директора департамента системных
решений IBS
Введение
Организации,
предоставляющие
ИТ-услуги,
все
более
ориентируются в своей работе на стандарты качества и управления
ИТ-услугами. В числе наиболее популярных стандартов для
руководства — управление ИТ-услугами, качеством и различными
аспектами операционной деятельности.
В этой книге рассматривается разработка и внедрение метрик в
организациях,
занимающихся
предоставлением
услуг
и
применяющих один или несколько из перечисленных стандартов. В
качестве основы используется структура процессов ITIL, а также
многие принципы ITIL и ISO20000 (первоначально BS15000 в
Великобритании). Книга является общим руководством по
применению метрик в качестве контролирующего и направляющего
механизма для управления ИТ-услугами.
Внедрение управления ИТ-услугами как ряда строго определенных
и тесно взаимосвязанных процессов позволяет сформировать
целостный подход, охватывающий все множество дисциплин,
присутствующих в современном ИТ-отделе.
Тысячи компаний со всего мира взяли за образец этот целостный
подход, и результаты превзошли все ожидания. ITSMF — это
действующая во многих странах мира независимая организация по
поддержке управления ИТ-услугами. Она проводит разнообразную
работу по улучшению практического применения ITIL за счет обмена
знаниями и опытом. В рамках этой деятельности организуются
мероприятия и издаются книги.
Во всех описаниях процессов в ITIL есть раздел, посвященный
возможным метрикам, что дает превосходную основу для создания
системы показателей. Так, в томе ITIL, посвященном планированию
управления услугами (Planning to Implement Service Management),
есть глава, посвященная KPI (Key Performance Indicators,
ключевые показатели эффективности). В этом руководстве
рассматривается конкретно реализация метрик в контексте схемы
управления ИТ-услугами с особым упором на ITIL.
12
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Главной причиной для написания этой книги послужило неумение
многих организаций правильно использовать метрики. В этом
пособии вы найдете анализ трудностей, возникающих при
разработке метрик, и реальные решения.
Книга является общим руководством по проектированию,
внедрению и использованию метрик в качестве механизма,
контролирующего и направляющего управление ИТ-услугами. В ней
также содержатся конкретные рекомендации по применению метрик
для процессов ITIL, ISO20000 и других, обсуждается обоснование
этих рекомендаций. Это позволит организации внедрить метрики
непосредственно в том виде, в каком они здесь описаны, в качестве
первичного решения, а затем провести их бенчмаркинг путем
сравнения с показателями других организаций. Но можно
использовать предложенные решения и в качестве отправной
точки для модификации определенных метрик применительно к
своим требованиям.
Плохо спроектированные метрики могут активно мешать
правильному функционированию организации, а создать такой их
набор, который бы позволил избежать подводных камней и принести
реальную пользу, нелегко. Книга сделает эту работу более простой и
менее подверженной ошибкам.
Книга
предназначена
для
менеджеров,
управляющих
предоставлением ИТ-услуг, владельцев процессов, консультантов,
руководителей ИТ-подразде-лений и всех тех, кто интересуется
метриками для управления ИТ-услугами.
В команду рецензентов вошли эксперты со всего мира. Их
многолетний коллективный опыт работы в сфере ИТ и
предоставления услуг значительно обогатил эту книгу. Вы можете
полагаться на нее как на руководство, обобщающее лучший опыт в
данной области.
1
Что такое метрики?
Метрика — просто другое название меры. В
информационных технологиях (ИТ) этот термин приобрел
несколько различных более конкретных смыслов. И хотя
эта книга посвящена метрикам как таковым, важно
помнить, почему мы ими пользуемся. Измерение ради
измерения — дорогая и бессмысленная забава, и метрики
— не самоцель, а важная часть системы управления,
направляющей
и
контролирующей
работу
ИТподразделения. Они, как мы впоследствии убедимся,
должны
разрабатываться
согласно
требованиям
клиентов и тестироваться на предмет возможности
реализации, а для выработанных параметров необходим
мониторинг, позволяющий контролировать их соответствие заданным пороговым значениям и исправлять
возникающие проблемы. Создание метрик — одна из задач
программы
непрерывного
улучшения
качества
обслуживания
(Continuous
Service
Improvement
Programme
—
SIP):
по
мере
постепенного
совершенствования процессов и служб должны меняться
и метрики для их оценки. Важно понимать, какие задачи
ставит перед собой бизнес, и согласовывать с ними
процессы измерения, мониторинга и контроля. А о том,
как это сделать, рассказывается в первой главе.
1.1. Задачи
Цели или задачи использования метрик в управлении ИТуслуга-ми (IT Service Management — ITSM) таковы.
1. Согласовывать деятельность ИТ-подразделения
с задачами бизнеса:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
14
• обеспечить учет ИТ-процессов и результатов ИТ-операций;
• информировать участников бизнеса о процессах ITSM;
• помогать участникам бизнеса разобраться в вопросах
производитель
ности и специфических сложностях ИТ.
2. Добиваться соответствия требованиям, предъявляемым к
коммер
ческим операциям:
• стратегически направлять ИТ-операции;
• помогать в прохождении аттестации по стандартам
ISO200001,
COBIT2 и др.;
• определять критические факторы успеха (Critical Success
Factors —
CSF), см. в разделах 1.3 и 10.2;
• максимизировать непрерывность бизнеса.
3. Стратегически направлять работу по совершенствованию
ИТ-опе
раций:
• оценивать производительность ИТ-подразделения и его
процессов;
• контролировать процессы ITSM;
• обеспечить тактическое управление работой ИТорганизации;
• максимально повышать производительность и
результативность
работы ИТ-организации;
« обосновать оценку вклада ИТ-организации в бизнес в целом.
Одним словом, необходимо придать нужное направление
измерениям, относящимся к определенной предметной области.
1.2. Связь ИТ и бизнеса
Библиотека ITIL3 предназначена для согласования работы ИТорганизации с потребностями предприятия. Она и другие
инициативы в области управления качеством (такие, как COBIT или
Six Sigma4) направлены на понима1
ISO (International Organization for Standardization) — международная организация
по стан
дартизации. Стандарт ISO 2000 (ISO 9001:2000) определяет требования к
системам управ
ления качеством. — Прим. пер.
2
COBIT (Control Objectives for Information and Related Technology) — контрольные
объекты
для информационных и смежных технологий, масштабная научноисследовательская рабо
та, направленная на разработку согласованного набора международных
стандартов для
управления, контроля и аудита ИС, которые могут быть применены для ИС
масштаба пред
приятия. — Прим. пер.
3
ITIL (IT Infrastructure Library) — библиотека, содержащая рекомендации и решения
для соз
дания инфраструктуры корпоративных систем. — Прим. пер.
4
Six Sigma — структурированная методология, опирающаяся на сочетание
статистических
методов контроля качества, методов анализа данных, систем повышения
квалификации и
направленная на устранение дефектов, снижение отходов и решение проблем
контроля
качества. — Прим. пер.
Глава 1. ЧТО ТАКОЕ МЕТРИКИ?
15
ние целей бизнеса, потребностей различных заинтересованных
сторон и роли ИТ-организации, заключающейся в том, чтобы
помогать бизнесу в достижении поставленных целей и
предоставлять его участникам нужные услуги.
1.2.1. Метрики как управленческая информация
Руководство компании должно понимать, насколько успешно
функционируют ее бизнес-процессы. ИТ-организация помогает ему
в этом тремя способами.
Во-первых, в настоящее время ИТ-подразделения отвечают за
бухгалтерское, логистическое и иное прямое обслуживание бизнеспроцессов. Соответственно, метрики включаются в управленческие
отчеты для различных бизнес-подразделений — например, в отчет о
продажах, генерируемый системой SAP для отдела продаж.
Во-вторых, ИТ-подразделения обслуживают бизнес-процессы,
внесенные
в
каталог
услуг
(Service
Catalogue).
Детали
предоставления
соответствующих
услуг
регламентируются
различными соглашениями об уровне сервиса (Service Level
Agreements — SLA), которые заключаются между менеджером по
уровню сервиса и бизнес-пользователями. В этом случае метрики
появляются в отчетах об отклонениях от ключевых показателей
эффективности (Key Performance Indicators — KPI), зафиксированных
в SLA. По таким отчетам можно проследить, как повышается
способность ИТ-организации к обеспечению высокого стандарта
обслуживания.
В-третьих, важны бизнес-процессы самого ИТ-подразделения:
чрезвычайный план1 для бизнеса без раздела, посвященного ИТсервисам, — большая редкость! Таким образом, отчеты ИТподразделения о выполнении его собственных процессов составляют
часть управленческой информации, необходимой бизнесу. Метрики,
используемые в этих отчетах и предназначенные для оценки
функционирования процесов, — основной предмет обсуждения в
данной книге.
Однако
к
коммерческой
информации
неприменимы
детализированные технические метрики. Скорее можно представить
сжатые результаты оценки ИТ-процессов в терминах бизнеса. Какникак, показатели бизнеса являются денежными, так что в конечном
итоге задача ИТ-подразделения заключается в обеспечении
хорошей окупаемости инвестиций (Return on Investment— ROI),
доходности используемого капитала (Return on Capital Employed —
ROCE), экономической добавленной стоимости (Economic Value Added
— EVA) и т. п.
1
Чрезвычайный план — предопределенный план действий в аварийных ситуациях,
включающий процедуры резервного копирования и подготовку резервного
оборудования для преодоления чрезвычайной ситуации. — Прим. пер.
16
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Но это может быть сделано не раньше, чем достигнет высокого
уровня зрелости финансовое управление ИТ-организацией (IT
Financial Management в терминах ITIL). До того наиболее полную
картину ИТ-услуг для бизнеса дают оценка эффективности процесса,
а также KPI в сопоставлении с SLA.
Когда четкие и значимые метрики разработаны, важно
правильно их представить. Ниже рассматриваются различные
способы, такие как система сбалансированных показателей
(balanced scorecard — BSC), «светофор» и «приборная панель».
Разным аудиториям соответствуют разные методы отчетности и
наборы метрик. Важную роль играют и названия метрик — они
вносят ясность в ситуации, когда метрика меняется от одного
отчетного периода к другому.
Если
процессы
реализованы
без
необходимой
последовательности и повторяемости, метрики для них будут
ненадежными. Как подчеркивается в стандарте ISO 20000, для того
чтобы метрики давали полезные оценки, очень важно иметь
устойчивую и достаточно зрелую систему управления, а также
поддерживать управление процессами как составную часть способа
работы организации.
1.2.2. Метрики для управленческого контроля
Когда в бизнесе что-то измеряется, особенно когда ответственность
за измерение возлагается на какого-либо менеджера или группу
сотрудников, поведение тех, кого измеряют, меняется.
Если метрики разработаны правильно и их задачи отвечают
требованиям бизнеса, поведение также будет меняться в сторону
соответствия этим требованиям. Другими словами, правильно
разработанная метрика в сочетании с адекватно реализованной
процедурой измерения представляет собой метод контроля. Если же
она плохо продумана, расходится с реальными требованиями
бизнеса, либо измерения по ней проводятся неправильно, подобный
«контроль» может спровоцировать совершенно противоположное
поведение и повредить бизнесу.
Есть множество подобных примеров, но чтобы показать, в чем здесь проблема,
хватит и одного, В Великобритании правительство решило, что время, в течение
которого пациент должен ждать операции, было бы полезной метрикой. Соответственно была поставлена цель сократить списки ожидания. Результатом стало точное
выполнение запроса правительства — списки ожидания действительно стали короче. Тем не менее фактически пациенты ждали операции ровно столько же, сколько
и раньше — просто администраторы больниц не позволяли записывать их в очередь
до тех пор, пока операция не оказывалась назначенной в пределах заданного срока
ожидания. Таким образом формировался другой, неофициальный список ожидания, куда вносились те, кто ждал допуска в основной список!
Глава 1. ЧТО ТАКОЕ МЕТРИКИ?
17
Этот пример удачен по ряду причин. Во-первых, он показывает
изобретательность людей и их склонность делать в точности то, о чем
их просят и что будет оцениваться, а не то, что действительно нужно,
следовать скорее букве, чем духу закона. Во-вторых, из него видно, что
нужно оценивать реально важные параметры. В данном случае
оценивался список ожидания. Однако было бы правильнее, хотя,
возможно, и сложнее, оценить интервал между датой направления
на операцию и датой самой операции. Поэтому очень важно
разрабатывать адекватные метрики. Последняя проблема состояла в
том, что сам процесс не подвергался оценке, поэтому когда
администраторы больниц изобрели новый процесс (неофициальный
список ожидания для тех, кто хочет попасть в основной список),
правительственные аудиторы этого не увидели.
Другой проблемой, с которой сталкивались многие компании,
является неопределенность. Если метрики плохо спроектированы,
конечно же, их необходимо изменить. Но если менять их без
тщательной разработки, только чтобы решить неотложную
проблему, новые метрики могут оказаться ничем не лучше старых.
Это означает, что их придется снова менять. Если метрики меняются
каждые несколько месяцев, сотрудникам нет смысла работать для
достижения заданных показателей. Люди быстро понимают, что им
нужно лишь дождаться очередного изменения, а потом начнется
новый период неопределенности, где не будет эффективных метрик,
а значит, и эффективного управленческого контроля. Воздействие,
которое оказывает на организацию постоянное изменение метрик,
похоже, вреднее, чем их полное отсутствие.
Мы рады работать для цели, которая представляется нам
достижимой, и работаем эффективнее, когда нас хвалят, а иногда и
награждают за хорошо выполненное задание. Если нас просят о
невозможном, мы знаем, что нас могут разве что обвинить в
неспособности справиться с порученным делом. Естественная
человеческая реакция — сдаться и просто имитировать попытки. При
разработке метрик следите за тем, чтобы показатели воспринимались
как достижимые и имели смысл для бизнеса, — только при этом
условии поведение сможет измениться в положительную сторону.
Из сказанного следует, что необходимо устанавливать
реалистичные метрики и поощрять сотрудников, которые достигают
заданных показателей и превышают их.
Различные процессуальные метрики позволяют ИТ-организации в
целом оценивать эффективность работы своих менеджеров по
обеспечению, улучшению и поддержанию качества обслуживания в
рамках их сфер ответственности.
1.2.3. Интеграция и представление метрик
Метрики включают мелкие показатели технического характера.
Этого не избежать. Но после того, как ключевые метрики
сформированы, детали
18
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
можно вывести на «светофор» или «приборную панель», которые
мы подробнее рассмотрим в главе 7. Подобный подход дает
возможность вникнуть в детали, когда проблема на высшем уровне
является изолированной.
Если метрики для разных процессов разрабатываются
аналогичным образом, такие процессы можно сравнить. Хотя
управление изменениями существенно отличается от управления
доступностью, одинаково структурированные интегрированные
метрики позволяют сопоставить эти процессы с точки зрения
управления ими, их зрелости и эффективности, особенно если
имеются точные показатели удовлетворенности клиентов (т.е. тех
людей, для которых в первую очередь предназначен процесс).
Например, если для управления доступностью взвешенная оценка
составляет 8,5 балла по десяти метрикам, а для управления
изменениями — 10,8 балла, можно сделать вывод, что в первом
случае процессы контролируются хуже, чем во втором, несмотря на
то, что сами процессы различны.
Как определяются взвешенные оценки и каков их смысл, мы
рассмотрим в главе 7.
1.2.4. Метрики и участники бизнеса
Коммуникация является неотъемлемой частью ITSM. Если
заинтересованные стороны получают информацию о показателях
бизнеса, они могут внести свой вклад в успех предприятия,
поддерживая открытость и прозрачность, отмечая улучшения. Ниже
для различных участников бизнеса будут рассмотрены потребности
и место в схеме взаимоотношений с клиентами (рис. 6.1).
За счет коммуникации обеспечивается передача самих метрик, их
результатов и смысла этих результатов с точки зрения
предоставления услуг заинтересованным сторонам. Важно, чтобы
последние стали частью определения задач ИТ-организации и
получали удовлетворение от результатов своего активного
участия.
Коммуникация — двусторонняя деятельность, поэтому важно
объединять требования различных участников бизнеса и постоянно
вовлекать их всех в работу по улучшению качества предоставления
услуг и совершенствованию процессов. Понадобится также
тщательно разработанный коммуникационный план, к созданию и
оценке которого следует привлечь разные заинтересованные
стороны.
Клиент
В данной книге, используя слово «клиент», мы имеем в виду
покупателя услуги, независимо от того, является ли она внутренней
или внешней. В этом разделе речь идет о конечном потребителе,
для
которого
должна
осуществляться
вся
деятельность
предприятия. ИТ-организация выполняет вспомо-
Глава 1. ЧТО ТАКОЕ МЕТРИКИ?
19
гательную функцию для бизнес-процессов, но иногда ее вклад
распространяется и на прямых клиентов компании (конечных
потребителей).
В подобных случаях, чтобы удостовериться в эффективности этого
вклада, компания должна оценить удовлетворенность всех прямых
клиентов. Однако к использованию подобных оценок нужно
подходить аккуратно. Если проводить опросы потребителей слишком
часто, сама эта деятельность станет для них раздражающим
фактором, если же интересоваться их мнением недостаточно часто,
есть опасность с опозданием узнать о тех или иных инцидентах, что
также может отрицательно повлиять на степень удовлетворенности.
Пользователь
Поскольку пользователи не участвуют в переговорах об условиях
обслуживания и не оплачивают его, они не являются прямыми
покупателями ИТ. Тем не менее это участники бизнеса, и их
удовлетворенность жизненно важна. Если пользователи недовольны
тем, что им предоставляются услуги низкого качества, подобного
мнения станут придерживаться и клиенты.
Сотрудник
Сотрудники ИТ-подразделения отвечают за функционирование
процессов обслуживания. В свою очередь, ИТ-подразделение может
обеспечить своему персоналу хорошие условия работы,
справедливую оценку и вознаграждение. Если сотрудники не
удовлетворены, предоставляемый ими уровень обслуживания
снижается вне зависимости от качества разработанных метрик.
Поэтому руководители ИТ-подразделений обязаны оценивать
моральное состояние своих подчиненных и реагировать на
изменения, которые могут оказать на него негативное воздействие.
Сотрудникам больше нравится, когда они ощущают, что их
признают участниками бизнеса. Важно также, чтобы они могли
отождествлять себя с работодателем, положительно относясь к
компании и одобряя ее процессы. Четкие и открытые метрики
позволяют им понимать, в каких областях подразделение
функционирует успешно, а где требуются дополнительные усилия.
Эффективная коммуникация помогает сотрудникам своевременно
реагировать на проблемы и находить вдохновение для дальнейшей
деятельности.
Правление
Как участники бизнеса, высшие менеджеры и правление компании
испытывают
специфическую
потребность.
В
интересах
процветания бизнеса их необходимо заранее предупреждать обо
всех потенциально серьезных инцидентах, чтобы можно было срочно
предпринять корректирующие действия. Открытая и прозрачная
коммуникация с правлением в состоянии помочь
20
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
выявлению этих инцидентов до того, как они перерастут в
непоправимые трудности.
Для правления важны и хорошие новости. Их можно
распространять как внутри, так и за пределами компании с целью
улучшения ее репутации. Так, например, аттестация по стандарту
ISO20000 — прекрасный повод с гордостью заявить об этом
достижении.
Другие заинтересованные стороны: правительство и акционеры
Несмотря на то что правительство и акционеры важны для
компании, ответственность за общение с ними несет правление. Если
у ИТ-подразделения есть информация, способная их успокоить или,
наоборот, о чем-то предупредить, эти данные необходимо сначала
передать правлению, и уже оно выберет подходящий канал и
способ коммуникации.
1.3. Почему метрики — это не SLA
Соглашение между бизнес-организацией, клиентом и ИТподразделением составляется менеджером по уровню сервиса.
Результатом этой работы является набор так называемых
соглашений об уровне сервиса (Service Level Agreements — SLA), и
SLA определяют, какое качество обслуживания готова предоставить
ИТ-организация.
Менеджер по уровню сервиса использует SLA для составления
соглашений об уровнях операционной поддержки (Operational Level
Agreements — OLA), а при наличии внешних поставщиков — также
договоров с ними, называемых Underpinning Contracts (UC).
Критические факторы успеха (Critical Success Factors — CSF) для
ИТ при взгляде снизу вверх определяются соглашениями OLA: если
OLA выполнено, то (при условии хорошего соответствия) будет
обеспечен и нужный CSF. В действительности OLA производны от
SLA, которые, в свою очередь, опираются на CSF и, следовательно, у
CSF охват шире, чем у любого отдельного OLA. Впрочем, члены
организации могут рассматривать CSF как цель OLA.
Перейдем к CSF. Это критерии, которым должно удовлетворять
предоставление услуги, чтобы выполнялось SLA. Каждый CSF можно
затем использовать
для
расчета
ключевого
показателя
эффективности (Key Performance Indicator— KPI), характеризующего
степень, в которой обеспечивается CSF.
Таким образом, вся цепочка
вытекает непосредственно из требований клиента, и KPI может быть
измерен, а полученные результаты доложены клиенту, чтобы
продемонстриро-
Глава 1. ЧТО ТАКОЕ МЕТРИКИ?
21
вать, насколько эффективно ИТ-организация обеспечивает
оговоренный уровень сервиса.
1.4. Метрики и KPI
Как мы видели выше, KPI обеспечивают метрику, предназначенную
для клиента и характеризующую успех в выполнении заключенного с
ним SLA.
Данная оценка позволяет руководителям ИТ-подразделения
ежемесячно узнавать, хорошо ли оно работает. Однако это слишком
поздно, чтобы что-либо предпринять. Указатель уровня топлива,
который сообщает, что бензобак пуст, мало на что годится: нужен
такой, чтобы показывал, насколько бак полон, тогда можно будет
дозаправиться, прежде чем это станет проблемой.
Точно так же ИТ-руководство должно располагать критериями,
характеризующими работу организации на ежедневной или
еженедельной основе и позволяющими вносить исправления,
прежде чем будет нарушено SLA.
Именно здесь на сцену выходят процессные метрики. В подходе
ITIL к ITSM предоставление услуг определяется в терминах
обслуживания клиентов. Именно поэтому KPI являются подходящей
метрикой для предоставления услуг. Однако кроме того ITIL
определяет функционирование различных частей ИТ в терминах
процессов, каждый из которых можно рассматривать как механизм,
принимающий нечто на входе и преобразующий его в нечто на
выходе (рис. 1.1).
На схеме показано движение процесса между организациями
и/или состояниями процесса, а также вклад в метрики на разных
участках. Отражены также связи между этим процессом и
участниками бизнеса, как внутрифирменными, так и внешними.
Темно-серым цветом показаны процессы и организации, внутренние
по отношению к ИТ, бледно-серым — внешние связи и организации.
Как видим, чтобы владелец процесса мог контролировать его
работу, для процесса определяются KPI. Они измеряются
ежедневно или ежечасно, а триггеры, связанные с пороговыми
значениями, инициируют передачу информации наверх для
выполнения корректирующих действий.
Однако для каждого процесса, связанного с другими ITILпроцессами, должны быть выработаны метрики, которые можно
представить руководству ИТ и другим участникам бизнеса для
сравнения работы различных ИТ-про-цессов. Их тщательный отбор
и аккуратное измерение, как было показано, обеспечивают
управление самим процессом, оценку владельца процесса и, при
необходимости, членов команды. Эти метрики содержат некоторые
KPI, используемые владельцем процесса — впрочем, он, вероятно,
будет применять более обширный набор параметров, чтобы
получить много деталей, относящихся к повседневным изменениям
в процессе и полезных для практического управления им.
22
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Рис. 1.1. Схема общего процесса
1.5. Метрики и бенчмаркинг1
В длительной перспективе можно сравнивать текущие метрики с
результатами за предыдущие месяцы или годы. Эти сравнения
полезны для постановки задач повышения производительности.
Здесь имеются две проблемы. Во-первых, при введении метрик
непонятно, каким мог бы быть приемлемый или идеальный уровень
производительности. Чтобы его задать, нужно выработать какой-то
начальный базовый уровень, или «точку отсчета» (benchmark). Это
часто делается путем выполнения измерений для двух или трех
периодов времени, после чего полученные значения берутся в
качестве точки отсчета, соответствующей минимальным требованиям.
Вторая проблема заключается в том, что нужно знать, как
заданная точка отсчета соотносится с другими организациями. Если
метрики установлены
1
Бенчмаркинг — процесс поиска новых и более совершенных процедур,
осуществляемый путем сравнения собственных процедур с наилучшими из тех,
которые используют другие — Прим пер
Глава 1. ЧТО ТАКОЕ МЕТРИКИ?
23
только для вашей организации, ответить на этот вопрос невозможно!
Кроме вас, вашими метриками никто не пользуется, поэтому нужно
самостоятельно определить допустимые значения.
Существуют два подхода к решению данной проблемы. Некоторые
исследовательские организации создали перечни стандартных
метрик, где приводятся средние результаты для многих фирм.
Воспользовавшись теми же стандартными метриками, можно
определить уровень организации относительно среднего.
Другой подход состоит в использовании либо стандартного
набора метрик, либо модифицированного, как в настоящей книге.
Тогда вы сможете непосредственно сравнить собственные метрики
с другими организациями, применяющими те же самые или очень
похожие критерии.
Возможен также смешанный подход. Если вы реализовали
собственные метрики, а кроме того проводите измерения в
соответствии с двумя-тремя опубликованными исследовательскими
критериями, то сравнение последних с точкой отсчета поможет
увидеть вашу организацию со стороны и оценить эффективность
процессов.
Если, к примеру, согласно исследовательским
метрикам показатели
вашей организации составляют 95 и 115% oт среднего вы можете пропорционально установить
для других метрик требуемые значения, попадающие в тот же диапазон. В будущем,
когда ваши показатели составят 120-130% от установленного контрольного
значения, можно будет обоснованно предположить, что вы находитесь примерно на этом
уровне относительно организаций, служивших точкой отсчета.
к
метрикам показатели вашей организации составляют 95 и 115% or
вы можете пропорционально установить
для других метрик требуемые значения,
в тот же диапазон. В будущем,
когда ним
составят 120-130% от установленного контрольного значения, можно будет обоснованно предположить, что вы находитесь примерно на этом
уровне относительно организаций, служивших точкой отсчета.
Метод, описанный в данной книге, — применение более или
менее стандартного набора метрик во всех процессах — допускает
и третий подход. Можно сравнивать процессы между собой. Как
правило, внедрение ITIL происходит поэтапно, поэтому если
взвешенные цели прочно установившегося процесса — например,
управления изменениями, — достигаются в среднем на 130%, то
можно задать первоначальную точку отсчета для нового процесса, так
чтобы средневзвешенный результат составил, скажем, 80%. Это позволит затем оценивать совершенствование процессов и определять,
сколько времени требуется процессу, чтобы сравняться с уровнем
управления изменениями.
_____________________________
2
Зачем нужны
метрики?
Чеширский Мурлыка...—заговорила Алиса несмело, — она
не знала,
понравится ли ему такое обращение. Кот в ответ
улыбнулся еще шире. «Значит, не сердится»,— подумала
Алиса и продолжала:
— Скажите, пожалуйста, куда мне отсюда идти?
— Это во многом зависит от того, куда ты хочешь прий
ти, — ответил Кот.
— Да мне почти все равно, — начала Алиса.
— Тогда все равно, куда идти, — сказал Кот.
— Лишь бы попасть куда-нибудь, — пояснила Алиса.
— We беспокойся, куда-нибудь ты обязательно попадешь, —
сказал Кот, — конечно, если не остановишься на полпути.
Льюис Кэрролл. «Алиса в Стране Чудес»1
Каждый день во многих наших делах мы полагаемся
на метрики, даже не задумываясь об этом. Очень важно
держать их в поле зрения, иначе есть опасность
окончательно потерять ориентиры. Если вы знаете, к
чему стремитесь, то можете определить, за чем
необходимо следить, чтобы оценить свое продвижение к
цели. Правда, получив в распоряжение механизм со множеством различных инструментов, легко поддаться
соблазну и увлечься инструментами вместо той работы,
для которой предназначен механизм.
1
Перевод Бориса Заходера.
26
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Если же нам, как Алисе, все равно, куда идти, то совершенно не
важно, что мы измеряем. Даже вообще не оценивая свое
продвижение, мы все равно куда-нибудь попадем. Но скорее всего
не туда, куда нужно!
2.1. Метрики как инструмент
Спидометр автомобиля или самолета является наглядным
примером использования метрик: он дает нам меру того,
насколько быстро движется водитель или пилот. Зная его
показания и предельную скорость, человек всегда будет
осведомлен о том, что перемещается слишком быстро и, следовательно, должен притормозить или сбросить газ.
Однако в подобных измерениях не было никакой необходимости
до появления быстрых автомобилей и радаров, контролирующих
скорость движения. Чтобы оценить быстроту езды, вполне хватало
развевающихся на ветру волос и заносов на поворотах.
Намного более важным измерительным инструментом с самых
ранних пор был указатель расхода топлива, особенно в самолетах.
Если в автомобиле кончится бензин, вам придется либо пройтись,
либо, если вы подготовились заранее, наполнить бак из
запасной канистры (что опасно). В самолете выбора нет вообще,
поэтому точный индикатор топлива еще нужнее.
На языке метрик запас топлива, достаточный, чтобы добраться до
пункта назначения, — это критический фактор успеха (CSF), а
инструменты (метрики) для его оценки — ключевые показатели
эффективности (KPI). Их число должно быть умеренным, иначе вы
не сможете сосредоточиться на вождении или пилотировании. Так
что указатель расхода топлива, как уже было сказано, — вероятно,
ваш главный KPI.
Вторым, не сильно отстающим по значимости, будет индикатор
уровня масла, потому что при низких значениях этот уровня
двигатель может заклинить. Однако в наше время эти инструменты
хотя и важны, но обычно настолько надежны, что нам хватает их
одних, чтобы узнать, когда следует дозаправиться и когда возникнет
опасность перегрева.
С помощью этих метрик легко понять, как работает модель
процесса. Представьте себе спидометр. Входные данные поступают
с датчика на колесе. Выходные данные — это показания стрелки на
табло. За промежуточные операции или сам процесс отвечает
зубчатая передача (или электронная схема) в спидометре,
преобразующая входную информацию с датчика — период одного
оборота — в выходные данные — скорость.
Целевой уровень, т. е. значение, которого мы хотим добиться, не
является постоянной величиной. К примеру, он будет разным на
автомагистрали и на сельской дороге, значение, оптимальное с
точки зрения возможностей двигателя, может оказаться
неприемлемым из-за действующих ограничений скорости и т. д.
Глава 2. ЗАЧЕМ НУЖНЫ МЕТРИКИ?
27
Спидометр и одометр (счетчик расстояния) менее существенны
для функционирования транспортного средства, зато важнее для
поездки. Зная расстояние и назначенное время прибытия, мы в
состоянии регулировать скорость в зависимости от пройденной
дистанции. Если в запасе много времени, можно даже делать
остановки, чтобы, отдохнув, более внимательно (а значит, безопасно)
вести машину.
При всем при этом совершенно не исключено, что нашим KPI, т. е.
действительно решающим фактором в вопросе о том, прибудем мы
вовремя или нет, является способность правильно прочитать карту
или воспользоваться сотовым телефоном, чтобы с помощью
местных ориентиров и советов тех, к кому мы едем, проехать
последние километры пути. Поскольку эти умения не оснащены
измерительными приборами (разве что в автомобиле есть GPS), их
трудно оценивать, пока дела не пойдут из рук вон плохо. Помните о
данном обстоятельстве при работе с ИТ-метриками.
2.2. Метрики как средство управления
За управление автомобилем отвечают руль, педаль газа, тормоза
и рычаг коробки передач. Они позволяют водителю, реагируя на
ежеминутные изменения дорожного покрытия, неожиданные
опасности и другие случайности, контролировать машину.
Аналогичным образом происходит повседневное управление в
компании, или так называемый микроменеджмент, когда уделяется
слишком много внимания мелким деталям. Это не значит, что детали
несущественны: если вы наедете на бревно и проколете шину,
время поездки наверняка увеличится.
Реальный долгосрочный контроль — как все на свете — является
результатом хорошего планирования. Тщательно отобранные
метрики в сочетании с правильным управлением стимулируют
выполнение правильно определенных действий, повышающих
вероятность своевременного прибытия в конечный пункт. Частота
технического обслуживания машины — метрика очень долгосрочная,
но важная.
Грамотное планирование и чтение карты гарантируют, что вам
не придется мчаться на максимальной скорости, нарушая
правила, закладывая крутые виражи и резко тормозя. Такие
действия позволят вам добраться до нужного места, но
одновременно увеличат риск и сделают поездку некомфортной для
пассажиров. В следующий раз они, возможно, предпочтут поехать на
поезде!
Некоторые инструменты, к примеру счетчик оборотов, не кажутся
чем-то представляющим непосредственную ценность, в некоторых
автомобилях их вообще нет. Но опытный водитель может
воспользоваться таким прибором, чтобы добиться оптимальной
скорости, не сильно изнашивая двигатель. При проведении
авторалли можно было бы присуждать участникам очки за то, что
счетчик оборотов у них никогда не зашкаливает и они проезжают
дис-
28
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
танцию за кратчайшее время при минимальном расходе топлива.
Для этого нужно отлично водить, планировать и ориентироваться.
Это длинное рассуждение полностью применимо и к ИТ-метрикам.
В ИТ существует ряд KPI, которые настолько важны, что непременно
должны контролироваться — подобно тому, как в машине необходим
точный указатель расхода топлива. Для других метрик трудно
собирать данные, и они, как счетчик оборотов, могут понадобиться
только сложным и зрелым ИТ-орга-низациям для достижения
оптимальной эффективности. Между тем большинству ИТподразделений будет очень выгодно использовать метрики для
контроля своей деятельности, чтобы их жизнь не состояла лишь из
тушения пожаров, крутых поворотов и экстренного торможения,
чтобы и бизнес, и ИТ чувствовали себя достаточно комфортно и
могли работать с полной отдачей без ненужного перенапряжения.
Важно помнить, что для достижения результата одного измерения
недостаточно — нужно еще и управлять деятельностью в
соответствии с метрикой: хорошо спроектированный спидометр не
заставит вас соблюдать ограничение скорости!
Минцберг
выделил
пять
методов
координирования
организационной работы. Можно провести аналогию между ними и
вождением автомобиля (табл. 2.1).
Таблица. 2.1
Пять методов координирования организационных мероприятий и
их аналоги при вождении автомобиля (по Минцбергу)
Аналогия при вождении автомобиля
Прямое руководство
Начальник поручает водителю доставить пакет клиенту
сегодня к 17:00.
Подстраивание друг под друга
Водители планируют свои перерывы, чтобы все автобусы
не оказались оставленными одновременно
Стандартизация методов работы
Водителей учат действовать в соответствии с заранее
определенной процедурой
Стандартизация результатов
Водители прибывают в пункт назначения с отклонением
от графика в пределах десяти минут
Стандартизация возможностей
Водители имеют высшую категорию
В таблице фигурируют различные способы запроса желаемых
результатов. Некоторые из них опираются на уже существующие
метрики — например, проверка того, что у всех водителей высшая
категория. Другие создаются для конкретного случая и должны
документироваться отдельно.
В управлении ИТ многое из того, что происходит сегодня,
относится к уровню «прямое руководство». С распространением ITIL
появилась
возможность
вводить
метрики,
позволяющие
специалистам с соответствующей
Глава 2. ЗАЧЕМ НУЖНЫ МЕТРИКИ?
29
квалификацией реализовывать стандартизованные процессы со
стандартными метриками. Как показано в ISO20000, эти приемы
работают только в составе единой системы управления.
2.3. Метрики и инновации
Метрики работают, только если существует процесс, который
необходимо оценить. При отсутствии процесса измерение не
позволит выявить в нем проблемные места и найти правильный
способ улучшения ситуации.
Критика в адрес использования метрик часто исходит от тех, кому в
действительности не нравятся не сами метрики, а процессы. Этот
вопрос мы подробнее рассмотрим в разделе 10.3.1, посвященном
сопротивлению изменениям. Здесь же стоит отметить, что люди
легко соглашаются работать в соответствии с определенным
процессом, а потом продолжают делать все в точности также, как и
раньше, если только нет соответствующих процессных метрик,
которые быстро покажут, что процесс не работает.
Руководители, считающие, что внедрили какие-либо процессы, и
обнаружившие, что те не приносят особой пользы, могут заметить,
что с введением процессных метрик ничего на самом деле не
изменилось. По этой и другим уже упоминавшимся причинам имеет
смысл запускать метрики одновременно с процессами, о чем часто
забывают.
Против процессов и, как следствие, метрик протестуют по
нескольким мотивам. Один заключается просто в том, что введение
процесса является изменением (а большинство из нас не
приветствует изменений). Второй — работа становится скучной, так
как всякий раз должна выполняться строго определенным способом.
Многим не нравится, что измерение количественных показателей
процесса ставит сотрудников под удар критики и может угрожать их
дальнейшему пребыванию в должности.
Во всех этих возражениях есть доля правды, особенно если
причина внедрения процессов недостаточно хорошо изложена.
Здесь уместна следующая аналогия. Езда на велосипеде — это
процесс. Обучившись ей, — а те, кто это сделал, помнят, как
поначалу вихляли, боялись упасть и разбивали коленки, — мы
больше не думаем о деталях. На самом деле замечено, что если
слишком задумываться о том, что именно делаешь, когда едешь, то с
большой вероятностью упадешь. Важно, что теперь можно
сосредоточиться на цели путешествия, видах и удовольствии от пребывания на свежем воздухе. Если мы так и не превратим езду на
велосипеде в хорошо знакомый процесс, то будем обречены всегда
испытывать трудности, падать и ездить без удовольствия. Вряд ли мы
совершим много путешествий, а уж дальних наверняка окажется
мало.
Точно так же обстоит дело с ITSM и с бизнес-процессами. Когда они
внедрены и работают, можно сосредоточиться на более
интересных
вопросах,
связанных
с
нововведениями,
а
непрекращающаяся борьба с пожарами пе-
30
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УО1УГАМИ
рестает быть стилем жизни. В компании, где существуют хорошо
отлаженные процессы, сотрудники могут предлагать новшества и
работать с полной отдачей в более спокойной и уравновешенной
обстановке, чем в организациях, не вылезающих из кризисов.
Да, метрики действительно позволяют разглядеть проблемы, но их
и нужно отмечать. Цель здесь — не найти виновных, а
отрегулировать процесс. Это осознается не сразу, но для процессов
и метрик жизненно важно их принятие персоналом.
Если метрики обеспечивают отчетность только по схеме
светофора с оценками «красный», «желтый» и «зеленый», то
менеджерам хочется отмечать исключительно «красные» метрики,
выявляющие проблемы. Чтобы обеспечить не только нахождение
изъянов, но и поощрение достижений, можно, например, ввести в
систему отчетности оценку «золотой» для случая, когда целевые
показатели не просто достигнуты, а превышены. И, повторим, всем
важно знать, и это следует подчеркнуть, что процессные метрики
создаются для улучшения регулирования процессов, а не для поиска
виновных!
2.4. Затраты
Проведение измерений может стоить массу денег. Одному
консультанту по управлению услугами посчастливилось сэкономить
для компании несколько миллионов фунтов стерлингов, закрыв
отдел, где более ста сотрудников занимались только составлением
отчетов. Он выяснил, что все эти отчеты проще и дешевле
получать из других отделов.
Некая международная организация ежемесячно рассылала
сборник своих отчетов, называвшийся, по цвету обложки, «Синей
книгой». В один из месяцев, чтобы проверить значимость отчетов,
руководство решило их не рассылать, а дождаться запросов.
Поступил только один. Руководители были рады узнать, что хоть
один из двадцати получателей этого весьма дорогого сборника
действительно в нем заинтересован, и захотели узнать причину.
«Книга очень нравится моей четырехлетней дочери, — объяснил он.
— На обороте каждой страницы можно рисовать картинки, а бумага
очень хорошего качества».
Отчеты представляют ценность только тогда, когда ими
пользуются, а это происходит при условии, что в них сообщается чтото интересное. Метрики должны создаваться для оценки того, что
действительно важно, и так, чтобы результаты были представлены в
четкой и простой форме. Для удоволетво-рения потребностей
большинства менеджеров в необходимой информации будет вполне
достаточно краткой сводки на одну страницу, размещенной на вебсайте, конечно, если потенциальные проблемы в ней понятно и
четко сформулированы. Прятать плохие новости в примечания в
конце отчетов — это подход, возможно, и срабатывающий для
компаний,
зарегистрированных
на
фондовой
бирже,
но
неприемлемый для ИТ.
Глава 2. ЗАЧЕМ НУЖНЫ МЕТРИКИ?
31
Метрики, информирующие нас о расходах, играют важную
роль, и в схеме ITSM за них отвечает финансовый отдел. Степень
зрелости организации определяет тот уровень расходов, при
котором возникает необходимость в создании метрик. Важно,
чтобы показатели затрат были точными. В связи с этим будет
лучше, если сначала бизнес и ИТ четко определят условия своего
взаимодействия посредством SLA и только потом адекватная
модель учета затрат на обслуживание будет согласована с
финансовым отделом организации.
2.5. Преимущества метрик
Следует разъяснить преимущества метрик:
• Метрики предоставляют необходимый инструментарий для
управления
процессами внутри организации.
• Благодаря метрикам проще сосредоточиться на важных
вопросах.
• Метрики, представленные в удобном виде, позволяют
своевременно
выявить опасность и исправить ситуацию.
• Метрики в состоянии поднять моральный дух организации.
• Метрики могут стимулировать здоровое соперничество между
владель
цами процессов.
• Метрики помогают согласовывать ИТ с целями бизнеса.
3
Области
применения
метрик
Программные инструменты ITSM обеспечивают работу с
целым рядом метрик, большинство из которых
представляют
интерес
либо
для
сотрудников
определенных
отделов,
либо
с
точки
зрения
функционирования конкретных процессов. Если используются только такие метрики, то «хвост виляет собакой» —
организация получает ту информацию, которую считал
необходимой разработчик ПО, а не ту, которая требуется
для согласования бизнеса и ИТ.
Поэтому следует начинать с другого конца: разработать
сначала процессы для своей организации, затем —
метрики для их оценки. После этого можно принять
решение о способе программной реализации метрик.
Метрики предназначены для того, чтобы дать
организации возможность управлять своим развитием, а
значит, кто-то должен за них отвечать. Если за одну и ту
же метрику отвечают двое, то в действительности не
отвечает ни один из них, так как действия одного могут
мешать другому добиться нужного результата.
При
процессном
управлении
ИТ-услугами,
независимо от того, используется ли ITIL, Six Sigma, Cobit
или все три стандарта, важно различать отдельных
работников, организации (структурные подразделения) и
процессы. Чтобы метрика служила эффективным
средством управления, за нее должен отвечать
определенный сотрудник, причем его необходимо
наделить полномочиями, позволяющими ему влиять на
выходной результат соответствующего процесса. Как
заметил Кинг Каньют (King Canute), нет смысла возлагать
на кого-либо ответственность за приливы, если он не в
состоянии на них воздействовать.
34
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Для каждой метрики нужно определить, кто станет ответственным
за нее, будь то начальник отдела или назначенный владелец
процесса, у которого, возможно, вообще нет ни единого
подчиненного.
3.1. Структурные подразделения
В управлении ИТ-услугами в любой организации участвуют как
минимум два структурных подразделения: Service Desk (ранее Help
Desk), обеспечивающее ИТ-поддержку пользователей, и отдел
управления ИТ-инфраструкту-рой (ICT Infrastructure Management
Team, ранее Operations), отвечающий за функционирование
информационно-телекоммуникационной инфраструктуры компании.
Во главе их стоят руководители, каждый из которых отвечает за
процессы своего подразделения и за метрики, оценивающие их эффективность.
На Service Desk часто возлагается ответственность за процесс
управления инцидентами (Incident Management). При этом его
руководитель становится владельцем процесса, отвечающим за
метрики.
В зависимости от размера и структуры ИТ-организации в ее
составе могут быть другие подразделения, реализующие или
поддерживающие определенные ITIL-процессы. Важно, чтобы и для
них были заданы адекватные метрики, согласующиеся с процессами
высшего уровня и являющиеся эффективными инструментами
управления для руководителя данного подразделения.
рассмотрим, например,
административный отдел,
обеспечивающий отчетность как
для процессных метрик ITIL, так и для соответствия SLA. У него
могут быть и дру-гие задачи, не независимо от этого руководитель
отдела должен иметь в своем
распоряжении метрики, проверяющие точность отчетов и своевременность их
создания. Таким отделам часто поручают и коммуникационный план, который
имеет большое значение, так Мак предоставляет услуги для всех остальных процессов. Для него необходимо определить собственные критерии успеха.
3.2. Процессы
Многие процессы не привязаны к одному конкретному отделу, а
являются сквозными и обеспечивают предоставление услуг на базе
многих подразделений и организаций. За такой процесс отвечает его
владелец, и он должен обладать достаточными полномочиями,
чтобы полностью влиять на работу метрик, и, если понадобиться,
использовать свое служебное влияние, или помощь руководства.
Глава 3. ОБЛАСТИ ПРИМЕНЕНИЯ МЕТРИК
35
Хорошим примером здесь может служить менеджер процесса управления
измене-ниями. Одно из важнейших требований к внедрению ITSM в
соответствии с реко-рендациями ITIL в отношении качества — это наличие
заинтересованного лица из ру[ководства компании. Управление изменениями
всегда подразумевает влияние на различные организационные процессы, так
как в управлении изменениями участвует множество различных сторон.
Менеджер прислушивается к советам коллег и один несет ответственность за
окончательное согласование изменений, Его решения не всегда пользуются
популярностью, и есть шанс, что они будут при-ниматься не из коммерческих, а из
политических соображений. Заинтересованное лицо в компании необходимо для
того, чтобы обеспечить менеджеру по изменени-ям поддержку, а для нее в свою
очередь требуются доказательства того, что де-ятельность менеджера
эффективна. Без метрик, подтверждающих это, вопрос является спорным, из-за
чего проще вести под менеджера по изменениям политический «подкоп».
Правильно выбранные метрики для процесса управления изменениями
помогают выявить сотрудников и подразделения, которые недостаточно
склонны к сотрудничеству. А сильный руководитель, являющийся
заинтересованным лицом, может существенно облегчить сглаживание любых
трудностей процесса.
Стоит еще раз повторить одно замечание. Люди очень
чувствительны к критике, как реальной, так и воображаемой.
Выявление недостаточно эффективных процессов с помощью
метрик открывает пути к совершенствованию, оно не предполагает
нападок на кого бы то ни было. Важно всегда подчеркивать эту
мысль при общении с сотрудниками.
4
Для кого
предназначены
метрики
Ценность метрик может быть осознана, только если
действительно ими пользоваться. Так как они
представляют собой форму коммуникации, их следует
планировать и преподносить аудитории подходящим для
нее способом, а для этого, в свою очередь, необходимо
понимать
нужды
различных
пользователей
(потребителей) метрик.
Получатели метрик должны быть также осведомлены о
том, для чего эта информация предназначена и как ею
правильно пользоваться. Есть опасность, что они станут
бегло просматривать метрики только на предмет пунктов,
выделенных красным цветом, чтобы потом отчитать
владельца процесса или руководителя отдела. Это очень
вредный подход, и, к сожалению, он широко
распространен. Понятно, что «красный» пункт имеет
большое значение и ответственным лицам следует
срочно им заняться. Однако по метрикам можно
прослеживать долгосрочные тенденции и на их основе
принимать решения, позволяющие избежать таких
ситуаций в будущем, — это важнее, чем «в пожарном
порядке» исправлять результаты предыдущего периода.
Владелец метрики процессов — как собственных, так и
«чужих», — помогает менеджерам управлять.
При внедрении метрик стоит подумать о том, чтобы не
сразу приступать к рассылке отчетов, а предусмотреть
определенный
период
обучения
(повышения
осведомленности) сотрудников. Он, возможно, будет
сопровождаться обсуждением будущего направления
развития, целей, ориентиров и программы постоянного
улучшения качества обслуживания (Continuous Service
Improvement Program — SIP).
38
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМ1
Уровень
детализации
метрик
определяет
степень
их
применимости. Если они слишком подробны, их восприятие
требует длительного времени и большой вероятностью может быть
урезано до описанного выше просмотр, «красных» пунктов. С другой
стороны, при отсутствии достаточного количе ства деталей можно
упустить из виду важные тенденции. Цель этой кни ги — найти
равновесие между двумя крайностями, предложив небольшие
понятные наборы показателей, характеризующих наиболее важные
парамет ры процесса.
4.1. Руководство компании
Руководители бизнеса и ИТ совместно направляют работу ИТподразделени) так, чтобы добиться ее оптимального сочетания с
потребностями
бизнеса
Эта
деятельность
никогда
не
заканчивается, поскольку частая и порой не ожиданная смена
требований заложена в самой природе бизнеса. Метри-ки —
возможно, в составе системы сбалансированных показателей
(Balancet Scorecard — BSC) или другой подобной схемы — помогают
количественно оценить эффективность тех директив и рычагов,
посредством которых руко водители осуществляют управление.
Метрика по самой своей сути может представлять информацию
только с совершившихся событиях. Важно удостовериться, что все
они отвечают нуж дам предприятия.
Самый непосредственный показатель качества ИТ-услуг,
имеющийся в распоряжении руководства компании, — это
фактическая эффективность в сравнении с критериями,
определенными
в
SLA.
Внутрифирменные
показа
тели
эффективности различных ИТ-процессов лишь дополняют эти
данные Если дела идут хорошо, а отступления от SLA редки и слабо
влияют на рабо-ту, руководству компании, как правило, не нужно
особенно вникать во внут-ренние механизмы работы, за
исключением тех случаев, когда становится известно о предстоящих
изменениях в коммерческой среде.
Случается, что ИТ-подразделение предоставляет услуги в
соответствии с оговоренными уровнями сервиса, но лишь за счет
высоких внутрифирмен-ных издержек и крайнего напряжения сил.
Это неприемлемо в длительной перспективе. Другая ситуация —
отдел успешно справляется с работой при нынешней загрузке, но не
обладает достаточным потенциалом на случай ее повышения.
Крупная операция по слиянию способна превратить эффективное
ИТ-подразделение в безнадежно провальное, но этого можно
избежать,
если
заранее
спланировать
необходимые
преобразования. Зная из процессных метрик о том, как
функционирует ИТ-служба, руководитель в состоянии строить
реальные планы на основе здравой оценки имеющихся возможностей и проблем.
Наконец, критерии SLA могут быть слишком жесткими с точки
зрения действительных нужд предприятия. Если руководитель,
согласующий усло-
Глава 4. ДЛЯ КОГО ПРЕДНАЗНАЧЕНЫ МЕТРИКИ
39
вия со стороны бизнеса, обладает большей властью или опытнее в
ведении переговоров, то не исключено, что под его давлением
менеджер по уровню сервиса уступит нереалистичным требованиям.
Кроме того, обстоятельства меняются, и SLA, подходящее для
организации при одном ее размере, при другом может сделаться
невыполнимым. На деле для соблюдения SLA данные соглашения
необходимо
пересматривать
и
обсуждать,
обеспечивая
рациональное согласование. Процессные метрики позволяют
менеджеру по уровню сервиса проверить принятые решения
относительно этих уровней в реальных условиях, предъявить
руководству показатели фактических затрат — пусть даже не в
денежном измерении, а просто как количество усилий и ресурсов,
— и, возможно, добиться пересмотра схемы, которая приносит
лишь незначительную пользу бизнесу, но при этом резко увеличивает накладные расходы на ИТ.
Как упоминалось во введении, процессные метрики будут
полезны высшим руководителям, только если те будут понимать их
содержание и связь с финансовыми издержками. Кроме того,
руководители должны иметь представление о других, менее
осязаемых, но тем не менее важных факторах, таких как моральное
состояние сотрудников ИТ-подразделения или текучесть кадров: хотя
их и трудно измерить, они оказывают существенное влияние на
предоставление услуг.
4.2. Менеджеры процесса
Менеджеры процесса видят метрики нижнего уровня и в силу этого
лучше понимают, почему тенденции, наблюдаемые для KPI, именно
таковы, каковы они есть. Если в очередном отчете ожидаются
«красные» пункты, менеджер заведомо узнает об этом первым, а
значит, к тому моменту, как отчет попадет в распоряжение
руководства ИТ и компании, может подготовить некоторые
разъяснения и предпринять определенные корректирующие
действия.
Однако при работе в течение длительного времени «красные»
пункты не должны быть высшим приоритетом. Для менеджера
процесса важнее иметь представление о тенденциях, позволяющих
выявить возможные опасности в среднесрочной перспективе.
Требуется сравнительно немного усилий, чтобы изменить
производительность процесса или преобразовать его, предупредив
таким образом развитие опасных сценариев, о которых сигнализировали метрики. Преодолевать кризис, когда он уже возник,
значительно тяжелее.
Менеджеры несут ответственность за управление собственными
процессами. Но у них, кроме того, есть и более широкая задача —
внедрение культуры, ориентированной на процесс. Необходимо
избавиться от глубоко укоренившегося в ИТ обычая награждать за
героическую борьбу с пожаром и спасение положения в последнюю
минуту, забывая о тех, кто предотвра-
40
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
щает возгорание, — ведь в действительности именно им в первую
очередь причитаются премии.
Для этой цели стоит открыто поощрять шаги, направленные на
нейтрализацию потенциальных будущих кризисов, и достигнутую
благодаря этим действиям экономию средств. Полезно также широко
распространить материалы с анализом происходивших крупных
кризисов, где делался бы упор на предотвращение сходных ситуаций
в будущем. И совершенно необходимо, чтобы постепенный сдвиг от
прежнего порядка к новому происходил на фоне регулярной
рассылки показателей, характеризующих нормальный ход процесса,
а не исключения из него.
Менеджерам процессов также следует серьезно заняться
выявлением ресурсов и накладных расходов, ставших избыточными
вследствие изменения эффективности или уменьшения запросов со
стороны бизнеса. Это нелегко, но в долгосрочной перспективе,
возможно, позволит усовершенствовать процесс так, чтобы он
обеспечивал лучшие результаты с меньшими затратами. К
сожалению, зачастую в организационную культуру заложено вознаграждение руководителей, имеющих большое число подчиненных, а
те, которым удается приносить много пользы при малом числе
сотрудников, остаются в тени.
4.3. Сотрудники ИТ-подразделений
Изменение
организационной
культуры,
рассмотренное
в
предыдущем разделе, существеннее всего сказывается на персонале
ИТ-подразделений. В них каждый сотрудник должен понимать, что
такое метрики, KPI и SLA, причем не только в общем, но и конкретно
— как именно они соотносятся с процессами и с его собственным
участием в деятельности предприятия.
В идеале отдел кадров должен располагать переработанными
должностными инструкциями и критериями оценки эффективности,
так чтобы ее можно было измерить при помощи соответствующих
метрик, сопоставить результат с контрольными показателями и в
зависимости
от
полученного
соотношения
определить
вознаграждение.
Очень важно постоянно информировать персонал о точном
смысле метрик, о том, какие достижения будут поощряться и как
именно. На еженедельных и ежемесячных собраниях необходимо
сравнивать эффективность различных процессов и награждать
сотрудников за превышение заданных критериев. Подобно тому, как
в производственных цехах сейчас существуют графики текущих
показателей производительности, в ИТ-отделах нужно на видном
месте вывешивать относящиеся к ним метрики, чтобы напоминать
сотрудникам о стоящих перед ними задачах.
Наиболее весомый вклад в программу SIP способны внести
сотрудники, первой линии поддержки. Людям, изо дня в день
предоставляющим услуги в рамках процессов, проще увидеть, как
они могли бы улучшить свою рабо-
Глава 4. ДЛЯ КОГО ПРЕДНАЗНАЧЕНЫ МЕТРИКИ
41
ту. Нужно советоваться с ними и достойно вознаграждать ценные
предложения. Как-никак, повышать качество услуг для конечных
пользователей путем совершенствования процесса обслуживания
лучше, чем вкладывать все больше средств в персонал, компьютеры
и другие ресурсы!
Когда производительность не соответствует идеалу и в KPI или
процессных метриках появляются показатели, выделенные красным
цветом, важно предотвратить повторение подобных ситуаций. Для
этого следует рассматривать проблему не как повод для обвинения
кого-либо, а как возможность найти пути дальнейшего
совершенствования
и
всячески
поощрять
сотрудников,
предлагающих способы исправить положение.
Также к обсуждению будущих изменений в метриках стоит
привлекать работников из групп, непосредственно отвечающих за
услуги
для
конечных
пользователей.
Благодаря
знанию
повседневных проблем они хорошо представляют себе последствия
преобразований и распознают нереалистичные запросы. Если же
руководству необходимо настаивать на своих требованиях, лучше
обсудить пути их выполнения совместно с сотрудниками. Тогда принятые решения не будут встречаться негодованием и неприятием,
что типично для ситуации, когда их навязывют сверху без ясного
понимания потенциальных результатов.
Все мы, очевидно, чувствуем себя комфортнее и лучше работаем
в условиях меньшего стресса и большего контроля над
собственным
будущим.
Сотрудники,
должным
образом
задействованные в процессах создания и согласования метрик,
будут сильнее ощущать себя ответственными за то, чтобы
обеспечить хорошее соответствие установленным критериям. Сколь
бы неосязаемыми ни казались подобные изменения морального
духа, они безусловно вносят свой вклад в итоговый результат
деятельности предприятия.
5
Как использовать
метрики
5.1. Время
Частота измерений влияет на результаты. Отчеты о
метриках могут предоставляться каждый день, месяц,
неделю, квартал или год, и очень важно, чтобы
временной интервал был выбран правильно.
Было бы ошибкой принимать стратегические
решения на основе одного из ежедневных отчетов:
нельзя исключить, что его данные — аномалия.
Аналогичным образом годовой отчет позволяет
выработать стратегию исправления ситуации, но не
тактические решения на следующую неделю для службы
Service Desk.
Важно понимать, что многие показатели, помимо
частоты измерения, характеризуют интервал времени, за
который должно смениться состояние процесса, —
например, как быстро проблема из «новой» превратится
в «решенную». В таких случаях нельзя просто
фиксировать состояние через равные промежутки
времени — ведь если код остается прежним, это не дает
никакой дополнительной информации. Здесь измерение
возможно только тогда, когда что-то (как правило,
некоторый процесс) действительно изменяется.
5.2. Измерение
Чтобы управлять бизнесом, его нужно измерять. В
коммерческой деятельности для этой цели выработано
несколько четких и конкретных показателей, общих для
целого ряда отраслей:
44
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
• доход;
•
•
•
•
•
•
прибыль;
объем продаж;
доля рынка;
норма окупаемости инвестиций (Return On Investment — ROI);
объем производства;
уровень запасов.
Некоторые из перечисленных показателей можно применить к
ИТ-про-цессам, и это тем проще, чем лучше связь между ИТ и
бизнесом.
Здесь есть риск увлечься измерением того, что легко измерить,
вместо того, что способно дать важную информацию о бизнесе.
Несложно посчитать число проданных единиц товара в супермаркете,
но при этом факты продажи пакетика конфет и стиральной машины
получат одинаковый вес, так что применимость подобной метрики
будет более чем ограниченной. В ИТ объекты не так осязаемы, как
стиральные машины, поэтому труднее оценить осмысленность того
или иного измерения.
На рис. 5.1 показана схема того, как процессы протекают в
различных подразделениях, обеспечивая взаимосвязь входных и
выходных потоков информации. Кружки обозначают этапы
процесса, причем подразделения-
Рис. 5.1. Общий сценарий процесса. Метрики могут фиксировать только изменения
состояния процесса. Чтобы они имели смысл, важно правильно определить процесс
Глава 5. КАК ИСПОЛЬЗОВАТЬ МЕТРИКИ
45
участники оказываются в состоянии производить измерения, когда в
рамках этого процесса начинают отвечать за выполнение
определенного действия или задания, — измерить что-либо можно
только в момент изменения.
Допустим, процесс в целом — это обработка заказа, а самый
темный кружок обозначает отдел, ответственный за проверку
кредитоспособности покупателей. Он может фиксировать моменты
времени, когда заказ поступил и когда был передан следующему
отделу как принятый или отклоненный. Эта информация полезна
для данного отдела, но представляет куда меньше интереса для
владельца процесса. Не все заказы проходят через кредитный
контроль, для небольших, возможно, используется упрощенный
механизм подтверждения. С точки зрения владельца процесса важна
стадия подтверждения, ее продолжительность, количество ошибок в
процессе и т.д.
Из-за подобных различий в точке зрения мы часто
рассматриваем эту схему как последовательность «состояний»
процесса. Заказ из состояния «кредитоспособность не проверена»
переходит в состояние «проверка кредитоспособности» и далее —
«кредитоспособность проверена». Эти переходы можно использовать
для измерения различных значимых факторов в данной части
процесса. Попробуем просто рассмотреть все заказы, находящиеся
в состоянии «проверка кредитоспособности», и решить, какие еще
факторы представляют интерес, к примеру:
• размер заказа;
• лицо или отдел, обрабатывающие заказ;
• конечная кредитоспособность клиента.
Фактически мы спрашиваем: «Что нам важно знать о ситуации с
заказами, когда проверяется кредитоспособность клиента?», т. е.
задаем вопрос о бизнесе и его значимых результатах.
В ИТ-процессе происходит то же самое. Мы определяем
состояния процесса, а затем для каждого из них определяем, что
существенно для достижения цели процесса согласно SLA.
Здесь проясняется один важный момент. В примере с проверкой
кредитоспособности привязка состояний к бизнес-процессу (а также
отделу) была очевидной, а в ИТ это далеко не так. Если состояние
охватывает два подпроцесса, измерение не может выделить ни один
из них. Без тщательно продуманных определений процессов
результаты, вполне вероятно, не будут иметь смысла или, что еще
хуже, введут в заблуждение.
Важно отметить, что на диаграммах, подобных той, которая
представлена на рис. 5.1, переход от одного состояния к другому
выглядит как моментальный. В реальной жизни это не всегда так.
Если заказ отпечатан на бумаге, то после получения им статуса
«кредитоспособность проверена» может потребоваться еще
несколько часов для его передачи на следующий этап обработки,
потому что нужно будет физически взять документ в руки и отнести
его следующему сотруднику. Даже в электронных системах возможны
задержки,
46
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
в частности, если заказ попадает не к тому работнику и его нужно
переслать по правильному адресу.
5.3. Контроль
Когда критерии выработаны, можно начинать контролировать
измеряемую часть процесса: узнать, кто отвечает за каждое из
конкретных состояний процесса и за переходы между ними, затем
установить для подпроцессов ориентиры, на основе которых будет
оцениваться их эффективность. Обычные способы для этого — либо
понаблюдать за показателями в течение одного-двух периодов
времени, чтобы получить таким образом представление о
нормальном ходе работы, либо сравнить данный подпроцесс с
аналогичным в своей или другой организации.
После установки ориентиров можно переговорить с владельцем
подпроцесса, чтобы вместе с ним определить задачи по улучшению
ситуации. Информация о продолжительности состояний позволяет
также выявить те подпроцессы, которые требуют больше всего
времени и ресурсов, а значит, обещают максимальный эффект от
усовершенствования.
Чтобы получить правильный результат, необходимо учитывать, что
не все состояния равноценны. На диаграмме состояний процесса,
показанной на рис. 5.2, можно увидеть альтернативные пути.
Рис. 5.2. Диаграмма состояний процесса. Степень насыщенности серого отражает
последовательность шагов от начала и до конца процесса. Диаграмма показывает
допустимые переходы между состояниями
Глава 5. КАК ИСПОЛЬЗОВАТЬ МЕТРИКИ
47
В этом нет ничего необычного. Просто из начального состояния
процесса (ПО) возможен переход в три других: (Ш, П6 и П7),
приводящих к различным вариантам хода процесса. Так как все они
завершаются конечным состоянием П5, время ПО -> П5 можно
измерить, и не исключено, что такой показатель будет полезен.
Однако если процессы ПЗ, П7 и П8 контролируются другими
частями организации, вам вряд ли легко удастся выяснить, почему у
них такие плохие показатели времени.
Когда переход ПО -> П5 представляет собой важную часть
выполнения процесса в соответствии с SLA, его продолжительность —
вполне обоснованный показатель. Но чтобы контролировать весь
процесс, его владельцу нужны метрики по отдельным ветвям, чтобы
понимать долю каждого маршрута в общем объеме обработки и
общей продолжительности задержек. К примеру, может оказаться,
что 90% процессного трафика проходит по маршруту ПО -> П6 -> П5,
но все случаи, в которых возникала опасность невыполнения SLA,
относятся к маршруту ПО -> П1 -> ПЗ -> П4 -> П5. Это означает, что усовершенствование или перепроектирование более сложного из двух
маршрутов позволит значительно улучшить уровень контроля всего
процесса, и пока это не сделано, не стоит тратить время на
альтернативный маршрут, характеризующийся высокими объемами.
5.4. Цель
Контроль — это прекрасно. И все же, продолжая нашу аналогию с
вождением автомобиля, если вас до наступления сумерек ждут в
Амстердаме, а вы, проведя день за рулем, приезжаете в Париж,
вас вряд ли за это похвалят.
Чтобы управлять процессом, нужно понимать, к чему именно вы
стремитесь. В примере с проверкой кредитоспособности можно
было бы, скажем, пожелать, чтобы общая сумма безнадежных
долгов не превышала 5% товарооборота, а время обработки заказа
— восьми рабочих часов. С заданной таким образом целью
становится намного понятнее, какие именно процессы нужно
измерять.
Определив цель и соответствующие измерения, необходимо
проверить обоснованность принятых решений с помощью
контрольного тестирования. Затем следует оценить разрыв между
целью и нынешним положением дел (к примеру, долги составляют
10% товарооборота, а обработка заказа длится двенадцать рабочих
часов). Заключительный шаг — разработка плана по преодолению
разрыва путем усовершенствования процесса, а также, возможно, за
счет использования дополнительных ресурсов или даже аутсорсинга
некоторых частей процесса.
С этими решениями можно уже двигаться по направлению к цели,
устанавливая
для
команд
и
владельцев
подпроцессов
промежуточные цели в виде определенных показателей
эффективности.
48
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
В ИТ не всегда легко правильно поставить цель. Здесь очень
важно не пожертвовать удовлетворенностью потребителя, чересчур
энергично взявшись за сложную задачу. Поэтому во все планы
процессов, рекомендуемые далее в настоящей книге, включена
метрика удовлетворенности. Она позволяет проследить, чтобы
движение к важным целям ИТ не увело компанию от клиентов.
5.5 Учет
В методиках, описывающих управление ИТ-услугами, в частности в
ITIL, ставится задача максимально тесной привязки этого
управления к целям конечного потребителя, которые часто (или
даже как правило) носят финансовый характер. Обеспечению
привязки посвящен специальный раздел ITIL — управление
финансами ИТ. Задействовав его на начальной стадии разработки
метрик, можно встроить в проект оценку ресурсоемкое™.
Допустим, установлено, что затраты на одну заявку составляют сто условных
единиц, изначально это, по видимому, очень грубая оценка, рассчитанная
путем деления расхдов на службу Service Desk на количество обращений. Со
временем ее можно будет уточнить, поедоставив управлению финансами
информацию о реальном времени работы согласно заданным процессным
метриках KPI и SLA, а также теоретическую базу для учета этих цифр.
В самом начале такая процедура способна помочь с выявлением SLA, вносят
незначительный вклад в выполнение бизнес-функции, но поглощают мно-го ИТресурсов. Разумеется, компания вполне может решить, что подобное распределение правильно, но в случаях, когда оно не является приоритетным, пересмотр «ресурсоемких» SLA позволит значительно сэкономить на расходах.
По мере созревания бизнеса модель затрат усложняется. На
данной стадии имеет смысл создать для финансового управления
метрики, отслеживающие расходы организации в целом. Это
позволит выявлять нежелательные тенденции и предпринимать
действия по исправлению ситуации, прежде чем появится
опасность серьезного перерасхода. Преждевременные попытки
упорядочить издержки могут оказаться опасными. Организации
проще вытерпеть дополнительные проблемы, издержки и давление,
когда мышление, опирающееся на процесс, становится нормой.
6
Разработка
метрик
Прежде чем приступить к подробному рассмотрению
конкретных метрик, нужно понять, что за процессы
должны ими оцениваться. Без этого невозможно
определить, будет ли работать полученный набор
метрик, каким бы впечатляющим он ни казался.
В настоящей главе исследуются методы создания
жизнеспособного набора метрик для компании.
При первоначальном обсуждении метрик внутри и за
пределами ИТ-подразделения следует рассмотреть
основополагающие принципы, чтобы все поняли, почему
применяется данный процесс и какими будут результаты.
6.1. Зачем разрабатывать метрики
Некоторые показатели мерить совсем легко. Ваш пакет
программного обеспечения наверняка содержит массу
готовых метрик — в некоторых инструментах их сотни.
Однако простота измерения — еще не основание для
того, чтобы использовать данную метрику, в
особенности метрику, которую невозможно измерить.
С использованием несложных на вид метрик связано
много опасностей. Самая серьезная заключается в
оценке параметров, которые не требуется улучшать.
Кроме того, есть риск, что метрика, поставляемая в
комплекте с набором программных инструментов,
выглядит интересно, но основана на формуле, неуловимо
отличающейся от того, что вы ожидаете.
50
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Представьте, что в пакет включена метрика «время закрытия инцидента». Вам
кажется, это именно то, что нужно. Но проверили ли вы, с какого момента отсчитывается время: со звонка в службу Service Desk, с перевода заявки в статус
«обработка» или с ее передачи ответственному лицу? Учитывается ли период
«ожидание дополнительной информации от клиента»? Как обрабатываются случаи,
когда инцидент закрывается, а потом открывается повторно? Если метрика подразумевает ежедневную отчетность, что происходит с еще не закрытыми обращениями — они отображаются в отчете со статусом «открытые» или попадают в него,
только получив статус «закрытых»? Как долго информация о закрытых обращениях будет включаться в отчет? Будут ли в нем присутствовать данные за вчерашний
день, прошлую неделю, прошедший месяц?
При разработке метрик вы должны обдумать все эти вопросы, а
значит, решить, что лучше всего подходит для вашей организации.
Если вы пользуетесь метрикой «прямо из коробки», то не знаете,
какие решения принял за вас разработчик программы. Они с
одинаковой вероятностью могут быть и теми, которые вам нужны, и
совершенно неподходящими для вашей организации.
Лучшее решение — разработать собственные метрики, а затем
посмотреть, каким образом можно было бы адаптировать метрику,
встроенную в программный пакет, так, чтобы она работала в
точности как вам нужно. В данном разделе рассматриваются
аспекты, которые нужно продумать при принятии решений об
используемых метриках.
6.2. Принципы
6.2.1. SMART
Аббревиатура SMART (Specific, Measurable, Achievable, Realistic,
Timely — конкретный, измеримый, достижимый, реалистичный,
своевременный) используется применительно ко многим бизнеспроцессам. Это полезный набор вопросов, которые следует задать
по поводу любой метрики перед тем, как ее внедрять.
Относится ли метрика к некоторому конкретному процессу или
части процесса? Если оценке подвергаются части двух разных
процессов, есть опасность, что ни один из их владельцев не будет
считать себя ответственным за достижение результатов.
Измерима ли метрика? Очень важно убедиться, что это базовое
условие выполнено. Если, допустим, вы решите измерить
продолжительность разговоров клиентов со службой Service Desk,
вам не удастся осуществить это без коммутатора или офисной
телефонной станции.
Глава 6. РАЗРАБОТКА МЕТРИК
51
Достижима ли метрика? Может ли служба Service Desk
выполнять все заявки в течение трех минут? Если две минуты
уходит на внесение в компьютер данных позвонившего — при
наличии хорошей базы управления конфигурациями (Configuration
Management Database — CMDB) это, конечно же, не так, — на
устранение неисправности остается всего одна минута, чего, повидимому, недостаточно!
Реалистична ли метрика? Есть ли смысл измерять время, в
течение которого заявки находятся в состоянии «ожидание»? Это
может происходить по множеству различных причин. Если они вам
неизвестны, то нереалистично просить сократить время ожидания,
— ведь вы не знаете, с чего начать! В этом случае логично разбить
«ожидание», к примеру, на:
• «ожидание повторного звонка клиента»;
• «ожидание ответа от службы поддержки второго уровня»;
• «ожидание обновленной версии программы».
Определитесь, действительно ли вы измеряете что-то из
реальной жизни или просто какую-то часть программного пакета.
Своевременна ли метрика? Если вы оцениваете работу службы
Service Desk раз в месяц, а удовлетворенность клиента измеряется
раз в квартал, у вас нет своевременной метрики. Клиенты могут два
месяца оставаться неудовлетворенными, прежде чем метрика это
покажет!
6.2.2. KISS
Аббревиатура KISS (Keep It Simple Stupid — будь проще, дурачок!) не
очень удачна, но выраженный в ней принцип тем не менее важен.
Если метрики плохо разъяснены и способы их достижения
недостаточно понятны, это открывает дорогу для сопротивления,
неприятия, разочарований и позволяет легко находить оправдания,
когда не выполнены требования.
Некоторым
людям
свойственно
подходить
ко
всему
аналитически. Это очень полезно в ИТ, где сложные задачи требуют
детального анализа. Однако при разработке метрик существует
опасность создания переусложненных формул для измерения сразу
нескольких вещей. Пусть, например, у нас есть метрика «среднее
число инцидентов на проблему, с которой связан запрос на
изменение». Этот показатель можно понять, но о чем он нам
сообщает и как его улучшить? Нужно ли, чтобы увеличилось число
запросов на изменение для проблем с большим количеством
инцидентов, или следует более дробно подразделять проблемы,
чтобы с каждой было связано меньше инцидентов? Совершенно
неясно, почему это важно и что здесь исправлять.
Лучше всего отступить на шаг и спросить себя, что в данном
случае существенно. Может быть, число инцидентов на проблему?
Или значение, придаваемое проблемам? Важны ли запросы на
изменение сами по себе или
52
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
как мера для оценки процесса решения проблемы? Ответив на эти
вопросы, вы, может быть, придете к выводу, что две-три простые
метрики
представляют
собой
лучшее
решение,
чем
первоначальная сложная.
6.2.3. GQM
Метрики давно используются в управлении проектами по
разработке прикладного ПО. Из этой сферы пришел метод
выработки метрик, называемый GQM (Goal, Question, Metric — цель,
вопрос, метрика).
Он предусматривает определение высокоуровневых целей
проекта (в управлении услугами это будут цели процесса). Для
каждой из целей составляется перечень вопросов, на которые будут
даны ответы, если поставленные цели достигнуты, а затем
разрабатывается
метрика
для
количественной
оценки
результатов.
И хотя данный формальный метод нами не применялся, метрики в
главах 7 и 8 разрабатываются сверху вниз. В начале каждого
раздела определяется цель процесса, затем перечисляются
соответствующие ей метрики, а объяснение каждой из метрик, по
сути, представляет собой вопрос, утвердительный ответ на который
означает, что цель достигнута.
6.2.4. МАРЕ
Метрики ITSM могут выдавать голые цифры, такие как столько-то
тысяч инцидентов, столько-то миллионов сетевых событий и т.д. Их
сложно сравнивать, особенно если речь идет о разных
организациях или процессах. Часто имеет смысл переводить
абсолютные показатели в проценты, чтобы сделать их проще для
понимания. Различные методы такого рода используются при
прогнозировании тенденций в бизнесе.
Они могут применяться и в ИТ для планирования мощностей или
оценки будущих ресурсов. Например, потребуется ли в следующем
году больше квалифицированных сотрудников для службы Service
Desk, и если да, то сколько именно? Чтобы ответить на этот вопрос,
необходимо разработать метрики для измерения рабочей нагрузки,
а кроме того, составить прогноз на следующий год. Для
прогнозирования существует масса разных методов — от прямой
линейной экстраполяции до сложного моделирования, — но с каким
из них мы получим качественный и надежный результат?
Коэффициент МАРЕ (Mean Absolute Percentage Error — средняя
абсолютная ошибка в процентах) применяется в статистике для
оценки достоверности прогнозов. Скажем, можно сравнить по
формуле для МАРЕ показатели, получающиеся при выбранном вами
способе прогнозирования, с существующими историческими данными
Service Desk за последние шесть месяцев. Если МАРЕ низкий (менее
40%), прогноз, вероятно, достаточно надежен. Формула для его
расчета выглядит следующим образом:
Глава 6. РАЗРАБОТКА МЕТРИК
53
MAPE=сумма/ (измеренные значения прогнозируемые значения)/ измеренные значения
\*100/ количество значений.
Т.е. это сумма отношений абсолютного значения разности
прогнозируемых и реальных данных к реальным данным,
выраженная в процентах и поделенная на количество значений.
6.2.5. Диаграмма взаимоотношений с клиентами
На рис. 6.1 приведен пример диаграммы взаимоотношений с
клиентами. Сложные связи, присутствующие во всех процессах,
представлены на ней в упрощенном виде. Однако цель диаграммы
не перечислить все отношения, а выявить в каждом процессе
наиболее непосредственного клиента.
Оттенками серого представлено количество шагов между
процессом и конечным клиентом. Стрелки указывают на первичного
клиента процесса. В зависимости от локальных требований возможно
включение других участников бизнеса и альтернативных первичных
клиентов.
Все это нужно, чтобы определить, на каком этапе можно было бы
измерить степень удовлетворенности клиентов. Действительно,
заинтересованных лиц много. Можно, конечно, считать, что уровень
удовлетворенности клиентов компании измеряется ценой, которую
готовы заплатить акционеры за ее
Рис. 6.1. Диаграмма взаимоотношений с клиентами
54
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАШ
акции. Однако для постоянной оценки удовлетворенности клиентов
работой ИТ-отдела это очень косвенный и ненадежный метод.
Чтобы избежать не приятных сюрпризов, нужно свести задачу к
рассмотрению
одного-един
ственного
клиента,
обеспечив
пристальное внимание к его нуждам, а также тесные
взаимоотношения с ним.
На рис. 6.1 крайние левые прямоугольники показывают клиентов,
а прямоугольники во второй колонке слева — процессы первой
линии, где оценки степени удовлетворенности клиентов можно
определить, общаясь непосредственно с клиентом. Третьей колонке
соответствует вторая линия, где удовлетворенность измеряется
исходя из процессов первой линии. К примеру, успешность процесса
управления проблемами оценивается по тому, какова степень
удовлетворенности для процесса управления инцидентами, насколько
хороши отчеты об известных ошибках и насколько успешно
сокращается число инцидентов при устранении вызвавших их
проблем. Управление изменениями — это процесс третьей линии,
получающий показатели удовлетворенности от процесса управления
проблемами. В свою очередь, для процесса управления
мощностями, относящегося к четвертой линии, удовлетворенность
клиентов определяется по соответствующему показателю процесса
управления изменениями.
Для простоты на рис. 6.1 не показаны другие процессы, которые с
большой вероятностью также присутствуют во взаимодействии с
клиентами. В реальную диаграмму были бы включены поставщики,
субподрядчики и, вероятно, еще какие-то значимые бизнес-единицы
или бизнес-процессы.
Как мы увидим в последующих главах, посвященных подробному
рассмотрению метрик, для каждого процесса должны выполняться
определенные критерии «удовлетворенности потребителя», и
именно они в конечном итоге являются основным ориентиром при
оценке эффективности процесса. Данная диаграмма дает наиболее
общее представление о том, каким образом были получены эти
критерии.
Перед внедрением метрик разумно организовать для
заинтересованных лиц и владельцев процессов семинар по
обсуждению диаграммы взаимоотношений и совместными усилиями
добиться, чтобы она правильно отражала конкретную ситуацию, в
которой находится компания. Например, для какой-то организации
вариант подхода к службе Service Desk как первичному клиенту
отдела управления ИТ-инфраструктурой будет более удобным.
6.3.Требования
Для
эффективной
работы
метрик
нужны
правильно
разработанные процессы. Со временем последние могут
меняться, и это в действительности необходимо в рамках
процессов непрерывного улучшения качества функционирования
ИТ-служб. Однако чем реже модифицируются основные
элементы, тем лучше. Такого рода преобразования требуют очень
аккурат-
Глава 6. РАЗРАБОТКА МЕТРИК
55
ного информирования, а возможно, также и переподготовки
всех, кто имеет отношение к процессу.
Метрики могут основываться только на собираемых данных. Если
записи о проблемах в течение определенного периода времени
находятся на этапах «Общий анализ основной причины», «Анализ
дерева неисправностей» и «Анализ журнала регистрации», то
относительный вклад этих этапов можно будет оценить лишь при
условии такой конфигурации системы, при которой соответствующие
состояния регистрируются и процесс действительно активизирует их
так, как это требуется.
Не стоит рассчитывать, что аналитики, исследующие проблему,
будут настолько подробно записывать свои действия. В конце
концов, задача заключается в том, чтобы быстрее добраться до
корня проблем, а слишком подробное документирование может
этому препятствовать. Но если ожидается, что данный уровень
будет востребован, необходимо учесть его при настройке
инструментария и планировании процесса.
То же самое касается таких категорий, как конфигурационная
единица, инцидент, изменение, проблема и т. п. Хорошо известно, что
опасно включать в их перечень всеохватывающую категорию
«Общее». Но важно отдавать себе отчет в том, что в список
категорий изменения вносятся гораздо чаще, чем в статусы
(состояния) указанных объектов.
Таким образом, первое требование — это спроектировать
процессы с учетом состояний, о которых необходимо собирать
информацию. Каждое из них должно отражать определенную
потребность бизнеса или процесса. Избыточные состояния,
введенные только ради полноты или возможности измерения, будут
мешать работе.
Отсюда следует, что для получения наилучшего результата метрики
должны разрабатываться в самом начале реализации ITIL в целом.
Если их понадобится модифицировать уже после внедрения
процессов, необходимо с особой тщательностью отнестись к
проектированию, контролю и реализации изменений. Обязательно
следует применить процесс управления релизами — он
гарантирует, что информация о сделанных изменениях будет
доведена до всех, кого это касается, и получит должное отражение
в документации.
Все мы люди. Если не придавать значения правильному
применению статусов и категорий, то из-за недостаточной заботы о
фиксации соответствующих изменений будут теряться важные
данные. Поэтому корректность использования статусов и категорий
должна отслеживаться и контролироваться. Обеспечить работу по
правилам помогут механизмы предварительной проверки. Например,
если изменение состояния П2 на П7 не отвечает логике, приложение
не должно его допускать. Сюда входит и популяризация
результатов, достигнутых благодаря правильной регистрации данных,
— распространение информации, полученной из анализа данных
процесса, а также сведений об участии в его улучшении и прорывах
в области управления проблемами.
56
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСПУГАМИ
Итак:
• разрабатывайте процессы таким образом, чтобы в них с самого
начала
были включены нужные состояния;
• если выполнение процесса подвергается изменению,
проследите за
полнотой информирования и переподготовки тех, кого это
касается;
• не используйте всеобъемлющих статусов и категорий;
• отслеживайте и контролируйте применение статусов и
категорий.
6.4. Разработка отдельных метрик
Проектирование метрик не является технической работой и не
относится к бэк-офису. Чтобы получить работающие метрики, нужно
проконсультироваться со всеми заинтересованными сторонами.
Требуется, чтобы клиенты и основные участники бизнеса были
удовлетворены метриками, т. е. считали, что они правильно
отображают происходящее в бизнес-процессах и на них можно
положиться как на источник информации. В свою очередь, владельцев процессов должна устраивать возложенная на них
ответственность за успешное достижение требуемых показателей.
Необходимо также оставить им определенную надежду превзойти
эти показатели с помощью целенаправленных усилий.
Чтобы достичь такого положения, целесообразно предложить
набор возможных метрик на семинаре, где будут присутствовать
владельцы процессов и заинтересованные лица, а затем по
очереди обсудить каждую из них и ее значение. Метрики при этом
могут переделываться и заменяться более подходящими. В итоге
все стороны приходят к консенсусу по поводу используемого набора
метрик (но в будущем не исключены модификации данного
набора).
Это очень важный шаг. Он означает, что отныне и вплоть до
момента пересмотра метрик владельцы процессов согласны за них
отвечать, а участники бизнеса, заинтересованные в процессах, —
принимать полученные результаты как верное отражение
положения дел. Все последующие обсуждения уже могут опираться
на согласованный набор стандартов и, таким образом, будут
вестись вокруг проблем, связанных с невыполнением метрик и
способами разрешения ситуации, а не того, насколько эти метрики
адекватны.
В самом начале, во время бенчмаркинга, руководитель ИТслужбы или сервисного подразделения может принять решение о
наборе метрик без такой консультации. Это вполне разумно, когда
речь
идет
о
бета-тестировании
процессов,
установке
предварительных данных для бенчмаркинга и проверке того, что
метрики могут быть получены вовремя. Подобные вопросы
действительно стоит отработать заранее, но после окончания
бета-тестирования следует непременно проконсультироваться с
заинтересован-
Глава 6. РАЗРАБОТКА МЕТРИК
57
ными участниками бизнеса и согласовать с ними набор метрик для
оценки и контроля процесса.
6.5. Разработка интегрированных
наборов метрик
Метрики для различных ITIL-процессов могут разрабатываться
независимо друг от друга. Однако в конечном итоге подобный
подход приводит к неудовлетворительным результатам, потому
что не позволяет руководству сравнить процессы различных
областей.
Хорошим способом повысить качество процессов является
товарищеское соревнование между их владельцами. Но если
метрики в разных подразделениях слишком сильно отличаются друг
от друга, это невозможно: нельзя сравнивать яблоки с апельсинами!
Чтобы получить сопоставимые метрики, лучше всего иметь
одинаковое их количество — постараться добиться этого насколько
возможно, не упуская из вида действительно важные элементы
процесса. Метрики должны быть представлены и упорядочены по
приоритету максимально одинаковым образом.
Заодно это позволит ИТ-администрации объединять метрики
различных процессов и создавать отчеты для высшего руководства,
показывающие
эффективность
работы
подразделения,
представленной как деятельность в рамках процесса.
Сосредоточенность на наиболее важном клиенте в каждом
процессе дает возможность еженедельно или ежемесячно оценивать
— и объективно сравнивать — степень удовлетворенности основных
клиентов. ' Наконец, разработка метрик, обладающих внешним
сходством даже при совершенно разном содержании, дает
владельцам процессов ощущение справедливого отношения к ним.
Процессы создают неодинаковую нагрузку на сотрудников.
Управление инцидентами создает напряжение и требует большой
отдачи энергии, а для планирования действий в чрезвычайных
ситуациях нужны аккуратность и педантичность. Несмотря на эти
различия, совместная интеграция метрик позволяет объединить
менеджеров процессов в команду, где будут учитываться
несовпадающие темпы работы и способы ее поощрения за особо
хорошее исполнение.
Пропаганда успехов очень важна с точки зрения морального духа
в организации, она способствует внутреннему росту сотрудников и
вдохновляет их на новые достижения. Если распределение наград
ощущается как несправедливое, это подрывает благоприятную
обстановку.
Интегрированные
наборы
метрик
позволяют
вознаграждать лучших, не вызывая подозрений в предвзятости или
необъективности. Поэтому они имеют большое значение для общей
морали и их нельзя недооценивать.
58
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
6.6. Примеры хороших и плохих метрик
Всем нам наверняка когда-то приходилось слышать от работника
службы Service Desk, что он обязан «закрыть заявку», а если
инцидент не исчерпан, он «откроет новую заявку». Возможно, мы
удивлялись, зачем нам знать что-либо о внутренних механизмах
работы подразделения, и недоумевали, почему собеседнику важнее
открывать и закрывать заявки, чем разбираться с нашим вопросом
или проблемой.
Это пример плохо заданной и, как результат, бесполезной и
неинформативной метрики. В некоторых центрах обработки
вызовов эффективность работы сотрудников оценивают по
скорости закрытия заявок, тем самым побуждая их как можно
быстрее заканчивать разговор, даже если звонящий еще не
удовлетворен. Они быстро догадываются, что каждый новый вызов
снижает среднее время закрытия, а значит, для руководства их
работа выглядит эффективнее.
Расплачиваться
приходится,
конечно
же,
низкой
удовлетворенностью клиентов, так как мы чувствуем, что являемся
лишь объектами, заявками, подлежащими обработке, а не
клиентами, которым требуется помощь. И бизнесу это вовсе не
нужно.
6.6.1. Как здесь исправить положение?
Вот один простой способ — ввести метрику «удовлетворенность
клиентов». Если клиент удовлетворен, даже когда заявка без
необходимости закрывалась и затем открывалась новая, то все
нормально. Это метод «балансирование метрик».
Второй способ заключается в добавлении новой метрики —
сколько звонков делает в неделю один и тот же клиент по одному и
тому же вопросу. Она должна выявить операторов, которые
закрывают заявки только для улучшения статистики.
К сожалению, оба метода не лишены недостатков. С первого
хорошо начинать — удовлетворенность клиентов играет важную
роль. Но все мы знаем, что за этим последует. Заявки будут
закрываться и открываться как новые, а сотрудник станет
разъяснять, что «на этом настаивает руководство». В результате он
получит положительный отзыв от вас как от клиента, но на деле вы
все равно останетесь недовольны, только не им, а анонимным «руководством». Небольшое улучшение для компании в целом!
Второе «решение» еще опаснее. Во-первых, сотрудники,
вероятно, начнут думать, что метрика введена с целью их
«подловить» (а это действительно так!). Во-вторых, для оператора
службы Service Desk и здесь есть выход — просто открывать заявки
разными темами. Тогда получится, что новая метрика не
зарегистрирует ничего подозрительного, т. е. ваша бизнесстатистика потеряет всякий смысл. Вряд ли вы хотите, чтобы у
службы
Глава 6. РАЗРАБОТКА МЕТРИК
59
Service Desk появился стимул неправильно использовать деление
по категориям и темам, — в результате процессы разрешения
инцидентов и исследования рынка будут получать неверные
данные, что может обойтись очень дорого.
6.6.2. Где же выход?
Если использовать методы, о которых говорилось в этой главе, то
первый вопрос, который приходит на ум, — это дал ли владелец
процесса согласие на метрику «время закрытия заявок»? Вероятно,
нет. Почему вообще так важно быстро закрывать заявки? Наверняка
вы и сами можете догадаться об ответе: клиент рад, когда его
проблема решена (если, конечно, она решена— путем открытия
новой заявки эта цель не достигается), центр может обрабатывать
больше заявок для того же числа людей (это, конечно же, неверно,
если несколько заявок представляют собой повторно открытую заявку для того же инцидента).
Следующий вопрос — консультировались ли создатели метрик с
заинтересованными лицами (теми, кто звонит)? Хотят ли эти люди,
чтобы их разговоры с центром обработки вызовов были как можно
короче? Видимо, нет — скорее всего, им интересно не «открытие» и
«закрытие» заявок, а решение проблем.
6.6.3. Существуют ли лучшие метрики?
Должно быть, да. Но прежде давайте подумаем о процессе
создания метрик. Не стоит ли нам вернуться к эскизу,
проконсультироваться с заинтересованными лицами, владельцами
процесса и определить, в чем состоят реальные задачи? И
опираясь на них, попытаться предложить более удачные метрики.
Это не кроссворд, и здесь не начисляются очки за самую
необычную метрику. Вопрос в том, чтобы усовершенствовать
процесс и улучшить его результат для конечного потребителя.
Для начала, не лучше ли будет передавать звонки, которые длятся
больше установленного времени, команде по управлению
проблемами для выяснения причин задержки? Тогда, если удастся
выявить конкретные сложности и придумать, как с ними справиться,
продолжительность вызовов сократится сама собой.
Корень проблемы просто в том, что разработчики метрики не
думали о приоритетах с точки зрения клиента, а сразу решили для
себя, что это лишь способ контролировать персонал службы Service
Desk (или центра обработки вызовов). Если же сотрудники
почувствуют, что их стремление повысить качество обслуживания
получает поддержку, они будут работать усерднее и эффективнее.
Предложив им описать, почему одни звонки требуют больше
60
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
времени, чем другие, вы дадите им некоторые возможности
воздействия на процесс, а в результате поднимется и их моральный
дух — определенный контроль среды этому очень помогает. Этот
«добродетельный»
(в
противоположность
порочному)
круг
продолжится по мере того, как все больше и больше довольных
сотрудников станут передавать свое настроение клиентам
посредством более спокойного тона разговоров, не содержащих
желания «закрыть» и «повторно открыть» заявку.
7
Создание метрик
на практике
В этой главе на примере одного набора показателей
разъясняется подход к обдумыванию и выбору метрик. В
следующей главе, которая называется «Конкретные
метрики для управления ИТ-услугами», представлен
такой набор для всех процессов управления услугами.
Глава 7 служит связующим звеном между теорией,
изложенной в первых шести главах, и реальными
метриками, приводимыми в качестве примеров.
Она необходима, чтобы объяснить, каким образом
выбор показателей согласуется со сделанными
рекомендациями и где он с ними расходится. Это поможет
при решении вопроса о том, использовать ли метрику
«как есть» или ее необходимо модифицировать.
С целью оптимизации работы с метриками
используются специальные схемы.
Из этой главы вы узнаете, как они действуют и что
представляют собой их поля.
Принципы построения метрик объясняются на
примере процесса управления конфигурациями,
который принципиально важен для ITSM и является
одним из центральных управляющих процессов,
определяемых в ISO20000. Обычно в качестве такого
примера используется управление инцидентами,
потому что для него легко придумать полезные (и не
очень) показатели, но рассмотрение слишком простого
процесса принесет мало пользы и даже может
дезориентировать
читателя. Поэтому управление
конфигурациями — более удачный выбор.
62
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
7.1. Основания для выбора метрик
(на примере управления конфигурациями)
В качестве метрик для процесса управления конфигурациями мы
выбрали степень удовлетворенности клиента и еще семь
показателей, отвечающих требованиям, о которых шла речь в
предыдущих главах, — простых, понятных (Keep It Simple Stupid —
KISS), конкретных, измеримых, достижимых, реалистичных и
своевременных (SMART). Учитывалось также их соответствие
задаче, или цели процесса, поэтому в приложениях каждое описание
метрик процесса начинается со следующих слов:
«Соотнесение метрик с задачами процесса — это ключевой шаг в их разработке: он позволяет отличить содержательные метрики от измеримых».
Согласно определению, даваемому библиотекой ITIL (том
«Поддержка услуг»), управление конфигурациями преследует
следующие цели:
1. Отвечать за все конфигурации ИТ в рамках организации и
оказывае
мых ею услуг путем поддержки логической модели ИТинфраструктуры и ИТ-услуг.
2. Предоставлять точную информацию о конфигурациях,
логических
моделях ИТ-инфраструктуры и ИТ-услуг, а также
соответствующую
документацию для поддержки других процессов, таких как
управление
инцидентами, проблемами, изменениями и релизами.
3. Сравнивать записи о конфигурации с инфраструктурой
исправлять
любые несовпадения.
Объединив эти три основных цели, можно на основе принципов,
рассмотренных в главах 1-6, получить одну конкретную цель метрик,
которая формулируется так: «Получать и анализировать
информацию об инфраструктуре ИТ и на основании полученных
данных осуществлять точное и эффективное управление ИТресурсами в соответствии с согласованными стандартами и
потребностями бизнеса». В приведенной спецификации под
«получением» информации об ИТ-инфраструктуре понимается
последовательность шагов по проверке и предоставлению
правильных данных об объектах ИТ-инфраструктуры, а
«управление» ИТ-ресурсами можно рассматривать как их
использование для выполнения задач бизнеса.
Все метрики должны следовать непосредственно из данной цели
— это необходимо для поддержания их измеримости, повышения
простоты, нахождения более конкретных метрик и т. д. Только при
этом условии мы постепенно придем к осмысленным, а не просто
измеримым показателям.
По мере созревания и развития процессов взаимосвязь между их
составляющими будет усиливаться. Когда уровень зрелости
взаимодействия про-
Глава7. СОЗДАНИЕ МЕТРИК НА ПРАКТИКЕ
63
цессов приближается к оптимальному, число метрик начинает
снижаться, так как становятся понятнее реальные контрольные
показатели и все более преобладают составные метрики. А
многочисленные низкоуровневые метрики воспринимаются при этом
как «шум», и потребность в них постепенно сходит на нет. Со
временем эта тенденция приводит к развитию в различных
подразделениях собственных наборов метрик, приспособленных к их
конкретным требованиям.
В приложениях вы найдете цели метрик для ряда процессов,
относящихся к управлению ИТ-услугами. А сейчас рассмотрим
поочередно метрики нашего примера — процесса управления
конфигурациями.
7.1.1. Степень удовлетворенности клиентов
Мы представили диаграмму взаимоотношений с клиентами еще в
предыдущей главе, чтобы подчеркнуть то значение, которое придается
в книге показателю удовлетворенности клиентов. Каждому процессу
сопоставлен «главный», «ближайший», «наиболее важный» или
«ключевой» клиент, хотя все сотрудники по большому счету работают,
чтобы удовлетворить конечного потребителя, для каждого процесса
лучшим и наиболее релевантным его измерителем является
интерфейсный процесс (или процессы), т.е. процесс, при помощи
которого
происходит
взаимодействие
непосредственно
с
потребителем.
Основой для измерения степени удовлетворенности клиентов
всегда служат либо данные опроса, либо отдельные оценки
выполненных работ — результаты процесса. Рекомендуется
установить в каждом процессе точку, в которой результат
заведомо готов (заявка закрыта), так что «ключевой» клиент уже
может поставить оценку.
В нашем случае метрика степени удовлетворенности применяется
к отчетам клиентов, обращавшихся в ИТ с заявками, и к анкетам,
рассылаемым по всей клиентской базе. Приводимые нами оценки
произвольны и при использовании другого метода, вероятно,
оказались бы иными. Существенен здесь сам факт, что этот
показатель измеряется и, как будет показано далее, важен для
руководства компании.
Для определенных процессов, которые непосредственно влияют
на работу клиентов, оценка удовлетворенности еще более
значима. В подобных случаях можно использовать показатель,
относящийся к такому процессу, вместо общего рейтинга для всей
организации. Если же рассылается анкета с вопросами,
относящимися к разным процессам (подразделениям), то, вероятно,
лучше будет не объединять ответы, а распределить их по соответствующим метрикам.
Опросы клиентов играют важную роль: в силу своего общего
характера они позволяют компаниям нацеливаться на клиентов,
которые никогда не имели дела ни со службой Service Desk, ни со
многими другими процессами, предусматривающими обязательную
оценку удовлетворенности. К сожале-
64
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
нию, такие опросы требуют денег и времени (в том числе отнимают
время у клиентов), и если они проводятся слишком часто, это
вызывает раздражение.
Поэтому опросы не могут удовлетворить потребность в
своевременной оценке эффективности процесса управления
услугами. Метрики в этой книге опираются на более «быструю»
обратную связь, получаемую для только что сделанной работы. К
примеру, закрытие инцидента, проблемы или релиза дает клиенту
шанс
прокомментировать
степень
собственной
удовлетворенности, а также высказать рекомендации по
улучшению работы.
В некоторых процессах сложно определить подходящие
контрольные точки. Для них, возможно, понадобится придумать в
той или иной степени искусственный механизм, который все-таки
обеспечит своевременную обратную связь и таким путем решит
проблему опросов. К примеру, удачным решением могут стать
еженедельные встречи по вопросам удовлетворенности с
менеджером «ключевого» процесса — по сути усеченный и более
частый опрос.
В нашей схеме метрики степень удовлетворенности клиентов
оценивается числом в интервале от 0 до 5, где 0 означает
«совершенно не удовлетворен», а 5 — «совершенно удовлетворен».
Целевое значение — 4, опасный уровень — ниже 3.
Что касается процесса управления конфигурациями, то здесь
стоит отметить, что на нашей диаграмме взаимоотношений (см. рис.
6.1) в качестве «главного» клиента показано управление релизами.
Вообще говоря, допустимым выбором было бы и управление
инцидентами, проблемами или изменениями — ведь все эти
процессы тоже упоминаются в формулировке целей управления
конфигурациями. Однако управление релизами особенно важно, так
как оно отвечает за крупные изменения инфраструктуры, которые
обязательно должны быть правильно отражены в CMDB.
Обратите также внимание, что метрика на рис. 7.1 относится к
одному процессу, но сама состоит из трех подпроцессов. Таким путем
обеспечивается измерение не только конечного результата в момент
закрытия релиза, но и важных промежуточных показателей во время
его планирования и реализации. Было бы неплохо изобрести и
другие метрики удовлетворенности клиента для различных
контрольных точек, где участвует процесс. Но не все так просто.
Так, слияние трех метрик может означать, что из-за одной ошибки в
CMDB сразу
три
по
видимости
отдельных
показателя
удовлетворенности окажутся низкими. Наверняка владелец процесса
воспримет это как несправедливость. Однако есть способ избежать
подобного эффекта. Если первая ошибка приводит к ошибке
планирования, то после фиксации этого факта и получения низкой
оценки самое время исправить CMDB. Так мы избавимся от двух
других низких оценок, проделав фактически исключительно
эффективную
Глава 7. СОЗДАНИЕ МЕТРИК НА ПРАКТИКЕ
65
работу по корректировке базы и инициировав запрос об изменении
процесса (с целью предотвратить повторное возникновение той же
ошибки, если это имеет смысл). Результатом может стать очень
высокая оценка в итоговом анализе релиза.
7.1.2. Количество неиспользуемых лицензий
С первого же взгляда видно, что данная метрика конкретнее, чем
большинство других. Лицензии на программное обеспечение —
одна из главных статей расхода для ИТ-подразделений, и их
отслеживание — функция процесса управления конфигурациями,
который помогает обеспечить правильное число лицензий,
принадлежащих компании, используемых и оплаченных ею. Эта
задача оказывает зримое и прямое влияние на финансовую
эффективность ИТ, рассматриваемую с точки зрения бизнеса, и
применяемый подход к ее решению не вполне обычен: мы создаем в
рамках управления конфигурациями конкретный объект измерения,
хотя в большинстве процессов предпочли бы что-либо менее
специфическое.
В данном случае это оправданно, так как показатель прост (KISS),
непосредственно связан с задачей процесса, определенной в ITIL
и ISO20000, и одновременно полезен как точка для проверки общего
уровня корректности CMDB. Чтобы определить правильность числа
лицензий, необходимо убедиться, что в CMDB присутствуют все
учетные элементы (CI), а связи лицензий с CI и пользователями
соответствуют действительности (установить эти связи должным
образом — важнейшая составляющая хорошего управления
конфигурациями).
Есть и другие способы описать то же самое измерение, например,
посчитать процент лицензий, фактически использовавшихся в
прошлом месяце, или число лицензий на ПО, которые не
применялись в течение шести месяцев (так что без этих лицензий
можно обойтись). В определенных отношениях альтернативные
варианты, наверное, даже лучше, но они не такие прямые и
непосредственные, и с ними сложнее определить, какую экономию
даст снижение показателя.
Другим достоинством данной метрики является минимальный
объем усилий, фактически нужных для измерения. Если предстоит
покупка программных инструментов, понадобится, чтобы они могли
предоставлять отчетность не только о приобретенных и имеющихся
(занесенных в базу как CI) лицензиях, но и о связях между
лицензиями и теми, кто ими пользуется. К примеру, о
десятипользовательской лицензии на программный продукт X можно
узнать, что ею пользуются всего шесть человек; тогда следующему
сотруднику, которому устанавливается программа X, будет отдана
одна из свободных лицензий — и не потребуется заказывать
дополнительную лицензию еще на десять пользователей!
Программный
инструмент,
обеспечивающий
корректное
вычисление данной метрики, вероятно, внесет весомый
66
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
вклад в сокращение расходов на лицензии ПО и поддержание связей в
CMDB в актуальном состоянии.
Как много пользы от одной довольно необычной метрики!
7.1.3. Количество RFC, отклоненных из-за ошибочных
данных CMDB
Процессы
управления
изменениями
и
конфигурациями
представлены в ISO20000 как тесно взаимодействующие друг с
другом: RFC (Requests for Change — запросы на изменение1)
опираются на CI. Если соответствующая информация в CMDB
неверна — например, не соответствуют действительности данные о
конфигурации ПО, владельце CI, или даже CI вообще отсутствует, —
RFC может быть отклонен и возвращен автору для повторной подачи.
Если это произойдет из-за сбоя CMDB, неудавшийся RFC будет
подсчитан в составе метрики. Она говорит не только о качестве
поддержки CMDB в актуальном состоянии, но и о том, каким
образом ошибки в базе влияют на другие важные процессы.
Управление изменениями выступает как один из ключевых
клиентов управления конфигурациями, которое, в свою очередь,
зависит от качества операций по поддержке CMDB. Благодаря
данной метрике становится ясно, что CMDB существенна не просто
сама по себе, а как часть функционирования управления услугами в
целом. Важным показателем, парным к данному, является метрика
7.1.7 — число RFC, по которым не было обновления CI: недостаточно
иметь в CMDB 95% корректных записей, если RFC продолжают
отклоняться из-за ошибочных данных CI.
7.1.4. Количество неучтенных конфигураций
Для многих процессов заданы наборы конфигураций вычислительной
среды, а для определенных основных (иногда «эталонных») CI —
ограничения на допустимые диапазоны атрибутов. Проверки,
конечно,
выявляют
конфигурации,
не
соответствующие
авторизованному набору, но они зачастую проводятся раз в полгодагод.
Неавторизованные конфигурации могут быть ничуть не менее
эффективными, чем разрешенные. Однако их использование в
состоянии негативно повлиять на время ремонта и восстановления
аппаратуры и ПО.
К
примеру,
стандартная
конфигурация
32-портового
маршрутизатора заданной мощности подразумевает использование
модели Y от производителя X. Возможно, производитель Z
предлагает более быструю модель, и если процесс приобретения не
контролируется должным образом, она будет зака1
Запрос на изменение — зафиксированное требование клиента на внесение
изменений в любые элементы конфигурации в инфраструктуре или внесение
изменений в процедуры, связанные с инфраструктурой. — Прим. пер.
Глава 7. СОЗДАНИЕ МЕТРИК НА ПРАКТИКЕ
67
зана и установлена в составе инфраструктуры. Но, так как на складе
эталонного аппаратного обеспечения (Definitive Hardware Store —
DHS) нет запчастей для данного компонента, его сбой может привести
к длительному простою и невыполнению SLA. Выявление подобных
неавторизованных конфигураций — а в идеале их недопущение
путем контроля закупок — способно предотвратить эту проблему.
После слияния компаний данный показатель может резко
возрасти из-за различий в используемом ими оборудовании (и ПО),
что будет отражать качество управления конфигурациями. Эти
данные помогут определить, следует ли заменять несовместимые
конфигурации или лучше включить их как новые в соответствующие
процессы, с тем чтобы авторизовать.
Данная метрика также определяет решение о выборе
инструментария
для
управления
вычислительной
средой.
Автоматическое сравнение CI, показывающих разрешенные
конфигурации, с реальными настройками оборудования и
фактически установленным ПО в состоянии выявить немало расхождений, из-за которых показатель поначалу вырастет, но затем,
благодаря структурированному управлению релизами, должен
снизиться до приемлемого уровня.
7.1.5. Количество инцидентов, связанных с некорректными
изменениями из-за неправильно задокументированных CI
Все изменения отражаются в CMDB. Если обновляется, удаляется или
добавляется неверный CI, это способно впоследствии вызвать
инцидент. Ошибка в CMDB может привести к тому, что будет
затронут некорректный CI — с аналогичным результатом.
Когда инцидент закрыт и видно, что его причина имеет
отношение к внесению изменений, она с большой вероятностью
связана и с управлением конфигурациями, но чтобы метрика
принесла пользу этому процессу, связь необходимо установить
достоверно.
Метрика акцентирует внимание на безошибочности и
правильности данных управления конфигурациями, используемых в
управлении изменениями, и обеспечивает тесное взаимодействие
между владельцами двух процессов.
7.1.6. Количество нарушений SLA, вызванных ошибками CMDB
С процессными метриками связана опасность чрезмерной
фокусировки на внутренних механизмах, которая высока и в случае
управления конфигурациями, ведь оно не предполагает
непосредственного взаимодействия с клиентом. Данная метрика
заставляет владельца процесса не забывать о приоритете вклада в
общий уровень обслуживания.
Случаи невыполнения SLA исследуются процессом управления
уровнем обслуживания, а их причины — процессом управления
проблемами. Если оказы-
68
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
вается, что нарушение связано с какой-либо характеристикой CMDB
(например, отсутствующие элементы, неправильные связи, плохая
эскалация из-за неправильной привязки CI к соответствующему SLA —
и это далеко не все), оно отражается в метрике и должно немедленно
стать предметом самого пристального внимания со стороны владельца
процесса управления конфигурациями.
Хотя в большинстве случаев показатель, по-видимому, будет равен
нулю, его существование подчеркивает значимость SLA для
внутренних процессов. При зрелой CMDB соглашения нечасто
нарушаются из-за ошибок внутри базы конфигурационных единиц.
Однако в настоящей книге речь идет об организациях, которые, по
всей видимости, еще не достигли высокого уровня зрелости (иначе бы
у них были все нужные метрики), поэтому мы должны учесть и
ситуации, возможные на ранних стадиях реализации CMDB. В этот
период ошибки базы действительно способны выступать как причина
инцидентов и проблем, в том числе отражающихся на SLA, хотя по
мере взросления организации соответствующую метрику можно и
нужно постепенно ликвидировать в рамках SIP.
Владелец процесса, вероятно, будет следить за всеми
инцидентами, дабы удостовериться, что их причиной не были ошибки
в CMDB. Подобного внимания вполне достаточно для своевременного
привлечения ресурсов, которые помогут устранить проблему, прежде
чем произойдет нарушение SLA.
7.1.7. Количество RFC без обновления CI
Для каждого RFC необходимо обновление CMDB в некоторой точке,
определенной политиками и процессом. Данная метрика
показывает степень соблюдения процедур контроля, которая в
свою очередь влияет на корректность CMDB и — так как не
предоставляется правильная информация о CI — на все
последующие преобразования и релизы.
Показатель легко измерить по отчетам программного
инструмента, используемого для мониторинга инфраструктурных
событий, по крайней мере если соответствующие компоненты
позволяют автоматическое обнаружение. Любой найденный элемент,
отсутствующий в CMDB, по определению не авторизован. Он может
появиться в результате незаконного или некорректного изменения,
не сопровождавшегося обновлением CMDB, либо — это наименее
серьезная причина — по ходу вполне правильно осуществляемой
модификации, когда CMDB еще не обновлена в соответствии с
планом. Очевидно, здесь стоит учитывать первые два случая. Размер
расхождений способен выявить проблемы с безопасностью, а также
области неэффективного управления релизами или изменениями.
7.1.8. Процент некорректных CI
Некорректные CI можно выявлять по сбоям, которые они вызывают в
других
процессах
и
которые
фиксируются
несколькими
рассмотренными выше мет-
Глава7. СОЗДАНИЕ МЕТРИК НА ПРАКТИКЕ
69
риками. Однако необходимо, чтобы процесс управления
конфигурациями не только реагировал на уже обнаруженные
ошибки, но и сам активно повышал качество CMDB. Хотя аудит
физической инфраструктуры, проводимый раз в год, полгода или
даже чаще, дает хорошее представление о серьезности ситуации,
важно организовать регулярную проверку и с помощью метрики
привлечь к ней должное внимание.
Измерение данного показателя, возможно, будет непростой
задачей, а метрика, как мы помним, должна соответствовать
принципу SMART, в том числе быть измеримой (М — measurable).
Инструментальные
средства,
применяемые
в
управлении
инфраструктурными событиями, обычно работают с собственными
базами данных, содержащими как минимум CI для физических
объектов, и разумно сверять с этими записями содержимое CMDB
хотя бы раз в неделю. Дополнительно служба Service Desk могла бы
при каждом обращении проверять данные, касающиеся
позвонившего пользователя, с отнесением всех несоответствий на
счет управления конфигурациями и учетом этих несоответствий
при формировании нашей метрики.
Обязательно нужно будет точно договориться о том, какие именно
измерения будут участвовать в данной метрике, а это зависит от
используемого инструментария. Показатель выражается в
процентах, а не в абсолютных цифрах, поскольку отражает реальное
качество работы процесса конфигурирования.
7.2. Модель данных для измерения метрик
Каждый процесс состоит из ряда подпроцессов, которые способны
возвращать определенное значение при изменении состояния. Это
значение может использоваться как метрика.
Во
всех
процессах
присутствует
метрика
степени
удовлетворенности клиента, поэтому рассмотрим модель данных,
в которой она применяется. В ИТ-подразделении много «внутренних»
процессов,
не
взаимодействующих
непосредственно
с
пользователями ИТ-услуг, и их «клиенты» тоже считаются
внутренними (руководство, другие процессы). Отметим, что в
процессе всегда есть одна или несколько заинтересованных сторон.
Как уже говорилось, в число ключевых клиентов управления
конфигурациями входит процесс управления релизами, поэтому
мы здесь попытаемся дать оценку удовлетворенности клиентов
работой процесса управления конфигурациями с точки зрения
процесса управления релизами.
При разработке метрики может составляться диаграмма,
подобная представленной на рис. 7.1. Она показывает
подсостояния процесса, которые возвращаются в качестве значения
для формирования метрики. Это обычно происходит одним из двух
способов: либо процесс, как в данном случае, возвращает то
значение, которое используется, либо поддерживается счетчик,
увеличивающийся на единицу при каждом переходе в следующее
состо-
70
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
яние. Например, если бы нам было необходимо узнать только число
релизов, мы могли бы не пользоваться возвращаемым значением
степени удовлетворенности, а просто пересчитать все состояния
«полный анализ релиза».
Метрика удовлетворенности клиента, таким образом, полностью
охватывает весь процесс управления конфигурациями. На рисунке
это обозначается двумя стрелками, ведущими от начала и от конца
процесса к подпроцессу измерения показателя.
На рис. 7.1 показаны три подпроцесса управления релизами:
• присвоение CI нового статуса;
• добавление CI в план релиза;
• полный анализ релиза.
Так как CI используются для документирования релиза, они перед
обновлением получают статус «предназначен для релиза», а после
него — «обновляется с релизом». Именно по эффективности этого
процесса и по отчетам о состоянии релиза в ходе его реализации мы
судим о качестве управления конфигурациями.
Три названных подпроцесса управления релизами интересуют нас
как те точки, где используются CI (результат процесса управления
конфигурациями). Именно здесь владелец подпроцесса (или
человек, которому делегирована эта задача) сможет оценить вклад в
него со стороны управления конфигурациями.
Рис. 7.1. Метрика степени удовлетворенности клиента
для процесса управления конфигурациями
Глава 7. СОЗДАНИЕ МЕТРИК НА ПРАКТИКЕ
71
Это будет субъективная оценка, равно как и все остальные,
относящиеся к удовлетворенности клиентов. Владелец процесса
сформирует ее после того, как обдумает, насколько правильной и
актуальной была информация CI, насколько легко было найти CI,
затронутые конкретным релизом, включить их «желаемое
состояние» в план релиза, а затем после завершения релиза
обновить их статус. Наконец, при анализе релиза владелец процесса
'сможет вернуть суммарное значение, показывающее, какой вклад
внес в этот релиз процесс управления конфигурациями.
Таким образом, каждый релиз передаст процессу управления
конфигурациями три показателя удовлетворенности клиентов,
относящиеся к стадиям планирования, реализации и анализа релиза
заинтересованным «лицом» — процессом управления релизами. В
результате формируется всестороннее понимание привносимого
вклада.
7.3. Приоритеты и подсчет метрик
Чтобы характеризовать каждый процесс за каждый период времени
всего одним показателем, нужен метод комбинирования
метрических значений. Таких методов масса, здесь в качестве
примера приводится всего один. Мы присвоим нашим восьми
метрикам приоритеты от 1 до 8 (по возрастанию значимости) и
затем будем использовать эти значения как вес.
Одни метрики выражаются в процентах, другие могут принимать
практически любые значения, поэтому их нельзя применять
непосредственно. Судить об их успехе или неудаче позволяет Цель.
Система оценки выдает три значения (как в «светофоре»
сбалансированной карты показателей): красный цвет (-1)
соответствует оценке, которая далека от целевой величины и ниже
опасной (она служит здесь пороговой), желтый (0) — оценке в
интервале между опасным и целевым значениями, зеленый (1) —
равной целевой или превосходящей ее. Теперь остается умножить
эти оценки на их вес и просуммировать результаты.
Управленческое преимущество здесь заключается в возможности
переназначать со временем приоритеты метрик, отражая таким
путем изменения, происходящие с требованиями бизнеса или
зрелостью процесса. В начале существования процесса
управления конфигурациями было бы большим оптимизмом
ожидать значительного сокращения числа инцидентов благодаря
поддержке других процессов с помощью качественной CMDB.
Соответственно, для данной задачи целевое и опасное значения
разумно установить мягкими (сравнительно легко достижимыми), а
приоритет — низким. Когда зрелость управления конфигурациями
достигает того уровня, при котором процент неправильных CI всегда
невелик, приоритет этой метрики (вероятно, очень высокий на
раннем этапе) можно понизить, а приоритет сокращения числа
инцидентов поднять, побуждая владельца процесса к дальнейшему
совершенствованию.
72
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Постановка целей — задача руководства, ее выполнение требует
способности рассуждать и анализировать. Эталонный (или
базовый) показатель процесса может быть как близким к
оптимальному, так и очень далеким от него. Чтобы устанавливать
достаточно сложные, но все же реалистичные цели, менеджер
должен понимать людей, технологии и степень зрелости процесса.
Простое повышение какой-либо метрики на определенное значение,
скажем на 5%, — неэффективная мера, поскольку для одних
процессов выполнить новые нормативы будет легко, а для других —
невозможно. На начальной стадии, при незрелом процессе,
подобные грубые приближения допускаются, но руководство должно
стремиться к более глубокому пониманию всех процессов, чтобы по
мере их созревания устанавливать цели в соответствии с текущей
ситуацией.
Как уже говорилось, существует много способов рассчитать
итоговую оценку. Самый простой таков:
где PN — приоритет N-й метрики, RN — результат за данный период,
который может быть равен -1 (зеленый), 0 (желтый) или 1
(красный).
Таблица 7 1
Данные метрик
IfciiMHillllLll
? *
•**
С
1. Степень удовлетворенности клиентов
<3
4
г
3
2
Количество неиспользуемых лицензий
>10
5
3
2
1
3
Количество RFC, отклоненных из-за ошибочных
данных CMDB
>20
10
15
7
0
4
Количество неавторизованных конфигураций
>15
5
2
8
1
Количество инцидентов, связанных с некор-
>6
0
0
6
1
>2
0
0
1
1
5
-1
ректными изменениями из-за неправильно
задокументированных CI
б
Количество нарушений SLA, вызванных
ошибками CMDB
7
Количество RFC без обновления CI
<90
95
20
4
1
8
Процент некорректных CI
>100
40
10
Ь
1
73
Глава 7. СОЗДАНИЕ МЕТРИК НА ПРАКТИКЕ
Для данных табл. 7.1 расчет выглядит так:
8xl
5 x l = -3 + 2 + 0 + 8 + 6 +1 + 4 + 5 =
Итоговый23.
показатель = 3 х (-1) + 2xl +
6xl +
lx
7xO
4xl
Диапазон возможных значений здесь — от 36 до -36: если бы все
значения были зелеными (+1), сумма составила бы (1 + 2 + 3 + 4 +
5 + 6 + 7 + 8) х х 1 = 36, а если красными (-1), то -36.
Чтобы сделать итоговый показатель независимым от числа
метрик на процесс, можно просто разделить его на это число. В
данном случае получится 23/8=2,9 при максимуме 4,5. Другой
вариант — разделить полученную сумму на максимальное
значение и работать с процентами, тогда показатель составит 0,64,
или 64%. Оба результата сравнимы с аналогичными для других
процессов. Итоговая таблица для компании могла бы иметь следующий вид:
Таблица 7.2
Подсчет метрик
Управление конфигурациями
+0,71
+0,68
+0,03
Управление изменениями
+0,84
+0,88
-0,04
Управление уровнем обслуживания
+0,55
Управление финансами
-0,24
+0,47
+0,08
-0,34
+0,10
Подобный подход способен благоприятно влиять на уровень
зрелости каждого процесса и, как следствие, всего ИТподразделения.
Как было показано выше, организации могут выбирать из
нескольких
методов
представления
результатов
в
количественной форме. Главное здесь — еще до начала каких бы
то ни было измерений иметь четкое представление о том, как
пользоваться этими методами и как интерпретировать полученные
результаты.
Таблица 7.3 демонстрирует количественную метрическую схему
в формате, который можно использовать при работе с
управленческой информацией. Метрики пронумерованы, чтобы
впоследствии было удобно на них ссылаться.
Таблица 7.3
Метрическая схема для управления конфигурированием
Опасность
Цел Возможные
ь значения
1. Степень удовлетворенности клиентов
<з
4
0-5
2. Количество неиспользуемых лицензий
>10
5
Не ограничено
74
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Окончание табл. 7.3
Опасн
ость
Цель
Возможные
значенния
3. Количество RFC, отклоненных из-за ошибочных данных
CMDB
>20
10
Не ограничено
4. Количество неавторизованных конфигураций
>15
5
Не ограничено
5. Количество инцидентов, связанных с некорректными
изменениями из-за неправильно документированных CI
>б
0
Не ограничено
6. Количество нарушений SLA, вызванных ошибками CMDB
>2
0
Не ограничено
<90
95
>100
40
Vетрика
•
7. Количество RFC без обновления CI
8. Процент некорректных CI
1
Не ограничено
0-100
В приложениях вы найдете множество метрик в фиксированной
форме представления данных, которые легко можно использовать в
метрических схемах, подобных приведенной в табл. 7.3.
Рекомендации по работе с такими схемами даются в разделе 10.4.1
«Представление метрик».
__________________________________________________________
8
Специфические метрики
для управления ЙТуслугами
В предыдущих главах мы обсудили методику, которая
применялась при разработке метрик, представленных в
этой книге. Теперь перейдем к конкретным примерам
метрик, подходящих для процессов управления ИТуслугами. Последние включают не только области
процессов ITIL, но и управление программами и
проектами (оно вынесено в особый раздел), и функциональную поддержку пользователей. В отличие от
библиотеки ITIL, где процессы подразделяются на
относящиеся к поддержке услуг и к предоставлению услуг,
мы разделим их на три группы в зависимости от типа
целей.
Краткосрочным
целям
соответствуют
операционные процессы, среднесрочным — тактические,
долгосрочным — стратегические.
Метрики для операционных процессов будут
относиться к:
• управлению инцидентами;
• службе Service Desk;
• управлению конфигурациями;
• управлению изменениями;
• управлению релизами (в том числе приложениями);
• управлению операциями (в том числе
инфраструктурой).
Метрики для тактических процессов будут относиться
к:
• управлению уровнем обслуживания;
• управлению проблемами;
• управлению финансами для ИТ-услуг;
• управлению мощностями;
• управлению непрерывностью предоставления ИТуслуг;
76
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
• управлению доступностью;
• управлению информационной безопасностью.
Метрики для стратегических процессов управления услугами будут
относиться к:
• оценке перспектив развития бизнеса;
• программе постоянного улучшения качества обслуживания
(Service
Improvement Programme — SIP);
• управлению рисками;
• управлению документацией;
• компетентности, осведомленности, обучению (Competence,
Awareness
and Training — CAT).
В заключительном подразделе перечислены метрики для
управления программами и проектами.
Подробные описания всех метрик приводятся в приложениях, где
дается их определение, объяснение и обоснование. Номер
приложения для каждого процесса указан в скобках.
В приложениях для каждого процесса описываются его цели,
формулируется назначение и указывается наиболее вероятный
владелец, а затем перечисляются конкретные задачи.
Каждой задаче соответствуют одна или более метрик, а каждой
метрике — ровно одна метрическая задача (та задача процесса,
выполнение которой оценивается с помощью данной метрики).
Метрики группируются по задачам.
Приводимые в книге метрики — это примеры, и их можно
модифицировать в соответствии с моделями работы или наборами
требований конкретных организаций, опираясь на принципы,
описанные в первых восьми главах. Впрочем, не возбраняется
использовать их и как есть. Примеры представлены так, как их можно
было бы реализовать в табличном процессоре. Многим
организациям будет удобнее автоматизировать сбор, построение
графиков
и
распространение
метрик
с
помощью
специализированных программ, баз данных и веб-серверов. Но этот
механизм не меняет природу самих метрик, поэтому во всей книге
используется табличный метод.
Таблицы, в которых описываются метрики для управления ИТуслугами, содержат следующие поля:
• Метрика — максимально простое описание метрики. Вслед
за ним
приводятся в фигурных скобках {} используемые единицы.
• Описание — краткая характеристика метрики в дополнение к
назва
нию.
• Спецификация — краткое разъяснение, что и как измеряется.
• Обоснование — объяснение, чем полезна данная метрика и
каково ее
значение.
Глава 8. СПЕЦИФИЧЕСКИЕ МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
77
• Аудитория — перечень тех, кому данная метрика
предположительно
будет предоставлять полезную информацию.
• Ограничения — любые обстоятельства, представляющие
препятствие
для применения или интерпретации метрики.
• Опасное значение — условие, при котором показатель
отображается
красным цветом (что сигнализирует о возможных проблемах в
области,
которая измеряется данным показателем).
• Цель — значение метрики, к которому предлагается
стремиться.
• Возможные значения — перечень значений, которые может
принимать
метрика.
Последние три поля являются числовыми, что позволяет
использовать метрику в информационной системе управления. Все
значения, приводимые далее, придуманы для воображаемой
организации и должны подгоняться под вашу ситуацию. Как именно
задать пороговые величины, зависит от результатов бенчмаркинга,
уровня допустимых отклонений, установленного владельцем
процесса, и амбициозности поставленных задач. В настоящей книге
поля «Опасность» и «Цель» заполнены просто для полноты и
связности изложения.
В поле Опасность задается пороговая величина, которая
сигнализирует владельцу процесса о проблеме, требующей
изучения. Первоначально ее значение устанавливается по
результатам бенчмаркинга — в данной книге цифры приводятся для
иллюстрации с таким расчетом, чтобы графики в разделе 10.4.1
соотносились с метриками. В первой метрике «Степень удовлетворенности клиентов» порог должен включаться при уровне
удовлетворенности меньше 3. Это означает, что положение намного
хуже, чем определено целевым значением. Если такой механизм
кажется вам запутанным, имеет смысл приравнять опасное
значение к целевому и работать только с одной пороговой
величиной.
Цель — это тот уровень, к которому договорились стремиться
владелец и непосредственные исполнители процесса. Как уже
упоминалось, согласование происходит после того, как бенчмаркинг
выдаст достижимые показатели (до PIR — анализа результатов
внедрения). Эталонные значения можно вывести из стандартов
рынка (основанных на данные других похожих компаний) или из
результатов,
достигавшихся
в
прошлом.
Опираясь
на
предполагаемый потенциал улучшения можно установить конкретное
целевое значение.
Можно было бы также ввести поле Предупреждение со
значением, скажем, 3,5, указывающим, что уровень близок к
целевому, и эту точку установить в качестве порогового значения.
Возможные значения — это диапазон, в который попадает
метрика. Для процентов он обычно указывается как 0-100, хотя
некоторые показатели могут принимать значение более 100% и
тогда это должно быть отмечено.
78
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Обозначение «не ограничено» соответствует диапазону, не имеющему
каких-либо очевидных пределов.
Значения представляют собой числа или проценты. Во многих
случаях число можно преобразовать в процент, сравнив его с общей
суммой. Типы значений метрик — числа или проценты —
определяются исходя из конкретной ситуации.
Во всех случаях значения измеряются периодически согласно
требованию Т (Timely — своевременный) в SMART, т. е. каждый
день, неделю, месяц. Процент может быть либо фиксированным,
либо скользящим средним. Большинство значений будут меняться
на протяжении времени.
Опасные значения всегда выше или ниже целевых. В зависимости
от ситуации в компании, относительной зрелости организации и
момента времени опасное значение может повышаться или
понижаться.
Измерение процессов очень важно, без него невозможно понять,
улучшается ли положение. Постепенному развитию метрик в
направлении все более полного соответствия нуждам организации
помогает непрерывная программа по улучшению услуг, о которой
рассказывается в разделе 8.3.2. Одним из главных преимуществ
внедрения процессов «как есть» является возможность сравнить
опыт и даже контрольные данные с другими организациями, выбравшими тот же путь.
Стандарт ISO20000 и его национальные эквиваленты в ряде
стран (например, SANS15000 в Южной Африке, AS8018 в Австралии),
а также COBIT и Six Sigma поддерживают применение метрик,
поэтому их внедрение в процессы управления услугами поможет
быстрее достигнуть целей этих процессов.
8.1. Метрики для операционных процессов
управления услугами
8.1.1. Управление инцидентами (А)
Метрики для управления инцидентами:
• Процент инцидентов, решенных на первой линии поддержки.
• Средняя продолжительность обработки инцидента до момента
эскалации.
• Процент инцидентов, некорректно назначенных на сотрудников
службы поддержки.
• Процент инцидентов, решенных в течение заданного времени
согласно приоритету.
• Среднее время ответа второго уровня поддержки.
• Среднее время решения инцидента.
• Процент переназначенных инцидентов.
Глава 8. СПЕЦИФИЧЕСКИЕ МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
79
• Процент неправильно классифицированных инцидентов.
• Процент обращений, поступивших к специалистам службы
поддержки «напрямую», минуя первый уровень.
• Степень удовлетворенности клиентов.
• Процент звонков, являющихся запросами на оказание услуг.
• Процент инцидентов, правильно решенных с первого раза.
• Процент инцидентов, решенных проактивно.
8.1.2. Служба Service Desk (В)
Метрики службы Service Desk:
• Число звонков на специалиста.
• Процент звонков, закрытых с первого раза (на одного
специалиста).
• Число звонков «не по адресу».
• Число звонков, заявки по которым были эскалированы на
второй уровень поддержки.
• Степень удовлетворенности клиента.
• Число звонков, заявки по которым были эскалированы на
третий уровень поддержки.
• Среднее время ожидания ответа на звонок.
• Средняя продолжительность попытки дозвониться до клиента
(на один звонок).
• Процент обращений через веб.
• Процент неправильно эскалировнных заявок.
• Процент звонков, которые были прерваны пользователями.
• Процент звонков, по которым были открыты заявки на
устранение проблемы.
• Процент инцидентов, поступивших от процесса управления
событиями.
• Процент звонков, правильно назначенных с первого раза.
8.1.3. Управление конфигурациями (С)
Метрики для управления конфигурациями:
• Число неиспользуемых лицензий.
• Число RFC, не выполненных из-за неверных данных в CMDB.
• Число неавторизованных конфигураций.
• Число инцидентов, связанных с невыполнением изменений изза не
правильно задокументированных CI.
• Число нарушений SLA, вызваных ошибками CMDB.
• Число RFC, по которым не было обновления CI.
80
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
• Процент некорректных CI.
• Степень удовлетворенности клиентов.
8.1.4. Управление изменениями (D)
Метрики для управления изменениями:
• Процент изменений, которые не удалось выполнить.
• Процент отклоненных RFC.
• Число неавторизованных изменений.
• Число невыполенных изменений.
• Простои во время изменений.
• Число неудачных изменений без плана возвращения в исходное
состо
яние.
• Процент изменений, выполненных вовремя.
• Процент изменений, вызвавших инциденты.
• Число предложений Консультативного комитета по изменениям
(Change
Advisory Board — CAB), не реализованных вовремя.
• Степень удовлетворенности клиентов.
• Число экстренных изменений.
• Число изменений, не принесших ожидаемых результатов.
8.1.5. Управление релизами (Е)
Отметим, что в управление релизами входит деятельность,
описанная в публикации ITIL по управлению приложениями:
основная масса релизов, с которыми мы сталкиваемся на практике,
— это релизы приложений. Однако в конечном итоге они все-таки
являются релизами и тем самым относятся к компетенции процесса
управления релизами, как описано в ключевых публикациях ITIL.
В этом разделе мы сначала рассмотрим общие, более
высокоуровневые вопросы управления релизами, а затем — детали
поддержки и разработки приложений.
Метрики для управления релизами включают:
• Число установленных программных пакетов, отсутствующих в
DSL.
• Число срочных релизов.
• Число инцидентов, вызванных новым релизом.
• Процент своевременных релизов.
• Число непротестированных релизов.
• Средние трудозатраты на релиз.
• Число неиспользуемых лицензий на ПО.
• Процент точности оценки трудозатрат на релиз.
• Степень удовлетворенности клиентов.
Глава 8. СПЕЦИФИЧЕСКИЕ МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСПУГАМИ
81
Поддержка приложений (Е.1)
Метрики для поддержки приложений:
• Число проанализированных программных ошибок.
• Число оптимизаций.
• Число приложений/ревизий, выпущенных в производство.
• Число учебных занятий для конечных пользователей.
• Число дефектов, обнаруженных по журналам регистрации.
• Число временных решений, протестированных и выпущенных в
произ
водство.
• Число временных решений, возвращенных для доработки.
Разработка приложений (Е.2)
Метрики для разработки приложений:
• Число ошибок, выявленных при разработке или тестировании.
• Число ошибок, исправленных при тестировании.
• Число зарегистрированных ошибок, которые были исправлены.
• Число приложений/ревизий, принятых к использованию.
• Число приложений/ревизий, отклоненных службой поддержки
прило
жений.
• Число разработок приложений, одобренных компанией.
• Число успешных сборок приложений.
• Число дней, потраченных на развертывание приложения.
8.1.6. Управление операциями/инфраструктурой И КГ (F)
Управление операциями рассматривается в ITIL как составная часть
управления инфраструктурой ИКТ, которое, в свою очередь,
включает разработку и планирование, ввод в эксплуатацию,
операции и техническую поддержку. Однако представляется более
логичным приписать этапы разработки существующим процессам
управления изменениями или релизами, и тогда управление
операциями в чистом виде окажется частью управления ИТ-услугами.
Но процесс по определению не может заниматься инфраструктурой
— это следует из разграничения процесса, продуктов и
функциональных обязанностей персонала. По данной причине мы
вводим группу процессов, называемую «Управление операциями».
Рассматривая управление инфраструктурой ИКТ в рамках
процесса управления операциями, мы используем традиционную
классификацию, и это должно помочь читателям, недостаточно
знакомым с ITIL. Метрики для управления инфраструктурой ИКТ:
• Число планов, одобренных компанией.
• Число планов, не готовых для одобрения.
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
82
• Отставание от плана внедрения.
• Число проблем, возникших при внедрении.
• Число серьезных или критических событий на один
управляемый
объект.
• Число событий, угрожающих информационной безопасности.
• Число сбоев при выполнении заданий/скриптов/резервного
копиро
вания.
• Число инцидентов, вызванных изменениями, которые возникли
в ре
зультате выполнения операций.
• Степень удовлетворенности клиентов.
8.2. Метрики для тактических процессов
управления услугами
8.2.1. Управление уровнем обслуживания (G)
Метрики для управления уровнем обслуживания:
• Число случаев нарушения SLA.
• Число случаев, когда SLA находится под угрозой нарушения.
• Процент SLA, требующих изменения.
• Число пересмотров SLA, произведенных своевременно.
• Число нарушений SLA по вине внешних подрядчиков,
осуществляющих
поддержку.
• Затраты на предоставление услуг.
• Число услуг, не охватываемых SLA.
• Число еще не согласованных операционных соглашений об уровне
услуг
(OLA) и внешних договоров (UC).
• Степень удовлетворенности клиентов.
• Время между выработкой требований по уровню обслуживания
(SLR)
и соглашением SLA.
8.2.2. Управление проблемами (Н)
Необходимо
отметить
значительное
перекрытие
между
управлением проблемами и другими тактическими процессами
управления ИТ-услугами: управление проблемами занимается
всеми трудностями, а управление мощностями или доступностью —
теми, которые связаны с соответствующими областями. Это
означает, что многие метрики общего характера можно легко
преобразовать в специфические. Ниже мы представим важнейшие
«об-
Глава 8. СПЕЦИФИЧЕСКИЕ МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
83
щие» и «специфические» проблемы, сохранив возможность
распространения «общих» проблем на конкретные области. Метрики
для управления проблемами:
• Число решенных проблем.
• Число инцидентов, разрешенных при помощи базы данных, где
описа
но решение аналогичных задач.
• Общее число инцидентов.
• Общее время неработоспособности пользователей.
• Число RFC, инициированных процессом управления
проблемами.
• Среднее число открытых проблем.
• Среднее время закрытия проблемы.
• Процент инцидентов, которые не удалось связать с проблемой.
• Число проблем, не решенных в течение заданного времени.
• Степень удовлетворенности клиентов.
• 5 категорий инцидентов, по которым было больше всего
обращений за
отчетный период.
• Число инцидентов, разрешаемых путем обучения
пользователей.
• Затраты на решение проблемы.
8.2.3. Управление финансами для ИТ-услуг (I)
Метрики для управления финансами:
• Процент учитываемых расходов на ИТ.
• Число изменений, сделанных в алгоритме начисления платы.
• Задержки в создании финансового отчета.
• Задержки в создании ежемесячного прогноза.
• Степень достоверности (в процентах) последнего
финансового прог
ноза.
• Степень достоверности (в процентах) финансового прогноза на
преды
дущий квартал.
• Совокупная стоимость владения (Total Cost of Ownership — TCO)
ИТ.
• Число жалоб, касающихся затрат на ИТ.
• Число вопросов, касающихся затрат на ИТ.
• Степень удовлетворенности клиента.
Для целей IS020000 этого достаточно. Возможно, некоторые ИТподраз-деления пожелают пойти дальше и стать центрами
получения прибыли1.
1
Центр получения прибыли — центр ответственности, для которого ведется
обособленный учет как затрат, так и доходов. Результаты его деятельности
оцениваются на основе разности между доходами и расходами. — Прим. пер.
84
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
8.2.4. Управление мощностями (J)
Метрики для управления мощностями:
• Число нарушений SLA из-за недостаточно быстрого
обслуживания.
• Число нарушений SLA из-за недостаточной производительности
компо
нента.
• Число инцидентов, вызванных недостаточной
производительностью
или мощностью.
• Стоимость разработки плана развития мощностей.
• Число незапланированных приобретений аппаратных средств,
нужных
для повышения производительности.
• Степень достоверности (в процентах) плана предстоящих
расходов.
• Процент избыточной производительности ИТ.
• Процент CI, для которых ведется мониторинг
производительности.
• Степень удовлетворенности клиентов.
• Соотношение (в процентах) между общей и ожидаемой загрузкой
ИТ-ресурсов.
8.2.5. Управление непрерывностью предоставления ИТ-услуг (К)
Метрики для управления непрерывностью предоставления ИТ-услуг
(IT Service Continuity — ITSC):
• Число услуг, не охватываемых планом ITSC.
• Задержка с подготовкой/обновлением плана ITSC.
• Задержка с тестированием плана ITSC.
• Число проблем, выявленных при последнем тестировании и
еще не
решенных.
• Результаты опроса по осведомленности о непрерывности
предоставле
ния ИТ-услуг проведенного выборочно — процент
удовлетворительных
ответов.
• Число выявленных за данный период проблем, которые ставят
под уг
розу план ITSC.
• Число писем, предназначенных для конкретной группы
сотрудников.
• Число неверных записей в справочнике группы кризисного
контроля.
• Запаздывание готовности резервных мощностей.
• Степень удовлетворенности клиентов.
8.2.6. Управление доступностью (L)
Многие метрики управления доступностью обязаны своим
происхождением жизненному циклу инцидентов — ведь те самым
непосредственным образом связаны с периодами полной или
частичной
недоступности.
В
ключевыхпубликациях
ITIL
терминология, относящаяся к жизненному циклу инцидентов, не
вполне последовательна, и здесь мы представляем ее улучшенный
вариант, позволивший обнаружить целый ряд метрик. В частности,
название метрики MTTR у нас расшифровывается не как Mean Time to
Repair Downtime (среднее время ликвидации простоя), а как Mean
Time to Restore (среднее время восстановления доступности).
Метрики для управления доступностью:
• Время простоя, недоступности услуг.
• Время недоступности компонентов.
• Время обнаружения инцидента.
• Время реагирования на инцидент.
• Время восстановления при инциденте.
• Время восстановления после инцидента.
• Время возобновления обслуживания после инцидента.
• Время разрешения инцидента.
• MTBSI (Mean Time Between System Incidents — среднее время
между
системными инцидентами).
• MTTR (Mean Time to Repair Downtime — среднее время
ликвидации
простоя. Mean Time to Restore — среднее время
восстановления до
ступности) .
• Время простоя в критические периоды.
• Время недоступности услуг внешнего подрядчика.
• Время недоступности компонентов, принадлежащих внешнему
подряд
чику.
• Время возобновления недоступных услуг.
• Число повторных сбоев.
8.2.7. Управление информационной безопасностью (М)
Метрики для управления информационной безопасностью:
• Число инцидентов, связанных с информационной
безопасностью.
• Число решенных проблем, связанных с информационной
безопаснос
тью.
• Число решенных проблем, выявленных в ходе аудита и
внутренних
проверок.
• Процент своевременно проведенных проверок и аудитов.
• Число выявленных рисков (предостережения и новые угрозы).
• Процент SLA, где явно оговорены вопросы информационной
безопас
ности.
• Процент внешних договоров, где явно оговорены вопросы
информаци
онной безопасности.
86
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
• Число выявленных проблем релиза, связанных с
информационной безо
пасностью релиза (возвраты к исходному состоянию/вирусы и
т.д.).
• Число изменений, которые были по соображениям
информационной
безопасности отменены (и система возвращена в исходное
состояние).
• Скорость установки патчей, связанных с информационной
безопас
ностью.
8.3. Метрики для стратегических процессов
управления услугами
8.3.1. Метрики для бизнес-планирования (N)
Целью
метрик
бизнес-планирования
является
оценка
воспринимаемого качества обслуживания (Quality of Experience,
QoC) — мера удовлетворенности бизнеса, соотнесенная с его
потребностями.
Воспринимаемое
качество
обслуживания
обеспечивется
следующим образом:
• приведение ИТ-услуг в соответствие с потребностями бизнеса
и его
клиентов;
• улучшение качества этих ИТ-услуг;
• сокращение расходов на оказание этих услуг.
В рамках управления непрерывностью бизнеса описываются
обязанности и возможности, с помощью которых менеджер
компании может улучшить одну из ключевых услуг, привносящих
вклад в продуктивность и эффективность бизнеса. Это может быть
достигнуто с помощью:
• изменений в ИТ-инфраструктуре; такие изменения способны
повлиять
на формы ведения бизнеса и непрерывность бизнес-операций,
однако
важно, чтобы руководители бизнеса обращали на них
внимание и за
ботились о мерах против неблагоприятных побочных эффектов;
• радикальной трансформации бизнес-практики, в результате чего
будет
обеспечен контроль деятельности ИТ-подразделения и его
интеграция
с бизнесом;
• партнерских и аутсорсинговых соглашений.
К бизнес-планированию относятся четыре процесса:
1) управление взаимоотношениями с бизнесом;
2) управление взаимоотношениями с поставщиками;
3) планирование, анализ и развитие;
4) взаимодействие, обучение и информирование.
Глава 8. СПЕЦИФИЧЕСКИЕ МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
87
Следующие три метрики предназначены для оценки бизнеспланирования в целом:
• Средние затраты на предоставление одной услуги.
• Степень удовлетворенности клиента.
• Знание бизнеса сотрудниками ИТ-подразделения.
Еще 13 метрик относятся к определенным бизнес-процессам, таким
образом, общее число метрик для бизнес-планирвоания — 16.
Управление взаимоотношениями с бизнесом (N.1):
• Число жалоб на обслуживание.
• Число невыполненных действий с момента последней проверки
данно
го сервиса.
Управление взаимоотношениями с поставщиками (N.2):
• Максимальное число инцидентов, связанных с одним
поставщиком.
• Процент постоянных поставщиков, удовлетворяющих
стандартам (на
пример, ISO20000).
• Процент проверок качества услуг поставщиков на соответствие
опреде
ленным требованиям, проведенных в срок.
• Число нерешенных проблем, относящихся к поставщикам.
Управление поставкой услуг (N.3):
• Минимальная оценка степени удовлетворенности клиентов.
• Число инцидентов.
• Степень удовлетворенности клиентов.
Планирование, анализ и развитие (N.4):
• Число проблем, выявленных при окончательной проверке
плана.
• Число планов, одобренных для реализации.
Взаимодействие, обучение и информирование (N.5):
• Число действий, предусмотренных планом информирования,
которые
не были выполнены в срок.
• Процент ИТ-персонала с неоптимальным для занимаемой
должности
уровнем подготовки.
8.3.2. Постоянно действующая программа по
улучшению услуг (0)
Постоянно действующая программа по улучшению услуг (Continuous
Service Improvement Programme — SIP) охватывает все процессы ИТподразделения. Вообще в сложных системах нежелательно менять
сразу многое: это часто
88
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
приводит к негативным последствиям, и трудно определить, какое
именно изменение отвечает за тот или иной результат.
По
этой
причине
в
SIP
приоритетность
изменений
устанавливается в зависимости от эффективности изменяемого
процесса и его значимости для бизнеса.
В разделе 4.4 стандарта 18020000-1:2002 рассматриваются
действия, необходимые на стадии постоянного улучшения
(соответствующей последнему элементу в стандартном цикле
Деминга Plan — Do — Check — Act — «Планирование — Выполнение
— Проверка — Действие»). Результаты метрик, описанных в
настоящей книге, позволят выявить процессы, наиболее нуждающиеся в улучшении. Влияние этих процессов можно будет
обсудить с представителями бизнес-подразделений и оценить по
степени соответствия SLA, а на основе полученных результатов
разработать план для следующего цикла. Согласно рекомендациям
ISO20000 такой план выполняется и оценивается как проект. По
завершении проекта эффективность плана может быть измерена с
помощью тех самых метрик и SLA, которые показали наличие
недостатков. Проверка плана, таким образом, обеспечивает
структуру улучшений для следующей программы SIP.
Как видим, SIP точно так же подчиняется циклу Деминга, как и
реализация
других
процессов.
Следовательно,
можно
рассматривать саму программу по улучшению как процесс и
составить для нее перечень метрик, который позволит ее
контролировать и отслеживать реальный прогресс. Владельцам
процессов важно проводить их модификацию в рамках процесса
управления изменениями, чтобы обеспечить ее отражение в
метриках SIP наряду с формальными элементами программы.
Метрики для SIP:
• Общая степень удовлетворенности клиентов.
• Процент экономии средств, достигнутой благодаря SIP
последнего про
цесса.
• Процент процессов, для которых SIP задерживается.
• Число действий, которые были одобрены, но не выполнены и не
достиг
ли цели.
• Число невыполненных действий, которые были записаны в
плане ин
формирования SIP.
• Число одобренных исправлений в политиках, планах и
процедурах уп
равления услугами.
• Число улучшений, внесенных владельцами процессов не в
рамках цик
ла SIP.
• Общий прогресс (в процентах) с момента последнего
бенчмаркинга.
• Число рекомендаций по улучшению, полученных от владельцев
других
процессов.
• Число изменений, требуемых для улучшения процесса.
• Число SIP, запланированных, но не осуществленных в срок.
Плавав. СПЕЦИФИЧЕСКИЕ МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
89
8.3.3. Управление рисками (Р)
Управление рисками подпадает под общую политику компании в этой
области. Решения о рисках в ИТ опираются на потребности
бизнеса — иначе невозможно найти баланс между приемлемым
уровнем опасности и затратами. В рамках управления услугами
управление рисками является компонентом нескольких различных
процессов:
• Управление доступностью — риск простоев.
• Управление непрерывностью предоставления ИТ-услуг —
риск по
терь в результате катастрофы в контексте плана по
непрерывности
бизнеса.
• Управление изменениями — риск неконтролируемых
изменений.
• Управление проблемами — риск повторения инцидентов,
приводящих
к простою и иному ущербу.
• Управление информационной безопасностью — риск
нарушений
безопасности, вызывающих неприемлемые простои и иной
ущерб.
• Управление инцидентами — риск инцидентов, приводящих к
недо
ступности услуг, которые необходимы для нормального
функциониро
вания бизнеса.
Все эти риски исследуются лишь постольку, поскольку
соответствующие
метрики
показывают
успешность
функционирования процессов. В рамках бизнес-планирования
управление рисками и оценка риска выполняемых операций
должны быть привязаны к требованиям бизнеса.
Метрики для управления рисками:
• Процент CI, охватываемых анализом воздействий на бизнес
(Business
Impact Analysis — BIA).
• Процент документов BIA, не проверенных в течение
требуемого вре
мени.
• Процент процессов, подлежащих оценке со стороны
операционного
риска (Operational Risk Assessment — ORA).
• Число инцидентов в связи с рисками, не учтенными в рамках
ORA.
• Процент инцидентов, частота которых превышает
предсказанную при
ORA.
• Процент CI, длительность простоя которых превышает
предсказанную
при ORA.
• Число действий, направленных на сокращение риска.
• Число вновь выявленных рисков.
• Процент CI, не включенных в план по непрерывности
предоставления
услуг.
• Число совещаний с поставщиками и владельцами
внутрикорпоратив
ных процессов.
90
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
8.3.4. Управление документацией (Q)
Метрики для управления документацией:
• Процент документов, для которых не была проведена в срок
плановая
проверка.
• Процент документов, не пересматривавшихся в течение года.
• Процент документов, не использовавшихся в течение года.
• Число невыполненных запросов о внесении изменений в
документы.
• Число документов, не удаленных после окончания срока
действия.
• Число недокументированных SLA.
• Число неполных политик и планов по управлению услугами.
• Число несоответствий между отдельными планами и общим
планом по
управлению услугами.
• Число инцидентов, относящихся к ошибкам в документации.
• Степень удовлетворенности клиентов.
8.3.5. Компетентность, осведомленность и обучение (R)
Метрики компетентности, осведомленности и обучения (Competence,
Awareness and Training — CAT):
• Число действий, запланированных, но не выполненных во
время кам
пании по повышению осведомленности.
• Число должностных инструкций, в которых не конкретизированы
тре
бования к компетентности.
• Процент сотрудников ИТ-подразделения, квалификация которых
офи
циально признана в отрасли.
• Средний процент недостаточности уровня подготовки.
• Процент сотрудников, имеющих подписанный план
индивидуального
развития.
• Процент ИТ-персонала с неоптимальным для занимаемой
должности
уровнем подготовки.
• Процент сотрудников с уровнем компетентности, не
удовлетворяющим
минимальным требованиям.
• Процент сотрудников, не выполняющих план индивидуального
разви
тия.
• Процент осведомленности сотрудников в целом по
организации.
• Процент текучести кадров в сфере ИТ.
• Число требований к персоналу, которые не удалось
удовлетворить.
• Процент сотрудников, не имеющих формально определенной
роли или
сферы ответственности.
Глава 8. СПЕЦИФИЧЕСКИЕ МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
91
8.4. Метрики для управления программами и
проектами (S)
Метрики для управления программами и проектами:
• Число не достигнутых в срок контрольных точек.
• Общее время задержки проекта в текущем месяце.
• Число полученных результатов проекта.
• Число достигнутых результатов проекта в текущем месяце.
• Число выявленных рисков.
• Задержка критического пути1.
• Число эскалации.
• Число несостоявшихся совещаний по проекту.
• Предполагаемая вероятность завершения проекта к
намеченному сроку
в рамках бюджета.
• Степень удовлетворенности клиентов.
• Число задач, сформулированных на совещании по
планированию про
екта, которые не были выполнены.
1
Критический путь — самая длительная последовательность выполнения работ при
реализации проекта, т.е. последовательность работ, показывающая
минимально необходимое время для завершения проекта. — Прим. пер.
____________________________________________
9
Интеграция метрик
В прошлом предпринималось множество попыток
усовершенствовать измерение бизнес-процессов. Немало
шагов было сделано и в ИТ, главным образом по развитию
уже существующих метрик.
Недавние изменения привлекли внимание к
измерениям в других областях. Важным вопросом стало
корпоративное управление — в первую очередь для
крупных международных компаний, но и для фирм
поменьше тенденция та же. В процессах управления
услугами было заострено внимание на значимости
измерений. И ITIL, и ISO20000, и COBIT, и Six Sigma, и
eTom предполагают использование метрик — именно
метрики
должны
обеспечить
функционирование
процессов таким образом, как они спланированы, и
служат основой для эффективных программ по их
улучшению.
Эти инициативы опирались на различные подходы и
точки зрения на ИТ. Как следствие, их результаты
непосредственно
нельзя
сопоставлять.
Ниже
рассказывается, как добиться интеграции метрик из
разных схем.
Структура и полезность метрик определяются
задачами, лежащими в основе их разработки. Набор
показателей,
предназначенный
для
руководящей
деятельности, может оказаться бесполезным, если нужно
улучшить процессы поставок техники или сократить
затраты на ИТ.
Если метрики разработаны для того, чтобы
контролировать
процессы
управления
услугами,
способствовать
сокращению
издержек
и
совершенствовать процессы, их можно использовать и как
источник информации для руководства.
94
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
9.1. Руководство бизнесом
Общее руководство бизнесом стало важной темой в последние
годы. Был предпринят ряд инициатив по улучшению корпоративного
управления, и в некоторых странах часть из них даже получила
законодательное оформление (закон Сарбейнса — Оксли в США,
Basel II в Европе и Кинг-2 в Южной Африке). В числе главных
аспектов — контроль, правильное применение и размещение
активов. Соответственно, в ITIL ядром процессов поддержки и
предоставления услуг являются управление конфигурациями и
управление изменениями, а стандарт ISO20000 делает центральную
контролирующую функцию еще более конкретной.
При том, что процессы управления конфигурациями и
изменениями составляют основу управления ИТ-услугами, они в
качестве «побочного эффекта» управляют еще и жизненным циклом
ИТ-активов.
По закону Сарбейнса — Оксли необходимо четкое разграничение
между аудиторами, проверяющими определенную область, и
лицами, ответственными за нее, — этого же требует и стандарт
ISO20000. Комитет спонсорских организаций комиссии Тредвея
(COSO) разработал критерии для проверки уровней руководства на
соответствие контрольным параметрам управления ИТ-услугами и
требованиям закона Сарбейнса — Оксли, а если воспользоваться,
например, ISO20000, эти схемы позволят оценить также и степень
зрелости корпоративного управления.
9.2. ITIL — IS020000 (BS15000)
Стандарт ISO20000 (бывший BS15000 в Великобритании, AS8018 в
Австралии, SANS15000 в Южной Африке) состоит из двух частей.
Первая, «Спецификации для управления услугами», содержит
перечень того, что непременно должно быть реализовано, вторая —
«Практические правила для управления услугами» — того, что
компаниям тоже следовало бы осуществить.
руководители большинства проектов захотят в конечном итоге
выполнить обе части. В действительности ISO20000 охватывает не все
процессы и функции ITIL — отсутствуют, например, управление
ИКТ-инфраструктурой и приложениями, а для ИТ-операций задается
минимальный уровень качества. Поэтому практически все компании
превзойдут этот стандарт во многих областях.
Наряду с огромным количеством других требований, имеющих
отношение к метрикам, стандарт определяет необходимость
адекватной количественной оценки следующих процессов и
функций:
• Система управления:
— Постоянно действующая программа по улучшению качества
обслу
живания (8.3.2);
— Управление рисками (8.3.3);
Глава 9. ИНТЕГРАЦИЯ МЕТРИК
95
— Требования к документации (8.3.4);
— Компетентность, осведомленность и обучение (8.3.5).
• Процессы предоставления услуг:
— Управление мощностями (8.2.4);
— Управление доступностью и непрерывностью
предоставления ИТуслут (8.2.5 и 8.2.6);
— Управление уровнем обслуживания (8.2.1);
— Система отчетности по услугам (10.4);
— Управление информационной безопасностью (8.2.7);
— Бюджетирование и бухгалтерский учет (управление
финансами) для
ИТ-услуг (8.2.3).
• Процессы контроля:
— Управление конфигурациями (7 и 8.1.3);
— Управление изменениями (8.1.4).
• Процессы релиза:
— Управление релизами (8.1.5).
• Процессы разрешения нештатных ситуаций:
— Управление инцидентами (8.1.1);
— Управление проблемами (8.2.2.).
• Процессы взаимодействия:
— Управление взаимоотношениями с бизнесом (8.3.1);
— Управление взаимоотношениями с поставщиками (8.3.1).
В скобках указаны номера соответствующих глав и разделов
настоящей книги.
9.3. еТОМ
Модель еТОМ (enhanced Telecom Operations Map — расширенная
карта процессов телекоммуникационных компаний), используемая
многими операторами связи как платформа предоставления услуг,
основана на стандартах управления сетями и концепции бизнеспроцессов. Международная ассоциация TeleManagement Forum
выпустила множество документов с описанием еТОМ, а также
подробную матрицу взаимосвязей между ITIL и еТОМ —
соответствующий документ имеет шифр GB9211. Необходимо понимать, что терминология, область действия и определения еТОМ
и ITIL различаются, поэтому хотя ITIL и может использоваться для
поддержки
1
http://www.rmforam.org/browse.asp?catID=2024&linkID=29248 — прямая ссылка на
документ. еТОМ поддерживается на сайте www.tmforam.org. Зарегистрированные
пользователи могут скачать документ бесплатно, а незарегистрированные — за
небольшую плату. — Прим. авт.
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
96
еТОМ, ее простого и прямого отображения на еТОМ не существует.
Так что данный документ носит рекомендательный характер и
отражает ITIL слабее, чем хотелось бы.
На самом высоком уровне соответствие можно рассматривать
так, как показано в табл. 9.1.
Таблица 9.1
Соответствие между еТОМ и ITIL
еТОМ
mi
Управление качеством сервиса
Доступность
Управление QoS (качеством обслуживания) / SLA для клиентов
Уровень обслуживания
Обработка проблем
Инцидент
Управление клиентским интерфейсом
Служба Service Desk
Сервисная проблема /сбой в ресурсах
Проблема
Конфигурирование и активация услуг/ обеспечение услуг
ресурсами
Конфигурация
Стоит отметить, что многие термины в двух системах
определяются по-разному. Как можно видеть, слова «сервис» и
«проблема» в правом и левом столбцах таблицы означают не одно и
то же.
С точки зрения метрик подход, использованный в настоящей
книге, можно расширить так, чтобы он подходил для
высокоуровневых процессов еТОМ.
9.4. COBIT
COBIT — это стандарт аудита, применяемый для проверки
соответствия ИТ действующему законодательству (например, закону
Сарбейнса — Оксли). Задачи контроля в COBIT хорошо согласуются с
ITIL — при разработке стандарта ITIL использовалась для
определения категорий — и, как следствие, с ISO20000.
Так же, как и в ITIL, отправной точкой COBIT является каталог
услуг, на основе которого оценивается качество сервиса. Показатели
SLA и метрики процессов дают подробную картину того, как
контролируется управление ИТ-услугами. Если компания применяет
или планирует применять COBIT в качестве механизма аудита, то
при реализации управления ИТ-услугами ей имеет смысл провести
бенчмаркинг соответствующих процессов и их метрик, используя в
качестве эталона задачи контроля, определенные в COBIT. Тогда для
метрик, выбранных компанией, еще до внедрения будет
гарантировано соответствие требованиям аудита.
Рассмотрим высокоуровневые задачи контроля, относящиеся к
мониторингу:
Глава 9. ИНТЕГРАЦИЯ МЕТРИК
97
Ml — мониторинг процессов;
М2 — оценка объективности внутреннего контроля;
МЗ — получение независимых гарантий;
М4 — проведение независимого аудита.
Как видим, структура ISO20000 вполне с этим согласуется.
Метрики, определяемые и рассматриваемые в настоящей книге,
непосредственно соотносятся с задачей Ml.
Только что был приведен один из примеров соответствия между
COBIT и ITIL — подробному описанию этих соответствий
(отвлекаясь от метрик) посвящен ряд книг. Например, изданное
нидерландским ITSM-форумом (ITSMF-NL) «Управление ИТ —
карманное руководство на основе COBIT» (IT Governance — A Pocket
Guide Based on COBIT) рекомендуется для следующего уровня
детализации1.
Некоторые видели в COBIT замену ITIL, однако скорее здесь стоит
говорить о взаимодополнении. COBIT — в высшей степени
стабильный метод проектирования, и он приносит огромную пользу
ИТ-аудиту. Лучше всего рассматривать его как структуру поддержки
аудиторов — наибольший выигрыш дает проектирование метрик с
учетом как аудита, так и операций. Следует, впрочем, заметить, что
в COBIT есть множество метрик, предназначенных для аудиторов, и
с ними стоит ознакомиться, чтобы при проектировании связывать
новые метрики с уже существующими, обеспечивая таким образом
расширение процессов аудита.
9.5. Six Sigma
Six Sigma функционирует как модель бизнес-процесса, цель которого
— сократить количество дефектов в заданных проблемных
диапазонах (сигма). Для этого нужны метрики, позволяющие
выявить дефекты.
Метрики для управления ИТ-услугами, представленные в
настоящей книге, совместимы с подходом Six Sigma. После того,
как для них проведен бенчмаркинг и накоплена определенная
история использования, дефект может рассматриваться как
недостижение некоторого заданного показателя. Так обеспечивается
связь двух систем, а цели Six Sigma обретают смысл в контексте
управления ИТ-услугами.
Подход Six Sigma отличен от принятого в этой книге в случае,
когда оценивается средняя эффективность процессов, — в нем
важно сокращение отдельных дефектов. Поэтому перед началом
применения Six Sigma стоит внедрить структуру управления ИТуслугами, поработать с ней полгода-год,
1
На веб сайте OGC есть интересная статья «Связывание COBIT, ITIL и ISO17799 во
благо бизнеса» (Aligning COBIT ®, ITIL® and ISO17799 for Business Benefit), адрес
http //www ml со uk/mcludes/ITIL-COBiT pdf —Прим авт
98
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
пройти несколько циклов программы по улучшению услуг (SIP) и
отладить как процессы, так и оценивающие их метрики.
Важно понимать, что модель Six Sigma, пришедшая из
производства, помогает управлять процессом снижения числа
дефектов, но не разрабатывать метрики для управления услугами.
Если в компании уже ведется проект Six Sigma, есть опасность, что
правильная последовательность ведения данного проекта будет
нарушена. Чтобы этого не допустить, нужно, как уже говорилось,
сначала внедрить метрики и провести их через цикл
совершенствования процесса, а уже потом встраивать полученные
результаты в структуру Six Sigma.
Отметим также, что достижение высоких уровней качества в Six
Sigma может оказаться дорогим удовольствием. Даже для Motorola
цена, которую приходилось платить за качество, оказалась
непомерной, и компания была вынуждена снижать достигнутый
уровень, чтобы повысить прибыльность. При установлении целей Six
Sigma важно руководствоваться здравым смыслом, а не идеализмом.
Найти правильный баланс между затратами и качеством — очень
непростая задача.
______________________________________
0
1
Реализация метрик
Люди могут измерять параметры, которые от них не
зависят, — например, количество света, излучаемого
Солнцем. Это часто интересно и помогает понять
природу вещей, но контроль над ними таким путем не
обеспечивается.
Чтобы контролировать бизнес- или ИТ-процесс, нужно
его определить, а затем выполнять — иначе говоря,
реализовать. Метрику следует разрабатывать таким
образом, чтобы требуемую информацию давал
работающий процесс, а участники этого процесса
понимали, что они могут сделать для улучшения
показателя,
и стремились его
улучшить.
От
изолированных метрик можно ждать в лучшем случае
интересных цифр — и ничего более.
Из этой главы вы узнаете, как правильно вводить
метрики и как добиться того, чтобы они стали полезным
механизмом контроля и помогали компании держаться
курса, выбранного руководством.
Не зная пункта назначения, вы далеко не
продвинетесь. Нужна система управления (как описано в
ISO20000), которая «знает», куда нужно попасть, т.е. в
ней заданы политика, задачи и планы управления
услугами.
10.1. Мероприятия
Чтобы обеспечить успешное управление ИТ-услугами,
подразделение должно заручиться поддержкой со
стороны
какого-либо
представителя
высшего
руководства компании или, в терминологии ITIL,
«спонсора» (executive sponsor). Иначе
100
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
любые попытки что-либо предпринять будут иметь мало успеха, в
конечном итоге вызовут раздражение у инициаторов и окажутся
неэффективными.
Поэтому первым делом необходимо проинформировать высшее
руководство о преимуществах, затратах и требованиях к реализации.
Если его удастся убедить в том, что компании нужно управление ИТуслугами, то следует внедрить систему управления, как это описано в
разделе 3 18020000-1:20000 «Требования к системе управления».
Затем следует добиться общего понимания требований к
мониторингу процессов посредством установленных метрик,
поскольку это является частью принципов курса «Основы ITIL».
На этой начальной стадии идеально будет встроить во все
процессы некоторый непротиворечивый, простой и сопоставимый
набор метрик. Именно такой подход предложен в настоящей книге.
Его преимущество — в упрощении задачи для владельцев
процессов, у которых много работы по реализации составляющей
«Люди — Процесс — Технология».
В идеале метрики для процессов проектируются параллельно с
самими процессами. В обширной литературе по проектированию
процессов много говорится о том, как важно не подстраиваться под
имеющийся инструментарий. Действительно, процессы должны
соответствовать требованиям организаций, и лишь в очень
немногих случаях работу можно начать «с чистого листа». Поэтому
наборы стандартных процессов, поставляемые консультантами или
в составе различных инструментариев, нужно адаптировать к
условиям конкретной компании.
Разработка новых процессов с нуля — дело само по себе
трудоемкое и часто неблагодарное, так как результатом
оказывается не реальное улучшение, а набор документов. Ее
можно упростить и ускорить с помощью метрик из этой книги.
Метрики можно подключать к стандартным процедурам
высокоуровневого проектирования для конкретных процессов,
учитывая реальные возможности выбранного инструментария
(или того, который, вероятно, будет выбран). Необходимо лишь
выявлять особые случаи, когда стандартный процесс не подходит
для данной организации, и там, где выбранное решение является
наилучшим, вносить соответствующие изменения. При данном
подходе большинство процессов и метрик используются «как
есть», а все немногочисленные исключения хорошо определены.
Естественно, проектирование по этой — как и по любой другой —
схеме не приведет к созданию идеальных процессов. Для
усовершенствования первоначальных разработок существует SIP,
поэтому не надо бояться, что компания навсегда застрянет на
стадии неоптимального решения. Совсем наоборот, она получит
быстрое и простое для реализации решение, которое можно будет в
дальнейшем модифицировать в свете истинных потребностей
бизнеса именно так, как это рекомендуется в ITIL!
Глава 10. РЕАЛИЗАЦИЯ МЕТРИК
101
10.2. Критические факторы успеха (CSF)
Главным CSF является преданная своему делу команда менеджеров
— система управления, включая политики и структуру, которые
обеспечивают эффективный контроль и реализацию всех ИТ-услуг
(ISO20000-1:2—2, раздел 3. Задача).
Для эффективной работы этой системы жизненно важно
выстроить и выполнять качественный коммуникационный план.
Когда это сделано, можно включать в политику управления
услугами различные положения и рекомендации из этой книги,
например:
«Политика по реализации метрик для процессов организации ABC заключается в том, что разрабатывается около десяти штрих на процесс таким
образом, чтобы т эффективность можно было измерять и методы проектирования для разных процессов т противоречили друг другу. Цель этого—сделать возможным использование результатов метрик для сравнения
процессов с учетом их зрелости и совершенствования».
На практике сказанное означает, что при разработке или
изменении процесса его владелец будет консультироваться с
владельцами других процессов, проверяя совместимость и
сопоставимость метрик. При обсуждении обязательно будет
затронут вопрос о реальных базовых показателях. Здесь можно
разработать общую практику — например, всякий внедряемый
процесс в течение трех месяцев выполняется в тестовом режиме со
стандартным набором метрик. Средний показатель трех лучших
недель за этот период принимается за базовый, а целевое значение
устанавливается на несколько процентов выше.
Это прагматичный подход — показатели легко изменить, если
окажется, что их слишком просто или, наоборот, слишком сложно
достичь. При его использовании метрики с большой вероятностью
будут удобными и смогут предоставлять ценную управленческую
информацию. Итак, перечислим CSF:
• Поддержка системы управления;
• Качественный коммуникационный план;
• Непротиворечивая разработка процесса;
• Непротиворечивая разработка метрик;
• Непротиворечивый метод мониторинга и сбора информации;
• Сбор информации и мониторинг, независимые от
владельцев про
цессов;
• Проектирование метрик в соответствии с принципами,
рассмотренны
ми в главе 8.
102
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
10.3. Возможные проблемы
И когда метрик слишком мало, и когда их слишком много, и когда
они просто-напросто плохо спроектированы, результаты могут быть
чудовищными.
В стандарте ISO20000 подчеркивается значение системы
управления, поддерживающей управление услугами. Это очень
существенный момент. Если владельцы не могут влиять на
показания метрик, то эти метрики будут иметь ограниченное влияние
на их поведение. То же самое произойдет и в отсутствие системы
управления, способной привлечь к метрикам достаточное внимание со
стороны менеджеров.
Если менеджеры не рассматривают метрики как ценный способ
измерения индивидуальных усилий (с последующим их поощрением),
у сотрудников не будет никаких стимулов к улучшению показателей.
Жизненно важно, чтобы система управления действовала, а
регулярные проверки и оценка сотрудников индивидуально,
используя показания метрик, подкрепляли в менеджерах
понимание значимости используемых метрик. В противном случае,
даже если поначалу и будет какой-то энтузиазм, через некоторое
время внимание переключится на другие вопросы и качество
предоставления услуг ухудшится.
Если метрики не удовлетворяют критериям разработки,
перечисленным в первых главах (SMART, KISS), они также не будут
действовать. Считая метрику недостижимой (справедливо или
ошибочно), сотрудники вполне могут отказаться от попыток ее
достичь: они будут думать, что раз провал неизбежен, нет смысла
делать его чуть менее провальным — ведь все равно усилия не
окупятся!
Сложности возникают и в связи с критериями измеримости и
установления реалистичных целей. Если, к примеру, сделать
метрикой среднее время обработки заявки группой технической
поддержки,
то
потребуется
правильно
фиксировать
продолжительность каждого разговора для каждого оператора. При
отсутствии соответствующего инструментария это приходится
делать вручную, прилагая дополнительные усилия. Таким образом,
настройка инструмента, обеспечивающего сбор данных, может
потребовать значительных трудозатрат при внедрении метрик.
Метрики и процедура их реализации могут нравиться технократам
и людям с аналитическим складом ума. Математический формат
позволяет строить множество сложных графиков, отображающих
разные представления данных. С этим связано несколько
опасностей.
Во-первых, самое важное в представлении — это простота: лучше
быстрее увидеть, что идет хорошо, а что нет, чем знать, насколько
именно плохи дела, с точностью до нескольких десятичных порядков.
Отыскание источника проблемы является частью процесса ее
решения, а не выявления. Вопросам представления метрик
посвящен раздел 10.4.1.
Глава 10. РЕАЛИЗАЦИЯ МЕТРИК
103
Во-вторых, хотя метрики реализуются и представляются с
помощью технических средств, они на самом деле оценивают
деятельность людей. Изучение того, чем занимаются сотрудники и
как они реагируют на стимулы или давление, относится к сфере
нежесткого менеджмента, а не технологий. Отношение к людям как
к механизмам (какое предполагал хронометраж движений
рабочего, популярный в 60-е годы) позволяет ответить на
некоторые интересные вопросы, но часто за счет человеческих
отношений. Все мы личности и любим, чтобы к нам относились как
к таковым. Если менеджер нами интересуется и оценивает нашу
работу как по метрикам (в качестве объективного источника
данных), так и по личному впечатлению, мы, вероятно, будем
положительно реагировать на его предложения.
Если же оценивать нас по проценту звонков, обслуженных менее
чем за определенное количество минут, то мы, скорее всего, станем
работать механически и прекратим стараться. В результате у нас
ухудшится моральное состояние и появится готовность при первом
удобном случае сменить работу, а организация в целом получит
высокую текучесть кадров, общий упадок духа и, как следствие,
плохое обслуживание клиентов.
10.3.1. Сопротивление изменениям
Сопротивление изменениям — важный фактор в поведении
человека, так же как инертность. Лица, ответственные за настройку и
управление процессами, должны иметь представление об этих
психологических особенностях. Они подробно обсуждаются в
литературе, поэтому мы лишь вкратце осветим основные моменты.
Дело в том, что метрики представляют собой некую отправную
точку. Организация и сотрудники (а также спонсор из высшего
руководства) могут уступить введению новшества, но в душе его не
принять. Метрики могут очень отчетливо это отразить и стать тем
объектом, против которого направлено сопротивление. Чтобы
противостоять этому сопротивлению, метрики должны быть хорошо
определены и согласованы.
Единственное средство от второго фактора, инертности, — это
постоянная бдительность менеджеров. Если собрания, связанные с
процессом, скучны, затянуты и на них обсуждаются несущественные
вопросы, то естественно, что им будут придавать все меньше
значения. Постепенно к ним перестанут относиться серьезно, начнут
присылать вместо руководителей произвольных сотрудников, а
реальная работа по мониторингу и совершенствованию процессов
будет стоять.
Такое возможно, когда собрания проводятся слишком часто или
когда решения принимаются не во время собрания, а позже. Полезно
рассматривать
мониторинг
и
совершенствование
как
самостоятельный
процесс,
эффективность
которого
можно
отслеживать. Как-никак, это часть плана по улучшению услуг (SIP).
104
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Срыв процесса редко бывает намеренным, хотя такое тоже
возможно. Если, например, отчеты, получаемые на основании
метрик, не готовы в срок и это регулярно повторяется, то не
исключено, что таким путем пытаются скрыть плохие новости до тех
пор, пока не представится шанс исправить ситуацию, или
уклониться от решения проблемы, способной оказать серьезное
воздействие на бизнес.
Для предотвращения подобных проблем следует формально
документировать собрания по обсуждению метрик, чтобы
отсутствующие и недоработанные показатели попали в протокол
совещания, раздаваемый всем участникам, и их нельзя было бы
игнорировать.
Сделав метрики слишком сложными для понимания или сбора
данных, вы непременно спровоцируете неприятие и активное
сопротивление их внедрению.
Если какой-либо метрики (метрик) не хватает или они
недоработаны, имеет смысл устроить отдельное собрание и, в
зависимости от того, что представляется более подходящим, либо
обсудить их изменение, либо более понятно объяснить, как они
работают, для чего нужен сбор данных и как повысить его
эффективность.
Метрики раскрывают функционирование процесса лучше, чем
обсуждение, наблюдение и иные неформальные методы. Если по
каким-то причинам не удается придерживаться процессов, метрики
это покажут. Так, не решенная проблема, связанная с
сопротивлением изменениям, скорее всего проявится в сложностях
с предоставлением отчетов по метрикам или сбором данных либо в
плохих показателях.
Поэтому важно, чтобы проблемы не отражались на людях,
которые отчитываются по метрикам. Слишком легко направить
действия на решение проблемы, которая таковой не является! Если
есть впечатление, что разрушается цель метрической программы,
нужно искать основную причину. Это может быть, например, стык
между отделами или процессами, один из которых работает в
направлении ITIL, а другой нет. Или изменение в бизнесе, из-за
которого существующий процесс перестал быть эффективным. Или
даже попросту новые работники, почему-то не введенные в курс
дела и не прошедшие обучение. Важнее всего исследовать ситуацию
и исправить положение.
Обсуждаемые формы сопротивления способны создавать очень
напряженную обстановку и оказывать крайне негативное
воздействие на дух коллектива и функционирование бизнеспроцессов. Необходимо, чтобы руководитель — спонсор ITIL —
знал о затруднениях, тогда к проблеме удастся привлечь внимание
старших менеджеров еще до того, как разовьется серьезный кризис.
Помните: увидев, что индикатор температуры двигателя в
автомобиле приближается к красной отметке, нужно остановиться и
разобраться с неполадкой, а не ругать датчик.
Глава 10. РЕАЛИЗАЦИЯ МЕТРИК
105
10.3.2. Метрики и процесс управление изменениями
Управление изменениями отвечает за все новшества и
преобразования в организации. Термин МОС (Management of
Change) используется для управленческой задачи, которая состоит
в том, чтобы обеспечить восприятие компанией и людьми
организационных и операционных изменений.
В осуществлении МОС руководству помогает отдел кадров,
который, в частности, организует учебные курсы. В двух словах,
процесс подразумевает доведение до всех сотрудников, затронутых
изменением, точки зрения компании и руководства на организацию
и на то, почему это изменение для нее необходимо.
Здесь приходится иметь дело с определенными человеческими
факторами, или «мягкими» аспектами изменений. Наверняка вы
столкнетесь с такими вопросами, как «Останусь ли я на своей
должности?», «Означает ли добавление новых задач к моим
должностным обязанностям, как это отразится на моей зарплате?»,
«Какую предварительную подготовку я получу для перехода к новой
работе и новым обязанностям?».
Поскольку метрики для управления ИТ-услугами в конечном
счете внедряются для того, чтобы привязать к ним оценки
работоспособности сотрудников, понятно, что при их реализации
необходимо
учитывать
управление
изменениями.
Для
руководства важна также дисциплина, которая обеспечивает
детальную проработку изменений с точки зрения бесперебойного
выполнения операций. При этом людей оценивают по тому,
насколько успешно они улучшают функционирование процесса, за
который отвечают, или содействуют изменениям в повседневной
трудовой практике.
Кое-что здесь может показаться нам «косметическим» — так
иногда называют изменения, затрагивающие только повседневную
работу отдельных людей. Но важно понимать, что при плохом
управлении эти, казалось бы, тривиальные факторы могут вызвать
сильное сопротивление персонала и, возможно, привести к провалу
проекта. Планируя предстоящие изменения, обязательно
проверьте, был ли учтен человеческий фактор.
Пока процессное мышление не стало стандартом в организации,
помогайте сотрудникам осознать, что именно процесс, а не
индивид, требует совершенствования и внимания. Индивидуальный
рост и развитие являются отдельными — и значимыми —
факторами, не зависящими от совершенствования процесса. Если
этого не понимать, то сбой процесса или график, из которого
следует, что какие-либо отделы работают неудовлетворительно,
могут вызвать большое беспокойство.
Когда удается справиться с негативным впечатлением,
появляется возможность товарищеского соревнования между
владельцами процессов и их командами (непосредственными
подчиненными или виртуальными группами), вносящего позитивный
вклад в совершенствование процесса.
106
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
10.3.3. Последствия метрик (макиавеллиевские метрики:
цель оправдывает средства)
Сами по себе метрики не могут сдвинуть дело с мертвой точки. Это
часть структуры управления с функцией информирования
руководства о текущем положении дел и последних изменениях.
Проблема заключается отчасти в том, что измерение начинает
опираться не на то поведение, которое помогает бизнесу, а на то,
которое удовлетворяет метрике. Когда в 1696 году был введен
налог на окна, он казался довольно прогрессивным. Чем богаче
домовладелец, тем больше у него дом и тем больше в нем дорогих
застекленных окон, так что с богатых налог был выше, чем с бедных.
До какой-то степени это действовало, но до сих пор в Англии можно
видеть полутемные изнутри дома с окнами, заложенными
кирпичом, — результат попыток избежать налога. Более того, налог
превратил окна в символы статуса, и богачи строили себе
загородные дома с максимальным количеством окон. Некоторые
врезали окна в несущие стены с единственной целью — поднять
налог и престиж! Ни один из этих результатов не предполагался и
не учитывался в момент изобретения налога.
Из книги «Практики ITIL дня небольших ИТ-подразделений»1,1995 г.
Число звонков в службу Help Desk — один из самых популярных и одновременно
наиболее сложных для интерпретации показателей. Первое свойство обусловлено
простотой сбора данных, второе — тем, что люди звонят в службу Help Desk не по
желанию, а по необходимости, и измерение, таким образом, зависит от ряда переменных.
Возможные причины увеличения числа звонков очень разнообразны и противоречивы, например:
• плохое качество поддержки способствует увеличению числа звонков, пото
му что пользователь вынужден звонить до тех пор, пока проблема не разре
шится;
• хорошее качество поддержки способствует увеличению числа звонков, по
тому что служба нравится пользователям и они чаще туда обращаются;
• простое информирование пользователей о наличии единой центральной
точки контактов само по себе повышает число звонков;
• новый релиз или изменение ПО привлечет больше звонков;
• изменения в кадровом составе или практике работы приводят к росту числа
звонков из-за появления пользователей, не очень хорошо знакомых с данной '
службой;
1
В рамках текущего проекта по обновлению ITIL готовится переработанное
издание этой книги, которое будет называться «Реализация ITIL в малых
масштабах» («ITIL small-scale implementation»). —Прим. авт.
Глава 10. РЕАЛИЗАЦИЯ МЕТРИК
107
• работа может быть сезонной, тогда в определенное время года будут исполь
зоваться малознакомые части ИТ-системы;
• может существовать проблема с предоставлением услуги, такие как:
— изменения, не протестированные должным образом;
,
— ПО, не синхронизированное с распределенной системой;
— сбой сети или компьютерной аппаратуры.
Как видим, метрики не независимы и интерпретировать их непросто; из того,
что показатель легко подсчитать, еще не следует, что он должен статьключевым
в управлении ИТ-услугами.
Другой известный пример — это оказавшее сильное влияние на
всех нас использование в центрах обработки вызовов метрики
«Продолжительность звонка» (см. раздел 6.6). Из-за этого критерия
операторы стремятся «закрыть заявку», а не заниматься тем, что
нужно клиенту. Зачастую они, еще не разобравшись с проблемой,
спрашивают: «Можно я сейчас закрою этот звонок?» и доходят
даже до того, что предлагают позвонить к ним снова по тому же
самому вопросу (так как сохранение открытой заявки снизит коэффициент закрытия). Такой подход не повышает степень
удовлетворенности клиентов!
В данном примере и ИТ-подразделение, и клиенты заинтересованы
в том, чтобы заявки не оставались подолгу открытыми, а
своевременно обрабатывались. Неправильно только делать
соответствующий показатель единственным или главным. Есть два
простых способа справиться с проблемой. Первый заключается в
подсчете повторных звонков по одному вопросу. Если это обычное
явление, значит, метрика закрытия заявок провоцирует неоказание
поддержки клиенту и нужно проследить, чтобы операторы не
открывали новых заявок по тому же или похожему вопросу.
Второй вариант — опереться на данные исследования степени
удовлетворенности клиентов: если пользователям не нравится, что
их просят прервать звонок ради удобства оператора, это будет
заметно, и тогда можно присвоить степени удовлетворенности более
высокий приоритет.
Механизм
приоритетов
позволяет
тонко
регулировать
относительную
значимость
требований.
Зная,
что
удовлетворенность клиентов важна, операторы станут заботиться
сначала о том, чтобы клиент остался доволен решением проблемы,
и только потом — о закрытии заявок. Если через некоторое время
продолжительность звонков возрастет до недопустимой величины,
приоритеты можно будет снова пересмотреть.
Этот подход, принятый в настоящей книге, использует логику,
которую рекомендовал для человеческих взаимоотношений
Макиавелли. Он предлагал подумать, какое поведение наиболее
вероятно, когда задана определенная цель. Хороший тест — «Что
бы я сделал, если бы передо мной была поставлена эта задача?»
Если ответ отличается от истинной задачи метрики, можно
использовать дополнительную метрику в качестве противовеса. Например,
«продолжительность
звонка»
компенсируется
«удовлетворенностью клиента».
Такова одна из движущих сил, определяющих выбор метрик. Все мы
будем стараться сделать максимум возможного для выполнения
задач организации, и все-таки наша главная цель — преуспеть
самим. Если метрики побуждают нас делать то, что хорошо для нас,
но не для организации, проблема в метриках, а не в нас!
Приведенные примеры довольно известны, а в реальной жизни
непредусмотренные последствия внедренных метрик обычно
проявляются менее явно. Важно следить за реальным
функционированием метрик, дабы убедиться, что они измеряют
истинные переменные процесса, а эти переменные связаны с
предоставляемыми услугами и не являются просто бюрократическим
вмешательством в работу людей. Неплохо начать с
уравновешивания различных показателей, как это рекомендовано
выше, но только реальные встречи с участниками процесса
позволят выяснить, чем они занимаются и как метрика
встраивается в их деятельность. Возможно, стоит включить
проверку полезности и корректности метрик в план по улучшению
услуг.
10.4. Отчетность по услугам
Главной целью отчетности по услугам является эффективное
донесение информации до адресата. Эта задача решается за счет ясности
и визуального воздействия .
"Лечше однин раз увидеть, чем сто раз услышать".
Многие организации устанавливают собственные стандарты
отчетности. Цель любого отчета — представить данные в понятной,
недвусмысленной и простой для понимания форме. Для этого
используется целый ряд различных графических методов.
Многие пакеты визуальной отчетности позволяют строить
цветные круговые и лепестковые диаграммы, гистограммы,
линейные графики, трехмерные представления данных. Набор
значений можно легко отобразить в любом из этих форматов. Но
остерегайтесь слишком красивых графиков — они могут отвлечь
внимание от содержащейся в них информации. Стремиться надо к
простоте и ясности, а не к внешнему изяществу. На практике
применяются:
• секторная диаграмма для сравнения по компонентам;
• гистограмма для сравнения по единицам продукции;
• столбчатая диаграмма для сравнения по временным рядам;
• линейный график для распределения частот;
• точечная диаграмма для корреляций.
В отчетах по метрикам наиболее важны три представления:
1. Историческое представление. Как шли процессы в несколько
послед них отчетных периодов? Это позволяет понять контекст
краткосрочных «всплесков» и, с одной стороны, избежать
паники, когда ситуация в целом вполне приемлема, а с другой
— заранее выявить опасные тенденции, даже если текущие
результаты представляются хорошими, и предпринять
необходимый действия еще до того, как ситуация начнет
отражаться на бизнесе.
2. Представление относительно других процессов. Насколько
успешно прогрессирует компания в целом? Какой процесс
работает лучше всех?
Насколько эффективны процессы по сравнению с аналогами в
других организациях? Этот подход позволяет корректировать
план по постоянному улучшению.
3. «Моментальный снимок» текущего состояния. Какие
проблемы возникали за последний отчетный период? Насколько
они серьезны? Как предотвратить их повторное
возникновение?
Хотя многие отчеты можно формировать автоматически с помощью
инструментария управления услугами или средств построения
отчетов, их обоснованность обязательно нужно проверять и вручную.
В соответствии с принципами аудита, изложенными в ISO20000, за
создание и проверку отчетов по услуге и за предоставление этой
услуги должны отвечать разные лица. Для каждого отчета вопрос о его
необходимости подлежит пересмотру раз в полгода (или в квартал),
составление отчетов, признанных ненужными, прекращается.
В ISO20000 дается следующая формулировка задач отчетности
по услугам:
«Создавать согласованные, своевременные, надежные и точные отчеты для
принятия обоснованных решений и эффективной коммуникации». Далее
говорится о необходимости понятного описания каждого отчета об услугах,
включая данные о заглавии, цели, аудитории и об источнике данных
(IS020000-1:2004).
Если данные в регулярных отчетах все время представлены в
одном и том же формате, есть опасность, что из-за однообразия
останется незамеченной важная информация. По этой причине
часто полезнее создавать так называемые исключительные отчеты,
т. е. когда процесс (или процессы) демонстрируют значительное
улучшение или неожиданное ухудшение, выпускать специальное
сообщение, где будет также сказано, что способствовало успеху
либо что запланировано для исправления положения. Отчет просто о
том, что все идет своим чередом, как обычно, не побуждает к
действию и не представляет большой ценности.
Распространение бумажных отчетов стоит дорого, отнимает много
времени, и их зачастую не читают (см. раздел 2.4). Вспомните ответ
в опросе об их пользе: «Пожалуйста, продолжайте их присылать:
моей дочурке так нравится рисовать на них!» Наверное, разумнее
размещать отчеты на внутрифирменном веб-сайте, где они
доступны для всех сотрудников, и рассылать по электронной почте
письма с описанием исключений. Тогда заинтересованные стороны
смогут, когда это нужно, знакомиться со свежими отчетами, но будут
это делать только при возникновении конкретной необходимости.
Вне зависимости от того, как вы распространяете отчеты — на
бумаге или через веб-сайт, в календарном плане должны быть
предусмотрены регулярные собрания с ключевыми участниками
бизнеса с целью обсуждения и согласования главных показателей
эффективности. Если позволить людям обращаться к данным только
тогда, когда им это понадобится, данные оказываются под угрозой
полного игнорирования.
Раздел 10.4.1 содержит отчеты по всем процессам за одну
неделю, а также график, показывающий сравнительное улучшение
различных показателей за три месяца.
10.4.1. Представление метрик
Представлять информацию руководству нужно в понятной форме,
подчеркивая аспекты, требующие внимания, и избегая чрезмерной
детализации.
Метрики, описанные в этой книге, спроектированы так, чтобы
оценивать все процессы примерно одинаковым образом; для
уравновешивания односторонних, по преимуществу технических
показателей среди них присутствует степень удовлетворенности
клиентов. Многие целевые показатели не нужны сами по себе — они
имеют смысл только при сопоставлении либо с эталонным
(базовым) уровнем, достигнутым в другой организации, либо с
более ранними собственными результатами.
В отрасли, характеризующейся высокой сезонностью, данные за
истекший квартал стоит сравнивать с данными за аналогичный
период прошлого года. Естественно, для вывода о том, что
эффективность процесса снизилась (или повысилась), одного
взгляда на показатели недостаточно, ведь есть множество факторов,
способных вызвать временный «всплеск». Однако рассмотрение
тенденции
за
последние
полгода
должно
сгладить
соответствующие эффекты и дать более ясную картину .
В регулировании общего направления интерес представляют не
столько многочисленные детали, сколько возможность сравнивать
процессы, учитывая тенденцию нескольких последних месяцев.
Ниже приводятся несколько примеров того, как представлять эту
информацию, с необходимыми пояснениями. За недостатком места
мы не можем осветить здесь алгоритмы обработки, применяемые
для определения тенденций, поэтому приводим лишь результаты.
В графике на рис. 10.1 показатели для управления изменениями
сведены к одному значению для каждого месяца. Это значение
включает все метрики с учетом их веса (приоритетов),
согласованного между руководством и владельцем процесса, и,
таким образом, приведено к виду, позволяющему сравнивать его с
другими процессами. Для процесса управления уровнем сервиса
используются, как мы знаем, совершенно другие метрики, но его
график будет похож на этот.
Интерпретация трех линий:
• линия совокупной необработанной оценки показывает, что в
течение данного периода процесс был близок к значению 5;
• эффективность относительно согласованного целевого
значения — самый лучший показатель для сравнения
процессов. Как видим, начало было неутешительным, в марте
произошло улучшение, но потом дела пошли на спад;
• эффективность относительно среднего значения
показывает успехи управления изменениями по сравнению со
средней эффективностью за данный период. Здесь также видны
значительное улучшение в марте и последующий спад;
• кроме того, есть линия, показывающая отклонение
необработанной оценки;
Результаты по метрикам для управления изменениями за
первое полугодие 2006 года
-л- Совокупная необработанная оценка
Результаты по метрикам для управления изменениями за первое
полугодие 2006 года Совокупная оценка (0-10)
•о Отклонение необработанной оценки
Результаты по метрикам для управления изменениями за первое
полугодие 2006 года Изменение за период
— Эффективность относительно
среднего значения
Результаты по метрикам для управления изменениями за первое
полугодие 2006 года Отклонение от среднего в процентах
—- Целевое значение
Результаты по метрикам для управления изменениями за
первое полугодие 2006 года Целевое значение
"»
Эффективность относительно согласованного
Месяц
Результаты по метрикам для управления изменениями
целевого значения
за первое полугодие 2006 года
Отклонение от целевого значения в процентах
Рис. 10.1. Пример, демонстрирующий метрики управления изменениями
112
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
• линия целевого значения отражает его изменение за период.
Оно было установлено слишком высоким и представлялось
недостижимым, но потом его удалось превзойти.
Чтобы выяснить, почему это все произошло, необходимо
дополнительное исследование. Но при беглом взгляде видно, что в
целом эффективность управления изменениями росла, хотя в
последние два месяца результаты были не так высоки, как в
апреле. Получить ту же информацию, имея перед собой подробные
метрики за полугодие, было бы гораздо сложнее.
График, представленный на рис. 10.2, показывает сразу все
метрики. Даже при том, что совокупность показателей для каждого
процесса сведена всего к одному числу, картина остается запутанной.
Видно, что худшие общие результаты (самое низкое среднее
значение) у управления релизами, а лучшие — у SIP. Но интереснее
всего майский рост эффективности до пикового значения и ее
июньский спад. Вероятно, в работе компании присутствует сильная
сезонная тенденция. Еще более обобщенную картину процессов
дает лепестковая диаграмма (рис. 10.3).
Судя по бледно-серой линии, соединяющей средние значения на
диаграмме, самой проблемной областью является документация,
тогда как наибольшего успеха (к счастью!) достигла SIP, поэтому
можно надеяться, что в будущем дела пойдут хорошо.
Все метрики
-А- Управление инцидентами - Служба Service Desk
-- Управление конфигурациями
-О- Управление изменениями й- Управление релизами
—
Управление операциями
-- Управление уровнем обслуживания
Ч> Управление финансами для ИТ-услуг
-•- Управление проблемами -ОУправление мощностями
у
Управление непрерывностью
предоставления ИТ услуг
— Управление доступностью
-•- Программа по постоянному
улучшению услуг (SIP) -+Метрики бизнес перспективы
—
Янв
Среднее
Управление безопасностью
" " " Управление рисками
значение
-•- Управление документацией
Рис. 10.2. Совокупные показатели по всем метрикам
113
Глава 10. РЕАЛИЗАЦИЯ МЕТРИК
Все метрики
Программа по постоянному
улучшению услуг
(SIP) Управление документацией
^___—1________^ Управление операциями
Управление проблемами
Управление непрерывностью
предоставления ИТ-услуг
Управление уровнем сервиса
Управление релизами
Управление рисками
Компетентность, осведомленность,
обучение (CAT)
-
Управление доступностью
Управление программами
и проектами
Метрики перспективы бизнеса
Управление конфигурациями
Управление мощностями
* Служба Service Desk
Средние значения
1
В текущем месяце
Управление финансами для ИТ-услуг
Управление инцидентами
Управление изменениями
Управление информационной
безопасностью
Рис. 10.3. Средние показатели за последние шесть месяцев (лепестковая диаграмма)
Теперь перейдем к рассмотрению темно-серой линии. В реальной
жизни подобный разброс значений маловероятен, тем не менее мы
видим, что наименее успешными в этом году оказались служба
Service Desk и процессы: управление изменениями, группа процессов
бизнес-перспективы,
управление
проблемами,
управление
документацией. Было бы полезно сосредоточить на них внимание
SIP, особенно это относится к двум последним процессам,
поскольку в течение всего периода они демонстрировали плохие
показатели относительно целевого значения.
11
Постоянное
совершенствование
с помощью метрик
— А ну, давай! — кричала Королева. — Еще быстрее!
И они помчались так быстро, что, казалось,
скользили по воздуху, вовсе не касаясь земли ногами,
пока, наконец, Алиса совсем не выбилась из сил.
Внезапно они остановились, и Алиса увидела, что
сидит на земле и никак не может отдышаться.
Королева прислонила ее к дереву и сказала ласково:
— А теперь можешь немного
отдохнуть!
Алиса в изумлении огляделась.
— Что это?—спросила она. — Мы так и остались под
зтим
деревом! Неужели мы не стронулись с места ни на шаг?
— Ну, конечно, нет, — ответила Королева. — А ты
чего
хотела?
- — У нас, — сказала Алиса, с трудом переводя дух, —
когда долго бежишь со всех ног, непременно попадешь в
другое место.
— Какая медлительная страна! — сказала Королева.
— Ну,
а здесь, знаешь ли, приходится бежать со всех ног,
чтобы толь
ко остаться на том же месте! Если же хочешь попасть в
другое
место, тогда нужно бежать по меньшей мере вдвое
быстрее!
Льюис Кэрролл «Алиса в
Зазеркалье»
Черная Королева из Зазеркалья сказала, что в ее
стране приходится бежать со всех ног, чтобы остаться
на том же месте. Задумайтесь об этом: организациям
нужно постоянно совершенствоваться, чтобы удержать
свои позиции. Многие учения об управлении
поддерживают такой подход и настаивают на
1
Перевод Нины Демуровой.
116
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
постоянном улучшении качества предоставления услуг: среди них и
цикл Деминга — «План — Выполнение — Проверка —
Реагирование» (Plan — Do — Check — Act), и руководство Six Sigma
«Определение, измерение, анализ, совершенствование и контроль»
(Define, Measure, Analyze, Improve and Control).
У всех этих концепций есть одна общая особенность: без
измерения показателей процесса они не были бы в состоянии
реально изменить культуру и результаты деятельности компании. Но
как подстраивать цели метрик под постоянно меняющиеся
потребности организации и как менять сами метрики по мере
созревания процессов и организаций?
Если девять из десяти метрик процесса неизменно выполняются, а
одна нет, то следует обратить внимание на эту одну, выяснить, в чем
ее особенность, как можно разложить ее на составляющие и
оценить более подробно.
Недавно одна крупная организация расформировала отдел
отчетности, насчитывающий свыше сотни сотрудников: выяснилось,
что выпускавшиеся отчеты не только не использовались для принятия
важных решений бизнеса, но еще и дублировали информацию,
которую можно было легко получить из других источников. Опасность
очевидна: если допустить, чтобы подготовка отчетов, как это бывает
в бюрократических организациях, существовала в качестве
отдельной функции, не была связана с программой по постоянному
улучшению качества предоставления услуг (SIP) и не оценивалась с
точки зрения полезности и эффективности, то она может поглотить
значительно больше ресурсов, чем представляется разумным с
точки зрения компании.
Важно понимать, что именно может быть предпринято, если
результат некоторой метрики выходит за пределы желаемого
диапазона. Если никаких конкретных действий на этот случай не
предусмотрено, лучше вообще не собирать соответствующие
данные: сбор информации стоит денег и оправдывается только
полезностью информации, т. е. ее дальнейшим эффективным
использованием.
Если метрики, передаваемые в подразделение управления
услугами, слишком подробны, то даже незначительные изменения в
самом процессе, произведенные в соответствии с требованиями
SIP, в состоянии сделать сбор данных невозможным. Чтобы этого
избежать, метрики должны измерять фундаментальные части
процесса, вносящие вклад в его эффективность. Программные
инструменты для управления услугами позволяют измерить
несколько сотен показателей, однако многие из этих метрик
совершенно бесполезны для принятия решений по улучшению
процесса — они измеримы, но несущественны и малопригодны для
дальнейшего использования.
Стоит взглянуть на задачи, выполняемые метриками. При
рассмотрении управления услугами сверху вниз бизнес
формулирует свой взгляд на то, куда он стремится и что ему нужно,
чтобы туда добраться. Отсюда вытекает стратегия, а из нее, в свою
очередь, — планы, политика и задачи, определяющие, что должно
быть сделано. Данное понимание перспективы позволяет
Глава 11. ПОСТОЯННОЕ СОВЕРШЕНСТВОВАНИЕ С ПОМОЩЬЮ МЕТРИК
117
увидеть, почему одни метрики с точки зрения курса, взятого
компанией, не слишком интересны, а другие исключительно важны.
Не всегда получается разрабатывать метрики именно таким
образом, но это хорошая проверка их разумности перед
использованием.
В этой книге сделана попытка предложить подобный список
значимых метрик, каждая из которых привязана к четко
обозначенной цели и задаче процесса. Кроме того, здесь
рассказывается о правилах самостоятельного построения метрик,
даются советы по их использованию, рассматриваются способы их
представления и сравнения друг с другом. В приложениях, которые
следуют далее, вы найдете подробное описание и объяснение всех
метрик, перечисленных в главе 8. Их можно адаптировать к
конкретным потребностям вашей организации.
___________________________________________________________
А
Метрики
для управления инцидентами
Главная пель процесса управления инцидентами заключается
в том, чтобы как моджно быстрее(и в установленный срок)
восстановить нормальное функционирование сервиса и
минимизировать неблагоприятное воздействие инцидента на
бизнес-операции, тем самым поддерживая ка-чество и доступность
обслуживания на самом высоком уровне, «нормальным» считается
функционирование сервиса в рамках соглашения об уровне услуг
(SLA).
(Библиотека ITIL, том «Поддаержка услуг»
Миссия: минимизировать воздействие сбоев сервиса на. бизнеспроцессы организации, восстановив его путем эффективного
управления инцидентами.
Владелец процесса: менеджер инцидентов.
Задача метрики: предотвратить нарушение согласованных
уровней сервиса, обеспечив своевременное устранение
инцидентов.
Метрика:
Процент инцидентов, решенных на первой
линии поддержки
Описание:
Сколько инцидентов не требуют эскалации на
вторую линию поддержки.
Спецификация:
эскалации.
Обоснование:
службы
Количество инцидентов, не требующих
Измеряет несколько параметров. Если у
Service Desk имеется хорошая база данных по
известным ошибкам, поставляемая управлением
проблема-
120
Аудитория:
Ограничения:
Опасное
значение:
Целевое
значение:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
ми, количество инцидентов, устраняемых
первой линией поддержки, вырастет.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Если процесс управления проблемами успешно
ликвидирует
коренные
причины,
доля
инцидентов, разрешение которых возможно на
первой
линии
поддержки,
сократится,
вследствие чего может уменьшиться и число
фактически разрешенных на ней инцидентов.
<65
85
Возможные значения: 0-100
Метрика:
Показатель эффективности. Уравновешивается
метрикой степени удовлетворенности клиента,
поскольку обслуживание заявки должно
длиться столько, сколько необходимо, чтобы
удовлетворить запросы пользователя по
решению
проблемы.
С
хорошим
инструментарием и БД по известным ошибкам этот
показатель можно уменьшить.
Спецификация:
Метрика показывает, сколько длится обработка
инцидента до момента эскалации.
Обоснование:
Слишком быстрое закрытие заявки вредно с
точки зрения удовлетворенности клиентов.
Задача службы Service Desk заключается в
эффективной обработке заявок, а метрика
отражает степень этой эффективности.
Аудитория:
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения:
Нет
Опасное значение:
>20 10
Целевое значение:
999999
Возможные
значения:
Описание:
А Метрики для управления инцидентами
121
Метрика:
Измеряется путем проверки истории заявок и
нахождения переназначенных.
Спецификация:
Сколько инцидентов назначены не той рабочей
группе.
Обоснование:
Переназначение заявок замедляет решение и
снижает эффективность работы команд. Чтобы
снизить этот показатель, нужны действенные
сценарии обработки обращений, обучение,
инструментарий и соответствующие процессы.
Аудитория:
Владелец процесса, руководство ИГ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения:
Опасное значение: Нет 30
Целевое значение: 20 0100
Возможные
значения:
Описание:
Метрика:
Когда заявка поступает в службу Service Desk,
ей назначается определенное время обработки
в зависимости от SLA службы и приоритета
заявки. Метрика показьшает, насколько часто
достигается целевое значение.
В заданный срок в соответствии с
Спецификация:
приоритетом.
Обоснование:
Непосредственный показатель эффективности
выполнения SLA службой Service Desk.
Аудитория:
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения:
Опасное значение: Нет <90
Целевое значение: 95 0100
Возможные
значения:
Описание:
А Метрики для управления инцидентами
121
Метрика:
Процент инцидентов, некорректно назначенных на сотрудников службы поддержки (%
инцидентов}
Описание:
Измеряется путем проверки истории заявок и
нахождения переназначенных.
Спецификация:
Обоснование:
Сколько инцидентов назначены не той рабочей
группе.
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Переназначение заявок замедляет решение и
снижает эффективность работы команд. Чтобы
снизить этот показатель, нужны действенные
сценарии обработки обращений, обучение,
инструментарий и соответствующие процессы.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 30
20 0100
Метрика:
Процент инцидентов, решенных в
течение заданного времени согласно
приоритету (% инцидентов}
Описание:
Когда заявка поступает в службу Service Desk,
ей
назначается
определенное
время
обработки в зависимости от SLA службы и
приоритета
заявки.
Метрика
показывает,
насколько часто достигается целевое значение.
В заданный срок в соответствии с
приоритетом.
Непосредственный показатель эффективности
выполнения SLA службой Service Desk.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Нет <90
95 0100
122
Метрика:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Среднее время ответа второго уровня
поддержки (минуты)
Описание: Время между передачей заявки на второй уровень
поддержки и ее принятием. Показатель эффективности
второго уровня поддержки.
Спецификаци Минуты.
я:
Передача заявок на второй уровень грозит несоблюОбоснование:
дением сроков, оговоренных в SLA. Время
между передачей и принятием заявки
оказывает
прямое
воздействие
на
длительность
задержки.
Метрика
отслеживает
время
реагирования
и
обеспечивает эффективность приема заявок.
Аудитория:
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения:
Нет
Опасное значение:
>10
Целевое значение: Зависит от приоритета. Например, для заявок с
приоритетом 1 (высшим) максимальное время
реагирования 10 минут; с приоритетом 2
(средним) — 30 минут, а с приоритетом 3
(низшим) — до 2 часов.
Возможные значения: 999999
Метрика:
Описание:
Спецификаци
я:
Обоснование:
Аудитория:
Ограничения:
Среднее время решения инцидента
(минуты)
Измеряет
продолжительность
решения
инцидента с момента открытия заявки до
момента ее решения. Обратите внимание:
измеряется время пребывания инцидента на
различных стадииях обработки, сюда не
включается время нахождения заявки в
состоянии
«ожидание
пользователя»
и
«закрыта».
Время в минутах от открытия заявки до
решения инцидента.
Это популярная метрика, показывающая общую
эффективность
процесса
управления
инцидентами.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Измеряется время с момента открытия заявки
до решения инцидента (не путать с
закрытием заявки).
А. Метрики для управления инцидентами
Опасное
значение:
Целевое
значение:
123
Между решением инцидента и закрытием
заявки
имеется
еще
один
шаг
—
административный, который не представляет
интереса для клиента. Этот шаг можно
использовать для обновления базы знаний,
улучшения качества регистрации и т. п. Его
продолжительность не имеет значения для
клиента, следовательно, не должна ему
сообщаться. Метрика требует, чтобы система
регистрации различала состояния «инцидент
решен» и «заявка закрыта».
>30
20
Возможные значения: 999999
Метрика:
Процент переназначенных инцидентов
{инциденты}
Описание:
Измеряет число инцидентов, более одного
раза назначенных на ресурс второго или
третьего уровня (так называемую группу
решения).
Заявки, которые были к моменту закрытия
назначены более двух раз. Как правило,
инциденты устраняются без назначения или с
назначением ресурса, а затем назад службе
Service Desk. Метрика учитывает
все
дальнейшие назначения.
Иногда помощь от других команд необходима и
переназначение
задания
является
единственным правильным решением. Но
подчас задания по ошибке попадают не к тем
командам,
и
их
приходится
снова
переназначать. Это отнимает время, снижает
доступность и говорит о том, что в управлении
инцидентами не отработан правильный выбор
исполнителей. Метрика позволяет увидеть
масштабы проблемы и понять, что делать для
исправления положения, как усовершенствовать
процессы
и
улучшить
информационное
наполнение базы данных по известным
ошибкам.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное
значение:
124
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Целевое значение:
10
Возможные значения: 0-100
Задача метрики; помогать процессу управления проблемами в
выявлении тенденций по инцидентам, а также в оценке
эффективности базы данных по известным ошибкам и CMDB.
Метрика:
Описание:
Процент неправильно
классифицированных инцидентов {%
инцидентов}
При регистрации каждой заявке назначается
категория, что облегчает ее обработку и
последующий
анализ.
Когда
заявка
закрывается, в соответствующей записи
указывается ее настоящая категория. Метрика
Спецификация:
показывает, сколько раз две категории не
совпали.
Количество
инцидентов,
которые
при
Обоснование:
первоначальном присвоении категории были
неправильно описаны или классифицированы.
Правильная классификация ускоряет решение
проблем.
Показатель
характеризует
эффективность
сценария
получения
информации у клиентов, уровень подготовки
Аудитория:
персонала центра обработки вызовов и
качество поддерживающей среды (например,
CMDB).
Ограничения:
Владелец процесса, руководство ИТ, владелец
Опасное значение: процесса SLA, бизнес-клиент, члены команды,
Целевое значение: владелец процесса SIP.
Возможные
Нет
значения:
60
40 0100
Задача метрики: обеспечить оценку правильности выявления и
регистрации всех инцидентов.
Метрика:
Описани
е:
Процент обращений, поступивших к
специалистам службы поддержки
«напрямую», минуя первый уровень (%
обращений)
Частота обращений клиентов непосредственно
на второй или третий уровень поддержки.
Измеряется путем подсчета поступивших
заявок. Важно, чтобы все со-
А. Метрики для управления инцидентами
Спецификация:
официальному ка-
Обоснование:
специалистам
Аудитория:
про-
125
грудники ИТ обязательно открывали инциденты,
если им звонят напрямую.
Заявки, которые не проходят по
налу.
Прямые обращения к техническим
имеют ряд недостатков. Специалисты теряют
время, которое предназначено для других дел.
Служба Service Desk регистрирует не все
инциденты. Само явление означает, что
пользователи не доверяют стандартному
процессу.
Владелец процесса, руководство ИТ, владелец
цесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения:
Нет
Опасное значение: > 10
Целевое значение: 5
Возможные значения:
0-100
Задача метрики: эффективное предоставление ИТ-услуг.
Метрика:
Степень удовлетворенности клиентов
{удовлетворенность}
Описание:
заяв-
Служит противовесом для других метрик. Если
Спецификация:
оценку в
Обоснование:
трех-
Аудитория:
процесОграничения:
Клиенты,
ки
закрываются
слишком
быстро
или
обслуживаются слишком долго, то независимо
от того, что говорят внутрифирменные метрики,
степень удовлетворенности клиентов начнет
снижаться и данная метрика это покажет.
Для измерения клиента просят поставить
момент закрытия заявки. Это можно делать
каждый раз или выборочно.
Эта метрика всегда будет оставаться в списке
четырех самых важных для управления
инцидентами как прямой способ выяснить
отношение сообщества пользователей к
предоставляемому сервису.
Владелец процесса, руководство ИТ, владелец
са SLA, бизнес-клиент, члены команды, владелец
процесса SIP.
Не стоит слишком докучать пользователям.
как правило, гораздо лучше относятся к выборочным
126
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
опросам, чем к необходимости отвечать на один
или несколько вопросов после каждого звонка.
Опасное значение:
<3 Целевое значение:
4 Возможные значения:
0-5
Метрика:
Процент звонков, являющихся запросами на
оказание услуг {% обращений}
Описание:
Процент звонков, которые представляют собой запросы на обслуживание, а не обращения по поводу
инцидентов (или по иным причинам).
Спецификаци Обращения, которые обрабатываются службой Service
Desk как запросы на обслуживание.
я:
По мере того как служба Service Desk становится
заслуживающим доверия консультантом, а
количество инцидентов сокращается, этот
Обоснование:
показатель должен расти. Чем он выше, тем
больше степень зрелости Service Desk.
Начинать
лучше
с
низких
целевых
показателей,
ведь
большинство
пользователей будут считать, что Service Desk
— это просто новое название Help Desk, службы
помощи исключительно по техническим
проблемам.
Со временем, когда Service Desk начнет
восприниматься так, как задумано, количество
заявок возрастет, но если значительную их
долю составляют запросы на обслуживание, то
значит, это хорошо для предоставления услуг
бизнесу.
Аудитория: Владелец процесса, руководство ИТ, владелец процесса
SLA, бизнес-клиент, члены команды, владелец процесса
SIP.
Ограничения: Чтобы метрика была полезной, важно правильно
идентифицировать запросы на обслуживание, чтобы в
эту категорию не попадали инциденты.
5
Опасное значение:
Целевое значение:
15
Возможные значения: 0-100
А. Метрики для управления инцидентами
127
Задача метрики: показать, сколько в состоянии сделать для
решения инцидентов процесс управления инцидентами и какой
для этого нужен объем дополнительной работы. Метрика
отражает эффективность работы групп решения.
Метрика:
Процент инцидентов, правильно решенных
с первого раза (правильное решение с
первого раза) (% инцидентов)
Процент инцидентов, решенных с первой
попытки. Это значит, что не требуется ни
повторное открытие того же инцидента, ни
открытие нового инцидента, связанного с тем
же событием.
Спецификация:
Менеджерам групп решения эта метрика
позволяет определять эффективность работы
своих групп, а также достаточность знаний и
опыта экспертов для решения инцидентов.
Обоснование:
Чем эффективнее группа решения, тем меньше
нужно после нее дополнительной работы и тем
выше удовлетворение клиента.
Аудитория:
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения:
Решение не должно быть чисто техническим,
Опасное значение: необходимо, чтобы клиенты одобрили и
приняли его.
Целевое значение:
75%
Возможные
90% 1значения:
100%
Описание:
Задача метрики: показать, в какой степени процесс управления
инцидентами действует проактивно и какова его эффективность
в решении инцидентов.
Метрика:
Процент инцидентов, решенных
проактивно (% инцидентов)
Описание:
Процент инцидентов, которые были решены до
того, как клиенты сообщили об ошибке (нужна
тесная связь с мониторингом систем и
приложений).
Решение инцидентов (обнаруженных по
событиям, зафиксированным инструментами
мониторинга) до того, как у пользователей
возникли проблемы, — важ-
Спецификаци
я:
128
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
ная составляющая ценности, привносимой
процессами управления услугами.
Проактивное решение инцидентов повышает
ценность процесса управления инцидентами и
не затрагивает бизнес-процессы.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Требует наличия активного процесса
мониторинга.
0%
15%
0-100%
_______________________________________
в
Метрики службы Service
Desk
Цели службы Service Desk: обеспечить клиентам единую точку
контакта. Предоставлять консультации и иинструктаж, облегчать
восстановление нормального функционирования служб с
минимальным вредом для бизнеса и клиента в рамках
согласованных уровней обслуживания и приоритетов бизнеса.
(Библиотека ITIL, том «Поддержка услуг»)
Миссия: служба Service Desk является единой точкой контакта для
всех звонков в ИТ-отдел. Она обеспечивает сфокусированное
взаимодействие пользователей и ИТ с тем, чтобы способствовать
эффективному использованию ИТ-услуг, быстро восстанавливать
их
нормальное
функционирование
и
предупреждать
потенциальные сбои, давая советы пользователям.
Владелец процесса: менеджер службы Service Desk.
Задача метрики: как можно быстрее восстановить нормальное
функционирование сервиса и минимизировать негативное
воздействие на бизнес-операции, поддерживая максимально
возможное качество обслуживания.
Метрика:
специа-
Число звонков без эскалации на одного
листа (звонки)
Описание:
одного
Спецификация:
без
Число звонков, принятых без эскалации, на
специалиста.
Число звонков, принятых службой Service Desk
эскалации, на одного специалиста в день.
130
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Это число звонков без эскалации, т.е. таких,
длительность которых меньше минимального
периода управленческой эскалации и которые
технически никуда не перенаправляются. Иначе
говоря, измеряется количество «простых», или
«стандартных», звонков на первую линию
поддержки, с которыми специалист службы
Service Desk разбирается сам, не прибегая к их
технической или функциональной эскалации.
Это простой, но значимый показатель нагрузки
на операторов. Его высокое значение говорит
либо о проблеме с ресурсами, либо об
исключительно эффективной службе Service
Desk — с чем мы имеем дело в данном случае,
можно будет определить в ходе дальнейшего
исследования или на основе имеющихся
Аудитория:
знаний о зрелости организации.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
Ограничения:
Опасное значение: владелец процесса SIP. Нет 40 20 999999
Целевое значение:
Возможные
значения:
Обоснование:
Метрика:
Процент заявок, закрытых с первого раза
(на одного специалиста) {% заявок}
Описание:
Спецификация:
Процент заявок без последующей эскалации.
Процент заявок, закрытых после первого
обращения, так как дан ответ, предложено
обходное решение
и т. д.
Поскольку в идеале все заявки должны
обрабатываться с первого раза, важно
измерить, насколько служба Service Desk близка
к этому идеальному состоянию.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP. Нет 40 65 0-100
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
131
В. Метрики службы Service
Desk
Метрика:
Число звонков «не по адресу» {звонки}
Описание:
Все
CI
должны
быть
привязаны
к
соответствующей службе, а данный показатель
характеризует службу, которая относится к
звонку, выходящему за рамки SLA.
Число (в день) звонков, выходящих за рамки
SLA.
Значимый показатель эффективности работы
Service Desk.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Нет
Возможные
значения:
3
999999
Метрика:
Число звонков, заявки по которым были
эскалированы на второй уровень
поддержки (звонки)
Описание:
Число (в день) звонков, заявки по которым были
переданы на второй уровень поддержки.
Спецификация:
Любые звонки, переданные впервые (за один
день).
Показатель
полезности
второго
уровня
поддержки, а также эффективности первой
линии поддержки, обеспечиваемой службой
Service Desk. В идеале данный показатель
должен
снижаться
по
мере
совершенствования процессов и базы данных по
известным ошибкам. Частично перекрывается
метрикой «Процент заявок, закрытых с первого
раза».
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 105
999999
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
132
Метрика:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Степень удовлетворенности клиентов
(удовлетворенность)
Удовлетворенность оценивается в момент
закрытия либо для каждой заявки, либо для
некоторой выборки заявок.
Установите для метрики высокий приоритет,
Спецификация:
дождитесь устойчиво хороших результатов,
затем
понизьте
приоритет.
Проводите
измерения для каждого звонка или в течение
фиксированного периода времени.
Обоснование
В конечном итоге это главная метрика службы
Service Desk.
: Аудитория:
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения:
Нет
Опасное значение:
<3
Целевое значение:
4 0Возможные
5
значения:
Описание:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Число звонков, заявки по которым были
эскалированы на третий уровень
поддержки (звонки)
Звонки, для обслуживания которых требуется
третий уровень поддержки.
Сколько звонков в день эскалируется со второго
уро-веня поддержки на третий.
Слишком высокий показатель говорит о
необходимости совершенствования процедур
и повышения эффективности первого и
второго уровней поддержки.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 6 3
999999
133
В. Метрики службы Service Desk
Метрика:
Среднее время ожидания ответа на
звоно (секунды)
Описание:
Измеряет загруженнсть службы Service Desk и
ее обеспеченность ресурсами.
Время в секундах, в течение которого клиент
ожидает ответа на звонок.
Любые источники промедлений представляют
собой проблему, которая должна быть решена
для достижения целей метрики. Один из этих
источников легко устранить, обеспечив службу
достаточными ресурсами. Также задержки
приводят
к
быстрому
снижению
удовлетворенности клиентов.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 20
10
999999
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Средняя продолжительность попытки дозвониться до клиента (на один звонок) {минуты}
Время дозвона.
Сколько минут (в пересчете на один звонок)
агент тратит на то, чтобы перезвонить клиенту
для получения дополнительной информации
или предоставления решения.
Конечно, пользователи очень заняты и до них
иногда сложно дозвониться. В таких случаях
можно воспользоваться вместо звонка другим
коммуникационными
методами
(SMS,
электронная почта) и за счет этого сократить
непродуктивные потери времени.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 10 5
999999
134
Метрика:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Процент обращений через веб (%
обращений)
Описание:
Показатель
частоты
использования
соответствующего канала.
Спецификация:
В идеале большинство обращений должны
поступать через веб-интерфейс.
Обоснование:
Чем
проще
и
быстрее
корректное
размещение заявок, тем эффективнее и
оперативнее решаются проблемы. Метрика
применима и к другим возможным каналам
обращения, например к электронной почте.
Эффективность службы Service Desk повышается еще и потому, что специалист в состоянии
определить, с какими пользователями нужно
связаться повторно и каким образом управлять
Аудитория:
этими контактами.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения:
Опасное значение: Нет 20
Целевое значение: 60 0100
Возможные
значения:
Метрика:
Описание:
Спецификаци
я:
Обоснование:
Аудитория:
Ограничения:
Процент
неправильно
эскалирован
Соответствует
числу заявок, которые были
ных
заявок
переназначены на основании их предыдущего
неправильного назначения.
Процент заявок, эскалированных не тем
рабочим группам.
Служба Service Desk старается возобновлять
нормальное функционирование сервисов как
можно
быстрее.
Показатель
измеряет
устранимую
задержку,
связанную
с
неправильным назначением заявок на конкретных исполнителей.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
В. Метрики службы Service Desk
135
Опасное значение:
15
Целевое значение:
5
Возможные значения: 0-100
Задача
метрики
ентов.
Метрика:
: обеспечить доступность службы Service Desk клиддя
Процент звонков, которые были прерваны
пользователями (% звонков)
Когда телефон является главным входным
каналом службы Service Desk, у компании
должно быть достаточно сотрудников для
приема звонков, причем они должны быть
готовы принимать входящие звонки в течение
оговоренного времени. Иначе пользователи не
Спецификаци
смогут сообщить о своей проблеме.
я:
Число
звонков,
которые
пользователи
Обоснование:
прервали, не дождавшись ответа после
согласованного времени ожидания или числа
Аудитория:
гудков, поделенное на общее количество
обращений,
зарегистрированных
системой
автоматического
распределения
звонков
(Automatic
Call
Distribution
System
—
ACD).
Ограничения:
От достижения целей метрики существенно
зависит степень удовлетворенности клиентов.
Высокое значение свидетельствует о низкой
доступности
сервиса,
обусловленной
нехваткой кадров, длительным временем
обработки заявок, неэффективными процессами.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Необходима
система
ACD,
технически
позволяющая
регистрировать
пропущенные
звонки и строить соответствующие отчеты.
Важно оговорить число гудков и процедуру
обработки звонка, так чтобы метрика не
включала случаи, когда абонент вешает трубку
раньше установленного числа гудков, в ходе
Опасное значение: нормальной обработки.
Целевое значение: 5% 3%
1-100
Возможные
Описание:
значения:
136
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Задача .метрики: измерить эффективность процесса обработки
звонков, чтобы определить загруженность службы Service Desk.
Метрика:
Описание:
Спецификаци
я:
Обоснование:
Аудитория:
Ограничения:
Процент звонков, по которым были
открыты заявки на устранение
проблемы
В службу Service Desk поступает множество
звонков. Некоторые из них не регистрируются в
системе учета по ряду причин (например,
дополнительные). Метрика позволяет понять,
сколько звонков действительно сообщают об
инцидентах или являются дополнительными, а
сколько поступило не в ту службу поддержки
(например, в ИТ вместо коммунальных услуг) и
т.д. При высоком значении показателя
необходимо изучить, какие звонки проходят
через Service Desk и насколько эффективно они
обслуживаются.
Отношение
(в
день)
числа
звонков,
зарегистрированных ACD, к числу заявок на
устранение
проблемы
(открытых
по
телефонному звонку).
Служба Service Desk должна располагать
эффективной процедурой обработки звонков,
при которой все они регистрируются в системе
учета заявок на устранение проблем. Число
дополнительных звонков следует снижать с
помощью
проактивных
механизмов.
Пользователей
необходимо
проинструктировать относительно правильных
контактных телефонов. Метрика отражает все
это и помогает повысить эффективность
службы Service Desk.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Метрику следует использовать, когда телефон
является главным каналом, по которому
поступают сообщения об инцидентах. В ACD
должна быть функция построения отчетов о
звонках.
Опасное значение:
Целевое значение:
I
Возможные значения: >1
137
В. Метрики службы Service Desk
Задача метрики: Проанализировать загруженность службы Service
Desk и рассчитать потребность в кадрах.
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничени
я:
Опасное значение:
Целевое значение:
Возможные
Процент инцидентов, поступивших от
процесса управления событиями {%
инцидентов}
Системы управления предприятием генерируют
автоматические
предупреждения,
которые
встроены в систему учета инцидентов и могут
автоматически
направляться
группам
поддержки. Этот механизм уменьшает работу
по регистрации звонков в Service Desk и
помогает вести проактивный мониторинг и
управление инцидентами.
Отношение числа заявок на устранение
проблем, созданных за определенный период
системами управления событиями, к общему
числу заявок за это же время.
Чем выше этот показатель, тем меньше у
службы Service Desk работы по регистрации и
назначению заявок.
Владелец процесса, руководство ИТ, владелец
SLA, члены команды, владелец SIP.
Интеграция системы управления событиями с
системой учета инцидентов должна исключать
генерацию нескольких заявок по одному и
тому же событию. В противном случае
значение показателя будет искаженным.
>0
О
0-100
значения:
Задача метрики: показывать компетентность службы Service Desk
в отношении того, в какиих областях возникают инциденты и какие
группы должны заниматься их решением.
Метрика:
Процент звонков, правильно назначенных с
первого раза (% заявок)
Описани
е:
Процент заявок, которые служба Service Desk
точно назначила тем исполнительным
группам, которые
138
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения;
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
решают именно данные задачи. Демонстрирует
эффективность службы и обеспечивает
доверие к ней со стороны клиентов.
Количество заявок, которые группы решения не
отклонили и не передали немедленно другой
группе.
Правильное назначение заявок обеспечивает
эффективное решение проблем, снижает сроки
обработки заявок и свидетельствует о
профессионализме обработки. Оно также
гарантирует, что заявки не передаются от одной
группы к другой.
Владелец процесса, руководство ИТ, владелец
SLA, члены команды, владелец SIP.
Объем знаний о службе Service Desk,
75%
90%
0-100
с
__________________________________________________
Метрики для управления
конфигурациями
Цели процесса управления конфигурациями:
- отчитываться за все активы и конфигурации ИТ в рамках
подразделения
и его служб;
- предоставлять правильные данные о конфигурациях и
соответствующей
документации для поддержки остальных процессов управления
услугами;
- обеспечивать стабильную основу для процессов управления
инцидента
ми, проблемами, изменениями и релизами;
- сверять записи о конфигурации с фактическим состоянием
инфраструк
туры и исправлять все несоответствия.
(Библиотека ITIL, том «Поддержка услуг»)
Миссия: определять, контролировать и проверять информацию,
требуемую для управления ИТ-услугами путем определения и
поддержки базы данных контролируемых объектов, их статуса,
жизненного цикла и отношений, а также любой другой
информации, необходимой для рентабельного управления
качеством ИТ-услуг.
Владелец процесса: менеджер конфигураций.
Задача метрики: получать правильные данные об ИТинфраструктуре и ее связях, эффективно управлять этой
информацией в соответствии с потребностями бизнеса и
согласованными политиками.
Метрика:
{лицензии}
Число неиспользуемых лицензий
Описание:
ПО с
CMDB содержит записи обо всех лицензиях на
указанием того, где они используются, что
позволяет составить отчет о неиспользуемых
лицензиях.
140
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Процесс управления конфигурациями должен
контролировать лицензии на ПО, чтобы
минимизировать расходы на те из них, которые
не используются.
Определенное количество неиспользуемых
лицензий — нормальное явление: они нужны,
чтобы
удовлетворить
потребности
в
наращивании мощности в ближайшие несколько
недель.
Высокое
значение
показателя
указывает на проблемы с процессом управления мощностями, а те в свою очередь — на
плохое использование этим процессом базы
CMDB, возможно, из-за ошибок в ней. Метрика
побуждает сотрудников, ответственных за
управление
конфигурациями,
обеспечить
правильность информации о лицензиях и
добиться,
чтобы
процесс
управления
мощностями опирался на эти данные для
минимизации
числа
неиспользуемых
лицензий.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP. Нет 80 50 999999
Число RFC, не выполненных из-за
неверных данных в CMDB {RFC}
RFC опираются на информацию CMDB. Если она
неверна и RFC в итоге отклоняются процессом
управления изменениями, это необходимо
зафиксировать. Для улучшения качества CMDB
этот показатель должен быть низким. Его
измерение означает, что команда управления
конфигурациями должна тесно сотрудничать с
менеджером по изменениям, обеспечивая
согласованность RFC с CMDB. Тогда качество
повысится.
Авторы RFC должны иметь возможность
опираться на то, что информация в CMDB
верна. RFC не должны отклоняться из-за
ошибочных данных в CMDB.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
С. Метрики для управления конфигурациями
141
Ограничения:
Нет
Опасное
значение:
20
Целевое
значение:
10
Возможные
значения:
999999
Метрика:
Число неавторизованных
конфигураций {конфигурации}
Описание:
Конфигурации
в
CMDB,
которые
не
авторизованы должным образом.
Это вопрос управления и взаимодействия с ИГ и
коллективами пользователей. В конечном итоге
нужно стремиться к действительно низкому
значению показателя.
Все
конфигурации
должны
получить
соответствующее
разрешение:
важно
обеспечить четкость процесса и точную запись
авторизации в CMDB. Метрика оценивает
работу этих процессов.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 15 5
999999
Спецификация:
Обоснование:
Аудитория;
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика-
Описание:
Спецификация:
Обоснование:
Число
инцидентов,
связанных
с
невыполнением
изменений
из-за
неправильно задокументированных CI
{инциденты}
Изменения получают одобрение в контексте
CMDB, которая считается авторитетным
источником. Если изменение не удается
выполнить из-за неверных данных о том или
ином компоненте, ответственность за это
несет процесс управления конфигурациями.
Вначале число таких инцидентов может быть
высоким — метрика должна помочь его
снизить.
Информация CI в CMDB должна быть верна,
тогда изменения будут корректными и не
приведут к инцидентам.
142
Аудитория:
Ограничени
я:
Опасное
значение:
Целевое
значение:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
При
закрытии
инцидентов
должна
существовать возможность регистрировать
те из них, которые произошли в результате
изменений, не выполненных из-за ошибок в
CMDB.
6О
Возможные значения: 999999
Метрика:
Описани
е:
Число нарушений SLA, вызваных
ошибками CMDB (SLA)
В первую очередь нужно обеспечить степень
правильности CMDB, достаточную, чтобы
предотвратить нарушение SLA. Со временем
следует добиться, чтобы этот показатель
можно было принять всегда равным 0; после
того, как он пробудет нулевым несколько
месяцев, вместо него можно подставить другую
метрику.
Спецификация:
SLA должны выполняться всегда. Когда CMDB
внедрена и механизмы, применяемые в
управлении
конфигурациями,
успешно
взаимодействуют с качественным управлением
изменениями, простоям из-за проблем с базой
данных вообще
нет
места.
Значение
показателя определяется по статусу закрытия
Обосновани
заявок.
е:
Неверные или отсутствующие элементы CMDB
Аудитория:
могут помешать решению проблем и даже
процессу управления инцидентами, что и
фиксирует
данная
метрика.
Поскольку
управление конфигурациями стремится снизить
этот показатель до нуля, его можно рассматривать как оценку зрелости процесса.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения: Опасное
Нет
значение: Целевое
2
значение: Возможные
О
значения: 999999
С. Метрики для управления конфигурациями
143
Задача метрики: обеспечить правильность информации,
предоставляемой CMDB.
Метрика:
Число RFC, по которым не было обновления
CI {RFC}
Каждый раз, когда CI подвергается изменению,
выполненную операцию должны отражать
соответствующий авторизованный RFC и
последующее обновление CMDB. В процессе
аудита RFC сопоставляется с информацией о
конфигурации в CMDB. Эти данные должны
совпадать. Показатель можно измерять в
процентах от общего числа поднятых RFC за
некоторый период.
Спецификация:
Число выявленных при аудите RFC, для
которых
CMDB
не
отражает
соответствующего
состояния
конфигурации.
Обоснование:
Метрика
обеспечивает
правильную
и
авторизованную информацию в CMDB за счет
строгого следования процессу.
Аудитория:
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
Ограничения:
процесса SIP.
Опасное значение:
Нет
Целевое значение:
>5, в любой момент времени
Возможные
Нет
значения:
99999
Описание:
Метрика:
Описание:
Спецификаци
я:
Обоснование:
Процент некорректных CI {% CI}
В данной метрике должны учитываться все
изменения в CI, сделанные для исправления
ошибок.
Качество ввода данных играет важную роль, и
так как некоторые из них поступают от других
инструментов и из других подразделений, может
потребоваться какое-то время, пока удастся
уменьшить показатель до приемлемого уровня.
Метрика рассчитывается как отношение числа
некорректных CI к их общему числу— так как мы
всегда знаем, сколько CI в CMDB, определить
этот процент не составляет труда.
Процессы
управления
конфигурациями
спроектированы так, чтобы обеспечивать
точность информации CI. Если данная метрика
со временем не снижается,
144
Аудитория:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
необходимо в рамках SIP выявить области, в
которых возможно повышение эффективности.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Нет
80
40
Ограничения:
Опасное
значение:
Целевое
значение:
Возможные значения: 0-100
Задача метрики: обеспечить эффективность процессов
управления услугами.
Метрика:
Степень удовлетворенности клиентов
{удовлетворенность}
Описание:
Удовлетворенность клиентов, определенная
согласно
диаграмме,
описывающей
взаимодействие процессов.
Удовлетворенность клиентов определяется
согласно
диаграмме
взаимоотношений
процесса.
Проверка эффективности данного процесса.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
<3
4 05
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
D
Метрики для управления
изменениями
Цель процесса управления изменениями состоит в том, чтобы
обеспечить использование стандартизованных методов и
процедур для эффективной и быстрой обработки всех изменений
с
целью
минимизировать
воздействие
инцидентов,
обусловленных преобразованиями, на качество обслуживания и,
как следствие, улучшить повседневное функционирование
подразделения. (Библиотека ITIL, том «Поддержка услуг».)
Миссия: управлять всеми изменениями, которые в состоянии
повлиять на способность ИТ предоставлять обслуживание, с
помощью формального, централизованного процесса утверждения,
планирования и контроля, дабы обеспечить постоянное
соответствие ИТ-инфраструктуры требованиям бизнеса и
минимизировать риски.
Владелец процесса; менеджер изменений.
Задача
метрики:
сделать
управление
изменениями
эффективным процессом для выполнения преобразований,
востребованных организацией.
Метрика:
выпол-
Процент изменений, которые не удалось
нить {% изменений}
Описание:
мо-
RFC, которые получили одобрение, но потом не
гут быть выполнены.
Спецификация:
Обоснование:
учитывать
Изменения, которые не удалось выполнить.
Процесс управления изменениями должен
риск, связанный с RFC, и те запросы на изменение,
146
Аудитория:
Ограничения:
Опасное
значение:
Целевое
значение:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
которые не удастся выполнить надлежащим
образом, не следует одобрять.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
10
5
Возможные значения: 0-100
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обоснование:
Процент отклоненных RFC {% RFC}
Предложения об изменениях проверяются
(главным образом службой Service Desk). Когда
изменение принято и доведено до стадии RFC, у
него должен быть неплохой шанс пройти
успешно. Метрика оценивает качество процесса
проверки.
Хорошее
взаимодействие
позволяет
поддерживать данный показатель на низком
уровне.
Следует выявлять несостоятельные запросы на
изменение
на
ранней
стадии.
Нужны
качественные процессы, чтобы обеспечить
создание RFC, до мелочей соответствующих
стандарту, — тогда они не будут отклонены.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP. Нет 20 10 0-100
Число неавторизованных
изменений {изменения}
Любое
обнаруженное
изменение
инфраструктуры, для которого не существует
ни стандартного изменения, ни одобренного
RFC.
Хорошее
взаимодействие
позволяет
поддерживать данный показатель на низком
уровне.
Все изменения должны контролироваться.
D. Метрики для управления изменениями
Аудитория:
147
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP. Нет 30 15
Ограничения:
Опасное
значение:
Целевое
значение:
Возможные значения: 999999
Метрика:
Описание:
Число невыполненных изменений
{изменения}
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика характеризует два параметра. Один —
это число утвержденных изменений, не
выполненных в течение заданного времени,
другой — число RFC, которые не были ни
одобрены, ни отклонены.
Если показатель высокий, подразделение не
справляется
с
процессом
управления
изменениями — возможно, из-за того, что
слишком много изменений или недостаточно
сотрудников.
При
реализации
изменений
старайтесь
максимально
приблизиться
к
целевому
показателю времени. Если RFC накапливаются
и не выполняются, есть риск, что изменение,
способное предотвратить сбой бизнеса, не
будет выполнено вовремя.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 15 5
999999
Метрика:
Простои во время изменений {инциденты}
Описание:
Любые перерывы в обслуживании измеряются
числом
инцидентов.
Если
изменение
происходит в нерабочие часы сервиса, то по
определению простоя в обслуживании быть не
может.
В идеальном мире во время изменений не
бывает никаких незапланированных простоев.
Если видно, что провести изменение не удается,
нужно восстановить прежнее состояние до того,
как про-
Спецификация:
Обоснование:
Аудитория:
Спецификация:
Обоснование:
148
Аудитория:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
изошедшее начнет сказываться на работе
сервиса. План «отступления» необходимо
предварительно
протестировать,
чтобы
восстановление не привело к простою.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
6
О
Ограничения:
Опасное
значение:
Целевое
значение:
Возможные значения: 999999
Метрика:
Описание:
Число неудачных изменений без плана
возвращения в исходное состояние
{изменения}
Метрика:
Учитываются любые изменения со статусом «не
выполнено» и без плана возвращения в исходное
состояние.
Для всех изменений должен существовать план
возвращения в исходное состояние, и это нужно
всегда проверять.
Ни одно изменение не имеет права на
существование
без
проверенного
плана
возвращения в исходное состояние. Если
изменение оканчивается неудачей, а план
отсутствует, анализ риска был проведен
некачественно.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
2
О
999999
Описание:
Процент изменений, выполненных вовремя
{% изменений}
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Спецификация:
Для
всех
изменений
установлен
срок
выполнения. Если по истечении этого времени
они остаются незавершенными, метрика их не
учитывает.
Задержки иногда вызваны вескими причинами,
и их значительное количество — при условии,
что про-
D. Метрики для управления изменениями
Обоснование:
это
Аудитория:
про-
149
цент неудавшихся изменений низок — может
быть приемлемым. Поэтому данной метрике
следует назначить невысокий приоритет.
Если изменения систематически запаздывают,
говорит о слабом контроле и повышенном риске
сбоев бизнеса.
Владелец процесса, руководство ИТ, владелец
цесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения:
Нет
Опасное значение: 90
Целевое значение: 95
Возможные значения:
0-100
Метрика:
Процент изменений, вызвавших инциденты
{% изменений}
Описание:
которых
Учитываются все инциденты, при закрытии
Спецификация:
приведут
Обоснование:
работу
Аудитория:
про-
было установлено, что они произошли
вследствие изменения.
Если существует опасность, что изменения
к инцидентам, следует проводить их вне часов
SLA, во время запланированной остановки.
Если же инцидент все-таки случается, то,
вероятно, по причине плохого планирования
или тестирования.
Изменения никогда не должны нарушать
компании.
Владелец процесса, руководство ИТ, владелец
цесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения:
Нет
Опасное значение:
10
Целевое значение:
5
Возможные значения: 0-100
Метрика:
комите-
Число предложений Консультативного
та по изменениям (Change Advisory Board
— CAB), не реализованных вовремя
{действия}
Описание:
Консультатив-
В любом письменном предложении
ного комитета по изменениям оговаривается срок
150
Спецификация:
Обоснование:
Аудитория:
Ограничени
я:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
реализации. Если этот срок прошел, а
предложение
не
реализовано,
оно
учитывается в данной метрике.
Все предложения CAB должны реализовываться,
так что в данном показателе не должно быть
необходимости. Если он все-таки высок,
организация, возможно, работает в условиях
чрезмерного напряжения. Сравните это с
метрикой невыполненных изменений.
CAB должен предоставлять обратную связь,
иначе менеджер изменений не сможет
принимать эффективных решений.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP. Документы и предложения CAB
должны регистрироваться в строгом
соответствии с правилами. 3 О 999999
Опасное значение:
Целевое значение: Число экстренных изменений {изменения}
Все преобразования, которые происходят
Возможные
экстренно в рамках процесса управления
значения:
изменения. Процесс управления изменениями
предназначен для того, чтобы эффективно
Метрика:
выполнять все, что требуется, и за счет этого
Описание:
снижать
риск,
сопряженный
с
любым
преобразованием. При экстренных изменениях
Спецификация:
допускается полный или частичный отказ от
некоторых мер предосторожности (в частности,
от тестирования). Этот повышенный риск,
хотя порой он неизбежен, необходимо
держать на уровне разумного минимума.
Метрика
показывает
тенденцию
к
чрезмерному использованию процесса и
позволяет
предпринять
корректирующие
действия.
Потребность
в
экстренных
изменениях так или иначе будет периодически
возникать, но важно, чтобы соответствующий
Обоснование:
процесс не стал нормальным способом
действий. Метрика отслеживает частоту, с
которой
применяется
процесс
для
исключительных случаев.
Владелец процесса, руководство ИТ, владелец
Аудитория:
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
151
D. Метрики для управления изменениями
Ограничения:
Нет
Опасное значение: 3
Целевое значение: 3
Возможные значения:
Метрика:
999999
Число изменений, не принесших
ожидаемых результатов {изменения}
Описание:
Изменения, которые не приносят результатов,
запланированных в RFC.
Изменения определяются в RFC, при этом
Спецификация:
указываются ожидаемые результаты. По
завершении изменения его проверяют с точки
зрения
правильности
выполнения
и
соответствия
результатов
тому,
что
ожидалось. Метрика учитывает изменения,
статус которых после проверки указывает, что
они
не
принесли
запланированных
Обоснование:
результатов.
Предполагается,
что
планирование
и
тестирование обеспечат переход от RFC к
эффективным изменениям, не нарушающим
работу и приводящим к нужным результатам.
Проверка изменений позволяет увидеть, что же
произошло
в
действительности.
Метрика
Аудитория:
замыкает
эту
цепочку
и
показывает,
обеспечивает ли процесс внесения изменений в
целом ожидаемые улучшения.
Ограничения:
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Опасное значение: Чтобы судить о соответствии результатов
Целевое значение: изменения ожиданиям, нужны четкие и
измеримые целевые значения.
Возможные
значения:
3
3
99999
9
Задача метрики: высококачественные процессы управления ИТуслу-гами.
Метрика:
Степень удовлетворенности
клиентов {удовлетворенность}
Описани
е:
Внутренняя удовлетворенность процессом
управления изменениями, оцениваемая для
каждого RFC.
152
Спецификация:
Обоснование:
Аудитория:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Определяется
согласно
диаграмме
взаимоотношений процесса.
Надежный показатель качества результатов.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
<3
4
Ограничения:
Опасное
значение:
Целевое
значение:
Возможные значения: 0-5
_____________________________________________________
Е
Метрики
для управления релизами
Цели управления релизами:
— планировать и контролировать успешное развертывание ПО и
сопут
ствующих аппаратных средств;
— разрабатывать и внедрять эффективные процедуры по
распространению
и инсталляции измененных компонентов ИТ-систем;
— обеспечивать возможность отслеживания и безопасность всех
измене
ний в ПО и аппаратных средствах, а также установку только
правиль
ных, авторизованных и протестированных версий;
- узнавать и учитывать ожидания клиента при планировании и
развер
тывании новых релизов;
— согласовывать точное содержание и план выпуска релизов во
взаимо
действии с процессом управления изменениями;
— внедрять новые релизы ПО или аппаратные средства в
операционную
среду с помощью процессов управления конфигурациями и
изменени
ями. Релиз должен находиться в ведении управления
изменениями и
может состоять из любого сочетания аппаратных средств, ПО,
встроен
ных программ и документов CI;
— обеспечивать сохранение мастер-копий всех программ в
библиотеке
эталонного программного обеспечения (БЭПО) и обновление
базы
данных управления конфигурациями (CMDB);
- обеспечивать безопасность развертывания и изменения всех LTаппарат
ных средств, используя услуги управления конфигурациями.
(Библиотека ITIL, том «Поддержка услуг»)
154
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Миссия: сформировать целостную картину изменения ИТ-услуги и
обеспечить, чтобы все аспекты релиза, как технического., так и
нетехнического характера, рассматривались вместе.
Владелец процесса: релиз-менеджер.
Задача метрики: в точности регистрировать все исправленные
версии ПО в DSL.
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Число установленных программных
пакетов, отсутствующих в DSL {пакеты}
В рамках стандартного процесса верификации
любое
ПО,
обнаруженное
на
любом
оборудовании, можно сверить с DSL, установив
таким путем, авторизовано ли оно и правильна
ли его версия.
Объем ПО, установленного, но взятого не из DSL.
Для
выявления
таких
программ
может
понадобиться регулярный аудит ПО (например,
с помощью инструментов мониторинга).
Отсутствие регистрации в DSL у какого бы то ни
было ПО, имеющегося в ИТ-инфраструктуре, —
это и высокий риск с точки зрения
информационной безопасности, и признак
неэффективности управления релизами.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес- клиент, члены
команды, владелец процесса SIP.
Нет 50
25
999999
Задача метрики: контролировать релиз ПО в инфраструктуре,
чтобы свести к минимуму число вероятных сбоев.
Метрика:
Описани
е:
Число срочных релизов {релизы}
Срочные релизы выполняются в рамках
соответствующего процесса — когда он
активизируется, этот факт может быть
зафиксирован и учтен в данной метрике.
Е. Метрики для управления релизами
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
155
В идеале все релизы следует планировать
заблаговременно, так что со временем
количество
срочных
релизов
должно
сокращаться.
Срочные релизы сопряжены с высоким риском
ошибки
и,
как
следствие,
сбоями
в
обслуживании. Иногда они оправданны, но такие
случаи должны быть редки. Если данная метрика
регистрирует существенное число срочных
релизов в месяц, на это необходимо обратить
внимание.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Нет 5 О
999999
Задача метрики: обеспечить эффективное управление релизами
с минимальным ущербом для бизнеса.
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Число инцидентов, вызванных новым
релизом
{инциденты}
Б записях о закрытии инцидентов в качестве
одной из потенциальных причин должно
фигурировать управление релизами. Если
фиксируется именно она, это учитывается
данной метрикой.
Тщательно
спланированные
и
протестированные
релизы
не
должны
перерастать в инциденты.
При создании и тестировании релизов должны
быть разработаны соответствующие планы
возвращения
в
исходное
состояние,
позволяющие избежать инцидентов.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Нет 50
5
999999
156
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Задача метрики: эффективное управление релизами с целью
удовлетворения потребностей бизнеса.
Метрика:
релизов}
Процент своевременных релизов {%
Описание:
сро-
Управление релизами включает планирование
Спецификация:
релиОбоснование:
веские ос-
Аудитория:
владелец
ков всех релизов в CMDB. Все изменения этих
сроков учитываются данной метрикой.
По мере совершенствования планирования все
зы должны стать своевременными.
Для изменения сроков релиза иногда есть
нования.
Однако
предварительные
консультации со всеми заинтересованными
лицами помогут этого избежать.
Владелец процесса, руководство ИТ-отдела,
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения:
Нет
Опасное значение: 90
Целевое значение: 95
Возможные значения:
0-100
Задача .метрики; обеспечить эффективное управление релизами с
целью сокращения возможных сбоев в работе компании.
Метрика:
{релизы}
Число непротестированных релизов
Описание:
одобряться, при-
Все релизы должны тестироваться и
Спецификация:
использоваОбоснование:
Любой
Аудитория:
владелец
Ограничения:
чем обязательно человеком, независимым от
автора релиза. Если этого не происходит, такой
случай учитывается метрикой.
Метрика имеет большое значение: при
нии непротестированных релизов велика
опасность инцидентов и простоев.
Тестироваться должны даже срочные релизы.
непротестированный
релиз
угрожает
непрерывности функционирования бизнеса.
Владелец процесса, руководство ИТ-отдела,
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
Е. Метрики для управления релизами
157
Опасное значение:
О
Целевое значение:
О
Возможные значения:
999999
Средние трудозатраты на релиз {часы}
Простой
показатель
—
фактические
трудозатраты в человеко-часах.
Целевое
значение
и
ограничения
Спецификация:
устанавливаются на основе грубой оценки (в
человеко-часах), для их уточнения служит
сама данная метрика. Следует стремиться к
постепенному сокращению трудозатрат на
один релиз. В более интеллектуальной среде
можно
использовать
вместо
данного
показателя разность между прогнозируемым (в
плане релиза) и реальным числом человекоОбоснование:
часов.
Релизы следует планировать так, чтобы их
Аудитория:
разработка была рентабельной.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
Ограничения:
команды, владелец процесса SIP.
Для измерения данной метрики необходимо
достаточно
эффективное
управление
финансами. Но и отлаженные процессы
Опасное значение: управления проектами в состоянии давать
Целевое значение: довольно точную оценку.
Возможные
500 300
значения:
999999
Метрика:
Описание:
Метрика:
Число неиспользуемых лицензий на
ПО {лицензии}
Описание:
Лицензии на ПО, которые не инсталлированы
и не подтверждены со стороны процесса
управления мощностями.
Программные лицензии нужно оплачивать
только для CI, авторизованных на установку
программ из DSL. Все прочие лицензии
должны быть прекращены.
Если CMDB нормально функционирует, с ее
помощью несложно выявить неиспользуемые
лицензии.
Спецификаци
я:
Обоснование:
158
Аудитория:
Ограничения:
Опасное
значение:
Целевое
значение:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Тесное сотрудничество с процессом управления
мощностями должно обеспечить сохранение
тех
из
них,
которые
действительно
потребуются в ближайшие несколько недель
или месяцев.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Не
т
20
0
10
0
Возможные значения: 999999
Метрика:
Описание:
Процент точности оценки трудозатрат на
релиз (% времени)
Проще говоря, абсолютная величина разности
между
запланированным
и
реальным
временем.
Спецификация:
Это составная метрика, вычисляемая на основе
предполагаемого времени создания релиза,
фактического числа потраченных на него
человеко-часов и числа затронутых им CI. В
момент окончания планирования релиза
нужно сохранить предварительную оценку, а
после завершения работ сравнить с реальным
показателем. Значение представляет собой
разность
в
процентах
относительно
Обоснование;
запланированного времени.
Точные
прогнозы
позволяют
принимать
рациональные деловые решения. Улучшение
прогнозирования для небольших релизов
должно повысить и достоверность предсказаний
Аудитория:
для крупных релизов, имеющих решающее
значение для бизнеса.
Владелец процесса, руководство ИТ-отдела,
Ограничения:
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Для получения точных показателей нужны
Опасное значение: качественные
процессы
управления
Целевое значение: проектами и финансами.
Возможные
60 80
значения:
0100%
Е. Метрики для управления релизами
159
Задача метрики: обеспечивать эффективность процессов
организации
обслуживания.
Метрика:
Степень удовлетворенности
клиентов {удовлетворенность}
Описание:
Назначьте
метрике
высокий
приоритет,
сохраняйте его до тех пор, пока значения не
станут стабильно высокими, а затем понизьте.
В данном случае там, где это возможно, следует
включать в метрику также отчеты об
удовлетворенности конечных пользователей
конкретными развертываниями.
Управление релизами оказывает сильное
влияние на конечных пользователей, поэтому
важно
правильно
их
информировать,
осведомлять
и
обучать.
Уровень
удовлетворенности этим процессом будет
отражать его качество.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Нет
<3
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
4
0-5
Е.1. Метрики для поддержки приложений
Метрика:
Число проанализированных
программных ошибок {ошибки}
Описание:
Метрика
показывает
возможность
обслуживания программного кода. В идеале
изменений, связанных с модернизацией,
должно быть больше, чем изменений,
связанных с исправлением ошибок.
Показатель измеряется на основе перечня
ошибок, зафиксированных и признанных
исправленными.
Есть более детальные показатели — в данной
метрике
не
различаются
легкои
трудноразрешимые проблемы.
Спецификаци
я:
Обоснование:
160
Аудитория:
Ограничения:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
На метрику влияет качество самого кода — то,
сколько в нем вообще ошибок, нуждающихся в
исправлении. Если результат превышает
целевое значение, т.е. устранено больше
ошибок, чем ожидалось, это хорошо с точки
зрения процесса, а также возможности
обслуживания кода, но совсем не является
достоинством с точки зрения качества кода.
24
Опасное
значение:
Целевое
значение:
Возможные значения: 999999
Метрика:
Число оптимизаций {оптимизации}
Зарегистрированные и одобренные
оптимизации.
Учитываются улучшения программного кода,
которые не одобрены ни как расширения, ни
как исправления ошибок. Они необходимы,
поскольку
одна из задач управления
мощностями заключается в повышении
производительности
приложений.
Данная
метрика
представляет
собой
оценку
этой
Обоснование:
деятельности.
Важно,
чтобы
приложения
эффективно
использовали
ресурсы.
Для
повышения
эффективности
следует
разрабатывать
новые
Аудитория:
приложения, однако и те, что уже существуют,
могут быть улучшены.
Владелец процесса, руководство ИТ-отдела,
Ограничения:
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
На метрику влияет качество самого кода —
сколько в нем вообще мест, где можно что-то
улучшить. Если результат превышает целевое
значение, т.е. произведено больше улучшений,
Опасное значение: чем ожидалось, это хорошо с точки зрения
процесса,
а
также
и
возможностей
Целевое значение: обслуживания кода, но совсем не является
Возможные
достоинством с точки зрения качества кода.
значения:
10 20
99999
9
Описание:
Спецификация:
Е. Метрики для управления релизами
Метрика:
161
Число приложений/ревизий, выпущенных в
производство {сборки}
Одобренные релизы.
Оценивается согласно DSL.
Показатель
реальной
обеспечиваемой
продуктивности, не обязательно связанный с
Обоснование:
качеством приложения.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
Аудитория:
команды, владелец процесса SIP.
Необходимо учитывать обстоятельства: если
клиентам не нужны улучшения в программе, а
Ограничения:
код не содержит ошибок, релизов будет очень
мало.
2
4
Опасное значение:
99999
Целевое значение:
9
Возможные
значения:
Число учебных занятий для конечных
пользователей {занятия}
Метрика:
Ознакомление конечного пользователя с
новыми релизами и новыми сотрудниками.
Описание:
Метрика оценивает непрерывное обучение
пользовательского контингента, а также
Спецификация:
единовременные учебные занятия по новым
релизам. Это важный показатель качества
взаимодействия между службой поддержки
приложений и пользователями. Слишком часто
обучением пренебрегают, не рассматривая его
в качестве критерия успеха поддержки
приложений.
Метрика
сосредоточивает
внимание на данной проблеме.
Собственно занятия проводит служба управления
Обоснование:
релизами, но подготовкой учебных материалов и
мониторингом качества курсов занимается
служба поддержка приложений.
Владелец процесса, руководство ИТ-отдела,
Аудитория:
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
В зависимости от стабильности сообщества
Ограничения:
пользователей.
Описание:
Спецификация:
162
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Опасное значение:
5
Целевое значение:
10
Возможные значения: 99999
Метрика;
Число дефектов, обнаруженных по
журналам регистрации {дефекты}
Описание:
Это просто число новых ошибок, выявленных
самой
службой
поддержки
приложений.
Учитываются все ошибки, обнаруженные как
по журналу регистрации, так и по другим
источникам.
Исправлять ошибки, найденные пользователями,
нормально. Но лучше исправлять их еще до
того, как их обнаружат пользователи, —- тогда
удастся избежать перерывов в обслуживании.
Данный показатель характеризует работу
системы решения проблем по выявлению еще
не проявившихся ошибок. Метрика может быть
абсолютным числом найденных дефектов или
их числом на каждого сотрудника службы
поддержки приложений.
Измерения, способные улучшить качество услуг
для бизнеса, имеют большое значение. Высокий
уровень раннего обнаружения и устранения
проблем, как правило, незаметен. Нужно
сделать его видимым и стимулировать его
повышение.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
В зависимости от качества программного кода.
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
2
4
Метрика:
999999
Описание:
Специф икация:
Число временных решений,
протестированных и выпущенных в
производство {решения}
Временные
решения,
выпущенные
в
производство.
Все
временные
решения,
зарегистрированные процессом управления
релизами. Метрика может быть абсолютным
числом временных решений или их числом на
одного
сотрудника
службы
поддержки
приложений.
Е. Метрики для управления релизами
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обосновани
е:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
163
Учитываются временные решения как не
связанные, так и связанные с исправлением
кода. За первые, такие как исправления
конфигурации, служба поддержки приложений
отвечает непосредственно, в случае вторых
она отвечает за их тестирование.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Зависит от качества программного кода.
3
5
999999
Число временных решений, возвращенных
для доработки {решения}
Временные решения, которые не сработали.
Временные решения, отклоненные службой
управления релизами или такие, внедрение
которых окончилось возвращением системы в
исходное состояние. Метрика может быть
абсолютным числом временных решений или
их числом на одного сотрудника службы
поддержки приложений.
Показатель низкого уровня тестирования.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Зависит от качества программного кода.
1
2
999999
Е.2. Метрики для разработки приложений
Метрика:
Число ошибок, выявленных при разработке
или тестировании {ошибки}
Описание:
Дефекты, обнаруженные в ПО собственной
разработки.
Учитываются дефекты, выявленные при
разработке или тестировании, но не при
непосредственном использовании. Метрика
может быть абсолютным чис-
Спецификаци
я:
164
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
лом дефектов или их числом на одного
сотрудника службы поддержки приложений.
Мера надежности создаваемого кода.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Зависит от качества программного кода.
10
20
999999
Метрика:
Число ошибок, исправленных при тестировании {ошибки}
Описание:
Дефекты,
зарегистрированные
как
исправленные и протестированные.
Дефекты, обнаруженные при тестировании.
Метрика может быть абсолютным числом
дефектов или их числом на каждого сотрудника
службы поддержки приложений. Мера
производительности.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Зависит от качества программного кода.
20
25
999999
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Число зарегистрированных ошибок, которые
были исправлены {ошибки}
Описание:
Спецификация:
Дефекты ПО, вызвавшие сбой в обслуживании.
Ошибки,
в
отношении
которых
было
установлено, что именно они привели к
инцидентам,
зарегистрированным
службой
Service Desk. Метрика может быть абсолютным
числом ошибок или их числом на одного
сотрудника службы поддержки приложений.
Об этих ошибках, в отличие от дефектов ПО,
выявленных при тестировании, известно, что
они стали причиной инцидентов, поэтому
важно, чтобы они были исправлены.
Обоснование:
165
Е. Метрики для управления релизами
Аудитория:
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Зависит от качества программного кода.
5
10
Ограничения:
Опасное
значение:
Целевое
значение:
Возможные значения: 999999
Метрика:
Число приложений/ревизий, принятых к
использованию {сборки}
Описание:
Спецификация:
Действующие релизы.
Число успешно внедренных релизов с точки
зрения процесса управления релизами.
Показатель общей продуктивности и успешной
реализации.
Владелец процесса, руководство ИТ,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет 1 3
999999
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Число приложении/ревизии, отклоненных
^
-
~
г
^
1
службой поддержки приложении {сборки}
Описание:
Ограничения:
Дефектные сборки.
Сборки, представленные для релиза, но
отклоненные службой поддержки приложений в
рамках процесса управления релизами.
Показатель качества сборок. По мере
совершенствования
тестирования
этот
показатель должен снижаться.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Нет 3 I
Опасное значение:
999999
Спецификация:
Обоснование:
Аудитория:
Целевое значение:
Возможные
значения:
166
Метрика:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Число разработок приложений,
одобренных компанией {разработки}
Описание:
Спецификация:
Обоснование:
Одобренные разработки.
Разработки, одобренные компанией.
Обеспечивается
прозрачность
процесса
разработки и одобрение результатов со
стороны бизнеса.
Аудитория:
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Ограничения:
Разработки
должны
формально
документироваться.
Метрика
зависит
от
Опасное значение:
деятельности
компании.
Целевое значение:
10
Возможные
2
значения:
999999
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения,
Опасное значение:
Целевое значение:
Возможные
значения:
Число успешных сборок приложений
{сборки}
Число сборок, представленных для DSL,
включая
как
промежуточные,
так
и
продуктивные.
Сборки, скомпонованные и протестированные
разработчиками.
Показатель
внутрифирменной
производительности.
Проверенные
и
одобренные внутренние сборки могут выходить
на уровень альфа- или бета-тестирования или
даже продуктивной эксплуатации.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Зависит от деятельности компании.
6
2
999999
Метрика:
Число дней, потраченных на
развертывание приложения {дни}
Описание:
Время отсчитывается согласно числу дней,
заранее
отведенных
на
поставку
протестированного кода в DSL.
Действует для всех приложений/версий.
Спецификаци
я:
Е. Метрики для управления релизами
Обоснование
: Аудитория:
167
Метрика показывает, насколько успешно
соблюдается календарный план при
разработке приложений.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Нет
10
5
Ограничения:
Опасное
значение:
Целевое
значение:
Возможные значения: 999999
__________________________________________________
F
Метрики для управления
операциями/
инфраструктурой ИКТ
Цели управления инфраструктурой ИКТ.
Разработка и планирование:
— удовлетворять существующие потребности бизнеса в ИКТ;
— внедрять более эффективные решения в области ИКТ и
бизнеса;
— обладать простотой развития и расширения, чтобы
удовлетворить бу
дущим потребностям организации в определенных временных
рамках
и при заданных издержках;
— развивать гибкость навыков в ИКТ путем продвижения
стратегии в
повседневные операционные задания;
- эффективно и продуктивно использовать все ресурсы ИКТ и
обеспечи
вать безопасность ИКТ-сред;
- содействовать улучшению качества ИКТ-услуг в рамках
налагаемых
затратных ограничений;
- сокращать, минимизировать или ограничивать долгосрочные
из
держки.
Внедрение:
— удовлетворять существующие потребности бизнеса;
- создавать приемлемую и стабильную среду ИКТ, которая может
разви
ваться, расширяться и приспосабливаться к будущим
потребностям
бизнеса;
— содействовать общему улучшению качества ИКТ-услуг.
Операции:
- эксплуатировать, управлять и поддерживать весь комплекс
инфраструк
туры ИКТ, упрощающей предоставление ИКТ-услуг бизнесу и
удовлет
воряющей всем согласованным требованиям и целям;
170
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
— обеспечивать надежность, стабильность, безопасность и
непротиворе
чивость инфраструктуры ИКТ, а также ее содействие
продуктивности и
эффективности бизнес-процессов организации.
Техническая поддержка:
— главная цель технической поддержки — обеспечить бизнесу
высокодо
ступные и рентабельные ИКТ-услуги, поддерживающие
выполнение им
своих задач. Для достижения этой цели служба технической
поддержки
предоставляет необходимые ресурсы, опыт и квалификацию
другим
процессам для поддержки их работоспособности.
Следовательно, она
должна стать центром технического совершенствования и
содействовать
службам эксплуатации и внедрения в цикле предоставления
услуг.
(Библиотека ITIL, том «Управление ИКТ-инфраструктурой»)
Миссия: управлять предоставлением высококачественных ИКТуслуг в соответствии с требованиями бизнеса в областях
разработки и планирования, внедрения, эксплуатации и
технической поддержки.
Владелец процесса: менеджер инфраструктуры ИКТ.
Задача метрики: управлять и предоставлять
высококачественные
ИКТ-услуги, соответствующие требованиям бизнеса в областях
разработки и планирования, внедрения, эксплуатации и
технической поддержки.
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Число планов, одобренных компанией
{планы}
Согласованные планы.
Разработка и планирование. Стратегический
план содержит подпланы, которые внедряются
в период действия стратегии. Каждый из этих
планов должен быть детально проработан и
подписан владельцами бизнеса, исходя из
стратегических критериев.
Необходимо правильно управлять планами и
подтверждать
их.
Это
критерий
продуктивности процесса.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 5 2
999999
F. Метрики для управления операциями/инфраструктурой ИКТ
171
Метрика:
Число планов, не готовых для
одобрения {планы}
Описание:
Спецификация:
Планы «на подходе».
Разработка
и
планирование.
Метрика
соответствует числу планов в стратегическом
документе, которые должны быть закончены в
текущем месяце, но еще не готовы для
одобрения.
Критерий будущей продуктивности. Высокое
значение может также свидетельствовать о
нехватке ресурсов.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Нет
5
2
99999
9
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Отставание от плана внедрения {время}
Отсроченные планы. Отставание реальных
сроков
внедрения
от
запланированных.
Измеряется по перспективному графику
изменений.
Внедрение. План внедрения должен содержать
контрольные точки, показатель представляет
собой продолжительность задержки в днях
относительно этих точек.
Показатель эффективности. Высокое значение,
вероятно,
свидетельствует
о
проблеме,
связанной с ресурсами или планированием
внедрения.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 7 2
999999
Метрика:
Число проблем, возникших при
внедрении {события/инциденты }
Описание:
Любые помехи, выявленные в процессе
внедрения.
172
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Внедрение. Под проблемами понимаются
события или инциденты, возникшие в
результате внедрения. Может перекрываться
с
метрикой
управления
изменениями
«Процент изменений, вызвавших инциденты».
Внедрение следует планировать так, чтобы
не мешать предоставлению услуг.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 5 2
999999
Число серьезных или критических событий
на один управляемый объект {события}
Показатель стабильности, измеряется с
помощью
инструментов
мониторинга
инфраструктуры.
Эксплуатация. Число серьезных или критических
событий на один управляемый объект.
Задача
эксплуатации
—
поддерживать
стабильность
инфраструктуры.
Метрика
оценивает эффективность выполнения данной
задачи.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец
процесса SIP.
Нет
0,03
0,01
99999
9
Число событий, угрожающих
информационной безопасности {события}
Измеряется
с
помощью
инструментов
мониторинга инфраструктуры.
Операции. Управление брандмауэрами и
программами уничтожения вирусов должно
сводить данный по-
F. Метрики для управления операциями/инфраструктурой ИКТ
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
173
казатель к минимуму. В норме он рассчитывается
ежедневно, потому что вирусы появляются с
такой же частотой и требуют немедленного
вмешательства.
Хотя брандмауэры и другие устройства
обеспечения
безопасности
относятся
к
управлению безопасностью и доступностью, их
повседневное функционирование — забота
службы эксплуатации. Показатель связан с
другой метрикой — «Число инцидентов, угрожающих информационной безопасности» — и
должен всегда быть ниже ее. Если обе метрики
имеют равное значение, это говорит о плохой
реакции службы управления инфраструктурой
на информационные угрозы.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
250
150
99999
9
Число сбоев при выполнении заданий /
скриптов / резервного копирования
{события}
Ошибки в скриптах, аппаратных средствах или
процессах эксплуатации.
Эксплуатация. Число сбоев при выполнении
заданий / скриптов / резервного копирования.
Все скрипты и задания являются частью DSL, в
случае сбоя необходимо исправлять их или
эксплуатационные
процедуры.
Важно
поддерживать число сбоев минимальным,
поскольку они могут негативно влиять на
сервисы.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 20 5
999999
174
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика:
Число инцидентов, вызванных изменениями,
которые возникли в результате выполнения
определенных действий {инциденты}
Описание:
Спецификация:
Серьезные операционные инциденты.
Число инцидентов, в качестве причины которых
при
их
закрытии
указаны
операции.
Перекрывается
с
метрикой управления
изменениями «Процент изменений, вызвавших
инциденты».
Изменения следует осуществлять в нерабочее
время, поэтому значение метрики должно быть
очень низким. Это необходимо контролировать,
для чего нужно измерять данный показатель.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP. Нет 10 5 999999
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Задача метрики: фективное обеспечение ИТ.
Э( Метрика:
Степень удовлетворенности клиентов
{удовлетворенность}
Описание:
Спецификация:
Степень удовлетворенности клиентов.
Степень
удовлетворенности
клиентов,
определяемая
согласно
диаграмме
взаимоотношений процесса.
Показатель эффективности обеспечения ИТ.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
<3
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
0-5
G
Метрики для управления
уровнем сервиса
Цель управления уровнем сервиса (Service Level Management — SLM)
— поддерживать и улучшать качество ИТ-услуг с помощью
непрерывного цикла согласования, мониторинга и подготовки
отчетности о достижениях служб, а также путем стимулирования
действий по улучшению качества обслуживания, в соответствии с
политикой бизнеса и обоснованием затрат. С помощью этих
методов можно улучшить взаимоотношения ИТ и клиентов.
(Библиотека ITIL, том «Предоставление услуг»)
Миссия: руководить процессом согласования, определения и
поддержания уровня ИТ-услуг для рентабельного предоставления
услуг, поддерживающих коммерческие цели организации.
Владелец процесса; менеджер уровня обслуживания.
Задача метрики: управление ИТ-услугами, предоставляющее
оговоренный уровень сервиса.
Метрика:
Число случаев нарушения SLA {инциденты}
Описание:
низком
Этот показатель следует поддерживать на
Спецификация:
согласоОбоснование:
обеспечен
уровне. Если он окажется высоким, это должна
быть исключительная ситуация, иначе следует
пересмотреть SLA.
Учитываются все инциденты, заявки, а также
ванные показатели, которые вышли за пределы
SLA.
Метрика показывает, сколько раз не был
оговоренный уровень сервиса. Важно, чтобы ИТпод-разделение было в состоянии представить
бизнесу
176
Аудитория:
Ограничения:
Опасное
значение:
Целевое
значение:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
объяснение случившегося и согласовать работы
для
исправления
положения.
Метрика
обращает внимание на данную проблему.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
25
10
Возможные значения: 999999
Метрика:
Число случаев, когда SLA находится под
угрозой нарушения {SLA}
Описание:
Метрика
показывает,
насколько
ИТподразделение подошло к нарушению SLA.
Включает все закодированные обращения,
связанные с тем, что в течение 30 минут или
скорее будет нарушено SLA. Показатель можно
уточнить, представив его как процент от
времени эскалации — например, SLA будет
нарушено по истечении 80% времени эскалации.
Хотя на бизнес влияют лишь реальные
нарушения
заключенных
SLA,
владелец
процесса
и
ИТ-подразделение
должны
заниматься всеми инцидентами, которые
серьезно угрожают пороговым значениям SLA.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP. Нет 25 10 999999
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Процент SLA, требующих изменения {% SLA}
Измеряются незапланированные изменения
SLA вне периода пересмотра. Такие изменения
предполагают серьезные расхождения между
ожиданиями бизнеса и ИТ-подразделения. То,
что наличие несоответствий признается и SLA
перезаключается, — положитель-
G. Метрики для управления уровнем сервиса
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
177
ное явление, но плохо, что возникает подобная
необходимость.
Если SLA плохо составлено, его невозможно
выполнить, поэтому требуется встретиться с
клиентом и изменить параметры SLA. Метрика
оценивает масштабы данной проблемы.
Предполагается, что там, где SLA составлены
грамотно, метрика имеет низкое (или нулевое)
значение. Тем не менее важно отслеживать
любые
SLA,
требующие
значительного
пересмотра. В хороших SLA учитывается, что
клиенты могут предъявлять дополнительные
неконтролируемые требования к оговоренным
услугам в связи с изменениями коммерческой
среды. ИТ-подразделение должно быть готово
принять такие изменения нагрузки по инициативе бизнеса и предусмотреть возможные
последствия в SLA.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 4 2
0-100
Число пересмотров SLA, произведенных
своевременно {пересмотры}
Пересмотры имеют большое значение и должны
содержать информацию, способную привести к
перезаключению SLA. Однако их нужно
вовремя проводить и заключать. SLA, подолгу
находящиеся
в
стадии
пересмотра,
представляют собой риск для бизнеса.
Для всех SLA должна быть предусмотрена дата
обновления.
Пересмотр
начинается
за
некоторое время до нее (например, за месяц), а
его завершение фиксируется данной метрикой.
Сокращение риска длительных пересмотров,
которые начинаются, но не завершаются.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
178
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Ограничения:
Нет
Опасное
значение:
90
Целевое
значение:
95
Возможные
значения:
999999
Метрика:
Число нарушений SLA по вине внешних подрядчиков, осуществляющих поддержку
{инциденты}
Описание:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Показатель помогает договариваться с внешними
подрядчиками
об
улучшении
условий
обслуживания. Кроме того, он предоставляет
компании данные, свидетельствующие об
эффективности
управления
внешними
договорами.
Если инцидент связан с нарушением SLA по
вине внешнего подрядчика, это обязательно
отражается в его итоговых данных, поэтому все
такие инциденты могут быть учтены в данной
метрике.
Если предоставление услуг по внешним
договорам не оценивается, нелЁзя быть
уверенным в их эффективности. Число
инцидентов,
создаваемых
внешними
продрядчиками, имеет значение, но скорее
для управления доступностью, чем для
управления уровнем обслуживания.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Нет 5 2
999999
Метрика:
Затраты на предоставление услуг {затраты}
Описание:
Вне зависимости от валюты целевое значение
принимается за 100, а его превышение на 2%
считается опасным.
Данная
метрика
со
временем
будет
измеряться довольно точно. Для получения
приближенной
оценки
поделите
сумму
издержек по предоставлению услуг на число
имеющихся в распоряжении подраз-
Спецификация:
Обоснование:
Аудитория:
Спецификаци
я:
G. Метрики для управления уровнем сервиса
179
деления человеко-часов — это даст стоимость
одного человеко-часа. Затем можно оценить
число часов, потраченных на предоставление
услуги, по времени на обработку звонков и
выполнение рабочих заданий, после чего
перевести их в затраты.
Обоснование:
Учет затрат является стандартной задачей
процесса управления услугами, в отличие от
выставления счетов. Здесь важна функция
контроля издержек, а управление уровнем
обслуживания — значимый источник такого
Аудитория:
контроля.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
Ограничения:
владелец процесса SIP.
Возможно, этот показатель не удастся
Опасное значение:
оценить до внедрения учета затрат.
Целевое значение:
102 100
Возможные
999999
значения:
Метрика:
Число услуг, не охватываемых SLA {услуги}
Описание:
Все услуги должны быть охвачены SLA — иначе
нельзя понять, насколько они критичны для
бизнеса. Однако со временем приходится
перезаключать SLA и вводить новые услуги,
поэтому значение метрики варьируется.
Введение управления SLA сокращает данный
показатель; конечная цель — охватить все
услуги.
Показатель охвата контроля для процесса SLA.
Если для большого количества услуг не
существует согласованных и одобренных SLA,
значит,
процесс
управления
уровнем
обслуживания не выполняет свою функцию.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
15 10
99999
9
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения
178
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Ограничения:
Нет
Опасное
значение:
90
Целевое
значение:
Возможные
95
значения:
999999
Метрика:
Число нарушений SLA по вине внешних подрядчиков, осуществляющих поддержку
{инциденты}
Описание:
Показатель помогает договариваться с внешними
подрядчиками
об
улучшении
условий
обслуживания. Кроме того, он предоставляет
компании данные, свидетельствующие об
эффективности
управления
внешними
договорами.
Спецификация:
Целевое значение:
Возможные
Если инцидент связан с нарушением SLA по
вине внешнего подрядчика, это обязательно
отражается в его итоговых данных, поэтому все
такие инциденты могут быть учтены в данной
метрике.
Если предоставление услуг по внешним
договорам не оценивается, нел£зя быть
уверенным в их эффективности. Число
инцидентов,
создаваемых
внешними
продрядчиками, имеет значение, но скорее
для управления доступностью, чем для
управления уровнем обслуживания.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Нет 5 2
значения:
999999
Метрика:
Затраты на предоставление услуг {затраты}
Описание:
Вне зависимости от валюты целевое значение
принимается за 100, а его превышение на 2%
считается опасным.
Спецификаци
я:
Данная
метрика
со
временем
будет
измеряться довольно точно. Для получения
приближенной
оценки
поделите
сумму
издержек по предоставлению услуг на число
имеющихся в распоряжении подраз-
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
G. Метрики для управления уровнем сервиса
179
деления человеко-часов — это даст стоимость
одного человеко-часа. Затем можно оценить
число часов, потраченных на предоставление
услуги, по времени на обработку звонков и
выполнение рабочих заданий, после чего
перевести их в затраты.
Обоснование:
Учет затрат является стандартной задачей
процесса управления услугами, в отличие от
выставления счетов. Здесь важна функция
контроля издержек, а управление уровнем
обслуживания — значимый источник такого
Аудитория:
контроля.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
Ограничения:
владелец процесса SIP.
Возможно, этот показатель не удастся
Опасное значение:
оценить до внедрения учета затрат.
Целевое значение:
102 100
Возможные
999999
значения:
Метрика:
Число услуг, не охватываемых SLA {услуги}
Описание:
Все услуги должны быть охвачены SLA — иначе
нельзя понять, насколько они критичны для
бизнеса. Однако со временем приходится
перезаключать SLA и вводить новые услуги,
поэтому значение метрики варьируется.
Введение управления SLA сокращает данный
показатель; конечная цель — охватить все
услуги.
Показатель охвата контроля для процесса SLA.
Если для большого количества услуг не
существует согласованных и одобренных SLA,
значит,
процесс
управления
уровнем
обслуживания не выполняет свою функцию.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 15
10
999999
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
180
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика:
Число еще не согласованных операционных
соглашений об уровне услуг (OLA) и внешних
договоров (UC) {OLA/UC }
Описание:
По мере распространения управления уровнем
услуг будут заключаться новые операционные
соглашения об уровне услуг (OLA) и внешние
договоры (UC), так что их число будет
возрастать. Данная метрика фактически
показывает продуктивность этого процесса.
OLA и UC, которые еще не заключены и не
одобрены.
Отсутствие этого показателя влечет две
опасности: во-первых, что OLA и UC будут
обсуждаться, но к окончательному соглашению
по сложным вопросам прийти так и не удастся,
во-вторых, что SLA будет заключено без
необходимой
поддержки
со
стороны
соответствующих соглашений OLA и UC.
Владелец процесса, руководство ИХ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Нет 40
25
999999
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Степень удовлетворенности клиентов
{удовлет-
Удовлетворение клиента с точки зрения
процесса, наиболее тесно связанного с
данным.
Метрика удовлетворенности клиента как она
описана в диаграмме взаимоотношений
процесса.
Это субъективная, но вполне аутентичная
оценка качества результатов процесса.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
<3
4 05
G. Метрики для управления уровнем сервиса
181
Метрика:
Время между выработкой требований по
уровню обслуживания (SLR) и соглашением
SLA (дни)
Описание:
Время от создания SLR до окончательного
принятия
SLA.
Количество дней, необходимых для перехода от
первого варианта SLR к подписанному SLA.
На
продолжительность
этого
периода,
безусловно, влияет скорость реагирования
бизнес-подразделения, а также эффективность
процесса SLA. Со временем способность к
взаимодействию, переговорам и
заключению SLA должна улучшаться, и данная
метрика оценивает эту тенденцию.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
60
Спецификация;
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
дней
30
дней
99999
9
н
_________________________________________________
Метрики для управления
проблемами
Цель управления проблемами — минимизировать негативное
воздействие на бизнес со стороны инцидентов, вызываемых
ошибками в ИТ-инфра-сгруктуре, и предотвратить повторение
таких инцидентов. С этой целью в рамках процесса управления
проблемами предпринимают усилия по выявлению исходной
причины инцидентов и затем принятию мер для улучшения или
исправления ситуации.
(Библиотека ITIL, том «Поддержка услуг»)
Миссия: минимизировать нарушения в предоставлении ИТ-услуг,
обеспечив необходимые ИТ-ресурсы для решения проблем в
соответствии с требованиями бизнеса; предотвращать повторные
нарушения
и
фиксировать
информацию,
позволяющую
усовершенствовать процесс решения проблем, что повысит
доступность и продуктивность.
Владелец процесса: менеджер по управлению проблемами.
Задача метрики: определить проблемы, связанные с
(потенциальными)
нарушениями
обслуживания,
и
минимизировать их воздействие либо полностью устранить их
как причину сбоев.
Метрика:
Число решенных проблем {проблемы}
Описание:
Спецификация:
Обоснование:
време-
Мера активности, а также эффективности.
Число записей о закрытых проблемах.
Решение проблемы может потребовать много
ни, но если их разрешаемость высока, это
говорит об эффективности процесса.
184
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Ограничения:
Опасное
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
10
значение:
20
Аудитория:
Целевое
значение:
Возможные значения: 999999
Метрика:
Число инцидентов, разрешенных при
помощи базы данных, где описано решение
аналогичных задач {инциденты}
Устранение инцидентов с помощью решений,
зарегистрированных в соответствующей базе
данных, экономит время и трудозатраты,
сохраняя высокий уровень обслуживания
клиентов.
Спецификация:
Число устраненных таким путем инцидентов
должно увеличиваться.
Обоснование:
База данных с описанием разрешения проблем
является главным каналом взаимодействия
между процессами управления проблемами и
инцидентами. Если ее правильно обслуживать
и вести так, чтобы ею было легко пользоваться,
это отразится на значении данной метрики.
Аудитория:
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения:
Должна иметься база данных с описанием
разрешения проблем, и все инциденты,
устраненные с помощью содержащегося там
решения или обходного приема, должны
регистрироваться как таковые. Следует ли
задать уровень опасного значение выше или
ниже целевого, зависит от конкретных условий.
Следовательно, имеет смысл измерять число
инцидентов, которые были решены путем
использования информации из базы данных по
Опасное значение: отношению к общему числу решенных
Целевое значение: инцидентов.
Возможные
20 50
значения:
99999
Описание:
9
185
Н. Метрики для управления проблемами
Метрика:
Общее число инцидентов {инциденты}
Описание:
Инциденты могут быть вызваны проблемами —
если
устранить
проблемы,
количество
инцидентов уменьшится.
Данная метрика и степень удовлетворенности
клиентов — два главных показателя качества
работы для процесса управления проблемами.
Уменьшение этого показателя — первая задача
процесса управления проблемами.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Необходимо оговорить с клиентами, что
нарушения, произошедшие по их вине, не
регистрируются
как
инциденты.
Важно
понимать, что число инцидентов может
возрастать или уменьшаться по причинам, не
связанным с управлением проблемами
(например,
доверие
или
недоверие
пользователей к службе Service Desk), поэтому
на данный показатель нельзя полностью
полагаться — следует использовать его в
сочетании с другими метриками для выяснения
причин
изменений.
При
любых
значительных изменениях метрики группа
управления проблемами должна провести
исследование их причин.
Спецификация:
Обосновани
е:
Аудитория:
Ограничения:
Опасное значение: 400 200
Целевое значение: 999999
Возможные
значения:
Метрика:
Описание:
Спецификаци
я:
Л,-
Г
f
Общее время неработоспособности
пользователей {время}
Хотя это фактически показатель доступности, он
позволяет оценить и эффективность процесса
управления проблемами: если проблемы
решаются быстро и эффективно, уровень
простоев у пользователей снижается.
Показатель может измеряться как суммарное
время (в часах) на устранение инцидентов для
всех затронутых пользователей в часы,
оговоренные в SLA.
186
Обоснование:
и по-
Аудитория:
проОграничения:
нарушения,
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика непосредственно связана с клиентами
казывает
степень
негативного
влияния
нерешенных проблем на бизнес.
Владелец процесса, руководство ИТ, владелец
цесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Необходимо оговорить с клиентами, что
произошедшие по их вине, не регистрируются
как инциденты.
Опасное значение:
200
Целевое значение:
100
Возможные значения: 999999
Метрика:
управ-
Число RFC, инициированных процессом
ления проблемами {RFC}
Описание:
про-
Спецификация:
Обоснование:
управле-
Аудитория:
про-
RFC, инициированные процессом управления
блемами и связанные с теми или иными
проблемами.
Количество поданных RFC.
Каждый RFC, инициированный процессом
ния проблемами в ответ на некоторую
проблему, нацелен на реализацию решения.
Таким
образом,
данная
метрика
—
непосредственный
показатель
результатов
процесса.
Владелец процесса, руководство ИТ, владелец
цесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения;
Нет
Опасное значение: 10
Целевое значение: 20
Возможные значения:
999999
Метрика:
{проблемы}
Среднее число открытых проблем
Описание:
нагруз-
Число открытых проблем отражает текущую
ку процесса управления проблемами. Важно
отслеживать этот показатель в сравнении с
числом решенных проблем. Если он слишком
высок, эффективность предоставления услуг
на должном уровне бизнесу находится под
угрозой.
Н. Метрики для управления проблемами
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
187
Среднее число открытых проблем.
Некоторые
проблемы
могут
оставаться
открытыми в течение длительного времени, и
тем не менее метрика отражает эффективность
управления рабочей нагрузкой.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
40
25
999999
Метрика:
Среднее время закрытия проблемы {время}
Описание:
Решение некоторых проблем отнимает много
времени. Возможно, придется неделями вести
мониторинг, прежде чем удастся собрать
достаточно данных и установить причину
инцидентов.
Если
проблемы
остаются
открытыми в течение продолжительного периода
времени,
это
свидетельствует
о
неэффективности процесса.
Время от открытия до закрытия проблемы (в
часах, днях или минутах) для проблем,
закрытых в течение данного отчетного периода.
Если со временем среднее время решения
проблемы снижается, это говорит об улучшении
используемого
инструментария
и
функционирования процессов. Рост показателя
служит заблаговременным предупреждением о
том, что управлению проблемами не хватает
ресурсов.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Когда проблема, остающаяся открытой в
течение долгого времени, устраняется,
метрика делает резкий скачок, что усложняет
оценку тенденции. Поэтому имеет смысл
исключить из рассмотрения проблемы,
которые не удавалось решить дольше
месяца.
Спецификаци
я:
Обоснование:
Аудитория:
Ограничения:
188
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Опасное
значение:
5
Целевое
значение:
3
Возможные
значения:
999999
Метрика:
Описание:
Процент инцидентов, которые не
удалось связать с проблемой {%
инцидентов}
Инциденты, которые еще не были исследованы
в рамках процесса управления проблемами.
Спецификация:
Процент инцидентов, которые не привязаны к
записи о проблеме. Можно измерять его раз в
день и усреднять раз в неделю, можно получать
среднее значение каждый час.
Обоснование:
Все инциденты (хотя и не все звонки в службу
Service Desk) вызываются проблемами. Когда
причинно-следственная связь установлена,
окончательное
разрешение
ситуации
оказывается в руках группы управления
проблемами. Очень высокий процент инцидентов, не привязанных ни к какой
проблеме, указывает на неэффективность
процесса управления проблемами и может
Аудитория:
свидетельствовать
также
о
недостатке
ресурсов.
Владелец процесса, руководство ИТ, владелец
Ограничения:
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Энергия, затрачиваемая на выявление коренных
причин инцидентов, не может быть
Опасное значение: безграничной. В исследовании (на основе
бизнес-кейсов) нуждаются только те
Целевое значение:
инциденты (группы инцидентов), которые
Возможные
причиняют серьезный ущерб организации. 40 25
значения:
0-100
Метрика:
Число проблем, не решенных в течение
заданного времени {проблемы}
Описани
е:
Для проблем, точно так же, как для инцидентов,
задается фиксированное время разрешения;
оно определяется на основе SLA и степени
срочности
соответствующих
инцидентов.
Метрика оценивает, на-
Н. Метрики для управления проблемами
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
189
сколько
эффективно
процесс
управления
проблемами укладывается в отведенные сроки.
Число
проблем,
которые
остались
нерешенными к намеченному дню и были
эскалированы.
Показатель дает представление о том, сколько
серьезных проблем имеется у организации. Если
в
процессе
предусмотрены
этапы
«расследования» или «решения», можно
рассматривать время, затрачиваемое на них,
как целевое, чтобы, отделив долгосрочные, следить
за
своевременным
устранением
стандартных
проблем.
Это
позволяет
использовать эскалацию разрешения проблемы
для определения того, следует ли тратить
больше времени на особо сложную проблему
(возможно, со слабой степенью влияния), чем на
другую, менее интересную, но со средним
влиянием. Вопрос в том, чтобы правильно
соотнести ресурсы со срочностью, серьезностью
и продолжительностью разрешения проблемы —
срочность и серьезность могут возрастать
вместе с продолжительностью, и на особо
трудные проблемы, возможно, понадобится
направлять больше ресурсов. Чтобы все это
исследовать, нужно задать некоторые цели и
точки эскалации.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP. Нет 5 2 999999
Метрика:
Степень удовлетворенности клиентов
{удовлетворенность}
Описание:
Степень
удовлетворенности
клиентов,
определенная по данным процесса (процессов),
наиболее тесно связанного (связанных) с
управлением проблемами.
Метрика степени удовлетворенности клиентов,
как
она
описана
в
диаграмме
взаимоотношений процесса.
Это субъективная, но вполне аутентичная
оценка качества результатов процесса.
Спецификаци
я:
Обоснование:
190
Аудитория:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Владелец процесса, руководство ИХ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
<3
4
Ограничения:
Опасное
значение:
Целевое
значение:
Возможные значения: 0-5
Задача метрики: содействовать выявлению тенденций в рамках
процесса управления проблемами.
Метрика:
Пять категорий инцидентов, по которым
было больше всего обращений за отчетный
период {инциденты}
Секторная диаграмма, показывающая пять
наиболее частых (в процентах) категорий
звонков, полученных за отчетный период. Если
составлять ее для каждого отчетного периода,
можно отслеживать тенденции и выявлять
проблемные области для дальнейшего анализа.
Число записей об инцидентах в каждой
Спецификация:
категории, поделенное на их общее число за
период и умноженное на 100. Пять категорий,
для которых это значение максимально,
отображаются на секторной диаграмме.
Управление инцидентами эффективно для
Обоснование:
выявления тенденций, относящихся к частоте
инцидентов. Некоторые области (например,
электронная
почта,
приложения)
могут
показывать
стабильно
высокий
процент
инцидентов, что, в свою очередь, учитывается
в форме приоритетов и при проактивном управлении проблемами.
Аудитория:
Владелец процесса, члены команды, владелец
процесса SIP, группа управления проблемами.
Ограничени
Этот показатель не может включаться в
консолидированные метрики, он является
я:
информативной внутренней метрикой, а не
метрикой процесса.
Не
Опасное значение:
определено.
Целевое значение:
Не
Возможные
определено.
значения:
Не
определены.
Описание:
Н. Метрики для управления проблемами
191
Задача метрики: сокращать число регистрируемых инцидентов и
повышать эффективность поддержки.
Метрика:
Число инцидентов, разрешаемых путем
обучения пользователей {инциденты}
Описание:
К инцидентам приводят как ошибки в
инфраструктуре, так и недостаточные знания
пользователей о том, как работать с
приложениями. Поэтому можно предотвратить
значительную часть инцидентов, просто
обучая пользователей.
Число
заявок,
которые
относятся
к
определенной категории инцидентов и для
которых
в
качестве
решения
указана
необходимость обучения пользователей.
Эффективное управление инцидентами и
проблемами предполагает выявление того,
каким образом можно сократить число
инцидентов,
обеспечив
обучение
пользователей; иначе требования к персоналу
службы поддержки несоразмерно возрастут.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
В описаниях решений должна фиксироваться
необходимость обучения.
>25 в определенной категории, вероятно,
означает необходимость сессии обучения.
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное
значение:
Целевое
значение:
О
Возможные значения: 99999
Задача метрики: выявлять значительные затраты на
качество для равления проблемами.
Метрика:
Описание:
Спецификаци
я:
Затраты на решение проблемы {затраты}
Сколько всего стоило решение данной проблемы.
Оцениваются часы работы персонала, материальные
издержки и другие статьи расходов, связанные с решением проблемы.
Управление проблемами — это процесс, связанный с
Обоснование: управлением качеством предоставления услуг. У качества есть цена. Для всех существующих
проблем нужно составлять бизнес-кейс, чтобы
определить, це-
192
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
лесообразно ли их устранение. Часто решение
опирается на оценки, точность которых можно
повысить с помощью проверенных на практике
измерений стоимости решения аналогичных
проблем. Обратите внимание, что решение о
том, стоит ли заниматься проблемой и тратить
на это деньги, принимается в рамках процесса
управления изменениями и относится к его
сфере ответственности.
Аудитория:
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения:
Менеджеры по управлению проблемами
должны в точности документировать все, чем
они занимаются, чтобы впоследствии можно
было проследить, к какой проблеме относится
Опасное
каждое действие.
значение:
Зависит от проблемы: затраты на решение
проблемы ни в коем случае не должны
Целевое
превышать выгод.
значение:
Сделать решение проблемы прибыльным.
Возможные значения: Теоретически не ограничены.
I
Метрики
управления финансами
для ИТ-услуг
Цель управления финансами для ИТ-услуг — обеспечение
рентабельного
распоряжения активами и ресурсами ИТ, используемыми в
предоставлении
ИТ-услуг.
(Библиотека ITIL, том «Поддержка услуг»)
Миссия: управлять затратами на ИТ-инфраструктуру и
обеспечивать стабильную основу для деловых решений,
касающихся ИТ, путем определения и учета затрат на
предоставление услуг, а также обоснованного возмещения издержек,
где это возможно.
Владелец процесса: руководитель ИТ.
Шдача метрики: управлять затратами на ИТ-инфраструктуру и
обеспе-швать стабильную основу для деловых решений,
касающихся ИТ, путем определения и учета затрат на
предоставление
услуг,
а
также
обоснован-юго
возмещения издержек, где это возможно.
Метрика:
Процент учитываемых расходов на ИТ
{% расходов}
Описани
Область, на которую распространяется текущий учет затрат.
CMDB предоставляет информацию об издержках
е:
из базы активов — эти данные можно сравнить
с записями бухгалтерии. Со временем точность
CMDB повышается.
Спецификация: В конечном итоге будут рассматриваться все издержки
на ИТ, как прямые, так и косвенные. К тому време-
194
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание
:
Спецификаци
я:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
ни станут известны операционные издержки,
такие как зарплата, расходы на телефонную
связь, электричество. Можно рассчитывать
показатель, пользуясь помощью бухгалтерского
отдела.
Чем шире охват, тем лучше.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 50
70 0100
Число изменений, сделанных в
алгоритме начисления платы
{изменения}
Насколько мы близки к стабильной системе.
Число изменений, внесенных в алгоритм. Даже
если
счета
в
действительности
не
выставляются,
полезно
иметь
алгоритм
калькуляции стоимости и регулярно проверять
его обоснованность.
В конечном итоге нам нужен алгоритм,
работающий стабильно благодаря правильной
модели. Но до этого момента хорошим
признаком
будет
активное
управление
процессом.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 10 3
999999
Задержки в создании финансового отчета
{дни}
Сколько времени занимает подготовка отчета.
Регулярный финансовый отчет должен быть
готов к определенной дате. Метрика показывает
запаздывание относительно этого срока.
I. Метрики управления финансами для ИТ-услуг
Обоснование
: Аудитория:
Ограничения:
Опасное
значение:
Целевое
Метрика:
значение:
Когда процесс достигнет зрелости, отчеты будут
подготавливаться вовремя. До тех пор пользуйтесь
данной метрикой для оценки прогресса.
Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец
процесса SIP.
Нет
21
Возможные значения: 999999
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
195
Задержки в создании ежемесячного прогноза
{дни}
Задержка, измеряемая в днях.
Прогноз очередных финансовых показателей
составляется ежемесячно.
По достижении зрелости процесса прогноз будет
выдаваться вовремя. До тех пор пользуйтесь
данной метрикой для оценки задержек в
формировании прогноза.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 2 1
999999
Степень достоверности (в процентах)
последнего финансового прогноза {% затрат}
Точность прогноза в процентах.
Измеряется следующим образом: Модуль
(Фактические
финансовые
данные
Финансовый
прогноз)
/
Фактические
финансовые данные х 100 за прошедший
период.
Оценивает качество управления финансами.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
196
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Ограничения:
Нет
Опасное значение: 80
Целевое значение: 85
Возможные значения:
0-100
Метрика:
Степень достоверности (в процентах)
финансо вого прогноза на предыдущий
квартал {% затрат}
Описание:
Скользящий
показатель
—
отношение
сделанного ранее прогноза к фактическим
данным.
Вычисляется по формуле: Модуль (Фактические
финансовые данные - Финансовый прогноз) /
Фактические финансовые данные х 100 за
прошедший период (квартал).
Ответственность за сметные предположения и
прогнозы в значительной степени лежит на
процессе управления мощностями, однако их
правильность
зависит
от
финансовой
информации. Поэтому имеет смысл возложить
ответственность за данную метрику на
управление финансами. Одновременно такая
мера побуждает группы, ответственные за
управление финансами и мощностями, к
тесному
сотрудничеству
для
улучшения
показателя.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 60
75 0100
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Совокупная стоимость владения
(Total Cost of Ownership — TCO) ИТ
{стоимость]
Рассчитывается
на
основе
моделей
управления финансами и CMDB.
Метрика показывает, в какую сумму обходится
компании
владение
информационными
технологиями. ТСО включает все финансовые
расходы, в том числе заработную плату, затраты
на амортизацию, оборудо-
I. Метрики управлен/я финансами для ИТ-услуг
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
197
вание и инфраструктуру. Задача заключается в
постепенном снижении показателя.
Цель управления финансами — снизить данный
показатель.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 50
10
999999
Число жалоб, касающихся затрат на
ИТ {жалобы}
Источником большей их части будут жалобы,
поступающие в службу Service Desk и
обсуждающиеся на регулярных собраниях по
SLA.
Жалобы, выдвинутые в этом качестве службой
Service Desk или вынесенные на обсуждение на
собрании по SLA, должны регистрироваться и
отслеживаться.
Либо группа управления финансами не
сообщила,
чем вызваны
определенные
затраты,
либо
причина
признана
неубедительной. В любом случае это означает,
что принципы управления финансами требуют
пересмотра.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 10 5
999999
Метрика:
Число вопросов, касающихся затрат на
ИТ {запросы)
Описани
е:
Источником большей их части будут вопросы,
поступающие в службу Service Desk и
поднимаемые на регулярных собраниях по SLA.
198
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Вопросы, поднятые в качестве жалоб службой
Service Desk или вынесенные на обсуждение
на
собраниях
по
SLA,
должны
регистрироваться и отслеживаться.
Либо группа управления финансами не
сообщила,
чем вызваны
определенные
затраты,
либо
причина
признана
неубедительной. В любом случае это означает,
что принципы управления финансами требуют
пересмотра.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 40
30
999999
Задача метрики: обеспечить эффективность Управления
финансами в Организации ИТ-обслуживания.
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения
Степень удовлетворенности
клиентов {удовлетворенность}
Удовлетворенность
клиентов
процесса
управлением финансами, измеряемая по
реакции клиентов на результаты деятельности
процесса.
Удовлетворенность клиента в соответствии с
диаграммой взаимоотношений процесса.
Показатель эффективности управления
финансами.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
<3
4 05
J
Метрики для управления
мощностями
Цель процесса управления мощностями — обеспечить, чтобы
мощность ИТ всегда была обоснованной с точки зрения затрат и
соответствовала как текущим, так и известным будущим
потребностям бизнеса. (Библиотека ITIL, том «Поддержка услуг»)
Миссия; обеспечить наилучшее использование инфраструктуры
ИТ, оптимально отвечающей потребностям бизнеса сейчас и в
будущем, за счет должного понимания требований как бизнеса,
так и инфраструктуры.
Владелец процесса: менеджер по мощностям.
Метрика:
Задача метрики; обеспечить эффективное управление
мощностями.
Число нарушений SLA из-за недостаточно быстрого
Описани обслуживания {нарушения SLA}
В задачи управления мощностями входит контроль того,
чтобы оговоренные в SLA показатели быстрое:
действия
не
были
превышены
из-за
недостаточной мощности. По возможности
следует учитывать здесь только инциденты,
относящиеся к мощности, но это зависит от зрелости
процессов управления инцидентами и проблемами.
Спецификаци Например, превышение времени ответа на звонок
или времени отклика приложения.
я:
На основе управления мощностями прогнозируются
потенциальные сбои в обслуживании из-за
проблем
Обоснование:
200
Аудитория:
Ограничения:
Опасное
значение:
Целевое
значение:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
с мощностью — данная метрика оценивает
эффективность этой деятельности.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
По возможности нужно учитывать только
инциденты, связанные с мощностями.
2О
Возможные значения: 999999
Задача метрики: обеспечить эффективное управление
мощностями ресурсов.
Метрика:
Описание:
Число нарушений SLA из-за недостаточной
производительности
компонента
{нарушения SLA}
Сбои
компонентов
из-за
недостаточной
производительности
и
т.п.
проблем,
связанных
Спецификация:
с нагрузкой.
Обоснование:
Например, плохое быстродействие системы.
В функции управления мощностями ресурсов
входит минимизация числа сбоев по причине
Аудитория:
недостаточной мощности.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
Ограничения:
владелец процесса SIP.
Опасное значение: По возможности следует учитывать только
инциденты, связанные с мощностями.
Целевое значение:
2
О
Возможные
99999
значения:
9
Задача метрики: обеспечивать нагрузку, достаточную для
предоставления
оговоренных
услуг
в
соответствии
с
оговоренными уровнями обслуживания.
Метрика:
Описани
е:
Число инцидентов, вызванных
недостаточной производительностью
{инциденты}
В рассмотрение включаются только
инциденты, относящиеся к производительности.
Мониторинг и на-
J. Метрики для управления мощностями
Спецификация:
Обосновани
е:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
201
стройка в сочетании с анализом тенденций
должны предотвращать их возникновение.
Необходимо,
чтобы
в
управлении
инцидентами
и
проблемами
производительность могла указываться в
качестве причины при закрытии инцидентов.
Также нужны процедуры, позволяющие
решить, действительно ли причина в этом.
Метрика оценивается на основе данных о
закрытии инцидентов.
Прямой показатель эффективности управления
мощностями.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет 10 5
999999
Задача метрики: разработать рентабельный план развития
мощностей.
Метрика:
Описание:
Спецификаци
я:
Обоснование:
Аудитория:
Стоимость разработки плана развития
мощносСуммарные
расходы
на
планирование.
Оцениваются отдельно от стандартных текущих
издержек, поэтому для определения процедур
регулярного мониторинга этих расходов
потребуется проделать определенную работ)"
совместно с группой управления финансами.
Трудозатраты в период планирования, а также
стоимость инструментария и т.д.
Для учета будущих тенденций и потребностей
бизнеса управление мощностями должно
предусматривать разработку планов развития
мощностей, причем необходимо, чтобы эта
разработка была рентабельной. Показатель
позволяет следить как за самим созданием
планов, так и за тем, чтобы не потреблялось
слишком много ресурсов.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
202
Ограничения:
Опасное
значение:
Целевое
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Для расчета данной метрики управление
финансами должно вестись на достаточно
высоком уровне.
30
10
значение:
Возможные значения: 999999
Задача метрики: планировать будущие требования бизнеса к
развитию
мощностей.
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Число незапланированных
приобретений аппаратных средств,
нужных для повышения
производительности {расходы}
Любое
приобретение,
необходимое
по
соображениям производительности, считается
незапланированным, если оно не было
предусмотрено в плане развития мощностей.
Сюда
могут
входить
дополнительная
оперативная память, диски, процессоры,
различные системы и се-. тевые устройства,
приобретаемые
для
решения
проблем
производительности и не включенные в план
развития мощностей. Фиксируйте наименования
или стоимость приобретений.
В управлении мощностями приобретения
должны планироваться заранее на основе
выявленных тенденций и известных бизнеспланов,
еще
до
того
как
возникнут
соответствующие
потребности.
Метрика
проверяет, сокращаются ли незапланированные
приобретения
в
результате
улучшения
планирования.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Нет 15
10
999999
Задача метрики: предоставлять точные прогнозы будущих
потребностей в мощностях в соответствии с известными
сценариями бизнеса.
J. Метрики для управления мощностями
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
203
Степень достоверности (в процентах)
плана предстоящих расходов {%
расходов}
Насколько расходы на повышение мощности
выше, чем планировалось. Изменения в связи с
новыми требованиями бизнеса должны
отражаться в сценариях управления
мощностями, а планируемые расходы —
соответствующим образом корректироваться.
Модуль (Запланированные расходы на период Реальные
расходы
за
период)
/
Запланированные расходы х 100 в течение
заданного периода.
Управление
мощностями
разрабатывает
планы по развитию мощностей, в которых
прогнозируются будущие расходы согласно
бизнес-планам компании. Метрика оценивает
достоверность этих прогнозов.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Для
получения
достоверной
картины
управление финансами должно вестись на
достаточно высоком уровне.
80 90
0100
Задача метрики: предоставлять план развития
мощностей тивного уравновешивания потребностей
бизнеса и издержек.
Метрика:
Описание:
Спецификаци
я:
Процент избыточной производительности
ИТ
{% нагрузки}
Для измерения уровней производительности,
дисков, памяти, процессоров, пропускной
способности сети и т.д. можно организовать
мониторинг и проверку на соответствие
критериям, описанным в политике управления
мощностями. Все обнаруженные при этом
избыточные мощности фиксируются и суммируются для получения данной метрики. Следует
добиваться ее постепенного сокращения.
Значение показателя можно измерять путем
аудита производительности ключевых CI.
Оптимальный уровень определен в плане
управления мощностями.
204
Обоснование:
Аудитория:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
В задачи управления мощностями входит
обеспечение эффективной мощности — не
слишком высокой, потому что это дорого.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP. Нет 30 20 0-100
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
аоача метрики: следить за
инфраструктурой
в области мощностей.
и выявлять
тенденции
Метрика:
Процент CI, для которых ведется мониторинг
производительности {% CI}
Описание:
Всякий раз, когда проведение мониторинга по
той или иной причине прекращается для
определенного числа ключевых CI, нужно
учитывать данную метрику. Если мониторинг
производительности для главных серверов не
ведется,
то
управление
мощностями
фактически лишено информации о тенденциях.
Показатель числа CI, для которых работает
мониторинг производительности. Набор CI
может определяться более детально, чтобы
исключить те из них, которые не имеют прямого
отношения к мониторингу нагрузки.
Для управления мощностями необходимо иметь
представление о текущих уровнях мощностей и
соответствующих тенденциях. Получить такое
представление позволит только эффективный
мониторинг CI.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP. Нет 60 70 0-100
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Задача метрики: оценивать
ynpai ностей бизнеса.
дюстью на основе
потреб-
J. Метрики для управления мощностями
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
205
Соотношение (в процентах) между общей
и ожидаемой загрузкой ИТ-ресурсов {%
загрузки}
Ожидаемая
загрузка
ИТ-ресурсов
определяется
в
плане
управления
мощностями как и «загрузка ресурсов» для
данной метрики.
Отношение общей загрузки ИТ-ресурсов к
предполагаемой
в
плане
управления
мощностями.
Для управления мощностями необходимо иметь
представление о текущих уровнях мощностей и
соответствующих тенденциях. Эту информацию
необходимо связывать с планами загрузки ИТресурсов на основе потребностей бизнеса,
чтобы составлять достоверные прогнозы на
будущее и понимать причины нынешних
ошибок.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP. Нет
85 80
0100
Задача метрики: обеспечить эффективность процессов
управления услуМетрика:
Степень удовлетворенности клиентов
{удовлет воренность)
Описание:
Спецификация:
Удовлетворенность клиентов.
Степень удовлетворенности клиентов,
измеряемая согласно диаграмме
взаимоотношений процесса.
Удовлетворение клиента позволяет убедиться
в эффективности результатов процесса.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP. Нет <3 4 0-5
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
к
___________________________________________________________
Метрики
управления непрерывностью
предоставления ИТ-услуг
(IT Service Continuity —
ITSC)
Цель управления непрерывностью предоставления ИТ-услуг —
поддерживать общий процесс управления непрерывностью
бизнеса,
обеспечивая
восстановление
работоспособности
необходимого оборудования и служб ИТ (включая компьютерные
системы, сети, приложения, телекоммуникации, техническую
поддержку и службу Service Desk) в требуемые для бизнеса и
оговоренные с ним сроки.
(Библиотека ITIL, том «Поддержка услуг»)
Миссия;
поддерживать
общий
процесс
управления
непрерывностью
бизнеса,
обеспечивая
восстановление
работоспособности необходимого оборудования и служб ИТ в
требуемые для бизнеса и заранее оговоренные с ним сроки.
Владелец процесса: менеджер по управлению непрерывностью.
Задача метрики: поддерживать общий процесс управления
непрерывностью
бизнеса,
обеспечивая
восстановление
необходимого оборудования и служб ИТ в требуемые для
бизнеса и оговоренные с ним сроки.
Метрика:
Число услуг, не охватываемых планом ITSC
{услуги}
Описание:
связи с
Для вех услуг и SLA должны быть оговорены
Спецификация:
услуг.
ITSC, даже если при этом говорится, что
восстановление
данной
услуги
при
чрезвычайных
обстоятельствах
не
предусмотрено.
ITSC — это непрерывность предоставления ИТ-
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УШГАМИ
208
Обоснование:
Аудитория:
Если какая-то услуга не включена в план ITSC,
это риск. Метрика гарантирует контроль
ситуации для всех услуг.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP. Нет 10 5
Ограничения:
Опасное
значение:
Целевое
значение:
Возможные значения: 999999
Метрика:
Задержка с подготовкой/обновлением
плана ITSC{дни}
Показатель
коммерческого
риска.
Даты
выполнения и обновления плана должны быть
зафиксированы в соответствующих документах,
по которым и контролируются.
Число дней от той даты, к которой должен был
Спецификация:
быть подготовлен или обновлен план, до дня
его фактической сдачи.
Если план не завершен, есть риск, что и
Обоснование:
восстановления не произойдет. Метрика
позволяет проследить за тем, чтобы планы
формировались в срок.
Аудитория:
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
Ограничения:
процесса SIP,
Опасное значение:
Нет 5 1
Целевое значение:
999999
Возможные
значения:
Описание:
Метрика:
Описание:
Спецификаци
я:
Обоснование:
Задержка с тестированием плана ITSC {дни}
Измеряется по плану ITSC, который подлежит
формальному документированию.
Число дней между намеченной и реальной
датами тестирования.
Задержки могут быть обусловлены многими
причинами. Чаще всего случается, что
участники тестирования заняты на другом
участке работы. Подобные
К. Метрики управления непрерывностью предоставления ИТ-услуг (IT Service Continuity — ITSC)
Аудитория:
209
задержки повышают риск для бизнеса, и к ним
следует
привлекать
внимание,
чтобы
многократные
отсрочки
не
привели
к
серьезному отставанию в подготовке плана.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Нет
10
5
Ограничения:
Опасное
значение:
Целевое
значение:
Возможные значения: 999999
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описани
е:
Число проблем, выявленных при
последнем тестировании, которые еще
не решены на данный момент времени
{проблемы}
План, проблемы и действия подлежат
формальному документированию, и данный
показатель измеряется по соответствующим
документам.
При каждом тестировании плана ITSC будут
возникать определенные вопросы, которые
нужно решить для снижения риска. Метрика
представляет собой число таких вопросов,
остающихся на данный момент открытыми.
Пока остаются нерешенные вопросы, план
неработоспособен. Поэтому для снижения риска
нужно пристально следить за данной метрикой.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Нет 10 5
999999
Результаты опроса по осведомленности о
непрерывности предоставления ИТ-услуг,
проведенного выборочно, — процент
удовлетворительных ответов {%
прошедших}
Опрос можно проводить регулярно, опрашивая
каждый раз другую аудиторию, чтобы одни и те
же со-
210
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
трудники давалт ответы не чаще чем раз в
годполтора.
Весь ИТ-персонал должен быть в курсе влияния
ИТ-услуг на бизнес, потребностей и запросов
бизнес-подразделений. Опрос для проверки
уровня осведомленности можно проводить
регулярно (например, раз в месяц), привлекая
разных сотрудников. Набранные баллы
характеризуют уровень их осведомленности.
Исследование
оценивает
успешность
коммуникационного плана. Плохие результаты
означают необходимость изменить метод
информирования, способ представления или
передачи
информации,
а
возможно,
потребность в специальных учебных курсах или
лекциях для повышения осведомленности.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP. Нет 90 95 0-100
Метрика:
Число выявленных за данный период
проблем, которые ставят под угрозу план
ITSC {проблемы}
Описание:
Эти проблемы перечислены в соответствующих
документах с указанием сроков устранения и
планируемых мер.
План ITSC требует доступа к оборудованию,
системе резервного копирования, удаленным
площадкам и персоналу. Менеджер ITSC
должен
выявлять
все
проблемы,
наличествующие в текущем месяце и препятствующие этому доступу. К примеру, нехватка
персонала по причине болезни может угрожать
плану непрерывности.
Проблемы с планами непрерывности бизнеса
могут возникать по многим причинам, но их
всегда важно отслеживать и принимать
соответствующие
меры.
Насколько
эффективна эта деятельность, показывает
данная метрика.
Спецификаци
я:
Обоснование:
К. Метрики управления непрерывностью предоставления ИТ-услуг (IT Service Continuity — ITSC)
Аудитория:
Ограничения:
Опасное
значение:
Целевое
значение:
211
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP. Нет 10 2
Возможные значения: 999999
Метрика:
Описание:
Число писем, предназначенных для
конкретной группы сотрудников
{коммуникации}
Измеряется на основе документов, которые
должны содержать соответствующие письма.
Спецификация:
Для каждой области ИТ-услуг и бизнеса должна
быть известна ее роль в плане ITSC. Чтобы
обеспечить их готовность, можно составить
целевые письма для каждой области и
периодически
их
рассылать.
Метрика
Обоснование:
позволяет удостовериться, что это делается.
Если бизнес-подразделения не в курсе
собственных требований к непрерывности,
нельзя ожидать от них правильных действий в
экстремальной ситуации. Целевые письма
Аудитория:
позволяют
проинформировать
всех
сотрудников о существующих инструкциях.
Ограничения:
Владелец процесса, руководство ИТ, владелец
Опасное значение: процесса SLA, члены команды, владелец
Целевое значение: процесса SIP.
Возможные
Нет О 1
значения:
999999
Метрика:
Число неверных записей в справочнике
группы кризисного контроля {контакты}
Описание:
В идеале в случайный момент делается
случайная выборка записей о контактах, а их
правильность
проверяется
независимым
агентом, например, службой Service Desk.
Один раз за определенный период можно
проверять правильность всей контактной
информации и сообщать значение данной
метрики, а также обновлять каталог.
Спецификаци
я:
212
Обоснование;
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Если контактная информация не во всем верна,
это означает, что контроль изменений и
контроль конфигураций в управлении планом
ITSC
неэффективны.
Кроме
того,
есть
опасность, что в чрезвычайной ситуации не
получится связаться с нужными людьми и это
серьезно повлияет на возможность восстановления.
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Нет 1 О
999999
значения:
Метрика:
Запаздывание готовности резервных
мощностей {время}
Описание:
Показатель готовности — оценка рисков для
бизнеса.
Спецификация:
Можно связываться с резервной площадкой в
случайно выбранные в каждом периоде
моменты времени, проверяя таким образом,
сколько времени займет ее приведение в
рабочее состояние. Разность между этим и
ожидаемым сроками представляет собой значение данной метрики.
Обоснование:
Аудитория:
Если риск для бизнеса не измерять, то его
нельзя
и
уменьшить.
Данная
метрика
обеспечивает регулярную и частую проверку
того, что восстановлению не угрожают
проблемы,
связанные
с
резервной
площадкой.
Если
запаздывание
часто
оказывается
большим,
рекомендуется
подыскать другую площадку.
Опасное значение:
Владелец процесса, руководство ИТ, владелец
процесса SLA, члены команды, владелец
процесса SIP.
Целевое значение:
Нет 1 О
Возможные
999999
Ограничения:
значения:
К. Метрики управления непрерывностью предоставления ИТ-услуг (IT Service Continuity — ITSC)
213
Метрика:
Степень удовлетворенности клиентов
воренность}
Описание:
Оценивается не на основе конкретных аварий,
которые, как мы надеемся, не произойдут, а
исходя
из
удовлетворенности
бизнесподразделений планированием и процессом,
поддерживающим
планы
в
актуальном
состоянии.
Измеряется в соответствии с диаграммой
взаимоотношений процесса.
Непрерывность предоставления ИТ-услуг — это
процесс планирования, который красной нитью
проходит через все бизнес-операции и
подразделения организации. Важно, чтобы
пользователи,
затрагиваемые
данным
процессом, были удовлетворены его результативностью и тем, как он на них влияет.
Владелец процесса, руководство ИТ, владелец
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
<3
4 05
_____________________________________________________
L
Метрики
управления доступностью
Цель управления доступностью — оптимизировать потенциал
инфраструктуры ИХ, организации обслуживания и поддержки,
предоставлять рентабельный и устойчивый уровень доступности,
позволяющий реализовывать задачи компании.
(Лучшие практики ITIL сервисной поддержки OGC)
Формулировка
миссии:
обеспечить
предоставление
ИТобслуживания в нужное время в нужном месте для нуждающихся
пользователей с помощью планирования и построения надежной
и устойчивой инфраструктуры, управления взаимоотношениями
с ключевыми поставщиками и партнерами в соответствии с
требованиями сервиса.
Владелец процесса: управляющий доступностью.
Задача метрики: обеспечить предоставление ИТ'обслуживания в
нужное время в нужном месте для нуждающихся пользователей с
помощью планирования и построения надежной и устойчивой
инфраструктуры, управления взаимоотношениями с ключевыми
поставщиками и партнерами в соответствии с требованиями
сервиса.
Метрика:
Простой, недоступность обслуживания
{минуты}
Описание:
рабо-
Любое время, когда услуга недоступна в часы
Спецификация:
дей-
ты, обусловленные договором.
Время в минутах, в течение 'которого услуга не
ствует. Метрика показывает доступность
сервиса.
L. Метрики управления доступностью
Метрика:
217
Время обнаружения неполадки {минуты}
Время, в течение которого осуществляется
поиск неполадки.
Время
отсчитывается
с
момента
Спецификация:
возникновения неполадки до ее обнаружения.
Метрику можно представить в виде набора
значений в таблице или диаграмме, либо
рассчитать средний показатель.
Обоснование:
Чтобы своевременно устранять неполадки,
важно обнаруживать их как можно быстрее. Это
обеспечивается посредством пристального
мониторинга,
желательно
Аудитория:
автоматизированного.
Владелец процесса, руководство ИТ, владелец
Ограничения:
SLA, клиент бизнеса, члены команды,
Опасное значение: владелец SIP.
Целевое значение: Нет 4 1
Возможные
999999
значения:
Описание:
Метрика:
Время реагирования на
неполадку {минуты}
Описание:
Время с момента обнаружения неполадки до
самых первых попыток ее устранения.
Метрику можно представить в виде набора
значений в таблице или диаграмме, либо
рассчитать средний показатель.
Прежде чем предпринять какие-то действия по
устранению
неисправности,
необходимо
провести ее диагностику. Для быстрой
постановки диагноза требуется поддержка
квалифицированных служб помощи, баз знаний
и т.д.
Владелец процесса, руководство ИТ, владелец
SLA, клиент бизнеса, члены команды,
владелец SIP.
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Нет 10 5
999999
218
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика:
Время ремонта в случае неполадки {минуты}
Описание:
Целевое значение:
Время с момента постановки диагноза до
окончания ремонта.
Время, затрачиваемое на ремонт, после
диагностирования неполадки. Метрику можно
представить в виде набора значений в таблице
или диаграмме, либо рассчитать средний
показатель.
Чтобы устранить неполадку как можно
быстрее, важно уметь управлять фактическим
временем ремонта. На его продолжительность
влияет
подготовленность
к
возможным
происшествиям:
доступность
запасных
компонентов или наличие ремонтного
комплекта.
Владелец процесса, руководство ИТ, владелец
SLA, клиент бизнеса, члены команды,
владелец SIP.
Нет 20
Возможные
10
значения:
999999
Метрика:
Время восстановления в случае
неполадки {минуты}
Описание:
Время восстановления поврежденных
компонентов.
Время после ремонта, требуемое для
восстановления
нормального
функционирования компонентов.
После ремонта поврежденных компонентов их
нужно восстановить, прежде чем снова ввести
в
обслуживание.
Продолжительность
восстановления зависит от времени ввода
оборудования в эксплуатацию, условий,
которые необходимо создать, и т.д.
Владелец процесса, руководство ИТ, владелец
SLA, клиент бизнеса, члены команды,
владелец SIP.
Нет 5 2
999999
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
L. Метрики управления доступностью
Метрика:
219
Время возобновления обслуживания в случае
неполадок (минуты)
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Время возобновления обслуживания на том
уровне, который был оговорен в соглашении.
Время,
требуемое
для
возобновления
согласованного
уровня
сервиса
после
восстановления компонента.
После
восстановления
поврежденных
компонентов
нужно
вновь
обеспечить
доступность сервиса для пользователей.
Скорость
возобновления
обслуживания
зависит от условий, которые приходится воссоздавать,
и
данных,
которые
нужно
восстановить, и т. д.
Владелец процесса, руководство ИТ, владелец
SLA, клиент бизнеса, члены команды,
владелец SIP.
Нет
5
2
999999
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
П
Г
1
Время устранения неполадки {минуты}
Время с момента обнаружения неполадки до
возобновления сервиса.
Складывается из четырех составляющих:
времени
реагирования на неполадку, времени ремонта,
времени
восстановления
и
времени
возобновления сервиса.
Если
детальное
управление
реагированием/ремонтом/восстановлением/возобновлением
недоступно, можно использовать сумму этих
элементов для регулирования времени с
момента
обнаружения
проблемы
до
возобновления сервиса.
Владелец процесса, руководство ИТ, владелец
SLA, клиент бизнеса, члены команды,
владелец SIP.
Нет 40
20
999999
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
220
Метрика:
MTBSI (среднее время между системными
неполадками) {минуты}
Среднее
время
между
возникновением
следующих друг за другом системных
неполадок. Показывает уровень стабильности
сервиса.
Спецификация:
Среднее время
между возникновением
неполадок,
измеряемое
в минутах, часах или
Обоснование:
днях .
Метрика имеет большое значение для понимания
«доступности» сервиса. Например, доступность,
равная 99,99%, может свидетельствовать как об
одном единственном факте часового простоя,
так
и
о
365
неполадках
общей
продолжительностью
9
секунд,
—
все
это
поАудитория:
разному влияет на пользователей. По
значению MTBSI можно сделать вывод о
Ограничения:
стабильности сервиса.
Опасное значение: Владелец процесса, руководство ИТ, владелец
Целевое значение: SLA, клиент бизнеса, члены команды,
владелец SIP.
Возможные
Нет
значения:
Описание:
150 200
999999
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
MTTR (среднее время прекращения
простоя, среднее время
восстановления) {минуты}
MTTR — это стандартный показатель
доступности, измеряющий среднее время с
момента возникновением неполадки до ее
устранения
(среднее
время
простоя,
приходящееся на одну неполадку).
Среднее время восстановления операционного
статуса или время простоя при сбое сервиса
(неполадке).
Объектом измерения является сервис, а не
компонент,
что
позволяет
компании
сосредоточиться на нужном уровне.
Владелец процесса, руководство ИТ, владелец
SLA, клиент бизнеса, члены команды,
владелец SIP.
Нет 40
20
999999
L. Метрики управления доступностью
221
Критическое время сбоя {минуты}
Критическим
периодом
для
услуг,
Описание:
предоставляемых финансовыми системами,
может быть 27-29 числа каждого месяца.
Метрика измеряет общее время простоя (в
минутах) в течение этого периода.
Спецификация:
Оценивается продолжительность нарушения
обслуживания в критический период времени.
Фактор «критичности» определяется видом
сервиса.
Например,
для
электронной
корреспонденции
наиболее
вероятным
временем возникновения неполадок является
промежуток с восьми до десяти утра, когда
люди приходят на работу в офис и
Обоснование:
просматривают входящие сообщения.
Данный показатель критического времени
поддержки позволяет выявить проблемы,
которые представляются более серьезными,
Аудитория:
чем рядовые нарушения SLA.
Владелец процесса, руководство ИТ, владелец
Ограничения:
SLA, клиент бизнеса, члены команды,
Опасное значение: владелец SIP.
Целевое значение: Нет 40
Возможные
20
значения:
999999
Метрика:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Недоступность услуг третьей стороны
{минуты}
Время в минутах, в течение которого ИТ-услуги
третьей стороны недоступны.
Простой из-за неполадок в обслуживании,
предоставляемом третьей стороной.
Простой в обслуживании, предоставляемом
третьей стороной, представляет особый
интерес для управления доступностью.
Владелец процесса, руководство ИТ, владелец
SLA, клиент бизнеса, члены команды,
владелец SIP.
Нет 120
60
999999
222
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика:
Недоступность компонентов, поставляемых
третьей стороной {минуты}
Описание:
Объектом оценки являются компоненты —
первоисточник
любых
простоев
в
обслуживании. Данная метрика дополняет
предыдущую (которая сосредоточивается на
обслуживании).
Время, в течение которого компонент,
поставляемый
третьей
стороной,
был
недоступен.
Роль управления
доступностью отчасти
сводится к анализу доступности уровня
компонентов. Даже если последние (особенно
те, что имеются в избытке) выходят из строя, не
оказывая явного влияния на сервис, они
повышают его уязвимость ко всем последующим неполадкам. По этой причине важно
обеспечить надежность как услуги, так и
компонента.
Владелец процесса, руководство ИТ, владелец
SLA, клиент бизнеса, члены команды,
владелец SIP.
Нет 60
30
999999
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Задача метрики: обеспечить эффективное управление
обслуживанием и доступностью компонентов.
Метрика:
Время возобновления недоступных
услуг {минуты}
Описание:
Время, требуемое для возобновления
обслуживания
клиентов.
Измеряется в человеко-часах,
израсходованных на
решение проблем доступности.
Существует множество методов сокращения
простоя, связанного с ремонтом: следует
оценить эффективность каждого из них.
Избыточные системы могут сократить время
возобновления сервиса, а метрика позволяет
выявить услуги, которые требуют принятия
соответствующих мер.
Владелец процесса, руководство ИТ, владелец
SLA, клиент бизнеса, члены команды,
владелец SIP.
Спецификаци
я:
Обоснование:
Аудитория:
L. Метрики управления доступностью
Ограничения:
регистра-
223
Необходимо наличие системы почасовой
ции.
Опасное значение:
60 Целевое значение:
30
Возможные значения: 999999
Метрика:
Количество повторных сбоев {неполадки}
Описание:
Количество
CI,
которые
неоднократно
выходили из строя.
Сумма всех сбоев CI.
Одна
из
обязанностей
управления
доступностью заключается в сокращении
многократных сбоев. О ее эффективности
можно судить по значению метрики. Отчет о CI,
перечисленных в порядке возрастания числа
сбоев, позволяет управлению доступностью
выбирать
наиболее
слабые
элементы
конфигурации и принимать решение об их
замене, анализе или преобразовании с целью
повышения работоспособности.
Владелец процесса, руководство ИТ, владелец
SLA, клиент бизнеса, члены команды,
владелец SIP.
Нет
600
300
99999
9
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
м
________________________________________________
Метрики для управления
информационной
безопасностью
Цель управления информационной безопасностью — обеспечить
эффективную защиту информации в рамках всей деятельности по
предоставлению услуг.
Во-первых, выполнять внешние требования безопасности,
вытекающие из различных SLA, контрактов, законодательных
норм и всевозможных политик безопасности.
Во-вторых, выполнять внутренние требования безопасности. Это
нужно, чтобы обеспечить непрерывность деятельности самого
поставщика ИТ-услуг. Необходимо, кроме того, упростить
управление уровнем обслуживания с точки зрения информационной
безопасности. Понятно, что работать с множеством разнообразных
SLA значительно сложнее, чем с небольшим их числом. По этой
причине должен быть установлен определенный базовый (так
называемый стандартный) уровень безопасности.
Миссия: регулировать и контролировать процесс управления
информационной безопасностью с целью удовлетворения
внешних
требований,
определяемых
SLA,
контрактами,
законодательством
и
политикой
безопасности
компании.
Обеспечить соблюдение внутренних требований безопасности
для поддержки непрерывности предоставления ИТ-услуг.
Владелец процесса: менеджер по информационной безопасности.
Задача метрики: регулировать и контролировать процесс
управления
информационной
безопасностью
с
целью
удовлетворения внешних требований, определяемых SLA,
контрактами, законодательством и политикой безопасности
компании. Обеспечить соблюдение внутренних требований
безопасности для поддержки непрерывности предоставления ИТуслуг.
226
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Число инцидентов, связанных с
информационной безопасностью
{инциденты}
Метрика
основывается
на
записях
о
количестве закрытых инцидентов и заявок.
Со временем для этой метрики нужно будет
провести
бенчмаркинг.
Устанавливаемые
ориентиры зависят от уровня контроля и других
факторов
(качество
программного
обеспечения и т.д.).
Очень важно, чтобы процессам, относящимся к
управлению информационной безопасностью,
были доступны данные о соответствующих
инцидентах.
Со
временем
отлаженные
процессы сократят число происшествий и
снизят их вредоносное воздействие.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет 100
50
999999
Число решенных проблем, связанных с
информационной безопасностью
{проблемы}
Сколько решенных проблем было закрыто с
формулировкой,
относящейся
к
информационной безопасности.
Показатель
характеризует
эффективность
управления проблемами и одновременно
является фундаментальным для оценки
управления безопасностью, которое должно
определить для всех процессов меры защиты.
Решение проблем, связанных с безопасностью,
приведет к сокращению числа инцидентов и
повышению доступности ИТ-услуг.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет
5
М. Метрики для управления информационной безопасностью
227
Целевое значение:
10
Возможные значения:
999999
Метрика:
Число решенных проблем, выявленных в ходе
аудита и внутренних проверок {проблемы}
Описание:
В списке проблем должны быть заданы сроки устранения, и при их превышении можно выпускать предупреждения (в дополнение к данной метрике).
Спецификаци Внутренние проверки и аудиты должны выявлять
я:
второстепенные проблемы. Их решение может требовать времени, и данная метрика позволяет
убедиться в том, что продвижение к
поставленной цели происходит в правильном
направлении.
Обоснование: Обеспечение информационной безопасности — это
долгосрочный процесс совершенствования. Проблемы,
выявляемые в ходе аудита и внутренних проверок, важны для получения должного контроля
над данным процессом. Метрика обеспечивает
постоянное внимание к этим проблемам.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец
процесса SLA, члены команды, владелец процесса SIP.
Ограничения: Перечень проблем должен формально документироваться.
5
Опасное
значение:
Целевое
значение:
Возможные значения: 999999
Метрика:
Описание:
Спецификаци
я:
Обоснование:
Процент своевременно проведенных
проверок
и аудитов {проверки/аудиты}
Сколько проверок и аудитов было выполнено в
запланированные сроки.
Пропущенные аудиты и внутренние проверки
могут быть признаком чрезмерной нагрузки,
нехватки ресурсов или чего-то еще более
серьезного.
Внутренние проверки и (в меньшей степени)
аудиты позволяют нам выявить недостатки
процесса. Очень важно, чтобы они проводились
своевременно, это и контролируется данной
метрикой.
228
Аудитория:
Ограничения
:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Планы и предписания аудитов и проверок
должны формально документироваться.
95
100
Опасное
значение:
Целевое
значение:
Возможные значения: 0-100
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Число выявленных рисков
(предостережения и новые угрозы)
{риски}
Все
выявленные
риски
должны
регистрироваться с указанием необходимых
действий. Журнал регистрации служит основой
для данной метрики.
Невозможно выдумать риск или угрозу там, где
их нет. Тем не менее в любой сложной среде
новые риски, хотя и незначительные, могут
обнаруживаться каждую неделю или по крайней
мере раз в месяц. Это свидетельствует об
активности
процесса
управления
информационной безопасностью.
В
рамках
управления
информационной
безопасностью должен активно вестись поиск
новых рисков и угроз. Показатель оценивает
успешность этого процесса: даже с учетом
различных обстоятельств риски могут быть
выявлены всегда.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет
5
10
999999
Процент SLA, где явно оговорены
вопросы информационной безопасности
{% SLA}
SLA хранятся в CMDB, и каждое содержит пункт,
посвященный информационной безопасности.
Метрика помогает следить за тем, чтобы эти
пункты не были шаблонными. SLA следует
должным образом изучить с точки зрения
вопросов безопасности. В общих чер-
М. Метрики для управления информационной безопасностью
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
229
тах это можно сделать, сравнивая тексты в
поле безопасности. Строго говоря, это должна
быть задача мини-аудита или внутренней
проверки.
Если SLA не меняются, метрика бесполезна.
Важно,
чтобы
вопросы
безопасности
учитывались при разработке всех SLA. Метрика
позволяет избежать рисков при создании новых
или перезаключении предыдущих SLA.
Вне зависимости от новизны или давности
сервиса требования к нему могут указывать на
возможные проблемы с безопасностью, и эти
проблемы, а также предложения по их
минимизации, должны быть явно отражены в
SLA.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет
70
100
0-100
Метрика:
Процент внешних договоров, где явно
оговорены вопросы информационной
безопасности {% внешних договоров}
Описание:
Внешние договоры, как и SLA, должны
храниться в CMDB, и их пункты, посвященные
информационной
безопасности, можно сравнивать, чтобы
убедиться, что они не являются шаблонными.
В конечном итоге внешние договоры, как и SLA,
должны быть приведены в соответствие с
политикой
информационной
безопасности
компании. Метрика позволяет отслеживать
соответствующую деятельность. Небрежность в
заключении внешних договоров способна
повлечь значительный риск.
Следует активно рассматривать внешние
договоры, чтобы предотвратить проблемы,
связанные с информационной безопасностью.
Эта работа оценивается
данной метрикой.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Спецификаци
я:
Обоснование:
Аудитория:
230
Ограничения:
документи-
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Внешние договоры должны формально
роваться.
Опасное значение:
Целевое значение:
100
Возможные значения: 0-100
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификаци
я:
Число выявленных проблем релиза,
связанных с информационной
безопасностью релиза (возвраты к
исходному состоянию/вирусы и т.д.)
{проблемы}
Все планы релизов должны содержать
нешаблонный
пункт,
посвященный
информационной безопасности.
Управление релизами крайне уязвимо с точки
зрения угроз для безопасности. Активный
контроль релизов (особенно срочных) со
стороны управления безопасностью позволит
поддерживать низкое значение метрики.
Релизы представляют высокий риск для
процедур,
относящихся
к
безопасности.
Метрика
обеспечивает
независимое
исследование допустимого уровня риска для
каждого плана релиза.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Релизы должны формально
документироваться.
5
О
999999
Число изменений, которые были по
соображениям информационной
безопасности отменены (и система
возвращена в исходное состояние)
{изменения}
Значение показателя определяется по записям
о выполненных изменениях: считаются те, где
указано, что причиной возвращения системы в
исходное состояние стала информационная
безопасность.
Если при внесении изменений возникает
проблема с информационной безопасностью,
они были плохо спланированы. Неудавшееся
изменение нужно все-
М. Метрики для управления информационной безопасностью
231
сторонне
исследовать,
чтобы
исключить
возможность преднамеренной атаки.
Изменения, включая релизы, следует должным
Обоснование:
образом планировать и тестировать. Если они
отменяются по причинам, связанным с
информационной безопасностью, это указывает
на слабость и неэффективность контроля.
Владелец процесса, руководство ИТ-отдела,
Аудитория:
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет 5
Ограничения:
Опасное значение: О
Целевое значение: 999999
Возможные
значения:
Задача метрики: показывать способность организации к
адаптации системы информационной безопасности путем быстрой
установки защитных
патчей.
Метрика:
Скорость установки патчей, связанных с
информационной безопасностью {время}
Всевозможные патчи и обновления, связанные
с безопасностью, выпускаются довольно часто,
и
специалистам
ИТ-служб
приходится
обновлять соответствующее ПО.
Время с момента выпуска патча поставщиком
Спецификация:
до его установки в среде промышленной
эксплуатации.
Обоснование:
Чем больше время, необходимое для установки
патча, тем выше риск, чем оно меньше, тем
уязвимость ниже.
Аудитория:
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Ограничения:
Неполучение
патчей
или
обновлений,
Опасное значение: связанных с безопасностью.
Целевое значение: 1 неделя
2 дня
Возможные
Теоретически не ограничены.
значения:
Описание:
Метрики
для бизнес-планирования
Целью
метрик
бизнес-планирования
является
оценка
воспринимаемого качества обслуживания (Quality of Experience —
QoE) — мера удовлетворенности бизнеса, соотнесенная с его
потребностями.
Миссия: постоянно поддерживать и повышать эффективность
бизнеса путем предоставления высококачественных услуг ИС,
согласованных с потребностями компании и способных на эти
потребности реагировать, обеспечивая при этом максимальную
окупаемость инвестиций в информационные системы.
Владелец процесса: руководитель ИТ.
Следующие три метрики предназначены для оценки бизнеспланирования в целом.
Задача метрики: приведение
потребностями бизнеса.
IT-услуг
в
соответствие
с
Метрика:
Средние затраты на предоставление
одной услуги {затраты}
Описание: Данные о затратах извлекаются из CMDB: Число обращений х Расчетная стоимость обращения + Управление
проблемами + Постоянные издержки и т.д.
Спецификация: Метрика требует действующего процесса управления
финансами, в противном случае стоимость нужно
чем-либо
заменить
(возможно,
даже
интенсивностью
234
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
звонков или временем простоя в расчете на одну
услугу). Расчет прост: Общие затраты / Число
услуг. В данном примере метрика выражается в
процентах от прямых затрат. Это суммарная
стоимость инцидентов, проблем, изменений и
операций, посвященных определенной услуге,
поделенная на общее число услуг. По мере
улучшения обслуживания показатель должен
снижаться, несмотря на то что запуск новых
услуг может характеризоваться высокими
издержками.
Это сложный (не соответствующий критериям
SMART) показатель. Тем не менее управлению
финансами стоит стремиться измерить его как
можно точнее, чтобы бизнес-планирование
могло представить руководству верную картину
стоимости услуг.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP. Нет 30 20 0100
Задача метрики: еспечить эффективную связь информационных
of
техпологий и
бизнеса.
Степень удовлетворенности клиентов
Метрика:
{удовлетворенность}
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Общая
сумма
всех
показателей
удовлетворенности клиентов.
Удовлетворенность клиентов управлением ИТуслу-гами.
В конечном итоге именно бизнес-планирование
несет
ответственность
за
обеспечение
эффективной связи бизнеса и ИТ.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Нет
<3
N. Метрики для бизнес-планирования
235
Целевое значение:
4 Возможные значения:
0-5
Метрика:
Знание бизнеса сотрудниками ИТподразделе-ния {удовлетворенность}
Описание:
Насколько
представители
бизнеса
удовлетворены уровнем знаний о бизнесе у
сотрудников ИТ-подраз-деления.
В опросы, проводимые для изучения степени
удовлетворенности
клиентов,
следует
включить вопрос о том, насколько приемлем с
точки зрения респондента уровень знаний о
бизнесе, демонстрируемый ИТ-персоналом.
Имеются в виду знания, относящиеся к бизнесфункции
респондента,
которые
были
продемонстрированы при работе с ним
сотрудниками ИТ-подразделения.
Все сотрудники ИТ-подразделения должны
обладать
определенными
знаниями
и
представлениями о том бизнесе, который они
обслуживают.
Показатель
характеризует
уровень этих знаний. Он применяется к бизнеспланированию, поскольку для эффективной
связи между ИТ и бизнесом необходимо
доверие, а оно требует определенного уровня
взаимопонимания и знаний друг о друге.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет
<3
4 05
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
N.1. Управление взаимоотношениями с бизнесом
Метрика:
Число жалоб на обслуживание {жалобы}
Описание:
Общее число жалоб на обслуживание,
поступивших в ИТ-подразделение.
Позволяет судить об удовлетворенности
клиентов и качестве взаимоотношений между
подразделениями.
Спецификаци
я:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
236
Обоснование:
меж-
Аудитория:
владелец
Ограничения:
подразделения,
Для хорошего управления взаимоотношениями
ду ИТ-подразделением и клиентом нужно
иметь представление об удовлетворенности
последнего.
Владелец процесса, руководство ИТ-отдела,
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Не все, кто недоволен работой ЙТ-
дают об этом знать.
Опасное значение:
20
Целевое значение:
10
Возможные значения: 999999
Метрика:
Число невыполненных действий с момента
последней проверки данного сервиса
{действия}
Описание:
послед-
Число действий, которые были намечены при
Спецификация:
подразде-
Обоснование:
действий поАудитория:
владелец
Ограничения:
вы-
ней проверке сервиса, но еще не были
выполнены.
Метрика показывает, насколько успешно
ление проводит проверки и выполняет намеченные
действия.
Эффективное выполнение намеченных
вышает удовлетворенность клиентов и тем
самым улучшает взаимоотношения с бизнесом.
Владелец процесса, руководство ИТ-отдела,
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Метрика характеризует скорость, но не качество
полнения действий,
Опасное значение: 15
Целевое
значение:
10
Возможные
значения:
999999
N.2. Управление взаимоотношениями с поставщиками
Метрика:
связанных
Максимальное число инцидентов,
с одним поставщиком {инциденты}
Описание:
конкретного
Каждый инцидент прослеживается до
поставщика. Учитывается число инцидентов в
расчете на одного поставщика.
N. Метрики для бизнес-планирования
Спецификация:
Обоснование:
Аудитория:
Ограничения:
237
Число инцидентов, полностью или частично
спровоцированных
поставщиком
или
произошедших по его вине. При качественном
управлении
взаимоотношениями
с
поставщиками этот показатель должен снизиться. Учитываются инциденты, а не проблемы,
поскольку
необходимо
минимизировать
нарушения работы бизнеса.
Дм хорошего управления взаимоотношениями с
поставщиками очень важно знать уровень
удовлетворенности обслуживанием.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Метрика не учитывает серьезность
последствий инцидентов. Вполне возможно, что
поставщик, по вине которого произошел всего
один, но очень крупный инцидент, нанес
Опасное значение: компании больше вреда, чем тот, из-за
Целевое значение: которого случилось много мелких неполадок. 70
50 999999
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения;
Опасное
значение:
Процент постоянных поставщиков,
удовлетворяющих стандартам {%
поставщиков}
Какая часть поставщиков удовлетворяет
стандартам.
Речь идет о стандартах IS09000 или ISO20000.
Цель — достигнуть состояния, когда им будут
соответствовать все поставщики. Как только
это произойдет, можно заменить метрику
показателем
качества,
выбранным
по
тактическим соображениям.
Вероятность
инцидента
или
проблемы
снижается,
когда
все
части
системы
подчиняются одним и тем же механизмам
работы,
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес- клиент, члены
команды, владелец процесса SIP.
Поставщики могут соответствовать стандартам
на словах, но это утверждение очень сложно
проверить.
85
238
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Целевое значение:
95
Возможные значения: 0-100
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Процент проверок качества услуг
поставщиков на соответствие
определенным требованиям, проведенных
в срок {% проверок}
Процент запланированных на регулярной основе
проверок
поставщиков,
которые
были
проведены своевременно.
Графики проверок, отражающие информацию о
тех проверках, которые должны были быть
проведены в прошлом и по которым при этом
не составлены итоговые отчеты либо перечни
необходимых действий.
Проверки поставщиков могут показаться
несущественными, когда дела идут хорошо, и
о них тогда легко забывать. Это опасно,
поскольку увеличивается риск перерастания
мелких
неполадок,
оставленных
без
внимания, в серьезные проблемы.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет 5 2
0-100
Метрика:
Число нерешенных проблем,
относящихся к поставщикам {проблемы}
Описание:
Проблемы
обнаруживаются
процессами
управления инцидентами, проблемами, а
также
при
проверках
поставщика
и
учитываются данной метрикой.
Число
проблем
в
соответствующем
регистрационном журнале.
Важно, чтобы поставщики своевременно
реагировали на сообщения о проблемах.
Метрика позволяет видеть, какие проблемы
остаются нерешенными, и помогает работать
над сокращением их числа. Без этого обе
стороны склонны рассматривать перечень
нерешенных вопросов как нечто менее важное,
чем
Спецификаци
я:
Обоснование:
N. Метрики для бизнес-планирования
Аудитория:
владе-
239
повседневные работы, в результате чего
повышается вероятность перерастания
нерешенных проблем в
инциденты.
Владелец процесса, руководство ИТ-отдела,
лец процесса SLA, члены команды, владелец
процесса SIP.
Ограничения:
Нет
Опасное значение: 20
Целевое значение: 10
Возможные значения:
0-100
N.3. Управление поставкой услуг
Миссия; Бизнес-планирование. Поставщик ИТ-услуг несет
ответственность за предоставляемые ИТ-услуги и уровень их
качества, включая первоначальный сбор требований, разработку
приложений, внедрение, повседневное управление, постоянное
улучшение, а впоследствии прекращение обслуживания. Чтобы
бизнес рассматривал эту деятельность как успешную, услуги
должны быть высококачественными, удовлетворять меняющимся
требованиям бизнеса и предоставляться по приемлемой цене.
Владелец процесса: менеджер по управлению уровнем
обслуживания.
Задача метрики: предоставлять
минимальными перебоями.
услуги
для
бизнеса
с
Метрика:
Минимальная оценка степени
удовлетворенности клиентов {удовлетворенность}
Описание:
Спецификация:
преОбоснование:
над
Аудитория:
владелец
Ограничения:
Процесс с самым низким показателем.
Минимальная оценка по всем процессам. Цель
доставления услуг — повысить данную оценку.
Группа предоставления услуг должна работать
улучшением наихудшего процесса — возможно,
посредством процесса SIP. Метрика оценивает
успешность этих действий.
Владелец процесса, руководство ИТ-отдела,
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Нет
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
240
Опасное значение:
<3 Целевое значение:
4 Возможные значения:
0-5
Метрика:
Число инцидентов {инциденты}
Описание:
Процесс
предоставления
услуг
должен
постепенно сокращать число инцидентов.
Чтобы избежать влияния сезонных или иных
краткосрочных факторов, можно заменить эту
метрику скользящим средним значением.
Общее число инцидентов является показателем
уровня нарушений обслуживания, выявленного
ИТ-под-разделением.
Инциденты
—
главный
показатель
неустойчивости обслуживания.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Нет 150
100
999999
9
Спецификация:
Обосновани
е:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Задача .метрики: эффективное предоставление услуг.
Метрика:
Степень удовлетворенности клиентов
{удовлетворенность}
Описание:
Показатель качества предоставления услуг на
уровне
бизнеса.
Общая удовлетворенность клиентов
аналогично
управлению уровнем обслуживания.
Эффективность
предоставления
услуг
оценивается по степени удовлетворенности
клиентов.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Нет
<3
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное
значение:
N. Метрики для бизнес-планирования
241
Целевое значение:
4
Возможные значения: 0-5
N.4. Планирование, анализ и развитие
Миссия: обеспечить эффективное планирование ИТ-процессов и
правильную реализацию разработанных и одобренных планов.
Владелец процесса: проектное бюро.
Задача метрики: проверять планы и модифицировать их согласно
требованиям бизнеса.
Метрика:
Число проблем, выявленных при
окончательной проверке плана {проблемы}
Число проблем.
Число проблем, выявленных при проверке.
Показывает, сколько изменений требуется
внести в документ, — со временем, по мере
совершенствования процессов, это число
должно уменьшиться.
Аудитория:
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Ограничения:
Опасное значение: Нет 8 6
Целевое значение: 999999
Возможные
Число планов, одобренных для реализации
значения:
{планы}
Описание:
Спецификация:
Обоснование:
Метрика:
Описание:
Спецификация:
Оценивается деятельность не только по
разработке, но и по утверждению планов.
Однако сложность планов не учитывается —
данный параметр отражает исключительно
количественную характеристику. Полезнее,
хотя и сложнее, было бы оценивать прогнозируемые масштабы проектов в человекочасах, а не просто считать их поштучно.
Поскольку документация будет храниться в
CMDB, информацию о статусе можно
узнавать непосред-
МЕТРИКИ для УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
242
Обоснование:
утвержАудитория:
владе-
ственно оттуда. Учитываются те планы, которые
перешли в категорию подписанных.
Планы необходимо не только создавать, но и
дать.
Владелец процесса, руководство ИТ-отдела,
лец процесса SLA, члены команды, владелец
процесса SIP.
Ограничения:
Нет
Опасное значение: 2
Целевое значение: 4
Возможные значения:
999999
N.5 Взаимодействие, обучение и информирование
Миссия: информировать пользователей и клиентов ИТ о текущих и
будущих планах и поощрять выдвижение идей по улучшению.
Владелец процесса: проектное бюро.
Задача метрики: укомплектовать все рабочие места
квалифицированными кадрами.
Метрика:
Число действий, предусмотренных планом
информирования, которые не были
выполнены в срок {действия}
Описание:
инфор-
Для всех действий, предусмотренных планом
Спецификация:
невыполненными на
Обоснование:
Мет-
Аудитория:
владе-
Ограничения:
Опасное значение:
мирования, в нем должен быть обозначен
определенный срок. Метрика показывает,
сколько действий не было выполнено к
установленной для них дате.
Действия, которые оставались
момент измерения.
Что запланировано, то должно быть выполнено.
рика показывает, насколько эффективно это
делается.
Владелец процесса, руководство ИТ-отдела,
лец процесса SLA, члены команды, владелец
процесса SIP.
Нет
5
N. Метрики для бизнес-планирования
243
Целевое значение:
3
Возможные значения:
999999
Метрика:
Процент ИТ-персонала с неоптимальным
для занимаемой должности уровнем
подготовки {% персонала}
Описание:
Уровень образования и опыта сотрудников
компании по данным отдела кадров либо базы
данных по подготовке и компетентности в
области ИТ.
Оценка квалификации персонала.
Стандарт ISO20000 требует, чтобы персонал
был
в
состоянии
продемонстрировать
профессиональную подготовленность и опыт,
соответствующие занимаемой должности.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Нет
2 1
0100
о
___________________________________________________
Метрики для постоянно
действующей программы
по улучшению услуг (SIP)
Миссия:
выполнять
SIP
как
непрерывную
программу.
Обмениваться информацией с руководством ИТ-подразделения и
обеспечить специальное рассмотрение каждого процесса в рамках
SIP как минимум раз в два года. При этом должны своевременно
рассматриваться процессы, которые, как показывают их метрики,
требуют наибольшего внимания.
Владелец процесса: проектное бюро.
Задача метрики: улучшать текущее функционирование процесса
в соответствии с требованиями бизнеса.
Метрика:
Общая степень удовлетворенности клиентов
{удовлетворенность}
Описание:
удовлетворен-
Среднее всех показателей степеней
Спецификация:
клиен-
Обоснование:
клиентов
Аудитория:
владелец
ности клиентов.
Общая степень удовлетворенности конечных
тов. Задача SIP — повышать этот показатель, а
также сокращать издержки.
Со временем степень удовлетворенности
должна повышаться благодаря SIP.
Владелец процесса, руководство ИТ-отдела,
процесса SLA, бизнес-клиент, члены команды,
владелец процесса SIP.
Ограничения:
Опасное значение:
Нет
<3
246
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Целевое значение:
4
Возможные значения: 05
Метрика:
Описание:
Процент экономии средств (достигнутой
благодаря SIP) для процессов {%
экономии}
Насколько снизилась благодаря SIP общая
сумма расходов на ИТ.
Как правило, в рамках SIP по очереди
рассматриваются все процессы. В результате
такого
рассмотрения
должна достигаться
определенная выгода — экономия средств. С
какой точностью ее измерять, зависит от
процесса и может определяться в SIP.
Измерение производится до завершения SIP
следующего процесса. Это позволяет вовремя
обнаруживать
непредвиденные
негативные
Обоснование:
последствия SIP и определять вклад программы
в совершенствование каждого из процессов.
Усовершенствование в рамках SIP должно
Аудитория:
давать ощутимые результаты, тогда экономия
будет измеримой и заметной.
Владелец процесса, руководство ИТ-отдела,
Ограничения:
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Опасное значение:
Чтобы получать правильные значения, должен
Целевое значение:
действовать процесс управления финансами
Возможные
для ИТ. 5 10 0-100
значения:
Спецификация:
Метрика:
Процент процессов, для которых SIP
задерживается {% процессов}
Описание:
Учитываются
процессы,
для
которых
задерживается рассмотрение их работы в
рамках SIP.
Если SIP для десяти ключевых процессов ITIL
выполняется каждые десять месяцев (по
процессу в месяц), опозданием считается
ситуация, когда с момента последнего
усовершенствования
некоторого
процесса
прошло одиннадцать или более месяцев.
Хотя SIP сосредоточивается в первую очередь
на тех процессах, которые, как показывают
метрики, нужда-
Спецификаци
я:
Обоснование:
0. Метрики для постоянно действующей программы по улучшению услуг (SIP)
Аудитория:
247
ются в улучшении, периодическим проверкам
должны подвергаться все процессы.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Нет
Ограничения:
20
Опасное
10
значение:
Целевое
значение:
Возможные значения: 0-100
Метрика:
Описание:
Спецификация:
Число действий, которые были одобрены,
но не выполнены и не достигли цели
{действия}
Что не было сделано.
Все действия в рамках SIP документируются,
цели предполагаемых усовершенствований
согласуются, и весь план утверждается.
Метрика
отслеживает
выполнение
этих
действий. Без этого SIP не может считаться
Обоснование:
успешной.
Действия,
рекомендуемые
SIP,
должны
соответствовать
критериям
SMART.
Это
означает, что мы можем отслеживать их
результаты. Очень важно, чтобы ожидаемые
Аудитория:
усовершенствования действительно были достигнуты. Метрика показывает, так ли это.
Владелец процесса, руководство ИТ-отдела,
Ограничения:
владелец процесса SLA. бизнес-клиент, члены
Опасное значение: команды, владелец процесса SIP.
Целевое значение: Нет
Возможные
5
3
значения:
99999
9
Метрика:
Описани
е:
Число невыполненных действий, которые
были записаны в плане информирования
SIP
{действия}
Метрика следит за тем, чтобы план
информирования
SIP
существовал,
а
перечисленные в нем действия выполнялись в
срок.
248
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Для усовершенствований, сделанных в рамках
SIP, следует получать количественную оценку,
составлять отчеты и выпускать в соответствии с
планом информирования информационные
сообщения. Метрика отслеживает любые
неполадки с выпуском сообщений, при этом
контролируется также составление отчетов.
Для успеха плана информирования SIP важны
перечисленные там действия, а значит, и
метрика, которая должна их отслеживать.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Нет 10 5
999999
Метрика:
Число одобренных исправлений в
политиках, планах и процедурах управления
услугами {исправления}
Описание:
Спецификация:
Изменения в SIP.
Нет никакой необходимости в большом числе
изменений, а основными являются только те из
них, которые реально одобрены. Тем не менее
SIP требует целостного подхода, и метрика при
необходимости обеспечивает измерение этих
исправлений в рамках SIP.
Метрика делает видимыми изменения в SIP, в
особенности те из них, которые относятся к
политикам и процедурам. Важно, чтобы они
понимались как часть SIP.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
SIP должна формально документироваться.
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
2
5
999999
0. Метрики для постоянно действующей программы по улучшению услуг (SIP)
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификаци
я:
Обоснование
:
249
*.Число улучшении,
внесенных владельцами
процессов не в рамках цикла SIP
{исправления}
Исправления, внесенные владельцами
процессов.
SIP — это постоянно действующий двигатель
улучшения обслуживания. Но кроме того,
владелец каждого процесса должен стараться
улучшить
и
SIP.
Подобные
усовершенствования
должны
координироваться в рамках процесса SIP и
представляться посредством этой метрики,
так чтобы можно было оценить всю
достигнутую экономию.
Есть
опасность,
что
SIP
будет
рассматриваться как единственное средство
усовершенствования
процессов.
Метрика
обращает внимание на соответствующую
деятельность владельцев процессов.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Нет
2
5
9999999
,_
г,т
Число SIP, запланированных, но не
осуществленных в срок {SIP}
Планы по улучшению услуг, которые пока не
выполнены.
SIP, предполагающие какие-либо действия,
срок выполнения которых прошел.
SIP — это фундаментальная часть задачи по
предоставлению
клиентам
надлежащего
качества обслуживания. Если в каком-либо
плане SIP определены действия, важно, чтобы
они были выполнены в соответствии с планом.
Метрика выявляет любые отклонения от этого
правила. Конечно, они могут быть обусловлены
вескими причинами, но на сам факт
невыполнения плана необходимо обратить
внимание, иначе он может отрицательно
повлиять
на
ряд
других
показателей,
улучшение качества обслуживания которых
зависит от SIP.
250
Аудитория:
Ограничения:
Опасное
значение:
Целевое
значение:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Нет
22
Возможные значения: 9999999
Задача метрики: обеспечить измеримый прогресс процессов.
Метрика:
Общий прогресс с момента последнего
бенч-маркинга {% прогресса}
Описание:
Изменение
показателей
процессов,
рассчитанное как скользящее среднее за три
месяца.
Входные данные должны собираться по всем
процессам. Важно учесть и измерить общий
вклад всех владельцев процессов.
Следует ежегодно проводить бенчмаркинг
метрик,
чтобы
оценивать
процессы
в
соответствии с его показателями. Показатели
процессов, усовершенствованных в рамках SIP,
должны улучшаться.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Чтобы данная метрика имела смысл, все
остальные метрики должны быть теми же, что и
в момент бенч-маркинга.
3 5
0100
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Задача метрики:
вносить э
ния услугами.
ективные изменения в процессы
управле-
Метрика:
Число рекомендаций по улучшению,
полученных от владельцев других процессов
{рекомендации}
Описани
е:
Когда процесс совершенствуется в рамках SIP,
владельцам связанных с ним других процессов
следует
0. Метрики для постоянно действующей программы по улучшению услуг (SIP)
251
высказывать свои рекомендации. Степень их
активности оценивается данной метрикой.
Показатель активности.
Спецификация:
SIP — не внешний аудит. Это программа,
Обоснование:
получающая информацию из метрик процесса
и рекомендации от владельцев смеждых
процессов.
Очень
важно,
чтобы
эти
рекомендации
поступали.
Аудитория:
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Ограничения:
Рекомендации владельцев процессов должны
Опасное значение: формально документироваться.
Целевое значение; 3 5
999999
Возможные
значения:
Метрика:
Число изменений, требуемых для
улучшения процесса {изменения}
Описание:
Спецификация:
Обоснование:
Изменения, необходимые для улучшения
процессов. Запросы на изменение (RFC) от
процесса SIP.
За изменение процессов отвечает процесс
управления изменениями. Поэтому число RFC
показывает степень активности процесса SIP и
объем
изменений,
необходимых
рассмотренных процессов.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Нет 3 5
999999
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
р
__________________________________________________
Метрики
для управления рисками
Миссия: управление рисками в ITIL. относится к процессу
управления доступностью, хотя используется b в ряде других областей. Так как
степень удовлетворенности клиентов является одной из метрик
управления доступностью, для управления рисками она не
оценивается.
Владелец процесса: менеджер по процессу управления
доступностью.
Задача метрики: управление рисками в ITIL относится к процессу
управления доступностью, хотя используется н в ряде других
областей.
Метрика:
воздейст-
% CI, охватываемых анализом
вий на бизнес (Business Impact Analysis — BIA)
(%Ш
Описание:
Спецификация:
классы
Обоснование:
включены
Аудитория:
Выполнен ля BIA?
Анализ воздействия на бизнес рассматривает
CI —не требуется рассматривать каждый CI в
отдельности. В идеале все CI должны быть
привязаны к со-ответствующему ВIА. Так как
степень
удовлетворенности
клиентов
является одной из метрик управления
доступностью. для управления рисками она не
оценивается..
В некоторый момент все CI должны быть
в ВIА и отмечены соответствующим образом.
Владелец процесса руководство ИТ-отдела,
владелец
Ограничения:
процесса SLA, члены команды, владелец процесса SIP.
Нет
254
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Опасное значение;
60 Целевое значение:
75
Возможные значения: 0-100
Задача метрики: управление непрерывностью предоставления
ИТ-ус-луг планирует сократить воздействие на бизнес всех
прогнозируемых рисков.
Метрика:
Процент документов BIA, не пересматривавшихся в течение требуемого времени {%
документов}
Описание:
В большинстве организаций BIA следует
пересматривать раз в год — или чаще, если
обстоятельства быстро меняются. Независимо
от того, какая периодичность пересмотра
определена для данной метрики, этот срок
должен быть определен и документально
зарегистрирован.
Показатель,
подтверждающий
своевременность пересмотров BIA.
Если
BIA
проводится
нерегулярно,
в
вычислительной среде могут происходить такие
изменения, которые усиливают (или ослабляют)
воздействие
различных
сценариев,
установленных ранее. Это означает, что
уязвимость
может
быть
выше,
чем
предполагалось, или, наоборот, указывать на
то, что Б дорогостоящих мероприятиях по
снижению риска не было необходимости.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет
12
20 0100
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Процент процессов, подлежащих оценке со
стороны операционного риска (Operational
Risk Assessment — ORA) {% процессов}
Описани
е:
Полезно проводить ORA в рамках процесса SIP,
причем важно делать это как минимум раз в
год. Чтобы
Р. Метрики для управления рисками
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
255
оценить операционный риск, в описании
каждого инцидента должен присутствовать
раздел, где перечислены связанные с ним
проявившиеся риски.
Все процессы подвержены операционному
риску. Метрика учитывает те из них, для
которых этот риск в итоге был реализован в
форме инцидентов.
Метрика помогает составить картину того,
каким образом инциденты соотносятся с
операционным риском, и какие процессы в
связи с этим подвержены наибольшей
опасности.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет 20
12 0-00
Задача метрики: управление непрерывностью предоставления
ИТ-услуг направлено на сокращение вредоносного воздействия
всех прогнозируемых рисков.
Метрика:
Число инцидентов в связи с рисками, не
учтенными в рамках ORA {инциденты}
Описание:
Оценка операционного риска (ORA) должна
быть
максимально
точной.
Метрика
соответствует степени ее ошибочности —
учитываются события, которые в принципе
могли бы оказать сильное влияние на
организацию и при этом не были ни
предсказаны, ни спрогнозированы.
Выявление инцидентов, которые должны быть
учтены, и сообщение о них — задача процесса
управления проблемами. Если, к примеру, релиз
программного обеспечения был установлен без
предварительной ORA, связанные с ним
инциденты являются неучтенными рисками.
Чтобы измерить показатель, понадобится
связывать CI с соответствующими ORA.
Очень важно понимать истинную степень
достоверности
ORA.
Предусмотреть
все
опасности невозмож-
Спецификаци
я:
Обоснование:
256
Аудитория:
Ограничения:
Опасное
значение:
Целевое
значение:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
но, тем не менее частота встречаемости
событий, не учтенных в ОКА, показывает, в
каких областях можно улучшить процесс
распознавания рисков.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет
20
10
Возможные значения: 999999
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Процент инцидентов, частота которых
превышает предсказанную при ORA {%
инцидентов}
ORA позволяет предсказать высокую, среднюю
или
низкую
вероятность
риска
для
конфигурационных элементов. Если прогнозы
регулярно не оправдываются, необходимо
корректировать ORA в соответствии с
реальными рисками.
Метрика требует количественного определения
того, что считать высокой, средней и низкой
вероятностью (например, высокая — более 200
событий в месяц, средняя — от 100 до 200,
низкая — менее 100). Показывает, насколько
прогнозируемый риск соответствует реальной
частоте, с которой происходят инциденты.
Прогнозы по своей природе недостоверны.
Тем не менее для бизнеса важно, чтобы они
составлялись,
причем
с
максимальной
достоверностью.
Метрика
обеспечивает
сравнение прогнозов с реальными событиями и
выявление отклонений, что позволяет повысить
достоверность.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет
70 50
0100
Р. Метрики для управления рисками
Метрика;
Описание:
257
Процент CI, длительность простоя
которых превышает предсказанную при
ORA {% CI}
Прогнозируемое
воздействие
конкретных
рисков на бизнес можно сравнивать с
реальным, чтобы повысить достоверность
прогнозов. Это возможно и допустимо лишь в
отношении распространенных низкоуровневых
Спецификация:
рисков.
С помощью вышеупомянутой связи можно
рассчитать предсказуемое воздействие простоя
определенного CI на бизнес и сравнить с
реальным временем, в течение которого
Обоснование:
простой этого CI нарушал нормальное
функционирование бизнеса.
Предсказание
воздействия
на
бизнес
существенно для принятия решений о ресурсах,
необходимых для уменьшения риска. Если
прогнозы ошибочны, то риск для бизнеса
Аудитория:
возрастает. Метрика обеспечивает сравнение
реального воздействия с прогнозируемым для
Ограничения:
повышения достоверности прогнозов.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
Опасное значение: владелец процесса SIP.
Целевое значение: Метрика неприменима и не будет
способствовать улучшению качества
Возможные
прогнозирования в случае значительных,
значения:
нетипичных рисков и их последствий,
70 50
0100
Задача
метрики:
управление
непрерывностью
предоставления ИТ-услуг позволяет снизить вредоносное
воздействие всех прогнозируемых рисков.
Метрика:
Число действий, направленных на
сокращение риска {действия}
Описание:
Процесс
документирования
действий,
предпринимаемых в ответ на выявленные
риски, должен формально контролироваться,
что обеспечит автоматический учет этих
действий.
В
качестве
реакции
на
расхождения,
оцениваемые с помощью описанных выше
метрик, а также в рамках
Спецификаци
я:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
258
SIP необходимо предпринимать действия,
направленные на сокращение определенных
рисков. Метрика фиксирует те из них, которые
были
правильным
образом
задокументированы.
Недостаточно
выявлять новые риски — нужно что-то
Обоснование:
делать для уменьшения их самих или их воздействия.
Метрика позволяет оценить степень активности в
этом направлении.
Владелец
процесса,
руководство
ИТ-отдела,
Аудитория:
владелец процесса SLA, члены команды, владелец
процесса SIP.
Ограничения:
Нет
Опасное
3
значение:
5
Целевое
Возможные
значения:
999999
значение:
Задача метрики: управление непрерывностью предоставления
ИТ-услуг позволяет минимизировать вероятность для всех
прогнозируемых рисков.
Метрика:
Число вновь выявленных рисков {риски}
Описание:
Новые
риски,
которые
формально
задокументированы.
Со временем риски меняются, особенно те,
которые затрагивают бизнес. Оценка риска
для ИТ должна отражать текущий уровень
опасности. Регулярное выявление новых
внутренних и внешних рисков имеет большое
значение.
После
выявления
новых
рисков
анализируется их влияние на бизнес, и
принимаются возможные встречные меры.
Пока риски не выявлены, сделать ничего
нельзя. Благодаря метрике активный анализ
вероятных рисков становится обязательной
частью ИТ-мышления.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Нет
2
3
999999
Р. Метрики для управления рисками
259
Задача метрики: включение всех CI в план по непрерывности
предоставления ИТ-услуг.
Метрика: Процент CI, не включенных в план по непрерывности предоставления услуг {% CI}
Описани Все CI должны быть включены в план по непрерывности
предоставления услуг. Возможно, они не требуют никаких действий, но это тоже должно
е:
быть явно прописано в плане. Для каждой
новой услуги в план необходимо вносить
соответствующую запись.
Спецификация: Проверка того, что все CI связаны с планом по непрерывности предоставления услуг, т.е. учтены, даже
если они не требуют никаких действий.
Обоснование: Если какие-то CI не включены в план по непрерывности предоставления услуг, то в этом случае в плане
для данных конфигурационных единиц не
может быть предусмотрено соответствующих
действий по их восстановлению в случае
аварии. Метрика обеспечивает динамическое
добавление новых CI в соответствующий
раздел плана, предотвращая тем самым
данный риск.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец
процесса SLA, члены команды, владелец процесса SIP.
Нет
Ограничения:
Опасное значение: 10
Целевое значение: 5 0-100
Возможные
значения:
Задача метрики: обеспечить, чтобы
внутренние и внешние поставщики
предоставляли услуги для бизнеса в соответствии с согласованными
уровнями обслуживания.
Метрика:
Описани
е:
Число совещаний с поставщиками и с
владельцами внутрикорпоративных
процессов {встречи}
Совещания
с
партнерами
не
всегда
позволяют добиться чего-либо. Однако если
они вообще не проводятся, внимание
поставщиков
и
владельцев
внутренних
процессов к задачам управления рисками может
260
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
сойти на нет. Сделав их регулярными, имеет
смысл перейти к оценке достигнутых в каждом
случае результатов.
Оценивается по протоколам совещаний с
поставщиками и владельцами процессов,
представляющим
собой
формальные
документы.
Поскольку повестки и протоколы совещаний
документируются, можно отслеживать их
проведение. В идеале желательно проверять
выполнение поставленных задач, но это
нелегко. Деятельность, описанная в первой
части раздела «Метрики для бизнеспланирования»,
подразумевает
активное
взаимодействие с поставщиками по самым
разным поводам, и чтобы ее оценивать,
понадобится какой-то показатель успешности
коммуникативного процесса (помимо просто
«удовлетворенности поставщика»). Вот почему
вводится данная метрика. Регулярные совещания с поставщиками должны проходить в
соответствии с фиксированным процессом,
иметь стандартную повестку, охватывающую
потенциальные источники проблем. Метрика
должна обеспечить проведение собраний,
чтобы поддерживать постоянное активное
взаимодействие вместо более обычных сегодня
процессов, вызываемых к жизни серьезными
проблемами или прекращением контракта.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP. Нет I
3
999999
Q
Метрики для управления
документацией
Миссия: соответствие стандартам и отслеживание метрик
управления документацией. Обеспечить безопасное хранение
документов и одновременно их качественную индексацию с целью
упрощения доступа для авторизованных пользователей. Вести
контрольные записи и проверять, чтобы управление всеми
существенными документами подчинялось плану непрерывности
предоставления ИТ-услуг и благодаря этому была обеспечена их
доступность в случае крупной аварии.
Владелец процесса: менеджер процесса управления
конфигурациями. Задача метрики: следование политике
управления документами.
Метрика:
Процент документов, для которых не
была проведена в срок плановая
проверка {% документов}
Описание:
Документы, которые устарели из-за того, что не
была
проведена
плановая
проверка.
Документы с истекшим сроком проверки.
Если документы не пересматриваются в
течение ранее определенных сроков, то
опирающиеся на них планы также устаревают и
могут привести к перебоям в обслуживании.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет
5
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное
значение:
262
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Целевое значение;
3
Возможные значения: 0-100
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
процент документов, не
пересматривавшихся в течение года {%
документов}
Проходили ли документы ежегодную проверку?
Должна быть указана периодичность проверки,
определенная в политике управления
документацией (год — средний срок).
Все документы должны пересматриваться и в
зависимости от того, актуальны ли они, либо
изменяться и помечаться как действительные,
либо удаляться.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет 5 3
0-100
Процент документов, не
использовавшихся в течение года {%
документов}
Документы, которыми долго не
пользовались. Неиспользуемые документы.
Точный срок зависит от политики управления
документацией, но неиспользуемые документы
должны периодически пересматриваться с
точки зрения их существенности и возможности
удаления.
Владелец процесса, руководство ИТ-отдела,
владелец
процесса SLA, члены команды, владелец
процесса SIP.
Нет
15
10
0-100
Число невыполненных запросов о
внесении изменений в документы
{запросы}
Документы, запросы об изменении которых не
были удовлетворены.
Q. Метрики для управления документацией
Спецификация:
263
Невыполненные
запросы
о
внесении
изменений в документ.
Запросы об изменении документов, доступ к
Обоснование:
которым закрыт или ограничен, должны
рассматриваться в соответствии с надлежащей
процедурой. Метрика характеризует работу
этого процесса.
Аудитория:
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Ограничения:
Опасное значение: Нет 10
Целевое значение: 5
999999
Возможные
значения:
Число документов, не удаленных после
окончания срока действия {документы}
Метрика:
Документы, которые должны были быть
удалены, но до сих пор существуют.
Описание:
Документы, присутствующие в системе после
истечения сроков их уничтожения.
Спецификация:
Продолжительность
жизни
документов
определяется политикой согласно требованиям
Обоснование:
закона и правилам безопасности.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
Аудитория:
владелец процесса SIP.
Нет 10
5
Ограничения:
999999
Опасное значение:
Целевое значение:
Число недокументированных SLA {SLA}
Возможные
SLA должны соответствовать требованиям,
значения:
обозначенным в политике компании.
SLA, в которых не хватает тех или иных
Метрика:
подкрепляющих документов.
Описание:
Требования к документации SLA должны быть
четко обозначены, что позволяет отсеивать всю
Спецификация:
ненужную
Обоснование:
264
Аудитория:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
информацию и оставлять только необходимые
разделы. Метрика проверяет, соблюдаются ли
эти требования во всех SLA.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Нет
5
Ограничения:
Опасное
2
значение:
Целевое
значение:
Возможные значения: 999999
Метрика:
Число неполных политик и планов по
управлению услугами {планы/политики}
Описание:
Планы, в которых отсутствуют обязательные
разделы или подписи.
Для
документов
этого
рода
должны
существовать стандартные шаблоны, так
чтобы
можно
было
подсчитать
число
недостающих разделов или подписей.
Данное требование должно соблюдаться во
всех
организациях,
где
контролируется
структура планов (аналогично SLA).
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет 5 2
999999
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Описание:
Спецификаци
я:
Число
несоответствий
между
отдельными планами и общим планом
по
управлению
услугами
{несоответствия}
Если централизованная подготовка всех
планов не позволяет достичь согласованности,
необходима ручная перекрестная проверка.
Планы должны быть взаимно согласованы и
отвечать политике организации. Метрика
выявляет любые несоответствия.
265
Q. Метрики для управления документацией
Обоснование:
Аудитория:
Залогом эффективности планов является
последовательность их исполнения.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет
10
Ограничения:
Опасное
5
значение:
Целевое
значение:
Возможные значения: 999999
Задача .метрики; обеспечить
безопасное щихся к поддержке других
процессов.
нение документов,
отно
Метрика:
Число инцидентов, относящихся к
ошибк в документации {инциденты}
Описание:
Подсчитывается по записям о закрытии
инцидентов и звонков в журнале регистрации.
Инциденты, которые согласно коду закрытия
связаны с ошибками в документации.
Процесс управления документацией должен
работать так, чтобы ошибки или неверные
сведения не приводили к инцидентам.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет
40 20
99999
9
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Задача метрики: обеспечение эффективности процессов
управления
Метрика:
Степень удовлетворенности клиентов
{удовлетворенность}
Описани
е:
Значение
показателя
удовлетворенности
клиентов для процесса (процессов), наиболее
тесно связанного (связанных) с данным.
266
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Степень
удовлетворенности
клиентов,
определенная
согласно
диаграмме
взаимоотношений процесса.
Субъективная, но истинная оценка результатов
работы процесса.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет
<3
4
0-5
___________________________________________________
R
Метрики компетентности,
осведомленности
и обучения (CAT)
Миссия; обеспечить достижение и поддержку намеченного уровня
обучения и осведомленности ИТ-персонала в соответствии с
требованиями ISO20000.
Владелец процесса: управление уровнем сервиса.
Задача метрики: добиться, чтобы все должности были заняты
работниками соответствующей квалификации.
Метрика:
Число действий, запланированных,
но не выполненных во время кампании
по повышению осведомленности
{действия}
Описание:
Спецификация:
и не
Невыполненные действия.
Действия, назначенные на определенную дату
Обоснование:
повы-
Аудитория:
владе-
выполненные на момент определения
значения показателя.
Обеспечивает контроль того, что кампания по
шению осведомленности проходит в
соответствии с планом.
Владелец процесса, руководство ИТ-отдела,
лец процесса SLA, члены команды, владелец
процесса SIP.
Ограничения:
Действия должны формально
документироваться.
Опасное значение:
10
268
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Целевое значение;
Возможные значения:
999999
5
Метрика:
Число должностных инструкций, в которых
не конкретизированы требования к
компетентности {должностные инструкции}
Описание:
Должностные инструкции для ИТ-персонала,
хранящиеся в отделе кадров или в CMDB, можно
связать с квалификациями модели SFIA (Skills
Framework for the Information Age —
квалификационная
структура
для
века
информатики). Метрика учитывает инструкции,
для которых такие связи отсутствуют.
Требования к компетентности нужно брать из
SFIA.
Согласно
ISO20000
сотрудники
должны
продемонстрировать специфические навыки,
необходимые для занятия тех или иных
должностей.
Владелец процесса, руководство ИТ, владелец
SLA, HR, члены команды, владелец SIP.
Нет 5 2
999999
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Задача метрики: обеспечить наличие квалифицированного
персонала.
Метрика:
Процент сотрудников ИТ-подразделения,
квалификация которых официально
признана в отрасли {% персонала}
Описание:
Эту
информацию
можно
найти
в
соответствующей матрице квалификации, где
есть данные об образовании и опыте работы.
Учитывается признание в авторитетных
организациях и обществах, объединяющих
специалистов
в
таких
областях,
как
управление проектами, услугами, теория
вычислительных систем и др., — член BSC
(British Computer Society), ISM (Institute of IT
Service Management) и т.д.
Членство в авторитетных организациях
свидетельствует об опытности старшего
персонала.
Спецификаци
я:
Обоснование:
R. Метрики компетентности, осведомленности и обучения (CAT)
Аудитория;
Ограничения:
Опасное
значение:
Целевое
значение:
269
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет
5 10
Возможные значения: 0-100
Метрика:
Средний процент недостаточности уровня
подготовки {% курсов}
Информация должна извлекаться из матрицы
квалификации.
Для сотрудника, который должен пройти N
Спецификация:
курсов обучения, а фактически прошел М
курсов, степень недостаточности подготовки
равна N - M/N х 100, а данная метрика
представляет собой среднее значение по ИТподразделению.
Обоснование:
Метрика дает общее представление о
недостатке
подготовки.
Соответствующие
планы обучения позволяют улучшить этот
показатель при условии не слишком высокого
Аудитория:
оттока персонала.
Владелец процесса, руководство ИТ, владелец
Ограничения:
SLA, HR, члены команды, владелец SIP.
Метрика не учитывает сотрудников, чья
квалификация выше, чем необходимо для их
работы, потому что они не компенсируют
Опасное значение:
недостатка квалификации у других.
Целевое значение: 10 5
Возможные
0-100
значения;
Описание:
Метрика:
Описание:
Спецификаци
я:
Процент сотрудников, имеющих
подписанный план индивидуального
развития
{% сотрудников}
Одобренные планы индивидуального развития.
Всем работникам необходимо иметь актуальные
подписанные планы индивидуального
развития, кото-
270
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
рые, чтобы учесть их с помощью данной
метрики, должны храниться в CMDB.
Благодаря планам развития персонал идет в
ногу
с
новейшими
достижениями,
компетентность поддерживается на высоком
уровне, а отток персонала — на низком.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP. Нет 90 95
999999
Метрика:
Процент сотрудников, не имеющих
формально определенной роли или сферы
ответственности {% сотрудников}
Описание:
Сотрудники, для которых не конкретизированы
роли и обязанности.
Роли и обязанности, определенные на уровне
организации, связаны с исполняющими их
сотрудниками. Метрика учитывает сотрудников,
у которых нет конкретных ролей или
обязанностей.
Когда сотрудника принимают на работу или
переводят на другую должность, определение
формальной роли и обязанностей может
показаться несущественной административной
деталью. Метрика помогает не потерять ее.
Если
у
сотрудника
нет
формально
определенной роли и обязанностей, то ни он
сам, ни руководство не в состоянии оценить,
насколько хорошо он справляется со своими
задачами. Это несправедливо и может
привести к снижению эффективности работы.
Владелец процесса, руководство ИТ, владелец
SLA, HR, члены команды, владелец SIP.
Нет 3 2
999999
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
R. Метрики компетентности, осведомленности и обучения (CAT)
271
Задача метрики: добиться, чтобы все должности были заняты
работниками, имеющими соответствующую подготовку.
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Процент ИТ-персонала с неоптимальным
для занимаемой должности уровнем
подготовки
{% персонала}
Источником данных для этой метрики может
быть информация об уровне подготовки,
учебных
планах
и
истории
обучения,
хранящаяся в CMDB (если она действительно
там хранится).
Для всех должностей, связанных со сферой
ИТ, должен быть задан оптимальный
уровень подготовки, а для каждого сотрудника
— составлен план
обучения.
Это позволит определить, оптимальна ли
подготовка.
IS020000 требует, чтобы персонал обладал
соответствующей квалификацией.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет
85 95
0100
Задача метрики: добиться, чтобы работники имели
соответствующую подготовку.
Метрика:
Процент сотрудников с уровнем
компетентное
ти, не удовлетворяющим минимальным
требо
ваниям {% сотрудников}
Описание:
Спецификаци
я:
Обоснование:
Информация из матрицы квалификации.
Метрика характеризует уровень подготовки, но
может быть улучшена за счет найма новых
сотрудников,
имеющих
требуемую
квалификацию.
Работники,
не
имеющие
достаточной
профессиональной подготовки для своей
должности, представляют угрозу для бизнеса.
272
Аудитория;
владе-
МЕТРИКИ для УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Владелец процесса, руководство ИТ-отдела,
лец процесса SLA, члены команды, владелец
процесса SIP.
Ограничения:
Нет
Опасное значение: 5
Целевое значение: 10
Возможные значения:
0-100
Задача метрики: обеспечить необходимую подготовку персонала.
Метрика:
Процент сотрудников, не выполнивших план
индивидуального развития {% сотрудников}
Описание:
но не
Действия, предусмотренные планом развития,
Спецификация:
инОбоснование:
действия,
Аудитория:
владе-
выполненные.
Чтобы такие действия можно было подсчитать,
формация о них должна храниться в CMDB.
Метрика помогает следить за тем, чтобы
обозначенные
в
планах
развития,
действительно
выполнялись.
Это
положительно сказывается на настроении
персонала.
Владелец процесса, руководство ИТ-отдела,
лец процесса SLA, члены команды, владелец
процесса SIP.
Ограничения:
Нет
Опасное значение:
15
Целевое значение:
10
Возможные значения: 999999
Задача метрики: поддержание в организации высокого уровня
осведомленности о проектах и достижениях ИТ.
Метрика:
организа-
Процент осведомленности в целом по
ции {% осведомленности}
Описание:
дан-
Спецификация:
регулярных
Осведомленность, о которой можно судить по
ным опросов и отдельных ответов в рамках
сценариев службы Service Desk.
Оценивается на основании результатов
выборочных опросов и ответов на вопросы службы
R. Метрики компетентности, осведомленности и обучения (CAT)
273
Service Desk. Когда проходит кампания по
повышению осведомленности, можно задавать
относящиеся к ней вопросы пользователям при
закрытии заявок, а затем подсчитывать
процент тех, кто имеет представление о ее
сути.
Используется
для
повышения
эффективности кампаний.
Обоснование:
ГГ-подразделение должно поддерживать связь с
организацией, это обеспечивает эффективность
взаимодействия.
Аудитория:
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Ограничения:
Опасное значение:
Нет
Целевое значение:
70 80
Возможные
0-
значения;
100
Задача метрики: обеспечить поддержание приемлемого уровня
компетентности персонала.
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное
Процент текучести кадров в сфере ИГ {%
персонала}
Сколько сотрудников уходят или приходят в течение
года.
Оценивается на основании данных отдела кадров
или частоте смены учетных записей на сервере.
Высокий
уровень
текучести
кадров
свидетельствует о низком моральном духе в
организации и о том, что компетентные сотрудники
в ней плохо задерживаются.
Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец
процесса SIP.
Нет
10
5
Целевое
Возможные значения: 999999
значение:
значение:
274
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Задача
обеспечить приемлемый уровень
метрики; новых профессионализма
сотрудников
Метрика:
Описание:
Спецификация
:
Число требований к персоналу,
которые не удалось удовлетворить
{требования}
Оценивается по информации отдела кадров.
Новые работники, вне зависимости от их
квалификации, не знакомы с организацией.
Даже
если
кадры
остаются
высококвалифицированными,
их
высокая
текучесть
означает
низкий
уровень
компетентности в организации. Метрика
оценивает сложность подбора компетентного
персонала. Требования могут оставаться
невыполненными из-за того, что руководство
не утвердило ставки, или потому, что не удалось
найти подходящего кандидата. В любом случае,
если
в
ИТ-подразделении
не
хватает
определенного
сотрудника,
уровень
Обоснование:
компетентности в нем ниже, чем следует.
Постоянно высокое значение показателя говорит
либо о большой текучести кадров, либо о
Аудитория:
недостаточном их наборе.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
Ограничения:
владелец процесса SIP.
Опасное значение:
Нет 7 4
Целевое значение:
999999
Возможные
значения:
s
Метрики
для управления программами
и проектами
Миссия; выполнять проекты и программы в соответствии со
стандартами, используя PRINCE2 или иную аналогичную
стандартную методику проектирования.
Владелец процесса: проектное бюро.
Задача метрики: соблюдать стандарты реализации проектов и
программ.
Метрика:
Число контрольных точек, не достигнутых
в срок {контрольные точки}
Описание:
Определяется на основании документации
проекта, имеющейся в хранилище документов —
• CMDB.
Спецификация:
Обоснование:
Число контрольных
текущем месяце.
точек,
пропущенных
Аудитория:
Проверяется, насколько точно
политика управления проектами.
значения:
9
в
соблюдается
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Ограничения:
Работа с документами должна вестись в рамках
Опасное значение: политики хранения документации.
1
2
Целевое значение:
99999
Возможные
276
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика:
Общее время задержки проекта в
текущем месяце {время}
Описание:
Определяется на основании документации
проекта, имеющейся в CMDB / хранилище
документов.
Насколько запаздывает проект —- соответствует
числу дней с пропущенными контрольными
точками в текущем месяце.
Необходимо обеспечить доступ к проектной
информации,
чтобы
понять
будущие
требования к изменениям и доступности.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса S1P.
Нет 5 2
999999
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Число спорных пунктов в проекте {пункты}
Описание:
Спецификация:
Спорные проблемные проекты.
Число новых проблемных пунктов, возникших в
проекте в текущем месяце. Рост их списка.
Во всяком проекте есть список проблемных
пунктов, и этот проект должен быть
управляемым. Метрика позволяет отслеживать
развитие таких списков, контролируя таким
образом само их наличие.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет 5 2
999999
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Число спорных пунктов проекта,
решенных в текущем месяце {пункты}
Описание:
Спецификаци
я:
Проблемы, решенные за истекший период.
Сокращение списка спорных пунктов.
S. Метрики для управления программами и проектами
Обоснование:
Аудитория:
Ограничения:
Опасное
значение:
Целевое
значение:
277
Показатель отражает решение проблем, и его
высокое значение говорит об эффективном
управлении проектом.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет
25
Возможные значения: 999999
Метрика:
Число выявленных рисков {риски}
Описание:
Если число выявленных рисков быстро растет,
то возможно, в дальнейшем в рамках проекта
предстоит столкнуться с трудностями.
Список рисков на текущий месяц.
Чем раньше получено предостережение о
потенциальных проблемах, тем проще их
своевременно решить.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP. Нет 10 6 999999
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Задержка критического пути {время}
Описание:
Спецификаци
я:
Показатель реального запаздывания проектов.
Суммарное запаздывание (в днях) всех
подпроектов относительно заданного для них
критического пути.
Необходимо, чтобы все критические пути были
должным образом заданы и задокументированы
(что уже хорошо), а задержки позволяли
объективное измерение.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Обоснование:
Аудитория:
278
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Ограничения:
Нет
Опасное
значение:
4
Целевое
значение:
2
Возможные
значения:
999999
Метрика:
Число эскалации {проблемы}
Описание:
Спецификация:
Степень сложности рабочей среды.
Проблемы рисков, эскалированные «наверх»
(«поднятые наверх» менеджером проекта).
Эскалация проблем, когда она необходима,
приветствуется, и такие случаи должны
учитываться. Метрика дает представление о
рисках, с которыми сталкиваются текущие
проекты.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP. Нет 5 1 999999
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Число несостоявшихся совещаний по проекту
{совещание}
Описание:
Спецификация:
Оценивается по данным хранилища
документов.
Число совещаний по проекту, которые были
просрочены более чем на один день в текущем
месяце.
Это, как правило, второстепенная проблема, но
неоднократный срыв сроков указывает на то,
что проекту недостает ресурсов или на
участников слишком сильно давят.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет 4 2
999999
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
S. Метрики для управления программами и проектами
279
Метрика:
Предполагаемая вероятность завершения
проекта к намеченному сроку в рамках
бюджета {% вероятности}
Описание:
Документированные прогнозы, находящиеся в
хранилище документов.
Насколько менеджер проекта уверен, что проект
будет завершен в срок и в рамках бюджета.
Прогнозы важны тем, что позволяют проверить
качество реализации проектов, а также улучшить
планирование в рамках процесса управления
мощностями.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Нет
70 80
0100
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
Метрика:
Число задач, сформулированных на
совещании по планированию проекта,
которые не были выполнены в срок {задачи}
Описание:
Действия, согласованные на совещании по
планированию проекта, которые остаются
невыполненными после оговоренного срока
завершения.
Действия с истекшей датой завершения и
статусом, отличным от «выполнено».
На возникновение сложностей, а также на
исчерпание ресурсов проекта в первую очередь
указывает то, что действия планируются,
однако затем не выполняются вовремя.
Метрика
позволяет
заметить
этот
предостерегающий признак на ранней стадии.
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, члены команды,
владелец процесса SIP.
Нет 10 5
999999
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Возможные
значения:
280
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Задача метрики; обеспечить эффективное выполнение процессов
управления услугами.
Метрика:
Описание:
Степень удовлетворенности
клиентов {удовлетворенность}
Оценивается при проверке проекта, однако
необходимо учесть также замечания по
поводу проектов, полученные службой Service
Desk.
Спецификация:
Удовлетворенность
клиентов
всеми
реализуемыми
проектами
и
программами.
Обоснование:
Проекты должны выполняться так, чтобы это
удовлетворяло пользователей и клиентов.
Аудитория:
Владелец процесса, руководство ИТ-отдела,
владелец процесса SLA, бизнес-клиент, члены
команды, владелец процесса SIP.
Ограничения:
Опасное значение: Нет
Целевое значение: <3
4 0Возможные
5
значения:
О библиотеке изданий
по управлению ИТ-услугами
Серия изданий, выходящих под общим названием ITSM Library,
посвящены передовому опыту управления ИТ и издаются по заказу
голландского отделения форума ITSMF — ITSMF Netherlands (ITSMFNL).
Форум по ИТ сервис-менеджменту (IT Service Management
Forum
-ITSMF)
является
ассоциацией
организаций,
предоставляющих ИТ-услуги, и заказчиков таких услуг. Цель ITSMF
— продвижение инноваций и содействие развитию управления ИТ.
В ITSMF равным образом представлены заказчики и поставщики.
Работа форума строится вокруг обмена знаниями и опытом между
коллегами. Наши авторы являются всемирно признанными
специалистами в своей области.
Следующие издания уже вышли или увидят свет в ближайшем
будущем.
Вводные курсы
• ИТ сервис-менеджмент. Вводный курс на основе ITIL
(Foundations of
IT Service Management based on ITIL / IT Service
Management, an
introduction — based on ITIL; на арабском, китайском, датском,
не
мецком, английском, французском, итальянском, японском,
корей
ском, голландском, португальском, русском и испанском
языках)
• IT Services Procurement, an introduction based on ISPL (на
английском и
голландском языках)
• Project Managemen based on Prince 2 (на голландском,
английском и
немецком языках)
IT Service Management best practices
• IT Service Management best practices Deel 1 (на голландском
языке)
• IT Service Management best practices Deel 2 (на голландском
языке)
• IT Service Management best practices, Deel 3 (на голландском
языке)
МЕТРИКИ для УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
282
Издания по отдельным темам
л управленческому инструментарию
1
• Метрики для управления ИТ-услугами (Metrics for IT Service
Management;
на английском и русском языках)
• Six Sigma for IT Management (на английском языке)
• De RfP voor IT-outsourcing — Management guide (на голландском
языке)
• Service Agreements — A Management Guide (на английском
языке)
• Frameworks for IT Management (на английском языке)
Карманные руководства
• 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 (на английском
языке)
Брукс Питер
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ
ИТ-УСЛУГАМИ
Технический редактор Н. Лисицына
Корректоры И. Баханова, В. Муратханов
Компьютерная верстка А. Абрамов
Художник обложки О. Белорус
Подписано в печать 10.10.2007. Формат 70x100
1/16.
Бумага офсетная № 1. Печать офсетная.
Объем 18,0 печ. л. Тираж 1100 экз. Заказ № 6744
Альпина Бизнес Букс
123060, Москва, а/я 28
Тел. (495) 980-5354
www.alpina.ru email: info@alpina.ru
Отпечатано в ОАО «ИПК «Ульяновский Дом
печати» 432980, г. Ульяновск, ул.
Гончарова, 14
Похожие документы
Выбор метрики для нечеткого поиска в структурированной
Выбор метрики для нечеткого поиска в структурированной
Оценка качества тестирования. - Тренинги «Intel Delta Course
Оценка качества тестирования. - Тренинги «Intel Delta Course
2. Как пользоваться
2. Как пользоваться
Скачать
реклама