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

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

Вероятность в структуре риска проявляется на трех уровнях: 1) Вероятность возникновения причин или источников риска (угроз), что зависит от внешней среды. 2) Вероятность того, что появление угрозы приведет к наступлению события, что определяется уровнем уязвимости системы и силой угрозы. 3) Вероятность того, что произошедшее событие вызовет конкретные последствия для организации, которые могут варьироваться от минимальных временных потерь до серьезных финансовых или репутационных убытков. PMBOK рекомендует рассматривать разные сценарии: пессимистический, наиболее вероятный и оптимистический, чтобы оценить возможные варианты исхода.

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

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

Активация аварийного плана восстановления (disaster recovery plan) необходима, если инцидент продолжается дольше установленного срока без признаков решения. Ответственность за принятие решения об активации плана лежит на менеджере major-инцидента. Этот специалист должен знать правила и процедуры запуска плана аварийного восстановления, чтобы оперативно перейти к следующему уровню реагирования при необходимости, сокращая время простоя критически важных сервисов.

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

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

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

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