2025年3月，我给一家做户外品类的跨境卖家做补货诊断。他们有7个亚马逊店铺、2个TikTok Shop店、1个独立站，在售SKU不到400个。按很多人的直觉，这个体量根本不需要多复杂的系统。但事实是：他们的采购员每周要花整整两个工作日做补货表，旺季每个月至少出现3次"同一个供应商、同一批货、被下了两次单"的事故。
更让我意外的是，当我问"这个SKU现在到底有多少可用库存"时，采购、运营、仓库给了我三个不同的数字。采购看的是Excel表里的在库数量，运营看的是平台后台的可售数量，仓库看的是实际到仓数量。三个数字都没错，但它们根本不是同一个东西。
这就是我今天想说的核心判断：多店经营的采购补货，难点从来不是"算多少"，而是"算谁的"。很多团队把ERP实施理解成"装一个更聪明的计算器"，结果上线之后补货反而更乱，因为系统只是把原本就混乱的库存口径，用更快的速度放大了一遍。
下面我会把这条实施路径拆成四件事：多店到底改变了什么、常见误区在哪、正确的判断顺序是什么、以及不同规模的卖家分别应该先做什么。中间会用我在实际项目里观察到的数据和一个可参考的落地样本（数跨境）来说明。
在展开之前，我先把三个结论摆出来。这三个结论决定了后面所有实施动作的先后顺序，如果顺序错了，投入的每一分钱都会打折。
绝大多数卖家在选型时最关心的问题是"你们的补货算法准不准"。但在我做过的项目里，补货建议失真的原因里，算法精度只占很小一部分，更多是因为输入数据本身口径不一致。
同一批货，在采购眼里是"已下单"，在仓库眼里是"未到货"，在平台后台是"不存在"，在财务眼里是"已付款"。四套口径喂给同一个算法，再准的公式也只会算出四个不同的答案。
所以实施的第一步不是配置算法参数，而是把"什么是可用库存"这件事定义清楚，并且让所有角色认同同一个定义。
很多团队的ERP实施顺序是：选型 → 上线 → 导数据 → 调参数。这个顺序有个致命问题：参数是在错误的账目基础上调的，越调越偏。
我建议的顺序是三步：先把账做对（主数据与库存口径统一），再把规则定清楚（补货触发、采购提前期、服务水平），最后才处理分配（哪个仓补哪个店、能不能跨店共享）。分配是最后一步，因为它依赖前两步的准确性。
行业里流行一句话："先选一个店铺跑通全流程，再复制到其他店。"这句话在单店业务上是成立的，但在多店采购补货场景里，我认为它是错的。
原因是：多店采购补货最大的价值来自共享库存池，而共享池是跨店逻辑，不是单店逻辑。如果你先用单店跑通，采购提前期、安全库存、补货点这些参数都会按单店口径设定；等到打通多店时，这些参数全部要推翻重来，前期的"跑通"变成了沉没成本。
我的建议是：跑通"一个共享库存池 + 两个店铺"的最小闭环，而不是"一个店铺的全流程"。两个店就够了，因为两个店才会暴露库存抢占、优先级排序、分配规则这些真正的问题。
抽象地说"多店更复杂"没有意义。我把实际项目里反复出现的四个场景写出来，你可以对照自己的团队看看中了几个。
有个卖家的三个亚马逊店铺共用同一个第三方海外仓。某个SKU总库存600件，A店后台显示可售600，B店后台也显示可售600，C店同样。三个店加起来"可售1800件"，实际只有600件。
结果是一次促销活动，三个店总共卖出了900多件，其中300多件无法履约。这不是库存不足的问题，是库存视图的问题，每个店看到的都是同一个池子的全量，而不是分配给自己的那一份。
这类问题在只有一两个店时不会暴露，因为运营会凭记忆避让；一旦超过三个店，靠记忆就无法覆盖了。
我见过最夸张的一次，是某卖家的采购部门在同一天向同一个供应商发了三张采购单，采购的是同一款产品，数量分别是200、150、300。
原因很简单：三个店铺的运营各自发现库存偏低，各自提了补货需求，而采购员是按需求单执行的，不掌握全局在途情况。当采购动作由"店铺需求"驱动而不是由"共享池库存"驱动时，重复采购是必然结果。
除了资金占用，这类重复采购还会带来一个隐性成本：供应商会认为你的需求预测能力弱，在旺季议价时你会更被动。
这是最普遍、也最容易被低估的问题。在途库存，尤其是头程在途、海外仓中转在途、FBA入仓中不可售，在很多团队里是以"微信群消息"和"货代给的Excel"形式存在的。
我做过一次抽样：在某卖家涉及的120个补货决策里，有37个决策没有把已确认在途计算进去，占比超过30%。这37个决策里，有11个直接导致了重复下单。
在途库存是补货公式里最容易被省略、但对结果影响最大的一项。因为它同时具备两个特征：金额大、时效不确定。而人工记忆对"不确定的东西"天然低估。
很多团队上线ERP之后，补货参数是"设一次用一年"。他们把采购提前期设成30天，安全库存设成一个固定值，然后就不管了。
但跨境业务的提前期波动极大：平时海运35天，旺季可能50天；平时清关3天，旺季可能10天。提前期一波动，原有的补货点全部失效，表现出来就是"该补的时候没补，不该补的时候压了一堆货"。
补货参数不是配置项，是需要按季度回看的管理动作。这一点后面在阶段五会展开。
把上面四个场景归纳一下，多店采购补货的复杂度不是由店铺数量单一决定的，而是四个因子的乘积：店铺数 × 平台数 × 仓库数 × 履约模式数。
3个店铺、1个平台、1个仓、1种履约模式，复杂度是3。7个店铺、3个平台、4个仓、3种履约模式（FBA/海外仓自发/国内直发），复杂度是252。差了两个数量级，但团队规模可能只增加了两个人。
下面这些误区，我在项目里几乎每次都会遇到至少三四个。它们有一个共同特征：看起来都是"操作细节"，实际上每一个都会让整套补货逻辑失效。
最典型的期待是："我上了系统，系统就会告诉我每个SKU补多少。"这个期待本身没有错，错在忽略了前置条件。
系统能算的前提是：它知道你有多少货、在途多少、每天卖多少、多久能到。这四件事里任何一件不准，输出就没有参考价值。所以ERP真正的价值不是"给出答案"，而是"让答案可被验证"，你能追溯到某个补货建议是基于哪些数据算出来的。
我见过太多项目，数据初始化阶段只导入了SKU清单和某一天的库存快照，然后就急着上规则。
但补货需要的历史数据至少包括：过去90-180天的分店铺销量、过去6-12个月的历史采购单和到货记录、供应商的交付准时率、头程各渠道的实际时效分布。没有历史数据的安全库存，就是在拍脑袋。
安全库存的作用是应对需求波动和供应波动，而这两个波动在不同店铺、不同平台上差异巨大。A店的爆款是B店的滞销款，用同一个安全库存值，等于对两个店都不负责。
我通常建议安全库存至少按三个维度分层：SKU的ABC分类、平台履约时效、仓库到货稳定性。一个A类爆款在FBA渠道和一个C类长尾在自有海外仓，安全库存的逻辑完全不同。
前面场景三里已经说过，这里再强调一次它的技术原因：在途库存的采集难点不在系统，在于数据源分散在采购单、货代、清关代理、平台后台四个地方，且更新频率不一致。
如果实施时不解决"谁负责在多长时间内更新在途状态"这个问题，系统里的在途字段很快就会被填上假数据，最后所有人都不再信任它。
常见的两种极端：一种是全集中，所有采购由总部一个人审批，运营提需求要等两天；另一种是全放开，每个店长自己下单，月底财务发现同一个供应商被下了七张单。
正确的做法是按"金额 + SKU属性"做分级授权，而不是按岗位一刀切。这一点在第五节阶段四会给出具体的设计方法。
因为采购补货是"最痛"的模块，很多团队会优先上线它。但如果库存口径没统一，采购模块拿到的可用库存是错的，采购建议也就是错的。
我的判断是：库存口径统一是采购补货模块的前置依赖，不是并行任务。顺序颠倒，采购模块上线后会被业务方判定为"不好用"，然后被弃用，这种"上线即废弃"的情况我见过不止三次。
有些团队希望一次性把采购、库存、财务、广告、客服全部上线。结果是每个模块都只做了70%，而采购补货需要的是库存、在途、销量三个模块都做到95%以上才能算准。
模块之间有依赖关系，依赖关系决定了上线顺序，而不是"哪个看起来更急"。采购补货的依赖树很短但很深：主数据 → 库存 → 在途 → 销量 → 采购建议。
ERP项目最危险的时刻，是上线后的第一个月。这时候所有人都在庆祝，没人去核对补货建议的准确率。
我的经验是：上线后前8周的校准工作量，至少等于实施期总工作量的30%。如果预算和人力没有为这一段留出空间，项目大概率会在三个月后回退到Excel。
这个误区比较隐蔽，但杀伤力很大。补货准确率本质上是"数据质量 + 参数合理性 + 采购执行"三者的联合结果，采购员只能控制最后一环。
如果把它压给采购员，理性的应对方式就是"少补"，因为缺货的责任会被归因到运营，而压货的责任会落在采购身上。指标设计不当，会系统性地引导团队做出对企业不利的选择。
梳理完误区，接下来是我认为最核心的部分，判断顺序。补货决策不是一个公式，而是五个层次的判断串联。顺序错了，后面的判断全部失去意义。
这是多店场景下最独特、也最容易被跳过的一层。在单店逻辑里，库存就是库存；在多店逻辑里，库存必须先回答"归谁"。
我用的判断框架是三个变量：平台独占性、销量波动性、库存占用金额。
反过来，独占性低、波动性低、金额低的SKU，可以完全共享，甚至可以完全不设安全库存，用现货率驱动。
这是我要求所有客户必须写进文档的一条定义。可用库存不等于在库数量，它是一条减法链：
可用库存 = 实物在库 + 已确认在途 − 已分配未发货 − 平台不可售 − 预留安全库存
每一项都有陷阱。"已确认在途"必须区分"已发货在途"和"已下单未发货"；"平台不可售"包括FBA入仓中、被冻结、被预留；"预留安全库存"在多店场景下需要按店拆，而不是全局一个数。
我把这条链子做成瀑布图，是因为它在实际沟通中最有效，当采购和运营争"到底有多少货"时，把这张图摊开，争论会立刻变成对某一项的核对。
补货触发有三种方式，适用场景完全不同：
我的建议是三种方式并行，按ABC分类分配：A类用补货点触发为主 + 预测校验，B类用固定周期触发，C类可以用固定周期 + 人工批量确认。
权限问题不是管理问题，它会直接影响补货时效和采购成本。我通常用两个维度切分：SKU是否跨店共享、单次采购金额。
共享SKU的采购权应该集中在总部，因为集中采购才能合并批量、拿到更好价格、避免重复下单。非共享SKU（平台定制款）的采购权可以下放到店铺，因为这类SKU的需求判断运营比总部更准。
金额维度上，我一般建议：小额（比如单次低于5000元）授权到运营主管，中额到大区负责人，大额到供应链总监。具体金额线要按自己的毛利和现金流定，不要照搬。
这是最容易被忽略、但影响最大的一层。补货本质上是"用库存成本买断货风险的降低"，这两者是对立关系。
服务水平从95%提到98%，看起来只提升了3个百分点，但对应的安全库存会增加约24%（Z值从1.65升到2.05）。这3个百分点的断货率降低，值不值得多压24%的库存，取决于这个SKU的毛利率和断货的可恢复性。
高毛利、断货后会永久流失客户的SKU，值得买高服务水平。低毛利、断货后可以等下次补货的SKU，就应该接受更低的服务水平。
把这五层串起来，你会发现补货决策其实是一条链：先判断能不能共享 → 再算准可用库存 → 再选触发方式 → 再定谁有权采购 → 最后定服务水平目标。前四层做对，第五层才有意义。
如果想用一张图看SKU的分布，我通常会用气泡图把SKU按"平台独占性"和"销量波动性"铺开，气泡大小代表库存占用金额。这样一眼就能看出哪些SKU应该共享、哪些必须独立。
前面讲的是判断逻辑，这一节讲落地的顺序和时间。我按实际项目经验给出五个阶段，每个阶段都标注了产出物，因为没有产出物的阶段等于没做。
这个阶段看起来最枯燥，但它决定了后面四个阶段的成败。核心工作是三件事：
产出物：SKU映射表、仓库主数据表、可用库存口径说明书。没有这三份文档就进入下一阶段的项目，我基本可以预判它会返工。
这个阶段解决"数据从哪来"的问题。三件事：
这个阶段最容易被低估的是平台数据同步的时效性。不同平台的库存更新延迟从几分钟到几小时不等，如果不了解这个差异，多店共享库存池会出现"卖超"的假象。
这个阶段开始碰参数。我的建议是按"先粗后细"的顺序配置：
关键原则：先给A类SKU精细配置，B类用粗参数，C类可以用规则批量处理。试图给400个SKU都做精细配置，项目会无限延期。
补货点 = 日均销量 × (供应商交付期 + 头程运输期 + 入仓上架期) + 安全库存
安全库存 = Z值 × 需求标准差 × √提前期
建议采购量 = (目标覆盖天数 × 日均销量) – 可用库存 – 在途库存
（结果
这三个公式本身不复杂，难点全在输入项。日均销量要不要剔除促销日？需求标准差按哪个窗口算？在途库存是否包含已下单未发货？每一个问题都需要团队自己给出答案，并且写进文档。
这是多店场景独有的阶段，也是区分"能用"和"好用"的分水岭。核心要解决三个规则：
这里有个实操经验：调拨规则的复杂度往往被高估，使用频率往往被低估。我见过不少项目把调拨规则设计得非常精细，结果实际使用率不到5%。原因是调拨需要跨仓操作和额外运费，运营倾向于用采购来解决问题。
试运行的对象选择很重要。我的建议是：选一个共享池 + 两个店 + 50个左右的SKU，其中包含A类、B类、C类各若干，跑满一个完整的采购周期。
试运行期间要盯三个数字：补货建议采纳率、缺货率变化、库存变化。如果建议采纳率低于60%，说明参数或数据有问题，不要急着扩大范围。
上线后的校准节奏我一般建议：前8周每周校准一次，第3-6个月每月一次，之后每季度一次。校准的重点是采购提前期的实际分布和安全库存的命中率。
上面讲的是方法论。具体到工具层面，我拿一个实际的平台举例，说明它在多店采购补货这件事上解决了哪些环节、哪些环节仍需要人工判断。这里以数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）为例，它属于跨境电商数据与经营管理类平台，主要服务多平台、多店铺的卖家。
多店采购补货的第一个卡点，是没有一个地方能把所有店的库存和销量放在一起看。数跨境这类平台的第一层价值就在这，把不同平台、不同店铺的数据归集到同一套主数据体系下。
这一步对应的正是我前面说的"阶段一：主数据与口径统一"。工具能帮你做映射和归一，但映射规则本身需要你来定：哪些平台SKU合并成一个主SKU、合并之后以谁的数据为准，这是业务决策，不是系统功能。
在数据归集和库存口径统一之后，补货建议才有意义。我在实际使用中比较看重的不是"它算得准不准"，而是它能不能让我看到建议是怎么算出来的，用了哪段区间的日均销量、把哪些在途算进去了、安全库存取了多少。
这一点很重要。因为补货建议的首要价值不是"直接执行"，而是"减少核对时间"。当采购员能一键看到依据，他才有信心采纳；当依据不可见，他只能回到Excel自己再算一遍。
下面这组数字来自我接触过的几个类似规模卖家的样本推演，属于示意数据，不代表任何平台的官方效果承诺，也不是真实统计。放在这里是为了说明各个指标的变化方向。
样本设定：7个店铺、3个平台、4个仓库、约400个在售SKU，实施前后各观察3个月。核心变化是补货人工工时从每周约22小时降到约8小时，超卖次数从月均4次降到月均1次，在途重复下单从月均3次降到0.5次。
值得注意的是库存周转天数的变化幅度最小（从62天降到54天）。这符合我的经验判断：补货系统的最大收益是"减少错误"和"释放人力"，库存优化是滞后收益，通常在6个月后才明显。如果有人告诉你上线一个月库存周转就能翻倍，那基本可以判断是在夸大。
方法论讲完了，最后要给的是分档建议。因为一个年GMV 80万的卖家和年GMV 8000万的卖家，做法应该完全不同。下面四档是我的实际建议。
这个阶段的店铺数通常不超过3个，SKU不超过200个。我的建议是先把Excel的补货表做成有公式的版本，而不是急着上ERP。
原因很直接：这个体量下，补货的准确率主要取决于你对产品的理解，而不是数据精度。上系统的实施成本（时间成本）可能比它带来的收益更大。
这个阶段真正该做的三件事：建立SKU主数据的命名规范、记录每一批货的实际到货时间（积累提前期数据）、把在途单独列一列。这三件事做完，未来上系统的数据基础就有了。
这个阶段的典型特征是店铺数在3-8个，开始出现明显的重复采购和超卖问题。我的建议是分两步走：
这个阶段最容易犯的错，是直接跳到第二步。我见过太多团队买了系统、导了数据、配了参数，然后发现可用库存是错的，整个项目停摆。
这个阶段的店铺数通常在8-25个，平台3个以上，仓库3个以上，复杂度乘积已经很大。此时必须走完五个阶段，而且阶段四（多店分配与调拨）是决定成败的关键。
这个阶段还有一个特殊任务：把采购权限体系正式化。因为组织规模到了这个程度，"谁有权下单"已经不能靠默契解决，必须有明确的金额线和SKU属性分级。
另外，这个阶段应该开始培养内部的"系统管理员"角色，不是IT，而是懂业务、能配参数、能做校准的人。这个角色往往决定了系统上线后能活多久。
这个阶段单一系统很难覆盖全部需求，通常是ERP + 数据平台 + 财务系统的组合。此时的重点从"把账做对"转向"如何不让系统之间产生新的口径差异"。
我的核心建议是：指定唯一的主数据权威源。SKU以哪个系统为准、库存以哪个系统为准、采购以哪个系统为准，必须明确。多系统并存最大的风险不是数据不互通，而是每个系统都认为自己是权威。
实施路径里必然遇到取舍。下面五组是我在项目里被问得最多、也最容易争论不休的。我给出自己的判断倾向，但结论要结合你的具体情况。
这个问题的答案取决于你的业务有多少"非标"。如果你的采购模式、仓库结构、平台组合都相对常规，标准产品能覆盖80%以上，自研的投入产出比通常不划算。
但如果你的业务有强特殊性（比如自有工厂、定制生产、多级分销），标准产品的改造成本可能超过自研。
我的判断标准是：如果标准产品需要改动的核心流程超过3个，就要认真考虑自研或深度定制；否则优先用标准产品。因为自研的隐性成本主要不在开发，而在后续维护和人员依赖。
集中采购的优势是批量议价、避免重复下单、库存可共享；劣势是响应慢、对区域需求不敏感。分散采购正好相反。
我的建议是按"是否共享"来切：共享SKU集中采购，非共享SKU（平台定制、区域特供）分散采购。这个切分方式比"按店铺"或"按品类"更符合库存逻辑。
还有一条经验：集中采购的前提是信息集中。如果总部看不到各店的真实需求和在途情况，集中采购会变成"瞎指挥"，反而比分散更糟。所以集权之前，先把数据打通。
很多团队希望一步到位做全自动。我的建议是至少在前6个月保留人工确认环节。
原因不是不信任系统，而是补货决策涉及的变量太多（推广计划、竞品动作、平台政策、供应商产能），这些变量短期内很难全部结构化。人工确认环节的作用是提供一层"业务常识"的校验。
更重要的是，人工确认的过程本身就是校准过程。采购员每次否决建议时，都会给出一个理由；把这些理由收集起来，就是参数优化的输入。如果直接全自动，这些信息就丢失了。
这个取舍的本质是提前期和资金占用的权衡。补海外仓提前期长（通常30-60天），但能做到快速履约；补国内仓提前期短，但直发时效差、转化率低。
我的判断逻辑是：按SKU的确定性来分。销量确定性高、复购稳定的SKU，优先补海外仓，用长提前期换低履约成本；销量确定性低的新品，优先走国内仓或小批量海外仓试水，用高履约成本换低库存风险。
这个判断在旺季前尤其重要，因为旺季的头程时效会进一步拉长，如果不提前做这个分类，很可能出现"爆款断货、新品压仓"的局面。
平台原生工具的优势是数据准确、无同步延迟、成本低；劣势是只覆盖单一平台，跨平台的多店共享做不了。
我的建议是两者并用，分工明确：平台原生工具用于店内的库存监控和广告联动，第三方ERP用于跨平台的主数据统一、共享库存池管理和采购补货。这样既保留了原生工具的数据准确性，又解决了多店协同问题。
需要注意的是，两者并用会引入新的对账工作。必须明确"以谁为准"，否则运营和采购又会陷入"到底看哪个数字"的争论。
项目上线后如果没有衡量体系，很快就会失去方向。我这里给出四个核心指标和两个反指标，前者用来判断做得好不好，后者用来防止做过头。
库存周转天数 = 平均库存金额 ÷ 日均销售成本。这个指标反映资金效率，是补货系统最常被引用的指标。
但要注意两点：一是要区分"总库存周转"和"可售库存周转"，把在途和滞销库存剔除后的数字才有意义；二是这个指标有季节性，旺季前必然升高，不能简单环比。
我通常建议按季度看，并且和去年同期对比，而不是和上个季度对比。
断货率 = 断货SKU天数 ÷ 应有可售SKU天数。这个指标反映的是销售机会的损失，往往比库存指标更直接影响业绩。
计算断货率时，最容易被忽略的是"部分断货"，SKU还有货但不足以支撑正常销售速度。我建议把"可售天数低于7天"也纳入观察范围，作为预警而非断货。
这个指标衡量的是系统与业务的信任关系。采纳率 = 被采纳的补货建议数 ÷ 总补货建议数。
采纳率低于60%时，问题通常不在采购员，而在数据或参数。此时应该做的是抽查被否决的建议，看是哪个输入项有问题，而不是施压提高采纳率。
很多团队只记录平均提前期，不记录方差。但方差才是安全库存的真正驱动力，提前期波动越大，需要的安全库存越高。
我建议按月统计各渠道提前期的P50和P90。如果P90和P50的差距在扩大，说明供应链稳定性在下降，安全库存应该上调，而不是维持原值。
降低库存有一个极限，就是断货率开始上升的那个点。库存持有成本占销售额比重这个指标，用来防止"为了周转率而过度压缩库存"。
如果这个指标持续下降但断货率在上升，说明你正在用销售机会换报表好看，这是得不偿失的。
呆滞库存指超过一定天数（比如180天）未产生销售的库存。这个指标反映的是补货决策的历史错误，而不是当前问题。
我建议把它作为季度复盘的核心输入：每一个呆滞SKU背后都对应一次错误的补货决策，找出这些决策的共性，才是真正的优化方向。
最后强调一点：这四个核心指标之间存在结构性权衡。库存周转天数下降通常会让断货率上升，服务水平的提升必然推高库存占用。
所以正确的做法不是"每个指标都做到最好"，而是确定一个主目标（通常是断货率或库存成本），其他指标作为约束条件。这个主目标应该由业务阶段决定，扩张期优先保断货率，收缩期优先保周转。
回到最开始那个案例。那家7店卖家的项目最后用了大约10周完成主体上线。但真正让补货准确率稳定下来的，是上线后第4个月的一次全面校准，他们发现头程实际时效比系统里配置的长了整整9天，修正之后，缺货率在两周内下降了近一半。
所以我一直认为，ERP采购补货模块的价值不在于它多"智能"，而在于它把原本散落在人脑、微信群、Excel里的口径和规则，变成了一份可核对、可追溯、可迭代的文档。
多店经营的采购补货，本质上是把一个共享资源的分配问题，从"靠默契"变成"靠规则"。系统只是这份规则的载体，规则本身的对错，还是要靠业务判断。
如果你正准备启动这件事，我的下一步行动建议是这四条：
采购补货是ERP实施的"第一公里"，因为它直接连着现金流；它也是最长的校准路，因为市场、供应链、平台规则一直在变。把它当成一次性的项目，它就会一次性失效；把它当成一个需要持续维护的经营机制，它才会持续产生收益。
我现在手上4个店，亚马逊两个、Shopee一个、TikTok Shop一个，采购补货全靠一张Excel表加人工盯库存。老板天天催我上ERP，但我觉得流程自己都没跑顺，怕上了系统更乱。到底该硬着头皮上，还是先把Excel用明白？
可以过渡，但要设一个明确的『退出条件』，不能无限期拖。判断标准是三条：一是SKU超过300个或店铺超过3个，Excel的跨店库存汇总会开始频繁出错；二是补货决策依赖的字段超过8个（在途、安全库存、日均销量、采购周期、MOQ、头程时效等），人工维护成本会指数上升；
三是一个月内出现过2次以上因数据不同步导致的超卖或断货。满足任意两条，就该启动ERP的采购补货模块。过渡期建议把Excel做成『准系统』：固定字段结构、固定更新频率（比如每天上午10点前更新在途和销量）、固定责任人，这样迁移到ERP时数据初始化会快很多。
反过来，如果SKU不到100、店铺只有2个、补货周期稳定，Excel完全够用，强行上ERP反而增加负担。
我们做的是同一批货同时在亚马逊和独立站卖，有时候亚马逊爆单把库存吃光了，独立站还在正常出单，结果超卖被投诉。但也有人说库存共享会互相拖累，一个店卖不动把另一个店的可用库存也占了。到底该怎么设？
没有标准答案，取决于你的履约结构。如果各平台用的是同一个海外仓或同一个FBA仓发货，就应该用『物理库存共享、逻辑库存分配』的方式：在ERP里设一个总库存池，但给每个店分配一个可用库存上限或比例，比如亚马逊占60%、独立站占40%，任一店铺超卖时系统自动从其他店的可用额度借调。
如果各平台是分开备货、分仓发货，那就必须独立库存，否则调拨成本会把利润吃掉。实操上建议分两步走：扩张初期（店铺少于5个、SKU集中）用共享池加比例分配，简单有效；店铺超过5个或品类分化明显后，切换为『共享总仓+分店安全库存』模式，每个店保留自己的安全库存线，超出部分才进入共享池。
关键判断依据是：你的货能不能低成本地在店铺之间调拨，能就共享，不能就独立。
我们公司现在是运营自己提采购需求，采购部统一下单，但问题是我负责的店铺经常被采购部压单，说我这个品类量太小优先级低。店多了以后，到底谁该有采购决定权？我不想每个店都各自为政，但也不想被总部卡死。
建议按『金额+频次』做分层授权，而不是一刀切。具体做法：单次采购金额低于某个阈值（比如5000元）且属于高频常规补货的，由店铺运营直接发起、系统自动审批；超过阈值的或新品类首次采购，走总部集采审批。这样既保证小批量补货的效率，又控制大额采购的风险。
在ERP里的配置方式是：给每个店铺角色设采购发起权限和金额上限，审批流按金额自动路由，小额走运营主管，大额走供应链负责人。判断依据是：如果你的品类之间关联度高（比如都是同一供应链的延伸），集采能拿到更好的价格和账期；如果品类差异大、各店选品逻辑独立，分店自主采购反而更灵活。
混合模式的关键是定期复盘：每月看各店的采购及时率和大额采购占比，及时率低于80%就说明授权额度太小，需要上调。
我们刚上完ERP的采购补货功能，老板问我效果怎么样，我只能说『感觉比以前顺了』，但拿不出具体数据。系统里报表一大堆，我不知道该看哪几个。有没有一套简单直接的衡量口径？
用四个指标做前后对比就够了，不需要看所有报表。第一，库存周转率：上ERP前后各取3个月的月均数据，计算口径是『月均销售成本÷月均库存成本』，提升幅度低于10%说明补货参数还没调准。
第二，缺货率：统计有销量但库存为0的SKU天数占比，健康值一般控制在5%以内，高于10%说明安全库存设太低或补货触发太晚。第三，补货准确率：系统建议补货量与实际最终采购量的偏差率，偏差超过30%说明预测模型的历史数据不够或参数不合理。
第四，采购周期：从『系统生成补货建议』到『采购单确认下单』的平均天数，这个指标直接反映流程效率，一般应该控制在2天以内。建议以季度为单位做趋势对比，不要看单月数据，因为采购有周期性波动。如果四个指标中至少三个在改善，说明实施方向正确，剩下一个可以针对性优化；
如果两个以上没变化，要回头检查数据初始化和规则配置是否有遗漏。
读者评论
作为7个亚马逊店加TikTok的卖家，文章里三个库存数字对不上的场景太真实了。我们采购和运营天天扯皮，后来发现就是可用库存定义没统一。先跑两个店共享池这个建议，比先跑通一个店合理，单店参数到多店确实要推翻重来。在途靠微信群对账我们也中招，看完准备先整理在途数据源。
做ERP实施顾问几年，最怕客户上来就问补货算法准不准。这篇文章把顺序讲对了：账→规则→分配。主数据和库存口径不统一，再好的算法也是放大错误。上线后前8周校准占30%工作量这点很实在，但多数项目预算根本没留，三个月后回Excel是常态。建议客户先看口径不一致SKU占比再决定上系统。
采购主管视角：同一天给同一供应商下三张单，我们真干过。文章说采购动作由店铺需求驱动而非共享池库存驱动，一针见血。安全库存全店一个数也是老毛病，A店爆款B店滞销却用同个值。不过按金额加SKU属性做分级授权，执行时老板不放权，运营还是各下各的，这点文章没展开怎么落地。