探祕技術專案管理（一）(轉)

探祕技術專案管理（一）
SAP解析ERP悲劇

　　“再造”、“e化”、“變革”……呼籲聲，附和聲，我們已經聽得太多了，但總是說得多，做得少，做好的更少。然而狂熱的吶喊之後，我們總要切實地實施。於是，真刀真槍的“技術專案管理”浮出水面。這裡容不得任何花架子。原聯想整合與北京三露廠“聯合制作”的ERP噩夢足以讓人在唏噓中冷靜下來。值此時刻，擁有30年實踐經驗的SAP公司，和20 年研究心得的資訊系統教授貝內特，一語驚人，指點迷津。

中國ERP第一案，一塌糊塗！

　　“現在很多企業或多或少都有一些系統和IT專案，但是，這其中有30%～45%在完成前就失敗了，而且失敗的專案還都是管理層所看重的關鍵專案。再有就是一半以上的專案都超出預算和進度200%甚至更多。……在一項調查中，超過60%的企業經理認為，他們已經錯誤地應用了購買的軟體包，並且只有極少有收益甚至是沒有收益。當失敗發生時，直接的損失不用說了，在業務上的總的間接損失要多得多。”

　　美國加州大學資訊系統教授貝內特得出的以上結論，真是觸目驚心。然而在事先，我們又經常無法預見，一個技術專案的實施過程中，到底會存在哪些問題……直到媒體披露了“中國ERP第一案”。

　　案件時間表顯示，聯想承諾專案進度為一年，但到2000年7月的最後失敗，可以看出實際進度為2年零4個月，而此案件的訴訟時間竟長達1年零2個月。原因是此案大量地涉及了技術問題，而且合同簽訂不嚴密不規範，在爭論中雙方無法說清ERP驗收標準。計劃書上沒有雙方當事人的簽字，每一次業務修改雙方負責人也沒有簽字。這些問題其實都暴露了技術專案管理人的法律認知缺失及實施經驗的嚴重匱乏。

聯想整合的三大敗筆

　　那麼，企業資訊化的專案管理該如何實施？擁有“世界第一ERP”美譽的德國SAP公司依靠其30多年的成功實踐，無疑有助於我們洞悉其中的奧妙。為此，記者專訪了SAP大中華區執行副總裁黃驍儉。

　　面對記者的困惑，黃驍儉一臉輕鬆：“這樣的事在我們業內已是見怪不怪了，比這更大的失敗都有，只是你們不知道而已。從整個事件來看，從使用者的購買、選型，以及合同的簽定，到後面的實施控制，大家都是沒有經驗的。比較專業的做法是，使用者在購買前就應該知道自己到底需要什麼樣的東西。為此，使用者必須要請專業的公司或專家幫助你分析需求。從我看到的報導來看，至少三露廠沒有很認真地做過這樣的事情。”

　　那麼，聯想整合是不是應該有義務幫助使用者分析需求？“理論上講是這樣的，但是聯想只是代理商。如果請廠商做分析的話，他往往從自己的產品角度去分析你，把你引導到他現有的模式中去，這對客戶是不公正的。而請第三方專門機構協助分析，就可以減少一些風險。這個專案實際一開始就給自己埋下了隱患。進而，實施方聯想整合又犯了一系列錯誤。

　　“首先，他們剛剛開始做這類專案時，不是很專業，也不是很懂。為了賣掉產品，他們做了過度的承諾。比如他的後期服務，花6萬元就去承諾長期的軟體升級、24小時服務，沒有哪個公司是能做到這一點的。第二，我感覺聯想整合是吃了MOVEX的虧，他們並沒有很好地對MOVEX產品進行非常深入的瞭解。第三，他們選擇MOVEX做合作伙伴就是一個錯誤。在當時來講，MOVEX在中國沒有任何一個支援機構，而且沒有本地化的強有力研發的支援團隊。這種情況下，用他們的產品要想很有效地接近中國企業的需求，肯定會有問題。”

　　按理說，聯想不應該出現這麼低階的錯誤吧。黃驍儉指出：聯想真正轉向做服務，也就是這兩年的事情。當時聯想處於高速發展階段，它可能對管理軟體的概念並不是很清晰，因為聯想自身是做硬體系統整合的，人員可能也更多是做純粹技術系統整合的。因此，他們沒有想到做管理軟體不是技術上的工程，而是一項複雜的管理工程，更多的應該是管理專家幫助企業去做這種實施的工作，而不是一些計算機人員。

技術，專案失敗的替罪羊

　　黃驍儉進一步認為：“從MOVEX的角度看，我覺得‘漢化不徹底’只是表面問題。問題是，像三露廠這樣非常有特點的中國企業要清楚：你上這個系統的目的是什麼？這絕不是簡單地把一些手工的工作搬到電腦裡去。如果目的真這麼簡單，就不必買國外的軟體。我估計三露廠主要還是想利用國外軟體引起管理模式上的重大變革。因此，漢化不漢化，只是一個技術問題。更深層次的原因是這個軟體代表的管理思想是三露廠沒辦法接受的，比如它的財務管理系統和中國的財務要求有很大的差距。也就是說，本質是軟體供應方本身沒有做到本地化。而專案出現危機後，它只是做技術彌補的話，就很難改變這個局面。

　　“軟體本身從技術角度來講，永遠都是可解決的，包括MOVX這種產品從技術角度也是可以解決的。那為什麼技術人員沒解決問題？是因為這個技術解決方案和三露廠的管理要求是截然不同的東西。軟體本身不可能失敗，你想讓我改到什麼程度，我就能改到什麼程度。但是這個軟體本身所遵循的一種規律被破壞的話，它就回天無力了。我感到媒體講了很多三露廠ERP失敗的原因，都沒有抓到實質。”

SAP的專案實施，步步為營

　　在這個失敗案例中，200萬元的損失與補償，其實都無法平息各方的內心哀嘆與失望，更無法消除人們對中國乃至全球技術專案管理水平的質疑。如此，我們自然會饒有興趣地回過頭來深入地研究一下SAP，這個資訊化“老手”在技術專案管理上的絕招。

　　SAP專門有三四張光碟以介紹它的ASAP的快速實施法。

　　第一階段：專案準備。SAP首先和使用者在售前共同討論、共同制定專案實施目標，這個目標要求能量化、比較明確。在專案前期會花很多時間，和客戶共同做使用者需求分析，分析客戶現有的企業經營狀況和現有的管理模式，分析如果要改進的話，將改進到什麼樣的程度，這是SAP必須要做的一件事。在這個階段，往往會有第三方機構加入到這個專案的定位中來。

　　同時，要確定專案組織結構及成員，制定實施計劃和標準，準備並安排各方面資源。SAP軟體有很多模組，所以在目標達成共識後，在產品採購過程時，SAP會和客戶共同制定整個的實施方案，他們也要考慮客戶逐漸投入的過程，不會讓你一下子花很多錢來買他的產品。
第二階段：業務流程藍本設計。期間要進行專案小組初級及中級培訓，專案目標明細化，確定基本系統的範圍，確定專案的詳細實施計劃，業務需求的確認，企業組織結構及業務流程的確定。

　　第三階段：業務藍圖實現。這個階段的目的是逐步實現業務藍圖，進行完整的系統測試，獲得使用者對系統的確認。主要任務要對專案小組進行高階培訓，開發資料轉換程式，開發應用介面程式，開發外掛或擴充套件程式，進行報表定義、格式定義、許可權定義及管理，歸檔定義及管理系統整合測試，製作使用者手冊及使用者培訓資料。

　　第四階段：投入執行準備。此階段的目的是要完成系統上線的準備，以保證系統正確運轉，同時要解決剩餘問題。主要任務是進行使用者培訓、系統管理、正式執行技術環境的安裝及測試，制定明細執行計劃，制定系統切換計劃，制定系統執行、支援計劃。

　　第五階段：系統投入執行及支援。正確移交系統，保證系統正常運轉。主要任務是提供使用者支援，確認正式業務流程的正確性，優化系統的使用，後續培訓，制定後續長期計劃，系統升級，系統日常維護，專案回顧。

道不同不相為謀

　　當然，除了嚴謹而科學的專案管理流程外，在一個系統專案上馬之前，客戶是否對這個專案的深層意義有全面深刻認識，是專案成功的關鍵前提。作為一個優秀的企業，面對不同的客戶時，一定要懂得去拒絕那些並不是真正意義上的客戶。從拒絕客戶中學習預先的問題管理，將後期可能發生的糾紛、風險降到最低，這是一種大公司必須具備的能力和品質。

　　因此，我們也不難知道，其實SAP也有距絕客戶的時候。SAP軟體代表的是一種管理思想，如果你不能接受這個思想，就不可能達成共識。黃驍儉語氣堅決地說：“SAP軟體絕不會模擬一個現有的管理模式和業務流程。”很多專案在投標的過程中，如果他們發現這個客戶制定的目標和SAP有較大差異的話，他們就會退出競標。

　　黃驍儉說：“首先我們提倡一體化的管理，不會簡單地為一兩個部門去實現資訊化。ERP的核心思想就是要進行資訊整合、共享、要以流程為單位來運作。有些客戶，甚至很多大企業都說，你只要給他解決一個倉庫管理或者你只要給他解決銷售管理，這不是我們要做的，我們賣的是企業產品，而不是部門產品。這說明企業在確定一個專案時，它並不明白它要達到一個什麼樣的目標，它對ERP的含義並沒有深刻的瞭解。如果只把ERP當成一個軟體產品來做的話，而不是一個管理改革的過程，註定要失敗。

　　“我們一直認為：客戶對ERP的投入不是一個短期投入，它是一個長期的投入。你要做資訊化就等於是上了‘賊船’，你可能在此後每年都會有不小的投入。在國外有個定律，企業至少要拿出總銷售收入的6%做資訊化的長期投入，中國企業很少有這樣的概念。不這樣，就很難保證這個專案會長期發生效益。為什麼後期我們要維護？因為管理本身不是一成不變的。有些公司總想投入很少產出很多，這種情況我們也會退出。”

　　三露廠的嘆息，聯想的憂鬱，和MOVX的無奈，都正在成為過去。但事情遠沒有結束。

　　由於市場交換的複雜性日益增大、IT業的迅猛發展，使得企業管理和業務從來沒有像現在這樣依賴於技術，雖然資訊化歷程中潛伏著巨大風險，但我們沒有理由因此而拒絕資訊化的潮流，因此對資訊化敬而遠之。我們現在所能做的是：儘量多地研究失敗，吸取教訓，並能從失敗中找出一些實質原因。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21084/，如需轉載，請註明出處，否則將追究法律責任。