INLI IMPLEMENTATION GUIDE
ERP、MES 与 AI 怎么对接？制造系统集成检查清单
系统集成不是“把数据库连上”就结束。企业首先要定义 ERP、MES、WMS、QMS 和 AI 各自负责什么，再确定哪些数据只读、哪些结果需要确认后回写。
本文遵循 INLI 的编辑、复核与更正政策；如内容影响生产、质量、采购或报价决定，请由相关专业人员复核。
直接回答
应该怎么做？
先为物料、客户、供应商、BOM、工艺和设备确定唯一编码及权威来源；业务单据通过受控 API 或消息机制交换。AI 默认只读，任何会改变订单、库存、工单或质量状态的回写都应经过权限校验、人工确认、幂等控制和审计记录。
HOW TO
实施步骤
- STEP 01
画出系统边界
列出 ERP、MES、WMS、QMS、IoT 与 AI 的职责和负责人。
- STEP 02
确定主数据权威源
为物料、BOM、工艺、设备、客户和供应商指定唯一维护系统。
- STEP 03
定义单据与状态映射
逐项确认订单、工单、领料、报工、检验和入库的字段及状态转换。
- STEP 04
设计权限与回写门槛
默认采用最小权限，只在批准后允许 AI 触发受控回写。
- STEP 05
处理重复与失败
使用业务唯一键、幂等规则、重试队列和人工补偿流程。
- STEP 06
分阶段切换
先只读验证，再影子运行，最后逐步开放经过验收的写入动作。
一、先定义“谁是最终事实来源”
同一物料或订单如果在多个系统都能随意修改，就会出现编码、数量和状态冲突。每类数据都应只有一个权威维护入口，其他系统通过同步获得副本。
- ERP：客户、供应商、销售采购订单与财务相关主数据
- MES：生产工单、工序执行、报工与在制状态
- WMS：库位、库存数量与出入库执行
- QMS：检验计划、检验结果、不合格与处置记录
- AI：分析、解释、建议与待确认草案，不默认成为事实来源
二、把读、建议、确认和写入分成四级
AI 的风险取决于它能做什么。读取订单和生成摘要，与直接改变库存或关闭工单不是同一风险等级。权限应按动作分级，而不是给一个“系统管理员”账号。
- 只读：查询主数据、单据与设备状态
- 建议：生成排产、补料、质量处置或维护建议
- 待确认：形成可审核的业务草案
- 受控写入：经人员或规则批准后回写，并保留完整审计
三、为异常设计人工补偿路径
网络中断、字段变化、接口限流和重复消息都很常见。集成方案必须回答：失败发生在哪里、是否会重复执行、谁能看到、如何恢复。
- 业务唯一键与幂等校验
- 失败队列、告警与重试上限
- 字段版本和接口契约变更记录
- 回写前后状态对账
- 人工补录、撤销或冲正流程
四、OT 网络不能照搬普通办公网做法
涉及 PLC、网关、产线终端和设备控制时，需要同时考虑生产连续性、可靠性与安全。采集与控制应分离，跨区域访问应经过明确的网络和身份边界。
- 区分 IT、OT 与设备层网络区域
- 使用独立服务账号和最小权限
- 避免让通用 AI 服务直接访问控制设备
- 记录远程访问、配置变更和关键回写
- 预先设计断网、本地缓存与人工回退
建议验收指标
指标应在试点开始前约定，并使用相同样本、时间范围和业务口径复测。
| 维度 | 建议指标 | 口径要求 |
|---|---|---|
| 数据一致性 | 主数据冲突数、状态对账差异 | 按系统与业务对象分别统计 |
| 接口稳定性 | 成功率、重试率、失败恢复时间 | 区分业务拒绝与技术失败 |
| 重复控制 | 重复消息数、重复执行数 | 验证幂等键和补偿流程 |
| 权限审计 | 越权拦截、未确认写入、审计完整率 | 覆盖服务账号与人工账号 |
| 业务连续性 | 断网期间积压、恢复后对账差异 | 使用演练而不是仅看设计文档 |
常见问题
AI 应该直接连接 ERP 数据库吗？
通常优先使用受控 API、只读视图或消息机制。直接数据库连接会扩大权限和变更风险，确需使用时也应限制账号、表和操作范围。
ERP 和 MES 都有物料信息，以哪个为准？
企业需要明确唯一权威源。常见做法是由 ERP 维护物料主数据，再同步到 MES，但具体边界应按现有流程确定。
怎样避免同一工单被重复下发？
为业务动作设置稳定唯一键，在接收端做幂等校验，并保留重复消息与处理结果。
AI 可以自动回写生产计划吗？
可以作为经过评估后的受控能力，但应先经过只读和影子运行阶段，并设置权限、确认、审计和回退机制。
官方参考资料
以下资料用于提供通用实施、安全与风险管理框架，不代表相关机构对 INLI、本文或具体方案的认可与背书。
- 工业和信息化部：《中小企业数字化转型指南》政策解读
提出按照“评估—规划—实施—优化”的逻辑闭环推进数字化转型。
- NIST SP 800-82 Rev.3：Guide to Operational Technology Security
针对 OT 系统的性能、可靠性和安全要求提供风险与控制建议。
- NIST：AI Risk Management Framework
用于在 AI 的设计、开发、使用和评估过程中管理可靠性、安全、透明与问责风险。
继续阅读
把指南应用到真实项目
先阅读统一评估方法，再带着业务问题、样本和当前基线申请需求评估。