數(shù)據(jù)管理質(zhì)量怎樣衡量

俗話講“一波未平，一波又起”，在數(shù)據(jù)倉庫的建設中，往往也是一期工程尚未了結(jié)，二期工程就開始動工了。那么，如何才能避免在一個不曾被證明可用的基礎上搭建更為宏大的后期工程呢？要衡量“數(shù)據(jù)管理”的好壞需要一桿什么樣的“秤”呢？

網(wǎng)界網(wǎng)：數(shù)據(jù)倉庫項目一期接著一期地建，可衡量標準仍然是模糊的?！@是和圈內(nèi)一些朋友交流他們所參與項目時經(jīng)常聽到的一點感觸。

從建設進程上看，金融行業(yè)的經(jīng)營分析系統(tǒng)也是從一期走到二期。一期主要的目標，是做數(shù)據(jù)整合和單一客戶視圖；二期的主要任務則是做分析應用。前者是一種后者的支撐，相當于是基礎設施?？赏黄诓]有被證明是可用的情況下，第二期就因為計劃和各方的壓力而開展起來。事實上，這里存在一個關鍵問題就是，如何度量第一期項目完成的好壞？

不能度量，是因為缺乏明確的項目目標。不能度量，也就無法分工細分。數(shù)據(jù)管理這種項目似乎只能作為項目大鍋飯的一部分，很難作為一個單獨的項目來進行，而且通常還是個吃力不討好的部分。它通常要拿具體的應用來衡量它，比如，用來做哪些報表、哪些主題、哪些專題應用等等，來衡量后臺的數(shù)據(jù)倉庫是否足夠強大。

在很多朋友的項目中，就存在這樣的問題。衡量數(shù)據(jù)整合的效果，只能用單一客戶視圖這項應用來衡量。如果這點做到了，就基本上認同一期成果。即便數(shù)據(jù)整合做得確實有些缺陷，也可以放到二期再慢慢補充。實際上，如果僅僅是為了滿足單一客戶視圖，其實根本沒有必要去建數(shù)據(jù)倉庫。但這樣哪行呢？領導知道了，肯定又不同意，“那不行，數(shù)據(jù)倉庫還是得建，要為日后打基礎嘛"。這真是一件矛盾的事情，而且，一個項目最怕的一點不就是目標不明確嗎？

因此，筆者就有個設想，是否能夠為“數(shù)據(jù)管理”這件事建立一套度量其好壞的參考規(guī)格？此處，我更愿意將數(shù)據(jù)整合擴大一層含義叫做數(shù)據(jù)管理，它的目標是為了讓企業(yè)分散的、凌亂的、異構的數(shù)據(jù)變成一種可管理狀態(tài)，就像要通過ERP、CRM將企業(yè)中資源、客戶變成可管理一樣。后者為了能夠提高資源利用率、客戶服務，前者也是如此，要提高數(shù)據(jù)的利用率，從中挖掘金子。

要達到這種可管理狀態(tài)，數(shù)據(jù)整合只是其中的一步，此外還有數(shù)據(jù)建模、元數(shù)據(jù)、數(shù)據(jù)質(zhì)量等等，而數(shù)據(jù)整合也是一種泛稱，可以是ETL，也可以是EAI、EII。當然，如果完整地考慮數(shù)據(jù)管理，可能還會包含數(shù)據(jù)安全、存儲等方面，暫時那些還不在探討范圍之內(nèi)。

大的行業(yè)做大項目，往往是要建立規(guī)范，其實也是在做建立標準、將目標度量化的嘗試。然而，這確實是個難以平衡的事情，規(guī)定得太細了，基本上這份規(guī)范將僅供參考，因為根本不符合實際項目環(huán)境；定義得太粗放了，又失去規(guī)范的作用，大家還是各自按各自的做法。

例如電信行業(yè)經(jīng)營分析規(guī)范中有個條款是規(guī)定數(shù)據(jù)源接口必須是文件接口的形式。這就是對過程的約束，做出規(guī)范當然有必要，但通過相關條款固定下來之后就基本成為一種強制性的東西。

這使得有些省分公司的項目在通過總部測試時就因為這一條不合格而未通過。其實，就這類規(guī)范本身來講，如果已經(jīng)經(jīng)過證明是一種好方法時，確實可以將其推而廣之。然而，在各項目建設中，總會有人懷疑這樣的約束是否總是起到作用。比如以上面這個文件接口的約束為例，是在所有環(huán)境中都能適用的嗎？事實是，如果省分公司數(shù)據(jù)量沒到一定級別，提供綜合營賬系統(tǒng)和經(jīng)營分析系統(tǒng)的可能就是同一家廠商，這種情況下還要做這種約束未必就是最好的方法了。

此外，這種參考規(guī)格之所以將過程和結(jié)果分開，就是要分而治之。譬如在規(guī)范中，對動態(tài)過程做規(guī)范，最好還是作為指導性的；而對靜態(tài)結(jié)果定義可衡量的標準，可能更加明確一些。