Гибридная модель (RBAC + ABAC) превосходит чистый RBAC гибкостью и точностью. RBAC ограничен статическими ролями, тогда как добавление ABAC позволяет учитывать контекст (время, местоположение, свойства объекта). Например, менеджер с ролью «Редактор заказов» может редактировать заказы только в своём филиале и при соблюдении лимита стоимости. Это снижает риски избыточных прав и повышает соответствие политикам безопасности.

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

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

Автор упоминает, что некоторые ИТ-специалисты воспринимают себя как "гуру и чуть ли не божества", чтобы подчеркнуть проблему излишней самоуверенности и ограниченности знаний у некоторых представителей ИТ-сферы. Он отмечает, что часто эти специалисты считают себя экспертами во всех вопросах только потому, что могут составлять простые программные конструкции из английских слов (for, while, if, loop), при этом их знание второго языка и технических аспектов обычно ограничено. Это создает барьеры в коммуникации с бизнесом и усугубляет проблему разобщенности между ИТ и бизнес-подразделениями.

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

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

Показатель CPI (Cost Performance Index) из методики EVM имеет несколько преимуществ по сравнению с показателем SPI. CPI эффективно оценивает соответствие проекта бюджету на всех этапах, включая завершённые проекты, поскольку он рассчитывается как отношение запланированной стоимости выполненных работ к фактическим затратам. В отличие от SPI, CPI не искажается к концу проекта и продолжает отражать финансовые отклонения, позволяя менеджерам объективно оценивать эффективность использования бюджета как в процессе выполнения, так и после завершения проекта.

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

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

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