在前面的幾篇文章中，筆者依次點明ERP的三處“軟肋”，即取消會計的庫存賬、不能全過程計算產(chǎn)品成本和不能編制現(xiàn)金流量表。計算機應用于企業(yè)管理，習慣上叫管理信息系統(tǒng)（MIS），ERP只是MIS的時尚別名，是20世紀90年代才提出來的新概念。而會計信息系統(tǒng)（AIS）本來就屬于管理信息系統(tǒng)（MIS），公認是后者的有機組成部分。從會計領域下手評說，不但沒有偏題，還便于讀者基于自已的專業(yè)背景，判斷這些批評是否有道理。本文打算從后臺會計轉(zhuǎn)向前臺業(yè)務，圍繞會計所監(jiān)控的“供產(chǎn)銷三環(huán)節(jié)”，考察ERP在內(nèi)部物流管理方面的實際業(yè)績，分析其之所以失敗的設計根源。

　　模塊成功≠ERP成功

　　我們順著供產(chǎn)銷主流程來觀察實物流動，會感到它是非常直觀的直線過程，就如圖1中的粗黑線所表示的，從供應商發(fā)送原材料開始，進入原材料庫，然后投入生產(chǎn)制造，完工后進入產(chǎn)成品庫，最后送到顧客手中而結束。根據(jù)這樣的表面現(xiàn)象，如果讓“鐵路警察各管一段”，用采購模塊處理供應商與原材料采購的關系，用生產(chǎn)管理模塊來管理從原材料投入到產(chǎn)成品交庫的內(nèi)部過程，用銷售模塊處理顧客和產(chǎn)成品發(fā)送的關系，似乎也有道理，而且以模塊套裝式構建整體的ERP，是全世界一致的套路，好像所有人都同意，ERP天生就該這么切塊的。甚至可以說，ERP領域最為顯眼的關鍵詞，便是“模塊化”。不知道從什么時候起，會計軟件也好，ERP軟件也好，都成了買賣“模塊”的交易。供應商迫不及待地演示模塊，告訴我們可以選擇買一個模塊、兩個模塊……要多少，只管放心往上堆就是了，模塊越多的供應商越有說服力。用戶受這種“教化”的結果，看到模塊什么功能都有，高興得很，除了只會問“你這軟件有多少模塊？”也就不知道還要了解什么了。

　　但是，模塊是用來處理數(shù)據(jù)的，數(shù)據(jù)不能只“窩”在模塊里流動，它要在模塊間暢通無阻地來回流轉(zhuǎn)！豆腐切開后不能無縫粘結，那么，模塊切開后，總有個重組裝問題，在模塊接合部上，怎么確保數(shù)據(jù)流的銜接與一致？

　　這是ERP設計理念是否成立的根本性問題。我們從會計總賬模塊和庫存模塊之間的脫節(jié)，已可看到模塊化設計的毛病。姑且不說庫存明細賬是“別人”的，即使ERP只讓財務部自己用，也會有麻煩，那就是：庫存模塊有金額和數(shù)量雙重核算，處理業(yè)務后，能向總賬模塊傳送只有金額的記賬憑證；總賬模塊只有粗略的金額核算，完成與庫存有關的賬務處理后，卻不能向庫存模塊傳送既有金額又有數(shù)量的數(shù)據(jù)，分攤到品種上，以保持雙方一致。這就和“單向閥”一樣，導致兩個模塊的數(shù)據(jù)脫節(jié)。其實，會計本來是從上到下渾然一體的，從總賬到最底級的明細賬一氣呵成，把明細賬加起來就是總賬，永遠也不會出問題。硬要切成總賬和明細賬模塊，再來設法調(diào)平，豈不是舍近求遠？

　　在物流調(diào)度上，更加回避不了的問題是：當試圖用“大卸八塊”的模塊來處理暢通無阻的數(shù)據(jù)流時，必然碰到“模塊為王”還是“數(shù)據(jù)為王”的問題。ERP顯然是以模塊為中心的，供應商對于模塊功能描述得很細，但在模塊與模塊之間的接合部上，數(shù)據(jù)如何相互溝通，則完全沒有人提起。

　　對于軟件系統(tǒng)而言，唯一的評價標準就是用戶的需求。那么用戶要的是什么？不是模塊，而是數(shù)據(jù)，處于不同職能上的用戶是依靠數(shù)據(jù)工作的！首先要了解其所處理業(yè)務的當前狀況，例如銷售部要知道當前有多少可供銷售的商品（這也許是倉庫管理員等部門的操作結果）；采購部門要知道有多少未完成的銷售訂單，有多少可供銷售的商品，該采購多少（這又是銷售部門和倉庫管理員等部門的操作結果）……其次，所有部門在軟件上所做的操作，會立即改變后續(xù)工作所得到的信息，例如銷售票據(jù)一旦開出，接著要開具下一張時，觀察到的可供銷售的商品數(shù)已減少了，財務部門知道要準備收款，倉庫管理員知道該出貨了，儲運車隊開始調(diào)度車輛……數(shù)據(jù)在各職能部門間暢通無阻，動態(tài)地交互作用，這才是評價ERP系統(tǒng)是否成功的終極標準。在許多案例中，套裝式的ERP軟件只用上一兩個模塊（如銷售模塊）便宣稱ERP成功上線?？墒牵呛蛡鹘y(tǒng)的信息孤島軟件又有什么區(qū)別呢？充其量也只是一個模塊的成功，而絕不是ERP的成功。

　　為了找到答案，筆者曾遍翻某世界最知名的ERP廠商出版的十幾冊英文原版書，發(fā)現(xiàn)書中對每個模塊的介紹都詳盡無遺，而對于ERP是否成功的真正標志，即模塊與模塊之間如何溝通數(shù)據(jù)、如何使之交互作用、整體聯(lián)動起來，幾乎是不著一字，只看到“填表”（fill tables）一詞還算與此有關，具體如何做，卻又語焉不詳。這只有兩種可能，一是設計者自己也不知道；二是事關軟件的超級商業(yè)機密，因此絕口不提。可是，該公司自己又不在現(xiàn)場干活，而是通過咨詢顧問進行推廣的，不交代清楚模塊之間數(shù)據(jù)如何對流，讓人怎么裝配設置？所以，最可能的答案應是“設計者自己也不知道”。

　　案例演示

　　作戰(zhàn)時，友軍的結合部往往是最薄弱的環(huán)節(jié)，軟件模塊也是如此。所以，筆者就“哪不開偏提哪壺”，通過一個虛擬的商品流通企業(yè)案例，重點揭露模塊結合部上的問題。

　　我們假設這個企業(yè)只經(jīng)營一種商品，買進來以后就賣出去，完全按銷售訂單來組織供應。采用“就地收購”和“訂單購進”兩種供應方式，“就地收購”的過程是由供應商送上門來，暫放倉庫，如果質(zhì)量檢驗后符合要求，就承付貨款成交，否則退還供應商自行拉回；“訂單購進”則是一般的商業(yè)采購模式。為了便于統(tǒng)一管理，在完成各種有關物流的業(yè)務處理時，也將該業(yè)務登記在表1中，對表中的有關欄目說明如下：

　　業(yè)務說明：表現(xiàn)各種不同的業(yè)務類型。

　　對應項目：用于登記與該業(yè)務有關的機構或人員，如銷售合同必有顧客，收貨待驗必有供應商，沒有對應項時不必填寫。

　　庫存總數(shù)：倉庫管理員所實際負責保管的存貨。

　　自有數(shù)：在庫存總數(shù)中，所有權屬于會計主體的那一部分存貨（會計后臺監(jiān)控的對象）。

　　代管：在庫存總數(shù)中，屬于為別人代管的那一部分存貨，如供應商送來，尚未通過驗收的存貨，或顧客已領取，但尚未能拉走的存貨等。

　　可用數(shù)：在自有數(shù)中，尚未有確定用途的那一部分存貨，本欄合計數(shù)即“可用而未用數(shù)”。

　　已用數(shù)：在自有數(shù)中，已有確定用途的那一部分存貨，本欄合計數(shù)即“已用而未提領數(shù)”。

　　未完銷售：表現(xiàn)銷售訂單的簽訂和執(zhí)行情況，本欄合計數(shù)即“已簽訂而未完成的銷售數(shù)”。

　　未完采購；表現(xiàn)采購訂單的簽訂和執(zhí)行情況，本欄合計數(shù)即“已簽訂而未到貨的采購數(shù)”。

　　在“業(yè)務說明”欄中，各類業(yè)務處理后，在登記表1時，該業(yè)務數(shù)據(jù)要滿足的約束條件如下。

　　銷售合同：簽下銷售合同的業(yè)務，因還未執(zhí)行，對“東海超市”的“未完銷售”做加法。

　　收貨待驗：就地收購的商品，茗香農(nóng)莊送來，因還未驗收，對“庫存總數(shù)”和“代管數(shù)”欄做加法。要滿足的約束條件：本次收貨數(shù)≤（“未完銷售”當前合計 – “可用數(shù)”當前合計 – “未完采購”當前合計）。

　　承付通知：對就地收購的“茗香農(nóng)莊”代管商品，驗收無異議后，通知財務付款。雖然財務付款也許還需時日，但已可認為是自己的商品了，所以對“代管數(shù)”做減法，對“自有數(shù)”和“可用數(shù)”做加法。要滿足的約束條件：承付商品數(shù)≤“茗香農(nóng)莊”的“代管”當前合計數(shù)。

　　采購訂單：對東風茶廠發(fā)出采購訂單，對“未完采購”做加法。要滿足的約束條件：本次采購數(shù)≤（“未完銷售”當前合計 –“可用數(shù)”當前合計 – “未完采購”當前合計）。

　　采購進庫：對東風茶廠發(fā)出的采購訂單到貨，對“東風茶廠”的“未完采購”做減法，對“庫存總數(shù)”、“自有數(shù)”和“可用數(shù)”做加法。要滿足的約束條件：本次進庫數(shù)≤“東風茶廠”的“未完采購”當前合計數(shù)。

　　銷售開單：組織供貨完成，對東海超市開出銷售單，對“可用數(shù)”和“未完銷售”欄做減法，對“已用數(shù)”做加法。要滿足的約束條件：本次開單數(shù)≤“可用數(shù)”當前合計數(shù)，且本次開單數(shù)≤“東海超市”的“未完銷售”當前合計數(shù)。

　　銷售出貨：東海超市提貨，倉庫管理員登記出貨業(yè)務，對“庫存總數(shù)”、“自有數(shù)”和“已用數(shù)”欄做減法。要滿足的約束條件：本次出貨數(shù)≤“東海超市”的“已用數(shù)”。

　　從該案例可見，所有部門既是數(shù)據(jù)需求方，也是數(shù)據(jù)提供方，某一職能部門的工作均要受到其他部門前期工作結果的約束，而其操作結果也反過來對其他部門產(chǎn)生約束作用，他們相互的信息依賴性很強，數(shù)據(jù)要在有關職能部門間不定向地流動，想切也切不開。讀者也許不相信，這么一個簡單得不能再簡單的表格，它所表達的，才是用戶對ERP物流管理的真正數(shù)據(jù)要求。如果各部門都在一起，沒有通信問題，也忽略手工處理速度低的問題，為每種物料設一張表，按以上規(guī)則填寫這個表，是不是已經(jīng)把物流管起來了，存貨還壓到了最低？內(nèi)部物流管理是ERP的核心，而其成功運作的唯一標志，就是涉及物流的各部門“整體聯(lián)動”地工作，實現(xiàn)最佳調(diào)控。達不到這一要求的ERP，都是失敗的。

　　可以說，ERP極高的失敗率，其實就源于“信息孤島”式的模塊設計，特別是在物流管理領域，設計者將手段（模塊）置于目標（數(shù)據(jù)）之上，任意切塊，阻斷了數(shù)據(jù)在各部門間的順暢流動。