Tuesday, 29 January 2013

SOP Bagi Pengurusan Asset

Terlebih dahulu, ucapan ribuan terima kasih kepada Allah s.w.t kerana semua tugasan yang diberikan dapat disempurnakan dengan jayanya. Kali ini, saya diberi tugasan menyiapkan SOP bagi pengurusan Asset.

Pengurusan Asset telah dibahagikan kepada 6 bahagian utama iaitu:
  1. Pendaftaran Aset / Inventori 
  2. Pengemaskini maklumat asset/inventori 
  3. Verifikasi / Pemeriksaan
  4. Pinjaman 
  5. Penyelenggaraan 
  6. Aduan 
  7. Pelupusan
  8. Pemindahan Aset / Inventori (yang melibatkan kewangan)

SOP juga yang perlu disiapkan adalah:
  1. Pendaftaran Aset / Inventori 
  2. Pengemaskini maklumat asset/inventori 
  3. Verifikasi / Pemeriksaan
  4. Pinjaman 
  5. Penyelenggaraan 
  6. Aduan 
  7. Pelupusan
  8. Pemindahan Aset / Inventori (yang melibatkan kewangan) 
Selain daripada SOP, saya juga perlu memastikan semua maklumat SETUP yang ada di dalam sistem adalah mengikut kehendak pengguna dan rekod tersebut perlu disimpan di tempat yang selamat. Setiap perubahan data setup, perlu dikemaskini di dalam maklumat panduan yang telah disediakan untuk memudahkan pengguna membuat rujukan.

Selain daripada itu, SOP yang disiapkan ini mengikut turutan supaya kesinambungan proses dapat diselesaikan dalam masa yang ditetapkan.

Thursday, 24 January 2013

Enhanced System (Module) Menggunakan Oracle Form Builder

Saya telah mendapat tugasan menyiapkan enhancement system menggunakan Oracle Form Builder. Tugasan ini perlu disiapkan mengikut timeline yang diberi. Saya telah dapat menyiapkan tugasan ini dengan jayanya kerana saya mempunyai kemahiran dalam design/coding yang ada atau coding baru.

 

Tuesday, 22 January 2013

Sistem Stock Control (juga dikenali sebagai Sistem Inventori)


Baru-baru ini, telah diadakan latihan Sistem Stock Control/Sistem Inventori bagi pengguna admin bagi menyimpan rekod-rekod stor. Selain daripada stor alat tulis, sistem ini juga sesuai bagi stor menyimpan barang-barang bengkel, makmal dan juga barang-barang pemasaran.


Sistem Inventori/Sistem Stock Control ini dibangunkan bertujuan:
  • Mendaftar semua stor yang terdapat di HQ dan cawangan-cawangan
  • Merekod penerimaan barang mengikut stor yang terlibat
  • Merekod pengeluaran barang daripada stor (secara online / manual)
  • Mengemaskini maklumat stor
  • Merekod paras minima (ROL level)
  • Mengetahui baki terkini stor




Flow Chart Bagi Sistem E-Procurement


Gambarajah dibawah menunjukkan kesilapan flow chart yang telah dihantar oleh vendor/software developer. Banyak kesilapan yang boleh dilihat dalam flow chart tersebut. Apabila diajukan soalan kepada pihak vendor/software developer, kenapa banyak proses yang tidak dipaparkan pada flow chart berkenaan, jawapan yang diberikan adalah “ User tidak perlu tahu proses berkenaan. Lagipun user bukan faham proses pun”. Sebenarnya pihak vendor/software developer silap kerana proses yang telah disembunyikan itu, pihak user akan mengandaikan bahawa proses tersebut tiada dalam system berkenaan dan system yang dicadangkan tidak bagus/lengkap. Malah, jangan la memandang serong kepada pihak user kerana mengandaikan mereka tidak faham/tidak tahu. Inilah kelemahan pihak vendor/software developer kerana terlalu sombong sehingga menganggap user tiada kemahiran tentang flow chart.


Thursday, 10 January 2013

Sistem Inventory vs Sistem Asset



Asset
Inventory
dikategorikan bagi harga kos yang lebih daripada harga siling asset. Contohnya, asset adalah semua barang yang harga kos melebihi daripada RM3000. Bagi barang tersebut, cabinet yang melebihi harga siling, dikategorikan sebagai asset
dikategorikan bagi harga kos yang kurang daripada harga siling asset. Contohnya, inventory adalah semua barang yang harga kos kurang daripada RM3000. Bagi barang tersebut, computer yang dibeli bawah harga siling, dikategorikan sebagai inventory
Depreciation & Accumulated Depreciation
Tiada depreciation

Ahli jawatankuasa pelupusan perlu melibatkan pihak kewangan

Pihak kewangan tidak terlibat untuk proses pelupusan

Cleanup Data Untuk Proses Data Migration


Data Cleanup adalah subjektif bagi sesebuah organisasi. Kita tidak ada tempat untuk membuat rujukan jika kita mempunyai persoalan bagi proses data cleanup. 


Antara soalan yang sering bermain di fikiran kita

  1. Adakah setiap data yang dibekalkan oleh organisasi mengikut template yang diberi?
  2. Adakah data tersebut dikaitkan dengan Setup? Adakah data setup tersebut adalah setup yang terkini?
  3. Adakah data yang diberikan benar-benar data yang sudah clean?
  4. Adakah data cleanup ini adalah tugasan pihak vendor/developer?


Bagi soalan yang dinyatakan, kita mencuba untuk mengungkai jawapan tersebut

  1. Bagi soalan 1 – walaupun data yang diberi mengikut template, tetapi data yang dimasukkan kadang-kadang tidak mengikut spesifikasi. Contohnya , template tersebut perlu di maklumkan cara untuk memasukkan data termasuk uppercase, lowercase, sentence case.
  2. Bagi soalan ke 2 – kalau data yang dimasukkan berkaitan dengan setup, vendor/developer perlu memaklumkan kepada pengguna mengenai data setup berkenaan. Dan data setup tersebut adalah data yang tulen/terkini.
  3. Bagi soalan ke 3 – kadang-kadang, vendor perlu buat re-migration semula kerana pengguna memaklumkan bahawa data yang diberikan tidak tulen dan mempunyai beberapa data yang perlu diubah
  4. Bagi soalan ke 4 – bagi pendapat saya, cleanup data perlu dilakukan oleh pihak pengguna. Dan semakan data cleanup juga perlu dilakukan pada organisasi. Data berkenaan amat difahami oleh pihak pengguna berbanding pihak vendor/developer. Selalunya pihak vendor/developer terus memasukkan data tersebut tanpa membuat semakan kedua.

Sistem Testing tidak boleh dilakukan oleh Developer/Programmer?



Apabila developer test code mereka sendiri, developer akan test bagi normal proses sahaja dengan ending output yang menarik/ menggunakan data yang sah sahaja. Ini akan menunjukkan seolah-olah code mereka tiada bug / error atau code yang mereka jana mengikut normal proses sehingga mereka terlupa untuk menguji exception proses/pengujiansecara terperinci.

Kebimbangan utama apabila developer yang melakukan testing adalah salah paham keperluan / keperluan kerja yang menyeluruh. Jika developer dari peringkat awal lagi sudah salah paham dengan keperluan pengguna, developer tidak akan jumpa masalah error yang berkaitan dimana masalah/error tersebut akan kekal sehingga pelaksanaan system dilakukan.   

Kebanyakan developer yakin dengan code yang mereka buat dan yakin dimana code tersebut berjalan dengan baik tanpa ada error/bug. Oleh itu, dengan keyakinan itu mereka tidak akan menguji code mereka.


Developer

Tester
Developer sentiasa inginkan code yang mereka jana/buat berjalan dengan lancar tanpa ada sebarang masalah/bug/error
Tester  akan test aplikasi kerana ingin menggagalkan aplikasi tersebut dengan apa cara sekalipun. Dan dengan pasti, tester akan menguji aplikasi tersebut dengan pelbagai cara untuk membuktikan yang aplikasi tersebut tidak berfungsi dengan baik.



Stock Control System


Ada sesetengah staff berpendapat bahawa stock control system adalah system yang merekod penerimaan barang, pengeluaran barang dan mengemaskini stock yang ada di dalam stor. Sebenarnya stock control system juga berkait dengan Income Statement dan juga Balance sheet. Oleh sebab itu, stock control system tidak boleh di pandang remeh oleh sesetengah pihak kerana stock control ini juga boleh menjejaskan keuntungan dan penyata kewangan sesebuah organisasi.

Dengan stock control system juga, kita mengetahui harga barang berdasarkan maklumat yang dimasukkan. Dengan maklumat ini juga, kita boleh melihat rekod kekerapan barang keluar/masuk di dalam system dan barang  yang telah lapuk di dalam store. Dengan ini, semua barang di dalam stor dikemaskini dan terkini daripada semasa ke semasa.

Training HR System (Claim Module) Integration with Finance System



Hari ini telah diadakan sesi latihan yang ke-2. Minggu lepas telah diadakan sesi latihan yang pertama. Apa yang berlaku pada sesi latihan tersebut? Dengan menggunakan module dan konsep yang sama, di dapati sesi latihan ke-2 lebih banyak bug/error yang timbul. Kenapa semua ini berlaku walaupun sesi UAT telah berjaya dilakukan?

Ada banyak kemungkinan kenapa masalah ini berlaku. Diantaranya adalah:
  1. Patch yang digunakan telah di update tanpa pengetahuan user
  2. Customization yang telah dibuat telah menganggu proses sedia ada
  3. Developer tidak sedar locking telah telah wujud semasa sesi latihan pertama

Apabila integration secara database tidak boleh dilakukan, ada beberapa konsep integration lain boleh dilakukan mengikut keadaan diantaranya menggunakan konsep import/export. Tetapi data import yang disediakan perlulah sama/seiring dengan maklumat system kedua. Kalau boleh, janganlah terlalu banyak menggunakan konsep manual.

Konsep Reverse Engineering


Semasa proses pembangunan system, kita menggunakan konsep SDLC (System Development Life Cycle). Hanya subjek ini yang sering diajarkan di IPTA/IPTS. Pelajar/graduan tidak permah di dedahkan dengan konsep reverse engineering. Ini berlainan sekali dengan dunia pekerjaan. Kebanyakan organisasi lebih mengutamakan produk on-shelf (produk base market) dengan mengambil kira customization yang perlu dibuat. Dengan konsep customization, banyak produk yang tidak disediakan dengan design & flowchart. Disini berlakunya reverse engineering supaya customization dapat dilakukan dengan jayanya. Tetapi, base product selalunya paling sukar untuk dilakukan customization. Oleh itu, reverse engineering memerlukan skills dan knowledge bagi product dan proses kerja. Dan proses reverse engineering akan lebih mudah jika skills yang lebih tinggi digunakan.   

Tuesday, 8 January 2013

QA Sangat Penting Semasa Pembangunan Sistem


QA digunakan untuk mengurangkan pelbagai kemungkinan kesilapan yang mungkin wujud dalam setiap fasa. QA juga untuk menjamin kualiti system yang dibangunkan adalah terbaik.

QA adalah quality assurance yang memastikan pembangunan system mengikut piawaian/standard yang telah ditetapkan. Piawaian yang dimaksudkan adalah perjalanan / pergerakan system yang dibangunkan mengikut kehendak pengguna

Matlamat utama QA adalah :
  • Membangunkan perisian  bebas daripada bug  / error yang nyata / terselindung
  • Menentukan samada terdapat apa-apa perubahan daripada keperluan perisian
  • Menggunakan perisian dalam persekitaran yang sebenar
  • Memberi keyakinan dalam menggunakan perisian

Kepentingan System Testing Semasa Pembangunan Sistem


Sistem testing boleh dilakukan pada fasa:
  • SRS
  • SDD
  • Pembangunan system – UAT
  • Integration system
  • Sistem

Sistem testing adalah mengesan kesilapan sebanyak mungkin menggunakan masa dan usaha paling minima.

Testing boleh dilakukan samada:

a.Black box testing – adalah pengujian bagi fungsi-fungsi aplikasi termasuk:
    • Decision table testing
    • All-pairs testing
    • State transition tables
    • Equivalence partitioning
    • Boundary value analysis

Black box testing  cuba mengesan kesilapan dari kategori berikut:
    • fungsi yang tertinggal atau tidak betul,
    • kesalahan antara muka/ interface,
    • kesalahan struktur data atau capaian kepada pangkalan data,
    • kesalahan kelakuan atau kemampuan,
    • kesalahan pada process flow.

b. White box testing - adalah testing bagi internal structure atau perjalanan aplikasi termasuk:
  • Control flow testing
  • Data flow testing
  • Branch testing
  • Path testing
  • Statement coverage
  • Decision coverage

Integrasi Sistem Booking dengan Sistem Asset


Booking sistem boleh dibahagikan kepada 2 iaitu:
  • Booking sistem bagi peralatan – pinjaman computer, LCD, kereta
  • Booking sistem bagi tempat – gymnasium, bilik mesyuarat

Booking sistem adalah sistem yang disediakan bagi organisasi yang menyediakan pinjaman. Booking sistem adalah sistem yang paling menarik kerana sistem ini akan dikaitkan dengan jadual dan kalender.  

Jika booking sistem melibatkan peralatan, maka booking sistem akan di integrasi dengan Sistem Asset

Integrasi ePayment dengan Sistem Perakaunan


Jikalau ada program / barang / perkhidmatan yang disediakan dan pembayaran dibuat menggunakan e-commerce. Dan maklumat tersebut terus di integrasi dengan system Perkaunan.
Ini adalah contoh epaymet yag telah saya buat dari segi interface. Epaymet ni boleh ditambah baik mengikut keperluan organisai.


ePayment yag dibuat adalah:
  • Seminar / Persidangan
  • Jualan Buku
  • Student fees
  • Student Summons/fines
  • Jualan Product