資料指標體系全方位解讀(附案例分析) 1. 01 如何建體系：自上而下&自下而上相結合1.1 介紹如何構建指標體系2. 02 自上而下的方法：基於企業自身業務戰略2.1 自上而下演繹：以價值樹方式逐層拆解指標示例3. 03 自下而上的方法：基於企業現有指標體系3.1 指標體系框架：多維度、多層級、全場景覆蓋3.2 由上至下可以分成三層，決策層、管理層和執行層。3.3 形成指標庫3.4 指標庫分成三個視角去看，業務屬性、技術屬性以及管理屬性3.5 招標全生命週期管理3.6 指標管理角色的定義3.7 以經銷商的營運分析體系為例4. 04 如何建底層：貼源-明細-彙總-應用4.1 指標來自於資料倉庫和資料集市，底層倉庫/集市是如何搭建的5. 05 如何用指標：BI分析為主，多層次應用5.1 構建好底層資料倉庫和指標體系後，如何應用指標5.2 現有BI應用絕大部分屬於統計型5.3 AI在統計型BI的應用場景中，側重輸入標準化，引導客戶思路5.4 此外，還可以拆解分析過程，啟發使用者思路6. 06 最後6.1 資料專案的最大風險：建完了，沒人用。大多數企業數位轉型已經取得初步成果，戰略方向上基本明確，組織架構上有足夠支撐，系統工具上基本完成建設。不過實際的轉型效果依然參差不齊，不少機構仍然存在戰略與執行脫節，取數難用數難，指標口徑不統一，同名不同義等痛點。 究其原因，大多數的問題都在指標上，因為指標是監控與貫徹戰略的抓手，取數、用數自然也是為了計算指標，口徑不一等指標的痛點，自然也影響業務監測，進而導致戰略與執行脫節。 因此，資料指標能否用得好，成為數位轉型的關鍵，本節將介紹資料指標在行業中的應用，重點圍繞下面三點展開： 1. 01 如何建體系：自上而下&自下而上相結合 1. 介紹如何構建指標體系 指標體系設計框架已較為成熟，主要來源於企業戰略自上而下的演繹，以及一線業務實操自下而上的歸納。基於這種設計方法，再加上底層應用和管理體系的支撐，共同構成了一個整體的經營分析的指標庫。 整體的目標制定是基於公司的發展戰略，如2024年度戰略規劃、數位轉型規劃等，分析戰略實現的決定性因素，梳理指示實現價值的可測量資料，進而形成一級指標，或稱北極星指標。 指標體系是按照自上而下演繹、自下而上歸納兩個方法結合，多維多層指標框架是對整個業務板塊指標的梳理，在每一個板塊裡面橫向展開指標業務的維度，縱向基於整個指標的層級，從戰略指標展開至經營管理指標、業務執行指標。指標體系梳理完畢，應用包括視覺化、流程、使用者互動等。指標的管理體系，需要基於管理制度、管理流程、組織職責。 2. 02 自上而下的方法：基於企業自身業務戰略 基於公司業務發展戰略，透過企業價值樹分解，梳理企業核心關鍵KPI，形成指標庫。戰略銜接需要透過核心指標拆解成為各個部門的承接指標，但是這些指標中的維度和口徑之間會有區別，這些區別是整個指標體系設計裡面需要重點關注的各項標準。 這裡需要引入"價值樹"的概念，可以理解為戰略分解的關鍵影響因素，可以拆分為不同層次的價值流，比如綠色工廠裡面可能會分解為相應的供應鏈，供應鏈裡面又可以分解成為不同的價值流，包括每個環節的響應效率、每個環節執行的質量健康度、基於時效和質量產生的對應成本等。 其次，這些價值流在不同業務板塊都有不同的呈現方式，需要根據價值驅動因素優先順序進行排列，比如目前哪些部門裡面的哪些對應的價值流是需要核心先關注的。 自上而下的演繹包括制定北極星指標、建立價值樹和價值驅動因素優先順序，逐步拆解形成指標。例如，提升客戶活躍和留存的北極星指標，可以拆成增加客戶留存、提升產品銷售能力和提升審批效率等二級指標，再向下可以拆成增加客戶留存、提升客戶粘性、提升客戶忠誠度、促進交易量等子指標。 這種自上而下演繹的方法論和傳統指標體系建設方式存在一定差異，傳統指標體系通常是拆解到維度，而這裡則注重指標上下級之間的關聯。在大指標出現異常的時候，會對其下的子指標進行分析，尋找原因，而不是單純的只看大指標的維度。 1. 自上而下演繹：以價值樹方式逐層拆解指標示例 有了自上而下演繹得到的指標，為什麼還要做自下而上的歸納呢？因為演繹過程中，可能為了追蹤新的戰略目標，而設定一些新指標，這些指標對一線業務來說是比較陌生的，因此還需要收集一線常用的指標並將其體系化，進行自下而上的歸納。兩個方向相結合，形成最終的指標庫。 3. 03 自下而上的方法：基於企業現有指標體系 透過指標的收集、解析、整合和歸類，形成指標庫。也叫做歸納法，透過梳理企業現有的經營指標去歸納總結，形成相應的指標互補，最終形成一個多維、多層級、全場景覆蓋的指標樹。比如提升渠道能力，可能涉及很多指標，我們把各個渠道的，比如網銀的、客戶經理產能的指標都細分出來，歸納到體系中，形成一個結合業務維度和技術維度的全場景的指標體系框架。 指標在收集的過程中，一方面需要對一線的業務系統做收集，一方面要對當前日常彙報材料進行歸納彙總，包括定期覆盤會、各級管理會議相應的資料，這些資料可以幫助去做整合歸類，而整合中又會用到目前指標的業務維度、技術維度等。但是自下而上梳理的過程中，也存在不同部門之間可能會有重合指標的情況，而這些重合的指標甚至可能也會在對應口徑上有出入。 為了解決這種問題，最好的解決方式之一是設定業務的指標owner，不同業務的指標owner會幫助整個指標梳理的過程形成更好的聚合。 1. 指標體系框架：多維度、多層級、全場景覆蓋 案例1：供應鏈環節 具體的指標盤點主要包括七大步驟，即透過調研訪談梳理業務條線、場景，以及業務流程和過程，覆蓋所有業務條線和場景、流程，形成原子指標，進而形成衍生指標。 以供應鏈的採購執行為例，採購執行可以分為對整個物料需求的拆解，到需求的下單，再到供應商的對接。採購執行環節包含了不同的流程，整個資訊流裡面會包含單據，所以這些流程和單據幫助企業構成了一個業務環節，這個業務環節所對應的原子指標同時也可以明確出其分析維度，比如供應商的維度、對應產品線的維度、不同財務科目的維度等，這些維度可以幫助企業去拆解出來KPI。基於這樣的KPI，就可以明確出計算邏輯，最終透過平臺落地。 最終形成一個圖譜，涵蓋所有的環節，可以看到每個環節中有多少指標。如果某個環節沒有指標，就說明存在遺漏，需要針對性地去補充指標；而如果某個環節指標偏多，則可能是KPI導向或者存在重複指標。這樣梳理出的圖譜就會比較完整，並且是基於統一價值鏈的。 需要特別注意"補資料"動作，不同的業務板塊裡面可以拆解出來相應的業務環節，以及對業務環節拆解出相應的原子指標，但是同時企業也需要去注意採取主動或者被動的方式去補充相應的資料指標。 比如供應鏈裡面供應商的管理，需要去根據現在的系統做一個比照，包括供應商的降本、供應商的配額等，這樣就可以幫助企業檢視哪些資料已經覆蓋，哪些資料還沒有覆蓋。 案例2：LTC環節 2. 由上至下可以分成三層，決策層、管理層和執行層。 決策層關注的人均產值、銷售收入、淨利潤、資金週轉、銷售訂單的情況，再往下拆解就對應到業務環節裡面，包括銷售拜訪、訂單簽訂流程、發貨出運的流程等等。這些流程構成管理層想要的核心指標，並拆解成具體的維度，比如產品、訂單、銷售業務、財務等。 繼續往下看，這些維度會涉及到執行層裡面詳細的一些指標的戰略體系，基於指標體系在價值流的過程中可以梳理出多維的價值動因分析，再去對相應的問題進行拆解指標，解決問題。 舉一個場景的案例，比如要對目前某個期間內訂單下滑明顯的行業，以及對應的客戶進行定位，就先要對客戶的類別、當前合同類別、延期提貨、以及訂單狀態等生命狀態去做相應的監控。要注意去觀察是否在某個期間內有客戶的價格是明顯低於紅線價的，依照LTC環節，分解出一個一個價值的動因。透過這樣的方式，最終可以解決在業務環節中指標體系的完整性和業務問題。 3. 形成指標庫 指標定義，應包括業務屬性、技術屬性和管理屬性，特別是屬主部門非常關鍵，需要明確由哪個部門對該指標的定義負責，當指標數值出現偏差時誰負責修正，指標管理中的很多痛點都是源於屬主部門沒有定義清楚。 4. 指標庫分成三個視角去看，業務屬性、技術屬性以及管理屬性 ● 業務屬性包括指標含義、指標業務口徑、計算規則、統計區間以及相應的統計頻率。 ● 技術屬性包括系統的欄位名稱、指標數值型別、指標的技術口徑等。 ● 管理屬性包括指標分類和屬主部門(指標的owner)。 5. 招標全生命週期管理 指標體系建好之後，還要管理好。首先，需求收集流程要明確，即需求誰來提、誰來處理。指標的拆分建立流程，也要定義好各部門的職責。 接下來，指標的審批、發佈，後期的監控和失效歸檔，都需要建立相應的機制。譬如，某股份制銀行的資料資產平臺中存在6–7個AUM指標，無法明確該用哪個，所以只好再增加一個，如此下去就可能導致指標的無限增長，因此需要一套完善的體系對指標的使用進行監控、分析和管理。 6. 指標管理角色的定義 分為指標的owner、指標落地的開發者，指標管理的維護者，指標的消費者。這些不同的管理角色可以對應到端到端的指標分解的流程（指標需求收集-指標拆分創建-指標發佈應用-指標歸檔失效）中，以及管理制度中。 指標管理的第一步是進行指標需求的收集，需要對齊業務口徑，資料初探以及梳理分歧/冗餘指標。在整個指標全生命週期管理的過程中，需要每一個業務部門的高層牽頭去做業務指標的定期最佳化改進，比如可以透過定期的覆盤會的形式。 7. 以經銷商的營運分析體系為例 將戰略指標進行拆解，對於經銷商的覆蓋率會下沉到對每一個三-六線城市進行分析；對於庫存是要考慮每一個工廠、每一個基地，每一個城市的分倉/中心倉等等。對於這些維度進行營運動作的分析拆解，比如考慮城市內的門店覆蓋率，必備單品的品規數，相應門店活動的投資金額、品牌的覆蓋等等。 以大區負責人的視角為例，本月預估是可以4個大區達成75%，但是其中的東區整體目標達成只有70%。在這種情況下，需要去關注這些變化來分析東區。同時，可以透過看中心倉/分倉，以及不同的區域和經銷商來看目前必備單品/新品庫存、暢銷品庫存的情況等。這些庫存的情況一方面可以幫助企業指導經銷商大力去推廣哪些品類，另外一方面可以幫企業透過經銷商的視角去預測。 4. 04 如何建底層：貼源-明細-彙總-應用 1. 指標來自於資料倉庫和資料集市，底層倉庫/集市是如何搭建的 資料倉庫的標準結構包括ODS層、DWD層、DWS層、ADS層。目前很多企業在使用BI等資料應用的時候，資料直接由ODS對接到資料應用，缺少了中間各層的資料加工。應用層直接讀取原始資料，由於明細資料量很大，會導致應用層很慢，不同的分析師從ODS從頭按自己的理解加工，也會帶來指標口徑不一致的問題。因此企業一定要建資料倉庫、建集市，一層一層地建設，最後透過ADS層來服務各類資料應用。 ● DWD層：主要做清洗和落標的工作，對於垃圾資料、髒資料、空資料、不符合碼值的資料會統一在這層做清洗，統一標準。同時在該層做一些維度退化，把表適度做寬。最後是做資料脫敏的工作。 ● DWS層：即彙總層，將資料彙總成服務於某一主題的寬表，不面向特定應用。 ● 彙總層：表需要滿足通用性，原則上不跨主題域，並且要標明統計週期，因為不同域的時效性不一樣，還要避免將不同層級的資料放在一起。 如果直接從底層資料取數，那麼指標的邏輯會寫在SQL中。例如授信餘額這一指標，業務含義是在授信額度上減掉已用額度所剩下的額度，如果沒有提前在彙總層中把授信餘額計算好，每個人對指標含義的理解可能不同，就會導致不同系統算出來的授信餘額不一樣，可能帶來超額授信等風險。出現指標差異，要去查底層邏輯也會非常耗時耗力。 如果把授信餘額口徑提前在彙總層加工好，在指做指標時只需要篩選客戶型別，然後選中授信餘額，就可以出指標，這樣業務部門就有了自己分析指標的基礎，因此數倉的良好構建非常必要。 5. 05 如何用指標：BI分析為主，多層次應用 1. 構建好底層資料倉庫和指標體系後，如何應用指標 指標主要用在BI分析，可分為4個層次，統計型、歸因型、預測型、決策型。 BI 分析是指標應用的主要場景，主要包括4種類型 ● 第一種是統計型 即基於現在的資料做統計分析，瞭解現在的資料呈現怎樣的特徵，這是大多數客戶使用BI的場景。 ● 第二種是歸因型 即瞭解為什麼資料會呈現某種統計結果，是由哪些原因導致的，可以透過指標的維度分佈檢視，也可以透過下鑽檢視關聯指標和子指標的情況。 ● 第三種是預測型 即根據現有的資料去預測未來的趨勢。現在通常的做法是透過一個專案來做，例如在金融行業裡預測下個週期的不良率，或某個客戶的投訴機率，在風險領域的建模，就是這樣一個過程，很少能透過BI直接完成這個建模和預測的過程。當然目前有拖拉拽式的自助式建模分析平臺，這是另一條技術路線。 ● 第四種是決策型 現在能做到這一步的非常少，或者說這不是BI的定位。決策型是指當發現某業務的趨勢後，直接透過介面把需要修正的業務透過API傳送給業務系統進行修正，例如改一個開關功能、改限額、改屬性等，整體是把BI的邊界做得很大，這是不是BI的職責目前還沒有定論。但這確實是指標分析的終極目標，即能夠完成從分析、歸因到改進的閉環，並且能夠監控改進後的結果。 目前絕大多數BI都屬於統計型，包括報表和大屏一類的視覺化應用。 2. 現有BI應用絕大部分屬於統計型 隨著人工智慧技術近兩年突飛猛進的發展，AI for BI這個賽道最近又熱了起來，AI 在統計型BI中，能幫使用者做些什麼呢？ 3. AI在統計型BI的應用場景中，側重輸入標準化，引導客戶思路 利用大模型的能力，可以透過問答的形式，給到一些原因的提示，如果輸入的內容其他人已經輸入過，或者在庫裡能夠匹配到這些度量或者維度，系統會做一些提示，也可以幫助引導分析思路。 分析出來後，產品會把整個的意圖和分析過程展示出來，由使用者確認分析路徑是不是有問題，使用者也可以在上面直接去改維度和分析的度量。這就是目前FineBI在嘗試的問答BI產品。 4. 此外，還可以拆解分析過程，啟發使用者思路 統計型BI更多的還是為你展示資料是什麼樣的，但不能告訴你為什麼。基於這一問題，FineBI提供了資料解釋的功能，可以初步完成歸因和下鑽。 ● 帆軟FineBI資料解釋功能可以完成初步的歸因和下鑽 比上圖所示，可以看到2016年利潤突然上漲很多，一般在傳統BI中需要把該指標提出來，再去數倉中做分析。FineBI的資料解釋功能，可以自動將利潤指標所涉及的維度全查出來，這樣就可以看到哪個維度佔比最大，比如A產品的利潤佔88%，是主要的貢獻者，可以繼續下鑽檢視A產品在不同地區的銷量，又發現華北的A產品銷量貢獻最大。 這樣就得到了初步的歸因，但這還是基於維度的，有時維度差異不大，再往下鑽維度差異也不大，就說明可能不是這些維度的影響，可能是底層其他子指標的影響，因此需要進一步的歸因分析。 在完成初步的分析以後，還可以進行深度歸因，這是基於指標體系構建時不同指標之間上下級的關係。 ● BI分析的深層次價值，體現在現有指標的影響歸因 例如信用卡的透支餘額指標，可能受卡數量和戶均餘額影響，這就是指標體系構建時，將北極星指標拆解到兩個子指標，還可以繼續下拆，比如卡數量可能受申請總量和透過率影響，申請總量又可以看不同的渠道，到底是線上還是線下渠道的申請總量變動比較多。 類似的拆分邏輯是基於業務知識的沉澱，透過大模型以及問答BI，學習業務人員的分析思路，最終體現在產品中，給出一些提示和建議。 ● AI在歸因領域，可以推薦不同維度進行計算展示，同時挖掘關鍵影響因素 比如在問答時自動彈出一些推薦，提示是否要看一些關聯指標。這是AI在指標管理和BI領域中的一個非常好的應用場景。 ● 在預測型BI領域，重點還是依靠規則和機器學習模型，給出特定場景的預測結果 預測型BI相對比較困難，目前大多是透過專案來實現。通常會涉及一些邏輯迴歸等模型，需要對大量的歷史資料做處理，之後形成對未來的洞察。例如預測投訴，客戶多次訪問頁面並在與客服通話中多次表達不滿，這些都是客戶投訴的前期表現，有了這樣的資料積累後，就可以預測客戶在哪些日期存在較大機率會投訴。 如果透過BI或指標來分析比較困難，首先這其中涉及非常多的非結構化資料以及非數值資料，需要進行WOE或onehot變換，其次到底是哪些因素影響的Y變數，很難判斷，需要非常多的資料積累，反覆的調參以及業務人員的經驗，因此通常透過專案來實現。 ● What's Next ? 繼續拆分，定位問題，並且聯動業務系統解決問題 基於歸因分析發現了問題根因，然後透過API或者在跳轉業務平臺的直接操作，完成問題發現、歸因到解決的閉環。 例如前面的例子，卡量下降8%，經過分析發現線上申請總量下降了9%，那麼就要定位到線上渠道去解決問題，如果解決不了可以督辦下去，這就涉及到經營分析的一些思路，即透過指標分析和歸因識別到問題以後，督辦問題負責人予以解決，把問題轉給渠道管理來解決。 又比如，筆均交易額突然出現大幅下跌，筆均交易額通常是受交易渠道限額影響，接下來去分析渠道的限額，如果發現確實是交易限額有變化，就可以去修改限額設定，直接在BI裡面完成介面修改。 這就是將來指標管理和BI產品的一個可能的方向，即完成統計、歸因、預測、決策的閉環，在BI中直接解決問題，這樣使資料分析的價值更加顯性化。 ● 構建完整的指標庫可以將指標歸因拆解邏輯內化，指導指標分析 指標體系都儲存在指標庫中，可以由專門的指標管理系統來儲存，不過不必糾結於工具，比如我們團隊的指標庫就是基於飛書線上文件實現的，包括業務架構、指標清單、管理要素、指標模型、維度清單等，還包括常用指標展示的駕駛艙和資料應用場景等。例如前面舉例的信用卡餘額指標，拆解為數量和餘額，以及進一步拆分成申請總量和透過率，這些都可以透過父子指標的層級配置實現。 北極星指標的拆解關係都配在指標庫中，業務人員想要分析時，只要在指標庫裡面查一下這個指標的下級指標都有哪些、怎樣使用，還可以疊加不同的維度，就可以完成指標的下鑽和歸因分析。 6. 06 最後 1. 資料專案的最大風險：建完了，沒人用。 所有的產品的最終目標是讓業務人員可以直接使用。然而目前在很多企業，BI的推廣和使用還存在很多問題，比如一些年齡比較大業務人員不會使用或者說抗拒使用，還有些人認為應該由技術人員來做，資料分析的職責不清。 針對這些問題，最關鍵的是組織架構上，需要有相應的資料分析團隊幫業務部門分析，而且資料分析團隊最好內建在業務部門，每個業務團隊有1–2個資料分析崗，這些人員由業務部門考核，逐步的讓業務條線感受到資料的作用，以及資料分析上手不難，這是需要一個過程的。 資料專案的最大風險就是建完了以後沒人用，因為資料專案與業務系統不同，通常是非剛需專案，不是雪中送炭，只是錦上添花，即沒有這一套產品，業務也能生存下去。所以在做資料類專案時，經常是建完以後業務部門覺得學習或遷移成本太高，沒必要用，業務部門還是習慣在原有的邏輯中去完成。甚至有一些業務人員認為數位化對其自身是一種威脅，原來所有的業務經驗和知識，包括客戶都在腦子裡，如透過數位化的手段固化到系統中，那個人的價值在哪？ 因此要讓業務人員充分參與，意識到產品能夠減輕工作量而不是增加工作量，需要長期的宣導、培訓、競賽，把企業的資料文化建立起來，這是最核心的工作。 通常的培訓都是產品上線後介紹產品操作方法，做起來非常簡單，但是絕大多數情況下不起作用。現在帆軟有專門的團隊透過一套方法論來引導客戶，而不是單純的講產品功能。整體包括資料人才診斷、培養和評估三個環節：先看整個組織架構有沒有問題，包括人才體系建設、職能崗位職責分佈；然後去做培訓，有線上、線下、集中、分散、點對點、批次等多種方式；之後去做評估，包括FCA和FCP認證。 http://mepopedia.com/forum/read.php?516,94684,94684#msg-94684 Sun, 25 Oct 2026 04:58:46 +0800 Phorum 5.2.7 http://mepopedia.com/forum/read.php?516,94684,94684#msg-94684 資料指標體系全方位解讀(附案例分析) http://mepopedia.com/forum/read.php?516,94684,94684#msg-94684
  1. 1. 01 如何建體系：自上而下&自下而上相結合
  2. 1.1 介紹如何構建指標體系
  3. 2. 02 自上而下的方法：基於企業自身業務戰略
  4. 2.1 自上而下演繹：以價值樹方式逐層拆解指標示例
  5. 3. 03 自下而上的方法：基於企業現有指標體系
  6. 3.1 指標體系框架：多維度、多層級、全場景覆蓋
  7. 3.2 由上至下可以分成三層，決策層、管理層和執行層。
  8. 3.3 形成指標庫
  9. 3.4 指標庫分成三個視角去看，業務屬性、技術屬性以及管理屬性
  10. 3.5 招標全生命週期管理
  11. 3.6 指標管理角色的定義
  12. 3.7 以經銷商的營運分析體系為例
  13. 4. 04 如何建底層：貼源-明細-彙總-應用
  14. 4.1 指標來自於資料倉庫和資料集市，底層倉庫/集市是如何搭建的
  15. 5. 05 如何用指標：BI分析為主，多層次應用
  16. 5.1 構建好底層資料倉庫和指標體系後，如何應用指標
  17. 5.2 現有BI應用絕大部分屬於統計型
  18. 5.3 AI在統計型BI的應用場景中，側重輸入標準化，引導客戶思路
  19. 5.4 此外，還可以拆解分析過程，啟發使用者思路
  20. 6. 06 最後
  21. 6.1 資料專案的最大風險：建完了，沒人用。
大多數企業數位轉型已經取得初步成果，戰略方向上基本明確，組織架構上有足夠支撐，系統工具上基本完成建設。不過實際的轉型效果依然參差不齊，不少機構仍然存在戰略與執行脫節，取數難用數難，指標口徑不統一，同名不同義等痛點。

究其原因，大多數的問題都在指標上，因為指標是監控與貫徹戰略的抓手，取數、用數自然也是為了計算指標，口徑不一等指標的痛點，自然也影響業務監測，進而導致戰略與執行脫節。

因此，資料指標能否用得好，成為數位轉型的關鍵，本節將介紹資料指標在行業中的應用，重點圍繞下面三點展開：



1. 01 如何建體系：自上而下&自下而上相結合



1. 介紹如何構建指標體系



指標體系設計框架已較為成熟，主要來源於企業戰略自上而下的演繹，以及一線業務實操自下而上的歸納。基於這種設計方法，再加上底層應用和管理體系的支撐，共同構成了一個整體的經營分析的指標庫。

整體的目標制定是基於公司的發展戰略，如2024年度戰略規劃、數位轉型規劃等，分析戰略實現的決定性因素，梳理指示實現價值的可測量資料，進而形成一級指標，或稱北極星指標。



指標體系是按照自上而下演繹、自下而上歸納兩個方法結合，多維多層指標框架是對整個業務板塊指標的梳理，在每一個板塊裡面橫向展開指標業務的維度，縱向基於整個指標的層級，從戰略指標展開至經營管理指標、業務執行指標。指標體系梳理完畢，應用包括視覺化、流程、使用者互動等。指標的管理體系，需要基於管理制度、管理流程、組織職責。

2. 02 自上而下的方法：基於企業自身業務戰略



基於公司業務發展戰略，透過企業價值樹分解，梳理企業核心關鍵KPI，形成指標庫。戰略銜接需要透過核心指標拆解成為各個部門的承接指標，但是這些指標中的維度和口徑之間會有區別，這些區別是整個指標體系設計裡面需要重點關注的各項標準。

這裡需要引入"價值樹"的概念，可以理解為戰略分解的關鍵影響因素，可以拆分為不同層次的價值流，比如綠色工廠裡面可能會分解為相應的供應鏈，供應鏈裡面又可以分解成為不同的價值流，包括每個環節的響應效率、每個環節執行的質量健康度、基於時效和質量產生的對應成本等。

其次，這些價值流在不同業務板塊都有不同的呈現方式，需要根據價值驅動因素優先順序進行排列，比如目前哪些部門裡面的哪些對應的價值流是需要核心先關注的。

自上而下的演繹包括制定北極星指標、建立價值樹和價值驅動因素優先順序，逐步拆解形成指標。例如，提升客戶活躍和留存的北極星指標，可以拆成增加客戶留存、提升產品銷售能力和提升審批效率等二級指標，再向下可以拆成增加客戶留存、提升客戶粘性、提升客戶忠誠度、促進交易量等子指標。



這種自上而下演繹的方法論和傳統指標體系建設方式存在一定差異，傳統指標體系通常是拆解到維度，而這裡則注重指標上下級之間的關聯。在大指標出現異常的時候，會對其下的子指標進行分析，尋找原因，而不是單純的只看大指標的維度。

1. 自上而下演繹：以價值樹方式逐層拆解指標示例





有了自上而下演繹得到的指標，為什麼還要做自下而上的歸納呢？因為演繹過程中，可能為了追蹤新的戰略目標，而設定一些新指標，這些指標對一線業務來說是比較陌生的，因此還需要收集一線常用的指標並將其體系化，進行自下而上的歸納。兩個方向相結合，形成最終的指標庫。

3. 03 自下而上的方法：基於企業現有指標體系



透過指標的收集、解析、整合和歸類，形成指標庫。也叫做歸納法，透過梳理企業現有的經營指標去歸納總結，形成相應的指標互補，最終形成一個多維、多層級、全場景覆蓋的指標樹。比如提升渠道能力，可能涉及很多指標，我們把各個渠道的，比如網銀的、客戶經理產能的指標都細分出來，歸納到體系中，形成一個結合業務維度和技術維度的全場景的指標體系框架。

指標在收集的過程中，一方面需要對一線的業務系統做收集，一方面要對當前日常彙報材料進行歸納彙總，包括定期覆盤會、各級管理會議相應的資料，這些資料可以幫助去做整合歸類，而整合中又會用到目前指標的業務維度、技術維度等。但是自下而上梳理的過程中，也存在不同部門之間可能會有重合指標的情況，而這些重合的指標甚至可能也會在對應口徑上有出入。

為了解決這種問題，最好的解決方式之一是設定業務的指標owner，不同業務的指標owner會幫助整個指標梳理的過程形成更好的聚合。

1. 指標體系框架：多維度、多層級、全場景覆蓋





案例1：供應鏈環節

具體的指標盤點主要包括七大步驟，即透過調研訪談梳理業務條線、場景，以及業務流程和過程，覆蓋所有業務條線和場景、流程，形成原子指標，進而形成衍生指標。

以供應鏈的採購執行為例，採購執行可以分為對整個物料需求的拆解，到需求的下單，再到供應商的對接。採購執行環節包含了不同的流程，整個資訊流裡面會包含單據，所以這些流程和單據幫助企業構成了一個業務環節，這個業務環節所對應的原子指標同時也可以明確出其分析維度，比如供應商的維度、對應產品線的維度、不同財務科目的維度等，這些維度可以幫助企業去拆解出來KPI。基於這樣的KPI，就可以明確出計算邏輯，最終透過平臺落地。



最終形成一個圖譜，涵蓋所有的環節，可以看到每個環節中有多少指標。如果某個環節沒有指標，就說明存在遺漏，需要針對性地去補充指標；而如果某個環節指標偏多，則可能是KPI導向或者存在重複指標。這樣梳理出的圖譜就會比較完整，並且是基於統一價值鏈的。

需要特別注意"補資料"動作，不同的業務板塊裡面可以拆解出來相應的業務環節，以及對業務環節拆解出相應的原子指標，但是同時企業也需要去注意採取主動或者被動的方式去補充相應的資料指標。

比如供應鏈裡面供應商的管理，需要去根據現在的系統做一個比照，包括供應商的降本、供應商的配額等，這樣就可以幫助企業檢視哪些資料已經覆蓋，哪些資料還沒有覆蓋。



案例2：LTC環節

2. 由上至下可以分成三層，決策層、管理層和執行層。



決策層關注的人均產值、銷售收入、淨利潤、資金週轉、銷售訂單的情況，再往下拆解就對應到業務環節裡面，包括銷售拜訪、訂單簽訂流程、發貨出運的流程等等。這些流程構成管理層想要的核心指標，並拆解成具體的維度，比如產品、訂單、銷售業務、財務等。

繼續往下看，這些維度會涉及到執行層裡面詳細的一些指標的戰略體系，基於指標體系在價值流的過程中可以梳理出多維的價值動因分析，再去對相應的問題進行拆解指標，解決問題。



舉一個場景的案例，比如要對目前某個期間內訂單下滑明顯的行業，以及對應的客戶進行定位，就先要對客戶的類別、當前合同類別、延期提貨、以及訂單狀態等生命狀態去做相應的監控。要注意去觀察是否在某個期間內有客戶的價格是明顯低於紅線價的，依照LTC環節，分解出一個一個價值的動因。透過這樣的方式，最終可以解決在業務環節中指標體系的完整性和業務問題。



3. 形成指標庫



指標定義，應包括業務屬性、技術屬性和管理屬性，特別是屬主部門非常關鍵，需要明確由哪個部門對該指標的定義負責，當指標數值出現偏差時誰負責修正，指標管理中的很多痛點都是源於屬主部門沒有定義清楚。

4. 指標庫分成三個視角去看，業務屬性、技術屬性以及管理屬性



● 業務屬性包括指標含義、指標業務口徑、計算規則、統計區間以及相應的統計頻率。
● 技術屬性包括系統的欄位名稱、指標數值型別、指標的技術口徑等。
● 管理屬性包括指標分類和屬主部門(指標的owner)。



5. 招標全生命週期管理



指標體系建好之後，還要管理好。首先，需求收集流程要明確，即需求誰來提、誰來處理。指標的拆分建立流程，也要定義好各部門的職責。

接下來，指標的審批、發佈，後期的監控和失效歸檔，都需要建立相應的機制。譬如，某股份制銀行的資料資產平臺中存在6–7個AUM指標，無法明確該用哪個，所以只好再增加一個，如此下去就可能導致指標的無限增長，因此需要一套完善的體系對指標的使用進行監控、分析和管理。

6. 指標管理角色的定義



分為指標的owner、指標落地的開發者，指標管理的維護者，指標的消費者。這些不同的管理角色可以對應到端到端的指標分解的流程（指標需求收集-指標拆分創建-指標發佈應用-指標歸檔失效）中，以及管理制度中。

指標管理的第一步是進行指標需求的收集，需要對齊業務口徑，資料初探以及梳理分歧/冗餘指標。在整個指標全生命週期管理的過程中，需要每一個業務部門的高層牽頭去做業務指標的定期最佳化改進，比如可以透過定期的覆盤會的形式。



7. 以經銷商的營運分析體系為例



將戰略指標進行拆解，對於經銷商的覆蓋率會下沉到對每一個三-六線城市進行分析；對於庫存是要考慮每一個工廠、每一個基地，每一個城市的分倉/中心倉等等。對於這些維度進行營運動作的分析拆解，比如考慮城市內的門店覆蓋率，必備單品的品規數，相應門店活動的投資金額、品牌的覆蓋等等。

以大區負責人的視角為例，本月預估是可以4個大區達成75%，但是其中的東區整體目標達成只有70%。在這種情況下，需要去關注這些變化來分析東區。同時，可以透過看中心倉/分倉，以及不同的區域和經銷商來看目前必備單品/新品庫存、暢銷品庫存的情況等。這些庫存的情況一方面可以幫助企業指導經銷商大力去推廣哪些品類，另外一方面可以幫企業透過經銷商的視角去預測。

4. 04 如何建底層：貼源-明細-彙總-應用



1. 指標來自於資料倉庫和資料集市，底層倉庫/集市是如何搭建的





資料倉庫的標準結構包括ODS層、DWD層、DWS層、ADS層。目前很多企業在使用BI等資料應用的時候，資料直接由ODS對接到資料應用，缺少了中間各層的資料加工。應用層直接讀取原始資料，由於明細資料量很大，會導致應用層很慢，不同的分析師從ODS從頭按自己的理解加工，也會帶來指標口徑不一致的問題。因此企業一定要建資料倉庫、建集市，一層一層地建設，最後透過ADS層來服務各類資料應用。

● DWD層：主要做清洗和落標的工作，對於垃圾資料、髒資料、空資料、不符合碼值的資料會統一在這層做清洗，統一標準。同時在該層做一些維度退化，把表適度做寬。最後是做資料脫敏的工作。

● DWS層：即彙總層，將資料彙總成服務於某一主題的寬表，不面向特定應用。

● 彙總層：表需要滿足通用性，原則上不跨主題域，並且要標明統計週期，因為不同域的時效性不一樣，還要避免將不同層級的資料放在一起。



如果直接從底層資料取數，那麼指標的邏輯會寫在SQL中。例如授信餘額這一指標，業務含義是在授信額度上減掉已用額度所剩下的額度，如果沒有提前在彙總層中把授信餘額計算好，每個人對指標含義的理解可能不同，就會導致不同系統算出來的授信餘額不一樣，可能帶來超額授信等風險。出現指標差異，要去查底層邏輯也會非常耗時耗力。

如果把授信餘額口徑提前在彙總層加工好，在指做指標時只需要篩選客戶型別，然後選中授信餘額，就可以出指標，這樣業務部門就有了自己分析指標的基礎，因此數倉的良好構建非常必要。

5. 05 如何用指標：BI分析為主，多層次應用



1. 構建好底層資料倉庫和指標體系後，如何應用指標



指標主要用在BI分析，可分為4個層次，統計型、歸因型、預測型、決策型。



BI 分析是指標應用的主要場景，主要包括4種類型

● 第一種是統計型

即基於現在的資料做統計分析，瞭解現在的資料呈現怎樣的特徵，這是大多數客戶使用BI的場景。

● 第二種是歸因型

即瞭解為什麼資料會呈現某種統計結果，是由哪些原因導致的，可以透過指標的維度分佈檢視，也可以透過下鑽檢視關聯指標和子指標的情況。

● 第三種是預測型

即根據現有的資料去預測未來的趨勢。現在通常的做法是透過一個專案來做，例如在金融行業裡預測下個週期的不良率，或某個客戶的投訴機率，在風險領域的建模，就是這樣一個過程，很少能透過BI直接完成這個建模和預測的過程。當然目前有拖拉拽式的自助式建模分析平臺，這是另一條技術路線。

● 第四種是決策型

現在能做到這一步的非常少，或者說這不是BI的定位。決策型是指當發現某業務的趨勢後，直接透過介面把需要修正的業務透過API傳送給業務系統進行修正，例如改一個開關功能、改限額、改屬性等，整體是把BI的邊界做得很大，這是不是BI的職責目前還沒有定論。但這確實是指標分析的終極目標，即能夠完成從分析、歸因到改進的閉環，並且能夠監控改進後的結果。

目前絕大多數BI都屬於統計型，包括報表和大屏一類的視覺化應用。

2. 現有BI應用絕大部分屬於統計型





隨著人工智慧技術近兩年突飛猛進的發展，AI for BI這個賽道最近又熱了起來，AI 在統計型BI中，能幫使用者做些什麼呢？

3. AI在統計型BI的應用場景中，側重輸入標準化，引導客戶思路





利用大模型的能力，可以透過問答的形式，給到一些原因的提示，如果輸入的內容其他人已經輸入過，或者在庫裡能夠匹配到這些度量或者維度，系統會做一些提示，也可以幫助引導分析思路。

分析出來後，產品會把整個的意圖和分析過程展示出來，由使用者確認分析路徑是不是有問題，使用者也可以在上面直接去改維度和分析的度量。這就是目前FineBI在嘗試的問答BI產品。

4. 此外，還可以拆解分析過程，啟發使用者思路





統計型BI更多的還是為你展示資料是什麼樣的，但不能告訴你為什麼。基於這一問題，FineBI提供了資料解釋的功能，可以初步完成歸因和下鑽。

● 帆軟FineBI資料解釋功能可以完成初步的歸因和下鑽



比上圖所示，可以看到2016年利潤突然上漲很多，一般在傳統BI中需要把該指標提出來，再去數倉中做分析。FineBI的資料解釋功能，可以自動將利潤指標所涉及的維度全查出來，這樣就可以看到哪個維度佔比最大，比如A產品的利潤佔88%，是主要的貢獻者，可以繼續下鑽檢視A產品在不同地區的銷量，又發現華北的A產品銷量貢獻最大。

這樣就得到了初步的歸因，但這還是基於維度的，有時維度差異不大，再往下鑽維度差異也不大，就說明可能不是這些維度的影響，可能是底層其他子指標的影響，因此需要進一步的歸因分析。

在完成初步的分析以後，還可以進行深度歸因，這是基於指標體系構建時不同指標之間上下級的關係。

● BI分析的深層次價值，體現在現有指標的影響歸因



例如信用卡的透支餘額指標，可能受卡數量和戶均餘額影響，這就是指標體系構建時，將北極星指標拆解到兩個子指標，還可以繼續下拆，比如卡數量可能受申請總量和透過率影響，申請總量又可以看不同的渠道，到底是線上還是線下渠道的申請總量變動比較多。

類似的拆分邏輯是基於業務知識的沉澱，透過大模型以及問答BI，學習業務人員的分析思路，最終體現在產品中，給出一些提示和建議。

● AI在歸因領域，可以推薦不同維度進行計算展示，同時挖掘關鍵影響因素



比如在問答時自動彈出一些推薦，提示是否要看一些關聯指標。這是AI在指標管理和BI領域中的一個非常好的應用場景。

● 在預測型BI領域，重點還是依靠規則和機器學習模型，給出特定場景的預測結果



預測型BI相對比較困難，目前大多是透過專案來實現。通常會涉及一些邏輯迴歸等模型，需要對大量的歷史資料做處理，之後形成對未來的洞察。例如預測投訴，客戶多次訪問頁面並在與客服通話中多次表達不滿，這些都是客戶投訴的前期表現，有了這樣的資料積累後，就可以預測客戶在哪些日期存在較大機率會投訴。
如果透過BI或指標來分析比較困難，首先這其中涉及非常多的非結構化資料以及非數值資料，需要進行WOE或onehot變換，其次到底是哪些因素影響的Y變數，很難判斷，需要非常多的資料積累，反覆的調參以及業務人員的經驗，因此通常透過專案來實現。

● What's Next ? 繼續拆分，定位問題，並且聯動業務系統解決問題



基於歸因分析發現了問題根因，然後透過API或者在跳轉業務平臺的直接操作，完成問題發現、歸因到解決的閉環。

例如前面的例子，卡量下降8%，經過分析發現線上申請總量下降了9%，那麼就要定位到線上渠道去解決問題，如果解決不了可以督辦下去，這就涉及到經營分析的一些思路，即透過指標分析和歸因識別到問題以後，督辦問題負責人予以解決，把問題轉給渠道管理來解決。

又比如，筆均交易額突然出現大幅下跌，筆均交易額通常是受交易渠道限額影響，接下來去分析渠道的限額，如果發現確實是交易限額有變化，就可以去修改限額設定，直接在BI裡面完成介面修改。

這就是將來指標管理和BI產品的一個可能的方向，即完成統計、歸因、預測、決策的閉環，在BI中直接解決問題，這樣使資料分析的價值更加顯性化。

● 構建完整的指標庫可以將指標歸因拆解邏輯內化，指導指標分析



指標體系都儲存在指標庫中，可以由專門的指標管理系統來儲存，不過不必糾結於工具，比如我們團隊的指標庫就是基於飛書線上文件實現的，包括業務架構、指標清單、管理要素、指標模型、維度清單等，還包括常用指標展示的駕駛艙和資料應用場景等。例如前面舉例的信用卡餘額指標，拆解為數量和餘額，以及進一步拆分成申請總量和透過率，這些都可以透過父子指標的層級配置實現。

北極星指標的拆解關係都配在指標庫中，業務人員想要分析時，只要在指標庫裡面查一下這個指標的下級指標都有哪些、怎樣使用，還可以疊加不同的維度，就可以完成指標的下鑽和歸因分析。

6. 06 最後



1. 資料專案的最大風險：建完了，沒人用。





所有的產品的最終目標是讓業務人員可以直接使用。然而目前在很多企業，BI的推廣和使用還存在很多問題，比如一些年齡比較大業務人員不會使用或者說抗拒使用，還有些人認為應該由技術人員來做，資料分析的職責不清。

針對這些問題，最關鍵的是組織架構上，需要有相應的資料分析團隊幫業務部門分析，而且資料分析團隊最好內建在業務部門，每個業務團隊有1–2個資料分析崗，這些人員由業務部門考核，逐步的讓業務條線感受到資料的作用，以及資料分析上手不難，這是需要一個過程的。

資料專案的最大風險就是建完了以後沒人用，因為資料專案與業務系統不同，通常是非剛需專案，不是雪中送炭，只是錦上添花，即沒有這一套產品，業務也能生存下去。所以在做資料類專案時，經常是建完以後業務部門覺得學習或遷移成本太高，沒必要用，業務部門還是習慣在原有的邏輯中去完成。甚至有一些業務人員認為數位化對其自身是一種威脅，原來所有的業務經驗和知識，包括客戶都在腦子裡，如透過數位化的手段固化到系統中，那個人的價值在哪？

因此要讓業務人員充分參與，意識到產品能夠減輕工作量而不是增加工作量，需要長期的宣導、培訓、競賽，把企業的資料文化建立起來，這是最核心的工作。

通常的培訓都是產品上線後介紹產品操作方法，做起來非常簡單，但是絕大多數情況下不起作用。現在帆軟有專門的團隊透過一套方法論來引導客戶，而不是單純的講產品功能。整體包括資料人才診斷、培養和評估三個環節：先看整個組織架構有沒有問題，包括人才體系建設、職能崗位職責分佈；然後去做培訓，有線上、線下、集中、分散、點對點、批次等多種方式；之後去做評估，包括FCA和FCP認證。]]> frlily 資訊 Mon, 16 Dec 2024 16:32:21 +0800