Философия SLA: про приоритеты запросов
Продолжаю цикл статей про SLA, публикуя то, что не уместилось в основную статью Как написать хороший SLA.
Не секрет, что начиная с определённого уровня зрелости в ИТ компании начинают регистрировать запросы в специальных системах, трекерах. Это позволяет понимать, кто и чем занимается, анализировать текущую ситуацию и уже проделанную работу и ещё массу полезного — при правильной постановке дела выгоды заметно перевешивают бюрократию. Очерёдность исполнения запросов регулируется приоритетами.
За много-много лет работы в поддержке самых разных ИТ-систем, мне очень понравилась система из четырёх приоритетов, о которой речь и пойдёт ниже. Эта система настолько хорошо показала себя на практике в самых разных проектах, что я искренне удивляюсь, встречаясь с другими подходами к приоритетам. Так что я готов приложить определённое количество усилий для популяризации таких определений приоритетов. Чтобы они чаще всеми использовались и чаще встречались в жизни.
TL; DR или сразу о сути
Если у Вас отсутствуют специальные причины (которые Вы готовы внятно сформулировать письменно), то в поддержке ИТ-систем используйте следующие приоритеты:
| № | Приоритет | Определение (для регламентов) | Определение «на пальцах» |
|---|---|---|---|
| 1. | Высший | Проблема влечёт за собой остановку или полную потерю работоспособности Системы. Становятся недоступны основные функции Системы и ситуация является критической. Проблемы данного приоритета обычно имеют одну или несколько характеристик:
|
Всё сломалось. Заинтересованные лица бросают все другие дела и начинают решать эту проблему, обычно работа ведётся в авральном (т.е. круглосуточном) режиме. |
| 2. | Высокий | Проблема влечет за собой значительную потерю работоспособности Системы. Критические функции Системы становятся недоступными, и нет применимого обходного пути решения, однако, Система сохраняет работоспособность в ограниченном объёме, и работы по решению будут вестись в рабочее время. | Проблема в самом деле критична, но не настолько всё плохо, чтобы переходить в авральный режим. |
| 3. | Средний | Проблема влечет за собой несущественную потерю работоспособности Системы, следствием чего является неудобство в работе или необходимость использовать альтернативные или обходные пути решения (workaround). | Проблема критична, но допускает ручной или иной способ обхода (workaround). |
| 4. | Низкий | Данная проблема не влечет потери работоспособности Системы. Это незначительная ошибка или неудобство, ошибка в документации и т.п., которые не препятствуют проведению операций в Системе. | Проблема должна быть решена, но не является критичной. Как ни странно, сюда попадает большая часть всех запросов. |
Эти приоритеты должны правильно пониматься и использоваться всеми сотрудниками ИТ компании, вовлечёнными в процесс сопровождения.
Для пользователей ИТ-систем от бизнеса приоритет должен ставиться автоматически на основании указанных ими свойств запроса, основанных на уместных, но по возможности объективных свойствах. Например, на критичности и степени влияния:
| Критичность\Влияние | На всех | На группу (отдел) | На одного |
|---|---|---|---|
| Высокая | 1 | 2 | 3 |
| Средняя | 2 | 3 | 4 |
| Низкая | 3 | 4 | 4 |
При этом для конкретных систем критичность может быть указана тут же. Например, для ERP-системы это могут быть диапазоны ожидающихся потерь: свыше 100 млн., от 1 до 100 млн., до 1 млн. Уместным может оказаться использование модификаторов вида «задействована VIP-персона», повышающих или понижающих приоритет. Матрица соответствия должна оставаться простой и прозрачной, но не позволяющей ставить высокие приоритеты необоснованно.
Причина такой кажущейся «дискриминации» рассматривается ниже.
Дальше об этом более детально и обстоятельно.
Зачем нужны приоритеты и какими они должны быть
Когда мы сами пишем регламенты, мы сами устанавливаем «правила игры». И имеет смысл установить такие правила не абы как, а чтобы было максимально удобно и эффективно. Это вопрос опыта, но начинать плясать от чего-то надо. Дальше уже дотачивать по месту. Давайте поговорим о том, как определять приоритеты. Начнём как обычно с главного — с ответа на вопрос «зачем это нужно».
Приоритеты нам нужны для того, чтобы выделять из общей массы запросов те, по которым мы хотим более активных действий. Таким образом мы сможем:
- Упорядочить работу исполнителя — задачи с более высоким приоритетом должны решаться раньше.
- Ввести в SLA разные целевые значения метрик в зависимости от приоритета, которые с одной стороны покажут, что задачи с более высоким приоритетом решаются в более срочном порядке, а с другой стороны позволят оценить, насколько хорошо эти правила выполняются.
Удобно иметь 3–5 приоритетов. Обычно этого хватает на все случаи жизни, другое количество приоритетов является скорее экзотикой. Чтобы приоритеты правильно работали, запросов более высокого приоритета должно быть в 5–10 раз меньше, чем предыдущего. Получается эдакая характерная лесенка (см.рис.). 
И тогда запрос с более высоким приоритетом в силу своей экзотичности привлечёт к себе естественное внимание и не затеряется в общей массе запросов конкретного исполнителя. Предполагается, что при нормальной загрузке на каждом исполнителе в среднем висит 5–15 открытых запросов, и половина из них требуют действий от кого-то ещё. Тогда с повышенными приоритетами у каждого исполнителя окажется в среднем не более чем 1–2 запроса, и совершенно понятно с какого конца нужно браться за работу.
Также хотелось бы иметь такие приоритеты, которые логичны и хорошо понимаются всеми участниками процесса. Потому что изменение приоритета слишком сильно может поменять целевые метрики работы, и если одна из сторон не согласна, то получится конфликт, чего хотелось бы избежать. Изменения приоритетов должны происходить при изменении масштаба решаемой проблемы или при появлении новой информации, которая существенно меняет начальную постановку задачи.
По моему многолетнему опыту очень удобной является система из четырёх приоритетов. Я их уже приводил в статье «Как написать хороший SLA». Ну и в начале этой статьи. Это три основных приоритета (Низкий, Средний, Высокий) и один экстраординарный (Высший) для тех самых случаев, когда все всё бросают и начинают заниматься только этой проблемой до победного конца.
Такая система приоритетов является довольно-таки интуитивно понятной. Меньше трёх регулярных приоритетов использовать нехорошо, плохо масштабируется. Больше трёх уже не особо нужно, да и Оккам не велел.
Определения приоритетов
Осталось обосновать определения приоритетов. Сделать это можно разными способами. Можно просто определить, никак не обосновывая. Можно и обосновать. Не претендуя на всеобщность я приведу один из подходов. Интересен он только тем, что его можно повторить для других специфических условий. Подход будет такой. Будем придумывать критерий, который позволит из общей массы запросов выделить те, которые требуют более пристального внимания. Потом из этих отобранных выбирать те, которые требуют ещё более пристального внимания. Ход мысли, надеюсь, понятен. А дальше из этих критериев и сделаем определения приоритетов. Чтобы определения были ясными, будем стараться каждый раз выбрать такой критерий, чтобы он был максимально простым и понятным.
Сразу отмечу, что по-умолчанию запросы должны всегда открываться с самым низким приоритетом, а более высокие приоритеты должны быть обоснованы в запросе. Иначе желаемой лесенки не получится. Требование письменно обосновать повышенный приоритет является важным, так как заставляет инициатора запроса задать себе вопрос, так ли в самом деле критична проблема. Попробуйте сами и поймёте, что это очень хороший фильтр.
Вернёмся к делению на приоритеты. Перво-наперво поделим все запросы на важные и неважные. Все неважные безжалостно закрываем.
Лирическое отступление
Неважных запросов не бывает. Если проблема ни для кого не является важной, не надо на неё тратить время. Это вопрос эффективности работы. Самый эффективный способ решения неважных проблем — это признать проблему никому не нужной и закрыть запрос. Никогда не оставляйте открытых «на потом» проблем. Вот когда будете готовы ими заниматься, вот тогда и заведёте. А если вдруг не вспомните, то значит и не надо было. Закрывайте. Иначе никакой SLA не поможет. Мир несовершенен, нечего и пытаться устранить в нём все несправедливости (см. рис.). Хотя согласиться с этим и тяжело. Мой внутренний перфекционист тоже было возражал, но ровно до тех пор, пока я не поставил его перед фактом, что делать ненужную работу будем в свободное от основной работы время. Если так уж мучает совесть, то помечайте такие закрытые запросы, чтобы к ним позже можно было вернуться. Когда, например, внезапно разгребли ворох всех текущих проблем и больше нечем стало заняться. Но так случаться не должно, если регулярно нечем заняться, то это значит, что часть ресуров нужно освободить для чего-то другого, более полезного.
Теперь у нас все запросы важные, выделим из них срочные и критичные. Потому что не всякая важная проблема обязана быть срочной или критичной. Как раз наоборот, критичные или срочные проблемы появляются не так уж и часто. Если Вам почему-то кажется, что все проблемы срочные и критичные, то просто попытайтесь письменно сформулировать, в чём важность и критичность каждой. Вот те, для которых не приходится натужно придумывать причину важности или брать нахрапом (сами что ли не понимаете, это же очень критично!), те и будут критичными.
Теперь из срочных и критичных выберем те, у которых нет обходных путей решения проблемы. Да, не так уж и редко бывает так, что с конкретной ситуацией вполне можно справиться без решения исходной проблемы. Посчитать руками на бумажке, собрать отчёт в Экселе, провести ручную операцию вместо штатной и т.п. Это всё обходные пути. Никто не спорит, что так делать неудобно, и что решать проблему надо, ибо зачем нужна ИТ-система, если она не работает. Но при наличии обходного пути, можно потратить на решение больше времени. Поэтому, если обходной путь существует, то им надо сразу пользоваться. Пока исполнитель пытается решить проблему в общем виде, инициатор сразу, не теряя времени, приступает к использованию обходного пути. А если инициатор может себе позволить подождать решения проблемы, то проблема скорее всего не такая уж важная или срочная, за которую он пытался её выдать, можно понижать приоритет.
Ещё лирическое отступление
Вот этот принцип паритета, он вообще очень важен в процессе сопровождения любых IT-систем. Ни одной из сторон процесса не должно быть больше нужно, чем другой. Должен быть паритет. Если одна сторона говорит «ну дальше вы сами, а я — домой, утром чтобы всё было сделано», то приоритет сразу надо понижать и тоже идти домой. Какой смысл ударно трудиться, найти решение глубокой ночью, чтобы оно так и осталось невостребованным до следующего рабочего дня? Или все работаем, или все расходимся. Особенно хорошо это правило работает в авральном режиме. Аврал и надо перейти на круглосуточную работу? Окей, отдел ИТ готов при необходимости работать в таком режиме, для того и создавался. Готов ли бизнес?… Обратную ситуацию (когда бизнесу надо, а ИТ не готов) я даже не рассматриваю,. Такой ИТ надо сразу разгонять в полном составе, так как не понимающий кто для кого работает отдел ИТ некомпетентен.
Вернёмся обратно к приоритетам. Нужно ли выделять в отдельный приоритет что-то ещё более важное? Да вроде бы уже и не нужно. Дальше только аврал.
Таким образом у нас получилось разбить все запросы на классы, причём каждый следующий класс запросов более редкий и требует более пристального внимания и более быстрого реагирования, чего и хотелось:
- важные, но критичные запросы (сюда по-умолчанию попадают все новые запросы);
- срочные и критичные (требуется обоснование почему);
- срочные и критичные, для которых нет обходного пути (тоже само собой с обоснованием).
Ну и конечно сверхприоритет:
- всё бросаем и занимаемся только этой проблемой без сна и отдыха.
Последний приоритет обычно выделяется из общего ряда по той причине, что по нему работают в круглосуточном режиме, в отличие от всех предыдущих, по которым работа ведётся в рабочее время. При соблюдении принципа паритета нужности, этот приоритет даже определять особо не нужно. Никто в здравом смысле не станет инициировать круглосуточный режим, если в самом деле не припрёт.
Итого получилось четыре понятных приоритета. Формулировки определений на канцелярите (чтобы можно было взять в свой регламент и исправить по месту) см. в табличке выше.
Названия можно взять предложенные мной, а можно нейтральные числовые — первый (самый высокий), второй, третий и четвёртый. А то бывает, что у кого-то рука не поднимается открывать запросы с приоритетом, который называется «Низким». Я, например, привык пользоваться обоими.
Приоритеты для бизнес-пользователей систем
Всё вышесказанное про приоритеты относится к тем людям, которые занимаются технической поддержкой по долгу службы. Сотрудники службы поддержки должны ориентироваться в общей картине по IT и уметь выставлять приоритеты объективно и единообразно в соответствии с внутренними регламентами. Пользователям же IT-систем от бизнеса лучше не давать возможность выбирать приоритет, а выставлять его автоматически. Хорошим приближением является диагональная матрица влияния и критичности из классического определения приоритета ITIL. Пример уже был приведён выше.
Почему так? Дело не в недоверии пользователям, мол, сирые они и убогие. Просто для пользователя ИТ-системы любая проблема, которая мешает лично ему, всегда будет самого высокого приоритета. Потому что мешает ему выполнять его собственную работу, причём вот прямо сейчас мешает. И ведь как всегда невовремя сломалось, именно тогда, когда нужно было. Иначе пользователь бы в систему не полез и тем более в службу поддержки бы не обращался. У него и так есть чем заняться из своих непосредственных служебных обязанностей. Если бы у него было много запросов, то вот в них приоритеты он бы может и расставил. Но у пользователя в большинстве случаев есть всего один запрос в поддержку. И общая картина по IT ему неизвестна, да и неинтересна, в отличие от сотрудников службы поддержки.
А ещё обычный пользователь обращается в службу поддержки нечасто и, даже стараясь быть объективным, может просто неправильно оформить запрос, указав не тот приоритет, а то и вовсе его не указав, или указав на всякий случай приоритет повыше (уж ошибаться так лучше в свою сторону). Ну и так далее.
Поэтому пользователи будут ставить какой угодно приоритет, только не тот, который должен быть, и нет никакой разумной силы, которая заставила бы их выставлять правильные приоритеты. Так что лучше и не давать им возможности ошибаться. Пусть лучше заполнят пару обязательных аттрибутов в запросе, и на выходе будет что-то довольно неплохо смахивающее на приоритет.
