Ответственность за Outcome лежит на обеих сторонах. Поставщик должен предоставить качественный и подходящий Output, а потребитель — использовать его правильно и вовремя. Например, в случае дня рождения пекарня предоставляет торт (output), но родители должны его купить, поставить на стол и устроить праздник, чтобы дети были счастливы (outcome). Если одна из сторон не выполняет свои обязательства, outcome достигнут не будет.

Для управления задачами разной природы можно использовать вертикальное или горизонтальное разделение ресурсов. Вертикальное разделение предполагает чередование периодов: например, две недели на разработку, неделю на R&D, неделю на технический долг. Горизонтальное разделение заключается в выделении долей трудозатрат (например, 70% на развитие, 20% на эксплуатацию, 10% на исследования), с контролем результатов по каждому направлению. Однако такой подход требует четкого баланса, чтобы избежать формирования силосов и потери общей целостности команды.

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

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

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

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

Автоматизация рутинных операций положительно влияет на соотношение инцидентов и запросов на обслуживание, так как позволяет перевести многие типовые запросы в полностью автоматизированный режим или самобранчинг (self-service). Это сокращает общий объем обращений в сервис-деск и, в частности, объем запросов на обслуживание, обрабатываемых вручную, позволяя команде сосредоточиться на более сложных задачах, включая работу по предотвращению инцидентов. В результате автоматизация не только улучшает удовлетворенность пользователей за счет более быстрого выполнения стандартных операций, но и позволяет повысить стабильность систем за счет высвобождения ресурсов для проактивной работы по снижению количества инцидентов.

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

В разработке ПО часто возникает проблема с классификацией дефектов из-за нечеткого определения, что именно считать дефектом. Существуют полярные мнения: одни считают дефектом всё, что не устраивает заказчика, другие - только то, что признали разработчики как неработоспособность системы. Кроме того, отсутствие четко документированных требований создает пространство для интерпретации, когда возникают споры типа 'баг или фича'. Даже если требования есть, различные участники процесса могут по-разному трактовать одно и то же поведение системы. Эта неопределенность затрудняет создание единой системы классификации дефектов и приводит к играм вроде 'а ну-ка, докажи' или 'у нас не воспроизводится'.

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