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

Сервисное мышление состоит из следующих ключевых компонентов: 1) знаете ли вы своих заказчиков/пользователей, 2) понимаете ли вы их ожидания, 3) фокусируетесь ли вы на создании ценности для заказчика, 4) берете ли на себя ответственность (включая за бизнес-результаты), 5) проявляете ли эмпатию, 6) осознаёте ли вы культурный контекст и адаптируетесь к нему, 7) способствуете ли вы сотрудничеству, 8) соблюдаете ли этичные нормы поведения. Все эти компоненты вместе формируют целостный подход к предоставлению услуг.

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

Точное определение уровня зрелости процесса в COBIT невозможно, так как один процесс может демонстрировать признаки сразу нескольких уровней зрелости одновременно. Эта особенность схожа с принципом суперпозиции в квантовой физике, когда система может находиться в нескольких состояниях сразу. Поэтому однозначно определить, на каком уровне зрелости находится процесс, который проявляет черты уровней 2, 3 и 4, невозможно. Существующие методы расчета уровня зрелости, такие как использование весовых коэффициентов, остаются субъективными и зависят от подхода конкретного аудитора.

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

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

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

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

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

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