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

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

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

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

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

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

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

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

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

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