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

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

При изменении бизнес-процессов: 1) Анализировать поддерживаемые системы на предмет появления новых объектов или операций, требующих добавления/изменения системных ролей. 2) Связывать новые роли с исполнителями (должностями или подразделениями), так как сами исполнители могут измениться. Например, если внедряется новый этап в цепочке согласования документов, необходимо создать роль 'Согласующий по новому направлению' и закрепить её за соответствующими сотрудниками. Акцент делается не на соответствие старых и новых ролей, а на актуализацию распределения прав в рамках изменённых процессов.

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

Системный подход в управлении ИТ-услугами означает анализ и улучшение всей системы в целом, а не отдельных её элементов, с учётом взаимного влияния различных компонентов системы и последствий воздействий на них. Этот подход подразумевает необходимость учитывать совокупное влияние, искать узкие места и направлять усилия в первую очередь на их устранение. В ITSM системный подход закреплён на уровне принципов руководства ITIL® Practitioner и включает анализ системы как набора взаимосвязанных элементов, где изменения в одном элементе влияют на всю систему в целом.

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

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

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

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

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