【51CTO.com快譯】如今的流程自動化有多種形式。而不斷發(fā)展的工具生態(tài)系統可以使從簡單的重復性任務到復雜的自定義工作流都實現自動化。

2015年，德國電信公司開始使用機器人流程自動化(RPA)，這是全流程自動化領域的眾多工具之一。隨著時間的推移，該公司開發(fā)了超過2500個機器人流程自動化(RPA)系統，并取得了巨大的成功。但他們也很清楚，即使機器人流程自動化(RPA)的名稱標明“流程自動化”，其實并不是真正意義上的流程自動化，而是任務自動化。

這是人們一個常見的誤解，其根源在于流程自動化領域的復雜性，在該領域中，其工具類別是多維的并且難以捕獲。以下將回答人們通常都會問到的問題—什么是流程自動化?并對流程自動化領域的發(fā)展進行概述。

為了描述更加簡潔，將流程自動化縮小到以下范圍：

• 業(yè)務流程和數字流程：這些是從大多數組織了解的典型業(yè)務流程(例如客戶入職、索賠清算、貸款發(fā)放、訂單履行等)，通常跨越兩個不同的端到端系統。如今，“數字化流程”一詞似乎很受歡迎，因為“業(yè)務流程”一詞通常被認為是過時的說法。
• 集成流程：集中于系統或服務集成的流程，例如，在進行遠程通信時協調微服務或保證一致性的流程。

其他流程自動化用例明顯超出這個范圍：

• 不受信任的參與者之間的流程：這是區(qū)塊鏈技術發(fā)揮作用的領域。
• 基礎設施配置或IT自動化(例如Ansible和Terraform)：這是具有專用工具的獨立領域。
• 持續(xù)集成/持續(xù)交付(例如，Jenkins、GitHub Workflows)：持續(xù)集成(CI)/持續(xù)交付(CD)管道是軟件工程中的標準流程，由標準軟件實現自動化。
• 物聯網(例如Node Red)：物聯網用例通常通過專用工具解決，可以將其歸類為任務自動化。為了簡單起見，本文對此不進行討論。

現在有兩種截然不同的數字或集成流程：

• 標準流程：當組織并不想通過流程實現差異化時，可以購買商業(yè)現成軟件(COTS)，如企業(yè)資源計劃(ERP)、客戶關系管理(CRM)或人力資源(HR)系統。在這種情況下，通常會根據軟件來調整工作流程。
• 自定義流程：某些流程是組織特有的，因此需要根據組織的需求進行自定義。盡管不同組織的這些流程可能是相同的(例如，客戶入職、訂單管理、保險理賠等)，但是組織設計和實施它們的方式是獨特的，這有助于在其市場中區(qū)分這些流程。這使組織能夠提高競爭力，更有效地開展業(yè)務，降低成本，增加收入，并轉變?yōu)楦訑底只臉I(yè)務。

在自定義標準軟件時，這兩個類別之間有一些灰色區(qū)域。但由于在過去的糟糕經歷，很多組織在這方面變得越來越謹慎。

因此針對組織中的每個流程分別做出決定。并且需要注意的是：沒有正確或錯誤的決定，只是組織的的選擇應該反映其業(yè)務策略。本文將重點討論自定義流程。

自定義流程涉及構建用于流程自動化的軟件。這是“構建軟件的軟件”， 可以大致分為兩個方面(工具的性質和自動化的性質)，如下圖所示：

• 流程自動化關注自動化流程的控制流程。它著重于任務的順序，而不是單個任務。任務自動化可以自動執(zhí)行流程中的單個任務，例如通過與某些系統集成。
• 對開發(fā)人員友好的工具無縫地集成在典型的開發(fā)人員工具堆棧和流程中，但是為開發(fā)人員解決了特定于流程自動化的某些問題(例如，提供了流程狀態(tài)的持久性、圖形化的流程模型、流程模型的版本控制)。開發(fā)人員友好的工具需要軟件開發(fā)才能構建解決方案。低代碼工具允許非開發(fā)人員通過提供復雜的圖形用戶界面和向導來隱藏技術細節(jié)，從而實現自動化邏輯。這允許不同的角色來構建解決方案，但也限制了可能性，并需要采用專有的知識。

有了這兩個維度，就可以將工具歸入以下所述的主要存儲區(qū)域中。

低代碼任務自動化

低代碼任務自動化的典型示例包括應用程序集成工具和機器人流程自動化(RPA)：

• 應用程序集成工具(例如Zapier、IFTTT、Tray.io、Integromat等)：應用程序集成工具可以在某些事件發(fā)生時執(zhí)行操作，例如，在完成Trello插入時將新數據插入Airtable。其中一些工具超出了任務自動化的范圍，還提供了基本的流程自動化功能(例如tray.io)。
• 機器人流程自動化(RPA)工具(例如UiPath)：機器人流程自動化(RPA)工具可以在不提供任何API的原有系統中自動執(zhí)行任務。這是關于屏幕抓取和模擬鼠標或鍵盤操作的，類似于Microsoft Office宏記錄器。

低代碼任務自動化工具非常適合單獨解決簡單的集成問題，并有助于消除人工集成工作，例如將數據從系統A復制到系統B。即時業(yè)務價值是機器人流程自動化(RPA)獲得成功的原因。

但是，其自動化范圍可能比較簡單。需要注意的是，生成的解決方案通常未經測試、不成熟且難以維護。許多解決方案將重點放在成功的案例上，而忘記了例外情況，這些例外情況在生產中會意外發(fā)生，并且往往會被忽略，這會使解決方案變得比較脆弱。

開發(fā)人員友好的任務自動化

以對開發(fā)人員友好的方式自動化單個任務通常意味著不僅要利用軟件開發(fā)，而且還包括以下方面：

• 集成框架(例如Apache Camel)：集成框架使開發(fā)人員可以輕松完成某些任務，例如與文件系統、消息中間件和其他接口技術的通信。
• 批處理：自動執(zhí)行單個任務的經典方法是使用批處理作業(yè)，該作業(yè)將這一任務應用于特定數據集中的每一行。
• 事件驅動的體系結構(EDA)：組件可以對流程​​中的數據做出反應，而無需知道這些數據來自何處。其通用工具包括Apache Kafka之類的事件代理。

與低代碼解決方案相比，開發(fā)人員友好型解決方案要求軟件開發(fā)人員參與其中。另一方面，這些開發(fā)人員通常非常有效率，因為他們可以在已知的堆棧中工作。而且，所得到的解決方案通常更穩(wěn)定，并且可以解決更復雜的問題。

邏輯鏈任務自動化

任務自動化工具無法實現業(yè)務流程。但是，一系列機器人流程自動化、集成任務或事件訂閱可能會形成實現業(yè)務流程的邏輯鏈。這帶來了兩個挑戰(zhàn)：首先，流程沒有持久性，這使得很難確定任何實例的當前狀態(tài)。其次，邏輯控制流不可見，這使得這些架構難以理解和維護。

有兩類工具致力于提供對這些任務鏈的可見性：

• 流程挖掘工具：這些產品可以幫助組織了解如何使用大量原有工具實現流程自動化。通常，這涉及從這些系統加載和分析一堆日志文件、發(fā)現相關性以及映射流程。
• 流程事件監(jiān)視工具：這些工具允許用戶將事件映射到即時提供或發(fā)現的流程模型。與通常基于日志文件分析的流程挖掘不同，流程事件監(jiān)視工具著重于攝取實時事件流，這可能是由事件驅動的架構產生的。

低代碼流程自動化

流程自動化工具使多步驟流程的控制流程自動化。它們的關注重點不再是單個任務，而是更多地關注任務之間的相互作用。流程通常在本質上是長期運行的，這會導致對工具有著自己的要求(持久性、操作工具等)。

低代碼工具旨在允許非開發(fā)人員實施這些流程。典型的工具類別包括：

• 傳統業(yè)務流程管理套件(BPMS)：調研機構Gartner公司現在將其稱為“智能業(yè)務流程管理套件”(iBPMS)，該領域的工具包括Pega和Appian。
• 集成平臺即服務(iPaaS)工具：iPaaS產品提供了實現流程邏輯的基本可能性。示例包括Tray.io和Process Street。
• 機器人流程自動化(RPA)工具：機器人流程自動化(RPA)工具有時被濫用以使流程自動化，建議不要這樣做。

其中一些工具確實可以幫助簡單的流程實施自動化。如果組織是一家初創(chuàng)企業(yè)，則可能會熟悉一些典型的SaaS應用程序，然后使用iPaaS解決方案進行處理。但是，這些方法在復雜的業(yè)務流程或集成方案中是不夠的。

人們經常發(fā)現，低代碼產品通常無法兌現其承諾，而且技術嫻熟的開發(fā)人員也無法自己實現核心流程。因此，組織不得不要求IT部門指派專業(yè)的軟件開發(fā)人員來完成這項工作，但這些方法在復雜的業(yè)務流程或集成場景中并不適用。

開發(fā)人員友好的流程自動化

有一些工具可以使軟件開發(fā)人員有效地實施流程自動化項目：

(1)開發(fā)人員友好的工作流引擎、流程編排器或微服務編排器，有以下三種形式：

• 開源產品：具有企業(yè)版的輕量級工具，可以從供應商處獲得，例如Camunda、JBoss jBPM或Flowable。擁有一個活躍的開源項目和社區(qū)，再加上依賴于收入流的供應商的保證，是一個很好的組合。
• 軟件即服務(SaaS)：提供了許多工具作為托管服務，或者只是SaaS形式(例如AWS Step Functions或Google Workflow)，或者是現有開源產品(例如Camunda Cloud)的托管版本。需要注意的是，目前大多數云計算提供商都將重點更多地放在集成上，而不是業(yè)務流程上。
• 開源項目：大型組織通常會開發(fā)自己的工具棧，其中包括工作流引擎。其中一些工具是在開源許可下提供的，但是沒有任何支持、保證或影響路線圖的可能性。這些工具是針對環(huán)境的，因為它們是針對某個特定組織而不是針對整個市場而構建的。其典型的例子是Netflix Conductor和Uber Cadence。

(2)數字流程自動化(DPA)：該類別基本上擴展了業(yè)務流程管理套件(BPMS)類別，以在數字化轉型的背景下專注于數字端到端流程。這一廣泛類別的界限并不清晰。這里概述的所有類別的供應商出于營銷原因要求實施數字流程自動化(DPA)。鑒于數字化和端到端流程自動化本質上是復雜的，因此將這一類別歸入對開發(fā)人員友好的流程自動化中。

有時，還會在流程自動化項目的場景中評估沒有特定流程自動化支持的工具類別。數據管道就是一個很好的例子。由于它們通常可以圖形化建模，因此很多人將它們用于流程自動化。

(3)數據管道(例如Apache Airflow、Spring Cloud Data Flow)：這些工具具有不同的重點，因此缺乏流程自動化用例的重要功能，例如對諸如循環(huán)之類的控制流結構的支持。此外，這些工具沒有自己的持久性實現，因此流程實例的狀態(tài)是流經管道的數據項。

當然，也可以簡單地對所有內容進行硬編碼以使流程自動化，從而產生自定義的工作流引擎，應該避免使用它。

結論

考慮到上述想法，專家繪制了下圖，列出了本文介紹的主要工具類別以及一些示例性工具。

因此，對開發(fā)人員友好的工作流引擎是使復雜的自定義流程自動化的合適選擇。低代碼方法也有其優(yōu)點，通常是在不需要太多管理的環(huán)境中自動執(zhí)行單個任務或簡單流程的時候。 

原文標題：Understanding the process automation landscape，作者：Bernd Ruecker

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】