首页 > 汽车技术

见到一点儿苗头就能看出事物的实质和发展的趋向

2022-04-15 04:14:54来源:   汽车技术 编辑:众创汽车资讯网

  科学的认识事物要有严谨的思维,没有魔法!  给你一篇文章看看  是用于企业管理的,但这个思想适用与生活各方面。  DMAIC方法  DMAIC是6δ里面很重要的一个方法,但是我们发现到DMAIC其实在我们的日常工作之中,尤其是工程有关的工作格外重要。所以以下我就分别来做些解说,目前公司在每  个会议室都有做一个DMAIC的广告牌,这个广告牌的目的就是要提醒各位,当遇到非常困  难的问题时refer一下这个广告牌,看看它的程序、它的思考逻辑,我个人认为用这个  方法,什么问题都可以解决。  【积极解决问题;问题也是机会】  接下来我先简单介绍一下基本的观念。首先,我们说是问题分析解决之钥,问题本身  是存在的,我们在怎么小心,在怎么细心,还是会有很多问题在我们设计的产品,我  们的日常工作,甚至生活之间。我们要怎样去面对问题?我认为一定要积极,因为消  极的话,问题永远存在,就像说你明年要考大学,今年就要好好的准备,这必须要积极  去面对,才能够有好的结果。所以我们积极去找到问题,所设计出的产品就会比别人  还要好,我们的工作质量,甚至生活质量就会比较好。另外我想要 highlight 的是  ,通常问题也是机会,譬如说:我们人从走路到骑车,从骑车到开车,速度越来越快  也产生了各式各样的危险,那这危险就是一个问题,所以你一开始就冒着生命危险去  开车,然后你绑安全带,慢慢地大家觉得说有无更安全的方法,就发明了安全气囊。  解决一个问题,也变成一个新的业务机会,所以我们不能等着问题来找我们,我们要  积极去找问题。聪明人找到问题解决之后,开创了一些新事业,也是经常有的事情,  所以我们脑袋要不停地转。  【欲速则不达】  第二个就是一般人解决问题的时候,通常是欲速则不达。这意思是说,通常我们在解  决问题的时候,会去找过去的经验、知识。如果一个问题在一两天之内,你就找到相  关类似,模拟非常高的pattern 模式,你加以解决,这个就是求速,任何人都会这样  做,也无可厚非;但若你经过了两三天,还解决不了,你还是不断地去跟人家请教,  想要找一个快速的解决方法,那就是真正的欲速则不达。底下我们要讲的DMAIC就是  一个真正的真功夫。像我自己以前在工程这方面20多年来,任何问题如果我没有办法  在短时间内解决,我就会泡一壶茶,然后慢慢地一边喝茶,一边思考,我的逻辑顺序  其实跟DMAIC非常非常的接近。所以我觉得我们每一个工程人员或者公司人员,大家都  能够认定这些逻辑的话,这个解决问题的逻辑、方式跟态度,事实上是可以帮我们解  决所有的问题,这是最基本的作法。  【D:做对的事--判断力】  D:Define,就是定义。基本上强调的重点是要做对的事。是强调判断力,强调  问题的描述,一般我们问题都讲不清楚,小孩子急急忙忙的跑回来,口吃了半天,很  多小孩出事了都不敢讲,避而不答。我们从产品卖出去之后,或工作中觉得不对劲的  时候,其实我们问题根本没办法厘清。所以厘清问题,将这问题到底是什么 What is  problem? What is impact?所以它强调描述与判断力,这部分我们要先努力把它弄  清楚。所以说现在学工程的国文能够不好吗?英文能够不好吗?若不好的话,连表  达都会有问题。  【M:毕其功于一役--联想力】  M就是Measure,Measure就是要发散,毕其功于一役,最主要依赖的是联想力,因为  如果我们解决问题是one by one的解决,你要花多少的时间one by one 才可以把问  题解决。遇到一个真正严重且困难的时候,我们要能够发散,想到各式各样可能的  原因,做实验加以确认。有时候很多问题是multi-factor,就是多项因素,你解决一  个因素,觉得有点成就感,但是问题没有真正的解决,从10%降到3%,improve了三倍,  但是问题没有解决,3%还是不可容忍的,3%到了0.3%还是不可容忍,因为它的比例还  是太高。所以我们一但遇到一个比较复杂棘手的问题时,要把它展开,一次把它解决  ,就是 step by step的debug,另一个说法就是 endless bug,就是你解决了怎么还  会有bug。  【A:真因--逻辑、科学方法与态度】  第三个就是A,Analysis分析。分析讲究的是追求真因,它所依赖的是逻辑,就是逻  辑性。很多在做分析时所需要的是科学方法与态度。讲到这里我必须说工程师或者任  何人员在学习的过程中,都必须学习科学方法跟态度,就是客观、观察、假设、实验  、推论,这样的一个流程。这样才有办法将真正的原因找出来,科学家利用这个方式  与态度,找到很多自然界的真相,事物的原理。当然这并不是解决,你知道水里面的  压力很大,solution是做潜水艇,压力很大是找到root case。  【I:正解-- 务实,一劳永逸】  接下来是找正解Improve,正解的意思是要务实,意思是说solution里面并不是谁的  责任谁来解。有时chip set的问题是由软件来解决,有时候RF的问题可能由机构来解  决,所以我们要务实,最低的成本、最高的效益、最短的时间、最小的冲击来加以解  决问题。我们希望Improve的solution是有效的可以做到一劳永逸。所以不要今天你  Improve了,过几天问题又回过头来找你,一个事情close了,又reopen。Close又  reopen对工程师来讲不是一个好的衡量指标。  【C:知识化的落实,预防再发】  最后一个是Control,因为你有一个Improve后,它这个问题有可能会在别地方不断的  发生,今天解决了,明天还会发生,这个Project解决了,另外一个Project还会发生  了。所以怎么将一个solution,加以知识化,加以落实,因为刚刚务实是一个态度  ,落实是手、是report、是报表。然后怎么做到预防,我们不希望问题不断再发生,  我们喜欢积极解决问题,但我们不喜欢解决同样的问题,没有人喜欢解决同样的问题  ,那是在消耗生命。  【参数量测以验证设计;功能测试以统计成效】  接下来跟各位分析,我这里面提到很多要各位不断的量测,这量测是指参数量测,就  是规格对规格。你今天做了一个Improvement,加了一个电容,你要去看它的report,  看它的delay,看它的waveform,而不是说,因为我们用参数设定,验证规格,可看出  它的容忍度,这是做design的verification。另外一种是功能测试,功能测试是用来  做统计,因为功能的话我们可以用大量;测试的部份,测试这个USB Function,work  不work,Camera picture的quality,功能测试,可以用大量的,3,4台100台是用来做  统计的。但是工程师决不能仰赖功能测试,因为design module 百分之一的问题是问  题,千分之一,万分之一的问题也问题。航天飞机飞上天空去,只要万分之一的问题,  它就掉下来了。所以我们看到航天员在天空漫步,去解决防热片的问题,为什么?没有  人希望下来变成烤鸡或烤鸭。  【马步就是真功夫】  所以真正的工程师一定要自我期许,对规格要看的懂,然后能够做量测验证,而不是  只靠做测试。所以最后要跟各位强调的是,我们学习这个东西它是马步,就是真功夫。  就是说问题没有速解,没有快解,我希望各位能够学习回归DMAIC,用这个方法一步一  步来解决问题。  【Define: 定义、判断、缓急】  接下来我们把DMAIC告示版简单复述一遍。DMAIC - Define就是定义,最重要的就是定  义,考验我们的判断力,就是要决定我们的轻重缓急,所以第一个问题一定要定义清楚  ,不要慌了手脚。所以Description 5个W,1个H;what、when、where、who、how。然  后我们要能描述对客户的影响impact judgment,尽量的能够数据化,譬如这个impact  会有多少的退货率、我们出货出了多少之类,用这个来判断轻重缓急Sense of Urgency。  因为如果投入有兴趣的事情,但不是投入最重要的事情,这样的话解决事情的focus  还是不对,所以轻重缓急非常的重要。设定改善的目标Set Goal,包括了明确的时程  ,因为在解决事情的时候,不可讳言的都有时间压力,所以这部份也要根据时间压力  ,决定我们的投入资源、需要求救、需要跟厂商conf. call,后面有一些管理的部份  我会提到。  【Measure: 发散、数据、收敛】  Measure就是量测,这里面的重点是我们要发散,因为刚刚的define比较像是归纳,听  到各式各样的问题归纳出一些它可能的影响。measure就是要发散,看有那些可能性,  像冰山的形成它可能跟天气、海流、工业污染等种种都会有关系。所以要发散就我们  的知识所及地发散。然后要收集数据让数字来说话;然后要收敛,开始去想到底这个  发散之后,怎样去收敛到几个关键因子,运用鱼骨图或是用脑力激荡,鱼骨图可能是  个人少数人的知识;脑力激荡,是跨专业的,所以你可能把软件、硬件、RF几个不相关  的人抓起来大家讲讲,就能拼出整个picture。所以解决问题有时候就像在拼图游戏一  样,很多东西的时候,大家你一言、我一语的时候反而能将这个拼图拼好。一些因素、  假设我们提出来的时候,要设定相关的量测点,有些事情不是官大学问大,而是我们  的实地量测下来,是不是有这个相关性,然后订定计划量测并且去记录有关的数据。所  以刚刚提到的要define measure point,然后要去define一个计划,因为你怎么去  exercise那些factors,去把那些数据量进来。量进来之后,所谓的有效数据是说你的  设备、量测设备、作的实验条件要有一致性,才不会收集到错误的数据,根据数据收敛  到关键因子。你不可能讲到有20个原因就可以explore 20个possibility,但是你最后  可能会focus到三到五个factors来解决。  【Analysis: 以逻辑、科学方法、确认真因】  接下来当你的factors已经收敛到一个地步的时候,你要开始分析。我们现在强调要用  逻辑、科学的方法来确认真因,依据因果的逻辑,因果是最重要的。等一下我会再做更  细部的介绍,用科学的方法来提出假设理论,根据logics你要提出assumption,就你认  为它可能是一个原因。如果是这个原因它会有那些Side effect,你怎么去观测如果是  这个原因,带来的一些影响是怎么样,我们可以设计实验来改善这些原因,这不是对策  而是去操弄这些原因,看这些原因是不是根据我们量测这些数据有它的因果关系;如果  它有因果关系,有它的效果的话,就可以称这些原因为root cause。譬如这电路板你加  一些电容,你实际没办法再rework进去,这部份是没有关系,我们只要先确定原因。  【Improve: 一致、周延、正解】  先确定原因后,接下来就是improve,improve强调的是一致性、周延性跟正解。根据真  因更正错误,我们尽量从root cause去解决,而不是从后端去解决。一个原因可能会有  好几个结果,你都要去解决结果的话,你要去解决中间的原因的话,你可能要解决六个  ,只要找到root cause,你只要解决一个就够了。根据量测确认相关的对策是正确的,  所以不要用赌的方式做对策,你要用功能测试去测、你要用量测去确认,然后确认实施  的可行性,因为你有很多材料已经买了,电路板也已经在那里,RF的antenna也做了。所  以要看我们的实施是不是可行的,怎么样让它大量生产、怎么样让它能做售后服务。模  拟验证相关的副作用,因为任何的solution下去,就像吃药都会有副作用。所以要怎么  去simulate,怎么去评估有什么副作用,然后要去验证它的副作用是acceptable的,然  后你下去的任何对策它本身也会有变因,所以要考虑它的design margin测试它的一致性  ,所以有时候我们的对策下去三台、五台有效,你去试投二十台、一百台又失效了。所  以这部份我们要有心理准备,这就是我们对真因掌握还不够确实,所以我们要考虑到  margin。  【Control: 预防、经验传承】  最后一个是control预防跟经验传承,因为我刚刚已经解释过了,同样的问题,没有人希  望一再的解决、重复的在解决。所以我们solution在导入的时候要及时导入,后面会再解  释为什么要及时,因为迟来的真理不是真理,尤其产品量产之后,你越晚去解决伤害越大  ,所以这部份一定要及时,决定要解决一个问题的时候,一定要设due day。改善流程预  防再次发生,遇到问题是流程的问题,流程非常的复杂,所以每个人都会犯错,那这时候  针对一个人去教、二个人去教,不如把流程改善或是简化,这部份我们要去想是不是  repeatable,如果是repeatable要从流程面去想。接下来是知识化以便分享跟教育,我们  员工还是会不断的流动,主管及新人也会不断的进来被promote上来,所以不管个人来讲,  不想再repeat一样的错误,对整个组织也投入更新更重要的一些挑战,而不是让那些人一  直重复那些错误。所以这是我把广告牌先简单讲一遍,接下来我们来讨各个比较小的问题。  【先判断轻重缓急 CIP? Gating? Holding? Call Back?】  接下来我们讲define问题,就这页我们来解释一下。我们常常把问题当作是冰山的一  角,也就是说,我们看到的是一个现象,其实整个冰山有多大,是我们要去find out  的。所以先谈问题本身,第一个最重要的是要强调我们的判断力,这个时候,研发的  人员其实要佩服品管的人员在这方面经年累月所培养的判断力,他们知道对客户的impact  对business的impact是什么,根据这个判断力来决定我们的轻重缓急。所以一个问题  的发生可能是一个CIP,就是continuous improvement program,你可以继续改善没关  系不gating,你也可以gating这个在开发中的phase,你也可以说holding停止出货,  damage都还在公司之内这都还好。如果已经出去了,你要怎么去call back或怎样去作  field service,这就是进一步更严重的问题。所以问题一发生的时候,我们一定要先  弄清楚这个问题对我们的重要性有多少sense solution是什么?所以在强调问题的时  候,强调5W1H,就是怎么描述。  【描述充分以利判断】  描述讲究充份、以利判断,这里面提到的问题发生的机率是怎么样,从总量跟机率我们  大概知道它的impact有多大,那它的环境有的是到了冬天才会发生,或到夏天才会发生  ,雨天才会发生(跟湿度有关)。那对使用者影响,对上班族、青少年、对老年、对不同  的使用者会有什么样的影响。所以当我们收集到了各式各样的feedback后加以分类、加  以归纳,然后可以判断这个问题是公司的一个什么样的问题,这是一个危机或是一个必  需要改善的quality。  【莫混杂因果,以结果为主】  这里面我要提醒各位,我经常看到不管是资深,还是资浅的人,都会犯的问题就是会混  杂因果,我要强调的是我们在讨论问题的时候,要以它的结果就是impact为我们讨论的  对象,什么叫混杂因果呢?就是假因先入为主。举例来讲有一个系统audio不好,可能在  描述这个问题的时候,这个问题因为喇叭不好所以音效不好,你在还没有做分析就作结  论了,事实可能不只是喇叭不好,可能是电机电路没有做好、可能厂商的问题、可能我  们自己设计的问题、可能是我们制造的问题、可能是机构的干涉让它的喇叭音响没办法  发挥的问题、可能是RF的干扰也有可能。所以我们在描述问题的时候,把因果一起描述  ,事实上是事倍功半,这样反而会混淆,且把这个原因当问题来描述,就是一种主观的  限缩,你在思考的时候就已经被限定了。我们知道现在有很多问题,教育的问题、国防  的问题种种的,其实都一样。我们都不要先假设原因就是什么,我们把因果分清楚,因  是什么、果是什么,接下来才来探究真因 。会把因果混淆的另外一个心态主要是逃避责  任的想法,所以一个问题可能HW、SW、ME、RF都有的时候,我们在描述问题的时候就避  而不谈。可能是某个function的问题,这样的描述也会隐喻失意,会变成一个miss  leading,所以担任主管的要非常小心,员工在跟你报告问题的时候不要被miss leading  ,最后我在提醒一下,这样的习惯也会变成trial & error,因为你第一次讲的时候很  有把握,因为这个东西不好,所以产生这个结果跟老板报告,去解决完后又来了,上次  的推论好像不太对,这问题没有解决,这就变成一种trial & error,从我工作以来trial  & error 一直是负面的形容词,所以我们不要被人家说是trial & error,但是很多人  都是这样子。另外我们在定义问题的时候要小心,不要因为改善的困难而逃避问题,我  们知道我们的设计也许因为definition的问题,也许初期的评估没有评估好,或许我们  设计不扎实,所以让不好的产品流入到市面,不要因为解决问题的困难性而去逃避问题  ,因为问题总是在那里,如果一个产品没有设计好就不要让它量产,如果它没有市场宁  可不要让它量产,如果设计已经量产了,可是产品还是有问题还要去面对,因为公司不  是开一个月就关掉,你总是要不断的面对它。所以我必需跟各位提醒,绝对不要因为改  善的困难而逃避问题,员工不可以,主管更不可以,高阶主管更不可以,这样的话绝对  会让整个团队失败。  【评估、衡量冲击 Impact analysis 以做损害控制 (Damage control) 并备妥备用计划  (containment plan):】  接下来我谈到的是Impact analysis,当这问题有所了解之后,我们看到这冰山浮出来  之后,要去衡量这个冰山有多大?对我们航道的影响?所以我们要去评估衡量这个  impact,就是我们称为冲击。有时候我们对Impact analysis的认知是会设计一些实验  ,举例来讲以前我们设计的第一台notebook,它的电源有两个5伏特,但是只有一个5  伏特被接另一个是floating的,也就是基本上你给他的power是不够的,它平常的时候  都不会出问题,在传输的时候会有一些fail rate。这个时候怎么办?我们要知道这个  问题有多严重,所以我们就放大数量去研究,在高温、或是高压、或是什么样的情况之  下,电压在一些电池有电或没电,插adapter,或是怎么样,设计一些实验去看这个  impact会怎么样,所以这个Impact analysis都要设计一些实验去做评估,这方面我们  的品管单位还满厉害的。二来呢?我们要做损害控制,就是说在我们还没有找到solution  前时间还是一直在过,你在解决这个问题可能要花一个礼拜、一个月都不一定,那你要  怎么做损害控制,可能要减少出货,或是准备一些备用计划containment plan,没有真  正原因的时候,我们先说好如果客户不能我们能够退什么,准备一些备用计划让客户不  满降到最低让损害降到最小,这叫damage control 跟containment plan。一般一个问  题对我们的工作、对我们的业务会有什么的impact呢?第一个是schedule,当然任何出  现都是意外的话,对你的schedule也许是一个measure impact;第二个是对我们的  performance,举例来说我们有个产品里面有个dsp因为耗电的问题,我没有去用它,所  以我们就没有开动这个dsp,但是performance就下降,因此有可能这个performance是  MHz,是客户对这个东西的感受,譬如说camera的问题客户会觉得不满意,或是通话的  质量,所以这是属于satisfaction或是comparison、bench marking的问题,属比较的  问题;第三个问题可能是工厂良率的问题,就是RD不能去避免这点,因为工厂的良率就  是最后出厂的质量,它绝对是有相关性,良率的问题逮不到就是质量的问题,当然良率  的问题,它的impact是造成成本、工时的增加、修护的困难,基本上就是一个不够好的  design。所以这部份当然工厂的PE一定得锲而不舍去要求到,either是厂商、制造或设  计都要改善;再下一个是quality return,就是已经出货了但是它会造成退货,就是大  家会觉得不满,譬如这个塑料裂开这些种种的问题,这已经是明显不堪使用;接下来更  恐怖是service跟Reliability,就是你在使用的前半年都ok,半年之后开始裂开那你怎  么办?你卖了半年,你运气不好,买了五百万个,你到时候亏大了。我们常常讲做一台  产品也许是notebook,也许是手机赚个十块美金好不好,你修一台notebook要200块美  金以上,所以你这个不良率超过几个%就注定赔大本,所以Reliability的问题是我们通  常来讲最严重的问题,因为它不会立刻发生,所以你要怎么样去judge这个Reliability  让他立刻去改善。我记得以前在做一个产品有一个MOS会烧掉,烧掉是个很严重的  Reliability issue,一但到了那个问题它不会立即发生,到了它发生的时候,客户绝  对会退货它不是一个不满意的问题;再下来的问题更严重就是Hazard跟crisis,就是  危机。像我们知道说有一辆车子轮胎会爆掉,爆掉之后油箱设计又不好会着火,任何只  要有safety的concern,以我们的来讲我们的电源部份、这个battery部分若会引起爆炸  ,这都是crisis造成公司危机,这跟你的销售金额无关,这个赔偿是蛮random的自由心  证,而且在美国可能会引起collect action(集体诉讼),引爆的问题非常的大。  【Set Target,组成专家团队,应及时解决导入对策】  接下来当我们问题define清楚的时候,知道问题严重性的时候我们要set goal,我们目  标设定好了以后,要组成专家团队,不要说那个自不量力,但是你参加的成员不够的时候  ,问题往往没有办法解的很干净,所以在这个时候中高阶主管一定要判断你要独立解决  ,还是call help,当专家都进来的时候,才可以实时的导入对策,这在define的部份,  等于是解决问题的一个准备动作。

你好!见微知著打字不易,采纳哦!

标签:

版权声明

    转载此文是出于传递更多信息之目的。若有来源标注错误或侵犯了您的合法权益,请作者持权属证明与本网联系,我们将及时更正、删除,谢谢您的支持与理解。