Страница 2 из 2

Re: Приоритет

Добавлено: 29 дек 2011, 15:16
Isenschtill
Ticket::Frontend::AgentTicketFreeText###Permission стоит rw
пытаюсь сделать на двух машинах - на одной агентом, в группе админов,
на второй - самим админом root@localhost
одно и то же

Re: Приоритет

Добавлено: 29 дек 2011, 15:25
ykolesnikov
Посмотрите еще здесь - SysConfig in Ticket -> Frontend::Agent::Ticket::MenuModule -->Ticket::Frontend::MenuModule###310-FreeText

Re: Приоритет

Добавлено: 29 дек 2011, 16:15
Isenschtill
Да, оно!
Спасибо большое :P

Re: Приоритет

Добавлено: 29 дек 2011, 23:43
alexus
Один совет - используйте контекстный поиск по конфигурации. Очень помогает сэкономить время, не дожидаясь ответов на форуме. Попробуйте для интереса поискать по слову "freetext", а затем на странице (Ctrl+F) "menu" ;)

Re: Приоритет

Добавлено: 06 янв 2012, 17:37
Isenschtill
Всех с прошедшим новым годом, продолжаем пилить приоритеты. :)

То, что у нас привязывается сервис к критичности, которая автоматом подставляется при выборе сервиса (на основе которой автоматом подставляется приоритет), а так же наличие возможности руками изменить эту критичность (и приоритет!), это всё очень, очень хорошо.

Однако, есть некоторое непонимание, как методологию привязать к техноте.
Давайте ещё раз обсудим приоритет, и параметры, которые должны влиять на приоритет.
Возьмём стандартную ITIL-овскую формулу Priority=Impact x Urgency. Здесь подразумевается простая матрица приоритетов.
Однако, в каждом из понятий у нас могут быть совершенно разнородные параметры.
Impact - это влияние.
Оно может оцениваться:
1)Компания, которую мы обслуживаем, если их несколько.
2)лицо, которое мы обслуживаем в этой компании - тут два параметра - VIP или НЕ vip.
3)Сервис, который мы обслуживаем в этой компании.
4)количество пользователей, которых затрагивает тикет. (1, группа, все)
5)...

Urgency - срочность выполнения.
Она может оцениваться:
1)Предполагаемыми времязатратами
2)...

Собственно этих "разрезов", в которых мы смотрим на влияние и срочность может быть разное количество.
т.е., мы рассматриваем Priority=Impact-1 x Impact-2 x Impact-3 x Impact-4 x Urgency-1
Логично ведь, что на приоритет влияет и та компания, от которой пришла заявка, и то лицо, кто её подал, и сервис (это ж sla!), и количество юзеров связанных с этим, и срочность, итд.,
И их нельзя всех отсортировать и запихнуть в один столбец матрицы Impact :!:

На сколько я вижу, Impact в OTRS учтён только в двух"разрезах" - это Критичность сервиса (пункт 3), и просто "impact", который ставится руками..

Вопрос - как технически в OTRS реализовать мою формулу?
Математически, этот приоритет можно представить в виде многомерной матрицы, а можно из матрицы [impact3 x urgency1] умноженной на набор переменных.

Как всё это автоматизировать? я хочу при создании заявки выбрать Компанию, Клиента, Сервис и Количество пользователей, и чтобы на основе всего этого автоматически рассчитался приоритет.


костыли типа кастомные поля совокуплятьс планировщиком задач - не приветствуется :evil:

Re: Приоритет

Добавлено: 07 янв 2012, 21:25
yuri0001
С наступившим Новым Годом и Рождеством!
Думаю, форум не ответит Вам на эти вопросы. "Измерить алгеброй гармонию...". Вы, по-моему, еще сами не достроили модель Вашей работы и пока Вы сами не поймете чего хотите, Вам и платные проектировщики не выдадут решение.
Вопрос не технократический, а идеологический. Вы хотите вычислить трехзначный приоритет, чтобы агент понял к кому быстрее бежать :D Мне это кажется не очень верным, всегда найдется еще параметр, который окажется в тот момент еще более важным. Всё равно останется набор факторов, которые придется разруливаить менеджеру, да и агент не должен быть болванчиком. Надо с ними работать. Как говорили классики марксизма: "Идея овладевшая массами становится производительной силой..."
Непонятен тезис о количестве клиентов.
Impact - учитывает влияние инцидента на состояние Сервиса, в том числе, например, сколько рабочих мест будет затронуто отказом коммутатора, поэтому и вручную. VIP/Не VIP - это скорее SLA.
Конечно заманчиво свести все к совершенно формальной процедуре, но это вряд ли, если только за деньги - любые желания за ваши деньги, но это скорее индийский подход - заказчик всегда прав, даже если несет ахинею. :D
Удачи в поисках истины

Re: Приоритет

Добавлено: 08 янв 2012, 15:12
Isenschtill
yuri0001,
yuri0001 писал(а):Непонятен тезис о количестве клиентов.
Вы сами пишете ответ на свой вопрос:
yuri0001 писал(а):Impact - учитывает .... сколько рабочих мест будет затронуто
---

С вашей общей позицией я не согласен - методология, явленная с помощью ПО - должна максимально упрощать деятельность, а не усложнять её (например, заставляя людей вычислять приоритеты).
Если всё хорошо формализовано, и более того - представлено технически в соответствии с формализацией, то "набор факторов, которые придется разруливаить менеджеру" и ненужная инженеру деятельность по вычислению приоритетов сводится к нулю или редкому исключения из правила. Видел я, когда системы работы с тикетами выполняют только функцию фиксирования. Трэш..
VIP/Не VIP - это скорее SLA
Формально - да, а технически - через Impact.
Конечно заманчиво свести все к совершенно формальной процедуре, но это вряд ли, если только за деньги
Именно так, а зачем же ещё нужны соответствующие методики? всё в конечном счёте выражается через деньги. И повышение KPI сотрудников, и повышение качества самой техподдержки.

Re: Приоритет

Добавлено: 08 янв 2012, 17:14
yuri0001
Суха теория приятель, но древо жизни зеленеет.
Если продолжать дискуссию, ее надо перенести в раздел методических вопросов.
Ваша позиция технократична и имеет право на жизнь, но мне она не близка.
Даже в документации по OTRS встретил, хотя и не ожидал, тезис о VIPах, которые правее правых, а это означает, что ошалевший от чувства собственной значимости и центропупизма чиновный прыщ пошлет Вашу формулу расчета приоритета в определенном направлении вместе с KPI. Важно определить границу до которой работает формула и где начинается искусство менеджера, а то ведь формально - правильно, а по сути издевательство. Боюсь абсолютной истины здесь нет. Еще раз успехов Вам на этом пути. Ваша приверженность идее достойна уважения.
Моя личная позиция - давать небольшой простор инициативе сотрудников, в том числе и техподдержки, они в поле видят все лучше. Чем меньше простор для инициативы, тем меньше у них ответственности - "нам электричество пахать и сеять будет..." - формула сказала беги туда - побежал, по жизни оказалось надо было бежать в другую сторону - дык ведь формула сказала "лошадью ходи...", а с меня спрос какой, я ж человек маленький. И что? Очередной коэффициент в формулу? Стохастические поправки на спорадические отклонения?
Извините, ворчу по-старчески, видел и проходил, к счастью вылечился. Еще раз удачи!

Re: Приоритет

Добавлено: 08 янв 2012, 20:43
Isenschtill
Что ж, спасибо за вашу позицию. Можно было бы и продолжить дискуссию, в разделе методологии )
Я, только "за" 8-)

Однако, возвращаясь к нашим техно-баранам..
Допустим, я представлю формулу так: priority = [impact1 x impact2] x [impact3 x urgency 1 ]
Чтобы многомерную матрицу свести к двухмерной,
примем за [impact1 x impact2] то, что в OTRS называется "критичность",
а [impact3 x urgency 1] за то, что в OTRS называется "Impact"
(ну, или наоборот).
Так как у меня ~ 10-13 приоритетов, то как нам быть, если матрица жёстко прдразумевает 5х5=25?
Как нам быть с "неиспользуемыми" ячейками?
Можно ли как-нибудь сделать, чтобы для каждой "критичности" я мог выбрать своё определённое количество "импактов"?
т.е. когда в интерфейсе создания заявки я выбираю "сервис", у меня были не постоянно пять импактов, а "в зависимости от" ?

Re: Приоритет

Добавлено: 09 янв 2012, 10:18
yuri0001
Попробуйте покурить про ACL. Встречались посты как поставить в зависимость очередь от типа заявки. Может по аналогии прикрутите. Поищите на нашем и буржуйском ноязычном форумах. Было бы желание и умение программировать и документировать, чтобы потом после обновлений OTRS, править и там. Или писать свое с нуля. У меня, в свое время, ребята написали свою систему за 2 года и потом с жалостью меняли на CA Unicenter, которую потом внедряли сверху. В своих кодах легче менять и копаться, если разработчики на месте. а в CA до сих пор, несмотря на мощную команду подрядчиков не все так как хотелось бы. Идеала нет, выбирают приближение по матрице Желания-Возможности-Сроки-Стоимость... далее везде ;)

Re: Приоритет

Добавлено: 09 янв 2012, 14:22
Isenschtill
Благодарю, аклы помогли. Красота. Теперь бы математику допилить. :D

Re: Приоритет

Добавлено: 09 янв 2012, 15:12
yuri0001
Удачи!
Допилите, поделитесь с сообществом в разделе HowTos. ;)

Re: Приоритет

Добавлено: 09 янв 2012, 22:50
alexus
И Вас с прошедшим и наступившим!

Продолжаем пилить :) .
Для начала исходные условия - OTRS ITSM, реализация процесса управления инцидентами по ITIL. Как следствие №1 - тема перенесена в подобающий раздел.

1. Формула ITIL Priority= Impact x Urgency - это только как вариант расчета приоритета, но не догма.

2. Соглаcно ITIL Приоритет это "Категория, используемая для понимания относительной важности Инцидента, Проблемы или Изменения. Приоритет базируется на Влиянии и Срочности и используется для определения требуемого времени обработки. К примеру, в Соглашении об уровне услуг (SLA) может быть указано, что Инциденты Второго приоритета должны быть разрешены в течение 12 часов." Вот тут уже есть много вопросов с точки зрения практики, т.к. этот подход не всегда хорош. Именно поэтому я отсылал Вас на портал "Реальный ITSM". Там представлены мнения авторитетных людей, суть которых - "ITIL - не всегда хорошо".

3. Срочность по ITIL - это не совсем "Urgency - срочность выполнения". Посмотрите приложение со словариком ITIL v3.

4.
Isenschtill писал(а):Логично ведь, что на приоритет влияет и та компания, от которой пришла заявка, и то лицо, кто её подал, и сервис (это ж sla!), и количество юзеров связанных с этим, и срочность, итд.,
Это логично лишь отчасти, т.к. SLA не определяют приоритет. И на основе этих параметров надо аксиоматически описать Влияние и Срочность. А затем уже составить матрицу.
Нормальную! Двумерную! Ибо Priority=Impact-1 x Impact-2 x Impact-3 x Impact-4 x Urgency-1, т.е. ПЯТИмерную матрицу, мое личное сознание не может помыслить :o, несмотря на все математические (боюсь представить сколько приоритетов получится) и философские (не могу подобрать подходящую сущность) потуги.

5. Мое мнение такое - надо определиться!

6. Вопрос на засыпку... А для чего Вам приоритет? Что Вы с ним будете делать?

Re: Приоритет

Добавлено: 10 янв 2012, 16:14
Isenschtill
Коллега,
отвечаю вам по вашим пунктам.

1. Согласен, не догма. Главное - удобство и соответствие нашим целям.
2. Хорошо это или не хорошо - это всего лишь практики-примеры, которые необходимо адаптировать в той или иной степени, а не критиковать их принципиально.
3. Здесь некоторая игра слов, в результате которой мы можем друг друга не понять. Под фразой "Urgency - срочность выполнения" я имею ввиду как раз именно то, что написано в словарике - как быстро заявка начнёт влиять на бизнес. Т.е. на сколько срочно её необходимо выполнить именно с этой точки зрения. Вообще, urgency тоже можно рассматривать в разных разрезах, как и impact. Например, не только то, как быстро начнёт влиять на бизнес, но и время, требуемое для выполнения этой заявки - при прочих равных, "быстрые" заявки логично выполнять первее "долгих". Давайте оставим Urgency в покое, во всяком случае, в этой теме, чтобы не разветвлять логику разговора :roll:

4. Абсолютно с вами не согласен. приоритет определяется сроками из SLA.
Когда вы заключаете несколько SLA (с разными компаниями или разными отделами внутри вашей компании), вероятно, вы заключаете их как на разные типы обращений, так и на разные сроки по этим типам обращений.Исходя из этого, получается то, что я говорил
-Компания влияет на приоритет
-VIP\не vip пользователя влияет на приоритет (ну, если в sla с компанией есть випы, и соответвенно, сроки по випам )
-Тип обращения влияет на приоритет
-итд...

То есть, если у вас два одинаковых инцидента от разных компаний, приоритет (по которому ориентируется инженер) должен быть продиктован сроками из sla.

5,6. Именно за этим нам и нужен приоритет, чтобы удобно, в соответствии со всеми требованиями, определил очерёдность работы с обращениями.

Я не догматик, но здесь я стараюсь приблизится именно к itil-овской парадигме, пусть и немного её видозменив.
Ключевая фраза - цитирую вашу цитату - "Категория, используемая для понимания относительной важности".
Приоритет определяю из SLA, а так как в SLA много параметров, я их использую как категории импактов и срочностей (в основном, импактов) для формирования конечного приоритета, которым руководствуется инженер.

Я для себя не могу понять, почему вы не можете придумать пример, когда для вас важны все эти импакты, вроде всё просто. Более того, я себе даже по другому не представляю. Понятно что иногда у нас компания всего одна, и тд, но общая-то суть..

Re: Приоритет

Добавлено: 11 май 2018, 08:10
otrsuser
ykolesnikov писал(а):1. Если не установлен, установите модуль ITSM.
2. В Web - Конфиге в разделе Администрирование системы появится раздел Критичность <-> Влияние <-> Приоритет (Criticality-Impact-Priority)
3. Критичность привязывается к Сервису, что логично.
4. При вводе телефонной заявки агентом появится поле Impact (Влияние) со значением по умолчанию. Соответственно вычислится и подставится приоритет. Чтобы это работало, для клиента должен быть привязан Сервис и в нем указана Критичность. Если заявка приходит от клиента там Impact не вводится и скорее всего он подставляется по умолчанию (Клиент не может знать о степени влияния его инцидента на весь Сервис). Где прописывается не помню, прочешите Конфиг. Изменить его можно при определенной настройке прав агента через Изменение полей заявки.
Вообщем, если есть желание этим заниматься - пробуйте, механизмы есть. "Пилите Шура, пилите, они золотые...". О.Бендер. :)
Добрый день!

Не могли бы Вы помочь. Установила ITSM, появилась матрица, отобразила динамические поля Критичность и Степень влияние, при заполнении этих полей Приоритет не вычисляется согласно матрице. :(

OTRS 5.0.21

Спасибо!