—творенн¤ структури забезпечувальноњ частини ћ≤— комерц≥йного банку повТ¤зане з вибором вид≥в забезпеченн¤ ≥ орган≥зац≥Їю взаЇмод≥њ м≥ж ним таким чином, щоб ¤кнайкраще забезпечити реал≥зац≥ю задач, ¤к≥ вход¤ть до функц≥ональноњ частини системи, що проектуЇтьс¤. «абезпечувальна частина ћ≤— комерц≥йного  банку охоплюЇ орган≥зац≥йно-економ≥чне, ≥нформац≥йне, техн≥чне, математичне, програмне та ≥нш≥ види забезпеченн¤.

ѕ≥д час вибору техн≥чного, ≥нформац≥йного ≥ програмного забезпеченн¤ сл≥д врахувати особливост≥ банку, його ф≥нансов≥ можливост≥ ≥ обс¤ги ≥нформац≥њ, що циркулюЇ, квал≥ф≥кац≥ю сп≥вроб≥тник≥в та ≥н. ѕри цьому необх≥дно дотримуватис¤ принципу сум≥сноњ розробки вс≥х вид≥в забезпеченн¤.

–озгл¤даючи орган≥зац≥йно-економ≥чне забезпеченн¤ ћ≤— комерц≥йного  банку, зазначимо, що воно Ї сукупн≥стю орган≥зац≥йно-економ≥чних метод≥в ≥ засоб≥в, необх≥дних дл¤ ефективного функц≥онуванн¤ системи. ¬≥д нього залежить взаЇмод≥¤ ц≥лей ≥ функц≥й системи, апарату управл≥нн¤, а також рац≥ональне використанн¤ ресурс≥в. ќсновною метою орган≥зац≥йно-економ≥чного забезпеченн¤ Ї анал≥з ≥снуючоњ системи управл≥нн¤ ≥ опрацюванн¤ комплексу орган≥зац≥йних р≥шень, спр¤мованих на п≥двищенн¤ њњ ефективност≥ [128]. “аке забезпеченн¤ налагоджуЇ взаЇмод≥ю персоналу ћ≤— ¤к з техн≥чними засобами, так ≥ м≥ж собою в процес≥ вир≥шенн¤ завдань управл≥нн¤ банку.

         ¬ структур≥ орган≥зац≥йного забезпеченн¤ можна вид≥лити чотири групи питань. ќсновна група охоплюЇ найважлив≥ш≥ методичн≥ матер≥али, що регламентують процес створенн¤ ≥ функц≥онуванн¤ системи. ƒо складу наступноњ групи вход¤ть засоби, необх≥дн≥ дл¤ ефективного проектуванн¤ ≥ функц≥онуванн¤ ћ≤—. ÷е комплекси задач, включаючи типов≥, структури управл≥нн¤, ун≥ф≥кован≥ форми документ≥в, загально - державн≥ ≥ галузев≥ класиф≥катори.

¬ажливою складовою орган≥зац≥йного забезпеченн¤ Ї техн≥чна документац≥¤, ¤ка формуЇтьс¤ в процес≥ проектного обстеженн¤ (техн≥чне завданн¤ ≥ техн≥ко-економ≥чне обірунтуванн¤ системи, що проектуЇтьс¤), п≥д час техн≥чного ≥ робочого проектуванн¤ (техн≥чний ≥ робочий проекти) ≥ в пер≥од впровадженн¤ (документи, що оформлюють поетапну здачу системи до експлуатац≥њ).

ќск≥льки виконанн¤ будь-¤коњ роботи передбачаЇ на¤вн≥сть виконавц≥в, колектив фах≥вц≥в апарату управл≥нн¤ банку, що зд≥йснюЇ процеси анал≥зу ≥нформац≥њ ≥ прийн¤тт¤ р≥шень, а також обробки даних ≥ займаЇтьс¤ проблемами розробки ≥ розвитку системи управл≥нн¤, складаЇ четверту групу структурноњ схеми орган≥зац≥йного забезпеченн¤.

ќрган≥зац≥йно-економ≥чне забезпеченн¤, що створюЇ Їдину систему з економ≥чних ≥ методичних питань, техн≥чного, програмного ≥ методичного забезпеченн¤, буде ефективним лише за умови дос¤гненн¤ оптимального розпод≥лу функц≥й м≥ж техн≥чними засобами ≥ людиною.

« метою загального кер≥вництва розробками доц≥льно створити координац≥йну раду, функц≥¤ми ¤коњ Ї: затвердженн¤ методолог≥њ автоматизац≥њ управл≥нн¤, контроль виконанн¤ етап≥в створенн¤ ћ≤—, прийн¤тт¤ р≥шень щодо орган≥зац≥йних та економ≥чних питань, що виникають.

” банку, дл¤ ¤кого проектуЇтьс¤ ћ≤—, бажано створити спец≥ал≥зований п≥дрозд≥л, основним призначенн¤м ¤кого Ї орган≥зац≥¤ роб≥т щодо п≥дготовки банку до впровадженн¤ новоњ системи управл≥нн¤, участь у розробках, впровадженн≥ ≥ супровод≥ системи, навчанн¤ персоналу банку новим методам роботи. Ќа нашу думку, ним може бути в≥дд≥л маркетинговоњ ≥нформац≥њ, положенн¤ про ¤кий запропоноване у додатку Ѕ.

        ≤нформац≥йне забезпеченн¤ ћ≤— комерц≥йного  банку Ц це сукупн≥сть даних, мовних засоб≥в опису даних, програмних засоб≥в обробки ≥нформац≥њ, а також процедур ≥ метод≥в њхньоњ орган≥зац≥њ, збер≥ганн¤, накопиченн¤ та доступу до них, що забезпечують наданн¤ ≥нформац≥њ, необх≥дноњ в процес≥ вир≥шенн¤ задач управл≥нн¤.

ѕри опрацюванн≥ ≥нформац≥йного забезпеченн¤ розвТ¤зуЇтьс¤ ц≥лий р¤д проблем. „астина з них повТ¤зана з необх≥дн≥стю отриманн¤ ≥нформац≥њ, п≥дготовки даних до обробки у ≈ќћ ≥ оперуванн¤ ними поза ≈ќћ, ≥нша частина Ц з обробкою, пошуком ≥ збер≥ганн¤м даних. «г≥дно з цим у склад≥ ≥нформац≥йного забезпеченн¤ вид≥л¤ють поза машинне ≥ внутр≥шньо машинне ≥нформац≥йне забезпеченн¤.

—творенн¤ внутр≥шньо машинного ≥нформац≥йного забезпеченн¤ передбачаЇ визначенн¤ складу обТЇкт≥в предметноњ галуз≥, њхню ≥дентиф≥кац≥ю, встановленн¤ властивостей обТЇкт≥в, в≥дношень м≥ж ними, що виникають у процес≥ функц≥онуванн¤ банку, формал≥зац≥ю даних у в≥дпов≥дност≥ до вимог машинноњ обробки ≥ опрацюванн¤ правил поданн¤ ≥нформац≥њ у в≥дпов≥дних документах. ѕозамашинне ≥нформац≥йне забезпеченн¤ охоплюЇ: системи класиф≥кац≥њ ≥ кодуванн¤ ≥нформац≥њ, класиф≥катори техн≥ко-економ≥чноњ ≥нформац≥њ, систему ун≥ф≥кованоњ документац≥њ.

ќднозначний формал≥зований опис вс≥х даних, що використовуютьс¤ при вир≥шенн≥ задач ћ≤—, ¤кий забезпечуЇ автоматизац≥ю процес≥в збер≥ганн¤, пошуку, обробки ≥ наданн¤ даних без викривленн¤ њхнього зм≥сту, зд≥йснюЇтьс¤ за допомогою засоб≥в формал≥зованого опису економ≥чноњ ≥нформац≥њ, до складу ¤коњ входить й система загальнодержавних ≥ галузевих класиф≥катор≥в, ¤к≥ дозвол¤ють ≥дентиф≥кувати обТЇкти, встановлювати њхн≥ властивост≥.

ѕри проектуванн≥ ≥нформац≥йного забезпеченн¤ сл≥д вивчати характеристики поток≥в ≥нформац≥њ. ≤нформац≥йн≥ потоки, що рухаютьс¤ у ћ≤—, мають бути ч≥тко в≥дстежуваними ≥ керованими. «а одиницю потоку використовують документ, показник, пов≥домленн¤. ƒокументи Ї основними нос≥¤ми маркетинговоњ ≥нформац≥њ у банку. ¬они ф≥ксують ≥ регламентують управл≥нську д≥¤льн≥сть. ƒл¤ будь-¤кого банку можна вид≥лити три потоки документ≥в: вх≥дний, внутр≥шн≥й ≥ вих≥дний. «разкова класиф≥кац≥¤ тип≥в документ≥в за потоками наведена у табл.4. 13.

        ” склад≥ ћ≤— циркулюЇ ≥нформац≥¤ про б≥знес-процеси у вигл¤д≥ керованих, оц≥нювальних ≥ некерованих параметр≥в, що отримуютьс¤ в≥д банк≥вських продукт≥в, п≥дрозд≥л≥в, кл≥Їнт≥в, конкурент≥в, ринк≥в тощо. јнал≥тичний механ≥зм поданн¤ ≥нформац≥њ маЇ супроводжуватис¤ можлив≥стю њњ конкретизац≥њ у розр≥з≥ кожного з аспект≥в, тобто можлив≥стю детал≥зац≥њ за здалег≥дь сформульованим класиф≥катором пон¤ть поданн¤ ≥нформац≥њ. ќтже з метою поданн¤ ≥нформац≥њ в такому вигл¤д≥ сл≥д зд≥йснити њњ попередню структуризац≥ю ≥з застосуванн¤м так званих метаданих. «астосовуючи такий п≥дх≥д, не важко визначити тенденц≥њ обс¤г≥в продажу щодо кожного банк≥вського продукту, за певний пер≥од, щодо кожного ринку. ћетадан≥ за своЇю суттю Ц це дан≥ про ≥нформац≥ю, що м≥ститьс¤ в ≥нформац≥йн≥й систем≥ банку, тобто зм≥стовний каталог ≥нформац≥йного сховища. ѕ≥д ≥нформац≥йним сховищем розум≥ють актуальну арх≥вну компТютерну систему

                                                                                                        “аблиц¤ 4.13

 ласиф≥кац≥¤ форм ≥ вид≥в документ≥в у розр≥з≥ документо поток≥в

збиранн¤, збер≥ганн¤ ≥ поданн¤ ≥нформац≥њ п≥д час п≥дготовки управл≥нських р≥шень. ќсновн≥ компоненти метаданих Ц модель даних, метрика, синон≥ми, регламент зм≥н Ц характеризують : джерела ≥нформац≥њ в ≥нформац≥йному сховищ≥, тобто розпод≥л походженн¤ ≥ структури баз даних; перетворенн¤ ≥нформац≥њ при передаванн≥ даних з р≥зних джерел в ≥нформац≥йне сховище; поточний опис даних в ≥нформац≥йному сховищ≥, ≥стор≥ю зм≥ни на¤вних даних.

ћетадан≥ слугують поЇднувальною ланкою вс≥Їњ ≥нформац≥йноњ арх≥тектури банку. ѕроцедури формуванн¤ ≥ використанн¤ метаданих викладен≥ в робот≥ [195]. –озгл¤д систем управл≥нн¤ банками дозвол¤Ї певним чином класиф≥кувати ≥нформац≥ю в розр≥з≥ типових груп користувач≥в (табл.4.14). ѕроте не завжди достатн≥м Ї на¤вн≥сть зв≥т≥в, що формуютьс¤ на основ≥ пост≥йних запит≥в. ” таких випадках маркетологи, менеджери, ≥нш≥ фах≥вц≥, кер≥вники потребують б≥льш витонченого ≥нструменту. ƒодатков≥ дан≥ до анал≥зу мають бути з≥бран≥ у зручн≥й форм≥, добре структурован≥.

≤нформац≥йним в≥дображенн¤м предметноњ галуз≥ маркетингу служить ≥нформац≥йна база системи. ќстанн¤ складаЇтьс¤, ¤к правило, з дек≥лькох баз даних. ѕ≥д базою даних розум≥ють наб≥р даних, що орган≥зован≥ за певними правилами, ¤к передбачають загальн≥ принципи опису, збер≥ганн¤ та ман≥пулюванн¤ даними.

¬ управл≥нн≥ базами даних бере участь адм≥н≥стратор бази. ¬≥н маЇ контролювати процеси збиранн¤ ≥нформац≥њ, проектуванн¤ та експлуатац≥њ баз даних, забезпеченн¤ захисту ≥ ц≥л≥сност≥ даних. ¬≥дзначимо, що у ћ≤— мають бути  зад≥¤н≥ не т≥льк≥ створюван≥, але й ≥снуюч≥ у банку бази даних.

« метою опису ≥нформац≥њ, що збер≥гаЇтьс¤ ≥ обробл¤Їтьс¤, використовуютьс¤ три р≥вн≥ детал≥зац≥њ: зовн≥шн≥й р≥вень Ц опис ≥нформац≥йних потреб к≥нцевого користувача; концептуальний р≥вень Ц опис ≥нформац≥йних потреб на р≥вн≥ пон¤ть ≥нформац≥йноњ системи; внутр≥шн≥й р≥вень Ц опис способу збер≥ганн¤ ≥нформац≥њ у памТ¤т≥ ≈ќћ та метод≥в доступу до нењ.

«овн≥шн≥й р≥вень Ї достатн≥м дл¤ використанн¤ генератор≥в додатк≥в, що включен≥ до вс≥х сучасних систем управл≥нн¤ базою даних (—”Ѕƒ). «а њхньою допомогою користувач може самост≥йно зд≥йснювати перетворенн¤ ≥нформац≥њ, що ним уводитьс¤, та ≥нформац≥њ, що м≥ститьс¤, в потр≥бну вих≥дну.

Ќа концептуальному р≥вн≥ описуЇтьс¤ повний ≥нформац≥йний зм≥ст бази: пов≥домленн¤ щодо структури оброблюваноњ ≥нформац≥њ та технолог≥њ њњ обробки Ц методи контролю ≥нформац≥њ, що застосовуютьс¤, опис використанн¤ поток≥в ≥нформац≥њ, опис обмежень на доступ до ≥нформац≥њ та ≥н.  онцептуальний р≥вень у принцип≥ Ї достатн≥м до вибору конкретноњ —”Ѕƒ. ѕравила опису даних вм≥щен≥ в модел¤х даних. –озр≥зн¤ють три основн≥ модел≥: рел¤ц≥йну, мережневу та ≥Їрарх≥чну [196; 197]. ≤снуюч≥ —”Ѕƒ забезпечують реал≥зац≥ю можливостей цих моделей, при цьому в переважн≥й б≥льшост≥ ≥нформац≥йних систем, що техн≥чно оснащен≥ персональними компТютерами типу IBM, використовуютьс¤ —”Ѕƒ рел¤ц≥йного типу.

¬нутр≥шн≥й р≥вень визначаЇ орган≥зац≥ю даних у памТ¤т≥ ≈ќћ ≥ метод≥в доступу до них [196]. якщо використовуЇтьс¤ —”Ѕƒ, то цей опис Ї м≥н≥мальним.

” перспективних ћ≤— у ¤кост≥ розвитку баз даних пропонуЇтьс¤ використанн¤ баз знань, ¤к≥ дозвол¤ть отримати в≥домост≥, що ¤вно не збер≥гаютьс¤ в базах даних. ѕринципову р≥зницю мають три модел≥ поданн¤ знань Ц продукц≥йна, фреймова та семантичних мереж [198]. “ак≥ системи належать до ≥нтелектуальних ≥ на початкових стад≥¤х свого розвитку можуть входити до складу ћ≤— ¤к њњ п≥дсистеми.

ѕрограмне забезпеченн¤ ћ≤— охоплюЇ програмн≥ засоби ≥ документац≥ю, необх≥дну дл¤ експлуатац≥њ цих програмних засоб≥в, ≥ под≥л¤Їтьс¤ на загальносистемне (базове) ≥ прикладне. «агальносистемне програмне забезпеченн¤ призначене орган≥зувати процес обробки ≥нформац≥њ в ћ≤— ≥ охоплюЇ операц≥йну систему, серв≥сн≥ програми, системи програмуванн¤ та програми техн≥чного обслуговуванн¤.

ѕризначенн¤м прикладного програмного забезпеченн¤ Ї вир≥шенн¤ конкретних завдань ћ≤—. ƒо його складу вход¤ть програмн≥ засоби загального призначенн¤ ≥ спец≥альн≥ програмн≥ засоби до конкретноњ ћ≤—. «асобами загального призначенн¤ Ї —”Ѕƒ, табличн≥ процесори, текстов≥ ≥ граф≥чн≥ редактори та ≥н. —пец≥альн≥ програмн≥ засоби можуть розробл¤тис¤ дл¤ конкретноњ ћ≤— ≥ купуватис¤ готовими.

—кладовими програмного забезпеченн¤ ћ≤— банку Ї: операц≥йн≥ системи, системи управл≥нн¤ базами даних, засоби розробки програм-додатк≥в (системи програмуванн¤), ≥нструментальн≥ засоби технолог≥њ наскр≥зного проектуванн¤ (CASE Ц технолог≥њ).

¬иход¤чи з реальних задач, строк≥в та ф≥нансових можливостей, р≥вн¤ готовност≥ персоналу, кер≥вництво банку в б≥льшост≥ випадк≥в приймаЇ р≥шенн¤ про техн≥чну реал≥зац≥ю банк≥вських компТютерних систем на локальн≥й мереж≥ ѕ≈ќћ у переважн≥й б≥льшост≥ з використанн¤ам мережних операц≥йних систем Netware Novell, Unix, Windows NT. Ќа робочих м≥сц¤х доц≥льно використовувати операц≥йн≥ системи та середовище DOS, Windows 3.0, Windows 3.11, Windows 95, Windows 98, Windows 2000, Windows NT. ѕричому, в одн≥й банк≥вськ≥й мереж≥ можуть використовуватис¤ р≥зн≥ операц≥йн≥ середовища. “акий п≥дх≥д, безумовно, виправданий дл¤ багатьох банк≥в, в ¤ких часто пор¤д з новими модел¤ми ѕ  працюють менш потужн≥, виготовлен≥ в попередн≥ роки [125].

ƒл¤ операц≥йних систем Windows ¤кнайкраще п≥дход¤ть —”Ѕƒ Visual FoxPro та —”Ѕƒ MS Access, а також промислова —”Ѕƒ Sybase. «асобами останньоњ, наприклад, створена система " редитно-депозитне обслуговуванн¤ банку", ¤ка, зокрема, охоплюЇ договори банку, взаЇморозрахунки з кл≥Їнтами, позабалансовий обл≥к терм≥нових та довготерм≥нових зобовТ¤зань за договорами [125]. —учасн≥ засоби розробки додатк≥в охоплюють системи, створен≥ ф≥рмою Borland  та Delphi C++ Builder. ¬ обох системах використовуютьс¤ обТЇктно-ор≥Їнтован≥ мови програмуванн¤ високого р≥вн¤ ≥ вбудован≥ в них можливост≥ роботи з базами даних. «азначен≥ системи Ї в≥зуальними засобами розробки додатк≥в.

ƒл¤ розробки ћ≤— може бути використана технолог≥¤ наскр≥зного проектуванн¤, ¤ка Ї набором компонент Ц програмних продукт≥в та метод≥в проектуванн¤. «окрема, ≥нтегрований CASE-≥нструментар≥й призначений до колективноњ розробки, що охоплюЇ вс≥ етапи життЇвого циклу системи. ѕроцес проектуванн¤ розпочинаЇтьс¤ з формал≥зац≥њ загальних вимог та передбачаЇ поступову конкретизац≥ю задуму з використанн¤м механ≥зму декомпозиц≥њ та переходу до детальних техн≥чних р≥шень, аж до отриманн¤ готового програмного коду, складу ≥ тополог≥њ техн≥чних засоб≥в системи, що проектуЇтьс¤. –езультатом виконанн¤ проекту Ї: база даних системи, що охоплюЇ вс≥ необх≥дн≥ ф≥зичн≥ обТЇкти, побудована з врахуванн¤м пол≥тики п≥дтримки ц≥л≥сност≥ даних; програми, що реал≥зують користувацький ≥нтерфейс.

“ехн≥чне забезпеченн¤ ћ≤— включаЇ весь комплекс техн≥чних засоб≥в збиранн¤, реЇстрац≥њ, передаванн¤, обробки, в≥дображенн¤ ≥ тиражуванн¤ ≥нформац≥њ. « метою реал≥зац≥њ розпод≥леноњ обробки даних створюютьс¤ багатомашинн≥ асоц≥ац≥њ, структура ¤ких опрацьовуЇтьс¤ за одним з наступних напр¤мк≥в: багатомашинних обчислювальних комплекс≥в та компТютерних (обчислювальних) мереж. Ѕагатомашинн≥ обчислювальн≥ комплекси можуть бути локальними та дистанц≥йними. Ќайвищою формою багатомашинних асоц≥ац≥й Ї компТютерн≥ мереж≥, ¤к≥ в≥др≥зн¤ютьс¤ розм≥рн≥стю, розпод≥лом функц≥й м≥ж компТютерами, необх≥дн≥стю вир≥шенн¤ в мереж≥ задач≥ маршрутизац≥њ пов≥домлень. ” ћ≤— доц≥льно застосовувати локальн≥ мереж≥ (LAN), рег≥ональн≥ мереж≥ (MAN) та глобальн≥ мереж≥ (WAN).

ћета розробки ћ≤— Ц створенн¤ високо¤к≥сноњ системи, що задовольн¤Ї вимоги кер≥вник≥в банк≥в, маркетолог≥в, менеджер≥в, економ≥ст≥в та ≥нших фах≥вц≥в у сучасн≥й та ¤к≥сн≥й ≥нформац≥њ, на п≥дстав≥ ¤коњ можна приймати оптимальн≥ р≥шенн¤. ѕроцесом розробки необх≥дно керувати з метою забезпеченн¤ впровадженн¤ системи у задан≥ терм≥ни, без перевищенн¤ кошторису витрат ≥ з характеристиками, що вимагаютьс¤. ќтже, створенн¤ ћ≤— банку маЇ грунтуватис¤ на певн≥й дисципл≥н≥, охоплювати стандартн≥ етапи ≥ завершуватис¤ виданн¤м нормативних документ≥в. ƒо того ж ћ≤— маЇ гарантувати бажан≥ показники витрат та ефективност≥, в≥др≥зн¤тис¤ високою над≥йн≥стю, легко поновлюватис¤ у раз≥ в≥дмов та бути простою у супровод≥.

ѕроект даноњ ≥нформац≥йноњ системи ¤к ≥ будь-¤коњ ≥ншоњ системи орган≥зац≥йно-економ≥чного призначенн¤ доц≥льно розпод≥лити на два головних взаЇмоповТ¤заних компонента: лог≥чний проект, що моделюЇ предметну сферу, ≥ технолог≥чний проект, що реал≥зуЇ цю модель [152]. —творенн¤ ћ≤— банку охоплюЇ три основних стад≥њ: передпроектну, проектуванн¤ системи, п≥сл¤проектну (впровадженн¤ та експлуатац≥¤ системи).  ожна стад≥¤ складаЇтьс¤ з етап≥в, що охоплюють окрем≥ роботи, ¤к≥ зд≥йснюютьс¤ певними виконавц¤ми. як правило, кожний етап маЇ зак≥нчуватис¤ в≥дпов≥дним документом (табл.4. 15)

Ќа в≥дм≥ну в≥д стандартних рекомендац≥й щодо складу роб≥т, що викладен≥ у л≥тератур≥ [20; 43; 72; 98], нами пропонуЇтьс¤ б≥льш розширений та детал≥зований комплекс роб≥т на передпроектн≥й стад≥њ (поглиблений анал≥з можливостей реал≥зац≥њ розробки автоматизованоњ системи на баз≥ системного п≥дходу) ≥ проектн≥й стад≥њ (р¤д роб≥т, повТ¤заних ≥з тестуванн¤м системи). ѕри цьому де¤к≥ роботи Ї видозм≥неними у в≥дпов≥дност≥ до сучасних у¤влень щодо проектуванн¤

“аблиц¤ 4.15.

ќсновн≥ стад≥њ, етапи ≥ роботи щодостворенн¤ ћ≤— у комерц≥йному банку

≥нформац≥йних систем.

ƒо розробки ћ≤— може бути залучена сторонн¤ орган≥зац≥¤, що маЇ необх≥дний науково-техн≥чний потенц≥ал ≥ достатн≥й практичний досв≥д. ¬≥д банку в будь-¤кому випадку обовТ¤зково беруть участь фах≥вц≥ служби маркетингу ≥ в≥дд≥лу автоматизац≥њ. «розум≥ло, що по м≥р≥ необх≥дност≥ мають залучатис¤ фах≥вц≥ ≥нших в≥дд≥л≥в, управл≥нь та служб.

”сп≥х розробки ћ≤— у значному ступен≥ залежить в≥д того, наск≥льки ретельно опрацьована стратег≥¤ њњ реал≥зац≥њ. ÷е означаЇ, що маЇ зд≥йснюватис¤ довгострокове плануванн¤ ≥нформац≥йних потреб банку в маркетингов≥й ≥нформац≥њ та виб≥р принципових техн≥чних р≥шень, що забезпечують њхнЇ задоволенн¤. ѕлануванн¤ розробки ћ≤— маЇ передувати  досл≥дженн¤ напр¤мк≥в д≥¤льност≥ банку, в результат≥ ¤кого визначаютьс¤ його головн≥ завданн¤ ≥ можуть перегл¤датис¤ ¤к способи реал≥зац≥њ тих чи ≥нших функц≥й управл≥нн¤, так ≥ сфери д≥¤льност≥, включаючи номенклатуру банк≥вських продукт≥в, ринки збуту тощо.

« метою визначенн¤ основних техн≥ко-економ≥чних характеристик ≥ функц≥й новоњ системи зд≥йснюЇтьс¤ критичний анал≥з вимог, zrs до нењ висуваютьс¤. ƒал≥ розробл¤Їтьс¤ загальний план проектуванн¤ системи, в ¤кому розпод≥лен≥ пр≥оритети м≥ж окремими напр¤мами роб≥т та оформлюЇтьс¤ техн≥чне завданн¤ на розробку ≥ впровадженн¤ ћ≤—.

ƒосл≥дженн¤ можливостей техн≥чноњ та економ≥чноњ реал≥зац≥њ ћ≤— банку починаЇтьс¤ з обстеженн¤ ≥снуючоњ системи управл≥нн¤ маркетинговою д≥¤льн≥стю банку. ѕередус≥м формуЇтьс¤ зведенн¤ операц≥й (функц≥й), що виконуютьс¤ функц≥ональними службами банк≥вськоњ установи. ¬изначаютьс¤ потоки ≥нформац≥њ. ѕри цьому обовТ¤зково враховуютьс¤ на¤вн≥ файли та бази даних.  р≥м того, структура ≥ функц≥њ ≥снуючоњ системи, а також на¤вн≥ проблеми можуть зТ¤суватис¤ в результат≥ бес≥д з менеджерами, фах≥вц¤ми та виконавц¤ми апарату управл≥нн¤.

“ут також необх≥дно з≥брати ≥нформац≥ю щодо структури витрат: про зароб≥тну плату, прем≥њ, видатки на обладнанн¤ тощо ≥ про њхн≥й розпод≥л за операц≥¤ми. ¬ажливим Ї також у¤вленн¤ про варт≥сть ≥ характеристики ≥снуючоњ системи, зокрема про чисельн≥сть управл≥нського ≥ обслуговуючого персоналу, використане обладнанн¤ та ≥н. —л≥д ф≥ксувати сильн≥ ≥ слабк≥ сторони д≥¤льност≥ банку. Ќедол≥ки в ≥нформац≥йн≥й сфер≥ розгл¤даютьс¤ окремо, включаючи ≥снуючу практику вир≥шенн¤ питань захисту даних, виробнич≥ зв"¤зки, ф≥нансов≥ ≥ юридичн≥ вимоги.

–езультати обстеженн¤ ≥снуючоњ системи обговорюютьс¤ ≥ уточнюютьс¤ з майбутн≥ми користувачами.

«а на¤вност≥ альтернативних вар≥ант≥в створенн¤ ћ≤— з кожного напр¤му проектних роб≥т маЇ зд≥йснюватис¤ анал≥з можливостей реал≥зац≥њ, результатом ¤кого Ї уточненн¤ можливостей новоњ системи, техн≥чних ≥ програмних засоб≥в њњ функц≥онуванн¤. «а умов безперервного вдосконаленн¤ ≥нформац≥йних технолог≥й значенн¤ роб≥т з формуванн¤ стратег≥њ ≥ анал≥зу можливостей реал≥зац≥њ розробки ≥стотно зростаЇ, тому з≥ставленн¤ р≥зних техн≥чних р≥шень ≥ виб≥р оптимального вар≥анту з позиц≥њ задоволенн¤ вимог користувач≥в ≥ витрат на реал≥зац≥ю сл≥д зд≥йснювати ¤комога ран≥ше.

ѕроектуванн¤ ћ≤— доц≥льно починати ≥з системного анал≥зу, основна мета ¤кого формулюЇтьс¤ так: ви¤вленн¤ недол≥к≥в ≥снуючоњ системи, опрацюванн¤ необх≥дних зм≥н, а також специф≥кац≥¤ характеристик новоњ системи з вказ≥вкою перел≥ку автоматизованих задач управл≥нн¤. √оловне завданн¤ на цьому етап≥ пол¤гаЇ у зд≥йсненн≥ опису новоњ системи шл¤хом визначенн¤ вс≥х функц≥й (операц≥й) ≥ наданн¤ лог≥чноњ структури вх≥дних, вих≥дних ≥ збережуваних даних.

” процес≥ системного анал≥зу формулюютьс¤, уточнюютьс¤ ≥ координуютьс¤ вимоги користувач≥в, виражен≥ у  терм≥нах њхньоњ основноњ д≥¤льност≥, при чому сл≥д осообливо вид≥лити т≥ вимоги, ¤к≥ можуть виконуватис¤ за допомогою автоматизац≥њ. ѕ≥дготований таким чином системними анал≥тиками лог≥чний проект подаЇтьс¤ проектувальникам, що зд≥йснюють подальше проектуванн¤ (визначенн¤ лог≥чноњ ≥ ф≥зичноњ структур баз даних, опрацюванн¤ методик та алгоритм≥в вир≥шенн¤ задач тощо).

–озробка автоматизованоњ ћ≤— Ї пром≥жною ланкою м≥ж системним анал≥зом ≥ програмуванн¤м. ќтже, техн≥чний проект маЇ в≥дображати ¤к адм≥н≥стративно-управл≥нськ≥, так ≥ техн≥чн≥ аспекти функц≥онуванн¤ системи.

ѕроектуванн¤ ћ≤— починаЇтьс¤ з вивченн¤ специф≥кац≥й, п≥дготовлених у процес≥ анал≥зу ≥ завершуЇтьс¤ створенн¤м специф≥кац≥й програм (техн≥чних завдань та програмуванн¤). “ут необх≥дно виконати великий обс¤г проектних роб≥т. ћ≤— маЇ бути розд≥лена на п≥дсистеми, комплекси задач, окрем≥ задач≥ ≥ програми. ƒан≥ мають п≥дл¤гати структуризац≥њ за базами даних, кр≥м того необх≥дно опрацювати методики та алгоритми обробки маркетинговоњ ≥нформац≥њ, обрати в≥дпов≥дн≥ процедури забезпеченн¤ контролю, захисту ≥ в≥дновленн¤ даних, визначити потенц≥йну ефективн≥сть системи ≥ розробити документац≥ю програм≥стам ≥ користувачам. ”сп≥шне виконанн¤ вс≥х цих роб≥т ц≥лком залежить в≥д квал≥ф≥кац≥њ ≥ досв≥ду проектувальник≥в.

” звТ¤зку з тим, що система розд≥лена на р¤д компонент≥в в≥дпов≥дно до прикладних функц≥й, Ї можлив≥сть залучати до проектуванн¤ користувач≥в. ¬загал≥, участь користувач≥в у процес≥ проектуванн¤ Ї дуже бажанj..

¬bокремленн¤ етапу лог≥чного проектуванн¤ дозвол¤Ї розробникам зосередитис¤ на пошуку принципового р≥шенн¤ функц≥ональноњ задач≥ перед тим, ¤к розпочати формуванн¤ файл≥в ≥ розробку програм. як п≥дсумок створена ћ≤— буде повн≥ше в≥дпов≥дати вимогам користувач≥в ≥ ви¤витьс¤ прост≥шою з точки зору њњ супроводженн¤. ќдна з переваг методу структурного проектуванн¤ пол¤гаЇ в тому, що в специф≥кац≥¤х формуютьс¤ лише призначенн¤ ≥ вимоги, що висуваютьс¤ до програм, а опрацюванн¤ њхн≥х внутр≥шн≥х структур зд≥йснюЇтьс¤ програм≥стами.

«авд¤ки под≥лу процесу проектуванн¤ на стад≥њ, а обТЇкт≥в розробки Ц на р¤д незалежних лог≥чних компонент≥в значно спрощуЇтьс¤ управл≥нн¤ проектом загалом, зТ¤вл¤Їтьс¤ можлив≥сть розпод≥лу завдань м≥ж розробниками, що дозвол¤Ї оперативно коригувати календарний план роб≥т, залучати фах≥вц≥в на етап≥ постановки завдань ≥ контролю проектних р≥шень.

” процес≥ програмуванн¤ розробл¤ютьс¤ автономно тестован≥ програми за специф≥кац≥¤ми, техн≥чними завданн¤ми на програмуванн¤, п≥дготовленими п≥д час системного проектуванн¤. √оловна мета програмуванн¤ Ц створити над≥йн≥ програми ≥ документац≥ю щодо системи. ” ход≥ розробки програм можна вид≥лити три самост≥йних види роб≥т: проектуванн¤, складанн¤ (кодуванн¤) ≥ тестуванн¤ (налагодженн¤) програм.

ѕроектуванн¤ охоплюЇ лог≥чне проектуванн¤ (розробку лог≥чноњ структури програми) ≥ ф≥зичне проектуванн¤ (створенн¤ програми з дек≥лькох повТ¤заних м≥ж собою модул≥в).

ѕитанн¤ щодо реал≥зац≥њ програми у вигл¤д≥ самост≥йних ф≥зичних модул≥в Ї дуже важливим, оск≥льки його в≥рне вир≥шенн¤ може скоротити загальний час розробки, а нев≥рне Ц зб≥льшити його в дек≥лька рок≥в. Ћог≥чний проект програми не повинен зм≥нюватис¤ у раз≥ њњ ф≥зичноњ реал≥зац≥њ у вигл¤д≥ окремих модул≥в.

“екст програми Ї важливою частиною документац≥њ системи, тому в≥н маЇ бути максимально зрозум≥лим. ѕ≥д час кодуванн¤ використовуютьс¤ спец≥альн≥ ≥нструментальн≥ засоби програмуванн¤. ќформленн¤ тексту програми маЇ в≥дображати њњ структуру.

«а трудом≥стк≥стю тестуванн¤ можна пор≥вн¤ти з проектуванн¤м ≥нформац≥йних систем, але оск≥льки воно Ї останн≥м етапом розробки, його плануванню прид≥л¤ють менше уваги, н≥ж попередн≥м етапам. “акий п≥дх≥д Ї необгрунтованим, бо метою тестуванн¤ Ї перев≥рка ступеню над≥йност≥ ћ≤— та можливост≥ виконанн¤ системою покладених на нењ функц≥й. ¬ипробуванн¤ мають продемонструвати в≥дпов≥дн≥сть системи њњ призначенню, зручн≥сть в експлуатац≥њ та адекватну взаЇмод≥ю з ≥ншими автоматизованими системами.  р≥м того, сл≥д перев≥рити процедури забезпеченн¤ контролю, захисту ≥ в≥дновленн¤ даних, а також вс≥ процеси взаЇмод≥њ м≥ж програмами. як св≥дчить заруб≥жний досв≥д, етап тестуванн¤ автоматизованоњ системи ≥нод≥ ви¤вл¤Їтьс¤ найскладн≥шим у розробц≥ загалом. “ут можуть ви¤витис¤ вс≥ неточност≥ ≥ хиби, на ¤к≥ розробники не звертали уваги п≥д час проектуванн¤ системи.

Ќа етап≥ досл≥дноњ експлуатац≥њ вс≥ р≥шенн¤, отриман≥ в результат≥ тестуванн¤ проекту, мають п≥дл¤гати критичному анал≥зу, головна мета ¤кого Ц ви¤вити, чи не порушен≥ обмеженн¤, що накладаютьс¤ орган≥зац≥йними вимогами, техн≥чними програмними засобами. –езультати досл≥дноњ експлуатац≥њ необх≥дно оформити документально у вигл¤д≥ зв≥ту. ÷е допоможе визначити необх≥дн≥ зм≥ни у систем≥.

ѕри цьому вир≥шуютьс¤ наступн≥ завданн¤:

-                     ви¤вленн¤ альтернативних р≥шень ≥ пошук найкращого з них у межах обмежень, що накладаютьс¤ загальним планом створенн¤ ћ≤—;

-                     ретельна перев≥рка системи перед њњ введенн¤м до експлуатац≥њ у банк≥вськ≥й д≥¤льност≥;

-                     п≥дготовка кадр≥в до роботи у систем≥;

-                     вивченн¤ ≥ анал≥з результат≥в досл≥дноњ експлуатац≥њ

¬ процес≥ експлуатац≥њ у банк≥вськ≥й д≥¤льност≥ сл≥д забезпечити нормальне функц≥онуванн¤ ћ≤—. « ц≥Їю метою необх≥дно орган≥зувати обслуговуванн¤ техн≥чних засоб≥в ≥ супроводженн¤ системного та додаткового програмного забезпеченн¤. “ехн≥чний контроль щодо запровадженоњ ћ≤— зд≥йснюЇтьс¤ у двох напр¤мках: з точки зору процесу розробки та њњ ефективност≥.

–ев≥з≥¤ процесу розробки маЇ охоплювати з≥ставленн¤ реальних витрат часу ≥ ресурс≥в та запланованих, перев≥рку в≥дпов≥дност≥ проектних р≥шень вимогам орган≥в управл≥нн¤. ћаЇ зд≥йснюватись також оц≥нюванн¤ ¤кост≥ проекту. ѕ≥д час оц≥нюванн¤ ефективност≥ ћ≤— сл≥д зТ¤сувати думку про нењ користувач≥в ≥ виконати розрахунок економ≥чноњ ефективност≥ впровадженоњ системи.  р≥м того, необх≥дно зТ¤сувати ступ≥нь в≥дпов≥дност≥ ћ≤— њњ призначенню, а також на¤вн≥сть ускладнень у ход≥ њњ експлуатац≥њ ≥ супроводженн¤.

Ќараз≥ сл≥д в≥дм≥тити, що ћ≤— банку Ї складною системою, у ¤к≥й доводитьс¤ оперувати з њњ частинами. ¬ир≥шальну роль тут в≥д≥грають методи декомпозиц≥њ системи ≥ методи ≥нтеграц≥њ складових частин. ѕри розробц≥ ћ≤— сл≥д забезпечити самост≥йн≥сть ≥ завершен≥сть окремих компонент (модулей), передбачивши њхн≥й комплексний звТ¤зок ¤к м≥ж собою, так ≥ з д≥ючими ≥нформац≥йними системами (≥нтегрованою банк≥вською системою), що дозволить користувачев≥ отримати бажаний ефект.