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

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

Жизненный цикл процесса в COBIT 5, включающий этапы планирования, приобретения, построения/приобретения/создания/внедрения, использования/эксплуатации, оценки/мониторинга и обновления/утилизации, может быть упрощен до цикла Деминга (PDCA). В этом случае этапы планирования, создания плана и постановки целей соответствуют фазе Planning (Планирование), этапы создания и внедрения - фазе Doing (Делание), этапы мониторинга и отчетности - фазе Checking (Проверка), а планирование совершенствования процесса - фазе Acting (Действие). Это упрощение сохраняет смысл и позволяет оценивать зрелость процесса по полноте реализации цикла PDCA, что является основой для подходов оценки зрелости, таких как CMMI-SVC и COBIT PAM.

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

Основная цель системы Kanban, разработанной на производстве Toyota, заключалась в организации вытягивающего типа производства для построения системы «точно-во-время» (just-in-time, JIT). Это достигалось за счёт использования карточек для сигнализации между участками производственной цепочки. Когда на одном участке приближалось завершение производства или достижение определённого порога, карточка отправлялась предыдущему участку, указывая необходимость изготовления следующей порции продукции. Такой подход позволяет минимизировать складские запасы, избежать избыточного производства и повысить скорость выпуска продукции, так как материалы поступают именно тогда, когда они требуются для дальнейшей обработки.

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

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

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

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

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