Специфические метрики для управления ИТ-услугами

ПОДРОБНЕЕ О КНИГЕ

Метрики для операционных процессов будут относиться к:

• управлению инцидентами;
• службе Service Desk;
• управлению конфигурациями;
• управлению изменениями;
• управлению релизами (в том числе приложениями);
• управлению операциями (в том числе инфраструктурой).

Метрики для тактических процессов будут относиться к:

• управлению уровнем обслуживания;
• управлению проблемами;
• управлению финансами для ИТ-услуг;
• управлению мощностями;
• управлению непрерывностью предоставления ИТ-услуг;
• управлению доступностью;
• управлению информационной безопасностью.

Метрики для стратегических процессов управления услугами будут относиться к:

• оценке перспектив развития бизнеса;
• программе постоянного улучшения качества обслуживания (Service Improvement Programme — SIP);
• управлению рисками;
• управлению документацией;
• компетентности, осведомленности, обучению (Competence, Awareness and Training — CAT).

В заключительном подразделе перечислены метрики для управления программами и проектами.

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

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

Каждой задаче соответствуют одна или более метрик, а каждой метрике — ровно одна метрическая задача (та задача процесса, выполнение которой оценивается с помощью данной метрики). Метрики группируются по задачам.

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

Таблицы, в которых описываются метрики для управления ИТ-услугами, содержат следующие поля:

• Метрика — максимально простое описание метрики. Вслед за ним приводятся в фигурных скобках {} используемые единицы.
• Описание — краткая характеристика метрики в дополнение к названию.
• Спецификация — краткое разъяснение, что и как измеряется.
• Обоснование — объяснение, чем полезна данная метрика и каково ее значение.
• Аудитория — перечень тех, кому данная метрика предположительно будет предоставлять полезную информацию.
• Ограничения — любые обстоятельства, представляющие препятствие для применения или интерпретации метрики.
• Опасное значение — условие, при котором показатель отображается красным цветом (что сигнализирует о возможных проблемах в области, которая измеряется данным показателем).
• Цель — значение метрики, к которому предлагается стремиться.
• Возможные значения — перечень значений, которые может принимать метрика.

Последние три поля являются числовыми, что позволяет использовать метрику в информационной системе управления. Все значения, приводимые далее, придуманы для воображаемой организации и должны подгоняться под вашу ситуацию. Как именно задать пороговые величины, зависит от результатов бенчмаркинга, уровня допустимых отклонений, установленного владельцем процесса, и амбициозности поставленных задач. В настоящей книге поля «Опасность» и «Цель» заполнены просто для полноты и связности изложения.

В поле Опасность задается пороговая величина, которая сигнализирует владельцу процесса о проблеме, требующей изучения. Первоначально ее значение устанавливается по результатам бенчмаркинга — в данной книге цифры приводятся для иллюстрации с таким расчетом, чтобы графики в разделе 10.4.1 соотносились с метриками. В первой метрике «Степень удовлетворенности клиентов» порог должен включаться при уровне удовлетворенности меньше 3. Это означает, что положение намного хуже, чем определено целевым значением. Если такой механизм кажется вам запутанным, имеет смысл приравнять опасное значение к целевому и работать только с одной пороговой величиной.

Цель — это тот уровень, к которому договорились стремиться владелец и непосредственные исполнители процесса. Как уже упоминалось, согласование происходит после того, как бенчмаркинг выдаст достижимые показатели (до PIR — анализа результатов внедрения). Эталонные значения можно вывести из стандартов рынка (основанных на данные других похожих компаний) или из результатов, достигавшихся в прошлом. Опираясь на предполагаемый потенциал улучшения можно установить конкретное целевое значение.

Можно было бы также ввести поле Предупреждение со значением, скажем, 3,5, указывающим, что уровень близок к целевому, и эту точку установить в качестве порогового значения.

Возможные значения — это диапазон, в который попадает метрика. Для процентов он обычно указывается как 0-100, хотя некоторые показатели могут принимать значение более 100% и тогда это должно быть отмечено. Обозначение «не ограничено» соответствует диапазону, не имеющему каких-либо очевидных пределов.

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

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

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

Измерение процессов очень важно, без него невозможно понять, улучшается ли положение. Постепенному развитию метрик в направлении все более полного соответствия нуждам организации помогает непрерывная программа по улучшению услуг, о которой рассказывается в разделе 8.3.2. Одним из главных преимуществ внедрения процессов «как есть» является возможность сравнить опыт и даже контрольные данные с другими организациями, выбравшими тот же путь.

Стандарт ISO20000 и его национальные эквиваленты в ряде стран (например, SANS15000 в Южной Африке, AS8018 в Австралии), а также COBIT и Six Sigma поддерживают применение метрик, поэтому их внедрение в процессы управления услугами поможет быстрее достигнуть целей этих процессов.

8.1. Метрики для операционных процессов управления услугами

8.1.1. Управление инцидентами (А)

Метрики для управления инцидентами:

• Процент инцидентов, решенных на первой линии поддержки.
• Средняя продолжительность обработки инцидента до момента эскалации.
• Процент инцидентов, некорректно назначенных на сотрудников службы поддержки.
• Процент инцидентов, решенных в течение заданного времени согласно приоритету.
• Среднее время ответа второго уровня поддержки.
• Среднее время решения инцидента.
• Процент переназначенных инцидентов.
• Процент неправильно классифицированных инцидентов.
• Процент обращений, поступивших к специалистам службы поддержки «напрямую», минуя первый уровень.
• Степень удовлетворенности клиентов.
• Процент звонков, являющихся запросами на оказание услуг.
• Процент инцидентов, правильно решенных с первого раза.
• Процент инцидентов, решенных проактивно.

8.1.2. Служба Service Desk (B)

Метрики службы Service Desk:

• Число звонков на специалиста.
• Процент звонков, закрытых с первого раза (на одного специалиста).
• Число звонков «не по адресу».
• Число звонков, заявки по которым были эскалированы на второй уровень поддержки.
• Степень удовлетворенности клиента.
• Число звонков, заявки по которым были эскалированы на третий уровень поддержки.
• Среднее время ожидания ответа на звонок.
• Средняя продолжительность попытки дозвониться до клиента (на один звонок).
• Процент обращений через веб.
• Процент неправильно эскалировнных заявок.
• Процент звонков, которые были прерваны пользователями.
• Процент звонков, по которым были открыты заявки на устранение проблемы.
• Процент инцидентов, поступивших от процесса управления событиями.
• Процент звонков, правильно назначенных с первого раза.

8.1.3. Управление конфигурациями (С)

Метрики для управления конфигурациями:

• Число неиспользуемых лицензий.
• Число RFC, не выполненных из-за неверных данных в CMDB.
• Число неавторизованных конфигураций.
• Число инцидентов, связанных с невыполнением изменений из-за неправильно задокументированных CI.
• Число нарушений SLA, вызваных ошибками CMDB.
• Число RFC, по которым не было обновления CI.
• Процент некорректных CI.
• Степень удовлетворенности клиентов.

8.1.4. Управление изменениями (D)

Метрики для управления изменениями:

• Процент изменений, которые не удалось выполнить.
• Процент отклоненных RFC.
• Число неавторизованных изменений.
• Число невыполенных изменений.
• Простои во время изменений.
• Число неудачных изменений без плана возвращения в исходное состояние.
• Процент изменений, выполненных вовремя.
• Процент изменений, вызвавших инциденты.
• Число предложений Консультативного комитета по изменениям (Change Advisory Board — CAB), не реализованных вовремя.
• Степень удовлетворенности клиентов.
• Число экстренных изменений.
• Число изменений, не принесших ожидаемых результатов.

8.1.5. Управление релизами (E)

Отметим, что в управление релизами входит деятельность, описанная в публикации ITIL по управлению приложениями: основная масса релизов, с которыми мы сталкиваемся на практике, — это релизы приложений. Однако в конечном итоге они все-таки являются релизами и тем самым относятся к компетенции процесса управления релизами, как описано в ключевых публикациях ITIL.

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

Метрики для управления релизами включают:

• Число установленных программных пакетов, отсутствующих в DSL.
• Число срочных релизов.
• Число инцидентов, вызванных новым релизом.
• Процент своевременных релизов.
• Число непротестированных релизов.
• Средние трудозатраты на релиз.
• Число неиспользуемых лицензий на ПО.
• Процент точности оценки трудозатрат на релиз.
• Степень удовлетворенности клиентов.

Поддержка приложений (E.1)

Метрики для поддержки приложений:

• Число проанализированных программных ошибок.
• Число оптимизаций.
• Число приложений/ревизий, выпущенных в производство.
• Число учебных занятий для конечных пользователей.
• Число дефектов, обнаруженных по журналам регистрации.
• Число временных решений, протестированных и выпущенных в производство.
• Число временных решений, возвращенных для доработки.

Разработка приложений (E.2)

Метрики для разработки приложений:

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

8.1.6. Управление операциями/инфраструктурой ИКТ (F)

Управление операциями рассматривается в ITIL как составная часть управления инфраструктурой ИКТ, которое, в свою очередь, включает разработку и планирование, ввод в эксплуатацию, операции и техническую поддержку. Однако представляется более логичным приписать этапы разработки существующим процессам управления изменениями или релизами, и тогда управление операциями в чистом виде окажется частью управления ИТ-услугами. Но процесс по определению не может заниматься инфраструктурой — это следует из разграничения процесса, продуктов и функциональных обязанностей персонала. По данной причине мы вводим группу процессов, называемую «Управление операциями».

Рассматривая управление инфраструктурой ИКТ в рамках процесса управления операциями, мы используем традиционную классификацию, и это должно помочь читателям, недостаточно знакомым с ITIL. Метрики для управления инфраструктурой ИКТ:

• Число планов, одобренных компанией.
• Число планов, не готовых для одобрения.
• Отставание от плана внедрения.
• Число проблем, возникших при внедрении.
• Число серьезных или критических событий на один управляемый объект.
• Число событий, угрожающих информационной безопасности.
• Число сбоев при выполнении заданий/скриптов/резервного копирования.
• Число инцидентов, вызванных изменениями, которые возникли в результате выполнения операций.
• Степень удовлетворенности клиентов.

8.2. Метрики для тактических процессов управления услугами

8.2.1. Управление уровнем обслуживания (G)

Метрики для управления уровнем обслуживания:

• Число случаев нарушения SLA.
• Число случаев, когда SLA находится под угрозой нарушения.
• Процент SLA, требующих изменения.
• Число пересмотров SLA, произведенных своевременно.
• Число нарушений SLA по вине внешних подрядчиков, осуществляющих поддержку.
• Затраты на предоставление услуг.
• Число услуг, не охватываемых SLA.
• Число еще не согласованных операционных соглашений об уровне услуг (OLA) и внешних договоров (UC).
• Степень удовлетворенности клиентов.
• Время между выработкой требований по уровню обслуживания (SLR) и соглашением SLA.

8.2.2. Управление проблемами (H)

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

Метрики для управления проблемами:

• Число решенных проблем.
• Число инцидентов, разрешенных при помощи базы данных, где описано решение аналогичных задач.
• Общее число инцидентов.
• Общее время неработоспособности пользователей.
• Число RFC, инициированных процессом управления проблемами.
• Среднее число открытых проблем.
• Среднее время закрытия проблемы.
• Процент инцидентов, которые не удалось связать с проблемой.
• Число проблем, не решенных в течение заданного времени.
• Степень удовлетворенности клиентов.
• 5 категорий инцидентов, по которым было больше всего обращений за отчетный период.
• Число инцидентов, разрешаемых путем обучения пользователей.
• Затраты на решение проблемы.

8.2.3. Управление финансами для ИТ-услуг (I)

Метрики для управления финансами:

• Процент учитываемых расходов на ИТ.
• Число изменений, сделанных в алгоритме начисления платы.
• Задержки в создании финансового отчета.
• Задержки в создании ежемесячного прогноза.
• Степень достоверности (в процентах) последнего финансового прогноза.
• Степень достоверности (в процентах) финансового прогноза на предыдущий квартал.
• Совокупная стоимость владения (Total Cost of Ownership — TCO) ИТ.
• Число жалоб, касающихся затрат на ИТ.
• Число вопросов, касающихся затрат на ИТ.
• Степень удовлетворенности клиента.

Для целей ISO20000 этого достаточно. Возможно, некоторые ИТ-подразделения пожелают пойти дальше и стать центрами получения прибыли¹.

8.2.4. Управление мощностями (J)

Метрики для управления мощностями:

• Число нарушений SLA из-за недостаточно быстрого обслуживания.
• Число нарушений SLA из-за недостаточной производительности компонента.
• Число инцидентов, вызванных недостаточной производительностью или мощностью.
• Стоимость разработки плана развития мощностей.
• Число незапланированных приобретений аппаратных средств, нужных для повышения производительности.
• Степень достоверности (в процентах) плана предстоящих расходов.
• Процент избыточной производительности ИТ.
• Процент CI, для которых ведется мониторинг производительности.
• Степень удовлетворенности клиентов.
• Соотношение (в процентах) между общей и ожидаемой загрузкой ИТ-ресурсов.

8.2.5. Управление непрерывностью предоставления ИТ-услуг (K)

Метрики для управления непрерывностью предоставления ИТ-услуг (IT Service Continuity — ITSC):

• Число услуг, не охватываемых планом ITSC.
• Задержка с подготовкой/обновлением плана ITSC.
• Задержка с тестированием плана ITSC.
• Число проблем, выявленных при последнем тестировании и еще не решенных.
• Результаты опроса по осведомленности о непрерывности предоставления ИТ-услуг проведенного выборочно — процент удовлетворительных ответов.
• Число выявленных за данный период проблем, которые ставят под угрозу план ITSC.
• Число писем, предназначенных для конкретной группы сотрудников.
• Число неверных записей в справочнике группы кризисного контроля.
• Запаздывание готовности резервных мощностей.
• Степень удовлетворенности клиентов.

8.2.6. Управление доступностью (L)

Многие метрики управления доступностью обязаны своим происхождением жизненному циклу инцидентов — ведь те самым непосредственным образом связаны с периодами полной или частичной недоступности. В ключевых публикациях ITIL терминология, относящаяся к жизненному циклу инцидентов, не вполне последовательна, и здесь мы представляем ее улучшенный вариант, позволивший обнаружить целый ряд метрик. В частности, название метрики MTTR у нас расшифровывается не как Mean Time to Repair Downtime (среднее время ликвидации простоя), а как Mean Time to Restore (среднее время восстановления доступности).

Метрики для управления доступностью:

• Время простоя, недоступности услуг.
• Время недоступности компонентов.
• Время обнаружения инцидента.
• Время реагирования на инцидент.
• Время восстановления при инциденте.
• Время восстановления после инцидента.
• Время возобновления обслуживания после инцидента.
• Время разрешения инцидента.
• MTBSI (Mean Time Between System Incidents — среднее время между системными инцидентами).
• MTTR (Mean Time to Repair Downtime — среднее время ликвидации простоя. Mean Time to Restore — среднее время восстановления доступности).
• Время простоя в критические периоды.
• Время недоступности услуг внешнего подрядчика.
• Время недоступности компонентов, принадлежащих внешнему подрядчику.
• Время возобновления недоступных услуг.
• Число повторных сбоев.

8.2.7. Управление информационной безопасностью (M)

Метрики для управления информационной безопасностью:

• Число инцидентов, связанных с информационной безопасностью.
• Число решенных проблем, связанных с информационной безопасностью.
• Число решенных проблем, выявленных в ходе аудита и внутренних проверок.
• Процент своевременно проведенных проверок и аудитов.
• Число выявленных рисков (предостережения и новые угрозы).
• Процент SLA, где явно оговорены вопросы информационной безопасности.
• Процент внешних договоров, где явно оговорены вопросы информационной безопасности.
• Число выявленных проблем релиза, связанных с информационной безопасностью релиза (возвраты к исходному состоянию / вирусы и т. д.).
• Число изменений, которые были по соображениям информационной безопасности отменены (и система возвращена в исходное состояние).
• Скорость установки патчей, связанных с информационной безопасностью.

8.3. Метрики для стратегических процессов управления услугами

8.3.1. Метрики для бизнес-планирования (N)

• приведение ИТ-услуг в соответствие с потребностями бизнеса и его клиентов;
• улучшение качества этих ИТ-услуг;
• сокращение расходов на оказание этих услуг.

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

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

К бизнес-планированию относятся четыре процесса:

1) управление взаимоотношениями с бизнесом; 2) управление взаимоотношениями с поставщиками; 3) планирование, анализ и развитие; 4) взаимодействие, обучение и информирование.

Следующие три метрики предназначены для оценки бизнес-планирования в целом:

• Средние затраты на предоставление одной услуги.
• Степень удовлетворенности клиента.
• Знание бизнеса сотрудниками ИТ-подразделения.

Еще 13 метрик относятся к определенным бизнес-процессам, таким образом, общее число метрик для бизнес-планирвоания — 16.

Управление взаимоотношениями с бизнесом (N.1):

• Число жалоб на обслуживание.
• Число невыполненных действий с момента последней проверки данного сервиса.

Управление взаимоотношениями с поставщиками (N.2):

• Максимальное число инцидентов, связанных с одним поставщиком.
• Процент постоянных поставщиков, удовлетворяющих стандартам (например, ISO20000).
• Процент проверок качества услуг поставщиков на соответствие определенным требованиям, проведенных в срок.
• Число нерешенных проблем, относящихся к поставщикам.

Управление поставкой услуг (N.3):

• Минимальная оценка степени удовлетворенности клиентов.
• Число инцидентов.
• Степень удовлетворенности клиентов.

Планирование, анализ и развитие (N.4):

• Число проблем, выявленных при окончательной проверке плана.
• Число планов, одобренных для реализации.

Взаимодействие, обучение и информирование (N.5):

• Число действий, предусмотренных планом информирования, которые не были выполнены в срок.
• Процент ИТ-персонала с неоптимальным для занимаемой должности уровнем подготовки.

8.3.2. Постоянно действующая программа по улучшению услуг (O)

Постоянно действующая программа по улучшению услуг (Continuous Service Improvement Programme — SIP) охватывает все процессы ИТ-подразделения. Вообще в сложных системах нежелательно менять сразу многое: это часто приводит к негативным последствиям, и трудно определить, какое именно изменение отвечает за тот или иной результат.

По этой причине в SIP приоритетность изменений устанавливается в зависимости от эффективности изменяемого процесса и его значимости для бизнеса.

В разделе 4.4 стандарта ISO20000-1:2002 рассматриваются действия, необходимые на стадии постоянного улучшения (соответствующей последнему элементу в стандартном цикле Деминга Plan — Do — Check — Act — «Планирование — Выполнение — Проверка — Действие»). Результаты метрик, описанных в настоящей книге, позволят выявить процессы, наиболее нуждающиеся в улучшении. Влияние этих процессов можно будет обсудить с представителями бизнес-подразделений и оценить по степени соответствия SLA, а на основе полученных результатов разработать план для следующего цикла. Согласно рекомендациям ISO20000 такой план выполняется и оценивается как проект. По завершении проекта эффективность плана может быть измерена с помощью тех самых метрик и SLA, которые показали наличие недостатков. Проверка плана, таким образом, обеспечивает структуру улучшений для следующей программы SIP.

Как видим, SIP точно так же подчиняется циклу Деминга, как и реализация других процессов. Следовательно, можно рассматривать саму программу по улучшению как процесс и составить для нее перечень метрик, который позволит ее контролировать и отслеживать реальный прогресс. Владельцам процессов важно проводить их модификацию в рамках процесса управления изменениями, чтобы обеспечить ее отражение в метриках SIP наряду с формальными элементами программы. Метрики для SIP:

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

8.3.3. Управление рисками (P)

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

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

Все эти риски исследуются лишь постольку, поскольку соответствующие метрики показывают успешность функционирования процессов. В рамках бизнес-планирования управление рисками и оценка риска выполняемых операций должны быть привязаны к требованиям бизнеса.

Метрики для управления рисками:

• Процент CI, охватываемых анализом воздействий на бизнес (Business Impact Analysis — BIA).
• Процент документов BIA, не проверенных в течение требуемого времени.
• Процент процессов, подлежащих оценке со стороны операционного риска (Operational Risk Assessment — ORA).
• Число инцидентов в связи с рисками, не учтенными в рамках ORA.
• Процент инцидентов, частота которых превышает предсказанную при ORA.
• Процент CI, длительность простоя которых превышает предсказанную при ORA.
• Число действий, направленных на сокращение риска.
• Число вновь выявленных рисков.
• Процент CI, не включенных в план по непрерывности предоставления услуг.
• Число совещаний с поставщиками и владельцами внутрикорпоративных процессов.

8.3.4. Управление документацией (Q)

Метрики для управления документацией:

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

8.3.5. Компетентность, осведомленность и обучение (R)

Метрики компетентности, осведомленности и обучения (Competence, Awareness and Training — CAT):

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

8.4. Метрики для управления программами и проектами (S)

Метрики для управления программами и проектами:

• Число не достигнутых в срок контрольных точек.
• Общее время задержки проекта в текущем месяце.
• Число полученных результатов проекта.
• Число достигнутых результатов проекта в текущем месяце.
• Число выявленных рисков.
• Задержка критического пути².
• Число эскалаций.
• Число несостоявшихся совещаний по проекту.
• Предполагаемая вероятность завершения проекта к намеченному сроку в рамках бюджета.
• Степень удовлетворенности клиентов.
• Число задач, сформулированных на совещании по планированию проекта, которые не были выполнены.

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

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