В COBIT 5 проводится чёткое разграничение между процессами руководства и управления. Руководство (Evaluate, Direct, Monitor — домен EDM) осуществляется извне, как взаимодействие с управляемым объектом в режиме «черного ящика»: на вход подаются политики и требования, на выходе формируются отчеты. Управление же предполагает вмешательство во внутренние процессы, координацию деятельности и ресурсов для достижения целей. Таким образом, руководство задаёт направление, а управление непосредственно обеспечивает достижение результатов в рамках установленных требований.

Многие компании не достигают ожидаемых результатов по ускорению разработки, потому что внедряют Agile формально, без глубокого понимания и реализации всех необходимых изменений. Как отмечается, современная разработка часто сводится к 'половине Скрама сделанной плохо и использованию Jira', не затрагивая фундаментальных аспектов организации ресурсов, архитектуры, управления входящими задачами и организации производства. Для реального кратного ускорения необходим системный подход к преобразованиям, а не частичное внедрение отдельных практик без работы над основными препятствиями.

Снижение производительности может происходить на фоне изменений в характере использования системы, например, при резком увеличении количества операций или числа пользователей. Так, если при 1000 операциях в день отчет формируется за 5 минут, то при 10 000 операциях такое же время уже может не соблюдаться. Поэтому важно фиксировать условия, при которых выполняются требования к производительности, чтобы понимать, как система ведет себя при разных уровнях нагрузки и можно ли ожидать от нее стабильной работы в новых условиях.

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

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

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

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

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

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

В CleverENGINE 3.1 модуль визуализации CMDB значительно улучшен. Теперь при вызове визуализатора есть возможность запрашивать конкретное представление данных CMDB. Например, при вызове из услуги отображаются конфигурационные единицы (CI), от которых она зависит, а при вызове из CI можно выбирать, какие связи показывать на диаграмме, ориентируясь на категории CI: для лицензий одни связи, для серверов и ПО — другие, для документов — третьи. Также появилась функция «раскрывать» связи выделенных CI и услуг, что позволяет аналитику «прогуливаться» по ИТ-инфраструктуре, отображая нужные детали по мере необходимости. Это упрощает поиск сбойных CI, влияющих на услугу, и определение последствий отказа CI при работе с инфраструктурными инцидентами.