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

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

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

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

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

Практические упражнения для распознавания Action Bias включают в себя анализ реальных кейсов и ситуаций, таких как рассмотренное в тексте упражнение «Найдите среди предлагаемых утверждений ложные, обоснуйте своё мнение». Полезно регулярно проводить рефлексию принятых решений, задавая вопросы: было ли это действие действительно необходимо? Что бы произошло, если бы мы этого не сделали? Также можно внедрить практику «остановки перед действием» - обязательную паузу перед запуском новых задач для обоснования их необходимости. Деловые игры и симуляции процессов, такие как «Проект Феникс - DevOps на практике», позволяют в безопасной обстановке увидеть, как скрытые убеждения влияют на принятие решений. Важно создавать среду, где вопросы о целесообразности действий поощряются, а не рассматриваются как проявление нерешительности.

При расчете Flow Efficiency возникает вопрос, какое рабочее время учитывать. Если команда состоит из сотрудников с разными графиками работы (например, аналитики в Новосибирске, разработчики в Москве, тестировщик на неполную ставку), возникает сложность выбора календаря. Можно было бы использовать календарь отдельного сотрудника, но в случае совместной работы над задачей это не отражает реальную ситуацию. В результате многие команды прибегают к упрощенным оценкам или договоренностям, которые дают неточные результаты, а не строгий расчет. Это приводит к ситуации, когда формально рассчитанная Flow Efficiency может отличаться от реальной эффективности в несколько раз.

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

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

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