Кафедра економічної кібернетики

Контрольна робота

з курсу:

“Системи обробки економічної інформацій ”

Вступ

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

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

1. Нарахування операційних комісійних та процентних доходів та витрат від операцій з клієнтами, на основі АБС "Операційний день банку"

1.1 Постановка задачі

Розробка програмного забезпечення АРМ "Операції по договорам" у складі АБС "Операційний день банку".

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

1.2 Організаційно-економічна сутність задачі

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

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

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

До операційних доходів і витрат Банку належать:

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

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

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

Основними принципами бухгалтерського обліку доходів та витрат є:

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

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

Банк застосовує такі схеми відображення визнаних/отриманих (сплачених) доходів/витрат у бухгалтерському обліку:

– через рахунки нарахованих доходів/витрат (2048, 2068, 2078, 3570 тощо);

– шляхом прямого віднесення доходів/витрат на відповідні рахунки 6 і 7 класу.

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

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

– у разі виконання одночасно таких умов:

1. дата нарахування та дата сплати клієнтом винагороди Банку співпадають,

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

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

1. дата нарахування та дата сплати клієнтом винагороди Банку співпадають,

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

Комісійна винагорода може відображатися в обліку методом прямого віднесення на рахунки 6 класу.

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

Порядок перенесення нарахованих доходів на відповідні їм рахунки прострочених нарахованих доходів (2049, 2069, 2079, 3579, тощо) один для всіх доходів Банку: через сім робочих днів після закінчення строку сплати, передбаченого відповідною угодою.

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

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

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

– "факт/факт", тобто за фактичну кількість днів у місяці (28,30,31) та році (365).

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

При розрахунку процентних доходів та витрат враховується перший день і не враховується останній день договору (контракту).

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

1.3 Основні вимоги до програмного забезпечення АРМ "Операції по договорам"

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

1. Функціональні можливості АРМ повинні дозволяти виконання в автоматичному режимі основних операцій, необхідних для повного і правильного нарахування операційних комісійних та процентних доходів та витрат від операцій з клієнтами.

2. Базове (системне) програмне забезпечення повинно дозволяти роботу в реальному часі, і допускати проведення в великій кількості операцій введення/виведення, читання, друкування.

3. Базові програмні засоби повинні забезпечувати перенос пакета прикладних програм на нові апаратні платформи, без будь-яких в них змін.

4. Прикладні програмні засоби повинні забезпечити взаємодію з існуючою БД.

5. Управління АРМ повинно бути простим і наглядним, а робота з використанням АРМ повинна знижувати кількість помилок яких може припуститися операційний працівник.

6. Апаратна реалізація системи повинна бути достатньо простою і ефективною по вартості.

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

1.4 Склад функціональних задач АРМ "Операції по договорам"

Основною вимогою до АРМ "Операції по договорам", з точки зору потреб споживачів, є автоматизоване виконання комплексу робіт, пов'язаних з нарахуванням операційних комісійних та процентних доходів та витрат від операцій з клієнтами.

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

– підрахунок кількості операцій, за здійснення яких банк нараховує фіксовану суму комісійних (кількість документів відправлених через СЕП, тощо) в розрізі клієнтів;

– визначення суми залишку на який нараховується відсотки (вхідний, вихідний, середньоденний, тощо);

– можливість редагування тарифів і відсоткової ставки в залежності від зміни умов договорів;

– перерахунок комісійних доходів від операцій з іноземною валютою (видача готівкової іноземної валюти з поточних рахунків суб'єктів підприємницької діяльності) в гривневий еквівалент по курсу НБУ на день здійснення операції;

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

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

– формування відомостей нарахованих сум комісій та процентів;

– автоматичне формування в ОДБ проводок по нарахуванню і сплаті доходів та витрат;

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

Згідно інструктивним матеріалам НБУ процес нарахування та взискання відсотків повинно здійснюватися в два етапи:

1) нарахування розрахованої суми на рахунках доходів/витрат;

2) погашення нарахованих відсотків. Всі тарифи повинні бути розділені на наступні логічні:

Комісії:

1. по кількості документів;

2. по сумі обороту.

Крім того, повинно бути відокремлено специфічний тариф "Плата за послуги та операції".



Рис.2.1. Функціональна схема АРМ “Операції по договорам”

Нарахування на залишок на рахунку:

1. за вхідний або вихідний;

2. по способу розрахунку -

– простий;

– среднедньоденний;

– незнижувальний.

Важливою особливістю проектуемого АРМ є створення дружнього інтерфейса системи з користувачем, враховуючого його рівень підготовки і можливість самонавчання. На рис.2.1 представлена функціональна схема АРМ "Операції по договорам".

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

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

Розрізняють внемашинне і внутрймашинне інформаційне забезпечення.

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

Вхідними документами при введення електронних договорів і розрахунку доходів та витрат є:

– договори на розрахунково-касове обслуговування;

– депозитні договори;

– розпорядження кредитних інспекторів.

Склад вихідних документів наступний:

– меморіальні документи по нарахуванню та сплаті;

– відомість (журнал) нарахувань.

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

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

1. Найменування схеми;

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

3. Період ставки - період, на який встановлена ставка (необхідно вказати кількість днів, яка буде враховуватися під періодом при розрахунку відсотків, становлених на місяць: фактичне або 30, логічно - на рік : 360 або 365);

4. "Дни в расчете"- календарні (всі дні заданого періоду) або банківські (тільки робочі дні);

5. "Тип залишку" - по яким залишкам розраховувати - по вхідним або вихідним;

6. "Методика розрахунку" -

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

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

– незнижувальний залишок - з усіх днів періоду вибирається min залишок.

7. Формула - опис умов оплати.

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

1. Схема нарахування.

2. Номер договору.

3. Період дії договору.

4. Вид документа.

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

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

– простоту та зручність роботи;

– відповідні умови доступу до підбаз з урахуванням санкціонованого доступу до даних;

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

Типові форми вихідних документів наведені в Додатках А, Б, В, Д.

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

1.6 Автоматизована технологія розрахунку операційних доходів та витрат

На рис.2.2 представлена структурна схема автоматизованої технології розрахунку операційних доходів та витрат.

Рис.2.2 Структурна схема автоматизованої технології нарахування операційних доходів та витрат від операцій з клієнтами.

1.7 Апаратне забезпечення АРМ "Операції по договорам"

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

До особливостей АРМ "Операції по договорам", які повинні враховуватися при його технічному оснащенні, відносяться наступні фактори:

– робота в реальному часі;

– великий обсяг обробляємої інформації.

На основі віщевикладеного можливо запропонувати наступний склад апаратних засобів:

– IBM совместимий персональний комп'ютер на базі мікропроцесора Pentium з тактовою частотою min 166 МГц (200 МГц) з платою мережі;

– обсяг оперативної пам'яті 32МБ;

– накопичувач на жестком магнітному диску, місткістю не менше 1,0 Гб;

– струйний або лазерний принтер;

– блок безперебійного живлення;

– пристрій приймання/передавання даних на сервер на основі мережі.

Блок-схема технічної бази " АРМ "Операції по договорам" наведена на рис.2.3



Рис.2.3 Блок-схема технічної бази " АРМ "Операції по договорам

1.8 Перелік та опис основних АРМів

АРМ "Операції по договорам" повинен бути повністю сумісним з іншими АРМами, які входять до складу АБС "Операційний день банку": АРМ "Бухгалтера", АРМ "Менеджер клієнтів", АРМ "Касові операції", ATM "Звітність та аналіз", АРМ "Кнфігуратор системи", АРМ "Адміністратор системи" та інші.

АРМ "Бухгалтера" - призначений для управління банківськими рахунками та інформацією про клієнтів банку.

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

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

АРМ "Менеджер клієнтів" - призначений для найбільш ефективного обслуговування клієнтів безпосередньо операціонистом або менеджером.

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

АРМ "Касові операції" - дозволяє організувати оперативний контроль за операціями з готівкою та проводити швидку підготовку касової звітності.

Дозволяє вести електронний документообіг касових документів незалежно від місцязнаходження каси та знизити до min витрати часу на закриття каси в кідці дня.

Формує різноманітні касові журнали і форми звітності як внутрішньобанківські, так і для НБУ.

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

АРМ "Звітність та аналіз" - призначений для підготовки форм звітності в НБУ, органи ДПА і Статистики як по одному підрозділу, так і по банку в цілому.

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

На базі модуля побудовано блок розрахунку аналітичних показників згідно з Інструкцією про порядок регулювання діяльності банків в Україні, затвердженої Постановою Правління НБУ 28.08.2001 р . № 368..

Має встоєні засоби побудови податкових декларацій, ведення архіву і консолідація даних файлів.

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

АРМ "Адміністратор системи" - призначений для розподілу доступу користувачів до системи і об'єднання користувачів в групи. Дозволяє Адміністратору швидко і легко підключити користувача до необхідних ресурсів системи.

2. Система управління базою даних (СУБД), її основні функції

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

Загалом базу даних можна визначити як сукупність елементів, організованих згідно з певними правилами, які передбачають загальні принципи опису, зберігання і маніпулювання даними незалежно від прикладних програм. Зв'язок кінцевих користувачів (прикладних програм) з базою даних відбувається з допомогою СУБД. Остання являє собою систему програмного забезпечення, яка містить засоби обробки мовами баз даних і забезпечує створення бази даних та її цілісність, підтримує її в актуальному стані, дає змогу маніпулювати даними і обробляти звернення до БД, які надходять від прикладних програм і (або) кінцевих користувачів за умов застосовуваної технології обробки інформації. До складу мов бази даних, які використовуються для вивчення і звертання до даних, належить мова опису даних (МОД) і мова маніпулювання даними (ММД).

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

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

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

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

Заслуговує також на увагу особливість процесу «Здобування і захоплення» даних у СППР на відміну від більш загального процесу збору даних із джерел. Природа СППР потребує, щоб процес здобування (і СУБД, яка керує цим процесом) був достатньо гнучким, аби швидко обслуговувати доповнення та зміни згідно з непередбаченими запитами, які надходять від користувачів. Для процесу «Здобування і захоплення» даних у сучасних СППР широко застосовуються програмні (інтелектуальні) агенти, а також, як уже зазначалося, сховища даних.

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

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

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

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

Рис. 1. Підсистема даних СППР

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

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

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

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

Системи управління базами моделей (СУБМ), як узагальнені програмні засоби, забезпечують користувачам широкий набір моделей і дають змогу проводити гнучкий доступ, оновлення та зміну бази моделей.

Основні функції СУБМ такі:

- створення нових моделей;

- каталогізація і оцінювання широкого діапазону моделей;

- зв'язування компонентів моделей у базі моделей;

- інтеграція складових елементів моделей;

- « виконання набору загальних функцій управління СУБМ.

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

Значна частина програмного забезпечення СУБМ має формат електронних таблиць. Зокрема, пакет Super Calc 2, версія 3, створений на основі електронних таблиць другого покоління, надає користувачеві можливість доступу до широкого діапазону математичних операцій з різними елементами в клітинках електронних таблиць; шляхом обробки стовпців як послідовних часових інтервалів можна також моделювати систему змінних в часі; забезпечуючи розв'язування задач за допомогою аналізу рішень та інструментів динамічного програмування.

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

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

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

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

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

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

Аналіз чутливості застосовується для визначення ступеня зміни виходу моделі щодо певного входу.

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

Висновок

АРМ "Операції по договорам" дозволить вирішити наступні основні задачі:

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

– скорочення витрат робочого часу на виконання рутинної роботи;

– підвищення якості та швидкості обслуговування кліїнтів банку.

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

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

1. А.Н.Романов, Б.Е.Одинцов „Советующие информационные системы в экономике „ ЮНИТИ, Москва, 2000 г.

2. Алан Нейбауэр „Access 2000 для занятых», перевод с английского, Питер, 2001, - 288 с.

3. В.М.Гужва „Інформаційні системи і технології на підприємствах”, навчальний посібник, Київ, 2001 р.

4. В.Ф.Ситник, Т.А.Писаревська, Н.В.Єрьоміна, О.С.Краєва „Основи інформаційних систем”, навчальний посібник, Київ, 2001 р.

5. Єрьоміна Н.В., Банківські інформаційні системи.-К.: КНЕУ, 2000.-220с.

6. І.Ф.Рогач, М.А.Сендзюк, В.А.Антонюк „Інформаційні системи у фінансово-кредитних установах”, навчальний посібник, Київ, 1999 р.

7. Под ред. Д.є.н. професора В.В.Евдокимова «Экономическая информатика», Учебник для вузов, Питер, 1997, - 592 с.

8. Рогач І.Ф., Сендзюк М.А., Антонюк В.А., Інформаційні системи у фінансово- кредитних установах. - К.: ІСНЕУ, 2001.-239с.

9. Система автоматизации банковской деятельности ProFIX/BANK - http://www.pr