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

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

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

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

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

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

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

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

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

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