Согласованный 'внеплановый' простой отличается от реального аварийного простоя тем, что он заранее запланирован, согласован со всеми заинтересованными сторонами и документирован, даже если и выходит за рамки обычного календаря плановых работ. Он имеет чёткие временные рамки, процедуры восстановления и оценку рисков. В отличие от него, аварийный простой возникает внезапно, без предварительного планирования, негативно влияет на бизнес-процессы и требует срочного реагирования через процессы управления инцидентами. Различие критично для правильной отчётности и анализа причин проблем, так как согласованные простои являются управляемыми элементами процесса, в то время как аварийные простоя сигнализируют о реальных проблемах с надёжностью систем.

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

Наличие документа об архитектурных и технологических стандартах является признаком зрелости ИТ-управления компании потому, что такие документы создаются у единичных, обычно крупных и наиболее зрелых в вопросах регламентирования деятельности компаний. Реализация единой архитектурной политики требует высокого уровня организации ИТ-процессов, понимания долгосрочных целей развития инфраструктуры и наличия компетенций в области ИТ-архитектуры. Такой документ определяет допустимые языки и среды разработки, используемые платформы и СУБД, механизмы развёртывания и настройки локаторов прикладных серверов и middleware, требования к интерфейсам, резервированию, мониторингу и журналированию. Наличие чётко прописанной технологической и архитектурной политики свидетельствует о том, что компания стремится к стандартизации и унификации своих ИТ-решений, что снижает операционные риски и затраты на сопровождение, повышает качество и безопасность разрабатываемых и эксплуатируемых систем.

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

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

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

Роль координатора изменений, хотя и не упомянута в официальной документации ITIL, широко используется в большинстве распространенных вендорских процессных моделях. Например, она присутствует в моделях компаний BMC, HP и IBM. В IBM Tivoli Unified Process эта роль называется 'Владелец изменений', что может вызывать терминологическую путаницу из-за многозначного использования слова 'Owner' в ИТ-управлении. Несмотря на отсутствие официального признания этой роли в ITIL, на практике внедрение управления изменениями в крупных компаниях практически всегда включает назначение координаторов изменений

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

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

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