當然，在軟件項目實際操作的時候，可能還會遇到另外一個問題，很可能用戶會亂用這個數據信任程度的概念，我個人的建議是在項目實施中如果可能的話，優先進入信任等級高的數據，然后才是信任程度低的數據；當然也可以從人員來角度作為切入點，信任等級越低的數據，進入系統需要的業務更熟悉的人員來操作錄入，而且經過的業務處理步驟越多。一句話，數據信任程度越低，應該受到的審查/檢察越多。
參考：數據信任等級圖
.gif)
6.數據來源管理
在現實中稍微規模大一點的軟件系統涉及到的組織機構都是比較大的，有很多還可能是松散的組織管理模式。在這類組織機構中，同樣的業務數據可能很多部門都會是數據錄入點和數據分析點，為此可以從數據采集/來源角度來描述數據本身。
從當前項目利益來說，數據來源管理方便數據查詢分類，長期來說可以建立起數據信任等級。
對于數據來源的識別，一般需要有特定信息來記錄數據的來源，特別是一些大型企業當然分支機構較多的公司企業政府，也應該這樣來管理。
事實上，數據來源管理是數據信任管理的進一步延伸，是數據信任管理的前置條件。一個數據，可以是來自于A部門的也可能是來自于B部門的。為了方便統計查詢和數據信任管理的加強，應該記錄下數據的來源地。
具體操方式可以有以下幾種：
1) 數據錄入人員的工作人員編號，知道了數據錄入人員的編號，知道數據的來源地。
當然，實際工作種存在人員調動，替操作（1個人用另外一個人的身份進入系統數錄入），這些都有可能需要考慮到，否則可能造成數據來源管理失效。
2)另外一種方式是直接記錄數據錄入的部門編號。
這種方式弊端是不能記錄下數據的具體操作人員。
其它說明：如果系統中引入了工作流產品，數據來源這部分工作可以由工作流來擔任。具體例子：在現實的軟件系統中可能存在一個主數據庫/數據中心，若干分數據庫/數據中心，系統在每過一定時間進行數據上傳/下載，為了進行數據合并和控制數據的修改，應該每個分數據中心只能處理修改自己的數據，可以查詢總數據中心/其他分數據中心的數據。如果沒有引入數據來源管理（數據屬地管理）和數據版本的控制機制，不知道系統在作數據中心合并會怎樣子？
7.數據項的分類編碼
數據項的分類編碼，實際上是數據項來源管理的一個具體延伸。數據項編碼的目的是更快更好的識別數據代表的業務意思。一個典型的例子是ERP中的BOM表（基本物料清單）.
數據項的分類編碼，不只是在系統模型建立上有指導意義，在進入系統的業務數據的規范化同樣有指導意義。
數據項的業務編碼和系統編碼分離。業務編碼很多時候只是為了識別業務數據的需要，很難保證業務數據的性要求。而且業務編碼可能會發生變動，有些單位的總體規劃從調研到討論制訂、到項目審批通過，再到終實施，常常幾年過去了，需求發生變化，這種編碼規則不發生變動幾乎不可能。2000年我參與的一個企業軟件系統，一個產品編碼規則2個月發生了5次變動。從更長的時間范圍內來說，應該考慮數據產生時期問題，不同時間階段產生的業務數據，使用的業務規則不一樣，數據編碼這個層次很多時候很難識別數據當時的業務環境。
以一個簡單的例子來說明：
業務數據表的primary key系統應該是系統定義的，而數據項的業務編碼只能作為索引或者備用鍵使用，這樣減少了數據業務編碼規則的變動對系統影響減少到更小的程度。
8.算法的版本化
本來我打算在前面的基礎上，再談一下業務流程的管理設置問題，不過，現在工作流思想深入人心，我也跳過了。我打算從數據的核心業務處理，算法處理角度來闡述。
其實在現實中的軟件項目中，大家提到的較多的BPR，工作流這些東西，但是很少提到算法這個單詞。當然，不可否認，很多軟件項目，特別是電子政務/OA的業務主要是體現在流程/文件上，算法這部分比較簡單（當然，我這樣說，有人可能不認可，暫且不爭論它了），沒有必要去強調算法的重要性了。
為了避免垃圾數據進入系統，垃圾數據出來，有必要對數據進行分類管理。正如前面提到的那樣，對于進入系統的數據，進行信任等級劃分，數據來源的分類；但是對于系統出口，為了避免出現垃圾數據，需要在數據處理階段，也要進行分類處理，這里引入了算法的版本化，來適應不同的數據/業務需要。
