Всех с прошедшим новым годом, продолжаем пилить приоритеты.
То, что у нас привязывается сервис к критичности, которая автоматом подставляется при выборе сервиса (на основе которой автоматом подставляется приоритет), а так же наличие возможности руками изменить эту критичность (и приоритет!), это всё очень, очень хорошо.
Однако, есть некоторое непонимание, как методологию привязать к техноте.
Давайте ещё раз обсудим приоритет, и параметры, которые должны влиять на приоритет.
Возьмём стандартную 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] умноженной на набор переменных.
Как всё это автоматизировать? я хочу при создании заявки выбрать Компанию, Клиента, Сервис и Количество пользователей, и чтобы на основе всего этого автоматически рассчитался приоритет.
костыли типа кастомные поля совокуплятьс планировщиком задач - не приветствуется