Сучасні банківські автоматизовані системи

ЗМІСТ

Введення ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .... ... .. ... ... .... 3

1. Автоматизовані банківські системи, їх еволюція і технологічне побудова ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .... 6

2. Основи автоматизації банківської діяльності ... ... ... ... ... ... ... .... ... ... 24

1. Ситуація на ринку банківських технологій ... ... ... ... ... ... ... ... .... ... ... 24

2. Класифікація сучасних автоматизований банківських систем ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 26

3. Принципи побудови автоматизований банківських систем як засоби автоматизації робіт з банківськими продуктами

... ... ... .28

Висновок ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 36

ВСТУП

Сучасне грошово-кредитна та фінансове господарство країнипереживає серйозні зміни в структурному відношенні. Перебудовуєтьсякредитна система, виникають нові види кредитно-фінансових інститутів іоперацій, модифікується система відносин центральних Банків та фінансово -кредитних інститутів, складаються інші пропорції в динаміцідержавного і приватного сектора.

Незважаючи на існуючі недоліки українського законодавства,що регулює діяльність банків, ситуація неухильно змінюється на краще.

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

Все це безпосередньо пов'язано зі зміною загальної економічноїобстановкою в Російській Федерації. Спад промислового виробництва увсіх галузях народного господарства хронічні неплатежі - все цезмушує шукати нові форми розрахунків, кредитних відносин.

Необхідність вироблення нової стратегії і тактики управлінняпідприємством вимагає підвищення кваліфікації персоналу, усвідомлення сутіфункціонування системи кредитно-фінансових відносин.

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

В умовах посилення міжбанківської конкуренції успіхпідприємницької діяльності буде супроводжувати тим банкірам, якікраще оволодіють сучасними методами управління банківськими процесами.

Пройшли часи, коли можна було легко заробляти наспекулятивних операціях з валютою та шахрайстві. Сьогодні все більшебанків робить ставку на професіоналізм своїх співробітників і новіінформаційні, комп'ютерні технології.

Важко уявити собі більш благодатний грунт для впровадження новихкомп'ютерних технологій, ніж банківська діяльність. В принципі майже всезавдання, які виникають у ході роботи банку, досить легко піддаютьсяавтоматизації. Швидка та безперебійна обробка значних потоківінформації є одним з основних завдань будь-якої великої фінансовоїорганізації.

Відповідно до цього очевидна необхідність володіння сучасноїавтоматизованої банківської системи (надалі АБС), що дозволяєефективно обробляти всі зростаючі інформаційні потоки, а такожбезпосередньо здійснювати операції на кожному етапі створення банківськогопродукту. Крім того, саме банки володіють достатніми фінансовимиможливостями для придбання та використання найсучаснішої техніки.
Однак не слід вважати, що середній банк готовий витрачати величезні суми накомп'ютеризацію. Банк, є перш за все фінансовою організацією,основним завданням якої є не максимізація прибутку, а сталийстановище на ринку. Відповідно до загальносвітової практики в середньому банкувитрати на комп'ютеризацію складають не менше 17% від загального кошторису річнихвитрат. Але в результаті різкого змін курсу рубля по відношенню додолара ця цифра значно зросла.

Інтерес до розвитку комп'ютеризованих банківських систем визначаєтьсяне бажанням витягти миттєву вигоду, а, головним чином, стратегічнимиінтересами. Як показує практика, інвестиції в такі проекти починаютьприносити прибуток лише через певний період часу, необхідний длянавчання персоналу та адаптації системи до конкретних умов. Вкладаючикошти в програмне забезпечення, комп'ютерне і телекомунікаційнеобладнання та створення бази для переходу до нових обчислювальнихплатформ, банки, в першу чергу, прагнуть до здешевлення і прискореннясвоєї рутинної роботи та перемоги в конкурентній боротьбі.

Нові інформаційні технології допомагають банкам, інвестиційнимфірмам та страховим компаніям змінити взаємовідносини з клієнтами та знайтинові засоби для отримання прибутку. Аналітики сходяться на думці, щонові технології найбільш активно впроваджують інвестиційні фірми, потімслідують банки, а самими останніми їх приймають на озброєння страховікомпанії.

Завдання, які стоять перед усіма фінансовими організаціями, однакові:інтеграція успадкованих систем в розподілену архітектуру локальнихмереж. Девід Стюарт, головний консультант з нових технологій в Global
Concepts, вважає, що сьогодні попит на людей, які розуміють в мережах, вище,ніж будь-коли раніше. На його думку, в наш час при влаштуванні на роботув банк перевага віддається програмісту, а не касиру.

Банківські комп'ютерні системи на сьогоднішній день є однією знайбільш швидко розвиваються галузей прикладного мережевого програмногозабезпечення. Потрібно відзначити, що АБС «є» "ласий шматочок"для будь-якого виробника комп'ютерів та програмного забезпечення. Томумайже всі великі компанії розробники комп'ютерної техніки пропонують нацьому ринку системи, на базі своїх платформ. Взяти, наприклад компанію R-
Style одного з найбільш перспективних, на мою думку, розробників АБС,що у міру випуску програмного забезпечення пропонує клієнтукомп'ютери, сервери комплектуючі і т. д.

В якості прикладів передових технологій, що використовуються в банківськійдіяльності, можна назвати бази даних на основі моделі "клієнт-сервер"
(характерне використання ОС Unix та БД Oracle); засоби міжмережевоївзаємодії для міжбанківських розрахунків; служби розрахунків, цілкоморієнтованих на Internet, або, так звані, віртуальні банки;банківські експертно-аналітичні системи, які використовують принципиштучного інтелекту і багато іншого.

1. Автоматизована банківська система,

ЇХ ЕВОЛЮЦІЯ І ТЕХНОЛОГІЧНЕ

ПОБУДОВА

У 1999 році виповнилося одинадцять років з моменту появи в нашійкраїні перших комерційних банків. Практично стільки ж існує івітчизняні автоматизовані банківські системи. Одинадцять років --чималий термін навіть за мірками західного ринку, де автоматизацією банківськоїдіяльності займаються вже понад чверть століття.

За радянських часів банківські установи виконували одне завдання --обслуговування розрахунків державних підприємств та організацій.
Автоматизація підприємств Держбанку СРСР перебувала в зародковому стані.
У другій половині вісімдесятих розрахунки для державних кредитнихустанов виробляли обчислювальні центри Держбанку, багато з яких посуті були машинолічильних станціями, які працювали на електромеханічнихкалькуляторах.

Комерційним банкам відразу ж довелося надавати в Держбанкщоденні баланси. Без власних засобів автоматизації зробити це було,м'яко кажучи, важко - навіть для того рівня банківських операцій,який був тоді. На щастя, саме в цей час з'явилися кооперативи тацентри НТТМ, завозиться в країну персональні комп'ютери. Люди, здатні допрограмування, створювали «тимчасові творчі колективи», шукали ізнаходили замовлення на автоматизацію банківської діяльності та отримували своїгроші за «впровадження науково-технічних досягнень». Програми писалися на
Clipper або FoxBase, іноді на ТурбоПаскале, які списувалися умільцямиодин у одного і освоювалися без жодної документації.

Перші серійні АБС - так звані «київський» і «тульський опердні»,рекомендовані для закладів тодішніх «спецбанков», розійшлися по всійкраїні. Де-не-де на них працюють до сих пір. Це були системи першоготехнологічного покоління. Вони працювали на автономних персональнихкомп'ютерах, не об'єднаних у локальну мережу (такі мережі тоді мало хтомав). Операціоністи виконували проводки безпосередньо по особових рахунках.
В кінці операційного дня дані з усіх комп'ютерів переносили на дискетахна один - головний, на якому проводилася їх консолідація і розраховувавсябаланс. Нерідко банки економили на дискетах, купуючи дешеві болгарські
«Пятідюймовкі», через що доводилося іноді ночами «перебивати»документи заново.

Вже в 1992 р. в багатьох банках почали з'являтися локальні мережі, ітоді заявили про себе системи другого покоління. По суті відмінність у нихбуло одне - всі робочі файли знаходилися на сервері локальної мережі. Цеспрощувало консолідацію балансу, однак створювало нові проблеми. Справа в тому,що «персональні» системи управління базами даних, на яких будувалисятакі АБС (ті ж самі Clipper, Fox або Clarion), призначалися длявикористання на одиночних комп'ютерах. Коли кілька користувачів здекількох робочих станцій одночасно зверталися до даних, в локальніймережі виникали «конфлікти». Крім того, вся обробка даних у подібнихсистемах проводилася робочими станціями - сервер використовувався лише як
«Зовнішній диск», сховище файлів, тому всі дані, накопичені в базі,доводилося «проганяти» по локальній мережі при кожній операції пошуку. Мережадосить скоро перевантажується, і було потрібно збільшувати потужність сервера іпропускну здатність активного мережевого обладнання. А якщо хтось ізопераціоністів під час виконання операції з великим обсягом обробкиданих (наприклад, перестроювання індексу), не дочекавшись її завершення,вимикав свій комп'ютер, вся база даних «розвалювалася». Те ж саме могловідбутися і просто через те, що невчасно «моргнув» електрику ...

АБС другого покоління дуже швидко завоювали ринок. На них вирослизараз такі відомі фірми, як ЛІМ, «Інверсія», «ПрограмБанк»,
«ДиаСофт», «АСофт» ... Деякі з них до цих пір основний свій дохід маютьвід супроводу старих систем другого покоління.
Проте вже в 1993 р. системи, зроблені на технологічній базі
«Персональних» СУБД, перестали задовольняти багато банків і перш за всевеликі: для них важлива була ефективна робота в локальній мережі. Ряд із нихстали закуповувати західні розробки, інші намагалися створити АБС своїмисилами ... Нові рішення почали пропонувати та вітчизняні фірми -розробники. Деякі, орієнтуючись на Захід, робили ставку на «важкітехнології »- потужні центральні комп'ютери, що працюють в режимі« хост -термінал »або« клієнт-сервер », і професійні системи управління базамиданих (СУБД). Саме так побудовані практично всі західні АБС,що працюють в серйозних банках. Проте в Росії подібні АБС до цих пір ненадто популярними: їх технічна база (центральні комп'ютери, ліцензії насистемне програмне забезпечення тощо), у порівнянні з персональноютехнікою, дуже дорого коштують і вимагає спеціальної підготовки персоналу. УВодночас у кожному банку, що має локальну мережу, є вже цілкомстійка мережева СУБД: простенький, але ефективний менеджер записів
Btrieve, що входив до складу мережевої операційної системи Novell NetWare.
Кмітливі розробники скористалися цим і створили на базі Btrieveцілий ряд АБС третього покоління.

У Росії системи третього покоління одержали широке поширенняі розвиток. Перші продукти цього покоління представили Інкомбанк (система
«Садко», зараз вже абсолютно застаріла морально), фірми «Банківськісистеми »(нині« Кворум »),« R-Style Software Lab. », новосибірський« Центрфінансових технологій »та інші. Деякі компанії ( «R-Style Software
Lab. », ЦФТ) на відповідній технологічній базі створили дужецікаві рішення, в яких засобами Btrieve реалізуються функції,споконвічно наявні в професійних СУБД, - наприклад, транзакційниймеханізм (RS-Bank), а також оригінальні архітектури (машина проводоксистемі ЦФТ).

Перші вітчизняні системи четвертого технологічного покоління --на базі професійних СУБД - з'явилися майже одночасно з системамидругого покоління. Як приклад можна привести систему «Піраміда»пітерської фірми НЕСТ, створену в 1990 р. Системами четвертого поколіннязаймалися фірми CSBI EE із Санкт-Петербурга, БІС, «ФОРС», «Ескейп-М» іінші.
Концентрація фінансового капіталу призводить до укрупнення банків, народженнюфіліальних мереж, що зумовило нові вимоги до АБС. АБСбагатофілійного банку повинна підтримувати розподілену обробкуінформації. Для цього необхідні відповідні телекомунікаційнікошти, а головне - адекватна технологія. АБС п'ятого покоління (якихпоки на нашому ринку дуже мало і за ціною вони дуже дорогі) відрізняються відсистем четвертого покоління використанням менеджера транзакцій --спеціальної програми, що керує доступом до розподілених даних. Такісистемам реалізовані в трирівневій архітектурі «клієнт-сервер» (АБСчетвертого покоління розроблені в дворівневої архітектури).

Наприкінці 1996 р. стало відомо про АБС шостого технологічногопокоління, побудованих на базі новітніх компонентних технологій.
Промислових систем шостого покоління поки немає, хоча є приклади вдаловиконаних за цими технологіями елементів АБС.

Таким чином, сьогодні на російському ринку АБС одночасноприсутні системи чотирьох технологічних поколінь - з другого поп'яте. Досить часто одна й та сама фірма-розробник одночаснопропонує клієнтам системи кількох поколінь. Так працюють, наприклад,
«Інверсія», «ПрограмБанк», «ДиаСофт» (вони пропонують системи друге,третього і четвертого поколінь), ЦФТ (пропонують системи третє,четвертого і п'ятого поколінь). Нещодавно компанія «R-Style Software Lab."також представила свою нову розробку «Кондор», що відноситься до четвертоготехнологічному поколінню.
У російських банках переважають системи другого і третього поколінь, хочаза кордоном вони практично не зустрічаються. Чому ж АБС на базіпрофесійних СУБД не зайняли в Росії того місця, яке вони займаютьза кордоном? Основна причина цього - різниця в мотивах і механізм прийняттярішень в галузі інформаційних технологій у нас і в інших країнах.

Як приймаються рішення?

Як показує практика, переважна більшість російських банківприймають рішення про закупівлю або зміні АБС виключно під впливомзовнішніх по відношенню до банку факторів: змін нормативної бази,вимог ЦБ РФ, необхідності вчасно здавати звіти і т.д. За кордономосновний мотив такого рішення - внутрішня потреба банку у змінітехнології: для зниження операційних витрат, поліпшення обслуговуванняклієнтів і т.п.

Звідси і різниця в механізмі прийняття рішень. У закордонному банкурішення про закупівлю (зміні) АБС фактично є наслідком рішення прозміну технології роботи банку. Воно приймається після ретельногообстеження банку, вивчення що проходять в ньому інформаційних потоків іскладання детального технічного завдання. Ця робота проводитьсяфахівцями-аналітиками (часто з зовнішньої консалтингової фірми) зучастю всіх підрозділів банку. АБС купується, як правило, наконкурсній основі. Її впровадження займає шість-дев'ять місяців - з моментупідписання контракту на поставку до введення АБС в експлуатацію. Зазвичай длякерування процесом закупівлі та впровадження створюється робоча група зкерівників банку, зовнішніх консультантів та представників розробника.
Ця група наділена дуже великими повноваженнями з реорганізаціїдіяльності підрозділів банку. У ході впровадження автоматизованасистема переробляється у відповідності з конкретною технологією, обраноїзамовником.

Як вибирається і впроваджується АБС у нас, читачі знають за власнимдосвіду. Найчастіше нова АБС купується або для нового банка, або коликолишню вже зовсім неможливо використовувати. При цьому головна вимогадо нової АБС - заткнути ті дірки, які не затикає попередня. Багатокерівники банків ставлять в основу дешевизну системи, до цих пір нерозуміючи, що «справжня» АБС повинна коштувати дорожче хоча б автомобіля, наякому їздить голова правління: саме від неї за великим рахункомзалежить благополуччя банку.

У відставання російських банків частково винні й розробники. Колиу 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

ТЕРМІНИ І ПОНЯТТЯ, що використовуються

Ядро системи

Центральне місце в ядрі системи займає облікова система. В їїоснові - абстрактна модель бухгалтерського обліку з основоположнимпринципом подвійного запису. Основними об'єктами системи обліку є:

- конто;

- показник;

- журнал;

- проводка.

У термінах бухгалтерської моделі конто і показники єабстрактними рахунками облікової системи.

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

Показник призначений для синтетичного обліку, для угрупуванняаналітики при формуванні звітності та аналізу. На зовнішньому рівніпоказниками відповідають рахунку I-II порядків, розділи Плану рахунків ЦБ,символи звітності різних форм.

Структура показників і конто будується на основі ієрархіїнеобмеженого рівня вкладеності.

Журнал - це об'єднання показників, що мають один економічнийсенс.

Прикладами журналів можуть бути глави Плану рахунків ЦБ ( "Балансовірахунки "," Позабалансові рахунки "," Рахунки депо "), список символів касовоїзвітності, форми звітності за Інструкцією № 17 і т.д.

Проводки формують стану конто - що зберігаються в системі обороти подебету і кредиту, залишок. Стани показників р.