Меньше мнений — больше цифр: как управлять без иллюзий и чем может помочь BPMS

Об этом на Fintech Data Day рассказал независимый эксперт Николай Петелин.

Когда анализ «сверху» не работает

Ценность для клиента создают продуктовые команды. Службы, которые «сверху» анализируют их процессы, пишут отчеты и раздают рекомендации, командами с собственными метриками, клиентами и KPI воспринимаются как назойливые комары: требуют изменений, но не отвечают за результат.

Более зрелый подход — когда поиск узких мест и оптимизация происходят внутри продуктовой команды. Это и дает BPMS: команда опирается на аналитику высоконагруженного процесса и меняет его на основе данных о поведении реальных клиентов, а не мнений руководителей, завязанных на свои KPI.

При этом BPMS — не разовое внедрение. Если после первых улучшений перестать регулярно мониторить метрики, эффект быстро сходит на нет. В период хайпа цифровизации так бывало часто: вендоры показывали рост, уходили, а без устойчивого управления внутри компании показатели проседали на 10–15%, а иногда и до 30% от достигнутого.

Что меняется, когда процесс видно в цифрах

Пример из личного опыта: мы разбирали высоконагруженный процесс открытия расчетных счетов с большим потоком заявок. В нем участвовали минимум пять ключевых систем (фронт, CRM, процессинг и др.) и 3–4 подразделения с разными интересами. Продажи давили на скорость ради бонусов, а операционный блок, распределенный по разным хабам, из‑за разницы часовых поясов мог задерживать процесс до 4 часов.

В такой среде нельзя управлять «по ощущениям» — нужны данные: где узкое место, сколько длится каждый шаг и кто влияет на итоговую метрику. Без цифр побеждает тот, кто громче продавливает решения.

Первые полгода мы так и жили: делали изменения по указке крупнейшего подразделения, но счет по-прежнему открывался за сутки. Позже стало понятно, почему «срочные улучшения» не дают эффекта: часть задач продавливали из личной выгоды (например, отчет под 20% бонуса). Тогда я поддержал внедрение process mining — и началось осознанное управление.

Мы выгрузили логи, взяли данные за полгода, собрали end-to-end прохождение заявки по всем пяти системам и загрузили в инструмент. Вскрылась главная боль — возвраты заявок. В МСБ и выигрывает тот, кто быстрее.

Мы поставили цель на первый год: полностью рабочий расчетный счет должен открываться за 30 минут во всех системах. Данные показали: один возврат растягивает срок до 36 часов, два возврата — до 72. Клиент за это время уходит и не возвращается.

Выбрали два ключевых инструмента:

1) process mining — дал масштаб и ключевые инсайты. Мы разобрали все возвраты, декомпозировали причины, выбрали топ‑5 и прицельно начали устранять. Например, на исторических данных обнаружили не «понятный маршрут заявки», а около 8000 вариаций прохождения — паутину из возвратов;

2) Power BI. От цикла «квартал закончился → месяц делают PowerPoint → месяц согласовывают → показывают уже неактуальную картину» (с предположениями «виноваты вот эти факторы» вместо конкретных цифр) перешли к режиму «почти онлайн»: за ночь системы собирали и консолидировали данные, выгружали в хранилище, а скриптами строились дашборды.

Каждое утро на стендапе и дейли команда начинала с цифр: как изменился процесс, особенно после релизов. За трехнедельный спринт мы брали в бэклог те изменения, которые сильнее всего влияли на метрики, и через 3–4 дня после релиза уже видели эффект в дашборде. Это снимало вопросы разработчиков «как я влияю на NPS/ROI/выручку»: каждый потерянный клиент — прямой минус к деньгам, а в МСБ стоимость привлечения доходила до 50 тысяч рублей.

Power BI (и аналоги) позволял без ручных выгрузок держать 3–4 ключевых показателя и быстро перестраивать борды под разные срезы.

Продолжение в следующем посте