Process Behaviour Charts: More Than You Need To Know

Note: this is Part 5 in a series of blog posts about becoming data driven in business. You may want to read the prior parts before reading this essay.

The last time we looked at process behaviour charts was in How to Become Data Driven, which laid out the Statistical Process Control (SPC) practitioner’s approach to, well, become data driven. A quick recap of that essay is:

1. To become data driven, you need to understand variation.
2. There are many ways to understand variation. The approach that SPC practitioners recommend is to use process behaviour charts. The simplest process behaviour chart is known as the XmR chart.
3. Once you start using such charts, the SPC argument is that your organisation will come to understand variation, and will thus slowly adopt the style of thinking necessary to do continuous improvement.

I’ve spent more time digging into the underpinnings of process behaviour charts since publishing that piece. This post pulls what I’ve uncovered into one resource, which should hopefully make it easier for you to put these ideas to practice. Bear in mind that I’m only at the beginning of application in my own work; I don’t yet have practical advice for XmR chart usage. I expect to update this piece in a few months with notes from use. For now, treat this as a distillation and a map for further reading.

The Practical Questions

We’ll start with more practical ‘how to’ notes, and then move on to more theoretical ‘why the hell does this even work?’ questions.

Can you use this technique on any kind of ‘process’?

The word ‘process’ in ‘process behaviour charts’ is a little deceptive. It doesn’t mean ‘industrial process’ or even necessarily some kind of business workflow that you run in your company. In my early readings on process control, I was a little surprised to see XmR charts of shopping mall footfall and of monthly receipts of insurance premium payments. In Donald Wheeler’s Making Sense of Data there is a particularly striking chart of daily peak exhalation flow rate readings by an asthma patient. None of these measures are traditionally associated with industrial processes (or, hell, with processes that one may run inside a company). I was expecting more typical metrics like ‘in-process inventory’ or ‘on-time shipping’. So what gives?

In the original 1931 book where he invented the approach, American statistician Walter Shewhart used the word ‘phenomenon’ instead of ‘process’:

A phenomenon is said to be controlled when, through the use of past experience, we can predict at least within limits, how the phenomenon may be expected to vary in the future. Here it is understood that prediction within limits means that we can state, at least approximately, the probability that the observed phenomenon will fall within the given limits.

The word ‘phenomenon’ captures a little of what we’re looking for. The truth is that there are only three requirements for using a process behaviour chart:

1. All data points come from the ‘same system of causes’. You are assuming that this system displays some kind of predictable, steady-state, routine variation.
2. All data points are measured the same way and by the same method.
3. The data should be arranged in chronological order (which implies you need to know when each measurement was taken — you do want to plot a time series, after all).

Or, to quote Wheeler: “The XmR Chart is intended for use with sequences of values that are logically comparable.”

What does ‘same system of causes’ mean? Well, let’s say that we’re trying to identify exceptional variation in an asthma patient’s peak exhalation flow rates. Our patient takes two measurements a day: one in the morning, before medication (let’s call this measurement X), and one in the evening, after taking medication (let’s call this measurement Y). For the sake of expediency, the patient’s doctor plots both values on the same time series, so the graph reads: X1, Y1, X2, Y2, X3, Y3 and so on.

This is a perfectly good time series, but it is not suitable for turning into an XmR chart, as measures X and Y are not logically comparable. In fact, we may say that the two sets of readings come from two different systems of causes. The doctor must separate these two readings and plot an XmR chart for measure X and for measure Y separately.

The overall point I’m making is that ‘process’ is more like ‘some underlying system of causes’ than it is ‘rigid business workflow’. As an example, I have subjected website visits to the process behaviour chart approach — a perfectly reasonable use for a perfectly normal business ‘phenomenon’.

What are process behaviour charts used for?

In a sentence: they are used to separate signal from noise.

The main problem that you have when you’re looking at any metric is that you often don’t know if a change represents something significant. Sales is down 12% this month — is that something to worry about? Is it seasonal variation? Should you wait a bit longer before you investigate? Conversely, if your boss yells at you to investigate now, are you going to waste all the time you spend digging into it — because it turns out to be routine variation?

The truth is that all natural processes display some amount of variation. Process behaviour charts give you a superpower: you are now able to tell if the variation you’re looking at is routine or exceptional. This may be used in a variety of ways:

1. You may investigate with confidence when exceptional variation shows up (either good or bad). No more “am I going to waste my time investigating this?” and “uhh, is this bad?” Conversely, you may ignore routine variation with the same confidence.
2. You know when your process improvement activities are beginning to give you results — because it will show up as exceptional variation. This in turn means that you’re better able to discover controllable input metrics to your process.
3. Finally, you know what your next steps are if you want to improve any process. Some terminology: if a process displays only routine variation, it is predictable. If a process displays both routine and exceptional variation, it is unpredictable. Hence: if the process is unpredictable, you need to first investigate and then remove exceptional variation. If the process is predictable, then you need to completely rethink the process. (A predictable process is already running the best it can, and the only way to change process behaviour is to fundamentally change the underlying process.)