В версии стандарта ISO 20000 за 2005 год было указано требование «There shall be an integrated approach to change and configuration management planning», предписывающее использовать интегрированный подход к планированию этих процессов. Однако в обновлённой версии 2011 года данная формулировка была удалена, что отразило более гибкий подход к взаимодействию процессов, позволяющий организациям самостоятельно определять степень их интеграции в зависимости от специфики бизнеса.

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

Метрика помогает предотвратить практику «футбола» за счёт того, что учитывает реальное время, затраченное группой на обработку инцидента, включая время с момента назначения до переназначения. Если группа быстро перенаправляет инцидент без реального анализа и работы, её доля во времени обработки (ti) будет небольшой. Однако, если инцидент в итоге просрочен, суммарная ответственность всех групп пропорциональна их реальному вкладу во время обработки. Кроме того, для предотвращения практики «футбола» рекомендуется использовать не только метрику своевременности, но и дополнительную метрику результативности, которая оценивает, насколько группа реально продвигает решение инцидента при работе с ним.

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

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

Определение границ между процессами управления проблемами (PRB) и постоянного совершенствования (CSI) в конкретной организации должно учитывать следующие факторы: 1) Масштаб и сложность организации - в небольших организациях границы могут быть размыты, тогда как в крупных необходимы четкие определения 2) Стадия зрелости процессов - на начальных этапах внедрения PRB может сосредоточиться только на технических проблемах, тогда как CSI будет охватывать более широкие аспекты 3) Специфика бизнеса и требований к услугам - чем критичнее услуги для бизнеса, тем более детальной должна быть проработка границ 4) Реальная практика работы - границы должны отражать то, как процессы фактически взаимодействуют, а не только теоретические модели 5) Потенциальные точки пересечения - важно определить, где процессы могут дублировать друг друга или оставлять "белые пятна" Практические рекомендации: - Начните с того, что уже работает: определите, какие аспекты процессов уже есть в организации, и формируйте границы вокруг них - Не пытайтесь создать единую систему сразу для всех уровней - начните с операционного уровня, затем переходите к стратегическому - Регулярно пересматривайте границы по мере развития процессов - Убедитесь, что есть четко определенные точки передачи задач между процессами - Создайте совместные рабочие группы для решения вопросов, где границы неочевидны Самое главное - границы должны быть практичными и решать реальные проблемы организации, а не соответствовать идеальным теоретическим моделям. Часто правильное определение границ приходит не по теоретическим соображениям, а в результате практической работы и устранения возникающих проблем.

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

В ITIL 4 картина с ролями упростилась по сравнению с ITILv3. Термин 'service level manager' упоминается лишь единожды в главной книге о взаимодействии потребитель-поставщик 'Повышение ценности для заинтересованных сторон', но сама роль не определяется. В публикации, описывающей одноименную практику 'Service Level Management ITIL4 Practice Guide', эта сущность не упоминается вообще. Это упрощение роли в новой версии ITIL минимизирует вероятность избыточного усложнения системы управления и бесплодных споров о распределении задач между ролями, что соответствует принципу 'Keep it simple and practical'.

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

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