Дмитрий Опарин, ELMA:
Банкам важнее не автоматизация, а операционная эффективность

Дмитрий Опарин: Не сказал бы, что уровень процессной зрелости по отрасли достаточно высок. Да, у банков есть описанные регламенты, но зачастую они просто не актуальны, потому что нет единого стандарта. Точнее он есть на бумаге, но отсутствует в жизни.

Вообще, это такое идеализированное представление о банках, будто бы внутри у них образцовый порядок и все работают единообразно и строго по инструкции. Это верно только для определенных видов деятельности, регламентированных документами вроде Basel (стандарт достаточности капитала). В меньшей степени это касается процессов взаимодействия с клиентами.

Показателен пример одного из наших заказчиков, для которого ELMA внедряла пилотный проект. Банк входит в перечень системно значимых банков России ЦБ РФ. Вроде бы уровень зрелости банка должен быть высоким. Тем не менее, когда мы стали собирать информацию с заказчика, выяснилось, что внутри банка существуют разные представления о том, как выглядят основные процессы. Каждый вице-президент управлял, по сути, по-своему, менеджеры по работе с юрлицами работали «как рассказали, как обучили». Так что наша задача на проекте заключалось в том, чтобы сделать процессы универсальными.

Дмитрий Опарин: Есть объективные показатели, которые связаны с Customer Experience и конкуренцией в отрасли. Банки смотрят, насколько стоимость и скорость их процессов и услуг соотносятся с рынком.

Например, сейчас можно говорить о банковском тренде на цифровизацию продуктов для малого и среднего бизнеса. Сбербанк, Тинькофф Банк и другие банки развивают цифровое обслуживание этого сектора. Один из наших заказчиков VestaBank в исследовании эффективности интернет-банков для малого бизнеса, которое проводило агентство Markswebb (Business Internet Banking Rank 2018) достиг результатов, превосходящих крупнейшие российские банки. В частности, клиенты VestaBank платят порядка 690 тыс. рублей за тот же набор услуг для МСБ, за который клиенты других банков отдают больше миллиона. Эта разница в стоимости — во многом следствие выстроенных бизнес-процессов.

Дмитрий Опарин: Для физлиц важна скорость процессов. Если человек пришел в банк, он ожидает, что заявку рассмотрят быстро. Что перезвонят завтра и скажут: вот ваша кредитная карта. Сотруднику банка достаточно просто посмотреть кредитную историю — отправить заявку в скоринг. В принципе всё, в соответствии с настроенной политикой риск-менеджмента, если клиент подходит, ему выдадут кредит тут же.

В B2B из-за большого числа проверок заявки в принципе не рассматриваются быстро. Но важную роль играет время на перевод клиента из предквалификации в фазу скоринга. Здесь Customer Experience напрямую связан с бизнес-процессами. Возникают потери внутри процесса, которые увеличивают срок рассмотрения заявки. Это могут быть повторные согласования и банальные потери документов в процессе. Заказчик может просто предоставить не то, что нужно, и потребуется повторная отправка. Всё это говорит о неоптимальности процессов.

Дмитрий Опарин: Даже если банк — топ с точки зрения продаж продукта, никто не отменял операционную эффективность. Она, в частности, интересует и акционеров. Да, можно много продавать и занимать определенную долю на рынке. Но вопрос в том, насколько эффективны бизнес-процессы. Это вопрос ставился и в проекте цифровой трансформации Kapital Bank (крупнейший банк Азербайджана по числу клиентов, прим. ред.).

Дмитрий Опарин: Kapital Bank сначала приглашал консультантов из McKinsey. Дальше банк искал платформу для цифровой трансформации — удобный инструмент с точки зрения интерфейсов, в котором можно выстраивать сквозные бизнес-процессы. Такой, чтобы сотруднику не нужно было обращаться в десятки разных систем.

В плане аналитики платформа для цифровой трансформации должна собирать данные. Например, просто транзакционная система не посчитает, сколько выполнялись та или иная операция. Способ тех же McKinsey — прийти к человеку с таймером и провести хронометраж процесса.Этот способ обладает определенными минусами — когда перед сотрудниками стоит кто-то с таймером, они начинают выполнять работу быстрее, объективной картины не получится. Особенно если это большая компания, у которой 80 филиалов в разных локациях.Метавселенная ВДНХ 2.8 т

Главное требование Kapital Bank к платформе для цифровой трансформации состояло том, чтобы сквозные процессы автоматизировались не «в монолите». Бизнес меняется быстро. Поэтому банкам нужен гибкий инструмент, который поможет вносить быстрые и низкие по стоимости изменения.

Похожая история еще с одним нашим клиентом. Банк перевозит весь свой бэк в регионы. Это требует изменения процессов. Не таких, что мы сейчас напишем ТЗ, поставим разработчикам задачу и они нам где-то через n-месяцев доработают софт. А легких и быстрых.

Или пример VestaBank. Бизнес-аналитик банка описал процесс, и за три недели процесс запустили в промышленную эксплуатацию. Понятно, что есть точки интеграции, которые сделает только разработчик. Но для изменений на уровне бизнес-логики весь путь от описания до введения в эксплуатацию занял всего три недели. И такие изменения внутри процессов происходят постоянно.

Дмитрий Опарин: В целом сейчас банки не ищут простых средств автоматизации — так или иначе всё уже автоматизировано. Много где корпоративные системы стоят уже 10—15 лет. Они выполняют свою функцию. Нет задачи их заместить, но есть задача объединить разные ИТ-решения.

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

Дмитрий Опарин: В транзакционных системах сложно выстроить коллаборацию между различными департаментами, потому что это, по сути, лишь учетные системы. В них не получится отследить операционную эффективность. Как это сейчас происходит. Сначала собираются данные. Тут банки используют сложные методики BI (Business Intelligence). Либо выстраивают процесс в BPM-системе — когда есть четкая последовательность задач, понятно, кто чем занимается. Данные собираются автоматически по мере того, как выполняются задачи по процессу.

Дальше проводится анализ, находятся «узкие места». Данные для анализа можно выгрузить из BPM-системы в платформу для Process Mining или в тот же BI и понять, какие филиалы, департаменты и люди эффективны. Дальше владелец процесса принимает какие-то решения. Допустим, он говорит: у меня есть гипотеза, что если мы запараллелим вот эти операции и введем еще одно бизнес-правило для заявок, то процесс будет идти быстрее. Важный момент, что гипотеза может остаться просто гипотезой, если она не подтвердится на А/B-тестировании.

Для быстрой проверки гипотез нужен инструмент, в который можно быстро вносить изменения. Если эти изменения вносятся в течение полугода — тогда возможности для маневра нет. Если изменения вносятся быстро, в течение трех недель, как в VestaBank, то можно экспериментировать и находить оптимальные решения.

Дмитрий Опарин: Сейчас главный тренд — RPA (Robotic Process Automation). Например, роботы сейчас способны закрыть целый пласт задач по интеграции с legacy-системой без API. Вместо того, чтобы долго и дорого автоматизировать передачу данных между системами, можно использовать RPA. Несколько таких решений уже были внедрены нами на клиентских проектах — пока что не для финансовых организаций. Но мы и, что важно, заказчики видим большие перспективы использования RPA в банковских процессах.

Как выглядит роботизации в связке с BPMS. BPM-система выстраивает сквозные процессы и при этом использует RPA, чтобы закрывать определенные участки этих процессов. Бизнес-аналитику, которой моделирует процесс, вообще все равно, кто выполняет задачу — пользователи или роботы. Он лишь задает, какую информацию нужно передать и что получить на выходе. Без какой-то сложной настройки и написания кода. Аналитик просто заходит в BPM-систему, перетаскивает кубики с задачами и получает исполняемое приложение. Для него RPA — это такой же кубик. Аналитик выбирает кубик и указывает, что в бизнес-процессе нужно сделать интеграцию, например, с «Почтой России». Разумеется, до этого в RPA-решении нужно настроить сценарии взаимодействия с этим сайтом.