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

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

В ITIL 4 управление запросами на обслуживание рассматривается как отдельная практика, отличная от управления инцидентами. В отличие от инцидентов, запросы на обслуживание являются "обычной" частью предоставления услуг. Основные особенности включают создание моделей запросов на обслуживание во время проектирования продуктов и услуг, а не после возникновения запросов. Практика управления запросами на обслуживание задействована на всех этапах жизненного цикла услуг. Для удобства пользователей запросы на обслуживание обычно включаются в пользовательские представления каталога услуг. Каталог запросов содержит информацию о доступных запросах, предварительных требованиях, необходимой информации для инициирования запроса, процессе утверждения и целевом времени выполнения. Это позволяет стандартизировать процесс подачи и выполнения запросов, делая его более прозрачным и предсказуемым для пользователей.

Основная сфера применения информации о связях КЕ — это планирование изменений (29% упоминаний). Также наблюдает тренд на расширение использования сервисно-ресурсной модели в расчёте себестоимости и определении потребности в мощностях. Это указывает на то, что организации всё чаще используют CMDB не только для базовых процессов управления изменениями, но и для более сложных аналитических задач.

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

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

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

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

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

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