流程自动化可以使得复杂工作流程变成自动化，这个自动化流程中无需人工干预审核，而任务自动化是自动运行某个任务的引擎。流程自动化与任务自动化是有区别的：
2015年，德国电信开始应用机器人流程自动化（RPA），它是整个流程自动化领域中众多工具之一。随着时间的流逝，该公司成功开发了一支由2500多个RPA“机器人”组成的军队。但是他们还必须了解，即使RPA的名称是“流程自动化”，它也不能真正实现流程的自动化，而是实现任务的自动化。
这是一个常见的误解，其根源在于流程自动化领域的复杂性，在该领域中，工具类别是多维的并且难以捕获。在本文中，我将回答几乎每天都被问到的问题（什么是流程自动化？），并概述流程自动化领域发展情况。
为了简洁起见，我将流程自动化的范围缩小到以下范围：
- 业务流程和数字流程：这是您从大多数公司了解的典型业务流程（例如客户入职，索赔清算，贷款发起，订单履行），通常跨越两个不同的端到端系统。如今，“数字流程”一词似乎很受欢迎，因为“业务流程”一词通常被认为是老派。
- 集成流程：专注于系统或服务集成的流程，例如，在进行远程通信时协调微服务或保证一致性。
其他流程自动化用例显然不在范围内：
- 不受信任的参与者（例如独立公司）之间的流程：这是区块链的潜在设置。
- 基础架构供应或IT自动化（例如Ansible，Terraform）：这是具有专用工具的独立域。
- 持续集成/持续交付（例如Jenkins，GitHub Workflows）：CI / CD构建管道是软件工程中的标准流程，由标准软件实现自动化。
- 物联网（例如，红色的节点）：物联网用例通常通过专用工具解决，我将其归类为任务自动化。为简单起见，我将不在本文讨论范围之内。
现在，有两种非常不同的数字或集成流程类型：
- 标准流程：每当您的公司不想通过流程进行区分时，您都可以购买商业现成的软件（COTS），例如ERP，CRM或HR系统。在这种情况下，通常需要使工作流程适应该软件。
- 量身定制的流程：某些流程是组织所特有的，因此需要针对组织的需求进行量身定制。尽管这些流程在不同组织中可能是相同的（例如，客户入职，订单管理，理赔），但是组织设计和实现它们的方式却是独特的，可以帮助他们在市场中脱颖而出。这使组织更具竞争力，可以更有效地开展业务，降低成本，增加收入，并转变为更具数字化的业务。
自动化定制流程的软件
量身定制的流程涉及构建用于流程自动化的软件。这是“构建软件的软件”，可以按照两个维度（工具的性质和自动化的性质）粗略分类，如下所示：
- 流程自动化关注自动化流程的控制流程。它着重于任务的顺序，而不是单个任务。任务自动化可自动完成流程中的单个任务，例如，通过与某些系统集成。
- 对开发人员友好的工具无缝地集成在典型的开发人员工具堆栈和流程中，但是为开发人员解决了特定于流程自动化的某些问题（例如，提供了流程状态的持久性，图形化的流程模型，流程模型的版本控制）。开发人员友好的工具需要软件开发才能构建解决方案。
- 低代码工具允许非开发人员通过提供复杂的图形用户界面和向导来隐藏隐藏的技术细节，从而实现自动化逻辑。这允许不同的角色来构建解决方案，但也限制了可能性，并且需要专有技术。
有了这两个维度，您就可以将工具归入下一部分所述的四个主要区域中。
低代码任务自动化
低代码任务自动化的典型示例包括应用程序集成工具和RPA：
- 应用集成工具（如Zapier，IFTTT，Tray.io，Integromat）：当一些事件发生，例如插入新的数据到应用集成工具可以执行的操作Airtable当Trello完成卡。其中一些工具超出了任务自动化的范围，还提供了基本的流程自动化功能（例如tray.io）。
- 机器人流程自动化（RPA）工具（例如UiPath）：RPA工具可以在不提供任何API的旧系统中自动执行任务。这与屏幕抓取和模拟鼠标或键盘操作有关，类似于Microsoft Office宏记录器。
低代码任务自动化工具非常适合单独解决简单的集成问题，并有助于消除手动集成工作，例如将数据从系统A复制到系统B。即时业务价值是RPA如此成功的原因。
但是，自动化范围必须足够简单。并请注意，生成的解决方案通常未经测试，幼稚且难以维护。许多解决方案将重点放在快乐的情况上，而忘记了例外情况，这些例外情况在生产中会意外受到打击，并且常常不被注意。这会使解决方案变得脆弱。
开发人员友好的任务自动化
以对开发人员友好的方式自动化单个任务通常意味着不仅要利用软件开发，还要利用以下各项：
- 集成框架（例如Apache Camel）：集成框架使开发人员可以轻松完成某些任务，例如与文件系统，消息中间件和其他接口技术的通信。
- 批处理：自动执行单个任务的经典方法是使用批处理作业，该作业将此任务应用于特定数据集中的每一行。
- 事件驱动体系结构（EDA）：组件可以对流中的数据做出反应，而无需知道该数据来自何处。通用工具包括Apache Kafka之类的事件代理。
与低代码解决方案相比，开发人员友好型解决方案要求软件开发人员参与其中。另一方面，这些开发人员通常非常有生产力，因为他们可以在他们已知的堆栈中工作。而且，所得解决方案通常更稳定，并且可以解决更复杂的问题。
链接任务自动化
任务自动化工具不能实现业务流程。但是，一系列RPA机器人，集成任务或事件订阅可能会形成实现业务流程的逻辑链。这带来了两个挑战。首先，流程没有自己的持久性，这使得很难确定任何实例的当前状态。其次，控制流逻辑到处可见，这使得这些架构难以理解和维护。
有两类工具致力于提供对这些任务链的可见性：
- 流程挖掘工具：这些产品可以帮助您了解如何使用大量旧版工具实际实现流程自动化。通常，这涉及从这些系统加载和分析一堆日志文件，发现相关性以及映射流程。
- 流程事件监视工具：这些工具允许用户将事件映射到即时提供或发现的流程模型。与通常基于日志文件分析的流程挖掘相反，流程事件监视着重于摄取实时事件流，这可能是由事件驱动的体系结构产生的。
低代码流程自动化
流程自动化工具使多步骤流程的控制流程自动化。他们的关注点不再是单个任务，而是更多地关注任务之间的相互作用。流程通常本质上是长时间运行的，这导致它们对工具有自己的要求（持久性，操作工具等）。
低代码工具旨在允许非开发人员实施这些流程。典型的工具类别包括：
- 传统业务流程管理套件（BPMS）：Gartner现在将其称为“智能” BPMS（iBPMS），该领域的工具包括Pega和Appian。
- 集成平台即服务（iPaaS）工具： iPaaS产品提供了实现流程逻辑的基本可能性。例如Tray.io和Process Street。
- 机器人流程自动化（RPA）工具：有时会滥用RPA工具来使流程自动化。我强烈建议您不要这样做，但为了完整起见，我想在此包括此选项。
其中一些工具确实可以帮助自动化简单的流程。如果您是一家初创企业，则可能会熟悉一组典型的SaaS应用程序，然后使用iPaaS解决方案进行充分连接。但是，这些方法在复杂的业务流程或集成方案中是不够的。
我经常发现，低代码产品无法兑现其承诺，而且技术娴熟的公民开发人员也无法自己实现核心流程。结果，公司不得不回到求助于到他们的IT部门，并要求他们指派专业的软件开发人员来完成这项工作，而这些工作反过来对专有的低代码堆栈没有帮助。
开发人员友好的流程自动化
有一些工具可以使软件开发人员有效地进行流程自动化项目：
- 对开发人员友好的工作流引擎，流程编排器或微服务编排器，有以下三种形式：
- 开源产品：与企业版本，购自供应商，例如轻量级的工具Camunda，JBoss的jBPM的，或flowable。拥有一个活跃的开源项目和社区，再加上依赖于收入流的供应商的保证，是一个很好的组合。
- SaaS：许多工具以托管服务的形式提供，或者仅作为SaaS提供，例如AWS Step Functions或Google Workflow，也可以作为现有开源产品（例如Camunda Cloud）的托管版本提供。请注意，目前大多数云提供商都将重点更多地放在集成上，而不是业务流程上。
- 开源项目：较大的组织通常会开发自己的本地工具堆栈，包括工作流引擎。其中一些工具是在开放源代码许可下提供的，但没有任何可能的支持，保证或影响路线图的可能性。这些工具是针对环境的，因为它们是针对某个特定组织而不是针对整个市场而构建的。著名的例子是Netflix Conductor和Uber Cadence，后者是相对较新的初创公司Temporal的基础。
- 数字流程自动化（DPA）：该类别基本上扩展了BPMS类别，以在数字转换的背景下专注于数字端到端流程。这一广泛类别的界限根本不清晰。这里概述的所有类别的许多供应商都出于营销原因要求DPA。鉴于数字化和端到端流程自动化本质上是复杂的，因此我将这一类别归入对开发人员友好的流程自动化中。
有时，还会在流程自动化项目的上下文中评估没有特定流程自动化支持的工具类别。数据管道就是一个很好的例子。由于它们通常可以图形化建模，因此人们很想将它们用于流程自动化。
- 数据管道（例如Apache Airflow，Spring Cloud Data Flow）：这些工具具有不同的重点，因此缺少流程自动化用例的重要功能，例如对诸如循环之类的控制流结构的支持。此外，这些工具没有自己的持久性实现，因此流程实例的状态是流经管道的数据项。
当然，也可以简单地对所有内容进行硬编码以使流程自动化，从而产生定制的工作流引擎，您应该避免使用它。