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

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

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

Детализация классификатора изменений должна быть сбалансированной, избегая как избыточного упрощения, так и чрезмерной детализации. Нецелесообразно прописывать все возможные сценарии изменений «до последнего чих», что потребует значительных временных и трудовых ресурсов без реальной пользы. В то же время классификатор должен учитывать специфику различных типов изменений. Оптимальным подходом является разделение изменений на стандартные и нестандартные. Для стандартных изменений, имеющих предсказуемый характер и минимальные риски, допустима высокая степень детализации с чётким прописыванием последовательности действий, исполнителей и сроков. Стандартные изменения могут быть включены в каталог поддержки, и для них могут устанавливаться нормативы SLA. Для нестандартных изменений детализация должна быть менее жесткой, предполагая наличие анализа рисков, оценки влияния и управленческих решений на ключевых этапах. Структура классификатора при этом должна иметь матрично-иерархическую организацию, сочетающую общие типовые порядки обработки с возможностью их настройки под специфику конкретных систем и направлений.

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

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

Минимизация технического долга достигается за счёт применения методологии Test-Driven Development (TDD), постоянного рефакторинга кода, внедрения сквозного автоматизированного тестирования и регулярного контроля качества. Также важно поддерживать баланс между скоростью разработки и стабильностью системы, выделяя время на устранение уязвимостей и улучшение архитектуры. Раннее выявление и исправление проблем помогает избежать накопления долгосрочных рисков и упрощает дальнейшее развитие продукта.

В управлении внеплановыми простоем при срочном внедрении изменений задействованы три основных процесса ITIL: управление изменениями (Change Management), который отвечает за процесс внедрения изменений и формирование документа PSO; управление уровнем услуг (Service Level Management, SLM), который занимается обсуждением и согласованием с заказчиком целевых показателей доступности на период внедрения изменений; и управление доступностью (Availability Management), который проверяет соответствие плановой доступности целевым значениям и оценивает влияние изменений на доступность сервисов в долгосрочной перспективе.

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

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