有朋友困惑於團隊報表取數太多的問題，跟我來探討提升的方法，這其實是大多數據團隊都會碰到的問題，原因無外乎以下幾個：
第一、市場變化很快，取數要跟着市場節奏走，這意味着響應要儘量快，個性化程度卻很高
第二、取數屬於IT的後端，IT部門是企業的後端，也就是後端的後端，這種生態位讓取數團隊在企業中處於弱勢地位，比如IT可以以穩定性、連續性爲由制定一些業務不得不遵守的規矩，但數據團隊就很難，連續性無法成爲數據團隊的理由
第三、取數對於大多數業務部門來講，不需要付出什麼成本，業務人員只要在EXCEL上填幾個字段，發個郵件或起一張工單，就有一堆IT人員爲你服務，叫我也拼命的提
當然如果每次取數爲企業創造的價值總是大於IT付出的成本，那取數肯定越多越好，但現實應該不是這樣，可以做2個思想實驗。
第一個思想實驗：
想象你跟業務部門處在一個真實的市場環境中，你要求業務部門爲每次取數付錢，你覺得他們能向公司申請到多少成本來支付這筆費用？業務部門一定不會爲取數付出太多，他們會放棄可有可無的取數，並將費用投在對業務更有價值的地方。
第二個思想實驗：
假如你的取數團隊有10個人，讓2個人放棄取數去幹一些不一樣的事情，比如開發，那這兩個人開發創造的價值能不能比取數更高呢？我相信一定可以，只是個人或管理不作爲而已。
取數要提升效率，單位時間內儘量做的多一點，但也要追求效能，因爲做的太多，邊際效率會降低，機會成本卻很大，站在企業的角度講，數據團隊全去幹取數了，就沒有機會去幹其他更有價值的事情了，如果這個平衡未做好，對於企業就是實實在在的浪費。
我們不僅僅要追求取數速度，更要追求點取數的效能，這是我寫這篇文章的立足點。
提升取數效能的方法有很多，我這裏總結了四個方面十二條策略，包括機制創新、人員優化、組織革命、技術提升等等，大家可以結合自身的事情挑選一二嘗試之，但不要生搬硬套，因爲每個公司的情況不一樣，比如有些公司IT很弱勢，管理的手段一般不好用，那就可以試試技術手段。
一、機制創新
第一條、建立標準取數流程
如果你們現在的取數流程還是線下爲主，比如郵件往來啥的，一定要儘量把取數這個流程數字化，爲什麼？
1、沒有數字化就意味着拿不到取數流轉數據，沒有流轉數據就意味着沒法進行分析，沒法分析就無從談起取數的改善，假如某一天業務部門領導找你抱怨取數太慢，請先去看看實際的數據，也許根本不支持這種觀點，你卻很容易被忽悠。
2、在線化後能夠提升取數需求的質量，因爲可以強制業務人員填寫一些必需的信息，比如背景、口徑、分類等等，這提升了規範性，同時增加審批環節後也是對業務人員的一種約束，至少不能亂提。在取數小作坊的年代，取數需求怎麼提都可以，但規模大了就是不一樣，一定要標準化，規範化。
第二條、推動取數透明管理
取數流程數字化後，通過數據分析可以讓你和業務方知道取數的真實情況，能夠增加彼此的理解，促成雙方的有效協作，以下是一些透明化的做法：
- 1、取數一般分爲需求分析、需求提交、需求審批、需求分配、取數開發、結果審覈、結果上傳、結果下載等環節，但取數方和業務方對於取數的耗時可能有不同的理解。
業務方所謂的取數時長是端到端的，也就是從需求分析到結果下載的總耗時，因爲他一般是站在領導的角度看問題；
而取數方計算的耗時一般是指從需求分配到結果上傳的總耗時，他是站在技術的角度看問題。
比如業務方從接收到任務到提交取數需求，花了整整一天，業務方如果把這個時間消耗算在了取數團隊，是不是不合理？業務領導審批就花了一天時間，如果把這個消耗也算在取數頭上，是不是也不合理？取數團隊明明昨天已經上傳了結果，但業務方今天才下載結果，是不是更不合理？
信息不對稱導致了很多的誤解，取數團隊很容易背這個鍋，如果能清晰的告訴業務方真實的時間消耗，會發現取數慢既有技術的原因，也有業務的原因，這個時候取數效能提升就成了雙方共同的事情。
- 2、取數團隊同時服務的部門和業務人員往往很多，但每個部門和個人其實只關注自己需求的完成情況，取數一旦慢了就很難達成諒解，某業務人員會說，我只是提了一個取數需求，而且非常簡單，爲什麼要這麼久？
如果取數團隊能將各個部門和個人的取數代辦清單和優先排序結果甩給他們看，也許會得到一定的理解，至少業務人員在跟自己的領導彙報進度時也有個說辭：他們取數的確很忙，你看其他部門的需求已經排到下週了，要麼領導你幫忙協調一下？
業務部門領導的面子很貴，他會權衡利弊來決策是否要跟取數團隊的領導做溝通，這樣就能避免一些緊急程度不太高的取數需求。
- 3、取數緊急是業務掛在嘴邊經常說的事情，左一個領導要求，右一個領導要求，但取數是否緊急不能光看別人怎麼說，還要看他是怎麼做的，這個還是要用數據說話，請統計下業務人員取數結果及時下載的比例，相信你會對所謂的緊急有新的認識，至少經驗告訴我，一旦你加急取好了，業務人員下載的動作可並不一定很快，有些甚至就從沒下載過。
取數團隊用取數的方式來支撐業務用數據說話，更要懂得用取數的方式來支撐自己用數據說話，否則就是知行不合一。
第三條、實施取數配額制度
公司給予的取數資源是有限的，一般取數團隊對於取數需求的管理方式還是比較粗獷的，誰先來就給誰先做，可能的結果就是對於公司不太重要的取數需求做了一堆，但特別重要緊急的取數需求支持倒不是特別給力，如果公司的取數規模大了，那麼實施取數的預算分配製也是可以嘗試的。
這個流程跟投資預算啥的分配原則差不多，就是根據歷史年度的取數資源消耗計算出每個業務部門今年大致的額度，預留出部分動態資源，然後每個月通報下使用進度，超了就提醒一下，如果長期超過，雖然不能直接拒絕需求，但至少要讓業務知道並欠一份人情，等到向公司申請資源調整的時候，業務至少能幫說一下話，否則很難得到理解。
第四條、提升取數加急門檻
以前做取數的時候，觀察到業務系統運維側做的比較好的一點，就是雖然他們有嚴格的上線管控要求，比如一月上2次線，但緊急上線也是挺多的，很多是業務的要求，然而他們有個鐵律，就是凡是加急的上線，都需要開發或業務的領導出面，否則決不會開口子。
而數據團隊在這方面立的規矩就很少，沒什麼擋取數需求的習慣，一方面可能跟取數反覆迭代的特點有關係，另一方面也可能跟生態位有關係，但任何事情還是要有個度的，否則容易小鬼當家，當取數的資源衝突越來越大的時候，適當提升取數的加急門檻是需要的，至少不要讓一個業務的小兵隨意的加急，否則取數團隊會被累死。
二、人員優化
第五條、優化關鍵接口人員
機制和流程是死的，人是活的，再好的機制和流程，在不同人手上發揮的作用也是不一樣的，一般取數團隊都會設置取數接口人，其會對取數工作進行統籌，但如果安排一個老好人去幹這活，估計要累死三軍。
企業內一般有權威文化，如果你這個人在專業上有發言權，那麼別人對你會有信任度，這就少了很多扯皮的事情。就拿取數來講，業務人員如果問專家取數，專家說了能取就能取，不能取他也就死心了，但如果換做一個新兵，顯然應對上就會差很多，業務人員這麼試試那麼試試的事情可多了。
令人遺憾的是，取數團隊的接口人，老好人性格的比較多，所謂服務意識好吧，不得罪人吧，數據團隊的leader一般也不會把專家或管理型人才放在取數團隊，取數顯得容易被人“欺負”，而業務方會提取數需求的往往是業務專家，或者比較強勢，這進一步“惡化”了取數團隊的環境。
第六條、激發人員自主創新
取數的不變是暫時的，而變化是永恆的，這是由市場決定的，當前成熟的平臺、模型及流程在給取數人員帶來便利的同時，也是一種限制，比如新人一進取數團隊，我們可能就給他立了很多規矩，讓其很難越雷池一步。
寬表現在是大多數取數人員的救世主，但現在的很多取數人員，即使幹了很多年，估計也很難有意識或有膽量去優化工具、優化寬表來提升響應能力，有點想法的取數人員，估計做幾個月或一年就被調走去做什麼產品、模型和分析去了。
取數人員要多思考下自身發展的可能性，在罵倉庫模型垃圾的同時看看能不能自主優化，取數團隊的leader則要多鼓勵這些行爲，試想如果沒有熟悉一線的取數人員的積極參與，倉庫模型怎麼可能獲得提升？
三、組織革命
第七條、實施授人以漁制度
20年前，我們完成一個取數平均耗時3天，10年前降低爲1天，現在估計1天能做幾十個取數了吧，但取數取得再快，業務也會提的更快，比如我們曾經通過技術創新大幅提升了取數速度，這讓業務人員高興了一下，但馬上又有了新的期待。
靠傳統的需求支撐模式是永遠無法達到理想的彼岸的，因爲市場是貪婪的，沒有最快，只有更快，在取數的平臺、數據、技術達到極限的時候，唯一能壓縮取數時間的就是減少溝通成本，那乾脆就讓業務人員自給自足，自己最清這就是取數的“授人以漁”模式。
數據中臺成立後大大加速了這個過程，但這種模式一般只會發生在市場競爭最激烈的地方，發生在對數據最有想法的地方，同時需要有一點運氣，即導火索。
業務人員自己取數從技術角度來講是沒有任何問題的，SQL是個人都能掌握，關鍵是業務觀念的改變，數據人員的觀念也要發生變化，即“建數據中臺纔是自己的本職工作”，而不是日復一日的取數。
這種模式是一種趨勢，傳統行業比較難，大多是時機未到，但做了的企業，可能就嚐到了甜頭，而且再也回不去了。
第八條、設置一線取數組織
“授人以漁”這種方式比較激進，那麼退而求其次，在業務部門設置小IT也是一種降低溝通成本的做法。中臺推出後，“大中臺，小前臺”讓IT前置有了很多可能性，而小IT裏，設置取數團隊是最常規的做法，作爲業務部門自己的人員，他們緊貼業務，跟業務一起辦公，大幅提升取數效率是不言而喻的，這種模式在很多企業以不同的形式存在。
當然這種小IT組織也有弊端，即取數人員的職業發展問題，其在IT技能上精進很難，卻也難成爲業務部門重點發展對象，有些想法的取數人員可以轉崗做業務，那麼其它人呢？
四、技術提升
第九條、加強取數模型提煉
現在都在提數據中臺，數據中臺最核心的東西就是融合模型，評估數據中臺是否好用的一種方法就是看對取數的支撐是否給力，有兩個指標可以來衡量：
第一個是取數支撐度，就是所有的取數中，直接利用融合模型支持的取數比例有多少，融合模型預計算了一些取數邏輯，理論上取數速度會大幅提升，如果取數還是要走基礎模型，那這種融合模型不要也罷。
第二個是取數複用度，就是融合模型被重複使用的平均次數，如果這個次數是1，那就說明模型沒有共享可言，這對計算資源的浪費是最多的。
取數團隊要與數據中臺團隊進行有效協同，取數作爲輸入，數據中臺進行優化，取數再進行評估，由此形成良性循環，這纔是在技術層面提升取數效率的方法，很多數據團隊的取數和模型走的是兩條路，需要反思這個問題。
第十條、升級取數計算引擎
我一直希望取數團隊能扔掉HIVE，直接用sparkSQL，CK等數據庫來取數，這種直接喫技術紅利的方法簡單粗暴好用。
當然更換計算引擎不是你想換就能換得，現實中有三個方面的挑戰：
第一，涉及到技術路線的選擇，周邊生態的配合、投資的計劃、時機的選擇、存量遷移的代價和人員技術棧更換等等複雜因素。
第二、很多取數團隊看到機會不會去抓，因爲做生不如做熟，少點風險最好，反正現在也能支持。
第三、很多取數團隊整天圍着業務走，早就忘了數據技術是怎麼回事了，更別提統籌規劃技術路線了。
第十一條、提升取數自助能力
自助取數並不是新的概念，其通過固化指標和維度，並剛過拖拉鑽取的方式來完成一個取數。但自助取數跟取數市場化的特點是相沖突的，市場要求取數適應變化，比如維度和指標都在變，而自助取數則要求不變，自助取數平臺就需要在這個夾縫中去尋找生存機會，這個夾縫的大小在不同的企業是不同的。
業務一線的工作以執行爲主，簡單的清單級取數比較高，變化也比較小，因此自助取數在基層會用得會好一點，但管理層級越高就越難支撐，因爲往往涉及到複雜的統計，連人都想不清楚的事情，就不能奢望機器了。
但無論如何，自助取數對於提升一線取數效率肯定是有幫助的，至少它能激發使用需求。
第十二條、優化取數開發體驗
PLSQL Developer這款Oracle數據庫管理軟件至今讓我念念不忘，因爲取數體驗做的相當不錯，但隨着Oracle退出大數據領域，這款軟件也逐步退出歷史舞臺。
我們需要在hadoop、MPP、流處理等複雜的技術棧上完成取數，在相當長的時間內沒能研發出一款能與之匹敵的取數產品，這極大的降低了取數的效率。
在剛開始用Hive的時候，以前用Oracle取數的同事就說取數體驗一下子從天堂掉到了地獄，至今仍然有少量的取數人員堅守在僅剩的幾臺Oracle機器上取數，他們寧可不厭其煩的去倒數。
爲了提升使用體驗，我們爲取數工具設置了專門的產品經理後，才逐步解決問題，魔鬼都在細節中吧，作爲數據團隊的leader，一定要親自體驗下自家大數據平臺的取數工具，這個對於取數生產力的影響實在太大了。
十二條策略講完了，當然你可能還有其他的策略，但相信已經不多了，個人的經驗是：解決取數的問題，管理手段一般是優先於技術手段的，不要就技術論技，數據團隊的leader必需身先士卒，如果你真的想解決問題。
從長遠來講，一個數據團隊沉迷於取數是不正常的，畢竟取數是邊際效益遞減的工作，符合2/8原則，你一年完成20%的取數跟完成100%，價值上區別不會很大，至少帶給領導的感知就是這樣，但如果這些取數資源能用來做一些更長遠的工作，比如報表優化、數據分析、數據產品、數字化轉型等等，我想這是任何公司的領導都希望看到的。
※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※
我是「數據分析那些事」。常年分享數據分析乾貨，不定期分享好用的職場技能工具。各位也可以關注我的Facebook，按讚我的臉書並私訊「10」，送你十週入門數據分析電子書唷！期待你與我互動起來~
文章推薦
◆跟資料打交道的人都得會的這8種資料模型，滿足工作中95%的需求
回顧十週入門數據分析系列文：
關注數據君的臉書：
我是「數據分析那些事」。常年分享數據分析乾貨，不定期分享好用的職場技能工具。按贊我的臉書，會有豐富資料包贈送唷！
