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

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

Если поток производства не работает круглосуточно (как это обычно бывает в ИТ), Time in Process должен рассчитываться только с учетом рабочего времени, а не полных календарных дней. Это означает, что период времени от начала до завершения задачи должен быть исчислен в рабочих часах или рабочих днях. Например, задача, которая начала обрабатываться в пятницу вечером и завершилась в понедельник утром, должна учитывать только рабочее время между этими временными точками, исключая выходные дни и нерабочие часы. Для этого необходима автоматизация или специальные правила обработки данных, учитывающие календари сотрудников, что значительно усложняет расчет по сравнению с простым вычитанием времени начала из времени завершения.

Для применения модели Compass Model к электронной почте как общеорганизационной ИТ-услуге: Север (потребности): сотрудникам необходимо надёжно и быстро обмениваться информацией внутри компании и с внешними партнёрами; получать уведомления о важных событиях; хранить переписку для последующего доступа. Запад (желания): интуитивно понятный интерфейс; синхронизация с календарём; фильтрация спама; дополнительные функции вроде шифрования или совместного редактирования файлов. Юг (стереотипы): корпоративная почта медленная, неудобная, часто зависает, или наоборот, безопасная и надёжная. Восток (эмоции): раздражение при сбоях в работе почты, спокойствие при стабильной работе, доверие к системе при эффективной защите данных. Такой анализ помогает определить, какие аспекты необходимо улучшить для повышения удовлетворённости сотрудников и повышения ценности услуги.

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

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

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

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

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

ISO 27031 (Guidelines for ICT Readiness for Business Continuity) описывает вопросы управления ИТ-системами для гарантии обеспечения непрерывности бизнеса в соответствии с подходом, установленным в стандарте ISO 22301. Стандарт был ранее известен как BS 25777 и практически не изменился при переходе в семейство стандартов по информационной безопасности.