先把结论摆出来：七个阶段，加一个贯穿动作
我的结论很直接：跨境 ERP 建设不是「选型，上线，培训」三步走，也不是某些方案商说的十几步瀑布流程。按我参与过的项目来看，真正能落地的是七个阶段加一个贯穿动作，其中前三个阶段吃掉整个项目 60% 以上的人力，却往往被排在选型之后。
这七个阶段是：目标与自检、流程梳理、主数据与补货规则、补货模块设计、选型与集成、上线与灰度、财务合规与对账。贯穿动作是案例拆解与复盘，它不是项目结束后的总结报告，而是从第一天就要建立的度量机制。
因为采购补货是跨境 ERP 里唯一一个能在一到两个月内同时验证数据质量、流程清晰度和跨部门协同的模块。
订单模块只要接口通了就能跑，财务模块只要科目表定了就能出报表。但补货不行：它要用到销量预测、在途库存、供应商交期、MOQ、安全库存、多仓调拨、平台仓容限制，任何一环数据是脏的，补货建议就是错的，采购就会骂系统，运营就会绕开系统用 Excel，项目就此进入死亡螺旋。
注意顺序。我说的是「采购补货的逻辑要先想清楚」，不是「采购补货模块要先开发」。这两件事差别很大。
很多团队的错误是：先谈需求、先开发补货模块，结果发现主数据里同一个 SKU 有三个编码，供应商交期字段一半是空的，最后补货模块做出来没人信。所以正确的做法是先用业务语言把补货逻辑跑通，再用系统语言把它固化下来。
我见过不止一个团队，直接拿国内电商 ERP 的选型清单来套跨境业务，最后的结果基本一致：功能清单 90% 对得上，业务跑不通。
原因不复杂。国内电商 ERP 的核心假设是「一个平台、一个仓、一个币种、一个税制、物流时效以天计」，而跨境业务把这个假设全部打碎了。下面四个场景，是我在项目里反复遇到的。
一个卖家在亚马逊、eBay、独立站同时卖同一个 SKU。亚马逊出了 30 单，独立站出了 8 单，如果库存同步是 15 分钟一次，这 15 分钟里独立站可能又卖出去 5 单，而实际库存只够 3 单。
国内电商遇到这个问题，处理方式是超卖赔付加道歉。跨境场景里，亚马逊的超卖直接影响账号绩效指标，独立站的超卖影响支付通道风控评分，代价完全不同。
所以跨境 ERP 的库存同步不是「定时任务」这么简单，它需要区分「可承诺库存」和「物理库存」，需要在不同平台之间做库存池的分配策略。这是国内 ERP 基本不考虑的。
国内补货，交期三天，补货周期可以按周算，安全库存按天算。跨境补货，国内仓到美国海外仓的头程，海运 30-40 天，空运 7-12 天，还要叠上清关、预约入仓、上架的时间。
更麻烦的是，海外仓的补货决策周期必须覆盖头程时效加上一个完整的销售波动周期。这意味着你在 8 月做的补货决定，影响的是 10 月的库存结构。用国内那套「周补货 + 3 天安全库存」的参数去做，断货和压货会同时发生，这正是我开头那个客户的处境。
我在诊断时最常问的一个问题是：你现在到底有多少货？十次有七次，对方给我的数字是「仓库里的货」，而不是「已经付了钱、正在路上的货」。
跨境卖家的资金有很大一块沉淀在在途库存上：已下单未发货、已发货未到港、已到港未清关、已清关未入仓、已入仓未上架。这五个状态在财务上都是支出，在库存上却常常是空白。
结果是补货判断失真：仓库里没货就急着下单，实际上海上还有两批；或者仓库里看着有货就不补，结果那批货卡在清关，两周后断货。
多币种听起来是个汇率换算问题，实际项目里它会牵扯到：采购用什么币种结算、平台回款用什么币种、汇率按哪一天的、汇兑损益怎么记、VAT 在哪个环节确认、平台佣金和广告费怎么归集到 SKU 维度。
我见过一个卖家，ERP 上线半年，财务每个月还要手工做 3 天账，因为系统里的平台结算数据和财务账套对不上。跨境 ERP 如果只做订单和库存，不做财务闭环，最后一定会变成两个系统两套账。
下面这九个错误，几乎每个出问题的跨境 ERP 项目都会踩到两三个。我把它们按「发生阶段」排列，方便你对照自己的进度。
最常见的开场白是「我们 IT 部门牵头，业务配合」。这句话一出来，项目基本就注定了结局。
ERP 项目的本质是把业务规则变成系统规则，业务方必须是主角。采购补货的规则、异常处理的口径、谁有权改安全库存，这些都不是 IT 能决定的。IT 的角色是翻译和实现，不是决策。
选型会上最热闹的问题通常是「你支持不支持多仓调拨」「你支持不支持组合 SKU」。但如果你的 SKU 编码在运营表、采购表、仓库表里是三套，任何系统接进来都会水土不服。
我的经验是：主数据治理应该排在选型之前，哪怕你还没决定用哪套系统。因为主数据的标准是业务标准，不是系统标准，换了系统这套标准照样用。
我见过一个团队，安全库存统一设成 30 天。我问为什么是 30 天，回答是「之前一直这么设的」。
问题在于，A 类爆款设 30 天安全库存，等于压了两个月的资金；C 类长尾设 30 天，等于永远清不完。补货参数必须分类、分层、有人负责、有复核周期，否则系统算得再准也没人信。
跨境场景的集成对象包括：销售平台（亚马逊、eBay、Shopee、TikTok Shop、Temu、独立站）、支付通道、物流商、海外仓服务商、财务软件、税务服务商。每一个接口的联调、字段映射、异常处理都要花时间。
很多预算表里只写了「接口开发」，没有写「接口维护」。平台 API 会改版、会限流、会调整字段，这是持续性成本。
VAT 申报口径、关税归类、原产地规则、平台代扣代缴，这些不是财务部门的收尾工作，它们会反过来影响你的采购价格模型和定价策略。
合规规则一旦变化，可能推翻你整个 SKU 的利润计算逻辑。所以合规要前置到需求阶段确认，而不是上线后补。
上线只是开始。真正决定项目成败的是上线后三个月：数据准不准、业务用不用、异常谁来处理、参数谁来回测。
全量切换的风险在于，出问题时你无法判断是数据问题、流程问题还是系统问题。灰度试点的价值就是把问题范围控制在可定位的范围内。
「感觉效率提高了」不是项目成果。库存周转天数、缺货率、滞销率、对账差异笔数、补货人工耗时，这些才是。
别人用某套方案成功，可能是因为他的品类、渠道、团队结构和你完全不同。案例的价值在于提炼可迁移的判断逻辑，而不是复制结论。
这一节是全文的核心。我把每个阶段要交付什么、判断标准是什么、什么情况下可以跳过，逐条讲清楚。
在谈任何系统功能之前，先让业务负责人回答这六个问题。回答不上来的，说明还没到选型阶段。
最后这个问题最关键。如果答案超过一个，说明目标还没收敛。我不建议一个项目同时追库存周转、履约时效、对账效率三个目标，通常只能主攻一个，其他作为附带收益。
SKU 少于 200 个、单平台、单仓、月订单量低于 3000 单的卖家，我不建议急着上 ERP。这个阶段用「ERP + 表格 + 轻量工具」的组合，成本更低、灵活性更高。
真正需要 ERP 的临界点，通常出现在三个信号同时出现时：多平台库存开始打架、补货决策每天耗时超过 2 小时、财务对账开始对不上。
合格的指标要满足三个条件：有基线、有口径、有责任人。「缺货率从 11.2% 降到 6% 以内」是合格指标，「提升库存管理效率」不是。
这一阶段的交付物是一张泳道图和一份状态定义表。不要小看这件事，我在项目里见过最常见的争议，就是「这个单子现在到底算什么状态」。
这十一个状态，每一个都要有明确的责任人、停留时长标准、超时预警规则。其中第 8 到第 11 个状态，是国内 ERP 基本没有的，也是跨境 ERP 的真正差异点。
泳道图画完后，我习惯把它翻译成一个状态机定义。这不是给开发看的，而是给业务确认的，因为文字描述会有歧义，状态机不会。
{
"purchase_order": {
"draft": { "next": ["pending_review"], "owner": "运营/采购" },
"pending_review":{ "next": ["approved", "rejected"], "timeout_hours": 24 },
"approved": { "next": ["supplier_preparing"], "owner": "采购" },
"supplier_preparing": { "next": ["domestic_shipped"], "sla_days": 7 },
"domestic_shipped": { "next": ["domestic_received"], "sla_days": 3 },
"domestic_received": { "next": ["qc_passed", "qc_failed"], "sla_days": 2 },
"qc_passed": { "next": ["headhaul_shipped"], "owner": "仓储" },
"headhaul_shipped": { "next": ["export_cleared"], "sla_days": 3 },
"export_cleared": { "next": ["import_cleared"], "sla_days": 30, "note": "海运参考值" },
"import_cleared": { "next": ["overseas_received"], "sla_days": 2 },
"overseas_received":{ "next": ["available"], "sla_days": 2 },
"available": { "terminal": true, "effect": "inventory_on_hand += qty" }
}
}这份定义的真正用途是：每一笔在途库存，都能被归到某个状态上，并且知道它已经卡了多久。补货公式里的「在途库存」才有意义，否则就是一个模糊的数字。
我个人的判断是：主数据治理的工作量，应该占整个项目的四分之一以上，但大多数项目只给了不到一周。
| 主数据类别 | 常见问题 | 统一标准建议 |
|---|---|---|
| SKU / 商品 | 运营、采购、仓库三套编码；组合装与单品混用 | 以「最小可售单元」为唯一编码，父子关系单独建表 |
| 供应商 | 同一供应商多个名称；交期字段长期为空 | 统一社会信用代码为唯一键，交期必须有历史数据支撑 |
| 仓库 / 库位 | 海外仓与平台仓混为一谈；虚拟仓无定义 | 区分「物理仓」「平台仓」「在途虚拟仓」三类 |
| 平台与店铺 | 同一平台多店铺未做归属；币种未绑定 | 店铺必须绑定结算币种、结算周期、费率模板 |
| 币种与汇率 | 汇率来源不统一；历史汇率未留存 | 指定唯一汇率来源，按月留存，禁止手工改历史 |
| 税率与合规 | VAT 规则散落在各人手里 | 按国家/地区建税率表，与 SKU 海关编码关联 |
| 物流渠道 | 时效参数靠回忆 | 按渠道段（国内段/头程/尾程）分别记录实测时效 |
市面上大部分补货公式长得差不多，我常用的基础版本是这样：
建议补货量 =
(预测日均销量 × (补货周期 + 安全库存天数))
当前可用库存
在途库存（按状态加权）
平台仓可用库存
+ 目标安全库存缺口
其中：
补货周期 = 供应商交期 + 国内段运输 + 头程时效 + 清关时效 + 上架时效
安全库存天数 = Z × √(补货周期) × 销量标准差 / 预测日均销量
Z 值按目标服务水平取值（95% 服务水平约取 1.65）
在途库存加权系数：
已下单未发货 × 0.9
国内已发货 × 0.85
头程在途 × 0.7
清关中 × 0.6
海外仓待上架 × 0.5
公式不难，难的是每个参数从哪来。供应商交期必须是历史实测均值而不是供应商承诺值，头程时效必须分渠道分季节统计，销量标准差必须按 SKU 分层计算。
我通常建议用「ABC 分层 + 生命周期阶段」两个维度切分 SKU：A 类爆款用更短的补货周期、更高的服务水平；C 类长尾用更保守的策略，甚至改为按需采购不做安全库存。
这一阶段要交付的是补货模块的规则说明书，而不是功能清单。我通常按四块来写。
预测模型不需要很复杂。跨境场景里，我倾向于用「近期加权移动平均 + 季节性系数 + 活动系数」的组合，比复杂的机器学习模型更容易解释，也更容易被业务接受。
关键是要定义清楚：哪些情况下系统建议可以被人工覆盖，覆盖需要什么理由，覆盖记录是否留痕。如果谁都能随手改建议数量且不留痕，这个模块三个月内就会失去公信力。
不是所有补货都要走同一套审批。我的建议是按金额和紧急度分级：
「库存异常提醒」是没有用的预警。有效的预警必须带动作，例如：
| 预警类型 | 触发条件 | 建议动作 |
|---|---|---|
| 断货风险 | 预计可售天数 < 补货周期 × 1.2 | 立即触发紧急补货评估 |
| 滞销风险 | 库龄 > 180 天且近 30 天销量为 0 | 进入清仓评估流程 |
| 在途异常 | 某状态停留时长 > 标准时效 1.5 倍 | 通知货代核查并更新预计到仓时间 |
| 超卖风险 | 可承诺库存 < 24 小时预测销量 | 自动下调平台可售数量 |
| 对账差异 | 平台结算金额与订单汇总差异 > 0.5% | 生成差异核查工单 |
当你有国内仓 + 多个海外仓时，补货决策会变成「补到哪个仓」的问题。这时候需要引入仓容限制、尾程配送时效、平台仓容政策三个约束条件。
我的经验是，先把「补到哪个仓」的决策规则写清楚，再让系统执行。很多项目跳过这一步，结果系统算出来的调拨建议仓储部根本不执行。
我自己在帮企业做选型评估时，只看三件事：业务匹配度、集成能力、可维护性。功能清单是最不重要的东西，因为大多数系统的功能清单看起来都很全。
| 模式 | 适合什么企业 | 主要风险 |
|---|---|---|
| SaaS 标准产品 | 年 GMV 5000 万以下，流程相对标准，希望快速上线 | 个性化流程难适配；数据在第三方；长期订阅成本累积 |
| 自研 | 年 GMV 5 亿以上，流程高度特殊，有稳定技术团队 | 周期长、成本高、人才流失风险；业务变化快于开发速度 |
| 标准产品 + 定制 | 年 GMV 5000 万至 5 亿，核心流程有个性化需求 | 定制部分升级困难；依赖供应商实施能力 |
我习惯在选型阶段就列一张集成清单，标注每个接口的方向、频率、字段数量、异常处理方式。这张表能让厂商的报价变得可比。
接口数量和接口质量，往往比系统本身的模块数量更能决定项目成败。我的经验是，跨境项目的接口工作量通常是国内电商项目的 2 到 3 倍。
上线阶段我坚持一个原则：不要按模块灰度，要按业务闭环灰度。
「并行运行」这四个字听起来很保守，但它能救命。我见过一个团队直接全量切换，上线第三天发现海外仓库存口径错了，导致系统连续下了一批错误补货单，最后花了三周才把在途库存理清。
迁移前必须做数据体检：SKU 是否有重复编码、库存数量是否与实物一致、供应商交期字段完整率是多少、历史订单是否有孤儿数据。
我的建议是库存数据在迁移前做一次全面盘点，尤其是海外仓。盘点的成本远低于上线后长期对不上账的成本。
培训不是讲功能，而是讲场景。有效的培训材料是：早上 9 点，采购专员打开系统做什么；发现断货预警后，几步内处理完；补货建议被覆盖时，在哪里填理由。
前面说过合规要前置，这里具体讲落地。
关键在于汇率来源唯一、历史汇率不可篡改。很多公司毛利算不准，根源不是成本核算方法，而是每次算的时候取的汇率不一样。
平台结算单里包含销售额、佣金、配送费、仓储费、广告费、退款、赔偿等多个项目。系统需要把这些项目拆开，分别归集到 SKU 或店铺维度。
我的建议是先定义「对账容忍度」，比如差异在 0.5% 以内自动核销，超过则生成工单。不要追求零差异，那会让财务陷入无限核对。
VAT 税率、关税归类、平台代扣代缴政策都会变化。我建议每季度做一次合规规则复核，把变化同步到系统配置里。这部分我不能给出具体的税率数字，因为各国政策差异大且更新频繁，请以官方税务公告和专业机构意见为准。
这是标题里「案例拆解」的部分。我的观点是：案例拆解的价值不在于看别人做到了什么，而在于搞清楚「同样的动作，在我这里成不成立」。
| 拆解维度 | 要问的问题 | 为什么重要 |
|---|---|---|
| 业务背景 | 品类、渠道数、SKU 数、GMV 量级、团队规模 | 没有背景的案例结论无法迁移 |
| 原流程痛点 | 上线前补货怎么做的，卡在哪一步 | 判断痛点是否和你一致 |
| 方案设计 | 补货参数怎么定，审批流怎么设，谁负责 | 这是最容易被忽略也最有价值的部分 |
| 实施过程 | 上线周期、灰度范围、遇到的问题 | 判断自己的组织能否承受同样的节奏 |
| 指标变化 | 库存周转、缺货率、滞销率、对账差异、人效 | 必须看指标口径，不能只看数字 |
| 踩过的坑 | 哪些做法后来被推翻了，为什么 | 比成功经验更有迁移价值 |
| 可迁移与不可迁移 | 哪些做法依赖特定条件，你这里有没有 | 决定你该抄什么、不该抄什么 |
「库存周转率提升了 30%」这句话没有意义，除非你知道它用的是哪一个口径：是按销售成本除以平均库存，还是按销售数量除以平均库存；平均库存是期末值还是期间均值；在途库存算不算进来。
不同口径算出来的结果可能差一倍以上。所以拆解案例时，我会先问口径，再看数字。
讲完方法论，我用一个我实际测试过的产品来把前面的逻辑落地。这里以数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）为例，讲它的采购补货链路是怎么组织的，以及哪些设计对应了我前面说的判断标准。
需要说明的是，我关注的重点不是「哪个功能有、哪个功能没有」，而是它把哪些业务规则做成了系统结构，这些结构对采购补货这件事意味着什么。产品版本会迭代，具体功能请以官方最新说明为准。
这是我看这类产品时最先验证的一点。前面我说过，在途库存如果只是一个总数，补货公式就是失真的。数跨境的处理方式是把采购单拆到多个环节状态，每个状态有对应的时间节点和责任人。
这个设计对应的正是我前面强调的：在途库存必须能被归到具体状态上，并且知道它卡了多久。只有这样，补货公式里的加权系数才有实际意义，断货预警也才能提前触发。
我测试时重点关注的是数据流向：平台订单进来之后，销量数据是否直接反映到补货建议的计算里，库存变动是否实时同步到各渠道。
这一点很关键。很多卖家的补货之所以失控，是因为补货决策看的是昨天的报表，而销售数据是实时变化的。补货建议的时效性，取决于数据链路是打通的还是靠人工搬运的。
从产品结构看，数跨境的采购、库存、订单、财务模块之间是共享同一套主数据的，这意味着 SKU 编码只需要维护一次。这一点对应我前面反复强调的：主数据不统一，后面全部返工。
我前面说案例拆解和复盘是贯穿动作，不是收尾工作。落到系统上，就是你需要能随时拉出库存周转、缺货、滞销、采购履约这些指标的看板。
数跨境背后是九数云的数据能力，所以在指标看板和自定义分析上是有一定基础的。这对做复盘的价值在于：你不用等到季度结束才手工拼 Excel，可以按周看补货参数调整后的实际效果。
我的判断逻辑很简单，不看功能清单，看三个问题：
如果这三个问题的答案都是正向的，那么它在采购补货这个核心场景上是合格的。如果第三个问题是否定的，我建议直接放弃，因为全局统一的补货参数在你做到一定规模后一定不够用。
方法论讲完了，接下来按规模分档给建议。我把卖家分成三档，每档的动作重点完全不同。
这个阶段的核心任务是把 Excel 用规范，而不是买系统。具体做三件事：
如果一定要上系统，选轻量 SaaS，先解决订单和库存同步，不要一次性上采购、财务、BI。这个阶段的组织能力还不足以消化复杂的系统。
这是最需要 ERP 的一档，也是失败率最高的一档。我的建议是：
这个阶段最容易犯的错是想一次做完所有模块，结果每个模块都做了一半。
这个规模的组织通常已经有多个系统并存，问题不是「上不上 ERP」，而是「ERP 的边界在哪里」。
我的建议是先明确数据归属：哪些数据以 ERP 为准，哪些以平台为准，哪些以财务系统为准。然后做集成治理，最后才是功能扩展。
这个阶段可以认真评估「标准产品 + 定制」或自研，但要注意一点：自研的前提是你有一个能稳定三年的技术团队，否则系统会变成没人敢动的黑盒。
最后讲取舍。跨境 ERP 建设里没有「全都想要」的选项，你一定会放弃一些东西。下面是我认为最需要提前想清楚的五组取舍。
先上系统的好处是能快速看到效果、争取内部支持；坏处是主数据没治理，后期返工成本高。
我的判断是：如果团队里没有一个人专门负责主数据，就不要选「先上」这条路。因为主数据治理是持续工作，没有专人负责就不会发生。
定制能解决眼前的流程痛点，但会让系统升级变得困难。我的建议是：核心差异化流程可以定制，通用流程尽量用标准功能。
判断标准是：这个流程是不是你的竞争力来源？如果是，定制；如果不是，改流程去适应系统。
补货参数可以细到每个 SKU、每个仓库、每个渠道，但维护成本很高。我通常建议先按「品类 + ABC 分层」两个维度设置，跑三个月后再决定要不要细分到 SKU。
自研给你完全的控制力，但需要持续投入。我算过一笔账：一个能支撑跨境 ERP 的技术团队，年成本通常在 150 万到 300 万之间，而且是持续支出。
如果你的业务规模还撑不起这个固定成本，自研就不是选项。
灰度会拉长项目周期，但能控制风险。我的建议是：采购补货这个闭环一定要灰度，其他模块可以视情况加快。
因为补货出错会直接变成钱：多补了压资金，少补了丢销售。这个代价比其他模块高得多。
回到标题的问题：erp 跨境电商建设路线，从采购补货到案例拆解分几步。我的答案是七个阶段加一个贯穿动作，但如果你只能记住一件事，请记住这句：决定项目成败的不是第七阶段，而是第二、第三、第四阶段，流程、主数据、补货规则。
这三个阶段都不写代码，也就最容易被压缩、被跳过。它们同时也是唯一无法外包给厂商的部分，因为只有你的业务团队才知道真实规则是什么。
我见过太多项目把预算的 80% 花在选型和开发上，却在流程梳理和主数据治理上只给两周。最后的结果是：系统功能很全，但没人信它的补货建议。
关于案例拆解，我的独特观点是：不要去找「和你最像的案例」，而要去找「和你痛点最像的案例」。规模相同不代表问题相同，一个 2 亿的卖家可能因为流程规范而没什么库存问题，一个 5000 万的卖家可能因为品类特性而断货严重。痛点相似度比规模相似度更有参考价值。
这套动作看起来慢，但它能让你在选型时少走至少半年的弯路。跨境 ERP 建设真正的成本从来不是软件费用，而是你花在这上面的时间和组织磨合成本。
如果你的团队现在正卡在「系统上了但补货还是靠人」这个阶段，我的建议是先停下来做一次参数回测：把过去六个月的系统补货建议和实际执行结果拉出来对比，算出建议准确率。如果这个数字低于 60%，问题一定不在系统，而在参数和主数据。
我们公司现在多平台多店铺，补货全靠运营用Excel拍脑袋，缺货和滞销同时发生。老板让我出一份ERP建设路线，但我不确定是该一次性规划全模块，还是先拿采购补货试点。我怕方向错了，后面返工代价太大。
可以分，但不要按模块数量分，按建设层次分更稳。实操上我一般拆成七步：定目标、梳理采购补货流程、统一主数据和补货规则、设计采购补货模块、选型与集成、上线灰度、案例复盘与财务合规前置。
判断依据是采购补货同时依赖订单、库存、在途、供应商交期、平台销量五类数据，它能一次性暴露主数据和流程问题，是成本最低的验证切口。所以建议先做采购补货闭环，但主数据标准和目标口径要在第一步就定死，否则试点跑通也无法复制到全量。若SKU少于500、单仓单平台，可以压缩成四步；
多平台多仓、多币种，建议老老实实走完七步。
我之前设安全库存基本靠感觉，卖得好的多备一点，卖得差的少备一点。结果旺季断货、淡季压仓，财务天天问库存周转。我想知道有没有一套能落地的算法口径，而不是听厂商讲概念。
先别追求复杂算法，先把四个参数跑通：日均销量、供应商交期、交期波动、目标缺货率。补货点等于日均销量乘以交期，再加上安全库存；安全库存等于安全系数乘以交期内的销量标准差。
安全系数按你能接受的缺货率取，缺货率容忍5%左右可取1.65，容忍10%左右可取1.28，这是常用近似口径，实际要按品类历史数据回测。关键是两条：一是日均销量要剔除大促和断货期的失真数据，二是交期必须用实际到货记录算，不能用供应商承诺值。
我自己的做法是先拿Top 50 SKU跑三个月历史回测，对比缺货率和滞销率，再逐步推广到全量。参数一定要有复盘机制，季度调一次，不要设完就不动。
我看了很多ERP厂商的客户案例，通篇都是效率提升、管理升级，但看不到具体数字。我们自己准备上线，老板问我怎么证明这个项目值，我也不想被厂商的漂亮话带着走。
判断标准只有一条：看上线前后同一口径的指标变化，而不是看功能清单。建议固定六个指标：库存周转天数、缺货率、滞销库存占比、订单履约时效、平台对账差异率、补货相关人效。拆解案例时按六段写：背景规模、原始痛点、原流程、方案与规则、上线后三个月和六个月指标对比、踩坑与返工点。
判断真假的关键在口径：库存周转要说明是否含在途、缺货率是按SKU还是按订单、对账差异率是否含汇率损益。如果厂商案例只有百分比没有基准值，基本可以判定不可用。上线三个月内指标波动属正常，六个月还没有一个指标显著改善，就要复盘是规则问题还是执行问题，而不是继续加功能。
我们团队有技术，但不多；业务又很特殊，标准SaaS总觉得不贴合。厂商报价看着不贵，可一到对接平台、物流、支付、财务就冒出一堆额外费用。我想知道选型时到底该按什么标准判断，别掉进低价陷阱。
选型只看三件事：业务匹配度、集成能力、长期维护成本，不要先看功能清单和报价。判断路径是这样：如果你的核心流程和行业主流一致、SKU在几千以内、没有自研团队，优先SaaS；如果补货规则、定价、供应链模式是核心竞争力且SKU上万，考虑自研或混合，把差异化模块自研、通用模块买SaaS。
集成成本最容易被低估的地方有四个：平台API限流与政策变更、物流面单与轨迹回传、支付与结算对账、财务凭证与税务字段。实操建议是选型阶段就要求厂商列出已对接的系统和接口清单，并让技术负责人做一次真实数据的小范围联调，不要只看演示环境。
合同里要明确接口变更、新增平台、数据导出和二次开发的责任与费用边界，否则上线后每一次改动都是额外报价。
读者评论
把补货逻辑想清楚和先开发补货模块分开讲，这点很关键。我们之前就是先立项开发，结果SKU三个编码、供应商交期一半为空，模块上线没人敢用。回头看，主数据清洗确实该排在选型前面，而且是业务标准不是系统标准，换系统照样能用，这步省不掉。
多平台库存同步那段说到痛处了。可承诺库存和物理库存不分，15分钟同步窗口叠加上去就是超卖。文中五平台以上超卖率是单平台十倍左右这个台阶式上升，和我们实际感受接近，渠道一多，缺货和滞销真会同时出现。
九个误区里最认同「IT牵头、业务配合」这条。ERP本质是把业务规则固化成系统规则，安全库存谁能改、异常谁处理，IT定不了。另外用上线当终点也常见，上线后三个月的数据准确率和参数回测才是真正的考验。