但在專案實施和驗收時，BI卻變成了報表開發專案，而報表的需求往往和個人習慣有關，一旦人員發生變動，尤其是新入職的高層，會把前公司的內容搬過來，這就需要重新開發一大堆報表。
如果不從源頭進行控制，被動服務模式下的IT不可能滿足所有人的報表需求。接下來我們要講的這個案例就真實反應了這個過程，同時也為大家解析問題產生的原因並找到解決問題的方法，建議所有有計劃或已經實施BI專案的企業，認真閱讀本文。
一、
2011年底至2012年初，筆者在某女裝公司組織實施BI系統，專案第一期就花了100多萬，長達6個月的週期，經歷了業務需求調研、資料清理、指標體系梳理、資料模型構建等等一系列中規中矩的專案實施過程。
從業務個性化需求報表到以經營指標為導向的資料模型、資料駕駛艙等等，在專案組看來，除移動化展現，幾乎覆蓋了當前所有業務需求。在多次宣導並召開上線動員大會後，BI終於正式執行了。
然而現實卻給了專案組一個響亮的耳光，在BI系統上線後，3個月內不僅使用次數屈指可數，就連最初要求的月度經營分析和績效考核必須從BI中取值這兩點都沒有實現，依然需要業務部門從各個系統中匯出資料再自行計算統計。
第一期專案很快就被宣判失敗，這讓整個專案組深受打擊，實施方法論是沒有問題的，也針對上述狀態的可能性做了很多短期過渡的報表，還有最大自由定義的萬能報表，但最後使用者們依然不滿意。這究竟是什麼原因呢？
二、
專案組進行反思，並用一週時間去做了使用者調研，進行深入地討論總結。
1、大部分使用者反饋BI系統操作缺乏便利性，使用起來特別麻煩。因為每個使用者只需檢視自己日常工作的資料即可，這第一期BI系統實施把所有業務特性進行了歸納，按照其基礎職能設定指標組合與自主選擇的時間跨度欄位。
使用者因此產生一個印象就是需要的報表全部堆砌在一起，你需求什麼自己去找，而且部分派生指標取值需要重新計算後產生，報表展現的效率低下，BI操作起來就很痛苦。
其實每一項體系既要有決策層的視角，也要有管理層的視角，雖然按照操作層的指標體系與時間自定義幾乎涵蓋一切，但這樣並沒有針對每一個崗位進行相應的配置，要想得到使用者認可，首要要素需要滿足各層級使用者在某一時間週期內的資料所見即所得
2、指標體系的管理邏輯梳理不清晰，需要使用者憑經驗去尋找資料背後的邏輯。BI的價值是提升管理的精準度，透過資料構築一個企業管理模型。
BI系統實施的最大能力就體現在如何梳理管理邏輯，幫助企業視覺化展現管理模型與管理的精細度。
3、主資料定義的一致性問題，使用者經常反饋業務系統與BI資料包表中相同維度的資料會出現的一些差異，導致大家對BI資料的信任度嚴重下降。
綜合上述調研的問題，專案組徵得公司資訊決策委員會的同意，於2012年8月啟動了第二期的BI系統實施，專案組經過商討決定改變實施思路，先暫停技術性工作，首要任務是進行公司的資料治理。
三、那麼資料治理要怎麼開展呢？
第一個就是主資料的治理，也就是說企業經營管理過程會用到哪些主資料？這些主資料是如何產生、如何進行分發、會標記哪些維度形成派生主資料？隨後在BI中單獨搭建一個主資料中心庫，抽取業務系統的主資料按照分類原則存放，並開發主資料一致性校驗程式與主資料分發日誌表。
第二個是指標的梳理，建立指標體系，定義每個分析過程中的使用的業務指標，建立評價標準，以及計算方法，將業務管理邏輯進行更加直觀的呈現，銷售環節出現了資料波動就可以直觀的呈現出來，透過指標的呈現，可以追蹤哪部分業務發生的問題。
第三個就是規範資料產生的入口，以及資料取值的出口的標準。明確所有資料的錄入產生的作業標準，建立各個系統到BI的介面規範，企業經營活動中產生的幾乎所有資料都要進資料倉儲，並由BI系統統一進行資料抽取與資料加工；
另外針對所有業務部、職能部提交的月度經營分析、月度績效考核、年度關鍵考核指標、日常管理分析的全部資料需求進行綜合評估分析，搭建相應的資料模型，要求任何所有應用資料都從BI系統取值，有了入口與出口的規範才能保證資料的一致性與唯一性。
四、
完成上述三個動作後由專案組協同企管部門編撰公司資料管理制度，進行全公司範圍的發文，資料管理制度定義了主資料產生、指標體系的結構與演算法、資料錄入與輸出的標準等，是一項公司完整資料管理規範。
發文同時還明確了公司資料治理小組的組織架構與職能，治理資料小組有4種角色：
- 第一個是資料操作員，是業務部門的操作人員，主要發起主資料的調整、BI系統的維護、指標體系的修改申請等等；
- 第二個是資料稽核主管，往往是部門領導。每個資料是由不同部門負責的，首先由資料操作員提出第一級的申請，其次是資料負責的部門進行稽核。
- 第三個角色是資料的分析員，他對資料稽核主管的稽核進行分析，看修訂的要求是否合理？是否影響其他主資料、指標和資料模型。
- 第四個角色是BI系統的管理員，經過審批稽核後修訂要求必須由系統管理員操作才能進行調整。即使這樣每隔一個時段還是會有很多業務指標需要調整，比如新的業務出現或是新業務發生變化，甚至要調整公司組織架構，這個流程申請就是專案管理形式進行。
公司OA中也配置相應的三個流程，一是主資料的修訂流程、二是管理指標和KPI指標調整的流程、三是報表最佳化的流程。透過資料治理實施過程，IT團隊的資料中心部門基本實現公司資料的統籌工作，整體上也形成了PDCA的迴圈。
五、
資料治理進行了一個月時間後，專案組又重新針對BI系統進行了最佳化，關鍵點有以下幾個：
梳理業務分析體系：先從純業務角度總結和梳理，分析各個業務中的流程和思路、常用角度、導向、評價標準，以及業務背後的原因。此體系的建立，是業務分析的總覽，也是業務流程環節的真實需求，為後續的指標體系、系統實現打下基礎，同時在業務分析體系建立的過程中，收集分析業務、資料的痛點和需求。
重新整理分析需求：根據收集的需求，業務分析的流程和思路，以及系統中的報表進行匹配和提煉，形成新的分析需求。
針對公司零售業務的變化特性，以月度為單位記錄業務調整導致的指標比重係數發生調整和變化的歷史資料，比如新店變成次新店、次新店升級為老店的時間維度差異。
將指標體系的業務管理邏輯進行更加直觀的呈現，銷售環節出現了資料波動就可以直觀的呈現出來，清楚的知道到底是哪部分業務發生的問題。
更加細緻精準劃分管理層級的資料展現，針對業務操作層的使用者也可在日常應用、周度彙報、月度績效、年度關鍵指標上進行資料的直觀呈現，所見即所得，雖然開發工作量增加，但是使用者體驗直線上升。
六、
公司的管理理念也發生了深刻的變化，從上至下不再用定性的語言表達，形成了用資料說話習慣。當管理維度與經營業務發生變化的時候，也形成了透過資料治理體系來進行相應修訂調整的習慣。
IT團隊的資料中心部門設定5個崗位，資料中心經理負責管理工作，資料分析師負責資料模型的設計以及指標的分析，有兩個BI系統開發師負責資料倉儲維護與資料模型開發，一個H5開發工程師負責移動端開發。
七、
從整個BI專案的實施價值上來講，有這樣幾點內容可以分享：
從公司經營決策者角度來講，透過駕駛艙可以快速看到企業的業務全域性，及時掌握公司的經營狀況，透過資料鑽取透視看到整體業務的變化過程。經營層面出現的任何問題，都能透過資料預警反饋到業務管理邏輯上，也非常容易找到關聯的業務動作，也就是哪些業務出現了問題。
管理者透過駕駛艙與關鍵考核指標組合報表可以快速閱讀自己的KPI指標以及關注和的經營指標的變化，因為每個管理崗位應該關注的什麼內容在體系上梳理很清晰了。
資料倉儲，透過建立資料倉儲，進行企業的資料治理，將企業的資料打通，形成可以分析和複用的資料資產。
整個操作層使用者的工作效率提高了很多，大家都在一個頻道，用同一種資料來源做彙報，再也不需要像過去需要臨時加工一些亂七八糟的報表了。
BI系統第2期的實施大大豐富了IT團隊的知識結構，尤其是資料中心團隊的歸納總結、分析問題以及對公司主營業務的認知和理解能力有很大進步。
也讓業務部門清楚地認識到IT對企業管理的價值，更加配合今後資訊系統的實施與部署，IT部門的影響力得到了直觀體現。