「你們的系統多少錢？」 「看你要做哪種生意。」
這個回答聽起來像在打太極，但它其實是我們花了好幾年才學會的事。
電子發票這件事，在台灣是同一套法規、完全不同的生意。一家貿易商跟一個夜市攤位，都要開發票、都要符合財政部的規範，但他們需要的東西幾乎沒有重疊。
這篇講我們怎麼把一套電子發票系統，拆成一條可以自由組合的產品線。
一、先講問題：一套大系統，兩邊都不划算 #
早期的做法很直覺 —— 把所有功能做進同一套系統，客戶買了之後用得到哪些算哪些。
聽起來很大方，實際上兩邊都吃虧：
對客戶：一家只做 B2B 開票的貿易商，買到的系統裡塞著觸控結帳、開班結班、庫存扣減 —— 全部用不到，但這些功能的開發成本都攤在報價裡。
對我們：每加一個客戶，就多一組「他只用其中三成功能」的維護負擔。改一個共用的地方，要回歸測試所有人的情境。沒人用的程式碼不會自己消失，它會在每次改版時提醒你它還在。
更麻煩的是需求會互相打架。餐飲客戶希望結帳畫面越大按鈕越好、越少步驟越好；企業開票的客戶希望欄位齊全、可查可改、有稽核紀錄。這兩種需求放進同一個畫面，只會兩邊都不好用。
二、怎麼拆：先找出真正的分界線 #
拆模組最容易犯的錯，是照技術結構拆（前端一包、後端一包、報表一包）。這種拆法對工程師有意義，對客戶沒有 —— 客戶沒辦法從「我要買前端」開始思考。
我們最後找到的分界線是兩個問題：
- 你開哪一種發票？ → 決定前台
- 你要管哪一種生意？ → 決定後台
依這兩個問題，整條產品線長這樣：
三種開票前台 #
| 前台 | 開什麼票 | 典型使用者 |
|---|---|---|
| 企業開票端 | B2B / B2G、折讓單、空白發票申報 | 貿易商、製造業、對政府機關開票的廠商 |
| 零售門市開票端 | B2C 收據、買方統編、載具 | 攤位、夜市、市集、文創展售、門市 |
| 餐飲點餐開票端 | B2C 收據，點餐流程整合 | 餐飲店、小吃店 |
三種營運後台 #
| 後台 | 管什麼 |
|---|---|
| 零售商品中樞 | 商品、庫存、進銷貨 |
| 餐飲營運中樞 | 菜單、品項、餐飲營運 |
| 總部中樞 | 多點統整、跨店報表 |
客戶挑自己需要的組合就好。 只做 B2B 的，買企業開票端，後台可以完全不要；夜市攤位要零售前台加商品中樞；連鎖餐飲則是餐飲前台配餐飲中樞再加總部中樞。
這個拆法的關鍵，不在於模組切得多細，而在於分界線是用客戶的語言定義的。客戶不需要理解我們的技術架構，只要回答「我開哪種票、做哪種生意」。
三、共用的地方要共用，不共用的不要硬湊 #
拆成產品線之後，最危險的誘惑是「既然都拆了，那全部都做成可設定的」。
我們的原則很簡單：法規要求的東西共用，生意邏輯的東西不共用。
必須共用（因為法規只有一套）：
- MIG 4.1 的 XML 產生與驗證
- 字軌號碼管理與追蹤
- 作廢、註銷、折讓的處理規則
- 上傳與回執的處理
這一層做錯，是全部客戶一起出事，所以它只能有一份實作、一份測試。法規會改，改的時候我們只想改一個地方。
堅持不共用（因為每種生意本來就不同）：
- 結帳畫面與操作流程
- 商品／菜單的資料模型
- 報表的呈現方式
餐飲的「品項」跟零售的「商品」看起來很像，硬做成同一個抽象只會兩邊都彆扭。寧可兩份清楚的實作，不要一份到處都是條件判斷的萬用實作。
四、兩個逆向的產品決策 #
拆產品線的過程中，有兩個決定跟現在的主流做法是反的。
決策一：離線桌面，不做 SaaS #
現在幾乎所有系統都往雲端走。我們的開票端反而堅持離線桌面應用。
理由很實際：開發票不能因為網路斷線就停擺。 客人在櫃檯前面等，網路剛好不通，這個情境是不能接受的。發票開立本身完全在本機完成，上傳是另一件事、可以稍後補。
也因為離線，我們提供三種彈性的上傳方式（本機 Turnkey、遠端 SMB／FTP、CSV 匯出），客戶依照自己的 IT 環境挑一種，不必為了配合系統去改網路架構。
決策二：一次買斷，不收月費 #
訂閱制對廠商是更好的商業模式，這點我們很清楚。但對台灣中小企業，每個月固定扣款是一個心理門檻，尤其是開發票這種「本來就該有」的基礎功能。
一次買斷讓客戶算得出總成本，也讓我們少掉一整套帳務與催繳流程。我們寧可把力氣花在系統本身。
五、模組化真正的成本 #
講完好處，也講代價 —— 產品線不是免費的。
測試矩陣會變大。 三前台配三後台，加上不同的上傳方式，組合數比單一系統多得多。我們的做法是把共用層（法規那一層）的測試做厚，組合層只驗介面接得起來，不重複驗法規邏輯。
文件與教育訓練要跟著拆。 客戶只買了兩個模組，就不該收到一本包含所有功能的手冊 —— 那只會讓他覺得「我是不是買少了」。
報價要說得清楚。 模組化的副作用是報價變複雜。我們的處理方式是先問清楚生意型態，直接給對應組合的價格，而不是丟一張模組價目表讓客戶自己加總。
六、這個思路不只適用於電子發票 #
如果你手上的系統有這些症狀，可能也到了該拆的時候：
- 不同客戶用的功能重疊度很低，但買的是同一套
- 兩種客戶的需求在同一個畫面上互相打架
- 改一個共用的地方，要回歸測試一堆不相干的情境
- 報價很難解釋，因為裡面包了客戶用不到的東西
拆的時機比拆的方法重要。 太早拆，會為了還不存在的客戶做抽象，白做工；太晚拆，共用的地方已經纏在一起，拆的成本會高得嚇人。
我們的判斷是：同一個功能出現第三種明顯不同的用法時，就該認真考慮拆了。 一種是特例，兩種可以用條件判斷擋著，三種代表這是結構性的差異，不是例外。
想知道你的情況該用哪個組合、或現有系統值不值得拆，直接跟我們說你的生意型態就好 —— 通常聊十分鐘就能判斷。