制造业 ERP 集成：把 SAP、Dynamics 与 Navision 连到车间

每家同时运行 ERP 与车间系统的制造企业，最终都会遇到同一种不一致。ERP 显示订单已完工，车间却清楚有两托盘返了工；ERP 按标准用量记录了物料消耗，实际消耗里却包含了没人登账的报废。两个系统都没有说谎，它们描述的是不同的时刻——ERP 描述计划及其财务后果，车间描述物理现实——而集成，就是让这两种描述保持一致的功夫。

第一个设计决策是"归属方向"，而这一点弄错，正是集成项目始终无法稳定下来的最常见原因。主数据——客户、供应商、物料、物料清单、工艺路线、价格——归 ERP 所有，向下流动。执行数据——实际开工与完工时间、实际产量、报废、停机原因、设备状态、人员分配、真实物料消耗——在车间产生，向上流动。当两个系统都被允许编辑同一个实体时，您得到的不是集成，而是一场配了同步计划表的持续争执。

向下流动通常是较简单的一半。ERP 中下达的生产订单连同其工序、工艺路线和物料清单出现在 MES 中；物料主数据变更自动传播；客户与交付数据到达需要它们的系统。主要的现实难点在于粒度：一张 ERP 生产订单往往对应跨多个工作中心的若干车间工序，ERP 结构与可执行结构之间的映射需要被有意识地定义，而不是想当然。

向上流动才是价值所在，难度也集中于此。报工——那些说明"本工序生产了多少、消耗了什么物料、耗时多久、报废多少"的消息——驱动着 ERP 的库存、成本和产能数字。当这些数据由设备和车间终端自动采集，而不是下班时凭记忆敲进去时，ERP 的数字就不再是近似值。成本核算会立刻改善，因为实际工时取代了标准工时。

可选的集成模式，差别主要在延迟与耦合度。基于文件的交换简单、通用支持，但不可避免地是批处理式的。直连数据库速度快但脆弱，会以难以预料的方式在厂商升级时断裂。REST 与 SOAP 接口——SAP 通过 IDoc、BAPI 或 OData，Dynamics 365 与 Business Central 通过其公开 API——是现代默认选择，版本演进也从容得多。消息队列则为高频事件增加了韧性，因为无论 ERP 在不在线，车间都在持续产生数据。

最后这一点值得强调，因为脆弱的集成正是在这里现形。ERP 停机时生产不会停。如果您的集成是同步的，而 ERP 正在计划性维护中不可用，那么要么车间停摆，要么数据丢失。采用队列缓冲的设计能让 MES 继续采集，并在连接恢复后补投积压——在多班次运行的工厂里，这不是边缘情况，而是每月都会遇到的现实。

本地与区域性 ERP 系统会带来一种特定的复杂性。全球套件有完善的接口文档和庞大的集成生态；而区域性产品——Panteon、Logo、Nebim 以及其他市场的同类——在中型制造企业中十分普遍，往往被深度定制，且很少有现成的 MES 连接器。这不是更换一套运行良好的 ERP 的理由，而是把集成层当作项目一等公民、而不是想当然的细节来对待的理由。

对账是最常被从项目计划里省略、随后吞掉运行头三个月的部分。消息会失败；报工会因物料被冻结而被拒绝；生产订单在车间已经开工后被人在 ERP 里删除。每一套集成都需要一个可查看的队列、一套重试机制、一个会提醒人的错误状态，以及一份定期对账报表，用来证明车间记录的与 ERP 持有的仍然一致。缺少这些的集成不会大声失败，它们会悄悄漂移，而那更糟。

经得起现实检验的范围建议是：先从一条产线上的一种订单类型入手，把从 ERP 下达、到车间执行、再回传报工的完整闭环跑通，然后再扩大。横跨所有工厂和订单类型的"大爆炸式"集成，其失败方式极难诊断，因为当一切都是新的，就没有任何东西可以当作参照。