我理解的 toB 产品框架(二)

前文再续,书接上一回。我想跟大家聊聊我脑海中的设想的toB产品框架。如果大家还没有看过第一篇的话,建议看看:我理解的 toB 产品框架(一)

上一篇说到现在大多数的B端应用,在我看来都是由两大部分构成。底层是权限系统,顶层是以表单为首的三大模块。各个模块自由组合,就构成了一个个的 toB 产品。但是,这种产品框架较适合像ERP那样的私有云的服务。

而因为各种各样的App Store兴起,越来越多的toB产品开始往平台发展。而且微信的巨大成功,也让各种 toB 企业看到了成为巨头的希望。(顺便插一句题外话。我一直有个疑惑,中国模仿式创新创造出了阿里巴巴、百度、微博、嘀嘀这样的巨头,但是为啥没有 toB 的巨头呢?要知道很多世界500强的企业都是做 toB 的产品的呀~)

所以像钉钉与云之家就是采取类似这样的产品框架(只是大体上类似而已):

其实就是在原有的传统的 toB 产品框架上,增加了两大块。一个是IM模块,另一个则是应用平台。IM模块无需多说,就是一个聊天功能。而应用平台则是让各种各样的垂直 toB 或 toC 服务接入到基础产品中,从而达到场景互补的作用。

但是市面上的产品基本是做到了模块与模块的简单拼接。而近一两年的发展趋势则是要将各个模块打通。比如钉钉3.0发布会后,又举办了一场小发布会,就有讲到阿里商旅与报销对接功能,这个功能一眼看去就是为了解决报销繁琐的问题,看似简单,实际上从产品观的角度考虑,这是个巨大突破。要知道传统的私有云ERP系统就是一个信息孤岛。别说是信息交换了,就是单纯的信息输入都会有各种各样的权限限制。

而未来产品的框架就会有所变化,IM模块将会融合到传统的 toB 框架上,成为另一个基础能力。而在应用平台上的各个应用就可以调用平台本身拥有的能力。

他们的关系可以用软件与硬件做类比,比如你在使用滴滴出行叫车的时候,滴滴出行一般会使用GPS功能,帮助你快速定位上车点,而GPS功能滴滴是没有的,但手机有。滴滴只是调用手机本身硬件上的GPS模块而已。而未来的平台级 toB 应用也会是这样,在平台上的应用可以轻松调用本身平台的基础能力,比如流程引擎、权限系统等,这些应用都无需再去开发那么麻烦的东西,可以花更多的时间与资源去深挖业务场景,脏话累活基本上都由平台去干了。

比如我用钉钉提到的商旅报销的场景,对于商旅应用来说,其实它根本无需考虑权限问题,也无需考虑审批单据如何扭转。只要用户点击报销,商旅应用只需传输特定信息给平台,就可以了,剩余的事平台做就好。流程引擎收到需求,将数据自动填写到符合流程的特定表单中,再根据权限系统提供的参数,分配给特定的人进行审批。数据分析系统自动统计与监控整个流程,出现数据异常,马上反馈特定管理员。(当然这是理想状态下,这个流要跑通,估计实施成本会非常高)

这个产品框架只能说是近一、两年 toB 产品的一个发展趋势,还有另外一个趋势,就是...

欲知后事如何,请听下回分解。

Comments
Write a Comment