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

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

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

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

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

其他流程自動(dòng)化用例明顯超出這個(gè)范圍：

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

現(xiàn)在有兩種截然不同的數(shù)字或集成流程：

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

在自定義標(biāo)準(zhǔn)軟件時(shí)，這兩個(gè)類別之間有一些灰色區(qū)域。但由于在過去的糟糕經(jīng)歷，很多組織在這方面變得越來越謹(jǐn)慎。

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

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

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

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

低代碼任務(wù)自動(dòng)化

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

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

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

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

開發(fā)人員友好的任務(wù)自動(dòng)化

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

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

與低代碼解決方案相比，開發(fā)人員友好型解決方案要求軟件開發(fā)人員參與其中。另一方面，這些開發(fā)人員通常非常有效率，因?yàn)樗麄兛梢栽谝阎亩褩Ｖ泄ぷ鳌６遥玫降慕鉀Q方案通常更穩(wěn)定，并且可以解決更復(fù)雜的問題。

邏輯鏈任務(wù)自動(dòng)化

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

有兩類工具致力于提供對(duì)這些任務(wù)鏈的可見性：

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

低代碼流程自動(dòng)化

流程自動(dòng)化工具使多步驟流程的控制流程自動(dòng)化。它們的關(guān)注重點(diǎn)不再是單個(gè)任務(wù)，而是更多地關(guān)注任務(wù)之間的相互作用。流程通常在本質(zhì)上是長期運(yùn)行的，這會(huì)導(dǎo)致對(duì)工具有著自己的要求(持久性、操作工具等)。

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

• 傳統(tǒng)業(yè)務(wù)流程管理套件(BPMS)：調(diào)研機(jī)構(gòu)Gartner公司現(xiàn)在將其稱為“智能業(yè)務(wù)流程管理套件”(iBPMS)，該領(lǐng)域的工具包括Pega和Appian。
• 集成平臺(tái)即服務(wù)(iPaaS)工具：iPaaS產(chǎn)品提供了實(shí)現(xiàn)流程邏輯的基本可能性。示例包括Tray.io和Process Street。
• 機(jī)器人流程自動(dòng)化(RPA)工具：機(jī)器人流程自動(dòng)化(RPA)工具有時(shí)被濫用以使流程自動(dòng)化，建議不要這樣做。

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

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

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

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

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

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

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

有時(shí)，還會(huì)在流程自動(dòng)化項(xiàng)目的場景中評(píng)估沒有特定流程自動(dòng)化支持的工具類別。數(shù)據(jù)管道就是一個(gè)很好的例子。由于它們通常可以圖形化建模，因此很多人將它們用于流程自動(dòng)化。

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

當(dāng)然，也可以簡單地對(duì)所有內(nèi)容進(jìn)行硬編碼以使流程自動(dòng)化，從而產(chǎn)生自定義的工作流引擎，應(yīng)該避免使用它。

結(jié)論

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

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

原文標(biāo)題：Understanding the process automation landscape，作者：Bernd Ruecker

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】