Qaisa - Notes and Guides

Syukur alhamdulillah, saya telah lulus exam PRINCE2 FOUNDATION. Sekarang saya akan cuba mem'praktiskan konsep prince2 dalam ' consultation' saya nanti Posted via Blogaway

Training MS Office Excel 2007 Intermediate telah diadakan untuk improve knowledge and skill staff. Training ini memg bagus bagi staff untuk  mengetahui lebih banyak function microsoft dalam ms excel ini.

Salam semua, Haritu, saya telah diberi tugasan untuk buat data migration post graduate. Saya telah membetulkan data tersebut berdasarkan complain pengguna apabila mereka dapati report yang dijana adalah salah. Setelah semakan dilakukan, ada maklumat yang perlu dimasukkan bagi menjana maklumat yang betul. Saya terpaksa mengemaskini maklumat tersebut secara detail supaya maklumat tersebut benar dan memenuhi kehendak. Selepas kejadian itu, saya mendapat aduan sekali lagi bahawa maklumat yang dimasukkan juga bermasalah. Kerana masalah ini terjadi berulang kali, saya memohon pihak yang bertanggungjawab menjawab soalan ini. Semakan keatas design database, maklumat tersebut bukanlah maklumat yang penting (not mandatory & not foreign key). Tetapi maklumat tersebut diperlukan bagi menjana report dan proses yang lain. Dan pihak yang bertanggungjawab ke atas sistem ini juga tidak aware kepada semua maklumat yang perlu disimpan dengan alasan, pemprosesan dalam sistem ini tidak ada stan

Salam.... Semasa penilaian penender dilakukan, banyak perkara yang kita terlepas pandang, termasuklah saya. Bagi kita, penilaian penender hanya melibatkan maklumat yang dinyatakan sahaja. Penilaian yang sering dilakukan: Harga Modal syarikat Projek yang telah dilakukan Presentation produk (jika berkaitan) Perkara yang kita lupa adalah: Melawat projek yang telah berjaya (reference site). Semasa lawatan rujukan inilah, kita boleh tahu dan nilai samada projek yang dinyatakan adalah projek yang berjaya atau tidak. Kita juga boleh tahu, kepuasan pelanggan penender bagi projek yang terdahulu. Selain daripada kepuasan pelanggan, kita juga boleh memohon pelanggan terdahulu melihat projek tersebut secara dekat. Kerana kelemahan tersebut, projek yang sedang dijalankan menjadi lambat. Ketidakpuasan hati pengguna juga terpaksa dipendam akibat kecuaian pemilihan penender.  Diharap, selepas ini, penilaian lebih teliti perlu dilakukan.

Vendor pada mulanya tidak mahu mengaku salah, menuding jari kepada user. PM beranggapan denan internal meeting yg telah diadakan cukup untuk memantau perjalanan projek. Menyalahkan user dengan beranggapan semua user tidak memahami proses kerja mereka. Setelah didesak beberapa kali dengan bukti yg kukuh, barulah PM mengaku kelemahan mereka. Sungguh memalukan, walhal mereka selalu canang pada semua orang yang mereka telah berjaya menyiapkan projek yang besar2. Perkara remeh macam tu pun tidak boleh ditangani dengan profesional. Secara kesimpulannya, vendor ini bekerja tidak profesional, menuding jari ke arah orang lain untuk menutup kelemahan diri sendiri. Sungguh memalukan. Apabila melakukan penilaian, perlulah dinilai dari semua bukti, jangan hanya gah yang di dengar. --- sharing is caring ---

Setelah meneliti semua module dokumen, saya dapati QA BPA Doc tidak dilakukan oleh vendor. Itulah kelemahan vendor dalam menjalankan tugas mereka. Dengan kelemahan vendor juga menyebabkan kelewatan menyerahkan dokumen untuk semakan. Apa kelemahan jika QA dokumen tidak dilakukan: 1. Format setiap module berbeza mengikut pengarang 2. Konsistensi ayat bagi setiap module tidak selaras 3. Indent dan format tidak diselaraskan dengan betul Masa yang diambil untuk membetulkan dokumen tersebut telah menganggu jadual perjalanan sistem. Oleh itu, pihak vendor tidak boleh mengambil lewa dalam semua proses pembangunan sistem yang sedang dijalankan. --- sharing is caring ---

Selepas BPA document telah di sign off, langkah berikutnya adalah menyiapkan gap analysis document. GAP analysis dokumen amat penting kerana dapat menilai sejauh mana perbezaan sistem sedia ada dengan kehendak pengguna. Dokumen ini tidak melibatkan pengguna, dan pihak yang terlibat adalah pihak vendor dan juga IT department. Disini dapat menilai sejauh mana vendor memahami maklumat pengguna yang telah diterangkan. Dan daripada dokumen ini, akan diteruskan kepada dokumen teknikal. Pengolaan ayat dan penggunaan ayat dalam dokumen ini lebih kepada perkataan teknikal dan lebih cenderung kepada teknikal documen. --- sharing is caring ---

Salam Saya diberi tugas untuk migrate data student ke dalam sistem perakaunan. Tugas ini saya terima dengan bersungguh-sungguh. Jauh di sudut hati tertanya2 mengapa tugas ini diserahkan kepada saya bukan kepada pihak yang bertanggungjawab mengawal selia sistem kewangan pelajar. Pihak kewangan ingin migrate semua maklumat data termasuk ageing dan yang dah knockoff dengan alasan mudah untuk menyemak kembali data history pelajar berkenaan. Setelah kerja2 migration siap dilakukan, saya memohon pihak kewangan untuk mengesahkan data tersebut. Pihak kewangan mengesahkan data2 tersebut dengan mengambilkira data random. Setelah agak lama, mereka dapati ageing yang dijana tidak betul. Saya terpaksa membetulkan hampir kesemua data yang telah dimigrate sebelum ini. Perkara seperti ini sering berlaku dimana vendor yang melakukan tugas2 ini kadangkala terlepas pandang. Masalah wujud dikemudian hari menyebabkan ramai yang menuding jari kepada pengguna dengan alasan mereka tidak menyemak data/m

Salam... Perbincangan dalam module Account Payable mengambil masa 10 hari. Module AP memerlukan penelitian yang tinggi supaya tidak ada tertinggal perkara2 yang penting. Tetapi, masalah dengan modul lain mula wujud bila ada maklumat/proses yang tidak dimasukkan semasa proses awal. Boleh di kategorikan banyak integrasi dengan modul lain dan sistem lain. Modul ini adalah nadi bagi sistem perakaunan. Laporan yang tepat dapat dihasilkan jika maklumat yang jitu dimasukkan disini. Pengolaan permintaan sehingga pelaksaan modul ini menunjukkan betapa pentingnya modul ini. --- sharing is caring ---

Salam.... Walaupun Purchase Order (PO) adalah modul yang senang kerana rentetan daripada modul PR, tetapi dengan kerenah user menjadikan sesi modul ini mengambil masa 3 hari untuk menyiapkannya. Semasa menyiapkan modul ini disiapkan, user banyak overlook (terlepas pandang) daripada pelbagai sudut. Kesannya, ada beberapa senario yang tidak dibincangkan secara mendalam. --- sharing is caring ---

Alhamdulillah... Dalam tempoh 2 hari, siap akhirnya BPA Review untuk module Purchase Requisition (PR). Masalah yang sering berlaku dan berlaku pada module ini adalah komitment daripada pihak user. Key roles user tidak join sesi ini. Only me yang membuat keputusan dan mencadangkan process flow yang terbaik pada department mereka. itulah masalah yang sering berlaku sesi requirement jika user tidak memberikan kerjasama yang baik. Pelbagai kemungkinan boleh berlaku jika masalah ini tidak dibendung diantaranya adalah user tidak akan bersetuju dengan BPA yang telah siap, semasa implementation ada perkara yang tidak diambil kira, user mohon change request yang banyak semasa proses implementation. Cara yang terbaik untuk menangani masalah seperti ini adalah, berharap user mengikut sahaja keputusan yang telah dibuat kerena masalah yang muncul berpunca daripada kesalahan mereka sendiri --- sharing is caring ---

Selepas 3 hari berhempas pulas menyiapkan fixed asset module ini, akhirnya module ni berjaya disiapkan dengan bantuan maklumat pihak user, pengolahan oleh pihak vendor dan semakan oleh saya. Module ini amat mudah jika dipandang secara terus, tetapi user telah menjadikan module ini sukar untuk ditafsirkan. Antara submodule yang disemak adalah: 1. Fixed Asset registration - GRN 2. Manual Registration through Asset Registration 3. Registration through Journal 4. Cost Acquisition adjustment 5. Depreciation / Ammortization 6. Depreciation adjustment 7. Asset transfer - accounting Semua submodule yang dibincangkan mengambil kira semua kemungkinan senario yang bakal berlaku  . --- sharing is caring ---

Alhamdulillah Akhirnya siap review untuk budget module. Kefahaman dan penelitian amat penting bagi menyiapkan sesebuah BPA. Untuk permulaan yang baik, pengertian, permintaan dan kefahaman daripada pihak user amatlah penting sebagai input kepada pihak vendor . Walaupun masa yang diambil terlalu lama, dan sesi ini lebih kepada user requirement session, tetapi kepuasan pelanggan daripada sesi ini bagi menyiapkan module ini amat penting. Subdmodule yang diambil kira semasa sesi Budget Module: 1. Budget Planning / Preparation 2. Budget Monitoring / Virement / Additional 3. Budget Forecasting --- sharing is caring ---

Alhamdulillah, akhirnya review telah dibuat. Budget module meliputi: Budget Planning / Preparation Budget Monitoring Budget Forecasting Tetapi hanya siap 2 submodule sahaja. Masa yang diambil untuk menyiapkan review ini 2 hari. Dapat disimpulkan bahawa 1 submodule = 1 hari. Lama kan, itu maknanya user requirement amat penting untuk memenuhi keperluan kedua-dua belah pihak. --- sharing is caring ---

Alhamdulillah….telah selesai review inventory management. Module yang paling asas dan penting dalam pembangunan system ini. Walaupun module ini Nampak mudah dan senang, tetapi kesannya boleh dilihat dalam module2 lain, inter related module. Siap module yang pertama.... --- sharing is caring ---

Vendor telah menjalakan tugas mereka untuk menyiapkan BPA documentation mengikut timeline yang dberikan. Tetapi format BPA berbeza2 mengikut penulis BPA. Saya mengambil keputusan untuk menyediakan BPA template yang perlu diguna pakai oleh semua author. Keputusan ini dipersetujui oleh kesemua pihak. --- sharing is caring ---

Salam... Baru2 ni saya dijemput untk menjadi konsultan bagi menyiapkan submodule stor. soalan yang ditanya adalah "mengapa submodule store perlu checking budget?" semua module perlu check budget kerana module budget adalah budget asas yang perlu ada. kaitan submodule store dengan module lain. beli barang (module perolehan / module budget)

Apakah yang dimaksudkan dengan project committee meeting? Apakah document yang diperlukan untuk meeting ini? Itulah kelemahan vendor ini kerana tidak paham/tidak dapat menyediakan document untuk sesi ini. Secara ringkasnya, dokumen yang diperlukan semasa meeting adalah: Agenda Minit meeting yang lepas Issue log Others matter Keputusan yang dapat dibuat semasa meeting ini akan dilengkapkan dengan agenda yang telah dibuat. Dengan kesemua dokumen ini, semua committee dapat mengetahui status projek atau kelemahan pengurusan projek yang sedang dibangunkan. Oleh yang demikian, walaupun sibuk dengan pengurusan projek yang lain, kita perlu juga menekankan dokumen yang diperlukan supaya kelancaran meeting ini selari dengan pengurusan projek yang sedang dijalankan. --- sharing is caring ---

Setelah berpenat-penat memikirkan pasal dokumen integration, akhirnya dokumen itu telah berjaya disiapkan. Dokumen integration yang disiapkan adalah: Integration Finance dengan Student billing Integration Finance dengan Payroll System Integration Finance dengan e-claim (staff portal) Integration yang penting adalah data yang perlu dihantar/diterima oleh sistem yang lain. Jika design yang dilakarkan adalah salah, menjadikan integration gagal dilaksanakan. Pada dasarnya, orang yang memainkan peranan adalah sistem analyst. Beliau yang perlu tahu penggunaan/db yang digunakan oleh kedua-dua belah pihak. Penghantaran/penerimaan data juga perlu diambil kira bagi memastikan data tersebut boleh digunapakai. --- sharing is caring ---

Pihak Vendor telah memilih untuk menggunkan sharepoint (office 365) team site sebagai platform bagi pembangunan sistem yang dijalankan. Pihak vendor memohon untuk mengemaskini semua maklumat dalam sharepoint. Tetapi pihak vendor tidak menyediakan tutorial/user manual. Selepas menggodek software sharepoint tersebut, akhirnya saya berjaya menyiapkan/mengemaskini sharepoint tersebut dengan jayanya. Konsep yang saya gunakan adalah konsep " try & error". Walaupun konsep ini salah, tetapi konsep berjaya menjadikan diri saya yakin dengan kemampuan saya dan saya boleh mengkategorikan diri saya sebagai " fast learner & willing to learn ". Selepas ini, saya hanya perlu mengupdate sharepoint dan memasukkan maklumat yang sepatutnya sahaja.

Alhamdulillah... Selama 1 bulan, sesi user requirement yang diadakan akhirnya selesai. Memang penat selama sesi ini dijalankan, malah banyak juga kerja backlog yang ada. Sesi ini merangkumi module: Budget Procurement AP AR General Ledger (GL) Project Accounting CRM (participants) Selain daripada module, sesi integration juga diadakan : Student Billing HR System Asset System Masalah yang wujud semasa sesi integration adalah: Misunderstanding antara department dengan department yang lain Kehendak dan process yang berlainan Vendor tidak memberi kerjasama

Hi, Salah satu step yang kritikal adalah untuk menyiapkan data migration. Nampak mudah dan senang disebut, tetapi implikasi yang besar akan berlaku dalam sistem baru yang sedang dibina. Apa yang berlaku sekarang adalah menyiapkan data vendor profile yang akan di migrate ke dalam sistem yang baru. Senario: 1. Setiap cawangan mempunyai vendor profile mereka yang tersendiri (setiap sistem cawangan adalah sistem sendiri/island sistem) 2. kemungkinan setiap cawangan akan berkongsi vendor yang sama Cara penyelesaian (yang dicadangkan) 1. Combine semua data vendor profile daripada semua cawangan, then migrate ke dalam sistem yang baru. Kemungkinan masalah yang berlaku: 1. Setaip vendor akan mempunyai creditor statement mereka. 2. Kod creditor setiap kampus adalah berlainan.  3. Jika semua vendor profile yang sama disatukan, perlu ada indicator bagi menyimpan vendor code yang lama bagi memudahkan carian dibuat.   Oleh yang demikian, system developer perlu mempunyai knowledge

Hi, Selepas sesi user requirement, saya dapat simpulkan bahawa user akan memberitahu system developer semua kehendak mereka. Kehendak mereka terdiri daripada normal flow, additional flow and exception flow. Masalah di sini adalah mereka tidak memberitahu system developer yang mana satu ada normal flow atau, additional flow atau exception flow. System developer pula tidak mengetahui untuk membezakan diantara business process and business system. Kadang2 masalah yang berlaku apabila kehendak yang diminta tidak mengikut process yang sebenar. Pada awalnya, semua user requirement perlu dicatatkan dan di analysis supaya maklumat tersebut dapat diterjemahkan. Tetapi selepas masalah ini wujud, semua yang dibuat akan jadi serba salah dan pending. Oleh itu, system developer perlu memahami business process bagi sesebuah organisasi, jangan bergantung harap kepada user requirement. Semua tindakan ini, perlu disusuli dengan pengurusan risiko supaya apa yang dirancangkan dapat dijalankan dengan

Hi, Dah masuk 3 minggu user requirement. Submodule yang dapat dibuat hanya 4/6 sahaja. Letih juga sesi ini. Dengan kehendak dan keperluan sistem dan juga business process. Submodule yang telah selesai dibincangkan: Budget Procurement Account Payable with PO / without PO Account Receivable

Hi, Hari ini adalah hari pertama sesi User Requirement BPA bagi submodule Budget. Banyak perkara yang perlu dibincangkan untuk mendapatkan keputusan yang jitu. Memang la semua manual proses perlu di automate kan tetapi persoalan kini adalah mampu ke sistem yang hendak dibangunkan ini mengikut proses kerja manual sekarang. Kadang2 keputusan perubahan cara kerja perlu dilakukan dengan segera supaya keputusan ini dapat dilakukan dengan segera. Walaubagaimanapun, proses kerja untuk submodule Procurement juga disentuh. Proses ini berkait dengan submodule Budget.

Setelah siap perbincangan mengenai proses pembelian (secara terus) dengan pengguna / user, hasil perbincangan telah ihasilkan. Hasil perbincangan ini juga perlu disahkan oleh pihak yang terlibat (pengguna perolahan, finance, Unit Aset). Selepas disahkan, pengguna dapat menyiapkan SOP unit dimana tally dengan sistem yang akan dibangunkan.

Pada hari Isnin (4/3/2013) telah diadakan kick off meeting untuk projek Sistem Kewangan. Banyak perkara yang dibincangkan diantaranya tentang milestone, project organisasi. Pada sesi akan datang, milsestone terperinci akan dibincangkan. Target Sistem Kewangan ini akan disiapkan dalam tempoh 6 bulan dari sekarang. Ini bermakna, sistem ini akan disiapkan pada awal bulan Oktober 2013. Saya berdoa dan berharap yang sistem ini dapat disiapkan mengikut jadual yang ditetapkan.

Pre - kickoff  meeting adalah satu langkah dimana sebelum kickoff meeting diadakan. Ia bertujuan untuk menentusahkan semua agenda perlu di selesaikan/dipersetujui sebelum kickoff di jalankan. Biasanya agenda untuk pre - kickoff dan agenda kickoff meeting adalah agenda yang sama tetapi agenda tersebut telah dimaklumkan dan pembetulan telah dilakukan mengikut persetujuan kedua-dua belah pihak.

Sekarang ni, saya lebih banyak menggunakan facility dropbox yang banyak membantu saya. Saiznya yang besar (2GB) dan boleh di access di mana menjadikan facility yang amat berguna. Selain itu, semua jenis fail boleh disimpan dan dikongsi bersama dengan orang lain. Ia juga selamat daripada virus dan juga kerosakan. Boleh cuba sekarang.

Sedang menyiapkan enhance project lain, saya sempat menyiapkan data setup untuk sistem stock control. Data yang lebih kemas dan tersusun. Kebanyakan maklumat ini, saya perolehi daripada carian di internet.

Kali ini, saya diberi tugasan untuk meng 'update' report menggunakan Oracle Report Builder. Tugasan ini memang mencabar kerana saya perlu mengetahui parameter yang digunakan dan hasil (output) yang dipaparkan.

Ni adalah salah satu ERP Accounting System yang telah saya buat. Design ini terhasil daripada perbincangan antara saya (SA) dan juga user. Integration juga dimasukkan dalam design ini bertujuan untuk mengetahui peringkat integration yang perlu dibuat.

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: Pendaftaran Aset / Inventori  Pengemaskini maklumat asset/inventori  Verifikasi / Pemeriksaan Pinjaman  Penyelenggaraan  Aduan  Pelupusan Pemindahan Aset / Inventori (yang melibatkan kewangan) SOP juga yang perlu disiapkan adalah: Pendaftaran Aset / Inventori  Pengemaskini maklumat asset/inventori  Verifikasi / Pemeriksaan Pinjaman  Penyelenggaraan  Aduan  Pelupusan 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

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 .  

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

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.

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

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 Adakah setiap data yang dibekalkan oleh organisasi mengikut template yang diberi? Adakah data tersebut dikaitkan dengan Setup? Adakah data setup tersebut adalah setup yang terkini? Adakah data yang diberikan benar-benar data yang sudah clean? Adakah data cleanup ini adalah tugasan pihak vendor/developer? Bagi soalan yang dinyatakan, kita mencuba untuk mengungkai jawapan tersebut 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. Bagi soalan ke 2 – kalau data yang dimasukkan berkaitan dengan setup, vendor/developer perlu memaklumkan kepada pengguna mengenai da

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 j

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.

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: Patch yang digunakan telah di update tanpa pengetahuan user Customization yang telah dibuat telah menganggu proses sedia ada 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.

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.   

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

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

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

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