Hal yang Perlu di Sampaikan dalam ERP
Bekerja sebagai stering commite dan proses kegagalan implementasi yang terjadi selama ini dalam implementasi ERP, saya kembali membaca kembali “User Requirements”. Sebuah analisis kebutuhan yang disusun oleh Konsultan dengan tim dari perusahaan. Di situ dijelaskan masalah yang dihadapi dalam sistem perusahan (legacy, yang sedang berjalan) – sistem yang dipakai dan solusi implementasi dalam sistem yang baru yang akan diimplementasikan. Sedangkan disain proses bisnis sebenarnya telah tersusun rapih oleh konsultan internasional. Jadi sebenarnya perusahaan tinggal “bertanggung jawab” memakainya saja.
Tapi kok gagal ya?.
Saya sebenarnya “iri” pada perusahaan yang berhasil melakukan implementasi dengan baik dan mampu fokus pada persoalan yang dihadapi serta mengintegrasikan dengan baik. Seperti yang dijelaskan rekan dari PT AAM (klik) di sini.
Kalau mengurut kembali kebelakang, kegagalan sebenarnya terjadi sejak awal dan harusnya sudah bisa dideteksi, yaitu kegagalan dalam melakukan “business process reengineering “. Implementasi dengan standar proses bisnis sekelas ERP harus konsisten untuk melakukan perubahan di dalam internal proses. Apalagi jika sebelumnya perusahaan sangat awam dan tradisional….
Hal ini yang saya kurang sadari sehingga ketika diskusi di awal dan tanda tangan “User Requirements”, saya oke-oke saja dengan segala janji dan kebecusan implementor.
User Requirements.
Menyusun kebutuhan pemakai untuk implementasi sistem sudah dilakukan dengan benar. Konsultan mempelajari sistem yang sedang berjalan, hambatan dan apa-apa yang kemudian secara detail disusun dan dievaluasi. Setelah dievaluasi dibandingkan dengan model ERP yang tersedia dan diplot serta dikastemisasi sesuai dengan kebutuhan perusahaan. Beberapa model dalam perusahaan yang sudah berjalan harus dapat diefektifkan dan bypass sehingga penerapan bisa berjalan baik.
Cukupkah?.
Dalam kasus kami, implementasi memaksa/mengharuskan migrasi data terdahulu (3 tahun terakhir) ke dalam sistem yang baru. Ini rupanya menjadi “penyakit” yang kurang disadari oleh Konsultan dan kami saat implementasi dilaksanakan. ERP akan lebih afdol dan mudah diterapkan jika memulai dengan sistem yang baru dan secara bertahap meninggalkan legacy sistem. Membawa data lama, cukuplah sampai level ledger dan saldo awal saja. Membawa data lama menimbulkan persoalan yang ternyata tidak mudah dipecahkan.
Hal kedua, konsultan implementasi juga bukan hanya berfokus bagaimana meyakinkan pelanggan untuk membeli produknya tanpa kesiapan memadai bagaimana ERP bekerja. Tahu cara menggunakan software, tapi gagal menangkap esensi dari proses bisnis akan membuat sistem bekerja tidak optimal. Contoh kongkritnya seperti menyusun potongan gambar.
Kalau sebuah perusahaan memiliki modul-modul proses kerja, katakanlah sebanyak 100 cara bekerja dalam berbagai bagian, lalu ERP memiliki proses dan pengembangan sebanyak 200 cara, kemudian dari 100 cara perusahaan yang sesuai dengan 200 cara yang disediakan oleh ERP itu ternyata hanya 75 saja, maka pertanyaannya yang 25 cara perusahaan yang tidak tersedia di ERP itu bagaimana akan diterapkan?, kastemisasikah?.
Hati-hati?. Sangat boleh jadi memang kastemisasi dibutuhkan (terutama dalam form untuk end user), tapi secara keseluruhan sangat boleh jadi, 25 cara yang tidak bisa diimplementasikan ke dalam sistem bersumber dari :
- Kesalahan sistem legacy (kesalahan model dan sistematika), belum tertangkapnya esensi persoalan dari sistem lama yang akan menemui jalan buntu dan sebenarnya sudah diberikan solusinya oleh ERP. ERP menyediakan solusi dan tahapan kerjanya. Namun proses ini tidak tertangkap oleh sistem lama maupun oleh manajer dan user.
- Sistem yang sedang berjalan (legacy), memotong sebagian proses dan ERP meminta tahapan sebelumnya harus disediakan. Di sini data lama tidak tersedia, sedangkan sistem menuntut. Jelas di sini harus ada usaha yang baik untuk membangun data untuk memenuhi sistem.
- Sistem yang lama adalah sistem yang korup dan lemah, perbaikan ke sistem baru akan menuntut terbentuknya standar baru yang sebenarnya sudah tersedia di ERP. Misalnya, sistem lama tidak bisa mengakomodasi perlindungan data keuangan yang bersifat rahasia yang pemiliknya hanya ingin diketahui oleh segelintir orang kunci perusahaan saja (biasanya pemilik) bersama dengan Ka. Keuangannya saja. Karyawan lain tidak boleh tahu. Dan ini ada di luar sistem, tapi masuk dalam kalkulasi perusahaan. Persoalan seperti ini tidak muncul dalam user requirements dan tidak muncul dalam pembahasan manapun. Padahal jelas perusahaan membutuhkan bahwa gaji BOD (Board of Director) atau sogokan ke penjabat yang korup oleh perusahaan serakah tidak usahlah datanya dibaca oleh seorang penata buku. Padahal, “kebutuhan” ini jelas ada, tapi tidak akan diucapkan. Akibatnya dualisme sistem terjadi. Padahal, sistem menyediakan bukan hanya password per user, tapi juga private user, blocking yang akan memproteksi secara khusus jurnal-jurnal akuntansi yang sifatnya rahasia dan dibatasi. Bahkan admin IT juga tidak akan bisa menembusnya. Singkat kata, Konsultan atau implementor dari dalam dan luar, harus memahami bahwa satu kebutuhan akan menimbulkan kebutuhan yang lain yang sebenarnya telah dipikirkan secara matang dari ribuan pengalaman industri sampai terbentuknya disain sistem ERP.
- Dari contoh tadi, ada 25 cara yang “tidak tersedia” dalam ERP. Setelah kian memahami sistem, ternyata yang benar-benar bersisa tinggal satu atau dua, atau bahkan tidak sama sekali jika saja kita memiliki cukup pengetahuan akuntansi dan proses bisnis secara mendalam. Jadi, ada solusi-solusi yang disiapkan, hanya saja kita tidak punya cukup pengetahuan memakainya sehingga kesulitan melakukan adaptasi ke dalam sistem erp. Seharusnya memang Konsultan membantu untuk menyelesaikan kasus-kasus seperti ini. Jika yang dilakukan hanya sekedar mengajarkan bagaimana menggunakan sistem dan beradaptasi dengan user requirements kini, maka peluang kebuntuan akan terjadi.
Kesalahan Model dan Sistematika dari Legacy System.
Saya ingin menggarisbawahi sebagai hal yang perlu diperhatikan seksama oleh tim internal perusahaan dan kerap juga dibahas dalam pembahasan mengenai sistem ERP dibandingkan dengan sistem yang telah didevelop sendiri oleh Tim IT.
Ambilah contoh sederhana. Perusahaan membeli barang. Barang itu untuk dijual dan barang untuk dipakai sendiri atau barang yang dibeli kemudian menjadi asset perusahaan dan dipakai untuk kegiatan operasional. Esensinya sama : Item product. Yang membedakan perlakuannya. Sistem lama hanya mengasumsikan barang untuk dijual saja sebagai item produk, sedangkan barang yang dipakai sebagai asset tidak dan hanya dicatat sebagai asset saja. Ketika asset tersebut dijual, catat saja sebagai penjualan lain-lain dan coret dari daftar asset. Dalam integrasi ERP, ketika masalah sederhana itu telah menjadi ribuan kejadian, maka memanajemeni data item asset for sale, for buy or for sale and for buy, haruslah dicatatkan dengan cara tertentu. Sistem ini, yang pada pengalaman saya memperhatikan pekerjaan implementasi tidak dijalankan dengan benar. Akibatnya, yang disebut integrasi penuh dan berhasil, sebenarnya hanya sepotong-sepotong saja dan cukup puas bahwa ada bagian-bagian proses yang menjadi lebih efektif.
Potongan-potongan ini haruslah disadari oleh manajemen lini tengah, bahwa tahapan-tahapan proses dari potongan puzzle gambar tersebut harus dilengkapi (tentu bertahap) agar sampai satu titik tertentu, ERP bisa menunjukkan kemampuan yang sebenarnya : Mengintegrasikan sistem. Kemudian menjawab pertanyaan yang yang keunikan data dan pengolahannya sebenarnya tersedia manis di ERP. Sebaliknya, kalau hal seperti ini diabaikan, maka yang disebut efesien adalah kesimpulan dan kepuasan hanya pada bagian-bagian proses otomatisasi saja yang sebenarnya bisa saja itu dilakukan oleh sistem yang lebih sederhana, yang sebenarnya juga disediakan oleh banyak software buatan dalam dan luar negeri.
Sumber: https://agorsiloku.wordpress.com/2008/10/29/implementasi-erp-puzzle-user-requirements/
Tidak ada komentar:
Posting Komentar