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

В ITIL v3 экстренное изменение (emergency change) определяется как изменение, которое должно быть внедрено как можно быстрее, например, для решения значительного инцидента или установки критического обновления безопасности. Отличие от ITIL v2 состоит в том, что в ITIL v3 экстренные изменения жестко ограничены для решения проблем, влияющих на бизнес, и не рассматриваются как способ быстрого внедрения новых функциональных возможностей. Новые функции должны обрабатываться как нормальные изменения, но с высокой степенью срочности.

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

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

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

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

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

Метод анализа 5-Why's предполагает многократное задавание вопроса «почему» (пять раз) для выявления корневой причины проблемы. В процессе управления проблемами ITIL метод позволяет последовательно углубляться в анализ каждой последующей причины предыдущего явления. Например, при анализе неработающего принтера такой подход выявляет цепочку: неисправный нагревательный элемент → перепады напряжения → нестабильная работа подстанции → её устаревание → отсутствие модернизации. Цель метода — определить первопричину, хотя на практике часто останавливаются на том этапе, где обнаруживается граница зоны влияния поставщика услуг.

Операционные затраты (OPEX) составляют 67-68% от общего объема затрат на ИТ в среднем по компаниям. В банках этот показатель выше — 76-79% (по данным за 2015 год), тогда как международная банковская статистика (Computer Economics) приводит цифру около 73%. Российские компании обычно демонстрируют более низкий уровень операционных затрат — 55-60%, но кризисные условия способствуют их росту за счет сокращения инвестиционных программ.

Рекомендации по формулированию KPI в ITIL 4 представлены через факторы успеха практик (PSF). Для каждой практики определяются PSF, каждый из которых сопровождается подробным описанием и примерами метрик, которые можно использовать в качестве KPI. Например, для практики управления инцидентами PSF «раннее выявление инцидентов» имеет следующие примеры KPI: время между возникновением и обнаружением инцидента и доля инцидентов, выявленных с помощью мониторинга. Такая структура делает процесс формулирования KPI более простым и понятным, поскольку она предоставляет конкретные рекомендации и примеры измерений для каждого важного аспекта практики.