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

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

Организация взаимодействия

Заставить разнородные системы прозрачно взаимодействовать между собой достаточно сложно. Допустим, мы «научили» одну систему работать с другой, добавив в неё некоторый объем кода, обеспечивающего транспортные функции: подготовить данные для отправки, подготовить сообщение, передать в другую систему, дождаться ответа, принять сообщение от другой системы и провести следующую бизнес-операцию. А что делать при появлении новой системы? Например, банк связал процессинговую систему, обслуживающую операции с пластиковыми картами, с бэк-офисом, решающим учетные задачи. Однако, если банк захочет выпускать кредитные карточки, необходим будет и кредитный модуль, рассчитывающий проценты по этим карточкам, который будет необходимо увязать с существующими системами. Таким образом, сложность сопровождения комплекса ИТ-систем, набор кода, не относящегося к их бизнес-задачам, а обеспечивающим транспортные функции, с усложнением ИТ-ландшафта растет катастрофически. Поэтому значительная часть западной индустрии ИТ-услуг в 90-ые годы прошлого века занималась интеграцией систем, получая за решение этой задачи основную долю средств. За рубежом давно осознали необходимость внедрения специальных интеграционных платформ, решающих несколько задач: во-первых, прозрачная организация бизнес-процесса, связанного с взаимодействием различных ИТ-систем, во-вторых, избежание необходимости попарного связывания информационных систем, в-третьих, вынос транспортной логики из бизнес-приложения в интеграционную систему.

Стимулы внедрения

Однако принять решение о необходимости внедрения платформы для интеграции бизнес-приложений банку достаточно сложно. Дело в том, что деятельность любого универсального банка разбита на множество бизнес-направлений: корпоративное кредитование, кредитование частных лиц, карты, вклады и т.д. В каждом из этих бизнесов существуют задачи, связанные с прохождением бизнес-процесса через несколько ИТ-систем, которые оптимально решать с использованием интеграционной платформы. Однако каждая из этих задач в отдельности невелика по масштабам, и её решение не сможет вернуть инвестиции в приобретение и внедрение ПО данного класса. Таким образом, для того, чтобы развертывание интеграционной платформы стало выгодно банку в целом, необходима некая критическая масса задач, основанных на потребностях различных бизнес-заказчиков — бизнес-направлений банка. С другой стороны, у банковских ИТ-специалистов должно сложиться видение такого проекта как единой стратегии к интеграции всех ИТ-систем банка. В нашей практике стимулы, подталкивающие банк к внедрению интеграционной платформы, связаны, в основном, с тремя задачами. Первая — решение задачи он-лайн связи нескольких систем, когда для автоматизации бизнес-процесса используется несколько ИТ-систем — кросс-системный бизнес-процесс. Традиционно эта задача решается посредством файлового обмена, однако с ростом масштабов возрастают риски потери информации и ненадежность работы. Файловый обмен данными не масштабируем, непрозрачен, и его текущее состояние сложно отследить. Второй стимул — организация в банке Хранилища данных. Доставку данных в ХД из разнородных ИТ-систем как в он-лайн, так и в офф-лайн режиме лучше поручить транспортному ПО, гарантирующему их доставку. Третий фактор, стимулирующий внедрение интеграционной платформы внедрение новой системы, которую необходимо вписать в существующий ИТ-ландшафт. Допустим, банк начинает заниматься розничным кредитованием. Для этого ему необходимо внедрить фронт-офис, скоринг и CRM-решение. И все это должно взаимодействовать с тремя существующими транзакционными системами: процессингом, кредитным блоком и ядром АБС. Аналогичная задача возникает при необходимости замены какой-либо существующей системы, не справляющейся с возросшими объемами. Как сделать это безболезненно, не остановив работу банка? Только путем постепенного «разрезания» существующих связей и перевода их на сервис-ориентированную архитектуру, перевода текущей системы на работу через четко описанные сервисы посредством интеграционного ПО. Тем самым мы поймем, как заменяемая система связана с другими, и затем этим знанием, реализованным в интерфейсах, начнет пользоваться новая система.

Выбор интеграционного ПО

Для успеха ИТ-проекта важны три фактора: осознание и понимание бизнес-задачи, выбор продукта и создание успешной команды проекта. Таким образом, значимость выбора ПО достаточно высока. «Неофлекс» — мультивендорная компания, и наши сотрудники обладают экспертизой в области интеграционных платформ: IBM, BEA, Tipco, Oracle Fusion, SAP XI и других поставщиков. Однако основная наша ценность, как команды, способной успешно выполнять интеграционные проекты,  это наличие экспертизы в банковской сфере, понимания работы банка, взаимосвязи и архитектуры его ИТ-систем, и конечно хорошее знание инструмента и его возможностей. Таким образом, если у клиента существует ориентация на какого-либо поставщика ПО, например, SAP, Oracle, Microsoft или IBM, это хорошо, так как упрощается интеграция. С другой стороны, если клиент хочет выбрать оптимальное для себя решение, мы готовы ему в этом помочь. Основными требованиями клиента по выбору интеграционной платформы являются надежность и производительность работы, наличие инструментария для самостоятельной настройки бизнес-процессов, а так же набор стандартных компонент в составе платформы  для развития интеграционного решения. Среди таких компонент интеграционной платформы, можно перечислить средства моделирования бизнес-процессов, встроенную среду разработки интеграционного решения, готовые интерфейсы к распространенным транзакционным системам, средства мониторинга бизнес-процессов, средства поддержки версионности бизнес-процессов, информационный портал, позволяющий включать в бизнес-процесс операторов, принимающих решение на основании предоставленных им данных. Важным фактором интеграционной платформы является технология, на которой она разработана, а так же открытость и распространенность стандартов данной технологии.

Проект в Ханты-мансийском банке

Выбор IBM WebSphere в качестве средства интеграции сотрудники ИТ-департамента банка осуществляли совместно с нами после анализа различных решений, предлагаемых на рынке. Анализ проводился как путем контакта с вендорами, так и с помощью оценки уже внедренных проектов в крупных отечественных компаниях и банках. В целом выбор платформы занял около четырех месяцев, но в результате специалисты банка убедились в способности платформы решить не только текущие, но и перспективные задачи в области интеграции приложений. Изначально внедрение интеграционного ПО планировалось для реализации гарантированного сбора информации из всех транзакционных систем головного офиса и филиалов банка в разрабатываемое Хранилище данных. Однако первым завершенным проектом, показавшим бизнесу необходимость средства интеграции приложений, стала автоматизация погашения кредитов через сеть банкоматов. В этом бизнес-процессе задействованы сразу несколько ИТ-систем. Транзакция по погашению кредита начинается в банкомате после авторизации карты клиента и выбора им соответствующего пункта экранного меню, как при оплате за мобильный телефон. Затем транзакция через систему, обслуживающую карточный процессинг, должна маршрутизироваться в тот филиал, в котором клиент получил кредит, чтобы запросить суммы его остатка и начислений по нему. Основная сложность на этом этапе состоит в том, что головной офис и 16 филиалов банка расположены в разных регионах России от Санкт-Петербурга до Новосибирска и учитывают кредиты в различных ИТ-системах. Далее транзакцию вместе с суммой платежа необходимо вернуть в банкомат, и после получения подтверждения клиента отразить погашение кредита в учете и распечатать клиенту соответствующие документы. Попарная интеграция ИТ-систем, используемых в этом бизнес-процессе, изначально представлялась ИТ-специалистам банка нереальной, поэтому было принято решение выполнить эту задачу, используя интеграционное ПО. В банке хорошо развита инфраструктура каналов связи между филиалами и головным офисом, однако для повышения надежности он-лайн интеграции приложений при проектировании решения нами была заложена возможность гарантированной доставки сообщений. Это было сделано путем установки в филиалах банка серверов поддержки очередей сообщений IBM WebSphere MQ, а в головном офисе — приложения IBM WebSphere Enterprise Service Base, в котором реализована логика бизнес-процессов. Таким образом, банк получил единый диспетчерский пункт гарантированной доставки сообщений, способный выполнять задачи он-лайн и офф-лайн интеграции всех ИТ-систем, работающих во всех филиалах банка. Работа над проектом «Погашение кредита с использованием сети банкоматов» была полезна специалистам банка не только в плане обкатки новой технологии, но и для взгляда со стороны на существующие в банке бизнес-процессы выдачи, обслуживания и погашения кредитов. Часть из них была перестроена, и к поддерживающим их ИТ-системам был организован доступ через IBM WebSphere, синхронный либо асинхронный в зависимости от необходимости. В целом решение этой, казалось бы, небольшой задачи оказалось весьма нетривиальным. Несмотря на это, нам удалось уложиться в бюджет проекта, и в сроки, отпущенные на его реализацию. Основным двигателем проекта в банке стал Департамент информационных технологий. Помимо его представителей, в рабочую группу проекта входили аналитик и архитектор решения с нашей стороны, а также представители заинтересованных бизнес-подразделений банка. Подготовительный этап проекта с выбором интеграционной платформы и разработкой технического задания, занял около 4 — 5 месяцев, зато сам проект был внедрен в кратчайшие сроки — чуть больше, чем один месяц (пять недель). Проект завершился демонстрацией работы внедренной технологии — руководитель ИТ-департамента банка с использованием собственной карточки погасил через банкомат кредит в региональном филиале, и получил распечатанный банкоматом чек, а все системы банка и филиалов сгенерировали необходимые проводки. Успешная реализация проекта породила масштабные планы по дальнейшему использованию интеграционной платформы в банке. Мы надеемся, на долгосрочное и взаимовыгодное партнерство, и что часть этих планов удастся воплотить в жизнь уже в текущем году.

Аналитический Банковский Журнал, №2, 2007


Источник: Аналитический банковский журнал


Поделиться

Вернуться к списку публикаций