CMMI on line

做中国最专业的CMMI网站!
欢迎光临 CMMI on line 登录 | 注册 | 帮助
in 搜索

原因分析及解决方案(Causal Analysis and Resolution)

本主题共有 3 篇回复,最新回复发表于 01-31-2008, 22:25,作者 zhangcb
帖子排序: 上一主题 下一主题
  •  01-04-2007, 1:19 303

    Yes [Y] 原因分析及解决方案(Causal Analysis and Resolution)

    聪明的人在出现问题的时候,除了解决问题外,都会想到如何避免问题以后再次发生,避免的办法可能是从过程或者技术两个方面入手,从根本杜绝问题的发生。

    问题分析是很常见的,为什么在5级的时候才有这样的要求呢?难道23级的企业,甚至是没有级别的企业,就不会做问题分析并防止问题再次发生吗?

     

    5级的这个CAR没有这么简单的,如果要通过5级这个CAR的评估,就必须做到:必须有证据证明原因分析改善了公共原因,让企业的性能基线有所提高。也就是说要对公共原因进行原因分析,并有实际的改善效果,让企业更有能力,而且最好有过程及技术方面的原因分析证据。这些都是在4级的基础上的进一步要求。

     

    SG1 Root cause of defects and other problems are systematically determined.

    系统地决定要进行原因分析的缺陷和问题。

    要进行“刨根究底式”的原因分析成本是比较高的,企业没有必要全部问题都需要做到以后杜绝再次发生的层次,但企业要选择有价值的问题进行这种分析,这些问题的改善对提高企业过程能力、实现企业商业目标是非常有用的。

     

    SP1.1 Select the defects and other problems for analysis.

    选择要进行分析的缺陷和问题。

     

    SP1.2 Perform causal analysis of selected defects and other problems and propose actions to address them.

    对选择的缺陷和问题进行原因分析,并提出相应的建议以避免问题再次发生。

     

    SG2 Root causes of defects and other problems are systemmatically addressed to prevent their future occurrence.

    系统地分析缺陷和问题,找到它们产生的根源,并阻止它们将来再次发生。

     

    SP2.1 Implement the selected action proposals that were developed in causal analysis.

    实施在原因分析中提出来的改进建议。

    在原因分析过程中,会提出一些防止这些问题再次发生的建议,实施这些建议。

     

    SP2.2 Evaluate the effect of changes on process performance.

    评估在过程性能方面这些改变的影响。

    SP2.1实施改进建议,SP2.2就是评估实施这些建议的影响。

     

    SP2.3 Record causal analysis and resolution data for use across the project and organization.

    记录原因分析及解决方案方面的数据,这些数据用于项目及组织。

    记录CAR过程中所有有用的数据,并把这些数据用来指导项目及组织的工作。


    CMMIonline 版权所有
    欢迎转载,但请给出指向本网站的链接:
    http://www.cmmionline.net
    版权声明见:
    http://cmmionline.net/forums/thread/1340.aspx
  •  01-26-2007, 14:04 319 回复至 303

    回复: 原因分析及解决方案(Causal Analysis and Resolution)

     请问楼主有此过程相关的模板吗?

    • 帖子点数:0
  •  01-31-2008, 21:04 1548 回复至 303

    回复: 原因分析及解决方案(Causal Analysis and Resolution)

    楼主,我们现在正在做这部分。但我发现找到根源比较困难。项目上的一帮人坐下来,分析发生的缺陷,常常就把问题归结到培训,业务不熟,能力不够。我们也曾试图使用4F鱼骨图来找根本原因,发现效果也不好,多数时候流于形式。不知道楼主怎么看这个问题?

  •  01-31-2008, 22:25 1549 回复至 1548

    回复: 原因分析及解决方案(Causal Analysis and Resolution)

    这情况很常见,我们也有类似这样的情况,我们有一套问题分析指南,有什么头脑风暴发、树形分解法、鱼骨头法、二八原则等等的方法,但要用好这些方法而找出问题真正之根源,还是很难!

    对于这个问题,我也思考了很久,有几点感想:
    1.要确认大家分析时,是不是态度认真,并且竭尽全力了?不是为了应付。
    2.分析是需要经验积累的,不能光有那些理论化的分析方法,需要一些实际的业务数据、案例,大家看了这些成功经验,才更有可能举一反三地发现当前的问题。
    3.发现问题能力,还依赖于分析者掌握的知识面和经验,尽管我们有经验库这些资产,但还是不能替代分析者自己本身的知识、经验和能力。

    培训不足、业务不熟、能力不够这些,其实常常不是问题的根源,如何从过程上来杜绝,很需要分析者的智慧。我们前段时间,我策划了两方面的过程改进来改善我们的过程,降低过程对人的能力的依赖:
    1.对业务的理解。以前我指望大家按照需求过程,来熟悉业务,但发现大家水平还是达不到要求,于是我集中业务比较熟悉的人,重新整改公司各核心产品的用户文档,将业务描述清楚,以后大家依照这个文档来工作。这样大家的业务水平得到比较好的提高。
    2.对设计要求的提高。我们采用统一的架构,和共用组件,来降低大家的编码难度,让大家更加集中精力去解决业务问题。这样工作量减少了,也能提高代码的质量。

    其实这两个改进,都会让过程对人的依赖降低,因为我们用过程将业务高手和设计高手的智慧“固化”并让项目组“重用”了。

    以上供参考,其实我也做得很不足,还需要继续学习,增加知识,知识不够,很多事情做不了。


    CMMIonline 版权所有
    欢迎转载,但请给出指向本网站的链接:
    http://www.cmmionline.net
    版权声明见:
    http://cmmionline.net/forums/thread/1340.aspx
以 XML 格式显示 RSS 新闻频道
CMMI on line 版权所有 ( 粤IC备07073557号)
Powered by Community Server, by Telligent Systems