盡管平時在ITValue社區或是電子周刊中討論和報道的都是一些優秀企業的信息化成功案例，但也有CIO在社區中提出，在這些企業中，或是一些不那么成功或優秀的企業中，也一定會有很多失敗或是不那么成功的信息化項目，這些失敗所體現出來的經驗教訓似乎對CIO們做好信息化更有幫助和警示作用，也更能夠讓我們在信息化光環之外，體會到更多的東西，感受到更多的真實。

一些CIO在ITValue中分享了他們所知或所經歷的失敗案例，因為其中很多涉及到企業機密，因此以下案例將以匿名的方式呈現，并作了部分簡化和改寫。

案例一：
這個事情發生在某公司剛采用軟件外包服務的時候。相對于這家公司原本合作過的一兩家規模較小的企業來說，這家外包公司一開始就給CIO留下了很深的印象，派了個老外來談業務，開發的方法論以及整體的架構都看起來非常的專業，很快便與對方總經理見面詳談，認可了對方經營團隊表現出來的專業度。到實質的項目合作階段，從簽定NDA防止泄密開始，到提出規格書給對方，到具體排定開發進度以及報價，在報價階段，對方展現了非常大的彈性和誠意，很快雙方就簽了約。

項目前期，一切都還在控制之中，部門的項目經理在前期跟CIO報告過對方除了項目經理以外的人員都畢業不超過一年時，CIO認為對方的管理制度應該解決和面對這類問題，甲方只要定期審核項目進度就可以了，所以不以為意。

到了項目的后期階段，問題終于爆發出來了。首先是要求對方做功能性的演示，發現整個流程甚至不能完整的跑完，對方為了趕進度，居然沒有做好內部的QA環節，導致質量出現很大的問題。然后再出現很大的效能問題，程序的效能慢到無法接受，用戶界面的友好性也完全無法接受。這個時候，他們的反饋居然是這些并沒有明確定義在甲方提供的規格書當中，所以并不能算是乙方的問題。實際上，通過檢查源代碼，發現乙方的5個開發人員是完全各自按照自己的思路開發，而非遵循通常的統一開發流程。

還好，對方的銷售人員還算愿意負責，承認他們的錯誤，大家友好的協商如何能夠把項目結掉，但這個時候又發生了幾件事情。

首先，開發人員產生很大的抵觸情緒，認為他們按照規格來開發是沒有錯誤的，現在要返工，對開發人員是不公平的，這個情緒直接導致開發人員效率不高。再來，發現項目質量有問題之后，對方的QA開始投入項目中，在項目質量及項目進度的雙重壓力下，居然導致了QA以及開發人員的對立，對方銷售人員答應的進度因此一再跳票。用戶則不斷的在內部質疑項目到底何時能夠上線。更離譜的是，乙方的項目經理居然在這個節骨眼，被抽調到另一個大客戶的項目中。這導致甲方不得不要求就地結案，不付尾款。最后找了一個原來報價高出很多的供應商來做收尾工作，系統上線至少被推遲了三個月。

案例二：
3年前某集團開始做整體信息化的時候，經過招標選型，最后和國內某知名管理軟件公司簽約。除了集中財務管理、人事管理系統和OA辦公系統之外，還牽扯到對主營業務的管理。由于主營業務的管理在市場上沒有合適的商品化軟件匹配，最后考慮定制開發，出于品牌效應和質量考慮，選擇由同一家供應商來做。甲方為了幫助軟件公司熟悉業務，還提前做了很多需求整理的工作，幫對方理清了需求的大框架。

但隨后問題就出現了。對方并沒有按合同簽訂的1個月內安排開發團隊進場，一直抽不出足夠的人手。多方溝通、交涉，終于在6個月后入場，但對方的開發團隊不是本地的，而是在另外一個城市做開發，后來協調為對方在調研期間每周過來一次，開發期間每月過來一次。

需求調研和開發過程還算順利，人員能力不錯，過程中發現的較明顯的問題要求對方整改，對方也表示沒問題。半年后初版開發完成，開始給試點用戶培訓，并開展內測。

隨后便發現很多嚴重的問題，遂要求對方派人現場駐點進行修改，連續兩個月，越試用，發現的問題越多；越了解，發現對方的團隊，除了一個有經驗的程序員外，其他幾個都是剛畢業的大學生，后面的代碼都是菜鳥寫的。然后，就是反復的僵持和扯皮，甲方覺得軟件問題很多，功能有缺陷，質量和穩定性很差；乙方覺得甲方的需求老是在變，要求太高，他們駐場的成本費用太高。

就在這關鍵時刻，公司決定在另一個城市啟動一個投資幾億的重大項目，主要的業務高管和業務骨干，大部分都被抽調到該城市，項目的試點和實施幾近于停滯。CIO不得不暫停實施，砍掉一些非關鍵的業務功能，只保留系統的核心功能，以避免整體失敗。一年后，公司在另一個城市的項目結束，一切才又回到正軌。

案例三：
某大型電子產品零售分銷企業，投資100多萬，和國內某知名軟件公司簽約，進行財務集中管理和供應鏈管理。一年后，項目實際上已經失敗。現在該公司只用了財務集中管理軟件，其供應鏈管理軟件又換回了原來用的某小企業開發的分銷ERP管理軟件。

案例四：
某大型家具制造企業，投資幾百萬，和國內某知名軟件公司簽約，進行全面的信息化。經過一兩年，項目也幾近失敗。后來該公司從外部引進一牛人擔任CIO。該CIO上任后，分批逐步中斷了與該軟件公司的合作項目。全部采用某國外知名ERP公司的全套管理軟件，現在逐步進入正軌。

案例五：
一家很有名的跨國公司的亞太CIO，公司的核心管理系統做了五六年了，但至今仍只上了一個MRP系統，其中不成功的項目很多，但究其原因還是因為其中國戰略不穩定，公司一直分分合合，業務環境尚不明朗，職權分配都不清楚，要做成一個項目太難了，雖然他們公司用的系統都是最好的。項目失敗和公司業務發展有根本聯系。

案例六：
某公司有一次系統上線，時間緊迫，業務負責人要求不做盤庫，直接拿舊的手工賬做數據的遷移，結果導致上線后的MRP失敗，原因是實際庫存和賬面差異很大。

CIO維基的從項目失敗中總結的教訓與經驗

1、項目經理一定要想辦法保持自己對于乙方的控制權，并且在項目遇到麻煩的時候，甚至可以果斷的暫停項目，對乙方施加強硬的措施，不能為了所謂的整體利益或者后續合作，而委曲求全，最后導致更大的危機出現。

2、在制定項目計劃的時候，一定要具有前瞻性，不要和公司其他的重大項目在時間和人員安排上面發生沖突，否則到時候被PK掉的一定是信息化項目。
3、信息化項目的應用水平，一定要和公司的管理基礎和水平相匹配，如果試圖在公司自身的管理還不規范的時候，達到一個理想的效果，最后只可能連最基本的功能都做不好。

4、諸如財務或OA之類的標準化程度較高的系統，一般失敗的幾率很小，感覺真正容易發生問題的項目，一般都是業務管理軟件，特別是定制開發的，或者是選型不當的。

5、永遠不遷就業務的一些不合理要求，該做的就是要不折不扣的完成。

6、項目還沒開始就要有內部和外部的大概議事規則等，選型時候對項目負責人的預見力和洞察力的要求還是蠻高的。

7、任何項目在選型、選產品、選合作團隊的時候，作為甲方負責人我認為最關注的應該是要圍繞“如果我來負責這個項目，結合自己在甲方的位置和影響力及個人能力，團隊能力，應該如何選擇產品和顧問團隊，來保障項目成功，并且過程和結果能夠較為可控制”。

8、供應商在選型和談判階段，為了能夠拿到項目，很多條件都可以答應，不合理的價格也可接受，這就為后面的風險埋下了伏筆。建議大家以后一定要在合同中，對乙方團隊的人員予以明確約定，并就違約責任約定清楚，這樣才能加強對乙方人員的管控。

9、有些企業項目的立項和預算是業務部門主導的，很多項目是業務做好后交給IT運維。項目的立項和實施缺乏全面的統籌，實施過程中企業的IT人員沒有很好的跟進和了解系統，系統為了上線又做了大量的客戶化開發，后期運維的費用又不足以支撐這些開發導致的繼續開發。

10、ERP的失敗比ERP的成功更有教益，不管是對自己還是對別人。IT項目的失敗其實很普遍，據分析，信息系統失敗的概率是70%。這么多年從事信息化，應該說特別失敗的案例沒有，但每一個項目其實都很不容易，如果沒有必勝的信心和執著的堅持，是很難取得成功的。有些項目甚至是經過幾年的努力才堅持下來，最后取得一定效果的。

11、公司戰略不穩定，公司一直分分合合，業務環境尚不明朗，職權分配都不清楚，信息化項目由此艱難。

12、階段性成果后，甲方該支付乙方的款項應及時支付，對結果的擔心可能造成對雙方合作關系的直接傷害。

13、綜合分析，得出幾大類原因：公司戰略不明確；上線時機選擇不對；業務需求不明確、人員不配合；供應商不配合，能力差；信息化制度、機制不明確。