把老闆的點子變成系統：產品數位化的真實流程

會議室裡，老闆畫了一張流程圖，講了十分鐘他腦中的系統該長什麼樣子。工程師點點頭，兩週後拿出一個東西：功能都有，邏輯卻完全不是那回事。老闆看著畫面，說不出哪裡不對，只覺得「這不是我要的」。工程師也很委屈，他確實照著會議紀錄做的。

這個場景在中小企業做產品數位化的過程中反覆上演。問題不在老闆不會表達，也不在工程師不夠專業，而是「點子」跟「系統」中間，本來就隔著好幾層轉譯，而大部分企業沒有人負責做這件事。

點子跟系統之間，其實隔著三層轉譯

老闆腦中的點子通常是一個商業邏輯：「客戶下單後，我想自動通知倉庫，然後庫存要扣掉，缺貨要提醒業務。」這句話聽起來很清楚，但要變成系統，中間要經過三層轉譯。

第一層是流程釐清：下單的定義是什麼？是客戶按下確認鍵那一刻，還是業務手動核准之後？如果同一時間兩個人下單同一批僅存的貨，系統該怎麼處理？這些問題老闆通常沒想過，因為在人工作業時，這些例外情況是靠員工的經驗即時判斷的，沒有人寫成規則。

第二層是資料結構設計：庫存要怎麼存、單位是什麼、跟哪些系統要串接、歷史紀錄要保留多久。這一層決定系統未來好不好維護、能不能擴充，但老闆完全看不到，也不會意識到這一步存在。

第三層才是工程實作：選什麼技術、怎麼寫程式、介面長什麼樣子。多數企業以為系統開發只有這一層，於是把點子直接丟給工程師，跳過前兩層，讓工程師自己猜、自己補洞。做出來的東西自然對不上老闆的想像，因為工程師補的洞，跟老闆腦中沒說出口的假設，常常是兩件事。

中間卡住的位置，決定了系統會出什麼問題

不同階段出問題，症狀完全不一樣，判斷卡在哪一層，比急著換工程師更重要。

大部分企業主抱怨「系統做不出我要的東西」時，其實卡在第一、第二層，而不是工程師的技術能力。找一個只會寫程式的人來救火，通常只是換一批人重新踩同樣的坑。

產品數位化該怎麼分階段做，才不會走回頭路

比較務實的做法，是把「點子變系統」拆成幾個明確階段，每個階段都要有產出，而不是直接跳進開發。

先做流程梳理，把現有的人工作業攤開來，寫成文字或流程圖，標出所有的例外情況跟判斷邏輯。這一步不需要工程師參與，但需要對業務現場夠熟的人主導，通常是主管或有經驗的第一線人員。

接著做系統規劃，把流程圖轉成資料結構跟功能清單，決定哪些是第一版必須有的核心功能，哪些可以之後再加。這一步最容易被跳過，但決定了系統未來三年好不好用。

開發跟測試緊接在後，而且測試不該只有工程師自己測，一定要拉業務現場的人一起走一遍實際情境，尤其是那些「萬一」的例外狀況。

什麼樣的點子，適合先做小範圍驗證

不是每個點子都值得一開始就做完整系統。如果這個點子牽涉到多個部門、資料量大、影響到核心營收流程，值得花時間做完整的流程梳理跟系統規劃。但如果只是想測試一個新做法可不可行，例如換一種客戶通知方式、試一個新的排班邏輯，先用小範圍、限定人數的原型跑一到兩個月，確認邏輯真的順了，再投入完整開發，會比一次到位划算得多。

判斷的關鍵不是點子大小，而是「如果做錯了，重來的成本有多高」。重來成本低的，先做小範圍驗證；重來成本高的，值得多花一到兩週做完整的流程梳理再動工。這一步多花的時間，通常會在後面省下數倍的返工成本。