思步网

查看: 72726|回复: 48
打印 上一主题 下一主题

每日一问:什么是根本原因(ROOT CAUSE)?

  [复制链接]
提问:
许多时候,我不得不解释识别根本原因的过程,5个为什么是一个识别根本原因的标准方法,但是有时理解起来却是困难的,“你能说你已经找到了根本原因,如果你问更多一个为什么这样的原因时,而这种原因的解决方案超出你的解决能力之外”我这样说是正确的吗?
例如:我正在为晚到一个地方而试图找到根本原因
第一个为什么:因为我驾驶的比较慢(在我的能力内我可以驾驶的更快)
第二个为什么:我驾驶的慢因为交通流量原因(在我的能力内我可以找到另外一条路线)
第三个为什么:道路坏掉导致行使缓慢(超出我的能力)
因此,第二个原因是根本原因,这样理解正确吗

解答:
根本原因的分析方法一般采用鱼骨图,而不仅仅采用提问中的过程来进行定义和识别,因为上述案例中定义和识别的方法包含了企业对团队的授权,权力越大,则问题处理的范围越大,但并不一定是根本原因,识别根本原因有以下几点:
1.
稳定过程下,非由于人、机、料等所发现问题而识别的过程原因;
2.
一个稳定的过程基本上没有特殊原因,基本上都是根本原因;
3.
根本原因针对的对象是某一量化的过程;
4.
根本原因的解决涉及到均值和方差的变化,以及上下限可能的调整;
5.
根本原因的解决只会提升企业能力,而不会降低企业能力;


该贴已经同步到 stepoo的微博


上一篇:【讨论】如何在外包公司推行过程改进?
下一篇:高成熟度的度量怎么做?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 转播转播 分享分享 分享淘帖 支持支持 反对反对
回复 论坛版权

使用道具 举报

关于这个问题,除了根本原因,补充一个共通原因(Common Cause)和大家交流。
简单来说和根本原因对应的是表面原因,和共通原因对应的是特殊原因(Special Cause)。
所以楼主给出的例子,要找出根本原因,可以从广度和深度进行分析。从广度方面来分析,目前大家公认比较好的方法是鱼骨图,针对这个问题考虑到可能影响的因素,如本例中,可能的影响因素有车、道路、驾驶技术、天气等等,接下来再借助5个为什么来画出鱼骨图中的分支,一层一层深入,也就是从深度来进行分析。这样两种方法结合,就一定可以找到根本原因。
而共通原因就不一样,它的分析是建立在一定数据量的基础之上的。如本例中,一次晚到我们可以分析出根本原因,但无法分析共通原因,因为这个事情本身就是一个个例。但如果一个月出门三十次,其中有十几次都晚到,这时候按照上面分析根本原因的方法,针对每一次进行分析,然后把这十几次的原因进行汇总,如果发现其中有很多次原因都一样,则这样的原因就是共通原因,其中有些原因只是个例,则为特殊原因。
以上内容,欢迎交流讨论。
根本原因与共通原因,比较有意思。以前用二八图找出的都是共通原因咯~~
LZ你能不能淡定点哈~
特殊情况总是在不断的跳跃,看来还是根因没有找到
root cause!
[发帖际遇]: 黄莺于飞 捡了钱没交公 金币 降了 3 (金) . 幸运榜 / 衰神榜
确实不错,顶先
向楼主学习
very good.
看起来不错
顶不错 支持下
众里寻他千百度,蓦然回首在这里!
向楼主学习
前排支持下了哦~
打酱油的人拉,顺便赚点金币
您需要登录后才可以回帖 登录 | 注册

本版积分规则



思步组织思步科技|思步网|火花学堂|思步文库|思步问答|思步英才|天下心
© 2007 思步网 浙ICP备10212573号-4(首次备案号:浙ICP备07035264号)|邮箱:service#step365.com(将#换成@)|服务热线:0571-28827450
在线培训课程|求职招聘|思步文库|官方微信|手机APP|思步问答|微博平台|官方QQ群|交流论坛|软件工程透析|关于我们|申请友链|
点击这里给我发消息     点击这里给我发消息
思步 step365 过程改进 CMMI中文 质量保证 质量管理 流程体系 需求跟踪矩阵 敏捷开发 Scrum 软件度量 项目评审 全员改进 流程管理 人力资源 6sigma 信息安全 ISO27001认证 IT服务管理 ISO20000认证 ISO9000认证 软件测试 SQA 配置管理 IPD 软件工程 PMP认证 PMP试题 PMBOK中文 精益研发 agile 顾问式管理培训
返回顶部