Для корректного определения общего количества релевантных обращений для расчёта метрик FLR и FCR применяются несколько методов. Один из распространённых подходов предполагает, что специалисты второй или третьей линии при закрытии инцидента отмечают, мог ли он быть решён на первой линии. Для запросов на обслуживание заранее определяется, какая линия должна их решать, или применяется аналогичный подход с отметками специалистов. Также используется более "красивое" решение – применение моделей инцидентов, в которых заранее определяется, на какой линии должны решаться подобные инциденты. Этот атрибут затем используется для фильтрации инцидентов при формировании отчётности.

Разные технические услуги имеют общие зависимости от одних и тех же инфраструктурных компонентов. 'Технические услуги для технических услуг' повторяются регулярно: услуга 'Работоспособность сетей и каналов передачи данных' необходима для функционирования всех ИТ-систем, так же как услуги по поддержке СУБД, СХД и других стандартных инфраструктурных компонентов.

Роль Service Owner изначально является частью обязанностей CIO, так как руководитель ИТ-организации несет окончательную ответственность за все ИТ-услуги. По мере роста организации и увеличения количества услуг CIO может делегировать ответственность за отдельные услуги конкретным Service Owner'ам. Таким образом, Service Owner может рассматриваться как расширенная роль, делегированная CIO для управления конкретной услугой.

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

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

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

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

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

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

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