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

一、源起

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

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

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

中美貿(mào)易戰(zhàn)+華為被國美列入出口管制的Entity List，國內(nèi)的RPA廠商都沒有放過這個宣傳國產(chǎn)品牌的大好時機。

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

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

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

二、RPA項目中的開發(fā)是一把雙刃劍，應該關(guān)在籠子里

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

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

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

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

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

2.1. 人員投入

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

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

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

2.2. 開發(fā)規(guī)范

是不是會要求開發(fā)規(guī)范？IDE？

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

都要來一套嗎？

2.3. 后續(xù)運維

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

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

擅長VBA的同事發(fā)現(xiàn)雙表互VLookup的邏輯是通過數(shù)據(jù)庫存儲過程實現(xiàn)的會作何感想？

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

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

2.4. 模式匹配

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

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

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

2.5. 工具推薦

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

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

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

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

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

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

3.1. 為客戶賦能

RPA與Tableau類似的一點：讓業(yè)務人員自己處理流程和數(shù)據(jù)。

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

對于業(yè)務人員：讓自己的流程被自動化，讓自己的數(shù)據(jù)被分析，讓自己從枯燥中被解脫，享受在工作中創(chuàng)造價值的快感。

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

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

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

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

3.2. 為團隊賦能

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

如何培養(yǎng)團隊本文也不打算展開論述，在本文的上下文環(huán)境中，提出以下觀點：

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

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

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

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

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

3.3. 保持靈活性

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

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

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

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

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

繼續(xù)閱讀：