為什麼說其實做電商是避無可避的事情？電商項目該怎樣開始入手？如何從零開始，搭建一個B2C商城框架？中小型團隊開發，電商項目初期只要配齊哪些功能就好？
商業變現
前一篇文章《從零開始做電商，你確定搞懂行情了？》介紹到，在進行電商項目立項之前，該如何結合產業鏈、行業供應鏈和企業價值鏈來評估市場機會和考慮電商產品的定位，經過市場分析之後，再決定佈局做電商的價值。這是做純電商的思路。
但其實，電商還有一種比較廣泛的應用，那就是完成產品的最後的環節——商業變現。
也就是已有的產品，在完成流量的導入跟用戶沉澱之後，最後以商城來完成商業的閉環。比如：抖音、keep、小紅書還有今日頭條的放心購。小紅書APP至今保留著內容社區的主架構，商城是作為第二大的功能加入產品中的，兩者相互配合，各自完成流量、用戶和營收的難題。
須知，移動互聯網產品的發展路徑往往殊途同歸的：做工具的想做內容，做內容的想做社區，做社區的想做電商。套用一篇文章的標題，就更加直白了：《互聯網亙古不變的商業模式：工具/內容+社群/社區+電商/服務》。畢竟工業發展到商品遠遠過剩的現在，銷售的迫切本來就自然而然地優先尋找新的銷售方式。
所以，其實很多時候，權衡來權衡去，其實電商往往是現在不開發，未來也總會考慮的事情。
所以該回到現實層面考慮了，無論是純電商還是內容型電商。目前比較應用廣泛的還是B2C的商城，零售商模式，直接企業/商家對接消費者。B2C商城的業務集中，貨源自採或者是自制，庫存可集中管理，物流統一發貨，客服售後可同步協調。與之相對應的，供應鏈信息化之後的商城也簡單些，這個量級一般的中小企業自主開發也不成大問題。
簡介
接下來，我們會以實際的做過的案例作為主線說明，市場上常見的電商產品做輔線介紹，從前端後臺角度，配合說明如何設計一款最簡版B2C商城，介紹其中的業務邏輯、模塊配合和設計注意點。當你知道見識過並且知道為什麼的時候，自然就能做出最好的設計，現在，需要的是儘早地渡過早期的新手階段。
P.S. 由於是創業公司，筆者是通做前端管理後臺的設計。因此，正好可以完整地以早期版本的思路來介紹B2C商城的從零到一的設計。
至於後續隨著業務的發展，商城可以隨著經驗積累和人員增加進行更加複雜和完善的設計，前期做好架構設計和模塊解耦就好。
項目背景
正如之前在之前的文章介紹過那樣，我們是做細分領域的平臺型APP，用戶人群是休閒垂釣愛好者，男性用戶為主。用戶在垂釣裝備耗材上還算捨得消費，但是多以線下實體店消費為主，是個機遇也是個難點。
我們原有的產品，在決定加入電商模塊之前，跟keep和小紅書一樣，已有其他的模塊承載導流跟留存的功能了，商城是作為商業變現的環節。
不過呢，在結合其他模塊之前，商城還是先獨立運作，後續再考慮場景的接入。
需求分析
跟做別的C端產品不大一樣，其實做商城跟做B端的產品一樣，需求其實很明確。重點了解公司關於商城的業務流程、角色任務、團隊的開發實力、再結合用戶畫像和競品分析，綜合考慮時間，需求確定起來相對容易。
業務流程上，我們的商品貨源自控，兼有自制跟自採，由多家供應商供貨，商品資料收集後到平臺統一上傳，商品集中倉庫管理，用戶下單之後，會統一物流發貨，售前售後自控處理。商品都是C端用戶的釣魚裝備和耗材，品類比起B2B2C商城而言少且集中。因財務上的個性化需求需要接入聚合支付服務商。
細說一點，跟其他產品的需求分析不同，如果不是加入一個已有的電商團隊，團隊本身沒有相關的經驗，其實競品分析會比需求分析要重要得多，因為PM需要首先引進外部經驗，先形成團隊共識，再來談需求。
因為你從甚至沒有成型概念的內部開始收集需求，梳理功能，做業務流程，平衡取捨做出來的東西，很可能錯漏百出，不能用，還要來來回回地補鍋。而電商的理論和產品發展到現在，體系已經相當成熟且高效，善用前人的輪子，你能學習到並且會做出更好的設計。
跟我們在實例分析拆解：如何設計一個運營活動類H5？裡做的需求主要來自於運營和場景推演的不一樣，電商初版的需求主要來自於競品分析，之後隨著運營起來，團隊和用戶都在實際運作中會產生確切且源源不斷的需求。
高效的經驗毋庸置疑是要學習，但設計流程和方式都可以視乎項目而變更，畢竟學習套路都是為了高效使用，看情況具體問題具體分析是被低估的品質。設計本無定法，合適的才是最好的。
名詞概念
在需求跟競品分析階段，儘早完成電商的入門。如前文所述，電商體系是線下供應鏈的信息化，在已有業內規範情況下，無論是買書研讀、報班學習還是社群共修，儘可能去了解電商體系的特有比較核心的概念和規則，這裡簡單羅列關鍵一點的：
概念：
- 商品管理：SKU、SPU、商品類型、類目、商品編碼、貨號；
- 訂單：庫存鎖定/釋放、優惠分攤；
- 數據：客單價、筆單價、復購率。
規則：
電子商務法、7天無理由退貨（在設計售後會用得到）。
SKU跟SPU是做電商必須重點掌握的概念，SPU=Standard Product Unit （標準產品單位）; SKU=stock keeping unit( 庫存量單位)，這都是在不同的維度來描述商品。在日常使用場景下，大家是不區分這兩個概念的，但是做電商是必須區分清楚彼此的不同。
比如：魅族16th是一個SPU，區別於另一個SPU魅族16th plus; 但是魅族16th下還有不同的型號在，比如不同顏色，不同的內存，所以一個SPU下會由SKU更詳細地來描述，魅族16th 遠山白 8+128GB就是一個SKU。
更多的術語概念在具體模塊的應用場景也會涉及到的。
商城框架
經過需求分析、競品分析和業務流程梳理之後，確定下來的功能模塊為以下羅列項，分客戶端跟管理後臺：
（1）客戶端
商城主版、主題頁面、商品詳情、購物車、訂單（主訂單+維權訂單+退款單）、地址管理、評價中心、優惠券、客服和消息通知。
（2）管理後臺
商城設置、商品管理、頁面管理、訂單管理、運營營銷、商城角色、賬務中心、數據統計和其他。
電商的設計可繁可簡，無論如何，在設計初期，搭建的產品架構一開始就要將模塊彼此獨立出來，這是為了保證後續的可拓展性，即使規劃的是最簡版；解耦的設計思維在商品管理模塊的專門章節會表現得更清晰些。
滿足上述功能的商城產品架構如下所示：
B2C商城架構圖
因為客戶端上我們是在已有的產品里加商城模塊，所以常規的登錄/註冊，意見反饋等不再列出，做純電商的要自己注意。
後臺系統裡商城角色（用戶/會員/推廣員/業務）跟賬務中心屬於比較個性的需求，而物流系統、支付系統和客服系統都直接用服務商提供的服務就好。
尾聲
電商是移動互聯網產品實現商業模式的重要途徑，其中又以B2C商城最為常見。本文意在在詳細講解實際的B2C電商模塊的設計之前，統括介紹項目的背景，介紹電商的概念和一些前期工作的注意事項，並且給出最簡版B2C商城的架構。
其實呢，不同的商城框架都比較相近，但是到模塊的詳細設計就會有比較大差別。
如果說要有什麼設計的建議的話，就是，一開始的話，最好儘量用敏捷開發的思路先完成通用的核心的功能，個別獨立而複雜的模塊，用服務商的SDK來完成，後續自己團隊再將精力放在迭代重要業務線和完善系統上。
如果對本文有不同看法或意見建議的話，直接留言就好。
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
