Sains-Inreligion

بِسْمِ اللَّهِ الرَّحْمَنِ الرَّحِيمِ

Dua Tahun Ribet Bersama Implementasi ERP Axapta-5

Posted by agorsiloku pada November 27, 2007

Tidak Boleh Menyerah.

Setelah merasa bahwa masih banyak masalah dalam implementasi maka usaha untuk membalikkan keadaan agar implementasi tetap mencapai arah yang dikehendaki maka kami memutuskan 3 hal pokok :

Rekrut SDM yang mengerti Axapta untuk melakukan pemeriksaan pekerjaan yang berjalan.

Siapkan/terus bangun software internal sebagai antar muka untuk menangkap data kegiatan perusahaan (khususnya di modul Trade Logistik (sempurnakan karena sudah termasuk legacy system, HRD – belum dimiliki, dan Cash Manajemen). Kami tak mungkin menunggu-nunggu hasil dari Axapta yang mahal itu.

Mengembangkan Kas Kecil.

Berawal dari kekecewaan kami kepada Kas Kecil pendukung Axapta, Tim Internal IT dengan dukungan penuh dari Sang Pemulung sebagai tokoh sentral, Oracle Girl, Penemu Jalan Buntu, serta kesabaran Sumeleh, kami bekerja siang malam untuk membuat ‘tandingan’ kondisi stagnasi yang dihadapi.

Tidak banyak yang dapat kami ceritakan, tapi perkembangan Kas Kecil kami ketengahkan sebagai bagian dari upaya pemecahan masalah untuk menangkap data perusahaan.

Pada prinsipnya semua kegiatan perusahaan yang berkenaan dengan transaksi selalu dimulai dari hal-hal rutin dan kecil-kecil saja, kemudian berakumulasi menjadi lebih besar dan lebih kompleks. Persoalannya, bagaimana sebaran data yang banyak dan luas itu dapat dikendalikan dan dikumpulkan dengan baik.

Oleh karena itu, program Kas Kecil dibuat untuk mencatat semua kejadian biaya dan dokumentasi serta pelaksanaan kegiatan penjualan melalui modul Trade Logistik.

Menetapkan kunci-kunci informasi.

Berbekal kekonyolan dan kenekadan yang ada, kami menetapkan langkah-langkah untuk menjawab persoalan antara lain :

Kegiatan transaksi harus dimulai dari Sales Order, Invoicing, sampai penjurnalan. Program harus terkait erat dengan masalah dalam permainan diskon (fleksibel diskon, tergantung dengan pelanggan dan kelas pelanggannya, mencatat retur dan pengembalian fisik barang ataupun penerimaan barang mencatat, sampai pembayaran pelanggan). Singkat kata, modul Trade Logistik haruslah dapat menjawab kebutuhan :

Multiple price, multiple discount, multiple customer, dan multiple product. Juga mencatat dengan tepat untuk kasus pembatalan pesanan, pengembalian barang, dan aspek-aspek yang berkenaan dengan penagihan baik tunai maupun intermediasi bank.

Program SDM yang dibuat (karena kami masih harus memikirkan, pakai modul HRD AXAPTA atau develop sendiri). Program SDM harus dapat mengunci informasi keseluruhan yang berkenaan dengan karakter organisasi dan perilaku manusia. Bagaimana menghadapi level organisasi yang berubah-ubah baik lokasi maupun kedudukannya, dobel jabatan, dan lain-lain. Kemudian mengawinkan data HRD dengan transaksi, kegiatan pelatihan karyawan, dan lain-lain.

Program Kas Kecil harus dapat menangkap aktivitas usaha, mulai dari pengajuan biaya perjalanan dinas sampai realisasinya, rencana pembelian asset, pembelian bahan baku, pencatatan kas kecil, penjurnalan akuntansi, dan proses-proses detailnya yang terjadi saat transaksi biaya berlangsung.

Tentu saja, masalah teknis yang ditetapkan juga harus dipertimbangkan :

  1. Level sekuriti dan hak akses, multi user, dan webbase.
  2. Reporting dan warning sistem harus memenuhi lapisan dari setiap fungsi manajerial.
  3. Data diinput dari unit-unit terkecil dari satuan informasi yang akan dibentuk. Jadi bukan dikumpulkan dalam satu atap dan dikerjakan di bagian lain.
  4. Data harus dibentuk sesuai dengan nomor account yang ditetapkan dan dapat dikembangkan (sub-sub ledger) sehingga detail informasi bisa ditangkap.
  5. Data harus memiliki skala variabel terhadap ukuran, entah itu berat, luas, volume, satuan, atau apa saja serta mencatat history dari pembelian yang terjadi.
  6. Organisasi dan karyawan harus menjadi titik sentral pelaporan terhadap kegiatan penjualan, penagihan, biaya, perhitungan time sheet manajemen. Disain perubahan organisasi harus fleksibel terhadap level, posisi jabatan, memiliki struktur informasi terinci untuk setiap kejadian yang menyebabkan seorang karyawan menerima “take home pay” berikut segala potongannya.

Oleh karena itu master informasi harus dapat dikembangkan dari beberapa komponen inti yang dinamis dan fleksibel :

  1. Pelanggan dan kontak detail dari pelanggan (institusi dan personal yang terlibat).
  2. Item produk terklasifikasi sesuai dengan karakteristik produk. Item produk dapat digabung dan dipecah dalam satuan-satuan produk lainnya dengan tetap dapat mengendalikan sistem pergudangan.
  3. Vendor informasi harus lengkap terdata.
  4. Mencatat dan mengendalikan biaya (budgetting).
  5. Mengontrol plafon pelayanan pada pelanggan dan mengkombinasikan dengan pengiriman dan penagihan.
  6. dan lain-lain.

Secara keseluruhan point-point ini dijadikan acuan mengikuti supply chains Porter. Kami yakin, kalau program didisain dalam satu kerangka kerja dan konsep yang tepat, maka perubahan yang dihadapi lebih mudan diantisipasi dan program bisa lebih mudah dikembangkan.

Setidaknya, ini yang kami tetapkan dan kebut. Dalam perjalanan inilah, ternyata banyak hal bisa kami temukan, bagaimana membuat program yang relatif cepat dan baik serta mudah untuk dikembangkan, sambil tetap memiliki kemungkinan untuk upload ke sistem ERP Axapta yang dimodifikasi.

Garis besar point-point yang dipikirkan seperti berikut ini (garis tebal adalah yang kami prioritaskan) :

Account management
Accounts payable
Accounts receivable
Benefits management
Budgeting
Business intelligence (BI)/enterprise performance management (EPM)
Capital asset management
Cash management
Contact management
Cost accounting
Customer contract management
Customer relationship management (CRM)
Customer service and support
Data warehouse functions
Document management
Earned value measurement (EVM)
Employee self-service
Expense management
Financial reporting
Financials and accounting
Fixed assets
General ledger
Human resources
Invoice management.
Marketing automation
Multiple user management
Partner management
Payroll
Performance appraisal
Personnel management
Portfolio management
Process management
Procurement and on-line reporting
Project accounting
Project costing and billing
Project management
Purchase order management
Record management
Repetitive vendor procurement
Requisitions and quotation management
Resource sharing
Resource management
Risk management
Sales management
Time management
User preference and contact details
Vendor contracts and agreements management
Vendor relationship management (VRM)
Workflow manager

17 Tanggapan to “Dua Tahun Ribet Bersama Implementasi ERP Axapta-5”

  1. budi permana said

    saya ada rencana mau cari software ERP,
    budget untuk Microsoft Dinamic berapa ?
    kalau untuk company tambang batu bara axapta pernah di implementasikan apa belum ….

    @
    Kita bisa mencek, evaluasi dari berbagai site perihal ERP, seperti Technologi Evaluation, dll
    Cari kata di gugel dengan kunci ERP test, ERP Comparison, ERP Evaluation maka kita dapatkan beberapa hal mengenai ketepatan pemilihan dengan ERP yang kita rencanakan.

    Budget ERP tentunya tergantung skala usaha dan jumlah user. Bisa puluhan milyar bahkan ratusan milyar rupiah sampai beberapa milyar rupiah.

    Mengenai Axapta, apakah cocok di usaha pertambangan, saya belum tahu, namun kita bisa uji masalah kita dengan site-site yang relevan. Dari situ kita bisa dapatkan gambaran awal kemungkinan untuk dipakai atau tidaknya…..

    Suka

  2. […] « Dua Tahun Ribet Bersama Implementasi ERP Axapta-3 Dua Tahun Ribet Bersama Implementasi ERP Axapta-5 […]

    Suka

  3. wahjoe said

    Ternyata banyak yang senasib dengan kami dalam implementasi Axapta, Ceritanya hampir sangat-sangat persis dengan kejadian yang saya alami, dan ketika saya bertemu dengan beberapa pengguna axapta, kasusnya semuanya hampir mirip. Akhirnya kami implementasi axp sendiri tanpa bantuan Konsultan, dengan asumsi Tim IT kami lebih menguasai bisnis proses perusahaan, istilahnya lebih menguasai medan dibandingkan “KONSULTAN”/”yang Sekedar tukang Install”, selama kurang lebih 6 bulan kami lakukan implementasi sampai tidak libur karena dikejar target Go Live Agustus 2007, akhirnya Go live Agustus 2007 bisa tercapai dan sejak September 2007 sampai sekarang LANCAR. Saat ini Kami sedang evaluasi secara bertahap kekurangan dan kelebihan Axapta dan mencoba memaksimalkan axapta secara bertahap, dengan tujuan user tidak kaget dan kami tidak stress.

    @
    Betul Mas Wahyoe,… implementor dan tim IT harus kerjasama lebih baik, saling percaya dan memang harus cukup pengetahuan antara proses bisnis perusahaan dengan proses bisnis standar. Tahapan kejadian yang kami alami terutama pada proses migrasi data menyadarkan bahwa pengetahuan tim IT kami juga harus dibenahi. Dari Tim Konsultan juga, memang seharusnya mereka memiliki senior manajemen yang mengetahui aplikasi praktis dan standar bisnis yang bisa diadaptasi. Bukan hanya sekedar kustomisasi.

    Semoga pula semakin lancar, di tempat sampeyan… juga di tempat kami….. 😀

    Suka

  4. Andreas Kagawa said

    Pak Agor,

    Perkenalkan saya Andreas, Business Lead Microsoft Dynamics – Microsoft Indonesia yang juga mengcover Microsoft Dynamics AX (Axapta). Saya dan juga Microsoft sangat concern dengan pengalaman Bapak dan ingin sekali bisa membantu dan sumbang saran semampu kami. Apakah saya bisa menghubungi Bapak atau Bapak bisa hubungi saya di 25518100 ext 8171 atau email saya?

    Pak Wahjoe, menarik juga pengalaman Bapak mengimplementasikan AX sendiri. Mungkin kita bisa ngobrol2 juga

    Andreas

    Suka

  5. agorsiloku said

    @
    Mas Andreas, terimakasih untuk undangannya… segera rekan saya akan menghubungi Bapak dan membicarakan dengan sangat serius persoalan yang memang belum tuntas diselesaikan. Tentu kami harapkan pula Mas Andreas serius membantu kami, seperti sering Mas sampaikan dalam event-event Microsoft Indonesia yang dilakukan beberapa kali dalam tahun lalu dan tahun ini…. 😀

    Suka

  6. Andreas said

    Baik Pak … see u today at 3pm at your office

    @
    Semoga ada perbaikan yang radikal.. 😀

    Suka

  7. […] pernah bertemu dengan beberapa rekan kami sebelumnya memberikan catatan yang membungakan hati di komentar. Beliau konsen dengan pengalaman ini. Dan pada waktu yang ditentukan, beliau bersedia bertemu […]

    Suka

  8. Nuris said

    Terima Kasih banyak atas share pengalamannya, Pak Agor.

    Memang saat implementasi itu beberapa tahap kritis yg perlu di fix-kan sebelum di implement adalah sistem, atau bisnis prosesnya dulu. setelah itu baru komitmen semua pihak (konsultan & user) untuk berpegang dg bisnis proses tsb. Bukankan bisnis proses itu seharusnya dijadikan acuan bersama untuk implementasi?

    Faktor lain yg penting jg peran implementor, yg tidak hanya tau dg teknis & pemrograman, tapi harus tahu kondisi real lapangan, tahu aktifitas2 & laporan2 operasional, dan laporan2 yg diperlukan oleh pihak manajemen/decision maker.

    Itu semua harus didukung dg kemampuan untuk bisa melihat sistem secara terintegrasi, tahu keterkaitan antar modul, antar fungsi, antar prosedur, antar bagian, tahu & bisa memprediksi sebab-akibat suatu aktivitas transaksi.

    Oh, ya strategi implementasi jg perlu dipersiapkan dg matang.
    Maksudnya apakah mau implemen semuanya langsung, atau bertahap untuk bagian tertentu saja dulu. (biasanya yg aman, finance & akunting saja dulu, atau supply chain aja, tapi ga konek ke cost dulu).

    Menurut pengalaman & yg sy tahu, masalah ‘ribet’ muncul ketika berbicara ttg cost di material/barang (apalagi terkait dg cost produksi..brrrr). Kalo cuma finance & acconting relatif std, begiru jg kalo cuma inventory stok, tanpa cost, juga relatif ga susah. CMIIW

    wah..memang banyak banget syarat jd implementor nih.
    Ditunggu koment nya ya.. trims

    @
    Betul Mas, implementasi di tahapan finansial dan accounting relatif lebih mudah karena dibatasi (dijaga) oleh nomer-nomer account. Apalagi kalau memang yang disajikan dibatasi pada laporan keuangan dan tidak sampai ke titik detail dari setiap jenis transaksi dan pembagian analisis data per bagian dan dimensi-dimensi dalam organisasi.
    Terkait dengan produksi, pembuatan produk pertama dikenal sebagai BOM (Bill Of Material), membagi jenis produk dan jasa, biaya eksternal dan internal, biaya cost center dan profit center, analisis biaya customer as supplier customer as vendor sehingga konsolidasi menjadi mudah dalam sistem kerap tidak disadari dan disiapkan oleh implementor sehingga syarat data tunggal masuk dalam sistem tidak terpenuhi. Masing-masing punya SOP dalam bagian-bagian yang seharusnya dilebur dan disatukan agar masuk ke dalam sistem menjadi lebih tepat.
    Umumnya manajer perusahaan merasa bahwa “saya harus mengontrol sendiri departemen saya” menyebabkan redudansi dalam sistem, juga dalam SOP. Sering pembuat SOP juga adalah orang akuntansi murni yang memahami supply chain setengah-setengah menjadi penyebab efektifitas program gagal dijalankan secara efisien.
    Membagi dahulukan akunting dan finansial proses sepertinya jalan tengah, namun menimbulkan persoalan ketika proses seharusnya kurang disadari. Data masuk ke dalam sistem tidak pada group-group yang secara detil dan mengelompok untuk kebutuhan proses operasional yang efisien.
    Ketika tahapan masuk ke produksi, kemudian dirasakan bahwa “keterlanjuran” di modul akuntansi dan keuangan menjadi kedodoran. Tidak lengkap dan untuk turun ke bawah lagi menjadi hambatan baru.
    Jadi, meskipun masuk ke modul finansial menjadi jalan pintas, namun sebenarnya optimasi dari implementasi justru tidak maksimal. Program memang memberikan peluang jalan pintas “untuk akal-akalan”, namun jika setting bisa didisain sejak produksi, atau minimum disiapkan dari produksi, maka kunci-kunci informasi bisa naik ke atas tetap terjaga.

    Berdasarkan pengalaman terbatas, kemudian saya lebih memilih bahwa kunci-kunci data detail yang mandatory tetap harus dijaga dan tidak boleh blank meskipun pilihan mendahulukan modul finansial dilakukan. Ini sepertinya membuang energi untuk “yang belum diperlukan”. Namun, kecenderungan dalam sistem selalu terjadi : Pemenuhan satu kebutuhan akan melahirkan kebutuhan yang lain. Kebutuhan ini sudah diperhitungkan implementor ketika sistem dijalankan. Jadi, tidak kelabakan lagi.

    Kesulitan lain, adalah pemahaman sistem dan klasifikasi/grouping. Kerap terjadi, satu item objek transaksi, pelanggan, atau lainnya salah diklasifikasi karena ditetapkan hanya berdasarkan pengalaman dalam satu industri saja atau karena merasa ini cukup pada satu periode tertentu. Padahal, ketika kompleksitasnya meningkat dan usaha berkembang, baru dipahami bahwa klasifikasi yang dibuat berada pada lokasi di sistem yang salah. Akibatnya, software tidak mendukung. Ini juga penyakit yang kerap kurang disadari….. Padahal sebenarnya software erp menyediakannya. Tapi karena input sistem diabaikan, maka dimasa depan menjadi hambatan atau program tidak mampu menjawab. Padahal sistem sebenarnya menyediakan. Contohnya misalnya kebijakan diskon terhadap waktu, pelanggan, dan besaran produk. Penagihan dan pengiriman dikonsolidasikan pada banyak pelanggan dan penagihan pada institusi yang berbeda dan barang dari pergudangan yang berbeda. Karena kebiasaan hanya tunggal, maka data tidak memadai untuk mengefesienkan proses.
    Penyakit-penyakit kecil ini mempengaruhi keandalan sistem.

    Namun, apakah Pak Nuris juga menghadapi kendala yang sama. Bagi ya pengalaman Mas….

    Suka

  9. fredy said

    boleh tanya, saya sudah pakai ax dynamic, di perusahaan bapak ini export atau lokal

    perusahaan export
    Account Receivabel :
    1. no. packinglist sama invoice itu bisa tidak ya sama
    2. satu packing list/invoice bisa tidak lebih dari satu so, dia bisa tapi susah
    3. kalau sudah di posting, kalau ada perubahan bisa tdk ya, edit/hapus no yg sama

    @
    Mas Fredy,
    Packing list atau banyak dikenal sebagai packing slip adalah bukti penerimaan barang dari penjual kepada penerima (pelanggan). Akunting belum mencatatkan pengeluaran barang ke penerima ini sebagai pendapatan. Sedangkan invoice atau faktur dibuat setelah barang diterima oleh pelanggan. Jadi secara teknis standar, no. packing slip tidak sama dengan invoice. Nomor akun keduanya harus dibedakan.
    Karena penomoran/sequence dari packing slip berbeda, maka tentu saja bisa lebih dari satu. Sedangkan invoice bisa dibuat berdasarkan packing slip yang dibuat, tapi bisa juga sekaligus.

    Kalau sudah diposting, artinya sudah diakui dan dicatat ke dalam buku besar. Karena sudah diakui legalitasnya, journal yang sudah diposting jangan lagi diedit/hapus. Penghapusan atau editing tidak diijinkan untuk journal yang sudah diposting. Untuk mengurangi atau menambah biasanya dilakukan pembuatan journal baru atau revers. Rujukan dari revers journal ke nomor yang sama untuk pelanggan yang juga sama.

    Prinsip ini sebaiknya kita pegang erat-erat karena data historis dari keputusan yang dibuat dalam sistem harus dipertanggungjawabkan.
    Mudah-mudahan membantu

    Suka

  10. fredy said

    journal baru atau revers, itu kita buat so baru atau saya harus lewat general jurnal, rujukan itu di tempel dimana ? pak bisa bantu

    Suka

  11. agorsiloku said

    Wah.. susah agor menjawabnya. Reverse atau jurnal balik itu membalikkan journal dari debet ke kredit atau sebaliknya. Misalnya kalau dari Kas dikeluarkan untuk perbaikan mobil A 100 ribu dan ternyata salah karena seharusnya untuk mobil B (padahal journal sudah diposting), maka reverse nya adalah kembalikan ke kas uangnya sehingga pengeluaran untuk mobil A menjadi nol. Ini journal balik. Tapi bisa juga reclas (reclasification) atau memindahbukukan pengeluaran mobil A (dikreditkan lagi) dan didebetkan ke pengeluaran mobil B.
    Tentu saja rujukannya dari General Journal (segala pencatatan, bermuara di General Journal).
    Caranya, tentu saja journal yang akan direverse atau direklasifikasi dipanggil (menu retrieve journal). Coba cari menu ini di Ax. Kalau dikunci, tentu saja agar bisa dilihat harus di unblocking dulu.
    Oh ya, mas sudah pelajari journal periodik AX. Yang rutin masuk ke template journal periodik. Dengan begitu pembuatan journal baru bisa mengambil template dari journal periodiknya.
    Salam.

    Suka

  12. foead said

    Assalamu’alaikum wr wb.

    gini pak, kebetulan ni q ma temen2 dapet proyek buat implementasi axapta buat satu perusahaan di semarang. pada awalnya kami merasa siap dan sanggup. padahal kami belum penah melihat yang namanya axapta. la mungkin saya bisa diberi info tentang yang namanya axapta. mungkin manual book dan yang lainnya.

    saya saat ini sedang kuliah di STMIK ProVisi Semarang semester 6.

    terima kasih

    @
    Wass.ww.
    Pekerjaan yang menarik. Nanti saya akan kirimkan ke alamat beberapa manual book, namun tentu saja yang terbaik adalah mengecek langsung ke : http://www.microsoft.com/dynamics/AX/default.mspx.
    Saya punya banyak perbendaraan file pdf AX3, sebagian AX 4 dan kalau tak salah versi terakhir Axapta adalah Versi 2009.

    Hanya cukup mengagetkan juga, Mas menyanggupi untuk melakukan implementasi sambil belum pernah melihat yang namanya Axapta. Sama mengherankannya dengan perusahaan di Semarang yang mas katakan. Apakah membeli Software Axapta tanpa didukung implementor yang memiliki pengalaman yang cukup. Jago program jauh dari cukup, punya pengetahuan akuntansi yang memadai masih kurang tanpa pengalaman bisnis memadai. Kalaupun itu semua sudah tersedia, harus disusun dengan baik SOP dari perusahaan, lakukan pemetaan dengan sangat hati-hati dan menerjemahkan proses bisnis ke dalam Axapta.

    Memang, sangat tergantung skala bisnis dan target yang ingin diselesaikan. Namun, mohon maaf, bukan saya merendahkan Mas, namun dibutuhkan energi dan kerjasama yang serius untuk melaksanakan tantangan ini. Saya senang bisa membantu asalkan lebih jelas persoalannya dan jelas juga seberapa besar tantangan persoalan yang dihadapi. Oh ya, tentu saya juga bisa menyarankan untuk berhubungan dengan orang-orang yang lebih berkompeten di bidang ini atau jika Mas mau berhubungan langsung dengan Microsoft Indonesia. Merekalah yang mengeluarkan sertifikasi dari staf implementor untuk bidang ini.
    Wass, agor

    Suka

  13. bambang said

    mas agor…

    dengan membuka program axapta kemudian “mengutip” proses-proses dan tampilan yg dimiliki axapta lalu menerapkan ke aplikasi buatan kita sendiri seperti yg dilakukan tim IT mas agor apakah ini legal mas? bukankan itu semua sudah di “copyright” oleh microsoft ? bagaimana dari sisi hukum nya mas? karena kita jg ingin membuat aplikasi sendiri hanya masih bingung dengan legalitas ini..

    Wass.

    Suka

    • agorsiloku said

      Tentu saja tidak membajak program, tetapi mempelajari fungsi-fungsi dan proses bisnisnya. Tentu juga bukan hanya Axapta, dipelajari pula Zahir, Accurate, MyObI, Oracle, Axapta. Memahami logika-logika bisnisnya, logika menyusun matriks, logika menyusun asset management. Lalu kami menyusun kembali. Ada yang menjadi lebih baik, ada yang ditinggalkan — relatif terhadap kemampuan menyerap ilmu dan pengetahuan…..
      Siapapun yang bekerja dalam bidang pemograman dan penyusunan software, tentulah melakukan hal yang sama. Dari sini akan didapatkan upgrade dan mutu yang lebih disempurnakan….

      Suka

  14. monica said

    Maaf pak.

    Saya dan teman-teman saat ini juga sama seperti mas Foead, sedang mencoba mengimplementasikan axapta (dynamics ax 2012) di satu instansi di Bandung. Kami concern ke bagian human resource dan payrollnya.
    Dan kasus yang sama juga seperti mas Foead, awalnya kami merasa siap dan sanggup tapi setelah dijalani ternyata kami sangat kesulitan karena kami masih sangat-sangat pemula disitu.
    Boleh ga pak saya diberikan info juga seputar axapta seputar manual book atau sebagainya, terutama di modul human resource dan payrollnya. Karena saya lihat bapak juga sudah mengimplementasikan di modul itu.
    Saya sedang kuliah di Universitas Telkom Bandung dan sangat membutuhkannya sesegera mungkin.

    Terimakasih,

    monicapardede@gmail.com

    Suka

Tinggalkan komentar