要做数据分析，你得先懂分析框架！

一个数据人的自留地分析是怎样一个过程？ 分析解决业务问题的框架又是什么？

作者｜小诺

本文主要介绍分析业务的一般流程，分为两个部分：

一、分析是怎样一个过程

二、分析解决业务问题的框架是什么

随着现在大数据存储、云计算、IOT等技术的快速发展，越来越多的场景数据被收集起来，数据的重要性也逐渐被各大公司重视。收集数据是第一步，更重要的是如何分析数据，发现背后的商业价值，帮公司做出正确的决策。

面对海量的数据，面对业务出现的问题，我该如何下手呢？其实分析解决问题的过程，和生活中医生给人看病的过程类似，都遵循一套流程。

这是解决问题/看病的一般流程，实际情况可能要更复杂一些，过程中需要根据结果反馈不断的迭代方案，直到解决问题。

根据上面的介绍，可以把解决问题的框架整理为：发现问题 – 定义问题 – 寻找原因 – 提出解决方案 – 落地执行 – 反馈迭代。

衡量标准：业务问题被解决，指标提升了。

发现问题的过程可能是来自于业务方，属于被动输入；也可能是商业分析师自己从指标变化中发现了问题，属于主动输入。后者需要对业务非常了解，清楚指标的正常波动范围在哪儿，对数据敏感，这样才能发现异常的波动。

对于发现的问题，要能够清晰的定义出来：可以根据SMART原则，不断的向下发问，直到没有问题为止。

    S：Specific 具体的；

    M：Measurable 可衡量的；

    A：Attainable 可实现的；

    R：Relevant 相关的；

    T：Time-bound 有期限的；

举个例子，老板让你分析下某社区附近的自家生鲜超市销量为什么最近有所下滑。很多时候老板/业务方的需求描述都是这样，问题比较模糊。这时候你就需要去进一步定义问题：

    1.销量下滑是整体品类都在下滑还是单一品类？

    2.最近下滑是最近什么时间段，同之前什么时间段的比较？

    3.下滑是降低了多少？计算口径是什么？老板的输入是来自哪里？

带着这些问题，辅助看一些数据，之后同老板再次确认细节，最终明确出来，老板提的需求是：分析某社区附近的自家生鲜超市2月份水果品类销量同1月份比较为什么下滑了10%？到这里，我们才明确要分析的问题是什么。

再接着往下分析之前，要先去数据校验一下老板提出的问题是否属实，因为他们的输入也不知道是来自哪里，可能和真实情况比会有偏差。

定义清楚问题之后，接下来就要去分析问题背后的原因了。首先要做的就是将业务进行拆解，遵循两个原则：

    1.按业务场景，往可运营的方向上拆解；

    2.每步拆解满足MECE原则；

这两个原则是什么意思呢？我们分析的项目常常会对应多个业务场景，例如：产品场景、运营场景、市场场景等等；所以我们在拆解这个项目时要把场景考虑全了，根据业务顺序，按场景来拆解。举个例子，如果公司的流量转商机率降低了，要去分析是什么原因。拆解的时候可以分成两个部分，流量进入平台（APP）、平台内的商机转化，对应的是：市场场景和产品场景。前者可能是广告投放命中的不是目标用户；后者可能是产品内容的问题，没有直接呈现用户感兴趣的内容，引导产生商机等等。

所以在拆解业务时，先拆场景，再针对具体场景往可运营方向上拆解，那这是什么意思呢？

我们以贝壳找房来举个例子，贝壳是一家平台型的房地产加盟公司，平台内有很多加盟品牌，例如：链家、德佑、21世纪、中环等等。我们在分析平台的业务时，很容易想到的拆解方向就是按品牌来，比如某城市的商机转成交率下降了，我们按品牌维度来拆解，这样确实可以定位出来是哪个品牌的原因，但是呢，贝壳平台不能跳过品牌直接去管理它下面的门店，所以这样拆解即使找到了原因，也没有办法解决。但贝壳将城市分成了几大片区，每个片区有贝壳自己的负责人，所以针对片区，我们可以去管理，那就很清晰了，拆解问题的方向要按片区来，只有这样发现的问题，我们才有能力去解决。

MECE（Mutually Exclusive Collectively Exhaustive）的意思是“相互独立，完全穷尽”，是来自于《金字塔原理》这本书中的说法，意思是业务拆解要全面，且相互独立。这个原则比较好理解，如果拆解的不全面，有遗漏，就可能找不到最终原因；如果拆解的子模块互相影响有交集，就没办法清晰确定是哪个部分的原因。

拆解完了之后，定义衡量每个模块的指标以及确定做的好坏的标准。正如有句名言所说：If you can\'t measure it, you can\'t improve it 。如果你不能衡量它，就没办法改善它。接着分析指标数据，判断是因为哪个模块做差了导致业务出现的问题。

然后分析该模块做差的原因：基于提出假设-数据验证的这一过程。不断提出可能的情况，反复的进行数据验证，直至找到最后的原因。但这一过程往往没有那么一帆风顺，经常会出现猜测的原因都不对，这个时候就需要去再深入了解业务，或者直接调研一线同事，让他们给你一些输入，再去不断的验证，定位出来真正原因，这个过程才算结束。

我们寻找问题原因的过程面对的是海量数据，所以我们要基于假设出发，用数据去验证，而不是boil the ocean，后者会让你在大数据面前无从下手。

所以寻找原因的流程： 拆解业务成模块 – 衡量模块表现 – 分析模块做差的原因。

分析出来是哪个模块做的差，以及做的差的原因之后，接下来就要去思考解决方案了。在寻找原因环节中，提到要往可运营的方向上拆解，也是为现在这一步做的准备，如果拆解的方向没有办法可以运营，即使找到了原因，也解决不了。

这个环节要注意的是解决方案要接地气可执行、执行成本可以接受。

有了解决方案之后，就需要去跟业务方沟通，用逻辑和数据去说服他们信任你的结论，以及采用你的解决方案。

这个环节可能会被不断的挑战和校准。挑战你论证的逻辑，所以在去沟通之前，要前后都想清楚，是不是每个环节的数据都足以支撑结论。解决方案也可能不断的被校准，以适应实际的情况。所以往往第一次沟通之后，分析师还需要再去做补充，多次沟通，直到双方都觉得OK。所以这也是我为什么觉得商业分析师最重要的两个能力是：专业能力和影响能力。只有专业才能严谨的分析出来结论，只有能影响业务方，方案才会被采纳执行。

那接下来就是去落地解决方案了，期间不断关注模块指标是否提升变好，同时业务的指标也在同步提升。一段时间之后，复盘方案执行的效果。有效的话就更全力的推进。如果无效，就需要去迭代，从以下几个方向思考方案问题：

    1.是不是落地的问题：执行的不到位；

    2.是不是运营方案的问题：运营方案没办法改善该模块；

    3.是不是方向的问题：本身数据论证的结论方向有问题；

复盘非常重要，根据实际的一线反馈，快速的调整。如此往复的进行这个过程，直到业务问题被解决，商业价值最大化才算整个分析的过程有效，才算结束。

其实所有问题的解决基本都是按这样的框架来：发现问题 – 定义问题 – 寻找原因 – 提出解决方案 – 落地执行 – 反馈迭代。无论是业务方提需求还是自己主动发现业务的异常波动，都要清晰的定义出来问题（可以参考SMART原则），接着拆解业务，定位问题模块，再通过不断的提出假设-数据验证的过程找到背后真正的原因，最后再通过运营或者其他方式解决问题，从而改善业务。

-END-