管理信息系統實施成功三大因素依次為：人、數據、技術，也許有些人不完全認同，但是數據的重要性是大家不可否認的。
1. 數據管理的組織機構的建立
為了更好的進行軟件系統的數據管理，應該從組織機構角度來做考慮，建立單獨的組織機構來管理數據相關工作，或者在實施小組里面專人總負責。
軟件開發商和客戶核心的業務骨干一起制定數據規范，客戶提供符合規范的業務數據，只有符合規范的數據才能進入系統。
2. 數據管理的原則
強調客戶和軟件開發商的2方項目組成員做到“不能有‘我以為’的思想”，一旦有如此思想，很容易陷入閉門造車，項目需求很容易走樣，因為客戶à所有的客戶，也是在‘我以為’。項目組要想做到控制住需求，一定要拋開自己的設想。所以任何一個項目組成員，第一句話告訴他，不要有“我以為”的想法。把’我以為’變成’客戶認為’(好是客戶和軟件提供商一致認為)，這才是重要的。
呵呵，這又回到了項目管理上。我在這里實際上只是想從數據管理這個更具體的角度來闡述問題。
3. 數據入口的單一性
同一數據必須一次、一處進入系統，保證其準確性，及時性和完整性和入口的單一性。管理控制一體化是系統的目的，如果一個數據在多個地方存儲，很容易造成數據的不一致。
4. 數據副本管理/數據版本管理
雖然上面提到了數據存儲的單一性，但是有些時候也需要存儲副本數據。存儲這些副本數據的目的是為了在使用數據副本的地方不受到數據源的變化的影響。
例如：數據1在業務A進入系統，業務B使用到了數據1，但是為了避免在業務B使用了數據1后，業務A又把數據1的修改影響到業務B，那需要業務B在使用數據1時候保存副本。
比如：城市拆遷資源計劃系統(http://www.netsky-tech.com/)的拆遷合同在使用房源業務錄入的房源房屋面積信息時，使用了副本機制，在合同使用房屋面積時候，把面積信息存儲下來，當合同構筑完成時候，如果相應的房屋面積信息發生了變動，用另外的業務來處理這個數據變動的相應處理（比如，使用房源的差價款合同來處理）。
有朋友建議用配置管理系統，把數據版本機制引入了業務數據里面.做過J2EE的項目，都知道很多地方可以通過配置來進行管理。其實這個思想延伸到數據庫模型的設計時候，體現出來了業務數據的配置管理的思想的使用。
我們其實也有是用這個思想，但是主要體現在 在基于數據表級別上用數據級別+歷史編號 來識別有效的數據。1個很簡單的例子：
一個員工的姓名原來 是aa， 后來改委bb，可以通過歷史編號 找到原來 的信息是bb通過數據級別識別現在的有效數據是aa，我們把數據版本控制更多的是采用’數據級別’加’歷史編號’另外還加上了一個’生效日期’， ‘截止日期’這2個時間戳另外，實際軟件系統的歷史業務數據進入系統比較煩，可能需要使用版本管理機制來處理才行得通。
5.建立數據等級制度
軟件項目實施中業務規則經常會陷入一個兩難的境地，如果業務規則加強，很多數據數據達不到規范化的要求，無法入機；如果放寬控制，很多垃圾數據進入了，大家都明白一個道理，對于軟件系統，垃圾數據進去，肯定是垃圾數據出來，統計查詢結果肯定是這樣的。
可以建立數據的等級制度，制定數據進入系統的低要求。達到低要求才能進入系統，比如：
業務A，需要數據a1，數據a2，，數據a3， 數據4。我們可以制定進入系統的關于業務A的條件是必須要有數據a1，a2才可以進入系統（也是低要求），如果提供的業務數據同時有數據a1，數據a2， ，數據a3，那是更高一級的數據（第二級數據），如果業務數據在滿足第二級數據的基礎上，提供了數據4，那是第三級數據。
如果用過J2EE平臺的同行理解起來比較容易，這實際上是JMS基于主題的消息管理思想用于軟件系統一個具體例子而已，這里不過是強調的是用于管理數據的信任等級而已。
其實很多軟件項目開始制定的的數據規范，一般到后來都執行不下去，主要是太理想化了，也許只有到系統真正用起來了，系統數據的信任等級才能上去。所以我覺得應該在系統開始時候把數據分等級，不同的等級，業務給與適當不同的處理，這樣也便于后期的業務進行查詢統計分析或者數據挖掘。
這種思想實際上是將數據可以信任的程度進行分類；而一般的軟件系統是把數據定義為兩類，可以進入系統，不可以進入系統；我在這里設想的是，從數據可以信任的角度出發，分成多種類別，使用了一個小數來描述信任程度，而不是一個二值邏輯變量來描述；這樣從建立軟件系統整體模型的時候，把數據信任管理納入考慮之內，在進一步作業務分析，決策支持或者數據挖掘時候是比較有好處的；當然進一步延伸可能需要從OLTP/OLAP混合建模來考慮，不過真要到那個高度，可能項目范圍擴大了很多，具體怎樣操作，還要看項目具體情形。
