第4章：FMEA团队组建：跨职能团队的角色与职责
做FMEA这事儿，我干了快二十年了。说实话，见过太多FMEA做成了「文档填表大赛」。为什么？因为团队没搭对。你想想看，一群设计工程师关起门来自己写FMEA，能写出什么来？
今天我就跟你聊聊，一个靠谱的FMEA团队到底该怎么搭。核心就一句话：跨职能，不是跨部门坐在一起开会，而是让不同视角的人真正参与进来。
4.1 为什么非得是跨职能团队？
我记得2015年有个项目，风机齿轮箱的FMEA是设计团队自己做的。他们把每个齿轮的接触疲劳、弯曲疲劳分析得头头是道。结果呢？样机一装，运维的人发现润滑油路设计根本没法维护——换一次油要拆三个小时的壳体。
这就是典型的「设计视角盲区」。你一个人再牛，也不可能同时懂设计、懂工艺、懂测试、懂运维。FMEA的本质是风险识别，而风险往往藏在不同专业的交界处。
核心原则：FMEA团队必须覆盖产品全生命周期的关键角色。缺一个视角，就多一个盲区。
4.2 核心成员有哪些？各自干什么？
我习惯把FMEA团队分成两类人：核心成员和支持成员。核心成员必须全程参与，支持成员可以按需介入。今天重点讲核心成员。
核心成员通常包括四个角色：设计工程师、工艺工程师、测试工程师、运维工程师。嗯，这里要注意，我说的「运维」不只是售后维修，还包括现场安装、调试、定期巡检这些环节。
| 角色 | 核心职责 | 必须参与的活动 |
|---|---|---|
| 设计工程师 | 提供设计原理、失效机理分析 | 失效模式识别、原因分析、改进方案 |
| 工艺工程师 | 评估制造过程对失效的影响 | 可制造性分析、工艺缺陷识别 |
| 测试工程师 | 提供测试数据、验证手段 | 检测能力评估、失效复现验证 |
| 运维工程师 | 反馈现场故障、维护经验 | 实际失效案例、可维护性评估 |
4.3 每个角色的参与要求
4.3.1 设计工程师
设计工程师是FMEA的「技术核心」。说白了，只有你最清楚这个零件为什么这么设计，哪些参数是关键的，哪些边界条件容易出问题。
我建议设计工程师在FMEA中重点回答三个问题：
- 失效模式是什么？——比如齿轮齿面点蚀、轴承保持架断裂
- 失效机理是什么？——是疲劳、磨损、腐蚀还是过载？
- 现有设计控制措施够不够？——比如安全系数、材料选择、热处理工艺
我的经验：设计工程师最容易犯的错是「过度自信」。总觉得自己的设计没问题，失效概率给得很低。我一般会让他们先写，然后让运维工程师来「打脸」——现场数据往往比理论分析更真实。
4.3.2 工艺工程师
工艺工程师的角色经常被低估。很多人觉得FMEA是设计的事，跟工艺有什么关系？关系大了去了。
举个例子。我曾经遇到一个风机主轴断裂的案例，设计分析认为是疲劳失效，但工艺工程师一看，发现是热处理工艺没控制好，导致表面硬度不均匀，产生了应力集中点。你看，同一个失效，设计视角和工艺视角给出的原因完全不同。
工艺工程师在FMEA中要关注：
- 制造过程是否引入了新的失效模式？比如焊接缺陷、铸造气孔
- 工艺参数波动是否会导致产品一致性差？
- 现有检测手段能否有效拦截工艺缺陷？
4.3.3 测试工程师
测试工程师是FMEA的「验证者」。设计说「这个失效概率很低」，工艺说「我们工艺控制得很好」，但到底好不好？测试数据说了算。
我个人的习惯是，让测试工程师在FMEA中负责两件事：
- 评估检测能力——现有的测试手段能不能发现这个失效？比如超声波探伤能不能检出微裂纹？
- 提供失效复现数据——实验室里有没有做过加速寿命试验？结果怎么样？
避坑指南：我曾经见过一个项目，测试工程师在FMEA会议上全程沉默。后来一问，他说「设计给的失效模式我根本测不出来，说了也没用」。这就是典型的「测试参与流于形式」。测试工程师必须敢于说「不」——测不了就是测不了，不能含糊过去。
4.3.4 运维工程师
运维工程师是FMEA的「真相提供者」。你设计得再好，工艺控制得再严，最终产品好不好，现场说了算。
运维工程师要带来什么？
- 实际失效案例——哪个部位最容易坏？平均多长时间坏？
- 维护过程中的发现——比如拆解时看到的异常磨损、腐蚀痕迹
- 可维护性评估——这个零件坏了好不好换？需要什么特殊工具？
我记得有一次做变桨轴承的FMEA，设计工程师说失效概率是1/1000，运维工程师当场拿出数据——现场统计是3/100。会议室瞬间安静了。这就是运维的价值。
4.4 团队协作的常见问题
团队搭好了，不代表就能顺利干活。我总结几个常见问题：
- 「设计一言堂」——设计工程师太强势，其他人不敢说话。解决办法：让FMEA主持人（通常是质量或可靠性工程师）控制节奏，确保每个人都有发言机会。
- 「运维缺席」——运维工程师觉得FMEA是研发的事，不愿意参加。解决办法：明确告诉他们，FMEA的输出直接影响备件策略和维护计划，不来就是给自己挖坑。
- 「测试数据滞后」——测试工程师拿不出数据，只能凭感觉打分。解决办法：FMEA启动前，先梳理已有的测试数据，缺什么提前安排。
4.5 知识体系框架
下面这张图是我自己整理的FMEA团队组建的核心逻辑。你可以把它当作一个检查清单，看看自己的团队有没有漏掉哪个角色。
4.6 我的建议
最后说几句实在话。FMEA团队组建这件事，看起来简单，做起来难。我见过太多公司，FMEA团队名单写得漂漂亮亮，实际开会时只有设计和质量两个人在场。
我的建议是：第一次FMEA会议，必须全员到场。哪怕运维工程师觉得跟自己没关系，也要把他拉来。让他听一听设计是怎么分析失效的，让他说一说现场的真实情况。只要开过一次好头，后面就好办了。
另外，团队组建不是一劳永逸的。产品迭代了、工艺变了、现场出了新故障，都要重新审视团队配置。FMEA是活的，团队也得是活的。
一句话总结：FMEA的质量，取决于团队的质量。团队搭对了，FMEA就成功了一半。