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

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

Touch Time — это сумма всех периодов времени, когда над задачей активно ведется работа, без учета времени ожидания, консультаций, перерывов и других отвлекающих факторов. Измерить его сложно, потому что в реальных условиях сотрудники редко работают над задачей без переключений: они могут участвовать в коммуникациях, оперативках, решать спонтанные проблемы, брать перерывы и т.д. Большинство систем не фиксируют точное время работы над задачей (например, по таймеру), а потому Touch Time обычно оценивается через анализ статусов задач в инструментах управления проектами, что приводит к грубым приближениям и неточностям в расчетах.

Бизнес-роль — это набор системных ролей из разных ИТ-систем, объединённых общей функцией в рамках бизнес-процесса или подразделения. Например, бизнес-роль 'Финансовый аналитик' может включать системные роли 'Пользователь модуля отчётности' (в ERP-системе) и 'Аналитик данных' (в BI-инструменте). Бизнес-роли отражают реальные задачи сотрудников, в то время как системные роли — технические права в рамках отдельных приложений. При масштабировании ролевой модели от уровня приложения до всего предприятия роль администратора управляет бизнес-ролями, которые автоматически распространяют доступ через связанные системные роли.

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

Основные причины, по которым не рекомендуется использовать автоматическую функциональную эскалацию: 1) Она возможна только в системах с фиксированными маршрутами эскалации, которые встречаются нечасто; 2) Специалист текущей линии (например, L2) может продолжать работать с заявкой после автоматической передачи на следующий уровень (L3), что приведет к параллельной работе двух разных уровней поддержки без взаимодействия; 3) Неясно, как информация о переводе заявки доходит до специалиста предыдущего уровня и как это влияет на его мотивацию решать проблемы без эскалации; 4) При массовых обращениях в случае major-инцидентов автоматическое перемещение заявок может нарушить стандартные процессы обработки, так как при закрытии такого инцидента заявки обычно разрешаются массово, но при этом они могут быть автоматически переданы выше по маршруту.

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

Чтобы определить нормальность количества инцидентов, необходимо рассчитать Incident Rate для вашей компании и сравнить её со стандартным диапазоном 0.3–2.0 (оптимальный диапазон — 0.8–1.2). При этом важно учитывать отраслевые особенности: например, в банковской сфере ожидается более высокий показатель. Если результат значительно выходит за рамки указанных диапазонов, это может сигнализировать о проблемах в качестве ИТ-услуг или управления инцидентами.

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

Автоматизация рутинных операций положительно влияет на соотношение инцидентов и запросов на обслуживание, так как позволяет перевести многие типовые запросы в полностью автоматизированный режим или самобранчинг (self-service). Это сокращает общий объем обращений в сервис-деск и, в частности, объем запросов на обслуживание, обрабатываемых вручную, позволяя команде сосредоточиться на более сложных задачах, включая работу по предотвращению инцидентов. В результате автоматизация не только улучшает удовлетворенность пользователей за счет более быстрого выполнения стандартных операций, но и позволяет повысить стабильность систем за счет высвобождения ресурсов для проактивной работы по снижению количества инцидентов.