讀「五個 ERP 失敗個案」有感

作者：蔡煥麟
日期：May-17-2002

2002 年 4 月號的「資訊與電腦」雜誌有一篇標題為「五個 ERP 失敗個案」的文章，作者是林存德。我一邊讀著，一邊想到之前曾經參與過的一個專案，想著想著，覺得有些東西可以記錄下來，偶爾回來看一下，也許可以從歷史教訓當中提醒自己避免犯同樣的錯誤。

在該文中，作者實際走訪了五家 PCB 產業，訪問了 MIS 人員、負責導入 ERP 系統的業者和顧問，並列舉每個個案的背景、現況（有的系統被客戶放棄，有的處於訴訟階段）、及失敗原因，我把幾個失敗原因摘列於下：

• Web-based 技術不成熟，當同時上線的使用者（concurrent user）超過 20 人以上，整個效能就會下降。
• 軟體廠商對該公司的 MIS 說：最好每隔一週就重新開機，軟體廠商說這是作業系統的問題；MIS 說：那不就是每隔一段時間就要求所有使用者都斷線一次？這可是三班制的公司耶！
• 顧問缺乏經驗，客戶成為顧問公司的教育訓練場。
• 軟體公司搖搖欲墜，主要菁英多已離職，造成對用戶所提出的需求往往要耗時極久才有回應，也讓用戶對軟體公司沒信心。
• 部分軟體模組不堪使用，套句用戶的話：能用多少就用多少。
• 客戶對使用者介面的需求不斷變更，弄錯導入重點；更甚者是，雙方的專案負責人（PM）都只是行政上的 PM！
• 關鍵使用者（key user）指定錯誤，把 MIS 視為關鍵使用者，同時請工讀生輸入資料，真正的用戶本身並不參與，而雙方的負責人竟可容許這樣的事情存在。
• 部分顧問過於「溫和」，面對強悍的用戶無法適當的強勢引導。
• 軟體公司開發速度過慢。

需要重新開機的伺服器

其中有一項很有意思：每個星期要將伺服器重新開機。看到這裡，我幾乎是反射動作地聯想到之前參與過的一個案子，為了避免不必要的麻煩，在這裡就以 C 專案來稱呼它好了。C 專案採用 Windows DNA（Distributed interNet Application）架構，分散於全台各地的用戶端透過專線連接至總公司，同時上線的用戶端數量約 30∼40，資料庫採用 SQL Server 2000，開發工具是 Delphi 5 企業版。記得系統剛上線時也是問題百出，相當混亂，總公司經常接到各地的用戶端打來的抱怨電話，大多是程式無法執行，或者速度太慢，讓他們的客人等太久。而我們的工程師則忙著四處奔走解決問題，甚至 24 小時派人輪流駐守機房，觀察應用程式伺服器和資料庫伺服器的運作狀況。幾番折騰，這才發現資料庫伺服器和應用程式伺服器的的記憶體資源很快就耗盡了，導致效能極差甚至當機，而且常常是資料庫伺服器先掛掉，接著引發 COM+ 元件無法處理交易，連帶地用戶端也受到影響而無法作業。

後來經過修改程式以及調整 COM+ 元件組態，使整個系統在理論上可以 7x24 小時運作，不用重新開機，但是由於 C 公司的作業型態是在假日及晚上特別忙碌，而且各地的用戶端需求同時湧入伺服器，交易量可以說是在同一個短時間內達到高峰，導致 COM+ 元件使用的記憶體不斷成長而少有機會釋放，而作為應用程式伺服器的機器效率又太差，記憶體容量也嚴重不足，因此尖峰時期系統仍有資源耗盡以致當機的可能。這個專案最後當然在使用者的抱怨聲中停止後續的開發了。

失敗因素

綜觀 C 專案的失敗因素，我覺得有下列幾點：

1. 初期硬體和網路架構未正確評估。
2. 系統完成了大部分的功能後才上線，太晚發現問題。
3. 全台門市一次上線，問題百出，令自己忙得雞飛狗跳，客戶失去信心。
4. 沒有實際走訪門市，探尋 end user 的使用需求和意見，也無法得知整個作業的程序和狀況。
5. 當效能瓶頸的問題發生時，客戶只抓住當初的軟硬體架構評估不當的辮子不放，卻不同時想辦法提昇自身的硬體效能，最後應用程式伺服器效能仍然低落，網路頻寬也只是調整上傳/下傳的傳輸比率而已，整體而言根本沒啥幫助。
6. 系統上線後，客戶那邊才出現一位 CIO 來接管這個系統，打破雙方原本已經建立起來的配合默契。
7. Windows 2000 和 COM+ 的缺陷。經測試發現，系統資源耗盡的元兇之一是 Windows 2000 的臭虫，在安裝了 Service Pack 2 之後獲得改善，但是 COM+ 對於元件生命週期的控制缺乏彈性卻無法完全解決，雖然微軟在 Windows XP 裡面的 COM+ 已針對這點改善，可是 Windows 2000 的用戶並無法享受到這個好處。

上面幾點當中，我認為初期的硬體環境和網路架構沒有正確評估是導致此專案失敗的最主要原因，怎麼說呢？

系統上線之後，我們的工程師才發現資料庫伺服器和應用程式伺服器的記憶體都只有 128MB（老天！），而那台 Windows 2000 應用程式伺服器上面除了 IIS 之外，竟然還裝了 AD（Active Directory）！真讓人哭笑不得，光是 AD 就要配給它 128MB 左右的記憶體了，哪裡還有剩下的記憶體給 COM+ 應用程式？況且以該公司當時的環境而言根本不需要 AD。至於網路方面，事前被告知專線頻寬是 128K，但後來才發現是 64K，雖然這不是效能低落的最主要因素，但是卻也可能造成開發人員在系統分析設計上的差異，在某些地方改用比較簡單卻需要較長的資料傳輸時間的方式來撰寫程式。

由於當初整個硬體設備是由其他單位負責規劃的，事前沒有徵詢過軟體部門的意見，到後來反而是當初未參與決策規劃的工程師去面對客戶的責難，既然是同一家公司，說什麼也只有扛下來了，這牽涉到公司管理愈制度面的問題，就不多談了。其實只要伺服器加裝幾條 DRAM 就可以大幅改善效能了，為什麼不做？除了這兩台伺服器的 DRAM 特別貴之外，客戶的固執也是一大原因，其一味責怪軟體廠商，卻不接受建議改善其硬體設備的做法，只會令軟體廠商感到無力，對整個系統的推行完全沒有幫助，最後雙方都是輸家。

結語

資訊系統開發不是只有系統分析設計和程式設計而已，初期的硬體環境評估的結果對日後軟體運作的成敗有著關鍵性的影響，如果系統規劃或架構評估人員對軟體的需求和架構不清楚，就應該向軟體開發人員（最好是 architect）尋求建議和協助，要不然在初期評估階段就應該找相關的技術人員陪同，綜合各方意見，並配合循環與漸進的開發方式，及早發現問題並加以修正，否則專案導入失敗、爭執訴訟、道歉賠償、疲於奔命以技術補強的戲碼將不斷上演。