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

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

Практические упражнения для распознавания Action Bias включают в себя анализ реальных кейсов и ситуаций, таких как рассмотренное в тексте упражнение «Найдите среди предлагаемых утверждений ложные, обоснуйте своё мнение». Полезно регулярно проводить рефлексию принятых решений, задавая вопросы: было ли это действие действительно необходимо? Что бы произошло, если бы мы этого не сделали? Также можно внедрить практику «остановки перед действием» - обязательную паузу перед запуском новых задач для обоснования их необходимости. Деловые игры и симуляции процессов, такие как «Проект Феникс - DevOps на практике», позволяют в безопасной обстановке увидеть, как скрытые убеждения влияют на принятие решений. Важно создавать среду, где вопросы о целесообразности действий поощряются, а не рассматриваются как проявление нерешительности.

Управление доступностью и управление непрерывностью тесно связаны, так как оба процесса ориентированы на обеспечение бесперебойной работы ИТ-услуг. В некоторых стандартах, таких как ISO/IEC 20000, они объединены в один процесс. Это обусловлено тем, что оба процесса направлены на предотвращение сбоев и минимизацию их последствий. Управление доступностью фокусируется на обеспечении требуемого уровня доступности услуг, а управление непрерывностью — на восстановлении услуг после инцидентов, связанных с непредвиденными простоями.

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

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

Принцип одного изделия в потоке (one piece flow) проявился в том, что команда DevOps в процессе реализации проекта «Феникс» настолько овладела подходом, что в конце игры уже не использовала второй ряд столов. Это означает, что задачи проходили через весь процесс без скопления промежуточных запасов, каждая следующая задача могла начаться сразу после завершения предыдущей, что исключило простои и сократило время цикла выполнения задачи. Такой уровень отлаженности процесса позволяет максимально уменьшить время ожидания, избегать параллельного выполнения множества задач, что обычно приводит к снижению производительности из-за многозадачности и переключений контекста.

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

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

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