2015年是SaaS和PaaS都非?;鸨钠髽I(yè)服務元年。2015年后,對于云服務而言,面對客戶,將何去何從?帶著客戶的疑問和身為行業(yè)從業(yè)者的一些經(jīng)驗,我試圖給出一點自己的想法。
觀點的碰撞和對未來趨勢的判斷,從來不乏對錯之爭。我無意介入這份紛紛擾擾,無意爭論對錯,僅是表達自己所看到的。
以下故事不針對某個具體的企業(yè),這是我們要一起背負的命題。
我所經(jīng)歷的企業(yè)服務
2000年,開啟了我企業(yè)服務的職業(yè)生涯。
站在2016年,SaaS元年后,軟件行業(yè)在天翻地覆地變化著,我接收到的客戶信息依然如十年前:你們的軟件服務交付了會減少成本和人力嗎?
SaaS交付方式的朋友很理直氣壯的說:一定會。因為,SaaS便宜;因為,SaaS按用戶實際使用情況收費;因為……
PaaS交付方式的朋友也會挺直腰桿說:會。PaaS更靈活,支撐基于業(yè)務定制還能節(jié)約成本。
自2011年9月再次以創(chuàng)業(yè)者的身份踏入企業(yè)服務領域,就開啟了“滿足客戶需求”的旅程,辛苦、委屈和無奈。曾經(jīng)部署過獨立業(yè)務的SaaS,撤掉了;原因沒錢燒。有朋友說SaaS服務很簡單,開賬號買賬號就好了;我感受到的是聽來的故事,沒有親自躬身干過就別妄言了??噙^,方知甜的滋味。
如果僅僅是沒錢燒,我們會啟動融資,會找朋友借錢或者其它的方式度過難關。相對于沒錢燒,更深刻的問題是客戶的反饋:你們的SaaS傳遞了什么價值?把曾經(jīng)給他們定制開發(fā)的軟件服務,以十分之一的價格出售,他們竟然被問及了傳遞了什么價值。這句話引發(fā)了我深深地思考。
問題一個個浮現(xiàn)出來:定制的結合了網(wǎng)站的引流,銷售SaaS沒有提供;定制的整合了OA的API接口,銷售的請假、報銷和業(yè)績能夠在同一個報表中,銷售SaaS沒有提供;……。這些沒有提供的問題解決了,銷售的SaaS就能貼合需求,好賣嗎?顯然不是。就連Salesforce也不是因為提供了各種整合才好賣的。
讀了Salesforce的創(chuàng)始人撰寫的《云攻略》。
細讀下去,發(fā)現(xiàn)的第一個問題:SaaS標準化就是一個誤區(qū),Salesforce從創(chuàng)建的第一天就開始追求不同行業(yè)客戶的不同需求滿足,根本沒有賴在標準化的“被窩里”意淫;
第二個問題:SaaS業(yè)務是交付模式的變化,不是業(yè)務結構的變化,Salesforce是通過不斷豐富自己的業(yè)務結構讓一個襁褓里的嬰兒長大的,他們的交付方式節(jié)約了客戶的使用成本;
第三個問題:和第三方系統(tǒng)的對接,Salesforce是非常主張企業(yè)內部數(shù)據(jù)似水般流動的,在PaaS系統(tǒng)上市之前先完成了SF的API化保證了系統(tǒng)對接的友好。
思考的過程我們并沒有停止對SaaS或PaaS業(yè)務的探索。2014年開始,逐漸通過API嵌入的方式提供了幾個大型企業(yè)客戶很好的體驗。
如:SAP的考勤系統(tǒng)在滿足“計件工時”的服務上是不友好的,一個35萬人的機械加工類企業(yè)找到我們定制了計件工時的系統(tǒng),我們并沒有提供自己系統(tǒng)的獨立管理入口等,而是結成到了SAP的軟件中;
又如:對于一個教育培訓連鎖機構,他們的教師上課“考勤”通過很多方案沒有解決,我們通過手機的方案解決后整合到了他們的Oracle薪酬系統(tǒng)中,并沒有提供自己的獨立管理入口;
再如:二維碼生成的系統(tǒng),我們提供了豐富的API保證和任何第三方開發(fā)語言的API對接,嵌入到了N個業(yè)務系統(tǒng)中。
云的下一站是API SaaS?
在業(yè)務實踐中,我們探索了一條不是獨立提供應用系統(tǒng),而是將系統(tǒng)嵌入客戶已有業(yè)務系統(tǒng)的方案。此時,有機構大規(guī)模報道了API SaaS。然后得知很多基于消息通訊的云RCS服務商獲得了諸多投資。在我們準備找投資的時候,一個新的問題出現(xiàn)了:客戶的付費模式無法支撐“按需付費”。
在中大型企業(yè)中的客戶軟件或者服務費用是預算制,如果沒有納入預算的費用是無法支付的?;贏PI的服務私有化部署,客戶是高度認可和接納的;一旦涉及到公有部署和按需收費,就沒有客戶可以按照此模式結算了。投資商對私有化部署是不認可的。
SaaS主要面向中小型客戶,他們有足夠的數(shù)量,這也是投資商喜歡的邏輯。在API化的應用面前,中小企業(yè)的接受度是極低的。首先,中小企業(yè)的采購環(huán)節(jié)很短,他們喜歡體驗操作后直接下單購買,API的應用是無法直觀體驗的;即便是做了直觀體驗,在實際采購的時候,他們采購的操作層面的“定制”服務,這個成本(時間和資金)都不是中小企業(yè)愿意的。
準備將原有應用系統(tǒng)通過API化提供服務融資方案就此否決了。依然面向大客戶,自己有收入就很好了。在今天我們交付的客戶中,也在APP端集成了美洽的客服API,客戶的客服中心、運營服務人員直接和他們的用戶在APP端進行了業(yè)務的交流。
計算能力的支撐在API化以后遇到了問題??蛻魰⒁粋€API系統(tǒng)“主動”嵌入到需求的系統(tǒng)中,然后服務器無法支撐了。第一次接到這種情況的電話,我就認為了Docker是解決這個問題的最優(yōu)方案。后來和華為的Docker項目負責人俞小濤在一次會議上深入聊了這個問題,他分析后強烈建議合作。我們似乎找到了合適的解決用戶私有化部署遷移到公有云的方案。不過由于部分原因這個合作還沒有開始。
基本的假設是客戶的私有化部署無法解決計算能力自動增量擴充的問題,我們將API應用的計算能力遷移到公有云,客戶通過租賃公有云+應用的模式付費,數(shù)據(jù)通過備份方案或者存儲方案部署到客戶本地。根據(jù)客戶獲取計算能力的值收費。
沒有了界面的支撐,在小企業(yè)和中小型企業(yè)銷售方面確實遇到了巨大的阻力;也突然了API SaaS的優(yōu)勢:非常好的契合了用戶的使用場景。將服務能力體現(xiàn)淋漓盡致的同時維護了企業(yè)服務各類角色的利益關系。
對于企業(yè)客戶而言:滿足需求和業(yè)務場景、省錢和在2-3年不落伍,這是對企業(yè)軟件服務的基本需求。API化的應用服務很好地滿足了這個特征。
API SaaS已經(jīng)有了這個名詞。這是好事兒!我在過去的兩年逐漸體會到了API SaaS帶來的巨大價值和優(yōu)勢,這是我們喜歡的領域。
在SaaS熱度以后,是否就是API SaaS,我不知道。云的下一步在哪里?我堅信,做好自己現(xiàn)在的未來就在哪里。創(chuàng)業(yè)是一次修行!