BRM участвует на всех основных этапах жизненного цикла услуги согласно ITIL. На этапе Service Strategy BRM держит руку на пульсе бизнеса заказчика, знает его задачи и изменения в деятельности, помогает коммуницировать стратегические цели заказчика ИТ-специалистам. На этапе Service Design BRM помогает сформулировать ценность услуги для заказчика и правильно расшифровать требования ИТ-специалистам. На этапе Service Transition BRM обеспечивает вовлечение заказчика в тестирование и передачу/приемку услуги. На этапе Service Operation BRM следит за тем, чтобы заказчик получал ожидаемую ценность и удовлетворенность, управляя процессом обработки жалоб. На этапе CSI (Continual Service Improvement) BRM определяет возможности по оптимизации услуги и участвует в service reviews для постоянного улучшения предоставляемых сервисов.

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

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

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

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

Мандатная модель (MAC) предполагает жёсткую привязку пользователей и информации к уровням допуска (например, 'секретно', 'совершенно секретно'). Все ресурсы одного уровня автоматически доступны всем, у кого есть мандат на этот уровень. Основной недостаток — негибкость: добавление новых классов секретности усложняет систему. Дискреционная модель (DAC) настраивает доступ на уровне отдельных объектов и операций для каждого пользователя через матрицу разрешений (таблицы доступа). Это даёт максимальную детализацию, но требует громоздкого администрирования при росте системы. Ролевая модель (RBAC) группирует права в бизнес-роли (например, 'бухгалтер', 'менеджер'). Пользователи получают доступ через назначение ролей, а не прямое управление объектами. Это сочетает структурированность (как в MAC) и управляемость (лучше, чем в DAC), так как изменения в правах вносятся на уровне ролей, а не пользователей. RBAC также поддерживает иерархию ролей и разделение полномочий, что недоступно в других моделях.

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

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

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

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