Привет, Хабр! Меня зовут Филипп Сенцов, я преподаю на курсе «Аналитик данных» в Яндекс Практикуме и работаю в «Альфа-Банке». Я техлид по аналитике в команде, отвечающей за инфраструктурную часть BaaS-платформы в банке. До этого я был техническим продактом в «СберТехе», развивал KeyCloak Sber Edition. А ещё раньше занимался интеграциями с системой ЕГАИС в «Магните».

В этой статье я расскажу, что значит понятие BaaS в нашем банке, как сложилась современная индустрия поставки IT-решений в виде сервиса, что её ждёт в будущем и как всё это связано с Open API.

Небольшая ремарка по терминам:

1. Сокращение BaaS я использую в значении Business as a Service (с англ. «Бизнес как сервис»), реже — как Banking as a Service (с англ. «Банкинг как сервис»). При этом в других контекстах его могут расшифровывать иначе.

2. В качестве более тяжеловесного синонима BaaS я иногда употребляю BPaaS (Business Processes as a Service, с англ. «Бизнес-процессы как сервис»). Это понятие в некоторых фрагментах более полно отражает суть.

3. Понятие BaaS (BPaaS) в этой статье спроецировано на IT-индустрию. Однако модель BaaS применима не только в IT.

Что такое BPaaS-модель

BPaaS (Business Processes as a Service) — это модель B2B-взаимодействия, когда отлаженную модель бизнес-процессов (по сути — бизнес) дают в аренду или продают в качестве услуги другой компании. Для IT-индустрии BPaaS представляет собой набор информационных услуг, которые обычно выстроены в виде иерархической модели: BPaaS на базе программного обеспечения (Software as a Service, SaaS), построенного на основе платформы (Platform As a Service, PaaS), инфраструктуры (Infrastructure As a Service, IaaS) или мониторинга (Monitoring As a Service, MaaS).

Такая иерархия сложилась эволюционно — от базовых уровней к верхним. Далее разберу эволюционную структуру BPaaS-ступеней детально.

Как появилась и развивалась BPaaS-модель

Ступень 1. Традиционное IT

В эпоху доткомов 2000-х годов в компаниях были только традиционные информационные технологии. Открывая IT-подразделение, бизнес самостоятельно закупал железо (серверы, жёсткие диски), оплачивал лицензионное программное обеспечение и при необходимости писал свой софт. Всё это запускали и сопровождали сотрудники компании.

Бизнес-логика постоянно усложнялась, новые потребности удовлетворяли с помощью цифровизации процессов. В соответствии с так называемым Законом Мура нужны были всё новые и новые вычислительные мощности, и это дорого обходилось.

Ступень 2. IaaS — Infrastructure as a Service

В ответ на проблемы усложнения IT появилось явление Infrastructure as a Service (IaaS). Суть подхода в том, что внешние компании предоставляют в аренду бизнесу своё «железо» — условные центры хранения и обработки данных, на которых организация могла хранить файлы и запускать приложения на простых виртуальных машинах (VM).

Например, Windows Servers позволяли в режиме Standalone запускать экземпляры LDAP-каталогов. Вместо покупки группы серверов за полмиллиарда рублей можно было арендовать это оборудование за ежемесячную оплату. Остальное по-прежнему делала компания: на арендованном «железе» нужно было самостоятельно разрабатывать, устанавливать и сопровождать ПО.

Ступень 3. PaaS — Platform as a Service

На следующей ступени развития бизнесу стало дорого не только закрывать потребности в вычислительных мощностях, но и разрабатывать растущее количество сложного, качественного софта. Понадобилось больше баз данных, больше лицензий. Появилась модель Platform as a Service (PaaS): вендоры начали продавать железо вместе с готовыми базами данных — лицензионными приложениями. 

Например, на российском рынке комплексные IaaS и PaaS-решения предлагает компания Selectel. Широко распространённое в мире PaaS-решение — платформа Docker.

На этом этапе сопровождать ПО должны были заказчики: поставщики давали только первоначальную конфигурацию. Это повышало расходы и увеличивало штат сотрудников.

Ступень 4. SaaS — Software as a Service

В подходе Software as a Service клиенту предоставляют железо, ПО и его сопровождение. Это просто и удобно: нажимаешь три кнопки — получаешь доступ к целой базе. Клиент только загружает данные и пользуется базой, а вендор сопровождает и обеспечивает её отказоустойчивость.

Сейчас компании широко используют SaaS: то есть «переезжают на облако», тем самым уменьшая издержки. Многие применяют Яндекс Облако и Amazon Web Services. И это работает до тех пор, пока предприятие не ставит новые цели по расширению бизнеса. Например, зайти в смежную область или запустить «с нуля» новый бизнес-процесс.

Можно всё сделать самостоятельно: нанять методологов, подготовить технологическую базу, переобучить сотрудников и потратить много времени и денег. А можно купить готовый набор бизнес-процессов у вендора. На этой стратегии и зародился BaaS. 

Ступень 5. BaaS — Business as a Service

Идёт эпоха BaaS, и компании получают возможность покупать другие бизнесы как отчуждаемую коммерческую услугу. Это позволяет улучшать собственные процессы, повышать ценность для потребителей и формировать новые продуктовые предложения. Но главная выгода для компании — в экономии издержек. А конечный потребитель покупает товар на более интересных условиях либо получает новые товары и услуги.

Эта иллюстрация показывает эволюцию к BaaS в IT:

Частный случай BaaS — это Banking as a Service, то есть покупка готовых банковских продуктов для поддержки бизнеса. Например, владельцам успешного магазина пришло в голову выпускать банковские карты для покупок в рассрочку. В модели SaaS им придётся открыть или купить банк, а затем взаимно интегрировать банк и магазин, чтобы выпускать карты под своим именем.

А Banking as a Service позволяет владельцам магазина купить у банка нужный бизнес-процесс. При этом не понадобится получать лицензию ЦБ РФ и набирать штат сотрудников. Всё это есть у банка-поставщика, который передаст в аренду цельный бизнес-процесс как услугу. Конечный потребитель не заметит разницы.

Чем SaaS отличается от BaaS

Поскольку моя предметная область — банковские продукты, далее в статье я буду использовать BaaS в узком значении — Banking as a service, то есть поставку банкинга как услуги. Хотя нет особой разницы, какой бизнес передаёт вендор.

В подходе BaaS всегда есть три стороны: 

• Конечный потребитель.

• Компания-партнёр, которая продаёт что-то потребителю.

• Вендор, поставляющий бизнес-процессы на продажу.

Модель SaaS предполагает, что потребитель должен обращаться к двум поставщикам услуг. Например, отдельно сходить в магазин, и отдельно — в банк за картой рассрочки. При этом магазин и банк должны взаимно интегрироваться, чтобы обрабатывать запрос на покупку товара по этой программе рассрочки. С точки зрения бизнес-логики, банк просто купит этот товар у компании-партнёра, а конечный потребитель будет должен деньги банку. Комиссию, то есть выгоду с этой продажи, получит банк.

В случае с BaaS компания-партнёр покупает бизнес-процесс эмиссии карт рассрочки. Банк для этого предоставляет свой API. Потребителю не придётся обращаться в банк: можно оформить карту в магазине и получить наиболее выгодное предложение по покупке товара. Деньги от продажи поступают напрямую магазину. Банк получает плату за использование его ресурсов и не несёт издержки по обслуживанию клиента.

Условия могут быть разными, всё зависит от договорённости между поставщиком и получателем банковских услуг. Наибольшую выгоду от сделки получает компания-партнёр.

Зачем это банку?

• Чтобы снизить затраты на обслуживание клиента. Часть клиентов пользуется картой рассрочки один раз и не покупает новые банковские продукты. Самостоятельно привлекать и вести таких клиентов банку невыгодно.

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

• Чтобы получить возможность пользоваться обезличенной аналитикой. Выпуская обычную карту для клиента, банк «знает» о нём минимальные данные, сбор которых продиктован регуляторной политикой. От компании-партнёра можно почерпнуть данные о транзакциях: что покупают в этом магазине, на каких условиях, в каких географических точках. На основании этого банк анализирует покупательную способность и делает выводы, в каких направлениях движется капитал. Дальше можно проследить тенденции, сделать прогноз и скорректировать свои продукты. И конечно, предложить партнёру расширить функции. Если в примере с магазином карты рассрочки будут успешны, следующим шагом может быть совместная программа лояльности, например кешбэк. Это потенциально увеличит спрос со стороны покупателей.

Многие банки по BaaS-парадигме постепенно встраиваются в рынок финтех-компаний. Они уже предоставляют не классические банковские продукты, а платформы по взаимодействию с этими продуктами. Можно сказать, что банки становятся теневым игроком во взаимодействии конечного потребителя и компании-партнёра.

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

Как технически реализовать BaaS

С технической точки зрения для внедрения BaaS нужна платформа, которую разработает вендор бизнес-процессов. Под капотом будет набор API для взаимодействия. Существуют API-решения для услуг по модели SaaS: компания-партнёр с их помощью, например, выдаёт клиенту банковскую выписку. Чтобы предоставить BaaS-услугу, нужно API-решение для целого бизнес-процесса, например эмиссии банковской карты.

Вся логика этого бизнес-процесса — кому и на каких условиях предоставлять банковский продукт — реализуется на стороне партнёра. Банк просто выполняет «заказы» с помощью API-интеграции, вызывая отдельные сценарии процесса. Причём порядок и параметры вызова определяет партнёр, исходя из его продуктовой стратегии. Технически для этого нужно только один раз построить платформу.

Для этого существует два подхода:

• Вендор предоставляет готовый бизнес-процесс. Он обеспечивает комплект сервисов API, с которым будет взаимодействовать партнёр. Этот подход предполагает фиксированный набор действий, ограничения со стороны вендора. Действия партнёра будут стандартизированы, все конечные потребители получат идентичный банковский продукт.

• Вендор делит свои бизнес-процессы на отдельные процессные элементы, из которых можно собрать что угодно. То есть максимизировать гранулярность своего API. Например, обеспечить по API доступ к каждому этапу эмиссии банковской карты: проверка клиента, скоринг, формирование персональных предложений, утверждение условий и выпуск карты. Порядок использования этих этапов можно отдать на усмотрение партнёру. Он самостоятельно обеспечит KYC (проверка know your client), проведёт скоринг и решит, какую карту предоставить. Так можно обеспечить каждого потребителя разными картами — будут отличаться тариф, комиссия за покупки, кешбэк.

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

Примеры BaaS и SaaS-решений

• Компания X5 Retail Group покупает у Альфа-Банка BaaS-решение. Под лицензией банка делается X5 Карта. С точки зрения брендинга это продукт White Label — на карте нет упоминания Альфа-Банка. Потребитель связывает её только с брендами «Перекрёсток» и «Пятёрочка».

• Отели хотят привлекать клиентов, но не хотят заниматься технической реализацией продажи путёвок и создавать для этого IT-департамент. SaaS-решение — интегрироваться с сервисом-хостингом страниц всех отелей. Например, в России это Национальный туроператор «Алеан». Поставщик услуги берёт на себя процесс оформления клиента. Отель получает деньги за клиента и информацию, когда и куда его поселить. Пользователь взаимодействует только с сервисом. Для изменения или отмены брони не надо обращаться в отель.
  Если это BaaS-решение, партнёр покупает обёртку с приёмом платежей. И пользуется бизнесом по оформлению заявок — за комиссию вендору. Для конечного потребителя это выглядит как личный кабинет на сайте отеля. Отель не просто купил ПО. Под капотом — этап проверок и работа сотрудников.

Какие перспективы у BaaS

Понятия BaaS и Open API не тождественны. Open API — это наиболее удобный технический способ реализации BaaS. Какого-то рода API используются и в моделях SaaS, PaaS, IaaS. Даже монитор «общается» с компьютером через API. BaaS — это эволюция SaaS с помощью Open API. Эти модели не взаимозаменяемы, предприятие может использовать и SaaS, и BaaS.

Open API — это техническая сторона медали, одна из возможных технологий, составляющих комплексные решения BaaS. Вендоры начинают выстраивать свои Open API-платформы в парадигме BaaS. В результате будут получаться всё более универсальные решения, которые можно подстроить под нужды конкретных партнёров. Например, компании нужно реализовать процесс из 10 этапов. Руководство понимает, что 3 этапа можно реализовать самостоятельно. Для других 5 этапов приобрели SaaS-решение. Ещё 2 этапа реализуют в BaaS-режиме. Это мобильно выстроенный бизнес. Open API интегрирует все части процесса между собой.

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

Развитие технологии зависит от того, куда будет двигаться рынок. Рассмотрим оптимистичный сценарий. Скорее всего, бизнес для максимизации прибыли построит свои процессы на базе доступных BaaS-решений. Да, обвязку нужно будет делать на своей стороне, но появится возможность быстро внедрять готовые бизнес-процессы, которые будут дешевле собственных.

В этом случае разовьётся много так называемых экосистем. Они обогатятся современными техническими решениями вплоть до применения искусственного интеллекта. Сейчас компания OpenAI предоставляет SaaS-решение — ChatGPT. Возможно, следующим шагом разработает на его основе готовый бизнес-продукт. Это вопрос технической зрелости. Сами по себе нейросети — технология, а не продукт. Пример продукта — это кредитный скоринг на основе искусственного интеллекта, он уже реализуется. То есть BaaS даёт возможность развивать продукты от поставщика к поставщику, обогащая их дополнительной ценностью для определённых групп потребителей.

Чем больше финтех-компаний понимает, что могут заработать на BaaS, тем больше появляется инновационных продуктов такого типа. Бизнес будет соткан из BaaS-решений разных компаний. Это повысит конкурентоспособность новых продуктов, позволит внедрять инновации на стыке разных сфер производства и услуг. Крупные компании, такие как Amazon, будут притягивать успешные BaaS-решения, поглощая других игроков.

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

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