决胜B端—产品经理升级之路
1、背景
M集团是一家经营了十几年的成功企业,下拥有售连超市,生鲜电商、金融理财多条业务线,务发展良好,系统建设成熟。公司是M集团下属的电商公司,成立5年,主管生鲜商品,以C端客户为主,业务稳定。
M公司在三个月前试开展分销业务,成立销售团队开发分销商合作伙伴。分销业务的目标客户是大型的餐饮进锁集团,以及大型生鲜分销商等企业级客户。
业务试点在北京、上海开展,三个月以来业鲁发展迅。目前分销业务月流水50万元,以每月20%的增幅快速发展但是,在高速发展中若干流程、管理、风隆问题越来越突出。
2、诉求
由于分销业务发展迅速,现急需配套的软件系统来提开业务效率,控制经营风险。
3、评估
经管理层评估,公司决定投入研发资源建设软件系统,支撑分销业务发展。项目期间CTO全力提供资源支持。
4、目标
在2-3个月的时间内搭建一套分销业务平台,至少支撑分销业务在未来2年内的高速发展,有效地提升效率、控制经营风险。
5、业务调研
5.1、明确调研目标
目的：1、梳理业务现状，2.总结业务问题
了解生鲜B2B业务线相对于整个M集团的战略定位，及其战略目标。
了解业务的经营策略、管理模式。
了解当前业务的线下运作方式与细节，包括组织架构、业务流程等
梳理业务问题与痛点，确定优先级
5.2、选取调研对象
一般包括：业务高管、业务经理、一线业务人员、合作伙伴高管、合作伙伴经理、合作伙伴一线人员
M公司：分销业务负责人1人、运营专员1人，北京、上海业务主管各1人、一线销售人员2~3人、北京、上海各选择一家分销客户
5.3、确认调研方法
一对一访谈
5.4、执行调研计划
5.4.1、战略定位与战略目标
扩充并尝试新销售渠道，发展高端零售的分销通路；战略目标是在3年内打入主要一二线城市高端零售分销市场，并站稳脚跟，形成初步竞争力
5.4.2、经营策略
M公司对下属部门采取了事权下放的管控模式，下属部门在遵守基本规则的前提下拥有售卖定价权、运营管理权等权利
5.4.3、组织架构
当前架构
调整后架构
5.4.4、业务流程
5.4.5、具体数据指标
5.4.6、业务问题总结
1、生鲜实时变价，每次下单要根据折扣表手工计算价格，效率低，易出错
2、不能及时控制账期客户端回款进度和账期风险
3、对账和开票工作复杂，需要处理大量数据表，容易出错
4、因为没有实现客户端子母账号管理体系，所以无法实现客户总部集采、大区集采、城市集采、门店自采等混合采购模式
5、因为无法标识特殊客户端特殊订单，因此不支持特殊分拣、配送要求，例如做不到针对某些特殊客户端订单提供蔬菜预加工和加急配送
5.4.7、解决问题思路
1、实现客户自主下单（高优）
2、实现系统自动定价（高优）
3、支持客户多门店分别定价与下单（高优）
4、实现对账报表（高优）
5、运营人员聚集参数设置、审核和异常问题跟进（高优）
6、将运营工作下放到各城市分部（中优）
7、支持账期和预付款模式（低优）
8、系统实现账期风控（低优）
5.5、总结归纳输出
总结业务现状和问题，确定各个问题的优先级
6、B端产品的整体方案设计
6.1、核心业务流程
根据对M公司的业务调研,我们总结出当前紧迫的业务诉求包括客户自主下单、自动定价,以及支持客户对多门店分别定价与下单因此我们考虑调整业务流程,由运营人员将客户信息录入系统,客户具备一个初始账号后,可以自主管理下属的多个门店和子账号。
因为M公司可能和客户总部签署了框架协议,具体合作关系又由客户的下属分公司或门店分别谈判,所以价格系数表要针对每个门店分别设置,以保证定价的灵活性。
因此当客户创建新门店后,还需要由运营人员设置一次价格系数表,之后,门店采购人员就可以通过关联的子账号进行下单了。
下单之后的环节保持之前的运作流程,不做改变。
经过和分销业务负责人沟通,因为目前销售人员数量有限,暂不需要设计给分销业务销售人员使用的CRM系统,客户线索管理、客户资质审批与合同签订审核,都可以继续保持线下运作。
因此,我们考虑将客户签约作为一个分界点,签约之前的环节依然线下运作,而为签约之后的环节设计一套全新的系统,支持后续业务流转。我们将这套系统暂且称为分销系统,将图5-1中的流程图略修改,体现出包含新系统的新业务流程图,如图5-2所示。从图中可以清晰地看出一套全新的业务系统对分销业务的支持,及其在主业务流程中的位置。
通过对核心流程的梳理,以及明确其中哪些环节需要线上化支持,分销系统的轮廓初现。
此时,我们暂时不需要深入细节,而要基于这个初现的轮廓,进一步思考分销产品的顶层设计。
6.2、产品定位
通过对M公司分销业务的核心流程梳理,我们已经对分销系统在整个系统中的位置有了初步判断,现在,我们进一步思考更精确的形态和定位。
首先在分销业务中,客户需要一个快速下单的工具,可以提供一个手机版商城C端。考虑到投入产出比,公司决定通过H5来实现,而不是AppH5所写的网站具有独立域名,外网可访问。
其次,需要为客户提供一套方便操作的管理后台,因为涉及大量的商品定价编辑、处理,账号、门店管理等功能,所以考虑PC版本实现,暂不支持手机版
最后,考虑到客户管理员和M公司管理人员的管理诉求不同,操作功能和页面差异较大,所以决定将管理后台拆解为两个独立的系统:给客户管理员使用的客户管理后台具备独立域名,外网可访问;给M公司管理人员(和运营人员)使用的运营管理后台也具备独立域名，但仅限内网访问。
经过以上分析，我们进一步将分销系统拆分为3个独立系统，每个系统的定位不同：
分销商城前台（移动端，通过H5实现）：为分销客户提供下单功能。
客户管理后台（PC端）：为分销客户提供子账号管理、门店管理及业务辅助功能
运营管理后台（PC端）为分销业务部门提供客户及商品定价管理的业务支持功能。
6.3、应用架构设计
M集团已经发展了多年,集团的软件体系结构非常成熟,这就意味着在设计一套新的系统或产品时,完全可以复用现有的部分系统或模块,从而快速实现新系统,提高系统建设效率,减少重复开发,更重要的是,保证合理的整体系统架构
对于新设计的分销平台,该如何和公司现有系统融合呢?
首先,M公司作为一家成熟的公司,之前已经有面向零售业务的C端商城,用于支持个人客户线上购物。那么针对分销业务的客户,我们是单独做一套C端商城,还是改造、复用现有的C端商城呢?经过分析评估个人客户和分销客户(属于企业客户)需要的功能差别较大,因而两套商城的整体区别较大,如果通过对原有商域进行改造来支持分销业务,需入的工时会很多,甚至可能比新开发一套系统还要多,而且还会影响主营业务系统的键壮性,此公司最终决定做一套新的C端城(分销商城前台)来支持分销业务。
其次,我们要思考的问题是如何维护、管理客户数据,是在分销平台中独立管理还是通过公司现有的客户资料管理模块管理?对于M公司来讲,现有C端客户资料全部存储在客户主数据DM(Master Data Management)系统中,我们认为无论是C端客户信息,还是分销业务的B端客户信息,都是企业的核心资产应该采用集团统一管理的方式。因此决定通过改造现有客户主数据系统,支持分销业务的客户信息存储和管理。
接着我们要思考如何管理客户账号体系。账号是用户登录系统的凭证,对于企业来讲,账号和客户是两个概念,一个客户可能有多个账号,但一个账号只会对应一个客户。比较成熟的企业都具备一套成熟的用户管理中心Passport)系统,实现统一账号管理。经过思考,我们打算将现有 Passport系统升级从单一账号体系升级为子母账号体系,支持分销渠道的企业客户账号管理。
然后我们考虑如何连接订单和仓配系统。公司已经有一套成熟的订单中心,基于订单中心可以完成正逆向交易操作及财务处理,且前已经在支持分销业务手工下单模式的作业处理。因为分销业务售卖的商品和C端业务售卖的商品来源是相同的,所以订单中心能够完美支持分销业务,因此决定分销平台不单独开发订单中心,而直接把交易发送给现有订单中心,由它作为桥连接后续生产配送环节这样就实现了分销平台和仓配系统的完美解耦。
关于分销平台的商品管理,完全可以复用C端的商品中心,只需要对价格模块做定制开发。
最后,我们考虑后端系统的权限管理,以及分销商城前台的支付问题。由于M公司现有权限管理系统(Auth)与支付平台(Pay)都是基于服务化建设思路实现的完善解决方案,国此可以作为基础服务快速支持新系统,无须重复开发。
至此,我们梳理并确定了分销平台和公司现有架构的融合关系,确定了系统的复用方案,我们将分销平台分为三个子系统,将其绘制到公司整体应用架构图中,如图5-3所示,深灰色矩形是新增的系统,浅灰色矩形是原平台中需要结合本次项目进行升级修改的系统,白色矩形是原平台中不受影响的系统。
6.4、功能模块设计
6.4.1、分销商城前台
分销商城前台即客户下单的H5工具,是一个经典的电商C端系统,分销客户需要在上面完成下单购买操作,也需要完成自我管理(例如对下属门店的管理,对发票、售后的管理),因此主要包括购买流程和个人中心两大部分。从购买流程的角度考虑,商城需要具备以下功能或模块:首页、搜索、推荐、列表页、详情页、购物车、结算页、收银台。个人中心要包括订单管理模块、账号管理模块、售后管理模块等;针对分销业务的特殊诉求,还需要包括门店维护、对账管理等模块。分销商城前台的功能模块如图5-4所示。
6.4.2、分销客户管理后台
分销客户管理后台是给分销客户管理员使用的管理后台,主要用来管理下属门店和子账号;还需要随时了解下属门店和子账号的经营情况,因而需要查询所有下属门店和子账号的数据;此外还需要进行统一的财务管理。因此分销客户管理后台一共包括下面三个大模块,其功能模块如图5-5所示。
客户管理模块,支持子账号管理与门店管理。
综合查询模块,实现所有可能的查询与信息检索诉求,包括门店报表、订单查询、综合报表、售后查询。
财务管理模块,支持基本的发票管理、对账管理,以及分销业务特有的预付款管理。
6.4.3、分销运营管理后台
分销运营管理后台是支持M公司分销业务的核心业务系统,同时也是一套典型的电商管理后台。典型的电商管理后台需要具备商品定价管理、财务管理、风控管理、运营管理、客户管理、报表管理几大模块,另外,针对案例中的分销业务,还需要具备账期管理模块,其功能块如围5-6所示。
商品定价管理模块:一般支持商品管理、价格管理。根据5.3节的分析,在M公司的分销业务中,其商品管理模块将完全复用C端业务的商品中心;其价格管理将通过价格系数设置模块和门店报价管理模块完成:商品的基本定价数据将从C端业务的价格中心获取,然后在分销平台维护价格系数表和门店报价单,从而计算针对不同客户和门的售价。
财务管理和账期管理:基于前期业务调研,我们明确分销业务要支持账期和预付款管理,所以相对应的账期回款监控、预付款管理都是必备功能
报表管理:报表管理模块将提供各类分析报表,实现对业务运作情况的监控和诊断。
风控管理、运营管理:在这两个一级模块中还可以实现定价风控、订单风控、CMS(内容管理)以及消息中心等,这里不再一一介绍。
6.5、演进蓝图设计
在对M公司的业务调研中,我们不仅列出了需求,而且明确了需求的优先级(参见4.5.2节)。根据优先级,以及前面绘制的分销平台三个系统的完整功能模块(图5-4、图5-5、图5-6),我们计划将分销平台分为三期实现,其演进蓝图如图5-7所示。
一期项目聚焦解决最基本的业务流程线上化问题及核心痛点(例如对账功能),在图5-7中用白色矩形表示。一期项目要实现哪些功能?有一个原则可以参考:凡是可以手工处理和解决的问题,都暂时不做系统支持。例如,报表管理功能可以通过定期运行SQL语句实现:价格系数设置功能的使用频率低,可以由RD在后台改数据库完成:缺少搜索、推荐功能并不会对客户下单的效率产生明显影响,因为根据调研,目前每个客户维护的SKU数量最多也不过20个。
二期项目聚焦于解决部分特殊业务刚需的诉求。对于M公司的分销业务,需要支持预付款模式、账期模式、发票管理,如果时间允许,还可以实现报表查询的若干功能。在图5-7中用浅灰色矩形表示。
三期项目聚焦风险控制,并强化运营功能,在图5-7中用深灰色矩形表示。一般来讲,很多互联网公司初期都会聚焦于业务本身,提升GMV(成交总额)验证可行性,不会太在意成本和风险控制。当业务达到一定规模时,则必须引入系统风控机制,实现事前、事中、事后的风险控制。
此外,基于本案例B2B业务的特点,我们在设计中并没有考虑太多的C端功能实际上C端功能只需要保证分销客户能够轻松下单,并做一些简单的运营、通知即可。
7、B端产品的细节方案设计
7.1业务数据建模
7.1.1、理想版分销业务客户模型
在业务数据建模工作开始之前,我们首先回顾一下客户诉在前的分客户中,有比较大型的集团客户,下设若机构、房门店调研时,集客户有如下诉求:
上海分公司采用了中央仓库模式,客户从M公司米商品后,商品首先会被配送到中央仓,再客户自己从中央仓向上海地区门发货此上海分公司需要开采购账号,以实现在中央仓系统中下单。
广州天河区也采用了中央仓模式,客户从M公司采商品后,商品首先会被配送到天河区中央仓,再由客户自己从中央仓库向天河区各门发货因此天河区需要开通采购员账号,以实现在天河中央仓系统中下单。
广州其他区是门角采模式,即门店采购自行下单采购,商品直接从M公司配送到门,此需要针对每个门店创建采购目账号。
广东省还需要一个高级别的采购目账号,能够帮广东各仓库和门店代下单。
上述诉求是业务系统建设中非常典型和常见的树形组织机构管理诉求企业往往有多层级管理的需求,需要软件系统支持多层级业务体系。多层级机构管理通常使用组织机构树呈现,M公司分销业务的组织机构树如图6-1所示。
这是一个非常典型的多层级组织机构树,树中存在三种对象:
组织机构对象,图中用深灰色节点表示,用来描客户的行政管理级结构。分销总部位于组织机构树的根节点上。
门店对象,图中用浅灰色节点表示,是下的目标,是挂在某个机构节点下的收货对象。在数据结构中称其为门店,实际上有可能是小门,也可能是中央仓。
账号对象,图中用白色节点表示,代表系统的用户账号也挂在某个机构节点下。在“分销总部”根节点下的账,是分销业后台的管理员账号,可以管理整裸组织机构树中的所有数据,包括所有的门店和账号。每个账号所管理的数据范畴(包括能给哪些门店下单能查看哪些门的数据等),是通过遍历其所在节点的所有子节点来确定的。
每个组织机构(简称机构)对象都有一个“上级机构”字段,基于这个字段,可以绘制出完整的组织机构树:每个账号或门店对象只能隶属于一个机构节点:每个门下可以维护多个收货人。我们将这几种对象的关系通过数据建模ER图(ER围是一种经典的描述对象之间关系的规范。）呈现出来,如图6-2所示。
7.1.2、简化版分销业务客户模型
完整的组织机构树的开发复杂度很高。产品经理和业务人员及客户沟通后确认,一期暂不用支持复杂的行政层级管理,只需要为客户实现若干子账号,让他们可以管理若干门店即可。因此,产品经理最终决定采用一套简化版的客户模型来支持一期业务,不过这个简化版客户模型完全可以在需要时升级为理想版的客户模型。
根据上述需求,我们对组织机构树做一些调整,如图6-3所示。
从图中可见,现在每个客户节点只有一个父节点(隶属于分销总部):客户的所有账号和门店都挂在该客户节点之下账号和门店的管理关系不再需要通过遍历机构节点来获取,图中虚线箭头直接标明了它们的归属关系。这样的设计将导致账号无法对不同层级的门店进行灵活管理(像图6-1中那样),但是会让代码开发简单很多,因为工程师不需要处理一棵层级复杂的树形结构,也就不需要编写大量的递归算法,这大大降低了开发难度。
在业务开展时,每个客户有一个管理员账号,可以创建并管理子账号和门店,子账号可以设置为采购员角色,能够对关联的门店进行下单操作。而分销业务的超级管理员角色挂在“分销总部”根节点下,依然可以对所有客户的账号、门店进行全面控制管理。
根据上述规则对理想版客户模型进行简化,如图6-4所示。
仔细观察可以发现,该模型与图6-2中的模型相比,唯一的变化是在账号和门店两个对象之间建立了关联关系。这样处理保持了模型的可扩展性,将来需要实现全面的组织架构管理时,将账号、门店之间的对应关系打断,在业务系统中实现遍历算法和组织机构树管理维护功能即可,整个数据底层基本不需要调整。
对于图6-4的客户模型,如果设计人员认为,目前的业务诉求很明确,一个门店只能被一个账号管理,所以账号和门店的对应关系应该为一对多(而非多对多),如图6-5所示。
假设有一天,客户的某个门店雇用了多名采购员,因而客户要求实现账号和门店多对多的设计,这在现实世界中是一种非常合理的业务场景。
为了实现此诉求,开发难度将非常大,因为从数据底层到前端功能实现,都认为子账号和门店是一对多结构,如果将结构改成多对多,首先底层数据库结构需要调整,所有历史数据要处理;其次,基本上所有涉及读取账号和门店关系的功能代码需要全部重写。看似简单的一个改造,会造成一场灾难。
7.2、流程和角色
7.2.1、绘制分销业务流程图和角色
我们在第5章已经为M公司的分销业务绘制了粗粒度的核心业务流程图,为了方便阅读,我们将它复制过来,如图6-6所示。现在,我们要绘制创建客户与下单流程的跨职能分系统流程图。这需要仔细研究、梳理业务流转的具体环节和步骤,区分不同的角色,描述不同角色在不同子系统中需要完成的具体工作。
在流程梳理的过程中,必须谨慎思考各个环节在逻辑上的先后顺序与依赖关系,例如,对于分销客户来讲,创建账号和创建门店的顺序是怎样的?是一次性创建完成还是分别创建?什么时候维护价格系数表?通过思考,我们梳理出如下不同角色。分销业务在M公司内部包含如下几个角色。
分销-销售人员:M公司分销业务的销售人员,负责完成客户开发与合约签订(目前继续采取线下作业的方式)
分销-管理员:M公司分销业务总部的管理人员,主要负责审核分公司提交的创建客户的申请,核查各分公司维护的价格系数表,并进行毛利核算。
分销-运营人员:M公司分销业务总部的业务运营人员,负责具体的客户创建、维护、报价单维护等事务性工作。
分销业务客户包含如下几个角色。
客户-管理员:分销客户的管理员,维护并管理客户公司内的所有子账号、门店。
客户-采购员:分销客户的采购人员,负责给门店下采购单、补货。
基于上述分析,我们绘制出更细致的业务流程图,如图6-7所示。
图6-7重点各个环节二分析如下。
首先，分销业务的销售人员（角色为“分销-销售人员”）在线下开发客户（即分销商),将签约客户的合同交给运营人员角色为“分销运营人员”进行审核,这些都是没有系统支持的线下动作。
运营人员审核通过后,在分销运营管理后台创建客户以及客户管理员账号(母账号,也叫根账号),其中,客户的信息包括机构名称、营业执照、税号等,客户管理员账号只是提供给客户的管理员使用的系统账号。
运营人员添加了客户和客户管理员账号后,必须由分铺业务总部的管理人员(角色名称为“分销-管理员”)在分销运营管理后台进行审核,这是为了控制风险的必需环节。
营销客户的根账号(客户管理员账号)创建完毕后,由分销业务的销售人员角色为“分销-销售人员”)通知客户,此时客户可以使用客户管理员账号登录分销客户管理后台,维护并管理具体的收货门店和子账号(对应“客户-采购员”角色的账号)。
创建收货门店后,必须由“分销-运营人员在分销运营管理后台针对门店编辑报价表,只有设置了报价表,门店才能购买商品。
“客户管理员”在分销客户管理后台将创建的子账号和门店进行关联,从而让“客户-采购员”可以通过子账号登录分销商城前台,给关联的门店进行下单操作。
除了新客户创建、下单流程,还有退货流程、对账流程,都需要一一设计,设计方法与上面的介绍类似,此处不再展开讲述。
7.2.2、绘制分销业务的页面流转图
我们以分销-运营人员创建客户和客户管理员账号,以及分销管理员审核客户这两个子流程为例,演示如何绘制页面流转图。
请你闭上眼睛,在脑海中思考,如果你的角色就是分销-运营人员,需要创建客户和客户管理员账号,都需要访问哪些页面呢?
分销-运营人员首先需要登录系统,进入首页,因为要创建客户和客户管理员账号,所以需要分别访问客户列表页与账号列表页,在列表页中都有创建按钮,点击“创建客户”或“创建账号”按钮后,分别进入客户创建编辑页和账号创建/编辑页。
创建客户后,需要由分销-管理员进行账号审核。
分销-管理员同样要先登录系统,进入首页,因为要处理客户审核工作,所以需要访问客户列表页。针对某个客户点击“审核”按钮,进入客户审核页,在客户审核页中可以录入审核结果,并执行通过或拒绝操作。
这里面有一个问题:分销-管理员和分销-运营人员都要访问客户列表页,二者看到的客户列表页是否是同一个页面?我们从实际情况考虑:管理人员可以对每一条客户信息进行查看明细、审核、删除的操作,而运营人员只能查看客户信息的明细,可见二者查询客户列表的诉求是类似的,只是操作的功能点不同,这样的差异点完全可以通过权限配置实现(见6.6节),而没必要开发两套客户列表页。
构思完页面访问操作的场景,我们开始绘制页面流转图,如图6-8所示图中对每个页面做了编号,如果两个流程中某一页面的编号相同,则代表同一个页面,例如两个流程中都有“2.1客户列表页”。
可见,页面流转图比业务流程图更加细致。在之前的业务流程图中,关于分销-运营人员创建客户和创建客户管理员账号的操作,只是通过一个矩形框就完成描述了,但是在页面流转图中,需要更加细致准确地描述实现操作的具体步骤和对应的页面。
经过对业务流程、使用场景、页面流转的完整梳理,我们总结出在分销业务后台(包括分销运营管理后台和分销客户管理后台)需要开发的页面,如表6-1所示(此处只展示了部分页面)。仔细观察可以发现,这些页面其实就是针对不同对象(客户、账号、门店、报价单等)的增删改查页面。
