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

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

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

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

Три основные причины, почему "заложенные" в процесс KPI не очень хорошо работают: 1. Авторы KPI спроектированного процесса часто слепо копируют рекомендации из "умных" книг (ITIL, COBIT и другие), не учитывая, что приведенные там метрики являются лишь примерами для иллюстрации, а не готовыми решениями, подходящими для конкретной организации. 2. При внедрении KPI часто игнорируется здравый смысл, когда стремятся измерить всё подряд и отвергают субъективные данные (например, опросы удовлетворенности пользователей), хотя некоторые аспекты управления можно и нужно оценивать через удовлетворенность. 3. KPI отдельных процессов проектируются изолированно, без учета их взаимосвязей и места в общей системе управления ИТ. Это создает фрагментарную картину вместо комплексной системы оценки деятельности ИТ-подразделения.

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

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

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

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

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