SaaS：關(guān)于數(shù)據(jù)應(yīng)用的三大疑問和解答

打投資焦點轉(zhuǎn)向企業(yè)服務(wù)領(lǐng)域之后，出現(xiàn)了很多關(guān)于SaaS的討論。其實這個問題至少十幾年以前就在業(yè)內(nèi)爭論過?，F(xiàn)在很多的關(guān)于SaaS的討論還是集中在商業(yè)模式創(chuàng)新上，甚至還扯到是不是只有基于公有云才算“正宗”SaaS。可事實上，這幾年來，以Salesforce為代表的SaaS公司自然是做得不錯，而以SAP為代表的“傳統(tǒng)”企業(yè)軟件廠商也還是活得挺滋潤。這不是軟件形態(tài)和商業(yè)模式孰對孰錯的問題，其本質(zhì)還是新的產(chǎn)品和服務(wù)能否滿足新興業(yè)務(wù)場景的問題。

我曾和Salesforce的研發(fā)高管在美國做了深入交流。Salesforce和SAP CRM 的核心用戶都是大中型企業(yè)。2015年，Salesforce收入的80%來自于不到2%的客戶，這些大客戶同樣需要不短的銷售周期和不小的定制化。但Salesforce以SAP沒有做好的產(chǎn)品作為切入點，同樣取得了成功。可是，最近Salesforce又為什么要收購Demandware呢？Demandware并不是一家符合流行的SaaS定義的公司，既不是真正的Multi-Tenant，也沒有PaaS。這難道意味著SaaS潮流的倒退？

讓我們在爭論商業(yè)模式創(chuàng)新（SaaS與否）的同時，不妨從產(chǎn)品和技術(shù)創(chuàng)新的角度來看看目前企業(yè)服務(wù)市場所面臨的變局。

這幾年新興起的有影響力的眾多企業(yè)技術(shù)服務(wù)公司中，如果從產(chǎn)品角度看，我覺得可以分成兩類。一類是把傳統(tǒng)廠商沒有做好的事情，利用新技術(shù)、新用戶體驗把產(chǎn)品做好，以滿足客戶需求并取得成功的，如CRM；另一類就是隨著企業(yè)經(jīng)營環(huán)境、業(yè)務(wù)模式的變化帶來的新需求，如數(shù)據(jù)分析、數(shù)據(jù)驅(qū)動型應(yīng)用。

第一類產(chǎn)品自不必多說。這里我花點篇幅分析一下第二類產(chǎn)品，因為這涉及到對趨勢的判斷。

過去幾十年來，企業(yè)軟件基本上都是在強調(diào)“管理”。大家耳熟能詳?shù)模还苁瞧髽I(yè)資源管理、辦公自動化、分銷管理，還是簡單的進銷存軟件，都是圍繞著流程管理展開的。而在這些流程性業(yè)務(wù)系統(tǒng)中流轉(zhuǎn)的，都是“單據(jù)（Document）“。大到“Order to Cash“， 小到一個“公文會簽“流程，都是圍繞著若干個Documents進行的。即使這幾年提出來的C2B， C2M等等，大家的關(guān)注點還是在單據(jù)的流轉(zhuǎn)。說“單據(jù)”好像有點low，可是本質(zhì)上不就是把原來紙質(zhì)的單據(jù)電子化了，然后通過計算機系統(tǒng)（加上后來的網(wǎng)絡(luò)），在不同崗位間傳遞。這好像看著有點眼熟，是不是很象上世紀(jì)80到90年代的一個高頻詞：電算化？

誠然，現(xiàn)在還有不少企業(yè)可能連這一點“電算化”都沒有做到，但這也恰恰是互聯(lián)網(wǎng)技術(shù)首先能夠幫助企業(yè)解決的?；ヂ?lián)網(wǎng)的強大“連接”能力，極盡方便又近乎免費。各種廣義的“通信工具”，讓企業(yè)可以無需自建系統(tǒng)，就完成單據(jù)的流轉(zhuǎn)。這也是為什么今天的微信和釘釘會對一些簡單的傳統(tǒng)企業(yè)軟件帶來最直接的沖擊的原因。

而除了OA等系統(tǒng)之外，現(xiàn)代的企業(yè)還需要會員管理、營銷管理、物流管理和商品管理。和銷售訂單管理、采購訂單管理以及發(fā)票管理等不同的是，會員、商品、物流、營銷等的管理必然是基于數(shù)據(jù)的管理。很難想象，一次營銷活動是基于某個單據(jù)或指令的。而物流也應(yīng)該是基于全網(wǎng)、全渠道的實時庫存和動態(tài)銷售情況，來達成全公司整體利益的優(yōu)化，而不是物流部門自身費用的局部優(yōu)化。商品的企劃、試銷、改款、鋪貨和補貨，在全渠道經(jīng)營業(yè)務(wù)場景下，無一不需要全網(wǎng)的數(shù)據(jù)支撐，而且數(shù)據(jù)反饋一定要及時。所以，在這樣的經(jīng)營模式中，部門和部門之間，公司和公司之間，都已經(jīng)不再是簡單地基于流程、單據(jù)或指令的協(xié)作，而必然是基于數(shù)據(jù)的協(xié)作。

這是一個從基于流程的商務(wù)協(xié)作，向基于數(shù)據(jù)的商務(wù)協(xié)作轉(zhuǎn)型的時代。這是互聯(lián)網(wǎng)普及后，倒逼企業(yè)去做全網(wǎng)、全渠道經(jīng)營時所推動的轉(zhuǎn)型。新興的業(yè)務(wù)場景尋求新的企業(yè)產(chǎn)品和服務(wù)。

這樣的數(shù)據(jù)驅(qū)動的商務(wù)協(xié)作模式，其實早已拉開序幕。做數(shù)字化營銷時，廣告主和廣告商之間不就是基于數(shù)據(jù)的協(xié)同么？教小孩子畫畫和教舞蹈的商家之間的異業(yè)聯(lián)盟，不就是基于數(shù)據(jù)的協(xié)同么？

有了數(shù)據(jù)的驅(qū)動，原有的流程性業(yè)務(wù)系統(tǒng)才擺脫了簡單的“執(zhí)行“角色，才變得開始有了”智能“。由此，企業(yè)信息系統(tǒng)才從“電算化”進化到“數(shù)據(jù)化”及“智能化”。這樣的進化，不管對企業(yè)本身，還是對技術(shù)服務(wù)商而言，都不是一件容易的事情，絲毫不亞于當(dāng)年ERP興起的時候帶來的沖擊。也正是因此，才創(chuàng)造出一個巨大的市場空間。

過去幾年中，基于對這個趨勢的預(yù)判，對基于數(shù)據(jù)的商務(wù)協(xié)作技術(shù)，我和很多客戶及同行一起有過很多的交流和實踐。從中，我大致歸納了以下三個方面的問題：

一、數(shù)據(jù)在哪里？

企業(yè)在經(jīng)營活動中自然產(chǎn)生很多數(shù)據(jù)，包括ERP、WMS、CRM等業(yè)務(wù)系統(tǒng)中流轉(zhuǎn)的單據(jù)，當(dāng)然線上業(yè)務(wù)產(chǎn)生的數(shù)據(jù)更多（瀏覽、點擊、收藏夾、購物車、評論等）。還有一類數(shù)據(jù)不是在自己的經(jīng)營活動中產(chǎn)生的，而是從外部數(shù)據(jù)平臺“買”來的，如第三方數(shù)據(jù)平臺以及外來的流量。

這幾年，出現(xiàn)很多很好的產(chǎn)品，可以幫助企業(yè)去抓取數(shù)據(jù)，特別是線上數(shù)據(jù)的采集的技術(shù)門檻大大降低。線下數(shù)據(jù)的抓取也有很多新技術(shù)在持續(xù)推動，包括WiFi，iBeacon，RFID，視頻識別等等。

可惜的是，這些數(shù)據(jù)要么是在各個孤立的業(yè)務(wù)系統(tǒng)中，在完成流程處理的使命之后就在數(shù)據(jù)庫里睡大覺（特別是ERP）；要么就是用了之后就沒有留存下來，如“買”來的流量，成為“一次性數(shù)據(jù)”。

與此同時，很多企業(yè)在前些年花了不少錢，買了大量服務(wù)器和網(wǎng)絡(luò)設(shè)備，建設(shè)了所謂的企業(yè)“數(shù)據(jù)中心”?？墒?，我相信，實際上包括這些企業(yè)自己的IT部門在內(nèi)，往往還是習(xí)慣性地稱其為“機房”。這，才是真相：這個“數(shù)據(jù)中心”只是一個物理上的中心，把服務(wù)器設(shè)備放在一起，讓領(lǐng)導(dǎo)看得見，安心而已。

而企業(yè)需要的是一個真正的數(shù)據(jù)中心，把分散在各個系統(tǒng)中的數(shù)據(jù)整合起來。不僅僅是要消除各個業(yè)務(wù)系統(tǒng)之間的流程孤島，更要消除數(shù)據(jù)孤島。

而隨著各種新業(yè)務(wù)“觸點“和“端”的不斷增加，數(shù)據(jù)量和計算量都是飛速增長的。比如，一個門店每天通過WiFi、RFID等設(shè)備采集的客流和試衣數(shù)據(jù)就可達到幾十萬條?？倲?shù)據(jù)量比交易數(shù)據(jù)高至少3-4個數(shù)量級。因此，企業(yè)數(shù)據(jù)中心要有能力高并發(fā)地接收海量數(shù)據(jù)。同時，通過即插即用的數(shù)據(jù)對接能力，把來自外部的數(shù)據(jù)也留存在數(shù)據(jù)中心。數(shù)據(jù)中心還要能實時加工，完成數(shù)據(jù)的清洗、拼接等工作，才能為其它的應(yīng)用所用。

這一切，對于傳統(tǒng)的基于交易事務(wù)的軟件系統(tǒng)架構(gòu)來說，改動代價極高，風(fēng)險很大。

二、數(shù)據(jù)怎么看？

企業(yè)應(yīng)用離不開圖表。經(jīng)常有客戶提出要我們定制幾個報表或圖表。我都會先追問一下，這個圖表用以解決什么問題？絕大部分情況下，圖表是用來幫助決策的，圖表的終極目標(biāo)是直接形成決策建議甚至業(yè)務(wù)指令。所以，數(shù)據(jù)不是用來看的，而是要“用“的。有興趣的，不妨去看看Tableau的股價走勢，我的看法是，數(shù)據(jù)光看不用，沒用。

三、數(shù)據(jù)怎么用？

數(shù)據(jù)本身沒有價值，只有用到了才體現(xiàn)其價值，而且，一定是“數(shù)到用時方恨少”。數(shù)據(jù)的應(yīng)用價值，是通過數(shù)據(jù)的流通和應(yīng)用輸出能力來體現(xiàn)的，即數(shù)據(jù)應(yīng)用（Data App）。

比較常見的數(shù)據(jù)應(yīng)用場景之一是廣告營銷?，F(xiàn)在有了數(shù)據(jù)中心以后，可以讓精準(zhǔn)的營銷能力延伸到每個觸點。比如，讓每個導(dǎo)購員通過數(shù)據(jù)中心獲取會員的完整知識圖譜，將該會員分散在各個系統(tǒng)中的事件、行為序列等雜亂的信息整理出來，以便于瀏覽和使用的方式推送給導(dǎo)購員。導(dǎo)購員就從“單兵”變成了擁有全方位戰(zhàn)場情報支持的“特種兵”。

而更深層次的數(shù)據(jù)應(yīng)用場景，是通過數(shù)據(jù)中心和流程中心的耦合形成的閉環(huán)應(yīng)用。并且，根據(jù)數(shù)據(jù)中心獨立于流程中心的特點，這類數(shù)據(jù)應(yīng)用可以通過數(shù)據(jù)的全流通，實現(xiàn)跨流程節(jié)點的實時聯(lián)動和全局優(yōu)化。

例如，在全渠道經(jīng)營模式下，當(dāng)線上訂單蜂擁而至，倉庫不堪重負的時候，通過對訂單的地址、商品需求數(shù)據(jù)與門店庫存、門店位置、客流量、動銷率等實時數(shù)據(jù)的分析與整合匹配，再結(jié)合來自于客服中心以及社交媒體的該消費者的數(shù)據(jù)，可能在原訂單中添加和該消費者權(quán)益有關(guān)的服務(wù)項目之后，訂單再被快速分配到最合適（不一定是最近）的門店進行打包，并同時通知快遞公司進行派送。對于商家來說，倉庫配送壓力大大減輕了，門店空閑時刻的人力被利用起來，整體資源利用效率得到提高；對于消費者來說，配送的效率提高了，還得到了一致的會員權(quán)益服務(wù)，品牌消費體驗自然也得到了提升。在這個例子中，基于數(shù)據(jù)中心的全渠道OMS系統(tǒng)就是一個數(shù)據(jù)應(yīng)用，能夠綜合源自各個業(yè)務(wù)系統(tǒng)的數(shù)據(jù)，做出全局優(yōu)化的決策，并通過發(fā)出指令到相應(yīng)的業(yè)務(wù)系統(tǒng)（零售POS、TMS）去執(zhí)行流程。這是數(shù)據(jù)中心和流程中心之間的一個閉環(huán)應(yīng)用。

這樣的數(shù)據(jù)應(yīng)用場景還存在于配送中心。例如，把零售分銷系統(tǒng)中所有門店的實時銷售和客流數(shù)據(jù)，反饋給在路上行駛并承擔(dān)區(qū)域配送中心（RDC）角色的物流車，達到快速動態(tài)調(diào)整庫存的目的。據(jù)我所知，一家著名服裝品牌公司已經(jīng)在這方面取得顯著的效果。

即使在營銷方面，我們還可以把傳統(tǒng)的DSP廣告投放，通過和企業(yè)自有數(shù)據(jù)中心的DMP、全渠道OMS的結(jié)合，形成從會員分層、廣告投放、展現(xiàn)效果到交易轉(zhuǎn)化的完整閉環(huán)，并根據(jù)各渠道量化指標(biāo)動態(tài)調(diào)整渠道投放策略。

類似的數(shù)據(jù)中心結(jié)合流程中心的閉環(huán)應(yīng)用場景還有很多。有了數(shù)據(jù)中心的驅(qū)動，企業(yè)的業(yè)務(wù)系統(tǒng)才可以變得有智能。數(shù)據(jù)中心是企業(yè)運營真正的大腦，而流程性業(yè)務(wù)系統(tǒng)是五官和四肢。

說完數(shù)據(jù)中心，再回到本文開頭的問題。作為SaaS企業(yè)的代表，Salesforce為什么要收購Demandware呢？因為Salesforce需要Demandware這樣的業(yè)務(wù)流程系統(tǒng)，通過CRM和OMS系統(tǒng)的后臺整合，形成一個兼具數(shù)據(jù)中心和流程中心的大后臺。SAP這幾年也頻頻收購公司，也是為了進一步增強后臺系統(tǒng)，結(jié)合投入多年研發(fā)的新數(shù)據(jù)庫平臺，提供整合的產(chǎn)品。不同廠商之間的系統(tǒng)打通不是件容易的事情，看看當(dāng)年IBM、SAP大力倡導(dǎo)的SOA架構(gòu)有沒有真正起作用就會知道，歷史總是有相似之處的。不同SaaS之間的整合打通也面臨同樣的問題。而企業(yè)用戶恰恰不喜歡面對一堆碎片化的云應(yīng)用。企業(yè)是需要用于不同業(yè)務(wù)場景的多個應(yīng)用，但是這些應(yīng)用應(yīng)該是基于一個大平臺。所謂，“大平臺，小應(yīng)用”，才能確保企業(yè)應(yīng)用的延展性和一致性。

所以，企業(yè)要轉(zhuǎn)型數(shù)據(jù)驅(qū)動的管理模式，需要的是一個盡量整合的系統(tǒng)，讓數(shù)據(jù)中心和流程中心之間可以更方便地打造更多閉環(huán)應(yīng)用場景。而這樣的系統(tǒng)不可避免會有定制工作，包括行業(yè)特性以及特定客戶的。對于企業(yè)服務(wù)領(lǐng)域的新創(chuàng)公司，必須要走產(chǎn)品化道路，就要控制定制化所占的比例在30%以下。而要達到這個目標(biāo)，必須依托一套標(biāo)準(zhǔn)化技術(shù)和開發(fā)平臺。這個技術(shù)平臺本身就是一個門檻。好在也沒有必要非得一開始就把這個技術(shù)平臺當(dāng)做“PaaS”開放出去。一來，一旦開放了，就束縛了革新的手腳，要知道把接口定義清楚也是一門技術(shù)活；二來，新公司也沒那么快具有公信力，讓別人愿意在這個平臺上開發(fā)應(yīng)用。Salesforce也是推出第一個CRM之后，過了6年之久才開放Force.com作為開發(fā)平臺的。所以，我們選擇的道路是：要打造PaaS，但先僅供內(nèi)部使用，要求所有產(chǎn)品功能的開發(fā)都基于這個PaaS；同時，聯(lián)合一家有技術(shù)能力的行業(yè)龍頭企業(yè)，和我們共同開發(fā)基于此PaaS的行業(yè)應(yīng)用。藉此，我們既不盲目背上太早開放PaaS的包袱，又能通過上層的應(yīng)用加速倒逼PaaS的形成。

猶記得，當(dāng)年很多論調(diào)，稱B/S架構(gòu)比C/S架構(gòu)先進，代表著“未來”?？扇缃襁€不是Web和App應(yīng)用并存么？所以，起決定因素的還是產(chǎn)品本身的創(chuàng)新點是否符合這個增長的市場趨勢，滿足新興的企業(yè)業(yè)務(wù)場景。而SaaS模式是商務(wù)上的助推器；云計算的特點也恰恰天然地符合企業(yè)對數(shù)據(jù)中心的需求。

“在云端用人工智能的方式處理大數(shù)據(jù)“，馬化騰先生不是隨便說說的。