Саме так було у Райфі із розвитком сервісу ОВДП у застосунку MyRaif. Команді потрібно було не просто винести інвестиційний продукт у цифровий канал, а змінити саму модель його проходження всередині банку: прибрати ручні вузькі місця, синхронізувати понад десять систем, автоматизувати документообіг і закласти основу для подальшого масштабування.
Читайте также: Кінець «мертвим зонам» в «Інтерсіті» та Гігабіт у кожне село: уряд показав телеком-план до 2030 року
Для технічної аудиторії цей кейс цікавий не лише самим продуктом, а інженерною задачею, як перевести складний банківський сценарій із частково ручної моделі у цифровий self-service без втрати керованості, процесного контролю та можливості розвитку в майбутньому.
Не просто «оцифрувати» продукт, а перебудувати процес
До появи повноцінного цифрового сценарію продаж ОВДП у банку вже існував. Але сам процес був складним і фрагментованим: клієнт звертався до менеджера, далі угода проходила через кілька підрозділів, а дані переносилися між системами частково вручну. Для поодиноких операцій така модель ще може працювати. Для масштабування — уже ні.
У якийсь момент стає зрозуміло: проблема не в тому, що клієнт не бачить кнопки в мобільному застосунку. Проблема в тому, що за цією кнопкою немає достатньо гнучкої внутрішньої системи, яка дозволяє сервісу зростати без пропорційного збільшення ручної участі.
Саме це й визначило підхід команди. Робота йшла не лише над клієнтським сценарієм у MyRaif, а одразу в двох площинах: зовнішній — де користувач отримує простий цифровий досвід, і внутрішній — де банк вибудовує процесову та технічну основу, щоб цей досвід був стабільним, керованим і масштабованим.
Понад 10 систем в одному сценарії
Купівля ОВДП у банку — це не одна транзакція в ізоляції. Це перевірки, дані, документи, статуси, маршрутизація, передача інформації між кількома внутрішніми та суміжними системами. Щоб зробити цей сценарій цифровим, команді довелося перебудувати велику кількість взаємодій між системами, а частину інтеграцій — створити фактично з нуля.
У рішенні задіяно понад десять систем. Щоб цей ланцюг працював стабільно, команда зробила ставку на мікросервісну архітектуру, BPM для оркестрації бізнес-процесів і event-driven підхід для побудови інтеграційних потоків між системами.
У такій моделі BPM став не просто інструментом для «схеми процесу», а механізмом керування переходами між етапами, обробкою статусів, контролем виконання і зниженням залежності від ручного втручання. Event-driven підхід, своєю чергою, дозволив зробити інтеграційні потоки менш жорстко зчепленими й підготувати систему до подальшого розвитку без повного перепроєктування кожного нового сценарію.
«Ми закладали архітектуру так, щоб вона працювала не лише для поточного запуску, а й для наступних етапів розвитку. Це дає можливість швидше автоматизувати внутрішні процеси, зменшувати ручну роботу і надалі розширювати сервіс на нові сценарії», — каже Руслана.
Фактично мова йшла не про одну функцію в мобільному застосунку, а про формування архітектурного каркаса, на якому можна будувати розвиток інвестиційного напряму далі.
Найскладніше «під капотом»
На перший погляд може здаватися, що основна складність такого сервісу в інтерфейсі: перелік облігацій, вибір інструменту, сума, документи, підписання. Але в банківських продуктах найскладніше часто починається саме за межами екрана користувача.
Потрібно забезпечити узгодженість даних між системами, не втратити статус на жодному з етапів, правильно сформувати документи, провести оплату, передати результат у наступний контур і при цьому не побудувати черговий «тимчасовий обхід», який не витримає наступної хвилі розвитку.
У таких сценаріях архітектура безпосередньо впливає на бізнесову швидкість. Якщо кожен новий крок вимагає ручної участі або кастомної інтеграції «в обхід», сервіс швидко впирається в межу росту. Якщо ж одразу закладати процесову й інтеграційну гнучкість, наступні релізи стають дешевшими, передбачуванішими й технічно здоровішими.
Саме тому команда в Raiffeisen розглядала запуск ОВДП у MyRaif не як фінальну точку, а як перший робочий шар більшої системи.
Читайте также: Український TechNovator, який працює над бездротовою зарядкою для дронів, виграв грант на $10 000
Від портфеля до повноцінного цифрового сценарію
Сервіс не з’явився одномоментно у фінальному вигляді. Команда рухалася поетапно.
Спочатку в MyRaif клієнти отримали можливість бачити свій портфель ОВДП. Далі замовляти й отримувати документи щодо володіння та операцій за рахунком у цінних паперах. Наступним кроком стала «вітрина» облігацій, де можна було обрати конкретний ISIN і кількість.
Після цього команда перейшла до повноцінного цифрового сценарію: вибір ОВДП, розрахунок суми, формування документів, підписання й оплата без розриву в клієнтському шляху.
Такий підхід дозволив не намагатися «закрити все одразу», а послідовно виносити в диджитал окремі частини складного банківського процесу, паралельно добудовуючи внутрішню архітектуру.
Невелика команда, але великий інженерний обсяг
Над розвитком сервісу працювала сфокусована команда: backend-розробники, mobile-фахівці, QA, бізнес-аналітик, архітектор, delivery-функція та суміжні ролі. Для великого міжнародного банку це не надто великий склад. Але саме така компактність дала змогу тримати фокус на одному наскрізному сценарії й швидше синхронізувати рішення між різними напрямами.
У цьому кейсі важливий не лише розмір команди, а й характер самої задачі. Це була не історія про окремий frontend-реліз або локальне доопрацювання. Команда працювала на стику кількох вимірів одночасно: клієнтський досвід, документообіг, інтеграції, внутрішні процеси, масштабованість і технічна готовність до наступних змін.
Для технічної аудиторії це знайомий тип задачі коли головна цінність народжується не від окремого сервісу чи екрана, а від того, наскільки стійкою є вся система і чи здатна вона пережити наступні ітерації без нарощування архітектурного боргу.
Як зрозуміли, що технічна гіпотеза спрацювала
Після запуску автоматизованого сценарію через MyRaif команда побачила головне: сервіс почав активно використовуватися клієнтами, а новий підхід працювати не лише на рівні клієнтського досвіду, а й на рівні внутрішньої операційної моделі.
Для команди це стало важливим підтвердженням, що ставка на автоматизацію, інтеграції й нову архітектурну основу була правильною. Коли складний процес стає коротшим і зрозумілішим для клієнта, а всередині банку менш ручним і краще керованим, сервіс отримує реальний потенціал до масштабування.
У цьому кейсі результат важливий не як PR-аргумент, а як індикатор того, що нова модель працює, клієнтський шлях став простішим, а внутрішня система готовою до масштабування без пропорційного збільшення ручного навантаження.
Що далі
Наступні етапи розвитку команда бачить у подальшій автоматизації внутрішніх процесів, зниженні мінімального порогу входу, розширенні сервісу на нові сценарії та подальшому використанні побудованої архітектури для розвитку інвестиційного напряму.
«Ми будуємо рішення з розрахунком на майбутнє. Коли внутрішні процеси будуть автоматизовані повністю, це дасть клієнту більше свободи, банку 0 масштабованість, а продукту — нову швидкість розвитку», — говорить Руслана.
І саме тут цей кейс виходить за межі теми ОВДП. По суті, команда в Райфі вирішувала універсальну для великих фінансових систем задачу: як перетворити складний, фрагментований і частково ручний процес на цифровий сервіс, який можна не лише запустити, а й розвивати далі без того технічного боргу, який згодом починає гальмувати будь-які зміни.
Для клієнта це — кілька простих кроків у мобільному застосунку. Для інженерної команди — побудова системи, яка робить ці кілька кроків можливими.
Читайте также: Мохаммад Захур Первая Жена Фото: Биография, Личная Жизнь и Карьера