我理解的 toB 产品框架（三）

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

我理解的 toB 产品框架（一）
我理解的 toB 产品框架（二）

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

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

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

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

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

理想化的场景将会是这样的故事（举例，非实际）：

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

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

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

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

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

好吧_{这次貌似写得有点多了，很累呀}