Если банк внедряет разные сервисы для решения локальных задач, то постепенно его IT-ландшафт превращается в зоопарк. Как банкам избежать такого опыта рассказал Александр Шумаков, эксперт продаж Abanking Digital Office.
Как сервисы превращают IT-ландшафт банка в IT-зоопарк
Бизнесу нужны результаты за определённое количество времени и средств, и на рынке существуют решения, которые невозможно развивать, но они подходят под ТЗ банка. Когда мы проводим предпроектные исследования, часто видим, что банки используют разные системы для решения локальных задач. Например, когда сервис регистрации бизнеса разработал один вендор, РКО второй, а факторинг банк будет собирать сам. Этот подход помогает решить локальные задачи, но со временем такая лоскутная автоматизация превращает работу с сервисами в хаос.
Управлять обычным зоопарком проще и дешевле, чем айтишным
В живом зоопарке не бывает проблем с инфраструктурой: вольеры для новых зверей или есть, или их согласовывают, строят и уже потом завозят животных. И вряд ли когда-нибудь в зоопарке будет задача подружить антилоп с гепардами, потому что остался только один вольер. В IT-зоопарке такая задача есть.
Чтобы внедрить новую систему, банку приходится искать место в IT-инфраструктуре и обучать команду работать с каждым новым «зверем».
Разрозненные системы приводят к низкой доступности данных и сложностям с управленческим контролем. Ещё работать в таком зоопарке дорого: нужно обучать и содержать команду сопровождения, и покупать лицензии на дублирующий функционал.
Чтобы не стать директором IT-зоопарка, выбирайте масштабируемое решение
Когда банк планирует запустить сервис, мы рекомендуем посмотреть, какие задачи он может закрыть, и какие ещё продукты разрабатывает вендор.
Например, в Abanking Digital Office мы создаём масштабируемые сервисы для физических и юридических лиц, и сотрудников банка. Решение «в одном окне» позволяет одной команде банка сопровождать несколько проектов для клиентов и сотрудников.
Благодаря nocode-платформе, банки могут как использовать готовые сервисы, так и создавать собственные с нуля. И каждый сервис может масштабироваться не только с точки зрения функционала, но и с точки зрения логики взаимодействия с другими сервисами.
Первый вариант масштабирования — сквозные процессы
С помощью сквозных процессов клиент может перемещаться по структурным подразделениям банка в рамках единого пользовательского пути. Например, когда клиент пройдёт регистрацию в сценарии открытии расчётного счёта, он сможет открывать новые продукты без повторного ввода данных.
Персонализированные сценарии и предложения
Ещё одна ветка развития — усложнение логики внутри сервиса и создание персонализированных сценариев.
Например, когда в кредитном калькуляторе клиент увеличивает сумму кредита, он будет получать разные предложения и способы их оформления: кредит с поручителями, под залог транспорта или недвижимости.
То есть в зависимости от суммы появляются сценарии с расширенным списком документов и происходит усложнение логики проверок.
По мере получения информации банком клиент будет получать персонализированные предложения. При регистрации бизнеса банк может узнать по ОКВЭД, что клиент планирует вести торговлю в интернете, и предложить ему специальное предложение РКО, и помощь по выходу на маркетплейсы.
Переход между сервисами по единому логину и паролю
Обычно чем больше продуктов внедряет банк, тем чаще его клиентам приходится вводить пароли при переходе между сервисами. Поэтому мы разработали возможность перехода между сервисами по единому логину и паролю, которые клиент указывает в личном кабинете.
Этот функционал можно интегрировать как с нашими продуктами, так и с действующими решениями банка. При этом интегрировать функционал мы можем вплоть до интерфейсной подстройки.
Дистанционное подписание документов с любыми типами подписи
Благодаря решению Nopaper.ru в системах Abanking Digital Office, во все наши сервисы возможно встроить дистанционное подписание документов с помощью электронной подписи любого типа.
Например, при оформлении кредита нужно, чтобы участники дали согласия на проверку в бюро кредитных историй. Наше решение определяет количество участников, создаёт для них личные документы и позволяет оформить, и подписать документы дистанционно.
Что делать, если инструментов нужно больше
Первый вариант: с помощью nocode-конструктора можно дорабатывать и развивать уже запущенные сервисы без участия вендора силами собственной команды. Например, совместно с клиентом мы разработали и внедрили сервис онлайн-ипотеки. Затем клиент уже самостоятельно запустил сервисы по оформлению вкладов и кредитных карт.
Второй: если встроенных инструментов nocode-конструктора недостаточно, и для работы сервиса требуется специфический функционал, его можно добавить в сервис в виде фронтального виджета. Виджет будет взаимодействовать со сторонним бэкендом, и его может написать команда банка или любой вендор.
И третий: также мы регулярно дорабатываем платформу и при этом прислушиваемся к пожеланиям наших клиентов. Если запрос ложится в контур разработки, то он появится в одном из обновлений.
Чек-лист как банку найти масштабируемую экосистему
Чтобы запустить новый сервис для онлайн-продаж, который будет развиваться и приносить прибыль, проверьте решения вендора по чек-листу:
- В одном сервисе можно разработать несколько продуктов.
- Сервис может масштабироваться без кастомных доработок.
- Управлять и вносить изменения в сервис может банк, а не только вендор.
- Язык, на котором написан сервис, должен быть понятен для команды банка, чтобы банк мог влиять на скорость разработки и интеграций.
Или просто используйте nocode-технологии Abanking Digital Office вместо программирования и лоскутной автоматизации. Создавайте и масштабируйте типовые банковские сервисы с помощью набора готовых компонентов без привлечения программистов.
Оставьте заявку на демо по ссылке 👉🏻