Navision's Objects - A Technical Overview

Agar Hidup Lebih Objektive ;)

 

Navision adalah sebuah software aplikasi ERP yang beroperasi dengan berbasiskan objek-objek yang dimilikinya. Jika kita membuka bagian Object Designer maka akan tampaklah semua objek-objek nya. objek-objek inilah yang menjadi jeroan dibalik penampakan navision yang digunakan oleh user sehari-hari. Itulah sebabnya jika ada masalah dengan transaksi-transaksi yang 'ajaib', biasanya para konsultan seperti kita langsung melakukan 'pemerkosaan' (=P) terhadap sistem dengan mengubah harga pada salah satu tabel yang terkait. Karena tabel adalah bagian dari objek.

Di dalam ilmu pemrograman, pemrograman yang berorientasi objek (OOP) merupakan sebuah langkah yang cukup revolusioner dibandingkan dengan madzhab pemrograman sebelumnya (struktural/prosedural). karena paradigma pemrograman ini mengizinkan programer untuk memodelkan objek-objek nyata dalam kehidupan sehari-hari menjadi sebuah tipe data yang  abstrak sehingga dapat disimulasikan dalam dunia virtual. Tapi, marilah kita lupakan sejenak tentang ilmu pemrograman dan kembali ke objek-objek yang ada di Navision. :D

Di dalam Navision, objek-objek dibagi menjadi 5 jenis, yaitu Tabel, Form, Report, Dataport, dan Codeunit. Masing-masing jenis objek memiliki peranan yang spesifik sebagai berikut : 

Objek Pertama - Tabel
Tabel adalah salah satu tipe objek yang sangat penting fungsinya dalam software data-base seperti Navision .. ibarat kate nih, software database tanpa tabel itu seperti makan kagak pake nasi. atau ibarat nikah kagak ada pasangannye he..he..he.. bahkan saking pentingnya, biarin lah software database isinya cuman tabel doang tanpa Form atau Report atau yang lainya.. asal siap2 aja mabok buat ngentri atau baca data nya huehehehe..

Nah tabel ini berfungsi sebagai sarang atau rumah buat sang data.. disana ada kamar-kamar yang dinamakan field, field ini ditampilkan dalam bentuk kolom-kolom tabel. sedangkan baris pada tabel (record) adalah sekumpulan data yang memenuhi masing-masing fieldnya. satu record umumnya merepresentasikan sebuah data beserta atribut-atribut yang melekat padanya ataupun mencatat sebuah transaksi.

Nah kalo kita lihat dari perilakunya, tabel-tabel ini pun dapat kita bagi lagi menjadi (setidaknya) 3 macam.
1. Tabel Sumber : Yaitu tabel yang memuat data-data dasar dari sebuah proses bisnis. data-data ini sifatnya statis dan tidak akan pernah berubah oleh jenis transaksi apapun kecuali oleh aktivitas entry data manual. Karena dia merupakan tabel sumber, maka tabel ini akan selalu menjadi rujukan dalam setiap transaksi yang dilakukan. Tabel-tabel yang tergolong tabel sumber adalah seperti : Tabel Item, Tabel Customer, Tabel Vendor, Tabel Unit of Measure, Tabel Item Unit of Measure, Tabel Location dan tabel-tabel sumber lainnya. Tabel sumber ini umumnya diisi pada masa-masa awal implementasi.

2. Tabel Transaksi : Tabel jenis ini merupakan tabel dinamis, yaitu tabel yang berinteraksi dengan user pada tahap pengisian atau pengolahan dokumen (form) . tabel transaksi ini biasanya diisikan atau diolah oleh user dengan mengkombinasikan beberapa data dari berbagai tabel sumber plus data tambahan yang di entri secara manual. misalnya salah satu contoh dari tabel transaksi adalah Sales Header yang merupakan kombinasi dari tabel-tabel sumber seperti Customer, Salespeople/Purchaser, Payment Terms, Location, Shipment Methods, Shipping Agents. atau pun tabel transaksi sales line yang merupakan kombinasi dari tabel-tabel dasar seperti Item, Item Variants, Item Unit of Measures dan beberapa field seperti Quantity yang diisi sendiri secara manual.

3. Tabel Muara :  Nah kalo nyang ini merupakan tempat 'pembuangan' akhir dari data setelah transaksi lengkap dilakukan. biasanya tabel muara ini terisi setelah aksi-aksi yang memicu terjadinya transaksi dilakukan, seperti aksi register, atau posting. Kalo di Hakiki biasanya tabel yang beginian itu diakses untuk mencari kambing hitam. siapa yang sudah salah posting, atau salah entry hehehe.. yang digolongkan sebagai tabel muara adalah tabel-tabel seperti Item Ledger Entry, Warehouse Entry, Sales Invoice, Sales Shipment, Customer Ledger Entry, Value Entry, Vendor Ledger Entry dan Muara dari segala transaksi yaitu G/L Entry serta ledger entry-2 lainnya.. tabel muara ini juga yang suka dikenai aksi2 'kekerasan' jika terjadi kesalahan2 transaksi, seperti tanggal posting atau harga,

 
Objek Kedua - Form
Form itu laksana jendela komunikasi antara sistem dan manusia (shhaaaah gaya teu? =P). Dia menyediakan informasi untuk user sekaligus juga sebaliknya, menyediakan perangkat2 yang dapat digunakan user memberikan perintah atau informasi kepada sistem. jadi ini kayak the interactive part of the system.. bagian ini kayak public relationnya sistem buat user.

Form dapat memberikan informasi dengan cara mengakses tabel serta menampilkannya secara langsung kepada user, form juga dapat digunakan oleh user sebagai tempat entry data, karena field-field yang tersedia pada form mengizinkan user untuk membubuhkan dan mengubah harga-harga yang ada padanya. Informasi yang diberikan oleh user melalui form pada umumnya akan mengisi tabel transaksi, selain itu form juga dapat mengeksekusi transaksi, meloncat untuk menampilkan form berikutnya dll, karena salah satu ciri khas dari form yang mutlak dapat kita kenali adalah adanya button ataupun menu untuk melakukan eksekusi, validasi, ataupun untuk berpindah ke form atau dokumen lainnya.

Selain dari itu, dalam sebuah proses bisnis, form juga berfungsi sebagai dokumen, form biasanya merupakan sebuah dokumen yang terlibat dalam salah satu fase dari keseluruhan rangkaian proses bisnis. oleh karena itu penanganan sebuah form berada dibawah tanggungjawab salah satu fihak yang terlibat dalam proses bisnis tersebut. misalnya sales yang bertanggungjawab terhadap Sales Order, Sales Quotes. atau Form Warehouse Shipment dan Warehouse Pick yang berada di bawah tanggungjawab Warehouse Officer..etc. Dan karena form terkait dengan tanggungjawab maka biasanya juga form ini memiliki print version yang dapat menyajikan form yang sudah dilengkapi oleh yang bersangkutan dalam versi hard copy untuk kebutuhan pengarsipan manual.

hemmm... apalagi tentang form yah???

O iya, Form ini kan PR nya sistem buat user, jadi dia harus di desain se-ergonomis mungkin sehingga menimbulkan kesan nyaman untuk digunakan. disini juga segala macem pengaman dipasang untuk mengurangi human error dalam pengisian data. bahkan saya pernah membayangkan bentuk interaksi antara sistem dengan user untuk aplikasi gudang, gimana kalo lebih graphical instead of tabular?. misalnya dengan gambar rak2 dan ruangan gudangnya, pokok-e ada visualisasinya. Soalnya berbeda dengan orang finance atau akuntansi yang terbiasa dengan tabel, sepertinya orang gudang akan mudah terbantu jika aplikasinya lebih visual,, kalo movement ada icon yang begerak2 dari bin satu ke bin lainnya,, hehe.. pake GUI gitu??.. bisa nggak yah??..

I think its still be a challenge..  ;)

  
Objek Ketiga - Report
Nah, berbeda dengan Form, objek yang satu ini berkomunikasi dengan user hanya satu arah, dimana sistem --dengan permintaan user tentunya-- menampilkan data-data dan informasi yang diinginkan dan tidak sebaliknya, user tidak dapat mengutak-atik apapun ketika report sudah dijalankan. Dan sesuai namanya, report digunakan untuk melaporkan seluruh transaksi yang pernah terjadi di dalam sistem. olehkarenanya ketika report dijalankan selalu berupa print preview yang siap untuk dicetak. karena sifatnya laporan dari hasil transaksi maka biasanya report bekerja dengan mengakses tabel muara.

Dalam sebuah perusahaan, biasanya cukup banyak permintaan data di akhir perioda analisis baik itu untuk kebutuhan pertanggungjawaban maupun untuk kebutuhan analisis dan perencanaan langkah perusahaan selanjutnya, dalam hal ini dibutuhkan teknik pelaporan yang dapat mengkombinasikan seluruh data transaksi yang disediakan oleh sistem. seperti data penjualan ke customer, pembelian dari vendor, penjualan item tertentu untuk customer tertentu dsb, dan report tersebut dapat ditampilkan dengan menggunakan satu tabel muara sebagai sumber atau beberapa tabel yang dikombinasikan dengan teknik pemrograman tertentu yang biasanya jadi urusan Iqbal ama Hilma. =)

 
Objek Keempat - Dataport
Ehm.. ehmm.. mau nulis ini teh malu euy.. soalnya belon pernah make :"> ... pernah sih.. nyoba sekali mengeksport data.. tapi cuman buat iseng.. dan abis di ekport nggak di apa-apain lagi.. jadi maaph jika uraiannya terlalu text book atau rada teoritis..

Nah, kalo kata petunjuknya sih (Application Development Guide.pdf) gini bunyinya.. "Dataports are objects that used for importing data from and exporting data to external text files" jadi kalo di departemen perdagangan mah kayak bagean EXIM nya kali ya..

Dengan data port ini kita bisa mengeksport data keluar dari navision menjadi sebuah file .txt , untuk itu kita bisa memilih field-field mana saja yang akan kita eksport :D.. begitu halnya dengan import dari file text.

hehe.. dikit ya.. kurang detil :D.. karena kurang menjiwai.. maaf..

 
Objek Kelima - Codeunit 
Jika kita mengenal tabel sebagai rumah dari data maka codeunit itu fungsinya adalah sebagai tempat ditanamnya skenario pergerakan data dari rumah yang satu ke rumah yang lain. suatu objek codeunit biasanya merupakan satu sekenario dari transaksi tertentu. jadi jika tabel itu sifatnya statis maka codeunit itu lebih dynamic.

Tidak hanya itu, codeunit juga adalah objek yang menjadi harapan terakhir untuk melakukan customisasi terhadap proses bisnis spesifik yang belum diakomodasi oleh fungsi2 standard Navision. So this is the lowest level part of the system, as i always be lazy to watch the script line by line and capturing its scenarios.. hehehe..

Salahsatu keunggulan Navision yang sering diulas dalam beberapa literatur yaitu extreemly customizable. Pertanyaan selanjutnya adalah, "Seberapa ekstrim kita bisa melakukan customisasi?" nah harapan terakhirnya ada pada codeunit itu.. semakin tinggi daya jelajah kita di codeunit, berarti semakin besar customisasi yang mungkin bisa kita lakukan. 

Hemm... well, demikian pemaparan subjektif saya tentang objek2 di Navision semoga kehidupan kita bisa lebih objektive ya nggak bal (lirik Iqbal :P - red) he..he..he..

 
I warn you !!! :
1. Ini adalah tulisan tentang teknikal dari orang awan dan untuk orang awam.
2. Membaca paparan ini mungkin dapat membuat pandangan yang lebih utuh tentang Navision yang kita geluti sehari-hari. otherwise, it can make you a little bit confuse.. hehehe
3. Jika bingung berlanjut segera hubungi Master Faizal, Master Iqbal, Atau Master Hilma
4. Dibutuhkan pengayaan terhadap tulisan ini.. jadi silahkan tanggapi. :)

Jejak-jejak Implementasi [1]

Cerita ini berawal dari tawaran seorang kawan untuk bergabung di sebuah company, perusahaan konsultan, Implementor software ERP (Enterprise Resource Planning), tepatnya kita menggunakan Navision, sebuah brand yang dikeluarkan oleh Microsoft. Jadi ceritanya adalah Microsoft Business Solution Certified Partner.

Perusahaan tempat saya gabung ini punya base di Jakarta, kantornya di Kemayoran tepat didepannya PRJ. saya kalo ke Jakarta suka nongkrong di sana.. cuman karena ini perusahaan konsultan.. maka kantor itu akan penuh jika tidak ada kerjaan hehehe. kalo banyak kerjaan berarti banyak projek dan semua konsultan yang ada akan tersebar ke tempat client nya masing-masing. akan tetapi sejak pertama bergabung dengan perusahaan ini (awal Februari) sampai saat ini saya tergabung dalam team yang menangani project di sebuah client di surabaya..

Selama satu semester bergerak di dunia ERP cukup banyak pengetahuan baru yang saya dapet. Mulai softwarenya itu sendiri, data base (SQL Server), Jaringan, Komunikasi Data, Proses bisnis, Manajemen Gudang, Finance, Ilmu komunikasi meyakinkan client, bahkan sampe cara berkelit ketika belum bisa menjawab pertanyaan client hehehe :p

 
1. Tentang Team.. 
Team konsultan kami terdiri dari 3 bagian dalam setiap implementasinya, yaitu bagian finance, warehouse (untuk client distribusi) dan bagian teknikal. dibutuhkan bagian-bagian tersebut karena ERP itu menghendaki integrasi dari sebuah proses bisnis. Pada awal bergabung saya memutuskan untuk ikutan ke bagian teknikal.. karena yang terbayang waktu itu cuman teknikal saja, yang lain belon terlalu punya gambaran. Sampai seiring dengan berjalannya waktu saya berpindah ke bagian gudang karena beberapa pertimbangan.

Karena yang kita implementasikan itu software yang sudah jadi, maka bagian finance dan warehouse itu adalah bagian aplikasi dari fitur-fitur dan menu-menu yang sudah available di Navision-nya sedangkan bagian teknikal adalah bagian yang melakukan customisasi terhadap kebutuhan proses bisnis client yang spesifik yang belum terakomodasi oleh software. jadi namanya bukan programer karena nggak ada proses membuat program dari awal. semuanya sifatnya customisasi dari tabel, form dan code yang sudah ada.

 
2. Tentang Client ^_^ 
==> data-data primer
Client saya di surabaya ini adalah perusahaan distribusi, mereka distributor bahan roti dan kue, dari mulai tepung roti, improver, susu, maizena, symrise, coklat bubuk, coklat butir, margarin, jagung, tatakan kue, lilin angka, boneka hias, cetakan coklat, gell. dari berbagai merek.. waaaa pokoke uaaaakeeh tenan.. jumlah itemnya ada sekitar 3000-an item, jika ditambah dengan variant-nya mungkin sekitar  3500-an bisa dibayangkan bagaimana softwere nya harus merekam data sebesar itu. belum lagi jumlah customernya yang sekitar 1600-an, yang bervariasi, dari mulai pabrik, hotel, restoran, retail dll... berkisar dari retailer sampe whole saler. Belum lagi Vendor yang jumlahnya 300-an dari dalam dan luar negeri. client saya ini juga punya 1 gudang utama di surabaya tepatnya di daerah margomulyo besarnya seukuran hanggar boeing 737-400 didalamnya ada sekitar 3000 bin atau rak yang baru dikasih nama sejak navision di implementasikan, sebelumnya dengan sistem lama, pengelolaan gudang sebesar itu dijalankan tanpa adanya penamaan bin (rak), jadi gudang itu dianggap sebagai sebuah bin besar, sehingga jika warehouse officer (baca: kuli) mau picking barang dia maen hafal2-an, ngapalin tiang demi tiang dan tidak jarang mereka harus mencari-cari dulu barangnya keliling2. Selain gudang utama tersebut, ada juga 1 toko di surabaya, 1 kantor yang juga rangkap sebagai gudang, dan 1 gudang di malang. belum lagi jenis transaksi yang sangat bervariasi, dari mulai pembelian eceran sampe partai besar, dari cara pembayarannya yang cash, atau lewat bank, atau lewar giro mundur yang bisa sampe 3 bulan.. prosedur penagihan oleh collector yang jalan2 ke customer, ataupun prosedur pembayaran utang ke vendor..

Serangkaian data2 primer tersebut (customer, vendor, item, bank, account, location, bin dll) menjadi bahan awal untuk di entry, sedangkan untuk transaksi2 yang tidak tersedia di Navision perlu ditambahkan tabel atau form tambahan. Giro mundur misalnya, jenis pembayaran ini rupanya common  di indonesia tetapi tidak di tempat lain, sehingga bagian teknikal harus sedikit putar otak untuk membuatkan fasilitas tambahan ini di softwarenya.

FYI: Salah satu cara untuk mengukur bagus atau tidak nya sebuah software ERP adalah dari kemudahan software tersebut untuk dicustomisasi, Seperti halnya Navision adalah salah satu contoh yang extreemly customizable. Karena mereka open source. tinggal kecanggihan orang teknikalnya yang harus terus diasah. :)

==> Anatomi Sosial Client.
Selain data-data bisnis tersebut, perlu juga saya menjelaskan hal diluar teknikal. a little bit social, tapi cukup menjadi faktor penting terhadap seluruh rangkaian implementasi yang dilakukan. Perusahaan ini dimiliki oleh seorang bapak dengan 3 orang, dua laki2 dan satu orang perempuan. Sang  anak perempuan tidak terlibat di perusahaan tersebut. Yang menarik, perusahaan tersebut sedang mengalami regenerasi dari sang bapak ke kedua anak lelakinya.. sebelumnya memang sudah di urus oleh anak lelaki yang pertama selama sekitar 3 tahunan tepat setelah dia menyelesaikan sekolahnya, pengalaman memimpin perusahaan tersebut cukup membuat sang kakak matang dalam memanage dan mengeluarkan kebijakan-kebijakan tepat dengan cepat. Berbeda dengan sang adik. si adik yang baru saja menyelesaikan kuliahnya (si adik seumuran saya, dia kelahiran 1981) sekarang mulai menggantikan kakaknya yang di tugasi sang ayah untuk menangani pembuatan pabrik margarin sebagai ekspansi usaha yang dilakukan keluarga tersebut. Sehingga fungsi sang kakak di perusahaan distribusi ini hanya menjadi pengawas dan pembimbing buat adiknya. Nah, celakanya proses pergantian top manajement ini dilakukan pada saat implementasi ERP sedang dijalankan, yaitu saat konsultan harus memahami dengan sangat dalam tentang proses bisnis client, dan di saat komunikasi antara dua fihak yang faham harus berjalan dengan sehat, juga disaat top management harus mengeluarkan keputusan2 yang tepat.. karena masa2 implementasi adalah masa2 genting, penuh perubahan di sana-sini, penuh keterkejutan2 dll.. jika leadernya nggak bisa ngambil keputusan tepat dengan cepat maka implementasi bisa menjadi bumerang yang memporakporandakan perusahaan.. membuat aktivitas bisnis sama sekali terhenti.. mungkin kalo dalam industri pengolahan minyak.. plant nya trip atau shut down.. hehehe..

Terkait dengan regenerasi perusahaan maka jika kita perhatikan karyawan-karyawan perushaan ini juga dapat dibagi menjadi dua kelompok umur, yaitu karyawan2 yang seusia sang bapak (setengah baya) dan karyawan2 muda yang seumuran anak2nya, they are quite energic, and passionate. Karena mereka generasi muda, maka pada umumnya mereka lebih siap dalam menghadapi perubahan, tidak terjebak dengan status quo dan kenyamanan sistem sebelumnya. dan hal tersebut sulit ditemui pada generasi yang lebih tua.

Jika jantung dari sebuah perusahaan manufaktur adalah pabrik, maka jantung dari perusahaan distribusi adalah gudang. dan yang membuat sulit implementasi di awal salah satunya karena personil gudang yang sebagian besar datang dari generasi sepuh. sulit berubah, bahkan sempat terjadi pertentangan dan benturan yang cukup keras dari para personel di gudang ketika sistem mau di pasang. Penentangan ini nggak tanggung2 datang dari arrangger gudang yang tiap harinya mengumpulkan sales order, menata sales order itu sehingga bisa langsung di pick oleh kuli dan siap untuk dikelompokan berdasarkan tonase dan area untuk selanjutnya dimasukan ke dalam truk dan mendapatkan rute pengiriman yang efisien. sang bapak itulah yang mengatur semuanya. posisinya sangat vital, kalau gudang itu jantungnya distribusi maka bapak ini (sebutlah namanya Pak Toro) adalah jantungnya gudang. secara struktural pak Toro ini berada di bawah kepala gudang yang sama-sama datang dari generasi sepuh.

 
3. Tentang Implementasi - "Sebuah interaksi mutual antara Konsultan dan Client (?)"
Jika saya dapat membuat klasifikasi fase implementasi ERP, Saya bisa membaginya dalam 3 fase:
1. Fase Assessment : Yaitu fase dimana konsultan mempelajari bisnis proses yang dimiliki client, pengumpulan data2 primer untuk dapat di entry kan ke dalam sistem.
2. Fase Go-LIve  (optional) : Yaitu fase dimana sistem baru sudah dapat dioperasikan akan tetapi sistem lama pun masih digunakan, bahkan masih jadi sistem utamanya.. fase go-live ini terjadi jika implementasi yang kita lakukan merupakan pergantian sistem ERP, tujuannya untuk pengkondisian agar para karyawan terbiasa dengan sistem yang baru.
3. Take-off : Pada fase ini sistem lama murni tidak digunakan sepenuhnya. dan seluruh proses bisnis dilakukan dengan sistem yang baru.
4. Pasca Take-off : Pada fase ini dilakukan pendampingan yang intensif oleh konsultannya kepada client nya. biasanya pada masa ini keadaan perusahaan memanas, suhunya tinggi dan penuh gejolak dimana2, pokoknya sangat emosional.

Nah, sayangnya saya bergabung dalam proyek surabaya ini pada masa2 menjelang take-off, sementara saya masih bengak-bengok dengan ERP, masih gagap dengan softwarenya dan masih  bingung kenapa kok perusahaan distribusi yang seharusnya aktivitasnya cuman beli dan jual ini kok bisa serumit ini...

 
.... bersambung