Многие компании редко используют полноценное управление проблемами, так как ограничиваются решением оперативных технических сбоев, не выходя на уровень выявления и устранения корневых причин. Кроме того, управление организационными аспектами требует больших усилий и более глубокого понимания бизнес-процессов, что делает его сложнее для внедрения. Часто компании сосредоточены на краткосрочных результатах, тогда как системная работа над проблемами предполагает долгосрочное планирование и постоянное совершенствование процессов.

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

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

Термин OLA может быть избыточным, потому что содержательно OLA не отличается от SLA, а является всего лишь SLA с другой стороны. Если рассматривать цепочку создания ценности, то то, что для одного участника выглядит как OLA, для другого будет SLA. Примеры из ITIL Service Design показывают, что предлагаемые SLA и OLA очень похожи. Поэтому OLA как отдельная концепция не добавляет ценности и может только запутать при реализации, так как теряет четкое определение и аргументированное обоснование, что и приводит к путанице в практическом применении.

Точки взаимодействия — это конкретные моменты, когда клиент контактирует с компанией: сайт, соцсети, телефонные звонки, точки продаж и т.д. Чтобы спроектировать их эффективно, необходимо: 1) понять, какая ценность предоставляется в каждой точке, 2) обеспечить их согласованность между собой для плавного перехода клиента к следующему этапу, 3) учитывать, что даже небольшие изменения контекста могут кардинально повлиять на восприятие. Точки должны быть не просто функциональными, но и мотивирующими клиента двигаться дальше по его путешествию. Если ценность точки неочевидна, это сигнал к её переработке.

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

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

Активно расширяющиеся компании выделяют на 'развитие и управление ИТ' лишь 1-2% от общего размера ИТ-бюджета, что значительно меньше, чем компании, придерживающиеся стратегии выживания (которые выделяют 4-8%).

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

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