说起数据分析面试,恐怕对于求职者来说,最难的就是考察业务知识的部分,其他知识都容易恶补,业务知识从哪学呢?业务经验真是一个世纪难题啊!
别急,今天这篇文章就帮大家科普一下,业务分析(不是数据分析)的一些知识;
这些知识是我在面试新人时最常问的概念性问题,它能最快速度帮我判断对方的业务经验基础。
业务分析与数据分析的区别
首先我们都说业务分析、业务分析,它一定是业务与分析两个部分的内容。
我之前介绍过数据分析的流程,可以用五个关键词来表示,分别是“目的”—“采集”—“清洗加工”—“可视化”—“业务价值”;
每个关键词都一一对应着数据分析流程当中的具体工作,分别是:“需求层”—“数据采集层”—“数据层”—“数据处理层”—“输出层”。
这是一般来说我们进行数据分析的五个关键步骤,不管你是做纯粹的数据分析,还是偏业务的分析,还是商业分析,基本原则是要按照这五个关键点出发的。
但是!
很多人在遇到真实的业务场景的时候,就会发现这套流程根本没有作用,这是因为什么呢?
因为实际的业务需求不仅是复杂的,而且是无序混乱的,按照我们习惯性的思维是很难去解决无序问题的,什么意思呢?
小时候我们都写过试卷,在试卷上的问题都是什么样的呢?
小明有十颗糖,上学的路上遇到了小红和小刚、小亮,给了小红三个,给了小刚两个,给了小亮一个,请问最后小明有几颗糖?
这就是我们从小时候就养成的思维方式,根据已经有的题干进行分析,因为我们的大脑会习惯性地依赖某个思维框架或者模式去分析问题,慢慢地大家都习惯地认为真正的业务问题也是有框架的、有模式的。
也就是说,大家都习惯在有提示的迷宫中寻找出口。
那么真正的业务问题应该是什么样子的呢?
小明一开始有十颗糖,上学的路上遇到了小红和小刚、小亮,请问最后小明剩下了几颗糖?
如果大家是在试卷上看到这样一道题目,大家肯定要骂娘了,这题干根本就不明确,连必要的信息都没有,你让我怎么解答?
这就是理论问题与实际业务问题的区别了!
真正的业务问题是没有题干的,是无序的,是混乱的,是复杂的,大家是站在一片迷雾当中寻找出口,所以大家会觉得无所适从。
那么怎么去克服这种依赖性思维方式呢?
最好的办法就是通过不断练习,尝试建立起自己的思维体系,任何问题放到思维框架中都可以得到解决,因此这个框架也就是分析思路。
业务分析的流程
想要搞清楚业务分析的流程,记住6个关键词就可以了,这也是业务分析报告的主要组成部分:场景——需求——问题——指标——结论——验证
这是我们进行业务分析流程的主要思路,首先我们确定分析场景是什么,然后将场景转化为需求,这时候我们需要建立需求文档;
有了需求,下一步就是梳理出业务问题是什么,业务问题往往不是单一的,而是复杂的,因此需要确立问题梳理的方法,这时候我们就需要利用指标体系;
通过指标体系进行数据分析的流程,每一个体系都可能做一次完整的数据分析,最终将所有分析形成一套业务方案,也就是业务结论;
这时候我们的工作还没有做完,因为业务分析的最后一步是需要将业务方案进行落地,或是配合的角色,或是主导的角色,总之要监督、跟踪并指导业务方案的实施。
1、诊断现状:
业务场景往往都是复杂的,我们需要准确判断业务问题的具体场景是什么,这里要包含三个要素:对象、关注点、目标
对象:场景中包含的分析对象,是分析人、物,还是企业、经济、财务、销售、用户等分类?
关注点:不同的对象侧重点不同,不能面面俱到,只能优先分析重点内容;
目标:分析要达到什么目的,是想发现问题,还是诊断现状,还是预测?
比如说,业务想让你分析一下最近的销售情况,这是一个相当复杂的场景,我们怎么进行梳理呢?
对象:对象是销售,也就是与销售直接相关的要素,最主要的是销售员、销售数据,因此我们主要是做销售收入、销售额、单价等与销售情况直接相关的分析。
目标:一般是完成销售任务,监控销售销量低的原因,提出解决方法;
关注点:销售与运营分析差不多,但是分析颗粒更细,频次更密,要求速度更快,所以主要关注时序进度、落后原因、销售单产情况;
2、需求文档:
下一步是将场景转化为需求,这时候我们需要做需求可行性文档,我们在进行分析之前,首先要搞清楚三件事:这个需求是什么?这件事值不值得做?这件事需要做到什么程度?
具体内容比较多,下一篇文章再详细介绍这一部分的内容!
3、梳理问题
确认了需求之后,我们要将需求转化为问题,也就是我们要分析什么东西、分析什么问题、分析什么内容,这里就不详细讲了。
4、建立指标
这是业务分析最困难的地方,这里我推崇两个方法去建立指标体系,一是点线面法,二是流程环节法,这里我以流程法举例:
我们按照如下框架梳理业务流程,首先是中间主要流程层,指某人通过某些流程步骤达到特定的目标;
在业务流程的具体步骤中,每个节点会做哪些事情,具体做到什么程度,即如何在业务流程中如何管理,我们称之为业务层;
在每个管理过程中,我们记录事件,对管理过程的事件进行量化,我们称之为数据层。
5、业务方案:
常理推断,当业务接到一个改进方案A的时候,脑海中浮现的问题是什么?
A是怎么解决我的问题的?
为什么A比B要好?好在哪些业务指标上?好多少?是否可持续可测量?
需要我做什么和现在不一样的事情?
也就是当我们着眼于业务的问题,提出解决方案的时候,第二步就是解决业务的后顾之忧。我们需要在方案中把业务关心的这些问题一并解决,告诉他们这么做了以后会有什么好处。
6、落地实施
做到前两步以后,基本上你的建议是可以落地了,但我的习惯是再加上最后一步:不断“跟踪”进行监测甚至迭代。
其实,这一步和上一步联系非常紧密。有些数据分析的同学会把建议甩给业务,业务接受以后自己就不管了。
但其实我很享受近距离观察自己的建议落地,并且持续监测各大指标,和业务一起优化的过程。当看到各项指标提升的时候,真的非常有成就感。
另外,当我们的建议被市场和用户证明了是有价值的以后,我们和业务之间的信任度就会提升非常多,那我们以后的方案再落地也会容易的多。
数据分析 BI
原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/173284.html