ERP專案失敗的「真正主要原因」是「ERP系統的『品質』不佳」
走筆至此，也許少數人仍有覺得「ERP系統的『品質』不佳」這句話太隴統、含糊、沒有搔到癢處、不一定是ERP專案失敗的真正主要原因。所以，有具體化這句話的必要。
借用我在台灣和中國兩個工廠任職的粗淺經驗，去揣測【魔鬼終結者】阿諾史瓦辛格的人事薪資、考勤（這裏就講「Human Resource, HR」）專案是怎麼死的。
http://ppt.cc/~kim
台灣和中國這兩家傳統企業的HR制度，記憶中有這些：
- 勞工：三班制：07:00 ~ 15:00、15:00 ~ 23:00、23:00 ~ 07:00。夜班提供夜點費。
- 遲到半小時內，扣薪N元。遲到M小時以上，視同請假半日。早退，（忘了詳情！）。未請假，曠職，扣薪X元。
- 有全勤獎。
- 小過：扣N元；大過，扣M元。小功：獎N元；大功，獎M元。
- 職員：高級主管不打卡，其餘須打卡。可填單報出差。
- 薪資：按層級表。也許有年終獎金。
- 年假/年資對照表。
- 外國勞工提供住宿。
- 中國廠有用餐制度、住房、保險。
- 台灣廠有勞保、健保、綜合所得扣繳憑單。
- 當然，打卡鐘24小時侍候。
這些HR制度，就是user對軟體「品質」的正面挑戰：
- 數據錯，是災難：多發薪，公司會倒；少發薪，下班可能有人在大門堵你這個MIS主管。
- 功能尚未開發，不能接受：發不出薪水，投資人以為公司要倒了，股價跌停。
（從HR系統的重要性可知：如果MIS主管不親自維護HR系統，那麼，他要100%善待負責HR的程式部屬，以免...）
HR的要求是「黑/白」、「是/非」、「有/無」、「Yes/No」，絕對沒有模糊的空間。
專案輔導顧問也好，軟體程式設計師也好、資料庫管理師也好，都不可逃避、曲解、轉移焦點。
「有」且「正確」，給100分；「無」或「錯」，退回、拒絕付款。
「最佳化」這句哲學用語面對HR的要求時，必須立即丟棄。
軟體專案組人員接到這種case，只有一個解決方案（solution）可以令user、MIS、軟體商、顧問4方皆大歡喜，成功結案。那就是：設計資料庫、程式、報表，一一滿足HR的需求。
至於SAP拿甚麼神奇妙藥去推這個專案，外人無從得知，只能透過隻字片語揣測。
「SAP co-CEO Leo Apotheker angrily denied there were problems with SAP's software, and blamed consulting firms like IBM (IBM) and Accenture (ACN) for sending people who knew nothing about the software to clients as experts on SAP. Leo also has said SAP's new cloud-like package, SAP Business Suite 7, should be easier to implement.」
SAP副總裁辯稱：「IBM和Accenture這些顧問不懂SAP的軟體。SAP的新『類似雲端』軟體應該比較容易推」。
根據此言，如果SAP拿出去的，是R/3那套架構的話，
- 它是製造業的架構，和HR相去十萬八千里。
- 資料庫裏現有的35000個table，有沒有先砍掉大部分？誰敢砍、有能力砍？
- 14000個function module，有沒有先砍掉大部分？誰敢砍、有能力砍？
- 如前述，想滿足HR的需求，要寫程式。
R/3的ABAP是加上一堆自己特有規定的COBOL級「祖」字輩低生產力語言。
(1)用ABAP去寫數百、上千個程式，何年何月何日可完成？
(2)加州現在用的系統，不就是COBOL嗎？捨穩定的COBOL，求尚未撰寫、更複雜的COBOL，是MIS主管做得出來的決策品質嗎？
至於SAP副總裁所指的「SAP的新『類似雲端』軟體」或「『類似SOA』軟體」是何種高科技？因為我沒時間去瞭解，所以不予置評。
按我對20年前的老舊技術「Common Object Request Broker Architecture，CORBA」的皮毛認知，懷疑許多學術界在ERP產業每隔幾年就推出的「軟體科技最新明星」只是一些舊瓶新裝的重複名詞炒作而已。
面對HR需求，軟體品質不良、拿不出來時，
- COBOL換COBOL的兄弟姊妹ABAP沒有用
- 開會沒有用
- 換顧問沒有用
- 換計畫主持人沒有用
- 加碼預算沒有用
- 溝通沒有用，只會火上加油、使關係更緊張
- 換SOA、雲端沒有用，除非採人海戰術：（按美國高階程式人員薪資水準估）月薪30萬/每人，投入30人。
「ERP系統的『品質』不佳」，在加州這個case，也許可以這樣指認：
- 該有的，沒有：一些畫面、報表、程式沒有設計給user。
- 不該有的，一大堆：製造業專用的table、ABAP程式殘留在HR系統中，混淆資訊人員的視聽、拖慢系統的運轉速度。
- 開發困難度太高：R/3本身就是半透明的黑盒子。資料庫結構猶如蜘蛛網、技術手冊不一定提供且不保證正確、有隱藏機制或陷阱、「Note（官方發佈的『注意事項』）」滿坑滿谷且很多已失效。
- 低生產力：ABAP。
- 難用：一項功能，必須在多個畫面完成（最多2層的「一對多」單據）；「Note」滿坑滿谷且很多已失效、互相牴觸。
統稱「品質不佳、不合用」。用「品質」不佳的軟體推大型專案而失敗，不足為奇。
加州這個case，要做的是：
- 設定停損時間點。就是N年前。
- 改用【資訊系統開發架構（framework）】，瘦客戶ERP、PostERP。
- 1位資料庫設計師、3位程式師上場。
- 屈下去（台語），老老實實地設計資料庫、寫PostgreSQL的PL/PGSQL程式。
做這項決策，
- 政府花的成本最低
- 最快結案
- 公務員user最滿意
- MIS主管悠閒、拿高薪、穩坐寶座
- 資料庫設計師、程式人員、軟體商收到的報酬最合理
以皆大歡喜收場。
竟出此言！豈非狂妄？有何根據？
略述「瘦客戶ERP」的開發應用資訊系統的流程，網友或多或少可以揣摩一下開發HR系統的「生產力」：
（1）設計資料庫的（150個？）table。2個人月。
（2）開發新畫面，不需要寫程式：
(a)指定用到哪些資料庫的table，就完工90%。3分鐘。
(b)剩下的10%是：選單、選項、畫面線上說明、欄位線上說明...。30分鐘。
（3）設計報表，不需要寫程式：
(a)設計SELECT ... SQL。10分鐘 ~ 1日。
(b)用滑鼠拉（drag and drop）報表外觀。30分鐘。
(c)掛在指定的畫面下、授權。各1分鐘。
（4）算考勤、績效、薪水：
(a)寫（20個？）PL/PGSQL function。2人日每支。
(b)掛在指定的畫面下、授權。各1分鐘。