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

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

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

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

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

Некоторые компании используют отдельные инструменты для учёта активов и экономических расчётов, потому что их программное обеспечение изначально разрабатывалось как разделённое — например, HP имеет отдельные продукты для ITSM (HPSM с CMDB) и для управления активами (HP Asset Manager с AMDB). Также некоторые разработчики продуктов не хотят, чтобы их инструменты зависели от наличия развитых ITSM-решений у заказчиков, поэтому они делают свои системы независимыми. Однако это обусловлено программно-архитектурными ограничениями конкретных решений, а не общими рекомендациями или лучшими практиками. Такие решения не всегда отражают наиболее эффективный подход к совмещению функциональности.

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

BMC Remedy ITSM Suite оказалась единственным лидером в магическом квадрате Гартнера за 2010 год благодаря оценке ее как надежного и стратегически стабильного партнера, способного поддерживать долгосрочные отношения с корпоративными клиентами. Гартнер оценивает не только технические характеристики продукта, но и способность компании внедрять продукт на предприятиях, поддерживать его развитие и обеспечивать уверенность клиентов в долгосрочной перспективе. В то время как другие компании, такие как HP, IBM и CA, потеряли позиции из-за оценки их маркетинговой и продажной активности, а также стратегического видения развития продукта.

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

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