項目管理手記(五)
DRP項目中的數據治理
由於我本人的項目經驗在DRP項目中會比較多一些，而且所談及的問題也是在DRP項目中碰到的，當然，也許我說的這個問題不只只是在DRP項目中，包括像ERP、PDM、KM等項目中都會碰上，但我還是會結合DRP項目中的實際問題來說。同時，由於本人所在的角度是甲方的角度，因此，DRP項目的週期對於甲方來說不只只是項目調研、實施、培訓，還會包括整個DRP系統的應用、部署、維護直到系統結束使用的DRP系統的整個使用週期。
DRP項目進行到後期，一般的企業都會擔心一個問題“顧問走了之後，我們怎麼辦？”。因爲如果實施顧問在現場的話，感覺都不會出什麼問題，就算有問題，顧問也解決掉了。但一旦顧問離場，DRP系統交由企業的IT部門負責運行與維護的時候，感覺問題就出的比較多了。這些問題可能會包括系統故障增多，系統運行速度減慢，軟件需求得不到響應，數據不準等。也因爲這些原因業務部門也在應用了一段時間之後感覺系統不好用了，特別是數據不準的情況經常出現，使得報表也不準了，久而久之，業務部門感覺DRP系統的價值也越來越低了，而這樣造成的直接後果就是DRP系統的使用效果打折，經常會聽到業務部門在抱怨：“這是什麼破系統嘛，出來的數據都不準!”，把數據問題與DRP系統邏輯問題相混淆，從而有可能對DRP系統本身引發了懷疑，導致DRP系統的使用週期因爲數據不準而大大縮短。
“數據事故”引發的數據治理思考
套用一句老話：“ERP是三分軟件、七分實施、十分努力、十二分數據、百分百的領導支持”。其實筆者一直在實施DRP項目的過程中，都有碰到多或多或少的數據問題，但應該都是小問題，所影響的範圍也不大，或者通過DRP系統的一些異常處理功能也就能夠解決的，如：退貨單出現的退貨價格不準確的問題，只要對這張單據進行廢除重做就好了，直到筆者碰到兩次重大的“數據事故”，纔對DRP項目的數據治理工作引發了重視與思考。
第一件事情是由於產品中心對新產品定價錯誤引發的“數據事故”。一直以來，新產品的定價是由產品中心會同財務、銷售、計劃等部門一起制定的，而且制定的是產品的零售價，然後根據零售價的折率分別倒推定製分銷價、出廠價、採購價，而採購價也是一個基準價，也就是說，產品的採購必須低於這個價格，否則的話公司是不會批准對這款產品進行投產的。在年度某季度新產品定價時，公司各部門定製出了當季產品的各種價格，並已經在系統中進行實施，但隨之而來的是，發現在市場對於當季產品的價格反映是偏高，而且代理商也認爲當季產品的分銷價格(即代理商進貨價)太高，所以公司決定對該款產品進行重新定價。隨之而來的就是要求DRP系統中對所有業務環節中的價格進行調整，包括對已經配送到分公司、代理商的產品進行重新調價，對已經配送到直營店，在倉庫中未銷售的產品進行價格調整。這一次的調整由於影響極大，導致公司各業務部門不得不集中人馬加班對數據進行調整，而且調整結束之後，在下月的系統過賬中發現財務報表總是有些出入，才發現數據調整有問題，有些調過來了，有些沒有調整過來，有些調整的時候產品已經銷售出去了，有的產品是退貨的，但成本卻沒有改過來，總之是亂的一團麻，使的該月的財務報表不得不在財務部門的要求下，各業務部門簽字覈定是由於操作不當引起的數據統計問題。本次問題其實是一個業務規範性的問題，或者是系統強壯型問題，如果業務夠規範，不會出現這種在產品進行銷售時更改產品成本的問題，或者系統足夠強壯，能夠對數據變更做出及時處理，這次事故應該也是能夠避免的。
第二件事是由於分公司內部管理、控制不到位及流程缺失導致的“數據事故”。記得當時還在外面開會，被財務總監電話催回公司，說是公司領導要求我今天準備一下，明天去華中大區出差，因爲當地分公司的本月的財務、系統數據都有嚴重問題，估計賬實不符情況嚴重，需要過去核查一下問題到底出在哪裏。第二天，當公司的財務、計劃、IT三部門人員到達華中大區所在地時，開始安排了對本大區所有的庫存盤點的工作，首先是對直營店進行盤點，全部由總部人員進行監督，經過五個晚上的盤點之後，再用了四天時間對大區的庫房進行盤點，發現：直營店的手工賬務與DRP系統中的數據不符情況嚴重，而直營店的手工賬務與實際庫存情況相差無幾，直營店也較好地執行了失貨賠償制度。而DRP系統中的數據與實際庫存嚴重不符的原因在於：大區的倉庫管理人員、數據員都沒有及時將直營店的退貨、銷售、調撥單據進行處理，以致直營店數據失真；同時對大區的庫存盤點時發現：大區的庫存結構不合理，庫存過大，直營店的過季產品處理不及時，數據員沒有對倉庫數據進行及時分析及利用。同時，大區的財務人員也沒有根據DRP系統中的數據進行財務數據覈對，以至於倉庫、數據、財務的工作脫節，形成了大區庫房管理工作出現了失控。這次事故經過審覈之後，上報到公司領導，下定決心對相關責任人進行了處罰，而也是在這次“數據事故”之後引發了筆者對於如何進行DRP系統“數據治理”的思考。
數據治理的理論及方法
項目小組總結之後，通過查找相關資料發現：數據治理其實是一種體系，是一個關注於信息系統執行層面的體系，這一體系的目的是整合IT與業務部門的知識和意見，通過一個類似於監督委員會或項目小組的虛擬組織對企業的信息化建設進行全方位的監管，這一組織的基礎是企業高層的授權和業務部門與IT部門的建設性合作。從範圍來講，數據治理涵蓋了從前端事務處理系統，後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
1. 發現：即發現問題和差異（Issues & Gaps），這是監管的基本職能。我們一定要在萌芽階段發現問題和差異，將其扼殺在苗頭。那麼如何去發現呢？
對於待建或在建的系統，要建立專家審覈制度，所謂專家包括技術專家和業務專家，如果本組織不具備條件則可以邀請第三方的顧問來參與系統數據的架構和設計決策，但根本原則是任何專家必須是相關領域的專業人士。
對於已建成使用的系統，則關鍵是IT的日常運維工作的規範化，主要包括規範的問題管理（Trouble Management），週期性審計(Periodic Review)。前者是爲了文檔化各種系統問題和缺陷，以及相應的IT判斷和響應；後者是爲了及時對系統的問題和缺陷做出歸納總結，找出規律而從根本上解決問題。
2. 監督：即持續的保持對業務數據健康狀況的跟蹤。監督主要通過週期性的數據分析來完成，市場上也有很多自動化的工具可以幫助您方便的對數據的健康狀況進行分析。與發現所不同的是，監督是主動的去發掘問題，而且在發現問題後立即採取行動去修正它。
3. 控制：即掌握信息系統建設的決策權。任何信息系統的建設、更新升級、大型變更都必須通過數據治理項目小組的審批，極端情況下甚至可以考慮任何數據變更都必須審批。集中化的控制的好處是，首先可以集中技術和業務相關領域的專家的意見，其次可以限制執行層面的IT人員和業務人員的隨意性、不嚴謹性，再次向監管層提供了從全局和長遠的角度看系統的機會。
4. 交流：即溝通，是跨部門的跨領域的溝通。對傳統IT的最大挑戰就是跨組織跨領域的溝通交流，而數據治理委員會這樣一個跨越了IT部門和業務部門的虛擬組織，通過建立例行的交流機制，保證了信息在整個組織範圍內的透明，這種透明性保證了所有參與者的步調一致的，保證了業務數據的一致性。交流滲透在前面所述的四點數據治理活動中，是它們成功的保障。
5. 整合：這是我們的目標同時也是解決之道，主要抓住三個方面的整合——信息的整合，資源的整合，能力的整合。通過信息的整合把分散的業務數據整合到一個一致的沒有歧義的體系中來；通過資源的整合把企業IT資源集中調配；通過能力的整合，將平臺的運算能力，業務數據處理能力集中管理，建立一種集中服務的模式，即提高了硬件利用率、人員工作效率又利於IT對各業務部門服務的成本覈算。
“數據事故”分析
爲了解決數據事故問題，筆者協調財務、計劃、銷售、IT等部門成立了專門的“數據治理”項目小組。數據事故，應該是由於數據的素質低劣造成的，根據調查機構Gartner稱，《財富》一千家大型企業所持有的數據，有超過四分一是不準確、不完整或重複的，並預期有四分之三的大型企業直到2010年前也不會或難以改善內部數據的素質。其實沒有一家企業不受數據素質問題困擾，但就算有公司意識到問題所在，也常常會低估問題的嚴重性。何況，數據素質會受多個因素影響而變化。因此，要應付這種挑戰，一次性的行動難以奏效，企業務必持之以恆，甚至採取能改寫企業文化的行動纔會有效。
Gartner研究顯示，良莠不齊的客戶數據可造成重大損失，包括流失客戶，以及由處理直銷郵件不善和錯過銷售機會所造成的浪費等。現時很多企業亦發現劣質數據不單打擊銷售及市場推廣，更會波及最具策略性的業務活動。後勤部門的運作，例如制定預算、生產及分銷也會受到影響。
解決劣質數據問題不只只是一個IT的問題。雖然IT有助將之改善，但企業管理纔是關鍵所在，例如企業文化對數據素質就有很大的影響力。
數據治理，需要對數據的素質提出一個定義，筆者認爲數據素質涵蓋以下多方面：
ü 存在 (即企業到底有沒有某一項數據)
ü 合法性 (即該項數據的數值是否符合一個可接受的範圍)
ü 一貫性 (例如同一項數據不論儲存在哪一個地點都有同一數值)
ü 整全性 (數據元素與不同數據集之間關係的完整程度)
ü 準確性 (該項數據是否能夠描述它應表達的東西)
ü 關聯性 (該項數據能否恰當地支援業務宗旨)
ü 時間性 (即該項數據是否能夠及時地被反應出來)
針對以上數據的素質，再結合DRP系統中的相關模塊，對DRP系統中數據問題按模塊分別分析。該分析表格如下：
|
| 採購 | 訂貨 | 直營 | 門店 | 價格 | 倉儲物流 | |
| 存在 | Y | Y | Y | Y | Y | Y | Y |
| 合法性 | Y | Y | Y | Y | Y | Y | Y |
| 一貫性 | Y | Y | Y | N | N | N | Y |
| 整全性 | N | Y | Y | Y | N | Y | Y |
| 準確性 | N | N | N | N | N | N | N |
| 關聯性 | Y | Y | Y | Y | Y | N | N |
| 時間性 | N | Y | N | N | N | N | N |
以上各模塊中，達到相應的數據素質目標即爲Y，否則爲N。經過對DRP系統中的各個模塊的數據素質調查發現：數據治理主要針對的是數據的準確性、時間性、關聯性。進一步對數據事故的原因分析，發現數據出問題往往是因爲對數據的應用不夠充分。比如物流配送，根據銷售和庫存信息來做，首先銷售的信息，每天系統裏面的銷售信息和銀行回款對比，有沒有差異，沒有差異就是對的。第二，配送是根據系統去配。慢慢的精細化，以前可能是粗放的，現在是一個環節套一個環節，根據這個系統來做，慢慢數據就會越來越準確。百分之百的準確不可能，當然也沒有必要，因爲隨便一個環節都有可能出現串碼。
但如果業務部門發現DRP系統不管用，但DRP使用者就會用自己祕密地使用自己“更方便更可靠的工作流程/做法”。而管理層認爲既然沒有發生什麼不妥，也就睜一隻眼，閉一隻眼。其實，任何繞道DRP系統的工作流程/做法都會產生DRP數據流之外的“數據暗流”。這種“數據暗流”會削弱企業對流程的控制，損害企業對流程的管理和進一步優化，自然DRP系統的數據準確性就更差了。那麼，我們又怎樣保證及時數據更新和避免繞道DRP的祕密的“更方便更可靠的工作流程/做法”呢?解決方案原則上很簡單：持續提高數據準確率，定期維護訂單修訂等系統參數，以確保DRP產生的數據流與實際運作相符，通過基於DRP的工作流程的改進，禁止任何繞道DRP的行爲。
同時，借鑑了業內同行的“數據事故”分析方法，可以得到如下的因果圖：
針對上述發現的各種原因，經過進一步的統計與分析，發現主要的問題在審覈流程缺失，KPI指標設定不完善、考覈與處罰機制沒有執行、指定時間內的數據不到位、業務不熟悉、操作不當上。相反，由於系統原因造成的DRP數據錯誤很少。而像流程原因導致數據錯誤出現的次數只佔20%，但由於流程原因出現的數據錯誤影響程度最大。而像操作不當、指定時間內的數據不到位的情況出現較頻繁，但對數據錯誤的影響有限。
數據治理方案
採用上述的數據治理理論，在經過“數據事故”的教訓之後，發現上述數據問題，分別針對時間因素、流程、數據基礎、考覈機制、人員、系統制定數據治理方案，並強調方案的執行、監督、控制職能，加強各業務人員溝通，達到數據治理的目的。
考覈機制：數據治理的問題其實也是企業管理的問題，而出現問題往往是沒有一個比較好的考覈與激勵機制。在數據事故當中，出了問題之後，IT人員急着去查找原因，財務部門則因爲數據報表出不來而乾着急，而往往是事故責任部門往往是數據生產部門，而不是數據消費部門。所以，沒有好的考覈機制，往往事故在出現了之後無據可依地進行處罰，導致員工情緒極大。因此，我們定製瞭如下考覈辦法：每月結束，涉及到DRP系統中數據操作的，出現錯誤次數在5次(含5次)以上的，每次罰款10元，充入公司獎金池；如果每月操作零錯誤的，則從獎金池內獎勵30元；各部門的年度KPI指標中加入DRP系統數據操作正確率，並給予一定的權重，此舉目的就是爲了能夠使各業務部門經理引起對DRP系統數據操作正確性的重視。
人員：人員責任心不強的問題，可以由前面的考覈機制來加強，而且由於數據操作涉及到部門的績效，因此，各業務部門經理也會加強在這方面的監督；對於操作不當，業務不熟悉的情況，可以歸結爲培訓不夠。對於培訓我們分爲兩大塊：一是新員工培訓，這包括老員工調職到新崗位，新員工如果需要操作DRP系統，必須經過IT部的上崗培訓方可開設DRP系統賬號，否則的話，將無權對DRP系統進行操作；還有就是專場培訓，這也有兩類，一類是專門的計算機基礎教育培訓，這裏會包括一些計算機基礎操作，基本故障處理；另一類是公司業務流程培訓，針對各個不同崗位的人員，將公司的業務流程整合起來講，讓各業務人員知道自己上下游的業務流程是什麼？如果有異常如何處理等，同時培訓由人力資源部培訓組與IT部共同負責，所有培訓考勤、反饋、考覈情況都記入員工培訓檔案，講師則由IT部門、業務部門經理分別承擔；如果是針對各業務經理的培訓，也會請外部的流程、IT專家來擔任。
系統：系統的問題，主要通過兩方面控制：一是加強測試，所有的系統升級都必須經過公司內部的程序員測試，撰寫測試報告，經由IT經理審批之後方可將升級包更新到DRP系統中去，如果由於升級原因造成系統邏輯問題造成的數據錯誤，必須由程序員與IT經理分別承擔責任，根據每次事故的問題嚴重性，每次罰款30—300不等，同時IT部門的KPI指標中也加入系統數據事故的次數進行考覈。二是對於關鍵服務器、網絡設備的突然當機等情況的處理，這些方案可以根據IT部門的原有處置與考覈機制進行。
數據基礎：基礎數據質量差，這就是對數據生產部門提出需求，必須控制數據質量，完善公司數據規格說明，對於必須填寫的數據，由IT部門定期出具數據質量審計報告，對數據生產部門進行考覈。對於數據錄入準確率低的問題，一是採用條碼、掃描等技術手段來加強數據質量，二是通過加強人員責任心來保證，三則是通過數據審覈，下游業務流程一定要加強對數據的審覈與比對，特別是在分公司，由財務、倉管、數據員三方進行數據確認，以保證數據與業務的同步。
流程：物流是最頭痛的問題，也是處理起來最難的問題，其實關於業務流程管理(BPM)是一個很大的話題，在這裏呢，只能說是，根據企業實際情況，一點點的改進，因爲流程改進是一個傷筋動骨的事情，包括：原有流程是合適企業應用的，但現在不合適了怎麼辦？原來的流程是由某個部門負責的，現在職能要細化，要分開怎麼辦？所以在這裏就不再鋪開來講，但以後有機會進一步進行論述。
時間因素：時間因素，主要在於企業的動作效率，也是對於員工的一個考覈指標，這方面沒有太大的難度，我們主要也是將時間作爲數據生產部門的一個指標來考覈，如：計劃部門必須在訂貨單的2小時之內將訂貨單貨配發出去；專賣店如果有DRP系統，必須在當天將銷售數據傳回，如果沒有DRP系統，則傳真數據必須在當天傳回，當地辦事處必須在第二天上午11：00之前將銷售數據做到DRP系統中；客服部必須在12小時內將客戶數據錄入到DRP系統中，對於客戶的禮品申請，必須在兩個工作日內處理完畢，並給客戶回覆等。
上述所有的針對問題的解決方案都離不開執行、監督、控制與交流。在這幾個環節當中，IT部門與行政部門爲主要的執行主體，IT部門負責對DRP系統中的數據異常或每月數據質量出具報告，行政部門則根據IT部門的報告和數據質量方面的制度，給業務部門的KPI指標進行評定，也針對操作人員進行具體的獎罰；同時在培訓這一塊，由人力資源部門與IT部門負責完成。
而IT部門的系統故障及錯誤等問題，則落實到財務部與行政部具體負責進行考覈，這也就是一個監督機制，IT部門作爲DRP系統的管理者，也是要被各個業務部門進行監督的。
而由於涉及到各個業務部門的各個業務環節，特別在加入了績效考覈之後，會引起業務部門對IT部門的敵視，甚至是對DRP系統的敵視，因此，所有策略的實施都需要IT經理與數據治理項目小組的負責人加強溝通。特別是要注意循序漸進，切忌要求一步到位，否則的話引起業務部門的不滿與反彈，有可能事情會變的更糟糕。
項目管理手記(五)
DRP項目中的數據治理
由於我本人的項目經驗在DRP項目中會比較多一些，而且所談及的問題也是在DRP項目中碰到的，當然，也許我說的這個問題不只只是在DRP項目中，包括像ERP、PDM、KM等項目中都會碰上，但我還是會結合DRP項目中的實際問題來說。同時，由於本人所在的角度是甲方的角度，因此，DRP項目的週期對於甲方來說不只只是項目調研、實施、培訓，還會包括整個DRP系統的應用、部署、維護直到系統結束使用的DRP系統的整個使用週期。
DRP項目進行到後期，一般的企業都會擔心一個問題“顧問走了之後，我們怎麼辦？”。因爲如果實施顧問在現場的話，感覺都不會出什麼問題，就算有問題，顧問也解決掉了。但一旦顧問離場，DRP系統交由企業的IT部門負責運行與維護的時候，感覺問題就出的比較多了。這些問題可能會包括系統故障增多，系統運行速度減慢，軟件需求得不到響應，數據不準等。也因爲這些原因業務部門也在應用了一段時間之後感覺系統不好用了，特別是數據不準的情況經常出現，使得報表也不準了，久而久之，業務部門感覺DRP系統的價值也越來越低了，而這樣造成的直接後果就是DRP系統的使用效果打折，經常會聽到業務部門在抱怨：“這是什麼破系統嘛，出來的數據都不準!”，把數據問題與DRP系統邏輯問題相混淆，從而有可能對DRP系統本身引發了懷疑，導致DRP系統的使用週期因爲數據不準而大大縮短。
“數據事故”引發的數據治理思考
套用一句老話：“ERP是三分軟件、七分實施、十分努力、十二分數據、百分百的領導支持”。其實筆者一直在實施DRP項目的過程中，都有碰到多或多或少的數據問題，但應該都是小問題，所影響的範圍也不大，或者通過DRP系統的一些異常處理功能也就能夠解決的，如：退貨單出現的退貨價格不準確的問題，只要對這張單據進行廢除重做就好了，直到筆者碰到兩次重大的“數據事故”，纔對DRP項目的數據治理工作引發了重視與思考。
第一件事情是由於產品中心對新產品定價錯誤引發的“數據事故”。一直以來，新產品的定價是由產品中心會同財務、銷售、計劃等部門一起制定的，而且制定的是產品的零售價，然後根據零售價的折率分別倒推定製分銷價、出廠價、採購價，而採購價也是一個基準價，也就是說，產品的採購必須低於這個價格，否則的話公司是不會批准對這款產品進行投產的。在年度某季度新產品定價時，公司各部門定製出了當季產品的各種價格，並已經在系統中進行實施，但隨之而來的是，發現在市場對於當季產品的價格反映是偏高，而且代理商也認爲當季產品的分銷價格(即代理商進貨價)太高，所以公司決定對該款產品進行重新定價。隨之而來的就是要求DRP系統中對所有業務環節中的價格進行調整，包括對已經配送到分公司、代理商的產品進行重新調價，對已經配送到直營店，在倉庫中未銷售的產品進行價格調整。這一次的調整由於影響極大，導致公司各業務部門不得不集中人馬加班對數據進行調整，而且調整結束之後，在下月的系統過賬中發現財務報表總是有些出入，才發現數據調整有問題，有些調過來了，有些沒有調整過來，有些調整的時候產品已經銷售出去了，有的產品是退貨的，但成本卻沒有改過來，總之是亂的一團麻，使的該月的財務報表不得不在財務部門的要求下，各業務部門簽字覈定是由於操作不當引起的數據統計問題。本次問題其實是一個業務規範性的問題，或者是系統強壯型問題，如果業務夠規範，不會出現這種在產品進行銷售時更改產品成本的問題，或者系統足夠強壯，能夠對數據變更做出及時處理，這次事故應該也是能夠避免的。
第二件事是由於分公司內部管理、控制不到位及流程缺失導致的“數據事故”。記得當時還在外面開會，被財務總監電話催回公司，說是公司領導要求我今天準備一下，明天去華中大區出差，因爲當地分公司的本月的財務、系統數據都有嚴重問題，估計賬實不符情況嚴重，需要過去核查一下問題到底出在哪裏。第二天，當公司的財務、計劃、IT三部門人員到達華中大區所在地時，開始安排了對本大區所有的庫存盤點的工作，首先是對直營店進行盤點，全部由總部人員進行監督，經過五個晚上的盤點之後，再用了四天時間對大區的庫房進行盤點，發現：直營店的手工賬務與DRP系統中的數據不符情況嚴重，而直營店的手工賬務與實際庫存情況相差無幾，直營店也較好地執行了失貨賠償制度。而DRP系統中的數據與實際庫存嚴重不符的原因在於：大區的倉庫管理人員、數據員都沒有及時將直營店的退貨、銷售、調撥單據進行處理，以致直營店數據失真；同時對大區的庫存盤點時發現：大區的庫存結構不合理，庫存過大，直營店的過季產品處理不及時，數據員沒有對倉庫數據進行及時分析及利用。同時，大區的財務人員也沒有根據DRP系統中的數據進行財務數據覈對，以至於倉庫、數據、財務的工作脫節，形成了大區庫房管理工作出現了失控。這次事故經過審覈之後，上報到公司領導，下定決心對相關責任人進行了處罰，而也是在這次“數據事故”之後引發了筆者對於如何進行DRP系統“數據治理”的思考。
數據治理的理論及方法
項目小組總結之後，通過查找相關資料發現：數據治理其實是一種體系，是一個關注於信息系統執行層面的體系，這一體系的目的是整合IT與業務部門的知識和意見，通過一個類似於監督委員會或項目小組的虛擬組織對企業的信息化建設進行全方位的監管，這一組織的基礎是企業高層的授權和業務部門與IT部門的建設性合作。從範圍來講，數據治理涵蓋了從前端事務處理系統，後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
1. 發現：即發現問題和差異（Issues & Gaps），這是監管的基本職能。我們一定要在萌芽階段發現問題和差異，將其扼殺在苗頭。那麼如何去發現呢？
對於待建或在建的系統，要建立專家審覈制度，所謂專家包括技術專家和業務專家，如果本組織不具備條件則可以邀請第三方的顧問來參與系統數據的架構和設計決策，但根本原則是任何專家必須是相關領域的專業人士。
對於已建成使用的系統，則關鍵是IT的日常運維工作的規範化，主要包括規範的問題管理（Trouble Management），週期性審計(Periodic Review)。前者是爲了文檔化各種系統問題和缺陷，以及相應的IT判斷和響應；後者是爲了及時對系統的問題和缺陷做出歸納總結，找出規律而從根本上解決問題。
2. 監督：即持續的保持對業務數據健康狀況的跟蹤。監督主要通過週期性的數據分析來完成，市場上也有很多自動化的工具可以幫助您方便的對數據的健康狀況進行分析。與發現所不同的是，監督是主動的去發掘問題，而且在發現問題後立即採取行動去修正它。
3. 控制：即掌握信息系統建設的決策權。任何信息系統的建設、更新升級、大型變更都必須通過數據治理項目小組的審批，極端情況下甚至可以考慮任何數據變更都必須審批。集中化的控制的好處是，首先可以集中技術和業務相關領域的專家的意見，其次可以限制執行層面的IT人員和業務人員的隨意性、不嚴謹性，再次向監管層提供了從全局和長遠的角度看系統的機會。
4. 交流：即溝通，是跨部門的跨領域的溝通。對傳統IT的最大挑戰就是跨組織跨領域的溝通交流，而數據治理委員會這樣一個跨越了IT部門和業務部門的虛擬組織，通過建立例行的交流機制，保證了信息在整個組織範圍內的透明，這種透明性保證了所有參與者的步調一致的，保證了業務數據的一致性。交流滲透在前面所述的四點數據治理活動中，是它們成功的保障。
5. 整合：這是我們的目標同時也是解決之道，主要抓住三個方面的整合——信息的整合，資源的整合，能力的整合。通過信息的整合把分散的業務數據整合到一個一致的沒有歧義的體系中來；通過資源的整合把企業IT資源集中調配；通過能力的整合，將平臺的運算能力，業務數據處理能力集中管理，建立一種集中服務的模式，即提高了硬件利用率、人員工作效率又利於IT對各業務部門服務的成本覈算。
“數據事故”分析
爲了解決數據事故問題，筆者協調財務、計劃、銷售、IT等部門成立了專門的“數據治理”項目小組。數據事故，應該是由於數據的素質低劣造成的，根據調查機構Gartner稱，《財富》一千家大型企業所持有的數據，有超過四分一是不準確、不完整或重複的，並預期有四分之三的大型企業直到2010年前也不會或難以改善內部數據的素質。其實沒有一家企業不受數據素質問題困擾，但就算有公司意識到問題所在，也常常會低估問題的嚴重性。何況，數據素質會受多個因素影響而變化。因此，要應付這種挑戰，一次性的行動難以奏效，企業務必持之以恆，甚至採取能改寫企業文化的行動纔會有效。
Gartner研究顯示，良莠不齊的客戶數據可造成重大損失，包括流失客戶，以及由處理直銷郵件不善和錯過銷售機會所造成的浪費等。現時很多企業亦發現劣質數據不單打擊銷售及市場推廣，更會波及最具策略性的業務活動。後勤部門的運作，例如制定預算、生產及分銷也會受到影響。
解決劣質數據問題不只只是一個IT的問題。雖然IT有助將之改善，但企業管理纔是關鍵所在，例如企業文化對數據素質就有很大的影響力。
數據治理，需要對數據的素質提出一個定義，筆者認爲數據素質涵蓋以下多方面：
ü 存在 (即企業到底有沒有某一項數據)
ü 合法性 (即該項數據的數值是否符合一個可接受的範圍)
ü 一貫性 (例如同一項數據不論儲存在哪一個地點都有同一數值)
ü 整全性 (數據元素與不同數據集之間關係的完整程度)
ü 準確性 (該項數據是否能夠描述它應表達的東西)
ü 關聯性 (該項數據能否恰當地支援業務宗旨)
ü 時間性 (即該項數據是否能夠及時地被反應出來)
針對以上數據的素質，再結合DRP系統中的相關模塊，對DRP系統中數據問題按模塊分別分析。該分析表格如下：
|
| 採購 | 訂貨 | 直營 | 門店 | 價格 | 倉儲物流 | |
| 存在 | Y | Y | Y | Y | Y | Y | Y |
| 合法性 | Y | Y | Y | Y | Y | Y | Y |
| 一貫性 | Y | Y | Y | N | N | N | Y |
| 整全性 | N | Y | Y | Y | N | Y | Y |
| 準確性 | N | N | N | N | N | N | N |
| 關聯性 | Y | Y | Y | Y | Y | N | N |
| 時間性 | N | Y | N | N | N | N | N |
以上各模塊中，達到相應的數據素質目標即爲Y，否則爲N。經過對DRP系統中的各個模塊的數據素質調查發現：數據治理主要針對的是數據的準確性、時間性、關聯性。進一步對數據事故的原因分析，發現數據出問題往往是因爲對數據的應用不夠充分。比如物流配送，根據銷售和庫存信息來做，首先銷售的信息，每天系統裏面的銷售信息和銀行回款對比，有沒有差異，沒有差異就是對的。第二，配送是根據系統去配。慢慢的精細化，以前可能是粗放的，現在是一個環節套一個環節，根據這個系統來做，慢慢數據就會越來越準確。百分之百的準確不可能，當然也沒有必要，因爲隨便一個環節都有可能出現串碼。
但如果業務部門發現DRP系統不管用，但DRP使用者就會用自己祕密地使用自己“更方便更可靠的工作流程/做法”。而管理層認爲既然沒有發生什麼不妥，也就睜一隻眼，閉一隻眼。其實，任何繞道DRP系統的工作流程/做法都會產生DRP數據流之外的“數據暗流”。這種“數據暗流”會削弱企業對流程的控制，損害企業對流程的管理和進一步優化，自然DRP系統的數據準確性就更差了。那麼，我們又怎樣保證及時數據更新和避免繞道DRP的祕密的“更方便更可靠的工作流程/做法”呢?解決方案原則上很簡單：持續提高數據準確率，定期維護訂單修訂等系統參數，以確保DRP產生的數據流與實際運作相符，通過基於DRP的工作流程的改進，禁止任何繞道DRP的行爲。
同時，借鑑了業內同行的“數據事故”分析方法，可以得到如下的因果圖：
針對上述發現的各種原因，經過進一步的統計與分析，發現主要的問題在審覈流程缺失，KPI指標設定不完善、考覈與處罰機制沒有執行、指定時間內的數據不到位、業務不熟悉、操作不當上。相反，由於系統原因造成的DRP數據錯誤很少。而像流程原因導致數據錯誤出現的次數只佔20%，但由於流程原因出現的數據錯誤影響程度最大。而像操作不當、指定時間內的數據不到位的情況出現較頻繁，但對數據錯誤的影響有限。
數據治理方案
採用上述的數據治理理論，在經過“數據事故”的教訓之後，發現上述數據問題，分別針對時間因素、流程、數據基礎、考覈機制、人員、系統制定數據治理方案，並強調方案的執行、監督、控制職能，加強各業務人員溝通，達到數據治理的目的。
考覈機制：數據治理的問題其實也是企業管理的問題，而出現問題往往是沒有一個比較好的考覈與激勵機制。在數據事故當中，出了問題之後，IT人員急着去查找原因，財務部門則因爲數據報表出不來而乾着急，而往往是事故責任部門往往是數據生產部門，而不是數據消費部門。所以，沒有好的考覈機制，往往事故在出現了之後無據可依地進行處罰，導致員工情緒極大。因此，我們定製瞭如下考覈辦法：每月結束，涉及到DRP系統中數據操作的，出現錯誤次數在5次(含5次)以上的，每次罰款10元，充入公司獎金池；如果每月操作零錯誤的，則從獎金池內獎勵30元；各部門的年度KPI指標中加入DRP系統數據操作正確率，並給予一定的權重，此舉目的就是爲了能夠使各業務部門經理引起對DRP系統數據操作正確性的重視。
人員：人員責任心不強的問題，可以由前面的考覈機制來加強，而且由於數據操作涉及到部門的績效，因此，各業務部門經理也會加強在這方面的監督；對於操作不當，業務不熟悉的情況，可以歸結爲培訓不夠。對於培訓我們分爲兩大塊：一是新員工培訓，這包括老員工調職到新崗位，新員工如果需要操作DRP系統，必須經過IT部的上崗培訓方可開設DRP系統賬號，否則的話，將無權對DRP系統進行操作；還有就是專場培訓，這也有兩類，一類是專門的計算機基礎教育培訓，這裏會包括一些計算機基礎操作，基本故障處理；另一類是公司業務流程培訓，針對各個不同崗位的人員，將公司的業務流程整合起來講，讓各業務人員知道自己上下游的業務流程是什麼？如果有異常如何處理等，同時培訓由人力資源部培訓組與IT部共同負責，所有培訓考勤、反饋、考覈情況都記入員工培訓檔案，講師則由IT部門、業務部門經理分別承擔；如果是針對各業務經理的培訓，也會請外部的流程、IT專家來擔任。
系統：系統的問題，主要通過兩方面控制：一是加強測試，所有的系統升級都必須經過公司內部的程序員測試，撰寫測試報告，經由IT經理審批之後方可將升級包更新到DRP系統中去，如果由於升級原因造成系統邏輯問題造成的數據錯誤，必須由程序員與IT經理分別承擔責任，根據每次事故的問題嚴重性，每次罰款30—300不等，同時IT部門的KPI指標中也加入系統數據事故的次數進行考覈。二是對於關鍵服務器、網絡設備的突然當機等情況的處理，這些方案可以根據IT部門的原有處置與考覈機制進行。
數據基礎：基礎數據質量差，這就是對數據生產部門提出需求，必須控制數據質量，完善公司數據規格說明，對於必須填寫的數據，由IT部門定期出具數據質量審計報告，對數據生產部門進行考覈。對於數據錄入準確率低的問題，一是採用條碼、掃描等技術手段來加強數據質量，二是通過加強人員責任心來保證，三則是通過數據審覈，下游業務流程一定要加強對數據的審覈與比對，特別是在分公司，由財務、倉管、數據員三方進行數據確認，以保證數據與業務的同步。
流程：物流是最頭痛的問題，也是處理起來最難的問題，其實關於業務流程管理(BPM)是一個很大的話題，在這裏呢，只能說是，根據企業實際情況，一點點的改進，因爲流程改進是一個傷筋動骨的事情，包括：原有流程是合適企業應用的，但現在不合適了怎麼辦？原來的流程是由某個部門負責的，現在職能要細化，要分開怎麼辦？所以在這裏就不再鋪開來講，但以後有機會進一步進行論述。
時間因素：時間因素，主要在於企業的動作效率，也是對於員工的一個考覈指標，這方面沒有太大的難度，我們主要也是將時間作爲數據生產部門的一個指標來考覈，如：計劃部門必須在訂貨單的2小時之內將訂貨單貨配發出去；專賣店如果有DRP系統，必須在當天將銷售數據傳回，如果沒有DRP系統，則傳真數據必須在當天傳回，當地辦事處必須在第二天上午11：00之前將銷售數據做到DRP系統中；客服部必須在12小時內將客戶數據錄入到DRP系統中，對於客戶的禮品申請，必須在兩個工作日內處理完畢，並給客戶回覆等。
上述所有的針對問題的解決方案都離不開執行、監督、控制與交流。在這幾個環節當中，IT部門與行政部門爲主要的執行主體，IT部門負責對DRP系統中的數據異常或每月數據質量出具報告，行政部門則根據IT部門的報告和數據質量方面的制度，給業務部門的KPI指標進行評定，也針對操作人員進行具體的獎罰；同時在培訓這一塊，由人力資源部門與IT部門負責完成。
而IT部門的系統故障及錯誤等問題，則落實到財務部與行政部具體負責進行考覈，這也就是一個監督機制，IT部門作爲DRP系統的管理者，也是要被各個業務部門進行監督的。
而由於涉及到各個業務部門的各個業務環節，特別在加入了績效考覈之後，會引起業務部門對IT部門的敵視，甚至是對DRP系統的敵視，因此，所有策略的實施都需要IT經理與數據治理項目小組的負責人加強溝通。特別是要注意循序漸進，切忌要求一步到位，否則的話引起業務部門的不滿與反彈，有可能事情會變的更糟糕。
項目管理手記(五)
DRP項目中的數據治理
由於我本人的項目經驗在DRP項目中會比較多一些，而且所談及的問題也是在DRP項目中碰到的，當然，也許我說的這個問題不只只是在DRP項目中，包括像ERP、PDM、KM等項目中都會碰上，但我還是會結合DRP項目中的實際問題來說。同時，由於本人所在的角度是甲方的角度，因此，DRP項目的週期對於甲方來說不只只是項目調研、實施、培訓，還會包括整個DRP系統的應用、部署、維護直到系統結束使用的DRP系統的整個使用週期。
DRP項目進行到後期，一般的企業都會擔心一個問題“顧問走了之後，我們怎麼辦？”。因爲如果實施顧問在現場的話，感覺都不會出什麼問題，就算有問題，顧問也解決掉了。但一旦顧問離場，DRP系統交由企業的IT部門負責運行與維護的時候，感覺問題就出的比較多了。這些問題可能會包括系統故障增多，系統運行速度減慢，軟件需求得不到響應，數據不準等。也因爲這些原因業務部門也在應用了一段時間之後感覺系統不好用了，特別是數據不準的情況經常出現，使得報表也不準了，久而久之，業務部門感覺DRP系統的價值也越來越低了，而這樣造成的直接後果就是DRP系統的使用效果打折，經常會聽到業務部門在抱怨：“這是什麼破系統嘛，出來的數據都不準!”，把數據問題與DRP系統邏輯問題相混淆，從而有可能對DRP系統本身引發了懷疑，導致DRP系統的使用週期因爲數據不準而大大縮短。
“數據事故”引發的數據治理思考
套用一句老話：“ERP是三分軟件、七分實施、十分努力、十二分數據、百分百的領導支持”。其實筆者一直在實施DRP項目的過程中，都有碰到多或多或少的數據問題，但應該都是小問題，所影響的範圍也不大，或者通過DRP系統的一些異常處理功能也就能夠解決的，如：退貨單出現的退貨價格不準確的問題，只要對這張單據進行廢除重做就好了，直到筆者碰到兩次重大的“數據事故”，纔對DRP項目的數據治理工作引發了重視與思考。
第一件事情是由於產品中心對新產品定價錯誤引發的“數據事故”。一直以來，新產品的定價是由產品中心會同財務、銷售、計劃等部門一起制定的，而且制定的是產品的零售價，然後根據零售價的折率分別倒推定製分銷價、出廠價、採購價，而採購價也是一個基準價，也就是說，產品的採購必須低於這個價格，否則的話公司是不會批准對這款產品進行投產的。在年度某季度新產品定價時，公司各部門定製出了當季產品的各種價格，並已經在系統中進行實施，但隨之而來的是，發現在市場對於當季產品的價格反映是偏高，而且代理商也認爲當季產品的分銷價格(即代理商進貨價)太高，所以公司決定對該款產品進行重新定價。隨之而來的就是要求DRP系統中對所有業務環節中的價格進行調整，包括對已經配送到分公司、代理商的產品進行重新調價，對已經配送到直營店，在倉庫中未銷售的產品進行價格調整。這一次的調整由於影響極大，導致公司各業務部門不得不集中人馬加班對數據進行調整，而且調整結束之後，在下月的系統過賬中發現財務報表總是有些出入，才發現數據調整有問題，有些調過來了，有些沒有調整過來，有些調整的時候產品已經銷售出去了，有的產品是退貨的，但成本卻沒有改過來，總之是亂的一團麻，使的該月的財務報表不得不在財務部門的要求下，各業務部門簽字覈定是由於操作不當引起的數據統計問題。本次問題其實是一個業務規範性的問題，或者是系統強壯型問題，如果業務夠規範，不會出現這種在產品進行銷售時更改產品成本的問題，或者系統足夠強壯，能夠對數據變更做出及時處理，這次事故應該也是能夠避免的。
第二件事是由於分公司內部管理、控制不到位及流程缺失導致的“數據事故”。記得當時還在外面開會，被財務總監電話催回公司，說是公司領導要求我今天準備一下，明天去華中大區出差，因爲當地分公司的本月的財務、系統數據都有嚴重問題，估計賬實不符情況嚴重，需要過去核查一下問題到底出在哪裏。第二天，當公司的財務、計劃、IT三部門人員到達華中大區所在地時，開始安排了對本大區所有的庫存盤點的工作，首先是對直營店進行盤點，全部由總部人員進行監督，經過五個晚上的盤點之後，再用了四天時間對大區的庫房進行盤點，發現：直營店的手工賬務與DRP系統中的數據不符情況嚴重，而直營店的手工賬務與實際庫存情況相差無幾，直營店也較好地執行了失貨賠償制度。而DRP系統中的數據與實際庫存嚴重不符的原因在於：大區的倉庫管理人員、數據員都沒有及時將直營店的退貨、銷售、調撥單據進行處理，以致直營店數據失真；同時對大區的庫存盤點時發現：大區的庫存結構不合理，庫存過大，直營店的過季產品處理不及時，數據員沒有對倉庫數據進行及時分析及利用。同時，大區的財務人員也沒有根據DRP系統中的數據進行財務數據覈對，以至於倉庫、數據、財務的工作脫節，形成了大區庫房管理工作出現了失控。這次事故經過審覈之後，上報到公司領導，下定決心對相關責任人進行了處罰，而也是在這次“數據事故”之後引發了筆者對於如何進行DRP系統“數據治理”的思考。
數據治理的理論及方法
項目小組總結之後，通過查找相關資料發現：數據治理其實是一種體系，是一個關注於信息系統執行層面的體系，這一體系的目的是整合IT與業務部門的知識和意見，通過一個類似於監督委員會或項目小組的虛擬組織對企業的信息化建設進行全方位的監管，這一組織的基礎是企業高層的授權和業務部門與IT部門的建設性合作。從範圍來講，數據治理涵蓋了從前端事務處理系統，後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
1. 發現：即發現問題和差異（Issues & Gaps），這是監管的基本職能。我們一定要在萌芽階段發現問題和差異，將其扼殺在苗頭。那麼如何去發現呢？
對於待建或在建的系統，要建立專家審覈制度，所謂專家包括技術專家和業務專家，如果本組織不具備條件則可以邀請第三方的顧問來參與系統數據的架構和設計決策，但根本原則是任何專家必須是相關領域的專業人士。
對於已建成使用的系統，則關鍵是IT的日常運維工作的規範化，主要包括規範的問題管理（Trouble Management），週期性審計(Periodic Review)。前者是爲了文檔化各種系統問題和缺陷，以及相應的IT判斷和響應；後者是爲了及時對系統的問題和缺陷做出歸納總結，找出規律而從根本上解決問題。
2. 監督：即持續的保持對業務數據健康狀況的跟蹤。監督主要通過週期性的數據分析來完成，市場上也有很多自動化的工具可以幫助您方便的對數據的健康狀況進行分析。與發現所不同的是，監督是主動的去發掘問題，而且在發現問題後立即採取行動去修正它。
3. 控制：即掌握信息系統建設的決策權。任何信息系統的建設、更新升級、大型變更都必須通過數據治理項目小組的審批，極端情況下甚至可以考慮任何數據變更都必須審批。集中化的控制的好處是，首先可以集中技術和業務相關領域的專家的意見，其次可以限制執行層面的IT人員和業務人員的隨意性、不嚴謹性，再次向監管層提供了從全局和長遠的角度看系統的機會。
4. 交流：即溝通，是跨部門的跨領域的溝通。對傳統IT的最大挑戰就是跨組織跨領域的溝通交流，而數據治理委員會這樣一個跨越了IT部門和業務部門的虛擬組織，通過建立例行的交流機制，保證了信息在整個組織範圍內的透明，這種透明性保證了所有參與者的步調一致的，保證了業務數據的一致性。交流滲透在前面所述的四點數據治理活動中，是它們成功的保障。
5. 整合：這是我們的目標同時也是解決之道，主要抓住三個方面的整合——信息的整合，資源的整合，能力的整合。通過信息的整合把分散的業務數據整合到一個一致的沒有歧義的體系中來；通過資源的整合把企業IT資源集中調配；通過能力的整合，將平臺的運算能力，業務數據處理能力集中管理，建立一種集中服務的模式，即提高了硬件利用率、人員工作效率又利於IT對各業務部門服務的成本覈算。
“數據事故”分析
爲了解決數據事故問題，筆者協調財務、計劃、銷售、IT等部門成立了專門的“數據治理”項目小組。數據事故，應該是由於數據的素質低劣造成的，根據調查機構Gartner稱，《財富》一千家大型企業所持有的數據，有超過四分一是不準確、不完整或重複的，並預期有四分之三的大型企業直到2010年前也不會或難以改善內部數據的素質。其實沒有一家企業不受數據素質問題困擾，但就算有公司意識到問題所在，也常常會低估問題的嚴重性。何況，數據素質會受多個因素影響而變化。因此，要應付這種挑戰，一次性的行動難以奏效，企業務必持之以恆，甚至採取能改寫企業文化的行動纔會有效。
Gartner研究顯示，良莠不齊的客戶數據可造成重大損失，包括流失客戶，以及由處理直銷郵件不善和錯過銷售機會所造成的浪費等。現時很多企業亦發現劣質數據不單打擊銷售及市場推廣，更會波及最具策略性的業務活動。後勤部門的運作，例如制定預算、生產及分銷也會受到影響。
解決劣質數據問題不只只是一個IT的問題。雖然IT有助將之改善，但企業管理纔是關鍵所在，例如企業文化對數據素質就有很大的影響力。
數據治理，需要對數據的素質提出一個定義，筆者認爲數據素質涵蓋以下多方面：
ü 存在 (即企業到底有沒有某一項數據)
ü 合法性 (即該項數據的數值是否符合一個可接受的範圍)
ü 一貫性 (例如同一項數據不論儲存在哪一個地點都有同一數值)
ü 整全性 (數據元素與不同數據集之間關係的完整程度)
ü 準確性 (該項數據是否能夠描述它應表達的東西)
ü 關聯性 (該項數據能否恰當地支援業務宗旨)
ü 時間性 (即該項數據是否能夠及時地被反應出來)
針對以上數據的素質，再結合DRP系統中的相關模塊，對DRP系統中數據問題按模塊分別分析。該分析表格如下：
|
| 採購 | 訂貨 | 直營 | 門店 | 價格 | 倉儲物流 | |
| 存在 | Y | Y | Y | Y | Y | Y | Y |
| 合法性 | Y | Y | Y | Y | Y | Y | Y |
| 一貫性 | Y | Y | Y | N | N | N | Y |
| 整全性 | N | Y | Y | Y | N | Y | Y |
| 準確性 | N | N | N | N | N | N | N |
| 關聯性 | Y | Y | Y | Y | Y | N | N |
| 時間性 | N | Y | N | N | N | N | N |
以上各模塊中，達到相應的數據素質目標即爲Y，否則爲N。經過對DRP系統中的各個模塊的數據素質調查發現：數據治理主要針對的是數據的準確性、時間性、關聯性。進一步對數據事故的原因分析，發現數據出問題往往是因爲對數據的應用不夠充分。比如物流配送，根據銷售和庫存信息來做，首先銷售的信息，每天系統裏面的銷售信息和銀行回款對比，有沒有差異，沒有差異就是對的。第二，配送是根據系統去配。慢慢的精細化，以前可能是粗放的，現在是一個環節套一個環節，根據這個系統來做，慢慢數據就會越來越準確。百分之百的準確不可能，當然也沒有必要，因爲隨便一個環節都有可能出現串碼。
但如果業務部門發現DRP系統不管用，但DRP使用者就會用自己祕密地使用自己“更方便更可靠的工作流程/做法”。而管理層認爲既然沒有發生什麼不妥，也就睜一隻眼，閉一隻眼。其實，任何繞道DRP系統的工作流程/做法都會產生DRP數據流之外的“數據暗流”。這種“數據暗流”會削弱企業對流程的控制，損害企業對流程的管理和進一步優化，自然DRP系統的數據準確性就更差了。那麼，我們又怎樣保證及時數據更新和避免繞道DRP的祕密的“更方便更可靠的工作流程/做法”呢?解決方案原則上很簡單：持續提高數據準確率，定期維護訂單修訂等系統參數，以確保DRP產生的數據流與實際運作相符，通過基於DRP的工作流程的改進，禁止任何繞道DRP的行爲。
同時，借鑑了業內同行的“數據事故”分析方法，可以得到如下的因果圖：
針對上述發現的各種原因，經過進一步的統計與分析，發現主要的問題在審覈流程缺失，KPI指標設定不完善、考覈與處罰機制沒有執行、指定時間內的數據不到位、業務不熟悉、操作不當上。相反，由於系統原因造成的DRP數據錯誤很少。而像流程原因導致數據錯誤出現的次數只佔20%，但由於流程原因出現的數據錯誤影響程度最大。而像操作不當、指定時間內的數據不到位的情況出現較頻繁，但對數據錯誤的影響有限。
數據治理方案
採用上述的數據治理理論，在經過“數據事故”的教訓之後，發現上述數據問題，分別針對時間因素、流程、數據基礎、考覈機制、人員、系統制定數據治理方案，並強調方案的執行、監督、控制職能，加強各業務人員溝通，達到數據治理的目的。
考覈機制：數據治理的問題其實也是企業管理的問題，而出現問題往往是沒有一個比較好的考覈與激勵機制。在數據事故當中，出了問題之後，IT人員急着去查找原因，財務部門則因爲數據報表出不來而乾着急，而往往是事故責任部門往往是數據生產部門，而不是數據消費部門。所以，沒有好的考覈機制，往往事故在出現了之後無據可依地進行處罰，導致員工情緒極大。因此，我們定製瞭如下考覈辦法：每月結束，涉及到DRP系統中數據操作的，出現錯誤次數在5次(含5次)以上的，每次罰款10元，充入公司獎金池；如果每月操作零錯誤的，則從獎金池內獎勵30元；各部門的年度KPI指標中加入DRP系統數據操作正確率，並給予一定的權重，此舉目的就是爲了能夠使各業務部門經理引起對DRP系統數據操作正確性的重視。
人員：人員責任心不強的問題，可以由前面的考覈機制來加強，而且由於數據操作涉及到部門的績效，因此，各業務部門經理也會加強在這方面的監督；對於操作不當，業務不熟悉的情況，可以歸結爲培訓不夠。對於培訓我們分爲兩大塊：一是新員工培訓，這包括老員工調職到新崗位，新員工如果需要操作DRP系統，必須經過IT部的上崗培訓方可開設DRP系統賬號，否則的話，將無權對DRP系統進行操作；還有就是專場培訓，這也有兩類，一類是專門的計算機基礎教育培訓，這裏會包括一些計算機基礎操作，基本故障處理；另一類是公司業務流程培訓，針對各個不同崗位的人員，將公司的業務流程整合起來講，讓各業務人員知道自己上下游的業務流程是什麼？如果有異常如何處理等，同時培訓由人力資源部培訓組與IT部共同負責，所有培訓考勤、反饋、考覈情況都記入員工培訓檔案，講師則由IT部門、業務部門經理分別承擔；如果是針對各業務經理的培訓，也會請外部的流程、IT專家來擔任。
系統：系統的問題，主要通過兩方面控制：一是加強測試，所有的系統升級都必須經過公司內部的程序員測試，撰寫測試報告，經由IT經理審批之後方可將升級包更新到DRP系統中去，如果由於升級原因造成系統邏輯問題造成的數據錯誤，必須由程序員與IT經理分別承擔責任，根據每次事故的問題嚴重性，每次罰款30—300不等，同時IT部門的KPI指標中也加入系統數據事故的次數進行考覈。二是對於關鍵服務器、網絡設備的突然當機等情況的處理，這些方案可以根據IT部門的原有處置與考覈機制進行。
數據基礎：基礎數據質量差，這就是對數據生產部門提出需求，必須控制數據質量，完善公司數據規格說明，對於必須填寫的數據，由IT部門定期出具數據質量審計報告，對數據生產部門進行考覈。對於數據錄入準確率低的問題，一是採用條碼、掃描等技術手段來加強數據質量，二是通過加強人員責任心來保證，三則是通過數據審覈，下游業務流程一定要加強對數據的審覈與比對，特別是在分公司，由財務、倉管、數據員三方進行數據確認，以保證數據與業務的同步。
流程：物流是最頭痛的問題，也是處理起來最難的問題，其實關於業務流程管理(BPM)是一個很大的話題，在這裏呢，只能說是，根據企業實際情況，一點點的改進，因爲流程改進是一個傷筋動骨的事情，包括：原有流程是合適企業應用的，但現在不合適了怎麼辦？原來的流程是由某個部門負責的，現在職能要細化，要分開怎麼辦？所以在這裏就不再鋪開來講，但以後有機會進一步進行論述。
時間因素：時間因素，主要在於企業的動作效率，也是對於員工的一個考覈指標，這方面沒有太大的難度，我們主要也是將時間作爲數據生產部門的一個指標來考覈，如：計劃部門必須在訂貨單的2小時之內將訂貨單貨配發出去；專賣店如果有DRP系統，必須在當天將銷售數據傳回，如果沒有DRP系統，則傳真數據必須在當天傳回，當地辦事處必須在第二天上午11：00之前將銷售數據做到DRP系統中；客服部必須在12小時內將客戶數據錄入到DRP系統中，對於客戶的禮品申請，必須在兩個工作日內處理完畢，並給客戶回覆等。
上述所有的針對問題的解決方案都離不開執行、監督、控制與交流。在這幾個環節當中，IT部門與行政部門爲主要的執行主體，IT部門負責對DRP系統中的數據異常或每月數據質量出具報告，行政部門則根據IT部門的報告和數據質量方面的制度，給業務部門的KPI指標進行評定，也針對操作人員進行具體的獎罰；同時在培訓這一塊，由人力資源部門與IT部門負責完成。
而IT部門的系統故障及錯誤等問題，則落實到財務部與行政部具體負責進行考覈，這也就是一個監督機制，IT部門作爲DRP系統的管理者，也是要被各個業務部門進行監督的。
而由於涉及到各個業務部門的各個業務環節，特別在加入了績效考覈之後，會引起業務部門對IT部門的敵視，甚至是對DRP系統的敵視，因此，所有策略的實施都需要IT經理與數據治理項目小組的負責人加強溝通。特別是要注意循序漸進，切忌要求一步到位，否則的話引起業務部門的不滿與反彈，有可能事情會變的更糟糕。
項目管理手記(五)
DRP項目中的數據治理
由於我本人的項目經驗在DRP項目中會比較多一些，而且所談及的問題也是在DRP項目中碰到的，當然，也許我說的這個問題不只只是在DRP項目中，包括像ERP、PDM、KM等項目中都會碰上，但我還是會結合DRP項目中的實際問題來說。同時，由於本人所在的角度是甲方的角度，因此，DRP項目的週期對於甲方來說不只只是項目調研、實施、培訓，還會包括整個DRP系統的應用、部署、維護直到系統結束使用的DRP系統的整個使用週期。
DRP項目進行到後期，一般的企業都會擔心一個問題“顧問走了之後，我們怎麼辦？”。因爲如果實施顧問在現場的話，感覺都不會出什麼問題，就算有問題，顧問也解決掉了。但一旦顧問離場，DRP系統交由企業的IT部門負責運行與維護的時候，感覺問題就出的比較多了。這些問題可能會包括系統故障增多，系統運行速度減慢，軟件需求得不到響應，數據不準等。也因爲這些原因業務部門也在應用了一段時間之後感覺系統不好用了，特別是數據不準的情況經常出現，使得報表也不準了，久而久之，業務部門感覺DRP系統的價值也越來越低了，而這樣造成的直接後果就是DRP系統的使用效果打折，經常會聽到業務部門在抱怨：“這是什麼破系統嘛，出來的數據都不準!”，把數據問題與DRP系統邏輯問題相混淆，從而有可能對DRP系統本身引發了懷疑，導致DRP系統的使用週期因爲數據不準而大大縮短。
“數據事故”引發的數據治理思考
套用一句老話：“ERP是三分軟件、七分實施、十分努力、十二分數據、百分百的領導支持”。其實筆者一直在實施DRP項目的過程中，都有碰到多或多或少的數據問題，但應該都是小問題，所影響的範圍也不大，或者通過DRP系統的一些異常處理功能也就能夠解決的，如：退貨單出現的退貨價格不準確的問題，只要對這張單據進行廢除重做就好了，直到筆者碰到兩次重大的“數據事故”，纔對DRP項目的數據治理工作引發了重視與思考。
第一件事情是由於產品中心對新產品定價錯誤引發的“數據事故”。一直以來，新產品的定價是由產品中心會同財務、銷售、計劃等部門一起制定的，而且制定的是產品的零售價，然後根據零售價的折率分別倒推定製分銷價、出廠價、採購價，而採購價也是一個基準價，也就是說，產品的採購必須低於這個價格，否則的話公司是不會批准對這款產品進行投產的。在年度某季度新產品定價時，公司各部門定製出了當季產品的各種價格，並已經在系統中進行實施，但隨之而來的是，發現在市場對於當季產品的價格反映是偏高，而且代理商也認爲當季產品的分銷價格(即代理商進貨價)太高，所以公司決定對該款產品進行重新定價。隨之而來的就是要求DRP系統中對所有業務環節中的價格進行調整，包括對已經配送到分公司、代理商的產品進行重新調價，對已經配送到直營店，在倉庫中未銷售的產品進行價格調整。這一次的調整由於影響極大，導致公司各業務部門不得不集中人馬加班對數據進行調整，而且調整結束之後，在下月的系統過賬中發現財務報表總是有些出入，才發現數據調整有問題，有些調過來了，有些沒有調整過來，有些調整的時候產品已經銷售出去了，有的產品是退貨的，但成本卻沒有改過來，總之是亂的一團麻，使的該月的財務報表不得不在財務部門的要求下，各業務部門簽字覈定是由於操作不當引起的數據統計問題。本次問題其實是一個業務規範性的問題，或者是系統強壯型問題，如果業務夠規範，不會出現這種在產品進行銷售時更改產品成本的問題，或者系統足夠強壯，能夠對數據變更做出及時處理，這次事故應該也是能夠避免的。
第二件事是由於分公司內部管理、控制不到位及流程缺失導致的“數據事故”。記得當時還在外面開會，被財務總監電話催回公司，說是公司領導要求我今天準備一下，明天去華中大區出差，因爲當地分公司的本月的財務、系統數據都有嚴重問題，估計賬實不符情況嚴重，需要過去核查一下問題到底出在哪裏。第二天，當公司的財務、計劃、IT三部門人員到達華中大區所在地時，開始安排了對本大區所有的庫存盤點的工作，首先是對直營店進行盤點，全部由總部人員進行監督，經過五個晚上的盤點之後，再用了四天時間對大區的庫房進行盤點，發現：直營店的手工賬務與DRP系統中的數據不符情況嚴重，而直營店的手工賬務與實際庫存情況相差無幾，直營店也較好地執行了失貨賠償制度。而DRP系統中的數據與實際庫存嚴重不符的原因在於：大區的倉庫管理人員、數據員都沒有及時將直營店的退貨、銷售、調撥單據進行處理，以致直營店數據失真；同時對大區的庫存盤點時發現：大區的庫存結構不合理，庫存過大，直營店的過季產品處理不及時，數據員沒有對倉庫數據進行及時分析及利用。同時，大區的財務人員也沒有根據DRP系統中的數據進行財務數據覈對，以至於倉庫、數據、財務的工作脫節，形成了大區庫房管理工作出現了失控。這次事故經過審覈之後，上報到公司領導，下定決心對相關責任人進行了處罰，而也是在這次“數據事故”之後引發了筆者對於如何進行DRP系統“數據治理”的思考。
數據治理的理論及方法
項目小組總結之後，通過查找相關資料發現：數據治理其實是一種體系，是一個關注於信息系統執行層面的體系，這一體系的目的是整合IT與業務部門的知識和意見，通過一個類似於監督委員會或項目小組的虛擬組織對企業的信息化建設進行全方位的監管，這一組織的基礎是企業高層的授權和業務部門與IT部門的建設性合作。從範圍來講，數據治理涵蓋了從前端事務處理系統，後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
1. 發現：即發現問題和差異（Issues & Gaps），這是監管的基本職能。我們一定要在萌芽階段發現問題和差異，將其扼殺在苗頭。那麼如何去發現呢？
對於待建或在建的系統，要建立專家審覈制度，所謂專家包括技術專家和業務專家，如果本組織不具備條件則可以邀請第三方的顧問來參與系統數據的架構和設計決策，但根本原則是任何專家必須是相關領域的專業人士。
對於已建成使用的系統，則關鍵是IT的日常運維工作的規範化，主要包括規範的問題管理（Trouble Management），週期性審計(Periodic Review)。前者是爲了文檔化各種系統問題和缺陷，以及相應的IT判斷和響應；後者是爲了及時對系統的問題和缺陷做出歸納總結，找出規律而從根本上解決問題。
2. 監督：即持續的保持對業務數據健康狀況的跟蹤。監督主要通過週期性的數據分析來完成，市場上也有很多自動化的工具可以幫助您方便的對數據的健康狀況進行分析。與發現所不同的是，監督是主動的去發掘問題，而且在發現問題後立即採取行動去修正它。
3. 控制：即掌握信息系統建設的決策權。任何信息系統的建設、更新升級、大型變更都必須通過數據治理項目小組的審批，極端情況下甚至可以考慮任何數據變更都必須審批。集中化的控制的好處是，首先可以集中技術和業務相關領域的專家的意見，其次可以限制執行層面的IT人員和業務人員的隨意性、不嚴謹性，再次向監管層提供了從全局和長遠的角度看系統的機會。
4. 交流：即溝通，是跨部門的跨領域的溝通。對傳統IT的最大挑戰就是跨組織跨領域的溝通交流，而數據治理委員會這樣一個跨越了IT部門和業務部門的虛擬組織，通過建立例行的交流機制，保證了信息在整個組織範圍內的透明，這種透明性保證了所有參與者的步調一致的，保證了業務數據的一致性。交流滲透在前面所述的四點數據治理活動中，是它們成功的保障。
5. 整合：這是我們的目標同時也是解決之道，主要抓住三個方面的整合——信息的整合，資源的整合，能力的整合。通過信息的整合把分散的業務數據整合到一個一致的沒有歧義的體系中來；通過資源的整合把企業IT資源集中調配；通過能力的整合，將平臺的運算能力，業務數據處理能力集中管理，建立一種集中服務的模式，即提高了硬件利用率、人員工作效率又利於IT對各業務部門服務的成本覈算。
“數據事故”分析
爲了解決數據事故問題，筆者協調財務、計劃、銷售、IT等部門成立了專門的“數據治理”項目小組。數據事故，應該是由於數據的素質低劣造成的，根據調查機構Gartner稱，《財富》一千家大型企業所持有的數據，有超過四分一是不準確、不完整或重複的，並預期有四分之三的大型企業直到2010年前也不會或難以改善內部數據的素質。其實沒有一家企業不受數據素質問題困擾，但就算有公司意識到問題所在，也常常會低估問題的嚴重性。何況，數據素質會受多個因素影響而變化。因此，要應付這種挑戰，一次性的行動難以奏效，企業務必持之以恆，甚至採取能改寫企業文化的行動纔會有效。
Gartner研究顯示，良莠不齊的客戶數據可造成重大損失，包括流失客戶，以及由處理直銷郵件不善和錯過銷售機會所造成的浪費等。現時很多企業亦發現劣質數據不單打擊銷售及市場推廣，更會波及最具策略性的業務活動。後勤部門的運作，例如制定預算、生產及分銷也會受到影響。
解決劣質數據問題不只只是一個IT的問題。雖然IT有助將之改善，但企業管理纔是關鍵所在，例如企業文化對數據素質就有很大的影響力。
數據治理，需要對數據的素質提出一個定義，筆者認爲數據素質涵蓋以下多方面：
ü 存在 (即企業到底有沒有某一項數據)
ü 合法性 (即該項數據的數值是否符合一個可接受的範圍)
ü 一貫性 (例如同一項數據不論儲存在哪一個地點都有同一數值)
ü 整全性 (數據元素與不同數據集之間關係的完整程度)
ü 準確性 (該項數據是否能夠描述它應表達的東西)
ü 關聯性 (該項數據能否恰當地支援業務宗旨)
ü 時間性 (即該項數據是否能夠及時地被反應出來)
針對以上數據的素質，再結合DRP系統中的相關模塊，對DRP系統中數據問題按模塊分別分析。該分析表格如下：
|
| 採購 | 訂貨 | 直營 | 門店 | 價格 | 倉儲物流 | |
| 存在 | Y | Y | Y | Y | Y | Y | Y |
| 合法性 | Y | Y | Y | Y | Y | Y | Y |
| 一貫性 | Y | Y | Y | N | N | N | Y |
| 整全性 | N | Y | Y | Y | N | Y | Y |
| 準確性 | N | N | N | N | N | N | N |
| 關聯性 | Y | Y | Y | Y | Y | N | N |
| 時間性 | N | Y | N | N | N | N | N |
以上各模塊中，達到相應的數據素質目標即爲Y，否則爲N。經過對DRP系統中的各個模塊的數據素質調查發現：數據治理主要針對的是數據的準確性、時間性、關聯性。進一步對數據事故的原因分析，發現數據出問題往往是因爲對數據的應用不夠充分。比如物流配送，根據銷售和庫存信息來做，首先銷售的信息，每天系統裏面的銷售信息和銀行回款對比，有沒有差異，沒有差異就是對的。第二，配送是根據系統去配。慢慢的精細化，以前可能是粗放的，現在是一個環節套一個環節，根據這個系統來做，慢慢數據就會越來越準確。百分之百的準確不可能，當然也沒有必要，因爲隨便一個環節都有可能出現串碼。
但如果業務部門發現DRP系統不管用，但DRP使用者就會用自己祕密地使用自己“更方便更可靠的工作流程/做法”。而管理層認爲既然沒有發生什麼不妥，也就睜一隻眼，閉一隻眼。其實，任何繞道DRP系統的工作流程/做法都會產生DRP數據流之外的“數據暗流”。這種“數據暗流”會削弱企業對流程的控制，損害企業對流程的管理和進一步優化，自然DRP系統的數據準確性就更差了。那麼，我們又怎樣保證及時數據更新和避免繞道DRP的祕密的“更方便更可靠的工作流程/做法”呢?解決方案原則上很簡單：持續提高數據準確率，定期維護訂單修訂等系統參數，以確保DRP產生的數據流與實際運作相符，通過基於DRP的工作流程的改進，禁止任何繞道DRP的行爲。
同時，借鑑了業內同行的“數據事故”分析方法，可以得到如下的因果圖：
針對上述發現的各種原因，經過進一步的統計與分析，發現主要的問題在審覈流程缺失，KPI指標設定不完善、考覈與處罰機制沒有執行、指定時間內的數據不到位、業務不熟悉、操作不當上。相反，由於系統原因造成的DRP數據錯誤很少。而像流程原因導致數據錯誤出現的次數只佔20%，但由於流程原因出現的數據錯誤影響程度最大。而像操作不當、指定時間內的數據不到位的情況出現較頻繁，但對數據錯誤的影響有限。
數據治理方案
採用上述的數據治理理論，在經過“數據事故”的教訓之後，發現上述數據問題，分別針對時間因素、流程、數據基礎、考覈機制、人員、系統制定數據治理方案，並強調方案的執行、監督、控制職能，加強各業務人員溝通，達到數據治理的目的。
考覈機制：數據治理的問題其實也是企業管理的問題，而出現問題往往是沒有一個比較好的考覈與激勵機制。在數據事故當中，出了問題之後，IT人員急着去查找原因，財務部門則因爲數據報表出不來而乾着急，而往往是事故責任部門往往是數據生產部門，而不是數據消費部門。所以，沒有好的考覈機制，往往事故在出現了之後無據可依地進行處罰，導致員工情緒極大。因此，我們定製瞭如下考覈辦法：每月結束，涉及到DRP系統中數據操作的，出現錯誤次數在5次(含5次)以上的，每次罰款10元，充入公司獎金池；如果每月操作零錯誤的，則從獎金池內獎勵30元；各部門的年度KPI指標中加入DRP系統數據操作正確率，並給予一定的權重，此舉目的就是爲了能夠使各業務部門經理引起對DRP系統數據操作正確性的重視。
人員：人員責任心不強的問題，可以由前面的考覈機制來加強，而且由於數據操作涉及到部門的績效，因此，各業務部門經理也會加強在這方面的監督；對於操作不當，業務不熟悉的情況，可以歸結爲培訓不夠。對於培訓我們分爲兩大塊：一是新員工培訓，這包括老員工調職到新崗位，新員工如果需要操作DRP系統，必須經過IT部的上崗培訓方可開設DRP系統賬號，否則的話，將無權對DRP系統進行操作；還有就是專場培訓，這也有兩類，一類是專門的計算機基礎教育培訓，這裏會包括一些計算機基礎操作，基本故障處理；另一類是公司業務流程培訓，針對各個不同崗位的人員，將公司的業務流程整合起來講，讓各業務人員知道自己上下游的業務流程是什麼？如果有異常如何處理等，同時培訓由人力資源部培訓組與IT部共同負責，所有培訓考勤、反饋、考覈情況都記入員工培訓檔案，講師則由IT部門、業務部門經理分別承擔；如果是針對各業務經理的培訓，也會請外部的流程、IT專家來擔任。
系統：系統的問題，主要通過兩方面控制：一是加強測試，所有的系統升級都必須經過公司內部的程序員測試，撰寫測試報告，經由IT經理審批之後方可將升級包更新到DRP系統中去，如果由於升級原因造成系統邏輯問題造成的數據錯誤，必須由程序員與IT經理分別承擔責任，根據每次事故的問題嚴重性，每次罰款30—300不等，同時IT部門的KPI指標中也加入系統數據事故的次數進行考覈。二是對於關鍵服務器、網絡設備的突然當機等情況的處理，這些方案可以根據IT部門的原有處置與考覈機制進行。
數據基礎：基礎數據質量差，這就是對數據生產部門提出需求，必須控制數據質量，完善公司數據規格說明，對於必須填寫的數據，由IT部門定期出具數據質量審計報告，對數據生產部門進行考覈。對於數據錄入準確率低的問題，一是採用條碼、掃描等技術手段來加強數據質量，二是通過加強人員責任心來保證，三則是通過數據審覈，下游業務流程一定要加強對數據的審覈與比對，特別是在分公司，由財務、倉管、數據員三方進行數據確認，以保證數據與業務的同步。
流程：物流是最頭痛的問題，也是處理起來最難的問題，其實關於業務流程管理(BPM)是一個很大的話題，在這裏呢，只能說是，根據企業實際情況，一點點的改進，因爲流程改進是一個傷筋動骨的事情，包括：原有流程是合適企業應用的，但現在不合適了怎麼辦？原來的流程是由某個部門負責的，現在職能要細化，要分開怎麼辦？所以在這裏就不再鋪開來講，但以後有機會進一步進行論述。
時間因素：時間因素，主要在於企業的動作效率，也是對於員工的一個考覈指標，這方面沒有太大的難度，我們主要也是將時間作爲數據生產部門的一個指標來考覈，如：計劃部門必須在訂貨單的2小時之內將訂貨單貨配發出去；專賣店如果有DRP系統，必須在當天將銷售數據傳回，如果沒有DRP系統，則傳真數據必須在當天傳回，當地辦事處必須在第二天上午11：00之前將銷售數據做到DRP系統中；客服部必須在12小時內將客戶數據錄入到DRP系統中，對於客戶的禮品申請，必須在兩個工作日內處理完畢，並給客戶回覆等。
上述所有的針對問題的解決方案都離不開執行、監督、控制與交流。在這幾個環節當中，IT部門與行政部門爲主要的執行主體，IT部門負責對DRP系統中的數據異常或每月數據質量出具報告，行政部門則根據IT部門的報告和數據質量方面的制度，給業務部門的KPI指標進行評定，也針對操作人員進行具體的獎罰；同時在培訓這一塊，由人力資源部門與IT部門負責完成。
而IT部門的系統故障及錯誤等問題，則落實到財務部與行政部具體負責進行考覈，這也就是一個監督機制，IT部門作爲DRP系統的管理者，也是要被各個業務部門進行監督的。
而由於涉及到各個業務部門的各個業務環節，特別在加入了績效考覈之後，會引起業務部門對IT部門的敵視，甚至是對DRP系統的敵視，因此，所有策略的實施都需要IT經理與數據治理項目小組的負責人加強溝通。特別是要注意循序漸進，切忌要求一步到位，否則的話引起業務部門的不滿與反彈，有可能事情會變的更糟糕。
項目管理手記(五)
DRP項目中的數據治理
由於我本人的項目經驗在DRP項目中會比較多一些，而且所談及的問題也是在DRP項目中碰到的，當然，也許我說的這個問題不只只是在DRP項目中，包括像ERP、PDM、KM等項目中都會碰上，但我還是會結合DRP項目中的實際問題來說。同時，由於本人所在的角度是甲方的角度，因此，DRP項目的週期對於甲方來說不只只是項目調研、實施、培訓，還會包括整個DRP系統的應用、部署、維護直到系統結束使用的DRP系統的整個使用週期。
DRP項目進行到後期，一般的企業都會擔心一個問題“顧問走了之後，我們怎麼辦？”。因爲如果實施顧問在現場的話，感覺都不會出什麼問題，就算有問題，顧問也解決掉了。但一旦顧問離場，DRP系統交由企業的IT部門負責運行與維護的時候，感覺問題就出的比較多了。這些問題可能會包括系統故障增多，系統運行速度減慢，軟件需求得不到響應，數據不準等。也因爲這些原因業務部門也在應用了一段時間之後感覺系統不好用了，特別是數據不準的情況經常出現，使得報表也不準了，久而久之，業務部門感覺DRP系統的價值也越來越低了，而這樣造成的直接後果就是DRP系統的使用效果打折，經常會聽到業務部門在抱怨：“這是什麼破系統嘛，出來的數據都不準!”，把數據問題與DRP系統邏輯問題相混淆，從而有可能對DRP系統本身引發了懷疑，導致DRP系統的使用週期因爲數據不準而大大縮短。
“數據事故”引發的數據治理思考
套用一句老話：“ERP是三分軟件、七分實施、十分努力、十二分數據、百分百的領導支持”。其實筆者一直在實施DRP項目的過程中，都有碰到多或多或少的數據問題，但應該都是小問題，所影響的範圍也不大，或者通過DRP系統的一些異常處理功能也就能夠解決的，如：退貨單出現的退貨價格不準確的問題，只要對這張單據進行廢除重做就好了，直到筆者碰到兩次重大的“數據事故”，纔對DRP項目的數據治理工作引發了重視與思考。
第一件事情是由於產品中心對新產品定價錯誤引發的“數據事故”。一直以來，新產品的定價是由產品中心會同財務、銷售、計劃等部門一起制定的，而且制定的是產品的零售價，然後根據零售價的折率分別倒推定製分銷價、出廠價、採購價，而採購價也是一個基準價，也就是說，產品的採購必須低於這個價格，否則的話公司是不會批准對這款產品進行投產的。在年度某季度新產品定價時，公司各部門定製出了當季產品的各種價格，並已經在系統中進行實施，但隨之而來的是，發現在市場對於當季產品的價格反映是偏高，而且代理商也認爲當季產品的分銷價格(即代理商進貨價)太高，所以公司決定對該款產品進行重新定價。隨之而來的就是要求DRP系統中對所有業務環節中的價格進行調整，包括對已經配送到分公司、代理商的產品進行重新調價，對已經配送到直營店，在倉庫中未銷售的產品進行價格調整。這一次的調整由於影響極大，導致公司各業務部門不得不集中人馬加班對數據進行調整，而且調整結束之後，在下月的系統過賬中發現財務報表總是有些出入，才發現數據調整有問題，有些調過來了，有些沒有調整過來，有些調整的時候產品已經銷售出去了，有的產品是退貨的，但成本卻沒有改過來，總之是亂的一團麻，使的該月的財務報表不得不在財務部門的要求下，各業務部門簽字覈定是由於操作不當引起的數據統計問題。本次問題其實是一個業務規範性的問題，或者是系統強壯型問題，如果業務夠規範，不會出現這種在產品進行銷售時更改產品成本的問題，或者系統足夠強壯，能夠對數據變更做出及時處理，這次事故應該也是能夠避免的。
第二件事是由於分公司內部管理、控制不到位及流程缺失導致的“數據事故”。記得當時還在外面開會，被財務總監電話催回公司，說是公司領導要求我今天準備一下，明天去華中大區出差，因爲當地分公司的本月的財務、系統數據都有嚴重問題，估計賬實不符情況嚴重，需要過去核查一下問題到底出在哪裏。第二天，當公司的財務、計劃、IT三部門人員到達華中大區所在地時，開始安排了對本大區所有的庫存盤點的工作，首先是對直營店進行盤點，全部由總部人員進行監督，經過五個晚上的盤點之後，再用了四天時間對大區的庫房進行盤點，發現：直營店的手工賬務與DRP系統中的數據不符情況嚴重，而直營店的手工賬務與實際庫存情況相差無幾，直營店也較好地執行了失貨賠償制度。而DRP系統中的數據與實際庫存嚴重不符的原因在於：大區的倉庫管理人員、數據員都沒有及時將直營店的退貨、銷售、調撥單據進行處理，以致直營店數據失真；同時對大區的庫存盤點時發現：大區的庫存結構不合理，庫存過大，直營店的過季產品處理不及時，數據員沒有對倉庫數據進行及時分析及利用。同時，大區的財務人員也沒有根據DRP系統中的數據進行財務數據覈對，以至於倉庫、數據、財務的工作脫節，形成了大區庫房管理工作出現了失控。這次事故經過審覈之後，上報到公司領導，下定決心對相關責任人進行了處罰，而也是在這次“數據事故”之後引發了筆者對於如何進行DRP系統“數據治理”的思考。
數據治理的理論及方法
項目小組總結之後，通過查找相關資料發現：數據治理其實是一種體系，是一個關注於信息系統執行層面的體系，這一體系的目的是整合IT與業務部門的知識和意見，通過一個類似於監督委員會或項目小組的虛擬組織對企業的信息化建設進行全方位的監管，這一組織的基礎是企業高層的授權和業務部門與IT部門的建設性合作。從範圍來講，數據治理涵蓋了從前端事務處理系統，後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
1. 發現：即發現問題和差異（Issues & Gaps），這是監管的基本職能。我們一定要在萌芽階段發現問題和差異，將其扼殺在苗頭。那麼如何去發現呢？
對於待建或在建的系統，要建立專家審覈制度，所謂專家包括技術專家和業務專家，如果本組織不具備條件則可以邀請第三方的顧問來參與系統數據的架構和設計決策，但根本原則是任何專家必須是相關領域的專業人士。
對於已建成使用的系統，則關鍵是IT的日常運維工作的規範化，主要包括規範的問題管理（Trouble Management），週期性審計(Periodic Review)。前者是爲了文檔化各種系統問題和缺陷，以及相應的IT判斷和響應；後者是爲了及時對系統的問題和缺陷做出歸納總結，找出規律而從根本上解決問題。
2. 監督：即持續的保持對業務數據健康狀況的跟蹤。監督主要通過週期性的數據分析來完成，市場上也有很多自動化的工具可以幫助您方便的對數據的健康狀況進行分析。與發現所不同的是，監督是主動的去發掘問題，而且在發現問題後立即採取行動去修正它。
3. 控制：即掌握信息系統建設的決策權。任何信息系統的建設、更新升級、大型變更都必須通過數據治理項目小組的審批，極端情況下甚至可以考慮任何數據變更都必須審批。集中化的控制的好處是，首先可以集中技術和業務相關領域的專家的意見，其次可以限制執行層面的IT人員和業務人員的隨意性、不嚴謹性，再次向監管層提供了從全局和長遠的角度看系統的機會。
4. 交流：即溝通，是跨部門的跨領域的溝通。對傳統IT的最大挑戰就是跨組織跨領域的溝通交流，而數據治理委員會這樣一個跨越了IT部門和業務部門的虛擬組織，通過建立例行的交流機制，保證了信息在整個組織範圍內的透明，這種透明性保證了所有參與者的步調一致的，保證了業務數據的一致性。交流滲透在前面所述的四點數據治理活動中，是它們成功的保障。
5. 整合：這是我們的目標同時也是解決之道，主要抓住三個方面的整合——信息的整合，資源的整合，能力的整合。通過信息的整合把分散的業務數據整合到一個一致的沒有歧義的體系中來；通過資源的整合把企業IT資源集中調配；通過能力的整合，將平臺的運算能力，業務數據處理能力集中管理，建立一種集中服務的模式，即提高了硬件利用率、人員工作效率又利於IT對各業務部門服務的成本覈算。
“數據事故”分析
爲了解決數據事故問題，筆者協調財務、計劃、銷售、IT等部門成立了專門的“數據治理”項目小組。數據事故，應該是由於數據的素質低劣造成的，根據調查機構Gartner稱，《財富》一千家大型企業所持有的數據，有超過四分一是不準確、不完整或重複的，並預期有四分之三的大型企業直到2010年前也不會或難以改善內部數據的素質。其實沒有一家企業不受數據素質問題困擾，但就算有公司意識到問題所在，也常常會低估問題的嚴重性。何況，數據素質會受多個因素影響而變化。因此，要應付這種挑戰，一次性的行動難以奏效，企業務必持之以恆，甚至採取能改寫企業文化的行動纔會有效。
Gartner研究顯示，良莠不齊的客戶數據可造成重大損失，包括流失客戶，以及由處理直銷郵件不善和錯過銷售機會所造成的浪費等。現時很多企業亦發現劣質數據不單打擊銷售及市場推廣，更會波及最具策略性的業務活動。後勤部門的運作，例如制定預算、生產及分銷也會受到影響。
解決劣質數據問題不只只是一個IT的問題。雖然IT有助將之改善，但企業管理纔是關鍵所在，例如企業文化對數據素質就有很大的影響力。
數據治理，需要對數據的素質提出一個定義，筆者認爲數據素質涵蓋以下多方面：
ü 存在 (即企業到底有沒有某一項數據)
ü 合法性 (即該項數據的數值是否符合一個可接受的範圍)
ü 一貫性 (例如同一項數據不論儲存在哪一個地點都有同一數值)
ü 整全性 (數據元素與不同數據集之間關係的完整程度)
ü 準確性 (該項數據是否能夠描述它應表達的東西)
ü 關聯性 (該項數據能否恰當地支援業務宗旨)
ü 時間性 (即該項數據是否能夠及時地被反應出來)
針對以上數據的素質，再結合DRP系統中的相關模塊，對DRP系統中數據問題按模塊分別分析。該分析表格如下：
|
| 採購 | 訂貨 | 直營 | 門店 | 價格 | 倉儲物流 | |
| 存在 | Y | Y | Y | Y | Y | Y | Y |
| 合法性 | Y | Y | Y | Y | Y | Y | Y |
| 一貫性 | Y | Y | Y | N | N | N | Y |
| 整全性 | N | Y | Y | Y | N | Y | Y |
| 準確性 | N | N | N | N | N | N | N |
| 關聯性 | Y | Y | Y | Y | Y | N | N |
| 時間性 | N | Y | N | N | N | N | N |
以上各模塊中，達到相應的數據素質目標即爲Y，否則爲N。經過對DRP系統中的各個模塊的數據素質調查發現：數據治理主要針對的是數據的準確性、時間性、關聯性。進一步對數據事故的原因分析，發現數據出問題往往是因爲對數據的應用不夠充分。比如物流配送，根據銷售和庫存信息來做，首先銷售的信息，每天系統裏面的銷售信息和銀行回款對比，有沒有差異，沒有差異就是對的。第二，配送是根據系統去配。慢慢的精細化，以前可能是粗放的，現在是一個環節套一個環節，根據這個系統來做，慢慢數據就會越來越準確。百分之百的準確不可能，當然也沒有必要，因爲隨便一個環節都有可能出現串碼。
但如果業務部門發現DRP系統不管用，但DRP使用者就會用自己祕密地使用自己“更方便更可靠的工作流程/做法”。而管理層認爲既然沒有發生什麼不妥，也就睜一隻眼，閉一隻眼。其實，任何繞道DRP系統的工作流程/做法都會產生DRP數據流之外的“數據暗流”。這種“數據暗流”會削弱企業對流程的控制，損害企業對流程的管理和進一步優化，自然DRP系統的數據準確性就更差了。那麼，我們又怎樣保證及時數據更新和避免繞道DRP的祕密的“更方便更可靠的工作流程/做法”呢?解決方案原則上很簡單：持續提高數據準確率，定期維護訂單修訂等系統參數，以確保DRP產生的數據流與實際運作相符，通過基於DRP的工作流程的改進，禁止任何繞道DRP的行爲。
同時，借鑑了業內同行的“數據事故”分析方法，可以得到如下的因果圖：
針對上述發現的各種原因，經過進一步的統計與分析，發現主要的問題在審覈流程缺失，KPI指標設定不完善、考覈與處罰機制沒有執行、指定時間內的數據不到位、業務不熟悉、操作不當上。相反，由於系統原因造成的DRP數據錯誤很少。而像流程原因導致數據錯誤出現的次數只佔20%，但由於流程原因出現的數據錯誤影響程度最大。而像操作不當、指定時間內的數據不到位的情況出現較頻繁，但對數據錯誤的影響有限。
數據治理方案
採用上述的數據治理理論，在經過“數據事故”的教訓之後，發現上述數據問題，分別針對時間因素、流程、數據基礎、考覈機制、人員、系統制定數據治理方案，並強調方案的執行、監督、控制職能，加強各業務人員溝通，達到數據治理的目的。
考覈機制：數據治理的問題其實也是企業管理的問題，而出現問題往往是沒有一個比較好的考覈與激勵機制。在數據事故當中，出了問題之後，IT人員急着去查找原因，財務部門則因爲數據報表出不來而乾着急，而往往是事故責任部門往往是數據生產部門，而不是數據消費部門。所以，沒有好的考覈機制，往往事故在出現了之後無據可依地進行處罰，導致員工情緒極大。因此，我們定製瞭如下考覈辦法：每月結束，涉及到DRP系統中數據操作的，出現錯誤次數在5次(含5次)以上的，每次罰款10元，充入公司獎金池；如果每月操作零錯誤的，則從獎金池內獎勵30元；各部門的年度KPI指標中加入DRP系統數據操作正確率，並給予一定的權重，此舉目的就是爲了能夠使各業務部門經理引起對DRP系統數據操作正確性的重視。
人員：人員責任心不強的問題，可以由前面的考覈機制來加強，而且由於數據操作涉及到部門的績效，因此，各業務部門經理也會加強在這方面的監督；對於操作不當，業務不熟悉的情況，可以歸結爲培訓不夠。對於培訓我們分爲兩大塊：一是新員工培訓，這包括老員工調職到新崗位，新員工如果需要操作DRP系統，必須經過IT部的上崗培訓方可開設DRP系統賬號，否則的話，將無權對DRP系統進行操作；還有就是專場培訓，這也有兩類，一類是專門的計算機基礎教育培訓，這裏會包括一些計算機基礎操作，基本故障處理；另一類是公司業務流程培訓，針對各個不同崗位的人員，將公司的業務流程整合起來講，讓各業務人員知道自己上下游的業務流程是什麼？如果有異常如何處理等，同時培訓由人力資源部培訓組與IT部共同負責，所有培訓考勤、反饋、考覈情況都記入員工培訓檔案，講師則由IT部門、業務部門經理分別承擔；如果是針對各業務經理的培訓，也會請外部的流程、IT專家來擔任。
系統：系統的問題，主要通過兩方面控制：一是加強測試，所有的系統升級都必須經過公司內部的程序員測試，撰寫測試報告，經由IT經理審批之後方可將升級包更新到DRP系統中去，如果由於升級原因造成系統邏輯問題造成的數據錯誤，必須由程序員與IT經理分別承擔責任，根據每次事故的問題嚴重性，每次罰款30—300不等，同時IT部門的KPI指標中也加入系統數據事故的次數進行考覈。二是對於關鍵服務器、網絡設備的突然當機等情況的處理，這些方案可以根據IT部門的原有處置與考覈機制進行。
數據基礎：基礎數據質量差，這就是對數據生產部門提出需求，必須控制數據質量，完善公司數據規格說明，對於必須填寫的數據，由IT部門定期出具數據質量審計報告，對數據生產部門進行考覈。對於數據錄入準確率低的問題，一是採用條碼、掃描等技術手段來加強數據質量，二是通過加強人員責任心來保證，三則是通過數據審覈，下游業務流程一定要加強對數據的審覈與比對，特別是在分公司，由財務、倉管、數據員三方進行數據確認，以保證數據與業務的同步。
流程：物流是最頭痛的問題，也是處理起來最難的問題，其實關於業務流程管理(BPM)是一個很大的話題，在這裏呢，只能說是，根據企業實際情況，一點點的改進，因爲流程改進是一個傷筋動骨的事情，包括：原有流程是合適企業應用的，但現在不合適了怎麼辦？原來的流程是由某個部門負責的，現在職能要細化，要分開怎麼辦？所以在這裏就不再鋪開來講，但以後有機會進一步進行論述。
時間因素：時間因素，主要在於企業的動作效率，也是對於員工的一個考覈指標，這方面沒有太大的難度，我們主要也是將時間作爲數據生產部門的一個指標來考覈，如：計劃部門必須在訂貨單的2小時之內將訂貨單貨配發出去；專賣店如果有DRP系統，必須在當天將銷售數據傳回，如果沒有DRP系統，則傳真數據必須在當天傳回，當地辦事處必須在第二天上午11：00之前將銷售數據做到DRP系統中；客服部必須在12小時內將客戶數據錄入到DRP系統中，對於客戶的禮品申請，必須在兩個工作日內處理完畢，並給客戶回覆等。
上述所有的針對問題的解決方案都離不開執行、監督、控制與交流。在這幾個環節當中，IT部門與行政部門爲主要的執行主體，IT部門負責對DRP系統中的數據異常或每月數據質量出具報告，行政部門則根據IT部門的報告和數據質量方面的制度，給業務部門的KPI指標進行評定，也針對操作人員進行具體的獎罰；同時在培訓這一塊，由人力資源部門與IT部門負責完成。
而IT部門的系統故障及錯誤等問題，則落實到財務部與行政部具體負責進行考覈，這也就是一個監督機制，IT部門作爲DRP系統的管理者，也是要被各個業務部門進行監督的。
而由於涉及到各個業務部門的各個業務環節，特別在加入了績效考覈之後，會引起業務部門對IT部門的敵視，甚至是對DRP系統的敵視，因此，所有策略的實施都需要IT經理與數據治理項目小組的負責人加強溝通。特別是要注意循序漸進，切忌要求一步到位，否則的話引起業務部門的不滿與反彈，有可能事情會變的更糟糕。
項目管理手記(五)
DRP項目中的數據治理
由於我本人的項目經驗在DRP項目中會比較多一些，而且所談及的問題也是在DRP項目中碰到的，當然，也許我說的這個問題不只只是在DRP項目中，包括像ERP、PDM、KM等項目中都會碰上，但我還是會結合DRP項目中的實際問題來說。同時，由於本人所在的角度是甲方的角度，因此，DRP項目的週期對於甲方來說不只只是項目調研、實施、培訓，還會包括整個DRP系統的應用、部署、維護直到系統結束使用的DRP系統的整個使用週期。
DRP項目進行到後期，一般的企業都會擔心一個問題“顧問走了之後，我們怎麼辦？”。因爲如果實施顧問在現場的話，感覺都不會出什麼問題，就算有問題，顧問也解決掉了。但一旦顧問離場，DRP系統交由企業的IT部門負責運行與維護的時候，感覺問題就出的比較多了。這些問題可能會包括系統故障增多，系統運行速度減慢，軟件需求得不到響應，數據不準等。也因爲這些原因業務部門也在應用了一段時間之後感覺系統不好用了，特別是數據不準的情況經常出現，使得報表也不準了，久而久之，業務部門感覺DRP系統的價值也越來越低了，而這樣造成的直接後果就是DRP系統的使用效果打折，經常會聽到業務部門在抱怨：“這是什麼破系統嘛，出來的數據都不準!”，把數據問題與DRP系統邏輯問題相混淆，從而有可能對DRP系統本身引發了懷疑，導致DRP系統的使用週期因爲數據不準而大大縮短。
“數據事故”引發的數據治理思考
套用一句老話：“ERP是三分軟件、七分實施、十分努力、十二分數據、百分百的領導支持”。其實筆者一直在實施DRP項目的過程中，都有碰到多或多或少的數據問題，但應該都是小問題，所影響的範圍也不大，或者通過DRP系統的一些異常處理功能也就能夠解決的，如：退貨單出現的退貨價格不準確的問題，只要對這張單據進行廢除重做就好了，直到筆者碰到兩次重大的“數據事故”，纔對DRP項目的數據治理工作引發了重視與思考。
第一件事情是由於產品中心對新產品定價錯誤引發的“數據事故”。一直以來，新產品的定價是由產品中心會同財務、銷售、計劃等部門一起制定的，而且制定的是產品的零售價，然後根據零售價的折率分別倒推定製分銷價、出廠價、採購價，而採購價也是一個基準價，也就是說，產品的採購必須低於這個價格，否則的話公司是不會批准對這款產品進行投產的。在年度某季度新產品定價時，公司各部門定製出了當季產品的各種價格，並已經在系統中進行實施，但隨之而來的是，發現在市場對於當季產品的價格反映是偏高，而且代理商也認爲當季產品的分銷價格(即代理商進貨價)太高，所以公司決定對該款產品進行重新定價。隨之而來的就是要求DRP系統中對所有業務環節中的價格進行調整，包括對已經配送到分公司、代理商的產品進行重新調價，對已經配送到直營店，在倉庫中未銷售的產品進行價格調整。這一次的調整由於影響極大，導致公司各業務部門不得不集中人馬加班對數據進行調整，而且調整結束之後，在下月的系統過賬中發現財務報表總是有些出入，才發現數據調整有問題，有些調過來了，有些沒有調整過來，有些調整的時候產品已經銷售出去了，有的產品是退貨的，但成本卻沒有改過來，總之是亂的一團麻，使的該月的財務報表不得不在財務部門的要求下，各業務部門簽字覈定是由於操作不當引起的數據統計問題。本次問題其實是一個業務規範性的問題，或者是系統強壯型問題，如果業務夠規範，不會出現這種在產品進行銷售時更改產品成本的問題，或者系統足夠強壯，能夠對數據變更做出及時處理，這次事故應該也是能夠避免的。
第二件事是由於分公司內部管理、控制不到位及流程缺失導致的“數據事故”。記得當時還在外面開會，被財務總監電話催回公司，說是公司領導要求我今天準備一下，明天去華中大區出差，因爲當地分公司的本月的財務、系統數據都有嚴重問題，估計賬實不符情況嚴重，需要過去核查一下問題到底出在哪裏。第二天，當公司的財務、計劃、IT三部門人員到達華中大區所在地時，開始安排了對本大區所有的庫存盤點的工作，首先是對直營店進行盤點，全部由總部人員進行監督，經過五個晚上的盤點之後，再用了四天時間對大區的庫房進行盤點，發現：直營店的手工賬務與DRP系統中的數據不符情況嚴重，而直營店的手工賬務與實際庫存情況相差無幾，直營店也較好地執行了失貨賠償制度。而DRP系統中的數據與實際庫存嚴重不符的原因在於：大區的倉庫管理人員、數據員都沒有及時將直營店的退貨、銷售、調撥單據進行處理，以致直營店數據失真；同時對大區的庫存盤點時發現：大區的庫存結構不合理，庫存過大，直營店的過季產品處理不及時，數據員沒有對倉庫數據進行及時分析及利用。同時，大區的財務人員也沒有根據DRP系統中的數據進行財務數據覈對，以至於倉庫、數據、財務的工作脫節，形成了大區庫房管理工作出現了失控。這次事故經過審覈之後，上報到公司領導，下定決心對相關責任人進行了處罰，而也是在這次“數據事故”之後引發了筆者對於如何進行DRP系統“數據治理”的思考。
數據治理的理論及方法
項目小組總結之後，通過查找相關資料發現：數據治理其實是一種體系，是一個關注於信息系統執行層面的體系，這一體系的目的是整合IT與業務部門的知識和意見，通過一個類似於監督委員會或項目小組的虛擬組織對企業的信息化建設進行全方位的監管，這一組織的基礎是企業高層的授權和業務部門與IT部門的建設性合作。從範圍來講，數據治理涵蓋了從前端事務處理系統，後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
1. 發現：即發現問題和差異（Issues & Gaps），這是監管的基本職能。我們一定要在萌芽階段發現問題和差異，將其扼殺在苗頭。那麼如何去發現呢？
對於待建或在建的系統，要建立專家審覈制度，所謂專家包括技術專家和業務專家，如果本組織不具備條件則可以邀請第三方的顧問來參與系統數據的架構和設計決策，但根本原則是任何專家必須是相關領域的專業人士。
對於已建成使用的系統，則關鍵是IT的日常運維工作的規範化，主要包括規範的問題管理（Trouble Management），週期性審計(Periodic Review)。前者是爲了文檔化各種系統問題和缺陷，以及相應的IT判斷和響應；後者是爲了及時對系統的問題和缺陷做出歸納總結，找出規律而從根本上解決問題。
2. 監督：即持續的保持對業務數據健康狀況的跟蹤。監督主要通過週期性的數據分析來完成，市場上也有很多自動化的工具可以幫助您方便的對數據的健康狀況進行分析。與發現所不同的是，監督是主動的去發掘問題，而且在發現問題後立即採取行動去修正它。
3. 控制：即掌握信息系統建設的決策權。任何信息系統的建設、更新升級、大型變更都必須通過數據治理項目小組的審批，極端情況下甚至可以考慮任何數據變更都必須審批。集中化的控制的好處是，首先可以集中技術和業務相關領域的專家的意見，其次可以限制執行層面的IT人員和業務人員的隨意性、不嚴謹性，再次向監管層提供了從全局和長遠的角度看系統的機會。
4. 交流：即溝通，是跨部門的跨領域的溝通。對傳統IT的最大挑戰就是跨組織跨領域的溝通交流，而數據治理委員會這樣一個跨越了IT部門和業務部門的虛擬組織，通過建立例行的交流機制，保證了信息在整個組織範圍內的透明，這種透明性保證了所有參與者的步調一致的，保證了業務數據的一致性。交流滲透在前面所述的四點數據治理活動中，是它們成功的保障。
5. 整合：這是我們的目標同時也是解決之道，主要抓住三個方面的整合——信息的整合，資源的整合，能力的整合。通過信息的整合把分散的業務數據整合到一個一致的沒有歧義的體系中來；通過資源的整合把企業IT資源集中調配；通過能力的整合，將平臺的運算能力，業務數據處理能力集中管理，建立一種集中服務的模式，即提高了硬件利用率、人員工作效率又利於IT對各業務部門服務的成本覈算。
“數據事故”分析
爲了解決數據事故問題，筆者協調財務、計劃、銷售、IT等部門成立了專門的“數據治理”項目小組。數據事故，應該是由於數據的素質低劣造成的，根據調查機構Gartner稱，《財富》一千家大型企業所持有的數據，有超過四分一是不準確、不完整或重複的，並預期有四分之三的大型企業直到2010年前也不會或難以改善內部數據的素質。其實沒有一家企業不受數據素質問題困擾，但就算有公司意識到問題所在，也常常會低估問題的嚴重性。何況，數據素質會受多個因素影響而變化。因此，要應付這種挑戰，一次性的行動難以奏效，企業務必持之以恆，甚至採取能改寫企業文化的行動纔會有效。
Gartner研究顯示，良莠不齊的客戶數據可造成重大損失，包括流失客戶，以及由處理直銷郵件不善和錯過銷售機會所造成的浪費等。現時很多企業亦發現劣質數據不單打擊銷售及市場推廣，更會波及最具策略性的業務活動。後勤部門的運作，例如制定預算、生產及分銷也會受到影響。
解決劣質數據問題不只只是一個IT的問題。雖然IT有助將之改善，但企業管理纔是關鍵所在，例如企業文化對數據素質就有很大的影響力。
數據治理，需要對數據的素質提出一個定義，筆者認爲數據素質涵蓋以下多方面：
ü 存在 (即企業到底有沒有某一項數據)
ü 合法性 (即該項數據的數值是否符合一個可接受的範圍)
ü 一貫性 (例如同一項數據不論儲存在哪一個地點都有同一數值)
ü 整全性 (數據元素與不同數據集之間關係的完整程度)
ü 準確性 (該項數據是否能夠描述它應表達的東西)
ü 關聯性 (該項數據能否恰當地支援業務宗旨)
ü 時間性 (即該項數據是否能夠及時地被反應出來)
針對以上數據的素質，再結合DRP系統中的相關模塊，對DRP系統中數據問題按模塊分別分析。該分析表格如下：
|
| 採購 | 訂貨 | 直營 | 門店 | 價格 | 倉儲物流 | |
| 存在 | Y | Y | Y | Y | Y | Y | Y |
| 合法性 | Y | Y | Y | Y | Y | Y | Y |
| 一貫性 | Y | Y | Y | N | N | N | Y |
| 整全性 | N | Y | Y | Y | N | Y | Y |
| 準確性 | N | N | N | N | N | N | N |
| 關聯性 | Y | Y | Y | Y | Y | N | N |
| 時間性 | N | Y | N | N | N | N | N |
以上各模塊中，達到相應的數據素質目標即爲Y，否則爲N。經過對DRP系統中的各個模塊的數據素質調查發現：數據治理主要針對的是數據的準確性、時間性、關聯性。進一步對數據事故的原因分析，發現數據出問題往往是因爲對數據的應用不夠充分。比如物流配送，根據銷售和庫存信息來做，首先銷售的信息，每天系統裏面的銷售信息和銀行回款對比，有沒有差異，沒有差異就是對的。第二，配送是根據系統去配。慢慢的精細化，以前可能是粗放的，現在是一個環節套一個環節，根據這個系統來做，慢慢數據就會越來越準確。百分之百的準確不可能，當然也沒有必要，因爲隨便一個環節都有可能出現串碼。
但如果業務部門發現DRP系統不管用，但DRP使用者就會用自己祕密地使用自己“更方便更可靠的工作流程/做法”。而管理層認爲既然沒有發生什麼不妥，也就睜一隻眼，閉一隻眼。其實，任何繞道DRP系統的工作流程/做法都會產生DRP數據流之外的“數據暗流”。這種“數據暗流”會削弱企業對流程的控制，損害企業對流程的管理和進一步優化，自然DRP系統的數據準確性就更差了。那麼，我們又怎樣保證及時數據更新和避免繞道DRP的祕密的“更方便更可靠的工作流程/做法”呢?解決方案原則上很簡單：持續提高數據準確率，定期維護訂單修訂等系統參數，以確保DRP產生的數據流與實際運作相符，通過基於DRP的工作流程的改進，禁止任何繞道DRP的行爲。
同時，借鑑了業內同行的“數據事故”分析方法，可以得到如下的因果圖：
針對上述發現的各種原因，經過進一步的統計與分析，發現主要的問題在審覈流程缺失，KPI指標設定不完善、考覈與處罰機制沒有執行、指定時間內的數據不到位、業務不熟悉、操作不當上。相反，由於系統原因造成的DRP數據錯誤很少。而像流程原因導致數據錯誤出現的次數只佔20%，但由於流程原因出現的數據錯誤影響程度最大。而像操作不當、指定時間內的數據不到位的情況出現較頻繁，但對數據錯誤的影響有限。
數據治理方案
採用上述的數據治理理論，在經過“數據事故”的教訓之後，發現上述數據問題，分別針對時間因素、流程、數據基礎、考覈機制、人員、系統制定數據治理方案，並強調方案的執行、監督、控制職能，加強各業務人員溝通，達到數據治理的目的。
考覈機制：數據治理的問題其實也是企業管理的問題，而出現問題往往是沒有一個比較好的考覈與激勵機制。在數據事故當中，出了問題之後，IT人員急着去查找原因，財務部門則因爲數據報表出不來而乾着急，而往往是事故責任部門往往是數據生產部門，而不是數據消費部門。所以，沒有好的考覈機制，往往事故在出現了之後無據可依地進行處罰，導致員工情緒極大。因此，我們定製瞭如下考覈辦法：每月結束，涉及到DRP系統中數據操作的，出現錯誤次數在5次(含5次)以上的，每次罰款10元，充入公司獎金池；如果每月操作零錯誤的，則從獎金池內獎勵30元；各部門的年度KPI指標中加入DRP系統數據操作正確率，並給予一定的權重，此舉目的就是爲了能夠使各業務部門經理引起對DRP系統數據操作正確性的重視。
人員：人員責任心不強的問題，可以由前面的考覈機制來加強，而且由於數據操作涉及到部門的績效，因此，各業務部門經理也會加強在這方面的監督；對於操作不當，業務不熟悉的情況，可以歸結爲培訓不夠。對於培訓我們分爲兩大塊：一是新員工培訓，這包括老員工調職到新崗位，新員工如果需要操作DRP系統，必須經過IT部的上崗培訓方可開設DRP系統賬號，否則的話，將無權對DRP系統進行操作；還有就是專場培訓，這也有兩類，一類是專門的計算機基礎教育培訓，這裏會包括一些計算機基礎操作，基本故障處理；另一類是公司業務流程培訓，針對各個不同崗位的人員，將公司的業務流程整合起來講，讓各業務人員知道自己上下游的業務流程是什麼？如果有異常如何處理等，同時培訓由人力資源部培訓組與IT部共同負責，所有培訓考勤、反饋、考覈情況都記入員工培訓檔案，講師則由IT部門、業務部門經理分別承擔；如果是針對各業務經理的培訓，也會請外部的流程、IT專家來擔任。
系統：系統的問題，主要通過兩方面控制：一是加強測試，所有的系統升級都必須經過公司內部的程序員測試，撰寫測試報告，經由IT經理審批之後方可將升級包更新到DRP系統中去，如果由於升級原因造成系統邏輯問題造成的數據錯誤，必須由程序員與IT經理分別承擔責任，根據每次事故的問題嚴重性，每次罰款30—300不等，同時IT部門的KPI指標中也加入系統數據事故的次數進行考覈。二是對於關鍵服務器、網絡設備的突然當機等情況的處理，這些方案可以根據IT部門的原有處置與考覈機制進行。
數據基礎：基礎數據質量差，這就是對數據生產部門提出需求，必須控制數據質量，完善公司數據規格說明，對於必須填寫的數據，由IT部門定期出具數據質量審計報告，對數據生產部門進行考覈。對於數據錄入準確率低的問題，一是採用條碼、掃描等技術手段來加強數據質量，二是通過加強人員責任心來保證，三則是通過數據審覈，下游業務流程一定要加強對數據的審覈與比對，特別是在分公司，由財務、倉管、數據員三方進行數據確認，以保證數據與業務的同步。
流程：物流是最頭痛的問題，也是處理起來最難的問題，其實關於業務流程管理(BPM)是一個很大的話題，在這裏呢，只能說是，根據企業實際情況，一點點的改進，因爲流程改進是一個傷筋動骨的事情，包括：原有流程是合適企業應用的，但現在不合適了怎麼辦？原來的流程是由某個部門負責的，現在職能要細化，要分開怎麼辦？所以在這裏就不再鋪開來講，但以後有機會進一步進行論述。
時間因素：時間因素，主要在於企業的動作效率，也是對於員工的一個考覈指標，這方面沒有太大的難度，我們主要也是將時間作爲數據生產部門的一個指標來考覈，如：計劃部門必須在訂貨單的2小時之內將訂貨單貨配發出去；專賣店如果有DRP系統，必須在當天將銷售數據傳回，如果沒有DRP系統，則傳真數據必須在當天傳回，當地辦事處必須在第二天上午11：00之前將銷售數據做到DRP系統中；客服部必須在12小時內將客戶數據錄入到DRP系統中，對於客戶的禮品申請，必須在兩個工作日內處理完畢，並給客戶回覆等。
上述所有的針對問題的解決方案都離不開執行、監督、控制與交流。在這幾個環節當中，IT部門與行政部門爲主要的執行主體，IT部門負責對DRP系統中的數據異常或每月數據質量出具報告，行政部門則根據IT部門的報告和數據質量方面的制度，給業務部門的KPI指標進行評定，也針對操作人員進行具體的獎罰；同時在培訓這一塊，由人力資源部門與IT部門負責完成。
而IT部門的系統故障及錯誤等問題，則落實到財務部與行政部具體負責進行考覈，這也就是一個監督機制，IT部門作爲DRP系統的管理者，也是要被各個業務部門進行監督的。
而由於涉及到各個業務部門的各個業務環節，特別在加入了績效考覈之後，會引起業務部門對IT部門的敵視，甚至是對DRP系統的敵視，因此，所有策略的實施都需要IT經理與數據治理項目小組的負責人加強溝通。特別是要注意循序漸進，切忌要求一步到位，否則的話引起業務部門的不滿與反彈，有可能事情會變的更糟糕。
項目管理手記(五)
DRP項目中的數據治理
由於我本人的項目經驗在DRP項目中會比較多一些，而且所談及的問題也是在DRP項目中碰到的，當然，也許我說的這個問題不只只是在DRP項目中，包括像ERP、PDM、KM等項目中都會碰上，但我還是會結合DRP項目中的實際問題來說。同時，由於本人所在的角度是甲方的角度，因此，DRP項目的週期對於甲方來說不只只是項目調研、實施、培訓，還會包括整個DRP系統的應用、部署、維護直到系統結束使用的DRP系統的整個使用週期。
DRP項目進行到後期，一般的企業都會擔心一個問題“顧問走了之後，我們怎麼辦？”。因爲如果實施顧問在現場的話，感覺都不會出什麼問題，就算有問題，顧問也解決掉了。但一旦顧問離場，DRP系統交由企業的IT部門負責運行與維護的時候，感覺問題就出的比較多了。這些問題可能會包括系統故障增多，系統運行速度減慢，軟件需求得不到響應，數據不準等。也因爲這些原因業務部門也在應用了一段時間之後感覺系統不好用了，特別是數據不準的情況經常出現，使得報表也不準了，久而久之，業務部門感覺DRP系統的價值也越來越低了，而這樣造成的直接後果就是DRP系統的使用效果打折，經常會聽到業務部門在抱怨：“這是什麼破系統嘛，出來的數據都不準!”，把數據問題與DRP系統邏輯問題相混淆，從而有可能對DRP系統本身引發了懷疑，導致DRP系統的使用週期因爲數據不準而大大縮短。
“數據事故”引發的數據治理思考
套用一句老話：“ERP是三分軟件、七分實施、十分努力、十二分數據、百分百的領導支持”。其實筆者一直在實施DRP項目的過程中，都有碰到多或多或少的數據問題，但應該都是小問題，所影響的範圍也不大，或者通過DRP系統的一些異常處理功能也就能夠解決的，如：退貨單出現的退貨價格不準確的問題，只要對這張單據進行廢除重做就好了，直到筆者碰到兩次重大的“數據事故”，纔對DRP項目的數據治理工作引發了重視與思考。
第一件事情是由於產品中心對新產品定價錯誤引發的“數據事故”。一直以來，新產品的定價是由產品中心會同財務、銷售、計劃等部門一起制定的，而且制定的是產品的零售價，然後根據零售價的折率分別倒推定製分銷價、出廠價、採購價，而採購價也是一個基準價，也就是說，產品的採購必須低於這個價格，否則的話公司是不會批准對這款產品進行投產的。在年度某季度新產品定價時，公司各部門定製出了當季產品的各種價格，並已經在系統中進行實施，但隨之而來的是，發現在市場對於當季產品的價格反映是偏高，而且代理商也認爲當季產品的分銷價格(即代理商進貨價)太高，所以公司決定對該款產品進行重新定價。隨之而來的就是要求DRP系統中對所有業務環節中的價格進行調整，包括對已經配送到分公司、代理商的產品進行重新調價，對已經配送到直營店，在倉庫中未銷售的產品進行價格調整。這一次的調整由於影響極大，導致公司各業務部門不得不集中人馬加班對數據進行調整，而且調整結束之後，在下月的系統過賬中發現財務報表總是有些出入，才發現數據調整有問題，有些調過來了，有些沒有調整過來，有些調整的時候產品已經銷售出去了，有的產品是退貨的，但成本卻沒有改過來，總之是亂的一團麻，使的該月的財務報表不得不在財務部門的要求下，各業務部門簽字覈定是由於操作不當引起的數據統計問題。本次問題其實是一個業務規範性的問題，或者是系統強壯型問題，如果業務夠規範，不會出現這種在產品進行銷售時更改產品成本的問題，或者系統足夠強壯，能夠對數據變更做出及時處理，這次事故應該也是能夠避免的。
第二件事是由於分公司內部管理、控制不到位及流程缺失導致的“數據事故”。記得當時還在外面開會，被財務總監電話催回公司，說是公司領導要求我今天準備一下，明天去華中大區出差，因爲當地分公司的本月的財務、系統數據都有嚴重問題，估計賬實不符情況嚴重，需要過去核查一下問題到底出在哪裏。第二天，當公司的財務、計劃、IT三部門人員到達華中大區所在地時，開始安排了對本大區所有的庫存盤點的工作，首先是對直營店進行盤點，全部由總部人員進行監督，經過五個晚上的盤點之後，再用了四天時間對大區的庫房進行盤點，發現：直營店的手工賬務與DRP系統中的數據不符情況嚴重，而直營店的手工賬務與實際庫存情況相差無幾，直營店也較好地執行了失貨賠償制度。而DRP系統中的數據與實際庫存嚴重不符的原因在於：大區的倉庫管理人員、數據員都沒有及時將直營店的退貨、銷售、調撥單據進行處理，以致直營店數據失真；同時對大區的庫存盤點時發現：大區的庫存結構不合理，庫存過大，直營店的過季產品處理不及時，數據員沒有對倉庫數據進行及時分析及利用。同時，大區的財務人員也沒有根據DRP系統中的數據進行財務數據覈對，以至於倉庫、數據、財務的工作脫節，形成了大區庫房管理工作出現了失控。這次事故經過審覈之後，上報到公司領導，下定決心對相關責任人進行了處罰，而也是在這次“數據事故”之後引發了筆者對於如何進行DRP系統“數據治理”的思考。
數據治理的理論及方法
項目小組總結之後，通過查找相關資料發現：數據治理其實是一種體系，是一個關注於信息系統執行層面的體系，這一體系的目的是整合IT與業務部門的知識和意見，通過一個類似於監督委員會或項目小組的虛擬組織對企業的信息化建設進行全方位的監管，這一組織的基礎是企業高層的授權和業務部門與IT部門的建設性合作。從範圍來講，數據治理涵蓋了從前端事務處理系統，後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
1. 發現：即發現問題和差異（Issues & Gaps），這是監管的基本職能。我們一定要在萌芽階段發現問題和差異，將其扼殺在苗頭。那麼如何去發現呢？
對於待建或在建的系統，要建立專家審覈制度，所謂專家包括技術專家和業務專家，如果本組織不具備條件則可以邀請第三方的顧問來參與系統數據的架構和設計決策，但根本原則是任何專家必須是相關領域的專業人士。
對於已建成使用的系統，則關鍵是IT的日常運維工作的規範化，主要包括規範的問題管理（Trouble Management），週期性審計(Periodic Review)。前者是爲了文檔化各種系統問題和缺陷，以及相應的IT判斷和響應；後者是爲了及時對系統的問題和缺陷做出歸納總結，找出規律而從根本上解決問題。
2. 監督：即持續的保持對業務數據健康狀況的跟蹤。監督主要通過週期性的數據分析來完成，市場上也有很多自動化的工具可以幫助您方便的對數據的健康狀況進行分析。與發現所不同的是，監督是主動的去發掘問題，而且在發現問題後立即採取行動去修正它。
3. 控制：即掌握信息系統建設的決策權。任何信息系統的建設、更新升級、大型變更都必須通過數據治理項目小組的審批，極端情況下甚至可以考慮任何數據變更都必須審批。集中化的控制的好處是，首先可以集中技術和業務相關領域的專家的意見，其次可以限制執行層面的IT人員和業務人員的隨意性、不嚴謹性，再次向監管層提供了從全局和長遠的角度看系統的機會。
4. 交流：即溝通，是跨部門的跨領域的溝通。對傳統IT的最大挑戰就是跨組織跨領域的溝通交流，而數據治理委員會這樣一個跨越了IT部門和業務部門的虛擬組織，通過建立例行的交流機制，保證了信息在整個組織範圍內的透明，這種透明性保證了所有參與者的步調一致的，保證了業務數據的一致性。交流滲透在前面所述的四點數據治理活動中，是它們成功的保障。
5. 整合：這是我們的目標同時也是解決之道，主要抓住三個方面的整合——信息的整合，資源的整合，能力的整合。通過信息的整合把分散的業務數據整合到一個一致的沒有歧義的體系中來；通過資源的整合把企業IT資源集中調配；通過能力的整合，將平臺的運算能力，業務數據處理能力集中管理，建立一種集中服務的模式，即提高了硬件利用率、人員工作效率又利於IT對各業務部門服務的成本覈算。
“數據事故”分析
爲了解決數據事故問題，筆者協調財務、計劃、銷售、IT等部門成立了專門的“數據治理”項目小組。數據事故，應該是由於數據的素質低劣造成的，根據調查機構Gartner稱，《財富》一千家大型企業所持有的數據，有超過四分一是不準確、不完整或重複的，並預期有四分之三的大型企業直到2010年前也不會或難以改善內部數據的素質。其實沒有一家企業不受數據素質問題困擾，但就算有公司意識到問題所在，也常常會低估問題的嚴重性。何況，數據素質會受多個因素影響而變化。因此，要應付這種挑戰，一次性的行動難以奏效，企業務必持之以恆，甚至採取能改寫企業文化的行動纔會有效。
Gartner研究顯示，良莠不齊的客戶數據可造成重大損失，包括流失客戶，以及由處理直銷郵件不善和錯過銷售機會所造成的浪費等。現時很多企業亦發現劣質數據不單打擊銷售及市場推廣，更會波及最具策略性的業務活動。後勤部門的運作，例如制定預算、生產及分銷也會受到影響。
解決劣質數據問題不只只是一個IT的問題。雖然IT有助將之改善，但企業管理纔是關鍵所在，例如企業文化對數據素質就有很大的影響力。
數據治理，需要對數據的素質提出一個定義，筆者認爲數據素質涵蓋以下多方面：
ü 存在 (即企業到底有沒有某一項數據)
ü 合法性 (即該項數據的數值是否符合一個可接受的範圍)
ü 一貫性 (例如同一項數據不論儲存在哪一個地點都有同一數值)
ü 整全性 (數據元素與不同數據集之間關係的完整程度)
ü 準確性 (該項數據是否能夠描述它應表達的東西)
ü 關聯性 (該項數據能否恰當地支援業務宗旨)
ü 時間性 (即該項數據是否能夠及時地被反應出來)
針對以上數據的素質，再結合DRP系統中的相關模塊，對DRP系統中數據問題按模塊分別分析。該分析表格如下：
|
| 採購 | 訂貨 | 直營 | 門店 | 價格 | 倉儲物流 | |
| 存在 | Y | Y | Y | Y | Y | Y | Y |
| 合法性 | Y | Y | Y | Y | Y | Y | Y |
| 一貫性 | Y | Y | Y | N | N | N | Y |
| 整全性 | N | Y | Y | Y | N | Y | Y |
| 準確性 | N | N | N | N | N | N | N |
| 關聯性 | Y | Y | Y | Y | Y | N | N |
| 時間性 | N | Y | N | N | N | N | N |
以上各模塊中，達到相應的數據素質目標即爲Y，否則爲N。經過對DRP系統中的各個模塊的數據素質調查發現：數據治理主要針對的是數據的準確性、時間性、關聯性。進一步對數據事故的原因分析，發現數據出問題往往是因爲對數據的應用不夠充分。比如物流配送，根據銷售和庫存信息來做，首先銷售的信息，每天系統裏面的銷售信息和銀行回款對比，有沒有差異，沒有差異就是對的。第二，配送是根據系統去配。慢慢的精細化，以前可能是粗放的，現在是一個環節套一個環節，根據這個系統來做，慢慢數據就會越來越準確。百分之百的準確不可能，當然也沒有必要，因爲隨便一個環節都有可能出現串碼。
但如果業務部門發現DRP系統不管用，但DRP使用者就會用自己祕密地使用自己“更方便更可靠的工作流程/做法”。而管理層認爲既然沒有發生什麼不妥，也就睜一隻眼，閉一隻眼。其實，任何繞道DRP系統的工作流程/做法都會產生DRP數據流之外的“數據暗流”。這種“數據暗流”會削弱企業對流程的控制，損害企業對流程的管理和進一步優化，自然DRP系統的數據準確性就更差了。那麼，我們又怎樣保證及時數據更新和避免繞道DRP的祕密的“更方便更可靠的工作流程/做法”呢?解決方案原則上很簡單：持續提高數據準確率，定期維護訂單修訂等系統參數，以確保DRP產生的數據流與實際運作相符，通過基於DRP的工作流程的改進，禁止任何繞道DRP的行爲。
同時，借鑑了業內同行的“數據事故”分析方法，可以得到如下的因果圖：
針對上述發現的各種原因，經過進一步的統計與分析，發現主要的問題在審覈流程缺失，KPI指標設定不完善、考覈與處罰機制沒有執行、指定時間內的數據不到位、業務不熟悉、操作不當上。相反，由於系統原因造成的DRP數據錯誤很少。而像流程原因導致數據錯誤出現的次數只佔20%，但由於流程原因出現的數據錯誤影響程度最大。而像操作不當、指定時間內的數據不到位的情況出現較頻繁，但對數據錯誤的影響有限。
數據治理方案
採用上述的數據治理理論，在經過“數據事故”的教訓之後，發現上述數據問題，分別針對時間因素、流程、數據基礎、考覈機制、人員、系統制定數據治理方案，並強調方案的執行、監督、控制職能，加強各業務人員溝通，達到數據治理的目的。
考覈機制：數據治理的問題其實也是企業管理的問題，而出現問題往往是沒有一個比較好的考覈與激勵機制。在數據事故當中，出了問題之後，IT人員急着去查找原因，財務部門則因爲數據報表出不來而乾着急，而往往是事故責任部門往往是數據生產部門，而不是數據消費部門。所以，沒有好的考覈機制，往往事故在出現了之後無據可依地進行處罰，導致員工情緒極大。因此，我們定製瞭如下考覈辦法：每月結束，涉及到DRP系統中數據操作的，出現錯誤次數在5次(含5次)以上的，每次罰款10元，充入公司獎金池；如果每月操作零錯誤的，則從獎金池內獎勵30元；各部門的年度KPI指標中加入DRP系統數據操作正確率，並給予一定的權重，此舉目的就是爲了能夠使各業務部門經理引起對DRP系統數據操作正確性的重視。
人員：人員責任心不強的問題，可以由前面的考覈機制來加強，而且由於數據操作涉及到部門的績效，因此，各業務部門經理也會加強在這方面的監督；對於操作不當，業務不熟悉的情況，可以歸結爲培訓不夠。對於培訓我們分爲兩大塊：一是新員工培訓，這包括老員工調職到新崗位，新員工如果需要操作DRP系統，必須經過IT部的上崗培訓方可開設DRP系統賬號，否則的話，將無權對DRP系統進行操作；還有就是專場培訓，這也有兩類，一類是專門的計算機基礎教育培訓，這裏會包括一些計算機基礎操作，基本故障處理；另一類是公司業務流程培訓，針對各個不同崗位的人員，將公司的業務流程整合起來講，讓各業務人員知道自己上下游的業務流程是什麼？如果有異常如何處理等，同時培訓由人力資源部培訓組與IT部共同負責，所有培訓考勤、反饋、考覈情況都記入員工培訓檔案，講師則由IT部門、業務部門經理分別承擔；如果是針對各業務經理的培訓，也會請外部的流程、IT專家來擔任。
系統：系統的問題，主要通過兩方面控制：一是加強測試，所有的系統升級都必須經過公司內部的程序員測試，撰寫測試報告，經由IT經理審批之後方可將升級包更新到DRP系統中去，如果由於升級原因造成系統邏輯問題造成的數據錯誤，必須由程序員與IT經理分別承擔責任，根據每次事故的問題嚴重性，每次罰款30—300不等，同時IT部門的KPI指標中也加入系統數據事故的次數進行考覈。二是對於關鍵服務器、網絡設備的突然當機等情況的處理，這些方案可以根據IT部門的原有處置與考覈機制進行。
數據基礎：基礎數據質量差，這就是對數據生產部門提出需求，必須控制數據質量，完善公司數據規格說明，對於必須填寫的數據，由IT部門定期出具數據質量審計報告，對數據生產部門進行考覈。對於數據錄入準確率低的問題，一是採用條碼、掃描等技術手段來加強數據質量，二是通過加強人員責任心來保證，三則是通過數據審覈，下游業務流程一定要加強對數據的審覈與比對，特別是在分公司，由財務、倉管、數據員三方進行數據確認，以保證數據與業務的同步。
流程：物流是最頭痛的問題，也是處理起來最難的問題，其實關於業務流程管理(BPM)是一個很大的話題，在這裏呢，只能說是，根據企業實際情況，一點點的改進，因爲流程改進是一個傷筋動骨的事情，包括：原有流程是合適企業應用的，但現在不合適了怎麼辦？原來的流程是由某個部門負責的，現在職能要細化，要分開怎麼辦？所以在這裏就不再鋪開來講，但以後有機會進一步進行論述。
時間因素：時間因素，主要在於企業的動作效率，也是對於員工的一個考覈指標，這方面沒有太大的難度，我們主要也是將時間作爲數據生產部門的一個指標來考覈，如：計劃部門必須在訂貨單的2小時之內將訂貨單貨配發出去；專賣店如果有DRP系統，必須在當天將銷售數據傳回，如果沒有DRP系統，則傳真數據必須在當天傳回，當地辦事處必須在第二天上午11：00之前將銷售數據做到DRP系統中；客服部必須在12小時內將客戶數據錄入到DRP系統中，對於客戶的禮品申請，必須在兩個工作日內處理完畢，並給客戶回覆等。
上述所有的針對問題的解決方案都離不開執行、監督、控制與交流。在這幾個環節當中，IT部門與行政部門爲主要的執行主體，IT部門負責對DRP系統中的數據異常或每月數據質量出具報告，行政部門則根據IT部門的報告和數據質量方面的制度，給業務部門的KPI指標進行評定，也針對操作人員進行具體的獎罰；同時在培訓這一塊，由人力資源部門與IT部門負責完成。
而IT部門的系統故障及錯誤等問題，則落實到財務部與行政部具體負責進行考覈，這也就是一個監督機制，IT部門作爲DRP系統的管理者，也是要被各個業務部門進行監督的。
而由於涉及到各個業務部門的各個業務環節，特別在加入了績效考覈之後，會引起業務部門對IT部門的敵視，甚至是對DRP系統的敵視，因此，所有策略的實施都需要IT經理與數據治理項目小組的負責人加強溝通。特別是要注意循序漸進，切忌要求一步到位，否則的話引起業務部門的不滿與反彈，有可能事情會變的更糟糕。
項目管理手記(五)
DRP項目中的數據治理
由於我本人的項目經驗在DRP項目中會比較多一些，而且所談及的問題也是在DRP項目中碰到的，當然，也許我說的這個問題不只只是在DRP項目中，包括像ERP、PDM、KM等項目中都會碰上，但我還是會結合DRP項目中的實際問題來說。同時，由於本人所在的角度是甲方的角度，因此，DRP項目的週期對於甲方來說不只只是項目調研、實施、培訓，還會包括整個DRP系統的應用、部署、維護直到系統結束使用的DRP系統的整個使用週期。
DRP項目進行到後期，一般的企業都會擔心一個問題“顧問走了之後，我們怎麼辦？”。因爲如果實施顧問在現場的話，感覺都不會出什麼問題，就算有問題，顧問也解決掉了。但一旦顧問離場，DRP系統交由企業的IT部門負責運行與維護的時候，感覺問題就出的比較多了。這些問題可能會包括系統故障增多，系統運行速度減慢，軟件需求得不到響應，數據不準等。也因爲這些原因業務部門也在應用了一段時間之後感覺系統不好用了，特別是數據不準的情況經常出現，使得報表也不準了，久而久之，業務部門感覺DRP系統的價值也越來越低了，而這樣造成的直接後果就是DRP系統的使用效果打折，經常會聽到業務部門在抱怨：“這是什麼破系統嘛，出來的數據都不準!”，把數據問題與DRP系統邏輯問題相混淆，從而有可能對DRP系統本身引發了懷疑，導致DRP系統的使用週期因爲數據不準而大大縮短。
“數據事故”引發的數據治理思考
套用一句老話：“ERP是三分軟件、七分實施、十分努力、十二分數據、百分百的領導支持”。其實筆者一直在實施DRP項目的過程中，都有碰到多或多或少的數據問題，但應該都是小問題，所影響的範圍也不大，或者通過DRP系統的一些異常處理功能也就能夠解決的，如：退貨單出現的退貨價格不準確的問題，只要對這張單據進行廢除重做就好了，直到筆者碰到兩次重大的“數據事故”，纔對DRP項目的數據治理工作引發了重視與思考。
第一件事情是由於產品中心對新產品定價錯誤引發的“數據事故”。一直以來，新產品的定價是由產品中心會同財務、銷售、計劃等部門一起制定的，而且制定的是產品的零售價，然後根據零售價的折率分別倒推定製分銷價、出廠價、採購價，而採購價也是一個基準價，也就是說，產品的採購必須低於這個價格，否則的話公司是不會批准對這款產品進行投產的。在年度某季度新產品定價時，公司各部門定製出了當季產品的各種價格，並已經在系統中進行實施，但隨之而來的是，發現在市場對於當季產品的價格反映是偏高，而且代理商也認爲當季產品的分銷價格(即代理商進貨價)太高，所以公司決定對該款產品進行重新定價。隨之而來的就是要求DRP系統中對所有業務環節中的價格進行調整，包括對已經配送到分公司、代理商的產品進行重新調價，對已經配送到直營店，在倉庫中未銷售的產品進行價格調整。這一次的調整由於影響極大，導致公司各業務部門不得不集中人馬加班對數據進行調整，而且調整結束之後，在下月的系統過賬中發現財務報表總是有些出入，才發現數據調整有問題，有些調過來了，有些沒有調整過來，有些調整的時候產品已經銷售出去了，有的產品是退貨的，但成本卻沒有改過來，總之是亂的一團麻，使的該月的財務報表不得不在財務部門的要求下，各業務部門簽字覈定是由於操作不當引起的數據統計問題。本次問題其實是一個業務規範性的問題，或者是系統強壯型問題，如果業務夠規範，不會出現這種在產品進行銷售時更改產品成本的問題，或者系統足夠強壯，能夠對數據變更做出及時處理，這次事故應該也是能夠避免的。
第二件事是由於分公司內部管理、控制不到位及流程缺失導致的“數據事故”。記得當時還在外面開會，被財務總監電話催回公司，說是公司領導要求我今天準備一下，明天去華中大區出差，因爲當地分公司的本月的財務、系統數據都有嚴重問題，估計賬實不符情況嚴重，需要過去核查一下問題到底出在哪裏。第二天，當公司的財務、計劃、IT三部門人員到達華中大區所在地時，開始安排了對本大區所有的庫存盤點的工作，首先是對直營店進行盤點，全部由總部人員進行監督，經過五個晚上的盤點之後，再用了四天時間對大區的庫房進行盤點，發現：直營店的手工賬務與DRP系統中的數據不符情況嚴重，而直營店的手工賬務與實際庫存情況相差無幾，直營店也較好地執行了失貨賠償制度。而DRP系統中的數據與實際庫存嚴重不符的原因在於：大區的倉庫管理人員、數據員都沒有及時將直營店的退貨、銷售、調撥單據進行處理，以致直營店數據失真；同時對大區的庫存盤點時發現：大區的庫存結構不合理，庫存過大，直營店的過季產品處理不及時，數據員沒有對倉庫數據進行及時分析及利用。同時，大區的財務人員也沒有根據DRP系統中的數據進行財務數據覈對，以至於倉庫、數據、財務的工作脫節，形成了大區庫房管理工作出現了失控。這次事故經過審覈之後，上報到公司領導，下定決心對相關責任人進行了處罰，而也是在這次“數據事故”之後引發了筆者對於如何進行DRP系統“數據治理”的思考。
數據治理的理論及方法
項目小組總結之後，通過查找相關資料發現：數據治理其實是一種體系，是一個關注於信息系統執行層面的體系，這一體系的目的是整合IT與業務部門的知識和意見，通過一個類似於監督委員會或項目小組的虛擬組織對企業的信息化建設進行全方位的監管，這一組織的基礎是企業高層的授權和業務部門與IT部門的建設性合作。從範圍來講，數據治理涵蓋了從前端事務處理系統，後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
1. 發現：即發現問題和差異（Issues & Gaps），這是監管的基本職能。我們一定要在萌芽階段發現問題和差異，將其扼殺在苗頭。那麼如何去發現呢？
對於待建或在建的系統，要建立專家審覈制度，所謂專家包括技術專家和業務專家，如果本組織不具備條件則可以邀請第三方的顧問來參與系統數據的架構和設計決策，但根本原則是任何專家必須是相關領域的專業人士。
對於已建成使用的系統，則關鍵是IT的日常運維工作的規範化，主要包括規範的問題管理（Trouble Management），週期性審計(Periodic Review)。前者是爲了文檔化各種系統問題和缺陷，以及相應的IT判斷和響應；後者是爲了及時對系統的問題和缺陷做出歸納總結，找出規律而從根本上解決問題。
2. 監督：即持續的保持對業務數據健康狀況的跟蹤。監督主要通過週期性的數據分析來完成，市場上也有很多自動化的工具可以幫助您方便的對數據的健康狀況進行分析。與發現所不同的是，監督是主動的去發掘問題，而且在發現問題後立即採取行動去修正它。
3. 控制：即掌握信息系統建設的決策權。任何信息系統的建設、更新升級、大型變更都必須通過數據治理項目小組的審批，極端情況下甚至可以考慮任何數據變更都必須審批。集中化的控制的好處是，首先可以集中技術和業務相關領域的專家的意見，其次可以限制執行層面的IT人員和業務人員的隨意性、不嚴謹性，再次向監管層提供了從全局和長遠的角度看系統的機會。
4. 交流：即溝通，是跨部門的跨領域的溝通。對傳統IT的最大挑戰就是跨組織跨領域的溝通交流，而數據治理委員會這樣一個跨越了IT部門和業務部門的虛擬組織，通過建立例行的交流機制，保證了信息在整個組織範圍內的透明，這種透明性保證了所有參與者的步調一致的，保證了業務數據的一致性。交流滲透在前面所述的四點數據治理活動中，是它們成功的保障。
5. 整合：這是我們的目標同時也是解決之道，主要抓住三個方面的整合——信息的整合，資源的整合，能力的整合。通過信息的整合把分散的業務數據整合到一個一致的沒有歧義的體系中來；通過資源的整合把企業IT資源集中調配；通過能力的整合，將平臺的運算能力，業務數據處理能力集中管理，建立一種集中服務的模式，即提高了硬件利用率、人員工作效率又利於IT對各業務部門服務的成本覈算。
“數據事故”分析
爲了解決數據事故問題，筆者協調財務、計劃、銷售、IT等部門成立了專門的“數據治理”項目小組。數據事故，應該是由於數據的素質低劣造成的，根據調查機構Gartner稱，《財富》一千家大型企業所持有的數據，有超過四分一是不準確、不完整或重複的，並預期有四分之三的大型企業直到2010年前也不會或難以改善內部數據的素質。其實沒有一家企業不受數據素質問題困擾，但就算有公司意識到問題所在，也常常會低估問題的嚴重性。何況，數據素質會受多個因素影響而變化。因此，要應付這種挑戰，一次性的行動難以奏效，企業務必持之以恆，甚至採取能改寫企業文化的行動纔會有效。
Gartner研究顯示，良莠不齊的客戶數據可造成重大損失，包括流失客戶，以及由處理直銷郵件不善和錯過銷售機會所造成的浪費等。現時很多企業亦發現劣質數據不單打擊銷售及市場推廣，更會波及最具策略性的業務活動。後勤部門的運作，例如制定預算、生產及分銷也會受到影響。
解決劣質數據問題不只只是一個IT的問題。雖然IT有助將之改善，但企業管理纔是關鍵所在，例如企業文化對數據素質就有很大的影響力。
數據治理，需要對數據的素質提出一個定義，筆者認爲數據素質涵蓋以下多方面：
ü 存在 (即企業到底有沒有某一項數據)
ü 合法性 (即該項數據的數值是否符合一個可接受的範圍)
ü 一貫性 (例如同一項數據不論儲存在哪一個地點都有同一數值)
ü 整全性 (數據元素與不同數據集之間關係的完整程度)
ü 準確性 (該項數據是否能夠描述它應表達的東西)
ü 關聯性 (該項數據能否恰當地支援業務宗旨)
ü 時間性 (即該項數據是否能夠及時地被反應出來)
針對以上數據的素質，再結合DRP系統中的相關模塊，對DRP系統中數據問題按模塊分別分析。該分析表格如下：
|
| 採購 | 訂貨 | 直營 | 門店 | 價格 | 倉儲物流 | |
| 存在 | Y | Y | Y | Y | Y | Y | Y |
| 合法性 | Y | Y | Y | Y | Y | Y | Y |
| 一貫性 | Y | Y | Y | N | N | N | Y |
| 整全性 | N | Y | Y | Y | N | Y | Y |
| 準確性 | N | N | N | N | N | N | N |
| 關聯性 | Y | Y | Y | Y | Y | N | N |
| 時間性 | N | Y | N | N | N | N | N |
以上各模塊中，達到相應的數據素質目標即爲Y，否則爲N。經過對DRP系統中的各個模塊的數據素質調查發現：數據治理主要針對的是數據的準確性、時間性、關聯性。進一步對數據事故的原因分析，發現數據出問題往往是因爲對數據的應用不夠充分。比如物流配送，根據銷售和庫存信息來做，首先銷售的信息，每天系統裏面的銷售信息和銀行回款對比，有沒有差異，沒有差異就是對的。第二，配送是根據系統去配。慢慢的精細化，以前可能是粗放的，現在是一個環節套一個環節，根據這個系統來做，慢慢數據就會越來越準確。百分之百的準確不可能，當然也沒有必要，因爲隨便一個環節都有可能出現串碼。
但如果業務部門發現DRP系統不管用，但DRP使用者就會用自己祕密地使用自己“更方便更可靠的工作流程/做法”。而管理層認爲既然沒有發生什麼不妥，也就睜一隻眼，閉一隻眼。其實，任何繞道DRP系統的工作流程/做法都會產生DRP數據流之外的“數據暗流”。這種“數據暗流”會削弱企業對流程的控制，損害企業對流程的管理和進一步優化，自然DRP系統的數據準確性就更差了。那麼，我們又怎樣保證及時數據更新和避免繞道DRP的祕密的“更方便更可靠的工作流程/做法”呢?解決方案原則上很簡單：持續提高數據準確率，定期維護訂單修訂等系統參數，以確保DRP產生的數據流與實際運作相符，通過基於DRP的工作流程的改進，禁止任何繞道DRP的行爲。
同時，借鑑了業內同行的“數據事故”分析方法，可以得到如下的因果圖：
針對上述發現的各種原因，經過進一步的統計與分析，發現主要的問題在審覈流程缺失，KPI指標設定不完善、考覈與處罰機制沒有執行、指定時間內的數據不到位、業務不熟悉、操作不當上。相反，由於系統原因造成的DRP數據錯誤很少。而像流程原因導致數據錯誤出現的次數只佔20%，但由於流程原因出現的數據錯誤影響程度最大。而像操作不當、指定時間內的數據不到位的情況出現較頻繁，但對數據錯誤的影響有限。
數據治理方案
採用上述的數據治理理論，在經過“數據事故”的教訓之後，發現上述數據問題，分別針對時間因素、流程、數據基礎、考覈機制、人員、系統制定數據治理方案，並強調方案的執行、監督、控制職能，加強各業務人員溝通，達到數據治理的目的。
考覈機制：數據治理的問題其實也是企業管理的問題，而出現問題往往是沒有一個比較好的考覈與激勵機制。在數據事故當中，出了問題之後，IT人員急着去查找原因，財務部門則因爲數據報表出不來而乾着急，而往往是事故責任部門往往是數據生產部門，而不是數據消費部門。所以，沒有好的考覈機制，往往事故在出現了之後無據可依地進行處罰，導致員工情緒極大。因此，我們定製瞭如下考覈辦法：每月結束，涉及到DRP系統中數據操作的，出現錯誤次數在5次(含5次)以上的，每次罰款10元，充入公司獎金池；如果每月操作零錯誤的，則從獎金池內獎勵30元；各部門的年度KPI指標中加入DRP系統數據操作正確率，並給予一定的權重，此舉目的就是爲了能夠使各業務部門經理引起對DRP系統數據操作正確性的重視。
人員：人員責任心不強的問題，可以由前面的考覈機制來加強，而且由於數據操作涉及到部門的績效，因此，各業務部門經理也會加強在這方面的監督；對於操作不當，業務不熟悉的情況，可以歸結爲培訓不夠。對於培訓我們分爲兩大塊：一是新員工培訓，這包括老員工調職到新崗位，新員工如果需要操作DRP系統，必須經過IT部的上崗培訓方可開設DRP系統賬號，否則的話，將無權對DRP系統進行操作；還有就是專場培訓，這也有兩類，一類是專門的計算機基礎教育培訓，這裏會包括一些計算機基礎操作，基本故障處理；另一類是公司業務流程培訓，針對各個不同崗位的人員，將公司的業務流程整合起來講，讓各業務人員知道自己上下游的業務流程是什麼？如果有異常如何處理等，同時培訓由人力資源部培訓組與IT部共同負責，所有培訓考勤、反饋、考覈情況都記入員工培訓檔案，講師則由IT部門、業務部門經理分別承擔；如果是針對各業務經理的培訓，也會請外部的流程、IT專家來擔任。
系統：系統的問題，主要通過兩方面控制：一是加強測試，所有的系統升級都必須經過公司內部的程序員測試，撰寫測試報告，經由IT經理審批之後方可將升級包更新到DRP系統中去，如果由於升級原因造成系統邏輯問題造成的數據錯誤，必須由程序員與IT經理分別承擔責任，根據每次事故的問題嚴重性，每次罰款30—300不等，同時IT部門的KPI指標中也加入系統數據事故的次數進行考覈。二是對於關鍵服務器、網絡設備的突然當機等情況的處理，這些方案可以根據IT部門的原有處置與考覈機制進行。
數據基礎：基礎數據質量差，這就是對數據生產部門提出需求，必須控制數據質量，完善公司數據規格說明，對於必須填寫的數據，由IT部門定期出具數據質量審計報告，對數據生產部門進行考覈。對於數據錄入準確率低的問題，一是採用條碼、掃描等技術手段來加強數據質量，二是通過加強人員責任心來保證，三則是通過數據審覈，下游業務流程一定要加強對數據的審覈與比對，特別是在分公司，由財務、倉管、數據員三方進行數據確認，以保證數據與業務的同步。
流程：物流是最頭痛的問題，也是處理起來最難的問題，其實關於業務流程管理(BPM)是一個很大的話題，在這裏呢，只能說是，根據企業實際情況，一點點的改進，因爲流程改進是一個傷筋動骨的事情，包括：原有流程是合適企業應用的，但現在不合適了怎麼辦？原來的流程是由某個部門負責的，現在職能要細化，要分開怎麼辦？所以在這裏就不再鋪開來講，但以後有機會進一步進行論述。
時間因素：時間因素，主要在於企業的動作效率，也是對於員工的一個考覈指標，這方面沒有太大的難度，我們主要也是將時間作爲數據生產部門的一個指標來考覈，如：計劃部門必須在訂貨單的2小時之內將訂貨單貨配發出去；專賣店如果有DRP系統，必須在當天將銷售數據傳回，如果沒有DRP系統，則傳真數據必須在當天傳回，當地辦事處必須在第二天上午11：00之前將銷售數據做到DRP系統中；客服部必須在12小時內將客戶數據錄入到DRP系統中，對於客戶的禮品申請，必須在兩個工作日內處理完畢，並給客戶回覆等。
上述所有的針對問題的解決方案都離不開執行、監督、控制與交流。在這幾個環節當中，IT部門與行政部門爲主要的執行主體，IT部門負責對DRP系統中的數據異常或每月數據質量出具報告，行政部門則根據IT部門的報告和數據質量方面的制度，給業務部門的KPI指標進行評定，也針對操作人員進行具體的獎罰；同時在培訓這一塊，由人力資源部門與IT部門負責完成。
而IT部門的系統故障及錯誤等問題，則落實到財務部與行政部具體負責進行考覈，這也就是一個監督機制，IT部門作爲DRP系統的管理者，也是要被各個業務部門進行監督的。
而由於涉及到各個業務部門的各個業務環節，特別在加入了績效考覈之後，會引起業務部門對IT部門的敵視，甚至是對DRP系統的敵視，因此，所有策略的實施都需要IT經理與數據治理項目小組的負責人加強溝通。特別是要注意循序漸進，切忌要求一步到位，否則的話引起業務部門的不滿與反彈，有可能事情會變的更糟糕。
項目管理手記(五)
DRP項目中的數據治理
由於我本人的項目經驗在DRP項目中會比較多一些，而且所談及的問題也是在DRP項目中碰到的，當然，也許我說的這個問題不只只是在DRP項目中，包括像ERP、PDM、KM等項目中都會碰上，但我還是會結合DRP項目中的實際問題來說。同時，由於本人所在的角度是甲方的角度，因此，DRP項目的週期對於甲方來說不只只是項目調研、實施、培訓，還會包括整個DRP系統的應用、部署、維護直到系統結束使用的DRP系統的整個使用週期。
DRP項目進行到後期，一般的企業都會擔心一個問題“顧問走了之後，我們怎麼辦？”。因爲如果實施顧問在現場的話，感覺都不會出什麼問題，就算有問題，顧問也解決掉了。但一旦顧問離場，DRP系統交由企業的IT部門負責運行與維護的時候，感覺問題就出的比較多了。這些問題可能會包括系統故障增多，系統運行速度減慢，軟件需求得不到響應，數據不準等。也因爲這些原因業務部門也在應用了一段時間之後感覺系統不好用了，特別是數據不準的情況經常出現，使得報表也不準了，久而久之，業務部門感覺DRP系統的價值也越來越低了，而這樣造成的直接後果就是DRP系統的使用效果打折，經常會聽到業務部門在抱怨：“這是什麼破系統嘛，出來的數據都不準!”，把數據問題與DRP系統邏輯問題相混淆，從而有可能對DRP系統本身引發了懷疑，導致DRP系統的使用週期因爲數據不準而大大縮短。
“數據事故”引發的數據治理思考
套用一句老話：“ERP是三分軟件、七分實施、十分努力、十二分數據、百分百的領導支持”。其實筆者一直在實施DRP項目的過程中，都有碰到多或多或少的數據問題，但應該都是小問題，所影響的範圍也不大，或者通過DRP系統的一些異常處理功能也就能夠解決的，如：退貨單出現的退貨價格不準確的問題，只要對這張單據進行廢除重做就好了，直到筆者碰到兩次重大的“數據事故”，纔對DRP項目的數據治理工作引發了重視與思考。
第一件事情是由於產品中心對新產品定價錯誤引發的“數據事故”。一直以來，新產品的定價是由產品中心會同財務、銷售、計劃等部門一起制定的，而且制定的是產品的零售價，然後根據零售價的折率分別倒推定製分銷價、出廠價、採購價，而採購價也是一個基準價，也就是說，產品的採購必須低於這個價格，否則的話公司是不會批准對這款產品進行投產的。在年度某季度新產品定價時，公司各部門定製出了當季產品的各種價格，並已經在系統中進行實施，但隨之而來的是，發現在市場對於當季產品的價格反映是偏高，而且代理商也認爲當季產品的分銷價格(即代理商進貨價)太高，所以公司決定對該款產品進行重新定價。隨之而來的就是要求DRP系統中對所有業務環節中的價格進行調整，包括對已經配送到分公司、代理商的產品進行重新調價，對已經配送到直營店，在倉庫中未銷售的產品進行價格調整。這一次的調整由於影響極大，導致公司各業務部門不得不集中人馬加班對數據進行調整，而且調整結束之後，在下月的系統過賬中發現財務報表總是有些出入，才發現數據調整有問題，有些調過來了，有些沒有調整過來，有些調整的時候產品已經銷售出去了，有的產品是退貨的，但成本卻沒有改過來，總之是亂的一團麻，使的該月的財務報表不得不在財務部門的要求下，各業務部門簽字覈定是由於操作不當引起的數據統計問題。本次問題其實是一個業務規範性的問題，或者是系統強壯型問題，如果業務夠規範，不會出現這種在產品進行銷售時更改產品成本的問題，或者系統足夠強壯，能夠對數據變更做出及時處理，這次事故應該也是能夠避免的。
第二件事是由於分公司內部管理、控制不到位及流程缺失導致的“數據事故”。記得當時還在外面開會，被財務總監電話催回公司，說是公司領導要求我今天準備一下，明天去華中大區出差，因爲當地分公司的本月的財務、系統數據都有嚴重問題，估計賬實不符情況嚴重，需要過去核查一下問題到底出在哪裏。第二天，當公司的財務、計劃、IT三部門人員到達華中大區所在地時，開始安排了對本大區所有的庫存盤點的工作，首先是對直營店進行盤點，全部由總部人員進行監督，經過五個晚上的盤點之後，再用了四天時間對大區的庫房進行盤點，發現：直營店的手工賬務與DRP系統中的數據不符情況嚴重，而直營店的手工賬務與實際庫存情況相差無幾，直營店也較好地執行了失貨賠償制度。而DRP系統中的數據與實際庫存嚴重不符的原因在於：大區的倉庫管理人員、數據員都沒有及時將直營店的退貨、銷售、調撥單據進行處理，以致直營店數據失真；同時對大區的庫存盤點時發現：大區的庫存結構不合理，庫存過大，直營店的過季產品處理不及時，數據員沒有對倉庫數據進行及時分析及利用。同時，大區的財務人員也沒有根據DRP系統中的數據進行財務數據覈對，以至於倉庫、數據、財務的工作脫節，形成了大區庫房管理工作出現了失控。這次事故經過審覈之後，上報到公司領導，下定決心對相關責任人進行了處罰，而也是在這次“數據事故”之後引發了筆者對於如何進行DRP系統“數據治理”的思考。
數據治理的理論及方法
項目小組總結之後，通過查找相關資料發現：數據治理其實是一種體系，是一個關注於信息系統執行層面的體系，這一體系的目的是整合IT與業務部門的知識和意見，通過一個類似於監督委員會或項目小組的虛擬組織對企業的信息化建設進行全方位的監管，這一組織的基礎是企業高層的授權和業務部門與IT部門的建設性合作。從範圍來講，數據治理涵蓋了從前端事務處理系統，後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
1. 發現：即發現問題和差異（Issues & Gaps），這是監管的基本職能。我們一定要在萌芽階段發現問題和差異，將其扼殺在苗頭。那麼如何去發現呢？
對於待建或在建的系統，要建立專家審覈制度，所謂專家包括技術專家和業務專家，如果本組織不具備條件則可以邀請第三方的顧問來參與系統數據的架構和設計決策，但根本原則是任何專家必須是相關領域的專業人士。
對於已建成使用的系統，則關鍵是IT的日常運維工作的規範化，主要包括規範的問題管理（Trouble Management），週期性審計(Periodic Review)。前者是爲了文檔化各種系統問題和缺陷，以及相應的IT判斷和響應；後者是爲了及時對系統的問題和缺陷做出歸納總結，找出規律而從根本上解決問題。
2. 監督：即持續的保持對業務數據健康狀況的跟蹤。監督主要通過週期性的數據分析來完成，市場上也有很多自動化的工具可以幫助您方便的對數據的健康狀況進行分析。與發現所不同的是，監督是主動的去發掘問題，而且在發現問題後立即採取行動去修正它。
3. 控制：即掌握信息系統建設的決策權。任何信息系統的建設、更新升級、大型變更都必須通過數據治理項目小組的審批，極端情況下甚至可以考慮任何數據變更都必須審批。集中化的控制的好處是，首先可以集中技術和業務相關領域的專家的意見，其次可以限制執行層面的IT人員和業務人員的隨意性、不嚴謹性，再次向監管層提供了從全局和長遠的角度看系統的機會。
4. 交流：即溝通，是跨部門的跨領域的溝通。對傳統IT的最大挑戰就是跨組織跨領域的溝通交流，而數據治理委員會這樣一個跨越了IT部門和業務部門的虛擬組織，通過建立例行的交流機制，保證了信息在整個組織範圍內的透明，這種透明性保證了所有參與者的步調一致的，保證了業務數據的一致性。交流滲透在前面所述的四點數據治理活動中，是它們成功的保障。
5. 整合：這是我們的目標同時也是解決之道，主要抓住三個方面的整合——信息的整合，資源的整合，能力的整合。通過信息的整合把分散的業務數據整合到一個一致的沒有歧義的體系中來；通過資源的整合把企業IT資源集中調配；通過能力的整合，將平臺的運算能力，業務數據處理能力集中管理，建立一種集中服務的模式，即提高了硬件利用率、人員工作效率又利於IT對各業務部門服務的成本覈算。
“數據事故”分析
爲了解決數據事故問題，筆者協調財務、計劃、銷售、IT等部門成立了專門的“數據治理”項目小組。數據事故，應該是由於數據的素質低劣造成的，根據調查機構Gartner稱，《財富》一千家大型企業所持有的數據，有超過四分一是不準確、不完整或重複的，並預期有四分之三的大型企業直到2010年前也不會或難以改善內部數據的素質。其實沒有一家企業不受數據素質問題困擾，但就算有公司意識到問題所在，也常常會低估問題的嚴重性。何況，數據素質會受多個因素影響而變化。因此，要應付這種挑戰，一次性的行動難以奏效，企業務必持之以恆，甚至採取能改寫企業文化的行動纔會有效。
Gartner研究顯示，良莠不齊的客戶數據可造成重大損失，包括流失客戶，以及由處理直銷郵件不善和錯過銷售機會所造成的浪費等。現時很多企業亦發現劣質數據不單打擊銷售及市場推廣，更會波及最具策略性的業務活動。後勤部門的運作，例如制定預算、生產及分銷也會受到影響。
解決劣質數據問題不只只是一個IT的問題。雖然IT有助將之改善，但企業管理纔是關鍵所在，例如企業文化對數據素質就有很大的影響力。
數據治理，需要對數據的素質提出一個定義，筆者認爲數據素質涵蓋以下多方面：
ü 存在 (即企業到底有沒有某一項數據)
ü 合法性 (即該項數據的數值是否符合一個可接受的範圍)
ü 一貫性 (例如同一項數據不論儲存在哪一個地點都有同一數值)
ü 整全性 (數據元素與不同數據集之間關係的完整程度)
ü 準確性 (該項數據是否能夠描述它應表達的東西)
ü 關聯性 (該項數據能否恰當地支援業務宗旨)
ü 時間性 (即該項數據是否能夠及時地被反應出來)
針對以上數據的素質，再結合DRP系統中的相關模塊，對DRP系統中數據問題按模塊分別分析。該分析表格如下：
|
| 採購 | 訂貨 | 直營 | 門店 | 價格 | 倉儲物流 | |
| 存在 | Y | Y | Y | Y | Y | Y | Y |
| 合法性 | Y | Y | Y | Y | Y | Y | Y |
| 一貫性 | Y | Y | Y | N | N | N | Y |
| 整全性 | N | Y | Y | Y | N | Y | Y |
| 準確性 | N | N | N | N | N | N | N |
| 關聯性 | Y | Y | Y | Y | Y | N | N |
| 時間性 | N | Y | N | N | N | N | N |
以上各模塊中，達到相應的數據素質目標即爲Y，否則爲N。經過對DRP系統中的各個模塊的數據素質調查發現：數據治理主要針對的是數據的準確性、時間性、關聯性。進一步對數據事故的原因分析，發現數據出問題往往是因爲對數據的應用不夠充分。比如物流配送，根據銷售和庫存信息來做，首先銷售的信息，每天系統裏面的銷售信息和銀行回款對比，有沒有差異，沒有差異就是對的。第二，配送是根據系統去配。慢慢的精細化，以前可能是粗放的，現在是一個環節套一個環節，根據這個系統來做，慢慢數據就會越來越準確。百分之百的準確不可能，當然也沒有必要，因爲隨便一個環節都有可能出現串碼。
但如果業務部門發現DRP系統不管用，但DRP使用者就會用自己祕密地使用自己“更方便更可靠的工作流程/做法”。而管理層認爲既然沒有發生什麼不妥，也就睜一隻眼，閉一隻眼。其實，任何繞道DRP系統的工作流程/做法都會產生DRP數據流之外的“數據暗流”。這種“數據暗流”會削弱企業對流程的控制，損害企業對流程的管理和進一步優化，自然DRP系統的數據準確性就更差了。那麼，我們又怎樣保證及時數據更新和避免繞道DRP的祕密的“更方便更可靠的工作流程/做法”呢?解決方案原則上很簡單：持續提高數據準確率，定期維護訂單修訂等系統參數，以確保DRP產生的數據流與實際運作相符，通過基於DRP的工作流程的改進，禁止任何繞道DRP的行爲。
同時，借鑑了業內同行的“數據事故”分析方法，可以得到如下的因果圖：
針對上述發現的各種原因，經過進一步的統計與分析，發現主要的問題在審覈流程缺失，KPI指標設定不完善、考覈與處罰機制沒有執行、指定時間內的數據不到位、業務不熟悉、操作不當上。相反，由於系統原因造成的DRP數據錯誤很少。而像流程原因導致數據錯誤出現的次數只佔20%，但由於流程原因出現的數據錯誤影響程度最大。而像操作不當、指定時間內的數據不到位的情況出現較頻繁，但對數據錯誤的影響有限。
數據治理方案
採用上述的數據治理理論，在經過“數據事故”的教訓之後，發現上述數據問題，分別針對時間因素、流程、數據基礎、考覈機制、人員、系統制定數據治理方案，並強調方案的執行、監督、控制職能，加強各業務人員溝通，達到數據治理的目的。
考覈機制：數據治理的問題其實也是企業管理的問題，而出現問題往往是沒有一個比較好的考覈與激勵機制。在數據事故當中，出了問題之後，IT人員急着去查找原因，財務部門則因爲數據報表出不來而乾着急，而往往是事故責任部門往往是數據生產部門，而不是數據消費部門。所以，沒有好的考覈機制，往往事故在出現了之後無據可依地進行處罰，導致員工情緒極大。因此，我們定製瞭如下考覈辦法：每月結束，涉及到DRP系統中數據操作的，出現錯誤次數在5次(含5次)以上的，每次罰款10元，充入公司獎金池；如果每月操作零錯誤的，則從獎金池內獎勵30元；各部門的年度KPI指標中加入DRP系統數據操作正確率，並給予一定的權重，此舉目的就是爲了能夠使各業務部門經理引起對DRP系統數據操作正確性的重視。
人員：人員責任心不強的問題，可以由前面的考覈機制來加強，而且由於數據操作涉及到部門的績效，因此，各業務部門經理也會加強在這方面的監督；對於操作不當，業務不熟悉的情況，可以歸結爲培訓不夠。對於培訓我們分爲兩大塊：一是新員工培訓，這包括老員工調職到新崗位，新員工如果需要操作DRP系統，必須經過IT部的上崗培訓方可開設DRP系統賬號，否則的話，將無權對DRP系統進行操作；還有就是專場培訓，這也有兩類，一類是專門的計算機基礎教育培訓，這裏會包括一些計算機基礎操作，基本故障處理；另一類是公司業務流程培訓，針對各個不同崗位的人員，將公司的業務流程整合起來講，讓各業務人員知道自己上下游的業務流程是什麼？如果有異常如何處理等，同時培訓由人力資源部培訓組與IT部共同負責，所有培訓考勤、反饋、考覈情況都記入員工培訓檔案，講師則由IT部門、業務部門經理分別承擔；如果是針對各業務經理的培訓，也會請外部的流程、IT專家來擔任。
系統：系統的問題，主要通過兩方面控制：一是加強測試，所有的系統升級都必須經過公司內部的程序員測試，撰寫測試報告，經由IT經理審批之後方可將升級包更新到DRP系統中去，如果由於升級原因造成系統邏輯問題造成的數據錯誤，必須由程序員與IT經理分別承擔責任，根據每次事故的問題嚴重性，每次罰款30—300不等，同時IT部門的KPI指標中也加入系統數據事故的次數進行考覈。二是對於關鍵服務器、網絡設備的突然當機等情況的處理，這些方案可以根據IT部門的原有處置與考覈機制進行。
數據基礎：基礎數據質量差，這就是對數據生產部門提出需求，必須控制數據質量，完善公司數據規格說明，對於必須填寫的數據，由IT部門定期出具數據質量審計報告，對數據生產部門進行考覈。對於數據錄入準確率低的問題，一是採用條碼、掃描等技術手段來加強數據質量，二是通過加強人員責任心來保證，三則是通過數據審覈，下游業務流程一定要加強對數據的審覈與比對，特別是在分公司，由財務、倉管、數據員三方進行數據確認，以保證數據與業務的同步。
流程：物流是最頭痛的問題，也是處理起來最難的問題，其實關於業務流程管理(BPM)是一個很大的話題，在這裏呢，只能說是，根據企業實際情況，一點點的改進，因爲流程改進是一個傷筋動骨的事情，包括：原有流程是合適企業應用的，但現在不合適了怎麼辦？原來的流程是由某個部門負責的，現在職能要細化，要分開怎麼辦？所以在這裏就不再鋪開來講，但以後有機會進一步進行論述。
時間因素：時間因素，主要在於企業的動作效率，也是對於員工的一個考覈指標，這方面沒有太大的難度，我們主要也是將時間作爲數據生產部門的一個指標來考覈，如：計劃部門必須在訂貨單的2小時之內將訂貨單貨配發出去；專賣店如果有DRP系統，必須在當天將銷售數據傳回，如果沒有DRP系統，則傳真數據必須在當天傳回，當地辦事處必須在第二天上午11：00之前將銷售數據做到DRP系統中；客服部必須在12小時內將客戶數據錄入到DRP系統中，對於客戶的禮品申請，必須在兩個工作日內處理完畢，並給客戶回覆等。
上述所有的針對問題的解決方案都離不開執行、監督、控制與交流。在這幾個環節當中，IT部門與行政部門爲主要的執行主體，IT部門負責對DRP系統中的數據異常或每月數據質量出具報告，行政部門則根據IT部門的報告和數據質量方面的制度，給業務部門的KPI指標進行評定，也針對操作人員進行具體的獎罰；同時在培訓這一塊，由人力資源部門與IT部門負責完成。
而IT部門的系統故障及錯誤等問題，則落實到財務部與行政部具體負責進行考覈，這也就是一個監督機制，IT部門作爲DRP系統的管理者，也是要被各個業務部門進行監督的。
而由於涉及到各個業務部門的各個業務環節，特別在加入了績效考覈之後，會引起業務部門對IT部門的敵視，甚至是對DRP系統的敵視，因此，所有策略的實施都需要IT經理與數據治理項目小組的負責人加強溝通。特別是要注意循序漸進，切忌要求一步到位，否則的話引起業務部門的不滿與反彈，有可能事情會變的更糟糕。
項目管理手記(五)
DRP項目中的數據治理
由於我本人的項目經驗在DRP項目中會比較多一些，而且所談及的問題也是在DRP項目中碰到的，當然，也許我說的這個問題不只只是在DRP項目中，包括像ERP、PDM、KM等項目中都會碰上，但我還是會結合DRP項目中的實際問題來說。同時，由於本人所在的角度是甲方的角度，因此，DRP項目的週期對於甲方來說不只只是項目調研、實施、培訓，還會包括整個DRP系統的應用、部署、維護直到系統結束使用的DRP系統的整個使用週期。
DRP項目進行到後期，一般的企業都會擔心一個問題“顧問走了之後，我們怎麼辦？”。因爲如果實施顧問在現場的話，感覺都不會出什麼問題，就算有問題，顧問也解決掉了。但一旦顧問離場，DRP系統交由企業的IT部門負責運行與維護的時候，感覺問題就出的比較多了。這些問題可能會包括系統故障增多，系統運行速度減慢，軟件需求得不到響應，數據不準等。也因爲這些原因業務部門也在應用了一段時間之後感覺系統不好用了，特別是數據不準的情況經常出現，使得報表也不準了，久而久之，業務部門感覺DRP系統的價值也越來越低了，而這樣造成的直接後果就是DRP系統的使用效果打折，經常會聽到業務部門在抱怨：“這是什麼破系統嘛，出來的數據都不準!”，把數據問題與DRP系統邏輯問題相混淆，從而有可能對DRP系統本身引發了懷疑，導致DRP系統的使用週期因爲數據不準而大大縮短。
“數據事故”引發的數據治理思考
套用一句老話：“ERP是三分軟件、七分實施、十分努力、十二分數據、百分百的領導支持”。其實筆者一直在實施DRP項目的過程中，都有碰到多或多或少的數據問題，但應該都是小問題，所影響的範圍也不大，或者通過DRP系統的一些異常處理功能也就能夠解決的，如：退貨單出現的退貨價格不準確的問題，只要對這張單據進行廢除重做就好了，直到筆者碰到兩次重大的“數據事故”，纔對DRP項目的數據治理工作引發了重視與思考。
第一件事情是由於產品中心對新產品定價錯誤引發的“數據事故”。一直以來，新產品的定價是由產品中心會同財務、銷售、計劃等部門一起制定的，而且制定的是產品的零售價，然後根據零售價的折率分別倒推定製分銷價、出廠價、採購價，而採購價也是一個基準價，也就是說，產品的採購必須低於這個價格，否則的話公司是不會批准對這款產品進行投產的。在年度某季度新產品定價時，公司各部門定製出了當季產品的各種價格，並已經在系統中進行實施，但隨之而來的是，發現在市場對於當季產品的價格反映是偏高，而且代理商也認爲當季產品的分銷價格(即代理商進貨價)太高，所以公司決定對該款產品進行重新定價。隨之而來的就是要求DRP系統中對所有業務環節中的價格進行調整，包括對已經配送到分公司、代理商的產品進行重新調價，對已經配送到直營店，在倉庫中未銷售的產品進行價格調整。這一次的調整由於影響極大，導致公司各業務部門不得不集中人馬加班對數據進行調整，而且調整結束之後，在下月的系統過賬中發現財務報表總是有些出入，才發現數據調整有問題，有些調過來了，有些沒有調整過來，有些調整的時候產品已經銷售出去了，有的產品是退貨的，但成本卻沒有改過來，總之是亂的一團麻，使的該月的財務報表不得不在財務部門的要求下，各業務部門簽字覈定是由於操作不當引起的數據統計問題。本次問題其實是一個業務規範性的問題，或者是系統強壯型問題，如果業務夠規範，不會出現這種在產品進行銷售時更改產品成本的問題，或者系統足夠強壯，能夠對數據變更做出及時處理，這次事故應該也是能夠避免的。
第二件事是由於分公司內部管理、控制不到位及流程缺失導致的“數據事故”。記得當時還在外面開會，被財務總監電話催回公司，說是公司領導要求我今天準備一下，明天去華中大區出差，因爲當地分公司的本月的財務、系統數據都有嚴重問題，估計賬實不符情況嚴重，需要過去核查一下問題到底出在哪裏。第二天，當公司的財務、計劃、IT三部門人員到達華中大區所在地時，開始安排了對本大區所有的庫存盤點的工作，首先是對直營店進行盤點，全部由總部人員進行監督，經過五個晚上的盤點之後，再用了四天時間對大區的庫房進行盤點，發現：直營店的手工賬務與DRP系統中的數據不符情況嚴重，而直營店的手工賬務與實際庫存情況相差無幾，直營店也較好地執行了失貨賠償制度。而DRP系統中的數據與實際庫存嚴重不符的原因在於：大區的倉庫管理人員、數據員都沒有及時將直營店的退貨、銷售、調撥單據進行處理，以致直營店數據失真；同時對大區的庫存盤點時發現：大區的庫存結構不合理，庫存過大，直營店的過季產品處理不及時，數據員沒有對倉庫數據進行及時分析及利用。同時，大區的財務人員也沒有根據DRP系統中的數據進行財務數據覈對，以至於倉庫、數據、財務的工作脫節，形成了大區庫房管理工作出現了失控。這次事故經過審覈之後，上報到公司領導，下定決心對相關責任人進行了處罰，而也是在這次“數據事故”之後引發了筆者對於如何進行DRP系統“數據治理”的思考。
數據治理的理論及方法
項目小組總結之後，通過查找相關資料發現：數據治理其實是一種體系，是一個關注於信息系統執行層面的體系，這一體系的目的是整合IT與業務部門的知識和意見，通過一個類似於監督委員會或項目小組的虛擬組織對企業的信息化建設進行全方位的監管，這一組織的基礎是企業高層的授權和業務部門與IT部門的建設性合作。從範圍來講，數據治理涵蓋了從前端事務處理系統，後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
1. 發現：即發現問題和差異（Issues & Gaps），這是監管的基本職能。我們一定要在萌芽階段發現問題和差異，將其扼殺在苗頭。那麼如何去發現呢？
對於待建或在建的系統，要建立專家審覈制度，所謂專家包括技術專家和業務專家，如果本組織不具備條件則可以邀請第三方的顧問來參與系統數據的架構和設計決策，但根本原則是任何專家必須是相關領域的專業人士。
對於已建成使用的系統，則關鍵是IT的日常運維工作的規範化，主要包括規範的問題管理（Trouble Management），週期性審計(Periodic Review)。前者是爲了文檔化各種系統問題和缺陷，以及相應的IT判斷和響應；後者是爲了及時對系統的問題和缺陷做出歸納總結，找出規律而從根本上解決問題。
2. 監督：即持續的保持對業務數據健康狀況的跟蹤。監督主要通過週期性的數據分析來完成，市場上也有很多自動化的工具可以幫助您方便的對數據的健康狀況進行分析。與發現所不同的是，監督是主動的去發掘問題，而且在發現問題後立即採取行動去修正它。
3. 控制：即掌握信息系統建設的決策權。任何信息系統的建設、更新升級、大型變更都必須通過數據治理項目小組的審批，極端情況下甚至可以考慮任何數據變更都必須審批。集中化的控制的好處是，首先可以集中技術和業務相關領域的專家的意見，其次可以限制執行層面的IT人員和業務人員的隨意性、不嚴謹性，再次向監管層提供了從全局和長遠的角度看系統的機會。
4. 交流：即溝通，是跨部門的跨領域的溝通。對傳統IT的最大挑戰就是跨組織跨領域的溝通交流，而數據治理委員會這樣一個跨越了IT部門和業務部門的虛擬組織，通過建立例行的交流機制，保證了信息在整個組織範圍內的透明，這種透明性保證了所有參與者的步調一致的，保證了業務數據的一致性。交流滲透在前面所述的四點數據治理活動中，是它們成功的保障。
5. 整合：這是我們的目標同時也是解決之道，主要抓住三個方面的整合——信息的整合，資源的整合，能力的整合。通過信息的整合把分散的業務數據整合到一個一致的沒有歧義的體系中來；通過資源的整合把企業IT資源集中調配；通過能力的整合，將平臺的運算能力，業務數據處理能力集中管理，建立一種集中服務的模式，即提高了硬件利用率、人員工作效率又利於IT對各業務部門服務的成本覈算。
“數據事故”分析
爲了解決數據事故問題，筆者協調財務、計劃、銷售、IT等部門成立了專門的“數據治理”項目小組。數據事故，應該是由於數據的素質低劣造成的，根據調查機構Gartner稱，《財富》一千家大型企業所持有的數據，有超過四分一是不準確、不完整或重複的，並預期有四分之三的大型企業直到2010年前也不會或難以改善內部數據的素質。其實沒有一家企業不受數據素質問題困擾，但就算有公司意識到問題所在，也常常會低估問題的嚴重性。何況，數據素質會受多個因素影響而變化。因此，要應付這種挑戰，一次性的行動難以奏效，企業務必持之以恆，甚至採取能改寫企業文化的行動纔會有效。
Gartner研究顯示，良莠不齊的客戶數據可造成重大損失，包括流失客戶，以及由處理直銷郵件不善和錯過銷售機會所造成的浪費等。現時很多企業亦發現劣質數據不單打擊銷售及市場推廣，更會波及最具策略性的業務活動。後勤部門的運作，例如制定預算、生產及分銷也會受到影響。
解決劣質數據問題不只只是一個IT的問題。雖然IT有助將之改善，但企業管理纔是關鍵所在，例如企業文化對數據素質就有很大的影響力。
數據治理，需要對數據的素質提出一個定義，筆者認爲數據素質涵蓋以下多方面：
ü 存在 (即企業到底有沒有某一項數據)
ü 合法性 (即該項數據的數值是否符合一個可接受的範圍)
ü 一貫性 (例如同一項數據不論儲存在哪一個地點都有同一數值)
ü 整全性 (數據元素與不同數據集之間關係的完整程度)
ü 準確性 (該項數據是否能夠描述它應表達的東西)
ü 關聯性 (該項數據能否恰當地支援業務宗旨)
ü 時間性 (即該項數據是否能夠及時地被反應出來)
針對以上數據的素質，再結合DRP系統中的相關模塊，對DRP系統中數據問題按模塊分別分析。該分析表格如下：
|
| 採購 | 訂貨 | 直營 | 門店 | 價格 | 倉儲物流 | |
| 存在 | Y | Y | Y | Y | Y | Y | Y |
| 合法性 | Y | Y | Y | Y | Y | Y | Y |
| 一貫性 | Y | Y | Y | N | N | N | Y |
| 整全性 | N | Y | Y | Y | N | Y | Y |
| 準確性 | N | N | N | N | N | N | N |
| 關聯性 | Y | Y | Y | Y | Y | N | N |
| 時間性 | N | Y | N | N | N | N | N |
以上各模塊中，達到相應的數據素質目標即爲Y，否則爲N。經過對DRP系統中的各個模塊的數據素質調查發現：數據治理主要針對的是數據的準確性、時間性、關聯性。進一步對數據事故的原因分析，發現數據出問題往往是因爲對數據的應用不夠充分。比如物流配送，根據銷售和庫存信息來做，首先銷售的信息，每天系統裏面的銷售信息和銀行回款對比，有沒有差異，沒有差異就是對的。第二，配送是根據系統去配。慢慢的精細化，以前可能是粗放的，現在是一個環節套一個環節，根據這個系統來做，慢慢數據就會越來越準確。百分之百的準確不可能，當然也沒有必要，因爲隨便一個環節都有可能出現串碼。
但如果業務部門發現DRP系統不管用，但DRP使用者就會用自己祕密地使用自己“更方便更可靠的工作流程/做法”。而管理層認爲既然沒有發生什麼不妥，也就睜一隻眼，閉一隻眼。其實，任何繞道DRP系統的工作流程/做法都會產生DRP數據流之外的“數據暗流”。這種“數據暗流”會削弱企業對流程的控制，損害企業對流程的管理和進一步優化，自然DRP系統的數據準確性就更差了。那麼，我們又怎樣保證及時數據更新和避免繞道DRP的祕密的“更方便更可靠的工作流程/做法”呢?解決方案原則上很簡單：持續提高數據準確率，定期維護訂單修訂等系統參數，以確保DRP產生的數據流與實際運作相符，通過基於DRP的工作流程的改進，禁止任何繞道DRP的行爲。
同時，借鑑了業內同行的“數據事故”分析方法，可以得到如下的因果圖：
針對上述發現的各種原因，經過進一步的統計與分析，發現主要的問題在審覈流程缺失，KPI指標設定不完善、考覈與處罰機制沒有執行、指定時間內的數據不到位、業務不熟悉、操作不當上。相反，由於系統原因造成的DRP數據錯誤很少。而像流程原因導致數據錯誤出現的次數只佔20%，但由於流程原因出現的數據錯誤影響程度最大。而像操作不當、指定時間內的數據不到位的情況出現較頻繁，但對數據錯誤的影響有限。
數據治理方案
採用上述的數據治理理論，在經過“數據事故”的教訓之後，發現上述數據問題，分別針對時間因素、流程、數據基礎、考覈機制、人員、系統制定數據治理方案，並強調方案的執行、監督、控制職能，加強各業務人員溝通，達到數據治理的目的。
考覈機制：數據治理的問題其實也是企業管理的問題，而出現問題往往是沒有一個比較好的考覈與激勵機制。在數據事故當中，出了問題之後，IT人員急着去查找原因，財務部門則因爲數據報表出不來而乾着急，而往往是事故責任部門往往是數據生產部門，而不是數據消費部門。所以，沒有好的考覈機制，往往事故在出現了之後無據可依地進行處罰，導致員工情緒極大。因此，我們定製瞭如下考覈辦法：每月結束，涉及到DRP系統中數據操作的，出現錯誤次數在5次(含5次)以上的，每次罰款10元，充入公司獎金池；如果每月操作零錯誤的，則從獎金池內獎勵30元；各部門的年度KPI指標中加入DRP系統數據操作正確率，並給予一定的權重，此舉目的就是爲了能夠使各業務部門經理引起對DRP系統數據操作正確性的重視。
人員：人員責任心不強的問題，可以由前面的考覈機制來加強，而且由於數據操作涉及到部門的績效，因此，各業務部門經理也會加強在這方面的監督；對於操作不當，業務不熟悉的情況，可以歸結爲培訓不夠。對於培訓我們分爲兩大塊：一是新員工培訓，這包括老員工調職到新崗位，新員工如果需要操作DRP系統，必須經過IT部的上崗培訓方可開設DRP系統賬號，否則的話，將無權對DRP系統進行操作；還有就是專場培訓，這也有兩類，一類是專門的計算機基礎教育培訓，這裏會包括一些計算機基礎操作，基本故障處理；另一類是公司業務流程培訓，針對各個不同崗位的人員，將公司的業務流程整合起來講，讓各業務人員知道自己上下游的業務流程是什麼？如果有異常如何處理等，同時培訓由人力資源部培訓組與IT部共同負責，所有培訓考勤、反饋、考覈情況都記入員工培訓檔案，講師則由IT部門、業務部門經理分別承擔；如果是針對各業務經理的培訓，也會請外部的流程、IT專家來擔任。
系統：系統的問題，主要通過兩方面控制：一是加強測試，所有的系統升級都必須經過公司內部的程序員測試，撰寫測試報告，經由IT經理審批之後方可將升級包更新到DRP系統中去，如果由於升級原因造成系統邏輯問題造成的數據錯誤，必須由程序員與IT經理分別承擔責任，根據每次事故的問題嚴重性，每次罰款30—300不等，同時IT部門的KPI指標中也加入系統數據事故的次數進行考覈。二是對於關鍵服務器、網絡設備的突然當機等情況的處理，這些方案可以根據IT部門的原有處置與考覈機制進行。
數據基礎：基礎數據質量差，這就是對數據生產部門提出需求，必須控制數據質量，完善公司數據規格說明，對於必須填寫的數據，由IT部門定期出具數據質量審計報告，對數據生產部門進行考覈。對於數據錄入準確率低的問題，一是採用條碼、掃描等技術手段來加強數據質量，二是通過加強人員責任心來保證，三則是通過數據審覈，下游業務流程一定要加強對數據的審覈與比對，特別是在分公司，由財務、倉管、數據員三方進行數據確認，以保證數據與業務的同步。
流程：物流是最頭痛的問題，也是處理起來最難的問題，其實關於業務流程管理(BPM)是一個很大的話題，在這裏呢，只能說是，根據企業實際情況，一點點的改進，因爲流程改進是一個傷筋動骨的事情，包括：原有流程是合適企業應用的，但現在不合適了怎麼辦？原來的流程是由某個部門負責的，現在職能要細化，要分開怎麼辦？所以在這裏就不再鋪開來講，但以後有機會進一步進行論述。
時間因素：時間因素，主要在於企業的動作效率，也是對於員工的一個考覈指標，這方面沒有太大的難度，我們主要也是將時間作爲數據生產部門的一個指標來考覈，如：計劃部門必須在訂貨單的2小時之內將訂貨單貨配發出去；專賣店如果有DRP系統，必須在當天將銷售數據傳回，如果沒有DRP系統，則傳真數據必須在當天傳回，當地辦事處必須在第二天上午11：00之前將銷售數據做到DRP系統中；客服部必須在12小時內將客戶數據錄入到DRP系統中，對於客戶的禮品申請，必須在兩個工作日內處理完畢，並給客戶回覆等。
上述所有的針對問題的解決方案都離不開執行、監督、控制與交流。在這幾個環節當中，IT部門與行政部門爲主要的執行主體，IT部門負責對DRP系統中的數據異常或每月數據質量出具報告，行政部門則根據IT部門的報告和數據質量方面的制度，給業務部門的KPI指標進行評定，也針對操作人員進行具體的獎罰；同時在培訓這一塊，由人力資源部門與IT部門負責完成。
而IT部門的系統故障及錯誤等問題，則落實到財務部與行政部具體負責進行考覈，這也就是一個監督機制，IT部門作爲DRP系統的管理者，也是要被各個業務部門進行監督的。
而由於涉及到各個業務部門的各個業務環節，特別在加入了績效考覈之後，會引起業務部門對IT部門的敵視，甚至是對DRP系統的敵視，因此，所有策略的實施都需要IT經理與數據治理項目小組的負責人加強溝通。特別是要注意循序漸進，切忌要求一步到位，否則的話引起業務部門的不滿與反彈，有可能事情會變的更糟糕。
項目管理手記(五)
DRP項目中的數據治理
由於我本人的項目經驗在DRP項目中會比較多一些，而且所談及的問題也是在DRP項目中碰到的，當然，也許我說的這個問題不只只是在DRP項目中，包括像ERP、PDM、KM等項目中都會碰上，但我還是會結合DRP項目中的實際問題來說。同時，由於本人所在的角度是甲方的角度，因此，DRP項目的週期對於甲方來說不只只是項目調研、實施、培訓，還會包括整個DRP系統的應用、部署、維護直到系統結束使用的DRP系統的整個使用週期。
DRP項目進行到後期，一般的企業都會擔心一個問題“顧問走了之後，我們怎麼辦？”。因爲如果實施顧問在現場的話，感覺都不會出什麼問題，就算有問題，顧問也解決掉了。但一旦顧問離場，DRP系統交由企業的IT部門負責運行與維護的時候，感覺問題就出的比較多了。這些問題可能會包括系統故障增多，系統運行速度減慢，軟件需求得不到響應，數據不準等。也因爲這些原因業務部門也在應用了一段時間之後感覺系統不好用了，特別是數據不準的情況經常出現，使得報表也不準了，久而久之，業務部門感覺DRP系統的價值也越來越低了，而這樣造成的直接後果就是DRP系統的使用效果打折，經常會聽到業務部門在抱怨：“這是什麼破系統嘛，出來的數據都不準!”，把數據問題與DRP系統邏輯問題相混淆，從而有可能對DRP系統本身引發了懷疑，導致DRP系統的使用週期因爲數據不準而大大縮短。
“數據事故”引發的數據治理思考
套用一句老話：“ERP是三分軟件、七分實施、十分努力、十二分數據、百分百的領導支持”。其實筆者一直在實施DRP項目的過程中，都有碰到多或多或少的數據問題，但應該都是小問題，所影響的範圍也不大，或者通過DRP系統的一些異常處理功能也就能夠解決的，如：退貨單出現的退貨價格不準確的問題，只要對這張單據進行廢除重做就好了，直到筆者碰到兩次重大的“數據事故”，纔對DRP項目的數據治理工作引發了重視與思考。
第一件事情是由於產品中心對新產品定價錯誤引發的“數據事故”。一直以來，新產品的定價是由產品中心會同財務、銷售、計劃等部門一起制定的，而且制定的是產品的零售價，然後根據零售價的折率分別倒推定製分銷價、出廠價、採購價，而採購價也是一個基準價，也就是說，產品的採購必須低於這個價格，否則的話公司是不會批准對這款產品進行投產的。在年度某季度新產品定價時，公司各部門定製出了當季產品的各種價格，並已經在系統中進行實施，但隨之而來的是，發現在市場對於當季產品的價格反映是偏高，而且代理商也認爲當季產品的分銷價格(即代理商進貨價)太高，所以公司決定對該款產品進行重新定價。隨之而來的就是要求DRP系統中對所有業務環節中的價格進行調整，包括對已經配送到分公司、代理商的產品進行重新調價，對已經配送到直營店，在倉庫中未銷售的產品進行價格調整。這一次的調整由於影響極大，導致公司各業務部門不得不集中人馬加班對數據進行調整，而且調整結束之後，在下月的系統過賬中發現財務報表總是有些出入，才發現數據調整有問題，有些調過來了，有些沒有調整過來，有些調整的時候產品已經銷售出去了，有的產品是退貨的，但成本卻沒有改過來，總之是亂的一團麻，使的該月的財務報表不得不在財務部門的要求下，各業務部門簽字覈定是由於操作不當引起的數據統計問題。本次問題其實是一個業務規範性的問題，或者是系統強壯型問題，如果業務夠規範，不會出現這種在產品進行銷售時更改產品成本的問題，或者系統足夠強壯，能夠對數據變更做出及時處理，這次事故應該也是能夠避免的。
第二件事是由於分公司內部管理、控制不到位及流程缺失導致的“數據事故”。記得當時還在外面開會，被財務總監電話催回公司，說是公司領導要求我今天準備一下，明天去華中大區出差，因爲當地分公司的本月的財務、系統數據都有嚴重問題，估計賬實不符情況嚴重，需要過去核查一下問題到底出在哪裏。第二天，當公司的財務、計劃、IT三部門人員到達華中大區所在地時，開始安排了對本大區所有的庫存盤點的工作，首先是對直營店進行盤點，全部由總部人員進行監督，經過五個晚上的盤點之後，再用了四天時間對大區的庫房進行盤點，發現：直營店的手工賬務與DRP系統中的數據不符情況嚴重，而直營店的手工賬務與實際庫存情況相差無幾，直營店也較好地執行了失貨賠償制度。而DRP系統中的數據與實際庫存嚴重不符的原因在於：大區的倉庫管理人員、數據員都沒有及時將直營店的退貨、銷售、調撥單據進行處理，以致直營店數據失真；同時對大區的庫存盤點時發現：大區的庫存結構不合理，庫存過大，直營店的過季產品處理不及時，數據員沒有對倉庫數據進行及時分析及利用。同時，大區的財務人員也沒有根據DRP系統中的數據進行財務數據覈對，以至於倉庫、數據、財務的工作脫節，形成了大區庫房管理工作出現了失控。這次事故經過審覈之後，上報到公司領導，下定決心對相關責任人進行了處罰，而也是在這次“數據事故”之後引發了筆者對於如何進行DRP系統“數據治理”的思考。
數據治理的理論及方法
項目小組總結之後，通過查找相關資料發現：數據治理其實是一種體系，是一個關注於信息系統執行層面的體系，這一體系的目的是整合IT與業務部門的知識和意見，通過一個類似於監督委員會或項目小組的虛擬組織對企業的信息化建設進行全方位的監管，這一組織的基礎是企業高層的授權和業務部門與IT部門的建設性合作。從範圍來講，數據治理涵蓋了從前端事務處理系統，後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
1. 發現：即發現問題和差異（Issues & Gaps），這是監管的基本職能。我們一定要在萌芽階段發現問題和差異，將其扼殺在苗頭。那麼如何去發現呢？
對於待建或在建的系統，要建立專家審覈制度，所謂專家包括技術專家和業務專家，如果本組織不具備條件則可以邀請第三方的顧問來參與系統數據的架構和設計決策，但根本原則是任何專家必須是相關領域的專業人士。
對於已建成使用的系統，則關鍵是IT的日常運維工作的規範化，主要包括規範的問題管理（Trouble Management），週期性審計(Periodic Review)。前者是爲了文檔化各種系統問題和缺陷，以及相應的IT判斷和響應；後者是爲了及時對系統的問題和缺陷做出歸納總結，找出規律而從根本上解決問題。
2. 監督：即持續的保持對業務數據健康狀況的跟蹤。監督主要通過週期性的數據分析來完成，市場上也有很多自動化的工具可以幫助您方便的對數據的健康狀況進行分析。與發現所不同的是，監督是主動的去發掘問題，而且在發現問題後立即採取行動去修正它。
3. 控制：即掌握信息系統建設的決策權。任何信息系統的建設、更新升級、大型變更都必須通過數據治理項目小組的審批，極端情況下甚至可以考慮任何數據變更都必須審批。集中化的控制的好處是，首先可以集中技術和業務相關領域的專家的意見，其次可以限制執行層面的IT人員和業務人員的隨意性、不嚴謹性，再次向監管層提供了從全局和長遠的角度看系統的機會。
4. 交流：即溝通，是跨部門的跨領域的溝通。對傳統IT的最大挑戰就是跨組織跨領域的溝通交流，而數據治理委員會這樣一個跨越了IT部門和業務部門的虛擬組織，通過建立例行的交流機制，保證了信息在整個組織範圍內的透明，這種透明性保證了所有參與者的步調一致的，保證了業務數據的一致性。交流滲透在前面所述的四點數據治理活動中，是它們成功的保障。
5. 整合：這是我們的目標同時也是解決之道，主要抓住三個方面的整合——信息的整合，資源的整合，能力的整合。通過信息的整合把分散的業務數據整合到一個一致的沒有歧義的體系中來；通過資源的整合把企業IT資源集中調配；通過能力的整合，將平臺的運算能力，業務數據處理能力集中管理，建立一種集中服務的模式，即提高了硬件利用率、人員工作效率又利於IT對各業務部門服務的成本覈算。
“數據事故”分析
爲了解決數據事故問題，筆者協調財務、計劃、銷售、IT等部門成立了專門的“數據治理”項目小組。數據事故，應該是由於數據的素質低劣造成的，根據調查機構Gartner稱，《財富》一千家大型企業所持有的數據，有超過四分一是不準確、不完整或重複的，並預期有四分之三的大型企業直到2010年前也不會或難以改善內部數據的素質。其實沒有一家企業不受數據素質問題困擾，但就算有公司意識到問題所在，也常常會低估問題的嚴重性。何況，數據素質會受多個因素影響而變化。因此，要應付這種挑戰，一次性的行動難以奏效，企業務必持之以恆，甚至採取能改寫企業文化的行動纔會有效。
Gartner研究顯示，良莠不齊的客戶數據可造成重大損失，包括流失客戶，以及由處理直銷郵件不善和錯過銷售機會所造成的浪費等。現時很多企業亦發現劣質數據不單打擊銷售及市場推廣，更會波及最具策略性的業務活動。後勤部門的運作，例如制定預算、生產及分銷也會受到影響。
解決劣質數據問題不只只是一個IT的問題。雖然IT有助將之改善，但企業管理纔是關鍵所在，例如企業文化對數據素質就有很大的影響力。
數據治理，需要對數據的素質提出一個定義，筆者認爲數據素質涵蓋以下多方面：
ü 存在 (即企業到底有沒有某一項數據)
ü 合法性 (即該項數據的數值是否符合一個可接受的範圍)
ü 一貫性 (例如同一項數據不論儲存在哪一個地點都有同一數值)
ü 整全性 (數據元素與不同數據集之間關係的完整程度)
ü 準確性 (該項數據是否能夠描述它應表達的東西)
ü 關聯性 (該項數據能否恰當地支援業務宗旨)
ü 時間性 (即該項數據是否能夠及時地被反應出來)
針對以上數據的素質，再結合DRP系統中的相關模塊，對DRP系統中數據問題按模塊分別分析。該分析表格如下：
|
| 採購 | 訂貨 | 直營 | 門店 | 價格 | 倉儲物流 | |
| 存在 | Y | Y | Y | Y | Y | Y | Y |
| 合法性 | Y | Y | Y | Y | Y | Y | Y |
| 一貫性 | Y | Y | Y | N | N | N | Y |
| 整全性 | N | Y | Y | Y | N | Y | Y |
| 準確性 | N | N | N | N | N | N | N |
| 關聯性 | Y | Y | Y | Y | Y | N | N |
| 時間性 | N | Y | N | N | N | N | N |
以上各模塊中，達到相應的數據素質目標即爲Y，否則爲N。經過對DRP系統中的各個模塊的數據素質調查發現：數據治理主要針對的是數據的準確性、時間性、關聯性。進一步對數據事故的原因分析，發現數據出問題往往是因爲對數據的應用不夠充分。比如物流配送，根據銷售和庫存信息來做，首先銷售的信息，每天系統裏面的銷售信息和銀行回款對比，有沒有差異，沒有差異就是對的。第二，配送是根據系統去配。慢慢的精細化，以前可能是粗放的，現在是一個環節套一個環節，根據這個系統來做，慢慢數據就會越來越準確。百分之百的準確不可能，當然也沒有必要，因爲隨便一個環節都有可能出現串碼。
但如果業務部門發現DRP系統不管用，但DRP使用者就會用自己祕密地使用自己“更方便更可靠的工作流程/做法”。而管理層認爲既然沒有發生什麼不妥，也就睜一隻眼，閉一隻眼。其實，任何繞道DRP系統的工作流程/做法都會產生DRP數據流之外的“數據暗流”。這種“數據暗流”會削弱企業對流程的控制，損害企業對流程的管理和進一步優化，自然DRP系統的數據準確性就更差了。那麼，我們又怎樣保證及時數據更新和避免繞道DRP的祕密的“更方便更可靠的工作流程/做法”呢?解決方案原則上很簡單：持續提高數據準確率，定期維護訂單修訂等系統參數，以確保DRP產生的數據流與實際運作相符，通過基於DRP的工作流程的改進，禁止任何繞道DRP的行爲。
同時，借鑑了業內同行的“數據事故”分析方法，可以得到如下的因果圖：
針對上述發現的各種原因，經過進一步的統計與分析，發現主要的問題在審覈流程缺失，KPI指標設定不完善、考覈與處罰機制沒有執行、指定時間內的數據不到位、業務不熟悉、操作不當上。相反，由於系統原因造成的DRP數據錯誤很少。而像流程原因導致數據錯誤出現的次數只佔20%，但由於流程原因出現的數據錯誤影響程度最大。而像操作不當、指定時間內的數據不到位的情況出現較頻繁，但對數據錯誤的影響有限。
數據治理方案
採用上述的數據治理理論，在經過“數據事故”的教訓之後，發現上述數據問題，分別針對時間因素、流程、數據基礎、考覈機制、人員、系統制定數據治理方案，並強調方案的執行、監督、控制職能，加強各業務人員溝通，達到數據治理的目的。
考覈機制：數據治理的問題其實也是企業管理的問題，而出現問題往往是沒有一個比較好的考覈與激勵機制。在數據事故當中，出了問題之後，IT人員急着去查找原因，財務部門則因爲數據報表出不來而乾着急，而往往是事故責任部門往往是數據生產部門，而不是數據消費部門。所以，沒有好的考覈機制，往往事故在出現了之後無據可依地進行處罰，導致員工情緒極大。因此，我們定製瞭如下考覈辦法：每月結束，涉及到DRP系統中數據操作的，出現錯誤次數在5次(含5次)以上的，每次罰款10元，充入公司獎金池；如果每月操作零錯誤的，則從獎金池內獎勵30元；各部門的年度KPI指標中加入DRP系統數據操作正確率，並給予一定的權重，此舉目的就是爲了能夠使各業務部門經理引起對DRP系統數據操作正確性的重視。
人員：人員責任心不強的問題，可以由前面的考覈機制來加強，而且由於數據操作涉及到部門的績效，因此，各業務部門經理也會加強在這方面的監督；對於操作不當，業務不熟悉的情況，可以歸結爲培訓不夠。對於培訓我們分爲兩大塊：一是新員工培訓，這包括老員工調職到新崗位，新員工如果需要操作DRP系統，必須經過IT部的上崗培訓方可開設DRP系統賬號，否則的話，將無權對DRP系統進行操作；還有就是專場培訓，這也有兩類，一類是專門的計算機基礎教育培訓，這裏會包括一些計算機基礎操作，基本故障處理；另一類是公司業務流程培訓，針對各個不同崗位的人員，將公司的業務流程整合起來講，讓各業務人員知道自己上下游的業務流程是什麼？如果有異常如何處理等，同時培訓由人力資源部培訓組與IT部共同負責，所有培訓考勤、反饋、考覈情況都記入員工培訓檔案，講師則由IT部門、業務部門經理分別承擔；如果是針對各業務經理的培訓，也會請外部的流程、IT專家來擔任。
系統：系統的問題，主要通過兩方面控制：一是加強測試，所有的系統升級都必須經過公司內部的程序員測試，撰寫測試報告，經由IT經理審批之後方可將升級包更新到DRP系統中去，如果由於升級原因造成系統邏輯問題造成的數據錯誤，必須由程序員與IT經理分別承擔責任，根據每次事故的問題嚴重性，每次罰款30—300不等，同時IT部門的KPI指標中也加入系統數據事故的次數進行考覈。二是對於關鍵服務器、網絡設備的突然當機等情況的處理，這些方案可以根據IT部門的原有處置與考覈機制進行。
數據基礎：基礎數據質量差，這就是對數據生產部門提出需求，必須控制數據質量，完善公司數據規格說明，對於必須填寫的數據，由IT部門定期出具數據質量審計報告，對數據生產部門進行考覈。對於數據錄入準確率低的問題，一是採用條碼、掃描等技術手段來加強數據質量，二是通過加強人員責任心來保證，三則是通過數據審覈，下游業務流程一定要加強對數據的審覈與比對，特別是在分公司，由財務、倉管、數據員三方進行數據確認，以保證數據與業務的同步。
流程：物流是最頭痛的問題，也是處理起來最難的問題，其實關於業務流程管理(BPM)是一個很大的話題，在這裏呢，只能說是，根據企業實際情況，一點點的改進，因爲流程改進是一個傷筋動骨的事情，包括：原有流程是合適企業應用的，但現在不合適了怎麼辦？原來的流程是由某個部門負責的，現在職能要細化，要分開怎麼辦？所以在這裏就不再鋪開來講，但以後有機會進一步進行論述。
時間因素：時間因素，主要在於企業的動作效率，也是對於員工的一個考覈指標，這方面沒有太大的難度，我們主要也是將時間作爲數據生產部門的一個指標來考覈，如：計劃部門必須在訂貨單的2小時之內將訂貨單貨配發出去；專賣店如果有DRP系統，必須在當天將銷售數據傳回，如果沒有DRP系統，則傳真數據必須在當天傳回，當地辦事處必須在第二天上午11：00之前將銷售數據做到DRP系統中；客服部必須在12小時內將客戶數據錄入到DRP系統中，對於客戶的禮品申請，必須在兩個工作日內處理完畢，並給客戶回覆等。
上述所有的針對問題的解決方案都離不開執行、監督、控制與交流。在這幾個環節當中，IT部門與行政部門爲主要的執行主體，IT部門負責對DRP系統中的數據異常或每月數據質量出具報告，行政部門則根據IT部門的報告和數據質量方面的制度，給業務部門的KPI指標進行評定，也針對操作人員進行具體的獎罰；同時在培訓這一塊，由人力資源部門與IT部門負責完成。
而IT部門的系統故障及錯誤等問題，則落實到財務部與行政部具體負責進行考覈，這也就是一個監督機制，IT部門作爲DRP系統的管理者，也是要被各個業務部門進行監督的。
而由於涉及到各個業務部門的各個業務環節，特別在加入了績效考覈之後，會引起業務部門對IT部門的敵視，甚至是對DRP系統的敵視，因此，所有策略的實施都需要IT經理與數據治理項目小組的負責人加強溝通。特別是要注意循序漸進，切忌要求一步到位，否則的話引起業務部門的不滿與反彈，有可能事情會變的更糟糕。
項目管理手記(五)
DRP項目中的數據治理
由於我本人的項目經驗在DRP項目中會比較多一些，而且所談及的問題也是在DRP項目中碰到的，當然，也許我說的這個問題不只只是在DRP項目中，包括像ERP、PDM、KM等項目中都會碰上，但我還是會結合DRP項目中的實際問題來說。同時，由於本人所在的角度是甲方的角度，因此，DRP項目的週期對於甲方來說不只只是項目調研、實施、培訓，還會包括整個DRP系統的應用、部署、維護直到系統結束使用的DRP系統的整個使用週期。
DRP項目進行到後期，一般的企業都會擔心一個問題“顧問走了之後，我們怎麼辦？”。因爲如果實施顧問在現場的話，感覺都不會出什麼問題，就算有問題，顧問也解決掉了。但一旦顧問離場，DRP系統交由企業的IT部門負責運行與維護的時候，感覺問題就出的比較多了。這些問題可能會包括系統故障增多，系統運行速度減慢，軟件需求得不到響應，數據不準等。也因爲這些原因業務部門也在應用了一段時間之後感覺系統不好用了，特別是數據不準的情況經常出現，使得報表也不準了，久而久之，業務部門感覺DRP系統的價值也越來越低了，而這樣造成的直接後果就是DRP系統的使用效果打折，經常會聽到業務部門在抱怨：“這是什麼破系統嘛，出來的數據都不準!”，把數據問題與DRP系統邏輯問題相混淆，從而有可能對DRP系統本身引發了懷疑，導致DRP系統的使用週期因爲數據不準而大大縮短。
“數據事故”引發的數據治理思考
套用一句老話：“ERP是三分軟件、七分實施、十分努力、十二分數據、百分百的領導支持”。其實筆者一直在實施DRP項目的過程中，都有碰到多或多或少的數據問題，但應該都是小問題，所影響的範圍也不大，或者通過DRP系統的一些異常處理功能也就能夠解決的，如：退貨單出現的退貨價格不準確的問題，只要對這張單據進行廢除重做就好了，直到筆者碰到兩次重大的“數據事故”，纔對DRP項目的數據治理工作引發了重視與思考。
第一件事情是由於產品中心對新產品定價錯誤引發的“數據事故”。一直以來，新產品的定價是由產品中心會同財務、銷售、計劃等部門一起制定的，而且制定的是產品的零售價，然後根據零售價的折率分別倒推定製分銷價、出廠價、採購價，而採購價也是一個基準價，也就是說，產品的採購必須低於這個價格，否則的話公司是不會批准對這款產品進行投產的。在年度某季度新產品定價時，公司各部門定製出了當季產品的各種價格，並已經在系統中進行實施，但隨之而來的是，發現在市場對於當季產品的價格反映是偏高，而且代理商也認爲當季產品的分銷價格(即代理商進貨價)太高，所以公司決定對該款產品進行重新定價。隨之而來的就是要求DRP系統中對所有業務環節中的價格進行調整，包括對已經配送到分公司、代理商的產品進行重新調價，對已經配送到直營店，在倉庫中未銷售的產品進行價格調整。這一次的調整由於影響極大，導致公司各業務部門不得不集中人馬加班對數據進行調整，而且調整結束之後，在下月的系統過賬中發現財務報表總是有些出入，才發現數據調整有問題，有些調過來了，有些沒有調整過來，有些調整的時候產品已經銷售出去了，有的產品是退貨的，但成本卻沒有改過來，總之是亂的一團麻，使的該月的財務報表不得不在財務部門的要求下，各業務部門簽字覈定是由於操作不當引起的數據統計問題。本次問題其實是一個業務規範性的問題，或者是系統強壯型問題，如果業務夠規範，不會出現這種在產品進行銷售時更改產品成本的問題，或者系統足夠強壯，能夠對數據變更做出及時處理，這次事故應該也是能夠避免的。
第二件事是由於分公司內部管理、控制不到位及流程缺失導致的“數據事故”。記得當時還在外面開會，被財務總監電話催回公司，說是公司領導要求我今天準備一下，明天去華中大區出差，因爲當地分公司的本月的財務、系統數據都有嚴重問題，估計賬實不符情況嚴重，需要過去核查一下問題到底出在哪裏。第二天，當公司的財務、計劃、IT三部門人員到達華中大區所在地時，開始安排了對本大區所有的庫存盤點的工作，首先是對直營店進行盤點，全部由總部人員進行監督，經過五個晚上的盤點之後，再用了四天時間對大區的庫房進行盤點，發現：直營店的手工賬務與DRP系統中的數據不符情況嚴重，而直營店的手工賬務與實際庫存情況相差無幾，直營店也較好地執行了失貨賠償制度。而DRP系統中的數據與實際庫存嚴重不符的原因在於：大區的倉庫管理人員、數據員都沒有及時將直營店的退貨、銷售、調撥單據進行處理，以致直營店數據失真；同時對大區的庫存盤點時發現：大區的庫存結構不合理，庫存過大，直營店的過季產品處理不及時，數據員沒有對倉庫數據進行及時分析及利用。同時，大區的財務人員也沒有根據DRP系統中的數據進行財務數據覈對，以至於倉庫、數據、財務的工作脫節，形成了大區庫房管理工作出現了失控。這次事故經過審覈之後，上報到公司領導，下定決心對相關責任人進行了處罰，而也是在這次“數據事故”之後引發了筆者對於如何進行DRP系統“數據治理”的思考。
數據治理的理論及方法
項目小組總結之後，通過查找相關資料發現：數據治理其實是一種體系，是一個關注於信息系統執行層面的體系，這一體系的目的是整合IT與業務部門的知識和意見，通過一個類似於監督委員會或項目小組的虛擬組織對企業的信息化建設進行全方位的監管，這一組織的基礎是企業高層的授權和業務部門與IT部門的建設性合作。從範圍來講，數據治理涵蓋了從前端事務處理系統，後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
1. 發現：即發現問題和差異（Issues & Gaps），這是監管的基本職能。我們一定要在萌芽階段發現問題和差異，將其扼殺在苗頭。那麼如何去發現呢？
對於待建或在建的系統，要建立專家審覈制度，所謂專家包括技術專家和業務專家，如果本組織不具備條件則可以邀請第三方的顧問來參與系統數據的架構和設計決策，但根本原則是任何專家必須是相關領域的專業人士。
對於已建成使用的系統，則關鍵是IT的日常運維工作的規範化，主要包括規範的問題管理（Trouble Management），週期性審計(Periodic Review)。前者是爲了文檔化各種系統問題和缺陷，以及相應的IT判斷和響應；後者是爲了及時對系統的問題和缺陷做出歸納總結，找出規律而從根本上解決問題。
2. 監督：即持續的保持對業務數據健康狀況的跟蹤。監督主要通過週期性的數據分析來完成，市場上也有很多自動化的工具可以幫助您方便的對數據的健康狀況進行分析。與發現所不同的是，監督是主動的去發掘問題，而且在發現問題後立即採取行動去修正它。
3. 控制：即掌握信息系統建設的決策權。任何信息系統的建設、更新升級、大型變更都必須通過數據治理項目小組的審批，極端情況下甚至可以考慮任何數據變更都必須審批。集中化的控制的好處是，首先可以集中技術和業務相關領域的專家的意見，其次可以限制執行層面的IT人員和業務人員的隨意性、不嚴謹性，再次向監管層提供了從全局和長遠的角度看系統的機會。
4. 交流：即溝通，是跨部門的跨領域的溝通。對傳統IT的最大挑戰就是跨組織跨領域的溝通交流，而數據治理委員會這樣一個跨越了IT部門和業務部門的虛擬組織，通過建立例行的交流機制，保證了信息在整個組織範圍內的透明，這種透明性保證了所有參與者的步調一致的，保證了業務數據的一致性。交流滲透在前面所述的四點數據治理活動中，是它們成功的保障。
5. 整合：這是我們的目標同時也是解決之道，主要抓住三個方面的整合——信息的整合，資源的整合，能力的整合。通過信息的整合把分散的業務數據整合到一個一致的沒有歧義的體系中來；通過資源的整合把企業IT資源集中調配；通過能力的整合，將平臺的運算能力，業務數據處理能力集中管理，建立一種集中服務的模式，即提高了硬件利用率、人員工作效率又利於IT對各業務部門服務的成本覈算。
“數據事故”分析
爲了解決數據事故問題，筆者協調財務、計劃、銷售、IT等部門成立了專門的“數據治理”項目小組。數據事故，應該是由於數據的素質低劣造成的，根據調查機構Gartner稱，《財富》一千家大型企業所持有的數據，有超過四分一是不準確、不完整或重複的，並預期有四分之三的大型企業直到2010年前也不會或難以改善內部數據的素質。其實沒有一家企業不受數據素質問題困擾，但就算有公司意識到問題所在，也常常會低估問題的嚴重性。何況，數據素質會受多個因素影響而變化。因此，要應付這種挑戰，一次性的行動難以奏效，企業務必持之以恆，甚至採取能改寫企業文化的行動纔會有效。
Gartner研究顯示，良莠不齊的客戶數據可造成重大損失，包括流失客戶，以及由處理直銷郵件不善和錯過銷售機會所造成的浪費等。現時很多企業亦發現劣質數據不單打擊銷售及市場推廣，更會波及最具策略性的業務活動。後勤部門的運作，例如制定預算、生產及分銷也會受到影響。
解決劣質數據問題不只只是一個IT的問題。雖然IT有助將之改善，但企業管理纔是關鍵所在，例如企業文化對數據素質就有很大的影響力。
數據治理，需要對數據的素質提出一個定義，筆者認爲數據素質涵蓋以下多方面：
ü 存在 (即企業到底有沒有某一項數據)
ü 合法性 (即該項數據的數值是否符合一個可接受的範圍)
ü 一貫性 (例如同一項數據不論儲存在哪一個地點都有同一數值)
ü 整全性 (數據元素與不同數據集之間關係的完整程度)
ü 準確性 (該項數據是否能夠描述它應表達的東西)
ü 關聯性 (該項數據能否恰當地支援業務宗旨)
ü 時間性 (即該項數據是否能夠及時地被反應出來)
針對以上數據的素質，再結合DRP系統中的相關模塊，對DRP系統中數據問題按模塊分別分析。該分析表格如下：
|
| 採購 | 訂貨 | 直營 | 門店 | 價格 | 倉儲物流 | |
| 存在 | Y | Y | Y | Y | Y | Y | Y |
| 合法性 | Y | Y | Y | Y | Y | Y | Y |
| 一貫性 | Y | Y | Y | N | N | N | Y |
| 整全性 | N | Y | Y | Y | N | Y | Y |
| 準確性 | N | N | N | N | N | N | N |
| 關聯性 | Y | Y | Y | Y | Y | N | N |
| 時間性 | N | Y | N | N | N | N | N |
以上各模塊中，達到相應的數據素質目標即爲Y，否則爲N。經過對DRP系統中的各個模塊的數據素質調查發現：數據治理主要針對的是數據的準確性、時間性、關聯性。進一步對數據事故的原因分析，發現數據出問題往往是因爲對數據的應用不夠充分。比如物流配送，根據銷售和庫存信息來做，首先銷售的信息，每天系統裏面的銷售信息和銀行回款對比，有沒有差異，沒有差異就是對的。第二，配送是根據系統去配。慢慢的精細化，以前可能是粗放的，現在是一個環節套一個環節，根據這個系統來做，慢慢數據就會越來越準確。百分之百的準確不可能，當然也沒有必要，因爲隨便一個環節都有可能出現串碼。
但如果業務部門發現DRP系統不管用，但DRP使用者就會用自己祕密地使用自己“更方便更可靠的工作流程/做法”。而管理層認爲既然沒有發生什麼不妥，也就睜一隻眼，閉一隻眼。其實，任何繞道DRP系統的工作流程/做法都會產生DRP數據流之外的“數據暗流”。這種“數據暗流”會削弱企業對流程的控制，損害企業對流程的管理和進一步優化，自然DRP系統的數據準確性就更差了。那麼，我們又怎樣保證及時數據更新和避免繞道DRP的祕密的“更方便更可靠的工作流程/做法”呢?解決方案原則上很簡單：持續提高數據準確率，定期維護訂單修訂等系統參數，以確保DRP產生的數據流與實際運作相符，通過基於DRP的工作流程的改進，禁止任何繞道DRP的行爲。
同時，借鑑了業內同行的“數據事故”分析方法，可以得到如下的因果圖：
針對上述發現的各種原因，經過進一步的統計與分析，發現主要的問題在審覈流程缺失，KPI指標設定不完善、考覈與處罰機制沒有執行、指定時間內的數據不到位、業務不熟悉、操作不當上。相反，由於系統原因造成的DRP數據錯誤很少。而像流程原因導致數據錯誤出現的次數只佔20%，但由於流程原因出現的數據錯誤影響程度最大。而像操作不當、指定時間內的數據不到位的情況出現較頻繁，但對數據錯誤的影響有限。
數據治理方案
採用上述的數據治理理論，在經過“數據事故”的教訓之後，發現上述數據問題，分別針對時間因素、流程、數據基礎、考覈機制、人員、系統制定數據治理方案，並強調方案的執行、監督、控制職能，加強各業務人員溝通，達到數據治理的目的。
考覈機制：數據治理的問題其實也是企業管理的問題，而出現問題往往是沒有一個比較好的考覈與激勵機制。在數據事故當中，出了問題之後，IT人員急着去查找原因，財務部門則因爲數據報表出不來而乾着急，而往往是事故責任部門往往是數據生產部門，而不是數據消費部門。所以，沒有好的考覈機制，往往事故在出現了之後無據可依地進行處罰，導致員工情緒極大。因此，我們定製瞭如下考覈辦法：每月結束，涉及到DRP系統中數據操作的，出現錯誤次數在5次(含5次)以上的，每次罰款10元，充入公司獎金池；如果每月操作零錯誤的，則從獎金池內獎勵30元；各部門的年度KPI指標中加入DRP系統數據操作正確率，並給予一定的權重，此舉目的就是爲了能夠使各業務部門經理引起對DRP系統數據操作正確性的重視。
人員：人員責任心不強的問題，可以由前面的考覈機制來加強，而且由於數據操作涉及到部門的績效，因此，各業務部門經理也會加強在這方面的監督；對於操作不當，業務不熟悉的情況，可以歸結爲培訓不夠。對於培訓我們分爲兩大塊：一是新員工培訓，這包括老員工調職到新崗位，新員工如果需要操作DRP系統，必須經過IT部的上崗培訓方可開設DRP系統賬號，否則的話，將無權對DRP系統進行操作；還有就是專場培訓，這也有兩類，一類是專門的計算機基礎教育培訓，這裏會包括一些計算機基礎操作，基本故障處理；另一類是公司業務流程培訓，針對各個不同崗位的人員，將公司的業務流程整合起來講，讓各業務人員知道自己上下游的業務流程是什麼？如果有異常如何處理等，同時培訓由人力資源部培訓組與IT部共同負責，所有培訓考勤、反饋、考覈情況都記入員工培訓檔案，講師則由IT部門、業務部門經理分別承擔；如果是針對各業務經理的培訓，也會請外部的流程、IT專家來擔任。
系統：系統的問題，主要通過兩方面控制：一是加強測試，所有的系統升級都必須經過公司內部的程序員測試，撰寫測試報告，經由IT經理審批之後方可將升級包更新到DRP系統中去，如果由於升級原因造成系統邏輯問題造成的數據錯誤，必須由程序員與IT經理分別承擔責任，根據每次事故的問題嚴重性，每次罰款30—300不等，同時IT部門的KPI指標中也加入系統數據事故的次數進行考覈。二是對於關鍵服務器、網絡設備的突然當機等情況的處理，這些方案可以根據IT部門的原有處置與考覈機制進行。
數據基礎：基礎數據質量差，這就是對數據生產部門提出需求，必須控制數據質量，完善公司數據規格說明，對於必須填寫的數據，由IT部門定期出具數據質量審計報告，對數據生產部門進行考覈。對於數據錄入準確率低的問題，一是採用條碼、掃描等技術手段來加強數據質量，二是通過加強人員責任心來保證，三則是通過數據審覈，下游業務流程一定要加強對數據的審覈與比對，特別是在分公司，由財務、倉管、數據員三方進行數據確認，以保證數據與業務的同步。
流程：物流是最頭痛的問題，也是處理起來最難的問題，其實關於業務流程管理(BPM)是一個很大的話題，在這裏呢，只能說是，根據企業實際情況，一點點的改進，因爲流程改進是一個傷筋動骨的事情，包括：原有流程是合適企業應用的，但現在不合適了怎麼辦？原來的流程是由某個部門負責的，現在職能要細化，要分開怎麼辦？所以在這裏就不再鋪開來講，但以後有機會進一步進行論述。
時間因素：時間因素，主要在於企業的動作效率，也是對於員工的一個考覈指標，這方面沒有太大的難度，我們主要也是將時間作爲數據生產部門的一個指標來考覈，如：計劃部門必須在訂貨單的2小時之內將訂貨單貨配發出去；專賣店如果有DRP系統，必須在當天將銷售數據傳回，如果沒有DRP系統，則傳真數據必須在當天傳回，當地辦事處必須在第二天上午11：00之前將銷售數據做到DRP系統中；客服部必須在12小時內將客戶數據錄入到DRP系統中，對於客戶的禮品申請，必須在兩個工作日內處理完畢，並給客戶回覆等。
上述所有的針對問題的解決方案都離不開執行、監督、控制與交流。在這幾個環節當中，IT部門與行政部門爲主要的執行主體，IT部門負責對DRP系統中的數據異常或每月數據質量出具報告，行政部門則根據IT部門的報告和數據質量方面的制度，給業務部門的KPI指標進行評定，也針對操作人員進行具體的獎罰；同時在培訓這一塊，由人力資源部門與IT部門負責完成。
而IT部門的系統故障及錯誤等問題，則落實到財務部與行政部具體負責進行考覈，這也就是一個監督機制，IT部門作爲DRP系統的管理者，也是要被各個業務部門進行監督的。
而由於涉及到各個業務部門的各個業務環節，特別在加入了績效考覈之後，會引起業務部門對IT部門的敵視，甚至是對DRP系統的敵視，因此，所有策略的實施都需要IT經理與數據治理項目小組的負責人加強溝通。特別是要注意循序漸進，切忌要求一步到位，否則的話引起業務部門的不滿與反彈，有可能事情會變的更糟糕。
項目管理手記(五)
DRP項目中的數據治理
由於我本人的項目經驗在DRP項目中會比較多一些，而且所談及的問題也是在DRP項目中碰到的，當然，也許我說的這個問題不只只是在DRP項目中，包括像ERP、PDM、KM等項目中都會碰上，但我還是會結合DRP項目中的實際問題來說。同時，由於本人所在的角度是甲方的角度，因此，DRP項目的週期對於甲方來說不只只是項目調研、實施、培訓，還會包括整個DRP系統的應用、部署、維護直到系統結束使用的DRP系統的整個使用週期。
DRP項目進行到後期，一般的企業都會擔心一個問題“顧問走了之後，我們怎麼辦？”。因爲如果實施顧問在現場的話，感覺都不會出什麼問題，就算有問題，顧問也解決掉了。但一旦顧問離場，DRP系統交由企業的IT部門負責運行與維護的時候，感覺問題就出的比較多了。這些問題可能會包括系統故障增多，系統運行速度減慢，軟件需求得不到響應，數據不準等。也因爲這些原因業務部門也在應用了一段時間之後感覺系統不好用了，特別是數據不準的情況經常出現，使得報表也不準了，久而久之，業務部門感覺DRP系統的價值也越來越低了，而這樣造成的直接後果就是DRP系統的使用效果打折，經常會聽到業務部門在抱怨：“這是什麼破系統嘛，出來的數據都不準!”，把數據問題與DRP系統邏輯問題相混淆，從而有可能對DRP系統本身引發了懷疑，導致DRP系統的使用週期因爲數據不準而大大縮短。
“數據事故”引發的數據治理思考
套用一句老話：“ERP是三分軟件、七分實施、十分努力、十二分數據、百分百的領導支持”。其實筆者一直在實施DRP項目的過程中，都有碰到多或多或少的數據問題，但應該都是小問題，所影響的範圍也不大，或者通過DRP系統的一些異常處理功能也就能夠解決的，如：退貨單出現的退貨價格不準確的問題，只要對這張單據進行廢除重做就好了，直到筆者碰到兩次重大的“數據事故”，纔對DRP項目的數據治理工作引發了重視與思考。
第一件事情是由於產品中心對新產品定價錯誤引發的“數據事故”。一直以來，新產品的定價是由產品中心會同財務、銷售、計劃等部門一起制定的，而且制定的是產品的零售價，然後根據零售價的折率分別倒推定製分銷價、出廠價、採購價，而採購價也是一個基準價，也就是說，產品的採購必須低於這個價格，否則的話公司是不會批准對這款產品進行投產的。在年度某季度新產品定價時，公司各部門定製出了當季產品的各種價格，並已經在系統中進行實施，但隨之而來的是，發現在市場對於當季產品的價格反映是偏高，而且代理商也認爲當季產品的分銷價格(即代理商進貨價)太高，所以公司決定對該款產品進行重新定價。隨之而來的就是要求DRP系統中對所有業務環節中的價格進行調整，包括對已經配送到分公司、代理商的產品進行重新調價，對已經配送到直營店，在倉庫中未銷售的產品進行價格調整。這一次的調整由於影響極大，導致公司各業務部門不得不集中人馬加班對數據進行調整，而且調整結束之後，在下月的系統過賬中發現財務報表總是有些出入，才發現數據調整有問題，有些調過來了，有些沒有調整過來，有些調整的時候產品已經銷售出去了，有的產品是退貨的，但成本卻沒有改過來，總之是亂的一團麻，使的該月的財務報表不得不在財務部門的要求下，各業務部門簽字覈定是由於操作不當引起的數據統計問題。本次問題其實是一個業務規範性的問題，或者是系統強壯型問題，如果業務夠規範，不會出現這種在產品進行銷售時更改產品成本的問題，或者系統足夠強壯，能夠對數據變更做出及時處理，這次事故應該也是能夠避免的。
第二件事是由於分公司內部管理、控制不到位及流程缺失導致的“數據事故”。記得當時還在外面開會，被財務總監電話催回公司，說是公司領導要求我今天準備一下，明天去華中大區出差，因爲當地分公司的本月的財務、系統數據都有嚴重問題，估計賬實不符情況嚴重，需要過去核查一下問題到底出在哪裏。第二天，當公司的財務、計劃、IT三部門人員到達華中大區所在地時，開始安排了對本大區所有的庫存盤點的工作，首先是對直營店進行盤點，全部由總部人員進行監督，經過五個晚上的盤點之後，再用了四天時間對大區的庫房進行盤點，發現：直營店的手工賬務與DRP系統中的數據不符情況嚴重，而直營店的手工賬務與實際庫存情況相差無幾，直營店也較好地執行了失貨賠償制度。而DRP系統中的數據與實際庫存嚴重不符的原因在於：大區的倉庫管理人員、數據員都沒有及時將直營店的退貨、銷售、調撥單據進行處理，以致直營店數據失真；同時對大區的庫存盤點時發現：大區的庫存結構不合理，庫存過大，直營店的過季產品處理不及時，數據員沒有對倉庫數據進行及時分析及利用。同時，大區的財務人員也沒有根據DRP系統中的數據進行財務數據覈對，以至於倉庫、數據、財務的工作脫節，形成了大區庫房管理工作出現了失控。這次事故經過審覈之後，上報到公司領導，下定決心對相關責任人進行了處罰，而也是在這次“數據事故”之後引發了筆者對於如何進行DRP系統“數據治理”的思考。
數據治理的理論及方法
項目小組總結之後，通過查找相關資料發現：數據治理其實是一種體系，是一個關注於信息系統執行層面的體系，這一體系的目的是整合IT與業務部門的知識和意見，通過一個類似於監督委員會或項目小組的虛擬組織對企業的信息化建設進行全方位的監管，這一組織的基礎是企業高層的授權和業務部門與IT部門的建設性合作。從範圍來講，數據治理涵蓋了從前端事務處理系統，後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
1. 發現：即發現問題和差異（Issues & Gaps），這是監管的基本職能。我們一定要在萌芽階段發現問題和差異，將其扼殺在苗頭。那麼如何去發現呢？
對於待建或在建的系統，要建立專家審覈制度，所謂專家包括技術專家和業務專家，如果本組織不具備條件則可以邀請第三方的顧問來參與系統數據的架構和設計決策，但根本原則是任何專家必須是相關領域的專業人士。
對於已建成使用的系統，則關鍵是IT的日常運維工作的規範化，主要包括規範的問題管理（Trouble Management），週期性審計(Periodic Review)。前者是爲了文檔化各種系統問題和缺陷，以及相應的IT判斷和響應；後者是爲了及時對系統的問題和缺陷做出歸納總結，找出規律而從根本上解決問題。
2. 監督：即持續的保持對業務數據健康狀況的跟蹤。監督主要通過週期性的數據分析來完成，市場上也有很多自動化的工具可以幫助您方便的對數據的健康狀況進行分析。與發現所不同的是，監督是主動的去發掘問題，而且在發現問題後立即採取行動去修正它。
3. 控制：即掌握信息系統建設的決策權。任何信息系統的建設、更新升級、大型變更都必須通過數據治理項目小組的審批，極端情況下甚至可以考慮任何數據變更都必須審批。集中化的控制的好處是，首先可以集中技術和業務相關領域的專家的意見，其次可以限制執行層面的IT人員和業務人員的隨意性、不嚴謹性，再次向監管層提供了從全局和長遠的角度看系統的機會。
4. 交流：即溝通，是跨部門的跨領域的溝通。對傳統IT的最大挑戰就是跨組織跨領域的溝通交流，而數據治理委員會這樣一個跨越了IT部門和業務部門的虛擬組織，通過建立例行的交流機制，保證了信息在整個組織範圍內的透明，這種透明性保證了所有參與者的步調一致的，保證了業務數據的一致性。交流滲透在前面所述的四點數據治理活動中，是它們成功的保障。
5. 整合：這是我們的目標同時也是解決之道，主要抓住三個方面的整合——信息的整合，資源的整合，能力的整合。通過信息的整合把分散的業務數據整合到一個一致的沒有歧義的體系中來；通過資源的整合把企業IT資源集中調配；通過能力的整合，將平臺的運算能力，業務數據處理能力集中管理，建立一種集中服務的模式，即提高了硬件利用率、人員工作效率又利於IT對各業務部門服務的成本覈算。
“數據事故”分析
爲了解決數據事故問題，筆者協調財務、計劃、銷售、IT等部門成立了專門的“數據治理”項目小組。數據事故，應該是由於數據的素質低劣造成的，根據調查機構Gartner稱，《財富》一千家大型企業所持有的數據，有超過四分一是不準確、不完整或重複的，並預期有四分之三的大型企業直到2010年前也不會或難以改善內部數據的素質。其實沒有一家企業不受數據素質問題困擾，但就算有公司意識到問題所在，也常常會低估問題的嚴重性。何況，數據素質會受多個因素影響而變化。因此，要應付這種挑戰，一次性的行動難以奏效，企業務必持之以恆，甚至採取能改寫企業文化的行動纔會有效。
Gartner研究顯示，良莠不齊的客戶數據可造成重大損失，包括流失客戶，以及由處理直銷郵件不善和錯過銷售機會所造成的浪費等。現時很多企業亦發現劣質數據不單打擊銷售及市場推廣，更會波及最具策略性的業務活動。後勤部門的運作，例如制定預算、生產及分銷也會受到影響。
解決劣質數據問題不只只是一個IT的問題。雖然IT有助將之改善，但企業管理纔是關鍵所在，例如企業文化對數據素質就有很大的影響力。
數據治理，需要對數據的素質提出一個定義，筆者認爲數據素質涵蓋以下多方面：
ü 存在 (即企業到底有沒有某一項數據)
ü 合法性 (即該項數據的數值是否符合一個可接受的範圍)
ü 一貫性 (例如同一項數據不論儲存在哪一個地點都有同一數值)
ü 整全性 (數據元素與不同數據集之間關係的完整程度)
ü 準確性 (該項數據是否能夠描述它應表達的東西)
ü 關聯性 (該項數據能否恰當地支援業務宗旨)
ü 時間性 (即該項數據是否能夠及時地被反應出來)
針對以上數據的素質，再結合DRP系統中的相關模塊，對DRP系統中數據問題按模塊分別分析。該分析表格如下：
|
| 採購 | 訂貨 | 直營 | 門店 | 價格 | 倉儲物流 | |
| 存在 | Y | Y | Y | Y | Y | Y | Y |
| 合法性 | Y | Y | Y | Y | Y | Y | Y |
| 一貫性 | Y | Y | Y | N | N | N | Y |
| 整全性 | N | Y | Y | Y | N | Y | Y |
| 準確性 | N | N | N | N | N | N | N |
| 關聯性 | Y | Y | Y | Y | Y | N | N |
| 時間性 | N | Y | N | N | N | N | N |
以上各模塊中，達到相應的數據素質目標即爲Y，否則爲N。經過對DRP系統中的各個模塊的數據素質調查發現：數據治理主要針對的是數據的準確性、時間性、關聯性。進一步對數據事故的原因分析，發現數據出問題往往是因爲對數據的應用不夠充分。比如物流配送，根據銷售和庫存信息來做，首先銷售的信息，每天系統裏面的銷售信息和銀行回款對比，有沒有差異，沒有差異就是對的。第二，配送是根據系統去配。慢慢的精細化，以前可能是粗放的，現在是一個環節套一個環節，根據這個系統來做，慢慢數據就會越來越準確。百分之百的準確不可能，當然也沒有必要，因爲隨便一個環節都有可能出現串碼。
但如果業務部門發現DRP系統不管用，但DRP使用者就會用自己祕密地使用自己“更方便更可靠的工作流程/做法”。而管理層認爲既然沒有發生什麼不妥，也就睜一隻眼，閉一隻眼。其實，任何繞道DRP系統的工作流程/做法都會產生DRP數據流之外的“數據暗流”。這種“數據暗流”會削弱企業對流程的控制，損害企業對流程的管理和進一步優化，自然DRP系統的數據準確性就更差了。那麼，我們又怎樣保證及時數據更新和避免繞道DRP的祕密的“更方便更可靠的工作流程/做法”呢?解決方案原則上很簡單：持續提高數據準確率，定期維護訂單修訂等系統參數，以確保DRP產生的數據流與實際運作相符，通過基於DRP的工作流程的改進，禁止任何繞道DRP的行爲。
同時，借鑑了業內同行的“數據事故”分析方法，可以得到如下的因果圖：
針對上述發現的各種原因，經過進一步的統計與分析，發現主要的問題在審覈流程缺失，KPI指標設定不完善、考覈與處罰機制沒有執行、指定時間內的數據不到位、業務不熟悉、操作不當上。相反，由於系統原因造成的DRP數據錯誤很少。而像流程原因導致數據錯誤出現的次數只佔20%，但由於流程原因出現的數據錯誤影響程度最大。而像操作不當、指定時間內的數據不到位的情況出現較頻繁，但對數據錯誤的影響有限。
數據治理方案
採用上述的數據治理理論，在經過“數據事故”的教訓之後，發現上述數據問題，分別針對時間因素、流程、數據基礎、考覈機制、人員、系統制定數據治理方案，並強調方案的執行、監督、控制職能，加強各業務人員溝通，達到數據治理的目的。
考覈機制：數據治理的問題其實也是企業管理的問題，而出現問題往往是沒有一個比較好的考覈與激勵機制。在數據事故當中，出了問題之後，IT人員急着去查找原因，財務部門則因爲數據報表出不來而乾着急，而往往是事故責任部門往往是數據生產部門，而不是數據消費部門。所以，沒有好的考覈機制，往往事故在出現了之後無據可依地進行處罰，導致員工情緒極大。因此，我們定製瞭如下考覈辦法：每月結束，涉及到DRP系統中數據操作的，出現錯誤次數在5次(含5次)以上的，每次罰款10元，充入公司獎金池；如果每月操作零錯誤的，則從獎金池內獎勵30元；各部門的年度KPI指標中加入DRP系統數據操作正確率，並給予一定的權重，此舉目的就是爲了能夠使各業務部門經理引起對DRP系統數據操作正確性的重視。
人員：人員責任心不強的問題，可以由前面的考覈機制來加強，而且由於數據操作涉及到部門的績效，因此，各業務部門經理也會加強在這方面的監督；對於操作不當，業務不熟悉的情況，可以歸結爲培訓不夠。對於培訓我們分爲兩大塊：一是新員工培訓，這包括老員工調職到新崗位，新員工如果需要操作DRP系統，必須經過IT部的上崗培訓方可開設DRP系統賬號，否則的話，將無權對DRP系統進行操作；還有就是專場培訓，這也有兩類，一類是專門的計算機基礎教育培訓，這裏會包括一些計算機基礎操作，基本故障處理；另一類是公司業務流程培訓，針對各個不同崗位的人員，將公司的業務流程整合起來講，讓各業務人員知道自己上下游的業務流程是什麼？如果有異常如何處理等，同時培訓由人力資源部培訓組與IT部共同負責，所有培訓考勤、反饋、考覈情況都記入員工培訓檔案，講師則由IT部門、業務部門經理分別承擔；如果是針對各業務經理的培訓，也會請外部的流程、IT專家來擔任。
系統：系統的問題，主要通過兩方面控制：一是加強測試，所有的系統升級都必須經過公司內部的程序員測試，撰寫測試報告，經由IT經理審批之後方可將升級包更新到DRP系統中去，如果由於升級原因造成系統邏輯問題造成的數據錯誤，必須由程序員與IT經理分別承擔責任，根據每次事故的問題嚴重性，每次罰款30—300不等，同時IT部門的KPI指標中也加入系統數據事故的次數進行考覈。二是對於關鍵服務器、網絡設備的突然當機等情況的處理，這些方案可以根據IT部門的原有處置與考覈機制進行。
數據基礎：基礎數據質量差，這就是對數據生產部門提出需求，必須控制數據質量，完善公司數據規格說明，對於必須填寫的數據，由IT部門定期出具數據質量審計報告，對數據生產部門進行考覈。對於數據錄入準確率低的問題，一是採用條碼、掃描等技術手段來加強數據質量，二是通過加強人員責任心來保證，三則是通過數據審覈，下游業務流程一定要加強對數據的審覈與比對，特別是在分公司，由財務、倉管、數據員三方進行數據確認，以保證數據與業務的同步。
流程：物流是最頭痛的問題，也是處理起來最難的問題，其實關於業務流程管理(BPM)是一個很大的話題，在這裏呢，只能說是，根據企業實際情況，一點點的改進，因爲流程改進是一個傷筋動骨的事情，包括：原有流程是合適企業應用的，但現在不合適了怎麼辦？原來的流程是由某個部門負責的，現在職能要細化，要分開怎麼辦？所以在這裏就不再鋪開來講，但以後有機會進一步進行論述。
時間因素：時間因素，主要在於企業的動作效率，也是對於員工的一個考覈指標，這方面沒有太大的難度，我們主要也是將時間作爲數據生產部門的一個指標來考覈，如：計劃部門必須在訂貨單的2小時之內將訂貨單貨配發出去；專賣店如果有DRP系統，必須在當天將銷售數據傳回，如果沒有DRP系統，則傳真數據必須在當天傳回，當地辦事處必須在第二天上午11：00之前將銷售數據做到DRP系統中；客服部必須在12小時內將客戶數據錄入到DRP系統中，對於客戶的禮品申請，必須在兩個工作日內處理完畢，並給客戶回覆等。
上述所有的針對問題的解決方案都離不開執行、監督、控制與交流。在這幾個環節當中，IT部門與行政部門爲主要的執行主體，IT部門負責對DRP系統中的數據異常或每月數據質量出具報告，行政部門則根據IT部門的報告和數據質量方面的制度，給業務部門的KPI指標進行評定，也針對操作人員進行具體的獎罰；同時在培訓這一塊，由人力資源部門與IT部門負責完成。
而IT部門的系統故障及錯誤等問題，則落實到財務部與行政部具體負責進行考覈，這也就是一個監督機制，IT部門作爲DRP系統的管理者，也是要被各個業務部門進行監督的。
而由於涉及到各個業務部門的各個業務環節，特別在加入了績效考覈之後，會引起業務部門對IT部門的敵視，甚至是對DRP系統的敵視，因此，所有策略的實施都需要IT經理與數據治理項目小組的負責人加強溝通。特別是要注意循序漸進，切忌要求一步到位，否則的話引起業務部門的不滿與反彈，有可能事情會變的更糟糕。
項目管理手記(五)
DRP項目中的數據治理
由於我本人的項目經驗在DRP項目中會比較多一些，而且所談及的問題也是在DRP項目中碰到的，當然，也許我說的這個問題不只只是在DRP項目中，包括像ERP、PDM、KM等項目中都會碰上，但我還是會結合DRP項目中的實際問題來說。同時，由於本人所在的角度是甲方的角度，因此，DRP項目的週期對於甲方來說不只只是項目調研、實施、培訓，還會包括整個DRP系統的應用、部署、維護直到系統結束使用的DRP系統的整個使用週期。
DRP項目進行到後期，一般的企業都會擔心一個問題“顧問走了之後，我們怎麼辦？”。因爲如果實施顧問在現場的話，感覺都不會出什麼問題，就算有問題，顧問也解決掉了。但一旦顧問離場，DRP系統交由企業的IT部門負責運行與維護的時候，感覺問題就出的比較多了。這些問題可能會包括系統故障增多，系統運行速度減慢，軟件需求得不到響應，數據不準等。也因爲這些原因業務部門也在應用了一段時間之後感覺系統不好用了，特別是數據不準的情況經常出現，使得報表也不準了，久而久之，業務部門感覺DRP系統的價值也越來越低了，而這樣造成的直接後果就是DRP系統的使用效果打折，經常會聽到業務部門在抱怨：“這是什麼破系統嘛，出來的數據都不準!”，把數據問題與DRP系統邏輯問題相混淆，從而有可能對DRP系統本身引發了懷疑，導致DRP系統的使用週期因爲數據不準而大大縮短。
“數據事故”引發的數據治理思考
套用一句老話：“ERP是三分軟件、七分實施、十分努力、十二分數據、百分百的領導支持”。其實筆者一直在實施DRP項目的過程中，都有碰到多或多或少的數據問題，但應該都是小問題，所影響的範圍也不大，或者通過DRP系統的一些異常處理功能也就能夠解決的，如：退貨單出現的退貨價格不準確的問題，只要對這張單據進行廢除重做就好了，直到筆者碰到兩次重大的“數據事故”，纔對DRP項目的數據治理工作引發了重視與思考。
第一件事情是由於產品中心對新產品定價錯誤引發的“數據事故”。一直以來，新產品的定價是由產品中心會同財務、銷售、計劃等部門一起制定的，而且制定的是產品的零售價，然後根據零售價的折率分別倒推定製分銷價、出廠價、採購價，而採購價也是一個基準價，也就是說，產品的採購必須低於這個價格，否則的話公司是不會批准對這款產品進行投產的。在年度某季度新產品定價時，公司各部門定製出了當季產品的各種價格，並已經在系統中進行實施，但隨之而來的是，發現在市場對於當季產品的價格反映是偏高，而且代理商也認爲當季產品的分銷價格(即代理商進貨價)太高，所以公司決定對該款產品進行重新定價。隨之而來的就是要求DRP系統中對所有業務環節中的價格進行調整，包括對已經配送到分公司、代理商的產品進行重新調價，對已經配送到直營店，在倉庫中未銷售的產品進行價格調整。這一次的調整由於影響極大，導致公司各業務部門不得不集中人馬加班對數據進行調整，而且調整結束之後，在下月的系統過賬中發現財務報表總是有些出入，才發現數據調整有問題，有些調過來了，有些沒有調整過來，有些調整的時候產品已經銷售出去了，有的產品是退貨的，但成本卻沒有改過來，總之是亂的一團麻，使的該月的財務報表不得不在財務部門的要求下，各業務部門簽字覈定是由於操作不當引起的數據統計問題。本次問題其實是一個業務規範性的問題，或者是系統強壯型問題，如果業務夠規範，不會出現這種在產品進行銷售時更改產品成本的問題，或者系統足夠強壯，能夠對數據變更做出及時處理，這次事故應該也是能夠避免的。
第二件事是由於分公司內部管理、控制不到位及流程缺失導致的“數據事故”。記得當時還在外面開會，被財務總監電話催回公司，說是公司領導要求我今天準備一下，明天去華中大區出差，因爲當地分公司的本月的財務、系統數據都有嚴重問題，估計賬實不符情況嚴重，需要過去核查一下問題到底出在哪裏。第二天，當公司的財務、計劃、IT三部門人員到達華中大區所在地時，開始安排了對本大區所有的庫存盤點的工作，首先是對直營店進行盤點，全部由總部人員進行監督，經過五個晚上的盤點之後，再用了四天時間對大區的庫房進行盤點，發現：直營店的手工賬務與DRP系統中的數據不符情況嚴重，而直營店的手工賬務與實際庫存情況相差無幾，直營店也較好地執行了失貨賠償制度。而DRP系統中的數據與實際庫存嚴重不符的原因在於：大區的倉庫管理人員、數據員都沒有及時將直營店的退貨、銷售、調撥單據進行處理，以致直營店數據失真；同時對大區的庫存盤點時發現：大區的庫存結構不合理，庫存過大，直營店的過季產品處理不及時，數據員沒有對倉庫數據進行及時分析及利用。同時，大區的財務人員也沒有根據DRP系統中的數據進行財務數據覈對，以至於倉庫、數據、財務的工作脫節，形成了大區庫房管理工作出現了失控。這次事故經過審覈之後，上報到公司領導，下定決心對相關責任人進行了處罰，而也是在這次“數據事故”之後引發了筆者對於如何進行DRP系統“數據治理”的思考。
數據治理的理論及方法
項目小組總結之後，通過查找相關資料發現：數據治理其實是一種體系，是一個關注於信息系統執行層面的體系，這一體系的目的是整合IT與業務部門的知識和意見，通過一個類似於監督委員會或項目小組的虛擬組織對企業的信息化建設進行全方位的監管，這一組織的基礎是企業高層的授權和業務部門與IT部門的建設性合作。從範圍來講，數據治理涵蓋了從前端事務處理系統，後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
1. 發現：即發現問題和差異（Issues & Gaps），這是監管的基本職能。我們一定要在萌芽階段發現問題和差異，將其扼殺在苗頭。那麼如何去發現呢？
對於待建或在建的系統，要建立專家審覈制度，所謂專家包括技術專家和業務專家，如果本組織不具備條件則可以邀請第三方的顧問來參與系統數據的架構和設計決策，但根本原則是任何專家必須是相關領域的專業人士。
對於已建成使用的系統，則關鍵是IT的日常運維工作的規範化，主要包括規範的問題管理（Trouble Management），週期性審計(Periodic Review)。前者是爲了文檔化各種系統問題和缺陷，以及相應的IT判斷和響應；後者是爲了及時對系統的問題和缺陷做出歸納總結，找出規律而從根本上解決問題。
2. 監督：即持續的保持對業務數據健康狀況的跟蹤。監督主要通過週期性的數據分析來完成，市場上也有很多自動化的工具可以幫助您方便的對數據的健康狀況進行分析。與發現所不同的是，監督是主動的去發掘問題，而且在發現問題後立即採取行動去修正它。
3. 控制：即掌握信息系統建設的決策權。任何信息系統的建設、更新升級、大型變更都必須通過數據治理項目小組的審批，極端情況下甚至可以考慮任何數據變更都必須審批。集中化的控制的好處是，首先可以集中技術和業務相關領域的專家的意見，其次可以限制執行層面的IT人員和業務人員的隨意性、不嚴謹性，再次向監管層提供了從全局和長遠的角度看系統的機會。
4. 交流：即溝通，是跨部門的跨領域的溝通。對傳統IT的最大挑戰就是跨組織跨領域的溝通交流，而數據治理委員會這樣一個跨越了IT部門和業務部門的虛擬組織，通過建立例行的交流機制，保證了信息在整個組織範圍內的透明，這種透明性保證了所有參與者的步調一致的，保證了業務數據的一致性。交流滲透在前面所述的四點數據治理活動中，是它們成功的保障。
5. 整合：這是我們的目標同時也是解決之道，主要抓住三個方面的整合——信息的整合，資源的整合，能力的整合。通過信息的整合把分散的業務數據整合到一個一致的沒有歧義的體系中來；通過資源的整合把企業IT資源集中調配；通過能力的整合，將平臺的運算能力，業務數據處理能力集中管理，建立一種集中服務的模式，即提高了硬件利用率、人員工作效率又利於IT對各業務部門服務的成本覈算。
“數據事故”分析
爲了解決數據事故問題，筆者協調財務、計劃、銷售、IT等部門成立了專門的“數據治理”項目小組。數據事故，應該是由於數據的素質低劣造成的，根據調查機構Gartner稱，《財富》一千家大型企業所持有的數據，有超過四分一是不準確、不完整或重複的，並預期有四分之三的大型企業直到2010年前也不會或難以改善內部數據的素質。其實沒有一家企業不受數據素質問題困擾，但就算有公司意識到問題所在，也常常會低估問題的嚴重性。何況，數據素質會受多個因素影響而變化。因此，要應付這種挑戰，一次性的行動難以奏效，企業務必持之以恆，甚至採取能改寫企業文化的行動纔會有效。
Gartner研究顯示，良莠不齊的客戶數據可造成重大損失，包括流失客戶，以及由處理直銷郵件不善和錯過銷售機會所造成的浪費等。現時很多企業亦發現劣質數據不單打擊銷售及市場推廣，更會波及最具策略性的業務活動。後勤部門的運作，例如制定預算、生產及分銷也會受到影響。
解決劣質數據問題不只只是一個IT的問題。雖然IT有助將之改善，但企業管理纔是關鍵所在，例如企業文化對數據素質就有很大的影響力。
數據治理，需要對數據的素質提出一個定義，筆者認爲數據素質涵蓋以下多方面：
ü 存在 (即企業到底有沒有某一項數據)
ü 合法性 (即該項數據的數值是否符合一個可接受的範圍)
ü 一貫性 (例如同一項數據不論儲存在哪一個地點都有同一數值)
ü 整全性 (數據元素與不同數據集之間關係的完整程度)
ü 準確性 (該項數據是否能夠描述它應表達的東西)
ü 關聯性 (該項數據能否恰當地支援業務宗旨)
ü 時間性 (即該項數據是否能夠及時地被反應出來)
針對以上數據的素質，再結合DRP系統中的相關模塊，對DRP系統中數據問題按模塊分別分析。該分析表格如下：
|
| 採購 | 訂貨 | 直營 | 門店 | 價格 | 倉儲物流 | |
| 存在 | Y | Y | Y | Y | Y | Y | Y |
| 合法性 | Y | Y | Y | Y | Y | Y | Y |
| 一貫性 | Y | Y | Y | N | N | N | Y |
| 整全性 | N | Y | Y | Y | N | Y | Y |
| 準確性 | N | N | N | N | N | N | N |
| 關聯性 | Y | Y | Y | Y | Y | N | N |
| 時間性 | N | Y | N | N | N | N | N |
以上各模塊中，達到相應的數據素質目標即爲Y，否則爲N。經過對DRP系統中的各個模塊的數據素質調查發現：數據治理主要針對的是數據的準確性、時間性、關聯性。進一步對數據事故的原因分析，發現數據出問題往往是因爲對數據的應用不夠充分。比如物流配送，根據銷售和庫存信息來做，首先銷售的信息，每天系統裏面的銷售信息和銀行回款對比，有沒有差異，沒有差異就是對的。第二，配送是根據系統去配。慢慢的精細化，以前可能是粗放的，現在是一個環節套一個環節，根據這個系統來做，慢慢數據就會越來越準確。百分之百的準確不可能，當然也沒有必要，因爲隨便一個環節都有可能出現串碼。
但如果業務部門發現DRP系統不管用，但DRP使用者就會用自己祕密地使用自己“更方便更可靠的工作流程/做法”。而管理層認爲既然沒有發生什麼不妥，也就睜一隻眼，閉一隻眼。其實，任何繞道DRP系統的工作流程/做法都會產生DRP數據流之外的“數據暗流”。這種“數據暗流”會削弱企業對流程的控制，損害企業對流程的管理和進一步優化，自然DRP系統的數據準確性就更差了。那麼，我們又怎樣保證及時數據更新和避免繞道DRP的祕密的“更方便更可靠的工作流程/做法”呢?解決方案原則上很簡單：持續提高數據準確率，定期維護訂單修訂等系統參數，以確保DRP產生的數據流與實際運作相符，通過基於DRP的工作流程的改進，禁止任何繞道DRP的行爲。
同時，借鑑了業內同行的“數據事故”分析方法，可以得到如下的因果圖：
針對上述發現的各種原因，經過進一步的統計與分析，發現主要的問題在審覈流程缺失，KPI指標設定不完善、考覈與處罰機制沒有執行、指定時間內的數據不到位、業務不熟悉、操作不當上。相反，由於系統原因造成的DRP數據錯誤很少。而像流程原因導致數據錯誤出現的次數只佔20%，但由於流程原因出現的數據錯誤影響程度最大。而像操作不當、指定時間內的數據不到位的情況出現較頻繁，但對數據錯誤的影響有限。
數據治理方案
採用上述的數據治理理論，在經過“數據事故”的教訓之後，發現上述數據問題，分別針對時間因素、流程、數據基礎、考覈機制、人員、系統制定數據治理方案，並強調方案的執行、監督、控制職能，加強各業務人員溝通，達到數據治理的目的。
考覈機制：數據治理的問題其實也是企業管理的問題，而出現問題往往是沒有一個比較好的考覈與激勵機制。在數據事故當中，出了問題之後，IT人員急着去查找原因，財務部門則因爲數據報表出不來而乾着急，而往往是事故責任部門往往是數據生產部門，而不是數據消費部門。所以，沒有好的考覈機制，往往事故在出現了之後無據可依地進行處罰，導致員工情緒極大。因此，我們定製瞭如下考覈辦法：每月結束，涉及到DRP系統中數據操作的，出現錯誤次數在5次(含5次)以上的，每次罰款10元，充入公司獎金池；如果每月操作零錯誤的，則從獎金池內獎勵30元；各部門的年度KPI指標中加入DRP系統數據操作正確率，並給予一定的權重，此舉目的就是爲了能夠使各業務部門經理引起對DRP系統數據操作正確性的重視。
人員：人員責任心不強的問題，可以由前面的考覈機制來加強，而且由於數據操作涉及到部門的績效，因此，各業務部門經理也會加強在這方面的監督；對於操作不當，業務不熟悉的情況，可以歸結爲培訓不夠。對於培訓我們分爲兩大塊：一是新員工培訓，這包括老員工調職到新崗位，新員工如果需要操作DRP系統，必須經過IT部的上崗培訓方可開設DRP系統賬號，否則的話，將無權對DRP系統進行操作；還有就是專場培訓，這也有兩類，一類是專門的計算機基礎教育培訓，這裏會包括一些計算機基礎操作，基本故障處理；另一類是公司業務流程培訓，針對各個不同崗位的人員，將公司的業務流程整合起來講，讓各業務人員知道自己上下游的業務流程是什麼？如果有異常如何處理等，同時培訓由人力資源部培訓組與IT部共同負責，所有培訓考勤、反饋、考覈情況都記入員工培訓檔案，講師則由IT部門、業務部門經理分別承擔；如果是針對各業務經理的培訓，也會請外部的流程、IT專家來擔任。
系統：系統的問題，主要通過兩方面控制：一是加強測試，所有的系統升級都必須經過公司內部的程序員測試，撰寫測試報告，經由IT經理審批之後方可將升級包更新到DRP系統中去，如果由於升級原因造成系統邏輯問題造成的數據錯誤，必須由程序員與IT經理分別承擔責任，根據每次事故的問題嚴重性，每次罰款30—300不等，同時IT部門的KPI指標中也加入系統數據事故的次數進行考覈。二是對於關鍵服務器、網絡設備的突然當機等情況的處理，這些方案可以根據IT部門的原有處置與考覈機制進行。
數據基礎：基礎數據質量差，這就是對數據生產部門提出需求，必須控制數據質量，完善公司數據規格說明，對於必須填寫的數據，由IT部門定期出具數據質量審計報告，對數據生產部門進行考覈。對於數據錄入準確率低的問題，一是採用條碼、掃描等技術手段來加強數據質量，二是通過加強人員責任心來保證，三則是通過數據審覈，下游業務流程一定要加強對數據的審覈與比對，特別是在分公司，由財務、倉管、數據員三方進行數據確認，以保證數據與業務的同步。
流程：物流是最頭痛的問題，也是處理起來最難的問題，其實關於業務流程管理(BPM)是一個很大的話題，在這裏呢，只能說是，根據企業實際情況，一點點的改進，因爲流程改進是一個傷筋動骨的事情，包括：原有流程是合適企業應用的，但現在不合適了怎麼辦？原來的流程是由某個部門負責的，現在職能要細化，要分開怎麼辦？所以在這裏就不再鋪開來講，但以後有機會進一步進行論述。
時間因素：時間因素，主要在於企業的動作效率，也是對於員工的一個考覈指標，這方面沒有太大的難度，我們主要也是將時間作爲數據生產部門的一個指標來考覈，如：計劃部門必須在訂貨單的2小時之內將訂貨單貨配發出去；專賣店如果有DRP系統，必須在當天將銷售數據傳回，如果沒有DRP系統，則傳真數據必須在當天傳回，當地辦事處必須在第二天上午11：00之前將銷售數據做到DRP系統中；客服部必須在12小時內將客戶數據錄入到DRP系統中，對於客戶的禮品申請，必須在兩個工作日內處理完畢，並給客戶回覆等。
上述所有的針對問題的解決方案都離不開執行、監督、控制與交流。在這幾個環節當中，IT部門與行政部門爲主要的執行主體，IT部門負責對DRP系統中的數據異常或每月數據質量出具報告，行政部門則根據IT部門的報告和數據質量方面的制度，給業務部門的KPI指標進行評定，也針對操作人員進行具體的獎罰；同時在培訓這一塊，由人力資源部門與IT部門負責完成。
而IT部門的系統故障及錯誤等問題，則落實到財務部與行政部具體負責進行考覈，這也就是一個監督機制，IT部門作爲DRP系統的管理者，也是要被各個業務部門進行監督的。
而由於涉及到各個業務部門的各個業務環節，特別在加入了績效考覈之後，會引起業務部門對IT部門的敵視，甚至是對DRP系統的敵視，因此，所有策略的實施都需要IT經理與數據治理項目小組的負責人加強溝通。特別是要注意循序漸進，切忌要求一步到位，否則的話引起業務部門的不滿與反彈，有可能事情會變的更糟糕。