ERP系统：SKU产品库的两种设计方案

编辑导语：在做电商时，SKU产品库是大多数运营者会接触的系统，而在SKU产品库中，又有两种不同的设计方案，这二者又有何区别？

一、在线产品与本地产品

在聊SKU产品库的设计方案之前，我们先了解一下两个名词： 在线产品与本地产品。

在线产品，一般是指电商平台上的“商品管理”或者“产品管理”模块中产品。而与之相对应则是本地产品或者也叫做库存产品，就是指实际存放在仓储中的实体产品。

一般来说，电商平台上卖的产品就是实际放在仓库中的实体产品，那为什么要区分为两种产品进行管理呢？

如果是对于单店铺或者是单平台来说，这两者保持一致其实是没问题的。但是由于电商卖家往往会开设多个店铺，运营多个平台，以此来提升自己的曝光度，获取更多的流量，所以就需要在多个平台，多个店铺上架自己的产品。

多个平台，多个店铺之间为了避免相同的产品被平台检测为恶意铺货或者不同的平台规则不一样，就会衍生出不同的在线产品，它们本质上可能对应的是同一款产品，但是由于不同的平台规则限制，最终会导致产品的一些基础信息各不相同。
在跨境电商ERP中，不同平台的产品维护与管理统称为“刊登”或者“产品”。所以，当卖家需要经营多个平台，多个店铺的时候，就需要分别对不同的平台的产品进行管理。

马帮ERP

店小秘ERP

虽然在多个平台有多个不同的产品，但是实际卖家要卖的产品可能就是那么几个，也就是实际放在仓库中的产品数量并没有那么多。

当不同的平台的订单都进入到了ERP中之后，就会出现一个问题： 每个平台的订单中的产品都不一样，那么我应该实际发出哪一款产品给用户呢？

这就是涉及到“本地产品与在线产品”的映射问题了，在跨境电商ERP中，这种关系也叫做“商品匹配”或者“产品配对”。

即通过接口将所有在线产品都同步到一个公共池中，然后设置一些规则将这些在线产品与本地产品绑定起来，后续平台订单进来了之后，通过这一层绑定关系可以自动匹配出实际要发货的产品是哪个，这个实际要发出的产品，也就是标题中提到的“本地产品”或者也称“库存产品”。

店小秘的商品配对

二、两种设计方案介绍

经过我的调研和实践，如果需要搭建一套用来管理本地产品的“SKU产品库”，一般会有两种设计方案：

1. 平台型设计方案，类似于电商平台的产品管理模式，以SPU为主体；
2. 库存性设计方案，以实际的库存管理粒度为主体，即以SKU为主体。

跨境电商ERP中采用方案2的居多，是主流的做法，而采用方案1的比较少，不太常见。

下面我分别来介绍一下这两种设计方案的具体细节。

1. 平台型设计方案（以SPU为主体）

阿里巴巴国际站后台-产品管理

有赞后台-产品管理

淘宝千牛后台-产品管理

以上三张图都是很典型的电商后台产品管理的界面，每一行展示的都是一款产品（SPU）的主要信息，这个跟用户在前台看到的列表是相同的。

但是实际用户点击进去了之后就会发现，当要购买一款具体的产品的时候，ta还需要选择一些规格，这样才能确定最终的价格。这些逐个选择的规格，最后就组成了实际的SKU，也就是能确定具体的库存单位是哪个。

具体的操作路径如下图所示：

其中我了解的采用平台型设计方案ERP有：通途，金蝶等。

通途ERP-产品管理

金蝶星辰-产品管理

2. 库存型设计方案（以SKU为主体）

库存型设计方案是市面上最主流的，最常见的方案。无论是单品还是多规格品，在创建之后都会以SKU的维度展示，所有的信息也都是在SKU维度进行更新的。SPU只是在创建多规格产品的时候用来快捷生成多个SKU的载体而已，当生成了SKU之后，SPU也就几乎没啥作用了。

芒果店长ERP-产品管理

店小秘ERP-产品管理

马帮ERP-产品管理

三、两种设计方案的差异

如果只是单纯的看图似乎并看不出两种设计方案的差异在哪里，不过如果你对此话题比较感兴趣的话我建议你可以去申请一些试用账号体验一下，相信会对其中的细节有更深的理解的。在此，我用一些文字来解释一下其中的关键差异。

1. 展现方式不一样

平台型设计方案是以SPU为维度展示产品的，而库存型设计方案则是以SKU为维度展示产品的。如果以SPU为维度，那么一些差异性的细节就不好展示了，例如价格、重量、尺寸，库存、可用情况等，这些信息一般是跟SKU挂钩的。

2. 编辑方式不一样

平台型设计方案如果要编辑具体的产品信息，需要编辑两块的内容，一块是公共的数据，也就是所有SKU都继承的内容；另一块是单个SKU关联的信息，不同的规格组合对应的信息不一样，需要单独维护。

库存型设计方案则直接就到了最小库存单位粒度了，所有的信息都是独立的，可以各自维护的。例如41码的鞋子和42码的鞋子是不同的SKU，可以分别维护这两者的信息，而不用考虑公共信息继承的问题。

你可以把41码的那个SKU的名字改成“女鞋”，而42码的那个SKU的名字改成“老人鞋”，虽然从电商产品管理的角度来说这不合理，但是在ERP中却没有限制，因为它们的SKU没有变化。

3. 调用的方式不一样

平台型设计方案，在需要选择SKU的时候，要先选择SPU，然后通过选择不同的规格来确定想要的那个SKU；而库存型设计方案则简单多了，只需要直接选择相应的SKU即可。

先选择SPU，再选择规格确定SKU

直接选择SKU

4. 删除的逻辑不一样

平台型设计方案，如果需要删除SKU的时候，需要通过删除规格来删除SKU，而且需要在SPU的载体上操作；而库存型设计方案则直接选择对应的SKU即可删除，不会和SPU等有什么强关联的关系。

5.平台型设计方案的利弊

总结来说，库存管理的本质还是以SKU为最小粒度，无论是平台型设计方案还是库存型设计方案最后都是通过以管理SKU来达到管理实物的作用。

以SPU为载体，然后通过规格去确定SKU有一定的好处，也有很明显的弊端，这也是为什么主流的跨境电商ERP中都不太选用此方案的原因。

主要的利处和弊端分别如下：

利处：

• 维护产品资料的时候可以与平台产品的逻辑保持一致，便于用户上手和理解；
• 适用于多规格属性比较多的产品，可以通过先选择产品然后再通过规格来定位具体的SKU；
• 适用于需要维护比较丰富的产品资料的场景，因为很多资料都是在SPU的维度，这样可以减少重复维护的工作量。比较适合B2B的模式，需要使用产品库的内容给用户做报价。

弊端：

• 调用产品的时候会麻烦一点，需要通过选择SPU再选择SKU，还需要记忆相应的规格来确定最终的SKU；
• 编辑和维护的时候有两套入口，一个是SPU的入口，一个是SKU的入口，会比较麻烦一些，而且SKU的入库能维护的信息不多；
• 无规格的产品和多规格的产品并列展示的时候，需要后台做特殊处理，例如给无规格的产品也加上SPU+SKU的关系；
• 查看和展示的时候不够直观，尤其是放在仓库层面来使用的时候，仓库应该是以SKU的粒度来管理是最有效的，但是此处也需要做特殊处理，将SKU抽离出来，并排展示。

四、一些踩坑点

上面介绍完了两种设计方案的一些差异，如果是按照库存型设计方案来做，基本上市面上主流的跨境ERP都是这样做的，该踩的坑别人都踩过了，所以自己只要对着竞品走一遍后，踩坑几率就可以大大降低。

所以这里谈到的踩坑点是针对平台型设计方案来总结的，这一块网络上已有的资料比较少，而且采用这种做法的ERP也比较少，所以踩坑点就多了些。

1. 单规格产品与多规格产品的转化

单规格和多规格产品的不同就在于规格是否大于1种以上，如果是大于1种以上则是多规格，如果是只有一种规格则是单规格。

为了避免单规格和多规格的随意转化，影响关联的单据和历史数据等，一般跨境电商EPR创建产品的入口就会分成两个：“创建普通产品”和“创建多规格产品”。

创建普通产品则是在创建SPU的同时也创建了SKU，而且SKU的所有信息都是从SPU这里继承来的，此刻的SPU编码会和SKU编码一致，SPU的存在只是为了兼容，以致于表结构呈现一体性。

创建多规格产品，则是先创建SPU，然后通过规格的组合自动生成SKU，SPU编码和SKU编码不相同，而是SKU维度上需要填写相应的属性，例如成本价、销售价、期初库存、重量等。

2. 平台产品的接口字段兼容

以阿里巴巴国际站为例，国际站的产品接口中，当有平台产品有规格信息的时候，SKU信息是有的；当没有规格信息的时候，则SKU信息为空。

阿里巴巴国际产品接口示意图

倘若还有其他的平台，例如Amazon、Wish、eBay等，它们的产品接口中SKU的逻辑可能和阿里巴巴国际站一样，也可能不一样。

所以在设计本地的SKU产品库的时候，要考虑这种接口上的数据兼容，当平台的产品只有SPU没有SKU的时候，应该怎么与本地产品做映射。

3. 产品库的展示与编辑

平台上的产品管理都是以SPU的维度来管理的， 但是如果放在ERP或者仓库中，那么这种逻辑是否可以直接沿用，这个也是一个坑。

从我一段时间的调研和体验来说，以SPU维度展示和以SKU维度展示都应该要做，因为它们适用于不同的场景。

以SPU维度的展示可以放在基础的产品管理页面，类似于平台的产品管理。这样可以很方便的维护这些数据，编辑和查看都是从SPU的维度进去。

而以SKU维度的展示可以放在例如库存查询，库存流水，或者就叫做专门的“SKU产品管理”页面。可以单个的对SKU的一些信息维护，例如条形码，价格，库存信息，销售情况等。

SPU维度展示产品

SKU维度展示产品

#专栏作家#

vitamin，也自称“皮酱”，微信公众号：皮酱叨逼叨。目前是一位外贸SaaS领域的供应链产品经理，曾做过3年半的跨境仓储物流方向的产品。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载

题图来自 Unsplash，基于CC0协议