Для оценки удовлетворенности заказчика ИТ-услугами можно использовать опрос, содержащий ключевые вопросы, задаваемые заказчикам на регулярной основе. Например, вопросы о степени удовлетворенности достигаемойutility услуг, степени удовлетворенности достигаемой warranty услуг, и степени соответствия показателей warranty реальным потребностям заказчика. Ответы даются по шкале 0-1 (0 – полное несоответствие, 1 – полное соответствие), а для определения итогового показателя можно использовать взвешенное арифметическое усреднение. Такой подход обеспечивает прямое получение обратной связи от заказчика.

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

Эффективным методом является постоянное ответы на четыре базовых вопроса: Зачем? Что? Кто? Как? Такой подход применяется на каждом этапе — при определении бизнес-задач, процедур, элементов учёта и информационных объектов. Он позволяет отделить ключевые задачи от второстепенных, корректно выстроить процесс и ролевую модель, а также сформировать точные требования к инструменту автоматизации.

Для корректного расчёта Incident Rate необходимо собрать данные за год с разбивкой по месяцам, чтобы исключить сезонные колебания. В числитель включаются только пользовательские обращения, классифицированные как инциденты, за исключением инфраструктурных инцидентов. В знаменатель следует брать количество активных пользователей ИТ-системы, исключая уволенных сотрудников и технические учетные записи. Для этого рекомендуется использовать данные из справочника сотрудников, реплицированного из Active Directory в ITSM-систему.

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

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

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

ITIL 4 упрощает формулирование ключевых показателей эффективности (KPI) благодаря подробному описанию каждого фактора успеха практики (PSF) и предоставлению сопровождающих примеров метрик, которые можно использовать в качестве KPI. Описания практик в ITIL 4 стали более практико-ориентированными, что позволяет легче определить, какие показатели следует измерять для оценки эффективности конкретных практик в контексте их вклада в потоки создания ценности. В ITILv3 подход был более процесс-ориентированным, и, хотя концепция CSF также позволяла формулировать KPI, в ITIL 4 это становится проще благодаря более структурированному и конкретному описанию факторов успеха.

Концепцию услуги в ITIL4 можно объяснить с помощью модели CAAS (Choco-as-a-Service). В этой модели важно рассмотреть три компонента: товар (например, шоколадка), ресурс (магазин со службой доставки или автомат с шоколадками) и операции (процесс доставки или обслуживание автомата). В отличие от простой продажи товара, услуга предполагает, что клиент перекладывает на поставщика определенные риски и затраты. Например, при регулярной доставке шоколадок клиент не заботится о том, когда и где ее купить - эта ответственность лежит на поставщике. Аналогично в IT: при использовании облачных сервисов клиент не несет затрат по поддержанию физической инфраструктуры.

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