Приоритет
Добавлено: 20 дек 2011, 12:31
Коллеги,
подскажите, где и как настроить цвет приоритетов?
подскажите, где и как настроить цвет приоритетов?
Код: Выделить всё
.Flag span.PriorityID-1 {
background-color:#03c4f0;
}
.Flag span.PriorityID-2 {
background-color:#83bfc8;
}
.Flag span.PriorityID-3 {
background-color:#cdcdcd;
}
.Flag span.PriorityID-4 {
background-color:#ffaaaa;
}
.Flag span.PriorityID-5 {
background-color:#ff505e;
А в матрице 4х4 вы будете 16 приоритетов делать?Isenschtill писал(а): alexus
По-вашему, 5 приоритетов - это достаточно?
Матрица приоритетов - минимум 3х2, или 3х3, если она простая
Смотрите сами, запросы могут быть разного типа, что само по себе имеет приоритет, а так же срочность и влияние, уже вон сколько параметров. пока что меня устраивает шесть, хотя в моей практике я обычно не делал менее девяти.
А можно пример, если не из жизни, то приближенный к реальности?Isenschtill писал(а):Например, если разные группы агентов работают с заявками разного типа, то эти типы могут иметь определённые зоны приоритета, и внутри каждого типа приоритет тоже может меняться, например из-за срочности или влияния.
Каждый может видеть свой приоритет (который может быть обозначен словом, а не цифрой).
Например, у каждой из трёх разных функциональных групп, которые разгребают разные типы заявок, есть всего по три приоритета - обычный, срочный, и очень срочный. Они только по ним и работают. А руководители и координаторы наблюдают весь пул, и видят, что приоритеты 1-3 - это одна группа, 4-6 вторая, 7-9 третья. Очень удобно в общем пуле. Ну это стандартная ситуация, обычно внутри группы больше приоритетов.
Надо посмотреть группы и Настройки в Конфигурации системы (Ticket) - там отдельно про FreeText поля и про AddtlITSMFields - разберетесь, не должны были пропасть, где-то они есть - закон природы - если где чо-нибудь убыло в другом месте обязательно добавится. У меня есть и те и эти и мирно сосуществуют.Isenschtill писал(а): p.s. после установки ITSM 3.0.5 у меня пропали в заявках "свободные поля" и появились свободные ITSM поля, что не соответствует моим ранее настроенным кастомным полям. куда они делись, они же нужны мне
сами настройки freetext остались старыми, но я не вижу интерфейса взаимодействия
Практический смысл - таков, что если хелпдескеры по стечению обстоятельств занимаются не только своими заявками, но и методологическими, они имеют наглядную картину очередности выполнения тикетов, а так же их содержания. по приоритету сразу всё видно. Существуют так же межфункциональные работники повышенного левела.alexus писал(а):Я в вашей схеме увидел только два с половиной приоритета . Обычный и VIP. Mass по смыслу можно отнести к VIP. Какой практический смысл в создании приоритетов для каждого типа запросов? Что это дает? Кому от этого легче? Кто был инициатором такой схемы приоритетов и какие были аргументы?
Я задаю вопросы не ради троллинга. Просто приоритеты - одна из злободневных и неочевидных тем в ITIL. И есть разные мнения и решения.
Проще (и мне кажется, правильнее) тикеты по очередям разным разделять. Все-таки у каждой очереди свой ящик почтовый. Или по RFC у вас идет переписка с ящика support @ 111.com? Да и еще есть моменты другие.Isenschtill писал(а):Практический смысл - таков, что если хелпдескеры по стечению обстоятельств занимаются не только своими заявками, но и методологическими, они имеют наглядную картину очередности выполнения тикетов, а так же их содержания. по приоритету сразу всё видно. Существуют так же межфункциональные работники повышенного левела.
RFC на 1 000 000 USD менее важен, чем "у меня сайт не работает!" (а на самом деле сетевой кабель переехало стулом)???Isenschtill писал(а):и уж конечно, в первую очередь надо обрабатвыать ошибки, а не запросы.
Да запросто!Isenschtill писал(а):и, кстати, это очень круто будет, когда приоритеты сами будут выставляться в зависимости от клиента, сервиса, срочности и прочих параметров
Убедили! 3 типа приоритетов ! Но все же одна мысль теразет. А как вы прям так сразу определяете, что сбой массовый?Isenschtill писал(а):Далее - mass по смыслу можно отнести к vip, но если массовая ошибка затеряется среди виповских, ущерб от простоя будет гораздо больше, чем если бы она не затерялась
И вторая мысль - типы тикета "Disaster", "ServiceRequest", RFС, которые штатно присутствуют в системе наводят на размышления, что это можно использовать для классификации запросов в целях эффективной обработки и статистики .Isenschtill писал(а):Да и тем более что потом - можно собрать статистику - сколько раз произошёл массовый сбой (сделать выводы,втыки, принять меры, завести problem или change, в конце концов).
Ну да, все очереди на одном почтовом ящике, зачем клиентам писать на десять разных почтовых ящиков? они могут послать письмо не только из веб-морды, но и просто руками (если не работает вебморда). Зачем им тогда морока типа "Если у вас на работает ___, пишите туда, если не работает ___, пишите сюда" ?alexus писал(а):Проще (и мне кажется, правильнее) тикеты по очередям разным разделять. Все-таки у каждой очереди свой ящик почтовый. Или по RFC у вас идет переписка с ящика support @ 111.com? Да и еще есть моменты другие.Isenschtill писал(а):Практический смысл - таков, что если хелпдескеры по стечению обстоятельств занимаются не только своими заявками, но и методологическими, они имеют наглядную картину очередности выполнения тикетов, а так же их содержания. по приоритету сразу всё видно. Существуют так же межфункциональные работники повышенного левела.
Ваше замечание корректно в общем случае, но в нашем частном случае таких чейнджей не бывает, а если и бывает - то наоборот, это заранее менее приоритетно, чем ошибка.alexus писал(а):RFC на 1 000 000 USD менее важен, чем "у меня сайт не работает!" (а на самом деле сетевой кабель переехало стулом)???Isenschtill писал(а):и уж конечно, в первую очередь надо обрабатвыать ошибки, а не запросы.
1) мы сами мониторим серверную часть, и если они навернулась, то всё понятно. Как правило, мы об этом узнаём раньше, чем пользователи начинают штурмовать хелпдеск.alexus писал(а):Убедили! 3 типа приоритетов ! Но все же одна мысль теразет. А как вы прям так сразу определяете, что сбой массовый?Isenschtill писал(а):Далее - mass по смыслу можно отнести к vip, но если массовая ошибка затеряется среди виповских, ущерб от простоя будет гораздо больше, чем если бы она не затерялась
Да, собрать отчёты можно по многим параметрам. Какие-то есть и штатно.. это уже отдельный разговорalexus писал(а):И вторая мысль - типы тикета "Disaster", "ServiceRequest", RFС, которые штатно присутствуют в системе наводят на размышления, что это можно использовать для классификации запросов в целях эффективной обработки и статистики .Isenschtill писал(а):Да и тем более что потом - можно собрать статистику - сколько раз произошёл массовый сбой (сделать выводы,втыки, принять меры, завести problem или change, в конце концов).
И вот еще ссылка для обмена опытом http://www.realitsm.ru/2011/03/inc_prio ... d_targets/. Там очень умные люди тоже сражаются с приоритетами.
Коллеги, выручайте )yuri0001 писал(а):Надо посмотреть группы и Настройки в Конфигурации системы (Ticket) - там отдельно про FreeText поля и про AddtlITSMFields - разберетесь, не должны были пропасть, где-то они есть - закон природы - если где чо-нибудь убыло в другом месте обязательно добавится. У меня есть и те и эти и мирно сосуществуют.Isenschtill писал(а): p.s. после установки ITSM 3.0.5 у меня пропали в заявках "свободные поля" и появились свободные ITSM поля, что не соответствует моим ранее настроенным кастомным полям. куда они делись, они же нужны мне
сами настройки freetext остались старыми, но я не вижу интерфейса взаимодействия
Среди FreeText полей часть зарезервированы ITSM (а также часть FreeTime полей)