零售系統架構設計?編輯導語：B端商品系統用于滿足B端平台需求，本文作者分享了B端商品系統的設計思路，介紹了電商平台、商品簡介、一般平台型商品中心分析以及B端電商平台商品中心設計思路的相關内容，一起來學習一下吧，希望對你有幫助，今天小編就來聊一聊關于零售系統架構設計?接下來我們就一起去研究一下吧!

零售系統架構設計

編輯導語：B端商品系統用于滿足B端平台需求，本文作者分享了B端商品系統的設計思路，介紹了電商平台、商品簡介、一般平台型商品中心分析以及B端電商平台商品中心設計思路的相關内容，一起來學習一下吧，希望對你有幫助。

本文主要從電商平台商品介紹，再到詳細的設計思路，講述了我自己設計滿足B端平台需求的商品中心過程。

Platform在英文中的意思是平台（主體——主體）。

用科技鍊接不同的人、鍊接不同的組織、資源來完成交換，如微信平台。

重新分配，有了新型的中間人。例如，音樂行業的高管們過去主要依靠經紀人來尋找新的人才。現在，他們一樣會在YouTube上尋找好的歌手，開發同學去Github尋找開發，去抖音上尋找視頻博主一樣。

市場聚合，将分散的市場聚合成為集中化的市場。例如，阿裡巴巴為全世界的批發商打造了一個單一的平台。

将資産與價值分離。你不必購買一輛汽車來作為每天代步的工具，而可以随時叫一輛滴滴專車來送你上班。

平台天然能提供壟斷與稅收，也就是平台的各種服務費，不直接産生産品，但能獲取最多的利潤。

為了能夠提高利潤，降低成本，我們需要增加售賣渠道和産品種類，同時增加供應鍊的複用率，降低供應鍊成本，如果能夠将産品和供應鍊的成本轉嫁到其他人身上那就更好了。

這就解釋了為什麼電商公司都逐漸發展成了平台（發展得好的話），而當前，我們公司也發展到了這一步，所以需要新的商品管理方式。

在超市，他是有價格和表面有一系列說明的可購買的最小單位在電商平台，他是有價格有庫存有規格參數及一系列說明的最小單位。

從商品的信息來推敲後台該如何設計，才能讓後台設計更好地滿足用戶需求。大緻來說有以下商品信息有以下幾部分：

商品的基本信息：包括标題，型号，說明與相關參數等；

商品的規格參數的信息；

商品價格，從哪發貨，還剩多少的信息；

商品标簽等運營信息。

我們設計商品中台，就是為了去更好地管理好這些商品信息。

一般來說，平台電商商品中心包括了以下幾個子模塊：

例如下方的商品後台示例：

上述的電商平台商品中心的路徑大同小異，存在的交互路徑可能有所不同，但底層的E-R結構和産品架構是比較類型的，都可以大緻看做是以下結構。

發布商品大緻的流程是：

這是一些電商平台商品中心的設計思路，這種設計有以下的一些特點：

同一商品可能有多種參數信息與補充信息；

商品需要維護信息較多，需要商戶投入精力較多；

商品信息的自定義程度高、商品的信息需要平台進行審核；

能夠自定義商品各種信息，以保證自身商品的競争力，适合一個商品很多賣家競争的場景；

店鋪類型決定了能夠售賣的商品品類等，管理較為細緻；

系統設計相對複雜，牽扯到例如删除了規格參數相關已存在SKU如何處理，删除了SPU類目如何處理SKU，修改了又如何處理等系統行為。

1. 業務模式分析

首先分析一下B端産品交易平台的需求特點：

B2B交易，交易相對平常購物的網站頻次更低；B端客戶更為理性，對營銷信息更慎重；

用戶需要的元器件商品的參數信息需要嚴格且準确，不能提供錯誤的參數信息；

商品是高度标準化的，并且商品一般隻有一個供應商生産此商品；

一個品牌的商品進行售賣的商家不會很多，不是淘寶/天貓那樣的大市集；

一個商品可能在一段時間進行持續供貨（一段時間生産周期内），商品信息的穩定性較高；

平台商家普遍不止一個渠道進行管理與銷售;

對于自營店，商品量大，種類衆多，管理難度相對較大。

所以有以下的幾點簡單推論可以得到：

對平台：核心需求是通過多店鋪的商品管理，加強平台的供應鍊能力，并在此基礎上仍能保障商品的參數正确性，并不是一個商品幾百家商家；

對用戶：商品信息嚴格準确，并盡量使商品有貨可售-前台呈現模塊；

對商家：維護商品的難度很低，不需要耗費很多時間，核心是把貨放在平台上賣，而不是考慮貨長什麼樣，怎麼更能吸引消費者（這是原廠産品性能考慮的東西）。

2. 商品術語定義

ON：商品的完整參數信息，除商品的價格和庫存等銷售信息外的所有信息；

商品：最小的可售單元；

商家：平台上的服務商；

店鋪：商家在平台上開的店鋪，平台進行服務費管理、店鋪管理的最小單位；

商品屬性：商品的基礎屬性，表達商品信息的内容，主要用于展示；

售賣屬性：用于售賣時計算使用，主要用于與訂單相關的内容。

3. 商品中心模型

平台化場景：即多個商家銷售多個商品時；自營店或其他店鋪都可以新建商品，但新建的商品都公用一套平台審核通過後的商品的信息内容（但框架上保留自定義内容空間）；保證平台商品參數的正确性，若商家認為商品參數有誤，可以進行編輯并提交商品參數的審核，商家直接引用平台通過審核後的商品參數則不再需要審核了。

這時候就能看到我們和某淘/某東的商品管理基本結構上的相似點。

同一個SPU：該規格下的所有SKU都分享同一份商品圖片和商品描述等信息

同一個ON：該ON下所有商品都分享同一份ON的信息内容

思想其實是類似的先聚合，再細分，最後把價格和庫存管理在最小的可售賣單元上。

聚合的是什麼，是SPU、類目、規格等可以複用的信息

細分的是什麼，每個商品都有細分的不同的商品參數、價格與庫存

4. 商品中心特點

商家引用平台審核通過商品參數再形成商品的策略，就顯得十分均衡；

元器件電商的規格參數需要很強的嚴謹度，保證了規格參數的嚴謹程度；

對于平台的商家，自行維護這一部分參數信息門檻很高，并很難做到準确；

平台非一個商品幾百個商家售賣的“大賣場”，不一定需要同樣商品（對用戶）建立多樣化的商品信息；

降低了維護難度，也滿足了敏捷開發的目标，沒有那麼複雜的規格、品類之間互相關聯的關系；

多店鋪多平台的結構，商品中心的業務中台能夠同時支撐英文獨立站和中文站的商品體系；

基于商品機構，可以直接再叠代多語言化的商品信息場景，來滿足多語言平台站點的不同需求，通過店鋪所屬站點，發布地址來判斷，直接将商品的多語言版本上架前台；

即：商家将平台提供的商品參數提供進行引用，商家自行管理商品的上下架、價格、庫存等信息，同時平台能夠有對商品總體的控制，避免風險。

本文主要介紹商品管理的設計思路而非具體設計方案，在B端設計中，先搭建好設計的框架才能進行具體的功能設計，商品管理系統在電商系統中是常見的核心系統，有非常多的設計案例和思路（電商類、ERP類），根據商業模式。

業務類型來建立真正适合自己的商品系統才能提供産品價值。很多設計是大同小異的。

本文由 @浮雲志 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!