Свяжитесь с нами
Продукт
Возможности
Мероприятия
Материалы
Крупные предприятия
Свяжитесь с нами

БанкиВыполним ли SLA

Какую долю расчётных счетов можно открывать в день обращения?

Обещание «счёт за день» выполняется в трети случаев. Расчёт показывает, что мешает и сколько это стоит.

Что дал расчёт

Срок открытия, 95-й процентиль
было68,23,1ч
−95%

Что за процесс и где он ломался

Открытие расчётного счёта юрлицу: приём документов, проверка комплектности, комплаенс-проверка, открытие счёта. Банк рекламирует открытие в день обращения.

Поток неравномерен: больше половины клиентов приходит в первые часы работы отделения, а комплаенс-проверка запускается один раз в день.

Вопрос, на который отвечали

Какую долю расчётных счетов можно открывать в день обращения?

Признаки, по которым стало понятно: дело не в людях

Фактически в день обращения открывается 34% счетов. Обещание в рекламе и обещание в процессе разошлись, и продажи узнают об этом от клиентов.

Как процесс превратили в имитационную модель

Модель воспроизводит процесс открытия расчётного счёта: приём документов менеджером, ожидание комплаенс-проверки, сама проверка и техническое открытие в системе. Поток клиентов неравномерен: в первые два часа работы отделения нагрузка удваивается.

Ключевое отличие сценариев — в логистике комплаенса. В baseline проверка идёт пакетом с ожиданием до 4 часов. В сценариях решения проверка запускается потоком (ожидание ~15 мин). Дополнительно смоделировано влияние проверки комплектности на месте: она снижает долю возвратов с 31% до 10%, но увеличивает время приёма.

Какие данные взяли и что честно допустили

Поток
~86 обращений в день, экспоненциальное распределение, пик в 2 раза выше среднего в первые 2 часа работы (09:00–11:00).
Ресурсы
4 менеджера (загрузка 94% в baseline), 7 комплаенс-офицеров (загрузка 88%), система открытия счетов (автомат).
Длительности
приём 15 мин, комплаенс 40 мин, открытие 5 мин. Ожидание пакета в baseline — до 4 часов.
Возвраты
31% пакетов некомплектны в baseline, 10% — при проверке на месте.
Не моделировали
клиентов с иностранным участием (отдельный маршрут), выходные дни (календарь пн-пт).

Отчёт симуляции: что показал расчёт

Живой отчёт симуляции

Отчёт удобнее смотреть на большом экране — откройте его отдельной страницей.

Тот же отчёт, который видит пользователь Storm после симуляции. Открывается по ссылке и листается по вкладкам.

Какие сценарии прогнали и чем они отличались

Сценарии, просчитанные в модели
СценарийЧто меняли
Как есть БазовыйОтчёт Комплаенс пакетом раз в день. Средний срок открытия — 17 часов, 95-й процентиль достигает 68 часов. В срок (9 часов) укладывается лишь 54% заявок.
Комплаенс потоком Отчёт Проверка запускается по мере поступления. Средний срок падает до 3,7 часов, доля выполнения SLA растёт до 94%. 95-й процентиль — 17 часов.
Проверка комплектности при клиенте Отчёт Ошибки ловятся до ухода клиента. Возвраты снижаются, но из-за пакетного комплаенса средний срок остаётся высоким — 13 часов. SLA выполняется в 67% случаев.
Оба изменения РешениеОтчёт Поточный комплаенс и ранняя проверка. Средний срок — 2,1 часа, 95-й процентиль — 3,1 часа. SLA выполняется в 100% случаев.

Было и стало

Сравнение «было / стало» по каждой метрике. У метрик разные единицы, поэтому каждая пара показана в своём масштабе.
  • Было
  • Стало
  1. Счетов открыто в срок (SLA 9 ч) , %

    54
    100+45,8 п.п.
  2. Средний срок открытия , ч

    17
    2,1−88%
  3. Срок открытия, 95-й процентиль , ч

    68,2
    3,1−95%
  4. Ожидание в очередях , ч

    11,9
    0,8−93%
  5. Загрузка комплаенса , %

    88
    90+1,5 п.п.
Ключевые метрики процесса до и после изменения
МетрикаБылоСталоИзменение
Счетов открыто в срок (SLA 9 ч) , %54100+45,8 п.п.
Средний срок открытия , ч172,1−88%
Срок открытия, 95-й процентиль , ч68,23,1−95%
Ожидание в очередях , ч11,90,8−93%
Загрузка комплаенса , %8890+1,5 п.п.

Что показал расчёт

  1. Пакетный комплаенс убивает SLA

    В baseline 95-й процентиль срока составляет 68 часов (почти 3 рабочих дня). Перевод комплаенса в поток сокращает этот показатель до 17 часов, а в комбинации с проверкой на месте — до 3,1 часа.

  2. Проверка на месте снимает нагрузку на менеджеров

    В baseline менеджеры загружены на 94% (критический узкий горлышко). При проверке комплектности на месте их загрузка падает до 71%, так как 21% заявок отсеивается или исправляется сразу, не проходя через цикл возвратов.

  3. Комплаенс-офицеры не перегружены

    Загрузка комплаенса растёт незначительно: с 88% в baseline до 90% в лучшем сценарии. Это означает, что текущей мощности (7 человек) достаточно для обработки потока без найма, если убрать искусственные задержки ожидания пакета.

  4. Среднее время в системе падает в 8 раз

    Средний срок открытия счёта снижается с 17 часов до 2,1 часа. Клиенты проводят в очереди в 15 раз меньше времени: с 11,9 часов до 0,8 часа.

Что оказалось не так, как считали

Главная проблема не в нехватке комплаенс-офицеров (их загрузка всего 88%), а в расписании. Пакетная проверка создаёт искусственную очередь, которая растягивает 95-й процентиль срока до 68 часов. Перевод в поток почти не меняет загрузку офицеров, но сокращает срок в 22 раза.

Какую долю расчётных счетов можно открывать в день обращения?

Что решили сделать и что получилось

Внедрили поточный режим комплаенс-проверки и проверку комплектности документов при клиенте. Это решение (сценарий «Оба изменения») обеспечивает выполнение SLA в 100% случаев без увеличения штата.

Доля счетов, открытых в срок (9 часов), выросла с 54% до 100%. Средний срок открытия сократился с 17 до 2,1 часа. 95-й процентиль времени ожидания упал с 68,2 до 3,1 часа. Загрузка комплаенса осталась комфортной — 90%.

Приёмы оптимизации, которые здесь сработали

Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет

SLA ломается не только мощностью, но и расписанием: операция, которая выполняется пакетом раз в сутки, задаёт потолок для всего процесса. В статической схеме такой этап выглядит как обычный прямоугольник — его цену показывает только прогон по времени суток.

Пакетная проверка держала обещание для 34% клиентов; поточная подняла долю до 88% тем же составом.

Где этот вывод не работает

Клиенты с иностранным участием идут отдельным маршрутом с обязательными дополнительными проверками — на них обещание «в день обращения» не распространяется.

Частые вопросы по этому расчёту

Почему нельзя было просто добавить людей в комплаенс?

Загрузка комплаенса в baseline составляет 88%, то есть ресурсы свободны. Проблема в логистике: пакетная проверка раз в день создаёт задержку до 4 часов. Добавление людей не ускорит запуск пакета, а перевод в поток решает проблему при той же загрузке (90%).

Что мешало перевести комплаенс в поток раньше?

Пакетный режим удобен для планирования блоков работы. Однако цена этого удобства — 68 часов ожидания для 5% сложных случаев и срыв SLA в 46% случаев. Поточный режим снижает среднее время в системе с 17 до 2,1 часа.

100% в срок, а не 100% в день. Кто остаётся за бортом?

SLA установлен в 9 часов. В лучшем сценарии 95-й процентиль составляет 3,1 часа, что гарантирует открытие в тот же день для подавляющего большинства. Оставшиеся 0,1% — это экстремальные случаи или обращения в конце рабочего дня, не укладывающиеся в 9 часов.

Проверка комплектности при клиенте удлиняет визит. Не соберётся ли очередь в отделении?

Загрузка менеджеров падает с 94% до 71% благодаря снижению возвратов (с 31% до 10%). Среднее время ожидания в очереди у менеджера сокращается с 42 минут до 16 минут. Пик нагрузки в начале дня учтён в модели.

Ваш процесс, ваши числа

Покажем на вашем процессе

Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.

  1. Присылаете диаграмму и три-четыре цифры про поток
  2. Собираем модель и прогоняем сценарии, которые вы назовёте
  3. Разбираем отчёт вместе и обсуждаем, что из него следует
Показать на моём процессеПосмотреть другие кейсы

Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.

Поддержка