Sains-Inreligion

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

Implementasi ERP : Puzzle User Requirements

Posted by agorsiloku pada Oktober 29, 2008

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 :

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Iklan

Satu Tanggapan to “Implementasi ERP : Puzzle User Requirements”

  1. Pawit said

    Sebelum implementasi ERP dilakukan pasti sudah ada tahap dalam penentuan vendor yang akan mengimplemetasikan ERP. Dalam pemilihan vendor ERP ada 2 hal utama yang harus diperhatikan yaitu :
    1. Pendekatan Product —> dalam hal pemilihan vendor perusahaan lebih cenderung melihat pada product yang ditawarkan, dimana jika ini dilakukan maka yang dibeli sebenarnya adalah product yang sudah jadi dan baku dengan sedikit customisasi.
    2. Pendekatan Solusi —> dalam hal pemilihan vendor perusahaan lebih cenderung melihat kepada solusi yang ditawarkan, dimana jika ini dilakukan maka sebenarnya yang dibeli bukan product tapi solusi untuk mengimplementasikan ERP secara keseluruhan.

    Kenapa hal ini saya sampaikan terlebih dahulu sebelum saya mencoba untuk sedikit berbagi tentang implementasi ERP.
    Ada beberapa hal yang perlu disampaikan kenapa user requirement sudah ditandatangani tetapi sewaktu implementasi mengalami kendala :
    1. Bahwa dalam Implementasi ERP yang utama adalah bisnis proses mapping yaitu bagaimana bisnis proses current dan to be akan mappingkan sehingga software ERP dapat di customisasi. Dari kasus ini kita akan kembali lagi ke dua hal diatas, pendekatan mana yang diambil oleh perusahaan dalam menentukan vendor. Jika lebih cenderung ke pendekatan product maka customisasi akan sangat terbatas sekali. Sedangkan jika ke pendekatan solusi customisasi akan lebih mudah untuk dilakukan.
    2. Dalam kasus migrasi data, memang sebaiknya tidak dilakukan, karena hal ini akan merusak dari alur proses dari erp yang ada. Hal ini disebabkan dari bisnis proses current dan to be ada perbedaaan sehingga akan kesulitan sekali jika memaksakan untuk melakukan migrasi data.
    3. Data keuangan yang bersifat rahasia, kalau masalah ini sebenarnya hanya merupakan suatu pola pikir atau suatu kebijakan saja. Jika memang perusahaan sudah bersifat PT maka kepentingan yang bersifat pribadi dari Board of Director atau pemilik yang langsung terlibat dalam perusahaan harus di kurangi dalam arti jika untuk kepentingan pribadi tidak usah dilibatkan dalam perusahaan. Tentang pencatatan data keuangan, ini hanya masalah pencatatan saja, dimana pada saat pencatatan dalam system akuntansi diberikan keterangan yang tidak mencolok. Hal seperti ini sudah umum terjadi diberbagai perusahan.
    4. Tentang masalah pencatatan fixed assets yang masuk ke inventory ini karena di pilih perusahaan adalah pendekatan kepada product sehingga minim sekali customisasinya.

    Yang lebih utama dalam suatu implementasi ERP adalah bagaimana kita menyikapi perubahan dari Bisnis proses curent dan to be. Hal ini akan sangat terasa sekali karena Implementasi ERP akan membawa perubahan terhadap :
    1. Pola pikir
    2. Cara kerja
    3. Cara membaca report
    4. Jam kerja (pada saat awal implementasi
    5. SOP

    Ini yang biasanya menjadi kendala utama didalam pelaksanaan Impementasi ERP. ERP bukanlah suatu software, tetapi ERP adalah merupakan suatu system informasi yang di buat untuk membantu proses kerja.

    Demikianlah sedikit yang bisa saya sampaikan semoga dapat berguna.

    @
    Mas Pawit, terimakasih untuk catatannya yang berharga. Apa yang mas sampaikan benar adanya dan akan menjadi perhatian kami. Ada sedikit catatan dari pengalaman saya selama ini :
    Vendor (Implementor) tidak memahami dengan baik current ke to be dan juga tidak memahami dengan baik memetakan current pada luasnya sajian yang disediakan oleh ERP. Akibatnya current diposisikan secara salah pada to be. Ini adalah kesalahan fatal yang menyebabkan ERP digunduli (baca dikastemisasi) tidak pada tempatnya. Kastemisasi sebenarnya tidak diperlukan karena ERP sebenarnya sudah memberikan solusi terhadap masalah yang dihadapi. Namun, karena implementor salah memakainya, membuat proses menimbulkan polemik lain.
    Migrasi sebenarnya tidak masalah sama sekali, karena ERP menyediakan sarana migrasi untuk masuk ke dalam sistem dengan baik. Persoalannya data current tidak dipahami dan dipetakan dengan baik sehingga seolah-olah menjadi rumit. Padahal jika dipahami dengan baik apa yang ada di current dan apa yang dibutuhkan to be, maka masalahnya tidaklah terlalu rumit. Memang benar, tidak semua kunci-kunci database tersedia pada current. Namun, jika implementor memahami Axapta dan mengerti hubungan semua relasi-relasi database, mengerti apa yang harus disediakan pada data untuk dimigrasikan, maka hal ini tidak terlalu sulit.
    Kalaupun sulit untuk mengambil data, maka proses akuntansi bisa dilakukan dengan menjurnalkan informasi yang diperlukan untuk masuk ke dalam sistem.

    Pada kasus yang kami alami, memang Vendor lebih melihat pendekatan produk. Artinya gagal memberikan solusi dan cuma mengejar penjualan saja. Karena itu, mereka sebenarnya tidak punya cukup tenaga terampil, tapi hanya terampil di jualan saja.

    Antara mapping dan customisasi ERP.
    Menurut yang kami alami, kastemisasi boleh jadi perlu, namun memaksakan kastemisasi current ke ERP sama saja dengan menghilangkan kemampuan ERP membangun solusi bisnis. Sebaiknya Vendor mampu membaca batasan kastemisasi dan mengikuti lebih serius apa yang tersedia dalam fasilitas ERP. Ini jauh lebih mudah ditangani daripada menangani kastemisasi yang bisa membuat ERP kehilangan kemampuan-kemampuan dasarnya menangani kerumitan proses bisnis. Contoh kongkrit dari AXAPTA adalah dimension Ax. Setiap ditanyakan apa manfaat dimension, jawabannya hanya “sekedar text” yang mendampingi informasi dari nomor akun. Jawaban konyol ini menjelaskan bahwa pemahaman vendor terhadap sistem Ax sendiri masih kalang kabut. Prihatinnya, justru perusahaan membutuhkan sistem ini untuk mengelola sistem informasi dan analisisnya.

    Mengenai kerahasiaan dokumen atau kebijakan keuangan, AX menyediakan private journal dan group private journal. Jelas perlindungan ini diperlukan dalam banyak perusahaan untuk menangani data sensitif atau dianggap sensitif dalam sistem. Bukan karena withdraw dari pemilik saja. Tapi beberapa titik penjurnalan memang membutuhkan “untuk tidak disentuh” oleh yang tidak berhak.

    Mengenai Asset dalam sistem inventory, memang perlu dibedakan antara asset hanya untuk dipakai, asset yang memiliki nilai depresiasi, asset yang hanya dibeli saja. Juga transfer asset ke inventory. Dengan begitu, tentu saja ERP menangani asset (main asset atau sub asset) dengan standar akuntansi dan sekaligus memanajemi harta perusahaan dengan baik, bukan hanya pada catatan akuntansi tetapi proses pemeliharaan, kontrol asset, penanggung jawab, inventory asset, dan lain-lainnya. Keterpaduan ini yang memang membedakan ERP bukan hanya terkendali di level akuntansi, tetapi juga proses bisnisnya.

    Memahami proses bisnis dari sebuah ERP ini yang harus dikuasai dengan baik oleh implementor sehingga tidak terjebak oleh keinginan dari perusahaan yang boleh jadi salah memahami sistemnya sendiri. Semakin hari, kami juga semakin menyadari, ERP bukan software untuk tahu bagaimana memakainya. Tapi lebih utama adalah memahami apa yang dimiliki ERP sebagai suatu proses solusi bisnis. Apalagi dari sistem software ERP “kosongan” yang datanya harus dibangun dari permulaan.
    Salam.

    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: