Автоматизація банківських систем [ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати. скачати Державний Університет Управління Інститут менеджменту в будівництві та управління проектом Кафедра управління будівництвом Спеціальність «Менеджмент» - 061100 Спеціалізація управління проектом Відділення вечірнє Курсовий проект З дисципліни: Інформаційні технології управління На тему: «Автоматизація банківської діяльності» Виконавець: студентка IV курсу Керівник проекту: кандидат ек. наук, доцент Шемтова О.Г. Москва 2000 Зміст: Зміст: 1 Введення. 3 Глава I. Автоматизовані технології в банківській діяльності. 5 Глава II. Особливості вітчизняних систем автоматизації банківських технологій. 6 Життєвий цикл ІТ. 9 Технічне оснащення рішення банківських задач. 13 Програмне забезпечення АБС. 14 Глава III. Системи автоматизації банківської діяльності за кордоном. 16 Глава IV.Інтегрірованная Банківська Система "STEM". 19 I. Концепція і принципи побудови. 19 Загальні вимоги до ІХС. 19 Вибір перспективних технологій і методу реалізації ІХС. 21 II. Інтегрована банківська система «STEM». Ядро системи. Менеджер Рахунків (Account Manager). 26 Характеристика завдань, що вирішуються Ядром ІХС. 26 Характеристики та особливості Менеджера Рахунків. 27 Реалізація підтримки цілісності Банківських операцій. 32 Підтримка впровадження системи в реальному часі. 33 III. Технологічна система ІХС "STEM". 34 Список використаної літератури: 41 Введення. Колись у середовищі розробників існувала думка, що достатньо п'яти осіб для створення банком системи комплексної автоматизації. Кожен банк, відділ автоматизації якої скільки-небудь амбітний, займався розробкою своєї АБС. Сьогодні, коли фірми розробники, виділяють під спеціалізовані проекти величезні колективи (понад 100 розробників) і витрачає багато часу на створення і опір складних багатоцільових систем, банки починають позбуватися від "дешевої лівизни" і в основному перейшли на програмні варіанти АБС. На початку 90-х років, в момент найбільш активного попиту на продукцію комплексної автоматизації банків, більшість користувачів досить слабо припускали собі, якою насправді повинна бути банківська система. Саме тоді і з'явилися прості системи, концепція побудови яких була жорстко орієнтована на "проводку" як основну структурну одиницю. З точки зору сервісних можливостей системи залишалися бажати багато кращого, а про їх надійність і говорити не доводиться, адже створювалися вони майже "на коліні", з використанням у якості СУБД FOXPRO, dBase, Clipper або Btricte. Природно, підхід до задачі саме з такої точки зору - універсальні засоби реалізації, відносна простота завдання (більшість банків вимагали від системи тільки сам мінімум), неготовність замовника до більш складної постановці завдання - і привів до того, що багато банків взялися за самостійну розробку, благо прибутковість бізнесу дозволяла. На жаль, значна відсталість структури в технологічному плані поряд з високою швидкістю вступу в цивілізоване економічне товариство зробила свій гальмівний вплив на розвиток ІТ у банківському бізнесі. Навіть сьогодні, коли практично кожен розуміє роль ІТ, а рівень підготовки наших фахівців став порівнянний з західним, може без зусиль знайти банки з першої сотні, для якої вважається абсолютно природним працездатність на слабенькою системі, реалізованої на FOXPRO, здійснюючи при цьому вручну кількість рутинних облікових операцій. Однак зі зростанням кількості банків, збільшенням конкуренції між ними зріс і рівень вимог користувачів до програмного забезпечення. На зміну "проводці" стало поступово приходити поняття "послуга" або "банківський продукт", а управління автоматизації усвідомили, що професійні СУБД - єдиноразове можлива основа для створення надійної банківської системи. Користувачі кинули погляд на ринок, а ринок у той час мовчав. Точніше, пропонував старі підходи, ненадійні за рідкісним винятком СУБД, і перспективи подальшого розвитку були вельми туманні. І банки, що пройшли колись вже цей шлях, звично пішли в атаку "за світле майбутнє" на принципово новій платформі, з новими концепціями, підходами і т.д. В устах ІТ менеджерів банків зазвучали слова UNIX, "клієнт-сервер", "трехзвенная архітектура", і банки, натхнення минулими успіхами, з новою силою взялися за реалізацію власних розробок. Отримати ж необхідний результат вдалося небагатьом. Чому? Сьогодні велика комплексна розроблена програмне забезпечення для автоматизації банківської діяльності на основі професійної СУБД, має у своєму штабі десятки аналітиків, проектувальників, програмістів, тестувальників, повністю зайнятих тільки в одному проекті. До того ж додатково залучають ресурси, зайняті в інших виробництвах. Виробник програмного забезпечення може інвестувати протягом кількох років створення комплексу для автоматизації банківської діяльності, розраховуючи окупити витрати продажем готового продукту. Але банки, навіть досить великі, сьогодні вже не можуть дозволити собі такої розкоші, оскільки прибуток від впровадження власної розробки у них принципово інша. У зв'язку з нестачею сил комплексу розробників банку не може охопити всі сфери його діяльності, і її робота нагадує, швидше, нагла латання дірок. У підсумку, банк, зайнятий поступовими доробками, не отримує бажаного результату. І чим більший банк, різноманітніше його бізнес і більше число філій, тим складніше йому створювати власне комплексне рішення. Сьогодні всі великі банки (з першої сотні), які раніше працювали на своїх системах, або вже придбали готові рішення російських і зарубіжних виробників, або перебувають у стадії з вибору. Таким чином, збільшення вимог банківського персоналу до комплексних рішень, значне ускладнення процесу розробки і впровадження професійного продукту на основі сучасних UNIX OC та реляціоннних СУБД, зниження прибутковості банківського бізнесу в порівнянні з минулими роками призвело до істотного зниження популярності власних розробок. [1]. Глава I. Автоматизовані технології в банківській діяльності. Впровадження електронних систем обробки і передачі інформації набувають універсальний і загальний характер, охопивши всі напрямки банківської діяльності. Сучасні інформаційні технології дозволяють координувати діяльність підрозділів банків, розширити міжбанківські зв'язки, діяти однократно на фінансових ринках ряду країн. Нові можливості автоматизації банківських операцій робочих місць фахівців, інформаційних технологій банківських послуг дозволяють комплексно вирішувати проблеми аналізу банківської діяльності, розробки і створення регіональних, міжрегіональних та міжнародних банківських систем. Автоматизація інформаційних і інших технологій банку сприяє рішенню стратегічних задач. Головними напрямками, за якими автоматизація обслуговування клієнтів впливає на конкурентну позицію банків, є зменшення витрат і збільшення якості обслуговування. Досягнення електронної техніки і технології запропонували принципово новий вид послуг - систему автоматизованого управління готівкою грошової маси. Ця система дає операційну інформацію про стан усіх банківських рахунків, дозволяє регулювати і прогнозувати рух грошових коштів, зменшити трудомісткість робіт з готівкою, переходити на безпаперову технологію. Позитивні аспекти безпаперовій технології: практично миттєва пересилання даних; унікальність зберігання; поліпшена захищеність; різке зменшення трудомісткості обробки документів. Рішення аналітичних завдань банківської діяльності диктується необхідністю визначення фінансових результатів, прогнозування напрямку розвитку, оцінкою економічної обгрунтованості і доцільності діяльності кожного банку. У вітчизняній практиці автоматизація аналітичних розрахунків утілюється поки в окремих програмних продуктах і ще не отримали широкого розподілу. На вітчизняному ринку сформувалися класи АБС, кожна з яких має визначених споживачів від починаючих банків, що здійснюють лише обмежений спектр карбованцевих операцій, до ведення банків, що вийшли на закордонний рівень обсягу і послуг. АБС містить необхідний споживачеві набір функцій. Основна маса пропонуємо на вітчизняному ринку АБС за вартістю і вимогам до обчислювальних засобів розрахована на середні і невеликі банки. Розширення систем відбувається, як правило, в тому випадку, якщо зростаючі запити споживача носять потенційно масовий характер для російських умов. Тому в міру росту фінансових можливостей банків можна чекати збільшення попиту на більш досконалі (багатоплатформений) системи, технічне і програмне забезпечення яке вимагатиме все зростаючою кваліфікації фахівців. Майже всі фірми - розробники містять нові версії АБС, узагальнюючі попередній досвід, орієнтовані на ті ж програмно-активні засоби, але з поліпшеною архітектурою і великим спектром можливостей. На ринку АБС немає єдиного магістрального напряму їх розвитку, а поява нових класів систем значною мірою визначається інтенсивністю та особливостями розвитку банківської справи в країні. [2]. Глава II. Особливості вітчизняних систем автоматизації банківських технологій. Актуально процеси автоматизації банківських технологій стали виявлятися в к.80-х-н.90-х рр.. Природним чином це було пов'язано з банківською реформою 1989р., Коли існуючі банки отримали велику самостійність і поряд з колишніми державними банками на ринку банківських послуг з'явилися нові комерційні банки. При цьому обчислювальні цифри, на яких здійснювалася обробка банківської інформації, уже не могли надати банкам весь спектр послуг, необхідних для зниження рутинної роботи і для аналізу і прогнозування фінансового стану банків. Розвиток процесу автоматизації діяльності банківських та інших фінансових структур призвело до появи різноманітних ІТ. Основна відмінність вітчизняної банківської інфраструктури ІТ від закордонної, з точки зору комп'ютерної платформи, - більш високий ступінь їх однорідності. Комп'ютерна банківська платформа - програмно-технічне оснащення рішення банківських задач на базі новітніх ІТ, включенню в себе конкретну методологію ведення банківської справи на визначеному професійному рівні. Частка витрат на автоматизацію в наших банків нижче, ніж у зарубіжних, де вона становить 10-15% всіх витрат. Вибір банками тих чи інших систем автоматизації пов'язаний, як правило, із співвідношенням ціна - надійність - продуктивність. Проблема ускладнюється при необхідності підтримати високошвидкісний обмін даними багатьма філіями, із клієнтами, іншими банками. У зв'язку з цим банкам доводиться планувати не тільки технічне оснащення, а й всю системну інфраструктуру ІТ. В інфраструктурі слід виділити 5 складових: інформаційне забезпечення (ІС) технічне оснащення програмні засоби системи зв'язку і комунікації (внутрішні та зовнішні) системи безпеки, захисту і надійності Склад ІВ, його організація визначається найпростіше складанням завдань. Найбільш традиційні завдання, рішення будь-яким банком,-операційна (розрахунково-касова) діяльність. При такому підході банківська технологія будується на програмному продукті "Операційний день банку" (ОДБ), а впроваджуваний комплекс задач дозволяє проводити операційний аналіз діяльності банку за будь-предметний відпрацювань часу. Для забезпечення комплексності автоматизації банківської діяльності потрібно ряд важливих програмних засобів і всі вони повинні бути інтегровані настільки, щоб при проведенні банківських операцій не було зайвих введення, набору, пересилань даних і т.д., а стан банку можна було оцінити на будь-який тимчасовий момент. Система "клієнт-банк" дає можливість клієнтові швидко вирішувати свої завдання спілкування з банком, минаючи операціоніста і не виходячи зі свого офісу. Автоматизація кредитування забезпечує не тільки автоматичний контроль за проходом платежів, а й, що найбільш можливо, прогноз на будь-який термін очікуваного в майбутньому стану банку. Ці функції автоматизуються в рамках комплектованих програм. "Ведення банківських договорів", на які накладаються численні аналітичні завдання з вирішення питання оптимізованого використання наявних у розпорядженні інформаційних банківських коштів. Рішення комплексів завдань з цінними паперами, діліт, біржові операції, організація міжбанківського обміну електронними копіями документів, аналітичні системи оцінки діяльності банку і його клієнтів і т.п., які в даний час автоматизовані далеко не повністю, повинні організаційно входити в комплексну систему організації діяльності банку. Вимоги, які необхідно враховувати при вирішенні задач автоматизації діяльності банку:. 1) ідеологія побудови системи повинна укладатися з урахуванням подальшого можливого розвитку банківських технологій, тобто аналіз завдань, що потребують вирішення СІ, має вестися з перспективою розвитку їх у найближчому майбутньому 2) впроваджувані технології повинні, по можливості рівномірно здійснити автоматизацію всіх сфер діяльності банку, що дозволить уникнути появи вузьких місць 3) має передбачатися відповідність програмних засобів автоматизації банківської діяльності наявності розгалужується мережі продажів, гарантійного обслуговування апаратних засобів, фахівців, які знають цю техніку 4) технологія повинна відповідати рівню розвитку суспільства, рівня розвитку банківських методологій: не відставати від загальних тенденцій розвитку, але і не забігати далеко вперед АБС - форма організаційного управління банком на базі основних теоретичних положень кібернетики та інформатики. АБС, спираючись на моделювання фінансово-кредитних операцій, впорядкування інформаційних потоків, застосування економіко-математичних методів, обчислювальної техніки та засобів зв'язку, зменшує трудомісткість і раціоналізує управлінську діяльність в банку, дозволяє розширити коло рішень завдань, збільшує аналітичність, обгрунтованість і своєчасність прийнятих рішень. Це досягається за рахунок нових ІТ - сукупність впроваджуваних у банківську практику цілісні принципово новітніх засобів і методів обробки даних, що представляють собою цілісні технологічні системи, що забезпечують формування, передачу, зберігання і відображення продукту з найменшими витратами. В основі АБС - нові інформаційні технології (НІТ), що реалізуються спільні технологічні моделі обробки даних,-термінологічні процеси, локальні і розподіляють мережі, системи машинної графіки, електронні пошти і т.п. Системний підхід є основоположним як при проектуванні НІТ, так і при вивченні та управлінні діючої інформаційної системи. Іншими важливими принципами є: інформаційна обробна зв'язок; декомпозиція; безперервний розвиток АБС, що передбачає оновлення і поповнення обчислювальної техніки, програмного забезпечення і технологій управління; АБС повинна нарощувати потужність, постійно розширювати і поповнювати БД; сумісність з іншими АБС; стандартизація та уніфікація при створенні та розвитку АБС; автоматизація інформаційних потоків та документообігу, що досягає шляхом виконання технічних засобів для збору, реєстрації, обробки даних, створення первинних і результативних документів, шляхом впровадження безпаперової технології, широкого використання засобів зв'язку для пересування банківської технології на будь-які відстані; ефективність (вибір найбільш раціоннальних проектних рішень, що підлягають впровадженню, і одержання економічного ефекту від витрат на створення АБС). Технологічна платформа АБС - вся сукупність апаратних засобів, мережевих і телекомунікаційних пристроїв та протоколів, ОС і СУБД, на яких функціонує АБС. [3]. Неправильний вибір платформи, особливо для багатофіліальних банків, може призвести до дуже дорогим і непередбачуваних наслідків. Вже існують інструментальні засоби, які переносять центр ваги при розробці інформаційної системи з програмування на проектування. Тобто в перспективі розробкою банку займається не програміст (людина, що вміє крок за кроком пояснювати машині, як вирішити задачу), а кваліфікований користувач - людина, що вміє сформувати, йому необхідно "на виході". Створення нової технології крім загальносистемних принципів вимагає врахування особливостей структури банківських систем і специфіки банківської діяльності. В основі НІТ полягає мережева архітектура, широке застосування ПЕОМ та формування на їх базі взаємопов'язаних спеціалізованих АРМів різних рівнів.

Життєвий цикл ІТ.

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

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

I-Зародження даної технології. Її розподіл невелика, але ефективність очевидна, тому масштаб використання збільшується.

II-Попит стійкий і випереджає пропозицію. Фаза прискорення зростання. Постійно пропозиція починає випереджати попит і настає III-уповільнення зростання. У період зрілості (IV) насичення попиту достатньо, а в V-настає спад, коли попит знижується і їй на зміну випливає інша, більш ефективна суспільна потреба.

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

ПК типу IBM AT-386SX/DX, IBM AT-486SX/DX, Pentium, робочі станції локальної обчислювальної мережі, термінали міні-ЕОМ та інші. Зміна технології у банках відбувається лише тоді, коли вона перестає приймати йому прибуток. Те, що використовується у великих західних банках, можливо, скоро буде замінюватися, тому що всі компоненти наближаються до останньої, укладає стадії життєвого циклу. Досвід останніх років це підтверджує. Наприклад, може служити аналіз технології використання для безготівкових розрахунків магнітних і електронних карт. На думку західних експертів, у Росії є унікальний шанс запровадити у себе відразу сучасну технологію, тому що у нас немає розвиненої інфраструктури з обслуговування магнітних карт.

Інформаційне забезпечення.

Інформаційне забезпечення АБС - інформаційна модель банку буває двох видів.

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

2) Внутримашинное ІС - надання даних на машинних носіях у вигляді різноманітних за створення, за призначенням і специфічним обробок органічних масивів (файлів), БД і їх інформаційних зв'язків.

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

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

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

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

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

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

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

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

Нова технологія вимагає інтеграції інформаційних процесів і, зокрема, організації інформації у вигляді сукупності баз даних. Існують різні інструментальні програмні засоби як для проектування, так і для управління та підтримки БД - це простіше за все різні СУБД: [* dBASE фірми Ashton-Jate Corp; * R: BASE файл Microrim Inc; * PARADOX файл Borlanol International; FoxBase і FoxPro файл Fox Software Inc та інші. Для російських банків характерним є використання прикладних банківських систем на основі перерахованих СУБД. Одні подібні програми оформлені тільки для необхідних банків, в яких відображається не більше 5000 документів щоденно. Тенденція ж до розширення банківських систем на обробку вісімдесят чи сотні тисяч документів щоденно в режимі реального часу, забезпечення гарантованої конфіденційності інформації в БД, високого ступеня безпеки і надійності БД робить необхідним застосування технології "клієнт-сервер", а для неї потрібні спеціальні СУБД. Сучасні СУБД, що реалізуються технологію "клієнт-сервер" при роботі з БД, - це складні і дорогі програмні продукти, тому вибір конкретних СУБД для банків повинен бути добре обгрунтований. Світовий ринок СУБД виділив лідерів - "велику четвірку": Oracle, Sybase, Informix, Indres. З інших доступних у нас можна назвати Progres, Gupta, Interbase.]

До внутримашинного ІС банківських систем представляється ряд вимог:

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

• Документи реалізуються в режимі реального масштабу часу, при якому зміни в даних, вироблені одним користувачем, відразу повинні ставати доступні іншим користувачам банківської системи;

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

• Система повинна забезпечити збереження цілісності інформації при відмові апаратури (дублювання інформації сервера БД).

Технічне оснащення рішення банківських задач.

Надання банківських послуг на основі комплексних систем може представляти у вигляді 3-х рівнів:

1) Різні банковсіе послуги, що передбачають виконання автоматів-касирів, пластикових карток та систем розрахунку в торговельних точках, а тільки послуги, пов'язані з обробкою і зберіганням грошових документів.

2) Послуги з управління грошовими операціями та їх контролю.

3) Діяльність РКЦ, автоматизованих розрахункових палат, міжбанківських розрахункових палат, клірингових центрів, створюваних декількома банками для забезпечення і прискорення взаєморозрахунків.

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

• засоби обчислювальної техніки;

• обладнання локальних обчислювальних мереж;

• засоби телекомунікацій і зв'язку;

• обладнання, що автоматизують роботу з готівкою (для підрахунку і підтвердження достовірності купюр і т.д)

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

Система "клієнт-банк" дозволяє банку та його клієнтам обмінюватися підписами і зашифрованими пакетами документів по телефонних лініях зв'язку. Вона складається з модуля "Банк", який встановлюється на комунікаційній ПЕОМ в банку, і модуля "Клієнт", встановленим на комп'ютері клієнта.

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

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

Програмне забезпечення АБС.

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

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

Наявність в спектрі базових засобів мережних функцій - неодмінний атрибут сучасних АБС (забезпечується многоуровненность, можливість об'єднання різних програмних платформ (DOC, "NetWare", Windows NT, UNIX та інші)).

Телекомунікаційні можливості базових засобів дозволяє перевести технологію міжбанківських розрахунків на принципово інший рівень за рахунок зменшення часу подачі документів. Це помітно розширить можливості банку.

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

Основною властивістю АБС з точки зору прикладних споживчих коштів є достатня широта функціонального набору.

Прикладні характеристики АБС, крім того, повинні відповідати вимогам інтегрованості, що конфігурується, відкритості і настроюваності системи.

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

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

Відкритість передбачає наявність коштів для розвитку та модифікації.

Сучасна методологія та інструментальні програмні засоби дають таку можливість (CASE-засоби) (для внесення змін без допомоги фірми-розробника)

Настроюваність необхідна для адаптації до технології конкретного банку.

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

Як щаблі, наступної за DOS-комплексами, можна розглядати системи, побудовані в архітектурі "Клієнт-сервер", в рамках "Novell Net Ware". Під сервером розуміється логічна процедура, яка забезпечить обслуговування надійшли до нього запитів. Клієнтами сервера є процедури ПЕОМ, що посилають серверу запити на той чи інший вид обслуговування. Завданням клієнта є:

1) встановлення зв'язку з сервером;

2) формування запиту конкретного виду на обслуговування;

3) отримання результатів;

4) підтвердження остаточного процесу обслуговування.

Наприклад, такої технології: мережеві бази даних з реалізацією стандартного структурованого мови запитів SQL.

Глава III. Системи автоматизації банківської діяльності за кордоном.

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

60-і рр.. - За допомогою ЕОМ зважувалися в основному задачі моделювання, оптимізації і планування, створення автоматичних архівів.

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

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

80-і рр.. - З'явилися високо виробничі міні-ЕОМ, автоматизація обробки банківської інформації на робочих місцях. На базі обчислювальних машин фірми DEC (США) стали створюватися системи автоматизації банківських офісів, які можуть інтегруватися в більш великі.

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

Лідери в партнерстві: IBM (США), DEC (США), "Siemens" (Німеччина), "Oliwetti" (Італія), "Bull" (Франція).

IBM: пропонує друге покоління машин AS/400 з сучасною операційною системою OS/400, яка забезпечує захищеність даних, підвищує продуктивність системи і користувача як у пакетному, так і в діалоговому режимах при роботі в мережах різноманітних конфігурацій.

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

Система IBIS / AS охоплює весь банк зі спеціальною функціональною підтримкою кожного відділу у відповідних модулях, що сформовані в 2 групи:

1) "Банківські" центральне місце "Головна бухгалтерія"

банківські функціональні модулі

2) Допоміжні модулі ("Архівація", "Аудиторські перевірки", "Інтерфейс SWIFT" і ін)

DEC (США). За участю цієї фірми головним розробником міжнародної компанії "Werter Perters" була створена міжнародна банківська система 90-х рр.. IBS-90. Компанія "Werter Pertners" протягом 20 років одна з лідируючих постачальників систем для світового фінансового суспільства, активно працює в багатьох країнах світу.

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

Спільно з розробками "Cilidak of America" ​​і спеціалізованою компанією ITB фірма DEC розробила банківську платформу майбутнього - FSA. Розроблені на базі FSA системи в даний час встановлені в 10 великих світових фінансових центрах, включаючи Лондон, Нью-Йорк, Гонконг.

Для універсального банку фірма DEC створила ще одну банківську платформу-"Profile". Вона допускає генерацію і настроювання трьох типів систем під конкретні вимоги замовників (власне інтегрованої банківської системи, що автоматизує усі види роздрібних послуг; ІС управління фінансами; системи автоматизації діяльності банку на вторинних ресурсах).

"Siemens" (Німеччина) - багатокористувальницька ОС "Sinix" (UNIX виробництва "Siemens"), що забезпечує розподіляє обробку даних і реалізують ефективну і економічну технологію об'єднання робочих місць в одиниці ЛС. Пропонує діалогову систему KORDOBA. Це спеціальне банківське програмне забезпечення реалізує всі операції у всіх відділеннях з першого робочого місця. Це пакет програм модульної структури, що включає податкову, інформаційну й організаційну частини. Особливу увагу у фірмах приділено вірогідності інформації і надійності прийнятих рішень.

"Olivetti Systems Networks (OSN)" пропонує свою "банківську платформу" (Platform for banking - PB) для автоматичного банку ("Automatic banking"). Це комплексне рішення, що відповідає тенденції побудови відкритих систем, забезпечить створення гнучкої і здатною до розширення системи банківських установ, реалізацію повного набору банківських функцій у середовищі розподіляють послуг і додатків в умовах ЛС і можливість виходу в ГС.

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

"Bull" створила міжбанківську систему телерасчетов STT для прискорення міжбанківських операцій, забезпечення безперервності обміну міжбанківськими повідомленнями, зменшення їхньої вартості.

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

Глава IV.Інтегрірованная Банківська Система "STEM".

I. Концепція і принципи побудови.

Загальні вимоги до ІХС.

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

1. Розрахована на багато користувачів система реального часу.

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

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

2. Захист інформації.

Відповідність системи міжнародним вимогам щодо захисту інформації забезпечується наступним чином.

• засобами апаратного забезпечення: використання систем апаратного шифрування, апаратної ідентифікації і аутентифікації (справжності), електронних ключів і т.д.;

• засобами операційної системи: використання ОС із сертифікованими засобами захисту інформації та розмежування доступу (UNIX, VMS);

• засобами СУБД: використання професійних СУБД з сертифікованими засобами розмежування доступу до інформації та засобами аудиту та журналізації;

• прикладним програмним забезпеченням: розмежування доступу до інформації, ведення журналу всіх операцій, контроль роботи активних користувачів системи, електронний підпис і засоби криптографічного захисту даних;

• організаційними заходами: інструктаж користувачів, технологія породження та передачі ключової інформації.

3. Цілісність інформації.

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

• засобами апаратного забезпечення: системи безаварійної роботи, застосування RAID-технології, застосування кластерних технологій тощо;

• засобами СУБД: використання професійних СУБД з двохфазові механізмами транзакцій, з можливістю on-line-резервування;

• організаційними заходами: інструктаж користувачів, резервування інформації.

4. Гнучкість і настроюваність системи.

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

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

Розвиток ІХС.

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

Вибір перспективних технологій і методу реалізації ІХС.

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

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

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

Опис елементів банківської системи.

Апаратна платформа.

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

При виборі платформи слід, перш за все, визначити реальне число користувачів, які мають бути одночасно підключені до розрахованої системі. Орієнтовно можна виходити з наступної оцінки: на одного користувача прикладного ПЗ потрібне 1МБ ОЗУ і 1 tps / A загальної продуктивності системи (tps-число транзакцій в секунду). Крім того, необхідно оцінити перспективи зростання банку та його фінансові можливості.

Кількість користувачів, що активно працюють на ІХС в реальному банку з продуктивністю до 2 000 операцій на день, не перевищить 20-30.

Таке навантаження цілком під силу системам на базі INTEL 486DX2/66 і Pentium/60, 90, що забезпечує наскрізну продуктивність 15-30 tps / A і 30-60 tps / A відповідно.

При активному підключенні філій або створення виносних операційних залів, що працюють у режимі on-line, число активних користувачів може бути доведено до 100 і більше, а кількість операцій досягати 10 000. У такому випадку необхідно орієнтуватися на системи класу midrange. Це може бути RISC-система (HP, Sun, IBM) або багатопроцесорна система на базі Intel 486 і Pentium (Corollary, Acer, Compaq, AST, ALR, Sequent, Unisys і т.д.). Не можна забувати про такі популярних (на заході) масштабованих системах, як AS/400 (IBM), VAX (DEC) і т.д. Важливим для нашого ринку може виявитися політика активного зниження цін на процесори INTEL і анонсування процесорів Pentium/150 з продуктивністю 250 MIPS і в 1995 році - P6 з продуктивністю 300 MIPS.

При покупці системи необхідно переконатися в наявності сертифікату ОС і СУБД, які використовуються в банку.

Операційна система.

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

Тому в основному використовуються РС-сумісні комп'ютери під управлінням DOS або Windows, з'єднані локальною мережею NetWare. При зовнішній простоті і привабливості таке рішення має ряд істотних недоліків:

1. DOS, Windows і NetWare не відповідають вимогам "надійності" захисту інформації та розмежування доступу згідно Trusted Computer System Evaluation Criteria ("Помаранчева Книга"). У світовій практиці ОС, що не пройшла такої сертифікації, не рекомендується до використання у фінансових установах.

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

3. Багатокористувальницьке ОС (UNIX, VMS та ін) в порівнянні з PC LAN значно простіше й ефективніше інтегруються в глобальній мережі. Це істотно при необхідності забезпечення режиму роботи on-line для філій і відділень, особливо на низькоякісних і ненадійних лініях передачі.

Специфічні вимоги банківських додатків дуже скоро зажадає переходу до більш мобільним і захищеним ОС. Сучасні ОС, як правило, переносяться (UNIX, Windows NT) або забезпечують роботу додатків на ряді комп'ютерів, масштабованих по продуктивності (VAX, AS/400).

Важливим фактором може виявитися наявність фахівців з установки, конфігурування ОС відповідно до вирішуваних задач. Оптимальним вибором є OC UNIX.

UNIX - розрахована на багато багатозадачна ОС, яка реалізована практично на всіх платформах і підтримує стандарт відкритих систем POSIX для переносимих ОС. Її важлива особливість - захищеність системи і даних від несанкціонованого доступу. Використання стандартних протоколів дозволяє спільно експлуатувати мережу Ethernet, OC NetWare, UNIX і, таким чином, здійснювати "м'який" перехід з однієї ОС в іншу.

Зв'язок ОС з 3GL рівнем зумовлює необхідність придбання середовища розробки (редактор, компілятори С і С + +) для даної ОС.

3 GL-підтримка.

До 3GL (3 Generation Language) - підтримці відносяться практично всі звичні інструментальні мови - С, С + +, Pascal, Modula і т.д. На цей рівень виносяться кошти, необхідні банківській системі, але не реалізовані штатними засобами СКБД. До них можуть відноситися системи цифрового захисту даних і т.п. Для максимального використання цього рівня необхідно наявність розвиненого інтерфейсу з мовами третього покоління в передбачуваній СУБД.

СУБД.

У описуваної ієрархії СУБД займає особливе місце:

• Як правило, за рахунок переносимості СУБД здійснюється переносимість ІХС на різні комп'ютерні платформи.

• У рамках однієї платформи важлива переносимість на різні ОС, наприклад, за схемою DOS -> NetWare -> INIX.

• Як правило, банківська система жорстко прив'язана до конкретної СУБД і, вибираючи ІХС, користувач повинен розглядати її як частину системи. При цьому не можна скидати з рахунків цінову політику фірми-виробника СУБД. У деяких випадках вартість ядра бази даних може істотно перевищувати вартість прикладного ПЗ.

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

При виборі необхідно орієнтуватися на СУБД, що реалізують технологію клієнт-сервер і дозволяють створювати додатки, які працюють в розподілених гетерогенних мережах. До таких СУБД, зокрема, відносяться ORACLE, Informix, PROGRESS, Sybase, Ingres і т.п.

Існує СУБД PROGRESS. Це переносима СУБД з 4GL-засобами для створення додатків. Вона забезпечує побудову систем архітектури клієнт-сервер і включає модулі створення додатків, інструментальні засоби підтримки, утиліти і середовищем виконання (run-time).

Це многосвязанная багатокористувацька система з інтегрованим словником даних, рівень захищеності і підтримкою широкого діапазону комунікаційних протоколів - TCP / IP, NetBIOS, SPX / IPX, SNA, DECNet, TLI, OSI і ін

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

Переносимість PROGRESS - одна з її сильних сторін. Можливість створення додатка на одній платформі і перенесення на іншу, незв'язану, платформу без єдиного зміни програми надає інсталяційного продукту значну гнучкість. PROGRESS підтримує 400 платформ, включаючи VAX; широкий діапазон систем UNIX, включаючи SCO UNIX SVR4, AIX, HP-UX, ULTRIX, CTOS, NetWare, OS / 2 і PC / DOS; і OS/400 популярних AS/400 середнього класу фірми IBM . [4].

PROGRESS підтримує транспортний доступ до DBMS:

- ORACLE - Object Store

- RMS (OOODBMS)

- SYBASE - DB2

- Rdb / VMS - Allbase

- OS/400 - ODBC

- C-ISAM - CT-ISAM

II. Інтегрована банківська система «STEM». Ядро системи. Менеджер Рахунків (Account Manager).

"Робіть правильно з самого початку".

У. Кеуффель

Характеристика завдань, що вирішуються Ядром ІХС.

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

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

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

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

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

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

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

Ядро банківської системи ІХС «STEM», крім описаної вище проблеми, вирішує наступні завдання:

- Переносимість і масштабованість рішень для центрального офісу та філій;

- Захист і цілісність інформації;

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

- Відпрацювання транзитних платежів;

- Зв'язок з клієнтами через вбудовану, повністю автоматизовану систему «Клієнт - Банк»;

- Можливість методологічного проектування;

- Забезпечення переходу на безпаперову технологію;

- Максимально спрощене впровадження;

- Можливість розширення системи без участі розробників.

Використання СУБД PROGRESS дозволяє вирішувати питання переносимості, функціонування в різних ОС і на різних платформах, побудови гетерогенних мереж та реалізації технології клієнт-сервер.

Характеристики та особливості Менеджера Рахунків.

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

Важлива особливість системи - датонезавісімость. На будь-яку дату в минулому і майбутньому можна отримати повністю актуальний стан системи. Ця особливість виявляється корисною як на етапі впровадження, так і для задач типу «Грати, що якщо ...» («Play what if ...»), наприклад, при розрахунку та аналізі виплат відсотків і резервування для цього коштів і т. п.

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

Рахунок.

На рівні Менеджера рахунків вирішуються всі задачі по обслуговуванню рахунків: відкриття, закриття рахунків, рух коштів по рахунках і т.п.

Рахунок і системі дозволяє вести облік по одному з видів фінансової діяльності. Система рахунків має ієрархічну структуру, тобто деяка група рахунків належить іншому "рахунку-господаря". Останні, у свою чергу, можуть групуватися і мати підпорядкованість третьому і т.д. Усі рахунки поділяються за рівнями. Рівні відображають ієрархію рахунків. Належність рахунків деяким рівнями збігається з необхідністю відкривати рахунки згідно з Планом рахунків бухгалтерського обліку. ІХС «STEM» забезпечує проектування Плану рахунків з будь-якою кількістю рівнів.

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

Зв'язок Власника рахунків і Платіжних систем.

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

Залишки на рахунках.

Залишок - це кількісний еквівалент грошових коштів на рахунку в системі рахунків. Залишок на активному (А) рахунку визначає платоспроможність власника рахунку (власні кошти). Як правило, це Банк. Залишок на пасивному (П) рахунку - заборгованість (зобов'язання та капітал) власника, наприклад, перед клієнтом Банку. Рух коштів по рахунках - зменшення або збільшення залишку - підрозділяється на Дебетове і Кредитове. З поняттям залишку пов'язане поняття оборотів за Банківський день. Обороти характеризують активність рахунки, залишок - результат діяльності. Як видно зі схеми № 1, дебетове рух збільшує залишок для Активного рахунку і зменшує для пасивного. Використання знакового залишку призводить до того, що дебетове рух зменшує залишок рахунків А і П, але для П збільшує абсолютне значення залишку. Схема роз'яснює вплив руху коштів по активних і пасивних рахунках і формалізує алгоритм зміни залишків.

Зміна знаку залишку призводить до зміни рахунку А на рахунок П, що суперечить змісту поділу рахунків на А і П. У бухгалтерських термінах така зміна знака називається «червоне сальдо».

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

Перша схема - всі рахунки або тільки активні або пасивні.

ГІДНОСТІ:

- Простота, тобто однаковий алгоритм для А і П, один знаковий залишок, два значення для обертів;

- Можливість поділу оборотів за активами і за пасивами;

- Можливість емуляції другої схеми використанням двох рахунків.

НЕСТАЧА:

• проблеми з впровадженням [існує практика використання АП-рахунків].

Друга схема - Допускається використання АП-рахунків.

ГІДНОСТІ:

- Емулює першу схему обмеженням зміни знаку залишку;

- Немає проблем з впровадженням (методологічно опрацьовано).

НЕДОЛІКИ:

- Інформаційна надмірність (2 без знакових залишку для одного рахунку);

- Принципово неможливо поділ оборотів за активами і пасивами.

У описуваної системі (ІХС «STEM») використовується другий метод.

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

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

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

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

Підтримка одновалютной або Багатовалютний систем обліку валютних операцій.

ІХС «STEM» підтримує два методи обліку валютних операцій:

- По курсовому еквіваленту у національній валюті (при цьому перерахунок здійснюється в момент здійснення операції);

- Безпосередньо у валюті, що бере участь в банківській операції.

Одновалютні система обліку.

Інформація про валюту зберігається як довідкова і необхідна для переоцінки валютних коштів («курсова різниця»), одержання валютного балансу.

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

ГІДНОСТІ:

- Регламентується інструкцією Міністерства Фінансів;

- Методично опрацьовано (форми документів) та зрозумілий бухгалтерам;

--- Немає проблем з впровадженням.

НЕДОЛІКИ;

- Для кожної валютної операції потрібно перерахування за обліковим курсом;

- При зміні курсів валют виникає необхідність актуалізації залишків, що вимагає великих витрат;

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

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

Багатовалютна система обліку.

Всі валюти рівноправні.

ГІДНОСТІ:

- Всі операції відбуваються безпосередньо у валюті, в них бере участь; основним результатом діяльності є валютний Баланс;

- Перерахунок за курсом відбувається тільки при приведенні балансу до однієї валюти (наприклад, національної) для складання звітності або аналізу діяльності;

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

Реалізація підтримки цілісності Банківських операцій.

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

Для залишків на рахунках і балансів:

- Проводка допускається тільки по двох рахунках одночасно;

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

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

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

--- На момент здійснення операції автоматично породжується історія по залишкам (по всіх рівнів);

- Проводка дозволена одночасно лише одному користувачеві (обмеження призводить до реальної продуктивності 1000 операцій на годину) і блокується при формуванні твердої копії фінансових результатів (балансу) - властивість всіх систем реального часу;

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

---- Здійснюється перевірка на достатність залишку для здійснення операції («червоне сальдо») як на дату здійснення операції, так і вперед з історії (якщо така є, наприклад, якщо проводка здійснюється заднім числом); характерно на етапі впровадження системи;

- Дозволяється / забороняється «червоне сальдо» (з журналізація операцій, наведених на «червоному»);

- Для валютних рахунків (тільки по одновалютной методу):

• проводки дозволені тільки у валюті; у національній валюті дозволена проводка тільки за операції «переоцінка»;

• потрібно визначення основного курсу для перерахунку в національну валюту (зазвичай курс національного Банку);

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

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

Для зв'язку з верхнім рівнем Ядра ІХС «STEM» - рівнем технологій, реалізований інтерфейс у вигляді наступних системних операцій:

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

Відкат проводки (операція, обернена до проводці) двох видів:

1) з проводки без документа (для введення залишків), використовується на етапі налагодження і впровадження;

2) по документу.

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

Введення залишків на рахунку можливий в наступних варіантах:

- Введення залишків в національній валюті в пакетному режимі; увазі наявність балансу по завершенню операції і використання «Операційного дня», з якого можливий експорт інформації про залишки на особових рахунках у текстовий файл і імпорт в ІХС «STEM» (обмеження продуктивності -1500 операцій в годину по введенню залишків);

- Введення валютних залишків у діалозі за інформацією про залишки у національній валюті на особових рахунках з контролем цілісності балансу (для обох методів обліку операцій у валюті);

- Введення валютних залишків у пакетному режимі (шляхом імпорту).

Підтримка впровадження системи в реальному часі.

Система дозволяє використовувати методику «м'якого» впровадження в банку та поетапного витіснення (заміщення) існуючого ОДБ, починаючи від апаратної платформи і закінчуючи впровадженням ІХС. При цьому впровадження можливе без зупинки банку при одночасному введенні залишків, здійсненні операцій і паралельному функціонуванні двох систем. Однак, це підвищує вимоги до підготовленості персоналу і збільшує завантаженість фахівців на весь термін впровадження. На даний момент розроблені утиліти переходу від ОДБ «БАРС» для передачі інформації про клієнтів, рахунки, залишки в ІХС «STEM» і вивантаження документів дня з ІХС «STEM» в ОДБ «БАРС». Крім того, з системі передбачена можливість переходу від одновалютной системи обліку валютних операцій до Багатовалютний. [5].

III. Технологічна система ІХС "STEM".

"Ми пливемо вгору за течією,

борючись з величезним потоком

дез організованості ... "

Норберт Вінер, 1956 р.

Цей розділ присвячений технології і всьому, що з нею пов'язано в контексті автоматизації. У поняття «технологія» вкладається його первинний сенс, який визначається значенням самого слова. У перекладі з грецької технологія - наука про майстерність (уміння). На мою думку, рішенням технологічних питань зараз приділяється недостатньо уваги як у самих комп'ютерних системах, так і в організаціях, що експлуатують ці системи. У багатьох випадках технологічні питання взагалі не вирішуються, вірніше вирішуються якось самі собою. Іншими словами, має місце технологічний безлад. Тому поряд з первинним глуздом поняття «Технологія» мимоволі з'являється другий зміст - організованість роботи.

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

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

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

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

- Складні технології одержання продукту;

- Велика кількість продуктів, що одночасно знаходяться в активній фазі (запущені в роботу, але ще не закінчаться);

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

- В технологічному процесі задіяний і велике число співробітників;

- Робочі місця рознесені територіально;

--- Висока ціна оптики за випуск неякісного продукту.

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

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

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

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

Розглянемо конкретну реалізацію цих ідей у ​​ІХС «STEM» на прикладі обробки платіжних документів. Технологічні можливості системи мають статус базових, що відображено в її структурі. Як говорилося в першій частині (I), технологічна система виділена в самостійний рівень, розташований між системою управління рахунками (II) і прикладним рівнем. Технологічна система є останнім, зовнішнім рівнем ядра «STEM». Прикладне оточення безпосередньо базується на технологічній системі і працює через неї. Технологічна інформація міститься в системі у вигляді даних, а не у вигляді програмного коду. Ці дані формалізовані, локалізовані і доступні користувачам.

Базовими поняттями в «STEM» є технологічна операція і технологічний процес.

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

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

Технологічна система гарантує для кожного документа (примірника продукту) індивідуально, що:

• все, що з ним має бути зроблено - буде зроблено;

• не буде зроблено нічого зайвого;

• всі операції будуть виконані в певній послідовності, з урахуванням їх взаємного впливу;

• всі дії будуть виконані певним персоналом;

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

Технологічний процес є, крім усього іншого, своєрідним планом обробки документа. Наявність в «STEM» такої інформації дозволяє системі в кожен момент часу "знати":

- Що, коли і ким зроблено, а також результати цих дій,

- Що, коли і ким має бути зроблено;

- Що, з того, що повинно бути зроблено, ще не зроблено і з якої причини.

При цьому система може виконувати дуже цікаві функції типу «Зробити все, що не зроблено» або «Зробити щось з усім, що не зроблено» або «Переглянути, чому не зроблено все, що не зроблено» і т.п.

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

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

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

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

Отже, технологічна система ІХС «STEM» породжує і супроводжує персональний технологічний процес для кожного документа. Наприклад, якщо в активній фазі знаходиться тисяча платіжних документів, то в «STEM» є тисячі незавершених технологічних процесів. Кожен з них є незалежним і обслуговується системою окремо. При цьому одні технологічні процеси можуть працювати швидше інших в залежності від зовнішніх умов.

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

У більшості випадків при роботі з ІХС «STEM» буває достатньо виконання запиту «Отримати всі документи, для яких не виконана задана операція». Наприклад, можна отримати всі виписані касові документи, які не пройшли через касира. У результаті адміністратор отримує доступ безпосередньо до шуканим документами (із зазначенням причини не обробки по кожному) і може прийняти рішення по кожному окремо чи за всіма. Широко застосовується сьогодні в банках метод підрахунку

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

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

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

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

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

Можливість відкоту технологічних процесів спільно з незалежністю від дати ІХС «STEM», про яку говорилося у другій частині (II), дозволяє вирішувати задачі типу "Play What if ...". При цьому співробітник банку може здійснити операцію і подивитися, як ця операція в майбутньому, наприклад через місяць, відіб'ється на стані банку. Після завершення експерименту операція може бувальщина скасована.

Повернемося до платіжних документів ІХС «STEM». При створенні нового документа, незалежно від того, який прикладний процес його створює (ручне введення або обслуговування комунікаційних каналів, макрогенератор, імпорт і т.д.), система будує для нього унікальний технологічний процес.

Технологічний процес для документа будується на основі базових технологій, результатів аналізу документа і параметрів налаштування системи. У «STEM» технологічний процес є віртуальним методом для платіжного документа.

Особливу роль у системі відіграють базові технології, які становлять суб'єктивні технологічні знання, які зберігаються у вигляді даних. Таким чином, «STEM», з технологічної точки зору, є відкритою для користувача системою.

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

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

У «STEM» включені багатофункціональні обробники, на базі яких користувачі можуть самостійно будувати різні технологічні операції. Крім того, якщо це необхідно, додаткові обробники можуть бути дописані на PROGRESS 4GL з використанням спеціальних угод.

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

Розберемо докладніше роботу з універсальними обробниками. Тривіальним є порожньою обробник - процедура «NUL», яка нічого не робить. Створимо на основі цієї процедури ручну операцію «Віза на відправлення платіжного повідомлення». Ця операція нічого з документом не робить, але важливо сама наявність цієї операції в технологічному процесі та її вплив на інші операції. Тепер можна сказати, що операція «Відправлення платіжного повідомлення» виконується тільки після виконання операції «Віза на відправлення платіжного повідомлення» і дати право на виконання операції «Віза ...» певного співробітнику або групі.

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

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

Список використаної літератури: