|
来自哈塞尔特大学商业与经济学院的的Mieke Jans团队基于欧洲一跨国机构，探究了流程挖掘对于企业内部审计的影响。该研究发现使用流程挖掘的分析方法相比传统审计方法能够更加有效地识别出渎职，未经批准的款项挪动，违反公司规范程序等问题。以下内容来自该文章《Does Process Mining Add to Internal Auditing? An Experience Report》。商业流程挖掘（或短期流程挖掘）是一门相对来说年轻的学科，它的目标是基于系统中实际的交易账单来确定一种程序模型。流程挖掘可以用于内部审计是由于它拥有三个特性：受审方无法影响该程序对于数据的使用，此数据我们称之为“元数据”。这个特性使得审计人员可以客观精确地重构交易过程。审计人员不需要设计程序模型，而是使用该过程发掘的实际的程序模型，并作为进一步流程的起点。流程挖掘可拓宽控制范围与细节。目前内部审计的数据分析基本上局限于监视内部控制，而这种方法再比较灵活的情况下很难保证准确性。因此需要一个流程来测试其与设计模型的偏差，而这是流程挖掘可以提供的。该团队基于欧洲一金融服务提供商进行该项目。团队进行了四组分析，在第一组中，集中分析流程中活动的顺序。在第二组中，分析人员的角色，例如批准人或采购订单创建者的角色。在第三组分析中，运行一些更详细的测试，以验证某些断言（验证阶段）。在第四组测试中，研究人员考察了一些社交网络。研究人员人为在一个组织内共同从事某项工作的人之间会存在社交网。而在该项目进行前，首先进行了传统的审计。而加入流程挖掘的审计方法发现了一些传统内部控制中未能发现的问题。在这一部分中研究人员检测了流程挖掘到底能为内部审计带来怎样的价值。商业流程管理中心（一个由昆士兰大学等高校联合组织的联合机构）是这样描述的：“流程挖掘的基本思想是从信息系统记录的事件中提取知识。然而这些事件中的信息很少用于分析底层流程。流程挖掘旨在通过提供从事件日志中发现流程、控制、数据、组织和社会结构的技术和工具来改进这一点”。如引用所示，用于流程挖掘的数据源是一个事件日志，通常称为“history”, ”audit trail”, ”transaction log”等。由于数据库和计算机网络技术的成熟，如今任何规模的大多数企业都采用电子方式存储数据，包括日志数据。流程挖掘是一个术语，包含了从一组实际执行中的真实数据中提取结构化流程描述的所有方法。在流程挖掘中使用的事件日志将从信息系统(IS)中提取。为了挖掘进程，在IS中捕获的数据必须满足一些条件。更准确地说，需要满足四个特征：例如，拥有唯一标识符000001的事件指的是2011年2月5日由Ann Smith(发起人)发出的采购订单4603(案例)的一个标记(活动)(时间戳)。这四个特征是由信息系统(在大多数情况下是企业资源规划(ERP)系统)记录的，并且不受员工的影响。在本文的上下文中，该数据被称为元数据，因为它记录了关于真实数据(即购买订单)注册的信息，即活动、案例、发起者和时间戳。为了审查流程挖掘对内部审计价值，在一个大型跨国欧洲银行的采购过程进行内部审计，并使用流程挖掘技术。作者是该银行外部研究人员，可以访问相关数据，也可以访问内部审计人员。选择采购过程是因为它是大多数组织中典型的、标准化的过程，在损益表费用中占很大一部分，而且涉及到财务报告活动。流程的选择还受到日志数据可用性的影响。在应用流程挖掘之前，采购部门要接受标准的内部审计。这样就可以比较发现的问题。在挖掘流程之前，已设计的流程对审核员来说应该是清晰的，以便识别哪些活动构成了流程。在这之后执行流程分析。为了收集所需的信息，研究人员应用了各种方法，如对执行人员(业务和信息系统专家)进行访谈，对各个部门的员工进行询问和观察，和对ERP系统的内部使用指南进行咨询。在执行流程分析之后，将从存储的日志数据中构建适当的事件日志。为了挖掘这些数据，需要将数据配置为具有流程挖掘中固有的格式要求的事件日志。这种格式构造了围绕构成流程的活动的相关数据。在研究中，所有2007年1月的发票都可以追溯到其所附的采购订单，之后研究人员将在整个采购过程中跟踪这些订单。团队并没有从这些数据中抽取样本，而是分析了整个群体。这种方法证明了这些技术在按月计算的人口基数上是适用的。一旦创建了事件日志，就可以通过应用几个流程挖掘技术对流程进行审计。一共进行了四类分析:在案例公司中，采购流程嵌入在ERP系统中，其结构如图1中的流程图所示。该过程由采购单元的人员创建采购订单(以下简称PO)触发。此订单由两个不同的人签署和发布并批准。一旦订单生效，采购单元的员工可以与供应商一起订购货物。这发生在ERP系统之外，因此没有在流程图中描述。供应商发送货物和随附的发票。如果‘收货’和‘发票’两份文件同时录入系统，会计部门将会记账。最后一个活动将触发支付。付款是在没有任何人为影响的情况下发生的，并存储在另一个信息系统中，不被视为与“订货发票”不同的活动。因此，我们将活动描述为“支付”，而不是“订货发票”。该系统进一步允许更改PO，有时会形成新的途径。但是图1中没有描述这一点，因为这并不构成最佳的设计流程。图1中描述的流程是已设计的流程模型。当在实践中执行这个流程时，可能会偏离指定的模型。例如，可以在PO创建之后对其进行一些更改，这可能会触发一个新的“sign”和“release”活动。这将导致一个不在流程模型中的额外活动(' change PO ')，以及一个重定向到活动' sign '和' release '的额外箭头。另一个例子是多次发送的货物。这将导致额外的收货指令，可能随后出现多个发票，从而导致多次“收到发票”行为。可以建议以系统不支持或不执行这些偏差的方式配置ERP设置，但这将导致不可操作性和不灵活性，这通常是不能接受的。因此，实际的过程执行可能会严重偏离设计的过程，并且仅监控内部控制(为了操作原因考虑这些偏差)不会显示出与设计的模型的偏差。值得注意的是，来自设计模型的异常不是每个定义内部控制失败。一些偏离过程的执行是正常的，其他是次优的，其他是异常值。需要对细节进行测试来分析这一点。在本例研究中，研究人员在整个总体上执行这些测试，包括申请流程视图的应用。2、通过将这些案例与关键活动联系起来，在整个过程中跟踪的案例或流程实例是什么?在这个案例研究中，研究人员基于流程分析步骤中收集的信息选择在事件日志中包含的活动。图1中的六个矩形表示的六个活动被选择合并到事件日志中。我们确定了一个额外的活动:执行更改。除了活动的选择之外，还需要选择流程实例。流程实例是一个可以被识别的独特的案例或主题，可以通过链接一个独特的ID全程跟踪并识别它。对于的流程实例选择，研究人员说到：”我们选择了一个PO的行项，以便在整个流程中跟踪它。我们更喜欢这种详细的PO项目级别，而不是整个PO，因为在财务分类账中发票的预订是基于项目级别的。但是，活动“创建PO”、“签署”和“发布”指的是项目行所属的母PO，因为在创建项目行时没有可用的时间戳，而且签署和发布是在PO级别上执行的，如前所述”。对于上述选择中的每个活动，从ERP系统中提取时间戳和发起者，并链接到相应的流程实例(PO项目行)。通过这种方式，一个活动流(或审计轨迹)被存储在每个被调查的流程实例中。一个案例的审计轨迹可以如下所示:Create PO - Sign - Release - GR - Change Line - IR - Pay.事件日志包含了26185个流程实例，181845个活动，涉及272个发起者。审计轨迹至少包含四个事件，平均包含六个事件，最多包含390个事件。通过前述四种分析（具体分析过程见原文），发现了值得进一步调查的以下问题：-在26185份订单中，有3份通过了内部控制系统，没有任何sign或release。-发生175次违反货物收讫和放行的责任隔离原则的事件(由三人提出)。-265项付款(共31817项)与发票无关，而是与另一种单据类型有关。这些付款集中在46个流程实例中。-尽管收货指示器出现标记，有3个PO没有在系统中显示收货条目。-742例未出现sign活动，但未满足该异常发生的条件。这些问题仅使用过程挖掘方法确定，而不是在传统的内部审计期间确定。在传统的内部审计和伴随的内部控制评价过程中，没有发现内部控制问题。在不检测所有人群的情况下，发现这些问题的机会很小。我们为流程挖掘方法发现问题总结了三个原因:1、元数据能够构建真正的流程执行，从而在流程中更具洞察力，并为验证阶段提供数据。这份报告介绍了在内部审计环境中使用过程挖掘技术的经验。对某大型跨国银行的采购过程进行了分析。与之前关于监控技术使用的研究和其他关于过程视图方法的研究一致。与内部审计师的评估相比，过程挖掘方法能发现更多的内部控制问题。实验确定了设计流程中所有涉及到的异常，这些异常发生的频率非常低。这些案件证明即使实施了ERP系统，控制监测也绝不是多余的。虽然流程挖掘在其他领域可能会得到更深入的研究，但本案例研究是在审计和流程挖掘之间架起桥梁的第一次尝试。将有关用户id和活动时间戳的数据合并到事件日志中，使得流程挖掘成为一种具有突破性可能的监视方法。在适当的条件下，过程挖掘方法使我们有机会重播作为流程一部分的所有案例，并全面而客观地分析它们，从而为我们提供极为可靠的保障。 来源：智能财会联盟 来源：智能财会联盟 ， 作者：Mieke Jans团队。 |
