Очередь обслуживания и SLA

[Adminuser]

Допустим у нас есть n сотрудников, которые могут обработать 1 обращение в час примерно. Ну и пусть SLA будет тоже час.
Поступает в час n*3 обращений, все они берутся в работу.
В итоге получается картина маслом - сотрудник через час имеет одно выполненное обращение и два просроченных. Как с этим бороться?
Как в реальных условиях кто решает задачу, когда возникает пиковая нагрузка? Или когда пиковая нагрузка возникает в определенные часы.
Увеличить SLA? Но как-то неправильно, когда сотрудник работает над одной задачей, а SLA тикает по нескольким одновременно.
Спасибо.

[alexus]

Добрый день!

Обычно заявки берутся в работу согласно Приоритета. Приоритет вычисляется по матрице Критичность(Сервиса)-Влияние(запроса для пользователя/лей)-Приоритет. В пиковой ситуации придётся в любом случае чем-то пожертвовать. SLA обычно формируются на основе расчётных данных с учётом производительности ресурсов и планируемой (либо экспериментально подтверждённой) загрузки.

[Adminuser]

Спасибо. Допустим , приоритет одинаковый. Но вопрос в другом. Мы рассчитали что 1 сотрудник успеет за час обработать 1 запрос. В день за 8 часов он выполняет 8 запросов и все хорошо.
До момента, пока не поступит 5 запросов единомоментно. Взяв все в работу, сотрудник за час выполняет один запрос и нарушает sla по 4 остальным. Как уберечься от этого?

[alexus]

До момента, пока не поступит 5 запросов единомоментно. Взяв все в работу, сотрудник за час выполняет один запрос и нарушает sla по 4 остальным. Как уберечься от этого?

Варианты
1. Переназначить на другие линии поддержки
2. Нанять больше сотрудиков
3. Пересмотреть SLA
3. "Принять и простить" - т.е. допустить просрочку один два раза, с соблюдением средней температуры по больнице

[Adminuser]

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

[alexus]

Это проблема вызвана устройством нашей Вселенной - время течёт всегда, для всех и сразу . Для клиента, который зарегал тикет времечко ведь тикает.
Вариант 5 - нанять людей Икс - Ртуть https://ru.wikipedia.org/wiki/Ртуть_(Marvel_Comics)

[Adminuser]

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

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

[alexus]

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

Нет, так не должно выходить. Надо строить правильные отчёты во-первых, во-вторых правильные KPI делать. Должны быть индивидуальные KPI за СВОЮ просрочку, и коллективные, если средний SLA по отделу плохой вышел.

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

С чего бы это? Можно планировщиком просроченным тикетам приоритет поднимать, есть вид отдельный - по эскалациям, и там самые просроченные наверху. Уведомления по эскалированным тикетам рассылаются обычно каждый день с утра всем, чтобы все понимали, что их ждёт убавка жалованья по итогам месяца.

[Adminuser]

Спасибо. Но все равно не понятно

Допустим с утра прилетает на группу из 2 человек 50 задач. Группа героически за полдня решает 10 из них, а остальные уже будут просрочены. Хотя если считать отдельно, то по каждой задаче сотрудник отработал как положено, но системой будет покарана группа. Но за что? Что входной поток без лимитов?

А увеличить сроки нельзя, т.к. по отдельной задаче на одну выделяется час и проблему я вижу в том, что на 50 задач время сотруднику не суммируется. Ну то есть хоть одну в час он должен решить, хоть 50.

Ну то есть должны быть какие-то лимиты , чтобы увидеть, что пришло работы сверх нормы.
А то выходит анекдотический случай, что за сколько ты Вася можешь одну машину разгрузить? За час. Вот тогда тебе 10 машин, но разгружай их не сразу, а по одной и час времени на все. Бред какой-то выходит.

[alexus]

Допустим с утра прилетает на группу из 2 человек 50 задач

Значит такие случаи надо учитывать при расчёте KPI, а не только факт просрочки. Вопрос, что делать, если каждое утро такая ситуация?

Ну то есть должны быть какие-то лимиты , чтобы увидеть, что пришло работы сверх нормы

Не лимиты, а дополнительные метрики для группы.

А то выходит анекдотический случай, что за сколько ты Вася можешь одну машину разгрузить? За час. Вот тогда тебе 10 машин, но разгружай их не сразу, а по одной и час времени на все. Бред какой-то выходит.

Из чего это следует? Из SLA? Если да, то это неверно. SLA - это не норматив на исполнение задачи, а максимально возможный, согласованный с заказчиком, срок её решения.

[Adminuser]

Спасибо! Получается, хороший вариант - из 50 поступивших заданий 2 берутся в работу и 48 в очереди висят и разбираются в порядке срочности и приоритета но уже с нарушенным временем принятия в работу. Если я все верно понял.

А дальше другая сложность, первый сотрудник справился за 10 минут и не спешит закрывать задание, т.к. зачем, если можно сделать мини отдых... В итоге в очереди висят 48 задач, время реагирования прогорает, но сотрудник отдыхает.

Хотя наверное тут можно всё-таки стимулировать делать в день больше (это ещё без учёта сложности задач..)

[alexus]

А дальше другая сложность, первый сотрудник справился за 10 минут и не спешит закрывать задание, т.к. зачем, если можно сделать мини отдых... В итоге в очереди висят 48 задач, время реагирования прогорает, но сотрудник отдыхает.

Я писал выше

во-вторых правильные KPI делать. Должны быть индивидуальные KPI за СВОЮ просрочку, и коллективные, если средний SLA по отделу плохой вышел.

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

[Adminuser]

Спасибо.
Как можно поступить в случае с временем реакции? Если никто не берёт в работу новую заявку, то можно это отметить в kpi отдела. Но если во время пришедшей заявки всё и так выполняют по одному знанию то как тогда быть?

[alexus]

Поясните, чем ваша компания занимается, в чём суть вопросов и в чём реальные проблемы.

[Adminuser]

Консультируем клиентов. Поступают запросы от клиентов и нужно их проконсультировать в телефонном режиме.

Что имеем - желание работать по ITIL: клиенты в систему подают запрос, формируется заявка и падает на отдел, который должен принять эту заявку в работу согласно определенного времени. Если 2 человека с утра не заняты, всё ок. Падает задача, кто-то хватает, выполняет за минут 30, закрывает.
Все меняется, если приходит 10 задач. Тогда каждый берет по одной и 8 висят и вот-вот протратится время на ответ по тикету.
Чтобы не просрочить это время, каждый вынужден взять оставшиеся задачи в работу также, причем при этом разговаривая по телефону приходится параллельно смотреть что там падает, и принимать в работу - как-то в этом моменте ITIL не понравился совсем.
А если не смотреть во время обслуживания клиента - то тогда пропустишь и протратишь время

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

Нигде в доках про итил не нахожу рекомендаций как же правильно всё организовать.

[alexus]

У вас есть с клиентом подписанный SLA в договорах?

[Adminuser]

Есть. SLA - час. Время реакции - 4 минуты. Т.е. кто-то из двоих должен раз в 4 минуты посматривать в почту.

[alexus]

При SLA на решение в 1 час, при двух сотрудниках и 10 тикетах в час у вас одна консультация не может занимать более 12 минут. Вы такой расчёт делали, когда SLA подписывали?

[Adminuser]

По какой формуле делать рассчет? Если sla будет не час, а полтора, как изменится всё? Если 40 заявок прилетят в первые 5 минут, а ещё 10 на 50й минуте, тоже будет ситуация иная?

Ещё момент - есть одна сложная консультация , по ней sla 4 часа. И есть 59 простых. В какой очередности обслуживать при потоке 50 обращений в час? Если заняться сложной, то можно сосредоточившись на ней за час профейлить остальные все , и наоборот, если разбирать простые, то до сложных дело не дойдет.

[Adminuser]

Вообще работа в таком режиме напоминает экзамен, когда у тебя есть 5 задач и есть час времени на решение. Если решать задачи последовательно и застрять на первой, то экзамен провален. Если пропустить там, где застрял, ну на 4 сдашь.
Тут так же, но разве это правильно, что мы одного клиента засунем на задний план?

[alexus]

Вы OTRS ведь используете? Поиграйтесь с отчётами или запросами в базу. Посмотрите, когда у вас идёт пиковая нагрузка по тикетам, как это отражается на SLA в итоге.

Тут так же, но разве это правильно, что мы одного клиента засунем на задний план?

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