编辑导读：用数据分析来指导业务问题，非常容易出现各种问题。比如数据分析指出某个早就存在的问题，却没有办法给出一个具体的解决方法，或者业务人员尝试解决无果之后，就会觉得数据分析是不可靠的。那么，怎样才能用数据分析来诊断业务问题呢？本文作者对此进行了分析，与你分享。

诊断业务问题，是很多企业对数据分析师的基础要求，也是数据分析驱动业务的三大基础方法之一。在数据分析方法里，业务问题诊断，是典型的“一看就会，一做就错”。

很多同学很苦恼：“为啥我做的问题分析，业务方不认可呢?”今天系统的解答一下。

一、常见做法

业务诊断有标准的流程：

1. 第一步：建立监控指标
2. 第二步：树立判断标准
3. 第三步：发现异常情况
4. 第四步：细分问题来源
5. 第五步：给出诊断建议

举个简单的例子：某公司有4条销售业务线，定了目标是月销1个亿，实际达成9500万，不达标。四条线表现如下图。则可以轻松看出，是A渠道出了问题（如下图）。

如果销售是线上销售，还能进一步看到转化流程，从而诊断出是哪个环节出了问题（如下图）。

于是，常见的诊断建议，就是：“发现A业务线出了问题，投放转化率太低，建议搞高”。

常规的做法即是如此。问题是，相当多的同学这么干完，会得到一句：“你说的都是废话！”的评论。感觉好冤枉。然而问题出在哪里呢？

二、常见问题

常规做法的问题，来自于：就数论数，浮于表面。这么做，就好比病人去看医生，医生说：“你的体温38度，建议搞低。”一样。你是病人，你也会拍案而起：“我TM早知道我发烧了呀！到底咋办呀！”。

单纯地罗列数据，不是问题诊断，充其量算是问题发现。

业务方期待听到的问题诊断，要指向一个：具体业务行动。还拿A公司举例子，业务方期望听到的，是如下诊断结果（如下图）。

很多做数据的同学，看到这里会脑瓜子“嗡！”的一声。这些东西太感性了，怎么和DAU、转化率、活跃率、消费金额这些指标关联起来呢？

三、解题关键

用数据驱动业务，最怕业务方说：“你行你上呀，不行别BB”。特别是用数据提出问题的时候，业务方会本能地进行反击。不是甩锅给大环境、上下游部门，就是伸手要资源，要么就祭出终极杀器：“你说的我都知道，我干过了，不行，不信你来干”。如果业务方下决心跟数据分析抬杠的话，数据分析师是非常弱势的，一定吵不赢。

因此在本质上，诊断问题，诊断的是业务方的心病。只有区分清楚谁真正愿意改进问题，才能对症下药。

区分的关键点，有四个：

1. 是否真的清楚现状
2. 是否已经采取行动
3. 是否已有行动计划
4. 是否打算申请资源

这四个关键点，能区分出业务方是否真想解决问题，以及业务方企图解决问题的方向。

在诊断业务问题的时候，可以先考虑常见做法里的结果之后，再对这四个关键点逐一确认，逐步导出诊断结果。

第一步：区分是否真清楚现状

很有可能，业务方只知道整体情况不好，并不知道具体在哪个部分出了问题。并且业务方的本能反应，也是基于整体认知给的。因此先呈现常见做法的内容，让业务方看清问题点。

如果业务方事先没有看过细节，则可能在看到细节后有解决问题的想法。基础的策略有2种（如下图），数据分析师可以补上对应的参考数据，辅助判断。到这一步，就完成了诊断。

也有可能，业务方已知晓细节，那就进入下一步。

第二步：区分是否已采取行动

注意，已采取行动但没见效，和没采取行动，完全是两个状态。如果业务方还没有采取行动，就值得怀疑：“为啥明明看到问题，却不行动？？？”

很有可能，业务方认为问题不重要，到时候就自然消失了。

很有可能，业务方已有安排，认为到时候能一举扭转乾坤。

此时，可以对历史数据进行复盘，找类似场景，有复盘结论后，再针对当前情况下判断（如下图）。

这种情况尚且容易处理，因为业务方没有计划的时候，对其他人的提醒/建议不会很激烈反对，真正难处理的是：已采取行动但没见效的场合。

此时，提给业务方的诊断结论，最好是他们从来没听过且非常有效的，不然铁定被人按着头怼：“你这说的都有啥用！老子刚试过了呀！”这时候下结论要特别小心。

第三步：区分是否有行动计划

已采取行动未见效的时候，业务方的本能反应就是：要资源。打仗打不赢，要大号的炮弹，是很正常的思路。

但老板本能反应就是：再想想。一定是你的方法不对，不信我换李云龙上肯定能把山崎大队打下来。

这种反差，使得直接申请资源的计划常常被驳回。如果申请不到资源，业务部门还有可能选择甩锅，不管是谁的问题，反正不是我的问题就行。

此时对于数据分析师来说，问题异常复杂。如果数据分析师贸然表态，很有可能被划入“敌对分子”的范畴，之后不管数据分析师再说什么，人家都会单纯地为了反对而反对。所以这时切忌主动表态。而是提前把可能解决问题/甩锅的选项分析清楚，最后交回给业务/老板评判。

常见的甩锅选项，如：

• 甩锅给外部环境：是否大环境真的变差，影响了所有业务线
• 甩锅给上游部门：是否上游部门真的没做好，所有下游都遭殃
• 甩锅给用户：是否真的某类型用户口味变化，集体流失

常见的解决问题选项，如：

• 上次解决类似问题的方法，本次是否已经用了
• 上次解决方法的投入力度，本次是否已经达到
• 其他业务线，是否有解决问题的类似方法

以上每一点，单独拆出来都是一个专题分析，内容太多，这里不一一举例了。但是想要帮助深陷困境的业务部门真正找到出路，是值得多花些精力的。

或者采用一种简单的方法：标杆分析法。挑出可以复制的标杆，直接对着照抄。这样省事很多。这也是为啥要先介绍标杆分析法，再介绍问题诊断的原因。有些业务部门就是懒得听理论，他们喜欢说：“你直接告诉我谁做的好，我抄他就完了，奥力给！”

四、小结

从本质上看，问题诊断之所难，难在两端：

• 行业环境、业务能力、用户口味、操作流程等等因素，都会导致业务上问题，但这些因素大多不能用数据量化，只能一个个细细立假设，做检验。
• 出现问题的时候，大家都怕担责任，因此会本能地找借口、想当然、树立场。然后纯粹因为立场不同而相互攻击，拒绝面对真相。

所谓“屋漏偏逢连夜雨”，就是这个局面。此时，想要用数据描述问题，容易，树个标杆就能看出差距。想用数据诊断问题，就得突破上边层层险阻，争取业务的支持和老板的理解，才能见效。这是从数据到落地的必经之路。

那有没有简单轻松的落地方法呢？当然有！最简单的就是业务/数据/老板说：“我有一个好点子！”。既然已经有好点子了，那可以直接检验效果，是所谓数据实验法，下一篇来分享，敬请期待哦。

#专栏作家#

接地气的陈老师，微信公众号：接地气学堂，人人都是产品经理专栏作家。资深咨询顾问，在互联网，金融，快消，零售，耐用，美容等15个行业有丰富数据相关经验。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议。