B端产品特点
一、强调抽象和逻辑
解释说明:B端产品的目标是解决企业、组织的某类业务问题,因此系统设计的重点在于如何让业务流程闭环、将核心流程跑通,进而赋能业务发展。
举例:在做B端产品时经常会遇到单据审批状态的逻辑,以合同为例:真正业务中合同单据只有领导审批通过之后系统内才能正式使用,应该如何设计产品逻辑?
解决方案:可以将合同状态分为:草稿、审批中、已生效、审批驳回,并且不同状态下又要具备不同的操作按钮与处理逻辑。
状态 | 定义 | 按钮 | 备注 |
---|---|---|---|
草稿 | 合同提交审批前状态 | 删除、编辑、查看、提交审批 | |
审批中 | 合同提交审批后、得到审批结果前状态 | 查看、撤销审批 | |
已生效 | 审批通过后的合同状态 | 查看 | 问题:已生效合同如需修改,请思考如何处理? |
审批驳回 | 审批驳回后的合同状态 | 查看、编辑 | 编辑后合同状态为草稿 |
深层分析:并不是说B端产品不需要考虑体验,更强调逻辑的原因在于目标和动力与C端产品不同。
-
目标:B端产品最基本要求是要提升原本同样业务流程的工作效率,而不是像C端产品一样如何提升用户的留存率,所以用户体验并不是最重要一环。
-
动力:B端产品使用者不是C端的每一名用户,所以企业在保证软件能用、好用的前提下,没有动力投入更多成本追求更好的视觉体验。
二、业务强驱动
解释说明:B端产品好坏的评价标准是能否现有业务问题、甚至引领业务发展,这就要求B端产品经理能够深入了解业务、判断业务发展方向,才能够设计出适合企业生存发展的好产品。
举例:电商集采是典型的、具备相对成熟方案的B端产品能力,公司A自行研发一套系统用于集中采购,请设计核心流程。
解决方案:作为产品经理,首先要了解企业电商集采流程,完全不同于我们个人在淘宝、京东购买产品。如果没有相关业务知识,建议先自行学习采购相关知识,再进行业务调研(思考:设计业务调研清单 ),否则会非常非常难受,下图是流程示意图。
深度分析:
-
为什么B端产品要考业务方驱动:B端产品是为了解决组织内某个或某一类具体业务领域问题,而业务方是离业务最近、离使用用户最近的,所以从谁更懂用户、谁才更能真正解决用户问题的角度看, 业务方驱动产品需求是正常的。
-
如何与业务方共同驱动产品:要想与业务共同驱动产品,只有一种解决方式:不断学习业务,比业务更懂业务。不过这是一个非常漫长的过程,可以通过视频、书籍提升专业知识能力,可以通过多次调研沟通了解业务操作,如果有条件可以亲身操作才能感同身受。
三、配置能力强
解释说明:相比于C端产品,B端产品是一群人在使用,所以避免不了会存在各种权限的配置(包括页面权限、按钮权限、数据权限等)、审批流的配置(合同审批流、付款审批流等人员的配置)、下拉列表值集权限配置、流程节点配置等。在这样的情况下,B端产品需要充分考虑市场情况,在设计之初就要在产品结构层上留出一定空间,能够把一些流程必要但是标准不统一的部分做成可灵活配置的功能,能够达到虽然业务流程不标准但是产品依旧能标准化的目的。
- 权限配置:B端的产品业务都会根据每个角色的不同而划分不同的业务场景,不同的业务对应不同的流程,所以需要各种不同业务流程的专业性解决方案。以集团内部业务协同系统为例,业务场景简化为发布公司需求,下表为简化后的角色和对应权限(思考:B端权限设计RBAC是什么?)
角色 | 权限 |
---|---|
业务人员 | 可以增删改自己发布的需求 |
公司管理员 | 可以增删改自己发布的需求,并且查看该公司及下级公司发布的所有需求 |
集团管理员 | 可以增删改自己发布的需求,并且查看该公司及集团各级发布的所有需求,对重点需求进行置顶、加热提高推荐概率的处理。 |
超级管理员 | 可以增删改查系统内所有需求,并且进行所有的操作。 |
- 审批流配置:审批流是非常成熟的功能模块,但是不同审批流能够满足的业务场景却有所不同,下表是常见的审批流规则需求。
审批流示例 | 审批流节点 |
---|---|
A部门付款审批流 | 业务员→部门领导→财务部领导→公司领导→财务人员 |
A部门合同审批流 | 根据合同金额做判断,合同金额小于等于50万,无需审批;大于50万小于等于200万,部门领导审批;大于200万,公司领导审批 |
A部门用印审批流 | 业务员→管理员1 |
A部门会签审批流 | 业务员→6位中层领导→公司领导,只有6位中层领导全部审批通过后,单据才能流转到公司领导。 |
A部门采购审批流 | 业务员→6位中层领导→公司领导,只要6位中层领导中有人通过,单据即可流转到公司领导。 |