采购自动化架构

采购自动化实际上意味着什么？

"采购自动化"涵盖了一系列方法，从通过固定审批链路由请购单的基于规则的工作流自动化，到像人类一样操作现有屏幕的机器人流程自动化（RPA），再到在其之上增加文档理解或匹配逻辑的智能自动化。经同行评审的研究将 RPA 描述为 使用低代码软件程序来自动化重复的常规业务流程，并称之为企业软件类别中增长最快的技术。这些方法都不能替代采购到付款（procure-to-pay）流程；它们嵌入其中，每一个都接管一个特定且明确定义的步骤，这就是为什么有用的问题是，在这个流程中的哪些步骤 采购到付款架构 哪些足够例行，可以交给软件处理，而哪些仍然需要人工判断。

哪些工作流步骤应优先实现自动化，原因是什么？

有四个步骤作为早期的自动化候选对象反复出现，因为它们每一个都具有高业务量、受规则管辖且具有清晰的通过/失败结果：请购路由与审批、采购订单、收货与发票之间的三方匹配、请购获批后的采购订单签发，以及针对三方匹配标记的不符项的发票异常处理。当前的采购基准测试发现 自动化提升了利用批量折扣、整合采购以及减少人工操作带来的成本和错误的能力，这也是将这些步骤视为起点而非全部宏伟目标的依据。同类基准测试工作还提出了一个值得认真对待的条件： 流程标准化有助于确保对速度的追求不会导致错误增加，因此自动化一个 采购订单工作流 尚未标准化的流程只会以更快的速度传递不一致性，因为标准化必须在构建之前或构建过程中完成。

自动化路径必须保留哪些控制措施？

有两个控制原则从人工采购中完整保留下来，而自动化工作流必须在软件中将其体现出来，而不能假设它们在迁移后自然存续。第一项是职责分离：联邦权威控制指南对其的定义是 在不同人员之间划分关键职责和责任，以降低错误、滥用或欺诈的风险；将授权交易、处理和记录交易、审查交易以及处理任何相关资产的职责分离开来，确保没有任何个人能够控制交易或事件的所有关键方面。第二项是授权： 交易仅由在其职权范围内行事的个人授权和执行。在手动流程中，这些体现为不同的人在不同的办公桌上处理采购订单。而在自动化流程中，它们必须体现为角色模型、审批阈值配置以及权限映射，机器人或工作流引擎不能仅仅因为技术上能够写入其能访问到的所有字段，就可以悄悄绕过这些限制。

如何对“治理优先”的推广进行排序？

传统 ERP 集成究竟在哪里失败？数据孤岛又是从何而来？

采购自动化平台连接至 ERP 的节点，在实践中正是治理风险汇聚的地方，同时也是数据孤岛容易形成的地方——如果自动化系统保留了其独立于 ERP 的供应商、预算或审批数据副本，而没有将 ERP 视为单一数据源的话。某家自动化供应商自己的集成指南便明确指出了访问风险： 被授予超出其功能所需访问权限的连接器可能会读取其绝不应看到的数据，并写入其绝不应触及的字段。为了方便起见，通常在设置时授予广泛的访问权限，但这并非工作流的实际需求，这非常值得作为供应商提供的检查清单项来进行测试，而不是对任何特定供应商自有产品的宣称。同一指南指出了第二种更安静的故障模式： 涵盖人工操作但未记录自动化决策的审计线索是不完整的，在任何严肃的审计中都会产生审计发现。如果机器人批准了一张发票，该决策就需要拥有与人工审批相同的记录：应用了什么逻辑、使用了什么数据以及结果是什么。

为什么未经核实的自动化成本高于其节省的成本？

人们很容易将自动化视为一个部署问题：配置工具、将其指向流程并上线。基础的工作流验证研究警告我们不要跳过中间的步骤。通过对工作流管理系统的总体研究，研究人员发现 然而，其后果是很少有工作流在实际部署前经过彻底检查，这往往导致必须以临时应变的方式纠正错误，且通常成本高昂。这一发现比当今的低代码自动化平台早了二十年，而其根本问题并未消失：工作流规范是一段逻辑，而未经检查实际需要处理的选择、顺序和异常的逻辑，无论是由人还是由机器人执行，都会以同样的方式失效，只是机器人的失效速度更快、规模更大。 工作流规范语言需要支持对选择时刻、顺序执行、并行处理、同步以及迭代的规范说明 正是因为实际业务流程需要所有这些环节，而一个仅测试顺畅路径的试点根本没有验证过工作流。