Для этого нужно шаг за шагом преобразовать функции и процессы в приложение, API или инструменты аналитики, а затем вывести их на рынок как совершенно новую технологию. В конце концов, это можно будет проделать со всеми банковскими операциями, и банк целиком окажется на открытом рынке, избавившись по пути от старых технологий. В крупной компании такая стратегия растянется на много лет, потребует лидера и стратегического видения, но ее можно реализовать. Однако когда банк приступит к таким изменениям, перед ним встанут две проблемы.
Первая связана с планированием таких преобразований, ведь у банка есть и другие неотложные дела. Например, банк практически ежедневно сталкивается с изменениями в нормативной базе и новыми требованиями, вынуждающими в первую очередь обновить старые системы. Обновления в ответ на требования регулятора съедают весь бюджет, даже если речь идет о доработке всего нескольких строк кода, ведь этот крошечный фрагмент кода может повлиять на мириады других строк. Поскольку все это требуется проверить и перепроверить, прежде чем запускать в работу, подобные обновления получаются очень ресурсозатратными и обходятся в миллионы. Вот почему банкам не хватает бюджета на инновации – большая часть средств тратится на старые системы, и, как говорят многие исполнительные директора, приходится просто следить за тем, «чтобы свет не гас».
Допустим, банк смог перестроиться и выбраться из этого хаоса, взял курс на открытый банкинг, основанный на работе с приложениями, API и аналитикой, – в чем тогда проблема? Ну слон из комнаты никуда не делся. Новая структура организации основывается на переходе от монолитных макросистем к автономным микросистемам. Однако банкам не нравятся автономные микросистемы. Они привержены тотальному контролю и не приемлют ничего иного. Банки привыкли работать медленно, чтобы все было под контролем и отвечало требованиям регулятора. Таким образом, переход к микросервисной архитектуре, которого требуют современные гибкие, дешевые, быстрые и простые технологии, сложен как раз для такой организации, чья культура пропитана контролем и следованием правилам.
Рассуждая об этом, я обычно говорю, что в микросервисной организации есть команды разработчиков размером не более двух пицц. То есть такую команду можно накормить, заказав на обед две пиццы. Если команде требуется три пиццы, значит, она слишком велика. Вся суть в маленьких и гибких адаптивных командах, умеющих быстро вносить изменения.
Итак, вообразим, что банк сформировал организацию-разработчика, применяющую микросервисную архитектуру. Каждая из команд трудится над своим фрагментом кода. Каждая команда может быстро изменить его и встроить обратно в общую архитектуру. Поскольку ни одна из команд не отвечает за весь код, никому не приходится под ним подписываться. Вот в чем загвоздка. Разве может банк отказаться от тотального контроля и позволить ордам умников заниматься им одним понятными вещами?
Если же сможет, то сможет и позволить себе ежедневный перезапуск. Однако я сомневаюсь, что многим это удастся. Так, мне довелось побеседовать об инновациях с топ-менеджером банка, и он мне объяснил, что такое «уловка-22» по-банковски. Вы хотите быть инноватором, только если это не сопряжено с рисками. Но риск – неотъемлемая часть инноваций. Можете играть в песочнице, как малые дети, но, если попытаетесь из нее выбраться, вас одернут и затащат обратно. Тут ваше место – тут и оставайтесь.
Я отмечал, что любые инновации, взятые из песочницы
[47], невероятно сложно приживаются, поскольку банковская культура заточена на уничтожение антител, привносимых в нее инноваторами-пожирателями. Вот почему возглавлять внедрение инноваций в любой финансовой компании – адова работа, которая непременно приведет вас в финтех-стартап или в центр занятости.
Банкир поразмыслил над этим, а потом выдал кое-что действительно интересное. Он заметил, что банки не любят проигрывать. Да, нам это известно, но сам феномен целиком связан с культурой работы по правилам. Проигрыш чреват проблемами и предупреждениями со стороны регулятора. Банки любой ценой стремятся избежать таких предупреждений, вот почему проигрыш для них не вариант. Я предположил, что микросервисные архитектуры на открытых рынках API дают им право на такой провал, поскольку в этом случае им не грозят репрессии, на что он ответил:
«Смотрите, Крис, вам это должно быть известно. Мы банк, и нам трудно инвестировать в гипотезы. Так, если мы запустим проект на $1 млн и он провалится, то будем с пристрастием выяснять, что пошло не так и, гораздо важнее, кто за это отвечал. Потребуется найти виноватого. Которого затем уволят. Однако если мы задумываемся о проекте стоимостью $1 млн, то можем обратиться в консалтинговую компанию. Они изучат его и сообщат нам, будет ли он успешным или нет. И, заметьте, все останутся довольны. Поэтому мы можем привлечь большую команду консультантов, заплатить им $1 млн за отчет, который покажет, что наш проект провальный. Ровно столько же мы потратили бы на его запуск. Все, однако, довольны. За $1 млн нам сказали, что проект не стоит начинать. Зато скольких дальнейших расходов, позора и стыда они помогли нам избежать».
Уф! Я осознал всю абсурдность и одновременно реалистичность его тезиса. Увидел это собственными глазами. Гораздо лучше, чтобы пришел кто-нибудь со стороны и сказал вам, правы вы или ошибаетесь. Ведь если позднее окажется, что его совет оказался ошибочным, вам будет кого винить и, возможно, на кого подать в суд. Однако когда то же самое вам скажет человек из собственной компании, горе ему, если он ошибался.
Этот подход объясняет и множество других загадок. Вспоминаю топ-менеджера одного из банков, рассказывавшего о бизнес-плане, окупаемости инвестиций, анализе «затраты – эффективность», а также о будущем доходе с проекта и его издержках. Он сказал, что банк строго следит за тем, чтобы экономическое обоснование подводилось подо все и вся. Если вы хотите начать новый проект, то сначала должны показать цифры.
Это сложно, если вы занимаетесь инновациями, поскольку никто до вас ничего подобного не делал, – а вы все равно должны прийти с цифрами. Фокус в том, сказал он, что цифры должны выглядеть убедительно. Покажите, что действительно изучили вопрос. Обратились в консалтинговую компанию, которая подобрала фокус-группы из вашей целевой аудитории, и представители этих групп стопроцентно убеждены, что ваше приложение нового поколения уже через месяц наберет миллион пользователей. Затем представьте все эти прогнозы на графиках. Это должно выглядеть потрясающе. Не ограничивайтесь презентацией в PowerPoint или PDF – привлеките лучших графических дизайнеров, а затем добавьте несколько гифок и видео, чтобы топ-менеджеры на совете директоров не уснули.
Только так вам выделят деньги. Вы получите средства благодаря красивому, но состряпанному на коленке бизнес-плану. Вы быстро сделали экономическое обоснование, все цифры взяли с потолка и набросали на салфетке в пабе, обсуждая детали. У вас есть цифры, и, похоже, вы можете их обосновать, вы провели исследование рынка и подготовили шикарную презентацию – вот поэтому вам выделили деньги. После того как деньги придут, можно ни о чем не беспокоиться, потому что никто не придет проверять цифры за прошлый год, если только ваши показатели существенно не просядут. Если вы как следует проработали цифры и определили свою политику, сможете долго обходиться без проблем.
