1. 为什么跨岗位协同成了供应链AI落地的头号难题先讲个我亲历的场景。某制造企业上了WMS、TMS、ERP、SRM每个系统都是行业里说得上名号的单独看都挺能打。可真到业务跑起来计划员在ERP里看到安全库存告警采购员在SRM里对着一张三天前生成的采购单发呆仓储那边因为提前到货的原料爆仓物流承运商的车辆在厂区门口排队等着卸货。每个岗位都在自己的系统里勤勤恳恳但整体效率就是上不去。问题出在哪不是系统不够多恰恰是系统太多、岗位太碎而连接这些系统和岗位的“协同层”几乎等于没有。传统的协同靠什么靠微信群、靠邮件、靠每天早上的站立会。计划员发现自己预测失误要手动采购采购再打电话问供应商能不能加急供应商回复之后采购再把结果同步给仓储。任何一个环节延迟整个链条就跟着停摆。这几年AI大模型火起来之后很多企业管理者有一个错觉上了AI就能把这些问题都解决。但你要是真去问那些已经做过AI试点项目的CIO他们多半会告诉你单点AI应用好做比如用大模型做需求预测、用OCR做单据识别真正难的是让AI跨岗位跑起来把不同角色、不同系统、不同流程串成一个闭环。这也是我们把白皮书系列第三篇定位在“跨岗位协同与系统渐进改造”的原因——前两篇已经把单点模型怎么选、数据底座怎么搭讲清楚了这篇重点聊协同层的设计和系统改造的节奏。这篇内容适合谁如果你是企业数字化负责人、供应链运营的管理者或者正在做AI应用落地的产品经理和架构师应该能从中找到一些可以直接拿去用的思路。我不会讲太多天花乱坠的概念重点放在三件事跨岗位协同的痛点到底长什么样、AI Agent智能体在协同中应该扮演什么角色、以及怎么用渐进式改造的方式让老系统平稳地长出“AI能力”。2. 我们先拆解一下跨岗位协同的痛点到底卡在哪里2.1 信息断层每个岗位都只看得到自己那一截供应链是一条很长的链。从一个需求预测开始到产能规划、采购计划、入库验收、生产领料、成品发运最后到客户签收中间要经过至少五六个岗位。传统信息化建设的一个重要成果是把每个岗位的作业线上化了但线上的结果往往散落在不同系统里。计划员用的预测模型输出的是一张Excel表采购员下单在SRM里供应商确认在邮件里仓储系统的入库单和采购订单之间没有自动关联需要人工核对。当信息以这种碎片化的方式存在时岗位之间的矛盾就会被放大仓储怪采购下单不准时采购怪计划预测太飘计划怪销售给的需求数据是拍脑袋想的。其实每个人都在自己的工位上做了正确的事但合在一起就是一个无序的流程。AI在这里面的第一个价值不是替代某个岗位而是把散落在各处的数据捞起来拼成一个可以让所有岗位看到同一版本的“事实”。这听上去简单实际做起来非常难因为不同系统的数据格式、编码规则、更新时间都不一样。但我们后面积累的经验是这一步不能省也不一定要一步到位先把最关键的一两条业务链的数据拉通就能看到明显的效果。2.2 目标冲突KPI不一致导致AI建议“没人听”这也是我们在实施过程中反复踩到的坑。跨岗位协同难不只是技术问题更是组织问题。采购的KPI是降本所以他倾向于大批量采购压低单价计划的KPI是交付准时率所以他想让采购备足安全库存仓储的KPI是周转率所以他不希望库里压太多货。三个岗位的目标天然就是拧着的。这时候你要是简单上一个AI系统告诉采购“为了降低库存建议你减少采购批量”采购一定会抵触因为这会直接影响他的绩效。所以我们在设计AI协同方案时有一个原则AI给出的建议不能只考虑全局最优还得考虑各岗位的局部约束并且要让每个岗位看到“这个建议对我在意的那几个指标意味着什么”。一个好用的做法是AI在推送建议时同时展示一个多维度的影响预估。话术可以是这样的“建议将本次采购量从500件调减至420件。预计库存周转天数下降3天但缺货风险上升1.2%建议同步启用替代供应商备选方案。”这样一来计划员看到的是风险可控采购员看到的是成本下降仓储看到的是周转改善各方都有台阶下AI建议被采纳的概率就高很多。2.3 流程刚性传统工作流引擎改不动再讲一个技术层面的痛点。不少企业的核心业务还是跑在传统的BPM业务流程管理引擎上流程节点是预先画死的先由计划员提交申请再到部门主管审批然后流转到采购执行每一步都有严格的顺序和角色限制。这种设计在业务稳定的时候没问题但现在的供应链环境变化太快一个临时的插单、一次意外的供应商断供都需要流程能动态调整。传统BPM的问题是改流程要提需求、排期、开发、测试一个版本迭代按周甚至按月算。等流程改好了业务可能已经换了一个场景。AI应用在这块能发挥的作用不是取代BPM而是在BPM之外加一个“灵活动作层”。也就是说标准的流程继续在BPM里跑而AI识别到异常时可以动态地给相关岗位生成一个临时任务指定新的处理路径和时限。这个临时任务不进BPM但在系统里全程留痕。3. AI Agent在跨岗位协同里到底怎么分工3.1 别把AI当成万能接线员它更适合做“协同编排器”现在市面上聊AI Agent聊得很凶很多人一上来就想搞一个“超级智能体”把供应链上所有事情都交给它。我的观点比较保守在跨岗位协同这种场景里AI Agent目前最合适的角色不是“全权代理”而是“协同编排器”。什么叫协同编排器就是AI不替任何岗位做最终决策但它负责把需要决策的事、需要决策的人、需要决策的时限都组织好。比如需求预测模型识别到未来两周某个SKU的需求量会大幅上升AI Agent会自动做这样几件事通知计划员某SKU预测需求上升建议复核安全库存策略通知采购员如果库存不足建议提前锁定某供应商的产能通知仓储如果采购确认加量需要预留库容并安排加班收货通知财务这次紧急采购可能带来额外的物流成本和资金占用需要提前准备付款计划。你看AI做的是信息路由和任务编排而不是直接告诉采购员“你下个单”。这种设计有几个好处一是每个岗位仍然保留专业判断权和决策权不会觉得被AI“架空”二是出问题的时候责任边界清晰三是AI建议被驳回时AI可以学习调整而不是强行推进。3.2 多Agent协作模式按角色划分还是按问题划分再往深一层说Agent怎么划分边界也是一个值得讨论的问题。我们做过两种尝试各有适用场景。第一种是按角色划分。给计划、采购、仓储、物流各配一个Agent每个Agent学习对应岗位的业务规则和历史偏好。比如采购Agent了解公司的供应商分级逻辑仓储Agent知道每天的收货波次安排。这种模式的好处是更贴近现有组织架构业务人员比较容易理解和接受坏处是Agent之间也需要协同如果协调机制没做好就会出现“两个Agent给同一个问题给了互相矛盾的建议”这种尴尬情况。第二种是按问题划分。不管岗位边界针对特定业务场景组建临时的Agent小组。比如“订单交付延迟处理”场景由一个主导Agent拉上需求分析、库存查询、物流在途追踪这几个子Agent共同解决一个问题。这种模式处理复杂问题时效率更高但对于Agent底座的技能编排能力要求也更高。我们目前的建议是初期从角色划分切入更容易上线也更容易让业务方建立信任等数据沉淀够了、Agent之间的交互协议成熟了再逐步转向按问题划分的混合模式。步子迈得太大容易扯着。3.3 AI Agent的记忆系统跨岗位协同的“共同大脑”跨岗位协同还有一个经常被忽视的问题——上下文断裂。你去问计划员为什么上周同意把某个订单交期往后调三天他可能翻半天聊天记录才想起来是采购反馈某个原材料要延迟到货。这种隐性的业务上下文散落在邮件、IM、甚至人的脑子里一旦人员流动就彻底丢了。我们在AI Agent设计里专门做了一个“协同记忆”模块。简单说就是AI会把每一次跨岗位协同的起因、过程、结论、涉及的附件和消息摘要沉淀下来形成一条结构化的协同记录。下次再遇到类似问题AI可以直接调取历史记录告诉相关岗位“上次遇到这种情况你们是这样处理的结果是这样的”。这个模块一开始做的时候业务方觉得无所谓但用了一段时间之后反馈最好。尤其是在处理供应商交期波动、紧急插单这类重复性比较强的异常场景时协同记忆能帮新入职的同事快速进入角色也让AI建议更有说服力。后面公司在做多Agent协作的时候这个协同记忆库也成了各个Agent共享的“共同大脑”。4. 系统渐进改造先让老系统长出AI能力而不是推倒重来4.1 为什么我不建议“重构一个AI原生系统”有朋友跟我聊过要不要干脆基于AI大模型重新开发一套供应链管理软件把老系统全换掉。我的回答通常是用一个问题反问回去你愿意把还在正常运转的心脏直接换掉还是先加一个起搏器试试老系统虽然笨重但它承载的是企业几十年的业务逻辑和流程沉淀里面每一张表、每一个状态字段背后都是一个个调优过的业务规则。把这些全部推倒重来技术上不是不行而是时间、成本、风险都不可控。更实际的做法是让老系统作为稳定的数据底座和业务执行底座保留下来在它上面加一层AI能力层。这层AI能力层做的事情很纯粹读老系统的数据理解老系统的流程然后用大模型的语义能力去弥补老系统在沟通、分析和动态编排上的短板。老系统不用知道AI怎么工作AI也不用修改老系统的核心逻辑两边保持松耦合。这样改造的好处是任何一个环节出了问题可以快速把流量切回原来的人工处理模式。4.2 四个演进阶段读数据、给建议、半自动、全自动我把渐进改造的路径拆成四个阶段每个阶段都有明确的进入条件和退出机制。这套框架在我们多个项目里反复验证过你可以根据自己的企业情况裁剪使用。第一阶段叫“读系统”也叫只读接入。AI只读数据不做任何输出。这时候AI做的事情是实时分析业务数据输出洞察报告。比如每天早晨自动生成一份供应链健康度报告告诉各岗位昨天有哪些指标异常、哪些SKU的库存处于风险区间。这些报告即使没人看也不会干扰业务属于最低风险的改造方式。第二阶段叫“给建议”。在只读接入的基础上AI开始把洞察推送给具体岗位并给出建议动作。这一步开始真正触达用户的日常工作流了所以要特别注意消息的精准度和频率控制。我们的经验是宁缺毋滥一条高质量建议的信任度抵得上一百条噪音。第三阶段叫“半自动执行”。对于低风险、高频次、规则清晰的操作AI可以代替人工直接执行但每一步执行都要留痕并且要配置“一键撤销”。典型的例子是根据库存变化自动调整采购订单的到货预约时间或者自动更新运输计划的优先级这些操作改动的都是系统里非核心主数据字段风险可控。第四阶段叫“全自动闭环”。这对应的是异常情况下AI可以跨系统自动完成一整套操作不用人工确认。老实说能走到这一阶段的企业不多因为涉及到权责边界、审计合规、系统间强依赖等复杂问题。我不建议一开始就冲这个阶段但可以设定为一个远期目标在特定场景里逐步放开。4.3 选好第一个切入场景比什么都重要渐进改造最怕的就是同时铺开太多场景。供应链环节多、岗位杂每个场景都有自己特殊的问题想用一套AI能力通吃几乎不可能。我的建议是选一个“痛点足够痛、价值足够清晰、失败影响可控”的场景作为第一刀。我们自己做过的项目里“订单交付延迟预警与协同”是性价比特别高的第一个场景。为什么因为订单交付直接对客户产生影响业务方对改善这个指标的意愿最强同时它跨了计划、销售、仓储、物流至少四个岗位非常适合验证跨岗位协同机制而且就算AI预警错了也只是多一条消息不会造成实质性的业务损失。第一刀切下去之后不管成不成功你都会得到一批非常宝贵的数据——哪些岗位愿意用AI、哪些岗位会抵触、哪类消息会被忽略、哪类建议会被采纳。这些数据比任何技术方案都重要它们决定了下一刀往哪里切。5. 实操实录一个订单延迟协同场景的完整落地过程5.1 场景目标与改造范围界定我拿一个实际的案例来讲。华东一家做消费电子组装的制造企业年产值十几亿订单模式是多品种、小批量原料供应中有不少进口件采购周期长。他们的痛点很典型成品订单交期经常延迟每次延迟都要靠各部门打电话才排查出原因平均排查时间接近4个小时客户投诉很多。这个项目我们界定的场景范围是这样的只处理“已经确定会延迟或存在高度延迟风险”的客户订单目标是让协同响应时间从4小时缩短到30分钟以内。注意我们刻意没有把需求预测、智能补货这些大而全的功能塞进来就是希望先把这条协同链跑通。5.2 系统接入先把“数据神经”搭好技术落地的第一步是数据接入。这个项目涉及三套核心系统ERP管的是订单和库存WMS管的是仓储作业TMS管的是物流运输。我们要让AI Agent能同时感知到这三个系统的状态。具体接入方式上用的是一个轻量级的数据管道通过各系统提供的API接口定期抽取增量数据统一清洗后写入一个分析数据库。清洗的重点有几个一是把不同系统对同一个物料的编码统一映射到主数据二是统一时间的表达方式比如ERP里的“计划到货时间”和TMS里的“预计到达时间”要换算到同一个时区三是对一些明显异常的脏数据做过滤比如未完成的测试单据、重复推送的变更记录。这块工作看起来不酷但恰恰是整个项目里工作量最大的部分。经验是不要试图把系统的所有数据都接过来先接跟场景相关的那几张表就够了。比如这个场景里我们只接了订单表、订单行项目表、库存快照表、收货预约表、在途运输表加起来不到二十张表数据链路清爽很多排查问题也快。5.3 规则模型与AI模型的组合不是所有预警都要靠大模型很多人会把“AI预警”想象成全部由大模型来干其实从工程效率上看完全没必要。我们在这个项目里采用的是“规则引擎 机器学习模型 大模型”三层组合。规则引擎负责处理那些逻辑完全明确的场景。比如“订单计划的完工日期已过但系统里还没有完工入库记录”这就是一个确定性的异常直接触发预警不需要任何AI计算。这类规则占了预警总量的七成左右计算成本低、可解释性强业务方也容易信任。机器学习模型负责处理那些需要预测的场景。比如根据历史数据预测“某供应商这次的交期大概率会延迟”用的是梯度提升树这类传统的监督学习模型特征包括供应商历史准交率、最近三个月的延迟趋势、当前订单的提前期是否偏短等。这类模型不需要大模型那么强的语言理解能力但预测准确率对所有预警的可信度至关重要。大模型在这套体系里做的是语义理解和信息生成。具体来说当规则或模型触发一个预警之后大模型负责做两件事第一把预警转成一段业务人员能秒懂的自然语言说明包括影响什么订单、涉及哪个客户、当前卡在哪个环节第二根据协同记忆库里的历史案例生成初步的处理建议。比如它会在预警信息里补上一句“根据历史同类型案例这类延迟平均需要提前3天锁定物流舱位建议物流经理现在确认舱位。”5.4 智能体编排消息如何精准到人预警触发之后怎么让对的人看到对的信息这是智能体编排要解决的问题。我们先梳理了订单延迟场景涉及的所有角色和职责边界角色核心职责预警后需要看到的内容客户经理维护客户关系哪些订单受影响、预期延迟多久、是否需要提前通知客户计划员调整排产与交期承诺延迟原因、涉及物料、可替代方案采购员跟催供应商缺料清单、供应商交期承诺、替代货源建议仓储主管协调收货与发运资源到货批次变化、库容建议、是否需要加班物流经理协调运输资源调整后的提货时间、舱位或车辆预留建议智能体编排的核心是把一条预警拆成多个“任务卡片”按角色的不同推送到对应的IM工作群或OA待办里。每条卡片除了问题描述还会带两个按钮“确认处理”和“反馈建议”。这两个按钮形成的闭环数据是我们用来持续优化AI建议准确率的金矿。5.5 灰度上线与复盘小步快跑定期校准这个项目上线方式也值得说一下。我们没有一次性把全部订单类型都覆盖而是选了三条产品线做灰度验证跑了两周。灰度期间每天做一次复盘统计预警数量、准确率、平均响应时间、建议采纳率四个核心指标。两周灰度下来几个数字变化很明显预警准确率从最初的63%提升到82%平均响应时间从4小时压到28分钟建议采纳率稳定在65%左右。特别有意思的是我们发现自己预设的那些规则有不少可以优化的空间。比如按最初的规则“供应商承诺交期晚于需求日期三天”就会触发预警但实际跑下来发现有些供应商的承诺本身就留有余量要结合近三个月的实际准交率来做动态阈值这让机器学习模型的价值得到了体现。6. 常见问题与排查技巧实录6.1 业务人员不信任AI建议怎么办这是每次项目都会遇到的第一个坎。我们的经验是不要试图用宣传口号说服大家要用数据和交付物说话。上线初期建议类消息一定要带上“依据说明”。比如一条采购建议后面注明“依据最近三个月的供应商准交率数据和当前安全库存水位生成”让业务人员能追溯逻辑。另一个好用的技巧是给AI建议设计一个“模拟模式”业务人员可以在系统里先跑一下“如果按AI建议执行会有什么结果”看到结果是好的信任自然就建立起来了。6.2 AI预警过多导致“狼来了”效应预警准确率再高也架不住消息量大。一旦业务人员每天收到二三十条预警他就会自动忽略掉大部分消息。解决思路有两条第一在触发端提高预警门槛把阈值从“有风险就报”改成“风险超过一定概率才报”第二在消费端做消息聚合比如同一个SKU在一天内的多条预警合并成一条趋势分析而不是一条一条刷屏。6.3 数据口径不一致导致AI分析偏差这个坑几乎是必然踩到的。不同系统对“库存”的定义都不一样ERP里的是账面库存WMS里的是实物库存中间还有个“在途库存”的概念如果不对齐AI分析出来的结果一定会被业务人员一秒识破。做这个项目时我们专门建了一份口径映射文档把每一条业务指标在不同系统里的计算逻辑写清楚并让业务方签字确认。这个文档后来成了系统的配置依据也成了培训教材价值很大。6.4 灰度期间发现严重Bug如何回滚任何系统上线都可能出状况关键是要有明确的回滚预案。我们当时的约定是如果AI预警的错误率在一天内超过15%自动触发“熔断机制”暂停所有AI触发的消息推送把协同流程降级回人工模式。这个机制的好处是给业务方吃了一个定心丸——他们知道AI只是一个可以随时被关掉的辅助工具不会影响核心业务运行。实际执行中确实触发过两次熔断一次是因为数据管道里日期字段的时区转换出错另一次是因为某供应商在系统里主数据被误删导致关联订单大面积报错。两次都因为预案准备充分在半小时内恢复。7. 经验沉淀与后续演进的几条建议7.1 渐进改造的三条红线从多个项目里踩坑踩出来的教训我总结成三句话第一不动核心主数据。物料编码、供应商编码、客户编码这些主数据是整个系统大厦的承重墙AI只能读取不能直接修改。第二不破坏财务闭环。任何涉及金额、付款、发票的操作AI可以生成建议但必须由专人审核后进入财务系统这条红线不能让。第三保留人工接管通道。不管AI跑得多顺每个自动操作界面都必须有一个“切换回人工”的入口系统的最终控制权永远在业务团队手里。7.2 组织准备比技术准备更关键有一件事我特别想强调跨岗位协同AI项目的成败五成在技术五成在组织和流程。技术团队选型再正确如果业务方没有准备好接受“AI建议可能出错”这个事实项目推进就会寸步难行。我们在项目启动前会花很多时间去跟业务方对齐预期明确告诉他们AI不是来替代岗位的而是来帮大家减少重复沟通和低价值工作的。计划员的重复催料、采购员的电话跟单、仓储的反复电话确认这些工作未来都会大幅减少但专业判断、异常处理和供应商关系维护这些核心技能恰恰是AI暂时替代不了、也需要人来投入更多精力的地方。7.3 后续演进从单场景智能体走向多Agent自主协同这个项目跑通之后企业自然会想把成功的模式复制到更多场景比如采购对账协同、库存调拨协同、供应商质量问题处理协同。场景多了之后各个智能体之间就需要一套统一的通信协议和任务调度机制不然会出现“这个AI建议采购加量那个AI建议仓储清库存”的矛盾。我们目前的方向是把每个场景的智能体沉淀为可复用的能力组件比如供应商交期预测组件、库存风险评分组件、消息生成组件让新场景可以通过搭积木的方式快速组合。同时也在探索用一个大模型的“调度中枢”来协调各个智能体的工作优先级但这一步我们态度很谨慎因为涉及的权责边界会更复杂。7.4 最后一句话的个人体会做供应链AI应用这几年我最大的感受是AI能跑多快往往不取决于算法有多先进而取决于你身边的组织愿意以多快的节奏去吸收和适应它。渐进改造听起来不像“颠覆式创新”那么性感但它确实能帮企业用最小的代价把AI能力一步一步长到自己的业务流程里。未来回头看你今天搭好的那条数据管道、那份口径文档、那套让业务方建立信任的预警机制可能比任何一个单独的AI模型都更值钱。