简介:这份PPT课件面向产品设计、工程创新与TRIZ初学者,系统讲解发明问题解决理论中的功能分析与系统裁剪方法,帮助读者把用户需求抽象为功能、识别有用功能与有害功能,并据此寻找结构优化和降本增效的切入点。压缩包仅含1个PPTX文件,约7.9MB,内容以章节化幻灯片组织,便于按主题浏览和课堂演示。已有955人学习,说明其在创新方法入门与工程案例分析中具有一定参考价值。课件从功能分析概述展开,覆盖功能定义、功能分类、功能整理、功能系统分析方法、基于组件的功能评估与系统裁剪,并结合技术系统、组件、超系统和目标等概念,给出功能定义原则、本质表达、图形化表达及功能模型思路,适合用于产品规划、原理设计、问题诊断和流程优化等场景的自主学习与教学引用。
1. 功能分析在TRIZ体系中的坐标:先看地图再拆模块
很多人学创新 TRIZ 时,第一反应是去背四十条发明原理或者矛盾矩阵,结果翻到功能分析这一章就卡住——概念一堆,动词表一长串,裁剪规则看起来像拼积木。其实把地图摊开就三件事:功能怎么定义、功能怎么分类整理、系统怎么剪裁。功能分析干的就是把产品从“实物”翻译成“功能语言”,先抽象描述,再分类整理,最后系统化建模,落到剪裁时才有依据。整份内容围绕功能定义、功能分类、功能整理、功能系统分析方法、基于组件的功能评估、系统裁剪六个模块展开。适合正在系统学 TRIZ 的人对照检查逻辑链,也适合备考复习时快速拉一遍主线——遇到“这个动词算不算功能”这种纠结,直接查第二、三章就有答案。
2. 功能定义:四原则与本质表达法
功能定义是整个功能分析的入口。这一步写歪了,后面分类整理和裁剪全部跟着歪,所以值得花最多时间打磨。TRIZ 对功能的定义很克制:某组件(功能载体)改变或保持另一组件(功能对象)某个参数的行为或作用。一句话里有三个要素——载体、动作、对象,缺一个就不完整。
2.1 功能=动词+对象:为什么必须是“V+O”结构
功能描述要求用动宾词组,功能=工作+对象,也就是动词加名词的结构。比如“电线传输电流”,“传输”是动作,“电流”是对象;“灯泡提供光源”,“提供”是动作,“光源”是对象。
这个约束不是文字游戏。用V+O描述之后,组件本身的名字被剥离了,剩下纯功能,后续才可能讨论“这个功能能不能换一种载体来实现”。如果写成“电线的功能是导电”,表面看没错,但“导电”是功能执行的结果,不是功能本身——结果描述会把实现方式焊死在原组件上,后面想做裁剪就没有腾挪空间。这也是很多人看功能分析觉得“像在玩文字”的原因:真正做过一遍整理的人会发现,定义写对了,后面识别冗余和有害功能的难度直接降一半。
梳理下来会发现一条暗线:功能定义做得越抽象,后续系统裁剪的选择面越宽。抽象度不够,裁掉某个组件后功能就无路可走。
2.2 本质表达与直觉表达:最容易栽的一步
功能定义最大的陷阱是把“功能执行的结果”当成功能。这里有一组对照表,是复习时最值得背的内容:
| 技术系统 | 直觉表达(结果描述) | 本质表达(TRIZ功能定义) |
|---|---|---|
| 电吹风机 | 吹干头发 | 蒸发水分 |
| 电风扇 | 凉爽身体 | 移动空气 |
| 放大镜 | 放大目标物 | 改变光线 |
| 白炽灯 | 照亮房间 | 发光 |
| 挡风玻璃 | 保护司机 | 防止车外物体撞击 |
| 二极管 | 整流电流 | 阻滞某极性电流 |
直觉表达描述的是结果,本质表达描述的是组件对对象参数做了什么。两者在含义上不是“哪个更高级”的区别,而是功能分析能不能继续往下走的分水岭——结果描述没法参与分类,也没法判断有用还是有害。
提示:判断是否写成了直觉表达,可以反问一句“这个功能发生之后,对象的哪个参数变了”。答不出参数,大概率还是结果描述。
2.3 四条红线:否定动词、对象限定与抽象度
功能定义的原则里,有四条最容易在实操中被违反:
- 必须用动宾词组,功能=工作+对象。一个功能受体至少要有一个参数受到影响并发生改变。
- 禁止用“不”替代否定动词。不能说“陶瓷不能传导电流”,要说“陶瓷阻碍电流”;不能说“河堤缺口不能阻止河水”,要说“河堤缺口引导河水”。用否定词会把功能定义变成对功能的否定,等于没定义。
- 功能对象必须是组件,不能是组件的参数。并且要针对特定条件下的具体技术系统来陈述,不能泛泛而谈。
- 尽量用抽象词语表达,避免专业术语。专业术语自带实现路径,抽象词才能留出替换空间。
第 3 条在实际整理中最容易漏。比如写“散热器降低CPU温度”,这里的“CPU”是组件,没问题;但如果写成“散热器降低CPU温度值”,对象就变成了参数,功能定义就失焦了。参数只能出现在描述功能作用结果的句子里,不能拿来当功能对象名词。
2.4 功能动词速查:先查表再定稿
本质表达法依赖一套常用功能动词。与其硬想,不如先翻动词表找到最接近的动词,再微调:
吸收 分解 加热 阻止 聚集 沉淀 支撑 加工 装配 破坏 告知 保护 弯曲 检测 连接 移除 拆解 干燥 定位 旋转 相变 嵌插 混合 分离 清洁 浸蚀 移动 振动 凝结 蒸发 定向 固定 冷却 析取 擦亮 传递 腐蚀 煮沸 防护 ……这张表真正的作用是当“功能定义卡壳时的词典”:比如某装置把热量从A组件传到B组件,动词候选有“传递”“移动”“导向”,选哪个取决于你想强调作用方向还是作用方式,选完后再检查对象是否准确、是否混进了直觉描述。动词的颗粒度直接决定后续功能分类的颗粒度,这一步偷懒,后面整理时必然返工。
3. 功能分类与功能整理:有用有害、三维体系与功能模型
功能定义写完之后,不能堆在那里,必须分类整理。分类解决的是“这个功能值不值得留”,整理解决的是“这些功能之间是什么关系”。两块合在一起,才能把一堆功能条目变成一张功能模型。
3.1 有用功能与有害功能:分类的第一刀
按功能发挥的具体作用来分,功能分为有用功能和有害功能:
| 分类 | 定义 | 特征 |
|---|---|---|
| 有用功能 | 功能载体对对象的作用,按期望方向改变对象参数 | 改善参数 |
| 有害功能 | 功能载体对对象的作用,不按期望方向改变对象参数 | 不改善甚至恶化参数 |
分类的意义在裁剪阶段才会显现:有用功能要保留并优化,有害功能是裁剪的第一批候选目标。但要注意,有害功能不一定来自坏组件——同一个组件可能同时产生有用功能和有害功能(比如某加热组件同时提升了相邻组件的温度),分类时要分开记录,不能合并成一条。
注意:功能分类没有绝对的“对错”,只有颗粒度差异。如果分类之后发现某个功能既像有用又像有害,那说明功能定义那句话本身写得不够具体,需要回头修正第2章的定义句。
3.2 功能分类的三种维度:作用、等级与性能水平
除了有用/有害这一刀,功能还可以从三个维度继续切:
- 功能作用分类:按作用性质归类,区分主要功能和辅助功能,帮助识别系统存在的理由。
- 功能等级分类:按功能在系统中的地位划分,哪些是基本功能,哪些是附加功能。
- 性能水平分类:按功能完成的质量划分,判断冗余和欠缺。
三个维度的关系类似“先分性质,再分层次,最后分好坏”,顺序不能乱。先做作用分类,再做等级分类,最后用性能水平标注——如果一上来就评判性能,很容易把辅助功能误标为多余功能,裁剪时就会误伤。梳理下来会发现,很多“系统太复杂”的问题,根子不在组件多,而在三种分类维度没有拉开层次,全挤在一个平面里判断。
3.3 功能整理:组件层次分析、相互作用分析与功能模型
功能整理是把分类后的功能条目串成关系图,主要做三件事:
- 组件层次分析:明确系统、超系统、目标三层的边界。技术系统由相互联系的组件和组件间相互作用组成;组件是组成技术系统或超系统的一部分、由物质或场组成的物体;超系统是将已经分析过的技术系统作为组件的系统,或不属于系统本身但与系统及其组件有一定相关性的系统;目标是技术系统的作用对象。
- 相互作用分析:判断哪两个组件之间存在功能关系,以及方向。
- 功能等级分析与性能水平分析:标注每个功能在系统中的层级和完成质量。
三件事做完,就可以建立功能模型了。功能模型不是流程图,而是把组件和功能分离开来考虑:每个功能条目画成“载体→动作→对象”的箭头关系,组件框只出现一次,功能箭头从载体指向对象。这和传统的那种“组件A连着组件B”的框图不同——框图表达的是结构连接,功能模型表达的是功能作用,两者在裁剪时起的作用完全不同。最容易混淆的就是把结构连接当成功能作用,看到一个组件连着两个组件就认为它有两项功能。
3.4 功能等级与性能水平:把“多余”提前标出来
等级分析和性能分析常常被当成“锦上添花”的步骤跳过,其实它们是裁剪前最有价值的一层过滤器。功能等级回答“这个功能在系统里排第几层”,性能水平回答“它达到预期没有”。
整理技巧可以这样操作:先给每个功能条目打两个标签——等级标签(基本/辅助)和性能标签(达标/不足/过剩)。打完之后,性能过剩且等级为辅助的功能条目,就是系统裁剪里最安全的删除对象。反过来说,如果某个功能等级是基本但性能不足,那不是裁剪问题,是优化问题,方向完全不同。很多人裁剪后系统功能断裂,根因就在这里——把性能不足的基本功能当成多余功能裁掉了。
4. 功能系统分析与系统裁剪:从模型到创新
功能系统分析是“把模型建对”,系统裁剪是“把模型剪好”。前者是后者的输入,后者是前者的出口。这一章把两个模块串起来讲,因为实际操作中它们本来就是一条链。
4.1 组建功能系统的起点:组件层次与边界判定
系统分析的起点是画边界。技术系统、超系统、目标三层必须分清:
- 技术系统:相互联系的组件和相互作用组成的整体,以实现某种功能。
- 组件:组成技术系统或超系统的一部分,由物质或场组成的物体。
- 超系统:把已分析的技术系统作为组件的更大系统,或与系统及其组件有一定相关性的系统。
- 目标:技术系统的作用对象。
边界判定的常见错误是把超系统组件强行拉进系统内。比如某消费电子产品的散热模块,使用者手持的姿势属于超系统,如果把“手持”当成系统组件来处理,功能分析会多出一大堆和系统无关的功能条目。正确的做法是:只把参与功能作用的组件拉进模型,超系统只作为外部约束条件记录,不画进功能箭头里。
4.2 相互作用分析与功能模型图:箭头里藏着功能类别
建立功能模型时,用矩形框表示组件、箭头表示功能,箭头从功能载体指向功能对象。功能模型的三个要点:
- 组件与功能分离,分别考虑。我们要的不是组件A,而是组件A提供的功能。
- 箭头必须标注动作(动词),不能只画一条光杆线。
- 按前面建立的分类体系标注功能性质(有用/有害)。
功能模型图的价值在于,它能把“组件之间的结构关系”转化成“功能作用关系”,从而暴露出那些结构上看起来正常、功能上却有问题的位置。比如某小型加热装置的承载结构,结构图上看两个组件紧密相连,功能模型里却出现一条“振动”→传热组件的箭头——结构上没毛病,功能上是一条有害作用。这种发现只能靠功能模型,靠结构图看不出来。
4.3 系统裁剪的六种基本策略
系统裁剪不是“拆零件”,而是“剪功能”——把某个组件承担的功能转移到其他组件上,或者直接删除功能。归纳起来有六种策略:
| 裁剪策略 | 操作方式 | 适用条件 |
|---|---|---|
| 删除 | 直接去除组件,连功能一起消除 | 该功能属于有害功能或彻底冗余 |
| 合并 | 两个组件承担的功能合并到一个组件 | 两者功能相近且不冲突 |
| 替换 | 用超系统或其他系统资源实现该功能 | 系统内无合适载体 |
| 简化 | 减少组件间功能链的层级 | 功能传递链过长导致效率损失 |
| 重新分配 | 把功能转移到另一个已有组件 | 存在功能冗余的组件 |
| 规避 | 改变系统结构使该功能不再被需要 | 功能本身可以重新定义 |
六种策略没有固定优先级,但有一个通用检查顺序:先判断功能性质,再判断功能对象,最后判断功能载体。顺序错了,就会出现“一刀剪下去系统性能反而变差”的翻车现场。
4.4 裁剪后的功能再分配与组件评估
裁剪的动作是删除组件,裁剪的本质是功能再分配。剪裁掉一个组件之后,它原本承担的有用功能必须由其他组件继承,否则系统功能链断裂。所以每次裁剪后要立即做两件事:
- 检查被裁组件承担的所有功能条目,标注每条功能的去向(被谁承接或彻底消亡)。
- 对承接组件做基于组件的功能评估,判断它的性能余量是否足以承担新增功能。
这个评估步骤容易被省略,但它是裁剪后是否要二次裁剪的决策依据。某图像处理Demo的制冷模块裁剪后,把散热功能转移到了壳体上,但壳体的热传导参数没有重新评估,结果系统能跑但温升超标——功能模型上那条箭头画出来了,参数没跟上,等于模型和实物脱节。系统裁剪的完整闭环是“裁剪—再分配—再评估”,少一步都算没做完。
5. 易错点:功能分析里最容易翻车的五处
功能分析的概念不多,但概念之间的边界很细,实际操作时错的位置非常集中。梳理下来,反复踩的坑就这五个。
5.1 易错点一:把结果当功能
易漏点:直觉表达和本质表达的区分。为什么漏:日常语言习惯就是用结果描述功能,“吹干头发”“照亮房间”说出来毫无违和感,很容易直接写进功能定义。怎么补:每写完一条功能定义,强制追问“对象的哪个参数变了”,答不出来就重写。电吹风机的功能不是吹干头发,是蒸发水分;电风扇的功能不是凉爽身体,是移动空气。
5.2 易错点二:拿参数当功能对象
易漏点:功能对象必须是组件,不能是参数。为什么漏:参数和组件在中文表达里经常连在一起,比如“降低温度”和“降低水温”看起来结构一样,但前者对象是参数,后者对象是组件加水(不严谨但方向对)。怎么补:写完功能定义后,把对象名词单独拎出来问“它是一个物理组件吗”。不是组件就改,改为对组件的作用,参数变化放到动作描述里体现。
5.3 易错点三:用否定词敷衍
易漏点:禁止用“不”替代否定动词。为什么漏:否定句在日常表达里太顺口,“不能传导”“不能阻止”写起来毫不费力。怎么补:把“不能+动词”的结构反向替换成“阻碍/引导/隔离”等肯定式动词。陶瓷的功能定义是“阻碍电流”,不是“不能传导电流”;河堤缺口的功能定义是“引导河水”,不是“不能阻止河水”。这一步不只是文字替换,用否定词会让功能分类失去依据——一个“不能做什么”的条目既不能归入有用也不能归入有害。
5.4 易错点四:裁剪时把基本功能误删
易漏点:裁剪对象应该是性能过剩的辅助功能,不是性能不足的基本功能。为什么漏:裁剪时注意力集中在“组件数量少了多少”,忽略了功能等级标签。怎么补:裁剪前先确认功能等级和性能标签,只对“辅助+性能过剩”的功能条目做删除或替换,对“基本+性能不足”的条目改走优化路线。裁剪清单上每个被删除的组件后面必须追一条功能去向,去向为空且功能等级为基本的,直接打回重审。
5.5 易错点五:混淆系统边界与超系统
易漏点:超系统组件不能当系统组件画进功能模型。为什么漏:超系统和系统在结构上有关联,画图时顺手就画进去了。怎么补:建模前先把组件清单分成“系统内”和“超系统”两列,功能箭头只在系统内组件之间画。超系统只作为约束条件记录在备注里,比如使用环境、外部接口条件,不参与功能链。系统边界一旦画错,后面的组件层次分析和裁剪都会跟着错。
6. 查漏补缺:一份可运行的复习清单
复习功能分析不需要重读全部材料,按下面这张清单过一遍就能定位知识漏洞。逐项打勾,打不上的对应回第几章找答案。
| 检查项 | 判断标准 | 对应章节 |
|---|---|---|
| 功能定义句式 | 每条都是“动词+对象”,没有结果描述 | 2.1 / 2.2 |
| 否定动词排查 | 全文无“不能+动词”结构 | 2.3 |
| 对象类型 | 每条功能对象都是组件不是参数 | 2.3 / 5.2 |
| 功能分类完整性 | 有用/有害分开记录,三维维度都标过 | 3.1 / 3.2 |
| 功能等级与性能标签 | 每个条目都有等级+性能双标签 | 3.4 |
| 功能模型箭头 | 每条箭头都标了动词,没有光杆线 | 4.2 |
| 系统边界 | 系统内组件和超系统组件分列清楚 | 4.1 / 5.5 |
| 裁剪去向 | 每个被删组件的功能都有去向记录 | 4.4 / 5.4 |
| 裁剪后再评估 | 承接组件的功能评估做过 | 4.4 |
这张表最实用的地方是第 4 行和第 7 行。功能分类漏标三维维度,当时看不出问题,裁剪时才发现找不到筛选依据;裁剪去向不记录,系统跑起来功能断了才发现。这两处反复踩过,血泪经验就一条:功能分析的每一步都要留下可回查的记录,不能只凭脑子记。
复习时还有一个更省力的做法——把功能动词表和本质表达对照表打印出来贴在桌边,每写一条功能定义就扫一眼,看动词在不在表里、对象是不是组件。这个习惯看起来笨,但用了之后定义返工率明显下降。从那以后我每次做功能分析都强制先过一遍对照表再看模型图,宁可定义阶段慢一点,也不让错误往后传。希望这份清单帮到你,复习时少走几步弯路。
本文还有配套的精品资源,点击获取