开环流程如何破坏业务中的信息流

在我的职业生涯中，我进行了大量的业务流程重新设计，而我发现的最大问题始终是相同的：开环业务流程。 开环流程的出现主要是因为责任分散在多个人之间，并且通常跨越多个部门。 从研发开始请求新设备的信息流可以通过财务和采购，然后超出组织边界到达供应商（它将依次通过几个部门），然后最终返回接收和采购。 ，幸运的是，发起流程的研发组。

在每个步骤中，都有可能导致沟通中断，项目经理需要降低这些风险。 如果构建到业务流程中的信息流没有明确地构造为捕获然后处理任何异常，那么直到很久以后才会检测到故障，或者可能根本不会检测到故障。 虽然某些信息流故障只会导致相对不重要的项目无法正确订购或交付，但其他故障可能会使组织损失大量资金或延迟关键任务活​​动。

开环可能会花费数百万美元

为了说明这一点，我首先要谈谈一家大型制药组织，该组织正在为数亿美元的设备纳税，它不再可以追踪，并希望消除这种不必要的开支。 我们的项目发现了许多基本的流程缺陷，所有这些缺陷每年都增加了数千万美元的不必要的税收，并且更多地用于错误地多次订购相同的东西。

责任区域之间的单向沟通

像所有大型组织一样，职责是孤立的。 制造部门的某个人需要设备 X，因此他们通知财务部，并生成采购订单 (PO)。 订购将采购订单发送给供应商。 最多在未来一年，X 由 Receiving 交付和接受。 接收通知制造和财务。 财务发出资产标签，收货人将其贴在 X 上。X 被放入生产线，一切正常。

除了，一切都不好。 首先，员工来来去去，很容易订购 X，而不会意识到九个月前同一角色的其他人订购了 X。 财务部不知道这个订单是重复的：他们假设您只需要另一个 X，因此会生成另一个 PO 并下达另一个订单。 除此之外，即使您没有意外地过度订购，您也会很快忘记您拥有的东西。

让我们假设 X 是一个复杂的设备，也许是一条填充线。 它由 20 个主要部件组成，在其使用寿命期间将多次更换。 随意贴在 X 的一部分上的资产标签会因磨损而消失。 更糟糕的是，资产标签甚至可能不会被应用，因为它没有及时到达接收。 在那之后，没有人知道如何跟踪 X，因此也不知道如何在生命周期结束时将其退役。 从税收的角度来看，X 仍然是一个有效的应税项目。

在 20 多年的过程中，这将开始以一种不小的方式损害底线。 此外，财务部门正在使用其 ERP 系统的一部分和一组资产标识符，而制造部门则使用完全独立的 ERP 模块和一组不同的资产标识符。 到年底，没有人能调和这两组数字，审计人员质疑为什么你的资本设备有数千万或数亿美元的差异。

这些都是由一组开环业务流程引起的经典问题。 开环是指您没有在工艺流程线上建立明确的确认点。 在上面的例子中，有太多的开环过程，保证失败。

创建双向信息流

以下是我们解决问题的方法。 我们从头到尾对每个重要的流程进行了建模。 我们确定了所有的开环。 然后我们设计了简单的方法来关闭这些循环，一次一个，从一开始就开始。

第一步

制造业需要 X，所以他们要求财务部门开一个采购订单。 财务部门现在与制造部门核对以确认，提供 X 的先前订单的详细信息可追溯到 24 个月。 避免意外重复订单。

第二步

制造向财务部门提供了 X 组件的明细，这些组件将在工作寿命期间被更换。 Finance 为每个组件创建资产标签并通过 Manufacturing 进行确认。 两个 ERP 模块都为每个组件填充了匹配的资产标签，允许在整个资产生命周期中进行跟踪。

第三步

接收通知财务，财务通知制造。 资产标签的放置由制造部门的负责方完成，以确保每个标签都放置在其正确的组件上。 然后为两个 ERP 模块重新确认所有标签/组件。

第四步

每次更换一个组件时，制造部门都会通知财务部门，制造部门会生成该组件的新资产标签并将其放置在新组件上，然后在两个 ERP 模块中进行确认。 财务部门随后开始从账簿中删除旧组件的过程，而制造部门则通过良好实践指南 (GMP) 的退役过程。 在退役结束时，制造部门会通知财务部门，以便将资产从账簿中删除。

细节比这个简化的例子要复杂一些，但要点很清楚：在沿途的每个阶段，都有明确的检查和确认。

确保应急行动

在另一个项目中，我被要求帮助一家服务公司提高其客户满意度。 他们的业务全是索赔处理，他们担心自己未能中标。 此外，在他们的中标中，随后客户的不满意味着他们的失账率太高。

只用了几天时间就确定了问题的核心，这又是一个开环流程。 当潜在客户要求出价时，客户经理将使用他们的内部系统将客户需求大纲发送给负责组合出价的人员。 然后，投标创建者将创建投标并将其转发给客户。 希望客户最终会做出响应，通常会进行所需的修改，出价创建者会将其构建到下一个版本中。 在某个时候，客户会接受投标，会计将创建一个新的客户帐户，开具发票，并向入职团队介绍情况。

第一个问题是投标创建者没有向客户经理明确确认，因此有时投标没有按时创建和发送，而且没人知道。 这是可能的，因为内部系统没有显示投标截止日期的字段，并且由于投标创建者永远过度劳累，这导致投标提交得太晚。 由于业务中信息流通不畅，这些情况从未浮出水面。

之后，对出价的修改不会传送给客户经理。 这很重要，因为当客户最终在虚线上签字时，是客户经理向入职团队介绍了情况。 简报通常是基于客户经理的初步理解，而不是客户实际接受的出价。

一旦开始参与，客户文件就会到达并转发给处理池中当周被分配来处理它们的任何团队成员。 由于没有明确的收据确认，文件可能会在没有人知道的情况下丢失，直到客户开始询问他们为什么没有收到处理工作的结果。

当处理过的文件被发回给客户时，收到后没有确认，因此任何丢失的文件都丢失了，直到有人开始抱怨他们的缺席。

确认关键事件

在投标过程的每一步，我们都建立了明确的确认。 我们针对系统缺陷创建了解决方法，以便捕获所有关键信息，包括要求的日期和后续的投标修改。 我们对公司内部以及公司与客户之间的所有业务信息流实施了明确的检查和确认。

例如，当客户发送文件包时，他们现在会向客户客户经理发送电子邮件通知他们。 客户客户经理会将其转发给索赔处理中的责任方。 如果在三天内未收到文件，则会发出警报。 收到文件后，会向客户发送一封电子邮件，确认收到。 当公司将处理后的文件发回给客户时，情况也正好相反。

由于大多数客户使用美国邮件来回移动硬拷贝文件，因此在每个步骤使用明确检查的闭环流程意味着可以快速识别任何丢失的文件并采取措施纠正这种情况。

设计异常处理程序

为了了解如何以合理的轻量级但有效的方式构建异常处理程序，我们将看看我在职业生涯中遇到的另一个真实示例，当时我是一家专注于调查原因的科学研究组织的 CIO衰老和与年龄有关的疾病的诱因。

所有 NIH 资助的研究机构都包含许多单独的实验室，每个实验室都由一名首席研究员 (PI) 运营，并配备各种下属科学家和博士后。 在某些时候，PI 需要一个新的多室试剂托盘，因此他们要求其中一位博士后创建必要的请求。 博士后创建请求并将其通过电子邮件发送给财务部门，要求提出 PO，抄送 PI 以确保 PI 知道请求已发送。 同时，PI 设置了自动日历通知，以提醒他们在某个日期未收到确认时检查请求状态。 这确保了故障安全机制，以防博士后忘记创建或发送必要的请求。

现在，如果博士后在设定的时间段内没有收到关于提出 PO 的确认，他们同样有一个自动日历通知来与财务部签到。 当财务部确实提​​出 PO 时，博士后会收到确认已发送给供应商的电子邮件，然后博士后会将此确认转发给 PI。

在这个阶段，PI或博士后设置另一个自动日历通知，以确保如果在设定的时间内没有收到供应商的任何回复，有人会与供应商核对以确保收到PO并发送已订购的设备。

假设供应商确认收到采购订单并发送项目以及发送通知，这将被发送到 PI 或博士后。 然后，他们在预定收货日期后三天设置最终日历通知，以确保如果物品没有出现，他们知道要联系供应商以跟踪发生的事情并正确交付物品。 如果项目确实按计划到达，博士后通知财务，如果组织使用资产标签，则可以启动这组流程。

在此过程的每一步，都需要明确的确认，并且有一个子流程可用于确保在主流程中断时采取补救措施。 没有任何东西是悬空的、未经证实的或不受支持的。 不需要特别行动，因为每个人都知道需要什么以及如果出现问题该怎么办。

学习从 SQL 创建闭环流程

良好流程的本质与设计基于 SQL 的关系数据库以确保事务一致性的方式非常相似。 任何行动都必须经过确认才能被认为已完成。 所有双向通信都需要作为流程的一部分内置明确的确认，并开发下级流程以确保如果未收到确认，则采取正确的行动。 成功的项目经理应该创建闭环流程来改善业务中的信息流并为组织节省大量时间和金钱。