編輯導語：隨着支付寶小前台，大中台的概念獲得成功實踐後，越來越多的企業進入到中台搭建的領域？本文作者結合具體中台商品中心搭建案例，向大家展示了具體的搭建步驟，並對過程中需要注意的問題進行了總結，供大家一同參考和學習。
在商品中心搭建的上篇（《中台產品經理實戰（9）：從零開始中台商品中心搭建（上）》）我們完成了中台商品中心的需求分析後，本篇開始我們就可以進入商品中心的設計與建設過程了。
具體來説，我們商品服務中心的搭建分為如下的兩步：
也就是需要面對並處理不同業務線的需求差異（以下僅摘取了部分差異性需求）：
（1）在商城展示中，有的業務線商品為固定包裝產品如啤酒會展示淨含量等單位，但是這個字段是否需要複用，如果複用了其他生鮮類業務線經常出現的生鮮品如整雞等約5-6斤，淨含量怎麼填寫？
（2）在供應鏈管理中，通常為最小存儲單元進行庫存管理，如瓶，但同時其他業務線也會出現按箱出入庫的現實情況（越級），此時箱作為一級封裝，如果再出現多箱打包為組的二級封裝，此時以什麼揀貨單位進行揀貨？
（3）每個業務線的商品類目在用户商城前台都有自己的一套分類體系，此時與後台訴求完全不一樣（各業務線用户展示與運營需求）
通過調研，我們可以發現不同產品線對於商品管理的訴求，本質上來説是偏重於不同角色的需求，也就是有的業務線可能對供應鏈管理有特殊要求如需要按箱入庫，有的業務線需要在前台增加更多運營屬性，如特殊的商品的分類。
因此總結下來，一箇中台中的商品服務中心的商品管理需要通盤解決上述的問題與角色可以總結為下表：
解決上述的問題與角色，首先我們需要確定商品的基本結構，也就是日常電商中商品管理功能大家都是怎麼去設計的？
其實對於商品來説當我們站在一定的高度上去看，可以發現任何商品管理的基本結構就是下面三個部分：
（1）商品定位：如何快速在龐大的商品庫中找到需要的商品；
（2）標識商品：很多時候僅依靠命名會存在很多相似的商品，如可樂1瓶/可樂1大瓶，此時要如何將相似商品進行區分標識出來，在後續系統中流轉不會出現錯誤；
（3）商品特性：完整的商品就像一個海膽，每一個尖觸角都像一個特性都會被有對應的需要的人捕捉，從而完成自己的業務。
那麼上面這三個需求翻譯成產品的語言其實就是：
明確了需要兼容的範圍，如何設計中台解決方案呢？下面我們一個個來拆解：
1. SPU/SKU體系這個部分可以算是中台商品服務中最為簡單的設計，為了統一管理全公司多業務線的商品，在中台中只需要建立起唯一的商品創建中心，也就是交由一處進行統一化管理，此時各個業務線的新增產品必須由商品創建中心創建，創建後併發布成為正式的商品。
特別的當有多個業務線創建相同商品且共同維護庫存時，本質上這樣的模式優勢就凸顯出來了，如下圖：
可以看到我們實現一個實物映射了多個不同業務線的售賣物，不管業務線中可樂商品是什麼叫法對於供應鏈來説只有一個SKU的可樂，這不僅實現了實物的歸一化管理，也實現了全局實物庫存的共享。
2. 類目類目管理必須拆解為前台類目與後台類目兩類，其中後台類目也被稱之為商品固有分類，也就是按照全公司的標準進行分類的，用於給供應鏈統一維護。
也就是説不管各前台如何將可樂這個商品放在哪個類目下，在後台類目中可樂永遠存在在如下類目中：
而中台維護的就是這個標準類目，提供全局最標準的類目，到這可以看到中台其實還起到全公司的標準制定的重要作用。
有了這個標準的後台類目後，各業務線在獲取到該商品後可以在自己的業務中自己維護一套類目。
3. 商品屬性解決完了前兩項，我們就來到了商品屬性設計的部分。
如果對商品的屬性下一個定義的話：商品屬性本質就是描述商品特徵與為對應業務觸發提供標識。
例如商品温層屬性：常温、冷藏、冷凍，就是提醒倉庫作業人員到底應該去哪個庫區存儲該商品。
可以説這一部分可以算是商品服務中心中最難處理的環節，因為它和具體的業務線是強相關的，每個業務線可能都有自己的特性需求，例如有些業務線是面向大客户，因此是按大包規售賣，不零賣，而有些業務線又是大小包規都會售賣。
也就是在前文我們定義的需要通盤解決的問題與角色，本質上就是由商品的基本屬性來承載不同角色需要解決的問題：
理清楚了思路，那麼這一步要如何兼容這些不同業務線之間的需求呢？
這裏使用的方法也就是在我撰寫的《中台產品經理寶典》一書中提到的——中台核心公式：Summary – Details設計方法，通俗來説也就是中台維護摘要信息，具體的詳細屬性由業務線自主賦予。
05 建設：屬性項分離要去實現Summary – Details的商品屬性設計模式，我們就需要拆解下現有的SKU屬性解決方式，這裏先借用網上找到的一張圖來描述下，通用的商品屬性是怎麼構成的：
可以看到在商品屬性中，通常分為了屬性項組->屬性項->屬性值三個部分，其中：
（1）屬性項組是為了進行分組，方便進行同類型集中管理；
（2）屬性項是具體的類型屬性，最小業務類型承載單元；
（3）屬性值是指具體某個業務含義的數據化承載；
明白了通用設計後，我們也可以參照這種通用的框架，對中台商品中心中的屬性部分進行建設。
步驟1：定義屬性項組
我們按照兩個維度進行屬性分組
維度1：按維護角色進行分組
SKU屬性 = 中台屬性（Summary） + 業務線屬性（Details）
説明：
（1）中台屬性解決標準問題，比如該SKU的產地，生產日期，大小，體積，各個業務線統一的打包配置等；
（2）業務線屬性根據自己的需要去定義對應屬性，如前台對商品的特殊描述：別名；
維度2：按屬性特性進行分組
SKU屬性 = 基礎屬性 + 業務屬性
説明：
（1）基礎屬性：指商品的固定的物理屬性，這也是中台屬性的組成部分；
（2）業務屬性：為了業務需要而賦予商品的相關屬性；
中台的統一屬性 = 商品的固定的物理屬性 + 公司內部各業務線對該屬性達成的共識的業務屬性（沉澱的公司內部規範）
我舉個例子來幫大家理解下共識類屬性的含義，在生鮮行業中，一般帶有倉內加工的電商中都會涉及到一個商品標品化的過程，也就是由非標品到標品過程。
比如，倉庫需要將採購到貨的原料土豆進行打包成一個獨立的包裝，此處的原料土豆我們就將其稱之為非標品，而打包好的土豆稱之為標品。
這裏的標品非標品的定義其實就是公司內部各業務線的共識：
所以我們就有了一箇中台屬性（共識屬性）：
這裏我給大家一個我曾經搭建的中台商品服務中心中的共識屬性示例，在共識屬性上我分又細分了兩個屬性層級：
（1）交易屬性：用於支持售賣模式的屬性，eg：價格，虛擬庫存，限購；
（2）供應鏈屬性：用於作業指導，eg：生產方式，類型：原料/成品；
於是我們便得到了完整的商品屬性項分組表：
最後一步在完成了中台的主體功能建設之後，我們接下來要做的就是重新將前台應用與後台的直接關聯進行斷開，在這兩者中間插入中台，也就是讓前台應用與中台建立關係，形成這樣的一個系統體系：
到這我們中台V1.0中的商品中心就建設完畢了，當然這裏的商品中心僅是我們中台服務的第1個服務中心，除了要支撐我們現在的產品線之外，更重要的一個意義是為了跑通前台應用-中台-後台數據這種業務模式。
不過由於篇幅有限，本文中還牽扯到很多電商的內部傳統產品設計問題沒有展開來講，如果有時間我後面會專門更新幾篇完整的電商建設文章以供大家學習參考。
#相關閲讀#《中台產品經理實戰（9）：從零開始中台商品中心搭建（上）》
#專欄作家#三爺，微信公眾號：三爺茶館，人人都是產品經理專欄作家，2019年年度作者。《中台產品經理寶典》作者，原萬達高級產品、MBA特約講師、獨立創業者，現叮咚買菜B端產品線負責人，擁有多款集團項目從零到一經驗並帶領實現商業化佈局。
本文原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議。