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

Более рациональным представляется различие по источнику запроса (пользователь/инфраструктура), потому что в практической работе различия в обработке инцидента, поданного пользователем, и сервисного запроса, поданного пользователем, не так велики, как различия между инфраструктурным инцидентом и обращением пользователя. Деление по источнику запроса отражает реальные различия в классификации, методах выявления/регистрации и процедурах закрытия. Подход, выделяющий инциденты и сервисные запросы, часто ведет к спорам о классификации и превращает технические вопросы в организационные проблемы, особенно когда разные типы запросов управляются разными процессами и ответственными.

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

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

Менеджер процесса должен владеть методологиями процессного управления, такими как BPMN (Business Process Model and Notation) для моделирования процессов, подходами к анализу и оптимизации процессов (например, методы 6 Sigma, Lean), уметь работать с метриками и KPI процессов, знать основы постановки целей процессов и их измерения, уметь применять специализированные инструменты для визуализации и анализа процессов (например, ARIS, Bizagi). Также важны навыки работы с общими management-инструментами: SWOT-анализ, постановка SMART-целей, матрица ответственности.

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

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

SPOC (Single Point of Contact) в контексте поддержки пользователей — это концепция, при которой каждому набору пользователей или ИТ-услуг назначена единая точка контакта. Эта точка может быть представлена отдельной узкоспециализированной группой, которая обеспечивает поддержку пользователей, взаимодействующих с определенными ИТ-решениями. Такой подход устраняет необходимость наличия общей централизованной службы, так как каждая специализированная группа самостоятельно выступает в роли точки контакта для своих пользователей.

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

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