Портал №1 по управлению цифровыми
и информационными технологиями

Как сделать приоритет реальным показателем очередности выполнения запросов и инцидентов

Все мы привыкли к ставшей уже общепринятой методике определения приоритета запроса или инцидента. Определяется срочность запроса (как быстро необходимо его выполнить), и воздействие/влияние запроса на пользователя или бизнес-процесс. На основе матрицы из срочности и влияния определяется приоритет запроса, который в свою очередь (в числе прочих параметров, например тип запроса – запрос на консультацию или обслуживание или изменение или инцидент – или статус Пользователя – VIP\не VIP), определяет выбор SLO и, в конечном счете, определяет, как быстро ИТ должно отреагировать и выполнить этот запрос – т.е. конечный срок выполнения запроса.

Соответственно, сотрудникам поддержки ИТ, в рамках регламентов и рабочих инструкций предписывается выполнять запросы в порядке убывания приоритета – от самых приоритетных, к самым низко приоритетным.

В такой ситуации есть очевидные минусы, которые также уже давно известны практикам управления ИТ, например, при большом количестве высокоприоритетных запросов ресурса поддержки начинает не хватать на выполнение низкоприоритетных, они “зависают” в накопителе и долгое время висят просроченные и не выполненные. Чтобы избежать этой ситуации в ряде компаний принимается решение нарушать этот регламент, и в число решаемых за день высокоприоритетных запросов, искусственно добавлять небольшое количество низкоприоритетных.

Я долго думал над этой ситуацией и хочу поделиться с вами своими выводами.

Мне кажется, привычный порядок определения приоритета должен быть изменен.

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

Первое – срочность есть показатель того, как далеко в будущем отстоит дата/время когда должен быть выполнен запрос. Она не должна выставляться вручную сотрудником поддержки и, уж тем более, конечным пользователем.

Второе – запрос имеющий большое влияние на бизнес, но низкую срочность, должен автоматически повышать свой приоритет по мере приближения конечного срока – ведь по мере приближения даты к которой он должен быть выполнен он одновременно начинает обладать И высокой срочностью И большим влиянием.

Таким образом механизм приоритезации должен быть изменен и в целевом виде должен выглядеть так:

1. На основании степени воздействия запроса/инцидента на бизнес определяется его влияние.
2. На основании типа запроса и его влияния определяется срок, к которому должен быть выполнен данный запрос и, соответственно, конечная дата/время исполнения.
3. На основании того, как далеко в будущем отстоит конечная дата/время исполнения, определяется срочность запроса/инцидента.
4. На основании сочетания влияния и срочности, определяется его приоритет (это остается точно также как и сейчас)
5. Приоритет является однозначным показателем порядка выполнения работ

С помощью такого механизма обеспечивается правильное и автоматическое определение срочности запроса/инцидента и связанного с ним приоритета исполнения.
В то же время мы уходим из петли – повышается срочность – повысился приоритет – изменилась SLO – изменилась конечная дата – изменилась срочность и т.д. И в то же время, при правильной настройке матрицы “влияние/срочность”, не обладающие большим воздействием запросы, даже при максимальном приближении к просрочке не получат сверхприоритета над действительно важными вещами.

Данный механизм я еще не встречал ни в одной системе класса Service Desk. Предлагаю его вам на обсуждение.

Автор: Алексей Лазарев, ITSM-консультант

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 8

  • Владимир Невский

    Определение приоритета на основании Срочности и Влияния уже много лет критикуется ITSM сообществом, т.к. заказчику всегда нужно СРОЧНО.
    ИМХО: если приостановка решений других обращений не нарушают в ближайшее время срок исполнения по SLA, вперед должны решаться “быстрые/простые” обращения, которые можно сделать за короткое время (как в Макдоналдсе); быстрые решения делают больше счастливых людей, по сравнению с тем, если бы эти люди ждали своей очереди.

    • Андрей Вишняков

      так и происходит в формате работы т.н. Dispatch Swarming (Triage Swarming) – см ITIL4 CDS 5.1.4 Swarming

    • по ссылке – одна из первых дискуссий на эту тему здесь на портале. К сожалению, не работает уже ссылка в тексте того поста, зато внизу – много комментариев, раскрывающих тему очень неплохо.
      9 лет назад деревья были большими, вопрос про приоритизацию вызывал дискуссии, а заметки на портале активно комментировались. Эх, время было…

      Кстати, еще одну дискуссию тогда вызывало написание слова “приоритизация”. Тут тоже ответ известен: http://new.gramota.ru/spravka/buro/search-answer/?s=%D0%BF%D1%80%D0%B8%D0%BE%D1%80%D0%B8%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F

    • Тоже сразу вспомнил. Соответственно, и техническая реализация этого принципа делается нами в проектах с 2008 года, он же является частью “коробочной” конфигурации CleverENGINE c 2009 года. А вот запись вебинара на эту тему: https://youtu.be/A887SQAh3eU

  • Konstantin

    Была у меня аналогичная ситуация и решал я ее следующим образом – из пяти сотрудников смены четверо работали по принципу FEFO (First Expires Fist Out), и один по FIFO (Fist In First Out). В итоге высокоприоритетные заявки разбирались быстро и в порядке очереди, а низкоприоритетные не залеживались, тк один человек ими постоянно занимался. Для нашей компании это прекрасно работало.

  • Александр Нагорный

    В описанном в статье способе приоритизации вижу логическую ошибку: срочность описана в виде срочности для исполнителя. А что бы быть клиенто-ориентированным нужно в первую очередь учитывать срочность для получателя услуги (заказчика).
    Что бы не путать интересы заказчиков и исполнителей мы в Naumen используем два различных приоритета:
    1. Внешний. В нем определяем все договоренности с заказчиком (включая срочность для заказчика)
    2. Внутренний. В нем определяем последовательность работ внутри исполнителя. Он (помимо информации о важности запроса для заказчика) включает в себя и оставшийся срок до просрочки запроса, и количество ресурсов у исполнителя и в целом любые другие параметры, важные для исполнителя. Этот приоритет мы так и называем – «Порядок выполнения»

  • Александр Нагорный

    Соответственно по внешнему приоритету определяем крайний срок выполнения запроса, а по внутреннему приоритету – порядок обработки у исполнителя.

    Внутренний приоритет в целом не транслируется заказчику, что бы ему было комфортно. Что бы он не видел кейсов, когда исполнитель выполняет менее приоритетный, но зато более простой запрос.


Добавить комментарий для Александр НагорныйОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM