黃 澤

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

0 引言

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

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

1 傳統(tǒng)信息化軟件越來越復雜的原因

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

圖1 傳統(tǒng)軟件數(shù)據(jù)處理模式Fig.1 Traditional software data processing mode

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

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

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

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

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

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

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

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

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

3 簡單的數(shù)據(jù)模擬演示

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

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

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

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

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

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

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

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

3.1.3 列出每項工作的具體數(shù)據(jù)內(nèi)容，確定“關鍵數(shù)據(jù)表”

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

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

表1 “合同簽訂”數(shù)據(jù)內(nèi)容Tab.1 Data content of “contract signing”

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

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

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

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

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

3.2 模擬數(shù)據(jù)運行

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

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

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

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

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

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

3.2.1 合同簽訂

單據(jù)內(nèi)容，見表。

在三個表添加的內(nèi)容，見表6-表8。

表5 “合同簽訂”模擬數(shù)據(jù)內(nèi)容Tab.5 Simulation data content of “contract signing”

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

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

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

表6 在index表中添加的數(shù)據(jù)Tab.6 Data added in index table

表7 在mat表中添加的數(shù)據(jù)Tab.7 Data added in mat table

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

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

SELECT DISTINCT

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

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

`index`.CPId AS `產(chǎn)品編號`,

`index`.CPName AS `產(chǎn)品名稱`,

`index`.Size AS `規(guī)格型號`,

`index`.Unit AS `單位`,

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

FROM

`index`,

mat

WHERE

`index`.WID = mat.MatIndex AND

mat.MatSubId = '1002' AND

`index`.HTId = 'HT0183'

GROUP BY

`index`.CPId

表8 在mon表中添加的數(shù)據(jù)Tab.8 Data added in mon table

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

表9 “產(chǎn)品需求”查詢結果Tab.9 Query results of “product requirements”

3.2.2 采購合同簽訂

根據(jù)簽訂的外銷合同，在國內(nèi)進行采購，可以從多家工廠分別采購。

單據(jù)內(nèi)容。

表10 采購合同模擬數(shù)據(jù)內(nèi)容Tab.10 Purchase contract simulation data content

在三個表中添加內(nèi)容。

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

表12 在mat表中添加的數(shù)據(jù)Tab.12 Data added in mat table

表13 在mon表中添加的數(shù)據(jù)Tab.13 Data added in mon table

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

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

再做一個采購合同。

單據(jù)內(nèi)容。

表15 第二個采購合同模擬數(shù)據(jù)內(nèi)容Tab.15 Simulation data content of the second purchase contract

在三個表中添加數(shù)據(jù)。

表16 在index表中添加的數(shù)據(jù)Tab.16 Data added in index table

表17 在mat表中添加的數(shù)據(jù)Tab.17 Data added in mat table

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

3.2.3 產(chǎn)品入庫

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

表18 在mon表中添加的數(shù)據(jù)Tab.18 Data added in mon table

單據(jù)內(nèi)容，見表19。

在三個表中添加內(nèi)容，見表20-表22。

查看統(tǒng)計結果：

操作到這個環(huán)節(jié)，為了方便查看數(shù)據(jù)的變化，建立一套“企業(yè)綜合報表”，有如下結果，見表23-表 27。

表19 產(chǎn)品入庫模擬數(shù)據(jù)內(nèi)容Tab.19 Product warehousing simulation data content

表20 在index表中添加的數(shù)據(jù)Tab.20 Data added in index table

表21 在mat表中添加的數(shù)據(jù)Tab.21 Data added in mat table

表22 在mon表中添加的數(shù)據(jù)Tab.22 Data added in mon table

表23 合同明細Tab.23 Contract details

表24 采購情況Tab.24 Procurement

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

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

應付款 應收款SELECTSELECT`index`.GYSName AS `生產(chǎn)廠名稱`,`index`.KHName AS `客戶名稱`,`index`.CGHTId AS `采購單號`,`index`.CKNo AS `發(fā)貨單號`,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`生產(chǎn)廠名稱` ASC

表25 產(chǎn)品庫存Tab.25 Product inventory

表26 應付款Tab.26 Accounts payable

表27 應收款Tab.27 Receivables

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

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

表28 第二筆產(chǎn)品入庫模擬數(shù)據(jù)內(nèi)容Tab.28 Second product warehousing simulation data content

三個表添加數(shù)據(jù)：

表29 在index表中添加的數(shù)據(jù)Tab.29 Data added in index table

表30 在mat表中添加的數(shù)據(jù)Tab.30 Data added in mat table

3.2.4 產(chǎn)品出庫

單據(jù)內(nèi)容，見表32。

三個表添加的數(shù)據(jù)，見表33-表35。

表31 在mon表中添加的數(shù)據(jù)Tab.31 Data added in mon table

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

數(shù)據(jù)的變化完全符合邏輯。

表32 “產(chǎn)品出庫”模擬數(shù)據(jù)內(nèi)容Tab.32 Simulation data content of “product delivery”

表33 在index表中添加的數(shù)據(jù)Tab.33 Data added in index table

表34 在mat表中添加的數(shù)據(jù)Tab.34 Data added in mat table

表35 在mon表中添加的數(shù)據(jù)Tab.35 Data added in mon table

表36 合同明細Tab.36 Contract details

表37 采購情況Tab.37 Procurement

表38 產(chǎn)品庫存Tab.38 Product inventory

表39 應付款Tab.39 Accounts payable

表40 應收款Tab.40 Receivables

3.2.5 付款

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

單據(jù)內(nèi)容。

表41 “付款”模擬數(shù)據(jù)內(nèi)容Tab.41 “Payment” simulation data content

三個表添加數(shù)據(jù)：

表42 在index表中添加的數(shù)據(jù)Tab.42 Data added in index table

表43 在mon表中添加的數(shù)據(jù)Tab.43 Data added in mon table

Mat表沒有添加數(shù)據(jù)。

3.2.6 收款

單據(jù)內(nèi)容。

表44 “收款”模擬數(shù)據(jù)內(nèi)容Tab.44 “Collection” simulation data content

三個表添加數(shù)據(jù)。

表45 在index表中添加的數(shù)據(jù)Tab.45 Data added in index table

表46 在mon表中添加的數(shù)據(jù)Tab.46 Data added in mon table

Mat表沒有數(shù)據(jù)添加。

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

表47 合同明細Tab.47 Contract details

表48 采購情況Tab.48 Procurement

表49 產(chǎn)品庫存Tab.49 Product inventory

表50 應付款Tab.50 Accounts payable

表51 應收款Tab.51 Receivables

結果和我們預期的一樣。

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

3.2.7 在已有的基礎上添加新功能和調(diào)整邏輯

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

對邏輯設計表進行修改：

圖8 邏輯設計表調(diào)整Fig.8 Logic design table adjustment

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

對“關鍵數(shù)據(jù)”表做如圖9修改。

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

圖9 關鍵字段表調(diào)整Fig.9 Key field table adjustment

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

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

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

表53 在mon表中原來的數(shù)據(jù)Tab.53 Original data in mon table

表54 在mon表中變化后的數(shù)據(jù)Tab.54 Data changed in mon table

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

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

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

圖10 邏輯設計調(diào)整Fig.10 Logic design adjustment

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

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

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

4 創(chuàng)新算法的意義

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

5 應用實踐

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

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

5.1 電子生產(chǎn)廠的管理特點和難點

（1）基本生產(chǎn)模式是按單生產(chǎn)，生產(chǎn)的組織是按照客戶訂單執(zhí)行，有若干穩(wěn)定客戶長期訂貨；

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

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

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

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

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

5.2 解決方案

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

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

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

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

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

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

5.2.2 以“生產(chǎn)安排”這一比較復雜的環(huán)節(jié)為例，介紹應用的效果

工作流程。

圖14 生產(chǎn)安排工作流程Fig.14 Production scheduling workflow

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

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

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

圖15 生產(chǎn)計劃操作界面Fig.15 Production plan operation interface

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

安排外廠生產(chǎn)2-4工序，如圖17所示。

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

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

圖17 安排外廠生產(chǎn)操作界面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

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

5.3 應用效果

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

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

6 結論

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