optimusprinceps
Junior Member | Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Цитата:| Статусы можно свои добавлять Любые... |
На самом деле, если исходить из теории, то статусы должны быть именно те, которые там есть и никакие другие. Понятно, что ITIL\ITSM это есть просто рекомендации, но они не зря уже стали фактически стандартом. Дело в том, что каждый из этих статусов несёт за собой конкретный процесс и ведёт к определённым действиям, как со стороны Инициатора заявок, так и со стороны Исполнителя. Если добавить в этот список ещё статусы, то соответственно - это либо новые процессы, либо это просто мусор. В своё время на курсах по ITIL кто-то тоже задавал этот вопрос. И по итогу мы сами же на него и ответили - мы не смогли привести случая, когда заявка может иметь статус отличные от тех, которые есть по умолчанию.
Конечно, в данном ПО, да и не только в этом, есть возможность добавлять новые статусы, но как правило это делается просто от непонимания теории - реальной необходимости в этом как правило нет (если конечно оптимально настроены сам автоматизируемый этим ПО процесс).
Цитата:| Ну а если я не хочу этот статус использовать |
Опять же нужно вернуться к теории. Проблема не в том, что вы хотите, а что нет - под каждое "хочу" ПО написать очень дорого, стоить оно будет немеряно и конфигурить его Вы просто устанете. Возьмите внедерите у себя HP ServiceDesk 4.5 - там можно делать практически всё, но внедрение занимает минимум полгода. Цена же продукта - просто ппц.
Статус OnHold, используется в том случае, если заявку нужно поставить "на удержание". Дело даже не в остановке счётчика. дело в самом процессе и в цели для которой это сделано. Практически всегда может возникнуть ситуация, когда от Инициатора нужна доп. информация, которую он не может предоставить прямо сию секунду. Как раз в этом случае заявку ставят на OnHold. И, поверьте, это не просто блажь. Если заявка находится в статусе "Открыта", но фактически над ней Специалист не может начать работу, т.к. ему не хватает данных от Инициатора, то возникает момент, когда заявка не может быть Закрыта, как решённая и может висеть в данном статусе вечно, т.к. грубо говоря Инициатор вообще может забыть о том, что он кому-то что-то должен предоставить дополнительно, а ч ерез месяц он обратиться к руководителю поддержки с вопросом: "... собственно, а какого х... оно до сих пор открыта?". И вот здесь как раз статус OnHold разруливает данный конфликт.
Примеров конечно использования данного статуса можно привести массу, но смысл такой - заявка в статусе OnHold в некотором смысле снимает ответственность за сроки её решения (не зря она останавливает и таймер).
|
и не зря же есть две категории, где определяются статусы.. на этапе решения и этапе закрытия.. они могут дополнятся своими статусами, которые определены этапами процесса.. 
