Нормировать в процессе управления проблемами можно фазу диагностики (problem control - PC), но не всю обработку проблемы целиком. Нормирование проводится на основании уровня влияния проблемы на бизнес-процессы. Например, для проблемы с высоким уровнем влияния срок диагностики может быть установлен в 1 неделю, для среднего уровня - 2 недели, и так далее. Это обосновано тем, что диагностика проблемы, определение корневой причины и вариантов решения имеет более предсказуемый временной контур по сравнению с последующей реализацией решения.

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

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

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

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

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

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

ITIL способствует экономической эффективности ИТ-услуг через интеграцию процессов управления услугами, мощностями и финансами. Это позволяет точно соотносить затраты ИТ с результатами в терминах качества обслуживания, избегать избыточных затрат, оптимизировать использование ресурсов, и демонстрировать стоимость-эффективность различных решений. В частности, Financial Management for IT обеспечивает методы для расчета реальной стоимости услуг и их прибыльности, что ведет к более экономически обоснованному управлению ИТ-портом.

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

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