<mark id="oztn4"></mark>
0
走標準化產品模式，還是做高度定制化解決方案？
這是RPA乃至所有To B科技公司面臨的戰略選擇。關乎估值，關乎增長。
過去五年，無數抱有做標準化平臺愿景的AI公司，在趟過數不盡的坑后，業內才終于達成共識：越重的定制化，越有機會活下去。
而隨著AI與RPA等技術的應用愈發成熟，不少傳統企業的IT基礎建設也逐步完善，“標準化”再次浮出水面。
為此，雷鋒網AI金融評論策劃了「RPA標準化」的系列選題，借同一個話題，對不同背景的受訪者、產品和客群各異的企業們進行采訪，期望在不同的商業認知下捕捉觀點碰撞的火花。
本系列選題的第一篇文章，由文因互聯CEO、聯合創始人鮑捷講述他眼中的RPA標準化命題。
同時，「RPA+AI系列公開課」也在進行當中。在本篇中接受采訪的鮑捷，將會在今晚8點（4月11日）做客雷鋒網公開課，更加深入地分享RPA從1.0到4.0時代的關鍵路徑。
以下為鮑捷的所感所想：
RPA的完全標準化是偽命題
根據多年的切身體會，我認為面向企業服務的RPA廠商，整個業務流程是很難標準化的。
如果它能標準化，To B服務早就SaaS化了。標準化服務不是RPA這種承載形式能夠提供的。
同時，在某些局部流程上又是可以標準化的，但要遵循一些特點。
第一，這個流程操作相對簡單，而且在企業里處于邊緣地位。如果一個業務的流程在企業內部處于核心地位，比如銀行的風控，是絕對不可能將它標準化的。
第二，它是國家強制性要求的、本身就比較規范的流程，比如財務報表。正因為國家有一個合規和強制的要求，使得目前的一些流程得以標準化。
否則，對于To B的RPA廠商來說，無論是需求理解環節、內部流程的構造環節、內部系統的接口環節，還是數據打通之后、生成新數據的環節，這些傳統的流程都不太可能被標準化。
我在金融領域做的業務比較多。在銀行，客戶經理要做一筆貸款，我們會將財務報表進行分析，生成財務報告，這個流程是有可能標準化的。但是如何生成財務報告，每家銀行其實不完全一樣。
定制化和標準化之間會有一個過程，在垂直行業里，需要積累很多年，通常來說你要服務幾十上百家客戶。而這個階段，你看起來非常像一個外包公司。
RPA的標準化，只有兩條出路。
一種就是做“前端”的東西，比如專門做火車票、做差旅報銷、做身份證識別、做上市公司財務報表的識別，只做一個點。公司不要把攤子鋪得太大，聚焦在一個細分領域，每年收入可能不多，不會快速地增長到很大。但是這樣能夠讓毛利率和凈利率變得很健康，變成一個小而美的企業。Uipath一開始就是小而美，頭十幾年沒怎么融資，也活下來了。國內其實也有不少這樣的公司。
另外一種最底層的知識庫管理系統也是可能標準化的。RPA也叫機器人流程自動化，所說的流程其實就是知識，是大量的業務規則，大量規則的管理就是知識庫管理系統KBMS。這個上面會出現未來的Oracle和SAP，提供標準化的底層知識計算平臺。
至于在中間的比如編輯器之類的，很難擺脫咨詢的命運，也就很難標準化了。
我之前看到有統計說，90%以上的RPA項目都失敗了。這是因為客戶的預期和RPA實際能做到的，這中間有一個巨大的Gap。客戶可能讀了很多宣傳以后，會認為上一套系統，流程立馬就可以自動化了。而實際情況并非如此。
RPA需要長時間的行業積累，才有可能逐漸的從零件化到配置化，再到標準化，它是一個漸進的過程，很難一步到位。
RPA不能標準化的原因，有哲學層面的、有系統層面的、還有實操層面的，是多方面的原因。
從哲學層面來講，最深層次的問題，RPA是一種流程自動化，是一種企業IT服務，它并不新穎，很早就有，只是在不同的時候叫不同的名字。
比如在20年前，我讀博士的時候，那時候管它叫企業數據集成，和現在RPA處理的是一樣的問題。那時候其實大家也開發了各種各樣的小工具來做，但為什么這個事情它始終就做不大？因為企業流程本身其實是一種世界觀，沒有兩個企業的世界觀是一樣的，同樣，沒有兩個企業的流程是一樣的。
在一個組織內，能夠走得通流程的方法，在另一個組織內就是走不通。比如你去比較一下釘釘、飛書這兩種同樣是做辦公軟件的團隊，你會發現他們的匯報流程、工作模式是完全不同的。
再比如說每一個企業它都有內賬外賬。
當企業做財會的流程自動化時，首先你得搞清楚，你是幫這個企業做外賬的流程自動化還是內帳的流程自動化。
如果是外賬的流程自動化，是可能做到標準化的程度的。因為國家要求企業每年到稅務局必須報這些科目，但是內帳的標準化就不可能做到，因為每個企業的內部情況都不一樣。
第二，是系統層面的原因，RPA要解決的，實際上是系統之間數據打通的問題。
一家公司內部，有的系統十年前就有，有的系統去年剛建成，有的系統即將完工，這些系統之間都沒有合適的接口連接，我們需要把這些系統之間的數據打通。但沒有兩個企業的IT系統一模一樣，系統都是由不同廠商在不同IT平臺上、不同操作系統上實現的。
所以RPA服務商要去跟不同的windows版本進行抗爭。在不同的機器上面有不同的配置，有的機器上裝殺毒軟件，它們都會給RPA的運行制造困難，然后你就會陷入bug的汪洋大海里去，和不兼容性做斗爭，RPA廠商得做非常多的補丁，才能解決這些問題。
如果是做企業RPA服務的話，那么它的核心問題其實是一個概念建模的問題，絕大多數的企業客戶自己的IT人員不具備這種建模的能力，所以你提供RPA商城也好，提供給它可視化編輯頁面也好，其實它是用不起來的。
歸根結底是因為大多數客戶沒有相應的建模能力，而不是一個界面本身好不好用的問題，還得看他這個RPA商城到底能不能把產品和服務銷售出去。客戶本來就沒有義務有概念建模的能力，這個是RPA服務商應該提供的服務。
我認為面對To C用戶的RPA商城倒是有可能成功的，比如IFTTT 之類。如果產品做到可以讓客戶不懂編程也能使用，不涉及流程編輯，而且整個流程也不涉及底層系統的對接，這樣的商城是有可能成功的。
RPA的四個階段
當前的RPA大致可以分成兩代：1.0版本是對于手的自動化，可以類比為“游戲外掛”，例如按鍵精靈；2.0版本是對眼睛和耳朵的自動化，例如目前這種搬運非結構化數據，并且自動化數據提取流程的類型。
從RPA1.0到2.0，就是自動化體力勞動，向自動化腦力勞動的轉變。
未來RPA還可能會演化到3.0版本，它將成為一個以知識庫為基礎的企業內流程化自動化管理系統。
目前行業大致在RPA2.0~3.0階段。
RPA2.0是去年年底時開始興起的，它在RPA1.0的基礎上，加上了OCR和NLP這兩種技術。
RPA1.0時代，RPA只能解決結構化數據的問題，但RPA2.0可以解決非結構化數據在應用之間轉移的問題。然而它們兩者本身還都是在做數據的轉移。
雖然RPA2.0時代，因為加上了OCR等技術，和AI進行了融合，但它的本質并沒有變。本質上RPA都是在提供一些標準件。
再往前可能還有RPA的4.0，解決企業之間的資源調度自動化，如開放銀行、供應鏈自動化等等。
今晚的分享，我主要和大家聊聊這部分，RPA 如何從1.0 演化到4.0，過程中涉及的核心技術以及實現的效果如何。
RPA本質上是咨詢
業務咨詢和RPA技術的結合，我認為這件事情肯定是成立的，而且在我看來這是一種新的商業模式。
其實我之前也一直在思考，為什么SaaS不能落地？為什么中國的To B的企業都像外包公司？
后來我想明白了，我認為在中國其實需要一種新的商業模式，我把它稱為CAAS（consulting as a service），它是在中國環境下被逼出來的一種模式。我認為國外應該還是沒有這種商業模式的，SaaS已經被接受，沒有必要讓每家服務商也具有咨詢能力，同時也存在了大量垂直的服務商可以因為自己的專業服務而收費，它可以越過這個階段。
而在中國，實施能力和咨詢能力的分離造成了一個兩極分化，咨詢和外包是兩個極端。
以前的咨詢公司只能把咨詢的結果轉化成一大堆報告，而現在的CAAS服務公司可以把咨詢的結果變成一個IT系統。
所以從這個角度來說，RPA公司和咨詢公司的合作從邏輯上是成立的，而且未來的咨詢公司一定會加強自己的RPA能力，而RPA公司一定會加強自己的咨詢能力，兩方最后甚至可能出現合并。
按照這樣的一個趨勢，兩個行業都可能產生一種顛覆性的結果。從這個角度來說我認為RPA的前途是非常美好的。
從我們當前業務流程來看，首先客戶提供資料并且跟我們說要在這些資料上面做什么樣的事情，然后我們的業務經理會跟他們一起坐下來分析具體的需求，想要實現什么效果，什么可以做到，什么無法做到，實施的效果如何等等。
這其實就是一個典型的咨詢過程，RPA服務商要懂客戶的業務并且要多一個前沿技術視角，比客戶更明白他能實現什么并且幫他做到。
雷鋒網（公眾號：AI金融評論）
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
