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

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

Операционный стандарт — это документ, фиксирующий уровень предоставления определённой технической услуги в рамках ИТ-инфраструктуры в целом. Например, «Операционный стандарт. Сети и каналы передачи данных», «Операционный стандарт. СУБД», «Операционный стандарт. СХД» и другие. Эти стандарты описывают параметры услуги: доступность, технологические перерывы, время восстановления, поддержку, ограничения, ответственных лиц и т.д.

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

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

Принцип распределения ответственности между группами при обработке просроченного инцидента заключается в том, что степень ответственности каждой группы пропорциональна её доле в общем времени обработки инцидента. То есть, если группа потратила большую часть времени на обработку просроченного инцидента, её доля ответственности будет больше и метрика KPI покажет более низкое значение. Формула учитывает время ti, которое каждая группа затратила на работу с инцидентом, и общее время Ti обработки инцидента. Таким образом, ответственность за просрочку распределяется более справедливо, чем при традиционном подходе, где вся ответственность возлагается на последнюю группу.

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

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

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

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