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

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

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

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

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

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

PCF был разработан в 1992 году Американским центром эффективности и качества (APQC), который продолжает поддерживать и развивать этот стандарт. Текущая версия PCF - 6.1.0, выпущенная в марте 2014 года. APQC является автором и поддерживающей организацией данного стандарта, обеспечивающей его постоянное развитие и адаптацию к меняющимся требованиям бизнеса.

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

Показатель SPI (Schedule Performance Index) из методики EVM не подходит для оценки соблюдения сроков завершённых проектов, так как по окончании проекта, даже с большим запозданием, весь первоначальный объём считается освоенным, и значение SPI автоматически становится равным единице. Это приводит к тому, что SPI не отражает реальное отставание по срокам выполнения проекта. Например, при измерении проекта рытья канавы, когда работы завершаются с задержкой, SPI в конце проекта станет 100%, несмотря на то, что работа была выполнена дольше запланированного срока.

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