作者｜小諾

本文主要介紹分析業(yè)務的一般流程，分為兩個部分：

一、分析是怎樣一個過程

二、分析解決業(yè)務問題的框架是什么

隨著現(xiàn)在大數(shù)據(jù)存儲、云計算、IOT等技術的快速發(fā)展，越來越多的場景數(shù)據(jù)被收集起來，數(shù)據(jù)的重要性也逐漸被各大公司重視。收集數(shù)據(jù)是第一步，更重要的是如何分析數(shù)據(jù)，發(fā)現(xiàn)背后的商業(yè)價值，幫公司做出正確的決策。面對海量的數(shù)據(jù)，面對業(yè)務出現(xiàn)的問題，我該如何下手呢？其實分析解決問題的過程，和生活中醫(yī)生給人看病的過程類似，都遵循一套流程。

這是解決問題/看病的一般流程，實際情況可能要更復雜一些，過程中需要根據(jù)結果反饋不斷的迭代方案，直到解決問題。

根據(jù)上面的介紹，可以把解決問題的框架整理為：發(fā)現(xiàn)問題 – 定義問題 – 尋找原因 – 提出解決方案 – 落地執(zhí)行 – 反饋迭代。

衡量標準：業(yè)務問題被解決，指標提升了。

發(fā)現(xiàn)問題

發(fā)現(xiàn)問題的過程可能是來自于業(yè)務方，屬于被動輸入；也可能是商業(yè)分析師自己從指標變化中發(fā)現(xiàn)了問題，屬于主動輸入。后者需要對業(yè)務非常了解，清楚指標的正常波動范圍在哪兒，對數(shù)據(jù)敏感，這樣才能發(fā)現(xiàn)異常的波動。

定義問題

對于發(fā)現(xiàn)的問題，要能夠清晰的定義出來：可以根據(jù)SMART原則，不斷的向下發(fā)問，直到?jīng)]有問題為止。

    S：Specific 具體的；

    M：Measurable 可衡量的；

    A：Attainable 可實現(xiàn)的；

    R：Relevant 相關的；

    T：Time-bound 有期限的；

舉個例子，老板讓你分析下某社區(qū)附近的自家生鮮超市銷量為什么最近有所下滑。很多時候老板/業(yè)務方的需求描述都是這樣，問題比較模糊。這時候你就需要去進一步定義問題：

    1.銷量下滑是整體品類都在下滑還是單一品類？

    2.最近下滑是最近什么時間段，同之前什么時間段的比較？

    3.下滑是降低了多少？計算口徑是什么？老板的輸入是來自哪里？

帶著這些問題，輔助看一些數(shù)據(jù)，之后同老板再次確認細節(jié)，最終明確出來，老板提的需求是：分析某社區(qū)附近的自家生鮮超市2月份水果品類銷量同1月份比較為什么下滑了10%？到這里，我們才明確要分析的問題是什么。

再接著往下分析之前，要先去數(shù)據(jù)校驗一下老板提出的問題是否屬實，因為他們的輸入也不知道是來自哪里，可能和真實情況比會有偏差。

尋找原因

定義清楚問題之后，接下來就要去分析問題背后的原因了。首先要做的就是將業(yè)務進行拆解，遵循兩個原則：

    1.按業(yè)務場景，往可運營的方向上拆解；

    2.每步拆解滿足MECE原則；

這兩個原則是什么意思呢？我們分析的項目常常會對應多個業(yè)務場景，例如：產(chǎn)品場景、運營場景、市場場景等等；所以我們在拆解這個項目時要把場景考慮全了，根據(jù)業(yè)務順序，按場景來拆解。舉個例子，如果公司的流量轉商機率降低了，要去分析是什么原因。拆解的時候可以分成兩個部分，流量進入平臺（APP）、平臺內(nèi)的商機轉化，對應的是：市場場景和產(chǎn)品場景。前者可能是廣告投放命中的不是目標用戶；后者可能是產(chǎn)品內(nèi)容的問題，沒有直接呈現(xiàn)用戶感興趣的內(nèi)容，引導產(chǎn)生商機等等。

所以在拆解業(yè)務時，先拆場景，再針對具體場景往可運營方向上拆解，那這是什么意思呢？

我們以貝殼找房來舉個例子，貝殼是一家平臺型的房地產(chǎn)加盟公司，平臺內(nèi)有很多加盟品牌，例如：鏈家、德佑、21世紀、中環(huán)等等。我們在分析平臺的業(yè)務時，很容易想到的拆解方向就是按品牌來，比如某城市的商機轉成交率下降了，我們按品牌維度來拆解，這樣確實可以定位出來是哪個品牌的原因，但是呢，貝殼平臺不能跳過品牌直接去管理它下面的門店，所以這樣拆解即使找到了原因，也沒有辦法解決。但貝殼將城市分成了幾大片區(qū)，每個片區(qū)有貝殼自己的負責人，所以針對片區(qū)，我們可以去管理，那就很清晰了，拆解問題的方向要按片區(qū)來，只有這樣發(fā)現(xiàn)的問題，我們才有能力去解決。

MECE（Mutually Exclusive Collectively Exhaustive）的意思是“相互獨立，完全窮盡”，是來自于《金字塔原理》這本書中的說法，意思是業(yè)務拆解要全面，且相互獨立。這個原則比較好理解，如果拆解的不全面，有遺漏，就可能找不到最終原因；如果拆解的子模塊互相影響有交集，就沒辦法清晰確定是哪個部分的原因。

拆解完了之后，定義衡量每個模塊的指標以及確定做的好壞的標準。正如有句名言所說：If you can't measure it, you can't improve it 。如果你不能衡量它，就沒辦法改善它。接著分析指標數(shù)據(jù)，判斷是因為哪個模塊做差了導致業(yè)務出現(xiàn)的問題。

然后分析該模塊做差的原因：基于提出假設-數(shù)據(jù)驗證的這一過程。不斷提出可能的情況，反復的進行數(shù)據(jù)驗證，直至找到最后的原因。但這一過程往往沒有那么一帆風順，經(jīng)常會出現(xiàn)猜測的原因都不對，這個時候就需要去再深入了解業(yè)務，或者直接調(diào)研一線同事，讓他們給你一些輸入，再去不斷的驗證，定位出來真正原因，這個過程才算結束。

我們尋找問題原因的過程面對的是海量數(shù)據(jù)，所以我們要基于假設出發(fā)，用數(shù)據(jù)去驗證，而不是boil the ocean，后者會讓你在大數(shù)據(jù)面前無從下手。

所以尋找原因的流程： 拆解業(yè)務成模塊 – 衡量模塊表現(xiàn) – 分析模塊做差的原因。

提出解決方案

分析出來是哪個模塊做的差，以及做的差的原因之后，接下來就要去思考解決方案了。在尋找原因環(huán)節(jié)中，提到要往可運營的方向上拆解，也是為現(xiàn)在這一步做的準備，如果拆解的方向沒有辦法可以運營，即使找到了原因，也解決不了。

這個環(huán)節(jié)要注意的是解決方案要接地氣可執(zhí)行、執(zhí)行成本可以接受。

落地執(zhí)行 – 反饋迭代

有了解決方案之后，就需要去跟業(yè)務方溝通，用邏輯和數(shù)據(jù)去說服他們信任你的結論，以及采用你的解決方案。

這個環(huán)節(jié)可能會被不斷的挑戰(zhàn)和校準。挑戰(zhàn)你論證的邏輯，所以在去溝通之前，要前后都想清楚，是不是每個環(huán)節(jié)的數(shù)據(jù)都足以支撐結論。解決方案也可能不斷的被校準，以適應實際的情況。所以往往第一次溝通之后，分析師還需要再去做補充，多次溝通，直到雙方都覺得OK。所以這也是我為什么覺得商業(yè)分析師最重要的兩個能力是：專業(yè)能力和影響能力。只有專業(yè)才能嚴謹?shù)姆治龀鰜斫Y論，只有能影響業(yè)務方，方案才會被采納執(zhí)行。

那接下來就是去落地解決方案了，期間不斷關注模塊指標是否提升變好，同時業(yè)務的指標也在同步提升。一段時間之后，復盤方案執(zhí)行的效果。有效的話就更全力的推進。如果無效，就需要去迭代，從以下幾個方向思考方案問題：

    1.是不是落地的問題：執(zhí)行的不到位；

    2.是不是運營方案的問題：運營方案沒辦法改善該模塊；

    3.是不是方向的問題：本身數(shù)據(jù)論證的結論方向有問題；

復盤非常重要，根據(jù)實際的一線反饋，快速的調(diào)整。如此往復的進行這個過程，直到業(yè)務問題被解決，商業(yè)價值最大化才算整個分析的過程有效，才算結束。

其實所有問題的解決基本都是按這樣的框架來：發(fā)現(xiàn)問題 – 定義問題 – 尋找原因 – 提出解決方案 – 落地執(zhí)行 – 反饋迭代。無論是業(yè)務方提需求還是自己主動發(fā)現(xiàn)業(yè)務的異常波動，都要清晰的定義出來問題（可以參考SMART原則），接著拆解業(yè)務，定位問題模塊，再通過不斷的提出假設-數(shù)據(jù)驗證的過程找到背后真正的原因，最后再通過運營或者其他方式解決問題，從而改善業(yè)務。

文章來源：鳥哥筆記