2024年11月的一个周一早会，我在一家年销四千多万的跨境卖家会议室里，亲眼看四个部门用同一个词吵了四十分钟。运营说某款爆款可售312件，仓库说实物只有189件，采购说还有400件在途但没入系统，财务说这个SKU的库存金额和上月报表差了23万。四个人说的都是"库存"，但四个人指的是四件事。那一刻我意识到，库存不是一个仓库数据，它是团队协同的显影液，所有没对齐的口径、没闭环的责任、没兑现的承诺，都会在库存这个数字上现出原形。

这篇复盘来自我2024年Q3到2025年Q3跟进的三个跨境团队，SKU规模从300到6000多不等，平台覆盖亚马逊、Shopee、TikTok Shop、独立站。我用库存管理当切口，去验证一件事：ERP到底能不能验证团队协同效果？如果能，它验证的是功能，还是管理？结论比我预想的更反常识：库存准确率的结构性提升里，真正由系统能力直接贡献的部分不到三成，剩下七成来自口径统一、责任划分和复盘节奏这些"非软件动作"。

ERP不是解药，它是一面不会说谎的镜子。

一、先把核心结论摆出来

在展开细节之前，我把这次复盘最硬的几个判断先放在前面。如果你只读一段，读这一段就够了。

1. 库存对不上，九成不是仓库执行的问题

我把三个团队一年内记录在案的库存差异事件做了归类，总共217起。按根因拆分，仓库现场操作失误只占11.5%，剩下88.5%分散在数据口径、在途归属、退换货处理、主数据错误和跨部门信息不同步上。这个分布和我最初的直觉完全相反，大多数老板第一反应是"仓库管理不行"，但数据告诉他们，仓库只是最后那个背锅的环节，差异在上游就被制造出来了。

更值得注意的是，这217起里有63起在三个月内重复出现，原因完全相同。这说明差异不是能力问题，是机制问题：同一个断点没被修复，它就会周期性地复发。

2. 库存是协同的显影液，因为它无法被单方面伪造

销售额可以靠压货做出来，广告ROI可以靠归因口径调出来，但库存是一个物理约束加一个逻辑约束：货在不在、账对不对。运营想让可售数字好看，仓库想让盘点简单，采购想让在途算成绩，财务想让金额准确，这四个诉求天然冲突。库存数字是这四个诉求博弈后的唯一交点，所以它比任何KPI都更能反映协同真实水平。

我后来把这个逻辑总结成一句话：想看一个跨境团队协同好不好，不用看周报，去看他们能不能在十分钟内对同一个SKU给出一致的可售量。

3. ERP提供的是可追踪性，不是自动正确性

很多团队上线ERP时的隐含期待是"系统会把数据理清楚"。这个期待本身就是误区。ERP能做的是把每笔变动记录下来、把责任落到人头上、把异常暴露出来；它不能替团队决定"在途算不算可售"，也不能替采购承诺到货日期。系统把协同问题从"看不见"变成"看得见"，但解决它仍然要靠人。这也是为什么我反对把ERP项目验收标准定成"功能全部上线"，那只能证明软件交付了，不能证明协同改善了。

二、复盘背景：三个体量不同的团队，三种协同病症

为了让结论有可迁移性，我刻意选了三个业务形态差异很大的团队。它们用的工具、团队规模、平台结构都不同，但库存协同上的病灶高度相似。这种"不同背景、相同病症"的对比，恰恰说明问题不在某个特定工具，而在协同机制。

1. 团队A：精品模式，SKU 300，高客单

团队A做家居类精品，主战场亚马逊美国站加独立站，客单价在80-200美元。SKU只有300来个，但每个SKU的备货周期长达75天，单次采购金额大。他们的库存问题不是数量多，而是资金压在错误的地方：爆款断货，长尾积压，而两边在ERP里看到的库存数据都对，只是没人把"周转天数"和"广告投入"放在一起判断。

他们的协同断点在采购和运营之间。运营看到的是广告还可以继续投，采购看到的是补货来不及。两边都没错，但缺少一个共同的判断时点。

2. 团队B：铺货模式，SKU 6000+，多平台

团队B做泛品类铺货，同时运营亚马逊、Shopee、TikTok Shop和两个独立站，SKU超过6000。他们的核心问题完全不同：数据量大到无法人工对账，但又没建立自动化的口径。财务月底要花6个人天做库存对账，出来的数字和仓库盘点还是差2%-4%。

他们的协同断点是"没有共同语言"。每个平台后台的库存逻辑不同，Shopee有本地仓、亚马逊有FBA，铺货模式下同一个SKU可能分散在五个库存池里，没人说得清总可售量。

3. 团队C：快速扩张，SKU 1400，团队从8人扩到30人

团队C是我认为最有代表性的一家。他们在2024年一年内团队从8人扩到30人，SKU从400涨到1400，销售额翻倍，但库存准确率从原来的85%掉到了68%。这不是管理变差了，而是原有的口头协同方式在规模扩张后失效了。

8个人的时候，运营和采购坐一起，喊一声就对齐了；30个人的时候，跨部门沟通要走流程，原来靠默契维持的口径开始分裂。他们的库存问题，本质是组织扩张速度超过了协同机制的建设速度。

三、五把尺子：用什么指标验证协同，而不是验证仓库

复盘最容易犯的错是"用感觉评价"。要让库存管理真正验证协同，必须先把尺子定下来。我最后收敛到五个指标，它们的共同特点是：单个部门无法独立优化，必须跨部门配合才能改善。

1. 库存准确率：账实一致的基础盘

口径定义为：盘点实物数量与系统可售数量一致的SKU占比，按金额加权。为什么用金额加权而不是数量加权？因为100个配件对不上和10个爆款对不上，业务影响差几十倍。团队C一开始用数量口径，准确率看起来有82%，换金额口径后只有68%，问题立刻暴露。

这个指标的协同意义在于：它同时要求仓库做对操作、运营做对状态维护、采购做对在途录入、财务做对成本映射。任何一个环节掉链子，准确率都会掉，而且无法通过单部门努力补回来。

2. 缺货率与滞销率：一对必须同时看的指标

缺货率定义为：可售库存为0的SKU占在售SKU的比例，按连续断货天数加权。滞销率定义为：超过90天无动销的SKU占库存金额的比例。

这两个指标必须成对看。只压缺货率，团队会本能地多备货，滞销率就上升；只压滞销率，团队会本能地少备货，缺货率就上升。我在团队A就看到过这个反复：第一季度冲缺货率，把滞销率从14%推到22%；第二季度清库存，缺货率又反弹。真正有效的做法是找这两个指标的平衡点，而不是各自最优。

3. 库存周转天数：资金效率的直接映射

口径为：平均库存金额除以日均销货成本。跨境和国内电商最大的差别是海运周期，团队A的备货周期75天，意味着他们的周转天数天然比国内同行高，直接对比没有意义，只能自己和自己比趋势。

这个指标的协同价值在于，它是采购节奏、运营动销、财务资金三方共同作用的结果。周转天数变差，可能是采购下多了，也可能是运营卖慢了，还可能是财务为了账期提前备货，必须一起看才能归因。

4. 补货及时率：协同承诺的兑现度

定义为：在计划到货日前3天内完成入库的补货单占比。这是我个人认为最能反映协同的指标，因为它直接衡量"跨部门承诺有没有兑现"。运营预测销量、采购下单、货代运输、仓库收货，四个环节任何一个延误，及时率就掉。

团队C上线ERP前，补货及时率只有54%，而且没有人知道是谁延误的，因为整个链条没有节点记录。这是最典型的协同黑箱。

5. 异常闭环时长：从发现到解决的中位时间

定义为：库存异常从被标记到状态关闭的中位小时数，异常包括账实不符、在途超期、退换货未回写等。这个指标不衡量"有多少异常"，而衡量"异常能不能被处理掉"。团队B的异常数量不少，但闭环时长短，说明他们的机制是健康的；团队C异常数量中等，闭环时长却有11天，说明异常在系统里躺着没人管。

这张表的最后一列是我刻意加的。如果一个库存指标能被单个部门优化，它就不适合用来验证协同，只适合用来考核那个部门。五个指标全部跨部门，这才是它们作为"协同尺子"的资格。

四、上线前的协同断点：我们到底在吵什么

把指标定下来之后，三个团队花了两周时间，把过去半年的跨部门冲突记录翻出来做归类。这个过程很不舒服，但非常有价值。归纳下来，断点集中在四个地方。

1. 数据口径不统一：同一个SKU，三个可售量

这是最高频的断点。运营算可售，习惯用"平台后台显示可售"；采购算可售，习惯用"在库+在途"；仓储算可售，习惯用"实物能发的数量"。三个口径本身都合理，放在一起就是灾难。

团队C的一次典型冲突：某SKU平台显示可售142件，仓库说实物只有89件，差53件。查下来是有一批退货正在海外仓质检，平台已经释放为可售，但仓库还没上架。这批货既"存在"又"不可发"，谁的账都没错，但没人定义它该归谁管。

口径问题最隐蔽的地方在于，它不会报错，只会让每个部门都觉得对方在说谎。

2. 补货靠经验：预测与到货之间没有闭环

团队A的采购负责人跟我说过一句话："我不是不想用数据，是数据出来的时候已经过时了。"他们的补货决策原来基于一张手工维护的销量预测表，旺季一周一更新，淡季两周一更新。等到采购看到预测、下完单、货到仓，市场情况可能已经变了。

更麻烦的是，补货决策没有记录。三个月后复盘"为什么这批货积压了"，没人能还原当时的判断依据。没有决策记录的补货，等于没有复盘价值。

3. 异常无人闭环：异常在系统里躺着

上线ERP之前，团队C的异常处理靠微信群。发现库存差异，在群里@一下相关人，然后就没有然后了。我统计过他们一个月的库存异常消息，超过40%的异常在群里发过一次之后再也没有下文。

这不是态度问题，是机制问题：没有责任人、没有截止时间、没有关闭状态的异常，本质上只是一个通知，不是任务。

4. 周会各说各话：同一SKU，两种结论

最典型的场景是周会。运营拿着平台后台数据说这个SKU库存健康，采购拿着自己的表说这个SKU要立刻补货，双方都不觉得自己错，因为数据源不同。当两个部门用不同数据源讨论同一个问题时，讨论的其实是两个问题。

这种会议开得越多，团队越疲惫，因为每次都在重复认知对齐，而不是解决问题。

五、常见误区：这五个坑我们全踩过

把断点理清之后，我把三个团队在上线ERP过程中踩过的坑做了横向汇总。这些误区有很强的普遍性，而且很多是把ERP当项目、而不是当管理变革来做的结果。

1. 把ERP当成数据自动清洗机

这是最普遍也最昂贵的误区。团队B上线时，管理层期待的是"系统上线后数据自动就干净了"。事实是，ERP只会把脏数据更快地同步到所有地方。数据治理是上线前的动作，不是上线后的结果。

团队B为此多花了两个月做数据清洗，那两个月里系统是"半可信"状态，团队一边用一边怀疑，反而加重了不信任。

2. 指标越多越好：十几个看板，没人负责

团队C上线时一口气配了17个库存相关看板。三个月后我回访，日常真正被使用的只有3个。指标过多的直接后果是责任稀释，每个指标看起来都有人看，实际上没有任何一个指标能绑定到具体责任人。

后来我们砍到5个核心指标，每个指标明确一个Owner，改善反而明显了。

3. 上线即验收：把功能交付当成协同达成

这是我见过最普遍的验收错位。项目组把"订单、采购、库存、财务模块全部上线"作为验收标准，然后宣布项目成功。但库存准确率、补货及时率这些协同指标，在上线当天不会有任何变化，甚至可能因为流程调整短暂变差。ERP项目的验收标准应该是协同指标，而不是功能清单。

4. 只在仓库侧考核：把协同问题单点化

因为库存差异最后暴露在仓库，很多团队本能地把准确率指标挂在仓储KPI上。这带来的后果是仓储为了保住数字，倾向于"少记录、晚报差异"，问题被藏起来而不是被解决。团队C一度出现盘点差异被延后上报的情况，这就是单点考核的副作用。

5. 用ERP替代管理动作：系统上线，流程照旧

团队A最初上线ERP时，采购流程、补货审批、异常处理全都沿用旧习惯，只是把Excel换成了系统录入。结果是"上线的是一套软件，运行的还是一片孤岛"。系统里的数据全了，但决策方式和从前一模一样。

六、专业判断逻辑：库存协同的四层归因模型

踩完坑之后，我逐渐收敛出一套归因逻辑。当库存指标出问题时，我会按四个层次自上而下排查，而不是直接跳到"哪个功能没配好"。这个顺序很关键，因为它决定了你会把资源投在哪个层次。

1. 第一层是主数据层：字段和口径是否唯一

先问三个问题：SKU编码是否全局唯一？组合装和变体是否有明确的父子关系？"可售库存"是否只有一个口径定义？如果这三条不成立，后面所有优化都是空中楼阁。

团队C在梳理主数据时发现，同一个产品在亚马逊、独立站和内部表格里存在三套编码，导致库存金额统计时出现重复和遗漏。主数据不唯一，任何报表都是不可信的。

2. 第二层是流程层：动作是否有明确的输入输出

库存相关的每个动作，都需要明确输入、输出和触发条件。比如"退货入库"这个动作：输入是退货到仓、触发是质检通过、输出是库存状态变更。如果流程没有明确的输入输出定义，它就只是一个习惯，无法被系统化和被追踪。

3. 第三层是责任层：每个环节是否绑定到人

流程清晰之后，必须把每个环节绑定到一个具体的人。团队C的做法是给每类库存异常指定一个默认责任人：退货未回写归仓储，在途超期归采购，状态错置归运营。责任不明时，异常会在部门之间循环流转，最终消失。

4. 第四层是复盘层：是否有固定的复盘节奏

最后一层是节奏。再好的机制也会随时间退化，必须有固定的复盘周期（我们是每周一次库存专项会，每月一次归因分析）来持续校准。团队B的经验是，复盘节奏一旦中断超过三周，库存准确率就开始下滑，说明机制需要持续维护。

七、落地动作：我们到底做了什么（以数跨境为例）

讲完逻辑，必须落到动作。这一节我用团队C的实际落地过程作为主线，中间会说明我们在数跨境里具体做了什么。选择数跨境作为统一平台的原因很直接：团队C的核心痛点是多平台库存口径不统一，而数跨境的定位就是把跨境电商的多平台数据接入并做统一的库存、供应链与核算口径（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）。

它不是用来替代管理动作的，而是让管理动作有据可依。

1. 统一主数据与库存口径

第一步是把所有平台的SKU映射到一套内部编码。这一步看起来简单，实际花了两周，因为存在大量历史脏数据：同一产品在不同平台用了不同编码，组合装没有拆解，变体库存被错算到父SKU上。

在数跨境里，我们把多平台商品数据接入后做了一层SKU映射表，把平台SKU、内部SKU、供应商货号三者对应起来。这样任何一个平台产生的库存变动，都能归到同一个内部SKU上。统一编码是让库存口径收敛的第一步，也是不可跳过的一步。

接着定义"可售库存"的唯一口径，写成一份可供全员引用的字段说明。这份说明后来成为团队C所有库存讨论的基础：

可售库存 = 在库可发数量 + 在途可确认数量 – 已占用待发数量 – 冻结/质检中数量
字段口径说明：

在库可发数量：已完成上架、质检通过、可被订单直接扣减的实物数量

在途可确认数量：已发货且有有效物流轨迹、预计到仓日在未来承诺窗口内的数量

已占用待发数量：已生成订单但尚未出库扣减的数量

冻结/质检中数量：退货待质检、批次异常、待处理的数量

更新频率：平台订单数据 15 分钟同步；在途数据按物流轨迹每日更新

责任归属：在库可发-仓储；在途可确认-采购；已占用待发-运营；冻结质检-仓储+客服

这份口径最大的价值不是数学公式，而是最后一行的责任归属。每一个字段都有明确的责任人，库存争议从此有了裁决依据。

2. 固化补货SOP：谁提报、谁审核、谁执行、谁复盘

第二步是把补货从"经验判断"变成"有记录的动作"。我们定义了四个环节和各自的承诺节点：

1. 运营提报需求：基于销量趋势和活动计划，每周二提交补货建议，含预测销量和紧迫度
2. 采购审核并下单：周三确认供应商交期和数量，在系统中生成补货单，明确计划到货日
3. 仓储收货并验收：按补货单号收货，数量差异当场记录，状态实时回写
4. 每周复盘：对比计划到货日与实际到货日，分析延误原因并归档

这个SOP的关键不是流程本身，而是每一步都在系统里留下了可追溯的记录。三个月后团队C第一次能回答"这批货为什么晚了12天"，因为补货单上记录了每个节点的实际时间。

3. 建立异常任务与责任人

第三步是把库存异常从"群消息"变成"系统任务"。我们定义了五类常见异常，每类都有默认责任人和响应时限：账实不符（仓储，24小时）、在途超期（采购，48小时）、退换货未回写（仓储+客服，72小时）、SKU映射错误（运营，24小时）、库存负值（运营+仓储，12小时）。

在数跨境里，这些异常可以在库存看板层面被标记和追踪，团队可以按状态筛选未闭合项，避免了此前"异常躺在群里"的问题。团队C上线这个机制后，异常闭环时长从11天降到2.3天。

4. 用看板对齐周会

最后一步是改变周会的开法。以前周会各部门带自己的表，现在所有人看同一块库存看板：准确率、缺货率、滞销率、周转天数、补货及时率、异常闭环时长。同一块屏幕意味着同一个事实基础，会议从"对齐认知"转向"讨论行动"。

团队C的周会时长从平均110分钟压缩到55分钟，而讨论的问题数量没有减少。省下来的时间不是靠砍议题，而是靠消除了口径争议。

八、效果复盘与归因：哪些结果该归功于系统，哪些不能

上线六个月后，团队C的核心指标全面改善。但我坚持做了一件事：把这些改善拆解归因，明确哪些来自系统能力，哪些来自管理动作。因为如果不做归因，团队会错误地把所有功劳记在软件上，下次遇到问题仍然不会从机制上找原因。

1. 指标变化的整体情况

库存准确率从68%提升到94%，补货及时率从54%提升到86%，异常闭环时长从11天缩短到2.3天，库存周转天数从62天降到48天，滞销率从19%降到11%。这些数字在团队C的语境里是真实的、可核对的。

2. 归因拆解：管理动作贡献约七成

我的归因方法是对照实验式观察：把改善拆成"系统上线带来的数据可见性提升"和"管理动作带来的行为改变"两部分。

以库存准确率为例，从68%到84%这一段主要靠系统把差异暴露出来（可见性贡献）；从84%到94%这一段主要靠异常责任机制和每周复盘（管理动作贡献）。系统让问题可见，管理让问题消失。如果没有后一段的管理动作，团队很可能长期停在84%左右，因为差异能看见了，但没人负责解决。

3. 三个典型SKU案例

（1）爆款SKU的缺货与虚高并存

某爆款在平台上显示可售142件，实际可发89件。统一口径后发现，差额来自一批海外仓退货未质检。修正口径后，运营按真实可售调整广告预算，避免了断货期间的无效投放。这个案例说明库存准确率直接影响广告效率，两者不是独立问题。

（2）长尾SKU的滞销与资金占用

某批SKU积压超过120天，金额约37万元。复盘发现根本原因是补货决策时没有参考历史动销趋势，仅凭一次活动数据判断。建立决策记录后，同类误判减少了。这个案例说明补货记录的价值在三个月后才显现，短期看不到收益，容易被忽略。

（3）在途超期导致的连续误判

某批货在途延误18天，但系统里未更新预计到仓时间，导致运营连续两周按原计划补货，最终重复下单。修正为物流轨迹每日更新在途状态后，此类问题基本消失。这个案例说明在途数据的时效性直接决定补货决策质量。

九、不同情况下的行动建议

复盘的价值在于可迁移。下面按团队所处阶段给出不同的行动优先级，这些建议来自三个团队的实践和踩坑。

1. 还没上ERP：先把口径写下来，再谈系统选型

如果团队还在用Excel管理库存，第一件事不是选系统，而是把"可售库存"的定义写下来并让所有部门认可。这件事不花钱，但决定了后面上任何系统的效果。我见过太多团队跳过了这一步，结果上线后仍在争论什么是可售。

第二件事是盘点SKU编码现状，找出重复和缺失。编码不统一的情况下上系统，只会把混乱搬到系统里。

2. 刚上线ERP：先验证指标，再宣布项目成功

刚上线的团队，建议把验收标准从功能清单改成协同指标。具体做法是设定基线：上线前记录五个指标的当前值，上线后按月跟踪。

同时要接受一个现实：上线后第一个月指标可能变差，因为流程调整会带来短期混乱。这时候不要急着否定项目，要看第二、第三个月的趋势。

3. 上线6个月以上：从指标跟踪转向机制维护

上线半年后，指标改善往往会放缓。这时候的重点应该转向维护：复盘节奏是否还在坚持？责任人是否因人员变动而失效？口径是否因业务变化而需要更新？

团队B就出现过这个问题：上线一年后复盘会从每周变成每月，库存准确率在两个季度内从95%回落到88%。协同机制像肌肉，不练就会退化。

4. 多平台多仓：优先解决数据接入的完整性

对于像团队B这样SKU多、平台多、仓库多的团队，优先事项是数据接入的完整性，而不是指标精细度。因为只要有一个平台的库存数据没接入，总可售量就是错的，后面所有分析都失去意义。

这也是我认为像数跨境这类专注跨境数据接入的平台在这类团队中价值更明显的原因：多平台、多币种、多仓库的库存数据能不能收敛到一个口径下，直接决定了协同讨论有没有共同基础。

十、不同情况下的取舍

行动建议之外，还需要讲取舍。库存协同中几乎每个改善都伴随成本或副作用，没有免费的午餐。

1. 准确率与时效性的取舍

追求100%准确率意味着每笔变动都要核对，会拖慢操作时效。团队B的经验是按金额分层设定标准：占库存金额前20%的SKU要求99%准确率，其余SKU接受97%。这样既控制了主要风险，又不拖慢整体流程。

2. 统一口径与部门自治的取舍

完全统一口径会让某些部门的特殊需求被牺牲。比如运营希望看到"潜在可售"用于投放判断，仓库只关心"实物可发"。我们的取舍是定义唯一主口径，但允许派生口径存在，只是必须标注来源和用途，避免派生口径被当作决策依据。

3. 系统自动化与人工兜底的取舍

自动化程度越高，异常情况下的处理弹性越低。团队A选择了在补货审批环节保留人工确认，虽然降低了效率，但避免了系统按错误预测自动下单的风险。自动化应该用在高频、低风险的环节，人工应该保留在低频、高风险的决策上。

4. 采购工具与自建开发的取舍

对于SKU规模在千级以内、平台数量不超过三个的团队，采购成熟工具通常比自建更划算，因为自建的隐性成本（维护、迭代、人员流动）常常被低估。但如果是高度定制化的业务模式，自建可能更合适。判断标准不是成本高低，而是你的库存逻辑是否足够特殊，特殊到通用工具无法承载。

十一、可复制模板：库存协同复盘清单

最后给出可直接套用的模板。这些模板是三个团队实践中逐步成型的，去掉了解释性文字，只留可执行结构。

1. 库存协同指标表

建议每周更新一次，每月做一次趋势回顾。表格要包含指标值、环比变化、责任人和异常备注四列，避免只记录数字不记录归因。

2. 补货SOP清单

1. 运营提报：明确预测销量、紧迫度、参考依据
2. 采购审核：确认供应商交期、下单量、计划到货日
3. 仓储收货：按单号验收，差异当场记录并回写
4. 周度复盘：对比计划与实际到货日，归因延误
5. 季度校准：回顾预测准确率，调整预测方法

3. 异常闭环看板字段

建议包含：异常类型、涉及SKU、发现时间、默认责任人、响应时限、当前状态、关闭时间、根因备注。核心是每一条异常都必须有责任人和时限，否则它只是一个通知。

4. 复盘会议议程

1. 五个核心指标本周表现（10分钟）
2. 未闭环异常进度回顾（15分钟）
3. 重点SKU案例归因（20分钟）
4. 下周行动与责任人确认（10分钟）

这个议程控制在55分钟内，比传统的库存会议短很多，但覆盖了从数据到行动的完整链路。

十二、结语：库存验证的是协同，不是软件

回到最初的问题：ERP跨境电商实战复盘，库存管理到底验证了什么？我的答案是，它验证的不是哪个系统功能更全，而是这个团队能不能对同一件事形成同一个事实。

三个团队、217起差异事件、六个指标、四个归因层次，最终指向一个判断：ERP的价值等于流程加数据加责任加复盘，缺任何一项，库存数字都不会变好。系统能让问题可见，但只有管理能让问题消失。这就是为什么我说库存准确率提升里七成来自管理动作，这个比例可能会让期待"买了系统就解决问题"的人失望，但它是我见过的最接近真相的答案。

如果你正准备做类似复盘，我的建议是：先别急着看功能清单，先找五个跨部门的同事，问他们同一个SKU的可售库存是多少。如果答案不一致，那么你的下一个动作不是选系统，而是把口径写下来、把责任人定下来、把复盘节奏排进日历。这三件事做完，你才有资格谈工具的价值。

库存是结果，协同是原因。把原因修好，数字自然会跟上。