BAB 4
HASIL EVALUASI & REKOMENDASI PROSES BISNIS
4.1 Business Process Model
Proses awal dari rekomendasi proses bisnis yang di usulkan adalah mengumpulkan daftar proses – proses apa saja yang mengalami perubahan dari proses bisnis pembelian, penjualan dan pembayaran. Daftar-daftar proses bisnis yang ada di tunjukkan mana yang mengalami perubahan proses bisnis, yang tidak mengalami perubahan dan yang diperbaharui yang digambarkan dengan tabel
Business Process Model.
Tabel ini terdiri dari :
• Activities : yang berisi aktivitas proses – proses bisnis pada PT Tirta Amarta.
• Requirement : yang berisi kebutuhan- kebutuhan user pada sistem Everest
yang digunakan pada PT Tirta Amarta.
• Old State : adalah kondisi dimana sebuah proses terdapat pada kondisi sistem
lama atau kondisi sekarang yang sedang berjalan.
• New State : adalah kondisi dimana sebuah proses terdapat pada kondisi
sistem baru atau sistem yang direkomendasikan.
• Comment : sebuah kondisi yang menjelaskan apakah proses tersebut sudah
ada dan tidak mengalami perubahan (fit), proses tersebut sudah ada dan mengalami perbaikan/perubahan (partial fit), proses tersebut tidak ada dan mengalami pengembangan/penambahan (gap).
Berikut merupakan Business Process Model dari proses penjualan yang berisi aktivitas atau proses bisnis penjualan, kebutuhan sistem untuk mendukung proses bisnis, kondisi dari masing-masing kebutuhan dan keterengan dari kondisi setiap
requirement tersebut :
Tabel 4.1
Business Process Model dari Pembelian
Activities Requirement Old State New State Comment Proses menambah vendor baru
Sistem yang dapat menambahkan data vendor baru ke database perusahaan
✓ ✓ Requirement ini
bestatus “Fit” sehingga tidak ada
Customizing atau Developing Proses pembuatan Purchase Order ke pabrik Bandung Sistem yang pembuatan Purchase Order dikhususkan untuk admin warehouse ✓ ✓ Requirement ini berstatus “Partial Fit” sehingga memerlukan Customizing ( Updated)
Sistem yang dapat mencetak
Purchase Order
✓ ✓ Requirement ini
berstatus “Partial
Fit” karena fitur
telah tersedia tapi tidak digunakan
Sistem yang dapat memberikan notifikasi ketika stok barang gudang telah mencapai titik re –order point - ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Proses penerimaan barang dari pabrik
Sistem yang dapat membuat Bukti Terima Barang (Purchase
Receipt) yang
dibuat oleh bagian
Warehouse ✓ ✓ Requirement ini bersifat “Partial Fit” karena membutuhkan Customizing (Update) pada sistem Proses penerimaan &
menandatangani
Delivery Note dari
pabrik bandung
- - - -
Proses pembuatan
Purchase Invoice
Sistem yang dapat membuat
Purchase Invoice
dari Delivey Note yang diterima yang dibuat oleh bagian Finance
✓ ✓ Requirement ini
bersifat “Fit” sehingga tidak perlu
Customizing/ Developing
(Kasir) Proses pembayaran
ke pabrik Bandung
Sistem yang dapat memberikan peringatan jatuh tempo pembayaran yang harus dilakukan ke pabrik Bandung - ✓ Requirement ini tergolong “Gap” karena memerlukan Development (Coding) untuk menambah fitur
Sistem yang dapat melakukan pelunasan atas Purchase Invoice yang telah dibayarkan menjadi Bukti Kas Keluar dalam database - ✓ Requirement ini tergolong “Gap” karena memerlukan Development (Coding) untuk menambah fitur Proses pembuatan Laporan masuk barang ke gudang dari pabrik Bandung
Sistem yang dapat membuat Laporan secara otomatis berdasarkan data dari Purchase
Order, Delivery Note dan Puchase
✓ ✓ Requirement ini
bersifat “Fit” sehingga tidak perlu
Customizing/ Developing
Invoice
Berikut merupakan Business Process Model dari proses pembelian yang berisi aktivitas atau proses bisnis penjualan, kebutuhan sistem untuk mendukung proses bisnis, kondisi dari masing-masing kebutuhan dan keterengan dari kondisi setiap requirement tersebut :
Tabel 4.2
Business Process Model dari Penjualan
Activities Requirements Old State New State Keterangan Penjualan Kredit Membuat Customer baru Sistem memiliki kemampuan untuk mencatat dan
menyimpan data dari
customer baru. ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing Menambahkan Credit Limit Customer Sistem memiliki kemampuan untuk menganalisa performa pembayaran customer selama periode tiga bulan. - ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development
sistem (coding) Meminta persetujuan Manager Accounting untuk menerima penaikkan Credit Limit - - - - Menerima pesanan dari Customer Sistem memiliki kemampuan untuk menerima data pemesanan dari
customer secara online
atau melalui website perusahaan. - ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Membuat Bukti Pemesanan - - - - Membuat Sales
Order dan Delivery Order
Sistem memiliki kemampuan untuk mencatat dan
menyimpan data serta jumlah barang yang dipesan oleh customer.
✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/
Developing
Sistem dapat
memberikan notifikasi jika credit limit
customer sudah tidak
cukup untuk melakukan pemesanan. ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing Sistem mampu memberikan notifikasi jika jumlah stock tidak dapat memenuhi jumlah barang yang dipesan. ✓ ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Sistem memiliki kemampuan untuk men-generate dan meng-edit data dari
Sales Order yang telah
dibuat sebelumnya untuk dibuat menjadi Surat Pengiriman Barang (Delivery - ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding)
Order) Sistem memiliki kemampuan untuk mencetak secara otomatis Surat pengiriman barang (Delivery Order) yang telah dibuat sebelumnya. - ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Melakukan pengemasan barang untuk siap dikirim
- - - - Melakukan pengiriman barang - - - - Membuat Stock Transfer untuk Invoice Bulanan Sistem memiliki kemampuan untuk melakukan pengurangan stock barang yang ada di sistem. ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing
Membuat Invoice Sistem memiliki kemampuan untuk membuat surat penagihan (Invoice) ✓ ✓ Requirement ini bersifat “Fit” sehingga
atas penjualan yang telah dilakukan oleh
customer. tidak perlu Customizing/ Developing Sistem memiliki kemampuan untuk melakukan pengurangan stock barang sesuai dengan jumlah barang yang dikirim ke customer. ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing Sistem memiliki kemampuan untuk mencetak Surat penagihan (Invoice) yang telah dibuat sebelumnya. ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing Membuat Laporan Penjualan Sistem memiliki kemampuan untuk mencetak hasil laporan penjualan dalam periode tertentu (harian, mingguan dan bulanan) ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing Penjualan Tunai
Membuat Customer baru
Sistem memiliki kemampuan untuk mencatat dan
menyimpan data dari
customer baru. ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing Menambahkan Credit Limit Customer Sistem memiliki kemampuan untuk menganalisa performa pembayaran customer selama periode tiga bulan. - ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Meminta persetujuan Manager Accounting untuk menerima penaikkan Credit Limit - - - - Menerima pesanan dari Customer Sistem memiliki kemampuan untuk menerima data - ✓ Requirement ini bersifat “ Gap”
pemesanan dari
customer secara online
atau melalui website perusahaan. sehingga membutuhkan Development sistem (coding) Membuat Bukti Pemesanan - - - - Membuat Sales
Order dan Performa Invoice
Sistem memiliki kemampuan untuk mencatat dan
menyimpan data serta jumlah barang yang dipesan oleh customer.
✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing Sistem dapat memberikan notifikasi jika credit limit
customer sudah tidak
cukup untuk melakukan pemesanan. ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing Sistem mampu memberikan notifikasi jika jumlah stock tidak dapat memenuhi
✓ ✓ Requirement
ini bersifat “
Gap”
jumlah barang yang dipesan. membutuhkan Development sistem (coding) Sistem memiliki kemampuan untuk men-generate dan meng-edit data dari
Sales Order yang telah
dibuat sebelumnya untuk dibuat menjadi
Delivery Order yang
sekaligus dapat digunakan untuk menagih customer (Performa Invoice). - ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Sistem memiliki kemampuan untuk mencetak secara otomatis Performa
Invoice yang telah
dibuat sebelumnya. - ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Melakukan - - - -
pengemasan barang untuk siap dikirim Melakukan
pengiriman barang
- - - -
Membuat Invoice Sistem memiliki kemampuan untuk membuat surat penagihan (Invoice) atas penjualan yang telah dilakukan oleh
customer. ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing Sistem memiliki kemampuan untuk melakukan pengurangan stock barang sesuai dengan jumlah barang yang dikirim ke customer. ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing Sistem memiliki kemampuan untuk mencetak Surat penagihan (Invoice) yang telah dibuat sebelumnya. ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing
Membuat Credit Memo Sistem memiliki kemampuan untuk melakukan pemotongan tagihan kepada customer karena adanya retur barang. ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing Sistem memiliki kemampuan untuk mencetak Invoice yang baru (Invoice Retur) karena adanya
pemotongan penagihan karena retur barang.
✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing Membuat Laporan Penjualan Sistem memiliki kemampuan untuk mencetak hasil laporan penjualan dalam periode tertentu (harian, mingguan dan bulanan) ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing
Berikut merupakan Business Process Model dari proses pembayaran yang berisi aktivitas atau proses bisnis penjualan, kebutuhan sistem untuk mendukung
proses bisnis, kondisi dari masing-masing kebutuhan dan keterengan dari kondisi setiap requirement tersebut :
Tabel 4.3
Business Process Model dari Pembayaran
Activities Requirement Old State New State Keterangan
Pembayaran secara cash/tunai
Bagian AR
melakukan pengecekan
invoice yang telah
jatuh tempo Sistem memiliki kemampuan untuk menampilkan invoice - invoice. Di : Menu Invoicing – Sales Invoice ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing Sistem memiliki kemampuan untuk menampilkan notifikasi
invoice yang akan jatuh
tempo pada periode tertentu. - ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Collector melakukan penagihan kepada customer Sistem memiliki kemampuan untuk menyusun agenda collector dalam penagihan customer (meliputi prioritasi alamat
- ✓ Requirement
ini bersifat “
Gap” sehingga
membutuhkan
customer) sistem (coding) Collector melakukan setoran ke kasir - - - - Kasir melakukan pengecekan uang yang diterima - - - - Kasir membuat bukti kas terima
Sistem memiliki kemampuan untuk membuat bukti kas terima.
- ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Sistem memiliki kemampuan untuk mencetak bukti kas terima.
- ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Kasir melakukan pelunasan di sistem Sistem memiliki kemampuan untuk
meng-update credit limit
customer. Di : Menu Accounting – Receipt Journal ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing
Pembayaran secara giro
Bagian AR
melakukan pengecekan invoice yang telah jatuh tempo Sistem memiliki kemampuan untuk menampilkan invoice - invoice. Di : Menu Invoicing – Sales Invoice ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing Sistem memiliki kemampuan untuk menampilkan notifikasi
invoice yang akan jatuh
tempo pada periode tertentu. - ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Collector melakukan penagihan kepada cutomer Sistem memiliki kemampuan untuk menyusun agenda collector dalam penagihan customer (meliputi prioritasi alamat
customer) - ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Collector melakukan setoran giro ke bagian finance - - - - Bagian finance mencairkan giro - - - -
dan melakukan setoran ke rekening PT. Tirta Amarta Bagian finance memberikan slip setoran dan invoice ke bagian kasir - - - - kasir membuat bukti kas terima
Sistem memiliki kemampuan untuk membuat bukti kas terima .
- ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Sistem memiliki kemampuan untuk mencetak bukti kas terima.
- ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Kasir melakukan pelunasan di sistem Sistem memiliki kemampuan untuk
meng-update credit limit
customer.
✓ ✓ Requirement
ini bersifat “Fit” sehingga
Di : Menu Accounting –
Receipt Journal
Customizing/ Developing
Pembayaran secara transfer
Customer melakukan transfer pembayaran sesuai jadwalnya - - - - Customer memberikan bukti transfer & invoice ke bagian finance - - - - Bagian finance melakukan pencetakan rekening Koran - - - - Bagian finance melakukan konfirmasi ke kasir - - - - Kasir membuat bukti kas terima
Sistem memiliki kemampuan untuk membuat bukti kas terima.
- ✓ Requirement
ini bersifat “
Gap” sehingga
membutuhkan
sistem (coding) Sistem memiliki
kemampuan untuk mencetak bukti kas terima.
- ✓ Requirement ini bersifat “ Gap” sehingga membutuhkan Development sistem (coding) Kasir melakukan pelunasan di sistem Sistem memiliki kemampuan untuk
meng-update credit limit
customer. Di : Menu Accounting – Receipt Journal ✓ ✓ Requirement ini bersifat “Fit” sehingga tidak perlu Customizing/ Developing
Terdapat 16 fungsi yang akan diaplikasikan kedalam sistem Everest berdasarkan evaluasi dengan metode Fit/Gap Analysis. Dimana terdapat 2 fungsi yang mengalami kondisi Partial Fit yang akan dilakukan perencanaan customizing
setting sistem Everest dan 14 fungsi yang mengalami kondisi Gap yang akan
dilakukan perencanaan developing atau pengembangan kode program (coding) sistem Everest.
Gambar 4.1
Diagram Business Process Model
4.2 Mapping Class Diagram
Berikut merupakan tampilan database perusahaan pada Head Office dan kantor cabang yang berhubungan dengan proses pembelian, penjualan dan pembayaran. Saat ini, database keduanya berbeda sehingga data tidak terintegrasi.
4.2.1 Class Diagram Head Office -id_customer -nama_customer -alamat_customer -telepon_customer -credit_limit -Jumlah_piutang Customer_HeadOffice -id_vendor -nama_vendor -alamat_vendor -telepon_vendor Vendor_HeadOffice -id_SO -id_customer -total_pesan -Metode_pembayaran -tgl_SO -Notes Sales_Order_HeadOffice -id_invoice -id_Customer -id_SO -total_pesan -tgl_invoice Invoice_HeadOffice -id_PO -id_vendor -id_inventory -total_pesan -tgl_PO Purchase_Order_HeadOffice -id_CM -id_Customer -id_invoice -jumlah_retur -tgl_CM Credit_memo_HeadOffice -id_PR -id_PO -jumlah_barang_diterima -tgl_PR Purchase_Receipt_HeadOffice -id_PI -id_PR -total_bayar -tgl_PR Purchase_Invoice_HeadOffice -id_RJ -id_customer -id_invoice -total_bayar -tgl_bayar Receipt_Journal_HeadOffice 1 1..* 1 1..* 1 1 1 1 1 1 1 1 -id_so -id_barang -qty_SO -Diskon Detil_sales_order_HeadOffice * 1 1 1..* 1 1 1 1 -id_PO -id_barang -qty_PO Detil_purchase_order_HeadOffice 1 1..* 1..* 1 -id_CM -id_Barang -qty_CM -Detil_CreditMemo_HeadOffice 1 1..* -id_invoice -id_barang -qty_invoice -harga Detil_Invoice_HeadOffice 1 1..* 1 1..* -id_barang -nama_barang -harga _barang -stock_barang -ROP_barang Barang_HeadOffice -id_PR -id_barang -qty_PR Detil_Purchase_Receipt_HeadOffice 1 1..* 1 1..* 1 1..* 1 1..* 1 1..* Gambar 4.2
Class Diagram Head Office PT Tirta Amarta
-id_customer -nama_customer -alamat_customer -telepon_customer -credit_limit -Jumlah_piutang Customer_Cabang -id_vendor -nama_vendor -alamat_vendor -telepon_vendor Vendor_Cabang -id_SO -id_customer -total_pesan -Metode_pembayaran -tgl_SO -Notes Sales_Order_Cabang -id_invoice -id_Customer -id_SO -total_pesan -tgl_invoice Invoice_Cabang -id_PO -id_vendor -id_inventory -total_pesan -tgl_PO Purchase_Order_Cabang -id_CM -id_Customer -id_invoice -jumlah_retur -tgl_CM Credit_memo_Cabang -id_PR -id_PO -jumlah_barang_diterima -tgl_PR Purchase_Receipt_Cabang -id_PI -id_PR -total_bayar -tgl_PR Purchase_Invoice_Cabang -id_RJ -id_customer -id_invoice -total_bayar -tgl_bayar Receipt_Journal_Cabang 1 1..* 1 1..* 1 1 1 1 1 1 1 1 -id_so -id_barang -qty_SO -Diskon Detil_sales_order_Cabang * 1 1 1..* 1 1 1 1 -id_PO -id_barang -qty_PO Detil_purchase_order_Cabang 1 1..* 1..* 1 -id_CM -id_Barang -qty_CM -Detil_CreditMemo_Cabang 1 1..* -id_invoice -id_barang -qty_invoice -harga Detil_Invoice_Cabang 1 1..* 1 1..* -id_barang -nama_barang -harga _barang -stock_barang -ROP_barang Barang_Cabang -id_PR -id_barang -qty_PR Detil_Purchase_Receipt_Cabang 1 1..* 1 1..* 1 1..* 1 1..* 1 1..* Gambar 4.3
Class Diagram Kantor Cabang PT Tirta Amarta
Untuk mengatasi permasalahan integrasi ini, kami melakukan mapping ulang untuk database PT Tirta Amarta jika melakukan integrasi database pada kantor- kantor distribusi mereka. Mapping penggabungan ini dilakukan dengan membuat
4.2.3 Mapping Database PT Tirta Amarta (Head Office & Kantor cabang)
Gambar 4.4
Class Diagram Penggabungan database
4.3 Rancangan solusi alur sistem dengan Use Case Diagram PT Tirta Amarta Dari analisa FIT/GAP yang telah dilakukan pada bab 3, didapatkan beberapa perubahan pada alur sistem karena adanya customizing pada sistem Everest. Berikut
merupakan rancangan perubahan alur sistem PT Tirta Amarta sesuai dengan solusi yang telah diberikan.
4.4 Use Case Description dari Use Case Diagram PT Tirta Amarta
4.4.1 Use Case Description proses Pembelian PT Tirta Amarta
Tabel 4.4
Use Case Description Membuat Purchase Order
1. Use Case name Membuat Purchase Order
Scenario Membuat Purchase Order untuk melakukan pemesanan barang ke pabrik Bandung
Trigerring Event Stok barang di Gudang mencapai titik Re-Order Point
(Notifikasi barang ROP)
Brief Description Ketika stok barang di gudang mencapai Reorder Point (notifikasi barang ROP) , bagian Warehouse akan membuat
Purchase Order untuk dikirimkan ke pabrik bandung lewat Fax
yang berisi id_barang, nama_barang, qty dan harga_barang
Actor Admin Warehouse
Related Use Cases
-
Stakeholders Admin Warehouse : Melakukan pembuatan Purchase Order Preconditions Adanya pemesanan dari customer dan stok barang mencapai
titik re order point Postconditions Purchase Order dibuat
Flow of Event
Actor System
1. Admin Warehouse memilih sub menu Purchase Order dari menu Purchasing pada sistem
1.1 Sistem menampilkan
Purchase Order dan
2. Admin Warehouse memilih id_vendor
3. Admin Warehouse memilih id_barang yang akan dipesan berikut jumlah yang ingin dipesan
4. Admin Warehouse menyimpan data dengan menu save
5. Admin Warehouse memilih menu Print untuk mencetak
Purchase Order
id_PurchaseOrder
2.1 Sistem menampilkan data vendor yang dipilih berupa nama_vendor, alamat_vendor
3.1 Sistem menampilkan id_barang, nama_barang, harga_barang dan qty yang dipesan
4.1 Sistem menampilka
Purchase Order Purchase Order yang dibuat berupa
id_purchaseOrder, data vendor, dan data barang yang dipesan
5.1 Sistem mencetak
Purchase Order yang dibuat
Exception Conditions
Tabel 4.5
Use Case Description Membuat Purchase Receipt
2. Use Case name Membuat Purchase Receipt
Scenario Membuat Purchase Receipt sebagai Bukti Terima Barang di gudang dari Pabrik
Trigerring Event Adanya Purchase Order yang dibuat dan pengiriman barang sesuai PO oleh Pabrik
Brief Description Ketika Purchase Order dikirimkan ke Pabrik, maka Pabrik akan mengirimkan barang sesuai pesanan dengan menyertakan bukti
Purchase Order yang ada.
Actor Admin Warehouse
Related Use Cases
Membuat Purchase Order
Stakeholders Admin Warehouse : Melakukan pembuatan Purchase Receipt Preconditions Adanya Purchase Order yang dibuat oleh admin Warehouse dan
barang yang dipesan dari pabrik telah dikirimkan Postconditions Purchase Receipt dibuat
Flow of Event
Actor Flow of Event
1. Admin Warehouse memilih sub menu Purchase Order dari menu Purchasing pada sistem
2. Admin Warehouse memilih
1.1 Sistem menampilkan list Purchase Order
vendor yang sesuai dan membuka Purchase Order yang sesuai
3. Admin Warehouse memilih menu option kemudian Process lalu Receive pada Purchase
Order yang ditampilkan
4. Admin Warehouse memasukan jumlah barang yang diterima dari pabrik di gudang sesuai dengan item barang yang dipesan
5. Admin Warehouse menyimpan (Save) Purchase Receipt yang telah disesuaikan jumlah barang yang dipesan dengan yang diterima dari pengiriman pabrik
Purchase Order yang dipilih
3.1 Sistem menampilkan Form Purchase Receipt
yang dipilih
5.1 Sistem menampilkan
Purchase Receipt yang telah
disimpan sebelumnya.
Exception Conditions
Tabel 4.6
Use Case Description Membuat Purchase Invoice
3. Use Case name Membuat Purchase Invoice
Scenario Membuat Purchase Invoice sebagai pembayaran atas pemesanan ke Pabrik berdasarkan Purchase Receipt yang telah dibuat Trigerring Event Adanya Purchase Receipt yang telah dibuat berdasarkan
pengiriman dari pabrik.
Brief Description Ketika Purchase Receipt dibuat, maka secara otomatis akan berubah status “belum terbayarkan” yang harus dilunasi
Actor Admin Finance (kasir) Related Use
Cases
Membuat Purchase Receipt
Stakeholders Admin Finance (kasir) : Melakukan pembuatan Purchase
Invoice
Preconditions Adanya Purchase Receipt yang dibuat oleh admin Warehouse Postconditions Purchase Invoice dibuat
Flow of Event
Actor Flow of Event
1. Admin Finance(kasir) memilih sub menu Purchase Invoice dari menu Purchasing pada sistem
2. Admin Finance(kasir) memilih
new lalu memilih in new window
1.1 Sistem menampilkan list Purchase Invoice
2.1 Sistem menampilkan list
3. Admin Finance(kasir) memilih menu option kemudian Process lalu Uninvoicede Order/ Receipt pada Purchase Invoice yang ditampilkan
4. Admin Finance(kasir) memilih
Purchase order/ receipt yang
belum dibayarkan
5.Admin Finance (kasir) meemasukkan jumlah barang yang dibayarkan dari yang telah diterima di gudang dari pabrik
6. Admin Finance(kasir)
menyimpan Purchase Invoice yang telah dibuat
2.2 Sistem menampilkan form Purchase Invoice
3.1 Sistem menampilkan list
uninvoiced order/ receipt
yang ada
6.1 Sistem menampilkan
Purchase Invoice yang telah
disimpan sebelumnya.
Exception Conditions
- Tidak ada Purchase Receipt yang dibuat/ tidak ada pengiriman barang dari pabrik
Tabel 4.7
Use Case Description Membuat Bukti Kas Keluar
4. Use Case name Membuat Bukti Kas Keluar
Scenario Membuat Bukti Kas Keluar sebagai bukti pelunasan Purchase
Invoice yang telah dibuat sebelumnya
Trigerring Event Adanya Purchase Invoice yang dibuat dan adanya pembayaran ke pabrik (vendor)
Brief Description Ketika Purchase Invoice dibuat, maka akan ada pembayaran ke
vendor
Actor Admin Finance
Related Use Cases
Membuat Bukti Kas Keluar
Stakeholders Admin Finance : Melakukan pembuatan Bukti Kas Keluar Preconditions Adanya Purchase Invoice yang dibuat oleh admin Finance dan
kemudian adanya pembayaran Postconditions Bukti Kas Keluar dibuat
Flow of Event
Actor Flow of Event
1. Admin Finance(kasir) memilih sub menu Bukti Kas Keluar dari menu Purchasing pada sistem
2. Admin Finance(kasir) memilih nomor Purchase Invoice yang
1.1 Sistem menampilkan
Form Bukti Kas Keluar
2.1 Sistem menampilkan detil dari Purchase Invoice
telah dibayarkan
3. Admin Finance(kasir) memilih menu save setelah Bukti Kas Keluar selesai dibuat
yang dipilih berupa data
vendor, barang yang
diterima dan jumlah pembayaran
3.1 Sistem menampilkan Bukti Kas Keluar yang telah disimpan
Exception Conditions
Belum adanya pembayaran atas Purchase Invoice yang dibuat
4.4.2 Use Case Description proses Penjualan PT Tirta Amarta
Tabel 4.8
Use Case Description Membuat Delivery Order
5.Use Case name Membuat Delivery Order
Scenario
Membuat Delivery Order untuk melakukan pengiriman barang ke customer
Trigerring Event Pengiriman barang ke customer
Brief Description
Ketika barang akan dikirim sesuai dengan tanggal yang telah ditentukan, admin warehouse membuat Delivery Order berisi nama customer dan alamat customer yang akan dikirim beserta
dengan barang (id barang, nama barang dan quantity barang) yang akan dikirim ke customer.
Actor Admin Distribution
Related Use Cases
Membuat Sales Order
Stakeholders
Sales Admin : memberikan id Sales Order yang telah dibuat
sebelumnya
Admin Distribution : membuat Delivery Order sesuai dengan Sales Order.
Preconditions Harus ada Sales Order dan stock barang tersedia Postconditions Delivery Order dibuat dan dicetak
Flow of Event Actor System
1.Admin Distribution memilih
menu Delivery Order
2.Admin Distribution memasukkan id Sales Order yang sebelumnya telah diberikan oleh Sales Admin
3.Admin Distribution dapat
mengganti quantity barang sesuai dengan jumlah barang yang akan dikirim
1.1.Sistem menampilkan
form Delivery Order
2.1. Sistem menampilkan data dari Sales Order
4.Admin Distribution
menyimpan data Delivery Order
5.Admin Distribution mencetak
Delivery Order
4.1. Sistem akan menyimpan data Delivery
Order yang telah dibuat
oleh Admin Distribution dan men-generate id Delivery
Order
5.1. Sistem akan mencetak
Delivery Order dan
menghasilkan sebuah output untuk Admin Warehouse
Exception Conditions
- Stock barang tidak mencukupi pesanan customer
Tabel 4.9
Use Case Description Membuat Performa Invoice
6. Use Case name Membuat Performa Invoice
Scenario
Membuat Delivery Order yang memiliki harga barang beserta total harga pemesanan untuk melakukan pengiriman barang ke
customer dan dapat langsung menagih customer
Trigerring Event Pengiriman barang ke customer
Brief Description
Ketika barang akan dikirim sesuai dengan tanggal yang telah ditentukan, admin warehouse membuat Performa Invoice berisi nama customer dan alamat customer yang akan dikirim beserta
dengan barang (id barang, nama barang, quantity barang, harga satuan barang dan total harga pesanan) yang akan dikirim ke
customer.
Actor Admin Distribution
Related Use Cases
Membuat Sales Order
Stakeholders
Sales Admin : memberikan id Sales Order yang telah dibuat
sebelumnya
Admin Distribution : membuat Delivery Order sesuai dengan Sales Order.
Preconditions Harus ada Sales Order dan stock barang tersedia Postconditions Delivery Order dibuat dan dicetak
Flow of Event Actor System
1.Admin Distribution memilih
menu Delivery Order
2.Admin Distribution memasukkan id Sales Order yang sebelumnya telah diberikan oleh Sales Admin
3.Admin Distribution dapat
mengganti quantity barang sesuai dengan jumlah barang yang akan dikirim
1.2.Sistem menampilkan
form Delivery Order
2.1. Sistem menampilkan data dari Sales Order
4.Admin Distribution
menyimpan data Delivery Order
5.Admin Distribution memilih
pilihan untuk menampilkan harga dan total harga pesanan
6.Admin Distribution mencetak
Delivery Order
4.1. Sistem akan menyimpan data Delivery
Order yang telah dibuat
oleh Admin Distribution dan men-generate id Delivery
Order
5.1. Sistem menampilkan harga satuan barang dan total harga pesanan customer
6.1.Sistem akan mencetak
Delivery Order dan
menghasilkan sebuah
output untuk Admin Warehouse
Exception Conditions
Tabel 4.10
Use Case Description Membuat Laporan Analisa Pembayaran Customer
7. Use Case name Membuat laporan analisa pembayaran customer
Scenario
Membuat Laporan Pembayaran untuk membantu manager dalam menganalisa pembayaran customer untuk periode tertentu sehingga manager dapat mengambil keputusan dalam menaikkan credit limit customer
Trigerring Event Customer meminta credit limit dinaikkan
Brief Description
Ketika bagian Accounting memberikan list daftar Customer yang meminta credit limit mereka dinaikkan beserta jumlah
credit limit yang mereka inginkan, Manager harus melakukan
analisa pembayaran customer terlebih dahulu sebelum memberikan ijin kepada bagian accounting untuk menaikkan
credit limit customer.
Actor Manager
Related Use Cases
Membuat Receipt Journal
Stakeholders
Accounting : Mendata dan memberikan list Customer dan Credit limit yang diminta untuk dinaikkan
Manager : Melakukan analisa pembayaran customer dan memberikan ijin agar credit limit customer dari list yang ada dapat dinaikkan.
Preconditions Harus ada Receipt Journal dan Master Customer Postconditions -
1.Manager memilih menu
Analisa Laporan Pembayaran
Customer
2.Manager memilih id customer
yang ingin ditampilkan
3.Manager memilih periode
pembayaran yang diinginkan
4.Manager memilih icon ‘chart’
untuk menampilkan laporan tersebut kedalam bentuk chart
1.3.Sistem menampilkan
form Laporan Analisa
Pembayaran Customer
2.1. Sistem menampilkan data dari customer (id customer, nama customer, alamat customer dan credit limit) yang telah dipilih 3.1. Sistem menampilkan data dari pembayaran
customer sesuai dengan
periode yang telah dipilih oleh manager
4.1.Sistem menampilkan laporan pembayaran kedalam bentuk chart agar lebih mudah dilihat oleh Manager Exception
Conditions
4.4.3 Use Case Description proses Pembayaran PT Tirta Amarta
Tabel 4.11
Use Case Description Membuat Agenda Penagihan
10. Use Case name Membuat Agenda Penagihan
Scenario
Membuat Agenda Penagihan untuk collector dalam melakukan penagihan invoice kepada customer, untuk memudahkan collector dalam melakukan penagihan.
Trigerring Event Jatuh tempo Invoice
Brief Description
Memilih kode Invoice yang akan dilakukan penagihan, dan mengklik button add untuk memasukkannya ke dalam tabel. Dilanjutkan ke tombol print untuk mencetak seluruh invoice yang akan ditagih oleh seorang collector.
Actor Staff Accounting Receivable
Related Use Cases Membuat Invoice
Stakeholders
Staff Accounting Receivable : Melakukan pemilahan Invoice
yang akan ditagih
Preconditions Harus ada Invoice tersedia Postconditions Agenda Penagihan dicetak
Flow of Event
Actor System
1. Staff Accounting Receivable memilih menu Agenda Penagihan
2. Staff Accounting Receivable memilih invoice yang akan
1.1. Sistem menampilkan
form Agenda Penagihan
2.1. Sistem menampilkan nama dan alamat customer
dilakukan penagihan
3. Staff Accounting Receivable mengklik button add
4. Staff Accounting Receivable
mengklik button remove untuk menghapus data yang dipilih dari tabel
5. Staff Accounting Receivable
mengklik button print untuk mencetak
3.1. Sistem
menampilkannya di tabel
4.1. Sistem menghapus data yang dipilih dari tabel
5.1. Sistem akan mencetak Agenda Penagihan dan menghasilkan sebuah output untuk Staff Accounting Receivable
Exception Conditions
Tabel 4.12
Use Case Description Membuat Bukti Kas Terima
9. Use Case name Membuat Bukti Kas Terima
Scenario
Membuat Bukti Kas Terima sebagai bukti bahwa kas telah diterima oleh bagian kasir perusahaan
Trigerring Event Pembayaran Invoice
Brief Description
Memilih kode customer dan sistem akan menampilkan detil
customer, memasukkan referensi invoice dan jumlah bayar,
beserta catatan / notes jika diperlukan.
Actor Staff Kasir
Related Use Cases
Pelunasan sistem
Stakeholders
Staff Kasir : Melakukan pelunasan sistem dan membuat Bukti
Kas Terima Preconditions Pelunasan sistem
Postconditions Pembuatan dan pencetakan Bukti Kas Terima
Flow of Event
Actor System
1. Staff Kasir memilih menu Bukti Kas Terima
2. Staff Kasir memilih customer yang telah melakukan pembayaran dan pelunasan di sistem
1.1. Sistem menampilkan
form Bukti Kas Terima
2.1. Sistem menampilkan detil customer
3. Staff Kasir memilih referensi invoice pembayaran
4. Staff Kasir memasukkan
jumlah pembayaran
7.Staff Kasir memasukkan notes
jika diperlukan
8. Staff Kasir mengklik button save untuk menyimpan dan button print untuk mencetak
8.1. Sistem akan mencetak Bukti Kas Terima dan menghasilkan sebuah output untuk Staff Kasir
Exception Conditions
-
4.5 Rancangan solusi kebutuhan dengan Sequence Diagram pada PT Tirta Amarta
Dari analisa FIT/ Gap yang dilakukan pada bab 3, didapatkan beberapa aktivitas – aktivitas yang memiliki kategori Partial Fit dan GAP yang berarti sistem Everest belum maksimal/ belum dapat memenuhi kebutuhan tersebut.
Berikut merupakan rancangan solusi untuk aktivitas dengan status Partial Fit dan Gap yang dibuat dalam bentuk Sequence Diagram
4.5.1 Sequence Diagram untuk proses pembelian
4.5.1.1 Aktivitas pembuatan Purchase Order ke pabrik Bandung
Gambar 4.6 Sequence Diagram Pembuatan Purchase Order oleh bagian Warehouse
Gambar 4.7
4.5.1.2 Aktivitas penerimaan barang dan menandatangani Delivery Order dari pabrik Bandung / Purchase Receipt
Gambar 4.8
4.5.1.3 Aktivitas Proses Pembayaran ke pabrik Bandung / Bukti Kas Keluar
Gambar 4.9
Sequence Diagram sistem membuat Bukti Kas Keluar sebagai pelunasan Purchase Invoice
4.5.2 Sequence Diagram untuk proses penjualan
4.5.2.1 Aktivitas membuat Laporan Pembayaran Customer / Analisa Pembayaran Customer
Gambar 4.10
Sequence Diagram sistem menganalisa performa pembayaran customer
4.5.2.2 Aktivitas membuat Sales Order dan Delivery Order
Gambar 4.11
Sequence Diagram sistem men-generate Sales Order menjadi Delivery Order
Gambar 4.12
4.5.2.3 Aktivitas membuat Sales Order dan Performa Invoice
Admin Distributor
<<boundary>> Delivery Order
:Add Delivery Order Handler
:Delivery Order
:Sales Order :Sales Order DA :Delivery Order DA
init_SalesOrder() read() save() save() save() save()
Membuat Performa Invoice
Loop
:Detil Sales Order :Detil Sales Order DA
init_DetilSalesOrder() read() get_DetilSalesOrder(id_SO) id_barang,nama_barang,qty_SO Ket : SO : Sales Order create_DeliveryOrder() get_SalesOrder(id_SO) add_DeliveryOrder(id_SO) add_DeliveryOrder(id_SO) id_SO,id_Customer,nama_Customer,alamat_Customer,id_barang,nama_barang,qty_SO id_SO,id_Customer,nama_Customer,alamat_Customer,id_barang,nama_barang,qty_SO id_SO,id_Customer,nama_Customer,alamat_Customer,id_barang,nama_barang,qty_SO edit_DeliveryOrder(qty) edit_DeliveryOrder(qty) edit_DeliveryOrder(qty) click_add_hargaBarang() click_add_hargaBarang() click_add_hargaBarang() get_hargaBarang(id_SO) harga_barang harga_barang,total_pesan harga_barang,total_pesan hitung_total_harga_pemesanan() hitung_total_harga_pemesanan() Gambar 4.13
Sequence Diagram sistem mengenerate Sales Order menjadi Performa Invoice
Gambar 4.14
Sequence Diagram sistem mencetak Performa Invoice
Gambar 4.15
4.5.3 Sequence Diagram untuk proses pembayaran
4.5.3.1 Aktivitas Collector melakukan penagihan / agenda collector
Gambar 4.16
Sequence Diagram sistem menyusun agenda collector untuk penagihan
4.5.3.2 Aktivitas Kasir membuat Bukti Kas Terima
Gambar 4.17
Gambar 4.18
4.6 Rancangan User Interface Sistem Everest Pada PT Tirta Amarta
Setelah membuat rancangan solusi dengan Seqeunce Diagram, berikut merupakan rancangan solusi untuk user interface sistem bila mengalami customizing pada pengaturan (setting) , perubahan data atau bila terjadi perombakan ulang (coding) dari requirement- requirement yang berstatus Partial Fit atau Gap.
4.6.1 Purchase Receipt
User memilih Purchase Order yang akan dibuat Purchase Receipt
nya, Sistem secara otomatis menampilkan Vendor beserta alamatnya dan tabel yang berisi item code, description dan quantity dari Purchase Order.
User dapat melakukan edit jika mendapatkan jumlah barang fisik yang
Gambar 4.19
User Interface Purchase Receipt
4.6.2 Bukti Kas Keluar
User memilih Vendor dan sistem secara otomatis menampilkan detilnya, mengisi jumlah bayar, dan catatan di textbox Notes jika diperlukan.
Gambar 4.20
User Interface Bukti Kas Keluar
4.6.3 Notifikasi Reorder Point
Jika jumlah stok sudah mencapai titik Reorder Point maka sistem secara otomatis menampilkan grafik beserta detail dari barang terkait dan sisa stoknya.
Gambar 4.21
User Interface Notifikasi Reorder Point
4.6.4 Notifikasi Purchase Invoice
Jika purchase invoice akan jatuh tempo sesuai waktu yang telah ditentukan maka sistem Everest akan menampilkan pop-up notifikasi jatuh tempo pembayaran purchase invoice.
Gambar 4.22
User Interface Notifikasi Purchase Invoice Due Date
4.6.5 Analisa Pembayaran Customer
User memilih customer yang ingin dilihat performa pembayarannya
dan sistem secara otomatis akan menampilkan detilnya lalu memilih periode laporannya. Sistem akan menampilkan tabel dan grafik performa pembayaran customer.
Gambar 4.23
User Interface Analisa Pembayaran Customer
4.6.6 Delivery Order
User memilih Sales Order yang akan dibuatkan Delivery Order nya,
code, description dan quantity dari barang yang dipesan melalui Sales
Order.
Gambar 4.24
User Interface Delivery Order
4.6.7 Notifikasi Insufficient Stock
Jika stok suatu barang tidak mencukupi untuk memenuhi order, maka sistem secara otomatis menampilkan notifikasi bahwa barang terkait tidak
mencukupi untuk memenuhi order. Notifikasi memberikan informasi
insufficient stock dan menampilkan detil barang beserta sisa stoknya.
Gambar 4.25
User Interface notifikasi Insuficcient Stock
4.6.8 Performa Invoice
Sama seperti delivery order, performa invoice dimulai dengan memilih kode sales order yang akan dibuat delivery order-nya. Sistem akan menampilkan detil customer-nya. User melakukan centang pada
check box "tampilkan harga". Maka sistem akan menampilkan tabel yang
berisi detil barang beserta harganya. Setelah itu akan ditampilkan jumlah harganya.
Gambar 4.26
User Interface Performa Invoice
4.6.9 Online Ordering
4.6.9.1 Form Login
Customer melakukan login kedalam website Viro Water untuk
Gambar 4.27
User Interface Form Login Online Ordering
4.6.9.2 Form Order
Customer mengisi form order dengan memilih item code
untuk barang yang diinginkan, sistem akan menampilkan description dan harganya, mengisi quantity sesuai dengan jumlah yang diinginkan dan meng-klik button add untuk menambahkan barang yang dipesan kedalam tabel order. Setelah selesai, customer meng-klik NEXT untuk melanjutkan ke tahap selanjutnya.
Gambar 4.28
User Interface Form Order Online Ordering
Tahap selanjutnya customer memilih metode pembayaran yang akan dilakukan, terdapat 2 pilihan Cash dan Credit. Jika
customer ingin menambahkan catatan khusus, customer dapat mengisi
di textbox Notes. Untuk masuk ke tahap selanjutnya, customer dapat meng-klik NEXT.
Gambar 4.29
User Interface Form Order Online Ordering
4.6.9.3 Order Review
Order Review berisikan konfirmasi alamat, tanggal, metode
pembayaran dan list pesanan yang dilakukan customer, beserta jumlah biaya yang harus dibayar oleh customer. Setelah customer melakukan
review atas pesanannya customer dapat meng-klik button Submit
Gambar 4.30
User Interface Form Order Review Online Ordering
4.6.10 Agenda Penagihan Collector
User pertama-tama memilih Id Collector yang akan melakukan
penagihan, sistem menampilkan nama dari collector. Lalu user memilih
invoice yang akan ditagih, sistem menampilkan Id Customer beserta detil dan
alamatnya. Button add untuk menambahkannya ke tabel yang berisikan
Invoice Number, Name dan Address dari customer.
Gambar 4.31
User Interface Agenda Penagihan Collector
4.6.11 Bukti Kas Terima
User memilih Id Customer dan sistem akan menampilkan alamat dan
detil dari customer, lalu memilih referensi invoice dan jumlah bayarnya beserta notes jika diperlukan.
Gambar 4.32
User Interface Bukti Kas Terima
4.6.12 Notifikasi Invoice Jatuh Tempo
Notifikasi menampilkan invoice yang akan jatuh tempo dalam waktu 7 hari, yang berisi data nomor invoice, nama customer, alamat customer dan tanggal jatuh tempo.
Gambar 4.33
User Interface Notifikasi Invoice Jatuh Tempo
4.7 Managemen Proyek Pengembangan & Perbaikan Sistem Pada PT. Tirta Amarta
Managemen proyek dilakukan tehadap estimasi perhitungan waktu dan biaya yang harus dilakukan PT. Tirta Amarta untuk melakukan perbaikan sistem.
4.7.1 Estimasi Waktu yang Dibutuhkan Untuk Pengembangan & Perbaikan
Tabel berikut ini menjelaskan aktivitas - aktivitas yang harus dijalankan untuk melakukan perbaikan sistem beserta durasi dengan satuan hari yang harus dikerahkan untuk melakukan perbaikan sistem.
Keterangan tabel :
- Activity : simbol dari aktivitas- aktivitas yang dijalankan
- Estimated Duration (Days) : estimasi/ perkiraan waktu yang
diperlukan masing- masing aktivitas.
- Predecessor : hubungan antar aktivitas, bagaimana awal , proses dan
akhir dari pelaksanaaan proyek.
Tabel 4.13
Activity on the Node Table Estimasi Waktu Perbaikan Sistem
Activity Description Estimated Duration (Days) Predecessor A Setting Server 7 - B Setting Database 7 A C Customizing setting system Everest (Purchase Order, Purchase Receipt) 2 B D Developing Notifikasi Re-order Point 1 C
E Developing Notifikasi jatuh tempo pembayaran vendor 1 D F Developing Bukti Kas Keluar 1 E G Developing Laporan Analisa Pembayaran 1 F H Developing Form Online Ordering (Design + Coding) 3 G I Developing notifikasi stok tidak cukup 1 H J Developing Delivery Order (termasuk Performa Invoice) 1 I K Developing 1 J
Notifikasi Jatuh Tempo Invoice L Developing Agenda Penagihan Customer 1 K M Developing pembuatan Bukti Kas Terima 1 L N Testing aplikasi 2 D, E, F, G, H, I ,J ,K, L , M
O Testing oleh user 1 N
P Implementasi Fitur baru 1 O Q Training user 24 P R Evaluasi dan Maintenance 5 Q
Tabel diatas menggambarkan Activity on the Nodes seluruh kegiatan yang diperlukan dalam perbaikan dan pengembangan sistem, beserta
estimasi waktu lebih rinci dari aktivitas di atas, akan dibuat dalam bentuk
Gantt Charts sebagai berikut :
Gambar 4.34
Gantt Chart Pengembangan & Perbaikan Sistem
Dari tabel Gant Chart diatas menggambarkan perkembangan proyek setiap minggunya sampai proyek tersebut selesai dilakukan. Dan untuk melakukan semua aktivitas yang ada, dibutuhkan waktu selama
4.7.2 Estimasi Biaya yang Dikeluarkana Untuk Pengembangan & Perbaikan Sistem
Tabel dibawah merupakan estimasi biaya yang kami perkirakan untuk bulan pertama proyek perbaikan dan pengembangan sistem everest. Dan total dari biaya perkiraan yang kami berikan ini masih dapat berubah dan disesuaikan dengan kebutuhan perusahaan. Perkiraan terdiri dari perangkat- perangkat yang diperlukan selama proyek dan sumber daya yang diperlukan.
Tabel 4.14
Estimasi Biaya Pengembangan & Perbaikan Sistem
No. Requirement Qty Cost
Hardware 1. Komputer Cassing : Simcool Memory : 2GB V-Gen Motherboard : Asus P5 G41T-MLX Processor : Core i3 Hard disk : 500 GB LCD : Samsung LCD 18,5 inch @ Rp 4.300.000 3 pc Rp12.900.000 2.
Keyboard & Mouse Logitech Optical USB
Merk :Logitech
@ Rp 114.000
3 pcs Rp 342.000
3.
Hard Disk Eksternal
Merk : Seagate
Memory : 500 Gb
USB : 3.0
1 pcs Rp 593.000
1 Windows XP SP3
@ Rp 936.000 3 Rp 2.808.000
2 Microsoft Office 2007
Untuk 3 user 1 Rp 670.000
Jaringan
1 Sewa Server di Telkom Indonesia Per bulan : Rp 16.000.000/ 24 user
±150 user
Rp 96.000.000 / bulan
2
Layanan Internet untuk 11 kantor cabang untuk akses server
- Paket speedy multi speed 2 Mbps/bulan = Rp. 995.000
11 Rp 10.945.000
Programmer
1
IT Programmer (Coding System) - Upah selama proyek dilaksanakan
selama 47 hari (@ Rp 200000 /hari) 2 perso n Rp 18.800.000 2 Networker
- Upah selama proyek dilaksanakan selama 14 hari (Server dan database) (@ Rp 250000 /hari) 1 perso n Rp 3.500.000 Total 145.874.000
