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

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

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

Группа 'б' включает проблемы, закрытые без решения и приведшие к непродуктивной трате ресурсов, то есть с явным вредом от напрасной работы. Группа 'в' – проблемы, закрытые без решения, но без вреда и пользы (например, дубли, закрытые на этапе первичной оценки). Группа 'б' влияет на снижение метрики, так как учитывается в знаменателе, тогда как группа 'в' исключается из расчета полностью.

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

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

Терминология ITIL меняется от версии к версии, потому что подходы к управлению ИТ-услугами эволюционируют в соответствии с изменениями в бизнес-среде и технологиях. ITIL4 делает акцент на гибкости, ко-создании ценности и интеграции с современными методологиями (такими как Agile и DevOps), что требует более гибкой терминологии. Жесткое разделение, существовавшее в ITIL V3, заменяется концепцией видимости ресурсов в зависимости от контекста, что лучше отражает сложность современных сервисных экосистем.

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

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

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