文末領取【Python練習題+代碼】
分析是怎樣一個過程？分析解決業務問題的框架又是什麼？
本文主要介紹分析業務的一般流程，分為兩個部分：分析是怎樣一個過程?分析解決業務問題的框架是什麼?
分析業務的過程
隨著現在大數據存儲、雲計算、IOT等技術的快速發展，越來越多的場景數據被收集起來，數據的重要性也逐漸被各大公司重視。收集數據是第一步，更重要的是如何分析數據，發現背後的商業價值，幫公司做出正確的決策。
面對海量的數據，面對業務出現的問題，我該如何下手呢？其實分析解決問題的過程，和生活中醫生給人看病的過程類似，都遵循一套流程。
這是解決問題/看病的一般流程，實際情況可能要更複雜一些，過程中需要根據結果反饋不斷的疊代方案，直到解決問題。
分析解決業務問題的框架是什麼
根據上面的介紹，可以把解決問題的框架整理為：發現問題 – 定義問題 – 尋找原因 –提出解決方案 – 落地執行 – 反饋疊代。
衡量標準：業務問題被解決，指標提升了。
1.發現問題
發現問題的過程可能是來自於業務方，屬於被動輸入；也可能是商業分析師自己從指標變化中發現了問題，屬於主動輸入。後者需要對業務非常了解，清楚指標的正常波動範圍在哪兒，對數據敏感，這樣才能發現異常的波動。
2.定義問題
對於發現的問題，要能夠清晰的定義出來：可以根據SMART原則，不斷的向下發問，直到沒有問題為止。
S：Specific 具體的
M：Measurable 可衡量的
A：Attainable 可實現的
R：Relevant 相關的
T：Time-bound 有期限的
舉個例子，老闆讓你分析下某社區附近的自家生鮮超市銷量為什麼最近有所下滑。很多時候老闆/業務方的需求描述都是這樣，問題比較模糊。這時候你就需要去進一步定義問題：
銷量下滑是整體品類都在下滑還是單一品類？
最近下滑是最近什麼時間段，同之前什麼時間段的比較？
下滑是降低了多少？計算口徑是什麼？老闆的輸入是來自哪裡？
帶著這些問題，輔助看一些數據，之後同老闆再次確認細節，最終明確出來，老闆提的需求是：分析某社區附近的自家生鮮超市2月份水果品類銷量同1月份比較為什麼下滑了10%？到這裡，我們才明確要分析的問題是什麼。
再接著往下分析之前，要先去數據校驗一下老闆提出的問題是否屬實，因為他們的輸入也不知道是來自哪裡，可能和真實情況比會有偏差。
3.尋找原因
定義清楚問題之後，接下來就要去分析問題背後的原因了。首先要做的就是將業務進行拆解，遵循兩個原則：
按業務場景，往可運營的方向上拆解
每步拆解滿足MECE原則
這兩個原則是什麼意思呢？
我們分析的項目常常會對應多個業務場景，例如：產品場景、運營場景、市場場景等等；所以我們在拆解這個項目時要把場景考慮全了，根據業務順序，按場景來拆解。
舉個例子，如果公司的流量轉商機率降低了，要去分析是什麼原因。拆解的時候可以分成兩個部分，流量進入平台（APP）、平台內的商機轉化，對應的是：市場場景和產品場景。前者可能是廣告投放命中的不是目標用戶；後者可能是產品內容的問題，沒有直接呈現用戶感興趣的內容，引導產生商機等等。
所以在拆解業務時，先拆場景，再針對具體場景往可運營方向上拆解，那這是什麼意思呢？
我們以貝殼找房來舉個例子，貝殼是一家平台型的房地產加盟公司，平台內有很多加盟品牌，例如：鏈家、德佑、21世紀、中環等等。
我們在分析平台的業務時，很容易想到的拆解方向就是按品牌來，比如某城市的商機轉成交率下降了，我們按品牌維度來拆解，這樣確實可以定位出來是哪個品牌的原因，但是呢，貝殼平台不能跳過品牌直接去管理它下面的門店，所以這樣拆解即使找到了原因，也沒有辦法解決。
但貝殼將城市分成了幾大片區，每個片區有貝殼自己的負責人，所以針對片區，我們可以去管理，那就很清晰了，拆解問題的方向要按片區來，只有這樣發現的問題，我們才有能力去解決。
MECE（Mutually Exclusive Collectively Exhaustive）的意思是「相互獨立，完全窮盡」，是來自於《金字塔原理》這本書中的說法，意思是業務拆解要全面，且相互獨立。這個原則比較好理解，如果拆解的不全面，有遺漏，就可能找不到最終原因；如果拆解的子模塊互相影響有交集，就沒辦法清晰確定是哪個部分的原因。
拆解完了之後，定義衡量每個模塊的指標以及確定做的好壞的標準。正如有句名言所說：If you can't measure it, you can't improve it 。如果你不能衡量它，就沒辦法改善它。接著分析指標數據，判斷是因為哪個模塊做差了導致業務出現的問題。
然後分析該模塊做差的原因：基於提出假設-數據驗證的這一過程。不斷提出可能的情況，反覆的進行數據驗證，直至找到最後的原因。但這一過程往往沒有那麼一帆風順，經常會出現猜測的原因都不對，這個時候就需要去再深入了解業務，或者直接調研一線同事，讓他們給你一些輸入，再去不斷的驗證，定位出來真正原因，這個過程才算結束。
我們尋找問題原因的過程面對的是海量數據，所以我們要基於假設出發，用數據去驗證，而不是boil the ocean，後者會讓你在大數據面前無從下手。
所以尋找原因的流程：拆解業務成模塊 – 衡量模塊表現 – 分析模塊做差的原因。
4.提出解決方案
分析出來是哪個模塊做的差，以及做的差的原因之後，接下來就要去思考解決方案了。在尋找原因環節中，提到要往可運營的方向上拆解，也是為現在這一步做的準備，如果拆解的方向沒有辦法可以運營，即使找到了原因，也解決不了。
這個環節要注意的是解決方案要接地氣可執行、執行成本可以接受。
5.落地執行 – 反饋疊代
有了解決方案之後，就需要去跟業務方溝通，用邏輯和數據去說服他們信任你的結論，以及採用你的解決方案。
這個環節可能會被不斷的挑戰和校準。挑戰你論證的邏輯，所以在去溝通之前，要前後都想清楚，是不是每個環節的數據都足以支撐結論。解決方案也可能不斷的被校準，以適應實際的情況。
所以往往第一次溝通之後，分析師還需要再去做補充，多次溝通，直到雙方都覺得OK。所以這也是我為什麼覺得商業分析師最重要的兩個能力是：專業能力和影響能力。只有專業才能嚴謹的分析出來結論，只有能影響業務方，方案才會被採納執行。
那接下來就是去落地解決方案了，期間不斷關注模塊指標是否提升變好，同時業務的指標也在同步提升。一段時間之後，復盤方案執行的效果。有效的話就更全力的推進。如果無效，就需要去疊代，從以下幾個方向思考方案問題：
是不是落地的問題：執行的不到位
是不是運營方案的問題：運營方案沒辦法改善該模塊
是不是方向的問題：本身數據論證的結論方向有問題
復盤非常重要，根據實際的一線反饋，快速的調整。如此往復的進行這個過程，直到業務問題被解決，商業價值最大化才算整個分析的過程有效，才算結束。
總 結
其實所有問題的解決基本都是按這樣的框架來：發現問題 – 定義問題 – 尋找原因 – 提出解決方案 – 落地執行 – 反饋疊代。無論是業務方提需求還是自己主動發現業務的異常波動，都要清晰的定義出來問題（可以參考SMART原則），接著拆解業務，定位問題模塊，再通過不斷的提出假設-數據驗證的過程找到背後真正的原因，最後再通過運營或者其他方式解決問題，從而改善業務。
End.
作者： 一個數據人的自留地
來源：鳥哥筆記
本文為轉載分享，如有侵權請聯繫後台刪除。
長按下方海報領取 【Python練習題+代碼】
< 零基礎入職數據分析就業班 >
課程形式主為「直播+錄播」
課程專享：月考測試通關+課程項目作業+1v1職場生涯規劃+班主任輔導學習+資深講師答疑
課程結束後能熟練掌握SQL、Python、Excel、PPT等數據分析工具
抓住4月復工熱潮，愛數據助你拿理想offer！