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

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

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

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

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

Подход к обучению в игре Grab@Pizza отличается от традиционных методов своей интерактивностью и вовлечённостью участников. В отличие от лекций или теоретического обучения, игра создаёт имитацию реальных рабочих ситуаций, в которых участники активно взаимодействуют между собой, принимают решения и видят их последствия в режиме реального времени. Такой метод обучения позволяет быстрее усваивать материал, лучше запоминать ключевые моменты и применять полученные знания на практике. Также игра создаёт условия неопределённости, похожие на реальный бизнес, что помогает развивать навыки принятия решений в стрессовых ситуациях.

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

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

В рекомендациях ITIL 4 к применению принципа "Отталкивайтесь от текущей ситуации" (Start where you are) указано, что при оценке текущей ситуации следует использовать непосредственные наблюдения, и этим наблюдениям следует отдавать предпочтение перед другими методами сбора информации. В частности, в разделе 4.3.2.2 ITIL 4 прямо указано, что "прямое наблюдение всегда должно быть предпочтительным вариантом" ("direct observation should always be the preferred option"). Это подтверждает важность элемента, который ранее был выделен как отдельный принцип "Приоритет прямого наблюдения" (Observe directly) в ITIL Practitioner Guidance 2016 года, но в ITIL 4 интегрирован в рекомендации по применению другого принципа.

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