Во-первых, правильный выбор архитектуры построения вычислительно-коммуникационной сети и ориентация на профессиональные СУБД. По экспертным оценкам, собственные разработки АИС в 53 % случаев базируются на СУБД Oracle, приблизиельно в 15 % — на Informix, в 22 % — другие СУБД.
Во-вторых, использование при разработке современного инструментария (CASE средства, эффективные средства разработки: Delphi, Designer2000, Developer2000, SQL-Stations и т. п.).
В-третьих, мультизадачная инфраструктура разработки проекта, когда конкретный модуль АИС ведет группа разработчиков с взаимосвязанным перечнем задач, построенная на принципах полной взаимозаменяемости, т. е. функционирование данного модуля АИС и его развитие не связаны с одним конкретным разработчиком.
В-четвертых, применение эффективных организационно-технических средств по управлению проектом и контролю версий АИС.
Только при соблюдении этих основных положений можно рассчитывать, что собственная разработка окажется конкурентной и эффективной. В противном же случае можно столкнуться с эффектом «неоправданных ожиданий» — это в лучшем случае, а в крайнем случае — вообще задуматься о смене АИС. При этом смена АИС может как вызвать непосредственно смену клиентских модулей и табличной структуры БД, так и потребовать замену серверного и клиентского аппаратного и общесистемного программного обеспечения, включая СУБД, а это дело не дешевое. Поэтому очень важно при выборе варианта реализации АИС сразу решить вопрос о возможностях экспорта/импорта данных в создаваемой системе. При правильном решении данного вопроса смена АИС, если в ней все-таки возникнет необходимость, произойдет практически безболезненно для функциональных подразделений.
С развитием финансового и фондового рынков сфера деятельности КБ расширялась, возрос и объем перерабатываемой информации.
В новых условиях стал неизбежным переход к комплексной автоматизации банковской деятельности.
В силу различия банков по размерам, структуре, используемой методологии, т. е. по всем тем параметрам, которые в первую очередь характеризуют банк как объект приложения информационных технологий, расширился круг используемых ими АБС.
Поэтому в настоящее время в России выделяют пять поколений банковских систем.
Основные характеристики систем, относящихся к тому или иному поколению приведены в табл. 2.1.
Таблица 2.1
Поколения АБС
Поколение
|
Аппаратная платформа
|
СУБД
|
Базовый элемент технологии
|
Структура АБС
|
1
|
ПК MS DOS
|
Clipper, foxpro, Clarion
|
Бухгалтерская проводка
|
Автономные АРМ, не связанные обмен файлами через перенос на носителе
|
2
|
ПК MS DOS + локальная сеть под Novell Net Ware
|
Clipper, foxpro, Clarion
|
Бухгалтерская проводка
|
Автономные АРМ, связанные данными через файлы на сервере, не связанные по функциям
|
3
|
ПК MS DOS Widows + локальная сеть под Novell Net Ware (Windows NT)
|
Btrive
|
Бухгалтерская проводка + документ
|
Автономные АРМ, связанные данными через файлы на сервере, слабо связанные по функциям. Переходная технология «файл-сервер» «клиент-сервер»
|
4
|
ПК MS DOS Widows + локальная сеть Windows NT
|
Профессиональная реляционная СУБД (MS SQL Server, Oracle, System, DB2, informix)
|
Бухгалтерская проводка + документ + сделка
|
Автономные АРМ, сильно связанные данными через общую БД, связанные по функциям через общее ядро. Архитектура «клиент-сервер» или «хост-терминал»
|
5
|
ПК ms windows + распределенные сети с несколькими выделенными физическими серверами приложений, работающими под многозадачными многопользовательскими ОС
|
Профессиональные реляционные или постреляционные СУБД (MS SQL Server, Oracle, System11, DB2, informix) + менеджеры транзакций
|
Документ или сделка
|
Логические АРМЫ, сильно связанные по данным и функкциям. Архитектура трехуровневая «Application Server», сервер приложений
|
Как мы видим, первые поколения АБС были предназначены для решения задач автоматизации бухгалтерских операций, АБС второго и третьего поколений также реализовывали элементы автоматизированного документооборота, АБС четвертого поколения строились уже по классической схеме трехзвенной клиент-серверной архитектуры и имели модульную структуру, реализующую концепции работы многих пользователей с потоком документов (docflow). В этой концепции документ в электронном виде мог поступать на обработку последовательно нескольким пользователям, а система сама контролировала корректность переходов при обработке данного документа.
АБС пятого поколения являются информационными системами, реализующими полнофункциональную модель workflow-автоматизации бизнес-процессов.
Бизнес-процесс — устойчивый процесс (последовательность работ), соотнесенный с отдельным видом производственно-хозяйственной деятельности банка и обычно ориентированный на создание новой стоимости (например, бизнес-процесс выдачи кредита, бизнес-процесс приема вклада), иерархия взаимосвязанных функциональных
действий, реализующих одну (или несколько) из целей системы, например выпуск продукции или ресурсное обеспечение выпуска (под продукцией понимают предоставление услуг банка, т. е. выполнение основных банковских операций).
Термин WorkFlow соответствует организации некоторой общей среды работы с документами, объединяющей весь электронный документооборот компании, в нашем случае — банка.
На рис. 2.2. приведена звездообразная архитектура АБС, базирующаяся на общем ядре.
Рис. 2.2. Архитектура системы, базирующаяся на общем финансовом ядре.
Важно отметить, что на современном этапе развития банковского бизнеса, который характеризуется в том числе возросшими требованиями к информационно-технологическому обеспечению, все большее распространение получает модель IT-инфраструктуры, получившая название SOA (Service-Oriented Architecture) — сервис-ориентированная архитектура. По сути, это реализация давно вызревавшей формы взаимодействия бизнес- и IT-подразделений по созданию и развитию АБС, когда в четко структурированной модели, понятной бизнес-подразделениям, определяется набор требований к внутренней структуре взаимодействия данных с помощью интеграционной платформы IT-решения. Опуская детали реализации, важно отметить конечную цель, достигаемую такой архитектурой решения, — это возможность гибкого реагирования на изменения требования бизнеса, его расширение, слияния/поглощения, изменения оргструктуры и т. д. По сути, речь идет о снятии ограничений на развитие бизнеса.
Но выбор клиента предопределяется не только результатами анализа технологических различий систем от российских и западных поставщиков АБС. Интегральная банковская система должна обеспечивать регистрацию и правильную обработку различных событий по взаимодействию с клиентами. Только на первый взгляд может показаться, что речь идет о наличии в составе решения CRM — Управление взаимоотношениями с клиентами. Безусловно, компонент CRM должен присутствовать в составе АБС, но на самом деле речь идет о реализации в системе know-how розничного бизнеса, когда все составляющие системы гармонично работают по обработке клиентской информации и взаимодействию людей, вовлеченных в цикл работы с клиентами: от первичного контакта до продажи и обслуживания.
Отдельно необходимо рассмотреть возможные схемы организации многофилиальных банков и соответственно АБС, которые обеспечивают корректную работу таких банков.
Можно сформулировать следующие требования к АБС многофилиального банка. Система должна обеспечивать:
корректный учет операций банка в соответствии с действующими нормативными документами;
составление периодической и разовой отчетности, определенной инструкциями Центрального Банка и другими документами;
гибкую настройку для учета всех изменений, вносимых в действующие нормативные акты;
возможность анализировать текущее состояние банка и прогнозировать его на заданную перспективу;
оперативное управление активами банка;
возможность получения консолидированных данных по всему банку;
одинаковый режим работы с лицевыми счетами в любом учреждении банка.
Можно выделить следующие схемы построения АБС:
централизованная,
консолидационная,
репликационная,
распределенная.
В централизованной схеме:
для ведения всех баз данных используется единый вычислительный комплекс, находящийся в головном учреждении банка;
доступ к данным из филиалов осуществляется в режиме «терминал-сервер»;
обработка всей информации производится центральным компьютером.
Достоинство: данная схема в любой момент гарантирует актуальность данных.
Недостатки:большая нагрузка на центральный компьютер и высокие требования к телекоммуникациям.
Консолидационная схема:
каждый филиал практически автономен.
для ведения баз данных используется вычислительный комплекс филиала, там же производятся и все операции.
расчеты между банковскими филиалами осуществляются по клиринговой схеме.
с определенной периодичностью филиалы подключаются к центральному компьютеру головного учреждения для клиринга и (или) консолидации баланса.
Достоинства: низкие требования к телекоммуникациям и неограниченное число уровней иерархии в структуре банка.
Недостатки:
банк не имеет оперативного представления ни о текущем состоянии своих активов, ни об их движении;
клиенты не могут рассчитывать на получение во всех учреждениях банка одинакового набора услуг, т. к. полный доступ к лицевому счету имеется только в том отделении, где счет был открыт;
консолидационная схема решает задачу объединения восходящих потоков информации;
нисходящие (от головного учреждения к филиалам) и горизонтальные (между филиалами) потоки в ней не предусматриваются, за исключением клиринговой информации.
Репликационная схема:
каждое учреждение банка имеет полнофункциональный вычислительный комплекс, работающий в автономном режиме;
периодически производятся сеансы связи между филиалами и головным отделением;
во время сеанса связи производится не просто консолидация баланса, а полная актуализация баз данных.
Достоинства: каждый филиал имеет полную актуальную БД.
Недостатки:
высокие требования к вычислительным мощностям (каждый филиал должен обладать ресурсами, необходимыми для ведения баз данных всего банка) и телекоммуникациям (объем передаваемых при репликации данных довольно велик);
актуальность данных сохраняется фактически лишь несколько мгновений непосредственно после репликации, а затем базы данных в разных учреждениях банка начинают быстро «расходиться»;
ввиду первых двух недостатков вытекает естественное требование — репликации должны производиться часто.
Распределенная схема:
предполагает использование монитора (менеджера) транзакций, который изолирует «клиентскую» часть от «серверной»;
со стороны клиента монитор транзакций выглядит как обычный сервер, со стороны сервера — как обычный клиент;
принципиальная разница заключается в том, что монитор транзакций «знает», на каком (или на каких) из серверов размещены данные, к которым обращается клиент;
отдельные части этой информации могут находиться на разных серверах, тем не менее благодаря монитору транзакций клиент обращается к ним так, как будто они располагаются на одном сервере.
Достоинства: АБС, построенные по этой схеме, позволяют обращаться к любым имеющимся данным в режиме реального времени. При этом создается возможность оперативного анализа и управления активами банка. Естественно, все услуги становятся одинаково доступными для клиентов банка во всех его филиалах.
Однако распределенная схема имеет и ряд ограничений:
такие АБС имеют высокую стоимость;
чрезвычайно сложны во внедрении;
требуют высококвалифицированного персонала;
«не любят» плохих линий связи, т. е. требуют выделенных каналов связи и закрытых надежных систем телекоммуникации.
2.4. Современное состояние АБС. Обзор отечественных АБС. Фирмы-разработчики АБС
По материалам периодической печати можно судить, что 1998 г. стал годом перехода к внедрению АБС четвертого поколения, основой которых, в свою очередь, является ориентация на профессиональные СУБД. Что же это дает и зачем все это нужно:
Оптимизированный многопользовательский режим работы с развитой системой транзакционной обработки обеспечивает многочисленным пользователям возможность работы с базой данных, не мешая друг другу.
Надежные средства защиты информации (учитывая стандартную трехзвенную архитектуру защиты на уровне сети — на уровне сервера БД — на уровне клиентской ОС).
Эффективные инструменты для разграничения доступа к БД.
Поддержка широкого диапазона аппаратно-программных платформ.
Реализация распределенной обработки данных.
Возможность построения гетерогенных и распределенных сетей.
Развитые средства управления, контроля, мониторинга и администрирования сервера БД.
Поддержка таких эффективных инструментариев, как словари данных, триггеры, функции, процедуры, пакеты и т. п.
Все вышеперечисленное обусловило широкое распространение решений на базе профессиональных СУБД в крупных коммерческих банках и промышленных корпорациях. По экспертным оценкам, по числу установок лидируют СУБД Oracle, Informix, Sybase. Несмотря на это, в большинстве средних банков и в малых банках и на предприятиях по-прежнему ориентируются на решения на базе АИС третьего и даже второго поколения.
Какие же основные «мнимые» стереотипы пока не позволяют этим структурам ориентироваться на использование профессиональных СУБД при построении своих АИС
ПРОТИВ« — Относительно высокая стоимость профессиональных СУБД.
«ЗА» — Как правило, поставщиками практически всех профессиональных СУБД сейчас предлагаются масштабируемые решения, т. е., например, Enterprise Database — для крупных систем и WorkGroup Database — для средних и малых систем, причем цена последних сравнима с ценами на локальные СУБД.
«ПРОТИВ» — Профессиональные СУБД предъявляют высокие требования к аппаратной платформе.
«ЗА» — С резким ростом производительности Intel-ориентированных аппаратных платформ большинство производителей профессиональных СУБД выпустили свои версии и под Intel-серверы, в том числе и под ОС LINUX, а учитывая, что LINUX при всей мощности UNIX-системы практичсеки беспланая ОС, то и решение на ее основе, как правило, не влечет больших финансовых затрат. Это позволяет при построении системы ориентироваться не только на высокопроизводительные многокластерные RISC сервера, но и использовать серверные Intel-платформы.
|
