Альтернативой OLA в практике управления ИТ-услугами являются SLA (Соглашения об Уровне Услуг) и UC (Underpinning Contracts). При правильной организации эти документы способны описать все необходимые обязательства и процессы без введения дополнительного термина OLA. SLA можно использовать как для взаимодействия с внешними заказчиками, так и для регулирования внутренних отношений, если определить уровни ответственности и обязательств соответствующим образом. Таким образом, вместо введения OLA, которое усложняет структуру и может привести к путанице, достаточно использовать SLA и UC, что упрощает управление сервисами и повышает прозрачность процессов.

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

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

FTA и анализ дерева событий (ETA) часто используются совместно как дополняющие друг друга методы. FTA – это дедуктивный метод (сверху вниз), направленный на анализ причин конкретного нежелательного события. ETA – индуктивный метод (снизу вверх), начиная с базового события, анализирующий все возможные последствия. Комбинация этих методов позволяет: использовать базовые события из FTA как отправные точки для построения ETA, что позволяет увидеть не только причины, но и все потенциальные последствия сбоя; проверить, не упущены ли какие-либо сценарии в FTA, через обратный анализ ETA; получить более полную картину рисковой ситуации – как от события к причинам, так и от причины к событиям. Например, базовое событие из FTA (например, отказ сервера) может стать начальной точкой для ETA, который покажет все возможные негативные сценарии, возникающие из-за этого отказа.

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

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

Переходной точкой между фазами problem control (PC) и error control (EC) является завершение диагностики проблемы - то есть момент, когда определена корневая причина проблемы и сформированы возможные варианты ее решения. В этот момент процесс управления проблемами переходит от этапа поиска и анализа проблемы к этапу реализации выбранного решения. Определение этой четкой границы между фазами позволяет разделить процесс на нормируемую часть (диагностика) и ненормируемую часть (реализация решения и проверка), что упрощает управление и контроль над процессом.

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

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

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