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

Процесс управления доступом можно автоматизировать путем создания наборов типовых полномочий и стандартных ролей в информационных ресурсах, которые объединяются по подразделениям организации. Это позволяет автоматически назначать доступы в соответствии с должностными обязанностями сотрудников без необходимости прохождения полной цепочки согласования для каждого запроса. Также можно внедрить предварительно согласованные маршруты утверждения для типовых запросов, использовать системы управления идентификацией и доступом (IAM), которые автоматически проверяют соответствие запросов политикам безопасности и принципу разделения обязанностей. Автоматизация ускоряет процесс предоставления доступа и снижает риск человеческой ошибки.

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

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

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

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

Одним из KPI для оценки эффективности коммуникации в процессе Управления инцидентами является «Среднее число звонков на Service Desk и прочих контактов со стороны бизнес-пользователей по поводу уже зарегистрированных инцидентов». Этот показатель измеряет, насколько эффективно обеспечивается прозрачность процесса: чем меньше у пользователей потребность в повторных обращениях за информацией об уже зарегистрированных инцидентах, тем выше качество коммуникации. Низкое значение этого KPI свидетельствует о том, что пользователи своевременно и в нужном формате получают информацию о статусе инцидентов, что приводит к повышению их удовлетворённости и снижению нагрузки на Service Desk.

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

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

Рефакторинг кода может не привести к ожидаемому результату из-за недостаточного понимания задачи исполнителем и эффекта Даннинга-Крюгера. В тексте приводится пример, когда команда обсудила план рефакторинга, но через месяц выяснилось, что исполнитель просто переносил проблему в другой слой системы, вместо того чтобы решать её. Это произошло потому, что человек не осознавал своей недостаточной компетентности в вопросе рефакторинга, считая, что его действия приведут к улучшению кода. Автор отмечает, что такой случай не уникален: «каждый человек понимает «в меру своей испорченности», переоценивает свои умения, не понимая истинной глубины своей некомпетентности». Поэтому важно не только обсудить план, но и обеспечить постоянный контроль и коммуникацию в процессе выполнения задачи.