掃碼下載APP
及時接收最新考試資訊及
備考信息
在前面的幾篇文章中,筆者依次點明ERP的三處“軟肋”,即取消會計的庫存賬、不能全過程計算產品成本和不能編制現金流量表。計算機應用于企業(yè)管理,習慣上叫管理信息系統(tǒng)(MIS),ERP只是MIS的時尚別名,是20世紀90年代才提出來的新概念。而會計信息系統(tǒng)(AIS)本來就屬于管理信息系統(tǒng)(MIS),公認是后者的有機組成部分。從會計領域下手評說,不但沒有偏題,還便于讀者基于自已的專業(yè)背景,判斷這些批評是否有道理。本文打算從后臺會計轉向前臺業(yè)務,圍繞會計所監(jiān)控的“供產銷三環(huán)節(jié)”,考察ERP在內部物流管理方面的實際業(yè)績,分析其之所以失敗的設計根源。
模塊成功≠ERP成功
我們順著供產銷主流程來觀察實物流動,會感到它是非常直觀的直線過程,就如圖1中的粗黑線所表示的,從供應商發(fā)送原材料開始,進入原材料庫,然后投入生產制造,完工后進入產成品庫,最后送到顧客手中而結束。根據這樣的表面現象,如果讓“鐵路警察各管一段”,用采購模塊處理供應商與原材料采購的關系,用生產管理模塊來管理從原材料投入到產成品交庫的內部過程,用銷售模塊處理顧客和產成品發(fā)送的關系,似乎也有道理,而且以模塊套裝式構建整體的ERP,是全世界一致的套路,好像所有人都同意,ERP天生就該這么切塊的。甚至可以說,ERP領域最為顯眼的關鍵詞,便是“模塊化”。不知道從什么時候起,會計軟件也好,ERP軟件也好,都成了買賣“模塊”的交易。供應商迫不及待地演示模塊,告訴我們可以選擇買一個模塊、兩個模塊……要多少,只管放心往上堆就是了,模塊越多的供應商越有說服力。用戶受這種“教化”的結果,看到模塊什么功能都有,高興得很,除了只會問“你這軟件有多少模塊?”也就不知道還要了解什么了。
但是,模塊是用來處理數據的,數據不能只“窩”在模塊里流動,它要在模塊間暢通無阻地來回流轉!豆腐切開后不能無縫粘結,那么,模塊切開后,總有個重組裝問題,在模塊接合部上,怎么確保數據流的銜接與一致?
這是ERP設計理念是否成立的根本性問題。我們從會計總賬模塊和庫存模塊之間的脫節(jié),已可看到模塊化設計的毛病。姑且不說庫存明細賬是“別人”的,即使ERP只讓財務部自己用,也會有麻煩,那就是:庫存模塊有金額和數量雙重核算,處理業(yè)務后,能向總賬模塊傳送只有金額的記賬憑證;總賬模塊只有粗略的金額核算,完成與庫存有關的賬務處理后,卻不能向庫存模塊傳送既有金額又有數量的數據,分攤到品種上,以保持雙方一致。這就和“單向閥”一樣,導致兩個模塊的數據脫節(jié)。其實,會計本來是從上到下渾然一體的,從總賬到最底級的明細賬一氣呵成,把明細賬加起來就是總賬,永遠也不會出問題。硬要切成總賬和明細賬模塊,再來設法調平,豈不是舍近求遠?
在物流調度上,更加回避不了的問題是:當試圖用“大卸八塊”的模塊來處理暢通無阻的數據流時,必然碰到“模塊為王”還是“數據為王”的問題。ERP顯然是以模塊為中心的,供應商對于模塊功能描述得很細,但在模塊與模塊之間的接合部上,數據如何相互溝通,則完全沒有人提起。
對于軟件系統(tǒng)而言,唯一的評價標準就是用戶的需求。那么用戶要的是什么?不是模塊,而是數據,處于不同職能上的用戶是依靠數據工作的!首先要了解其所處理業(yè)務的當前狀況,例如銷售部要知道當前有多少可供銷售的商品(這也許是倉庫管理員等部門的操作結果);采購部門要知道有多少未完成的銷售訂單,有多少可供銷售的商品,該采購多少(這又是銷售部門和倉庫管理員等部門的操作結果)……其次,所有部門在軟件上所做的操作,會立即改變后續(xù)工作所得到的信息,例如銷售票據一旦開出,接著要開具下一張時,觀察到的可供銷售的商品數已減少了,財務部門知道要準備收款,倉庫管理員知道該出貨了,儲運車隊開始調度車輛……數據在各職能部門間暢通無阻,動態(tài)地交互作用,這才是評價ERP系統(tǒng)是否成功的終極標準。在許多案例中,套裝式的ERP軟件只用上一兩個模塊(如銷售模塊)便宣稱ERP成功上線??墒?,那和傳統(tǒng)的信息孤島軟件又有什么區(qū)別呢?充其量也只是一個模塊的成功,而絕不是ERP的成功。
為了找到答案,筆者曾遍翻某世界最知名的ERP廠商出版的十幾冊英文原版書,發(fā)現書中對每個模塊的介紹都詳盡無遺,而對于ERP是否成功的真正標志,即模塊與模塊之間如何溝通數據、如何使之交互作用、整體聯動起來,幾乎是不著一字,只看到“填表”(fill tables)一詞還算與此有關,具體如何做,卻又語焉不詳。這只有兩種可能,一是設計者自己也不知道;二是事關軟件的超級商業(yè)機密,因此絕口不提。可是,該公司自己又不在現場干活,而是通過咨詢顧問進行推廣的,不交代清楚模塊之間數據如何對流,讓人怎么裝配設置?所以,最可能的答案應是“設計者自己也不知道”。
案例演示
作戰(zhàn)時,友軍的結合部往往是最薄弱的環(huán)節(jié),軟件模塊也是如此。所以,筆者就“哪不開偏提哪壺”,通過一個虛擬的商品流通企業(yè)案例,重點揭露模塊結合部上的問題。
我們假設這個企業(yè)只經營一種商品,買進來以后就賣出去,完全按銷售訂單來組織供應。采用“就地收購”和“訂單購進”兩種供應方式,“就地收購”的過程是由供應商送上門來,暫放倉庫,如果質量檢驗后符合要求,就承付貨款成交,否則退還供應商自行拉回;“訂單購進”則是一般的商業(yè)采購模式。為了便于統(tǒng)一管理,在完成各種有關物流的業(yè)務處理時,也將該業(yè)務登記在表1中,對表中的有關欄目說明如下:
業(yè)務說明:表現各種不同的業(yè)務類型。
對應項目:用于登記與該業(yè)務有關的機構或人員,如銷售合同必有顧客,收貨待驗必有供應商,沒有對應項時不必填寫。
庫存總數:倉庫管理員所實際負責保管的存貨。
自有數:在庫存總數中,所有權屬于會計主體的那一部分存貨(會計后臺監(jiān)控的對象)。
代管:在庫存總數中,屬于為別人代管的那一部分存貨,如供應商送來,尚未通過驗收的存貨,或顧客已領取,但尚未能拉走的存貨等。
可用數:在自有數中,尚未有確定用途的那一部分存貨,本欄合計數即“可用而未用數”。
已用數:在自有數中,已有確定用途的那一部分存貨,本欄合計數即“已用而未提領數”。
未完銷售:表現銷售訂單的簽訂和執(zhí)行情況,本欄合計數即“已簽訂而未完成的銷售數”。
未完采購;表現采購訂單的簽訂和執(zhí)行情況,本欄合計數即“已簽訂而未到貨的采購數”。
在“業(yè)務說明”欄中,各類業(yè)務處理后,在登記表1時,該業(yè)務數據要滿足的約束條件如下。
銷售合同:簽下銷售合同的業(yè)務,因還未執(zhí)行,對“東海超市”的“未完銷售”做加法。
收貨待驗:就地收購的商品,茗香農莊送來,因還未驗收,對“庫存總數”和“代管數”欄做加法。要滿足的約束條件:本次收貨數≤(“未完銷售”當前合計 – “可用數”當前合計 – “未完采購”當前合計)。
承付通知:對就地收購的“茗香農莊”代管商品,驗收無異議后,通知財務付款。雖然財務付款也許還需時日,但已可認為是自己的商品了,所以對“代管數”做減法,對“自有數”和“可用數”做加法。要滿足的約束條件:承付商品數≤“茗香農莊”的“代管”當前合計數。
采購訂單:對東風茶廠發(fā)出采購訂單,對“未完采購”做加法。要滿足的約束條件:本次采購數≤(“未完銷售”當前合計 –“可用數”當前合計 – “未完采購”當前合計)。
采購進庫:對東風茶廠發(fā)出的采購訂單到貨,對“東風茶廠”的“未完采購”做減法,對“庫存總數”、“自有數”和“可用數”做加法。要滿足的約束條件:本次進庫數≤“東風茶廠”的“未完采購”當前合計數。
銷售開單:組織供貨完成,對東海超市開出銷售單,對“可用數”和“未完銷售”欄做減法,對“已用數”做加法。要滿足的約束條件:本次開單數≤“可用數”當前合計數,且本次開單數≤“東海超市”的“未完銷售”當前合計數。
銷售出貨:東海超市提貨,倉庫管理員登記出貨業(yè)務,對“庫存總數”、“自有數”和“已用數”欄做減法。要滿足的約束條件:本次出貨數≤“東海超市”的“已用數”。
從該案例可見,所有部門既是數據需求方,也是數據提供方,某一職能部門的工作均要受到其他部門前期工作結果的約束,而其操作結果也反過來對其他部門產生約束作用,他們相互的信息依賴性很強,數據要在有關職能部門間不定向地流動,想切也切不開。讀者也許不相信,這么一個簡單得不能再簡單的表格,它所表達的,才是用戶對ERP物流管理的真正數據要求。如果各部門都在一起,沒有通信問題,也忽略手工處理速度低的問題,為每種物料設一張表,按以上規(guī)則填寫這個表,是不是已經把物流管起來了,存貨還壓到了最低?內部物流管理是ERP的核心,而其成功運作的唯一標志,就是涉及物流的各部門“整體聯動”地工作,實現最佳調控。達不到這一要求的ERP,都是失敗的。
可以說,ERP極高的失敗率,其實就源于“信息孤島”式的模塊設計,特別是在物流管理領域,設計者將手段(模塊)置于目標(數據)之上,任意切塊,阻斷了數據在各部門間的順暢流動。
Copyright © 2000 - sinada.com.cn All Rights Reserved. 北京正保會計科技有限公司 版權所有
京B2-20200959 京ICP備20012371號-7 出版物經營許可證 京公網安備 11010802044457號
套餐D大額券
¥
去使用