Фаза problem control (PC) включает диагностику проблемы, определение ее корневой причины и вариантов решения. Эта фаза заканчивается, когда определены возможные решения проблемы. На противоположной стороне находится фаза error control (EC), которая начинается после диагностики и включает реализацию выбранного решения, проверку его результативности и, при необходимости, контроль известной ошибки. Разделение происходит в момент завершения диагностики, когда переход к error control означает переход от поиска решения к его внедрению.

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

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

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

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

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

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

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

Для оценки результатов PIR применяются инструменты бизнес-аналитики (на пример, Power BI, Tableau), которые визуализируют данные по KPI, бюджету и срокам. Также используются опросники (например, SurveyMonkey) для сбора обратной связи от пользователей. В ИТ-сфере активно задействуются мониторинговые системы (Nagios, Zabbix), чтобы оценивать технические показатели после внедрения изменений.

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