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

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

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

Диагностика продуктовой команды позволяет создать беспристрастную оценку реального положения дел в команде, выявляя как технические навыки, так и коммуникационные аспекты. Сторонние эксперты могут оценить реальный уровень компетенций членов команды с разных точек зрения (360-градусная оценка), что помогает обнаружить случаи, когда специалисты переоценивают свои способности из-за эффекта Даннинга-Крюгера. В тексте подчеркивается, что диагностика рассматривает артефакты работы, рабочие процессы и коммуникации внутри команды и с бизнесом, формируя объективную картину, которую затем можно обсудить с командой. Это помогает определить, какие аспекты требуют корректировки, и разработать план действий для улучшения сотрудничества и работы команды.

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

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

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

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

Главное различие между запросом и потребностью заключается в том, что потребность - это то, что на самом деле нужно заказчику/потребителю, возможно даже неосознанное самим заказчиком. Например, бизнес может не видеть неэффективность в каких-то участках процесса или не представлять альтернативные решения. Запрос же - это конкретное выражение потребности после её осознания. То есть запрос возникает у заказчика в связи с осознанием потребности. Например, в истории с мылом постоялец хотел использовать своё мыло и попросил не класть отельное, тогда как его потребностью было комфортное проживание без лишних предметов в ванной. Бизнес-аналитик или ИТ-специалист должен уметь выявлять истинные потребности, а не просто слепо выполнять полученные запросы.

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