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

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

Финальный уровень Definition of Done в DevOps определяется как состояние, когда код работает в продуктивной среде, и при этом вся сборка, тестирование и развертывание выполнены автоматическими средствами. Это важно потому, что автоматизация всех этапов процесса минимизирует человеческий фактор, повышает скорость и надежность доставки изменений, обеспечивает воспроизводимость результатов и позволяет командам регулярно и безопасно вносить изменения в рабочую систему. Такой подход гарантирует, что процесс разработки и эксплуатации является прозрачным, предсказуемым и соответствует лучшим практикам.

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

Предложенные показатели (суммарное время простоев, максимальный разовый простой, количество нарушений) имеют несколько преимуществ перед классическим подходом. Они позволяют: 1) Более точно оценить влияние доступности ИТ-услуг на конкретные бизнес-процессы; 2) Учесть специфику разных видов бизнеса - для некоторых критичны долгие простои, для других частые кратковременные; 3) Принимать обоснованные решения по повышению надежности систем с учетом реального бизнес-влияния; 4) Создать более прозрачные SLA с учетом особенностей воздействия простоев на бизнес; 5) Лучше оценить успешность мероприятий по повышению надежности на основе их реального влияния на бизнес-процессы.

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

Понятие 'экономически обоснованный уровень услуги' непосредственно связано с принципами сервисной экономики, поскольку оно предполагает установление уровня качества и объема ИТ-услуг, который экономически рационален для предоставления при существующих условиях. Этот уровень должен балансировать между потребностями бизнеса в качественной ИТ-поддержке и экономическими возможностями компании. Определение такого уровня требует проведения детального анализа затрат, понимания ценности услуг для бизнес-процессов, а также оценки последствий предоставления услуг на различных уровнях качества. Результатом должно быть обоснование как минимально необходимого уровня сервиса, так и дополнительных опций, которые могут быть предоставлены за дополнительную плату, что особенно важно при внутреннем ценообразовании между подразделениями компании.

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

Термин 'менеджер услуг' (service manager) в ITIL представляет собой общий термин для обозначения любого руководителя в организации поставщика услуг. В словаре ITIL 2011 он описывается как руководитель, который может относиться к менеджерам по взаимоотношениям с бизнесом, менеджерам процессов или к высшему руководству, отвечающему за ИТ-услуги в целом. При переходе на ITILv3 этот термин формально сохранялся, но фактически не использовался из-за слишком обширного смыслового наполнения. В ITIL 4 упоминание сущности 'менеджер услуг' полностью исчезло.

Да, канбан можно использовать для визуализации всего потока создания ценности, однако это не его основная функция. Разные инструменты имеют свои сильные стороны: канбан лучше подходит для регулирования потока работ через ограничение WIP и поддержания стабильного ритма производства, тогда как карта потока создания ценности (VSM) предназначена преимущественно для анализа и выявления потерь во времени. В реальной практике часто комбинируют оба подхода — используют VSM для оптимизации процесса и выявления точек улучшения, а затем внедряют канбан для поддержания улучшённого процесса в стабильном состоянии.