編輯導(dǎo)語：商品在整個電商系統(tǒng)中處于核心位置，因此商品維護(hù)對于電商后臺設(shè)計的重要性不言而喻，本文作者以此為出發(fā)點，和我們聊一聊在電商后臺設(shè)計中關(guān)于商品維護(hù)的那些事。

對于電商系統(tǒng)來說，商品模塊的維護(hù)可以說是核心功能了，整個系統(tǒng)都是圍繞商品來進(jìn)行運營的。所以能否設(shè)計一個靈活便捷的商品模塊，對于整個系統(tǒng)的操作都非常重要。

今天我們就來聊聊商品管理那點事，對于商品信息的維護(hù)，它的本質(zhì)是對一堆屬性和屬性值的管理，理清其中的關(guān)聯(lián)關(guān)系，就能將其玩轉(zhuǎn)的游刃有余。

首先我們先來看看一個商品都有哪些屬性，下圖是某電商平臺的商品圖：

整理一下可以得到其中的屬性：商品名稱、品牌、品類、顏色、內(nèi)存、價格、圖片、商品編碼、CPU型號、機身存儲、商品毛重、操作系統(tǒng)等等。

在上一篇《電商后臺設(shè)計：屬性管理》中，我們將這些屬性分了四類：基礎(chǔ)屬性、銷售屬性、搜索屬性、特有屬性。除了其中的搜索屬性被融合在特有屬性中，其它的功能在商品信息維護(hù)中都有所涉及，接下來我們一一進(jìn)行討論。

一、基礎(chǔ)屬性

對于所有商品包含的屬性，都可以歸類到基礎(chǔ)屬性中，如商品名稱、品牌、品類、狀態(tài)等。對于基礎(chǔ)屬性的維護(hù)比較簡單，由于都是單一可以確定類型，通常根據(jù)數(shù)據(jù)展示形式一一維護(hù)即可。

其中有幾個屬性需要說明一下：

品類：由于商品的特有屬性和搜索屬性都關(guān)聯(lián)在品類上，所以商品品類是必須選擇的。狀態(tài): 上架/下架，確定是否在前臺展示當(dāng)前商品。這是整個商品的全局控制；如果上架，則之后關(guān)聯(lián)的SKU也一同上架；反之則一樣。商品類型：單品/復(fù)合商品;部分平臺上支持打包出售的模式，也就是一個商品實際上是包含多個關(guān)聯(lián)子商品的。可以通過商品類型字段先標(biāo)記出當(dāng)前商品是單品還是復(fù)合商品；如果是復(fù)合商品，之后還需要關(guān)聯(lián)對應(yīng)子商品。

二、特有屬性

在上一篇《屬性管理》中，我們介紹了商品特有屬性的設(shè)置以及與品類的關(guān)聯(lián)綁定。在商品信息維護(hù)時，當(dāng)選定品類后，我們就能獲得已經(jīng)設(shè)置好的配置內(nèi)容，接下來根據(jù)配置將表單展示出來，并維護(hù)好其中的屬性值即可。

品類綁定屬性設(shè)置

規(guī)格參數(shù)維護(hù)表單

三、銷售屬性

在說銷售屬性前，我們先來了解兩個基本概念：SPU和SKU。

SPU：Standard Product Unit (標(biāo)準(zhǔn)化產(chǎn)品單元)

SPU是商品信息聚合的最小單位，是一組可復(fù)用、易檢索的標(biāo)準(zhǔn)化信息的集合，該集合描述了一個產(chǎn)品的特性。

SPU通俗的來講就是一類具有相同屬性、屬性值的商品，這些屬性和屬性值通常不參與商品的銷售價確定。如iphone6s就是一個SPU，無論你在那個平臺或者實體店查詢iphone6s，他們給出的商品屬性信息都是一致的。

SKU： Stock Keeping Unit(庫存量單位)

SKU即庫存進(jìn)出計量的單位， 可以是以件、盒、托盤等為單位。

SKU是物理上不可分割的最小存貨單元，而這個不可分割是相對于儲存場景的，對于相同的商品，在不同的倉儲場景下，對SKU的管理是不一樣的。

舉個列子，我們平時去超市買早餐奶，可以買一袋，也可以買一箱。按最小單元來說，那么”袋”就是超市管理早餐奶的SKU。超市的貨源是來自供應(yīng)商的，供應(yīng)商是按箱賣給超市的，所以”箱”是供應(yīng)商管理早餐奶的SKU。

不知道大家有沒有留意過，在物美、家福樂去買一箱奶，結(jié)賬的時候，收銀員不是掃描箱子上的條碼，而是打開箱子取出一袋來進(jìn)行掃碼，然后再輸入數(shù)量最后結(jié)賬，這也就能看出這些大超市的對奶制品的管理方式。

SKU可以簡單理解為：SKU = SPU 銷售屬性，當(dāng)在SPU上添加上商家、顏色、內(nèi)存等影響銷售加價的屬性后，這個商品就成一個SKU。

看著和上面SKU的定義有點出入，如果仔細(xì)想想，商家對商品價格的定義不就是按照商品的最小單元設(shè)置的嗎？

所以當(dāng)我們想要確定一個SKU時，首先需要明確有幾個屬性在影響價格，找到對應(yīng)的屬性，列出每個屬性的屬性值，通過屬性值的組合就能確定所有的SKU。

對于銷售屬性的維護(hù)，也是通過屬性和屬性值來操作的，但是有兩個特殊的地方需要處理:

在完成屬性值的維護(hù)后，需要根據(jù)屬性值組合來生成SKU：這個是整個商品模塊最關(guān)鍵的地方，因為后面的價格、庫存、圖片都依賴于生成的SKU。屬性值的個性化設(shè)置：如同一款手機中的相同紅色，不用商戶的叫法各不相同，如炫彩紅、玫瑰紅等待，以及不同的顏色上會上傳不同的款式的手機樣式圖。

維護(hù)好銷售屬性和屬性值后，就能通過組合產(chǎn)品唯一的SKU，之后商品的銷售價格、訂單、庫存等一些屬性信息，都需要與SKU直接掛鉤。

所以這里有一個特別需要注意的地方，一旦確定了組成商品的SKU銷售屬性后，就不能再做對銷售屬性進(jìn)行修改；如果添加或刪除銷售屬性，之前生成的SKU數(shù)據(jù)肯定就不對了，而添加或刪除某個具體銷售屬性的屬性值僅會影響部分SKU的數(shù)據(jù)。

1. 商品價格

在SKU維護(hù)時，有多個價格的設(shè)置，需要注意每個價格的用途：

1）采購價

采購人員從供應(yīng)商那里采購商品時的價格，系統(tǒng)中有幾個處會使用采購價的地方：

商品采購入庫時，商品的采購價格會同商品信息一起保存在入庫單中；在填寫商品的日常銷售價和活動銷售價時，會通過對比采購價，防止銷售價格過低而使企業(yè)受損失；商品完成訂單銷售后，系統(tǒng)計算銷售成本和應(yīng)收金額時使用。

2）吊牌價

吊牌價通常是供應(yīng)商在商品出廠時，為商品所設(shè)置的一個市場銷售參考價，價格通常會和商品的一些質(zhì)檢信息一同寫在商品的吊牌上。吊牌價一般在線下使用的比較多，如商場里的服裝時最為常見。

在線上系統(tǒng)設(shè)計時，吊牌價僅僅為銷售價設(shè)定起到一個參考作用，實際價格我們一般采用另一個概念——銷售價，銷售價又分日常銷售價和活動銷售價。

3）日常銷售價

商品在沒有參與活動時所設(shè)置的出售價格就是日常銷售價格，商品在上架期間日常活動價會一直存在的。

如果是個體商戶，戶主自己根據(jù)進(jìn)貨價設(shè)定價格，如果是大的自營電商，通常由采購人員根據(jù)采購價和期望利潤來確定日常銷售價。

4）活動銷售價

商品參與活動時所設(shè)置的銷售價格就是活動銷售價，活動銷售價只有在活動期間有效；活動過期，商品售價又會使用日常銷售價。大的自營電商里面，通常由采購人員來維護(hù)。

5）預(yù)警價

預(yù)警價格的設(shè)計主要是為了防止商品運營人員錄入失誤，將商品出售價格設(shè)置的過低，導(dǎo)致企業(yè)損失而設(shè)置的預(yù)警功能。

這個和采購價有部分類似，一般低于采購價是允許出售的。如一些即將過期的產(chǎn)品或拉新做的活動，但是低于預(yù)警價通常是不讓出售的。

常用的兩個地方：日常銷售價維護(hù)和活動價維護(hù)，這兩個價格在保存前都需要和預(yù)警價進(jìn)行比對，如果低于預(yù)警價，系統(tǒng)會給出提示，以確保價格設(shè)置正確。

2. 庫存

對于SKU的出售自然就涉及到了庫存，在商品維護(hù)界面僅有一個對庫存數(shù)維護(hù)的地方，也就是實際可售庫存。

對于大平臺的入駐商戶來說，通常采用手動錄入方式(有開發(fā)能力的可以做系統(tǒng)對接)，讓商戶自己維護(hù)SKU的銷售數(shù)量。具體填寫多少由商戶自己決定，這個填寫的數(shù)字就是實際可售庫存。

而對于平臺自營來說，公司通常都有自己的倉儲系統(tǒng)，每個SKU都有明確的存儲記錄，并且部分SKU參與內(nèi)部任務(wù)(如調(diào)撥、拍照、戰(zhàn)略儲存等)使得當(dāng)前時間不可售。

因此實際的SKU庫存可能并不等于全部可售，具體實際可售庫存需要通過倉儲系統(tǒng)經(jīng)過統(tǒng)計同步到商戶模塊中，而不是由買手自己手動維護(hù)。

3. 上架/下架

除了在商品的基礎(chǔ)屬性上設(shè)置有商品的上架/下架操作，通過在具體的SKU上也設(shè)置一個上架/下架操作，可以更加細(xì)粒度的管理到具體的SKU上下架狀態(tài)。

4. 第三方編碼

平臺在生成SKU時，會為每個SKU也分配相應(yīng)的揀貨碼(可能是商品身上的條碼，也可能是公司內(nèi)部自己定義的編碼)，以方便揀貨時使用。

如果是自營平臺，買手采購時供應(yīng)商會提供給采購平臺以便錄入系統(tǒng)；如果是平臺商戶，一是平臺沒有辦法采集數(shù)據(jù)，二是各商戶各自在揀貨時使用的規(guī)則各不相同，所以僅給一個可以讓商戶自己維護(hù)的字段。

當(dāng)有訂單產(chǎn)生時，在訂單模塊中導(dǎo)出的揀貨單中會帶有維護(hù)的第三發(fā)編碼以供商戶進(jìn)行揀貨操作。

5. 圖片維護(hù)

商品各位置的展示圖片，圖片維護(hù)通常有三個地方：列表圖、SKU圖組和默認(rèn)圖組。

列表圖：主要是搜索列表所展示的圖片；SKU圖組：為每個具體的SKU上傳對應(yīng)的一組展示圖片，主要用在商品詳情頁的展示上；默認(rèn)圖組：如果對應(yīng)的SKU未設(shè)置展示圖片，則顯示默認(rèn)的這組圖片進(jìn)行展示。

小知識點：圖片在展示時，為了能夠提升圖片展示速度，優(yōu)化頁面展示速度，商品圖片在上傳時通常會通過縮放，將圖片保存成多個不同的尺寸，以方便不同頁面進(jìn)行調(diào)用。

6. 導(dǎo)入功能

電商平臺上的商品成千上萬，如果都通過常規(guī)的表單一個一個維護(hù)，維護(hù)人員就得被累死了(看一下一個電子產(chǎn)品有多少產(chǎn)品規(guī)格)，通常系統(tǒng)都會設(shè)計導(dǎo)入功能供維護(hù)人員使用。

在商品信息的導(dǎo)入功能里有兩個限制：

一是一次只能導(dǎo)入一個品類，因為不用品類的特殊屬性不一樣，沒有辦法合并在一起；

二是僅能導(dǎo)入基礎(chǔ)屬性和特殊屬性信息，銷售屬性信息不支持通過導(dǎo)入生成，因為銷售屬性需要通過屬性值組合成SKU信息，系統(tǒng)需要生成唯一ID， 內(nèi)部邏輯比較復(fù)雜。

【#】后面為需要導(dǎo)入的特殊屬性列表。

上面介紹的內(nèi)容，基本涵蓋了一個商品的核心信息，大家有需要的可以根據(jù)自己的實際業(yè)務(wù)場景再進(jìn)行優(yōu)化修改。

四、商品維護(hù)流程

最后我們再來看一下商品的維護(hù)流程。

在電商平臺上的個體商戶，由于自家SKU數(shù)量比較少，從錄入商品參數(shù)到商品拍照、上架一個人基本都能解決。

但是對于自營平臺過萬的SKU，這樣的方式顯然是不行的。大平臺對一個商品的維護(hù)需要多個部門協(xié)同合作來完成，基本流程如下：

采購部：買手先維護(hù)好后端品類，為每個品類綁定關(guān)聯(lián)屬性，并設(shè)置好屬性輸入方式、搜索方式等基礎(chǔ)配置信息。采購部: 買手從供應(yīng)商獲取采購商品基本信息，并將商品基本信息導(dǎo)入系統(tǒng)中，并根據(jù)銷售屬性生成SKU。采購部：買手通過采購單采購商品，并協(xié)同倉庫一同將商品錄入倉庫完成商品采購，系統(tǒng)完成SKU同步庫存信息，買手完成日常銷售價格的維護(hù)。采購部：買手在系統(tǒng)提交商品圖像采集工單。圖像采集部：圖像采集部同事根據(jù)工單申請倉儲圖像采集調(diào)撥工單(將之前錄入的SKU每件調(diào)撥出來一件)。倉儲部：根據(jù)圖像采集調(diào)撥單，準(zhǔn)備調(diào)撥商品。圖像采集部：圖像采集部同事和倉儲部進(jìn)行交接出庫，拿到樣品、進(jìn)行拍照、修圖，完成后再上傳到系統(tǒng)中。圖像采集部：拍照完成后，將商品再還回倉庫中。倉儲部：將商品重新放回倉庫中。采購部：買手檢測商品信息完善后，就可以進(jìn)行日常上架銷售了。

以上四個步驟中，除了第三步采購入庫、設(shè)置價格會經(jīng)常使用，其它的三步僅在商品第一次錄入系統(tǒng)的時候需要維護(hù)。

對于上述操作流程有人可能有疑問，通常不是運營在做產(chǎn)品銷售嗎，這里怎么是買手呢？

在電商企業(yè)中買手的工作范疇主要是維護(hù)商品信息、采購、維護(hù)銷售價格以及下上架；而運營人員主要負(fù)責(zé)構(gòu)建活動、專題框架、活動和專題中的具體商品由買手來決定是否來參與，最終的利潤由雙方來分(運營和買手的薪資是和銷售額有關(guān)的)。

這個在后期的運營篇中會給大家繼續(xù)講解！

作者：JackLiu；個人微信公眾號: 揚帆去遠(yuǎn)航（ID:Jackai_liu)

本文由 @Jack 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自 Pexels，基于CC0協(xié)議。