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

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

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

Функциональные роли ресурсов, такие как СУБД, web-сервер, файл-сервер и другие, важны в модели CMDB потому, что именно с ними связаны специфичные единицы объёма потребления, затраты и зависимости мощности от обеспечивающих ресурсов. Например, СУБД может требовать определённого объёма вычислительных мощностей, памяти или дискового пространства, которые отличаются от требований простого сервера. Учёт этих ролей позволяет более точно планировать мощности и ресурсы, необходимые для обеспечения качества предоставляемых услуг, а также проводить анализ затрат на обслуживание каждой функциональной роли.

При прямом измерении удовлетворённости заказчика учитываются как warranty (гарантийные аспекты, связанные с надежностью, доступностью и безопасностью услуг), так и utility (полезность услуги, соответствие потребностям и функциональным требованиям). Такой подход позволяет оценить не только количественные показатели, прописанные в SLA, но и общее впечатление заказчика об услуге, а также соответствие реальных результатов его ожиданиям и бизнес-потребностям.

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

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

DevOps-метрики, которые можно соотнести с элементами Causal Loop Diagram, включают: Lead Time (Time to Market), Process Time (Process Time), Deploys per day (Release Rate), процент успешно реализованных изменений (% changes successfully implemented), процент полных и точных изменений (%C/A – percent complete and accurate), PIR Coverage Index, Mean time between release implementation, Percentage of Changes Without Recurring incidents, Total time of Major incidents caused by Releases, Number of defects per release, Average number of release units per release, Emergency Change Rate, Percentage of Changes Registered.

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

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