做好公司各部門數據報表支撐的幾個簡單思維

越來越多的數據，越來越多的需求，越來越多的不滿意

如今，大數據分析軟體和數據分析的概念相當普及，從基層到管理層，從IT到業務，都深知「數據化管理」、「數據決策」的重要性。越多重視，壓力也就越多，導致信息中心和數據部門往往處於進退兩難的狀態：

數據變多，需求變多，工作價值得不到體現，內部疲於應付。

提供了數據，但需求多樣變更極快，無法滿足各方需求，內部怨言層出。

如何做好面向全公司的數據支撐，哪怕只是簡單的報表提供，其實也是一件複雜且考驗思維邏輯的事。

作為曾經一度經歷過的表哥，本著吐槽加總結加吹牛的原則，匯總下我在梳理並重新規劃公司數據支撐體系時的一些思路，紀念下曾經看指標看瞎的某年5月。

管理思維：數據支撐體系不僅僅是指標體系，還有更開闊的管理邏輯

數據報表的工作只是在整理數據嗎？當然不是，數據的整合和展現最終都是為了經營決策的，報表體系的背後邏輯應反映整個公司的經營結果和經營方法。

做報表的，雖然事務工作多，但還是要抬起頭來，系統思考一下，報表的路該怎麼走？ 阿里提出了「小前台，大中台」的概念，實際道理是相通的。報表中台對於報表人員的綜合素質要求很高，既要有寬廣的業務視野，也要有深厚的數據沉澱，輔以溝通協調能力，造詣甚至遠超一般的業務人員。

一旦想清楚這個問題，你就知道你的數據體系必須要和公司目前的經營狀況和當前工作方向緊密聯繫，所以你的數據工作的方向也就呼之欲出了：

方向一：公司目前是什麼樣的基本狀態？——銷售額、利潤、行業份額，用戶規模……

方向二：公司目前的市場競爭形勢是怎樣的？—— 新增份額、凈增份額，凈收益……

方向三：就目前形勢，公司需要抓住的用戶群來源在哪裡？——各渠道新增用戶價值轉換率、各渠道用戶價值分層、各渠道投入產出比、會員滲透率、存量用戶重複購買率……

方向四：就目前形勢，公司推出的核心產品有哪些？——核心產品銷售達成率、核心要產品渠道滲透率、核心產品重複購買率……

方向五：就目前形勢，公司採用什麼樣的管理方法和工具？—— OKR目標、KPI體系、銷售經理管理指標體系、客戶經理管理指標體系、CRM系統、OA系統、EPR系統……

在梳理過程中，會發現對應到任何一個整體業務的分析，需要提供的已經遠不只是業務結果那麼簡單，還包括各種管理和執行數據。

簡化思維：數據不是越全越好，主次突出，重點聚焦是王道

確定好數據的大方向後，接下來便是細化分析每個數據方向的具體指標體系，以及確定細分的程度。

這個時候，最容易犯的錯誤便是開始把所有用到的、想到的全部羅列並設計進去，建立一個所謂大而全的內容。我始終認為，真正的報表製作是為企業開發的，業務人員只是報表的需求提出者，因此，還需要去理解報表提出的背景，哪些是這張報表的用戶，你需要尊重提出報表需求的人員，但對於報表開發要有自己的想法和主導權。一味強調廣而全，不僅會讓執行者無法聚焦工作重點，而且會讓數據部門自身工作量大增，吃力不討好。

所以，在明確數據需求的大方向基礎上制定詳細的數據體系時，一定要時刻提醒自己，重點是什麼？

一、不同的指標要有重點

比如在產品運營指標體系中，如果已開始投放（電商），需要積累數據，重點關注流量指標，例如UV、PV、渠道來源、用戶線索、瀏覽量、產品瀏覽量排行、頁面跳失率、顧客評價指數、轉化率等等。

而如果運營了一段時間，市場已經成熟，首要的任務是通過數據分析提高銷售額。此階段需要重點監測追蹤流量和銷售指標，例如訪客數、瀏覽量、轉化率，以及新增會員數、會員的流失率、客單價、ROI、動銷率、庫存天數、銷售額等。

若行業份額較小，以拓展為主，那除了新增份額、凈增份額常見指標外，新增搶奪指標方面需往下衍生新增用戶存活率、瀏覽用戶轉換率、新增用戶價值分層等細化體系，保有指標設計則相對簡單。

而如果行業份額已經較大，以保有為主，那新增相關指標則相對可以簡單，而保有指標除用戶保有率、會員活躍率等常見指標外，還需往下衍生合約捆綁率，會員忠誠度、積分計劃活躍度等指標。

數據分析，報表實例，專業的人都在這裡！加入FineReport臉書粉絲團！

二、相同的指標要有側重

同樣以用戶保有指標為例，用戶保有率和用戶流失率其實是同樣作用的指標，一方面是選擇其一即可。另一方面是，選擇哪個，其實放到實際使用中，會有微妙的差別。

如果採用用戶保有率指標，往下衍生是業務層面的合約捆綁率、用戶活躍率、會員滲透率等積極導向指標，注重行銷執行。如果現在用戶流失率，往下衍生是用戶觸店但無消費率、用戶沉默率、用戶直流流失率、流失用戶畫像特徵等，導向為預警關懷。

三、指標的細分，不需要過於龐雜

一般而言，過程三級，執行三級，就已經足夠定位問題及全面展現情況。

邏輯關係：不僅僅是分類，更是反映業務之間的關聯

一、數據選擇邏輯：

為什麼業務部門提出一項數據的要求後，往往會接二連三的提出其他數據需求？其實他們也是在試圖嘗試尋找某個數據背後的原因及可能。

在設計報表體系過程中，不僅僅只是分類，而應該考慮到指標間的關聯，在設計過程中就應該加入業務分析的思維，比如分析者看到這個數據會聯想到其他哪些數據來探究原因？

我在當初利用帆軟報表（FineReport）設計整個報表體系的時候，常用的就是「結果指標——過程指標——執行指標」三層邏輯結構。結果指標由過程指標決定，而過程指標由結果指標決定。

這種邏輯不僅在運營數據上適用，在管理指標上也同樣適用。比如KPI體系是結果，渠道任務目標管理系統是過程，渠道經理/客戶經理監督體系是執行。

二、數據呈現邏輯：

確定好指標內容和指標邏輯後，就是數據呈現了。這方面，之前在如何設計企業內部的數據平台？中就已經總結了，其實就是利用「分析報表—管理報表——基礎類查詢報表」三種層級展示，實現從宏觀到微觀，從上而下定位問題的呈現邏輯。

對於筆者而言，我設計的方式是站在「分析報表—管理報表」維度上，以主題為維度切入，設計全報表。這樣就可以直接從分析報表找到該主題發展的短板，從管理報表上找到導致該短板的主要原因，最後才去分析單報表。

以上是我對於整個報表體系建設的 一點思考感悟，但是實際操作過程中也並沒有這麼理想，仍然需要根據具體情況具體分類具體設計。

電力+大數據項目中的架構研究與思考

閱讀目錄：

1、前言
2、業務架構
3、數據架構
4、技術架構
5、實施架構
6、示範架構
7、小結

前言

智慧電網(Smart Grid)是以物理電網為基礎，將現代先進的感測測量技術、通信技術、信息技術、計算機技術和控制技術與物理電網高度集成而形成的新型電網。

電力大數據(Power Big Data)是實現智慧電網的關鍵技術之一，它通過挖掘數據之間的關係與規律，提高電網企業在生產、經營、管理等方面的質量與效率。如開展電網設備狀態監測的大數據應用，實現電網設備狀態的智慧監測，實時分析電網線損、配電負載等等。

本文旨在跟讀者分享某電網公司在配用電大數據項目中所採用的多維架構(包含數據架構、業務架構、技術架構等)，為本系列的後續文章打下鋪墊。

業務架構

配用電大數據項目的業務架構，是指從業務角度說明配用電大數據項目要做什麼事。此架構不會過多牽涉技術細節，它的重要性要高於其他幾類架構。一般來說，這類架構要在項目啟動前，通過多次的調研、分析、專家研討後方可決定。

上圖的業務架構主要將業務劃分為了五大層次，其中最為關鍵的是數據源層和應用層：

1. 數據源層：規定配用電大數據項目能從哪些地方獲得數據資源。這是非常重要的一環，尤其是在電網領域。因為當前電力信息系統中的「網路孤島」現象比較嚴重，要梳理清楚哪些數據能采、哪些數據采上來有意義，是非常不容易的。

2. 應用層：明確配用電大數據能為電力系統實現哪些業務。規劃該層次時，行業化大數據從業人員需要和電力專業的人員進行多次深入地溝通交流。從筆者親身經歷來看，這一層切不可假大空，一定要確保落地。通俗點來說，若這層寫得太虛，可能會把後續開發人員，甚至是自己給坑了…

至於其他幾個層，則是從一個較為宏觀的角度去設計系統組件。一般來說在業務架構的側重點在系統的功能性方面，對於技術細節不過多糾結。

數據架構

電網企業的數據主要包括三類：

1. 電力設備數據：主要包括電網設備監測數據、設備地理位置數據、設備狀態數據等；

2. 企業管理數據：主要包括跨單位、跨部門的電網企業職工數據、財務數據等；

3. 企業運營數據：主要包括客戶信息、客戶用電數據、電費數據等。

但是上述只是一個特粗略的分類。筆者在項目實施過程中發現，數據的分類在每一個環節都需要按照不同標準重新做一次。

為何要這麼麻煩？這是因為，[數據類型]+[業務需求]將決定你選用何種大數據分析軟體組件去處理它。

這裡先以電網的拓撲結構數據為例：這類數據大都存在電力系統的RDBMS里，那麼我們顯然可以考慮使用Sqoop來做同步；而其後為高效實現電網拓撲分析業務，顯然應將其放至HIVE這類數據倉庫工具里合適。

再以電網設備檢測數據為例：這類數據由於具有事實性，用Storm或者Spark Streaming來同步就顯然更加合適了；而這類數據有部分業務環境是不需要做太多數據分析的，因此可考慮將其導入到HBase這類NoSql數據里，實現高效存取。

讀者看到這裡，應該明白了需要時刻思考數據分類的原因了吧？上述兩個例子都屬於電力設備數據，然而它們被處理的方式顯然是不同的。在實際中，我們往往根據當前架構所在層次的屬性來決定使用何種組件來處理數據。個人真心建議針對將來數據特別複雜的情況，可以考慮引入「數據畫像」這個概念，根據不同的處理方式為各類數據打上標籤，以便於管理。

技術架構

總的來說，針對配用電大數據的技術研究可以分為三個層面來展開：

1. 數據集成層面：研究電力系統中多源數據的分類方式、集成與融合方法，並設計出面向雲環境的多源異構數據集成模型。

2. 基礎架構層面：結合線上流處理與離線批處理的應用需求，研究可拓撲分解的流處理計算技術、分布式並行批處理計算技術，並提供應用編程介面。

3. 支援系統層面：研究電力大數據項目的建設規範，大數據集群系統的綜合管理工具、大數據可視化組件，並提供多種形式的集成介面，以便支援不同上層應用對大數據以及分析結構的調用需求。

需要特別說明的是，在這三個層面之上是真正的「電力應用層」。

數據分析，報表實例，專業的人都在這裡！加入FineReport臉書粉絲團！

實施架構

對於配用電大數據項目的具體實施，需要明確的主要是將計算機集群具體分成哪些區，每個區又具體採用哪些組件。

這部分內容比較繁雜，以下僅針對其中某類實時數據的處理做個大致的介紹：

1. 各業務系統和數據採集系統的秒級數據通過專線網路，經過加密壓縮傳輸到總部的負載均衡器；
2.負載均衡器將數據分發給Kafka集群落地；
3.Storm集群從Kalfa集群接收所訂閱的數據，負責對數據進行清洗、按照設定的告警條件實時監測數據並發出告警；
4.Storm清洗和標註後的數據，直接存入HDFS落地；
5.HDFS中的數據同步到數據存儲和查詢模塊（時序數據管理平台），方便在其中進行線上查詢；
6.數據分析平台上根據預訂的作業隊列，調度數據分析程序在Hadoop集群中運行，結果存入HDFS或者按用戶程序定義寫入相應存儲位置；
7.數據分析平台將秒級數據匯總成十分鐘級數據、根據定義的數據種類、數據格式和存儲方式將數據分發給計算存儲群組及HBase資料庫；統計報表程序通過Hive集群執行各種類SQL完成統計查詢和報表製作生成。

（上述介紹僅是針對其中某類實時數據的處理，而不同類型數據的處理方式是不同的）

示範架構

在項目後期，需要將配用電大數據平台部署到部分地市局來進行試點，因而需要明確網 – 省兩地，或者網 – 省 – 市三地的綜合示範架構。

在本文給出的參考架構中，我們首先利用高速4G專網和GPRS /230M無線專網實現低壓居民用戶和專變/公變終端的採集；採集的數據通過智慧一體化終端進行簡單轉換後，上傳至區域分布式大數據中心；區域大數據中心將對電量和非電量數據，結構化與非結構化數據進行大數據集成與融合。

在區域大數據中心，可基於大數據聚類與分析技術，實現用電用戶類型的精細化劃分、分析用戶的用電行為、評估非介入式用戶的能效水平，形成一系列面向配用電網的通用知識模型與關鍵技術，為省級大數據中心提供數據與關鍵演算法支撐。

小結

作為該系列博文的開篇，本文從各類架構的角度出發讓讀者對配用電大數據的項目有了全方位的整體認識。

後續的文章將涉及到真正的電力+大數據研究，這也是電力專業與計算機專業的綜合領域，讀者或許需要具備一定的電力系統知識才能消化。

簡單回顧下電力系統相關的知識，然後一起開始智慧電網之旅吧^_^。

作者 | 穆晨
原文 | 配用電大數據項目中的架構研究與思考

如何用精細化數據管理打造競爭優勢？——實例分析

永輝超市是中國大陸首批將生鮮農產品引進現代超市的流通企業之一，被國家七部委譽為中國「農改超」推廣的典範，被百姓譽為「民生超市、百姓永輝」。生鮮經營是其最大的特色，各門店的生鮮經營面積都達到40%以上；在集團總銷售額中，生鮮農副產品的銷售額佔到總銷售額50%以上。2016年，以數據分析技術為依託，通過賽馬制和供應鏈資源整合，集團毛利率已高達20.19%，在中國連鎖百強企業中，暫居第10位，並以高於10%增長率向更強邁進。

如何實現精細化管理

永輝超市大數據團隊的吳江淮介紹，永輝超市主營零售、服務亮大行業，主營生鮮&加工、食品用品和服裝等產品，旗下有大賣場、賣場、社區店、BRAVO精緻超市等主要業態，全國合計300多加門店，170多萬會員。其中生鮮&加工營業收入增長了約19%，食品用品增長了月20%。這兩塊是永輝重點做精細化管理的產品線。除了針對產品線做精細化管理，對不同業態的門店也做重點管理。從效果來看，大賣場和社區店效果顯著，分別增長2.5%和1.2%。

零售行業裡面的增長空間靠規模取勝是沒有希望了，用投資擴大資本取得社會增長的這個時代也已經過去了。企業增長方式要從圈地逐漸轉化為精細化運營。企業運營效率也是決定企業核心競爭力的關鍵指標。做精細化運營，首選的技術是AI。永輝在上海成立了專門的大數據公司，為超市做數據支撐、雲計算支撐。永輝就是要走零售轉數據科技的發展方向方向，依託大數據分析軟體公司的數據處理能力和數據分析能力，來支撐自身精細化運營。同時，廣泛和社會上的像帆軟這類的專註於產品的大數據、數據分析公司合作。永輝的專長是零售業務運營，走科技創新、數據科技之路，依然是重點深耕業務，依託多年業務積累經驗，轉型做商業智慧零售解決方案提供商。

數據分析，報表實例，專業的人都在這裡！加入FineReport臉書粉絲團！

生鮮精細化管理

為提升數據的及時性，準確性，便利性及實用性。2016年上線了永輝生意人、永輝到家、永輝管家等APP，幫助各部門提升的工作效率，優化了工作流程。這其中，重要的一塊便是帆軟數據分析的集成與應用。永輝將生鮮毛利分析模塊集成到現有業務APP中，讓業務部門直接隨手可查經營數據，及時提供經營異常預警。如下圖的生鮮毛利率日分析，店長通過手機APP，可是實時看到當前門店（下圖中的門店一）的毛利率情況，包括月累計銷售同比、月累計毛利同比、區域毛利率、本店毛利率、毛利率排名。還有毛利率排行榜。那這個怎麼用起來呢？根據自身店面的毛利和區域的毛利率以及其他毛利率對比，一旦數據異常，系統自動彈出消息提示經理。門店經理根據分析頁面提供的數據，初步判定毛利是否在可接受範圍。然後根據查看排名靠前的門店的經銷實時情況對比分析，看是自己的有效SKU不足導致的，還是斷銷導致的，或者是客流不足導致的等等，系統會自動對比這些維度的數據，幫助門店經理分析自己店面的不足，及時改正。

門店賽馬精細化管理

數據驅動運營，不管是數據分析還是信息系統，都是輔助業務經營和管理。真正改變業務的，還是要靠一線業務人員的執行。如何在強化管理的同時又調動業務部門的積極性和創造性呢？我們採用KPI體系和賽馬體系兩者結合運營管理。KPI體系就是「大棒」，就是上級給下級定任務，施加壓力，完不成就扣績效獎金。賽馬體系是「胡蘿蔔」，就是同級之前相互競爭，完成的好有獎勵，除了物質獎金獎勵，還有榮譽獎勵。另外，大家都是勤勤懇懇的員工，多年共事，相互之間還是想比一比的，自己落後了肯定面子掛不住。所以，賽馬體系激發業務部門的活力和創造力。

如下圖的賽馬成績單，賽馬成績單的核心就是不同門店、課組的業績獨立核算。永輝在這裡形成了一套完整體系，相對公平的模型來自動評分，每月公布一次。同時，門店看門店相互競爭，門店還看自己的課組，要對下級監督；課組看課組相互競爭，課組還看門店，對上級監督。為什麼既能相互競爭，又能相互監督呢？哪裡來的動力和權力呢？因為永輝做了績效考評，有個人績效獎懲和團隊績效獎懲，這樣大家就團結成一股繩。

供應鏈精細化管理

2016年，永輝超市從品牌商合作轉向工業化採購、向市場化貿易商機制轉變，全面提升採購服務和效率。規模化採購與區域靈活性兼顧，優化商品結構，聚焦核心商品。食品用品集中化採購佔比提升0.8個百分點，梳理淘汰近2萬 SKU，淘汰了15%供應商；服裝淘汰近25%的供應商。

永輝超市的物流預警管理，主要依託的是微信公眾號，將帆軟報表集成到微信裡面。之前永輝用的是SAP的報表製作，想要個性化定製，功能不十分滿足，技術難度很大，而且這個費用確實不太合適。現在這個微信集成方案，永輝申請好企業號，然後要求需要推送消息的用戶關注永輝企業號。帆軟和微信後台可以對接集成，實現人員許可權、數據許可權的匹配。

我們看物流庫存預警報表，預警缺貨。這個物流庫存預警永輝針對不同崗位受眾，有不同的版本。我們看下圖，對東北大區不同課組的商品做缺貨預警，其中預警信息是通過微信自動實時發到課組長手上。預警消息含詳細的商品描述、含稅進價、總庫存天數、物流信息和門店的庫存詳情。可以看到，不同課組的缺貨狀態時，門店庫存天數並不相同。這實際上是由我們一線的業務人員綜合物流運輸管理、庫存管理等綜合設定的，是每個門店在總部提供的建議值的基礎上，做了量體裁衣的精細化調整。如此根據業務需求自動調整定製，這才是永輝物流庫存預警靈活高效的秘訣之一。

精細化管理成效

永輝數據中心APP，是公司高層大行數據驅動決策的成果，是永輝紮實做數據分析的良好實踐。從一年多的統計數據來看，數據中心APP用戶活躍率正在逐步上升，這正說明數據中心APP真正在業務中得到了認可，並在被廣泛推廣。尤其是，永輝數據中心APP曾創下當日線上人數6300+人，日查詢次數10w+次的記錄。正是這樣的廣泛關注和認可，讓永輝的數據創新工作蒸蒸日上。

千言萬語，不如我們店長一段實時在在的感慨。他郵件給數據中心部門寫到：

文 | 帆軟數據應用研究院 船長

企業如何以客戶為中心進行數據化運營？-看這個實例

當下互聯網的餘震未醒，「新零售」又提出。成本上升、人口紅利消失、電商滲透率飽和都在倒逼零售的整體升級。

不管業內業外，政府公司，都在談轉型。但關鍵如何轉型，基點在哪？這都需要探索。

有人說，消費變革的起點一定是在里消費者最近的地方，其中最關鍵的一環，就是要提升自身的數據能力，真正實現以用戶體驗為中心的經營模式。

就在上月，步步高集團電商事業部產品技術總監王衛東在帆軟零售大會上發表了一場「頗具格局」的演講。從數字化創新驅動業務發展、「人貨場」的數據分析、再談到實際的數據化管理案例。

全程乾貨滿滿，總計4700餘字，建議閱讀時間10分鐘。

步步高商業連鎖股份有限公司（下文簡稱步步高），是涉及零售業、電子商務、商業地產、互聯網金融、大型物流等多業態的大型商業集團。目前擁有步步高超市、步步高百貨(廣場)、步步高雲猴網、步步高置業(步步高新天地)、步步高電器城、太楚餐飲、匯米巴便利店等業態。2016年銷售收入超過320億元人民幣，位列中國民營企業500強第158位。

一、數字化創新驅動業務變革

2017年是步步高數字化轉型的一年，總體數字化創新戰略方針是線上節約顧客時間，線下「浪費」顧客時間，創造更好的購物體驗。步步高擁有百貨和超市兩大事業群，兩個事業群的客戶群體是不同的。步步高超市業務以快捷為主，百貨業務以客戶體驗為主。如何通過數字技術來提高客戶滿意度呢？總體是增強智慧體驗、優化線上渠道、客戶畫像精準行銷三個路徑來實現技術驅動業務創新。

客戶獲取與經營的閉環

運營的關鍵是兩條線：獲客和經營。我們的數字運營體系，圍繞著用戶的運營這個重心，以顧客為中心，融合數字技術形成客戶獲取與客戶經營閉環。抓好這兩條線，讓客戶群不斷壯大，提高客戶成長轉化率，以此來保證毛利的提高。零售行業是個薄利行業，提高企業毛利，就是要在這個閉環裡面多下功夫。具體怎麼下功夫呢？可以針對性活動設計（目的）、分析人群相關性（精準）、交易簡便個性化、提供更多價值（權益/服務）、了解顧客喜好（消費偏好）、贏得顧客信任和主動傳播。

客流數據分析建模

傳統零售的數據是基於交易客流，基本等同於俗稱的會員。商超裡面的客流其實分為交易客流、飯店客流、進店客流、到達客流、潛在客流。這裡最容易獲取的就是交易客流，因為企業現有的CRM系統或者收銀系統基本都能涵蓋這部分客流。而現行的基於CRM客流管理和收銀系統客流管理模式有兩個管理上的缺陷。一是普遍重視客戶的消費能力，而忽視傳播與分享能力，也無法量化客戶的傳播與分享能力；二是高度重視新用戶的數量積累，而忽視後期的長期服務和維護，靠利益刺激，吸引促銷客戶而非忠誠客戶。我們應該有新的認知：到店即是會員，得顧客數據者得天下。怎麼得顧客數據？這就要建立一整套的全顧客全消費行為管理的客流分析系統。

身份識別

顧客到店，不同級別的會員消費不同，給企業帶來的效益也有較大差別。如何提前區分會員等級？而不是在收銀的時候強制出示會員卡來事後統計會員。首先，是對不同渠道、方式獲取的顧客機那裡統一的ID和ID映射圖譜方案，能夠在具體的場景中識別顧客。比如步步高用WIFI探針、手機號、微信號、支付寶ID、人臉識別等等。只要有了顧客ID，那麼客戶就成為了廣義的會員，把這些有身份信息的會員管理起來，在不同的場景中預判用戶行為，在顧客離店之前便進行適當的會員關懷和消費引導。

客流分析系統

客流分析系統的升級，戰略目標就是要獲取全顧客全消費行為數據。傳統的客流分析系統，主要是人工統計、紅外感應、視頻檢測，採集到的主要就是進店客流、POS等銷售數據，能做的工作優先，主要是就是強化管理，努力提高顧客轉化率。然而，一方面是競爭加劇，另一方面是經營成本增加，這些都要求步步高必須要做變革，以保持較強的競爭力。升級的客流分析系統，重點是對到達客流、車流數據、顧客運動軌跡、WIFI探針等做挖掘建設。通過識別和數據採集技術以及數據分析技術，步步高得以豐富會員畫像做精準的會員成長關懷和管理，提高客單附加值，提高會員活躍度，甚至從周邊商圈吸引到潛在客流並最終轉化為忠誠會員。

數據分析，報表實例，專業的人都在這裡！加入FineReport臉書粉絲團！

二、數據分析綱要

數據分析的核心三要點

我們鋪設整體的信息化，是有明確的綱要的。這個綱要就像是做項目的章程，是我們的指導文件。數據分析的核心三要素是什麼，是數據一致、實用當先、以人為先。保持數據的一致性，是要解決數據分散在各個系統，不同部分重複開發報表，不同報表製作計算口徑不一的問題。步步高通過建立統一的數據倉庫，集中解決數據不一致的問題，並保持嚴格的定期維護。杜絕華而不實，實用當先，不做表面文章，重在先能用，再好用。步步高數據分析項目一期，明確暫緩大屏項目，優先從查詢報表、監控報表、數據分析報表三步逐次實現。這就是堅持先能用再好用。以人為先，工具次之。帆軟工具確實數據分析領域的成熟的平台，但工具再好用，做再多的分析，業務人員不會用，也是捨本逐末，功虧一簣。步步高通過成立專業的大數據學院，在企業內部培養大數據分析軟體專業人才，精通業務，熟練掌握數據分析工具，然後由他們結合企業特點，向集團各單位推廣數據分析平台。

人貨場財指標梳理

傳統零售運營，分四個維度：人、貨、場、財。雖然大體維度相似，但具體到指標，還是各有不同。我們針對自身，做了專門的維度和指標的梳理。

人員，主要分為員工和顧客，前者是對內管理，後者是管理客戶運營。如何用這些數據，如果做對內管理，我們要規劃好目標，規劃好對內管理的定位。要想對內管理好用到位，必須基於每一個商業智慧單位設置各自的KPI考核。千萬不要給自己挖坑，做個高大上的分析或者報表。不用高大上，只需要幾個關鍵指標值。作為業務人員，他更多關注的是老闆對他設定的考核指標，如何改善公司層面的業績。業務人員關注的，是KPI。顧客分析，重點考核3個指標：客單價、毛利率、會員數。客單價的變化，毛利率的變化，會員的整理流失、有效、貢獻、年齡層次變化直接在日報中體現，每天都要抓。

貨。我們從採購環節、供應鏈環節、銷售環節、售後環節進行指標管理和控制，穿透整個經營環節。我們只把關鍵指標篩選出來，作為監控項和管理項。具體的監控和管理指標，可以看上圖。

場。我們在場這個維度上重點管理績效。包括銷售指標、競爭情況指標、促銷指標、渠道指標。每次促銷活動，不僅會監測會員和銷量指標，還會重點監測場指標，貨源是零售長期穩定經營的基石。

財。財務重點關注的一點就是毛利和回款。步步高的百貨，重點還關註銷售利潤率。

三、數據分析案例

我們的數據分析項目2017年還在重點就建設中。很多的數據分析的實踐剛有起色，並未得到長期的經營驗證。所以部分經驗和案例效果圖還不便公開，我們也本著開放的心態，歡迎更多同行能前來交流。這裡就部分內容做個分享。

巡店預警

我們的會員管理部分只關注門店會員數據，其他周邊數據業務部門並不想要。所以不需要定製太多的報表，也不需要提供太多的維度和指標數據。曾經，兩個月的時間完成的初版巡店預警控制報表，一線人員反饋說沒用。他們只關注商品調撥，需要實時查詢相關數據。這個預警報表能不能告訴業務人員當前門店哪個品類、哪個商品有問題，告訴業務人員這些，就是他們最需要的。我們對初版報表稍作改動，出來了下圖的最終版。現在一線業務人員，可以通過一張報表直接告訴他們那些商品有異常，哪些銷量有異常，哪些會員有異常。旗下的梅西新天地有1萬多款SKU，這一張報表就可以完成監測和分析。當然，針對會員也提供了關鍵指標畫像，只提供業務人員最為關注的幾個指標。

對標比價

我們引入京東、天貓、一號店以及其他同行的一些外部數據，監測零售同行商品的價格走勢和當前活動。根據外部數據，步步高一整套數據分析報表會自動給門店經理手機提示異常，會直接告訴他哪些價格有異常，同行的當前價格和歷史價格多少，以及預測近期價格走勢，並給店長提供建議價格做參考。

除了銷售對標比價，另一個就是採購。如果發現採購價格高於隔壁同行，商超裡面採購經理會說別人家在做促銷活動，或者有其他原因。但是顧客偏偏就是漸漸到隔壁家消費去了。現在專門開發了對標比價系統，店長拿著手機，對著商品QR code一掃，就能立馬顯示天貓、京東、一號店甚至是一些隔壁同行的價格。步步高在每個超市門店，都實現了對標比價的應用對接。

異常監測分析

目前我們已經建立了銷售、毛利、庫存、會員和積分的五大異常模塊。原來傳統的方式監測是依靠專家經驗（甚至很多企業現在也是這麼做的）。那麼我們分析一下，對於出差，第一周1次，第二周2次，第三周2次，第四周0次，第五周4次，第五周是否異常？如果專家判斷3次以上算異常，那就是異常，如果專家判斷4次以上是異常，那就4次剛好達標，不算異常。這裡面就有人為制定固定標準的局限。同理，我們看訂單數變化，連續多日統計後，某一天訂單量為85，這是否異常？同樣類似的會員消費，消費頻率達到多少算是活躍會員？業務專家給的指標建議，都是固定的，很難自動調節。我們也很難針對每個SKU、每個訂單都單獨去做人工測試。那怎麼辦？步步高採用的是建立分析模型，系統自動算一個標準差為基礎的UCL、LCL和CL。因為這個是固定一個標準差，所以分析模型是專業的。而整個三個指標的計算，是系統動態的根據近期數據或者整個歷史數據自動計算的，所以這三個指標也是隨著業務發展自動變化的。這樣就節約了指標維護的工作量。再對訂單數通過該模型分析，模型給出UCL=81，那麼顯然訂單數85屬於銷售異常。異常檢測分析，其實核心就是建立動態的異常指標。

到店客流監測

到店顧客，其實是需要我們重點經營轉化的。那麼要思考幾個問題：這些客戶從哪裡來，客戶量有沒有變化，這些客戶要消費什麼，這些客戶哪些是常客，這些客戶都對哪些店面感興趣等等。能用數據回答清楚這幾個問題，就方便進行顧客的數據運營和管理了。

首先，如何回答這些客戶數量的變化。因為一天接待的顧客眾多，很難用人員觀察統計，即使採用定時定點安排人統計人數，也是不科學抽樣，可信度不高。步步高升級了客流分析系統，得以通過停車場數據系統、WIFI探針數據、人臉識別等技術自動識別客流變化，然後，定製出客流量檢測看板。步步高主要關注近一小時累計客流量、近一小時新增客流量、今日累計客流量、今日平均停留時間這四個主要指標。當然，還針對歷史數據做對比分析，會對比昨日數據，看指標變化數值和變化幅度。這些指標變化也是納入異常檢測分析範圍的，只要超出動態的CCL和UCL，系統自動給店長預警，提示相關人員採取措施，並關聯KPI績效。督促一線人員及時有效的解決問題。

那麼客流總數異常，從哪些維度查找原因呢？或者客流總數正常，客流質量是否也正常呢？步步高重點關注兩個對比類指標。一個是新老客戶佔比，一個是今日客戶到店分布對比。客流數異常，首先要看的就是新老客戶佔比和數量的變化，新客戶減少可能是宣傳或者促銷的問題了；老客戶減少，多半是會員政策或者商品經營出了問題。這樣，步步高就幫助業務人員快速分析業務問題，及時幫助解決業務問題。當然，及時客流總數正常，也要關注新老客戶佔比變化。比如開展促銷活動，新客戶佔比增加顯然是促銷的一個關鍵指標。

到店客戶，他們來了，我們想知道他們都停留在哪裡，去了哪裡，好做針對性的店面布局和行銷管理。步步高採用電子圍欄技術、WIFI探針、人臉識別等技術，實時採集人流分布數據和運動軌跡。那做這個是什麼目的呢？其實說白了就是為了百貨經營時增加客戶的整體駐留時間，提高消費的可能性。步步高在梅西新天地做了客流實時分布分析和客流軌跡分析。通過這些分析，步步高可以判斷客流都是從哪些區域過來的，甚至是從哪個周邊小區過來的。然後從不同區域進店的客戶，消費目的有和不同，消費習慣有何不同，是否有更多的消費需求可以挖掘。負責管理的樓層長經理要思考：為什麼一些區域熱度很高，另一些區域熱度卻很低，為什麼有些熱度高的區域最終毛利卻不高，現在的店面布局是不是有更合理的方案。

通過對客流的監測和分析，步步高將一些經營決策所需要的數據和信息下放到基層管理崗，讓熟悉業務個店長樓層長來提出決策建議，供高層選擇，用數據來支撐決策，用可視化分析提高決策效率和科學性。

文 | 帆軟數據應用研究院 船長

企業數據分析部門組織架構形式探討

數據時代的到來使企業越來越意識到數據的價值,企業紛紛建立自己的數據分析團隊.花重金招攬的數據人才怎麼融入到本企業組織中才能發揮他們的才能呢？本文試圖分析數據分析部門組織架構形式的優劣及影響。

從數據分析部門與傳統IT部門的關係來看,分析部門有兩種形式：設立獨立的分析部門或設在IT部門下，由一個CIO管轄。

從數據分析人員是否集中來看也分兩種情況：數據分析人員集中在大數據分析軟體中心或者數據分析人員分散在各個業務部門。或者混合情況：兩者都有數據分析人員，但職能分工不同。

下面具體分析三種典型組合情況：

第一種形式為傳統式，

如下圖：大數據中心設立在IT部門下，數據分析師集中在大數據中心。

這是一種大信息中心的形式。這種形式的特點是大數據中心與IT合并在一起，貼近數據源，業務部門向大數據中心提需求，大數據中心根據需求統一排期開發、分析。這時一般傳統的報表、臨時需求分析等也可能會與業務系統分開，由大數據中心管理。大數據中心對接各業務系統數據源在部門內部即可解決。各業務部門只需要跟大信息中心一次提需求即可。業務部門沒有自己的分析挖掘團隊，但一般會有傳統的報告分析。

這種形式大多由傳統BI系統部門演變而來。傳統的經營分析中心或商業智慧部演變為大數據中心，在數據倉庫基礎上增建大數據平台，增加大數據及數據挖掘人才，在原來的報表製作的基礎上建設更深入的數據分析應用。

優點：數據中心與IT在一個部門，離數據近，數據整合便利，保障數據質量高。集中的需求管理也使內部溝通有效，避免重複開發，也可以使分析師內部總結提高。

缺點：離業務較遠，尤其是分析團隊與業務部門的工作地點不同時，容易與業務部門溝通不暢，閉門造車。如果業務變化快，無法跟上業務的步伐，對數據的思考不夠深入，與業務部門溝通成本加大。

針對分析師集中後離業務較遠的弊端有一種方法為：分析師仍然集中在大數據中心，但分析資源的使用、請求在各個業務部門，企業各業務部門自己根據項目需求請求所需的分析師。這種情況下分析師需要同時向本部門和業務部門彙報工作。

數據分析，報表實例，專業的人都在這裡！加入FineReport臉書粉絲團！

第二種形式為集中式。

這種形式與第一種的主要區別在於大數據中心是否獨立。

這種形式的特點是公司所有與數據相關的平台建設、數據應用、數據分析挖掘都歸屬到一個部門，此部門是數據管理的唯一出口，業務部門不設立自己的分析團隊，IT部門也不負責相應平台開發維護。

優點：部門職責明確單一。指標由一個部門計算，口徑統一，且與業務部門獨立，所以立場獨立，分析結果更中立。

缺點：同時具有第一種形式的缺點，並且離業務部門及業務系統都較遠，無論是數據理解還是業務理解都可能不夠深入，同時如果大數據平台開發維護能力不強，會有技術困難難以推進。

第三種形式為混合式

此圖與之前的主要區別在於業務部門是否有分析師。這裡不再分析大數據中心是否獨立的問題。主要分析大數據中心下分析師與業務部門分析師的職能及定位。

大數據中心分析團隊職責主要集中在整個企業級的數據產品、數據應用、數據分析。服務的對象也主要是公司級的部門和領導。他們技術能力和業務能力更強，能利用最新技術解決業務問題，同時必要時對業務部門分析團隊給予指導。

而各業務部門自己的分析團隊主要服務於自己部門內部，技術能力不等，以前主要根據報表做統計或分析報告，但他們本身在業務部門對業務理解深入，主要是利用數據解決業務問題。有些強勢部門可直連倉庫自己寫SQL提數，定製開發簡易報表，技術強的業務部門甚至要求建設自己的數據集市，搭建自己的挖掘團隊。

這種形式下的主要缺點是兩者職責有時劃分不清，造成部門利益為重、爭搶項目、職責推諉、重複開發、口徑不一致等問題。各業務部門的分析團隊之間交流不暢，技能提升有限。有一種變通的方法為打破各部門利益障礙，建立橫向的虛擬分析團隊，加強虛擬團隊內部溝通交流，甚至團隊內部成員作為共享資源可根據項目周期流動。

通過以上分析可以發現為發揮分析優勢，是在集中分析部門便於內部交流與靠近業務便於理解業務的矛盾的平衡。

每個形式都有各自的優點與缺點，沒有對錯之分。沒有最好的只有最合適的，每個企業都要根據自己的實際情況進行調整。

文 | 岳瑞
文章源自：數據陽光

從DAMA出發，一個指標庫到底是如何煉成的？

 在數據管理領域，我們通常將數據分為：主數據、交易數據、參考數據、元數據和統計數據分析（指標）， 指標是BI系統裡面核心的概念，是一個企業數據運營關注的核心數據，一般以KPI和報表的形式體現。

從實踐來看，一個企業要進行數據治理，涉及了架構、安全等諸多層面，但最迫切的是提升數據質量，其中指標質量則是重中之重，一般業務上90%以上關於數據的疑問都從指標的質疑開始，只要你從事數據相關工作，就應該深有體會。

「這個指標好像跟業務發展實際不符，快去查查」，估計這是報表取數人員聽到的最多的一句話了。

下文就來談談如何從根本上去提升指標的數據質量，即實現指標的標準化，作為一個數據管理人員，不管你有多少能力，曾經解決了多少問題，當過多少回救火英雄，都應該從更為長遠的角度來思考這個問題。

指標標準化的核心價值在於實現「書同文，車同軌」，即通過針對指標的一系列管理過程，去提升指標準確性、一致性、敏捷性及開放性。

DAMA將數據治理放到核心地位，指標的標準化就是個典型的數據治理問題，治標是容易的，治本的代價則太高，但如果要實現進階，還是要站的高一點，多思考一下，想想是否有更好的方法，就從筆者多年前做過的指標標準化項目開始吧，分為組織保障、報表梳理、指標整合、實現方式、功能架構、可視化引擎及管理流程等七個方面。

1、組織保障

指標庫這類數據管理項目，或稱BI項目，一般業務部門參與的力度是不大的，這是大多BI項目實施效果不佳的一個深層次原因。

DAMA提到要實施數據治理活動，跨部門的數據治理委員會等是關鍵的組織，的確是這樣，指標跟全公司每個單位都相關，對於其進行規範化改造當然應該獲得大家的一致同意。

可惜的是，大多企業沒有這個理想條件，也不會有數據治理委員會，在數據還未成為真正的實質性資產前，比如納入財務部的資產目錄，很少有企業會設立這個數據組織，因為效益不明顯，因此，哪個企業都不大可能為指標出一個規範並且通令全公司貫徹執行，對於數據管理人員，指標庫這個事情也許意義不小，但對於全公司意義則小了，這是現狀。

在沒有公司層面的組織保障前，數據管理人員或BI部門大多得靠自己，通過自己來推動事情往前走， 這是應有的態度，你不提，公司也沒有任何人會提，畢竟你是最大受益者，實施指標庫這個事情非常複雜，誰都沒有成功的把握，秉持小步快跑，試點探索的原則是不錯的。

筆者的這個指標庫項目獲得了分管領導的強力支持，這是項目能進行的現實組織保障，其實這類管理項目設立之初，很難讓業務部門和一線人員馬上認識到其價值並充分參與進來，這個溝通管理成本太高了，但無論如何，一個數據治理項目能否成功，公司的支持是第一要務，不僅僅是IT部門的事情，DAMA的很早就在《DAMA數據管理知識體系指南》明確了數據治理的組織要點，以下是DAMA的數據治理組織架構圖，非常超前：

當然我覺得現實的組織演進也許如下圖更合適，但道理是一樣的，相關利益方需要對這個事情達成共識：

2、報表梳理

指標的主要表現形式是報表，因此第一要務就是報表梳理，公司的報表浩如煙海，因此這個項目設立之初就限制了範圍，主要針對一線市場部經理、終端管理、流量管理三類核心角色，共梳理了相關的39個彩信、48份郵件通報及數據集市上的733張報表。（筆者所在公司為某運營商）

數據分析，報表實例，專業的人都在這裡！加入FineReport臉書粉絲團！

3、指標整合

各類報表及相關指標表達各不相同，梳理前應該給出一個描述指標的標準框架，包括指標大類、子類、維度、周期、歸屬、命名規範等等，曾經由於框架漏了一些要素導致返工現象，這個頂層設計一定要做好，以下是示例：

命名規範：業務限定詞+業務名稱+量值限定詞+量值描述（量、收、用）

舉例1：兩網有效用戶到達數

舉例2：自建有線寬頻出賬用戶數

下圖列出了大致的梳理步驟，主要以省公司報表和彩信KPI為基礎確定基準指標，各地市指標剔除個性指標後，合并到省公司的基準指標中，形成本次的最終指標範圍。

全省指標共計6841個（未剔重），經過歸併整合，得到基礎共性指標2306個，如下圖所示：

此項工作耗時巨大，以下是成果的示意：

4、實現方式

根據指標性質不同可以分為3類，即基礎指標1046個、計算指標652個和通用行銷類指標303個。

5、功能架構

為了支撐指標快速，標準化實現，通過增強數據管理平台來實現指標的快速開發、部署和管理，主要包括指標信息維護、指標開發、運維管理、指標質量管理等功能。

比如指標庫每月需要新增超過9. 5億行的數據，存儲周期按12+1，即123億行，以傳統關係型資料庫的查詢能力無法支撐，這裡就採用Hbase架構支撐海量指標的快速查詢。

6、可視化引擎

為了支撐指標組裝報表與配置報表的快速開發，使用數據可視化引擎產品，主要包括指標組裝、報表開發、報表展現功能，現在的這類產品很多了，但定製化給予一個創新性項目更大的自由度。

指標組裝報表製作工具是區別傳統基於SQL配置報表的靈活度更高的報表配置方式，主要提供基於指標選擇組裝生成報表。

7、管理流程

指標的建設只是走完了數據治理的第一步，為了確保指標庫長期可用，必須要有一套針對的指標管理機制和流程，否則建設的結束就是混亂的開始，理想的做法當然是發布一套公司級別的指標管理規範，但這個時候時機往往並不成熟，比如系統可用性到底如何，因此，我們當時就確立了一個簡單原則，一條開發鐵律：不重複開發，能用指標實現的不允許單獨開發報表，當然這非常考驗數據管理的藝術，極大依賴於團隊的業務和數據能力，但有主見的數據管理團隊一定要懂得如何與業務人員進行博弈，記得你才是全公司數據的管理者，而不僅僅是個開發者。

筆者在關於指標庫的實現簡要談完了，但我對於大多企業搞指標庫卻是持悲觀態度的，傳統BI部門面對浩海的數據需求時，往往是沒有管理原則的，因為公司對你的數據管理授權是不明確的，我們不得不以犧牲長遠來滿足當前，其實BI每接收一個不規範（比如胡亂的指標命名和定義）的報表需求就要承擔由此帶來的管理成本，而不僅僅是開發成本，這為後續數據管理的混亂埋下了禍根。

但存在的又是合理的，因為搞個指標庫在開始的時候，無論是管理及運維成本都不低，關鍵是短期來看效益還不明顯，這也許是成功案例不多的一個原因。

因此，當我們在抱怨業務指標口徑一塌糊塗的時候，要記得是企業沒有數據管理的原則導致了這個現象，也是你的不作為導致了這個現象，這跟公司的文化、機制及流程是息息相關的，頂層設計沒解決，也許只能將就了，或者，你就要付出百倍的努力去改變或優化這個設計吧，這需要巨大的決心和毅力。

DAMA談數據治理首當其衝談組織設置，顯然是非常睿智的，奇怪的是在知乎上關於DAMA數據治理的討論幾乎沒有，這倒是值得思考的問題。

文 | 傅一平
原文自：微信公眾號 與數據同行