編輯導語：無論是傳統企業還是電商，供應鍊都是一個非常重要的環節，同時供應鍊也是一個極其複雜的系統，包含了從生産制造到流通過程中的所有環節。本文作者對廣義的供應鍊進行了分析，一起來看一下吧。

無論是傳統企業還是電商，供應鍊都是一個重要的環節，且無法繞過。甚至一個企業的成功與否，很大程度上取決于其供應鍊建設的完整性。但是供應鍊是一個極其複雜的系統，包含了從生産制造到流通過程中的上下遊的所有環節。筆者在本文嘗試去打造一個“烏托邦”式的供應鍊，淺淺的聊一下廣義的供應鍊都包含哪些内容，希望對你有所啟發。

注：本文所述的供應鍊，是圍繞自産自營電商進行假設

一、供應鍊

本文不再從基礎定義去推導什麼是供應鍊，直接關注業務本質，來便于大家快速理解。

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 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部