Метрики могут быть использованы для оценки руководителей подразделений через систему взаимосвязанных показателей, отражающих их вклад в процессы. Решение заключается в построении матрицы, где по вертикали расположены функции (отделы, группы), а по горизонтали — процессы. Пересечение функции и процесса означает участие данной функции в реализации процесса, соответственно функциональный руководитель отвечает за предоставление необходимых ресурсов. Процессные метрики сотрудников подразделения связываются с руководителем, назначаются целевые значения, и контролируется их соблюдение. Даже если руководитель формально не несет функциональных обязанностей в процессах (например, не является ответственным в матрице RACI), такой подход стимулирует его к взаимодействию с процессным управлением. На разных уровнях иерархии метрики могут агрегироваться: например, региональные руководители оцениваются по своим метрикам, а руководитель в HQ — по агрегированным метрикам региональных руководителей. Важно, чтобы все используемые KPI были сопоставимы между собой (единая шкала от 0 до 1, одинаковое направление оценки).

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

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

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

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

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

BPO (Business Process Outsourcing) — это вид аутсорсинга, при котором поставщику передаются исполнение и ответственность за целую бизнес-функцию или процесс. В отличие от обычного аутсорсинга задач, где на сторону передаются отдельные проекты с ограниченными сроками и бюджетом, BPO предполагает долгосрочное сотрудничество без жестких временных рамок и фиксированного бюджета. Организация передает аутсорсеру замкнутую функциональную область, а не отдельные задачи. Это более глубокая форма аутсорсинга, требующая тесного взаимодействия между заказчиком и исполнителем.

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

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

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