Для расчета интегрального показателя одной услуги с множеством KPI рекомендуется сначала разделить все показатели на смысловые группы, например: производительность, доступность и поддержка. Для каждой группы рассчитывают индивидуальный интегральный показатель, возможно, используя разные методы агрегирования в зависимости от природы показателей. Например, для показателей доступности, где критично важно поддерживать высокий уровень по всем метрикам, может применяться среднее геометрическое, а для показателей поддержки — среднее арифметическое. После этого полученные групповые показатели объединяют в общий интегральный показатель услуги, используя подходящий метод агрегирования, например, взвешенное среднее.

В расширенном RBAC (стандарт INCITS 494-2012) атрибуты используются для создания динамических ограничений на основе внешних факторов. Атрибутами могут быть: определенный период времени в сутках, местоположение пользователя, цель использования системы, класс пользователя, значение определенного типа данных и тип учетной записи. Например, можно создать правило, которое запрещает доступ к финансовым операциям вне рабочего времени или ограничивает использование определенных ролей только в офисе компании. Атрибуты позволяют сделать систему управления доступом более гибкой и адаптированной к изменяющимся условиям, добавляя контекстную зависимость к правилам доступа, что преодолевает недостатки 'чистого' RBAC.

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

В организации с глубокой иерархией подход к использованию метрик для оценки руководителей адаптируется через многоуровневую систему агрегации метрик. На нижних уровнях оценка строится на основе оперативных процессных метрик сотрудников. Затем эти метрики агрегируются на следующем уровне управления для оценки руководителей среднего звена. Процесс продолжается до самого верха иерархии, где руководитель высшего звена оценивается по агрегированным метрикам своих подчиненных руководителей. Ключевым требованием является приведение всех метрик к сопоставимому формату (шкала от 0 до 1), чтобы обеспечить корректную агрегацию. Например, если начальник отдела оценивается по метрикам К1-К4, то для начальника группы отделов могут агрегироваться рейтинги отдельных начальников отделов с использованием арифметического или взвешенного среднего. Такая структура позволяет сохранить прозрачность и связность системы оценки на всех уровнях иерархии.

Менеджер по взаимоотношениям с бизнесом (Business relationship manager) играет важную роль в процессе управления уровнем услуг, хотя в данной статье он не рассматривается подробно. Его основная задача - обеспечивать связь между бизнесом и ИТ, передавая требования бизнеса в понятном для ИТ виде. Он занимается трансляцией требований бизнеса, полученных от заказчиков, в понятные ИТ-задачи, которые затем передаются владельцу услуги и другим процессам ИТ. BRM участвует в формировании требований к уровням услуг, которые ложатся в основу SLA.

Структура фактора влияния COBIT 5 позволяет организовать систему измерений и оценки процесса управления изменениями через четыре ключевых аспекта: заинтересованные стороны, цели (с разделением на прямое и контекстуальное качество), хорошие практики и жизненный цикл. Для каждого аспекта можно определить соответствующие метрики: для прямого качества - своевременность изменений и удовлетворенность пользователей, для контекстуального - долю стандартных и экстренных изменений, для практик - полноту реализации ключевых практик COBIT, для жизненного цикла - полноту выполнения этапов PDCA. Такой системный подход помогает избежать несоответствия измерений и целей процесса, а также определить конкретные области для улучшения.

В традиционной системе KPI, где оценка основана только на соблюдении максимального времени Tmax, решение инцидента сразу перед истечением срока (например, за 3 часа 55 минут при Tmax = 4 часа) дает полный балл. Это создает обратную мотивацию — исполнители могут откладывать решение до последнего момента, не стремясь к оперативному восстановлению сервисов, что приводит к ненужным простоям и ущербу для бизнеса, хотя формально все нормативы соблюдены.

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

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

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