流程才是B端产品的用户
本文从角色、数据、逻辑三个角度分析了——为什么说B端产品用户是流程。
笔者之前设计了一企业服务SaaS产品,如今产品已经上线。C端产品的用户是个人,那B端产品也是如此么?
我认为:B端产品的用户是流程。下图是笔者设计的一个产品功能的流程图(泳道图)。结合此图讲解下为什么说B端产品用户是流程。
这张图由3部分构成:角色(管理员、其他业务角色)、数据(业务数据、系统数据)、逻辑(节点和分支)。
角色
首先说说“人”,也就是使用者。在C端产品中,大多数情况下都是单人使用。这类产品用户往往以自我为核心,产品是否满足了需求?产品解决了什么问题?这些都有单个人决定。
但是在B端产品中,一个人通常是一个角色,如仓管,财务,销售等等,这个人只是参与了工作流程中的一部分(如上图中的管理员,仅起到了平台管理的作用),更确切地说是某个角色参与了其中,而这个角色并不能完全决定产品是否满足了其需求。
在考虑人的问题上,需要从个体和整体出发。个体即单个使用者,系统不是强人工智能,很多事情需要人来完成,用户的交互体验在这个时候B/C端无异,都需要有友善的交互,友好的界面来实现。
但在整体上,B端就需要思考一个C端产品通常没有的功能:权限。每个角色都需要参与,但不同的角色可操作的或者可见的数据都不一样,在这里笔者推荐B端产品同学学习下RBAC模型,可适用于广泛的后台系统。
上图中我们可以看到,TK仅可做发起和结束的操作,对应的数据可见性也是如此(上图中TK不可见JW操作的数据)。不同的角色拥有不同的权限,根据企业客户的需求配置权限是B端产品的基本功能。
三级RBAC模型有岗位和角色设置,可以满足大部分企业需求
数据
说完角色,我们再说说数据。
数据现在越来越被重视,在一个企业运行过程中,其实都是对数据进行操作。每个公司都有不同的业务数据,就算是通用的流程如审批、请假等也可能会有不同的数据产生。在不同的业务中,我们就需要梳理不同的业务模型,其实也就是梳理数据的流动(上图中数据来源是TK,中间经过不同角色处理,最后再回到TK)。在做数据梳理的时候,需要注意版本和统计。
企业生产的产品的迭代更新过程也就是数据的变更过程。积淀下的数据作为历史版本保留是每个企业发展过程的必要需求,一方面历史版本可在后续产品变更过程中起到避免踩坑的作用(互联网产品也不是如此么);另外历史版本的记录可以作为追溯材料,一旦后续生产过程中出现问题,即可了解原因以及追责。做B端产品的时候,如果开发同学没有做对应的功能准备,记得一定要提醒他们为版本对比、版本记录做好准备工作。
数据另一个必须的操作就是统计。
产品在生产过程中一定会遇到各种异常(生产制造业有良率、合格率),统计生产过程中的数据,了解生产过程中的异常是大型企业必做的工作(通常有个质量管理部门做这个工作)。
其实除了生产的数据需要结合实际业务需要做有关统计外,企业用户往往不会想到一些基础的系统数据:日期、生产批次、处理时间等。在做数据统计时候,一定要提前考虑到这些看似与业务无关的数据,痛点问题其实往往隐藏在这些不经意的数据中。因此,作为产品经理也需要提前考虑到这些数据的采集埋点工作。
PCBA工艺流程
逻辑
说完了数据,最后说下流程中的逻辑。
上一节中有讲到数据的流动,数据怎么流动就是产品设计中的产品逻辑。思考B端产品逻辑往往是考验B端产品经理最基础的基本功。笔者个人认为,梳理产品逻辑的前提是对业务逻辑的梳理,而业务逻辑的梳理就是数据流动的梳理。
绝大多数情况下,产品逻辑是不止一条单向路径的,这也往往是企业用户的痛点所在:内外运作过程中,涉及到不同的人,不同的流程,人在处理这些事务的时候无法像机器一样工作而不出差错,通常情况下就是靠更多的人力来解决。那么B端产品就是将这些业务逻辑抽象成产品逻辑,用软件产品代替人力工作。产品服务对象之一即逻辑。
该图是产品中的一个子功能模块(NPI功能),该图显示了在不同的情况下(节点),数据的不同走向(分支)。如何才能相对完整的做出一个数据流程图?个人认为就是考虑闭环。数据闭环一定是有始有终的,如果发现某一个数据没有出现在任何分支中,那说明这个逻辑肯定出了问题。
在考虑产品逻辑的时候,可能因为分支多节点多,一下子考虑不清楚,个人建议先做主流程的梳理(上图中最左边竖直的流程),通常来说业务流程都会有一个很顺利的主线(最短线路),优先完成该主线路再思考其他线路会比较条理清晰。思考分支线路的时候,还是注意闭环,当出现一个分支选择的时候,先理清其中一条线,再去考虑其他的分支,完成了一个循环再做下一个。在设计过程中,尽可能避免大闭环中套小闭环,不然在程序设计上会非常麻烦,在用户体验上也可能导致层次不清的糟糕体验。
综上所述:B端产品服务于角色、数据、逻辑,而该三者构成的即是流程。缺少任何一个,其余两者皆构不成企业运作。
- 角色的重点在于权限,不同的角色有不同的功能;
- 数据的除了业务数据外,也要注意版本和统计,没有对比的数据是无用的;
- 最后逻辑将数据和角色串联起来,完成一个产品的功能,满足企业用户的需求。
本文由 @Hannibal 原创发布于人人都是产品经理,未经许可,禁止转载
题图来自Unsplash,基于CC0协议
深表人同,B端产品角色划分/业务逻辑/流程 务必先确认清楚,再考虑具体的功能。否则功能做出了就是一锅粥
我觉得抽象为: 参与人、数据对象、业务规则、流程 更加好
一个判断出现两个NO不会出现逻辑错误吗
好乱的流程图 1
好乱的流程图
不错不错