74
EVALUASI MODUL FINANCIAL ACCOUNTING BERBASIS SAP
4.1. Fit/Gap Analysis
Analisis Fit/Gap dilakukan dengan membandingkan fitur-fitur 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)
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.
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 Chart of Accounts H F Sistem 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 account group ke dalam bahasa lain dan dapat membuat keyword untuk mencari akun tersebut
L F Menggunakan Key word/transaltion - 1.3 Dapat membuat G/L accounts H F Sistem memungkinkan user untuk membuat G/L Accounts baru - 1.4 Dapat menampilkan G/L account list H F Menampilkan chart of accounts yang spesifik untuk satu -
company code tertentu 1.5 Dapat memaintain financial statement version H F Memastikan bahwa setiap account G/L tercantum dalam versi financial statement yang benar 1.6 Dapat mengeksekusi posting G/L H F Eksekusi posting G/L menggunakan Enjoy Screen dan traditional screen untuk posting yang lebih kompleks - 1.7 Dapat menjalankan balance sheet H F Sistem dapat menampilkan balance sheet sesuai dengan accounting period yang diinginkan -
1.8 Dapat menampilkan cost elements
H F Digunakan untuk memposting obyek pada controlling, seperti misalnya cost centers dan internal orders
1.9 Adanya reconciliation Accounts
H F Menghubungkan Subsidiary Ledger dengan General Ledger secara real-time, sehinggaapa yang di post pada subsidiary Ledger jugater-update pada General Ledger
-
1.10 Dapat men-drill down asal dokumen dari account yang terdapat pada account G/L
M F Sistem dapat melacak asal dokumen dari GL account yang ada
-
1.11 Dapat menghasilkan laporan yang
memungkinkan
pengguna laporan untuk melakukan analisa terhadap laporan tersebut
H G Sistem belum dapat menghasilkan laporan Payment Analysis Sistem dapat menghasilkan laporan untuk Payment Analysis secara rutin pada akhir periode setelah closing
1.12 Dapat me-maintain amortisasiprepaid
H P Selama ini proses maintain
amortisasi menumpang pada modul Fixed Asset
Sistem dapat
melakukan proses maintain amortisasi prepaid
1.13 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 (one-time-vendor) Memasukkan setiap vendor ke dalam kategori vendor yang ada 2.2 Memaintain vendor master records H F Mendata terms of payment dan payment methods yang digunakan - 2.3 Melakukan posting vendor invoice H F Merupakan tipe invoice yang tidak memiliki reference purchase order
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.
L G Jika terjadi kesalahan pada nomor invoice yang diinput, maka user harus
mengulang kembali input dari awal
Sistem hanya melakukan koreksi pada nomor invoice yang salah saja, sehingga user tidak perlu mengulang kembali proses input
2.5 Menggunakan recurring entry program untuk posting reguler/rutin H F Posting otomatis untuk transaksi rutin, seperti misalnya pembayaran sewa - 2.6 Melakukan posting manual outgoing payment H F Posting untuk pembayaran transaksi yang dilakukan secara manual - 2.7 Menjalankan automatic outgoing payment H F Melakukan posting transaksi dengan pembayaran otomatis - 2.8 Me-maintain parameter untuk payment H F Menentukan akun dan item mana saja yang termasuk dalam automatic payment run
-
2.9 Memeriksa dan mengedit payment proposal M F Memeriksa keakuratan data sebelum menjalankan payment program -
2.10 Menjalankan pembayaran (payment run) H F Memposting dokumen pembayaran, menghapus open items, menyiapkan data untuk media pembayaran
-
2.11 Menampilkan due date analysis report
H F Untuk mengetahui open items yang akan jatuh tempo
-
2.12 Mengecek account balance dan line items
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 H F User dapat mengedit, menambahkan, maupun menghapus data customer - 3.2 Memasukkan dan mengubah invoice konsumen H F Untuk mengetahui besarnya piutang yang dapat dikontrol secara daily basis - 3.3 Memungkinkan untuk mengirimkan tagihan melalui e-mail M F User dapat mengirimkan langsung tagihan kepada customer melalui e-mail -
3.4 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 Ranking Requirements H 21 3 1 M 3 - - L 1 - 1 Total 24/29 x 100% = 83% 3/29 x 100% = 10% 2/29 x 100% = 7%
4.2. 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 Level
Sistem dapat menghasilkan laporan untuk Payment Analysis secara rutin pada akhir periode setelah closing
High
Sistem dapat melakukan proses maintain amortisasi prepaid
High
Special GL untuk intern reimbursement: AP/Clearing, yang dijurnal oleh Treasury
High
Memasukkan setiap vendor kedalam kategori vendor yang ada
High
Sistem hanya melakukan koreksi pada nomor PO yang salah saja, sehingga user tidak perlu mengulang kembali proses input
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 High-Gap (1), Low-Gap (1), dimana sistem berjalan belum memenuhi requirement perusahaan, dan High-Partial 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
maksimal dan memberikan dampak positif serta memberikan nilai lebih bagi perusahaan.
4.3. Rencana Implementasi
4.3.1. 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 masing-masing pengelompokan biaya, sesuai dengan mata uang yang digunakan dalam pembayaran, yang dapat ditampilkan sesuai dengan
periode yang diinginkan.
Transaction Details merupakan sub-report 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)
Berikut merupakan tambahan prosedur untuk konfigurasi Payment Analysis Report:
Gambar 4.2 Rancangan Tampilan MIR7
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 di-autogenerate 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
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.7 Rancangan Tampilan Payment Analysis Report - Summary (3)
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
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
4.3.2. 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 me-maintain 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 di-maintain secara manual.
4.3.3. 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
4.3.4. Vendor Master Data
Tabel 4.7 Vendor Master Data
Tipe Vendor Master Data
Analisis Masalah Sesuai dengan kebijakan perusahaan, maka kateogori one-time-vendor ingin dihilangkan, sehingga nantinya semua vendor, baik yang telah terdaftar sebagai one-time-vendor maupun calon vendor baru, harus terdaftar dalam kategori Vendor yang ada pada Vendor Master Data
Kebutuhan Sistem Mengeliminasi kategori one-time-vendor Usulan Rekomendasi Meng-update Vendor Master Data Deskripsi Rekomendasi Melakukan penyesuaian/update kategori
terhadap seluruh vendor yang termasuk dalam kategori one-time-vendor (ZZ000000 – ZZ999999) dan nantinya seluruh vendor baru juga harus terdaftar dalam kategori yang ada, yaitu:
- Vendor Dalam Negri (10000 - 19999) - Vendor Luar Negri (20000 – 29999) - Vendor Capex (40000 – 49999)
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
4.3.5. Koreksi nomor Purchase Order
Tabel 4.8 Koreksi Nomor Purchase Order
Tipe Sistem Koreksi Nomor Purchase Order
Analisis Masalah Pada proses Park document, jika terjadi kesalahan pada nomor invoice yang diinput, maka user harus mengulang kembali input nomor invoice dari awal. Kebutuhan Sistem Sistem hanya melakukan koreksi pada
nomor invoice yang salah saja.
Usulan Rekomendasi Melakukan konfigurasi sistem dalam proses post document, yaitu pada proses validasi nomor invoice.
Deskripsi Rekomendasi 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.
4.4. Gantt Chart
Berikut merupakan perkiraan waktu pelaksanaan re-implementasi upgrade SAP ECC 6.0 :
Tabel 4.9 Gantt Chart
Kegiatan Minggu Total Durasi 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 13 14 Wawancaradanpengembanga
nuser requirements 7 hari Meeting consultant dankonfigurasisistem 60 hari Testing danevaluasi 21 hari SAP Launching 2 hari
