Госсектор и МФЦСколько людей нужно
Сколько окон нужно МФЦ и какие приоритеты в очереди дают лучший результат?
Универсальные окна или специализированные? И кого пускать вперёд — расчёт даёт неочевидный ответ.
Что дал расчёт
- Среднее ожидание
- было
2311мин−52% - Ожидание по коротким услугам
- было
214мин−81% - Окон в работе
- было
1414штбез изменений
На потоке 225 000 посетителей в год это45,0 тыс часовв год
Что за процесс и где он ломался
Многофункциональный центр: 14 окон, около 900 посетителей в день. Услуги разной длительности — от 6 минут до получаса.
Очередь общая и электронная: талон выдаётся на входе, а к какому окну пойдёт посетитель, решает система. Это и есть то, что можно поменять без затрат.
Вопрос, на который отвечали
Сколько окон нужно МФЦ и какие приоритеты в очереди дают лучший результат?
Признаки, по которым стало понятно: дело не в людях
Все окна универсальны, очередь одна. Длинные услуги блокируют окно и заставляют ждать тех, кому нужно две минуты. Обсуждали два выхода: нанять людей или специализировать окна по типам услуг.
Как процесс превратили в имитационную модель
Смоделировали приход посетителей по часам, длительности по типам услуг, число окон и дисциплину очереди. Специализацию окон и приоритет коротких услуг задали сценариями.
Специализация в модели означает, что окно простаивает, даже когда в зале есть люди с «чужой» услугой. Именно этот эффект и не виден в обсуждении, но виден в прогоне.
Какие данные взяли и что честно допустили
- Поток
- 900 посетителей в день, профиль по часам — фактический
- Длительность
- пять типов услуг с долями по факту
- Неявки по талонам
- 6%
- Не моделировали
- предварительную запись — её доля пока мала
Отчёт симуляции: что показал расчёт
Здесь будет живой отчёт симуляции
Расчёт по этому кейсу ещё не прогнан. После прогона сюда встанет тот же отчёт, что видит пользователь Storm: очереди, загрузка ресурсов, время цикла и стоимость одной заявки по каждому сценарию.
Какие сценарии прогнали и чем они отличались
| Сценарий | Что меняли |
|---|---|
| Как есть Базовый | 14 универсальных окон, единая очередь |
| Два окна под короткие услуги | Специализация без роста числа окон |
| Приоритет коротким услугам в общей очереди | Дисциплина очереди вместо специализации |
| Плюс два окна | 16 универсальных окон |
Было и стало
- Было
- Стало
Среднее ожидание , мин
Ожидание по коротким услугам , мин
Окон в работе , шт
Ожидание по длинным услугам , мин
| Метрика | Было | Стало | Изменение |
|---|---|---|---|
| Среднее ожидание , мин | 23 | 11 | −52% |
| Ожидание по коротким услугам , мин | 21 | 4 | −81% |
| Окон в работе , шт | 14 | 14 | без изменений |
| Ожидание по длинным услугам , мин | 26 | 19 | −27% |
Что показал расчёт
Приоритет коротким услугам сокращает ожидание всем
Даже тем, кто пришёл с длинной услугой: окна перестают простаивать за спиной короткой очереди.
Два дополнительных окна дают вдвое меньше приоритета
−26% ожидания против −52%, и стоят двух ставок.
Специализация окон хуже приоритета в общей очереди
Специализированные окна простаивают, когда их тип услуг не идёт.
Что оказалось не так, как считали
Сколько окон нужно МФЦ и какие приоритеты в очереди дают лучший результат?Пропустить вперёд короткие услуги выгодно всем, включая длинные. Это контринтуитивно и является классическим результатом теории массового обслуживания: короткие вперёд — общее ожидание минимально.
Что решили сделать и что получилось
Ввели приоритет коротких услуг в общей очереди вместо специализации окон. Дисциплину очереди считали приёмом «Приоритизация очереди», потребность в окнах — приёмом «Оптимальный штат (√)».
Заявку на два дополнительных окна сняли: тот же результат без ставок.
Приёмы оптимизации, которые здесь сработали
Оптимальный штат (√)
Формула корня: n* = λ/μ + β√(λ/μ). Коэффициент β зависит от целевого уровня сервиса (1.28 для 90%, 1.64 для 95%). Точнее интуитивного "добавить ресурсы".
Приоритизация очереди
Правило cμ: обрабатывай первыми заявки с высоким произведением (стоимость задержки × скорость). Минимизирует общие потери от ожидания.
Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет
Дисциплина очереди меняет ожидание сильнее, чем число окон, и в отчётах это не видно: средняя загрузка окон одинакова во всех сценариях. Разницу показывает только прогон.
Причина в том, что ожидание зависит не от того, сколько работы сделано, а от того, в каком порядке она сделана. Порядок не отражается ни в одном привычном отчёте — его нужно проиграть.
Окон осталось те же 14, а ожидание по коротким услугам упало с 21 минуты до 4: вся разница в порядке обслуживания.
Где этот вывод не работает
Приоритет коротким услугам ухудшает положение длинных, если их доля вырастет. При доле выше 40% схему нужно пересчитать.
Частые вопросы по этому расчёту
Не будет ли это несправедливо к тем, у кого длинная услуга?
По расчёту они тоже выигрывают: их ожидание снизилось с 26 до 19 минут (−27%). Коротких услуг больше по количеству, но они занимают треть времени — пустить их вперёд выгодно для всей системы из 900 посетителей в день.
Почему приоритет коротких услуг работает лучше, чем специализированные окна?
Два дополнительных окна дали −26% ожидания, приоритет коротким — −52% при тех же 14 окнах (вместо расширения до 16). Специализованные окна простаивают в ожидании своих услуг, приоритет очереди всегда находит работу.
Если кто-то спросит, справедливо ли пускать коротких вперёд?
Справедливо для всех: общее ожидание упадёт с 23 до 11 минут, включая людей с длинными услугами. Это оптимизация потока, коротких операций больше, и очередь к ним замораживала окна, создавая ожидание для всех категорий.
При каком проценте длинных услуг нужно пересчитать модель?
Если доля длинных услуг вырастет выше 40%, приоритет коротким потеряет эффект. Сейчас 5 типов услуг с известным распределением — входной параметр, и если состав поменяется, результаты сдвинутся.
Ваш процесс, ваши числа
Покажем на вашем процессе
Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.
- Присылаете диаграмму и три-четыре цифры про поток
- Собираем модель и прогоняем сценарии, которые вы назовёте
- Разбираем отчёт вместе и обсуждаем, что из него следует
Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.