БанкиГде узкое место
Где в рассмотрении заявки на кредит МСБ теряется неделя?
Срок рассмотрения — 12 рабочих дней, работы в них меньше двух. Куда уходит остальное время.
Что дал расчёт
- Срок от подачи до решения
- было
1,40,9дней - −39%
- Время ожидания в очередях
- было
31,218,4часов - −41%
Что за процесс и где он ломался
Процесс рассмотрения кредитной заявки малого бизнеса: восемь этапов, четыре подразделения, срок от подачи до решения — 12 рабочих дней. Конкуренты обещают пять, и продажи теряют сделки на сроке, а не на ставке.
Вопрос, на который отвечали
Где в рассмотрении заявки на кредит МСБ теряется неделя?
Признаки, по которым стало понятно: дело не в людях
Каждое подразделение отчитывалось, что укладывается в свой норматив. Сумма нормативов давала 3,5 дня, факт — двенадцать. Восемь с половиной дней не принадлежали никому и потому не улучшались.
Как процесс превратили в имитационную модель
Моделируем процесс рассмотрения кредитной заявки МСБ от приёма до решения. Восьмиступенчатый маршрут проходит через четыре подразделения: менеджеры, скоринг, залоговая служба и риск-менеджмент. Заявки поступают с интервалом около 33 минут в течение рабочего дня.
Ключевая особенность модели — учёт календарных окон ресурсов. Залоговая служба работает только с 13:00 до 17:00, что создаёт искусственные задержки. Мы протестировали четыре сценария: текущий процесс, параллельный запуск независимых проверок (скоринг и залог), найм дополнительного сотрудника в залог и комбинированное решение (параллельность + расширение рабочего окна залоговой службы до 11:00–17:00).
Какие данные взяли и что честно допустили
- Поток заявок
- экспоненциальное распределение, в среднем одна заявка каждые 33 минуты в рабочее время (09:00–18:00, пн–пт).
- Ресурсы
- 3 кредитных менеджера, 4 сотрудника залоговой службы (окно 13:00–17:00), 2 аналитика скоринга, 1 риск-менеджер.
- Длительности этапов
- нормальное распределение, вариативность 30–40% (например, проверка залога в среднем 60 минут).
- Не моделировали
- сезонность спроса, отпуска сотрудников, сложные возвраты на доработку документов.
- Календарь
- стандартная пятидневка, перерывы и выходные не учитываются в времени обработки, но влияют на очереди.
Отчёт симуляции: что показал расчёт
Какие сценарии прогнали и чем они отличались
| Сценарий | Что меняли |
|---|---|
| Как есть БазовыйОтчёт | Базовый процесс: средний срок решения 1,4 дня, из которых 31,2 часа — чистое ожидание. Залоговая служба загружена на 90% и является критическим узким местом. |
| Параллельная проверка залога и скоринг Отчёт | Скоринг и финанализ идут параллельно. Срок сократился до 1,1 дня, но залоговая служба всё ещё загружена на 84%, ограничивая дальнейший рост. |
| Усиление узкого этапа Отчёт | Добавлен пятый специалист в залоговую службу. Срок остался прежним (1,4 дня), так как календарное окно работы службы не изменилось. |
| Параллельность и усиление вместе РешениеОтчёт | Параллельный старт проверок + расширение рабочего окна залоговой службы. Срок упал до 0,9 дня, загрузка службы снизилась до 64%. |
Было и стало
- Было
- Стало
Срок от подачи до решения , дней
Время ожидания в очередях , часов
Срок решения, 95-й процентиль , дней
Ожидание у залоговой службы , часов
Загрузка залоговой службы , %
| Метрика | Было | Стало | Изменение |
|---|---|---|---|
| Срок от подачи до решения , дней | 1,4 | 0,9 | −39% |
| Время ожидания в очередях , часов | 31,2 | 18,4 | −41% |
| Срок решения, 95-й процентиль , дней | 3,7 | 2,9 | −22% |
| Ожидание у залоговой службы , часов | 1,5 | 0,8 | −45% |
| Загрузка залоговой службы , % | 90 | 64 | −26,7 п.п. |
Что показал расчёт
Ожидание съедает 80% времени заявки
Средняя заявка находится в системе 1,4 дня, но реальная работа над ней занимает менее 3,5 часов. Оставшиеся 31,2 часа — это время простоя в очередях и ожидание начала рабочего дня ресурсов.
Найм не помогает, если узко календарь
Добавление пятого специалиста в залоговую службу (сценарий s3) не сократило срок решения вообще. Причина: новые сотрудники работают в том же узком окне 13:00–17:00, и заявки всё равно ждут начала этого окна.
Параллельность даёт эффект только при разгрузке узкого места
Просто запустив скоринг параллельно с залогом (сценарий s2), мы сократили срок до 1,1 дня, но залоговая служба осталась загруженной на 84%. Полный эффект (0,9 дня) дался только после расширения её рабочего окна.
95-й процентиль снизился с 3,7 до 2,9 дней
Оптимизация не только ускорила среднюю заявку, но и стабилизировала процесс. Худшие случаи (95-й процентиль) стали на 22% быстрее, что критично для удержания клиентов, не готовых ждать неделю.
Что оказалось не так, как считали
Где в рассмотрении заявки на кредит МСБ теряется неделя?Самый загруженный ресурс (залоговая служба, 90%) не был самым долгим по обработке (60 минут против 30 минут у скоринга). Ускорение самой долгой операции не помогло бы, потому что проблема была не в скорости рук, а в том, что служба работает всего 4 часа в день. Заявки копятся не потому, что их много, а потому что «окно» для их обработки слишком узкое.
Что решили сделать и что получилось
Решили внедрить параллельную проверку залога и скоринга и расширить рабочее окно залоговой службы с 13:00–17:00 до 11:00–17:00. Найм новых сотрудников не требуется — достаточно перераспределить время существующих специалистов.
Средний срок решения сократился с 1,4 до 0,9 дня (−39%). Время ожидания в очередях упало с 31,2 до 18,4 часов. Загрузка залоговой службы снизилась с 90% до 64%, устранив критическое узкое место.
Приёмы оптимизации, которые здесь сработали
Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет
Узкое место нельзя найти опросом: каждое подразделение видит только свой участок и честно укладывается в норматив. Модель видит процесс целиком вместе с очередями между этапами — там и обнаруживаются потерянные дни.
И только модель отвечает на вопрос «что будет, если»: она показывает, что ускорение неузкого этапа бесполезно, ещё до того, как на это потратили квартал.
Счёт по этому процессу такой: из 12 дней срока работой заняты 1,7, остальные 10,3 заявка ждёт в очередях между подразделениями.
Где этот вывод не работает
Если заявки принципиально разные и каждая требует своего маршрута, усреднённая модель начнёт врать. В этом случае процесс сначала сегментируют, а потом считают по сегментам.
Расчёт не учитывает отпуска и сезонность: в июле и январе фактический срок будет выше расчётного.
Частые вопросы по этому расчёту
Разве это не задача process mining?
Process mining покажет, как процесс шёл: заявка обрабатывается 3,5 часа и ждёт 31,2 часа. Это факт истории. Но он не отвечает на вопрос «что будет, если сделать иначе» — для этого нужна модель. Mining скажет «между залогом и оценкой заявка висит долго», модель скажет «если запустить их параллельно и сдвинуть старт залога, это станет 18,4 часов».
Если ускорить параллельную проверку залога на 2 дополнительных дня, насколько сократится общий срок?
В текущей модели (сценарий s4) срок уже ограничен другими этапами. Дальнейшее ускорение залога не даст эффекта, так как риск-менеджер загружен на 74% и становится новым ограничением. Чтобы сократить срок ещё, нужно оптимизировать этап риск-оценки.
Почему залоговая служба, нагруженная на 90%, не рассматривалась как узкое место?
Залоговая служба находилась в конце цепочки, каждый отдел отчитывался в своих нормативах. Служба работала в сверхурочные, чтобы укладываться в общие сроки — но это казалось её проблемой, а не проблемой процесса. Модель показала конкретный факт: эта служба отдаёт процессу только 4 часа в день. Остальное время — ожидание. Узкое место видно только если считать весь процесс, а не отдел.
Какие данные собрать, чтобы перенести модель на другой тип кредитов?
Маршрут этапов (какие проверки и в каком порядке), длительность каждого (честная оценка на 10–15 делах достаточна), график специалистов. Если маршруты сильно отличаются — малый и средний бизнес часто имеют разные схемы — каждый сегмент моделируется отдельно, но расчёт критического пути работает универсально.
Ваш процесс, ваши числа
Покажем на вашем процессе
Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.
- Присылаете диаграмму и три-четыре цифры про поток
- Собираем модель и прогоняем сценарии, которые вы назовёте
- Разбираем отчёт вместе и обсуждаем, что из него следует
Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.