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

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

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

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

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

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

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

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

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

Принцип "Действуйте итерационно" (Progress iteratively), описанный в ITIL Practitioner Guidance 2016 года, был дополнен в ITIL 4 2019 года до формулировки "Действуйте итерационно, используя обратную связь" (Progress iteratively with feedback). Это изменение подчеркивает важность не просто итерационного подхода к работе, но и обязательного сбора и учета обратной связи на каждой итерации. Авторы ITIL 4 таким образом делают акцент на том, что обратная связь является ключевым элементом успешных итераций, позволяющим корректировать дальнейшие шаги и улучшать результаты.