在我的职业生涯中，我做过相当多的业务流程重组工作, 我发现最大的一个问题总是一样的:开环业务流程. 开环流程的出现主要是因为责任由多个人分担，而且往往是由多个部门分担. 以R开头的信息流&D与一个新设备的请求可以通过财务和采购，然后再到组织边界之外的供应商(在那里它将依次经过几个部门), 然后最终回到接收和, 幸运的是, R&发起流的D组.

在经营管理的每一步业务信息流, 通信有可能中断, 和 项目经理 需要降低这些风险. 如果内置于业务流程中的信息流没有明确地结构化以捕获并处理任何异常, 直到很久以后才会发现故障，或者可能根本不会发现故障. 而一些信息流故障仅仅导致相对不重要的项目没有被正确订购或交付, 其他故障可能会使组织损失大量资金或延迟关键任务活动.

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

说明信息流在组织中的重要性, 我首先要讲的是一家大型制药公司，该公司为数亿美元的设备缴税，而这些设备已经无法追踪，他们想要消除这些不必要的开支. 我们的项目揭示了许多基本的流程缺陷, 所有这些加起来，每年都要缴纳数千万美元的不必要的税款，而错误地多次订购同样的东西也要花费更多的钱.

责任区域之间的单向沟通

像所有大型组织一样，责任是分散的. 生产部需要X设备, 所以他们通知财务, 生成采购订单(PO). 订购将订单发送给供应商. 在未来一年内，X由接收方交付并接收. 接收制造和财务通知. 财务发出一个资产标签，接收将其贴到X上. X被放入生产线，一切正常.

除了，一切都不太好. 首先, 员工来来去去, 很容易订购X，而没有意识到9个月前同一职位的其他人订购了X. 财务部门不知道这个订单是重复的:他们认为你只是需要另一个X, 这样就会生成另一个PO，并下另一个订单. 除此之外，即使你没有不小心超额订购，你也会很快忘记你有什么.

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

在20多年的过程中，这将开始以一种不小的方式损害底线. 此外, 财务部门使用ERP系统的一部分和一组资产指示器, 而制造业则使用完全独立的ERP模块和不同的资产指示器集. 在年底, 没有人能使这两组数字一致, 审计员质疑为什么你们的资本设备有几千万甚至上亿美元的出入.

这些都是由一组开环业务流程引起的经典问题. 开环是指您没有沿着流程线建立明确的确认点. 在上面的例子中，有如此多的开环过程，失败是必然的.

创建双向信息流

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

第一步

制造部门需要X，所以他们要求财务开一个PO. 财务现在与制造部门确认, 提供X过去24个月的订单明细. 避免了意外的订单重复.

第二步

制造部门向财务部门提供了X部件的详细信息，这些部件在使用寿命期间将被更换. 财务部门为每个组件创建资产标签，并与制造部门确认. 两个ERP模块都使用每个组件匹配的资产标签填充, 允许跨资产生命周期进行跟踪.

第三步

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

第四步

每次换出组件时, 制造业影响金融, 然后为该组件生成一个新的资产标签，并由Manufacturing放置在新组件上, 然后在两个ERP模块中进行确认. 然后，财务部门开始从账簿中删除旧组件，而制造部门则通过良好实践指南(GMP)退役过程. 在退役结束时，制造部门通知财务部门，以便将资产从账簿中取出.

细节比这个简化的示例要复杂一些, 但重点很清楚:在这条路上的每个阶段, 有明确的检查和确认.

确保应急行动

在另一个项目中，我被要求帮助一家服务公司提高客户满意度. 他们的业务就是处理索赔, 他们担心自己无法赢得竞标. 此外, 在他们的中标中, 随后客户的不满意味着他们的账户损失率过高.

只花了几天时间就找到了问题的核心, 又是开环过程吗. 当一个潜在客户要求出价时, 客户经理将使用他们的内部系统向负责组装投标的人员发送客户需求大纲. 然后，投标创建者将创建投标并将其转发给客户端. 希望, 客户端最终会响应, 通常需要进行一些修改, 哪个出价创建者将构建到下一个版本. 在某一时刻, 客户将接受投标, 会计部将创建一个新的客户帐户, 开具发票, 入职小组做了简报.

第一个问题是，没有从投标发起人到客户经理的明确确认, 因此，有时投标没有按时创建和发送, 没有人知道这件事. 这是可能的，因为内部系统没有字段来显示投标的截止日期, 作为竞标发起人，他总是超负荷工作, 这导致投标提交得太晚. 由于企业信息流通不畅，这些情况从未出现过.

在那之后，对投标的修改没有传达给客户经理. 这一点很重要，因为当客户最终在虚线上签字时，是客户经理向入职团队介绍情况的. 简报通常是基于客户经理的初步理解，而不是客户实际接受的报价.

一旦交战开始, 客户文档将到达并转发给当周指定处理池中的任何团队成员来处理它们. 因为没有明确的收货确认, 文件有可能在无人察觉的情况下丢失, 直到客户开始问为什么他们没有收到处理工作的结果.

当处理过的文档被发送回客户端, 收货时没有确认, 所以所有丢失的文件都消失了，直到某处有人开始抱怨他们的失踪.

确认关键事件

在招标过程的每一步，我们都有明确的确认. 我们为系统缺陷创建了变通方法，以便捕获所有关键信息, 包括投标修改所需的日期和随后的修改日期. 我们对公司内部业务中的所有信息流实施了明确的检查和确认, 以及公司和客户之间的关系.

例如, 当客户发送文件包时, 他们现在会给客户客户经理发一封电子邮件，让他们知道. 客户客户经理会将此转发给索赔处理中的责任方. 如果在三天内没有收到文件，就会发出警报. 收到文件后，客户收到确认邮件. 当公司将处理过的文件发送回客户时，情况也正好相反.

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

设计异常处理过程

了解如何以一种相当轻量级但有效的方式构造异常处理过程, 我们来看看我在职业生涯中遇到的另一个现实世界的例子，当时我是一家科研机构的首席信息官，专注于调查衰老的原因和与年龄相关的疾病的触发因素.

所有 的结果 研究机构包含许多独立的实验室, 每个项目都由一名首席研究员(PI)管理，并由不同的下属科学家和博士后组成. 在某一时刻, PI需要一个新的多室试剂托盘, 所以他们让一个博士后创建必要的请求. 博士后创建请求，并通过电子邮件将其发送给财务，要求筹集PO, 抄送PI以确保PI知道请求已发送. 与此同时, PI有一个自动日历通知设置，提醒他们检查请求状态，如果他们没有收到确认在某个日期. 这确保了一个故障安全机制，以防博士后忘记创建或发送必要的请求.

现在博士后同样有一个自动日历通知，如果他们没有在设定的时间内收到订单的确认，他们可以与财务联系. 当财务部门筹集到PO时, 博士后收到电子邮件确认已发送给供应商, 博士后将此确认转发给PI.

在这个阶段, PI或博士后设置另一个自动日历通知，以确保在设定的时间内没有收到供应商的任何回复, 有人与供应商进行核对，以确保收到订单并发运所订购的设备.

假设供应商确认收到了订单，并发送了发货通知, 这是发给PI或博士后的. 然后，他们在预定的收货日期后的三天内设置一个最后的日历通知，以确保如果物品没有出现, 他们知道要联系供应商来追踪发生了什么，并让货物正确交付. 如果货物如期到达, 博士后通知财务, 如果组织使用资产标签, 然后可以启动这组流程.

在路上的每一步, 需要明确的确认，并有一个子过程可用，以确保在主过程流中断时发生补救行动. 没有什么是悬空的，未经证实的，或没有支持的. 不需要特别的行动，因为每个人都知道需要什么，以及如果出现问题该怎么做.

学习从SQL创建闭环过程

一个好的流程的本质与基于sql的关系流程所使用的方式非常相似 数据库 是为了确保事务一致性而设计的吗. 任何行动必须经过确认，才能被认为已完成. 作为流程的一部分，所有双向通信都需要明确的确认, 并制定了下属流程，以确保未收到确认, 采取了正确的行动. 成功的项目经理 应该知道如何通过创建闭环流程来改善公司的信息流, 这样做将为组织节省大量的时间和金钱.