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

Для преодоления низкой отзывчивости клиентов рекомендуется упростить процессы сбора обратной связи: сократить длину форм, сделать их мобильными, добавить элементы gamification (например, розыгрыши призов). Также важно персонализировать запросы, обращаясь к клиенту по имени и указывая, как его отзыв поможет улучшить услугу. Критически важно, чтобы ответы на отзывы были видимыми — клиент должен видеть, что его мнение влияет на изменения. Это повышает вероятность дальнейшего участия и переводит взаимодействие из «Мертвой зоны» в более активные сценарии.

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

Предложенные показатели (суммарное время простоев, максимальный разовый простой, количество нарушений) имеют несколько преимуществ перед классическим подходом. Они позволяют: 1) Более точно оценить влияние доступности ИТ-услуг на конкретные бизнес-процессы; 2) Учесть специфику разных видов бизнеса - для некоторых критичны долгие простои, для других частые кратковременные; 3) Принимать обоснованные решения по повышению надежности систем с учетом реального бизнес-влияния; 4) Создать более прозрачные SLA с учетом особенностей воздействия простоев на бизнес; 5) Лучше оценить успешность мероприятий по повышению надежности на основе их реального влияния на бизнес-процессы.

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

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

С 2012 по 2018 год отмечается сглаживание разрыва между отраслями. Снижение количества обращений в ранее лидирующих секторах (например, финансы) сочеталось с небольшим ростом в тех сферах, где обращений было мало (например, здравоохранение). Это говорит о более равномерном внедрении ИТ-решений во всех отраслях, росте грамотности пользователей и улучшении качества услуг. Общий тренд — снижение среднего числа обращений на пользователя в долгосрочной перспективе.

В ITIL рекомендуется использовать «marketing mindset» (маркетинговый способ мышления) при сборе и обработке требований заказчика. Сервис-провайдеру нужно отвечать не на вопрос «Что мы должны предоставить?», а на три ключевых вопроса: какие задачи выполняет заказчик и как ИТ может им в этом помочь; каких результатов хочет достичь заказчик; какие ограничения могут помешать заказчику достичь желаемого и как сервис-провайдер может снять эти ограничения. ITIL отмечает, что у сервис-провайдера часто нет руководств по сбору и обработке требований, что приводит к ситуации, когда заказчики предоставляют требования в произвольной форме без учета процессов. BRM играет ключевую роль в правильной интерпретации требований и обеспечении обратной связи между заказчиком и ИТ-специалистами.

Outcome зависит от субъективного восприятия потребителя и часто выражается в нематериальных или долгосрочных эффектах, которые сложно зафиксировать количественно. В то время как Output обычно имеет чёткие количественные параметры (например, сроки доставки, объём функционала), что позволяет легко его измерять и отчитываться о нём. Для оценки Outcome необходимо собирать обратную связь, проводить опросы удовлетворённости или анализировать поведение клиентов.

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