文章目錄
每套 ERP 上線時的權限都偏寬。專案後期趕上線，「先開了讓大家能作業」幾乎是每家公司的共同選擇——這一步沒有錯，錯的是把它當成終點。真正的共識之錯不在「當初開太寬」，而在多數團隊打從心裡以為「上線後有空再收」——而那個「有空」永遠不會來。權限只會往寬長，不會自己往窄收。
於是三年後，權限清單裡躺著離職員工的帳號、身兼數職的萬能角色、和一堆「當初為什麼開的沒人記得」的例外。等到會計師進場做內控查核，這張清單就是問題清單。
這篇提出一套今天就能開始跑的框架——我們稱之為 SoD 三步：建矩陣 → 掃衝突 → 分離優先／補償墊底。它不是什麼新發明，是把內控用了幾十年的「授權、執行、記錄、保管四權分立」翻譯成一張你今天就能打開 Excel 動手的作業流程。
先立一條貫穿全文的定律，後面每一節都會回到它：補償控制是妥協，不是解法——它只是把「職務分不開」的風險，換成「每月覆核有沒有真的在跑」的風險。 記住這句話，你就不會用一個覆核章去騙自己權限已經乾淨了。
先立原則：權限跟著角色走，不跟著人走
權限設計的第一個分岔路：直接把權限開給「某個人」，還是先定義「角色」再把人放進角色。答案永遠是後者，理由是維護性——採購助理離職換人，角色制只要把新人放進「採購助理」角色；個人制則要人工重演前任的幾十條權限，漏一條是作業中斷、多一條是控制缺口。
這是平移：內控本來就講「不看人、看職務」，這裡只是把它落到系統的角色物件上。角色設計的方法是從職務盤點來，不從系統功能來：列出公司實際的職務（業務助理、生管、成會、倉管……），每個職務對應日常作業清單，作業清單再對應系統功能與資料範圍。兩個實務原則：最小授權——這個職務的日常作業需要什麼就給什麼，「順便」「以防萬一」是權限膨脹的兩大藉口；查詢與異動分離——需要「看」的人給唯讀，跨部門查詢需求用唯讀角色滿足，別為了讓主管看報表就給他整個模組的異動權。
新增的那一半：ERP 的角色不是靜態名冊，它會被「臨時代理」「專案特權」不斷污染。所以角色制真正的難點不在初次設計，而在後面第三節講的「讓它活著」——沒有維護機制的角色制，兩年後就退化成個人制。
第一步：建矩陣——把不相容職務系統化盤點
職能分離（Segregation of Duties）的原理一句話：讓舞弊需要共謀——單獨一個人不應該能完成一筆交易的全部關鍵環節。就像那兩把分別插在不同鎖孔的鑰匙，缺一把門就開不了。落到實作是一張矩陣：把關鍵權限列成行與列，標出哪些組合不相容。
先給你這張矩陣的骨架——SoD 不相容組合矩陣（關鍵權限 × 關鍵權限，✖ 為不相容格）：
| 關鍵權限 ＼ 關鍵權限 | 供應商主檔 | 採購下單 | 收料確認 | 發票核准 | 收款沖帳 | 系統權限管理 |
| 供應商主檔維護 | — | ✖ | ✖ | ✖ | ||
| 採購下單 | ✖ | — | ✖ | ✖ | ✖ | |
| 收料確認 | ✖ | — | ✖ | ✖ | ||
| 發票核准／付款 | ✖ | ✖ | ✖ | — | ✖ | |
| 開立發票／收款沖帳 | ✖ | ✖ | ||||
| 系統權限管理 | ✖ | ✖ | ✖ | ✖ | ✖ | — |
經典的不相容組合（每個循環都有，以下為判讀這張矩陣的說明）：
- 供應商主檔維護 × 採購下單：自己開供應商自己下單＝假供應商舞弊的完整路徑
- 採購下單 × 收料確認 × 發票核准：三權集中＝虛假採購無人攔截
- 客戶信用額度維護 × 訂單放行：自己放寬自己放行
- 開立發票 × 收款沖帳：侵占貨款後自己沖帳滅跡
- 薪資主檔維護 × 薪資計算執行：自己造人頭自己發薪
- 系統權限管理 × 任何業務交易權限：管權限的人不碰交易，這條本身就是一條 SoD（矩陣最後一行整行皆 ✖，不是巧合）
建矩陣的流程：列出各循環的關鍵權限點（授權、執行、記錄、保管四類）→ 定義不相容規則 → 拿現有角色與使用者對照掃描 → 產出衝突清單。平移的是九大循環那套關鍵控制點的分類；新增的是把它從「文件上的敘述」變成一張機器可以逐格比對的矩陣——這一步把內控從「看得懂」推進到「掃得動」。
第二步：掃衝突——第一次很難看是正常的
矩陣建好，拿它去對現況：把每個角色、每個使用者實際擁有的權限攤開，逐一比對矩陣裡的 ✖ 格，落在 ✖ 格上的就是一條衝突。第一次掃描的結果通常很難看——一個財務同仁同時能開發票又能沖帳、一個資深員工的角色累積了六年的「順便開一下」。這不代表你的公司特別糟，代表你終於在看真相了。 重點不是掃出幾條，是接下來每一條怎麼收。
第三步：分離優先，補償控制墊底
掃出來的每一條衝突，三選一。這是你要帶走的第二張表——衝突三選一決策表：
| 處理方式 | 適用情境 | 怎麼做 | 查核時會計師怎麼看 |
| ① 調整權限（首選） | 權限可以拆開、工作本來就該分兩人做 | 把不相容的權限拆到不同角色，人各歸其位 | 直接看角色權限表，衝突消失即通過，最乾淨 |
| ② 調整職務 | 權限拆不動，因為工作本來就一人兼 | 動的是分工——重新安排誰做哪一段，讓交易鏈上至少換一次手 | 看職務分工表與實際作業，確認關鍵環節確實換手 |
| ③ 補償控制（最後手段） | 小公司人力真的不夠拆 | 保留兼職權限，加一道獨立的事後覆核（例：兼管收款沖帳者，其沖帳紀錄每月由主管全數覆核並簽名留痕） | 逐條檢視覆核「有沒有真的在跑」——抽覆核紀錄、看日期連不連續、看有沒有真的抓到過異常 |
要誠實面對的一點，就是本文的定律：補償控制是妥協，不是解法——它只是把「職務分不開」的風險，換成「每月覆核有沒有真的在跑」的風險。 查核時會計師會逐條檢視補償控制到底有沒有落實——形式上的覆核章救不了你。一個從來沒抓到過任何異常、每月同一天一次蓋十張章的覆核紀錄，本身就是紅旗。
中小企業的務實路徑是：高風險循環（採購付款、銷售收款）優先做真分離（決策表的 ①②），其他循環過渡期用補償控制墊底（③），隨組織成長逐步收斂。有 IPO 時程的公司請倒過來想：專審時會計師調的第一批資料，就是權限清單對職務分工表——這件事做的品質，直接決定問題清單的長度（完整的審查邏輯見我們的 ERP 與 IPO 專文）。
讓它活著：三個常態機制
權限治理最常見的死法是「做過一次」。SoD 三步跑完一輪只是起點，讓它活著需要三個機制：
- 申請留痕——所有權限異動走申請單（哪怕是簡單的電子表單），記錄誰申請、誰核准、為什麼。「當初為什麼開的」從此有答案，這也是把角色制不被個人特權污染的第一道閘（呼應第一節）。
- 季度或半年度盤點——各部門主管確認自己人的權限清單、資訊人員清離職與調職帳號、對照 SoD 矩陣重掃一次。矩陣不是建完就束之高閣，它是每季都要重新跑一遍的工具。
- 例外有期限——臨時代理、專案需要開的例外權限，開立時就設到期日，到期自動收回，而不是等人想起來。沒有到期日的例外，就是明天的衝突。
三個機制都不複雜，難的只是開始做並且不停。這也是為什麼「補償控制是妥協」——真分離做完就穩了，補償控制卻要靠這三個機制永遠跑下去才有效，任何一個月的覆核斷掉，那條風險就裸奔了。
查核的視角：會計師調的第一批資料
準則不會替你設計權限，但查核邏輯可以預演。四個遲早會被問的問題，現在就拿來自我檢驗：
- 權限清單對得上職務分工表嗎？ 這是專審調的第一份資料，兩張表對不起來，後面全部要解釋。
- SoD 矩陣掃過了嗎、衝突怎麼處理的？ 拿得出矩陣、拿得出衝突清單、每條都有處置紀錄，你就站在對的那一邊。
- 補償控制真的在跑嗎？ 抽三個月覆核紀錄，看它連不連續、抓沒抓到過東西。
- 權限異動留痕了嗎、多久盤一次？ 申請單調得出來、盤點紀錄有連續性——這是內控「有效運作」的證據（老規矩：紙上的制度誰都會寫，軌跡才是真話）。
四題答得出來，不管會計師從哪個角度切，你都不心虛。
常見問題（FAQ）
小公司人少，職能分離做得到嗎？
完全分離做不到，但高風險組合的分離加補償控制做得到。優先處理採購付款與銷售收款兩個循環的經典衝突，其餘用獨立覆核墊底，隨人力成長逐步收斂。
權限盤點多久做一次？
建議每半年一次全面盤點，人事異動（離職、調職）即時處理。有上市櫃計畫的公司建議季度盤點，並保留盤點紀錄——它是內控運作的證據。
ERP 系統本身有 SoD 檢查功能嗎？
大型系統（S/4HANA、Oracle Fusion）有內建或加購的權限治理模組可自動掃描衝突；中小型系統多半沒有，用匯出權限清單加 Excel 矩陣人工掃描，一樣做得到，只是要有人負責。
本文的 SoD 三步（建矩陣 → 掃衝突 → 分離優先／補償墊底）為本站提出之權限治理方法論，各系統的權限架構差異大，本方法將隨主流 ERP 的權限治理模組與查核實務演進持續迭代（建議每半年回訪本文）。若需要協助建立貴公司的角色設計、SoD 矩陣或盤點機制，歡迎與我們聯繫。
