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

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

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

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

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

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

Противоречие заключается в том, что процессы EDM01 и EDM05, которые должны описывать управление системой руководства ИТ, следуют той же структуре практик (оценка, направление, мониторинг), что и процессы руководства системы управления ИТ (например, EDM02–EDM04). При этом в COBIT 5 проводится чёткое разграничение между руководством и управлением. Если процессы EDM01 и EDM05 представляют собой процессы управления системой руководства, их структура должна быть ближе к управленческим циклам, например, PDCA (планирование-реализация-оценка-корректировка). А если это процессы руководства, тогда возникает вопрос о том, кем и в чьих интересах осуществляется руководство над системой руководства, что представляется избыточным.

Заинтересованные стороны играют ключевую роль в домене EDM COBIT 5. Процесс EDM05 напрямую связан с их потребностями, так как обеспечивает прозрачность и информирование заинтересованных сторон. Кроме того, все процессы домена EDM ориентированы на удовлетворение ожиданий и требований заинтересованных лиц. Например, процессы EDM02, EDM03 и EDM04 направлены на оптимизацию ценности, рисков и ресурсов именно с точки зрения интересов заинтересованных сторон. Таким образом, заинтересованные стороны выступают как основные получатели результатов деятельности системы руководства ИТ.

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

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