7.1 业务数据分析 - 图1

1. 业务分析流程

1.1 业务分析与数据分析的区别

数据分析 业务分析
惯性思维：有框架、有模式、有指引
image.png		 业务思维：无序的、混乱的、未知的
image.png
上帝视角
image.png		 迷雾视角
image.png

1.2 业务分析的流程

image.png

  • 分析思路

“场景、需求、问题”三个关键词对应着“业务”，也就是说业务分析的第一步是将模糊的场景转化为具体需求，再将需求转化为具体的问题。
“指标、结论、验证”三个关键词对应着“分析”，与数据分析是一致的，即根据问题建立指标体系，通过对指标的分析得到结论，再使用其他的数据去验证这个结论。

  • 分析过程

诊断现状：虽然场景是模糊的，但是可以用一些标准去衡量场景。
需求文档：即需求可行性文档（后面介绍）。
梳理问题：根据需求文档去梳理其中的问题。
指标体系：根据梳理出来的问题，建立完善的指标体系。
业务方案：也就是数据分析的流程，包括目标确定、数据采集、数据清洗、数据处理、数据可视化。
落地实施：制定完业务方案后，并不是就结束了，还要关注方案的落地实施（后面介绍）。

撰写业务分析报告时，就可参考以上分析过程的6个步骤来成文。

1.3 诊断现状-需求文档-梳理问题

诊断现状：对场景的衡量，一般有3点，对象、关注点、目标。比如经营类的业务分析，对象是收入、毛利额、销量等，关注点是收入、毛利额、销量的变化情况、变化趋势、地区分布等，目标是发现企业经营过程中的问题。

需求文档：通过与业务的沟通确认，得到一些关键问题的答案，由此建立需求文档，评估需求的可行性。

类别 解释
核心目的 想实现什么目标？
定位问题 出现了什么问题？
逻辑关系 目的与问题存在什么样的逻辑关系？
场景拆解 分析内容是什么？
效果验收 需要做到什么程度？
预案时间 需要什么时候完成？
成本控制 需要花费多大的成本？
价值性 投入产出比多大？

1.4 建立指标-方案设计-落地实施

image.png
建立指标：有两种思路，点线面法和流程法（后面细说）。
方案设计：业务拿到分析方案时，基本上会问以下3个问题，所以设计方案时也要从这3个角度出发

  • how：怎么解决我的问题？
  • what：需要我做什么工作？
  • why：为什么A方案比B方案好？

落地实施：有时数据分析师做完方案后就抛给了业务，业务也可能将方案搁置了，或者业务看到方案时会有自己的理解，所以我们要帮助业务弄明白方案的真正意义。方案实施的过程中需要不断检测指标，发现不完善的地方需要跟业务一起去迭代优化流程。

2. 指标体系建立

2.1 点线面体(OMTM)

image.png
点线面体法详见：https://www.yuque.com/mengxiangjiaharry/data_analytics/uqyxtz#VcN4H
点线面体法核心：拆解指标。详见https://www.yuque.com/mengxiangjiaharry/data_analytics/blyl6t#DGvuu

2.2 流程法：业务环节

第一步：梳理业务流程
以举办一次促销活动为例
image.png

  1. 流程层：先建立流程层，按照顺序梳理出业务的整体流程。比如一次活动的业务流程为：活动准备、宣传推广、现场管理、转化促销。
  2. 业务层：根据流程层，整理出每一个流程中所包含的业务动作，也就是业务层。比如，“活动准备”的业务包括商品准备、人员准备、奖品准备等；“宣传推广”的业务包括线上推广、线下推广等；“现场管理”的业务包括现场分工、活动流程等；“转化促销”的业务包括转化设计、销售等。
  3. 数据层：根据业务层，整理衡量业务的指标，即数据层。比如，“商品准备”时需要知道商品的成本、库存量；“奖品准备”时，需要知道奖品的预算成本；为了衡量“线上推广”，需要知道广告单价、广告成本、广告产出。

另一种拆解方式是按照公司架构进行拆解，适用于拆解KPI，如下所示
image.png

  1. 公司层：供应链 -> 市场 -> 销售 -> 运营
  2. 部门层：以“销售部门”为例，部门层的流程可拆解为销售团队、销售过程……完成交易
  3. 个人层：以“销售部门的销售过程”为例，个人层的流程可拆解为电话邀约、客户拜访……下单


第二步：量化业务流程**
一定要确保业务层的指标数据能够完全覆盖业务层的内容。这里也需要多跟业务沟通，了解他们的KPI，数据指标与KPI挂钩，帮助业务更好地完成KPI，才能让数据分析结果更好地落地。
image.png

3. 业务需求落地

3.1 为什么业务需求无法落地？

  1. 不切实际的需求

关键点在于业务人员和数据人员的思考方式不同。业务人员是从问题出发，追溯到现状，数据人员是从现状出发，回归到问题。
业务人员只关心问题能否被解决，没有考虑解决问题的投入产出比，所以有些需求可能会很离谱。数据人员要从实际出发，过滤掉投入很大，但产出很低的需求。什么样的需求可以做？什么样的需求无法做？什么样的需求现在不能做，后续可以做？需要与业务定义一个标准，明确需求的可行性。

  1. 需求模糊

如果不说清楚，那么最终的分析往往得不到业务的认同。
image.png
这时就需要用到“需求可行性文档”，与业务定义清楚可行性的标准。

3.2 需求可行性文档

跟业务人员一起填表，有些不切实际的需求在填表的过程中就会被过滤，而模糊的需求也会变得明确，最终的分析结果也更容易得到业务的认可。

类别 解释 内容
核心目的 想实现什么目标？ 提高复购率
定位问题 出现了什么问题？ 新客户的获客成本太大，增加了10%
逻辑关系 目的与问题是否存在逻辑关系？ 复购率能否降低获客成本？
场景拆解 分析内容是什么？ 复购率与会员体系、商品、活动等有关
效果验收 需要做到什么程度？ 将复购率提高10%
预案时间 需要什么时候完成？ 月底之前
成本控制 需要花费多大成本？ 优化成本在10w以内
价值性 投入产出比多大？ 投入产出比较高

3.3 数据人员的问题解决能力

需求无法落地，还有一个问题是数据人员解决问题的能力不行，常见的几种问题是：

  1. 结论满满当当，却根本不符合业务
  2. 徒有分析，半天写不出一条建议
  3. 分析过程不严谨，错误漏洞百出

针对这几种问题，对应的解决方案

  1. 结论满满当当，却根本不符合业务
    1. 符合业务实际
    2. 梳理业务流程
    3. 业务知识学习
  2. 徒有分析，半天写不出一条建议
    1. 业务知识学习
    2. 目标思维导向
  3. 分析过程不严谨，错误漏洞百出
    1. 重推理，轻归纳
    2. 重逻辑关系
    3. 数据准确性
    4. 统计学基础扎实