供应链管理中，有一个问题长期困扰着企业：异常已经被看见了，但问题仍然没有真正被解决。一个订单延期，到底是客户需求变化导致的？是订单确认不足？是库存无法承接？还是仓储、运输环节出现异常？一个 Loss 数字背后，究竟是规划阶段的问题，还是履约执行的问题？找到问题之后，又应该由哪个团队处理？采取动作之后，业务结果是否真正改善？
过去，Control Tower 解决的是"让异常被看见"。企业真正需要的，是让异常进一步走向：为什么发生？应该怎么处理？处理之后有没有改善？
在本期观远数据 Aha! Moment 直播中，我们围绕供应链 Control Tower 场景，通过一个完整业务案例展示：观远供应链 Agent 如何从全局扫描异常，到深入拆解根因，再到推动 PDCA 闭环，让供应链管理从"看见问题"，走向"解释问题、处理问题、沉淀经验"。
注：以下内容所涉案例中所有具体业务数据均为模拟数据，仅为还原真实业务场景中的核心问题，不代表任何真实企业的实际经营情况。
01 异常不是只要被看见 而是要知道先追哪里的问题
很多企业做 Control Tower 时，第一反应是把订单流转和核心指标放到一张大屏上。订单有没有创建，是否已经确认，仓库有没有发货，运输是否在途；OTIF、OTD、Loss、Loss 原因等指标也都被定义出来。看起来，供应链链路已经被集中展示了。
但即使有了大屏和指标，业务人员仍然很难回答两件事。第一，这些指标变化背后关联的风险是什么？第二，指标异常之后，业务人员到底应该采取什么行动？
所以，我们先做了一个全局扫描，这个页面主要回答三个问题：
当前履约状态是否存在异常？
如果存在异常，影响范围有多大？
下一步应该优先看哪个客户、哪个渠道或哪个范围？
过去，这一步往往依赖供应链核心人员每天早上打开多个报表，分别看 OTIF、订单、库存、Loss，再凭经验判断要先从哪里查。现在，Agent 会先完成一次主动扫描，帮助业务人员锁定异常范围和处理优先级。
在本期案例中，顶部状态明确提示：当前阶段存在明显异常，受影响客户有 14 家，受影响 SKU 有 27 个，Loss 订单行有 187 条。再看核心 KPI。当前 OTIF 为 87.6%，相比目标 95% 明显低了接近 8 个百分点，相比上期也下降了 3.2 个百分点。OTD 和订单满足率也有下降。
但 Agent 提醒，真正需要重点关注的是 Loss。本周 Loss 已经接近 91,800 箱，相比上周增加 35,400 箱，增幅约 63%。这说明问题不只是 OTIF 掉了，也不只是某个指标表现不好，而是当前履约服务水平下降的同时，需求与履约确认之间的缺口被明显放大。
从趋势上看，Loss 从 4 号开始出现大幅上升，对比当前周期和上期状态，异常非常明显。Agent 的主动摘要也把问题指向了 Loss Quantity，并提示主要影响渠道、重点客户和下一步建议。
接下来，页面进一步拆贡献，看本次下降究竟是谁在拖累整体表现：
从客户集中度看，Top3 客户合计贡献了将近 67% 的 Loss，说明这次异常不是平均分散在所有客户上，而是集中在少数重点客户上。
从渠道看，国家级重点客户，也就是 NKA，贡献约 40%；电商模块贡献接近 30%。这两个渠道本身都对履约稳定性非常敏感：NKA 关系到战略客户服务，电商则关系到线上订单体验和促销承诺。
从品类看，异常更多集中在衣物清洁相关品类；从地域看，华东区域承担了接近 50% 的 Loss。
左右滑动查看更多
最终，在客户和渠道列表中，Loss 最严重的是 华东全国连锁客户，其次是全国电商平台自营。到这里，第一部分已经把一个笼统的"履约异常"，定位到了更明确的追查入口：华东区域、国家级重点客户、华东全国连锁客户。这背后的关键，是 Agent 并不是单纯联动几张图，而是结合了业务本体中客户、渠道、客户等级、OTIF、Loss 数量、Loss 占比、Loss 订单行等关系，快速判断哪些对象风险更高、哪些对象应该优先关注。
Aha!
Control Tower 的核心价值，不是多看几个指标，也不是把所有指标联动起来，而是更快知道应该先追哪里的问题。
第一个 Aha! Moment：OTIF 不是一个结果数字，而是一条完整履约链路的最终表现。认知变化：从看 KPI，升级到看订单、库存、仓储和物流事实链。
02 Loss 不是一个总数 而是要拆清楚贡献、阶段和证据
第一部分定位到华东全国连锁客户之后，第二部分就进入拆贡献和找原因。
这个客户的 Loss 已经达到 2 万多箱，对应的 Loss 订单行接近 30 条。这一整页要解释的，就是这 2 万多箱 Loss 到底是怎么来的。这里的关键不是再看一遍总数，而是把 Loss 拆到几个层次：先看 SKU，再看问题发生在哪个阶段，再看规则原因，最后落到具体订单。
从 SKU 层面看，SKU-001（洗衣液相关商品）贡献最大，接近3,700箱，占整体 Loss 的 16.8%。这说明问题并不是所有商品平均异常，而是存在明显的重点 SKU。
接着，看阶段构成。当前 Loss 中，订单确认问题占约 60%，履约执行问题占约 34.9%。也就是说，如果要继续深入拆解，最核心的方向应该先看订单确认问题，而不是一上来就去找仓库或物流。Agent 在订单确认问题中识别出的首要原因，是 ATP 可承诺量不足，贡献了接近 7,000 多箱 的 Loss。它进一步指出，当前问题与洗衣液 SKU 相关，并关联到 0187 这张订单；匹配到的规则原因，就是 ATP 可承诺量不足。
这一步非常重要。因为在真实业务中，看到"客户 Loss 很高"以后，很多人会自然理解为"还有很多货没发出去"。但直播中的案例说明，这个判断可能是错的。
对于这个华东全国连锁客户来说，大量 Loss 不是货已经进入仓储物流环节后才发不出去，而是在前段订单确认阶段就没有被足量承诺。
订单确认问题主要看的是：客户需求来了以后，系统有没有足量确认，有没有受到 ATP、库存、安全库存、生产供给等约束。在这个案例里，ATP 可承诺量不足是首要原因，库存及安全库存约束、其他确认约束也构成了影响。履约执行问题则是另一类逻辑。它发生在订单数量已经确认之后，继续往仓储、跨仓、PGI、运输等环节推进时出现异常。比如跨仓或分仓延迟，运输节点没有及时跟踪，甚至 3PL 状态缺失。也就是说，同样叫 Loss，背后的责任方向可能完全不同。
如果是 ATP 不足，问题更偏 Planning，需要复核供给计划、可承诺量和库存约束；如果是仓储物流履约问题，就可能要优化物流路线、RDC 仓储分布或 3PL 节点回传机制。
直播中继续下钻到订单级。进入订单列表后，系统不再只是从客户维度看 Ordered、Confirmed 和 Loss，而是把重点订单排出来，让业务看到每一张订单的影响量、问题阶段、风险严重程度和证据。其中，0187 订单被识别为重点订单。它的问题归结为订单确认问题，当前风险是确认缺口待处理。BI 证据链与 Agent 诊断相互印证：问题确实集中在洗衣液 SKU 和 0187 订单上，且与 ATP 可承诺量不足相关。
Aha!
根因不是一个标签，而是一条能够回到订单数据的证据链：
哪个 SKU 贡献最大；
问题发生在订单确认还是履约执行；
命中了哪类规则原因；
关联到哪张订单；
订单当前风险是什么；
后续应该指向哪个责任团队。
第二个 Aha! Moment：根因不是一个标签，而是一条能够回到具体订单的数据证据链。认知变化：从"库存问题、物流问题"的粗分类，升级到规则命中、订单影响和责任方向。
03 Agent 不是替人拍板 而是把订单风险推进PDCA闭环
找到订单问题之后，第三部分进入订单处置。这时分析已经来到最细颗粒度：0187 订单。这张订单的实际需求量是 8,000 箱，已确认数量是 4,800 箱，实际影响形成 3,200 箱 Loss。由于责任方向属于前段确认问题，改善方向指向 Planning。
系统给这张订单设置了处理时限：需要在 2 天 内完成闭环动作。之后，系统还会回到 KPI 结果中观察，这次处理是否让异常收敛，业务情况是否好转。
从订单节点看，这张订单从创建到 Confirm，再到后续提货和在途，原本应该沿着完整链路继续推进。但当前卡在订单确认节点，后续节点无法完整完成。订单已经在确认节点停留 12 小时，属于急需改善的状态。
这时 Agent 给出风险判断：当前需要复核供给计划，确认补量；也可以评估替代仓，快速提高 Confirmed Order 的数量；必要时做拆单方案。可以看到，Agent 并不是停留在"这个订单有风险"，而是把风险转成了可执行的处置方向。
接下来，页面进入 PDCA 任务链路。PDCA 在这里不是一个抽象管理模型，而是从异常识别推进到处理和复盘的行动策略：
Plan，制定方案和目标；
Do，执行具体动作；
Check，验证执行效果；
Act，复盘并沉淀经验。
在过去，制造业供应链中的很多处置经验依赖"老师傅"的个人判断。经验有效，但沉淀慢、传承难，也很难在每一次订单处理中被标准化复用。Agent 结合 PDCA 后，能把每一次 Planning 或执行后的结果记录下来，让后续类似问题有迹可循。
在 Plan 阶段，系统不仅重复展示问题和影响基线，更重要的是给出处理方案和处理目标。Agent 建议的动作包括复核 ATP 与供给计划、确认补量、评估替代仓或拆单方案。
但这里有一个关键边界：Agent 给出建议之后，并不会直接替业务执行。在真实工作场景里，不可能 Agent 一给建议，业务就立刻批准。是否补量，是否替代仓，是否拆单，都需要人工核验。Agent 的角色不是替代人工，而是作为人工更好的助手，帮助优化整体工作。
所以，系统会由 AI 推荐责任团队，例如 Planning；再由业务人员手工选择负责人，比如周负责人；并在确认验证通过后，进入正式执行。处理目标也不是一句"请尽快处理"。页面给出的目标很明确：满足率要达到设定目标值，确认缺口，也就是 Loss，要尽可能降低到 0 箱。
在 Do 阶段，责任人按照执行清单推进子任务。直播中展示的结果是：周负责人完成了对应三项任务，确认补量 3,000 多箱，剩余缺口还有 120 箱，但已经比未处理状态明显改善。
在 Check 阶段，系统关注的不是责任人有没有点"完成"，而是在 deadline 之前，目标是否真的被达成。最终结果显示，该任务完全达标，订单级风险已经解除，并建议进入 Act 复盘和同类异常对比。从结果看，满足率从约 82% 提升到约 97%；拆单或补量后，Loss 程度下降到约 7.2%。同类异常在处理后的观察期内持续减少，说明这次处置不只是完成了一张订单，也对同类问题的后续管理产生了帮助。
在 Act 阶段，系统沉淀出几类标准化动作：如果后续再次出现类似缺口，应在 Planning 层做提前预警；如果缺口过大，应快速评估替代仓能否承接；对于重要战略客户的大额订单，提前考虑拆单，别把所有订单压力集中在一条产线或单一路径上。
这些动作会进入下一次 Agent 智能巡诊中，持续用于 Loss 诊断。
Aha!
从数据源到人员配置，再到行动状态抓取和复盘，过去需要大量表格和人工协作；现在每位业务人员都可以在平台上看到清晰链路：我应该做什么、什么时候完成、要达到什么目标、最后产生什么复盘结果。
第三个 Aha! Moment：Agent 的价值不是回答问题，而是帮助业务形成统一的处理顺序。认知变化：从自然语言问数，升级到风险排序、摘要输出和行动协同。
04 DecideX + AI Agent 让决策更智能，行动走向闭环
在 BI 时代，数据应用更多解决的是"让数据被看见"。但进入 AI Agent 阶段，企业真正希望的是让决策更智能，行动走向闭环。
在决策和数据分析领域，做 Agent 的难度更高，如果 Agent 不是建立在可信的数据底座上，如果它不知道业务真实运行逻辑，不知道 Control Tower 到底是什么场景，不知道业务每天面对什么问题、过去通常怎么解决，它就无法给出有证据、有责任、有闭环的建议。
所以，观远构建面向业务决策的 Agent，不是单纯讲抽象产品概念，而是强调它未来要能落到真实业务判断中。
Control Tower 数字员工可以理解为几层能力的结合：
第一层，是观远 Decide X 和企业已有 BI 数据底座。很多企业已经在 BI 中沉淀了大量数据，DecideX 会把这些多元数据承接到业务决策模型中，作为可信数据源。
第二层，是 KPI 规则资产，也就是对象、指标和关系。比如 Agent 面对订单、SKU、渠道等不同经营对象时，应该如何识别、如何判断、沿着哪条推理链路继续往下走。
第三层，是异常拆解和行动建议。当 Agent 识别出异常并拆解到原因之后，能够给出相应建议，再由真正的员工与数字员工协同确认。
第四层，是在数据应用产品中完成 PDCA 和知识沉淀。最终目标，是让 Agent 越来越像企业经营和业务判断中一起共事的数字伙伴。
AI Agent 不是一个外挂入口，也不是一个通用问答助手，而是要建立在业务本体、可信数据、规则资产和行动闭环之上，真正成为业务生产力。
结语 从看结果到找原因 从找原因到把订单风险闭起来
本期直播，我们不是简单展示一个 Control Tower，而是走完了一条供应链异常从发现到闭环的完整链路：看结果 → 拆贡献 → 找原因 → 识别风险 → 排优先级 → 推动闭环。
过去，企业通过 Control Tower 可以看到 OTIF、Loss 等指标变化，但指标只是结果。真正困难的是，当异常发生时，业务能否快速判断问题在哪里、为什么发生，以及下一步应该如何处理。
观远供应链 Agent 通过全局扫描识别风险，通过业务链路拆解根因，再通过 PDCA 推动订单风险闭环，让供应链管理从"看到异常"走向"解释异常、处理异常、沉淀经验"。它解决的不是"有没有数据"的问题，而是供应链运营中更关键的三个问题：发现慢、归因粗、闭环弱。最终让Control Tower 不再只是一个监控异常的大屏，而是一套连接数据、判断、行动和反馈的智能运营工作流。
对管理者来说，它让异常不再停留在一个 Loss 数字上。
对供应链团队来说，它减少了人工拆数和经验猜测。
对 Planning、仓储、物流等责任团队来说，它让每个任务都有证据、有目标、有验证标准。
对企业来说，它让 Control Tower 从一个大屏，升级为一套可以持续推动业务改善的智能运营工作流。
供应链 Control Tower 的下一步，不只是让异常被看见，而是让异常被解释、被处理、被验证，并最终沉淀为可复用的运营经验。
想进一步体验 AI+BI 在业务分析中的落地效果，可以从这里开始。
