一、ERP二次開發招誰惹誰了？
    芒果累滿枝頭的季節，剛好驗收一個ERP二次開發的項目，經歷了半年的項目終于要關閉，再一次感到一段新奇歷程結束時的喜悅。于是拿起電話打給一個朋友，他是東莞一家服裝制造公司IT主管，手頭也正在進行著ERP庫存模塊的優化項目，他在電話里抱怨這次優化成果剛剛上線，修改后ERP系統很不穩定，每天都在救火，不是搞亂了數據就是修改效果不符合終端用戶意見要返工，完全不能支持最初的流程優化設想，上線以來一直象夢魘。還不住的抱怨工程師們沒搞清需求，開發質量差。
    掛上電話，我陷入了沉思：不管作為甲方IT還是乙方服務商，最終目的都是為業務部門做好服務，作為ERP實施顧問，我最不愿意看到甲方對項目有如此失望，就好象是自己親自破壞了他們的ERP系統，導致他們疲憊不堪。回頭看看，行業內對ERP二次開發的聲討10年由來沒有停止過：有過一種思潮說ERP標準功能代表行業最佳實踐模型，沒必要二次開發，遵守學習就行了；又有過一種思潮說ERP實施是給客戶提供最佳解決方案，該開發時就開發；再有過一種思潮說我們現在倡導ERP實施過程按需求開發會使ERP變味，我們要停止開發…
    ERP二次開發招誰惹誰了？
    作為一個實施顧問，我看到的很多企業成功了。他們早就成功實施了oracle ERP很多年，根據企業發展需求有的已經在標準功能的基礎上，又成功二次開發了高級排程、高級備料系統，幾經耕耘并且還在繼續優化流程。我認為，我們是時候來思考ERP二次開發的‘知’與‘行’了。

二、開發目標，決策對了嗎？
    不要過早抱怨技術工程師開發的功能很別扭，挖掘不出（或堅持不了）真正的優化需要，最終作出的開發當然是四不像，這樣企業方和服務商雙方都有責任�？纯匆韵聫恼鎸嶍椖康陌咐���
    一家熱水器制造公司生產采購部門領導提出，要減輕采購員下達采購訂單的工作量把工作中心轉移到采購缺料跟蹤上。明確向其IT部門提出需求：由采購部們出資，IT出人主導，要求幫其二次開發批量下達、批量審批采購訂單的功能。IT部門在主導立項時，將其定位成明確的批量下達采購訂單功能，并且這樣的開發被定性為比較簡單。企業方任命了2名采購員作為關鍵用戶，這2名采購員對ERP系統非采購模塊不熟悉，在項目開展調研階段，他們認定，自己每天都要花很長時間在系統錄入一張張訂單，的確耗費不少工作量，開發一個批量下達的功能真的很好。顧問方根據關鍵用戶提出的意見，分析之后認為做到批量下達可行，同時開展了緊湊的開發測試過程。上線后，采購員門望著靈活的批量下達功能，一下子不敢在系統下達訂單了。
    采購員的工作效率被誰偷去了？最后經過多方走訪，發現采購員們每天被采購價格不確定、主計劃善變所干擾，每下訂單都要重復確認某些物料的價格、詢問某些物料的采購計劃是否有變化、衡量儲備庫存要保持多少才好……是這些因素在起關鍵作用桎梏采購工作效率，一個簡單的批量下達功能是無法從根本上解決這些問題的，盡管確實方便了部分人可以通過全選、下達等功能批量下達一了百了，但這顯然是不負責任的做法。
    根本問題出在：提出優化需求的人，沒有把自己的要求明確傳遞給授權參與項目的關鍵用戶；IT在立項內容中縮小了問題考慮范圍，ERP優化不同于一般的小系統優化，往往牽一發而動千軍，立項之前首先企業內部沒有進行過評估分析，同時IT也有必要站在全局的角度考慮這個開發需求是否合理；顧問在有限的資源支持下，得不到完整的客戶需求問題點，更無從分析評估主計劃為什么不剛性、供應鏈管理價格為什么不規范。
    二次開發‘知’與‘行’。以上案例中的項目甲乙方，無不互相抱怨，甲方抱怨乙方作為顧問公司沒有替用戶考慮全面；乙方委屈甲方沒有配備正確的用戶，沒有提出合理的項目范圍。既成事實，后悔已晚。讓我們來思考如何做好需求決策吧：
    a）凡是實施了大型ERP系統的公司，其組織架構必然也比較比較龐大，任何工作流程的優化必然涉及其他部門，不穿越部門壁壘的流程很少，ERP軟件的管理思想就是由一組組緊密關聯的流程組成，所以在評估需求何調研需求時，企業IT都應該要特別重視ERP二次開發項目的需求調研范圍；
    b）企業實施了ERP標準功能之后，需要不斷自我審查在日后的流程執行過程，是否有偏離，對于不健康的ERP系統運作，何談優化？因為根本無從下手去優化了，本案例中的需求，調查到最后其實可以通過業務流程規范來解決，可能最后根本不需要ERP二次開發了，這一點必須依靠企業的主觀能動性來檢討。不得不重視的是，顧問公司在接到訂單那一刻，基本沒有太多理由告訴客戶說這個項目不用做了，因為當顧問公司給出這樣的結論時，是對這個項目立項可行性的質疑，通常情況下，顧問公司不會如此做。除非項目立項之前，企業邀請了顧問公司來作評估分析，這一邀請行為可以成為專門的項目了，因為顧問人天都比較貴，況且企業IT應該承擔起ERP系統運作是否健康的監察責任；
    c）企業持續培養知用善用人才的很重要。根據多年的項目實施經驗，不少企業在最初實施ERP系統時，培養了一批優秀的關鍵用戶，但在后來的建設和維護階段，因人員流動而喪失了這些熟悉系統原理的人才，我們往往發現很多優化項目中推選的關鍵用戶，其實對ERP系統原理后臺的數據邏輯并不清楚，他們只知道操作，出現疑問并不能有效自我診斷和思考；
    d）作為顧問公司，在接觸到這樣的ERP優化項目時，要對客戶提出的果決的需求問題點，進行初步分析，以此來評定工作量以及合同細節，以免項目真正開展起來，出現如案例所述的時候，互相抱怨，進退兩難，賠了夫人又折兵，最終做了客戶不滿意的項目。同時，從行業分工來講，顧問公司具備優質資源，也應該承擔把握項目方向的主動權。

三、開發計劃，評估對了嗎？
    二次開發項目的前提范圍很大，小小的開發都需要考慮對全局的影響。企業老板不要一開始就強制項目組務必趕工在幾月幾日時上線，拍腦袋決定的計劃惡果最終是要自己買單的。為什么呢？如下是我親身經歷的一個項目：
    接到一家空調制造公司供應鏈部門提出需求，要對供應商使用的供應商平臺進行二次開發，目的在于將現有的供應商送貨單由單張打印改變成合并打印，以方便為供應商省紙。客從進駐項目第一天算起，客戶要求在10天以后立即上線。當時我所處的項目組技術顧問和功能顧問共同研究后，發現20天時間只夠開發和系統性測試，沒辦法安排用戶測試和意見反饋修改的時間。但業務部門領導不同意，強調需求非常緊迫，IT部門迫于壓力也只能強調按這個目標執行。作為顧問公司，聲明了如此工作計劃不合理，但是客戶感情上不能接受。最終，這個項目以加班的方式趕在20天后上線了。但是上線第一天就發現有一些邊緣觸發功能不夠完善；供應商沒有經過嚴格培訓和事前試用，在使用合并打單時有很多問題。導致顧問和企業關鍵用戶都在救火，最后招致IT建設部門領導的批評和最終用戶的不滿。
    抱怨來的時候，誰準備好了？經歷了這樣一次雙方不能正視項目開展方式的項目，所有人都在承受著因計劃安排失策，而帶來的迫不得已加班、偷工減序等行為。盡管著急上線后，還是要對未完善、未盡職的工作進行補救，但這在ERP二次開發項目中，是非常忌諱的。好歹這次失誤只是對供應商平臺的影響，如果涉及ERP帳務等問題導致財務出現差錯，想必所有人都不好過了。
    根本問題在于：雙方沒有建立互相信任的基礎。讓我們來思考在有限的合同條款下，雙方如何平衡好計劃安排：
    a）企業希望二次開發越快越好，就要正確面對二次開發類項目的特征：ERP系統涵蓋企業最關鍵的財務、制造、庫存，任何改動都必然放在全局范圍內考慮方案、安排技術、開展驗證，只有準備工作做足了，才能做到萬無一失；企業給出此類項目的實現目標中，必須包括‘安全’這一條，以免最后出現四處救火、痛不欲生；相信當企業理解了這一特征后，技術工程師們沒有理由降低代碼質量（比如可擴展性），實施顧問們沒理由不準備完整的測試文檔，培訓師們沒理由不提供詳細的原理培訓和對應用戶掌握程度的測試評估。一切質量都需要時間。
    b）企業應該指派具備技術能力的人，對二次開發項目行駛監督職責。項目計劃安排決定了整個項目工作安排的質量，企業一方面希望通過縮短時間來督促顧問方盡可能多的做足準備工作，另一方面又擔心因開發技術過于專業而無法監督。其實，二次開發項目與普通的項目具備大多數共通因素，只是開發和測試環節技術專業性較高。因此，企業希望實現深度監控，完全有必要指派具備技術能力的人全成跟進，已解決后顧之憂。
    c）顧問公司在任何危機條件下，都不能放棄項目質量。本案例中的上線結果有驚無險，如果涉及重要的企業資料，那顧問公司就不僅僅是承擔項目延期罪名了。面對每一家客戶對優化需求的迫不及待，顧問公司完全有必要給出全面細致的WBS分解，讓客戶了解每一項工作安排的必要性。相信企業不會認為，因時間要求緊迫，可以不開展必要的用戶測試，可以不開展必要的用戶培訓，可以不開展有安全保障的模擬上線，要知道這幾項工作雖然組織起來麻煩，但卻可以事半功倍。

四、項目控制，執行到位了嗎？
    ERP二次開發項目與常規的項目在控制方面，都是共通的，項目管理的9大知識體系無須多言。在此只談幾項致命的要素，通常是這些因素導致大家常說的，很多二次開發的功能最后用不起來了。讓我們看看在執行過程如何控制：
    a）性能優化問題：很多ERP二次開發項目，都會忽視新開發功能的性能問題。因為ERP標準功能作為成熟產品，必然經過產品公司強大資源在各方面的測試，建立了合理的性能優化機制，合格后才賣給客戶。但往往在經歷幾次二次開發之后，系統運行更慢了，甚至莫名其妙的down機。最關鍵的原因在于，開發是建立在一個龐大的技術框架內，技術顧問們最關注功能是否可以正常使用，但忽視新功能的數據增長模式，在項目完成的1－2個月內，性能尚可，經過1年半載的應用，往往出現瘋狂的數據增長而導致系統性能損失。企業IT維護部門必須正視這個問題，需要將其作為ERP二次開發要考慮的基本點。而顧問公司方，也往往會很容易提供性能優化的機制。
    b）延伸影響問題：此處指的延伸問題，是指與被二次開發功能點具有流程關聯性的其他功能點。此類問題往往是上線之后救火的重點，其特征是：其不直接與優化功能點關聯，非常隱蔽；其數據操作特征肯能受優化功能的影響，比如上游數據格式變化可能對下游某個點有影響；其與被優化功能點屬于相同業務實體，只是別人變而自己不變，此時很可能央及自己。對于此類問題，首先期望在方案階段可以考慮到，但方案階段往往不考慮這些細節，實際執行過程大多通過測試來接觸影響。因此，二次開發的測試工作是整個工作中濃墨重彩的一筆，不要總是怪技術顧問想得不周到，范這些錯都是在情理之中的，要有這種意識就可保上線后無須四處救火。切記切記。
    ERP二次開發是否會妖魔化原有功能，這完全取決于雙方對開發策略的定位，是否準確；二次開發工作是否會因各種不成熟因素而催生成畸形，這完全取決于雙方對二次開發的典型特征的認知；二次開發功能經歷了時間考驗后，會不會變成累贅或多余的東西，這完全取決于在項目執行過程的控制是否到位。

    知與行，行與知。讓我們謹記。

轉載請注明出處：拓步ERP資訊網http://m.guhuozai8.cn/

本文標題：ERP系統二次開發招誰惹誰了？

本文網址：http://m.guhuozai8.cn/html/consultation/1082065057.html