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

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

Жёсткие временные рамки могут мешать качественному решению задач, особенно в нестандартных ситуациях. Отсутствие фиксированного лимита позволяет сотрудникам сосредоточиться на реальном результате вместо гонки за временем. Например, если для полного решения проблемы пользователю требуется 25 минут вместо 15-минутного ориентира, это приведёт к повышению его удовлетворённости и снижению количества повторных обращений. Гибкость процессов поддерживает мотивацию сотрудников, так как они видят ценность своих действий в качестве обслуживания, а не формальном соблюдении сроков.

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

ITIL выделяет три типа поставщиков услуг: Тип I и Тип II (внутренние поставщики) и Тип III (внешние поставщики). Для внутренних поставщиков (Тип I и Тип II) финансовые штрафы обычно отсутствуют, а ответственность выражается в виде уменьшения премий сотрудников ИТ-подразделения. Штрафы могут применяться автоматически или на усмотрение руководства, что делает применение санкций менее однозначным. Для внешних поставщиков (Тип III) предусматриваются реальные финансовые санкции, но их размер и применение часто ограничены. Например, сумма штрафов обычно не превышает 20–30% от суммы контракта, а в некоторых законах, таких как 44-ФЗ, штрафные санкции определены значительно ниже, в диапазоне от 0,5% до 2,5% от суммы контракта.

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

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

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

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

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