编辑导语：随着互联网科技的发展，分销成为品牌进行网络营销的一大用户来源。那么，如何构建一个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协议。