您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
数据分析必备思维之结构思维
 
 
 
  1581  次浏览      16
2021-1-21
 
编辑推荐:
本文主要讲解了数据分析必备思维之结构思维的工具之一逻辑树的三种类型,分别是:问题树、假设树、是否树。
本文来自三元方差 ,由火龙果软件Linda编辑、推荐。

结构化分析的主要工具之一是逻辑树。这是麦肯锡公司的咨询顾问分析问题时最常使用的工具。

逻辑树有三种类型,分别是:问题树、假设树、是否树。

问题树也有翻译成议题树的。网上搜索逻辑树一般会默认是问题树,往往忽略了后两种。

这三种逻辑树结构类似,但是有不同的使用前提,合理的使用它们,对于我们分析问题和制定解决方案能起到事半功倍的效果。

问题树

当对问题不了解 ,或者需要对问题进行全面的分解以确保不遗漏任何一个方面时,可以使用问题树。即:在解决问题的初始阶段使用问题树。

问题树的结构如下:

MECE原则

问题的同一层级必须遵循MECE原则。

MECE(MutuallyExclusive,CollectivelyExhaustive)的意思是“相互独立,完全穷尽”,发音是me see。

在思考问题的过程中,我们需要将问题进行分解,每一层级的问题与问题之间没有重复、交叉、相关性,就是“相互独立”,而每一层级中务必不出现遗漏,就是“完全穷尽”。

这个原理比较容易理解,不多说。

如何建立问题树

建立问题树有两种方式,一种是自上而下,一种是自下而上。

1. 自上而下做分解

比如我们要完成100万元的业绩,可以从哪些方面入手呢?

因为销售的最终目标是客户,所以我们可以将客户分类,对不同的客户群体采用不同的营销方式。

根据MECE原则,客户无非是三种:

陌生的新用户

正在跟进的用户

已经购买的老用户因此,我们可以在逻辑树的第一层,划分这样三个类别。

根据业务常识,销售额=流量×转化率×客单价。所以我们在三个群体下分别有三种策略。

根据上述的策略,再往每一个子分类中添加具体的对策。

这样经过一层层的演绎推理,最终形成了一个问题树。我们将一个大问题拆解成了一个个可执行的小问题。

其中,第一层的分类最重要,它决定了你整个结构的整体功能。

不过这个分解方式没有标准答案,你在运用的过程中,得根据实际问题,找到对问题的解决最直接有效的切分方式,比如:

侧重于分而治之的,可以按空间维度进行分类:新客户、跟进中客户、老客户;或者业务A、业务B、业务C

侧重于进度把控的,可以按时间维度进行分类:第一个月、第二个月、第三个月

侧重于战略聚焦的,可以按重要程度进行分类:机构客户、普通客户

侧重于目标达成的,可以按演绎逻辑进行分类:流量、转化率、客单价、复购率

资深分析师相比新手分析师,最大的区别就在于能够找到更好的分类维度。这种差距是业务思维上的差别,我将在之后的文章再详细解读,本文不做深入。

2. 自下而上做聚合

自上而下演绎法的好处是效率高,可以很快速地就把问题结构化。

可是,这种方式有个前提,就是你得对问题的解决方法有深刻的理解,能够快速找到恰当的分解角度,或者大脑中已经有了现成的结构可以直接使用,比如:销售额=流量×转化率×客单价。

如果没有现成的结构,或者找不到分解的角度怎么办?你可以尝试使用“归纳法”自下而上地提炼结构。具体怎么做?

第一步:收集信息。在这一步,我们把所有收集到的信息,都一条一条地罗列出来。

第二步:分类。在这个环节中,我们要按信息的属性、特点进行归类,确保在同一组的信息都属于同一个范畴。

第三步:概括总结。在这个环节中,我们要根据每个分类的特点,给每个分类写一个具备总结功能的标题。举个例子:

比如想要销售额提升一倍,怎么办呢?

如果你没有对业务的整体认知,那么可以召集团队成员,一起开个头脑风暴会议,大家一起想一想有什么方法。

经过激烈的头脑风暴会议,大家列举出了很多的想法:

约客户吃饭

请客户喝咖啡

陌生拜访

公众号合作

电商合作

老客户回访

挖掘新用户

线下活动

……

这些信息杂乱无序,我们进入第二步分类,用归纳法把类型相同的信息分成一类。

比如电商合作、公众号合作、线下活动属于渠道类,请客户吃饭、请客户喝咖啡等属于沟通类。陌生拜访又属于挖掘新用户下面的一种方式。然后是第三步概括总结。渠道类里,电商和公众号属于线上渠道,线下活动属于线下渠道。

经过这样的梳理分类逐渐清晰。然后再根据每个分类下的情况,删除重复的内容,增加缺少的内容。

比如用户类型里有挖掘新用户、老客户回访,因此需要增加一个跟进中用户。

但到了这一步还没有完,我们依然要遵循MECE原则。

这样的分类,有渠道、有沟通方式,还有用户类型。用户类型明显和前天类型不是同一个维度的内容。所以我们可以选择把用户类型放到上一层。

最终通过自下而上,构建了一个和之前类似的逻辑树。

自上而下和自下而上,到底哪种方法比较好?要看不同的的情况。

自上而下适合我们的目标特别明确的时候。比如你参加竞聘,这时你的目标就非常明确,一定是从上往下搭建结构会更好。

自下而上适合我们没有目标的时候,比如年底写工作总结的时候,一开始往往不知道怎么归类。那就把一月至十二月所有的事情列出来,然后按照你的工作内容进行分类,之后再将每个类别概括出一个结构,最后再将这些结论往上概括出一个总结论来,便完成了金字塔结构的搭建。

但是,在实际工作中,不太可能只用一种方法就把结构建完,一定是两种方法同时使用。

假设树

当你对问题已经有了较为充足的了解时,可以用假设树分析问题。

假设树是针对问题提出了某种假设的解决方案,需要验证假设是否成立时的使用方法。换句话说,假设树用于验证假设。

假设树的结构如下:

对于某种假设方案,只有当所有论点都支持该方案时,该假设方案可以得到验证,否则会被推翻。对于每一个论点同样可以进行分解,直至分解到可以被基本假设证实或证伪。

假如需要针对X公司制定“提高销量”的方案,我们在了解了公司各方面的情况之后,觉得该公司可能可以通过研发新品来获得销量提升,遂绕过问题树的方法,直接提出“X公司应该研发新产品”这一假设。为了验证假设是否成立,则可以构建如下假设树。

只要我们将第三层次的7个论点进行验证,就可以证明“X公司应该研发新产品”这一假设是否合理。

这种方式实际上就是对问题先做演绎或者归纳,列举出前提或者是论据,然后用数据验证这个推理是否正确。

假设树这种分析方式相比问题树效率更高。假设树针对问题所提出的假设,不用将问题的所有方面都考虑到,只要能够验证假设合理或者不合理即可,这是其与问题树最大的不同,加快解决问题的进程。

不过还是那个问题,怎么建立假设?一个问题究竟如何提出正确的假设?在看到让X公司“提升销量”的问题时,为什么要提出“X应该研发新产品这样一个假设”,而不是“增加销售渠道”?

这个问题依然还是业务思维的范畴。

是否树

是否树相比假设树还要更简单。

是否树的主要形式是:先提出一个问题,然后对这一问题进行是否判断,分析的结果只能是“是”或者“否”,然后接着进行下一轮判断分析,继续得出分析结果“是”或者“否”。

是否树的结构如下:

在使用是否树进行分析前,对一些结果应已有标准方案。如果答案为“是”,就可以应用实现准备好的标准方案。如果答案为“否”,那就需要再进行下一轮的判断分析,对具体情况进行具体分析,根据结果确定解决方案。

比如,以下是分析产品战略的一个简单的是否树:

通过图中的分析,根据不同的结果,就能够确认最终合适的方案是哪一个。

三种树的使用场景

最后,说一下三种逻辑树的区别和其适用的场景进行简单的分析。

问题的初始阶段,尚不明确具体情况,需要对问题进行全盘分析时,使用问题树

对问题已经有一定了解了,并且有了一种假设方案,对假设方案进行验证,使用假设树

对问题不仅足够了解,且针对一些结果已经有了标准方案,需要在方案中进行选择时,使用假设树。

使用逻辑树有以下优点:

通过“树干”和“树枝”的搭建,找出问题的所有相关项,以此确保问题获得完整的解决

通过问题与问题的关联,识别哪些是必须的,哪些是证明前提假设的重点

个人使用时能帮助理清思路,将大问题分解为利于操作和解决的小问题

团队使用时,能将大问题分解为小问题再落实到个人,避免责任不清。

总 结

以上这些方法看起来平平无奇,似乎都是我们生活中部分觉知和使用的。麦肯锡最厉害的地方在于,把我们习以为常、自动化思维的做法,经过提炼和梳理,形成系统化的方法论。

严格执行这些方法论,可以消除不确定性,让结果稳定、可靠、可达预期。即使是一个刚毕业的大学生,按照方法论分析的结果也不会差到哪里去。

以上是解决问题的基本思维结构,很多的分析模型都是建立在这几个结构之上。

比如矩阵模型,实际上就是通过2×2的矩阵列举出MECE的四种情况,算是问题树的另一种表现形式。

为什么我不一上来就直接写矩阵分析、漏斗分析这类分析工具。因为如果不把这些更底层的东西说出来,很多人不懂得什么时候用什么工具,也不懂得工具如何变通。

工具是思维的延伸,不改变思维,就算掌握了正确的工具也未必能得出正确的结果。

 
   
1581 次浏览       16
相关文章

基于EA的数据库建模
数据流建模(EA指南)
“数据湖”:概念、特征、架构与案例
在线商城数据库系统设计 思路+效果
 
相关文档

Greenplum数据库基础培训
MySQL5.1性能优化方案
某电商数据中台架构实践
MySQL高扩展架构设计
相关课程

数据治理、数据架构及数据标准
MongoDB实战课程
并发、大容量、高性能数据库设计与优化
PostgreSQL数据库实战培训
最新课程计划
信息架构建模(基于UML+EA)3-21[北京]
软件架构设计师 3-21[北京]
图数据库与知识图谱 3-25[北京]
业务架构设计 4-11[北京]
SysML和EA系统设计与建模 4-22[北京]
DoDAF规范、模型与实例 5-23[北京]
 
最新文章
大数据平台下的数据治理
如何设计实时数据平台(技术篇)
大数据资产管理总体框架概述
Kafka架构和原理
ELK多种架构及优劣
最新课程
大数据平台搭建与高性能计算
大数据平台架构与应用实战
大数据系统运维
大数据分析与管理
Python及数据分析
更多...   
成功案例
某通信设备企业 Python数据分析与挖掘
某银行 人工智能+Python+大数据
北京 Python及数据分析
神龙汽车 大数据技术平台-Hadoop
中国电信 大数据时代与现代企业的数据化运营实践
更多...