特性传递的管理功能同样重要

不改完，不解锁---DFMEA 正向传递的最后一道“门禁”

一个真实到肉疼的场景

项目结构：系统 → 子系统 → 总成 → 组件 → 零部件

系统工程师老张，花了三天把“整车能量管理”功能分析到第三版，群里发了一句：“功能定了，大家按这个往下做。”

两天后他打开子系统的 FMEA：

子系统用的还是第一版。

总成参考的是子系统“凭记忆转述”的第二版。

零部件的失效模式，已经和系统功能没有半毛钱关系。

老张问：“为什么不跟最新版？”

回复很统一：

• “你没通知我改哪了。”
• “我以为系统还没定。”
• “我改了一周，你现在让我重来？”

全员返工。两周白干。

这不是态度问题，是流程里缺了一个东西：强制依赖。

什么是强制依赖

在 DFMEA 的五层结构（系统→子系统→总成→组件→零部件）中，每一层级都可以独立开启一个规则：

• 上级功能未完成 → 下级禁止编辑（只读）
• 上级完成 → 下级自动解锁，并收到变更通知

专业点说：只有上级基线冻结，下级才能获得编辑权。

这不是“管得严”，而是确保功能正向传递的完整性——上游没想清楚，下游不盲目开工。

强制依赖的逻辑

1. 锁得住

系统层开启强制依赖：系统未完成时，子系统、总成、组件、零部件全部只读，谁也别想“抢跑”。

系统层点击“完成”：依赖锁释放，下级自动进入可编辑状态。

2. 说得清

上级完成不是只在群里吼一声。系统自动做两件事：

• 推送消息给下一级全员“系统层功能分析已完成，基线版本 v2.1，可开始编辑”
• 在批注里逐条记录修改内容（不是“已修改”三个字）

示例：

[2026-05-21 系统工程师 老张]

修改内容：

• 新增功能“峰值功率响应≤50ms”
• 删除“被动散热”，并入“热平衡控制”
• “过温保护延迟”严重度 7→8

下级打开批注，上游改了什么、为什么改、基线在哪。不用翻聊天记录，不用猜。

3. 配得活

每一层级独立开关，不是一刀切。

子系统收到通知后，可以自己决定：

• 开启强制依赖 → 不完成，不准总成动（适用于高风险/新设计）
• 关闭强制依赖 → 允许总成并行（适用于成熟模块）

总成、组件、零部件同理。该锁的锁死，该放的放行，规则完全可控。

对比一下

一句话总结

• 不改完，不解锁 —— 保证正向传递不中断
• 改了什么，批注写清 —— 保证变更可追溯
• 每层可配，灵活控权 —— 保证流程不死板

这是 DFMEA 从“填表”走向流程管控的一道实在的门禁。