信息中心
ERP實施手記：生不如死的二次開發
無休止的ERP實施加班，無休止的項目實施變更、延期，無休止地在做需求調研、編寫需求方案，展開需求驗證，一再地處理因為二次開發帶來的BUG；ERP項目實施過程就被這無休止的二次開發活生生地拖死了，把這篇文章再翻出來，其實是想告訴大家：客戶有他自己的要求，但對于ERP顧問和項目經理而言，并不是所有的要求就一定是需求。請注意ERP顧問在行為態度評估標準中關于“客戶意識”的說明：幫助或服務客戶的愿望以滿足他們的要求，專注于如何發現并滿足客戶的需求（專業與公司戰略和業務緊密結合）。我們的目標是滿足客戶的要求，但我們需要通過我們的專業能力專注于發現并滿足客戶的需求。意味著需求是被我們挖掘和發現的，往往不是客戶直接所能表達的。這也是為什么我們有許多項目做了大量二次開發以后，客戶滿意度還不高的原因，因為我們看似滿足了客戶的要求，但這并不是他的真實需求。
無休止的ERP實施加班后，我終于迎來了難得的半天休息，在家舒服地看了電影《特洛伊》讓我感受至深——古希臘神話中所向披靡的勇士阿喀琉斯最怕腳后跟受傷，成為其致命的“命門”，其實ERP也有最怕觸及的“命門”，這就是二次開發。
多數情況下，二次開發都會演變成一個對ERP系統無休止的修改過程，最終會把用戶和廠商都拖進泥潭難以自拔，而開發和實施顧問則會心力交碎，生不如死。
固執己見的客戶
在我做ERP實施顧問的第一天，上司告訴我第一條準則就是要以用戶需求為驅動。然后，上司又告訴我第二條準則：作為實施顧問要堅決不贊同用戶進行太多的二次開發，過多的二次開發不僅會增加軟件的不穩定性，還會延長實施項目的周期，從而增加項目成本，要用盡各種各樣的辦法把用戶需求向ERP軟件已有的流程上走。這兩個看起來相互矛盾的準則，令我在近期一個ERP項目實施過程中感到生不如死，左右為難。
用戶是一個老國企，在界面上和操作上提出非常多的特殊要求，固執地要求按他們的習慣進行二次開發，以滿足他們原有的操作模式。一般來說，我們的ERP軟件產品為了具有較強通用性，軟件功能已經比較標準，流程設置也相對規范化。雖然通過參數可調的形式可以部分滿足不同用戶的需求，但很多情況下這種“輕度”靈活會失效。
用戶的固執或偏見主要是表現在這幾面：
①不愿意改變現有的操作習慣。用戶想把現在的手工流程、手工作業一成不變地搬到ERP中去，而這恰恰是換湯不換藥的做法。當我對用戶分析ERP現有的流程與用戶原有的流程的優劣性比較時，用戶一句話就把我頂住，說我們一直是這樣做，而且還做得不錯，我們就是用這樣的管理手段得到發展，并且獲得了上你們ERP系統的資金，以后還打算一直用我們習慣的方式去管理。
用戶除了在業務流程等方面具有個性化需求外，往往還存在著一些不涉及業務流程的、由企業的特殊性而產生的個性化需求，例如單據/表格的格式。一般ERP都會提供通用的單據格式，而用戶又有自己習慣的一套單據格式。因此在實施時，企業上來就問能否按這個格式打印。其實，這是本末倒置，只要該有的內容有了，沒有必要一成不變的按原由的格式。
這樣的問題在我參與的實施中時常出現，與用戶溝通常常讓我費盡心力，舌根冒火才勉強說服用戶同意先試用單據格式。這樣不但容易造成項目延期，而且還把大家注意力轉移到無關系統的邊緣流程上，吃力不討好現象時常發生。
只有當碰到無法通過調節參數來完成;或者報表功能真是不適應用戶需求時導致報表樣式、內容要改變，這些情況才應該通過二次開發來實現。這種因操作習慣提出的二次開發主要針對用戶各類報表系統的查詢，打印格式和字段標準化等方面。
②不合理的管理制度造成的特殊流程需求。用戶有些二次開發需求，是原先不合理的管理制度和流程所造成的。因此，我們首先要做的是判斷其要求的合理性，然后深入到一線去找出真正的需求。而無數的事實證明，大量由于不合理的管理流程需求提出要二次開發的案例最終都失敗了。
③ERP軟件確實無法滿足需求。當然，每個用戶確實都存在著一些ERP無法滿足的個性業務流程需求，畢竟ERP是一個套裝軟件，而不是根據用戶量身定制的。針對這種需求，即使通過各種各樣的實施方法后，也沒有找到更好的處理方式，那只好進行二次開發了。
二次開發的風險
當用戶明確提出要二次開發的時候，則很容易出現項目延期、開發的程序不穩定容易報錯等問題;或者用了一段時間后想再做修改，才發現原來當初這樣做是不對的，但可能涉及當初拍板決定的各方領導利益問題，所以也沒人敢改了，因此導致二次開發的程序成了雞肋，扔也不是，不扔也不是。
①修改報表格式或用戶查詢系統等不涉及程序代碼改動的需求相對簡單，因為軟件一般都具有報表生成功能，任何業務人員不需要有很多計算機知識就可以自行設置，這種情況在實施時經過實施顧問組與用戶充分溝通一般比較容易解決。
②當用戶需求具有個性化，并涉及改動程序代碼時，工作就很復雜了，往往需要ERP系統提供支持二次開發的工具，還可能需要有廠商軟件的源程序支持，這些大都要支付額外費用。
當用戶提出需要代碼級二次開發時，實施顧問必須清楚與用戶溝通，否則更易陷入泥潭，因為代碼級二次開發可能會使ERP系統變得越來越復雜，變成一個“四不象”的浮腫龐雜的ERP系統。
一般來說，代碼級二次開發主要有以下三個方面的風險：
①易造成系統的不穩定或崩潰。ERP系統是個錯綜復雜的系統，各個模塊是個有機的整體。若要修改其中的一個功能，其影響的不單單是現在這個功能，還可能影響到其他功能。目前實施顧問一般對ERP代碼級二次開發的一個觀點是：能不做就不要做。因為ERP系統就像人的血脈那樣錯綜復雜，在二次開發的時候，如果因為增加的用戶個性化功能觸動了ERP原有的大動脈，否則會大大影響其整個性能，并且開發、調試的費用也是非常嚇人的。
②嚴重影響項目實施周期。代碼級二次開發的時間短則幾天，長則半月、一月，甚至也可能長達幾個月，很容易延誤項目實施進程，這個因素應該在簽定合同或者說制定項目實施計劃時包括進去。
③后續維護和升級風險大。改動軟件后還會影響以后的軟件版本升級。如果不升級，新版本的長處無法應用。如果升級，則面臨著重新進行二次開發的可能。因為ERP軟件供應商在進行新版本的ERP系統開發時，可能根本不會考慮某個特定的用戶在舊版本上所作的二次開發。因此，在進行二次開發前，要做認真的分析對比。究竟是修改軟件，還是改革現行管理程序，還是兩者都作一些修改，對修改的必要性、效果和代價要心中有數。
反思ERP二次開發的得失
無論是實施顧問還是用戶都可能產生過這樣的感慨：明明是經過幾個月的初期討論和項目分析，在用戶的認可下做好了的ERP系統，結果由于“二次開發”，系統變得越來越復雜，與最初期望的效果越來越遠，最后猛然一看系統已經完全“變味”了。因此，把握二次開發的原則很重要。
①在觀念認識上，實施顧問應要讓用戶清醒認識到，不應過多強調用戶自身的特點，ERP軟件中的管理流程是從許多企業中提煉出來的，具有先進性和合理性。許多用戶的特殊之處都是由于流程自身的不合理產生的，應該通過ERP的實施，對企業進行業務流程優化或重組，而不是一味修改軟件以適應不合理的流程。
②當需要二次開發時，實施顧問和開發顧問應該要嚴格遵守不修改核心代碼這一條基本原則。如果必須進行二次開發，則應盡量使得二次開發做出的功能模塊獨立于原來的ERP系統。這樣當ERP系統版本更新時，二次開發出來的模塊無需修改或者只需較少的修改就可以應用于高版本的ERP系統。
③二次開發的需求必須控制好，盡量不要在ERP系統的功能還沒有充分了解是否配合用戶管理需求之前就進行二次開發。因為用戶的業務流程并不是一成不變的，ERP軟件中流程一般比較抽象，大的方面與用戶業務流程通常可以套上，細節部分不作修改也可以。同時，ERP軟件不是給一個人用的，每個用戶都可能有自己想法，不可能都滿足的。部分要服從大局。項目按時、按預算完成實施，上線運行是實施階段的大局，哪些二次開發必須要做，哪些可以不做，要看會不會影響大局。可做可不做的，堅決不做。
集成系統網絡情報信息數據庫
CIO頻道人物視窗
CIO頻道方案案例庫
大數據建設方案案例庫
電子政務建設方案案例庫
互聯集成系統構建方案案例庫
商務智能建設方案案例庫
系統集成類軟件信息研發企業名錄