企業導入 ERP，目的是讓未來更好；廠商提供軟體與服務，也肯定想贏得客戶信賴。雙方都想要好結果，為什麼我們卻總是看到 ERP 廠商與企業關係每況愛下、水火不容，甚至對簿公堂？這篇是我們寫了三十年系統的真心話：問題很少出在人不認真，多半出在三個看似正常、通用的做法——合約模型、系統分析方法，與對「修改」的態度。
真心話一：ERP合約模型的本質缺陷
三成、四成、三成，誘因從第一天就錯了
常見的 ERP 合約長這樣：簽約收三成、交付收四成、驗收後收尾款三成；專案開發可能多分幾道，但邏輯一樣：驗收前修改不用錢，驗收後修改要收費。這個結構會發生什麼事？客戶把所有需求——該用的、不該用的、一百年內可能用到的——全部提出來。因為不提出來好像就失職了。原本十張報表的需求，變成一百張；資源花在短期內用不到、甚至永遠用不到的功能上，整件事的重點從第一天就扭曲了。
合約不讓你「做中學」
客戶不是系統分析的高手，軟體公司也不是經營這個行業的高手——兩邊都還在磨合，就要寫出一套完整可用的規格，本來就很難。真正可行的路必然是做中學、學中做，但驗收制的合約偏偏不讓你這樣做：要驗收完才能用，那要怎麼學？怎麼開規格？很多需求是用了之後才浮現的，事先沒辦法預知。冷冰冰地看合約，很容易把「照期執行」當成最高責任；但企業自己開發產品也會因為更好的構想而延期，那為什麼系統多花點時間把事情做對，反而變成解約的理由？重點放錯了，雙方就在合約上出現爭執。
我們改用按月收費的長期合約，客戶就可以放心了：今天有需求今天提、明天有需求明天提，修改不另外加費——不用把一百年的需求一次提完，也不用在驗收單上與廠商對峙。這就是我們在ERP 費用與計價方式裡講的月付制——它不是價格方案，是把誘因擺對。
真心話二：ERP系統分析，難以呈現企業的真實面貌
訪談型：掛一漏萬，還不敢簽字
訪談型的系統分析有個先天限制：被訪談的人對自己的職務很難有完整的結構。你去訪談一位會計從業人員，他講得出一套會計制度嗎？多數只能片面講出日常作業，簡單的都講了，重要的例外狀況全漏了。拿這樣的素材去做分析，結果往往是錯的；你不熟他的作業所以不知道自己錯了，他不懂系統所以也看不出你的分析有漏洞。接著還有簽字的困境：你寫的東西用的都是我的名詞，但我怎麼知道你寫得完不完整？我自己都不見得講得清楚，怎麼敢簽？於是又回到前面那個問題——為了不漏，就把需求講得更多更大。
套裝型：大部分看起來對，就以為全部都對
套裝軟體則是另一種盲點：它用自己的觀點詮釋別人的事情。每家企業都有自己的特殊變化，大部分流程看起來都對，就以為全部都對——真正導入時才發現某些關鍵流程是錯的。更根本的問題是：品質、內控、效率、預防錯誤這些在企業底層流動的東西，根本訪談不出來——而這些恰恰是 ERP 最重要的任務。花了大工夫，得到的卻只是不需要訪談也知道的瑑碎常規。
我們的做法：先建溝通模型，再談內容
我們沒有一個大模子，只有最簡單的一件事：人跟人是怎麼講話的。我交代你一件事、你去做、做完回報；交代十件做了三件，剩下七件可以改、可以取消。交辦、回報、異常——這些溝通行為的「文法」先定好，很多事情就自然了：單據會不會改？一定會；命令還沒執行能不能改？當然能——這些都不用再問。真正訪談時只需要談內容，瑑碎複雜的部分都不用花時間。這套溝通模型後來長成了我們的看板管理方法論——有興趣的讀者可以深入看看。
真心話三：永續改善能力，決定企業的成長動力
水泥牆，還是活動隔間？
任何 ERP 系統都不可能不修改，因為企業本身就在追求永續改善。但專案開發商的任務是完成你訂的規格，交付條件裡沒有「好不好改」這件事。就像你要一間彈性隔間的辦公室，他卻用水泥施作，然後告訴你：之後要改，把牆打掉重蓋就好。結果就是改一面牆要動到地基、天花板、裝潢——最後沒人敢打這面牆，系統就越用越僵化，人去遷就系統。我們從第一天就認定軟體必然要改，所以系統用一個一個小組件術接，隨時能拆卸、重組——改一個畫面就是一個畫面的工，改一張報表就是一張報表的工。
前三年，每年改掉六、七成——這是常態
根據我們的經驗，一家企業在 ERP 上線的前兩三年，每年大約要改掉整個系統的 60～70%，之後每年也有三成左右。這不是系統做得差，恰恰相反——這代表經理人持續在構思改善、在跟進市場與客戶的變化。改得快與慢，本質差異在這裡：你鼓勵員工全員改善，結果提了案系統卻跟不上，這個改善怎麼成立？反過來，某位同仁對單據格式有建議，今天提出過幾天就上線，對了馬上享受成果、錯了馬上改回來，幾乎沒有負擔——這樣才形成改善循環，大家才更願意改善。
修改不是負擔，是我們的本業
從合約角度想就更清楚：對專案制與套裝廠商來說，完成專案才是大收入，維護修改是能免則免的負擔；客戶提修改，得先告訴廠商「你要改哪裡」，沒有人幫你從原始需求去拆解問題。而在月付制裡，修改就是我們的本業：客戶提出一個重大的難題，很可能經過顧問拆解後只要改一點點；系統能預防錯誤是最高境界，出錯時通知你就差一級——哪種做法適合現在的狀況，需要有經驗的顧問一起判斷。這些都包在月費裡，因為這本來就是我們該做的事。
結語：把誘因擺對，三件事就都順了
回頭看這三個真心話，其實是同一件事：買斷制的誘因設計，讓雙方在錯的地方用力。合約讓客戶灌需求、讓廠商趕交付；系統分析變成簽字大會；上線後的修改變成誰都不想碰的負擔。把誘因擺對——月付制、溝通模型、為修改而設計的系統架構——合約、分析、改善三件事就自然順了。至於導入過程怎麼降低風險，那是另一個真心話，我們寫在步進式 ERP 導入流程（SDT）。
常見問題
簽ERP合約時，最該注意什麼？
看「驗收後的修改怎麼計價」。如果驗收後每次修改都要另外報價，你就會被迫在簽約前把所有需求一次提完——而真正重要的需求，往往是用了之後才浮現的。合約的誘因設計，比價格數字更值得花時間看。
為什麼ERP系統分析常常做不準？
因為被訪談的人講不出自己職務的完整結構，重要的例外狀況都在細節裡；而品質、內控、預防錯誤這些企業底層的東西，根本訪談不出來。先有溝通模型再談內容，才能避開這個先天限制。
ERP上線後還要一直改，正常嗎？
非常正常，而且是好事。依我們的經驗，上線前兩三年每年會改掉系統的 60～70%，之後每年約三成——這代表企業持續在改善。該擔心的反而是都不用改的系統：不是企業沒進步，就是系統改不動，大家已經回去用 Excel 了。
想知道把誘因擺對之後的合作長什麼樣子？看看我們的ERP費用與計價方式，或直接預約免費諮詢——把你現在合約裡最不安的那一條拿出來聊，我們老實跟你說。
