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

Управление конфигурациями требует учета связей между элементами инфраструктуры (CI) и услугами, а также между самими услугами. Это критически важно для корректного понимания влияния изменений в инфраструктуре на конечные услуги и для обеспечения целостности сервисов при проведении изменений.

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

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

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

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

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

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

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

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