Во-первых, страницы ITIL, которые объясняют термин Запрос на обслуживание (Service Request), должны быть тщательно интерпретированы. Там утверждается, что Запросы на обслуживание управляются подобно Инцидентам, что - по моему опыту - абсолютно неверно (но может быть, я работал в плохой организации?). Поэтому я дам другое объяснение.
СервисДеск получает обращения типов Неудовлетворенность сервисом (Инцидент: "пожалуйста, выполняйте соглашение" или "восстановите сервис"), Изменения сервиса (мне нужно что-нибудь другое) и Запрос на обслуживание (мне нужно иное/больше чем в меню сервиса).
Запрос на обслуживание предопределен и согласован в сервисном контракте (СК). Это значит, что если клиент запрашивает структурное изменение согласованных уровней сервиса, подобно изменению типовых часов предоставления сервиса, это НЕ является Запросом на обслуживание. Вместо этого, должен быть изменен СК (SLA) и должны быть внедрены структурно новые спецификации сервиса.
Примерами регулярных запросов на обслуживание могут быть:
- Вопросы о функциональности
- Запрос о статусе
- Замена пароля
- Запрос на пакетное задание и авторизацию пароля
- Выборка из БД
- Запрос на обеспечение нового сотрудника соответствующими ИТ функциональностью/сервисами
Как можно видеть, этот список содержит действия, которые должны рассматриваться как изменение… Но на практике это не так, просто потому, что они были отнесены к запросам на обслуживание. И это потому, что организации решили сделать так, чтобы упростить усложненный процесс управления изменениями. Таким образом, процесс управления изменениями может быть зарезервирован для "настоящих" изменений, которые требуют сложного и тщательного управления в рамках процедуры изменений. Запросы на обслуживание тогда попадают в производственный процесс (production process): выборка из БД, предоставление запрашиваемой информации, изменение пароля и т.п.
Они могут быть перечислены в СК (SLA) с определенными уровнями сервиса(время исполнения, стоимость предоставления, другие параметры качества).Стандартизованные изменения проходят через другой поток работ (workflow): укороченную и упрощенную процедуру, но такую, которая включает запуск процесса управления конфигурациями. Они могут быть описаны в СК, но они также могут быть описаны только в руководстве по качеству ИТ организации.
Любые запросы на изменения (RFC), которые отнесены к таким стандартизованным изменениям, будут проще маршрутизироваться в стандартном потоке работ (workflow) (который называется "Change Model" in ITIL Service Support: параграф 8.3, страницы 170, 176)
Итак, запросы на обслуживание не являются изменениями и наоборот. Но каждый из них НЕ инцидент и НЕ может обрабатываться как инцидент. Они будут обрабатываться различными потоками работ.
Ян ван Бон - один из выдающихся авторитетов в управлении ИТ сервисами иработает в этой области с конца 1980 - х.
Он один из основателей форума по управлению ИТ сервисами (ITSMF) и фонда поуправлению ИТ сервисами в Голландии.
Ян ван Бон - главный редактор большого числа профессиональных ITSM изданий и отвечает за создание, продвижение и распространение многих публикаций и инноваций в этой области.
взято отсюда
P.S. Хоть это и касается V2, но объяснение вполне внятное
