4. 集成需求分析与方案设计方法

在Teamcenter与ERP、MES的集成工程中，最容易被低估、却最容易导致返工的环节，不是接口开发，而是需求分析。很多项目在接口联调阶段才发现“物料主数据到底谁说了算”“工单变更要不要实时下发”“ERP过账失败后MES该不该继续报工”这类问题，根源都在需求阶段没有把业务场景讲清楚。本节围绕一条可落地的方法主线展开：从业务场景出发识别集成需求，逐层定义集成范围、数据流向、触发时机、频率与异常处理策略，最终形成一份可评审、可开发、可验收的《集成需求规格说明书》。

一、从业务场景而不是从接口出发

集成需求最常见的错误起点是“我们要做一个物料接口”。接口是解决方案，不是需求。正确的起点是业务场景：谁在什么情况下、需要什么数据、做什么决策、如果拿不到会怎样。建议用“角色—事件—数据—后果”四要素描述场景，例如：

• 场景A（设计发放）：设计工程师在Teamcenter中完成零件版本发布，工艺与制造需要基于该版本创建BOM和工艺路线，若版本信息延迟，会导致按旧版本备料。
• 场景B（生产执行）：计划员在ERP中下达生产订单，车间需要在MES中接收工单并派工，若工单缺失，产线停线等待。
• 场景C（完工反馈）：MES完成报工与入库，ERP需要据此扣减库存并核算成本，若反馈丢失，账实不符。

把场景列全后，再反向推导需要哪些数据对象、哪些字段、什么方向、什么时机。这样得到的接口清单是有业务依据的，而不是拍脑袋的。

二、定义集成范围：先划边界，再谈细节

范围定义要回答三个问题：集成哪些业务域、覆盖哪些数据对象、哪些明确不做。建议用一张“域—对象—系统归属”的矩阵来锁定边界。以Teamcenter为PLM主系统、ERP为计划与财务主系统、MES为执行主系统为例：

“主数据源唯一”是范围定义中最关键的一条原则：同一个字段只能有一个系统负责创建和修改，其他系统只读。否则一旦出现双写，数据冲突几乎无法收敛。范围之外的内容要显式写出“不纳入本期”，例如“MES不直接修改BOM，仅接收Teamcenter发布的冻结版本”。

三、数据流向、触发时机与频率

范围确定后，逐对象定义流向与时机。流向要明确方向（单向/双向）和同步方式（推/拉）。触发时机通常分三类：事件触发（如版本发布、工单下达）、定时触发（如每15分钟批量同步）、按需触发（如人工点击同步）。频率要与业务时效匹配，而不是越实时越好——实时接口的开发和运维成本显著更高。

下面这张图给出了一条典型的集成数据流与触发关系，可作为方案设计的参照骨架：

图中把三个系统、集成总线、触发时机、频率与异常策略放在同一视图里，目的是让方案评审时能一眼看清“谁在什么时候把什么发给谁、发不出去怎么办”。

四、异常处理策略：需求阶段就要写清楚

异常处理不是开发阶段才考虑的事，而是需求规格中必须明确的内容。至少要覆盖四类：

1. 传输失败：网络中断、中间件不可用。策略是重试，重试次数与间隔要写死，例如3次、间隔30秒/2分钟/5分钟。
2. 业务校验失败：如ERP中不存在该物料、工单已关闭。这类失败重试无意义，应直接进入死信队列并告警，由业务人员处理。
3. 重复消息：必须定义幂等键，通常用“业务单据号+版本号”或“消息唯一ID”，确保重复消费不产生重复过账。
4. 数据不一致：如MES已报工但ERP未收到。需要设计对账机制，例如每日按工单号比对报工数量与ERP入库数量，差异超过阈值触发告警。

五、输出《集成需求规格说明书》

需求分析的最终交付物是《集成需求规格说明书》，它既是开发依据，也是验收标准。一份可用的规格书至少应包含以下内容，建议按接口逐条编写：

规格书完成后，应组织PLM、ERP、MES三方以及业务代表进行评审，重点确认主数据源、触发时机和异常责任。评审通过后冻结版本，后续变更走变更流程。这样，集成方案才具备可开发、可测试、可运维的基础。