Qaisa - Notes and Guides

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