Ритейл и e-commerceСколько людей нужно
Сколько операторов нужно ПВЗ в пиковый час: три или два?
Вечерний пик выдачи заказов: третий оператор снимет очередь или просто добавит простоя.
Что дал расчёт
- Ожидание в пиковый час
- было
14,24,1мин−71% - Длина очереди в пике
- было
93чел−67% - Загрузка операторов в пике
- было
9778%−19 п.п.
Что за процесс и где он ломался
Пункт выдачи заказов федерального маркетплейса: одна стойка, две зоны — выдача и возврат, поток около 320 клиентов в день. Работают два оператора по скользящему графику, третьего просят «на пики» уже полгода.
Дневной поток распределён крайне неравномерно: с 18:00 до 21:00 приходит почти половина клиентов. Утром операторы простаивают, вечером к стойке выстраивается очередь на улицу.
Вопрос, на который отвечали
Сколько операторов нужно ПВЗ в пиковый час: три или два?
Признаки, по которым стало понятно: дело не в людях
Спор шёл в терминах «людей не хватает», а данных не было ни у кого. Управляющий просил третьего оператора, региональный директор отвечал, что загрузка по дню — 46%, и нанимать некого. Обе стороны были правы: средняя загрузка низкая, а в пике система стоит.
Как процесс превратили в имитационную модель
Модель собрали на существующей BPMN-схеме процесса выдачи — рисовать заново ничего не пришлось. В неё добавили то, чего в схеме нет: интенсивность прихода клиентов по часам, длительность выдачи и возврата, вероятность возврата, календарь смен и ёмкость стойки.
Ключевое отличие от расчёта в таблице: модель учитывает, что клиенты приходят неравномерно и мешают друг другу. Именно это и рождает очередь — среднее по дню такой эффект не показывает никогда.
Какие данные взяли и что честно допустили
- Поток заявок
- восстановлен из выгрузки сканирований за 30 дней, распределение по часам — фактическое
- Длительность выдачи
- замеры по 40 обслуживаниям, разброс учтён распределением, а не средним
- Доля возвратов
- 18%, взята из учётной системы за квартал
- Не моделировали
- обеденные перерывы операторов и отказы оборудования
Отчёт симуляции: что показал расчёт
Какие сценарии прогнали и чем они отличались
| Сценарий | Что меняли |
|---|---|
| Как есть: два оператора Базовый | Текущий график, две смены внахлёст с 16:00 |
| Третий оператор на весь день | Полная ставка, покрывает всю смену |
| Третий оператор только на пик | Выход с 17:30 до 21:30, четыре часа |
| Две стойки без найма | Разделение выдачи и возврата по зонам, те же два человека |
Было и стало
- Было
- Стало
Ожидание в пиковый час , мин
Длина очереди в пике , чел
Загрузка операторов в пике , %
Ушли, не дождавшись , % клиентов
Средняя загрузка за смену , %
| Метрика | Было | Стало | Изменение |
|---|---|---|---|
| Ожидание в пиковый час , мин | 14,2 | 4,1 | −71% |
| Длина очереди в пике , чел | 9 | 3 | −67% |
| Загрузка операторов в пике , % | 97 | 78 | −19 п.п. |
| Ушли, не дождавшись , % клиентов | 6,4 | 1,1 | −83% |
| Средняя загрузка за смену , % | 46 | 48 | +2 п.п. |
Что показал расчёт
Узкое место — совмещение выдачи и возврата на одной стойке
Возврат занимает втрое больше времени, чем выдача, и блокирует очередь целиком: пока оформляется один возврат, восемь человек за выдачей просто стоят.
Третий оператор на полный день сокращает ожидание всего до 9 минут — деньги уходят в простой
Днём он загружен на 30%, а вечером всё равно упирается в одну стойку: очередь ограничена рабочим местом, и руки тут ни при чём.
Разделение потоков даёт 4 минуты ожидания тем же составом
Эффект сопоставим с наймом, но стоит одной перестановки мебели и правки регламента.
Что оказалось не так, как считали
Сколько операторов нужно ПВЗ в пиковый час: три или два?Третий человек упёрся бы в ту же стойку, что и первые два. Очередь сократилась бы на треть, а зарплата выросла бы на целую ставку. Сработало разделение выдачи и возврата, которое не стоило ничего.
Что решили сделать и что получилось
Разделили зоны выдачи и возврата, перевели вторую смену на выход к началу пика. Приём «Добавить ресурсы» отложили: расчёт показал, что он упирается в ту же стойку.
Найм третьего оператора отложили и вернулись к вопросу через квартал, уже с цифрами. Порог, после которого найм действительно понадобится, посчитали приёмом «Оптимальный штат (√)»: это 480 клиентов в день, до него хватает двоих.
Приёмы оптимизации, которые здесь сработали
Добавить ресурсы
Ресурс перегружен (загрузка выше оптимальной). Добавление мощности позволит распределить нагрузку и сократить очередь. По закону Литтла: меньше очередь → короче время цикла.
Оптимальный штат (√)
Формула корня: n* = λ/μ + β√(λ/μ). Коэффициент β зависит от целевого уровня сервиса (1.28 для 90%, 1.64 для 95%). Точнее интуитивного "добавить ресурсы".
Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет
Вопрос «сколько людей нужно» не решается делением потока на производительность. Очередь рождается неравномерностью, а не нехваткой мощности в среднем. Средняя загрузка 46% и очередь на улице прекрасно уживаются: так устроена любая система массового обслуживания: об этом говорят и закон Литтла, и формула Кингмана.
Имитационное моделирование прогоняет тысячи клиентов по фактическому распределению прихода и показывает, что произойдёт с очередью в каждом сценарии — до того, как кого-то наняли.
Где этот вывод не работает
Вывод верен для процессов с выделенными ресурсами и большим потоком однотипных заявок. Если у вас пять уникальных сделок в квартал или сотрудники размазаны по десяти процессам сразу — такой расчёт не даст ничего: моделировать нечего.
Абсолютные значения зависят от конкретного ПВЗ. Переносить цифры на свой пункт нельзя — переносить можно метод.
Частые вопросы по этому расчёту
Чем это отличается от расчёта в Excel?
Excel работает со средними: средний поток 320 клиентов в день при средней загрузке 46% кажется нормальным. Но клиенты приходят неравномерно: с 18:00 до 21:00 приходит половина суточного потока. Модель прогоняет тысячи клиентов по фактическому распределению и показывает, что в пиковый час очередь упирается в 9 человек, хотя в среднем система недогруженна. Excel никогда такой эффект не покажет.
Что будет, если поток клиентов в пиковый час вырастет вдвое?
Разделение зон упрётся в то же рабочее место, но максимум давления вырастет. Расчёт показал пороговый поток — 480 клиентов в день — после которого третий оператор становится необходимостью. Вдвое от текущих 320 переведёт ПВЗ за эту границу, найм понадобится, но только когда экономика это требует.
Откуда взялась цифра 6,4% клиентов, которые уходят, не забрав заказ?
Восстановлено из системы отслеживания возвратов: клиент не приходит забирать в день выдачи — это отмечается как уход. При ожидании в пиковый час 14,2 минут уходит 6,4% клиентов, при оптимизации до 4,1 минут уходит только 1,1%. Эта цифра показывает прямое влияние очереди на поведение: каждая минута ожидания — стоимость в потерянных клиентах.
Как перенести выводы на другое ПВЗ с потоком 500 клиентов в день?
Абсолютные цифры ожидания переносить нельзя — они зависят от конкретных длительностей операций вашего ПВЗ. Но метод переносится целиком: собрать параметры (распределение потока по часам, длительность выдачи и возврата в вашем случае), прогнать те же четыре сценария. Пороговая цифра найма может отличаться на 30–40% в зависимости от структуры вашего потока.
Ваш процесс, ваши числа
Покажем на вашем процессе
Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.
- Присылаете диаграмму и три-четыре цифры про поток
- Собираем модель и прогоняем сценарии, которые вы назовёте
- Разбираем отчёт вместе и обсуждаем, что из него следует
Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.