BAB 4 EVALUASI MODUL FINANCIAL ACCOUNTING BERBASIS SAP

Transkripsi

1 BAB 4 EVALUASI MODUL FINANCIAL ACCOUNTING BERBASIS SAP 4.1. Fit/Gap Analysis Analisis Fit/Gap dilakukan dengan membandingkan fiturfitur yang terdapat pada sistem SAP dengan sistem berjalan pada PT. Sarihusada Generasi Mahardhika, khususnya pada modul Financial Accounting. Hal ini dilakukan dengan tujuan sebagai tindak lanjut dalam usaha memaksimalkan penggunaan dalam implementasi pengembangan SAP (upgrade) ECC 6.0 dalam perusahaan. Analisis Fit/Gap akan ditampilkan dengan menggunakan tabel yang menyertakan proses bisnis dalam modul Financial Accounting. Requirement sistem yang dimiliki oleh perusahaan, level yang menentukan tingkat prioritas di dalam perusahaan, Fit/Gap/Partial, keterangan yang menjelaskan secara singkat mengenai requirement tersebut, dan alternatif yang dapat digunakan oleh perusahaan sebagai solusi dari Gap yang ada. Tahapan analisis Fit/Gap dimulai dengan Ranking Requirement, yaitu penilaian berdasarkan pada tingkat prioritas perusahaan terhadap requirement sistem tersebut. Ranking Requirement ini terdiri dari 3 level prioritas, yaitu: High (H) Mission Critical Requirements Level ini menyatakan bahwa requirement sistem dinilai sangat kritikal, sangat diperlukan untuk pengoperasian perusahaan. Medium (M) Value Add Requirements Level ini menyatakan bahwa requirement sistem dinilai tidak kritikal terhadap bisnis perusahaan, namun dapat memberikan nilai tambah yang cukup signifikan bagi perusahaan. Low (L) Desirable Requirements Level ini menyatakan bahwa requirement sistem dinilai tidak esensial, yang jika diterapkan hanya akan memberikan sedikit nilai tambah ataupun sedikit perubahan bagi perusahaan. Untuk tahapan berikutnya, yaitu Degree of Fit, yaitu tahap penentuan peringkat kesesuaian antara requirements dengan sistem yang ada. Dimana tingkat peringkat tersebut adalah: Fit (F) Sistem atau pun software telah mencakup atau memenuhi requirement. Gap (G) 74

2 75 Sistem atau pun software sama sekali tidak memenuhi requirement yang ada, dimana terdapat alternatif dan rekomendasi yang diberikan. Kemungkinan akan dilakukan customization terhadap software atau sistem tersebut. Partial Fit (P) Sistem telah memiliki fungsi yang mendukung requirements, namun diperlukan customization agar sistem dapat memenuhi requirements secara menyeluruh.

3 76 Berdasarkan analisis Fit/Gap pada tabel di atas, maka dapat diambil kesimpulan bahwa tingkat/level ranking requirement dan degree of fit atas sistem SAP yang berjalan pada saat ini, yaitu pada modul Financial Accounting, dapat dilihat pada tabel berikut ini: Tabel 4.1 Analisis Fit/Gap No. Requirements Level F/P/ G Comments Alternative 1 Modul General Ledger 1.1 Dapat menampilkan H F Sistem Chart of Accounts menampilkan dalam Central View G/L Master Records, sebagian besar terdiri atas account number, account name, type of G/L 1.2 Dapat mengubah nama L F Menggunakan Key account group ke dalam word/transaltion bahasa lain dan dapat membuat keyword untuk mencari akun tersebut 1.3 Dapat membuat G/L H F Sistem accounts memungkinkan user untuk membuat G/L Accounts baru 1.4 Dapat menampilkan G/L H F Menampilkan account list chart of accounts yang spesifik untuk satu

4 77 company code tertentu 1.5 Dapat memaintain financial statement version 1.6 Dapat mengeksekusi posting G/L 1.7 Dapat menjalankan balance sheet 1.8 Dapat menampilkan cost elements H F Memastikan bahwa setiap account G/L tercantum dalam versi financial statement yang benar H F Eksekusi posting G/L menggunakan Enjoy Screen dan traditional screen untuk posting yang lebih kompleks H F Sistem dapat menampilkan balance sheet sesuai dengan accounting period yang diinginkan H F Digunakan untuk memposting obyek pada controlling, seperti misalnya cost centers dan internal orders

5 1.9 Adanya reconciliation Accounts 1.10 Dapat mendrill down asal dokumen dari account yang terdapat pada account G/L 1.11 Dapat menghasilkan laporan yang memungkinkan pengguna laporan untuk melakukan analisa terhadap laporan tersebut H F Menghubungkan Subsidiary Ledger dengan General Ledger secara realtime, sehinggaapa yang di post pada subsidiary Ledger jugaterupdate pada General Ledger M F Sistem dapat melacak asal dokumen dari GL account yang ada H G Sistem belum dapat menghasilkan laporan Payment Analysis 78 Sistem dapat menghasilkan laporan untuk Payment Analysis secara rutin pada akhir periode setelah closing 1.12 Dapat memaintain H P Selama ini proses Sistem dapat amortisasiprepaid maintain melakukan proses amortisasi maintain amortisasi menumpang pada prepaid modul Fixed Asset

6 Special GL untuk intern reimbursement: H P Saat ini special GL untuk intern reimbursement menyebabkan proses berulang, dari park dokumen oleh departemen AP kemudian post pembayaran dan jurnal oleh Treasury (AP/Bank), kemudian dijurnal lagi oleh departemen AP (Expense/AP) Special GL untuk intern reimbursement: AP/Clearing, yang dijurnal oleh Treasury 2 Modul Accounts Payable 2.1 Membuat daftar vendor H P Tidak semua vendor terdaftar dalam daftar vendor (onetimevendor) 2.2 Memaintain vendor H F Mendata terms of master records payment dan payment methods yang digunakan 2.3 Melakukan posting H F Merupakan tipe vendor invoice invoice yang tidak memiliki reference purchase order Memasukkan setiap vendor ke dalam kategori vendor yang ada

7 2.4 Memungkinkan pengecekan list invoice yang di input, sistem akan mensortir list yang benar dan masuk kedalam data dan menolak list yang salah untuk dilakukan koreksi kembali. 2.5 Menggunakan recurring entry program untuk posting reguler/rutin 2.6 Melakukan posting manual outgoing payment 2.7 Menjalankan automatic outgoing payment 2.8 Memaintain parameter untuk payment 2.9 Memeriksa dan mengedit payment proposal L G Jika terjadi kesalahan pada nomor invoice yang diinput, maka user harus mengulang kembali input dari awal H F Posting otomatis untuk transaksi rutin, seperti misalnya pembayaran sewa H F Posting untuk pembayaran transaksi yang dilakukan secara manual H F Melakukan posting transaksi dengan pembayaran otomatis H F Menentukan akun dan item mana saja yang termasuk dalam automatic payment run M F Memeriksa keakuratan data sebelum menjalankan payment program 80 Sistem hanya melakukan koreksi pada nomor invoice yang salah saja, sehingga user tidak perlu mengulang kembali proses input

8 Menjalankan pembayaran (payment run) 2.11 Menampilkan due date analysis report 2.12 Mengecek account balance dan line items H F Memposting dokumen pembayaran, menghapus open items, menyiapkan data untuk media pembayaran H F Untuk mengetahui open items yang akan jatuh tempo H F Untuk mengetahui apakah dokumen yang di post sudah masuk kedalam list open items 3 Modul Accounts Receivable 3.1 Memaintain customer master records 3.2 Memasukkan dan mengubah invoice konsumen 3.3 Memungkinkan untuk mengirimkan tagihan melalui H F User dapat mengedit, menambahkan, maupun menghapus data customer H F Untuk mengetahui besarnya piutang yang dapat dikontrol secara daily basis M F User dapat mengirimkan langsung tagihan kepada customer melalui

9 Dapat menghasilkan Aging Accounts Receivable Report H F Untuk mengetahui besarnya Piutang pada setiap akhir periode Tabel 4.2. Hasil Analisis Fit/Gap Degree of Fit F P G H Ranking M 3 Requirements L 1 1 Total 24/29 x 100% = 83% 3/29 x 100% = 10% 2/29 x 100% = 7% Gambar 4.1 Pie Chart Presentasi Hasil Analisis Fit/Gap

10 Rekomendasi Hasil Fit/Gap Analysis Berdasarkan pada hasil analisis di atas, dapat disimpulkan bahwa sistem SAP yang diterapkan oleh PT. Sarihusada Generasi Mahardhika, yaitu pada modul Financial Accounting, telah berjalan dengan cukup baik. Seperti yang tergambarkan pada tabel dan grafik di atas, bahwa prioritas High(H) atas sistem yang berjalan sekarang telah dimanfaatkan dengan baik oleh perusahaan. Namun dapat dilihat pula dari tabel di atas bahwa masih terdapat kesenjangan yang terjadi atas requirement yang dimiliki oleh perusahaan, sehingga perusahaan dianjurkan untuk melakukan kustomisasi. Berikut merupakan rekomendasi yang dihasilkan dari analisa Fit/Gap yang dilakukan: Tabel 4.3 HasilAnalisis Fit/Gap Alternatives Sistem dapat menghasilkan laporan untuk Payment Analysis secara rutin pada akhir periode setelah closing Sistem dapat melakukan proses maintain amortisasi prepaid Special GL untuk intern reimbursement: AP/Clearing, yang dijurnal oleh Treasury Memasukkan setiap vendor kedalam kategori vendor yang ada Sistem hanya melakukan koreksi pada nomor PO yang salah saja, sehingga user tidak perlu mengulang kembali proses input Level High High High High Low Kelima alternatives tersebut di atas merupakan usulan yang diberikan berdasarkan hasil analisa yang telah dilakukan, dimana alternatif yang diberikan merupakan alternatif atas requirementyang termasuk di dalam tingkat HighGap (1), LowGap (1), dimana sistem berjalan belum memenuhi requirement perusahaan, dan HighPartial Fit (3), dimana sebenarnya perusahaan telah memiliki fungsi yang mendukung requirement tersebut, namun lebih baik jika perusahaan melakukan kustomisasi untuk menyempurnakan requirement tersebut agar penggunaannya lebih

11 maksimal dan memberikan dampak positif serta memberikan nilai lebih bagi perusahaan Rencana Implementasi Payment Analysis Report Tabel 4.4 Payment Analysis Report Tipe Payment Analysis Report Analisis Masalah Sistem belum dapat mengkonfigurasi Payment Analysis Report, dimana pengelolaan laporan ini masih dilakukan secara manual menggunakan Ms.Excel Kebutuhan Sistem Sistem menyediakan laporan untuk Payment Analysis dengan detail per mata uang yang digunakan untuk pembayaran Usulan Rekomendasi Mengkonfigurasi sistem agar dapat menghasilkan laporan sesuai dengan kebutuhan pengguna laporan Deskripsi Rekomendasi Payment Analysis Report ini dibuat dengan tujuan untuk mengolah data pembayaran menjadi informasi yang bernilai. Berfokus pada pengelolaan seluruh pembayaran/pengeluaran kas dilakukan oleh perusahaan. Laporan ini terdiri atas 2 menu, yaitu: Summary Report Transaction details Dimana Summary Report merupakan rangkuman total dari masingmasing pengelompokan biaya, sesuai dengan mata uang yang digunakan dalam pembayaran, yang dapat ditampilkan sesuai dengan

12 85 periode yang diinginkan. Transaction Details merupakan subreport yang berisikan tentang detail transaksi dari setiap kelompok/kategori biaya yang ada. Laporan ini dapat ditampilkan sesuai dengan periode (mm/yyyy) dan mata uang yang dipilih (AUD/EUR/IDR/SGD/USD) Sistem SAP berjalan belum dapat menghasilkan Payment Analysis Report yang digunakan sebagai acuan untuk analisa perencanaan pengeluaran periode berikutnya. Solusi yang diberikan adalah sistem dapat menghasilkan Payment Analysis Report, dimana tampilan laporan yang dihasilkan sesuai dengan kebutuhan pengguna laporan tersebut. Rancangan laporan yang diusulkan terdiri atas : Description : yang berisi pengelompokan biaya Currency : yang berisi pengelompokan mata uang yang digunakan untuk pembayaran (AUD, EUR, IDR, SGD, USD)

13 Berikut merupakan tambahan prosedur untuk konfigurasi Payment Analysis Report: 86 Gambar 4.2 Rancangan Tampilan MIR7 Gambar 4.3 Rancangan Tampilan FBL1N

14 87 Gambar 4.4 Rancangan Tampilan Awal Payment Analysis Report Pada proses Park/Post document, nantinya staff A/P akan menginput payment category pada form Park Incoming Invoice (MIR7) dengan memilih dari jenis kategori pembayaran yang sudah ada. Kemudian pada form FBL1N (Vendor Line Items Display) di bagian Treasury juga akan ditampilkan satu kolom tambahan, yaitu kolom Payment Category yang diautogenerate dari input yang telah dilakukan sebelumnya pada proses park document (MIR7). Setelah pembayaran terhadap vendor dilakukan dan posting transaksi oleh A/R Accountant, maka Treasury Manager dapat melihat Payment Analysis Report. Berikut merupakan prosedur untuk memproses Payment Analysis Report: 1. Pada tampilan awal Payment Analysis Report, user menginput: Company Code : diisi dengan Company Code Sarihusada Fiscal Year : diisi sesuai dengan tahun fiskal yang ingin ditampilkan Posting Date : diisi dengan tanggal posting pembayaran yang ingin ditampilkan, dengan format (dd.mm.yyyy) Mode : diisi sesuai dengan format tampilan yang diinginkan, yaitu: display all : menampilkan Summary Report atau resume keseluruhan laporan details only : menampilkan Transaction Details atau detail

15 88 transaksi. Jika menu ini yang dipilih, maka berikutnya, user harus memilih jenis mata uang yang ingin ditampilkan (AUD/EUR/SGD/IDR/USD). 2. Selanjutnya user dapat memilih icon jam (simulate) untuk memproses laporan. Berikut merupakan rancangan tampilan laporan yang diusulkan : Gambar 4.5 Rancangan Tampilan Payment Analysis Report Summary (1) Gambar 4.6 Rancangan Tampilan Payment Analysis Report Summary (2)

16 89 Gambar 4.7 Rancangan Tampilan Payment Analysis Report Summary (3) Gambar 4.8 Rancangan Tampilan Payment Analysis Report Summary (4)

17 90 Gambar 4.9 Rancangan Tampilan Payment Analysis Report Transaction Details Laporan terdiri atas 2 bagian, yaitu yang pertama adalah Summary Report, dimana yang ditampilkan hanyalah ringkasan total biaya per pengelompokkan biaya dengan setiap mata uang yang digunakan. Kemudian pada bagian kedua nantinya user dapat melihat detail transaksi pada Transaction Details screen, dimana akan ditampilkan detail transaksi dari setiap kelompok biaya yang ada, yang dapat ditampilkan sesuai dengan periode dan mata uang yang diinginkan. Rancangan tampilan Transaction Details terdiri atas: Period Berisi periode yang ditampilkan, dengan format : mm/yyyy Currency Berisi mata uang yang ditampilkan, dengan pilihan : AUD/EUR/IDR/SGD/USD Value Date Berisi tanggal pembayaran oleh Bank Payment Method/Type Berisi tipe metode pembayaran, dengan pilihan : Domestic Funds Transfer / Cross Border Funds Document Number Reference Berisi referensi nomor dokumen yang terdapat pada SAP Transaction Reference

18 91 Berisi referensi nomor transaksi Bank Status Berisi status pembayaran, terdiri atas : Processed, Level 3 Approvement Beneficiary or Debit Party Name Berisi nama vendor atau penerima pembayaran Payment Amount Berisi jumlah yang dibayarkan Amortisasi Prepaid Tabel 4.5 Amortisasi Prepaid Tipe Laporan Amortisasi Prepaid Analisis Masalah Pada sistem berjalan saat ini, pengelolaan amortisasi Prepaid menumpang pada modul Fixed Asset. Kebutuhan Sistem Sistem menyediakan laporan untuk memaintain amortisasi Prepaid Usulan Rekomendasi Mengkonfigurasi sistem agar dapat menghasilkan laporan sesuai dengan kebutuhan pengguna laporan Deskripsi Rekomendasi Laporan amortisasi prepaid ini dibuat dengan tujuan untuk memantau dan mengelola amortisasi prepaid sehingga nantinya dapat diketahui jumlah piutang yang tersisa pada setiap akhir periode. Berfokus pada pengelolaan amortisasi prepaid yang dapat dimaintain secara manual.

19 Special G/L untuk internal reimbursement Tabel 4.6 Special G/L untuk internal reimbursement Tipe Special G/L Account Analisis Masalah Saat ini prosedur sistem berjalan dinilai kurang efektif karena menyebabkan proses berulang, yaitu park document oleh staff AP, kemudian post pembayaran dan post jurnal oleh Treasury, lalu dilakukan adjustment oleh SPV AP. Kebutuhan Sistem Special G/L untuk intern reimbursement adalah AP/Clearing yang diposting oleh Treasury. Usulan Rekomendasi Mengkonfigurasi sistem agar sesuai dengan Special G/L account tersebut, sehingga tidak perlu ada proses berulang. Deskripsi Rekomendasi Proses yang diusulkan adalah: Park Documents oleh staff AP > post pembayaran dan kemudian posting jurnal oleh Treasury, yaitu: Accounts Payable xxx Clearing xxx

20 Vendor Master Data Tabel 4.7 Vendor Master Data Tipe Analisis Masalah Kebutuhan Sistem Usulan Rekomendasi Deskripsi Rekomendasi Vendor Master Data Sesuai dengan kebijakan perusahaan, maka kateogori onetimevendor ingin dihilangkan, sehingga nantinya semua vendor, baik yang telah terdaftar sebagai onetimevendor maupun calon vendor baru, harus terdaftar dalam kategori Vendor yang ada pada Vendor Master Data Mengeliminasi kategori onetimevendor Mengupdate Vendor Master Data Melakukan penyesuaian/update kategori terhadap seluruh vendor yang termasuk dalam kategori onetimevendor (ZZ ZZ999999) dan nantinya seluruh vendor baru juga harus terdaftar dalam kategori yang ada, yaitu: Vendor Dalam Negri ( ) Vendor Luar Negri ( ) Vendor Capex ( ) Semua vendor baru harus didaftarkan terlebih dahulu dengan mengirimkan form vendor kepada calon vendor baru, kemudian jika calon vendor baru sudah mengisi form tersebut, maka staff SSD wajib melaporkan hal tersebut dengan mengirimkan new vendor request form untuk kemudian didatakan oleh A/P SPV ke dalam Vendor Master Data

21 94

22 Koreksi nomor Purchase Order Tabel 4.8 Koreksi Nomor Purchase Order Tipe Analisis Masalah Kebutuhan Sistem Usulan Rekomendasi Deskripsi Rekomendasi Sistem Koreksi Nomor Purchase Order Pada proses Park document, jika terjadi kesalahan pada nomor invoice yang diinput, maka user harus mengulang kembali input nomor invoice dari awal. Sistem hanya melakukan koreksi pada nomor invoice yang salah saja. Melakukan konfigurasi sistem dalam proses post document, yaitu pada proses validasi nomor invoice. Pada proses validasi nomor invoice, sistem memungkinkan dilakukannya pengecekan list nomor invoice dengan mensortir list yang benar dan kemudian menyimpan data tersebut dan menolak nomor invoice yang salah dan user harus melakukan koreksi terhadap nomor invoice yang salah.

23 Gantt Chart Berikut merupakan perkiraan waktu pelaksanaan reimplementasi upgrade SAP ECC 6.0 : Tabel 4.9 Gantt Chart Kegiatan Minggu Total Durasi Wawancaradanpengembanga nuser requirements 7 hari Meeting consultant dankonfigurasisistem Testing danevaluasi 60 hari 21 hari SAP Launching 2 hari Reimplementasikeseluruhan 7 hari