ERP二次開發(fā)的多與少

1、ERP 二次開發(fā)的多與少企業(yè)的 ERP 系統(tǒng)必定是管理系統(tǒng)，管理系統(tǒng)并不能僅僅通過 IT 的力量就可以成功的，ERP 的二次開發(fā)也是為了服務(wù)于此管理系統(tǒng)而為企業(yè)的管理目標而服務(wù)，如果離開這個目 標是一味受制于業(yè)務(wù)部門的需求，只會使 ERP 這個管理系統(tǒng)越來越難以管理，最終造成管 理的混亂而不是提升。ERP 系統(tǒng)的開發(fā)一直是大家爭論的焦點，到底應(yīng)不應(yīng)該開發(fā)？開發(fā)的量多少才算合理？不 主張開發(fā)的認為： ERP 系統(tǒng)是結(jié)合了業(yè)界先進的業(yè)務(wù)流程經(jīng)驗，是最佳的業(yè)務(wù)實踐，建議 盡量使用系統(tǒng)的標準功能來提升企業(yè)的管理水平，另一種觀點是： ERP 系統(tǒng)先進的管理經(jīng) 驗以及業(yè)務(wù)實踐需要借鑒， 但同時， 不同企業(yè)

2、有其自身的特點， 通過開發(fā)符合企業(yè)特點的功 能，可以提升業(yè)務(wù)人員的效率。 在此，筆者不敢妄加評論那種觀點是否正確，先跟大家分享 一下，前幾天在一個討論會上，一個企業(yè) IT 主管提出的煩惱：A 公司實施 OracleERP 系統(tǒng)已經(jīng)有好幾年的時間， 而且也通過實施 ERP 系統(tǒng)獲得管理水平 的提升，同時為了提高不同部門員工使用系統(tǒng)的效率，結(jié)合企業(yè)的實際情況，在 ERP 的標 準功能基礎(chǔ)上， 開發(fā)了很多可以提升業(yè)務(wù)部門工作效率的功能點。 但經(jīng)歷了幾年的不斷開發(fā) 以及完善，現(xiàn)在企業(yè)遇到了新的難題： 1、開發(fā)出來的各種各樣的子系統(tǒng)無法整合，維護工 作困難； 2 、單點功能的開發(fā)提升了最終使用人員的效率

3、，但對整個業(yè)務(wù)流程未見提升，甚 至影響流程的穩(wěn)定性； 3、開發(fā)的功能不斷增加，系統(tǒng)復(fù)雜度以及耦合度增大，系統(tǒng)穩(wěn)定性 難以保證。 A 公司的煩惱很有代表性，也代表著我們對ERP 二次開發(fā)的觀點，難道真的盡量減少二次開發(fā)，使用系統(tǒng)的標準功能嗎？筆者覺得，ERP 實施過程中，多少的二次開發(fā)量才算合理， 不同的企業(yè)不盡相同， 但必須把握好二次開發(fā)的原則： 這個原則與當初企業(yè)為 什么要實施 ERP 系統(tǒng)是一樣的，希望通過實施 ERP 系統(tǒng)提升企業(yè)的管理水平，優(yōu)化企業(yè)的 流程，而不是僅僅提高某部門或某員工的某功能的工作效率； 提高員工的工作效率固然重要， 但任何東西都有取舍， 不是任何可以提升員工的工作效

4、率的開發(fā)都要去做， 當此工作效率的 提升反而會影響業(yè)務(wù)流程的穩(wěn)定性， 堅決不做； 如果此開發(fā)的工作效率提升， 并未對業(yè)務(wù)流 程以及管理水平有幫忙，盡量少做。明確 ERP 二次開發(fā)的目的以及原則后，需要對二次開 發(fā)進行規(guī)劃。1 、對整個企業(yè)的業(yè)務(wù)進行 IT 規(guī)劃結(jié)合選擇的 ERP 系統(tǒng)，明確哪些系統(tǒng)可以通過標準功能可以滿足的，哪些業(yè)務(wù)流程系統(tǒng)標 準功能無法符合企業(yè)的需要進行開發(fā)； 這必須是從業(yè)務(wù)流程的角度去考慮， 而不是某個功能 點去考慮；不能因為某個業(yè)務(wù)部門想法而隨意改變計劃，就像大的方面，企業(yè)的信息化分 ERP、CRM 、SCM 、PDM 等，根據(jù)企業(yè)的實際，希望先重點解決哪些業(yè)務(wù)，就ERP

5、 而已，哪些業(yè)務(wù)流程是 ERP 系統(tǒng)標準功能很好支持的，哪些業(yè)務(wù)流程必須通過開發(fā)來改善系統(tǒng)對 此流程的支持的。2、開發(fā)要有所取舍對所需要的開發(fā)進行規(guī)劃后， 確認開發(fā)的先后順序， 并明確不同子系統(tǒng)開發(fā)的側(cè)重點后， 對 具體的流程開發(fā)時， 要有所取舍。 對于某個業(yè)務(wù)部門來說， 他們的需求都是基于其工作現(xiàn)場 而提出，但正像文章前面所說，無論是二次開發(fā)還是 ERP 實施，都是為了提升企業(yè)的管理 水平， 對業(yè)務(wù)流程進行優(yōu)化，但很多最終用戶提出的需求，只是基于其功能點，而不會考慮 對整個業(yè)務(wù)流程的影響， 更談不上對管理的提升。 例如， 很多批量下達采購訂單， 批量關(guān)閉 采購訂單這樣的功能， 單從系統(tǒng)來說，

6、 的確可以提升采購員的工作效率， 但從業(yè)務(wù)流程的角 度來考慮， 系統(tǒng)關(guān)閉任務(wù)時是為了檢查作業(yè)的相關(guān)信息是否無效， 如果批量關(guān)閉， 用戶根本 就不會去逐個檢查， 這樣功能實施批量關(guān)閉了， 但這個業(yè)務(wù)的控制點卻減弱了， 反而不利于 整個業(yè)務(wù)流程的控制。 這樣看似提升最終用戶的開發(fā)而對業(yè)務(wù)流程無利的， 要慎重， 必須站 在業(yè)務(wù)流程的高度去考慮，有所取舍，要問，到底此開發(fā)，對提升企業(yè)管理是否有幫助。 3、開發(fā)的效率與可維護性 當最終確認需要通過二次開發(fā)來解決后， 進行實際性開發(fā)階段， 這時候進行開發(fā)必須把握原 則，到底是開發(fā)的效率重要還是后期可維護性重要，特別是對于哪些企業(yè)內(nèi)部 IT 人員自己 進行的

7、開發(fā)， 對于業(yè)務(wù)人員來， 每個功能的開發(fā)總是要求很緊的， 一個月的開發(fā)工作量非要 說 10 天要做出來，這樣的后果是，任何開發(fā)需求文檔不再編寫，直接進行編碼階段，直接 讓開發(fā)人員把功能開發(fā)出來讓用戶使用。 先不說開發(fā)的質(zhì)量如何， 最要命的是， 后期程序發(fā) 生變化需要修改時無法維護。 某客戶的二期項目， 一期的項目做了大量的二次開發(fā)， 但經(jīng)歷 一年時間后， IT 人員流失得差不多，到現(xiàn)在沒有一個人能清楚到底做了哪些開發(fā)，這些開 發(fā)到底實現(xiàn)了什么功能， 如何設(shè)置使用根本就無人能說得清楚， 大部分的開發(fā)涉及到各種模 塊，更不用說后期的修改了。對其修改直接影響到原來功能的使用，而有不少人員認為，當 比

8、較緊急的情況下， 可以先開發(fā)，后補文檔； 但筆者經(jīng)歷了這么多的項目與客戶， 后補的文 檔質(zhì)量根本就不能讓人相信，都只是應(yīng)付形式的。因此，對于企業(yè) ERP 這重大管理系統(tǒng)， 開發(fā)的效率當然需要追求， 但如果以犧牲流程的穩(wěn)定性以及日后的可維護性的話， 這樣的開 發(fā)效率是否值得提倡。企業(yè)的ERP系統(tǒng)必定是管理系統(tǒng)，管理系統(tǒng)并不能僅僅通過IT的力量就可以成功的，ERP的二次開發(fā)也是為了服務(wù)于此管理系統(tǒng)而為企業(yè)的管理目標而服務(wù)，如果離開這個目標是一味受制于業(yè)務(wù)部門的需求，只會使 ERP 這個管理系統(tǒng)越來越難以管理，最終造成管理的混 亂而不是提升。因此做 ERP 開發(fā)前，必須進行規(guī)劃，確認此開發(fā)是否對企業(yè)

9、管理有所提升， 是否有利于業(yè)務(wù)流程的順暢。 同時開發(fā)是服務(wù)于流程提升， 因此開發(fā)并不是越快越好， 必須 在開發(fā)的質(zhì)量與可維護性有所保障的基礎(chǔ)上追求開發(fā)效率。ERP 二次開發(fā)的知'與行'回頭看看， 行業(yè)內(nèi)對 ERP 二次開發(fā)的聲討 10 年由來沒有停止過： 有過一種思潮說 ERP 標準功能代表行業(yè)最佳實踐模型，沒必要二次開發(fā)，遵守學(xué)習(xí)就行了；又有過一種思潮說 ERP 實施是給客戶提供最佳解決方案，該開發(fā)時就開發(fā)；再有過一種思潮說我們現(xiàn)在倡導(dǎo)ERP實施過程按需求開發(fā)會使 ERP變味，我們要停止開發(fā)ERP二次開發(fā)招誰惹誰了？一、ERP 二次開發(fā)招誰惹誰了？芒果累滿枝頭的季節(jié)，剛好驗收

10、一個ERP二次開發(fā)的項目，經(jīng)歷了半年的項目終于要關(guān)閉，再一次感到一段新奇歷程結(jié)束時的喜悅。 于是拿起電話打給一個朋友， 他是東莞一家服裝制 造公司IT主管，手頭也正在進行著 ERP庫存模塊的優(yōu)化項目，他在電話里抱怨這次優(yōu)化成 果剛剛上線，修改后 ERP 系統(tǒng)很不穩(wěn)定，每天都在救火，不是搞亂了數(shù)據(jù)就是修改效果不 符合終端用戶意見要返工， 完全不能支持最初的流程優(yōu)化設(shè)想， 上線以來一直象夢魘。 還不 住的抱怨工程師們沒搞清需求，開發(fā)質(zhì)量差。掛上電話，我陷入了沉思：不管作為甲方 IT 還是乙方服務(wù)商，最終目的都是為業(yè)務(wù)部門做 好服務(wù)，作為 ERP 實施顧問，我最不愿意看到甲方對項目有如此失望，就好象

11、是自己親自 破壞了他們的 ERP 系統(tǒng)，導(dǎo)致他們疲憊不堪。 回頭看看， 行業(yè)內(nèi)對 ERP 二次開發(fā)的聲討 10 年由來沒有停止過：有過一種思潮說 ERP 標準功能代表行業(yè)最佳實踐模型，沒必要二次開 發(fā)，遵守學(xué)習(xí)就行了；又有過一種思潮說 ERP 實施是給客戶提供最佳解決方案，該開發(fā)時 就開發(fā)；再有過一種思潮說我們現(xiàn)在倡導(dǎo) ERP 實施過程按需求開發(fā)會使 ERP 變味，我們要 停止開發(fā)ERP 二次開發(fā)招誰惹誰了？ 作為一個實施顧問，我看到的很多企業(yè)成功了。他們早就成功實施了 oracleERP 很多年， 根據(jù)企業(yè)發(fā)展需求有的已經(jīng)在標準功能的基礎(chǔ)上， 又成功二次開發(fā)了高級排程、 高級備料系 統(tǒng)，幾經(jīng)

12、耕耘并且還在繼續(xù)優(yōu)化流程。我認為，我們是時候來思考ERP 二次開發(fā)的知'與行'了。二、開發(fā)目標，決策對了嗎？不要過早抱怨技術(shù)工程師開發(fā)的功能很別扭， 挖掘不出（或堅持不了） 真正的優(yōu)化需要，最 終作出的開發(fā)當然是四不像， 這樣企業(yè)方和服務(wù)商雙方都有責(zé)任。 看看以下從真實項目的案 例：一家熱水器制造公司生產(chǎn)采購部門領(lǐng)導(dǎo)提出， 要減輕采購員下達采購訂單的工作量把工作中 心轉(zhuǎn)移到采購缺料跟蹤上。明確向其 IT 部門提出需求：由采購部門出資， IT 出人主導(dǎo)，要 求幫其二次開發(fā)批量下達、批量審批采購訂單的功能。 IT 部門在主導(dǎo)立項時，將其定位成 明確的批量下達采購訂單功能，并且這樣的

13、開發(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)采購員們每天被采購價格不確定、 主計劃善變所干擾， 每下訂單都要重復(fù)確認某些物料的價格、 詢問某些物料的采購計劃是否 有變化、衡量

14、儲備庫存要保持多少才好是這些因素在起關(guān)鍵作用桎梏采購工作效率，一盡管確實方便了部分人可以通過全個簡單的批量下達功能是無法從根本上解決這些問題的， 選、下達等功能批量下達一了百了，但這顯然是不負責(zé)任的做法。根本問題出在： 提出優(yōu)化需求的人， 沒有把自己的要求明確傳遞給授權(quán)參與項目的關(guān)鍵用戶； IT 在立項內(nèi)容中縮小了問題考慮范圍， ERP 優(yōu)化不同于一般的小系統(tǒng)優(yōu)化，往往牽一發(fā)而 動千軍，立項之前首先企業(yè)內(nèi)部沒有進行過評估分析，同時 IT 也有必要站在全局的角度考 慮這個開發(fā)需求是否合理； 顧問在有限的資源支持下， 得不到完整的客戶需求問題點， 更無 從分析評估主計劃為什么不剛性、供應(yīng)鏈管理價格

15、為什么不規(guī)范。二次開發(fā)知'與行' 。以上案例中的項目甲乙方，無不互相抱怨，甲方抱怨乙方作為顧 問公司沒有替用戶考慮全面； 乙方委屈甲方?jīng)]有配備正確的用戶， 沒有提出合理的項目范圍。 既成事實，后悔已晚。讓我們來思考如何做好需求決策吧：a ）凡是實施了大型 ERP系統(tǒng)的公司，其組織架構(gòu)必然也比較比較龐大，任何工作流程的優(yōu) 化必然涉及其他部門，不穿越部門壁壘的流程很少， ERP 軟件的管理思想就是由一組組緊 密關(guān)聯(lián)的流程組成，所以在評估需求何調(diào)研需求時，企業(yè)IT都應(yīng)該要特別重視 ERP二次開發(fā)項目的需求調(diào)研范圍；b ）企業(yè)實施了 ERP標準功能之后，需要不斷自我審查在日后的流程執(zhí)行

16、過程，是否有偏離，對于不健康的 ERP 系統(tǒng)運作，何談優(yōu)化？因為根本無從下手去優(yōu)化了，本案例中的需求， 調(diào)查到最后其實可以通過業(yè)務(wù)流程規(guī)范來解決，可能最后根本不需要ERP 二次開發(fā)了，這一點必須依靠企業(yè)的主觀能動性來檢討。 不得不重視的是， 顧問公司在接到訂單那一刻， 基 本沒有太多理由告訴客戶說這個項目不用做了， 因為當顧問公司給出這樣的結(jié)論時， 是對這 個項目立項可行性的質(zhì)疑，通常情況下， 顧問公司不會如此做。除非項目立項之前，企業(yè)邀 請了顧問公司來作評估分析， 這一邀請行為可以成為專門的項目了， 因為顧問人天都比較貴， 況且企業(yè)IT應(yīng)該承擔起ERP系統(tǒng)運作是否健康的監(jiān)察責(zé)任；c）企業(yè)持續(xù)

17、培養(yǎng)知用善用人才的很重要。根據(jù)多年的項目實施經(jīng)驗，不少企業(yè)在最初實施ERP 系統(tǒng)時，培養(yǎng)了一批優(yōu)秀的關(guān)鍵用戶，但在后來的建設(shè)和維護階段，因人員流動而喪 失了這些熟悉系統(tǒng)原理的人才， 我們往往發(fā)現(xiàn)很多優(yōu)化項目中推選的關(guān)鍵用戶， 其實對 ERP 系統(tǒng)原理后臺的數(shù)據(jù)邏輯并不清楚， 他們只知道操作， 出現(xiàn)疑問并不能有效自我診斷和思考；d）作為顧問公司，在接觸到這樣的 ERP優(yōu)化項目時，要對客戶提出的果決的需求問題 點，進行初步分析， 以此來評定工作量以及合同細節(jié)，以免項目真正開展起來，出現(xiàn)如案例 所述的時候，互相抱怨，進退兩難，賠了夫人又折兵，最終做了客戶不滿意的項目。同時， 從行業(yè)分工來講，顧問公司

18、具備優(yōu)質(zhì)資源，也應(yīng)該承擔把握項目方向的主動權(quán)。三、開發(fā)計劃，評估對了嗎？ 二次開發(fā)項目的前提范圍很大，小小的開發(fā)都需要考慮對全局的影響。企業(yè)老板不要 一開始就強制項目組務(wù)必趕工在幾月幾日時上線， 拍腦袋決定的計劃惡果最終是要自己買單 的。為什么呢？如下是我親身經(jīng)歷的一個項目：接到一家空調(diào)制造公司供應(yīng)鏈部門提出需求，要對供應(yīng)商使用的供應(yīng)商平臺進行二次 開發(fā)，目的在于將現(xiàn)有的供應(yīng)商送貨單由單張打印改變成合并打印，以方便為供應(yīng)商省紙。 客從進駐項目第一天算起，客戶要求在 10 天以后立即上線。當時我所處的項目組技術(shù)顧問 和功能顧問共同研究后，發(fā)現(xiàn) 20 天時間只夠開發(fā)和系統(tǒng)性測試，沒辦法安排用戶測試

19、和意 見反饋修改的時間。但業(yè)務(wù)部門領(lǐng)導(dǎo)不同意，強調(diào)需求非常緊迫，IT 部門迫于壓力也只能強調(diào)按這個目標執(zhí)行。 作為顧問公司， 聲明了如此工作計劃不合理， 但是客戶感情上不能接 受。最終，這個項目以加班的方式趕在 20 天后上線了。但是上線第一天就發(fā)現(xiàn)有一些邊緣 觸發(fā)功能不夠完善；供應(yīng)商沒有經(jīng)過嚴格培訓(xùn)和事前試用，在使用合并打單時有很多問題。 導(dǎo)致顧問和企業(yè)關(guān)鍵用戶都在救火，最后招致IT 建設(shè)部門領(lǐng)導(dǎo)的批評和最終用戶的不滿。抱怨來的時候，誰準備好了？經(jīng)歷了這樣一次雙方不能正視項目開展方式的項目，所 有人都在承受著因計劃安排失策， 而帶來的迫不得已加班、 偷工減序等行為。 盡管著急上線 后，還是要

20、對未完善、未盡職的工作進行補救，但這在ERP 二次開發(fā)項目中，是非常忌諱的。好歹這次失誤只是對供應(yīng)商平臺的影響，如果涉及ERP帳務(wù)等問題導(dǎo)致財務(wù)出現(xiàn)差錯，想必所有人都不好過了。根本問題在于：雙方?jīng)]有建立互相信任的基礎(chǔ)。讓我們來思考在有限的合同條款下， 雙方如何平衡好計劃安排：a）企業(yè)希望二次開發(fā)越快越好，就要正確面對二次開發(fā)類項目的特征：ERP系統(tǒng)涵蓋 企業(yè)最關(guān)鍵的財務(wù)、制造、庫存，任何改動都必然放在全局范圍內(nèi)考慮方案、安排技術(shù)、開 展驗證，只有準備工作做足了， 才能做到萬無一失；企業(yè)給出此類項目的實現(xiàn)目標中， 必須 包括安全'這一條，以免最后出現(xiàn)四處救火、痛不欲生；相信當企業(yè)理解了這

21、一特征后， 技術(shù)工程師們沒有理由降低代碼質(zhì)量（比如可擴展性） ，實施顧問們沒理由不準備完整的測 試文檔， 培訓(xùn)師們沒理由不提供詳細的原理培訓(xùn)和對應(yīng)用戶掌握程度的測試評估。 一切質(zhì)量 都需要時間。b）企業(yè)應(yīng)該指派具備技術(shù)能力的人，對二次開發(fā)項目行駛監(jiān)督職責(zé)。項目計劃安排決 定了整個項目工作安排的質(zhì)量， 企業(yè)一方面希望通過縮短時間來督促顧問方盡可能多的做足 準備工作， 另一方面又擔心因開發(fā)技術(shù)過于專業(yè)而無法監(jiān)督。 其實， 二次開發(fā)項目與普通的 項目具備大多數(shù)共通因素， 只是開發(fā)和測試環(huán)節(jié)技術(shù)專業(yè)性較高。 因此， 企業(yè)希望實現(xiàn)深度 監(jiān)控，完全有必要指派具備技術(shù)能力的人全成跟進，已解決后顧之憂。c ）

22、顧問公司在任何危機條件下，都不能放棄項目質(zhì)量。本案例中的上線結(jié)果有驚無險， 如果涉及重要的企業(yè)資料， 那顧問公司就不僅僅是承擔項目延期罪名了。 面對每一家客戶對 優(yōu)化需求的迫不及待，顧問公司完全有必要給出全面細致的 WBS 分解，讓客戶了解每一項 工作安排的必要性。 相信企業(yè)不會認為， 因時間要求緊迫，可以不開展必要的用戶測試，可 以不開展必要的用戶培訓(xùn)， 可以不開展有安全保障的模擬上線， 要知道這幾項工作雖然組織 起來麻煩，但卻可以事半功倍。四、項目控制，執(zhí)行到位了嗎？ERP二次開發(fā)項目與常規(guī)的項目在控制方面，都是共通的，項目管理的9大知識體系無須多言。 在此只談幾項致命的要素， 通常是這些

23、因素導(dǎo)致大家常說的， 很多二次開發(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ù)增長模式，在項目完成的12個月內(nèi)，性能尚可，經(jīng)過 1 年半載的應(yīng)用，往往出現(xiàn)瘋狂的數(shù)據(jù)增長而導(dǎo)致系統(tǒng)性能損失。企業(yè) IT 維

24、護部門必須正視這個問題，需要將其作為 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è)務(wù)實體， 只是別人變而自己不變， 此時很可能央及 自己。對于此類問題，首先期望在方案階段可以考慮到，但方案階段往往不考慮這些細節(jié)， 實際執(zhí)行過程大多通過測試來接觸影響。 因此，二次開發(fā)的測試工作是整

25、個工作中濃墨重彩 的一筆， 不要總是怪技術(shù)顧問想得不周到， 范這些錯都是在情理之中的， 要有這種意識就可 保上線后無須四處救火。切記切記。ERP 二次開發(fā)是否會妖魔化原有功能，這完全取決于雙方對開發(fā)策略的定位，是否準 確；二次開發(fā)工作是否會因各種不成熟因素而催生成畸形，這完全取決于雙方對二次開發(fā)的典型特征的認知； 二次開發(fā)功能經(jīng)歷了時間考驗后， 會不會變成累贅或多余的東西， 這完全 取決于在項目執(zhí)行過程的控制是否到位。知與行，行與知。讓我們謹記?？蛻艋_發(fā)風(fēng)險分析及對策在項目實施過程中， 客戶化開發(fā)工作主要關(guān)注的應(yīng)該是客戶方和開發(fā)方如何配合，既保證為客戶方提供正確指導(dǎo)， 又能使開發(fā)方充分考慮項

26、目潛在因素及對風(fēng)險的控制。 使客戶方 和開發(fā)方能達到利益最大化為目的，實現(xiàn)共贏，走向成功?，F(xiàn)代企業(yè)面對激烈的競爭， 信息化被越來越多企業(yè)所采納， 但實施信息化的過程中為了滿足 企業(yè)特定的需求， 需要對企業(yè)進行客戶化開發(fā)， 但進行客戶化開發(fā)的過程中也伴隨著一定的 風(fēng)險。 那么如何合理的規(guī)避企業(yè)風(fēng)險， 使企業(yè)能順利的開展信息化工作， 并最終通過信息化 來全面提高企業(yè)的效益， 提升企業(yè)的競爭力？本文想從客戶化開發(fā)角度闡述一下企業(yè)信息化 實施過程中如何規(guī)避風(fēng)險的問題?？蛻艋_發(fā)的成因和風(fēng)險而每客戶化開發(fā)的成因主要有兩個， 其一，軟件產(chǎn)品是商品化軟件，屬于行業(yè)通用型軟件， 個企業(yè)還是有其自身的特點，既要

27、吸納管理軟件中的先進管理思想，也要保持企業(yè)的特色,因此需要對于原來的軟件進行客戶化的修改。其二，隨著項目的實施，客戶對信息系統(tǒng)有了更深的了解，應(yīng)用不斷深入，對信息系統(tǒng)產(chǎn)品就會提出更多的要求，這些要求就形成了客戶化開發(fā)的另一來源。客戶化開發(fā)在滿足客戶實際應(yīng)用的特殊性需求的同時，也會給實施工作帶來了巨大的風(fēng)險。 縱觀失敗的信息化實施項目，因客戶化開發(fā)導(dǎo)致的延期比比皆是。沒有節(jié)制的客戶化開發(fā)工作是導(dǎo)致項目失敗的重要原因之一?？蛻艋_發(fā)風(fēng)險主要體現(xiàn)在如下幾占：八、一、實施過程中，對于需求，客戶方與開發(fā)方只有口頭的交互，沒有正式的確認文檔。這樣 做可能產(chǎn)生歧義，客戶和實施顧問對需求的理解不一致，做出來的

28、東西不符合客戶方需要， 使開發(fā)成果與需求產(chǎn)生偏差，客戶方無法使用，開發(fā)方白白浪費時間。二、 隨著開發(fā)的進行，客戶方需求不斷增加或變更，開發(fā)方盡力滿足，導(dǎo)致形成一個需求黑 洞，整個項目組陷入到需求黑洞中， 客戶要求的合理性無法衡量， 開發(fā)方工作不被認可，致 使項目偏離初衷，無法為企業(yè)提供指導(dǎo)與幫助。三、開發(fā)方?jīng)]有對需求開發(fā)過程進行嚴格的監(jiān)控與跟蹤，對項目進度影響較小的變更不做監(jiān)控，產(chǎn)生積累效應(yīng)，可能對整個項目的產(chǎn)生影響。四、開發(fā)方評審工作不到位，使一些看上去無關(guān)緊要的修改與其它系統(tǒng)產(chǎn)生關(guān)聯(lián)錯誤。五、現(xiàn)場的更改沒有記錄， 包括變更的原因和變更的內(nèi)容，使客戶的升級工作變得非常困難。所有的這些風(fēng)險都對項目的進度、質(zhì)量和成本產(chǎn)生不同程度的影響，給實施雙方帶來嚴重后果，浪費了時間和精力，資金遭受損失，只以失敗告終?？蛇@些風(fēng)險又不能完全避免，我們需要一些手段來控制?？蛻艋_發(fā)問題對策站在項目實施的角度上來看，項目實施顧問一定要按原則辦事。給客戶開發(fā)一個功能， 修改一段程序看似比說服客戶放棄修改的念頭容易得多，因此實施顧問寧可埋頭做程序而不愿意說服客戶，其中隱含的風(fēng)險卻往往被忽略，這種做法是對客戶和公司的不負責(zé)任。項目實施顧問應(yīng)在充分了解客戶需求的基礎(chǔ)上