Философия SLA: про приоритеты запросов

Автор: admin от 8-02-2018, 16:55, посмотрело: 268

Продолжаю цикл статей про SLA, публикуя то, что не уместилось в основную статью Как написать хороший SLA.



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



Философия SLA: про приоритеты запросов

За много-много лет работы в поддержке самых разных ИТ-систем, мне очень понравилась система из четырёх приоритетов, о которой речь и пойдёт ниже. Эта система настолько хорошо показала себя на практике в самых разных проектах, что я искренне удивляюсь, встречаясь с другими подходами к приоритетам. Так что я готов приложить определённое количество усилий для популяризации таких определений приоритетов. Чтобы они чаще всеми использовались и чаще встречались в жизни.

Как написать хороший SLA". Ну и в начале этой статьи. Это три основных приоритета (Низкий, Средний, Высокий) и один экстраординарный (Высший) для тех самых случаев, когда все всё бросают и начинают заниматься только этой проблемой до победного конца.



Такая система приоритетов является довольно-таки интуитивно понятной. Меньше трёх регулярных приоритетов использовать нехорошо, плохо масштабируется. Больше трёх уже не особо нужно, да и Оккам не велел.



Определения приоритетов



Осталось обосновать определения приоритетов. Сделать это можно разными способами. Можно просто определить, никак не обосновывая. Можно и обосновать. Не претендуя на всеобщность я приведу один из подходов. Интересен он только тем, что его можно повторить для других специфических условий. Подход будет такой. Будем придумывать критерий, который позволит из общей массы запросов выделить те, которые требуют более пристального внимания. Потом из этих отобранных выбирать те, которые требуют ещё более пристального внимания. Ход мысли, надеюсь, понятен. А дальше из этих критериев и сделаем определения приоритетов. Чтобы определения были ясными, будем стараться каждый раз выбрать такой критерий, чтобы он был максимально простым и понятным.



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



Вернёмся к делению на приоритеты. Перво-наперво поделим все запросы на важные и неважные. Все неважные безжалостно закрываем.



Лирическое отступление





Философия SLA: про приоритеты запросов Неважных запросов не бывает. Если проблема ни для кого не является важной, не надо на неё тратить время. Это вопрос эффективности работы. Самый эффективный способ решения неважных проблем — это признать проблему никому не нужной и закрыть запрос. Никогда не оставляйте открытых "на потом" проблем. Вот когда будете готовы ими заниматься, вот тогда и заведёте. А если вдруг не вспомните, то значит и не надо было. Закрывайте. Иначе никакой SLA не поможет. Мир несовершенен, нечего и пытаться устранить в нём все несправедливости (см. рис.). Хотя согласиться с этим и тяжело. Мой внутренний перфекционист тоже было возражал, но ровно до тех пор, пока я не поставил его перед фактом, что делать ненужную работу будем в свободное от основной работы время. Если так уж мучает совесть, то помечайте такие закрытые запросы, чтобы к ним позже можно было вернуться. Когда, например, внезапно разгребли ворох всех текущих проблем и больше нечем стало заняться. Но так случаться не должно, если регулярно нечем заняться, то это значит, что часть ресуров нужно освободить для чего-то другого, более полезного.

Теперь у нас все запросы важные, выделим из них срочные и критичные. Потому что не всякая важная проблема обязана быть срочной или критичной. Как раз наоборот, критичные или срочные проблемы появляются не так уж и часто. Если Вам почему-то кажется, что все проблемы срочные и критичные, то просто попытайтесь письменно сформулировать, в чём важность и критичность каждой. Вот те, для которых не приходится натужно придумывать причину важности или брать нахрапом (сами что ли не понимаете, это же очень критично!), те и будут критичными.



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



Ещё лирическое отступление





Вот этот принцип паритета, он вообще очень важен в процессе сопровождения любых IT-систем. Ни одной из сторон процесса не должно быть больше нужно, чем другой. Должен быть паритет. Если одна сторона говорит "ну дальше вы сами, а я — домой, утром чтобы всё было сделано", то приоритет сразу надо понижать и тоже идти домой. Какой смысл ударно трудиться, найти решение глубокой ночью, чтобы оно так и осталось невостребованным до следующего рабочего дня? Или все работаем, или все расходимся. Особенно хорошо это правило работает в авральном режиме. Аврал и надо перейти на круглосуточную работу? Окей, отдел ИТ готов при необходимости работать в таком режиме, для того и создавался. Готов ли бизнес?.. Обратную ситуацию (когда бизнесу надо, а ИТ не готов) я даже не рассматриваю,. Такой ИТ надо сразу разгонять в полном составе, так как не понимающий кто для кого работает отдел ИТ некомпетентен.

Вернёмся обратно к приоритетам. Нужно ли выделять в отдельный приоритет что-то ещё более важное? Да вроде бы уже и не нужно. Дальше только аврал.



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




  • важные, но критичные запросы (сюда по-умолчанию попадают все новые запросы);

  • срочные и критичные (требуется обоснование почему);

  • срочные и критичные, для которых нет обходного пути (тоже само собой с обоснованием).



Ну и конечно сверхприоритет:




  • всё бросаем и занимаемся только этой проблемой без сна и отдыха.



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



Итого получилось четыре понятных приоритета. Формулировки определений на канцелярите (чтобы можно было взять в свой регламент и исправить по месту) см. в табличке выше.



Названия можно взять предложенные мной, а можно нейтральные числовые — первый (самый высокий), второй, третий и четвёртый. А то бывает, что у кого-то рука не поднимается открывать запросы с приоритетом, который называется "Низким". Я, например, привык пользоваться обоими.



Приоритеты для бизнес-пользователей систем



Всё вышесказанное про приоритеты относится к тем людям, которые занимаются технической поддержкой по долгу службы. Сотрудники службы поддержки должны ориентироваться в общей картине по IT и уметь выставлять приоритеты объективно и единообразно в соответствии с внутренними регламентами. Пользователям же IT-систем от бизнеса лучше не давать возможность выбирать приоритет, а выставлять его автоматически. Хорошим приближением является диагональная матрица влияния и критичности из классического определения приоритета ITIL. Пример уже был приведён выше.



Почему так? Дело не в недоверии пользователям, мол, сирые они и убогие. Просто для пользователя ИТ-системы любая проблема, которая мешает лично ему, всегда будет самого высокого приоритета. Потому что мешает ему выполнять его собственную работу, причём вот прямо сейчас мешает. И ведь как всегда невовремя сломалось, именно тогда, когда нужно было. Иначе пользователь бы в систему не полез и тем более в службу поддержки бы не обращался. У него и так есть чем заняться из своих непосредственных служебных обязанностей. Если бы у него было много запросов, то вот в них приоритеты он бы может и расставил. Но у пользователя в большинстве случаев есть всего один запрос в поддержку. И общая картина по IT ему неизвестна, да и неинтересна, в отличие от сотрудников службы поддержки.



А ещё обычный пользователь обращается в службу поддержки нечасто и, даже стараясь быть объективным, может просто неправильно оформить запрос, указав не тот приоритет, а то и вовсе его не указав, или указав на всякий случай приоритет повыше (уж ошибаться так лучше в свою сторону). Ну и так далее.



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



Источник: Хабрахабр

Категория: Информационная безопасность » Криптография

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

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *