剛才發現：原來於2014年尾，在mobile01仍有網友受ERP的毒害，因而有發不平之鳴者、有忠告尚未上賊船者、有徵求解脫良藥者。
參考資料：
2014-08-15
2011年
2011年
2010年
2006年
林放問禮之本，孔子一句：「大哉問！...」傳頌千年。偉哉！孔子。
因為鄙人人微言輕，無人聞問，所以自問自答。
文章如有誤謬，請網友指正；若有冒犯，請受害者海涵！
不才曾於國、內外工廠、銀行、壽險、多層傳銷、連鎖服飾業、forwarder..的MIS部門任職。經歷過：
* 從面對面服侍end user，負責infrastructure，跪在地板拉網路線、鎖螺絲、換硬碟、寫RS-232軟體，
* 到只出一張嘴「管理、帶領」30位部屬的MIS部門最高主管，
* 到被「更高級、更專業」的上級財務主管炒過魷魚
* 從低階的用6502組合語言寫四則運算，到中階的IBM MVS mainframe的JCL和報表程式，
到高階的Linux上面用SQL。
- 外商：
不才強迫女性user同事使用鄙人設計的軟體，因「溝通不良」，而使這位同事在辦公室大聲哭泣，20年後仍自責不已。矛盾的是，同公司的美國同事在大飯店的餐桌上卻當眾稱讚鄙人：「XYZ，Good job！」
- 台灣電子廠：
老闆在面談時聲明：「正在推ERP」。為求餬口，不才違心允諾：「有自信能勝任」。
這套外國ERP，不能改。有N個畫面，每個畫面有M個欄位。
博士級的代理商老闆親自輔導。博士顧問一離開大門，沒有任何user繼續在用。
一直到公司倒閉，上報紙，都沒有上線，棄置一旁。
半途逃之夭夭，老闆大發雷霆，自己的信用掃地。
- 台灣傳統產業：
接手前輩300萬元購入的國產軟體，有4GL原始碼數百MB。
進銷存與會計100%脫離。會計人員十餘位，翻閱進銷存資料，獨立操作會計模組。
沒有現金流量表。
萬能table「tlf_file」超大，包山包海，與進銷存畫面時有出入。
沒有買成本、製造。
不能處理批號但是業務需要。
資料不一致，A畫面與B報表對不隴。
過帳、結帳不一定成功，必須看程式去挖錯誤單據。所以，結帳期間，程式負責人不可請假。所以，主管必須展現領導、帶人的管理能力。
盤點資料生成會計「相關」資料（注意！不是分錄）的批次處理時而失敗，必須看程式去挖錯誤單據。所以，結帳期間，程式負責人不可請假。所以，主管必須具備領導、帶人的管理能力。
不具「多倉、多庫區、多儲位」架構。
不具「一張單，多品名。一品名，多批號。一張單，多出貨日、多地點...」等架構。
一個資料庫只支援單一公司。
資料庫不提供sub query，必須用數十數百列的4GL程式彌補。
印表時而變成亂碼、不停送紙。
不是GUI，必須開DOS視窗跑盜用的「非」免費telnet軟體。
- 外商多層傳銷公司：
總公司外包美國的一家軟體商用COBOL寫的軟體。台灣只能用Windows的Remote Desktop操作。
不才「只」負責溝通、聯絡、把資料弄正確「而已」。
聯絡唯一管道是yahoo messenger。軟體商晝伏夜出，多數時間不上線，上線不一定回答問題。
就職前，已經天下大亂：獎金有多發、短發，該晉升的未晉升、不該晉升的已升，該累積的業績未累積、不該累積的已累積。
美國總公司分批派2位專家過來「解決」問題：
(1)第一位拿著超大Apple notebook PC，命令不才坐在他的大辦公桌前，看他操起流利的English，一邊發E-mail，一邊質問問題的癥結。發完E-mail、召開會員大會後隨即離境。
(2)第二位女士陪老闆娘去花東旅遊結束後，回辦公室辦正事。把約千份的紙張記錄逐一手工「處理」，手工做出「補發獎金」清冊，命不才火速奔往郵局和銀行轉帳數百萬元給數百位會員。
救不了公司，更救不了自己。
唯一可以自豪的是：在強大的引誘環境中，鄙人絕未在這家公司偷取絲毫不義之財。
- 在中國16000人的台商工廠：
(1)首先，資訊系統是前輩自己開發。
(2)第2次，前輩（台幹？）買外國ERP，不允許修改。user怨聲載道。
軟體組的阿六副理帶領其部屬，外掛N個Delphi程式，受阿六部屬極高的推崇。
User按enter鍵後，主機15分鐘內不回應。主機是兩顆CPU、16GB RAM的Dell。硬體組的阿六副理強烈建議買IBM刀鋒伺服器，以「解決」系統的低速問題。
原訂派往外國。某日，老闆問不才：「有無能力接IT部？」。答：「可」。1小時後，原台幹被炒魷魚。
(3)第3次，老闆堅持買高雄一家用C開發的軟體，不才抵死不從。E-mail給老闆，CC給軟體組阿六副理：「如果買這套體，6個月失敗的機率約50%，9個月失敗的機率約70%，1年失敗的機率約90%。不過，一旦公司決定，職也會配合。」，被炒魷魚。
離職後傳出來的消息與不才的預測接近，除了一點 -- 宣告失敗的時間提早1年：價金1000萬，軟體公司拿到簽約金30%後不參加會議，自此消失。
(4)第4次，換成用Oracle開發的「XYZ產業專用ERP」，台製。
- 有Power MAN、tiptop、四班（Forth Shift）、SAP R/3等皮毛經驗。
- 幫一家醫院、再保險公司（reinsurance）開發過資訊系統，用C++設計高速網站，開發ERP。
從片段的經驗中得到一個結論：
*** ERP系統的『品質』與『合用度』決定一切 ***
個人積分：15分
文章編號：52499715
個人積分：15分
文章編號：52499938
上一篇所指出的，只是我一個人的失敗經驗，代表性不足。所以，我們也必須參考國內超大公司以及西洋ERP先進國的一些大型ERP專案推動經驗，以便
（1）討論：外國的ERP使用狀況有無比台灣好
（2）找出失敗的真正原因
（3）最重要的，避免重蹈覆轍
（A）台灣
台電4.3億買軟體 難用
台電4.3億買軟體 難用
遭質疑浪費 民轟：漲電價補錢坑
2012年04月05日
【王玉樹╱台北報導】電價擬漲，引爆外界批評台電經營不善導致虧損。昨出刊的《壹週刊》報導，台電3年前花4億多元採購軟體，遭抱怨貴又難用；甚至因判斷錯誤，導致高價採購燃煤、損失上千億元，延後打造運煤船又多付40億元。消基會批評，台電應先檢討內部控管與採購浪費等問題，再來談漲電價。
造運煤船多付40億
台電2009年花4億3000萬元，向德商思愛普採購「企業營運核心系統整合重建計劃（ERP）」軟體，統整管理各部門資金、物料、設備等資訊。《壹週刊》指出，軟體遭台電員工抱怨難用，還得每年付2億元權利金給廠商，堪稱天價。
此外，2008年台電董事長陳貴明主導，在煤價高點時簽8年購煤長約，後來煤價大跌，台電被質疑虧損上千億元；另如2004年暫緩打造運煤船，5年後才重啟計劃，也被批評這段時間多花40億元運費。
辯稱「沒有虧8年」
昨台電高層一一駁斥上列質疑，指稱台積電、宏達電也在用ERP軟體，當時是公開招標由思愛普標得，且無須每年再付權利金，「這是很新的系統，同仁用不習慣很正常。」
至於延誤打造運煤船與高價採購燃煤，台電高層認為外界批評「都是事後諸葛」，因當年鋼價大漲，一條船造價從3600萬元漲到4900萬元，且立法院編列購船預算尚未通過，當然要暫緩；購煤長約隔年就可依市價重新議價，「沒有虧8年這回事。」
熟悉ERP的中原大學資管系教授吳肇銘說，思愛普是國際知名大廠，像台電如此大規模公司，「花4億多元或許不能說太貴，但是否改用本土廠商較便宜的ERP，是可討論的。」台電員工透露：「很多人確實覺得ERP難上手，工會也曾質疑為何花大錢購買，但因大企業也有採用，後來內部反對聲浪就小了。」
消基會批應先檢討
消基會董事長蘇錦霞指出，種種質疑都顯示，台電有內部控管、採購浪費等問題，應先自行檢討，再來談漲電價。民眾楊景順批評：「國營事業無能、浪費成性，只會用漲價來填補錢坑，怎能了解升斗小民的痛苦？」
近年台電遭質疑浪費事件
年度 事項
◎今年：監察院公布核四工程各種浪費，如延誤11年致預算追加逾1039億元；核反應器契約審核品質差，造成設計重新變更，增加10億元支出；輕忽工地防颱措施造成二號機被淹，損失2億元
◎2009年：台電以4.3億元採購「企業營運核心系統整合重建計劃（ERP）」軟體，遭批太貴又難用
◎2008年：《壹週刊》踢爆當時已是台電董事長的陳貴明在煤價高點大買燃煤，一次簽8年約，後來煤價下跌，台電損失上千億元
◎2004年：台電委託台船造運煤船，時任總經理的陳貴明以鋼價高漲批示暫緩，2009年重啟造船計劃，台電為此多花40億元運費
資料來源：監察院、《壹週刊》、《蘋果》資料室
個人積分：1464分
文章編號：52500173
個人積分：15分
文章編號：52500182
（B）中國、歐美
來源：中國網站論壇
* oracle和哈爾濱制藥的合作案例
* 美國加州政府使用SAP的人事薪資模組而損失2,500萬美元，軟體棄置不用。德國總公司去的頂級主管這樣解釋「都是顧問的錯」，並重新建議：「加州政府應該改用我們的另一款『類、似、像SOA』軟體」。
* Waste Management控告SAP：用戶損失金額＝1億美元
* 英國ICI因使用SAP而損失2,300萬英磅
* sap和General Motors Locomotive Group的合作案例。
* Nike用i2的結果：損失金額＝8,000萬 ~ 1億美元
* W.W. Grainger Inc.用SAP而損失4,200萬美元。
* sap + IBM和Hershey Foods Corp.的合作案例：用戶損失＝上線後首季業績掉12%
* oracle和Tri Valley Growers的合作案例：用戶損失＝600萬美元
* sap和HP的合作案例：「HP did a pretty good job at this major project, they only missed their revenue target by $400 million, a third of which was due to the Fusion project. Other than a lost CEO, many millions in business, and a lot of anxiety, HP positioned itself for a recovery.」
簡譯：用了SAP後，HP收入減少4000萬美元、總裁捲鋪蓋、公司啟動「恢復元氣措施」。
* Avis用PeopleSoft的服務損失4,500萬歐元。
* 前美國第四大藥廠FoxMeyer Corporation用了SAP的ERP，關門大吉。
* 珠寶公司Shane和SAP簽約8百萬美元要上庫存模組和POS系統，預計1年上線。實際用了32個月、3600萬美元。上線後，庫存不準確，導致Shane破產。
個人積分：15分
文章編號：52500381
ERP專案失敗的「可能」原因有千百種，媒體、ERP專業網站的討論、學術界的研究報告能寫的，大概就是這些：
（1）ERP專案管理能力不足：
* 找錯顧問
* 時程沒把握好
* 甘特圖不好用
* 職掌分配圖不實際
* 負責「use case」圖的團員失職
* 預算太少
* 軟體商不斷要求追加收費，獅子大開口
（2）顧問的上線輔導（中國同行用語「實施」）出問題：
* 不瞭解軟體：不知道畫面、報表用到哪些資料庫的table，不知道在A畫面輸入的資料也會跑去B畫面、C報表。不知道軟體用到哪些資料去計算成本，不知道財務、MRP的計算細節。
* 不會改軟體：回答：「會把你的需求記錄下來，轉給程式人員」後，就沒有下文。薪資制度小改一下，就兩手一攤。
* 缺乏現場經驗，或學理與實際環境不相容，令生產線上員工啼笑皆非。
* 忽略user的痛苦，不願面對user的實際作業需求，強人所難，強硬套用「best practice（最佳配置）、best implementation template（最佳方案樣板）」，以「我就是專家」姿態逼迫user「照手冊、SOP、ISO、CMMI、書面規範做就對了！」
* 情緒管理欠佳：（心中）指責user：「全球前百大企業都在用，都100%成功，你還在懷疑甚麼？你為何抵制？專案如果失敗，就是因為有你這種人在抵制！」
（3）user的心態不正確：不配合、抵制、執著於舊軟體的優良面、精於內鬥。
（4）user的教育水準低落：都是電腦白痴、缺乏企業管理觀念、沒有受過邏輯訓練、亂輸入資料。
（5）合約未能事先說清楚、講明白：
* 軟體商：「需求不明確、變來變去。沒完沒了、貪得無饜的需求，永遠無法滿足」。
* 用戶：「上了賊船」。拒絕付款。
（6）溝通不良：會議開得不夠多，user的EQ不良，顧問未能搞定user的情緒，自己先失控。
（7）上級不配合：老闆沒做到：右手持獎金、左手拿皮鞭，24小時釘住全部員工。顧問費用預算必須加3倍，以免顧問團不爽。
（8）流程規劃不理想。
上列原因，可能都有發生。
但是，都不是失敗的主因。
邏輯是這樣推理的：
（1）「ERP專案管理能力不足」？
那麼，換個專案管理人不就成了？何必等到內爆、見諸媒體、鬧上法院，或買賣雙方聯手掩飾失敗？
（2）「顧問的實力不夠」？
那麼，換一組人數更多、學歷更高、輔導經驗更豐富的顧問群去重新輔導，不就成了，何必鬧上法院？
（3）「user的心態不正確」？
這種障礙，可以用時間去磨、去排除掉。
（4）「user的教育水準低落」？
這種障礙，可以用時間去磨、去排除掉。
「亂輸資料」的確很令人頭痛。但是一般人不會把這種錯怪罪在軟體商、顧問身上。而且，除了銀行、多層傳銷等少數行業外，這種錯通常不足以導致用戶破產。
（5）「合約未能事先說清楚、講明白」：雙方各退一步就皆大歡喜：
(a)用戶自己的MIS人員接手維護（中國人講的「二次開發」）
(b)軟體商打折收尾款
（6）「溝通不良」？
ERP這一行講究硬實力。「開會」通常不能解決技術問題。資料錯誤就是錯誤，未滿足的需求就是未滿足、缺少的功能就是「沒有提供」，「會議」本身無法無中生有。安撫user的情緒，只是表面的妥協、不滿情緒的壓制、累積。
（7）「上級不配合」？
老闆都已經願意掏口袋出鉅資讓MIS主管邊做邊學ERP專案了，還回頭指老闆「不配合」？難道老闆在暗中抵制？
執行細節是MIS與user的任務，不是老闆這種層級應該去承擔的。
（8）「流程規劃不理想」？
那麼，重新規劃不就成了？何必宣告失敗？
上述每一項障礙都能排除、超越。
然而，令人費解的是：未見任何國內、外專家曾經懷疑過ERP新手也能直覺想到的第一個最可能「嫌疑犯」---ERP系統的『品質』不佳，換言之，「ERP不合用」！
*** ERP專案失敗的「真正主要原因」是「ERP系統的『品質』不佳」***
個人積分：15分
文章編號：52500555
走筆至此，也許少數人仍有覺得「ERP系統的『品質』不佳」這句話太隴統、含糊、沒有搔到癢處、不一定是ERP專案失敗的真正主要原因。所以，有具體化這句話的必要。
借用我在台灣和中國兩個工廠任職的粗淺經驗，去揣測【魔鬼終結者】
阿諾史瓦辛格的人事薪資、考勤（這裏就講「Human Resource, HR」）專案是怎麼死的。
台灣和中國這兩家傳統企業的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的要求是「黑/白」、「是/非」、「有/無」、「Yes/No」，絕對沒有模糊的空間。
專案輔導顧問也好，軟體程式設計師也好、資料庫管理師也好，都不可逃避、曲解、轉移焦點。
「有」且「正確」，給100分；「無」或「錯」，退回。
「最佳化」這句哲學用語面對HR的要求時，必須立即丟棄。
軟體專案組人員接到這種case，只有一個解決方案（solution）可以令user、MIS、軟體商、顧問4方皆大歡喜，成功結案。那就是：設計資料庫、程式、報表，一一滿足HR的需求。
SAP為何無法滿足【魔鬼終結者】的真正原因，我認為只有一個：搶單時，包山包海；執行時，未能100%滿足【魔鬼終結者】的需求。
至於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」的皮毛認知，懷疑這些「最新軟體高科技」只是一些舊瓶新裝的重複名詞炒作而已。
面對HR需求，軟體品質不良、拿不出來時，
- COBOL換COBOL的兄弟姊妹ABAP沒有用
- 開會沒有用
- 換顧問沒有用
- 換計畫主持人沒有用
- 加碼預算沒有用
- 溝通沒有用，只會令人更火大、關係更緊張、更瞧不起彼此
- 換SOA、雲端沒有用，除非採人海戰術：（按美國高階程式人員薪資水準估）月薪30萬/每人，投入30人。
「ERP系統的『品質』不佳」，在加州這個case，也許可以這樣指認：
- 該有的，沒有：一些畫面、報表、程式沒有設計給user。
- 不該有的，一大堆：製造業專用的table、ABAP程式殘留在HR系統中，混淆資訊人員的視聽、拖慢系統的運轉速度。
- 開發困難度太高：R/3本身就是半透明的黑盒子。資料庫結構猶如蜘蛛網、技術手冊不一定提供且不保證正確、有隱藏機制或陷阱、「Note（官方發佈的『注意事項』）」滿坑滿谷且很多已失效甚至互相牴觸。
- 低生產力：ABAP。
- 難用：一項功能，必須在多個畫面完成（最多2層的「一對多」單據）；「Note」滿坑滿谷且很多已失效。
統稱「品質不佳、不合用」。
用品質不佳的軟體推大型專案而失敗，不足為奇。
加州這個case，要做的是：
- 設定停損時間點。就是N年前。
- 改用允許深度修改、容易修改的資訊系統開發架構（framework）。
- 1位資料庫設計師、3位程式師上場。
做這項決策，
- 政府花的成本最低
- 最快結案
- 公務員user最滿意
- MIS主管悠閒、拿高薪、穩坐寶座
- 資料庫設計師、程式人員、軟體商收到的報酬最合理
個人積分：77分
文章編號：52500742
個人積分：15分
文章編號：52500867
前文指出ERP專案的真正失敗主因是：選用了品質不良的ERP；MIS部門的諸多管理問題，多源自劣質ERP。
ERP的「品質」應如何定義？
在ERP產業，「品質」只是一個空洞的名詞，「最好」或「the best」也是廣告用語。
「品牌」等於「品質」嗎？用戶數量的多寡等於「品質」嗎？
以上皆非。「品牌」和用戶數量是「市場佔有率」，與「品質」無關。
在中國的ERP專業網站有人在找理想的ERP系統。在眾多建議中，出現了這個回應：
「在預算範圍內，要挑最貴的，最有名氣的，這樣大家都不用擔責任。
比如上SAP，如果有個三長兩短，誰也不好說啥：世界一流的產品你沒用好，你說是誰的原因？」
ERP專家很多。我也厚顏鳴放一番，嘗試把「品質」具體化，請網友指教！
高品質的ERP軟體，必須具有下列特性：
（1）軟體具有高可塑性
世界上不存在一體適用的「萬能ERP」。不贅述「產業不同，則對ERP的功能需求相異』這項大家已知的常識。
在競爭激烈、「毛三到四」的微利時代，企業或政府為求獲利或只求生存，組織的改變幅度和頻率也不得不隨之提高。ERP軟體乃企業的營運工具，當然也必須允許用戶隨時修改、強化，以因應不斷改變的業務活動。
ERP導入專案的「管理藝術」建立在「ERP品質」的基礎上面：
(a) ERP若滿足了user的需求，則user願意配合，甚至不必溝通就直接接受。
(b)如果user對ERP不滿意，就變得很難溝通、「頑固」，醞釀抵制。
試想：使用一套不允許修改的「套裝軟體」，於面對下列經營活動的變更時，MIS人員如何能配合企業的營收來源---行銷部門？
- 電子代工廠的A級客戶採X銷售價格策略，B級客戶採Y銷售價格策略，C級客戶採Z銷售價格策略，AA類客戶沒有議價空間。適用期間時有變動，各種策略與指定期間的銷售量與生產成本連動。
- 百貨公司或大賣場的週年慶促銷活動：三件1000元，購物滿4000元贈500元折價券。
- 連鎖雜貨店的每週四，除了特價商品，全部打95折。
- 客戶於累積消費點數達3000點，可折價買A產品；達2000點，可折價買B產品；達1000點，可折價買C產品。
使用「套裝軟體」的企業，一旦遇到這些隨時可能出現的「不」意外臨時資訊需求，卻未能滿足使用人的時候，「溝通」、「協調」這類「管理」藝術全部失效。通常最後有3種選擇：
(a)請原軟體提供者修改。
(b)將就使用，過一天算一天。捨軟體，採人海戰術。
(c)更換軟體。
身為專業經理人，MIS主管於被告知ERP軟體允許修改之後，仍必須繼續深入追究其真實品質：
（1a）允許深層修改
一套只允許MIS人員增加欄位、MIS人員只能變通：加外掛程式或報表的「套裝軟體」，無法應付企業的業務。
為了應付企業永無止境的經營活動改變，ERP軟體仍必須允許MIS人員做深層、大幅度的修改：
- 改變資料庫架構（schema）：table、欄位等。
- 增加和改寫畫面、業務處理程式、報表。
（1b）容易修改
「ERP系統允許修改」這句話仍不夠明確。高品質的ERP必須容易修改。
技術上很難修改、需要大批軟體人員去維護、無法駕馭的恐龍ERP系統，非「高品質」。ERP之所以恐龍，大抵脫離不了這些特性：
- 系統龐大：資料庫的table、欄位以萬計，程式數十、數百MB。
- 系統文件浩瀚如大海，難以搜尋、錯誤、闕漏、新舊版矛盾，甚至連原廠工程師也無法釐清全貌。
- 程式語言的生產力低，例如：COBOL與其變種兄弟。
- 開發工具或程式語言的進入障礙高，MIS人員短期內難有生產力。
- 專屬、特有的開發工具或程式語言：MIS人員必須接受學校課程以外的訓練。
使用維護困難的ERP的企業，通常最後有3種選擇：
(a)招聘更多MIS人員、幫MIS人員加薪以留住人才。（重複提示：「MIS部門的諸多管理問題，多源自劣質ERP。」）
(b)將就使用，過一天算一天。捨軟體，採人海戰術。
(c)更換軟體。
（2）容易使用、操作簡單
常識告訴我們：越是複雜難用、需要越多人去駕御的ERP軟體，則推動複雜的軟體上線，必須投入較多的資金、人力、時間；運轉複雜的軟體，需要較高檔的硬體、較多的MIS人員、較多的終端使用人。
所以，專業MIS主管應追求易用、簡單的ERP，而非反向操作。
（3）容易安裝
ERP軟體面臨下述情況時，通常需要安裝：
- 啟用ERP軟體前
- 硬體損壞
- 電腦中毒
- 升級ERP版本（中國同行稱之為「打補釘」）
小規模企業的ERP使用人在同一個地點使用同一套ERP軟體，這些工作尚不至於形成困擾。
然而大企業、跨國企業使用同一套ERP軟體時，上述工作負擔與MIS人員的人數、費用、佔用網路頻寬...等各項「成本」息息相關。故MIS主管宜積極選用容易安裝的ERP系統，而非反向操作。
想像一下最極端的例子：client軟體是2片DVD；遍布全國的電腦上千台，必須逐一到場或遙控安裝、維護。
不當膨脹ERP專案規模與上線成本的劣質決策，應避免、可避免。
（5）高安全性
小規模企業對ERP的安全度要求一般不高，大型企業、跨區或跨國企業的MIS主管不宜忽略安全性。ERP系統的運算架構影響安全性。
- 通訊安全：
資料傳輸，宜加密。
如果需要高安全性而ERP軟體的傳輸資料卻不加密，則MIS部門必須額外付費架設Virtual Private Network (VPN）之類的防護措施。這種額外投資成本對user分佈廣、各點用戶數少，的企業負擔更是明顯，例如：連鎖零售業。
- 二層運算架構（資料庫管理系統對接client軟體）的ERP軟體，其安全性較低：
(a)通常在資料庫管理系統與client軟體兩者之間的資料傳輸，無法加密。
(b)資料庫管理系統通常必須允許任何軟體的連接。因此，任何內部人員，甚至外界，都可以使用工具直接連接資料庫管理系統，刪除或修改資料庫內容。
- 盡量避免具SQL injection漏洞。
（4）高運行效率
小規模企業使用低運轉速度的ERP尚可忍受，大型企業的專業MIS主管有義務要求ERP系統的回應速度。
如前述：本人使用過20分鐘不回應的西洋ERP。
- 語言
參見：
Interpreter
Stackoverflow的最佳答案
(a) 執行前，程式碼只經過interpret過的ERP系統，其執行速度最低。
(b) 執行前，程式碼經過just-in-time interpret過的ERP系統，其執行速度次低。
(c) 執行前，程式碼經過compile過的ERP系統，其執行速度最高。
以R3為例：首次打開某些畫面時，系統必須花掉20秒以上的時間去「準備」。系統最後終於「想通了」之後，畫面才出現。
大企業的ERP使用人數多，資料量大，其MIS主管應選擇運轉效率高的輕巧ERP系統，才是名符其實的「專業經理人」。而非反向操作，選擇「大」且「慢」的恐龍。
- 架構層次
本文不談系統出問題的機會之高低，僅討論系統運轉效能。疊床架屋的ERP系統，其整體運轉速度比架構簡單的ERP系統慢：
5層運算架構：
1：資料庫管理系統
2：4GL
3：4GL/HTML轉換器
4：HTTP伺服器
5：瀏覽器
的ERP系統，其運轉速度比3層運算架構的ERP慢：
1：資料庫管理系統
2：應用伺服器軟體
3：client（客戶軟體）
理論上，2層運算架構（1：資料庫管理系統 + 2：client）的運行速度最快。但是有安全性缺點，如前述。
欲兼顧(a)整體ERP系統運作性能與(b)安全性，宜先考慮選擇3層運算架構。
另外，對網路頻寬的要求越低的ERP系統，其「品質」當然越高。
（5）使用高品質的資料庫管理系統。
個人積分：15分
文章編號：52502336
froce wrote:
顧問公司都是抓別人問題，當然不可能抓自己商品的問題。
說得好！
A案例使用的方法放到相似的B案例不一定會有同樣的結果，就算同一行業，ERP也需要依各公司去訂製，
完全同意。
然而ERP產業的亂象是：搶單時，賣方把自己的軟體講得無所不能、可以飛天鑽地、全部合用、套入「世界級的best practice」在買方企業上而使其管理品質蛙跳N+1級層次。
前面有案例可資證明廣告內容和業務總監的話之真、假。
市面上販售整套的大多拿模組下去改，頂多只能說同業有的我也有，要用到同業沒有的就得提錢去，但軟體公司又不是吃你這行飯的，寫出來的東西到底符不符合需求也只有用下去了才知道。
可行的選擇是：選用用戶自己有能力接手修改的系統。除非是小企業。
個人積分：423分
文章編號：52509650
用open source ERP下去自己改嗎？把同樣花幾千萬的經費，找幾個程設工人，假定四個人，一個月共要20萬薪資成本，一年一百四十萬，燒下去，肯定能改出一個符合的ERP.......要快的話，多找幾個，但人月神話肯定要注意。
否則，要找一套能OPEN，能改的ERP，基本上是.......找不到吧！
單單SOURCE要錢，之後授權又要拿一次，而且用越多拿越多，升級又要，純手工做ERP的話.........可能要花二年時間，住在工廠吧！
校能要好，又要能校調，除外又扯系統架構、規劃，又要有彈性，這兩者是嚴重矛盾！這裡指ERP來論，DB join慢，不join table...太大...
另外花個二千萬搞個open stack的聯合運算架構，全部用PC來做，RAM開最大，虛擬化，storeage搞出來，運算效能和不停機就辦得到，PC太便宜了！不然就是找可以單server插1xxG ram以上，以前估過，一台做二十萬，至少買個40台，做open stack肯定夠了！花錢買NetApp做storeage，或是自建ZFS平台，一次插個100顆HD，保證I/O不再是問題。
