企業(yè)BI項目藍圖規(guī)劃建設(shè)方案
BI——商業(yè)智能，一個高大上的名字，一直被很多人認為是企業(yè)信息化中的“面子工程”。
什么是面子工程？“面子工程”是“形象工程”的意思，內(nèi)含只做表面形象，不解決實際問題，在當今社會成為了一個貶義詞。
01
BI是什么？
為什么會成為面子工程？
02
做好BI，
要從需求調(diào)研開始！
大致需求與詳細需求
明確大致需求，就是要弄清楚當前企業(yè)中各方人員的痛點，找到必須建設(shè)BI項目的理由和共識，并確定項目范圍。
由于不同行業(yè)的企業(yè)價值訴求點并不相同，因此在項目前期要注意收集和整理，多跟企業(yè)領(lǐng)導(dǎo)層、業(yè)務(wù)部門溝通，挖掘他們的關(guān)注點，弄清楚他們真正想要的是什么，再整理出項目的應(yīng)用場景、功能需求、交互需求、管理需求，預(yù)估項目周期等。
BI項目成功與否，最終要看項目完成后企業(yè)能不能將它用起來。很多企業(yè)的BI項目之所以失敗，就是因為沒想清楚需求就開始建設(shè)，導(dǎo)致一步錯，步步錯，做出來的系統(tǒng)并不能解決企業(yè)的問題，甚至根本用不上，領(lǐng)導(dǎo)也會質(zhì)疑IT部門的價值和BI系統(tǒng)的意義。
所以，上BI項目前，要準備好，瞄準目標再出發(fā)。
要大致了解BI系統(tǒng)是哪些部門用，用在哪些場景中，用了后能夠帶來多少價值，最好能帶來企業(yè)整體業(yè)績或者利潤的提升（即有可見的、可量化的價值）。
有了大致的需求，就可以進行需求調(diào)研，收集和明確詳細需求進行項目藍圖方案的設(shè)計了。
詳細需求設(shè)計是對大致需求的深入和細化，要具體到可執(zhí)行的粒度，例如每一個業(yè)務(wù)指標的分析與展示的維度和單位等。這個過程涉及業(yè)務(wù)、技術(shù)、數(shù)據(jù)等方面，需要通過細致的需求調(diào)研來完成。
總體來看，大致需求確定BI項目的核心價值和邊界，詳細需求確定BI項目的落地和驗收，兩者相輔相成，前者指明出發(fā)的本心，后者規(guī)范前行的里程碑。
需求調(diào)研的方法和步驟
收集和明確需求并非易事，尤其是挖掘需求方詳細的、深層次的需求。
很多企業(yè)在做需求調(diào)研時，經(jīng)常由于雙方對問題描述和理解上的差異，使得需求在不斷傳遞的過程中發(fā)生較大的偏差，最終開發(fā)出來的功能與原始需求大相徑庭。
圖1 需求的傳遞偏差
（1）調(diào)研業(yè)務(wù)部門分析場景
需求調(diào)研從三個層面展開：
首先是管理層面，主要調(diào)研與企業(yè)戰(zhàn)略相關(guān)的指標分析需求，方法是將企業(yè)戰(zhàn)略目標層層拆解到不同的層級。例如，將戰(zhàn)略目標拆解到某個部門后，該部門就需要通過BI系統(tǒng)分析部門的KPI或OKR（Objectives and Key Results，目標與關(guān)鍵成果）、項目進度、部門業(yè)績，以及人員各項指標的完成情況等。可以參考表1拆解企業(yè)戰(zhàn)略目標，并進行分析和記錄。
其次是調(diào)研業(yè)務(wù)部門在一些日常分析場景中的需求，可以通過表2進行收集。
在完成這些需求調(diào)研后，可以依據(jù)場景維度指標化與數(shù)據(jù)體系化的原則，對收集的所有場景需求進行總結(jié)。
（2）調(diào)研數(shù)據(jù)質(zhì)量
數(shù)據(jù)質(zhì)量的好壞是導(dǎo)致BI項目是否成功的最關(guān)鍵的因素。
企業(yè)中的數(shù)據(jù)按來源主要分為業(yè)務(wù)系統(tǒng)數(shù)據(jù)、手工數(shù)據(jù)、外部數(shù)據(jù)等。對數(shù)據(jù)質(zhì)量的調(diào)研也從這三個來源展開，本質(zhì)是梳理企業(yè)已有的數(shù)據(jù)。
對業(yè)務(wù)系統(tǒng)數(shù)據(jù)進行調(diào)研時，項目團隊需要明確各業(yè)務(wù)系統(tǒng)對接人，獲取相關(guān)數(shù)據(jù)接口和數(shù)據(jù)字典，若無法獲取則需要協(xié)商，制訂應(yīng)對策略。
對于手工數(shù)據(jù)，項目團隊可先行收集歷史手工數(shù)據(jù)資料，此項工作可與業(yè)務(wù)部門的需求調(diào)研同步進行。
對于外部數(shù)據(jù)，可參考業(yè)務(wù)系統(tǒng)數(shù)據(jù)的調(diào)研方式，重點關(guān)注數(shù)據(jù)的可獲取性和使用場景。
需要注意的是，在調(diào)研數(shù)據(jù)質(zhì)量階段，需要清晰地定義組織架構(gòu)、用戶及權(quán)限體系等項目的核心架構(gòu)數(shù)據(jù)。其中，權(quán)限不僅包括模塊功能權(quán)限，還包括數(shù)據(jù)權(quán)限，即不同的用戶、角色能夠看到哪些數(shù)據(jù)，例如城市銷售經(jīng)理能夠看到所負責(zé)城市的銷售數(shù)據(jù)，區(qū)域銷售經(jīng)理則能夠看到所負責(zé)區(qū)域的銷售數(shù)據(jù)等。
（3）設(shè)計、確認及修改數(shù)據(jù)體系
設(shè)計數(shù)據(jù)體系時主要考慮原始表和基礎(chǔ)寬表兩個層級，結(jié)合之前調(diào)研時所考慮的數(shù)據(jù)使用要求的最小粒度，以及分析中可能用到的維度、指標，盡可能做到對分析場景的全覆蓋，滿足各類數(shù)據(jù)粒度要求。
對數(shù)據(jù)體系的確認和修改主要包括數(shù)據(jù)維度、指標、粒度的增/刪/改，字段含義及邏輯口徑統(tǒng)一。
03
做好BI，
一定要做好藍圖規(guī)劃！
好的項目藍圖規(guī)劃能有效提升開發(fā)人效，縮短項目周期，實現(xiàn)項目預(yù)期目標。圍繞項目藍圖規(guī)劃，企業(yè)需要確定三件事：做什么、誰來做，以及怎么做。下面我們一一展開來談。
做什么：確定項目范圍
項目規(guī)劃的第一步是根據(jù)項目需求和目的確定項目范圍，這時在項目初期收集和明確的需求就派上用場了。對于項目管理者而言，只清楚項目范圍的含義是不夠的，最重要的是正確、清楚地定義項目范圍。
如果項目范圍劃分得不夠明確，會直接導(dǎo)致項目內(nèi)容意外變更，有可能造成項目最終成本提高、進度嚴重延遲、偏離原定目標，以及影響整個項目發(fā)展和項目團隊成員積極性等不良后果。
具體來說，項目范圍包括組織、功能、業(yè)務(wù)、數(shù)據(jù)、接口等5個方面的范圍。
（1）組織范圍框定的是實施項目的主體，企業(yè)需要明確當期項目是否只需要在總部實施還是要在總部和所有子公司都實施，實施的內(nèi)容又涉及哪些業(yè)務(wù)部門。
（2）功能范圍指BI項目所包含的功能模塊及具體功能。IT開發(fā)人員可以根據(jù)功能范圍提前學(xué)習(xí)和掌握BI工具，在做開發(fā)時更有針對性、更高效。
（3）業(yè)務(wù)范圍描述企業(yè)需要通過BI系統(tǒng)實現(xiàn)的日常業(yè)務(wù)處理和分析任務(wù)，主要對業(yè)務(wù)模塊、分析應(yīng)用、分析維度、分析形式等內(nèi)容進行定義。
（4）數(shù)據(jù)范圍包括數(shù)據(jù)源范圍和數(shù)據(jù)關(guān)聯(lián)規(guī)則等，其中數(shù)據(jù)源范圍不僅描述數(shù)據(jù)來自哪里，還包括對源數(shù)據(jù)的理解、源數(shù)據(jù)質(zhì)量保障、數(shù)據(jù)抽取等。表5給出了確定數(shù)據(jù)源范圍的示例。
表5 確定數(shù)據(jù)源范圍
誰來做：組建項目團隊
項目團隊是企業(yè)BI項目建設(shè)過程中的“大腦”，分工明確、配合有序的項目團隊是項目成功的關(guān)鍵。
由于BI項目的建設(shè)涉及企業(yè)內(nèi)部多個部門，需要高層管理者與業(yè)務(wù)部門的認同及參與，因此項目團隊通常以幾位企業(yè)高層管理者為核心，設(shè)立項目領(lǐng)導(dǎo)委員會來統(tǒng)籌整個項目，其他成員則由企業(yè)IT部門負責(zé)人牽頭，與各部門對接人一起，設(shè)立不同的小組，全程參與BI項目的規(guī)劃與實施。
項目團隊的角色分為團隊領(lǐng)導(dǎo)者、業(yè)務(wù)精通者、方案設(shè)計者、技術(shù)落地者等4類。每一類角色又可以進一步細分，例如技術(shù)落地者可以包括數(shù)據(jù)倉庫（簡稱數(shù)倉）開發(fā)團隊與應(yīng)用開發(fā)團隊等。
如果企業(yè)采用引入BI廠商或者外包商的方式來建設(shè)BI項目，就需要根據(jù)企業(yè)、BI廠商或外包商的實際情況來組建項目團隊。不過需要注意的是，項目領(lǐng)導(dǎo)委員會都需要企業(yè)自己派遣成員設(shè)立，以保證對項目的整體把控。
怎么做：設(shè)計實施方案
項目實施方案是在項目開展后為規(guī)范項目開展過程而制定的指導(dǎo)性方案，它定義了項目的進度安排、業(yè)務(wù)和技術(shù)方案、關(guān)鍵產(chǎn)出、交付標準及各環(huán)節(jié)中可能需要的管控措施等，是項目實施過程的行動指南。主要包括3項主要內(nèi)容，即項目計劃、藍圖方案和項目管理方法。
1．項目計劃
2．藍圖方案
前文提到，企業(yè)建設(shè)BI項目時需要收集和明確詳細需求，藍圖方案是經(jīng)過詳細調(diào)研后擬定的具有實際指導(dǎo)意義的文檔，可以將它理解為更具體的解決方案，即將解決方案中的各類框架細化到可設(shè)計、可執(zhí)行的粒度。對藍圖方案有兩大要求，即可行性與全面性。
可行性指藍圖方案的整體設(shè)計符合企業(yè)業(yè)務(wù)發(fā)展的需要，不能過于理想化，要考慮實施的難度。全面性則指項目團隊不能局限于單個模塊，而要在項目實施范圍內(nèi)解決企業(yè)的關(guān)鍵問題，并且考慮系統(tǒng)后續(xù)的可擴展性。
項目的藍圖方案一般包括3個部分，即整體方案、系統(tǒng)環(huán)境方案和詳細方案。
（1）整體方案包括業(yè)務(wù)、技術(shù)和數(shù)據(jù)三個方面。
業(yè)務(wù)方案主要是基于業(yè)務(wù)需求分析結(jié)果，設(shè)計業(yè)務(wù)分析模型，例如財務(wù)和人力等部門的分析體系、美工特色、報表權(quán)限體系等，可直接提供業(yè)務(wù)系統(tǒng)原型供企業(yè)參考。一般的業(yè)務(wù)方案為：首先準備數(shù)據(jù)源接口；再到數(shù)據(jù)處理層，搭建基礎(chǔ)數(shù)據(jù)平臺和業(yè)務(wù)分析平臺，梳理各個業(yè)務(wù)板塊的內(nèi)容；最后，搭建決策管理平臺，通過報表、駕駛艙、移動端、大屏等多種方式展示數(shù)據(jù)，達到最終目標——信息共享、信息對稱。
技術(shù)方案是支撐業(yè)務(wù)分析的整體技術(shù)框架，包括特殊技術(shù)預(yù)演結(jié)果、相關(guān)代碼整合等內(nèi)容。BI項目的技術(shù)架構(gòu)一般如圖3所示。首先，利用ETL工具抽取業(yè)務(wù)系統(tǒng)的明細數(shù)據(jù)，進行數(shù)據(jù)轉(zhuǎn)換之后，載入企業(yè)數(shù)據(jù)倉庫。接著，在數(shù)據(jù)倉庫的基礎(chǔ)上形成數(shù)據(jù)集市，用于企業(yè)不同主題業(yè)務(wù)數(shù)據(jù)的整合分析。最后，利用BI工具在不同門戶與終端上實現(xiàn)儀表板、固定報表、自助分析等功能。
數(shù)據(jù)方案則包括對數(shù)據(jù)獲取方式、數(shù)據(jù)血緣關(guān)系的梳理與描述，以及數(shù)據(jù)校對功能的設(shè)計、數(shù)據(jù)校對策略的制訂等。
（2）系統(tǒng)環(huán)境方案描述軟件環(huán)境、網(wǎng)絡(luò)與服務(wù)器環(huán)境的配置要求。其中，軟件環(huán)境包括客戶端軟件、BI應(yīng)用、中間件、數(shù)據(jù)庫管理系統(tǒng)及操作系統(tǒng)等。網(wǎng)絡(luò)與服務(wù)器環(huán)境主要是參考BI系統(tǒng)的要求，描述ODS（Operational Data Store，操作數(shù)據(jù)存儲）服務(wù)器、OLAP服務(wù)器、Web應(yīng)用服務(wù)器，以及整個網(wǎng)絡(luò)的配置情況。
（3）詳細方案是在整體方案的基礎(chǔ)上對每個模塊的方案進一步細化，例如數(shù)據(jù)倉庫建設(shè)方案、數(shù)據(jù)集成方案、數(shù)據(jù)補錄方案、數(shù)據(jù)分析平臺建設(shè)方案、多平臺集成方案等。企業(yè)可以根據(jù)自身的需求，在技術(shù)、業(yè)務(wù)和數(shù)據(jù)方案上進行拓展。
以數(shù)據(jù)倉庫建設(shè)方案為例，一般包括架構(gòu)規(guī)劃、數(shù)據(jù)模型、數(shù)據(jù)庫災(zāi)備、擴展性方案等4個部分的內(nèi)容。其中，在架構(gòu)規(guī)劃部分，需要明確數(shù)據(jù)倉庫的建設(shè)理念和建設(shè)原則。
一般在設(shè)計數(shù)據(jù)倉庫時，要遵循易用、實用、高可用、靈活擴展、可靠、可配置、安全等多項原則；同時，還需要對數(shù)據(jù)倉庫的邏輯架構(gòu)和技術(shù)架構(gòu)進行規(guī)劃。對于數(shù)據(jù)模型，一般情況下建議采用星型模型，雪花模型則適用于維度表數(shù)據(jù)量較大、業(yè)務(wù)邏輯較復(fù)雜，需要節(jié)省空間和分清層次的情況。
數(shù)據(jù)庫災(zāi)備部分主要包含網(wǎng)絡(luò)拓撲、硬件清單和集群等內(nèi)容，用于確定數(shù)據(jù)庫備份的方案以應(yīng)對突發(fā)情況。另外，面對企業(yè)中激增的數(shù)據(jù)，在數(shù)據(jù)倉庫的基礎(chǔ)之上，需要用MPP等擴展方案來提高數(shù)據(jù)倉庫處理海量數(shù)據(jù)的能力。
3．項目管理方法
04
做好BI，
還要管好開發(fā)和交付過程！
敏捷BI開發(fā)
敏捷BI開發(fā)（敏捷開發(fā)）有優(yōu)點也有缺點，優(yōu)點在于靈活應(yīng)對需求變化，快速交付，其缺點也很明顯，即需要犧牲一定的技術(shù)穩(wěn)定性和美觀性。
所以，企業(yè)在考慮開發(fā)模式的時候要想清楚，自身的需求是變化較快還是長期不變？如果是前者，則項目必須快速交付，如果是后者，則可以慢慢開發(fā)。
例如，績效類項目就更適合敏捷開發(fā)，因為這類項目的需求一般變化頻率都很高，如果在一個考核周期內(nèi)沒有完成開發(fā)，下一個周期需求肯定會發(fā)生變更。
企業(yè)領(lǐng)導(dǎo)臨時提出的一些需求也是如此，由于是領(lǐng)導(dǎo)提出來的需求，IT部門一般會盡心盡力加班加點去實現(xiàn)，但最后開發(fā)出來的項目，領(lǐng)導(dǎo)可能用過幾次就不用了。對于這種情況，如果采用敏捷開發(fā)，先滿足領(lǐng)導(dǎo)的需求，等到后續(xù)項目功能被持續(xù)使用，再優(yōu)化升級會更加高效。
項目風(fēng)險管理
任何項目都存在不確定性，因此盡管有完美的規(guī)劃做指導(dǎo)，但也不可不考慮不確定性帶來的風(fēng)險。對風(fēng)險的管理以事前管理和事中管理為佳。
做項目規(guī)劃時準確預(yù)測風(fēng)險，實施項目時有效管控風(fēng)險，都能夠最大限度地避開風(fēng)險或減小損失，保障項目最終落地。
就BI項目而言，風(fēng)險一般存在于管理、需求、數(shù)據(jù)質(zhì)量、原型、硬件環(huán)境等方面，如表8所示，表中也描述了相應(yīng)的規(guī)避措施。
表8 BI項目風(fēng)險及規(guī)避措施
類 別 | 風(fēng) 險 | 規(guī)避措施 |
管理風(fēng)險 | 項目中XX方組織松散，缺乏有效的協(xié)調(diào)和溝通，導(dǎo)致項目工作效率低下 | 需要公司領(lǐng)導(dǎo)密切關(guān)注，發(fā)揮強大推動作用，提高執(zhí)行力，促進交流，提高效率 |
目標偏差：各級人員對項目目標的理解不一致，存在潛在第二目標 | 通過培訓(xùn)、交談等方式進行互動，在對目標的理解一致后進行下一步行動 | |
業(yè)務(wù)人員不配合：業(yè)務(wù)人員工作繁忙，無法投入足夠精力參與項目 | 項目實施期間，通過制度保證業(yè)務(wù)人員投入BI項目的時間 | |
需求風(fēng)險 | 項目業(yè)務(wù)分析主題不明確，可能造成項目實施寬度和深度不確定 | ① 對各部門加強培訓(xùn)，組織內(nèi)部討論，協(xié)調(diào)資源，組建需求挖掘小組② 協(xié)調(diào)顧問，對業(yè)務(wù)進行梳理和引導(dǎo) |
目標偏差：各級人員對項目目標理解不一致，存在潛在第二目標 | 通過培訓(xùn)、交談等方式進行互動，在對目標的理解一致后進行下一步行動 | |
數(shù)據(jù)質(zhì)量 | 數(shù)據(jù)來源：多數(shù)據(jù)源不一致、潛在的數(shù)據(jù)錄入錯誤 | 加深對業(yè)務(wù)系統(tǒng)的理解，發(fā)現(xiàn)數(shù)據(jù)質(zhì)量問題，提出合理的解決方案 |
類 別 | 風(fēng) 險 | 規(guī)避措施 |
數(shù)據(jù)缺失：系統(tǒng)需要的數(shù)據(jù)無法獲取或需要補錄 | 通過完善業(yè)務(wù)系統(tǒng)、二次開發(fā)補錄系統(tǒng)、直接補錄等方式解決 | |
信息缺失：各業(yè)務(wù)系統(tǒng)管理軟件的廠商無法提供數(shù)據(jù)源字典和技術(shù)上的支持 | 盡量獲取技術(shù)支持，如果由于特殊原因無法獲取支持，可以由熟悉業(yè)務(wù)系統(tǒng)的IT人員和實施小組共同解決 | |
控制失效：數(shù)據(jù)質(zhì)量控制失效，業(yè)務(wù)系統(tǒng)負載過重，失去對臟數(shù)據(jù)來源的跟蹤 | 設(shè)立業(yè)務(wù)系統(tǒng)隔離區(qū)，生成數(shù)據(jù)抽取批次日志，設(shè)立時間窗口，采取數(shù)據(jù)分區(qū)控制 | |
原型風(fēng)險 | 原型設(shè)計：對業(yè)務(wù)理解不足，驗收模型的基礎(chǔ)維度和指標設(shè)計偏離正確方向 | 通過培訓(xùn)加強雙方對業(yè)務(wù)的理解，以及對維度模型設(shè)計方法的理解 |
原型驗證：過于關(guān)注報表樣式而忽略業(yè)務(wù)含義，忽視對多維模型結(jié)構(gòu)的驗證 | 明確驗證任務(wù)，劃定討論范圍，講解模型邏輯 | |
硬件環(huán)境 | 目前機房、網(wǎng)絡(luò)及服務(wù)器的實際情況不是很理想 | 在當前條件下，優(yōu)化機房資源和網(wǎng)絡(luò)，努力保證服務(wù)器性能 |
需求變更管理
項目需求與項目風(fēng)險類似，前期做的需求分析再完善，受到眾多不確定因素的影響，項目需求也很難保證一成不變，因此項目實施過程中經(jīng)常會遇到需求突然變更的情況。
既然需求的變更不可避免，應(yīng)對的關(guān)鍵就在于對變更進行更有效的控制，若控制不當會對整個項目的進度、成本、質(zhì)量等產(chǎn)生較大影響。
需求變更管理同樣要求項目團隊事先做好規(guī)劃，避免需求變更時沒有完善的應(yīng)對方案而影響項目整體的進度和質(zhì)量。在發(fā)生需求變更時應(yīng)及時做好管控。
通常情況下，需求變更要經(jīng)過變更申請、變更評估、決策、回復(fù)等4個步驟，若變更申請通過則需要增加實施變更和驗證變更這兩個步驟。
需要注意的是，變更需求時一定要先申請再評估。對于發(fā)生變更的需求，首先需要識別其是否在既定的項目范圍之內(nèi)。如果變更在項目范圍之內(nèi)，項目團隊應(yīng)評估變更所造成的影響，并將信息傳達給受影響的各方人員，然后再根據(jù)影響程度決定是否變更。若確定變更，就制訂相應(yīng)的應(yīng)對措施，解決變更的需求。如果變更在項目范圍之外，項目團隊就需要與用戶進行溝通和談判，討論是否增加費用或放棄變更。
項目驗收管理
推薦閱讀：
不是你需要中臺，而是一名合格的架構(gòu)師（附各大廠中臺建設(shè)PPT）
企業(yè)IT技術(shù)架構(gòu)規(guī)劃方案
論數(shù)字化轉(zhuǎn)型——轉(zhuǎn)什么，如何轉(zhuǎn)？
企業(yè)10大管理流程圖，數(shù)字化轉(zhuǎn)型從業(yè)者必備！
【中臺實踐】華為大數(shù)據(jù)中臺架構(gòu)分享.pdf