1、電商系統可能是世界上最複雜的業務系統
說個有意思的小事，和一位PM同行聊工作，問我電商做的如何，我說並不是一件易事。對方哈哈一笑，說電商不就那麼回事嗎，有啥難的，是個PM都能做，我嘿嘿一笑，不作辯解。
光說中國電商，發展至今已有20多年的歷史，且一直處於高速的發展和競爭當中，時至今日，都不可妄語塵埃落定，對於大型公司來說，電商僅為銷售渠道之一，而在此基礎上衍生出來的研、產、供、銷、服整套的資訊系統體系，才是支撐其運作的核心。當你從銷售或是使用者這個點來看電商，會覺得無比簡單，而當你從整個體系的面來看電商時，會覺得沒有邊際。
2、一圖描述電商架構
以下僅展示與電商直接有關聯的系統模組，而對於一個大型企業的IT系統架構，是遠不止下圖中包含的系統單元的。隨著業務的發展，每個系統單元都需要長時間迭代，其成熟的過程中凝聚了大量的人力物力，鄙人只能管中窺豹，從概念層面來描述，每個系統模組的大致功能。
3、從一個訂單開始說起
由一個使用者下單的主幹流程，可以看出所有系統之間的互動流程，直接畫圖說明。不同公司的業務、團隊劃分都不同，故此IT架構的劃分也不是絕對的，舉例來說，支付業務，我在圖中劃分到了交易中心，而現實中也有併入結算中心的。
4、庫存怎麼來的？
5、各業務單元概念及作用簡析
由以上2個主幹流程和系統架構圖，可以對電商系統的全鏈路有個基礎瞭解，下面再用文字描述一下各個系統單元的概念和作用。每個模組的PRD都可以單獨成章，在一篇文章當中也不可能描述所有細節，但對於部分系統的解析，可以在我的部落格中看到，我也會持續更新。
6、大前臺
6.1各個銷售前端
一家公司往往有多個銷售渠道，線下有不同型別的加盟店直營店等等，線上也有不同模式的電商，而這些觸點用於直接讓使用者接觸到商品。拿阿里巴巴來說，在淘寶體系下本身有天貓超市、普通商家端、淘寶直播、天貓APP等等。
6.2 CMS
除了商品頁面之外網站和APP還有其他的內容頁面，比如說店鋪的首頁、維修退換政策、活動頁面等，這些都要用單獨的內容管理系統去承載，直觀的瞭解來看大家都用過QQ空間，其中空間的裝修就可以理解為是一個簡單的cms系統。
6.3交易中心
交易中心其實是一個技術的中介軟體，所有和銷售前端互動的系統都要透過交易中心來完成，此外還要承擔一些使用者主要交易流程當中的邏輯，舉例來說，下單之前需要先呼叫庫存服務，查詢庫存，使用者加入購物車之後，要透過呼叫營銷中臺來計算購物車內商品活動後的總價等。
7、大中臺
7.1商品中心
簡單來說，商品中心就是一個商品的資料庫，會在所有的業務系統當中都用得到，其來源包含第三方的和自主建立的。主要包含的有三層關係，第1層關係是類目，產品的類目分前臺類目和後臺類目可以在不同的渠道下自定義支援。第2層關係是spu和sku的關聯。第3層關係是屬性，屬性可以繫結在類目下，也可以繫結在spu下或者是sku下，子會繼承父的商品屬性，相關的文章也有很多，我的部落格《從小賣鋪開始，聊聊商品和庫存模型》中也有大致介紹。
7.2營銷中臺
營銷中臺主要包含兩大塊，第1塊為活動，第2塊為優惠券碼。可以針對不同的使用者、產品、渠道進行優惠活動的設定，對於使用者感覺來說，優惠活動一般是在購物車當中呈現，而優惠券碼一般是在結算時扣除相應的金額，我的部落格《非平臺型營銷中臺搭建全貌》一文中也有概述。
7.3庫存服務
庫存一般會分為三級，渠道當前可售庫存、產品可售庫存、倉庫實際庫存。其解決的核心問題是，使用者從下單開始到最終扣除倉庫庫存，在不同環節應該如何去扣減，從而達到最高的庫存使用效率，我的部落格《銷售庫存模型講解》一文中也有介紹。
7.4 WPS
WPS解決的核心問題是，商品應該如何排程。具體來看，當訂單接收之後，應該由哪個倉庫來進行滿足，使用者在商城介面看到是否有貨，應該如何判斷。我的部落格《多倉模式下的分倉和拆單》一文中也有介紹。
7.5 Express
Express解決的問題是，當商品的發貨任務已經分到了具體的倉庫，我們應該使用哪一家的快遞，才能同時兼顧成本和速度。因為在不同地區的倉庫，快遞公司的服務響應、成本是不一樣的。其核心邏輯是，對於不同的倉庫，在路線的配置上選取不同的快遞公司。
7.6會員中心
會員中心其實和我們玩王者榮耀的使用者等級很像，是對不同的渠道提取出共性的使用者升級規則，又或者是付費型會員。舉例來說，一個遊客使用者看到的商品價格是100元，當遊客登入後，會發現使用者的會員等級是付費會員，此時前端頁面會調取商品中心當中的會員價格再呈現給使用者，此時使用者看到的商品價格是80元。
7.7發票中心
一般來說，業務發展到全球化的時候，才會誕生髮票中心。因為不同的國家才會對於開票的規範有不同的要求。其核心流程就是兩個，一個是開票，另一個是衝紅，但是在不同的業務下，可能對於開票和衝紅的時間點會有不同，這一點一般是由訂單中心來進行定義。
7.8客服服務
這一點比較好理解，一般客服系統的搭建現在分為三大塊。第1塊是線上聊天客服，使用者發起的聊天會分配給系統後臺的人工坐席。第2塊是智慧知識庫，會將使用者所有的常見問題彙總到知識庫當中，給使用者自動推薦，從而減少人工客服的壓力。第3塊是客服的系統操作檯，客服可以幫助使用者人工的干擾一些訂單的程序，比如修改價格建立退換單等等。
7.9秒殺
由於中國使用者的數量眾多，特價商品的活動，幾乎都會用秒殺的方式來進行。故此秒殺已經成為了各個中大型電商的基本服務，其核心邏輯就是在於多極快取，逐級篩選使用者。
7.10風控
風控的應用場景其實有很多，這裡只談談下單場景的應用。如果我們判斷出一個高風險的訂單，這個訂單將會被系統給拒絕，一般我們會從兩個方面去判斷，一個是使用者歷史的行為，一個是使用者當前的下單風險，前者來說，我們可以看使用者的賬號是否高風險，是否有比平常人更高的拒收率等等，後者來說一般是判斷使用者是否存在技術刷介面的可能性，比如判斷這個使用者在當前下單的時候，是否請求過於頻繁。
7.11結算
一般包含三個步驟，對賬清分和結算。將我們從第三方支付獲取的貨款進行自動結算，告知財務一個結果，從而打到供應商的賬戶當中，一般會和集團的OA審批流進行結合。
7.12資料中心
所有系統的資料都會共享給資料中心然後基於資料去進行各種場景的組合和應用。舉例來說最常見的是使用者畫像平臺，運營人員需要透過使用者畫像平臺去篩選出使用者的偏好，來進行精準營銷。舉例來說，當我們想主推一款手機殼的時候，運營人員可能先去篩選出最近30天購買過新手機、加購過手機殼、最近30天沒有購買過手機殼的使用者群ID，然後給這些使用者去發PUSH。
7.13訂單中心
所有渠道的訂單都必須匯聚到訂單中心，然後進行統一處理，舉例來說，我們的天貓店，淘寶店，抖音店，快手店以及自營電商平臺，使用者提交的訂單都會匯聚到訂單中心，然後再進行下一步的流轉和操作。同時財務的結算也會以訂單中心的訂單狀態為標準，這樣保障所有系統的上下游資料都有一個通用的資料來源。
8、大後臺
8.1WMS
和某一個具體倉庫相關的所有業務流程都在wms管理，具體包含的業務流程有三個出庫，入庫和上架。出庫的型別有很多種，比如說電商訂單的型別就是購買出庫，當倉庫接收到出貨單以後會列印分揀單，倉庫員工會根據分揀單對於貨物進行揀貨、打包等操作，最後將打包完畢的商品放在出庫區等待承運商拉走。入庫的型別也有很多種，一般最常見的就是採購入庫。而商品上架則是需要先根據倉庫的庫位管理劃分很多的區域，然後再將不同的商品商家都不同的區域。
8.2XMS
XMS中文名稱叫售後管理系統，售後的型別有三種退換修，然而退換修需要有不同的備件庫，可能是更換零件進行維修，也可能是直接更換整機。如果是退貨的話，則需要在XMS當中判定使用者發回的貨是滿足退貨條件的，此時在XMS當中會告訴訂單中心，從而再觸發支付和結算業務的退款流程。
8.3使用者中心
使用者中心也就是儲存使用者基礎資料的地方，同時需要承擔使用者的註冊登入找回密碼，更換手機號的相應流程，對於不同的國家，需要支援不同型別的註冊方式，比如手機號註冊和郵箱註冊或者是谷歌賬戶註冊，同時在技術方案上也要支援不同型別的前端產品，比如說支援Web、Webview、APP等。對於不同風險等級的業務，也要支援不同型別的註冊方式，比如只是電商業務的話，只需要手機號註冊即可，但如果是金融信貸業務，則還需要支援人臉識別或者是身份證認證等。
8.4 SRM
SRM的中文名為供應商管理系統，核心邏輯是對於不同的供應商進行打分和評判，篩選初優質的供應商。同時對於詢價、採購、物流、財務等供應流程進行資料化管理。