二次開發的風險當用戶明確提出要二次開發的時候,則很容易出現項目延期、開發的程序不穩定容易報錯等問題;或者用了一段時間后想再做修改,才發現原來當初這樣做是不對的,但可能涉及當初拍板決定的各方領導利益問題,所以也沒人敢改了,因此導致二次開發的程序成了雞肋,扔也不是,不扔也不是。
①修改報表格式或用戶查詢系統等不涉及程序代碼改動的需求相對簡單,因為軟件一般都具有報表生成功能,任何業務人員不需要有很多計算機知識就可以自行設置,這種情況在實施時經過實施顧問組與用戶充分溝通一般比較容易解決。
②當用戶需求具有個性化,并涉及改動程序代碼時,工作就很復雜了,往往需要
ERP系統提供支持二次開發的工具,還可能需要有廠商軟件的源程序支持,這些大都要支付額外費用。
當用戶提出需要代碼級二次開發時,實施顧問必須清楚與用戶溝通,否則更易陷入泥潭,因為代碼級二次開發可能會使
ERP系統變得越來越復雜,變成一個“四不象”的浮腫龐雜的
ERP系統。
一般來說,代碼級二次開發主要有以下三個方面的風險:①易造成系統的不穩定或崩潰。
ERP系統是個錯綜復雜的系統,各個模塊是個有機的整體。若要修改其中的一個功能,其影響的不單單是現在這個功能,還可能影響到其他功能。目前實施顧問一般對
ERP代碼級二次開發的一個觀點是:能不做就不要做。因為
ERP系統就像人的血脈那樣錯綜復雜,在二次開發的時候,如果因為增加的用戶個性化功能觸動了
ERP原有的大動脈,否則會大大影響其整個性能,并且開發、調試的費用也是非常嚇人的。
②嚴重影響項目實施周期。代碼級二次開發的時間短則幾天,長則半月、一月,甚至也可能長達幾個月,很容易延誤項目實施進程,這個因素應該在簽定合同或者說制定項目實施計劃時包括進去。
③后續維護和升級風險大。改動軟件后還會影響以后的軟件版本升級。如果不升級,新版本的長處無法應用。如果升級,則面臨著重新進行二次開發的可能。因為
ERP軟件供應商在進行新版本的
ERP系統開發時,可能根本不會考慮某個特定的用戶在舊版本上所作的二次開發。因此,在進行二次開發前,要做認真的分析對比。究竟是修改軟件,還是改革現行管理程序,還是兩者都作一些修改,對修改的必要性、效果和代價要心中有數。
反思ERP二次開發的得失
無論是實施顧問還是用戶都可能產生過這樣的感慨:明明是經過幾個月的初期討論和項目分析,在用戶的認可下做好了的
ERP系統,結果由于“二次開發”,系統變得越來越復雜,與最初期望的效果越來越遠,最后猛然一看系統已經完全“變味”了。因此,把握二次開發的原則很重要。
①在觀念認識上,實施顧問應要讓用戶清醒認識到,不應過多強調用戶自身的特點,
ERP軟件中的管理流程是從許多企業中提煉出來的,具有先進性和合理性。許多用戶的特殊之處都是由于流程自身的不合理產生的,應該通過
ERP的實施,對企業進行業務流程優化或重組,而不是一味修改軟件以適應不合理的流程。
②當需要二次開發時,實施顧問和開發顧問應該要嚴格遵守不修改核心代碼這一條基本原則。如果必須進行二次開發,則應盡量使得二次開發做出的功能模塊獨立于原來的
ERP系統。這樣當
ERP系統版本更新時,二次開發出來的模塊無需修改或者只需較少的修改就可以應用于高版本的
ERP系統。
③二次開發的需求必須控制好,盡量不要在
ERP系統的功能還沒有充分了解是否配合用戶管理需求之前就進行二次開發。因為用戶的業務流程并不是一成不變的,
ERP軟件中流程一般比較抽象,大的方面與用戶業務流程通??梢蕴咨?,細節部分不作修改也可以。同時,
ERP軟件不是給一個人用的,每個用戶都可能有自己想法,不可能都滿足的。部分要服從大局。項目按時、按預算完成實施,上線運行是實施階段的大局,哪些二次開發必須要做,哪些可以不做,要看會不會影響大局??勺隹刹蛔龅?,堅決不做。