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

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

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

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

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

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

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

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

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

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