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

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

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

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

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

В тексте описаны две основные конфликтующие цели ИТ: необходимость поддерживать развитие бизнеса и быстро проводить изменения (минимизировать Time to market), и необходимость предоставлять услуги высокого качества (стабильные, надежные, безопасные), что подразумевает обеспечение Service Quality. Эти цели конфликтуют, потому что чем быстрее проводятся изменения (меньше Time to market), тем выше риски с точки зрения качества услуг, а повышение уровня защиты продуктивной среды (увеличение Service Quality) приводит к увеличению времени на реализацию изменений (увеличению Time to market). Этот конфликт лежит в основе многих проблем в ИТ-организациях и часто приводит к так называемому Core Chronic Conflict (CCC) между разработкой и эксплуатацией.

Для лучшего понимания взаимодействия между ИТ и заказчиками полезны следующие подходы: визуализация потока создания ценности, прозрачное определение ролей и ответственности, применение методологий Lean и DevOps, четкое согласование SLA. Также важно, чтобы сотрудники компании понимали, как они вписываются в общую цепочку создания ценности и как их работа влияет на удовлетворение потребностей конечных заказчиков.

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

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

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