供应链标准产品工作台：
让计划和订单人员先看到问题

计划靠线下协同、订单履行看不见、异常难追溯、经营指标分散，这些问题在不同制造企业里反复出现；但每家企业的组织、数据和流程又不一样。

所以目标不是把一个客户的系统复制给下一个客户，而是找出稳定的业务对象和决策链路：共性做成模块，差异做成配置，交付沉淀为可复用的版本基线。

我在其中做的事

• 参与市场调研、竞品分析、立项申请和版本规划，识别能复用的共性场景；
• 负责计划、订单、运营相关工作台的交互原型和关键页面，参与 BI 大屏与运营驾驶舱设计；
• 参与需求评审、研发协同和测试验收，整理版本材料；
• 制作产品 Demo、软著申报材料和宣传方案，支持售前演示。

计划员每天要回答三件事：哪里供不上，影响哪些订单，该找谁处理。原来这些信息散在报表、邮件和会议里。工作台按“指标变化、供需缺口、关键预警、协同日历”的顺序组织，先发现问题，再进入处理。

判断：首页不是指标陈列。每条预警都要回答“为什么、影响什么、下一步做什么”，并直接给出处理入口。

订单履行人员关心的是：一张订单卡在哪个环节，该谁负责。工作台按“履行指标、端到端链路、异常订单、责任待办”组织。点链路上的一个环节，就能筛出卡在这一环的订单。

判断：大屏和驾驶舱的数字都要能落到任务。点任何一个数字，都能看到对应的订单和负责人。

供需平衡是客户差异最大的地方：有的企业按订单先后分配，有的按客户等级；有的追求交付率，有的追求库存最低。产品没有为某家客户写死规则，而是把需求优先级、库存优先级、优化目标和业务约束做成配置项，试算结果要能解释、能追溯。

供需分配算法由研发团队实现；我参与的是配置项、试算流程和结果呈现的方案设计。

1. V3.0版本基线

   跟踪 23 项需求、178 个用例，144 个缺陷中 124 个已解决，结论为商用发布。

2. V3.1轻量化与授权

   30 项需求、43 个用例全部通过，32 个缺陷全部闭环；覆盖 License 能力，以及订单、计划模块与模型驱动平台的对接。

3. V3.3供需分配

   18 项需求、25 个用例全部通过，19 个缺陷全部闭环；覆盖优先级、优化目标、约束、试算、接口与结果展示。

4. V3.6产品蓝图

   形成计划、订单、物流一站式协同平台与运营中心的产品蓝图。

以上是产品团队的版本数据，用来说明能力形成了可测试、可复制的基线，不是个人业绩。

我参与了约半数项目的售前演示或项目支持。签约与落地是部门结果，不等同于个人业绩；产品目前没有适合公开的业务改善指标，界面中的数字都是演示数据。