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

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

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

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

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

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

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

Предельные способы агрегирования, такие как среднее арифметическое и произведение, работают неэффективно при большом количестве KPI, потому что при увеличении числа показателей в случае среднего арифметического интегральный показатель стремится к 1 (100%), а при использовании произведения – стремится к 0. Это приводит к тому, что отдельные показатели теряют значимость и не вносят существенного различия в общую оценку.

Риски, связанные с неправильной оценкой потенциала агента изменений при найме, включают: непродуктивную работу в случае, если сотрудник не может справляться с масштабами и сложностью изменений ("Падшая звезда"); потерю ценного сотрудника, если его потенциал выше, чем заложено в его позицию ("Заряженная пружина"); и неоптимальное использование ресурсов компании, когда траектории развития компании и агента не совпадают. Это может привести к дополнительным затратам на замену сотрудника, замедлению темпов изменений и снижению морального климата в команде.

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