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

Информация о major-инциденте для первой линии поддержки должна включать: описание происшествия с указанием, что произошло и в какое время, ожидаемое время решения; уникальный идентификатор инцидента (ID) для установки связей с поступающими обращениями пользователей; оценку влияния на ИТ-услуги, опирающуюся на данные CMDB, чтобы понимать, каким пользователям и в какой степени оказывается влияние, а также уровень критичности проблемы. Эти данные позволяют первой линии давать точные ответы на вопросы пользователей и управлять потоком обращений.

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

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

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

В ITIL 4 вместо критических факторов успеха процессов (CSF), использовавшихся в ITILv3, появились факторы успеха практик (PSF). Основные изменения заключаются в том, что теперь факторы успеха определяются не для отдельных процессов, а для практик в целом. PSF представляют собой комплексные функциональные компоненты практики, необходимые для обеспечения её соответствия своему назначению, и охватывают все аспекты управления услугами: Организации и люди, Информация и технологии, Потоки ценности и процессы, Поставщики и партнёры. Формулирование KPI по-прежнему основывается на этих факторах, но теперь в контексте практик и их вклада в потоки создания ценности.

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

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

Выбор первого процесса ITIL для внедрения должен основываться на комплексной оценке. Необходимо проанализировать несколько ключевых факторов: 1) Какие процессы в данный момент вызывают наибольшие проблемы и боли у бизнеса и пользователей (частые простои, низкая удовлетворенность, регулярные ошибки); 2) Какой процесс при успешном внедрении даст самые быстрые и заметные улучшения, чтобы создать позитивный импульс для дальнейших изменений; 3) Какой процесс имеет наибольшую поддержку среди ИТ-персонала и руководства; 4) Какие процессы имеют простую структуру и четкие границы, что упростит внедрение. Обычно рекомендуется начинать с управления инцидентами, так как это процесс, который непосредственно влияет на пользователей, имеет четкие метрики (время решения, удовлетворенность), и его улучшение быстро заметно бизнесу. Альтернативой может быть управление запросами на обслуживание (Service Request Management), который часто менее сложен в реализации и также дает быстрый эффект. Важно избегать сложных процессов, таких как управление конфигурациями или управление изменениями, на начальном этапе, так как они требуют значительных изменений во многих других процессах.

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