ERP系統:SPU和SKU的踩坑總結

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

一、SPU和SKU的關系

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

ERP系統:SPU和SKU的踩坑總結

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形成相同的結構(規格結構不一樣)。

ERP系統:SPU和SKU的踩坑總結

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

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

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

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

ERP系統:SPU和SKU的踩坑總結

千牛后臺截圖

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

于是我開始找了另一類競品:電商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是否已被使用。

ERP系統:SPU和SKU的踩坑總結

有贊后臺截圖

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

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

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

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

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

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

ERP系統:SPU和SKU的踩坑總結

創建多規格產品(SKU)的時候,將供應商信息掛在SPU維度上,然后SKU繼承這些信息,就避免了逐個SKU維護供應商的繁瑣操作。

如果是創建單規格產品(SKU)的時候,將供應商信息直接掛在SKU維度上,一個SKU就維護一次。

ERP系統:SPU和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系統:SPU和SKU的踩坑總結

千牛后臺截圖

六、一些參考資料

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

  • 電商后臺的競品:千牛(淘寶商家后臺)、劉志遠——電商后臺產品設計課程、相關圖書(京東)、有贊。
  • ERP的競品:店小秘、馬幫、金蝶星辰、聚水潭。

#專欄作家#

vitamin,微信公眾號:皮醬叨逼叨。人人都是產品經理專欄作家,公眾號運營小白,初中級B端產品一枚(一年開發經驗+三年產品經驗)。主導過在線教育類產品,目前是跨境電商供應鏈倉儲物流產品一枚,歡迎勾搭,一同學習。

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

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

給作者打賞,鼓勵TA抓緊創作!

文章若有侵權請來信告知:品牌行銷策略,產品行銷與設計,各類型行銷推廣案例分享-品牌行銷點點讚 » ERP系統:SPU和SKU的踩坑總結