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

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

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

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

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

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

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

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

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

Стандарт INCITS 494-2012 добавляет к базовому набору RBAC команды, необходимые для работы с расширенным функционалом, в частности, для обработки динамических ограничений. Примеры таких команд включают 'GetRule', 'ParseRule', 'GetValue' и другие, которые предназначены для взаимодействия с внешними политиками и правилами. Эти команды позволяют системе получать правила от внешних источников, обрабатывать (парсить) их и извлекать значения для применения динамических ограничений. Они дополняют базовые команды административного, системного и контрольного типов, обеспечивая расширенный функционал, который позволяет RBAC учитывать внешние факторы при принятии решений о предоставлении доступа.