Sains-Inreligion

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

Mengintegerasikan Informasi dalam Paket Pemograman

Posted by agorsiloku pada November 28, 2007

Dari pokok-pokok persoalan yang dihadapi dalam ribetnya dua tahun bersama Axapta, kami akhirnya kami menjajal 3 program pendukung untuk Axapta, yaitu trade logistik internal (sayang jadinya, kami belum memakai modul Axapta), kas kecil yang kemudian kami ubah namanya menjadi myCentralDataBank, dan eHris (program SDM).

Membangun Informasi Dalam Paket Integrasi Perangkat Lunak.

Tulisan berikut ini tidak berbicara mengenai teknik pemograman, namun lebih ke arah bagaimana konsep organisasi “sebaiknya” dikembangkan dalam pembuatan program.

Organisasi adalah titik sentral informasi. Semua pelaporan, berinduk pada usaha menjawab posisi dalam organisasi, biaya, hasil, dan rasio manajemen, serta rasio unit-unit atau anggota di dalamnya. Program yang didisain tidak mengandalkan fleksibilitas organisasi akan mudah usang. Oleh karena itu, disain program dan tampilan harus memberikan kemudahan untuk dikembangkan dalam satu dinamika organisasi yang bergerak dan berubah-ubah. Berikut ini beberapa catatan yang kami anggap penting :

  • Organisasi memiliki sejarah,
  • Organisasi memiliki bentuk (struktur),
  • Organisasi memiliki nama,
  • Organisasi memiliki tingkatan (level) teratur dan tidak teratur (tidak mengikuti level),
  • Organisasi memiliki lokasi yang sama atau berbeda.

Sebuah laporan, katakanlah laporan penjualan dari suatu struktur organisasi yang mengalami perubahan setiap tahun (baik ukuran maupun dimensinya atau terjadi pergeseran area geografisnya). Pertanyaan kemudian, bagaimana kita harus melaporkan penjualan dari struktur organisasi 3 level di masa lalu menjadi 2 level di masa berikutnya atau melaporkan penjualan dari 3 salesman menjadi 10 salesman di tahun berikutnya dengan wilayah yang saling beririsan?. Kalau kita main total-totalan saja sih gampang, tapi apakah ini akan menjawab persoalan di wilayah mana dan pada salesman mana atau pada area mana terjadi penurunan rasio penjualan dan rasio biaya?.

Persoalan organisasi tidak hanya pada manusia, tetapi juga kita akan temui dalam produk, pelanggan, supplier, dan dokumen, maupun harta perusahaan (asset).
Juga tidak kalah penting, setiap produk, pelanggan, supplier, asset, maupun dokumen memiliki dimensi ukuran yang haus diperhatikan seksama. Ukuran-ukuran itu bisa berupa unit-unit atau satuan yang berdimensi satuan pengukuran, luas, volume, ataupun rumus fungsi matematik. Data ini bisa statis, tapi bisa juga bergerak. Seperti pengiriman barang – ekspedisi – pergudangan memiliki ukuran-ukuran yang diperhitungkan seksama. Kalau kita bicara produk, artinya kita bicara bahan baku, proses, dan pergudangan, dst.
Karakteristik lain yang harus diperhitungkan juga adalah mutasi dan kebijakan perusahaan dalam menjalankan aksinya. Bagaimana persoalan yang dihadapi ketika perusahaan/industri sedang bertemu dengan pelanggannya, berhubungan dengan suppliernya, atau menjalankan aksi pemasarannya (diskon, bahan promosi, pelengkap produk, sampai sekuriti data).

Hal terakhir yang tidak kalah pentingnya, tentu saja bagaimana kita mendefinisikan kejadian-kejadian di atas dalam satu klasifikasi penting. Di awal kita mulai dari sebuah proposal pengajuan (dan perencanaan dan anggaran) dan diakhiri dengan perhitungan berdasarkan nomor rekening akuntansi. Model-model antara pokok-pokok di atas adalah gelimang pikiran untuk melibatkan perumusan matematis dari berbagai masalah dalam industri dan perencanaan. Masalah perhitungan sediaan melalui FIFO, LIFO atau sejenisnyalah, metode penyusutan, model pengiriman, critical path method, dan seabrek modul-modul manajemen yang kerap dibangga-banggakan oleh para manajer dan konsultan.

Nah sekarang tergantung dari mana kita akan memulai mempersiapkan sistem yang terintegrasi. Dari mana saja terserah deh. Tapi perhatikan bahwa setiap jenis kegiatan atau apa saja memiliki “struktur organisasi” yang harus peka terhadap perubahan. Karena itu, selalu siapkan tabel database yang memiliki struktur organisasi sendiri yang bisa memotret kejadian pada asset, produk, jasa, dokumen, supplier. Tentukan mana variabel perubahnya yang bergerak bersama waktu, dimensi ukuran, dan mana yang mungkin akan bertambah atau berkurang pada berbagai kondisi.

Kalau pemograman dibuat dengan mengabaikan mana yang menjadi titik sentral pengembangan informasi dan data dengan unsur-unsur lainnya (organisasi terhadap produk, pelanggan, supplier, dokumen, asset) tidak terdisain dengan baik, maka bersiaplah untuk membuat program anda bisa tidak berfungsi baik, atau kesulitan dalam pengembangan karena gagal mengadaptasi hierarkhi data. Namun, jika program yang telah susah payah dibuat dengan tegas membangun klasifikasi yang kokoh, maka proses pemograman juga bisa diringkas dan padat, karena struktur satu bagian dari masalah bisa dicopy paste ke bagian lain untuk kriteria yang sama dengan sedikit modifikasi.

Oh ya.. sekedar catatan tambahan.. kalau sudah pernah mencoba software semi ERP atau akuntansi seperti zahir, logika, MyOB, maka kita akan menyadari, ketika perusahaan berkembang atau persoalan bertambah, kebutuhan meningkat, maka kita akan mengerutkan kening.

Jangan pernah dilupakan, satu pemenuhan akan melahirkan kebutuhan yang lain. Satu perubahan akan menimbulkan kebutuhan yang lain, dan satu kehilangan akan melahirkan penemuan atau pencarian yang lain. Karakteristik ini kurang ditangkap oleh para pengembang software, khususnya di tanah air.

Mengendalikan Kunci-Kunci Informasi.

Di atas telah diuraikan bahwa kunci-kunci informasi pada dasarnya berada pada tipikal bentuk organisasi. Bentuk ini menjadi bentuk dasar bagi seluruh kunci-kunci informasi berikutnya. Maka dengan mengikuti pola berpikir ini, akan kita temui organisasi manusia karyawan, organisasi produk, organisasi vendor/supplier, organisasi vendor, organisasi asset. Dengan bahasa lain kita katakan Tabel organisasi (karyawan, produk, pelanggan, vendor, asset, dokumen) . Tabel struktur ini adalah katagori yang ditentukan (variabel) yang akan memberikan muatan pada setiap informasi dari unsur-unsur yang menghubungkan sebuah transaksi yang terjadi.

Singkatnya, kalau tabel organisasi dikaitkan dengan produk maka kita akan mengelompokkan produk berdasarkan struktur produk. Struktur produk itu mengklasifikasi produk untuk setiap kepentingan informasi yang ingin dihasilkan. Kalau katagori organisasi dibangun dengan tingkatan L1-L2… Ln maka produk juga memiliki pola yang sama, dokumen juga, vendor juga, dst. Yang membedakan hanyalah nama atau sebutan saja. Dengan begitu kuncinya menjadi :

L1…Ln –>(Product Id, VendorId, Customer Id, Employee Id, Asset Id, Doc Id).

Id = identifikasi, nomor unik yang memastikan yang berperan sebagai master.

Kalau organisasi tertinggi ada 15 level, n menjadi 15. Jadi kalau kita membuat sebuah subprogram yang kuat dan teruji dari L1..Ln–>Product Id maka selanjutnya hanyalah mengkopipais saja program yang dibuat dan diterapkan pada katagori lainnya. Sangat disarankan untuk tidak membuat produk Id berbarengan (pada satu tabel master) dengan L1..Ln. Mengapa?. Karena mempersulit pengolahan informasi dan akan memaksa program menjadi lebih rumit ketika tahapan proses harus dilakukan. Sering terjadi (dan cenderung menjadi kebiasaan) untuk membangun L1..Ln pada tabel yang sama dengan master data. Akibatnya, karakteristik dari informasi pada tabel master menjadi beragam ketika data master akan diolah dalam proses transaksi. Jadi cukuplah dibuat saja penghubung antara master dengan satu field untuk terciptanya hubungan. L1..Ln sebaiknya dibuat terstruktur. Misalnya setiap Li (i =1 sampai n) dengan jumlah yang tetap atau teratur. Misalnya L001, L002, L003 (L001, L002, L003).

Dengan bentuk yang tetap maka ketika kita akan menjumlahkan penjualan cukup dengan menjumlahkan organisasi (yang sudah diterjemahkan ke dalam satu baris field) kepada transaksi yang terjadi.

Penjualan salesman

(L001 = Manajer, L002 = Supervisor, L003 = Salesman). –>L003, employeeId, jumlah penjualan.

Penjualan produk lembaran

(L001 = dus, L002 = pak, L003 = lembaran). –>L003, productId, jumlah penjualan.

Tentu saja dalam transaksi selalu dibutuhkan data yang lengkap sesuai dengan master data yang dibutuhkan. Jadi penjualan tentulah menyangkut productId,vendorId, employeeId, docId.

Usahakan semua data perhitungan selalu ditulis lengkap. Misalnya dalam kenyataan tidak ada VendorId karena pembeli datang langsung dan jual putus, tetap saja program melakukan perhitungan dengan seluruh unsur lengkap. Modifikasi hanya dilakukan diformat tampilan dan input, tapi tabel databasenya tetap.

Dengan begitu kita telah mempersiapkan model data general yang memenuhi syarat transaksi. Modifikasi untuk muncul atau tidakpun, sebaiknya pilihan (tick mark) bahwa informasi yang dibutuhkan perlu dimunculkan atau tidak. (lebih enak ini ditetapkan pada setiap master data dan pada user/pelaksana)

Cara-cara di atas memungkinkan data dan perhitungan selalu diproses dengan sebuah standar prosedur yang sama. Ini sangat menguntungkan dalam kecepatan pemograman maupun mengalihkan program yang dibentuk ke format-format lainnya.

Kalau variabel dari asset, produk, hrd, vendor, dokumen membutuhkan ukuran-ukuran, maka buat saja X, Y, Z hubungan X, Y, Z tergantung rumusnya, bisa pilih kategori matematika (kali, bagi, tambah, kurang, log, kuadrat, pangkat, atau fungsi sudut ) dan h (interval x, y, dan z) .  X, Y, Z adalah variabel pengukuran yang bisa diisi dengan satuan fisika (m, kg, ton, unit, pak, dll).  Pada tabel ini sediakan pula tanggal awal dan akhir.

Kemudian sediakan pula tabel kebijakan (multiple diskon, multiple price).

Kemudian pelajari seksama hubungan antara setiap item master.  Ada baiknya langsung dihubungkan antara productId dengan AssetId, VendorId dgn CustomerId, EmployeeId dgn ProductId, maupun documentId.  Jadi transaksi yang dibangun bisa memiliki hubungan-hubungan untuk kasus spesifik, misalnya bagaimana mengendalikan data penjualan yang dilakukan karyawan agar langsung tercatat menjadi pelanggan sambil pembayarannya nanti akan dipotong dari gajinya.  Kasus seperti ini unik.  Sama uniknya dengan kejadian yang harus dicatat, misalnya sebuah dokumen berpindah tangan dari staff A ke Staff B yang berbeda jabatan organisasinya.  Artinya ada hubungan antara DocumentId dengan EmployeeId, maupun VendorId (yang melakukan pengiriman).

Kalau banyak kemungkinan dari kejadian transaksi atau mutasi itu terdefinisi jelas dan juga masing-masing jenis transaksi juga dihubungkan dengan no.rekening (accountnum) maka bisa dipastikan bahwa perubahan atau permintaan perusahaan akan kejadian sudah tertangkap pada level pertama kejadian.

Singkatnya jangan ada yang dilupakan kombinasi-kombinasi transaksi yang mungkin terjadi (paling tidak sebanyak-banyaknya yang mungkin dapat kita pikirkan).  Tetapkan polanya dan masing-masing independen tapi dapat direlasikan secara database relasional.

Persiapan seperti ini menyelesaikan hampir 90% dari tindakan-tindakan yang harus dilakukan dalam mencatat transaksi apa saja.

Barulah setelah lengkap, pemograman terstruktur dilakukan.  Untuk selanjutnya, hampir banyak persoalan tidak lebih dan kurang berada pada level berikutnya (group by) dan hanya klasifikasi atau pengelompokkan untuk berbagai kepentingan.

Ketika ini bisa dipetakan dengan baik (tentu struktur data sebaiknya melihat supply chains management), maka program akan memiliki disain yang mantap dan mudah dikembangkan.  Selanjutnya, tentu saja disain pula satu pola menu yang akan dikembangkan untuk modul menu lainnya yang relatif akan sama cara dan aturannya).

Jika peta ini sudah siap, maka model sudah bisa dibuat programnya… serahkan pada programmer handal Anda…..

Iklan

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: