ERP Axapta – Dimension : Departement, Cost Center, dan Purpose Yang Membingungkan !

Salah satu pertanyaan saya kepada mantan implementor yang pergi tanpa pamit adalah : Apakah fungsi Dimension: Departement, Cost Center, dan Purpose?.  Mengapa implementasi selama ini hanya menggunakan satu pilihan saja, yaitu Departemen!?.  Lebih dua tahun implementor berkutat dan melakukan implementasi Microsoft Dynamic Axapta hanya dengan satu pilihan dimension saja !.  Data memang disusun begitu, sesuai dengan permintaan dari Konsultan.  Jawaban yang diberikan masih sangat standar dan karena penggunaannya tidak jelas, maka hasilnya seperti yang saya duga.  Penuh dengan aral !.  Di sisi lain, saya yakin bahwa menu pilihan departement, cost center, dan purpose tentulah memiliki tujuan dalam proses bisnis.  Tapi seperti apa?, bagaimana ini digunakan?, adalah persoalan tersendiri yang jawabannya selalu menggantung.

Logika Proses Bisnis

Boleh jadi kita sudah hafal di luar kepala dan menghayati proses bisnis dalam modul-modul yang sesuai dengan Value Chain Porter atau model-model yang disajikan dalam beragam ERP Model (ERP = Enterprise Resources Planning) dari berbagai jenis industri dan dalam berbagai variasinya.  Oleh karena “kerumitannya”, very complicated gitu, program-program seperti SAP, Microsoft Axapta, Baan, Oracle, dan lain-lain menempati tempat istimewa dalam industri sistem informasi dan proses bisnis.  Contoh ini mungkin kurang relevan, tapi menurut saya cukup bisa diketengahkan adalah ketidakpahaman implementor dalam menerapkan satu proses bisnis yang tersedia dalam Axapta, yaitu Departement, Cost Center, dan Purpose.  Dan masih banyak contoh proses lainnya dalam sistem terintegrasi diterapkan dengan cara yang tidak tepat.

Logika Akuntansi dan Bisnis skala Enterprise.

Program Akuntansi terintegrasi sudah banyak. Mulai dari yang murah sampai yang mahal dan super mahal.  Beberapa program yang mendekati skala-skala besar bisnis dicoba dekati oleh para pemain lokal.  Salah satu yang mengemuka adalah Zahir yang juga mengekspor programnya ke pasaran internasional.  Cukup sukses mereka itu.  Tentu saja Zahir Accounting Software, versi Enterprise sekalipun bukanlah lawan sekelas Dynamic Axapta, apalagi Oracle atau SAP yang mahalnya selangit. Namun, pemain internasional itu juga mengeluarkan versi untuk usaha kelas menengah dalam rangka memperluas pasarnya.

Meskipun sama-sama bermuara di akuntansi, memang ada perbedaan sedikit (eh banyak) antara modul logika akuntansi dan ERP.  Format sistem dalam software-software akuntansi dan erp sama-sama bermuara ke account-account akuntansi juga.  Namun, ERP kemudian mengintegrasikan proses bisnis dalam kesatuan utuh sistem informasi, sedangkan software-software akuntansi hanya berfokus pada proses dan laporan keuangan saja.  Campur tangan pada bisnis proses dan fleksibilitas menghadapi proses bisnis kurang diakomodir.  Ini yang menjadikan ERP bisa eksis dengan harga tinggi dan mahal di tengah kancah bisnis informasi.

Contoh sederhananya, ERP Software akan mengakomodasi kegiatan penjurnalan akuntansi dari satu cabang perusahaan nun jauh di sana yang biayanya dikeluarkan cabang tersebut tapi dibebankan kepada account-account di kantor cabang lain.  Cabang lain tersebut tidak perlu mencatatkan pertanggung jawaban yang telah dicatatkan di cabang atau kantor pusatnya.  Semua dengan indah dikonsolidasikan — on line — lagi.

Contoh lain, peran pelanggan sekaligus sebagai supplier diakomodasikan dengan baik oleh sistem informasi yang terintegrasi.  Kebijakan-kebijakan marketing (discount produk, diskon ke pelanggan, pembuatan paket diskon) dan lain-lain diakomodasikan sistem dan prosedurnya dengan baik.

Masih contoh juga, alokasi biaya antar cabang, bagaimana mendistribusikan biaya-biaya setiap departemen pada satu perusahaan dan account-account yang aktif dari satu cabang ke cabang lain di atur oleh sistem adalah satu bagian yang menjadi keunggulan sistem erp.  Singkat kata, ERP memanajemini sistem informasi bisnis dan mengendalikannya.

Oleh karena itu, meskipun software akuntansi adalah juga berujung pada” executive summary for business activities“,  namun berbeda kelas dengan erp yang memberikan disain sistem bagaima proses ini dikendalikan dan dikontrol sampai level operasional.  Inilah tantangan yang menarik.

Oleh karena itu, ketika implementor tidak bisa menjawab dan mengimplementasikan sistem dengan hanya satu dimension saja, maka saya menduga bahwa proses implementasi yang sedang berjalan adalah penggundulan Axapta , persis seperti gundulnya hutan-hutan Indonesia.

Dimension: Departement, Cost Center, Purpose.

Kembali ke topik awal, saya juga terus terang ketika mempelajari apa itu dimension dalam axapta mengalami kesulitan, apalagi jawaban yang diperoleh dari “ahli”nya sangat tidak memuaskan.  Data yang tersusun dalam sistem juga hanya diisi departemen saja.  Meskipun demikian, toh software mahal itu bisa jalan juga.  Jalan apa adanya.  Jalan dengan penerapan yang sangat boleh jadi tidak sesuai dengan harapan disainer axaptanya.

Kemudian, yang dapat saya pahami dari dimension yang memiliki tiga unsur ini yang baru dapat saya pahami adalah bagian dari pengendalian dan kemudahan sistem entry data.  Terkait dengan pengendalian user dan setup sistem ketika program canggih ini akan dipakai.  Dimension bukanlah hierakhi data atau organisasi, jadi jangan bayangkan sebagai sebuah struktur organisasi.  Dimension lebih mirip kombinasi dari irisan-irisan data untuk sampai pada account-account dari ledger.  Segalanya bermuara ke sana, tapi jalan menuju ke sana adalah konsepsi bisnis !.

Katakanlah perusahaan A memiliki 10 Cabang, setiap cabang memiliki 30 Departemen-departemen (akunting, logistik, pembelian, pool kendaraan, bagian penjualan, dan seterusnya).  Ini adalah departemen yang diisikan pada menu dimension.  Cost Center akan melakukan irisan dari departement-departement untuk mengakomodasi departement di atasnya yang punya fungsi-fungsi akuntansi pada departemen tersebut.  Jadi misalnya Departemen Logistik yang punya bagian dept. akuntansi sendiri dan punya Pool Kendaraan sendiri, maka isian Cost Center dari sesuai bagiannya dengan akuntansi dan pool kendaraan.  Purpose kemudian mengarahkan pada account yang ditentukan.  Pemilihan setup yang tepat dari dimension akan membuat pekerjaan dan arah pemilihan account menjadi mudah dan terlokalisir.   Ini menolong untuk mengurangi tingkat kesalahan yang terjadi.

Kombinasikan dengan hak user dalam sistem, maka pemakai akan bekerja sesuai dengan bagian-bagiannya dan proses bisnis menjadi lebih ringkas dan hemat.  Kemungkinan kesalahan menjadi minimum.  Tapi jika bagian-bagian dimension ini hanya diisi dengan “Departement” saja, maka jika satu departement ada 10 bagian di dalamnya, dimension yang disi menjadi 10, jika ada kombinasinya maka kombinasinya harus juga ditulis di bawahnya.  Akhirnya departement menjadi pilihan yang banyak dan ribet.  Ini hanya satu sisi saja dari pemakaian dimension, saya kira untuk bidang-bidang lain pemanfaatan dimension ini diperlukan dalam group yang apik dan terarah agar muara ke ledger berjalan dengan tepat dan baik.  Mengelompokkan dalam satu isian (departemen saja) tidak bisa disalahkan.  Ini seperti memasukkan apapun barang anda dalam gudang yang sama, tidak perduli apakah itu permata, atau pakaian.  Namun optimasi sistem jangan diharapkan bekerja sebagai bagian dari usaha untuk menghemat daya.  Ini tidak akan bisa dicapai kalau penerapan tidak sesuai dengan disain sistem.

Sepertinya, di sini pentingnya melihat dan mengkombinasikan pemahaman proses bisnis, siklus bisnis, prinsip-prinsip akuntansi, dan memanajemeni sistem informasi agar kita bisa memaksimalkan peranan Software ERP dengan baik.  Pengalaman selama ini mengajarkan pula bahwa klasifikasi, grouping data dari program yang dibuat sendiri dan term-term yang dibuat berdasarkan pengalaman dan selera ternyata tidak tepat untuk diterapkan langsung pada sistem standar.  Beberapa tahun terakhir ini membangun klasifikasi-klasifikasi untuk sistem reporting perusahaan dan dipakai mulus-mulus saja.  Ternyata setelah  belajar kembali, baru sadari bahwa klasifikasi yang dibuat, bukan hanya kompatibel dalam sistem sederhana.  Harus dipetakan ulang ketika integrasi ke sistem informasi akan dibangun.  Pemetaan ini, artinya skala kerja dari sistem lama dan logika-logika hierarkhis yang dikenali oleh sumber daya perusahaan juga harus ditata ulang.  Ini tantangannya, jadi wajar saja kalau begitu implementor menyerah karena saya juga berpikir mana yang lebih enak jus nangka, jus melon, atau jus baygon….

😀