你的位置: 首页 > 培训资讯首页 > 文章详情

如何减少研发过程返工

作者: 任传宏  上传时间:2015-09-08  浏览:22
两年前与一家企业(A企业)交流时,他们的企业负责人说:我的产品开发返工太多,一个小产品也要折腾3-4次,严重影响了上市计划;研发负责人也在向我们诉苦:其实我们也不想改来改去,可市场的需求不停的在改,我们也没办法,再说了,我们改来改去,也是为了产品更好卖啊;供应链负责人则向我们抱怨:研发交付的样品问题一大堆,我们简直没法生产。不是缺了某个技术图纸、就是图纸不是最新的,或者图纸标注错误;不是缺了某个物料、一等好几天,就是我们的工艺根本就没法生产……我们虽然多次向他们反映,可我们开发人员却总是不以为然,他们甚至认为这些问题都是“小问题”,不要小题大做,可正是由于太多的这样“小问题”重复的、经常的出现,新产品多的时候,搞得我们无法正常生产,货期经常延期。为了进一步了解A企业产品开发经常返工的问题,我们进行了深入的调研,经过2周的调研分析,我们发现,A企业产品开发过程中的返工可以归纳为以下五大类:1、  由于一些“小问题”而返工。例如:产品图纸/技术文档不是最新的、图纸/技术文档标注错误等;2、  由于需求不明确而返工。例如:产品图纸/技术文档里忘记说明器件或配件/物料的装配工艺,而靠下游的打样人员根据自己的经验去判断,结果往往会导致样品与开发人员要求不一致而返工;3、  由于遗漏某方面的需求分析(如“条件限制”)而返工。例如,由于工艺条件达不到,而返工,由于采购不到需要的器件,而返工,由于超目标成本而返工;4、  由于需求更改而返工。例如:销售人员突然反馈说,这款产品需要增加一个新功能或者成本太高等;5、  由于设计错误,导致产品功能不符合要求而返工。上述五类问题中,出现较多的是第一类和第二类问题,接下来次多的是第三及第四类,第五类问题较少。为了减少返工,我们对上述五类问题产生的原因分别进行了分析,分析发现:1、  由于产品开发人员忽视技术文档以及不良的工作习惯(比如粗心),导致经常出现“小问题”;2、  由于上下游之间缺乏明确的输入及输出要求,凭经验办事,经常造成需求不明确或需求理解错误,而引起返工;3、  由于缺乏对需求的全面理解和需求分解工具,造成在进行需求分析时仅仅考虑功能、性能等技术性需求,而忽视或遗漏了成本、可采购性需求、可制造性需求等“限制性需求”或“内部需求”。4、  造成需求更改的主要原因有两类,一是在前期需求分析时,由于缺乏系统的希求分析工具或投入不够,而遗漏了部分需求,比如易用性、成本等,另外一类是由于对市场及产品缺乏系统的规划,只能被动的由市场或客户牵着鼻子走。5、  造成设计错误的原因主要是由于经验不足。从上述的问题原因分析中,我们可以发现,造成产品开发过程中返工多的原因虽然是多方面的,但是通过统计归类,我们发现主要是以下三个层面:1、  认识层面:对产品开发的可管理性及系统性缺乏理解。造成第一、三、四类问题的原因中,有很多就是属于对产品开发管理认识不到位的原因。2、  工作方法层面:缺乏明确的、可操作的开发过程指导。开发过程过于粗放,甚至关键活动的输入、输出都不明确。不同的人做同一件事情,有不同的做法,甚至同一个人都同一件事情也有不同的做法,结果相差很大。“同一个方案/样品,今天评审没有通过,明天重新评审一下就可以通过了,这是常有的事情”。一位研发经理如是说。造成第二类问题的原因就是很典型的属于工作方法层面的问题。3、  工具层面:产品开发过程缺乏专业、系统缺的工作工具(主要是非技术方面的工具,例如需求分析方法及工具、评审方法及工具等)。针对每类问题出现的频率以及问题产生的原因,我们采取了不同的解决策略及方法,并从认识、工作方法及工具层面进行系统的改进。在认识层面,我们对产品开发团队(不仅仅是技术人员,包括市场、采购、工艺等与产品开发相关的职能代表)及业务骨干进行了研发管理体系、研发流程、研发项目管理、研发人员职业素养等培训,通过系统的培养,研发团队及相关业务骨干,特别是中高层团队对产品开的跨部门协同性、系统性以及可管理性有了较深入的认识,对树立跨部门协作的流程意识起了表率作用。“真没有想到自己的一个‘小问题’会给下游部门带去那么多的麻烦及工作量,以后的工作中,我们将争取杜绝‘小问题’”。培训后他们的一位研发负责人这样感慨到。在工作方法层面,首先,我们优化了市场与产品规划流程,把以前市场与研发各做各的规划统一起来一起考虑,以避免研发与市场脱节,同时也可以让研发更好的理解市场、理解需求,减少需求变更。为了减少客户的需求变更,除了提高需求分析的质量外,我们还建议加强对客户需求的管理及引导,这就需要我们对客户的业务或市场有较强的前瞻性,为此建议对业务专家的招聘与培养提升到战略高度。其次,我们产品开发流程、及其相关子流程进行了优化,明确了每个阶段的输入及输出和关键控制点。并重点对产品开发流程中的关键活动(如需求分析、测试、评审等)进行了优化,对关键活动从输入、输出、执行活动的角色职责与能力要求、活动的操作方法及工具等方面进行了细化(如需求分析子流程、原始需求收集操作指导书、需求评审要素表等),从而保障关键活动的需求明确、执行步骤明了、执行人的职责清晰、操作方法及工具清晰,避免由于需求不明、活动缺失或模糊而导致的返工。对经常发生返工的环节,设置了监控点,进行自检或互检,然后再进行子评审,子评审通过后提交到项目组,进行评审等,以加强预防与监控。          
 控制点
角色1
角色2
角色3
角色4
角色5
活动1
活动2
活动2
活动2
活动2
问题区域/质量风险区 
关键活动
活动3
活动7
活动6
活动4
活动5
活动4
操作指导书
模板
 
          
                         开发过程中返工预防及监控在开发工作的组织方面,我们建议A企业将原来的串行开发转变成并行开发。组建了有技术、营销、生产、采购及质量等部门人员参加的跨部门开发小组,让其他部门从一开始就介入到产品开发中来,把他们的“抱怨”作为需求提出来,一起形成产品的需求,然后再一起开发产品的“设计方案”(如系统、软件、硬件、结构、工艺等)。这样以来,既可以让相关部门准确的理解需求,又可以及早的暴露问题,并可以及时的得到修改,避免造成大量的返工。在工具层面,我们针对经常出现的问题以及其原因,对产品开发过程中的关键活动,在流程及工作方法(流程、指导书)优化的基础上,进一步细化了流程活动的操作工具活动模板,而且很多模板做到了样例化。比如,针对研发人员经常出现小“问题”,我们在相应的活动后面增加了自检或审核,并对自检及审核设计了自检与审核工具---CheckList(查捡表)。针对需求分析经常出现遗漏或需求模糊的问题,我们设计了需求分析模板以及需求评审模板需求分析书、需求评审要素表等。对这些常出现的问题,他们建立经验教训库,并借助IT工具对其进行动态的更新管理,以便使其能够既有效的避免员工犯同样的错误,而又不至于占用他们很多的时间,以提高经验教训库的实用性。 4-1  流程关键模板示例最后,为了确保这些改进措施得到落地执行与持续优化,A企业还接受了我们的建议,成立专门的流程管理部门,并将流程优化纳入到对各部门负责人及骨干的考核中。改进措施实施三个月后,“小问题”开始明显减少。半年后,由于需求不明确或需求遗漏而造成的返工也开始明显减少,大家的跨部门协同意识也明显加强。“以前,只要是出了问题,大家首先说的都是为自己推脱责任,现在,大家首先说的则是怎么能把问题解决了,变化很大!”A企业的一位高层如是说。其实,像A企业这样的企业还很多,我们希望通过这个案例,能对其他企业在减少产品开发过程的返工,提高过程质量与效率,提升研发管理水平有所启发与帮助。

路过

鸡蛋

鲜花

握手

雷人
分类:

讲师文苑

关键字: 产品开发 研发项目管理
免责声明 免责声明