Раздел: ITIL и прочее

ITIL, Определение приоритетов и очерёдности выполнения заявок

Одна из вечных тем — определение приоритетов заявок в Service-Desk. Стандартное Priority=Urgency*Impact не удовлетворяет требованиям объективности оценки очерёдности выполнения заявок. Здесь я опубликую своё видение ситуации.

ITILv3 в книге Service Operation определяет Приоритет(Priority) как Категорию, используемую для понимания относительной важности Инцидента, Проблемы или Изменения.

Само значение приоритета вычисляется исходя из значений других «переменных» — Влияния(Impact) и Срочности(Urgency).

Под Влиянием(Impact) в общем случае можно понимать влияние заявки (Инцидента, Проблемы или Изменения) на бизнес. Например, если компьютер завис у секретарши — это не то же самое, что и зависание компьютера у главного бухгалтера или генерального директора.

Под Срочностью(Urgency) понимается то, на сколько быстро необходимо выполнить заявку (устранить Инцидент, и пр.). Если процитировать ITIL: «на сколько быстро бизнесу нужно решение». Пример следующий: инцидент типа «У меня завис компьютер, я не могу выполнять свою работу» отличается от «У меня завис компьютер, но я уже ухожу домой, и у вас будет неделя, чтобы разобраться с этим, пока я в командировке». Если принять, что этот запрос от одного и того же сотрудника, то этот пример показывает заявку с одинаковым Влиянием, но разной Срочностью.

Таким образом, ITIL предлагает нам вычислять приоритет на основании этих двух категорий.

Проиллюстрировано это так:

Матрица приоритетов ITIL

Есть матрица значений Влияния(Impact) и Срочности(Urgency). В данном случае, у каждого из этих значений по три параметра, но их может быть любое количество, и матрица не обязательно должна быть квадратной. Определяя Влияние и Срочность, на пересечении мы находим Приоритет. Опять-таки, значения Приоритета не обязательно должны располагаться именно таким «зеркально-диагональным» образом.

После определения матрицы приоритетов, ITIL подводит нас к тому, что мы должны на основании значений приоритетов составлять SLA, ставя каждому приоритету в соответствие — время, в течение которого должна быть выполнена заявка.

Сразу скажу, почему мне такой подход не нравится:

1) Если у специалиста Service Desk любой линии возникает потребность в определении очерёдности выполнения заявок, то он должен ориентироваться сразу на несколько параметров, и самостоятельно определять эту очерёдность. Специалист должен: а) посмотреть на приоритеты заявок, выбрать наиболее «приоритетные»; б)Среди группы наиболее «приоритетных» заявок выявить те, которые поступили раньше всего, т.к. весьма логично начать с тех, которые поступили раньше, особенно, учитывая, что это важно для выполнения SLA. В особо ужасных случаях, когда происходит «Завал», Специалисты ещё и начинают ознакомление с заявками на предмет того, как бы выполнить побольше в оставшееся время.

Я считаю, что Специалист должен заниматься своей работой, а очерёдность работы должна на заранее определённых параметрах вычислять машина, автоматически.

2) Нецелесообразно использовать значения приоритетов для определения «resolution time» в SLA, т.к.: а) Может меняться матрица приоритетов, придётся менять SLA, нервировать людей. б) Исходя из опыта — Заказчику всё равно, «какой у нас приоритет», и что это вообще означает. Ни одному руководителю подразделения не интересна вся эта «кухня» — матрица приоритетов, итд. Как правило, они все хотят чёткого соотношения «Тип заявки=Время выполнения». Например: «Вышел из строя принтер=1 час»; «Не доступен интернет=30 минут». Такие категории гораздо более понятны Заказчикам, и их не интересует, какой Приоритет за этим стоит в нашем понимании.

3)Если мы обслуживаем нескольких внешних Заказчиков то, скорее всего, у каждого из них будут свои требования по срочности выполнения заявок, которые никак нельзя будет объединить в единую шкалу приоритетов.

Исходя из определения Приоритета, по логике ITIL он и не должен указывать на очерёдность выполнения заявок. Точнее, не это есть его основное назначение. Встаёт вопрос — а как тогда определять очерёдность работы с заявками? Я предлагаю использовать унифицированную шкалу приоритетов, и Приоритет использовать как показатель очерёдности выполнения заявок, вычисляя его особым образом.

Для того, чтобы определить наш Приоритет-Очерёдность, требуется сначала оценить параметры заявок, влияющие на этот конечный приоритет.

Например:

  • Тип заявки — Инцидент, Запрос на обслуживание, Запрос на изменение, и прочее ITIL’овское. Считаю именно этот параметр основным в определении Приоритета-Очерёдности, потому что, как говорилось выше, именно на основе типа заявки в SLA устанавливается срок выполнения.
  • Количество пользователей, которое ожидает выполнения заявки(или связано с ним). Как правило, у этого параметра два значения: Один или Много. Так же может быть три: Один, Группа (несколько), Все.
  • Заявитель — Обычный пользователь или VIP (секретарша и гендиректор из примера выше).
  • Время подачи заявки (полностью автоматически вычисляемый параметр, «столько-то часов назад»). Этот параметр должен помочь установить очерёдность выполнения заявок на основе их даты-времени поступления.

Конечно, нельзя исключать и ITIL:

  • Срочность
  • Влияние

Таким образом, Формула вычисления Приоритета-Очерёдности имеет вид:

Приоритет_Очерёдность=Тип×Количество×Заявитель×Время×Срочность×Влияние

Данная формула не обязательна к применению именно в таком виде; она показывает суть подхода к определению очерёдности выполнения заявок. Параметров, влияющих на это значение может быть больше (например, можно добавить параметр «Компания», если обслуживаются несколько внешних клиентов); так же, не обязательно использовать все параметры, представленные здесь.

Получается, что значение Приоритета-Очерёдности должно быть либо элементом многомерного массива (по аналогии с Urgency×Impact), либо значением, вычисляемым как умножение чисел, соответствующих весу каждого из параметров.

Данный подход позволит минимизировать телодвижения по определению очерёдности выполнения, однако требует тщательного просчёта весов каждого из параметров, чтобы получить адекватную очерёдность на выходе. Так же, нужно понимать что, несмотря на попытку абсолютизировать значение очерёдности, мы не уходим полностью от того, чтобы специалист (или координатор) включали голову, потому что задачу по анализу  времени ожидания компьютер не выполнит, поскольку время ожидания — тоже является параметром заявки при определении очерёдности выполнения, но определяется только при знакомстве специалистом с сутью заявки, а иногда и при начале её выполнения.

Для тех, кто не знаком, могу пояснить связь времени ожидания и очерёдности выполнения.

Пусть срок выполнения одной заявки T¹=3 часа, срок выполнения второй заявки T²=1 час.

В случае, если специалистом будет выполнена сначала первая заявка, потом вторая, то время ожидания первого заявителя будет три часа, а время ожидания второго заявителя 3+1=4 часа; суммарное время ожидания будет равно 3+4=7 часов.

В случае, если специалистом будет выполнена сначала вторая заявка, потом первая , то время ожидания второго заявителя будет один час, а время ожидания первого заявителя 1+3=4 часа; суммарное время ожидания будет равно 1+4=5 часов.

Итог.

Несмотря на невозможность достичь абсолютизации в автоматическом определении очерёдности выполнения заявок, описанный выше подход максимально упрощает работу специалистам ServiceDesk в поставленной задаче, хотя и не соответствует ортодоксальному ITIL.

Комментировать

Комментарии

18 + пять =