乳制品行業DRP產品的構建與實戰
編輯導語:隨著互聯網科技的發展,分銷成為品牌進行網絡營銷的一大用戶來源。那么,如何構建一個DRP產品系統,達到分銷管理效率化?作者以乳制品行業DRP項目為例,介紹如何進行DRP產品系統的構建,分享給你。
今天給大家分享一下最近做的乳制品DRP項目,何謂DRP呢,全名為:“Distribution Resource Planning”,分銷管理中心。
我們先來講分銷的廣義。分銷即為經銷商到終端網點的連接鏈條。產品使用主體為經銷商,下單主體為終端網點,但真正的數據獲取受益人則為品牌方。
分銷系統的最大好處就在于品牌方可以知曉經銷商的訂單、渠道、庫存等動態的業務數據,那我們從正常的業務角度去思考,品牌方拿到這些數據可以做什么呢?
- 訂單:通過BI數據分析中心,針對于經銷商訂單的分析,減少品牌方的生產成本。同時經銷商在進行報單時,品牌方的經管部也可以對經銷商客戶有著更好的分貨判斷。
- 庫存:品牌方在了解到相對精準的渠道庫存后,可以進行全新的庫存模式管控,如果DRP系統可以成功推廣,那么品牌方就可以采用VMI模式進行庫存管理,初步達到一盤貨的效果。
- 渠道:經銷商自有渠道進行售賣同類型產品時,品牌方可獲取經銷商渠道信息,同時判斷該渠道下的終端網點是否售賣了品牌方本品,未售賣情況,品牌方自己的業務員工即可去拓展渠道,實現網點的橫向拓展。
整體在對經銷商上線DRP產品后,除了讓經銷商的日常工作更加便捷之外,更多的是要對品牌方有著業務上的增長或好處。
DRP產品是否可以單獨存在呢,其實對于經銷商來說,后臺的數據獲取是無感知的,那么整套產品對經銷商來說也有著好處,比如訂單回溯、分貨整理、減少人工成本、簡單的賬務管理、簡單的庫存管理等等。
所以,DRP產品完全可以做成標品來單獨售賣。那么對于項目主體為品牌方的時候,DRP就必須要與其他產品模塊進行交互,比如上游的DMS ,下游的SFA、本部的BI等等,只有讓DRP的產品數據流動起來,才可以滿足品牌方的正常需求。
從F-B-b-c的全鏈路數據是每一個品牌方無法拒絕的誘惑,那么實際上DRP產品就承擔了最重要的三個環節,B-b-c,當然b-c的鏈路數據,DRP是很難獲取到的,那么構建于DRP上的云店起到了很大的幫助,云店后續我們再來介紹,現在還是回到我們的DRP產品當中。
上面講了DRP產品存在的意義以及品牌方對于DRP的真實訴求(數據),那么整體對DRP的構建,就要從主要用戶(經銷商)進行需求分析及了解,在了解需求之前,我們要做的就是整套產品的底層架構,到底要怎么去做。
經銷商用戶量較大,不同經銷商要求數據隔離,那么首先,DRP產品的用戶天生就有一個上級,也可以叫做一級租戶,經銷商們本身是二級租戶,不同租戶之間要進行數據隔離,這就是DRP產品最少要做到的事情,那么我們在構建的過程中,還要考慮到并發量、代碼保護以及底層架構的穩定,這一塊兒肯定是開發的同事要更加的熟悉些,我在這個項目上定的是3000并發量,引用jar包方式進行代碼保護,底層架構使用DDD模式進行搭建。
我們把產品地基搭建好了以后,就要對產品本身功能及需求進行搭建和設計,那么我們可以大概整理一個腦圖,對于經銷商目前在業務過程中無法或缺的業務要點進行梳理:
在為期兩周的調研結束后,我與我的團隊整理出了經銷商的整體業務要點,那么我就要來判斷,他們的這些要點存在了哪些現在沒有信息產品輔助的,線下操作的要點,這些要點包含了哪一些功能等等。
那么梳理結束后,其實整體DRP產品覆蓋到的大模塊就是車銷、庫存、主數據、訂單、促銷模塊,分為三個端,配送員端、終端網點端、web端,分別針對不同的人員進行使用,三端連接為DRP系統。
整體的產品框架呢,就如圖:
我們在設計本身呢,要考慮到現實因素,如在城市主城部分無法進行車銷,只可以進行配送(道路無法停車)、乳制品產品效期短,經銷商對終端網點的退換貨情況、品牌方向經銷商壓貨,經銷商簽收情況、臨過期產品的產品虛擬庫位單獨存放、車銷出車過程中兩種類型的產品(臨過期產品、正常產品)、乳制品竄貨嚴重等業務實際場景,根據實際業務場景去設計產品功能,才能夠使產品試用者更加適用。
上文我們講了DRP產品的好處與用處,那實際上DRP產品有什么壞處呢,其實品牌方通知經銷商使用產品,經銷商本身是抗拒的,因為對于經銷商而言,很多經銷商可以猜到品牌方是想要數據的,那么這種抗拒心理對經銷商的推廣就非常困難。更何況經銷商在經營同類型產品的時候呢。
對于DRP產品的介紹和構建到這里就結束了,希望大家可以在做同類型項目的時候,不要再踩坑了,下篇文章會給大家帶來網點數字化SFA的項目分享、構建和實戰。下次見啦~
本文由 @禮讓 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
樓主怎么不繼續更新了