过去二十年，ERP实施商最熟悉的一句话是：

项目什么时候上线？

客户问这句话，供应商也问这句话。

立项、调研、蓝图、配置、开发、测试、培训、上线、验收，所有动作都围绕一个终点展开：系统能不能按时上线。

在传统ERP 时代，这套逻辑是成立的。因为ERP 的核心对象是功能和流程。只要流程跑通、权限设好、数据导入完成，系统基本就能稳定运行。项目上线以后，实施商逐渐撤场，客户进入日常使用和运维阶段。

但AI ERP 出现以后，这套逻辑开始松动。

因为企业买AI ERP，不只是买一个系统，也不是买一组功能，而是在引入一批会查询、会生成、会建议，甚至具备执行能力的“数字员工”。

数字员工和传统系统最大的不同是：它不是上线那一刻就完成了，而是在使用过程中不断暴露问题、积累经验、调整边界、修正规则、迭代能力。

所以，ERP实施商的下一场转型，不是从一个系统换到另一个系统，也不是从传统ERP 实施转向AI ERP 实施，而是从“上线项目”转向“能力运营”。

上线是项目思维，运营是产品思维。

实施商要做的，不只是帮企业做完一个项目，而是帮企业养好一批数字员工。

过去，实施商交付的是系统能不能用；未来，实施商要持续回答的是：AI能力用得怎么样，哪些场景真的进了业务，哪些Skill 经常出错，哪些规则需要调整，哪些权限需要收紧，哪些能力可以进一步放权。

这是一个新的战场。

它看起来离实施很近，但本质上已经不是传统实施。

01 AI ERP项目最容易出现：上线很热闹，使用很冷清

我见过一个很典型的场景。

一家企业上AI ERP，实施商按照传统项目方法推进：调研、设计、配置、开发、测试、培训、上线，一切都很完整。

项目验收时，效果看起来不错。供应商交付了15 个AI Skill，包括采购申请生成、库存预警、费用分析、合同风险摘要、经营分析报告、供应商评估等多个场景。

验收会上，大家演示得很顺。客户领导觉得项目很先进，实施团队也觉得交付很成功。

但三个月后再看后台数据，情况完全不一样。

15个Skill 里，真正被频繁调用的只有3 个。有5 个Skill 基本没人用，因为业务人员觉得“不如自己查得快”。有4 个Skill 经常被用户修改，修改率超过60%，但这些修改没有回流到规则优化里。还有3 个Skill 因为早期出过几次错，被业务人员绕开了。

最麻烦的是，没有人真正负责这件事。

业务部门说这是系统功能，找IT。IT 说这是业务规则，找业务。实施商说项目已经验收，后续属于运维范围。

于是这些AI Skill 就停在系统里。

能打开，能演示，但没有真正进入业务。

这就是AI ERP 项目最容易出现的问题：

上线很热闹，使用很冷清。

传统ERP 项目里，系统上线后，即使用户不喜欢，也往往必须使用。因为流程在系统里，单据在系统里，审批在系统里。

但AI Skill 不一样。

很多AI 能力不是强制流程，而是“可选能力”。用户不信它，就不会用；用户觉得麻烦，就会绕开；用户连续几次发现它不准，就会把它踢出自己的工作习惯。

比如有一家企业上线了AI 采购助手，刚开始大家都觉得新鲜。它可以自动推荐供应商，还能给出价格建议。三个月后，采购员几乎不用了。原因很简单：AI 推荐的供应商价格总是偏高。

后来复盘发现，AI使用的是标准价口径，没有考虑历史折扣、账期条件和临时返利。站在系统口径看，它没有算错；站在采购业务看，它给出的建议很蠢。

这类问题不是靠再培训用户能解决的，而是要重新调整规则、补充数据口径、修正Skill 判断逻辑。

所以，AI ERP不能只按上线项目做。

因为AI 能力真正的生命，不在验收会上，而在上线后的持续使用里。

02 AI ERP的交付物，不再只是文档和配置

传统ERP 项目的交付物，通常是业务蓝图、流程方案、权限矩阵、系统配置清单、开发清单、测试报告、培训材料、上线方案和验收报告。

这些交付物的核心，是证明系统已经按约定配置完成，可以上线运行。

但AI ERP 项目必须多出一层交付物：

能力资产。

比如业务Skill 清单、Agent 场景清单、查询生成执行三层风险分级、AI 权限矩阵、Skill 调用规则、异常中断条件、审计留痕方案、AI 输出人工确认机制、用户反馈闭环、Skill 运营看板、能力迭代路线图。

这些东西听起来像文档，但本质上不是文档，而是AI ERP 能不能长期运行的“能力操作系统”。

这其实就是前面文章里讲过的“Skill契约”在实施环节的落地。所谓契约，不只是写清楚这个Skill 能做什么，还要写清楚它从哪里取数、输出什么结果、在什么权限下运行、遇到什么异常必须中断、每一次判断能不能被审计追溯。

举个例子。

传统ERP 里，你配置一个采购订单流程。采购员填单，部门经理审批，采购负责人审核，财务校验预算，最后生成订单。这个流程上线了，只要权限和流程没变，它就可以一直跑。

但在AI ERP 里，如果有一个采购申请生成Skill，问题就复杂得多。

它从哪里取数据？用哪个价格口径？能不能自动推荐供应商？供应商评分低于多少必须中断？金额超过多少必须人工确认？它生成的采购建议，人修改后是否回流？用户连续三次否定AI 建议，系统是否要提醒运营人员优化规则？

这已经不是简单的流程配置。

这是能力治理。

传统实施商擅长把“业务流程”搬进系统。AI ERP时代，实施商要学会把“业务判断”拆成可调用、可解释、可追溯、可迭代的能力。

过去的交付物证明系统能跑。

未来的交付物要证明能力能运营。

但问题也在这里：如果实施商看不清哪些工作正在被AI 压缩、哪些能力正在变得更值钱，即使交付了这些新文档，也守不住自己的价值位置。

03低价值实施工作会被压缩，高价值实施工作会被放大

AI ERP对实施商不是单纯利好。

它首先会压缩一部分传统实施工作。

基础配置会被压缩。组织、岗位、权限、科目、物料、客户、供应商、流程模板，这些配置过去大量依赖实施顾问手工完成。未来，AI可以根据客户资料、历史模板和行业标准自动生成初始配置建议。实施顾问不一定消失，但“搬配置”的人天会减少。

重复培训会被压缩。过去培训用户，要一遍遍讲菜单在哪里、按钮怎么点、报表怎么查、流程怎么提交。AI入口出现以后，很多操作不再需要用户记住路径。用户可以直接问：“帮我查这个订单到哪了”“这个供应商过去一年表现怎么样”“帮我生成一份费用超预算说明”。当自然语言入口替代菜单路径，传统“教用户点系统”的培训价值会下降。

标准报表和普通运维答疑也会被压缩。AI具备查询和生成能力后，很多固定报表会被动态问答和自动分析替代；用户忘了路径、不会查数据、看不懂提示这类一线问题，也会越来越多地被系统自己消化。

这些变化，对传统实施商是压力。

因为过去很多收入，来自客户不会用、系统不好配、报表不好取、流程不好调。

但这不意味着实施商没有价值。

真正高价值的实施工作会被放大。

只是价值位置变了。

AI ERP时代，实施商最核心的价值，不再是“帮客户把系统配出来”，而是“帮客户判断哪些能力值得做，怎么做，做到什么边界”。

比如，客户说：

我想让AI 自动审核采购申请。

传统实施商会问采购审批流程、审批节点、金额权限和系统配置。

这些问题当然还要问。

但AI ERP 实施商还要继续问：这个场景适合查询型、生成型，还是执行型？AI 可以判断到哪一步？哪些条件下必须交给人？它调用哪些数据才算依据完整？出错以后能不能追溯到规则、数据和确认人？用户否定AI 建议以后，是否进入反馈闭环？

这才是AI ERP 实施商的新价值。

再比如，客户说：

我想让AI 生成经营分析报告。

传统做法是做一套经营报表。但AI ERP 实施商不能只做报表，而要判断：这份报告给谁看，老板关注利润、现金流还是增长，财务关注预算偏差还是费用结构，业务负责人关注客户、订单还是库存；AI 生成的是事实摘要，还是经营判断；哪些结论必须引用数据依据，哪些口径必须和财务报表一致，哪些异常波动需要追问原因。

这里真正难的，不是让AI 写一段文字。

真正难的是把企业的经营判断逻辑拆出来。

这也呼应了前面讲过的“不要一上来就自动执行”。实施商要帮助企业判断一个场景到底处在查询、生成还是执行层，而不是把所有需求都包装成自动化。

所以，实施商未来的竞争力，会从“系统熟练度”迁移到“场景判断力”。

谁更懂业务场景，谁更能判断AI 适合做到哪一步，谁更能设计能力边界，谁就更有价值。

04能力运营，至少要交付三张表

如果把“能力运营”落到具体工作上，我认为实施商未来至少要交付三张表。

第一张表，叫AI 场景分级表。

所有AI 场景，不能一股脑上线。要先分清楚哪些是查询型，哪些是生成型，哪些是执行型，哪些可以低风险试点，哪些需要强审计，哪些暂时不能做。

比如，查订单状态、查库存水位、查供应商准时率，可以先做查询型；生成月度费用分析、合同风险摘要、采购建议，可以做生成型；自动下单、自动付款、自动调整价格，就必须进入执行型管控。

这张表解决的是：

什么值得做，先做到哪一步。

说白了，它是在回答：

这个AI 场景，应该先走路，还是已经可以跑？

第二张表，叫AI 权限边界表。

每一个AI Skill 或Agent，都必须回答：谁能调用，能看哪些数据，能生成什么结果，能不能提交，能不能修改，能不能触发流程，什么条件下必须中断，谁来确认，谁承担责任。

这张表解决的是：

AI可以做到哪里，哪里必须停下来。

说白了，它是在回答：

这个数字员工的岗位职责和授权边界是什么？

第三张表，叫AI 能力运营表。

上线以后，每个Skill 都要被持续观察：调用次数、成功率、用户采纳率、人工修改率、异常触发次数、错误归因、规则调整记录、权限调整记录、下次迭代建议。

这张表解决的是：

AI能力有没有持续变好。

说白了，它是在回答：

这个能力上线以后，是越来越好用，还是越来越没人用？

传统实施商交付的是蓝图、配置和验收报告。

未来实施商要交付的是场景分级、边界治理和能力运营。

这三张表，决定了实施商能不能从项目交付者，转向能力运营者。

05实施商可以先从2—3个Skill开始试点

这种转型不是一天完成的。

实施商不需要一上来就重构全部服务体系，也不需要一开始就把自己包装成AI 能力运营公司。

更现实的做法，是先从一个客户、两三个高频Skill 开始跑通。

比如，一个客户刚上线了AI ERP，可以先选三个场景：

一个查询型Skill：订单状态查询。

一个生成型Skill：费用分析报告。

一个轻量执行型Skill：低风险补货建议。

这三个场景足够小，但足够真实。

实施商可以和客户约定一个8—12 周的能力运营周期：每周看调用次数、用户反馈、人工修改率、异常触发情况；每两周调整一次规则和提示；每月输出一份能力运营报告。

这个试点不一定一开始就很赚钱，但它会帮助实施商建立一种新的能力。

过去，实施商熟悉的是项目计划表。

未来，实施商要熟悉能力运营表。

过去，实施商习惯看“需求闭环率”。

未来，实施商要学会看“AI采纳率”“异常中断率”“人工修改率”“规则迭代次数”。

转型不是喊出来的。

是从第一个被持续运营的Skill 开始的。

06 AI ERP会让实施商更像“企业能力教练”

未来的ERP 实施商，可能不再只是客户和软件厂商之间的交付团队。

它会更像企业的能力教练。

教练不替运动员上场，但教练要判断这个人适合打什么位置、应该练什么动作、什么习惯必须纠正、什么能力可以加强、什么时候该上场、什么时候应该暂停。

AI ERP实施商也是一样。

它不是替企业把所有AI 能力都做完，而是帮助企业建立一套可以持续进化的能力系统。

比如，一个企业想让AI 参与采购管理。能力教练式的实施商，不会一上来就说“我们给你做自动下单”。

它会先判断：采购场景里哪些只是查询，哪些可以生成建议，哪些绝不能自动执行；然后设计第一批低风险Skill，让业务人员先建立信任；再通过运营数据观察哪些建议被采纳，哪些经常被修改，哪些场景总是触发异常；最后才判断哪些标准场景可以进一步放权。

这和传统顾问、传统实施商都不同。

传统顾问更像是给方案：告诉你应该怎么做。

传统实施商更像是做落地：把方案配置进系统。

能力教练则要持续陪企业练习：看使用数据，调规则，改边界，复盘错误，逐步提高AI 能力在组织里的可信度。

过去，客户不会用系统，实施商教他怎么点。未来，客户不会运营AI 能力，实施商要教他怎么判断、怎么反馈、怎么调整边界、怎么迭代Skill。

这会带来服务模式的变化。

传统模式是项目收费：按模块、按人天、按二开、按实施周期。

未来可能会出现能力运营服务：按月度顾问、按场景包、按Skill 运营、按Agent 治理、按能力提升效果收费。

比如AI 场景诊断服务、AI Skill 设计服务、AI 权限边界设计服务、AI 能力运营月报、AI Agent 健康检查、AI 业务规则迭代服务、AI 使用数据分析和优化建议。

这些服务听起来不再像传统实施。

它更像咨询、产品运营和组织治理的结合体。

在前面讲AI 入口之争时，我说过，谁掌握入口，谁就更接近企业操作系统。软件厂商会争通用入口，企业会争自己的数据入口，而实施商最应该争的是业务入口——把AI 能力真正装进企业业务流程里的那个入口。

软件厂商可以提供产品底座，但未必能深入每一家企业的真实业务现场。企业自己有业务经验，但未必能把经验拆成可调用、可追溯、可运营的AI 能力。

实施商如果站在中间，就有机会成为那座桥。

07从做项目的人，到运营能力的人

很多实施商会担心：

AI会不会替代我们？

这个问题问反了。

AI会替代一部分低价值实施动作，但不会自动替代高价值的业务判断、场景设计、边界治理和能力运营。

真正危险的，不是AI 抢走实施商，而是实施商自己还停在上线逻辑里。

如果实施商还把自己定义为“配置系统的人”，那AI ERP 一定会压缩它的价值。因为配置会越来越自动化，培训会越来越智能化，报表会越来越动态化，普通答疑会越来越自助化。

但如果实施商把自己定义为“帮助企业运营AI 能力的人”，价值空间反而会变大。

因为AI 进入企业以后，问题会更多，而不是更少。

哪些场景适合AI？哪些场景不能让AI 做？哪些能力没人用？哪些能力用户不信？哪些建议经常被修改？哪些执行动作风险太高？哪些规则要更新？哪些日志说明不了问题？

这些问题，都需要懂业务、懂系统、懂组织、懂AI 边界的人来处理。

实施商可以先问自己四个问题：

第一，我们现在交付的是系统上线，还是能力持续可用？

第二，我们有没有帮客户做AI 场景分级、权限边界和能力运营？

第三，我们有没有在项目结束后持续看Skill 的调用、采纳、异常和迭代？

第四，我们有没有把AI 能力运营包装成一种可销售、可交付、可复购的服务？

如果这四个问题都答不上来，说明转型缺口已经出现了。

过去，ERP实施商最重要的能力，是把项目做完。

未来，AI ERP实施商最重要的能力，是让能力持续有效。

这是两种完全不同的工作逻辑。

项目做完，意味着交付结束。

能力有效，意味着运营开始。

项目做完，看的是范围、周期、成本、验收。

能力有效，看的是调用、采纳、异常、反馈、迭代。

项目做完，实施商可以撤场。

能力有效，实施商必须持续在场。

这就是ERP 实施商下一场转型的本质：

从上线项目，到能力运营。

从系统交付，到场景经营。

从配置功能，到设计边界。

从培训用户，到训练组织。

从写验收报告，到写能力运营报告。

这不是换一个说法，而是商业模式、服务能力和顾问角色的重新定义。

回头看这一整个系列，线索其实很清楚。

我们讲了入口从菜单到对话，讲了能力从功能到Skill，讲了边界从开放到治理，讲了节奏从一步到位到循序渐进，也讲了选型不能只看Demo。

这些问题最后都会落到一个现实问题上：

谁来把这些AI 能力放进企业真实业务里，并让它们持续跑起来？

这就是实施商转型的意义。

AI ERP不是一次上线，而是一套能力体系的持续建设。

如果说传统ERP 实施的关键词是“上线”，那么AI ERP 实施的关键词就是“运营”。

谁能帮助企业把AI 能力持续用起来、管起来、改起来，谁才会在下一轮企业软件重构中留下来。

AI ERP的价值，不在上线那天，而在运营每一天。

如果实施商还只盯着上线，它交付的是昨天的ERP。

如果实施商开始运营能力，它交付的才是明天的组织。