這是一篇RPA實施項目中關于自定義開發的探索與階段性思考。

一、源起

RPA項目實施過程中會涉及到或多或少的自定義開發（Python/VBA/...），一方面確實可以加速項目進程，另一方面也會成為后續運維或優化的定時炸彈。

2019年5月16日參加了北京Tableau大會，看到了敏捷BI軟件強大的號召力與未來蓬勃發展的潛力。

RPA項目的人員一直的緊缺的。作為咨詢公司，希望聘請的同事都是咨詢范兒的，但是RPA實施又確實需要擼起袖子。

中美貿易戰+華為被國美列入出口管制的Entity List，國內的RPA廠商都沒有放過這個宣傳國產品牌的大好時機。

與RPA開發相關的，提出兩個觀點并進行說明（其余觀點看法另做文章論述）。

觀點1：RPA項目中的開發是一把雙刃劍，應該關在籠子里；

觀點2：RPA項目是一個賦能的過程，應保持對于變化的適應性。

二、RPA項目中的開發是一把雙刃劍，應該關在籠子里

RPA進行Excel處理是非常常見的操作，當處理邏輯稍加復雜，且待處理的數據量稍微多一點兒，那么各路大神便開始各顯神通（例如：VBA/.Net/Python/存儲過程等等）。

這樣的操作可以減少UiPath程序的編碼的工作量，縮短項目的總體時間。

可以想象這樣一個場景：當某個功能被這些計算機語言（非UiPath）實現，程序的開發者以及項目組成員都覺得“好酷炫以及好有技術含量”（褒義詞）。

BUT，其實這個“技術含量”可能就是一個大坑。當使用所謂“降維打擊”的解決當前問題的同時，也增加了RPA項目的“技術復雜度”。

一旦“技術復雜度”被提升，這些問題需要被思考：

2.1. 人員投入

要求多數項目組成員都新學習新的語言嗎？

配置專門的成員解決不同項目的問題嗎？

抑或是讓各個項目的成員八仙過海各顯神通？

2.2. 開發規范

是不是會要求開發規范？IDE？

功能說明文檔以及粒度要求？版本管理？命名規范？……

都要來一套嗎？

2.3. 后續運維

程序的復雜度越高，運維的復雜度可能就越困難，成本就越高。

試想：Python程序員看到需要運維一堆VBA代碼時的心情何如？

擅長VBA的同事發現雙表互VLookup的邏輯是通過數據庫存儲過程實現的會作何感想？

這個時候客戶幽幽地走過，問到：不好意思，我也不是催您，不過業務用戶真的很著急，請問預計什么時候可以解決？

我想這個時候情緒澎湃的程度一點兒都不會亞于之前“好酷炫以及好有技術含量”（貶義詞）時。

2.4. 模式匹配

咨詢公司的RPA咨詢實施團隊（作為RPA市場的主流力量），核心價值在于貼身服務，業務快速理解、咨詢建議、方案出具；而維持一個技術團隊不是好的選擇（一是太貴，二是成員沒有發展前景）。

開發公司的RPA實施團隊（目前如雨后春筍般蓬勃發展），如果能夠基于已有的客戶資源和聚焦于特定行業，會有不錯的表現。除此之外，RPA實施團隊無論是走自主研發的路線，還是走人員外包的路線，個人感覺未來的前景都會比較艱辛。

（關于RPA的模式，本文暫不展開，日后可能專門論述）

2.5. 工具推薦

邏輯處理的問題總要被正視和解決，我們正在引入Alteryx作為可視化邏輯處理的工具。

UiPath+Alteryx+Tableau/Qlik的組合會有非常廣闊的應用場景。（這個話題以后可以聊一聊）

三、RPA項目是一個賦能的過程，應保持對于變化的適應性

和遠在外地的項目組成員交流，他向我質疑：為什么我們要花很大的精力去做一年才使用一次的流程？僅僅是因為合同的約定嗎？

很開心能夠聽到這樣的質疑，我回答道：同意你的觀點，我們應該對這樣的選擇保持警惕，應該有更好的選擇的！

反思之余，希望團隊能夠達成如下共識：RPA項目應該能夠為客戶賦能，為自己的團隊賦能，保持靈活性、保持對變化的適應、保持對未來的可能性。

3.1. 為客戶賦能

RPA與Tableau類似的一點：讓業務人員自己處理流程和數據。

換個角度論述：為業務用戶賦能，把高深晦澀的技術拉下神壇，不再是少數人（IT部門）的專利，而是大眾（具體業務部門）普及的工具。

對于業務人員：讓自己的流程被自動化，讓自己的數據被分析，讓自己從枯燥中被解脫，享受在工作中創造價值的快感。

對于IT人員：從輔助支持部門進一步提升，去考慮平臺的問題（數據中臺/計算中臺/AI中臺等）、去考慮規范的問題（主數據/集成等）、去考慮業務擴展適應性的問題（微服務/虛擬化等）、去考慮網絡信息安全的問題……

讓技術以更為民主的方式為企業服務，試圖營造全員創新的氛圍（所以我們的RPA項目組會不遺余力地為客戶做知識轉移，以及大規模的培訓宣傳推廣）。

RPA團隊成員應該更多地思考如何借助技術創造價值，而不僅僅關注于履行現有合同內容。（事實上，我們大多數的實際落地的RPA流程與業務約定書中的約定并不完全一致。具體原因后續可能有文章論述）

基于上述闡述，程序員們的專業開發語言引入RPA項目，顯然需要比較謹慎的對待。

3.2. 為團隊賦能

RPA項目需要成員的三種能力：項目管理、方案設計、技術落地。

如何培養團隊本文也不打算展開論述，在本文的上下文環境中，提出以下觀點：

以上三種能力的培養，最好的方式是在項目中經歷，而不是培訓教室里學習。

越不容易培養的能力越顯稀缺，越有價值。相比于技術落地能力（UiPath開發），方案設計能力和項目管理能力的培養更花時間和更具備難度。

具備技術落地能力（有相關的經驗），對于方案設計和項目管理的幫助很大，可以說是必要條件。

讓團隊快速成長，讓團隊做正確的事情，這個循環就可以良性地循環下去。（說起來容易，做起來也比較費勁；前途是光明的，道路一如既往的曲折）

站在團隊成員賦能的角度，重新審視是否要引入一門新的語言，結論可以各異，但思考的過程是有意義的。

3.3. 保持靈活性

先說結論：我們經歷的很多的管理活動，都是在追求確定性；而RPA項目更大的意思可能在于追求對于不確定的適應，以及保留對于變化的可能。

比如，做ERP咨詢與實施，有必要的環節是業務流程梳理，或者是業務流程再造，就會涉及到業務流程的固化。如果業務流程無法固化，那么后續的系統設計和開發就無法展開。但企業中更多的流程是無法固化的，因為市場等內外部環境是瞬息萬變的。當可以固化的流程已經在ERP系統中完成了固化，那么針對無法固化的流程予以靈活應對就顯得非常重要了。

再比如，業務部門找IT部門提需求，如果需求總是不能明確，并無法落地成為需求說明文檔或者藍圖設計文檔，那么后續是無法進行開發工作的。但業務部門人員更多時候應該是：我有一個想法，需要嘗試一下；很多可能性無法預料，因為這是一個新的事情。

在Tableau大會上聽到：馬云爸爸已經進入到養豬行業了。未來無法預知，固化可以固化的，用UiPath/Tableau/Qlik這樣的工具去適應短期內無法固化的，可能是更好的選擇。

站在靈活性適應的角度，對于自定開發的程序，也要考慮下當前開發的程序，在未來打算如何定位的問題。

繼續閱讀：