由于國內企業實施ERP/SCM的時間較外國企業晚，對于ERP/SCM企業資源整合全面電算化的經驗和專業應用上普遍都較歐美企業晚起步二十年以上。因此，有許多MIS和經營管理咨詢公司的專業從業人員都可能會誤認為：‘歐，美，日國家的ERP/SCM企業資源整合全面電算化的專業技術肯定比國內先進，完美！’。這個想法也許可以被容許，但是卻不是絕對正確的看法。羅馬帝國發展得比美國還早N千年，如果照前面這個道理推理的話，美國的科技永遠都趕不上羅馬帝國，這個誤解能稱得上是個道理嗎？先做的人不必然做得更好，慢做的人也未必然做得不好，巧思妙用完全存乎于不同專業人才的腦海構思規劃里，誰家天下則是自有安排。
首先說個簡單的故事：有一天早上，一輛載滿貨物的卡車沖進了遂道，由于高度超過了遂道高度，卡車的前半身卡在遂道里，后半身則露在遂道外頭，進退不得，卡車司機沒有受傷，可是卻把整個遂道堵得水泄不通，綿延了數公里的車隊。交警找來了各種車輛協助將卡車拉出遂道，來來回回三，四個小時都無功而返，周邊圍了四，五百人看得膛目結舌，就是拿不出一個法子。突然一個七歲的孩子走到這個地方圍觀，他開口說：‘就把卡車的所有輪胎泄了氣，卡車就不會卡住遂道了，不是嗎？’，結果眾人一試，卡車輪胎泄了氣，就少了近40公分的高度，果真卡車就順利拉出來了！如果你說：‘我吃的鹽巴比你吃的飯還多上千百倍！’，這個只有倚老賣老的人才會有這么個無知的說法，所謂：‘后生可愄’，這個肯定是個平凡的道理。
如果你具備一定的經營管理專業知識，有相當年資的軟件規劃和開發的實務經驗，加上在制造產業實際輔導ERP全面電算化實施的經驗，你將能夠輕易的發現，目前國內、外很多ERP軟件系統規劃的架構理念是有嚴重的錯誤的，一套良好的ERP系統不僅僅是功能要完整，整合程度要高，運行效率要快，實施過程要短，必須具備QRM快速反應機制，維護作業要簡單，移植能力要好，還要實質上能大幅降低營運成本。可是，當你使用過國內、外ERP軟件，你會發覺，這些ERP的最終的訴求，他們大部份都無法實現。
舉個案例來說：國外軟件在系統架構上，將所有關系企業的數據都存放在同一個數據庫Database里，光是這個規劃方式，就是一個非常嚴重的錯誤。我們把幾個問題范例給予提列出來：1.多家關系企業的數據都存放在同一個數據庫，把沒有任何關系的數據存放在一起，系統執行的速度肯定會變得更慢，這已經違反了ERP提高工作效率的原則。從10，000筆資料中查找一筆符合條件的資料，和在100，000筆資料中查找一筆符合條件的數據，你認為不會影響速度嗎？將一個公司過期的ERP資料結轉到歷史文件，和將十個公司過期的ERP數據結轉到歷史文件，所使用的時間會是一樣的嗎？一套好的ERP軟件系統的使用量是非常驚人的，每個User占用Data server或AP server的時間越長，就表示電腦提供服務的時間就越久，運行的效率就越差。對于只有白天上班的企業來說，其利用下班時間來處理大量的批次過檔數據，可能還有相當充裕的時間，可是對于24小時輪班的企業而言，晚上時間還有大量的電腦用戶在執行工作，如果要將多家關系企業的大批量過期資料結轉到歷史檔中，這就會嚴重的干擾到其他User的工作執行。這個和單獨將一家企業的過期資料結轉到歷史檔中所需要耗費的時間和速度是非常不一樣的。
2.任何一種ERP的資料Table，在每一家關系企業，都有不同的屬性或用途，例如：料品主檔，相同的一個料品，在AX01公司屬于原材料，在BL01公司屬于半成品，在DX03公司屬于制成品，在FC02公司則是屬于商品，到底由哪家公司的人來負責定義這個屬性？為甚么別人公司的數據要由某個人來統一設定呢？另外，屬于研發機能的屬性該由誰來設定？屬于采購機能的屬性該由誰來設定？屬于生產機能的屬性該由誰來設定？屬于營業機能的屬性該由誰來設定？屬于委外加工機能的屬性該由誰來設定？屬于生管機能的屬性該由誰來設定？屬于物控機能的屬性該由誰來設定？屬于財務和成本屬性的數據該由誰來設定？本來各公司自行設定，既快速，又簡潔，現在把它搞在同一個Database，就變得復雜無比，每建立一個新的產品，就可能有幾十項到幾百，幾千項新的子階料品，就需要等待這些料品都建立完畢，才能開始順利運作，這算是有效率的管理模式嗎？為了每一個關系企業而設定的不同屬性的數據，能夠放在同一個Table里定義嗎？10個公司的屬性和50個公司的屬性，如果存放在一起，字段數量肯定不同，因此，肯定必須放在不同的Table里，這就讓系統的復雜度變大了，如果有30個關系企業，對于不同的屬性數據，就必須開30個Table，在系統的維護工作上，不就變得非常復雜了嗎？一個人有一個頭，一個身體，兩條胳膊，兩條腿，五臟六府。..。..，這是何等的靈活而有效率，現在把30個人的頭，身體，胳膊，兩條腿，五臟六府。..。..等等全部結合在一起，這個架構能夠更有效率的運行嗎？從30個合倂的人體中讓其中一個人運作，速度可能會變快還是變慢？這么一個復雜的人體結構，一旦動起手術來，會比幫一個人東手術快嗎？這個道理應該非常的簡單。
3.一個料品在兩個關系企業中，可以使用不同的料號，既然料號不必然相同，資源也不能共享，將兩家公司的料品放在一個Database數據庫里，有任何意義嗎？把30家公司的料品放在一個Table里，在計算機執行的效益里能達到何種好處？如果要求所有關系企業都必須使用相同的料號，這個本身是不現實的，首先，相同的料品，不同的產地，其成本結構可能有相當大的差異，使用同一個料號是行不通的。其次，當集團公司購并一個新的關系企業，員工有6000人，料品有50，000項，是否要求必須將該企業所有料品都依據集團料號整編后，使用相同料號才能開始運作？到底整編一家6000人的企業需要投入多少時間？在沒有完成整編之前，就不能獨立運作嗎？就不能產生集團財務合并報表嗎？如果各關系企業允許使用不同的料號，每個關系企業有20，000種料品，30個企業就有600，000筆料號，把這樣無法相互利用的數據堆放在一起，有任何意義嗎？能提升系統運行的效率嗎？
4.同樣是會計總帳，不同的企業可能就有不同的營業型態（Business model），就可以規劃不同的會計科目，不同的公司就有不同的簿記賬冊，產生不同的財務報表。把多家公司的會計總帳資料放在同一個Database中，用公司代碼加以區隔，并不能提升任何工作效率，而且，不屬于某家公司的會計科目，全部顯示出來讓會計人員選擇，還會出現誤用會計科目的可能，如果每個企業使用的會計科目以公司代碼將其分隔，避免誤用會計科目，則會計科目就無法資源共享。對于無法達到資源共享的數據把它們放在同一個Database，到底有甚么意義？當集團企業在進行集團內部交易調整/沖銷分錄之時，這些關系企業的會計總帳的傳票（憑證）也不能提供任何合并匯總的用途，集團財務是拿各關系企業的電子表格進行合并匯總作業，這種合并調整和沖銷分錄和會計總帳的會計傳票屬性和做法完全不同，集團財務合并報表屬于合并匯總的觀念，而不是像總帳會計的簿記賬冊的觀念，把這兩種屬性不同管理體系的數據存放在同一個Database中，除了把系統搞得更復雜，能夠得到其它任何效益嗎？所以，從總帳會計和集團財務合并報表的角度來分析，這種架構規劃也是完全錯誤的規劃方式。
5.不同的關系企業可能分布在不同的國家或地區，使用不同的記帳幣別，擁有不同的匯率體系，將30家關系企業的數據放在同一個Database，各自設定不同的記帳幣別，建立不同的每日匯率，這和將數據存放在不同的Database數據庫有何差異？資源無法共享，卻造成數據量變得龐大，執行效率降低，系統維護工作也變得更復雜，這對集團企業有產生任何價值嗎？
6.不同的關系企業就有不同的采購員，生管員，物控員，倉管員。..。..等等，這些人員的工作都完全獨立，并不需要將數據拿來分享，A公司的生管員并不需要知道B公司的任何數據，B公司的生管員也不需要知道C公司的任何數據，C公司的生管員并不需要知道D公司的任何數據。..。..等等，將30家關系企業的數據一起存放在同一個Database，除了導致系統執行速度變得緩慢之外，還能得到甚么其它效益嗎？生管，物控，采購，倉管，制造。..。..制造成本。..。..等等的數據都不具備資源共享的價值，有必要將所有關系企業的數據都存放在一個Database嗎？
7.當集團公司將一個子公司出售時，如果想要將該公司的ERP數據也一并出售給別的法人公司，如何從合并在同一個數據庫Database的所有數據中進行移轉？并確保其移植出去的數據庫數據沒有遺漏。這就要大動干戈，才能確保將該公司保留在原有數據庫的數據，完整無誤的移植出去？如果每一家關系企業的數據都規劃為各自獨立數據庫，只要把ERP系統軟件和Database復制過去就好了，甚么其它工作都沒有。清楚，乾凈利落。
8.人力資源，固定資產，制造成本。..。..等等管理體系。..。..，從任何角度分析，把所有關系企業的資料存放在同一個數據庫，肯定是不合理的規劃方式。由于將多家關系企業的資料存放在同一個Database里，如果想要共用數據資源，就要把各個公司無法共用的數據屏蔽掉，這個工作任務就變得非常繁重而復雜，如果沒有把各個公司無法共用的數據屏蔽掉，就有可能造成User誤選數據，導致后續許多的數據錯誤。當User數據選用錯誤之后，再來事后清理的話，這就等于把狗或貓放在公園到處排瀉，事后再來清理一樣，絕對是一件非常不好玩的苦差事。如果這些存放在同一個Database里的資料使用公司代碼給予區隔，不讓部同的企業共享數據資源，那又何必將這么龐大的不同公司的數據存放在同一個數據庫Database里呢？
從ERP物流，帳流，信息流，資金流的任何一個角度來看，每個關系企業都是一個獨立的個體，都有各自的獨立帳套，每個關系企業的物流數據不得和其它關系企業混雜在一起，每個關系企業的帳流數據不得和其它關系企業混雜在一起，每個關系企業的資金流數據， 不得和其它關系企業混雜在一起，每個關系企業的信息流數據也不得和其它關系企業混雜在一起，就算最基本的公用基本數據和參數設定都不能混雜在一起。所以，沒有任何一家公司的資料可以完整的提供其它關系企業直接延用。既然如此，將集團企業里的每個關系企業的ERP數據合并在同一個數據庫Database里的做法，除了導致數據量非常龐大，系統執行效率變得更加緩慢，維護成本變得非常沉重之外，并不能得到任何實質的效益。在進行集團財務合并報表的處理作業時，其數據結構型態和單一法人公司的數據型態完全不相同，也沒有必要將Consolidate的數據合并在單一法人公司ERP系統的同一個數據庫里頭。你認為歐美公司的ERP軟件系統這么一個規劃設計的構想，有甚么先進性，優越性可言嗎？
一套完整的ERP全面電算化整合信息管理系統所包含的范圍非常的廣泛而博大精深，不論從基礎工程的規劃設定，系統參數的規劃設定，往來客戶和廠商的規劃設定，倉儲管理的規劃應用，總帳會計的規劃應用，財務資金的規劃應用，營銷收款循觀體系的規劃管理，采購付款循環體系的規劃管理，生產制造循環體系的規劃管理，生產管制體系的規劃應用，物料管制體系的規劃應用，委外加工體系的規劃應用，質量管制體系的規劃應用，固定資產體系的規劃應用，人力資源管理體系的規劃應用，制造成本分析體系的規劃應用，稅務管理體系的規劃應用，關務管理體系的規劃應用，短期投資體系的規劃應用，融資貸款體系的規劃應用，產品研發體系的規劃應用，自動立體倉儲體系的規劃應用，廠務管理體系的規劃應用。..。..等等，每一個企業實體都有各自獨立運作的相關體系。不同關系企業之間的數據是不可以搞混在一起的，就算是親兄弟的公司也得明算帳，何況，在現今國際金融體系跨國快速運作的環境下，今天是關系企業的公司，明天就可能不再是關系企業，今天不是關系企業的公司，明天卻可能就是關系企業。今天是屬于控股公司的，明天就不是屬于控股公司。在分分合合的國際金融購併體系下，把隨時都有可能改變關系的公司數據存放在同一個Database數據庫中，你認為這樣的系統集成結構規劃方式是個合理的架構規劃設計嗎？
就算一個集團企業擁有幾十家或幾百家關系企業，30年內都不會改變其關系企業的持股狀態，A公司的采購資料，營業資料，庫存資料，生管資料，會計資料，人力資源資料。..。..等等，和B關系企業有甚么關系？和C關系企業有甚么關系？和D關系企業有甚么關系？。..。..等等。和任何企業都沒有任何關系，每家關系企業都是獨立營運，獨立核算的。既然這些資料或憑證都是和關系企業沒有任何關系，為甚么有必要存放在同一個數據庫里？有這個必要嗎？有需要把File layout搞得這么復雜嗎？
這不是一種批評，或是一種攻擊的言論，純粹是站在一個Open式的學理和實務的探討，真理是越辯越明的.ERP最關鍵的效益就是建立合理化，高效化，標準化，制度化，系統化的營運模式，提高工作效率，減少工作量，降低營運成本，建立企業的神經網絡，提升企業的異常反應能力。可是我們不難發現，國外軟件產業竟然將所有關系企業的數據存放在同一個Database數據庫中，甚至連集團財務合併報表的數據也存放在同一個Database數據庫中，你相信這樣的規劃設計方式能夠提高工作效率嗎？能夠加快電腦的執行效率嗎？如果因為這樣的規劃設計方式導致每筆數據讀取需要增加20%的時間，就表示每個人的工作效率是降低20%，因為每個人都必須要多Waiting20%的時間。何況，把幾十家公司的資料全部混在一個Database數據庫中存放，只會降低20%的運作效率嗎？任何一個企業的信息，耽誤20%的時間，就可能喪失許多商機，增加許多成本，何況是耽誤50%或更多的時間？這是算數問題，并不需要特殊專業的學問才能判斷。從這么簡單的角度分析，外國軟件到底有甚么地方稱得上可以提升產業競爭優勢的？這就是值得國內專家和學者進行思考的其中一個問題！
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：什么樣的ERP架構思想才是正確的？
相關文章
