ITIL. IM и CM

Нужно больше сокращений.

новое рабочее место

New Work Place — NWP

неисправный жесткий диск

Faulty Hard Disk Drive — FHDD

сервере

Terminal Server — TS

операционную систему

OS

папку со звукозаписями

Sound Asset Library — SAL

лишь бы что-то ляпнуть

if only something to blurt out - IOSBO

я конечно далёк от ITIL(учитывая что на его внедрение начальство тупо не пойдет), но ИМХО только пункт 2 можно назвать инцидентом.

Позвольте полюбопытсовать к какому процессу ITIL Вы отнесли бы эту деятельность к управлению инцидентами или изменениями.

Всё описаное относится к change management, но может инициироваться incident management если это требуется для устранения инцидента.

Почитай описание после картинки: http://www.computereconomics.com/article.cfm?id=1074

P. S. Не путаем инцидент с проблемой, да?

Организовать новое рабочее место. Подключить оператора к ИС;

Это просто SR или OPR, или вообще BAU.

Заменить неисправный жесткий диск в сервере;

BreakFix CR. Может инициироваться инцидентом или сама замена в рамках инцидента.

Обнвоить операционную систему на сервере kf54;

Если security-хотфиксы поставить - то CR. А если обновить ОС - так не делают в энтерпайзе. Правильно - два отдельных реквеста на decommission старого сервера и заливку нового.

Расшарить папку со звукозаписями АТС в сеть для Иванова ИК;

Обычно такое автоматизируется в self-service нафик.

Добавить новый коммутатор в стек.

Infrastructure CR

Почитай описание после картинки: http://www.computereconomics.com/article.cfm?id=1074

Картинка по делу!

Не путаем инцидент с проблемой, да?

Конечно нет

Всё описаное относится к change management, но может инициироваться incident management если это требуется для устранения инцидента.

Именно так. Это вносимые изменения в инфраструктуру. Вопрос к оргнизации билинга. Сейчас появился новый взгляд. (у нас ИТ выведен из предприятия занимающегося основной деятельностью) Любой инцидент должен быть связан с измненением, практически. Просто изменения вызванные инцидентом это одно, а вызванные запросом на обслуживание по другому учитываться должны. Они должны быть выведены из Абон. платы.

Ну, а как по процессам ITIL это пустить.

И в чем вопрос?

Я плотно имел дело с тех. поддержкой; не по ITIL, но очень похоже. Анализ инцидента/проблемы по заявке делали всегда мы. В контракте четко описывалось (и от этого зависила цена), внедрением занимаемся мы или кастомер; в последнем случае мы просто говорим что должно быть сделано - рекомендацию.

CR'ы не связанные с incident management/problem management у нас в любом случае оплачивались.

Получается, что в случае, если по контракту мы даем только рекомендацию как устранить инцдент/проблему, а заказчик не хочет сам это внедрять, то он может заказать CR (ну, и SLA там другие). Знаю, есть модели, где в абонплату входит договоренное число CR'ов (обычно определенного типа или лимитируются man-day'и, тут вариантов много).

Это в общих чертах.