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

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

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

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

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

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

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

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

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

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