Связка срочности и приоритета

Добрый день, коммунити.
Может кто подскажет - где настраивается матрица Срочность/Приоритет?
Все уже пересмотрел - никак не могу найти, а зависимость, установленная по умолчанию, не удовлетворяет требованиям.

Привет! Если я правильно понял, нужно изменить правила, по которым iTop вычисляет приоритет тикета из выбранных срочности (urgency) и влияния (impact)? По умолчанию он делает это вот по этой матрице и руками через интерфейс (как в otrs) это не меняется.
Напиши, какие модули используешь, я подскажу, где и что поправить.

Установлено все по максимуму, учет запросов и инцидентов по ITIL.
Дефолтную матрицу влияния я нашел, значения метрик подогнал под нее.
В принципе дефолтная матрица нормально сделана, но все же хотелось бы знать - как в случае необходимости ее изменить.

Для каждого типа тикетов (запросы, инциденты, проблемы и изменения) приоритет определяться по-разному. За вычисление отвечает метод ComputePriority, описанный в файлах моделей данных тикетов (типа datamodel.itop-incident-mgmt-itil.xml) в разделе methods.

Пример для инцидентов:

public function ComputePriority()
    {
            // priority[impact][urgency]
            $aPriorities = array(
                    // single person
 Это влияние--->  1 => array(
     Это срочность--->   1 => 1, <---Это получающийся приоритет, его нужно менять
                         2 => 1,
                         3 => 2,
                         4 => 4,
                    ),
                    // a group
                    2 => array(
                            1 => 1,
                            2 => 2,
                            3 => 3,
                            4 => 4,
                    ),
                    // a departement!
                    3 => array(
                            1 => 2,
                            2 => 3,
                            3 => 3,
                            4 => 4,
                    ),
            );
            $iPriority = $aPriorities[(int)$this->Get('impact')][(int)$this->Get('urgency')];
            return $iPriority;              
    }

По-быстрому - можно изменить в datamodels\2.x\itop-incident-mgmt-itil\datamodel.itop-incident-mgmt-itil.xml и файлах моделей других типов тикетов. Затем прогнать установку с обновлением или обновить код iTop через toolkit. Важно не забыть об изменении этом при переходе на новую версию iTop.

По-хорошему - нужно сделать это дополнение в виде модуля и установить как полагается в extensions. Потом можно матрицу через конфиг-файл модуля править, а там уже недалеко и до настройки через интерфейс).

Как-то так. Спрашивай, если что непонятно объяснил.

1 лайк

Приветствую, про матрицу спасибо понятно объяснили, но можно ли настроить права доступа, чтобы некоторые агенты(допустим через отдельный профиль) могли вручную изменить в заявке приоритет?
Спасибо.

Или отключить матрицу приоритета, чтобы вручную выставлять приоритет. Руководство интересуется, чтобы пользователи создавали заявку, указывали только срочность, а агенты уже могли менять приоритет вручную.

Вероятно, ваше руководство не понимает, что это за матрица приоритетов. Приоритет тикета это же не просто абстрактная “важность”, это основание для определения последовательности, в котором должны решаться тикеты (чтобы не выйти за рамки SLA). И определяться этот порядок должен обоснованно на базе более простых и понятных вещей. Сделаете ручной выбор, получите половину тикетов высокого и критического приоритетов.
Давать рядовому пользователю выбор критичности из “низкая”, “средняя”, “высокая” и “критическая” это тоже так себе идея. Какую критичность выберет кадровик, если у него краска в принтере закончилась? Конечно “критическую”, краска же уже закончилась)
Оставьте пользователям выбор влияния, это наиболее понятная составляющая приоритета. Если принтером пользуется один сотрудник, он выберет “сотрудник”, если принтер на отдел – “отдел”. А срочность пусть выбирают агенты, исходя из параметров заявки. Например, если в отделе всего один принтер, то срочность “высокая”, а если заявка от босса – “критическая”. Основная идея в том, что для изменения приоритета нужно осознать, какая из его составляющих и в какую сторону изменилась.

А вообще, конечно, можно и матрицу отключить. Нужно в нужных тикетах в методе ComputeValues убрать вызов метода ComputePriority.

1 лайк

Спасибо, буквально недавно нашёл ниже под функцией ComputePriority функцию ComputeValues где увидел присовение результата матрицы приоритета.
Я говорил насчёт приоритета, но там женщины написали тз и они хотят чтобы приоритет меняли только операторы, операторов всего 3-5 человек, и они будут сидеть на первой линии, пользователям приоритет менять нельзя, у пользователей срочность только есть.
а влияние мне сказали, у них будет это расположение(регион).

Менять приоритет и так могут только операторы через изменение срочности и влияния. Пользователь влияет только на первичное определение приоритета.

В справочнике влияния только три варианта, этого хватит для списка расположений, или его расширять будут? Рассмотрите возможность использования КЕ Расположение для вычисления приоритета. У инициатора тикета есть Расположение, у связанной с тикетом КЕ может быть Расположение, в сам тикет можно добавить поле для связи с Расположением, а в расположения добавить справочник критичностей. В общем, есть где развернуться))

1 лайк