淺聊一下廣義供應鏈的前中後臺

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

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

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

一、供應鏈

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

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