Jangan Terus Bina Sistem. Faham Dulu Flow Yang Nak Diselesaikan

Ada satu benda yang saya perasan bila tengok orang bincang pasal teknologi, bisnes dan software.

Bila ada masalah dalam bisnes, kita cepat sangat lompat kepada solution.

“Bisnes aku tak teratur. Kena buat system.”

“Staff selalu buat silap. Kena buat app.”

“Sales slow. Kena buat website.”

“Customer banyak tanya benda sama. Kena buat chatbot.”

Benda-benda tu mungkin betul.

Tapi mungkin juga tak.

Sebab kita terus lompat daripada masalah kepada solution, tanpa faham apa yang berlaku di tengah-tengah.

Dan bagi saya, ini antara sebab kenapa banyak software yang cantik akhirnya tak banyak membantu bisnes.

---

Saya teringat pasal hydrogen untuk kereta

Kebelakangan ni saya banyak nampak content pasal hydrogen assist untuk kereta.

Ada orang kata hydrogen boleh bantu pembakaran.

Ada yang kata boleh jimat minyak.

Ada yang kata semua tu scam.

Ada pula yang tunjuk test sendiri dan nampak macam memang ada perubahan.

Kalau tengok sepintas lalu, memang senang untuk pilih satu side.

“Hydrogen memang tipu.”

atau

“Hydrogen memang jimat minyak.”

Tapi benda sebenar lebih menarik daripada dua jawapan tersebut.

Hydrogen memang boleh mempengaruhi proses pembakaran enjin.

Dalam keadaan tertentu, hydrogen boleh membantu mempercepatkan flame propagation, meningkatkan combustion stability dan membolehkan enjin beroperasi pada campuran yang lebih lean.

Jadi, mechanism itu memang wujud.

Tetapi itu tidak bermaksud setiap hydrogen generator yang dipasang pada kereta akan terus menghasilkan fuel saving.

Sebab ada satu lagi perkara yang perlu dikira.

Kalau kita menghasilkan hydrogen menggunakan elektrik daripada alternator:

engine → alternator → electricity → electrolyzer → hydrogen → engine

kita sebenarnya mengambil tenaga daripada engine untuk menghasilkan hydrogen dan memasukkan hydrogen itu semula ke engine.

Jadi soalan yang betul bukan:

“Hydrogen boleh bantu pembakaran atau tak?”

Soalan yang lebih betul ialah:

“Dalam keseluruhan system ini, adakah improvement daripada hydrogen lebih besar daripada tenaga yang digunakan untuk menghasilkan hydrogen tersebut?”

Itu soalan yang jauh lebih susah.

Dan jauh lebih berguna.

---

Ini sebenarnya masalah yang sama dalam software

Bila customer datang dan cakap:

“Saya perlukan system.”

Saya tak rasa itu sebenarnya requirement.

Itu adalah solution yang customer dah pilih.

Requirement sebenar mungkin masih belum diketahui.

Contohnya customer kata:

“Saya nak system untuk manage order.”

Okay.

Tapi apa yang sebenarnya berlaku sekarang?

Mungkin flow dia:

Customer WhatsApp
↓
Sales reply
↓
Customer bagi order
↓
Sales tulis dalam notebook
↓
Sales forward kepada admin
↓
Admin masukkan Excel
↓
Warehouse tengok Excel
↓
Barang disediakan
↓
Customer buat payment
↓
Admin update Excel lagi
↓
Sales inform customer

Kemudian customer kata:

“System sekarang ni tak efficient.”

Betul.

Tapi apa masalah sebenarnya?

Adakah masalahnya tiada system?

Tidak semestinya.

Masalah mungkin:

• data dimasukkan banyak kali
• tiada single source of truth
• ownership setiap step tak jelas
• status order tidak standard
• sales dan admin menggunakan data yang berbeza
• warehouse hanya mengetahui order selepas admin update
• payment tidak dikaitkan dengan order
• terlalu banyak kerja manual

Bila kita nampak flow itu, baru kita boleh decide software macam mana yang diperlukan.

---

Masalah sebenar bukan selalu “tak ada system”

Ini perkara yang saya rasa paling penting.

Software bukan business process.

Software cuma satu cara untuk menjalankan atau mengawal business process.

Kalau business process tak jelas, software tak akan magically mencipta process yang baik.

Ia cuma akan digitalize kekeliruan yang sedia ada.

Contohnya sekarang staff buat:

“Bila customer bayar, inform admin.”

Kita buat system.

Lepas payment:

“Click button untuk mark as paid.”

Nampak macam dah improve.

Tapi kemudian kita jumpa masalah baru.

Siapa yang patut verify payment?

Kalau payment gagal?

Kalau customer bayar kurang?

Kalau customer bayar lebih?

Kalau customer bayar tetapi order dibatalkan?

Kalau refund?

Kalau payment masuk tapi staff terlupa update?

Sekarang kita mula sedar bahawa masalah sebenar bukan button “Paid”.

Masalah sebenar ialah payment flow.

---

Flow lebih penting daripada feature

Ini sebab saya lebih suka tanya:

“Apa yang berlaku sekarang?”

berbanding:

“Feature apa yang awak nak?”

Feature biasanya datang daripada assumption.

Flow datang daripada real operation.

Contohnya:

Customer minta quotation.

Apa berlaku selepas itu?

Quotation dibuat.

Siapa buat?

Berapa lama?

Customer approve macam mana?

Deposit diperlukan?

Siapa verify?

Bila deposit diterima, siapa assign kerja?

Bila kerja selesai, siapa keluarkan invoice?

Siapa collect balance?

Bila commission dikira?

Bila staff dianggap selesai?

Bila customer dianggap selesai?

Bila business dianggap selesai?

Itulah flow.

Dan daripada flow itu, kita boleh nampak state, transition, ownership, dependency dan failure point.

Barulah architecture mula masuk akal.

---

Architecture bukan sekadar database table

Bila developer dengar perkataan architecture, kadang-kadang terus fikir:

Laravel.

Microservices.

Redis.

Queue.

Docker.

API.

Database.

Itu semua adalah technical architecture.

Tetapi sebelum technical architecture, ada satu benda yang lebih penting:

Business architecture.

Kita perlu faham:

• siapa melakukan apa
• bila ia dilakukan
• data apa yang diperlukan
• siapa yang memiliki data tersebut
• apa yang menyebabkan sesuatu status berubah
• apa yang berlaku apabila sesuatu gagal
• siapa yang perlu diberitahu
• apa output setiap proses

Contohnya satu Order bukan sekadar:

orders
- id
- customer_id
- amount
- status

Kalau business flow sebenar ialah:

Draft
 ↓
Submitted
 ↓
Reviewed
 ↓
Approved
 ↓
Payment Pending
 ↓
Paid
 ↓
Processing
 ↓
Completed

maka status itu bukan sekadar field/column.

Ia adalah business state machine.

Setiap transition ada rule.

Contohnya:

Submitted → Approved

mungkin hanya boleh dilakukan oleh manager.

Approved → Payment Pending

berlaku secara automatik.

Payment Pending → Paid

hanya selepas payment disahkan.

Paid → Processing

hanya apabila warehouse menerima order.

Itulah architecture yang lahir daripada pemahaman flow.

Bukan daripada senarai feature.

---

Jangan automate masalah yang belum difahami

Ini mungkin rule yang paling saya suka.

Jangan automate sesuatu yang kita sendiri tak faham.

Kalau sekarang staff mengambil masa 3 jam untuk buat sesuatu kerja, jangan terus assume:

“Kita buat software, mesti jadi 5 minit.”

Tanya dulu:

Kenapa 3 jam?

Mungkin 2 jam daripada 3 jam itu hanya menunggu approval.

Kalau begitu, software bukan penyelesaian utama.

Kita mungkin perlu ubah approval process.

Atau mungkin staff perlu copy data dari lima tempat.

Maka software boleh membantu.

Atau mungkin kerja itu memang memerlukan physical inspection.

Maka software mungkin hanya boleh mengurangkan paperwork, bukan menghapuskan kerja tersebut.

Kalau kita tak faham punca, kita mungkin membina software yang menyelesaikan masalah yang salah.

---

Ini juga berlaku bila orang nak buat website

Contoh paling mudah:

“Saya nak website sebab sales tak banyak.”

Okay.

Website mungkin membantu.

Tapi kenapa sales tak banyak?

Adakah:

• orang tak tahu produk?
• traffic terlalu sedikit?
• offer tak menarik?
• trust rendah?
• customer tak faham produk?
• sales team lambat reply?
• harga terlalu tinggi?
• targeting salah?
• customer banyak tetapi conversion rendah?

Website hanya boleh menyelesaikan sebahagian daripada masalah tersebut.

Kalau masalah sebenar ialah:

1,000 orang masuk tetapi hanya 3 orang bertanya,

maka kita ada conversion problem.

Kalau:

10 orang sahaja masuk,

kita ada traffic problem.

Kalau:

100 orang bertanya tetapi sales team hanya follow up 20 orang,

kita mungkin ada operation problem.

Tiga-tiga business tersebut boleh berkata:

“Saya perlukan website.”

Tetapi architecture solution mereka mungkin sangat berbeza.

---

Sistem yang baik sebenarnya mengawal output

Saya rasa ini cara paling mudah untuk melihat nilai software.

Business biasanya perlukan sesuatu output.

Contohnya:

Order diterima dengan betul.

Payment collected.

Customer mendapat service.

Stock sentiasa accurate.

Commission dikira dengan betul.

Management boleh nampak keadaan operasi.

Software yang bagus bukan sekadar memberikan user tempat untuk click button.

Ia membantu memastikan output tersebut menjadi lebih predictable.

Contohnya tanpa system:

Customer
   ↓
Staff A
   ↓
WhatsApp
   ↓
Staff B
   ↓
Excel
   ↓
Staff C
   ↓
Customer

Banyak tempat untuk process itu rosak.

Dengan architecture yang betul:

Input
  ↓
System
  ↓
Validation
  ↓
Business Rules
  ↓
Workflow
  ↓
Output

Sekarang kita boleh control apa yang berlaku.

Kita boleh enforce rules.

Kita boleh record history.

Kita boleh detect failure.

Kita boleh measure performance.

Itulah nilai sebenar system.

---

Tapi ada satu lagi perangkap

Kadang-kadang kita terlalu obses dengan automation.

Semua benda nak automate.

Padahal automation bukan sentiasa jawapan terbaik.

Contohnya satu process berlaku 10 kali sebulan.

Staff ambil masa 5 minit setiap kali.

Jumlah masa:

50 minit sebulan.

Kalau nak buat system bernilai RM20,000 semata-mata nak jimatkan 50 minit sebulan, mungkin itu bukan keputusan yang bagus.

Sebaliknya, process lain mungkin berlaku:

500 kali sehari.

Setiap transaction mempunyai risiko error.

Di situ automation mungkin sangat bernilai.

Sebab itu saya tak suka melihat software berdasarkan:

“Feature ini cool.”

Saya lebih suka tengok:

“Berapa banyak friction, cost, risk atau inconsistency yang kita remove?”

---

Informed decision vs assumption

Bagi saya, inilah perbezaan besar.

Assumption

“Bisnes saya bermasalah. Saya perlukan system.”

Informed decision

“Dalam proses order, data dimasukkan sebanyak tiga kali. 8% order mempunyai discrepancy. Staff mengambil purata 12 minit untuk reconcile setiap order. Saya perlukan system untuk mengurangkan duplicate entry dan enforce validation.”

Yang kedua jauh lebih kuat.

Sebab sekarang kita tahu:

Apa masalahnya.

Di mana ia berlaku.

Kenapa ia berlaku.

Apa yang software perlu buat.

Dan paling penting:

Apa yang kita akan ukur selepas system dibina.

---

Ini juga mengubah cara kita ukur success

Kalau assumption kita:

“Kita dah launch system.”

Maka system dianggap berjaya apabila:

“System dah live.”

Itu bukan business success.

System boleh live dan business masih sama.

Kalau kita faham mechanism, kita boleh define outcome.

Contohnya sebelum system:

• order processing: 15 minit
• error rate: 8%
• reconciliation: 2 jam sehari
• report: setiap hujung minggu
• stock update: 1 hari lewat

Selepas system:

• order processing: 5 minit
• error rate: <2%
• reconciliation: 20 minit sehari
• report: real-time
• stock update: immediate

Sekarang kita boleh tanya:

“Adakah system itu berjaya?”

Jawapannya boleh diukur.

Bukan berdasarkan rasa.

---

Balik kepada hydrogen tadi

Sebab itu saya rasa contoh hydrogen ini menarik.

Kita boleh tengok satu technology dan terus membuat kesimpulan.

“Hydrogen jimat minyak.”

Tetapi bila kita buka flow sebenar:

Fuel
 ↓
Engine
 ↓
Mechanical energy
 ↓
Alternator
 ↓
Electricity
 ↓
Electrolysis
 ↓
Hydrogen
 ↓
Engine

kita mula nampak soalan yang perlu dijawab.

Berapa banyak hydrogen dihasilkan?

Berapa banyak electricity/power diperlukan?

Berapa banyak energy terkandung dalam hydrogen?

Apa effect hydrogen terhadap combustion?

Adakah engine berubah operating condition?

Adakah ECU compensate?

Berapa banyak fuel saving diperlukan untuk break even?

Sekarang kita bukan lagi bercakap berdasarkan:

“Saya tengok orang buat.”

Kita sedang bercakap berdasarkan mechanism.

Dan benda yang sama patut dilakukan dalam business.

---

Jangan bina system kerana bisnes “nampak perlukan system”

Bina system apabila kita faham apa yang system itu perlu ubah.

Saya tak rasa semua business perlukan software.

Ada business yang cuma perlukan SOP.

Ada yang perlukan training.

Ada yang perlukan seorang lagi staff.

Ada yang perlukan process yang lebih simple.

Ada yang perlukan automation.

Dan ada yang memang perlukan custom system.

Tetapi kita hanya boleh bezakan semua itu apabila kita faham flow.

---

Software bukan magic

Saya suka software.

Saya suka bina system.

Tapi sebab itulah saya rasa kita kena berhati-hati dengan software.

Software sangat powerful.

Kita boleh ambil process yang berlaku 1,000 kali dan automate.

Kita boleh ambil data daripada pelbagai tempat dan jadikan satu source of truth.

Kita boleh enforce rules.

Kita boleh eliminate human error.

Kita boleh measure operation.

Tetapi software juga boleh mengambil process yang buruk dan menjadikannya lebih susah untuk diubah.

Kalau process yang salah sudah dimasukkan ke dalam system, setiap staff akan ikut process yang salah itu dengan lebih konsisten.

Jadi sebelum kita tanya:

“System apa yang kita nak buat?”

Saya rasa soalan yang lebih baik ialah:

“Apa sebenarnya yang berlaku dalam business kita sekarang?”

Lepas itu:

“Di mana output mula rosak?”

Kemudian:

“Kenapa ia rosak?”

Dan barulah:

“Adakah software merupakan cara terbaik untuk memperbaikinya?”

Kalau jawapannya ya, barulah kita bina.

Bukan sebab kita rasa kita perlukan system.

Tetapi sebab kita faham mekanisma yang sistem perlu kawal.

Dan pada saya, itu perbezaan antara:

membina software

dengan

membina system yang benar-benar membantu business.