简介这份PPT面向产品设计、研发工程师及创新方法学习者系统讲解TRIZ理论中功能分析与系统裁剪的核心方法帮助读者从功能本质出发理解技术系统、识别问题并寻找改进机会。内容涵盖功能分析概述、功能定义、功能分类、功能整理、功能系统分析方法、基于组件的功能评估与系统裁剪七大模块并配有功能图形化表达、本质表达法常用功能动词等实用工具可支撑产品规划到原理设计阶段的分析工作。资源包共1个pptx文件约7.9MB结构完整、图文并茂适合作为培训课件或自学材料直接使用。目前已有955人学习适合希望掌握创新规律、提升系统分析能力的中级学习者参考。1. 功能分析到底在分析什么从“顾客买的不是产品”说起你有没有想过买一台电风扇你真正掏钱买的是什么不是那几片塑料叶片也不是那个底座而是“让空气流动起来”这件事本身。上世纪四十年代一位美国工程师在价值工程研究中提出了一个反直觉的判断顾客买的从来不是产品本身而是产品所承载的功能。这句话放到今天依然锋利——它意味着当我们想改进一个东西时盯着零件看往往看不透得先把“它到底在干什么”抽出来看。TRIZ 这套源自前苏联的发明问题解决理论把这件事做成了一套可操作的流程叫做系统功能分析。通俗地说它就是把一个技术系统拆开用统一的语言描述每个组件对谁做了什么再据此判断哪些功能有用、哪些有害、哪些多余。搞懂它你就能在“改产品”之前先看清“产品在干什么”避免一上来就陷入零件细节的泥潭。这也是创新有规律可循的起点。2. 功能定义为什么必须用“动宾词组”说话2.1 从“吹干头发”到“蒸发水分”的翻译过程日常说话和功能分析说话是两套语言。你说“电吹风吹干头发”这是直觉表达描述的是结果功能分析要求你说“电吹风蒸发水分”这才是本质表达描述的是动作。两者差别在哪直觉表达里藏着使用场景和人的感受本质表达里只留下“谁对谁做了什么”。这个翻译动作看着简单实际是整套方法的地基。因为一旦你用“吹干”这种词思路就被锁在“吹”这个动作上换成“蒸发水分”你才可能想到加热、吸水、通风等一整套替代路径。TRIZ 把功能的标准句式定为“X 改变或保持 Z 的某个参数 Y”其中 X 是功能载体Z 是功能对象Y 是被改变的参数。电线的功能是“传输电流”灯泡的功能是“提供光源”放大镜的功能是“改变光线”——都是动宾结构干净利落。2.2 五条硬规矩每条都对应一个踩坑现场功能定义不是随便写句话它有几条必须守住的规矩每一条背后都是血泪经验。第一条用动宾词组描述功能等于工作加对象。写成“传输电流”可以写成“电流传输功能良好”就不行后者是评价不是定义。第二条功能对象至少要有一个参数真的发生变化。说“传输电流”意味着电子位置发生了改变如果找不到变化的参数这个功能定义就是空的。第三条禁止用“不”来替代否定动词。不能说“陶瓷不能传导电流”要说“陶瓷阻碍电流”不能说“河堤缺口不能阻止河水”要说“河堤缺口引导河水”。为什么这么较真因为“不传导”这种表述在后续分析里没法继续推演而“阻碍”是一个正向动作能接着问“阻碍得够不够”“能不能换成别的方式阻碍”。第四条功能对象必须是组件不能是组件的参数而且要针对具体技术系统陈述。你不能说“这个功能作用于温度”得说作用于哪个具体部件。第五条尽量用抽象词语避免专业术语。术语会把不同背景的人挡在门外抽象词反而更容易迁移。提示这五条里最容易翻车的是第三条。写功能定义时只要看到“不”字就该停下来想想怎么改成正向动词。2.3 图形化把功能和组件拆开看的那一刀功能定义还有一套图形化表达法用矩形框代表组件用箭头代表动作箭头从功能载体指向功能对象箭头上标注动词。看起来只是个画图技巧真正的价值在于它完成了一次分离——把“组件 A”和“A 的功能”拆成两件事分别考虑。这个分离为什么重要因为人天生会把功能和实现它的零件绑死。看到“吹风”脑子里就是电机加叶片。可一旦你把功能单独拎出来问“我们需要的是组件 A还是 A 所执行的那个功能”替代方案的空间就打开了。可能不需要电机可能用压电陶瓷产生气流可能根本不用气流而用别的原理蒸发水分。图形化表达法的作用就是逼你承认我们要的是功能组件只是当前这一版功能的载体。3. 功能分类与整理有用、有害还有那些说不清的部分3.1 有用功能与有害功能一个参数的两个方向功能按发挥的作用分最基础的一刀是切成有用功能和有害功能。判断标准很明确功能载体对功能对象的作用是否按照期望的方向改变参数。按期望方向改叫改善参数是有用功能不按期望方向改甚至恶化参数是有害功能。这个分类听起来像废话实际用起来非常扎心。因为同一个组件往往同时产生两类功能。比如某个加热元件它加热目标区域是有用功能但它同时向旁边的敏感部件传热就是有害功能。传统思路是“这个零件有用留着”功能分析的思路是“这个零件产生了一个有用功能和一个有害功能得分开处理”。分开之后你才可能想到给有害功能加隔离、改路径或者干脆换一种方式实现那个有用功能。3.2 功能整理把散落的功能串成一张网单个功能定义完还是一地零件。功能整理要做的是把这些功能按组件层次和相互作用关系组织起来形成功能模型。具体包括组件层次分析——搞清楚系统里有哪些组件、哪些属于子系统、哪些属于超系统相互作用分析——看哪些组件之间真的存在功能关系功能等级分析——判断哪些功能是主要的、哪些是辅助的性能水平分析——评估每个功能实现得好不好。这里有个容易忽略的概念叫超系统。超系统是把已经分析过的技术系统当作组件的大系统或者虽然不属于系统本身、但和系统及其组件有相关性的部分。打个比方分析一台发动机发动机是技术系统装它的整辆车就是超系统。很多功能问题不在系统内部而在系统和超系统的接口上整理阶段不把超系统画进来后面裁剪就容易剪错地方。3.3 功能模型一张图看懂系统在干什么功能模型是整理阶段的产出物本质是一张标满箭头的组件关系图。图上每个箭头都是一条功能箭头方向是作用方向标注是动词。建完这张图系统的“黑匣子”就被打开了哪些组件承担了主要功能哪些组件只产生有害功能哪些组件几乎不参与任何功能关系一目了然。这张图的价值在于它把“理解系统”和“找问题”合并成了一步。你不需要先完全理解再去找问题画图的过程本身就在暴露问题——画不出功能关系的组件是可疑的只进不出的组件是可疑的功能箭头绕远路的也是可疑的。后续的系统裁剪基本就是拿着这张图做减法。4. 系统裁剪为什么“删掉零件”反而可能更好用4.1 裁剪不是省钱是重新分配功能很多人一听裁剪第一反应是降成本、减零件。这只说对了一小半。系统裁剪的核心动作是去掉某个组件同时把它承担的有用功能转移给系统里剩下的组件或者超系统。注意是转移功能不是消灭功能。如果删掉一个零件导致某个有用功能没人干了那不叫裁剪叫功能缺失。所以裁剪的正确问法是这个组件执行的功能能不能由别的组件顺便完成能不能由超系统提供能不能用更简单的原理实现三个问题只要有一个答案是肯定的这个组件就有被裁掉的可能。裁剪的对象通常是三类产生有害功能的组件、功能冗余的组件、以及那些功能可以由更廉价方式实现的组件。4.2 一个虚构的散热系统裁剪推演设想一个模拟项目里的散热系统主板上有一个发热芯片芯片上方压着一块金属散热片散热片旁边装了一个小风扇风扇由独立电机驱动。功能模型画出来大致是芯片产生热量有害功能对系统而言散热片吸收热量并传导到空气风扇电机驱动风扇叶片风扇叶片移动空气加速散热。现在做裁剪推演。先看风扇电机它执行“驱动风扇叶片”这个功能能不能转移如果散热片面积足够大、结构改成自然对流鳍片移动空气这个功能就可以交给超系统环境空气的自然对流来完成电机和叶片一起裁掉。再看散热片它执行“吸收并传导热量”能不能转移如果芯片外壳本身改成高导热材料并直接暴露在气流中散热片也可以裁掉。每一步裁剪都要回头检查功能模型被裁组件的有用功能是否都有新归属有没有引入新的有害功能。这个推演过程不需要真实样机一张图和一支笔就能跑很多轮这正是功能分析在纸面上省下的试错成本。4.3 裁剪之后必须回查的那张表裁剪做完不能拍脑袋说“更好了”得回查。回查的对象是功能模型和一份简单的对照表被裁组件原来承担哪些功能、这些功能现在由谁承担、承担者的性能水平够不够、有没有产生新的有害功能。这张表不用复杂但每一项都得填。被裁组件原承担功能功能新归属性能是否足够新增有害功能风扇电机驱动叶片超系统自然对流需验证无散热片吸收传导热量芯片外壳直接散热需验证外壳温升可能影响周边这张表的意义在于它把“裁剪”从一个灵感动作变成了可验证的工程动作。填不满的表就是裁剪方案还没想清楚的地方。5. 常见误区功能分析里最容易搞混的几组概念5.1 功能与功能实现方式易混点把“功能”和“实现功能的具体结构”当成一回事。为什么混因为日常语言里两者经常黏在一起说“照明”脑子里就是灯泡。怎么区分功能回答“干什么”实现方式回答“怎么干”。功能定义阶段只写“提供光源”不写“通过钨丝通电发热发光”。一旦在定义里写进了实现方式替代方案就被提前排除了。5.2 有用功能与必要功能易混点以为有用功能就一定得保留。为什么混“有用”这个词自带正面色彩。怎么区分有用功能是方向正确的功能必要功能是当前系统缺了它就不成立的功能。一个功能可能有用但冗余——两个组件都在执行同一个有用功能裁掉一个系统照样转。判断标准不是“有没有用”而是“少了它行不行”。5.3 功能对象与功能载体易混点写功能定义时分不清谁对谁。为什么混因为很多组件既作用于别人也被别人作用角色是流动的。怎么区分看动作箭头的方向发出动作的是载体接收动作的是对象。同一个组件在一条功能里是载体在另一条功能里可能是对象写定义时必须一条一条单独确认不能笼统说“这个零件有散热功能”。5.4 系统与超系统的边界易混点把超系统里的东西算进系统内部或者反过来。为什么混因为边界是人划的划法不同结论就不同。怎么区分看分析目的如果这次要改的是系统内部结构超系统只作为外部条件画进来如果问题出在接口上就得把相关超系统组件纳入功能模型。边界一旦定了整轮分析要一致中途改边界等于重来。5.5 有害功能与功能不足易混点把“做得不够好”当成“有害”。为什么混两者都让人不满意。怎么区分有害功能是方向错了参数往反方向走功能不足是方向对但幅度不够。处理方式完全不同有害功能要消除或隔离功能不足要增强或换实现方式。把功能不足误判成有害功能容易把有用的东西裁掉。6. 什么时候该用功能分析什么时候别硬套功能分析不是万能锤子它有明确的适用边界。适合用的场景很清晰你要改进一个已有技术系统但不知道从哪下手或者要开发新系统需要先理清主功能和子功能的关系又或者系统里问题很多、互相纠缠需要一张图把因果关系摊平。这几种情况下先做功能定义和功能整理往往比直接改结构省时间。尤其是系统裁剪它天然依赖功能模型没有模型就裁剪等于闭着眼睛拆零件。不适合硬套的情况也得说清楚。如果问题已经定位到单一参数、单一组件的局部优化比如某个尺寸差零点几毫米直接调参比画功能模型快得多。如果系统极其简单、组件就三五个、功能关系一眼看穿做完整的功能分析属于杀鸡用牛刀。还有一种情况是时间压力极大的应急修复功能分析需要静下来画图填表这时候先用经验止血、事后再补分析更现实。我自己的习惯是凡是动到“要不要删掉一个组件”或者“要不要换一种原理”这类决策都强制走一遍功能定义和功能模型哪怕只画草图。因为这类决策一旦拍错返工成本远高于画图的那半小时。有一次在一个模拟项目里我凭直觉认定某个支撑件是多余的差点直接删掉画完功能模型才发现它还承担了一条隐蔽的“保持间距”功能删了会引发连锁问题。从那以后我每次做裁剪决策前都强制走一遍功能模型回查再没在这上面翻过车。这份资料把功能分析的七个环节——概述、定义、分类、整理、系统分析方法、基于组件的功能评估、系统裁剪——串成了一条完整的线从概念到图形化表达再到裁剪推演都有对应内容适合放在手边当查阅底稿。需要完整资料的话按文末方式获取即可。希望帮到你。本文还有配套的精品资源点击获取