Для расчета интегрального показателя качества для множества услуг рекомендуется сначала разделить все услуги на группы по степени их важности: mission-critical, business-critical и обычные. Для каждой группы рассчитывается свой интегральный показатель, возможно, с использованием разных методов агрегирования. Например, для mission-critical услуг можно применять среднее геометрическое, так как здесь каждая метрика критически важна. Для business-critical услуг подойдет среднее арифметическое. Затем полученные групповые показатели объединяют в общий интегральный показатель с использованием среднего арифметического или геометрического, возможно, с присвоением различных весов каждой группе в соответствии с их важностью для бизнеса.

В практике управления инцидентами термины 'Critical Incident' и 'Major Incident' часто используются как синонимы, но имеют некоторые различия в трактовке. 'Major Incident' (Значительный инцидент) в ITIL определяется как инцидент с наивысшей категорией влияния, вызывающий существенные потери для бизнеса. Основной акцент делается на необходимости применения специальной процедуры управления, выходящей за рамки обычных процедур. Термин 'Critical Incident' может относиться к инцидентам, критическим для функционирования отдельных систем или компонентов, но не обязательно имеющим широкое влияние на весь бизнес. Таким образом, все Critical Incidents не обязательно являются Major Incidents, но Major Incidents всегда имеют критическое влияние на бизнес в целом.

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

В HP OpenView Service Desk используется, по мнению автора, более рациональное деление по сравнению с HP SM или BMC Remedy ITSM Suite. В OpenView деление сделано по принципу различия между инфраструктурными инцидентами и обращениями пользователей, в то время как в других системах деление чаще проводится между инцидентами и сервисными запросами. В реальной практике разница в обработке инцидента, поданного пользователем, и сервисного запроса, поданного пользователем, не так велика, как разница между инфраструктурным инцидентом и обращением пользователя. Это подразумевает разную классификацию, разные процедуры выявления/регистрации и разные процедуры закрытия для этих двух основных типов случаев.

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

Реализация ITSM кардинально изменяет управление инцидентами, обеспечивая более обоснованные и чёткие нормативы. Меняется подход к классификации обращений пользователей, что требует переподготовки первой линии поддержки. Существенно усиливается потребность в эффективной координации устранения крупных инцидентов (major incidents) и регистрируются инфраструктурные инциденты для контроля доступности услуг.

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

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

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

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