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

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

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

Приоритетные виды лицензий следует выбирать исходя из текущих проблем организации. Например, это могут быть продукты Microsoft с подпиской, часто устанавливаемые вручную, или «прикладной софт» (например, Photoshop), который сотрудники копируют без контроля. Серверное ПО редко становится первоочередной задачей. Ключевой критерий – наличие уже существующего процесса учёта (даже в Excel), так как внедрение системы для управления тем, что никто не готов отслеживать, обречено на провал.

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

В ITIL 4 для выявления требований потребителя используются методы, такие как анализ путешествия заказчика (customer journey), регулярные опросы удовлетворенности (CSAT, NPS), оценка поведения пользователей (например, объем усилий, количество ошибок) и обратная связь в рамках сервис-ревью. Цель этих методов — идентифицировать ключевые характеристики услуги, важные для потребителя, и согласовать их измерение для достижения оптимального уровня удовлетворенности.

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

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

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

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