Цифры не отражают человеческого фактора: мотивации, качества взаимодействия, скрытых издержек. Например, показатель «100% задач выполнено в срок» может маскировать постоянные переработки сотрудников или откладывание проблем на будущее. Без анализа контекста руководство получает искаженную картину, которая не помогает в принятии решений и может привести к ухудшению эффективности в долгосрочной перспективе.

Учет рабочего времени при расчете Flow Efficiency для распределенных команд является сложной задачей, так как сотрудники могут работать в разных часовых поясах и иметь разные графики (например, аналитики в Новосибирске, разработчики в Москве, тестировщик на неполную ставку). Точный расчет требует учета доступного рабочего времени каждого участника потока, но в условиях совместной работы над задачей неясно, какой календарь использовать. Практически все реализации сводятся к упрощенным подходам и договоренностям, а не к точному расчету, что делает получаемые значения приблизительными. Некоторые методы предполагают использование среднего календаря команды или выделенного ответственного, но ни один из них не дает идеального результата.

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

Показатель SPI (Schedule Performance Index) в методике EVM работает адекватно в процессе выполнения проекта, показывая соотношение запланированного объёма работ к фактически выполненному. Например, если в проекте рытья канавы длиной 20 метров пришлось работать с меньшей производительностью из-за болезни одного рабочего, SPI в первые дни будет корректно показывать отставание (например, 50%). Однако к концу проекта, когда весь объём работ выполнен, даже с задержкой, SPI автоматически становится равным 1, что скрывает реальное отставание в сроках и вводит в заблуждение при оценке соблюдения временных рамок проекта.

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

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

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

Да, проверка CMDB обязательно должна включать анализ взаимосвязей CI, так как ошибки в отображении связей между элементами (например, неправильное указание зависимостей серверов и приложений) приводят к каскадным сбоям при изменениях. Аудиторы проверяют актуальность отношений «родитель-потомок», корректность отображения физических и логических связей, соответствие схем взаимодействия реальным сценариям использования. Это особо важно для процессов управления изменениями и восстановления после аварий.

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

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