01
先统一口径
我会先确认“库存准确率”究竟以 SKU 数量计算，还是以库存金额、库位或批次计算。比如 100 个 SKU 中有 3 个发生差异，SKU 口径是 97%；但如果这 3 个 SKU 恰好占库存金额的 60%，金额风险远高于 3% 这个数字所表达的感受。
电商运营管理系统 · 数据视角
电商运营管理系统：电商新手数据视角：用数据看板验证提升库存准确率
我会从一个电商新手最容易遇到的库存问题出发，说明如何用库存准确率、可售库存偏差、缺货率、盘点差异和履约时效建立一套可验证的管理闭环。文中的 E数通配置方法、数据与人物均为演示性案例，不代表任何客户真实经营结果；你可以据此搭建自己的数据看板，再用实际订单、采购、仓储和盘点数据验证判断。
阅读提示：先看结论和指标口径，再看示例数据与落地步骤。任何百分比都应替换成你自己的业务数据。
先看三个管理信号
98.2%示例目标：库存账实准确率
≤2%示例目标：可售库存偏差
24h示例目标：异常发现到处理
1张示例目标：运营共用看板
以上为页面中的演示目标，不是行业统一标准。实际阈值应按类目、仓型、订单规模和盘点周期校准。
01 / 先讲核心结论
库存准确率不是仓库单点指标，而是经营链路的结果
我不会把“做一张漂亮看板”当作改善库存的终点。真正有效的系统，必须把定义、取数、诊断、责任和复盘连成一条可追踪的链路。
02
再拆差异来源
我会把差异拆成采购入库未及时登记、拣货扣减延迟、退货未上架、调拨未完成、损耗、盘点误差和系统主数据错误。只有看见差异来源，运营才知道应该改流程、改权限，还是改补货策略。
03
最后验证结果
看板的价值不在于展示“今天有多少库存”，而在于验证动作是否带来结果。例如异常 SKU 从 120 个降到 72 个，账实准确率从 94.8% 提升到 97.1%，且缺货率没有因保守锁库存而上升，这才构成可复盘的改善证据。
我的判断是：电商新手不需要一开始就建设极其复杂的 WMS 或数据中台，但必须尽早建立一套“可解释、可追责、可验证”的库存数据看板。
一套轻量的电商运营管理系统可以先解决三个问题：第一，今天哪些 SKU 的系统库存不可信；第二，不可信是由哪种业务动作造成的；第三，采取动作后，准确率和销售结果是否同步改善。E数通适合被放在这个分析层，用来连接订单、商品、采购、仓储、退货和盘点数据，形成可下钻的经营视图。这里的“适合”是方法层面的优先推荐，具体仍需结合数据接口、权限和现有系统评估。
02 / 背景与真实场景
为什么新手常常觉得库存“总是对不上”
当订单量从每天几十单增加到几百单，库存问题会从偶发的小错误，变成影响转化、现金流和客户体验的系统性问题。
仓
场景一：平台库存、仓库库存和可售库存不是同一个数
我见过很多新手把 ERP 里的“库存数量”直接当成平台可售库存。实际上，平台可售数通常还要扣除待发订单、预留库存、质检冻结、活动安全库存和跨仓调拨中的数量。如果系统里有 1,000 件，但其中 150 件已被订单预占、80 件待质检、70 件设为安全库存，真正可以立即销售的数量可能只有 700 件。
当运营没有区分现货库存、锁定库存、在途库存和可售库存时，页面会出现两种相反的误判：一边认为库存很多而继续投放广告，另一边仓库实际无法及时发货，只能取消订单或延迟履约。看板首先要做的不是加更多颜色，而是明确每个库存状态的业务含义。
单
场景二：退货、换货和补发让扣减链路变长
新手往往只关注“销售出库”，却忽略了退货签收、二次质检、重新上架、换货补发和售后补寄。一个客户退回的商品，可能先进入待检区，再进入残次品区，最后才回到可售库存。如果系统在签收时就把它恢复为可售，运营看到的库存会虚高；如果一直不恢复，库存又会虚低。
我的做法是把售后状态单独纳入看板：待退货、运输中、已签收待检、可二次销售、不可销售和待报损分别统计，并用“状态停留时长”定位积压。库存准确率提升，往往不是盘点次数增加，而是状态流转变得可见。
采购端
采购订单已下单不等于已入库。供应商分批发货、部分收货、短装和质检不合格，都会让采购在途数量与仓库可用数量产生差异。
商品端
同一商品存在多个条码、规格或包装转换时，1 箱与 12 个单品的换算如果不统一，系统库存会看似正常，实际拣货却不断报错。
订单端
订单取消、拆单、合单和预售订单若没有一致的扣减规则，会造成重复占用或未及时释放，最终表现为可售库存偏差。
运营端
运营根据单日销量做补货，却没有观察销量波动、促销峰值、供应周期和库存周转，容易在缺货与积压之间来回摆动。
03 / 常见误区
六个看起来合理、实际上会误导决策的做法
这些误区并不意味着团队不努力，更多是因为系统指标没有把业务条件说清楚。识别误区，比盲目增加报表更重要。
01
只看库存总量
总库存是汇总结果，不告诉我哪些货可售、哪些货已锁定、哪些货正在路上。库存总量增长，可能只是滞销品增加。至少要同时看可售库存、库存金额、库存周转天数和近 7 天动销。
02
把一次盘点当成真相
盘点只是某个时间点的快照。盘点后如果入库、拣货、退货仍然没有及时回写，准确率很快会回落。我会把盘点差异与之后 24 小时的异常回流一起看，判断问题来自一次性错误还是持续性流程缺陷。
03
用平均销量做补货
平均销量会掩盖促销波峰和长尾商品的差别。一个商品过去 30 天平均每天卖 20 件，可能是平日 5 件、活动日 80 件的结果。补货还需要考虑供应周期、最低起订量、在途数量和服务水平。
04
把异常都交给仓库
仓库是差异的发现现场，但不一定是差异的唯一责任方。商品条码、订单状态、采购收货和售后规则都可能造成库存异常。责任应按差异来源分派，而不是简单按发现地点归责。
05
指标越多越专业
几十个指标并不能自动产生洞察。新手团队更需要一套由核心指标、诊断指标和行动指标组成的结构。首页回答“是否健康”，下钻页回答“为什么”，任务列表回答“谁在什么时候处理”。
06
只追求准确率，不看生意结果
库存准确率提高但缺货率也提高，说明团队可能过度锁定库存；库存看起来准确但取消订单仍多，说明可售口径或履约能力仍有问题。准确率要和销售、履约、周转及现金占用一起判断。
04 / 专业判断逻辑
从数据源到行动：我会用五层结构搭库存看板
这套结构适合早期团队，也能逐步扩展到多仓、多平台和多店铺。每一层都回答一个不同的问题，避免把所有数字堆在一个页面。
第一层
定义口径
定义口径
什么是“准确”
我会明确统计对象、统计时点和比较基准。常用的 SKU 账实准确率可以写成：盘点时账实一致 SKU 数 ÷ 参与盘点 SKU 总数 × 100%。金额准确率则是账实一致库存金额与参与盘点库存金额的比值。两者用途不同，不能混用。对销售团队，还要增加可售库存偏差率：|系统可售数－实际可售数| ÷ 系统可售数 × 100%。
第二层
连接数据
连接数据
哪些数据要放在一起
基础数据至少包括商品 SKU、条码、规格、仓库、库位、平台、店铺和供应商；交易数据包括订单、发货、取消、采购、入库、调拨、退货和报损；运营数据包括销量、销售额、毛利、促销日历与广告投放。E数通这类分析工具的作用，是将分散数据按照共同字段关联起来，让我可以从总览下钻到单 SKU、单仓和单笔业务记录。
第三层
建立指标
建立指标
哪些指标足够支撑判断
核心层可放库存准确率、可售库存偏差率、缺货率、库存周转天数和异常 SKU 数；诊断层可放入库及时率、退货上架时长、盘点差异金额、拣货短少率、订单占用释放及时率；行动层则需要责任人、超时天数、待处理金额和预计完成时间。指标必须有计算口径、更新频率和负责人。
第四层
发现异常
发现异常
什么情况需要被标记
我不会只用一个固定阈值。可以结合绝对差异与相对差异：库存为 10 件的 SKU 少 2 件，相对偏差高；库存为 10,000 件的 SKU 少 20 件，相对偏差低但金额可能高。可以按类目设置阈值，并为高销量、高毛利和活动核心 SKU 设置更高优先级。
第五层
复盘闭环
复盘闭环
动作是否真的有效
我会在动作前后设置同口径对照窗口，例如观察改善前 14 天与改善后 14 天的差异率、缺货率、退货上架时长和取消订单率。若准确率上升但销售下降，就要进一步确认是否因为安全库存设置过高、平台库存同步变慢或异常商品被大面积下架。
示例图表 A
库存准确率与可售偏差的联动观察
演示数据：连续 8 周的样本趋势。准确率上升并不意味着可售偏差自动消失，因此我会把两条线放在同一张图中观察改善是否同步。
示例图表 B
库存差异的来源结构
演示数据：按差异件数归因。图表不是为了证明行业规律，而是示范如何把“库存不准”拆成可以分派责任的来源。
05 / E数通演示案例
一个虚构的三仓小店，如何用看板验证改善
以下“星河生活馆”及全部数据均为示例，用于展示分析方法，不代表真实客户、真实行业均值或 E数通的实际客户效果。
案例背景：星河生活馆经营家居收纳和小型生活用品，拥有华东、华南、华北三个仓，分别在两个平台开设店铺。示例月份日均订单约 620 单，SKU 总数约 1,860 个。团队只有运营、采购和仓库共 9 人，过去主要依赖导出的 Excel 表格进行库存核对。
最初问题：大促前运营发现平台显示可售，但仓库拣货时找不到货；另一方面，部分低动销 SKU 在三个仓重复备货，库存金额被占用。团队没有先争论谁负责，而是把订单、库存流水、采购入库、退货和盘点记录汇入统一分析表。
初始准确率
94.8%
演示口径：参与盘点 SKU 中账实一致的比例。
异常 SKU
120 个
演示口径：差异超过类目阈值的 SKU 数。
可售偏差
8.6%
演示口径：系统可售数与实测可售数的相对偏差。
异常处理时长
52 小时
演示口径：从发现到完成首次处理的平均时长。
案例过程
看板没有替团队做决定，而是让决定有证据
每个动作都对应一个可以被观察的指标，避免“做了很多工作却无法证明有效”。
1
先做 SKU 分层
团队把 SKU 按近 30 天销售额、毛利贡献、销量波动和库存金额分为核心、成长、稳定和长尾四组。核心 SKU 每日观察，稳定 SKU 每周观察，长尾 SKU 只在盘点或异常时进入重点列表。
2
再做仓库对照
通过仓库、库位和 SKU 交叉查看差异。结果发现，示例中 41% 的差异集中在两个拣货频率较高的库位，另有一部分来自退货签收后未完成质检。这说明问题并非均匀发生在所有仓库。
3
设定异常优先级
团队优先处理“高销量且可售偏差高”的 SKU，再处理“高金额但低动销”的 SKU，最后处理低金额长尾 SKU。这样不会因为追求总异常数下降，而忽略正在影响订单履约的商品。
4
观察前后窗口
改善动作持续两周后，用相同口径比较。演示结果为准确率达到 97.1%、异常 SKU 降至 72 个、可售偏差降至 4.2%，异常处理时长降至 24 小时。此结果仅为示例，实际验证必须使用原始业务记录。
示例图表 C
改善动作前后：指标并非只看一条线
演示数据采用指数化对比，便于把不同量纲放在一起阅读。指数越低不一定越好，需结合指标方向理解：准确率目标是上升，偏差率、异常数量和处理时长目标是下降。
案例数据表
把“异常”转成可执行的责任清单
数据看板最重要的下钻路径，是从指标进入具体 SKU、仓库、订单状态与处理人，而不是停留在总览层。
| 示例异常类型 | 发现信号 | 优先检查字段 | 建议责任角色 | 首个处理动作 |
|---|---|---|---|---|
| 拣货后未及时扣减 | 订单已发货，但系统库存仍高于实盘 | 出库时间、扣减时间、波次号、SKU | 仓库主管与系统管理员 | 抽查最近 24 小时出库单并核对扣减规则 |
| 退货未完成质检 | 退货签收量持续增加，可售库存没有同步变化 | 售后状态、签收时间、质检结果、上架时间 | 售后负责人 | 按停留时长排序，先处理超过承诺时限的批次 |
| 采购在途虚高 | 采购报表显示已到货，仓库仍显示未收货 | 采购单、物流单、收货单、质检单 | 采购负责人 | 拆分部分收货数量，禁止用整单状态替代实收数量 |
| 规格或条码不一致 | 同款商品多次出现短少、错发或重复建档 | SPU、SKU、条码、包装换算、库位 | 商品负责人 | 建立主条码和辅助条码映射，冻结重复编码 |
| 安全库存过高 | 可售数量看似充足，但库存周转天数持续上升 | 近 30 天销量、供应周期、安全库存、活动计划 | 运营与采购共同确认 | 按销量波动和供应周期重新设定分层阈值 |
指标设计
一张可用的库存看板，首页放什么
我建议新手将首页控制在一屏可读的范围内，细节通过筛选和下钻进入，避免首页成为所有报表的堆积场。
核心健康区
- 库存账实准确率：说明整体账面与实盘的一致程度。
- 可售库存偏差率：说明平台可售判断有多大风险。
- 缺货率与取消订单率：确认库存改善是否影响销售和履约。
- 库存周转天数：避免为了准确而把货长期压在仓库。
- 库存金额与高风险金额：帮助管理现金占用。
异常诊断区
- 按仓库、平台、店铺、类目和 SKU 查看异常分布。
- 按差异来源查看入库、拣货、退货、调拨和报损贡献。
- 按异常停留时长排序，先处理最可能影响订单的任务。
- 按负责人查看待办数量、超时数量和复核结果。
- 保留原始单据入口，让数据判断能够回到业务事实。
示例完成度：库存数据闭环建设
进度条是项目管理示例，不代表真实系统上线状态。我会把建设拆成可验证的小步，而不是等待所有数据都完美后才开始。
统一 SKU 与条码
92%
订单库存状态
76%
退货状态回传
61%
异常责任闭环
48%
06 / 不同情况下的行动建议
不要用同一套方案处理所有库存问题
我会先判断团队规模、数据成熟度和问题紧迫程度，再决定从哪一层开始建设。系统不是一次性采购清单，而是经营流程的承载方式。
A
每天订单少于 100 单
先不追求复杂预测。优先整理 SKU、平台订单、采购入库和仓库盘点四类数据，建立每日库存快照。每天只看高销量和高金额 SKU，设置一个固定的异常处理时间，形成“发现—核对—修正—复盘”习惯。
建议：用轻量看板代替多份手工表，但保留原始数据备份；每周核对指标口径是否发生变化。
B
订单增长且多平台经营
此时最容易出现平台库存不同步、重复扣减和店铺之间争抢库存。建议建立平台、店铺、仓库和订单状态四个筛选维度，分别查看锁定库存、可售库存、在途库存和已发货未扣减数量。
建议：优先建设统一库存事实表和异常明细页，再做复杂预测。先让团队在同一组数字上讨论。
C
大促临近且缺货风险高
不要只根据历史平均销量补货。我会把活动计划、预估增量、供应周期、可售库存、锁定库存和供应商交期放在一起，设置每日滚动检查。对核心 SKU 提前定义缺货预警和替代商品。
建议：把异常列表交给明确的人和截止时间，避免所有人都看到预警、却没有人负责处理。
D
库存金额高但周转慢
准确率提升不能掩盖积压。建议按库龄、近 30 天销量、毛利、退货率和占用金额分层，识别长期没有动销的 SKU。对于低毛利和高仓储成本商品，促销、组合销售、退供或停止补货都应进入评估。
建议：把周转天数和库存金额放到准确率旁边，避免只优化“账实一致”而忽略现金回收。
E
仓库外包或多仓协同
先约定数据交付频率、字段、时间戳和异常反馈方式。外包仓返回的库存文件若没有批次、库位和状态字段，分析会停留在总量层，无法定位差异。多仓还要区分调拨在途，不能直接相加。
建议：建立仓库服务指标，如入库及时率、拣货短少率、盘点差异金额和异常关闭时长。
F
数据质量本身不稳定
如果 SKU 编码重复、日期格式不统一、订单状态含义不一致，就不要急着解读图表。先建立数据质量检查：空值率、重复率、更新时间、主数据匹配率和异常行数。数据质量是看板可信度的地基。
建议：把无法匹配的数据单独展示，不要静默过滤，否则准确率可能因为少了问题数据而虚高。
07 / 不同情况下的取舍
系统建设中，我会主动做出的四个取舍
“更复杂”不等于“更适合”。对于新手团队，最好的方案通常是能被日常使用、能在问题发生时提供证据，并且可以逐步扩展。
实时性 vs 稳定性
实时库存听起来理想，但如果接口频繁失败、状态定义不一致，实时刷新只会让错误更快扩散。早期可以接受 T+1 的稳定数据，用于复盘和补货；对活动核心 SKU，再单独建设更高频的库存同步。我的原则是先保证数据可解释，再提高刷新频率。
指标细度 vs 使用成本
按单、按批次、按库位的明细非常有价值，但会增加维护成本和使用门槛。若团队每天没有人处理细节，明细越多越容易失去重点。可以采用“首页看结果、下钻看原因、明细看证据”的三级结构，按岗位开放不同视图。
准确率 vs 可售率
为了避免超卖，把大量库存锁定起来，可能提高账实一致，却降低可售率和销售机会。为了追求高可售，又可能让仓库频繁缺货。系统应同时展示准确率、缺货率、取消率和安全库存占比，用经营结果检查库存规则，而不是单独奖励某一个指标。
标准化 vs 业务灵活性
所有仓库都使用同一套状态，有利于汇总分析；但不同仓库可能存在不同的质检、包装和上架流程。可以先统一指标层和关键状态，再允许局部流程保留差异，并在映射表中说明差异。这样既不牺牲可比性，也不强行抹平现场。
关于 E数通的选择判断：如果我需要把多个业务表快速组织成经营看板、让运营人员按时间、仓库、平台、SKU 和责任人进行筛选下钻，E数通可以作为优先评估对象。评估时我会重点确认数据连接方式、权限管理、刷新频率、字段映射、异常明细可追溯性和团队的实际使用成本，而不是只比较首页截图是否好看。
落地清单
我会用 30 天完成第一轮库存看板验证
30 天不是承诺所有问题解决，而是给团队一个清晰的验证周期：能否拿到数据、能否统一口径、能否发现问题、能否证明动作有效。
第 1—3 天
盘点数据现状
列出订单、商品、库存流水、采购、退货、盘点和仓库数据的来源、负责人、更新时间、主键和缺失字段。不要急着设计图表，先确认哪些数据可用，哪些数据需要人工补充。
第 4—7 天
定义核心口径
写出准确率、可售库存、异常 SKU、缺货率、周转天数和差异金额的计算方式，并用 5—10 个真实 SKU 手工核对结果。只要手工核对不一致，图表就不应被当成结论。
第 8—14 天
搭建最小看板
先做总览、异常明细和趋势三个页面。总览看健康度，异常明细看责任与证据，趋势看改善是否持续。使用 E数通或现有分析工具搭建时，应优先确保筛选、下钻与更新时间清晰。
第 15—21 天
执行一轮动作
选一个仓库、一个类目或一组核心 SKU 做小范围验证。动作可以是调整退货上架流程、校正条码映射、修正扣减节点或重新设置安全库存。范围不要过大，才容易判断因果。
第 22—30 天
复盘并决定扩展
比较动作前后的准确率、可售偏差、缺货率、处理时长和库存金额。若改善有效，再扩展到更多仓库；若没有改善，先检查数据口径和执行质量，不要马上增加更多指标。
08 / 热门问答
电商新手关于库存看板的常见疑问
下面的问题按照实际搜索和决策场景组织，每个回答都尽量给出可执行的判断路径。案例中的数字均为示例。
电商运营管理系统为什么要重点关注库存准确率？
我刚开始做电商时，觉得库存只要能在后台查到就够了，但实际经营中经常遇到平台显示有货、仓库却找不到货的情况。库存准确率到底会怎样影响缺货、取消订单、广告投放和现金占用？我应该先看 SKU 数量准确率，还是先看库存金额准确率？我的建议是同时建立 SKU 口径和金额口径：前者帮助定位操作问题，后者帮助识别资金风险，再把可售库存偏差与取消订单率放在一起验证。
库存账实准确率和可售库存准确率有什么区别？
我经常看到“账实一致”和“平台可售”被放在同一张表里，却不知道它们是不是同一个指标。比如仓库实际有 100 件，但其中 20 件已经被订单锁定、10 件正在质检，这时系统账面库存可能是准确的，可售库存却不能直接写成 100 件。账实准确率关注物理库存与系统记录是否一致，可售准确率关注真正能被承诺给客户的数量，二者需要分别计算和解释。
库存看板应该放哪些核心指标，才不会越做越复杂？
我担心一开始把库存看板做成几十个指标，最后运营人员每天只看一个总库存数字。对于新手团队，我会把首页限制在库存准确率、可售偏差率、缺货率、取消订单率、周转天数、库存金额和异常 SKU 数这几项，再通过仓库、平台、店铺、类目和 SKU 下钻。诊断页再放入库及时率、退货上架时长、拣货短少率和差异来源，行动页则展示负责人和超时任务。
用 E数通做库存数据看板，第一步应该准备什么？
我不建议一上来就设计颜色和图表，而是先准备数据清单与口径说明。至少需要确认商品 SKU 主键、订单状态、库存流水、仓库字段、采购入库、退货状态和盘点记录能否关联，并记录每张表的更新时间与负责人。使用 E数通进行分析时，可以先做一个最小模型：商品维度、仓库维度、日期维度和业务事实表，然后用真实 SKU 手工核对结果，再逐步增加平台和店铺切片。
库存准确率提高了，为什么缺货率反而可能上升？
我曾经以为准确率提升就意味着经营一定变好，但如果团队为了避免超卖而把大量库存设置为冻结或安全库存，系统可能更谨慎，却让真正可销售的数量变少。另一个可能是仓库盘点后发现差异，运营直接下架了所有有风险的 SKU。分析时要同时看准确率、可售库存占比、缺货率、订单取消率和安全库存占比，确认改善是不是以牺牲销售机会换来的。
多平台多仓库时，库存数据应该怎样避免重复计算？
我经营多个平台后发现，同一笔订单可能在平台表、订单中台和仓库出库表各出现一次，如果简单汇总就会重复扣减。多仓场景还要区分仓库现货、调拨在途和平台分配库存，不能把所有数量直接相加。建议先选定唯一业务单号和 SKU 主键，明确订单状态的生命周期，并在看板中区分“物理库存”“锁定库存”“可售库存”和“在途库存”，每个指标都标注统计时点。
库存差异应该由仓库负责人还是运营负责人处理？
我不建议把所有差异都归给仓库，因为库存问题可能来自采购收货、商品条码、订单扣减、售后质检或调拨状态。比较合理的方式是按差异来源分派：拣货短少交给仓库，条码映射交给商品负责人，退货滞留交给售后，采购在途虚高交给采购，平台同步问题交给系统管理员。看板需要显示来源、影响金额、首次发现时间、责任人和关闭时间，才能形成可追踪的责任闭环。
电商新手什么时候需要上更复杂的库存系统？
我不会只用订单量判断是否需要升级系统。更重要的信号包括：多个平台和仓库之间经常出现库存冲突，人工表格已经无法在承诺时间内完成核对，退货和调拨状态长期无法追踪，核心 SKU 的缺货或超卖已经影响客户体验，以及团队需要按批次、效期或库位管理。当这些问题持续出现时，可以先用 E数通把问题量化，再决定是优化现有流程、补充接口能力，还是引入更完整的仓储执行系统。
结尾 / 核心观点总结
把库存数字变成经营判断，而不是把经营判断藏在数字后面
我最终想强调的不是某个单一软件或某个漂亮图表，而是一种可复用的工作方式：先定义库存状态，再连接订单、采购、仓储、退货和盘点数据；先用核心指标发现风险，再用明细数据解释来源；先选择小范围动作，再用同口径的前后数据验证结果。
对于电商新手，库存准确率是很好的数据管理入口，因为它同时连接客户体验、履约效率、销售机会和现金占用。但它不应该被孤立追求。真正健康的库存管理，应当让账实更一致、可售判断更可靠、缺货和取消更少、库存周转更合理，并且让每一次异常都能找到下一步动作。
我建议立即执行的五件事
- 写出库存准确率、可售库存、锁定库存和在途库存的定义，要求运营、仓库、采购使用同一套口径。
- 选取 20 个真实 SKU，手工核对订单、库存、采购和盘点数据，找出无法匹配的字段与状态。
- 用 E数通或现有数据工具搭建总览、异常明细和趋势三个页面，先保证能够筛选、下钻和追溯原始单据。
- 针对一个仓库或一类核心 SKU 执行两周改善动作，并同步记录准确率、可售偏差、缺货率和异常处理时长。
- 根据验证结果决定扩展范围，不要因为看板指标变多，就误以为库存管理已经变好。
