DMBot onepage/ FDE × SI
WORK MODEL · FIELD NOTE
FDE 與 SI 的差異：關鍵不是駐點，而是能否把客戶問題變成產品能力
兩者都可能訪談客戶、進入真實環境、整合系統、客製化與寫程式。真正的分水嶺是：誰定義問題、交付後知識往哪裡流，以及下一個客戶是否因此更容易成功。
Published: 2026-08-14Format: ChatGPT shareTopic: FDE / SI
01 / 起點
需求，還是問題？
SI 常從「要做什麼」開始；FDE 應從「為何要做、成功如何衡量」開始。這不是話術，而是後續範圍、架構與取捨的決策權。
02 / 交付
專案，還是價值？
SI 的自然終點是驗收、上線或維運；FDE 對結果負責，會把 adoption、流程改變與可量測商業價值納入工作定義。
03 / 複利
客製，還是抽象？
一次性客製可以很有價值，但若每個案子都重新發明，第十一個客戶不會變容易。FDE 的核心回路是把重複模式帶回平台。
Key signals
別被相似的工作表象騙了
Surface
都會駐點
走進客戶現場不是 FDE 的充分條件；SI 也會做 discovery、整合與 deployment。
Authority
能重問題
FDE 必須能把「做 A」重述為「想解 B」，並用證據驗證 A 是否真是好方法。
Output
可衡量價值
不只交付功能，還要對採用、流程與業務結果建立可檢驗的成功定義。
Loop
回到產品
從客戶特殊情境找出共通 workflow、tooling 或 capability，讓下一次交付更快。
Decision rights
真正差異在決策權，而非職稱
SI
把明確需求可靠地做完
傳統 SI 的強項是按客戶定義的範圍，交付系統、串接既有環境、管理專案風險並支撐後續維運。它不是較低階的工作，而是有清晰商業邏輯的交付模式。
FDE
在模糊現場縮小「正確問題」
真正的 FDE 不把需求照單全收：先做 discovery、technical scoping 與 sequencing，理解限制與工作流，再用公司的平台能力建出能進 production 的解法。
風險
名片是 FDE，流程卻仍是 SI
如果角色沒有質疑需求的空間、不能調整範圍、也沒有把現場經驗回饋產品的管道，最終很可能只是「PM → 客製化工程師 → 駐點維運」的換名版本。
Comparison
用四個面向看清楚分野
第一個問題SI：你要做什麼？
FDE：你為什麼要做？不做的成本是什麼？
FDE：你為什麼要做？不做的成本是什麼？
成功定義SI：功能、時程、驗收與 SLA。
FDE：加上 adoption、流程改善與可量測的 business outcome。
FDE：加上 adoption、流程改善與可量測的 business outcome。
客製化的去向SI：以當前客戶的交付為中心。
FDE：辨識可重用的 abstraction，推回產品、工具與標準做法。
FDE：辨識可重用的 abstraction，推回產品、工具與標準做法。
規模化方式SI：擴大專案與人力的交付能力。
FDE：讓相似問題被平台化，降低下一次解題成本。
FDE：讓相似問題被平台化，降低下一次解題成本。
Economics
FDE 的經濟學，理論上是「減少下一次客製化」
客戶 A 的特殊需求不是終點先把現場限制與真正需要的 workflow 搞清楚；不要急著把每個畫面、規則和串接都固化成只屬於 A 的版本。
找出可共享的抽象把可重複的流程、資料模型、工具介面與評估方式整理出來，才可能成為產品團隊可採用的能力。
回到平台，變成下一案的起點理想路徑是「A 的需求 → abstraction → 產品 capability → B 直接使用」，而不是每一案都從訪談與重寫開始。
第十一個客戶是最誠實的測試若十個案子後仍完全靠人力重新理解、重新建置與重新維護，公司提供的是專案能力；若交付變快、風險變低，才看得到 FDE 的複利。
Practical test
導入 FDE 前，可先問的五個問題
角色能否拒絕或重構需求？沒有這個權限，就很難做 problem discovery，只能照單實作。
成功指標是否包含實際採用與業務結果？若只有功能完成率，團隊自然會把注意力放在交付，而非價值。
客戶洞察是否有固定回饋產品的機制？沒有產品回路，再好的現場工程師也只能累積個人經驗。
產品團隊是否願意吸收與維護可重用能力？FDE 不是把所有需求丟回產品，而是讓雙方共同決定哪些模式值得平台化。
第十一個客戶會變得更容易嗎？這題同時檢驗交付模式、產品策略與組織學習是否真的連成迴路。
Source