商品系统架构设计part1
商品系统中最重要的两个概念，一个是SPU，一个是SKU，SPU和SKU相关的概念网上已经有很多的解释，不再赘述。
除此之外，还包含了后台类目，供货商（店铺/商家），仓库模块，属性库等模块
这篇主要是聊聊商品系统在实际业务中的整体设计思路。
商品系统设计首先要明确的几个点：
1、平台还是自营
2、现在和未来经营的类目是标品还是非标品
3、 公司经营的商品种类
4、是否有分仓发货业务，库存是否要绑定
明确了这几个问题后，我们就可以开始对整个系统做构建了。
1、电商自营和电商平台的区别
电商自营，意味着所有的item和sku都是由己方的运营控制，供货商也稳定为自营的一家，所以从常规意义上来说，电商平台一定需要SPU的模块，而自营电商不一定需要SPU模块。
SPU主要是用来解决相同商品多item的规格和描述信息统一的问题，并且方便运营做整个平台的商品管理。
后期的实际业务中，如果平台运营走的是类似天猫这样对商家控制比较严格的路子，商家在进行商品管理，也需要对商品可操作的SPU进行授权管理，以及分润比例控制。这些都是可以基于SPU进行的。
2、经营类目是标品还是非标品
如果加入了SPU的模块，则需要了解经营类目是标品还是非标品。如果是标品，则可以在SPU层面加入CSPU的概念，以达到进一步对商家可能发布的SKU的控制，确保平台的商品可靠性。
例：已知iPhone X 只有银色64G、银色256G、灰色64G、灰色256G这四种规格，那么平台是可以在设置iPhone X 的 SPU时，直接设置好iPhone X 下的这四个规格的CSPU。
这样商家在创建时可以直接结用这四个CSPU的信息进行商品创建，规范了平台商品的同时也达到了减少商家工作量的目的。
3、公司经营的商品种类
这个一般不会对SPU和SKU的结构关系造成影响，但是也是我们前期需要考虑的点。因为不同的商品种类可能会对之后的交易订单履约流程造成影响。（详见电商系统的模块化设计1
https://zhuanlan.zhihu.com/p/42520179）
简要归纳商品种类包含如下：
- 实物商品
- 服务（打车，团购）
- 虚拟资产（话费，游戏币）
- 信息（卡密、简历、数据）
一般电商平台我们常见的商品种类主要还是实物商品和虚拟资产，而服务类商品多见于线下O2O项目，信息类产品大多是垂直领域。
所以如果可能涉及到多种类的商品交易，则需要在设计SPU或item时就考虑到商品种类的设置。如果是在现有的系统基础上去新增商品类型，其实也可以通过指定后台类目商品类型的方式进行后续的订单履约业务。
4、是否有分仓发货业务，库存是否要绑定
同样的，这个业务也不会影响SPU和SKU的结构关系，但是在设计中也是很重要的点。
如果有分仓发货业务，则需要考虑以下几个要点：
- 仓与仓之间是否具备跨仓发货的条件
导致这个问题的可能性有很多，如成本高，距离过远则物流质量无法保证等。
如果不具备跨仓发货条件，那可能需要根据实际业务来对每个分仓设置其所配送区域范围（根据业务需求可以精确到省/市/区县/街道），再对上架SKU设置其在不同分仓的库存，或者自动同步仓库库存。而前台则需要用户确认自己所在的城市或收货区域，以用来查询上架SKU的库存情况，确认是否能加入购物车或是下单。
- 是否有商品具备特殊的配送范围
比如，分仓常规商品可以配送北上广。但是澳洲龙虾的生命力不如波士顿龙虾，只能在分仓同城配送。
这种情况下，配送范围就不能跟着仓库走，而应该跟着商品走。商品可以默认配送范围就是分仓的配送范围，但是也可以完全自定义。
- 实际运营业务中针对分仓的商品售卖是否会有价格差异。
比如波士顿龙虾的货物到岗清关是在上海，而针对波龙的销售除了江浙沪外，还有珠三角的业务，这时候需要将在上海清关的波龙在通过冷链干线运送到珠三角的水产仓/放养池。
那这部分珠三角和长三角的成本差异自然也会提现在最终售价里，从而变为同样的SKU由于销售城市的不同售价不同的情况。
如果出现这种情况，而运营又对精细化控制有要求的话，可能SKU的售价控制，就需要精确到市了。
其它：具体的公司结构、人事情况和运营业务策略也将决定系统结构搭建。
如：假如某些厂商自营2C电商系统，在实际操作中，使用生产产品管理人员和电商业务运营人员分属为两个不同的事业部时，可能会由产品管理人员录入产品信息——甚至是从生产管理系统中直接导入产品信息至电商系统。而由电商业务运营人员控制产品作为商品属性部分的售卖信息。这个时候，虽然可能sku很少，且是自营属性，但是由于业务流程和操作人员不同权限控制的需求，也需要搭建SPU-sku的系统结构。
如果大家对电商系统设计有什么心得想法或疑问，欢迎留言讨论交流。
