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

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

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

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

Руководящие принципы помогают в подготовке к экзамену ITIL Practitioner тем, что явное следование им позволяет значительно упростить поиск правильного ответа. При решении экзаменационных вопросов, которые часто имитируют реальные рабочие ситуации, знание и применение этих принципов помогает определить оптимальное решение, так как большинство вопросов построены таким образом, чтобы проверить понимание и умение применять эти руководящие принципы в практических сценариях.

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

Срочное изменение в ITIL v2 — это любое изменение, которое необходимо выполнить настолько быстро, что часть стандартных этапов процесса управления изменениями для него либо пропускается, либо выполняется в сокращенном виде, либо проводится задним числом. Например, пропуск тестирования в тестовой среде (тестирование проводится в продуктивной среде), сокращенная процедура согласования или оформление операций после фактического внедрения. При этом причина срочности не ограничивалась в ITIL v2: это могло быть как устранение ошибки, так и реализация срочной бизнес-потребности.

Совет по руководству информационными технологиями и телекоммуникациями (ICTGC) Бахрейна сгруппировал 37 процессов COBIT5 в 8 блоков: Стратегия и руководство, Управление финансами, Люди и ресурсы, Инфраструктура и эксплуатация, Управление приложениями, Планирование услуг и архитектура, Управление рисками и безопасностью, Управление портфелем и проектами. Эта группировка была сделана для лучшего управления ИТ в контексте развития электронного правительства.

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

Предельные способы агрегирования, такие как среднее арифметическое и произведение, работают неэффективно при большом количестве KPI, потому что при увеличении числа показателей в случае среднего арифметического интегральный показатель стремится к 1 (100%), а при использовании произведения – стремится к 0. Это приводит к тому, что отдельные показатели теряют значимость и не вносят существенного различия в общую оценку.