【51CTO.com快译】像云原生企业一样，许多大型或老牌企业希望尽可能提高运营的自动化程度。因此，许多企业在流程自动化目标方面过于雄心勃勃，试图推出面向整个组织的数字化转型项目。虽然有野心是好事，但许多这类项目需要数年才能完成，常常需要将遗留系统推倒重来。
很少有企业考虑到端到端流程自动化需要在人员、流程和技术等方面改变观念。不妨看看三个最常见的流程自动化错误，以及企业如何协同解决这些错误。
一、推出战略性自动化项目过快
虽然力求战略性没有错，但考虑过大的规模是过于雄心勃勃的自动化项目的常见陷阱。过早承担太多的战略性工作带来很大的风险：企业在很长一段时间内看不到任何业务价值。因此，开发人员很可能陷入这种困境：在不了解用例的情况下设计一种复杂平台。
相反，尝试将庞大的战略性项目分成几部分，先从最紧急或最重要的项目入手。以下是这么做的一种方法：
- 从试点项目开始：试点项目的目标是定义并验证架构和堆栈。这个试点项目通常充当概念验证(PoC)。然而，上线试点项目很重要，以便真正了解工作流解决方案在整个软件开发生命周期(SDLC)的所有方面。
- 加快到灯塔项目：运行成功的试点项目后不久，应处理灯塔项目。灯塔项目应该有更广泛但仍然切合实际的范围，以便向贵组织的其他人和团队展示工作流自动化的架构、工具和价值。
- 进入到大规模转型：利用从灯塔项目汲取的经验教训，使该项目团队的人员能够运行卓越中心(CoE)，从而打破团队之间的孤岛，并推动面向整个组织的变革。
我称这种方法为“渐进式转型的艺术”。理想情况下，在开展大规模自动化项目之前，尝试勾勒整个流程生态系统——包括在后台的相关人员、系统和设备。先更新改造对客户影响最大的流程。然后设计一种转型方法，适合业务或客户的需求，而不是适合贵公司技术堆栈的需求。
二、孤立地处理自动化项目
尽管建议采用渐进式转型方法，但并不意味着“孤立”或不成体系。如果每个团队都选择自己的工具，很难实现面向整个组织的变革或端到端流程自动化。技术决策需要承诺多年甚至数十年的投入。这些决策和随之而来的维护影响的不仅仅是当前的一线团队。
如上所述，CoE方法有助于打破组织孤岛，分享关于以前的自动化项目中哪些管用、哪些不管用的优秀实践。理想情况下，该小组并不硬性规定任意标准，而是维护可在整个公司重复使用的一系列已批准的工具和框架。
除了工具外，CoE 还可以维护入门指南、项目模板和可重用的开源组件/库，供团队利用。此外，它们还可以充当自动化代言人，通过运作社区针对公司内部的新自动化项目加强宣传。在此框架内，更多团队可以从自动化在本部门内的潜力中获得启发。
三、未拥抱微服务架构
要考虑的一个重要因素是公司内部构建软件的方式。传统公司拥抱微服务架构说起来容易做起来难。常常存在难以取代的遗留系统。据估计，仍有超过2000亿行代码是用COBOL(一种有数十年历史的编程语言)编写的。大规模更换这些系统可能至少需要4万亿美元到8万亿美元。
这时候渐进式转型方法有了用武之地。比如说，许多公司已实施了初步自动化，RPA 实施在遗留系统(比如用COBOL编写的系统)上。适合这种场景的好方法就是，分三个主要阶段进行现代化改造：
- 沿端到端业务流程编排所有这些RPA机器人驱动的本地任务自动化。
- 按优先级顺序逐一弃用这些机器人
- 致力于将底层业务逻辑重写成微服务，而微服务可以沿端到端业务流程再次加以编排
基于微服务的自动化工作流具有的优势在于，它允许分散式架构，其中每个团队“负责”各自的隔离流程。万一某个流程出现了问题，可以轻松控制和修复问题。此后，流程引擎可以在整个组织“驱动”这些基于微服务的流程，并且在必要时将这些流程统一起来。
总之，端到端流程编排不可能凭空发生。整个组织的利益相关者都应参与进来，项目应该从小处着手。如果没有明确的试点项目，大规模的战略性自动化工作很容易无法证明业务价值。只有齐心协力确定优先级、创建优秀实践并推出所需的技术变革，组织才可以确保端到端流程自动化成功实现。
原文标题：3 common process automation mistakes (and how to fix them)，作者：Jakob Freund
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
