亂寫RPA

要寫在前面的是，企業上RPA是一個大趨勢。我仍然十分看好RPA的將來。

只是一直以來的RPA從業生涯中，遇到了種種問題和困惑。

在這裏想到哪寫到哪。

只求達意，不拘文法。

 

RPA的目標是降本增效，但實際項目中經常變成增本增效的結果。

首先說增效。
它毫無疑問提升了企業員工的能效。
其它條件相同的前提下，具有RPA能力的企業確定能夠處理更多的工做。
但問題是，將一樣的資源投入到其它的技術提高中，是否能產生同樣多甚至更多的能效？在這個問題上，企業每每有本身的評估和衡量，進而致使企業其實有不少選擇。
我能不能二次開發SAP，Oracle，金蝶，用友呢？
我能不能上Python，VBA，甚至更原始的批處理呢？
我能不能上BPM，或者改用SaaS平臺呢？
工做方式的改變，有時帶來的不是量的提高，而是質的飛越。這種狀況下，RPA是否仍是企業的首選？
其實UiPath也好，AA也好，官方培訓內容其實已經說明了，在沒有其它流程優化手段的狀況下，才應該最終考慮上RPA。
問題就在於，許多實施商是直接衝着RPA去的，就是經常說的「爲了RPA而RPA」，流程優化反而沒有很好地考慮。
這就形成，應該讓企業質變的時候，不恰當的RPA卻讓企業進行量變，反而拖慢了質變的時機。

另外一方面，RPA機器人經常並未全負荷運行，這致使了算力的浪費。
4核，8核，甚至16核的CPU，8G，16G，32G，甚至64G的內存，機器人能用到的有多少計算資源？
一天24個小時，機器有效處理工做任務用了多少時間？那麼空餘的算力和時間，則全是浪費的成本。
也就是說做爲計算機它本該處理更多事務，可是做爲RPA機器人，反而下降了它能夠處理的事務量。
從這個角度看，是否應該說它增效了呢？

還有的時候RPA只能讓人輕鬆一點，卻未必效率更高。
由於機器處理事務與人工處理事務的邏輯未必徹底一致，也沒有必要徹底一致。
而這些差別的環節，一般會讓機器比人類更快，偶爾會讓機器比人類更慢。
不過即使機器比人慢，但咱們省了人力，就仍是有人願意投入。
有時候是由於企業看重的點並不是機器人的快慢。
有時候是咱們能夠經過簡單堆加更多機器，來解決處理速度比人類慢的問題。
畢竟堆機器比堆人要快得多。

假設它是增效的，但這不能表明降本。
RPA經常沒法如預期地那樣減小必要的員工數量。
不多人的工做能夠徹底被機器替代的。
並且RPA目前廣泛應用粗淺，軟件自己的整體購買和長期使用成本未必比人工便宜。
中國不像歐美日本，有許多企業人工很便宜。
便宜到什麼程度呢？總裁一個不高興，能夠把副總裁如下的全部人員所有砍掉從新招。
這種狀況下，RPA只是無關緊要的錦上添花，對企業來講尚未起到很是重大的影響。

並且RPA長期使用，還有很多的運維成本。
不管是本身家的IT負責維護，仍是請乙方公司來運維，都存在直接或者間接的運維成本。
因此一般那些已知6個月內界面將發生較大變化的應用，不建議經過RPA來實現自動化。
RPA的客戶端一般對軟硬件要求較低，可是服務器端就有相對較高的要求。配服務器不用錢？
並且RPA工具自己數據處理能力相對薄弱，只要有數據處理的場景基本上都須要引入數據庫，這有可能帶來額外的成本。
另外經常用到的高精度OCR，有些項目會有專用的USB Hub/Server等等，這些都有額外的成本。
這些成本不歸廠商管，因此廠商不會跟你講，也不須要跟你講。
可是你不投入又上不了RPA。
這就是矛盾。
這不是降本，而是增本。
這讓RPA究竟是降本增效，仍是增本增效，變得複雜起來。

那麼往客戶這邊推RPA就比較困難，經常面臨諸多問題。
首先是前面說起的人力成本，原本就很低，這樣的話RPA的性價比就不那麼明顯。
RPA主要是針對那些有規則的，重複度高的人工操做。
可是你想，作這些工做的人，是什麼水平的人？
這種水平的人，日常能領多少薪水？
你砍掉這我的頭，可能並不能省下多少錢。
固然了，有的人會強調RPA不僅是省錢這一個好處，它整年無休，不會出錯。。。
可是企業並不老是介意這些好處。
畢竟本來作這些工做的人，雖然一天只工做8小時，還要雙休和各類假期，還要交五險一金。但反正薪資不高，企業原本就已經能夠忍受甚至接受。
那企業爲啥沒事動這些人呢，吃飽了撐的？
人類天性如此，很難主動歡迎變化。
就算人工處理事務出錯了，形成的損失未必很大，甚至企業根本無所謂。
這時候你強調那些不能帶來直接經濟效益的方面，企業真的會謝謝你嗎？
說到底累計節省的FTE要很高，才能產生效益。
基本上要比官方課程推薦的要高不少才行。

RPA行業的生存空間也面臨來自多方面的擠壓。
有些企業自身也有必定的IT開發能力，在應用推廣RPA以前，已經採起了其它的自動化方案。
好比前面講的Python，VBA，批處理。。。
那麼人家就會問，沒有RPA的狀況下我已經已經實現了自動化，我爲啥要用RPA來「從新發明輪子」？
那麼企業已有的自動化能力，反而有可能成爲RPA推廣的阻力。

一些企業採用的是SaaS的方案，買公共的按量計費的服務。
好比一些雲端版本的財務平臺，CRM等等。
SaaS供應商自己對特定領域的業務已經有長期且深刻的研究。
你爲了上RPA作的那點功夫，比得上人家終年累月的積累嗎？

還有許多人分不清RPA與RDA的區別。
總覺得RPA像RDA同樣簡單。
總覺得RPA就是單機的自動化。
不論他是怎麼產生這個誤解。
這將RPA直接拉入與Python，VBA，甚至批處理的直接競爭。
這是技術的倒退。。。
我甚至見過聲稱是RPA的自動化項目，其實每一步都用Excel的VBA去處理，只是最外面用UiPath去調用了一下。
UiPath在整個項目中的惟一做用就是啓動VBA腳本。。。
而後把這稱之爲RPA！
而後客戶竟然還買單了！
有時候不得不認可，客戶買單就是真理。
客戶不買單，RPA仍是RDA，又有什麼分別？
但是我想問，大家知道爲何這個項目沒有二期嗎？
掛RPA的羊頭，賣RDA的狗肉，比比皆是。

本質上來講，RPA圈子真正的資深人士仍是太少。
有些人或許有多年工做經驗。
但對於RPA這種綜合了多方面知識的專業技術，仍是掌握得不夠全面，不夠深刻。
有些人可能技術很好，會.net開發。
而後不斷地在RPA項目中寫代碼，還洋洋自得。
好像會寫自定義組件很是了不得。。。
然而RPA工具自己默認自帶的功能，他不去研究，他本身寫代碼。
真牛逼！

廠商也是，喜歡說本身的產品容易上手。
這樣講字面上也沒錯。
可是給人營造一種錯覺，好像「RPA很是容易」。
考認證很容易，不等於實際作項目很容易好嗎！
懂業務的人，基本都不肯意靜下心來學習RPA。
畢竟有業務背景的人，職業生涯選擇太多，搞RPA來錢太累。
搞IT的又可貴有機會去深刻學習業務。
可是業務又經常兼職項目經理，項目經理又經常兼職技術架構。。。
因此RPA的潛力有時候都是被技術架構所侷限的。
技術已經翻天覆地了，能作什麼不能作什麼，已經超越了絕大多數外行的想象。
但卻由外行來指導內行？
你不翻車你找我，我好好學習一下！

UiPath不是最好的RPA工具。
可是人材匱乏讓UiPath成爲咱們無可奈何的首選。
有錢的企業很是多，RPA工具也不是很貴的企業級軟件。
可是你買得起，不表明你用得起。
軟件配上了，你的人會用嗎？
會用的人你招嗎？
你招的人他真的會用嗎？
你敢肯定供應商不是用RPA工具調用VBA來糊弄你？
說到底RPA廠商還沒把國內的社區培養起來。
UiPath也不能說花了大力氣培養，可是它來得早，就有先發優點。
人力資源多嘛，有項目的時候你找獲得人上。
別的RPA工具很差嗎？我看未必。
可是別的RPA工具你經常找不到人用啊！
這就比較頭痛了。
過一段時間各個廠商開始發力，社區培養起來以後，人力資源的問題應該會緩解。