Ритейл и e-commerceСколько людей нужно
Сколько операторов нужно ПВЗ в пиковый час: три или два?
Вечерний пик выдачи заказов: третий оператор снимет очередь или просто добавит простоя.
Что дал расчёт
- Ожидание в пиковый час
- было
2416,4мин - −32%
- Длина очереди в пике
- было
42,8чел - −29%
- Загрузка операторов в пике
- было
9172% - −19,2 п.п.
Что за процесс и где он ломался
Пункт выдачи заказов федерального маркетплейса: одна стойка, две зоны — выдача и возврат, поток около 320 клиентов в день. Работают два оператора по скользящему графику, третьего просят «на пики» уже полгода.
Дневной поток распределён крайне неравномерно: с 18:00 до 21:00 приходит почти половина клиентов. Утром операторы простаивают, вечером к стойке выстраивается очередь на улицу.
Вопрос, на который отвечали
Сколько операторов нужно ПВЗ в пиковый час: три или два?
Признаки, по которым стало понятно: дело не в людях
Спор шёл в терминах «людей не хватает», а данных не было ни у кого. Управляющий просил третьего оператора, региональный директор отвечал, что загрузка по дню — 46%, и нанимать некого. Обе стороны были правы: средняя загрузка низкая, а в пике система стоит.
Как процесс превратили в имитационную модель
Модель воспроизводит процесс выдачи заказов в ПВЗ с двумя операторами, работающими с 10:00 до 22:00. Поток клиентов неравномерен: с 18:00 до 21:00 интенсивность возрастает в 2,5 раза. Каждый клиент проходит сканирование (1,2 мин), затем либо получает заказ (2 мин), либо оформляет возврат (4 мин) с вероятностью 18%.
Симуляция учитывает случайную вариативность длительностей операций и накопление очереди при превышении пропускной способности. Мы сравнили текущий штат с вариантами расширения команды и изменением архитектуры стойки.
Какие данные взяли и что честно допустили
- Поток
- экспоненциальное распределение, средний интервал 4,05 мин, пик 18:00–21:00 (коэффициент 2,5).
- Длительности
- выдача ~2 мин, возврат ~4 мин (нормальное распределение, вариативность 0,4–0,5).
- Ресурсы
- 2 оператора, календарь 10:00–22:00, ставка 600 руб/ч.
- Доля возвратов
- 18% от всех обращений.
- Не моделировали
- обеденные перерывы и технические сбои оборудования.
Отчёт симуляции: что показал расчёт
Какие сценарии прогнали и чем они отличались
| Сценарий | Что меняли |
|---|---|
| Как есть: два оператора БазовыйОтчёт | Текущий режим: загрузка операторов 91%, 21,2% клиентов уходят, не дождавшись обслуживания. Очередь в среднем 4 человека. |
| Третий оператор на весь день РешениеОтчёт | Решение: добавление третьего сотрудника. Загрузка падает до 72%, доля отказов снижается до 7,5%, среднее ожидание сокращается до 16,4 мин. |
| Третий оператор только на пик Отчёт | Гибкий график: загрузка 71,7%, доля отказов 6,5%. Эффективность близка к полному дню, но требует сложного управления сменами. |
| Две стойки без найма Отчёт | Разделение потоков: загрузка оператора возвратов достигает 95,3%, общее ожидание вырастает до 70 мин, доля отказов 17%. Решение ухудшает сервис. |
Было и стало
- Было
- Стало
Ожидание в пиковый час , мин
Длина очереди в пике , чел
Загрузка операторов в пике , %
Ушли, не дождавшись , % клиентов
Средняя загрузка за смену , %
| Метрика | Было | Стало | Изменение |
|---|---|---|---|
| Ожидание в пиковый час , мин | 24 | 16,4 | −32% |
| Длина очереди в пике , чел | 4 | 2,8 | −29% |
| Загрузка операторов в пике , % | 91 | 72 | −19,2 п.п. |
| Ушли, не дождавшись , % клиентов | 21,2 | 7,5 | −65% |
| Средняя загрузка за смену , % | 91 | 72 | −19,2 п.п. |
Что показал расчёт
Текущий штат не справляется с пиковой нагрузкой
При двух операторах загрузка достигает 91%, что приводит к потере 21,2% клиентов. Среднее время ожидания в системе составляет 49,5 минут, а максимальная длина очереди доходит до 46 человек.
Третий оператор радикально снижает потери
Добавление третьего сотрудника снижает загрузку до 72% и уменьшает долю ушедших клиентов до 7,5%. Среднее ожидание падает до 16,4 минут, а максимальная очередь сокращается до 43 человек.
Разделение зон без найма ухудшает ситуацию
Сценарий с двумя стойками (выдача/возврат) создает новый узкое место: оператор возвратов загружен на 95,3%. Общее ожидание вырастает до 77 минут, а доля отказов остается высокой — 17%.
Гибкий график почти так же эффективен, как полный день
Третий оператор только на пик дает загрузку 71,7% и долю отказов 6,5%. Разница с полным днём минимальна, но требует более сложного администрирования смен.
Что оказалось не так, как считали
Сколько операторов нужно ПВЗ в пиковый час: три или два?Разделение выдачи и возврата на разные стойки без найма нового сотрудника ухудшает сервис. Вместо решения проблемы, это переносит узкое место на оператора возвратов (загрузка 95,3%), увеличивая среднее ожидание с 49,5 до 77 минут и сохраняя высокий уровень отказов (17%).
Что решили сделать и что получилось
Принято решение нанять третьего оператора на полную ставку. Это единственный сценарий, обеспечивающий стабильную загрузку 72% и снижение потерь клиентов до приемлемых 7,5%.
Внедрение третьего оператора снизило долю ушедших клиентов с 21,2% до 7,5%. Средняя загрузка операторов упала с 91% до 72%, а среднее время ожидания сократилось с 49,5 до 16,4 минут.
Приёмы оптимизации, которые здесь сработали
Добавить ресурсы
Ресурс перегружен (загрузка выше оптимальной). Добавление мощности позволит распределить нагрузку и сократить очередь. По закону Литтла: меньше очередь → короче время цикла.
Оптимальный штат (√)
Формула корня: n* = λ/μ + β√(λ/μ). Коэффициент β зависит от целевого уровня сервиса (1.28 для 90%, 1.64 для 95%). Точнее интуитивного "добавить ресурсы".
Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет
Вопрос «сколько людей нужно» не решается делением потока на производительность. Очередь рождается неравномерностью, а не нехваткой мощности в среднем. Средняя загрузка 46% и очередь на улице прекрасно уживаются: так устроена любая система массового обслуживания: об этом говорят и закон Литтла, и формула Кингмана.
Имитационное моделирование прогоняет тысячи клиентов по фактическому распределению прихода и показывает, что произойдёт с очередью в каждом сценарии — до того, как кого-то наняли.
Где этот вывод не работает
Вывод верен для процессов с выделенными ресурсами и большим потоком однотипных заявок. Если у вас пять уникальных сделок в квартал или сотрудники размазаны по десяти процессам сразу — такой расчёт не даст ничего: моделировать нечего.
Абсолютные значения зависят от конкретного ПВЗ. Переносить цифры на свой пункт нельзя — переносить можно метод.
Частые вопросы по этому расчёту
Чем это отличается от расчёта в Excel?
Excel работает со средними: средний поток и средняя загрузка не показывают пиковых перегрузок. Модель учитывает неравномерность прихода (пик в 2,5 раза) и вариативность длительностей. Именно это вызывает очереди до 46 человек и потерю 21,2% клиентов, чего не видно в таблицах.
Что будет, если поток клиентов в пиковый час вырастет вдвое?
При текущей конфигурации с тремя операторами система справляется с текущим пиком (загрузка 72%). Двукратный рост потока потребует пересмотра штата или процессов, так как текущий запас прочности ограничен.
Откуда взялась цифра 21,2% клиентов, которые уходят, не забрав заказ?
Это результат симуляции политики таймаута: клиенты, ожидающие более 20 минут, покидают очередь. В базовом сценарии 21,2% клиентов превышают этот лимит. При трёх операторах доля таких клиентов падает до 7,5%.
Как перенести выводы на другое ПВЗ с потоком 500 клиентов в день?
Абсолютные цифры зависят от длительностей операций. Метод переносится: нужно собрать параметры потока и длительностей, прогнать сценарии. При большем потоке эффект от третьего оператора будет ещё значимее, но порог окупаемости может сместиться.
Ваш процесс, ваши числа
Покажем на вашем процессе
Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.
- Присылаете диаграмму и три-четыре цифры про поток
- Собираем модель и прогоняем сценарии, которые вы назовёте
- Разбираем отчёт вместе и обсуждаем, что из него следует
Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.