Все о системах управления бизнес-процессами
 
Почитать
Поговорить
Побродить
Завершить


 
Перспективы использования технологий SOA и BPM при автоматизации расчетных операций банков

Литература:

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

Проблемы интеграции и адаптации информационной системы банка

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

Такое положение вещей обусловлено рядом причин, среди которых можно выделить:

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

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

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

Как правило, на этапе становления, банк ограничивается покупкой некоторой АБС стороннего производителя (ограничиваясь базовым набором модулей), а также установкой программ для обеспечения расчетов по корреспондентским счетам и выполнения требований регулирующих органов.

По мере развития банка, идет наращивание функционала за счет установки дополнительных модулей АБС, покупки иного программного обеспечения и разработки программного обеспечения своими силами. В дополнение к АБС банки, как правило, устанавливают аналитическую систему, систему «Клиент-Банк», CRM-систему (Customer relationship management – управление взаимоотношениями с клиентами), систему управления знаниями и т.д. В последнее время появилась тенденция устанавливать еще и ERP-систему (Enterprise Resource Planning – планирование ресурсов предприятия).

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

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

Другой источник дефрагментации связан с постоянной работой банков по улучшению своих бизнес-процессов. В результате, банки вынуждены отклоняться от референтных моделей бизнес-процессов, жестко запрограммированных в АБС, CRM, ERP и т.д., что требует разработки разработки/приобретения дополнительных модулей для автоматизации перепроектированных бизнес-процессов.

В связи с неоднородностью информационной системы, появляется достаточно много проблем, требующих постоянного отслеживания и решения: проблемы сопровождения сложной IT-инфраструктуры, проблемы управления конфигурацией, проблемы обучения и переобучения кадров и т.д. Но главной проблемой является экспорт/импорт данных между различными единицами программного обеспечения, который далеко не всегда осуществляется в автоматическом режиме. Учитывая, что в случае наличия N единиц программного обеспечения необходимо обслуживать, как правило, N-1 связей (стыковка всех систем с АБС), актуальность данной проблемы растет одновременно с развитием информационной системы2.

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

Как упоминалось выше, несмотря на дефрагментацию, неоднородная информационная система не обеспечивает необходимую гибкость для целей непрерывного совершенствования или реинжиниринга бизнес-процессов. Операции в рамках АБС, CRM, ERP и т.д. характеризуются «жесткими» связями, заданными референтными моделями бизнес-процессов3 и используемыми системами управления данными (как правило, на основе реляционных баз данных)4.

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

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

Потребность в интеграция и адаптации при автоматизации расчетов и операционной работы банка

В наибольшей степени изложенная выше проблематика характерна для автоматизации расчетов и операционной работы банка.

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

а) автоматизированная банковская система (АБС), в рамках которой осуществляется основной комплекс операций по открытию и ведению счетов клиентов, в том числе, осуществлению безналичных расчетов и кассовых операций, начислению процентов, покупки и продажи валюты и т.д.;

б) программное обеспечение для управления корреспондентскими счетами НОСТРО (как минимум, включающее программное обеспечение Банка России для осуществления расчетов по корреспондентскому счету банка в РКЦ или ОПЕРУ Банка России);

в) другое программное обеспечение, обеспечивающее функционал, не вошедший в АБС (системы «Клиент-Банк», «Интернет-бэнкинг», on-line расчеты по ЛОРО-счетам и т.д.);

г) программное обеспечение класса ERP для обслуживания расчетных операций различных подразделений банка в рамках функционирования банка как юридического лица;

д) программное обеспечение класса CRM для поддержки выполнения расчетных операций клиентов за счет получения дополнительной информации о клиенте и о его взаимодействии с банком;

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

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

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

б) «жесткие» связи между компонентами программного обеспечения и «жесткая» структура используемых данных препятствует изменению функциональности информационной системы на уровне бизнес-процессов. Как результат, внесение любых изменений в технологию расчетных операций (например, в связи с изменением нормативной базы Банка России) будет сопряжено со значительными трудностями;

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

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

Однако, в связи с появлением технологий SOA (Service-Oriented Architecture) и BPM5 (Business Process Management6), ситуация стала более обнадеживающая. И опыт первопроходцев7 показывает, что данные технологии имеют большие перспективы в банковском секторе России.

Интеграция на основе технологии SOA

В наиболее общем виде, сервис-ориентированная архитектура8 (СОА или SOA) не является архитектурой в буквальном смысле этого слова (то есть, не является метаязыком для описания структуры информационной системы9), а определяется как «модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами»10.

Так как любой сервис подразумевает наличие провайдера и потребителя сервиса, схематично концепцию SOA можно представить в виде схемы (Рис.1), включающей:

а) провайдера сервиса, который публикует информацию о сервисе в каталоге сервисов и реализует сервис при соединении с потребителем;

б) потребителя сервиса, который осуществляет поиск необходимого сервиса в каталоге сервисов и обращается за реализацией сервиса к провайдеру;

в) каталога сервисов, в котором хранится информация о сервисах, опубликованная провайдерами;

г) непосредственно самого сервиса (точнее набора сервисов), информация о котором хранится в каталоге сервисов и который провайдер реализует по запросу потребителя.

Рис. 1. Обобщенная схема SOA

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

Процитируем несколько определений SOA, которые можно найти в литературе [1]:

а) SOA – «IT-архитектура в масштабе предприятия, которая обеспечивает слабые связи, многократное использование и взаимодействие между системами»;

б) SOA – «архитектура приложений, в которой все функции и службы определены при помощи языка описаний и имеют интерфейсы вызова, обращение к которым осуществляется при выполнении бизнес-процессов. Каждое взаимодействие является независимым от всех прочих взаимодействий и внутренних протоколов, обеспечивающих соединение устройств. Поскольку интерфейсы независимы от платформы, клиент может использовать службу, применяя любое устройство, используя любую операционную систему и любой язык»;

в) SOA – «системная архитектура, в которой функции приложения создаются в форме компонентов (служб), которые имеют слабые связи и четко определены с целью совместимости, повышения гибкости и возможности многократного использования»;

г) «SOA – это синоним таких архитектурных решений, которые используют технологии Web-служб, такие, как SOAP11, WSDL12 и UDDI13»;

д) «Сервис-ориентированная архитектура – это каркас для интеграции бизнес-процессов и поддерживающей их IT-инфраструктуры в форме безопасных, стандартизованных компонентов – служб, – которые могут использоваться многократно и комбинироваться для адаптации к изменению приоритетов в бизнесе» [1].

Естественно, добавление каждого нового требования или соглашения сужает содержание SOA. Например, добавление соглашения об использовании только сервисов, созданных на основе Web-сервисов, исключает из рассмотрения SOA, сервисы которых реализованы на основе других технологий.

Отметим два важных элемента SOA, которые отмечают большинство авторов:

а) слабая связанность сервисов, которая позволяет использовать сервисы независимо друг от друга. При этом детали реализации сервиса скрыты от потребителя и могут изменяться провайдером без каких-либо последствий для потребителя (при условии сохранения неизменным интерфейса сервиса);

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

Интеграционные возможности SOA непосредственно следуют из общей схемы, приведенной выше. Как известно, значение термина «интеграция» включает два аспекта:

а) объединение каких-либо элементов (частей) в целое;

б) процесс взаимного сближения и образования взаимосвязей.

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

Конкретные реализации SOA могут использовать различные варианты программного обеспечения среднего уровня14 (middleware): MOM (Message Oriented Middleware), интеграционные брокеры, серверы приложений и др.

В настоящее время, наиболее перспективным решением, по-видимому, является решение на основе ESB (Enterprise Service Bus) – сервисной шины предприятия: появившись позже вышеперечисленных технологий, в нем были учтены многие ошибки и использованы многие перспективные элементы предыдущих технологий интеграции.

Реализация SOA на основе ESB

В общем виде «сервисная шина предприятия – это основанная на стандартах интеграционная платформа, объединяющая обмен сообщениями, Web-сервисы, преобразование данных и интеллектуальную маршрутизацию» [2].

Данное определение необходимо дополнить такими отличительными чертами ESB, как:

а) слабая связанность сервисов (что обеспечивает гибкость автоматизации бизнес-процессов и создает условия для внедрения BPM-систем);

б) существенно распределенная сеть15 (что облегчает наращивание интегрированного кластера, в том числе, обеспечивая постепенную интеграции распределенной IT-структуры).

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

Обеспечение связанности указанных приложений в рамках ESB достигается путем использования подходящих протоколов, унаследованной среды обмена сообщениями, адаптеров приложений и т.д. (при интеграции старых приложений в рамках SOA обычно говорят об «обертывании» - wrapping – приложений в Web-сервисы16).

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

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

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

Рис. 2. Схема ИС до внедрения ESB

Как правило, приведенная схема интеграции реализуется с помощью методов извлечения, преобразования и загрузки ETL (Extract, Transform and Load) и ночной пакетной обработки данных, что является источником стандартных проблем автоматизации расчетных операций, перечисленных выше.

В случае внедрения ESB (Рис.3), схема ИС существенно изменится. Все приложения через адаптеры будут соединены с локальными участками ESB, которые в свою очередь, будут соединены между собой защищенными соединениями, основанными на надежном обмене сообщениями.

Рис. 3. Схема ИС после внедрения ESB

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

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

Адаптация к изменениям на основе технологии BPM

Так как неотъемлемой особенностью SOA (в частности, ESB) является слабая связанность сервисов и возможность практически неограниченного наращивания количества сервисов (в том числе, сложных сервисов, использующих другие сервисы как компоненты), появляется возможность достаточно просто осуществлять автоматизацию перепроектированных бизнес-процессов.

Полноценная возможность использования SOA для целей адаптации и совершенствования бизнес-процессов появилась в результате развития BPM-технологий и создания так называемых BPM-систем или BPMS.

Современная BPMS как минимум должна включать пять компонент:

а) компоненту, обеспечивающую проектирование бизнес-процессов (BPD или Business Process Design);

б) компоненту, обеспечивающую исполнение бизнес-процессов (BPE или Business Process Engine);

в) компоненту, обеспечивающую мониторинг и контроль бизнес-деятельности (BAM или Business Activity Monitoring);

г) полноценную сервисную шину предприятия ESB;

д) пользовательский интерфейс.

Кроме того, в BPMS могут включаться такие компоненты, как:

а) репозиторий метаданных;

б) поддержка сложных бизнес-правил;

в) управление версиями документов, присоединяемых к экземплярам бизнес-процессов;

г) компонента бизнес-анализа BI (Business Intelligence), необходимая для анализа информации, поступающей из BAM и т.д.

Потенциально, BPMS может обеспечивать [3]:

а) более полное вовлечение бизнеса в разработку решений по автоматизации бизнес-процессов;

б) более плотную интеграцию людей и систем, которые вовлечены в осуществление бизнес-процессов;

в) моделирование бизнес-процессов с целью разработки наиболее оптимальных для внедрения процессов;

г) мониторинг, контроль и совершенствование бизнес-процессов в реальном времени;

д) внесение в реальном времени изменений в текущие бизнес-процессы.

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

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

В настоящее время рынок BPMS активно развивается и растет, причем лидерами рынка «чистых» BPMS по данным Gartner являются относительно небольшие компании, такие, как Pegasystems, Savvion, Lombardi, Tibco, Metastorm и Global 360.

Однако уже сейчас наметилось движение рынка в сторону платформ бизнес-процессов BPP (Business Process Platform)17, которые фактически представляют собой связку SOA и BPMS. А здесь уже основными игроками являются SAP (NetWeaver Platform), IBM (IBM WebSphere Platform) и Oracle (WebLogic Application Server Platform)18.

Литература

[1] Норберт Биберштейн, Синджей Боуз, Марк Фиаммант, Кейт Джонс, Роун Ша. Компас в мире сервис-ориентированной архитектуры (SOA). М.: Кудиц-пресс, 2007.

[2] Дэвид А. Шаппел. ESB – сервисная шина предприятия. С-Пб.: БХВ-Петербург, 2008.

[3] James F. Chang. Business Process Management Systems. New York: Auerbach Publications, Taylor&Francis Group, 2006.

Примечания

1 При написании статьи использованы материалы лекции «Автоматизация бизнес-процессов», прочитанной автором в Банковском институте ГУ – ВШЭ в рамках курса «Управление бизнес-процессами в компании».

2 Максимальное количество связей, которые потенциально могут поддерживаться между N единицами ПО в режиме «каждый с каждым» будет N(N-1)/2.

3 Обычно АБС и ERP системы разрабатываются на основе некоторых референтных моделей бизнес-процессов, которые, в свою очередь, строятся на основе «лучших практик» (best practice). При этом современные АБС и ERP системы включают инструментарий, позволяющий изменять в определенных пределах встроенные референтные модели. Однако, при существенном изменении бизнес-процессов, гибкости инструментария для настройки моделей обычно не хватает.

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

5 Аббревиатура BPM может обозначать не только Business Process Management, но и Business Performance Management (управление эффективностью бизнеса), а также Business Process Modeling (моделирование бизнес-процессов). Конкретное значение аббревиатуры обычно ясно из контекста.

6 В данном случае, термин Business Process Management обозначает IT-технологию, что необходимо отличать от другого его значения – управления бизнес-процессами, как дисциплины менеджмента. При этом BPM как IT-технологию часто обозначают BPMS (Business Process Management System).

7 См. например: Дарья Тренина. Банки осваивают SOA. Neoflex, 08.05.2008, http://www.mskit.ru/news/n48706. Или Дмитрий Назипов, ВТБ: Нормально организованные процессы в банке важнее самых развитых ИТ. Intelligent Enterprise, №2 (178), 11 февраля 2008 года.

8 В настоящее время в литературе примерно одинаково часто можно встретить перевод SOA как «сервис-ориентированная архитектура», так и «сервисно-ориентированная архитектура».

9 Глеб Галкин. Архитектура как метаязык. Intelligent Enterprise, № 4 (180), 10 марта 2008 года.

10 Википедия, http://ru.wikipedia.org

11 Simple Object Access Protocol – протокол обмена структурированными сообщениями в распределённой вычислительной среде (первоначальное значение – простой протокол доступа к объектам).

12 Web Services Description Language – язык описания Web-сервисов, основанный на языке XML.

13 Universal Description Discovery & Integration — инструмент для расположения описаний Web-сервисов (WSDL) для последующего их поиска другими организациями и интеграции в свои системы.

14 Необходимо отметить, что некоторые решения на основе MOM, интеграционных брокеров и серверов приложений иногда относят не к SOA, а к EAI (Enterprise Application Integration).

15 Построение в виде распределенной сети отличает ESB от интеграционных брокеров, построенных в топологии типа «звезда».

16 Наталья Дубова. На пути к SOA. Открытые системы, 29.08.2005. www.osp.ru/cio/2005/08/379555.

17 Игорь Костылев. Смерть BPMS или о новой «зонтичной» концепции. Intelligent Enterprise, №4 (180), 10 марта 2008 года.

18 После поглощения компании BEA, в платформу Oracle включены компоненты платформы BEA WebLogic.

Комментарии
Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права