起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識淺聊一下廣義供應鏈的前中后臺
編輯導語：無論是傳統企業還是電商，供應鏈都是一個非常重要的環節，同時供應鏈也是一個極其復雜的系統，包含了從生產制造到流通過程中的所有環節。本文作者對廣義的供應鏈進行了分析，一起來看一下吧。
無論是傳統企業還是電商，供應鏈都是一個重要的環節，且無法繞過。甚至一個企業的成功與否，很大程度上取決于其供應鏈建設的完整性。但是供應鏈是一個極其復雜的系統，包含了從生產制造到流通過程中的上下游的所有環節。筆者在本文嘗試去打造一個“烏托邦”式的供應鏈，淺淺的聊一下廣義的供應鏈都包含哪些內容，希望對你有所啟發。
注：本文所述的供應鏈，是圍繞自產自營電商進行假設
一、供應鏈
本文不再從基礎定義去推導什么是供應鏈，直接關注業務本質，來便于大家快速理解。
1. 人貨場
凡是需要進行貨物或者服務的有償傳遞的過程，都離不開人貨場。
- 人：上游包含了原材料提供商、生產制作商等；下游包含了經銷商、店員、倉儲專管員、快遞小哥、消費者等；公司內部包含了采購計劃組、調撥組、訂單組、物流組、財務BP、前端業務方，甚至供應鏈產品經理。
- 貨：可能是一個實物，可能是一種服務，在“人”的不斷交付過程中完成功能的升級，例如從農民手里的甘蔗，通過生產制造變成了精美的白糖，再通過物流運輸，分發到網店或實體店，再被購買后由快遞小哥送到消費者手里。
- 場：“人”與“貨”的串聯是需要物理空間來承載的，“場”就是這個物理空間，工廠、倉庫、快遞中轉中心、運輸工具等共同組成了供應鏈的“場”，并在這些環節中將“人”與“貨”的串聯形象化，可視化。
上述是基于業務場景進行的劃分，傳遞到產品層面時，我更加傾向于用“四流合一”來抽象供應鏈，并拓展供應鏈形成一個廣義的供應鏈。
2. 四流合一
傳統四流主要強調的是企業與上游之間的溝通與往來，忽略了下游的銜接；為了提高整個項目的效率，實現降本增效是應該統籌看待上下游的四流合一。
- 信息流：傳統場景是買賣雙方的信息交換與溝通，現在更多的是要求各個系統之間的打通，信息傳遞高效率，例如生產管理系統-ERP-OMS-WMS-TMS之間的信息自動化傳遞，從而提高作業效率。
- 商流：信息傳遞是多樣性的，如何保證規范，那就要依靠商流中的合同約束、合同結算、合同付款來一步步的有效管理，甚至到下游的商品銷售、發票獲取等。
- 資金流：在合同完成結算后就需要涉及到實際的資金撥付，在實際場景下交付方式可以基于合同具體節點、壓款等各種形式，就會導致合同結算進度與實際資金撥付差異，能反映出整體預算與決算的差異，保障各個階段的供應鏈計劃順利運行。
- 貨物流：回歸到供應鏈的本質，也是供應鏈的核心，在完成上述三流后，就需要通過完整的供應鏈來監控整個貨物的運轉，并在完成對客戶的交付后內部完成“對賬”，形成四流合一的閉環。
綜上我們通過了業務角度的形象化、產品角度的抽象化來分別解讀了廣義的供應鏈應該是什么模樣的，那具體到產品方案上，應該怎么樣做才能具體落地呢？下文會繼續進行產品方案的分總模式拆解。
二、供應鏈后臺
供應鏈的底層建設決定了其后期的可拓展性、靈活性。最常采用的是業務劃分的模式進行建設例如訂單履約中心、中央庫存、倉儲系統等，然后再進行抽象提供相關的中臺服務。
好處是業務方對接中臺很輕松，不用理會后臺的復雜邏輯；壞處是，后臺邏輯復雜，各個底層業務的耦合較深，越到后期越有牽一發動全身的趨勢，真的是“有苦自己咽”?；谶@些問題考慮，我更推薦的通過領域模型，進行DDD的實踐落地（有興趣的可以單獨查詢，在這里就不深入了）。
領域驅動設計是一門技術語言，對產品來說的好處就在于是以每個功能為切入點，不深度耦合，每次的迭代都遵循：
按照此思路，根據實際業務場景，可以大概劃分為如下的領域：
說明：簡單的領域模型，實際可能有差異
1）核心數據
商品中心實現對全公司貨物的統一管理，負責基礎商品數據維護；碼中心實現一物一碼、一物多碼、管理盒提箱碼的關系、滿足營銷策略；最后通過中央庫存管理，實現對全公司所有貨物的統一調度、分發，實時掌握庫存情況，指導其他業務開展工作。
2）核心功能
貨物需要流動，通過訂單中心收集全公司的訂單需求進行相關的訂單策略配置，例如是否需要拆單、是否為預售、如何生成發貨單等，是唯一的訂單收口單位，與業務緊密關系的；發貨中心承接單純的供應鏈發貨任務，沒有業務規則的困擾，快速行使供應鏈發貨的本質職能；退換貨中心則主要承擔售后功能，串連倉庫、供應鏈、前段業務訂單的退款；最后的物流中心，就是供應鏈的神經，傳遞著最上層的指令，并且實時監控每一宗貨物的交付。
3）輔助功能
在全國自建多倉布局下，CDC-RDC-FDC之間的貨物調撥分配顯得尤為重要，為了更好的提供實時數據給中央庫存做決策，調撥中心是必須搭建的，形成科學、實時的調撥策略，統籌全國調撥計劃；調撥過程落地后我們稱之為配送過程，不同于2C的配送有完整運營商承接，受制于全部不同地區的經濟發展程度，調撥配送可能需要自建或者購買TMS模塊來實現對調撥貨物的實時掌握，以便于成本控制。
上述底層域劃分清楚后，各自都能獨立運作，并提供相應的橫向支持，整個地基顯得更加牢固，如下圖所示：
三、供應鏈中臺
底層域的交互在盡可能簡單的場景下，對于上游業務來說也顯得很復雜，理解成本是偏高的，此時就應該結合實際業務開展供應鏈中臺建設，進行相應的任務編排。
從產品角度來理解，中臺的任務編排其實就是內部任務編排與外部任務編排。
內部任務編排：對一些常用的任務進行規劃編排，盡可能簡單的讓業務使用，例如庫存查詢服務，業務方可以輸入A商品，系統根據權限配置返回中央庫存、分倉庫庫存、可售數、可配數等，兼容多場景。
外部編排：提供多種服務給到業務方，其自行進行編排以達到某種目的，例如先利用商品查詢服務獲取到商品編碼，再用商品編碼進行商品庫存查詢。
按照這個思路，我們傾向于在中臺提供商品應用服務、庫存查詢服務、訂單API服務、物流查詢服務、碼應用服務、數倉服務，將供應鏈后臺的復雜結構服務化，通過不斷的服務補充來完成供應鏈中臺建設
- 商品應用服務：提供商品增刪改查服務，維護商品全局統一性
- 庫存查詢服務：提供中央庫存、分倉庫存、可售數、可配數等物料數據的單個或批量實時查詢，支持前端實時售賣
- 訂單API服務：中臺最核心的功能，接收全公司所有訂單的標準化輸入，保證后續供應鏈流程正常流轉
- 碼應用服務：通過自身編碼規則生產符合我司實際業務的編碼并輸出到生產系統中對商品進行賦碼，并提供基于商品與碼的關聯查詢服務
- 數倉服務：供應鏈唯一的大數據出口，能夠進行簡單的數據加工，給大數據部門提供可靠穩定的數據接口服務，實現供應鏈數據可視化
- 物流查詢服務：圍繞著賦能前端2C業務開展的，可以結構化多承運商的路由結構，輸出符合我司的標準快遞路由，減少閱讀與統計成本
綜上可以看出，供應鏈中臺建設主要是圍繞著“多快好省”的方式進行的，并不會暴露太多供應鏈底層邏輯，減少了溝通節點與成本。
四、供應鏈前臺
供應鏈中臺不僅會支持兄弟部門的業務，圍繞供應鏈業務會拓展出很多產品應用，如下圖所示：
廣義的供應鏈前臺涵蓋了從招采到最后的數據駕駛艙的全部前臺功能。
- 招采中心、生產/采購計劃管理：主要聚焦的是招投標、工廠生產、成品采購等，與商品基礎數據緊密相關，其中還會涉及到樣品打樣、供應商評分、開標等，一旦中標則進行合同管理模塊
- 合同管理：合同的價值、數量，交付節點與數量，直接關系著調撥計劃、入庫上架時間、前端售賣節點等；而交付完成，根據產品質量則涉及到合同結算，以及合同款項的撥付，特別是采購種類繁多、SKU量級大的場景下，一個完整的供應鏈合同臺賬管理是必須的
- 收付款管理、對賬管理、資金計劃管理：是供應鏈預決算的體現，通過對采購相關合同付款、物流費用付款、倉儲費用付款；以及銷售資金的收款；自動匹配年度資金計劃，進行全局的收支呈現
- 發票管理：主要在分為采購合同的進項發票管理，與售出貨物的開票（銷項發票）管理
- 數據駕駛艙：針對倉庫庫存實時分布、訂單數據統計、物料運輸數據統計的大屏展示，便于直觀的了解供應鏈的整體運轉情況
- 供應鏈工作臺：供應鏈管理人員日程處理相關實物的工作臺，例如工單咨詢與處理、異常訂單或異常物流的監控與處理、個人效率統計等
上述功能都是依托于供應鏈中臺服務實現，并不直接干涉供應鏈后臺底層業務流轉，可以根據財務審計要求、供應鏈業務訴求隨時靈活調整。
五、業務前臺
不同于供應鏈前臺，業務前臺其實與供應鏈是沒有直接關系了，而是通過其自營業務、或者在第三方電商平臺的業務進行數據收集后，通過供應鏈中臺的相關服務與供應鏈發生交互，主要是通過“不可見”的接口進行的，這里就不詳細表述了。
六、外部對接
除了上述的前中后臺，在供應鏈業務中還有一個很重要的方向就是外部對接，前中臺業務絕大部分都局限于公司內部的數據交互與治理，但是遠遠滿足不了供應鏈的交付需求，例如業務前端有一個貨物需要指定某快遞承接，此時就需要引入外部的例如快遞承運商等第三方平臺來協助共建供應鏈。
如上圖所示，WMS是整個外部最核心的對接方，貨物在倉庫里面的所有驗收上架、分揀運作均需要通過其完成，且軟硬件結合明顯，專業度極高，一般采用全套才買或者租賃倉庫對接公司供應鏈系統的方式進行。
快遞承運商一般是與WMS進行對接，由甲方（公司）下達派送命令到WMS再傳遞到對應的快遞承運商執行的，但是涉及到大客戶協議、快遞費用對賬、更高精度的攔截、改派、疫情防控等，還是需要甲方與快遞承運商直連，實現精準的1V1。
OMS/ERP主要為可能會存在對接獨立于本供應鏈之外的系統例如第三方電商等。
財務審計則是最后的數據標注輸出，供應鏈的繁瑣流程決定了其對賬成本的巨大的，如何與公司的財務系統實現業財一體化，是一直探索的目標。
對于需要自行生產實物的公司，還需要能夠具備與工廠流水線的機器對應的系統對接的能力，例如二維碼的噴涂等。
七、完整架構與MVP
根據上面的分模塊介紹后，我們可以很清晰將各個模塊拼接起來，形成如下圖所示的廣義供應鏈的完整架構
上述架構是我們“烏托邦”式的暢想，實際落地中，往往會有阻力或者難度，并不是說不讓做而是根據公司的實際情況，可能放在其他模塊更加合適。
- Case1：收付款管理中針對銷售收入一般放在交易模塊，并不會由供應鏈來承接
- Case2：發票管理也只有在財務側使用的情況下才會收集到跟采購合同相關的發票，銷售側發票不會同步到供應鏈環節
- Case3：第三方電商的訂單明文數據，現在受制于相關法律要求，基本無法采集
- Case4：TMS的建設涉及到實體貨車的購買與維護，成本巨大，一般企業難以負擔，更多的是脫離監控的調撥或指定有第三方運輸公司外包
類似與上述場景的問題還有很多，我們就不再展開了，那在面對如此多的問題困擾下，如何快速的建設一個能跑起來的供應鏈呢？我們需要的是一個可落地MVP路徑，如下圖所示：
在此MVP加持下，基本可以滿足業務訴求，保證業務先行。但是作為一個產品經理的執念，大家不要忘記了心中的“烏托邦”！
本文由 @寒松 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
你好，文章很有啟發作用，是否有相關書籍推薦，幫助更深入了理解前中后臺