What does stability in operations look like?

If the operating environment is not stable, making changes or attempting to improve the environment may result in making the environment more unstable. 
In this article I will focus on what does stability look like in operations.  I define operations as any environment where there is a series of transformation steps that are completed in some sequence to satisfy a customer need.  Therefore, it is not just for manufacturers, but can also apply to service organizations as well.

Any environment where there is a series of transformation steps that are completed in some sequence to satisfy a customer need.

What is a stable system?

First of all, I would like to define a stable system.  Dr. Edwards W. Deming defined a stable system as a system that does not have any special causes (or assignable causes) of variation present, and all the variation in the system is from common cause (or inherent) variation.  My assumption is that unless you are trained in Six Sigma or Statistical Process Control (SPC), you may not understand these terms.    Therefore, I will use an example that most people are familiar with to explain the difference between common cause and special cause variation. Before explaining the different types of variation, I must define variation.  Variation can be defined as the difference between the expected result verses the actual results that you get from performing a process.

An example

The example I will use to explain the different types of variation is the process of driving to work each day.  Let’s assume that you expect to arrive at work each day at 6:45am. Each day you document when you actually arrive at work and you see a range of times between 6:40am to 6:50am (such as 6:43, 6:46, 6:42, 6:48, 6:50, 6:40, 6:45, and 6:42). Let’s also assume that you leave your house about the same time every day, you follow the same route to work, and use the same mode of transportation.   The variation in times that you observe is cause by the common causes of variation that is “inherent” in the process.  Examples of common cause of variation in the process of going to work would be: weather conditions, amount of traffic, and number of stops made on the way.  Then one day, you arrive to work 20 minutes late, which was caused by a sporadic event that caused a significant delay that caused you to be late.  This sporadic event is defined as a special cause of variation that caused the process to deviate significantly from the expected result.  Examples of special causes would be: there was a traffic accident; you got a flat tire; or you got pulled over by the police. These types of events would be special causes, also known as assignable causes because a specific reason can be assigned to why the process deviated significantly from the expected result.

How to get your operations stable

Now that you have a basic understanding between common cause variation and special cause variation, let shift the focus back to Operations.  One objective of Operations is to have a stable and capable delivery system.  Having a stable Operating System means that the time to complete all the processes in the system (the value stream), however defined, from start to finish, is highly predictable.  In order to be highly predictable, the system must be free of special causes of variation.  Special causes in variation in operations can come in many different forms, some being easy to identify and some not so easy to identify.  Some of the typical easy to identify variables that I have classified as special causes would be: lack of supplies due to late deliveries from vendors or sub-contractors, unplanned process downtime, and quality issues.  These types of special causes can be easily addressed by the application of Lean and Six Sigma techniques to reduce or eliminate the causes. On the other hand, some of not so easy to identify issues that I have classified as special causes would be: processing easy items at the expense of the harder items, jamming rush jobs into the system without consideration of capacity, batching jobs together in order to be “efficient”, pulling jobs ahead to “save” or reduce setups, or bad multi-tasking.   Dealing with these issues is much more difficult to correct because it involves behavioral changes from the people within the organization.  From my experience, the behavior modification is one of the most difficult changes to make within an organization, and in addition, it is typically these behaviors that most contribute to instability in operations.

Insights in (in)stability

The best way to identify if special causes of variation exist in Operations is to gather some data about operational performance.  The easiest way to understand the degree of stability (or instability) is to measure the performance of all jobs from start to finish for a given value stream over a time period.  By plotting the data on a histogram and analyzing the data, the statistics can give an indication of stability, or instability.

Figure 1, is an example of an operating system that is unstable.  In this example, there is a range of more than 100 days to complete the same work through the same value stream.  Some jobs finished in 40 days, and other jobs, for the same item, took more than 140 days.

Figure 1

Figure 2, is an example of an operating system that is much more stable.  In this example, there was only a range of 6 days to complete the same work through the same value stream.  The average number of days to complete jobs in this value stream was 33 days, with most jobs completing between 29 and 36 days.

Figure 2

In Operations it is very important to first achieve stability (eliminate the special causes of variation) before attempting to focus on making the operations capable.