每個選擇都有道理，未來卻可能沒留下位置

看完伯利恆鋼鐵的影片，再想到之前看的 Walmart 與 Kmart 的討論，我在意的不是誰比較聰明，而是：我們說一門生意不值得做，究竟是需求不足，還是自己的做法做不起來？

鋼鐵案例裡，大型鋼廠把資源留給利潤更好的市場，有它的道理。小鋼廠卻用不同的製程與成本結構，從較低階的市場累積能力，再逐步往上走。這是Christensen Institute 對小鋼廠發展的分析，不是伯利恆興衰的全部解釋。

Walmart 讓我想到另一面：如果只看一間小鎮門市，可能覺得規模不夠；但門市背後還有共用的採購、配送與營運能力。它不是只把價格壓低，而是建立能支撐低價的做法。Walmart 的年報也把天天低價與天天低成本分開說明。

兩個故事不能當成相同的失敗公式。但它們讓我把問題帶回 metabiz：小公司真的用不起好的系統，還是我們仍然用服務大型專案的方式，來服務每一家小公司？

SaaS 本來就在解決這件事

如果每個客戶都得重新訪談、設計、開發、測試，再獨自承擔維護，成本當然不低。

SaaS 的意義，就是讓多個客戶使用共用的產品能力，把開發、維護與更新的投入分攤出去。客戶不必為了使用一套成熟功能，就先付出從零打造它的成本。

這是我覺得 SaaS 與 Walmart 可以放在一起理解的地方：個別客戶或門市規模不大，不代表背後只能使用一套小而不成熟的能力。

但買了 SaaS，也不代表事情就完成了。

會員在一套系統，訂單在另一套，現場又有自己的做法。功能各自能用，實際工作卻可能還是要靠人搬資料、核對和追問。

如果為了解決這個落差，又為每個客戶重做整套系統，剛才省下來的成本，很可能又花回去。

共通的不要重做，差異的才投入

metabiz 想走的方向，是用 SaaS 提供成熟的共用能力，用 AI EDP 接起完成工作所需的資料與流程，再由 AI 輔助的 FDE，處理客戶真正不同的地方。

AI EDP 不要求把原本能用的 POS、ERP 或 CRM 全部換掉。先選一段工作，確認資料從哪裡來、送到哪裡、何時交換，以及出錯由誰處理，再把需要的部分接起來。

FDE 則不是工程師拿到文件後才開始寫程式，而是更直接接近客戶的工作，理解問題、實作，再確認結果能不能用。

例如，客戶需要的可能不是再多一張報表，而是每天不用花時間對照兩套訂單。那就應該先確認這段核對能不能減少、資料不一致時怎麼處理，而不是只展示新的畫面能跑。

這是說明做法的例子，不是我們已完成的客戶成效。

AI 可以協助整理、開發與檢查，但不能讓責任消失。需要確認的承諾、資料權限、例外與驗收，仍然要留下來。工程師直接處理比較快，也不該變成所有問題都靠他默默補救。

做完一次，下一次不能又從零開始

FDE 如果最後只是替每個客戶做一套全新的客製系統，仍然沒有解決成本問題。

我更在意的是：這次做過的連接方式，能不能變成可沿用的模組？遇過的錯誤，有沒有留下測試？釐清過的交付方法，下次是不是不用再靠同一個人解釋？

共用的是方法、工具與能力，不是把客戶資料混在一起。

大型專案不是不好，客製也不是不應該。有些差異確實值得投入。但不需要每個客戶都重新負擔共通部分的建置成本。

這也回到今天文章原本的問題。

眼前有收入的案子要完成，但如果所有時間都用在下一次仍得重做的工作，共用能力就永遠只能等忙完再整理。每一次選擇都有理由，放在一起，卻可能讓我們一直停在同一種交付方式。

我想留給未來的位置，不只是多做一個新產品，而是讓今天替客戶完成的工作，也能讓下一次服務更成熟。

有沒有真的做到，不能只看用了多少 AI，或程式產生得多快。要回頭看交付工時、返工、維護負擔，以及客戶原本想完成的事情，有沒有完成。

小公司不需要一套縮水的大型專案。它需要的是，在負擔得起的投入裡，把重要的工作做好。

— Adam｜metabiz 創辦人

延伸參考：理性避難所｜伯利恆鋼鐵・Walmart 與 Kmart