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

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

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

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

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

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

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

Фиксация условий нагрузки важна, потому что требования к производительности не могут быть универсальными для всех сценариев использования. Например, время формирования отчета может зависеть от количества операций за день. Если при 1000 операциях это занимает 5 минут, то при 10 000 операциях может потребоваться значительно больше времени. Поэтому необходимо четко определить, при каких условиях выполняется требование к производительности, чтобы избежать недоразумений и обеспечить реалистичные ожидания.

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

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