很多跨境电商团队选 ERP 的顺序是反的：先让服务商发一份功能清单，把订单、库存、采购、刊登、财务、BI 的勾选项逐个对比，再按报价和演示效果拍板。上线三个月后才发现，真正卡住业务的不是缺某个功能,而是选品方式决定了主数据长什么样、供应链节奏有多快、财务对账有多碎,而这些问题在功能清单里根本看不出来。
我做过六年跨境卖家的数字化顾问，前后参与过二十多次 ERP 选型和替换。有一个反复出现的规律：选品策略越清晰，ERP 实施边界就越清晰；选品策略越模糊，ERP 上线就越像在赌。铺货团队的 SKU 是几千上万条、生命周期只有几周，精品团队是几十条 SKU、一条链路要养三年，这两种业务放在同一套功能清单里比较，本身就是错的。
这篇文章不复述 ERP 定义，也不做服务商推荐。我会用自己踩过的坑，讲清一件事：先用选品策略判断业务复杂度，再倒推 ERP 的实施范围、模块优先级和上线节奏。文中的成本区间、处理耗时、字段量级来自我对服务商报价单、实施排期表和卖家后台导出的观察总结，涉及具体金额的属于样本推演区间，请以你实际拿到的报价为准。
如果只让我留一句话给正在选 ERP 的团队，就是这句：ERP 不是按功能多少来选，而是按你的选品打法需要什么数据、什么流程、什么集成来选。选品策略决定了 SKU 结构、采购频次、库存分布、履约方式和结算复杂度，这五个变量又直接决定 ERP 哪些模块必须做深、哪些可以后置、哪些干脆不做。
功能清单是静态的，它只能回答“系统能不能做这件事”；选品策略是动态的，它回答的是“你的业务每天会产生多少条数据、多快的变化、多碎的对账”。我见过一家做家居铺货的团队，选 ERP 时最看重的是多平台刊登功能，上线后第一个月就崩在库存同步上，他们每天有 300 到 500 条 SKU 上下架，库存扣减规则没定清楚，超卖率一度到 4%。
第二个原因是，功能清单无法反映流程冲突。铺货团队习惯“先上架、后补货”，精品团队习惯“先备货、后动销”，这两种节奏对应的采购单审批流、头程计划、库存预警阈值完全不同。同一套 ERP，配置方式错了，功能再全也跑不通。
我把这套判断压缩成一个可以贴在会议室白板上的公式，它不精确，但能快速统一团队认知：
ERP 实施范围 =（SKU 宽度 × 生命周期变化速度）+（采购前置期复杂度）+（结算主体数量）+（履约节点数量）
四项里任何一项被低估，实施周期就会膨胀。SKU 宽度决定主数据建模难度，生命周期变化速度决定刊登和库存策略，采购前置期决定计划和头程模块的必要性，结算主体和履约节点决定财务模块的复杂度上限。
下面三个场景都出自我实际参与过的项目，为保护客户信息，业务数据做了区间化处理，但问题的结构和决策失误的过程是真实的。我讲它们不是为了吐槽，而是因为每一种失误都对应一个选品策略没有想清楚的环节。
这家团队做欧美站点家居类目铺货，在售 SKU 大约 8000 条，旺季一个月上下架能到 2000 条以上。他们最初的需求非常明确：要一个能快速批量刊登、批量改价的工具。选型时演示环节全在讲刊登效率，库存和采购模块只看了十分钟。
上线后的第一个旺季，问题集中爆发。他们的库存同步是半小时一次，但促销期间订单集中在两个小时内，结果同一批货被卖出三次，超卖率达到 3.8%，退款和差评直接拉低了店铺评分。复盘时发现，真正的瓶颈不是刊登不够快，而是库存扣减规则、安全库存阈值、平台同步频率三者没有和选品节奏对齐。
铺货型选品的核心特征是高频测品、快速淘汰，这要求 ERP 的库存模块必须支持“低安全库存 + 高频同步 + 自动下架”的组合，而不是简单地把库存字段同步到平台。
如果让我重做这个项目，我会把库存同步和自动下架放进第一阶段验收项，刊登批量操作反而可以放在第二阶段，因为刊登效率低只是慢，库存不准是直接亏钱。
第二家是做小家电精铺的，SKU 控制在 150 条左右，每季度测 20 到 30 个新款。他们在选型时被服务商的“智能采购计划”“销量预测”“自动补货”打动，采购了包含高级计划模块的版本，年费比基础版高出约 40%。
结果上线半年，采购计划模块的使用率不到 20%。原因是他们的测款逻辑本身就依赖运营的经验判断和小批量试单，预测模型给出的建议和他们的实际决策经常冲突，最后运营干脆绕过系统，回到 Excel。这就是典型的“功能超过业务成熟度”，系统能力可以领先，但领先太多就会变成负担。
他们最缺的其实是刊登批量管理、多平台订单归集和单款毛利分析，因为 150 条 SKU 需要精细算出每款的广告、物流、退货成本，而这三块他们当时是靠人工拼接报表完成的。
我的经验判断是：当你的单款销量波动可以被至少一个季度的数据解释，且备货前置期超过 45 天时，采购计划模块才有足够的信息密度支撑决策。否则它只是在替运营做一件运营自己更有把握的事。
第三家是做 DTC 品牌独立站的，SKU 只有 60 多条，但涉及独立站、两个平台店铺、三种币种结算，还接了分期付款和本地钱包。他们的 ERP 选型重点全在履约体验上，财务模块选了基础版。
上线后财务团队每月要花 6 到 8 个人天做手工对账，因为系统无法按支付渠道拆分收款、手续费、退款、拒付四条流水，也无法自动匹配平台结算单。这个成本在选型阶段完全没人算过。独立站卖家的财务复杂度不来自 SKU 数量，而来自支付通道和结算周期的碎片化。
误区之所以有生命力，是因为它们在选型会上听起来非常合理。我把最常见的四个列出来，并说明它们各自的失效场景，这样你在会议室里可以更快识别。
“先买全，以后用得上”，这句话我至少听过三十次。问题在于，ERP 的成本不只是订阅费。多买的模块会带来配置复杂度、培训成本、数据字段冗余，以及最要命的：让真正该先做的事情被稀释。
更现实的判断是，ERP 模块的使用率呈现明显的长尾分布：核心三到四个模块使用率超过 80%，后面七八个模块常年低于 25%。这些低使用率模块不是资产，而是每月都在产生维护决策成本的负债。
这是实施延期最常见的原因。我参与过的项目里，凡是把主数据治理放在上线之后的，平均延期 6 到 10 周，而且延期的部分几乎全在返工。
主数据不统一的具体表现是：同一款产品在不同平台有不同编码，组合装和单品没有父子关系，变体属性命名混乱，头程费用没有归属到 SKU 维度。这些问题在上线前修是流程工作，上线后修是数据灾难。
演示环境是干净的：几十条标准订单、规整的 SKU、没有异常退款。但你的真实业务里有超卖订单、拆单发货、平台罚款、退货二次入库、促销临时改价。
我的建议很具体：在签约前要求服务商用你自己的脱敏数据跑一遍最脏的场景。如果对方拒绝，这本身就是重要信息。
ERP 实施失败的项目里，有一个高度一致的特征：项目负责人只有 IT 或财务背景，没有业务决策权。选品节奏、库存策略、采购审批这些决策必须由业务负责人拍板，IT 负责落地实现。
反过来也成立：如果业务负责人完全不参与，只在下线后验收，那这个项目大概率会在中途失去方向。
这套方法我在多个项目里迭代过，核心思路是把选品策略翻译成系统语言。它不需要你先懂 ERP，只需要你如实回答业务问题。
先确认你属于哪一种，或者更常见的情况是，你在哪几种之间摇摆。摇摆本身就是一个信号：说明你的业务还没有收敛，这时候上的 ERP 大概率要二次改造。
这一步最关键。你需要列出业务里真实存在的数据对象，以及它们的量级和变化频率。下面这张表是我在项目里常用的翻译模板。
| 选品模式 | 核心数据对象 | 典型量级 | 变化频率 | 主数据难点 |
|---|---|---|---|---|
| 铺货型 | SKU、平台映射、库存快照 | 3000-20000 条 | 每日数百条上下架 | 多平台编码映射、批量属性继承 |
| 精铺型 | SKU、测款批次、成本明细 | 100-300 条 | 每季度换代 | 单款成本归集、测款批次追溯 |
| 精品型 | SPU、变体、认证、供应链 | 30-200 条 | 每季度微调 | 变体父子关系、认证有效期 |
| 品牌独立站 | 会员、订单、支付流水、履约节点 | 订单量大、SKU 少 | 实时 | 支付渠道拆分、复购归因 |
集成不是越多越好，而是要判断哪些集成断了业务就停。我通常会问一个问题：如果这个接口今天挂了，业务能撑几天？撑不过一天的接口，必须在第一阶段完成；能撑一周的，可以放到第二阶段。
常见的集成优先级排序（从高到低）：
“上线成功”这句话没有意义，必须换成可量化的验收项。我在项目里要求每个阶段至少有 3 个数字指标，并且由业务方签字确认。
例如第一阶段的最小闭环可以这样定义：
这一步最容易被忽略，但它是控制范围的唯一手段。一份没有“不做清单”的实施计划，等于没有范围。把当前业务成熟度支撑不了的模块明确写下来，约定在什么条件下再评估，这比含糊地“后续考虑”要安全得多。
下面我用“数跨境”这个平台作为观察对象，说明选品策略如何具体影响实施配置。数跨境的官网是 https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys ，它主要面向跨境电商卖家提供数据与经营分析相关能力。我把它放进案例，不是因为要做推荐，而是因为它的产品结构恰好覆盖了从选品数据到经营分析的一段链路，适合用来演示“数据对象先行”的判断方法。
大多数团队把选品和 ERP 当成两件事：选品用一套工具，ERP 用另一套，中间靠 Excel 或人工搬运。这种做法的隐性成本在 SKU 数量超过 500 条之后开始急剧上升。
具体表现是：选品阶段判断的爆款潜力、测款数据、竞品价格带，和 ERP 里的采购成本、库存周转、实际毛利是两套口径。等到要复盘某款为什么失败时，你拿不出一个贯穿的数据视图。选品和 ERP 之间如果只靠人工搬运，你的经营分析永远滞后一个季度。
从数跨境这类数据平台的使用逻辑看，它的价值在于把平台端的数据先规范成可分析的结构，再输出给决策环节。这个思路对 ERP 选型有直接启发：先确定数据从哪里来、以什么粒度聚合、多久更新一次，再决定 ERP 需要接收什么。
如果选品判断依赖平台侧的销量、价格、评论、类目数据，那么 ERP 侧必须能接住这四类数据的映射关系，否则选品结论落不到执行层。
这是最低层也是最容易被忽略的一环。一个平台商品可能对应一个内部 SKU，也可能对应组合 SKU，还可能在换供应商后变成新 SKU。映射关系没定清楚，后面的库存、成本、毛利全部错位。
选品分析通常看 7 天、30 天销量趋势，ERP 的库存和采购计划可能按周或按批次计算。两边的粒度不一致，就会出现“数据显示在涨、系统显示该补货”这类矛盾。我的做法是在实施文档里明确写出每个指标的计算粒度，不允许含糊。
选品阶段常看的是平台售价和竞品价格，但 ERP 里必须回答的是到手成本，包括采购价、头程分摊、平台佣金、广告摊销、退货损耗。这两套口径如果不打通，你会得到“看起来赚钱、算下来亏损”的款。
选品阶段有“待测、测款中、主推、淘汰”这些状态，ERP 里有“在售、停售、清仓”。如果不做映射，运营和采购对同一个款的认知会不一致，直接表现为该停的没停、该补的没补。
我参与过一个从铺货转向精铺的团队，他们在售 SKU 从 4000 条收缩到 260 条，同时开始用数据平台辅助选品。这个转型对 ERP 配置的影响非常典型，我把它整理成对照表。
| 配置项 | 转型前（铺货） | 转型后（精铺） | ERP 侧需要改动的地方 |
|---|---|---|---|
| 刊登策略 | 批量模板、自动改价为主 | 人工审核、精细化描述 | 刊登字段增加审核状态与版本记录 |
| 库存策略 | 低安全库存、快速清仓 | 按款设定差异化阈值 | 库存预警需支持按 SKU 分组配置 |
| 采购节奏 | 高频小批量、随卖随补 | 按测款批次计划备货 | 采购单需关联批次与测款编号 |
| 成本核算 | 按类目粗算 | 按单款精确归集 | 成本项需拆分并支持手工调整留痕 |
| 数据接入 | 平台后台导出为主 | 平台数据与选品工具对齐 | 需明确数据粒度、状态字段映射 |
这次转型最痛的环节不是系统配置，而是采购单和测款批次的关联。转型后他们需要知道每一批货对应哪一个测款批次，才能算出真实测款成本。原来的系统里采购单只有商品和数量，没有批次维度，等于要重新设计数据结构，最后额外花了近三周做字段扩展和存量数据回填。
行动建议必须和你的实际阶段绑定，否则就是正确的废话。我按四种典型情况给出可执行的动作，你可以对号入座。
这个阶段不建议上重型 ERP。你的业务还在找模式，流程随时会变，上一套需要三个月配置的系统，很可能在你还没跑顺之前就已经不匹配了。
更合理的做法是：用轻量的订单和库存管理工具保证不超卖、不漏发，同时把主数据规范好。具体动作包括统一 SKU 编码规则、建立平台映射表、固定成本核算口径。这三件事和用不用 ERP 无关，但决定了你未来换系统时的迁移成本。
这是最典型的精铺区间，也是最值得认真做 ERP 选型的阶段。建议按最小闭环上线，第一阶段只做订单、库存、采购、财务四块，验收通过后再扩展。
选型时重点验证三件事：变体和组合装的处理方式、多平台库存同步的频率上限、单款毛利能不能算准。这三项直接对应你日常最高频的决策。
这个阶段的核心矛盾从功能转向治理。你需要重点考虑的是权限体系、审批流、数据口径统一、多主体核算，以及系统之间的集成稳定性。
建议在实施前先做一次流程盘点，明确哪些流程必须标准化、哪些允许保留差异。多主体运营的团队，财务模块的复杂度会显著高于其他模块，建议单独做一轮需求确认。
过渡期是最容易出问题的阶段，因为两套逻辑同时存在。建议不要在转型中途切换 ERP，而是在转型方向明确后再做系统升级，否则你会同时面对业务不确定和系统不确定。
如果确实需要提前上线，建议先用配置隔离的方式支持两种模式，例如按 SKU 分组设置不同的库存和采购策略，等业务收敛后再做简化。
取舍比建议更难，因为它意味着承认有些事现在做不了。我把常见决策项分成三档，并给出判断依据。
这一档没有商量空间。订单抓取、库存同步、发货回传、采购基础流程、财务基础对账，这五项属于业务地基。凡是缺失会导致超卖、漏发、错算成本的模块，都必须进第一阶段。
判断方法很简单：问一句“这个模块如果三个月不上，会不会造成实际损失”。答案如果是会，就进第一阶段。
智能采购计划、高级 BI 分析、CRM 会员体系、广告投放联动，这些模块价值真实存在，但需要业务成熟度支撑。
我为它们设定了触发条件，供你参考：
这一档最需要勇气。过度定制的审批流、业务还没跑通的自动化规则、为了好看而做的数据大屏，都属于此类。
我的经验是，在 ERP 上做的每一个自动化，都必须先有一段人工稳定运行的记录。你把一个还没稳定的流程自动化，只会让错误更快地被执行。
服务商选择同样需要取舍。功能覆盖度、行业经验、实施团队稳定性、报价结构、退出机制，这五项很难同时最优。
我的建议是把权重放在实施团队稳定性和退出机制上，而不是功能覆盖度。原因是功能可以补，但一个中途换人的实施团队会直接让项目停摆；而没有数据导出和退出条款的合同，会让你在未来失去议价能力。
下面这份清单是我在实际项目中反复使用的版本，按模块分组。建议在演示环节逐条追问，并要求对方给出具体场景下的操作演示，而不是口头确认“支持”。
如果你希望把评估过程标准化，可以用一段脚本把各服务商的关键指标结构化，避免凭印象打分。下面是我在项目中用过的示例结构，字段可按需增删。
# ERP 选型评估表（示例结构，数据需按实际填写）
evaluation = {
"vendor_name": "服务商名称",
"modules": {
模块名: [是否覆盖(0/1), 演示验证打分(1-5), 实施优先级(1-3)]
"order_sync": [1, 5, 1], # 订单同步，必须第一阶段
"inventory_sync": [1, 4, 1], # 库存同步，必须第一阶段
"purchase_plan": [0, 2, 3], # 采购计划，后续评估
"listing_batch": [1, 3, 2], # 批量刊登，第二阶段
"finance_recon": [1, 2, 1], # 财务对账，必须第一阶段
"bi_analysis": [0, 1, 3], # BI 分析，暂不采购
},
"integration": {
"platform_api_rate_limit": "每分钟请求上限",
"stock_sync_interval": "最小同步间隔（分钟）",
"abnormal_scenario_demo": "是否同意用脱敏异常数据演示",
},
"contract": {
"data_export": "是否支持全量导出",
"customization_cap": "定制费用封顶机制",
"exit_clause": "退出与数据迁移条款",
},
}
权重建议：核心流程 0.5 / 集成能力 0.3 / 合同条款 0.2
说明：权重需按自身阶段调整，过渡期团队应提高集成能力权重。
评估表填完只是开始，真正决定成败的是能不能把结论转成有明确负责人、时间点和验收指标的计划。这里建议只保留三列：做什么、谁负责、什么时候验收通过。多出来的列通常没人维护。
这一节讲最容易被低估的部分。软件订阅费只是冰山露出水面的那一角，下面的部分决定了项目真实成本。
根据我接触过的报价单和项目结算记录，ERP 项目的首年总成本中，软件订阅通常只占 30% 到 40%。其余部分包括实施服务费、接口开发费、数据迁移与清洗费、培训费、以及业务停摆带来的机会成本。
| 成本项 | 典型占比 | 说明 | 是否常被低估 |
|---|---|---|---|
| 软件订阅 | 30%-40% | 按模块、用户数或订单量计费 | 否，报价单最显眼 |
| 实施服务 | 20%-30% | 按人天计费，范围变更会追加 | 中等，通常低估 30% |
| 接口开发 | 10%-20% | 非标准平台或自建系统对接 | 是，常按 0 预算处理 |
| 数据迁移与清洗 | 8%-15% | 含主数据规范、历史数据回填 | 是，几乎总被低估 |
| 培训与切换期损耗 | 7%-12% | 含并行期人力、效率下降 | 是，极少被列入预算 |
失败通常不是突然发生的，而是有一串可以观察的信号。以下六个信号来自我参与过的失败项目复盘。
第一，分阶段验收与付款绑定。每个阶段设置明确的量化验收指标，通过后再支付下一阶段费用。
第二，数据所有权与导出格式明确。约定退出时提供完整数据导出，格式为通用格式，并说明导出所需时间和费用。
第三，变更管理机制。明确需求变更的计费方式、审批流程和封顶比例，避免范围无限扩张。
有三种情况我建议先不上重型系统：一是业务模式还在频繁切换；二是核心流程还没有稳定的负责人；三是团队规模小于 10 人且没有专职运营支持。
这三种情况下，先解决业务和组织问题，比上系统更有效。ERP 会放大你已有的秩序，也会放大你已有的混乱。
回到最开始那个反常识的判断：选 ERP 不该从功能清单开始。功能清单回答的是系统能做什么，而你需要回答的是业务需要什么、什么时候需要、需要到什么程度。这三个问题的答案，全部藏在你的选品策略里。
我在这篇文章里反复强调的几个判断，其实指向同一件事：先定选品打法，再定系统边界；先跑最小闭环，再扩展集成；先确认不做清单，再谈功能覆盖。这三句话看起来简单，但在我参与的项目里，能做到的团队不到三成。
如果你正在选型，下一步可以按这个顺序行动。第一步，用第四节的方法给自己的选品模式定性，并列出核心数据对象和量级。第二步，用第八节的问题清单，约两到三家服务商做场景化演示，重点是让他们用你的脱敏数据跑异常场景。第三步，用第九节的成本结构做一份包含隐性成本的预算，给自己留出 20% 到 30% 的浮动空间。
最后提醒一句：不要指望一次选型就找到完美系统。更现实的目标是选一套能和你的选品节奏一起演进、并且在你想离开时不会困住你的系统。把这句话写进你的评估标准，很多纠结会立刻变得清楚。
我们团队SKU从几百涨到几千，老板让我出ERP方案，我第一反应是找服务商要功能清单对比，但清单越比越乱，每家都说自己能做。我到底该从哪儿切入，才不至于上线后核心流程跑不通？
先别比功能，先做一次选品盘点。把近6到12个月的SKU按三个维度打标签：上新频率（月上新SKU数）、生命周期（从首单到清仓的月数）、变体和组合复杂度（一个SPU下几个变体、有没有捆绑销售）。铺货型通常月上新几百到上千、生命周期1到3个月、变体简单；精铺型月上新几十、以测款为主；
精品和品牌型月上新更少但生命周期常在12个月以上，配件和变体关系复杂；独立站还要叠加会员、复购和履约数据。盘完后按“哪条流程最痛”排优先级：铺货把刊登、订单、库存放第一层；精铺加采购计划和头程；精品和品牌型把采购协同、批次或效期管理、财务结算、BI提前。
判断依据是流程断点，不是功能数量，如果某个模块缺失不会造成重复人工劳动或对账差异，就先不上。
我们有亚马逊、独立站还有两个东南亚平台，同一个产品在四个后台的编码完全不一样，运营各自维护Excel。之前上过一次系统，库存对不上、报表两套数，最后不了了之。这次我想上线前把这事处理干净，但不知道做到什么粒度才算够。
判断标准很简单：任意一个物理库存单元，能不能在全链路里用同一个主键串起来。具体要做到三件事。第一，建立一套内部SKU主数据表，字段至少包含内部SKU、品名、变体属性、包装规格、供应商、采购成本、HS编码和合规属性，外部平台编码只作为映射字段挂在这张表下面，不做主键。
第二，明确一物一码还是多物一码：同一个产品不同平台不同包装，必须在内部SKU层面就区分开，否则后期库存永远对不上。第三，确定谁维护、什么时候维护，规则定成“新品上架前必须先建内部SKU，平台编码由系统回填”，而不是上线后再补。
验收口径建议是映射覆盖率100%、未映射SKU数为0、一物多码的重复项全部合并。这一步做完再谈接口对接，顺序反了，接口越多越乱。
第一次看服务商报价觉得还能接受，结果数据迁移、接口、培训一项项加起来翻了一倍。老板问我为什么超支，我也说不清哪些是必须花的、哪些是可以砍的。有没有一个比较靠谱的口径，能让我一开始就把账算明白？
让服务商把报价拆成五项：软件订阅（按店铺数、订单量或账号数阶梯计费，一定要问清超过阶梯怎么涨）、实施服务（人天单价和总人天）、第三方接口或插件费（平台、物流、支付、BI各算各的）、数据迁移与清洗、培训与售后SLA。经验上后四项加起来经常和一年订阅费同一量级甚至更高。
隐性成本按三块预留：内部人力，业务骨干参与调研和UAT，项目周期内要占掉三成到五成工时；并行期双录，切换前后通常1到2个月新旧系统同时跑；停摆风险，旺季前两个月不建议做切换。
可执行口径是把12个月总拥有成本写成“订阅乘12＋实施人天乘单价＋接口年费＋内部人力折算＋10%到20%应急预算”，用这个数去汇报，而不是用第一年报价。
我们业务增长挺快，但主推品类一直在换，选品、定价、补货基本靠运营的经验拍板。服务商说越早上一体化越好，我又担心流程还没定型就固化下来，反而把自己绑死。这种情况到底该不该先上系统？
有三个信号出现时，先别上复杂ERP。第一，SKU结构和订单结构还在剧烈变动，比如主推品类没定型、月上新结构变化超过三成，这时候把流程固化下来，等于给还在长身体的业务穿紧身衣。
第二，核心环节大量依赖人拍板、没有稳定规则，选品、定价、补货全靠运营经验，流程没沉淀就没法配置，配出来的也只是Excel的电子版。第三，团队里没有能对实施结果负责的内部owner，只有IT或某个运营兼职，这类项目失败率最高。
遇到这些情况先做阶段0：统一SKU编码和主数据规则，跑订单、库存、采购、财务的最小闭环。验收指标建议定为库存账实一致率不低于98%、订单自动流转率不低于90%、月结对账差异笔数可解释，稳定跑1到2个月再谈刊登、广告和BI。ERP不会替你补流程，它只会把你现有的流程放大。
读者评论
作为铺货卖家很认同库存同步优先于刊登效率。我们SKU八千多，旺季上下架频繁，曾因同步频率和安全库存没设好超卖到3%以上。选型时确实容易被批量刊登演示带偏，应该把库存扣减规则和自动下架放进第一阶段验收。
精铺团队那个案例很真实。我们一百多条SKU，也买过带销量预测的采购计划，结果运营还是靠经验和小批量试单，模块使用率很低。反而单款毛利分析、多平台订单归集更缺。功能领先业务太多就是负担，采购计划等前置期和波动数据够了再上。
独立站财务对账的痛点被说中了。SKU不多不代表财务简单，多币种、分期、本地钱包、拒付会让基础财务模块撑不住。选型时一定要让财务参与，按支付渠道拆分流水和自动匹配结算单应该提前验证，否则每月人工对账成本很高。