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

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

前文再续,书接上一回。上一篇文章跟大家分享了这一、两年的 toB 产品的一个趋势,本篇想跟大家分享下另一个趋势。如果你没有看过我之前的分享,可以看看:

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

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

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

如果说 toB 产品的第一个趋势是应用互联,那么另外一个趋势就是企业间的信息互联。像传统私有云的 toB 产品,基本上就是个信息孤岛,企业信息很少流出,或者与其它企业直接交换信息。举个例子:

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

你的客户需要订一批货物,销售一般会在公司的ERP或CRM系统录入订单或合同,然后走审批。该合同可能还需要快递到你的客户那里,然后又走一遍审批。最后完成生产和发货。整个流程异常繁琐,而且速度很慢。(这个场景已经算是快的了,还有更长更麻烦的。)

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

另一方面,即使是简单的信息触达,可能都会很麻烦。拿钉钉做为例子:

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

你所在的公司在使用钉钉,内部交流一直是使用钉钉,但是当你需要跟你的合作伙伴、你的客户交流时,你还是需要打开邮箱、QQ或者微信,因为你的合作方不一定在使用钉钉。

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

第一个场景,将会是目前 toB 平台产品重点关注的切入点。即类似钉钉3.0推出的服务窗的概念。企业的外部好友(合作伙伴、客户、甚至供应商)都能通过这个服务窗发起订货、退货甚至联系客服等等。而这个服务窗的背后,将会是企业的ERP系统,甚至是企业的智能制造系统。其产品框架将会类似(A、B为不同企业):

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

理想化的场景将会是这样的故事(举例,非实际):

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

如果某经销商需要订购100箱面包,该经销商直接在面包生产商那订购,面包生产商收到订购订单后,系统自动进行库存盘点,如果发现货物不足,机器自动开始生产。同时发现面粉也不够了,会自动向上游的面粉厂订购面粉。

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

这套产品框架貌似能跑通,但是实际上是个大坑。比如目前钉钉提供的服务窗能力对于 B2B 的企业估计就比较麻烦了,毕竟这种企业涉及的订单金额更大,流程也更加繁琐,人情交易也更多。如何在做到信息流动之余,还做到销售提速,将是产品需要突破的地方。单纯的信息流动并不能让企业用起来,只有让企业看到了利润才是最关键的。
另一方面,B2C的企业跑这套流程,可能也不太好使,因为C端的用户并不一定使用钉钉,不过阿里倒是可以考虑将旺旺与钉钉、微博与钉钉打通,从而解决B、C端之间的消息触达问题。但是仍然很难根本上解决消息触达的问题。所以就目前看来,谁最优机会根本上解决消息触达的问题?估计就是企业微信了。

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

小程序的出现,意味着未来企业微信也将会存在应用平台的能力,而且它的能力比我之前提到的 toB 产品框架还要强大,因为它在普通的框架上,还搭载了独特的程序框架,大大提高了体验,不像现在的H5应用那样需要实时加载。而且,因为页面可以调用小程序提供的组件,这些组件早已内置在微信客户端,它们的体验将会更加「原生」。所以我认为未来较为理想的 toB 的产品框架将会是这样:

平台除了提供带有 toB 属性的能力外,还会额外提供统一的设计、审核以及运营规范,甚至还会提供类似Swift那样的开发语言,或者类似微信小程序那样的特有语言。

不过我脑海中还有一个更加疯狂的设想,那就是...

好吧这次貌似写得有点多了,很累呀

本文由开元棋牌发布于办公软件,转载请注明出处:我理解的 toB 产品框架(三)

TAG标签:
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。