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

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

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

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

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

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

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

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

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

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