平台最大的敵人，不是舊系統，而是沒講清楚的流程

平台最大的敵人，不是舊系統，而是沒有被講清楚的流程。

這句話是我做平台這幾年，被現場教出來的。

一個「很簡單」的功能，怎麼越拆越大

做平台很容易遇到這種場景。BU 說：「我要這個功能，這個功能很簡單。」

產品往下拆，才慢慢冒出來：

• 「這個情況不一樣。」
• 「這類客戶要另外處理。」
• 「這裡還是要人工判斷。」
• 「這個 Case 比較特殊。」

最後，一個看起來很簡單的功能，越拆越大。

我要先說，單看每一個需求，其實都有道理。提需求的人沒有在找麻煩，他們描述的就是每天真實發生的工作。

人可以撐住模糊，系統不行

但全部放到平台上，就會開始看到真正的問題：

• 同一件事，不同單位有不同做法。
• 很多規則其實只存在某些人的經驗裡。
• 特殊情境一個接一個。
• 遇到問題，最後還是「問某某某就知道、問誰誰誰才決定」。

在人工作業的世界，這些模糊地帶可以靠經驗撐住。資深同仁知道哪個客戶要特別處理，知道哪個欄位其實沒人在看，知道哪種情況要打電話問誰。

但平台不行。系統會逼我們把很多以前沒講清楚的事情講清楚：

• 什麼是標準流程？
• 什麼才算真正的例外？
• 誰有權決定例外？
• 例外多到什麼程度，其實代表流程本身就該重做？

這些問題沒有一個是工程問題，但如果沒有人回答，工程師就只能自己猜，或者全部都做。

我原本以為的平台化

我早期對平台化的理解，比較接近「把現有流程搬進系統」。需求來了，盡量支援；例外來了，加個設定。看起來很有服務精神。

後來才發現這條路的終點長什麼樣子：

如果原本有 100 種例外，最差的做法就是在系統裡寫 100 個條件判斷。

因為最後得到的，不是一個平台，只是把原本「人治的複雜度」，變成「系統的複雜度」。而系統的複雜度更難處理：以前改一個做法只要大家講好，現在要改規格、改程式、改測試，還要擔心哪裡被連帶影響。

碰到功能需求，先往前問

所以現在碰到功能需求，反而要先往前問：

• 哪些流程應該先標準化？
• 哪些規則可以透明化？
• 哪些特殊情境其實可以被消掉？
• 哪些判斷真的值得留給人？

這幾個問題問下去，常常會發現有些「特殊 Case」其實只是歷史習慣，沒有人記得當初為什麼要這樣做；有些例外是因為上游資料不完整，修好上游就不用在下游處理；也有些判斷確實需要人，那就老老實實把它設計成一個清楚的人工節點，而不是假裝系統能自動處理。

平台建設，其實是一種流程治理

平台化真正困難的，不是 Development，而是 Standardization。

再講白一點：蓋平台，其實也是在做流程治理。光有 PM 和工程師不夠，還要業務單位願意坐下來，一起決定「我們以後就這樣做」。

好的平台不是支援所有人的所有做法，而是讓大部分事情走標準流程，把人的判斷，留給真正值得判斷的地方。

否則每一個「特殊 Case」都被做成一個功能後，我們最後數位化的，可能只是組織多年累積下來的歷史包袱。

最後

下次聽到「這個功能很簡單」，我會先問一句：這件事，現在大家的做法都一樣嗎？

如果答案是「不太一樣」，那真正要先做的，可能不是開發，而是一場把流程講清楚的會議。這場會議通常不好開，但比寫 100 個條件判斷便宜多了。