原标题：蔬果撷取：跨境电商国外仓OTWB的此基础数据资料管理工作与递送
重要信息技术控制系统中的许多此基础统计数据保护和管理工作的组件常常不受倚重，尽管这几块的文本可能是稍稍单纯的，或是没因此注重的，但并不代表者着它不关键。特别是对于国外仓销售业务而言，此基础统计数据有十分大的促进作用。本文作者对跨境电商国外仓OTWB的此基础数据资料管理工作与递送展开分析，一起来看看。
一、此基础统计数据
通常而言，要构筑一套重要信息技术控制系统，最核心理念最关键的当然是销售流程和销售业务功能模块的实现，这个是用户最容易交互，也是最能直接体现价值的点。因此市售关于这几块的文本常常数据资料十分的多，例如WMS的nobres和拣货销售业务，是WMS十分核心理念的销售业务和功能点，而且市售也有十分多的参考数据资料，对许多初入行的朋友而言，尽管这几块比较难，但唉有可学习的东西做为支撑。
控制系统中的许多此基础统计数据保护和管理工作的组件常常就不因此受到人们的倚重了，许多人第一觉得是这个组件是此基础的校订改查罢了，没什么难度；甚至许多负责这几块销售业务的商品副经理们也会有这种“过劳”的觉得，觉得他们Farnese做去一直在做这些此基础统计数据，没有满足感，是舍弃了他们的天分。
但我对个人认为，此基础统计数据不仅仅是对国外仓销售业务而言有十分大的促进作用，对其它行业的商品也是有十分大的关键的。尽管这几块的文本可能是稍稍单纯的，或是没因此注重的，但并不代表者着它不关键。它只是在背后默默地加码，没有因此夺目罢了，做为商品副经理的我们，从此基础统计数据组件接掌，既是一个渐进熟悉销售业务控制系统的好方法，也是故意练他们底子的好机会。特别是对初级商品副经理而言，做好此基础统计数据相关的商品方案，其实也十分地锻炼对个人能力，也能掌握许多沙丘下的销售基本知识。
此基础统计数据是构建销售业务控制系统的前提，近似于人体中的血液一样，此基础统计数据遍及各处，源源不绝地提供控制系统运行的动力。对国外仓控制系统而言，通常情景的此基础统计数据有这么几个：
仓库 散货 物流渠道 地址重要信息 商品重要信息这些此基础统计数据通常而言单厢被超过2个以上的控制系统所使用，因此除了要考量统计数据在哪里保护，怎么管理工作之外，还须要考量其它控制系统初始化的问题。国外仓的OTWB如果销售业务规模覆盖的区域非常多的话，通常单厢采用分布式系统布署的方式，也是说相同的控制系统或是同一个控制系统的相同的组件可能会布署在相同的地区的伺服器上，这样就须要额外考量统计传输的速度，准确度，连续性和异常越俎代庖的逻辑等。
国外仓OTWB的控制系统交互示意图
1. 仓库
仓库的此基础重要信息，例如仓库名称，仓库编码，地址，收件人，时区，所使用的币种等。在WMS中，“仓库”是一个可以一直增加和修改的此基础数据资料，但实际上实体仓库是有限的，不可能无限增加。对仓库服务商而言，如果采购或是研发一套控制系统，能覆盖越多的仓库，因此这套控制系统平摊到每个仓库的成本就会很低。如果一套控制系统只用于一个仓库，因此单个仓库的重要信息技术成本就会很高了。
“仓库”这个统计数据在OTWB中，算是最此基础也最容易被忽略的一个此基础重要信息了。对国外仓WMS而言，通常会考量在仓库管理工作中保护“时区”的重要信息，因为国外仓分布在相同的国家/地区，有些时候为了照顾当地的用户，因此须要将WMS中的一些时间转化为本地时间展示，因此就须要借助仓库管理工作中的“时区”这个字段的重要信息。OTWB中存储的标准时间通常是北京时间，因为大多数控制系统的用户都在国内，也是“UTC+8”的时间，然后根据相同的国外仓的所属的时区进行换算即可。
2. 散货
散货也可以称之为客户，通常是客户将货物放在仓库中，然后仓库服务商根据对应的指令来操作客户的货物。不过，仓库服务商也可以只服务于他们，也是他们建设仓库给他们内部销售业务所使用，这个时候散货是他们。
因此对仓库管理工作而言，会有“单散货”和“多散货”的概念，单散货相当于仓库是给某个客户专用的，而多散货是多个客户共享仓库的资源。
如果是单散货的体系下，可以不用“散货”这个词，相当于默认所有的货物都是属于一对个人的，就不须要单独用一个“散货”的字段来做区分了。但如果是多散货的体系下，因此散货这个字段就十分的关键的，如果没有这字段，就分不清某个货物到底是属于谁的，这样也不利于后续的结算。
对第三方国外仓服务商而言，它们的主要盈利方式是为客户订单履约提供仓储物流服务，因此肯定是会有客户的，于是就要在控制系统中保护“散货”的重要信息，有一些国外仓控制系统也称之为“客户管理工作”，都是一个意思。
3. 物流渠道
客户的订单指令会推送到仓库，需要仓库按要求去履约发货，仓库除了要拿到准确的货物和数量之外，还要按要求贴上对应的物流商的面单。面单是电子快递单，在控制系统中通常是一个PDF文件或是PNG图片。
在国外仓实际经营中，相同的仓库在相同的国家或地区，货物的体积重量类型等不一样，因此选择的物流服务商和对应物流渠道也会不一样。物流渠道做为很关键的此基础重要信息，是须要提前保护在控制系统中的。
一个物流商下会有物流服务（物流渠道）
除了此基础的物流渠道重要信息之外，还须要保护关键仓库-物流渠道的关联关系，甚至做的细节的时候，还须要保护客户-仓库-物流渠道的关系。
客户-仓库-渠道的关系
渠道重要信息通常包含渠道编码，渠道名称，渠道授权重要信息，渠道的时效，渠道运输的范围等，可以围绕渠道做许多销售业务的拓展。
4. 地址
因此，如果要构筑一套国外仓控制系统，提前准备好一套全球国家统计数据+重点国家的省/州+城市的统计数据十分关键，一方面可以提升用户录入统计数据的效率，另一方面也可以在这份此基础统计数据上做一些对照校验，避免在地址方面耽误太多的时间。
对美国电商而言，还有一些公司会专门做一些插件区解析地址，同时判定该地址的类型是住宅地址还是商业地址，因为相同的地址类型涉及到计费也不一样。FedEx和UPS在美国的住宅地址和商业地址的判定规则就有细微的不太一样，因此须要额外对接挺多的物流商接口才能确定这些重要信息。
美国的省州统计数据关系表
如果搞不到一些重点国家的省州+城市联动统计数据，因此可以退而求其次把国家+省州的统计数据保护好，这样也能提升许多用户体验了。一些重点国家+省州的联动统计数据，我放在了语雀知识库中，感兴趣的朋友可以看这个链接。
5. 商品数据资料
尽管WMS是叫作仓库管理工作控制系统，但是仓库中管理工作的核心理念还是实际的货物，有些控制系统中叫做商品，有些叫货品，我在此统一定义为商品。
仓库须要对实际的商品进行管理工作，因此WMS中商品数据资料可以称得上是最核心理念、最必备的此基础数据资料了。
WMS的商品数据资料涉及到的字段不会许多，特别是国外仓不须要精细化管理工作和运营的情景下。通常可以将商品数据资料分成这么几大类：
此基础重要信息，例如SKU，商品名称，英文名称，图片，备注等 规格重要信息，例如尺寸，重量 条码重要信息，例如EAN/UPC，FNSKU，其它条码等 申报重要信息，例如申报中文名，申报英文名，申报价格，海关编码，原产地，是否危险品等 一些控制重要信息，例如效期管理工作，SN管理工作，出入库的作业要求等产品数据资料通常是由客户提供的，因此通常都是在OMS端录入，但须要用到商品数据资料的控制系统许多，基本上所有的销售业务控制系统（OTWB）都须要用到这个统计数据，只不过有一些控制系统用的多，有一些控制系统用的少一些，因此商品数据资料就涉及到此基础统计数据的递送问题，须要重点注意一下。
二、此基础重要信息的创建与递送
上述提到的一些此基础统计数据，在多个控制系统中单厢须要用到，有一些统计数据是须要同步到下游的控制系统中的，这里就涉及到了一些统计数据的递送销售业务，我们先讲一下统计数据递送这几块的文本。
通常而言，如果OTWB都是布署在一个伺服器中或是共同初始化的都是一个统计数据库中统计数据，因此此基础重要信息的递送就很单纯了，只须要分别去请求统计数据库中的对应的此基础统计数据表即可。
但对国外仓而言，由于仓库是分布在国外相同的国家/地区，因此就会涉及到多站点布署的问题。关于多站点布署的这几块，其实还是有一些很容易踩的坑，当时我在做这几块的文本的时候还花了挺多时间和心思去规避这个问题。
市售主流的做法有两种，一种是将此基础统计数据的递送放在WMS中，另一种做法是将此基础统计数据的递送放在单独的一个控制系统，例如公共统计数据平台或是运营管理工作控制系统中。例如国外仓SaaS WMS领域中的老大哥——易仓WMS是选择将此基础数据放在WMS中，WMS中除了作业相关的统计数据，还有仓库，客户（散货），物流，地址，商品，费用等组件。
易仓WMS示意图
这种设计模式的好处明显，坏处也很明显。
好处是，一个控制系统包揽了许多角色要操作的文本，通过相同的权限去控制，这样更利于集中管理工作和保护。
但缺点也许多，首先是对管理工作员或是权限比非常多的角色登录了这个控制系统之后，会发现有许多功能菜单，会导致上手学习的难度十分高；其次是这种设计背后有一个很尴尬的问题，是多国访问的速度问题。例如把WMS放在香港的伺服器，然后美国，欧洲，拉美，东南亚等地区访问的时候速度会慢。而且还是SaaS多租户的模式，就会导致资源很紧张，控制系统负担很重。
另一种做法是将此基础统计数据的递送放在单独的一个控制系统，例如公共统计数据平台或是运营管理工作控制系统中，然后由公共统计数据平台对外提供统一的初始化接口或是递送接口。我所经历的两家公司都是用的这种方式，据我了解“递四方（4PX）”的WMS也是用的这种解耦的模式。
此基础统计数据放在公共统计数据平台中
上面讲到，此基础统计数据包含有：
仓库统计数据 散货统计数据 物流渠道统计数据 地址重要信息统计数据 商品数据资料统计数据 ……客户之外，其它的统计数据都是可以让国外仓服务商的运营人员他们去创建的，因此这些此基础统计数据的创建放在运营管理工作控制系统中是最好的，我把这个控制系统定义为OMP，即Operation Management Platform（运营管理工作平台）。
而商品数据资料是客户创建的，因此自然是放在OMS中去创建了，不过由于有一些仓库须要对客户的创建的商品数据资料进行前置审核，因此OMS创建的商品数据资料也会同步一份到OMP中，然后再由OMP执行统一的统计数据递送即可。
此基础统计数据的创建与递送
除此之外，还有一种更加细节的优化方式，可以考量将OMS的的商品数据资料组件和OMP打通，相当于两个控制系统共用的是一份统计数据，OMS可以看到这份统计数据，OMP看到的也是这份统计数据，然后借助OMP对外的这种递送能力去推送到相同的控制系统中。
例如OMP可以推送商品数据资料到WMS中，可以推送到BMS中，也可以推送到TMS中，不过通常TMS用不上这些重要信息，只须要OMS在物流下单的时候带上一些商品的此基础重要信息过去即可。这类重要信息通常都是和物流报关/清关、还有费用计算，保险索赔有关系的，例如尺寸、重量，是否带电，申报价值，海关编码等。
三、此基础统计数据递送一些注意事项 1. 推送方
要考量清楚，数据是在哪里创建？是由谁推送给谁？此基础统计数据的创建入口最好要做收敛，不是越多越好。 什么时候推送？是创建之后就立马推送，还是定时推送，还是通过某个按钮点击之后或是是状态更新之后才推送，商品副经理要定义好这些统计数据的推送时机。 2. 接收方 谁须要这些重要信息，接收方是谁？如果有多个接收方，因此相同的接收方的处理逻辑都要单独梳理一下。 接收方怎么接收这些统计数据，这些统计数据从哪里来？是不是已经有提供好了接口？ 一次接收的统计数据量会不会太大？会不会有更新的情况，更新了要怎么接收？ 3. 容错机制的设计 如果统计数据推送失败了，接收者没有收到统计数据怎么办？这种异常流程要怎么处理？ 是否有重试或是越俎代庖的策略？针对统计数据同步方面，要多和技术沟通一些容错机制，尽量规避这种问题的出现。 4. 监测逻辑的补充 如果报错了，失败了，有没有做监控，会不会及时提醒？谁来接收这些重要信息，然后及时处理？这几块也要和技术还有运维同事沟通清楚，商品副经理要有这样的销售业务敏感性。 能不能统计到某个接口报错的频率，后续可以专项处理，升级优化？出现问题之后要及时解决，避免下次再重现。上面提到的此基础统计数据，都是指OTWB多个控制系统之间单厢用到公共统计数据，但如果是WMS中创建的此基础统计数据通常都是仅限限于仓库本身所使用，因此是哪个仓库创建的，就哪个仓库使用即可，不须要特殊考量递送的问题，这些统计数据通常是：
库区、库位 容器 播种墙 包材 员工重要信息 ……在下篇文章中，我将详细给大家介绍一下这几块的文本。
专栏作家
维他命（VitaminERP等领域，撷取跨境和供应链相关的商品知识。
题图来自Unsplash，基于 CC0 协议。
