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

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

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

Нет, не существует универсального стандарта, который бы полностью покрывал все вопросы управления информационными технологиями. Согласно материалу от Гартнера, в этой области отсутствуют 'серебряные пули' (there is no silver bullet for standards), что означает необходимость комбинирования нескольких подходов для полного охвата потребностей организации.

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

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

Для базовой веб-навигации и работы с почтой скорость в 10 кбит/с считается крайне низкой, так как даже простые сайты и электронная почта требуют минимум 50-100 кбит/с. Для стриминга видео, онлайн-игр и других ресурсоемких задач необходима скорость от 10 Мбит/с и выше. Нынешние стандарты подключения редко опускаются ниже 1 Мбит/с даже в условиях ограниченного тарифа.

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

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

В ITIL 4 Specialist: Drive Stakeholder Value описываются три типа сервисных отношений, каждый из которых имеет свои характеристики. Один из важных аспектов — это партнерство, при котором контракты могут быть основаны на результатах или вовсе не заключаться. Основной критерий для партнерских отношений — высокий уровень доверия между поставщиком и заказчиком. Это позволяет сосредоточиться на человеческом взаимодействии и поддержании успешных отношений, а не только на формальных соглашениях.