How Open-Loop Processes Affect Business Information Flow

Throughout my professional experience, I have conducted numerous business process re-engineering efforts and the greatest challenge I have consistently encountered is the presence of open-loop business processes. These are typically created as a result of duties or tasks being delegated or shared between various people or departments. For example, an information flow that originates in the research and development division concerning a request for new equipment may pass through the finance and purchasing departments before being sent to the vendor, which can involve additional departments before it is eventually returned to the receiving division and, hopefully, the R&D group that initiated the request.

At each stage of communication, there is a potential for disruption, and project managers must take measures to minimise these risks. Without proper configuration of the data flows integrated into the business process, any exceptions that occur may not be detected until much later, resulting in potentially significant losses and delays of key tasks. While smaller issues such as incorrect products being ordered or delivered may seem inconsequential, they can have serious financial implications for businesses.

Open loops may cost millions of dollars.


In order to illustrate the point I am making, consider a prominent pharmaceutical company that was incurring taxes on equipment with an aggregate cost of hundreds of millions of dollars, despite the fact that the organisation had lost track of the assets. Upon further investigation, we identified several fundamental process issues that were leading to tens of millions of dollars being needlessly paid in taxes annually, as well as tens of millions more being wasted in duplicate orders due to inadvertent errors.

One-Way Communication Among Responsibilities


At our organisation, responsibilities are divided into distinct areas in a manner typical of large corporations. When Manufacturing needs an item of equipment called X, they contact Finance, who generates a purchase order (PO). The PO is then sent to the supplier, and when X is delivered and accepted by Receiving, both Manufacturing and Finance are notified. Receiving will also attach an asset tag to X, as assigned by Finance. Finally, when X is placed in its proper location on the assembly line, the process is complete.

However, things are not looking good. People come and go and it is easy to place an order for X without taking into consideration that someone else from the same team had requested it nine months prior. Unfortunately, Finance is not aware that this is a duplicate order, thinking it is an additional request for X, therefore a Purchase Order is created and the order is placed. Furthermore, even when there is no intention of over-ordering, it becomes difficult to keep track of what is already in possession.

Assuming X is a sophisticated piece of machinery, such as a fill-finish line, it is comprised of 20 key components, each of which will need to be changed frequently due to wear and tear. In some cases, an asset tag may not be applied to X due to a delay in the arrival of the tag at Receiving. As a result, it is difficult to keep track of the machine and its components, meaning it is difficult to properly decommission X at the end of its service life. From a tax standpoint, X is still considered a functional taxable item.

Over the last two decades, this could have a substantial effect on the company’s financial performance. Additionally, the Finance department utilises one component of their Enterprise Resource Planning system together with one set of asset identifiers, while Manufacturing makes use of a separate ERP module and a distinct set of asset identifiers. As a result, when it comes time to close the books at the end of the year, it is impossible to reconcile the two sets of data, leaving the auditors to question the existence of tens or even hundreds of millions of dollars of discrepancies in capital equipment.

It is common for open-loop business procedures to lead to a number of issues. When explicit validation points are not included in the process, it is referred to as an open-loop. The previous example showcased the consequences of multiple open-loop operations, with the outcome being a high likelihood for failure.

Establishing Two-Way Information Flows

After a thorough analysis of the problem, we implemented a solution that encompassed every important step. Our strategy included mapping out the entire process and identifying all areas of improvement. Subsequently, we formulated a plan that addressed the open loops in a systematic fashion, beginning at the beginning and incrementally resolving the issues one by one.

STEP ONE

Manufacturing has requested that Finance initiate a purchase order for X. To ensure that order duplication is avoided, Finance has confirmed with Manufacturing and provided data on prior orders for X dating back a period of 24 months.

STEP TWO

Manufacturing provides Finance with an itemised list of components to be replaced throughout the asset’s life cycle. Finance creates asset tags for each component and verifies the information with Manufacturing. Both Enterprise Resource Planning (ERP) modules are populated with the associated asset IDs for each component, allowing for tracking and monitoring of the asset throughout its lifespan.

STEP THREE

Upon receipt of information, the Finance department is notified who in turn alert the Manufacturing department. A competent individual from Manufacturing then adheres asset tags to each component to ensure accuracy. Subsequently, all tags and components are double-checked to ensure that both ERP modules are correctly updated.

STEP FOUR

Upon the replacement of a component, Manufacturing will issue a new asset tag for the new component and ensure that it is verified across both ERP modules. Additionally, Manufacturing will follow the Good Practice Guide (GMP) decommissioning procedure. Upon completion of this procedure, Manufacturing will notify Finance to initiate the process of removing the old component from the books and deactivating the asset.

More detailed than this simplified illustration, the idea is quite straightforward: At every step of the process, there are explicit assessments and verifications that need to be carried out.

Taking Precautionary Measures


In my previous assignment, I was tasked with helping a service provider to boost customer satisfaction. This particular company specialises in claims processing and was concerned about losing bids due to customer dissatisfaction. Furthermore, even for the bids they were winning, their rate of lost accounts was alarmingly high.

After conducting a thorough investigation, it was determined that the source of the issue was open-loop processes. When a potential customer requested a bid, the account manager would send an overview of the customer’s needs to the individual responsible for drafting the proposal. Subsequently, the bid maker would create the bid and send it to the client. In the event that the customer provided feedback, the bid maker would make the necessary modifications for the next version. Ultimately, the customer would accept the offer, and the Accounting department would set up a new account for the customer, generate an invoice, and notify the onboarding team.

The lack of communication between the bid author and the account manager caused a series of problems, such as bids not being made and transmitted on time, and no one being aware of it. This issue was left unrecognised since the internal system had no area that displayed the due date of each bid and the bid creator was often overworked, leading to bids being sent out late. This was a direct result of the company’s lack of a proper information flow system.

Subsequently, alterations to the proposal were not relayed to the account manager. Consequently, when the customer eventually consented to the agreement, the account manager was responsible for relaying the details to the onboarding team. Unfortunately, the instruction to the onboarding team was typically based on the account manager’s original understanding of the proposal, rather than the version the customer had agreed to.

Once the engagement had been initiated, the client documents would be distributed to the team member responsible for managing the processing work that week. Unfortunately, due to the lack of confirmation upon receipt, it was possible for the documents to go unnoticed until the customer queried why they had not received the results of the processing task.

Upon completion of the processing of the necessary paperwork, no proof of receipt was provided to the customer. As a result, any documents that were not returned to the customer remained unseen until a complaint was filed in regards to their absence.

Confirm Important Dates


At each stage of the bidding process, we ensured clear and definitive confirmations were included. We created solutions to any system issues to collect all the essential information, including the due date and any changes to the bid. Moreover, we implemented strict controls and confirmations of all the business data flow within the company and between the company and the customer.

If a customer sends out a document bundle, they should notify the relevant Client Account Manager via email. The Client Account Manager will then pass on the notification to the appropriate party responsible for claims processing. An alert will be triggered if the documents have not been received within three days. Once the documents have been received, the customer will be sent an email to confirm the receipt. Similarly, when the firm returns the processed paperwork to the customer, an email will be sent out to confirm.

Due to the fact that the majority of customers favoured using the United States Postal Service to send physical documents to and from each other, closed-loop processes, which included specific checks at each stage, were employed to ensure that any documents that were missing could be identified quickly and steps could be taken to rectify the problem.

Procedures for Handling Errors

At my job as Chief Information Officer of a scientific research organisation focused on the causes of ageing and the triggers of age-related disorders, I will demonstrate how exception-handling methods can be incorporated into a relatively lightweight but effective way. Using a real-world example, I will illustrate how this can be done.

At NIH-funded research institutions, each laboratory is headed by a Principal Investigator (PI) and comprises a team of scientists and post-doctoral fellows. When the PI requires a multi-chamber reagent tray, they ask one of the post-docs to make the request. The post-doc then submits the request to Finance, with a copy to the PI, to obtain a Purchase Order (PO). To ensure the request is taken care of, the PI sets up an automated calendar notification to remind them to track the progress of the request, in case the post-doc fails to generate or submit it.

If the post-doctoral researcher does not receive confirmation that the Purchase Order (PO) has been raised within the specified timeframe, they will receive an automated reminder in their calendar to check in with the finance department. When the finance department issues the PO, the post-doctoral researcher will receive an email confirmation that the PO has been forwarded to the vendor. The post-doctoral researcher must then forward this confirmation to their Principal Investigator (PI).

At this juncture, the Principal Investigator or the Postdoctoral Researcher establishes an automated calendar reminder to ensure that if there is no response from the vendor within a specific timeframe, then someone will contact the vendor to verify the receipt of the Purchase Order and the dispatch of the required equipment.

Upon assuming that the vendor confirms receipt of the purchase order and dispatches the item, the post-doctoral researcher or principal investigator should set a final calendar reminder for three days after the expected date of delivery. This ensures that they will be alerted if the item fails to arrive, enabling them to contact the vendor to trace the cause of the delay and ensure that the item is delivered correctly. Upon the item arriving on time, the post-doctoral researcher should notify Finance, and if the business uses asset tags, the necessary steps can then be taken.

At every stage of the process, explicit affirmation is required, and a sub-process is available to ensure that any disruptions to the main process are addressed in a timely manner. All elements are thoroughly verified, supported, and addressed as necessary. By having a clear understanding of expectations and the necessary steps to take in the event of an issue, there is no requirement for any additional and potentially unnecessary activities.

Creating Processes Using SQL


A well-constructed procedure should be consistent with the fundamentals of SQL-based relational databases, which were designed to ensure transactional integrity. Before any action can be considered complete, it must be validated. Additionally, two-way interactions must be confirmed as part of the process, and subordinate procedures should be implemented so that if confirmation is not received, the necessary steps are taken. To maximise efficiency and minimise costs, project managers should create closed-loop systems to streamline information flow.

Join the Top 1% of Remote Developers and Designers

Works connects the top 1% of remote developers and designers with the leading brands and startups around the world. We focus on sophisticated, challenging tier-one projects which require highly skilled talent and problem solvers.
seasoned project manager reviewing remote software engineer's progress on software development project, hired from Works blog.join_marketplace.your_wayexperienced remote UI / UX designer working remotely at home while working on UI / UX & product design projects on Works blog.join_marketplace.freelance_jobs