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

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

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

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

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

Время реакции группы на назначение инцидента (время с момента назначения до переназначения в другую группу или окончания работы) включено в параметр ti, который представляет собой общее время обработки i-го инцидента силами данной группы. Чем дольше группа реагирует на назначенный инцидент, тем больше значение ti, а следовательно, тем больше доля группы во времени обработки и тем ниже её KPI в случае просрочки. Поэтому метрика стимулирует группы оперативно приступать к работе над назначенными инцидентами, даже если инцидент был передан уже близко к окончанию срока.

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

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

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

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