編輯導語：隨著互聯網科技的發展，分銷成為品牌進行網絡營銷的一大用戶來源。那么，如何構建一個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協議。