基礎數據

一般來說，要搭建一套信息化系統，最核心最關鍵的當然是業務流程和業務功能模塊的實現，這個是用戶最容易感知，也是最能直接體現價值的點。所以市面上關于這一塊的內容往往資料非常的多，例如WMS的波次和揀貨業務，就是WMS非常核心的業務和功能點，而且市面上也有非常多的參考資料，對于很多初入行的朋友來說，雖然這一塊比較難，但是好歹有可學習的東西作為支撐。

系統中的很多基礎數據維護和管理的模塊往往就不那么受到人們的重視了，很多人第一感覺就是這個模塊就是基礎的增刪改查而已，沒什么難度；甚至很多負責這一塊業務的產品經理們也會有這種“大材小用”的感覺，覺得自己做來做去一直在做這些基礎數據，沒有成就感，是埋沒了自己的才華。

但是我個人認為，基礎數據不僅僅是對于海外倉業務而言有非常大的作用，對其他行業的產品也是有非常大的重要的。雖然這一塊的內容可能是稍微簡單的，或者沒那么突出的，但是并不代表著它不重要。它只是在背后默默發力，沒有那么耀眼而已，作為產品經理的我們，從基礎數據模塊接手，既是一個循序漸進熟悉業務系統的好方法，也是刻意練習自己基本功的好機會。尤其是對初級產品經理來說，做好基礎數據相關的產品方案，其實也非常地鍛煉個人能力，也能掌握很多冰山下的業務知識。

基礎數據是構建業務系統的前提，類似于人體中的血液一樣，基礎數據遍布各處，源源不斷地提供系統運轉的動力。對于海外倉系統而言，一般場景的基礎數據有這么幾個：

1. 倉庫

2. 貨主

3. 物流渠道

4. 地址信息

5. 產品信息

這些基礎數據一般來說都會被超過2個以上的系統所使用，所以除了要考慮數據在哪里維護，怎么管理之外，還需要考慮其他系統調用的問題。海外倉的OTWB如果業務量覆蓋的區域較多的話，一般都會采用分布式部署的方式，也就是說不同的系統或者同一個系統的不同的模塊可能會部署在不同的地區的服務器上，這樣就需要額外考慮數據傳輸的速度，準確率，一致性和異常兜底的邏輯等。

倉庫

倉庫的基礎信息，例如倉庫名稱，倉庫編碼，地址，收件人，時區，所使用的幣種等。在WMS中，“倉庫”是一個可以一直增加和修改的基礎資料，但是實際上實體倉庫是有限的，不可能無限增加。對于倉庫服務商來說，如果采購或者研發一套系統，能覆蓋越多的倉庫，那么這套系統平攤到每個倉庫的成本就會很低。如果一套系統只用于一個倉庫，那么單個倉庫的信息化成本就會很高了。

“倉庫”這個數據在OTWB中，算是最基礎也最容易被忽略的一個基礎信息了。對于海外倉WMS來說，一般會考慮在倉庫管理中維護“時區”的信息，因為海外倉分布在不同的國家/地區，有些時候為了照顧當地的用戶，所以需要將WMS中的一些時間轉化為本地時間展示，所以就需要借助倉庫管理中的“時區”這個字段的信息。OTWB中存儲的標準時間一般是北京時間，因為大多數系統的用戶都在國內，也就是“UTC+8”的時間，然后根據不同的海外倉的所屬的時區進行換算即可。

貨主

貨主也可以稱之為客戶，一般是客戶將貨物放在倉庫中，然后倉庫服務商根據對應的指令來操作客戶的貨物。不過，倉庫服務商也可以只服務于自己，也就是自己建設倉庫給自己內部業務所使用，這個時候貨主就是自己。

所以對于倉庫管理來說，會有“單貨主”和“多貨主”的概念，單貨主相當于倉庫就是給某個客戶專用的，而多貨主就是多個客戶共享倉庫的資源。

如果是單貨主的體系下，可以不用“貨主”這個詞，相當于默認所有的貨物都是屬于一個人的，就不需要單獨用一個“貨主”的字段來做區分了。但是如果是多貨主的體系下，那么貨主這個字段就非常的重要的，如果沒有這字段，就分不清某個貨物到底是屬于誰的，這樣也不利于后續的結算。

對于第三方海外倉服務商來說，它們的主要盈利方式就是為客戶訂單履約提供倉儲物流服務，所以肯定是會有客戶的，于是就要在系統中維護“貨主”的信息，有一些海外倉系統也稱之為“客戶管理”，都是一個意思。

物流渠道

客戶的訂單指令會推送到倉庫，需要倉庫按要求去履約發貨，倉庫除了要拿到準確的貨物和數量之外，還要按要求貼上對應的物流商的面單。面單就是電子快遞單，在系統中一般是一個PDF文件或者PNG圖片。

在海外倉實際經營中，不同的倉庫在不同的國家或地區，貨物的體積重量類型等不一樣，所以選擇的物流服務商和對應物流渠道也會不一樣。物流渠道作為很關鍵的基礎信息，是需要提前維護在系統中的。

除了基礎的物流渠道信息之外，還需要維護關鍵倉庫-物流渠道的關聯關系，甚至做的細節的時候，還需要維護客戶-倉庫-物流渠道的關系。

渠道信息一般包含渠道編碼，渠道名稱，渠道授權信息，渠道的時效，渠道運輸的范圍等，可以圍繞渠道做很多業務的拓展。

地址

對于國內電商來說，中國的省-市-縣區的三級聯動數據已經很成熟了，有一些免費的且準確的數據，再加上國內的地址規范相對來說還是比較標準的。所以在向物流商獲取面單的時候，因為地址信息不合規或者填寫錯誤而導致獲取失敗的場景比較少的。

但是對于跨境電商來說，包裹會發到全球國家或地區，不同國家/地區的地址錄入方式，語種，必填的字段等都不太一樣，所以就在向物流商獲取面單的過程中，因為地址不合規或者填寫錯誤等原因而導致獲取失敗的場景很多。

所以，如果要搭建一套海外倉系統，提前準備好一套全球國家數據+重點國家的省/州+城市的數據非常重要，一方面可以提升用戶錄入數據的效率，另一方面也可以在這份基礎數據上做一些對照校驗，避免在地址方面耽誤太多的時間。

對于美國電商來說，還有一些公司會專門做一些插件區解析地址，同時判定該地址的類型是住宅地址還是商業地址，因為不同的地址類型涉及到計費也不一樣。FedEx和UPS在美國的住宅地址和商業地址的判定規則就有細微的不太一樣，所以需要額外對接挺多的物流商接口才能確定這些信息。

如果搞不到一些重點國家的省州+城市聯動數據，那么可以退而求其次把國家+省州的數據維護好，這樣也能提升很多用戶體驗了。一些重點國家+省州的聯動數據，我放在了語雀知識庫中，感興趣的朋友可以看這個鏈接。

https://www.yuque.com/jiaowovitamin/uizu4s/rdevgq67g6yhm0yr#GF9k

產品資料

雖然WMS是叫作倉庫管理系統，但是倉庫中管理的核心還是實際的貨物，有些系統中叫做商品，有些叫貨品，我在此統一定義為產品。

倉庫需要對實際的產品進行管理，所以WMS中產品資料可以稱得上是最核心、最必備的基礎資料了。

WMS的產品資料涉及到的字段不會很多，尤其是海外倉不需要精細化管理和運營的場景下。一般可以將產品資料分成這么幾大類：

1. 基礎信息，例如SKU，商品名稱，英文名稱，圖片，備注等

2. 規格信息，例如尺寸，重量

3. 條碼信息，例如EAN/UPC，FNSKU，其他條碼等

4. 申報信息，例如申報中文名，申報英文名，申報價格，海關編碼，原產地，是否危險品等

5. 一些控制信息，例如效期管理，SN管理，出入庫的作業要求等

產品資料一般是由客戶提供的，所以一般都是在OMS端錄入，但是需要用到產品資料的系統很多，基本上所有的業務系統（OTWB）都需要用到這個數據，只不過有一些系統用的多，有一些系統用的少一些，所以產品資料就涉及到基礎數據的分發問題，需要重點注意一下。

基礎信息的創建與分發

上述提到的一些基礎數據，在多個系統中都會需要用到，有一些數據是需要同步到下游的系統中的，這里就涉及到了一些數據的分發業務，我們先講一下數據分發這一塊的內容。

一般來說，如果OTWB都是部署在一個服務器中或者共同調用的都是一個數據庫中數據，那么基礎信息的分發就很簡單了，只需要分別去請求數據庫中的對應的基礎數據表即可。

但是對于海外倉來說，由于倉庫是分布在海外不同的國家/地區，那么就會涉及到多站點部署的問題。關于多站點部署的這一塊，其實還是有一些很容易踩的坑，當時我在做這一塊的內容的時候還花了挺多時間和心思去規避這個問題。

市面上主流的做法有兩種，一種是將基礎數據的分發放在WMS中，另一種做法是將基礎數據的分發放在單獨的一個系統，例如公共數據平臺或者運營管理系統中。例如海外倉SaaS WMS領域中的老大哥——易倉WMS就是選擇將基礎數據放在WMS中，WMS中除了作業相關的數據，還有倉庫，客戶（貨主），物流，地址，產品，費用等模塊。

這種設計模式的好處明顯，壞處也很明顯。

好處就是，一個系統包攬了很多角色要操作的內容，通過不同的權限去控制，這樣更利于集中管理和維護。

但是缺點也很多，首先就是對于管理員或者權限比較多的角色登錄了這個系統之后，會發現有很多功能菜單，會導致上手學習的難度非常高；其次就是這種設計背后有一個很尷尬的問題，就是多國訪問的速度問題。例如把WMS放在香港的服務器，然后美國，歐洲，拉美，東南亞等地區訪問的時候速度會慢。而且還是SaaS多租戶的模式，就會導致資源很緊張，系統負擔很重。

另一種做法是將基礎數據的分發放在單獨的一個系統，例如公共數據平臺或者運營管理系統中，然后由公共數據平臺對外提供統一的調用接口或者分發接口。我所經歷的兩家公司都是用的這種方式，據我了解“遞四方（4PX）”的WMS也是用的這種解耦的模式。

上面講到，基礎數據包含有：

1. 倉庫數據

2. 貨主數據

3. 物流渠道數據

4. 地址信息數據

5. 產品資料數據

6. ……

其中除了產品資料數據來源于客戶之外，其他的數據都是可以讓海外倉服務商的運營人員自己去創建的，所以這些基礎數據的創建放在運營管理系統中是最好的，我把這個系統定義為OMP，即Operation Management Platform（運營管理平臺）。

而產品資料是客戶創建的，那么自然是放在OMS中去創建了，不過由于有一些倉庫需要對客戶的創建的產品資料進行前置審核，所以OMS創建的產品資料也會同步一份到OMP中，然后再由OMP執行統一的數據分發即可。

除此之外，還有一種更加細節的優化方式，可以考慮將OMS的的產品資料模塊和OMP打通，相當于兩個系統共用的是一份數據，OMS可以看到這份數據，OMP看到的也是這份數據，然后借助OMP對外的這種分發能力去推送到不同的系統中。

例如OMP可以推送產品資料到WMS中，可以推送到BMS中，也可以推送到TMS中，不過一般TMS用不上這些信息，只需要OMS在物流下單的時候帶上一些產品的基礎信息過去即可。這類信息一般都是和物流報關/清關、還有費用計算，保險索賠有關系的，例如尺寸、重量，是否帶電，申報價值，海關編碼等。

基礎數據分發一些注意事項

推送方

1. 要考慮清楚，數據是在哪里創建？是由誰推送給誰？基礎數據的創建入口最好要做收斂，不是越多越好。

2. 什么時候推送？是創建之后就立馬推送，還是定時推送，還是通過某個按鈕點擊之后或者是狀態更新之后才推送，產品經理要定義好這些數據的推送時機。

接收方

1. 誰需要這些信息，接收方是誰？如果有多個接收方，那么不同的接收方的處理邏輯都要單獨梳理一下。

2. 接收方怎么接收這些數據，這些數據從哪里來？是不是已經有提供好了接口？

3. 一次接收的數據量會不會太大？會不會有更新的情況，更新了要怎么接收？

容錯機制的設計

1. 如果數據推送失敗了，接收者沒有收到數據怎么辦？這種異常流程要怎么處理？

2. 是否有重試或者兜底的策略？針對數據同步方面，要多和技術溝通一些容錯機制，盡量規避這種問題的出現。

監測邏輯的補充

1. 如果報錯了，失敗了，有沒有做監控，會不會及時提醒？誰來接收這些信息，然后及時處理？這一塊也要和技術還有運維同事溝通清楚，產品經理要有這樣的業務敏感性。

2. 能不能統計到某個接口報錯的頻率，后續可以專項處理，升級優化？出現問題之后要及時解決，避免下次再重現。

上面提到的基礎數據，都是指OTWB多個系統之間都會用到公共數據，但是如果是WMS中創建的基礎數據一般都是僅限限于倉庫本身所使用，所以是哪個倉庫創建的，就哪個倉庫使用即可，不需要特殊考慮分發的問題，這些數據一般是：

1. 庫區、庫位

2. 容器

3. 播種墻

4. 包材

5. 員工信息

6. ……