角色 × 狀態 × 規則：複雜企業流程，為什麼不該只用頁面與功能拆需求

企業流程的複雜度通常不在畫面多，而在同一個角色於不同階段能做什麼、不能做什麼，以及退回、鎖定、例外與重新提交如何彼此影響。若一開始只用頁面與功能拆需求，這些規則很容易散落在介面、系統介接與人工記憶裡。

核心觀點

先定義角色、狀態與規則，再設計頁面。當角色、狀態與規則可以被明確描述，介面才是這個產品模型的呈現，而不是規則本身。

先問系統現在是什麼狀態，不要先問下一頁長什麼樣

很多流程型需求會從頁面開始描述：員工填表、主管審核、人資查看進度、最後發布結果。這種說法容易理解，但一旦出現退回、跨層主管、特殊角色、補件、鎖定或同年度重新匯入，單純的頁面流程就會開始失去解釋力。

我會先把需求轉成三個基本維度：角色是誰在操作；狀態是資料或流程現在在哪個階段；規則則定義這個角色在這個狀態下能看、能改、能送出或必須被禁止的行為。

角色誰在操作？員工、主管、人資、管理者或特殊角色。

狀態目前在哪個階段？草稿、待確認、已送出、退回、鎖定或完成。

規則在這個角色 × 狀態組合下，哪些行為允許、禁止或需要額外條件。

例外特殊身分、歷史資料、補件、重送與流程外人工決策怎麼處理。

「按鈕不能按」不等於規則真的被鎖住

流程系統最常見的風險之一，是把業務規則只寫成前端狀態。例如送出後把按鈕停用，看起來像是完成鎖定，但如果後端沒有對相同狀態再次驗證，換一個入口、重新提交舊資料或直接呼叫系統介接，仍可能繞過規則。

因此我會把介面當成規則的提示層，而不是規則的唯一實作位置。真正的規則必須能由系統狀態與權限共同判斷，並且在資料重新載入、流程退回或角色改變後仍然成立。

好的企業流程系統不是「畫面走得通」，而是同一套規則在不同入口、不同角色與不同例外情境下仍然一致。

03 · Make exceptions explicit

例外不是最後再補，而是產品模型的一部分

企業流程幾乎一定有例外。真正危險的不是例外多，而是團隊把例外當成「之後再處理」。當例外沒有被正式建模，它最後通常會變成某個人的操作記憶、後台人工修改，或一段沒有人敢動的特殊程式。

我會先區分哪些例外可以被規則化，哪些必須保留人工判斷。前者進入角色 × 狀態 × 規則；後者則需要被清楚標示決策責任、資料紀錄與回復路徑。這能避免系統為了涵蓋所有情境變得過度複雜，也能避免人工例外變成不可追溯的黑箱。

我會用四個問題檢視一個流程模型是否成熟：

這不是工程建模技巧，而是產品決策工具

角色 × 狀態 × 規則的價值不只在於讓工程比較好寫。對產品經理而言，它更重要的用途是把模糊的制度與流程，轉成可以被共同討論、測試與取捨的模型。

當產品、人資、商業與工程對「現在是什麼狀態」「誰可以做什麼」「哪個條件不可被繞過」有共同語言，使用者驗收測試（UAT）才能真正驗證制度，而不是只驗證畫面。正式環境出現問題時，也比較能快速定位是介面、規則、資料狀態還是流程設計本身出了問題。

這也是我在企業流程與營運型產品中反覆使用的工作方式：先把複雜度整理成模型，再讓使用者看到最簡單的操作。