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

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

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

Воздействия на отдельные переменные недостаточно для решения проблем в системе ИТ из-за наличия усиливающих и балансирующих циклов обратной связи, в которых эти переменные участвуют. Простое изменение отдельного показателя может привести к временному улучшению, но со временем система через цепочку причинно-следственных связей вернется к нежелательному состоянию или ситуация может даже усугубиться. Реальное решение требует понимания структуры циклов, определения ключевых точек воздействия и разработки стратегии, которая влияет на весь цикл, а не только на отдельные элементы. Например, попытка просто ускорить Time to market без учета влияния на Change Risk и Service Quality приведет к повышению числа сбоев и проблем. Истинное решение заключается в «оздоровлении» негативных циклов (разрушении вредоносных петель) или запуске новых балансирующих циклов, которые будут поддерживать желаемое состояние системы продолжительное время.

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

Согласно исследованию Google Project Oxygen, восемь ключевых качеств хорошего менеджера включают: быть хорошим коучем; раздавать ответственность, избегая микроменеджмента; проявлять заинтересованность в успехах сотрудников, включая личные аспекты; быть нацеленным на результативность и достижение целей; обладать навыками эффективной коммуникации; помогать в карьерном росте подчинённых; иметь чёткое видение и стратегию для команды; обладать важными техническими компетенциями, позволяющими поддерживать команду. Эти качества были сформулированы после многократных опросов, анализа данных по методу «360 градусов» и интервью с уходящими сотрудниками, что позволило определить, какие характеристики наиболее существенно влияют на результативность работы подчинённых.

Архитектурные решения критически важны, потому что сложные, монолитные системы, созданные годами и состоящие из тесно связанных компонентов, просто не могут поддерживать высокую скорость разработки. Такие системы, где аббревиатура 'CI/CD' вызывает удивление или смех, принципиально не позволяют достигнуть кратного ускорения. Чтобы достичь значительного снижения Time to Market, необходимо провести работу над архитектурой: разбить монолит на микросервисы или модули, внедрить автоматизацию тестирования и развертывания, создать условия для параллельной работы нескольких команд без постоянных конфликтов. Эти изменения требуют значительных усилий и инвестиций, но без них реальное кратное ускорение невозможно.

Другие стандарты подходят к управлению доступностью иначе, чем ITIL. Например, ISO/IEC 20000 объединяет управление доступностью с управлением непрерывностью, COBIT5 и CMMI для сервисов связывают его с управлением мощностями, MOF включает его в функцию надежности вместе с управлением непрерывностью, мощностями и безопасностью. Авторы ISM Method относят управление доступностью к управлению качеством (Quality Management), наряду с другими аспектами, такими как безопасность и непрерывность. Это свидетельствует о том, что в других стандартах управление доступностью не выделено отдельно как самодостаточный процесс.

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

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