Sains-Inreligion

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

Dua Tahun Ribet Bersama Implementasi ERP Axapta-2

Posted by agorsiloku pada November 25, 2007

Bertanya ke Tempat Yang Salah dan Salah Memahami Kebutuhan.Boleh jadi para insinyur implementor itu pintar, tapi kalau wawasan tidak cukup, maka akan terasa konyol juga. Ketika ureq (user requirements) sudah tersusun dengan — menurut saya sudah cukup baik — maka persoalannya tinggal menerapkan saja. Pikiran itu salah besar. Top eksekutif memiliki target mengapa mengambil ERP masuk ke dalam perusahaannya, lini manajemen tengah punya harapan dan visi ketika ureq disusun, dan user memikirkan dan menginginkan operasional perusahaan tetap sebagaimana biasa karena kerap juga sudah merasa nyaman dengan apa yang sudah terjadi saat ini (given). Konsultan yang asyik hanya dengan kebutuhan user dan rajin bertanya ke user tapi kurang atau tidak memperhatikan apa yang diharapkan oleh jajaran eksekutif akan terkendala ketika permintaan perubahan berorientasi kepada apa yang kini terjadi dengan apa yang akan dan seharusnya terjadi.

Fakta ini kemudian gagal dipahami pula dengan baik oleh tim implementor. Implementor begitu aktif bertanya pada kekinian (user) tapi arahan dari Stering Committe tentang apa yang diharapkan dan dibutuhkan tidak didefinisikan dengan benar. User Req mendefinisikan dengan detail juga apa yang diminta manajemen lini kedua. Tapi apa yang ditangkap dalam user req, kalau ditanyakan ke user langsung akan berbeda. User operasional perusahaan berada pada posisi praktis kekinian.

Nah… datang lagi bencana kedua. Setelah dua bulan lagi memperbaiki kondisi fatal sebelumnya, konsultan melupakan ureq yang disusun karena terlalu banyak bertanya kepada user saat ini yang hanya melihat pada kebutuhan praktis di lapangan. Terjadilah kesimpulan yang berbeda. Project Manager kamipun bingung karena hasil yang didapat dalam form-form tampilan dan inputan berbeda dengan “apa yang semestinya terjadi”, beberapa relasi database yang seharusnya diadakan (karena belum tersedia di sistem yang lama) malah tidak diadakan. Implementor lebih berorientasi pada kebutuhan saat ini dan bukan saat ini dan nanti….

Berbekal pengalaman pertama, saya bilang :

Aduh nduk… nduk… piye toh sampeyan ini. Sampeyan ini malah menggunduli Axapta pada level penyederhanaan dengan mengadaptasi sistem lama perusahaan. Kalau itu yang dilakukan, sama saja dengan kita beli mobil dengan seluruh asesoris lengkap dan modern, kemudian sampeyan preteli yang dianggap tidak dibutuhkan oleh sopirnya. Yang pakai mobil itu emang supir, tapi ya mobil itu adalah alat untuk mencapai tujuan. Bukan tujuan itu sendiri”.

Al hasil semua produk yang dihasilkan dalam 2-3 bulan kerja itu terpaksa dibatalkan. Konsultan implementor cari praktisnya untuk menjawab kebutuhan saat ini, tapi tidak mengoptimumkan kapasitas Axapta, tapi malah membawa sistem lama perusahaan. Jelas, kekeliruan ini menimbulkan pula kelambatan dan pengaruh terhadap biaya implementasi. Yang menyedihkan dalam kondisi ini, arah pemograman untuk kustomisasi terhadap siklus kerja dan SOP yang sudah disiapkan jauh-jauh hari malah dilupakan karena asyik masyuk dengan kondisi kekinian. Ini kebiasaan buruk, orang kita itu susah menulis dan enggan membaca. Lebih suka bertanya, padahal apa yang ditanya sudah jelas dan terinci ada pada user requirement. Pola olah data dan hasil diskusi bersama para manajer lini tengah seolah terhapus begitu saja.

Tanda-tanda badai sudah mulai tampak. Saya mengirim surat secara resmi ke implementor untuk melakukan perbaikan, menambah atau mengganti implementor yang tidak memenuhi kualifikasi dan melakukan pengarahan ulang terhadap apa yang kami mau. Bisnis adalah bisnis, implementor kemudian menambah, memperbaiki dan masuk kembali ke track yang seharusnya. Ada staf programmer dari implementor, yang meskipun cukup pendiam tapi cukup pandai dan bisa memahami apa yang diarahkan dari ureq. Kami melakukan pembahasan lagi tentang isi ureq. Pelajaran ini saya harapkan cukup disadari oleh implementor.

Namun, tidak boleh dilupakan. Bukan nama besar (citra perusahaan) yang membuat sebuah proses berjalan baik. Siapa orang yang melaksanakan dan kualifikasinya yang menentukan. Waktu berjalan terus, target satu tahun sudah dilewati beberapa bulan. Vendor punya order lain rupanya lalu menarik tenaga inti dari implementasi dan diganti yang lain. Pembagian tugas antara yang mengerti dan yang setengah mengerti menghasilkan proses implementasi yang melambat lagi. Beberapa persoalan teknis diselesaikan semakin lambat. Kemudian pula Project Manager dari tim implementor juga sering sakit. Ini manusiawi, tapi akibatnya proyek berjalan mulur.

Program Utama dan Pendukung

Ada beberapa program pendukung untuk bergabung ke ERP AXAPTA. Salah satunya adalah program Kas Kecil. Program ini hanya program kecil biasa saja. Program ini datanya akan diupload ke ERP Axapta secara offline saja. Pertimbangan ini dibuat karena perusahaan memiliki puluhan cabang yang tersebar di banyak kota. Meng-online-kan seluruh Axapta masih kami pertimbangkan serius. Apakah Citrix Access Gateway bisa dipakai atau tidak atau solusi sederhana saja. Pertimbangan bahwa biaya on line ke banyak kota masih terlalu mahal dan tidak sesuai dengan kebutuhan menyebabkan kami memilih upload rutin saja dari kas kecil yang didevelop implementor. Kalau ke cabang-cabang utama sih masih oke saja. Yang penting, tempat kejadian data diinput oleh user dan secara rutin datanya ditransfer ke Axapta. Kegiatan ini seminggu sekali saja dari kantor pembantu ke Pusat.

Program kedua adalah pengganti program sistem lama yang menyangkut Trade and Logistic. Ini masalah serius. Ada puluhan orang yang bekerja secara rutin di sini dan menyangkut segala aktivitas penjualan. Program lama memang tidak lengkap dan banyak kelemahan, terutama dalam isian data dan kelengkapan. Tapi sudah friendly user. Sehari saja tidak berfungsi, akibatnya bisa parah. Jadi, proses kustomisasi dari antar muka Axapta terhadap sistem lama harus ditangani hati-hati. Apalagi sistem lama tidak mengenal apa yang disebut sales order, tapi berorientasi langsung pada invoice. Ada polemik akuntansi di sini. Namun, kami lebih concern bahwa peralihan harus berjalan mulus mengingat resikonya terhadap aktivitas inti perusahaan.

Kembali salah arah terjadi, program kas kecil dalam prakteknya kemudian berkembang ke aspek-aspek lebih luas dalam kegiatan perusahaan yang menyangkut transaksi biaya. Bahkan kemudian menjadi pengganti Cost Control, salah satu program tak terintegrasi dari perusahaan untuk mengendalikan biaya (budgeting). Akibatnya, terjadi loncatan tahapan rencana implementasi, sampai-sampai implementor sendiri menyatakan : dengan sedikit perombakan lagi, program yang kami disain akan menjadi kasbank dan kas kecil sekaligus budgeting. Lucunya, karena konsentrasi kas kecil ditinggalkan, maka sistem pencatatan tidak lagi dimulai dari opening balance. Saldo awal tertinggal. Saya kembali terkecoh dengan perkembangan ini. Kemudian, kami terpaksa lagi evaluasi. Rupanya perkembangan arah program terjadi lagi ketika implementor lebih mendengar user ketimbang disain perencanaan yang telah ditetapkan. Yang lebih mengesalkan lagi, komunikasi antar data yang seharusnya bisa sentralisasi, malah menjadi desentralisasi. Terpecah-pecah di sana sini. Akibatnya konsolidasi data menjadi lebih sulit dan rumit. Singkat kata program ini kami nilai salah arah lagi. Namun, implementasi sudah berjalan ketika stering committe mempertanyakan dan mengevaluasi, kondisi keterlanjuran sudah terjadi.

Saya membuat surat sekali lagi ke tim implementor dengan pertimbangan untuk memutuskan hubungan. Kerja tidak profesional begini menghabiskan terlalu banyak energi. Namun, sebagaimana pedagang. Pintar merayu. Kami bersepakat lagi untuk memperbaiki situasi. Namun berbeda dengan sebelumnya, saat itu kami mulai sangat serius membuat backup proses. Artinya disain dari sistem lama terus kami develop dan sempurnakan dengan kemungkinan menjadi antarmuka bagi ERP AXAPTA.

Sampai setahun kemudianpun kustomisasi dari Trade Logistik Axapta belum berhasil dimodifikasi oleh Tim Implementor. Kelemahan dari sistem lama yang telah kami kenali dengan baik kelemahan dan keunggulannya kami revisi. Dua bulan kemudian kami sosialisasikan sistem trade dan logistic baru yang didevelop oleh Tim IT dengan merujuk kemungkinan sistem beradaptasi dengan Axapta. Hanya belum disambungkan dengan Axapta karena pada saat itu memang kualifikasi biaya (nomor account) juga belum selesai direvisi. Pekerjaan develop yang baru ini dikerjakan tanpa menganggu tim implementor. Tapi jelas kekuatan dalam tim Axapta dari internal berkurang.
Selesai ini, kami ambil keputusan pahit. Kas kecil produk implementer kami nilai tidak layak pakai dan kami putuskan untuk develop sendiri. Kami sudah jengkel dengan kemampuan minimum yang ditunjukkan oleh implementor. Sekali lagi, kami dapatkan pelajaran berharga. Bukan nama besar yang menjanjikan keunggulan implementor, tapi wawasan dan keterampilan yang mendukung. Boleh jadi dahulunya mereka punya kekuatan yang cukup baik. Namun berganti-gantinya sumber daya menyebabkan kekuatan implementor juga tidak memadai.

Perusahaan konsultan IT ini lebih layak disebut pedagang saja. Mereka berdagang dengan baik. Jual putus adalah proses paling menguntungkan. Ini tidak bisa dilakukan dalam implementasi ERP yang lebih merupakan otomatisasi budaya perusahaan ke sistem terintegrasi berbasiskan teknologi. Tampaknya manajemen mereka dan juga manajemen internal perusahaan harus menyadari benar hal ini. Implementor juga tidak bisa selalu memenuhi keinginan dari user tanpa konsep manajemen yang jelas dan terarah. Hal terakhir ini kami rasakan sebagai batu sandungan ketika implementor selalu berusaha memenuhi kebutuhan user meskipun keluar dari rel yang seharusnya.

Namun, sedikit berbeda dengan sebelumnya dimana kami memberikan lebih banyak kepercayaan pada implementor. Sejak keputusan untuk membuat ban serep dan menjadikan kemungkinan ERP AXAPTA sebagai back bone saja maka ada beberapa hal yang mungkin kami optimumkan. Yang pertama, biaya penambahan user terhadap ERP bisa diminimumkan dan kedua target perbaikan prosedur sesuai SOP tidak lagi digantungkan sepenuhnya pada tim implementor. Kerugiannya, konsentrasi pekerjaan terpecah. Boleh jadi mem-PHK-kan implementor saat itu lebih baik dari pada mempertahankan. Namun, pertimbangan memulai segalanya dari awal lagi juga akan merusak citra tim IT keseluruhan.

Kelemahan lain adalah, ERP AXAPTA menjadi tidak bisa dijalankan dengan penuh. Padahal dalam setting rencana awal. ERP AXAPTA dirancang untuk operasional di Kantor Pusat dan salah satu cabang. Kemudian tahap kedua seluruhnya jika implementasi ditahap pertama berhasil. Ternyata di tahap pertama saja berbagai persoalan yang muncul menyebabkan kami melakukan pilihan-pilihan yang terpaksa berbeda.

Meskipun program lama kami develop, tapi kami tetap siap dengan kemungkinan untuk implementasi keseluruhan dengan Sistem Axapta. Jadi, program lama yang disempurnakan lebih sebagai jaga-jaga sampai titik implementasi yang mengalami kemunduran bisa diatasi. Dari segi biaya ini tidak bermasalah, namun dari sudut moral dan kepercayaan pada sistem, mengalami degradasi cukup parah.

(bersambung)

Iklan

8 Tanggapan to “Dua Tahun Ribet Bersama Implementasi ERP Axapta-2”

  1. […] Terbaru Dua Tahun Ribet Bers… on Dua Tahun Ribet Bersama Implem…Chika on Nobel Fisika 2005 Untuk Bidang…NuDe on […]

    Suka

  2. Syafriadi said

    hehehe…
    dimana2 ternyata begitu ya 😀

    @
    Dalam kasus kami nih, kemampuan implementor yang betul-betul jadi masalah…. 😦

    Suka

  3. kurtubi said

    Ini tentang program keuangan tah pak, duuh maaf gak ngerti… jadi tidak dibaca semuanya…

    @
    Hampir sih Mas Kurt… , ERP (Enterprise Resources Planning) lebih dari integrasi sistem dengan banyak aspek berbasiskan teknologi komputasi terhadap banyak aspek dalam industri hilir. Kalau di hulu atau pabrikan memakai MRP (Material R.P.)…

    Suka

  4. Dedy Darmawan said

    Boleh jadi para insinyur implementor itu pintar

    ==>
    Ya…ya…
    Mungkin ini salah satu kesalahan yang suka terjadi di implementor.
    Dengan “bungkus” sebagai produk IT, direktrutlah para engineer sebagai implementor.
    Satu hal yang tidak boleh terlupakan adalah aplikasi ERP sangat luas cakupannya. Akan celakalah jika seorang implementor hanya pintar di bidang IT. Terutama jika dia berperan tidak di Programming tetapi di Functional.

    @
    Betul sekali Mas Dedi, implementor menganggap ERP menyediakan segalanya tapi juga tidak didalami dengan memadai ketika harus dikawinkan dengan problematika ril yang dihadapi perusahaan. Seharusnya memang, implementor tidak sekedar mengenal manajemen resiko dan proses bisnis dalam kulitnya saja. Akan lebih tepat, juga seorang fungsional/praktisi yang memiliki pengalaman luas juga dalam logika-logika komputasi dan terutama :Organisasi Data. Kesalahan dalam memahami dan menerapkan logika organisasi data menyebabkan kustomisasi dan pemograman berulang-ulang mengalami bongkar pasang, karena kebutuhan “yang tidak diperkirakan” kemudian muncul. Ambil misal penilaian salesman terhadap hasil penjualan. Bagaimana menilai prestasi salesman yang dalam satu tahun mengalami 5 kali mutasi dan berpindah area organisasi?. Bagaimana menilai supervisornya dan penjualan per unit-unit pelanggan. Ketika organisasi di evaluasi, tidak mampu mengukur dengan dengan baik dari data yang ada, karena data dibentuk dengan struktur statis. Untuk mengubahnya, jika pemograman sudah terbuat dalam struktur yang kaku, maka program tidak mampu menangkap perubahan. Akibat lanjutnya, program hanya dapat memenuhi sebagian kebutuhan saja. Ini jadi masalah berikutnya. Hal yang sama ketika kita harus mengevaluasi dari master data lainnya.

    Suka

  5. Fred said

    Nimbrung dikit pak.
    Mungkin kesalahan terjadi di awal pada saat mendefinisikan functional requirements. Kadang-kadang implementor terlalu memaksakan untuk menerima suatu requirement (otherwise they can loose a client), padahal requirement itu terlalu sulit untuk dipenuhi dengan paket ERP tersebut. Atau ada gap yang terlalu besar antara kemampuan paket ERP dengan yang diinginkan client.
    Jadi bagaimana kelanjutannya pak?

    @
    Ada benarnya yang Mas Fred sampaikan. Namun, yang krusial justru ketika programmer dari tim implementor tidak terlalu menguasai Axapta, terlalu banyak bertanya pada user legacy yang ada dan kurang mendalami user requirement yang sebenarnya sudah tersusun cukup rapih dan mendalam. Kegagalam implementor untuk memahami proses bisnis yang kami miliki dan mengadaptasinya dengan kapasitas ERP adalah salah satu persoalannya yang membuat pekerjaan yang seharusnya ringkas menjadi bertele-tele.

    Yang kedua, “Dimension” yang dimiliki Microsoft Axapta (Versi 3.0) tidak memadai untuk mengatasi kerumitan dari sistem Trade n Logistic perusahaan. Pada versi 4.0 yang baru dirilis, barulah Microsoft Axapta melakukan perbaikan mutu dari dimensionnya yang terlalu simpel itu.

    Namun, karena kedatangan release 4.0 ini saat kami telah berjalan hampir 90% dari proses kustomisasi, maka kami belum berani pindah ke Axapta Versi 4.0 karena pertimbangan waktu dan disain yang ada. Pada beberapa sisi, versi 4.0 juga masih belum pas dengan yang kami harapkan, meskipun solusi “dimension”-nya telah mencapai 90% lebih kebutuhan kami.

    Oleh karena kami juga membuat sistem Trade Logistik dan Kasbank untuk upload ke Axapta (karena lisensi Axapta berdasarkan satu server), sedang cabang kami banyak, maka untuk kegiatan kas kecil kami buat sendiri untuk bergabung ke Axapta.

    Nah, saat pembuatan kaskecil untuk masuk ke Axapta, kami belajar lebih giat di kedalaman tabel-tabel Axapta dan relasi-relasi serta extended field-nya. Kemudian saat kami membuat program, logika-logika axapta coba kami adaptasi. Bahkan kemudian ini menjadi tantangan yang menarik untuk dielaborasi lebih maksimal. Tak terasa, program kaskecil yang kami buat terasa lebih fleksibel dari Axapta dan lebih mudah dikendalikan fungsi-fungsinya. Kami tambahkan fitur-fitur baru yang tidak tersedia di Axapta : Misalnya perluasan pemanfaatan dimension menjadi unlimited. Dengan begitu, kami bisa menangkap pergerakan/perubahan organisasi dalam periode waktu dan penjualan, pencatatan detil biaya bisa dirumuskan lebih detil dan lengkap, pembuatan dokumen handling (pengarsipan digital) dan data imaging ke dalam tabel database, struktur procurement, struktur asset, struktur customer group dan detail group, vendor group dan vendor detail, built of material kami susun lebih lengkap lagi dari yang disediakan oleh Axapta, penyusunan proposal pengajuan biaya, sales order, otorisasi, sampai ke grouping account, grouping user, zona, geographical dimension, budget dan realisasi, line discont, multiple discount yang lebih friendly user dan lengkap sampai optimasi dari Cash Discount yang pemanfaatan di modul Axapta terbatas. Measurement line dan grouppun kami siapkan untuk persiapan mengikuti perubahan satuan dan informasi yang dibentuk. Other accountpun kami siapkan, termasuk connector yang menghubungkan customer, vendor, employee, product, docoment, konsolidasi bank, dan satuan ukuran (satuan fisika dan currency) Semua itu kami disain fleksibel, sehingga mudah bagi kami untuk melakukan penyesuaian terhadap perubahan organisasi, perubahan sistematika product atau penambahan klasifikasi product, penambahan klasifikasi customers, klasifikasi pengiriman, klasifikasi biaya (terarah mana yang biaya, kas, dan aktiva) dan kustomisasi form dan inputan.
    Kami sendiri tidak menduga perkembangan kas kecil menjadi semakin lebar, sehingga kami ganti namanya menjadi KasBank, kemudian kami ganti lagi menjadi Kas and Central Data Bank. Akhirnya, perkembangan program yang kami develop sendiri itu menyebabkan 50 user yang kami lisensikan pun menjadi terlalu besar, karena banyak fungsi digantikan. Padahal jelas, rencana awal dari Axapta akan dipakai kurang lebih sampai 300 user. Sekarang, dengan perkembangan program pendukung maka kebutuhan itu bisa diminimalkan. Cukup menghemat, apalagi ada tambahan fitur yang tidak dimiliki oleh Axapta.

    Kami sendiri, mulai berpikir ulang, setelah kami bandingkan dengan beberapa program aplikasi Indonesia yang telah ada seperti Accurate atau Myobi, struktur data yang kami bangun lebih lengkap dan handal. Demikian juga dengan sistem reportingnya yang kami disain berlevel-level sehingga kami bisa menangkap informasi biaya terkecil dari sebuah bukti pengeluaran dalam berbagai varian organisasi, melakukan pengelolaan naskah/arsip/dokumen dan foto, perjanjian, dan tentu saja account sesuai dengan nomor rekening akuntansi. Yang belum sempat kami sentuh, yang berhubungan dengan hulu industri, yang menyangkut route product dan perencanaan, serta ke hilir yang menyangkut CRM (Customer Relationship Marketing/Managementnya).

    Pekerjaan memang masih belum selesai, masih banyak lagi tantangan yang harus kami disain. Namun, rasanya kami sudah masuk pada track yang benar dan punya kemungkinan untuk berintegrasi sempurna dengan Axapta atau mengembangkan modul-modul lainnya dalam ERP dalam konteks yang lebih rumit (seperti warehouse manajemen dengan sistem berjalan, conveyor, barcode system, retail, sampai ke kompilasi material yang lebih terukur untuk menjadi produk).

    Yang juga belum adalah tuning tabel data, kalau kami perkirakan akan mengolah data sampai misal 10-50 juta record atau lebih. Kalau ratusan ribu sih sudah oke.

    Suka

  6. Tukang Ketik said

    Pak, nanya dong, di japri aja. Implementornya siapa sih? Biar ga masuk kelobang yang sama nih. Kebetulan kantor saya ada rencana pakai Axapta.

    Thanks

    adiwirasta[at]lycos[dot]com

    @
    Dari pengalaman banyak implementor, setahu saya nama terkenal atau tidak dari implementornya sama sekali tidak menjamin sukses. Faktor sdmnya yang paling menentukan. Karena itu, kita betul-betul harus mencermati sdm yang ditawarkan menjadi implementor. Di samping tentunya teliti juga kapasitas dan kemampuan (adaptable) dari Ax.

    Suka

  7. lutfi said

    Apakah tidak menggunakan metodologi pak? harusnya pake ya tapi painnya dimana yah dari metodologi yang telah disusun?

    Suka

    • agorsiloku said

      Metodelogi?, maksudnya ! Tentu saja ada proses, ada analisis, ada cara bagaimana dan upaya agar sistem yang dibeli (Axapta) dapat diimplementasikan dengan baik. Kalau yang dimaksud proses bisnis, tentu saja ada, karena Axapta menyediakan sejumlah cara dan fasilitas bagaimana proses bisnis harus dilakukan dengan benar, pencatatan yang benar, dan mengorganisasikan transaksi pada sistem secara benar. Faktanya, ini justru yang kalang kabut. 😀

      Suka

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

 
%d blogger menyukai ini: