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

Формула расчёта First Line Resolution (FLR): R/N, где R — количество обращений, решённых на первой линии поддержки, N — общее количество обращений, поступивших на первую линию за отчётный период. Формула расчёта First Contact Resolution (FCR): C/N, где C — количество обращений, решённых в ходе первичного контакта с пользователем, N — общее количество обращений, поступивших в заданную группу за отчётный период. Обе метрики измеряют долю успешно разрешённых обращений к общему количеству поступивших обращений, но с разными критериями успешного разрешения.

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

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

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

Управление доступностью считается уникальным процессом в ITIL потому, что оно не выделено как отдельный процесс в других известных стандартах управления ИТ, таких как ISO/IEC 20000, COBIT5, CMMI для сервисов или MOF. В этих стандартах управление доступностью либо совмещено с другими процессами (например, с управлением непрерывностью или мощностями), либо отсутствует. ITIL предлагает этот процесс самостоятельно, хотя его задачи частично пересекаются с функциями других процессов, что вызывает вопросы о его необходимости как отдельной процедуры.

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

ABAC не подходит для аудита, потому что в нём отсутствует явное понятие «права», как в RBAC. В ABAC доступ определяется динамически через набор условий на основе атрибутов, что делает невозможным однозначное определение привилегий пользователя без анализа всех текущих контекстных данных (время, место, свойства объекта). Это усложняет проверку и документирование прав, необходимые для аудита.

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

Для оценки выполнения целей процесса в ITIL должны использоваться метрики, которые: - Непосредственно указаны в формулировке цели (например, для цели "увеличить долю решённых инцидентов до 95%" метрикой будет процент своевременно устранённых инцидентов). - Соответствуют критерию измеримости: имеют количественную шкалу и метод расчёта. - Привязаны к временным рамкам (ежемесячные, ежеквартальные отчёты). - Учитывают как количественные показатели (проценты, время выполнения), так и качественные аспекты в операционных задачах. - Связаны с цепочкой ценности: показывают влияние на качество услуг или бизнес-результаты. При этом метрики для задач процесса могут быть статичными (так как задачи редко меняются), тогда как для целей они переопределяются при каждом пересмотре целей.