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

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

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

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

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

Фраза 'Целое больше суммы его частей', приписанная Аристотелю, является основой целостного подхода, подчеркивающего, что никакая услуга, практика, процесс, отдел или поставщик не существуют в одиночку. Это означает, что организация должна работать интегрированным образом, управляя своей деятельностью в целом, а не отдельными ее частями. Данный принцип отражен в руководящих принципах ITIL 4, в частности в принципе 'Используйте целостный подход' (Think and work holistically). При таком подходе важно понимать, как все части организации работают вместе интегрированным образом, а услуги предоставляются посредством координации всех необходимых компонентов без выборочного внимания к отдельным элементам системы.

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

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

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

В ITIL указано, что роли в управлении изменениями могут быть объединены различным образом в зависимости от организационного контекста. Например, небольшие организации могут объединить обязанности владельца процесса управления изменениями, менеджера процесса, администратора изменений и председателя Консультативного совета по изменениям (CAB) в одну роль - менеджера изменений. В более крупных организациях эти функции обычно распределяются между различными специалистами. В ITIL4 с введением роли менеджера изменений как специфической для практики 'Поддержка изменений' также допускается сочетание его обязанностей с координатором изменений для работ в ограниченном контексте, в зависимости от структуры организации и масштаба изменений.