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

Рекомендуется проводить пост-имплементационный обзор (PIR) через 30-90 дней после завершения внедрения изменений. Этот период позволяет оценить краткосрочные и среднесрочные эффекты, включая стабилизацию процессов и реакцию пользователей. Для критических изменений может быть назначен дополнительный экспресс-обзор через 1-2 недели для оперативного выявления проблем.

Принцип "Упрощайте" (Keep it simple), описанный в ITIL Practitioner Guidance 2016 года, был расширен в ITIL 4 до формулировки "Простота и практичность" (Keep it simple and practical). Это изменение отражает важность не только простоты решения, но и его практической применимости. В ITIL 4 подчеркивается, что слишком сложные решения затрудняют внедрение и эксплуатацию, однако простота ради простоты тоже не имеет смысла, если решение не решает поставленные задачи. Таким образом, акцент смещен с простого упрощения на поиск оптимального баланса между простотой и практической пользой.

Основные различия между двумя подходами к управлении релизами: первый подход (в подразделении разработки) рассматривает управление релизами как отдельный процесс, который самостоятельно обрабатывает нестандартные изменения, отвечает за авторизацию изменений на CAB'е и имеет дело только с изменениями в приложениях; второй подход (в подразделении эксплуатации) рассматривает управление релизами как часть процесса управления изменениями, который объединяет несколько изменений в релиз, но не отвечает за авторизацию изменений (это делает управление изменениями), и применяется как к приложениям, так и к инфраструктуре. Первый подход соответствует модели BMC SMPM, второй - ITIL и IBM Tivoli Unified Process.

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

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

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

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

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

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