B端产品的业务诊断与建模

10 评论 15077 浏览 110 收藏 19 分钟

2021年9月4日~5日,人人都是产品经理举办的【2021产品经理大会·广州站】完美落幕。致景科技集团创新事业群副总裁翟锦修进行了精彩的内容分享,他分享的主题是《B端产品的业务诊断与建模》。添加大会小助手豆豆(微信号:13265455310),回复暗号【031】,获取本场嘉宾分享视频回放,观看完整演讲。

下面我先做一下自我介绍,我叫翟锦修,大家可以叫我老翟,我有16年IT相关工作经验,14年产品经理工作经验,在很多企业都干过。真正让我得意的成就是我在起点学院已经完成了22期,4300+余名产品经理的线上线下实战教学,有个好处就是每个城市里都有我的学生。

一、B端产品能力挑战:业务建模

1. B端产品经理是个什么

中国现在已经进入到B端产品时代,当我们在百度搜B端产品经理这个词,会搜出多种结果。大部分都是在问B端产品经理是一个什么样的角色、它最核心的能力是什么、我该如何修炼、如何提升等等。

一个个互联网产品要么向个人用户提供服务,要么向企业用户提供服务,这是它的商业模式所决定的。如果你向个人用户提供服务,你可以做短视频、电商,这些都是服务于个人的个人用户,他一定是以自然人、以用户的形态出现的。他不是一定有工作职责的人,他就是一个自然人,有喜怒哀乐,有爱恨情仇,你可以通过人性去揣测他、通过A/B测试去测试他,这就是我们所说的To C是产品的商业价值,是基于个人用户的。

如果你是得物的产品经理,主要负责得物的配送系统,当需要把货送到用户家时,请问这个时候你还有用户吗?如果你负责得物的商家结算系统向供应商进行结算,那你还有用户吗?

答案是没有,你面对的是企业用户,当你向业务用户、企业用户去谈功能时,商业利益和工作利益将会压倒他的个人欲望、个人诉求,这就是我们所说的TO B。

得物是一个TO C的产品,但是它却有B端的产品经理在研发它B端的功能,B端支撑起了它的C端,所以TO B和TO C是一种商业模式的不同,C端和B端是产品经理划界的不同。

任何一个企业都有可能会出现B端的产品和C端的产品。比如有赞,有赞是TO B,卖给一个企业来使用,并由企业来付费,但是有赞一定会有商城的存在,虽说是给企业搭建商城,其实也是由个人用户来使用。

所以说,TO B和TO C是从商业价值的实现方法方面来说的,B端和C端在产品生态中的使用者到底是谁?B端的使用者往往以“角色”的形象出现的,而C端的使用者被统一称呼为“用户”。

B端和C端在这里主要差别在于使用对象不同,用户是有主动观念的、是要被你拉拢的、是要向他讨好的。但是角色不一定会这样,他有可能是被你欺负的,因为他的领导要求这个业务流程必须这么走,无论角色喜欢与否,也得执行工作。

2. B端产品经理的能力模型

我们可以用一个金字塔来表示B端产品经理的能力范畴,一个人的能力往往屈从于三个环节,第一个是素质,素质带有一定的天赋,比如思考能力、沟通能力、协调能力等等,天赋好的人容易事半功倍,天赋不好的人则容易事倍功半。

第二个是知识领域,当你做B端的时候,大家都会说你是哪个行业的或者是哪个领域的。比如,我是做财务结算清分系统的,你现在让我去做仓储物流系统,那我就得从零开始了。业务知识是卡掉产品经理的一个很重要的环节,这也是这个行业中人才很难诞生的原因。

第三个是技能,技能是需要你通过不断的实践总结去获得的,它分为系统设计的能力和业务建模的能力。

3. 业务建模是什么

一个B端产品做一个等分,一部分对接IT。另一部分是业务建模,对接的是业务,这是我们今天要讲的主要内容。有人认为B端业务是很容易的,因为客户有需求,可以直接找业务方商讨。

先给大家讲一个案例,产品汪建了一个仓库系统,一开始很简单,系统做了一张入库单,一张出库单,操作也很方便。B端有个特点就是很多的业务流程变更都是由领导变更开始的,因为B端是要承载管理思想的,所以当管理思想发生变化,业务流程就一定会发生变化。

有一天,来了一个新主管,主管就要求我们对业务做区分化管理。在主管的带动下,大家集思广益后,我们在系统上增加了很多功能,有一般出入库单流程、大家电入库单流程、样机借出库单流程、样机借用换入单流程、配件出入库单、退货出库单流程、WMI入库单流程等等。产品汪就想,干了这么多,来个五星好评!但是系统一上线,甲方嫌很多业务没覆盖,所以只能再次开发业务,二次上线后,甲方又嫌系统太复杂。

所以我们要怎么解决这个问题呢?大家都知道,业务是不断灵活的发展的,很多东西都是尝试性的。比如来了一个新的仓库主管要求分等级做管理,接着又换了一个主管要求管理集中化,所以怎么才能做一个灵活的系统去适配情绪需求的变化?这时候就要做业务建模。

一个仓库发货收货有哪些节点会影响到业务流程和业务实体属性,这是第一个要思考的问题,一张单据一定会有一个品类限制,只能发某一类的货,比如,大家电的单据只能发冰箱、空调等等。跨库调拨的单据不能跨库调拨生鲜,因为生鲜一出冰库就容易坏,不好保证按品质再入库。

第二个叫库位限制,就是某一张单据只能逆动到某一个库位的东西,比如说退货给厂商,只能从退货区发货。

第三个就是就是异动属性,有异动属性的品类,有的是发货,有的是收货,而跨库调拨单据是转移。

第四个就是结算方式,有的单据的结算方式是WMI,有的是采购。结算方式为采购的单据在货物入库后,就会产生收账,应付账款。

第五个是成本核算,有的单据和财务相关,这时候就要对账单进行成本预算。

第六个是审批流程,每个账单的审批流程都不太一样,你可以做流程引擎的抽象并命名这个流程名称与哪类业务账单挂钩,所以我们出现一个概念叫单据类型。

我们把单据类型定义为收货、退给厂商、跨库调拨、样机借用、紧急采购、报废代减、检验报废、包装领用、销售出库等属性的集合体。

这时候我可以支撑一张单据,也可以支撑二十五张单据分层分等级地去建设,而且我能够给程序员讲清楚每一种业务逻辑,所以这就是清晰的业务建模,业务建模是一个产品经理功力的表现,是跟着需求走的。

那业务建模是什么业务建模?业务建模是对业务进行抽象的过程,又叫业务数据建模、业务实体建模,合理的建模可以让后续功能设计水到渠成,而不合理的建模会导致后续设计重复返工。

B端业务建模对整个B端设计是至关重要的,一个优秀的业务建模可以保证业务扩张、研发成本和系统复杂性三者的平衡,一个错误的业务建模,或者完全没有业务建模,都可能导致随着业务业务扩张、研发成本/系统复杂性暴增,直至企业IT无法承受。

各个B端产品经理在“江湖地位上”的差异很大,其在能力上差异主要在三个点:业务专业知识、业务诊断能力、业务建模能力,这是评定一个B端产品经理优秀与否的关键。

4. 如何做业务建模

业务建模的能力体系分为三层:知识层、能力层、方法层。

知识层指的是业务知识,业务知识是业务建模的基础,它可以通过读书上课获得也可以在不断地工作和实践中进行学习、总结业务知识。各个领域都有各个领域的业务名词、业务术语、业务逻辑等等,这都是需要长时间的摸索、积累、总结,而且这些业务知识会随着行业发生变化而变化。

与C端产品经理不同,B端产品经理的业务知识是最为重要的基础能力。你可以没有Sense,没有style,没有满口的“发力、降维、抓手、反哺、下沉、裂变、组合拳击穿心智……”

但是你要熟悉你的专业领域,而且不断迭代你自己领域的专业知识。这也就是B端产品经理从来没有35岁危机的原因,这是一个越老越香的岗位。

能力层指的是抽象能力,抽象能力是做业务建模的必要条件,它需要依赖一定的天赋,否则你只能使用别人抽象的成果。业务抽象的能力决定了一个产品经理的天花板。一般来说,一个专注于某个领域的产品经理,只要不是划水汪,6-8年的积累足以让他的业务知识达到够用的层面。

那如何去培养业务建模的能力呢?方法有三个:抽象要素、理清关系、寻找规律。抽象要素是寻找业务实体内部的自我构成,比如一个商品库存的要素是地点+库位+品号+批号之类的。理清关系是寻找业务实体之间的关联。寻找规律是在上述两点的基础上推演出业务规律来。

5. 总结

如果你有志成为一名越老越香的B端产品经理,踏踏实实的一步一个脚印的成长,才是唯一的捷径,因为无论是知识的积累、能力的训练都需要花费大把的时间和心血。

碰上困难就念叨着选择大于努力,做几个模块就觉得自己天下无敌,努力几个月就想改变世界的同学,不适合做B端产品经理,仰望星空很重要,但是脚踏实地地去积累和成长更加重要。

二、B端产品汪的生存报告

1. B端产品的三大爽和三大难

三大爽指的是领域专业性、成长周期长、团队地位高。刚刚已经讲过B端产品的领域专业性强,B端不同于C端,比如你做个抖音,说不定几个月就爆红了,但是做B端是一条比较难的路,周期会很长,比较稳定,但是需要长期的积累。

还有一个就是B端产品经理是整个B端研发团队中地位最高,比B端产品经理地位更高的只有领导。但也同时存在着三大难,方案设计难在刚刚已经讲过了,可想而知,一个简单的商品模型、单据模型的构思都这么复杂,所以证明它的设计难度很大。另两难指的是项目推进难和实施落地难。

2. 如何落地一个B端产品项目

B端产品落地分为三个阶段。第一个阶段是需求阶段,在这个阶段会经历需求准备、需求内审、方案评审会、方案定稿封板等过程,在方案评审过程中一定要有优秀的业务建模,而且一定要控制好需求定稿。众所周知,抽象、逻辑都是基于一个固定的需求场景,当需求场景不断发生变化时,是没有办法去把方案定好。

第二个阶段是开发阶段,这个阶段是项目实施关键点。技术方案及排期、测试用例评审、开发、测试、产品验收等都属于开发阶段,这个阶段跟其它行业的产品线差不多。

第三个阶段是发布阶段,这个阶段主要包括发布准备、项目实施、正式上线、数据/用户反馈、需求池。

如果想要落地一个B端产品,就要做好项目实施。项目完成并上线后,理论上是可以用了,那为什么还需要实施呢?

因为大部分使用B端产品的用户都是被迫使用的,他们并不想用这套系统,我们做业务需要纪律性,就得被系统控制,所以即使不喜欢,也得为了工作着想,所以才会出现用户主动性不强的情况。如果想要整体的系统被用好,你就得帮助B端产品使用群体掌握产品的标准化使用方法,形成内部传承,达到使用效果,这个过程叫做项目实施。

项目实施可以分为六大步,分别是先宣贯、再培训、找种子、写手册、驻场训、勤总结。

宣贯是为了告诉参加这个项目的人,这个项目的具体信息以及未来的工作安排。再往上就是分批做操作培训,培训要先僵化后优化,要有考试和打分。接着要去找种子,就是每个角色都要有种子用户,把操作手册交给种子用户,之后新员工就可以去找种子用户去学习,然后组织种子用户写手册,用用户的语言来说操作,以达到一种授之以渔,文档迭代的效果。

接下来就是驻场训,在前几步的基础上,项目一旦上线,你就一定要在现场待着,有问题随时解决。最后就是勤总结,勤沟通,勤汇报,站会、周会、月会,寻找问题,总结规律。

以上就是我的分享,谢谢大家。

相关阅读

《C端产品的增长实践》

《大变局下的产品经理生存指南》

《新消费品牌爆发背后的全域增长之道》

《透过金融产品实战,深入剖析业务驱动下的产品架构》

《不被时代抛弃的产品经理》

《从机票增长变迁窥见获客新世界》

年度行业大会开启巡回

互联网圈年度盛典,听一线实战专家深度分享,与数千位互联网圈同行深度交流,拆解产品、运营实战案例,挖掘行业新机会!

扫描下方二维码添加大会小助手,回复暗号【032】领产品经理&运营人必备工具包,获取全年大会最新资讯!

本文为【2021产品经理大会(广州站)】现场分享整理内容,由人人都是产品经理实习生 @黄彩怡 整理发布。未经许可,禁止转载,谢谢合作。

题图来自大会现场

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 可以就建模来举个例子嘛?带图的更好理解

    回复
  2. 有原视频地址吗

    来自河北 回复
  3. 写的很好,感谢分享

    来自江苏 回复
  4. 感谢分享,受益匪浅。

    回复
  5. 这一篇说的真不辍

    来自北京 回复
  6. 很干,的确是要有很系统的建模能力,业务给的都是零零散散的点,很容易被带偏,非标准的诉求往往不能有拓展性,导致会重复做工,业务同时又说系统不好用

    来自广东 回复
    1. 同感,一直以为这个业务建模,也就是抽象能力才是最重要的,忽略了这一点系统生命周期就不长了。

      来自广东 回复
  7. 要成为一个好的产品经理,根本上是要落实项目的实施,专家说得都是基操,新人应该多看看。

    来自广东 回复
  8. 挺好

    回复
  9. 学习了

    回复