开环流程如何影响业务信息流

在我的职业生涯中,我进行了大量的业务流程再造,而我一直遇到的最大问题就是开环业务流程。 开环程序的出现主要是因为责任分布在几个人之间,在许多情况下,还分布在部门之间。 从研发开始的新设备请求的信息流会通过财务和采购部门,然后越过组织边界到达供应商(将依次通过几个部门)并最终返回到接收部门。

每个阶段都有可能出现中断沟通的问题,项目经理必须限制这些风险。 如果集成到业务流程中的信息流出现错误并无法提前分辨,那么直到很久以后才会发现故障。 虽然某些信息流故障会导致少量的产品无法被购买或正确交付,但其他信息流故障可能会使企业损失大量资金或导致关键任务被延迟推行。

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

为了证明我的论点,请考虑一家大型制药公司,该公司正在为价值数亿美元的设备纳税,并且无法追踪此款项及如何消除这种不必要的支出。 我们的调查发现了几个基本的流程错误,每年总计数千万美元的不必要的税款,还有因错误地多次订购相同的商品而浪费了数千万美元。

职责之间的单向沟通

与所有大公司一样,职责被部门划分。 当制造部门的某个人需要设备 X 时,他们会通知财务部门,并生成采购订单 (PO)。 订购部门将采购订单传送给卖方。 X 在未来一年内会被提供而且由接收部门接受。 制造和财务部门通过接收部门得到通知。 财务部门将资产标签分配给 X,接收部门应用该资产标签。 一旦 X 被正式组装,那一切看似是顺利的。

但这未必是好的。 对于初学者来说,员工有留有走,如果没有意识到九个月前具有相同能力的人已要求 X,那订购 X 是很简单的。 财务部门不知道此订单是重复的:他们认为您只需要一个额外的 X,因此准备了另一个采购订单并下达了订单。 除此之外,即使您没有故意过度订购,您也会很快忘记您所拥有的东西。

假设 X 是一台复杂的机器,例如灌装线。 它由 20 个关键部件组成,在其使用寿命期间,所有部件都将多次更换。 磨损会导致匆忙贴在 X 的一部分上的资产标签消失。 更糟糕的是,由于它没有及时被接收部门接受,资产标签甚至可能不会被应用。 在那之后,没有人知道如何保持对 X 的跟进,因此没有人知道如何在其生命结束时将其替代。 从其他的角度来看,X 仍然是一个有功能性的项目。

在 20 多年的时间里,这已造成相当大的影响。 此外,财务部门使用其 ERP 系统的一个部分和一组资产代号,而制造部门则使用完全不同的 ERP 模块和一组不同的资产代号。 到了年底,没有人能调和这两组数据,审计人员无法知道您为什么有几千万或几亿美元的资本设备差异。

这些是由一组开环业务程序引起的典型问题。 当您无法为生产线提供明确指示时,您就有了一个开环。 在前面的示例中显示太多的开环操作,几乎可以确定失败。

建立双向信息流

以下是我们解决问题的方法。 从开始到结束,我们对每一个重要的流程都进行探讨。 我们找到了所有的开环。 回到起点,我们设计了简单的方法来关闭这些循环。

第一步

制造部门需要 X 并请求财务部门发起采购订单。 财务部门现在与制造部门确认,并提供 X 二十四个月以前的订单数据。这样可以避免重复订单。

第二步

制造部门向财务部门提供了 X 组件的明细,而这些组件将在整个工作寿命期间被更换。 财务部门为每个组件生成资产标签并与制造部门核对。 两个 ERP 模块都应预先填充每个组件的相应资产标识符,这样就能够在整个资产生命周期内进行跟进。

第三步

接收部门通知财务部门,然后财务部门告知制造部门。 制造部门的负责人放置资产标签以验证每个标签都放在相关组件上。 然后为两个 ERP 模块重新确认所有标签/组件。

第四步

当一个组件被更换时,制造部门会通知财务部门,该组件的新资产标签由制造部门生产并放在替换组件上,然后在两个 ERP 模块中进行验证。 财务部门随后开始从账簿中删除旧组件的记录,而制造部门则实践良好实践指南 (GMP) 退役程序。 退役完成后,制造部门会通知财务部门,以便可以停用该资产。

具体细节比这个简化的例子要复杂一些,但我们可以清楚知道:每个步骤都有明确的检查和确认。

采取预防措施

在另一项任务中,我被要求协助服务提供商提高他们的客户满意度。 他们的公司专门从事索赔处理,他们担心失去投标。 此外,在达标中,客户的不满意味着他们的账户丢失率过高。

只需几天时间就可以查明问题的根源,那就是开环流程。 当潜在客户要求出价时,客户经理将利用他们的内部系统将客户需求传送给负责提出提案的人。 之后,投标人将生成投标并将其发送给客户。希望客户最终会做出反应,通常会一并要求投标人在下一个版本中包含的更改。 在某个时候,客户会接受报价,会计会建立一个新的客户帐户,开具发票,并通知负责团队。

第一个问题是投标人没有向客户经理明确确认,这意味着投标有时没有按时进行和传送,而且无人知晓。 这是可能会发生的情况,因为内部系统没有显示投标截止日期的区域,并且由于投标创建者被不断压迫,投标可能发送得太晚了。 由于企业信息流不足,这些情况无法避免。

再来,提案的更改未传达给客户经理。 当客户最终在虚线上签名时,客户经理向负责团队介绍了情况。 简报通常基于客户经理的原始解释,而不是客户接受的建议。

客户文件将在合作开始后送达,并发送给该周处理它们的任何团队成员。 由于没有具体的收据证明,文件可能会在无人知晓的情况下丢失,甚至在客户开始询问为什么他们没有得到处理工作的结果之前文件就被丢失了。

当处理过的文件被退回给客户时,由于没有收据证明,任何丢失的文件仍然无法被查看,直到有人开始抱怨无法查阅。

确认重要日期

我们在投标过程的每个阶段都包含了明确的确认信息。 我们为系统缺陷设计了解决方法,以收集所有关键信息,包括截止日期和随后的投标调整。 我们为组织内部以及公司与客户之间的每个业务信息流开发了明确的检查和确认。

例如,如果客户发送了一个文档包,他们现在会通过电子邮件通知客户经理。 这将由客户账户经理发送给索赔处理中的相关方。 如果在三天内没有收到文件,警报将被发出。 当文件到达时,会向客户发送一封电子邮件以确认收到。 当公司将处理过的文件退还给客户时,也应当采用一样程序。

由于大多数客户使用美国邮件来回发送纸质文件,因此每个阶段都设有明确检查的闭环程序可确保立即识别任何丢失的文件并采取措施纠正问题。

异常情况的处理程序

我们将看看另一个真实世界的例子,作为一家科学研究机构的 CIO,我专注于衰老的原因和与年龄相关的疾病触发因素,以展示异常处理方法如何以一个相对轻量级但有效的方式被构建。

所有 NIH 资助的研究机构都包括几个不同的实验室,每个实验室都由一名首席研究员 (PI) 领导,并由各种下属科学家和博士研究员组成。 当首席研究员需要新的多室试剂托盘时,他们会要求其中一位博士提出适当的要求。 博士提出请求并将其发送给财务部门以寻求采购订单,同时把首席研究员包括在邮件里以确保首席研究员收到最新资讯。同时,首席研究员设置了一个自动日历通知,如果他们在特定日期之前没有得到确认,则提醒他们检查请求的进度。这是为避免博士忘记生成或提交所需请求的情况下提供一种保护方法。

如果博士在一定时间内没有得到采购订单的确认,他们将收到自动日历通知,以便与财务部门查询。 当财务部门发出采购订单时,博士会收到电子邮件确认已将其转发给供应商,然后博士将其发送给首席研究员。

此外,首席研究员或博士可设置另一个自动日历提醒,以保证如果在一定时间内没有人收到供应商的回复,有人会负责联系供应商以确认收到采购订单并发货设备。

假设供应商确认收到采购订单并发送物件,此通知将被将发送至首席研究员或博士。 然后,他们在预计收货日期后三天设置最终日历通知,以保证如果物品没有到达,他们会联系供应商以追踪进度并正确交付物品。 如果项目准时到达,博士会提醒财务部门,如果业务使用资产标签,项目则可以开始被启动。

在此过程中的每一步,都需要明确的确认,并且随时访问详细流程以确保在主流程中断时采取纠正措施。 任何步骤不应该未经验证、不受支持或悬而未决。 没有必要进行多余任务,因为每个人都了解预期的内容以及如果出现问题该怎么办。

使用 SQL 创建闭环流程

一个好的过程基本上可以与基于 SQL 的关系数据库的方式相媲美。 任何步骤都必须经过验证才能被视为完成。 所有双向交互都需要作为流程的一部分,以及如果未收到确认,那应该如何执行适当的操作。 成功的项目经理应该开发闭环方法来增加信息流并节省企业时间和金钱。

加入世界顶尖前 1% 的自由领人才网络

领类将顶尖前1%的自由领程序员和设计师与世界各地领先品牌以及初创企业联系起来。我们专注于需要高技术人才和问题解决者的复杂且具有挑战性的一级项目。
经验丰富的项目经理正在审查从领类上聘请的自由软件工程师在软件开发项目上的进展 blog.join_marketplace.your_way经验丰富的自由 UI/UX 分析师在舒适的家中远程工作,并领类上完成 UI/UX 和产品设计项目 blog.join_marketplace.freelance_jobs