Автор: Брукс П.
Теги: информационные технологии вычислительная техника обработка данных микропроцессоры менеджмент
ISBN: 978-5-9614-0647-4
Год: 2008
Текст
l/SMF International
The IT Service Management Forum
библиотека
IBS
Метрики
для управления
ИТ-услугами
Сделав доброе дело затратив труд на сканирование столь интересной книги.
Хотелось бы попросить помощи в поиске ряда очень необходимых мне книг, в
соответствии с представленным списком.
Благодарности можно размещать на сайте www.infonata.org. Всем заранее
респект за помощь
;-))
Л. Басс, П. Клементс, Р. Кацман Архитектура программного обеспечения на практике
Алистер Коберн Быстрая разработка программного обеспечения
Пер Кролл, Филипп Крачтен Rational Unified Process - это легко. Руководство по RUP для
практиков, пер. с англ.
Стефан Бергстрём, Лотта Роберт Книга Rational Unified Process - путь к успеху. Руководство по
внедрению RUP. Пер. с англ.
Бусыгин А.В. Эффективный менеджмент
Детмер У. Теория ограничений Голдратта: Системный подход к непрерывному совершенствованию
Эли Шрагенхайм Управленческие дилеммы: Теория ограничений в действии
Александров Л.В., Карпова Н.Н. Рабочая книга по систематизации информации. - М., 1993.
Акофф Р. Планирование в больших экономических системах ,-М.: Советское радио, 1972. - 223 с.
Аккоф Р., Арнольд Л., Черчмен У. Введение в исследование операций. - М.: 1977.
Акофф Р. Райветт П. Исследование операций. Пособие для административно-управленческих
работников. - М. Мир. 1988. - 144 с.
Акофф Р., Магидсон Д., Эддисон Г.Д. Идеализированное проектирование: Как предотвратить
завтрашний кризис сегодня. - М.; Баланс Бизнес Букс, 2007.
Белов П.Г. Системный анализ и моделирование опасных процессов в техносфере: учебное пособие
для вузов. - М.: Academia, 2003. - 505 с.
Бир Стаффорд. Кибернетика и менеджмент. - М.: КомКнига, 2006. - 265 с.
Бир Стаффорд. Наука управления. ЛКИ, 2007. - 120 с.
Большие системы. Теория, методология, моделирование / Под общ. Ред. Б.В.Гнеденко. - М.:
Наука, 1971. - 320 с.
Блаумберг И.В. Проблема целостности и системный подход. - М.: Эдиториал УРСС, 1997. - 440 с.
Бондаренко Н.И. Методология системного подхода к решению проблем: история, теория,
практика. - СПб: Изд-во Санкт-Петербургского ун-та экономики и финансов, 1997. - 388 с.
Бондаренко М.Ф., Соловьева Е.А., Маторин С.И. Основы системологии. - Харьков: ХТУРЭ, 1998.
- 118 с.
Бурков В.Н. Сетевые модели и задачи управления. - М.: Сов. Радио, 1967.
Васильев В.И., Романов Л.Г., Червонный А.А. Основы теории систем: Конспект лекций. - М.:
МГТУ ГА, 1994. - 104 с.
Вишанский Г. Системотехника (введение в проектирование автоматизированных систем
обработки и информации и управления). - М.: Москва, 2003. - 634с.
Волкова В.Н. Концепции современного естествознания: Учебное пособие. - СПб.: Изд-во СПбГТУ,
2006. - 200 с.
Волкова В.Н., Денисов А.А. Основы теории систем и системного анализа. - СПб.: СПбГТУ, 1997. -
510 с.
Волкова В.Н., Денисов А.А. Теория систем: Учебник для студентов вузов. - М.: Высшая школа,
2006. - 511 с.
Волкова В.Н., Денисов А.А., Темников Ф.Е. Методы формализованного представления систем:
Уч. пособие. - СПб.: Изд-во СПбГТУ, 1993. - 107 с
Волкова В. Н. Искусство формализации: От математики - к теории систем, и от теории систем - к
математике. СПб.: Изд-во СПбГТУ, 1999. - Изд- 2.е. СПб.: Изд-во СП6ГПУ, 2004. - 200 с.
Вопросы анализа и процедуры принятия решений. - М.: Мир, 1975.
Гараедаги Д. Системное мышление. Как управлять хаосом и сложными процессами. Платформа
для моделирования архитектуры бизнеса. - Гревцов Паблишер, Минск, 2007. - 480 с.
Гвишиани Д.П. Организация и управление. - М.: Наука, 1972.
Герман И.М., Шухов Н.С., Сергеев А.А. Системный подход в управлении экономикой:
Методологические аспекты. Саратов: Издательство Саратовского университета, 1991. -133с.
Голубков Е.П. Системный анализ в управлении народным хозяйством. - М.: МИНХ, 1975.
Голубков Е.П. Использование системного анализа в отраслевом планировании. - М.: Экономика,
1977.
Голубков Е.П. Технология принятия управленческих решений. - М.: ДиС, 2005. - 544 с.
Горохов В. Г. Методологический анализ системотехники: научное издание. - М.: Радио и связь,
1982. - 157 с.
Губанов В.А., Захаров В.В., Коваленко А.Н. Введение в системный анализ: Учебное пособие. -
Л.: Изд-во Ленинградского ун-та, 1988. - 232 с.
Гутштейн А.И Управление промышленным предприятием и кибернетика. - М.: Экономика. 1968.
Джонс Дж.К. Методы проектирования. - М.: Мир, 1986. -326 с.
Дегтярев Ю.И. Системный анализ и исследование операций -М.: Высш.шк. 1996. -335 с.
Денисов А.А. Современные проблемы системного анализа: Информационные основы: Учебное
пособие. - СПб: Изд-во СПбГТУ, 2005. - 295 с.
Денисов А.А., Колесников Д.Н. Теория больших систем управления: Учебное пособие для
студентов вузов. - Л.: Энергоиздат, 1982. - 288 с
Денисов А.А., Волкова В.Н. Иерархические системы: Учебное пособие. - Л.: ЛПИ, 1989. - 88 с.
Диксон Дж. Проектирование систем: изобретательство, анализ, принятие решений. М.: Мир, 1969.
Дрогобыцкий И.Н. Системный анализ в экономике. - М.: Финансы и статистика, 2007. - 512 с.
Дружинин В.В., Конторов Д.С. Проблемы системологии (проблемы теории сложных систем). - М.:
Советское Радио, 1976. - 296 с.
Дружинин В.В., Конторов Д.С. Системотехника. - М.: Радио и связь, 1985. - 200 с.
Думлер С.А. Управление производством и кибернетика. - М.: Машиностроение, 1969. - 424 с.
Думлер С.А. Автоматизированные системы управления промышленным предприятием. - М.:
Экономика, 1966.
Жилин Д.М. Теория систем: опыт построения курса. - М.: Едиториал УРСС, 2004. - 184 с.
Исследование операций. Методологические основы и математические методы: В 2-х т.
/Под ред. Дж. Моудера и С. Элмаграби. М.: Мир, 1981.
Исследования по общей теории систем / Пер, с англ. Под общ. Ред. В.Н.Садовского и
Э.Г.Юдина,- М.: Прогресс, 1969. К
Калман Р., Фалб П., Арбиб М. Очерки по математической теории систем: пер. с англ./под ред.
Я.З. Цыпкина - М.: Едиториал УРСС, 2004. - 400 с.
Карташев В.А. Система систем. Очерки общей теории и методологии. - М.: Прогресс-академия,
1995. - 416 с.
Качала В.В. Основы системного анализа: Учебное пособие. - Мурманск: Изд-во МГТУ, 2004. - 104
с.
Качала В.В. Основы теории систем и системного анализа М.: Горячая линия -Телеком, 2007. - 216
с.
Кулагин О.А. Принятие решений в организациях. - СПб.: Сентябрь, 2001. - 148 с.
Козлов В.Н. Системный анализ и принятие решений: Учебное пособие. - СПб.: Изд-во СПбГТУ,
2000. - 190 с.
Конторов Д. С. Внимание - системотехника. - М.: Радио и связь, 1993. - 223 с.
Кофман А. Методы и модели исследования операций. - М.: Мир, 1966.
Кофман А., Фор Р. Займемся исследованием операций. - М.: Мир, 1966.
Крайнюченко И.В. Системное мировоззрение. Теория и анализ. - Пятигорск: Изд-во ИНЭУ, 2005. -
222с.
Лагоша Б.А., Емельянов А.А. Введение в системный анализ. - М.: Изд-во МЭСИ, 1998.
Лаукс Г., Лирманн Ф. Основы организации: управление принятием решений - М.: ДиС, 2006 - 600
с.
Лернер А.Я. Начала кибернетики. - М.: Наука, 1967. - 400 с.
Липаев В.В. Системное проектирование сложных программных средств для информационных
систем. -М.: Синтег, 2002. -268 с.
Локтионов М.В. Системный подход в менеджменте. 2001. - 288 с.
Лопухин М.М. Паттерн - метод планирования и прогнозирования научных работ. - М.: Советское
радио, 1971.
Льноградский Л.А. Горизонты системного анализа. - Самара: ИЭКА «Поволжье», 2000. - 244 с.
Льноградский Л.А. Концепция системного проектирования. - Самара: Изд-во Самарского гос. тех.
ун-та, 2005. - 180 с.
Лэсдон Л.С. Оптимизация больших систем. - М.: Наука, 1975.
Лямец В.И., Тевяшев А.Д. Системный анализ. - Харьков: ХТУРЭ, 1998. - 252 с.
Малиновская Е.В. Использование системного анализа в экономике. - М.: Экономика, 1974.
Малышевский А.В. Качественные модели в теории сложных систем. -М.: Физматлит, 1998. -528 с.
Мангейм М.Л. Иерархические структуры. М., «Мир», 1970.
С.В. Емельянова. - М.: Мир, 1987.
Методология общей теории систем / А.М. Иванов, В.П. Петров, И.С. Сидоров и др. - СПб.:
Научная мысль, 2005. - 480 с.
Моисеев Н.Н. Математические задачи системного анализа. - М.: Наука, 1981. - 488 с.
Молотков Ю.И. Системное управление социально-экономическими объектами и процессами. - М.:
Наука.
Миллер Р.В. ПЕРТ - система управления. - М.: Экономика, 1965.
Мильнер Б.З. Организация программно-целевого управления. - М.: Наука 1980. - 376 с.
Мильнер Б.З., Евенко Л.И., Рапопорт В.С. Системный подход к организации управления. М.:
Экономика, 1983. - 224 с.
Мильнер Б.З. Системный подход к организации управления. Организация управления,- М.: ИНФРА-
М, 2002.
Мушик Э., Мюллер П. Методы принятия технических решений. -М.: Мир, 1990. -206 с.Н
Надеев А.Т. Систематика. Книга 1. Концепция систематики. Книга 2. Пространства. - Нижний
Новгород: Изд-во Волго-Вятской академии государственной службы, 1996. - 244 с.
Николаев В.И., Брук В.М. Системотехника: методы и приложения. - Л.: Машиностроение, 1985. -
199
Никаноров С.П., Никитина Н.К., Теслинов А.Г. Введение в концептуальное проектирование
АСУ: анализ и синтез структур. - М.: Ракетные войска стратегического назначения, 1995,- 234с.
Новые принципы государственного управления в США - М.: НИИ Госплана СССР, 1967.0
Общая теория систем / А.М. Иванов, В.П. Петров, И.С. Сидоров, К.А. Козлов. - СПб.: Научная
мысль, 2005. - 480 с.
Острейковский В.А. Теория систем: Учебник для вузов. - М.: Высшая школа, 1997. - 240 с.П
Прангишвили И.В. Научные основы построения АСУ ТП сложных энергетических систем. -М.:
Наука 1992 -231 с.
Прангишвили И.В. Энтропийные и другие системные закономерности: Вопросы управления
сложными системами. - М.: Наука, 2003. - 428 с.
Прангишвили И.В. Системный подход и повышение эффективности управления. -М.: Наука, 2005.
- 420с.
Радвик Б. Военное планирование и анализ систем. М., Воениздат, 1972.
Радченко А.И. Основы государственного и муниципального управления. Системный подход. ИКЦ
Март, 2007. - 608 с.
Райзберг Б.А., Голубков Е.П., Пекарский Л.С. Системный подход в перспективном
планировании. - М.: Экономика, 1975.
Раскин Л.Г. Анализ сложных систем и элементы теории оптимального управления. - М.: Сов. Радио
1976. - 343с.
Рейльян Я.Р. Аналитическая основа принятия управленческих решений. М. Финансы и статистика,
1989.
Рейнгольд Л.А. Структурирование информации: системный подход, Наука, 2004,
Рыков А.С. Модели и методы системного анализа: принятие решений и оптимизация: учебное
пособие. — М. : Изд-во МИСиС : Руда и металлы, 2005. — 352 с.
Саратовский В.Н. Основы систематизации всеобщих категорий, 1973.
Садовский В.Н. Основания общей теории систем. Логико-методологический анализ. - М.: Наука,
1974. - 279 с.
Северцев Н.А., Дедков В.К. Системный анализ и моделирование безопасности : учебное
пособие. — М. : Высшая школа, 2006. — 463 с.
Семечкин А. Системный анализ и системотехника , 2005. - 536 с.
Системный анализ и принятие решений: Словарь-справочник: Учебное посо-бие для вузов /
Под ред. В.Н. Волковой, В.Н. Козлова. - М.: Высш, шк., 2004. - 616 с.
Системный анализ и структуры управления / Под ред. В.Г. Шорина. - М.: Знание, 1975. - 303
с.
Системный подход в современной науке (к 100-летию Людвига фон Берталанфи). - М.:
Прогресс-Традиция, 2004. - 560 с.
Спиди К., Браун Р., Гудвин Дж. Теория управления. Идентификация и оптимальное управление.
-М.: Мир, 1973.- 247 с.
Старр М.К. Управление производством. - М.: Прогресс, 1968. Теория систем и методы
системного анализа в управлении и связи / В.Н. Волкова, В.А. Воронков, А.А. Денисов и др. -
М.: Радио и связь, 1983. - 248 с.
Уилсон А., Уилсон М. Управление и творчество при проектировании систем. Пер. с англ. - М.:
Сов. Радио, 1976 - 256 с.
Флейшман Б.С. Элементы теории потенциальной эффективности сложных систем. - М.:
Советское радио, 1971. - 225 с.
Флейшман Б.С. Основы системологии. - М.: Радио и связь, 1982. - 272 с.
Форрестер Дж. Мировая динамика. М., 1978. 169 с.
Формирование технических объектов на основе системного анализа: производственно-
практическое издание /В. Е. Руднев [и др.]. - М.: Машиностроение, 1991. - 317 с.
Хитч Ч. Руководство обороной. Основы принятия решений М., «Советское радио» 1968. -105 с.
Хитч Ч., Маккии Р. Военная экономика в ядерный век. М.: Воениздат 1964. - 258 с.
Хомяков П.М. Системный анализ: краткий курс лекций/Под ред. В.П. Прохорова - М.: КомКнига,
2006. - 216 с.
Хорафас Д. Системы и моделирование. - М.: Мир, 1967.
Цвиркун А.Д. Структура сложных систем. - М.: Сов. Радио, 1975. - 193 с.
Черников Ю.Г. Системный анализ и исследование операций : учебное пособие. — М. : Изд-во
МГГУ, 2006. — 376 с. : ил.
Шумский А. А., Шелупанов А. А. Системный анализ в защите информации: Учебное пособие
для вузов. - М.: Гелиос АРВ, 2005. - 220 с.
Эддоус М., Стенсфилд Р. Методы принятия решений, - М.; Аудит, ЮНИТИ, 1997. - 590 с.
Эйрес Р. Научно-техническое прогнозирование и долгосрочное планирование. - М.: Мир, 1971.
Пи^ер Брукс
Метрики
для управления
ИТ-услугами
Peter Brooks
Metrics
for IT Service
Management
Van Haren Publishing
Питер Брукс
Метрики
для управления
ИТ-услугами
Москва
2008
УДК
ББК
004
32.97
Б89
Издано при содействии IBS
Переводчик В. Первушина
Научные редакторы А. Белей, И. Копасов,
О. Чернова, В. Губер д Аболенцев
Редактор М. Суханова
Брукс П.
Б89 Метрики для управления ИТ-усдугами / Питер Брукс; Пер. с англ. —
М.: Альпина Бизнес Букс, 2008. —. ^83 с
ISBN 978-5-9614-0647-4
Книга, адресованная в первую очер>ЬдЬ ИТ-директорам, представляет собой
общее руководство по проектирование и реализации метрик для сервисных
ИТ-подразделений, работающих по стч^дартам отрасли. Автор берет за основу
структуру процессов ITIL и опирается род принципов, сформулированных в
ITIL и стандарте IS020000 (BS15000.), Большое место отводится типичным
проблемам, связанным с правильным применением метрик, и возможным
путям их решения. Даются конкретные рекомендации по применению метрик
в процессах ITIL, IS020000 (BS15000) и другИХ. Приводимые в книге метрики
могут быть использованы и непосредстй£ННО, и в качестве отправной точки для
создания набора, отвечающего специфе>ческим потребностям организации.
УДК 004
ББК 32.97
Все права защищены. Никакая часть
этой книги не может быть воспро-
изведена в какой бы то ни было форме
и какими бы то ни было средствами
без письменного разрешения владель-
ца авторских прав.
ISBN 978-5-9614-0647-4 (рус.)
ISBN 90-77212-69-8 (англ.)
© ITSMF, 2006
© Издание на русском языке,
перевод, оформление.
ООО «Альпина Бизнес Букс», 2008
Оглавление
Предисловие к русскому изданию.............................9
Введение...................................................11
1. Что такое метрики?....................................13
1.1. Задачи...........................................13
1.2. Связь ИТ и бизнеса...............................14
1.3. Почему метрики — это не SLA 20
1.4. Метрики и KPI....................................21
1.5. Метрики и бенчмаркинг............................22
2. Зачем нужны метрики?..................................25
2.1. Метрики как инструмент .. 26
2.2. Метрики как средство управления..................27
2.3. Метрики и инновации..............................29
2.4. Затраты..........................................30
2.5. Преимущества метрик 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. Зачем разрабатывать метрики..................49
6.2. Принципы.....................................50
6.4. Разработка отдельных метрик..................56
6.5. Разработка интегрированных наборов метрик....57
6.6. Примеры хороших и плохих метрик..............58
7. Создание метрик на практике.......................61
8. Специфические метрики для управления
ИТ-услугами..........................................75
9. Интеграция метрик.................................93
10. Реализация метрик.................................99
11. Постоянное совершенствование
с помощью метрик.....................................115
А. Метрики для управления инцидентами...............119
В. Метрики службы Service Desk......................129
С. Метрики для управления конфигурациями............139
D. Метрики для управления изменениями...............145
Е. Метрики для управления релизами..................153
Е.1. Метрики для поддержки приложений............159
Е.2. Метрики для разработки приложений...........163
F. Метрики для управления операциями/
инфраструктурой ИКТ..............................169
G. Метрики для управления уровнем сервиса...........175
Н. Метрики для управления проблемами................183
I. Метрики управления финансами для ИТ-услуг........193
Оглавление
7
J. Метрики для управления мощностями................199
К. Метрики управления непрерывностью предоставления
ИТ-услуг (IT Service Continuity — ITSC)..........207
L. Метрики управления доступностью..................215
М. Метрики для управления
информационной безопасностью.....................225
N. Метрики для бизнес-планирования..................233
N.I. Управление взаимоотношениями с бизнесом.....235
N.2. Управление взаимоотношениями с поставщиками.236
N.3. Управление поставкой услуг..................239
N.4. Планирование, анализ и развитие.............241
N.5 Взаимодействие, обучение и информирование....242
О. Метрики для постоянно действующей
программы по улучшению услуг (SIP) ..............245
Р. Метрики для управления рисками...................253
Q. Метрики для управления документацией.............261
R. Метрики компетентности, осведомленности
и обучения (CAT).................................267
S. Метрики для управления программами
и проектами......................................275
О библиотеке изданий по управлению ИТ-услугами.......281
Предисловие
к русскому изданию
В настоящее время принципы управления уровнем сервиса уже широко ис-
пользуются во всем мире и стали стандартом де-факто для многих россий-
ских предприятий. Опыт компании IBS показывает, что все чаще и чаще от
задачи простой автоматизации приема заявок от пользователей ИТ-службы
переходят к полноценной организации своих процессов, реальному выстраи-
ванию отношений с бизнес-подразделениями на сервисных принципах, по-
вышению качества услуг.
Однако необходимо учитывать известный факт — нельзя улучшить то,
что нельзя измерить!
Универсальное правило, применимое ко всем сферам деятельности: об-
ратная связь в различных процессах базируется на результатах измерений.
Деятельность ИТ-службы не является исключением и также должна оцени-
ваться объективными измеряемыми параметрами. Вот только что это за
параметры, сколько их должно быть, как часто их измерять, каковы в общем
критерии выбора параметров оценки деятельности ИТ-службы?
Во-первых, они должны быть конкретными, а не абстрактными. Во-вто-
рых, их не должно быть очень много, но их количество должно быть доста-
точным. В-третьих, их выбор должен основываться на целях и задачах,
стоящих перед всей компанией и перед ИТ-службой. В-четвертых, они долж-
ны быть для сотрудников мотивирующим фактором, отражающим качество
их деятельности.
Неоценимую помощь в непростом выборе таких показателей окажет чи-
тателю эта замечательная книга, вышедшая в серии «Библиотека IBS».
С одной стороны, это довольно подробный и обширный справочник
с перечнем метрик и детальными разъяснениями. С другой стороны, это еще
и руководство к действию с большим количеством примеров из реальной
деятельности. Книга «Метрики для управления ИТ-услугами» не просто мето-
дическое пособие по выбору метрик, она может служить источником полез-
10
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
ных идей. Хочется надеяться, что читатель не только ознакомится с ней на
этапе создания своей системы оценки, но и будет время от времени возвра-
щаться к ней, чтобы переосмыслить существующий набор КР1, взглянуть на
ситуацию с разных сторон и точек зрения.
Вас не должен пугать большой список метрик. Все их контролировать
сложно, да и не нужно. Достаточно определиться с перечнем, актуальным
для данной компании в данное время. Не нужно ждать, когда определится
идеальный набор метрик для контроля, —- его составить невозможно. Более
того, набор метрик не является постоянным. Время идет, меняется компания,
меняются цели («чтобы двигаться, надо бежать в два раза быстрее»), меня-
ется набор KPI.
Но мы уже забегаем вперед, не будем пересказывать книгу...
Петр Дубенсков,
заместитель директора департамента системных решений IBS
Введение
Организации, предоставляющие ИТ-услуги, все более ориентируются в сво-
ей работе на стандарты качества и управления ИТ-услугами. В числе наибо-
лее популярных стандартов для руководства — управление ИТ-услугами,
качеством и различными аспектами операционной деятельности.
В этой книге рассматривается разработка и внедрение метрик в органи-
зациях, занимающихся предоставлением услуг и применяющих один или
несколько из перечисленных стандартов. В качестве основы используется
структура процессов ITIL, а также многие принципы ITIL и IS020000 (перво-
начально BS15000 в Великобритании). Книга является общим руководством
по применению метрик в качестве контролирующего и направляющего ме-
ханизма для управления ИТ-услугами.
Внедрение управления ИТ-услугами как ряда строго определенных и тес-
но взаимосвязанных процессов позволяет сформировать целостный подход,
охватывающий все множество дисциплин, присутствующих в современном
ИТ-отделе.
Тысячи компаний со всего мира взяли за образец этот целостный подход,
и результаты превзошли все ожидания. ITSMF — это действующая во многих
странах мира независимая организация по поддержке управления ИТ-услу-
гами. Она проводит разнообразную работу по улучшению практического
применения ITIL за счет обмена знаниями и опытом. В рамках этой деятель-
ности организуются мероприятия и издаются книги.
Во всех описаниях процессов в ITIL есть раздел, посвященный возмож-
ным метрикам, что дает превосходную основу для создания системы пока-
зателей. Так, в томе ITIL, посвященном планированию управления услуга-
ми (Planning to Implement Service Management), есть глава, посвященная
KPI (Key Performance Indicators, ключевые показатели эффективности).
В этом руководстве рассматривается конкретно реализация метрик в кон-
тексте схемы управления ИТ-услугами с особым упором на ITIL.
12
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Главной причиной для написания этой книги послужило неумение многих
организаций правильно использовать метрики. В этом пособии вы найдете
анализ трудностей, возникающих при разработке метрик, и реальные реше-
ния.
Книга является общим руководством по проектированию, внедрению и
использованию метрик в качестве механизма, контролирующего и направ-
ляющего управление ИТ-услугами. В ней также содержатся конкретные ре-
комендации по применению метрик для процессов ГПЬ, IS020000 и других,
обсуждается обоснование этих рекомендаций. Это позволит организации
внедрить метрики непосредственно в том виде, в каком они здесь описаны,
в качестве первичного решения, а затем провести их бенчмаркинг путем
сравнения с показателями других организаций. Но можно использовать
предложенные решения и в качестве отправной точки для модификации
определенных метрик применительно к своим требованиям.
Плохо спроектированные метрики могут активно мешать правильному
функционированию организации, а создать такой их набор, который бы
позволил избежать подводных камней и принести реальную пользу, нелегко.
Книга сделает эту работу более простой и менее подверженной ошибкам.
Книга предназначена для менеджеров, управляющих предоставлением
ИТ-услуг, владельцев процессов, консультантов, руководителей ИТ-подразде-
лений и всех тех, кто интересуется метриками для управления ИТ-услугами.
В команду рецензентов вошли эксперты со всего мира. Их многолетний
коллективный опыт работы в сфере ИТ и предоставления услуг значительно
обогатил эту книгу. Вы можете полагаться на нее как на руководство, обоб-
щающее лучший опыт в данной области.
_______________1
Что такое метрики?
Метрика — просто другое название меры. В информационных
технологиях (ИТ) этот термин приобрел несколько различных
более конкретных смыслов И хотя эта книга посвящена метри-
кам как таковым, важно помнить, почему мы ими пользуемся.
Измерение ради измерения — дорогая и бессмысленная забава,
и метрики — не самоцель, а важная часть системы управления,
направляющей и контролирующей работу ИТ-подразделения.
Они, как мы впоследствии убедимся, должны разрабатываться
согласно требованиям клиентов и тестироваться на предмет
возможности реализации, а для выработанных параметров не-
обходим мониторинг, позволяющий контролировать их соот-
ветствие заданным пороговым значениям и исправлять возни-
кающие проблемы. Создаю е метрик—одна из задач программы
непрерывного улучшения качества обслуживания (Continuous
Service Improvement Programme — SIP): по мере постепенного
совершенствования процессов и служб должны меняться и мет-
рики для их оценки. Важно понимать, какие задачи ставит пе-
ред собой бизнес, и согласовывать с ними процессы измерения,
мониторинга и контроля. А о том, как это сделать, рассказыва-
ется в первой главе.
1.1. Задачи
Цели или задачи использования метрик в управлении ИТ-услуга-
ми (IT Service Management — ITSM) таковы.
1. Согласовывать деятельность ИТ-подразделения с зада-
чами бизнеса:
14
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
• обеспечить учет ИТ-процессов и результатов ИТ-операций;
• информировать участников бизнеса о процессах ITSM;
• помогать участникам бизнеса разобраться в вопросах производитель-
ности и специфических сложностях ИТ.
2. Добиваться соответствия требованиям, предъявляемым к коммер-
ческим операциям:
• стратегически направлять ИТ-операции;
• помогать в прохождении аттестации по стандартам IS0200001,
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) и т. п.
Чрезвычайный план — предопределенный план действий в аварийных ситуациях, включа
ющий процедуры резервного копирования и подготовку резервного оборудования для
преодоления чрезвычайной ситуации. — Прим. пер.
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
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
выявлению этих инцидентов до того, как они перерастут в непоправимые
труднос.и
Для правления важны и хорошие новости. Их можно распространять как
внутри, так и за пределами компании с целью улучшения ее репутации. Так,
например, аттестация по стандарту IS020000 — прекрасный повод с гордос-
тью заявить об этом достижении.
Другие заинтересованные стороны: правительство и акционеры
Несмотря на то что правительство и акционеры важны для компании, от-
ветственность за общение с ними несет правление. Если у ИТ-подразделения
есть информация, способная их успокоить или, наоборот, о чем-то предуп-
редить, эти данные необходимо сначала передать правлению, и уже оно
выберет подходящий канал и способ коммуникации.
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.
Таким образом, вся цепочка
Требование
клиента
-^SLA-^ OLA/UC-+* CSF- +-KPI-+*
Ежемесячный
отчет
вытекает непосредственно из требований клиента, и 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. ЧТО ТАКОЕ МЕТРИКИ?
23
только для вашей организации, ответит на этот вопрос невозможно! Кроме
вас, вашими метриками никто не пользуется, поэтому нужно самостоятель-
но определить допустимые значения.
Существуют два подхода к решению данной проблемы. Некоторые иссле-
довательские организации создали перечни стандартных метрик, где приво-
дятся средние результаты для многих фирм. Воспользовавшись теми же
стандартными метриками, можно определить уровень организации относи-
тельно среднего.
Другой подход состоит в использовании либо стандартного набора мет-
рик, либо модифицированного, как в настоящей книге. Тогда вы сможете
непосредственно сравнить собственные метрики с другими организациями,
применяющими те же самые или очень похожие критерии.
Возможен также смешанный подход. Если вы реализовали собственные
метрики, а кроме того проводите измерения в соответствии с двумя-тремя
опубликованными исследовательскими критериями, то сравнение последних
с точкой отсчета поможет увидеть вашу организацию со стороны и оценить
эффективность процессов.
Если, к примеру, согласно исследовательским метрикам показатели вашей органи-
зации составляют 95 и 115% от среднего, вы можете пропорционально установить
для других метрик требуемые значения, попадающие в тот же диапазон. В будущем
когда ваши показатели составят 120-130% от установленного контрольного значе-
ния, можно будет обоснованно предположить, что вы находитесь примерно на этом
уровне относительно организаций, служивших точкой отсчета.
Метод, описанный в данной книге, — применение более или менее стан-
дартного набора метрик во всех процессах — допускает и третий подход.
Можно сравнивать процессы между собой. Как правило, внедрение ITIL про-
исходит поэтапно, поэтому если взвешенные цели прочно установившегося
процесса — например, управления изменениями, — достигаются в среднем
на 130%, то можно задать первоначальную точку отсчета для нового процес-
са, так чтобы средневзвешенный результат составил, скажем, 80%. Это поз-
волит затем оценивать совершенствование процессов и определять, сколько
времени требуется процессу, чтобы сравняться с уровнем управления изме-
нениями.
2
Зачем нужны
метрики?
— Чеширский Мурлыка... — заговорила Алиса несмело, — она
не знала, понравится ли ему такое обращение.
Кот в ответ улыбнулся еще шире.
«Значит, не сердится»,— подумала Алиса и продолжала:
— Скажите, пожалуйста, куда мне отсюда идти?
— Это во многом зависит от того, куда ты хочешь прий-
ти, — ответил Кот.
— Да мне почти все равно, — начала Алиса.
— Тогда все равно, куда идти, — сказал Кот.
— Лишь бы попасть куда-нибудь, — пояснила Алиса.
— Не беспокойся, куда-нибудь ты обязательно попадешь, —
сказал Кот, — конечно, если не остановишься на полпути.
Льюис Кэрролл. «Алиса в Стране Чудес»1
Каждый день во многих наших делах мы полагаемся на мет-
рики, даже не задумываясь об этом. Очень важно держать их в
поле зрения, иначе есть опасность окончательно потерять ори-
ентиры. Если вы знаете, к чему стремитесь, то можете опреде-
лить, за чем необходимо следить, чтобы оценить свое продвиже-
ние к цели. Правда, получив в распоряжение механизм со мно-
жеством различных инструментов, легко поддаться соблазну и
увлечься инструментами вместо той работы, для которой пред-
назначен механизм.
1 Перевод Бориса Заходера.
26
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Если же нам, как Алисе, все равно, куда идти, то совершенно не важно,
что мы измеряем Даже вообще не оценивая свое продвижение, мы все рав-
но куда-нибудь попадем. Но скорее всего не туда, куда нужно!
2.1. Метрики как инструмент
Спидометр автомобиля или самолета является наглядным примером ис-
пользования метрик: он дает нам меру того, насколько быстро движется
водитель или пилот. Зная его показания и предельную скорость, человек
всегда будет осведомлен о том, что перемещается слишком быстро и, следо-
вательно, должен притормозить или сбросить газ.
Однако в подобных измерениях не было никакой необходимости до по-
явления быстрых автомобилей и радаров, контролирующих скорость движе-
ния. Чтобы оценить быстроту езды, вполне хватало развевающихся на ветру
волос и заносов на поворотах.
Намного более важным измерительным инструментом с самых ранних
пор был указатель расхода топлива, особенно в самолетах. Если в автомо-
биле кончится бензин, вам придется либо пройтись, либо, если вы подго-
товились заранее, наполнить бак из запасной канистры (что опасно).
В самолете выбора нет вообще, поэтому точный индикатор топлива еще
нужнее.
На языке метрик запас топлива, достаточный, чтобы добраться до пункта
назначения, — это критический фактор успеха (CSF), а инструменты (мет-
рики) для его оценки — ключевые показатели эффективности (KPI). Их
число должно быть умеренным, иначе вы не сможете сосредоточиться на
вождении или пилотировании. Так что указатель расхода топлива, как уже
было сказано, — вероятно, ваш главный KPI.
Вторым, не сильно отстающим по значимости, будет индикатор уровня
масла, потому что при низких значениях этого уровня двигатель может за-
клинить. Однако в наше время эти инструменты хотя и важны, но обычно
настолько надежны, что нам хватает их одних, чтобы узнать, когда следует
дозаправиться и когда возникнет опасность перегрева.
С помощью этих метрик легко понять, как работает модель процесса.
Представьте себе спидометр. Входные данные поступают с датчика на коле-
се. Выходные данные — это показания стрелки на табло. За промежуточные
операции или сам процесс отвечает зубчатая передача (или электронная
схема) в спидометре, преобразующая входную информацию с датчика — пе-
риод одного оборота — в выходные данные — скорость.
Целевой уровень, т. е. значение, которого мы хотим добиться, не является
постоянной величиной. К примеру, он будет разным на автомагистрали и на
сельской дороге, значение, оптимальное с точки зрения возможностей дви-
гателя, может оказаться неприемлемым из-за действующих ограничений
скорости и т.д.
Глава 2. ЗАЧЕМ НУЖНЫ МЕТРИКИ?
27
Спидометр и одометр (счетчик расстояния) менее существенны для функ-
ционирования транспортного средства, зато важнее для поездки. Зная рас-
стояние и назначенное время прибытия, мы в состоянии регулировать ско-
рость в зависимости от пройденной дистанции. Если в запасе много времени,
можно даже делать остановки, чтобы, отдохнув, более внимательно (а значит,
безопасно) вести машину.
При всем при этом совершенно не исключено, что нашим KPI, т. е. дейст-
вительно решающим фактором в вопросе о том, прибудем мы вовремя или
нет, является способность правильно прочитать карту или воспользоваться
сотовым телефоном, чтобы с помощью местных ориентиров и советов тех, к
кому мы едем, проехать последние километры пути. Поскольку эти умения
не оснащены измерительными приборами (разве что в автомобиле есть GPS),
их трудно оценивать, пока дела не пойдут из рук вон плохо. Помните о дан-
ном обстоятельстве при работе с ИТ-метриками.
2.2. Метрики как средство управления
За управление автомобилем отвечают руль, педаль газа, тормоза и рычаг
коробки передач. Они позволяют водителю, реагируя на ежеминутные изме-
нения дорожного покрытия, неожиданные опасности и другие случайности,
контролировать машину. Аналогичным образом происходит повседневное
управление в компании, или так называемый микроменеджмент, когда уде-
ляется слишком много внимания мелким деталям. Это не значит, что детали
несущественны: если вы наедете на бревно и проколете шину, время поезд-
ки наверняка увеличится.
Реальный долгосрочный контроль — как все на свете — является резуль-
татом хорошего планирования. Тщательно отобранные метрики в сочетании
с правильным управлением стимулируют выполнение правильно определен-
ных действий, повышающих вероятность своевременного прибытия в конеч-
ный пункт. Частота технического обслуживания машины — метрика очень
долгосрочная, но важная.
Грамотное планирование и чтение карты гарантируют, что вам не при-
дется мчаться на максимальной скорости, нарушая правила, закладывая
крутые виражи и резко тормозя. Такие действия позволят вам добраться до
нужного места, но одновременно увеличат риск и сделают поездку неком-
фортной для пассажиров. В следующий раз они, возможно, предпочтут по-
ехать на поезде!
Некоторые инструменты, к примеру счетчик оборотов, не кажутся чем-то
представляющим непосредственную ценность, в некоторых автомобилях их
вообще нет. Но опытный водитель может воспользоваться таким прибором,
чтобы добиться оптимальной скорости, не сильно изнашивая двигатель. При
проведении авторалли можно было бы присуждать участникам очки за то,
что счетчик оборотов у них никогда не зашкаливает и они проезжают дис-
28
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
танцию за кратчайшее время при минимальном расходе топлива. Для этого
нужно отлично водить, планировать и ориентироваться.
Это длинное рассуждение полностью применимо и к ИТ-метрикам. В ИТ
существует ряд KPI, которые настолько важны, что непременно должны кон-
тролироваться — подобно тому, как в машине необходим точный указатель
расхода топлива. Для других метрик трудно собирать данные, и они, как
счетчик оборотов, могут понадобиться только сложным и зрелым ИТ-орга-
низациям для достижения оптимальной эффективности. Между тем боль-
шинству ИТ-подразделений будет очень выгодно использовать метрики для
контроля своей деятельности, чтобы их жизнь не состояла лишь из тушения
пожаров, крутых поворотов и экстренного торможения, чтобы и бизнес,
и ИТ чувствовали себя достаточно комфортно и могли работать с полной
отдачей без ненужного перенапряжения. Важно помнить, что для достиже-
ния результата одного измерения недостаточно — нужно еще и управлять
деятельностью в соответствии с метрикой: хорошо спроектированный спи-
дометр не заставит вас соблюдать ограничение скорости!
Минцберг выделил пять методов координирования организационной
работы. Можно провести аналогию между ними и вождением автомобиля
(табл. 2.1).
Таблица. 2.1
Пять методов координирования организационных мероприятий
и их аналоги при ддении автомобиля (по Минцбергу)
четой координирования Аналогия при вождении автомобиля
Прямое руководство Начальник поручает водителю доставить пакет клиенту сегодня к 17:00.
Подстраивание друг под друга 1 _ Водители планируют свои перерывы, чтобы все автобусы не оказались оставленными одновременно
Стандартизация методов работы Водителей учат действовать в соответствии с заранее определенной процедурой
Стандартизация результатов Водители прибывают в пункт назначения с отклонением от графика в пределах десяти минут
Стандартизация возможностей Водители имеют высшую категорию
В таблице фигурируют различные способы запроса желаемых результатов.
Некоторые из них опираются на уже существующие метрики — например,
проверка того, что у всех водителей высшая категория. Другие создаются для
конкретного случая и должны документироваться отдельно.
В управлении ИТ многое из того, что происходит сегодня, относится к
уровню «прямое руководство». С распространением ITIL появилась возмож-
ность вводить метрики, позволяющие специалистам с соответствующей
Глава 2. ЗАЧЕМ НУЖНЫ МЕТРИКИ?
29
квалификацией реализовывать стандартизованные процессы со стандартны-
ми метриками. Как показано в IS020000, эти приемы работают только в со-
ставе единой системы управления.
2.3. Метрики и инновации
Метрики работают, только если существует процесс, который необходимо
оценить. При отсутствии процесса измерение не позволит выявить в нем
проблемные места и найти правильный способ улучшения ситуации.
Критика в адрес использования метрш чаете исходит от тех, кому в дейст-
вительности не нравятся не сами метрики, а процессы. Этот вопрос мы под-
робнее рассмотрим в разделе 10.3.1, посвященном сопротивлению измене-
ниям. Здесь же стоит отметить, что люди легко соглашаются работать в со-
ответствии с определенным процессом, а потом продолжают делать все в
точности так же, как и раньше, если только нет соответствующих процессных
метрик, которые быстро покажут, что процесс не работает.
Руководители, считающие, что внедрили какие-либо процессы, и обнару-
жившие, что те не приносят особой пользы, могут заметить, что с введением
процессных метрик ничего на самом деле не изменилось. По этой и другим
уже доминавшимся причинам имеет смысл запускать метрики одновремен-
но с процессами, о чем часто забывают.
Против процессов и, как следствие, метрик протестуют по нескольким
мотивам. Один заключается просто в том, что введение процесса является
изменением (а большинство из нас не приветствует изменений). Второй —
работа становится скучной, так как всякий раз должна выполняться строго
определенным способом. Многим не нравится, что измерение количествен-
ных показателей процесса ставит сотрудников под удар критики и может
угрожать их дальнейшему пребыванию в должности.
Во всех этих возражениях есть доля правды, особенно если причина внед-
рения процессов недостаточно хорошо изложена.
Здесь уместна следующая аналогия. Езда на велосипеде — это процесс.
Обучившись ей, — а те, кто это сделал, помнят, как поначалу вихляли, боя-
лись упасть и разбивали коленки, — мы больше не думаем о деталях. На
самом деле замечено, что если слишком задумываться о том, что именно
делаешь, когда едешь, то с большой вероятностью упадешь. Важно, что теперь
можно сосредоточиться на цели путешествия, видах и удовольствии от пре-
бывания на свежем воздухе. Если мы так и не превратим езду на велосипеде
в хорошо знакомый процесс, то будем обречены всегда испытывать трудно-
сти, падать и ездить без удовольствия. Вряд ли мы совершим много путешес-
твий, а уж дальних наверняка окажется мало.
Точно так же обстоит дело с ITSM и с бизнес-процессами. Когда они внед-
рены и работают, можно сосредоточиться на более интересных вопросах,
связанных с нововведениями, а непрекращающаяся борьба с пожарами пе-
30
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
ресгает быть стилем жизни. В компании, где существуют хорошо отлаженные
процессы, сотрудники могут предлагать новшества и работать с полной от-
дачей в более спокойной и уравновешенной обстановке, чем в организациях,
не вылезающих из кризисов.
Да, метрики действительно позволяют разглядеть проблемы, но их и нуж-
но отмечать. Цель здесь — не найти виновных, а отрегулировать процесс.
Это осознается не сразу, но для процессов и метрик жизненно важно их при-
нятие персоналом.
Если метрики обеспечивают отчетность только по схеме светофора с
оценками «красный», «желтый» и «зеленый», то менеджерам хочется отме-
чать исключительно «красные» метрики, выявляющие проблемы. Чтобы
обеспечить не только нахождение изъянов, но и поощрение достижений,
можно, например, ввести в систему отчетности оценку «золотой» для случая,
когда целевые показатели не просто достигнуты, а превышены. И, повторим,
всем важно знать, и это следует подчеркнуть, что процессные метрики созда-
ются для улучшения регулирования процессов, а не для поиска виновных!
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
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Уровень детализации метрик определяет степень их применимости. Если
они слишком подробны, их восприятие требует длительного времени и с
большой вероятностью может быть урезано до описанного выше просмотра
«красных» пунктов. С другой стороны, при отсутствии достаточного количе-
ства деталей можно упустить из виду важные тенденции. Цель этой кни-
ги — найти равновесие между двумя крайностями, предложив небольшие
понятные наборы показателей, характеризующих наиболее важные парамет-
ры процесса.
4.1. Руководство компании
Руководители бизнеса и ИТ совместно направляют работу ИТ-подразделения
так, чтобы добиться ее оптимального сочетания с потребностями бизнеса.
Эта деятельность никогда не заканчивается, поскольку частая и порой не-
ожиданная смена требований заложена в самой природе бизнеса. Метри-
ки — возможно, в составе системы сбалансированных показателей (Balanced
Scorecard — BSC) или другой подобной схемы — помогают количественно
оценить эффективность тех директив и рычагов, посредством которых руко-
водители осуществляют управление.
Метрика по самой своей сути может представлять информацию только о
совершившихся событиях. Важно удостовериться, что все они отвечают нуж-
дам предприятия.
Самый непосредственный показатель качества ИТ-услуг, имеющийся в
распоряжении руководства компании, — это фактическая эффективность в
сравнении с критериями, определенными в SLA. Внутрифирменные показа-
тели эффективности различных ИТ-процессов лишь дополняют эти данные.
Если дела идут хорошо, а отступления от SLA редки и слабо влияют на рабо-
ту, руководству компании, как правило, не нужно особенно вникать во внут-
ренние механизмы работы, за исключением тех случаев, когда становится
известно о предстоящих изменениях в коммерческой среде.
Случается, что ИТ-подразделение предоставляет услуги в соответствии с
оговоренными уровнями сервиса, но лишь за счет высоких внутрифирмен-
ных издержек и крайнего напряжения сил. Это неприемлемо в длительной
перспективе. Другая ситуация — отдел успешно справляется с работой при
нынешней загрузке, но не обладает достаточным потенциалом на случай ее
повышения. Крупная операция по слиянию способна превратить эффектив-
ное ИТ-подразделение в безнадежно провальное, но этого можно избежать,
если заранее спланировать необходимые преобразования. Зная из процес-
сных метрик о том, как функционирует ИТ-служба, руководитель в состоя-
нии строить реальные планы на основе здравой оценки имеющихся воз-
можностей и проблем.
Наконец, критерии SLA могут быть слишком жесткими с точки зрения
действительных нужд предприятия. Если руководитель, согласующий уело-
Глава 4. ДЛЯ КОГО ПРЕДНАЗНАЧЕНЫ МЕТРИКИ
39
вия со стороны бизнеса, обладает большей властью или опытнее в ведении
переговоров, то не исключено, что под его давлением менеджер по уровню
сервиса уступит нереалистичным требованиям. Кроме того, обстоятельства
меняются, и SLA, подходящее для организации при одном ее размере, при
другом может сделаться невыполнимым. На деле для соблюдения SLA дан-
ные соглашения необходимо пересматривать и обсуждать, обеспечивая
рациональное согласование. Процессные метрики позволяют менеджеру по
уровню сервиса проверить принятые решения относительно этих уровней
в реальных условиях, предъявить руководству показатели фактических
затрат — пусть даже не в денежном измерении, а просто как количество
усилий и ресурсов, — и, возможно, добиться пересмотра схемы, которая
приносит лишь незначительную пользу бизнесу, но при этом резко увели-
чивает накладные расходы на ИТ.
Как упоминалось во введении, процессные метрики будут полезны выс-
шим руководителям, только если те будут понимать их содержание и связь
с финансовыми издержками. Кроме того, руководители должны иметь пред-
ставление о других, менее осязаемых, но тем не менее важных факторах,
таких как моральное состояние сотрудников ИТ-подразделения или текучесть
кадров: хотя их и трудно измерить, они оказывают существенное влияние
на предоставление услуг.
4.2. Менеджеры процесса
Менеджеры процесса видят метрики нижнего уровня и в силу этого лучше
понимают, почему тенденции, наблюдаемые для KPI, именно таковы, како-
вы они есть. Если в очередном отчете ожидаются «красные» пункты, менед-
жер заведомо узнает об этом первым, а значит, к тому моменту, как отчет
попадет в распоряжение руководства ИТ и компании, может подготовить
некоторые разъяснения и предпринять определенные корректирующие
действия.
Однако при работе в течение длительного времени «красные» пункты не
должны быть высшим приоритетом. Для менеджера процесса важнее иметь
представление о тенденциях, позволяющих выявить возможные опасности
в среднесрочной перспективе. Требуется сравнительно немного усилий,
чтобы изменить производительность процесса или преобразовать его, пре-
дупредив таким образом развитие опасных сценариев, о которых сигнали-
зировали метрики. Преодолевать кризис, когда он уже возник, значительно
тяжелее.
Менеджеры несут ответственность за управление собственными процес-
сами. Но у них, кроме того, есть и более широкая задача — внедрение куль-
туры, ориентированной на процесс. Необходимо избавиться от глубоко
укоренившегося в ИТ обычая награждать за героическую борьбу с пожаром
и спасение положения в последнюю минуту, забывая о тех, кто предотвра-
40
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
щает возгорание, — ведь в действительности именно им в первую очередь
причитаются премии.
Для этой цели стоит открыто поощрять шаги, направленные на нейтра-
лизацию потенциальных будущих кризисов, и достигнутую благодаря этим
действиям экономию средств. Полезно также широко распространить мате-
риалы с анализом происходивших крупных кризисов, где делался бы упор на
предотвращение сходных ситуаций в будущем. И совершенно необходимо,
чтобы постепенный сдвиг от прежнего порядка к новому происходил на
фоне регулярной рассылки показателей, характеризующих нормальный ход
процесса, а не исключения из него.
Менеджерам процессов также следует серьезно заняться выявлением
ресурсов и накладных расходов, ставших избыточными вследствие изменения
эффективности или уменьшения запросов со стороны бизнеса. Это нелегко,
но в долгосрочной перспективе, возможно, позволит усовершенствовать
процесс так, чтобы он обеспечивал лучшие результаты с меньшими затрата-
ми. К сожалению, зачастую в организационную культуру заложено возна-
граждение руководителей, имеющих большое число подчиненных, а те, ко-
торым удается приносить много пользы при малом числе сотрудников, оста-
ются в тени.
4.3. Сотрудники ИТ-подразделений
Изменение организационной культуры, рассмотренное в предыдущем раз-
деле, существеннее всего сказывается на персонале ИТ-подразделений. В них
каждый сотрудник должен понимать, что такое метрики, КР1 и SLA, причем
не только в общем, но и конкретно — как именно они соотносятся с процес-
сами и с его собственным участием в деятельности предприятия.
В идеале отдел кадров должен располагать переработанными должност-
ными инструкциями и критериями оценки эффективности, так чтобы ее
можно было измерить при помощи соответствующих метрик, сопоставить
результат с контрольными показателями и в зависимости от полученного
соотношения определить вознаграждение.
Очень важно постоянно информировать персонал о точном смысле мет-
рик, о том, какие достижения будут поощряться и как именно. На ежене-
дельных и ежемесячных собраниях необходимо сравнивать эффективность
различных процессов и награждать сотрудников за превышение заданных
критериев. Подобно тому, как в производственных цехах сейчас существуют
графики текущих показателей производительности, в ИТ-отделах нужно на
видном месте вывешивать относящиеся к ним метрики, чтобы напоминать
сотрудникам о стоящих перед ними задачах.
Наиболее весомый вклад в программу SIP способны внести сотрудники,
первой линии поддержки. Людям, изо дня в день предоставляющим услуги
в рамках процессов, проще увидеть, как они могли бы улучшить свою рабо-
Глава 4. ДЛЯ КОГО ПРЕДНАЗНАЧЕНЫ МЕТРИКИ
41
ту. Нужно советоваться с ними и достойно вознаграждать ценные предложе-
ния. Как-никак, повышать качество услуг для конечных пользователей путем
совершенствования процесса обслуживания лучше, чем вкладывать все боль-
ше. средств в версанал, компьютеры и другие ресурсы*.
Когда производительность не соответствует идеалу и в KPI или процессных
метриках появляются показатели, выделенные красным цветом, важно пре-
дотвратить повторение подобных ситуаций. Для этого следует рассматривать
проблему не как повод для обвинения кого-либо, а как возможность найти
пути дальнейшего совершенствования и всячески поощрять сотрудников,
предлагающих способы исправить положение.
Также к обсуждению будущих изменений в метриках стоит привлекать
работников из групп, непосредственно отвечающих за услуги для конечных
пользователей. Благодаря знанию повседневных проблем они хорошо пред-
ставляют себе последствия преобразований и распознают нереалистичные
запросы. Если же руководству необходимо настаивать на своих требованиях,
лучше обсудить пути их выполнения совместно с сотрудниками. Тогда при-
нятые решения не будут встречаться негодованием и неприятием, что ти-
пично для ситуации, когда их навязывют сверху без ясного понимания по-
тенциальных результатов.
Все мы, очевидно, чувствуем себя комфортнее и лучше работаем в усло-
виях меньшего стресса и большего контроля над собственным будущим.
Сотрудники, должным образом задействованные в процессах создания и
согласования метрик, будут сильнее ощущать себя ответственными за то,
чтобы обеспечить хорошее соответствие установленным критериям- Сколь
бы неосязаемыми ни казались подобные изменения морального духа, они
безусловно вносят свой вклад в итоговый результат деятельности пред-
приятия.
______________5
Как использовать
метрики
5.1. Время
Частота измерений влияет на результаты. Отчеты о метриках
могут предоставляться каждый день, месяц, неделю, квартал
или год, и очень важно, чтобы временной интервал был выбран
правильно.
Было бы ошибкой принимать стратегические решения на
основе одного из ежедневных отчетов: нельзя исключить, что
его данные — аномалия. Аналогичным образом годовой отчет
позволяет выработать стратегию исправления ситуации, но не
тактические решения на следующую неделю для службы Service
Desk.
Важно понимать, что многие показатели, помимо частоты
измерения, характеризуют интервал времени, за который долж-
но смениться состояние процесса, — например, как быстро
проблема из «новой» превратится в «решенную». В таких случа-
ях нельзя просто фиксировать состояние через равные проме-
жутки времени — ведь если код остается прежним, это не дает
никакой дополнительной информации. Здесь измерение возмож-
но только тогда, когда что-то (как правило, некоторый процесс)
действительно изменяется.
5.2. Измерение
Чтобы управлять бизнесом, его нужно измерять. В коммерчес-
кой деятельности для этой цели выработано несколько четких и
конкретных показателей, общих для целого ряда отраслей:
44
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
• доход;
• прибыль;
• объем продаж;
• доля рынка;
• норма окупаемости инвестиций (Return Investment — ROI);
• объем производства;
• уровень запасов.
Некоторые из перечисленных показатели можно применить к ИТ-про-
цессам, и это тем проще, чем лучше связь между ИТ и бизнесом.
Здесь есть риск увлечься измерением тог°> что легко измерить, вместо
того, что способно дать важную информацию ° бизнесе. Несложно посчитать
число проданных еданищтовара в суперма<?кете’ но ПРИ этом факты продажи
пакетика конфет и стиральной машины получат одинаковый вес, так что
применимость подобной метрики будет б^лее чем ограниченной. В ИТ объ-
екты не так осязаемы, как стиральные машины, поэтому труднее оценить
осмысленность того или иного измерений
На рис. 5.1 показана схема того, как процессы протекают в различных
подразделениях, обеспечивая взаимосвйзь входных и выходных потоков
информации. Кружки обозначают этапы процесса, причем подразделения-
Рис. 5.1. Общий сценарий процесса. Метрики фиксировать только изменения
состояния процесса. Чтобы они имели смысл ражно правильно определить процесс
Глава 5. КАК ИСПОЛЬЗОВАТЬ МЕТРИКИ
45
участники оказываются в состоянии производить измерения, когда в рамках
этого процесса начинают отвечать за выполнение определенного действия
или задания, — измерить что-либо можно только в момент изменения.
Допустим, процесс в целом — это обработка заказа, а самый темный
кружок обозначает отдел, ответственный за проверку кредитоспособности
покупателей. Он может фиксировать моменты времени, когда заказ поступил
и когда был передан следующему отделу как принятый или отклоненный.
Эта информация полезна для данного отдела, но представляет куда меньше
интереса для владельца процесса. Не все заказы проходят через кредитный
контроль, для небольших, возможно, используется упрощенный механизм
подтверждения. С точки зрения владельца процесса важна стадия подтверж-
дения, ее продолжительность, количество ошибок в процессе и т.д.
Из-за подобных различий в точке зрения мы часто рассматриваем эту
схему как последовательность «состояний» процесса. Заказ из состояния
«кредитоспособность не проверена» переходит в состояние «проверка креди-
тоспособности» и далее — «кредитоспособность проверена». Эти переходы
можно использовать для измерения различных значимых факторов в данной
части процесса. Попробуем просто рассмотреть все заказы, находящиеся в
состоянии «проверка кредитоспособности», и решить, какие еще факторы
представляют интерес, к примеру:
• размер заказа;
• лицо или отдел, обрабатывающие заказ;
• конечная кредитоспособность клиента.
Фактически мы спрашиваем: «Что нам важно знать о ситуации с заказами,
когда проверяется кредитоспособность клиента?», т. е. задаем вопрос о биз-
несе и его значимых результатах.
В ИТ-процессе происходит то же самое. Мы определяем состояния про-
цесса, а затем для каждого из них определяем, что существенно для достиже-
ния цели процесса согласно SLA.
Здесь проясняется один важный момент. В примере с проверкой креди-
тоспособности привязка состояний к бизнес-процессу (а также отделу) была
очевидной, а в ИТ это далеко не так. Если состояние охватывает два подпро-
цесса, измерение не может выделить ни один из них. Без тщательно проду-
манных определений процессов результаты, вполне вероятно, не будут иметь
смысла или, что еще хуже, введут в заблуждение.
Важно отметить, что на диаграммах, подобных той, которая представлена
на рис. 5.1, переход от одного состояния к другому выглядит как моменталь-
ный. В реальной жизни это не всегда так. Если заказ отпечатан на бумаге, то
после получения им статуса «кредитоспособность проверена» может потре-
боваться еще несколько часов для его передачи на следующий этап обработ-
ки, потому что нужно будет физически взять документ в руки и отнести его
следующему сотруднику. Даже в электронных системах возможны задержки,
46
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
в частности, если заказ попадает не к тому работнику и его нужно переслать
по правильному адресу.
5.3. Контроль
Когда критерии выработаны, можно начинать контролировать измеряемую
часть процесс а: узнать, кто отвечает за каждое из конкретных состояний
процесса и за переходы между ними, затем установить для подпроцессов
ориентиры, на основе которых будет оцениваться их эффективность. Обыч-
ные способы для этого — либо понаблюдать за показателями в течение од-
ного-двух периодов времени, чтобы получить таким образом представление
о нормальном ходе работы, либо сравнить данный подпроцесс с аналогич-
ным в своей или другой организации.
После установки ориентиров можно переговорить с владельцем подпро-
цесса, чтобы вместе с ним определить задачи по улучшению ситуации. Ин-
формация о продолжительности состояний позволяет также выявить те
подпроцессы, которые требуют больше всего времени и ресурсов, а значит,
обещают максимальный эффект от усовершенствования.
Чтобы получить правильный результат, необходимо учитывать, что не все
состояния равноценны. На диаграмме состояний процесса, показанной на
рис. 5.2, можно увидеть альтернативные пути.
Рис. 5.2. Диаграмма состояний процесса. Степень насыщенности серого отражает
последовательность шагов от начала и до конца процесса. Диаграмма показывает
допустимые переходы между состояниями
Глава 5. КАК ИСПОЛЬЗОВАТЬ МЕТРИКИ
47
В этом нет ничего необычного. Просто из начального состояния процесса
(ПО) возможен переход в три других: (П1, Пб и П7), приводящих к различным
вариантам хода процесса. Так как все они завершаются конечным состоя-
нием П5, время ПО -» П5 можно измерить, и не исключено, что такой пока-
затель будет полезен. Однако если процессы ПЗ, П7 и П8 контролируются
другими частями организации, вам вряд ди легко удастся выяснить, почему
у них такие плохие показатели времени.
Когда переход ПО -» П5 представляет собой важную часть выполнения
процесса в соответствии с SLA, его продолжительность — вполне обоснован-
ный показатель. Но чтобы контролировать весь процесс, его владельцу нуж-
ны метрики по отдельным ветвям, чтобы понимать долю каждого маршрута
в общем объеме обработки и общей продолжительности задержек. К приме-
ру, может оказаться, что 90% процессного трафика проходит по маршруту
ЛО П6 П5, но все случаи, в которых возникала опасность невыполнения
SLA, относятся к маршруту ПО -> Ш -> ПЗ -> П4 -> П5. Это означает, что усо-
вершенствование или перепроектирование более сложного из двух маршру-
тов позволит значительно улучшить уровень контроля всего процесса, и
пока это не сделано, не стоит тратить время на альтернативный маршрут,
характеризующийся высокими объемами,
5.4. Цель
Контроль — это прекрасно. И все же, продолжая нашу аналогию с вож-
дением автомобиля, если вас до наступления сумерек ждут в Амстерда-
ме, а вы, проведя день за рулем, приезжаете в Париж, вас вряд ли за это
похвалят.
Чтобы управлять процессом, нужно понимать, к чему именно вы стреми-
тесь. В примере с проверкой кредитоспособности можно было бы, скажем,
пожелать, чтобы общая сумма безнадежных долгов не превышала 5% това-
рооборота, а время обработки заказа — восьми рабочих часов. С заданной
таким образом целью становится намного понятнее, какие именно процессы
нужно измерять.
Определив цель и соответствующие измерения, необходимо проверить
обоснованность принятых решений с помощью контрольного тестирования.
Затем следует оценить разрыв между целью и нынешним положением дел
(к примеру, долги составляют 10% товарооборота, а обработка заказа длится
двенадцать рабочих часов). Заключительный шаг — разработка плана по
преодолению разрыва путем усовершенствования процесса, а также, возмож-
но, за счет использования дополнительных ресурсов или даже аутсорсинга
некоторых частей процесса.
С этими решениями можно уже двигаться по направлению к цели, уста-
навливая для команд и владельцев подпроцессов промежуточные цели в
виде определенных показателей эффективности.
48
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
В ИТ не всегда легко правильно поставить цель. Здесь очень важно не
пожертвовать удовлетворенностью потребителя, чересчур энергично взяв-
шись за сложную задачу. Поэтому во все планы процессов, рекомендуемые
далее в настоящей книге, включена метрика удовлетворенности. Она позво-
ляет проследить, чтобы движение к важным целям ИТ не увело компанию
от клиентов.
5.5 Учет
В методиках, описывающих управление ИТ-услугами, в частности в ITIL,
ставится задача максимально тесной привязки этого управления к целям
конечного потребителя, которые часто (или даже как правило) носят фи-
нансовый характер. Обеспечению привязки посвящен специальный раздел
ITIL — управление финансами ИТ. Задействовав его на начальной стадии
разработки метрик, можно встроить в проект оценку ресурсоемкое™.
Допустим, установлено, что затраты на одну заявку составляют сто условных еди-
ниц. Изначально это, по-видимому, очень грубая оценка, рассчитанная путем
деления расходов на службу Service Desk на количество обращений. Со временем
ее можно будет уточнить, предоставив управлению финансами информацию о
реальном времени работы согласно заданным процессным метрикам, KPI и SLA,
а также теоретическую базу для учета этих цифр.
В самом начале такая процедура способна помочь с выявлением SLA, которые
вносят незначительный вклад в выполнение бизнес-функции, но поглощают мно-
го ИТ-ресурсов. Разумеется, компания вполне может решить, что подобное рас-
пределение правильно, но в случаях, когда оно не является приоритетным, пере-
смотр «ресурсоемких» SLA позволит значительно сэкономить на расходах.
По мере созревания бизнеса модель затрат усложняется. На данной стадии
имеет смысл создать для финансового управления метрики, отслеживающие
расходы организации в целом. Это позволит выявлять нежелательные тен-
денции и предпринимать действия по исправлению ситуации, прежде чем
появится опасность серьезного перерасхода. Преждевременные попытки
упорядочить издержки могут оказаться опасными. Организации проще вы-
терпеть дополнительны- проблемы, издержки и давление, когда мышление,
опирающееся на процесс, становится нормой.
6
й" *
Разработка
метрик
Прежде чем приступить к подробному рассмотрению конкрет-
ных метрик, нужно понять, что за процессы должны имИ оцени-
ваться. Без этого невозможно определить, будет ли работать
полученный набор метрик, каким бы впечатляющим он ни ка-
зался.
0 настоящей главе исследуются методы создания жизнеспо-
собного набора метрик для компании.
"При первоначальном обсуждении метрик внутри и з'атцтеде-
ламИ ИТ-подразделения следует рассмотреть основополагающие
принципы, чтобы все поняли, почему применяется данный про-
цесс и какими будут результаты.
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
МАРЕ = У, | (измеренные значения - прогнозируемые значения) /
измеренные значения] *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. Где же выход?
Если использовать методы, о которых гоВорилось в этой главе, то первый
вопрос, который приходит на ум, — это ли владелец процесса согласие
на метрику «время закрытия заявок»? ВерОЯТНО> нет Почему вообще так
важно быстро закрывать заявки? Наверняка вы и сами можете догадаться об
ответе: клиент рад, когда его проблема решена (если, конечно, она реше-
на— путем открытия новой заявки эта Цель не достигается), центр может
обрабатывать больше заявок для того же Цисла людей (это, конечно же, не-
верно, если несколько заявок представляв^ собой повторно открытую заяв-
ку для того же инцидента).
Следующий вопрос — консультировалась ли создатели метрик с заинте-
ресованными лицами (теми, кто звонит)? Хотят ли эти люди, чтобы их раз-
говоры с центром обработки вызовов бц1ЛИ как можно короче? Видимо,
нет — скорее всего, им интересно не «отКрЫТИе>> и «закрытие» заявок, а ре-
шение проблем.
6.6.3. Существуют ли лучшие метрику?
Должно быть, да. Но прежде давайте по^ем о процессе создания мет-
рик. Не стоит ли нам вернуться к эскизу, проконсультироваться с заинте-
ресованными лицами, владельцами процесса и определить, в чем состоят
реальные задачи? И опираясь на них, поцытаться предложить более удач-
ные метрики.
Это не кроссворд, и здесь не начисляют^ Очки за самую необычную мет-
рику. Вопрос в том, чтобы усовершенств5вать процесс и улучшить его ре-
зультат для конечного потребителя.
Для начала, не лучше ли будет передавцть ЗВОнки, которые длятся больше
установленного времени, команде по управлению проблемами для выясне-
ния причин задержки? Тогда, если удастся выявить конкретные сложности
и придумать, как с ними справиться, продОЛЖИтельность вызовов сократит-
ся сама собой.
Корень проблемы просто в том, что разработчики метрики не думали о
приоритетах с точки зрения клиента, а сразу решили для себя, что это лишь
способ контролировать персонал службы Servjce uesk (или центра обработки
вызовов). Если же сотрудники почувствутот, что их стремление повысить
качество обслуживания получает поддержку, они будут работать усерднее и
эффективнее. Предложив им описать, поцему одни ЗВОНки требуют больше
60
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
времени, чем другие, вы дадите им некоторые возможности воздействия на
процесс, а в результате поднимется и их моральный дух — определенный
контроль среды этому очень помогает. Этот «добродетельный» (в противо-
положность порочному) круг продолжится по мере того, как все больше и
больше довольных сотрудников станут передавать свое настроение клиентам
посредством более спокойного тона разговоров, не содержащих желания
«закрыть» и «повторно открыть» заявку.
Создание метрик
на практике
В этой главе на примере одного набора показателей разъясняет-
ся подход к обдумыванию и выбору метрик. В следующей гла-
ве, которая называется «Конкретные метрики для управления
ИТ-услугами», представлен такой набор для всех процессов
управления услугами.
Глава 7 служит связующим звеном между теорией, изложен-
ной в первых шести главах, и реальными метриками, приво-
димыми в качестве примеров.
Она необходима, чтобы объяснить, каким образом выбор
показателей согласуется со сделанными рекомендациями и где
он с ними расходится. Это поможет при решении вопроса о том,
использовать ли метрику «как есть» или ее необходимо моди-
фицировать.
С целью оптимизации работы с метриками используются
специальные схемы.
Из этой главы вы узнаете, как они действуют и что пред-
ставляют собой их поля.
Принципы построения метрик объясняются на примере
процесса управления конфигурациями, который принципи-
ально важен для ITSM и является одним из центральных уп-
равляющих процессов, определяемых в IS020000. Обычно в
качестве такого примера используется управление инциден-
тами, потому что для него легко придумать полезные (и не
очень) показатели, но рассмотрение слишком простого про-
цесса принесет мало пользы и даже может дезориентировать
читателя. Поэтому управление конфигурациями — более удач-
ный выбор.
62
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
7.1. Основания для выбора метрик
(на примере управления конфигурациями)
В качестве метрик для процесса управления конфигурациями мы выбрали
степень удовлетворенности клиента и еще семь показателей, отвечающих
требованиям, о которых шла речь в предыдущих главах, — простых, понят-
ных (Keep It Simple Stupid — KISS), конкретных, измеримых, достижимых,
реалистичных и своевременных (SMART). Учитывалось также их соответ-
ствие задаче, или цели процесса, поэтому в приложениях каждое описание
метрик процесса начинается со следующих слов:
«Соотнесение метрик с задачами процесса — это ключевой шаг в их разра-
ботке: он позволяет отличить содержательные метрики от измеримых».
Согласно определению, даваемому библиотекой ITIL (том «Поддержка
услуг»), управление конфигурациями преследует следующие цели:
1. Отвечать за все конфигурации ИТ в рамках организации и оказывае-
мых ею услуг путем поддержки логической модели ИТ-инфраструкту-
ры и ИТ-услуг.
2. Предоставлять точную информацию о конфигурациях, логических
моделях ИТ-инфраструктуры и ИТ-услуг, а также соответствующую
документацию для поддержки других процессов, таких как управление
инцидентами, проблемами, изменениями и релизами.
3. Сравнивать записи о конфигурации с инфраструктурой исправлять
любые несовпадения.
Объединив эти три основных цели, можно на основе принципов, рассмот-
ренных в главах 1-6, получить одну конкретную цель метрик, которая фор-
мулируется так: «Получать и анализировать информацию об инфраструкту-
ре ИТ и на основании полученных данных осуществлять точное и эффектив-
ное управление ИТ-ресурсами в соответствии с согласованными стандартами
и потребностями бизнеса». В приведенной спецификации под «получением»
информации об ИТ-инфраструктуре понимается последовательность шагов
по проверке и предоставлению правильных данных об объектах ИТ-инф-
раструктуры, а «управление» ИТ-ресурсами можно рассматривать как их
использование для выполнения задач бизнеса.
Все метрики должны следовать непосредственно из данной цели — это
необходимо для поддержания их измеримости, повышения простоты, нахож-
дения более конкретных метрик и т.д. Только при этом условии мы посте-
пенно придем к осмысленным, а не просто измеримым показателям.
По мере созревания и развития процессов взаимосвязь между их состав-
ляющими будет усиливаться. Когда уровень зрелости взаимодействия про-
Глава 7. СОЗДАНИЕ МЕТРИК НА ПРАКТИКЕ
63
цессов приближается к оптимальному, число метрик начинает снижаться,
так как становятся понятнее реальные контрольные показатели и все более
преобладают составные метрики. А многочисленные низкоуровневые мет-
рики воспринимаются при этом как «шум», и потребность в них постепенно
сходит на нет. Со временем эта тенденция приводит к развитию в различных
подразделениях собственных наборов метрик, приспособленных к их конк-
ретным требованиям.
В приложениях вы найдете цели метрик для ряда процессов, относящихся
к управлению ИТ-услугами. А сейчас рассмотрим поочередно метрики наше-
го примера — процесса управления конфигурациями.
7.1.1. Степень удовлетворенности клиентов
Мы представили диаграмму взаимоотношений с клиентами еще в предыдущей
главе, чтобы подчеркнуть то значение, которое придается в книге показателю
удовлетворенности клиентов. Каждому процессу сопоставлен «главный», «бли-
жайший», «наиболее важный» или «ключевой» клиент, хотя все сотрудники по
большому счету работают, чтобы удовлетворить конечного потребителя, для
каждого процесса лучшим и наиболее релевантным его измерителем является
интерфейсный процесс (или процессы), т. е. процесс, при помощи которого
происходит взаимодействие непосредственно с потребителем.
Основой для измерения степени удовлетворенности клиентов всегда слу-
жат либо данные опроса, либо отдельные оценки выполненных работ — ре-
зультаты процесса. Рекомендуется установить в каждом процессе точку,
в которой результат заведомо готов (заявка закрыта), так что «ключевой»
клиент уже может поставить оценку.
В нашем случае метрика степени удовлетворенности применяется к отче-
там клиентов, обращавшихся в ИТ с заявками, и к анкетам, рассылаемым по
всей клиентской базе. Приводимые нами оценки произвольны и при исполь-
зовании другого метода, вероятно, оказались бы иными. Существенен здесь
сам факт, что этот показатель измеряется и, как будет показано далее, важен
для руководства компании.
Для определенных процессов, которые Непосредственно влияют на рабо-
ту клиентов, оценка удовлетворенности еще более значима. В подобных
случаях можно использовать показатель, относящийся к такому процессу,
вместо общего рейтинга для всей организации. Если же рассылается анкета
с вопросами, относящимися к разным процессам (подразделениям), то, ве-
роятно, лучше будет не объединять ответы, а распределить их по соответ-
ствующим метрикам.
Опросы клиентов играют важную роль: в силу своего общего характера
они позволяют компаниям нацеливаться на клиентов, которые никогда не
имели дела ни со службой Service Desk, ни со многими другими процессами,
предусматривающими обязательную оценку удовлетворенности. К сожале-
64
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
нию, такие опросы требуют денег и времени (в том числе отнимают время
у клиентов), и если они проводятся слишком часто, это вызывает раздра-
жение.
Поэтому опросы не могут удовлетворить потребность в своевременной
оценке эффективности процесса управления услугами. Метрики в этой
книге опираются на более «быструю» обратную связь, получаемую для
только что сделанной работы. К примеру, закрытие инцидента, проблемы
или релиза дает клиенту шанс прокомментировать степень собственной
удовлетворенности, а также высказать рекомендации по улучшению ра
боты.
В некоторых процессах сложно определить подходящие контрольные
точки. Для них, возможно, понадобится придумать в той или иной степени
искусственный механизм, который все-таки обеспечит своевременную об-
ратную связь и таким путем решит проблему опросов. К примеру, удачным
решением могут стать еженедельные встречи по вопросам удовлетвореннос-
ти с менеджером «ключевого» процесса — по сути усеченный и более частый
опрос.
В нашей схеме метрики степень удовлетворенности клиентов оценива-
ется числом в интервале от О до 5, где О означает «совершенно не удовлет-
ворен», а 5 — «совершенно удовлетворен». Целевое значение — 4, опасный
уровень - - ниже 3.
Что касается процесса управления конфигурациями, то здесь стоит отме-
тить, что на нашей диаграмме взаимоотношений (см. рис. 6.1) в качестве
«главного» клиента показано управление релизами. Вообще говоря, допус-
тимым выбором было бы и управление инцидентами, проблемами или из-
менениями — ведь все эти процессы тоже упоминаются в формулировке
целей управления конфигурациями. Однако управление релизами особенно
важно, так как оно отвечает за крупные изменения инфраструктуры, которые
обязательно должны быть правильно отражены в CMDB.
Обратите также внимание, что метрика на рис. 7.1 относится к одному
процессу, но сама состоит из трех подпроцессов. Таким путем обеспечивает-
ся измерение не только конечного результата в момент закрытия релиза, но
и важных промежуточных показателей во время его планирования и реали-
зации. Было бы неплохо изобрести и другие метрики удовлетворенности
клиента для различных контрольных точек, где участвует процесс. Но не все
так просто.
Так, слияние трех метрик может означать, что из-за одной ошибки в CMDB
сразу три по видимости отдельных показателя удовлетворенности окажу гея
низкими. Наверняка владелец процесса воспримет это как несправедливость.
Однако есть способ избежать подобного эффекта. Если первая ошибка при-
водит к ошибке планирования, то после фиксации этого факта и получения
низкой оценки самое время исправить CMDB. Так мы избавимся от двух
других низких оценок, проделав фактически исключительно эффективную
Глава 7. СОЗДАНИЕ МЕТРИК НА ПРАКТИКЕ
65
работу по корректировке базы и инициировав запрос об изменении процес-
са (с целью предотвратить повторное возню новение той же ошибки, если
это имеет смысл). Результатом может стать очень высокая оценка в итоговом
анализе релиза.
7.1.2. Количество неиспользуемых лицензий
С первого же взгляда видно, что данная метрика конкретнее, чем большин-
ство других. Лицензии на программное обеспечение — одна из главных
статей расхода для ИТ-подразделений, и их отслеживание — функция про-
цесса управления конфигурациями, который помогает обеспечить правиль-
ное число лицензий, принадлежащих компании, используемых и оплачен-
ных ею. Эта задача оказывает зримое и прямое влияние на финансовую
эффективность ИТ, рассматриваемую с точки зрения бизнеса, и применяе-
мый подход к ее решению не вполне обычен: мы создаем в рамках управле-
ния конфигурациями конкретный объект измерения, хотя в большинстве
процессов предпочли бы что-либо менее специфическое.
В данном случае это оправданно, так как показатель прост (KISS), непос-
редственно связан с задачей процесса, определенной в ITIL и IS020000,
и одновременно полезен как точка для проверки общего уровня корректнос-
ти CMDB. Чтобы определить правильность числа лицензий, необходимо
убедиться, что в CMDB присутствуют все учетные элементы (CI), а связи
лицензий с CI и пользователями соответствуют действительности (установить
эти связи должным образом — важнейшая составляющая хорошего управле-
ния конфигурациями).
Есть и другие способы описать то же самое измерение, например, посчи-
тать процент лицензий, фактически использовавшихся в прошлом месяце,
или число лицензий на ПО, которые не применялись в течение шести меся-
цев (так что без этих лицензий можно обойтись). В определенных отноше-
ниях альтернативные варианты, наверное, даже лучше, но они не такие
прямые и непосредственные, и с ними сложнее определить, какую экономию
даст снижение показателя.
Другим достоинством данной метрики является минимальный объем
усилий, фактически нужных для измерения. Если предстоит покупка про-
граммных инструментов, понадобится, чтобы они могли предоставлять от-
четность не только о приобретенных и имеющихся (занесенных в базу как
CI) лицензиях, но и о связях между лицензиями и теми, кто ими пользуется.
К примеру, о десятипользовательской лицензии на программный продукт X
можно узнать, что ею пользуются всего шесть человек; тогда следующему
сотруднику, которому устанавливается программа X, будет отдана одна из
свободных лицензий — и не потребуется заказывать дополнительную лицен-
зию еще на десять пользователей! Программный инструмент, обеспечиваю-
щий корректное вычисление данной метрики, вероятно, внесет весомый
66
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
вклад в сокращение расходов на лицензии ПО и поддержание связей в CMDB
в актуальном остоянии.
Как много пользы от одной довольно необычной метрики!
7.1.3. Количество RFC, отклоненных из-за ошибочных
данных CMDB
Процессы управления изменениями и конфигурациями представлены в
IS020000 как тесно взаимодействующие друг с другом: 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 предлагает более быструю модель, и если
процесс приобретения не контролируется должным образом, она будет зака-
Запрос на изменение — зафиксированное требование клиента на внесение изменений в
любые элементы конфигурации в инфраструктуре или внесение изменений в процедуры,
связанные с инфраструктурой. — Прим. пер.
Глава 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
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
яние. Например, если бы нам было необходимо узнать только число релизов,
мы могли бы не пользоваться возвращаемым значением степени удовлетво-
ренности, а просто пересчитать все состояния «полный анализ релиза».
Метрика удовлетворенности клиента, таким образом, полностью охваты-
jdkfT'BevB ^равлекил кокфисурарил/.си. На рисунке это обозначает-.
ся двумя стрелками, ведущими от начала и от конца процесса к подпроцессу
измерения показателя.
На рис. 7.1 показаны три подпроцесса управления релизами:
• присвоение Q] нового статуса;
• добавление Cl в план релиза;
• полный анализ релиза.
Так как CI используются для документирования релиза, они перед обнов-
лением получают статус «предназначен для релиза», а после него — «обнов-
ляется с релизом». Именно по эффективности этого процесса и по отчетам о
состоянии релиза в ходе его реализации мы судим о качестве управление
конфигурациями.
Три названных подпроцесса управления релизами интересуют нас как те
точки, где используются С1 (результат процесса управления конфигурация-
ми). Именно здесь владелец подпроцесса (или человек, которому делегиро-
вана эта задача) сможет оценить вклад в него со стороны управления кон-
фигурациями.
Рис- 7.1. Метрика степени удовлетворенности клиента
для процесса управления конфигурациями
Глава 7. СОЗДАНИЕ МЕТРИК НА ПРАКТИКЕ
71
Это будет субъективная оценка, равно как и все остальные, относящиеся
к удовлетворенности клиентов. Владелец процесса сформирует ее после того,
как обдумает, насколько правильной и актуальной была информация CI,
насколько легко было найти CI, затронутые конкретным релизом, включить
их «желаемое состояние» в план релиза, а затем после завершения релиза
обновить их статус. Наконец, при анализе релиза владелец процесса сможет
вернуть суммарное значение, показывающее, какой вклад внес в этот релиз
процесс управления конфигурациями.
Таким образом, каждый релиз передаст процессу управления конфигура-
циями три показателя удовлетворенности клиентов, относящиеся к стадиям
планирования, реализации и анализа релиза заинтересованным «лицом» —
процессом управления релизами. В результате формируется всестороннее
понимание привносимого вклада.
7.3. Приоритеты и подсчет метрик
Чтобы характеризовать каждый процесс за каждый период времени всего
одним показателем, нужен метод комбинирования метрических значений.
Таких методов масса, здесь в качестве примера приводится всего один. Мы
присвоим нашим восьми метрикам приоритеты от 1 до 8 (по возрастанию
значимости) и затем будем использовать эти значения как вес.
Одни метрики выражаются в процентах, другие могут принимать прак-
тически любые значения, поэтому их нельзя применять непосредственно.
Судить об их успехе или неудаче позволяет Цель. Система оценки выдает три
значения (как в «светофоре» сбалансированной карты показателей): красный
цвет (-1) соответствует оценке, которая далека от целевой величины и ниже
опасной (она служит здесь пороговой), желтый (0) — оценке в интервале
между опасным и целевым значениями, зеленый (1) — равной целевой или
превосходящей ее. Теперь остается умножить эти оценки на их вес и просум-
мировать результаты.
Управленческое преимущество здесь заключается в возможности перена-
значать со временем приоритеты метрик, отражая таким путем изменения,
происходящие с требованиями бизнеса или зрелостью процесса. В начале
существования процесса управления конфигурациями было бы большим
оптимизмом ожидать значительного сокращения числа инцидентов благо-
даря поддержке других процессов с помощью качественной CMDB. Соответ-
ственно, для данной задачи целевое и опасное значения разумно установить
мягкими (сравнительно легко достижимыми), а приоритет — низким. Когда
зрелость управления конфигурациям и достигает того уровня, при котором
процент неправильных CI всегда невелик, приоритет этой метрики (вероят-
но, очень высокий на раннем этапе) можно понизить, а приоритет сокраще-
ния числа инцидентов поднять, побуждая владельца процесса к дальнейшему
совершенствованию.
72
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Постановка целей — задача руководства, ее выполнение требует способ-
ности рассуждать т нализировать. Эталонный (или базовый) показатель
процесса может быть как близким к оптимальному, так и очень далеким от
него. Чтобы устанавливать достаточно сложные, но все же реалистичные
цели, менеджер должен понимать людей, технологии и степень зрелости
процесса. Простое повышение какой-либо метрики на определенное значе-
ние, скажем на 5%, — неэффективная мера, поскольку для одних процессов
выполнить новые нормативы будет легко, а для других — невозможно. На
начальной стадии, при незрелом процессе, подобные грубые приближения
допускаются, но руководство должно стремиться к более глубокому понима-
нию всех процессов, чтобы по мере их созревания устанавливать цели в со-
ответствии с текущей ситуацией.
Как уже говорилось, существует много способов рассчитать итоговую
оценку. Самый простой гаков:
8
Итоговый показатель > X PN х RN,
N=1
где PN — приоритет N-й метрики, RN — результат за данный период, кото-
рый может быть равен -1 (зеленый), 0 (желтый) или 1 (красный).
Таблица 7.1
Данные метрик
Метрик Опасное значение Целевое значение Фактическое значение Приоритет/ Вес Результат
1. Степень удовлетворенности клиентов <3 4 2 3 -1
2. Количество неиспользуемых лицензий >10 5 3 2 1
3. Количество RFC, отклоненных из-за ошибочных данных CMDB >20 10 15 7 0
4. Количество неавторизованных конфигураций >15 5 2 8 1
5. Количество инцидентов, связанных с некор- ректными изменениями из-за неправильно задокументированных CI >6 0 0 6 1
6. Количество нарушений SLA, вызванных ошибками CMDB >2 0 0 1 1
7. Количество RFC без обновления CI <90 95 20 4 1
[ 8. Процент некорректных CI >100 40 10 5 1
Глава 7. СОЗДАНИЕ МЕТРИК НА ПРАКТИКЕ
73
Для данных табл. 7.1 расчет выглядит так:
Итоговый показатель = 3 х (-1) +2xl+7x0+8xl+6xl+lx
х 1 + 4х 1 + 5 х 1 = -3 + 2 + 04-8 + 6 +1 +4 + 5 = 23.
Диапазон возможных значений здесь — от 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,47 +0,08
Управление финансами -0,24 -0,34 + 0,10
Подобный подход способен благоприятно влиять на уровень зрелости
каждого процесса и, как следствие, всего ИТ-подразделения.
Как было показано выше, организации могут выбирать из нескольких
методов представления результатов в количественной форме. Главное
здесь — еще до начала каких бы то ни было измерений иметь четкое пред-
ставление о том, как пользоваться этими методами и как интерпретировать
полученные результаты.
Таблица 7.3 демонстрирует количественную метрическую схему в фор-
мате, который можно использовать при работе с управленческой инфор-
мацией. Метрики пронумерованы, чтобы впоследствии было удобно на них
ссылаться.
Таблица 7.3
Метрическая схема для управления конфигурированием
Метрика Опасность Цель Возможные значения
1. Степень удовлетворенности клиентов <3 4 0-5
2. Количество неиспользуемых лицензий >10 5 Не ограничено
74
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Окончание табл. 7.3
Метрика Опасность Цель Возможные значения
3. Количество RFC, отклоненных из-за ошибочных данных CMDB >20 10 Не ограничено
4. Количество неавторизованных конфигураций >15 5 Не ограничено
5. Количество инцидентов, связанных с некорректными изменениями из-за неправильно документированных □ >6 0 Не ограничено
6. Количество нарушений SLA, вызванных ошибками CMDB >2 0 Не ограничено
7. Количество RFC без обновления CI <90 95 Не ограничено
8. Процент некорректных CI >100 40 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. Одним из
главных преимуществ внедрения процессов «как есть» является возможность
сравнить опыт и даже контрольные данные с другими организациями, вы-
бравшими тот же путь.
Стандарт IS020000 и его национальные эквиваленты в ряде стран (на-
пример, 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
Поддержка приложений (ЕЛ)
Метрики для поддержки приложений:
• Число проанализированных программны; ошибок.
• Число оптимизаций.
• Число приложений/ревизий, выпущенных в производство.
• Число учебных занятий для конечных пользователей.
• Число дефектов, обнаруженных по журналам регистрации.
• Число временных решений, протестированных и выпущенных в произ-
водство.
• Число временных решений, возвращенных для доработки.
Разработка приложений (Е.2)
Метрики для разработки приложений:
• Число ошибок, выявленных при разработке или тестировании.
• Число ошибок, исправленных при тестировании.
• Число зарегистрированных ошибок, которые были исправлены.
• Число приложений/ревизий, принятых к использованию.
• Число приложений/ревизий, отклоненных службой поддержки прило-
жений.
• Число разработок приложений, одобренных компанией.
• Число успешных сборок приложений.
• Число дней, потраченных на развертывание приложения.
8.1.6. Управление операциями/инфраструктурой ИНТ (F)
Управление операциями рассматривается в ITIL как составная часть управ-
ления инфраструктурой ИКТ, которое, в свою очередь, включает разработку
и планирование, ввод в эксплуатацию, операции и техническую поддержку.
Однако представляется более логичным приписать этапы разработки сущест-
вующим процессам управления изменениями или релизами, и тогда управ-
ление операциями в чистом виде окажется частью управления ИТ-услугами.
Но процесс по определению не может заниматься инфраструктурой — это
следует из разграничения процесса, продуктов и функциональных обязан-
ностей персонала. По данной причине мы вводим группу процессов, назы-
ваемую «Управление операциями».
Рассматривая управление инфраструктурой ИКТ в рамках процесса уп-
равления операциями, мы используем традиционную классификацию, и это
должно помочь читателям, недостаточно знакомым с ITIL. Метрики для уп-
равления инфраструктурой ИКТ:
• Число планов, одобренных компанией.
• Число планов, не готовых для одобрения.
82
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
• Отставание от плана внедрения.
• Число проблем, возникших при внедрении.
• Число серьезных или критически^ событий на один управляемый
объект.
• Число событий, угрожающих информационной безопасности.
• Число сбоев при выполнении задаТ)Ий/скриптов/резервного копиро-
вания.
• Число инцидентов, вызванных изменениями, которые возникли в ре-
зультате выполнения операций.
• Степень удовлетворенности клиентов.
8.2, iVerpWAW для- гоАтйччгса'йЧ: процессов
управления услугами
8.2.1. Управление уровнем обслуживания (G)
Метрики для управления уровнем обслуживания:
• Число случаев нарушения SLA.
• Число случаев, когда SLA находится Под угрозой нарушения.
• Процент SLA, требующих изменение.
• Число пересмотров SLA, произведенных своевременно.
• Число нарушений SLA по вине внешг1ИХ подрядчиков, осуществляющих
поддержку.
• Затраты на предоставление услуг.
• Число услуг, не охватываемых 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. Управление мощностями (3)
Метрики для управления мощностями:
• Число нарушений SLA из-за недостаточно быстрого обслуживания.
• Число нарушений SLA из-за недостаточной производительности компо-
нента.
• Число инцидентов, вызванных недостаточной производительностью
или мощностью.
• Стоимость разработки плана развития мощностей.
• Число незапланированных приобретений аппаратных средств, нужных
для повышения производительности.
• Степень достоверности (в процентах) плана предстоящих расходов.
• Процент избыточной производительности ИТ.
• Процент CI, для которых ведется мониторинг производительносги.
• Степень удовлетворенности клиентов.
• Соотношение (в процентах) между общей и ожидаемой загрузкой ИТ-ре-
сурсов.
8.2.5. Управление непрерывностью предоставления ИТ-услуг (К)
Метрики для управления непрерывностью предоставления ИТ-услуг (IT Ser-
vice Continuity — ITSC):
• Число услуг, не охватываемых планом ITSC.
• Задержка с подготовкой/обновлением плана ITSC.
• Задержка с тестированием плана ITSC.
• Число проблем, выявленных при последнем тестировании и еще не
решенных.
• Результаты опроса по осведомленности о непрерывности предоставле-
ния ИТ-услуг проведенного выборочно — процент удовлетворительных
ответов.
• Число выявленных за данный период проблем, которые ставят под уг-
розу план ITSC.
• Число писем, предназначенных для конкретной группы сотрудников.
• Число неверных записей в справочнике группы кризисного контроля.
• Запаздывание готовности резервных мощностей.
• Степень удовлетворенности клиентов.
8.2.6. Управление доступностью (L)
Многие метрики управления доступностью ооязаны своим происхождением
жизненному циклу инцидентов — ведь те самым непосредственным образом
связаны с периодами полной или частичной недоступности. В ключевых
Глава 8. СПЕЦИФИЧЕСКИЕ МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
85
публикациях 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, QoE) — мера удовлетворенности
бизнеса, соотнесенная с его потребностями.
Воспринимаемое качество обслуживания обеспечивется следующим об-
разом:
• приведение ИТ-услуг в соответствие с потребностями бизнеса и его
клиентов;
• улучшение качества этих ИТ-услуг;
• сокращение расходов на оказание этих услуг.
В рамках управления непрерывностью бизнеса описываются обязанности
и возможности, с помощью которых менеджер компании может улучшить
одну из ключевых услуг, привносящих вклад в продуктивность и эффектив-
ность бизнеса. Это может быть достигнуто с помощью:
• изменений в ИТ-инфраструктуре; такие изменения способны повлиять
на формы ведения бизнеса и непрерывность бизнес-операций, однако
важно, чтобы руководители бизнеса обращали на них внимание и за-
ботились о мерах против неблагоприятных побочных эффектов;
• радикальной трансформации бизнес-практики, в результате чего будет
обеспечен контроль деятельности ИТ-подразделения и его интеграция
с бизнесом;
• партнерских и аутсорсинговых соглашений.
К бизнес-планированию относятся четыре процесса:
1 ) управление взаимоотношениями с бизнесом;
2 ) управление взаимоотношениями с поставщиками;
3 ) планирование, анализ и развитие;
4 ) взаимодействие, обучение и информирование.
Глава 8. СПЕЦИФИЧЕСКИЕ МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
87
Следующие три метрики предназна ены для оценки бизнес-планирования
в целом:
• Средние затраты на предоставление одной услуги.
• Степень удовлетворенности клиента.
• Знание бизнеса сотрудниками ИТ-подразделения.
Еще 13 метрик относятся к определенным бизнес-процессам, таким обра-
зом, общее число метрик для бизнес-планирвоания — 16.
Управление взаимоотношениями с бизнесом (N.1):
• Число жалоб на обслуживание.
• Число невыполненных действий с момента последней проверки данно-
го сервиса.
Управление взаимоотношениями с поставщиками (N.2):
• Максимальное число инцидентов, связанных с одним поставщиком.
• Процент постоянных поставщиков, удовлетворяющих стандартам (на-
пример, IS020000).
• Процент проверок качества услуг поставщиков на соответствие опреде-
ленным требованиям, проведенных в срок.
• Число нерешенных проблем, относящихся к поставщикам.
Управление поставкой услуг (N.3):
• Минимальная оценка степени удовлетворенности клиентов.
• Число инцидентов.
• Степень удовлетворенности клиентов.
Планирование, анализ и развитие (N.4):
• Число проблем, выявленных при окончательной проверке плана.
• Число планов, одобренных для реализации.
Взаимодействие, обучение и информирование (N.5):
• Число действий, предусмотренных планом информирования, которые
не были выполнены в срок.
• Процент ИТ-персонала с неоптимальным для занимаемой должности
уровнем подготовки.
8.3.2. Постоянно действующая программа
по улучшению услуг (0)
Постоянно действующая программа по улучшению услуг (Continuous Service
Improvement Programme — SIP) охватывает все процессы ИТ-подразделения.
Вообще в сложных системах нежелательно менять сразу многое: это часто
88
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
приводит к негативным последствиям, и трудно определить, какое именно
изменение отвечает за тот или иной результат.
По этой причине в SIP приоритетность изменений устанавливается в за-
висимости от эффективности изменяемого процесса и его значимости для
бизнеса.
В разделе 4.4 стандарта 15020000-1:2002 рассматриваются действия, не-
обходимые на стадии постоянного улучшения (соответствующей последнему
элементу в стандартном цикле Деминга Plan — Do — Check — Act — «Пла-
нирование — Выполнение — Проверка — Действие»). Результаты метрик,
описанных в настоящей книге, позволят выявить процессы, наиболее нуж-
дающиеся в улучшении. Влияние этих процессов можно будет обсудить с
представителями бизнес-подразделений и оценить по степени соответствия
SLA, а на основе полученных результатов разработать план для следующего
цикла. Согласно рекомендациям IS020000 такой план выполняется и оцени-
вается как проект. По завершении проекта эффективность плана может быть
измерена с помощью тех самых метрик и SLA, которые показали наличие
недостатков. Проверка плана, таким образом, обеспечивает структуру улуч-
шений для следующей программы SIP.
Как видим, SIP точно так же подчиняется циклу Деминга, как и реализа-
ция других процессов. Следовательно, можно рассматривать саму програм-
му по улучшению как процесс и составить для нее перечень метрик, который
позволит ее контролировать и отслеживать реальный прогресс. Владельцам
процессов важно проводить их модификацию в рамках процесса управления
изменениями, чтобы обеспечить ее отражение в метриках SIP наряду с фор-
мальными элементами программы. Метрики для SIP:
• Общая степень удовлетворенности клиентов.
• Процент экономии средств, достигнутой благодаря SIP последнего про-
цесса.
• Процент процессов, для которых SIP задерживается.
• Число действий, которые были одобрены, но не выполнены и не достиг-
ли цели.
• Число невыполненных действий, которые были записаны в плане ин-
формирования SIP.
• Число одобренных исправлений в политиках, планах и процедурах уп-
равления услугами.
• Число улучшений, внесенных владельцами процессов не в рамках цик-
ла SIP.
• Общий прогресс (в процентах) с момента последнего бенчмаркинга.
• Число рекомендаций по улучшению, полученных от владельцев других
процессов.
• Число изменений, требуемых для улучшения процесса.
• Число SIP, запланированных, но не осуществленных в срок.
Глава 8. СПЕЦИФИЧЕСКИЕ МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ УСЛУГАМИ
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, Aware-
ness and Training — CAT):
• Число действий, запланированных, но не выполненных во время кам-
пании по повышению осведомленности.
• Число должностных инструкций, в которых не конкретизированы тре-
бования к компетентности.
• Процент сотрудников ИТ-подразделения, квалификация которых офи-
циально признана в отрасли.
• Средний процент недостаточности уровня подготовки.
• Процент сотрудников, имеющих подписанный план индивидуального
развития.
• Процент ИТ-персонала с неоптимальным для занимаемой должности
уровнем подготовки.
• Процент сотрудников с уровнем компетентности, не удовлетворяющим
минимальным требованиям.
• Процент сотрудников, не выполняющих план индивидуального разви-
тия.
• Процент осведомленности сотрудников в целом по организации.
• Процент текучести кадров в сфере ИТ.
• Число требований к персоналу, которые не удалось удовлетворить.
• Процент сотрудников, не имеющих формально определенной роли или
сферы ответственности.
Глава 8. СПЕЦИФИЧЕСКИЕ МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
91
8.4. Метрики для управления программами
и проектами (S)
Метрики для управления программами и проектами:
• Число не достигнутых в срок контрольных точек.
• Общее время задержки проекта в текущем месяце.
• Число полученных результатов проекта.
• Число достигнутых результатов проекта в текущем месяце.
• Число выявленных рисков.
• Задержка критического пути1.
• Число эскалаций.
• Число несостоявшихся совещаний по проекту.
• Предполагаемая вероятность завершения проекта к намеченному сроку
в рамках бюджета.
• Степень удовлетворенности клиентов.
• Число задач, сформулированных на совещании по планированию про-
екта, которые не были выполнены.
Критический путь — самая длительная последовательность выполнения работ при реализа-
ции проекта, т. е. последовательность работ, показывающая минимально необходимое
время для завершения проекта. — Прим. пер.
_______________9
Интеграция метрик
В прошлом предпринималось множество попыток усовершен-
ствовать измере ние бизнес-процессов. Немало шагов было сде-
лано и в ИТ, главным образом по развитию уже существующих
метрик.
Недавние изменения привлекли внимание к измерениям в
других областях. Важным вопросом стало корпоративное управ-
ление — в первую очередь для крупных международных компа-
ний, но и для фирм поменьше тенденция та же. В процессах
управления услугами было заострено внимание на значимости
измерений. И ITIL, и IS020000, и COBIT, и Six Sigma, и eTom
предполагают использование метрик—именно метрики должны
обеспечить функционирование процессов таким образом, как
они спланированы, и служат основой д ля эффективных программ
по их улучшению.
Эти инициативы опирались на различные подходы и точки
зрения на ИТ. Как следствие, их результаты непосредственно
нельзя сопоставлять. Ниже рассказывается, как добиться интег-
рации метрик из разных схем.
Структура и полезность метрик определяются задачами, ле-
жащими в основе их разработки. Набор показателей, предназна-
ченный для руководящей деятельности, может оказаться беспо-
лезным, если нужно улучшить процессы поставок техники или
сократить затраты на ИТ.
Если метрики разработаны для того, чтобы контролировать
процессы управления услугами, способствовать сокращению
издержек и совершенствовать процессы, их можно использовать
и как источник информации для руководства.
94
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
9.1. Руководство бизнесом
Общее руководство бизнесом стало важной темой в последние годы. Был
предпринят ряд инициатив по улучшению корпоративного управления, и в
некоторых странах часть из них даже получила законодательное оформле-
ние (закон Сарбейнса — Оксли в США, Basel II в Европе и Кинг-2 в Южной
Африке). В числе главных аспектов — контроль, правильное применение и
размещение активов. Соответственно, в ITIL ядром процессов поддержки и
предоставления услуг являются управление конфигурациями и управление
изменениями, а стандарт IS020000 делает центральную контролирующую
функцию еще более конкретной.
При том, что процессы управления конфигурациями и изменениями со-
ставляют основу управления ИТ-услугами, они в качестве «побочного эффек-
та» управляют еще и жизненным циклом ИТ-активов.
По закону Сарбейнса — Оксли необходимо четкое разграничение между
аудиторами, проверяющими определенную область, и лицами, ответствен-
ными за нее, — этого же требует и стандарт ISOLOOOO. Комитет спонсорских
организаций комиссии Тредвея (COSO) разработал критерии для проверки
уровней руководства на соответствие контрольным параметрам управления
ИТ-услугами и требованиям закона Сарбейнса — Оксли, а если воспользо-
ваться, например, IS020000, эти схемы позволят оценить также и степень
зрелости корпоративного управления.
9.2. ITIL — IS020000 (BS15OOO)
Стандарт IS020000 (бывший BS15000 в Великобритании, AS8018 в Австра-
лии, SANS15000 в Южной Африке) состоит из двух частей. Первая, «Специ-
фикации для управления услугами», содержит перечень того, что непремен-
но должно быть реализовано, вторая — «Практические правила для управ-
ления услугами» — того, что компаниям тоже следовало бы осуществить.
Руководители большинства проектов захотят в конечном итоге выполнить
обе части. В действительности IS020000 охватывает не все процессы и функ-
ции 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.tmforum.org/browse.asp7catID=2024&linkID=29248 — прямая ссылка на документ.
еТОМ поддерживается на сайте www.tmforum.org. Зарегистрированные пользователи могут
скачать документ бесплатно, а незарегистрированные — за небольшую плату. —Прим. авт.
96
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
еТОМ, ее простого и прямого отображения на еТОМ не существует. Так что
данный документ носит рекомендательный характер и отражает ITIL сла-
бее, чем хотелось бы.
На самом высоком уровне соответствие можно рассматривать так, как
показано в табл. 9.1.
Таблица 9.1
Соответствие между еТОМ и ITIL
еТОМ ITIL
Управление качеством сервиса Доступность
Управление QoS (качеством обслуживания) /SLA для клиентов Уровень обслуживания
Обработка проблем Инцидент
Управление клиентским интерфейсом Служба Service Desk
Гервисная проблема / сбой в ресурсах Проблема
Конфигурирование и активация услуг / обеспечение услуг ресурсами Конфигурация
Стоит отметить, что многие термины в двух системах определяются по-
разному. Как можно видеть, слова «сервис» и «проблема» в правом и левом
столбцах таблицы означают не одно и то же.
С точки зрения метрик подход, использованный в настоящей книге,
можно расширить так, чтобы он подходил для высокоуровневых процессов
еТОМ.
9.4. СОВГГ
COBIT — это стандарт аудита, применяемый для проверки соответствия ИТ
действующему законодательству (например, закону Сарбейнса — Оксли).
Задачи контроля в COBIT хорошо согласуются с ITIL — при разработке стан-
дарта ITIL использовалась для определения категорий — и, как следствие,
с IS020000.
Так же, как и в ITIL, отправной точкой COBIT является каталог услуг, на
основе которого оценивается качество сервиса. Показатели SLA и метрики
процессов дают подробную картину того, как контролируется управление
ИТ-услугами. Если компания применяет или планирует применять COBIT в
качестве механизма аудита, то при реализации управления ИТ-услугами ей
имеет смысл провести бенчмаркинг соответствующих процессов и их метрик,
используя в качестве эталона задачи контроля, определенные в COBIT. Тогда
для метрик, выбранных компанией, еще до внедрения будет гарантировано
соответствие требованиям аудита.
Рассмотрим высокоуровневые задачи контроля, относящиеся к монито-
рингу:
Глава 9. ИНТЕГРАЦИЯ МЕТРИК
97
Ml — мониторинг процессов;
М2 — оценка объективности внутреннего контроля;
М3 — получение независимых гарантий;
М4 — проведение независимого аудита.
Как видим, структура IS020000 вполне с этим согласуется. Метрики, оп-
ределяемые и рассматриваемые в настоящей книге, непосредственно соот-
носятся с задачей Ml.
Только что был приведен один из примеров соответствия между COBIT и
ITIL — подробному описанию этих соответствий (отвлекаясь от метрик)
посвящен ряд книг. Например, изданное нидерландским ITSM-форумом
(ITSMF-NL) «Управление ИТ — карманное руководство на основе СОВ1Т»
(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.itil.
co.uk/includes/ITIL-COBiT.pdf —Прим. авт.
98
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
пройти несколько циклов программы по улучшению услуг (SIP) и отладить
как процессы, так и оценивающие их метрики.
Важно понимать, что модель Six Sigma, пришедшая из производства, по-
могает управлять процессом снижения числа дефектов, но не разрабатывать
метрики для управления услугами. Если в компании уже ведется проект Six
Sigma, есть опасность, что правильная последовательность ведения данного
проекта будет нарушена. Чтобы этого не допустить, нужно, как уже говори-
лось, сначала внедрить метрики и провести их через цикл совершенствования
процесса, а уже потом встраивать полученные результаты в структуру Six
Sigma.
Отметим также, что достижение высоких уровней качества в Six Sigma
может оказаться дорогим удовольствием. Даже для Motorola цена, которую
приходилось платить за качество, оказалась непомерной, и компания была
вынуждена снижать достигнутый уровень, чтобы повысить прибыльность.
При установлении целей Six Sigma важно руководствоваться здравым смыс-
лом, а не идеализмом. Найти правильный баланс между затратами и качест-
вом — очень непростая задача.
____________10
Реализация метрик
Люди могут измерять параметры, которые от них не зависят, —
например, количество света, излучаемого Солнцем. Это часто
интересно и помогает понять природу вещей, но контроль над
ними таким путем не обеспечивается.
Чтобы контролировать бизнес- или ИТ-процесс, нужно его
определить, а затем выполнять — иначе говоря, реализовать.
Метрику следует разрабатывать таким образом, чтобы требуе-
мую информацию давал работающий процесс, а участники
этого процесса понимали, что они могут сделать для улучшения
показателя, и стремились его улучшить. От изолированных
метрик можно ждать в лучшем случае интересных цифр — и ни-
чего более.
Из этой главы вы узнаете, как правильно вводить метрики и
как добиться того, чтобы они стали полезным механизмом конт-
роля и помогали компании держаться курса, выбранного руко-
водством.
Не зная пункта назначения, вы далеко не продвинетесь. Нуж-
на система управления (как описано в IS020000), которая «зна-
ет», куда нужно попасть, т. е. в ней заданы политика, задачи и
планы управления услугами.
10.1. Мероприятия
Чтобы обеспечить успешное управление ИТ-услугами, под-
разделение должно заручиться поддержкой со стороны како-
го-либо представителя высшего руководства компании или,
в терминологии ITIL, «спонсора» (executive sponsor). Иначе
100
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
любые попытки что-либо предпринять будут иметь мало успеха, в конеч-
ном итоге вызовут раздражение у инициаторов и окажутся неэффектив-
ными.
Поэтому первым делом необходимо проинформировать высшее руковод-
ство о преимуществах, затратах и требованиях к реализации. Если его удаст-
ся убедить в том, что компании нужно управление ИТ-услугами, то следует
внедрить систему управления, как это описано в разделе 315020000-1:20000
«Требования к системе управления».
Затем следует добиться общего понимания требований к мониторингу
процессов посредством установленных метрик, поскольку это является час-
тью принципов курса «Основы ITIL».
На этой начальной стадии идеально будет встроить во все процессы не-
который непротиворечивый, простой и сопоставимый набор метрик. Имен-
но такой подход предложен в настоящей книге. Его преимущество — в уп-
рощении задачи для владельцев процессов, у которых много работы по реа-
лизации составляющей «Люди — Процесс — Технология».
В идеале метрики для процессов проектируются параллельно с самими
процессами. В обширной литературе по проектированию процессов много
говорится о том, как важно не подстраиваться под имеющийся инструмен-
тарий. Действительно, процессы должны соответствовать требованиям ор-
ганизаций, и лишь в очень немногих случаях работу можно начать «с чис-
того листа». Поэтому наборы стандартных процессов, поставляемые кон-
сультантами или в составе различных инструментариев, нужно адаптировать
к условиям конкретной компании.
Разработка новых процессов с нуля — дело само по себе трудоемкое и
часто неблагодарное, так как результатом оказывается не реальное улуч-
шение, а набор документов. Ее можно упростить и ускорить с помощью
метрик из этой книги. Метрики можно подключать к стандартным про-
цедурам высокоуровневого проектирования для конкретных процессов,
учитывая реальные возможности выбранного инструментария (или того,
который, вероятно, будет выбран). Необходимо лишь выявлять особые
случаи, когда стандартный процесс не подходит для данной организации,
и там, где выбранное решение является наилучшим, вносить соответству-
ющие изменения. При данном подходе большинство процессов и метрик
используются «как есть», а все немногочисленные исключения хорошо
определены.
Естественно, проектирование по этой — как и по любой другой — схеме
не приведет к созданию идеальных процессов. Для усовершенствования
первоначальных разработок существует SIP, поэтому не надо бояться, что
компания навсегда застрянет на стадии неоптимального решения. Совсем
наоборот, она получит быстрое и простое для реализации решение, которое
можно будет в дальнейшем модифицировать в свете истинных потребнос-
тей бизнеса именно так, как это рекомендуется в ITIL!
Глава 10. РЕАЛИЗАЦИЯ МЕТРИК
101
10.2. Критические факторы успеха (CSF)
Главным CSF является преданная своему делу команда менеджеров — сис-
тема управления, включая политики и структуру, которые обеспечивают
эффективный контроль и реализацию всех ИТ-услуг (IS020000-1:2—2, раз-
дел 3. Задача).
Для эффективной работы этой системы жизненно важно выстроить и
выполнять качественный коммуникационный план.
Когда это сделано, можно включать в политику управления услугами
различные положения и рекомендации из этой книги, например:
«Политика по реализации метрик для процессов организации АВС заключа-
ется в том, что разрабатывается около десяти метрик на процесс таким
образом, чтобы их эффективность можно было измерять и методы проек-
тирования для разных процессов не противоречили друг другу. Цель это-
го — сделать возможным использование результатов метрик для сравнения
процессов с учетом их зрелости и совершенствования».
На практике сказанное означает, что при разработке или изменении про-
цесса его владелец будет консультироваться с владельцами других процессов,
проверяя совместимость и сопоставимость метрик. При обсуждении обяза-
тельно будет затронут вопрос о реальных базовых показателях. Здесь можно
разработать общую практику — например, всякий внедряемый процесс в
течение трех месяцев выполняется в тестовом режиме со стандартным набо-
ром метрик. Средний показатель трех лучших недель за этот период прини-
мается за базовый, а целевое значение устанавливается на несколько про-
центов выше.
Это прагматичный подход — показатели легко изменить, если окажется,
что их слишком просто или, наоборот, слишком сложно достичь. При его
использовании метрики с большой вероятностью будут удобными и смогут
предоставлять ценную управленческую информацию. Итак, перечислим
CSF:
• Поддержка системы управления;
• Качественный коммуникационный план;
• Непротиворечивая разработка процесса;
• Непротиворечивая разработка метрик;
• Непротиворечивый метод мониторинга и сбора информации;
• Сбор информации и мониторинг, независимые от владельцев про-
цессов;
• Проектирование метрик в соответствии с принципами, рассмотренны-
ми в главе 8.
102
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
10.3. Возможные проблемы
И когда метрик слишком мало, и когда их слишком много, и когда они
просто-напросто плохо спроектированы, результаты могут быть чудовищ-
ными.
В стандарте IS020000 подчеркивается значение системы управления,
поддерживающей управление услугами. Это очень существенный момент.
Если владельцы не могут влиять на показания метрик, то эти метрики будут
иметь ограниченное влияние на их поведение. То же самое произойдет и в
отсутствие системы управления, способной привлечь к метрикам достаточное
внимание со стороны менеджеров.
Если менеджеры не рассматривают метрики как ценный способ измере-
ния индивидуальных усилий (с последующим их поощрением), у сотрудни-
ков не будет никаких стимулов к улучшению показателей. Жизненно важно,
чтобы система управления действовала, а регулярные проверки и оценка
сотрудников индивидуально, используя показания метрик, подкрепляли в
менеджерах понимание значимости используемых метрик. В противном
случае, даже если поначалу и будет какой-то энтузиазм, через некоторое
время внимание переключится на другие вопросы и качество предоставления
услуг ухудшится.
Если метрики не удовлетворяют критериям разработки, перечисленным
в первых главах (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 не по
желанию, а по необходимости, и измерение, таким образом, зависит от ряда пере-
менных.
Возможные причины увеличения числа звонков очень разнообразны и проти-
воречивы, например:
• плохое качество поддержки способствует увеличению числа звонков, пото-
му что пользователь вынужден звонить до тех пор пока проблема не разре-
шится;
• хорошее качество поддержки способствует увеличению числа звонков, по-
тому что служба нравится пользователям и они чаще туда обращаются;
• простое информирование пользователей о наличии единой центральной
точки контактов само по себе повышает число звонков;
• новый релиз или изменение ПО привлечет больше звонков;
• изменения в кадровом составе или практике работы приводят к росту числа
звонков из-за появления пользователей, не очень хорошо знакомых с данной
службой; В
В рамках текущего проекта по обновлению ITIL готовится переработанное издание этой
книги, которое будет называться «Реализация IT1L в малых масштабах» («ITIL small-scale
Implementation»). —Прим. авт.
Глава 10. РЕАЛИЗАЦИЯ МЕТРИК
107
• работа может быть сезонной, тогда в определенное время года будут исполь-
зоваться малознакомые части ИТ-системы;
• может существовать проблема с предоставлением услуги, такие как:
— изменения, не протестированные должным образом;
— ПО, не синхронизированное с распределенной системой;
— сбой сети или компьютерной аппаратуры.
Как видим, метрики не независимы и интерпретировать их непросто; из того,
что показатель легко подсчитать, еще не следует, что он должен стать ключевым
в управлении ИТ-услугами.
Другой известный пример — это оказавшее сильное влияние на всех нас
использование в центрах обработки вызовов метрики «Продолжительность
звонка» (см. раздел 6.6). Из-за этого критерия операторы стремятся «закрыть
заявку», а не заниматься тем, что нужно клиенту. Зачастую они, еще не
разобравшись с проблемой, спрашивают: «Можно я сейчас закрою этот
звонок?» и доходят даже до того, что предлагают позвонить к ним снова по
тому же самому вопросу (так как сохранение открытой заявки снизит коэф-
фициент закрытия). Такой подход не повышает степень удовлетворенности
клиентов!
В данном примере и ИТ-подразделение, и клиенты заинтересованы в том,
чтобы заявки не оставались подолгу открытыми, а своевременно обрабаты-
вались. Неправильно только делать соответствующий показатель единствен-
ным или главным. Есть два простых способа справиться с проблемой. Первый
заключается в подсчете повторных звонков по одному вопросу. Если это
обычное явление, значит, метрика закрытия заявок провоцирует неоказание
поддержки клиенту и нужно проследить, чтобы операторы не открывали
новых заявок по тому же или похожему вопросу.
Второй вариант — опереться на данные исследования степени удовлетво-
ренности клиентов: если пользователям не нравится, что их просят прервать
звонок ради удобства оператора, это будет заметно, и тогда можно присвоить
степени удовлетворенности более высокий приоритет.
Механизм приоритетов позволяет тонко регулировать относительную
значимость требований. Зная, что удовлетворенность клиентов важна, опе-
раторы станут заботиться сначала о том, чтобы клиент остался доволен ре-
шением проблемы, и только потом — о закрытии заявок. Если через некото-
рое время продолжительность звонков возрастет до недопустимой величины,
приоритеты можно будет снова пересмотреть.
Этот подход, принятый в настоящей книге, использует логику, которую
рекомендовал для человеческих взаимоотношений Макиавелли. Он предла-
гал подумать, какое поведение наиболее вероятно, когда задана определен-
ная цель. Хороший тест — «Что бы я сделал, если бы передо мной была
108
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
поставлена эта задача?» Если ответ отличается от истинной задачи метрики,
можно использовать дополнительную метрику в качестве противовеса. На-
пример, «продолжительность звонка» компенсируется «удовлетворенностью
клиента».
Такова одна из движущих сил, определяющих выбор метрик. Все мы будем
стараться сделать максимум возможного для выполнения задач организации,
и все-таки наша главная цель — преуспеть самим. Если метрики побуждают
нас делать то, что хорошо для нас, но не ,для организации, проблема в мет-
риках, а не в нас!
Приведенные примеры довольно известны, а в реальной жизни непреду-
смотренные последствия внедренных метрик обычно проявляются менее
явно. Важно следить за реальным функционированием метрик, дабы убе-
диться, что они измеряют истинные переменные процесса, а эти переменные
связаны с аредосгашисеыыми услугами и v*e являются просто бюрократичес-
ким вмешательством в работу людей. Неплохо начать с уравновешивания
различных показателей, как это рекомендовано выше, но только реальные
встречи с участниками процесса позволят выяснить, чем они занимаются и
как метрика встраивается в их деятельность. Возможно, стоит включить
проверку полезности и корректности метрик в план по улучшению услуг.
10.4. Отчетность по услугам
Главной целью отчетности по услугам является эффективное донесение
информации до адресата. Эта задача решается за счет ясности и визуаль-
ного воздействия.
«Лучше один раз увидеть, чем его раз услышать».
Многие организации устанавливают собственные стандарты отчетности.
Цель любого отчета — представить ганньге в понятной, недвусмысленной и
простой для понимания форме. Для этого используется целый ряд различных
графических методов.
Многие пакеты визуальной отчетности позволяют строить цветные кру-
говые и лепестковые диаграммы, гистограммы, линейные графики, трех-
мерные представления данных. Набор значений можно легко отобразить в
любом из этих форматов. Но остерегайтесь слишком красивых графиков —
они могут отвлечь внимание от содержащейся в них информации. Стремить-
ся надо к простоте и ясности, а не к внешнему изяществу. На практике
применяются:
• секторная диаграмма для сравнения по компонентам;
• гистограмма для сравнения по единицам продукции;
• столбчатая диаграмма для сравнений по временным рядам;
Глава 10. РЕАЛИЗАЦИЯ МЕТРИК
109
• линейный график для распределения частот;
• точечная диаграмма для корреляций.
В отчетах по метрикам наиболее важны три представления:
1. Историческое представление. Как шли процессы в несколько послед-
них отчетных периодов? Это позволяет понять контекст краткосрочных
«всплесков» и, с одной стороны, избежать паники, когда ситуация в
целом вполне приемлема, а с другой — заранее выявить опасные тен-
денции, даже если текущие результаты представляются хорошими, и
предпринять необходимый действия еще до того, как ситуация начнет
отражаться на бизнесе.
2. Представление относительно других процессов. Насколько успешно
прогрессирует компания в целом? Какой процесс работает лучше всех?
Насколько эффективны процессы по сравнению с аналогами в других
организациях? Этот подход позволяет корректировать план по посто-
янному улучшению.
3. «Моментальный снимок» текущего состояния. Какие проблемы воз-
никали за последний отчетный период? Насколько они серьезны? Как
предотвратить их повторное возникновение?
Хотя многие отчеты можно формировать автоматически с помощью инст-
рументария управления услугами или средств построения отчетов, их обос-
нованность обязательно нужно проверять и вручную. В соответствии с прин-
ципами аудита, изложенными в IS020000, за создание и проверку отчетов
по услуге и за предоставление этой услуги должны отвечать разные лица. Для
каждого отчета вопрос о его необходимости подлежит пересмотру раз в пол-
года (или в квартал), составление отчетов, признанных ненужными, прекра-
щается.
В IS020000 дается следующая формулировка задач отчетности по услу-
гам:
«Создавать согласованные, своевременные, надежные и точные отчеты для
принятия обоснованных решений и эффективной коммуникации». Далее
говорится о необходимости понятного описания каждого отчета об услугах,
включая данные о заглавии, цели, аудитории и об источнике данных
(IS020000-1: 2004).
Если данные в регулярных отчетах все время представлены в одном и том
же формате, есть опасность, что из-за однообразия останется незамеченной
важная информация. По этой причине часто полезнее создавать так назы-
ваемые исключительные отчеты, т. е. когда процесс (или процессы) демонст-
рируют значительное улучшение или неожиданное ухудшение, выпускать
110
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
специальное сообщение, где будет также сказано, что способствовало успе-
ху либо что запланировано для исправления положения. Отчет просто о том,
что все идет своим чередом, как обычно, не побуждает к действию и не
представляет большой ценности.
Распространение бумажных отчетов стоит дорого, отнимает много време-
ни, и их зачастую не читают (см. раздел 2.4). Вспомните ответ в опросе об
их пользе: «Пожалуйста, продолжайте их присылать: моей дочурке так нра-
вится рисовать на них!» Наверное, разумнее размещать отчеты на внутри-
фирменном веб-сайте, где они доступны для всех сотрудников, и рассылать
по электронной почте письма с описанием исключений. Тогда заинтересо-
ванные стороны смогут, когда это нужно, знакомиться со свежими отчетами,
но будут это делать только при возникновении конкретной необходимости.
Вне зависимости от того, как вы распространяете отчеты — на бумаге
или через веб-сайт, в календарном плане должны быть предусмотрены ре-
гулярные собрания с ключевыми участниками бизнеса с целью обсуждения
и согласования главных показателей эффективности. Если позволить людям
обращаться к данным только тогда, когда им это понадобится, данные ока-
зываются под угрозой полного игнорирования.
Раздел 10.4.1 содержит отчеты по всем процессам за одну неделю, а также
график, показывающий сравнительное улучшение различных показателей
за три месяца.
10.4.1. Представление метрик
Представлять информацию руководству нужно в понятной форме, подчер-
кивая аспекты, требующие внимания, и избегая чрезмерной детализации.
Метрики, описанные в этой книге, спроектированы так, чтобы оценивать
все процессы примерно одинаковым образом; для уравновешивания одно-
сторонних, по преимуществу технических показателей среди них присут-
ствует степень удовлетворенности клиентов. Многие целевые показатели не
нужны сами по себе — они имеют смысл только при сопоставлении либо с
эталонным (базовым) уровнем, достигнутым в другой организации, либо с
более ранними собственными результатами.
В отрасли, характеризующейся высокой сезонностью, данные за истекший
квартал стоит сравнивать с данными за аналогичный период прошлого года.
Естественно, для вывода о том, что эффективность процесса снизилась (или
повысилась), одного взгляда на показатели недостаточно, ведь есть множес-
тво факторов, способных вызвать временный «всплеск». Однако рассмотре-
ние тенденции за последние полгода должно сгладить соответствующие
эффекты и дать более ясную картину .
В регулировании общего направления интерес представляют не столько
многочисленные детали, сколько возможность сравнивать процессы, учиты-
вая тенденцию нескольких последних месяцев. Ниже приводятся несколько
Глава 10. РЕАЛИЗАЦИЯ МЕТРИК
111
примеров того, как представлять эту информацию, с необходимыми поясне-
ниями. За недостатком места мы не можем осветить здесь алгоритмы обра-
ботки, применяемые для определения тенденций, поэтому приводим лишь
результаты.
В графике на рис. 10.1 показатели для управления изменениями сведены
к одному значению для каждого месяца. Это значение включает все метрики
с учетом их веса (приоритетов), согласованного между руководством и вла-
дельцем процесса, и, таким образом, приведено к виду, позволяющему срав-
нивать его с другими процессами. Для процесса управления уровнем серви-
са используются, как мы знаем, совершенно другие метрики, но его график
будет похож на этот.
Интерпретация трех линий:
• линия совокупной необработанной оценки показывает, что в течение
данного периода процесс был близок к значению 5;
• эффективность относительно согласованного целевого значения —
самый лучший показатель для сравнения процессов. Как видим, начало
было неутешительным, в марте произошло улучшение, но потом дела
пошли на спад;
• эффективность относительно среднего значения показывает успехи
управления изменениями по сравнению со средней эффективностью за
данный период. Здесь также видны значительное улучшение в марте и
последующий спад;
• кроме того, есть линия, показывающая отклонение необработанной
оценки;
Результаты по метрикам для управления изменениями
за первое полугодие 2006 года
Совокупная необработанная оценка.
Результаты по метрикам для управления изменениями
за первое полугодие 2006 года.
Совокупная оценка (0-10)
о Отклонение необработанной оценки.
Результаты по метрикам для управления изменениями
за первое полугодие 2006 года.
Изменение за период
Эффективность относительно
среднего значения.
Результаты по метрикам для управления изменениями
за первое полугодие 2006 года.
Отклонение от среднего в процентах
— Целевое значение.
Результаты по метрикам для управления изменениями
за первое полугодие 2006 года.
Целевое значение
“°" Эффективность относительно согласованного
целевого значения.
Результаты по метрикам для управления изменениями
за первое полугодие 2006 года.
Отклонение от целевого значения в процентах
Рис. 10.1. Пример, демонстрирующий метрики управления изменениями
112
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
• линия целевого значения отражает его изменение за период. Оно бы-
ло установлено слишком высоким и представлялось недостижимым, но
потом его удалось превзойти.
Чтобы выяснить, почему это все произошло, необходимо дополнительное
исследование. Но при беглом взгляде видно, что в целом эффективность
управления изменениями росла, хотя в последние два месяца результаты
были не так высоки, как в апреле. Получить ту же информацию, имея перед
собой подробные метрики за полугодие, было бы гораздо сложнее.
График, представленный на рис. 10.2, показывает сразу все метрики.
Даже при том, что совокупность показателей для каждого процесса сведена
всего к одному числу, картина остается запутанной. Видно, что худшие общие
результаты (самое низкое среднее значение) у управления релизами, а луч-
шие — у SIP. Но интереснее всего майский рост эффективности до пикового
значения и ее июньский спад. Вероятно, в работе компании присутствует
сильная сезонная тенденция. Еще более обобщенную картину процессов
дает лепестковая диаграмма (рис. 10.3).
Судя по бледно-серой линии, соединяющей средние значения на диаграм-
ме, самой проблемной областью является документация, тогда как наиболь-
шего успеха (к счастью!) достигла SIP, поэтому можно надеяться, что в бу-
дущем дела пойдут хорошо.
Все метрики
-А- Управление инцидентами
значение
•=- Управление документацией
Рис. 10.2. Совокупные показатели по всем метрикам
Глава 10. РЕАЛИЗАЦИЯ МЕТРИК
ИЗ
Все метрики
Программа по постоянному
улучшению услуг
(SIP)
Управление документацией
Управление проблемами
Управление непрерывностью
предоставления ИТ-услуг
Управление Операциями
Управ.ление релизами
Управление программами
и проектами
Метрики перспективы бизнеса
Управление конфигурациями
Управление уровнем сервиса
Управление доступностью
Управление рисками
Служба Service Desk
Управление финансами для ИТ-услуг
Управление инцидентами
Компетентность, осведомленность,
обучение (CAT)
Упдййление мощностями Управление
безопасностью
Рис. 10.3. Средние показатели за последние шесть месяцев (лепестковая диаграмма)
Управление изменениями
Средние значения
-Ш- В текущем месяце
Теперь перейдем к рассмотрению темно-серой линии. В реальной жизни
подобный разброс значений маловероятен, тем не менее мы видим, что на-
именее успешными в этом году оказались служба Service Desk и процессы:
управление изменениями, группа процессор бизнес-перспективы, управление
проблемами, управление документацией. Было бы полезно сосредоточить на
них внимание SIP, особенно это относится к двум последним процессам,
поскольку в течение всего периода они демонстрировали плохие показатели
относительно целевого значения.
11
Постоянное
совершенствование
с помощью метрик
— А ну, давай! — кричала Королева. — Еще быстрее!
И они помчались так быстро, что, казалось, скользили по
воздуху, вовсе не касаясь земли ногами, пока, наконец, Алиса
совсем не выбилась из сил. Внезапно они остановились, и Алиса
увидела, что сидит на земле и никак не может отдышаться.
Королева прислонила ее к дереву и сказала ласково:
— А теперь можешь немного отдохнуть!
Алиса в изумлении огляделась.
— Что это? — спросила она. — Мы так и остались под этим
деревом! Неужели мы не стронулись с места ни на шаг?
— Ну, конечно, нет, — ответила Королева. — А ты чего
хотела?
— У нас, — сказала Алиса, с трудом переводя дух, — когда
долго бежишь со всех ног, непременно попадешь в другое место.
— Какая медлительная страна! — сказала Королева. — Ну,
а здесь, знаешь ли, приходится бежать со всех ног, чтобы толь-
ко остаться на том же месте! Если же хочешь попасть в другое
место, тогда нужно бежать по меньшей мере вдвое быстрее!
Льюис Кэрролл «Алиса в Зазеркалье»1
Черная Королева из Зазеркалья сказала, что в ее стране при-
ходится бежать со всех ног, чтобы остаться на том же месте.
Задумайтесь об этом: организациям нужно постоянно совер-
шенствоваться, чтобы удержать свои позиции. Многие учения
об управлении поддерживают такой подход и настаивают на
1 Перевод Нины Демуровой.
116
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
постоянном улучшении качества предоставления услуг: среди них и цикл
Деминга — «План — Выполнение — Проверка — Реагирование» (Plan —
Do — Check — Act), и руководство Six Sigma «Определение, измерение, ана-
лиз, совершенствование и контроль» (Define, Measure, Analyze, Improve and
Control).
У всех этих концепций есть одна общая особенность: без измерения по-
казателей процесса они не были бы в состоянии реально изменить культуру
и результаты деятельности компании. Но как подстраивать цели метрик под
постоянно меняющиеся потребности организации и как менять сами метри-
ки по мере созревания процессов и организаций?
Если девять из десяти метрик процесса неизменно выполняются, а одна нет,
то следует обратить внимание на эту одну, выяснить, в чем ее особенность,
как можно разложить ее на составляющие и оценить более подробно.
Недавно одна крупная организация расформировала отдел отчетности,
насчитывающий свыше сотни сотрудников: выяснилось, что выпускавшиеся
отчеты не только не использовались для принятия важных решений бизнеса,
но еще и дублировали информацию, которую можно было легко получить из
других источников. Опасность очевидна: если допустить, чтобы подготовка
отчетов, как это бывает в бюрократических организациях, существовала в
качестве отдельной функции, не была связана с программой по постоянному
улучшению качества предоставления услуг (SIP) и не оценивалась с точки
зрения полезности и эффективности, то она может поглотить значительно
больше ресурсов, чем представляется разумным с точки зрения компании.
Важно понимать, что именно может быть предпринято, если результат
некоторой метрики выходит за пределы желаемого диапазона. Если никаких
конкретных действий на этот случай не предусмотрено, лучше вообще не
собирать соответствующие данные: сбор информации стоит денег и оправ-
дывается только полезностью информации, т. е. ее дальнейшим эффектив-
ным использованием
Если метрики, передаваемые в подразделение управления услугами, слиш-
ком подробны, то даже незначительные изменения в самом процессе, про-
изведенные в соответствии с треби маниями SIP, в состоянии сделать сбор
данных невозможным. Чтобы этого избежать, метрики должны измерять
фундаментальные части процесса, вносящие вклад в его эффективность.
Программные инструменты для управления услугами позволяют измерить
несколько сотен показателей, однако многие из этих метрик совершенно
бесполезны для принятия решений по улучшению процесса — они измеримы,
но несущественны и малопригодны для дальнейшего использования.
Стоит взглянуть на задачи, выполняемые метриками. При рассмотрении
управления услугами сверху вниз бизнес формулирует свой взгляд на то,
куда он стремится и что ему нужно, ’’тобы туда добраться. Отсюда вытекает
стратегия, а из нее, в свою очередь, — планы, политика и задачи, определя-
ющие, что должно быть сделано. Данное понимание перспективы позволяет
Глава 11. ПОСТОЯННОЕ СОВЕРШЕНСТВОВАНИЕ С ПОМОЩЬЮ МЕТРИК
117
увидеть, почему одни метрики с точки зрения курса, взятого компанией, не
слишком интересны, а другие исключительно важны. Не всегда получается
разрабатывать метрики именно таким обрДзом, но это хорошая проверка их
разумности перед использованием.
В этой книге сделана попытка преддо^ить подобный список значимых
метрик, каждая из которых привязана к ч₽тко обозначенной цели и задаче
процесса. Кроме того, здесь рассказывается о правилах самостоятельного
построения метрик, даются советы по их использованию, рассматриваются
способы их представления и сравнения друг с другом. В приложениях, кото
рые следуют далее, вы найдете подробное описание и объяснение всех мет-
рик, перечисленных в главе 8. Их можно адаптировать к конкретным по-
требностям вашей организации.
A
Метрики
для управления инцидентами
Главная цель процесса управления инцидентами заключается в том,
чтобы как можно быстрее (и в установленный срок) восстановить нор-
мальное функционирование сервиса и минимизировать неблагоприятное
воздействие инц ад( нта на бизнес-операции, тем самым поддерживая ка-
чество и доступность обслуживания на самом высоком уровне. «Нормаль-
ным» считается функционирование сервиса в рамках соглашения об уров-
не услуг (SLA).
(Библиотека ITIL, том «Поддержка услуг»)
Миссия: минимизировать воздействие сбоев сервиса на бизнес-процес-
сы организации, восстановив его путем эффективного управления ин-
цидентами.
Владелец процесса: менеджер инцидентов.
Задача метрики: предотвратить нарушение согласованных уровней сер-
виса, обеспечив своевременное устранение инцидентов.
Метрика:
Описание:
Спецификация:
Обоснование:
Процент инцидентов, решенных на первой
линии поддержки (% инцт тентов}
Сколько инцидентов не требуют эскалации на вто-
рую линию поддержки.
Количество инцидентов, не требующих эскалации.
Измеряет несколько параметров. Если у службы
Service Desk имеется хорошая база данных по извест-
ным ошибкам, поставляемая управлением проблема-
120
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
ми, количество инцидентов, устраняемых первой ли- нией поддержки, вырастет.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Если процесс управления проблемами успешно лик- видирует коренные причины, доля инцидентов, раз- решение которых возможно на первой линии под- держки, сократится, вследствие чего может умень- шиться и число фактически разрешенных на ней инцидентов.
Опасное значение- <65
Целевое значение 85
Возможные значения: 0-100
Метрика: Средняя тродолжительность обработки инци- дента до момента эскалации {минусы}
Описание: Показатель эффективности. Уравновешивается мет- рикой степени удовлетворенности клиента, посколь- ку обслуживание заявки должно длиться столько, сколько необходимо, чтобы удовлетворить запросы пользователя по решению проблемы. С хорошим инс- трументарием и БД по известным ошибкам этот по- казатель можно уменьшить.
Спецификация: Метрика показывает, сколько длится обработка ин- цидента до момента эскалации.
Обоснование: Слишком быстрое закрытие заявки вредно с точки зрения удовлетворенности клиентов. Задача службы Service Desk заключается в эффективной обработке заявок, а метрика отражает степень этой эффектив- ности.
Аудитория: Владелец процесса, руководство ИТ, владелец процес- са SLA, бизнес-клиент, члены команды, владелец про- цесса SIP.
Ограничения: Нет
Опасное значение: >20
Целевое значение: 10
Возможные значения 999999
А. Метрики для управЛения инцидентами
121
Метрика: Процент инцидентов, некорректно назначен- ных на сотрудников службы поддержки {% инцидентов}
Описание: Измеряется путем проверки истории заявок и нахож- дения переназначенных.
Спецификация: Сколько инцидентов назначены не той рабочей группе.
Обоснование: Переназначение заявок замедляет решение и снижает эффективность работы команд. Чтобы снизить этот показатель, нужны действенные сценарии обработки обращений, обучение, инструментарий и соответ- ствующие процессы.
Аудитория: Владелец процесса, руководство ИТ, владелец процес- са SLA, бизнес-клиент, члены команды, владелец про- цесса SIP.
Ограничения: Нет
Опасное значение: 30
Целевое значение: Возможные знайения: 20 0-100
Метрика*. заданного времени согласно приоритету {% инцидентов}
Описание: Когда заявка поступает в службу Service Desk, ей на- значается определенное время обработки 0 зависи- мости от SLA службы и приоритета заявки. Метрика показывает, насколько часто достигается целевое зна- чение.
Спецификация: Обоснование: В заданный срок в соответствии с приоритетом. Непосредственный показатель эффективности выпол- нения SLA службой Service Desk.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: <90
Целевое значение: Возможные значения: 95 D-1DD
122
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика: Среднее время ответа второго уровня поддерж- ки {минуты}
Описание: Время между передачей заявки на второй уровень поддержки и ее принятием. Показатель эффектив- ности второго уровня поддержки.
Спецификация: Минуты.
Обоснование: Передача заявок на второй уровень грозит несоблю- дением сроков, оговоренных в SLA. Время между передачей и принятием заявки оказывает прямое воздействие на длительность задержки. Метрика отслеживает время реагирования и обеспечивает эффективность приема заявок.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: >10
Целевое значение: Зависит от приоритета. Например, для заявок с при- оритетом 1 (высшим) максимальное время реагиро- вания 10 минут; с приоритетом 2 (средним) — 30 ми- нут, а с приоритетом 3 (низшим) — до 2 часов.
Возможные значения: 999999
Метрика: Сре^ время решения инцидента {минуты}
Описание: Измеряет продолжительность решения инцидента с момента открытия заявки до момента ее решения. Обратите внимание: измеряется время пребывания инцидента на различных стадииях обработки, сюда не включается время нахождения заявки в состоянии «ожидание пользователя» и «закрыта».
Спецификация: Время в минутах от открытия заявки до решения ин- цидента.
Обоснование: Это популярная метрика, показывающая общую эф- фективность процесса управления инцидентами.
Аудитория: Владелец процесса, руководство ИТ, владелец процес- са SLA, бизнес-клиент, члены команды, владелец про- цесса SIP.-
Ограничения: Измеряется время с момента открытия заявки до ре- шения инцидента (не путать с закрытием заявки).
А. Метрики для управления инцидентами
123
Между решением инцидента и закрытием заявки имеется еще один шаг — административный, кото- рый не представляет интереса для клиента. Этот шаг можно использовать для обновления базы знаний, улучшения качества регистрации и т. п. Его продол- жительность не имеет значения для клиента, следо- вательно, не должна ему сообщаться. Метрика требу- ет, чтобы система регистрации различала состояния «инцидент решен» и «заявка закрыта».
Опасное значение: >30
Целевое значение: 20
Возможные значения: 999999
Метрика: Процент переназначенных “нцидентов {инци- денты}
Описание: Измеряет число инцидентов, более одного раза на- значенных на ресурс второго или третьего уровня (так называемую группу решения).
Спецификация: Заявки, которые были к моменту закрытия назна- чены более двух раз. Как правило, инциденты устра- няются без назначения или с назначением ресурса, а затем назад службе Service Desk. Метрика учиты- вает все дальнейшие назначения.
Обоснование: Иногда помощь от других команд необходима и пе- реназначение задания является единственным пра- вильным решением. Но подчас задания по ошибке попадают не к тем командам, и их приходится сно- ва переназначать. Это отнимает время, снижает до- ступность и говорит о том, что в управлении инци- дентами не отработан правильный выбор исполни- телей. Метрика позволяет увидеть масштабы пробле- мы и понять, что делать для исправления положения, как усовершенствовать процессы и улучшить инфор- мационное наполнение базы данных по известным ошибкам.
Аудитория: Владелец процесса, руководство ИТ, владелец процес- са SLA, бизнес-клиент, члены команды, владелец про- цесса SIP.
Ограничения: Нет
Опасное значение: >10
124
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Целевое значение: 10
Возможные значения. 0-100
Задача метрики: помогать процессу управления проблемами в выявле-
нии тенденций по инцидентам, а также в оценке эффективности базы
данных по известным ошибкам и CMDB.
Метрика: Процент неправильно классифицированных инцидентов {% инцидентов}
Описание: При регистрации каждой заявке назначается катего- рия, что облегчает ее обработку и последующий ана- лиз. Когда заявка закрывается, в соответствующей записи указывается ее настоящая категория. Метрика показывает, сколько раз две категории не совпали.
Спецификации Количество инцидентов, которые при первоначаль- ном присвоении категории были неправильно опи- саны или классифицированы.
Обоснование: Правильная классификация ускоряет решение про- блем. Показатель характеризует эффективность сценария получения информации у клиентов, уро- вень подготовки персонала центра обработки вы- зовов и качество поддерживающей среды (напри- мер, CMDB).
Аудитория: Владелец процесса, руководство ИТ, владелец процес- са SLA, бизнес-клиент, члены команды, владелец про- цесса SIP.
Ограничения: Нет
Опасное значение: 60
Целевое значение: 40
Возможные значения: 0-100
Задача метрики: обеспечить оценку правильности выявления и регист-
рации всех инцидентов.
Метрика: Процент обращений, поступивших к специалис- там службы поддержки «напрямую», минуя первый уровень (% обращений}
Описание: Частота обращений клиентов непосредственно на вто- рой или третий уровень поддержки. Измеряется путем подсчета поступивших заявок. Важно, чтобы все со-
Л. Метрики для управления инцидентами
125
трудники ИТ обязательно открывали инциденты, ес- ли им звонят напрямую.
Спецификация: Заявки, которые не проходят по официальному ка- налу.
Обоснование: Прямые обращения к техническим специалистам имеют ряд недостатков. Специалисты теряют вре- мя, которое предназначено для других дел. Служба Service Desk регистрирует не все инциденты. Само явление означает, что пользователи не доверяют стандартному процессу.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: >10
Целевое значение: 5
Возможные значения: 0-100
Задача метрики: эффективное предоставление ИТ-услуг,
Метрика: Степень удовлетворенности клиентов {удовлетворенность}
Описание: Служит противовесом для других метрик. Если заяв- ки закрываются слишком быстро или обслуживаются слишком долго, то независимо от того, что говорят внутрифирменные метрики, степень удовлетворен- ности клиентов начнет снижаться и данная метрика это покажет.
Спецификация: Для измерения клиента просят поставить оценку в момент закрытия заявки. Это можно делать каждый раз или выборочно.
Обоснование: Эта метрика всегда будет оставаться в списке трех- четырех самых важных д ля управления инцидентами как прямой способ выяснить отношение сообщества пользователей к предоставляемому сервису.
Аудитория: Владелец процесса, руководство ИТ, владелец процес- са SLA, бизнес-клиент, члены команды, владелец про- цесса SIP.
Ограничения: Не стоит слишком докучать пользователям. Клиенты, как правило, гораздо лучше относятся к выборочным
126
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
опросам, чем к необходимости отвечать на один или несколько вопросов после каждого звонка.
Опасное значение: <3
Целевое значение: 4
Возможные значения: 0-5
Метрика: Процент звонков, являющихся запросами на оказание услуг {% обращений}
Описание: Процент звонков, которые представляют собой за- просы на обслуживание, а не обращения по поводу инцидентов (или по иным причинам).
Спецификация: Обращения, которые обрабатываются службой Ser- vice 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
В. Метрики службы Service Desk
131
Метрика: Число звонков «не по адресу» {звонки}
Описание: Все CI должны быть привязаны к соответствующей службе, а данный показатель характеризует службу, которая относится к звонку, выходящему за рамки SLA.
Спецификация: Число (в день) звонков, выходящих за рамки SLA.
Обоснование: Значимый показатель эффективности работы Service Desk.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 8
Целевое значение: 3
Возможные значения: 999999
Метрика: Число звонков, заявки по которым были эскалированы на второй уровень поддержки {звонки}
Описание: Число (в день) звонков, заявки по которым были пе- реданы на второй уровень поддержки.
Спецификация: Любые звонки, переданные впервые (за один день).
Обоснование: Показатель полезности второго уровня поддержки, а также эффективности первой линии поддержки, обеспечиваемой службой Service Desk. В идеале дан- ный показатель должен снижаться по мере совер- шенствования процессов и базы данных по извест- ным ошибкам. Частично перекрывается метрикой «Процент заявок, закрытых с первого раза».
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 10
Целевое значение: 5
Возможные значения: 999999
132
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика: Степень удовлетворенности клиентов {удовлетворенность}
Описание: Удовлетворенность оценивается в момент закрытия либо для каждой заявки, либо для некоторой выбор- ки заявок.
Спецификация: Установите для метрики высокий приоритет, дожди- тесь устойчиво хороших результатов, затем понизьте приоритет. Проводите измерения для каждого звон- ка или в течение фиксированного периода времени.
Обоснование: В конечном итоге это главная метрика службы Service Desk.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: <3
Целевое значение: 4
Возможные значения: 0-5
Метрика: Число звонков, заявки по которым были эскалированы на третий уровень поддержки {звонки}
Описание: Звонки, для обслуживания которых требуется третий уровень поддержки.
Спецификация: Сколько звонков в день эскалируется со второго уро- веня поддержки на третий.
Обоснование: Слишком высокий показатель говорит о необходи- мости совершенствования процедур и повышения эффективности первого и второго уровней под- держки.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение. 6
Целевое значение: 3
Возможные значения: 999999
В. Метрики службы Service Desk
133
Метрика: Среднее время ожидания ответа на звонок {секунды}
Описание: Измеряет загруженнсть службы Service Desk и ее обеспеченность ресурсами.
Спецификация: Время в секундах, в течение которого клиент ожидает ответа на звонок.
Обоснование: Любые источники промедлений представляют собой проблему, которая должна быть решена для достиже- ния целей метрики. Один из этих источников легко устранить, обеспечив службу достаточными ресурса- ми. Также задержки приводят к быстрому снижению удовлетворенности клиентов.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 20
Целевое значение: 10
Возможные значения: 999999
Метрика: Средняя продолжительность попытки дозво- ниться до клиента (на один звонок) {мт гы!
Описание: Время дозвона.
Спецификация: Сколько минут (в пересчете на один звонок) агент тратит на то, чтобы перезвонить клиенту для получе- ния дополнительной информации или предоставле- ния решения.
Обоснование: Конечно, пользователи очень заняты и до них иногда сложно дозвониться. В таких случаях можно восполь- зоваться вместо звонка другим коммуникационными методами (SMS, электронная почта) и за счет этого сократить непродуктивные потери времени.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 10
Целевое значение: 5
Возможные значения: 999999
13ч
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика: Процент обращений через веб {% обращений}
Описание: Показатель частоты использования соответствующе- го канала.
Спецификация: В идеале большинство обращений должны поступать через веб-интерфейс.
Обоснование: Чем проще и быстрее корректное размещение за- явок, тем эффективнее и оперативнее решаются проблемы. Метрика применима и к другим возмож- ным каналам обращения, например к электронной почте. Эффективность службы Service Desk повыша- ется еще и потому, что специалист в состоянии оп- ределить, с какими пользователями нужно связать- ся повторно и каким образом управлять этими кон- тактами.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 20
Целевое значение: 60
Возможные значения: 0-100
Метрика: Процент неправильно эскалированных заявок {% заявок}
Описание: Соответствует числу заявок, которые были перена- значены на основании их предыдущего неправиль- ного назначения.
Спецификация: Процент заявок, эскалированных не тем рабочим группам.
Обоснование: Служба Service Desk старается возобновлять нормаль- ное функционирование сервисов как можно быстрее. Показатель измеряет устранимую задержку, связан- ную с неправильным назначением заявок на конкрет- ных исполнителей.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
В. Метрики службы Service Desk
135
Опасное значение: 15
Целевое значение: 5
Возможные значения: 0-100
Задача метрики: обеспечить доступность службы Service Desk для кли-
ентов.
Метрика: Процент звонков которые были прерваны пользователями 1% звонков}
Описание: Когда телефон является главным входным каналом службы Service Desk, у компании должно быть доста- точно сотрудников для приема звонков, причем они должны быть готовы принимать входящие звонки в течение оговоренного времени. Иначе пользователи не смогут сообщить о своей проблеме.
Спецификация: Число звонков, которые пользователи прервали, не дождавшись ответа после согласованного времени ожидания или числа 1удков, поделенное на общее ко- личество обращений, зарегистрированных системой автоматического распределения звонков (Automatic Call Distribution System — ACD).
Обоснование: От достижения целей метрики существенно зависит степень удовлетворенности клиентов. Высокое зна- чение свидетельствует о низкой доступности серви- са, обусловленной нехваткой кадров, длительным временем обработки заявок, неэффективными про- цессами.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Необходима система ACD, технически позволяющая регистрировать пропущенные звонки и строить соот- ветствующие отчеты. Важно оговорить число гудков и процедуру обработки звонка, так чтобы метрика не включала случаи, когда абонент вешает трубку рань- ше установленного числа гудков, в ходе нормальной обработки.
Опасное значение: 5%
Целевое значение: 3%
Возможные значения: 1-100
136
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Задача метрик? : измерить эффективность процесса обработки звонков,
чтобы определит агруженносгь службы Service Desk.
Метрика: Процент звонков, по которым были открыты заявки на устранение проблемы {% звонков}
Описание: В службу Service Desk поступает множество звонков. Некоторые из них не регистрируются в системе уче- та по ряду причин (например, дополнительные). Метрика позволяет понять, сколько звонков дейст- вительно сообщают об инцидентах или являются дополнительными, а сколько поступило не в ту служ- бу поддержки (например, в И1 вместо коммуналь- ных услуг) и т. д. При высоком значении показателя необходимо изучить, какие звонки проходят через Service Desk и насколько эффективно они обслужи- ваются.
Спецификация: Отношение (в день) числа звонков, зарегистриро- ванных ACD, к числу заявок на устранение пробле- мы (открытых по телефонному звонку).
Обоснование: Служба Service Desk должна располагать эффектив- ной процедурой обработки звонков, при которой все они регистрируются в системе учета заявок на устрн нение проблем. Число дополнительных звонков сле- дует снижать с помощью проактивных механизмов. Пользователей необходимо проинструктировать от- носительно правильных контактных телефонов. Мет- рика отражает все это и помогает повысить эффек- тивность службы Service Desk.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Метрику следует использовать, когда телефон явля- ется главным каналом, по которому поступают сооб- щения об инцидентах. В ACD должна быть функция построения отчетов о звонках.
Опасное значение: >1,1
Целевое значение: 1
Возможные значения: >1
В. Метрики службы Service Desk
137
Задача метрики: 1роанализироват е загруженность службы Service Desk
и рассчитать потребнисп ь кадрах
Метрика: Процент инцидентов, поступивших от процесс управления событиями {% инцидентов}
Описание: Системы управления предприятием генерируют ав- томатические предупреждения, которые встроены в систему учета инцидентов и могут автоматически направляться группам поддержки. Этот механизм уменьшает работу по регистрации звонков в Service Desk и помогает вести проактивный мониторинг и управление инцидентами.
Спецификация: Отношение числа заявок на устранение проблем, созданных за определенный период системами уп- равления событиями, к общему числу заявок за это же время.
Обоснование: Чем выше этот показатель, тем меньше у службы Service Desk работы по регистрации и назначению заявок.
Аудитория: Владелец процесса, руководство ИТ, владелец SLA, члены команды, владелец SIP.
Ограничения: Интеграция системы управления событиями с систе- мой учета инцидентов должна исключать генерации нескольких заявок по одному и тому же событию. В противном случае значение показателя будет иска- женным.
Опасное значение: >0
Целевое значение: 0
Возможные значения: 0-100
Задача метрики: показывать компетентность службы Service Desk в от-
ношении того, в какиих областях возникают инциденты и какие группы
должны заниматься их решением.
Метрика: Процент звонков, правильно назначенных с пер- вого раза {% заявок}
Описание: Процент заявок, которые служба Service Desk точно назначила тем исполнительным группам, которые
138
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
решают именно данные задачи. Демонстрирует эф- фективность службы и обеспечивает доверие к ней со стороны клиентов.
Спецификация: Количестве заявок, которые группы решения не от- клонили и не передали немедленно другой группе.
Обоснование: Правильное назначение заявок обеспечивает эффек- тивное решение проблем, снижает сроки обработки заявок и свидетельствует о профессионализме обра- ботки. Оно также гарантирует, что заявки не переда- ются от одной группы к другой.
Аудитория: Владелец процесса, руководство ИТ, владелец SLA, члены команды, владелец SIP.
Ограничения: Объем знаний о службе Service Desk.
Опасное значение: 75%
Целевое значение: 90%
Возможные значения: 0-100
___________________с
Метрики для управления
конфигурациями
Цели процесса управления конфигурациями:
— отчитываться за все активы и конфигурации р]Т в рамках подразделения
и его служб;
— предоставлять правильные данные о конфигурациях и соответствующей
документации для поддержки остальньсх процессов управления услугами;
— обеспечивать стабильную основу дл^ процессов управления инцидента-
ми, проблемами, изменениями и релизами;
— сверять записи о конфигурации с фазическим состоянием инфраструк-
туры и исправлять все несоответствия.
(Библиотека ITIL, том «Под держка услуг»)
Миссия: определять, контролировать и Проверять информацию, требуемую
для управления ИТ-услугами путем определения и поддержки базы данных
контролируемых объектов, их статуса, жизненного цикла и отношений,
а также любой другой информации, необходимой для рентабельного уп-
равления качеством ИТ-услуг.
Владелец процесса: менеджер конфигураций.
Задача метрики: получать правильнее данные об ИТ-инфраструктуре и
ее связях, эффективно управлять этой Информацией в соответствии с пот-
ребностями бизнеса и согласованными политиками.
Метрика: Число неисполь3уемых лицензий {лицензии}
Описание: 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
Целевое значение: 0
Возможные значения: 999999
Метрика: Число нарушений SLA, вызваных ошибками CMDB {SLA}
Описание: В первую очередь нужно обеспечить степень пра- вильности CMDB, достаточную, чтобы предотвра- тить нарушение SLA. Со временем следует добиться, чтобы этот показатель можно было принять всегда равным 0; после того, как он пробудет нулевым не- сколько месяцев, вместо него можно подставить дру- гую метрику.
Спецификация: SLA должны выполняться всегда. Когда CMDB внед- рена и механизмы, применяемые в управлении кон- фигурациями, успешно взаимодействуют с качест- венным управлением изменениями, простоям из-за проблем с базой данных вообще нет места. Значе- ние показателя определяется по статусу закрытия заявок.
Обоснование: Неверные или отсутствующие элементы CMDB могут помешап решению проблем и даже процессу управ- ления инцидентами, что и фиксирует данная метри- ка. Поскольку управление конфигурациями стремит- ся снизить этот показатель до нуля, его можно рас- сматривать как оценку зрелости процесса.
Аудитория: Владелец 1роцесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 2
Целевое значение: 0
Возможные значения: 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
Возможные значения: 0-5
Метрики для управления
изменениями
Цель процесса управления изменениями состоит в том, чтобы обеспечить
использование стандартизованных методов и процедур для эффективной
и быстрой обработки всех изменений с целью минимизировать воздей-
ствие инцидентов, обусловленных преобразованиями, на качество обслу-
живания и, как следствие, улучшить повседневное функционирование
подразделения. (Библиотека 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
Метрика: Простои во время изменений {инциденты1
Описание: Любые перерывы в обслуживании измеряются чис- лом инцидентов. Если изменение происходит в нера- бочие часы сервиса, то по определению простоя в обслуживании быть не может.
Спецификация: В идеальном мире во время изменений не бывает никаких незапланированных простоев.
Обоснование: Если видно, что провести изменение не удается, нуж- но восстановить прежнее состояние до того, как про-
148
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
изошедшее начнет сказываться на работе сервиса. План «отступления» необходимо предварительно протестировать, чтобы восстановление не привело к простою.
Аудитория: Владелец процесса, руководство ИГ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 6
Целевое значение: 0
Возможные значения: 999999
Метрика: Число неудачных изменений без плана возвра- щения в исходное состояние {изменения}
Описание: Учитываются любые изменения со статусом «не выпол- нено» и без плана возвращения в исходное состояние.
Спецификация: Для всех изменений должен существовать план воз- вращения в исходное состояние, и это нужно всегда проверять.
Обоснование: Ни одно изменение не имеет права на существова- ние без проверенного плана возвращения в исход- ное состояние. Если изменение оканчивается неуда- чей, а план отсутствует, анализ риска был проведен некачественно.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 2
Целевое значение 0
Возможные значения: 999999
Метрика:
Описание:
Спецификация:
Процент изменений, выполненных вовремя
1% изменений}
Для всех изменений установлен срок выполнения.
Если по истечении этого времени они остаются неза-
вершенными, метрика их не учитывает.
Задержки иногда вызваны вескими причинами, и их
значительное количество — при условии, что про-
D. Метрики для управления изменениями
149
цент неудавшихся изменений низок — может быть приемлемым. Поэтому данной метрике следует на- значить невысокий приоритет.
Обоснование: Если изменение систематически запаздывают, это говорит о слабом контроле и повышенном риске сбо- ев бизнеса.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 90
Целевое значение: 95
Возможные значения: 0-100
Метрика: Процент изменений, вызвавших инциденты {% изменений}
Описание: Учитываются все инциденты, при закрытии которых было установлено, что они произошли вследствие из- менения.
Спецификация: Если существует опасность, что изменения приведут к инцидентам, следуе г проводить их вне часов SLA, во время запланированной остановки. Если же инци- дент все-таки случается, то, вероятно, по причине плохого планирования или тестирования.
Обоснование: Изменения никогда не должны нарушать работу компании.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 10
Целевое значение: 5
Возможные значения: 0-100
Метрика: Число предложений Консультативного комите- та по изменениям (Change Advisory Board — CAB), не реализованных вовремя {действия}
Описание: В любом письменном предложении Консультатив- ного комитета по изменениям оговаривается срок
150
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
реализации. Если этот СРОК прошел, а предложе- ние не реализов<лно’ оно учитывается в данной метрике.
Спецификация: Все предложения Должны реализовываться, так что в данном показЯтеле не Должно быть необходимос- ти Если он все-та!™ высок, организация, возможно, работает в условий чрезмерного напряжения. Срав- ните это с метрикой невыполненных изменений.
Обоснование: САВ должен пред<;,ставлять обратную связь, иначе менеджер измени1™ не сможет принимать эффек- тивных решений.
Аудитория: Владелец процесс;1’ Руководство ИТ, владелец про- ^са.ЕСА,чкекыкоманДЬ1’ владелец процесса SIP.
Ограничения: Документы и преДД°жения Должны регистриро- ваться в строгом соответствии с правилами.
Опасное значение: 3
Целевое значение: 0
Возможные значения: 999999
Метрика: Число экстреннь!* изменений {изменения}
Описание: Все преобразован^’ которые происходят экстренно в рамках процесс^ управления изменения.
Спецификация: Процесс управлении1 изменениями предназначен для того, чтобы эффе1<тивно выполнять все, что требует- ся и за счет этого снижать риск, сопряженный с лю- бым преобразовав™^ ПРИ экстренных изменениях допускается полнЬ1Й и™ частичный отказ от некото- рых мер предостоРожности частности, от тести- рования). Этот п0ВЬ1шенный риск, хотя порой он неизбежен, необУ°Димо ДеРжать на уровне разум- ного минимума. Метрика показывает тенденцию к чрезмерному исп*льзованию процесса и позволяет предпринять корректиРУЮ1Дие Действия.
Обоснование: Потребность в экстренных изменениях так или иначе будет периодически возникать, но важно, чтобы соот- ветствующий npotfecc не стал нормальным способом действий. Метрик* отслеживает частоту, с которой применяется проц*сс Д™ исключительных случаев.
Аудитория: Владелец процесс*’ Руководство ИТ, владелец про- цесса SLA, бизнес^иент’ ’“е™ команды, владелец процесса SIP.
D. Метрики для управления изменениями
151
Ограничения: Нет
Опасное значение: 3
Целевое значение: 3
Возможные значения: 999999
Метрика: Число изменений, не принесших ожидаемых результатов {изменения}
Описание: Изменения, которые не приносят результатов, запла- нированных в RFC.
Спецификация: Изменения определяются в RFC, при этом указыва- ются ожидаемые результаты. По завершении изме- нения его проверяют с точки зрения правильности выполнения и соответствия результатов тому, что ожидалось. Метрика учитывает изменения, статус которых после проверки указывает, что они не при- несли запланированных результатов.
Обоснование: Предполагается, что планирование и тестирование обеспечат переход от RFC к эффективным изменениям, не нарушающим работу и приводящим к нужным ре- зультатам. Проверка изменений позволяет увидеть, что же произошло в действительности. Метрика замыкает эту цепочку и показывает, обеспечивает ли процесс внесения изменений в целом ожидаемые улучшения.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Чтобы судить о соответствии результатов изменения ожиданиям, нужны четкие и измеримые целевые зна- чения.
Опасное значение: 3
Целевое значение: 3
Возможные значения: 999999
Задача метрики: высококачественные процессы управления ИТ-услу-
гами.
Метрика: Степень удовлетворенности клиентов {удовлетворенность)
Описание: Внутренняя удовлетворенность процессом управле- ния изменениями, оцениваемая для каждого RFC.
152
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Спецификация: Определяется согласно диаграмме взаимоотноше- ний процесса.
Обоснование: Надежный показатель качества результатов.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: <3
Целевое значение: 4
Возможные значения: 0-5
Метрики
для управления релизами
Цели управления релизами:
— планировать и контролировать успешное развертывание ПО и сопут-
ствующих аппаратных средств,
— разрабатывать и внедрять эффективные процедуры по распространению
и инсталляции измененных компонентов ИТ-систем;
— обеспечивать возможность отслеживания и безопасность всех измене-
ний в ПО и аппаратных средствах, а также установку только правиль-
ных, авторизованных и протестир ванных версий;
— узнавать и учитывать ожидания клиента при планировании и развер-
тывании новых релизов;
— согласовывать точное содержание и план выпуска релизов во взаимо
действии с процессом управления изменениями;
— внедрять новые релизы ПО или аппаратные средства в операционную
среду с помощью процессов управления конфигурациями и изменени-
ями. Релиз должен находиться в ведении управления изменениями и
может состоять из любого сочетания аппаратных средств, ПО, встроен-
ных программ и документов CI;
— обеспечивать сохранение мастер-копий всех программ в библиотеке
эталонного программного обеспечения (БЭПО) и обновление базы
данных управления конфигурациями (CMDB),
— обеспечивать безопасность развертывания и изменения всех аппарат-
ных средств, используя услуги управления конфигурациями.
(Библиотека ITIL, том «Поддержка услуг >)
154
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Миссия: сформировать целостную картину изменения ИТ-услуги и обеспе-
чить, чтобы все аспекты релиза, как технического, так и нетехнического
характера, рассмттр шс! вместе.
Владелец процесса: релиз-менеджер.
Задача метрики: ПО в DSL. в точности регистрировать все исправленные версии
Метрика: Число установленных программных пакетов, отсутствующих в DSL {пакеты}
Описание: В рамках стандартного процесса верификации любое ПО, обнаруженное на любом оборудовании, можно сверить с DSL, установив таким путем, авторизовано ли оно и правильна ли его версия.
Спецификация: Объем ПО, установленного, но взятого не из DSL. Для выявления таких программ может понадобиться ре- гулярный аудит ПО (например, с помощью инстру- ментов мониторинга).
Обоснование: Отсутствие регистрации в DSL у какого бы то ни бы- ло ПО, имеющегося в ИТ-инфраструктуре, — это и высокий риск с точки зрения информационной безо- пасности, и признак неэффективности управления релизами.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес- клиент, члены команды, владе- лец процесса SIP.
Ограничения: Нет
Опасное значение: 50
Целевое значение: 25
Возможные значения: 999999
Задача метрики: контролировать релиз ПО в инфраструктуре, чтобы
свести к минимуму число вероятных сбоев.
Метрика: Число срочных релизов {релизы}
Описание: Срочные релизы выполняются в рамках соответству- ющего процесса — когда он активизируется, этот факт может быть зафиксирован и учтен в данной метрике.
Е. Метрики для управления релизами
155
Спецификация: В идеале все релизы следует планировать заблаговре- менно, так что со временем количество срочных ре- лизов должно сокращаться.
Обоснование: Срочные релизы сопряжены с высоким риском ошиб- ки и, как следствие, сбоями в обслуживании. Иногда они оправданны, но такие случаи должны быть редки. Если данная метрика регистрирует существенное чис- ло срочных релизов в месяц, на это необходимо об- ратить внимание.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Опасное значение: Нет 5
Целевое значение: 0
Возможные значения: 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.
Ограничения: Нет
Опасное значение: 200
Целевое значение 100
Возможные значения: 999999
Метрика: Процент точности оценки трудозатрат на релиз {% времени}
Описание: Проще говоря, абсолютная величина разности между запланированным и реальным временем.
Спецификация: Это составная метрика, вычисляемая на основе пред- полагаемого времени создания релиза, фактическо- го числа потраченных на него человеко-часов и чис- ла затронутых им CI. В момент окончания планиро- вания релиза нужно сохранить предварительную оценку, а после завершения работ сравнить с реаль- ным показателем. Значение представляет собой раз- ность в процентах относительно запланированного времени.
Обоснование: Точные прогнозы позволяют принимать рациональ- ные деловые решения. Улучшение прогнозирования для небольших релизов должно повысить и достовер- ность предсказаний для крупных релизов, имеющих решающее значение для бизнеса.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Для получения точных показателей нужны качест- венные процессы управления проектами и финан- сами.
Опасное значение: 60
Целевое значение: 80
Возможные значения: 0-100%
Е. Метрики для управления релизами
159
Задача метрики: обеспечивать эффективность процессов организации
обслуживания.
Метрика: Степень удовлетворенности клиенте в {удовлетворенность}
Описание: Назначьте метрике высокий приоритет, сохраняйте его до тех пор, пока значения не станут стабильно высокими, а затем понизьте.
Спецификация: В данном случае там, где это возможно, следует вклю- чать в метрику также отчеты об удовлетворенности конечных пользователей конкретными развертыва- ниями.
Обоснование: Управление релизами оказывает сильное влияние на конечных пользователей, поэтому важно правильно их информировать, осведомлять и обучать. Уровень удовлетворенности этим процессом будет отражать его качество.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Нет
Опасное значение: <3
Целевое значение: 4
Возможные значения: 0-5
ЕЛ. Метрики для поддержки приложений
Метрика: Число проанализированных программных ошибок {ошибки}
Описание: Метрика показывает возможность обслуживания программного кода. В идеале изменений, связанных с модернизацией, должно быть больше, чем измене- ний, связанных с исправлением ошибок.
Спецификация: Показатель измеряется на основе перечня ошибок, зафиксированных и признанных исправленными.
Обоснование: Есть более детальные показатели — в данной метри- ке не различают: [ легко- и трудноразрешимые про- блемы.
160
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: На метрику влияет качество самого кода — то, сколь- ко в нем вообще ошибок, нуждающихся в исправле- нии. Если результат превышает целевое значение, т.е. устранено больше ошибок, чем ожидалось, это хорошо с точки зрения процесса, а также возможнос- ти обслуживания кода, но совсем не является досто- инством с точки зрения качества кода.
Опасное значение: 2
Целевое значение 4
Возможные значения 999999
Метрика Число оптимизаций {оптимизации}
Описание: Зарегистрированные и одобренные оптимизации.
Спецификация: Учитываются улучшения программного кода, кото- рые не одобрены ни как расширения, ни как ис- правления ошибок. Они необходимы, поскольку одна из задач управления мощностями заключает- ся в повышении производительности приложений. Данная метрика представляет собой оценку этой деятельности.
Обоснование: Важно, чтобы приложения эффективно использова- ли ресурсы. Для повышения эффективности следует разрабатывать новые приложения, однако и те, что уже существуют, могут быть улучшены.
Аудитория: Владелец процесса, руководство ИТ-отдела владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: На метрику влияет качество самого кода — сколько в нем вообще мест, где можно что-то улучшить. Если результат превышает целевое значение, т. е. произве- дено больше улучшений, чем ожидалось, это хорошо с точки зрения процесса, а также и возможностей обслуживания кода, но совсем не является достоин- ством с точки зрения качества кода.
Опасное значение: 10
Целевое значение: 20
Возможные значения: 999999
Е. Метрики для управления релизами
161
Метрика: Число приложений/ревизий, впущенных в про- изводство {сборки'
Описание: Одобренные релизы.
Спецификация: Оценивается согласно DSL.
Обоснование: Показатель реальной обеспечиваемой продуктивное - ти, не обязательно связанный с качеством приложе- ния.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Необходимо учитывать обстоятельства: если клиен- там не нужны улучшения в программе, а код не со- держит ошибок, релизов будет очень мало.
Опасное значение: 2
Целевое значение: 4
Возможные значения: 999999
Метрика: Число учебных занятий для конечных пользова- телей {заняти’'
Описание: Ознакомление конечного пользователя с новыми ре- лизами и новыми сотрудниками.
Спецификация: Метрика оценивает непрерывное обучение пользо- вательского контингента, а также единовременные учебные занятия по новым релизам. Это важный по- казатель качества взаимодействия между службой поддержки приложений и пользователями. Слишком часто обучением пренебрегают, не рассматривая его в качестве критерия успеха поддержки приложений. Метрика сосредоточивает внимание на данной про- блеме.
Обоснование: Собственно занятия проводит служба управления рели- зами, но подготовкой учебных материалов и монито- рингом качества курсов занимается служба поддерж- ка приложений.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: В зависимости от стабильности сообщества пользо- вателей.
162
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Опасное значение: 5
Целевое значение: 10
Возможные значения: 99999
Метрика: Число 1 (ефектов, обнаруженных по журналам пегисг;>ации {дефекты}
Описание: Это просто число новых ошибок, выявленных самой службой поддержки приложений. Учитываются все ошибки, обнаруженные как по журналу регистра- ции, так и по другим источникам.
Спецификация: Исправлять ошибки, найденные пользователями, нор- мально. Но лучше исправлять их еще до того, как их обнаружат пользователи, — тогда удастся избежать перерывов в обслуживании. Данный показатель ха- рактеризует работу системы решения проблем по выявлению еще не проявившихся ошибок. Метрика может быть абсолютным числом найденных дефек- тов или их числом на каждого сотрудника службы поддержки приложений.
Обоснование: Измерения, способные улучшить качество услуг для бизнеса, имеют большое значение. Высокий уровень раннего обнаружения и устранения проблем, как пра- вило, незаметен. Нужно сделать его видимым и сти- мулировать его повышение.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: В зависимости от качества программного кода.
Опасное значение: 2
Целевое значение: 4
Возможные значения: 999999
Метрика: Число временных решений, протестированных и выпущенных в производство {решения}
Описание: Временные решения, выпущенные в производство.
Спецификация: Все временные решения, зарегистрированные про- цессом управления релизами. Метрика может быть абсолютноым числом временных решений или их числом на одного сотрудника службы поддержки приложений.
Е. Метрики для управления релизами
163
Обоснование: Учитываются временные решения как не связанные, так и связанные с исправлением кода. За первые, та- кие как исправления конфиптэации, служба поддерж- ки приложений отвечает непосредственно, в случае вторых она отвечает за их тестирование.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Зависит от качества программного кода.
Опасное значение: 3
Целевое значение: 5
Возможные значения: 999999
Метрика: Число временных решений, возвращенных для доработки {решения}
Описание: Временные решения, которые не сработали.
Спецификация: Времс иные решения, отклоненные службой управле- ния релизами или такие, внедрение которых окончи- лось возвращением системы в исходное состояние. Метрика может быть абсолютным числом времен- ных решений или их числом на одного сотрудника службы поддержки приложений.
Обоснование: Показатель низкого уровня тестирования.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Зависит от качества программного кода.
Опасное значение: 1
Целевое значение: 2
Возможные значения: 999999
Е.2. Метрики для разработки приложений
Метрика: Число ошибок, выявленных при разработке или тестировании {ошибки}
Описание: Дефекты, обнаруженные в ПО собственной разра- ботки.
Спецификация: Учитываются дефекты, выявленные при разработке или тестировании, но не при непосредственном ис- пользовании. Метрика может быть абсолютным чис-
164
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
лом дефектов или их числом на одного сотрудника службы поддержку приложений.
Обоснование: Мера надежности Создаваемого кода.
Аудитория: Владелец процессу руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Зависит от качест^а программного кода.
Опасное значение: 10
Целевое значение: Возможные значения 20 999999
Метрика: Число ошибок, исправленных при тестирова- нии {ошибки}
Описание: Дефекты, зарегисТрИрОванные как исправленные и протестированные
Спецификация: Дефекты, обнаруженные ПрИ тестировании. Метри- ка может быть абс5лютным ЧИслом дефектов или их числом на каждого сотрудника службы поддержки приложений.
Обоснование: Мера производительности.
Аудитория: Владелец процесс?^ руководство ИТ, владелец про- цесса SLA, члены Команды, владелец процесса SIP.
Ограничения: Зависит от качества программного кода.
Опасное значение: 20
Целевое значение: 25
Возможные значения 999999
Метрика: Число зарехистрированнь1х ошибок, которые были исправлены {ошибки}
Описание: Дефекты ПО, вызвг1вшие сбой в обслуживании.
Спецификация: Ошибки, в отнош<,нИИ которых было установлено, что именно они п£ивели к инцидентам, зарегистри- рованным службой service Desk. Метрика может быть абсолютным числом ошибок или их числом на одно- го ' отрудника ^1у»сбы поддержки приложений.
Обоснование: Об этих ошибках, в отличие от дефектов ПО, выяв- ленных при тести{юваниИ1 известно, что они стали причиной инцидентов, поэтому важно, чтобы они были исправлены.
Е. Метрики для управления релизами
165
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Зависит от качества программного кода.
Опасное значение: 5
Целевое значение: 10
Возможные значения: 999999
Метрика: Число приложений/ревизий, «нятых к исполь- зованию {сборки}
Описание: Действующие релизы.
Спецификация: Число успешно внедренных релизов с точки зрения процесса управления релизами.
Обоснование: Показатель общей продуктивности и успешной реа- лизации.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 1
Целевое значение: 3
Возможные значения: 999999
Метрика: Число приложений/ревизий, отклоненных службой поддержки приложений {сбо] си}
Описание: Дефектные сборки.
Спецификация: Сборки, представленные для релиза, но отклоненные службой поддержки приложений в рамках процесса управления релизами.
Обоснование: Показатель качества сборок. По мере совершенство- вания тестирования этот показатель должен сни- жаться.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 3
Целевое значение: 1
Возможные значения: 999999
166
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика: Число разработок приложений, одобренных компанией {разработки}
Описание: Одобренные разработки.
Спецификация: Разработки, одобренные компанией.
Обоснование: Обеспечивается прозрачность процесса ра $работки и одобрение результатов со стороны бизнеса.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Разработки должны формально документироваться. Метрика зависит от деятельности компании.
Опасное значение: 10
Целевое значение: 2
Возможные значения: 999999
Метрика: Число успешных сборок приложений {сборки}
Описание: Число сборок, представленных для DSL, включая как промежуточные, так и продуктивные.
Спецификация: Сборки, скомпонованные и протестированные разра- ботчиками.
Обоснование: Показатель внутрифирменной производительности. Проверенные и одобренные внутренние сборки мо- гут выходить на уровень альфа- или бета-тестирова- ния или даже продуктивной эксплуатации.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Зависит от деятельности компании.
Опасное значение: 6
Целевое значение: 2
Возможные значения: 999999
Метрика: Числе дней, потраченных на развертывание приюжения{дни}
Описание: Время отсчитывается согласно числу дней, заранее отведенных на поставку протестированного кода в DSL.
Спецификация: Действует для всех приложений/версий.
Е. Метрики для управления релизами 167
Обоснование: Метрика показывает, насколько успешно соблюдает- ся календарный план при разработке приложений.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 10
Целевое значение: 5
Возможные значения: 999999
Метрики для управления
операциями/
инфраструктурой И КТ
Цели управления инфраструктурой И1СГ.
Разработка и планирование:
— удовлетворять существующие потребности бизнеса в ИКТ;
— внедрять более эффективные решения в области ИКТ и бизнеса;
— обладать простотой развития и расширения, чтобы удовлетворить бу-
дущим потребностям организации в определенных временных рамках
и при заданных издержках;
— развивать гибкость навыков в ИКТ путем продвижения стратегии в
повседневные операционные задания;
— эффективно и продуктивно использовать все ресурсы ИКТ и обеспечи
вать безопасность ИКТ-сред;
— содействовать улучшению качества ИКТ-услуг в рамках налагаемых
затратных ограничений;
— сокращать, минимизировать или ограничивать долгосрочные из-
держки.
Внедрение:
— удовлетворять существующее потребности бизнеса;
— создавать приемлемую и стабильную среду ИКТ, которая может разви-
ваться, расширяться и приспосабливаться к будущим потребностям
бизнеса;
— содействовать общему улучшению качества ИКТ-услуг.
Операции:
— эксплуатировать, управлять и поддерживать весь комплекс инфраструк-
туры ИКТ, упрощающей предоставление ИКТ-услуг бизнесу и удовлет-
воряющей всем согласованным требования» и целям;
170
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
— обеспечивать надежность, стабильность, безопасность и непротиворе-
чивость инфраструктуры ИКТ, а также ее содействие продуктивности и
эффективности бизнес-процессов организации.
Техническая поддержка:
— главная цель технической пиддержки — обеспечить бизнесу высокодо-
ступные и рентабельные ИКТ-услуги, поддерживающие выполнение им
своих задач. Для достижения этой цели служба технической поддержки
предоставляет необходимые ресурсы, опыт и квалификацию другим
процессам для поддержки их работоспособности. Следовательно, она
должна стать центром технического совершенствования и содействовать
службам эксплуатации и внедрения в цикле предоставления услуг.
(Библиотека ГПЬ, том «Управление ИКТ-инфраструкгурой»)
Миссия: управлять предоставлением высококачественных ИКТ-услуг в
соответствии с требованиями бизнеса в областях разработки и планирова-
ния, внедрения, эксплуатации и технической поддержки.
Владелец процесса: менеджер инфраструктуры ИКТ.
Задача метрики: управлять и предоставлять высококачественные
ИКТ-услуги, соответствующие требованиям бизнеса в областях разработ-
ки и планирования, внед| ения, эксплуатации и технической поддержки.
Метрика: Число планов, одобренных компанией {планы}
Описание: Согласованные планы.
Спецификация: Разработка и планирование. Стратегический план содержит подпланы, которые внедряются в период действия стратегии. Каждый из этих планов должен быть детально проработан и подписан владельцами бизнеса, исходя из стратегических критериев.
Обоснование: Необходимо правильно управлять планами и под- тверждать их. Это критерий продуктивности про- цесса.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 5
Целевое значение: 2
Возможные значения: 999999
F. Метрики для управления операциями/инфраструктурой ИКТ
171
Метрика: Число планов, не готовых для одобрения { планы}
Описание: Планы «на подходе».
Спецификация: Разработка и планирование. Метрика соответствует числу планов в стратегическом документе, которые должны быть закончены в текущем месяце, но еще не готовы для одобрения.
Обоснование: Критерий будущей продуктивности. Высокое значение может также свидетельствовать о нехватке ресурсов.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 5
Целевое значение: 2
Возможные значения: 999999
Метрика: Отставание от плана внедрения {время}
Описание: Отсроченные планы. Отставание реальных сроков внедрения от запланированных. Измеряется по пер- спективному графику изменений.
Спецификация: Внедрение. План внедрения должен содержать конт- рольные точки, показатель представляет собой про- должительность задержки в днях относительно этих точек.
Обоснование: Показатель эффективности. Высокое значение, веро- ятно, свидетельствует о проблеме, связанной с ресур- сами или планированием внедрения.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 7
Целевое значение: 2
Возможные значения: 999999
Метрика: Число проблем, возникших при внедрении {события/инциденты}
Описание: Любые помехи, выявленные в процессе внедрения.
172
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Спецификация: Внедрение. Под проблемами понимаются события или инциденты, возникшие в результате внедре- ния. Может перекрываться с метрикой управления изменениями «Процент изменений, вызвавших ин- циденты».
Обоснование: Внедрение следует планировать так, чтобы не ме- шать предоставлению услуг.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 5
Целевое значение: 2
Возможные значения: 999999
Метрика: Число серьезных или критических событий на один ’управляемый объект {события}
Описание: Показатель стабильности, измеряется с помощью инструментов мониторинга инфраструктуры.
Спецификация: Эксплуатация. Число серьезных или критических со- бытий на один управляемый объект.
Обоснование: Задача эксплуатации — поддерживать стабильность инфраструктуры. Метрика оценивает эффективность выполнения данной задачи.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение 0,03
Целевое значение: 0,01
Возможные значения: 999999
Метрика: Число событий, угрожающих информационной безопасности (события)
Описание: Измеряется с помощью инструментов мониторинга инфраструктуры.
Спецификация: Операции. Управление брандмауэрами и программа- ми уничтожения вирусов должно сводить данный по-
F. Метрики для управления операциями/инфраструктурой ИКТ
173
казатель к минимуму. В норме он рассчитывается еже- дневно, потому что вирусы появляются с такой же час- тотой и требуют немедленного вмешательства.
Обоснование: Хотя брандмауэры и другие устройства обеспечения безопасности относятся к управлению безопаснос- тью и доступностью, их повседневное функциониро- вание — забота службы эксплуатации. Показатель связан с другой метрикой — «Число инцидентов, уг- рожающих информационной безопасности» — и дол- жен всегда быть ниже ее. Если обе метрики имеют равное значение, это говорит о плохой реакции служ- бы управления инфраструктурой на информацион- ные угрозы.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 250
Целевое значение: 150
Возможные значения: 999999
Метрика: Число сбоев при выполнении заданий / скрип- тов / резервного копирования {события}
Описание: Ошибки в скриптах, аппаратных средствах или про- цессах эксплуатации.
Спецификация: Эксплуатация. Число сбоев при выполнении заданий / скриптов / резервного копирования.
Обоснование: Все скрипты и задания являются частью DSL, в слу- чае сбоя необходимо исправлять их или эксплуата- ционные процедуры. Важно поддерживать число сбоев минимальным, поскольку они могут нега- тивно влиять на сервисы.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 20
Целевое значение: 5
Возможные значения: 999999
174
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика: Число инцидентов вызванных изменениями, которые возникла в результате выполнения опр< селенных 1 {инциденты}
Описание: Серьезные операционные инциденты.
Спецификация: Число инцидентов, в качестве причины которых при их закрытии указаны операции. Перекрывается с метрикой управления изменениями «Процент изме- нений, вызвавших инциденты».
Обоснование: Изменения следует' осуществлять в нерабочее время, поэтому значение метрики должно быть очень низ- ким. Это необходимо контролировать, для чего нуж- но измерять данный показатель.
Аудитория: Владелец процесс#» руководство ИТ, владелец про- цесса SLA, бизнес-^иент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение- 10
Целевое значение: 5
Возможные значения: 999999
Задача метрики: э ективное обеспечение ИТ
Метрика: Степень удовлетворенности клиентов {удовлетворенность)
Описание: Степень удовлетворенности клиентов.
Спецификация: Степень удовлетворенности клиентов, определяемая согласно диаграмм6 взаимоотношений процесса.
Обоснование: Показатель эффективности обеспечения ИТ.
Аудитория: Владелец процесс#» руководство ИТ, владелец про- цесса SLA, бизнес-<О1иент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: <3
Целевое значение: 4
Возможные значения: 0-5
Метрики для управления
уровнем сервиса
Цель управления уровнем сервиса (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
Метрика: Про1 !нт 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
Возможные значения: 999999
180
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика: Число еще не согласованных операционных соглашений об уровне услуг (OLA) и внешних договоров (UC) {OLA/UC }
Описание: По мере распространения управления уровнем услуг будут заключаться новые операционные соглаше- ния об уровне услуг (OLA) и внешние договоры (UC), так что их число будет возрастать. Данная метрика фактически показывает продуктивность этого про- цесса.
Спецификация: OLA и UC, которые еще не заключены и не одобрены.
Обоснование: Отсутствие этого показателя влечет две опасности: во-первых, что OLA и UC будут обсуждаться, но к окончательному соглашению по сложным вопросам прийти так и не удастся, во-вторых, что SLA будет заключено без необходимой поддержки со стороны соответствующих соглашений OLA и UC.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 40
Целевое значение: 25
Возможные значения: 999999
Метрика: Степень удовлетворенности клиентов {удовлет- воренность}
Описание: Удовлетворение клиента с точки зрения процесса, наиболее тесно связанного с данным.
Спецификация: Метрика удовлетворенности клиента как она описа- на в диаграмме взаимоотношений процесса.
Обоснование: Это субъективная, но вполне аутентичная оценка качества результатов процесса.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: <3
Целевое значение: 4
Возможные значения: 0-5
G. Метрики для управления уровнем сервиса
181
Метрика: Время между выработкой требований по уров- ню обслуживания (SLR) и соглашением SLA {дни}
Описание: Время от создание SLR до окончательного принятия SLA.
Спецификация: Количество дней, необходимых для перехода от пер- вого варианта SLR к подписанному SLA.
Обоснование: На продолжитель ость этого периода, безусловно, влияет скорость реагирования бизнес-подразделе- ния, а также эффективность процесса SLA. Со време- нем способность к взаимодействию, переговорам и заключению SLA должна улучшаться, и данная мет- рика оценивает эту тенденцию.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 60 дней
Целевое значение: Возможные значения: 30 дней 999999
н
Метрики для управления
проблемами
Цель управления проблемами — минимизировать негативное воздействие
на бизнес со стороны инцидентов, вызываемых ошибками в ИТ-инфра-
структуре, и предотвратить повторение таких инцидентов. С этой целью в
рамках процесса управления проблемами предпринимают усилия по вы-
явлению исходной причины инцидентов и затем принятию мер для улуч-
шения или исправления ситуации.
(Библиотека ITIL, том «Поддержка услуг»)
Миссия: минимизировать нарушения в предоставлении ИТ-услуг, обеспе-
чив необходимые ИТ-ресурсы для решения проблем в соответствии с
требованиями бизнеса; предотвращать повторные нарушения и фиксиро-
вать информацию, позволяющую усовершенствовать процесс решения
проблем, что повысит доступность и продуктивность.
Владелец процесса: менеджер по управлению проблемами.
Задача метрики: определить проблемы, связанные с (потенциальными)
нарушениями обслуживания, и минимизировать их воздействие либо
полностью устранить их как причину сбоев.
Метрика: Число решенных проблем {проблемы}
Описание: Мера активности, а также эффективности.
Спецификация: Число записей о закрытых проблемах.
Обоснование: Решение проблемы может потребовать много време-
ни, но если их разрешаемость высока, это говорит об
эффективности процесса.
184
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 10
Целевое значение: 20
Возможные значения: 999999
Метрика:
Описание:
Спецификация:
Обоснование:
Аудитория:
Ограничения:
Опасное значение:
Целевое значение:
Число инцидентов, разрешенных при помощи
базы данных, где описано решение аналогич-
ных за (эч {инциденты}
Устранение инцидентов с помощью решений, заре-
гистрированных в соответствующей базе данных,
экономит время и трудозатраты, сохраняя высокий
уровень обслуживания клиентов.
Число устраненных таким путем инцидентов должно
увеличиваться.
База данных с описанием разрешения проблем явля-
ется главным каналом взаимодействия между про-
цессами управления проблемами и инцидентами.
Если ее правильно обслуживать и вести так, чтобы
ею было легко пользоваться, это отразится на значе-
нии данной метрики.
Владелец процесса, руководство ИТ, владелец про-
цесса SLA, бизнес-клиент, члены команды, владелец
процесса SIP.
Должна иметься база данных с описанием разреше-
ния проблем, и все инциденты, устраненные с помо-
щью содержащегося там решения или обходного при-
ема, должны регистрироваться как таковые. Следует
ли задать уровень опасного значение выше или ни-
же целевого, зависит от конкретных условий. Следо-
вательно, имеет смысл измерять число инцидентов,
которые были решены путем использования инфор-
мации из базы данных по отношению к общему чис-
лу решенных инцидентов.
20
50
Возможные значения: 999999
Н. Метрики для управления проблемами
185
Метрика: Общее число инциденте инциденты}
Описание: Инциденты могут быть вызваны проблемами — если устранить проблемы, количество инцидентов умень- шится.
Спецификация: Данная метрика и степень удовлетворенности клиен- тов — два главных показателя качества работы для процесса управления проблемами.
Обоснование: Уменьшение этого показателя — первая задача про- цесса управления проблемами.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Необходимо оговорить с клиентами, что нарушения, произошедшие по их вине, не регистрируются как инциденты. Важно понимать, что число инцидентов может возрастать или уменьшаться по причинам, не связанным с управлением проблемами (напри- мер, доверие или недоверие пользователей к служ- бе Service Desk), поэтому на данный показатель нель- зя полностью полагаться — следует использовать его в сочетании с другими метриками для выясне- ния причин изменений. При любых значительных изменениях метрики группа управления проблема- ми должна провести исследование их причин.
Опасное значение: 400
Целевое значение: 200
Возможные значения: 999999
Метрика: Общее время неработоспособности пользовате- лей {время}
Описание: Хотя это фактически показатель доступности, он поз- воляет оценить и эффективность процесса управле- ния проблемами: если проблемы решаются быстро и эффективно, уровень простоев у пользователей сни- жается.
Спецификация: Показатель может измеряться как суммарное время (в часах) на устранение инцидентов для всех затро- нутых пользователей в часы, оговоренные в 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 в определенной категории, вероятно, означает необходимость сессии обучения.
Целевое значение: 0
Возможные значения: 99999
Задача метрики: выявлять значительные затраты на качество для
управления проблемами.
Метрика: Затраты на решение проблемы {затраты}
Описание: Сколько всего стоило решение данной проблемы.
Спецификация: Оценивают» я часы работы персонала, материальные издержки и другие статьи расходов, связанные с ре- шением проблемы.
Обоснование: Управление проблемами — это процесс, связанный с управлением качеством предоставления услуг. У ка- чества есть цена. Для всех существующих проблем нужно составлять бизнес-кейс, чтобы определить, це-
192
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
лесообразно ли их устранение. Часто решение опира-
ется на оценки, точность которых можно повысить с
помощью проверенных на практике измерений стои-
мости решения аналогичных проблем. Обратите вни-
мание, что решение о том, стоит ли заниматься про-
блемой и тратить на это деньги, принимается в рам-
ках процесса управления изменениями и относится к
его сфере ответственности.
Аудитория: Владелец процесса, руководство ИТ, владелец про-
цесса SLA, бизнес-клиент, члены команды, владелец
процесса SIP.
Ограничения: Менеджеры по управлению проблемами должны в
точности документировать все, чем они занимаются,
чтобы впоследствии можно было проследить, к какой
проблеме относится каждое действие.
Опасное значение: Зависит от проблемы: затраты на решение пробле-
мы ни в коем случае не должны превышать выгод.
Целевое значение: Сделать решение проблемы прибыльным.
Возможные значения: Теоретически не ограничены.
I
Метрики
управления финансами
для ИТ-услуг
Цель управления финансами для ИТ-услуГ — обеспечение рентабельного
распоряжения активами и ресурсами ИТ, используемыми в предоставлении
ИТ-услуг.
(Библиотека ITIL том «Поддержка услуг»)
Миссия: управлять затратами на ИТ-инфраструктуру и обеспечивать ста-
бильную основу для деловых решений, касающихся ИТ, путем определения
и учета затрат на предоставлени' услуг, а также обоснованного возмещения
здер кек, где эт< * "зм-окно.
Владелец процесса: руководитель ИТ.
Задача метрики: управлять затратами иа ИТ-инфраструктуру и обеспе-
чивать стабильную основу для деловых решений, касающихся ИТ, путем
определения и учета затрат на предоставление услуг, а также обоснован-
ного возмещения издержек где это возможно.
Метрика: Процент учитываемых расходов на ИТ {% расходов}
Описание: Область, на которую распространяется текущий учет затрат. CMDB предоставляет информацию об издерж- ках из базы активов — эти данные можно сравнить с записями бухгалтерии. Со временем точность CMDB повышается.
Спецификация: В конечном итоге будут рассматриваться все издерж- ки на ИТ, как прямые, так и косвенные. К тому време-
194
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
ни станут известны операционные издержки, такие как зарплата, расходы на телефонную связь, электри- чество. Можно рассчитывать показатель, пользуясь помощью бухгалтерского отдела.
Обоснование: Чем шире охват, тем лучше.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 50
Целевое значение: 70
Возможные значения: 0-100
Метрика: Число изменений, сделанных в алгоритме начисления платы {изменения}
Описание: Насколько мы близки к стабильной системе.
Спецификация: Число изменений, внесенных в алгоритм. Даже если счета в действительности не выставляются, полезно иметь алгоритм калькуляции стоимости и регулярно проверять его обоснованность.
Обоснование: В конечном итоге нам нужен алгоритм, работающий стабильно благодаря правильной модели. Но до это- го момента хорошим признаком будет активное уп- равление процессом.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 10
Целевое значение: 3
Возможные значения: 999999
Метрика: Задержки в создании финансового отчета {дни}
Описание: Сколько времени занимает подготовка отчета.
Спецификация: Регулярный финансовый отчет должен быть готов к определенной дате. Метрика показывает запаздыва- ние относительно этого срока.
I. Метрики управления финансами для ИТ-услуг
195
Обоснование: Когда процесс достигнет зрелости, отчеты будут под- готавливаться вовремя. До тех пор пользуйтесь дан- ной метрикой для оценки прогресса.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 2
Целевое значение: 1
Возможные значения: 999999
Метрика: Задержки в создании ежемесячного прогноза {дни}
Описание: Задержка, измеряемая в днях.
Спецификация: Прогноз очередных финансовых показателей состав- ляется ежемесячно.
Обоснование: По достижении зрелости процесса прогноз будет выда- ваться вовремя. До тех пор пользуйтесь данной метри- кой для оценки задержек в формировании прогноза.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 2
Целевое значение: 1
Возможные значения: 999999
Метрика: Степень достоверности (в процентах) последне- го финансового п догноза ’ % затрат}
Описание: Точность прогноза в процентах.
Спецификация: Измеряется следующим образом: Модуль (Фактиче- ские финансовые данные - Финансовый прогноз) / Фактические финансовые данные X 100 за прошед- ший период.
Обоснование: Оценивает качество управления финансами.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
196
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Ограничения: Нет
Опасное значение: 80
Целевое значение: 85
Возможные значения: 0-100
Метрика: Степень joctoi ерности (в процентах) финансо- вого прогноза на предыдущий квартал (% затрат >
Описание: Скользящий показатель — отношение сделанного ранее прогноза к фактическим данным.
Спецификация: Вычисляется по формуле: Модуль (Фактические фи- нансовые данные - Финансовый прогноз) / Факти- ческие финансовые данные х 100 за прошедший пе- риод (квартал).
Обоснование: Ответственность за сметные предположения и про- гнозы в значительной степени лежит на процессе управления мощностями, однако их правильность зависит от финансовой информации. Поэтому имеет смысл возложить ответственность за данную метри- ку на управление финансами. Одновременно такая мера побуждает группы, ответственные за управле- ние финансами и мощностями, к тесному сотрудни- честву для улучшения показателя.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 60
Целевое значение: 75
Возможные значения 0-100
Метрика: Совокупная стоимость владения (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
Возможные значения 0-5
Метрики для управления
мощностями
Цель процесса управления мощностям!1 — обеспечить, чтобы мощность
ИТ всегда была обоснованной с точки зрбния затрат и соответствовала как
текущим, так и известным будущим потребностям бизнеса.
(Библиотека ITIL, том «Поддержка услуг>Э
Миссия: обеспечить наилучшее использование инфраструктуры ИТ, опти-
мально отвечающей потребностям бизйеса сейчас и в будущем, за счет
должного понимания требований как бйзнеса’ так и инфраструктуры.
Владелец процесса: менеджер по мощностям-
Задача метрики: обеспечить эффективное управление мощностями.
Метрика: Число нарушений SLA из-за недостаточно быстрого обслужИвания {нарушения SLA}
Описание: В задачи управления мощностями входит контроль того, чтобы оговоренные в SLA показатели быстро- действия не были превышены из-за недостаточной мощности. По возможности следует учитывать здесь только инциденты, относящиеся к мощности, но это зависит от зрелости процессов управления инциден- тами и проблемам/'
Спецификация: Например, превышение времени ответа на звонок или времени отклйка приложения.
Обоснование: На основе управления мощностями прогнозируются потенциальные сб^и в обслуживании из-за проблем
200
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
с мощностью — данная метрика оценивает эффек- тивность этой деятельности.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: По возможности нужно учитывать только инциден- ты, связанные с мощностями.
Опасное значение: 2
Целевое значение: 0
Возможные значения: 999999
Задача метрики: обеспечить эффективное управление мощностями ре-
сурсов.
Метрика: Числе нарушений SLA из-за недостаточной произ- водительности компонента {нарушения SLA}
Описание: Сбои компонентов из-за недостаточной производи- тельности и т. п. проблем, связанных с нагрузкой.
Спецификация: Например, плохое быстродействие системы.
Обоснование: В функции управления мощностями ресурсов входит минимизация числа сбоев по причине недостаточ- ной мощности.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: По возможности следует учитывать только инциден- ты, связанные с мощностями.
Опасное значение: 2
Целевое значение: 0
Возможные значения: 999999
Задача метрики: обеспечивать нагрузку, достаточную для предоставле-
ния оговоренных услуг в соответствии с оговоренными уровнями обслу-
живания.
Метрика: Числе» инцидентов, вызванных недостаточной пр оизводительностью {инциденты}
Описание: В рассмотрение включаются только инциденты, от- носящиеся к производительности. Мониторинг и на-
J. Метрики для управления мощностями
201
стройка в сочетании с анализом тенденций должны предотвращать их возникновение.
Спецификация: Необходимо, чтобы в управлении инцидентами и проблемами производительность могла указываться в качестве причины при закрытии инцидентов. Так- же нужны процедуры, позволяющие решить, дей- ствительно ли причина в этом. Метрика оценивает- ся на основе данных о закрытии инцидентов.
Обоснование: Прямой показатель эффективности управления мощ- ностями.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 10
Целевое значение: 5
Возможные значения: 999999
Задача метрики: разработать рентабельный план развития мощностей
Метрика: Стоимость разработки плана развития мощнос- тей {расходы}
Описание: Суммарные расходы на планирование. Оцениваются отдельно от стандартных текущих издержек, поэто- му для определения процедур регулярного монито- ринга этих расходов потребуется проделать опреде- ленную работу совместно с группой управления фи- нансами.
Спецификация: Трудозатраты в период планирования, а также стои- мость инструментария и т.д.
Обоснование: Для учета будущих тенденций и потребностей бизне- са управление мощностями должно предусматривать разработку планов развития мощностей, причем не- обходимо, чтобы эта разработка была рентабельной. Показатель позволяет следить как за самим создани- ем планов, так и за тем, чтобы не потреблялось слиш- ком много ресурсов.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
202
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Ограничения: Для расчета данной метрики управление финансами должно вестись на достаточно высоком уровне.
Опасное значение- 30
Целевое значение: 10
Возможные значенш 999999
Задача метрики: планировать будущие требования бизнеса к развитию
ЩН ГГсЙ
Метрика: Число 1 .^запланированных приобретений аппаратных средств, нужных для повышения роизводительности {расходы}
Описание: Любое приобретение, необходимое по соображени- ям производительности, считается незапланирован- ным, если оно не было предусмотрено в плане раз- вития мощностей.
Спецификация: Сюда могут входить дополнительная оперативная память, диски, процессоры, различные системы и се- тевые устройства, приобретаемые для решения про- блем производительности и не включенные в план развития мощностей. Фиксируйте наименования или стоимость приобретений.
Обоснование: В управлении мощностями приобретения должны планироваться заранее на основе выявленных тен- денций и известных бизнес-планов, еще до того как возникнут соответствующие потребности. Метрика проверяет, сокращаются ли незапланированные при- обретения в результате улучшения планирования.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
ограничения: Нет
Опасное значение: 15
Целевое значение: 10
Возможные значения 999999
Задача метрики: предоставлять точные прогнозы будущих потребностей
в мощностях в соответствии с известными сценариями бизнеса.
J. Метрики для управления мощностями
203
Метрика: Степень достоверности (в процентах) плана предстоящих расходов {% расходов}
Описание: Насколько расходы на повышение мощности выше, чем планировалось. Изменения в связи с новыми тре- бованиями бизнеса должны отражаться в сценариях управления мощностями, а планируемые расходы — соответствующим образом корректироваться.
Спецификация: Модуль (Запланированные расходы на период - Ре- альные расходы за период) / Запланированные рас- ходы х 100 в течение заданного периода.
Обоснование: Управление мощностями разрабатывает планы по развитию мощностей, в которых прогнозируются будущие расходы согласно бизнес-планам компании. Метрика оценивает достоверность этих прогнозов.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Для получения достоверной картины управление финансами должно вестись на достаточно высо- ком уровне.
Опасное значение: 80
Целевое значение: 90
Возможные значения: 0-100
Задача метрики: предоставлять план развития мощностей для эффек-
тивного уравновешивания потребностей бизнеса и издержек.
Метрика: Процент избыточной производительности ИТ {% нагрузки}
Описание: Для измерения уровней производительности, дисков, памяти, процессоров, пропускной способности сети и т.д. можно организовать мониторинг и проверку на соответствие критериям, описанным в политике управления мощностями. Все обнаруженные при этом избыточные мощности фиксируются и сумми- руются для получения данной метрики. Следует до- биваться ее постепенного сокращения.
Спецификация: Значение показателя можно измерять путем аудита производительности ключевых CI. Оптимальный уро- вень определен в плане управления мощностями.
204
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Обоснование: В задачи управления мощностями входит обеспече- ние эффективной мощности — не слишком высокой, потому что это дорого.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
(граничения: Нет
Опасное значение: 30
Целевое значение: 20
Возможные значения: 0-100
Задача метрики: следить за инфраструктурой ИТ и выявлять тенденции
в области мощностей.
Метрика; Процент CI, для которых ведется мониторинг производительности {% CI}
Описание: Всякий раз, когда проведение мониторинга по той или иной причине прекращается для определенного числа ключевых CI, нужно учитывать данную метри- ку. Если мониторинг производительности для глав- ных серверов не ведется, то управление мощностями фактически лишено информации о тенденциях.
Спецификация: Показатель числа CI, для которых работает монито- ринг производительности. Набор CI может опреде- ляться более детально, чтобы исключить те из них, которые не имеют прямого отношения к мониторин- гу нагрузки.
Обоснование: Для управления мощностями необходимо иметь пред- ставление о текущих уровнях мощностей и соответ- ствующих тенденциях. Получить такое представле- ние позволит только эффективный мониторинг CI.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 60
Целевое значение: 70
Возможные значения: 0-100
Задача метрикг оценивать управление мощностью на основе потреб-
ностей бизнеса.
J. Метрики для управления мощностями
205
Метрика: Соотношение (в процентах) между общей и ожидаемой загрузкой ИТ-ресурсов {% загрузки}
Описание: Ожидаемая загрузка ИТ-ресурсов определяется в плане управления мощностями как и «загрузка ре- сурсов» для данной метрики.
Спецификация: Отношение общей загрузки ИТ-ресурсов к предпола- гаемой в плане управления мощностями.
Обоснование: Для управления мощностями необходимо иметь пред- ставление о текущих уровнях мощностей и соответ- ствующих тенденциях. Эту информацию необходимо связывать с планами загрузки ИТ-ресурсов на основе потребностей бизнеса, чтобы составлять достовер- ные прогнозы на будущее и понимать причины ны- нешних ошибок.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 85
Целевое значение: 80
Возможные значения: 0-100
Задача метрики: обеспечить эффективность процессов управления услу-
гами.
Метрика: Степень удовлетворенности клиентов {удовлет- воренность}
Описание: Удовлетворенность клиентов.
Спецификация: Степень удовлетворенности клиентов, измеряемая согласно диаграмме взаимоотношений процесса.
Обоснование: Удовлетворение клиента позволяет убедиться в эф- фективности результатов процесса.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: <3
Целевое значение: 4
Возможные значения: 0-5
Спецификация:
к
Метрики
управления непрерывностью
предоставления ИТ-услуг
(IT Service Continuity — ITSC)
Цель управления непрерывностью предоставления ИТ-услуг — поддержи-
вать общий процесс управления непрерывностью бизнеса, обеспечивая
восстановление работоспособности необходимого оборудования и служб
ИТ (включая компьютерные системь., сети, приложения, телекоммуника-
ции, техническую поддержку и службу Service Desk) в требуемые для биз-
неса и оговоренные с ним сроки.
(Библиотека ITIL, том «Поддержка услуг»)
Миссия: поддерживать общий процесс управления непрерывностью биз-
неса, обеспечивая восстановление работоспособности необходимого обо-
рудования и служб ИТ в требуемые для бизнеса и заранее оговоренные с
ним сроки.
Владелец процесса: менеджер по управлению непрерывностью.
Задача метрики: поддерживать общий процесс управления непрерыв-
ностью бизнеса, обеспечивая восстановление необходимого оборудова-
ния и служб ИТ в требуемые для бизнеса и оговоренные с ним сроки.
Метрика: Число услуг, не охватываемых планом ITSC
{услуги}
Описание: Для вех услуг и SLA должны быть оговорены связи с
ITSC, даже если при этом говорится, что восстанов-
ление данной услуги при чрезвычайных обстоятель-
ствах не предусмотрено.
ITSC — это непрерывность предоставления ИТ-услуг.
208
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Обоснование: Если какая-то услуга не включена в план ITSC, это риск. Метрика гарантирует контроль ситуации для всех услуг.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 10
Целевое значение: 5
Возможные значения: 999999
Метрика: Задержка с подготовкой/обновлением плана TTSC (дни}
Описание: Показатель коммерческого риска. Даты выполнения и обновления плана должны быть зафиксированы в соответствующих документах, по которым и контро- лируются.
Спецификация: Число дней от той даты, к которой должен был быть подготовлен или обновлен план, до дня его факти- ческой сдачи.
Обоснование: Если план не завершен, есть риск, что и восстановле- ния не произойдет. Метрика позволяет проследить за тем, чтобы планы формировались в срок.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 5
Целевое значение: 1
Возможные значения: 999999
Метрика: Задержка г -естированием плана ITSC {дни}
Описание: Измеряется по плану ITSC, который подлежит фор- мальному документированию.
Спецификация: Число дней между намеченной и реальной датами тестирования.
Обоснование: Задержки могут быть обусловлены многими причи- нами. Чаще всего случается, что участники тестиро- вания заняты на другом участке работы. Подобные
К. Метрики управления непрерывное гью предоставления ИТ-услуг (IT Service Continuity - ITSC) 209
задержки повышают риск для бизнеса, и к ним сле- дует привлекать внимание, чтобы многократные от- срочки не привели к серьезному отставанию в подго- товке плана.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 10
Целевое значение: 5
Возможные значения: 999999
Метрика: Число проблем, выявленных при последнем тестирован» и, которые еще не решены на данный момент времени {ппоблемы}
Описание: План, проблемы и действия подлежат формальному документированию, и данный показатель измеряет- ся по соответствующим документам.
Спецификация: При каждом тестировании плана ITSC будут возни- кать определенные вопросы, которые нужно решить для снижения риска. Метрика представляет собой число таких вопросов, остающихся на данный мо- мент открытыми.
Обоснование: Пока остаются нерешенные вопросы, план нерабо- тоспособен. Поэтому для снижения риска нужно при- стально следить за данной метрикой.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 10
Целевое значение: 5
Возможные значения: 999999
Метрика: Результаты опроса по осведомленности о непрерывности предоставления ИТ-услуг, проведенного выборочно, — процент удовлет- воритеиьиых ответов {*4 прел едших}
Описание: Опрос можно проводить регулярно, опрашивая каж- дый раз другую аудиторию, чтобы одни и те же со-
210
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
трудники давалт ответы не чаще чем раз в год- полтора.
Спецификация: Весь ИТ-персонал должен быть в курсе влияния ИТ- услуг на бизнес, потребностей и запросов бизнес- подразделений. Опрос для проверки уровня осве- домленности можно проводить регулярно (напри- мер, раз в месяц), привлекая разных сотрудников. Набранные баллы характеризуют уровень их осве- домленности.
Обоснование: Исследование оценивает успешность коммуникаци- онного плана. Плохие результаты означают необхо- димость изменить метод информирования, способ представления или передачи информации, а возмож- но, потребность в специальных учебных курсах или лекциях для повышения осведомленности.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 90
Целевое значение: 95
Возможные значения: 0-100
Метрика: Число выявленных за данный период проблем, которые ставят под угрозу план ITSC {п роблемы}
Описание: Эти проблемы перечислены в соответствующих доку- ментах с у казанием сроков устранения и планируе- мых мер.
Спецификация: План ITSC требует доступа к оборудованию, системе резервного копирования, удаленным площадкам и персоналу. Менеджер ITSC должен выявлять все про- блемы, наличествующие в текущем месяце и препят- ствующие этому доступу. К примеру, нехватка персо- нала по причине болезни может угрожать плану не- прерывности.
Обоснование: Проблемы с планами непрерывности бизнеса могут возникать по многим причинам, но их всегда важно отслеживать и принимать соответствующие меры. 1асколько ффективна эта деятельность, показывает данная метрика.
К. Метрики управления непрерывностью предоставления ИТ-услуг (IT Service Continuity — ITSC) 211
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 10
Целевое значение: 2
Возможные значения: 999999
Метрика: Число писем, предназначенных для конкретной группы сотрудников {комм <икации}
Описание: Измеряется на основе документов, которые должны содержать соответствующие письма.
Спецификация: Для каждой области ИТ-услуг и бизнеса должна быть известна ее роль в плане ITSC. Чтобы обеспечить их готовность, можно составить целевые письма для каждой области и периодически их рассылать. Мет- рика позволяет удостовериться, что это делается.
Обоснование: Если бизнес-подразделения не в курсе собственных требований к непрерывности, нельзя ожидать от них правильных действий в экстремальной ситуации. Це- левые письма позволяют проинформировать всех сотрудников о существующих инструкциях.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 0
Целевое значение: 1
Возможные значения: 999999
Метрика: Число неверных записей в справочнике группы кризисного контроля {контакты}
Описание: В идеале в случайный момент делается случайная вы- борка записей о контактах, а их правильность проверя- ется независимым агентом, например службой Service Desk.
Спецификация: Один раз за определенный период можно проверять правильность всей контактной информации и сооб- щать значение данной метрики, а также обновлять
каталог.
212
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Обоснование: Если контактная информация не во всем верна, это означает, что контроль изменений и контроль кон- фигураций в управлении планом ITSC неэффектив- ны. Кроме того, есть опасность, что в чрезвычайной ситуации не получится связаться с нужными людьми и это серьезно повлияет на возможность восстанов- ления.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 1
Целевое значение: 0
Возможные значение 999999
Метрика: апаздывание готовности резервных мощнос- тей {время}
Описание: Показатель готовности — оценка рисков для биз- неса.
Спецификация: Можно связываться с резервной площадкой в случай- но выбранные в каждом периоде моменты времени, проверяя таким образом, сколько времени займет ее приведение в рабочее состояние. Разность между этим и ожидаемым сроками представляет собой зна- чение данной метрики.
Обоснование: Если риск для бизнеса не измерять, то его нельзя и уменьшить. Данная метрика обеспечивает регуляр- ную и частую проверку того, что восстановлению не угрож нот проблемы, связанные с резервной площадкой. Если запаздывание часто оказывается большим, рекомендуется подыскать другую пло- щадку.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 1
Целевое значение: 0
Возможные значения: 999999
К. Метрики управления непрерывностью предоставления ИТ-услуг (IT Service Continuity — ITSC) 213
Метрика: Степень удовлетворенности клиентов {удовлет- воренность}
Описание: Оцениваемся не на основе конкретных аварий, кото- рые, как мы надеемся, не произойдут, а исходя из удовлетворенности бизнес-подразделений планиро- ванием и процессом, поддерживающим планы в ак- туальном состояние
Спецификация: Измеряется в соответствии с диаграммой взаимоот- ношений процесса.
Обоснование: Непрерывность предоставления ИТ-услуг — это про- цесс планирования, который красной нитью прохо- дит через все бизнес-операции и подразделения орга- низации. Важно, чтобы пользователи, затрагиваемые данным процессом, были удовлетворены его резуль- тативностью и тем, как он на них влияет.
Аудитория: Владелец процесса, руководство ИТ, владелец про- цесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: <3
Целевое значение: 4
Возможные значения: 0-5
L
Метрики
управления доступностью
Цель управления доступностью — оптимизировать потенциал инфраструк-
туры ИТ, организации обслуживания и поддержки, предоставлять рента-
бельный и устойчивый уровень доступности, позволяющий реализовывать
задачи компании.
(Лучшие практики ITIL сервисной поддержки OGC)
Формулировка миссии: обеспечить предоставление ИТ-обслуживания в
нужное время в нужном месте для нуждающихся пользователей с помощью
планирования и построения надежной и устойчивой инфраструктуры,
управления взаимоотношениями с ключевыми поставщиками и партне-
рами в соответствии с требованиями сервиса.
Владелец процесса: управляющий доступностью.
Задача метрики: обеспечить предоставление ИТ'обслуживания в нужное
время в нужном месте для нуждающихся пользователей с помощью плани-
рования и построения надежной и устойчивой инфраструктуры, управле-
ния взаимоотношениями с ключевыми поставщиками и партнерами в со-
ответствии с требованиями сервиса.
Метрика: Простой, недоступность обслуживания
{минуты}
Описание:
Спецификация:
Любое время, когда услуга недоступна в часы рабо-
ты, обусловленные договором.
Время в минутах, в течение'которого услуга не дей-
ствует. Метрика показывает доступность сервиса.
216
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Обоснование: Прямой показатель общей доступности.
Аудитория: Владелец процесса, руководство ИТ, владелец SLA, клиент бизнеса, члены команды, владелец SIP.
Ограничения: Определить доступность сервиса достаточно пробле- матично, особенно если он предназначен для многих пользователей и включает разнообразные функции. Представьте услугу, которой пользуются 1000 чело- век: вполне возможно, что в какой-то момент даже два пользователя не смогут получить к ней доступ. Сервис недоступен полностью? Или частично? Или все же доступен? Уровни сервиса должны оговари- ваться в контрактах, чтобы организация ИТ-обслу- живания всегда могла определить, в какой степени доступна та или иная услуга.
Опасное значение: 40
Целевое значение: 20
Возможные значения: 999999
Метрика: Недоп упность компонента {минуты}
Описание: Бездействие компонента, оцениваемое операциями на уровне управляемого объекта (МО), а не CI. Изме- рения лучше всего проводить с помощью инструмен- та мониторинга операций.
Спецификация: Время, в течение которого компонент бездействует.
Обоснование: Даже если компоненты (особенно те, которые име- ются в избытке) выходят из строя, не оказывая явно- го влияния на сервис, они повышают его уязвимость ко всем последуюпдим неполадкам. По этой причине важно обеспечить надежность как компонента, так и услуги.
Аудитория: Владелец процесса, руководство ИТ, владелец SLA, клиент бизнеса, члены команды, владелец SIP.
Ограничения: Метрика не связана напрямую с уровнем сервиса, но представляет для него косвенную угрозу. Ею можно пользоваться только в контексте OLA или UC.
Опасное значение: 60
Целевое значение: 30
Возможные значения: 999999
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
Метрика: Время устранения неполадки {минуты}
Описание: Время с момента обнаружения неполадки до возоб- новления сервиса.
Спецификация: Складывается из четырех составляющих: времени реагирования на неполадку, времени ремонта, вре- мени восстановления и времени возобновления сер- виса.
Обоснование: Если детальное управление реагированием/ремон- том/восстановлением/возобновлением недоступно, можно использовать сумму этих элементов для регу- лирования времени с момента обнаружения пробле- мы до возобновления сервиса.
Аудитория: Владелец процесса, руководство ИТ, владелец SLA, клиент бизнеса, члены команды, владелец SIP.
Ограничения: Нет
Опасное значение: 40
Целевое значение: 20
Возможные значения: 999999
220
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика: MTBSI (среднее время между системными непс ладками) {минуты}
Описание Среднее время между возникновением следующих друг за другом системных неполадок. Показывает уровень стабильности сервиса.
Спецификация: Среднее время между возникновением неполадок, измеряемое в минутах, часах или днях .
Обоснование: Метрика имеет большое значение для понимания «до- ступности» сервиса. Например, доступность, равная 99,99%, может свидетельствовать как об одном единс- твенном факте часового простоя, так и о 365 неполад- ках общей продолжительностью 9 секунд, —• все это по-разному влияет на пользователей. По значению MTBSI можно сделать вывод о стабильности сервиса.
Аудитория: Владелец процесса, руководство ИТ, владелец SLA, клиент бизнеса, члены команды, владелец SIP.
Ограничения: Нет
Опасное значение: 150
Целевое значение: 200
Возможные значения: 999999
Метрика: MTTR (среднее время прекращения простоя, среднее в;»емя восстановления) {минугы}
Описание: MTTR — это стандартный показатель доступности, измеряющий среднее время с момента возникнове- нием неполадки до ее устранения (среднее время простоя, приходящееся на одну неполадку).
Спецификация: Среднее время восстановления операционного стату- са или время простоя при сбое сервиса (неполадке).
Обоснование: Объектом измерения является сервис, а не компо- нент, что позволяет компании сосредоточиться на нужном уровне.
Аудитория: Владелец процесса, руководство ИТ, владелец SLA, клиент бизнеса, члены команды, владелец SIP.
Ограничения: Нет
Опасное значение: 40
Целевое значение: 20
Возможные значения: -99999
L. Метрики управления доступностью
221
Метрика: Критическое время сбоя {минуты}
Описание: Критическим периоде м для услуг, предоставляемых финансовыми системами, может быть 27-29 числа каждого месяца. Метрика измеряет общее время про- стоя (в минутах) в течение этого периода.
Спецификация: Оценивается продолжительность нарушения обслу- живания в критический период времени. Фактор «критичности» определяется видом сервиса. Напри- мер, для электронной корреспонденции наиболее вероятным временем возникновения неполадок яв- ляется промежуток с восьми до десяти утра, когда люди приходят на работу в офис и просматриваю] входящие сообщения.
Обоснование: Данный показатель критического времени поддерж- ки позволяет выявить проблемы, которые представ- ляются более серьезными, чем рядовые нарушения SLA.
Аудитория: Владелец процесса, руководство ИТ, владелец SLA, клиент бизнеса, члены команды, владелец SIP.
Ограничения: Нет
Опасное значение: 40
Целевое значение: 20
Возможные значения: 999999
Метрика: Недоступнг сть услуг г[ тьей сгоро ны {м гнуты}
Описание: Время в минутах, в течение которого ИТ-услуги тре- тьей стороны недоступны.
Спецификация: Простой из-за неполадок в обслуживании, предостав- ляемом третьей стороной.
Обоснование: Простой в обслуживании, предоставляемом третьей стороной, представляет особый интерес для управле- ния доступностью.
Аудитория: Владелец процесса, руководство ИТ, владелец SLA, клиент бизнеса, члены команды, владелец SIP.
Ограничения: Нет
Опасное значение: 120
Целевое значение: 60
Возможные значения: 999999
222
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика: Недоступность компонентов, поставляемых тре- тьей стороной {минуты}
Описание: Объектом оценки являются компоненты — перво- источник любых простоев в обслуживании. Данная метрика дополняет предыдущую (которая сосредо- точивается на обслуживании].
Спецификация: Время, в течение которого компонент, поставляемый третьей стороной, был недоступен.
Обоснование: Роль управления доступностью отчасти сводится к анализу доступности уровня компонентов. Даже если последние (особенно те, что имеются в избытке) вы- ходят из строя, не оказывая явного влияния на сер- вис, они повышают его уязвимость ко всем последу- ющим неполадкам. По этой причине важно обеспе- чить надежность как услуги, так и компонента.
Аудитория: Владелец процесса, руководство ИТ, владелец SLA, Клиент бизнеса, члены команды, владелец SIP.
Ограничения: Нет
Опасное значение: 60
Целевое значение: 30
Возможные значения: 999999
Задача метрики: обеспечить эффективное управление обслуживанием и
доступностью компонентов.
Метрика: Время возобновления недоступных услуг (мину1 ы}
Описание: Время, требуемое для возобновления обслуживания клиентов.
Спецификация: Измеряется в человеко-часах, израсходованных на решение проблем доступности.
Обоснование: Существует множество методов сокращения простоя, Связанного с ремонтом: следует оценить эффектив- ность каждого из них. Избыточные системы могут Сократить время возобновления сервиса, а метрика Позволяет выявить услуги, которые требуют приня- тия соответствующих мер.
Аудитория: Владелец процесса, руководство ИТ, владелец SLA, клиент бизнеса, члены команды, владелец SIP.
L. Метрики управления доступностью
223
Ограничения: Необходимо наличие системы почасовой регистра- ции.
Опасное значение: 60
Целевое значение: 30
Возможные значения: 999999
Метрика: Количество повторных сбоев {неполадки}
Описание: Количество CI, которые неоднократно выходили из строя.
Спецификация: Сумма всех сбоев CI.
Обоснование: Одна из обязанностей управления доступностью за- ключается в сокращении многократных сбоев. О ее эффективности можно судить по значению метрики. Отчет о CI, перечисленных в порядке возрастания числа сбоев, позволяет управлению доступностью выбирать наиболее слабые элементы конфигурации и принимать решение об их замене, анализе или преобразовании с целью повышения работоспособ- ности.
Аудитория: Владе лец процесса, руководство ИТ, владелец SLA, клиент бизнеса, члены команды, владелец SIP.
Ограничения: Нет
Опасное значение: 600
Целевое значение: 300
Возможные значения: 999999
Метрики для управления
информационной
безопасностью
Цель управления информационной безопасностью — обеспечить эффек-
тивную защиту информации в рамках всей деятельности по предоставле-
нию услуг.
Во-первых, выполнять внешние требования безопасности, вытекающие
из различных SLA, контрактов, законодательных норм и всевозможных
политик безопасности.
Во-вторых, выполнять внутренние требования безопасности. Это нужно,
чтобы обеспечить непрерывность деятельности самого поставщика ИТ-
услуг. Необходимо, кроме того, упростить управление уровнем обслужива-
ния с точки зрения информационной безопасности. Понятно, что работать
с множеством разнообразных SLA значительно сложнее, чем с небольшим
их числом. По этой причине должен быть установлен определенный базо-
вый (так называемый стандартный) уровень безопасности.
Миссия: регулировать и контролировать процесс управления информаци-
онной безопасностью с целью удовлетворения внешних требований, оп-
ределяемых SLA, контрактами, законодательством и политикой безопас-
ности компании. Обеспечить соблюдение внутренних требований безо-
пасности для поддержки непрерывности предоставления ИТ-услуг.
Владелец процесса: менеджер по информационной безопасности.
Задача метрики: регулировать и контролировать процесс управления
информационной безопасностью с целью удовлетворения внешних требо-
ваний, определяемых SLA, контрактам’ законодательством и политикой
безопасности компании. Обеспечить соблюдение внутренних требований
безопасности для поддержки непрерывности предоставления ИТ-услуг.
226
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика Число инцидентов, связанных с информацион- ной безопасностью {инциденты}
описание: Метрика основывается на записях о количестве за- крытых инцидентов и заявок.
Спецификация: Со временем для этой метрики нужно будет провес- ти бенчмаркинг. Устанавливаемые ориентиры зави- сят от уровня контроля и других факторов (качество программного обеспечения и т.д.).
Обоснование: Очень важно, чтобы процессам, относящимся к управ- лению информационной безопасностью, были доступ- ны данные о соответствующих инцидентах. Со време- нем отлаженные процессы сократят число происше- ствий и снизят их вредоносное воздействие.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
□граничения: Нет
Опасное значение: 100
Целевое значение: 50
Возможные значения: 999999
Метрика: Число решенных проблем, связанных с инфор- мационной безопасностью {проблемы}
Описание: Сколько решенных проблем было закрыто с форму- лировкой, относящейся к информационной безопас- ности.
Спецификация: Показатель характеризует эффективность управле- ния проблемами и одновременно является фунда- ментальным для оценки управления безопаснос- тью, которое должно определить для всех процессов меры защиты.
Обоснование: Решение проблем, связанных с безопасностью, при- ведет к сокращению числа инцидентов и повыше- нию доступности ИТ-услуг.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 5
М. Метрики для управления информационной безопасностью
227
Целевое значение: 10
Возможные значения: 999999
Метрика: Число решенных проблем, выявленных в ходе аудита и внутренних прове юк {прюблемы}
Описание: В списке проблем должны быть заданы сроки устра- нения, и при их превышении можно выпускать пре- дупреждения (в дополнение к данной метрике).
Спецификация: Внутренние проверки и аудиты должны выявлять второстепенные проблемы. Их решение может тре- бовать времени, и данная метрика позволяет убе- диться в том, что продвижение к поставленной цели происходит в правильном направлении.
Обоснование: Обеспечение информационной безопасности — это долгосрочный процесс совершенствования. Пробле- мы, выявляемые в ходе аудита и внутренних прове- рок, важны для получения должного контроля над данным процессом. Метрика обеспечивает постоян- ное внимание к этим проблемам.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Перечень проблем должен формально документиро- ваться.
Опасное значение: 5
Целевое значение: Возможные значения: 8 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.
23(
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Ограничения: Внешние договоры должны формально документи- роваться.
Опасное значение: 75
Целевое значение 100
Возможные значения: 0-100
Метрика: Число выявленных проблем релиза, связанных с информационной безопасностью релиза (возвраты к исходному состоянию/вирусы и т.д.) {проблемы}
Описание: Все планы релизов должны содержать нешаблонный пункт, посвященный информационной безопасности.
Спецификация: Управление релизами крайне уязвимо с точки зре- ния угроз для безопасности. Активный контроль ре- лизов (особенно срочных) со стороны управления безопасностью позволит поддерживать низкое зна- чение метрики.
Обоснование: Релизы предсгавляют высокий риск для процедур, относящихся к безопасности. Метрика обеспечивает независимое исследование допустимого уровня рис- ка для каждого плана релиза.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Ограничения: Релизы должны формально документироваться.
Опасное значение: 5
Целевое значение: 0
Возможные значения: ,'99999
Метрика: Число изменений, которые были по соображе- ниям информационной безопасности отменены (и .истема возвращена в исходное состояние) {изменения}
Описание: Значение показателя определяется по записям о вы- полненных изменениях: считаются те, где указано, что причиной возвращения системы в исходное со- стояние стала информационная безопасность.
Спецификация: Если при внесении изменений возникает проблема с информационной безопасностью, они были плохо спланированы. Неудавшееся изменение нужно все-
М. Метрики для управления информационной безопасностью
231
сторонне исследовать, чтобы исключить возможность преднамеренной атаки.
Обоснование: Изменения, включая релизы, следует должным обра- зом планировать и тестировать. Если они отменяют- ся по причинам, связанным с информационной безо- пасностью, это указывает на слабость и неэффектив- ность контроля.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 5
Целевое значение: 0
Возможные значения: 999999
Задача метрики: показывать способность организации к адаптации сис-
темы информационной безопасности путем быстрой установки защитных
патчей.
Метрика: Скорость установки патчей, связанных с инфор- мационной безопасностью {время}
Описание: Всевозможные патчи и обновления, связанные с бе- зопасностью, выпускаются довольно часто, и специ- алистам ИТ-служб приходится обновлять соответ- ствующее ПО.
Спецификация: Время с момента выпуска патча поставщиком до его установки в среде промышленной эксплуатации.
Обоснование: Чем больше время, необходимое для установки пат- ча, тем выше риск, чем оно меньше, тем уязвимость ниже.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Неполучение патчей или обновлений, связанных с безопасностью.
Опасное значение: 1 неделя
Целевое значение: 2 дня
Возможные значения: Теоретически не ограничены.
N
Метрики
для бизнес-планирования
Целью метрик бизнес-планирования является оценка воспринимаемого
качества обслуживания (Quality of Experience — QoE) — мера удовлетво-
ренности бизнеса, соотнесенная с его потребностями.
Миссия: постоянно поддерживать и повышать эффективность бизнеса
путем предоставления высококачественных услуг ИС, согласованных с
потребностями компании и способных на эти потребности реагировать,
обеспечивая при этом максимальную окупаемость инвестиций в информа-
ционные системы.
Владелец процесса: руководитель ИТ
Следующие три метрики предназначены для оценки бизнес-планирования в
целом.
Задача метрики: приведение ИТ-услуг в соответствие с потребностями
би неся.
Метрика: Средние затраты на предоставление одной услуги {затраты}
Описание: Данные о затратах извлекаются из CMDB: Число об- ращений х Расчетная стоимость обращения + Управ- ление проблемами + Постоянные издержки и т.д.
Спецификация: Метрика требует действующего процесса управления финансами, в противном случае стоимость нужно чем-либо заменить (возможно, даже интенсивностью
234
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
звонков или временем простоя в расчете на одну услу- гу). Расчет прост: Общие затраты / Число услуг. В дан- ном примере метрика выражается в процентах от пря- мых затрат. Это суммарная стоимость инцидентов, проблем, изменений и операций, посвященных опре- деленной услуге, поделенная на общее число услуг. По мере улучшения обслуживания показатель должен снижаться, несмотря на то что запуск новых услуг может характеризоваться высокими издержками.
Обоснование: Это сложный (не соответствующий критериям SMART) показатель. Тем не менее управлению финансами сто- ит стремиться измерить его как можно точнее, чтобы бизнес-планирование могло представить руководству верную картину стоимости услуг.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Нет
Опасное значение: 30
Целевое значение: 20
Возможные значения: О-1ОО
Задача метрики: обеспечить эффективную связь информационных тех-
нологий и бизнеса.
Метрика: Степень удовлетворенности клиентов {уд ивлетво ценность}
Описание: Общая сумма всех показателей удовлетворенности клиентов.
Спецификация: Удовлетворенность клиентов управлением ИТ-услу- ’ами.
Обоснование: В конечном итоге именно бизнес-планирование несет ответственность за обеспечение эффективной связи бизнеса и МТ.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Нет
Опасное значение: <3
N. Метрики для бизнес-планирования
235
Целевое значение: 4
Возможные значения: 0-5
Метрика: Знание бизнеса сотрудниками ИТ-подразделе- ния {удовлетворенн" ь}
Описание: Насколько представители бизнеса удовлетворены уровнем знаний о бизнесе у сотрудников ИТ-подраз- деления.
Спецификация: В опросы, проводимые для изучения степени удов- летворенности клиентов, следует включить вопрос о том, насколько приемлем с точки зрения респон дента уровень знаний о бизнесе, демонстрируемый ИТ-персоналом. Имеются в виду знания, относящи- еся к бизнес-функции респондента, которые были продемонстрированы при работе с ним сотрудника- ми ИТ-подразделения.
Обоснование: Все сотрудники ИТ-подразделения должны обладать определенными знаниями и представлениями о том бизнесе, который они обслуживают. Показатель ха- рактеризует уровень этих знаний. Он применяется к бизнес-планированию, поскольку для эффективной связи между ИТ и бизнесом необходимо доверие, а оно требует определенного уровня взаимопонима- ния и знаний друг о друге.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: <3
Целевое значение: 4
Возможные значения: 0-5
N.I. Управление взаимоотношениями с бизнесом
Метрика: Число жалоб на обслуживание {жалобы}
Описание: Общее число жалоб на обслуживание, поступивших в ИТ-подразделение.
Спецификация: Позволяет судить об удовлетворенности клиентов и качестве взаимоотношений между подразделениями.
236
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Обоснование: Для хорошего управления взаимоотношениями меж- ду ИТ-подразделением и клиентом нужно иметь представление об удовлетворенности последнего.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Не все, кто недоволен работой ИТ-подразделения, дают об этом знать.
Опасное значение: 20
Целевое значение: 10
Возможные значения: 999999
Метрика: Число невыполненных действий с момента последней проверки данного сервиса {действия}
Описание: Число действий, которые были намечены при послед- ней проверке сервиса, но еще не были выполнены.
Спецификация: Метрика показывает, насколько успешно подразде- ление проводит проверки и выполняет намеченные действия.
Обоснование: Эффективное выполнение намеченных действий по- вышает удовлетворенность клиентов и тем самым улучшает взаимоотношения с бизнесом.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Метрика характеризует скорость, но не качество вы- полнения действий.
Опасное значение: 15
Целевое значение: 10
Возможные значения 999999
N.2. Управление взаимоотношениями с поставщиками
Метрика:
Описание:
Максимальное число инцидентов, связанных
с одним поставщиком {инци> енты)
Каждый инцидент прослеживается до конкретного
поставщика. Учитывается число инцидентов в расче-
те на одного поставщика.
N. Метрики для бизнес-планирования
237
Спецификация: Число инцидентов, полностью или частично спрово- цированных поставщиком или произошедших по его вине. При качественном управлении взаимоотноше- ниями с поставщиками этот показатель должен сни- зиться. Учитываются инциденты, а не проблемы, по- скольку необходимо минимизировать нарушения ра- боты бизнеса.
Обоснование: Для хорошего управления взаимоотношениями с по- ставщиками очень важно знать уровень удовлетво- ренности обслуживанием.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Метрика не учитывает серьезность последствий ин- цидентов. Вполне возможно, что поставщик, по вине которого произошел всего один, но очень крупный инцидент, нанес компании больше вреда, чем тот, из-за которого случилось много мелких неполадок.
Опасное значение: 70
Целевое значение: 50
Возможные значения: 999999
Метрика: Процент постоянных поставщиков, удовлетво- ряющих стандартам {% поставщиков}
Описание: Какая часть поставщиков удовлетворяет стандартам.
Спецификация: Речь идет о стандартах IS09000 или IS020000. Цель — достигнуть состояния, когда им будут соответство- вать все поставщики. Как только это произойдет, можно заменить метрику показателем качества, вы- бранным по тактическим соображениям.
Обоснование: Вероятность инцидента или проблемы снижается, когда все части системы подчиняются одним и тем же механизмам работы.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес- клиент, члены команды, владе- лец процесса SIP.
Ограничения: Поставщики могут соответствовать стандартам на словах, но это утверждение очень сложно проверить.
Опасное значение: 85
238
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Целевое значение: 95
Возможные значения: 0-10U
Метрика: Процент проверок качества услуг поставщиков на соответствие определенным требованиям, проведенных в срок {% проверок}
Описание: Процент запланированных на регулярной основе про- верок поставщиков, которые были проведены свое- временно.
Спецификация: Графики проверок, отражающие информацию о тех проверках, которые должны были быть проведены в прошлом и по которым при этом не составлены ито- говые отчеты либо перечни необходимых действий.
Обоснование: Проверки поставщиков могут показаться несущест- венными, когда дела идут хорошо, и о них тогда легко забывать. Это опасно, поскольку увеличива- ется риск перерастания мелких неполадок, остав- ленных без внимания, в серьезные проблемы.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса 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
Возможные значения: 9999999
Задача метрики: эффективное предоставление услуг.
Метрика: Степень удовлетворенности клиентов {удовлет- ор< пзость}
Описание: Показатель качества предоставления услуг на уровне бизнеса.
Спецификация: Общая удовлетворенность клиентов аналогично управлению уровнем обслуживания.
Обоснование: Эффективность предоставления услуг оценивается по степени удовлетворенности клиентов.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Нет
Опасное значение. <3
N. Метрики для бизнес-планирования
241
Целевое значение: 4
Возможные значения: 0-5
N.4. Планирование, анализ и развитие
Миссия: обеспечить эффективное планирование ИТ-процессов и правиль-
ную р еализацию заработанных и одобренных планов.
Владелец процесса: проектное бюро.
Задача метрики: проверять планы и модифицировать их согласно требо-
ваниям бизнеса.
Метрика: Число проблем, выявленных при окончатель- ной проверке плана {проблемы}
Описание: Число проблем.
Спецификация: Число проблем, выявленных при проверке.
Обоснование: Показывает, сколько изменений требуется внести в документ, — со временем, по мере совершенствова- ния процессов, это число должно уменьшиться.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 8
Целевое значение: 6
Возможные значения: 999999
Метрика: Число планов, одобренных для реализации {планы}
Описание: Оценивается деятельность не только по разработке, но и по утверждению планов. Однако сложность пла- нов не учитывается — данный параметр отражает исключительно количественную характеристику. Полезнее, хотя и сложнее, было бы оценивать про- гнозируемые масштабы проектов в человеко-часах, а не просто считать их поштучно.
Спецификация: Поскольку документация будет храниться в CMDB, информацию о статусе можно узнавать непосред-
242
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
ственно оттуда. Учитываются те планы, которые пе- решли в категорию подписанных.
Обоснование: Планы необходимо не только создавать, но и утверж- дать.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 2
Целевое значение: 4
Возможные значения: 999999
N.5 Взаимодействие, обучение и информирование
Миссия: информировать пользователей и клиентов ИТ о текущих и буду-
щих планах и поощря'” , аыд1 Кенис, идей по улучшению.
Владелец проиесса проектное бюро.
Задача метрики: укомплектовать все рабочие места квалифицированны-
ми кадрами.
Метрика: Число действий, предусмотренных планом информирования, которые не были выполнены в срок {действия}
Описание: Для всех действий, предусмотренных планом инфор- мирования, в нем должен быть обозначен определен- ный срок. М"трика показывает, сколько действий не было выполнено к установленной для них дате.
Спецификация: Действия, которые оставались невыполненными на момент измерения.
Обоснование: Что запланировано, то должно быть выполнено. Мет- рика показывает, насколько эффективно это дела- ется.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 5
N. Метрики для бизнес-планирования
243
Целевое значение: 3
Возможные значения: 999999
Метрика: Процент ИТ-персонала с неоптимальным для занимаемой должности уровнем подготовки {% персонала}
Описание: Уровень образования и опыта сотрудников компа- нии по данным отдела кадров либо базы данных по подготовке и компетентности в области ИТ.
Спецификация: Оценка квалификации персонала.
Обоснование: Стандарт IS020000 требует, чтобы персонал был в состоянии продемонстрировать профессиональную подготовленность и опыт, соответствующие занима- емой должности.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 2
Целевое значение: 1
Возможные значения: 0-100
Метрики для постоянно
действующей программы
по улучшению услуг (SIP)
Миссия: выполнять SIP как непрерывную программу. Обмениваться ин-
формацией с руководством ИТ-подразделения и обеспечить специальное
рассмотрение каждого процесса в рамках SIP как минимум раз в два года.
При этом должны своевременно рассматриваться процессы, которые, как
показывают их метрики, требуют наибольшего внимания.
Владелеи процесса: проектное бюро.
Задача метрики: улучшать текущее функционирование процесса в соот-
ветствии с требованиями бизнеса.
Метрика: Общая степень удовлетворенности клиентов {удовлетворенность}
Описание: Среднее всех показателей степеней удовлетворен- ности клиентов.
Спецификация: Общая степень удовлетворенности конечных клиен- тов. Задача SIP — повышать этот показатель, а также сокращать издержки.
Обоснование: Со временем степень удовлетворенности клиентов должна повышаться благодаря SIP.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Нет
Опасное значение: <3
246
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Целевое значение: 4
Возможные значения: 0-5
Метрика: Процент экономии средств (достигнутой благодаря SIP) для процессов {% экономии}
Описание: Насколько снизилась благодаря SIP общая сумма рас- ходов на НТ.
Спецификация: Как правило, в рамках SIP по очереди рассматривают- ся все процессы. В результате такого рассмотрения должна достигаться определенная выгода — экономия средств. С какой точностью ее измерять, зависит от процесса и может определяться в SIP. Измерение про- изводится до завершения SIP следующего процесса. Это позволяет вовремя обнаруживать непредвиденные негативные последствия SIP и определять вклад про- граммы в совершенствование каждого из процессов.
Обоснование: Усовершенствование в рамках SIP должно давать ощутимые результаты, тогда экономия будет изме- римой и заметной.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Чтобы получать правильные значения, должен дей- ствовать процесс управления финансами для ИТ.
Опасное значение: 5
Целевое значение: 10
Возможные значения: 0-100
Метрика: Процент процессов, для которых SIP задержива- ется {% процессов}
Описание: Учитываются процессы, для которых задерживается рассмотрение их работы в рамках SIP.
Спецификация: Если SIP для десяти ключевых процессов ITIL выпол- няется каждые десять месяцев (по процессу в ме- сяц), опозданием считается ситуация, когда с мо- мента последнего усовершенствования некоторого процесса прошло одиннадцать или более месяцев.
Обоснование: Хотя SIP сосредоточивается в первую очередь на тех процессах, которые, как показывают метрики, нужда-
О Метрики для постоянно действующей программы по улучшению услуг (SIP)
247
ются в улучшении, периодическим проверкам долж- ны подвергаться все процессы.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Нет
Опасное значение: 20
Целевое значение: 10
Возможные значения: 0-100
Метрика: Число действий, которые были одобрены, но не выполн~ны и не достигли цели {действия}
Описание: Что не было сделано.
Спецификация: Все действия в рамках SIP документируются, цели предполагаемых усовершенствований согласуются, и весь план утверждается. Метрика отслеживает вы- полнение этих действий. Без этого SIP не может счи- таться успешной.
Обоснование: Действия, рекомендуемые SIP, должны соответство- вать критериям SMART. Это означает, что мы можем отслеживать их результаты. Очень важно, чтобы ожи- даемые усовершенствования действительно были до- стигнуты. Метрика показывает, так ли это.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Нет
Опасное значение: 5
Целевое значение: 3
Возможные значения: 999999
Метрика: Число невыполненных действий, которые были записаны в плане информирования 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.
Ограничения: Нет
Опасное значение: 2
Целевое значение: 2
Возможные значения 9999999
Задача метрика обеспечить измеримый прогресс процессов.
Метрика: Общий прогресс с момента последнего бенч- маркинга прогресса}
Описание: Изменение показателей процессов, рассчитанное как скользящее среднее за три месяца.
Спецификация: Входные данные должны собираться по всем процес- сам. Важно учесть и измерить общий вклад всех вла- дельцев процессов.
Обоснование: Следует ежегодно проводить бенчмаркинг метрик, чтобы оценивать процессы в соответствии с его по- казателями. Показатели процессов, усовершенство- ванных в рамках SIP, должны улучшаться.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Чтобы данная метрика имела смысл, все остальные метрики должны быть теми же, что и в момент бенч- маркинга.
Опасное значение: 3
Целевое значение: 5
Возможные значения: 0-100
Задача метрики: вносить эффективные изменения в процессы управле-
ния услугами.
Метрика: Число рекомендаций по улучшению, получен- ных от владельцев других процессов {рекомен- дации}
Описание: Когда процесс совершенствуется в рамках SIP, вла- дельцам связанных с ним других процессов следует
0. Метрики для постоянно действующей программы по улучшению услуг (SIP)
251
высказывать свои рекомендации. Степень их актив- ности оценивается данной метрикой.
Спецификация: Показатель активности.
Обоснование: SIP — не внешний аудит. Это программа, получаю- щая информацию из метрик процесса и рекоменда- ции от владельцев смеждых процессов. Очень важно, чтобы эти рекомендации поступали.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Рекомендации владельцев процессов должны фор- мально документироваться.
Опасное значение: 3
Целевое значение: 5
Возможные значения: 999999
Метрика: Число изменений, требуемых для улучшения процесса {изменения}
Описание: Изменения, необходимые для улучшения процессов.
Спецификация: Запросы на изменение (RFC) от процесса SIP.
Обоснование: За изменение процессов отвечает процесс управле- ния изменениями. Поэтому число RFC показывает степень активности процесса SIP и объем измене- ний, необходимых рассмотренных процессов.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Нет
Опасное значение: 3
Целевое значение: 5
Возможные значения: 999999
Метрики
для управления рисками
Миссия: управление рисками в ITIL относится к процессу управления до-
ступностью, хотя используется и в ряде других областей. Так как степень
удовлетворенности клиентов является одной из метрик управления доступ-
ностью, для управления рисками она не оценивается
Владелец процесса: менеджер по процессу управления доступностью.
Задача метрики: управление рисками в ITIL относится к процессу управ-
ления доступностью, хотя используется и в ряде других областей.
Метрика: Процент CI, охватываемых анализом воздейст- вий на бизнес (Business Impact Analysis — BIA) {% CI}
Описание: Выполнен ли BIA?
Спецификация: Анализ воздействия на бизнес рассматривает классы CI — не требуется рассматривать каждый CI в отдель- ности. В идеале все CI должны быть привязаны к со- ответствующему BIA. Так как степень удовлетворен- ности клиентов является одной из метрик управле- ния доступностью, для управления рисками она не оценивается.
Обоснование: В некоторый момент все CI должны быть включены в BIA и отмечены соответствующим образом.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
254
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Опасное значение: 60
Целевое значение: 75
Возможные значения: О-1ОО
Задача метрики: управление непрерывностью предоставления ИТ-ус-
луг планирует сократить воздействие на бизнес всех прогнозируемых
рисков.
Метрика: Процент документов BIA, не пересматривав- шихся в течение требуемого времени {% доку- ментов}
Описание: В большинстве организаций BIA следует пересмат- ривать раз в год — или чаще, если обстоятельства быстро меняются. Независимо от того, какая пери- одичность пересмотра определена для данной мет- рики, этот срок должен быть определен и докумен- тально зарегистрирован.
Спецификация: Показатель, подтверждающий своевременность пе- ресмотров BIA.
Обоснование: Если BIA проводится нерегулярно, в вычислительной среде могут происходить такие изменения, которые усиливают (или ослабляют) воздействие различных сценариев, установленных ранее. Это означает, что уязвимость может быть выше, чем предполагалось, или, наоборот, указывать на то, что в дорогостоящих мероприятиях по снижению риска не было необхо- димости.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 12
Целевое значение: 20
Возможные значения: 0-100
Метрика: Процент процессов, подлежащих оценке со стороны операционного риска (Operational Risk Assessment — ORA) {% процессов)
Описание: Полезно проводить ORA в рамках процесса SIP, при- чем важно делать это как минимум раз в год. Чтобы
Р. Метрики для управления рисками
255
оценить операционный риск, в описании каждого инцидента должен присутствовать раздел, где пере- числены связанные с ним проявившиеся риски.
Спецификация: Все процессы подвержены операционному риску. Метрика учитывает те из них, для которых этот риск в итоге был реализован в форме инцидентов.
Обоснование: Метрика помогает составить картину того, каким образом инциденты соотносятся с операционным риском, и какие процессы в связи с этим подверже- ны наибольшей опасности.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 20
Целевое значение: 12
Возможные значения: 0-00
Задача метрики: управление непрерывностью предоставления ИТ-услуг
направлено на сокращение вредоносного воздействия всех прогнозируе-
мых рисков.
Метрика: Число инцидентов в связи с рисками, не учтен- ными в рамках ORA {инциденты}
Описание: Оценка операционного риска (ORA) должна быть максимально точной. Метрика соответствует степе- ни ее ошибочности — учитываются события, кото- рые в принципе могли бы оказать сильное влияние на организацию и при этом не были ни предсказа- ны, ни спрогнозированы.
Спецификация: Выявление инцидентов, которые должны быть учте- ны, и сообщение о них — задача процесса управл» ния проблемами. Если, к примеру, релиз программно- го обеспечения был установлен без предварительной ORA, связанные с ним инциденты являются неучтен- ными рисками. Чтобы измерить показатель, понадо- бится связывать CI с соответствующими ORA.
Обоснование: Очень важно понимать истинную степень достовер- ности ORA. Предусмотреть все опасности невозмож-
256
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
но, тем не менее частота встречаемости событий, не учтенных в ORA, показывает, в каких областях мож- но улучшить процесс распознавания рисков.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 20
Целевое значение: 10
Возможные значения: 999999
Метрика: Процент инцидентов частота которых превы- шает предсказанную при ORA {% инцидентов}
Описание: ORA позволяет предсказать высокую, среднюю или низкую вероятность риска для конфигурационных элементов. Если прогнозы регулярно не оправдыва- ются, необходимо корректировать ORA в соответ- ствии с реальными рисками.
Спецификация: Метрика ребует количественного определения того, что считать высокой, средней и низкой вероятнос- тью (например, высокая — более 200 событий в ме- сяц, средняя — от 100 до 200, низкая — менее 100). Показывает, насколько прогнозируемый риск соот- ветствует реальной частоте, с которой происходят инциденты.
Обоснование: Прогнозы по своей природе недостоверны. Тем не менее для бизнеса важно, чтобы они составлялись, причем с максимальной достоверностью. Метрика обеспечивает сравнение прогнозов с реальными со- бытиями и выявление отклонений, что позволяет по- высить достоверность.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 70
Целевое значение: 50
Возможные значения: О-1ОО
Р. Метрики для управления рисками
257
Метрика: Процент CI, длительность простоя которых превышает предсказаны ><> при ORA {% CI}
Описание: Прогнозируемое воздействие конкретных рисков на бизнес можно сравнивать с реальным, чтобы повы- сить достоверность прогнозов. Это возможно и до- пустимо лишь в отношении распространенных низ- коуровневых рисков.
Спецификация: С помощью вышеупомянутой связи можно рассчи- тать предсказуемое воздействие простоя определен- ного CI на бизнес и сравнить с реальным временем, в течение которого простой этого CI нарушал нор- мальное функционирование бизнеса.
Обоснование: Предсказание воздействия на бизнес существенно д ля принятия решений о ресурсах, необходимых для уменьшения риска. Если прогнозы ошибочны, то риск для бизнеса возрастает. Метрика обеспечивает сравнение реального воздействия с прогнозируемым для повышения достоверности прогнозов.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Ограничения: Метрика неприменима и не будет способствовать улучшению качества прогнозирования в случае зна- чительных, нетипичных рисков и их последствий.
Опасное значение: 70
Целевое значение: 50
Возможные значения: 0-100
Задача метрики: управление непрерывностью предоставления ИТ-
услуг позволяет снизить вредоносное воздействие всех прогнозируемых
рисков.
Метрика: Число действий, направленных на сокращение риска {действия}
Описание: Процесс документирования действий, предпринима- емых в ответ на выявленные риски, должен формаль- но контролироваться, что обеспечит автоматический учет этих действии
Спецификация: В качестве реакции на расхождения, оцениваемые с помощью описанных выше метрик, а также в рамках
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.
Нет
1
3
999999
Метрики для управления
документацией
Миссия: соответствие стандартам и отслеживание метрик управления до-
кументацией. Обеспечить безопасное хранение документов и одновремен-
но их качественную индексацию с целью упрощения доступа для автори-
зованных пользователей. Вести контрольные записи и проверять, чтобы
управление всеми существенными документами подчинялось плану непре-
рывности предоставления ИТ-услуг и благодаря этому была обеспечена их
доступность в случае крупной аварии.
Владелец процесса: менеджер процесса управления конфигурациями.
Задача метрики: следование политике управления документами.
Метрика: Процент документов, для которых не была проведена в срок плановая проверка {% юкументов}
Описание: Документы, которые устарели из-за того, что не была проведена плановая проверка.
Спецификация: Документы с истекшим сроком проверки.
Обоснование: Если документы не пересматриваются в течение ра- нее определенных сроков, то опирающиеся на них планы также устаревают и могут привести к перебо- ям в обслуживании.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 5
262
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Целевое значение: 3
Возможные значения: 0-100
Метрика: Процент документов, не пересматривавшихся в течение года {% документов}
Описание: Проходили ли документы ежегодную проверку?
Спецификация: Должна быть указана периодичность проверки, оп- ределенная в политике управления документацией (год — средний срок).
Обоснование: Все документы должны пересматриваться и в зависи- мости от того, актуальны ли они, либо изменяться и помечаться как действительные, либо удаляться.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 5
Целевое значение: 3
Возможные значения 0-100
Метрика: Процент документов, не использовавшихся в течение года {% документов)
Описание: Документы, которыми долго не пользовались.
Спецификация: Неиспользуемые документы.
Обоснование: Точный срок зависит от политики управления доку- ментацией, но неиспользуемые документы юлжны периодически пересматриваться с точки зрения их существенности и возможности удаления.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 15
Целевое значение: 10
Возможные значения О-1ОО
Метрика. Число невыполненных запросов о внесении изменений в документы {запросы
Описание: Документы, запросы об изменении которых не были удовлетворены.
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
Метрика: Число несоответствий между отдельными планами и общим планом по управлению услугами {несоответствия}
Описание: Если централизованная подготовка всех планов не позволяет достичь согласованности, необходима руч- ная перекрестная проверка.
Спецификация: Планы должны быть взаимно согласованы и отве- чать политике организации. Метрика выявляет лю- бые несоответствия.
Q. Метрики для управления документацией
265
Обоснование: Залогом эффектив ности планов является последова- тельность их исполнения.
Аудитория: Владелец процессе!, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 10
Целевое значение: 5
Возможные значения: 999999
Задача метрики: обеспечить безопасное хранение документов, относя-
щихся к поддержке друг их процессов
Метрика: Число инцидентов, относящихся к ошибкам в документации {инциденты}
Описание: Подсчитывается по записям о закрытии инцидентов и звонков в журнале регистрации.
Спецификация: Инциденты, которые согласно коду закрытия связа- ны с ошибками в документации.
Обоснование: Процесс управления документацией должен рабо- тать так, чтобы ошибки или неверные сведения не приводили к инцидентам.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 40
Целевое значение: 20
Возможные значения: 999999
Задача метрики: обеспечение эффективности процессов управления
документацией.
Метрика: Степень удовлетворенности клиентов {удовлет- воренность}
Описание: Значение показателя удовлетворенности клиентов для процесса (процессов), наиболее тесно связанного (связанных) с данным.
266 МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Спецификация: Степень удовлетворенности клиентов, определенная согласно диаграмме взаимоотношений процесса.
Обоснование: Субъективная, но истинная оценка результатов рабо- ты процесса.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: <3
Целевое значение: 4
Возможные значения: 0-5
Метрики компетентности,
осведомленности
и обучения (CAT)
Миссия: обеспечить достижение и поддержку намеченного уровня обу-
чения и осведомленности ИТ-персонала в соответствии с требованиями
IS020000.
Владелец процесса: управление уровнем сервиса
Задача метрики: добиться, чтобы все должности были заняты работника-
ми соответствующей квалификации.
Метрика: Число действий, запланированных, но не выполненных во время кампании по повышению осведомленности {действия)
Описание: Невыполненные действия.
Спецификация: Действия, назначенные на определенную дату и не выполненные на момент определения значения по- казателя.
Обоснование: Обеспечивает контроль того, что кампания по повы- шению осведомленности проходит в соответствии с планом.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Действия должны формально документироваться.
Опасное значение: 10
268
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Целевое значение: 5
Возможные значения: 999999
Метрика: Число должностных инструкций, в которых не конкретизированы требования к компетент- юсти {должностные инструкции}
Описание: Должностные инструкции для ИТ-персонала, храня- щиеся в отделе кадров или в CMDB, можно связать с квалификациями модели SFIA (Skills Framework for the Information Age — квалификационная структура для века информатики). Метрика учитывает инструк- ции, для которых такие связи отсутствуют.
Спецификация: Требования к компетентности нужно брать из SFIA.
Обоснование: Согласно IS020000 сотрудники должны продемонст- рировать специфические навыки, необходимые для занятия тех или иных должностей.
Аудитория: Владелец процесса, руководство ИТ, владелец 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.
Ограничения: Метрик: i не учитывает сотрудников, чья квалифика- ция выше, чем необходимо для их работы, потому что они не компенсируют недостатка квалификации у других.
Опасное значение: 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
Возможные значения: 0-100
Задача метрики: добиться, чтобы работники имели соответствующую
подготовку.
Метрика: Процент сотрудников с уровнем компетентнос- ти, не удовлетворяющим минимальным требо- ваниям % сотру ников}
Описание: Информация из матрицы квалификации.
Спецификация: Метрика характеризует уровень подготовки, но мо- жет быть улучшена за счет найма новых сотрудни- ков, имеющих требуемую квалификацию.
Обоснование: Работники, не имеющие достаточной профессио- нальной подготовки для своей должности, представ- ляют угрозу для бизнеса.
272
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 5
Целевое значение: 10
Возможные значения: 0-100
Задача метрики: обеспечить необходимую подготовку персонала.
Метрика: Процент сотрудников, не выполнивших план индивидуального развития {% сотрудников}
Описание- Действия, предусмотренные планом развития, но не выполненные.
Спецификация: Чтобы такие действия можно было подсчитать, ин- формация о них должна храниться в CMDB.
Обоснование: Метрика помогает следить за тем, чтобы действия, обозначенные в планах развития, действительно вы- полнялись. Это положительно сказывается на на- строении персонала.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 15
Целевое значение: 10
Возможные значения: 999999
Задача метрики: поддержание в организации высокого уровня осведом-
ленности о проектах и дос пгж< ниях ИТ.
Метрика: Пре цент осведомленности в целом по организа- ции (% осведомленности}
Описание: Осведомленность, о которой можно судить по дан- ным опросов и отдельных ответов в рамках сценари- ев службы Service Desk.
Спецификация: Оценивается на основании результатов регулярных выборочных опросов и ответов на вопросы службы
R. Метрики компетентности, осведомленности и обучения (CAT)
273
Service Desk. Когда проходит кампания по повыше- нию осведомленности, можно задавать относящиеся к ней вопросы пользователям при закрытии заявок, а затем подсчитывать процент тех, кто имеет пред- ставление о ее сути. Используется для повышения эффективности кампаний.
Обоснование: IT-подразделение должн о поддерживать связь с орга- низацией, это обеспечивает эффективность взаимо- действия.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 70
Целевое значение: 80
Возможные значения: 0-100
Задача метрики: обеспечить поддержание приемлемого уровня компе-
тентности персонала.
Метрика: Процент текучести кадров в сфере ИТ {% персонала}
Описание: Сколько сотрудников над ходят в течение года.
Спецификация: Оценивается на основании данных отдела кадров или частоте смены учетных записей на сервере.
Обоснование: Высокий уровень текучести кадров свидетельствует о низком моральном духе в организации и о том, что компетентные сотрудники в ней плохо задержива- ются.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 10
Целевое значение: 5
Возможные значения: 999999
274
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Задача метрики: обеспечить приемлемый уровень профессионализма
новых сотрудников.
Метрика: Число требований к персоналу, которые не удалось удовлетворить {требования}
Описание: Оценивается по информации отдела кадров.
Спецификация: Новые работники, вне зависимости от их квалифика- ции, не знакомы с организацией. Даже если кадры остаются высококвалифицированными, их высокая текучесть означает низкий уровень компетентности в организации. Метрика оценивает сложность под- бора компетентного персонала. Требования могут оставаться невыполненными из-за того, что руко- водство не утвердило ставки, или потому, что не уда- лось найти подходящего кандидата. В любом случае, если в ИТ-подразделении не хватает определенного сотрудника, уровень компетентности в нем ниже, чем следует.
Обоснование: Постоянно высокое значение показателя говорит ли- бо о большой текучести кадров, либо о недостаточ- ном их наборе.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 7
Целевое значение: 4
Возможные значения: 999999
Метрики
для управления программами
и проектами
Миссия: выполнять проекты и программы в соответствии со стандартами,
используя PRINCE2 или иную аналогичную стандартную методику проек-
тирования.
Владелец процесса: проектное бюро.
Задача метрики: соблюдать стандарты реализации проектов и программ
Метрика: Число контрольных точек не достигнутых в срок {контрольные точки}
Описание: Определяется на основании документации проекта, имеющейся в хранилище документов — CMDB.
Спецификация: Число контрольных точек, пропущенных в текущем месяце.
Обоснование: Проверяется, насколько точно соблюдается политика управления проектами.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Работа с документами должна вестись в рамках по- литики хранения документации.
Опасное значение: 1
Целевое значение: 2
Возможные значения: 999999
276
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Метрика: Общее время задержки проекта в текущем месяце (время}
Описание: Определяется на основании документации проекта, имеющейся в CMDB / хранилище документов.
Спецификация: Насколько запаздывает проект — соответствует чис- лу дней с пропущенными контрольными точками в текущем месяце.
Обоснование: Необходимо обеспечить доступ к проектной инфор- мации, чтобы понять будущие требования к измене- ниям и доступности.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 5
Целевое значение: 2
Возможные значения: 999999
Метрика: Число спорных пунктов в проекте {пункты}
Описание: Спорные проблемные проекты.
Спецификация: Число новых проблемных пунктов, возникших в про- екте в текущем месяце. Рост их списка.
Обоснование: Во всяком проекте есть список проблемных пунктов, и этот проект должен быть управляемым. Метрика позволяет отслеживать развитие таких списков, кон- тролируя таким образом само их наличие.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Ограничения: Нет
Опасное значение: 5
Целевое значение: 2
Возможные значения: 999999
Метрика: Число спорных пунктов проекта, решенных в текущем месяце {пункты}
Описание: Проблемы, решенные за истекший период.
Спецификация: Сокращение списка спорных пунктов.
S. Метрики для управления программами и проектами
277
Обоснование: Показатель отражает решение проблем, и его высо- кое значение говорит об эффективном управлении проектом.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 2
Целевое значение: 5
Возможные значения: 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
Возможные значения: 0-100
Метрика: Число задач, сформулированных на совещании по планированию проекта, которые не были выполнены в срок {задачи}
Описание: Действия, согласованные на совещании по планиро- ванию проекта, которые остаются невыполненными после оговоренного срока завершения.
Спецификация: Действия с истекшей датой завершения и статусом, отличным от «выполнено».
Обоснование: На возникновение сложностей, а также на исчерпа- ние ресурсов проекта в первую очередь указывает то, что действия планируются, однако затем не выпол- няются вовремя. Метрика позволяет заметить этот предостерегающий признак на ранней стадии.
Аудитория: Владелец процесса, руководство ИТ-отдела, владе- лец процесса SLA, члены команды, владелец процес- са SIP.
Ограничения: Нет
Опасное значение: 10
Целевое значение: 5
Возможные значения: 999999
280
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ
Задача метрики: обеспечить эффективное выполнение процессов управ-
ления услугами.
Метрика: Степень удовлетворенности клиентов {удо вл етворенность}
Описание: Оценивается при проверке проекта, однако необхо- димо учесть также замечания по поводу проектов, полученные службой Service Desk.
Спецификация: Удовлетворенность клиентов всеми реализуемыми проектами и программами.
Обоснование: Проекты должны выполняться так, чтобы это удов- летворяло пользователей и клиентов.
Аудитория: Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владе- лец процесса SIP.
Ограничения: Нет
Опасное значение: <3
Целевое значение: 4
Возможные значения: 0-5
О библиотеке изданий
по управлению ИТ-услугами
Серия изданий, выходящих под общим названием ITSM Library, посвящены
передовому опыту управления ИТ и издаются по заказу голландского отде-
ления форума ITSMF — ITSMF Netherlands (ITSMF-NL).
Форум по ИТ сервис-менеджменту (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 СММ, a pocket guide (на английском языке)
• IT Service Management, een samenvatting (на голландском языке)
• IT Service Management from hell based on Not ITIL (на английском языке)
1 Настоящее издание.
Брукс Питер
МЕТРИКИ ДЛЯ УПРАВЛЕНИЯ
ИТ-УСЛУГАМИ
Технический редактор Н. Лисицына
Корректоры И. Боханова, В. Муратханов
Компьютерная верстка А. Абрамов
Художник обложки О. Белорус
Подписано в печать 10.10.2007. Формат 70x100 1/16.
Бумага офсетная № 1. Печать офсетная.
Объем 18,0 печ. л. Тираж 1100 экз. Заказ № 6744
Альпина Бизнес Букс
123060, Москва, а/я 28
Тел. (495) 980-5354
www.alpina.ru
e-mail: info@alpina.ru
Отпечатано в ОАО «ИПК «Ульяновский Дом печати»
432980, г. Ульяновск, ул. Гончарова, 14
Метрики
для управления
ИТ-услугами
Книга представляет собой общее руководство по проектиро-
ванию, созданию и использованию метрик и KPI (ключевых по-
казателей эффективно.-, в качестве механизма управления
ИТ-услугами. Опираясь на лучшую мировую практику, включая
ряд принципе?., сформулированных в ITIL и стандарте IS020000,
автор дает конкретные рекомендации по применению метрик
для оценки качества ycriyi и эффективности функционирования
процессов, образующи х деятельность ИТ-подразделений. Осо-
бое внимание в книге уделяете я анализу трудностей и проблем,
возникающих при разработке оптимального набора метрик
и KPI, и возможным путям их решения.
Книга предназначено; для менеджероЕ. управляющих подде-
ржкои и пр. доставление И Г услуг, влздельцев процессов, кон-
сультйнтов, руководите; др, делений и всех тех, кто
интересуется подходами и принцип тми измерения и оценки эф-
фективности работы ИТ в организации.
Перевод на русский язык одобрен ITSMF Россия.
ISBN 1?в-5-1ЫЧ-иЬЧ?-Ч
BRARY
АЛЬ ПИНА БИЗНЕС БУКС
Т-п “(он -*951960 5354
•тернст-магазин:
wwwMtlpina »u
телефоне 49515В; 077