項目管理理論中關於軟件項目外包採購管理的探討

1、基本概念和背景

　　項目管理理論是一門綜合多門學科的新興研究領域，共有九大知識領域，包括項目集成管理、項目範圍管理、項目時間管理、項目費用管理、項目質量管理、項目人力資源管理、項目溝通管理、項目風險管理和項目採購管理。項目採購管理是指須要從執行組織之外得到貨物和服務的過程。一般把貨物和服務稱爲產品，把買方稱爲業主或對應分承製方的總承包商，而賣方稱爲承包商、廠商或供應商。項目採購管理通常包括如下主要過程：採購計劃編制，詢價計劃編制，詢價，承包商選擇，合同管理，合同收尾[ 1 ].對於軟件產品，通常採購能夠分爲兩大類，一類是對已經在市場流通的軟件產品進行採購。例如，某企業想作信息化建設項目，涉及到數據庫，那麼它就能夠在目前市面流行通用的幾種廠家和種類的數據庫中選擇。例如Oracle公司的Oracle數據庫，Microsoft 公司的SQL Sever，IBM公司的DB2數據庫等等。而後根據本身的需求，經過詢價、籤合同、安裝培訓等過程來購買此類產品。這種採購過程基本已經造成幾套通用的解決方案，比較簡單，中國企業在處理這類產品的採購時，大部分都處理的較好。個別的企業因爲需求分析不清晰，培訓工做不到位等緣由，也會產生購買的產品不適用，或不會用的狀況。另一類軟件產品採購的形式是外包採購。它是指在市場上沒有出現現成的產品或者沒有適合本身企業需求的產品的狀況下，須要以定製的方式把項目（功能模塊）承包給其餘企業。例如某企業須要實施企業資源計劃項目（ERP），雖然能夠購買BAAN軟件，可是基於本企業業務流程的管理軟件必須定製，對於各個原有孤立島的集成軟件，沒法購買現成的產品，必須本身開發或外包給別的公司。

　　2、 軟件項目外包採購管理的意義許多大型複雜工程項目的實施須要業主、總承包商、分承製商、供應商和開發製造商等共同合做來完成。所以在任何甲方和乙方之間必不可少的涉及到部分子項目（功能模塊）的採購活動。目前社會中，企業的信息化、網絡化建設正在世界範圍內展開。誰先進行信息化改造，誰就早日適應社會發展的要求，得到鉅額利潤。大規模的企業信息化建設造成了龐大的軟件產品市場，促進了軟件業的發展。許多項目龐大複雜、高風險而且涉及高科技信息領域，在客觀上使企業須要採購和外包許多產品，包括軟件產品。主觀上，在經濟全球一體化形式下，這種外包採購做爲採購活動的一種特殊的、更爲複雜的形式，在企業中更爲廣泛存在。企業爲了在日益競爭的社會環境中加強自身的核心競爭力，須要根據企業的特色，專門從事某一個領域或幾個領域的業務，在某個業務領域內造成本身的核心業務，把企業內部的智能和資源集中在那些有核心競爭優點的活動上；把一些非本身擅長的業務領域的子項目和功能模塊外包給有實力和優點的公司，纔有利於加快項目的完工進度，下降風險，優化資源配製，保證項目質量，下降成本，創造更高的價值。

　　以電信行業爲例，愛立信公司2000年末宣佈把手機生產的絕大部分業務外包給新加坡的 Flextronics公司，專一於移動通訊網絡設備業務。緣由是愛立信的移動通訊網絡設備的銷售佔愛立信公司銷售額的54%，利潤達90%以上，佔有全球的移動通訊市場分額高達30%，而手機生產的投資回報率很底，甚至出現虧損狀況。對於愛立信而言，手機生產"外包"是在信息化時代的戰略調整，但願經過外包生產，調整投資結構，使手機下降成本而且儘快盈利，集中精力穩定和拓展電信業的新市場。出於一樣目的，美國的摩托羅拉公司也表示將外包部分地區的手機生產業務。做爲手機市場份額最大的諾基亞，在專一於手機生產業務的同時，大力開發周邊產業。但願以手機業務帶動相關產業的發展。從三大公司的投資趨勢，能夠看出，"外包"做爲一種先進的國際專業化的生產方式正被一些大公司愈來愈多的採用。我國正處在信息化建設的高速發展階段，必然會有愈來愈多的企業因爲自身的能力限制或業務發展的戰略選擇，將採起業務"外包"的生產方式。

　　就軟件項目外包採購的市場來講，2000年是企業信息化實施的第一年，國內企業，特別是大型企業的信息化項目開始運做。行業信息化改造重點將由原來的電信、金融、海關等行業轉向交通、製造、醫療等傳統行業。這些行業因爲自身計算機技術水平和業務發展重點的緣由，將會把大量的軟件項目外包給軟件公司。根據CCID的統計（軟件能夠分紅平臺軟件、中間軟件和應用軟件），2000年中國軟件市場中應用軟件的銷售額爲147億元，佔軟件總市場份額的63.9%.預計到2005年，計算機信息服務和軟件市場銷售額增加到1750億元。屆時我國軟件項目"外包"市場潛力可想而知。

　　3、軟件外包採購管理存在的問題雖然在傳統行業，許多工程項目的採購活動，例如機械工程項目或建築工程項目等等已經造成比較成熟的管理體制和標準。可是軟件項目的外包管理工做並不象其餘行業那樣順利。

　　軟件工程項目管理引發普遍注意源於20世紀70年代中期，當時發現70%的項目是由於管理不善而引發。20世紀90年代中期，美國的軟件開發仍然很難預測，大約只有10%的項目可以在預約的費用和進度下交付。商用軟件一般只有9%（中小型軟件公司有16%）的軟件項目可以及時交付且費用並不超支。

　　這裏有多方面的緣由：軟件產品做爲一種特殊商品形式，具備高度不可測量性和高度柔性；軟件企業開發能力還不太成熟，軟件開發大多數還處於手工做坊方式，軟件研發企業有其自身的運作方式，人爲因素比重大，很差量化管理。因爲不肯定因素太多，許多軟件開發企業對於本身的項目都難以精確控制進度、質量、資源和成本，那麼對於業主來講，想對外部企業（例如分承製商）保持良好控制力的難度就更大了。再加上具備技術優點的軟件開發商通常集中在幾個科技發達的大城市，與業主的距離遠，相互的交流不方便，所以許多軟件採購項目的實際應用效果都差強人意：不適用，進度超期，性能達不到標準，成本過高等等狀況時有發生。

　　軟件項目外包採購的成功與失敗不只僅影響到當前軟件項目的質量、成本和工做進度，並且關係到企業信息化建設整個項目的總體結構、性能以及進度，意義重大。特別是當軟件項目做爲總體項目計劃關鍵路徑的一個環節，軟件項目採購的進度直接影響總體項目的進度，而且總成本將成指數級增長。因爲軟件採購的狀況特別複雜，涉及的學科領域不只是科學技術上的，還有商業上的和觀念上的，軟件項目外包採購管理水平的高低，將直接關係到企業整個信息化建設進程。所以軟件項目採購管理做爲項目管理理論中一個新的研究課題，有必要給予足夠的重視。

　　3、 目前軟件外包採購管理狀況美國項目管理協會的"項目管理知識體系指南"（PMBOK）[1]、美國卡內基-梅隆大學軟件工程研究所的"軟件能力成熟度模型"（CMM）[2，3]和國際標準ISO9000-3[4]中雖然對外包採購管理的流程有過論述，可是他們指出的只是外包採購管理的通常原則；雖然人們能夠結合自身企業特色實施標準，具備必定靈活性，可是事物的另外一對立面就是操做過程不具體。這給軟件產品的外包採購管理者帶來具體操做上的困惑。另外PMBOK體系原則上是應用在各個行業的，缺少針對軟件領域的特色作專門的論述。ISO 9000-3系列和CMM雖然是針對軟件領域的標準，可是ISO 9000-3的最大的特色是隻告訴你要按規定作，不強調效果和後續改善，不強調經驗積累和後評估。從這個意義上講ISO9000注重水平的評估，不太強調提升企業成長的過程，所以對於提升企業的管理水平意義不大；CMM雖然旨在強調企業的過程能力的持續改進，可是它重點強調軟件的開發過程管理和產品管理，缺少軟件的分發、轉交和服務等方面的管理標準，因此也有必定的侷限性。

　　4、 基於"共贏"策略的軟件外包採購思想本文做者在集成美國項目管理協會的"項目管理知識體系指南"（PMBOK）和美國卡內基-梅隆大學軟件工程研究所的"軟件能力成熟度模型"（SW-CMM，SA-CMM）和ISO9000-3中關於外包採購的宗旨的基礎上提出"共贏"策略的軟件外包採購思想。

　　"共贏"策略的軟件外包採購思想旨在利用雙方業務能力互補，經過共同合做完成軟件外包項目，達到"共贏"的目的，促進雙方業務整體能力的提升。這種"共贏"策略要求雙方在如下方面達成共識：雙方共同關注過程控制，才能保證有效結果；只能成功，不能期望依靠懲罰手段來收回採購成本，軟件外包採購項目的失敗對整個項目帶來的損失是巨大的；在合做過程當中，創建對分承製商關係的管理體系，做爲之後合做的基礎；重視開發過程的風險評估和採購項目後評估，使得雙方業務能力獲得持續提升。

　　傳統的外包採購中，採購方只關心分承製商產品的進度和質量，覺得只要分承製商定期、按質交貨，就能夠圓滿結束這次採購活動。有些項目儘管前期進度和質量知足合同要求，可是許可能是以高投入、高負荷、高消耗等手段來保證的，這給後期帶來極高的風險。在階段評審中，若是採購方對分承製商開發過程當中的費用投入、人員負荷、資源消耗、組織結構變化等不聞不問，所以就不能及早預見風險、控制風險。很難想象，後期在費用透支、人員疲憊或流失嚴重的狀況下，分承製商仍能保證產品質量和進度。這種狀況下，採購方只能要麼加大投入，要麼終止合同，並要求賠償，要麼延期驗收等等。其反作用可想而知。而分承製商爲了減小損失，根據博弈論中子博弈精練納什均衡原理，必然採起下降質量要求，減小投入的策略，來加快進度。結果最終仍是採購方遭受損失。

　　5、 軟件項目外包採購管理過程爲了保證軟件外包採購項目的順利進行，本文做者在上訴理論體系和"共贏"採購策略的基礎上，提出和細化了軟件項目外包採購的整體框架和具體操做內容，旨在爲軟件項目外包採購管理人員提供具體的可操做過程。

　　對於本採購過程，若是業主方因爲行業、人員等緣由，沒有健全的監控部門，能夠聘請具備軟件監理職責的公司，或者總承包給具備必定軟件工程監控能力的公司。這時的總承包公司角色至關於本文提到的採購部。

　　軟件項目的整個外包採購過程能夠分爲十個工做階段，包括整體項目需求分析和設計、子項目的需求分析、廠商選擇、分承製商開發、業主階段評估、交驗測試、安裝、培訓、維護，後評價。

　　在開始外包採購以前，首先業主要完成項目的整體需求規格說明書和承包項目的需求說明書。通常承包項目的需求分用戶需求和分配需求。對於分承包商來講，業主對軟件項目所提出的需求通稱 "用戶需求".對於業主來講，系統整體分配給軟件的系統需求通稱 "分配需求".如何做好子項目的需求分析和管理，請參閱《軟件需求》，詳見參考文獻5.而後業主把需求說明書交給採購組組織採購。採購部門收到需求說明書後，再補充質詢調查表、報價指南、綜合條款及條件等文件，組成採購質詢技術文件發往廠商進行質詢。採購部門在廠商質詢的基礎上，準備了廠商選擇和投標估價等技術文件後，向業主送審，提請業主批准和確認所選廠商。在廠商選擇和投標估價這兩個文件中，採購部根據擬採購的軟件對被質詢的至少三家以上的供應廠商，就技術開發成熟能力、資源（包括以有的產品、硬件、軟件、信息和已通過的培訓）、資格和信譽、過去的合做關係、價格、提供的售後服務（包括培訓和維護）、分承製方組織配置結構、與質詢要求的差別等方面，通過經濟技術和商業戰略角度出發進行全面評估，通過其餘各部門（例如系統工程組、軟件工程組、質保組、財務組）審覈後，列出供應廠商的優劣次序，擇其優者爲該項目的供應廠商。採購部通常以月爲單位向業主通報軟件採購狀況。通常以招投標方式或內部評審的方式來肯定分承製商。

　　分承製商在接到採購部的訂貨之後，就能夠進行工做說明書、用戶需求說明書、軟件需求規格說明書、軟件開發詳細計劃和成本概預算、測試計劃、質量控制方法、風險控制、擬採用的軟件工程標準和軟件生命週期等文檔的製做。而後分承製商把有關的技術資料文件經過業主的採購部送給業主進行校覈和批准，而後才能開始開發。

　　業主在接到分承製商的上述材料後，組織系統工程部、軟件工程部、質保部、財務部、採購部、法律部就上述材料中的開發項目視圖和需求範圍、使用或須要購買的軟硬件、進度計劃和成本、測試計劃與案例、使用的技術和工程標準、人員配置等進行評審，並出具評審文件和風險評估、控制建議書。並由採購部制定採購項目監督評估計劃書。合格後，由採購部、質保部及法律人員與分承製商簽署詳細的軟件採購子合同。如須要對軟件項目投保，以此來下降風險，須要和分承製商協商後，歸入合同文件。

　　分承製商在簽署合同後能夠進行設計和開發。業主應該委派採購部監督分承製商的工做。採購部應該有計劃的組織質保部、軟件工程部的項目計劃管理人員和配置管理人員，按期對分承製商的開發活動進度、質量、成本等進行評估，並造成評估建議書。送審業主方的系統工程部、項目管理人員、分承製商的此項目的負責人。分承製方的項目負責人要對評估建議書的建議進行書面回覆，並確保實施。

　　分承製方對全部須要採購的資源（軟件、硬件、人力資源等）負責進行檢驗；採購部有權在任什麼時候候對分承製商所採購的資源進行驗證，使之符合所採用的規格說明書、規範、標準和其餘技術文件所規定的要求，確保分承製商專款專用，創建開發環境。在這個階段以前，採購部門和分承製商首先要肯定由分承製商提供的驗證建議書，並做好準備工做，提交檢驗用的技術文件，包括廠商說明書、設備性能數據表、配製清單、試驗程序、檢驗技術要求。在檢驗的物質條件和技術條件均已準備妥善後，分承包商就能夠向採購部並經過採購部向業主提出書面檢驗申請。通常分承包商能夠提早三週通知採購部，由採購部提早兩週以書面形式向業主提出檢驗申請，由業主召集系統工程部、軟件工程部、質保部組成驗證組，在規定的時間、地點檢驗。經過檢驗後，分承包商進入項目開發階段；業主進入監控和評估階段。對於重大關鍵項目，業主能夠派遣項目監督員短時間或長期進駐分承包商單位。

　　因爲做爲外部單位，業主不便時刻監督項目的開發過程。雖然理論上須要把分承製商看做是本身的一個項目部門來對待，歸入本身的進度控制和質量控制體系，可是客觀上因爲分承製商與業主距離較遠，人員不熟悉，各自有本身的企業文化和管理體制，雙方之間的信息溝通不順暢，業主難以實時監督分承製商的開發進程和質量。最好的辦法就是在分承製商的軟件項目的各個里程碑處和分承製商一塊兒進行檢查和評估。軟件項目通常能夠劃分紅若干個里程碑（3-5個爲益），分承製商須要提早一週通知採購部組織相關人員來評估。軟件項目的里程碑通常指產品設計趨於穩定，中間產品定義趨於明晰，項目開發組真正瞭解項目實際的關鍵技術難度和可行的進度計劃，開發活動中止，產品進入除錯和穩定、隨時能夠發佈的階段，或當產品設計被刪減、資源增長、進度延誤的時候。在評估軟件質量、進度和功能的同時，還要評估分承製商的人員工做負荷程度、風險、費用和資源消耗狀況，並造成文檔。由採購部送審系統工程部、軟件工程部、項目管理部和分承製商的此項目負責人。

　　當產品進入交驗測試的時候，分承製商須要提早三週通知採購部，採購部於前兩週通知業主做好交驗的組織評估準備工做。這時業主組織系統工程部、軟件工程部、測試部、質保部和採購部，根據分承製商和業主在分承製商開發階段預先共同定義、評審並批准的測試計劃和驗收方案進行驗收測試，對需求規格說明書中的各項逐個詳細的測試。最後以書面的形式給出對整個軟件項目的測試評估報告。並對未經過驗收測試的軟件產品指定相應的補救措施和計劃。分承製商交付給業主方的軟件產品應當包括：源代碼、軟件開發計劃、仿真環境、軟件需求規格說明書、設計文檔、軟件測試計劃、軟件測試說明、驗收測試計劃、軟件使用手冊、軟件安裝手冊、軟件維護手冊。必要的話，還包括相關培訓計劃。

　　軟件採購的一個重要階段是交貨，也是目前常常忽略的階段。當所採購的軟件產品以及硬件運行環境在規定的時間到達採購部時候，採購部要以書面的形式通知業主交貨。業主對所交的整個軟件產品清單進行驗收，並事先通知採購部拆箱日期，要採購部和分承包商的表明按時到場。業主要在接到採購部交貨通知後一個月內，對所檢查驗收的整個軟件產品（包括相關的軟件、硬件及其附屬產品、文檔、技術資料等子合同中規定的產品）出具一份交貨證實，若是這些提交的軟件產品沒有受到損壞並與裝箱清單相一致，並在業主方環境運行良好；不然出具一份書面通知，說明在某個方面此產品損壞或與裝箱單不符，或在業主方提供的環境運行不良。此通知或證實應由採購部和分承製商表明簽署。若是在籤合同的時候，就規定分承製商負責安裝和調試，則相應的過程省略。

　　最後業主方由採購部把全部的文檔歸類封存，以備後續相似項目採購的參考查詢。同時採購部在兩個月以內以書面形式，對分承製商的技術開發成熟能力、資源（包括以有的產品、硬件、軟件、人力資源和已通過的培訓）、信譽、分承製方組織配置結構，管理能力和企業文化提交後評價報告，做爲創建客戶關係管理（CRM）的依據。對於這次採購的經驗和教訓，包括進度控制、質量控制、成本控制、客戶關係控制、流程控制、風險控制等方面，採購部以文檔的形式在組內討論並保存。

　　5、 結束語：做爲大型工程項目中的軟件子項目或者部分功能模塊的採購（外包），因爲軟件開發的固有特性（風險大，柔性強，人爲因素突出，結果不宜測量等），使軟件項目的外包採購管理變得十分複雜。如何控制分承製商的開發進度和質量等關鍵因素，須要在實踐中不斷探索，並針對具體公司和項目對採購過程有所裁剪。