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

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

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

Укрупнённые схемы ИТ-систем, показывающие только общие компоненты (например, «ERP-система»), недостаточны для расчёта себестоимости услуг, потому что не учитывают различия в потреблении ресурсов различными группами пользователей. Например, одни пользователи могут постоянно работать в системе, другие использовать её редко для отчётов, третьи — обрабатывать большие объёмы данных. Себестоимость услуг зависит от профиля использования, который определяется бизнес-процессами. Для точного расчёта необходима детализация до уровня подсистем, отражающая, как именно разные пользователи потребляют ресурсы.

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

Для выбора подходящего владельца критичного для бизнеса процесса необходимо сначала определить степень критичности каждой обязанности владельца, используя десятибалльную шкалу, где 10 означает, что отсутствие выполнения этой обязанности может привести к серьезным проблемам. Затем следует искать человека, обладающего достаточными полномочиями и возможностями для выполнения наиболее критичных обязанностей. Для высококритичных процессов владельец должен иметь широкий охват контроля (scope of control), охватывающий все подразделения, участвующие в процессе. Если невозможно назначить высокопоставленного руководителя, необходимо создать надежные механизмы поддержки и эскалации, чтобы владелец мог оперативно получать необходимую поддержку от руководства. Также важно учитывать, что владелец должен иметь достаточно времени для выполнения обязанностей по управлению процессом, не будучи перегруженным другими обязанностями.

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

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

Основное различие между подходами канбана и VSM в части ограничения работ в процессе заключается в том, что в канбане ограничение WIP является неотъемлемым и регулируемым элементом системы, тогда как в классической карте потока создания ценности (VSM) такое ограничение не определяется напрямую. В VSM можно определить теоретическое ограничение всей системы по самому медленному участку (узкому месту), но в канбане WIP-ограничения задаются явно для каждого этапа или для всего процесса, что позволяет оперативно управлять загрузкой и скоростью выполнения задач. Это особенно важно в средах, где необходимо сохранять ресурсы для неплановых задач, таких как срочные исправления ошибок.

Рейтинг решения инцидента рассчитывается по формуле: если фактическое время устранения (ti) меньше или равно Tmin, рейтинг составляет 100%; если ti превышает Tmax, рейтинг равен 0%. При времени между Tmin и Tmax рейтинг плавно снижается от 1 до 0 по формуле (Tmax - ti) / (Tmax - Tmin). Такой подход учитывает не только соблюдение сроков, но и степень влияния простоя на бизнес, поощряя максимально быстрое устранение инцидентов.