ITIL: Инциденты и запросы на обслуживание - одно и то же или нет?

Во-первых, страницы 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, но объяснение вполне внятное

В чем различие между Инцидентом и Запросом?

Q: What is the difference between incident and a service request?

A: Incident is not planned and means that the service is disrupted, Service Request has a planned process or procedure ready to be executed, for example password reset.

I will explain you with an example.
1. Service Request -> Request for a new PC
2. Incident -> My PC is not working
In certain conceptions request for a new PC could be classified as Change Request.

Thus, some examples of Service requests would be...
Add toner to the printer
Run a report
Etc.

Мониторинг ИТ инфраструктуры V.2

Радикально обновил блок информационных материалов по теме. С акцентом на продуктовую линейку CA.

1. Концепция
• Технико-экономическое обоснование
• Последовательность этапов внедрения
2. Service Desk
• Типовые требования
• Описание системы
• Базовый проект по внедрению
3. Мониторинг ИТ инфраструктуры
• Типовые требования
• Описание CA Spectrum
• Описание CA eHealth
• Описание пилотного проекта
• Базовый проект по внедрению
• Вопросы-ответы
4. Мониторинг приложений
• Мониторинг Java\.NET приложений

ITIL: в чем разница между инцидентом и проблемой

Искал наглядный ответ. И вроде как нашел.

OK, here is an example:
A user's PC freezes and she raises an incident at the service desk. Service desk tells her to reboot and the incident is fixed.

A few days later, her PC freezes again and Service desk notice that it happened a few days before as well. Service desk raises a problem record, because rebooting the PC only solves the incident temporarily and it does ot fix the root cause of whatever is casuing the PC to freeze. The problem record gets assigned to 2nd line support to do root cause analysis on what is causing the PC to freeze. They find to be a specific application and the problem ebcomes a known error. A change request gets raised to install a patch from the vendor of the application on the user's PC. If the patch is installed succesfully, the problem and all related incidents are resolved.

====================================

I sometimes find that giving the textbook answer does not always clarify the difference though. I think it is also important to stress that the difference is how we deal with each one
- Incidents... quick turnaround, get the user back up and running
- Problems... require more time, only worth dealing with if the cost of implementing the fix is less than that of communicating and implementing the workaround.

e.g. something that affects one client once per week and is fixed within 5 mins is not worth logging as a problem in many cases.