去年第四季度，我帮一家做家居园艺的跨境卖家做系统复盘。他们团队 11 个人，同时运营亚马逊美国站、eBay 德国站、Wayfair 和 TikTok Shop 美国站。老板的原话是："我们的 ERP 太烂了，想换掉。"我让他先把过去 30 天的刊登事故拉出来，结果拉出来 137 条记录：46 条是类目属性缺失导致刊登失败，31 条是变体关系错乱，22 条是价格同步延迟造成错价，18 条是库存回传慢导致超卖，剩下 20 条里有 14 条是运营手动改了平台后台、没同步回 ERP。
这 137 条里，真正属于"ERP 功能不行"的，我判断不超过 25 条。剩下的问题，一半是平台规则理解偏差，一半是内部流程没有定义清楚谁在什么时点做什么。如果当时直接换系统，这些问题会在新系统里原样复现，只是换了个抱怨对象。
这就是我想在这篇文章里讲清楚的事：ERP 跨境电商升级方案的第一步不是选型，是诊断。而诊断最有效的工具，是一份能落到字段级的问题清单。多平台刊登之所以难，不是因为 ERP 不够强，而是因为大多数团队从来没有把"刊登到底哪里断了"写成可验收的需求。下面我会把这份清单怎么设计、怎么归类、怎么转成需求表、怎么用于 POC 验收，完整拆一遍。
先把结论摆出来，后面所有内容都是在解释这个结论怎么落地。
结论一：多平台刊登的失败，80% 以上不是"发不出去"，而是"发出去的东西不对"。真正发不出去的场景，比如 API 报错、账号掉线，反而好排查。难的是那些系统显示成功、业务侧却出问题的场景：价格对不上、属性填错、变体挂错父体、库存显示有货实际无货。这类问题不会在刊登日志里报错，只会在客服工单和平台警告里冒出来。
结论二：ERP 升级有三种路径，不要默认只有"换系统"这一种。路径 A 是模块增购，比如在原系统上加刊登中台或库存同步模块；路径 B 是换 ERP，适合原系统架构老、接口不开放、数据模型不支持多平台的情况；路径 C 是不换系统，做流程 + 工具组合改造，用接口中间层、批量表格工具、外部 RPA 补足短板。三条路的成本差可能是 10 倍以上，选错方向的代价远大于选错服务商。
结论三：问题清单的真正价值，是把主观抱怨转成可验收指标。"刊登老是出错"没法验收，"美国站园艺类目新 SKU 首次刊登成功率 ≥ 95%、平均耗时 ≤ 8 分钟、人工干预率 ≤ 15%"才能验收。没有可验收指标，任何 ERP 演示都能显得很完美。
要理解为什么刊登这么难，得先看一条刊登链路从头到尾经过了多少个可能出错的节点。我把这条链路拆成七段，每一段都有典型的失败形态。
大多数团队的 SKU 主数据存在 Excel、ERP、平台后台三个地方，而且三者经常不一致。我见过最典型的场景是：供应商给的原始编码里有空格和全角字符，运营在 Excel 里手动清洗了一遍，导入 ERP 时又转了一次编码规则，最后到平台后台变成第三种形态。这时候如果要做跨平台库存合并，系统根本认不出这是同一个商品。
更麻烦的是属性数据。一个园艺花盆，在亚马逊美国站需要填材质、尺寸、容量、是否含植物、适用场景；在 eBay 德国站需要填 Material、Größe、Farbe、Hersteller；在 Wayfair 需要填 Room Type、Shape、Primary Material。这些字段名不同、枚举值不同、必填项不同。如果 ERP 没有做好属性映射模板，运营就得每个平台手工填一遍。
我统计过自己经手的几个项目，类目属性相关的失败占刊登失败总量的 35%，45%。原因很简单：平台类目树会调整，属性会新增，枚举值会下线，而 ERP 里的映射模板是静态配置的。平台改一次规则，映射就失效一批。
这里有个细节值得展开：亚马逊的 Browse Node 和商品类型（Product Type）在两套体系里并行，很多 ERP 只映射了 Browse Node，没有映射 Product Type，导致新品刊登时必填属性缺失。这个坑我在 2023 年遇到过至少两次，每次都导致一批 SKU 卡在草稿状态。
价格问题的复杂性在于它是"多层计算"：基础价、促销价、会员价、优惠券、平台活动价、汇率换算。ERP 通常只管理基础价和部分促销价，平台侧的优惠券和活动价是独立的。如果两侧没打通，就会出现 ERP 显示 29.9 美元、平台实际显示 19.9 美元的情况。
2024 年我接触过一家做厨房小家电的卖家，因为一次平台秒杀活动与 ERP 促销规则叠加，出现 3 小时错价，涉及 87 个订单，直接货值损失约 1.8 万美元，另加平台侧的订单取消率惩罚。事后复盘发现，问题不在 ERP 计算错误，而在于活动创建的审批流程里没有任何人核对 ERP 侧的促销状态。
多平台共用一批库存时，库存同步的核心矛盾是时效。亚马逊的库存更新有延迟窗口，eBay 的 API 有限流，TikTok Shop 的回执机制又不一样。如果 ERP 采用定时批量同步，同步间隔 15 分钟，那么在两个平台同时出单的高峰时段，超卖几乎不可避免。
我的经验判断是：对于日均订单 200 单以上、SKU 数超过 500 的卖家，库存同步间隔超过 5 分钟就已经是风险区。缓冲库存（Buffer Stock）是常用的缓解手段，但它只是把超卖概率降低，不是消除。缓冲设置多少，需要基于历史出单速度分布来算，而不是拍一个固定值。
批量刊登的体验差异极大。有的 ERP 提交 500 个 SKU 后只告诉你"完成"，不告诉你哪几个失败、为什么失败。运营只能去平台后台一个个核对。这种设计下，人工干预率可以高达 40%。
好的设计应该提供：失败清单可导出、失败原因可读（不是原始错误码）、支持按失败原因分组批量重试、失败 SKU 可回退到草稿状态修改后重新提交。
刊登时属性填错，订单生成后可能触发平台的合规审核，或者导致物流方案不匹配。比如刊登时申报重量填错，订单生成后运费计算错误，实际发货时才发现亏损。这类问题追溯起来很麻烦，因为原因在刊登环节，表现在订单环节。
多平台、多店铺、多子账号的情况下，如果没有操作审计，出现错价或违规刊登时无法定位责任人。我见过一家公司因为离职运营带走了主账号权限，导致大促期间无法修改价格，损失的时间窗口远超系统成本。
这是最普遍的误区。团队遇到刊登失败，第一反应是查 ERP 功能清单，看有没有对应模块。但前面已经说过，真正归因于系统能力的只占约三成。剩下的问题，换任何 ERP 都会存在，因为它们的根因在平台规则理解和内部流程定义。
我的判断方法是：如果一个问题的复现条件是"某个运营操作了某一步"而不是"系统在某个条件下自动执行了某一步"，那它大概率不是系统问题。这类问题应该改流程，不是换工具。
很多卖家选型时会拿一张几十项的功能对比表打分。这个方法的致命缺陷是：功能清单上的"支持多平台刊登"这一项，不同产品的实现深度差 10 倍。有的只是支持把商品推到平台基础接口，有的是支持多平台属性映射 + 变体关系转换 + 失败重试 + 异常队列。
我建议把功能清单换成场景清单。比如不问"是否支持多平台刊登"，而问"同一个 SKU 同时刊登到亚马逊美国站和 eBay 德国站，属性映射模板怎么配置？如果一个平台刊登失败，另一个平台的状态会怎样？"用具体场景追问，才能看出实现深度。
全量迁移的风险在于，当问题集中爆发时，你分不清是数据问题、配置问题还是系统问题。我见过一家卖家一次性把 3000 个 SKU 迁到新系统，结果前三天出现大量刊登异常，团队陷入救火，最后不得不回滚，损失了两周时间和一次大促准备期。
更稳的做法是先选一个平台、一个类目、20，50 个 SKU 做试点，把问题清单上的每一类问题都在试点里验证一遍，再决定是否扩展。
ERP 可以帮你约束流程，比如强制填写认证信息、拦截禁售类目，但它不能替代卖家对合规的责任。欧盟的 GPSR、EPR，美国的 CPSIA、Prop 65，这些要求的最终责任主体是卖家。指望 ERP 帮你自动合规，风险很大。
ERP 的真实成本结构是：订阅费 + 实施服务费 + 数据迁移费 + 培训成本 + 并行期人力 + 切换期的销售损失。实施费和并行期人力经常是订阅费的 2，5 倍。如果只按订阅费做预算，项目很容易中途资金不足。
一份能转成需求的问题清单，至少要包含这七个字段。缺任何一个，后期都会变成扯皮点。
| 字段 | 填写要求 | 常见错误 |
|---|---|---|
| 问题现象 | 描述可观察的行为，不写主观评价 | 写"刊登很慢"，应写"500 个 SKU 批量刊登耗时 47 分钟" |
| 涉及平台 | 精确到站点，不止平台名 | 写"亚马逊"，应写"亚马逊美国站 + 德国站" |
| 发生频率 | 给出周期内的次数或比例 | 写"经常发生"，应写"近 30 天发生 23 次，占刊登操作 8%" |
| 业务影响 | 量化到小时、金额或订单数 | 写"影响效率"，应写"每次平均占用运营 25 分钟" |
| 根因假设 | 可验证的假设，不是结论 | 写"ERP 不行"，应写"怀疑属性映射模板未包含新增必填项" |
| 责任角色 | 具体到岗位，不写部门 | 写"运营部"，应写"亚马逊类目运营 + ERP 实施顾问" |
| 期望结果 | 可测量，带指标和时间 | 写"提升刊登成功率"，应写"首次刊登成功率 ≥ 95%" |
把所有问题先扔进六个桶，再决定每个桶用什么解法。这个分类决定了升级路径的选择。
我通常建议客户在做完分类后，先解决"人员桶"和"流程桶"，因为这两类改动成本最低、见效最快，而且能立刻降低问题总量。等这两桶清空后，再看系统桶里还剩多少，这时候再谈 ERP 升级，需求会清晰得多。
问题清单的最后一个用途，是直接变成 POC 的测试用例。每一个高优先级问题，都应该对应一个 POC 场景。我通常要求客户准备这样的测试集：
POC 的价值不在于验证功能是否存在，而在于验证失败场景下的系统行为。功能演示谁都能做得漂亮，失败处理才见真章。
下面这组指标是我从多个项目里总结的参考区间，不是行业标准，实际应该按团队规模和平台组合调整。
| 验收指标 | 建议基准 | 测量方法 |
|---|---|---|
| 首次刊登成功率 | ≥ 95%（成熟团队）；≥ 85%（初期） | 首次提交即成功的 SKU 数 / 总提交数 |
| 单 SKU 刊登平均耗时 | ≤ 8 分钟（含人工核对） | 从数据准备到平台可见的端到端时间 |
| 人工干预率 | ≤ 15% | 需要人工修改后重新提交的 SKU 占比 |
| 库存同步延迟 | ≤ 5 分钟（日均 200 单以上） | ERP 库存变更到平台生效的时间差 |
| 错价事件数 | 0 起 / 月 | 平台实际售价与 ERP 目标价偏差超 5% 的事件 |
| 失败原因可读率 | ≥ 90% | 失败日志中能直接定位原因的比例 |
理论讲完，用一个具体产品来说明这些能力在产品层面是什么样。这里我以数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）为例做观察。
需要说明的是，下面是我基于公开资料和实际使用体验整理的观察，不是官方承诺，也不构成选型建议。具体是否适合你的业务，取决于你的平台组合、SKU 结构和团队规模，仍需要自己做 POC 验证。
数跨境的商品中心里，我比较关注的是它对多平台属性的处理方式。它支持按平台 + 类目维护属性映射模板，这意味着一个花盆 SKU 的材质、尺寸、容量只需要在 ERP 侧填一次，系统按各平台规则转换成对应字段。
这个设计对多平台卖家的价值在于：当平台新增必填属性时，只需要更新一次模板，历史 SKU 可以批量补填，不需要逐个平台修改。我见过不少团队因为平台属性变更而导致大批 SKU 刊登失败，有了模板机制后，这类问题的响应周期可以从几天缩短到几小时。
批量刊登的体验好坏，我认为关键看三件事：失败清单能不能导出、失败原因能不能读懂、能不能按原因批量重试。
如果只能看到"提交失败"这样笼统的提示，运营就得去平台后台一个个查，500 个 SKU 的排查可能要花一整天。如果能按"属性缺失""类目不允许""图片规格不符"分组，运营就可以针对每一组批量处理，效率差好几倍。
库存同步这块，我关注的是它支持多仓库存合并计算还是分开同步。对于有海外仓 + 国内直发两种履约方式的卖家，这两者差别很大。合并计算容易出现海外仓超卖，分开同步则可能导致平台侧显示库存过高。
价格方面，促销隔离是个容易忽略的点。如果 ERP 的价格规则不能识别平台侧的促销活动，就可能出现 ERP 基准价覆盖掉平台活动价的情况，直接造成错价。这个场景在多平台同时做活动时尤其危险。
子账号、操作日志、数据导出控制这些能力，在业务顺利时感觉是负担，出事时才知道重要。我判断的标准很简单：能不能查到某个 SKU 的价格在什么时间被哪个账号改成了什么值。如果查不到，风控就是空的。
把上面这些能力抽象一下，我得到的判断是：多平台刊登 ERP 的核心竞争力，不在于支持多少平台，而在于平台之间的差异处理得有多细。支持 30 个平台但每个平台只能做基础推送，不如支持 8 个平台但每个平台的类目、属性、变体、价格规则都做到位。
另一个观察是：刊登能力的好坏，在上线三个月内很难体现，因为前期 SKU 少、类目单一。真正的考验出现在 SKU 数过千、类目超过 5 个、平台超过 3 个之后。所以选型时的 POC 一定要模拟足够复杂的数据结构，而不是用几个干净的测试 SKU 走个流程。
这个阶段的团队，我通常不建议上重型 ERP。刊登量小，人工处理完全可控，上系统反而增加学习成本和固定支出。
建议做法是先把 Excel 模板和平台后台的批量工具用透，同时开始记录问题清单。这个阶段记录清单的目的不是马上买系统，而是积累后续选型的需求素材。等到单量上来时，你已经有了真实的问题数据，不会被销售演示牵着走。
这是最纠结的区间。我的建议是先做一次完整的刊登问题盘点，用前面说的六个桶分类。如果系统桶的问题占比超过 30%，考虑升级；如果不到 20%，优先做流程和模板优化。
升级时优先选模块化产品，允许只买刊登 + 库存模块，订单和财务先用现有工具过渡。一次性上全模块，实施风险会明显放大。
这个规模下，刊登已经不是单点工具问题，而是数据流问题。建议把 ERP 升级和主数据治理一起做，否则系统再好也会被脏数据拖垮。
同时建议引入独立的数据中间层思路：ERP 负责业务操作，中间层负责多平台字段转换和规则维护。这样平台规则变化时，只需要调整中间层，不用动 ERP 核心配置。
这种情况的刊登复杂度会低于预期，因为属性映射是重复的。重点应该放在库存同步和价格一致性上。可以考虑用更轻量的工具组合，不必上重型 ERP。
这是最难的情况。类目跨度大意味着属性映射模板数量多、维护成本高。建议在选型时重点考察属性模板的继承机制和批量维护能力，这个能力直接决定了长期运营成本。
换 ERP 能得到更完整的能力和更新的架构，代价是数据迁移风险、团队重新学习、以及切换期的业务波动。我的经验是，切换期至少要预留 4，8 周，而且必须保留旧系统的只读权限至少 3 个月，用于历史数据查询。
如果旧系统的核心问题集中在某个模块（比如刊登），而不是全面落后，我更倾向于模块增购或外部补足，而不是整体替换。
全自动刊登的效率最高，但风险也最高。我的建议是把自动化分成三层：
这样设计的好处是效率和安全兼顾，而不是在两者之间做非此即彼的选择。
缓冲库存设得高，超卖风险低，但平台侧显示的可用库存会低于实际，可能影响转化和平台算法表现。设得低则相反。这个取舍没有通用答案，需要基于历史出单速度分布来定。
我的粗略建议是：如果某个 SKU 的日均出单量标准差较大（波动剧烈，比如促销期），缓冲应该按峰值出单速度的 1，2 倍来设；如果出单平稳，可以设得低一些。
覆盖 20 个平台的服务商，通常在每个平台上的深度不如只做 3，5 个主流平台的服务商。这个取舍取决于你的平台策略：如果主力平台集中在前三个，优先选深度；如果是铺货型多平台策略，优先选广度。
| 取舍维度 | 选 A 的适用情况 | 选 B 的适用情况 |
|---|---|---|
| 换系统 vs 模块增购 | 原系统架构老旧、接口封闭、数据模型不支持多平台 | 核心问题集中在单一模块，其余部分运行良好 |
| 全自动 vs 半自动 | SKU 稳定、类目单一、团队流程成熟 | SKU 复杂、类目跨度大、团队新组建 |
| 高缓冲 vs 低缓冲 | 出单波动大、促销频繁、超卖赔付成本高 | 出单平稳、库存充足、平台算法对库存敏感 |
| 覆盖广度 vs 单平台深度 | 铺货型多平台策略、SKU 同质化程度高 | 主力平台集中、类目规则复杂、需要深度属性映射 |
这个阶段的唯一目标是产出一份可信的问题清单和一份 POC 计划。具体动作包括：
这个阶段不要急着联系服务商。需求不清楚的时候看演示，只会被功能密度误导。
带着问题清单去做 POC，重点验证失败场景。这个阶段的产出物是一份带数据的评估报告：哪些问题解决了、哪些没解决、哪些是新发现的问题。
同时要开始准备数据迁移方案。主数据的清洗工作量经常被低估，我建议预留至少两周专门做编码统一和属性补全。
上线不要一次性全量。建议先上 1 个平台、1 个类目，运行 1，2 周，确认刊登成功率、库存同步延迟、错价事件数都达到预期后，再逐步扩展。
灰度期的关键动作是每天复盘异常清单。这个阶段的异常会成为后期扩展时的知识库，价值很高，不要跳过。
回到最开始那家家居园艺卖家。我们没有换 ERP，做了三件事：重建属性映射模板并建立每周同步平台规则的机制；把价格变更和促销设置纳入审批流；在原有系统上补了一个库存同步中间层。三个月后，他们的刊登失败记录从每月 137 条降到 21 条，错价事件归零。
我说这个案例，不是为了证明不需要换 ERP，而是想说：ERP 升级的成功率，取决于升级之前你对问题的定义精度。问题清单不是一份文档，它是一个把业务抱怨翻译成技术需求的转换器。没有这个转换器，再好的系统也只能解决你碰巧说清楚的那部分问题。
我的独特判断是：多平台刊登优化本质上是"差异管理"，不是"功能堆叠"。平台之间的类目差异、属性差异、库存机制差异、促销规则差异，这些差异不会因为你换了一个更贵的系统就消失，只会因为你有没有把它们一条条列清楚、定义清楚、验收清楚而被管理住或被放任。
下一步怎么做，我给三个明确的动作：
最后提醒一点：任何 ERP 升级方案的效果，都需要 3，6 个月才能稳定体现。如果在第一个月没看到明显改善就急着推翻方案，很可能推翻的是一套本来会有效的方案。给流程改造和团队适应留出时间，同时用问题清单的指标变化来客观判断，而不是靠感觉。
我们团队现在三个平台都在铺货，运营天天在群里喊“刊登又失败了”“属性对不上”，但真要让 IT 去提需求，大家又说不清到底要改什么。我自己也踩过这个坑，凭印象提了一堆需求，结果 ERP 实施方做完发现解决的不是最痛的点。
所以我想知道，问题清单应该记到什么颗粒度，才能既不让运营觉得麻烦，又能让 IT 和 ERP 服务商看懂。
建议至少固定七个字段：问题现象、发生平台、出现频率、造成影响、根因假设、责任角色、期望结果。记录口径要写成可复核的事实，比如“A 平台批量刊登 200 个 SKU，失败 37 个，其中 29 个报缺失必填属性，运营逐个补录平均耗时 40 分钟”，而不是写“刊登经常失败”。
频率用“每天几次/每周几次”或“占批量任务比例”量化，影响尽量折算成人力工时、下架时长、赔付金额这类可比较的单位。根因假设允许写错，但要写出来，因为它的作用是引导验证方向。
最后把同一根因的问题合并成一条需求，附上期望结果和验收口径，例如“类目属性模板命中率从 60% 提升到 90% 以上，人工补录次数下降一半”。这样一张表既能内部对齐，也能直接拿去和服务商谈功能边界。
我们公司现在的情况是，刊登效率低、错价偶发、库存偶尔不同步，老板第一反应是 ERP 太老了要换，但我作为运营负责人心里没底，万一是我们自己的流程乱，换了系统还是一样。之前也见过同行花了大价钱换系统，结果半年后大家还在用 Excel 补位。
所以我特别想知道，有没有一套方法能先把根因定位清楚，再决定要不要动系统。
可以用三层排查法。第一层看数据源：同一个 SKU 在商品中心的属性是否完整、类目映射是否唯一、价格和库存是否只有一个权威来源，如果数据源本身就多头维护，优先修流程而不是换系统。
第二层看平台侧：把失败回执和错误码拉出来分类，如果大量错误集中在“平台必填属性缺失”“图片规格不符”“类目选错”，这是映射规则问题，靠模板和校验就能解决大半；如果集中在限流、超时、接口不支持某类操作，那才是系统能力问题。第三层看人：统计同一操作不同人的执行差异，差异大说明缺 SOP 和权限约束。
判断依据是看问题分布，如果 70% 以上能归到数据源和规则映射，先做流程和模板治理，ERP 只做增购或接口改造；如果核心链路平台根本不支持批量或 API 覆盖不足，再谈升级或替换。
我们最近在接触几家 ERP 服务商，每家演示都很流畅，但演示用的都是他们准备好的干净数据，我心里很清楚真跑起来不会这么顺。之前吃过亏，上线后才发现某些平台类目映射要人工重做，销售旺季根本扛不住。所以我想在 POC 阶段就把验收标准写死，但不确定该用哪些指标、定到什么数值才算合理。
POC 验收建议围绕五个指标设计：刊登成功率、单 SKU 平均耗时、人工干预率、错价或错属性发生率、库存同步延迟。口径要事先约定，比如刊登成功率按“一次提交成功、无需人工修改”计算，而不是按最终发布成功计算，否则数值会虚高。
测试集不要用服务商提供的样板数据，用你自己真实的 SKU，覆盖至少 3 个平台、2 个类目，并且包含一个变体商品和一个促销场景，因为这两类最容易暴露映射和价格规则问题。
数值目标不要照抄行业说法，用你当前基线做对比，例如当前人工刊登平均 12 分钟一个，要求 POC 阶段降到 3 分钟以内且人工干预率低于 20%。同时把失败场景写进验收：API 限流时怎么排队、批量失败后如何重试、超卖如何拦截。达不到就明确记录，作为后续谈 SLA 和费用的依据，而不是靠上线后扯皮。
我们运营着五个平台，老板想一次性全部迁到新方案上，说是长痛不如短痛，但我担心一旦出问题，旺季订单和库存全乱。之前小范围试过一次插件，结果数据把正式环境的价格覆盖了，赔了不少。所以我想说服团队先做试点，但不知道怎么选试点对象、跑多久、看什么信号才敢放量。
试点选择遵循三个原则：选一个平台而不是全部、选一个品类而不是全店、选一个小组而不是全员。平台优先选规则相对稳定、API 支持较完整的那个，把最复杂的平台留到第二轮，因为你需要先验证链路能不能通，而不是一上来挑战最难场景。
品类选 SKU 数量适中、变体结构清晰、季节性不强的，避开大促主推款，避免试点失败直接影响营收。时间上建议给到 2 到 4 周，覆盖至少一个完整的补货和促销周期，否则库存同步问题看不出来。
观察信号重点看四个：刊登失败是否集中在少数可解释的原因、人工干预是否逐周下降、库存和价格是否出现过不一致、异常处理是否有明确的责任人和 SOP。这四个都稳定了再扩平台，扩的时候按平台逐个灰度，每上一个平台观察一周。如果试点期间出现无法解释的数据错乱，先停下来查根因，不要靠加人加班硬扛过去。"
读者评论
文章把刊登问题拆成平台规则、内部流程和系统能力三块，这个比例很真实。我们公司之前也总怪ERP，后来发现一半以上是运营没按SOP改价、没同步后台，换系统解决不了。
类目属性映射那段深有同感。亚马逊Product Type和Browse Node并行，很多ERP只做了一层，新品一上就卡草稿。我们后来专门维护映射表，但平台一改规则还是得人工补，确实不是换系统就能一劳永逸。
库存同步间隔超过5分钟就是风险区，这个判断比较中肯。我们日均300单，之前用15分钟批量同步，大促超卖过几次。后来加缓冲库存和订单触发的实时扣减，才把超卖压下来，但缓冲值确实要按历史出单分布算。
选型只看订阅费这点太容易被忽略。我们去年评估ERP，实施费和并行期人力加起来是订阅费的3倍，数据迁移还另算。如果按功能清单打分，很容易选到演示好看、落地一堆配置的产品。
权限与审计那部分很关键。多店铺多子账号，没有操作日志，出了错价根本找不到是谁改的。我们后来强制主账号权限回收、改价走审批，虽然麻烦，但比大促期间改不了价强多了。