бесплатно рефераты
 

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

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

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

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

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

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

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

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

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

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

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

представить заказчику законченную АБС, должны быть готовы к 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

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

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

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

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

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

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

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

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

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

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

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

| |модулей. |

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

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

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

| |обобщенные объекты различного уровня |

| |“вложенности”. При управлении доступом |

| |администратор системы манипулирует обобщенными |

| |объектами наравне с базовыми объектами. |

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

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

| |являются базовые операции, а “ветвями” — |

| |обобщенные операции различного уровня |

| |“вложенности”. При управлении доступом |

| |администратор системы манипулирует обобщенными |

| |операциями наравне с базовыми операциями. |

|Оргштатная структура |Логическое объединение группы оргштатных |

| |элементов. Это иерархическая структура, |

| |“листьями” которой являются оргштатные элементы,|

| |а “ветвями” — оргштатные подразделения |

| |различного уровня “вложенности”. При управлении |

| |доступом администратор системы манипулирует |

| |оргштатными структурами наравне с самими |

| |оргштатными элементами. |

Ядро системы

Центральное место в ядре системы занимает учетная система. В ее

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

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

- конто;

- показатель;

- журнал;

- проводка.

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

абстрактными счетами учетной системы.

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

операций с использованием механизма проводок. На внешнем (прикладном)

уровне конто соответствуют лицевые счета (балансовые, внебалансовые, депо),

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

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

аналитики при формировании отчетности и анализа. На внешнем уровне

показателям соответствуют счета I—II порядков, разделы Плана счетов ЦБ,

символы отчетности различных форм.

Структура показателей и конто строится на основе иерархии

неограниченного уровня вложенности.

Журнал — это объединение показателей, имеющих один экономический

смысл.

Примерами журналов могут быть главы Плана счетов ЦБ (“Балансовые

счета”, “Внебалансовые счета”, “Счета депо”), список символов кассовой

отчетности, формы отчетности по Инструкции № 17 и т.д.

Проводки формируют состояния конто — хранящиеся в системе обороты по

дебету и кредиту, остаток. Состояния показателей рассчитываются на основе

их отношения к конто.

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

планирования, подтверждения планирования и фактического учета. При помощи

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

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

сервера данных. В состав модулей системы учета входят модули клиентской

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

В основном это модули технолога системы, которые позволяют:

- осуществлять ведение структуры объектов учетной системы;

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

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


ИНТЕРЕСНОЕ



© 2009 Все права защищены.