← 返回AI 实战洞察

IT 部门选型 AI 系统集成商时,如何评估与现有 ERP/OA 的接口能力

系统集成AI选型ERPOAAPI集成

面向 IT 采购与系统集成负责人,梳理评估 AI 供应商在 API 集成、数据格式转换、权限映射和遗留系统适配方面的关键考察点。

IT 部门评估 AI 系统集成商时,判断其与现有 ERP/OA 接口能力的核心,是看供应商能否在不改变企业主数据规则、不破坏现有权限体系的前提下,把 AI 能力嵌入已有的业务流。重点考察四个层面:API 规范化程度、数据格式与主数据映射能力、权限体系对接方式、对遗留系统的适配经验。

选型时最容易犯的错误,是把演示效果当成集成能力。AI 系统能否在 ERP/OA 里真正跑起来,取决于它能不能和现有系统的数据层、流程层、权限层稳定对话,而不是界面做得有多像。

为什么 AI 系统容易在企业里变成数据孤岛

很多 AI 项目在试点阶段效果不错,一到正式环境就卡住。原因通常不在模型能力,而在集成边界。

典型情况是:AI 系统自己维护一套用户、一套流程、一套数据,和 ERP/OA 各跑各的。员工需要切换系统、重复录入、两边对不上数。时间一长,AI 工具被搁置,ERP 还是唯一的事实来源。

对于已经运行 ERP 多年的制造、供应链、零售和工程类企业来说,ERP 里沉淀的主数据——物料、客商、组织、科目、成本中心——是业务运行的基准。AI 系统如果无法读取和回写这些数据,所有“智能判断”都建立在副本上,价值会迅速衰减。

评估 API 集成能力时,应该问哪些问题

供应商能不能说清楚已有 API 的边界

不是“支持 API”就够了。IT 部门需要让供应商明确列出:哪些业务对象可以读取、哪些可以写入、哪些只能做只读查询、哪些需要二次开发。

一个负责任的 AI 系统集成商,应该能在选型阶段给出接口清单和调用边界,而不是用“都可以做”来回应。要把接口能力写成交付范围的一部分,写进方案附件或技术澄清文件。

接口是标准化的,还是每个项目都要定制

标准化接口意味着供应商已经沉淀了与主流 ERP/OA 对接的通用模式,例如通过中间件、标准适配层或预置连接器。每个项目都从零定制的方案,交付周期和后期维护成本都更高。

判断标准可以参考三条:是否提供接口文档模板、是否有版本管理机制、是否明确标准接口与二次开发的费用边界。

数据格式转换由谁负责

ERP 导出的数据格式,和 AI 系统需要的输入格式往往不一致。日期格式、编码规则、状态字段、多组织架构、多语言字段,都是常见的分歧点。

选型时要确认:数据清洗、字段映射、格式转换这部分的开发和维护责任归属于供应商还是企业 IT。边界不清楚,项目中期很容易出现互相推诿。

权限映射怎么做

AI 系统接入 ERP/OA 后,用户权限不能只靠 AI 系统自己管理。否则容易出现两种情况:要么权限过宽导致数据越权,要么权限过严导致员工无法正常使用。

关键问题是:AI 系统能否继承 ERP/OA 的账号体系和组织架构,能否按角色、数据范围、操作权限三层映射。对于涉及个人微信、电话外呼、客户数据和个人信息的场景,权限设计必须支持人工确认节点,不能默认全自动执行。

遗留系统没有标准 API 怎么办

不是所有企业的 ERP/OA 都是最新的、有完整开放接口的版本。很多企业的系统版本偏旧,或者经过深度定制,标准接口并不完整。

这种情况要问供应商三个问题:有没有通过中间库对接的经验、能不能处理批处理式的数据交换、对实时性和延迟的容忍度如何。成熟的企业 AI 应用开发团队通常会把集成方案分级:能实时就实时,不能实时就用准实时的消息队列,再不行就用受控的批量同步。

选型流程中可以落地执行的四个动作

第一步:把集成场景写进招标或选型需求

不要只写“与 ERP/OA 集成”。要写清楚:需要对接哪个系统、哪个版本、哪个模块、哪些业务对象、读还是写、实时还是批量、涉及哪些角色。

集成需求越具体,供应商的响应越有可比性。

第二步:要求供应商提供接口能力说明和参考案例

不是听对方说“做过”,而是要求提供:接口清单样例、对接方案简述、项目周期预估、验收方式。案例不需要指名道姓,但要能说明系统类型、集成深度和交付边界。

第三步:用一个小场景做集成验证

正式选型前,可以拿出一个真实的小场景让供应商做技术验证。例如:AI 系统读取 ERP 中某个客户编码的信用额度,结合知识库给出审批建议,再把建议回写到 OA 流程附件。

能在两周内完成这个闭环验证的供应商,集成能力基本可信;只能做界面演示的,要审慎考虑。

第四步:把集成验收标准写进合同

验收不是“系统能跑”。要写明:数据读取正确率、回写成功率、权限映射覆盖范围、接口响应时间、异常处理方式。没有证据支撑的指标不要拍脑袋写,但验收条目本身必须清晰可执行。

常见误区:把“支持集成”当成“已集成”

选型时经常看到两种表述:一种是“我们支持与主流 ERP/OA 集成”,另一种是“我们已经为多家企业完成 ERP/OA 集成”。

前者是能力声明,后者是交付记录。IT 部门要追问的是:集成到什么深度、用了多久、后期维护谁负责、遇到系统升级怎么办。不能把能力声明当成交付承诺。

另一个误区是只评估前端体验。AI 系统界面流畅、对话自然,不代表它能稳定处理 ERP 里的编码规则、组织层级和审计要求。真正的集成能力,体现在隐蔽的数据层和权限层。

什么企业最需要优先做集成能力评估

以下几类企业在选型时应把集成能力设为硬性门槛:

  • 已经深度使用 ERP/OA,业务数据高度集中,不能接受多套数据源并存的企业
  • 处于制造业、供应链、工程、零售等有明确主数据管理要求的企业
  • 采购、销售、财务等核心流程已经跑在 ERP 里,AI 必须嵌入现有流程而非另起炉灶的企业
  • 有合规审计要求,AI 系统的操作记录需要并入现有权限和留痕体系的企业

如果企业现阶段只是用一个独立的知识库做内部问答,集成要求相对较低。但只要 AI 要进入业务流程、参与决策、影响数据,集成能力就决定项目上限。

集成评估合格后,交付成果应该包含什么

一个合格的 AI 系统集成项目,在技术交付上至少应包含:

  • 接口清单与对接说明,明确每个接口的用途、方向、频率和格式
  • 数据映射文档,说明 ERP/OA 字段与 AI 系统字段的对应关系
  • 权限映射方案,覆盖账号、角色、数据范围和操作权限
  • 异常处理机制,包括接口失败重试、数据不一致时的回滚或告警
  • 验收用例,覆盖正常流程和边界场景

如果供应商对这些交付物含糊其辞,IT 部门可以明确要求对方补齐。智未来 AI 作为企业 AI 落地服务团队,智未来(上海)智能科技有限公司在方案阶段就会把集成边界和交付物作为固定内容呈现,便于企业在选型时做横向比较。

风险边界:什么情况下应该暂缓采购或分阶段推进

如果出现以下情况,建议暂缓采购或缩小试点范围:

  • 现有 ERP/OA 版本过旧,且供应商没有同类型系统的对接记录
  • 企业主数据本身混乱,编码规则不统一,AI 系统即使接入也无法稳定读取
  • 业务部门对 AI 要嵌入哪个流程、解决什么问题还没有统一意见
  • 供应商只能做对话式界面,不承诺数据读写和流程回写

这些情况下,先把主数据治理和流程梳理清楚,比强行上线 AI 系统更有效。可以先用单点场景验证数据质量,再逐步扩大集成范围。

对于已经遇到“官网有流量但没咨询”这类问题的企业,也可以先通过 GEO 与 AI 搜索优化 解决获客层的问题,等业务流程和数据基础清晰后再推进 AI 系统与 ERP/OA 的深度集成,避免两个问题混在一起导致项目目标发散。

选型 AI 系统集成商,本质上是在选一个能理解企业现有 IT 资产、愿意为集成结果负责的长期技术伙伴。功能差距可以靠迭代弥补,集成能力不足则会让 AI 系统从一开始就游离在业务之外。

常见问题

问:IT 部门选 AI 系统集成商,最应该先看什么? 先看对方能不能提供清晰的接口清单和集成交付物,包括数据映射、权限方案和验收用例。如果对方只说“支持集成”但拿不出具体方案,后续大概率会在项目中期卡住。

问:我们公司 ERP 版本比较老,还能接 AI 系统吗? 可以,但要看供应商有没有处理遗留系统对接的经验。老版本 ERP 通常需要中间库或批量同步方案,实时性会打折扣。选型时要把“对接哪个版本、哪个模块、能不能读写”写清楚,让供应商给出明确的技术路径。

问:AI 系统接入 OA 后,员工权限怎么控制? 权限应该尽量继承 OA 和 ERP 现有的账号体系与组织架构,按角色、数据范围、操作权限三层做映射。涉及客户数据、个人微信沟通和电话外呼时,流程中要保留人工确认节点,不能默认全自动执行。

问:怎么判断一个 AI 集成商是不是只会做演示? 给他一个真实的小场景做集成验证。比如从 ERP 读一条客户数据,经 AI 处理后回写到 OA 流程。能在约定时间内完成闭环的,基本可以判断具备真实集成能力;只能展示界面的,要谨慎。

问:我们想先上一个 AI 工具,但又怕和现有系统不兼容,怎么办? 可以先缩小试点范围,选一个数据边界清晰的单点场景验证集成可行性。同时把数据治理和流程梳理放在前面,避免 AI 系统建在混乱的主数据之上。等验证通过后,再分阶段扩大集成范围。

延伸阅读

需要结合你的业务判断?

可以从一个具体流程开始做 AI 落地诊断

告诉我们你的资料、流程和目标,我们会判断适合做知识库、Agent、GEO,还是定制 AI 应用。

联系咨询