基于“二元”分析法的企業信息管理的架構：“三個Table的ERP”

黃 澤

（山東青島嶗山區海爾路數碼科技大廈B-1304 山東脈達信息科技有限公司）

0 引言

企業信息化是計算機應用中的一個重要領域，信息技術在企業管理中的應用對企業管理效率的提高，規范化管理等發揮著重要作用。但在企業管理軟件在企業的應用，特別是在中小企業中的應用卻不盡人意，經過多年的努力業界提供了各種概念和解決方案，成功的案例不多。大多數中小企業還停留在使用Office系列產品，做簡單的文檔和數據處理，僅實現了無紙化辦公的初級要求，目前國內企業面臨轉型壓力[1]，迫切需要管理工具幫助企業提高管理水平，提高工作效率[2]。在中小企業的信息化中，困難主要在于兩點：一是系統太復雜，學習和實施比較困難，費用也比較高；二是系統僵硬，管理內容和模式固定，個性化適應性差，二次開發難度高，實際根源在于系統結構太復雜、龐大，缺乏彈性[3-4]。為此經過多年在甲乙兩方的工作經驗的總結，創新出一種全新模式的數據結構和算法，極大的簡化了數據結構，這樣就很易于系統的配置和修改。在使用這一算法的基礎上設計的企業信息化工具，在實際應用中，可以讓企業以極低的投入建立適合自己企業的信息系統，并且可以伴隨企業的發展，管理的進步不斷調整、修改，作為真正的“企業管理信息化工具”幫助中小企業完成信息化建設。

聲明：題目中“三個Table”是指記錄、統計和計算的核心只要用三個表，如果做成完整的軟件還需其他數據的補充協助；“ERP”是泛指企業管理中對業務數據的管理應用，如ERP、進銷存等，不是嚴格意義的ERP，僅為了便于描述。

1 傳統信息化軟件越來越復雜的原因

傳統管理軟件，不論是進銷存、ERP，還是為行業量身打造的各種管理系統，通常都不外乎遵循：根據“業務數據”產生“表單”，然后經過“數據邏輯處理”保存到對應的“數據庫”中；查看、統計時，根據表的內容設計“查詢統計邏輯”，將結果輸出，如下圖。

圖1 傳統軟件數據處理模式Fig.1 Traditional software data processing mode

這樣的結構，“業務數據”、“邏輯處理”和“數據庫”這三層的關系[5]是一一對應的，或者相互交叉、組合的，那么隨著業務內容的增加，各個環節都會相應增加，業務越復雜，邏輯和數據庫也就越復雜。作為管理軟件的供應商，為使自己的軟件可以有更廣泛的適應性，盡量把可能會用到的管理內容加到系統中，把系統做得越來越龐大，越來越復雜，甚至以此為傲。但這樣的系統對中小企業來說實施的困難就加大了，特別是當有行業個性化需求的時候，需要修改和添加功能，就幾乎是不可能完成的任務。雖然各廠商紛紛推出各自的PaaS系統[6-7]，包裝了許多API、UI元素，“低代碼開發”[8]甚至“0代碼開發”以提高開發的效率，但根基就是那么復雜，中小企業自己很難駕馭，委托二次開發成本也太高，往往是個“坑”。這應該是多年來在中小企業推廣信息化非常艱難的原因之一[9-10]。

如果我們目標在“簡化管理系統”，必須要考慮從根本上改變這個邏輯結構。

2 “二元”分析法的核心思想

上面所說的結構是從數據庫技術的角度去做企業管理，實際上我們應該拋開數據庫的理論結構，從管理應用的角度去思考系統的架構。也就是說當企業產生了一個業務數據，傳統思維只盯住數據，處理的方法就是把數據存儲到對應的數據庫表中，新的思維模式是首先分解這個業務操作的“管理意義”，所謂“管理意義”就是業務操作對整個管理系統的各個方面的影響和作用。例如：做了一個“入庫”的工作，那么產生的“管理意義”就可能是：①產生了若干數量某物料的“庫存”，②產生對某供應商的“應付款”（假設是貨到付款）。設定那些“管理意義”和具體操作無關，企業根據管理流程和管理關注點的不同，設定的“管理影響”項目也可以不同。假如企業又有一項工作是“客供物料入庫”，那么這個業務的“管理意義”只有①產生了若干數量某物料的“庫存”，和上面的入庫一樣，但沒有②產生“應付款”。一項工作可以對整個管理系統有多項影響，產生多個“管理意義”；而對于某項“管理意義”可能來源于不同的工作。這樣，通過對每個業務操作解析出“管理意義”，使具體的操作數據和管理邏輯分開，“松耦合”，這樣設置和修改就相對清晰、容易。

一個完整的企業管理系統是由一個個業務工作有順序、有邏輯、有制約組成的，都是鏈條上的一環，那么如何將們鏈接在一起呢？這里引入了我們古老智慧中的哲學“世間萬物，陰陽互變，有陰即有陽”，事物都有其“兩面性”，也就是說對于每個業務工作產生的每項“管理意義”都要找到它的“另一面”，例如上面的例子中，入庫操作產生了一個“庫存”的“管理意義”，如果把這個設為“＋”，那么假設這個入庫是根據某個采購單來的，可以設定另一個“管理意義”，即“已下單未交貨數量”，這個設為“－”，而對于“下采購單”的這個業務操作，它產生的“管理意義”對于“已下單未交貨數量”就是“＋”，形成下面的關系：

圖2 “二元”關系描述Fig.2 Description of “binary” relationship

這樣，兩項工作就通過一對對“＋”“－”，就像鏈條的每個環節都有兩端那樣，首尾相連，建立起企業管理的完整鏈條。并且相互關系清晰明了，當需要關注某些管理要素的時候查詢統計會非常簡單，例如：想查看一下供應商還有多少沒交貨，合計“已下單未交數量”這個“管理意義”就得出結果了。假設我們考慮每項工作可能會對“物料”和“財務”兩方面產生影響，例如上面“入庫”的操作，在數量上產生庫存，同時在財務方面要產生相應的“應付款”，這樣我們就可以建立如下的模型：

圖3 “二元”算法數據處理模型Fig.3 Data processing model of binary algorithm

對“物料”和“財務”這兩方面的邏輯可以分別設置，在各項工作中可以單獨分解對這兩個方面的影響。這些就是新數據架構的主要核心思想，下面舉個簡單的例子說明一下。

3 簡單的數據模擬演示

基于上面的理論，我們模擬一個簡單的外貿業務系統，業務內容是：和外商簽訂合同，在國內找供應商生產采購，然后出口，賺取差價。將用“三個 Table”，即可完成對全部業務的存儲，數據的統計管理，并且可以方便的擴展和修改調整。

3.1 先做幾項準備工作對管理系統的結構和邏輯進行設計

在進行數據配置之前，先對業務數據進行整理，作為配置的基礎。整理的內容為“一圖二表”，一圖是整理“業務流程圖”，“二表”為“關鍵字段表”和“邏輯關系表”。

3.1.1 理順工作流程，畫出業務流程圖如下。

圖4 模擬企業管理流程圖Fig.4 Simulated enterprise management flow chart

此圖可以看出管理系統所涉及的各項工作及順序、邏輯關系等。

3.1.2 分解各項工作的“管理意義”形成“邏輯關系表”

首先明確幾個概念，上面論述的“管理意義”，簡稱為“科目”，實例中分解每項工作對“物料”和“財務”兩個方面的管理意義，如圖5所示，并且相應進行編號。

3.1.3 列出每項工作的具體數據內容，確定“關鍵數據表”

所謂“關鍵數據”是指在工作數據中，不僅要記錄在本工作的單據中，其內容還要在后續的工作中不斷引用，或者作為條件去查詢的，例如：合同簽訂工作中，具體數據如表1所示。

圖5 各項工作的管理意義和邏輯關系Fig.5 Management significance and logical relationship of various works

表1 “合同簽訂”數據內容Tab.1 Data content of “contract signing”

圖6 各項工作所涉及的關鍵數據列表Fig.6 List of key data involved in each work

其中的“合同號”、“產品編號”、“規格型號”、“單位”和“單價”等數據，在后續的采購、出入庫的工作中都有可能會需要，也就是說“關鍵數據”是在整個管理系統中共同普遍關注的數據。

下面把各項工作的“關鍵數據”羅列在一起，因為有很多工作是在前一個工作的基礎上進行的，例如：入庫工作是根據采購的數據進行入庫，就對上面的數據基礎上只產生“入庫單據號”就可以，很多數據是在各項工作間共用的，所以總的并不多，標識中“*”是在該項工作中產生輸入的數據，“#”為沿用上面工作的數據。

到此為止，對于整個管理系統的邏輯規劃設計就已完成，整個管理系統的邏輯關系和數據內容都體現出來了。根據管理的要求建立了管理邏輯，把每項工作對“物”和“財”兩方面對管理的影響都分解出來，這樣工作的具體數據和邏輯設置是分離的，可以綜合考慮，分別設計，一個工作有多項影響，而邏輯中的某項“管理影響”可以由不同的工作產生數據。

下面就在三個表中按照上面的邏輯設計運行。

3.2 模擬數據運行

這里使用 MySQL數據庫來演示，首先建立三個表，mat，mon，index，表結構如下。

表2 mat表結構Tab.2 mat table structure

三個表的關系是：mat表的 MatIndex字段和mon表的MonIndex字段都和index表的WID字段關聯。

表3 mon表結構Tab.3 mon table structure

表4 index表結構Tab.4 index table structure

在實際應用中mat和mon表不用動，僅根據管理系統的各項工作內容不同添加 index表中的字段即可。下面我們模擬業務運行這6項工作。

3.2.1 合同簽訂

單據內容，見表。

在三個表添加的內容，見表6-表8。

表5 “合同簽訂”模擬數據內容Tab.5 Simulation data content of “contract signing”

解釋：為了簡化數據結構，數據不分“主從”，按明細的記錄數量記錄，所以首先在 index表中產生兩條記錄，并自動生成“WID”號，而對于每條記錄的正負是根據邏輯設計的，如圖7所示。

在“物料”和“財務”都各有一對科目記錄，所以在mat表和mon表中各添加“兩對”四條記錄，并且其中的MatIndex字段和MonIndex字段的值和index表中的WID相關聯對應。

可以看到這樣處理一項工作的涉及邏輯的數據被分離出去了，關鍵數據被集中管理了。

表6 在index表中添加的數據Tab.6 Data added in index table

表7 在mat表中添加的數據Tab.7 Data added in mat table

圖7 “合同簽訂”工作物料科目、財務科目邏輯設置Fig.7 Logical setting of “contract signing” work material account and financial account

這時，如果想查看“有哪些產品需要采購？”可以運行如下SQL語句：

SELECT DISTINCT

`index`.HTId AS `合同號`,

`index`.KHName AS `客戶名稱`,

`index`.CPId AS `產品編號`,

`index`.CPName AS `產品名稱`,

`index`.Size AS `規格型號`,

`index`.Unit AS `單位`,

Sum(mat.MatValue) AS `需求數量`

FROM

`index`,

mat

WHERE

`index`.WID = mat.MatIndex AND

mat.MatSubId = '1002' AND

`index`.HTId = 'HT0183'

GROUP BY

`index`.CPId

表8 在mon表中添加的數據Tab.8 Data added in mon table

其中：查詢條件，合同號HT0183，科目“1002”就是在邏輯設計表中的“采購需求”。運行結果見圖。

表9 “產品需求”查詢結果Tab.9 Query results of “product requirements”

3.2.2 采購合同簽訂

根據簽訂的外銷合同，在國內進行采購，可以從多家工廠分別采購。

單據內容。

表10 采購合同模擬數據內容Tab.10 Purchase contract simulation data content

在三個表中添加內容。

表11 在index表中添加的數據（黃色為新增數據）Tab.11 Data added in index table (yellow is new data)

表12 在mat表中添加的數據Tab.12 Data added in mat table

表13 在mon表中添加的數據Tab.13 Data added in mon table

這時再運行SQL語句BI001，查詢結果。

表14 “產品需求”再查詢結果Tab.14 Re query results of “product requirements”

再做一個采購合同。

單據內容。

表15 第二個采購合同模擬數據內容Tab.15 Simulation data content of the second purchase contract

在三個表中添加數據。

表16 在index表中添加的數據Tab.16 Data added in index table

表17 在mat表中添加的數據Tab.17 Data added in mat table

這個操作就相當于把剩下的“產品需要”都采購了，可以看到在mat表中記錄了科目數量的變化，mon表中財務金額的變化。

3.2.3 產品入庫

根據采購合同做一筆入庫，訂貨800個，實際到貨810個，要按照實際收貨數量付款。

表18 在mon表中添加的數據Tab.18 Data added in mon table

單據內容，見表19。

在三個表中添加內容，見表20-表22。

查看統計結果：

操作到這個環節，為了方便查看數據的變化，建立一套“企業綜合報表”，有如下結果，見表23-表 27。

表19 產品入庫模擬數據內容Tab.19 Product warehousing simulation data content

表20 在index表中添加的數據Tab.20 Data added in index table

表21 在mat表中添加的數據Tab.21 Data added in mat table

表22 在mon表中添加的數據Tab.22 Data added in mon table

表23 合同明細Tab.23 Contract details

表24 采購情況Tab.24 Procurement

數據顯示的結果符合實際工作的進展情況，并且可以達到管理要求。

上面的報表，參考SQL語句：

應付款 應收款SELECTSELECT`index`.GYSName AS `生產廠名稱`,`index`.KHName AS `客戶名稱`,`index`.CGHTId AS `采購單號`,`index`.CKNo AS `發貨單號`,Sum(mon.MonValue) AS `應付款`Sum(mon.MonValue) AS `應收款`FROMFROM`index` ,`index` ,monmon WHEREWHERE`index`.WID = mon.MonIndex AND`index`.WID = mon.MonIndex AND mon.MonSubId = '1005'mon.MonSubId = '1006'GROUP BYGROUP BY`index`.GYSName`index`.CKNo ORDER BY`生產廠名稱` ASC

表25 產品庫存Tab.25 Product inventory

表26 應付款Tab.26 Accounts payable

表27 應收款Tab.27 Receivables

統計查詢也就是圍繞這三個表，變換一下“科目”的相關查詢條件就可以，也很簡單，邏輯清晰。

下面同樣的道理，把第二筆采購合同全部入庫。

表28 第二筆產品入庫模擬數據內容Tab.28 Second product warehousing simulation data content

三個表添加數據：

表29 在index表中添加的數據Tab.29 Data added in index table

表30 在mat表中添加的數據Tab.30 Data added in mat table

3.2.4 產品出庫

單據內容，見表32。

三個表添加的數據，見表33-表35。

表31 在mon表中添加的數據Tab.31 Data added in mon table

這時我們再運行一下建立的綜合報表，見表36-表40。

數據的變化完全符合邏輯。

表32 “產品出庫”模擬數據內容Tab.32 Simulation data content of “product delivery”

表33 在index表中添加的數據Tab.33 Data added in index table

表34 在mat表中添加的數據Tab.34 Data added in mat table

表35 在mon表中添加的數據Tab.35 Data added in mon table

表36 合同明細Tab.36 Contract details

表37 采購情況Tab.37 Procurement

表38 產品庫存Tab.38 Product inventory

表39 應付款Tab.39 Accounts payable

表40 應收款Tab.40 Receivables

3.2.5 付款

做一筆付款操作，為“電子廠2”付款。

單據內容。

表41 “付款”模擬數據內容Tab.41 “Payment” simulation data content

三個表添加數據：

表42 在index表中添加的數據Tab.42 Data added in index table

表43 在mon表中添加的數據Tab.43 Data added in mon table

Mat表沒有添加數據。

3.2.6 收款

單據內容。

表44 “收款”模擬數據內容Tab.44 “Collection” simulation data content

三個表添加數據。

表45 在index表中添加的數據Tab.45 Data added in index table

表46 在mon表中添加的數據Tab.46 Data added in mon table

Mat表沒有數據添加。

這時我們再運行一下建立的綜合報表。

表47 合同明細Tab.47 Contract details

表48 采購情況Tab.48 Procurement

表49 產品庫存Tab.49 Product inventory

表50 應付款Tab.50 Accounts payable

表51 應收款Tab.51 Receivables

結果和我們預期的一樣。

由此可見，如果用常規數據庫結構進行設計恐怕三個表很難完成，采用新的算法，可以增加更多的業務操作內容，還是使用這三個表，并且調整修改非常簡單，對已有的內容影響也不大。

3.2.7 在已有的基礎上添加新功能和調整邏輯

上面的例子只是一個簡單的應用，管理還比較粗放，只是記個賬而已，如果對企業管理要求提高，要求整個系統以“合同”為中心開展各項工作，考核最終合同執行完成后實際的利潤情況，并增加一項工作“其他費用錄入”，把在合同執行過程中的運費、輔料費等都計入成本，我們對已有的結構做如下調整。

對邏輯設計表進行修改：

圖8 邏輯設計表調整Fig.8 Logic design table adjustment

在邏輯設計添加一項新工作“W007-費用錄入”，在“財務”科目里添加兩項“1009-成本預算”、“1010-成本”，在“付款”和“費用錄入”兩項工作時，發生成本，也就是說對某個合同產生實際付款和費用的時候產生成本，統計1010科目即可查看實際成本發生情況。

對“關鍵數據”表做如圖9修改。

也添加了“費用錄入”工作，關鍵數據增加一個“費用名稱”，注意：對于“付款”增加了對“合同號”數據的繼承，也就是說，原來在付款的時候不會考慮“合同號”，只針對供應商就行，總計欠多少，付多少，現在付款要不僅要針對供應商，還有具體到哪個合同，區分款項是給哪個合同付的，這樣才能記錄合同的成本。

圖9 關鍵字段表調整Fig.9 Key field table adjustment

以上是理清思路和邏輯規劃的工作，實際上對于“三個表”的改變僅需要在 index表中加個字段Cost（費用名稱）即可。

表52 index表添加字段后結構Tab.52 Structure of index table after adding fields

這樣在實際運行中，比如原來付款在mon表中記錄的數據將有如下變化：

表53 在mon表中原來的數據Tab.53 Original data in mon table

表54 在mon表中變化后的數據Tab.54 Data changed in mon table

操作“費用錄入”和上面道理一樣不做贅述。這樣處理數據，當合同執行結束，各項款項都處理了，按“合同號”統計1010科目的數據即可得到整個合同的成本了。增加一個工作簡單吧！

分析：在邏輯設計中，添加“成本”時，為了能找到可以“抵扣”的對象，同時加了個“成本預算”科目，如果系統功能要求已經達到了，那么這個科目就沒有統計意義了，但是，再深入考慮一下，在最初“合同簽訂”的時候，和客戶談判確定產品的價格的時候是不是會考慮“根據經驗在國內采購這些產品大概價格是說多少？加上合理的利潤，確定報價”？對邏輯設計做如圖10修改。

添加個“虛”的“總成本”作為抵扣在“合同簽訂”的工作操作時，輸入如表55數據。

圖10 邏輯設計調整Fig.10 Logic design adjustment

表55 “合同簽訂”修改后模擬數據Tab.55 Simulation data after modification of “contract signing”

把“預算金額”加入到“成本預算1009”中，這樣將來合同執行結束后，根據“合同號”統計成本預算，通過合計的正負可知實際經營的結果和預想的差異，如果為正，則說明實際執行的情況比預算好，多賺錢了，如果為負，則說明實際執行情況超出預算了。這樣在管理上如果業務和采購是兩個部門，相應的考核標準也就出來了。并且這樣的改動調整對企業業務沒有什么影響。

這樣看來，這種算法是不是非常符合企業管理的自然思維，很多管理功能和管理想法很輕松的就實現了，并且邏輯關系嚴密、清晰。

4 創新算法的意義

企業信息化的應用歷史從DOS時代的dBase，到Windows時代的FoxPro、MRP、ERP等等一路走來，都是沿著數據記錄、邏輯處理這個路子不斷羅列、擴展而來，新的算法完全顛覆目前所有管理軟件的模式，把管理邏輯作為思維的核心，大大簡化了數據結構，處理企業管理的數據更加“簡單、清晰、合理”，系統設計的思維方式也和管理契合，以此理論為基礎設計開發的管理軟件將更加適合企業應用，很容易二次開發和修改調整。在設計和應用中不僅可以完成企業已有的實際管理工作，還可以很自然地發現管理邏輯中的漏洞和問題，在應用過程中調動管理者的聰明才智，激發靈感，反過來推動企業管理的完善和提高，這才是管理軟件的目標和真正意義所在。

5 應用實踐

我們根據上述的算法原理，開發了“脈達M3”軟件系統，其核心數據架構依照上面介紹的原理，只不過進一步完善輔助的各項配置數據和功能，并形成配置工具，可以方便地配置出“二元”分析所得到的結果，下面以在某電子廠應用為例，介紹這個理論在實際應用中的效果。

某電子廠的管理是典型的制造業小型企業，產品主要是生產小型變壓器、電感等線圈纏繞類電子零件，業務的操作模式涵蓋了小企業運營中的許多問題，該企業也嘗試使用國內某著名管理軟件供應商的產品，但不能完全滿足企業的某些業務要求，我們使用 M3系統為其配置出符合工作要求的業務管理系統，特此總結其特點和解決方案。

5.1 電子生產廠的管理特點和難點

（1）基本生產模式是按單生產，生產的組織是按照客戶訂單執行，有若干穩定客戶長期訂貨；

（2）以本廠加工為主，有部分外加工，外加工情況復雜，可以是某部分工序委托外加工，并且如果工期緊張還可能中途轉移部分加工任務回廠或委托其他企業生產，這樣會產生加工費的變化和余料結算等問題。

（3）原料采購付款對于銅線及其同類原料的價格在當月結算時才能根據交易市場銅牌價來計算應付款；

（4）對于常用低值易耗品常備在車間，例如：焊錫、助焊劑和漆等，通常整包裝發給車間，逐漸使用，對于用量的控制有難度；

（5）收付款時由于目前的經濟問題，相互間有使用“承兌”支付，由于承兌匯票額度固定，和應付款項會有差額，要由業務來往逐漸相互抵扣彌補。

因此，雖然企業不大，但業務并不簡單，還有一些“不規范” 的業務操作，但確是實際工作存在的情況，要有相應合理、合乎邏輯的處理，不能忽視。

5.2 解決方案

用戶做好“一圖二表”的設計，就可以使用配置工具搭建出業務系統，并且由于數據結構簡單，“脈達M3”采用“人機對話”的模式，在“機器人”的提示下對話，就可以完成所有業務數據的錄入、查詢等工作，并且手機可以同樣操作，可以隨時隨地進行數據操作。

圖11 “脈達M3”操作界面Fig.11 “MEDA m3” operation interface

5.2.1 設計工作流程圖和用“二元”分析法進行邏輯設計

根據企業管理的需求，我們設計了28項工作，每項工作的邏輯關系用一對對“+”、“-”標識出邏輯關系，進行對物料和財務邏輯的設計，由于表的數據很多，表很長，圖中僅展示局部，示意說明設計的方法。

圖12 電子廠業務管理流程圖Fig.12 Business management flow chart of Electronic Factory

圖13 電子廠“二元”分析表局部Fig.13 Part of “binary” analysis table of Electronic Factory

5.2.2 以“生產安排”這一比較復雜的環節為例，介紹應用的效果

工作流程。

圖14 生產安排工作流程Fig.14 Production scheduling workflow

（1）根據銷售合同首先對每個產品分別做“生產計劃”，可以根據產品交貨的需求分多個批次下達生產計劃。

完成此操作后，系統后臺的邏輯配置做如下處理：①根據計劃生產的數量和 BOM 計算出物料的需求；②根據各工序的在制品和成品生成生產的需求。

（2）“生產安排”是對“生產計劃”所產生的生產需求進行安排，確定由哪些工廠生產哪些工序和加工數量。

圖15 生產計劃操作界面Fig.15 Production plan operation interface

例如：安排本廠生產1,5工序，如圖16所示。

安排外廠生產2-4工序，如圖17所示。

（3）“物料安排”分“本廠生產物料安排”和“外加工物料安排”兩種操作，因為使用物料略有不同，有些消耗品計入加工費。

圖16 安排本廠生產操作界面Fig.16 Arrange the production operation interface of the factory

圖17 安排外廠生產操作界面Fig.17 Arrange the production operation interface of other factories

圖18 本廠物料安排操作界面Fig.18 Operation interface of material arrangement in the plant

圖19 外廠物料安排操作界面Fig.19 Operation interface of material arrangement in other factories

經過上述操作完成以下工作：①合同整體的物料需求；②生產計劃落實到生產單位；③根據生產的安排對應的物料需求。使用很簡單的配置，即可以配置比較復雜的數據關系。

5.3 應用效果

基于上述理論設計的“脈達M3”系統完全可以滿足比較復雜的管理內容，可以從零開始，配置出操作簡單，和實際工作比較貼近的操作模式，完成企業管理所涉及的各項業務數據和管理邏輯。

由于邏輯設計和業務數據錄入是剝離開的，即先建立邏輯結構作為“骨架”，業務的數據操作把對應的數據添加到邏輯的各個環節。所以配置時可以跳出傳統的數據模式，有更高的自由度和靈活性，局部的調整也不影響大局，對于同一工作環節，可以對數據有多種處理模式以應對各種實際情況。

6 結論

在企業信息化中，本文所提出的數據模式，可以解決在企業管理中各種業務操作的大部分數據問題，并且由于結構非常簡單、邏輯清晰，也易于設計和修改，思維模式也符合自然的管理思維模式和習慣，這種應用模式對中小企業來說，由于企業管理個性化強，管理模式自由、靈活，采用這種設計方法，可以快速搭建，并且可以伴隨企業的發展、管理的進步不斷修改完善，適合在企業推廣應用。