Dari mana nak mula bila sistem bisnes dah serabut?

Mulakan dengan keputusan yang sistem patut sokong, bukan senarai feature baru. Bila staf tanya siapa boleh approve order, saya akan semak siapa yang buat keputusan dan kesannya pada duit, keadaan mana boleh diubah, serta bukti kerja yang berlaku. Ujian Tiga Penjuru membantu anda tapis punca sebelum pilih untuk jelaskan proses atau ubah software.

Situasi

Owner masih perlu jawab soalan staf walaupun sistem dah digunakan. Staf tanya siapa boleh approve order yang luar dari kebiasaan, tapi jawapannya berubah ikut siapa yang ditanya. Report pula tidak sepadan dengan apa yang owner sangka berlaku. Owner mungkin terus minta feature baru atau tukar software sebelum keputusan di belakang kerja itu jelas.

Ujian Tiga Penjuru

1. Peraturan sebelum software. Siapa yang buat keputusan, bila, dan apa kesannya pada duit? Kalau jawapannya tak jelas, sistem akan jadi tempat dua orang bertengkar.
2. State sebelum skrin. Apa state sebenar, dan siapa yang boleh mengubahnya? Kalau tak jelas, skrin nampak siap tetapi data tak boleh dipercayai.
3. Bukti sebelum pendapat. Apa yang sebenarnya berlaku, bukan apa yang orang rasa? Kalau tak jelas, kita baiki bahagian yang salah dan ulang kerja.

Ini filter masalah, bukan flow projek. Anda tidak perlu anggap setiap masalah mesti bermula pada penjuru pertama dan berakhir pada penjuru ketiga. Gunakan soalan yang berkaitan dengan kekusutan di depan anda.

Kalau staf tunggu owner untuk buat keputusan, semak peraturan. Kalau dua orang baca status yang sama dengan maksud berbeza, semak state/keadaan. Kalau perbincangan bermula dengan “rasanya dah buat”, semak bukti.

1. Kekusutan: ambil masalah yang sedang mengganggu kerja, lalu semak sama ada rule keputusan jelas.
2. Rule: kalau keputusan belum jelas, mula di sini. Kalau jelas, semak state/keadaan.
3. State/Keadaan: kalau perubahan state/keadaan belum tracked, mula di sini. Kalau sudah, semak bukti.
4. Bukti: kalau bukti belum cukup, mula di sini sebelum memilih perubahan software.

Apa yang rosak kalau salah

Bila keputusan siapa boleh approve order belum kita set, staf akan tanya owner setiap kali ada pengecualian. Masalah ini mudah disalah faham sebagai weakness software, jadi owner minta butang “approve”. Butang itu tidak menetapkan siapa berkuasa membuat keputusan, pertikaian yang sama cuma berpindah ke dalam sistem.

Label “success” boleh dibaca sebagai kerja sudah siap oleh seorang staf, tetapi sebagai bayaran sudah diterima oleh staf lain. Kedua-duanya merujuk pada state/keadaan yang sama walaupun maksud berbeza. Report jadi sukar dipercayai, dan orang terpaksa menyemak semula apa yang sebenarnya berlaku sebelum membuat keputusan.

Apa yang nota ini tidak cover

• Cara menetapkan setiap rule operasi. Ujian ini hanya tunjukkan soalan yang perlu dijawab, bukan tetapkan siapa patut ada kuasa buat keputusan dalam bisnes anda. Kesan pada duit juga bergantung pada cara bisnes itu bekerja.
• Reka bentuk penuh state/keadaan dan database. Beza maksud state/keadaan adalah langkah awal. Nota ini tak menentukan semua perubahan state yang dibenarkan atau macam mana rekod patut disimpan.
• Cara audit setiap report. “Bukti” di sini bermaksud semak apa yang berlaku sebelum baiki sesuatu. Ia bukan jaminan yang semua data sedia ada tepat atau lengkap.
• Keputusan untuk tukar software. Ada keadaan di mana software sedia ada memang tidak sesuai. Ada juga keadaan di mana kejelasan proses dan rule sudah memadai. Ujian ini tidak buat keputusan itu bagi pihak anda.
• Pelan development. Selepas punca lebih jelas, masih perlu menilai skop, kos, risiko dan apa yang patut dibuat dahulu. Jangan jadikan tiga penjuru ini sebagai senarai feature.

Kalau selepas tapis masalah anda masih perlukan custom system, Hubungi Saya Jom sembang dengan keputusan dan workflow yang perlu disokong.

Glosari

Guna semula: Anda boleh guna rajah, jadual atau senarai dalam nota ini dengan atribusi.

Contoh: "Sumber: HamizulFaiz, Dari mana nak mula bila sistem bisnes dah serabut? (Di Sebalik Sistem), hamizulfaiz.my".