FlowPilot Lab · 供应链计划与决策平台FlowPilot Lab · Supply-chain planning platform
把"月度补货 → 周度发货"这套原本靠表格计算的流程，做成每个数字都能追溯来源的平台。I turned a spreadsheet-driven "monthly replenishment → weekly shipment" process into a platform where every number can be traced to its source.
2条计算链路（月度 6 阶段、周度 8 阶段）calculation chains (6 monthly, 8 weekly stages)
6条异常规则，自动发现风险risk rules flag issues automatically
31张数据表，覆盖需求、库存、在途、订单tables: demand, stock, in-transit, orders
0差异：重构 212 个文件后结果逐字段一致differences after a 212-file refactor
项目背景CONTEXT
基于供应链实习中接触的业务，把逻辑沉淀下来。供应链计划常见三个难题：数据分散在多张表格里，计划结果说不清是怎么算的，异常往往事后才发现。Built on what I saw in my supply-chain internship. Planning teams face three problems: data scattered across spreadsheets, results nobody can explain, and issues found only after they hurt.
项目成果OUTCOME
- 打通需求预测到周度发货的完整闭环End-to-end loop from demand forecast to weekly shipments
- 任意 SKU 可逐步追溯公式、输入和重算结果Any SKU can be traced step by step: formula, inputs, recomputed value
- 开源并附中英双语说明、计算链路图和规则文档Open-sourced with bilingual docs, a chain diagram and the calculation rules
我做了什么WHAT I DID
- 拆业务流程：拆成字段定义、业务规则和页面需求，覆盖风险发现、月度计划、周度履约、查询追溯 4 个环节。Process design: broke the workflow into field definitions, business rules and page requirements across risk detection, monthly planning, weekly fulfilment and traceability.
- 造数据、验系统：演示数据覆盖 5 个渠道、6 个产品分类、18 个 SKU；测试场景参考实习中的设计，模拟缺货、到货延迟、库存积压等情况。Data and testing: demo data spans 5 channels, 6 categories and 18 SKUs; scenarios modelled on my internship test design cover stock-outs, late arrivals and overstock.
- 查问题、修问题：抽样复算修正预测口径、汇率换算和回溯逻辑；核对数据发现两处隐藏口径错误，误判的异常 SKU 从 18 个降到 8 个。Finding and fixing: sample recalculations corrected forecast, FX and trace logic; reconciliation exposed two hidden definition errors, cutting falsely flagged SKUs from 18 to 8.
- 脱敏与重构：内部编码统一换成通用业务术语，改动 212 个文件，31 张表、2,267 行结果逐字段一致。Refactor: replaced internal codes with generic business terms across 212 files; all 31 tables and 2,267 rows matched field by field.
关键取舍Key trade-off
该如何判断优先级？How do you decide what comes first?
- 起初我想尽量完整地还原业务规则，把预测需求、现有库存、在途数量、交付周期、经销商优先级都算进去，让结果更精确。At first I tried to model every business rule (forecast demand, stock on hand, in-transit quantities, lead times, dealer priority) to make results as precise as possible.
- 测试中我发现，算对了不等于用户会用。系统只给出一个建议采购量，却说不清这个数是怎么来的，用户就很难信任它。Testing showed that a correct number isn't the same as a usable one. If the system gives a suggested order quantity without explaining where it came from, users won't trust it.
- 所以我把重心转向可解释性：每个建议都能下钻查看相关的库存、需求和在途数据，并看到异常情况如何影响这个建议。So I shifted the focus to explainability: every suggestion drills down to the related stock, demand and in-transit data, and shows how exceptions affect it.
复盘Looking back
如果重做，我会怎么改What I'd do differently
- 更早引入真实用户：先只做一个最核心的场景，比如“库存不足时怎么定补货计划”，做出最小可用版本，再根据反馈扩展其他模块，而不是先把功能做全。Bring in real users earlier: start with one core scenario, such as planning replenishment when stock runs short, ship a minimum usable version, then expand based on feedback instead of building everything first.
- 验证“有没有用”，而不只是“算没算对”：看用户能不能快速看懂建议、据此完成决策，以及系统是否真的减少了重复分析的工作量。Validate usefulness, not just correctness: can users understand a suggestion quickly, make a decision with it, and does the system actually cut repetitive analysis?
左右滑动 · 点击放大 · Swipe · tap to zoom · 驾驶舱 · 数据看板 · 单 SKU 计算追溯（演示数据）Cockpit · dashboard · per-SKU calculation trace (demo data)
