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