22
BAB IV
ANALISIS SISTEM
Pada bab ini akan dipaparkan analisis dan pembahasan mengenai domain masalah yaitu virtual account. Tujuan dari menganalisis domain masalah adalah untuk mengetahui proses apa saja yang ada dalam operasional virtual account. Selain itu ada dua sistem sejenis yang dianalisis yaitu: OVO dan Go-Pay. Tujuan dari menganalisis sistem sejenis adalah untuk mengetahui bagaimana cara kerja dari aplikasi virtual account yang telah berjalan hingga bisa menyimpulkan kelebihan dan kekurangan dari aplikasi. Lingkup analisis yang akan dilakukan pada sistem sejenis terkait dengan empat hal yaitu: analisis mengenai bisnis proses dari sistem sejenis, pengguna dan peran pengguna dalam sistem sejenis, business rule sistem sejenis, dan model domain dari sistem sejenis.
4.1 Analisis Domain Masalah
Pada subbab ini akan dibahas analisis domain masalah dalam pengembangan aplikasi virtual account.
4.1.1 Analisis Virtual Account
Dalam era perubahan teknologi yang berkelanjutan, cara konsumen berinteraksi dan terlibat dengan bank telah berubah dalam beberapa tahun terakhir sebagai akibat dari adopsi teknologi yang cepat. Layanan perbankan dapat melayani kebutuhan konsumen dengan lebih baik dengan menawarkan produk seperti virtual account dengan alasan berikut:
1. Open Banking
Dengan adanya Open Banking, Lembaga perbankan dipaksa untuk berubah. Peraturan ini mengharuskan bank untuk menyerahkan kontrol data
transaksional kepada pelanggan. Informasi ini dapat dibagikan kepada pihak ketiga yang membangun alternatif layanan perbankan. Layanan baru yang diaktifkan oleh aturan Open Banking akan mencakup kemudahan akses untuk pembuatan rekening baru bagi para konsumen [BR-01].
Dengan adanya Open Banking, pelanggan bisa meminta berbagai layanan perbankan untuk bisa diakses secara cepat, real time, dan self service. Kombinasi dari keinginan konsumen yang meningkat terkait dengan kebutuhan layanan perbankan, Open Banking dan pasar yang sangat kompetitif sangat berarti bagi Lembaga perbankan. Lembaga perbankan harus fokus pada penyampaian produk dan layanan yang paling penting bagi pelanggan mereka. Untuk melakukan ini, mereka harus mengikuti perkembangan perbankan di level ritel. Layanan dasar yang wajib diberikan pada pelanggan yaitu layanan untuk bertransaksi secara non tunai dan real time antara pelanggan dengan ritel atau antar pelanggan [BR-02]. Hanya yang terus berubah dan berinovasi yang akan bertahan, berkembang, dan tumbuh.
2. 94% Bank mengatakan virtual account membantu memenangkan bisnis baru Virtual account memberikan kesempatan bagi Lembaga perbankan untuk memberikan layanan yang lebih baik dari harapan pelanggan. Ini karena pelanggan yang dapat dengan mudah mengakses informasi keuangan yang mereka inginkan ketika mereka menginginkannya secara langsung. Klien dari bank meminta fungsionalitas baru yang mampu menyelesaikan masalah bisnis proses mereka. Bank menyadari bahwa virtual account adalah alat untuk menyelesaikan masalah bisnis proses klien.
Penelitian juga menemukan bahwa 94% bank mengatakan bahwa akun virtual membantu mereka memenangkan pelanggan baru. Ini adalah tren yang berkembang cepat. Hampir semua bank yang disurvei (99%) mengklaim bahwa mereka saat ini menawarkan atau berniat untuk menawarkan solusi akun virtual dalam 18 bulan ke depan [16].
24
4.1.2 Evaluasi Domain Masalah
Dari analisis yang telah dilakukan berkenaan dengan virtual account yang telah dipaparkan, didapatlah daftar proses yang terjadi dalam sistem virtual account yang tertera pada Tabel 1.
Tabel 1 Hasil evaluasi domain masalah virtual account
Kode Aktor Nama Proses Analisa
Acuan
Dependensi Proses EPD-01 Customer Customer
Registration
[BR-01] p.23 EPD-02 Customer Customer Inquiry [BR-01] p.23
EPD-03 Customer Top Up Balance [BR-02] p.23 EPD-01 p.24 EPD-04 Customer Payment [BR-02] p.23 EPD-01 p.24
EPD-03 p.24 EPD-05 Customer Transfer [BR-02] p.23 EPD-01 p.24 EPD-03 p.24 EPD-06 Customer Transaction
History
[BR-02] p.23 EPD-01 p.24
4.2 Rencana Penerapan Rational Unified Process (RUP)
Pada subbab ini akan dibahas tahapan-tahapan yang akan dilalui selama membangun perangkat lunak dari usulan model bisnis virtual account yang telah dipaparkan serta artifact yang dihasilkan dari setiap tahapan dalam RUP. Hasilnya dipaparkan pada Tabel 2.
Tabel 2 Rencana Penerapan Rational Unified Process No Tahapan Jumlah
Iterasi
Artifact
1 inception 1 Model bisnis proses, business rule
2 elaboration 2 Model bisnis proses, business rule, model domain, use case text
3 construction 3 business rule, use case text, model struktur data, model arsitektur perangkat lunak, model statis perangkat lunak, dokumen spesifikasi API, dokumen skenario pengujian perangkat lunak
4 transition 2 model deployment perangkat lunak, dokumen konfigurasi perangkat lunak, dokumen
No Tahapan Jumlah Iterasi
Artifact
skenario pengujian perangkat lunak, dan dokumen hasil pengujian perangkat lunak
4.3 Analisis Sistem Sejenis: OVO
OVO merupakan mobile application milik PT Visionet Internasional yang fungsinya memberikan layanan kepada konsumen untuk bertransaksi secara non tunai di semua merchant bertanda OVO Accepted Here. Layanan transaksi non tunai yang dimiliki OVO merupakan implementasi dari virtual account.
4.3.1 Bisnis Proses Sistem OVO
Bisnis proses yang akan dianalisis pada sistem OVO yaitu: register customer, top up, payment, transfer, dan transaction history.
1. Bisnis proses register customer [BPO-01]
Analisis ini dilakukan berdasarkan hasil evaluasi domain masalah Customer Registration EPD-01 p.24 dengan tujuan mengidentifikasi proses pembuatan rekening virtual account. Proses ini dilakukan melalui aplikasi mobile OVO yang dapat diunduh di Google Playstore dan Apple Store. Alur bisnis proses register customer dijelaskan pada Gambar 1.
26
Gambar 1 Bisnis proses register customer
Keterangan dari alur bisnis proses register customer dijelaskan pada Tabel 3. Tabel 3 Keterangan model bisnis proses register customer OVO
No. Nama Proses Tipe Proses Keterangan
1 Send Customer Registration Data
Action OVO Mobile Apps mengirimkan data registrasi customer berupa: nama, nomor telepon, dan email ke OVO service
2 Check if customer is already registered
Decision OVO Service memeriksa apakah data customer yang diterima sudah terdaftar atau belum. yes: see Send Error Messages no: see Generate Token Verification
3 Generate Token Verification
Action OVO Service mebuat sebuah token verifikasi yang bertujuan untuk menghindari spam
No. Nama Proses Tipe Proses Keterangan 4 Send Token
Verification
Action OVO Mobile Apps mengirimkan token verifikasi untuk
mengkonfirmasi bahwa client yang menjalankan activity bukan fiktif.
5 Check if token is valid
Decision OVO Service memvalidasi token verifikasi yang dikirimkan oleh client dengan token yang dibuat pada proses Generate Token Verification
yes: see Send Customer Password
no: see Send Error Messages 6 Send Customer
Password
Action OVO Mobile Apps mengirimkan data password untuk digunakan sebagai authentication pada proses yang lain
7 Create Customer Action OVO Service membuat rekening virtual account baru berdasarkan data yang dikirimkan. Data nomor telepon akan menjadi nomor identifikasi virtual account dengan format: prefix OVO + nomor telepon customer 8 Send Error
Messages
Action OVO Service mengirimkan pesan error yang redaksinya sesuai dengan penyebab dari error tersebut
9 Display Messages Action OVO Mobile Apps menampilkan pesan informasi atau pesan error sesuai dengan apa yang
28
2. Bisnis proses customer inquiry [BPO-02]
Analisis ini dilakukan berdasarkan hasil evaluasi domain masalah Customer Inquiry EPD-02 p.24 dengan tujuan mengidentifikasi proses menampilkan informasi dari diri customer dan balance atau saldo virtual account kepada customer. Alur bisnis proses balance inquiry dijelaskan pada Gambar 2.
Gambar 2 Bisnis proses balance inquiry OVO
Tabel 4 Keterangan model bisnis proses balance inquiry OVO
No. Nama Proses Tipe Proses Keterangan
1 Send Auth Data Action OVO Mobile Apps mengirimkan request authentication berupa user identifier dan password 2 Check if
authentication is valid
Decision OVO Service menerima melakukan authentication berdasarkan request yang diterima
yes: see Get Customer & Account Data
no: see Send Error Messages 3 Get Customer &
Account Data
Action OVO Service mengambil data customer dan data account ke database berdasarkan user identifier yang telah terotentikasi 4 Send Error
Messages
Action OVO Service mengirimkan pesan error yang redaksinya sesuai dengan penyebab dari error tersebut
5 Display Messages Action OVO Mobile Apps menampilkan pesan informasi atau pesan error sesuai dengan apa yang
dikirimkan dari OVO Service 6 Display Customer
Balance
Action OVO Mobile Apps menampilkan informasi saldo atau balance milik customer
3. Bisnis proses top up [BPO-03]
Analisis ini dilakukan berdasarkan hasil evaluasi domain masalah Top Up EPD-03 p.24 dengan tujuan mengidentifikasi proses pengisian saldo awal ke rekening virtual account. Alur bisnis proses top up dijelaskan pada Gambar 3.
30
Gambar 3 Bisnis proses top up balance OVO
Keterangan dari alur bisnis proses top up balance dijelaskan pada Tabel 5. Tabel 5 Keterangan model bisnis proses top up balance OVO
No. Nama Proses Tipe Proses Keterangan
1 Transfer to OVO Virtual Account
Action Top Up Balance OVO bisa dilakukan dengan berbagai cara, yaitu: ATM, internet banking, mobile banking, debit card, dan melalui OVO booth yang tersebar di berbagai mall.
2 Check if virtual account is exists and active
Decision OVO Service menerima request top up dari Third Party Banking System lalu memeriksa apakah nomor virtual account yang ingin
No. Nama Proses Tipe Proses Keterangan di top up terdaftar dan masih aktif atau tidak.
yes: see Send Error Messages no: see Generate Token Verification
3 Transfer from Escrow to
Destination Virtual Account
Action OVO Service melakukan credit balance ke akun virtual account tujuan dan melakukan debit pada akun escrow OVO
Escrow OVO adalah mirroring akun dari akun giro OVO yang terdartar di Third Party Banking Systems
4 Send Error Messages
Action OVO Service mengirimkan pesan error yang redaksinya sesuai dengan penyebab dari error tersebut
5 Display Messages Action Third Party Banking Systems menampilkan pesan informasi atau pesan error sesuai dengan ketentuan yang berlaku di masing-masing system
4. Bisnis proses payment [BPO-04]
Analisis ini dilakukan berdasarkan hasil evaluasi domain masalah Payment EPD-04 p.24 dengan tujuan mengidentifikasi proses transaksi non tunai antara customer dengan merchant OVO menggunakan virtual account. Alur bisnis proses payment dijelaskan pada Gambar 4.
32
Gambar 4 Bisnis proses payment OVO
Keterangan dari alur bisnis proses payment dijelaskan pada Tabel 6. Tabel 6 Keterangan model bisnis proses payment OVO
No. Nama Proses Tipe Proses Keterangan
1 Send Payment Request
Action OVO Mobile Apps mengirimkan http request yang berisi payload payment berupa: debit account, credit account, amount,
transaction date, dan invoice number
2 Check if payment request is valid
Decision OVO Service memeriksa
payment request berdasarkan rule berikut:
No. Nama Proses Tipe Proses Keterangan
1. Credit account merupakan akun virtual account yang terdaftar di system OVO 2. Amount atau nominal
transaksi tidak boleh lebih besar dari balance atau saldo dari debit account
yes: see Do Transfer
no: see Send Error Message 3 Do Transfer Action OVO Service melakukan
perpindahan dana dari debit account ke credit account sejumlah nilai amount 4 Send Error
Messages
Action OVO Service mengirimkan pesan error yang redaksinya sesuai dengan penyebab dari error tersebut
5 Display Messages Action OVO Mobile Apps menampilkan pesan informasi atau pesan error sesuai dengan ketentuan yang berlaku di masing-masing sistem
5. Bisnis proses transfer [BPO-05]
Analisis ini dilakukan berdasarkan hasil evaluasi domain masalah Transfer EPD-05 p.24 dengan tujuan mengidentifikasi proses transaksi non tunai antar customer OVO secara peer-to-peer. Alur bisnis proses transfer dijelaskan pada Gambar 5.
34
Gambar 5 Bisnis proses transfer OVO
Keterangan dari alur bisnis proses transfer dijelaskan pada Tabel 7. Tabel 7 Keterangan model bisnis proses transfer OVO
No. Nama Proses Tipe Proses Keterangan
1 Send Payment Request
Action OVO Mobile Apps mengirimkan http request yang berisi payload payment berupa: debit account, credit account, amount,
transaction date, dan invoice number
2 Check if transfer request is valid
Decision OVO Service memeriksa
payment request berdasarkan rule berikut:
1. Credit account merupakan akun virtual account yang terdaftar di system OVO 2. Amount atau nominal
transaksi tidak boleh lebih besar dari balance atau saldo dari debit account
No. Nama Proses Tipe Proses Keterangan yes: see Do Transfer
no: see Send Error Message 3 Do Transfer Action OVO Service melakukan
perpindahan dana dari debit account ke credit account sejumlah nilai amount 4 Send Error
Messages
Action OVO Service mengirimkan pesan error yang redaksinya sesuai dengan penyebab dari error tersebut
5 Display Message Action OVO Mobile Apps menampilkan pesan informasi atau pesan error sesuai dengan ketentuan yang berlaku di masing-masing sistem
6. Bisnis proses transaction history [BPO-06]
Analisis ini dilakukan berdasarkan hasil evaluasi domain masalah transaction history EPD-06 p.24 dengan tujuan menampilkan catatan transaksi akun customer sebagai bagian dari aturan Open Banking. Alur bisnis proses transaction history dijelaskan pada Gambar 6.
36
Gambar 6 Bisnis proses transaction history OVO
Keterangan dari alur bisnis proses balance inquiry dijelaskan pada Tabel 8. Tabel 8 Keterangan model bisnis proses transaction history OVO
No. Nama Proses Tipe Proses Keterangan
1 Send Customer Identifier Id
Action OVO Mobile Apps mengirimkan request user identifier id
2 Check if
authenticated & session is valid
Decision OVO Service memeriksa validitas user identifier id dan session
yes: see Get Customer Transaction History
no: see Send Error Messages 3 Get Customer
Transaction History
Action OVO Service mengambil data catatan transaksi customer ke database berdasarkan user identifier yang telah tervalidasi
No. Nama Proses Tipe Proses Keterangan 4 Send Error
Messages
Action OVO Service mengirimkan pesan error yang redaksinya sesuai dengan penyebab dari error tersebut
5 Display Messages Action OVO Mobile Apps menampilkan pesan informasi atau pesan error sesuai dengan apa yang
dikirimkan dari OVO Service 6 Display Customer
Transaction History
Action OVO Mobile Apps menampilkan informasi riwayat transaksi milik customer
4.3.2 Pengguna dan Peran Pengguna dalam Sistem OVO
Pengguna yang terlibat untuk mengoperasikan Sistem OVO ada tiga yaitu:
1. PT Visionet Internasional selaku pemilik aplikasi OVO. Memiliki wewenang penuh dalam menentukan seluruh term & condition yang berlaku untuk operasional OVO.
2. OVO Customer selaku target pemasaran utama dari penggunaan aplikasi OVO. 3. OVO Merchant selaku rekanan dari PT Visionet Internasional dan menjadi tempat utama terjadinya transaksi non tunai dengan Customer menggunakan virtual account OVO.
4.3.3 Business Rule
Dari hasil pemaparan bisnis proses dan pengguna dari sistem OVO didapat business rule yang dijelaskan pada Tabel 9.
Tabel 9 Business rule OVO
ID Rule Referensi Keterangan
BRO-01 Setiap customer OVO diidentifikasi
berdasarkan email dan nomor telepon Analisis bisnis proses register customer [BPO-01] p.25, Analisis bisnis proses top up Nomor rekening virtual account customer merupakan kombinasi dari prefix OVO dan
38
ID Rule Referensi Keterangan
nomor telepon customer BRO-02 Proses transaksi non
tunai menggunakan OVO virtual account diinisiasi oleh dua pihak yaitu virtual account yang berada di posisi debit dan virtual account yang berada di posisi credit
Analisis bisnis proses payment [BPO-04] p.31, Analisis bisnis proses transfer [BPO-05] p.33 Customer bisa menjadi pihak yang berada di posisi debit dan credit ketika transaksi
sedangkan OVO merchant hanya bisa menjadi pihak yang berada di posisi credit
4.3.4 Model Domain
Model domain ini didapat dari hasil analisis proses bisnis dan business rule OVO. Gambar 7 merupakan conceptual class yang merepresentasikan dunia nyata dalam Aplikasi virtual account OVO.
Gambar 7 Domain Model OVO 4.4 Evaluasi Sistem Sejenis
Selain melakukan analisis terkait virtual account terhadap perangkat lunak OVO, dilakukan juga analisis terhadap perangkat lunak virtual account lain seperti Go-Pay, dan Dana.id. Hasilnya, bisnis proses yang dilakukan sangat mirip dengan bisnis proses OVO sehingga cukup diwakilkan dengan membahas bisnis proses OVO. Dengan adanya kemiripan bisnis proses ini maka untuk perangkat lunak virtual account yang akan dibuat akan mererapkan skema multi-company dimana satu engine virtual account bisa digunakan oleh banyak entitas secara simultan
dengan cara memberikan identifier pada setiap proses transaksi yang berlaku untuk masing-masing entitas.
Tabel 10 menampilkan hasil pemetaan evaluasi proses dari domain masalah dengan hasil analisis sistem sejenis yang telah dilakukan.
Tabel 10 Daftar Proses yang dievaluasi
No. Kode Nama Proses Acuan Bisnis
Proses
Rencana Implementasi 1 [EPD-01] Customer Registration [BPO-01] p.25 Ya 2 [EPD-02] Customer Inquiry [BPO-02] p.28 Ya 3 [EPD-03] Top Up Balance [BPO-03] p.29 Ya
4 [EPD-04] Payment [BPO-04] p.31 Ya
5 [EPD-05] Transfer [BPO-05] p.33 Ya
6 [EPD-06] Transaction History [BPO-06] p.35 Ya
Hasil evaluasi ini menjadi dasar dari aplikasi virtual account yang akan dibuat. Pemaparan usulan model bisnis aplikasi virtual account akan menggunakan pendekatan domain driven design. Langkah-langkah yang harus dilakukan telah dipaparkan pada bab landasan teori dengan subbab domain driven design. Domain yang akan dibahas yaitu virtual account.
Pembagian sub domain dilakukan berdasarkan proses-proses yang ada pada perangkat lunak virtual account yang telah dibahas pada bagian analisis. Hasil pembagiannya adalah sebagai berikut:
1. Proses-proses yang fokus pada pengelolaan data diri customer akan berada pada sub domain Customer Information File.
2. Proses-proses yang fokus pada kegiatan transaksi non tunai akan berada pada sub domain Account Transaction.
Tabel 11 Tabel responsibility sub domain No. Nama Bounded
Context
Responsibility Process 1 Customer Information
File
Customer Registration EPD-01 p.24, Customer Inquiry EPD-02 p.24
40
2 Transaction Top Up Balance EPD-03 p.24, Payment EPD-04 p.24, Transfer EPD-05 p.24, Transaction History EPD-06 p.24
4.5 Usulan Model Bisnis Aplikasi Virtual Account
Pada bagian ini akan dipaparkan usulan model bisnis aplikasi virtual account yang akan dibangun. Basis dari usulan ini adalah hasil evaluasi dari domain masalah dan hasil evaluasi sistem sejenis.
4.5.1 Bisnis Proses
Usulan bisnis proses dibuat berdasarkan evaluasi dari domain masalah dan evaluasi sistem sejenis yang telah dilakukan. Sesuai dengan hasil evaluasi yang telah dilakukan, rangkaian proses akan dikelompokkan menjadi bounded context dengan hasil pada Tabel 12.
Tabel 12 Bisnis proses usulan No. Nama Bounded
Context
Referensi Proses 1 Customer Information
File
Customer Registration EPD-01 p.24, Customer Inquiry EPD-02 p.24
2 Transaction Top Up Balance EPD-03 p.24, Payment EPD-04 p.24, Transfer EPD-05 p.24, Transaction History EPD-06 p.24
Seluruh bisnis proses dari aplikasi virtual account yang akan dibangun mereplikasi bisnis proses dari sistem sejenis sesuai dengan yang telah dipaparkan pada bagian evaluasi sistem sejenis. Penambahan bisnis proses yang akan dilakukan yaitu dengan menerapkan skema multicompany atau multigroup sehingga virtual account yang akan dibangun tidak hanya diperuntukkan untuk end customer saja namun bisa diterapkan di berbagai organisasi dengan masing-masing basis customer yang dimiliki oleh organisasi tersebut.
4.5.2 Pengguna dan Peran Pengguna
Pada sub subbab ini akan dipaparkan siapa saja stakeholoder atau pihak yang terlibat dan berkepentingan dalam operasional transaksi non tunai menggunakan virtual account. Analisis ini berdasar pada hasil observasi, wawancara dengan praktisi yang pernah terlibat dalam kegiatan dan pembuatan aplikasi virtual account serta hasil dari analisis sistem sejenis. Hasilnya, terdapat lima stakeholder yang terlibat dalam operasional transaksi non tunai menggunakan virtual account yaitu: bank, virtual account provider, organizations, customer, dan merchant. Gambar 8 memaparkan bagaimana hubungan pihak-pihak tersebut.
42
Penjelasan dari struktur pada Gambar 8 terjadi pada tabel Tabel 13 di bawah ini. Tabel 13 Daftar pengguna dan peran pengguna
No Stakeholder Kepentingan
1 Organizations 1. Memberikan pelayanan transaksi non tunai bagi semua customers sebagai bagian dari peningkatan pelayanan pada pelanggan 2. Mengurangi potensi terjadinya korupsi
dengan cara melakukan transparansi pembayaran atas layanan yang diberikan 2 Virtual Account Provider 1. Menjadi penyedia layanan transaksi non
tunai bagi berbagai jenis dan bidang organisasi melalui penggunaan virtual account
3 Bank 1. Memiliki sebanyak mungkin nasabah
2. Mengurangi sebesar mungkin biaya operasional akuisisi nasabah dan biaya pengelolaan uang tunai
4 Customer 1. Melakukan pembayaran atas layanan yang diberikan oleh Organizations atau Merchant dengan cepat dan aman
5 Merchant 1. Menyediakan layanan pembayaran melalui transaksi non tunai bagi customer sebagai usaha menumbuhkembangkan bisnis
4.5.3 Business Rule
Berdasarkan usulan bisnis proses dan pihak yang terlibat dalam operasional transaksi non tunai menggunakan virtual account, maka ditentukan business rule yang dipaparkan pada Tabel 14.
Tabel 14 Usulan business rule
ID Rule
BRM-1 Customer wajib mendaftarkan diri melalui aplikasi virtual account untuk mengakses layanan transaksi non tunai.
Data customer yang harus dilengkapi dalam proses pendaftaran yaitu:
1. Nama 2. Email 3. No telepon
BRM-2 Setiap customer yang telah terdaftar akan memiliki rekening virtual account yang nomor identifikasinya adalah kombinasi dari kode unik organisasi dan nomor telepon customer.
BRM-3 Transaksi non tunai diizinkan jika dan hanya jika:
1. Virtual account pengirim (debit account) dan virtual account penerima (credit account) terdaftar dan berstatus aktif
2. Saldo (balance) dari Virtual account pengirim (debit account) lebih besar atau sama dengan nominal transaksi yang dilakukan BRM-4 Customer berhak melihat riwayat transaksi berdasarkan nomor
virtual account
BRM-5 Stakeholder dikelompokkan menjadi dua bagian: 1. Back Office, dengan anggota:
a. Organizations
b. Virtual Account Provider c. Bank
2. Customer, dengan anggota: a. Customer
b. Merchant
BRM-6 Setiap Organization memiliki unique identifier
4.5.4 Model Domain
Pada subbab ini akan dijelaskan model domain dari aplikasi yang akan dibangun. Model domain ini dibuat berdasarkan bisnis proses dan business rule yang telah dibuat. Domain model akan digambarkan untuk per bounded context yaitu: customer information file dan transaction.
1. Model Domain Bounded Context Customer Information File (DMCIF)
Model domain untuk bounded context Customer Information File disajikan pada pada Gambar 9.
44
Gambar 9 Model domain usulan Bounded Context Customer Information File
Penjelasan model domain usulan untuk bounded context customer information file dijelaskan melalui Tabel 15 - Tabel 18.
Tabel 15 Keterangan entitas Customer Customer
Pengguna dari aplikasi virtual account
Atribut Keterangan
name Nama pengguna aplikasi virtual account email Email pengguna aplikasi virtual account
phone Nomor telepon pengguna aplikasi virtual account username Identifier pengguna aplikasi virtual account password Kata sandi autentikasi pengguna
Tabel 16 Keterangan entitas Customer Verification Customer Verification
Verifikasi untuk menjadi customer aplikasi virtual account
Atribut Keterangan
token Kata sandi untuk aktivasi menjadi customer
requestor Entitas yang mengajukan pembuatan token verifikasi expire_time Tengat waktu masa aktif penggunaan token verifikasi
Tabel 17 Keterangan entitas Account Account
Akun untuk melakukan transaksi non tunai dalam aplikasi virtual account
Atribut Keterangan
account_number Nomor identifikasi virtual account
balance Saldo yang bisa digunakan untuk proses transaksi non tunai
Tabel 18 Keterangan entitas Group Group
Superset dari customer yang tidak saling beririsan
Atribut Keterangan
group_code Nomor identifikasi Group group_name Nama Group
2. Model Domain Bounded Context Transaction (DMTRX)
Model domain untuk bounded context Customer Information File disajikan pada pada Gambar 10.
46
Penjelasan model domain usulan untuk bounded context transaction dijelaskan melalui Tabel 19 - Tabel 23.
Tabel 19 Keterangan entitas Account Account
Akun untuk melakukan transaksi non tunai dalam aplikasi virtual account
Atribut Keterangan
account_number Nomor identifikasi virtual account
balance Saldo yang bisa digunakan untuk proses transaksi non tunai
Tabel 20 Keterangan entitas Account Type Account Type
Tipi akun yang mengatur limitasi transaksi dari akun virtual account
Atribut Keterangan
name_of_account_type Nama identifikasi dari tipe akun limit_configuration Konfigurasi limitasi transaksi
Tabel 21 Keterangan entitas Account Transaction Account Transaction
Catatan transaksi debit dan kredit dari akun virtual account
Atribut Keterangan
transaction_time Timestamp transaksi debit amount Jumlah nominal debit credit amount Jumlah nominal kredit
balance Saldo setelah proses debit atau kredit dilakukan previous transaction Pointer ke catatan transaksi sebelumnya. Diperlukan
untuk memvalidasi perubahan saldo.
Tabel 22 Keterangan entitas Journal Transaction Journal Transaction
Catatan pasangan akun yang saling melakukan transaksi debit dan kredit
Atribut Keterangan
debit_account Akun yang di debit credit_account Akun yang di credit transaction_amount Jumlah nominal transaksi
Tabel 23 Keterangan entitas Account Type Transaction Type
Kategori atau jenis transaksi
Atribut Keterangan
name_of_transaction_type Identitas jenis transaksi 4.6 Evaluasi Gap Analisis
Bagian ini akan membahas gap antara sistem sejenis yang telah dianalisis dan sistem yang akan dibangun yang telah dipaparkan pada subbab usulan model bisnis virtual account.
Dari sisi fungsionalitas yang telah dibahas pada bagian bisnis proses, tidak ada perbedaan antara virtual account dari sistem sejenis dengan virtual account yang akan dibangun. Karena dari sisi fungsionalitas, sistem sejenis sudah memenuhi aturan Open Banking.
Berdasarkan hasil analisis dan pembahasan yang telah dilakukan, perbedaan antara virtual account dari sistem sejenis dengan virtual account yang akan dibangun dapat dilihat dari pengguna dan peran pengguna dari masing-masing perangkat lunak dan business rule yang digunakan.
Rangkuman gap analisis disajikan pada Tabel 24 di bawah ini. Tabel 24 Hasil Evaluasi Gap Analisis
No Gap Point Sistem Sejenis Sistem yang Akan Dibangun 1 Pengguna dan Peran
Pengguna
Skema Single Company: PT Visionet Internasional
Skema Multi Company: Many Organizations use single core system 2 Business Rule Transaksi tidak bisa
lintas company
Transaksi bisa lintas company
48
4.7 Kebutuhan Perangkat Lunak
Dari usulan model bisnis aplikasi virtual account yang telah dipaparkan, dibuatlah model requirement perangkat lunak untuk memaparkan kebutuhan-kebutuhan yang perlu dipenuhi untuk mewujudkan aplikasi virtual account yang sesuai dengan usulan model bisnis yang telah dibuat.
4.7.1 Daftar Aktor
Dari daftar kebutuhan yang telah dipaparkan sebelumnya, maka use case actor yang terbentuk dapat dilihat pada Tabel 25.
Tabel 25 Daftar Use Case Actor dari Aplikasi Virtual Account
No Nama Aktor Penjelasan
1 Back Office Penjabaran dari stakeholder sesuai dengan business rule point BRM-5 p.43
2 Customer Penjabaran dari stakeholder sesuai dengan business rule point BRM-5 p.43
4.7.2 Daftar Use Case
Berdasarkan hasil analisa fungsi bisnis dan daftar kebutuhan yang telah dipaparkan, berikut adalah use case yang perlu ada untuk memenuhi kebutuhan yang telah didefinisikan.
Tabel 26 Daftar Use Case aplikasi virtual account
Kode Nama Use Case Penjelasan Acuan Analisa
UC-REG
Register Customer
Mengelola proses registrasi customer baru dari mulai skenario pelengkapan data customer, verifikasi customer, dan aktivasi akun customer. [EPD-01] UC-ACC Register Account
Mengelola proses pembuatan akun yang berfungsi sebagai identifikasi customer dalam melakukan transasksi non tunai. Definisi akun disini ekuivalen dengan istilah akun dalam ilmu
Kode Nama Use Case Penjelasan Acuan Analisa akuntansi. Digunakan sebagai
pelaku yang terlibat proses jurnaling atau proses debit dan kredit.
UC-TRX
Fund Transfer Memproses transaksi keuangan yang artinya melakukan prosedur debit dan kredit antar akun-akun yang terlibat dalam setiap transaksi. [EPD-03] p.39, [EPD-04] p.39, [EPD-05] p.39 UC-RPT
View Report Melakukan pencarian dan melihat data customer dan riwayat transaksi yang telah dilakukan customer berdasarkan kriteria pencarian tertentu.
[EPD-06] p.39
4.8 Use Case Text
Use case adalah kebutuhan perangkat lunak yang mengindikasikan apa yang harus sistem lakukan. Melalui use case text, kebutuhan perangkat lunak dipaparkan. Terdapat 4 use case text yang menjelaskan kebutuhan dan model perilaku dari aplikasi yang akan dibuat yaitu: use case text register customer, use case text register account, use case text fund transfer, dan use case text reporting.
4.8.1 Use Case Text Register Customer (UC-REG)
Use case Section Comment Use case name Register Customer Scope Aplikasi Virtual Account Level User goal
Primary Actor Customer Stakeholders
and Interests
Customer: Ingin mendaftarkan diri sebagai pengguna aplikasi virtual account agar bisa menggunakan layanan-layanan yang disajikan oleh aplikasi virtual account.
50
Use case Section
Comment
Preconditions 1. Data customer belum terdaftar sebagai pengguna aplikasi virtual account
Success Guarantee
1. Data customer tercatat di database virtual account Main Success
Scenario
1. Customer submit data pendaftaran customer baru 2. Sistem mengenerate token registrasi
3. Customer melakukan verifikasi pendaftaran dengan menggunakan token yang diberikan
4. Sistem memverifikasi token pendaftaran customer 5. Sistem mencatat data customer ke database
6. Sistem melakukan prosedur Register Account (UC-ACC) Extensions 1a. Data customer sudah terdaftar di database
1. Sistem menampilkan pesan error “Customer sudah terdaftar”
2. Proses pendaftaran customer baru dihentikan 1b. Data customer yang dikirim tidak lengkap
1. Sistem menampilkan pesan error “Data yang dikirimkan tidak lengkap, silakan lengkapi”
2. Proses pendaftaran customer baru dihentikan 4a. Token verifikasi tidak valid
1. Sistem menampilkan pesan error “Token verifikasi tidak ditemukan”
2. Proses pendaftaran customer baru dihentikan Special
Requirements
1. Identifier customer adalah field email dan nomor telepon Technology
and Data Variations List
Data input form pendaftaran customer terdiri dari: 1. Nama 2. Email 3. Nomor telepon 4. Password Aplikasi Frequency of Occurrence
Setiap kali Customer melakukan pendaftaran sebagai customer baru.
4.8.2 Use Case Text Register Account (UC-ACC) Use case Section Comment Use case name Register Account
Scope Aplikasi Virtual Account Level User goal
Primary Actor Customer, Back Office Stakeholders
and Interests
Back Office: Ingin melakukan konfigurasi awal akun-akun escrow yang diperlukan untuk operasional aplikasi Virtual Account
Customer: Ingin bisa menggunakan layanan transaksi non-tunai menggunakan aplikasi virtual account
Preconditions 1. Data account belum terdaftar di database virtual account Success
Guarantee
1. Customer: data account telah terbentuk dan berelasi dengan data customer.
Customer mendapatkan nomor identifikasi virtual account 2. Backoffice: data account escrow telah terbentuk dan tidak
bisa digunakan langsung oleh customer. Main Success
Scenario
A. Customer:
1. Customer berhasil melakukan prosedur Register Customer (UC-REG)
2. Sistem mengenerate data account lalu merelasikan data tersebut dengan data customer yang bersangkutan
3. Sistem menyimpan data account ke database B. Back Office
1. Back Office mengisi lalu submit form pembuatan account 2. Sistem menyimpan data account ke database
Extensions B1-a. Data account sudah terdaftar di database
a. Sistem menampilkan pesan error “Account sudah terdaftar”
b. Proses pembuatan account baru dihentikan Special
Requirements
52 Use case Section Comment Technology and Data Variations List none Frequency of Occurrence
1. Setiap kali Customer berhasil melakukan pendaftaran sebagai customer baru.
2. Setiap kali Back Office ingin mendaftarkan account baru untuk keperluan operasional
Miscellaneous none
4.8.3 Use Case Text Fund Transfer (UC-TRX)
Use case Section Comment Use case name Fund Transfer
Scope Aplikasi Virtual Account Level User goal
Primary Actor Customer Stakeholders
and Interests
Customer: Ingin menggunakan layanan pembayaran non-tunai Preconditions 1. Account pengirim dan penerima terdaftar di sistem virtual
account
2. Account pengirim memiliki saldo > 0 3. Nominal transfer > 0
Success Guarantee
1. Saldo account pengirim berkurang sejumlah nominal transfer
2. Saldo account penerima bertambah sejumlah nominal transfer
3. Data transfer tercatat di database Main Success
Scenario
1. Customer melakukan request fund transfer
2. Sistem melakukan validasi dan posting (proses debit dan kredit) berdasarkan request fund transfer
Use case Section
Comment
Extensions 2a. Account penerima tidak terdaftar di sistem
1. Sistem menampilkan pesan error “Nomor tujuan tidak ditemukan”
2. Proses fund transfer dihentikan
2b. Saldo account pengirim lebih kecil dari nominal transfer 1. Sistem menampilkan pesan error “Saldo Anda tidak
cukup”
2. Proses transfer dihentikan Special
Requirements
1. Setiap 1 cycle tidak boleh melebihi 30 detik
2. Terdapat mekanisme void atau reversal untuk proses posting Technology
and Data Variations List
request fund transfer 1. Nominal transaksi 2. Debitor Account 3. Creditor Account 4. Tipe transaksi Frequency of Occurrence
Setiap kali Customer menggunakan jasa layanan transaksi non-tunai menggunakan aplikasi virtual account.
Miscellaneous none
4.8.4 Use Case Text View Report (UC-RPT)
Use case Section Comment Use case name View Report
Scope Aplikasi Virtual Account Level User goal
Primary Actor Customer, Backoffice Stakeholders
and Interests
Customer: Mengetahui saldo saat ini dan melihat riwayat mutasi rekening sesuai dengan aturan open banking
Backoffice: Sebagai source of truth dari proses rekonsiliasi Preconditions 1. Customer telah melalui proses Register Customer
54 Use case Section Comment Success Guarantee
1. Customer dapat melihat informasi saldo di virtual account dan melihat mutase rekening dari virtual account
2. Backoffice data melihat riwayat transaksi dari seluruh customer yang terurut berdasarkan timestamp transaksi Main Success
Scenario
1. Customer melakukan request data informasi saldo atau informasi mutasi rekening
2. Sistem menampilkan informasi saldo atau mutasi rekening berdasarkan virtual account milik customer requestor Extensions 2a. Customer belum pernah melakukan Fund Transfer
(UC-TRX) p.52
1. Sistem menampilkan saldo 0 dan menampilkan list kosong untuk informasi mutasi rekening
Special Requirements
1. Informasi mutasi rekening diurutkan berdasarkan data paling baru
2. Informasi mutasi rekeing ditampilkan berdasarkan periode tanggal Technology and Data Variations List Frequency of Occurrence
Setiap kali Customer atau Backoffice melakukan permintaan informasi saldo atau informasi mutasi rekening
