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

Если все старые проблемы были решены, а новые зарегистрированы, то метрика принимает значение 1. Это происходит потому, что в этом случае количество открытых проблем по итогам периода (O) будет равно количеству новых проблем (N), так как все старые проблемы закрыты. Подставляя в формулу (N + C)/(N + C + O) и учитывая, что O = N, а C равно количеству закрытых старых проблем, получаем, что значение метрики будет равно 1. Это максимальное значение, которое показывает идеальную работу процесса управления проблемами за отчетный период.

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

Google использовала несколько методов для анализа эффективности менеджеров в рамках Project Oxygen: интервью с сотрудниками, анализ данных по методу «360 градусов» за несколько лет, специальные опросы уходящих из компании сотрудников, оценку поставленных KPI – оценку эффективности деятельности и оценку менеджера сотрудниками. Эти методы позволили получить комплексное представление о том, какие качества руководителей влияют на результаты команды, а какие приводят к снижению эффективности. Многократные проверки данных помогли определить восемь ключевых компетенций, которые теперь используются при обучении и оценке менеджеров в Google.

В ITIL Service Strategy упоминаются типы моделей аллокации затрат, такие как cost by service (аллокация по услуге) и cost by customer (аллокация по клиенту), но подробности их построения не рассматриваются.

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

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

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

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

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