跳到主要内容

ERP 厂商停服自救：保留数据库，快速上线智能体

· 阅读需 14 分钟

当 ERP 厂商宣布停服或停止支持时，影响往往远超“IT 问题”。这会迅速升级为业务连续性风险：发货、开票、采购审批、生产计划、合规取证都依赖系统持续可用。

一条可落地的自救路径很清晰：把现有 ERP 数据库当作必须保留的记录系统（system of record），在其上搭建一层轻量动作层，并上线一个连接数据库的 AI 智能体，先从安全的只读流程起步，再逐步升级到受治理的写回。 这条路能争取时间、降低中断成本，并在原 ERP 已不可持续的情况下，为后续升级提供可控的跑道。

ERP“停服”到底意味着什么（为何会很快变得紧急）​

在真实项目里，“ERP 厂商停服”可能对应多种情形，风险形态各不相同：

  • 停止支持（End of Support, EoS）： 厂商停止补丁、修复与常规支持。系统也许还能运行，但风险会逐月上升。
  • 生命周期终止（End of Life, EoL）： 产品线进入退役阶段；兼容性与安全性停滞，集成接口开始陆续失效。
  • 服务停用（Service shutdown / 停服）： 托管服务、许可校验或关键端点停止，ERP 的部分能力可能立刻不可用。

无论是哪一种情形，底层现实一致：业务数据才是核心资产，数据库是最大杠杆。 只要你能掌控数据库，就能稳住运营、重建访问入口，并按自己的节奏完成现代化。

为什么“智能体进入企业应用”正在成为默认方向​

两股趋势正在汇合：

  1. 智能体正在进入企业核心应用。 Gartner 预测：到 2026 年，40% 的企业应用将集成任务型 AI 智能体，2025 年这一比例还不到 5%。
  2. 缺少治理会让很多智能体项目失败。 Gartner 也警告：到 2027 年，超过 40% 的 Agentic AI 项目可能被取消，常见原因是成本失控与结果不清晰，本质上反映了执行控制与运行机制没有在早期设计好。

因此，ERP 停服期间的赢法不在于“立刻全量替换”。更现实的目标是尽快恢复可控能力，再持续放大规模。

核心思路：保留数据库，分层重建能力​

第 1 层：保住记录系统（你的数据库）​

你的 ERP 数据库已经承载了：

  • 主数据（客户、供应商、物料）
  • 交易历史（订单、发票、过账记录）
  • 运营状态（可用量、流程状态）
  • 审计证据（时间戳、审批、用户）

它就是连续性的锚点。

第 2 层：在数据库之上搭一层轻量动作层​

无需先重建完整 ERP 界面，优先交付：

  • 映射到表的模型层（具备 ORM 特性的对象）
  • 面向安全只读的查询层
  • 为后续写回准备的受治理命令层

第 3 层：上线“连接数据库”的 AI 智能体​

智能体可以立刻把自然语言变成：

  • 范围受控的查询
  • 结构化汇总
  • 异常发现
  • 建议动作（配合审批）

这一步会凸显企业开发平台的重要性：你需要可复用的建模、权限与审计能力，让智能体成为“可控的产品能力”，而不是一次性提示词演示。

可复用的术语定义（方便与业务/管理层对齐）​

  • 记录系统（System of record）： 业务真相的权威来源（此处即 ERP 数据库）。
  • 行动系统（System of action）： 决策被执行并落地改变的地方（写回、工单、审批）。
  • 只读优先智能体（Read-first agent）： 从安全查询与证据封装开始，不执行数据库写入。
  • 受治理写回（Governed write-back）： 写入受 schema 约束、权限可控、审批门控、幂等、防重复、全程可审计。
  • 证据封装（Evidence packaging）： 每次输出都附带查询语句/参数、行数统计、引用记录，以便快速复核。

一套务实的自救计划：72 小时 → 30 天 → 90 天​

0–72 小时：稳态、冻结、加固访问​

目标： 防止数据丢失，避免运营陷入混乱。

  • 确保数据库连续性

    • 全量备份并做恢复演练
    • 条件允许时建立只读副本（或逻辑复制）
    • 固化 schema 版本与关键存储过程/作业（jobs）

  • 冻结高风险变更路径

    • 暂停非必要的定制
    • 收紧高风险写入权限

  • 梳理“必须跑”的核心流程

    • 发货放行
    • 发票过账
    • 采购审批
    • 月末对账

若 ERP 属于托管服务或与供应商合同强绑定，需要尽早明确：数据访问与导出权利、时间窗口、删除政策。UNCITRAL 对云计算合同的指引强调：合同应清晰约定数据导出范围与访问方式。

第 3–30 天：交付只读优先智能体 + 最小可用运营控制台​

目标： 为一线团队恢复速度与可见性。

优先交付以下能力：

  • 表到模型映射（Table-to-model mapping）

    • 映射核心表（订单、库存、发票、供应商、客户）
    • 定义关联关系与关键约束

  • 安全查询工具箱

    • “按订单号查询订单”
    • “超过 30 天未回款的未结发票”
    • “按仓库统计库存异常”
    • “对比上周的主要差异排行”

  • 面向业务的智能体入口

    • 支持自然语言提问
    • 输出附带证据（记录、计数、筛选条件、时间戳）
    • 可导出结果集（CSV/Excel）以维持运营连续性

平台化方式能缩短从“只有表”到“可用工作流”的时间。你可以在 JitAI 教程 里查看这一类工作流模式。

第 30–90 天：为高价值动作加入审批与受治理写回​

目标： 把洞察转成可控执行。

用一条严格管线把“答案”升级成“动作”：

  1. 智能体提出变更建议（草案 payload + 理由 + 影响记录）
  2. 执行策略检查（权限、约束、风险等级）
  3. 对高影响动作强制人工审批
  4. 写回执行，带幂等与审计日志
  5. 写后验证查询，确认状态符合预期

许多团队在这一步消耗数月。更稳的做法是：把写回当作带控制面的产品能力来做，从设计阶段就具备约束与可审计性。

参考架构：面向智能体的数据库自救技术栈​

可用于工程评审与安全评审的蓝图：

1）数据平面（Data plane）​

  • ERP 数据库（记录系统）
  • 只读副本 / CDC 数据流（可选）
  • 备份与恢复演练

2）模型与 API 平面（Model & API plane）​

  • 表到模型映射（ORM-like）
  • 带参数校验的查询端点
  • schema 约束的命令端点

3）治理平面（Governance plane）​

  • RBAC/ABAC 权限控制
  • 按风险等级分层的审批工作流
  • 带 before/after 差异的审计日志
  • 策略规则（PII 访问、财务阈值）

ISO/IEC 42001 提供了 AI 管理体系的方法论，适用于映射到智能体控制点：风险评估、生命周期管理、供应商治理等。

4）智能体运行时（Agent runtime）​

  • Tool calling 调用查询/命令端点
  • 每次响应强制证据封装
  • 评估指标：准确性、策略合规、回滚准备度

先自动化什么（高 ROI、低后悔）​

从“降人力”同时“低业务风险”的任务开始：

运营可见性​

  • “哪些订单被阻塞，原因是什么？”
  • “今天哪些 SKU 低于安全库存？”
  • “哪些审批卡住超过 48 小时？”

异常处理​

  • 重复数据（供应商/客户）
  • 跨表状态不一致
  • 过账/发货所需字段缺失

辅助修复（先建议、后执行）​

  • 提出状态修正建议并附证据
  • 提出合并建议并做冲突检测
  • 按规则建议调整审批路由

在审批、审计与回滚策略落地后，再逐步放开写回。

让自救计划安全可控的控制清单​

在允许任何写回之前，确保以下条件成立：

  • 最小权限： 智能体使用受限凭据，杜绝共享管理员账号
  • 动作分级： 低/中/高风险动作走不同审批要求
  • 幂等键： 重试不会造成重复写入
  • 事务边界： 多表更新在需要时保持原子性
  • 审计链： 谁批准、改了什么、何时、为何，信息可追溯
  • 对账作业： 每日检查，发现预期与真实状态漂移
  • 回滚策略： 软删除、冲正分录、补偿事务等可用

这些实践契合一个市场事实：集成能力与受治理执行是企业级 AI 的基础投入。数据集成市场预计从 2025 年 175.8 亿美元增长到 2030 年 332.4 亿美元，反映了企业对可靠连接与数据正确性的持续投入。

JitAI 在哪里发挥作用（保持克制、偏实用）​

ERP 停服期间，团队需要速度，同时也要避免把环境变成脆弱的一次性工程。

平台化方式可以帮助你：

  • 快速把表映射成可复用模型
  • 将受控查询与动作方法暴露为智能体工具
  • 一致地执行权限与审批
  • 维护能跨人员/跨供应商长期存在的审计记录

想快速走通“数据库 → 模型 → 智能体工具”的流程，可从 试用 JitAI 开始；需要建模模式的上手演练，查看 JitAI 教程。

常见坑与规避方式​

坑 1：先重建 UI，后恢复能力​

优先恢复工作流与动作：查询、异常、审批、写回。界面可以后置。

坑 2：让智能体直接写数据库​

把变更统一走动作层与控制面。直写短期很快，长期代价很高。

坑 3：一次性迁移所有东西​

先圈定驱动 80% 日常运营的 20% 流程，稳定后再扩展。

坑 4：跳过证据封装​

用户无法快速复核会直接损害信任，智能体很容易被闲置。

FAQ​

ERP 厂商停服后，我们多快能看到价值？​

许多团队能在数周内通过“保留核心表 + 只读优先智能体”恢复可用的可见性，并逐步迭代到审批与受治理写回。

现代化一定要替换 ERP 吗？​

可以先在原地逐层重建能力：保住数据库，逐步补齐访问层与执行层，之后再决定替换范围与节奏。

第一个允许写回的用例选什么？​

从低风险、可逆的更新开始（标记、路由、状态建议），并要求审批。财务过账与不可逆状态转换建议等控制成熟后再放开。

如何让安全与合规团队放心？​

采用最小权限、审批门控、审计日志、动作分级，并参考 ISO/IEC 42001 等治理框架设计运行机制。

如果合同限制终止后的数据导出/访问怎么办？​

尽早审阅终止与导出条款，明确必需数据集，建立并演练可执行的导出流程。UNCITRAL 的云合同指引强调：导出范围与访问方式需要在合同中清晰定义。