我們(men) 先回顧一下木子在上一篇文章中對於(yu) 整車物流大數據的觀點：

--大數據天然存在，不是新創造出來。不管你做什麽(me) 或者你不做什麽(me) ，它一直都在，等你來發現。

--整車物流大數據目前的病因就是“欠整”。基於(yu) 數據的隱私性和安全性，操刀之人，這個(ge) 角色隻有主機廠可以扮演。

--基於(yu) 對客戶可感知需求的理解對於(yu) 大數據在物流營運中的應用可完全夠用。

--整合是前提，整合是手段不是目的。目的在於(yu) 精準定位客戶需求和新的商業(ye) 遐想。

1.目前的業(ye) 務模型

整車業(ye) 務對於(yu) 主機廠來講一般是按照車型劃分生產(chan) 基地，然後通過進出口貿易銷售全球。如圖一所示，歐洲兩(liang) 家工廠生產(chan) 的車輛通過進口貿易到中國，然後通過國內(nei) 的4個(ge) 整車分銷中心（VehicleDistributionCentre）發運到全國經銷商。國內(nei) 的兩(liang) 家工廠的產(chan) 品也經由4個(ge) VDC為(wei) 全國近200家經銷商提供產(chan) 品供應。同時國產(chan) 車也經由上海港出口北美市場，順便說一句，木子服務的品牌是第一家從(cong) 發展中國家向發達國家出口豪華車的企業(ye) 。我要說：”我驕傲！“

除了上麵的提到數據，這條供應鏈承載的數據還包括，每年近10萬(wan) 台車的批售，零售。這些商品車的移動包涵，公路，鐵路，水路三種運輸方式；有數以百計的人員在工作，有數以千計的運輸車輛在承載，這些車輛關(guan) 聯數以10萬(wan) 計的最終用戶。同時更重要的是有數以十億(yi) 的資金和借貸在支撐著這條鏈滾滾向前。

2.目前的相關(guan) 數據分布

當我們(men) 把目前用到的所有數據，數據來源，數據取得的方式以及數據流向匯總到一起後，我們(men) 麵前有這樣一幅圖畫，如圖二所示。整個(ge) 圖畫可以分為(wei) 6部分。

A區的數據單向從(cong) 物流的外部流入，包括一些基本信息，有客戶的，車型的，物流服務合同的等等，還有一些計劃信息化，包括銷售計劃的，以及生產(chan) 計劃的和車輛生產(chan) 下線信息。

B區的信息不同於(yu) A區，是雙向流動的。信息從(cong) 其他部門傳(chuan) 遞到物流部門後，同時需要物流給予反饋。大多是和訂單以及訂單執行相關(guan) 的信息，例如進口車裝船信息，各種訂單內(nei) 容，訂單的財務信息。而物流部反饋的是訂單執行的狀況。

C區的信息是發生在主機廠和第三方物流服務商之間，內(nei) 容多是物流操作相關(guan) ，而且是一個(ge) 雙向的信息交互。

D區顯示的是A,B,C三部分信息喂入物流模塊後，在物流內(nei) 部各功能之間加工，流轉的過程。加工後輸出到D,C,E（報告）,F（客戶服務與(yu) 反饋）模塊。

數據來源於(yu) 四個(ge) IT係統的手工下載，工廠係統，銷售係統，財務係統，上遊的TMS，其他為(wei) 手工信息。數據傳(chuan) 到物流模塊後，再次被手工處理，數據源和再處理的數據被分散存放於(yu) 20多個(ge) Excel文件中。

3.如果安於(yu) 現狀，那是一幅怎樣的數據”畫麵“？

盲人摸象，沒有完整畫麵。從(cong) 整個(ge) 整車物流管理的角度看，沒有一個(ge) 係統能掌握一台商品車輛的完整的數據檔案。如果想拚接這份完整的圖畫，必須翻閱20幾個(ge) Excel文件。然後手工關(guan) 聯數據。

畫麵“分辨率”不夠高。由於(yu) 數據量的關(guan) 係，隻能記錄少量關(guan) 鍵節點，比如運輸在途的監控，隻有出庫，到店，在途三個(ge) 狀態，而不是一個(ge) 全過程的監控。這樣就會(hui) 可能失去采取Pro-action來改善客戶滿意度的機會(hui) ，具體(ti) 論述參看木子的節奏物流（ID:Rhythm_Logistics）1月29日推送的文章--《節奏物流之物流狀態追蹤》。

畫麵“失真”是大概率事件。由於(yu) 數據量巨大而且數據存儲(chu) 的安全性很低，同時Excel沒有權限管理，會(hui) 造成數據丟(diu) 失；對於(yu) 每年銷量在10萬(wan) 級的企業(ye) ，如果要分析過往幾年的數據，手工數據處理很難支持。

畫麵傳(chuan) 輸大多是“老電影”。由於(yu) 數據來源紛雜和人工處理手段落後的原因，報告缺乏實效性。人工數據處理完了，很可能已經是過時的了，很難為(wei) 決(jue) 策提供實時數據支持。如果想從(cong) 多角度分析，效率就更低了。

畫麵的“觀眾(zhong) ”有限。由於(yu) 上述的數據采集以及分析的原因，目前大多隻能用於(yu) 物流部內(nei) 部，很難開放給整車物流的內(nei) 外用戶。木子服務的品牌現有外部客戶近200家，再考慮到公司內(nei) 部的客戶，從(cong) 功能上分就不下10家。物流部隻能提供簡單信息服務。

4.數據整合僅(jin) 是前提和第一步。

看了上述情況，找個(ge) 專(zhuan) 家望聞問切，抄起筆來，刷刷點點開個(ge) 方子--整合數據，實現數據實時電子交互，數據儲(chu) 存上傳(chuan) 雲(yun) 端，利用SQL或者”OO“進行數據處理。還有更多我們(men) 幹物流的聽不懂技術和名詞。但是木子能看懂的就是先整合數據。

說幹就幹，就有了如圖三的數據整合的變化。這個(ge) 整合著重於(yu) 物流的內(nei) 部，即把原來的導入的所有信息儲(chu) 存在雲(yun) 端的數據庫，在雲(yun) 端根據目前的數據需求，用基於(yu) SQL技術的數據處理。這步動作帶來了如圖四所示的變化，木子在此不在贅述。

5.二期開發的規劃

大家能看到在圖三中還有很多表示數據交互的空心箭頭，它們(men) 表示數據在不同係統/數據表格之間傳(chuan) 遞。目前這些數據的傳(chuan) 遞還是以人工上載的方式到雲(yun) 端，未來如果實現EDI，那麽(me) 對於(yu) 改善數據實效，準確以及數據格式的統一是非常有幫助的。

細化用戶權限管理，為(wei) 更多內(nei) 外部客戶以及整車物流供應鏈上的各方提供更多Tailor–made的信息服務。

通過經銷商付款的信息以及在途信息的大數據分析，找到弱勢發運線路的原因，從(cong) 而指導物流服務商找到改善服務的原因。

通過RFID追蹤改善對於(yu) 庫存維護保養(yang) 的遠程監控。

這裏隻是羅列了一些目前看到的可能性，當整合後的數據完整的展現在您麵前的時候，基於(yu) 對客戶可感知需求的理解，您可能發現更多的驚喜。所有這些都來源於(yu) 您邁出的第一步—數據整合，主動打開上帝遮在您眼前的簾。借那首膾炙人口的歌詞作為(wei) 本文的結尾。

如果我能看得見

就能輕易的分辨白天黑夜

就能準確的在人群中牽住你的手

就能驚喜的從(cong) 背後給你一個(ge) 擁抱

讓我看見這世界就在我眼前