數據時代的到來使企業越來越意識到數據的價值,企業紛紛建立自己的數據分析團隊.花重金招攬的數據人才怎麼融入到本企業組織中才能發揮他們的才能呢？本文試圖分析數據分析部門組織架構形式的優劣及影響。 從數據分析部門與傳統IT部門的關係來看,分析部門有兩種形式：設立獨立的分析部門或設在IT部門下，由一個CIO管轄。 從數據分析人員是否集中來看也分兩種情況：數據分析人員集中在大數據分析軟體中心或者數據分析人員分散在各個業務部門。或者混合情況：兩者都有數據分析人員，但職能分工不同。 下面具體分析三種典型組合情況： 第一種形式為傳統式， 如下圖：大數據中心設立在IT部門下，數據分析師集中在大數據中心。 這是一種大信息中心的形式。這種形式的特點是大數據中心與IT合并在一起，貼近數據源，業務部門向大數據中心提需求，大數據中心根據需求統一排期開發、分析。這時一般傳統的報表、臨時需求分析等也可能會與業務系統分開，由大數據中心管理。大數據中心對接各業務系統數據源在部門內部即可解決。各業務部門只需要跟大信息中心一次提需求即可。業務部門沒有自己的分析挖掘團隊，但一般會有傳統的報告分析。 這種形式大多由傳統BI系統部門演變而來。傳統的經營分析中心或商業智慧部演變為大數據中心，在數據倉庫基礎上增建大數據平台，增加大數據及數據挖掘人才，在原來的報表製作的基礎上建設更深入的數據分析應用。 優點：數據中心與IT在一個部門，離數據近，數據整合便利，保障數據質量高。集中的需求管理也使內部溝通有效，避免重複開發，也可以使分析師內部總結提高。 缺點：離業務較遠，尤其是分析團隊與業務部門的工作地點不同時，容易與業務部門溝通不暢，閉門造車。如果業務變化快，無法跟上業務的步伐，對數據的思考不夠深入，與業務部門溝通成本加大。 針對分析師集中後離業務較遠的弊端有一種方法為：分析師仍然集中在大數據中心，但分析資源的使用、請求在各個業務部門，企業各業務部門自己根據項目需求請求所需的分析師。這種情況下分析師需要同時向本部門和業務部門彙報工作。 第二種形式為集中式。 這種形式與第一種的主要區別在於大數據中心是否獨立。 這種形式的特點是公司所有與數據相關的平台建設、數據應用、數據分析挖掘都歸屬到一個部門，此部門是數據管理的唯一出口，業務部門不設立自己的分析團隊，IT部門也不負責相應平台開發維護。 優點：部門職責明確單一。指標由一個部門計算，口徑統一，且與業務部門獨立，所以立場獨立，分析結果更中立。 缺點：同時具有第一種形式的缺點，並且離業務部門及業務系統都較遠，無論是數據理解還是業務理解都可能不夠深入，同時如果大數據平台開發維護能力不強，會有技術困難難以推進。 第三種形式為混合式 此圖與之前的主要區別在於業務部門是否有分析師。這裡不再分析大數據中心是否獨立的問題。主要分析大數據中心下分析師與業務部門分析師的職能及定位。 大數據中心分析團隊職責主要集中在整個企業級的數據產品、數據應用、數據分析。服務的對象也主要是公司級的部門和領導。他們技術能力和業務能力更強，能利用最新技術解決業務問題，同時必要時對業務部門分析團隊給予指導。 而各業務部門自己的分析團隊主要服務於自己部門內部，技術能力不等，以前主要根據報表做統計或分析報告，但他們本身在業務部門對業務理解深入，主要是利用數據解決業務問題。有些強勢部門可直連倉庫自己寫SQL提數，定製開發簡易報表，技術強的業務部門甚至要求建設自己的數據集市，搭建自己的挖掘團隊。 這種形式下的主要缺點是兩者職責有時劃分不清，造成部門利益為重、爭搶項目、職責推諉、重複開發、口徑不一致等問題。各業務部門的分析團隊之間交流不暢，技能提升有限。有一種變通的方法為打破各部門利益障礙，建立橫向的虛擬分析團隊，加強虛擬團隊內部溝通交流，甚至團隊內部成員作為共享資源可根據項目周期流動。 通過以上分析可以發現為發揮分析優勢，是在集中分析部門便於內部交流與靠近業務便於理解業務的矛盾的平衡。 每個形式都有各自的優點與缺點，沒有對錯之分。沒有最好的只有最合適的，每個企業都要根據自己的實際情況進行調整。 文 | 岳瑞 文章源自：數據陽光

在數據管理領域，我們通常將數據分為：主數據、交易數據、參考數據、元數據和統計數據分析（指標）， 指標是BI系統裡面核心的概念，是一個企業數據運營關注的核心數據，一般以KPI和報表的形式體現。 從實踐來看，一個企業要進行數據治理，涉及了架構、安全等諸多層面，但最迫切的是提升數據質量，其中指標質量則是重中之重，一般業務上90%以上關於數據的疑問都從指標的質疑開始，只要你從事數據相關工作，就應該深有體會。 「這個指標好像跟業務發展實際不符，快去查查」，估計這是報表取數人員聽到的最多的一句話了。 下文就來談談如何從根本上去提升指標的數據質量，即實現指標的標準化，作為一個數據管理人員，不管你有多少能力，曾經解決了多少問題，當過多少回救火英雄，都應該從更為長遠的角度來思考這個問題。 指標標準化的核心價值在於實現「書同文，車同軌」，即通過針對指標的一系列管理過程，去提升指標準確性、一致性、敏捷性及開放性。 DAMA將數據治理放到核心地位，指標的標準化就是個典型的數據治理問題，治標是容易的，治本的代價則太高，但如果要實現進階，還是要站的高一點，多思考一下，想想是否有更好的方法，就從筆者多年前做過的指標標準化項目開始吧，分為組織保障、報表梳理、指標整合、實現方式、功能架構、可視化引擎及管理流程等七個方面。 1、組織保障 指標庫這類數據管理項目，或稱BI項目，一般業務部門參與的力度是不大的，這是大多BI項目實施效果不佳的一個深層次原因。 DAMA提到要實施數據治理活動，跨部門的數據治理委員會等是關鍵的組織，的確是這樣，指標跟全公司每個單位都相關，對於其進行規範化改造當然應該獲得大家的一致同意。 可惜的是，大多企業沒有這個理想條件，也不會有數據治理委員會，在數據還未成為真正的實質性資產前，比如納入財務部的資產目錄，很少有企業會設立這個數據組織，因為效益不明顯，因此，哪個企業都不大可能為指標出一個規範並且通令全公司貫徹執行，對於數據管理人員，指標庫這個事情也許意義不小，但對於全公司意義則小了，這是現狀。 在沒有公司層面的組織保障前，數據管理人員或BI部門大多得靠自己，通過自己來推動事情往前走， 這是應有的態度，你不提，公司也沒有任何人會提，畢竟你是最大受益者，實施指標庫這個事情非常複雜，誰都沒有成功的把握，秉持小步快跑，試點探索的原則是不錯的。 筆者的這個指標庫項目獲得了分管領導的強力支持，這是項目能進行的現實組織保障，其實這類管理項目設立之初，很難讓業務部門和一線人員馬上認識到其價值並充分參與進來，這個溝通管理成本太高了，但無論如何，一個數據治理項目能否成功，公司的支持是第一要務，不僅僅是IT部門的事情，DAMA的很早就在《DAMA數據管理知識體系指南》明確了數據治理的組織要點，以下是DAMA的數據治理組織架構圖，非常超前： 當然我覺得現實的組織演進也許如下圖更合適，但道理是一樣的，相關利益方需要對這個事情達成共識： 2、報表梳理 指標的主要表現形式是報表，因此第一要務就是報表梳理，公司的報表浩如煙海，因此這個項目設立之初就限制了範圍，主要針對一線市場部經理、終端管理、流量管理三類核心角色，共梳理了相關的39個彩信、48份郵件通報及數據集市上的733張報表。（筆者所在公司為某運營商） 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數據治理的討論幾乎沒有，這倒是值得思考的問題。 文 | 傅一平 原文自：微信公眾號 與數據同行

數據分析項目到收尾關頭，總要出一份數據報告。 按照項目類型，可能是產品投放市場的效果評估；日常報表製作數據匯總；活動數據分析。而報告也分多種情況，有的需要給項目組一個交代，有的需要和業務組一同評估分析，有的則是郵件抄送領導向上級彙報。 數據報告無論是文本、PPT還是數據圖表製作，都得展示分析的核心思路和結果，本質都是相同的。 1.好的分析師要會講故事 一個數據報告的核心不是面面俱到的內容，而是讓讀者讀懂「問題——假設——原因——驗證過程——結論——背後現象——可推行的決策」這樣一個脈絡的故事。類同於諮詢和投資機構，在做BP之前會先花時間理清楚storyline。其實各種報告都應該這樣，先理清楚思路，就有了故事。 2.數據分析報告的框架 這裡列出一個我慣用的報告框架（針對不同業務場景可能會有所調整，增刪或再細分）： 項目背景 &項目進度 項目背景，需要簡述項目相關背景，項目需求、分析目的、市場情況、為什麼做，目的是什麼，以讓讀者了解項目的前因後果。項目進度，需要綜述項目的整體進程，以及目前的情況。 指標定義&數據獲取 核心指標如何定義？公式是什麼，為什麼這麼定義，這點是很重要也是很容易被忽略的，很多時候的誤解都是沒有對指標進行統一定義。舉個例子，比如服裝「斷碼」。從領導層來講，公司倉儲的服裝全部尺碼如果不完整就是斷碼；從倉庫的倉管員角度來講，倉庫內的服裝尺碼不全就是斷碼；從門店的業務員角度來講，客戶需要的尺碼當前門店無貨就是斷碼。定義不同，在會員系統、庫存系統、訂單系統中這個斷碼的數據就不對應。主數據管理可能並沒有覆蓋到所有指標，所以分析指標時要考慮這一點。 數據概覽 &數據探維 數據概覽是對指標的發展趨勢和變化情況，例如最高最低點做成因解釋。而數據探維是對某指標按照不同的維度做分析，做細節補充。這也是數據分析時常的方法，多維度分析。這一點常常用FineBI等BI系統工具來操作，製作好模板，以後就可以按照特定的維度來分析了。這裡需要注意的是，核心指標要少而關鍵，拆分指標要有意義並有清晰地邏輯來說明。如果涉及的維度較多，不建議用PPT來一個一個描述。一些BI工具可直接在web上展示，切換維度，動態的展示更加生動，容易說明。 結論匯總 結論匯總，基本是對之前數據分析階段的數據進行匯總，形成完整的結論。後續改進，需要在數據分析的結論和問題的基礎上，對後續的迭代和改進措施作出方向性的說明。這部分其實很多時候也是分析的根本目的。 最後附上詳細的數據，尤其是那些沒有必要在數據報告中體現但是仍然有價值的數據。一個項目/業務，如果你不能衡量它就不能了解他，也就無法改進它，說的就是數據。 我們都不可能提前知道數據的結果，也不能報紙中立的態度去判斷。任何從事數據工作的人，尊重數據結果，並分析形成結論，遠比相信一些所謂的方法論的條條框框好得多。

報表是數據展示工具，商業智慧BI是數據分析工具。 報表工具是一類報表製作工具和數據展示工具，用於製作各類數據報表、圖形報表。或者製作特定格式的電子發票聯、流程單、收據等等。 商業智慧的重點在於商業數據的分析，集成了數據統計、數據展示、數據分析和挖掘的解決方案。Gartner給出的定義：商業智慧是提取企業各個運作系統的數據，然後進行清理、抽取、轉換和裝載，即ETL過程，合并到一個企業級的數據倉庫里，從而得到企業數據的一個全局視圖，在此基礎上利用合適的查詢和分析工具、數據挖掘工具、OLAP工具等對其進行分析和處理，最後將結果呈現給管理者，為管理者的決策過程提供支援。 從功能上講 以報表FineReport和BI系統工具FineBI舉例。 FineReport的應用場景主要是業務報表製作，比如一些企業固定的月報，季報和關鍵數據指標的統計、展示和分析。主要功能分為三大類：數據展示(報表)、數據查詢(參數)和數據錄入(填報)，還有報表管理。 數據展示報表可分為表格類和圖表類 1、表格類 a. 樹形報表 b. 聚合報表 c. 匯總報表 d. 複雜票據 2、 圖表類（一般按業務主題分析） 注重業務數據的可視化展現 3、數據查詢 a. 數據錄入（填報）：向資料庫提交信息。 商業智慧工具側重於數據分析，所以在報表製作難度上大大降低，但換來的代價是，不能製作複雜的報表。不同於傳統做表的方式，他的目的在於將大數據量的數據快速的進行模型構建，自由維度分析，製成Dashboard。相比報表，側重點在於分析，優勢在於操作簡單、數據處理量大，分析快速，能實時分析，可以數據分析類的工具如R、Python語言結合，拓展數據挖掘的分支。 功能上FineBI有簡單報表（匯總表和明細表）、Dashboard和分析功能。 簡單報表 Dashboard 數據處理方面有鑽取、聯動、旋轉、切片、預警。 從面向群體來講 報表主要面向IT開發者，或者某些企業專門設置的報表開發人員。因為需要一定的資料庫知識和少量的JS知識；商業智慧主要面向業務人員、數據分析人員。操作簡單，側重分析。兩者最後的報表和數據分析結果都是給領導、管理層看的，他們通過分析結果來制定決策。 從背後的技術架構來講 商業智慧可以和大數據分析軟體平台對接，處理更大的數據量，常常基於企業搭建的數據平台，連接數據倉庫進行分析。當然有些報表工具也可以完成這一部分工作。 最後的最後，兩者的關係可交叉可遞進，關鍵還是取決於企業需求，業務需求，也並不能絕對的判斷好壞，各有優勢，各有適用環境。

概述：作者是業界資深的數據分析師，人工智慧投資人，他在文章里給我們介紹了什麼是大數據的來源，目前在數據領域的初創公司與現有巨頭的競爭現狀，各自在數據領域所採取的不同做法，數據分析工作的外包，為什麼有關大數據分析軟體的項目總是會失敗？ 在本章節中，我想試著描述、分享一下大數據在公司商業運營情境當中所扮演的角色。 大數據的能力是從何處而來？ 首先，我想先花一點時間來談談有關數據的價值，數據所發揮的作用，它是從何處而來的。 我認為「企業專家中心「（Centre Of Excellence) 這個部門非常之重要，它作為最前沿的公司職能部門，負責將數據的角色引入到公司，並將其功能放大化。它的主要職能就是對跨部門的工作進行協調，具體包括了下面這幾項內容： 1. 對企業的技術架構進行維護和升級 2. 決定應該收集什麼樣的數據，從哪個部門來收集這些數據 3. 推動人才招募計劃 4. 制定「關於從數據中獲取真相」的流程環節以及戰略，並制定有關隱私、合法合規性、以及行業道德規範標準的政策制度。 但是，除此之外還存在其他的管理架構和形式。也許對你現有的商業模式來說，還存在匹配程度更高的管理架構和形式，數據分析、組織結構模式。 其實，在商業模式和數據分析基礎的結合上，存在著好多種組合方式。商業單元（BU）各自獨立，各自為戰是一種法子，相互獨立的 BU 為了某些具體的項目相互協作也是一種法子，企業內部治理（公司治理的金字塔頂端）是一種途徑，外部中心（企業專家中心）也是一種途徑。 數據初創公司與數據壟斷型公司的對決 到底是數據初創公司勝出？還是數據壟斷型公司勝出？這個答案不可能清楚地給出，裡面有太多需要考慮到的變數，尤其跟公司本身所處的行業，還有所持有的競爭優勢有關。最重要的一點是，商業策略的制定，跟公司處於哪個成長階段有著莫大的關係。 儘管從歷史經驗上我們可以看出：很多小公司在結構上比大公司要有著明顯的優勢（就比如說一些初創公司在管理數據上面比大型藥品公司要做的出色的多），但是這並不能說：公司越是初期，在數據處理和應用上的成熟度更高。 更準確的說法是：因為小公司本身的靈活性，它們在這方面行動會非常迅速，而且因為本身基數小，所以很容易在增長比例上大幅超越大公司。 在這裡，我想要強調的重點是：初創公司和大公司，在面對數據問題，儘管目標一樣，但是採取的路徑和方式方法是截然不同的。這裡將這兩種方法分別稱之為：回溯型方式和前瞻型方式。 前瞻型方式：一般適用於小型初創公司，更準確的說，是那些剛剛進入行業不久，短期內還無法產出大量的數據，但是很快就會實現。正因為這一點，決定了它們從一開始就要制定一個高效實用數據的戰略。 回溯型方式：更適合於已經在行業里紮根多年的大公司，它手上握有海量數據，但是它們不知道怎麼使用，比如如何將數據向某個中心樞紐集中。 前瞻型方式 採取這種方式的初創公司不拘泥於過去既定的任何組織架構，而且從一開始，為了某種長期的願景，它就制定出非常嚴格的數據政策，以避免未來在數據領域出現任何的突髮狀況。而且，它一開始就投入大量的資源和時間，如果做對了的話，那麼它會繞開接下來運營發展中的種種不便。 一開始就制定好一個完善的數據政策，能夠很好地滿足初創公司在接下來發展中，處於各個不同發展階段時的需要。更重要的是，年輕的公司所受的約束較少，這種約束不僅體現在內部，比如官僚層級還沒有形成；更體現在外部，比如政策法規上面扶持鼓勵遠遠多過約束限制。而且它們往往對風險的接受度較高，使得它們願意去測試和應用很多前沿科技，它們更願意關注高質量的數據，而不是追求數據量的積累以便獲得研發的基礎。 回溯型方式（已有的大公司） 大公司往往會遇到下面的兩個問題： 1. 它擁有的數據量確實非常大，但是它們不知道該如何是好。 2. 它們手裡有數據，而且頭腦中已經存在著明確的目的，但是因為數據質量達不到標準，數據整合方式上面並不完善，以及配套技能上不過關，連啟動這個項目都做不到。 先說第一種情況。這樣的公司往往是剛試著轉型到數據驅動領域，它是有數據，但是不知道如何從中提取出有價值的東西出來。鑒於很多大公司的工作崗位要求都很明確，工作任務都被塞的很滿，要求也比較高，所以某些時候它是無法做到公司內部進行創新的，也就是說，它們太忙了，根本抽不出時間。有些行業，比如銀行業、金融科技行業，這個問題體現的尤其明顯。 關於這個問題，我認為一開始就要聘請一名專門在商業智慧想法、戰略上做創新的人進來。這個人富有經驗，能夠成為「數據驅動」理念的傳道者，哪怕他不具備非常強大的計算機技術背景，他也能夠為整個公司帶來非常寶貴的建議和想法。 有了這樣一個角色的存在之後，再去考慮找一名合格的數據分析師。 再來看第二種情況。他們手上有數據，也有明確的目的，但是不知道如何利用它們。我認為這存在著兩種解決方案： 1. 公司從「一張白紙」出發，建立某種全新的數據平台，團隊，以及以數據為核心的文化； 2. 公司直接將數據分析工作以及與數據有關的問題外包出去。 第一種方式如果一切進展如預期一樣，肯定會帶來更加穩健強勁的發展，但是成本也比較高。所以這個時候決策者是需要權衡成本收益誰大誰小的。 第二種方式是數據分析工作的外包。大公司一般傾向於選擇某些大學作為數據分析工作的外包方。理由很簡單：大學一般來說都比較缺錢，也需要數據來進行一些研究，從而方便最終形成論文報告。一般它們的報價也比專註於做數據分析的初創公司要低很多，更何況大學機構中不缺人才，不缺時間，不缺意願，有足夠多的理想條件來收拾整理一堆亂七八糟的數據。 相比之下，初創公司以盈利為目標，選擇它就意味著較高的成本，但是它也是有優勢的。往往這樣的公司里聚集著世界最頂尖的數據分析人才，而它本身就掌握著很多非常有價值的應用研究案例和資料庫，這些東西都是大學機構所比擬不了的。 但無論你是選擇大學機構還是初創公司，都存在著一個繞不開的問題：數據的隱私安全性。你需要問下面的這些問題：公司外包出去的數據都是什麼？第三方機構是如何保證這些數據的安全性的？它們是怎麼存儲數據，決策機制又是怎樣的？ 除了這兩種辦法之外，其實還有一些「旁門左道」，能夠讓你近乎於免費的得到數據分析結構。這就是科技圈裡日趨流行起來的黑客馬拉松和某些行業內聚會。你在這其中可以看到很多人有數據分析的才能，也能通過公開自己的數據，免費地拿到數據分析結果。 為什麼大數據項目很容易失敗？ 原因來自各個方面： 1、缺少商業目標和規劃； 2、無法正確的找出需要解決的問題，缺少解決方案規模化的路徑； 3、缺少 C […]

面對紛繁複雜的大數據生態，人們常常用亂花漸欲迷人眼的字樣來描述。因所處背景和位置差異，每個人對大數據的反應也各有不同，或疑惑、或欣喜、或鄙視、或無奈。大數據很通俗，每個人都可以聊聊。大數據也很神秘，很多觀點其實並不清楚在表達什麼。 本文嘗試從生態視角聊一下大數據的現狀，並以反欺詐模型為例簡述一下大數據挖掘的未來發展。希望聊大數據的時候能處於同一平面，浮於表面的觀點或雞同鴨講的交流都屬於浪費時間。 金融科技「四大俗」 大數據的火爆，以及大數據給人造成的反感，一個很大原因在於其內在偏虛。我們不能光說價值，總得拿出點看得見摸得著的東西。大數據不是獨立存在，還要關注幾個相關的領域。從邏輯上看，大數據的下面可以是雲計算和區塊鏈，上面是人工智慧，這就是之前在朋友圈隨口說的的金融科技「四大俗」。俗的一個原因是由媒體爆炒引發了連鎖反應，鄙視不負責任的忽悠和開的比瓢都大的腦洞。為人處事需要好好學學基本道理，「兩學一做」其實不錯。 四個熱門領域都是我關注的，實際上這四個處於不同的發展階段。目前雲計算已經比較實在了，企業可能已經關注盈利了。大數據整體還在穩步發展，關注的是多行業、多領域的應用。人工智慧離科幻電影裡面的AI還很遙遠，目前火爆的是特定領域的應用。至於區塊鏈，還是以概念、模式為主，killer application還沒有，理論和實踐都需要持續完善。 關於四者的結構關係，畫了兩個圖。左邊的是層次分割，從基礎到應用。右邊的是以大數據為核心，硬的環繞軟的，將大數據作為原油或血液的比喻了；其實還可以加上物聯網，不過在金融科技裡面談的還不是太多。 當我們開始討論大數據的時候 相比雲計算的踏實，人工智慧和區塊鏈的高冷，只有大數據是真的「俗」。似乎所有的人都可以聊聊，有人專心聊思維，有人聊商業模式，有人做數據治理，有的人聊數據資產。當然，更多的人集中在技術和應用上面。總體而言，大數據應用是核心驅動力，基於新思維、新技術開採數據資源，並構建相應的商業模式；過程中數據治理貫穿始終，確保各層協同一致，保障數據價值創造。 至於整體生態則表現的過於繁雜，大數據生態圈、hadoop生態圈，甚至有人一聽到生態就頭大，因為還會加上業務生態。實際上也想不到更好的描述，生態說明了這個系統的複雜性。在生態裡面的玩家很多，形形色色，各講各話。我建議還是少關心些模式、戰略，多研究些問題和技術。三年前還比較好混，比如光靠說別人聽不明白的話就可以混混；但現在不行了，理論和實踐綜合起來才可以繼續愉快的刷「存在感」。 窮理的過程中，大數據領域有一個容易陷入的誤區就是以偏概全，從一個點出發就對全局下一個判斷，諸如大數據是萬能的，或者大數據是無能的，這樣的結論看的多了自然就會厭倦。當然，還是那句話，形形色色，存在即合理，尊重每個人的觀點。 紛繁複雜的大數據生態 Matt Turck發布了最新的2017年大數據版圖，原圖很大就不浪費流量了。大數據生態圖譜中包括889家公司/產品，具體分布如下。首先要了解整體布局，然後有時間可以逐個走一遍，挑感興趣再查查資料，這樣就能了解整體生態的基本情況了。如同學科交叉的發展，今年大數據生態裡面包含了更多AI的內容；數據科學、機器學習、人工智慧，是大數據分析軟體發揮價值的關鍵。 ps1: 高清版下載地址——http://mattturck.com/wp-content/uploads/2017/04/Big-Data-Landscape-2017-Matt-Turck-FirstMark.png ps2: 圖片上具體產品的說明需要到明細網址查看，並非所有的內容都畫到了圖上。 基礎設施領域主要是多了一個Data Governance，領頭羊是Informatica和IBM。 難道大家建了一堆數據湖之後開始關心治理了，不得而知。另外最近的熱點是Spanner及其開源版本CockRoach，集成sql和nosql的優勢，很神奇。還有就是銀行常用來與TD edw配套的GreenPlum，歸屬於Cloud EDW；查了查資料，大概是MPP已經不足以反映GP的技術優勢，還加入了雲、敏捷開發等新技術。 分析這部分與2016年的版本大體一致，多了點中國元素，face++和Mobvoi。 應用部分更加細化，金融部分居然包括三個單元，不愧為大數據的頭號炒作行業。 開源部分也進一步細化了，尤其是增加了AI/DL單元。 大數據挖掘的昨天、今天和明天 數據挖掘是大數據發揮價值的關鍵，如果企業沒有成功的數據分析挖掘，那無論如何是不該說已經具備大數據能力的。以反欺詐挖掘建模為例，聊聊大數據挖掘的發展，也就是過去、現在和未來。 傳統反欺詐管理中主要依賴專家經驗，通過人工方式制定檢測規則，當申請或交易信息與反欺詐規則匹配後即執行相應的業務策略。這種管理模式得出的反欺詐規則存在一定的局限性，不能枚舉所有業務場景，無法對各類欺詐行為進行全面覆蓋。當專家規則積累達到一定數量後誤報率通常會比較高，能夠影響到實際風險決策制定和實際業務開展。 目前的主流做法是應用機器學習技術進行欺詐風險管理，機器學習是一種研究機器獲取新知識和新技能並識別現有知識的方法。可以結合大數據理念從整體視角對欺詐風險進行評估，實現風險的精準預測並以此作為應對欺詐風險的強力手段；同時可根據模型結果進一步提煉異常規則，發現未知欺詐模式。 未來伴隨大數據與人工智慧的持續發展，可以期待能夠識別各類欺詐模式的「真正」人工智慧模型。魔高一尺，道高一丈，模型具備自主學習和進化能力，實現欺詐風險的提前預判（想到了少數派報告）。在這個狀態下，單純的大數據已經沒有意義，替代的是一個個商業智慧解決方案，大數據和人工智慧會融入同一個生態圖譜。 大數據之路漫漫 相比之下，國內大數據行業的整體規模還不算大，說的多，做的少，掏錢的更少，整體還是起步階段。換句話說，就是killer application還比較少。插一句負責任的話，現在看到的文章和案例水分都很大；當然，不深入進去可能不太容易識別出來。 現在無論大數據治理還是大數據應用，無論諮詢公司還是實施公司，乾貨真的不多，以至於交流的時候會忍不住吐槽幾句。大數據進入銀行視野超過五年了，所以交流的時候需要乾貨，這等同於誠意的表現。踏踏實實的做點事還真不太容易，因為項目里不確定因素太多，只能確保自己盡量靠譜一點。 當然，在大數據領域，無論如何都要保持足夠的謙卑，學會選擇。在踐行過程中懂了一些，就會發現不懂的更多。從2012年開始，每年的想法都會變，所幸螺旋式的上升也會逐步到達融會貫通的境界。 原文自：SmarterBank

本文是來自帆軟粉絲deafire在帆軟論壇的分享，大家可以去論壇與更多帆軟粉絲交流，獲取有用資訊哦。 前言： 這兩天公司組織學習了李善友教授的認知革命，可以說是給自己開了一個腦洞，具體腦洞多大這裡就不細談，因為不是本篇主題。聽完之後，反思過去種種，其實感覺自己也是一直有在用這種思維做事，只是自己還不了解這種思維的本質。 本篇帶給大家的，更多的是一種解決問題，剖析問題的思路，這種思路其實不單單局限於帆軟，也不是在說明帆軟就一定要按照我說的這樣子去用，帆軟是一款自由度很高的軟體，像excel，可以用在各方各面。日常工作生活中，應該也可以找得到共鳴。 好了，進入今天的主題。 正題： 大概在兩年前，我發布了第一個總結的帖子：http://bbs.fanruan.com/thread-66099-1-1.html。這帖子是在使用帆軟一個月之後做的一些東西。 兩年前，我認為帆軟對於這種企業系統是萬能的，兩年後，我這個想法依舊不變。經過這兩天的學習，我把我為什麼這麼認為的想法，具象化出來，供大家參考。首先：我以下說的，都是錯的 問：帆軟有什麼功能？ 答：兩個主要功能：填報、數據展示 這兩個功能，是帆軟的根，其他一切功能，都是基於這兩個的擴展，疊加出來 那麼在問：目前的ERP，OA，CRM，或者各種各樣其他的業務系統他們最根本最實質，剖析到最深處的，是什麼？ 答：填報、數據展示 填報：各種各樣得流程表單 數據展示：列印、導出、數據分析 看到沒，看到共同點了沒，都是填報、數據展示，所以這也就是說為什麼我當初遇到帆軟第一天，我就知道了，帆軟能用來做什麼，這兩年的時間，無數的項目也驗證了我這一想法，幾乎沒有她做不了的企業系統。無論是什麼樣子的系統，業務系統，物流系統，HR系統，CRM，MRP系統，ERP系統，OA系統，這些系統你只要努力摸清楚，他們的根本，把他們的業務一遍又一遍的梳理，剖析，會發現，最終出來就只有兩個表單，報表（最多最多給你加多一個流程引擎，當然這是後話，帆軟也是可以跟流程引擎結合的（activity ），也是很完美的結合的。），那麼這兩個梳理出來後，我們要做的第一個步驟，就是打基礎，把資料庫底層邏輯都定下來，然後再這個基礎上，再去用帆軟去實現一個界面的填報，跟展示。 所以，什麼？ 所以，大家看到沒，帆軟她就是一款萬能的工具，就是一款高自由度的展示工具，只要你對業務熟悉，你有想法，那麼你加上帆軟，可謂如虎添翼。 可能剖析的比較淺，因為這兩天的學習，我大部分時間也是在閉目，冥想。但是我也正是遵循了這一個原則、定律，我才能用帆軟攻克下不少項目，也是用她，實現了我很多想法，很多我以前可能得花費很多時間、金錢才能完成的想法。 好了，說的不多，只是覺得很多人用帆軟，都只是簡單把他用作報表製作工具，沒能正確理解，剖析她到底可以用到另外一個方面，這裡做個路標，引導大家可以從另外一個方面去用帆軟（當然很多人不拿來這麼用的原因其實還有：成本貴、已有成熟系統可用，哈哈） 最終總結： 帆軟是萬能的企業E化工具，簡單的可以做：資訊收集工具、考試系統、評分系統、協同數據導入模板等等；複雜的可以做：OA，ERP，CRM，公司內部自己的業務系統等等等等。 帆軟的組成=業務（70%）+ SQL（20%）+ JS（5%）+ FineReport使用（5%） 這公式不是跟你瞎掰的，我花了1天可以用他做項目，目前所在公司的小妹（沒有系統學過SQL，會的SQL都是從別複製粘貼，但是對要做的報表業務都熟悉），花了1天可以用她開發報表，所以他的使用是特別特別簡單，你會用excel你就會用帆軟，然後加上你對業務的熟悉，懂點SQL語法，再懂一點點JS代碼，那麼項目，可攻破。各種其他你編程上面的遇到的技術問題，不攻自破，因為你已經開闢一條新的道路來實現系統了，已經不用去用編程了，所以都不攻自破。另外：以上我說的，都是錯的。 學習步驟（簡單四步走）： SQL為一切的基礎，所以 第一步學習SQL（不用深入，你只要知道幾個基本概念，資料庫是什麼東西，他能幫助我做什麼，為什麼要用他就可以了） 第二步理解你的業務（你是想做庫存管理系統呢，工資系統呢，還是僅僅是數據收集統計系統） 第三步了解點JS 第四步，用FineReport分別開發一個簡單的填報，再把填報的數據以不同的維度展示出來。 做完這四步驟，那麼恭喜你，你入門了，以後就看你自己怎麼發展了。

來自帆軟粉絲Kody在帆軟論壇的分享，大家可以去論壇與更多帆軟粉絲交流，獲取有用資訊哦。 數據可視化是一個溝通複雜信息的強大武器。通過可視化信息，我們的大腦能夠更好地抓取和保存有效信息，增加信息的印象。FineReport可以美化圖表，但如果數據可視化做的不佳，效果會不是那麼理想。錯誤的表達會損害數據的傳播，完全曲解他們。 優秀的數據可視化依賴可視化工具的同時，也依賴優異的設計。在我們看到的圖表表達中，各種讓人啼笑皆非的錯誤都有，下面就是這些錯誤當容易糾正的例子： 錯誤1：混亂的餅圖分割 餅圖，是最簡單的圖表之一。不過偏偏有人喜歡把它搞得很複雜。餅圖的設計應該直觀而清晰。下面就是兩種可以讓讀者的注意力瞬間集中到你要表述的重點的方法。 方法一：將最大的部分放在12點鐘方位,要順時針。第二部分12點鐘,逆時針方向。剩下的部分可以放在下面,繼續逆時針方向。 方法二：最大一塊12點鐘開始,順時針方向旋轉。剩餘部分在降序排列,順時針。 錯誤2：一直使用單一的圖表元素 根據不同的內容，我們可以設計多樣化的圖表元素來強化視覺衝擊，不可以反覆使用一直類型的圖表元素。 錯誤3：數據排序混亂 你的內容應該以一種合乎邏輯的和直觀的方式來引導讀者了解數據。所以，記得將數據類別按字母順序,大小順序,或價值進行排序。 錯誤4：數據模糊不清 確保沒有數據丟失或被設計。例如,使用標準的面積圖時，可以添加透明度,確保讀者可以看到所有數據。 錯誤5：讓讀者自己解讀 設計師應該使圖表儘可能輕鬆地幫助讀者理解數據。例如,在散點圖中添加趨勢線來強調的趨勢。 錯誤6：扭曲數據 確保所有可視化方式是準確的。例如,氣泡圖大小應該根據區域擴展,而不是直徑。 錯誤7：在一張熱力圖上使用不同的顏色 顏色用得太花，會給數據增加不可承受之重，相反，設計師應該採用同一色系，或者類比色。 錯誤8：條狀圖太胖或太瘦 或許你的報告很有創意，非常精彩，但是記得圖表製作水平也要跟上。條形圖之間的間隔應該是1/2欄寬度。 錯誤9：很難比較數據 比較是展示數據差異的好法子，但是如果你的讀者不容易看出差別的話，那麼你的比較就毫無意義。確保所有的數據都是呈現在讀者面前,選擇最合適的比較方法。 錯誤10：濫用3D圖表 雖然他們看起來很酷，但是濫用3D形狀有可能會扭曲感知,因此扭曲數據。有的時候堅持2次元，會使數據分析顯示更加準確。

企業的數據分析是個很複雜的工程，需要業務和分析技術兩塊知識。這裡從業務的角度切入，談談如何對業務分析，文章參考帆軟軟體的零售業數據管理方案。 首先，企業的分析主要分為管理分析和經營業務分析，分析整體的思路是：明確業務場景——確定分析目標——構建分析體系——梳理核心指標。 因為每個企業/行業的業務不同，分析體系也不同，這裡主要說一下零售電商，按照不同的分析場景來探討下。其他行業也歡迎大家勾搭，或者可以看看這個專欄里里的案例（比較偏向報表製作體系，有一定借鑒意義）：帆軟數據應用研究院 以電商為例，常用的業務分析場景有銷售、商品、渠道、競品、會員等等，而商品可進一步細分為商品的庫存、商品的利潤以及關聯銷售分析。在整個業務分析體系中，電商行業遵循「人貨場」的思維邏輯，其指標可這樣劃分： 1、銷售類分析 銷售分析主要是為了追蹤銷售情況，與KPI對比，調整銷售策略，進一步提升銷售額。 分析思路：基本上任何一個問題都可以套用「人貨場的模型來分析」。比如分析客單價下降的原因，從人貨場角度切入的話，可建立如下的分析模型： 分析方法：數據分析可通過數據對比、極值、預測的方式來分析 對比：比如事業部銷售額排行榜、銷售額貢獻度、城市排行榜等等 極值：比如月銷售額最高紀錄，激勵銷售人員或事業部突破記錄 預測：根據權重曲線預測未來的銷售額 2、商品分析 商品分析是基於商品的一個流程管理——進銷存。比如商品庫存太大，佔用資金，則採購進貨不合理；商品陳列不合理，造成發貨不及時，銷售滯後。 商品分析體系——「進銷存」思路，常用的指標如商品的折扣率、動銷率、周轉率等。 3、會員數據分析 會員數據分析一方面是可以指導銷售營運，另一方面是提高行銷的精準度，增加用戶的粘性，減少流失。 會員分析管理體系： 4、其他管理分析 人力資源管理中的數據分析一般包括兩個方面，一方面是人員結構分析，另一方面是人力效能的分析。在人效分析過程中最關注兩個指標，人均產出和人員費用產出率。人員結構分析包括不同職能部門的人力結構、不同層級的人才結構、不同工作年限的人才結構等等。分析人力結構是防止人才的斷層，在招聘上做好預案，優化薪酬分布。 數據分析領域的財務主要是管理財務，管理財務需要細化到每個子公司、每個業務、每個產品、每個業務部門、每個客戶，以他們為主題的分析有：現金流分析、盈利能力分析、財務預算分析等。 這裡只是概述了一個框架，每一個點展開都是一門知識，歡迎留言探討~

了解過數據倉庫歷史的人都知道Bill Inmon、 Ralph Kimball。 Bill Inmon 代表作《Building the Data WareHouse》 ， Ralph Kimball代表作為 《The Data Warehouse Toolkit》、《The data Warehouse lifecycle》。兩位大師對數據模型都分別作了深入闡述，個人理解的數據模型是數據平台的靈魂。數據模型設計好了對數據應用、數據分析支援是非常有幫助的。尤其 kimball 提出的維度模型 ，圍繞業務模型能夠直觀的表達業務數據關係。 關於數據模型概念不多講，本文與大家分享多維數據模型設計的十個技巧。 技巧一：維度表中應該包含最細的顆粒度 通常在數據平台做開發的同學，「特麽」經常抱怨 「 需求怎麼又變了，這個需求能不能不要來回的改「，數據建設中會遇到非常不確定性需求，不可預測篩選與匯總。 尤其是在互聯網做數據化運營，絕大部分需求幾個匯總類指標是無法滿足需求，很多時候會沉浸到比較明細、更深層次的細節信息。當然匯總指標是能夠概括一些概述數據細節，但只有細節數據才能回答各種不停的業務上數據追問。 技巧二： 圍繞業務流程來構建維度 數據是真實的反應業務活動與成果的，業務流程在不同的階段所產生數據項也是不一樣的。比如說一個用戶從尋找App、下載、安裝、啟動、再啟動這個流程，用戶在淘寶購物、尋找瀏覽物品、放入購物車、跳轉收銀台、支付、完成。 這兩個流程背後代表某個業務事件活動，在不同的環節產生的數據項是不同的，如果將流程不同階段的指標沉澱下來變為可度量的關鍵指標，如果將這些關鍵指標根據關係合并與設計到事實表中，就變為支撐業務人員分析、探索業務的細節數據。 為了能夠從業務流程上的多維度來探索數據，所涉及到的很多維度最好是業務流程來做設計，比如上圖交易現相關，從訂單的來源，所屬產品、到支付階段的資金來源，從業務流程上來看，還可以擴展出更多的維度、與度量值。 在不同的業務環節，業務人員都會「很任性」的需求不同指標，但是在需求中往往是與業務流程有很大關係的。 技巧三：盡量保證每張事實表與時間維度有關聯 在原則二中描述那兩個案例業務永遠是與日期有關係的，不管是月、日、年、還是分、秒，財務年、自定義時間事件段等。 每個事實表至少有一個外鍵能夠與日期維度表相連，時間維度能才能反映出存量與流量，才能分析某一時刻、某一時間段的業務流程變化情況。 技巧四：同一張事實表的指標對應維度層級必須一致 一般的事實表有四種類型，粒度事實、周期性快照事實、聚合快照事實、非事實事實表，不管它們的粒度類型，事實表中的每個度量值在顆粒度上必須保持與維度的顆粒度是一致的，否則就等著崩潰吧。 例如原則二給出的案例，要分析一個用戶訂單支付業務。如果對這個業務進行設計分析模型時，把產品維度粒度定義為產品，但是在度量值金額卻是按照不同產品分類做聚合的，那就有意思了。我暫時也沒回憶起類似的場景會在什麼情況犯錯。 技巧五：處理好事實表和維度表之間的多對多關係 在多個維度表的值可以賦給單個事實事務時，事實表和維度表之間通常是多對多關係，比如為了計算寫書的作者分成，一本書可能有多個作者， 一個作者可能出版了多本書，這個案例下就是多對多的關係。要考慮到可以計算出每個作者的的分成，中間可以增加一個橋接表。 綜上所述，在這種情況下多個值的維度與事實表直連可以採用橋接表來處理。 技巧六：經常發生變化的維度處理 在設計維度上很多時候都是扁平化處理，業務中普遍的維度關係是一對一的關係，比如例如客戶Simmy將自己的地址由原先的Addr1改為Addr2。這時我們需要將這個記錄了客戶Simmy的記錄中的有效截止日期改為現在，並重新添加一條有效截止日期為現在的和一個新的版本號且Address為Addr2的記錄。 但是也經常存在一對多的關係，比如大家的購物郵寄地址、個人電話號碼等在現實生活中有變化的處理。這種情況可能存在一對多的關係，假如一張維表存在上百萬的維度且匯總信息經常在變化，那得注意做緩慢變化、或快速變化處理了。 技巧七：讓維度表使用代理鍵 英文叫SurrogateKey，翻譯過來又叫代理鍵，在建模中通過一些毫無意義鍵值來代替一些業務鍵值，有利於維度統一整合。 技巧八：進行一致性維度的處理 一致性維度，又叫統一維度。對於構建企業級數據平台數據模型具有關鍵的意義，通過在數據轉換處理環節一次性處理後，在構建不同數據集市、不同數據層時可以反覆被使用。 統一維度在構建多維模型時，可以很便捷能把多種不同類型業務指標進行關聯，讓使用用戶在不同業務間切換分析、還能減少維護工作。 比如數據描述經常不一致性如，同名異義、同物異名，還有口徑多樣化、編碼不統一、命名不統一等。還能處理一些未知、不知道名字、日期待定等一些含糊的分類。 而然，在實施統一維度時最大的障礙是需要不同的業務部門、IT部門對每個維度屬性上達成一致，那就涉及到數據管理、數據治理的範疇了。比如含義相同但名稱不同業務術語等。 […]