Попытка сохранить привычный сторонний софт в корпоративном контуре оборачивается для финансовых организаций неконтролируемым ростом ИТ-бюджета. За переход на новую версию платформы вендор затребовал крупную сумму, а за миграцию со старой версии попросил заплатить второй раз за тот же объем данных, поскольку инструмент переноса не входил в базовый контракт. На кону оказалась финансовая устойчивость ИТ-бюджета при попытке коммерческого поставщика переложить регуляторные издержки на клиента. В такой ситуации переход на внутреннюю разработку становится единственным способом вернуть контроль над юнит-экономикой клиентской поддержки.
Фактическим толчком к пересмотру стратегии послужили регуляторные требования: весной 2022 года вышел Указ Президента № 166 о технологической независимости критической информационной инфраструктуры. Ранее банк использовал для обслуживания физических лиц решение отечественного поставщика, собранное на базе зарубежных компонентов. Внутри этой системы работал NLU-движок, закрывавший около 60% обращений клиентов без участия операторов контакт-центра. Однако выпуск импортозамещенного релиза платформы поставщик сопроводил выставлением счетов не только за лицензии, но и за сам процесс миграции и повторную интеграцию изменившихся протоколов.
Инженерный стек и экономика отказа от лицензий
Собственная разработка потребовала создания стека с нуля, но позволила избежать постоянных лицензионных платежей сторонним компаниям. Бэкенд новой чат-платформы инженеры построили на Python 3 и FastAPI, а пользовательский интерфейс — на TypeScript и React, настроив обмен данными между клиентом и сервером через протокол SSE (Server-Sent Events). Базой данных стал Postgres Pro, в то время как межсервисный транспорт организовали через HTTP и Kafka в зависимости от типа нагрузки.
Внутренняя PaaS-платформа App.Farm взяла на себя инфраструктурные вопросы, избавив продуктовую команду от необходимости администрировать кластеры.
Инфраструктурную базу предоставила внутренняя PaaS-платформа банка App.Farm. Благодаря этому команда развития чатов для физических лиц смогла сфокусироваться на продуктовой логике минимальным составом: 3 бэкендера, 2 фронтендера, 2 тестировщика, аналитик и продакт. Ранее банк уже спроектировал и обкатал собственную платформу на корпоративных клиентах, поэтому стоимость интеграции решения для розничного сегмента оказалась почти нулевой.
Перенос сценариев и риски собственной разработки
Главным препятствием при отказе от вендора стала потеря накопленных за годы алгоритмов понимания речи: сторонний NLU-движок был отточен, тогда как собственный бот стартовал с чистого листа. За счет чего удалось перенести накопленную базу знаний без покупки инструментов у поставщика?
Перенос диалоговых сценариев со старой системы потребовал ручного разбора данных. Собственная команда разработки потребовала постоянных затрат на содержание штата специалистов взамен простой покупки готовых лицензий, однако такой шаг полностью устранил зависимость от ценовой политики внешнего поставщика и чужих очередей доработки.
Глубокая интеграция внутри единого контура позволяет боту самостоятельно блокировать банковские карты и менять ПИН-коды клиентов без пересылки типовых инструкций.
Прямой доступ к банковскому ядру снял ограничения коробочного софта, где за каждую интеграционную доработку приходилось платить дважды — поставщику и внутренним разработчикам. Как отметил управляющий директор Центра развития финансовых технологий в Россельхозбанке Олег, собственная команда развития обходится дороже регулярной платы за лицензию, однако она ликвидирует зависимость от сторонних очередей доработки и чужих технологических контрактов.
Коммерческий поставщик рассчитывал продать банку собственный инструмент переноса данных поверх нового лицензионного соглашения, но финансовая организация сделала выбор в пользу контроля над инфраструктурой.
Что это значит
Уход от риска неконтролируемых лицензионных платежей вынуждает финансовые организации обменивать готовую внешнюю функциональность на постоянные затраты на собственный штат. Опыт Россельхозбанка на Хабре показывает, как выставление счетов вендором за миграцию данных подталкивает бизнес строить стек на Python 3 и FastAPI силами компактной команды из девяти человек. Сможет ли внутренняя команда из трех бэкендеров и аналитика вернуть прежний уровень автоматизации в 60% клиентских обращений без готового стороннего движка?