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

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

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

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

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

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/

本文標題：ERP系統(tǒng)二次開發(fā)招誰惹誰了？

本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/1082065057.html