中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

商品管理是電商的重中之重，是一切的基石。

讀大學那會還真沒有想過自己最后會涉足互聯網。不過命運就是這么奇妙，兜兜轉轉，最終我這個當初看不起互聯網的屌絲也臣服在IT女神的皮鞭蠟燭之下，甘愿驅遣了。進入這個行當，就一直在做電商，從前端APP、H5頁面等的設計，到后臺的運營后臺，以及中臺ERP/WMS，都有涉及。眼看著很多做電商的小伙伴們，設計前端APP模塊的時候還有競品還分析，設計運營后臺就沒多少競品可供參考了，故趁著最近心情還不錯，本著獨樂樂不如眾樂樂的精神，就分享些個人的經驗，免得大家踩不必要的坑吧。

計劃是寫一個長篇系列，以自營的B2C平臺為例，剖析運營后臺主要框架，如果興致高，可能還會包括WMS。不過我素來是懶癌患者，大家就求多福吧。以下是預計撰寫但不一定寫的文章，收好，不謝：

• B2C電商是如何煉成的-運營后臺之商品管理篇
• B2C電商是如何煉成的-運營后臺之訂單管理篇
• B2C電商是如何煉成的-運營后臺之營銷管理篇
• B2C電商是如何煉成的-運營后臺之采購管理篇
• B2C電商是如何煉成的-WMS篇
• B2C電商是如何煉成的-運營后臺之會員管理篇

上面廢話了那么多，接下來，干貨直接出場，請熱烈歡迎第一篇：商品管理。

概論

商品管理是電商的重中之重，是一切的基石。對于運營后臺商品管理，私以為主要要滿足以下需求：

1. 使用戶在前端能快速的發現商品（主要依賴于搜索以及商品列表頁的篩選、前臺分類的運營、促銷活動的結構化以及精準化推薦等，這方面就要求商品管理模塊能提供結構化的特征屬性）；
2. 使用戶得到盡可能多的決策必須的信息（例如：品牌、名稱、規格參數、文描和價格等）；
3. 使運營童鞋方便的維護商品信息（例如盡可能的簡化維護步驟，使需要維護的信息盡可能的簡潔而又完備）；
4. 使運營童鞋能夠方便快捷的實現整個商品生命周期的管理（從創建，審核，上架，下架和回收等）；
5. 使運營童鞋能夠結構化的管理整個平臺的商品庫（一個平臺少則幾千幾萬個SKU，多則幾百萬幾千萬個SKU，要分門別類，為運營提供品牌，基礎分類等多個維度來管理商品庫）；

以京東的前端某商品詳情頁為例：

對于上圖的手機頁面，前端呈現的各種信息怎么樣通過后臺商品管理模塊一步步維護，請帶著瓜子板凳，聽我慢慢道來。

商品管理的主要框架圖見http://www.xmind.net/m/kHXe，截圖比較模糊，大家可以到所述網址下載，更清晰。

具體的講解順序，就按照

1. 基礎類目管理；
2. 品牌管理；
3. 屬性管理；
4. 商品管理；
5. 前臺分類管理開搞吧。

1基礎類目管理

對于未接觸過電商的童鞋，可能對基礎類目沒什么概念。其實這個東西很好理解，基礎類目就是商品屬于什么基礎分類，是手機，還是平板，還是筆記本電腦，換言之，商品的基礎類目就是定義商品是什么。類似于生物學的門綱科目屬。不同的基礎類目之間實際上是描述這個類目的特征的不同。

例如手機這個類目，對應的特征就是：前攝像頭像素，后攝像頭像素，屏幕尺寸，網絡制式等；而褲子這個類目，對應的特征就是：腰圍，褲長，面料材質，厚度等。對于電商，習慣上把描述不同類目的特征稱之為屬性，每一個類目維護的時候，就要選定該類目的屬性，然后新增商品的時候，先選中該商品的類目，則會出現對應的屬性供運營者維護。以屬性為區分維度建立適合粒度而又不耦合的類目樹，串聯所有的商品，是商品管理的核心所在。

一個電商APP的運營后臺基礎類目樹只能有一顆，任一個商品只能屬于該類目樹上的一個基礎類目。具體的類目管理包括：類目節點的新增/編輯/刪除、類目節點的排序和類目節點的屬性維護。

1.1子節點的新增/編輯和排序

每個平臺默認有一顆基礎類目樹，點擊菜單進入該類目樹詳情頁，以選中的“休閑零食”這一節點為例，第一個頁簽“節點詳情”為當前節點的明細，包括三個信息：名稱（必填），描述，是否最小分類（必填，單選）。最小分類的概念是指在運營維度該分類已達到平臺所需的最小粒度，沒有必要在其下繼續細分分類。

對于非最小分類的節點，選中該分類還會有額外的兩個頁簽，第二個頁簽是在當前分類下新增子分類，第三個頁簽是當前分類下一級子分類的排序操作。具體的界面下圖：

分類詳情

子分類新增

子分類排序

具體的頁面交互細節就不說了，值得注意的有二：

• 萬一一個分類剛創建的時候被定義為了最小分類，例如上圖中的“油炸商品”，后續商品SKU太大，運營需要繼續細分，就需要變更這一定義，同時也有可能有分類創建的時候是“非最小分類”，后來需要變更為“最小分類”，這個時候需要校驗一個邏輯：當前分類及其子分類有無關聯商品。如果有商品，則不允許變更，若無商品，則可以變更。
• 刪除某分類時，需校驗該分類及其各級子分類下是否有關聯商品，若有，則不可刪除；若無，則可以刪除

1.2基礎類目的屬性管理

對于是最小分類的節點，則其沒有子分類的新增和排序的頁簽，而是有額外的頁簽：分類屬性。具體頁面如下：

分類屬性這個頁簽主要是定義當前分類的商品具有哪些屬性。這里有幾個概念需要先解釋下。

• 屬性分組：由于一個分類的屬性有時會很多，可能幾十上百個，所以又引入了屬性分組的概念，把形容某一類特征的幾個屬性歸屬于一個組，這樣在前端的規格參數里可以按后臺設置的屬性分組按序展示。
• 屬性的用途：分為基本、系列和導購?；緦傩允侵冈搶傩詴徽故驹谇芭_商詳頁的規格參數里。如下圖：

• 系列屬性是同一品牌同一款產品的不同型號區分的特征，例如同一款衣服的尺碼：S,M.L.XL，例如Ihpone7的顏色：黑、灰。系列屬性主要是為了前臺商品的聚合展示，在同一個頁面，通過勾選不同的屬性值，就能對不同的商品操作，大大方便了用戶，提高轉化率。

• 導購屬性是指在商品列表頁，展示了多種商品，能幫助用戶繼續篩選所需商品的可篩選屬性。如下圖：

解釋了上述概念，編輯和排序的具體細節操作不一一講了，只講比較重要的，就是對于最小分類，如何添加和刪除屬性。

添加屬性：分類的屬性必須從已維護好的屬性庫里去選擇。具體的操作界面如下，點擊添加后彈出查詢彈窗，查詢到需要的屬性后，選擇該屬性在當前分類下的用途，點擊添加，即添加到當前分類。

刪除屬性：若當前分類無商品，則屬性可直接刪除；若有商品，屬性無法真正刪除，從某屬性組刪除后會自動跳入默認的屬性分組（每一個分類都有一個默認的屬性分組）；

刪除屬性分組：則需校驗當前分組下無屬性。

2品牌管理

品牌管理的意義在于，維護一個平臺共有的品牌庫，商品新增和編輯的時候，只能從品牌庫勾選已有可用的品牌，從而避免前臺一個品牌多個名稱，同時在運營過程中也能清晰的按品牌維度操作。

品牌管理主要分為品牌的查詢、新增/編輯和刪除。具體的新增/編輯頁面如下：

其他細節不一一贅述，有三點值得注意：

• 一個品牌可以維護多個品牌別名，中間用；隔開即可。維護別名的意義主要在于方便用戶前臺搜索；
• 只有“啟用”的品牌，才能是商品編輯的時候被選中；
• 刪除品牌時，只有當前品牌沒有被商品關聯選中，且品牌狀態為已停用，才能刪除。

3屬性管理

屬性管理主要是建立一個屬性庫，以精確描述商品，為用戶提供必要的商品信息。就像我們形容一個人，會用身高、年齡、性別等屬性來描述一個人。從前文講基礎類目的時候，聰明的讀者應該已經領悟到了每一個基礎分類實際上就是一個屬性集合（不要告訴我你不是），其實這才是暗合宇宙真理。哲學幾大問，第一問就是“What”，要回答what是what，必然是用一個屬性集來拆招的。

和品牌庫一樣，屬性庫主要也是滿足屬性的查詢、新增/編輯和刪除的功能。主要講下屬性的新增/編輯吧。下圖就是屬性新增/編輯的頁面。其中屬性的編輯方式是“單選”或者“多選”的時候，下方必須維護可選擇的值。

其中有一點需特別注意，屬性的刪除需校驗當前屬性沒有被基礎分類關聯，若關聯則不允許刪除。

4商品管理

經過上面的步驟，建好基礎分類，建好品牌庫和屬性庫，維護好基礎分類的屬性，就可以來新增一個商品了。商品管理模塊同樣離不開商品的查詢、新增/編輯、刪除以及商品的狀態控制。

首先講下商品的狀態控制。一個商品，從商品運營童鞋在后臺新增，到上架以便前端用戶可見可購買，不僅僅是上架下架這么簡單。一個規范的商品管理模塊，應該將涉及到商品運營的工作人員的工作流程化。具體來看，需要承擔的工作有：商品的新增/編輯/刪除（維護商品庫），商品的審核（審核內容及售價），商品的上架和下架（日常銷售運營），商品的巡查（即通過審核后的抽查）。不同的公司有不同的做法，有的是把職責綜合起來，有的是分開來，但不管怎樣，上述四個職責，是一定要體現的。下圖是商品的管理流程：

本來自營的B2C平臺沒有商家和平臺之分，但為了大家更好的理解商品的新增/編輯/刪除、審核、上下架、巡查（即上圖中的鎖定）各種操作，故特意假定自營也是一個特殊的商家，故上述流程引入了商家和平臺的概念。具體對應的商品狀態有新增、待審核、待上架、審核不通過和已下架5種。

這么多操作中，具體講下普通商品的新增和系列商品的新增。（建議參考前文給出的商品管理腦圖，互相映照）

4.1普通商品的新增

商品新增的入口在商品查詢頁面，或者商品詳情頁。點擊新增按鈕，出現如下彈窗，其中商品類型分為普通和虛擬，倉庫性質為國內倉，直郵倉，保稅倉，商品分類為欲新增商品的基礎分類。這三個字段決定商品維護的信息不同，以及含該商品的訂單處理流程不同，故需要在新增第一步定義。

定義好之后，點擊確認，則跳轉到具體的商品新增頁面，如下：

要完成商品信息的維護，需將六個頁簽都維護完畢。其中商品圖片主要是上傳商品的圖片，商品描述是一個富文本輸入框，用來輸入商品的文描。其余三個頁簽界面如下（商品頁面的操作按鈕隨著商品的狀態變化）：

類目屬性頁簽：主要維護該商品在當前基礎分類下的各個屬性的值。

庫存運費頁簽：主要維護該商品在各地區的所屬倉庫以及各倉庫中的庫存控制，還有當前商品適用的運費規則。

值得注意的有：

1. 每個商品可選擇一種運費規則，購物車結算時，遵守同一運費規則的商品按照規則計算該組用戶運費，綜合不同規則算出來的運費即為本次結算的總運費；
2. 一個商品可存放多個倉庫，每個倉庫需要設置該倉庫的銷售范圍，這樣可以根據前端用戶的地址判斷庫存及訂單的拆單與推送；
3. 每個倉庫可以單獨設置該商品的庫存管理方式（簡單起見，也可以同一設置，各倉庫存單獨和WMS同步）

價格設置頁簽：主要維護該商品在不同平臺（APP價格可以設低，以吸引用戶轉移向移動端），不用會員組別（新用戶可低價以吸引用戶下單，高等級用戶可以享受低價以提升用戶忠誠度）之間的售價。

一般來說，三個維度的價格已足夠。

• 采購價：可以用來分析商品毛利和凈利，也可以用來做售價的設置預警，當設置的售價相對于低于采購價多少時，預警或者設置不通過；
• 參考價：即專柜價；
• 售價：即用戶前端結算時的價格，此價格又可以細分出一個特價，并可以設置生效時間，這樣，當需要舉行降價促銷時，可以事先設置，過后自動恢復原價。

4.2系列商品的新增

系列品的概念前文已經講過，簡單舉例再說下，就是一件衣服S/M/L不同的尺碼，或者不同的顏色。對于這樣的商品，有的平臺運營后臺在后面維護成一個SKU，但帶有不同的銷售屬性，個人認為比較好的做法是，把每個最小物理單位在系統中都維護成一個獨立的SKU，只是在前臺展示的時候按屬性做下聚合，做到同一個頁面點擊不同屬性就切換到不同的商品。如此，價格和庫存等所有商品信息，都是每個獨立的SKU控制。

具體的系列商品怎么聚合而成，且看下圖：

上圖是平臺所有系列商品的查詢界面，點擊新增，則彈窗如上圖右側，選定系列品的基礎類目，品牌以及用哪個系列屬性（即前文定義的屬性，其用圖包含系列）作為聚合維度，點擊確認，跳轉到系列品的新增頁面如下圖所示：

具體的交互和邏輯就不講了，只提一個問題給大家，為什么我要限制系列品的類目和品牌？

還有一種商品形態，組合商品（即將兩個獨立的SKU A和B 打包在一起賣，同時A和B獨立也在售賣），不過組合商品現在的應用實際上也沒有那么廣泛了，就簡單講下吧。

對于組合商品通常有兩種實現方式，一實一虛。實的是指組合商品C=A+B是一個獨立的SKU，與普通商品一致有必要的商品信息（例如圖片和文描），用戶下單時系統里生成的訂單商品表里直接記錄該獨立SKU=C的信息，只是在該訂單發往WMS履行時，才將A和B而不是C推給WMS，該方式會帶來一系列例如庫存，銷量統計等的不便；故個人認為可行的方式是走虛的路線。即在新增組合商品時，實際只是新增了一條價格設置，當用戶在前臺搜索到A時，A的詳情頁會告知A+B的組合優惠價，用戶一起將A和B 加入購物車結算時優惠的組合價生效。該種方式組合的商品沒有獨立的商品信息，但庫存管理簡單，下單主流程改動較小，對于系統而言，輕而且方便，也實現了以優惠帶動目標商品銷量的根本目的。

5前端分類管理

前端分類是指PC或者APP中便于消費者定位某商品而又運營童鞋管理的一種分類，此分類與基礎分類最大的不同，在于基礎分類是定義一個商品是什么，有什么屬性，不同基礎分類之間的屬性按理是不一樣的，一個商品只能屬于一個最小基礎分類。

前端分類是與消費者聯系比較密切的一個分類，與消費者的認知趨同，貼近消費熱點，比如Iphone7 128G黑色這款手機，即可能出現在前端“雙攝像頭手機”分類下，還可能出現在“大屏手機”分類下，或者將各個品牌最新旗艦手機聚合成一個分類，歸屬于“暢銷旗艦“分類下。

前端分類不局限于一顆，有可能PC是一顆，H5和APP是一顆，也有可能APP上不同的頻道頁的都有獨立的分類樹。

前端分類樹及其分類節點的查改增刪就不一一細說了，這里只簡單講一個問題，怎么把商品聚合到某個前端分類節點下？其實這無外乎一個選品的功能，按照基礎分類、品牌、和單個SKU三種不同維度篩選出商品，然后聚合即可。

前端分類建好了，商品也關聯好了，怎么展示在前臺相應的位置？這個簡單點的，可以由前端頁面接口中寫死；更進一步，可以由CMS模塊來做配置，指定某頁面展示某分類樹，這一塊，就要在以后的文章中談到了。

結語

B2C電商（自營）運營管理平臺之商品管理模塊至此介紹完了。以上只是筆者從業以來經驗的總結，不同的公司有不同的使用場景，其中細節部分大可斟酌，但萬變不離其宗，就看大家怎么去架構了。希望上文能給大家帶來幫助，坑能少踩就少踩，畢竟出來混，坑自己不要緊，坑了隊友那就悲劇了，是吧？

作者：一夜不孤城，微信：akulama

本文由 @一夜不孤城 ?原創發布于人人都是產品經理。未經許可，禁止轉載。