【.com快译】与云原生业务一样，许多大型或老牌企业都希望尽可能自动化其运营。因此，许多公司对其流程自动化目标过于雄心勃勃，试图在整个组织内推出数字化转型项目。虽然雄心勃勃是件好事，但其中许多项目需要数年时间才能完成，通常需要对遗留系统进行改造。很少有公司认为端到端流程自动化需要在人员、流程和技术方面改变思维方式。查看三个最常见的流程自动化错误，以及组织如何共同努力来解决这些错误。1.过快启动战略性自动化项目虽然战略性并没有错，但过于宏大的想法是雄心勃勃的自动化项目的常见陷阱。过早承担过多的战略工作会带来很大的风险：企业在很长一段时间内看不到任何商业价值。结果，开发人员很可能陷入在不了解用例的情况下设计复杂平台的陷阱。相反，尝试将大型战略项目分解成多个部分，首先从最紧迫或最重要的项目开始。下面是一种方法：从试点项目开始：试点项目的目标是定义和验证架构和堆栈。该试点项目通常作为概念验证(PoC)。但是，为了真正了解整个软件开发生命周期(SDLC)中工作流解决方案的所有方面，进行试点项目非常重要。加快Lighthouse项目的速度：在成功运行试点项目后不久，应该着手处理Lighthouse项目。Lighthouse项目应该具有更广泛但仍然现实的范围，以向组织中的其他人员和团队展示工作流自动化的架构、工具和价值。进行大规模转型：利用从Lighthouse项目中汲取的经验教训，授权项目团队中的人员运行卓越中心(CoE)，打破团队之间的孤岛并推动整个组织的变革。我将这种方法称为“增量转换的艺术”。理想情况下，在着手大规模自动化项目之前，尝试绘制整个过程生态系统——包括后台办公室中涉及的人员、系统和设备。首先改造对客户影响最大的流程。然后设计一种适合业务或客户需求的转型方法，而不是您公司技术堆栈的需求。2.孤立地处理自动化项目虽然建议采用增量转换方法，但这并不意味着“孤立”或分散。如果每个团队都选择自己的工具，那么组织范围内的变革或端到端的流程自动化是很困难的。技术决策需要多年甚至数十年的承诺。这些决定和随之而来的维护不仅仅影响当前的一线团队。如上所述，CoE方法有助于打破组织孤岛并分享有关在以前的自动化项目中有效和无效的最佳实践。理想情况下，该小组不会规定任意标准，而是维护一套经过批准的工具和框架，这些工具和框架可以在整个公司内重复使用。除了工具之外，CoE还可以维护入门指南、项目模板和可重用的开源组件/库供团队使用。此外，他们还可以充当自动化代言人，通过运营社区提高公司内部对新自动化项目的认识。在这个框架内，更多的团队可以从他们所在行业的自动化潜力中得到启发。3.不采用微服务架构一个需要考虑的重要因素是公司内部构建软件的方式。传统公司拥抱微服务架构说起来容易做起来难。通常存在难以替换的遗留系统。据估计，仍有超过2000亿行代码是用COBOL这种已有数十年历史的编程语言编写的。大规模更换这些系统可能至少要花费4万亿到8万亿美元。这就是增量转换方法派上用场的地方。例如，许多公司已经通过在遗留系统（例如使用COBOL编写的系统）上实施RPA实现了初始自动化。适应这种情况的一个好方法是在三个主要阶段进行现代化：沿着端到端业务流程协调所有这些RPA机器人驱动的本地任务自动化。按优先顺序逐一淘汰这些机器人专注于将底层业务逻辑重写为微服务，这些微服务可以沿着端到端业务流程再次编排基于微服务的自动化工作流的优势在于它允许分散式架构，其中每个团队都“负责”自己的隔离过程。万一过程出现问题，它可以很容易地被控制和修复。然后，流程引擎可以在整个组织中“驱动”这些基于微服务的流程，并在必要时统一它们。总之，端到端的流程编排不可能凭空发生。整个组织的利益相关者都应该参与进来，项目应该从小处着手。如果没有明确定义的试点项目，大规模的战略自动化工作很容易无法展示商业价值。只有齐心协力确定优先级、创建最佳实践并推出所需的技术变革，组织才能确保成功的端到端流程自动化。原标题：3个常见的流程自动化错误（以及如何修复），作者：JakobFreund
