前文再續(xù)，書接上一回。上一篇文章跟大家分享了這一、兩年的 toB 產(chǎn)品的一個趨勢，本篇想跟大家分享下另一個趨勢。如果你沒有看過我之前的分享，可以看看：

我理解的 toB 產(chǎn)品框架（一）
我理解的 toB 產(chǎn)品框架（二）

如果說 toB 產(chǎn)品的第一個趨勢是應(yīng)用互聯(lián)，那么另外一個趨勢就是企業(yè)間的信息互聯(lián)。像傳統(tǒng)私有云的 toB 產(chǎn)品，基本上就是個信息孤島，企業(yè)信息很少流出，或者與其它企業(yè)直接交換信息。舉個例子：

你的客戶需要訂一批貨物，銷售一般會在公司的ERP或CRM系統(tǒng)錄入訂單或合同，然后走審批。該合同可能還需要快遞到你的客戶那里，然后又走一遍審批。最后完成生產(chǎn)和發(fā)貨。整個流程異常繁瑣，而且速度很慢。（這個場景已經(jīng)算是快的了，還有更長更麻煩的。）

另一方面，即使是簡單的信息觸達(dá)，可能都會很麻煩。拿釘釘做為例子：

你所在的公司在使用釘釘，內(nèi)部交流一直是使用釘釘，但是當(dāng)你需要跟你的合作伙伴、你的客戶交流時，你還是需要打開郵箱、QQ或者微信，因為你的合作方不一定在使用釘釘。

第一個場景，將會是目前 toB 平臺產(chǎn)品重點關(guān)注的切入點。即類似釘釘3.0推出的服務(wù)窗的概念。企業(yè)的外部好友（合作伙伴、客戶、甚至供應(yīng)商）都能通過這個服務(wù)窗發(fā)起訂貨、退貨甚至聯(lián)系客服等等。而這個服務(wù)窗的背后，將會是企業(yè)的ERP系統(tǒng)，甚至是企業(yè)的智能制造系統(tǒng)。其產(chǎn)品框架將會類似（A、B為不同企業(yè)）：

理想化的場景將會是這樣的故事（舉例，非實際）：

如果某經(jīng)銷商需要訂購100箱面包，該經(jīng)銷商直接在面包生產(chǎn)商那訂購，面包生產(chǎn)商收到訂購訂單后，系統(tǒng)自動進(jìn)行庫存盤點，如果發(fā)現(xiàn)貨物不足，機(jī)器自動開始生產(chǎn)。同時發(fā)現(xiàn)面粉也不夠了，會自動向上游的面粉廠訂購面粉。

這套產(chǎn)品框架貌似能跑通，但是實際上是個大坑。比如目前釘釘提供的服務(wù)窗能力對于 B2B 的企業(yè)估計就比較麻煩了，畢竟這種企業(yè)涉及的訂單金額更大，流程也更加繁瑣，人情交易也更多。如何在做到信息流動之余，還做到銷售提速，將是產(chǎn)品需要突破的地方。單純的信息流動并不能讓企業(yè)用起來，只有讓企業(yè)看到了利潤才是最關(guān)鍵的。
另一方面，B2C的企業(yè)跑這套流程，可能也不太好使，因為C端的用戶并不一定使用釘釘，不過阿里倒是可以考慮將旺旺與釘釘、微博與釘釘打通，從而解決B、C端之間的消息觸達(dá)問題。但是仍然很難根本上解決消息觸達(dá)的問題。所以就目前看來，誰最優(yōu)機(jī)會根本上解決消息觸達(dá)的問題？估計就是企業(yè)微信了。

小程序的出現(xiàn)，意味著未來企業(yè)微信也將會存在應(yīng)用平臺的能力，而且它的能力比我之前提到的 toB 產(chǎn)品框架還要強(qiáng)大，因為它在普通的框架上，還搭載了獨特的程序框架，大大提高了體驗，不像現(xiàn)在的H5應(yīng)用那樣需要實時加載。而且，因為頁面可以調(diào)用小程序提供的組件，這些組件早已內(nèi)置在微信客戶端，它們的體驗將會更加「原生」。所以我認(rèn)為未來較為理想的 toB 的產(chǎn)品框架將會是這樣：

平臺除了提供帶有 toB 屬性的能力外，還會額外提供統(tǒng)一的設(shè)計、審核以及運營規(guī)范，甚至還會提供類似Swift那樣的開發(fā)語言，或者類似微信小程序那樣的特有語言。

不過我腦海中還有一個更加瘋狂的設(shè)想，那就是...

好吧_{這次貌似寫得有點多了，很累呀}