В ITIL доступность является частью управления непрерывностью бизнеса (BCM). Доступность фокусируется на минимизации простоев текущих операций, тогда как BCM охватывает долгосрочную устойчивость бизнеса при кризисных ситуациях (стихийные бедствия, массовые сбои). Высокая доступность снижает риски, требующие вмешательства BCM, но не заменяет его: даже при 100% доступности возможны сценарии, требующие полного восстановления инфраструктуры.

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

Некоторые организации продолжают использовать методы, восходящие к HPOVSD (Hewlett Packard OpenView Service Desk), из-за инерции мышления, привычки к традиционным подходам и недостатка осведомленности о современных практиках управления инцидентами. Часто решение о выборе метода основано не на текущих потребностях и возможностях, а на рекомендациях предыдущих консультантов или устаревших шаблонах внедрения. В ряде случаев отсутствует глубокий анализ эффективности используемых методов, что приводит к сохранению практик, которые когда-то могли быть оптимальными для конкретных систем, но сейчас уже устарели в условиях современных возможностей автоматизации.

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

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

Процесс управления проблемами инициируется не внешними событиями (в отличие от инцидентов), а внутренними механизмами: анализ тенденций множества инцидентов, плановые аудиты, результаты диагностики инцидентов, данные мониторинга систем и рекомендации экспертных групп (например, PRB). Для эффективной работы необходимо внедрить регулярные проверки этих источников и чётко прописать критерии создания записи о проблеме.

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

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

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

При использовании дорожной карты сроки реализации требований определяются иначе, чем при работе только с бэклогом. Сначала обозначаются конкретные целевые состояния и сроки, в которые необходимо достичь этих состояний. Затем определяется состав работ по достижению каждого целевого состояния, включая не только список требований, но и всю деятельность, необходимую для движения к этому состоянию. Под этот состав работ намечается календарь конкретных действий, основанный на опыте команды. Этот подход учитывает не только сложность самих задач, но и дополнительные факторы: время на уточнение требований, согласования, синхронизацию со смежными командами, организацию поставок, согласование приёмочных работ, резервирование ресурсов сервисных команд. Благодаря такому подходу удается дать более точные прогнозные сроки реализации запросов бизнеса, так как виден полный контекст работы над достижением целевого состояния, а не только отдельная задача из бэклога.