Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Сучасні банківські автоматизовані системи
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Кафедра електронних приладів та систем
Інформація про роботу
Рік:
2009
Тип роботи:
Теорія
Предмет:
Інші
Група:
ЕЛ-42
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти та науки України
Національний університет „Львівська політехніка”
кафедра електронних приладів та систем
Сучасні банківські автоматизовані системи
Підготував:
ст. гр. ЕЛ-42
Львів 2009
ЗМІСТ
Введення...................... .... 3
1. Автоматизовані банківські системи, їх еволюція і технологічна побудова.................. 6
2. Основи автоматизації банківської діяльності...........24
2.1. Ситуація на ринку банківських технологій............24
2.2. Класифікація сучасних автоматизований банківських систем...........................26
2.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 і так далі
Проводки формують стани конто — обороти, що зберігаються в системі, по дебету і кредиту, залишок. Стани показників розраховуються на основі їх відношення до конто.
При виконанні операцій над проводками фіксуються час введення, планування, підтвердження планування і фактичного обліку. За допомогою цього механізму ведеться фактичний і позиційний облік операцій. Для реалізації алгоритмів облікової системи використовуються процедури і таблиці сервера даних. До складу модулів системи обліку входять модулі клієнтської частини, які забезпечують діалоговий режим створення і застосування рахунків. В основному це модулі технолога системи, які дозволяють:
- здійснювати ведення структури об'єктів облікової системи;
- організовувати доступ для проведення аудиту до всіх рахунків і проводок системи обліку незалежно від їх прикладного застосування.
Інтерфейс модулів технолога представляє журнали, показники, конто і проводки в термінах прикладної області.
Форма зберігання документів і форматований документ дозволяють автоматизувати обробку за допомогою вибірки даних, які передаються в облікову систему і в прикладну систему (для компоненти підтримки документообігу).
При обробці документа транзитна система формує звернення до облікової системи — як при виконанні операції, так і при її відкоті. У цій системі присутні правила обліку, які визначають склад проводок і їх атрибути, а також фонд рахунків, що переводить зовнішнє представлення рахунків в ідентифікатори конто облікової системи. Крім того, в транзитній системі зберігається історія руху документа, що фіксує переходи документа з однієї стадії обробки в іншу. Транзитна система отримує результати виконання операцій обліковою системою і передає їх прикладній системі.
Прикладна система
Компоненту підтримки документообігу — найважливіша в прикладній системі. У її склад входять: документ, картотека і портфель.
Погляд на систему забезпечення документообігу досить детально висвітлений в однойменному розділі статті В.Чаусова “Концептуальна побудова банківської системи” [5].
У нашій статті поняття “тека” замінене на поняття “картотека”. Картотеки (на відміну від тек) мають деякі обмеження, зокрема:
- їх кількість в системі звичайно;
- користувачі системи не можуть створювати і знищувати їх;
- дозволені переміщення документа з однієї картотеки в іншу заздалегідь прописуються технологом системи;
- звернення до транзитної системи для ініціації проводок в системі обліку відбувається при переміщенні документа з картотеки в картотеку.
Картотека об'єднує документи, що знаходяться на одній стадії обробки (скажімо, особові рахунки картотеки № 2).
Портфель містить групу документів і визначає, яким чином ці документи зв'язані між собою (підкреслимо, проте, що на взаємодію прикладної системи з транзитною і обліковою він не впливає). Прикладом портфеля може служити сукупність документів, що відносяться до кредитного договору: власне договір, угода про пролонгацію, графіки погашення платежів, платіжні документи, супроводжуючі його виконання і ін.
Взаємодія прикладної системи з обліковою в процесі руху і обробки документа представлена на Мал. 4.
Будь-яка операція по обробці документів починається з введення документа в систему. Потім компоненту забезпечення документообігу прикладної системи виконує переміщення документа з однієї картотеки в іншу, одночасно з цим документом здійснюються певні операції. Коли у складі цих операцій є облікові, система звертається до транзитної системи, яка, у свою чергу, формує запит до облікової системи для формування проводок і зміни стану конто.
Мал. 4. Процес обробки документа.
У прикладної системи досить складна клієнтська інтерфейсна частина, що відображає рух документів по картотеках з урахуванням специфіки функціональності, що реалізовується.
Модулі клієнтської частини і процедури сервера даних забезпечують як виконання операцій над документом, так і інформаційний сервіс по документообігу.
Компоненту представлення облікової системи дає (незалежно від документообігу) можливість доступу до системи обліку в межах, необхідних конкретній прикладній підсистемі.
Компоненту довідників і класифікаторів — допоміжна. Основне її призначення — здійснювати облік решти всіх об'єктів банківської системи, тобто тих, які не є ні документом, ні рахунком. До цих об'єктів відносяться анкетні дані про клієнтів, класифікатори банків-кореспондентів, інформація про валюти (зокрема про їх курси), зведення про умови нарахування відсотків для різних банківських операцій і так далі
Для кожного з цих об'єктів передбачені по дві групи програмних модулів: одна відповідає за створення і підтримку об'єктів, інша є модулями використання об'єктів.
Перша група модулів забезпечує введення даних про об'єкти в систему, їх збереження, модифікацію і видалення. Для деяких об'єктів (серед них анкетні дані, курси валют і так далі) ведеться історія зміни їх станів, що потрібний для правильного виконання алгоритмів, пов'язаних з обробкою рахунків (відмітимо, що стан рахунку або його позиція — це теж історія зміни станів). До історії станів об'єктів звертаються і в тому випадку, якщо необхідно підготувати звітність за який-небудь період.
Друга група модулів призначена для використання даних про об'єкти програмами організації інтерфейсу користувача, процедурами підготовки звітів, а також операціями обробки документів в системах забезпечення документообігу і облікових системах. Багато об'єктів з класифікаторів і довідників є об'єктами аналітичного обліку. Тому документи і рахунки в своїх структурах зберігають посилання на ці об'єкти і звертаються до системи довідників і класифікаторів за сервісом — і, набувши значень об'єктів, указують їх в цих посиланнях.
3. ОСНОВИ АВТОМАТИЗАЦІЇ БАНКІВСЬКОЇ
ДІЯЛЬНОСТІ
3.1. СИТУАЦІЯ НА РИНКУ БАНКІВСЬКИХ ТЕХНОЛОГІЙ
Сьогоднішня банківська система Росії характеризується:
- зусиллям конкурентної боротьби між банківськими консорціумами на всіх поточних ринках і боротьби за нові ринки;
- злиттям банків, поглинанням крупними банками дрібних;
- припиненням діяльності ряду дрібних банків.
Боротьба за виживання актуальна для кожного банку незалежно від його розміру, історії, профілю діяльності. Банк, що не забезпечує динамічного розвитку свого бізнесу, ризикує рано чи пізно опинитися в числі аутсайдерів. Банк постійно розширює спектр послуг, що борються за місце під сонцем на старих і нових для себе...
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора