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

Эффект Даннинга-Крюгера — это когнитивное искажение, при котором люди с низким уровнем компетентности в определенной области не осознают своей некомпетентности и, наоборот, переоценивают свои способности. В контексте ИТ-отделов это проявляется в том, что разработчики или члены бизнес-команды не понимают глубины своих знаний, что приводит к ошибочным решениям, несоответствию ожиданий и реальности, а также к неэффективным процессам. Например, в тексте описывается случай, когда разработчик заявил: «Да что там разбираться?! Пока не читал. Сели и пишем, чего там», что явно демонстрирует иллюзию компетентности и приводит к снижению качества работы и задержкам.

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

Сотрудники обычно ассоциируют перегрузку с интенсивностью труда — тем, насколько много и быстро они работают. Однако низкая производительность часто связана не с недостатком усилий, а с неэффективной организацией труда, отсутствием правильных инструментов или процессов. Когда сотрудник говорит, что он перегружен, это может означать, что его работа недостаточно оптимизирована или что он выполняет задачи, которые можно автоматизировать или распределить иначе. Интенсивность не равна результату: много бегать по заявкам не означает, что всё делается качественно и полезно.

Операционные затраты (OPEX) составляют 67-68% от общего объема затрат на ИТ в среднем по компаниям. В банках этот показатель выше — 76-79% (по данным за 2015 год), тогда как международная банковская статистика (Computer Economics) приводит цифру около 73%. Российские компании обычно демонстрируют более низкий уровень операционных затрат — 55-60%, но кризисные условия способствуют их росту за счет сокращения инвестиционных программ.

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

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

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

В ITIL определены несколько ролей в области управления изменениями: Владелец практики (Practice owner) - отвечает за общее управление, развитие и стратегическое направление практики; Менеджер изменений (Change manager) - управляет всеми аспектами практики 'Поддержка изменений', включая управление жизненным циклом отдельных изменений; Координатор изменений (Change coordinator) - выполняет те же обязанности, что и менеджер изменений, но в ограниченном контексте; Председатель Консультативного совета по изменениям (CAB chair); Участники Консультативного совета по изменениям; Инициатор изменений. Роли могут комбинироваться в зависимости от размера и структуры организации.

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