某精密机械企业：ECN变更闭环上线后，工程变更周期缩短60%

添加HanTop-MKT，解决企业变更管理难题

“以前一个变更走完，从工程师改图到所有部门都知道、ERP都更新了，最快5天，最慢两个礼拜。现在2天以内能闭环。”

说这话的是深圳一家精密机械企业的研发总监。他们用SolidWorks PDM Professional管了四年图纸，版本控制一直没问题，但变更管理始终是"PDM管不了、微信群管不好"的状态。

在PDM基础上搭配鹏焬OIDS后，ECR→ECO→ECN变更闭环跑通了，变更周期缩短了约60%。

这篇文章把这个企业的变更管理痛点、选型过程、实施效果说清楚。

一、企业背景

PDM使用情况：图纸版本管理、检入检出、基本审批流程都跑通了，工程师已经习惯在PDM里做设计协同。

PDM管不了的部分：BOM管理、变更管理、编码管理、ERP集成——这些靠Excel+微信群+邮件补位。

二、变更管理的痛点

2.1 变更通知"漏人"是家常便饭

这家企业的变更流程是这样的：

1. 工程师发现要改图，跟主管口头说一声
2. 改完图，在PDM里做版本升级
3. 微信群发一条"XX产品A零件从V2改到V3，各部门注意"
4. 采购看到了去改ERP BOM，工艺看到了去改工艺文件
5. 谁没看到？看运气

研发总监说：“最严重的一次，改了一个零件的材料，微信群通知了采购和工艺，但忘了通知仓库。仓库按旧版材料的库存备料，上线后发现材料不对，那批直接报废。损失大概3万。”

2.2 变更影响范围靠记忆，漏了就是事故

工程师发起变更时，要自己想"这个零件还被用在哪些产品里"。45人的研发团队、几百个产品、几千个零件，靠记忆根本记不全。

有一次一个通用件改了，工程师只想到它用在两个主力产品上，通知了相关人。结果这个件还被用在一个小批量产品上——没人通知，那个产品按旧版做了3个月才发现。

2.3 ERP BOM靠人工改，经常漏改

变更通知发出后，采购要去ERP里手动改BOM。但ERP BOM和PDM BOM的结构不一样——ERP需要的是制造BOM，有虚拟件、包装材料、辅料，PDM导出的是设计BOM。

采购要从设计BOM推导出制造BOM，再在ERP里改。这个过程容易出错，也容易漏改。有一次ERP BOM忘了改，生产按旧版领料，上线后装配不上，停线2小时。

2.4 变更追溯靠翻聊天记录

ISO审核时，审核员问：“这个变更为什么做？谁批的？影响范围是什么？什么时候通知到各方的？”

工程师翻出手机，在微信群里翻了10分钟找到了3个月前的一条消息。审核员说：“这不符合变更管理的可追溯要求。”

三、选型过程

研发总监在选型阶段评估了2个方案：

研发总监选了PDM搭配OIDS，主要原因有三个：

1. PDM不换——四年积累的图纸和版本数据都在PDM里，不想迁移
2. 变更闭环是标准功能——不是定制开发，后续维护风险低
3. 实施团队有达索背景——熟悉SW PDM生态，沟通成本低

四、实施过程

4.1 实施周期

总实施周期约4周（培训+试运行1周，比预期快）。

4.2 实施中的关键动作

关键动作1：变更影响分析配置

把所有产品的BOM关联关系导入OIDS后，工程师发起ECR时，系统自动拉出"这个零件被哪些产品用到、哪些BOM包含它、哪些在制订单受影响"。

原来靠记忆做的事，现在系统自动算。

关键动作2：通知规则配置

按企业实际流程，配置了变更通知规则：

• 设计变更 → 通知工艺+采购+质量
• 材料变更 → 通知工艺+采购+仓库+质量
• 工艺变更 → 通知生产+质量
• 供应商变更 → 通过供应商门户推送通知

通知渠道：工程师推钉钉，采购推钉钉，供应商推邮件。

关键动作3：ERP联动配置

用友U8通过API可配置方式对接OIDS。变更ECN完成后，BOM变更自动推送ERP，ERP里的BOM版本同步更新。接口日志记录每一次传输明细。

五、上线效果

5.1 量化数据

5.2 研发总监怎么说

“最直观的改变是变更通知不再漏人了。以前每次改完图都要反复确认’采购看到了吗？工艺看到了吗？仓库呢？'，现在系统自动通知，通知记录可追溯，我不用操这个心了。”

“变更影响分析这个功能太实用了。以前工程师改一个通用件，要自己想还被用在哪里，想不全就出事。现在系统自动拉出来，一目了然。”

“ERP联动也省了不少事。以前BOM改了还要人工去ERP改，现在ECN走完自动推ERP，省了一道人工环节，也杜绝了漏改的问题。”

5.3 工程师怎么说

“刚开始觉得走ECR→ECO→ECN流程比以前微信群通知麻烦，但用了两周就习惯了。最大好处是不用自己想’还要通知谁’——系统帮我算好了。”

“变更影响分析太好用了。以前改一个件，心里总不踏实，怕漏了哪个产品。现在系统一拉就知道影响范围，心里有底。”

六、这个案例的3个启示

启示1：PDM管不了变更流程，这是结构性问题不是PDM不好用

PDM的定位是管图纸文件，变更管理流程不在它的能力范围内。用微信群补位是临时方案，长期来看一定漏通知、漏执行、漏追溯。

启示2：变更影响分析必须靠系统，不能靠人脑

产品越多、零件越多，靠人脑记"这个件还被用在哪里"就越不现实。BOM关联关系是结构化数据，只有系统能完整管理。

启示3：PDM搭配OIDS是变更管理的最小代价路径

PDM不换、数据不迁移、工程师操作习惯不变——在PDM基础上补齐变更闭环，是实施周期最短、风险最低的路径。

常见问题

Q1：我们企业比这家小（20人研发团队），适合上变更闭环吗？

变更管理的需求和企业规模没有直接关系，和产品复杂度、变更频率有关。如果月均变更超过5次、产品结构超过3层BOM、有多个部门需要协同，就值得上系统化的变更管理。

Q2：我们PDM用了不到一年，现在上OIDS会不会太早？

不早。越早上越早受益——数据量小的时候实施更快，等数据积累多了再上，数据梳理和迁移的工作量更大。

Q3：我们用的不是用友U8，是其他ERP，能对接吗？

通过API可配置方式对接主流ERP系统，支持SAP、用友、金蝶等。具体看ERP类型和集成深度，可以联系我们做集成方案评估。

互动

如果你的企业也在用SolidWorks PDM，变更管理还在靠微信群和Excel，可以联系我们了解变更闭环解决方案，包含ECR→ECO→ECN方案设计和同行业实施案例参考。