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

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

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

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

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

Для внешних ИТ-систем, направленных на внешних клиентов, которые готовы платить за решение своих проблем, продуктовый подход подходит идеально, так как здесь присутствуют все три критерия: динамически меняющиеся возможности, высокая неопределенность в начале и необходимость активного развития. Для внутренних ИТ-систем, напротив, которые кастомизируются для автоматизации внутренних бизнес-процессов, продуктовый подход часто избыточен. Внутренние системы обычно имеют более фиксированные требования, целевая аудитория не платит за использование, и нет необходимости постоянно менять позиционирование или монетизацию. Применение таких инструментов как CustDev или retention metrics для внутренних систем отделов бухгалтерии или логистики становится нецелесообразным.

Традиционные KPI фокусируются только на соблюдении Tmax, игнорируя тот факт, что даже кратковременные простои вблизи лимита могут нанести бизнесу значительный ущерб. Например, при Tmax = 4 часа инцидент, устраненный за 3,9 часа, формально считается успешным, хотя за это время бизнес мог потерять клиентов или прибыль. Новый подход учитывает реальное влияние на операции через Tmin, что позволяет выстроить более справедливую систему оценки, ориентированную на реальные результаты, а не формальное соблюдение сроков.

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

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

Пример Twitter иллюстрирует необходимость разделения потоков ценности на основе инициативы по добавлению кнопки 'Купить'. Эта кнопка представляла собой отдельный вид бизнеса (торговую площадку для партнеров), а не просто техническую задачу добавления элемента интерфейса. Twitter, изначально основанный на рекламной модели, получил дополнительную ценностную составляющую. Пример показывает, что Twitter содержит как минимум три взаимосвязанных блока потоков: Community (коммуникационная платформа), Advertising (рекламный бизнес) и Marketplace (торговая площадка). Эти потоки создают разную по природе ценность: Community формирует аудиторию (измеряется в натуральных единицах), Advertising и Marketplace создают выручку (измеряются в финансах). При этом они сильно зависят друг от друга и могут конфликтовать за ресурсы.