從靈活方法到靈活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的脆弱性對業務流程穩定性造成的極大挑戰，也在一些組織中的規模化應用中表現得越發明顯。安永在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、自動化本身的問題。由于機器人和軟體應用程式之間的同步問題，由于對象識别能力差，或者由于沒有或缺少恢複、異常或錯誤處理，機器人正在中斷生産。
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。】