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

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

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

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

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

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

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

Продолжительность отчетного периода влияет на значение предложенной метрики через соотношение с средним временем решения проблем. Если отчетный период слишком короткий по сравнению со средним временем решения проблем, то за этот период будет закрыто мало проблем (C мал), а количество новых проблем (N) может быть высоким, что приведет к более высокому значению метрики. Если же период слишком длинный, то большая часть проблем будет закрыта, но новые проблемы (N) уже могут быть частично закрыты, что может исказить значение метрики. Оптимально устанавливать отчетный период равным или немного большим среднего времени решения проблем, чтобы метрика адекватно отражала реальную эффективность процесса.

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

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