Все мы привыкли к ставшей уже общепринятой методике определения приоритета запроса или инцидента. Определяется срочность запроса (как быстро необходимо его выполнить), и воздействие/влияние запроса на пользователя или бизнес-процесс. На основе матрицы из срочности и влияния определяется приоритет запроса, который в свою очередь (в числе прочих параметров, например тип запроса – запрос на консультацию или обслуживание или изменение или инцидент – или статус Пользователя – VIP\не VIP), определяет выбор SLO и, в конечном счете, определяет, как быстро ИТ должно отреагировать и выполнить этот запрос – т.е. конечный срок выполнения запроса.
Соответственно, сотрудникам поддержки ИТ, в рамках регламентов и рабочих инструкций предписывается выполнять запросы в порядке убывания приоритета – от самых приоритетных, к самым низко приоритетным.
В такой ситуации есть очевидные минусы, которые также уже давно известны практикам управления ИТ, например, при большом количестве высокоприоритетных запросов ресурса поддержки начинает не хватать на выполнение низкоприоритетных, они “зависают” в накопителе и долгое время висят просроченные и не выполненные. Чтобы избежать этой ситуации в ряде компаний принимается решение нарушать этот регламент, и в число решаемых за день высокоприоритетных запросов, искусственно добавлять небольшое количество низкоприоритетных.
Я долго думал над этой ситуацией и хочу поделиться с вами своими выводами.
Мне кажется, привычный порядок определения приоритета должен быть изменен.
Приоритет запроса должен быть четким, единственным и обязательным показателем очередности выполнения запросов. Только в таком виде он может быть полезным инструментом для сотрудников поддержки. Чтобы этого достичь необходимо осознать несколько вещей:
Первое – срочность есть показатель того, как далеко в будущем отстоит дата/время когда должен быть выполнен запрос. Она не должна выставляться вручную сотрудником поддержки и, уж тем более, конечным пользователем.
Второе – запрос имеющий большое влияние на бизнес, но низкую срочность, должен автоматически повышать свой приоритет по мере приближения конечного срока – ведь по мере приближения даты к которой он должен быть выполнен он одновременно начинает обладать И высокой срочностью И большим влиянием.
Таким образом механизм приоритезации должен быть изменен и в целевом виде должен выглядеть так:
1. На основании степени воздействия запроса/инцидента на бизнес определяется его влияние.
2. На основании типа запроса и его влияния определяется срок, к которому должен быть выполнен данный запрос и, соответственно, конечная дата/время исполнения.
3. На основании того, как далеко в будущем отстоит конечная дата/время исполнения, определяется срочность запроса/инцидента.
4. На основании сочетания влияния и срочности, определяется его приоритет (это остается точно также как и сейчас)
5. Приоритет является однозначным показателем порядка выполнения работ
С помощью такого механизма обеспечивается правильное и автоматическое определение срочности запроса/инцидента и связанного с ним приоритета исполнения.
В то же время мы уходим из петли – повышается срочность – повысился приоритет – изменилась SLO – изменилась конечная дата – изменилась срочность и т.д. И в то же время, при правильной настройке матрицы “влияние/срочность”, не обладающие большим воздействием запросы, даже при максимальном приближении к просрочке не получат сверхприоритета над действительно важными вещами.
Данный механизм я еще не встречал ни в одной системе класса Service Desk. Предлагаю его вам на обсуждение.
Автор: Алексей Лазарев, ITSM-консультант
Определение приоритета на основании Срочности и Влияния уже много лет критикуется ITSM сообществом, т.к. заказчику всегда нужно СРОЧНО.
ИМХО: если приостановка решений других обращений не нарушают в ближайшее время срок исполнения по SLA, вперед должны решаться “быстрые/простые” обращения, которые можно сделать за короткое время (как в Макдоналдсе); быстрые решения делают больше счастливых людей, по сравнению с тем, если бы эти люди ждали своей очереди.