去年8月，一个做家居收纳的卖家找到我，说他们在会员日当天超卖了 340 多单，其中 217 单来自同一个爆款 SKU。聊到最后发现，问题根本不在 ERP 上，他们用的那套 ERP 功能其实很全，库存同步、订单占用、波次拣货都有。真正的问题在于：运营在后台手动改了库存，仓储在 ERP 里按实物盘了库，两个动作之间没有任何时序约定，谁先谁后完全看当天谁更闲。
这件事基本能代表我在跨境电商库存管理上见过的绝大多数问题。不是工具不行，是流程没想清楚；不是没有流程，是流程里的"谁先动、谁后动、谁说了算"从来没被写下来过。
这篇内容我想把"库存管理中的流程设计怎么处理"这件事拆到底。不谈概念，直接讲我在实操里怎么判断、怎么取舍、哪些坑一定会踩。文中涉及的数据，一部分来自我和卖家团队一起跑出来的实测值，一部分是行业公开口径，还有一部分是情景模拟，我会在相应位置标清楚来源，你可以自己判断可信度。
先把最重要的判断说在前面，后面所有章节都是围绕这三句话展开的。
判断一：库存准确率的上限，由"库存事件的定义"决定，而不是由 ERP 的功能清单决定。
我见过功能很全的 ERP 跑出 82% 的库存准确率，也见过功能一般的 ERP 跑出 98%。差别在哪？前者团队里没人说得清"出库"到底指"包裹离开仓库"还是"面单打印完成"。
事件定义不统一，所有下游的库存扣减、回写、对账都会错位。这个错误会随着订单量放大，最后变成一笔谁也说不清的糊涂账。
判断二：跨境场景下，流程设计的第一优先级是"时序"，不是"功能"。
国内电商的库存扣减逻辑相对统一，跨境不一样。亚马逊、Shopee、TikTok Shop、Temu 在库存扣减时点上都有差异，有的下单即占，有的付款后占，有的发货才扣。
所以跨境库存流程设计里，最该先回答的问题是：同一个 SKU 在 5 个平台上，分别在哪一个时刻被认为是"已经卖掉了"？
判断三：流程必须留人工兜底出口，但兜底出口要限量。
完全不允许人工干预的库存流程，在大促、清仓、换供应商这些场景下会直接卡死业务。但如果你给运营留了 12 个可以手动改库存的入口，那这个流程等于没有流程。
我的经验是：全流程的人工干预入口控制在 3 个以内，并且每一个入口都必须留下可追溯的操作日志。
行业里流传一句很正确但很不完整的话：先理流程，再选 ERP。它对的部分是提醒你不要被功能清单牵着走；不完整的部分是，它把流程设计看成了一个可以先于工具存在的静态物件。
实际情况是反过来的。流程的颗粒度，受限于你手里的工具能记录多细的数据。
举个很具体的例子。如果你的工具只能记录到 SKU 级别的库存，那你想做库位级别的拣货路径优化，流程画得再漂亮也落不了地，因为数据源头就没有这一层信息。
所以更准确的顺序应该是：先定义库存事件 → 再据此设计流程 → 再确认工具能否记录事件所需的字段 → 最后才是选型。中间第三步经常被跳过，结果就是流程和工具互相将就，谁也不舒服。
为了不让你在阅读时被模糊表述误导，我把后面会用到的几类数据来源先交代清楚。
很多人把跨境库存管理理解成"国内库存管理加个海外仓"，这个理解会直接导致流程设计跑偏。实际多出来的是四层结构性的复杂度。
同样是卖一个 SKU，不同平台对"这件货已经不属于你了"这件事的判定时点是不一样的。有的平台下单就锁库存，有的付款后锁，有的要等到你上传物流单号才扣减。
这意味着你在设计流程时，不能只有一个"可用库存"概念，至少要拆成三个：实物库存、平台锁定库存、可售库存。
我见过的最常见的错误，是把这三个数字当成同一个东西，然后让运营在后台直接改"库存"。改完之后，平台侧显示的、ERP 里记的、仓库里躺的，三份数据永久性错位。
更麻烦的是，不同平台的锁定时长也不一样。有的平台超时未付款会自动释放，有的会锁很久。如果你的流程里没有"锁定库存自动释放"这一环，你的可售库存会被慢慢吃掉，最后表现为"明明有货却显示缺货"。
头程在途、海外仓调拨在途、FBA 转运在途，这些货到底算不算库存，是跨境卖家每天都在纠结的问题。
我的处理原则是：在途库存不进"可售库存"，但要进"未来可用库存"，并且必须带预计到仓时间。
为什么不进可售库存？因为头程延误、清关卡关、货代换船，任何一个环节出问题，你的在途时间就会从 25 天变成 45 天。如果你提前把这些货算进可售，运营就会按有货的逻辑去投广告、报活动，最后爆单发不出去。
那为什么又要单独记录？因为没有这个数字，采购补货就没有依据，你会陷入"缺货，紧急空运，成本爆炸"的循环。
这是最隐蔽也最致命的一层。运营、仓储、采购，三方说的"可用库存"往往不是同一个数。
三个数字都对，但三个数字不一样。如果流程里没有明确规定"对平台报库存时用哪一个口径"，那就会出现：运营说还有 800 件，仓储说只有 420 件，采购说按在途算有 1500 件。会议开三小时，谁也没说服谁。
跨境电商的库存成本牵扯到汇率、头程运费分摊、关税、仓储费，这些成本和货物实物的流转节奏并不一致。
比如一批货 3 月 10 日发出头程，4 月 2 日到海外仓，5 月 18 日才全部卖完。业务上这批货 4 月 2 日就算入库了，但财务上汇率的确认、运费的分摊可能要等到 5 月底对账完成才能定。这个时间差如果没有在流程里设计好挂账和冲销节点，财务和业务就永远对不上账。
下面这五个错误，几乎每一个跨境卖家团队都会至少踩中两个。我把它们按我观察到的出现频率排序。
这是最普遍的一个。团队在选型时问的第一个问题经常是"你们能不能多平台库存同步"，对方答"能"，这事就算过了。
但库存同步从来不是一个能或不能的问题，而是一组必须明确的规则：同步频率是多少？同步冲突时以谁为准？同步失败重试几次？重试全部失败后触发什么动作？
我在一个做 3C 配件的团队里见过这样的配置：5 个平台每 15 分钟同步一次，冲突时以 ERP 为准。听上去没问题。但他们的爆款 SKU 在会员日期间每分钟能出 3，5 单，15 分钟的同步间隔意味着最多有 75 单的窗口期是"各平台各卖各的"。
结果就是超卖。这个问题不是 ERP 的问题，是同步频率和业务节奏不匹配的问题，而同步频率是流程设计里必须提前定的参数。
共用一个库存池看起来最简单，实际上是把所有平台的销售速度差异风险集中到了一起。
假设你有一个 SKU，在亚马逊上每天出 20 件，在一个新开的小平台上每天出 1 件。共用一个 500 件的池子，理论上 25 天卖完。但如果亚马逊广告突然爆量，3 天卖掉 300 件，那个小平台上的买家就会开始遇到超卖。
更糟的是，小平台往往是你刚开始做、最需要好评积累的时候，一次超卖带来的差评影响远大于亚马逊上的一次超卖。
我的建议是：头部平台和长尾平台必须分池，分池比例按近 30 天各平台的实际销量占比来定，并且每周复核一次。
这是库存虚增的最大来源。买家的退货包裹寄回来了，仓库签收了，员工在系统里点一下"退货入库"，库存数字就加上去了。
但这件货真的还能卖吗？可能包装破损、可能缺配件、可能是买家换货寄回的另一个型号。如果不做判定直接入库，你的可用库存里就会混进一批永远卖不掉的货，而这些货会持续拉高你的库存周转天数。
我给团队的标准是：退货入库必须经过判定环节，判定结果至少分四类，可再售、需翻新、可拆件、报废。只有"可再售"这一类才能进入可用库存，其余三类分别进入独立库位，不参与销售分配。
库存对不上怎么办？很多团队的做法是安排一个人每天手动核一遍，把差异改回来。
这个做法在订单量小的时候是有效的，但它有一个隐藏成本：它会让系统性的逻辑错误永远暴露不出来。
因为你每天用手工把错误改掉了，系统就永远不会告诉你"哪个环节在持续产生差异"。等到订单量翻三倍，一个人核不过来了，所有积压的问题一次性爆发。
正确的做法是：人工核对保留，但必须记录差异条目和差异原因，每月做一次差异归因分析。核对的目的是发现规律，不是抹平数字。
流程上线那天，往往是它最贴合业务的那天。之后业务在变，平台规则在变，SKU 结构在变，但流程不动。
我一般会要求团队在流程设计文档里明确写三个时间点：上线后第 30 天做第一次复盘、第 90 天做第一次修订、之后每季度做一次复核。每次复核必须回答一个问题：过去一个季度，哪个环节的异常率最高，为什么。
下面这套五层模型是我在实际项目里反复用过的推导顺序。它的特点是：每一层都必须在上层确定之后才能做，跳过任何一层都会在后面付出代价。
先把所有会让库存数字发生变化的事情列出来，每一件事都要有明确的名称、触发条件和数据来源。
一个完整的跨境库存事件清单通常包含这些：采购下单、头程发货、到仓签收、质检完成、上架、平台订单生成、平台订单付款、订单审核通过、拣货完成、打包完成、面单打印、交接物流、物流揽收、平台确认发货、退货签收、退货判定、调拨出库、调拨到仓、盘点调整、报废。
这份清单看起来啰嗦，但它的价值在于：只有把事件列全了，你才能发现哪些事件在流程里是缺失的。我见过的团队里，至少有三分之一在第一次列清单时漏掉了"退货判定"，还有一部分漏掉了"平台确认发货"这个动作与本地库存扣减的先后关系。
事件列全之后，接下来要回答的是：哪些事件有严格的先后依赖，哪些可以并行，哪些必须互斥。
以最关键的"库存扣减"为例，你要明确知道：库存是在"平台订单生成"时扣，还是在"平台确认发货"时扣。这两种选择带来的结果完全不同。
我的判断标准很简单：如果你的退货率超过 15%，或者你的客单价超过 50 美元，优先选下单即扣。因为这两种情况下，超卖带来的损失远大于库存占用带来的损失。
库存不是一个数字，是一个状态。每一个 SKU 的每一批货，都应该在任意时刻处于一个明确的状态中。
我通常会把库存状态设计成下面这样一套，并且要求任何流程动作都只能让状态在这几个值之间迁移：
库存状态定义（示意）
PURCHASING 采购中，不计入任何可用口径
IN_TRANSIT 头程在途，计入"未来可用库存"
RECEIVING 已到仓待质检，不计入可售
QC_HOLD 质检异常隔离，不计入可售
AVAILABLE 可售，参与平台分配
RESERVED 已被平台占用，未出库
PICKING 拣货中，已从可用池移出
SHIPPED 已出库，实物离开仓库
RETURN_HOLD 退货待判定
RETURN_SELLABLE 退货可再售，回到 AVAILABLE
SCRAPPED 报废，永久退出
允许的状态迁移（部分）：
PURCHASING -> IN_TRANSIT （头程发货）
IN_TRANSIT -> RECEIVING （到仓签收）
RECEIVING -> QC_HOLD （质检不合格）
RECEIVING -> AVAILABLE （质检通过并上架）
AVAILABLE -> RESERVED （平台订单生成/付款）
RESERVED -> AVAILABLE （订单取消或超时释放）
RESERVED -> PICKING （拣货任务生成）
PICKING -> SHIPPED （交接物流完成）
SHIPPED -> RETURN_HOLD （买家退货签收）
RETURN_HOLD -> RETURN_SELLABLE （判定为可再售）
RETURN_HOLD -> SCRAPPED （判定为报废）
这套状态机的价值在于：任何一笔库存差异，都可以被定位成"某次不允许的状态迁移"或"某个状态停留时间过长"。这就把"库存对不上"这个模糊问题，变成了一个可以逐条排查的具体问题。
正常路径走通只解决了 80% 的问题，剩下 20% 是异常。异常出口的设计原则是：出口数量要少，但覆盖要全。
我给团队设计的标准异常出口通常只有三个：
三个出口以外，一律不允许直接改数据库或后台改数字。这条规则听起来严格，但它是库存准确率能长期维持在 95% 以上的前提。
这是最容易被忽略、但价值最高的一层。校验回路的意思是：流程必须自己检查自己对不对。
具体来说，至少要建立三组定期校验：
这三组校验如果都能跑起来，库存问题基本不会积累到不可收拾的程度。库存管理最难的不是发现问题，而是在问题还小的时候发现它。
流程设计完之后，接下来是落实到系统。这里我要讲一个具体的工具视角，因为很多团队的问题不是不会设计流程，而是设计完流程之后，没有任何一层机制能验证流程到底跑得对不对。
我在给团队做库存流程复盘时，常用的一套思路是：ERP 负责"执行流程"，另外需要一层负责"校验流程"。这两件事在系统里通常是分开的。执行层管的是订单进来之后按规则扣库存、生成拣货任务、回传物流单号；校验层管的是把多个来源的数据拉到一起，看它们对不对得上。
在这一层上，我比较常用来做验证的工具之一是数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）。它的定位更偏数据整合与分析，不是仓储执行系统，所以它在我这套流程里的角色非常明确，它不替你管仓库，它替你验证你的仓库管得对不对。
这是最基础也最见效的一步。多平台卖家的第一痛点从来不是某个平台的数据不对，而是五个平台的数据放在五个后台，没人能在一分钟内说清"我现在到底有多少货"。
我在实操里的做法是，把各平台店铺的订单、库存、退货数据授权接入之后，统一到一张库存明细表里。这张表的核心字段通常包括：SKU、平台、站点、日期、期初库存、平台扣减量、ERP 记录扣减量、退货量、差异量。
有了这张表，你会发现一些以前完全看不见的东西。比如某个平台的扣减量连续 7 天比 ERP 多出固定比例，那基本可以确定是扣减时点的规则差异，不是操作错误。
再比如某个 SKU 在三个平台的库存数字完全一致，但实物每次盘点都少几件，那问题大概率出在退货判定环节被跳过了。
库存数据汇总之后，第二件有价值的事情是做周转分析。我关注的指标主要是三个：库存周转天数、动销率、滞销库存占比。
这三个指标本身不新鲜，但用它们反推流程瓶颈，是我觉得最有意思的地方。
举个真实的例子。一个做户外用品的卖家，整体库存周转天数是 78 天，看起来还行。但拆到 SKU 层面之后发现，占比 12% 的滞销 SKU 贡献了 46% 的库存金额，周转天数是 210 天。
追下去发现，这批滞销货的入库时间集中在同一个月份，而那个月正好是他们海外仓换服务商的月份。换服务商导致入库质检流程被压缩，一批本来应该在质检阶段就被识别为"包装破损不符合销售标准"的货，被直接上架了。
上架之后没人买，三个月后才发现包装问题，但那时已经过了退货窗口。这就是典型的流程漏洞在数据上的表现：它不会表现为"库存对不上"，它会表现为"周转天数异常"。
第三步是把前面讲过的校验回路，从"想起来才做"变成"定期自动跑"。
我的做法是把校验做成三张固定看板，每周固定时间看一眼：
第三张看板经常被忽略，但它其实是最有价值的。手工操作次数是一个极好的流程健康度指标：它上升，说明你的流程在某处已经不适配业务了；它下降，说明流程优化真的起作用了。
为了让你对"数据层校验"这件事有更具体的感知，我把一个典型周末巡检的操作路径写出来，你可以对照自己的情况调整。
这套动作熟练之后，一个人每周花 40 分钟就能跑完。它的价值不在于消灭差异，而在于让差异始终处在一个可解释的状态。能解释的差异是可控的，不能解释的差异才是风险。
库存流程设计没有一套通吃的方案。下面按我接触最多的四类团队情况分别给建议，你可以先对号入座。
这个阶段的团队，最大的风险是过度设计。我见过年 GMV 300 万的团队花两个月设计五层决策模型，结果业务节奏跟不上，流程还没上线爆款周期就过了。
我的建议是只做三件事：
这个阶段不要上复杂的状态机，不要做多平台分池，不要引入第三套系统。这个阶段的库存准确率目标定在 92% 就够，剩下 8% 用人工核对兜住更划算。
这是问题最集中、也是收益最明显的一个区间。多数团队在这个阶段会同时遇到超卖、账实不符、周转天数上升三个问题。
我的建议是：
这个阶段的重点不是"上一个更强的 ERP"，而是让现有的 ERP 跑在一个被持续验证的环境里。工具再强，跑错了没人知道，一样是白搭。
这个阶段的复杂度主要来自组织和地理分布，不再是单一流程问题。
我的建议是：
这类团队最忌讳的动作是"换系统"。换系统解决不了流程问题，只会把老问题原样搬到新系统里，外加一次数据迁移的事故风险。
我给出的标准动作是三步：
前面讲的都是"应该怎么做"，这一节讲的是"怎么选都难受"的部分。这些选择没有标准答案，但有判断依据。
实时扣减的好处是安全，坏处是贵。每一次订单状态变更都要触发一次跨系统调用，接口成本、失败重试、并发冲突的处理量都会上去。
延迟扣减的好处是便宜、稳定，坏处是有超卖窗口。
我的取舍判断是：看单量密度，不看单量总量。如果某个 SKU 在促销期每分钟能出 5 单以上，就必须实时；如果一天出 5 单，延迟 15 分钟完全没问题。
所以正确的做法不是全局二选一，而是按 SKU 分级配置。爆款走实时、长尾走延迟，这才是成本可控的方案。
集中池的优势是库容利用率高，劣势是平台间互相挤占；分池的优势是各平台体验稳定，劣势是总会有平台库存压着卖不完。
我的经验数据是：当你的平台数超过 3 个，且各平台销量占比差距超过 3 倍时，分池的综合收益明显更高。因为这个时候，长尾平台被挤占带来的差评损失，已经超过了集中池节省下来的那点库存成本。
反过来，如果两个平台销量占比接近，集中池更划算，因为两个池子之间的余量可以互相补。
这个取舍的核心不是"要不要人工"，而是"人工的入口设在哪"。
我的原则是：入口设在流程的"判断节点"上，不设在"执行节点"上。
判断节点指的是需要经验和上下文的地方，比如退货判定为可再售还是报废、库存冻结要不要解除。这些地方让系统自动做，风险反而更大。
执行节点指的是有明确规则的地方，比如订单生成后扣多少库存、拣货完成后扣哪个库位。这些地方让人来做，纯属浪费人力还容易出错。
所以正确的做法是：执行节点全自动化，判断节点保留人工，但人工的每一次判断都必须产生一条带原因码的记录。
每个平台都有自己的规则怪癖。有的平台允许超卖，有的平台超卖直接扣分；有的平台退货周期是 30 天，有的是 90 天。
全部标准化会让某些平台的体验变差，全部做特例又会让流程复杂度爆炸。
我的判断标准是：只对"会直接导致资金损失或账号风险"的平台规则做特例，其余一律标准化。
比如超卖扣分，这属于账号风险，必须做特例，给这个平台单独留安全库存。比如退货周期长短，这只影响财务预估，标准化处理即可，不需要为它专门设计一条流程分支。
写到这里，我想把整篇的判断收敛成几句话，再给你一份可以直接拿去用的自查清单。
库存流程设计不是画流程图，是在回答"库存的每一次变化，由谁在什么时候、依据什么来认定"这个问题。
围绕这个定义，我有三个可能和主流说法不太一样的观点：
下面这份清单共 12 项，你可以逐条对照自己的团队。打勾少于 6 项，说明你的库存流程还处在"靠人"的阶段。
如果你现在就想动手，我建议按这个顺序来，不要跳步。
第一周，只做一件事：把库存事件清单列出来。不要改任何系统，不要写任何文档，就是把团队里三个人拉在一起，把"库存数字会变化的所有时刻"一条一条写下来。你会发现三个人写出来的清单是不一样的，这个差异本身就是最有价值的发现。
第二到第三周，做归因不做修复。记录两周内所有库存差异的细节，按原因分类，看看前两类占了多大比例。不要急着改，先看清分布。
第四周开始，只改贡献最高的那一类原因。改完观察两周，看看差异量有没有下降。下降了再动第二类，没下降说明你对原因的判断是错的，回去重新归因。
至于工具层面，我的建议是分两步：执行层继续用你现在的 ERP，不要急着换；校验层可以先用轻量的数据工具把多平台库存数据拉到一起，看看能不能对得平。像数跨境这类定位在数据整合与分析的工具，在这个阶段起的作用就是把看不见的差异变成看得见的表格，让你在动手改流程之前，先知道问题到底出在哪。
库存管理这件事，从来不是一次上线就结束的工程。它是随着你的 SKU 结构、平台组合、仓储布局持续变化的一套活流程。能持续发现问题，比一开始设计得多完美重要得多。
我同时做亚马逊、Shopee和TikTok Shop，三个平台的出单节奏完全不一样。大促那天东南亚站先爆单，美国站还在慢悠悠出，结果ERP里显示还有货，实际仓库已经被拣空了，最后超卖赔了两单。我一直在纠结是不是该把所有平台都改成实时同步，但又怕接口调用太频繁被限流。
判断依据不是『哪个更先进』，而是你的订单峰值和库存粒度。日订单在200单以内、SKU少于500个，用5到15分钟的定时同步就够了，接口稳定且成本低。
超过这个量级或者做大促，建议采用『中心库存池+平台可用量分配』的模式：ERP维护一份总库存，按各平台历史动销占比分配可售额度，平台侧显示的是分配量而不是总量，任一平台出单后立即扣减中心池并回写其余平台。同时设置缓冲值，比如实际库存100件，各平台可售量合计只放95件，留5件吸收同步延迟。
大促前把同步频率临时提到1到3分钟一次，并在活动开始前2小时冻结库存分配比例，避免中途调整导致的数据错乱。
我们做的是自发货加少量海外仓，运营那边经常抱怨库存对不上。有次客户下单后自己取消，系统里库存没回滚，第二天又卖了一件，实际仓库只有一件，发货时才发现。还有一次是订单还在待付款状态，库存就已经被占掉了，导致别的平台显示无货。我搞不清到底应该在哪个节点扣库存。
标准做法是把库存分成三段状态管理：可用库存、占用库存、实扣库存，而不是一个数字直接加减。下单未付款阶段只做『预占』，设置15到30分钟的预占超时，超时未付款自动释放；付款成功后转为『占用』，此时不扣减可用库存但锁定不可售；仓库发货扫描出库时才做『实扣』，真正从可用库存里减掉。
取消和退款的回滚要挂在订单状态机上：付款前取消直接释放预占，付款后发货前取消把占用退回可用，发货后退货则走逆向入库流程，质检合格后才重新计入可用库存。判断ERP是否靠谱，就看它能不能把这三个状态分开显示，只给一个『库存数量』的ERP，对账时一定会出问题。
我们有国内仓备货，也用了美国海外仓，还有一批货在海上漂着。运营天天问这批在途的能不能先拿去投广告、先开预售，我怕算进去之后发不出货。现在是两头手工对，Excel加ERP，经常对不上，月底盘一次要两天。
建议按『物理位置+业务状态』两个维度建模，而不是简单分成国内和海外。常见做法是划分为：国内可用、国内待发、在途（头程未到港）、海外在库、海外在途（尾程调拨中）、待质检、锁定/预留。
在途库存是否计入可用，取决于你的承诺能力：如果头程时效稳定（比如固定船期且历史准点率在90%以上），可以把在途设置为『可预售』，但要在平台侧单独开一个预售SKU或设置更长的承诺发货时间，绝不能直接混进现有SKU的可用量。
海外仓补货建议设定再订货点和安全库存，安全库存按『补货周期内的日均销量×波动系数』估算，头程30天的线路，波动系数取1.3到1.5比较稳妥。国内仓和海外仓之间用调拨单串联，调拨单出库即从国内可用扣减、计入海外在途，海外仓签收入库后才转为海外可用，中间的每一步都要有单据，否则对账永远对不上。
我们去年上了一套ERP，功能看着挺全的，但用起来还是靠人救火。打单员要手工核对平台订单和仓库发货，退货入库经常忘记登记，运营天天在群里问库存准不准。老板觉得是ERP不行想换，我又觉得可能是我们自己的流程没理清，纠结要不要推倒重来。
先用两周做一次『单据断点排查』再决定换不换系统。具体做法是：把一笔订单从平台下单到财务入账的完整链路画出来，标出每个环节由谁操作、在哪个系统里记录、下一步靠什么触发。凡是出现『靠微信通知』『靠Excel中转』『靠人记得』的节点，就是断点。
断点位置如果在系统能力覆盖范围内（比如退货入库ERP本来就支持，只是没人用），那是流程执行问题，补制度和培训就能解决，换系统没用。如果断点是系统根本不支持（比如多平台库存无法统一视图、退货不能生成逆向入库单、打单不能按波次合并），那才是选型问题。
经验上，ERP上线后仍然靠人对账、月盘点差异率超过1%、订单从付款到发货超过24小时的，八成是流程断点而非系统缺陷，先把断点修完再看效果，通常能解决大部分问题。
读者评论
库存事件定义不统一这个点很真实，我们之前就是运营在后台改库存，仓储又盘库，两边不同步，大促直接超卖。后来把'谁先动、谁后动'写清楚，差异少了很多。
共用库存池不做分池这个坑我们踩过，亚马逊爆单把新平台坑惨了，差评哗哗来。分池确实是必要动作，尤其长尾平台在积累期，一次超卖影响很大。
文章提到流程上线即冻结的问题，我深有同感。很多团队上线后就不管了，业务变了流程没变，异常率慢慢爬高。定期复盘这个机制建议很实用。
退货只收货不判定是库存虚增的元凶，我们仓库就堆了一堆不能卖的退货。分四类处理虽然增加工作量，但能避免可用库存被污染，长期看值得做。