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

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

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

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

Для многих пост-советских компаний концепция услуг может быть чуждой из-за особенностей их менталитета и управления. В таких организациях часто доминирует декларативный подход, при котором ИТ-департамент воспринимается как техническая служба, а не как провайдер услуг. Бизнес не привык рассматривать ИТ в качестве партнера, способного участвовать в достижении целей через предоставление услуг. Это делает внедрение управления ИТ-услугами сложным, так как требует глубоких культурных изменений, а не просто формальных процессов.

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

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

Согласно рекомендациям ITIL, правильная обработка жалоб заказчиков включает несколько важных принципов. Необходимо создать формальный процесс по обработке жалоб, так как жалобы неизбежны. Никакую жалобу нельзя оставлять без внимания – на каждую жалобу должен быть подготовлен ответ. Жалоба всегда является сигналом о явной или скрытой проблеме и должна быть идентифицирована и проанализирована. В ITIL выделяют основания для регистрации жалоб, типы жалоб и правила их обработки. BRM на этапе Service Operation отвечает за управление этим процессом, убеждаясь, что каждая жалоба получает надлежащее внимание и решение, что в свою очередь помогает выявить проблемы и улучшить качество предоставляемых услуг.

После выявления «известной ошибки» она документируется в специальной базе данных известных ошибок (KEDB - Known Error Database). В запись об ошибке включается информация о корневой причине, описании проблемы, временном обходном решении (workaround), а также данные о влиянии на бизнес и истории связанных с ней инцидентов. Эта информация используется при возникновении аналогичных инцидентов для быстрого применения известного обходного решения. Запись поддерживается в актуальном состоянии и обновляется по мере получения новых данных или поиска постоянного решения проблемы.

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