Согласно статистике, деловые игры в России проводятся значительно реже, чем в Европе — примерно в 4-8 раз реже. При этом эффективность этого метода обучения в западных компаниях ощущается больше, и организации чаще используют его в процессе развития персонала. Разница может быть связана с разным подходом к восприятию термина «деловая игра» и его роли в обучении, а также с бюрократическими ограничениями и непониманием ценности данного метода в российских компаниях.

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

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

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

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

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

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

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

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

Процесс Управления запросами на обслуживание (RFF) не несёт первичной ответственности за прозрачность процесса Управления инцидентами. RFF может выступать как дополнительный канал коммуникации для передачи информации пользователю по запросу (реактивный канал), действуя как транспорт для информации, предоставляемой процессом INC. Однако ответственность за эффективное использование этого канала и обеспечение должного уровня прозрачности процесса лежит на процессе Управления инцидентами (INC), который должен определить, когда и как использовать RFF для информирования пользователей. INC является владельцем процесса и несёт ответственность за качество коммуникации в целом.