企業選ERP，最容易把兩件不同的事當成一件。

一件是：今天這張單，系統能不能做出來。 另一件是：明年規則改了，還要不要再請一隊人來改程序。

前一件，二次開發幾乎都能答應。后一件，才決定這套系統是資產還是包袱。

對已經把ERP用進采購、生產、銷售和財務的企業來說，參數化配置多，是一件好事。不是多幾個菜單那么簡單。是工單、BOM、審批、庫存、成本、組織這些經營對象上，能被參數接住的變化越多，企業就越不必為每一次個性去買開發。配得越多，經營越主動；個性不必按次付費；少改一次程序，就少一輪測試。二次開發能應急。企業不能靠應急過日子。

可這件事還有后半句，不寫出來，前面全是空的：

多是好事。多而不管，就不是。

企業里把參數化做砸的，通常不是因為參數太多，而是實施把“多”理解成把開關全部擰開，又把難點看輕了。難點不在軟件菜單有沒有開關，在規則、人、測試和實施。

一、能開發是廠商的靈活，能配置才是企業的靈活

合同里寫了“支持定制”，很多人就覺得給自己留了后路。這后路是廠商的。廠商有人、有排期、有報價，當然什么都能做。

企業要的靈活不是這個。

插單來了，工單要不要拆；設計改了，BOM哪一版生效；客戶換了結算方式，審批走哪一條；新工廠、新事業部開工，報工和成本按什么口徑歸——這些事不會預約，也不會等你立項。

規則在配置里，計劃、物控、關鍵用戶還能動；規則在代碼里，全公司都得排隊。

所以參數化配置要多。多的意思，是覆蓋面：能進配置層的經營規則越多，企業自己能做主的空間越大。不是系統越重，是企業越自由。自由的意思很具體：變化發生在自己家里，不必先變成一張開發單。

參數少，企業看起來輕松，其實是把大量變化預支成了以后的開發。參數多，企業今天要多做決定，以后才不必反復求人。這正是“多”對企業是一件好事的原因。

二、SAP、Oracle、萬達寶，都把參數做多

這件事如果只停留在道理上，還不夠硬。把企業選型時真正會拿來對標的幾套系統放在一起看，結論會清楚得多。

SAP在全球制造企業里能用很多年，靠的并不是“你要什么我們做什么”。它把工廠日歷、MRP范圍、工藝路線、檢驗類型、訂單類型先做成大量參數，實施的主體工作是在配，不是在寫。參數覆蓋得深、覆蓋得廣，企業才有可能在組織、物料、生產和質量這些層上先適應變化，而不是一變就改程序。

Oracle走的是同一條路。彈性域、業務規則、工作流，都是讓企業的個性先停在配置層，開發放在后面當補充。

萬達寶服務大量亞洲制造和貿易企業，字段、界面、審批和一部分業務規則更靠近現場，參數同樣往多里做：常見的經營變化，盡量先被配置接住，而不是先變成項目。

三個名字，體量不同，顧問也不同，方法卻相近。能長期跑下去的ERP，幾乎都把參數做多，而不是把開發當靈活。國際系統往往深，動起來更依賴顧問；更貼近現場的系統，把一部分配置留給企業自己的計劃、生產和物控。

對企業來說，這不是在排座次。這是在說明：參數化配置多，不是某家的說法，是SAP、Oracle、萬達寶這類系統已經走過的路。低價、小工具型軟件很少認真討論這些，不是它們更簡單，是很多參數本來就不在里面。等企業要管細，能改的只剩下代碼。參數少的輕松，是預支的。

可這件事還有后半句，不寫出來，前面全是空的：

多是好事。多而不管，就不是。

企業里把參數化做砸的，通常不是因為參數太多，而是實施把“多”理解成把開關全部擰開，又把難點看輕了。難點不在軟件菜單有沒有開關，在規則、人、測試和實施。

三、規則說不清，參數再多也是空的

參數是規則的容器。容器本身不產生規則。

超發料誰批、按什么數量、跨組織調撥算銷售還是調撥、返工料回不回原工單、齊套差一件能不能先開工——這些問題如果還在老師傅腦子里、在幾套對不上的Excel里、在車間和財務各執一詞里，配什么都是假的。

實施一問，現場開始爭論。爭論沒有結果時，最省事的出口就是：先按現在這樣開發死。

于是很多人以為自己卡在軟件。其實卡在企業還沒有一句話能拍板。

參數化最不客氣的地方就在這里：它逼著企業把口頭習慣變成可執行的規則。規則說不清，配置只是把糊涂數字化。二次開發看起來更痛快，是因為它允許糊涂繼續存在，只是用代碼把某一次做法釘死。釘死以后，下一次爭論還來。

參數再多，也接不住一句都說不清的話。

四、參數多，不是把所有開關擰開。

開關一多，配錯比不會配更常見。

同一物料，工廠級策略和倉庫級策略打架；同一張工單，訂單類型、默認倉庫、倒沖領料把計劃員繞進去；同一條審批，金額、客戶類型、物料組疊了三層，誰也說不清為什么這張單被卡住。

配的時候圖快，沒人記錄改過什么、為什么改、哪天生效。過三個月，誰都不敢動。

企業這時很容易得出一個錯誤結論：參數還是少一點干脆，不行就開發。干脆的是眼前。留下的是一套沒人敢碰的系統。這里要分開兩件事：

參數覆蓋面多，是好事。參數沒主人、沒記錄、沒邊界，是壞事。

前者說的是工單、BOM、審批、庫存、成本里，有多少變化能不改程序。后者說的是誰能擰、擰完留痕、能不能回滾。沒有邊界的配置，和沒有配置一樣危險。前者亂，后者死。企業要躲的是這兩種，不是躲“多”本身。

五、會配的人一走，參數等于沒有。

配置要有主人。

完全丟給IT，IT不懂這道工序為什么必須拆單；完全丟給車間，車間不會先想到財務期間和成本卷。企業需要能聽懂兩邊的人：關鍵用戶。

這個崗位在很多企業的編制里并不存在。項目期間臨時抓壯丁，上線后各回各崗，參數變成無人區。下一步，變化重新送去開發。不是系統忽然不會配了，是會配的人被項目遣散了。

參數再多，沒有人接，就等于沒有。

更麻煩的是，關鍵用戶不能只會點。他們要判斷：這是一次例外，還是規則要改。例外走臨時處理，規則走配置。分不清這兩件事，配置權會變成現場的新后門——誰聲音大，誰改一版。

參數化失敗，有時不是權限太少，是權限給錯了人，又沒有人復核。對企業來說，配置多要求的不是更多操作工，是更清楚的人：誰拍板，誰執行，誰驗收。

六、開發好報價，配置難驗收

還有一層更少被寫進實施計劃，卻經常決定項目走哪條路：不是所有實施都愿意把配置做透。

開發好報價，好驗收，好證明工作量。配置做深了，要開會，要拍板，要培訓，項目看起來慢，賬面不一定更好看。

于是“先開發頂上”會成為房間里最容易達成的共識。企業當時覺得問題解決了。幾個月后才發現，每一次小變化都還要再買一次。

參數化配置多這個好處，就在這一步被賣掉了。

把幾套企業真正會拿來對標的系統放在一起看，這件事更清楚。SAP參數多，是它能長跑的原因之一。可配得深，不等于企業自己配得動。顧問走了，后臺參數仍在，企業不敢碰，后來每一筆還是開發。Oracle也是如此。彈性域、業務規則、工作流能把個性停在配置層；停得住，還要看企業有沒有人接。萬達寶把參數往多里做，是為了讓企業少走開發。可開關在，人不在，一樣會廢。

能長期跑下去的ERP，幾乎都把參數做多，而不是把開發當靈活。對企業真正值錢的，不是品牌，是參數覆蓋了多少經營變化，以及這些參數自己的人用不用得了。

七、少一輪開發測試，不是零測試。

少一輪開發測試，不是零測試。

工單類型配錯、MRP范圍配錯、審批閾值配錯，炸的是實賬和實料。企業要的是一份短的、跟業務走的驗證：這張單還會不會齊套，這筆料還會不會倒沖，這個成本還會不會卷到原訂單。

不是把“配一下”當成不用負責。

測試變短，正是參數多了之后才出現的好處：改的是規則，回歸可以按單據、組織、流程劃清，驗收可以回到車間和物控，而不必先讀一疊程序說明。升級時配置還在，也不必把舊定制再修一遍。

可如果實施階段根本沒人驗證配置，企業只是把炸彈從代碼里挪到了參數里。省下的時間會在第一張錯單上連本帶利回來。

產線等系統的時間，比會議室里的開發計劃貴。配錯的時間，同樣貴。參數多，省的是開發測試；省掉驗證，就不是多的紅利了。

八、個性必須以配置進系統，而不是按次開發

企業沒有個性，這不成立。

電子廠有替代料和換線，機械廠有非標和多層BOM，服裝廠有顏色尺碼和損耗，食品廠有批次、效期和追溯，貿易和多組織企業還有價格策略、信用和核算口徑。

個性要以什么方式進系統，才是分界。

按次開發，眼前一定能做出來，隨后變成代碼分叉：升級越貴，維護越糊，企業以為買到了自己，其實買到的是以后每一筆再買一次。

參數化配置多，就是把這件事反過來。字段、審批、權限、單據、校驗、管理維度，能進配置的都進配置。覆蓋面越寬，企業為個性付的開發費越少，為變化付的等待越短。開發留給行業算法、外部集成，以及產品確實到不了的地方。

一個字段、一條審批、一張報工單，不該成為項目。同樣，也不該成為某個臨時人員夜里改掉、白天全公司找不到原因的事故。

少做二次開發，省下的不只是錢，是這套系統還能不能算企業自己的。

前提是：企業愿意為“多”付出實施上那些難看的成本——把規則從口頭里逼到紙上，給關鍵用戶編制而不是抓壯丁，允許改、同時記錄、審批、能回滾，合同里買的是把變化留在企業手里的方法，而不只是開發人天。

九、先問能配多少，再問能不能開發

企業選ERP，問法就該換。

不要只問支不支持二次開發，功能清不清單，案例像不像自己。

要問參數多不多。但問的不是開關數量，是覆蓋面：工單、BOM、工藝、庫存、審批、成本、報表，有多少能在不改源碼的前提下調整？規則今天說得清嗎？誰來調，調完誰驗，升級以后還在不在？實施團隊面對爭論，是逼企業拍板，還是立刻改程序給一個假平靜？

能開發，只說明廠商做得到。能配置，而且配得多、接得住，才說明企業自己還做得了主。

接得住的意思，不是菜單上有配置項，是企業過得了規則、人、測試和實施這幾關。演示很順、特殊需求張口就答應開發的系統，最容易讓人以為買到了靈活。真正要看的是：變化發生時，企業自己的人還動不動得了；動的時候，還知不知道自己動了什么。

參數化配置多，對企業來說是一件好事。好就好在：今天能被參數接住的變化越多，明天就越不必把特殊需求做成項目習慣。

可它要求企業在實施時做一件更難受的事：先把自己講清楚，再把變化的鑰匙拿回來。鑰匙拿不回來，參數再多，也只是別人家里的開關。

鑰匙拿得回來，參數就該多。多，才是企業的。