ERP Implementation – Notes

Berikut tambahan beberapa catatan perjalanan dalam implementasi ERP di tempat kami.

1. Hati-hati dalam business requirement study
bisa ada yang ketinggalan antara lapangan dengan administratif

contoh : ketika BRS di rubber factory, semua cukup jelas
namun ketika dilakukan Blueprint Walkthrough, dari orang administratif ketahuan bahwa ada status TOLL PROCESS, OUTGROWERS, dan OWN yang belum sempat tercover/tersampaikan informasinya ketika BRS.

2. Pada semua proses/tahapan, setiap meeting, buatlah berita acara / minutes of meeting, catat semua kejadian, catat peserta, requirement pada saat diskusi/meeting berlangsung.
Walau pun pasti ada yang miss, namun setidaknya bisa meminimalisir berulang-ulangnya finalisasi blueprint.

3. Penandatanganan blueprint harus melampirkan secara mendetail dari setiap
– report
informasi apa saja yang akan ditampilkan dalam setiap report.

4. COA adalah penting, harus ABC = activity base costing
tujuan : untuk simplified, easy to maintain

jika sama-sama ABC, tapi konsepnya berbeda, misalnya :
X = menuliskan semua dalam masing-masing account
Y = menuliskan hanya account utama, ditambah dimensi :
– Mature/Immature
– Product : OP/Rubber/Tea
– Labour/Material/Transport/Contract

Namun ada juga COA yang justru makin panjang, tapi tetap ABC

pros and cons :
– toh tujuannya sama, kenapa harus spend waktu lebih banyak untuk modifikasi
– bukannya tak bisa, tapi pertimbangan waktu modifikasi dari yang sudah ada, tinggal pake
– buat studi apakah banyaknya field memperpanjang waktu proses ? field dimensi
– apakah proses mau dilimpahkan/bebankan kepada user ? ataukah mau diserahkan ke sistem ?
– mau beli baju yang sudah dibuat mereka, atau mau diukur supaya pas di badan kita
– orang sistem, pasti maunya membebankan kerjaan kepada user, vice versa
– apakah kalau ngikutin maunya kita, ke depan akan ada masalah gak ? jangan sampe mereka bilang, “itu kan
maunya anda! itulah impactnya”
– kalau kita ikutin mereka, kita bisa pegang cakapnya. dan mereka harus mempertanggungjawabkan
– masalah performance, transaksinya akan lebih baik jika dipisahkan tiap bulan untuk mempertahankan kinerja
logikanya kalau mencari data di satu bulan tentunya lebih sedikit dibanding semua data jadi satu.
– pelajaran dari navision, yang databasenya terus membengkak. well, membengkak adalah kewajaran. lha iya thoh ? Masaka database bgitu-bgitu aja. Tapi maksudnya disini, membengkak dan melambat. Apakah solusinya ganti server ? Sebelum betul-betul ganti server, coba analisa dulu, apa iya servernya yang mestin diganti ? Karena planning yang kurang tepat dalam mendesain program/database juga dapat mengakibatkan turunnya performance. Jadi bukan semata-mata servernya harus diupgrade. Setuju ?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s