Функціональна повнота системи є першою і основною вимогою, що висувається до САБД. Повнофункціональною можна вважати систему, якщо набір її функцій дає змогу виконувати всі операції конкретного банку. Оскільки банки, як правило, є багатопрофільними, слід визначити набір модулів, потрібних для роботи в режимі on-line на загальній базі даних, визначити коло задач, для вирішення яких достатньо автономних пакетів, що формують у разі необхідності проведення у книзі особових рахунків і в балансі банку тощо. Програмний комплекс має дозволяти автоматизувати максимально можливу кількість робочих місць у банку, чи то фронт-офіс розрахунково-касового обслуговування, бек-офіс кредитування, АРМ із розрахунку заробітної плати тощо. Хорошим показником вибраної системи є задоволення 85-90% потреб банку.
Надзвичайно важливим є принцип комплексності розробки, який передбачає створення сукупності взаємопов'язаних програмних засобів, що, організовані в цілісну систему, автоматизують низку банківських функцій. Звичайно, система, яка відповідає сьогоднішнім потребам користувачів, може не задовольнити їх завтра, якщо в банку з'являться нові функції. Тому ще однією вимогою, що ставиться до САБД, є її гнучкість.
Гнучкість - один із ключових факторів, який полягає в тому, що будь-яка банківська система повинна мати можливість розширюватися та розвиватись, і не лише фірмою-розробником, а й силами спеціалістів банку. Постійні зміни, що відбуваються у сфері діяльності банків і зачіпають юридичну сферу, економічну сферу і банківські технології, вимагають від систем управління банком високого ступеня адаптації. У зв'язку з цим банківські інформаційні системи повинні мати гнучку структуру і бути відкритими системами, тобто такими, які дозволяють вносити потрібні зміни. Гнучкість системи перш за все базується на принципі параметризації - настроювання має бути одноразовим (на момент упровадження) і полягає в конфігуруванні системи за кількістю користувачів, особливостями і складом фізичних пристроїв тощо. Настроювання може бути і поточним, тоді його виконує адміністратор системи.
Розвиток системи може відбуватися у двох напрямах: кількісному -шляхом збільшення кількості філій чи клієнтів; якісному - шляхом розширення спектра банківських операцій і послуг. Зміни кількісного характеру призводять до неминучості нарощування системи, яке можна виконувати двома способами: за допомогою встановлення в головній конторі більш потужної ЕОМ чи розпаралелювання процесу обробки на кілька ЕОМ; шляхом збільшення продуктивності обчислювальних комплексів у філіях банку і переходу на розподілену обробку даних, зберігаючи за центральним обчислювальним комплексом лише функції консолідації балансу та обслуговування поточних інформаційних потреб.
Вибір способу нарощування САБД залежить від стратегії розвитку банку, особливостей взаємодії головної контори і її філій, а також від прийнятого розподілу функцій і відповідальності за них. Але в будь-якому разі розробник САБД повинен вказати конкретні шляхи вирішення проблеми нарощування системи для того чи іншого банку.
У цілому система повинна мати можливість розширення як по горизонталі (збільшення кількості клієнтів, каналів зв'язку тощо), так і по вертикалі (перехід на потужнішу техніку). При цьому мають бути зведені до мінімуму можливі зміни: інтерфейсу користувача; технології роботи зі системою; структури файлів бази даних.
Надійність системи полягає в тому, що САБД повинна забезпечувати роботу великої кількості користувачів, які одночасно можуть вводити документи (рахунки чи угоди), формувати звітність без будь-яких конфліктів, пов'язаних з одночасним доступом до даних. Реальний масштаб часу після введення документа САБД має забезпечувати його бухгалтерське проведення. Новий стан рахунків відразу стає доступним для всіх користувачів і відображається в балансі, а також може бути використаний при обчисленні нормативів. Система, побудована з урахуванням цієї вимоги, має такі переваги: дозволяє в будь-який момент часу мати повну картину фінансового стану банку; дає можливість оперативно відстежувати інформацію, що надходить у систему; забезпечує можливість отримання додаткових кредитних ресурсів.
Інтегрованість системи - це інформаційно та функціонально пов'язані між собою модулі. Банківські операції пов'язані єдиною технологією їх виконання, а комп'ютерна їх реалізація здійснюється за принципом побудови інтегрованої системи. Інформаційний зв'язок полягає в тому, що всі складові системи працюють із спільною базою даних, що дає змогу уникнути дублювання, забезпечує цілісність та узгодженість даних. Функціональний зв'язок дозволяє функціональним задачам, які характеризуються однаковою прикладною логікою, але розв'язуються на різних АРМах (за опорну концепцію розробки систем автоматизації банківської діяльності прийнято принцип АРМ), використовувати спільні процедури, що зберігаються у відповідних бібліотеках (наприклад, нарахування процентних ставок тощо). Головну увагу в такій системі приділено тому, щоб користувач використовував наближено одні й ті ж прийоми роботи і міг швидко переключитися з однієї групи операцій на іншу.
Забезпечення багато філійноїроботи банку. Вибір системи автоматизації і фірми - партнера з автоматизації є найскладнішим завданням для банків, що вже мають розвинуту філійну структуру або планують розвиток мережі філій. Це зумовлено тим, що філії, як правило, суттєво відрізняються за обсягом операцій та їх набором, кадровим складом працівників. Придбання різнотипних програм кількох фірм-розробників виявляється дорожчим (фірми зазвичай надають знижки в разі тиражування у філіях), тягне за собою проблеми в консолідації звітності і неможливість створення групи спеціалістів банку у сфері автоматизації для розв'язання проблем у центрі та у філіях щодо адаптації й доробки системи. Використання однієї системи в рамках багатофілійної структури також пов'язано з проблемою вибору системи, оптимальної за витратами на придбання бази даних, програмного забезпечення і техніки. Забезпечення ефективності багатофілійної роботи банку полягає в тому, що для банків, які мають багато філій, і особливо для тих, структура яких є трирівневою, важливим моментом є забезпечення єдності й цілісності технології. Виконання цієї вимоги в ідеальному варіанті - це забезпечення розподіленої обробки даних у режимі on-line. Забезпечення розподіленої обробки даних у такому режимі коштує поки що досить дорого і під силу не всім банкам. Тому реальнішим щодо забезпечення цієї вимоги є єдність технологій, тобто як мінімум системи всіх рівнів повинні мати однакову структуру даних, однакові інтерфейси та інструментальні засоби розробки програмного забезпечення.
Безпека та захищеність системи - одна із життєво необхідних вимог, що ставиться до САБД. За оцінками західних спеціалістів, навіть великий і стабільний банк збанкрутує, якщо він відкриває всю свою документацію. Тому САБД має бути захищена як усередині від можливих зловживань співробітниками банку, так і зовні від різного роду спроб розкриття банківської таємниці та шахрайства із його коштами.
Актуальна проблема забезпечення безпеки електронної банківської інформації може бути вирішена успішно тільки за комплексного підходу, який допускає розподіл доступу до інформації, до різних АРМ і до режимів у них. Так, для доступу до системи існують рівні: доступу в певну директорію, доступу до диска, реалізації всіх функцій иа віддаленій ЕОМ. Режим доступ в певну директорію передбачає також пересилання файлів у пеону директорію. Для цього, як правило, використовують систему паролів, шифрування інформації, що пересилається, електронні підписи.
Відповідність якостям системи документообігу. САБД має відповідати якостям системи документообігу. Це означає, що порядок проведення операцій описується на рівні системи, котра реалізує надійний контроль, щоб працівники банку виконували те, і лише те, що передбачено їхніми посадовими інструкціями. Тобто виконавець на своєму робочому місці виконує лише операції над документами, переміщуючи ці документи з одного списку в інший. Усі потрібні при цьому облікові дії система здійснює автоматично. Для цього в самому ядрі САБД мають бути реалізовані можливості опису практично будь-якої банківської операції.
Наявність "уповноваженого" модуля настроювання технології функціонування. САБД має бути організована таким чином, щоб настроювання технології її функціонування (технологія роботи банку) виконувалась не з АРМ кінцевих користувачів, а з певного одного "уповноваженого" модуля. Автоматизована банківська система повинна дозволяти описати всі інструкції централізовано - усі основні настроювання робить кваліфікований технолог банку, а працівники кредитної організації можуть одразу розпочати роботу з програмою. Це забезпечує можливість оперативних змін умов виконання будь-якої операції, що суттєво для створення нових банківських продуктів.
Швидкісні характеристики. САБД повинна дозволяти швидко, не вистоюючи черги, вводити клієнтські платежі, оперативно виконувати регламентні процедури (переоцінку валютних рахунків, випуск звітів тощо). Тому швидкість слід розглядати не як деякі єдині об'єктивні показники, яких потрібно досягти, а стосовно технології роботи банку. САБД перш за все має давати змогу кожному банківському працівникові своєчасно виконувати виробниче завдання. Так, якщо операціоніст зобов'язаний за дві хвилини обслужити клієнта, то за ці дві хвилини система повинна забезпечити пошук потрібної для нього інформації, ввести документ, зберегти його в базі даних, а також автоматично виконати всі належні при цьому бухгалтерські проведення. Швидкісні характеристики САБД оцінюються суб'єктивно - багато залежить від того, скільки часу вимагається на обробку цієї операції в конкретному банку. Разом із тим для фронт-офісних модулів особливо важливі такі показники, як швидкість уведення інформації і швидкість щодо ергономіч-ності (наприклад, довга відозва на дії користувача може створити серйозний психологічний дискомфорт). Що ж стосується бек-офісу, то ці дві вимоги не мають настільки суттєвого значення.
Можливість гнучкого настроювання звітів і друкованих форм документів. Серйозні проблеми виникнуть у банків, які використовують системи автоматизації, що не мають механізмів (генераторів) швидкого та гнучкого настроювання звітів і друкованих форм документів.
Пошук інформації та зручність роботи користувачів. Простота і зручність роботи іноді можуть бути вирішальним фактором для вибору системи, особливо якщо порівнюють кілька аналогічних програмних продуктів. Окрім того, цей критерій неявно свідчить про кваліфікацію компанії-розробника.
Легкість упровадження. Про легкість упровадження доцільно говорити в тому разі, якщо банківська установа жорстко обмежена кінцевими термінами та можливостями, потрібними для приведення системи в робочий стан. Недотримання цієї вимоги перетворює впровадження автоматизованої системи в нескінченний процес.
Тиражованість системи (кількість її впроваджень) є суттєвим аргументом, що допомагає прийняти остаточне рішення щодо вибору системи автоматизації. Так, якщо система не привернула уваги жодного з підприємств, це має змусити принаймні бути обережним. Якщо ж систему впроваджено, то спілкування з персоналом організації, в якій вона успішно працює, дозволить уникнути можливих помилок.
Проблеми, що стоять перед банківськими структурами, можуть бути успішно вирішені, якщо фірма-розробник у плані мінімізації ризиків надає замовникові такий сервіс: вибору з кількох систем, реалізованих різними мовами програмування, на різних базах даних і операційних системах; створення замовного проекту комплексної автоматизації банку з різними варіантами обробки даних у межах єдиного інформаційного простору головного банку і його відділень (філій); модернізація програмного продукту з урахуванням особливостей прийнятої в клієнта технології, причому доопрацювання системи і розробка нових модулів може здійснюватись як силами фірми-постачальника, так і силами клієнта, а також спільно; передача клієнтові вихідних текстів системи з повністю документованою структурою бази даних; різні рівні підтримки, найбільш розвинутий з яких передбачає прикріплення до банку персональної групи менеджерів і програмістів, що зайняті рішенням тактичних і стратегічних завдань автоматизації, тісна співпраця провідних спеціалістів та експертів фірми з працівниками банку-партнера; отримати під час придбання системи вихідні коди. Це зобов'яже утримувати у своєму штаті кілька кваліфікованих програмістів, однак зніме безліч проблем, пов'язаних із супроводженням та впровадженням системи.
3.3.1. Необхідність автоматизації документообігу
3.3.2. Універсальність побудови ядра інформаційної системи
3.3.3. Розширення спектра послуг віддалених офісів
3.3.4. Автоматизація управління філіями
3.3.5. Інтеграція клієнтів у банківський документообіг
3.4. РИЗИКИ ІНФОРМАЦІЙНИХ СИСТЕМ
3.4.1. Фактори ризику інформаційної системи
3.4.2. Мінімізація інвестиційних ризиків
Процес розробки інформаційної системи