在上一篇文章中主要分享了TMS系統中從下單到攬件的訂單系統，本篇文章來分享運單系統。

運單是指司機完成攬件報單之後到運單被簽收的過程，如果公司業務是一體的，那麼運單系統和訂單系統也可以合二為一。

當司機完成攬件報單之後，運單就開始進入物流/快遞公司的内部運作流程中。目前，行業中最主要/核心的運作場景可以粗略劃分為：倉儲、幹線、末端派送三個部分。

但坦誠來說，現在大多數的TMS系統主要承載了線下數據的記錄、登記，很少能達到“智慧物流”的效果。目前運輸管理系統的核心趨勢，是将運作中的流程逐漸智能化，比如說大數據預測等。

無論公司怎麼去實現“智能物流”都需要有物流基礎數據的承載，而運單系統正是承載了一個運單運作流轉中全流程各項基礎數據的系統。

運單信息

• 運單号：運單号是貫穿整個運輸管理系統的唯一标識，同時也是承運合同的合同編碼，剛開始的運單号為11位數，但因快遞行業的高速發展，部分公司的運單号已經調整為14位數或者更多。細心的同學可以觀察到運單聯的背面都是密密麻麻的字，上面就是本次寄送快遞的合同。不過運單号是帶有強業務屬性的編碼，所以技術上一般會存儲運單ID做為系統層級的标識；
• 尺寸：貨物的長、寬、高；
• 重量：貨物的重量；
• 件數：貨物的件數。在這裡分别描述了尺寸、重量、件數這三個字段，如果一個運單隻有一個貨物的時候比較容易理解，但在零擔場景會出現了一個運單對應多個貨物，此時就會出現多組尺寸、重量、件數。所以大家在産品設計時候可以将該業務場景涵蓋在内。

客戶信息

• 寄件信息：寄件人姓名、電話、地址是寄送快遞的數據，其中地址可以借助分單服務幫助用戶完成地址的錄入，提升地址規範化水平，同時也減少因為地址解析錯誤而增加的運送成本。據稱順豐可以将地址解析到18級，但解析準确率與落地情況暫時未知；
• 收件信息：收件人姓名、電話、地址是派送快遞的數據，這裡不進行贅述。

路由信息

• 攬件時間：這裡的報單時間是指司機在客戶處攬件完畢并進行報單的時間；
• 交接時間：因不同公司的運作方式不一樣，可能針對業務流程進行劃分并獨立命名。但因為這裡的差異都是基于公司業務需要也進行設定的，但我們在這裡統稱為交接時間。在記錄該項數據時，記錄過程數據和結果數據。如果隻記錄結果數據丢棄過程數據，那麼後續進行數據分析時将缺失該部分數據。所以大家需要根據業務需求制定數據存儲的策略；
• 簽收時間：運單派送完畢後，收件客戶簽收運單的時間。在簽收時間這個字段上，因存在拆單派送等多次簽收的場景。所以大家也需要考慮數據存儲的邏輯。

财務信息

• 運單基礎運費：客戶寄送運單的基礎運費，主要基于重量、尺寸進行計算；
• 運單增值費用：在基礎運費之外，向客戶提供增值費用跟客戶收取的代收貨款費用、回單費用、木架費用、包裝費用等。

派送信息

派送信息指在末端派送環節派送運單的司機信息。司機信息可根據業務需求确定展示的規則，如果有客服或銷售人員對接的，那麼不需要展示司機信息，提供客服電話即可；但公司本身屬于平台，又不希望洩露公司信息的可提供虛拟号的方式聯系司機。

正向流程

運單從報單到配送的過程。這裡主要從3PL物流公司通用的功能，部分功能根據實際場景需要略有調整。

比如在同城業務中就沒有規劃中轉、幹線運輸，可能點對點直接派送；在落地配業務中，就隻有末端派送環節。取貨環節由商家準備了好貨物，騎手隻需要根據訂單上的地址進行配送即可。

在全國性物流公司中，一個運單從報單到簽收涉及的環節比上圖的節點還要更多。

• 關于報價問題：在C端場景下一般都是提供通用報價，所以提供采用報價模闆即可；但在B端客戶時，針對不同的客戶會有不同的報價，可以根據自身需要建立對應的模塊或者報價系統，一般情況下會将報價信息放在CRM系統或财務系統中，此處問題後續另文展開；
• 物流/快遞行業為了提高支線/幹線的裝載率會将一個大件貨物拆分成兩個“包”進行運輸，然後到達目的地城市/中轉場之後再次進行合單，同時在末端派送時也會對同一區域的貨物進行合單派送。除了國内業務運作中出現的合單，在跨境物流中，承運商也會将零散運單(包裹)打包成一個大單給到第三方，通過對這個大包進行報關、清關能有效降低成本和提效。合單和拆單邏輯後續另文展開，而跨境物流屬于一個大的命題，跨境物流後續會做為一個系列進行分享；
• 針對任何一家零擔/快遞等有車承運商、非平台業務的公司，公司的運輸路由屬于公司底層、核心命脈。在順豐、德邦支線到幹線的線路策略為不考慮裝載率的班次；也有一些公司根據實時貨量去決定線路發車時間的策略，這種方式下需要增加一定的人力成本進行調度。這個問題的抉擇更多是時效優先抑或是成本優先，沒有絕對的好壞之分；
• 在取、派調度環節中，一般自營物流會采取人工/自動調度的方式，而在衆包物流或者城配物流中會采取區域派單，人工搶單的方式。派單和搶單有各自的優劣勢，後續另文展開；
• 在自營物流中會存在場地管理或倉儲管理的需求，這裡主要關注場地貨物吞吐量、吞吐速度、裝卸貨耗時等；
• 自營物流也同時存在車輛管理的需求，主要關注靜态的車輛保養狀态，動态的車輛關注車輛是否超速、疲勞駕駛等；
• 路徑規劃一般與司機調度結合在一起，但因為中間涉及到成本、運力、時效等多方面的影響，目前行業中比較成熟的方案當屬阿裡的方舟系統，這裡牽扯到著名的“旅行商問題”，後續另文展開分享我粗淺的理解。

運單數據交互

本次文章分享承載全流程運單數據的運單系統，所以這裡會涉及到多個運單狀态的變更，以及當運單數據達到某個條件的阈值時，是否要通知到某個具體的用戶。

比如說調度了司機之後是否要進行通知，同時通知了司機之後，司機過了兩個小時還沒有達到客戶處；再比如說一個運單在場地滞留了三天仍舊沒有動靜等諸如此類的場景。

在運單數據狀态的變更有很多有意思的需求可以挖掘，如果你有興趣歡迎與我交流。

#相關閱讀#

運輸管理系統（TMS）——訂單系統

作者：微摳；公衆号：VicoPM

本文由 @微摳 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議

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