Компактность и однородность "размеров" элементов в бэклоге важны потому, что они позволяют команде обещать стабильность поставок. Если трудоемкость задач варьируется чрезмерно, например, от 10 минут до нескольких недель, становится практически невозможно прогнозировать скорость работы и планировать загрузку команды. Однородные по сложности элементы позволяют более точно оценивать их выполнение, упрощают балансировку потока работ и обеспечивают предсказуемость производительности команды. Это особенно важно для упреждающего управления загрузкой и соблюдения установленных work in progress лимитов.

Существует два основных подхода к определению соотношения этих процессов. 1) Модель №1: CSI рассматривается как общий подход к совершенствованию, который встраивается во все области деятельности, в том числе в процесс управления проблемами. В этом случае CSI является мета-практикой или инструментом, который используется на всех этапах жизненного цикла услуги и опоясывает стратегию, проектирование, преобразование и эксплуатацию. Процесс управления проблемами, в свою очередь, использует подходы CSI для решения конкретных проблем. 2) Модель №2: Граница между CSI и PRB проходит не между различными видами деятельности, а между различными уровнями организации. В этом случае CSI представляет собой общекорпоративную практику, которая охватывает всю организацию (например, весь ИТ-департамент), в то время как процесс управления проблемами фокусируется на решении конкретных технических ошибок. При этом в большинстве организаций эти практики появляются не одновременно и имеют разный охват, что делает вопрос границы между ними актуальным только после установления жизнеспособности обеих практик. Если рассматривать CSI как мета-практику, обеспечивающую единые подходы к управлению качеством (аналогично практике риск-анализа), то эти процессы находятся в разных плоскостях, но взаимодействуют друг с другом.

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

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

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

Новые возможности визуализации CMDB позволяют значительно упростить анализ инфраструктурных инцидентов. Теперь можно легко определять, какие конфигурационные единицы (CI) влияют на конкретную услугу, и оценивать последствия отказа определенных CI. Благодаря возможности «раскрывать» связи, аналитики могут детально изучить зависимости внутри ИТ-инфраструктуры, быстро находя проблемные участки и планируя решения.

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

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

Процедура мини-расследования (major incident review) после устранения major-инцидента включает анализ всех факторов инцидента, формирование отчета с рекомендациями по предотвращению аналогичных ситуаций в будущем, оценку эффективности действий, предпринятых во время управления инцидентом. Результаты расследования обсуждаются с заинтересованными сторонами, и на их основе могут быть зарегистрированы проблемы, известные ошибки, либо предложены меры по улучшению ИТ-услуг (например, через service improvement plan или реестр CSI).

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