我理解的 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 产品的一个发展趋势，还有另外一个趋势，就是...

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