Service Request Management (SRM)
Что? Зачем? И почему это не «просто тикеты»?

Service Request Management (SRM) - обеспечивает выполнение рутинных запросов пользователей, чтобы они могли работать без лишних задержек.

Что такое сервисный запрос (или ЗНО - запрос на обслуживание)?
Это запрос пользователя на доступ к стандартизированным и предварительно одобренным услугам, информации, консультациям или рутинным изменениям. Отличительные черты:
▪️Предсказуемость: это не внезапный сбой, а ожидаемая потребность.
▪️Стандартизация: есть чёткий процесс выполнения.
▪️Низкий риск: обычно не приводит к критическим сбоям.

Примеры сервисных запросов
▪️сброс пароля, установка ПО, запрос нового оборудования, доступ к VPN.
▪️предоставление доступа новым сотрудникам, запрос оборудования, отзыв доступа при увольнении.
▪️настройка инструментов для отчётов.
▪️настройка мобильных устройств, доступ к Wi-Fi, выделение облачных ресурсов.

Что такое Service Request Management (SRM)?
Это процесс управления и выполнения запросов пользователей на IT-услуги. SRM - сердце ITSM, которое помогает оперативно и качественно обрабатывать запросы, от сброса пароля до выдачи нового оборудования.

Цель SRM: не просто закрыть запрос, а сделать это так, чтобы пользователь остался доволен, а поддержка не тратила лишнее время. Это про скорость, прозрачность и user-friendly подход.

Основные цели SRM:
1️⃣ Ускорить выполнение запросов.
Автоматизировать рутину, чтобы запросы решались в реальном времени.
2️⃣ Повысить удовлетворённость пользователей.
Прозрачные процессы и чёткая коммуникация создают позитивный опыт взаимодействия с IT.
3️⃣ Оптимизировать ресурсы IT-команды.
Категоризация и приоритизация помогают распределять задачи там, где они действительно нужны.
5️⃣ Обеспечить видимость и контроль.
Руководители видят статус запросов, тренды и узкие места, чтобы принимать взвешенные решения.
5️⃣ Двигать непрерывное улучшение.
Анализ данных запросов помогает находить проблемы и улучшать процессы.

Как работает процесс SRM?
Процесс SRM - это структурированный путь от подачи запроса до его выполнения. Всё ради удовлетворённости клиентов.

1️⃣ Запрос - через самообслуживания портал, почту, чат.
2️⃣ Логирование - уникальный ID, статус, трекинг.
3️⃣ Классификация - тип, команда, SLA.
4️⃣ Автоматизация - если можно - система делает сама.
5️⃣ Исполнение - человек вмешивается только там, где нужно.
6️⃣ Обратная связь - пользователь знает: «Всё готово».
7️⃣ Анализ - что можно автоматизировать/улучшить завтра?

Кто участвует?
▪️Пользователь/Клиент - подаёт запрос.
▪️IT-инженеры (L1/L2/L3) /Финансы/ИБ-специалисты - исполняет (или одобряет).
▪️ Менеджер процесса - настраивает процессы, каталог услуг, SLA

Приоритизация запросов: не всё сразу
Это основа управления очередями запросов. Она учитывает:
▪️Влияние: Насколько запрос важен для бизнеса?
▪️Срочность: Как быстро это нужно сделать?

Пример категорий:
▪️Критичный (P1): Запросы, влияющие на всю компания, от руководства (VIP-клиентов)
▪️Высокий (P2): Запросы, влияющие на целый отдел, важные проекты
▪️Средний (P3): Установка стандартного ПО
▪️Низкий (P4): Запрос информации, консультация

Что важно измерять?
▪️% автоматизированных запросов - чем выше, тем меньше рутины.
▪️Среднее время выполнения - если растёт, значит, что-то ломается.
▪️Удовлетворённость (CSAT/CDSAT) - пользователь доволен или злится?
▪️SLA - сколько заявок закрыты в срок.

Типичные ошибки
▪️Смешивают с инцидентами
Разные процессы. Разные цели.
▪️Нет self-service портала
Инженеры тонут в рутине.
▪️Нет каталога услуг
Каждый запрос - как первый.
▪️Не автоматизируют очевидное
Пароль сбросили 500 раз - и всё ещё вручную?
▪️Плохая коммуникация: пользователь не знает, на каком этапе его запрос, и теряет доверие.
▪️Игнорирование приоритизации: срочные запросы тонут среди незначительных.
▪️Отсутствие анализа: без обратной связи и метрик процесс не улучшается.

Итог:
Хороший SRM - когда никто не замечает поддержку
Потому что всё просто работает.
#SRM #ITSM #ITIL #TechSupport