How Open-Loop Processes Disrupt Information Flow in Business

I’ve done a fair amount of business process re-engineering over the course of my career, and the single biggest problem I find is always the same: open-loop business processes. Open-loop processes occur mostly because responsibility is divided across multiple people and often across multiple departments. A flow of information that begins in R&D with a request for a new piece of equipment can travel through Finance and Purchasing before going outside the organizational boundary to the Vendor (where it will pass through several departments in turn), and then eventually back to Receiving and, with luck, the R&D group that initiated the flow.

At each step of business information flow in operation management, there is a possibility that communication will be disrupted, and project managers need to mitigate these risks. If the information flows built into a business process are not explicitly structured to catch and then handle any exceptions, failure won’t be detected until much later or perhaps not at all. While some information flow failures merely result in relatively unimportant items not being ordered or delivered correctly, other failures can cost organizations vast sums of money or impose delays on mission-critical activities.

Open-Loops Can Cost Millions of Dollars

To illustrate the importance of information flow in an organization, I’m first going to talk about a large pharma organization that was paying taxes on hundreds of millions of dollars of equipment it no longer could trace and wanted to remove this unnecessary expense. Our project uncovered many fundamental process flaws, all of which added up to tens of millions of dollars of unnecessary taxes per year and as much more being spent on ordering the same things multiple times by mistake.

One-Way Communication Between Areas of Responsibility

Like all large organizations, responsibilities were in silos. Someone in Manufacturing needs equipment X, so they inform Finance, and a purchasing order (PO) is generated. Ordering sends the PO to the vendor. Up to a year in the future, X is delivered and accepted by Receiving. Receiving notifies Manufacturing and Finance. Finance issues an asset tag, which Receiving slaps onto X. X is placed into the production line and all is well.

Except, all is not well. For a start, employees come and go, and it is easy to order X without realizing that someone else in the same role ordered X nine months ago. Finance has no idea this order is a duplicate: They assume you simply need another X, and so another PO is generated and another order is placed. Apart from that, even if you don’t accidentally over-order, you quickly lose track of what you have.

Let’s assume X is a complex piece of equipment, perhaps a fill-finish line. It consists of 20 major components, all of which will be replaced multiple times during its duty life. An asset tag slapped haphazardly onto one part of X will disappear due to wear and tear. Worse still, the asset tag may not even be applied because it doesn’t reach Receiving in time. After that, no one has any idea how to keep track of X, and therefore no idea how to decommission it at end-of-life. From a tax perspective, X is still a functioning taxable item.

Over the course of 20+ years, this would begin to hurt the bottom line in a not insignificant way. Moreover, Finance is using one part of their ERP system with one set of asset designators, while Manufacturing is using a totally separate ERP module with a different set of asset designators. At the end of the year, no one can reconcile the two sets of numbers, and the auditors are questioning why you have tens or hundreds of millions of dollars in discrepancy regarding your capital equipment.

These are classic problems arising from a set of open-loop business processes. Open-loop is when you don’t build in explicit confirmation points along the process flow line. In the example above, there were so many open-loop processes that failure was guaranteed.

Creating Two-Way Information Flows

Here’s how we tackled the problem. We modeled every significant process flow from beginning to end. We identified all the open loops. Then we engineered simple ways to close those loops, one at a time, starting from the very beginning.

Step One

Manufacturing needs X so they ask Finance to open a PO. Finance now checks with Manufacturing to confirm, providing details of previous orders for X going back 24 months. Accidental duplication of orders is avoided.

Step Two

Manufacturing provides Finance with a breakdown of X’s components that will be replaced during duty life. Finance creates asset tags for each component and confirms with Manufacturing. Both ERP modules are populated with matching asset tags per component, permitting tracking across the asset lifecycle.

Step Three

Receiving notifies Finance, which notifies Manufacturing. Placing of asset tags is done by a responsible party from Manufacturing to ensure each tag is placed on its correct component. All tags/components are then reconfirmed for the two ERP modules.

Step Four

Every time a component is swapped out, Manufacturing informs Finance, and a new asset tag for that component is generated and placed on the new component by Manufacturing, and then confirmed across both ERP modules. Finance then begins the process of removing the old component from the books while Manufacturing goes through the Good Practice Guide (GMP) decommissioning process. At the end of decommissioning, Manufacturing informs Finance so the asset can be taken off the books.

The details are a bit more complex than this simplified example, but the point is clear: At every stage along the road, there are explicit checks and confirmations.

Ensuring Contingency Actions

In another project, I was asked to help a services company improve its customer satisfaction rates. Their business was all about claims processing, and they were concerned that they were failing to win bids. Moreover, in their winning bids, subsequent dissatisfaction from clients meant their lost account ratio was too high.

It took only a few days to identify the heart of the problem, which was once again open-loop processes. When a prospect asked for a bid, the account manager would use their internal system to send a client requirement outline to the person responsible for assembling the bid. The bid creator would then create the bid and forward it to the client. Hopefully, the client would eventually respond, usually with desired modifications, which the bid creator would build into the next version. At some point, the client would accept the bid, and a new client account would be created by Accounting, an invoice raised, and the onboarding team briefed.

The first problem was that there was no explicit confirmation from the bid creator to the account manager, so sometimes bids weren’t created and sent on time, and no one knew about it. This was possible because the internal system had no field to show a due date for a bid, and as the bid creator was perpetually overworked, this led to bids being submitted too late. Due to poor information flow in the business, these situations never surfaced.

Following that, modifications to the bid weren’t transmitted to the account manager. This mattered because it was the account manager who briefed the onboarding team when a client finally signed on the dotted line. Often the brief was based on the account manager’s initial understanding rather than on the bid the client had actually accepted.

Once the engagement had begun, client documents would arrive and be forwarded to whichever team member in the processing pool had been assigned that week to handle them. As there was no explicit confirmation of receipt, it was possible for documents to go missing without anyone being aware of the fact, until the client began to ask why they weren’t receiving the results of the processing work.

When processed documents were sent back to the client, there was no confirmation upon receipt, so any missing documents were lost to view until someone somewhere began to complain about their absence.

Confirm Key Events

At each step of the bidding process, we built in explicit confirmations. We created workarounds for system shortcomings so that all critical information was captured, including date required by and subsequent bid modifications. We implemented explicit checks and confirmations for all information flow in business within the company, and between the company and the client.

For example, when a client sent out a document package, they would now send an email to the client account manager letting them know. The client account manager would forward this to the responsible party in claims processing. If the documents weren’t received within three days, an alert would be raised. When the documents were received, an email went to the client confirming receipt. The reverse was also true when the company sent processed documents back to the client.

As most clients used US mail to shuffle hardcopy documents back and forth, closed-loop processes using explicit checks at each step meant that any lost documents could quickly be identified and steps taken to rectify the situation.

Design Exception Handling Procedures

To see how exception handling procedures can be constructed in a reasonably lightweight yet effective way, we’re going to look at another real-world example I encountered in my career when I was the CIO of a scientific research organization focusing on investigating the causes of aging and the triggers of age-related diseases.

All NIH-funded research institutes contain many individual labs, each one run by a Principal Investigator (PI) and staffed by various subordinate scientists and post-docs. At some point, the PI needs a new multichamber reagent tray, so they ask one of the post-docs to create the necessary request. The post-doc creates the request and emails it to Finance to ask for a PO to be raised, cc’ing the PI to ensure the PI is aware that the request has been sent. Meanwhile, the PI has an automatic calendar notification set to remind them to check on the request status if they haven’t received confirmation by a certain date. This ensures a failsafe mechanism in case the post-doc forgets to create or send the necessary request.

Now the post-doc likewise has an automatic calendar notification to check in with Finance if they don’t receive confirmation of the PO being raised within a set period of time. When Finance does raise the PO, the post-doc receives email confirmation that it’s been sent to the vendor, and the post-doc forwards this confirmation to the PI.

At this stage, either the PI or the post-doc sets another automatic calendar notification to ensure that if nothing is heard back from the vendor within a set period of time, someone checks with the vendor to ensure receipt of the PO and dispatch of the equipment that’s been ordered.

Assuming the vendor acknowledges receipt of the PO and dispatches the item along with a dispatch notification, this is routed to the PI or the post-doc. They then set a final calendar notification for three days after the scheduled date of receipt in order to ensure that if the item doesn’t turn up, they know to reach out to the vendor to track what happened and get the item delivered correctly. If the item does arrive as planned, the post-doc notifies Finance, and if the organization employs asset tags, then this set of processes can be initiated.

At every step of the way, there is an explicit confirmation required and a sub-process available to ensure remedial action occurs if the main process flow is interrupted. Nothing is left dangling, unconfirmed, or unsupported. No ad-hoc actions are required because everyone knows what is required and what to do if things go wrong.

Learning To Create Closed-Loop Processes from SQL

The essence of a good process is very similar to the manner in which SQL-based relational databases were designed to ensure transactional consistency. Any action must be confirmed in order for it to be assumed as completed. All two-way communications need explicit confirmation built in as part of the process, and subordinate processes developed to ensure that if confirmation is not received, the correct action is taken. Successful project managers should know how to improve information flow in a company by creating closed-loop processes, doing so will save organizations vast amounts of time and money.