Cофт для финтеха: делать самим или брать в аренду?

Юрий Мейталов, доктор инженерных наук, директор IT-отдела британской финтех-платформы Bilderlings, рассказывает о плюсах и минусах обоих вариантов, о том, как выбирать поставщиков SaaS и как собрать свою IT-команду.

Любой финтех-бизнес сталкивается с выбором: создать свой софт или взять в аренду. Если точнее, варианта три:

• взять уже готовый софт в аренду (SaaS-решения);
• заказать создание софта у третьих лиц (аутсорсинг);
  
• или создать софт самому, силами своей IT-команды.

Главное, чем определяется итоговый выбор, — это что именно вам нужно, какие у вас альтернативы и как быстро надо начать.

Во-первых, многое зависит от профиля компании, от того, на чем она специализируется (например, есть ли подходящие готовые решения под вашу специфику). Во-вторых, зависит от вашей бизнес-стратегии и формата интеграции — насколько развита в компании вертикальная интеграция.

Если вы делаете что-то уникальное, out of the box, удобнее делать самим.

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

Например, система АБС (автоматизированная банковская система, Core banking system) стоит в диапазоне от $500 тыс до $1 млн (цифры очень приблизительные, все зависит от деталей). И ее развертывание занимает около года. Учитывайте также плату за аренду, которая по договору у вас будет минимум на пять или 10 лет.

То есть вы заплатите сразу полмиллиона за интеграцию и еще потом по $100 тыс. в месяц за аренду. Отметим, что АБС не обязательно нужна каждому финтеху и не обязательно нужна на старте — здесь просто приводим в качестве примера.

Купить готовое решение или потратить год на разработку, наняв айтишников? Это может обойтись примерно в одну и ту же сумму. Но с готовым решением можно сразу выйти на рынок и весь этот год (потраченный на потенциальную разработку) продавать и зарабатывать.

Выходит, важно еще и то, сколько вы можете заработать за этот год. Однако если работать на своем продукте, кастомизировать и дорабатывать его будет значительно проще и дешевле.

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

Например, вы запустили финтех-стартап на основе купленного коробочного решения, а потом понадобилось внедрить автоматизированную систему AML (Anti Money Laundering — программы, направленные на борьбу с отмыванием средств). Для этого ее надо кастомизировать.

Чаще всего такие услуги можно заказать у поставщика софта, но они достаточно дорогостоящие. Кроме того, поставщик может внедрять это и у других клиентов — то есть вы заплатите, а он продаст это решение и остальным.

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

Многие банки 20 лет назад запускались на купленных системах, интегрировали их друг с другом, и все работало. Но спустя годы в итоге приходили к выводу, что нужно свое решение, и вкладывались в IT-команду и разработку своего ПО.

Во-первых, поставщик всегда может закрыться. Тогда ваше решение сразу перестанет быть доступным.

Другой риск — это риск утечки данных. Все, что хранится не у вас, вы не можете контролировать и быть на 100% уверенными, что там все в порядке. И если утечка произойдет на стороне поставщика услуг, то репутационные и финансовые риски в итоге все равно будут на вас.

К этому стоит отнестись ответственно, помня, что продать хотят все и всё. Основной алгоритм такой:

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

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

Богатый опыт и наличие крупных клиентов также не гарантируют вам, что все будет идеально: может быть так, что продукт вам просто не подойдет.

Здесь всегда можно обжечься.

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

Большинство IT-систем умирают, когда уже невозможно внедрить новую фишку, которую система не может поддерживать. Часто такое случается при увеличении числа клиентов: просто ПО не обладает той пропускной способностью, которая требуется вам на данном этапе.

На предыдущей работе мы использовали системы 20-летней давности, и в какой-то момент моя команда столкнулась с тем, что там вообще ничего не изменить. Работали только с баг-репортами. Тогда пришлось делать выбор: купить снова готовое решение или вычеркнуть это и сделать все с нуля (выбрали последнее).

Нужны ключевые люди: лиды, вокруг которых наращивается команда.

Нанять много джуниоров и надеяться на лучшее — опрометчиво.

Нужны люди, которые понимают систему, с которой работают. Для постановки задачи нужны аналитики. Кто-то должен направлять команду, управлять ими, давать ими задачи. Это иллюзия, что можно нанять программистов, которые сами будут делать «что-то».

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

Важно заранее продумать сторону HR, сторону бизнеса, кто какими проектами будет заниматься и как будет проходить мониторинг, чтобы понимать, что и насколько эффективно происходит.

Если вы прогнозируете рост, надо на старте понимать, как вы будете этим ростом управлять и перестраиваться.

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

Если команда уже есть, надо искать других центровых людей — а значит, проводить кучу интервью. Нужен хороший HR и умение принимать решения вместе с командой, чтобы человека оценивали и с технической точки зрения, и с личной. Коллектив должен быть слаженным — нанимать несколько талантливых разработчиков, которые не умеют общаться, рискованно. Человеческий ресурс так же важен, как и все остальные, поэтому вопросы HR стоит учитывать на старте, в том числе выбирая между SaaS и разработкой своего софта.

Полностью материал можно прочитать на сайте Rusbase.