24周年

財稅實務(wù) 高薪就業(yè) 學(xué)歷教育
APP下載
APP下載新用戶掃碼下載
立享專屬優(yōu)惠

安卓版本:8.7.50 蘋果版本:8.7.50

開發(fā)者:北京正保會計科技有限公司

應(yīng)用涉及權(quán)限:查看權(quán)限>

APP隱私政策:查看政策>

HD版本上線:點擊下載>

模塊化:豆腐切開以后

來源: 汪一凡 編輯: 2009/12/13 20:16:39  字體:

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

  模塊成功≠ERP成功

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

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

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

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

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

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

  案例演示

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

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

  

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

  對應(yīng)項目:用于登記與該業(yè)務(wù)有關(guān)的機構(gòu)或人員,如銷售合同必有顧客,收貨待驗必有供應(yīng)商,沒有對應(yīng)項時不必填寫。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

責(zé)任編輯:小奇

實務(wù)學(xué)習(xí)指南

回到頂部
折疊
網(wǎng)站地圖

Copyright © 2000 - m.8riaszlp.cn All Rights Reserved. 北京正保會計科技有限公司 版權(quán)所有

京B2-20200959 京ICP備20012371號-7 出版物經(jīng)營許可證 京公網(wǎng)安備 11010802044457號