• Tidak ada hasil yang ditemukan

BAB III ANALISA.

N/A
N/A
Protected

Academic year: 2021

Membagikan "BAB III ANALISA."

Copied!
9
0
0

Teks penuh

(1)

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

(2)

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.

(3)

 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

(4)

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:

(5)

Tabel 3.1. Skenario Use Case Memasukan data Plafon Mingguan

Nama Use Case Memasukan data Plafon Mingguan

Aktor Supervisor Pembayaran

Deskripsi Supervisor Pembayaran melakukan input data plafon mingguan sebagai anggaran dana pada tiap minggu setiap bulannya.

Skenario Supervisor Pembayaran melakukan input data plafon mingguan

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

Deskripsi Supervisor Pembayaran melakukan input data SKK & SPK

sebagai bentuk tagihan tiap minggunya.

Skenario Supervisor Pembayaran melakukan input data SKK & SPK

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

Deskripsi DM Pembayaran melakukan persetujuan data SKK & SPK sebagai

persetujuan tagihan yang masuk.

Skenario DM Pembayaran melakukan persetujuan data SKK & SPK melalui

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 Staff Verifikasi membuat data nota dinas sebagai biodata awal vendor yang melakukan transaksi

Skenario Staff Verifikasi membuat data nota dinas melalui MS. Excel pada

(6)

Post Kondisi -

Tabel 3.5. Skenario Use Case Membuat data Verifikasi

Nama Use Case Membuat data Verifikasi

Aktor Staff Verifikasi

Deskripsi Staff Verifikasi membuat data verifikasi sebagai rincian total semua tagihan yang ada pada tiap transaksi

Skenario Staff Verifikasi membuat data verifikasi melalui MS. Excel pada

tiap minggu setiap bulannya.

Post Kondisi -

Tabel 3.6. Skenario Use Case Persetujuan data Verifikasi Nama Use Case Persetujuan data Verifikasi

Aktor DM Anggaran, Supervisor Verifikasi, Supervisor Pajak, MB

Keuangan, DM Keuangan

Deskripsi Pada tiap divisi melakukan persetujuan data verifikasi sebagai sahnya data transaksi yang sedang di proses

Skenario Supervisor Pembayaran melakukan persetujuan data verifikasi

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 DM Anggaran melakukan pengelompokan nilai akhir untuk

selanjutnya diproses oleh divisi lain.

Skenario DM Anggaran melakukan input data plafon Mingguan melalui

MS. Excel pada tiap minggu setiap bulannya.

(7)

Tabel 3.8. Skenario Use Case Melakukan Pembayaran Tagihan

Nama Use Case Memasukan data Plafon Mingguan

Aktor Kasir

Deskripsi Kasir melakukan pembayaran tagihan transaksi sebagai selesainya

proses transaksi setiap minggunya

Skenario Kasir melakukan pembayaran tagihan transaksi melalui MS. Excel

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

Deskripsi Aktor melakukan persetujuan pembayaran tagihan sebagai sahnya

transaksi untuk membayar tagihan tersebut.

Skenario Supervisor Pembayaran melakukan persetujuan pembayaran

tagihan melalui MS. Excel pada tiap minggu setiap bulannya.

Post Kondisi -

Tabel 3.10. Skenario Use Case Mencetak laporan dan transfer

Nama Use Case Memasukan data Plafon Mingguan

Aktor Supervisor Anggaran, Supervisor Verifikasi, Supervisor Pajak,

Supervisor Pembayaran, Kasir

Deskripsi Aktor Mencetak laporan dan transfer sebagai bukti sah transaksi

setiap minggunya.

Skenario Supervisor Pembayaran Mencetak laporan dan transfer

melalui MS. Excel pada tiap minggu setiap bulannya.

(8)

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.

(9)

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 meng-update 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.

Gambar

Gambar 3.1 : Block Diagram Sistem Berjalan Bisnis PT PLN (Persero) Distribusi Banten
Tabel 3.3. Skenario Use Case Persetujuan data SKK &amp; SPK  Nama Use Case  Persetujuan data SKK &amp; SPK
Tabel 3.6. Skenario Use Case Persetujuan data Verifikasi  Nama Use Case  Persetujuan data Verifikasi
Tabel 3.9. Skenario Use Case Persetujuan Pembayaran Tagihan  Nama Use Case  Persetujuan Pembayaran Tagihan

Referensi

Dokumen terkait

Untuk penilaian (Validasi) umum terhadap tes diagnostik two-tier untuk mendiagnosis miskonsepsi siswa dalam mempelajari aljabar linear mendapat keterangan b yaitu dapat direvisi

Abstrak: Tujuan dari penelitian ini adalah untuk mengembangkan latihan pliometrik three-point shoot bolabasket menggunakan stimulasi Plek sus Brak hialis pada siswa

Supplier menerima PO (Purchase Order) dari owner dan supplier akan mengirimkan invoice dan surat jalan ke marketing.Setelah menerima invoice serta surat jalan dari supplier

Undang-undang Nomor 32 Tahun 2004 tentang Pemerintahan Daerah (Lembaran Negara Republik Indonesia Tahun 2004 Nomor 125, Tambahan Lembaran Negara Republik Indonesia Nomor 4437)

Dengan tersedianya sistem informasi berbasis web, diharapkan dapat membantu pihak pelanggan dalam berinteraksi dengan perusahaan tentang penggunaan produk cctv yang mungkin

Penelitian ini bertujuan untuk meneliti determinan perilaku nyumbang di masyarakat kelurahan Sekaran, Gunungpati Semarang ditinjau dari theory of reasoned action

Seperti telah dijelaskan gejala atau tanda pada TB sistem skeletal bergantung pada lokasi kelainan, kelainan pada tulang belakang disebut gibbus, menampakan gejala

Serangga artropoda yang tertangkap setelah aplikasi bioinsektisida cair terdiri atas 2 ordo, 5 famili, 8 spesies dan 70 individu serangga fitofaga yang terperangkap dalam