Завоевание доверия бизнеса является критически важной задачей для BRM, потому что наличие доверия кардинально меняет динамику взаимодействия. Когда бизнес доверяет сервис-провайдеру, единичные провалы в соблюдении SLA не становятся критическими и не приводят к разрушению отношений. Доверие позволяет выстраивать более открытый и конструктивный диалог, когда бизнес готов воспринимать объективные ограничения и сложности, с которыми сталкивается сервис-провайдер. Доверие создает прочную основу для долгосрочного партнерства, где заказчик воспринимает поставщика услуг как стратегического партнера, а не просто исполнителя, что в конечном итоге способствует повышению общей удовлетворенности и стабильности сотрудничества.

Уровень зрелости процесса по модели COBIT 5 PAM определяется не количеством или формальным оформлением документов, а фактом систематического выполнения управленческих практик и наличием подтверждающих свидетельств. Документы рассматриваются как один из возможных источников доказательств, но не как обязательное условие. Если управление процессом организовано эффективно и стабильно, то будут существовать реальные свидетельства его работы — будь то планы улучшений, результаты измерений, записи встреч или устные подтверждения от участников. Формальные документы без реальной деятельности не создадут устойчивой способности процесса достигать целей и будут выявлены оценщиком как недостаточные или несоответствующие.

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

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

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

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

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

Стандарт ISO/IEC 20000:2011, раздел 8.1, предъявляет следующие требования к управлению значительными инцидентами: поставщик услуг должен документировать и согласовать с заказчиком определение значительного инцидента; значительные инциденты должны классифицироваться и обрабатываться в соответствии с документированной процедурой; информация о значительных инцидентах должна доводиться до топ-менеджмента; топ-менеджмент должен назначить ответственного за управление каждым значительным инцидентом; после восстановления согласованного уровня услуг должен быть проведен анализ инцидента с целью определения возможностей по улучшению. Эти требования направлены на обеспечение четкого и эффективного управления кризисными ситуациями, которые существенно влияют на бизнес-процессы заказчика.

Пересмотр ролевой модели необходим при следующих изменениях: 1) Изменение ИТ-ландшафта — замена или вывод систем из эксплуатации, что ведёт к изменению набора системных ролей (например, при переходе от кастомного решения к дистрибутивному). 2) Изменение бизнес-процессов — появление новых операций или объектов, требующих корректировки ролей в нескольких системах одновременно. 3) Изменение организационной структуры — слияние, разделение подразделений или изменение их функций, что влияет на распределение бизнес-ролей между отделами. Например, при объединении департаментов бизнес-роли могут комбинироваться ('старое-новое'), а при создании нового подразделения формируется уникальный набор ролей ('новое').

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