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

В ITIL v3 определение инцидента включало два предложения: «Незапланированное прерывание или снижение качества ИТ-услуги. Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом, как, например, сбой одного диска из массива зеркалирования». В ITIL 4 второе предложение отсутствует, и определение стало короче: «Незапланированное прерывание или снижение качества услуги». Однако в руководстве по управлению инцидентами ITIL 4 указано, что практика все равно включает в себя восстановление нормальной работы ресурсов даже если их сбой не виден пользователям. Таким образом, ключевые смыслы остались прежними, различие скорее терминологическое.

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

Предложенные показатели (суммарное время простоев, максимальный разовый простой, количество нарушений) тесно связаны с традиционными метриками надежности MTRS (Mean Time To Restore Service), MTBF (Mean Time Between Failures) и MTBSI (Mean Time Between Service Incidents). Например, суммарное время простоя связано с MTRS, количество нарушений - с MTBF, а средняя продолжительность работы без нарушений соотносится с MTBSI. Однако предложенные показатели сформулированы более приближенно к бизнес-эффекту и фокусируются на том, как именно простои влияют на бизнес-процессы, в то время как традиционные метрики носят более технический характер и не всегда напрямую связаны с бизнес-потерями.

В ITIL указано два конкретных примера emergency-изменений: первое — изменение, необходимое для устранения массового инцидента, когда, например, сервис перестал обслуживать большое количество пользователей; второе — установка патча для закрытия критических уязвимостей в системе безопасности. Эти случаи требуют немедленного реагирования, так как их игнорирование приведёт к значительному ущербу для бизнеса, включая финансовые потери или репутационный риск.

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

Методология PRINCE2® определяет шесть основных аспектов управления проектами: Сроки (Timescales), Затраты (Costs), Объем работ (охват), Качество (Quality), Выгоды (Benefits) и Риск (Risk). Эти аспекты представляют собой параметры, которые необходимо контролировать в рамках проектного управления, и образуют взаимосвязанную систему, где изменение одного из параметров может повлиять на другие.

В ITIL определены несколько ролей в области управления изменениями: Владелец практики (Practice owner) - отвечает за общее управление, развитие и стратегическое направление практики; Менеджер изменений (Change manager) - управляет всеми аспектами практики 'Поддержка изменений', включая управление жизненным циклом отдельных изменений; Координатор изменений (Change coordinator) - выполняет те же обязанности, что и менеджер изменений, но в ограниченном контексте; Председатель Консультативного совета по изменениям (CAB chair); Участники Консультативного совета по изменениям; Инициатор изменений. Роли могут комбинироваться в зависимости от размера и структуры организации.

Формулировки типа «внедрить процесс управления изменениями» не отражают реальную ценность проекта для бизнеса и могут привести к ситуации, когда проект «живет своей жизнью» без четкого измерения результатов. Такой подход не отвечает на вопросы: для чего нужен этот процесс, какие проблемы он решает, какую пользу приносит бизнесу. Постановка цели как «внедрить процесс» фокусируется на инструменте, а не на результате. Вместо этого стоит формулировать цели через конкретные результаты и их влияние на бизнес, например: «Снизить количество аварийных изменений на 30% за счет внедрения структурированного процесса управления изменениями» или «Сократить время на утверждение изменений на 25%».

COBIT 5 for Risk предлагает рекомендации по снижению рисков, сгруппированные по семи факторам влияния: политики, принципы и подходы; процессы; организационная структура; культура, этика, поведение; информация; услуги, инфраструктура и приложения; люди, навыки и компетенции. Для каждой категории рисков из 20 предложенных в документе даются конкретные меры и уточнения о том, как каждая из них влияет на вероятность возникновения риска и величину возможного ущерба. Помимо этого, для каждого риска указывается применимость различных стратегий реагирования: уклонение, принятие, передача и снижение.