分销系统的建设：从 0 到 1 搭建全球化 B2B 分销平台的工程实践

一单跨境采买要跑 2~3 个月、十几个人肉协作；一套分销系统从立项到上线只用了 3 个月。这篇文章来聊聊：一个跨境 B2B 分销系统，到底应该解决什么问题、为什么这样设计、以及从 0 到 1 落地过程中我们踩过的认知陷阱。

一、为什么 DTC 出海绕不开 B2B

解释一下什么叫做DTC: DTC(Direct to Consumer), 指的是直接面向消费者的生产模式

在跨境电商领域，B2C 是最被津津乐道的模式。但真正把一个品牌”种”进一个新市场，往往绕不开 B2B——甚至 B2B2C。

为了帮助大家建立认知，我把常见的几种交易模式整理成下面这张表：

模式	定义	特点	典型代表
B2C	企业直接向最终消费者销售	通过自营网站、APP、线下店触达个人消费者	电商平台、餐饮、零售品牌
B2B	企业之间直接交易	交易规模大、合同复杂，客户即供应商	批发商、制造商、供应链服务商
B2B2C	通过中间商把产品送达消费者	一家企业作为入口，另一家企业承接分销	电商平台第三方卖家、1688、京东自营+POP
eB2B	通过电子手段进行的 B2B	强依赖在线平台、数字化工具与电子支付，强调在线化与协同	各类 SaaS 化采购平台、API 化供应链

传统 B2B 与 eB2B 的核心差异在于”数字化程度”和”在线化”。后者借助数字工具显著提升了交易效率和透明度，这也是今天几乎所有供应链升级的核心叙事。

二、故事的起点：印度市场与 Nykaa

我们团队在打开的第一个新兴市场，就是印度。

很多人对印度的第一印象是”下一个中国”——13 亿人口、移动互联网高速普及、电商渗透率快速攀升。但真正把一个海外品牌”种”进印度，挑战远不止”语言 + 支付 + 物流”这三个老生常谈的话题。

• 贸易政策：印度对外来品牌有相当多的合规和准入限制，特别是部分品类需要本地注册主体、本地仓储；
• 投资信心：海外投资者对印度市场存在结构性信心不足，更倾向与本土有实力的合作伙伴联姻；
• 本地团队：自建本地团队的成本、合规风险、跨文化沟通成本都很高。

综合权衡之后，我们选择了”借船出海”——与印度本土最大的美妆时尚平台 Nykaa 合作。Nykaa 在印度市场相当于”聚美优品”的角色：成立于 2012 年，总部在孟买，业务覆盖护肤、彩妆、香水、沐浴、奢侈品等品类，旗下还运营着面向零售商的 eB2B 批发平台。其主要的三个收入来源分别是：美容和个人护理业务、时尚业务，以及面向零售商的批发业务平台。

选择 Nykaa 的原因，除了品牌契合度高、用户基数大之外，还有一个非常现实的考量：Nykaa 自己就有 B2B 业务，他们理解批发逻辑，知道怎么把商品铺到线下门店、二级分销商、跨境零售网络中。这意味着合作中”教育对方”成本会低很多。

这便是这家品牌在 B2B 模式上的第一次尝试——内部称之为”印度采买”。

三、一单跑了 2~3 个月的”采买”是怎么发生的

在分销系统上线之前，每一次”印度采买”都是靠”人工智能”——也就是研发、业务、仓库三方的肉身协作——来完成的。整个流程大致是这样的：

业务确认商品 → 创建订单 → 多轮确认订单 → 打包装箱生成 Invoice → 合作方后台录入商品 → 物流商到仓库验货 → 财务付款 → 货到合作方仓库 QC

每个节点消耗的时间大致如下：

节点	关键动作	耗时（周）
业务确认商品筛选规则	每个 SPU 至少 N 件、N 个码；SKU 最少 M 件；定价、属性定义	1
创建订单	跟进并更新库存	1 ~ 2
确认订单	多轮确认不满足需求的款 → 锁定库存 → 敲定最终订单	1 ~ 2
打包装箱 + Invoice	仓库拣货装箱，研发出明细表与属性表	2 ~ 3
合作方后台录入商品信息	商品上架到合作方后台	2 ~ 3
物流商到仓库验货	现场 QC	1
合作方安排财务付款	走付款流程	2.5
货到合作方仓库、对方 QC	收货检验	—

从确认订单到完成交易，全链路大约需要 2~3 个月。一单下来，业务、产研、仓库前后十几个人要忙活半个月，仓库资源也会被长时间占用。

仔细看这个流程，你会发现一个有趣的现象：真正”创造价值”的环节（选品、定价、QC）只占其中很小一部分，大量时间被消耗在”信息同步 + 流程等待”上。这正是 eB2B 想要解决的核心问题——用数字化工具把”信息同步”和”流程等待”压缩到极致。

为什么一开始没有做系统？

这不是疏忽，而是有意为之的克制：

1. 模式未定型：第一次合作，第一次尝试 B2B，未来是否持续合作、模式是否可行都不确定。盲目投入系统建设，会形成沉没成本。
2. 业务复杂度不高：初期只需要”筛选出符合库存的 SKU → 锁定库存 → 仓库收发货”，暂不需要独立的操作系统。
3. 系统建设的优先级：在模式验证成功前，工程资源应该聚焦在核心 C 端业务。

痛点在哪里？

随着合作深入，痛点越来越无法忍受：

• 沟通成本高：跨时区、跨语种、跨团队，一封邮件往返经常要一两天；
• 研发反复造轮子：每次”采买”都要研发临时写代码筛品、跑脚本、生成报表；
• 人力消耗大：一单十几人参与半个月，且高度依赖关键人的经验；
• 仓库资源被占用：大货长时间压在仓库，影响正常出入库效率。

当合作的频次提升到”每季度一宗大货、单笔百万美元级”时，业务方明确提出：必须工程化。

四、立项：分销系统需要解决的四个核心问题

立项时，我们把目标拆解成了四个关键问题：

1. 支持批发 + 小包代发两种业务模式，覆盖大货与小单；
2. 提供分销商品管理、定价策略、订单结算、发货等基础能力；
3. 支持更多 B2B 场景的库存分配与调用，实现多渠道差异化价格政策；
4. 实现内外部组织协同，订单履约全流程节点管理。

这四个问题对应的，其实就是分销中台的四大支柱：业务模式灵活化、商品与价格中心化、库存多渠道化、履约协同可视化。

五、架构设计的核心思路

分销系统不是一个孤岛，它必须和 ERP、WMS、订单、商品、库存等内部系统协同。从”模式”层面看，核心设计思路是：

• 分销中台作为外部分销商的统一入口，屏蔽内部系统的复杂性；
• 统一商品中心 + 库存中心，复用 C 端能力，避免数据双写；
• 多渠道价格策略，按分销客户维度配置批发价、零售价、促销价；
• 全流程履约节点可视化，让分销商实时看到订单状态。

从”位置”上看，分销系统处在 ERP 内部系统与外部生态角色的中间层，向上要承接多个内部域（商品、库存、订单、履约），向下要面对多种外部合作方（电商平台、个人卖家）。

与”向上开放”的开放平台是同构的

值得指出的是，分销系统和 ERP 侧的供应链开放平台（向上游供应商开放）在设计哲学上是高度同构的：把内部系统能力以 API 化的方式开放给外部生态角色。

系统	服务对象	数据流向	核心能力
分销系统	下游分销商（电商平台/个人卖家）	内部系统 → 分销商	商品分发、批发代发、订单结算
供应链开放平台	上游供应商（MES 系统）	供应商 MES → 内部系统	生产进度、产能、采购协同

两者在鉴权、事件推送、API 网关上完全可以复用一套基础设施。供应链开放平台在鉴权设计上参考了飞书开放平台、微信开放平台的成熟做法：采用基于 access_token 的鉴权协议，事件内容用 AES-256-ECB 加密（先对 encryptKey 做 SHA256 得到密钥，再用 PKCS5Padding 填充后加密），订阅方通过事件订阅接收业务变更。这套机制几乎可以直接复用到分销系统。

如果你们也在做”向上开放 + 向下开放”的双向能力，强烈建议从一开始就抽象统一的”开放平台”基础设施，而不是为两个方向各做一套。

六、模式落地的三个关键认知

从立项到上线，整个过程踩过不少坑。回过头看，有三个认知是”早知道能少走一半弯路”的。

1. 先验证模式，再投入系统

“印度采买”这件事本身，就是用最小可行的人力跑通 1~2 个完整周期，先验证模式可行。如果一上来就投入系统建设，模式跑不通的话系统就成了沉没成本。

这也是为什么我把”一单跑了 2~3 个月”放在文章开头——它不是吐槽，而是用最便宜的方式验证了模式。等模式稳定了，再把成本算清楚（人力、沟通、错误率、仓库占用），用数据驱动立项。

2. 先拆依赖，再拆数据

WMS 拆分复盘中有个核心教训：先拆 RPC，再拆 SQL。

WMS（仓储管理系统）原本是 ERP 内部一个庞大的模块，十大子模块紧密耦合在一起、历史包袱重、不支持异地多部署。我们决定把它从 ERP 中独立出去，过程中发现：入库单依赖采购单、采购单又依赖采购计划 / 采购母单 / 供应商；出库依赖包裹、包裹依赖订单 / 物流……”共同依赖产品”这条线把所有东西都串在了一起。第一次尝试硬拆时陷入了”无限关联”——这要是硬搞，那还不如直接 CV 一份 ERP 出来。

最终的破局思路是：先做依赖梳理（RPC、MQ、Redis、XXL 等中间件的依赖关系全部列清楚），再把内部方法调用改造为 RPC 调用。这样既不需要同步新旧两套代码，又能随时上线验证。

这个教训在分销系统建设中同样适用。分销系统需要调用 ERP 的商品、库存、订单等多个内部域。如果这些调用还停留在”内部方法调用 + 共享数据库”的阶段，分销系统的独立部署根本无从谈起。

经验法则：当一个子系统需要”独立部署、独立伸缩、独立演进”时，先把跨系统的调用从”方法调用 + 共享库表”改造为”RPC + 独立库表”，再做后续的能力建设。

3. 上线策略比技术方案更重要

分销系统是跨部门项目（涉及 ERP、WMS、财务、仓库、合作方），上线策略是这类项目的”生命线”。我们采用的方式是：

• 应用层独立部署，不与原系统强耦合；
• 数据库初期共用，后期按业务域拆分；
• 依赖 RPC 化：将原本内部方法调用改造为远程调用；
• 流量可控：通过权限网关把特定人员的流量切到新环境验证，做到”秒级流量切换、随开随关”。

这套打法的核心是：充分测试 + 流量可控，随开随关。一旦新环境出问题，可以秒级切回旧环境，影响面被控制在一个很小的范围。

WMS 拆分的实战经验也印证了这一点：他们依靠权限网关把每个作业环节的特定人员的流量放到新环境验证，发现问题即刻关闭；MQ 消费通过统一 SDK 控制，仓库作业涉及实物流转，MQ 短时间无法消费对作业无影响，因此可以接受 10 分钟内的回滚。总的来说就是”充分规划 + 流量可控”。

七、上线即出单：模式验证的工程闭环

分销系统从立项到上线，研发周期大约 3 个月。上线第一天就出了第一单。

这是工程化对业务最直接的验证——以前靠”人工智能”半个月才完成的流程，现在系统跑通后几小时内就能完成。

更重要的是，上线不是终点，而是起点。分销系统上线后，合作的频次、订单的颗粒度、价格的灵活度都有了质的提升。原本只能”按季度做大货”，现在可以”按周做小单”；原本只能”统一批发价”，现在可以”按客户配置差异化价格策略”。

从”印度采买”这个单一场景出发，未来这套分销中台的能力还会延伸到其他海外市场、其他类型的合作方（线下零售商、个人代购、跨境 KOL）。这正是 eB2B 模式的核心想象力：一旦把 B2B 流程数字化、可配置化，规模化扩张的边际成本就会显著下降。

八、写给同样处境的工程师

如果你所在的团队也面临”是否要为 B2B 业务建一套系统”这个问题，我的建议是：

1. 先用”人工智能”验证模式：别一上来就投入系统建设，先用最小可行的人力跑通 1~2 个完整周期，验证模式可行；
2. 量化”人工成本”：把人力、沟通、错误率、仓库占用等隐性成本算清楚，用数据驱动立项；
3. 从”能用”到”好用”分阶段：第一版聚焦核心流程跑通，不要追求完美；第二版再考虑多渠道、多市场、复杂价格策略；
4. 复用而非重建：分销系统的商品中心、库存中心、订单履约节点，尽量复用 C 端成熟能力，避免重造轮子；
5. 先拆依赖，再拆数据：当子系统需要独立部署时，先把跨系统调用从”方法调用 + 共享库表”改造为”RPC + 独立库表”；
6. 上线策略比技术方案更重要：流量可控、秒级切换、可灰度的发布能力，是跨部门项目的”生命线”。

九、参考资料

• Nykaa 为什么能成为印度最成功的化妆品和时尚企业