超级自动化的正确打开方式（二）— 超级自动化执行

继上篇《超级自动化的正确打开方式》，我们已经对超级自动化有了初步认知，本篇文章会针对超级自动化-执行阶段进行解构。

超级自动化能力框架

超级自动化一词最早由Gartner在2019年提出，它是一个以交付工作为目的的集合体，是机器人流程自动化、流程挖掘、智能业务流程管理等多种技术能力与软件工具的组合，是智能流程自动化、集成自动化等概念的进一步延伸。超级自动化能够简化业务流程、提升业务执行效率，助力企业实现降本增效提质并释放创新活力，从而提升综合影响力和核心竞争力。

国内外大量RPA厂商、iBPMS厂商、iPaaS厂商、流程挖掘厂商等都声称自己提供的是超级自动化软件，虽然这些厂商都是超级自动化这一庞大技术集合体系中技术和软件工具的供应商，但由于各软件厂商所倡导的超级自动化理念和方向存在差异，会让超级自动化的概念被一定曲解，本次就带大家拆解超级自动化，以便理解其本质。

我将相对核心的能力进行了分层，见超级自动化能力框架如下：

 超级自动化能力框架

超级自动化能力框架主要分为三个层级：任务自动化层、流程自动化层、增强组件层，在做每层定义解释前，我们先来看个示例：

员工入职流程图

从上图可以看出以单职能视角完成的事项为任务级，而跨多个职能协作完成的一连串任务为流程级。任务自动化是自动运行某个任务的引擎，而流程自动化可以使得复杂工作流程变成自动化。基于此，支撑任务自动化的技术与工具为：机器人流程自动化和集成平台服务，支撑流程自动化的技术与工具会在任务自动化的基础上再增加：智能业务流程管理套件、低代码工具、决策管理套件、多体验开发平台等。

而增强组件，主要是基于AI能力和大数据能力、流程科学对流程自动化进行赋能，让流程自动化更加的智能，包含：人工智能、智能文档处理、任务挖掘/流程挖掘、数据编织等技术及工具组成。

超级自动化-执行

该阶段是以替代人们的重复劳动为目的，应具备的领域能力为：执行系统。

执行系统以iBPMS、LCAP、iPaaS、RPA等技术为主，致力于用协作流、执行流、数据流打破企业组织壁垒和资源孤岛(业务孤岛、应用孤岛、数据孤岛)，激活企业活力。

在“超级动化-执行”阶段，主要表现形式为“任务自动化”和“流程自动化”，在前文中简述了“任务”和“流程”的区别，为了更好地帮助大家理解，这里引入“业务流程分级图”，见下图：

业务流程分级图

业务流程一共可以分为5个级别：

● Level 1 为公司价值链层，是整个组织最高级别的流程图，是组织创造价值最核心的价值环节，比如图中“人力资源管理”作为企业核心价值环节之一，和它同级的一般还有销售管理、产品管理、研发管理等。

● Level 2 为业务流程链层，代表了一组相连接的(串行的或并行的)业务流程，是描述组织某个价值环节所涉及的全部流程，比如图中“培训与发展管理”是作为人力资源领域中的一个细分领域，在人力资源领域还会有如招聘管理、绩效管理、人才管理等细分领域。

● Level 3 为流程层，该层是上层业务流程链中的一个具体流程，比如图中“培训管理”隶属于培训与发展管理的领域，是一个可以具体落地的流程，而Level 1和Level 2的层级相对抽象，不能直接作为具体落地的流程。

● Level 4 为活动层，该层代表了一系列组成流程的活动，用来描述该流程是如何实现的，比如图中“培训申请”是作为一个活动，后续活动可能会有：培训审批、培训排期、通知具体培训信息、培训认证等围绕培训管理闭环的一系列活动。

● Level 5 为步骤层，该层代表为完成活动而进行的一系列步骤的详细信息，每个方框都是具体的动作或程序，是怎么完成活动的具体描述。

基于以上信息，我们就可以更好地解释和理解“任务自动化”和“流程自动化”，“任务自动化”就是Level 4 活动层中的一个“活动”，并把这个“活动”所对应的Level 5中所有“步骤”尽可能地自动化。“流程自动化”就是Level 3 流程层中的一个“流程”，并把这个“流程”所对应的Level 4 中所有“活动”，及所有“活动”所对应的Level 5 中所有“步骤”尽可能地自动化。所以流程自动化比任务自动化高一个维度，需要把多个任务进行组合编排，所以在超级自动化能力框架图中看到流程自动化比任务自动化多了几种技术组件，分别是智能业务流程管理套件、低代码工具、决策管理套件、多体验开发平台等。

任务自动化典型代表技术组件是机器人流程自动化(RPA)和集成平台服务(iPaaS)，两种技术都可以代替人去执行重复的任务活动，可以被代替的主要任务活动为：PC界面操作、移动端界面操作、应用系统操作、数据相关操作等。通过下面这张任务自动化透视图，直观了解RPA和iPaaS是如何进行自动化的。

任务自动化透视图

RPA主要通过UI抓取(桌面元素、网页元素拾取)实现自动化，可以模拟用户在PC端和移动端的大部分操作，能对桌面办公软件、web浏览器、B/S及C/S应用软件、移动应用进行自动化操作，兼容性较高，比较灵活。

iPaaS主要通过API集成、数据集成、应用集成、批量Agent脚本执行等能力，可以直接与应用系统、应用数据进行高频交互，稳定性高。两种任务自动化技术各有特点及优势，在我们实际落地超级自动化场景时，这两种技术需要相互配合与互补，基于用户场景使用最适合的任务自动化技术组件。

从上图我们可以看到，C/S架构还是B/S架构的应用系统一般都采用三层架构：表现层(UI, User Interface Layer)，业务逻辑层(BLL, Business Logic Layer)，数据访问层(DAL, Data Access Layer)。RPA通过PC端和移动端设备前台访问B/S、C/S应用系统的UI层，代替人来完成人机交互操作。而iPaaS则通过API与JDBC等数据通讯协议与B/S、C/S应用系统的应用层和数据层进行后台调用。

那既然两种技术都可以完成对应用系统的交互，我们该如何选择呢，请看下表所示：

接下来我们来看两个场景，分别对应应用软件操作和数据相关操作，首先是应用软件操作的场景，见下图：

 员工入职场景下的RPA与iPaaS

上图为一个员工入职场景的推演，其中RPA路径为：用户表单录入或者Excel导入新员工的信息 → RPA开始分别登录多个系统，每打开一个系统会把新员工信息从前台界面录入，然后再开下一个系统，依次循环进行 → 信息全部录入后，通过邮件把汇总信息发送给用户。

iPaaS的路径为：用户表单录入或Excel导入新员工的信息 → iPaaS后台并发调用多个系统接口，将用户录入新员工信息转换成参数在多个系统内创造好账户 → 创建后的信息统一汇总发邮件给到用户。

两种路径对比如下：

再来看一个数据查询场景，见下图：

 数据查询场景下的RPA与iPaaS

上图为一个数据查询场景的推演，其中RPA路径为：用户表单录入查询请求 → RPA开始分别登录多个系统，每打开一个系统会从前台界面下载数据，然后再打开下一个系统，依次循环进行 → 数据全部下载后，打开Excel进行本地数据操作(计算处理) → 最后把整理好的数据，通过邮件发送给用户。

iPaaS的路径为：用户表单录入查询请求 → iPaaS会把事先构建好的数据服务直接返回数据(事先iPaaS会通过数据集成能力把不同系统的数据源同步到iPaaS，再通过简单的数据建模用SQL查询包装成一个数据服务供调用) → 用户可以在界面上直接看到数据查询的结果。

两种路径对比如下：

综上所示，任务自动化的技术选择方法：界面操作场景、被操作的应用系统无API接口时和数据权限时首选RPA，其他默认选择iPaaS。

经过上面的介绍，我们对任务自动化有了一定认知，并且从业务流程分级图已知流程自动化需要调度和编排多个任务自动化来完成一个较为复杂的业务场景，需要RPA和iPaaS技术组件的基础上引入智能业务流程管理套件(iBPMS)、低代码工具(LCAP)、决策管理套件(DMS)、多体验开发平台(MXDP)等组件。

业务流程自动化不仅需要调度和编排任务自动化，更主要的是实际业务场景需要跨职能、部门的人员进行协作，所以需要流程自动化不仅需要具备流程引擎调度外部自动化的能力，还需要表单引擎建立表单后让人参与进来，与流程进行交互，包括审批等动作，而表单引擎和流程引擎就是典型iBPMS所必须具备的能力。在业务流程中“审批”动作不是为了审批而审批，更多是一种决策，流程引擎通过审批节点让人进行审批决策，而很多审批决策是可以被固化下来的，完成自动审批决策，这就需要引入DMS，它能通过规则引擎将决策因子用规则矩阵视图进行统一配置，当然DMS不仅仅只有基于规则的决策，还有基于大数据分析和AI算法的延伸，这部分内容会在后续超级自动化-智能阶段及DMS独立章节进行展开。

为了满足不断变化的业务，业务流程的配置过程也需要敏捷快速，则可以引入LCAP进行图形化拖拉拽编排快速上线，同时为了人更好的参与流程协作，则需要让流程能在多端(PC端、移动端等)上进行操作，可以引入MXDP来加速多端交互界面的开发。接下来我们来看下业务流程自动化全景框架图(这里需要说明：部分技术组件的边界不一定会如此清晰，实际产品在规划时为赢得更多卖点，技术组件衍生的产品边界感会变得模糊)，见下图：

业务流程自动化全景框架图

 业务自动化产品界面图

我们来一起解构这张图，首先由iBPMS构建起主业务流程，分为三个节点：

节点1为“申请节点”

节点2为“审批节点”

节点3为“自动化节点”

节点1与节点2分别由两个用户进行协作，一位用户通过PC端来访问，一位用户通过移动端的H5页面进行访问，一个流程多端的交互体验由MXDP进行编排加速交付，用户A通过节点1完成申请表单的填写，流程流转到节点2的审批节点，该审批节点既可以让用户B进行主观审批，也可以基于审批决策的规则用DMS完成自动审批(有些iBPMS产品会把部分DMS能力集成在一起)，当流程审批完成后，流程流转到节点3的自动化节点，该节点可以通过标准API协议(如Webservice、RESTful等)与第三方系统进行交互，这里自动化节点与任务自动化编排后的工作流所生成的API进行交互，任务自动化通过iPaaS和RPA与PC、移动端、应用系统、数据、AI服务等进行交互调用操作，当任务自动化完后会把执行结果节点3的自动化节点，即业务流程自动化的主流程执行完成。同时 iBPMS的流程编排、任务自动化的执行任务编排、MXDP多端交互体验进行页面编排都应用LCAP的技术理念(与其说LCAP是一种独立的产品，我更想讲LCAP是一个产品设计理念，应用了LCAP设计理念的产品都可以称之为LCAP类的产品，但该类产品可以横跨多个领域)，可以让用户使用图形化拖拉拽的方式快速进行编排配置。

下面给大家一个业务流程自动化工具选择的框架，帮助大家在实际场景中，选择适合自己场景的自动化技术组件，见下图：

业务流程自动化工具的选择路径

上图中绿色模块为超级自动化框架里的技术组件，蓝色模块为传统技术手段，如果你的场景最终路径指向蓝色模块，即代表你的场景不适合使用超级自动化进行落地或改进。

最后我们来看一个实际场景来结束“超级自动化-执行”阶段的拆解，举例的是一个证券行业通用的场景，场景名字叫“证券代码段变更”，场景背景是目前证券交易所会不定期给各个证券公司以邮件的形式告知哪些股票上新、哪些股票退市了，因为这属于重要业务信息，需要及时更新到各家的证券股票软件里，所以每家证券公司都会安排专人负责收取邮件，第一时间收到邮件后，走流程最终完成变更，中间涉及多个角色和多个操作动作(变更、复核等)，流程冗长且重要，所以证券公司就希望把该流程线上化、并自动化，流程图如下：

证券代码段变更场景解构图

场景路径推演

步骤1：通过iPaaS的应用集成能力不定期轮询邮箱系统。

步骤2：当匹配到对应邮件信息，触发iPaaS工作流A，提取邮件相应信息后调用iBPMS流程接口触发流程。

步骤3：iBPMS节点A会把变更内容在表单内进行展示，同时提供受理人审批表单。

步骤4：当上一步完成审批后，iBPMS节点B会为负责人提供审批表单。

步骤5：当上一步完成审批后，iBPMS节点C为自动化节点，触发接口调用。

步骤6：通过API调用iPaaS工作流B接口，触发iPaaS工作流B。

步骤7：根据变更代码段的表单自动转换SQL，并通过JDBC协议与柜台系统数据库进行调用，完成数据备份操作。

步骤8：柜台系统数据库完成执行后返回结果。

步骤9：iBPMS节点C接收到iPaaS工作流B执行成功结果后，流转到iBPMS节点D。

步骤10：由于柜台系统无法提供API接口，所以只能通过RPA模拟人为操作对柜台系统UI界面进行操作，触发RPA工作流A。

步骤11：RPA工作流A开始工作，依次完成“打开C/S应用程序”、“变更信息界面操作”、“提交确认”动作。

步骤12：此步为RPA与柜台系统UI界面交互。

步骤13：iBPMS节点D接收到RPA工作流A执行成功结果后，流转到iBPMS节点E。

步骤14：通过API调用iPaaS工作流C接口，触发iPaaS工作流C。

步骤15：根据变更代码段的表单自动转换SQL，并通过JDBC协议与柜台系统数据库进行调用，完成变更结果查询进行复核。

步骤16：柜台系统数据库完成执行后返回结果。

步骤17：iBPMS节点F接收到iPaaS工作流C执行成功结果后，人为判断执行结果，判断是否变更成功。

综上所述，我们一起对超级自动化-执行阶段的“任务自动化”和“流程自动化”进行了解构，该阶段解决方案和产品已经相对成熟，各位可以基于自身组织的情况，进行一定尝试。另外OCR、NLP、IDP等技术与任务自动化、流程自动化的结合也有非常多的实践场景，这些内容会在后续文章的超级自动化-智能阶段去给大家进行陈述。最后希望本文对您有帮助，如果描述不准确的情况，还请见谅。

撰文：精鲲科技CTO 葛丁佳