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

Компонент підтримки документообігу — найважливіша в прикладній системі. У її склад входять: документ, картотека і портфель.

У нашій статті поняття " папка" замінено на поняття " картотека". Картотеки (на відміну від папок) мають деякі обмеження, зокрема:

- їх кількість у системі звичайна;

користувачі системи не можуть створювати і знищувати їх;

- дозволені переміщення документа з однієї картотеки в іншу, що заздалегідь про­писується технологом системи;

звертання до транзитної системи для ініціювання проводок у системі обліку від­бувається при переміщенні документа з картотеки в картотеку.

Картотека поєднує документи, що знаходяться на одній стадії обробки (ска­жемо, особові рахунки картотеки № 2).

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

Взаємодія прикладної системи з обліковою в процесі руху й обробки докумен­та представлено на Мал. 4.

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

Мал. 4. Процес обробки документа.

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

Модулі клієнтської частини і процедури сервера даних забезпечують як ви­конання операцій над документом, так і інформаційний сервіс по документообігу.

Компонент представлення облікової системи дає (незалежно від документо­обігу) можливість доступу до системи обліку в межах, необхідних конкретній приклад­ній підсистемі.

Компонент довідників і класифікаторів — допоміжний. Основне призна­чення — здійснювати облік всіх інших об'єктів банківської системи, тобто тих, котрі не є ні документом, ні рахунком. До цих об'єктів відносяться анкетні дані про клієнтів, класифікатори банків-кореспондентів, інформація про валюти (у тому числі про їхні курси), зведення про умови нарахування відсотків для різних банківських операцій і т.д.

Для кожного з цих об'єктів передбачені по дві групи програмних модулів: одна відповідає за створення і підтримку об'єктів, інша є модулями використання об'єктів.

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

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

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

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

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

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

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

Отже, вимоги до фінансових систем за останні два роки істотно зросли. Тепер усі хочуть мати масштабні і стерпні системи, що могли б функціонувати не на одній, а цілому ряді популярних СУБД і на цілому ряді мережних операційних систем. Усіх ці­кавить можливість доступу через глобальну мережу Інтернет. Багатьом дуже цікава мо­жливість створення графічної звітності, наявність елементів бізнес графіки, а також можливість роботи з графічною інформацією, наприклад, збереження фотографій фізи­чних осіб, зразків їхніх підписів і т.д.

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

Усі перераховані задачі дуже важко, а найчастіше і неможливо вирішувати на тому поколінні інструментальних засобів, якими користуються сьогодні більшість фірм - розроблювачів. Ці інструментальні засоби реалізовані для платформи МS-DOS і вже значно застаріли. Тому сучасні програмні засоби повинні відповідати перерахованим вище вимогам.

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

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

Такими параметрами можуть бути, наприклад:

/. «Базовий об'єкт» при побудові технологій обробки бізнес процесів: проводка; документ; банківський продукт.

2. Рівень реалізації банківських технологій:

з жорстко заданим набором визначених технологій;

з можливістю працювати з різними банківськими технологіями (універсальна

АБС).

3. Рівень захисту інформації:

криптозахист;

криптозахист і трьохрівнева модель обробки даних;

криптозахист, трьохрівнева модель;

інші засоби захисту.

4. Функціональна повнота:

наявність системи керування ризиками;

наявність системи консолідованого керування фінансовими ресурсами; підтримка широкого спектра банківських продуктів;

включення новітніх банківських технологій («Ноте Ваnking», «Іпternet», «теле­фонного банку», відеоконференцій і т.д.).

5. Робота з філіями і вилученими площадками:

на основі розподіленої бази даних з off-line-реплікацією; на основі єдиної бази даних.

6. Використання убудованих засобів розробки:

генератора звітності; - макромови;

генератора об'єктів; інших САSE-засобів.

Можливі й інші критерії оцінки.

Ймовірно, що надалі при класифікації автоматизованих банківських систем бу­де використаний комплексний («матричний») метод, заснований на виборі групи кри­теріїв, що визначають безліч можливих значень класифікації. Сукупність значень кри­теріїв для оцінюваної АБС за допомогою визначеної функції перетворяться в зведений інтегральний показник — так названий Класифікатор «покоління АБС». Таким чином, думаю, можна досягти найбільш повної «вірогідності» класифікації. При використанні «матричного» підходу розроблювач-аналітик повинен визначати наступні параметри моделі:

- найбільш адекватні критерії оцінки; - формальні взаємозв'язки між цими критеріями; - значення обраних критеріїв оцінки; - значення Класифікатора «покоління АБС»;

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

Таблиця 2

ОСНОВНІ ОЗНАКИ, ЩО КЛАСИФІКУЮТЬ ТЕХНОЛОГІЧНЕ ПОКОЛІННЯ АБС

 

Технологічне покоління АБС	Основна ознака, що класифікує
І	Персональна СУБД в автономному режимі
П	Персональна СУБД у мережному режимі
Ш	Менеджер записів Btrieve
IV	Професійна СУБД
у	Менеджер гранзакцій
VI	Компонентна технологія

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

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

Мета автоматизації робіт з банківськими продуктами

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

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

Мал. 7 Банківські технологічні ланцюжки

Головний бухгалтер банку, що відповідає за правильне відображення процесу реалізації банківських послуг у звітах, установлених чинним законодавством, зацікав­лений у тому, щоб АБС мала у своєму розпорядженні засоби, що забезпечують одно­значний опис правил бухгалтерського обліку операцій відповідно до прийнятої обліко­вої політики банку. Одночасно АБС повинна надавати головному бухгалтеру засоби, що дозволяють контролювати виконання конкретними співробітниками чи окремими структурними підрозділами банку правил бухгалтерського обліку при здійсненні бан­ківських операцій.

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

Що стосується технолога банку чи адміністратора АБС, найчастіше виконую­чого ці обов'язки, то їм необхідно бачити загальну картину створення і реалізації бан­ківських продуктів. Тут питання функціонування АБС прямо стуляються з організацій-ними аспектами в діяльності банку. Це — питання керування доступом до даних і фун­кцій системи, проблеми побудови бізнес процесів, узгодження дій різних служб і пра­цівників банку і т.п. Якщо для конкретного співробітника банку, потрібно специфічний підхід до організації інтерфейсу, що враховує особливості виконуваних ним операцій, то технологу банку глибоко формалізований і універсальний опис бізнес процесів до­зволяє якісно оцінити ефективність виконання тієї чи іншої банківської послуги і намі­тити заходи для усунення " вузьких" місць у технології роботи організаційно штатних елементів системи, що експлуатуються в банку.

Способи реалізації вимог до АБС, покликаної забезпечувати автоматизацію ро­біт з банківськими продуктами.

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

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

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

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

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

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

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