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

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

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

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

Заказчики не любят платить за 'гарантию' услуг, потому что это невидимая часть сервиса, которая сама по себе не создает прямой полезности для бизнеса. Люди склонны ценить и готовы платить только за то, что они видят и непосредственно используют - например, за работоспособное приложение или доступ в интернет. Гарантия, обеспечивающая надежность, безопасность, соответствие SLA и другие параметры, проявляет себя только тогда, когда чего-то не происходит (сбоев, нарушений безопасности), и поэтому ее ценность сложно оценить. Кроме того, для оценки гарантии нужны знания и опыт, которые обычно отсутствуют у заказчиков, что делает эту часть услуги менее понятной и менее ценной в их глазах, даже несмотря на то, что без нее полезность не может быть стабильно предоставлена.

Заказчик играет ключевую роль в запуске потоков создания ценности. Заказчик предъявляет требования к услуге - новой или существующей, что запускает соответствующие потоки. При создании или изменении услуги заказчик запускает потоки, связанные с согласованием и фиксацией новых условий услуги и требований к уровню обслуживания (SLA) на этапах Offer и Agree. В рамках этих взаимодействий сбор требований осуществляется в виде деятельности потока Engage. Таким образом, заказчик является инициатором определенных потоков, когда предъявляет спрос на изменение или создание новых услуг.

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

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

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

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