數據分析報告,【建議】部分該怎么寫?
在數據分析中,如何提出有效的策略性建議?本文通過一個簡單的例子,展示了如何運用數據思維,深入挖掘問題背后的原因,并提出具體的、可操作的建議。
你不要光報數字!要做策略性思考!要提出可行的建議!
很多做數據的同學都被領導、同事這么吆喝過。然而,什么是策略性思考???往往一聽到這種詞,就有同學急不可耐地掏出《麥肯錫方法》之類的鎮山法寶,或者在網上搜《底層思維》、《核心邏輯》、《分析框架》之類的文章。
結果除了“裂變”“痛點”“顛覆”這些似懂非懂的詞以外屁都沒有記住,下次寫報告還是繼續同比、環比、三年比,低了要搞高……
咋辦?!
看個簡單的例子,今天HR的小妹妹李芊穎同學被領導罵哭了,因為身為HR,她本人這周的考勤表,長這樣:
SO,作為數據分析師的同學們,看到這個咋提建議?
一、缺乏策略性的表現
很快,4個做數據分析的同學都給了答案。
同學1的答案:
- 本月共22個工作日,遲到11個工作日,遲到率50%
- 遲到最多的是第二周,共遲到4天,遲到率80%
- 遲到最少的是第三周,共遲到1天,遲到率20%
同學2的答案:
- 遲到次數太多,建議不要遲到。
- 特別建議周一不要遲到。
同學3的答案:
- 數據來源是……
- 建模過程是……
- 經過回歸模型分析,預測下個月遲到12天。
- 建議減少遲到。
同學4,還沒給答案:
他正在網上找《員工遲到分析模型》。找了一上午沒找到,但是加了五個數據分析討論群,每個群里都在問:
- 有沒有數據分析高手?
- 有沒有HR行業的數據分析師?
- 有沒有HR方面分析的書,最好PDF版的?
- 急!可付費!在線等!
問,以上四個同學,哪個能及格?
二、核心的癥結
顯然,以上四個都不合格哈!
不合格不僅僅因為他們說的都是空話、廢話。更因為他們都犯了同一個問題:就數論數,脫離過程。
作為HR經理,想聽到的建議是:
- 建議1:早點出門。
- 建議2:該打車就打車,省那錢干啥。
- 建議3:犯了錯就認罰,哭有屁用!
作為李芊穎小妹妹,想聽到的建議是:
- 建議1:減少給李芊穎同志的工作量。
- 建議2:由于李芊穎同志住得太遠,建議多批幾天特例。
- 建議3:上個月李芊穎同志太辛苦,建議免于處罰。
看到區別木有,無論是業務方的領導和下屬,都不關心具體的數字是什么,更不關心得出數字的模型是什么。他們關心的是可以做什么。做的事情要有依據,能服人就更好了!所謂建議,是業務部門可以做的一個具體動作。這個動作和業務工作流程有密切關系。要能夠達到一個大家認可的結果。
所以在推導建議的時候,不要單純在數字上糾結,特別是不要在類似題目的這種“結果數字”上糾結。單純糾結結果,就會變成“你說我偷懶,我說我沒懶”這種小孩磨牙式爭吵。要想辦法深入到問題發生的過程中,才能找到答案。
三、破題的思路
聯系到具體過程,我們就能發現:數據對于量化過程、鎖定問題有巨大幫助。
比如最簡單的一個建議:“早點出門”,聽起來是個理,實際上至少存在三個漏洞:
- 早到幾點出門不清楚,6點?7點?8點?空口說“早點出門”跟沒說一樣,需要量化。
- 有沒有特殊原因,不清楚。很有可能小姑娘哭得梨花帶雨的:“人家前一天加班到半夜,第二天起不來很正常嗎?。?!要求正裝出席,出門前化妝不很正常嗎?。?!又要人家忙又怪人家,嗚嗚嗚”……不區分具體場景的量化,根本說不服人。
- 特殊原因真的假的,不知道。鬼知道她是真在忙,還是前天出去嗨到半夜去了。更糾結的是,可以直接推導出答案的數據可能是缺失的。你又不是人家男朋友,你怎么知道人家前一天晚上是出去嗨了還是加班了。
沒有直接證據的情況下,就得一步步來:
- 先清理出來可用的數據,建立一個基本分析框架
- 再看怎么挖掘具體場景,排除異常情況
這樣才能做到有理有據,以理服人。
四、答題的順序
第一步,先搞清有什么數據可以用。
通勤這件事,我們其實并不需要那么多隱私信息:
第二步,建立基礎的分析框架。
基礎的分析框架中,不考慮各種意外情況、特殊場景,就看業務最基本的數據邏輯。
比如通勤這個事,只要選好了起點(李芊穎住的小區)終點(公司),打開高德地圖都能看到:
- 距離多遠
- 坐地鐵需要多久
- 坐車需要多少錢,需要多久
有了這些基本信息,就能判斷出來:這個距離是否真的太遠,從而剔除很多借口/猜疑(如下圖):
第三步,討論可以量化的特例。
不要一看到小姑娘漂亮就想八卦人家的隱私,除了引發爭吵外沒啥好處。先把能收集到數據的,明面上的問題,比如加班、打車算清楚。這樣一來能看到:是不是真的分工不均,委屈別人了;二來也能堵住找借口的嘴(如果確實沒加班的話)。
第四步,推導建議。
有了以上的鋪墊,推導建議就能有理有據了,而且非常具體(如下圖):
五、回到現實工作
當然,上邊只是一個逗比的小例子,但是清晰地反映了現實中問題:
- 業務部門往往處于本位主義思考,提的建議都是對自己有利/自己想表達的,懶得顧及事實,更懶得細致分類。
- 數據部門往往陷入數字游戲,過于關注數字計算,忽視業務過程,最后就數論數,止于數字。
這樣都是不利于得出正確的結論和建議的,最好的做法,就是從過程出發,層層推進,構建起邏輯樹。然而這兩年算法模型概念廣為流傳,一下讓業務方和數據都以為,只要LR,CNN,XGBOOST呼啦啦往上懟,電腦就能開口說話:“李芊穎呀,我是全知全能的阿爾法大狗子,這個月遲到都怪你自己哦”……于是就惹出更多笑話了。
當然,這些都建立在一個基本前提上:你得能分清看到的是結果數據還是過程數據。曾經有個同學問陳老師:“老師,我要如何提升策略性思考能力,你看我們現在明明一切做得很好,可轉化率就是上不去,為啥嗯?”
答曰:你們現在就是李芊穎呀,嘟著粉紅小嘴一臉委屈的:“我明明每天很積極上班了,可咋就是遲到了呢”……想找到答案,光糾結結果沒啥用,得深入過程中哦。
所以不要單純地堆砌數字,或者擺一堆圈圈框框,具體問題具體分析才是正道。
專欄作家
接地氣的陳老師,微信公眾號:接地氣的陳老師,人人都是產品經理專欄作家。資深咨詢顧問,在互聯網,金融,快消,零售,耐用,美容等15個行業有豐富數據相關經驗。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
“建立基礎的分析框架”,這一步講得有些模糊,有幾個問題:
1. 不同的場景,分析的問題和數據是不同的,文章里面并沒有給出普適性的方法論——如何搭建分析框架?
2. 現實的場景中,數據、問題、目標等,并不像“遲到問題”這么簡單。強行去簡化,也只能得出比較空泛的結論,無法給出具體可行的實施方案;
我感覺“框架”這個詞感覺被用爛了,好像一個萬能的黑盒,給人一種“簡便方法”,又或者是解決問題的固定套路的感覺。
很多文章上來就是提出一個問題,然后丟到框架里面去,答案就出來了。
支持?。?!