Современные банковские автоматизированные системы

В отставании российских банков отчасти повинны и разработчики. Когда

в 1994-1995 гг. создались благоприятные условия для смены поколений АБС

(банки имели свободные средства, а норма прибыли начала ощутимо снижаться —

это способствовало созданию у банков внутренней мотивации к

совершенствованию технологий), на рынке почти не оказалось отечественных

АБС четвертого поколения, приемлемых по критерию «стоимость —

эффективность». Ведущие (по числу проданных копий) разработчики АБС

предыдущих поколений либо сочли, что «от добра добра не ищут», либо

отнеслись к созданию АБС нового поколения недостаточно продуманно. Многие

из них решили, что для успеха достаточно перенести на профессиональную СУБД

то, что было наработано на Clipper или FoxPro. Технически осуществить такой

«перенос» было относительно легко, но очень сложным делом оказалось

объяснить покупателям, зачем надо платить в несколько раз больше за

систему, в которой практически нет отличий от старой с точки зрения

функциональности. К тому же подавляющее большинство разработчиков просто не

смогло вовремя представить на рынок законченные системы четвертого

поколения, так как освоение инструментальных средств и выработка концепции

новой системы отняли у них слишком много времени. Ряд разработок, с большой

помпой объявленных два-три года назад, не готовы и до сих пор.

Немудрено, что многие российские банки до сих пор используют морально

устаревшие, неадекватные и ненадежные АБС. А уж о безопасности систем

второго, и отчасти третьего, поколений говорить не приходится.

«Оправданием» отечественных банков может служить то, что они вынуждены

покупать системы по принципу «побыстрее да подешевле», как говорится, не от

хорошей жизни. До сих пор нормотворчество Центробанка заставляло

разработчиков не реже, чем дважды в год, переделывать ядро системы и схему

данных, а что касается отчетов, то они добавлялись или изменялись порой по

несколько раз на неделе. Апофеозом такого стиля руководства отечественной

банковской системой стал переход на новый План счетов, который объективно

необходим и полезен, но внедряется со свойственной нашему национальному

характеру бесшабашностью и недальновидностью.

Из всех постсоциалистических стран, где вводился план счетов по

образцу международного, только в России национальный банк тянет до

последнего с формированием полного комплекта инструктивных и методических

материалов. Отдельные инструкции, без которых, кстати говоря, невозможно

представить заказчику законченную АБС, должны быть готовы к 1 ноября1997

г., то есть за два месяца до перехода — и это по плану, а что будет на

самом деле — Бог весть... Но даже в случае, если ЦБ РФ выдержит собственный

план, инструкции поступят в банки отнюдь не в день их подписания.

В этой ситуации некоторые банки искренне надеются, что «все

рассосется», и каким-то чудодейственным образом переход на новый План

счетов будет сдвинут с 1 января 1998 г. на какой-то неопределенный срок.

Ассоциация российских банков даже обратилась в Банк России с просьбой

перенести переход на начало второго квартала(!). Не дай Бог, если эта

просьба будет удовлетворена. Тогда к организационным сложностям перехода

добавятся чисто технические, поскольку — и это достаточно очевидно — всякие

изменения в бухгалтерском учете гораздо легче ввести с начала года, чем с

начала квартала.

Новый план счетов и АБС

Необходимо отметить, что переход на новый План счетов бухгалтерского

учета потребует обязательной замены или модернизации АБС практически во

всех отечественных банках. Дело в том, что изменяется не только План

счетов, но и сама методология бухгалтерского учета, причем в нормативных

документах ЦБ РФ некоторые функции в обязательном порядке возлагаются на

АБС. Почти во всех системах автоматизации, которые сегодня работают в наших

банках, этих функций просто-напросто нет. Поэтому современная ситуация на

рынке напоминает ту, которая сложилась в 1992 г., когда число банков

стремительно росло, и фирмы-разработчики не успевали удовлетворять спрос на

специализированные банковские программные продукты.

Неизбежен передел рынка АБС: с него уже ушли некоторые фирмы,

например «АСОФТ» (не путать с «АСофт», которая благополучно продолжает

существовать) или «VIMCOM». По-видимому, понесут некоторые потери такие

заслуженные разработчики, как «Инверсия», «ПрограмБанк», «ЛИМ», чьи DOS-

комплексы в некоторых банках будут заменены на системы третьего поколения —

и вовсе не обязательно тех же самых фирм. Ожидается, что самые большие

«убытки» понесут собственные программные разработки банков.

Целый ряд опросов, проведенных журналом «Банковские технологии»,

показал парадоксальную картину: среди банков-респондентов, имеющих АБС

собственной разработки, довольных этой АБС оказалось значительно меньше,

чем среди тех, кто работает на «фирменной» АБС. Объясняется это просто: во-

первых, собственные системы в большинстве случаев выполнялись на тех же

FoxPro или Clipper; во-вторых, коллективы разработчиков, которых могут

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

разработка ведется по принципу «латания дыр», что исключает системный

подход и нормальное взаимодействие отдельных модулей. «Доморощенные» АБС

очень трудно, да и практически невозможно, подвергнуть серьезной

модернизации, так как нормальная документация проекта обычно не ведется.

Именно такие АБС скорее всего потребуют замены. Если какие-то банки еще

питают иллюзии, что им удастся «довести до ума» подобную разработку

собственными силами и в срок, и поэтому тянут с решением о переходе на АБС,

созданную внешними фирмами, то их ожидают большие разочарования.

Совершенно очевидно, что многие банки будут вынуждены «менять коней

на переправе», так как имеющиеся у них АБС неадекватны, и любые попытки как-

то удержаться на старой платформе приведут к большим потерям. В этом случае

следует помнить одно: переход на новый План счетов будет успешным только

там, где вовремя проведена тщательная его организационная подготовка (жаль

только, что методичность и скрупулезность не свойственны нашему

национальному характеру). Руководство банка должно было уже в октябре

составить и утвердить детальный план перехода, в котором следует четко

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

Этот план должен быть расписан по неделям, а с декабря — по дням, с

соответствующей оперативной отчетностью.

Чтобы более нагляднее представить, что такое современная АБС,

постараемся более подробно разобрать ее строение.

Технологическое построение АБС описывает группировку программных

модулей и процессы, происходящие в ходе функционирования системы. Суть

части этих процессов определяют абстрактные механизмы, лежащие в основе

реализации конкретных прикладных компонент системы. Такие механизмы

составляют технологическое ядро системы.

Архитектурное построение

Вся система состоит из трех компонентов:

1) клиентской части системы;

2) объектов сервера данных;

3) процедур сервера приложений.

Клиентская часть системы обеспечивает взаимодействие пользователя с

системой. Никакой обработки данных в клиентской части не происходит. Ее

назначение сводится к тому, чтобы принять от пользователя запрос на

выполнение операции системы и необходимые для выполнения этого запроса

данные. После того, как запрос реализован, клиентская часть дает

пользователю возможность ознакомиться с результатами выполнения операции.

Объекты сервера данных являются центральной частью системы. Здесь

хранятся все данные системы и процедуры, обеспечивающие выполнение ее

операций. Хранимые процедуры получают запрос от клиентской части на

выполнение операций и подготавливают для нее результаты своей работы. Для

выполнения некоторых специфических операций хранимые процедуры могут

вызывать процедуры сервера приложений.

На сервере приложенией выполняются специализированные AS-процедуры,

которые вызываются по запросам от процедур сервера данных.

Процедуры сервера приложений обеспечивают функционирование системы

безопасности и управления доступом, а также выполняют ту часть прикладных

операций, для которой реализация средствами сервера данных неэффективна. AS-

процедуры могут обращаться и к объектам сервера данных, если это необходимо

для их работы.

Клиентская часть системы. Основное назначение клиентской части

системы — обеспечить взаимодействие пользователя с системой, предполагающее

организацию интерфейса пользователя (отображение и обработка событий) и

связь с сервером данных (Manager SQL).

Интерфейс пользователя состоит из процедур отображения результатов

работы системы, представленных в виде экранных форм или отчетов, а также из

процедур обработки событий, возникающих в результате действий пользователя

или по сообщениям сервера данных.

Объекты сервера данных. Объекты сервера данных — это таблицы и

процедуры. По своему назначению они разделяются на системные (в контексте

банковской системы, а не базы данных) и прикладные.

Системные объекты реализуют задачи “секретности” и управления

доступом (этим правом обладает только уполномоченный оператор — так

называемый “офицер безопасности”).

Доступ к прикладным объектам клиентов возможен только через узкую

“щель”, определенную системой безопасности. Система построена так, что все

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

Последние надежно защищены системой управления доступом, и поэтому давать

разрешение пользователю на использование таблиц нет необходимости. Иначе

пришлось бы заботиться о том, кому из персонала банка следует передать

таблицу для выполнения определенных действий — при этом о доступе к

конкретным записям (“сайтам”) речь не могла бы идти вообще.

При вызове клиентом пользовательских процедур (объектов,

представляющих для системы безопасности основной интерес) сразу же

происходит обращение к серверу защиты (он реализуется как сервер

приложений). При получении соответствующего разрешения выполнение процедур

продолжается. В этом и заключается сущность взаимодействия клиента с

сервером данных под надзором системы безопасности. Остальные процедуры

(т.е. те, которые не вызываются клиентом) не связаны с системой

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

Рис. 1. Архитектура построения системы.

Все объекты на сервере данных создаются при инсталляции системы системным

администратором. Этот процесс проходит в пакетном режиме, когда с клиента

на сервер посылаются запросы на создание процедур и таблиц, а также на их

заполнение.

Процедуры сервера приложений. Сервер приложений организуется

средствами Open-Server Sybase. Он может функционировать на том же

компьютере, что и сервер данных, но может быть реализован и на другом

компьютере. Различают два вида процедур сервера приложений: первые из них

отвечают за функционирование системы безопасности и управления доступом,

вторые выполняют ту часть прикладных операций, которая неэффективно

реализуется средствами сервера данных.

Независимо от назначения, все AS-процедуры вызываются только по

запросам от хранимых процедур. Последние могут обращаться на сервер данных

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

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

Open-Client Sybase.

Технологическое построение

Проектирование и реализация системы позиционного и фактического учета

банковских операций, детальное рассмотрение вопросов ее взаимодействия с

обработкой банковских документов позволило представить технологическое

построение системы в следующем виде (Рис. 2):

Рис.2. Технологическое построение системы.

Можно определить три составляющие системы:

- Система безопасности и управления доступом.

- Ядро системы.

- Прикладная система.

Как уже отмечалось, система безопасности и управления доступом

обеспечивает защиту информации от несанкционированного доступа, являясь

обособленной системой (ей все равно, какую прикладную систему защищать).

Все остальные системы при разработке регистрируют в системе безопасности

свои объекты, а потом процедуры прикладных систем разрабатываются с учетом

требований безопасности (в основном эти процедуры представляют собой вызов

в определенных местах прикладных процедур соответствующих им процедур

системы безопасности).

Ядро системы — достаточно абстрагированный от предметной области

проблемно-ориентированный инструмент. Работа механизмов ядра не зависит от

функциональности системы. Ядро включает в себя:

- систему учета банковских операций;

- систему хранения документов;

- транзитную систему.

Система учета выполняет фактический и позиционный учет операций, а

также формирует “ограничения” на лицевые счета на базе единой абстрактной

модели.

Система хранения документов обеспечивает формализацию и хранение

документов предметной области.

Транзитная система осуществляет взаимодействие системы учета с

прикладной системой.

Реализацию функциональности, адаптацию к изменениям предметной

области обеспечивают механизмы прикладной системы, состоящей из трех

компонент:

- компоненты поддержки документооборота и выполнения операций;

- компоненты справочников и классификаторов;

- компоненты представления системы учета в аспекте предметной области.

Прикладная система обеспечивает реализацию объектов и операций

предметной области.

Система безопасности и управления доступом

Система безопасности и управлением доступом призвана обеспечить

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

данным). Она базируется на сервере данных и использует для управления

доступом к объектам БД — таблицам и процедурам — возможности сервера

данных. Для проверки возможности выполнения пользовательских процедур,

которые защищает система, применяется специализированный сервер защиты. Он

реализован в виде сервера приложений.

Основными требованиями, предъявляемыми к системе безопасности и

управления доступом, являются гибкость при определении объектов доступа и

удобство администрирования при управлении доступом. Поэтому была выбрана

матричная система защиты, предусматривающая, что управление доступом

рассматривается как с точки зрения доступа к прикладным объектам системы,

так и относительно доступа к прикладным операциям системы.

Для определения прав пользователя на возможность осуществлять

операции и на доступ к объектам надо построить некую матрицу, узлами

которой являются пересечения требований на доступ к объектам и операциям.

Функциональность системы основана на базовых операциях. Предоставляя

пользователю набор базовых операций, администратор системы определяет тем

самым его доступ. Базовые объекты определяют объектно-ориентированный

взгляд на систему. Появляется возможность управлять доступом к объектам,

определяя права на их методы, которыми являются элементарные операции.

Каждая базовая операция использует какой-либо из методов базового объекта

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

в системе складывается из его прав на базовые операции и объекты.

Рис.3. Объекты управления доступом.

Для обеспечения эффективной работы администратора системы по

управлению доступом вводится понятие оргштатного элемента, модуля и

способов группировок базовых объектов, базовых операций и самих оргштатных

элементов. Дефиниции всех этих понятий представлены в Таблице 1, а схема

управления — на Рис.3.

Работу системы по организации обобщенных объектов и операций,

построению оргштатной схемы и определению прав оргштатных элементов на

объекты и операции выполняет технолог системы на основе анализа бизнес-

процессов, происходящих в банке. Администратор системы назначает

исполнителей оргштатных элементов из числа штатных сотрудников банка.

Таблица 1

ТЕРМИНЫ И ПОНЯТИЯ, КОТОРЫЕ ИСПОЛЬЗУЮТСЯ

ПРИ РАБОТЕ АДМИНИСТРАТОРА ПО УПРАВЛЕНИЮ ДОСТУПОМ.

|Оргштатный элемент |Это “обезличенный” пользователь системы, для |

| |которого проводится работа по управлению |

| |доступом к операциям и объектам системы. Затем |

| |реальному пользователю выдается право быть |

| |представленным в системе в виде оргштатного |

| |элемента. |

|Модуль |Это характеристика клиентской части системы, |

| |физически объединяющая вызовы базовых операций. |

| |Одна базовая операция может входить в несколько |

| |модулей. |

|Обобщенный объект |Логическое объединение группы базовых объектов. |

| |Это иерархическая структура, “листьями” которой |

| |являются базовые объекты, а “ветвями” — |

Страницы: 1, 2, 3, 4