33
BAB III ANALISA
3.1 Analisa Sistem Analisa merupakan suatu kegiatan yang bertujuan mempelajari serta mengevaluasi bentuk permasalahan yang ada pada sistem. Agar sistem yang dirancang dapat berjalan sebagaimana mestinya, perlu dilakukan analisa masalah dan analisa fungsional yang bertujuan untuk pembuatan aplikasi ini. Tahap ini dilakukan dengan cara wawan cara pada pihak PT PLN (Persero) Distribusi Banten yang bersangkutan dengan aplikasi ini.
3.1.1 Analisa Sistem Berjalan Adapun sistem berjalan pada proses transaksi bisnis antara anggaran dana dengan tagihan pembayaran (SKK dan SPK) dari vendor yang bekerja sama dengan PT PLN (Persero) Distribusi Banten, adalah sebagai berikut:
1. Proses input data tagihan dan anggaran dana (plafon mingguan) a. Data tagihan Supervisior Anggaran menginput data tagihan yang berupa, SKK (Surat Kerja Kuasa) dan SPK (Surat Perintah Kerja) ke dalam database yang nantinya akan di proses lebih lanjut untuk di periksa. Dimana pada setiap data tersebut terdapat tanggal, nominal, jenis anggaran, jenis pekerjaan, nama vendor, dll. Apabila ada kesalahan pihak Supervisior Anggaran juga yang akan mengupdate data tersebut, misal ada kesalahan pada SKK dan nantinya data SKK tersebut akan direvisi nominalnya dan diisi tanggal berapa revisi tersebut dilakukan. Begitu juga pada SPK yang akan dilakukan pada setiap amandemen setiap tanggalnya, teradpat 3 jenis amandemen dan 1 amandemen kosong yang dapat diseuaikan. b. Anggaran dana (plafon mingguan) Supervisor Pembayaran akan melakukan input data plafon mingguan yang isinya terdapat batas waktu berlakunya anggaran
http://digilib.mercubuana.ac.id/
34
tersebut, jumlah nominal yang ada, serta jenis anggaran yang dapat diterimanya. Dimana data tersebut menjadi sebuah acuan utama pada setiap minggunya, seberapa besar anggaran dana yang dikeluarkan untuk membayar tagihan dari vendor-vendor yang sudah bekerjasama dengan PT PLN (Persero) Distribusi Banten. Jika anggaran dana telah habis maka akan dilakukan input data kembali pada tiap minggunya dalam satu bulan.
2. Proses approvement dan membuat data pengecekan (verifikasi) a. Approvement data Data yang sudah diinput selanjutkan akan diperiksa satu persatu oleh:
DM Anggaran: yang bertugas untuk approve data SKK dan SPK. Serta mengelompokan jumlah nilai tagihan total pada setiap SKK, apakah jumlahnya <100 juta atau >100 juta yang nantinya akan dilakukan pengecekan oleh Supervisor Verifikasi dan DM Keuangan.
Staff Verifikasi: yang bertugas untuk mengecek keseluruhan data SKK dan SPK setelah pengecekan dilakukan oleh DM Anggaran dan juga membuat data verifikasi, yaitu rincian transaksi dari inputan SKK dan SPK. Dimana sebelumnya harus memasukan data nota dinas, yang berisikan biodata tentang jenis anggaran, tanggal penerimaannya, tanggal pelaksanaanya.
Supervisor Verifikasi: melakukan approve data verifikasi yang sudah dibuat oleh Staff Verifikasi, serta menyetujui apakah data tersebut sudah benar atau belum yang dimana hal tersebut dilakukan berdasarkan sistem SAP yang sudah ada.
Supervisor Pajak: melakukan pengecekan jenis-jenis pajak yang ada pada data verifikasi, apakah sudah benar atau belum.
http://digilib.mercubuana.ac.id/
35
DM Keuangan: melakukan approve data verifikasi yang sudah dibuat oleh Staff Verifikasi dan Supervisor Verifikasi dan dikelompokan berdasaran jumlai nilainya oleh DM Anggaran, serta menyetujui apakah data tersebut sudah benar atau belum yang dimana hal tersebut dilakukan berdasarkan sistem SAP yang sudah ada.
MB Keuangan: melakukan approve data verifikasi yang sudah diperiksa sebelumnya oleh DM Anggaran, serta menyetujui apakah data tersebut sudah benar atau belum yang dimana hal tersebut dilakukan berdasarkan sistem SAP yang sudah ada.
b. Membuat data pengecekan (verifikasi) Staff Verifikasi membuat data verifikasi yang isinya berupa ringkasan semua data yang sudah dimasukan oleh Supervisor Anggaran yaitu SKK dan SPK, dan pada data inilah semuanya di proses lebih lanjut, mulai dari pengurangan nominal dari pajak, indentitas dari pihak vendor (nama, nomor rekening, nama bank), serta nominal lainnya yang akan dilakukan oleh banyak pihak. Sehingga data verifikasi menjadi sangat penting pada proses transaksi ini, dimana bagian-bagian pada data ini sangat berpengaruh dan melibatkan banyak pihak, dan data inilah yang akan menjadi transaksi berjalan pada setiap minggunya per tiap bulannya.
3. Proses pembayaran tagihan Pembayaran tagihan dilakukan oleh pihak Kasir, dimana hal tersebut mengacu pada data plafon mingguan yang sebelumnya sudah di input oleh Supervisor Pembayaran. Data tersebut menjadi jumlah anggaran yang disediakan pada tiap minggunya pada setiap satu bulan. Data plafon mingguan akan di cocokan dengan data verifikasi dan hasilnya akan mengeluarkan saldo akhir, nominal tersebut didapat dengan cara
http://digilib.mercubuana.ac.id/
36
jumlah nilai total pada setiap data verifikasi setiap minggunya di kurangkan dengan jumlah nominal plafon mingguan. Tahap akhir yaitu Supervisor Pembayaran akan melakukan pengecekan akhir dari semua data dan akan diserahkan pad DM Keuangan untuk meminta persetujuan untuk melakukan pembayaran dari tagihan tersebut. Setelah melalui pengecekan dan persetujuan, Kasir mencetak lembar verifikasi dan surat transfer pada tiap masing-masing vendor untuk nantinya akan segera di proses pembayarannya
3.1.2 Block Diagram Sistem Berjalan Berikut ini Bentuk Use Case Diagram sistem yang berjalan pada pada proses transaksi bisnis antara anggaran dana dengan tagihan pembayaran (SKK dan SPK) dari vendor yang bekerja sama dengan PT PLN (Persero) Distribusi Banten:
Gambar 3.1 : Block Diagram Sistem Berjalan Bisnis PT PLN (Persero) Distribusi Banten
http://digilib.mercubuana.ac.id/
37
Tabel 3.1. Skenario Use Case Memasukan data Plafon Mingguan Nama Use Case
Memasukan data Plafon Mingguan
Aktor
Supervisor Pembayaran Supervisor Pembayaran melakukan input data plafon mingguan
Deskripsi
sebagai anggaran dana pada tiap minggu setiap bulannya. Supervisor Pembayaran melakukan input data plafon mingguan
Skenario
melalui MS. Excel pada tiap minggu setiap bulannya.
Post Kondisi
-
Tabel 3.2. Skenario Use Case Memasukan data SKK & SPK Nama Use Case
Memasukan data SKK & SPK
Aktor
Supervisor Anggaran Supervisor Pembayaran melakukan input data SKK & SPK
Deskripsi
sebagai bentuk tagihan tiap minggunya. Supervisor Pembayaran melakukan input data SKK & SPK
Skenario
melalui MS. Excel pada tiap minggu setiap bulannya.
Post Kondisi
-
Tabel 3.3. Skenario Use Case Persetujuan data SKK & SPK Nama Use Case
Persetujuan data SKK & SPK
Aktor
DM Pembayaran DM Pembayaran melakukan persetujuan data SKK & SPK sebagai
Deskripsi
persetujuan tagihan yang masuk. DM Pembayaran melakukan persetujuan data SKK & SPK melalui
Skenario
MS. Excel pada tiap minggu setiap bulannya.
Post Kondisi
-
Tabel 3.4. Skenario Use Case Membuat data Nota Dinas Nama Use Case
Membuat data Nota Dinas
Aktor
Staff Verifikasi
Deskripsi
Skenario
Staff Verifikasi membuat data nota dinas sebagai biodata awal vendor yang melakukan transaksi Staff Verifikasi membuat data nota dinas melalui MS. Excel pada tiap minggu setiap bulannya.
http://digilib.mercubuana.ac.id/
38
Post Kondisi
-
Tabel 3.5. Skenario Use Case Membuat data Verifikasi Nama Use Case
Membuat data Verifikasi
Aktor
Staff Verifikasi Staff Verifikasi membuat data verifikasi sebagai rincian total
Deskripsi
semua tagihan yang ada pada tiap transaksi Staff Verifikasi membuat data verifikasi melalui MS. Excel pada
Skenario
tiap minggu setiap bulannya.
Post Kondisi
-
Tabel 3.6. Skenario Use Case Persetujuan data Verifikasi Nama Use Case
Persetujuan data Verifikasi DM Anggaran, Supervisor Verifikasi, Supervisor Pajak, MB
Aktor
Keuangan, DM Keuangan Pada tiap divisi melakukan persetujuan data verifikasi sebagai
Deskripsi
sahnya data transaksi yang sedang di proses Supervisor Pembayaran melakukan persetujuan data verifikasi
Skenario
melalui MS. Excel pada tiap minggu setiap bulannya.
Post Kondisi
-
Tabel 3.7. Skenario Use Case Pengelompokan nilai akhir Nama Use Case
Pengelompokan nilai akhir
Aktor
DM Anggaran
Deskripsi
Skenario Post Kondisi
DM Anggaran melakukan pengelompokan nilai akhir untuk selanjutnya diproses oleh divisi lain. DM Anggaran melakukan input data plafon Mingguan melalui MS. Excel pada tiap minggu setiap bulannya. -
http://digilib.mercubuana.ac.id/
39
Tabel 3.8. Skenario Use Case Melakukan Pembayaran Tagihan Nama Use Case
Memasukan data Plafon Mingguan
Aktor
Kasir Kasir melakukan pembayaran tagihan transaksi sebagai selesainya
Deskripsi
proses transaksi setiap minggunya Kasir melakukan pembayaran tagihan transaksi melalui MS. Excel
Skenario
pada tiap minggu setiap bulannya.
Post Kondisi
-
Tabel 3.9. Skenario Use Case Persetujuan Pembayaran Tagihan Nama Use Case
Persetujuan Pembayaran Tagihan
Aktor
DM Keuangan, Supervisor Pembayaran Aktor melakukan persetujuan pembayaran tagihan sebagai sahnya
Deskripsi
transaksi untuk membayar tagihan tersebut. Supervisor Pembayaran melakukan persetujuan pembayaran
Skenario
tagihan melalui MS. Excel pada tiap minggu setiap bulannya.
Post Kondisi
-
Tabel 3.10. Skenario Use Case Mencetak laporan dan transfer Nama Use Case Aktor
Deskripsi
Skenario Post Kondisi
Memasukan data Plafon Mingguan Supervisor Anggaran, Supervisor Verifikasi, Supervisor Pajak, Supervisor Pembayaran, Kasir Aktor Mencetak laporan dan transfer sebagai bukti sah transaksi setiap minggunya. Supervisor Pembayaran Mencetak laporan dan transfer melalui MS. Excel pada tiap minggu setiap bulannya. -
http://digilib.mercubuana.ac.id/
40
3.1.3 Analisa Masalah Dari sistem berjalan yang ada terdapat beberapa permasalahan, antara lain: 1. Belum ada sistem aplikasi yang dapat memantau transaksi antara anggaran dana dengan tagihan pembayaran (SKK dan SPK) dari vendor yang bekerja sama dengan PT PLN (Persero) Distribusi Banten, dimana status tersebut sudah dibayar atau belum dan juga pada saldo plafon pembayaran per tiap bulannya. Akibatnya terdapat kejanggalan nilai akhir pada anggaran daana dengan tagihan pembayaran. 2. Database yang digunakan masih individu atau masing-masing divisi, sehingga dalam hal pengecekan transaksi sering terjadi perbedaan nilai akhir karena salah satu divisi telat update databse dan divisi lainnya tidak tahu akan hal itu. 3. Database yang digunakan masih manual, yaitu dengan MS. Exel. Sehingga jika terjadi kesalahan input akan sangat sulit untuk menemukannya dan mengubahnya kembali karena semuanya dilakukan secara manual dan satu-persatu pada tiap database, dimana hal itu sangat menggangu proses kinerja yang lain, yang seharusnya sudah selesai dikerjakan tetapi malah terganggu oleh sulitnya mencari data yang salah pada MS. Exel.
3.1.4 Anilisa Fungsional Berdasarkan identifikasi permasalahan yang ada pada PT PLN (Persero) Distribusi Banten, maka perlu dibuatkan sebuah sistem usulan yang mampu menjawab permasalahan tersebut. Berikut ini adalah perancangan sistem usulan: 1. Membuat sistem aplikasi yang dapat memantau transaksi antara anggaran dana dengan tagihan pembayaran (SKK dan SPK) dari vendor yang bekerja sama dengan PT PLN (Persero) Distribusi Banten, serta dapat meng-update statusnya menjadi sudah dibayar atau belum dibayar dan meng-update data saldo plafon pada setiap bulannya agar tidak terjadi kejanggalan nilai akhir yang berbeda satu sama lain.
http://digilib.mercubuana.ac.id/
41
2. Pada setiap divisi akan dibuatkan database pada masing-masing pihaknya untuk meng-input, delete, update data kedalam satu databse. Dan nantinya akan ada notifikasi bila salah satu pihak divisi telah meng-input atau mengupdate data terbaru yang dimana data tersebut berhubungan dengan pihak divisi lainnya. Sehingga tingkat miss komunikasi. 3. Proses membuat (create), mencari (read), mengubah (update), serta menghapus (delete) pada setiap database masing-masing pihak divisi sudah ada pada aplikasi ini, sehingga bila ingin mengubah serta menghapus data yang salah dapat dilakukannya secara langsung tanpa harus melakukan ini itu terlebih dahulu, semuanya sudah ada pada di dalam aplikasi.
http://digilib.mercubuana.ac.id/
