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

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

Заказчики не любят платить за 'гарантию' услуг, потому что это невидимая часть сервиса, которая сама по себе не создает прямой полезности для бизнеса. Люди склонны ценить и готовы платить только за то, что они видят и непосредственно используют - например, за работоспособное приложение или доступ в интернет. Гарантия, обеспечивающая надежность, безопасность, соответствие SLA и другие параметры, проявляет себя только тогда, когда чего-то не происходит (сбоев, нарушений безопасности), и поэтому ее ценность сложно оценить. Кроме того, для оценки гарантии нужны знания и опыт, которые обычно отсутствуют у заказчиков, что делает эту часть услуги менее понятной и менее ценной в их глазах, даже несмотря на то, что без нее полезность не может быть стабильно предоставлена.

Выбор стандарта зависит от цели расчетов. Для внутренней технической оценки надежности компонентов сети (например, оборудования) рекомендуется использовать ГОСТ Р 53480-2009, так как он фокусируется на физических характеристиках систем. Для управления ИТ-услугами и взаимодействия с заказчиками предпочтительнее ITIL и ISO/IEC 20000, где акцент сделан на доступность услуги в контексте бизнес-процессов. На практике часто применяются оба подхода: ГОСТ для технических отчетов, ITIL — для коммуникации с клиентами.

Преимущество уточнённого определения Nj при расчёте FTR заключается в том, что оно позволяет точно отразить качество работы каждой отдельной рабочей группы. Учитывая только завершённые обращения (Cj + Sj), метрика исключает влияние незаконченных процессов, которые могли бы исказить результат. Это обеспечивает прозрачность и точность измерения эффективности групп, что важно для выявления слабых мест и оптимизации процессов управления инцидентами.

Процесс руководства в COBIT 5 рассматривается как деятельность, осуществляемая извне относительно управляемого объекта, потому что руководство взаимодействует с объектом как с «черным ящиком»: на вход подаются требования, правила и политики, а на выходе формируются отчеты о результатах. Руководство не вмешивается в детали реализации процессов, не управляет ресурсами напрямую, а фокусируется на достижении стратегических целей и соблюдении интересов заинтересованных сторон. Таким образом, руководство определяет направление и контролирует результат на высоком уровне, оставляя детали реализации функции управления.

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

Мощность как компонент Warranty определяет, насколько услуга обладает достаточным запасом ресурсов для удовлетворения потребностей всех пользователей в пиковые периоды нагрузки. Высокая мощность означает, что услуга может справиться с максимальной нагрузкой без ухудшения качества. Например, для электрического света недостаточная мощность проявляется в том, что свет горит тускло, когда включено много приборов, так как электричества не хватает для всех устройств. В ИТ-услугах недостаточная мощность может проявляться в медленной работе приложения при большом количестве пользователей или низкой скорости соединения через VPN. Мощность критически важна для пригодности услуги к использованию, так как даже при наличии самой полезной услуги (высокая Utility) недостаточная мощность делает ее неудобной или невозможной для использования в реальных условиях.

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

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