編輯導語：SPU和SKU是電商後台和ERP後台的重要單元。SPU即标準化産品單元，SKU即最小庫存單元。而電商後台系統設計與ERP系統設計有所不同，單純地借助電商後台管理系統設計，将導緻ERP設計上有所誤差。本文作者結合其工作經驗對ERP系統設計中的SPU和SKU設置進行闡述，一起來看一下。

一、SPU和SKU的關系

關于SPU和SKU的基礎概念的了解，建議大家還是看看一些關于電商的書籍介紹，在此我就不做過多的整理，直接從《電商産品經理兵法：基于SaaS的電商系統設計與實踐》此書中搬運一些基礎概念過來。

1. 什麼是SPU？

SPU即标準化産品單元，是一組可複用、易檢索的标準化信息的集合。該集合描述了一個“産品”的特性。

通俗來說，屬性值、特性相同的商品就可以稱為一個SPU。也可以說，SPU是一個抽象出來的模闆。

一般來說，類目系統中的關鍵屬性（品牌、貨号等）能夠确定一個SPU，例如，iPhone 6就是一個SPU，諾基亞N97也是一個SPU，這與商家無關，與顔色、款式、套餐也無關。

SPU的屬性是分類屬性的子集。隻要用戶在SPU中定義了屬性，那麼用戶在錄入商品時，就不需要再次錄入，也不可以更改。

摘自《電商産品經理兵法：基于SaaS的電商系統設計與實踐》

2. 什麼是SKU？

SKU即單品/最小庫存單元。目前，SKU在各種零售商品中應用得非常普遍。例如，某款衣服是一件商品，不同顔色、不同尺碼的該款衣服，對應不同的SKU。SKU比較簡單，就是把銷售的值組合存放，再加上庫存、價格。例如，該款衣服的黑色大号共有5件，每件20元；紅色小号共有3件，每件21元。

摘自《電商産品經理兵法：基于SaaS的電商系統設計與實踐》

3. 電商後台與ERP的商品管理差别

電商後台往往不會直接有SKU層面的管理，都是在「商品管理」中處理，也就是在SPU層面來管理。主要涉及的操作有商品發布、編輯/修改、商品上/下架、提交商品審核等。

而ERP中，往往是在SKU層面進行管理的，例如發起采購、創建訂單、查看庫存、出入庫單據等，都是關聯的SPU。

所以在設計ERP的商品管理功能的時候，如果隻是單純地參考電商後台的管理，很容易踩坑，也很不太能理解背後是怎麼運作、怎麼管理的。

前段時間我剛好在調研這一塊的業務，既調研了電商後台商品管理的一些邏輯，也上手試用了好幾款ERP的商品管理，有一些疑惑已經解開，同時也有一些踩下的坑讓我記憶猶新。

所以此文就來談談前段時間我是怎麼被SPU和SKU這兩個東西折磨的，還有踩過的坑分别有哪些。

二、SPU删除規格之後怎麼處理？

基于電商後台的規則，SKU是通過SPU的多規格來生成的，例如在創建SPU的時候，選擇不同的規格，然後不同的規格就會通過笛卡爾乘積，生成不同的SKU。

在梳理這一塊的邏輯的時候我就發現了一個問題：如果一個SPU的規格屬性有兩種「顔色」和「尺碼」，然後在「顔色」中有“紅色”、“藍色”，在「尺碼」中有“S”和“M”，則意味着一共是會生成四個SKU。

但是如果允許後期修改規格（修改規格屬性或者修改規格值）的内容的話，會重新生成SKU，同時老的SKU在這裡就無法體現了（因為規格不存在或者屬性不存在）。

例如下圖，如果将“藍色”改成“綠色”，那麼應該重新生成SKU，但是原來的“藍色”規格的SKU就“消失”了。還有如果一些創建商品的時候沒有選擇規格，然後隻是生成了一個SKU，後續如果要增加規格的時候，那麼原來的商品也不能和後續多規格衍生的SKU形成相同的結構（規格結構不一樣）。

如果SKU編碼BS和BM是在庫的、有庫存的，那麼直接删除這兩個SKU顯然是不合理的，但是由于電商的管理應該大多數是基于SPU層面，所以如果修改了規格屬性（電商也叫銷售屬性），那麼被更改了的那個應該不能再出現了，類似于此款停産或者不再售賣了。

下圖是淘寶的千牛後台，發布商品的時候先選擇對應的類目後，會給出對應的銷售屬性，而且是都必填，所以不存在中途增加和修改銷售規格的情況出現。

但是ERP系統就不會有這麼嚴謹的邏輯，而且也沒有對應的類目信息。

所以這一塊如果限制死了，不允許客戶添加規格，那麼就可能會滿足不了一些多規格的商品的信息維護；如果放開了限制，那麼用戶就可以随意調整對應的規格信息，那麼生成的SKU可能就會和原SPU斷開關聯。

千牛後台截圖

基于上述的情況，我查了很多資料，也問了一些朋友之後發現，如果是單純地參考電商平台的後台處理邏輯，那麼很難兼容各行各業的商家的産品。

于是我開始找了另一類競品：電商ERP，主要還是跨境類的，例如店小秘、馬幫、通途等。

結果發現它們的處理方式很巧妙，在創建商品的時候可以選擇類型：

• 單規格産品，也可以稱為無規格産品；
• 多規格産品，可以自由添加規格進行變換。

單規格産品不能轉為多規格，如果需要增加規格，則需要重新創建SPU再生成SKU；多規格産品也不能轉為單規格産品，多規格産品一定要選擇至少一項規格屬性。這樣一分類，就将很多複雜的場景給隔離開了，隻需要重點關注多規格産品的管理即可。

三、無規格的産品怎麼創建SKU？

在沒有仔細地調研跨境ERP的做法的時候，關于無規格的産品怎麼創建SKU的問題，我們内部讨論了兩種方案。

1. 直接創建SPU的時候，不填寫規格信息，當沒有規格信息的時候，默認SPU對應一個SKU，即一對一的關系；
2. 創建SPU的時候，填寫一個規格，例如衣服就隻有一個型号「白色的中碼」，那麼就是創建一個規格「White*M」。

後來調研了跨境ERP的做法之後，我發現這兩種做法都不好，具體的理由和上面的是一樣的。如果當前隻有一個規格，後期多了規格需要拓展的時候，在此商品SPU的基礎上拓展SKU，還是會踩坑。例如删除了“白色”這個規格，然後用了其他顔色，也删除了“M”這個尺碼，那麼之前的「White*M」就挂不在SPU之下了。

所以我決定采用跨境ERP的做法，在創建SKU的時候要先選擇類型，到底是單規格産品還是多規格産品。如果是單規格産品，那麼直接就生成SKU，不能拓展所謂的規格屬性；如果是多規格産品，則先生成父級SPU，然後再通過多規格屬性來拓展生成具體的SKU。

而且多規格的産品，不能添加&删除原來的規格屬性，隻能追加對應的屬性值。

例如一開始的規格屬性是「顔色」和「尺碼」，後續編輯的時候，隻能繼續追加「顔色」的屬性值，或者追加「尺碼」的屬性值，而不能再删除「顔色」或者添加新的其他規格屬性。同時也要限制不允許随意删除已生成的SKU（例如上面提到的BM和BS），要先判斷SKU是否已被使用。

有贊後台截圖

所以，最終我所選擇的方案是：無規格的産品直接創建一個單品SKU，不需要和SPU關聯；而有規格的産品則先創建SPU之後，再通過規格來創建SKU。

當然還有更簡單的辦法就是，ERP中不存在SPU的概念，直接全部創建的都是SKU，用映射的方式來将電商平台的SPU下的SKU映射到系統中。這種邏輯是最簡單粗暴的，利弊都很明顯，隻是我們要支持的業務場景，不允許這樣做……

四、供應商與SPU&SKU的關系

供應商是與SPU關聯還是和SKU關聯，這個也是我之前一直很糾結的一個問題。按理說，供應商提供的是具體的産品，那麼自然而然應該是跟SKU關聯。

但是有一部分的SKU是通過SPU的多規格屬性演化而來的，如果供應商直接和SKU關聯，那麼則意味着創建好了SKU之後，還需要分别對同SPU但是不同SKU的産品一一設置供應商關系、供應商報價等。

從操作層面來說，用戶要做多次重複的工作；從設計層面來說，有很多可複用的屬性沒有複用到……

創建多規格産品（SKU）的時候，将供應商信息挂在SPU維度上，然後SKU繼承這些信息，就避免了逐個SKU維護供應商的繁瑣操作。

如果是創建單規格産品（SKU）的時候，将供應商信息直接挂在SKU維度上，一個SKU就維護一次。

通途ERP截圖

通途ERP也是這樣的做法，比較清晰明了。

五、SKU如何編輯？可以編輯哪些信息？

上面提到了，我們創建了SKU的時候有兩個入口，一個是創建單規格産品，一個是創建多規格産品。所以對應的，我們編輯SKU的入口也有兩個，一個是從SPU層面進入編輯，另外一個是從SKU的層面進入編輯。

期初我一直覺得既然創建好了SKU，那麼其實在ERP中，SPU基本上就沒啥作用了，所以編輯隻需要在SKU層面即可。

但是随着對業務的分析，以及對SPU和SKU的關系的進一步熟悉，我發現如果隻是在SKU層編輯就會出現一些很奇怪的問題。

例如「iPhone 12 國行」可以算作是一個SPU，然後“iPhone 12 國行 紅色 64G”（簡稱為：紅色64G）和“iPhone 12 國行 白色 128G”（簡稱為：白色128G）則是其所對應的SKU。

如果我将所有的編輯都放在SKU層面，那麼我自然而然可以編輯一些“基礎信息”、“非關鍵屬性”、“銷售信息”等。

如果隻是編輯“銷售信息”那麼還沒什麼問題，因為不同的SKU就是因為銷售屬性不一樣而做的區分。但是如果允許編輯一些“基礎信息”，例如說“名稱”、“描述”、“類目”等，那麼可以将“iPhone 12 國行 紅色 64G”改成“蘋果12 中國紅 64G”，也可以改成“蘋果11 白色 64G”等等，這樣就會亂套了。

所以，SKU的編輯應該遵循和創建的邏輯相同，也要符合SPU和SKU的關系的定義。有兩個入口創建，也就有兩個入口編輯。同時，不同的入口可以編輯的信息是不一樣的。

SPU維度編輯的“基礎信息”等應該是複用在所有的SKU層面的，即改了SPU的信息則SKU的信息也要改；SKU維度的編輯，隻能是一些自己獨立的屬性，例如“售價”、“庫存信息”、“采購價格”等。

千牛後台截圖

六、一些參考資料

最後分享一些相關參考資料給大家，如果大家對電商後台或者ERP後台感興趣的，可以根據下面的關鍵詞進行搜索。有一些後台賬号是需要申請試用的，找個小号去申請比較好，能避免後續很多的騷擾。

• 電商後台的競品：千牛（淘寶商家後台）、劉志遠——電商後台産品設計課程、相關圖書（京東）、有贊。
• ERP的競品：店小秘、馬幫、金蝶星辰、聚水潭。

#專欄作家#

vitamin，皮醬叨逼叨。人人都是産品經理專欄作家，公衆号運營小白，初中級B端産品一枚（一年開發經驗 三年産品經驗）。主導過在線教育類産品，目前是跨境電商供應鍊倉儲物流産品一枚，歡迎勾搭，一同學習。

本文原創發布于人人都是産品經理，未經作者許可，禁止轉載

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

,

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

查看全部