Microsoft Dynamic Axapta Yang Digunduli….

Dalam catatan saya bulan Nopember 2007 tentang peran Konsultan yang mendukung implementasi Axapta :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.

Catatan ini merupakan ungkapan kekesalan karena implementasi tidak bisa berjalan mulus dan sibuk dengan upaya upload yang juga tidak bisa kunjung selesai. Selalu saja muncul alasan dan sebab akibat yang secara teknis ada, tapi secara nyata pula tidak bisa diatasi. Ada harapan agar catatan ini dipahami, tapi rupanya bertepuk sebelah tangan.

April tanggal 2 2008, Business Lead Axapta yang telah 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 beberapa rekan untuk membicarakan, kira-kira apa masalahnya dan apa yang bisa dibantu. Tentunya sejuta terimakasih atas perhatian Beliau. Sayang memang kemudian, beliau lebih terlibat tidak secara teknis persoalan dan menawarkan tenaga yang diperkirakan bisa membantu. Namun, tampaknya belum “berjodoh” karena tenaga yang diharapkan waktunya untuk hadir di Indonesia juga sangat sempit, sedang yang lain masih dalam negosiasi…. 😦 .

Ada guyonan kecil dari rekan kita ini, kurang lebih Beliau bertanya atau mungkin mendapat kesan dari yang lain bahwa perusahaan berusaha membawa axapta ke dalam sistem bisnisnya. Ini yang sebenarnya saya tolak mentah-mentah dalam tulisan kedua saya yang saya kutip kembali di atas. Namun, sekali persepsi itu masuk dalam alam pikiran, kadang begitu teramat sulitnya manusia melihat ada sisi lain. Kami justru sebaliknya, ingin bagaimana sebuah bisnis standar ERP bisa masuk dalam sistem bisnis standar yang sebagian telah kami miliki dan jalankan.

Sebulan sebelumnya, pimpinan kami memutuskan untuk “meringankan” masalah ganjelan migrasi data yang tidak selesai-selesai dari tiga tahun, menjadi hanya 1 tahun saja. Itupun data tahun terakhir yang harus masuk ke Axapta. Itupun harus segera disusul dengan data tahun berjalan. Hal ini dipilih karena informasi yang diperoleh, migrasi yang sudah sukses sebelumnya (masuk ke dalam axapta), terpaksa dibatalkan total alias harus dihapus, karena setelah naik ke dalam sistem ketahuan bahwa ada parameter setting yang salah sehingga ketika laporan diproses oleh aplikasi Axapta, perhitungan menjadi dilakukan dua kali. Al hasil, laporan jadi amburadul sehingga dengan terpaksa database dikosongkan lagi… 😦 😦

Setelah satu bulan lewat satu minggu akan diproses lagi dan semua validasi dipersiapkan. Saya kembali menggerutu lagi, kok belum juga final-final validasinya. Padahal waktu yang kami minta satu bulan sudah mulai dilewati. Akhirnya, komandan memutuskan untuk hanya masuk ke level ledger saja. Artinya resumenya selama satu tahun saja. Kami juga sudah betul-betul frustasi dengan kondisi ini. Mungkin ada Pak Andreas yang bisa memberikan dukungan lebih cepat dan mantap, tapi memang kondisi belum memungkinkan. Kepada Implementor, kami memberikan waktu seminggu untuk menaikkan data ke ledger yang nomor accountnya sudah jelas. Pikiran kami sederhana saja, kalau cuma untuk memasukkan data jumlah bulanan dari beberapa cabang ke ledger rasanya cukup sehari saja menghitungnya, lalu data bisa masuk ke Axapta. Jadi waktu seminggu sudah lebih dari cukup. Namun, kami maklum karena beberapa hari kemudian, data utuh yang semestinya diberikan ke konsultan/implementor, masih ada yang ditinggalkan (karena relasi datanya belum tersedia), padahal dengan keputusan hanya masuk total hitungan ke ledger saja, urusan relasi bisa diabaikan. Data diberikan di hari ke lima. Jadi putuslah harapan untuk upload ke ledger dalam seminggu bisa diselesaikan. Minggu ke dua, Konsultan kembali memberikan data yang sudah siap upload, nggak banyak sih….. paling banter hanya 720 an baris record data saja. Namun, terpaksa pula “senyum” dikulum kembali karena data yang tersaji masih ada bilangan negatif pada data debet dan kredit. Walah… staf saya mengkritisi hal ini. Saya jadi kehabisan kata juga, luar biasa rupanya. Kembali saya ingat protes yang disampaikan ke tim implementor : “Anda harus punya tenaga Quality Control yang punya kemampuan yang baik dan mengerti bisnis dan tentu saja mengerti akutansi. Seorang akuntan tidak akan membiarkan data debet atau kredit dengan angka minus 🙂 Kalau itu tidak diperiksa namanya bukan akuntan, tapi pendengar. Kalau masih bertanya, data ini mana field kuncinya maka bukan programmer, mungkin tukang baso. Salah itu manusiawi, tapi kalau pura-pura tidak tahu apa itu GIGO, yo wis… nggak usah cerita lagi. Bukan hanya mengerti Axapta, tapi nggak ngerti memecahkan persoalan bisnis ke dalam Axapta. Hanya bisa angguk-angguk atau omdo”. Jadilah proses upload tidak jadi dilakukan sampai ke minggu ke dua berakhir….. Sungguh tragis pengalaman ini.

Saya jadi ingat kembali catatan Rekan Wahyu yang di perusahaan beliau, memang akhirnya memutuskan untuk implementasi saja sendiri. Tampaknya, kami semakin yakin bahwa pilihan ini adalah pilihan yang benar.

Kas Kecil/Kas Bank Pendukung Axapta dan Migrasi data ke Axapta.

Ke Pak Andreas, Bisnis Lead Microsoft kami tunjukkan hasil pekerjaan kami untuk menggantikan kas kecil yang dibuat oleh Konsultan yang kami nilai sangat tidak memenuhi syarat. Kas Kecil yang dibuat dan memang kami kembangkan lebih dari sekedar kas kecil dapat mencatat seluruh transaksi perusahaan secara cukup lengkap. Memang untuk kantor-kantor kami yang jauh dan kecil-kecil, kami tidak mungkin memakai program semahal Axapta, jadi untuk yang kecil-kecil akan kami gunakan program kecil ini yang kami namai myCdB yang bekerja offline atau online. Dalam tampilan, sengaja kami sedikit meniru Ax, juga dalam struktur prosesnya meski tidak selengkap Axapta. Namun, model-model standar yang ada di Ax kami adaptasi agar mudah masuk ke dalam Axapta.

Melalui program kecil ini, kami coba upload data lama ke dalam sistem kecil kami. Memang banyak hal harus dibenahi. Misalnya pengelompokkan data (Group Id dan Dimension Id dan puluhan field lainnya) harus dirapihkan dan disesuaikan untuk kemudahan report dan pengendalian tabel database. Data Warehouse yang tidak ada kami harus adakan. Hubungan vendor dan customer harus didefinisikan ulang, account num dengan headernya harus diurut ulang, parameter setting dan posting profile harus didefinisikan kembali. Data lama yang sudah kami berikan ke tim implementor untuk diupload ke AX tidak bisa begitu saja masuk ke program kecil kami begitu saja tanpa pembenahan relasi dan dokumentasi yang perlu. Apalagi dalam program yang kami buat itu dilengkapi pula dengan pengendalian dokumen terstruktur yang bisa terhubungkan dengan peta wilayah dan komponen penting transaksi : Vendor, Asset, Employee, Bill Of Material, Product (Item) dan configurationnya, Warehouse, Picking Route, Measurement (unit/satuan) dengan konvesinya dan tentu saja satu dengan lainnya memiliki hubungan yang memudahkan kontrol ketika akan digroup masuk ke accountnya. Dan tentu saja dimensinya dari setiap komponen transaksi. Untuk mengisi field data customer saja dibutuhkan lebih dari 60 field yang harus terisi lengkap. Belum lagi relasi-relasi yang dikunci mati dalam database sql yang dibuat ketat harus memastikan bahwa semua komponen memiliki hubungan yang mengunci satu dengan lainnya.

Ketika saya mulai melakukan upload ke dalam sistem yang dibuat rekan, baru kemudian menyadari bahwa apa yang terjadi dalam upload Ax mestilah kurang lebih begitu masalahnya. Kalau saya saja harus melengkapi master-master sebanyak itu, belum lagi untuk komponen lainnya, maka tidak mungkinlah data yang akan diupload ke AX itu bisa masuk dengan mulus. Kalau parameter settingnya atau bypass dilakukan, sudah tentulah Upload tidak akan punya makna apa-apa. Jelas, saya sangat bodoh selama ini. Terlalu bodoh malah. Seharusnya saya menyadari bahwa untuk masuk dalam sistem Axapta, maka semua klasifikasi didefinisikan dengan baik dan benar, bukan hanya number sequencenya saja harus tepat atau primary keynya tereleasi dan mengisi tabel-tabel turutannya.

Lha kalau begitu, bagaimana dengan upload program sendiri saja butuh dibenahi, bagaimana dengan upload ke Axapta?, apa implementor mengerti data apa yang harus dilengkapi?. Masak transaksi hanya cukup dengan kode pelanggan, kode invoice, kode produk, kuantum dan rupiah saja. Bukankah banyak data pendukung harus masuk secara baik dan benar !. Belum lagi pemanfaatan line discount atau apa-apa saja yang seharusnya bisa masuk dengan baik ke AX.

Kami semakin yakin, memang implementor tidak mengenal Axapta. Kalaupun mengenal, hanya tahu cara memakainya, tapi bodoh dalam memahami isinya. Seperti supir yang canggih, tapi tidak mengerti mesinnya. Tidak mengerti konsekuensi data dan hubungan yang diperlukan antara satu data dengan data lainnya. Kerena itupula mereka gampang saja membuang ketersediaan fasilitas Axapta. Yang terjadi adalah “gadis manis berkepala gundul“. Ini rupanya yang sedang dikerjakan oleh tim implementor. Karena gundul itu pulalah, maka kejadian salah parameter terjadi sehingga data upload di-reject.

Semestinya tim implementor mengajarkan hal ini kepada kami 3 tahun sebelumnya dan bukan berkutat menggunduli Axapta yang akhirnya kami harus belajar habis-habisan menumbuhkan rambutnya kembali….

Namun, selalu ada hikmahnya. Saya bersyukur sekarang bisa mengenali sebuah proses bisnis standar dengan lebih baik. Akhirnya, kami memang telah merugikan perusahaan, sawah kami dengan pekerjaan yang tidak selesai-selesai ini. Kami juga sudah rekrut staf dari perusahaan lain yang telah mengimplementasikan AX. Kami pikir, kita akan manut saja sama implementor internal dalam praktis bisnis. Ini lebih baik dari pada keputusan kami sebelumnya…..