На этапе разработки сервисов BRM помогает в нескольких важных аспектах. BRM помогает заказчику сформулировать, в чем заключается ценность услуги, которую он хочет получить от ИТ. BRM бережно донесет и правильно расшифрует требования для ИТ-специалистов, поскольку заказчики часто затрудняются четко сформулировать свои требования, а сервис-провайдер не может их правильно интерпретировать. BRM продолжает эту работу при изменении требований, уточнении спецификаций и проектного решения. BRM применяет маркетинговый способ мышления («marketing mindset») и помогает ответить на три ключевых вопроса: какие задачи выполняет заказчик и как ИТ может им помочь; каких результатов хочет достичь заказчик; какие ограничения могут помешать достижению целей и как сервис-провайдер может с ними справиться.

Доля повторно открытых инцидентов может служить характеристикой качества работы процесса управления инцидентами. В идеале закрытие инцидента означает его полное решение и достаточную проверку эффективности решения. Рост доли инцидентов, которые потребовали переоткрытия, при прочих равных условиях свидетельствует об ухудшении качества работы процесса — снижается показатель First Time Resolution (FTR), что говорит о снижении рациональности процесса и увеличении необходимости переделок.

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

Отчет выделил три основных сценария: 1) Выживание предприятия преимущественно за счет реструктуризации и частичного сокращения бизнес-направлений; 2) Пережидание кризисного периода за счет эффективности, без существенного сокращения бизнес-направлений; 3) Активное расширение бизнеса, выход новых продуктов и услуг, экспансия на новые рынки.

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

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

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

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

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

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