自動化 AI
訂閱
軟體工程的 DevOps 取向，透過統一開發與營運，徹底改變了發行速度。您的開發團隊現在很可能就是由 DevOps 原則提供強制持續整合與部署的架構，藉此引導開發團隊的流程。當您運用 DevOps 取向來開發軟體時，您即遵循開發、測試、驗收和生產 (DTAP) 所構成的生命週期。擁有大型開發團隊的組織，尤其是開發團隊散布各地的組織，已意識到需要採用 DevOps 取向來大幅改善其軟體開發生命週期 (SDLC) 流程。正因如此，採用相同的 DevOps 取向在全企業開發機器人流程自動化 (RPA) 機器人，再恰當不過。
現今，大多數 RPA 解決方案提供各種功能，讓您能將機器人從開發生命週期的某一階段移到下個階段。這是否表示，這些解決方案支援 DevOps 取向的機器人生命週期管理 (BLM)？其實不然。只要機器人遵照 DevOps 生命週期就構成 BLM，這樣的想法是一種迷思。但正如許多其他迷思，如果不深入檢驗，乍聽之下也能魚目混珠。
DevOps 與 BLM 並不相同
DevOps 生命週期的每個階段分別都在不同的環境中展開。在一個環境中進行開發，然後在另一個環境進行測試。生產則又是在另一個環境。因此，要管理機器人的生命週期，需要能依照機器人所在的生命週期階段，為機器人維持各自的環境，而且需要能讓整個機器人套件依次通過不同階段。
假設您建造了 A 機器人，為了讓機器人有效運作，A 機器人依賴個別流程 A.1、A.2 和 A.3。因此，需要管理機器人和其相依性，並且以同一套件的形式循序通過機器人生命週期。您說：「顯然是要這樣」。但是大多數 RPA 解決方案還沒辦法這麼做，他們只是將機器人匯入和匯出您所提供的環境。您要分開管理機器人相依性。您可能會問：「真的嗎？聽起來很麻煩。」真的。而且，沒錯，任何一位 RPA 程式管理員都會這樣回答您，這真的很麻煩。
如未設置真正的 BLM 架構，則必須建立和管理開發與測試環境。您也必須個別管理和推進相依性。當您只是在為 RPA 進行概念驗證時，這種做法或許行得通，但是卻無法擴充。必須用互不相連的流程來管理的機器人越多，就需要越長的時間，才能將機器人投入生產。此外，如果相依性不慎遺漏，可能會出現更多錯誤，延誤持續整合與部署。
合規也可能會是一個問題。對於有合規要求的機器人接觸流程，例如美國沙賓法案 (SOX) 涵蓋的財管流程，缺乏真正的 BLM 架構，會迫使您不得不開發和管理自家公司的機器人控管技術。
運用 BLM 進行擴充
BLM 架構包含在 Automation Anywhere Enterprise 內，不僅只匯入和匯出機器人，還能輕易地與 DevOps 工作流程整合。內建對個別開發、測試、驗收和生產環境的支援，包括完整版本控制與回復功能。
高度精密的角色型存取控制 (RBAC) 是企業必備的另一項功能，可強化企業 RPA 平台的安全性。有了精密的 RBAC 功能，機器人就能順利通過 DevOps 生命週期的各個階段。那要怎麼處理相依性？相依性會跟隨機器人通過整個生命週期。因為 Automation Anywhere Enterprise 會在機器人生命週期中管理整個機器人套件。即使有嚴格的合規要求，這項控制版本、角色和機器人套件的功能，仍然讓您能更快地開發更多機器人。這讓您能快速將 RPA 擴充到整個企業，並且更快地獲得更高的投資報酬率，這是精心研擬的企業級 RPA 策略的一大特點。
立即申請示範 Automation Anywhere Enterprise 平台，獲得第一手機器人生命週期管理體驗。
