干货！9个实用的供应链中台设计经验分享

01、中台搭建的3个原则

在搭建中台系统时，需要遵守3个原则：

一、包容性。中台需要能支持各种业务的接入，且能允许不同业务之间的细微差异存在。不能接受业务差异的中台是不可靠的，尤其是供应链，需要支持不同平台的业务，各平台的业务规则存在一定的差异是在所难免的。

二、稳定性。中台应该是个相对中立的系统，不是为某个平台或业务量身定做，所以要必须保证主体结构的稳定性，不能跟着业务随意调整底层逻辑。

三、扩展性。中台系统不是一锤子买卖，用完即扔，也不是为某一个业务而单独设计的，所以在设计时要兼具扩展性和开放性，能够扩展更多场景、更多功能和更多业务。

02、9个实用的设计经验分享

下文为笔者在过往工作中用到的设计经验总结，供大家在日常需求过程中参考。

（1）能不能复用是中台价值衡量的一个很关键的参考因素。在梳理系统边界时，要将多业务通用功能提炼、抽象，并下沉至中台，而不通用的功能可以留给业务系统自行实现，保证中台的稳定和纯净。例如基础数据、仓库权限、库存等功能，都是各个业务通用的功能，便可以交由供应链中台统一来承接，避免业务重复建设。但如果每个接入的业务方有不同的业务规则，例如A业务要按仓库分配物流，B业务要按照地区分配物流，双方逻辑互斥无法达成共识时，可以将物流分配的功能扔给业务侧去处理，中台仅提供物流信息的输出和接收分配的结果。

（2）中台和平台最大的区别是平台只提供各种组件让业务自行组合，不参与业务，而中台则更贴合业务。在设计时，尽可能将跨系统的功能集成，为业务提供一站式解决方案，可以降低业务接入的难度。例如订单查询功能的集成、中央库存集成、跨系统取消订单功能集成等。

（3）当遇到某些业务无法完全统一的情况时，可以由中台负责整体节点控制，但在某些分支可以开放个性化的需求窗口给各业务侧来填充，这是设计模式中的工厂模式思想。例如订单下发至履约中心以后，有个订单审核的环节，用以疑似恶意订单的排查、异常订单的审核处理。由于每个业务对异常订单审核的标准不同，如果都由订单履约中心实现，则需要梳理所有业务侧的规则，这种业务规则并不是供应链中台应该关心的，便可以将特殊审核的逻辑开放给业务系统来实现，履约中心只需要在订单审核的节点上调用对应业务系统的接口来获取审核结果即可。如下图所示：

▲订单节点开放给业务系统示例

（4）当不同的业务需要走不同的流程时，可以通过链路配置的方式来实现。例如仓库入库支持到货登记、收货、验收、拍照、上架5个节点，但并不是所有的业务都需要这5步操作。于是我们就可以增加一张配置表，按照业务配置不同的链路，在仓储系统中入库时，便能按照此链路配置驱动不同业务走不同的入库流程了，当上一个节点操作完成后，系统会根据配置自动跳转到链路中的下一个节点。如图：

▲入库链路配置示例

（5）通用字符串与枚举值扩展新场景。当业务场景越来越多时，今天要按业务送精美礼品、明天要求按平台使用不同的包装，我们不能总是要求技术扩展新字段来记录新的业务，特别是订单这些关键表，每每调整可能都会影响上下游，但业务也不能不支持，那怎么办？可以定义一个长字符串，例如0000000000，这是1个10位的字符串，我们可以对每一位分配0-9，A到Z等不同的枚举值，每个值代表一种业务属性，例如第一位代表平台，第二位代表包装属性（普通包装、精美包装等），1000000000代表自营订单，2000000000代表三方平台订单，1100000000代表自营平台的精美包装，如上，位数可以不断扩充，枚举值也可以扩，还可以两位组合、三位组合搭配，这样就可以扩展无数的场景了。

（6）通用属性和扩展属性搭配妙用。不同的业务、不同的商品品类之间的差异一定是存在的，但作为中台需要兼容，该怎么办？我们可以把属性分为通用属性和扩展属性两组。所有业务和品类都通用的属性通过通用属性存储，每个品类个性化的属性用扩展属性存储，可以通过长串报文放到数据库中的一个字段中存储。这样通用数据和扩展属性搭配便能存储全品类商品信息了。例如在设计商品相关的功能时，商品编码、名称、类目是每个品类都必须的，这一类数据便放至通用属性中，而图书的版本、手机的网络制式、衣服的尺码等，属于每个品类特有属性，就通过扩展属性来存储。

不仅商品属性，标准订单状态+扩展订单状态、标准商品库+业务自有商品库、通用操作+个性化操作等场景都可以按此思路来设计，以达到供应链中台兼容不同业务的目标。

（7）通过扩展字段来适配不同的属性。再强大的系统也不可能囊括所有行业的业务属性，但可以留出空间给用户自定义。不同于上面将扩展属性通过长报文存到一个字段中，此设计思路是通过扩展不同的字段存储不同的属性，但数据库中的同一个扩展字段对应不同的业务存储的属性不同，此类设计在用友、金蝶等将软件服务商的产品形态上比较多见。

例如某产品在做商品属性设计时，在数据库中总共设计10个字段，前4个字段为固定字段，存储通用属性(商品ID、商品名称、规格、类目)，后6个扩展字段预留给用户自行配置，存储各行业个性化的属性。

现有A用户为手机行业，配置了扩展字段5-9，分别对应内存、容量、网络制式、主屏幕尺寸、运营商；B用户为服装行业，配置了扩展字段5-8，分别对应货号、尺寸、风格、材质。于是，A、B两个用户在使用系统时，便能分别看到不同的属性名称了，但在数据库中都是对应同样的扩展字段。

（8）灵活使用适配器保证供应链中台的稳定性。为了保证供应链中台内部逻辑的一致性，可以通过适配器来将外围各业务逻辑转换为供应链体系认可的标准，这样就能将差异放到供应链中台之外，不用供应链中台来迁就业务了，保证了中台架构的稳定性。通俗的说法就是映射。例如不同平台的地址库的统一、不同平台SKU编码的统一、不同业务订单状态的统一等，都可以通过适配器来进行转换。

（9）系统参数是个好东西。做中台，不可能百分百标准化，难免会遇到不同业务要求不同逻辑的情况，这时，就可以增加一张系统参数表，使用系统参数来配置不同的业务逻辑。例如：A仓订单需要合单，B仓订单不需要合单，为了同时应对两个仓的业务诉求，便可以增加一个”是否需要合单”的参数，配置为“是”则合单，为“否”则不合单，由A仓和B仓自行配置。

以上只是众多设计经验中的点滴，在供中台的搭建思想上，产品设计和架构设计思想是相通的，感兴趣的朋友可以多看一些设计模式方面的书籍，对提升我们自身的规划能力有极大的帮助。