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

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

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

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

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

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

ITIL предоставляет структурированный подход к управлению стоимостью сервисов через Financial Management for IT, который описывает методы расчета стоимости ресурсов и услуг с учетом как прямых, так и косвенных затрат. Это обеспечивает точное распределение затрат между потребителями услуг, позволяет анализировать стоимость-эффективность различных сервисов и формировать обоснованные цены или внутренние ставки для учета ресурсов, что ведет к более прозрачному и экономически рациональному управлению ИТ-услугами.

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

В ITIL 4 роль менеджера уровня услуг не упоминается в руководстве по одноименной практике, потому что картина с ролями в новой версии ITIL была значительно упрощена. В отличие от ITILv3, где эта роль была более четко определена, в ITIL 4 акцент сместился на упрощение и практическую применимость, что соответствует общему направлению развития фреймворка. Это решение помогает избежать избыточного усложнения системы управления и бесплодных споров о распределении задач между различными ролями, что согласуется с применением принципа 'Keep it simple and practical'.

Если руководитель обнаруживает в RACI-матрице, что он является ответственным за выполнение задачи (A - Accountable), но механизмы контроля не определены, следует предпринять следующие шаги: 1. Сформулировать, какие конкретно инструменты контроля необходимы для данного вида деятельности (системы отчетности, регулярные проверки, программные инструменты мониторинга и т.д.). 2. Определить, кто сможет обеспечить эти механизмы (внутренние специалисты или внешние консультанты). 3. Обсудить необходимость создания указанных механизмов контроля до окончательного утверждения RACI-матрицы. 4. Зафиксировать в матрице или дополнительных документах перечень и порядок работы этих механизмов контроля. Важно, чтобы система контроля была не только описана, но и реально внедрена, так как ответственность без возможности контроля становится бессмысленной - руководитель будет нести ответственность за результат, на который фактически не может повлиять.