3種團隊分組适應項目_搞砸SAP項目的3種方法

在一次上線之後，我和幾位項目裡的戰友坐在街角的宵夜攤前，啜着啤酒啃着串，分享着各自的SAP故事。

不知什麼時候開始，話題轉向了各自經曆的，失敗的或瀕臨失敗的項目經驗。

這也進而讓我想把那天聊到的一些内容寫下來。

天下沒有失敗的SAP項目

在SAP圈子裡我聽說過一句話：“SAP項目上線永遠是成功的”。

因為“成功的”是一個形容詞，這就讓每個人都有各自充分發揮的空間。你可以認為資料全部導入就算成功，也可以認為第一個訂單建立就算成功，還可以認為月結完成就算成功。

但一個項目是否成功，相信每個參與了項目的人，心裡都有一杆秤。

就算因為公司的壓力或是團隊的榮譽，其實很難在口頭上承認一個項目最終其實是挺失敗的，但或多或少，内心都會有自己的判斷。

SAP項目裡的失敗，要麼牽扯到人，要麼牽扯到事，讓我們先從人說起。

不合格的項目團隊

顧問團隊，一定是SAP項目裡最重要的資源，以及確定項目能成功的最重要因素之一。

如果能擁有一個技術過硬，經驗老道，相處融洽，彼此配合的顧問團隊，那這個項目還沒開始，就成功了一半。

技術過硬，經驗老道，代表着自己子產品裡的大事小情都能從容應對，就算偶爾出現個難點，查查notes也能解決。當然，并不用項目組裡的每個人都是高手，但至少每個子產品能有一個獨當一面的顧問，再配合一些實習顧問，項目就能成功運轉下去。

現在市場上有些項目，或許是受限于成本，最資深的顧問都不超過三年經驗。三年，可能才做了兩個項目，接觸過一兩個行業，就算學習能力強，願意加班追趕，也是很難獨挑大梁，讓客戶滿意的。

客戶總是喜歡那種有着成熟、自信、一切盡在掌握的顧問，而這些氣質，都得靠時間磨練。

技術不夠好，就不夠自信，跟客戶講話就沒有底氣，客戶就會對顧問不買賬。

另一種情況，是技術到位了，但顧問之間彼此沒有配合。

足球場上，有再厲害的前鋒，也得中場喂球才能有射門的機會。

顧問之間的配合，有時候會比你想象得更重要。

記得有一個國企項目，客戶老總别出心裁地在大禮堂裡召集全公司的人一起看SAP內建測試的報告會。每個子產品的使用者都要上去操作，而顧問在下面支援。偏偏其中MM顧問就是個沒有太多團隊精神的人，覺得其他子產品的測試跟自己關系不大，給PP和SD子產品用的測試物料都建立得亂七八糟，一些問題使用者又沒有能力當場就解決，導緻現場意外不斷，狀況頻出。

結果就是客戶老總大怒，項目整風反思一個月。而這多花的一個月的時間，就源自那一點點的配合不暢。

一切問題，歸根結底都是人的問題，人有問題，項目還怎麼可能成功？

太激進的項目計劃

不知道是不是咱們骨子裡都有點好大喜功的基因一脈相傳下來，就跟很多其他事情一樣，我們做SAP項目也喜歡“大幹快上”。原本十個月正好完成的項目，因為各種原因可能壓縮到六個月就要上線。

這就像建房子，為了趕工期，一樓的水泥還沒幹透就着急忙慌地趕着蓋二樓，這品質能好麼？将來房子倒了，又該怪誰？是決策者太着急，還是項目管理者沒做好計劃，還是執行者沒做好實施呢？

我參與過不止一個項目，都是有着最緊繃的項目計劃。每一項任務都按照沒有任何空間和餘地的方法在安排。

系統配置給三天，內建測試給一周，使用者教育訓練給兩天。這樣的安排方式，讓無論是顧問還是使用者都隻能蒙頭趕路，顧不上身邊的細節。

欠的債早晚是要還的，配置時疏忽的點，測試時遺漏的業務場景，教育訓練時沒有提到的關鍵，都會或早或晚地爆發出來。

最終，SAP系統的使用者們會覺得這是個方案不完善、細節有缺陷的系統，進而産生抵觸情緒，根本不信任系統。

那你說這樣的項目，就算匆匆忙忙上線了，能算成功麼？

太複雜的項目範圍

另一種讓項目成為炸藥桶的方式，就是擁有不斷擴張，太過複雜的項目範圍。

老子在《道德經》裡告誡世人要懂得“知止”，說的就是過猶不及的道理。

而SAP項目裡，無論是顧問，還是項目經理，非常重要的一點就是懂得Say No。

或許我們都碰到過，在項目範圍已經鎖定，藍圖已經完成，配置已經做好的情況下，客戶又有了新的需求，新的想法。這不是不允許的，隻是必須要非常謹慎，因為無數項目都是因為變更管理沒有做好，而進入後期無法按質按量傳遞的尴尬境地。

有的項目經理就在這一點上做得很好，我記得曾經跟一位墨西哥來的項目經理合作。他在藍圖确定之後的大會上，就對台下大大小小使用者說：“從現在開始，你們可以來向我提要求。但是，請記住，我的預設答案就是No，除非你有非常強的理由（例如法律規定）能夠說服我。不然，你會得到的回答就是No”。

還有些客戶是第一次搭建企業資訊系統，想着一次就要做到盡善盡美，一口吃成個胖子。項目範圍裡塞滿了各種必須的，不必須的功能。看起來咨詢公司能做個大項目，可吃得多了，也容易噎着。

我有幸親眼見證過一個有上百個顧問、大幾百個世界各地使用者參與，花費了上千萬美元的巨型SAP項目。其中需求的複雜度超乎想象，開發的功能不計其數。最終這樣一個巨無霸在幾年後，因為系統太過龐雜，沒有人懂得裡面所有的細節，後續維護成本太高被迫停止使用。業務功能被重新拆散到多個不同的IT系統中去。

少即是多，這恐怕是很多人耗費無數金錢和努力換來的至理名言了。

小結

項目想做好，要方方面面的努力。而想搞砸，隻要有一個敗筆就夠了。

咱們一起，有則改之，無則加勉吧。

延伸閱讀

你準備好成為SAP自由顧問了嗎？

Central Procurement 采購的未來（1）

做SAP顧問，需要什麼樣的英語水準