信息系統項目失敗的原因分析及對策

李惠

（南京富士通南大軟件技術有限公司 江蘇省南京市 210012）

1 引言

根據PMI（Project Management Institute）的報告Pulse of the Profession 2020，從系統的目標達成（MetGoals）、滿足預算(Within budget)、及時交付(On Time)、范圍蔓延(Scope creep)、項目失敗（Project failures）五個方面看，在各類組織中，信息系統研發和運營方面都存在諸多問題。如果將以上五個方面中的任一方面未達成則視作項目失敗的話，則失敗率將超過50%。分析項目失敗的原因并找出解決方案，對提高項目的成功率尤為重要。

本文將結合筆者的實踐，提出一種改進的信息系統項目失敗的原因分析模型，并提出基于敏捷軟件開發的模型來解決項目失敗的問題。

2 信息系統失敗原因分析模型

Rajiv Sabherwal 等人提出信息系統成功的個人與組織決定因素中，基于信息系統成功、用戶相關和情景相關三個維度，從信息系統購買方（后文統稱甲方）的角度進行分析和建模，可以很好地對信息系統是否成功進行評價[1]。但是，該模型忽略了信息系統的提供方（后文統稱乙方）和開發過程。對于項目失敗的原因分析，不僅要從甲方，也需要從乙方的角度進行分析。筆者結合多年的從業經驗，借鑒Rajiv Sabherwal 等人的評價模型，從系統、情景、人員、商務4 個維度出發，結合甲方和乙方的視角進行信息系統失敗的原因分析。分析模型如表1所示。

3 信息系統項目失敗原因分析

3.1 系統因素

從系統因素出發，主要有如下3 個方面對系統的失敗有重大影響。

3.1.1 需求不明確

在過去的幾十年里，各企事業單位導入的各種信息系統，大多都借鑒了國外成熟的系統和實施方法，需求相對容易把握。但是最近幾年，伴隨著數字化技術的發展，需要向數據要價值，這方面還處于探索階段，且各行各業的數據差異大，甲方的訴求也大不相同，因此需求也相當不明確，導致項目的難度變大。

3.1.2 準備不充分

大多數企業對信息系統寄予了過高的期望，以為導入信息系統可以解決一切問題，比如生產制造企業，以為導入了ERP、MES等系統后，馬上可以起到降低庫存、提高產能等效果。但實際上，信息系統是幫助客戶固化標準流程，可以提高工作效率和資源利用率，而不能從主觀上幫助企業梳理業務流程[2]。因此在導入信息系統之前，必須首先對業務流程進行梳理，將工作流程進行標準化。企業在沒有將業務理順之前就上馬信息系統，往往導致達不到既定目標，從而把責任怪罪到信息系統上。

3.1.3 計劃不切實際

由于諸多原因，信息系統開發項目一般周期都比較短。大多數企業要求簽訂合同兩～三個月以內甚至更短的周期內交付系統。乙方面對一個完不成的計劃，而又不愿意失去商機，就只能在各個方面進行“偷工減料”，項目失敗的概率也大幅提高。

3.2 情景因素

情景因素主要是公司高層的支持以及各種面向項目的政策支持，是信息系統開發成功的助推劑。

表1：信息系統項目失敗分析模型

表 2：基于Scrum 的解決方案

3.2.1 高層支持

信息系統從立項到開發實施再到后期運用，都離不開高層支持，因為高層的支持，代表了公司意志，員工必須遵照執行。同時高層具有較大的權力，比如人事評價、資源調度等，這些權力影響著員工個人的利益。因此高層出席項目的里程碑會議、在各種場合對項目鼓勵等，影響著所有項目干系人，能加強他們對項目的認同感和責任感，對項目的成功起到關鍵作用[3]。

3.2.2 促進因素

在導入信息系統時，適當的促進因素有助于提升用戶的參與。比如給予參與項目的員工一些表揚甚至是物質性獎勵。

3.3 人員因素

信息系統的開發和運用都離不開人的參與。經常會有一種誤解：信息系統的開發階段是乙方開發團隊的事，上線運營后是甲方運營團隊的事。但是一個真正成功的信息系統，無論是開發階段還是使用階段，都離不開甲乙雙方開發和運營團隊的共同參與。

3.3.1 客戶參與度

客戶的積極參與是項目成功的關鍵[4]。無論是業務調研階段還是開發過程中的需求確認，都需要典型客戶代表以及具有最終決定權的關鍵干系人參與。客戶參與度不高的話，往往會導致問題在項目后期或者交付后才被發現，糾錯代價極高。

3.3.2 開發團隊技能

毋庸置疑，開發團隊的技能，無論是項目管理水平還是技術能力，都直接影響項目的進度、質量和成本。好的項目經理對外積極主動與客戶溝通、把握項目范圍，對內制定計劃、協調資源并按照計劃推進。而項目組的編碼人員的能力也至關重要，好的程序員不僅效率比普通人員高，而且代碼質量更好。

3.4 商務因素

商務因素有很多，這里主要指信息系統開發實施的價格和邊界兩個因素。

3.4.1 合理價格

在信息系統建設過程中，如果乙方的收益不能保證合理的利潤，又沒有其他值得期待的收益（比如進入某個行業、樹立標桿客戶等），則很容易導致乙方“偷工減料”。價格之所以出現不合理的情況，可能是惡意競標、層層轉包等原因導致的。

3.4.2 邊界明確

信息系統作為軟件項目，往往很難對開發范圍進行非常精準的界定。實際操作中，往往是靠甲乙雙方不斷交流逐步明確邊界，交流的過程是一個相互博弈的過程。如果甲乙雙方不能進行良好的溝通，將會導致需求蔓延，最終導致項目失敗。

4 避免信息系統項目失敗的對策

根據前文的原因分析，可以發現大部分的問題都通過甲乙雙方進行深入交流、共同明確需求和計劃并不斷迭代以降低風險進行解決。而敏捷開發模式本身具備的特征，正好可以作為解決信息系統項目失敗的一種解決方案。

4.1 敏捷軟件開發

敏捷軟件開發方法出現于上世紀60年代，90年代開始，一些開發方法如Rapid Application Development（RAD）、Scrum、Extreme Programming (XP)等越來越受到人們的關注，特別是Scrum 和XP 的實踐者甚多。這些方法論強調了四個方面：

（1）開發團隊和業務干系人之間的密切合作；

（2）商業價值頻繁交付；

（3）緊密合作的自組織團隊；

（4）代碼匠藝、驗證和交付代碼的巧妙方法[5]。

2001年2月，17 位軟件行業領軍人物聚在一起，共同發布了敏捷軟件開發宣言和十二條原則。基于敏捷宣言定義的價值觀和原則的一系列方法和實踐的總稱就是敏捷軟件開發模式[5]。其中“客戶合作高于合同談判、響應變化高于遵循計劃[6]”的思想對解決信息系統的失敗有很好的啟迪。

Scrum 是敏捷開發方法的一種實踐，是開發和持續支持復雜產品一個框架。在這個框架中，整個開發過程由若干個長度為一到四周的Sprint 組成，每個Sprint 優先開發對客戶具有較高價值的需求[7]。

4.2 Scrum解決信息系統失敗的方案

根據Scrum 開發框架的特征，結合信息系統項目失敗的原因，制定面向信息系統開發的解決方案，如表2所示。

根據Scrum 的角色、工件和事件分別對甲方和乙方的相關干系人進行定義。

（1）甲方工作內容：甲方派出人員作為產品負責人（Product Owner，簡稱：PO），收集需求，決定開發內容，即產品列表；同時決定每個Sprint 開發列表，并參與每個Sprint 的計劃會議和評審會議。根據敏捷宣言中“業務人員和開發人員必須相互合作，項目中的每一天都不例外”的規定，甲方的PO 作為專職人員，隨時保持與項目開發人員的溝通。另外，PO 必須具有一定的影響力，能夠從業務人員處收集到真實的需求，并且能夠在重要的里程碑節點，邀請高層人員試用并對系統進行評價。

（2）乙方人員擔任ScrumMaster（簡稱：SM）和開發團隊的角色，主要負責各產品列表的實現工作，提交可見的成果供甲方驗證。乙方人員必須參與計劃會議，討論Sprint 的工作內容；參加每日站會，匯報進度和工作成果，及時解決每日問題；參加評審會議，了解客戶的反饋；參加回顧會議，不斷進行反省和提高。

通過基于Scrum 開發框架的解決方案，可以解決信息系統失敗原因中的“需求明確性、計劃合理性、高層支持、客戶參與度、邊界界定”等導致的問題。由于雙方統一了戰線，形成了一個有機整體，因此對需求、計劃的理解和制定將更加趨向一致。對于“準備充分度”原因導致的項目失敗，通過甲方人員擔任PO 角色可以得到很大程度的改善。由于每兩周就發布一個版本，因此可以將版本及時提供給重要干系人試用，及時了解他們的想法，通過持續吸引重要干系人的關注，從而解決“高層支持、促進因素”的問題。

另外，對于需求尚不明確的信息系統，也可以通過Scrum 開發框架，采用POC（Proof of Concept）的思想進行驗證，當發現結果不理想時可以及時終止項目，及時止損。

關于“價格合理”的問題，Scrum 框架雖然無法直接解決，但是由于雙方人員是一個有機的整體，雙方交流頻繁，信任程度將得到大幅提高，因此對于合同價格的惡意競爭將大幅減少，甚至只是簽訂框架性合同，然后根據每個Sprint 的工作量進行結算。

5 小結

在信息系統開發過程中，雖然采用Scrum 框架可以解決現有問題，但是也面臨如下兩個方面的課題：

5.1 甲方配合度問題

雖然甲方人員作為產品負責人，但是往往不能100%專職，以及可能產品經驗不足，導致人不能勝任。這種情況下，需要乙方有經驗的人員主動輔佐，齊心協力干好產品負責人的工作。

5.2 乙方不能主動進行改善的問題

由于敏捷軟件開發決定了雙方的透明度，乙方在工作過程中提出的各種節省成本、提高質量等方面的改善都很難有新的回報，因此容易導致乙方不再積極主動進行各種生產改善，導致團隊整體能力和工作效率不能提升。

雖然Scrum 框架可以解決信息系統失敗原因中的諸多問題，但是由于在實操層面還有一些課題，因此需要根據實際情況進行調整。在具體項目實施時，不應生搬硬套敏捷開發框架，而應該把握敏捷思維，結合實際情況選擇最優的做法，爭取項目的成功。