運輸管理系統(tǒng)(TMS)——運單系統(tǒng)
在上一篇文章中主要分享了TMS系統(tǒng)中從下單到攬件的訂單系統(tǒng),本篇文章來分享運單系統(tǒng)。
運單是指司機完成攬件報單之后到運單被簽收的過程,如果公司業(yè)務是一體的,那么運單系統(tǒng)和訂單系統(tǒng)也可以合二為一。
當司機完成攬件報單之后,運單就開始進入物流/快遞公司的內(nèi)部運作流程中。目前,行業(yè)中最主要/核心的運作場景可以粗略劃分為:倉儲、干線、末端派送三個部分。
但坦誠來說,現(xiàn)在大多數(shù)的TMS系統(tǒng)主要承載了線下數(shù)據(jù)的記錄、登記,很少能達到“智慧物流”的效果。目前運輸管理系統(tǒng)的核心趨勢,是將運作中的流程逐漸智能化,比如說大數(shù)據(jù)預測等。
無論公司怎么去實現(xiàn)“智能物流”都需要有物流基礎數(shù)據(jù)的承載,而運單系統(tǒng)正是承載了一個運單運作流轉(zhuǎn)中全流程各項基礎數(shù)據(jù)的系統(tǒng)。
運單字段
運單信息
- 運單號:運單號是貫穿整個運輸管理系統(tǒng)的唯一標識,同時也是承運合同的合同編碼,剛開始的運單號為11位數(shù),但因快遞行業(yè)的高速發(fā)展,部分公司的運單號已經(jīng)調(diào)整為14位數(shù)或者更多。細心的同學可以觀察到運單聯(lián)的背面都是密密麻麻的字,上面就是本次寄送快遞的合同。不過運單號是帶有強業(yè)務屬性的編碼,所以技術上一般會存儲運單ID做為系統(tǒng)層級的標識;
- 尺寸:貨物的長、寬、高;
- 重量:貨物的重量;
- 件數(shù):貨物的件數(shù)。在這里分別描述了尺寸、重量、件數(shù)這三個字段,如果一個運單只有一個貨物的時候比較容易理解,但在零擔場景會出現(xiàn)了一個運單對應多個貨物,此時就會出現(xiàn)多組尺寸、重量、件數(shù)。所以大家在產(chǎn)品設計時候可以將該業(yè)務場景涵蓋在內(nèi)。
客戶信息
- 寄件信息:寄件人姓名、電話、地址是寄送快遞的數(shù)據(jù),其中地址可以借助分單服務幫助用戶完成地址的錄入,提升地址規(guī)范化水平,同時也減少因為地址解析錯誤而增加的運送成本。據(jù)稱順豐可以將地址解析到18級,但解析準確率與落地情況暫時未知;
- 收件信息:收件人姓名、電話、地址是派送快遞的數(shù)據(jù),這里不進行贅述。
路由信息
- 攬件時間:這里的報單時間是指司機在客戶處攬件完畢并進行報單的時間;
- 交接時間:因不同公司的運作方式不一樣,可能針對業(yè)務流程進行劃分并獨立命名。但因為這里的差異都是基于公司業(yè)務需要也進行設定的,但我們在這里統(tǒng)稱為交接時間。在記錄該項數(shù)據(jù)時,記錄過程數(shù)據(jù)和結果數(shù)據(jù)。如果只記錄結果數(shù)據(jù)丟棄過程數(shù)據(jù),那么后續(xù)進行數(shù)據(jù)分析時將缺失該部分數(shù)據(jù)。所以大家需要根據(jù)業(yè)務需求制定數(shù)據(jù)存儲的策略;
- 簽收時間:運單派送完畢后,收件客戶簽收運單的時間。在簽收時間這個字段上,因存在拆單派送等多次簽收的場景。所以大家也需要考慮數(shù)據(jù)存儲的邏輯。
財務信息
- 運單基礎運費:客戶寄送運單的基礎運費,主要基于重量、尺寸進行計算;
- 運單增值費用:在基礎運費之外,向客戶提供增值費用跟客戶收取的代收貨款費用、回單費用、木架費用、包裝費用等。
派送信息
派送信息指在末端派送環(huán)節(jié)派送運單的司機信息。司機信息可根據(jù)業(yè)務需求確定展示的規(guī)則,如果有客服或銷售人員對接的,那么不需要展示司機信息,提供客服電話即可;但公司本身屬于平臺,又不希望泄露公司信息的可提供虛擬號的方式聯(lián)系司機。
運單流程
正向流程
運單從報單到配送的過程。這里主要從3PL物流公司通用的功能,部分功能根據(jù)實際場景需要略有調(diào)整。
比如在同城業(yè)務中就沒有規(guī)劃中轉(zhuǎn)、干線運輸,可能點對點直接派送;在落地配業(yè)務中,就只有末端派送環(huán)節(jié)。取貨環(huán)節(jié)由商家準備了好貨物,騎手只需要根據(jù)訂單上的地址進行配送即可。
在全國性物流公司中,一個運單從報單到簽收涉及的環(huán)節(jié)比上圖的節(jié)點還要更多。
- 關于報價問題:在C端場景下一般都是提供通用報價,所以提供采用報價模板即可;但在B端客戶時,針對不同的客戶會有不同的報價,可以根據(jù)自身需要建立對應的模塊或者報價系統(tǒng),一般情況下會將報價信息放在CRM系統(tǒng)或財務系統(tǒng)中,此處問題后續(xù)另文展開;
- 物流/快遞行業(yè)為了提高支線/干線的裝載率會將一個大件貨物拆分成兩個“包”進行運輸,然后到達目的地城市/中轉(zhuǎn)場之后再次進行合單,同時在末端派送時也會對同一區(qū)域的貨物進行合單派送。除了國內(nèi)業(yè)務運作中出現(xiàn)的合單,在跨境物流中,承運商也會將零散運單(包裹)打包成一個大單給到第三方,通過對這個大包進行報關、清關能有效降低成本和提效。合單和拆單邏輯后續(xù)另文展開,而跨境物流屬于一個大的命題,跨境物流后續(xù)會做為一個系列進行分享;
- 針對任何一家零擔/快遞等有車承運商、非平臺業(yè)務的公司,公司的運輸路由屬于公司底層、核心命脈。在順豐、德邦支線到干線的線路策略為不考慮裝載率的班次;也有一些公司根據(jù)實時貨量去決定線路發(fā)車時間的策略,這種方式下需要增加一定的人力成本進行調(diào)度。這個問題的抉擇更多是時效優(yōu)先抑或是成本優(yōu)先,沒有絕對的好壞之分;
- 在取、派調(diào)度環(huán)節(jié)中,一般自營物流會采取人工/自動調(diào)度的方式,而在眾包物流或者城配物流中會采取區(qū)域派單,人工搶單的方式。派單和搶單有各自的優(yōu)劣勢,后續(xù)另文展開;
- 在自營物流中會存在場地管理或倉儲管理的需求,這里主要關注場地貨物吞吐量、吞吐速度、裝卸貨耗時等;
- 自營物流也同時存在車輛管理的需求,主要關注靜態(tài)的車輛保養(yǎng)狀態(tài),動態(tài)的車輛關注車輛是否超速、疲勞駕駛等;
- 路徑規(guī)劃一般與司機調(diào)度結合在一起,但因為中間涉及到成本、運力、時效等多方面的影響,目前行業(yè)中比較成熟的方案當屬阿里的方舟系統(tǒng),這里牽扯到著名的“旅行商問題”,后續(xù)另文展開分享我粗淺的理解。
運單數(shù)據(jù)交互
本次文章分享承載全流程運單數(shù)據(jù)的運單系統(tǒng),所以這里會涉及到多個運單狀態(tài)的變更,以及當運單數(shù)據(jù)達到某個條件的閾值時,是否要通知到某個具體的用戶。
比如說調(diào)度了司機之后是否要進行通知,同時通知了司機之后,司機過了兩個小時還沒有達到客戶處;再比如說一個運單在場地滯留了三天仍舊沒有動靜等諸如此類的場景。
在運單數(shù)據(jù)狀態(tài)的變更有很多有意思的需求可以挖掘,如果你有興趣歡迎與我交流。
#相關閱讀#
作者:微摳;公眾號:VicoPM
本文由 @微摳 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議
對于我做運單管理很有用 期望出更多的內(nèi)容
在攬收打單的的時候就要查路由規(guī)劃模塊了不然物流三段碼如何展示
你好,可以再多寫些文章吧,很實用
KYE物流報道