Платіжні системи - Вовчак О.Д. - Створення платіжної системи

6.1. Методологія розробки платіжних систем

Процес розробки платіжної системи такий:

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

1.1. Аналіз стратегії проекту, в результаті якого початкова концепція переводиться до форми "переліку потреб користувачів" і створюються попередні варіанти обґрунтування проекту та плану організації робіт за цим проектом.

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

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

Створення платіжної системи

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

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

2.3.Побудова системи (робочий проект), під час якої на основі детального проекту створюється програмний продукт і випробовуються окремі компоненти системи. Готуються попередні варіанти довідників користувача, щоб сприяти побудові моделей випробувань на стадії їх підготовки.

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

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

Досягнення практичного результату

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

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

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

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

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

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

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

Серед вимог користувачів можна виділити, зокрема, вимоги до:

- механізмів розрахунку;

- бухгалтерської моделі;

- графіка роботи системи;

- форми повідомлень;

- доступу до системи;

- реагування на нестандартні ситуації;

- швидкості обробки платежів;

- продуктивності системи;

- зберігання інформації;

- умов оплати за послуги системи;

- рівня захисту;

- ведення статистичної інформації;

- надійності системи;

- механізму вирішення спірних питань.

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

- зручною та простою у використанні (зокрема, статус платежів повинен бути зрозумілим для всіх учасників);

- високонадійною, особливо стосовно цілісності та захисту даних;

- такою, що забезпечує високий рівень готовності послуг;

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

- гнучкою та придатною до легкої адаптації;

- універсальною щодо доступу в різних режимах часу;

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

- такою, що забезпечує управління системними ризиками та стримує їх вплив;

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

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

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

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

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

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

До мережі зв'язку стандартної платіжної системи висувають такі вимоги:

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

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

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

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

- досить гнучка структура, здатна враховувати зміни у потребах фінансової сфери;

- висока надійність та захист передачі фінансової інформації;

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

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

- зв'язок з іншими інтерфейсами мережі;

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

- інтерфейс із глобальними мережами зв'язку;

- інтерфейс із резервними каналами зв'язку.

Вибір централізованої чи децентралізованої архітектури обробки даних залежить від чотирьох основних факторів:

1) типу прикладного використання при обробці інформації від користувачів;

2) характеру і приналежності даних та інформації, необхідних для задоволення потреб користувачів;

3) здатності забезпечувати повний контроль за станом системи телекомунікацій;

4) доступу користувача або можливості використання прикладних функцій системи та можливості введення та отримання інформації.

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

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

2. Чим треба керуватися при визначенні місцезнаходження розрахункових рахунків (враховуючи, наприклад, необхідність контролю за ними)?

3. Який тип механізму розрахунків використовуватиметься: на чистій чи на валовій основі?

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

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

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

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

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

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

1) розробки стратегії щодо постачання та субпідрядів;

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

3) підготовки документа, необхідного для відбору постачальників на конкурсній основі;

4) оцінки та вибору кращих пропозицій;

5) переговорів щодо укладення контракту та його підписання;

6) контролю та регулювання робіт, пов'язаних з виконанням контракту.

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

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

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

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

Виходячи з цієї концепції, можна виділити три характерні етапи реалізації проекту:

1) визначення потреб і їх формулювання у термінах цілей або специфікацій проекту;

2) створення системи або продукту, що відповідає зазначеним потребам;

3) досягнення відповідного практичного результату завдяки ефективному введенню системи в експлуатацію.

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

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

- ефективне керівництво роботою щодо створення системи;

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

- забезпечення ефективного функціонування програмно-технічних засобів.

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

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

Усю роботу над проектом повинна спрямовувати група керівництва проектом, очолювана "спонсором проекту". Спонсором проекту має бути керівник або член керівництва, що відповідає за надання послуг системою.

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

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

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

- розробки вимог щодо прикладних характеристик системи;

- бухгалтерського обліку та стандартів;

- юридичних питань і нормативних документів;

- розробки вимог до електронно-обчислювальної техніки та засобів зв'язку.

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

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

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

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

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

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

- система зручна у користуванні та може надавати необхідну допомогу й підтримку користувачам.

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