大多數時候,取數的量遠遠超過報表的量,因為報表往往是成形的指標的系統固化,而取數往往是具有探索性和分析型,因此數量可能會非常龐大,比如一些企業一年的報表新增或修改不到幾百張,但取數卻有上萬個。取數是一個企業非常依賴的一項基礎IT工作,除了常規的KPI和報表,其實放在領導案頭的多數分析數據,往往來自臨時性的取數,典型的場景如下:“領導發現了KPI的一個異動問題,業務分析人員要盡快核查清楚問題,但常規的報表然并卵,業務人員會作一些設想,然后設計大量的分析表格,而這個表格的數據,則需要BI團隊中的取數人員臨時性的提取并提供。”現在大數據很熱,人工智能很高大上,但其實大多企業的日常決策,靠的還是這種數據支撐模式,IT在里面的價值,就是提供這些數據。取數是當前大多數企業決策的生命線,也是IT價值的重要體現,這個評價我想在當前毫不為過,雖然業務人員可以風光的將取數人員的成果最終展現為漂亮的圖表和分析報告,但完成分析的時候,也請千萬別忘了感謝一下取數人員。這里為取數人員的價值正名,雖然可能在老板年終總結報告上只有一個呆板的數字,但又有哪一頁跟取數脫得了關系,雖然很多人并沒意識到。但業務人員卻經常抱怨取數的速度和質量,取數看起來并不那么容易。為什么?自己有過很多年的取數經歷,雖然現在已經不做取數了,但還是要回過頭來談談關于取數的看法,希望有所啟示。首先,是錯位問題。取數,到底是IT人員的職責還是業務分析人員的職責,從傳統的角度來講,存在的即是合理的,在大多數企業仍然是IT人員的職責,畢竟IT人員離數據最近,既然系統是你建的,從上面取個數理所當然是你的職責,況且還要寫代碼,更加不可能是業務人員的事情。但從另一個角度講,取數是業務人員的職責也是合理的,做分析,講究的是個數據探索,探索本來是個不確定的事情,而且需要反復迭代,取數中業務人員和取數人員的溝通成本是很大的,兩個不同背景的人,在業務口徑和數據口徑上要達到統一,對于雙方要求都很高。取數的迭代成本其實蠻高的,一般以天計,給取數設置一個指標,比如反復取數率,估計這個指標也是驚人的。這個錯位需要改變嗎?各個企業需要根據實際情況做取舍,沒有絕對的邊界,取數放在哪邊都有合理的地方,但如果業務人員抱怨速度太慢,可以轉換下思維,嘗試下自己去取數,這個并不是純技術活,懂點SQL就能應付大多數場景,在數據處理靈活性上,比那個EXCEL強很多。玩數據,不要太相信人家端到你面前的,那也是信息量打了很多折扣的,業務分析人員應該看到企業最鮮活、最原始的數據,那個最有價值。因此建議業務分析人員應該具備取數能力,這為數據分析和創新提供了無限可能,雖然會犧牲一些取數時間,但爭取來的溝通成本降低、IT技能增長及數據分析視野拓展,是完全值得的,取數讓你更具競爭力。對于取數人員來講,如果有可能,可以先嘗試著開放一點集市讓業務人員自己來取,你不開放,不去推動,業務人員也許永遠不會走出第一步。除了傳統習慣,業務人員所以不自己取數,往往是因為市場競爭沒到那個份上,數據分析快點慢點沒關系,也不是關鍵環節,但如果是個數據驅動型的企業,還是要做一些變革。但有一點需要承認,如果錯位不改變,無論取數系統多快,由于溝通成本很難降低,取數速度沒法獲得幾何級的上升。其次,取數對于BI的人員要求其實很高。取數人員,對于某個取數,要知其然并知其所以然,什么意思呢?當前BI取數人員,大多是從數據倉庫或報表庫等OLAP系統提取數據,數據倉庫的模型表往往是已經加工好的表,其在提供取數方便的時候,也過濾掉了大量源系統數據的信息,這往往導致一個取數需求明明可以取,但由于數據倉庫的限制而無法取的情形,取數人員就像井底之蛙,只能看到數據倉庫讓你看到的東西。這種現象普遍存在,因為系統早就在那里,你接手的是一個成熟的系統,現在開發都講封裝,但封裝在提供開發便利的時候,也讓我們的新手缺少了接觸本源信息的機會,從而扼殺了創造力,我們不是站在巨人的肩膀上,而是被限制在巨人的肩膀上,不敢去懷疑哪怕是半點。要成為取數專家,特別強調的一點是一定要理解源系統數據,只有這樣才能理解數據倉庫模型的本質,才能更好的理解業務需求,通過刻意訓練,你成為了公司內唯一能夠連接起業務人員、倉庫人員、源系統開發人員的橋梁,你才可能成為專家。專家不僅僅是滿足需求的人,還能主動創造需求和給出建議,比如能對于數據倉庫的模型提出改進意見,能對業務人員提出的需求進行質疑,這都來源于你對于數據認知的深度,但這樣的人,其實很少,因為需要刻意訓練。舉個例子,公司內CRM菜單上的某個條目,你知道對應于源系統哪個數據嗎?并且影響到數據倉庫哪個模型嗎?業務人員往往不管你從哪個系統取數,總是從看得見的地方提出問題和需求,如果你是普通的取數人員,一旦倉庫沒有對應數據,是否就不清楚如何作答,但專家不是,這就是差距。當然取數人員不僅需要專,也需要廣,這又是為什么?數據分析的價值在于多領域數據的融合分析,這就需要取數人員對于公司的大多領域數據要有充分的掌握,數據廣度往往決定了取數人員的視野,也決定了其發展潛力。但取數還是比較容易陷入“做熟做專”困境,因為平常接觸到的取數需求可能大多比較狹隘,因此掌握更多領域的數據似乎無此必要,這也是專家和普通取數者的區別,但如果你對于數據有更多的大局觀,你就能適應不同場景的需求,就能融會貫通。領導所以為領導,有一個特別重要的,就是它接觸的領域比你廣太多,對于取數的人來說,更廣的數據視野讓你取數游刃有余,有更大的發展潛力。比如,你要做業務,可以,企業最需既懂數據也懂業務的綜合人才,你要做系統,可以,因為你懂源系統的數據,你要做模型,可以,廣褒的數據視野和強大的取數能力是你獨一無二的分析武器,你要做項目,可以,很多綜合的取數人員往往能走上BI項目經理的崗位,你要做技術,也行,平臺要獲得成功始終要依賴業務和數據的深入理解。做一個合格的取數人員很不容易,特別是要成為專家型的人物,那也是需要付出巨大的代價的,沒人逼你做這些又紅又專的事情,想選擇怎樣的道路,全賴自己。但有一點是肯定的,如果你希望通過被動的接收一些取數需求就能獲得更大的提升,那基本也不可能,取數這個事情,2-3年就可以很熟很上手了,應付崗位訴求綽綽有余。但要讓業務人員對你建立起完全的信任,真心的稱呼你為專家,則是兩個境界的事情。再次,取數要能自動化,但這個真得很難。取數人員的使命是讓取數更快更準,這將越來越成為企業的核心競爭力,因為新的時代市場變化越來越快,取數越快越準,企業的決策成本就能越低。除了增強取數人員本身能力,還有什么辦法讓取數越快呢?那就是自動化,平臺化。記住,取數不總是那么變幻萬千,它也是有一定規律的,這為自動化提供了可能,比如有兩類典型取數類型,營銷清單型和復雜分析型,營銷清單型,往往跟一線執行相關,70-80%的規則是比較簡單的,通過配置往往就可以提供,復雜分析型,則規則比較難抽象,但也是有規律可循的。不少企業,正是建立了自助取數平臺,通過提供前臺配置界面,從而讓業務人員自助完成取數工作,這能夠解決很大部分取數工作,好處很多,以XX運營商為例:(1)? 能自助解決至少50%以上的取數需求;(2) ?取數標準化,不易出錯;(3)? 速度更快,一般在30分鐘;(4) ?取數在線化,經驗獲得傳承;當然這類取數平臺建設比較艱難,除了體驗要好,性能要高,還要去做持續的運營,而且改變業務人員取數習慣很難。但取數人員始終要有一顆自動化的心,以前筆者和同事堅持做這個平臺2-3年,最后算是推廣開,而這個平臺現在還活著,至少占據著公司40%的取數量。作為一個IT人員,最大的褒獎應是自己倡導或建設的平臺有人仍然在用,并持續的發揮出價值吧,而筆者以前在5年里拉磨似的取的上千個數,還有誰會記得呢?這個其實也帶點平臺化的思維,取數人員一定要努力形成取數的平臺生態,你發力的點不在一個個取數,而在于建設及運營好取數這個開放的平臺,不要僅僅是自己在這個平臺孤獨的跳舞,要能創造足夠好的數據模型,提供足夠好的操控體驗。大數據時代,現在領先一點的都開始搞人工智能了,雖然我們是傳統企業,但也不要被拉的太遠,要有一顆“平臺”的心,關于取數自動化后面我會專門撰文,敬請期待。創造環境,讓別人比你活得更好。最后,在這個大數據時代,取數人員還是要與時俱進。以前報表取數人員橫跨業務和數據,號稱是企業的綜合型人才,但現在已經遠遠不夠了。為什么?大數據時代技術突飛猛進,隨著數據量的變化,IOE已經無法走遍天下了,你要取數取得快,需要升級你的平臺引擎了,我能打造更牛逼的自助取數平臺嗎?最近也一直在問,我們傳統企業的取數挖掘,能不能全部搬到SPARK?大數據結構越來越復雜,業務場景越來越多,SQL顯然不夠用了,我們的取數人員未來是不是要掌握各類語言,以適應不同的取數場景?比如,能否取出近3分鐘的上網流數據并統計給我?能否臨時爬蟲看看公司的負面輿情如何?大數據時代更強調算法了,我們半路出家的取數人員,如果面對業務人員這個問題,該如何作答?能否給我取個數,看看杭州的公交司機有多少?這個還是傳統的取數嗎,是嗎?不是嗎?沒必要去質疑業務人員,這個可能就是未來的臨時取數需求,取數人員,準備好了嗎?