不换ERP也能上AI：查数、分析、代办业务实战

上周一位做精密制造的朋友跟我聊了近一个小时核心就一句话公司用了十多年的ERP老板最近天天在问AI能不能直接从系统里把数据要出来。他的困境很有代表性——流程单据全在老系统里历史数据动不得换套系统又得按年算周期风险大到没人敢拍板。我给他的回答也很直接换不换ERP不是关键真正要解决的是怎么让AI和存量ERP系统协作。这篇文章就是我帮多家制造、贸易、服务类企业做存量ERPAI落地时的经验整理专门聊三件事让AI查询数据、让AI分析经营、让AI代办业务。内容偏实操会给出账号权限、查询视图、Python连接Oracle的脚本、指标字典模板、Agent代办业务的边界设计以及实施过程里最容易踩的几个坑。适合正在做ERP智能化改造的技术负责人、实施顾问以及准备给业务管理层提方案的CIO们参考。1. 先想明白不换ERP到底是想解决什么问题很多企业陷入一个误区老板看到同行上了新系统第一反应是自己的ERP太老得换。但真去梳理需求会发现老板要的往往不是新ERP而是快速从数据里拿到答案。1.1 老板要的不是新系统是从数据到答案的效率以制造企业为例ERP里通常有销售订单、采购、生产工单、库存、财务等模块跑十几年下来历史数据积累了几百GB业务流程被审批流、权限矩阵、单据模板绑得死死的。换系统意味着重新规划物料编码和客户主数据、迁移历史数据、全员重新培训实施周期基本是按年算的。但老板的实际诉求往往是即时性的——这个月哪些产品毛利下降了某客户回款怎么一直拖着华东仓和华南仓哪个周转更慢。传统做法是打开ERP找到对应报表手动筛选导出Excel再自己算一轮快的半小时慢的半天。遇到跨模块的问题比如销售毛利要关联订单、成本、回款三块数据经常要拉好几个部门的Excel才能拼出来。AI能压缩的恰恰是从问题到答案这段路。它不需要替代ERP的流程引擎只需要读懂ERP里的数据并把它转化成业务人员能直接看懂的结论。这里有个关键认知要摆正ERP负责记录和流程AI负责理解和反馈两者是叠加关系不是替代关系。如果流程本身是乱的AI帮不上忙但如果流程是顺的、只是要数太难AI就有巨大发挥空间。1.2 AI与存量ERP的分工边界以及一个先决条件为了讲清楚这种叠加关系我一般用下面这张表跟企业方对齐预期环节谁来做为什么数据采集、单据流转、审批控制ERP稳定、可追溯、已固化多年自然语言理解、语义关联、问题拆解AI大模型能理解模糊的业务提问并组织答案指标计算、历史对比、异常发现AI视图层让AI按固定口径去计算而不是自由发挥最终决策、审批通过、业务调整人责任主体必须是人AI只提供参考权限控制、审计记录ERP中间层AI不能绕过系统安全边界这个边界想清楚之后落地方案才有骨架。还有一个先决条件必须提醒数据质量体检。如果客户主数据一塌糊涂、物料编码重复率超过10%、同一个字段被不同部门塞了不同含义AI再聪明也查不对——它只是把脏数据更快地翻出来而已。所以启动AI项目前至少要做一轮数据质量评估重点看重复、空值、口径漂移这三类问题。这个步骤省不得后面所有环节都建立在它之上。2. 让AI查数从只读账号到自然语言SQL的完整链路查询数据是整个项目里最容易快速见效、也最容易翻车的环节。翻车的原因通常不是AI不够聪明而是给了AI过大的数据库权限或者让它直接面对几百张结构复杂的业务表。2.1 优先建只读账号和视图层不要让AI直连生产核心表这条必须放在最前面。实践中有项目直接给大模型配了一个生产库的读写账号结果AI生成的SQL出现全表扫描甚至有误操作风险。正确做法是在数据库里单独创建一个只读账号只授予查询视图的权限不碰业务原始表和事务数据。CREATE USER ai_query IDENTIFIED BY safe_password; GRANT CONNECT, CREATE SESSION TO ai_query; GRANT SELECT ON reporting.v_sales_order TO ai_query; GRANT SELECT ON reporting.v_inventory_balance TO ai_query; GRANT SELECT ON reporting.v_ar_aging TO ai_query;为什么一定要通过视图而不是直接授权表三方面考虑。第一视图可以提前过滤敏感列比如成本明细、折扣底线、个人薪资这些不该让AI回答的内容直接在视图层拿掉。第二可以在视图里统一字段命名把ERP原本的拼音缩写或英文缩写转换成业务术语比如把AR_BAL字段命名为应收余额大幅降低AI理解门槛。第三视图能限制查询范围比如默认只允许查近三年的数据避免AI在几十亿条历史数据上跑出灾难性查询。2.2 自然语言转SQL的落地策略先把20个高频查询固化成视图Text2SQL听起来很美好但直接让AI对着几百张表生成SQL就是灾难表名缩写看不懂、同名字段一抓一把、连表关系复杂到连老实施顾问都要想半天。我的经验是不要追求让AI直接理解全集而是梳理出业务高频查询场景前20个左右每个场景对应一个视图或一个参数化查询让AI在受控范围内把问句翻译成对标准视图的查询。这个策略能把准确率从60%直接拉到90%以上。这里给一套我常用的Prompt模板供参考你是一个ERP数据查询助手。只能基于以下视图回答 - v_sales_order: 销售订单头与行含客户、产品、数量、金额、区域、订单日期、交付日期 - v_inventory_balance: 库存余额含物料编码、仓库、可用量、冻结量 - v_ar_aging: 应收账龄含客户、账期区间、余额 任务规则 1. 把用户问题翻译成SQL字段名只能使用视图中存在的命名 2. 问题如果涉及视图之外的字段必须回答暂无权限查询该数据 3. 查询结果为空时如实说明禁止编造数据。 用户问华东区上个月销售额是多少注意最后两条规则很重要。模型在自由对话中习惯了有问必答但在数据分析场景里查不到就说查不到比硬编答案安全得多。你要在Prompt里明确授权AI拒绝回答。2.3 Python连接Oracle的实操脚本从cx_Oracle到python-oracledb热词里有个python连接oracle查询数据实践中很多项目的查询中间层就是Python写的。早期大家习惯用cx_Oracle但Oracle官方已经停止cx_Oracle的新功能开发转向了python-oracledb。这个库有个很友好的特性支持thin模式不需要额外安装Oracle客户端一台装了Python的机器就能直连数据库部署成本低很多。下面是我在中间层里实际跑过的脚本骨架import oracledb conn oracledb.connect(userai_query, passwordsafe_password, dsn192.168.1.10:1521/ORCL) cur conn.cursor() sql SELECT region, SUM(order_amount) AS total_amount FROM reporting.v_sales_order WHERE order_date TO_DATE(:start_date, YYYY-MM-DD) GROUP BY region cur.execute(sql, start_date2025-01-01) for row in cur: print(row) cur.close() conn.close()这脚本看着简单但有个容易被忽略的点绑定变量。AI生成的SQL在执行前一定要做参数化改写不能直接把字符串拼进语句里。这样一方面降低SQL注入风险另一方面也方便做查询缓存——同样参数的查询可以直接命中缓存减少数据库压力。开发过程中我见过太多团队图省事把AI生成的SQL当纯字符串执行结果一个客户名里带单引号的问题就能让查询服务崩掉。2.4 查询性能与缓存别让AI把生产库压垮ERP白天业务高并发AI查询如果不加限制几个大查询就能把生产库拖慢。我见过一个案例AI生成的查询在几千万行的订单明细表上做全表扫描直接把数据库CPU打到90%前台开单都卡了。从那以后我定了一条铁律AI查询链路必须有三道闸。第一道闸是查询副本。优先连接只读备库或独立的数据仓库而不是生产主库。如果公司没有备库至少要把AI查询限定在视图层并设置数据库资源组限制CPU和IO。第二道闸是超时熔断。在查询中间层设置合理的超时时间我一般用10秒超过就自动取消SQL并提示用户查询太复杂请换个更具体的问法。第三道闸是行数限制。自动在SQL末尾追加FETCH FIRST 200 ROWS ONLY或Oracle的ROWNUM限制防止一次性返回几十万行打爆内存。缓存这层也值得做。同一类问题语义相近参数相同在5分钟内直接命中缓存重复查询不再打到数据库。用Python写一个带过期时间的字典或接入Redis都很简单但对ERP库的减压效果非常明显。3. 让AI懂经营指标口径和语义层建设才是不花冤枉钱的关键查询数据做到位AI已经能回答了。但回答得对和分析得准之间隔着一道企业特有的坎——指标口径。这一章也是热词里企业erp或crm产品的ontology指向的核心让机器理解业务流程里的词汇和关系。3.1 先别搭知识图谱先做一张指标字典本体论或ontology这个词听起来很玄很多团队一听就想着要建知识图谱、做实体关系标注结果投入巨大、产出寥寥。我在实践里的判断是对大多数企业来说真正见效的是用Excel或Wiki做一张指标字典它就是AI分析经营时的翻译词典。指标业务口径计算公式数据来源订单毛利不含税收入减不含税成本SUM(订单金额-订单成本)reporting.v_sales_order回款周期开票日到收款日的天数AVG(收款日期-发票日期)reporting.v_ar_aging订单交付及时率按期交付订单数占应交付订单数比例COUNT(按期交付订单)/COUNT(应交付订单)reporting.v_sales_order这张表的价值在于把业务语言和计算逻辑彻底显式化。比如毛利率这个指标销售理解的毛利可能只扣出厂成本财务理解的毛利要分摊制造费用和物流成本两者算出来能差好几个点。指标字典里明确写明用什么口径AI照着字典去算结果才经得起业务人员的质疑。3.2 指标口径的清洗与确认流程指标字典不是IT团队关起门来写的必须由业务部门确认。我的做法是召集财务、销售、生产、仓储各出一个人花半天时间开指标对齐会逐条过一遍高频指标。这个会虽然看起来不像技术活但几乎所有AI经营分析项目的成败都会卡在这里。开会时我习惯准备一张指标确认单列这几项指标名称业务叫法计算公式可执行的数学表达式数据来源表/视图适用范围哪些部门用、哪些业务线用默认口径AI回答时优先使用哪个口径变更时通知谁会议结束一定要发会议纪要标注财务负责人确认XX指标口径为……。这类确认记录后期既是AI的prompt素材也是团队之间免扯皮的凭证。没有这步AI上线后你就会被这个数不对淹没。3.3 经营分析提示词与分步确认机制让AI直接回答分析一下上个月的经营情况这种大问题等于逼它胡说。我踩过这个坑当时AI给了一堆看似合理的结论仔细一核对一半是编的。后来改成了分步确认机制把分析任务拆成带检查点的小步骤任务是分析上月经营情况按以下步骤执行 第一步列出该问题需要哪些指标并说明每个指标的口径 第二步用只读视图查询上月数据输出指标数值 第三步和上上月对比找出变化最大的三项给出变化幅度 第四步尝试归因比如从客户、产品、区域维度下钻 第五步如果某个归因没有数据支撑必须写明数据不足待确认。这个机制的好处是每一道都能检查。老板看到AI结论时可以顺着步骤反向核查而不是面对一个无法解释的最终答案。从工程角度看也容易定位问题出在哪一步——是SQL错了、指标算错了还是归因逻辑有问题。3.4 一个完整的经营分析案例拿一个真实场景串一下。某制造企业老板问华东区这个月订单交付及时率怎么下降了第一步AI从指标字典里找到定义订单交付及时率等于按期交付订单数除以应交付订单数。第二步从reporting.v_sales_order视图查询华东区本月和上月数据计算后得到本月80%、上月92%下降12个百分点。第三步下钻到产品线发现新款产品BOM准备时间过长导致该产线订单大面积延期。第四步AI给出结论华东区整体交付及时率下降主要由新款产品的物料齐套延迟造成建议调整排产优先级。整个过程从人工翻报表的两个小时压缩到两分钟。而且AI给的是数据线索最终调整排产的决策仍然由人拍板。这个分工模式在管理层那里很容易通过因为AI不再是做决定而是把依据摆到桌面。4. 让AI办事Agent代办业务的安全边界与落地姿势查询和分析都是只读操作到了办理业务这一步事情就变得敏感了因为涉及到数据写入和流程推进。热词里AI Agent被点得很频繁但企业场景里的Agent不能只会聊天它必须能调用系统接口、生成单据、发起流程同时不破坏现有治理结构。4.1 三种操作模式与风险分级我把AI代办分成三个级别级别典型操作风险等级控制措施L1查询数据、生成报表、口径解释极低只读账号、视图层控制L2代填申请单草稿、创建订单草稿、推荐审批人中用户二次确认、草稿可编辑L3自动提交审批流、跨系统触发动作高场景白名单、幂等键、审批人指定大部分企业不要一上来就做L3。我见过最稳妥的路径是先把L1跑稳让业务人员习惯用AI查数据接着挑一个高频低险的L2场景比如采购申请单草稿让AI能真正动手而不越权等信任建立了再谈自动化那时候自然会有业务部门主动提需求。4.2 Agent的落地架构工具调用与接口封装AI Agent要办理业务靠的不是直接改数据库而是调用ERP已有的业务接口。比如创建采购申请就应该走ERP的WebService或REST API填写销售订单就要调用对应的单据新增接口。Agent的工作流程是解析用户意图选择工具生成参数字段调用接口展示结果。{ name: create_purchase_request, description: 创建采购申请草稿不提交审批, parameters: { type: object, properties: { material_code: { type: string, description: 物料编码 }, quantity: { type: number, description: 申请数量 }, request_reason: { type: string, description: 申请原因 } }, required: [material_code, quantity] } }这个JSON Schema就是Function Calling里的工具说明书。模型看到用户说帮我申请一下缺料的钢材时会解析出material_codeGC-001、quantity5000、request_reason库存低于安全阈值然后填充到工具调用参数里。这个模式的关键点是草稿两个字AI生成的申请单默认不提交给用户留一个确认和修改的余地。这套草稿代理模式在企业的接受度非常高因为它把AI放在了助手的位置而不是决策者。4.3 用工作流引擎兜底AI出意图系统走流程实际执行层面不要把AI和审批引擎耦合得太深。推荐架构是AI负责生成建议动作填写申请单、推荐审批人、计算采购数量真正的单据流转、审批规则、会签逻辑仍然由现有工作流引擎控制。AI的产出物写在业务表的一个AI建议备注字段里而不是直接进入正式单据。拿采购申请举例。采购员对AI说帮我申请一下缺料的原材料AI解析后生成一张采购申请草稿备注栏自动带出由AI根据库存阈值建议数量仅供参考。采购员确认后点提交单据转入原有审批流后续照旧。这样即使AI建议错了也会被人工拦截在草稿阶段。这套设计的核心是把AI当副驾而不是司机方向盘始终在业务人员手里。4.4 权限、审计与并发控制办理业务环节最容易被忽视的是权限体系。这里有一个必须记住的原则AI的操作权限不能超过使用者的权限。也就是说AI调用接口时必须带当前登录用户的身份ERP侧按照该用户的角色控制数据可见性和操作权限。绝不能给AI一个系统管理员身份去操作所有单据那种做法等于给每个员工配了一把万能钥匙。审计日志要记录完整链路谁在什么时间通过AI执行了什么动作、AI生成的关键参数是什么、用户有没有修改、最终有没有提交。我把这种日志称为AI指纹出问题的时候可以精确追溯到AI参数、用户行为和系统结果三层。并发方面AI批量提交时要特别注意锁冲突和重复提交。通常做法是接口加幂等键唯一请求号防止AI重试导致重复单据——这个错误我见过不止一次AI网络超时后自动重试结果一张采购单在系统里被创建了三遍。5. 落地前绕不开的四个大坑数据地图、模型幻觉、口径扯皮、评估节奏这一章是给准备动手的团队看的。前面讲了不少方法和技能但真正决定项目成败的往往是实施过程中暴露的非技术问题。5.1 第一个坑连数据在哪都不知道很多企业启动AI项目后的第一周全都在考古——查这个字段是什么意思、那个表和哪个表怎么关联。我曾经遇到一个客户财务说要查应收余额结果数据散在三套表里命名分别是AR_BAL、YSZK_YE、receivable_bal三个不同部门维护数据还不一致。这种情况不能怪AI它确实不知道该信谁。建议在项目启动前花一到两周做一张数据地图用Excel就行。列出每个核心字段的业务含义、所属模块、负责人、质量状态。这张图后续既是AI做字段理解的素材也是指标字典的基础更是中间层SQL改写规则的来源。没有这张图后面的工作都像在打盲牌今天问一个人搞清一个字段明天再问另一个人效率极低。5.2 第二个坑AI一本正经地胡说八道大模型的幻觉在经营分析场景同样会出现它可能编一个不存在的客户名算一个根本没有的增长率甚至把两个不相关的表拼在一起推导出结论。解决思路有三层让AI只能查询白名单视图查不到就明确说查不到并且把这条规则写进Prompt。在中间层对SQL结果做自动校验比如空值检查、波动检查。如果某个指标环比波动超过100%系统自动标红提醒不允许AI直接输出。要求AI在给出结论时附上取数范围和计算口径比如本数据来自v_sales_order区间为2025年3月1日至3月31日便于人工复核。根据我的经验允许AI说查不到这条最简单也最有效。它直接切断了AI编造数据的动力。5.3 第三个坑同一个指标三个部门三个口径再强调一遍回款这个词销售认为是客户实际付款财务认为是应收账款核销老板觉得是现金流到账。如果AI用销售口径查出来给老板看老板一定骂数据不对。这不是AI的问题是企业内部一直存在的口径之争被AI放大了。破解方法就是前面说的指标对齐会。把口径冲突的指标列成一张争议清单会上逐个裁定会后归档作为指标字典的正式内容。这里有个实践技巧会议纪要一定要发给财务负责人做书面确认否则到了下次复盘又会有人翻案。5.4 第四个坑想一步到位结果连第一个Demo都跑不出来我见过不少项目死在贪多上。一上来就规划采购、销售、库存、财务四大模块全覆盖光指标对齐全就用了三个月Demo连影子都没有。建议的做法是选一个三好模块启动商业价值最高、数据质量最好、流程最标准化。销售订单查询与毛利分析通常是最理想的第一站因为销售数据相对干净毛利又是老板最关心的指标。评估维度建议用四块查询准确率、业务办理成功率、用户采纳率、平均响应时间。先定一个能接受的下限比如准确率80%以上、用户每周至少用三次跑两个月再复盘。从我的经验看从单模块跑通、建立完整链路视图到指标到Prompt到Agent到审计再复制到其他模块是阻力最小的路径。把这个顺序反过来项目大概率会死在演示阶段。最后聊一点个人体会。AI项目上线只是开始真正的难点在持续维护。我每次做这类项目都会给客户留下一套黄金测试集把业务里最重要的五十到一百个场景写成问答对每个版本改动之后跑一遍回归测试。这套测试集加上前面说的指标字典是AI在ERP里保持稳定输出的两个支点。守住这两条底线AI就会从新鲜玩具慢慢变成业务离不开的基础设施。