Помоги проекту - поделись книгой:
Вот такой COBOL.
По оценке финансовой консалтинговой компании Celent, не менее 75 % или свыше $200 млрд, затрачиваемых банками на IT-нужды, идет на поддержку устаревших систем. Королевский банк Шотландии (RBS), уплативший регулятору рекордный штраф за глобальный отказ своих систем в 2012 году, рассчитывал решить эти проблемы, заменив основной движок процессинга и потратив на это £750 млн. Однако СЕО банка Росс Макьюэн три года спустя признал, что предстоит еще большая работа по сокращению количества систем и приложений, эксплуатируемых в RBS, – их насчитывалось более 3000.
Комментируя схожую проблему, Андреа Орчел, глава международного инвестиционного отдела UBS, сказал: «Острая проблема большинства банков – они нетехнологичны… Технологии продолжают стремительно развиваться и становятся критично важными для банковского сектора, и банку приходится лавировать в пространстве, которое технологически очень сложно устроено, где не работают приемы, в которых банк наиболее компетентен». Правда? Я сам много раз это подчеркивал, но банками управляют банкиры, тогда как за управление в равной степени должны отвечать и инженеры – как это делается в финтех-компаниях.
Так или иначе, проблема с устаревшими АБС будет усугубляться, в конечном счете потому, что люди, занятые поддержкой устаревшего кода, постепенно вымрут (если закрыть глаза на прочие факторы). Этот феномен не нов. Еще в 2012 году журнал Computerworld провел опрос и выяснил, что 46 % IT-специалистов считают, что поле для программирования на COBOL (аббревиатура означает «универсальный язык, ориентированный на коммерческие задачи») сокращается, а 50 % отметили, что средний возраст специалиста по COBOL – 45 лет и старше.
Почему почти половина систем, функционирующих на основе мейнфреймов, написана на языке COBOL? Этот вопрос, в частности, задан на сайте Quora. Мне бы хотелось процитировать здесь все ответы, но по понятным причинам не получится. Я лишь подчеркну, что 50-летние вложения в безнадежно запутанный код COBOL сегодня становятся самой крупной проблемой для банков, открывающих доступ к своим структурам. Выживут банки, переходящие к использованию облачных корпоративных архитектур, данные в которых рационализируются и консолидируются на машинном интерфейсе. Вымрут те, кто полагает, что не пропадут со своими надежными и стабильными системами, написанными на COBOL.
Устаревшие системы нужны ретроградам
Проблема не только в устаревшей системе, но и в сотрудниках-ретроградах и клиентах-ретроградах. Такие сотрудники противятся переменам. Они знают, на чем заработать кусок хлеба, и никуда не хотят двигаться. Еще они присматриваются к новым технологиям и размышляют, как адаптировать их под существующие процессы. Например, банк выстроил огромный виртуальный филиал для работы через очки виртуальной реальности Oculus Rift. Да, банк может предоставить клиенту дополненную реальность. Но если в подлинной реальности человек даже не заглянет в этот банк, зачем ему посещать отделение в виртуальной?
Подобные унаследованные преграды, мешающие переменам, а также стереотипное мышление заставляют нас выводить породу самых быстрых лошадей, а не изобретать новый скоростной транспорт. Спросите старомодного клиента, чего он хочет. Ответы могут отличаться, но, скорее всего, будут упомянуты снижение комиссии, более высокие процентные ставки, желание ощущать «особое» отношение. Да, этим и занимаются все альтернативные банки, но клиента интересует не форма, а суть. Вот почему появляются банки, предлагающие инновационные приложения, удобные платежи и бесплатные счета, а клиенты все равно пользуются интернет-банкингом (потому что не доверяют мобильным приложениям), чеками (с ними проще, чем с наворотами PayPal) и сберегательными книжками (да, раньше все ими пользовались, я хочу видеть, сколько у меня на балансе).
Это может выглядеть смехотворным – но покажите мне хотя бы один крупный банк, полностью распрощавшийся с наследием прошлого. Если у банка были отделения, они так и остались (может быть, чуть в меньшем количестве); если банк пытался избавиться от чеков, то поднимался такой гвалт, что чековые книжки приходилось оставлять; а если клиентам предлагали отказаться от той или иной услуги (например, закрывали отделение), пресса чернила такой банк, как Лорда Волан-де-Морта из книг о Гарри Поттере. Инновации сами по себе не прославят банк, особенно если при их внедрении приходится сообщать клиенту, что ему придется отказаться от чего-то привычного. Потому и продолжают работать старомодные банки с сотрудниками-ретроградами, выискивающими клиентов-ретроградов.
Это еще одна причина, по которой никто не меняет устаревшие АБС. Разве банк потеряет клиентов, если ничего не будет менять в своем пятидесятилетнем ядре (и при этом не сможет эффективно конкурировать и противостоять киберугрозам)? Нет. Так зачем что-то менять? Если клиенту все равно, с какой системой он работает, а проблем с процессингом и эксплуатацией не возникает, зачем ломать то, что работает? Где веская причина, по которой нужно заменять АБС полувековой давности?
Кто-то таких причин не видит, поскольку замена АБС – сложная задача. Учтите, что та система, о которой мы сейчас говорим, вероятно, появились в середине 1970-х годов при обновлении АБС клиентских депозитных счетов; обновление потребовалось, чтобы адаптироваться к внедрению банкоматов. Это была пакетная модификация, система перфокарт, которая годами обновлялась и совершенствовалась. Ее возможности не ограничивались обслуживанием филиалов, поэтому она стала в режиме реального времени обеспечивать доступ к балансу в интернет-банкинге через интерфейсы промежуточного ПО. Таким образом, через 25 лет после внедрения эта АБС стала центральным элементом обновления балансовых данных по миллионам клиентских счетов, обросла сложной структурой интерфейсов и компонентов, благодаря чему выглядела весьма неплохо, пусть даже банку было известно, насколько она архаична. Она работала, а зачем ремонтировать то, что не сломалось?
Банк из года в год руководствуется такой логикой при стратегическом обзоре технологий – и неизменно приходит к одному и тому же выводу. Менять придется не только АБС, но и все, что с ними связано. АБС середины 1970-х годов «обросли» таким количеством надстроек, что любая модернизация означает полномасштабную замену всего и вся. Такая работа обойдется в миллиарды, и нет никаких причин ею заниматься, если система по-прежнему жизнеспособна. Проходит еще 10 лет, а эта аргументация все еще сильна. Да, поддерживать старую систему дорого, но продолжать ее эксплуатировать куда дешевле и не так рискованно, чем все менять.
К сожалению, такое не может длиться вечно. Технологический ландшафт стремительно меняется. АБС, где все возможности интегрированы в простой клиентский интерфейс, стыкующийся с интерфейсом базы данных, становятся все более затратными. Клиенты хотят приложений, партнеры хотят API, а конкуренты переходят от внутрикорпоративных закрытых структур на открытые платформы, где можно работать в облаке. В силу применения анализа данных и машинного обучения конкурировать приходится уже на уровне персонализированных предложений. Кроме того, конкуренты снижают издержки, избавляясь от старых АБС и переходя к современным интернет-архитектурам. Однако старая добрая АБС, загнанная в угол, по-прежнему работает, поэтому менять ее незачем, верно?
Думаю, именно здесь становится актуален мой основной аргумент о необходимости заменить АБС. Мы живем в интернет-эпоху открытых финансов, и наши бизнес-модели, архитектура и инфраструктура должны поспевать за временем. Мой ключевой месседж: впервые в истории новые технологии стали подтачивать АБС бэк-офиса.
Тем не менее некоторые банки по-прежнему будут упорствовать, что нет никакой срочности или острой нужды обновлять АБС полувековой давности. Однако рано или поздно регулятор принудит их модернизировать свои АБС, обязав обеспечить возможность подключения служб банковского надзора к системам банка в режиме реального времени через API, а также предоставить возможность подключения сторонних организаций к балансовым счетам клиентов. Во что это обойдется? По-видимому, эти банки потратятся сильнее, чем все остальные. Ничего страшного, затраты можно компенсировать комиссиями за овердрафт и по кредиту, но ведь старомодный клиент может это заметить. Только тогда подобные банки поймут, что пришло время менять устаревшие АБС, но теперь, когда приходится вскакивать в последний вагон, такая задача может оказаться непосильной.
Что же делать банкам-ретроградам? Во-первых, им нужно осознать, что проблема существует. Во-вторых, попытаться ее решить. В-третьих, понять, что для этого требуется реконструкция фундамента, а не просто косметический ремонт. Наконец, нужны воля, умение принимать трудные решения и сильное руководство, чтобы запустить процесс трансформации и преодолеть косность менеджеров среднего звена.
Я все время вспоминаю тезис, озвученный 20 лет назад Томом Питерсом. В своем выступлении он рассказал о бизнес-трансформациях в американской железнодорожной компании Union Pacific Railroad. Кто-то из команды сказал: «Организация вас либо дожмет, либо дождется вашего ухода». Это так. Однако если банк найдет лидера, который не допустит ни первого, ни второго варианта, то будет реализован третий: выстраивание организации, которая позволит покончить со стереотипами и соответствовать требованиям XXI века.
Мой опыт подсказывает, что единственная причина, по которой банк не меняет устаревшую АБС, – генеральный директор рассчитывает, что останется у руля еще два-три года. В результате он перекладывает все риски и затраты, связанные с фундаментальными переменами, на своего преемника. Вот почему АБС доживают до таких почтенных лет. Каждое поколение менеджеров просто переводит стрелки на тех, кто придет следом. Такой подход работал 30 лет, но, поверьте мне, он перестанет функционировать в нашу эпоху опенсорсного финансового обмена.
В самом ли деле нужно перестилать дорожное покрытие?
Давайте сравним финтех с транспортом. Да, финтех-компании разрабатывают беспилотные автомобили, но ведь это не повод перестилать дорожное покрытие, правда? Нет. Транспортная система обеспечена колоссальной инфраструктурой, в которую входят и скоростные шоссе, и автомагистрали, и железные дороги, и аэропорты. Если технология привела к переосмыслению идеи автомобиля, поезда или самолета, это не означает, что нужно реконструировать всю шоссейную, железнодорожную инфраструктуру и аэропорты. Просто надо эксплуатировать имеющуюся инфраструктуру более эффективно. Производители автомобилей, поездов и самолетов должны определиться, смогут ли они адаптироваться к инновациям, принесенным на рынок новыми игроками. Вот почему в General Motors, Ford и BMW столько говорят об угрозах со стороны Tesla, Google и Apple. Когда беспилотные автомобили станут захватывать рынок, старожилы постараются за ними угнаться и попробуют сами предложить достойные аналоги со всевозможными наворотами.
Вернемся к финтеху. Большинство компаний из этой сферы разрабатывают новые виды платежей, транзакций, обмена цифровыми активами и их хранения. Одни очень специфичны, а другие – подлинные новаторы, но никто из этих компаний не заставляет нас перестилать все дорожное покрытие. Фактически почти все они пользуются теми же «шоссе», «железными дорогами» и «аэропортами», которые возвела банковская система. Возможно, они вынуждают банки обновить эти АБС (например, внедрить проекты с использованием открытого реестра при клиринге, расчетах и платежах), но радикальная реконструкция и перестройка всей сети при этом не требуется.
Присматриваясь к финтех-компаниям, я вижу, что их можно разделить на несколько категорий. Большинство дополняют уже существующую финансовую систему, создавая решения, которые чертовски проще имеющихся. Таковы, например, онлайн-платежи напрямую между клиентом и продавцом (услуга Stripe), перевод небольших сумм от одного пользователя другому с помощью приложения для мобильного телефона (услуга Venmo) или работа в тех регионах, куда не добрались крупные банки (например, Square для небольших компаний или M-Pesa и мобильные кошельки, используемые в Африке южнее Сахары).
Там, где банки ведут основной бизнес, финтех-стартапы еле выживают. Bloomberg опубликовал очень показательный отчет в подтверждение этого тезиса. У альтернативного банка нет клиентов, репутации и капитала – все это проблемы. Если банку удастся с ними справиться и завоевать долю рынка, его просто купит крупный рыночный игрок, например BBVA.
Традиционным банкам тоже приходится туго. Недавно серьезные проблемы испытали Deutsche Bank и Wells Fargo. Ранее прекратили работу RBS, Northern Rock, Wachovia и Washington Mutual. Однако эти провалы связаны с ошибками менеджмента, а не с технологической стратегией. Поэтому я возражаю тем, кто связывает неудачи с финтехом: ни одного крупного игрока стартап не свалит, ни один стартап пока не стал козырем и не побил туза.
«Тузы» владеют дорогами, строят автомобили и обслуживают сеть. Да, могут появляться новые автомобили и новые способы эксплуатации сети, и проблема крупных игроков – поспевать за этими изменениями. Однако сама идея о том, что такие изменения подвигнут перестилать дорожное покрытие, отстраняться от клиентов, не реагировать и в итоге бросаться со скалы, – вздор.
Я пишу эти строки, потому что нынешняя ситуация меня не устраивает. Естественно, мы должны перестилать дорожное покрытие – по той простой причине, что наш транспорт сильно изменился. Отличный пример таких перемен – сама природа базовой транспортной инфраструктуры, которой мы пользуемся.
Исторически технологическая архитектура выстраивалась на основе жестко контролируемых программных систем. В 1990-е годы мы перешли к системам, основанным на модульных вычислениях, объектно-ориентированной архитектуре и сервис-ориентированной архитектуре (SOA). Сегодня мы живем в мире автоматически конфигурируемых API и открытых рынков. Старые и новые структуры очень отличаются, хотя между ними, безусловно, есть сходство.
Объектно-ориентированные разработки, реализованные в 1990-е годы, были рассчитаны на автоматическую конфигурацию только внутри системы. Современные открытые API разрабатываются с прицелом на автоматическую конфигурацию с компонентами внешних систем. Разница в акцентах; она означает, что можно перестроить дороги при помощи более гибких подходов, воспользовавшись открытыми рынками и краудсорсинговыми разработками.
Обновление АБС напоминает ремонт метро
Недавно мне встретилось сравнение, в котором банки, их системы и структуры сопоставлялись с устройством лондонской подземки. Я говорю о многочисленных трубах, проводах, кабелях и туннелях, которые прокладывались в Викторианскую эпоху, но эксплуатируются по сей день. Ежедневно и еженощно инженеры поддерживают систему в рабочем состоянии, а также регулярно ремонтируют пути. На станциях метро появились кондиционеры, лифты, пандусы для колясочников, Wi-Fi и прочее, благодаря чему эти древние залы выглядят современно, хотя это лишь видимость. По сути, они так и остались образцами викторианской архитектуры и помнят дела давно минувших дней.
Обсудим две истории. Первая – о том, как сложно встроить современную лифтовую шахту в существующую подземную станцию метро (стоимость работ – около £50 млн), вторая – об исключительно сложной прокладке новой линии метро (стоимость – £15 млрд). Сопоставьте эти истории с АБС – и вы уловите суть.
Строительство метро в Лондоне началось в 1863 году, и с тех пор подземка росла, пока не превратилась в обширную сеть, которая сегодня включает 270 станций и обслуживает около 4 млн пассажиров в день. Сейчас основные проблемы лондонского метро связаны с доступностью для всех категорий граждан и с дооборудованием старых станций лифтами, встраиваемыми в архаичную инфраструктуру под сильно загруженными улицами. Например, чтобы оснастить лифтом станцию Грин-Парк, потребовалось два года и £50 млн. Это всего лишь одна модификация одной станции, сделанная с учетом требований времени. Поставьте на место 270 станций 270 разных АБС, которыми оперирует банк, – и оцените масштаб проблем, когда речь заходит о модернизации.
Второй пример связан с Crossrail – это железная дорога длиной 120 км, ведущая из Беркшира в Эссекс, она должна была проходить под оживленными лондонскими улицами благодаря подземным тоннелям длиной 42 км. Здесь инженеры столкнулись со всеми теми сложностями, которые возникают при строительстве новой железной дороги в существующей инфраструктуре.
Суть двух этих историй в том, что большинство транспортных компаний тратят львиную долю своего бюджета на поддержание дорожной инфраструктуры. Transport for London (TfL) расходует более £10 млрд в год – в основном на техническое обслуживание. Немного напоминает банки, не правда ли? Затем, когда компания решает построить что-то новое, например Crossrail, такой проект всегда выходит более дорогим, более сложным и более трудоемким, чем планировалось. Например, первоначально стоимость строительства Crossrail оценивалась в £10 млрд, причем уже тогда были опасения, что завершить проект вовремя (к маю 2019 года) не удастся. Эта ситуация также напоминает большинство проектов по модернизации АБС. Эти же цифры иллюстрируют, почему банки и страховые компании так много тратят на технологии (полтриллиона долларов в год). К сожалению, как и у TfL, большая часть этих средств (75 %, по данным Celent) уходит на техническую поддержку.
Так удобно начинать с нуля в рамках финтеха, правда? Возможно, именно поэтому Gartner прогнозирует, что бюджет, заложенный на банковские технологии, в ближайшие годы существенно возрастет – чтобы идти в ногу со временем.
АБС должны проектироваться с учетом их морального устаревания
Рассуждая о переходе от собственных уникальных технологий к открытым, от контролируемых систем к свободным рынкам и о смещении акцентов с внутреннего на внешнее, необходимо учесть еще одно ключевое изменение, связанное с природой технологий как таковых. Вполне очевидно, что сегодня для запуска стартапа требуется всего несколько тысяч долларов, Amazon Web Services и яркая идея. Не нужно строить сложную инфраструктуру и ждать месяцами, пока сотни программистов что-то напишут. Вот почему в банковском секторе и в сфере электронных платежей возникло такое множество стартапов, и речь не только о крупных брендах, названия которых всем известны. Возьмем, к примеру, немецкий solarisBank. Очевидно, создать новый банк можно очень быстро, если у вас есть толковые люди, яркая идея и энтузиазм. Как минимум в Европе. Я замечаю по всей Европе множество новых банков и недавно лицензированных банков; их объединяет то, что они работают на открытых рынках, задействуют API, приложения и облачные технологии для быстрого старта и вливания свежей крови в банковскую систему; все происходит очень быстро. Например, некоторые успевают получить лицензию менее чем за год.
Все это так отличается от банковского сектора, в котором я проработал всю жизнь. Когда я только начинал заниматься банковскими технологиями, мы затрачивали огромное количество ресурсов на приобретение новой системы. Это был извилистый путь: обосновать, проанализировать окупаемость инвестиций и рентабельность, говорить и показывать презентации, показывать презентации и говорить, сталкиваться с огромным сопротивлением каждого, кто чаще говорил «да». Для многих и тогда, и сейчас сказать «да» – уже серьезный шаг. Дать согласие означает для банка взять на себя обязательства по пяти-, десяти- или даже двадцатилетнему контракту, изыскать миллионы или даже миллиарды долларов инвестиций и надолго определить направление стратегического развития банка.
Гнет «крупной сделки» до сих пор определяет решения многих банковских менеджеров-ветеранов, однако сегодня все стало проще. Если такие стартапы, как Ant Financial, solarisBank, Thought Machine, PrivatBank и другие, смогут написать и запустить всю необходимую банкам линейку ПО, станет очевидно, что сейчас все решают скорость, гибкость и экономичность. Нет тут ничего от серьезного шага. Фактически можно выстроить непрерывно обновляющийся банк: микросервисная архитектура позволяет очень маленькой команде постоянно менять небольшие части архитектуры. Банк, способный обновлять свои приложения и API ежедневно или даже чаще, отличается от тех, которые делают это ежегодно или даже раз в два года.
Здесь я повторю свой призыв: заменяйте АБС, поскольку именно из-за них внедрение любых технологических изменений сегодня – это очень серьезный шаг. В настоящее время банку, увязшему в сложном, запутанном, устаревшем коде, очень сложно стать гибким, опенсорсным, переориентироваться на постоянную разработку и конкурировать с финтех-рынками. Он слишком тяжел на подъем. Любое решение обрекает банк на многомиллиардные траты и многолетние перемены, за это слишком сложно взяться. В конце концов, генеральному директору через пару лет на пенсию, его премии зависят от доходов акционеров, и ему достаточно изображать видимость действий на рынке, представив клиентам симпатичное приложение. Тогда никто не заметит, что бэк-офис невыносимо смердит.
Раньше такое было возможно, но сегодня уже не пройдет. В конце концов, инновационные банки, финтех-стартапы и новые игроки, практикующие гибкие подходы, имеют дело с совершенно иным миром. В их мире циклы сменяются очень быстро. Они могут одновременно отплясывать квикстеп, фокстрот, танцевать танго и самбу. Все это связано с пониманием того, что не бывает слишком сложных задач, непозволительных трат, ведь все их разработки делаются с учетом быстрого морально-технического устаревания, а их путь состоит из непрерывных технологических изменений.
Сравните такое устройство с работой более «традиционных» современников. Банки, запутавшиеся в спагетти-коде, «вальсируют» на рынке. Их движения медленные и отлаженные, в ответ на любую смену темпа они покашливают и кряхтят. Им известно, что все сложно и все стоит денег. Для них непозволительно моральное устаревание, поскольку оно неизбежно ударит по бюджету, по доходам акционеров и по бонусам топ-менеджеров. Их путь – добавление новых залов замку, а не его модернизация.
Знаю, я уже прожужжал вам уши, но в мире, где технологии стали расходным материалом, производственные циклы ускоряются, а технологическая конкуренция на открытых рыночных платформах становится лютой. Я бы всерьез обеспокоился, если бы стоял у руля банка, который даже войти в такой мир не может.
Нужен ли в банке IT-директор?
Недавно я беседовал с сотрудниками технологической фирмы, которая предлагает всевозможные решения от облачных технологий до АБС. Текущая ситуация такова, что им постоянно нужно обходить конкурентов. Не IBM. Не Accenture. Не Tata Consultancy Services (TCS). Не FIS. Не SAP. Никого из крупных брендов этого рынка, которые приходят на ум. Нет, их CIO (аббревиатура означает «генеральный директор по информационным технологиям»), IT-директора.
Я сам был в похожей ситуации. Помню, как мы прорабатывали грандиозную идею – полностью автоматизировать работу организации. У нас был отличный продукт, и мы решили выйти с ним на рынок, однако столкнулись с противостоянием исполнительного директора, который на корню пресекал все разговоры об автоматизации. Почему? Если автоматизировать работу компании, несколько десятков или даже сотня сотрудников лишатся работы.
Все это может звучать абсурдно – очевидно, суть автоматизации заключается в вытеснении людей, но тем, кто управляет такими империями, ничего подобного не нужно. Если банковские технологии станут опенсорсными, что ожидает тех многочисленных разработчиков, которые сегодня заняты техподдержкой старого хлама? Если вы внедрите безотзывные транзакции в открытом реестре, не требующие сверки счетов, что станет с фирмами, занимающимися такой проверкой, с их сотрудниками и заказчиками? Если все операции можно проводить в облаке, что произойдет с IT-отделом?
Кому-то такие страхи могут показаться смехотворными, но именно так мыслят многие люди, занимающие в банках должность IT-директора. Именно они поддерживают статус-кво, берегут свою империю, внедряют инновации по минимуму и борются за неприкосновенность сложившихся отношений с поставщиками ПО. Какой интерес такому человеку заниматься инновациями, которые могут привести к упразднению отдела, который он возглавляет?
Вот почему многие полагают, что айтишники и IT-директора будут вести себя так же, как раньше электрики. Пятьдесят лет назад в каждом банке был отдел электроэнергетики, его начальник отвечал за поддержание электросети в исправном состоянии и обеспечение электричеством всего банка. Интересно наблюдать за новым поколением бедолаг и размышлять о том, что у них нет будущего – а его у них действительно не будет через 10–15 лет. Почему? Потому что наступили фундаментальные перемены – переориентация технологий на потребителя.
По мере того как технологии развиваются в опенсорсном направлении, даже самый недальновидный генеральный директор начинает понимать, в чем смысл облачных технологий Amazon, что Gmail работает, Dropbox полезен, а CRMсистемы на порядок проще таблиц. Распространив эту логику на API вроде Stripe, умные приложения для умных вещей и распределенные реестры, подделать которые невозможно, даже самый закостенелый гендир задумается, зачем ему все эти архитекторы и клавиатурные виртуозы, эксплуатирующие системы, созданные в 1980-е годы (обходящиеся в целое состояние) и не стремящиеся к гибкости. Когда рынки, платформы и все финтех-сообщество приступает к выстраиванию пиринговой сети на основе алгоритмов, софта и серверов, даже Джейми Даймон вам скажет: надо что-то менять. Так оно и есть.
Удивительно, но множество инноваций в банках внедряется не технарями, а бизнес-аналитиками. Понятна и безотлагательность перемен, и то, что айтишники посрамлены. Банкиры и бизнесмены видят, как банкинг становится опенсорсным, и говорят: «Эй, ребята! Вы, BASIC-кишки нашего фортрановского банка, немедленно внедрите С++, а то нас обскачут на Java!» Примерно в таком духе. Банкиры видят угрозу, поэтому во многих репликах слышится страх.
• Джейми Даймон, СЕО банка JPMorgan Chase: «Когда я бываю в Кремниевой долине, то вижу, что [все они] отбирают наш хлеб».
• Урс Роннер, председатель совета директоров Credit Suisse: «Технологическая компетентность на уровне совета директоров – необходимость, а в скором времени она станет незаменимой составляющей финансовых институтов».
• Анри де Кастр, бывший СЕО AXA: «Цифровая трансформация – это уже не предмет выбора, а насущная необходимость».
• Ана Патрисия Ботин, исполнительный директор Santander: «Если сегодня задуматься о крупных игроках, окажется, что это не банки, а четыре крупные технологические компании (Google, Apple, Facebook, Amazon), которые стоят больше нас».
Руководители этих банков боятся технологической избыточности в своих организациях, поэтому реорганизуют их архитектуру, добиваясь слияния финтеха с банками. От этого должны проиграть тысячи штатных айтишников – разработчики и архитекторы. Однако не только они сойдут со сцены. За ними последуют многие их высокооплачиваемые сотрудники фронт-офиса, мнящие себя хозяевами Вселенной, тогда как на самом деле они операторы денежного рынка, выигрывающие чаще, чем проигрывающие. Их функции будут автоматизированы с помощью искусственного интеллекта и машинного обучения. Рыночные фонды уже движутся к пассивному инвестированию. Скоро специалист по управлению инвестиционными фондами займет место рядом с руководителем отдела технического обслуживания – и они будут размышлять, куда же делись их рабочие места.
Это не какой-то оторванный от реалий прогноз, а очевидный этап постепенного перехода от собственных уникальных систем к открытости и от внутрикорпоративных технологий, в которых никто (кроме технологов) не разбирается, к технологиям, ориентированным «наружу», понятным всем, в том числе клиенту.
Клиентоориентированные открытые системы, обеспечивающие совместимость рынков, – вот к чему движется мир, и если вы этого еще не осознали, хотя работаете в банке, то учитесь поддерживать, разрабатывать и создавать роботов и умные системы, поскольку именно в этих отраслях уцелеют те немногие технари, на которых в будущем еще возникнет спрос.
Банк, ориентированный на разработку
Во многих банках бытует мнение, что задача IT-директора – использовать технологии. Как правило, это они и делают. Но не этим им предстоит заниматься в будущем.
Человек, руководящий технологическими разработками в любом крупном банке, должен быть двигателем перемен. Все потому, что его основная задача – менять АБС, превращая их в опенсорсные структуры, основанные на использовании облачных технологий, аналитики, API и искусственного интеллекта. Это серьезная задача. Но самое важное – что делать, когда эта работа завершена?
Меня просветил мой друг Сергей Даниленко, специалист из технологической компании PrivatBank, которая, так уж случилось, предлагает в том числе и банковские услуги. Сергей занимает пост директора по маркетингу и отвечает за глобальное продвижение услуг банка, цифровая АБС которого работает в облаке, предоставленная сотнями API, образующих микросервисную архитектуру.
Микросервисная архитектура позволяет распределить все операции по обновлению и модернизации между небольшими независимыми командами, которые смогут управлять компонентами банковских технологий через внутренние приложения и API. Чтобы этого добиться, банк должен разделить все процессы, которые необходимо выполнить, и реализовать каждый из них в виде крошечного приложения. Каждое приложение будет разрабатываться отдельно и помещаться в сеть. Благодаря стандартизации все эти крошечные компоненты затем можно будет объединить, и это «целое» будет надежным и удобным в обслуживании прежде всего потому, что модернизироваться и обслуживаться будут мелкие фрагменты, а не колоссальная монолитная структура.
Все это очень отличается от устройства старых АБС, с которыми я привык иметь дело. Их работа обеспечивалась программами, состоящими из тысяч строк кода; требовался жесткий контроль изменений, поскольку любое обновление кода могло отозваться по всей системе и сломать ее. Микросервисная архитектура работает совершенно иначе. Можно менять что угодно и когда угодно, поскольку все компоненты независимы, разделены и распределены.
Еще один критически важный фактор: бизнес строится на микропроцессах. Хороший пример Stripe – API для организаций, которым нужна упрощенная система проверки. В ноябре 2016 года (спустя шесть лет после основания) она оценивалась в $9,2 млрд – очень неплохо для микросервиса.
Иными словами, финтех позволяет открепить все функции и процессы от продуктов и поставщиков ПО и предлагать их в виде микросервисов, которые благодаря DevOps, облачным технологиям и API могут быть переосмыслены в виде любой бизнес-модели и структуры на ваш вкус.
Данную концепцию удивительно образно объяснил Адриан Кокрофт, бывший облачный архитектор компании Netflix. Он рассказал о переходе компании от DVD к потоковому вещанию и о том, каким масштабным изменениям пришлось подвергнуть всю технологическую структуру. Вот на чем он заостряет внимание:
• Теперь функции – это крупные компании.
• Сегодня не осталось соборов – только базары.
• Сегодня приложения – это инфраструктура.
• Ключевой аспект – проектирование, инициированное разработчиками.
• Монолитов больше не осталось, теперь все реализовано в виде микросервисов.
• Если в вашей организации принята каскадная модель разработки – это прискорбный факт.
• Когда разработчики сами отвечают за проектирование продукта, он получается гораздо более гибким и интересным[17].
Банки должны взять эти тезисы на заметку и учиться на них, ведь у многих из них, с кем я имею дело, система контроля выстроена по принципу «сверху вниз». Идея распределить контроль между разработчиками там будет воспринята как ересь. Но все-таки именно это нужно сделать.
IT-директор будущего – это не IT-директор
Как я уже говорил, задача IT-директора – перейти от управления империей инженеров техподдержки к созданию распределенной организации разработчиков. Смена роли связана с переходом от иерархической структуры, все элементы которой разрабатывались компанией под свои нужды, к организации, ориентированной наружу, более «плоской», открытой и широкой. Большинство разработок будет поступать извне, поскольку они не предназначены исключительно для внутреннего использования и не создаются такими. Если банки перенесут свои сервисы на платформы и станут действовать на открытых рынках, они, как никогда, плотно будут вовлечены в этот процесс, но старые добрые времена, когда бизнес-процессами можно было обладать, уйдут в прошлое.
Таким образом, IT-директор путем постепенных изменений должен превратить организацию из закрытой и замкнутой в опенсорсную и широкую. Банк превращается из собора в базар, из монолита в рынок. Такова роль двигателя перемен: создать новую компанию, работающую по принципу «банкинг – это платформа».
«Банкинг как платформа» – это весьма актуальный тренд, о котором я писал еще семь лет назад, и вот мы до него дожили. Это возможность свободно подключить и использовать все банковские функции, которые будут работать как приложения через API. Речь не только о внутренних приложениях и API, но и о сторонних. Это новый принцип работы, где банк встраивается в экосистему технологических компонентов. Напоминаю: банк руководит этими компонентами, поскольку остается ведущим игроком на рынке, обладает миллионами клиентов, миллиардными активами и лицензией регулятора. Но дни, когда банк был полностью замкнутой на себя, закрытой структурой, сам себе закон, – в прошлом.
Сегодня банк – это интегратор компонентов в новом рыночном окружении, где банкинг – это сервис или платформа. Как только IT-директор завершит эту работу, его роль снова изменится. Он превратится в дирижера. Руководитель организации, развертывающей банкинг как платформу, должен отслеживать все группы от бэк-офиса (ударные) до миддл-офиса (духовые) и фронт-офиса (струнные), координировать их работу, чтобы они играли слаженно, в едином темпе.
Эта роль непростая, поскольку некоторые элементы новой банковской платформы «взяты из другого оркестра». Времени на репетиции почти нет, а оркестр должен играть круглосуточно, без выходных. Вот почему столь важно, чтобы дирижер позволял оркестру, управляемому разработчиками, самостоятельно распределять партитуру. У каждого музыканта в оркестре свое место. Кто-то может сфальшивить, но в общем музыкальном рисунке этим можно будет пренебречь.
Думаю, это последний элемент в описанной долгосрочной мозаике. Я давно слышу, что организационные структуры должны переходить от иерархического армейского устройства по принципу «команда/управление» к более ровному, семейному («наставничество/советы»). Банки противились таким переменам, ведь они привыкли командовать и контролировать. Однако технологии неотвратимо развиваются в направлении распределенных открытых платформ и рынков, монолитной иерархической структуре отмерен короткий век.
Иными словами, банки могут сохранять принцип «команда/управление» на физическом уровне (в отделениях), но отделения – лишь часть в постоянно растущем семействе цифровых структур. Возможно, их правомерно сравнить со старейшим членом семьи, скажем с отцом семейства, но необходимо дать себя проявить и другим членам семьи, признав, что диктат старших в прошлом. Именно поэтому должность дирижера, пожалуй, может стать важнейшей в банке будущего. Возможно, у него в подчинении не будет людей, не будет организации, и не будет рычагов управления, и вся его функция будет заключаться в создании прекрасной цифровой музыки. Я только за.
Глава 4. Восстание машин
Если вам не довелось послушать речь Энди Халдейна, главного экономиста и исполнительного директора по монетарному анализу и статистике Банка Англии – то вот его главная мысль: в ближайшие несколько десятилетий людей заменят роботы. Халдейна цитировали все ведущие издания прежде всего потому, что в своих прогнозах он основывался на исследованиях, проведенных Банком Англии. Согласно им, большинство менеджеров, клерков и рабочих лишатся работы: на смену им придут роботы. В Великобритании станет на 15 млн безработных больше, а в США – на 80 млн. Вероятность полного исчезновения бухгалтеров – 95 %, а парикмахеров – всего 33 %. Под угрозой все профессии – даже творческие, связанные с дизайном, искусством и музыкой.
В 2011 году редакторы одного из старейших американских литературных журналов
Стихотворение ничем не примечательно, кроме одного: написал его компьютерный алгоритм, и никто об этом не догадался. Создатель алгоритма Закари Шолл не стал сообщать редакторам, что поэт – на самом деле машина, потому что «никого не хотел шокировать».
Когда будет пройден тест Тьюринга?
Задача теста Тьюринга, разработанного в 1950 году Аланом Тьюрингом, – проверить, сможет ли машина продемонстрировать интеллект, эквивалентный человеческому или неотличимый от него. Многие считают, что в 2014 году чат-бот Женя Густман успешно прошел тест Тьюринга, но это неверно: скорее он обманул судей при помощи целого ряда уловок. Итак, когда же мы пройдем тест Тьюринга? На этот вопрос ответила
В среднем мозг человека содержит около 100 млрд нейронов. С каждым нейроном могут быть связаны до 10 000 других нейронов. Таким образом, количество синапсов (связей) между двумя нервными клетками может составлять от 100 до 1000 триллионов. Google и другие компании стремятся воспроизвести такую сеть при помощи компьютеров. Это исключительно сложная задача, и до создания нейронной сети с триллионами связей еще очень далеко. В прошлом десятилетии Google активно работала над искусственным интеллектом, достигнув важной вехи в 2012 году, когда появилась возможность распознавать изображения кошек.
Допустим, вы хотите написать программу, распознающую изображения котиков, на базе старой символической модели искусственного интеллекта. Несколько дней уйдет на то, чтобы загрузить в машину исчерпывающие и подробные описания котика: четыре лапы, острые ушки, есть усы, хвост и т. д. Вся эта информация будет сохранена в специальной ячейке памяти, именуемой CAT. Далее начинаем показывать картинки. Сначала машина должна вычленить отдельные элементы изображения, затем применить к ним правила, сохраненные в памяти. Если (лапы=4) и если (уши=остроконечные), а также если (усы=есть) и (хвост=есть), если (выражение=надменное), то (кот=да). Но что если показать такой программе шотландскую вислоухую кошку – умилительное животное с генетической особенностью, из-за которой уши всегда висят как лопушки? Наш символический искусственный интеллект дойдет до этапа «уши=остроконечные», проверит этот признак и авторитетно заявит: «Не кошка». Программа воспринимает информацию буквально – даже двухлетний малыш проявил бы больше сообразительности.
Поделиться книгой: