要寫在前面的是，企業上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工具你常常找不到人用啊！
這就比較頭痛了。
過一段時間各個廠商開始發力，社區培養起來之后，人力資源的問題應該會緩解。
