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

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

Модель зрелости канбан-системы (KMM) описывает уровни развития практик. Второй уровень включает явное отображение требований к процессу, введение WIP-лимитов и управление блокерами на регулярных встречах. Третий уровень предполагает количественную оценку потока и измерение ключевых метрик, таких как время выполнения задач. Что касается обработки возвратов, на втором уровне их обычно отображают явным возвратом задачи на предыдущий этап, тогда как на четвертом и пятом уровнях (еще более зрелых) предпочитают использовать комбинацию основной и дочерней задач для исправлений, что позволяет более точно анализировать причины возвратов и совершенствовать систему.

Компактность и однородность "размеров" элементов в бэклоге важны потому, что они позволяют команде обещать стабильность поставок. Если трудоемкость задач варьируется чрезмерно, например, от 10 минут до нескольких недель, становится практически невозможно прогнозировать скорость работы и планировать загрузку команды. Однородные по сложности элементы позволяют более точно оценивать их выполнение, упрощают балансировку потока работ и обеспечивают предсказуемость производительности команды. Это особенно важно для упреждающего управления загрузкой и соблюдения установленных work in progress лимитов.

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

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

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

Автор считает, что должен существовать промежуточный уровень между USM и eSCM-SP, потому что USM слишком простой, а eSCM-SP слишком сложный для практического применения. Автор видит потребность в подходе, который будет близок по сложности к eTOM, но с возможностью обобщения на различные виды услуг, а не только телекоммуникационные. Такой промежуточный уровень должен сохранить простоту понимания USM, иметь достаточную детализацию, чтобы быть практически полезным, и не быть перегруженным сложностью eSCM-SP, что сделало бы его малоприменимым для многих организаций.

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

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