30%到50%的RPA項目以失敗告終，敏捷方法如何助力RPA高效實施？

從敏捷方法到敏捷RPA，敏捷開發(fā)原則如何助力RPA高效實施應(yīng)用？

30%到50%的RPA項目以失敗告終，敏捷方法如何助力RPA高效實施？

當(dāng)敏捷開發(fā)遇到RPA，敏捷RPA緣何成為RPA高效開發(fā)實施的護(hù)航艦？

文/王吉偉

與傳統(tǒng)自動化相比，RPA 不僅易于使用且實施成本更低，且成效明顯。相關(guān)數(shù)據(jù)表明，RPA可以穩(wěn)定地將運營成本平均降低 25-50%。

Gartner數(shù)據(jù)顯示，RPA市場價值在2020年便已激增至13億美元。Forrester則預(yù)測，到2025年，全球RPA市場規(guī)模將達(dá)到225億美元，其中RPA軟件市場規(guī)模65億美元，RPA服務(wù)市場更是高達(dá)160億美元。

隨著RPA與AI、流程挖掘等技術(shù)的深度融合，其應(yīng)用場景也越來越多。更大的優(yōu)勢，讓RPA成為十年以來最吸引企業(yè)想象力以及錢包的自動化技術(shù)。這也使得RPA的普及度進(jìn)一步加速，正在被越來越多的組織采用。

但，RPA 并非沒有缺點。RPA的脆弱性對業(yè)務(wù)流程穩(wěn)定性造成的極大挑戰(zhàn)，也在一些組織中的規(guī)模化應(yīng)用中表現(xiàn)得越發(fā)明顯。安永在2020年的一項數(shù)據(jù)調(diào)查中就曾指出，30% 到 50% 的RPA項目以失敗告終。

盡管 RPA 和智能自動化項目失敗的原因不止一個，但流程選擇不當(dāng)、缺乏治理以及最終不符合標(biāo)準(zhǔn)的項目管理實踐往往是主要促成因素。

這就引出了一個問題，RPA 相關(guān)項目管理和軟件開發(fā)的敏捷方法能否幫助確保成功?事實上，為了防止拓展RPA的挑戰(zhàn)和失敗，一些大型組織已經(jīng)采用敏捷方法來實施和推動其自動化計劃。

實踐證明，這些組織采用敏捷原則開發(fā)、應(yīng)用和維護(hù)RPA，可以讓RPA在業(yè)務(wù)中獲得更好的治理、更靈活的擴(kuò)展能力、效率和大大降低的成本，進(jìn)而減輕各種實施風(fēng)險和頻繁返工。

當(dāng)RPA的開發(fā)與應(yīng)用引入敏捷方法之后，一種更高效的RPA應(yīng)用與實施方法論也就出現(xiàn)了，UiPath等廠商及組織將其稱為敏捷RPA。

什么是敏捷RPA？為什么RPA需要敏捷方法？敏捷開發(fā)原則如何助力RPA成功？本文，王吉偉頻道就跟大家聊聊這些。

從敏捷開發(fā)說起

在軟件開發(fā)領(lǐng)域，大多數(shù)軟件開發(fā)和技術(shù)實施一直都是按順序、逐步的過程部署的，長期以來主流開發(fā)模式都是瀑布模型。這是一種“重型”的開發(fā)模式，整個流程走完通常周期很長，少則數(shù)月，多則數(shù)年。長周期導(dǎo)致風(fēng)險增加、難以響應(yīng)變化。

直到2001年，17 位知名軟件開發(fā)人員齊聚一堂，討論替代瀑布模型這種重量級軟件開發(fā)過程的新方法。把大家都認(rèn)同的理念整理出來，這就是后來的敏捷宣言，并成立了敏捷聯(lián)盟。

自此，軟件開發(fā)誕生了新的“輕量級”迭代模型，后來大家將其統(tǒng)稱為敏捷。

敏捷宣言指出：敏捷不是一種方法論，也不是一種軟件開發(fā)的具體方法，更不是一個框架或過程，而是一套價值觀和原則。

如果說各種敏捷框架、方法論和工具是“術(shù)”，告訴大家敏捷開發(fā)的方式，那么敏捷就是“道”，以一套價值觀和原則指導(dǎo)大家在軟件項目開發(fā)中做決策。

敏捷宣言基于12條原則，主要有4個核心價值觀，如下圖。

4個核心價值觀，強(qiáng)調(diào)了協(xié)作與即時性的作用，增加了客戶參與度，并進(jìn)一步將軟件開發(fā)從面向過程轉(zhuǎn)變?yōu)槊嫦驅(qū)ο?。這種轉(zhuǎn)變，也使得它與瀑布模型有了明顯的區(qū)別。

正如敏捷聯(lián)盟所解釋的那樣，“將敏捷與其他軟件開發(fā)方法區(qū)分開來的一點是，關(guān)注工作的人以及他們?nèi)绾我黄鸸ぷ?。解決方案通過自組織跨職能團(tuán)隊之間的協(xié)作而發(fā)展，利用適合其背景的適當(dāng)實踐。”

敏捷開發(fā)要做的，就是解決瀑布模型這樣的重型軟件開發(fā)方法存在的問題，用一種輕量的、敏捷的方法來改善甚至是替代它。

敏捷開發(fā)以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行軟件開發(fā)。在敏捷開發(fā)中，軟件項目在構(gòu)建初期被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備可視、可集成和可運行使用的特征。

換言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。

因此，它與傳統(tǒng)開發(fā)模式的另一個不同之處就體現(xiàn)在，它將項目分解為小的、可消化的增量，稱為“沖刺” (Sprint)。在整個項目全生命周期中不斷評估需求、計劃和結(jié)果，使變更成為流程的有機(jī)組成部分。

敏捷RPA與敏捷交付

雖然更多的RPA開發(fā)者是沒有編程基礎(chǔ)的一線業(yè)務(wù)人員，但這些平民開發(fā)者也參與了軟件開發(fā)過程，所以還要遵守一定的軟件開發(fā)邏輯。比如，采用某種軟件開發(fā)方法論或者某種開發(fā)模型。

擴(kuò)展閱讀：一線業(yè)務(wù)人員即將成為RPA開發(fā)大軍，距離RPA人人可用還有多遠(yuǎn)?

與傳統(tǒng)軟件開發(fā)的區(qū)別是，RPA、低代碼等技術(shù)簡化了軟件程序的開發(fā)過程，因此更加注重交付環(huán)節(jié)。出于對于自動化、程序及開發(fā)平臺等的理解不同，不同業(yè)務(wù)線的工作人員開發(fā)出的自動化程序在邏輯上也會有一些不同，會使得這些自動化程序的穩(wěn)定性降低，脆弱性也會不同程度的增加。

大量業(yè)務(wù)人員的并行開發(fā)，會帶來大量的自動化程序。而這些程序能不能高質(zhì)量交付，或者如何保障這些程序的高效交付，也成了自動化程序交付的主要問題。

敏捷開發(fā)已成主流的現(xiàn)在，在主流RPA廠商的影響之下，RPA在開發(fā)與交付方面同樣正在摒棄傳統(tǒng)的瀑布式開發(fā)等模式，而是盡力向敏捷開發(fā)靠攏。由此，誕生了敏捷RPA（Agile RPA）。

前文我們講過，敏捷不是一個過程，而是一組價值觀。敏捷RPA也不是單純指某種技術(shù)，而是指RPA交付的哲學(xué)。

在實踐中，這種交付理念得到了一組輕量級流程框架（例如Scrum、看板、SAFe、Nexus、LeSS）和操作技術(shù)（例如CI/CD）的支持，幫助RPA團(tuán)隊將這些價值付諸實踐。

所以，執(zhí)行敏捷開發(fā)和成為敏捷組織是有區(qū)別的：前者的重點是過程和技術(shù)，后者的重點則是由敏捷原則和價值觀指導(dǎo)的行為。

敏捷交付，是迭代式交付和增量式交付的組合。為實現(xiàn)某個業(yè)務(wù)流程的自動化而進(jìn)行的增量交付，可能意味著一個接一個地自動化一些流程組件，以更好的效果發(fā)布它們，并在下一個版本中自動化其他流程組件。

迭代交付可能意味著以低保真度自動化所有流程組件，發(fā)布它們，然后在下一個版本中提高流程組件的自動化保真度。

在自動化程序開發(fā)中，增量是添加流程組件到自動化中，迭代則是轉(zhuǎn)化為自動化中的“優(yōu)化流程組件”。因此，以敏捷的方式交付自動化業(yè)務(wù)流程，意味著以低保真度逐個自動化一些業(yè)務(wù)流程組件，然后發(fā)布它們，然后逐漸提高其自動化保真度，并自動化其他流程組件和下一個版本。

一般而言，經(jīng)典交付意味著一次為整個自動化業(yè)務(wù)流程執(zhí)行一項活動（例如，設(shè)計、開發(fā)、測試、部署），而敏捷交付意味著同時為整個自動化的業(yè)務(wù)流程的一個子集執(zhí)行所有活動。

因此，敏捷RPA交付的關(guān)鍵是經(jīng)常生產(chǎn)“工作機(jī)器人”（又名機(jī)器人增量），以實現(xiàn)頻繁反饋。對于工作機(jī)器人，大家可以理解為為利益相關(guān)者創(chuàng)造價值的最終自動化業(yè)務(wù)流程的子集。

需要說明的是，在敏捷RPA交付中，沒有什么是真正被認(rèn)為是最終的，因為您總是可以在功能、性能、可靠性、穩(wěn)定性、安全性、可用性（例如，有人值守的機(jī)器人）和許多其他屬性方面拓展自動化。

因此，從某種意義上說，敏捷RPA交付的目標(biāo)不是要完美，而是要逐漸減少無意義的開發(fā)行為。

為什么RPA需要敏捷方法?

根據(jù)德勤（2018）的數(shù)據(jù)，78%的實施了RPA的組織預(yù)計在未來3年內(nèi)會大幅增加投資。然而，其中只有3%的人能夠?qū)PA擴(kuò)展到初始試點之外。與自動化相關(guān)的維護(hù)工作，是阻止公司擴(kuò)展RPA的決定性因素。

維護(hù)是一個總括術(shù)語，它封裝了與RPA相關(guān)的各種問題。高維護(hù)RPA主要是由脆弱的RPA引起的，脆弱的RPA便意味著不穩(wěn)定的RPA，會導(dǎo)致機(jī)器人程序中斷生產(chǎn)。

導(dǎo)致機(jī)器人中斷運行并持續(xù)投入維護(hù)的三個主要原因如下：

1、自動化本身的問題。由于機(jī)器人和軟件應(yīng)用程序之間的同步問題，由于對象識別能力差，或者由于沒有或缺少恢復(fù)、異?；蝈e誤處理，機(jī)器人正在中斷生產(chǎn)。

2、應(yīng)用程序問題。這些問題，是因為對機(jī)器人使用的軟件應(yīng)用程序所做的更改造成的。這些更改由軟件開發(fā)團(tuán)隊進(jìn)行，包括技術(shù)更改(例如，更改UI控件、API定義)或軟件應(yīng)用程序的業(yè)務(wù)邏輯更改。

3、環(huán)境問題。這些問題通常由IT運營團(tuán)隊造成，包括性能問題、依賴第三方服務(wù)引起的問題、數(shù)據(jù)相關(guān)問題、系統(tǒng)更改引起的問題(例如，防病毒更新、安全修補(bǔ)程序、瀏覽器更新)，或?qū)Υ虬腃RM/ERP應(yīng)用程序(例如，SAP、ServiceNow、Salesforce)進(jìn)行自定義以考慮法規(guī)更改而引起的問題。

如果不夠重視這些上述問題，你的RPA項目很可能會以失敗告終，或者無法通過拓展更多的業(yè)務(wù)場景實現(xiàn)更高的ROI。

事實證明，已經(jīng)上線幾個月又需要重新設(shè)計的RPA項目并不少見，因為不可預(yù)見的問題引發(fā)了RPA實施的復(fù)雜性。如果這些項目在立項之初就能遵循一些敏捷原則，則可以避免很多問題而不至于重新設(shè)計。

對于RPA項目而言，敏捷方法能夠帶來的好處大概有以下幾點：

首先，敏捷方法要求創(chuàng)建跨職能團(tuán)隊，打破孤島并促進(jìn)業(yè)務(wù)/IT 協(xié)調(diào)，這是 RPA 成功的必要條件。

其次，如前文所述，RPA相當(dāng)脆弱，對變化反應(yīng)不佳。與傳統(tǒng)方法不同，敏捷方法為實施后的持續(xù)、迭代更改和升級留出了更多空間。

第三，也是最最重要的，敏捷提供了在整個企業(yè)中擴(kuò)展 RPA 和智能自動化所需的治理框架。在這些場景中，組織可以采用類似工廠的方法來實施由可重用組件、工作流、標(biāo)準(zhǔn)和指南、工具和參考實施組成的 RPA。這種方法不僅成本高、勞動效率高，而且還能帶來更高質(zhì)量和更安全的 RPA 應(yīng)用程序。

RPA的目標(biāo)是通過消除重復(fù)的、低價值的任務(wù)以增強(qiáng)人類工作體驗，因此它必須與最終用戶共同實施。這個邏輯，與敏捷方法鼓勵的盡早并經(jīng)常與利益相關(guān)者密切合作不謀而合。

并且，RPA正在不斷降低使用門檻與開發(fā)難度，這本身就是敏捷開發(fā)的一部分。

敏捷開發(fā)原則如何助力RPA 成功?

RPA與純軟件和產(chǎn)品開發(fā)有很大不同，但是可以借鑒和應(yīng)用基本的敏捷原則來產(chǎn)生相同的結(jié)果：更快地交付價值，同時降低成本和風(fēng)險。

流程不是產(chǎn)品，不能與純軟件開發(fā)相同的方式開發(fā)和部署，因此敏捷RPA不能遵循敏捷Scrum框架（迭代式增量軟件開發(fā)過程，敏捷方法論中的重要框架之一）的每一條原則。

但是，敏捷Scrum方法的各種元素可以為有遠(yuǎn)見的組織提供更多紅利，大家可以借鑒敏捷開發(fā)的方法與邏輯，加速規(guī)模并建立RPA卓越中心（CoE）以及相似的組織，以保障自動化能夠更高效的助力企業(yè)提質(zhì)增效降本。

敏捷方法，至少可以讓組織在RPA實施過程中做到以下幾點：

更懂協(xié)作的團(tuán)隊。RPA 的敏捷方法包含一個由不同利益相關(guān)者組成的專門團(tuán)隊，他們緊密合作，包括開發(fā)人員、測試人員和業(yè)務(wù)角色。這不僅增強(qiáng)了識別 RPA 機(jī)會的有效性，而且還促進(jìn)了大規(guī)模治理，因為專門的團(tuán)隊可以更好地管理和協(xié)調(diào)影響業(yè)務(wù)和運營不同部分的自動化流程。

更優(yōu)質(zhì)的設(shè)計和定義。在機(jī)器人流程自動化的敏捷方法中，業(yè)務(wù)流程在任何開發(fā)開始之前就被設(shè)計和優(yōu)化。這使大型組織能夠完全標(biāo)準(zhǔn)化和優(yōu)化端到端、復(fù)雜和多層的業(yè)務(wù)流程，成為真正的自動化投資回報率所在。

它還為他們提供了寶貴的機(jī)會來考慮這些流程并將其與更大的業(yè)務(wù)目標(biāo)和企業(yè)或監(jiān)管約束、政策和控制聯(lián)系起來。

自動化基本的戰(zhàn)術(shù)流程要簡單得多，但從長遠(yuǎn)來看，其價值回報率也會顯著降低。大規(guī)模阻礙 RPA 的主要障礙是自動化更復(fù)雜的流程并確保透明有效地遵守法規(guī)。促進(jìn)預(yù)先定義和設(shè)計以確保優(yōu)化和法規(guī)遵從性的方法極大地使有意愿的企業(yè)能夠克服這一挑戰(zhàn)。

更高效的積壓維護(hù)。要擴(kuò)展 RPA，機(jī)器人必須變得更大、更復(fù)雜。積壓工作能夠讓組織將復(fù)雜的端到端流程分割成多個工作項或故事，并將它們作為積壓工作獨立地確定優(yōu)先級。

積壓也是有效管理機(jī)器人維護(hù)的關(guān)鍵。隨著許多機(jī)器人和不斷發(fā)生的變化，維護(hù)工作可能會消耗積壓并扼殺提供價值和創(chuàng)新的新項目。因此，有組織的優(yōu)先排序方法至關(guān)重要。

沖刺計劃和回顧。與在項目開始時定義的時間表不同，計劃短暫的工作突增或沖刺使團(tuán)隊能夠在出現(xiàn)需要解決的問題時重新確定工作的優(yōu)先級。而不是在項目結(jié)束時意識到不對勁，導(dǎo)致返工并因此增加成本。

Sprint回顧還可以使團(tuán)隊能夠隨著工作的進(jìn)展吸取經(jīng)驗教訓(xùn)，并將其融入整個 RPA 工作中，進(jìn)而避免在下游犯下相同的錯誤并及時實施良好實踐。

后記：因人而異擇優(yōu)而選

看到這里，大家應(yīng)該對敏捷RPA有了一定的了解。關(guān)于敏捷RPA，很多人看完可能會感覺非常復(fù)雜。其實想要實現(xiàn)敏捷RPA也很簡單，就是建立RPA卓越中心，然后告訴RPA CoE管理者要引入敏捷方法，并堅定不移的支持其工作就可以了。

但說起來容易做起來難，因為要改變大型組織固有的IT組織架構(gòu)及開發(fā)邏輯，著實是一個難上加難的問題。

所以，這篇文章的用意，并不是告訴大家在RPA建設(shè)與應(yīng)用上一定要嚴(yán)格遵守敏捷方法，而是說在RPA引入時可以適當(dāng)參考敏捷方法，以避免在后面的RPA應(yīng)用中出現(xiàn)太多問題而導(dǎo)致項目擱淺，同時也為基于自動化獲得更高的ROI打下更好的基礎(chǔ)。

同時大家也應(yīng)該知道，每個組織的信息化程度不同，IT建設(shè)情況不同，程序開發(fā)的理念也不同，這就決定了不是每個組織都適合采用敏捷方法進(jìn)行各種項目開發(fā)。

敏捷RPA交付有許多好處，但它也帶有敏捷方法固有的某些風(fēng)險。因此敏捷方法并不適合每個組織，這取決于組織的情況以及如何下定決心克服困難去采用敏捷。如果參與RPA交付的人員不愿意緊密協(xié)作，很可能以敏捷的方式工作會成為一場IT與流程變革的災(zāi)難。

所以，在敏捷方法與RPA項目上，不要將敏捷實踐和原則強(qiáng)加給那些不愿采用敏捷的人，只需要給人們正確的信息讓他們說服自己。

也不要試圖說服別人，只需要告訴并解釋敏捷能夠帶來了什么就可以了。

剩下的，全部交給決策者。

【王吉偉頻道，關(guān)注TMT與IoT，專注數(shù)字化轉(zhuǎn)型、業(yè)務(wù)流程自動化與RPA。】