先说钱的事：一个仓库 BI 看板，值多少钱？
一家 2 万平的仓库，日均出货 8000 单，去年花了 60 多万上了 WMS，又花 20 多万上了 OMS。老板早上问运营总监："这周赚钱了吗？"对方回答："还行，比上周好一点。"老板问："好多少？哪个环节挣的？钱漏在哪了？"——没人答得上来。缺的不是系统，是一个仓库 BI 看板：数据全在系统里躺着，老板看经营还是靠周五晚上加班拼的 Excel 周报，数字还对不上。
仓库 BI 看板要解决的，就是这件事：每天到底看哪几个数，每个数从哪来。
我不谈"数字化愿景"，只算两笔账。第一笔：一个没有看板的仓库，老板每个月至少做 3 次拍脑袋决策——补不补人、降不降价、接不接这个客户的单子。每次拍错的代价，往少了说也是几万块。第二笔：上 BI 的钱，一年摊下来有没有超过它省下的决策损失？两笔算完，看板上不上，一目了然。
仓库 BI 看板上的 8 个数，少一个都看不清经营
我给老板们的看板只留 8 个数，多的全是干扰。这 8 个数每一家都测得出，口径统一，不用争论。
| # | 指标 | 口径（一句话说清） | 健康线 |
|---|---|---|---|
| 1 | 库存准确率 | 盘点账面一致的 SKU 数 ÷ 盘点 SKU 总数 | ≥99.5% |
| 2 | 订单准时出库率 | 承诺截单时间前发出的订单 ÷ 总订单 | ≥98% |
| 3 | 人效 UPH | 出库单量 ÷ 一线工时（拣/复核/打包） | 因行业而异 |
| 4 | 单位履约成本 | 当月履约总费用 ÷ 当月出库单量 | 同比下降 |
| 5 | 库位利用率 | 已占库位数 ÷ 可用库位总数 | 75%～85% |
| 6 | 退货率 | 退货单量 ÷ 出库单量 | 电商 <8% |
| 7 | 加班占比 | 加班工时 ÷ 总工时 | <10% |
| 8 | 呆滞库存金额 | 90 天无动销的库存成本金额 | 同比下降 |
为什么是这 8 个？库存准确率是根——账实不符，别的数全是假的，我见过一家仓库存准确率 97%，每月差异 40 多万货款对不上，别的指标看得再漂亮都是自我安慰。订单准时率直接挂着客户赔付，晚发一天，快递加急费、平台罚款、客户流失，账全在这。UPH 和加班占比是一对，UPH 下降、加班上升，说明人力结构出了问题，不解决下个月工资单就给你颜色看。单位履约成本是老板的底线数，别的都是它的分解。库位利用率和呆滞库存金额是一对——库位利用率上 90%，你不该再租仓了，该清的是呆滞货。
反常识的判断来了：很多老板以为 BI 看板解决的是"看不见"，实际解决的是"没法争"。 以前仓库和销售掐架，销售说"你们发货太慢"，仓库说"你们单子进来太晚"，两边各拿一版 Excel。看板上线后，准时率掉的那天，看板上直接标出截单后进来的单子占比 41%——架不用吵了，数字摆着。
仓库 BI 看板的数据源：别让看板变成手工 Excel 的精装版
数据源是看板成败的全部。我见过最可笑的"BI 看板"：开发花两周做了个漂亮界面，数据每周一从 WMS 导出 Excel、人工填进去——这不叫看板，这叫周报换了个皮肤。
8 个数的数据源，实打实是这样：
| 指标 | 主数据源 | 口径里的"账面"到底指哪张表 |
|---|---|---|
| 库存准确率 | WMS（盘点单+库存台账） | 盘点差异 = 系统库存 - 实盘数，按 SKU 汇总 |
| 订单准时出库率 | OMS（订单+承诺时效）或 WMS（出库时间戳） | 以 OMS 承诺截单时间为准，别用 WMS 内部时间 |
| 人效 UPH | WMS（任务完成时间戳）+ 考勤系统（上岗工时） | 分母是一线作业工时，管理岗剔除 |
| 单位履约成本 | 财务（工资/耗材/快递账单）+ WMS（单量） | 分子是真金白银的费用，不是预算数 |
| 库位利用率 | WMS（库位主数据+占用状态） | "可用"要扣掉坏库位、预留库位 |
| 退货率 | OMS（退货单）或 WMS（退货收货） | 口径选一个，两边都要对上 |
| 加班占比 | 考勤系统（打卡/排班） | 以考勤为准，别听主管报的 |
| 呆滞库存金额 | WMS（库存+批次入库日期）+ 财务（成本价） | 90 天无动销 × 移动平均成本 |
这里有个坑，九成仓库会踩：同一个数，不同系统口径不一样。 订单准时率，OMS 按"承诺时间"算，WMS 按"复核完成时间"算，差出来的 2～3 个点够两边吵一个月。看板上线第一件事不是开发，是定口径：8 个数，每个数写一句话定义，数据源指到具体系统具体表，签字画押。
数据源还决定了看板能不能"每天看"。库存准确率这种盘点数，一周才有一次，就别硬塞进日看板——日看板放 6 个能日更的数，库存准确率和呆滞库存金额放周看板。看板不是指标越多越好，是更新频率和指标口径要对得上。
自建看板 vs 买 BI 工具：这笔账我帮你算到小数点
这是老板们问得最多的问题。两种路线的成本结构完全不一样，我直接摆出来。
场景设定：一家日均 8000 单的仓库，8 个指标，日更 6 个、周更 2 个。
| 成本项 | 自建看板（内部开发/外包一次性） | 买 BI 工具（年订阅） |
|---|---|---|
| 首年投入 | 8～15 万（开发+联调） | 3～8 万/年（license+实施） |
| 次年及以后 | 1～2 万/年（维护） | 3～8 万/年（续费） |
| 数据源打通 | WMS/OMS/考勤/财务接口一个个对，人力成本高 | 多数 BI 工具要配 ETL 或中间库，实施费另算 |
| 口径变更成本 | 改一行 SQL 的事 | 改报表+改 ETL，有时要加钱 |
| 三年总拥有成本 | 约 12～19 万 | 约 9～24 万 |
| 最大的坑 | 开发离职，没人维护 | 数据源一换，报表全废 |
这笔账的结论：单仓、日单量 1 万以内、8 个指标这个量级，自建更划算。 一个懂 SQL 的数据岗，两周能把看板搭起来，三年省下至少大几万。但有两个例外买 BI 工具更合适：第一，多仓、多组织，要权限、要下钻、要移动端，BI 工具的现成功能值回票价；第二，没有数据岗，老板自己就是最大的数据工程师——那就别自建，买工具，把人力成本省下来。
还有个 trade-off 很多人没想到：看板最大的成本不是开发费，是口径扯皮的时间。 我见过一家仓，BI 工具买了半年没上线，不是因为技术，是因为财务和运营对"单位履约成本"的分子吵了三个月——快递费摊不摊、退货成本算不算、管理人员工资进不进。工具选型会议开了 5 次，口径会议开了 11 次。所以不管自建还是买，先定口径，再谈工具，顺序反了就是烧钱。
落地清单：四周上线，别搞成半年项目
看板项目最容易犯的病是做成"数字化大工程"。我给你一个四周落地的节奏，超过这个节奏的，十有八九是方向错了。
第一周：定口径。8 个数一句话定义，数据源指到表，财务、运营、IT 三方签字。这一步没签字，后面全白干。
第二周：打通数据源。日更的 6 个数先跑通，写定时任务，每天凌晨 3 点跑批。别一上来就搞实时——日更对经营决策完全够用，实时看板多花的钱，九成是浪费。
第三周：做界面。一个页面，8 个数，红绿灯。别做下钻、别做多维分析、别做预测——先让老板每天早上 8 点打开手机能看到 8 个数，这就是成功。
第四周：跑两周，修口径。数字对不上的地方，一定是口径问题，不是技术问题。修完，正式发布。
最后算总账：一个能用的仓库 BI 看板，首年投入 8～15 万（自建）或 3～8 万（买工具），上线后每月至少省下 2～3 次拍脑袋决策。 按一次拍错决策损失 3 万算，一年 36 次，省下来的钱是投入的 10 倍以上。这笔账，值。
作者：老周｜物流成本分析师
