走標準化產(chǎn)品模式，還是做高度定制化解決方案？

這是RPA乃至所有To B科技公司面臨的戰(zhàn)略選擇。關(guān)乎估值，關(guān)乎增長。

過去五年，無數(shù)抱有做標準化平臺愿景的AI公司，在趟過數(shù)不盡的坑后，業(yè)內(nèi)才終于達成共識：越重的定制化，越有機會活下去。

而隨著AI與RPA等技術(shù)的應(yīng)用愈發(fā)成熟，不少傳統(tǒng)企業(yè)的IT基礎(chǔ)建設(shè)也逐步完善，“標準化”再次浮出水面。

為此，雷鋒網(wǎng)AI金融評論策劃了「RPA標準化」的系列選題，借同一個話題，對不同背景的受訪者、產(chǎn)品和客群各異的企業(yè)們進行采訪，期望在不同的商業(yè)認知下捕捉觀點碰撞的火花。

本系列選題的第一篇文章，由文因互聯(lián)CEO、聯(lián)合創(chuàng)始人鮑捷講述他眼中的RPA標準化命題。

同時，「RPA+AI系列公開課」也在進行當中。在本篇中接受采訪的鮑捷，將會在今晚8點（4月11日）做客雷鋒網(wǎng)公開課，更加深入地分享RPA從1.0到4.0時代的關(guān)鍵路徑。

以下為鮑捷的所感所想：

RPA的完全標準化是偽命題

根據(jù)多年的切身體會，我認為面向企業(yè)服務(wù)的RPA廠商，整個業(yè)務(wù)流程是很難標準化的。

如果它能標準化，To B服務(wù)早就SaaS化了。標準化服務(wù)不是RPA這種承載形式能夠提供的。

同時，在某些局部流程上又是可以標準化的，但要遵循一些特點。

• 第一，這個流程操作相對簡單，而且在企業(yè)里處于邊緣地位。如果一個業(yè)務(wù)的流程在企業(yè)內(nèi)部處于核心地位，比如銀行的風(fēng)控，是絕對不可能將它標準化的。

• 第二，它是國家強制性要求的、本身就比較規(guī)范的流程，比如財務(wù)報表。正因為國家有一個合規(guī)和強制的要求，使得目前的一些流程得以標準化。

否則，對于To B的RPA廠商來說，無論是需求理解環(huán)節(jié)、內(nèi)部流程的構(gòu)造環(huán)節(jié)、內(nèi)部系統(tǒng)的接口環(huán)節(jié)，還是數(shù)據(jù)打通之后、生成新數(shù)據(jù)的環(huán)節(jié)，這些傳統(tǒng)的流程都不太可能被標準化。

我在金融領(lǐng)域做的業(yè)務(wù)比較多。在銀行，客戶經(jīng)理要做一筆貸款，我們會將財務(wù)報表進行分析，生成財務(wù)報告，這個流程是有可能標準化的。但是如何生成財務(wù)報告，每家銀行其實不完全一樣。

定制化和標準化之間會有一個過程，在垂直行業(yè)里，需要積累很多年，通常來說你要服務(wù)幾十上百家客戶。而這個階段，你看起來非常像一個外包公司。

RPA的標準化，只有兩條出路。

一種就是做“前端”的東西，比如專門做火車票、做差旅報銷、做身份證識別、做上市公司財務(wù)報表的識別，只做一個點。公司不要把攤子鋪得太大，聚焦在一個細分領(lǐng)域，每年收入可能不多，不會快速地增長到很大。但是這樣能夠讓毛利率和凈利率變得很健康，變成一個小而美的企業(yè)。Uipath一開始就是小而美，頭十幾年沒怎么融資，也活下來了。國內(nèi)其實也有不少這樣的公司。

另外一種最底層的知識庫管理系統(tǒng)也是可能標準化的。RPA也叫機器人流程自動化，所說的流程其實就是知識，是大量的業(yè)務(wù)規(guī)則，大量規(guī)則的管理就是知識庫管理系統(tǒng)KBMS。這個上面會出現(xiàn)未來的Oracle和SAP，提供標準化的底層知識計算平臺。

至于在中間的比如編輯器之類的，很難擺脫咨詢的命運，也就很難標準化了。

我之前看到有統(tǒng)計說，90%以上的RPA項目都失敗了。這是因為客戶的預(yù)期和RPA實際能做到的，這中間有一個巨大的Gap?？蛻艨赡茏x了很多宣傳以后，會認為上一套系統(tǒng)，流程立馬就可以自動化了。而實際情況并非如此。

RPA需要長時間的行業(yè)積累，才有可能逐漸的從零件化到配置化，再到標準化，它是一個漸進的過程，很難一步到位。

RPA不能標準化的原因，有哲學(xué)層面的、有系統(tǒng)層面的、還有實操層面的，是多方面的原因。

從哲學(xué)層面來講，最深層次的問題，RPA是一種流程自動化，是一種企業(yè)IT服務(wù)，它并不新穎，很早就有，只是在不同的時候叫不同的名字。

比如在20年前，我讀博士的時候，那時候管它叫企業(yè)數(shù)據(jù)集成，和現(xiàn)在RPA處理的是一樣的問題。那時候其實大家也開發(fā)了各種各樣的小工具來做，但為什么這個事情它始終就做不大？因為企業(yè)流程本身其實是一種世界觀，沒有兩個企業(yè)的世界觀是一樣的，同樣，沒有兩個企業(yè)的流程是一樣的。

在一個組織內(nèi)，能夠走得通流程的方法，在另一個組織內(nèi)就是走不通。比如你去比較一下釘釘、飛書這兩種同樣是做辦公軟件的團隊，你會發(fā)現(xiàn)他們的匯報流程、工作模式是完全不同的。

再比如說每一個企業(yè)它都有內(nèi)賬外賬。

當企業(yè)做財會的流程自動化時，首先你得搞清楚，你是幫這個企業(yè)做外賬的流程自動化還是內(nèi)帳的流程自動化。

如果是外賬的流程自動化，是可能做到標準化的程度的。因為國家要求企業(yè)每年到稅務(wù)局必須報這些科目，但是內(nèi)帳的標準化就不可能做到，因為每個企業(yè)的內(nèi)部情況都不一樣。

第二，是系統(tǒng)層面的原因，RPA要解決的，實際上是系統(tǒng)之間數(shù)據(jù)打通的問題。

一家公司內(nèi)部，有的系統(tǒng)十年前就有，有的系統(tǒng)去年剛建成，有的系統(tǒng)即將完工，這些系統(tǒng)之間都沒有合適的接口連接，我們需要把這些系統(tǒng)之間的數(shù)據(jù)打通。但沒有兩個企業(yè)的IT系統(tǒng)一模一樣，系統(tǒng)都是由不同廠商在不同IT平臺上、不同操作系統(tǒng)上實現(xiàn)的。

所以RPA服務(wù)商要去跟不同的windows版本進行抗爭。在不同的機器上面有不同的配置，有的機器上裝殺毒軟件，它們都會給RPA的運行制造困難，然后你就會陷入bug的汪洋大海里去，和不兼容性做斗爭，RPA廠商得做非常多的補丁，才能解決這些問題。

如果是做企業(yè)RPA服務(wù)的話，那么它的核心問題其實是一個概念建模的問題，絕大多數(shù)的企業(yè)客戶自己的IT人員不具備這種建模的能力，所以你提供RPA商城也好，提供給它可視化編輯頁面也好，其實它是用不起來的。

歸根結(jié)底是因為大多數(shù)客戶沒有相應(yīng)的建模能力，而不是一個界面本身好不好用的問題，還得看他這個RPA商城到底能不能把產(chǎn)品和服務(wù)銷售出去。客戶本來就沒有義務(wù)有概念建模的能力，這個是RPA服務(wù)商應(yīng)該提供的服務(wù)。

我認為面對To C用戶的RPA商城倒是有可能成功的，比如IFTTT 之類。如果產(chǎn)品做到可以讓客戶不懂編程也能使用，不涉及流程編輯，而且整個流程也不涉及底層系統(tǒng)的對接，這樣的商城是有可能成功的。

RPA的四個階段

當前的RPA大致可以分成兩代：1.0版本是對于手的自動化，可以類比為“游戲外掛”，例如按鍵精靈；2.0版本是對眼睛和耳朵的自動化，例如目前這種搬運非結(jié)構(gòu)化數(shù)據(jù)，并且自動化數(shù)據(jù)提取流程的類型。

從RPA1.0到2.0，就是自動化體力勞動，向自動化腦力勞動的轉(zhuǎn)變。

未來RPA還可能會演化到3.0版本，它將成為一個以知識庫為基礎(chǔ)的企業(yè)內(nèi)流程化自動化管理系統(tǒng)。

目前行業(yè)大致在RPA2.0~3.0階段。

RPA2.0是去年年底時開始興起的，它在RPA1.0的基礎(chǔ)上，加上了OCR和NLP這兩種技術(shù)。

RPA1.0時代，RPA只能解決結(jié)構(gòu)化數(shù)據(jù)的問題，但RPA2.0可以解決非結(jié)構(gòu)化數(shù)據(jù)在應(yīng)用之間轉(zhuǎn)移的問題。然而它們兩者本身還都是在做數(shù)據(jù)的轉(zhuǎn)移。

雖然RPA2.0時代，因為加上了OCR等技術(shù)，和AI進行了融合，但它的本質(zhì)并沒有變。本質(zhì)上RPA都是在提供一些標準件。

再往前可能還有RPA的4.0，解決企業(yè)之間的資源調(diào)度自動化，如開放銀行、供應(yīng)鏈自動化等等。

今晚的分享，我主要和大家聊聊這部分，RPA 如何從1.0 演化到4.0，過程中涉及的核心技術(shù)以及實現(xiàn)的效果如何。

RPA本質(zhì)上是咨詢

業(yè)務(wù)咨詢和RPA技術(shù)的結(jié)合，我認為這件事情肯定是成立的，而且在我看來這是一種新的商業(yè)模式。

其實我之前也一直在思考，為什么SaaS不能落地？為什么中國的To B的企業(yè)都像外包公司？

后來我想明白了，我認為在中國其實需要一種新的商業(yè)模式，我把它稱為CAAS（consulting as a service），它是在中國環(huán)境下被逼出來的一種模式。我認為國外應(yīng)該還是沒有這種商業(yè)模式的，SaaS已經(jīng)被接受，沒有必要讓每家服務(wù)商也具有咨詢能力，同時也存在了大量垂直的服務(wù)商可以因為自己的專業(yè)服務(wù)而收費，它可以越過這個階段。

而在中國，實施能力和咨詢能力的分離造成了一個兩極分化，咨詢和外包是兩個極端。

以前的咨詢公司只能把咨詢的結(jié)果轉(zhuǎn)化成一大堆報告，而現(xiàn)在的CAAS服務(wù)公司可以把咨詢的結(jié)果變成一個IT系統(tǒng)。

所以從這個角度來說，RPA公司和咨詢公司的合作從邏輯上是成立的，而且未來的咨詢公司一定會加強自己的RPA能力，而RPA公司一定會加強自己的咨詢能力，兩方最后甚至可能出現(xiàn)合并。

按照這樣的一個趨勢，兩個行業(yè)都可能產(chǎn)生一種顛覆性的結(jié)果。從這個角度來說我認為RPA的前途是非常美好的。

從我們當前業(yè)務(wù)流程來看，首先客戶提供資料并且跟我們說要在這些資料上面做什么樣的事情，然后我們的業(yè)務(wù)經(jīng)理會跟他們一起坐下來分析具體的需求，想要實現(xiàn)什么效果，什么可以做到，什么無法做到，實施的效果如何等等。

這其實就是一個典型的咨詢過程，RPA服務(wù)商要懂客戶的業(yè)務(wù)并且要多一個前沿技術(shù)視角，比客戶更明白他能實現(xiàn)什么并且?guī)退龅健?/strong>

雷鋒網(wǎng)（公眾號：AI金融評論）

雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。