导语:随着支付宝小前台,大中台的概念获得成功实践后,越来越多的企业进入到中台搭建的领域,但是不是所有的企业都需要中台呢?本文作者以所在支付业务为例,向大家展示是否所有企业都需要搭建中台。
在搭建业务中台前,首先看一下是否有搭建中台的必要,分析一下支付行业整体的发展方向。
自从2004年支付宝作为第一家第三方支付公司出现至今,支付行业经历了从蓝海到红海的。以前支付牌照是香饽饽,监管不严格,利用牌照特性赚钱非常的容易。
现在央行也被支付公司一次次的套路中,学会如何进行监管,近年来巨额的罚单接连不断。监管意味着支付市场的空间被挤压,中小支付公司更是前有AT两大巨头,后有监管。面临以上种种情况,支付公司目前做的选择有一下几种:
1. 深耕支付领域、切入行业根据艾瑞数据《2020Q2第三方支付行业数据发布报告》得知,支付行业依旧是支付宝财付通保持领先地位,但是在第二梯队的情况在垂直的行业蓬勃发展。
例如:平安旗下壹钱包深耕在零售、金融、商旅行业,份额逆势而上占到了1.5%。
中小支付公司可以依据自身多年的经营特点,深入商户的支付场景,根据行业特点与商户共同搭建合规的支付系统,共同建立稳固的护城河。
同时还可以深入到平台上下游的厂商、经销商、品牌商等各个环节,通过支付服务、账户服务、供应链服务,并联合物流服务平台、金融服务机构帮助企业疏通产业链的各个堵塞环节,帮助整个产业链实现效能提升,进而达到对交易量、交易效率的改善效果,成功促成交易。
2. 外包服务,转型输出支付平台随着近年来产业互联网的推进,普通的产业会升级成数字化、在线化经营,这就伴随着支付也必须进行线上支付。
这就给第三方支付公司对外输出支付平台的机会,支付机构可以转型成为系统服务商,对外输出技术服务,可以收取相应的技术服务费用。例如可以为政府缴费平台、分银联支付平台搭建支付底层服务与完整支付的账户体系。
根据艾瑞数据查询的数据得知,目前第三方产业支付市场已经达到了百亿级别,中小支付企业可以乘势而上,加入产业支付升级的互联网大军中。
3. 市场下沉,聚焦聚合支付在面对支付宝、微信两座大山面前,挑战是必输无疑的选。
那么唯有选择进行合作。在移动支付还没有盛行之前,各支付机构主流采用的都是快捷支付、网银等支付方式。部分商户系统对接能力较差的,无法对接多个支付机构。
但是系统的支付稳定性又没有保障,这时候就出现了四方支付机构。四方支付机构的特点就是一站式服务,解决商户对接困难问题,保证支付的成功率。对接四方的费率就会高一些。
以前只有没有牌照的支付企业才做聚合支付项目,称作是服务商,主要针对的是B端的商户。
但是中小的支付企业目前也是在抢占聚合支付的市场,依靠自身拥有支付牌照,可以建立支付账户体系,可以进行清算的特性,搭建一站式聚合支付服务,为商户提供一站式接入云闪付、支付宝、微信支付、银行APP等主流支付工具进行收款。
4. 出售牌照,金盆洗手近期看到字节跳动、携程、京东、拼多多系列的牌照收购事件,在被央行监管、支付宝、微信多种挤压下,很多中小型的支付公司已经没有变现盈利的能力了,只能够寻找新的变现渠道,那就是出售牌照。
而同时呢,行业巨头有支付牌照的需求,不希望在自己的场景内,把支付业务的主动权拱手,但却无法再申请新的支付牌照,两者的需求交互,产生了一门新的生意——牌照收购。
所以许多拥有牌照的中小企业,可以依附于行业巨头的树荫下,或者直接出售牌照的所有权,直接金盆洗手,不干支付行业了。
5. 行业分析结果从目前来看,聚合支付市场以及行业支付领域都是比较饱和的市场,处于一片红海,唯有外包服务服务,还是市场比较大 ,传统的企业需要数字化转型需要大量的外包业务服务。这就给支付公司的业务模式有很大的挑战性。
一般支付公司的后端的逻辑是比较稳定的,为了契合业务方的需求,不断的复制同一套代码,做定制化的业务改造,有些相同的业务也是在重复搭建,维护的时候相当的复杂。
在底层有变更时,需要同步变更多个服务,还需要评估变更对这些业务的影响有多少,可能有的影响多,有的不受影响,这就给中台提供了机会。
二、业务框架梳理按照业务线的形式,梳理了两条的业务线的产品架构,具体内容如下:
1. 原业务逻辑说明根据以上梳理的业务框架可以看出,两条业务线之间重合部分比较多。这就导致了两条业务线之间都分别重复搭建业务重合部分,这就造成了很多的资源的浪费。
除此之外并且会造成以下几个问题点:
- 后端逻辑有改动时,两边业务得同时更改。这就造成后端上线有部分无法兼容所有业务的内容,前端必须反过来兼容后端的业务逻辑。
- 后台的业务系统日渐趋于成熟,改动点比较难,如果有业务线有新需求接入时,需要兼容的内容太多,会导致迭代的速度非常慢。
- 商户数据未打通,各业务线容易形成数据孤岛,无法联合进行营销、风控等。
以上图框架中以云闪付产品举个例子,分别对应以上的问题点:
- 例如银联云闪付业务变更,此时后端的逻辑逻辑进行了变更,需要必传参数增多,此时需要同时聚合支付业务线和快捷业务线都得相应的进行改造。
- 聚合支付业务线向后台业务提了一个需求,希望后端更新云闪付的红包功能,但是这个业务功能并不是快捷业务线所需要的,此时后台就需要兼容快捷线做兼容考虑,可能会导致迭代的效率较慢。
- 由于聚合支付业务线刚起步,希望针对云闪付的商户做补贴。需要精准的找到补贴用户有些,这些用户在快捷业务线才有。此时聚合支付业务线只能依赖线下传输方式才能完成此时的补贴,用户数据不断变化的,每次做营销活动都得进行线下活动整合数据形式才能完成,并且数据并非是实时数据,还不能和自身业务进行相匹配。
以上的三个案例充分说明了,当有多条业务共用一个后台时,此时就会陷入多方同时维护同一个功能的地步,造成资源极大的损耗。同时会在公司内部不同业务线之间存在极大的信息孤岛,不利于公司的后续发展。
三、中台业务梳理通过上面的数据分析完成后,说明还是很有必要构建业务中台,在构建之前需要考虑清楚什么业务的才能成中台业务,这些业务如何才能体现中台价值。搭建业务中台最终目的是为了节约成本,包括人力成本、资源成本、时间成本等。
即当公司需要发展多条业务线时,这几个业务有高度重合部分时,可以快速的进行迭代,并且所使用的资源是最少,简单来说就是做一个产品需要性价比高,或者ROI(投入产出比)高。
1. 功能在各业务线使用的频次在计算业务线使用的频次之前,得先梳理系统的业务逻辑,需要具体到每个业务流程都使用了哪些功能。
以收银为例梳理整个过程所用到的功能:
- 登录商家账号使用的模块:商户管理(商家状态校验、商户信息查询);
- 选择收款方式:商户管理(商户开通产品);
- 扫码用户二维码:商户管理(商户信息查询、商户状态校验)、账务管理(账户状态)、路由管理(路由查询可用支付渠道)、订单管理(创建订单、优惠信息计算)、通道管理(往上游上传交易相关信息,获取用户支付信息);
- 用户确认支付:无(PS:用户端输入支付密码,属于微信、支付宝、银联等客户端输入支付密码,与B端商家侧系统无关,此处是为了流程更加畅通,方便阅读);
- 收款完成:商户管理(校验商户信息)、订单管理(更新订单状态)、账务管理(计算手续费、计算分润、生成账务流水)、账户管理(更新商户账户余额、更新手续费账户余额、更新代理商分润账户余额)。
整理上述的功能模块复用情况如下:
根据上图可以得知,聚合支付业务线商户管理、订单管理的复用次数最多,同时将其他行业线也一同梳理,最终将不同行业,相同功能模块的模块整理成一个表。
例如下图展示:
以上表可以得出商户管理、订单管理占据在整体比重较大,可以优先抽取至业务中台,剩余的模块需要根据公司业务进行评估处理。
2. 公司战略目标在设计业务中台时,还需要和公司的整体战略目标相一致,中台的威力才能完全体现。
因为中台最大的作用就是复用能力,当公司业务重心在某一领域时,业务中台应该契合公司业务重心,才能发挥作用,不然又是陷入重复建设的陷阱。
公司想把所有的账户进行打通,让商户接入不同业务线时,资金可以在不同业务线之间共用,而每个业务都有账户管理模块,此时就可以将账户管理模块统一化,建立统一的账户体系。当一个商户对接多条业务线,资金不需要重复的进行提现充值动作,可以直接在不同业务线之间划转。
四、新业务框架根据业务梳理的情况,构建了新的业务框架,具体如下:
将前台相同模块的业务进行抽取,简化前端的业务逻辑,将大量的运算放置在中台,同时前端业务不直接对接到后端。
后端有变动时,只需要中台进行修改兼容就可以,而不需要每个业务线都进行相应的整改,并且将业务数据进行打通,便于前端进行推广或冷启动时提供更多的商户数据。
五、总结关于业务中台是否需要搭建,主要还是根据公司业务情况而定,总结一下几点:
- 如果企业业务是横向拓展,并且相互之间没有太大的关联性,同时公司战略也不是同时多业务线并行开发的,这种搭建中台的必要性就不高。
- 如果业务集中在某一个领取或者业务之间的功能重合度比较高,此时可以考虑先抽取重合部分抽取组成业务中台。
- 搭建中台还需要关注行业动态,必须的捕捉行业的发展趋势,因为中台建立后,所有的前台的业务都对接中台,相关的业务承接方变成中台。得中台建立完成后,前台才能完成相关动作,所以中台尤为关键的就是捕捉行业的动态。不然跟不上发展趋势,前台业务可能会另起炉灶,自己重新建立业务系统。
本文由 @TOM 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。