企业管理软件 AI 化重构⑥:企业选型,不能只看 Demo 漂亮

你是一个CIO，正在参加一场AI ERP 选型会。

供应商的演示很精彩。采购经理在对话框里说一句话，AI自动生成采购订单；老板问一句“这个月经营情况怎么样”，AI 输出一份图文并茂的分析报告；销售负责人追问库存风险，AI 立刻给出补货建议。现场很顺，屏幕很漂亮，所有动作都像提前排练过一样流畅。

但你隐约感觉，有些问题被绕过去了。

如果数据不完整，AI怎么办？如果规则刚改过，AI 用新规则还是旧规则？如果权限不够，AI 会停下来，还是继续给出答案？如果AI 自动生成了错误订单，系统能不能说清楚这个错误是怎么发生的？

这才是企业买AI ERP 时真正该问的问题。

ERP的AI 化，不是把AI 接到系统上，而是把企业业务拆成可理解、可调用、可治理、可审计的能力网络。

前面几篇，我讲了入口迁移、Skill契约、AI 入口之争、权限治理，以及AI ERP 为什么不要一上来就自动执行。这一篇，要回到一个更现实的问题：

企业买AI ERP，到底应该看什么？

很多企业选AI ERP 的时候，最容易被Demo 打动。一句话下单，自动生成采购订单；说几句话，自动输出经营分析报告；问一个问题，AI 立刻给出库存建议、供应商建议、费用异常分析。这些演示都很漂亮，也很容易让人产生一种感觉：这个系统已经很智能了。

但我要提醒一句：

Demo是晴天展示，不是雨天测试。

供应商展示给你的，往往是数据干净、规则清楚、权限顺畅、流程完整的理想路径。而企业每天面对的真实业务，恰恰不是这样。

真实业务里，数据会缺，规则会变，权限会交叉，流程会中断，责任会追溯。

所以，买AI ERP，不能只看Demo 漂亮。真正要看的，是它在“雨天”会不会停得住、说得清、追得回。

更准确地说，所有问题最后都指向同一个东西：

边界。

AI ERP的成熟度，不在它回答得多漂亮，而在它的业务边界有多清楚。它能做什么，它不能做什么，它做错了怎么办，这三个问题才是AI ERP 选型的底层问题。

01一个漂亮Demo，是怎么埋下风险的？

先讲一个真实场景。

某企业选型AI ERP。供应商做了一场漂亮的Demo。

现场演示时，一个采购经理在对话界面说了一句话，AI就直接生成了采购订单：供应商自动匹配，数量按历史采购量推荐，单价调用最新合同价。全场鼓掌。

接着，供应商演示库存智能分析。AI自动识别出三个高周转SKU，建议加大备货量，销售VP 看了连连点头。随后又演示报表自动生成，管理者口播几句需求，AI 输出了一份月度经营分析报告，包含关键指标、异常波动和优化建议。

老板说：

不错，就这个了。

合同签了，系统上线了。六个月后，问题开始集中出现：AI生成了200 多个错误订单，库存建议导致部分商品爆仓，经营分析报告里的指标口径和财务报表对不上。

后来复盘才发现，很多问题不是AI “不会回答”，而是它在不该继续执行的时候继续执行了。有些错误订单，是因为AI 调用了过期合同价；合同价格已经更新，但测试环境和生产环境之间的数据同步没有打通。有些库存建议，是因为AI 只看到了高周转，没有看到仓储容量和季节性波动。有些报表差错，是因为AI 使用了销售口径的数据，却输出成了财务口径的经营分析。

企业去找供应商，供应商回复：

你们没有正确配置业务规则。

老板很愤怒。但真正的问题，并不是实施阶段才出现的，而是在选型阶段就已经埋下了。

因为整个选型过程里，所有人都在看Demo 展示了什么，却没有人问：

Demo没有展示什么？

这是企业买AI ERP 最容易踩的坑。Demo 展示的是系统最好的一面，但企业真正要买的，是一个能进入真实业务现场的系统。

02 Demo展示的是晴天，企业要问雨天

Demo的天然属性，是展示最好的一面。选AI ERP 的时候尤其如此。

供应商一定会展示几条“完美路径”：一句话下单，AI自动比价，语音生成报表，智能识别库存风险，自动输出经营建议。每一段操作都是设计好的，数据是干净的，条件是最优的，不确定性被完全排除在外。

但企业每天面对的业务，不是这样运行的。

采购订单遇到一个临时供应商，系统里没有历史数据，AI怎么处理？库存水位因为接口延迟出现了数据不一致，AI 是继续计算，还是标记异常？业务规则上个月刚改过，AI 用旧规则还是新规则？一个操作同时涉及采购、财务、仓储三个模块，权限发生交叉，AI 能做完吗，还是必须停下来？

这些场景，Demo通常不会演示。不是演示方一定不诚实，而是Demo 本身就是一个“晴天展示”。它负责让你看到系统能做什么，但企业真正要问的是：

当数据不完整、逻辑有冲突、权限有交叉、规则有变化的时候，AI怎么办？

好的AI ERP，不是永远给出答案，而是该回答时回答，该建议时建议，该执行时执行，该停下来的时候必须停下来。

所以，选型时真正该问的，远不止“这个功能能不能演示出来”，还包括四组更关键的问题：

第一，AI到底有没有真实业务能力？第二，AI 的权限和边界清不清楚？第三，AI 出错以后，企业能不能控制住？第四，AI 上线以后，能不能持续运营？

这四组问题，问来问去，其实都在问同一件事：

这个AI ERP 知不知道自己的边界在哪里？

03先看能力：它是真业务能力，还是聊天窗口？

我最怕看到一种Demo。

用户问：

帮我分析一下这个月采购情况。

AI很快输出一段话：

本月采购金额较上月有所增长，建议优化供应商结构，加强采购成本控制。

这段话看起来很像经营分析。但你往下追问：你刚才用了哪些采购数据？查的是ERP 里的订单，还是SRM 里的报价？有没有调用合同价格？有没有排除已作废订单？

对方开始含糊的时候，你就要警惕：它可能不是在调用业务能力，只是在生成一段业务口吻的文字。

真正的AI ERP，应该能调用真实的业务能力单元，比如采购评估Skill、库存预警Skill、合同风险检查Skill、费用异常分析Skill、供应商准入评估Skill。每一个Skill 背后，都应该是一整套可执行、可审计、有边界的业务逻辑，而不是一段提示词拼出来的对话回复。

判断方法很简单。你可以问供应商：

如果业务数据断开了，这个功能还能不能正常工作？

如果AI 还能继续生成一段很流畅的文字，但它没有真实数据依据，那你看到的很可能不是AI ERP，而是一个聊天窗口。

再往下看，还要看它能不能跨模块编排完整业务任务。

企业里的业务动作，通常不在一个模块里完成。比如“补充一批原材料”，至少涉及查库存水位、判断是否低于安全库存、选择供应商、检查采购价格、申请预算、生成采购申请、进入审批流程等多个动作。

Demo里，每个功能通常是独立展示的。演示采购就说采购，演示库存就说库存，演示报表就说报表。但真实业务里，一个业务意图往往需要跨模块串联。AI 能不能理解一个“补充原材料”的指令，自己判断需要调用库存查询Skill、供应商比价Skill、预算检查Skill，并按正确顺序执行？

如果只能单点问答，不能跨模块编排，那它更像一个智能查询助手，而不是AI ERP 的业务调度中枢。

最后，还要看它能不能接入企业现有系统的数据。

没有一家企业的ERP 是孤岛。核心ERP 可能是用友、金蝶、SAP，OA 是另一套，采购有SRM，销售有CRM，财务核算还有独立系统，有些企业还有MES、WMS、BI、电子签章、发票系统和外部工商信用接口。

一个采购评估Skill，可能需要从ERP 拿历史交易数据，从OA 拿审批记录，从SRM 拿供应商报价，从外部接口查工商风险。如果AI 只能接自己的ERP，不能接其他系统，那它在真实业务中的价值会被严重限制。

所以，第一组问题问的是能力真实性：

它到底是真正进入业务系统了，还是只是在业务系统旁边聊天？

04再看边界：它知道自己能做到哪里吗？

能力越强，越要问边界。

AI以谁的身份在操作？

采购员能看到供应商信息，但不一定能看到所有采购价格；部门经理能看到预算总额，但不一定能看到所有明细；财务能看到付款记录，但不一定能看合同条款；老板能看集团经营数据，但普通员工不能。

如果以采购员身份问AI，AI 能看到什么？如果以总经理身份问AI，AI 又能看到什么？有没有可能，一个普通员工通过AI 看到了他不该看的数据？

这不是小问题。

AI不能是一个“全知全能”的超级账号。它必须继承操作者本人的岗位角色和权限边界，并且在超出边界时知道停下来。否则，AI 越聪明，越可能变成企业权限体系里的漏洞。

还要看它是否区分查询、生成和执行三层风险。

查一个数据，风险最低。比如“上个月销售额是多少？”查错了，最多是信息不准确。生成一个建议，风险中等，比如“建议加大这个SKU 的采购量”，它只是给人参考，最终决策还是人做。执行一个动作，风险最高，比如直接下单、直接付款、直接修改价格、直接触发审批，错了就是真实的业务损失。

好的AI ERP，应该天然区分这三层：查询层可以相对开放，生成层需要人确认，执行层必须经过严格条件校验、权限判断、异常中断和审计留痕。

如果你发现AI 在查询、生成、执行三层之间的权限一样、流程一样，那它本质上就是一个“不分轻重的执行器”。这很危险。

尤其要追问一条链路：

AI输出之后，是人工确认，还是默认生效？

AI可以自动生成采购订单，但不意味着它可以直接提交订单；AI 可以生成付款建议，但不意味着它可以自动付款；AI 可以输出合同风险报告，但不意味着它可以替法务签字。

Demo里，AI 生成订单的动作往往一气呵成。但现实里要看清楚，AI 输出之后，到底是进入人工确认，还是默认直接生效。

前者是助手模式，后者是风险模式。

成熟的AI ERP，应该能清晰设计“AI 输出→ 人工确认→ 生效执行”这条链路。尤其在生成型和执行型场景里，不能把“生成”偷换成“执行”。

这一组问题，问的是边界治理：

它到底知道自己能做到哪里吗？

05关键看出错以后：能不能查清、停住、回滚、追责？

AI一定会犯错。关键是犯错以后，企业能不能控制住。

选AI ERP 时，你可以直接问供应商：

刚才那个采购订单是怎么生成的？

好的AI ERP，应该打开一张审计卡，而不是重新生成一段解释。

这张审计卡上，至少应该能看到任务发起人是谁、AI以什么身份执行、调用了哪个业务Skill、读取了哪些数据、使用的是哪个规则版本、是否触发过异常判断、是否经过人工确认、最终结果有没有回写ERP。

如果是采购订单，还应该能看到当时的数据快照：合同价是多少，库存水位是多少，供应商评分是多少，预算余额是多少。只有这些信息能被打开，企业才有可能判断这个订单是数据错、规则错、Skill判断错，还是人类确认错。

这才是审计留痕。

一般的AI ERP，可能只能给你一段解释：

根据历史数据，我判断这个订单需要下单。

这听起来合理，但它不是日志。

判断方法也很简单。制造一个错误订单，然后问供应商：

你怎么查到这个错误是怎么发生的？

如果他们说“我可以让AI 再分析一次”，那系统很可能没有真正留痕。如果他们打开审计页面，清楚列着每一环的操作记录、调用时间、数据快照、决策依据和确认人，那才是全链路留痕。

接着再问：

AI出错时能不能中断、回滚和追责？

假设AI 连续生成了三份错误采购订单：第一份已经提交，第二份还在审批中，第三份刚生成出来。系统能不能回滚第一份，取消订单并恢复库存状态？能不能及时拦截第二份，阻止它进入下一环？能不能直接把第三份判定为异常，禁止继续操作？

更重要的是，系统能不能追责。错误的源头到底是模型判断错、业务规则配置错、数据本身错、某个Skill 的边界没设计好，还是人类确认时没有审核？

Demo永远不演示“怎么修复错误”，但企业上线后的每一天，都在和错误打交道。一个AI ERP 是否成熟，不看它在演示里多顺，而要看它在错误发生后能不能被控制住。

这一组问题，问的是风险控制：

它犯错后能不能被发现、被中断、被回滚、被追责。

06上线之后呢：能不能持续运营？

选型时还有一个容易被忽略的问题：上线之后，谁来持续运营AI 能力？

AI ERP上线，不等于AI ERP 跑起来。企业管理规则不是一成不变的，采购金额超过多少需要集团审批，上个月标准是50 万，这个月可能改成30 万；供应商准入标准可能调整，过去只查工商资质，现在还要查环保合规记录；预算审批链条也可能变化，原来是部门经理批完财务总监批，现在改成先过预算委员会。

这些规则变化以后，AI能不能跟着调整？

如果每次调整都需要重新训练模型、重新写代码、重新录入大量数据，那这个AI ERP 到企业手里，很快就会变成一个“死的AI”，因为它跟不上业务变化的速度。

好的AI ERP，应该把规则、Skill、权限、异常条件设计成可配置、可调整、可运营的机制。

除此之外，还要看它有没有运营分析机制。

上线后，谁在用？用得怎么样？哪些Skill 使用率高？哪些Skill 基本没人用？AI 的判断准确率是多少？异常集中在哪些流程？哪些用户经常修改AI 输出？哪些场景经常需要人工介入？

这些不是技术问题，而是能力运营问题。

一个成熟的AI ERP，不应该只是“提供了AI 能力”，还要能回答：AI 能力用得怎么样，哪些能力值得继续优化，哪些能力没有进入真实业务，哪些异常正在反复出现。

花钱买一个系统，不应该只知道“现在能用”，更应该知道：

用得怎么样，还能不能更好。

这一组问题，问的是持续运营：

它上线后是不是还能持续变好？

07选型时，把这十个问题带进会议室

前面四组问题，最终都指向同一件事：边界。

Demo展示的是AI 能做什么，企业真正要问的是：AI 不能做什么？AI 做错了怎么办？AI 上线后还能不能持续变好？

下次选型时，可以把这十个问题直接带进会议室。

第一组：能力是不是真的？

AI能不能调用真实业务Skill？

AI能不能跨模块编排完整业务任务？

AI能不能接入企业现有系统数据？

第二组：边界清不清楚？

AI是否继承操作者的岗位角色和权限？

AI是否区分查询、生成和执行三层风险？

AI输出后是否需要人工确认，还是默认生效？

第三组：出错能不能控制住？

AI执行过程能不能全链路留痕？

AI出错时能不能中断、回滚和追责？

第四组：上线后能不能持续运营？

业务规则能不能灵活配置和迭代？

AI有没有运营分析机制？

这十个问题，不是为了为难供应商，而是为了判断一件事：它卖给你的，到底是一个漂亮Demo，还是一个可进入真实业务现场的AI ERP？

一个好的AI ERP，不只是会回答问题，也不是永远显得很聪明。它应该清楚告诉使用者三类信息：它能做什么，它在什么条件下不能做，它做错了怎么办。

Demo展示的，永远是“能做的部分”。你真正要看的，是供应商能不能回答：

不能做时怎么办？做错了怎么办？

前面文章里我讲过一句话：

Skill是契约，不是规格说明书。

这句话放到AI ERP 选型里，也同样成立。规格说明书定义每一步做什么，契约定义原则和边界。

一个好的AI ERP 产品，本质上就是一组写得很好的业务契约：它告诉AI 什么可以做，什么需要问人，什么条件下必须停下来，什么结果必须被审计。

这十个问题，拆开来看，每一个都是在问这份契约写得好不好。

08 Demo是发布会，不是尽职调查

企业买AI ERP，有点像招一个正式员工。

你不会只问“你会什么”，还会问：你之前在哪里做过，出了错怎么补救，在什么情况下不适合这个岗位，能不能遵守公司的权限和流程，能不能持续成长。

如果招的是财务总监，你不会只听他讲自己做过多少报表、管过多少预算。你会做背景调查，会问他处理过什么风险事件，会看他在压力场景下怎么决策，会确认他有没有守住底线的能力。

选AI ERP 也是一样。

你招的不是一个“会说话的对话窗口”，而是一个会进入企业流程、调用企业数据、代表员工操作、对业务结果产生影响的数字员工。

所以，别只看Demo。

Demo是发布会，不是尽职调查。

下次选型会上，当供应商结束那场精彩演示后，请合上笔记本，看着他们，然后问一句：

如果今天不是我的人操作，是AI 自己做的——出了错，你打算怎么担保？

这个答案，比任何一个功能演示都更值得写进合同。