Я начал разговор ещё до того, как поставил ITSM модуль и начал радоваться. До этого приоритеты были слабо автоматизированы.
В конечном итоге я хочу в общем числе добиться около 13 приоритетов, уже на основании всех sla, срочностей, и других параметров, а не в кажом sla
Ну да, все очереди на одном почтовом ящике, зачем клиентам писать на десять разных почтовых ящиков? они могут послать письмо не только из веб-морды, но и просто руками (если не работает вебморда). Зачем им тогда морока типа "Если у вас на работает ___, пишите туда, если не работает ___, пишите сюда" ?alexus писал(а):Проще (и мне кажется, правильнее) тикеты по очередям разным разделять. Все-таки у каждой очереди свой ящик почтовый. Или по RFC у вас идет переписка с ящика support @ 111.com? Да и еще есть моменты другие.Isenschtill писал(а):Практический смысл - таков, что если хелпдескеры по стечению обстоятельств занимаются не только своими заявками, но и методологическими, они имеют наглядную картину очередности выполнения тикетов, а так же их содержания. по приоритету сразу всё видно. Существуют так же межфункциональные работники повышенного левела.
Тем более, что количество очередей у нас нещадно вырастает, потому что один цикл ПО - от 2 недель до полугода, параллельно ведётся несколько проектов, на один проект приходится минимум 2-3 очереди.. а если я сделаю очередей вместо приоритетов - это будет.. очень много, очереди будут плодиться быстро.. да и какой смысл в этом псевдоприоритете? то на то и выходит, что в каждой очереди свой приоритет, и когда смотришь весь список, у тебя столько же приоритетов.
Ваше замечание корректно в общем случае, но в нашем частном случае таких чейнджей не бывает, а если и бывает - то наоборот, это заранее менее приоритетно, чем ошибка.alexus писал(а):RFC на 1 000 000 USD менее важен, чем "у меня сайт не работает!" (а на самом деле сетевой кабель переехало стулом)???Isenschtill писал(а):и уж конечно, в первую очередь надо обрабатвыать ошибки, а не запросы.
1) мы сами мониторим серверную часть, и если они навернулась, то всё понятно. Как правило, мы об этом узнаём раньше, чем пользователи начинают штурмовать хелпдеск.alexus писал(а):Убедили! 3 типа приоритетовIsenschtill писал(а):Далее - mass по смыслу можно отнести к vip, но если массовая ошибка затеряется среди виповских, ущерб от простоя будет гораздо больше, чем если бы она не затерялась! Но все же одна мысль теразет. А как вы прям так сразу определяете, что сбой массовый?
2) Анализ одной заявки может указать на то, что проблема серверной части не попала в мониторинг(например, это ошибка ПО а не железа), и мы понимаем, что это у всех. Как правило это самый распространённый тип.
3) большое количество одинаковых заявок в одно и то же время, банально..
Да, собрать отчёты можно по многим параметрам. Какие-то есть и штатно.. это уже отдельный разговорalexus писал(а):И вторая мысль - типы тикета "Disaster", "ServiceRequest", RFС, которые штатно присутствуют в системе наводят на размышления, что это можно использовать для классификации запросов в целях эффективной обработки и статистикиIsenschtill писал(а):Да и тем более что потом - можно собрать статистику - сколько раз произошёл массовый сбой (сделать выводы,втыки, принять меры, завести problem или change, в конце концов)..
И вот еще ссылка для обмена опытом http://www.realitsm.ru/2011/03/inc_prio ... d_targets/. Там очень умные люди тоже сражаются с приоритетами.
Спасибо за ссылку, буду воевать с приоритетами не только здесь
Цветов радуги на всех хватит.
Например, у каждой группы агентов свой цвет. у одних - Бордовый, красный, розовый. У других - тёмносиний, синий, светлосиний, итд. Сразу всё понятно, имхо.
