很多制造企业都会遇到一个问题：需求计划每个月都在做，每周都在改，甚至每天都在被销售、计划、供应和生产反复拉扯。
销售说客户要货，DP 说历史出货不支持；供应说库存水位不对，生产说产能窗口排不进去。最后，大家经常围绕一张计划表反复确认：这个 SKU 到底该填多少？销售提报要不要采纳？库存和产能能不能接住？执行后偏差到底是谁的问题？
DP 计划难，并不是因为企业没有计划表，而是因为计划本身连接了多方变化：销售目标会变，客户需求会变，渠道活动会变，SKU 动销会变，库存水位会变，产能排期也会变。
在观远数据「Aha! Moment」直播间中，我们围绕制造业需求计划管理场景，用一个完整的制造企业 Demo，展示观远超级应用（SuperApp）和 Agent 如何串联 SP 销售计划填报、DP 需求计划确认、库存与产能承接、DP 计划质量复盘，让需求计划从“反复改表”走向“目标驱动、供应验证、复盘修正”的闭环管理。
注：以下内容所涉案例中所有具体业务数据均为模拟数据，仅为还原真实业务场景中的核心问题，不代表任何真实企业的实际经营情况。
01 SP 不是直接填数 是把销售目标拆成可解释的计划建议
很多企业做需求计划时，起点并不是某一个 SKU，而是更上层的销售目标：下个月要完成多少销售金额，未来三个月要滚动达到多少目标。
但销售目标本身无法直接指导供应链执行。它必须继续拆到具体客户、渠道、SKU、品类和周度窗口，才可能形成可提交给 DP 的销售计划。
这也是 SP 销售计划填报的第一道难题：目标不是不能拆，而是拆完之后，每一个数字能不能解释清楚。
在本期 Demo 中，第一步进入的是 SP 销售计划填报。这是销售侧入口，不是 DP 计划员的最终确认页。销售人员先看到本周期销售目标和当前填报进度：M+1 销售目标是 3,200 万元，已填报金额是 2,860 万元，待补目标是 340 万元，M+3 滚动目标是 9,600 万元，当前 SP 提交达成率是 89.4%。
这说明销售侧当前填报还没有达到锁版前目标，需要继续拆到 SKU 和周度上。此时 Agent 给出建议补量 42 万箱，折算金额约 245 万元，可覆盖目标缺口的 72%。也就是说，Agent 不是直接替销售填一个数字，而是先回答一个更业务化的问题：为了达成销售目标，哪些客户、哪些 SKU、哪些周度应该补量？哪些 SKU 应该下调？哪些 SKU 应该暂缓？
以 茉莉绿茶 500ml｜8 月第 3 周 为例，这条计划来自 KA 渠道客户华联量贩，属于茶饮系列。当前 SP 填报量是 82 万箱，近 3 月均出货是 72 万箱，Agent 建议量是 90 万箱，AI 差异是 +8 万箱。
如果只看这几个数字，业务人员很难判断该不该采纳。但点击“查看依据”之后，可以看到 Agent 的判断依据：近 3 月均出货 72 万箱，去年同期 68 万箱，近 4 周动销 +8%，SKU 目标缺口 36 万元，渠道缺口 180 万元，客户缺口 62 万元，目标金额占比 21.5%。
这些信息合在一起，才解释了为什么 Agent 建议从 82 万箱上调到 90 万箱：不是单纯为了把目标填满，而是因为该 SKU 有一定动销支撑，同时也承担了渠道和客户层面的目标缺口。
因此，销售侧可以选择采纳、部分采纳或不采纳 Agent 建议。点击“采纳智能体建议”后，当前 SKU 的 SP 填报量会更新为 Agent 建议量，并作为销售侧提报结果提交给后续需求计划环节。
但这一步并不代表计划已经可以锁版。采纳 SP Agent 建议，只说明销售侧认可这个填报逻辑；接下来还要进入 DP 计划员视角，判断这个销售提报能不能转成真正的需求计划。
Aha!
从销售目标到 SP 提报，Agent 把一个销售目标拆成可解释的客户、SKU 和周度计划，让每一个填报数字都带着目标依据、历史依据和客户依据。
第一个 Aha! Moment：SP 填报不是销售凭经验报数，而是让目标缺口被拆成有依据、可判断、可提交的计划建议。
02 DP 不是重复填报 是判断 SP 提报能不能转成需求计划
销售完成 SP 提报之后，计划还不能直接进入供应和生产。
因为销售侧更多站在目标、客户和渠道活动角度做判断，而 DP 计划员要进一步结合历史出货、库存状态、动销趋势、目标结构和承接风险，判断这个 SP 提报是否合理。
因此，第二步进入的是 需求计划工作台。这一页的核心问题不是“销售应该填多少”，而是：SP 提报是否合理？是否要转成 DP 需求计划？是采纳、调整、退回，还是提交承接校验？
还是以茉莉绿茶 500ml 为例。销售侧 SP 提报是 82 万箱，历史参考是近 3 月 72 万箱，Agent 建议是 90 万箱，人工填报量仍然可以由 DP 计划员调整。系统同时展示库存状态和承接状态，例如当前库存状态是低于安全水位，承接状态是待校验。
这时候，DP Agent 的角色和 SP Agent 不一样。
SP Agent 更关注：为了完成销售目标，应该怎么拆分和补量。
DP Agent 更关注：这个销售提报是否合理，是否能进入需求计划，是否需要库存与产能承接校验。
所以 DP Agent 的建议会更综合。例如：
茉莉绿茶 500ml 当前 SP 提报 82 万箱，建议调整为 90 万箱。该 SKU 近 4 周动销稳定增长，销售目标缺口仍需补量，但当前 SP 库存 38 万箱，低于安全水位，因此建议部分采纳 SP 补量，并提交库存与产能承接校验。
这句话里包含两个判断。
第一，需求上调有一定合理性，因为目标缺口和动销趋势支持补量。
第二，这个计划不能直接锁定，因为库存状态存在风险，必须继续进入承接校验。
这就是 DP 工作台的价值：它不是重复销售填报，而是把 SP 提报转成一张可判断、可校验、可回写的需求计划表。
对于不同 SKU，DP Agent 会给出不同判断。
有些 SKU 可以保持，例如橙汁 1L，结构稳定、库存正常，可以直接提交。
有些 SKU 需要下调，例如乌龙茶 500ml，SP 库存偏高，近两周动销放缓，Agent 建议从 76 万箱下调到 64 万箱。
有些 SKU 可以补量但必须校验，例如青柠气泡水 330ml，渠道活动拉动明显，但库存偏低。
还有些 SKU 不建议继续上调，例如白桃气泡水 330ml，铺货率不足，应该暂缓放量。
所以，DP 计划员看到的不只是销售提报数量，而是每一行计划背后的判断逻辑：历史是否支撑、库存是否健康、动销是否匹配、是否需要承接校验。
当 DP 计划员确认后，可以点击“提交承接校验”。这个动作代表 DP 侧已经完成计划判断，但还没有完成执行判断。接下来要进入库存与产能承接，看这个 SKU 的计划能不能被供应链接住。
Aha!
从 SP 提报到 DP 确认，Agent 把销售侧目标逻辑转成计划侧判断逻辑，让 DP 能区分哪些计划可以采纳、哪些需要调整、哪些必须继续校验。
第二个 Aha! Moment：DP 不是重复销售填报，而是把 SP 提报转成可判断、可校验、可承接的需求计划。
03 计划被确认 不代表库存和产能接得住
在需求计划管理中，“计划侧认可”和“执行侧接得住”是两件事。
一个 SKU 的 SP 提报有目标依据，DP 计划员也认可它具备一定需求逻辑，只能说明这个数字在计划侧成立。但要真正进入执行，还必须继续回答：库存够不够？在途能不能赶上？安全库存有没有被击穿？产能窗口能不能排进去？
因此，第三步进入的是 库存与产能承接。
这一页不是全局看板，而是从 DP 工作台某一行 SKU 打开的二级分析页面。它围绕单个 SKU 展开，专门判断这条需求计划是否可以执行。
以 茉莉绿茶 500ml｜M+1 W3 为例，页面顶部会明确当前分析对象：SKU 是茉莉绿茶 500ml，品类是茶饮系列，周度是 M+1 W3，SP 提报量是 82 万箱，金额是 98.4 万元，Agent 建议量是 90 万箱，采纳状态是部分采纳，承接状态是建议调整填报量 / 库存偏高。
这时要回答的问题是：这个 DP 计划能不能被库存、在途、安全库存和产能窗口接住？
先看库存水位。当前 SP 填报量是 82 万箱，可用库存是 210 万箱，在途库存是 18 万箱，安全库存是 150 万箱。预计库存覆盖是 35 天，高于 25 天安全阈值。Aging 风险量是 18 万箱，黄货风险金额是 280 万元。
这组数据说明，茉莉绿茶 500ml 当前不是供应不足，而是库存覆盖偏高。如果继续按照 82 万箱甚至 90 万箱去锁版，并安排新增投产，就会继续放大 Aging 和黄货风险。
再看周度承接。对于 M+1 W3 来说，需求是 82 万箱，库存加在途高于安全库存，因此系统判断它“可承接”。但这里的“可承接”不代表计划健康，只说明它不会缺货。真正的问题是库存水位已经偏高。
这就是承接分析里的一个关键区别：有些 SKU 是接不住，因为库存不够；有些 SKU 是接得住，但不应该继续投，因为库存已经太高。
茉莉绿茶 500ml 属于第二类。
再看产能窗口。茶饮产线 A 负荷为 72%，茶饮产线 B 负荷为 68%，华东包装线负荷为 76%。从产能角度看，产线不是瓶颈。系统甚至提示，茶饮产线 A 可暂停本 SKU 排产，茶饮产线 B 可延后投产窗口，跨区调拨池可以向低库存区域调拨消化。
所以这个页面最终给出的承接建议不是追加生产，而是：暂停新增投产，优先跨区调拨，并结合渠道促销消化库存。
在下方的回写结论中，系统会把承接结果回写到 DP 工作台同一行 SKU：
承接状态：建议调整填报量 / 库存偏高。
建议修正量：82 → 72 万箱。
建议动作：暂停新增投产；跨区调拨 22 万箱；下调第 4 周补货；结合渠道促销消化库存。
是否允许锁版：否，需先确认库存消化动作。
责任团队：库存计划 / 销售计划 / 生产计划。
回写备注：茉莉绿茶 500ml 库存覆盖 35 天，高于安全阈值，存在 Aging 与黄货风险，不建议继续按当前量锁版。
这一步的价值，不是把“库存偏高”四个字写回计划表，而是把库存、在途、安全库存、产能窗口和建议动作一起带回计划链路。
所以，库存与产能承接校验真正解决的是：这个计划不是能不能写进表，而是能不能被执行链路接住。
点击“回写状态”后，承接结论会回到 DP 工作台，并弹出提示：是否进入计划复盘。这个入口非常关键，因为计划管理不是状态回写就结束。执行之后，还要继续看：本周期计划准不准，满足率如何，库存健康是否恶化，下周期应该怎么改。
Aha!
从 DP 确认到承接校验，Agent 把计划数字放到库存、在途、安全库存和产能窗口里验证，并把承接状态和建议动作回写到计划链路。
第三个 Aha! Moment：计划被确认，不代表能够执行；需求计划必须经过库存与产能侧的承接验证。
04 复盘不是看差了多少 是判断下周期怎么修
计划执行之后，很多企业最先看到的是偏差：计划报了多少，实际出了多少，中间差了多少。
但偏差本身不是结论。真正重要的是判断：这个偏差来自哪里？是需求填高了，还是供应没满足？是库存太高，还是库存不够？是单个 SKU 的问题，还是品类结构已经跑偏？下周期到底应该怎么修？
因此，最后一步进入 DP 计划质量复盘。
这一页不是继续处理某个 SKU 的承接问题，而是站在本周期执行结果上，把前面的 SP 提报、DP 确认、承接结果和实际执行串起来，形成一份可追溯的复盘报告。
如果是从茉莉绿茶 500ml 的承接回写进入，顶部会显示来源提示：来自 Agent 承接回写｜茉莉绿茶 500ml｜M+1 W3｜茶饮系列。
SP 提报量是 82 万箱，实际出货是 66 万箱，承接状态是建议调整填报量，Agent 修正量是 82 → 72 万箱。这说明复盘不是凭空生成的，而是从前面的承接结论进入的。
页面首先给出复盘结论：该 SKU 先跨计划，再消化库存。
Agent 的判断是：茉莉绿茶 500ml 不是供应不足，而是需求高估带来库存风险。SP 填报 82 万箱，实际出货 66 万箱，偏差约 24%；库存覆盖 35 天，Aging 风险 18 万箱。下周期应压降填报量，暂停新增投产。
这个结论把本周期问题说清楚了：问题不是缺货，不是产能不足，而是前端计划填高了，并且库存已经被推高。
接下来进入偏差归因。SP 填报量是 82 万箱，实际出货是 66 万箱，偏差量是 16 万箱。从计划视角看，兑现率只有 80%。但进一步拆解可以发现，实际需求已经被满足，偏差来自需求高估，而不是供应未满足。
所以，满足率低不能直接等同于供应问题。这就是复盘页的核心价值：不只是看差了多少，而是判断偏差性质。
再看库存健康。茉莉绿茶 500ml 的库存覆盖达到 35 天，高于 25 天阈值；Aging 风险量 18 万箱，黄货风险金额 280 万元。这说明前面的计划高估已经传导成库存健康问题。库存健康已经成为下周期计划约束，不能再继续新增投产。
再看结构偏移。茉莉绿茶所属品类是茶饮系列。茶饮系列目标金额占比是 38%，实际贡献是 45%，偏移 +7pp。这说明茶饮系列实际贡献已经高于目标，不是当前最需要补量的品类。继续给茶饮补量，会进一步推高结构偏移和库存压力。
所以，复盘不是停留在“某个 SKU 偏了”，而是把这个偏差放回目标结构中判断：这个 SKU 所属品类还该不该继续补？这个品类是不是已经过度贡献？下周期目标拆解要不要调整？
在底部的证据链中，系统保留了几个反向入口：填报来源、承接过程、定位计划行、SKU 校验详情。
点击填报来源，可以回看 SP 销售计划最初是怎么填出来的。
点击承接过程，可以回看库存与产能当时是怎么判断的。
点击定位计划行，可以回到 DP 工作台对应 SKU 行。
点击 SKU 校验详情，可以打开刚才这条 SKU 的承接分析。
这样，复盘就不是一份孤立报告，而是把 SP、DP、承接和执行结果串成一条完整证据链。
右下角的 Agent 复盘助手还可以继续追问：
这个 SKU 本周期最大问题是什么？
满足率低是需求问题还是供应问题？
库存健康是否已经恶化？
下周期要不要继续补量？
这个 SKU 所属品类结构是否偏高？
系统会基于前面的图表和证据继续解释。例如，它会判断：茉莉绿茶 500ml 本周期最大问题不是供应不足，而是需求高估和库存压力叠加。建议下周期将该 SKU 填报量从 82 万箱下调至 72 万箱，并暂停新增投产，优先消化库存。
Aha!
从执行结果到计划修正，Agent 把偏差分析、满足率分析、库存健康和结构偏移放在一起，判断下周期应该下调需求、补齐供应，还是调整结构。
第四个 Aha! Moment：复盘不是看差了多少，而是判断偏差来自哪里，并把结论沉淀到下一周期计划修正。
05 GuanCLI + 超级应用 低门槛搭建可生长的业务应用
很多企业会好奇：这样一套完整的计划闭环应用，搭建起来会不会很复杂？直播中也通过实操演示了这套应用的搭建与迭代方式 —— 依托GuanCLI + 超级应用（SuperApp），即使是非技术背景的业务人员，也能快速完成应用的修改、配置与发布。
1、标准化底座，解决 “样板房没法住” 的问题
不同于普通 AI 生成的 “只有页面、没有数据” 的样板界面，超级应用（SuperApp）构建在观远 BI 的标准化数据底座之上，天然继承了企业统一的数据集、指标口径、数据权限、发布与管控体系。
数据口径统一：所有计划、库存、产能数据来自同一套数据底座，不存在多方口径不一致的问题；
权限自动继承：不同角色（销售、计划员、生产、管理者）进入应用后，自动匹配对应的数据权限，只能查看所辖范围的数据；
交互能力完整：筛选、联动、钻取、填报等交互能力原生支持，无需额外开发。
2、自然语言交互，应用修改像聊天一样简单
传统报表或应用的修改，需要提需求、排开发、做测试，周期动辄数天。而借助GuanCLI 的 AI Agent 能力，业务人员只需用自然语言描述需求，Agent 就能自动定位代码、完成逻辑修改、校验功能效果，全程无需手动编写代码。比如只需输入 “在 SKU 需求计划表中增加比例调整功能，修改占比后自动联动更新同品类其他 SKU 的数值与金额”，Agent 就能在短时间内完成全部功能调整。
3、一键发布，快速落地到业务
完成应用调整后，只需一句指令，就能将项目一键发布为超级应用（SuperApp），同步到观远 BI 环境中。业务人员无需安装额外软件，通过 BI 后台即可直接访问使用，真正实现 “当天提需求、当天改功能、当天就落地”。超级应用（SuperApp）不是固定的报表或页面，而是一套可生长的应用能力 —— 底座是标准化的，业务表达是自由的。企业可以根据自身业务流程，灵活搭建符合自己需求的计划管理应用，并且随着业务变化快速迭代。
AI 时刻 Agent 不是替人填数字 而是让每个数字进入闭环
在需求计划场景里，Agent 的价值不是简单给出一个推荐量。
如果只是生成一个数字，销售不知道该不该采纳，DP 不知道能不能确认，供应和生产不知道能不能承接，执行后偏差也很难回到下一周期。
真正有价值的是，Agent 把计划数字放进一条完整链路里：
在 SP 阶段，Agent 帮销售把销售目标拆成客户、渠道、SKU 和周度计划，并解释为什么建议补量、下调、保持或暂缓。
在 DP 阶段，Agent 帮计划员判断 SP 提报是否合理，是否需要调整，是否可以进入承接校验。
在承接阶段，Agent 把计划量放到库存、在途、安全库存和产能窗口中验证，并生成承接状态、建议修正量和回写备注。
在复盘阶段，Agent 基于实际执行结果，判断偏差来自需求高估、供应未满足、库存健康恶化，还是结构贡献偏移，并生成下周期修正建议。
所以，Agent 不是替代销售、计划员、供应或生产，而是让每个角色在同一条证据链上协同。
它让每一个数字都能回答四个问题：
从哪里来？
为什么这么填？
能不能执行？
执行后该怎么修？
结语 从反复改表到计划管理闭环
今天这场直播，我们完整走完了一条需求计划管理链路。
第一步，SP 销售计划填报。它解决的是：销售应该怎么填。销售侧基于目标缺口、客户分发、渠道活动和 SKU 动销，由 Agent 给出补量、下调、保持或暂缓建议。
第二步，DP 需求计划确认。它解决的是：DP 应该怎么判。计划员不直接照单全收，而是结合历史参考、库存状态、动销趋势和 Agent 判断，确认 SP 提报是否可以转成需求计划。
第三步，库存与产能承接。它解决的是：计划能不能接住。系统围绕单个 SKU 校验库存、在途、安全库存和产能窗口，并把承接状态和建议动作回写到计划表。
第四步，DP 计划质量复盘。它解决的是：下周期应该怎么改。系统从偏差、满足率、库存健康和结构偏移四个角度复盘计划质量，并生成下周期修正建议。
如果用一句话总结：需求计划管理不是反复改表，而是让每一个计划数字有来源、有依据、有承接校验、有复盘反馈。
对销售来说，它让提报数字不再只靠经验，而是有目标、历史和客户依据。
对 DP 来说，它减少了重复判断，让计划确认更有证据。
对供应和生产来说，它提前暴露库存和产能风险。
对管理者来说，它能区分需求高估、供应不足、库存压力和结构偏移，而不是只看最后有没有达成。
最终，这套超级应用（SuperApp）和 Agent 共同做的事情，不是替人填数字，而是把需求计划从“经验填报”推进到“目标驱动、计划确认、供应验证、复盘修正”的闭环管理。
想进一步体验 AI+BI 在业务分析中的落地效果，可以从这里开始。
