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

從敏捷方法到敏捷RPA，敏捷開發原則如何助力RPA高效實施應用？

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

當敏捷開發遇到RPA，敏捷RPA緣何成為RPA高效開發實施的護航艦？

文/王吉偉

與傳統自動化相比，RPA 不僅易于使用且實施成本更低，且成效明顯。相關數據表明，RPA可以穩定地將運營成本平均降低 25-50%。

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

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

但，RPA 并非沒有缺點。RPA的脆弱性對業務流程穩定性造成的極大挑戰，也在一些組織中的規?；瘧弥斜憩F得越發明顯。安永在2020年的一項數據調查中就曾指出，30% 到 50% 的RPA項目以失敗告終。

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

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

實踐證明，這些組織采用敏捷原則開發、應用和維護RPA，可以讓RPA在業務中獲得更好的治理、更靈活的擴展能力、效率和大大降低的成本，進而減輕各種實施風險和頻繁返工。

當RPA的開發與應用引入敏捷方法之后，一種更高效的RPA應用與實施方法論也就出現了，UiPath等廠商及組織將其稱為敏捷RPA。

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

從敏捷開發說起

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

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

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

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

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

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

4個核心價值觀，強調了協作與即時性的作用，增加了客戶參與度，并進一步將軟件開發從面向過程轉變為面向對象。這種轉變，也使得它與瀑布模型有了明顯的區別。

正如敏捷聯盟所解釋的那樣，“將敏捷與其他軟件開發方法區分開來的一點是，關注工作的人以及他們如何一起工作。解決方案通過自組織跨職能團隊之間的協作而發展，利用適合其背景的適當實踐。”

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

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

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

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

敏捷RPA與敏捷交付

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

擴展閱讀：一線業務人員即將成為RPA開發大軍，距離RPA人人可用還有多遠?

與傳統軟件開發的區別是，RPA、低代碼等技術簡化了軟件程序的開發過程，因此更加注重交付環節。出于對于自動化、程序及開發平臺等的理解不同，不同業務線的工作人員開發出的自動化程序在邏輯上也會有一些不同，會使得這些自動化程序的穩定性降低，脆弱性也會不同程度的增加。

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

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

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

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

所以，執行敏捷開發和成為敏捷組織是有區別的：前者的重點是過程和技術，后者的重點則是由敏捷原則和價值觀指導的行為。

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

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

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

一般而言，經典交付意味著一次為整個自動化業務流程執行一項活動（例如，設計、開發、測試、部署），而敏捷交付意味著同時為整個自動化的業務流程的一個子集執行所有活動。

因此，敏捷RPA交付的關鍵是經常生產“工作機器人”（又名機器人增量），以實現頻繁反饋。對于工作機器人，大家可以理解為為利益相關者創造價值的最終自動化業務流程的子集。

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

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

為什么RPA需要敏捷方法?

根據德勤（2018）的數據，78%的實施了RPA的組織預計在未來3年內會大幅增加投資。然而，其中只有3%的人能夠將RPA擴展到初始試點之外。與自動化相關的維護工作，是阻止公司擴展RPA的決定性因素。

維護是一個總括術語，它封裝了與RPA相關的各種問題。高維護RPA主要是由脆弱的RPA引起的，脆弱的RPA便意味著不穩定的RPA，會導致機器人程序中斷生產。

導致機器人中斷運行并持續投入維護的三個主要原因如下：

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

2、應用程序問題。這些問題，是因為對機器人使用的軟件應用程序所做的更改造成的。這些更改由軟件開發團隊進行，包括技術更改(例如，更改UI控件、API定義)或軟件應用程序的業務邏輯更改。

3、環境問題。這些問題通常由IT運營團隊造成，包括性能問題、依賴第三方服務引起的問題、數據相關問題、系統更改引起的問題(例如，防病毒更新、安全修補程序、瀏覽器更新)，或對打包的CRM/ERP應用程序(例如，SAP、ServiceNow、Salesforce)進行自定義以考慮法規更改而引起的問題。

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

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

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

首先，敏捷方法要求創建跨職能團隊，打破孤島并促進業務/IT 協調，這是 RPA 成功的必要條件。

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

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

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

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

敏捷開發原則如何助力RPA 成功?

RPA與純軟件和產品開發有很大不同，但是可以借鑒和應用基本的敏捷原則來產生相同的結果：更快地交付價值，同時降低成本和風險。

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

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

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

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

更優質的設計和定義。在機器人流程自動化的敏捷方法中，業務流程在任何開發開始之前就被設計和優化。這使大型組織能夠完全標準化和優化端到端、復雜和多層的業務流程，成為真正的自動化投資回報率所在。

它還為他們提供了寶貴的機會來考慮這些流程并將其與更大的業務目標和企業或監管約束、政策和控制聯系起來。

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

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

積壓也是有效管理機器人維護的關鍵。隨著許多機器人和不斷發生的變化，維護工作可能會消耗積壓并扼殺提供價值和創新的新項目。因此，有組織的優先排序方法至關重要。

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

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

后記：因人而異擇優而選

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

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

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

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

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

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

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

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

【王吉偉頻道，關注TMT與IoT，專注數字化轉型、業務流程自動化與RPA?！?/p>