— Николай, в последние несколько лет количество вендоров, которые заявляют nocode-технологии в своих продуктах, значительно выросло. Чем отличаются эти системы?

— Nocode-платформы появляются в разных категориях задач. Они позволяют проектировать бизнес-процессы, интерфейсы, структуру данных, интеграции. Но, как правило, nocode-функциональность в этих системах покрывает конкретную продуктовую механику. Например, есть nocode-платформы, которые позволяют конструировать BPMN-процессы. Часть продуктов фокусируется на nocode-инструментах для создания интерфейсов, другая часть — на функционале для интеграции и т.п.

На банковском рынке, если вендоры и используют nocode-механики, то, как правило, для настройки некоторых составляющих своих продуктов. И чаще всего это фрагменты nocode-инструментария, встроенные в историческую архитектуру продуктов. Такая архитектура не позволяет создавать новые сервисы с нуля — лишь менять определенные продуктовые настройки.

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

— Для каких банковских систем применим nocode? Есть ли какие-то ограничения?

— Это зависит от функционала nocode-решения. Изначально эта архитектура (даже lowcode, а еще не nocode) получила развитие в конструировании внутренних бизнес-процессов, что подтверждают давно существующие BPMN-платформы. Но сейчас рынок nocode-решений предлагает достаточно широкий спектр решаемых задач.

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

На нашей nocode-платформе мы стараемся закрыть максимум задач, чтобы дать заказчику независимость в развитии их сервисов и создании новых продуктов силами своей аналитической команды.

— Как появление новых технологий влияет на взаимоотношения банка и вендора?

— Ключевая дилемма в отношениях между заказчиком и проприетарной технологией — это вендорлок. Все банки боятся попасть в зависимость от вендора, его ценовой, ресурсной политики и динамики продуктового развития. Поэтому у банков всегда был запрос на инструментарий, который позволял бы сопровождать приобретенную систему с минимальной зависимостью от подрядчика.

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

Таким образом, идеальный nocode-вендор дает такой контур продукта, который позволил бы банку реализовать любую задумку на этой платформе, не прибегая к услугам продуктовой команды вендора в части настройки либо доработки ядра системы. Если банки получают функциональность, которая позволяет им реализовывать свою собственную бизнес-экспертизу, то их требования к вендору будут трансформироваться в сторону запроса на гибкость технологий, а не на его бизнес-экспертизы или готовые бизнес-решения.

— Зачем банку забирать конструирование сервисов на свою сторону, если ему все равно придется нанимать людей, обучать и развивать их, а вендору по-прежнему нужно платить?

— Логика финансовых отношений с вендором разделяется на лицензионную, внедренческую и саппортную. Лицензионная составляющая никуда не исчезнет, потому что это оплата за пользование технологией. А внедрение и поддержка сопровождения могут перейти на сторону внутренней компетенции — и это существенно сократит time to market. Скорость изменений, которые будут проводиться во внутреннем контуре, будет всегда выше, нежели во взаимодействии заказчика с подрядчиком.

Николай Адеев, основатель Artsofte и «борт № 1» Abanking

Внедрение можно сделать и силами вендора, но оно никогда не бывает статичным. Мы живем в эпоху гиперавтоматизации, что подразумевает регулярное изменение требований и проверку гипотез, а также циклы итеративных улучшений. Nocode-технологии дают банку развилку. Можно внедрить продукт силами вендора либо самостоятельно, получив специализацию по работе с продуктом. Или выбрать гибридный вариант: например, вендор может собрать MVP, провести обучение, а дальше банк может сам развивать и видоизменять внедренные сервисы.

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

— Могут ли nocode-технологии для банковского ПО заменить традиционный подход к разработке?

— Как и в случае с любыми проприетарными технологиями, рынок всегда находится в конфликте между внутренними компетенциями разработки и внешними. Поэтому важно, чтобы применение nocode-платформ не приводило к резкой замене с трудом наработанного кадрового IT-потенциала банка, а позволяло гибридно встраивать в себя имеющиеся разработческие компетенции.

Например, в нашем решении мы реализовали возможность публикации внутри платформы виджетного функционала, который может быть написан на любом кодовом стеке при исполнении заявленного манифеста публикации. Это позволяет делать специ­фические новые разработки частью nocode-инструментария. Nocode-платформа выступает как технологический каркас для конструирования сервисов, в котором могут быть вкрапления кастомных виджетов. Это дает возможность реализовывать специ­фические бизнес-запросы, которые не укладываются в nocode-архитектуру и продуктовый бэклог нас как вендора.

— Как появление ДБО на nocode-архитектуре может изменить банковский рынок?

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

Nocode-решения в ДБО приведут к появлению нового пласта специализированных интеграторов и IT-компаний, которые смогут войти в этот достаточно монополизированный сегмент и применить соответствующую внедренческую экспертизу. Это ускорит развитие рынка, больше игроков смогут участвовать в решении цифровых банковских задач. Например, один из наших текущих технологических партнеров, который был вендором традиционного ДБО, уже самостоятельно сконструировал на нашей nocode-платформе абсолютно новые сервисы для исламского банкинга, которые были сертифицированы муфтиятом вообще без участия разработки.

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