麻國順
(浙江麥嬌奴服飾有限公司,浙江 溫州 325000)
現今市場上各種信息化軟件不管是業務系統還是財務系統,都是層出不窮,各種價格檔位,中小企業可選擇性很多。選擇一款適合自己的軟件固然重要,但怎樣才是適合自己這很難判斷。這些軟件的功能基本上都大同小異,差別更多的在于軟件公司的知名度,甚至于很多也是抄襲的。即使有些軟件公司總是宣稱自己的軟件功能如何如何強大,但當你購買了以后,總會發現這些功能都是你無法使用或是不需要的,一個信息系統應用的好不好,從根本上說在于用軟件的人而不在于軟件本身。所以本文并不對如何選擇軟件進行研究,而只是就軟件應用方面的標準化問題展開探討。
各行各業都有自己的標準,財務管理同樣如此。近幾年,國家層面也對財務行業發布了很多標準,如會計準則、內部控制、管理會計等方面。本文所探討的主要是同財務管理相關的信息化標準問題。
財政部于2013年12月發布了財政部關于印發《企業會計信息化工作規范》的通知(財會〔2013〕20號),其中也提到,大型企業、企業集團開展會計信息化工作,應當注重整體規劃,統一技術標準、編碼規則和系統參數,實現各系統的有機整合,消除信息孤島。這里其實表述的重點就是解決標準化問題,因為只有各種系統都按要求和公司統籌規劃實現標準化,才有可能在不同系統間建立聯系,以消除信息孤島。
因此,一個企業內的眾多的信息系統,必須要有一套將各系統連接起來的規則和標準,實現數據互通互享。
首先要弄清楚標準什么。任何系統的最終目的都是為了獲取有用的數據,以進行分析統計或報告。而數據是多維的,前端人員在操作過程中形成的數據往往只有一味的金額或數量,或通過操作人員手工錄入,或通過設備感應錄入,而其他維度大多是在后端已經設置完成,前端作選擇而已。當然選擇也很重要,如果選擇錯誤,同樣也會影響數據的有效性。
本文僅就后端設置的標準化進行論述。一個軟件的后端設置有很多,就業務系統而言,如終端渠道信息、客戶信息、顧客信息、供應商信息、商品信息、材料信息等;就財務核算軟件而言,如部門檔案、客戶檔案、供應商檔案、科目檔案等。這些設置最終都會體現在數據的各種維度中來,影響分析決策人員的判斷。
(1)以商品信息為例。很多企業的商品或材料都有幾千上萬種,如果不分類很難想象在后續的工作中如何進行分析決策。各種業務系統自然都有這種功能。如商品信息,系統可能會要求維護商品的各種屬性,就筆者所在企業而言,有品名、款式顏色、款式種類、款式大類、款式小類、款式年份、款式季節等幾十個屬性,問題在于系統將這些屬性都分割開來了,各自維護。而這里面有些屬性之間是有關聯的,如同一品名,它的款式種類、款式大類、款式小類等屬性應該是唯一的。而當系統將屬性獨立維護的時候就出現這樣的一個問題,如商品信息維護人員在維護商品檔案時,A1款商品品名為B1(假設品名為商品的最小屬性),款式種類、款式大類、款式小類分別選擇為C1、D1、E1,而在建A2款商品時,品名同樣為B1,款式種類、款式大類、款式小類卻分別選擇成了C2、D1、E2,最終出現了同一品名不同類別,從而影響分析結果。
(2)如何解決這個問題。筆者認為業務系統對于這些相關的屬性應該有個匯總屬性表,以最小屬性為基礎,組合其他屬性,而每個最小屬性在這匯總屬性表中都是唯一的存在。商品檔案維護人員在維護商品檔案時,只要選擇最小商品屬性,其他相關屬性都會自動匹配過來,不至于出現同一個最小屬性存在多種相關屬性的情況。但可惜的是,在筆者接觸的這些軟件中,沒有一個系統是這么做的。
為了解決這個問題,筆者只好在自己開發的財務管理系統中搭建了這么一個中間檔案表,用來規范業務系統導出來的基礎數據。這樣不僅解決了上述的不唯一問題,還可以根據其中某種屬性來對應財務會計科目,建立業務系統同財務核算系統的對接,實現會計核算憑證自動化處理。
企業內部相關部門在設置相關基礎信息時,往往不考慮財務部門的需求,而只是考慮是否滿足自身需要,這同樣嚴重限制了業務系統同財務核算系統的對接。
仍以商品信息為例。商品信息維護部門在業務系統中維護一些非銷售類商品信息,如易耗物料等信息時,往往很隨意,因為這些商品對于他們后期的分析統計不會有什么影響。而財務往往會根據這些物料的類型分別計入不同的科目進行核算,如辦公用品、廣宣物料、包裝物料、固定資產等科目。
如何解決這種狀況,筆者建議企業財務部門在業務系統搭建之初就要全程介入,特別是在各種基礎信息的設置上,比如上述的商品信息,財務應該提出需求,要求至少有一種屬性是需要匹配財務使用的,讓財務來維護這項信息或將相關標準提供給商品維護人員。只有這樣,財務部門在后續提取數據時才不至于如此被動。
當然,很多企業的問題在于,財務部門自身根本就沒意識到這點。如果有這種意識,相信業務部門還是會配合的,特別是在系統剛引入時。如果等業務系統運行了很長一段時間,積累了大量基礎信息和數據后再要求他們配合難度就會大很多,甚至根本不會配合。所以財務部門介入的時機是很重要的。這種缺陷也是可以通過在財務管理系統中搭建中間表來解決。
基礎信息設置問題解決可以通過建立中間表來解決,但前面提到的同業務屬性相關的信息如單據類型、采購類型、發貨類型、退貨類型等信息是無法通過中間表解決的。因為這些信息在基礎設置時可以標準化,但在業務發生時大多是需要人工根據企業相關文件判斷選擇的,所以實際業務發生過程中會面臨各種問題。
因為不同的業務屬性可能需要做不同的賬務處理,有不同的會計核算要求,或是需要根據業務屬性進行各種分析決策,甚至有的企業會基于不同的業務屬性,針對供應商或客戶有不同的結算政策。財務需要分析企業實際業務可能存在哪些業務類型,各種類型對財務的會計核算和分析有什么區別或有什么影響,以及企業是否根據不同業務屬性針對供應商或客戶有不同的結算政策等。
(5)旅游市場基礎。旅游市場現狀和發展潛力影響地區生態旅游開發。生態旅游產品需要與之對應的市場將游客生態旅游行為轉化為地區經濟效益,良好的旅游市場基礎對地區生態旅游開發具有重要支持和帶動作用。故本研究從旅游市場規模、旅游經濟效益和旅游消費潛力三個維度對生態旅游市場基礎進行評價。
實際業務發生時財務也需要介入。業務屬性的基礎設置是一次性的,所以這時的標準化問題比較容易解決。難就難在實際業務發生時對這些標準的使用。對標準的使用從本質上也是一個標準化問題。在什么情形下選擇哪種類型,企業需要建立一個業務屬性說明文檔,這就是一個標準文件,實際上很多企業沒有這個文件,大多是采用口傳身教。企業不僅需要用這個文件去培訓員工,財務部門也需要用這個文件去監控業務數據操作過程,并且在前端就要介入,而不是等業務流結束了才參與審核,因為業務單據的控制一般都是不可逆的,這時就會顯得很被動。
本文僅就財務核算系統中基礎信息設置的標準化進行探討,如科目檔案、部門檔案、客戶檔案、供應商檔案等,尤其是科目檔案和部門檔案顯得更為重要。如果業務系統和財務系統用的是同一個軟件,如用友、金蝶等軟件都有業務模塊,這方面的困惑就會少很多,因為這種情況下,很多基礎設置都是共用的。而實際情況卻不是如此,大部分中小型企業,業務系統和財務系統分屬不同軟件,而這些軟件的很多規則是不一致的,很難實現業務系統和財務系統的統一,這就需要一個中間系統進行連接,這點在筆者的另一文中已有探討。但財務系統自身的標準化也同樣重要。
(1)財務人員在設置科目檔案時的問題。很多會計人員在搭建會計核算體系時,都沒有好好規劃會計科目。有些把科目級次設的很多,在編制會計分錄選擇會計科目時要一層又一層地展開,效率低下;有些把客戶和供應商都設置成科目,要知道這些軟件都是有客戶和供應商輔助核算功能的;有些甚至于把業務系統中的材料名稱、產品名稱等設置成科目,曾經看到有個企業的會計在軟件中設置了6000多個科目,簡直就是眼花繚亂;有些會計會每年改變或調整會計科目,缺少長遠規劃,導致前后期會計科目不一致。各種情況層出不窮,五花八門。
(2)出現這些問題的原因,一方面是對未來預計不足,只著眼于當前的企業狀況,一切依據現狀進行設計。如有的科目你只有一級,目前是沒什么問題的,但隨著企業發展,未來可能處理新的業務情況,而你的核算需要通過不同的下級科目處理,這個時候想再去調整就很難了,當然也不是不能處理。另一方面就是缺乏管理會計理念,如成本管理、現金流管理、分析決策等,這些理念都會影響著你對科目整個體系的設計。如成本管控方面,你可能需要分清哪些可控成本,哪些是不可控成本,或哪些是固定成本,哪些是變動成本,而這些在一定程度上是可以通過科目設計進行區分的。當你在設計時沒有考慮這些理念,而未來有這個需求時,想調整已經很困難,這個時候可能唯一可做的就是整個科目體系推倒重建,從0開始。還有就是對軟件系統的功能不了解。
(3)科目的級次特別是成本費用科目的級次要合理,筆者往往只設計三級,而末級相對會比較細分。為什么要這樣設計?因為會計核算軟件的科目設置是不具有擴展性的,一經設定就很難改變,如某個四級科目A4,歸類在三級科目A3下,在運用過程中想把A4歸類到B3下或C2下,就很難調整,除非把原有的科目棄用了,重新設置科目。而經常有這種不同歸類需求的時候,這就是災難了。所以筆者干脆就將科目級次減少,然后在筆者自己開發的財務管理系統中搭建一個科目表,在會計核算系統科目設計的基礎上,增加多列自定義的科目分類,分別命名為自定義一、自定義二、自定義三等,然后隨時可以根據需求進行自定義歸類。當然歸類是匯總性質的,所以會計核算系統末級科目的設置才是關鍵所在,太細了賬務處理選擇就比較困難,太粗了歸類匯總也難以判斷及難以進行多樣性的歸類。
部門設置也可以叫責任中心設置。這里以零售企業自營的終端渠道為例。
(1)財務部門一般都會將自營零售終端作為一個部門或責任中心進行核算,在財務核算軟件中設置對應的部門檔案。但財務核算軟件的部門檔案設置的屬性是不具有良好的擴展性的,比如在后續工作中可能需要根據渠道的面積、位置、存活時間、城市級別、分管區域等屬性進行分析決策,但軟件中并不能設置這些屬性或其他可以根據需要隨時自定義的屬性。當然,現在的業務系統中對于渠道的屬性設置往往是比較齊全的,但問題在于,很多企業在維護業務系統中的渠道屬性時,往往并沒有標準或有標準但沒有得到較好執行,維護不全或不規范的現象總有發生,財務沒有辦法有效利用業務系統中的這些設置。
所以筆者的處理就只能在自己開發的財務管理系統中增加這么一張渠道檔案表,除了常規的一些屬性外,還增加一些使用人員可自定義的其他屬性。
(2)解決了屬性設置的問題,還要面臨另一個問題。由于財務系統和業務系統一般都有自身的編碼規則,不同軟件系統之間相同信息的編碼是很難實現一致的,所以這個是可以接受的,但如果財務系統中檔案的名稱、業務系統中對應檔案的名稱設置各不一致,系統間就失去了直接關聯的可能性。另外,特別是有些系統對編碼沒有嚴格的規則控制的時候,當維護人員發生變更的時候,不同的人總是有自己不同的編碼方式。這導致財務核算系統同業務系統根本沒法實現數據關聯,嚴重限制了財務對業務數據的充分利用。
基于這個問題,筆者在自己開發的財務管理系統中的部門檔案表中增加了兩列對照信息,分別為財務核算系統的部門編碼、對應業務系統中的編碼,這樣就可以將財務核算系統和業務系統進行連接,實現數據關聯。
(3)財務核算系統中部門檔案設置的層級以及每層的分類也是一個很重要的事項。其實這里的設置同科目設置的原理是一樣的,解決的思路也基本相同。這里不再詳細探討。
通過前面的探討可以預見,財務系統同企業內其他系統往往是很難直接兼容的。財務想要充分利用其他系統的數據很是困難。這個時候中間系統就起了關鍵作用。利用一個中間系統建立各種標準,牽線搭橋,將財務核算系統和企業內其他系統進行連接,把不同系統的數據都抓取到中間系統中來,并在中間系統里進行分析統計。
當然,對于一些財力雄厚的企業,可能會通過建立財務共享中心,實現這種不同系統間的數據互聯,筆者也一直有這個夢想,希望有一天可以自己親身實踐。但可惜經歷了那么多企業一直沒有這種機會,中間呆過一個企業,也買了SAP系統,可惜因各種原因難以推廣。唯有另辟蹊徑,尋找適合自己也適合企業的一條路子。筆者把這個系統稱之為財務管理系統,至于如何搭建這個系統,在筆者的另一文中已有所探討,本文不再深入。