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

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

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

Бухгалтерская зависимость

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

«Первой серьезной утратой, понесенной программистами новой формации при миграции обкатанных технологий государственных банков на платформе Wintel, был неумышленный отказ от так называемой технологии упреждающего расчета процентных чисел, – считает Виктор Галактионов, главный системный архитектор АКБ «РосЕвроБанк».

Новая формация Wintel-программистов, сделав в конце 90-х, по сути, шаг назад в автоматизации банковской деятельности, теперь недоумевает: почему раньше АБС всего шести государственных банков справлялись с обработкой потока информации с пространства всего СССР, а нынешние АБС тысяч банков постоянно «тормозят» и в результате закрытие месяца, а уж тем более квартала, давно превратилось в сущий ад? Но вместо того чтобы признать сделанные более десяти лет назад ошибки и их исправить, оправдываются тем, что, дескать, за десять лет неимоверно выросли объемы обрабатываемой информации и от этого никуда не деться.

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

«Но вот что интересно: по мере насыщения рынка ПК, снижения их стоимости, постепенного вытеснения бумажных технологий с уровней мидл- и бэк-офиса, а затем и фронт-офиса в бизнес-процессы банков проникали не новые ИТ-решения, а адаптированные прежние – в первую очередь дебет-кредит банковского бухгалтерского учета. Не было бэк-офисного регистрового учета, программисты успешно подменяли его бухгалтерским учетом. Настоящие банковские технологи еще не выросли, поэтому все сотрудники – от операциониста до председателя правления банка – с подачи автоматизаторов мыслили в терминах бухгалтерского учета. Другого автоматизаторы тогда предложить не могли, – вспоминает Галактионов. – Тем временем, программисты (не те, кто отвечал за банковские технологии) продолжали развивать автоматизацию также с позиций бухгалтерского учета. Определить момент, когда настала пора отделить регистровый учет операций (сделок) клиентов по договорам, а не проводок по бухгалтерским счетам, и реализовать его в отдельных системах автоматизации бэк-офисных операций, автоматизаторам с программистским сладом ума было непросто. Момент был упущен – автоматизация бэк-офисных операций пошла по пути, уже проторенному в ходе автоматизации бухгалтерского учета. На рабочих местах кредитных сотрудников появился, по сути, тот же операционный день с теми же 20-значными лицевыми счетам. Позднее эти счета «докатились» и до банковских фронт-офисов».

Последствия сложившихся архитектур

Поскольку бухгалтерским учетом оказались пронизаны все уровни российских АБС вплоть до фронт-офиса, то всякое изменение плана счетов или правил ведения бухгалтерского учета приводит к глобальным пересмотру функционала АБС – от фронт-офиса до систем отчетности и хранилища данных. Подобные изменения были вызваны Положением № 302-П Банка России от 26 марта 2007 года , которое вступило в силу с 1 января 2008 года. Основные требования этого положения касались изменения бухгалтерского учета, то есть должен был быть затронут только нижний уровень ядра – главной бухгалтерской книги. В результате практически все российские банки оказались в крайне непростой ситуации и были вынуждены адаптировать свои АБС под требования ЦБ РФ, начиная зачастую с фронт-офиса и заканчивая хранилищами и системами отчетности.

По мнению Вадима Пахомова, начальника управления ИТ Русского международного банка, на Положении 302-П дело не остановится, появятся новые распоряжения ЦБ РФ, их реализация еще не раз потребует большой и напряженной работы, поскольку речь не идет об изменениях в каком-то одном банковском приложении – по сути, меняется целое направлении банковской работы, не только учет, но и подход к рынку в целом.

Галактионов расценивает сложившуюся ситуацию как близкую к кризисной. «Некоторые дальновидные банки, как правило крупные, те, что могут позволить серьезные инвестиции в перспективные ИТ, пытаются выходить из этой ситуации, разделяя бэк-офис и бухгалтерский учет. Часто это ограничивается полумерой – в качестве ядра регистрового учета ставится та же самая АБС (а иногда по непонятным причинам и другая), на которой ведется бэк-офисный учет, например, розничных операций, поэтому говорить о правильном построении сервис-ориентированной архитектуры можно только условно».

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

«Насколько я знаю, некоторые разработчики ведут активные работы: они пытаются менять функционал своих систем, вплоть до замены ядра. Но пока все эти заявления носят скорее декларативный характер. Например, программные продукты для обслуживания розничного рынка, предлагаемые сейчас, – это просто системы корпоративного обслуживания, в которых реализованы типичные операции розничного рынка. АБС в силу инертности их разработчиков остаются трудно адаптируемыми к изменениям и модификациям. Необходима полная ломка и замена этих систем», – считает Пахомов.

Пути решения проблемы

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

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

На ранних этапах расчет скорингового балла осуществлялся в рамках АБС. Сейчас разумнее, например, те же скоринговые расчеты реализовать в виде отдельного ИТ-сервиса на отдельной аппаратной платформы. В этом случае замена программного или аппаратного обеспечения будет проходить гораздо проще. «Выделение подобных сервисов и вынос их на отдельные платформы дает не только свободу для быстрой модернизации, но и позволяет легко масштабировать сервисы, гибко повышая их производительность на узких сегментах бизнес-процессов, – отмечает Галактионов. – Когда время, необходимое монолитной АБС для закрытия месяца или квартала, превышает все возможные и невозможные пределы, пользователь такой АБС (то есть банк) вынужден покупать очередной мэйнфрейм только для того, чтобы уложить в допустимые пределы всего- навсего один элемент бизнес-процессов, который выполняется раз в месяц или квартал. В случае же выделения данного сервиса с возможностью его масштабирования можно бы за меньшие деньги купить более «скромные» машины или даже выделять необходимые мощности на тех, что обслуживают другие бизнес-процессы, на короткий промежуток времени раз в месяц или квартал. Тяжелая, ресурсоемкая процедура закрытия отчетного периода выполняется обычно раз в месяц или квартал и используется в течение нескольких часов со стопроцентной загрузкой оборудования. В остальное время приобретенные мощности нужны в лучшем случае лишь на 10—15%. Проблема может решаться путем привлечения на критичные периоды мощностей других сервисов, менее критичных для бизнеса, которые можно остановить, отложить или перераспределить. Думается, что задача гибкого управления мощностями абсолютно реальная, хотя она большая, трудоемкая и ресурсоемкая и за нее страшно браться. Но ею надо заниматься, если мы смотрим вперед».

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

Кроме того, закупать оборудование для отдельного выделенного сервиса может оказаться дешевле, чем для всей монолитной системы. «В моей практике был случай, когда предстояло нарастить производительность сервера приложений, поддерживающего работу фронт-офисных приложений. Если бы я предпочел монолитное решение, то не справляющийся с нагрузкой сервер за 100 тысяч пришлось бы заменить на другой за 200 тысяч. Однако система была построена таким образом, что для масштабирования сервера приложений достаточно было взять ПК сотрудника, находящегося в отпуске, установить на него ПО с сервера, поддерживающего фронт-офисные приложения, и поставить этот ПК в пул серверов. Операция масштабирования занимала не более одного часа и давала запас производительности, достаточный для работы дополнительных 150–200 пользователей. Если бы это было монолитное решение, то пришлось бы выложить несколько сотен тысяч долларов, – уверен Галактионов. – Часто проблема носит не только финансовый характер. Поставщикам нецелесообразно держать на складах необходимое дорогостоящее оборудование, поэтому сроки его поставки часто составляют несколько недель, а то и месяцев. Возможность выделять сервисы и масштабировать их позволяет эффективно и оперативно управлять совокупной производительностью информационных систем банка».

Ситуация осложняется тем, что банковское ИТ-сообщество находится в неведении относительно дальнейших действий ЦБ РФ на пути реформирования финансового рынка России. При отсутствии перспективной программы ЦБ РФ постоянное непонимание направления развития банковского регулирования вынуждает ИТ-сообщество оставаться в состоянии догоняющих бизнес. Недопонимание ситуации приводит к конфликтам на самых разных уровнях – от линейных менеджеров до руководства банка, при этом ИТ-департаменты и их руководители легко могут оказаться в состоянии «крайних». Все это говорит о том, что к теме модернизации банковских ИТ-архитектур предстоит еще не раз вернуться.

«Выделение узкофункциональных ИТ-сервисов и вынос их на отдельные платформы дает не только свободу для быстрой модернизации банковских систем, но и позволяет легко масштабировать сервисы, гибко повышая их производительность на узких сегментах бизнес-процессов, Виктор Галактионов, главный системный архитектор АКБ «РосЕвроБанк»

 

«АБС в силу инертности их разработчиков остаются трудно адаптируемыми к изменениям и модификациям. Необходима полная ломка и замена этих систем», Вадим Пахомов, начальник управления ИТ Русского международного банка