Противоречие заключается в том, что процессы EDM01 и EDM05, которые должны описывать управление системой руководства ИТ, следуют той же структуре практик (оценка, направление, мониторинг), что и процессы руководства системы управления ИТ (например, EDM02–EDM04). При этом в COBIT 5 проводится чёткое разграничение между руководством и управлением. Если процессы EDM01 и EDM05 представляют собой процессы управления системой руководства, их структура должна быть ближе к управленческим циклам, например, PDCA (планирование-реализация-оценка-корректировка). А если это процессы руководства, тогда возникает вопрос о том, кем и в чьих интересах осуществляется руководство над системой руководства, что представляется избыточным.

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

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

Практические упражнения, помогающие понять разницу между товаром и услугой, включают в себя анализ примеров из реальной жизни с акцентом на выявление рисков и затрат, которые клиент перекладывает на поставщика. Например, участникам предлагают взять простой товар (шоколадку, автомобиль) и преобразовать его в услугу, определяя: 1) Какие риски и затраты клиент может переложить на поставщика; 2) Какие ресурсы необходимы для предоставления услуги; 3) Какие операции должен выполнять поставщик. Другой вариант упражнения - анализ существующих бизнес-моделей (каршеринг vs покупка автомобиля, аренда жилья vs покупка квартиры) и выделение компонентов услуги: товара, ресурса и операций. Эти упражнения помогают участникам глубже понять концепцию услуги в рамках ITIL4.

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

Термин Service Capacity Management не рекомендуется использовать как фиксированное название подпроцесса, потому что понятие «услуга» может относиться к разным уровням: бизнес-процессам, ИТ-системам или ресурсам. Это приводит к путанице в терминологии и не позволяет четко определить уровень, на котором происходит управление мощностями. Вместо этого предлагается использовать термины, отражающие конкретный уровень: Business, System или Resource Capacity Management.

Полная автоматизация в Definition of Done согласно DevOps дает следующие преимущества: 1) Снижение ошибок, вызванных человеческим фактором; 2) Ускорение циклов разработки и развертывания; 3) Повышение надежности и воспроизводимости процессов; 4) Раннее обнаружение и исправление дефектов; 5) Упрощение процесса масштабирования; 6) Повышение удовлетворенности команды за счет уменьшения рутинных операций; 7) Возможность непрерывного улучшения продукта через регулярные небольшие обновления. Такой подход позволяет фокусироваться на создании ценности для пользователей, а не на организационных и технических сложностях процесса доставки.

Роль формального менеджера и неформального лидера в проектной команде отличаются по источнику авторитета и способу влияния на команду. Формальный менеджер имеет официальный статус, назначенный руководством, и обладает правом давать указания, распределять задачи и оценивать результаты работы. Он обычно отвечает за соблюдение сроков, бюджета и качества проекта. Неформальный лидер, напротив, приобретает авторитет благодаря личным качествам, опыту или уважению со стороны коллег, и его влияние строится на доверии и уважении, а не на должностных полномочиях. Неформальный лидер может возникнуть на любой роли в команде, даже на позиции, не предполагающей руководства (например, как руководитель каменоломни в игре 'Египет'). В то время как формальный менеджер часто фокусируется на процессах и выполнении задач, неформальный лидер может сильнее влиять на мотивацию и командный дух.

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

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