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

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

Применение сервисного подхода требует участия как поставщика услуг, так и заказчика, потому что ценность услуг определяется именно со стороны заказчика. Одностороннее применение сервисного подхода поставщиком услуг без учета потребностей и восприятия заказчика приводит к ситуации, когда услуги становятся «навязанными» и не приносят никакой пользы ни одной из сторон. Взаимное понимание необходимо для того, чтобы определить, что именно заказчик считает ценным и какие функции он воспринимает как услуги.

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

Согласно второму принципу DASA, важность ориентации на конечный результат (Create with the End in Mind) заключается в отказе от водопадного подхода и процессно-ориентированных моделей, где сотрудники выполняют только конкретные функции без понимания общей картины. Вместо этого компании должны действовать как продуктовые организации, явно сфокусированные на создании продуктов для реальных заказчиков. Это требует, чтобы все сотрудники понимали полный контекст создания продукта и представляли его конечными пользователям. Такой подход позволяет более эффективно выстраивать процессы, минимизировать разрыв между отделами и обеспечивать создание ценности для клиентов с самого начала процесса разработки.

PCF был разработан в 1992 году Американским центром эффективности и качества (APQC), который продолжает поддерживать и развивать этот стандарт. Текущая версия PCF - 6.1.0, выпущенная в марте 2014 года. APQC является автором и поддерживающей организацией данного стандарта, обеспечивающей его постоянное развитие и адаптацию к меняющимся требованиям бизнеса.

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

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

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

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