Банковское дело

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

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

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

В настоящее время проблему устаревших систем крупные банки решают в два этапа. На первом этапе происходит выделение функций.

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

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

Процесс разделения функций — это административная работа по решению того, что к чему относится. На рисунке 5.3 для простоты указаны четыре группы. К первой относится все, что связано с поставкой продуктов и услуг, ко второй — информация о клиентах. Третья группа представлена типовыми процессами вроде оценки кредитоспособности, ценообразования, разнесения проводок в главной бухгалтерской книге и прочие агностические и комплексные функции; четвертая — группа производственных процессов, концентрирующаяся лишь на эффективной обработке и не обремененная различными деталями, не имеющими отношения к продуктам. При таком подходе у банков появляются определенные возможности. Речь идет, например, о замене одного из компонентов решения, который впоследствии будет автоматически введен в действие по всему банку. Или о возможности добавления новых каналов, призванных естественным образом поддерживать все необходимые продукты (притом необходимость внедрения изменений в сами продукты уже отпадает). А можно применить методику ценообразования с учетом всех отношений клиента с банком.

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

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

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

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

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

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

Скажем прямо, большая часть компаний пытается идти по проторенной дороге, лишь кое-как сооружая новые, но до боли похожие на уже имеющиеся старые решения. И крупным банкам это уже начинает надоедать. Господам из компаний пора бы выработать новые конфигурации, в рамках которых будет обеспечено беспрепятственное развитие автоматически настраиваемых (plug and play) компонентов и которые принесут реальную пользу клиентам и освободят банки от груза наследия их систем. Как только банки завершат этап выделения функций и процессов, они смогут приступить ко второму — поиску тех компонентов, которые помогут улучшить их функциональные возможности.

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

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

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

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

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

Так что мы никоим образом не хотим расстраивать мистера Патт по поводу его закона, но, возможно, в информационных технологиях присутствует еще один тип людей — те, кто управляют и понимают то, чем управляют. Причина их немногочисленности заключается в сложности бега вприпрыжку по болоту устаревших систем. Многие предприимчивые бизнесмены способны и даже полны желания найти совершенно новое применение информационным технологиям — с некоторой помощью со стороны. Тем не менее, в существующей среде они постоянно сталкиваются с ограничениями вроде это сделать невозможно, это делать не нужно, это следует делать только так и не иначе. Первоочередное значение придается избеганию подводных рифов, а не достижению желаемого места назначения. Штурман важнее капитана корабля, знающего лишь, что не сможет попасть из точки А в точку В по прямой, не проделав пару дырок в своем корабле. Разумеется, если убрать рифы, значимость фигуры штурмана автоматически нивелируется — ведь тогда капитан сможет и сам без проблем доплыть, куда ему надо. Непрекращающийся спор, могут ли предприниматели управлять или этим должны заниматься IT-специалисты, переходит в критическую стадию. Мы полагаем, что намного целесообразнее именно предпринимателям взять на себя эту ответственность, и первым шагом станет устранение рифов устаревших систем, а те, кто знал местонахождение этих рифов, больше вовсе (!) не понадобятся. Лишь немногие, очень немногие из Т-штурманов достигнут звания капитана и смогут управлять бизнесом — те, кто приложит столь же много усилий к изучению банковского дела, сколько к изучению рифовых образований.

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

При традиционном подходе к лицензированию программ и приложений для розничного банковского сектора банки выплачивают лицензионный сбор и регулярные годовые платежи. Размер лицензионного сбора при таком методе, как правило, привязывается к размеру банка — будь то количество счетов, клиентов, размер активов или другой показатель; метод требует от банка крупных авансовых инвестиций и ежегодных издержек. В разных областях банкинга существуют и другие модели ценообразования, например, цена за место на фондовых рынках или цена за использование и/или цена подписки в других сферах. Поскольку прикладные программы превратились в предмет купли-продажи, а рыночные колебания оказывают значительное влияние на их ценность, банки все больше заинтересованы в разработке подвижной модели ценообразования, при которой затраты на лицензию будут соответствовать реальной полезности программыприложения. Им, без сомнения, хотелось бы избавиться от больших авансовых платежей за лицензию, особенно в связи с немалыми дополнительными авансовыми расходами по внедрению программ, что делает процесс замены программы двойной обузой. Кроме того, розничные банки хотели бы иметь гарантии того, что выбранный ими разработчик IT будет работать с полной самоотдачей над проектом и нести за него ответственность. Получение награды авансом (до успешного внедрения продукта) отнюдь этому не способствует. Не за горами новые интересные подходы к лицензированию, которые объединят банк и поставщика 7 в некий союз с равным распределением рисков и наград, в результате чего смогут выиграть обе стороны.

Метка: IT, Розничный банкинг