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

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

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

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

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

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

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

Чтобы выявить и использовать стереотипы клиентов (Юг) для улучшения ИТ-услуг, следует: 1) Провести исследования и собрать информацию о существующих установках клиентов посредством опросов, интервью и анализа обратной связи. Например, для ИТ-поддержки стереотипом может быть мнение, что служба медленно реагирует на запросы. 2) Определить, какие из этих стереотипов негативны и влияют на восприятие услуги. 3) Разработать специальные мероприятия для разрушения негативных стереотипов: например, внедрить систему отслеживания времени ответа и гарантировать ответ в течение 15 минут. 4) Создать коммуникацию, демонстрирующую клиентам, что негативные стереотипы не соответствуют реальности вашей услуги. Например, сообщать клиентам при обращении в поддержку: "Спасибо за обращение, ваш запрос будет обработан в течение 15 минут". 5) Регулярно измерять, как изменяются восприятие и стереотипы после внедрения изменений. Это позволит целенаправленно улучшать восприятие вашей ИТ-услуги.

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

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