起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識中臺產品經理實戰（9）：從零開始中臺商品中心搭建（上）
本篇我們來談談公司級中臺實戰的一個重要服務中心——商品中心搭建，該商品中心支撐全公司1萬4千多類SKU的管理。
本文為新書《中臺產品經理寶典》業務中臺建設路徑的拓展案例篇，關于案例中所涉及到的知識點可以參看下表：
PS：新書將于6月中旬上市大家敬請期待！
（后續中臺文章中用到書中知識點的部分我都會標注詳細章節，方便大家查閱書中內容）。
1. 起點：中臺體系結構
要想學習一個系統的設計與建設思路，那么我們必須要從這個項目的啟動背景來看起，這樣才能知道很多設計的原因。
這個案例當時的業務背景是這樣的，當時在公司內部共分為兩條產品線，各自獨立擁有自己的客戶端面向不同類的客戶：
- C端產品線：負責向普通消費者提供一般消費品售賣服務；
- B端產品線：負責向企業提供企業級采購服務。
由于兩個業務從商業模式上并無不同，都是通過售賣商品來賺去商品差價。
而在業務模式我們按照《中臺實戰7 繞不開的企業架構》中講述的梳理服務節點方法，得到整個商城的節點信息流模型如下圖：
（這里為了文章講解方便我將電商履約的完整后臺進行了精簡，只抽象出了最核心的幾個節點。如果對這里感興趣，我后面會寫一些專門的電商文章）
仔細來看初期B端與C端的模式上，本質就是每單的客單價不同，因此從下單與訂單拆分上沒有任何區別，而當時唯一的差距就是在下訂單之后，由于每單下單商品數量的不同，其物流配送方式上有一定的差距。
具體來說是如下幾點：
因此我們可以發現在這里的業務流程中有變化的部分，也有不變的部分，而不變的部分占整個信息流節點的絕大部分。
于是在我們拿出這樣的分析報告后，公司高層決定在公司內部來建設中臺，由中臺團隊進行兩條業務線的高重疊節點服務統一研發。
根據這個決定在開始正式建設前，當時我們的中臺架構初步準備建設這樣的三層服務體系：
- 服務組件：是中臺中的最小單元，服務組件也就是由開發編寫的微服務代碼，具體來說承載我們想要提供的復用功能，如我們上層希望支撐的商品類目管理服務，這里的微服務可能是：類目項增加，類目項刪除，類目項修改，類目項查詢，類目向兄弟系統的同步。用一句話來概括：本層定義了中臺的微服務項是哪些？
- 服務中心：這是我們從功能實現的角度去定義的，也就是我們將中臺劃分為提供不同功能的幾個模塊，這里也就是我們產品經理經常會畫的功能架構所定義的內容。而在當時我們只初步定義了商品，訂單等幾個模塊，這里后文會展開來敘述。用一句話來概括：本層定義了中臺要實現哪些功能？
- 中臺接入：再往上一層就是我們將中臺所提供的服務進行封裝，對前臺應用的部門我們給他提供簡潔的服務接口讓他們能快速的接入到中臺里。用一句話來概括：本層定義了中臺要如何接入？
當然這里我們提出的架構更多是技術層面的支撐架構，目的是為了將中臺進行一個肢解，讓我們清楚地知道中臺具體要干哪幾件事情：
中臺的微服務項是哪些->中臺要實現哪些功能->中臺要如何接入
當然雖然本篇文章名稱叫做商品中心的搭建，但是作為案例篇的文章，我還是會給大家以商品來串講一個包含完整三層體系中臺架構的建設路徑。
此處給大家個提醒，對于沒有一定技術背景的產品經理來說，我們就需要拉上自己的項目經理共同去討論并定義這樣的架構。
在探秘了當年是怎么論證啟動中臺后我們下面來看看這個中臺是想解決那些問題？
2.?分析：中臺目標
建設一個系統根本意義上就是為了達成一個目標，那么這次我們的中臺建設從抽象來說核心目標是為了解決“前臺+后臺”的齒輪速率匹配失衡的問題。
怎么理解呢？以我之前這家公司為例，在公司成立初期由于只有一個業務線，后臺幾乎對于前臺的需求都是實時響應的，如今天要新增個物流查詢功能，那么后臺就會去對接快遞公司并開發前臺轉發的接口。
而待我們又孵化出了B端項目后，我們發現當前臺B，C端業務不斷變化時，后臺的響應就不是那么及時了。
究其原因就是作為后臺每次為了支撐前臺業務，后臺都必須至少完成兩件事：
- 提供對應的接口；
- 進行數據持久化建設。
而在這個大背景下由此帶來的矛盾就是：以往為了支撐前臺越來越多的業務，后臺在建設中不斷追求服務穩定性就無法達到前臺要的響應速度，當時我們發展到極端時一個簡單的庫存作業狀態查詢接口要開發半個月。
所以我們就需要一個中臺去將一些基礎的數據匯總到中臺，由中臺進行二次加工來快速響應前臺的需要。
再說回商品中心建設案例，我們搭建中臺具體說來是想找到這幾個問題的解決方案：
問題1：
由于歷史問題之前的供應鏈系統與商城并沒有公用同一套完整的商品體系，也就是商城有自己的一套SKU體系，供應鏈中也有自己的一套SKU體系。
造成的結果是雖然大家貨物可能都是一樣的，但是在兩個系統中SKU的ID（以及部分的名稱）都是不一樣的，此時當我們從下采購單入庫后，收到的商品還不能直接成為前臺庫存，需要由倉庫人員進行庫存掛載，也就是將收到的貨倉庫由選擇是前臺的那個商品收到貨了。
如果只是庫存掛載我們還可以人工克服，但是在我們的SKU發展多了起來之后，遇到的另外一個問題就非常讓人難以處理了，這就是SKU庫存的轉換。
對于實物商品來說我們經常會出現的一個局面是雖然都是最小庫存單元的商品（也就是倉庫計算庫存的商品），但是卻有不同的包規。
舉個例子來說，作為可樂來說我們330ml的可樂它的最小庫存單元都是一瓶易拉罐，也就是無論我們平時買到的是一箱可樂還是一組可樂，對于我們倉庫來說這些SKU的庫存都是轉換為多少瓶可樂進行存儲的，只不過對于這些不同的是我們有不同的包規。
還是不太明白是吧？沒問題我給大家來看兩張圖SKU1：可樂330ml×24，SKU2：可樂330ml×6×4。
看出區別了嗎？24=4*6連裝與24=24裝是完全不同的兩個東西。但是注意這里是在實物上是兩個不同的東西，但是在倉庫庫存系統里頭這兩個又是相同的東西。
具體來說在WMS（倉儲管理系統）這兩個SKU的存儲結構是這樣的：
看出點什么了嗎？也就是說這兩個SKU除了包規與名稱外其實本質上是同一個東西：可樂330ml。
也就是這個問題導致了我們會出現一種場景，也就是當我們的商城前臺售賣的時候，我們可能會出現某種包規的可樂售賣完畢了，因此我們就需要進行拆箱的動作，這個拆箱的動作就是來自于其他SKU的借調，也就是我們通過消耗一個可樂箱裝庫存，可以為我們的可樂單瓶裝增加24個庫存。
那么當采購緯度與商城的SKUid不統一的時候，我們人工去做這個動作就非常的復雜。
我們要消耗的這一箱可樂庫存到底在原前臺掛載在哪個SKU下？轉換的目標SKU在前臺又是什么？而如果在我們轉換的時候又有了新的商品到貨又要增加庫存，這完全就讓整個作業流程變得復雜，作業任務中需要核對的信息隨著新的倉庫動作成倍增長。
問題2：
采購對同一SKU不用進行二次分離（倉管緯度，在后面講解供應鏈中臺的文章中會展開詳述）。
問題3：
SKU信息的標準化：基礎屬性+品牌+價格。
最后一個就是非常老生常談的一個需求，我們希望借助中臺將不同業務線系統里的SKU字段進行統一化管理，也就是全部交由中臺進行管理。
以此我們對于SKU的信息能實現有一個地方能去查看它全量的信息，從而當其他業務線有這樣的需求的時候無需再去修改數據庫字段，就可以直接由中臺將該字段通過接口暴露給該業務線，實現0開發使用。
故此我們就得到了中臺商品中心的V1.0功能架構：
3.?分析：建設方案
中臺本質是什么？這個問題我們從技術實現上來看其實就是數據沉淀與代碼復用。為了達到這樣的效果，我們在產品設計上必須也使用高靈活性設計方法。
那又要怎么做呢？在我的《中臺產品經理寶典》一書中我為大家總結過一個5步搞定中臺建設的MSS方法論（MSS方法論可以參看書第6章），而如果讓我用一句話來總結這里面最核心的步驟就是：Summary與Details分離化設計模式。
- Summary：信息對象摘要；
- Details：信息對象詳情。
舉例來說我們設計一個賬期功能，其包含的基礎信息有商品下單扣費，配送運費扣費，商品退款額度返還等現金流，這個時候賬期功能的信息架構設計時我們就應該分為如下兩層體系：
這樣分層的目的是為了保證我們在前臺業務展示的時候，盡量在同一個位置顯示一個層級的東西。
例如絕大多數信息架構設計好的產品在功能的首頁通常展示的都是信息的Summary，而會在詳情頁承載功能的Details。
通過這樣的信息架構劃分，我們就可以將一個功能交由中臺和前臺分離了，也就是將產品的摘要信息由中臺定義，具體的詳情信息由各業務前臺進行補充。
這就是中臺建設MSS方法論里最重要的一個建設原則，而現在市面上80%的中臺復用模式都可以依據這個建設原則進行實現。當然這樣的設計原則對我們在產品的信息架構的抽象能力是有一定的要求。
回顧一下我們現在已經完成了如下這些工作：
到這里中臺的需求分析就已經進行完畢了，我們可以看到在中臺從零到一的時候與普通功能設計最大的不同就是需要增加從全公司業務維度出發的通盤思考。
那么從下篇開始我們正式進入中臺商品中心的建設篇里。
#相關閱讀#
#專欄作家#
三爺，微信公眾號：三爺茶館，人人都是產品經理專欄作家。《中臺產品經理寶典》一書作者，曾任萬達高級產品、MBA特約講師、獨立創業者，現某支付公司產品線負責人，擁有多款集團項目從零到一經驗并帶領實現商業化布局。
本文原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
“問題1”中的不同包規的售賣商品，關聯最小單元的sku是怎么實現的？人員關聯么？還是cspu?
好文值得推薦，文章10怎么中間就斷了呢。
好文值得推薦，請問文章10是否可以更新下，期待回復
10呢，直接從9跳到11了