Выбор основывается на: 1) объеме данных (ручные методы неэффективны при высокой частоте процесса), 2) сложности формализации (субъективные оценки часто невозможно автоматизировать), 3) критичности ошибки (для высокорисковых зон предпочтительна автоматизация), 4) доступности ресурсов. Например, для массовых обращений с низкой сложностью регистрации подходит автоматизация, а для анализа качества коммуникации — опросы специалистов.

Правильная цепочка разработки KPI начинается с определения назначения процесса и его ключевых целей. Затем следует выявление ключевых практик, необходимых для достижения этих целей. После этого определяются метрики, которые будут измерять выполнение этих практик и показывать прогресс в достижении целей. Только на следующем этапе устанавливаются целевые и граничные значения для метрик. Последним этапом является переход к KPI как к интегральным показателям, которые используются для принятия управленческих решений. Эта цепочка: Назначение ⇒ ключевые практики ⇒ метрики ⇒ целевые и граничные значения ⇒ KPI.

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

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

Различие в подходах к управлению параметрами качества между ITIL и другими фреймворками объясняется разной философией построения процессных моделей. ITIL придерживается более детализированного подхода, разделяя близкие по смыслу, но потенциально конфликтующие процессы, чтобы каждому процессу можно было посвятить отдельное внимание без компромиссов. Другие фреймворки, такие как COBIT, могут объединять эти процессы для упрощения структуры управления, считая, что схожие аспекты можно эффективно управлять в рамках одного процесса. Это различие отражает разные стратегии: одна фокусируется на детализации и специализации, другая — на интеграции и упрощении.

Вспомогательная услуга в ITIL — это услуга, которая может быть незаметна для заказчика, но необходима для предоставления основной услуги. Часто её не различают от поддерживающей (обеспечивающей) услуги, считая оба термина синонимами. Обе они обеспечивают функционирование основной услуги, но не являются её центральной частью. Например, внутренние процессы или технологии, на которые клиент не обращает внимания, но без которых основная услуга невозможна.

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

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

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

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