Fighting Performance Entropy

Introduction

You may be asking, what the heck is “Performance Entropy?” In this article, I will talk about “Performance Entropy”, why it matters, and how we can avoid it using Smart and Lean problem solving.

Let me paint a quick picture: There is a chronic problem on the shop floor and the continuous improvement team is brought in to help solve it. The team puts in a great effort and documents big improvements and savings for the business. Then the team moves on to another process that is having a problem. Before too long, the first broken process (the one that got “fixed”) is broken again and performance is back down to what it was like before the improvement event.

Does this problem sound familiar? I bet it does! Every business I’ve ever talked to has experienced this issue. Yet every problem-solving template has a step to address this problem: “Standardize” in many of them, “Control” in DMAIC, etc.

This is a big issue, too. It means that problems are not getting long-term fixes and persist on the shop floor. It also means that a lot of money is being wasted on continuous improvement projects.

What can be done to fix this?

Today we’re going to walk through why this happens and what can be done to prevent it in the future.

Why Does Entropy Happen?

Let’s get started with why performance entropy (or erosion, if you prefer) happens.

Not All Root Causes Identified

The first reason why those gains get washed away is that not all the root causes of the problem were identified in the first place.

As teams go through root cause analysis there are many reasons why certain root causes are not found. For example, when performing 5 Why analysis, teams will sometimes go deep but not broad. They will uncover one of the root causes of the problem and then jump straight into problem solving mode.

Another reason why this happens is because of insufficient data. In these cases, the team may do a very good job following the data to the problem causes. But if the data is incomplete or if it is biased, then the data may point the team to address the wrong set of causes to the problem. The issues with the data can happen in many ways, but they happen very frequently when the data for improvement projects is collected manually. It is hard to gather enough information for valid analysis. Timeframes for manual data collection tend to be short and experience limited exposure to all the causes for problematic performance.

Additionally, people behave differently when they are being watched. This leads to biased data collection that does not reflect how the process normally operates. When specific behaviors or habits are part of the issue, these could disappear when the operators know they are being monitored and reappear as soon as the team leaves.

Change Did Not Get “Locked In”

The next big reason why the performance erosion occurs is that the change was not truly “locked in” while the team was still present.

This could be due to several factors. The first is that the new standard work may not have been clearly defined or communicated. One outcome of every improvement project should be updates to the standard work for that process. If this new SOP is not properly documented, communicated, and made visible to everyone involved with the process, then there will certainly be issues as a result. After all, people cannot be expected to follow a procedure they have not been trained upon.

Next is a lack of involvement of the operators during the improvement process. When engineering or the CI team creates a change without involving the people that run the process, they may not get buy-in to the solution being implemented. This can cause people to fall back to the old way of doing things as soon as the improvement team moves on to another project. Even when the “primary” operator is part of the improvement team, there could be many other people running that process that were not involved in the problem-solving process. It is important to make sure that everyone who runs that process has some opportunity to make their voice heard so that they will take some level of ownership of the solution and gain an understanding of what is being done.

Finally, it may be that the desired new habits were not set properly. I’ll dive into this more deeply during the “fix” part of the presentation, but it is important that there is a motivation for the new behavior and a “trigger” that will remind people to perform the new actions.

Process Drift

The last cause of performance erosion that I’ll cover today is “process drift”. This is a recognition that it takes energy to maintain a certain level of performance in any process due to natural changes happening across time.

In every process, whether it is optimized or not, the current level of performance is challenged by changes to the products that are being manufactured, new workers hired by the organization, or cross-trained workers who are simply new to that process. This means it takes energy to keep the work instructions up to date, or to train people to do the work properly.

It should be an expectation for any process that time should be reserved to both maintain and train to avoid these issues.

How to Fight Performance Entropy: Psychology of Change

Now we come to the fun part!

I have established the challenge associated with maintaining the new levels of performance after an improvement project. Next, let’s talk about how to avoid those problems and sustain the gains.

Build Better Habits

For those unfamiliar with BJ Fogg’s research into behavioral change, I highly recommend reading the book “Tiny Habits”. It’s a quick read and talks about how to establish new habits and break old ones.

The fundamental concept of the model is that Behavior = Motivation + Trigger. So, if you want to instill a new behavioral habit, you must understand the motivation for the behavior and then tie the initiation of the action to some sort of trigger.

For the motivation for the new behavior you are trying to install on the shop floor, you must communicate to the workers how this will benefit them, the team, the company or some other motivating factor. This motivating factor could be an intrinsic reward of doing a better job or an extrinsic reward of hitting performance bonuses.

For the trigger, it depends on the behavior you are trying to create. The trigger should immediately precede the action that should be taken. The trigger could be at start of shift, or during a changeover, whenever there is downtime, or some other facet of normal events on the shop floor. It could also be prompted by technology when the time is right. An example of this could be a message that pops up for the operator when an autonomous maintenance task needs to be performed.

One more important factor in the behavioral change model - reinforce the new action with celebration!

Gaining Ownership

The next facet of change management that must be addressed is getting ownership of the change from the team on the floor.

The main point here is one of philosophy. Most people I’ve talked to will say that they want the operators to feel ownership of implementing the change in the process. They want them to buy in and follow the new process like the change was their idea in the first place. Fewer of them say that they keep the operators involved throughout the improvement process. Even fewer treat the operators as if they really do “own” the process.

If the operators aren’t treated as if they own the process, why would they take ownership of the change?

At the very least, make certain that the primary operator is involved in the change process. Get their participation throughout – defining the problem, performing root cause analysis, generating solutions, and standardizing the change. Be sure to allow participation from other shifts and across rotations.

I will also point out that designing the change around the humans in the process will help gain ownership. If Human-Centered Design in manufacturing is an unfamiliar topic, I have done a couple of joint presentations with my partner at Sandalwood Engineering and Ergonomics. They are experts at human-centered design on the shop floor and can help your company design processes that work for the operators. When the people on the shop floor can see that the effort is being put in to make the workplace a good one for them, it helps to gain that ownership of the updated process.

Communicate

Finally, I’ll close this section with the need to communicate. It is very hard to over-communicate, but it is terribly easy to under-communicate.

When the project is complete, everyone should understand their role and the way that the change is going to benefit them. If they do not get this communication, they will revert to running the process the way they are most comfortable.

I have seen many of these projects go sideways because people on the shop floor did not understand the motivations behind the change. For example, at one customer we implemented a change to track detailed information about the production process to eliminate various sources of variation that were causing quality problems. Because nobody had talked to the third shift operator about why the change was happening, the first thing they did each night was to turn off the data collection. They had assumed that management was trying to find reasons do dock their pay or write them up. Once it was explained to them what was being done and why, they were on board and participated fully in driving those quality improvements.

We just had to sit down and talk with him first!

How to Fight Performance Entropy: Better Problem Solving

Next, I will look at how to adapt the problem-solving process itself to make sure performance remains good once the team moves on to another project.

In my webinar on “Improving Problem Solving in Manufacturing” a couple of weeks ago, I went into many of these topics in detail. Today, my focus will be on why these particular steps are important for creating lasting change. I will also emphasize how to approach these steps to fight against performance entropy.

Define the Problem Correctly

I did not mention this earlier, but one of the reasons that the correct root causes of a problem do not get identified is that the problem is not defined correctly in the first place. There are many reasons why this happens. Often, it comes down to either a lack of data, or a lack of data-driven problem-solving.

An example of this would be when the data being collected shows that a machine is failing during first shift much more frequently than during other shifts. Then the team jumps to the conclusion that the first shift operator is doing something differently than the other shifts and focuses their root cause analysis on why that’s the case. In actuality, the project team has an engineer watching the machine during first shift and they are counting on the other shifts to self-report when the downtime occurs. The downtime is being driven by something else, but the flawed data collection is leading the team to the wrong conclusion.

This example highlights several issues that can be addressed through automated data collection and augmented intelligence systems.

The first is that comprehensive data is required to properly define the problem. When data is collected manually, the information can very often be incomplete. That could be due to a short time frame for the data collection not capturing the full picture of a random process. It could also be that information is collected differently across different shifts. There are a multitude of problems with correctly defining the problem when the data is incomplete.

The next big issue is that the data being collected is not fully contextualized. When it comes to framing the problem, context really is king. When instances of downtime are being collected by simple tick sheets on a piece of paper, it is impossible to track the context of each downtime event. This means that the problem is very unlikely to be framed correctly. There could be many different problems that get lumped in as one single problem. The root cause analysis is not likely to uncover all the reasons for failure in this case because the problem itself is not framed properly. This will leave lingering issues that erode performance once the project team moves on.

Finally, even if automated data collection is in place, the team still needs the data literacy to interpret the data correctly. The team can get help with properly framing the data in a couple of different ways. One way is to use an algorithm such as a classifier system that can augment the human analysis. Another would be to involve an expert in data analysis as part of the project team.

Better Root Cause Analysis

The issues we discussed for defining the problem also apply to improving root cause analysis.

With Root Cause Analysis, the additional item I will discuss in this section is the need for granular data. Whether the project team is using a lean approach such as a 5 Why analysis or Ishikawa diagram, data needs to be collected at a detailed enough level to ensure that the team is not simply guessing which of the factors they identify are truly significant contributors. This does not mean that they must run a full analysis of variance or design of experiments, but they should have data at a granular enough level to identify which instances of the problem being studied are driven by which particular cause. That’s really hard to do with tick sheets!

Capturing data at the process variable level plus output variable level allows for detailed correlations showing the impact of different factors. If the data has been collected historically, the DOE or ANOVA can be run on the historical information to identify the contributing factors.

Detailed data is also critical for using artificial intelligence or machine learning applications to assist with the analysis.

Create Superior Solutions

If the improvement team does a better job defining the problem and determining the root causes of the problem, they will almost certainly create better solutions. After all, they are much more likely to be addressing the real problem!

In addition to that, it is possible to use Industry 4.0 solutions to open new avenues that were not previously possible. One example of this is implementing a system of closed-loop process control that utilizes a machine learning algorithm to continually improve performance over time.

In addition, these solutions can be used to share information across projects – even across multiple sites within the company. When the problems are defined in a previous step, they can be tracked through a set of standardized attributes. Then, by identifying common traits to previous problems, solutions can be searched that have been used to solve previous problems of a similar nature. Not only does this help share knowledge across time and space, but it also helps to broaden the thinking of the project team to incorporate ideas they may not have thought of on their own.

Standardize and Control

Finally, we come to the real heart of the matter. The final step in most problem-solving processes is to standardize the solution or put in controls for the process. This is the step where we are directly attempting to prevent performance entropy.

Several times earlier in the presentation we talked about a lack of standard work adoption being a major reason for performance erosion. This is where that standard work or SOP needs to get documented and communicated. The importance of having that standard work not only documented clearly, but highly available to anyone performing the process cannot be emphasized enough. The state of the art for this is utilizing hands-free augmented reality displays that show the operator the new work instructions right within the context of the task that they are performing. But even if you do not go that far, be sure to provide those work instructions in a highly visible and easily accessed way. Also make certain that everyone involved in the process is fully trained on the new SOP.

Every effort should also be made to make the process error-proof. This could mean utilizing standard poka yoke techniques. It may also mean providing automation or prescriptive solutions where possible so that there is no choice involved – the process will always be run the same way every time.

Finally, when it isn’t possible to error-proof the solution, be sure to “leave the lights on.” What I mean by this is to leave the data collection systems running when the project team leaves. The machine settings can be tracked to ensure the standard work is being followed. Performance can be tracked to ensure it remains at the newly expected levels. Any deviations that occur can be immediately identified and diagnosed. Where training reinforcement is needed, that can be provided.

Conclusion

Some closing thoughts...

Performance entropy is a significant problem in manufacturing. There are many underlying causes why performance falls back to previous levels after improvement events conclude. Each of these issues can be addressed by paying close attention to the people in the process and through improving the problem-solving process with smart factory solutions. It is through combining these approaches that we can make sure the “lights are left on” after the project team leaves and the new levels of performance are maintained for the long haul.