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

Какой критерий может проактивно показать, что группа перестает справляться с поступающим потоком обращений?

В редакцию портала поступил вопрос:

Добрый день! Какой критерий может проактивно показать, что группа перестает справляться с поступающим потоком обращений? Как у вас налажен этот процесс? Хотелось бы выявлять перегрузку до того, как будут сорваны договорные сроки, настроить какой-то “красный сигнал”, что вот на данный момент дела начинают идти плохо.

В магазине это растущая очередь в кассе до определенной величины, сигнал того, что нужно подключать еще кассы. А как на практике используете вы, какие индикаторы? (возможно размер очереди или еще какие-то параметры).

Спасибо!

IT Service Management
Учебные курсы от соавторов ITIL 4

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

  • Александр Трофимов

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

  • Сергей

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

    • Сергей

      Ну, и регулярно (раза 4 реже периода планирования) оцениваем динамику плановых и фактических затрат аремени, а также дельту между ними, и пытаемся предсказывать будущее.

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

    Я считаю так: кол-во решенных обращений группой за период (не важно когда созданных)/разделить на кол-во зарегистрированных обращений на группу за период = доля решения, %. Если доля решения >100%, то бассейн заявок сливается; если <100%, то бассейн нерешенных заявок наполняется и группе не хватает мощности, чтобы справиться с потоком.
    Проактивность в том, что не нужно допускать, когда бассейн начнет выливаться на Вас через край 🙂

  • С

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

    Я смотрю на время до реакции агента. Первая отметка – время регистрации факта обращения (не open request, а приём звонка или получение номера в очереди). В зависимости от ситуации оно может расти или уменьшаться, но изменяться – будет.


Добавить комментарий для СОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM