高绩效团队管理模型(团队管理2业务模型拆解)
业务模型的存在可以服务于企业的商业运转模式,结合业务模型,企业也可以更好地推动未来业务发展。然而,如何才能建立一个完善的业务模型?本篇文章里,作者总结了业务模型的搭建策略,一起来看看吧。
在《团队管理2——业务模型拆解(上)》这篇文章中,我们介绍了一家公司是如何运作的逻辑,一家公司的三大模型:商业运作模型,业务模型,财务运作模型。
接下来我们进一步较为详细的分析怎样搭建一个全局业务模型。
全局业务模型模型:简单说就是为了模拟、演示、深入分析被研究对象而建造的一套有逻辑的体系,可能包含许多规则、协作机制、流程,用以表达一个事物的运行方式。
业务模型:服务于一家公司的核心商业模式而搭建的一套模型,这个模型能够说明这个商业的运作方式,当有input输入到这套模型之后,能够有output,让一家公司的业务具有规模化,并进行发展。大致如下图所示:
为了能够更简单清晰的说明业务模型,我们以一个笔者实际操作过的业务举例。
笔者之前做了一个同城众包模式配送的平台,商业模式为:商家或者或者个人在平台发货,平台拿到订单,通过一定规则,将订单分配为众包配送员,配送员去发货点取货,取完货之后,进行配送,最终进货物送到收货人手上。
我们再将商业模式进行拆解,画出商业画布。通过商业画布,对我们的用户群体是谁,满足用户什么需求,给用户提供什么服务和价值,通过什么渠道、方式去接触用户,重要的合作伙伴,成本,收益等就非常清晰了。
在此基础上,我们分析核心价值链,先简单说配送的传统模式,也即是没有互联网介入时候的情况:发货人要发货的需求,电话找到配送员,给配送员交代收货点并移交货物(可能支付部分费用),配送员取货之后进行配送,送到收货点,收货人签收,提供回执,配送员拿到回执进行收费(尾款)。
为什么要分析一个东西的传统模式,通过了解一个事情的传统或者历史,能够把握这个事情的本质,也就是最初要达到的目的,这能让我们不陷入各种延伸的业务中,直接了解最基础的东西,避免抓不住重点。
对于配送来说,同城配送平台除了解决基本配送服务以外,还解决了商家找配送员、运费支付的双方担保、配送人员路线导航等痛点问题,提高了业务的运作效率,降低了配送人员入门的门槛(没有导航之前,必须要对路线非常熟练,你才能高效的完成任务)。对应的同城配送业务的核心价值链基本为:
1. 全局业务模型介绍
从核心流程及核心价值链,我们可以看出,整个链条由两部分构成:
上面说发货人的引入,发货人到平台发货,最终享受配送服务,这个链条是业务流转的基础,是实现收入的基础逻辑。
另一部分,比如要进行研发,要进行平台运营,要提供配单,运力调度等则是基础辅助业务。
则我们可以进一步说全局业务模型包括核心业务模型和支撑核心业务模型的其它辅助模型。
1)核心业务模型(业务增长模型):如何获取目标用户(客户),达到业务目的(转化、留存),获得商业价值的流程(收益、流量)的模型。
2)支撑核心业务流程的辅助业务模型,比如:生产、供应链、交付。
3)两者的结合点就在资金与服务/商品/内容的交付及服务保障这个环节,这也搭建了一个业务的整体业务概要模型,如下图为绝大部分业务的整体概要模型。
2. 如何梳理一家公司/平台的全局业务模型
我们还是以同城配送平台这个为例子进行介绍。
1)先梳理业务增长模型
① 发货客户增长模型
整个发货客户的增长模型,我们可以分为获客,激活转化,交易,客户留存(维护)几个大的环节,我们分析每个阶段需要做什么进行。
获客:可以通过线上、线下不同的渠道进行获客,线上线下又有不同的渠道,不同的渠道又要采取不同的措施,这里不展开说针对每个渠道的具体措施。
转化:通过日常的引流活动,促销,优惠券等方式,让用户去下单,进一步将用户根据用户自己的需求分流。比如用户如果是需要配送,那就去下配送单,如果用户需要别人帮买东西那就去下帮买单,如果用户需要别人帮忙办事则下代办单。
交易:用户下单、支付之后,等待配送员上门,并将货物移交和配送员,配送员配送完成之后,会将送到消息给到发货方。
客户维护:用户下单之后,可能因为服务的不满意而不继续使用,那么这个时候需要进行流失用户的召回,对于用户也需要建立用户激励体系,激励用户持续不断的使用服务。
对于不同的业务,其增长驱动略有不同,比如自己不做营销获客这一块,那么可以采用分销模式,则其获客,转化等可能就不是自己来做,也有可能是服务等外包。
但总的来说,需要梳理整个增长模型,这样才能清楚明白如何做增长,分析现存环节中的问题。
② 配送员增长模型
配送平台提供服务的是配送员,且这些配送员与平台非直接雇佣关系,平台利用配送员来提供配送服务。要获得配送员的配送能力,也基本是:获客,激活转化,交易,客户留存(维护)几个大的环节,我们分析每个阶段需要做什么进行。
配送员获客:通过线上方式拉配送员,比如通过人才市场,天桥下面有很多蓝领人可以到这个地方去发传单,小区的配送员会在快递柜存放快递也可以到这个地方去。线上有配送员的QQ群,可以和一些快递行业的公众号合作,通过官网招募,各种蓝领招聘网站进行招募。
转化:通过在目标人群聚集的地方拉人之后,这些有意向的人群进行报名,通过线上线下的方式对他们进行培训,让他们了解一些配送的规则,并进行考核,满足条件的人让他们入驻平台,则平台拥有了配送能力,可以进行配送业务了。
交易:配送人员提供配送服务,获取收益这是最根本的。则有订单的时候,根据订单的距离,配送人员表现等给配送人员指派订单,配送员根据订单信息拿货,进行配送,最终交货给收货人,平台根据配送金额进行核算将配送员的收益进行结算,则整个配送环节完成。
配送员维护:部分配送员可能因为各方面原因,会不再继续配送则需要进行一些召回措施,为了留住配送员在平台持续的进行配送,则需要对配送员进行激励。
③ 综合增长模型
我们通过上面的分析,获得发货客户和配送员的驱动模型,再把两个模型做结合,他们的交互点是,发货客户下单,配送员获得订单;配送员去发货方取货,并完成配送,两个模型之间的关联节点就清楚了。
通过交互节点,完成支付、服务的提供与转移,如下图:
2. 再梳理辅助业务模型
我们进一步分析辅助模型,发货方要发货,需要到平台进行注册,发货;配送方也需要到平台注册,获取订单,进行导航等。则平台需要提供相关的注册、发单、调度、接单、资金服务,要对他们进行运营管理,要提供整套的平台系统。
3. 全局业务模型
我们将增长模型和辅助模型结合起来,那么我们可以得到一个同城配送(众包模式)下的全局业务模型,从中我们就可以清晰的看到发货客户获客、转化、交易、维护是怎么做的;配送员获客、转化、交易、维护是怎么做的;他们都有哪些关键模块。我们也能清晰的看到,平台为了让业务顺利开展,需要做哪些具体的辅助业务,怎样来管理,管理哪些关键环节。
如下图:
4. 以业务系统为基础搭建IT系统
我们进一步分析业务系统,就能够得到我们要做的软件产品主要包含哪些系统,比如同城配送对应的系统就可以很清晰的看到:
- 发货系统对应发货服务体系:解决发货客户注册,发货,支付,到货通知等问题;
- 配送系统对应运输配送体系:解决配送员报名、配送、入驻、获取订单、进行配送导航,获取收益等问题;
- 运营管理后台对应整个平台的服务保障体系:解决发货、配送的所有相关问题。
5. 扩展到产品整体架构
我们进一步分析,可以将发货系统、配送系统、平台管理系统进行细化,则可以得到这个软件产品,包含哪些端口,为了实现业务,需要做哪些功能模块。下图我们将配送员和发货方使用的端口统一,都使用一个app来实现,则可以得到如下的一个完整的同城配送平台的产品架构图。
6. 可以从哪些方面去优化全局业务模型
1)明确基本收入转化链条
根据不同商业模式绘制典型商业价值诞生路径 收入转化链条,每一种商业模式的收入链条都不太一样,比如抖音、和美团的模式就有非常大的差别,制造公司和销售公司也不一样,这就需要根据具体的业务进行分析,找到这个业务的基本收入转化链条。
2)对不同用户的搭建不同的收入转化链条
同一个业务,针对不同的用户群体时,是否存在多个不同的渠道/典型转化路径可支持业务增长。比如说做教育,教育中有幼儿教育,幼儿教育又可以通过网课或者线下门店来做,那这其中的收入转化链条都不同。
3)根据业务/产品的类型来分析
不同的业务/产品其模式也会不一样,重大决策,非标,高价型产品与标准、快速、便宜的产品其模式就差距很大。比如买房与买洗发水,其用户决策心态,渠道,转化的手段,消费频次都差异巨大,在做模型的时候,就需要考虑到业务/产品类型的差异,来搭配适合的策略与模型。
4)判断是否需要进行长期的用户生命周期管理
有些业务就是一锤子买卖,有些业务则需要进行持续的服务。比如说考研培训,考公培训,旅游景区的饰品店等很多就是一锤子买卖,一个用户可能只有一次买卖,根本也谈不上持续的生命周期管理,就只会管本次服务交易。
而有些服务,比如说微信、抖音,或者美团这些,都是希望用户能够持续使用,不断的使用。那这些不同的业务,其业务模型,关注的重点等就会有很大的差异,有些业务你搭建用户生命周期管理的意义可能就不大。
5)理清关键成功因素及制约因素
每个业务成功的关键因素也不一样,比如说手工定制类的业务紫砂壶靠的主要是师傅的手艺,工厂靠的是标准流程与设备(工人在里面就不是关键因素),实体零售店靠的是位置,很多互联网平台靠的是流量。
以上提供了从几个方面去优化业务模型的点,但只有综合分析本身业务的特点,根据业务的情况来搭建适合业务的模型,这个模型才能发挥更大的价值,让业务更好的发展。
7. 如何评估业务模型的优劣
看模型是否稳定,是否能规模化,是否具备竞争力和增长驱动力
1)模型的真实性
尽可能真实、正确地捕捉业务。定义的业务架构应该是现实可行的、易于实现、有助于实现业务目标。
2)模型的清晰度
易于理解,并能够促进不同的利益相关者之间的沟通,而不是增加了理解业务的困难度,增加了相关方的隔阂。
3)模型的共识度
各方是否对模型的理解一致,是否承认这个模型,是否以此模型作为指导进行工作,是否在同一个语系下对话。
4)模型的扩展性
具有良好的适应性,易于变化和扩展,不会因为未来业务的发展而需要调整一些最基本的逻辑(早期探索的另说,这个时候业务本身是否合理都不一定)。
专栏作家
Markzou,8年产品经验,人人都是产品经理专栏作家。主要专注于本地生活、O2O、到家服务、新零售领域;曾任职于多家本地生活垂直领域头部公司,具有丰富的本地生活行业经验。
本文原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自 Unsplash,基于 CC0 协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
,
免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com