如果有人问我“跨境电商ERP建设路线,从库存管理到选品策略到底分几步”,我的回答是:跑到稳态通常要5步,库存打底、订单与供应链协同、数据与财务打通、选品系统化、组织复盘迭代;但在第1步之前,还有一个几乎所有人都会跳过的第0步:定业务边界。
这个结论不是从产品手册里抄来的,而是过去几年我在二十多家卖家身上做选型陪跑、上线复盘之后总结出来的。踩坑最密集的地方从来不是“功能不够”,而是“顺序错了”:急着买选品插件、只比谁家报价低、把库存准确率当成IT部门的事、上完系统三个月没人登录。
这篇文章会把这条路线完整拆开,讲清每一步解决什么问题、什么指标算过关、什么情况下可以跳过、什么时候必须停下来先补地基。如果你正在选型,或者已经买了系统但用不起来,建议按顺序读完,最后一节有可以直接照做的自查动作。
标准答案是5步,但真正的分水岭在第0步。第0步不是“选哪个ERP”,而是“我的业务边界是什么”,你是铺货、精品还是品牌?是纯B2C,还是B2B大单和零售并行?是单平台单仓,还是五平台三海外仓?边界不清,后面五步全是返工。
第0步之后的五步顺序是固定的:库存打底 → 订单与供应链协同 → 数据与财务打通 → 选品系统化 → 组织复盘迭代。这个顺序的底层逻辑是数据可信度逐层递进,上层的决策必须建立在下层数据可靠的前提上。
我试过把这条路线压缩成3步(库存、订单、数据),结果发现选品会被硬塞进“数据”里,最后变成一个没人负责的模糊地带。也见过拆成10步的方案,细到“主数据治理”“API网关建设”,中小卖家根本没有人力承接,PPT很好看,落地为零。
5步的好处是每一步都能对应一个明确的责任人、一段可量化的上线周期、一组可验收的指标。少于5步,责任会糊;多于5步,组织会散。
最常见的颠倒就是“先上选品,后补库存”。逻辑上很诱人,选品直接决定赚钱,为什么不先做?但选品的判断依据是SKU级的成本、周转、退货、利润数据,这些数据全都来自库存和财务层。库存不准,你算出来的毛利率就是假的;毛利是假的,选品评分卡就是自欺欺人。
第二个常见颠倒是在库存还没稳定时去打通供应链。采购建议建立在可用库存和在途库存之上,库存数字漂移,采购建议就会失真,最后变成“系统让我补货,我补了,结果压了一堆滞销”。

| 阶段 | 核心目标 | 可量化验收指标 | 典型周期 |
|---|---|---|---|
| 第0步 定边界 | 明确业务模式与MVP范围 | MVP模块清单、上线里程碑、成功指标定义 | 1-2周 |
| 第1步 库存打底 | 库存成为可信数据 | 库存准确率≥97%、缺货率下降、周转天数可算 | 4-8周 |
| 第2步 订单供应链协同 | 从“能查到”到“能调度” | 订单自动抓取率≥95%、异常订单占比、采购及时率 | 6-10周 |
| 第3步 数据财务打通 | 算得清每个SKU的真利润 | SKU级利润可算率≥85%、对账差异率≤1% | 6-12周 |
| 第4步 选品系统化 | 把经验变成可复算流程 | 选品评分覆盖率、测款成功率、上新失败率 | 持续 |
| 第5步 组织复盘 | 路线持续迭代 | 系统日活使用率、淘汰SKU占比、SOP执行率 | 持续 |
跨境卖家的成长不是一条斜线,而是三个台阶。第一个台阶是日出百单以下,用Excel加平台后台就能活,痛点是“忙”。第二个台阶是日出三百到一千单,多平台多店铺开始出现,痛点是“乱”。第三个台阶是多平台加多海外仓加B2B大单,痛点是“算不清”。
这三个台阶对应三种完全不同的ERP诉求。很多人选型失败,本质是拿着第三阶段的方案去解决第一阶段的问题,或者用第一阶段的工具硬撑第三阶段的业务量。
第一个翻车现场是一家做家居的卖家,五个平台、三个海外仓。他们先用表格管库存,某次旺季出现超卖,一次性赔了将近两万美元的平台罚款和客户补偿。复盘发现根因不是仓库发货慢,而是各平台可售库存同步延迟了平均4小时,而他们的ERP根本没接海外仓的实时库存接口。
第二个翻车现场是一家从铺货转精品的团队。老板拍板先上选品工具,花钱买了数据和插件,结果选出来的爆款测了三个月死了七个。后来我们把数据拉出来看,发现他们算毛利时只算了采购价和国际运费,漏掉了平台佣金、广告费、仓储费和退货损耗,真实毛利比测算低一多半。
第三个翻车现场最典型:一家年销售额上亿的工贸企业,系统功能齐全,两年后盘点发现日活使用率只有27%。运营嫌录入麻烦,财务用自己的表格另算一套,采购看系统的采购建议但手动改一半。系统变成“给老板看的系统”。
不是表格不够好,而是表格的维护成本是平方级增长。SKU从500涨到2000,人工核对的组合数涨了近16倍;店铺从2个涨到8个,跨表对账的路径数涨了十几倍。这个拐点通常在日出300单左右出现。
更麻烦的是,表格没有校验机制。一个人填错单价,整条利润链就错了,而且没人会发现,直到月底对不上账。

我经常提醒团队的一句话:没有任何一个老板是因为“上了ERP”而赚钱的,赚钱的是因为“决策变准了”。所以判断ERP建设是否成功,不要看上线了几个模块,要看三件事,库存敢不敢信、利润算不算得清、选品有没有依据。
这是最贵的误解。ERP的强项是订单、库存、供应链、财务的沉淀和一致性,选品需要的是市场侧数据,需求趋势、竞品价格带、评论痛点、季节性、合规门槛。这两类数据来源根本不同。
ERP在选品中的正确角色是“验证器”而不是“发现器”:它不能告诉你该卖什么,但能告诉你“这个品卖起来到底赚不赚钱”。如果你的ERP连SKU级利润都算不出,谈选品就是空中楼阁。
我见过最多的选型会议,前40分钟都在问报价。但ERP的支出远不止订阅费,还包括实施费、数据迁移、接口开发、培训、二次开发、每年的人员工时。一个便宜40%的系统,如果实施多花两个月、每月多耗两个人力,一年多出来的成本往往超过差价。
顺序颠倒的代价是双份的:选品模块的钱花了,但因为数据不准,结论不可用;等库存补好,又发现选品模块的数据口径和库存对不上,还得重做映射。我更建议先跑通“库存,订单,利润”这条主干,再挂选品这个枝。
“统一库存、一套运营体系”这类说法听起来很爽,但落地时它是极其具体的工程问题:不同平台的SKU映射规则是什么?共享库存池还是分池?安全库存按平台还是按SKU?B2B大单锁库存会不会挤占B2C可售?这些问题没有标准答案,必须按自己的业务规则定。任何把“统一库存”当卖点而不是当项目来谈的方案,都要多问几句。
系统上线不是终点,是起点。我建议每个阶段都提前约定一个业务指标和一个使用指标:业务指标例如库存准确率、周转天数;使用指标例如日常录单率、报表查看人数。没有验收指标的项目,最后一定会退化成“老板的报表工具”。
很多人以为接口是无限的。实际上不同平台的调用频率、数据字段、历史数据可回溯范围、授权方式差异很大,还有一些平台对订单数据的存储和跨境传输有合规要求。选型阶段就要把这些问清楚,否则会出现“功能有,但拿不到数据”的尴尬。

我把跨境卖家的数据成熟度分成四级。L0是手工账,数据靠人对;L1是系统记账,订单库存进系统但口径不统一;L2是口径统一,全公司用同一套SKU和成本定义;L3是决策可用,数据能直接支撑补货、定价和选品。
大部分卖家以为自己处在L2,实际在L1和L2之间。判断方法很简单:让运营和财务各自算同一个SKU上个月的毛利,看两个数字差多少。差超过5%,就还没到L2。
完整的选品判断需要五类输入:市场侧的需求与竞争数据、产品侧的合规与质量要求、成本侧的完整成本结构、供应侧的产能与交期、资金侧的周转与账期。ERP能覆盖的主要是后三类,而且是以“验证历史”的方式覆盖,不是以“预测未来”的方式覆盖。
所以现实中的分工是:市场侧数据靠外部工具和人工判断,成本、供应、资金侧靠ERP沉淀。两边缺一边,选品都不成立。
我常用一个简化公式做初筛:真实净毛额 = 售价 − 采购成本 − 头程 − 尾程 − 平台佣金 − 广告费 − 仓储费 − 退货损耗 − 汇兑损益 − 资金占用成本。这个公式里最容易被忽略的是后三项,而它们恰恰是中小卖家利润被吃掉的主要来源。
只有当你能量化这个公式里的每一项,选品评分卡才有意义。否则评分卡只是把“凭感觉”换了个更好看的说法。

| 数据成熟度 | 该重点建设 | 建议暂缓 | 典型误判 |
|---|---|---|---|
| L0 手工账 | 主数据统一、SKU编码规则、库存基础台账 | 高级选品模型、BI大屏 | 以为买系统就自动变规范 |
| L1 系统记账 | 库存准确率、订单自动抓取、多仓映射 | 复杂的供应链绩效体系 | 以为订单进系统就等于管住了 |
| L2 口径统一 | SKU级成本归集、利润报表、周转分析 | 过早做预测类算法 | 以为报表多就是数据好 |
| L3 决策可用 | 选品评分卡、测款数据回流、淘汰机制 | 为了“先进”而堆技术栈 | 以为有模型就不用人工判断 |
评分卡的价值不在于分数本身,而在于把“为什么选它”写下来,事后可以复盘。我一般用六个维度:市场需求、竞争强度、毛利空间、合规风险、物流适配、复购潜力,各自加权。
关键细节是:权重必须由自己定,而且每季度复盘一次权重是否合理。给“毛利空间”25%的权重还是15%,反映的是你的资金策略,不是通用答案。
# 选品评分卡:把经验变成可复算的分数
WEIGHTS = {
"市场需求": 0.20,
"竞争强度": 0.15,
"毛利空间": 0.25,
"合规风险": 0.15,
"物流适配": 0.15,
"复购潜力": 0.10,
}
def score(item, weights=WEIGHTS):
total = 0.0
for key, weight in weights.items():
total += item.get(key, 0) * weight
return round(total, 2)
每项 0-10 分,由人工或模型打分后录入
candidate_a = {"市场需求": 8, "竞争强度": 3, "毛利空间": 7,
"合规风险": 8, "物流适配": 9, "复购潜力": 5}
candidate_b = {"市场需求": 6, "竞争强度": 8, "毛利空间": 5,
"合规风险": 9, "物流适配": 7, "复购潜力": 9}
print("A:", score(candidate_a)) # 权重不同,结论可能完全相反
print("B:", score(candidate_b))这段代码的意义不在于多复杂,而在于把选品从“讨论会”变成“可回测的流程”。三个月后回头看,你可以知道当初哪个维度打分打错了,而不是只记得“当时感觉不错”。

这个案例是我2023年下半年跟进的一家深圳卖家,主营家居与户外小件,从铺货转精品。当时的状态是:5个平台、8家店铺、3个海外仓,在售SKU约1300个,月订单量约4万单,团队18人,其中3人全职做数据表格。
他们的问题很典型:库存不准导致偶尔超卖,SKU级利润算不出来,选品主要靠老板经验和运营感觉。他们最开始的需求是“上一套选品工具”,我建议先别急,从库存开始。
第一步做的是最枯燥的主数据治理。把所有SKU重新编码,建立“内部SKU,平台SKU,条码,供应商料号”的四向映射表,把三个海外仓的库位信息标准化。
然后是库存同步策略。他们原来的做法是各平台独立库存,靠人工调;改造后设置共享可用库存池 + 平台维度安全库存,安全库存按历史动销和补货周期动态调整。
验收指标上,他们把“库存账实相符率”从72%拉到98.6%,用了三次全盘加两次抽盘。缺货率从9.3%降到3.1%。这一步做完,运营第一次敢用系统数字直接回复客户“有货”。
订单环节的核心是自动化和异常处理。订单自动抓取率从人工导入时代的不到60%提升到96%以上,剩下的4%是平台接口异常和特殊订单,需要人工兜底。
供应链环节做的是采购单、头程、海外仓入库、尾程派送的链路打通。这里有个细节很关键:在途库存必须能被看见,否则补货决策是盲的。他们把在途拆成“已下单未发货、已发货在途、已到港未入仓”三段,分别设置预期到仓时间。
供应商管理上,他们只做了两件事:交期达成率和到货合格率,两个指标,每月更新一次。不做复杂的绩效模型,因为采购只有两个人,看不懂的指标等于没有指标。
这是整个项目最难的阶段,也是最容易被低估的。他们最初以为“把平台结算单导进来就行”,实际做起来才发现,平台结算的时间口径、费用口径、退款口径,和内部财务口径三套都不一样。
解决路径是先定一套内部成本归集规则,再和各平台结算做映射,最后让系统自动生成差异表。这个过程中,他们专门花了三周做历史数据回算,把过去6个月的SKU级利润重算了一遍。
结果很震撼:按SKU级真实利润排序,前20%的SKU贡献了约78%的净毛利,而尾部35%的SKU整体是负贡献。这个结论直接改变了他们后面的选品逻辑。

有了第3步的利润底账,第4步才真正开始。他们的选品流程从“老板看中一个品就上”变成三步:评分卡初筛 → 小单测款 → 数据回流修正权重。
评分卡用的就是前面那六个维度,权重由运营、采购、财务三方共同确定。测款阶段严格控制首批数量,一般不超过300件,测款周期4到6周。
最关键的机制是数据回流:测款结束后必须填一张复盘表,记录当初评分与实际表现差在哪。半年下来,他们把“竞争强度”的权重从0.15调到0.22,把“复购潜力”从0.10调到0.12,因为复盘发现这两个维度的预测准确性最高。
最后一步不是技术活,是管理活。他们设了三个固定动作:每周一次库存与异常订单复盘、每月一次SKU利润与淘汰复盘、每季度一次选品权重与SOP复盘。
每个动作都有明确的责任人和输出物,避免变成“开会讨论不出结论”。推行四个月后,系统日活使用率从上线初期的31%提升到86%,运营和财务用的是同一套数字。
在这个案例里,他们最终选择的是以数据为主线的一类方案。我在给同行做分享时,经常用数跨境作为参考样本,因为它恰好覆盖了这条路线里最难的第3步,多平台数据接入后的SKU级利润归集与库存周转分析。
我观察到的几个特点值得说清楚。第一,它把重心放在“数据打通和口径统一”上,而不是把所有功能都堆上去,这符合我在第四节讲的“口径统一优先于功能丰富”的判断。第二,多平台数据接入后可以按SKU、店铺、站点、仓库多个维度下钻,这对做“砍哪些SKU”的决策很实用。第三,它更偏向分析与看板,库存预警、周转、利润这些指标能直观看到,但不代表它能替代执行层的ERP操作。
需要提醒的是:任何工具的能力边界都要以官方实际功能为准,也要以你的业务复杂度为准。中小卖家如果用不到多平台多仓的复杂度,先用轻量方案把库存和订单跑顺,也是合理路径。工具是配路线的,不是路线配工具的。

这个项目从启动到第5步跑顺,前后约11个月。他们事后做过一次成本归集,结果和大多数人的直觉不太一样:软件订阅费只占总投入的约三分之一,其余大多花在人力、实施和流程改造上。

这个阶段的建议是能用平台官方工具就用官方工具,先把SKU编码规则和库存台账规范起来。不要花大钱买全套ERP,也不要先上选品工具。
具体动作:把SKU编码规则写成一页纸并强制执行;建立一个SKU级的简单成本表,至少包含采购、头程、佣金、广告四项;每月做一次库存盘点,用盘点差异率作为自己的第一指标。做到这三点,你的数据成熟度就能到L2边缘,为后面选型省下大量时间。
这个阶段是上ERP性价比最高的窗口。优先建两块:库存的多平台多仓管理、订单的自动抓取与异常处理。利润模块可以稍后,但成本归集规则要在这时候定下来,不然后面改口径成本很高。
选型时的关键问题是:能不能接你所有在营平台的订单?能不能管你所有海外仓?接口调用频率够不够?这三个问题答不上来,功能再多也别选。
规模越大,顺序越不能乱。我的建议是先做库存统一,再做利润口径统一,最后才谈选品。多仓场景下,库存准确率低于95%基本等于不可用,这个标准要比单仓更严。
这个阶段要特别注意B2B和B2C的库存分配规则。如果两种业务共用库存池,一定要提前定义锁定逻辑和优先级,否则大单进来会直接挤占零售可售库存。
工厂背景的卖家最容易犯的错误是用零售的成本逻辑去算大单,或者用大单的账期去套零售。我的建议是把两条线的成本核算彻底分开,至少在利润报表层面分开,共享的部分只共享库存和产能。
另外,B2B的订单履约周期和B2C完全不同,不要强行用一套SOP。系统层面可以采用同一套主数据,但流程节点必须分开配置。
我见过太多“换了三套系统还是用不起来”的团队。换系统之前先做三件事:查日活使用率、查数据口径是否统一、查有没有验收指标。如果这三项都有问题,换系统只是把问题搬到新系统里。
诊断之后通常是两类结论:一类是流程问题,重新设计SOP和责任人就能解决;一类是能力问题,比如接口接不进来、多仓管不了,这时候才考虑换。

SaaS方案上线快、维护轻,但定制空间有限;自研灵活、数据完全自主,但人力成本和维护负担重;平台官方工具免费或便宜,但通常只管自己平台,跨平台能力弱。这不是优劣问题,是匹配问题。
我的经验判断是:年订单量在50万单以下、业务模式相对标准的团队,SaaS几乎总是更优解;只有当你的业务规则极度特殊(比如特殊的加工流程、特殊的分销体系),自研才划得来。
| 对比维度 | SaaS方案 | 自研方案 | 平台官方工具 |
|---|---|---|---|
| 上线速度 | 快,通常1-3个月 | 慢,通常6-18个月 | 极快,几天到几周 |
| 首年成本 | 中 | 高(人力为主) | 低 |
| 定制能力 | 有限,依赖配置和开放接口 | 极高 | 几乎没有 |
| 跨平台能力 | 强 | 取决于自建范围 | 弱,基本限于单一平台 |
| 维护负担 | 低 | 高,需要稳定技术团队 | 无 |
| 数据自主性 | 中,受服务商能力影响 | 高 | 低 |
| 适合谁 | 绝大多数中小及成长型卖家 | 业务规则特殊、订单量极大的团队 | 单平台起步阶段 |
不是“不好用”就该换。真正的换系统信号有三个:接口能力跟不上平台扩张速度、数据口径已经无法统一、维护成本超过业务增长带来的收益。满足其中任意两条,就可以启动选型了。
如果只是“界面不顺手”“报表不够漂亮”,那属于优化问题,不值得承担迁移风险。系统迁移的隐性成本很高,包括历史数据清洗、流程重训、员工抵触,这些往往被严重低估。
我一般建议先不买三类模块:一是高级预测类算法,数据量不够时预测不如人工;二是复杂的供应商绩效体系,团队没有专职采购时用不起来;三是过度精细的BI大屏,看着漂亮但不驱动动作。
先把“库存准、订单通、利润清”三件事做到位,再谈锦上添花。这三件事没做好,其他模块买回来也只是增加培训负担。
第一,库存准确率不能打折。可以接受上线慢一点,但不能接受库存数字不可信。第二,成本口径必须一次定清楚,后面改起来是全链路返工。第三,必须有验收指标,没有指标的模块宁可不上。
这三条底线听起来保守,但它们是把钱花在刀刃上的前提。我见过的成功项目,没有一个是靠堆模块取胜的,全都是靠把基础几件事做扎实。

第一,“分几步”的答案不是5,而是“第0步加5步”。跳过业务边界定义的项目,后面每一步都会返工一次。第二,选品不是ERP的功能,而是ERP数据的应用,把选品当选品工具来买,方向就错了。第三,ERP建设的真正瓶颈是口径和组织,不是技术,多数失败项目败在没人负责和没有指标,而不是功能不够。
如果你的库存准确率已经稳定在97%以上,SKU级利润能算清,那可以并行做选品。但如果这两项都不达标,先做选品基本等于把钱扔进一个无法验证的黑箱,测款结果也没法归因。
优先做减法。库存只做三件事:SKU编码统一、多平台映射、安全库存设置。利润只做一件事:把采购、头程、佣金、广告四项成本归到SKU。其他的等有专人再说。少做但做透,比全做但都浅要好。
按我参与的案例,库存准确率的改善通常在第1到第2个月就能看到,报表编制耗时的下降在第3个月左右明显,SKU级利润的改善要等到第6个月之后,因为需要几个月的数据积累才能形成对比。选品成功率的改善通常要一年以上才能被统计出来。
问四个具体问题:不同平台SKU怎么映射?共享库存池还是分池?B2B大单怎么锁库存?安全库存按平台还是按SKU?能清楚回答这四个问题的,才叫能力;只会重复“统一库存、一套体系”的,那是口号。
多数情况下是配合使用。ERP负责执行层的数据产生和流程跑通,分析平台负责多源数据的整合、口径统一和决策看板。如果预算有限,先把ERP的库存和订单跑顺,等数据量足够、问题变成“看不过来”而不是“记不下来”时,再上分析层。
最后回到最初那个问题:从库存管理到选品策略分几步?结构上是5步,实践上是“第0步想清楚 + 5步做扎实 + 每一步有验收”。路线图可以抄,纪律抄不了。你现在最该做的不是选系统,而是先回答一个问题,你和你的财务,能算出同一个SKU的真实利润吗?

我一开始以为ERP就是买个软件装上就行,结果销售跟我说先上选品模块,实施顾问又说必须先做库存,我彻底懵了。身边有朋友跳过库存直接上选品工具,最后数据对不上又回头补,我想知道这个顺序到底有没有硬性逻辑。
有共性顺序但不必死守。推荐主线是库存打底→订单供应链协同→数据财务打通→选品系统化→组织复盘。判断依据是数据依赖关系:选品评分卡要用到SKU级利润和库存周转,利润核算又依赖订单和成本数据,而订单准确性建立在库存可信之上。
如果你的库存准确率已经稳定在98%以上、SKU级利润能算清,可以直接跳到选品系统化;但如果库存还在靠手工表格对账,先补地基,否则选品结论不可信。
我们公司上了ERP半年,库存模块天天在用,但运营还是不敢信系统里的数,每次大促前都要人工盘一遍。老板问我到底做到什么程度算合格,我也说不清,只能凭感觉说‘差不多准了’。
建议用四个量化指标验收。第一,库存准确率:系统账面数与实际盘点数差异率控制在2%以内,核心爆款SKU控制在1%以内。第二,缺货率:因库存不同步导致的超卖订单占比低于0.5%。第三,周转天数:按SKU分层统计,能自动算出每个SKU的周转天数并与采购补货联动。
第四,滞销占比:超过设定天数无销量的SKU能自动标记并推送预警。这四个指标连续两个月达标,才算库存打底完成,可以进入下一步。
我们运营总监一直想让ERP承担选品功能,觉得花那么多钱买的系统应该能直接告诉我卖什么。但我实际用下来发现,系统里只有历史销售数据,看不到市场趋势和竞品动向。我搞不清楚到底该把选品寄托在ERP上,还是另外买工具。
ERP不是选品神器,它的角色是选品的数据底座和流程载体。市场机会发现要靠外部数据源,比如平台榜单、第三方市场分析工具、竞品监控;合规和专利风险排查也需要专门渠道。ERP能做的是:沉淀你店铺的SKU级利润、库存周转、退货率、复购率,把这些数据喂进选品评分卡,对候选品做利润测算和供应链可行性判断。
正确做法是外部工具负责发现机会,ERP负责验证机会在你店铺里能不能赚钱,人工负责最终决策,三者缺一不可。
我们同时做亚马逊、独立站和TikTok Shop,在美西和美东各有一个海外仓,选型时销售说得天花乱坠,但我最怕的是上线后发现平台API对接不全、库存同步有延迟、海外仓数据不同步。有没有办法在签约前就判断出这些坑?
重点核实三件事。第一,平台API覆盖和同步频率:要求对方现场演示你正在做的每个平台的订单拉取和库存回传,确认同步延迟是多少分钟,是否支持你用的海外仓服务商。第二,多仓库存逻辑:能不能按仓库维度设置安全库存和补货规则,跨仓调拨是否有完整单据流。
第三,总拥有成本:不只看年费,要问清店铺数上限、订单量阶梯、API调用限制、额外模块费用、实施费和培训费。建议签约前要求两周试用期,用你自己的真实店铺数据跑一遍订单和库存同步,再决定是否买单。


读者评论
第0步定业务边界这点很戳我。我们去年上系统就是没想清楚铺货还是精品,结果库存池规则改了三次,SKU映射重做了两遍,白白拖了两个月。如果先花一周把业务边界和MVP范围写清楚,后面能省不少返工。
选品是验证器不是发现器,这个说法我认同。我们之前先买了选品工具,结果毛利算出来是正的,实际做完发现漏了佣金、广告和退货,真实利润差一大截。先把库存和财务口径打通再谈选品,顺序确实不能反。
库存准确率≥97%这个验收指标很实在。我们日出三百单左右就开始乱了,表格对账一周要二十多个小时,还出过超卖被平台罚。文章说拐点在三百单,跟我们的实际感受基本一致,手工表格确实是平方级成本。
比较认同总拥有成本那段。我们比价时只看了订阅费,后来数据迁移、接口开发和培训又追加了不少预算,算下来并不便宜。另外API调用频率和合规限制也是选型时必须提前问的,不然功能有但拿不到数据,等于白搭。