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

В части 2 стандарта ISO 20000 на странице 20 содержится рекомендация: «Целевые показатели разрешения должны быть основаны на приоритете». Эта формулировка указывает, что сроки устранения проблем или инцидентов следует устанавливать с учетом их приоритета. При этом важно отметить, что это именно рекомендация, а не обязательное требование, так как находится во второй части стандарта.

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

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

Для построения отчетов по конфигурационным элементам с использованием данных из внешних систем можно использовать два подхода: 1) Перенос необходимых атрибутов из внешних систем в CMDB, что позволяет строить стандартные отчеты без дополнительных сложностей; 2) Создание консолидированных источников данных, которые объединяют информацию из CMDB и внешних систем, что позволяет формировать комплексные отчеты без дублирования данных в CMDB.

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

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

При разработке плана управления сервисными активами и конфигурациями необходимо учитывать следующие стандарты и политики: внутренние политике организации в области ИТ и управления сервисами, отраслевые стандарты такие как ISO/IEC 20000 (стандарт ИТ-услуг) и ISO/IEC 19770-1 (стандарт управления ИТ-активами и лицензированием), внутренние стандарты организации, затрагивающие аппаратное обеспечение и другие компоненты инфраструктуры. Также следует учитывать требования бизнес-направлений, договорные обязательства и другие внешние требования. Все эти элементы формируют основу для определения требований к структуре ответственности, возможностям отслеживания изменений и формированию аудиторского следа в рамках процесса SACM.

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

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