起點(diǎn)課堂會員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會特權(quán)
個人IP打造特權(quán)
30+門專項(xiàng)技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導(dǎo)直播
12場專業(yè)技能直播
會員專屬社群
榮耀標(biāo)識
ERP系統(tǒng)：SPU和SKU的踩坑總結(jié)
編輯導(dǎo)語：SPU和SKU是電商后臺和ERP后臺的重要單元。SPU即標(biāo)準(zhǔn)化產(chǎn)品單元，SKU即最小庫存單元。而電商后臺系統(tǒng)設(shè)計(jì)與ERP系統(tǒng)設(shè)計(jì)有所不同，單純地借助電商后臺管理系統(tǒng)設(shè)計(jì)，將導(dǎo)致ERP設(shè)計(jì)上有所誤差。本文作者結(jié)合其工作經(jīng)驗(yàn)對ERP系統(tǒng)設(shè)計(jì)中的SPU和SKU設(shè)置進(jìn)行闡述，一起來看一下。
一、SPU和SKU的關(guān)系
關(guān)于SPU和SKU的基礎(chǔ)概念的了解，建議大家還是看看一些關(guān)于電商的書籍介紹，在此我就不做過多的整理，直接從《電商產(chǎn)品經(jīng)理兵法：基于SaaS的電商系統(tǒng)設(shè)計(jì)與實(shí)踐》此書中搬運(yùn)一些基礎(chǔ)概念過來。
1. 什么是SPU？
SPU即標(biāo)準(zhǔn)化產(chǎn)品單元，是一組可復(fù)用、易檢索的標(biāo)準(zhǔn)化信息的集合。該集合描述了一個“產(chǎn)品”的特性。
通俗來說，屬性值、特性相同的商品就可以稱為一個SPU。也可以說，SPU是一個抽象出來的模板。
一般來說，類目系統(tǒng)中的關(guān)鍵屬性（品牌、貨號等）能夠確定一個SPU，例如，iPhone 6就是一個SPU，諾基亞N97也是一個SPU，這與商家無關(guān)，與顏色、款式、套餐也無關(guān)。
SPU的屬性是分類屬性的子集。只要用戶在SPU中定義了屬性，那么用戶在錄入商品時(shí)，就不需要再次錄入，也不可以更改。
摘自《電商產(chǎn)品經(jīng)理兵法：基于SaaS的電商系統(tǒng)設(shè)計(jì)與實(shí)踐》
2. 什么是SKU？
SKU即單品/最小庫存單元。目前，SKU在各種零售商品中應(yīng)用得非常普遍。例如，某款衣服是一件商品，不同顏色、不同尺碼的該款衣服，對應(yīng)不同的SKU。SKU比較簡單，就是把銷售的值組合存放，再加上庫存、價(jià)格。例如，該款衣服的黑色大號共有5件，每件20元；紅色小號共有3件，每件21元。
摘自《電商產(chǎn)品經(jīng)理兵法：基于SaaS的電商系統(tǒng)設(shè)計(jì)與實(shí)踐》
3. 電商后臺與ERP的商品管理差別
電商后臺往往不會直接有SKU層面的管理，都是在「商品管理」中處理，也就是在SPU層面來管理。主要涉及的操作有商品發(fā)布、編輯/修改、商品上/下架、提交商品審核等。
而ERP中，往往是在SKU層面進(jìn)行管理的，例如發(fā)起采購、創(chuàng)建訂單、查看庫存、出入庫單據(jù)等，都是關(guān)聯(lián)的SPU。
所以在設(shè)計(jì)ERP的商品管理功能的時(shí)候，如果只是單純地參考電商后臺的管理，很容易踩坑，也很不太能理解背后是怎么運(yùn)作、怎么管理的。
前段時(shí)間我剛好在調(diào)研這一塊的業(yè)務(wù)，既調(diào)研了電商后臺商品管理的一些邏輯，也上手試用了好幾款ERP的商品管理，有一些疑惑已經(jīng)解開，同時(shí)也有一些踩下的坑讓我記憶猶新。
所以此文就來談?wù)勄岸螘r(shí)間我是怎么被SPU和SKU這兩個東西折磨的，還有踩過的坑分別有哪些。
二、SPU刪除規(guī)格之后怎么處理？
基于電商后臺的規(guī)則，SKU是通過SPU的多規(guī)格來生成的，例如在創(chuàng)建SPU的時(shí)候，選擇不同的規(guī)格，然后不同的規(guī)格就會通過笛卡爾乘積，生成不同的SKU。
在梳理這一塊的邏輯的時(shí)候我就發(fā)現(xiàn)了一個問題：如果一個SPU的規(guī)格屬性有兩種「顏色」和「尺碼」，然后在「顏色」中有“紅色”、“藍(lán)色”，在「尺碼」中有“S”和“M”，則意味著一共是會生成四個SKU。
但是如果允許后期修改規(guī)格（修改規(guī)格屬性或者修改規(guī)格值）的內(nèi)容的話，會重新生成SKU，同時(shí)老的SKU在這里就無法體現(xiàn)了（因?yàn)橐?guī)格不存在或者屬性不存在）。
例如下圖，如果將“藍(lán)色”改成“綠色”，那么應(yīng)該重新生成SKU，但是原來的“藍(lán)色”規(guī)格的SKU就“消失”了。還有如果一些創(chuàng)建商品的時(shí)候沒有選擇規(guī)格，然后只是生成了一個SKU，后續(xù)如果要增加規(guī)格的時(shí)候，那么原來的商品也不能和后續(xù)多規(guī)格衍生的SKU形成相同的結(jié)構(gòu)（規(guī)格結(jié)構(gòu)不一樣）。
如果SKU編碼BS和BM是在庫的、有庫存的，那么直接刪除這兩個SKU顯然是不合理的，但是由于電商的管理應(yīng)該大多數(shù)是基于SPU層面，所以如果修改了規(guī)格屬性（電商也叫銷售屬性），那么被更改了的那個應(yīng)該不能再出現(xiàn)了，類似于此款停產(chǎn)或者不再售賣了。
下圖是淘寶的千牛后臺，發(fā)布商品的時(shí)候先選擇對應(yīng)的類目后，會給出對應(yīng)的銷售屬性，而且是都必填，所以不存在中途增加和修改銷售規(guī)格的情況出現(xiàn)。
但是ERP系統(tǒng)就不會有這么嚴(yán)謹(jǐn)?shù)倪壿?，而且也沒有對應(yīng)的類目信息。
所以這一塊如果限制死了，不允許客戶添加規(guī)格，那么就可能會滿足不了一些多規(guī)格的商品的信息維護(hù)；如果放開了限制，那么用戶就可以隨意調(diào)整對應(yīng)的規(guī)格信息，那么生成的SKU可能就會和原SPU斷開關(guān)聯(lián)。
千牛后臺截圖
基于上述的情況，我查了很多資料，也問了一些朋友之后發(fā)現(xiàn)，如果是單純地參考電商平臺的后臺處理邏輯，那么很難兼容各行各業(yè)的商家的產(chǎn)品。
于是我開始找了另一類競品：電商ERP，主要還是跨境類的，例如店小秘、馬幫、通途等。
結(jié)果發(fā)現(xiàn)它們的處理方式很巧妙，在創(chuàng)建商品的時(shí)候可以選擇類型：
- 單規(guī)格產(chǎn)品，也可以稱為無規(guī)格產(chǎn)品；
- 多規(guī)格產(chǎn)品，可以自由添加規(guī)格進(jìn)行變換。
單規(guī)格產(chǎn)品不能轉(zhuǎn)為多規(guī)格，如果需要增加規(guī)格，則需要重新創(chuàng)建SPU再生成SKU；多規(guī)格產(chǎn)品也不能轉(zhuǎn)為單規(guī)格產(chǎn)品，多規(guī)格產(chǎn)品一定要選擇至少一項(xiàng)規(guī)格屬性。這樣一分類，就將很多復(fù)雜的場景給隔離開了，只需要重點(diǎn)關(guān)注多規(guī)格產(chǎn)品的管理即可。
三、無規(guī)格的產(chǎn)品怎么創(chuàng)建SKU？
在沒有仔細(xì)地調(diào)研跨境ERP的做法的時(shí)候，關(guān)于無規(guī)格的產(chǎn)品怎么創(chuàng)建SKU的問題，我們內(nèi)部討論了兩種方案。
- 直接創(chuàng)建SPU的時(shí)候，不填寫規(guī)格信息，當(dāng)沒有規(guī)格信息的時(shí)候，默認(rèn)SPU對應(yīng)一個SKU，即一對一的關(guān)系；
- 創(chuàng)建SPU的時(shí)候，填寫一個規(guī)格，例如衣服就只有一個型號「白色的中碼」，那么就是創(chuàng)建一個規(guī)格「White*M」。
后來調(diào)研了跨境ERP的做法之后，我發(fā)現(xiàn)這兩種做法都不好，具體的理由和上面的是一樣的。如果當(dāng)前只有一個規(guī)格，后期多了規(guī)格需要拓展的時(shí)候，在此商品SPU的基礎(chǔ)上拓展SKU，還是會踩坑。例如刪除了“白色”這個規(guī)格，然后用了其他顏色，也刪除了“M”這個尺碼，那么之前的「White*M」就掛不在SPU之下了。
所以我決定采用跨境ERP的做法，在創(chuàng)建SKU的時(shí)候要先選擇類型，到底是單規(guī)格產(chǎn)品還是多規(guī)格產(chǎn)品。如果是單規(guī)格產(chǎn)品，那么直接就生成SKU，不能拓展所謂的規(guī)格屬性；如果是多規(guī)格產(chǎn)品，則先生成父級SPU，然后再通過多規(guī)格屬性來拓展生成具體的SKU。
而且多規(guī)格的產(chǎn)品，不能添加&刪除原來的規(guī)格屬性，只能追加對應(yīng)的屬性值。
例如一開始的規(guī)格屬性是「顏色」和「尺碼」，后續(xù)編輯的時(shí)候，只能繼續(xù)追加「顏色」的屬性值，或者追加「尺碼」的屬性值，而不能再刪除「顏色」或者添加新的其他規(guī)格屬性。同時(shí)也要限制不允許隨意刪除已生成的SKU（例如上面提到的BM和BS），要先判斷SKU是否已被使用。
有贊后臺截圖
所以，最終我所選擇的方案是：無規(guī)格的產(chǎn)品直接創(chuàng)建一個單品SKU，不需要和SPU關(guān)聯(lián)；而有規(guī)格的產(chǎn)品則先創(chuàng)建SPU之后，再通過規(guī)格來創(chuàng)建SKU。
當(dāng)然還有更簡單的辦法就是，ERP中不存在SPU的概念，直接全部創(chuàng)建的都是SKU，用映射的方式來將電商平臺的SPU下的SKU映射到系統(tǒng)中。這種邏輯是最簡單粗暴的，利弊都很明顯，只是我們要支持的業(yè)務(wù)場景，不允許這樣做……
四、供應(yīng)商與SPU&SKU的關(guān)系
供應(yīng)商是與SPU關(guān)聯(lián)還是和SKU關(guān)聯(lián)，這個也是我之前一直很糾結(jié)的一個問題。按理說，供應(yīng)商提供的是具體的產(chǎn)品，那么自然而然應(yīng)該是跟SKU關(guān)聯(lián)。
但是有一部分的SKU是通過SPU的多規(guī)格屬性演化而來的，如果供應(yīng)商直接和SKU關(guān)聯(lián)，那么則意味著創(chuàng)建好了SKU之后，還需要分別對同SPU但是不同SKU的產(chǎn)品一一設(shè)置供應(yīng)商關(guān)系、供應(yīng)商報(bào)價(jià)等。
從操作層面來說，用戶要做多次重復(fù)的工作；從設(shè)計(jì)層面來說，有很多可復(fù)用的屬性沒有復(fù)用到……
創(chuàng)建多規(guī)格產(chǎn)品（SKU）的時(shí)候，將供應(yīng)商信息掛在SPU維度上，然后SKU繼承這些信息，就避免了逐個SKU維護(hù)供應(yīng)商的繁瑣操作。
如果是創(chuàng)建單規(guī)格產(chǎn)品（SKU）的時(shí)候，將供應(yīng)商信息直接掛在SKU維度上，一個SKU就維護(hù)一次。
通途ERP截圖
通途ERP也是這樣的做法，比較清晰明了。
五、SKU如何編輯？可以編輯哪些信息？
上面提到了，我們創(chuàng)建了SKU的時(shí)候有兩個入口，一個是創(chuàng)建單規(guī)格產(chǎn)品，一個是創(chuàng)建多規(guī)格產(chǎn)品。所以對應(yīng)的，我們編輯SKU的入口也有兩個，一個是從SPU層面進(jìn)入編輯，另外一個是從SKU的層面進(jìn)入編輯。
期初我一直覺得既然創(chuàng)建好了SKU，那么其實(shí)在ERP中，SPU基本上就沒啥作用了，所以編輯只需要在SKU層面即可。
但是隨著對業(yè)務(wù)的分析，以及對SPU和SKU的關(guān)系的進(jìn)一步熟悉，我發(fā)現(xiàn)如果只是在SKU層編輯就會出現(xiàn)一些很奇怪的問題。
例如「iPhone 12 國行」可以算作是一個SPU，然后“iPhone 12 國行 紅色 64G”（簡稱為：紅色64G）和“iPhone 12 國行 白色 128G”（簡稱為：白色128G）則是其所對應(yīng)的SKU。
如果我將所有的編輯都放在SKU層面，那么我自然而然可以編輯一些“基礎(chǔ)信息”、“非關(guān)鍵屬性”、“銷售信息”等。
如果只是編輯“銷售信息”那么還沒什么問題，因?yàn)椴煌腟KU就是因?yàn)殇N售屬性不一樣而做的區(qū)分。但是如果允許編輯一些“基礎(chǔ)信息”，例如說“名稱”、“描述”、“類目”等，那么可以將“iPhone 12 國行 紅色 64G”改成“蘋果12 中國紅 64G”，也可以改成“蘋果11 白色 64G”等等，這樣就會亂套了。
所以，SKU的編輯應(yīng)該遵循和創(chuàng)建的邏輯相同，也要符合SPU和SKU的關(guān)系的定義。有兩個入口創(chuàng)建，也就有兩個入口編輯。同時(shí)，不同的入口可以編輯的信息是不一樣的。
SPU維度編輯的“基礎(chǔ)信息”等應(yīng)該是復(fù)用在所有的SKU層面的，即改了SPU的信息則SKU的信息也要改；SKU維度的編輯，只能是一些自己獨(dú)立的屬性，例如“售價(jià)”、“庫存信息”、“采購價(jià)格”等。
千牛后臺截圖
六、一些參考資料
最后分享一些相關(guān)參考資料給大家，如果大家對電商后臺或者ERP后臺感興趣的，可以根據(jù)下面的關(guān)鍵詞進(jìn)行搜索。有一些后臺賬號是需要申請?jiān)囉玫模覀€小號去申請比較好，能避免后續(xù)很多的騷擾。
- 電商后臺的競品：千牛（淘寶商家后臺）、劉志遠(yuǎn)——電商后臺產(chǎn)品設(shè)計(jì)課程、相關(guān)圖書（京東）、有贊。
- ERP的競品：店小秘、馬幫、金蝶星辰、聚水潭。
#專欄作家#
vitamin，微信公眾號：皮醬叨逼叨。人人都是產(chǎn)品經(jīng)理專欄作家，公眾號運(yùn)營小白，初中級B端產(chǎn)品一枚（一年開發(fā)經(jīng)驗(yàn)+三年產(chǎn)品經(jīng)驗(yàn)）。主導(dǎo)過在線教育類產(chǎn)品，目前是跨境電商供應(yīng)鏈倉儲物流產(chǎn)品一枚，歡迎勾搭，一同學(xué)習(xí)。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載
題圖來自 Unsplash，基于CC0協(xié)議。
作者您好，請教一下，您說的
“而且多規(guī)格的產(chǎn)品，不能添加&刪除原來的規(guī)格屬性，只能追加對應(yīng)的屬性值。
例如一開始的規(guī)格屬性是「顏色」和「尺碼」，后續(xù)編輯的時(shí)候，只能繼續(xù)追加「顏色」的屬性值，或者追加「尺碼」的屬性值，而不能再刪除「顏色」或者添加新的其他規(guī)格屬性。同時(shí)也要限制不允許隨意刪除已生成的SKU（例如上面提到的BM和BS），要先判斷SKU是否已被使用?！?br /> 這個是您后來采用的方案嗎？即“有規(guī)格的產(chǎn)品則先創(chuàng)建SPU之后，再通過規(guī)格來創(chuàng)建SKU?！?/p>
前前后后一共看了5遍，收獲很大，謝謝作者分享
你好，請教個問題。我們的商品模型設(shè)計(jì)比較靈活，把SPU的基礎(chǔ)屬性和sku的銷售屬性都設(shè)計(jì)成可配置。這樣就造成一個問題，比如類目下設(shè)置的基礎(chǔ)屬性改成銷售屬性，那么這個類目下已有spu就有可能重復(fù)，需要合并SPU，遷移sku 和spu 的關(guān)系。這樣做會有什么問題？或者有沒有更好的解決方案？還是確定了類目下的基礎(chǔ)屬性就不能再修改？
估值核算
SPU就是商品基本數(shù)據(jù)，SKU應(yīng)該是銷售層的產(chǎn)品分類，比如毛衣+顏色+尺寸是SPU，毛衣、紅色、小號，價(jià)格+銷售策略（如返利、買贈）這屬于一種SKU。SPU就是元數(shù)據(jù)，SKU是銷售數(shù)據(jù)，前者來自供貨商，后者來自平臺二次編輯，因?yàn)楹芏嚯娚特浽词遣捎昧说谌焦?yīng)鏈API接口選品供貨，不是自己尋找廠家或者實(shí)體供貨商模式，供應(yīng)鏈合作的對象可能就是京東、蘇寧、國美這些，自己只是三道販子
在建spu時(shí)，默認(rèn)選一個版本規(guī)格呢？但是版本規(guī)則及其屬性在前臺不展示，這樣關(guān)聯(lián)sku是否合理
通過簡單粗暴的 sku映射到spu里面不同規(guī)格這種方式有什么弊端嗎？我倒覺得挺靈活的，在為spu新增多個規(guī)格的時(shí)候，只要有sku關(guān)聯(lián)，就顯示可以售賣，沒有關(guān)聯(lián)的，置灰不可買；然后對于供應(yīng)鏈端來說，以sku為維度感覺更合適，就以手機(jī)來舉例，不同內(nèi)存的價(jià)格不一樣，關(guān)聯(lián)的采購訂單可能也是多行，如果以spu為維度的話，可能沒有這么細(xì)致
用SKU是很靈活，但是要考慮平臺設(shè)計(jì)的問題，平臺需要SPU，供應(yīng)鏈可以用SKU
討教一下，不同的規(guī)格通過笛卡爾乘積，生成SKU列表；那這種方式，我怎么給商品添加新的SKU？選擇新的屬性，通過笛卡爾積會生成重復(fù)的SKU，怎么辦？
對的，這個就是很尷尬的問題，如果你增加了屬性，那么之前的歷史SKU也會增加屬性，如果你不想改動原來的SKU，那么就只能讓新增加的屬性無效。
例如之前只有 尺碼+顏色，現(xiàn)在增加了要一個產(chǎn)地，那么必然之前的組合都要加上產(chǎn)地這個屬性，如果是一些空的或者沒用的SKU則設(shè)置 不使用或者庫存變成0
不贊同這種觀點(diǎn)。通過合理的界面交互設(shè)計(jì) 完全不存在你說的這種情況。我們可以把商品設(shè)計(jì)成多屬性規(guī)格的SPU，在創(chuàng)建sku時(shí)對于規(guī)格屬性的選擇設(shè)計(jì)成可配置的即可，
你好，不太理解你的意思，可以再解釋下嗎，想學(xué)習(xí)下
一般競品都是用的笛卡爾積的方式，在spu下建立sku，當(dāng)規(guī)格下的規(guī)格值有修改時(shí)，會導(dǎo)致原來的sku消失，但是我們把刪除和增加進(jìn)行了拆分，后續(xù)的修改規(guī)格時(shí)笛卡爾積結(jié)果中用戶選的新規(guī)格只做增加，不影響已經(jīng)生成的sku，已生成的sku需要手動去停用（刪除），但像您說的增加新的屬性（規(guī)格），確實(shí)原有的sku沒法同步上
你好，可以推薦本erp的書籍嗎
如果是產(chǎn)品的話，好像沒什么ERP相關(guān)的書籍很吻合；如果是想要看供應(yīng)鏈相關(guān)的知識，可以看看劉寶紅的一些書籍。
好的，謝謝
也可以看我的公眾號，里面我有推薦過一些書單。
你好，我現(xiàn)在也在設(shè)計(jì)一個ERP系統(tǒng)，看到你的文章，解決了我的一些疑惑，但是有一點(diǎn)疑問 。
“直接創(chuàng)建SPU的時(shí)候，不填寫規(guī)格信息，當(dāng)沒有規(guī)格信息的時(shí)候，默認(rèn)SPU對應(yīng)一個SKU，即一對一的關(guān)系”這是你們否定得一個方案，但是我目前是按這種方式去設(shè)計(jì)的，即創(chuàng)建無規(guī)格商品，同時(shí)生產(chǎn)一個SPU和SKU信息，創(chuàng)建之后（或有訂單記錄后）就不能再添加規(guī)格項(xiàng)。
我認(rèn)為這種方式和文章里說的創(chuàng)建無規(guī)格商品，是一樣的效果。麻煩您解答一下。
嗯，你的方案是對的。當(dāng)時(shí)我在寫這篇文章的時(shí)候，我一直認(rèn)為SPU沒有規(guī)格，不創(chuàng)建SKU，那么單獨(dú)存在一個SPU是很奇怪的，不合理的。
但是最近我在研究電商平臺的商品同步接口的時(shí)候發(fā)現(xiàn)，其實(shí)沒有規(guī)格的產(chǎn)品還是會有SPU但是沒有SKU的情況，所以ERP為了兼容這種場景，其實(shí)應(yīng)該做到：沒有規(guī)格的SPU也可以創(chuàng)建SKU，SKU編碼和SPU編碼一致。
然后你說的那種方式，其實(shí)和創(chuàng)建普通產(chǎn)品和多規(guī)格產(chǎn)品是一樣的，不過我感覺分成兩個入口可以讓用戶感知更加清晰一點(diǎn)，避免出現(xiàn)創(chuàng)建了SPU無規(guī)格又想要改成又規(guī)格的情況。
如果還有疑問的話可以加WX聯(lián)系一下：vitamin_mpp
販賣虛擬物品的時(shí)候，這種情況確實(shí)很多。包括現(xiàn)在像千牛的后臺，當(dāng)你的商品只有spu的時(shí)候，也是可以上架的。比如我們自己的，全面家庭套餐999，它直接在描述上體現(xiàn)了，不需要任何sku。千牛它后臺的存儲應(yīng)該就是spu。包括有贊的后臺，甚至sku的創(chuàng)建直接開放給了商家。
嗨，勤勞的皮醬~
建議：供應(yīng)商和商品的關(guān)聯(lián)在實(shí)際應(yīng)用中還是挺高頻的，可以單獨(dú)拎出來做一個管理界面的哈，方便維護(hù)采購量、價(jià)、生產(chǎn)周期等信息。
嗯 是會拎出來單獨(dú)管理。我想表達(dá)的意思是就是供應(yīng)商和商品的關(guān)聯(lián)，到底是供應(yīng)商直接和SKU還是和SPU。然后通過我的體驗(yàn)或者競品試用，我建議是單規(guī)格產(chǎn)品直接和供應(yīng)商關(guān)聯(lián)；而多規(guī)格產(chǎn)品，則是用SPU的維度去和供應(yīng)商關(guān)聯(lián)，然后SPU下的SKU直接繼承這個SPU的供應(yīng)商即可。