ERP 專案治理與 Key User 制度：開局的人事安排，決定終局的成敗

「下個月 ERP 就要開跑了，倉庫的小陳最近比較閒，讓他當 key user 吧。」——此刻，這句話正在某間會議室裡被說出來，老闆以為自己在做資源調度，其實是在簽一張延期保單。市場共識把 ERP 失敗歸咎於「系統選錯」或「顧問不力」，但這兩個原因加起來，都沒有名單排錯來得大。

先立這條貫穿本站導入系列的定律：ERP 的成敗，一半決定在啟動會議之前——決定在三張名單上；而甲方最常挑「最有空的人」，不是「最懂流程的人」。 三張名單：專案主持人是誰、指導委員會有誰、key user 是哪些人。

這篇把名單背後的制度，講成一套可以直接抄進專案章程的框架——我們稱之為專案治理三支柱：治理結構、Key User 制度、決策時效。它不是憑空發明：選型只決定三成成敗，剩下七成在簽約之後，這是我們在導入與維運完全指南畫過的「七成地圖」；本篇把地圖上的第一仗拆到可執行的顆粒度。每根支柱都先平移你熟悉的管理常識，再指出 ERP 專案特有的新課題。

支柱一：治理結構——三層各有唯一功能，混了就失靈

平移的部分很簡單：任何大型專案都需要「裁決層、推進層、執行層」。ERP 特有的新課題是——它動的是跨部門的作業與權力結構，所以每一層的「唯一功能」比一般專案更不能混。

指導委員會（Steering Committee）。 總經理主持，各部門最高主管與顧問方專案總監出席，每月一次。它的功能只有三個：裁決跨部門爭議（業務要彈性、財務要控制，這種仗只有這裡打得完）、核准範圍變更、盯里程碑。指導委員會流於形式的訊號很明確——會議變成進度朗讀會，沒有任何議題需要「裁決」。健康的專案，每次指委會都該有至少一個要拍板的衝突。

專案經理（雙 PM 制）。 顧問方一個 PM、企業方一個 PM，缺一不可。企業方 PM 是最常被省略的角色——「顧問不是有 PM 了嗎？」——但顧問的 PM 管的是他的人天與交付，你的 PM 管的是你的人、你的資料、你的決策時效。這個角色需要近全職投入，人選的關鍵特質不是懂系統，是在組織裡叫得動人：一個叫不動業務部的資訊主管，不如一個叫得動所有人的特助。

Key User 群。 每個循環至少一人，由部門主管指派最懂流程的人，而不是最有空的人——定律講過了，這兩者通常是反義詞，也正是這個制度最常在第一步就走歪的地方。

這張表可以直接帶進你的啟動會議：

支柱二：Key User 制度——用「三個說到做到的機制」取代誠意

「釋放三成工時」每個專案都承諾，多數專案都跳票。跳票的原因不是誠意，是沒有機制。平移的部分：承諾要有制度載體，這是管理常識。ERP 特有的新課題是——key user 的投入不是平均分佈，訪談期與 UAT 期接近五成、其他期間三成（各階段落在哪幾個月，見導入時程的逐月拆解），所以機制必須管到「階段」，不能只留一句「盡量配合」。

三個說到做到的機制，直接當勾選清單用：

• [ ] 寫進專案章程並由指委會核定——不是口頭共識，是附 key user 名單、各階段投入比例的正式文件
• [ ] 原職務真的有人接——部門主管安排職務代理或減量；沒有這步，「釋放」只是要求同一個人做一點五份工作
• [ ] 投入時數進專案週報——每週實際投入時數列給指委會看，連續兩週低於承諾就是升級議題

聽起來官僚，但這是唯一有效的做法：工時釋放靠自覺的結局，我們在導入失敗學的死法六做過完整解剖。

機制解決「能不能投入」，誘因解決「願不願意投入」。站在 key user 的角度想：接下這個角色，原工作沒少多少、專案壓力全新增、還要當同事抱怨新系統時的出氣口——如果沒有誘因設計，你挑到的注定是推不掉的人，而不是最好的人。務實的組合三條：專案納入年度考核的正式項目（占比講明）、專案獎金與上線及驗收里程碑掛勾、以及最容易被忽略但最值錢的一條——把 key user 經歷變成晉升履歷。走完一次完整導入的人，懂流程、懂系統、懂跨部門協作，本來就是主管的候選池；把這件事講明白，好的人才會舉手。

支柱三：決策時效——SLA 把拖延的成本還給決策者

平移的部分：對外服務有 SLA，對內決策也該有。ERP 特有的新課題是——導入過程每週都在產生待決事項：編碼原則選 A 還 B、這個流程要不要簽核、那個欄位誰維護。每一項懸而未決，後面的設定與開發就停著等；懸案一路積到驗收前才清，UAT 這道上線前最後的品質閘門就會被迫走形式。

專案章程裡訂三條：

1. 一般設計決策，key user 層級三個工作天內回覆
2. 跨部門爭議升級企業方 PM，一週內裁決或提指委會
3. 逾期未決視同同意顧問建議方案

最後一條看起來霸道，實務上是救命的——它把「拖著不決定」的成本，從專案身上移回決策者身上。

啟動會議前的四題自檢

把三支柱折回四個問題，開跑前答得出來再簽到：專案主持人有沒有跨部門的裁決權？企業方 PM 在組織裡叫得動誰？key user 名單裡有幾個是「最懂流程的人」、工時釋放的三個機制進章程了沒？決策 SLA 的三條寫進去了沒？——四題都答得出來，你已經贏過一半的專案；答不出來，先別急著開啟動會議。

常見問題（FAQ）

專案主持人一定要總經理嗎？
中小企業是。ERP 動的是跨部門的作業與權力結構，只有總經理層級壓得住。大型企業可由營運長或主導事業群的最高主管擔任，原則不變：主持人必須有跨部門的裁決權。

Key user 可以是部門主管自己嗎？
不理想。主管懂決策但常不懂操作細節，且工時最難釋放。較好的組合是主管進指導委員會、資深承辦當 key user，一個管裁決、一個管細節。

顧問方已經有很強的 PM，企業方 PM 還需要嗎？
需要，而且不能用兼差的方式需要。顧問的 PM 對他的公司負責——管人天、管交付、管合約範圍；你的資料整不整得出來、部門吵架誰去喬、決策三天內回不回得來，都在他的職責之外。企業方 PM 缺位的專案，這些事會自動流向顧問，而顧問唯一能做的是等——等的成本，記在你的時程上。

小公司人少，治理可以簡化嗎？
結構可以合併（指委會與專案會議合開），但三個功能不能少：有人能裁決、有人管進度、有人懂流程。真要簡化，順序是這樣：先定一個有裁決權的主持人，再找出每個循環最懂流程的那個人，最後把工時釋放三機制與決策 SLA 寫進章程——三步做完，五十人的公司也有了治理的骨架。

本文的「專案治理三支柱」與工時釋放三機制為本站整理之原創方法論，將隨導入實務與客戶現場的回饋持續迭代（建議每半年回訪本文）。治理架構為一般性設計，實際依組織規模調整；若需要協助設計貴公司的專案章程與 key user 制度，歡迎與我們聯繫。