Describing highly variable processes with Work Unit Routing Analysis (WURA)

Skip to Content

Menu<br>Close

Continuous improvement

Describing highly variable processes with Work Unit Routing Analysis (WURA)

A method for documenting & understanding processes when people say there isn’t a process.

Brian Kerr

Tacoma, WA 98407

Website

LinkedIn

Bluesky

Mastodon

5 min read

Share

Email

Copy link

Photo by Brian Kerr.

On this page

Unlock full content

WURA WTF<br>An easy way to understand Work Unit Routing Analysis (WURA) is to start with its predecessor, Product-Quantity-Routing (PQR) analysis.<br>You’ll find PQR analysis used in settings where there are a lot of small-batch custom orders. Take a print shop, paint shop, or light manufacturer that has to set up and configure workspaces and equipment for a specific run of work, ship those off, and then re-set and re-configure things for the next, different, run. This is an environment where some things are always different, and other things are always the same. Knowing which materials—supplies, stable intermediate forms, scrap/junk, and final products (P)—are being produced and in what quantities (Q) as they’re routed (R) across the shop becomes the basis for various insights.<br>WURA was the extension of this analytical approach to clinical settings, and from there into other types of work—including the hopelessly computer-addled work I get involved in. To call the products of labor ‘work units’ (WU) upon which one could perform a similar routing analysis (RA) is a meandering walk but it eventually gets us to the WURA acronym.<br>My experience has been that some people have heard of PQR and others WURA. The happiest people have heard of neither.<br>When you might use WURA<br>WURA is a great fit for low-volume, moderate complexity, highly variable work. When I hear something like “we don’t have a process” or “every is different” I consider whether WURA might be an appropriate format to use.<br>I’ve personally used WURA:<br>To document various ways projects got approved inside a corporation while bypassing the official, mandatory approvals mechanism.<br>To discern how a real estate company prepares distressed properties for sale at auction across various geographies, property conditions, and the like.<br>To understand billing procedures for a professional services firm across its various lines of business and combinations of customers, industries, and project types.<br>How to run WURA<br>Note: click or tap an image to see it full-width.

Describe a single scenario<br>First, document a single scenario in a single row in a data table. In this example, there are six major process steps, numbered 1-6 and each given a short but descriptive name.<br>The easiest way to get this down is to follow a single ‘work unit’ around and see what people do. This initial scenario doesn’t have to be a typical or even common case; it’s merely the first one you’re writing down. Don’t worry about exceptions handling or alternate scenarios yet. These will get their own rows later.<br>Any methods you’ve used elsewhere for identifying and distinguishing process steps will work here. (For example: look for transitions, hand-offs, or notifications.)<br>A single scenario is documented. It has six process steps.Document additional scenarios<br>Next, document as many additional scenarios as you encounter, using the same format. Number process steps in sequence. Add new process steps as you see them. This list is totally unordered at this point. Keep adding exhaustively.<br>Exceptions, special cases, rush jobs, undisussables—each get their own row.<br>Seek to keep process steps at approximately the same level of detail. Split, combine, and rearrange in order to match what is actually happening.<br>Various scenarios are documented. The initial scenario is now about halfway down the list.Annotate with frequency & quality data<br>At some point you will exhaust scenarios people can show you or that you can observe. Someone might say that “every is different” but the finite length of this scenarios list indicates otherwise—at least when viewed from a this level of abstraction.<br>Once you’ve gotten here, annotate the list with a few data points for each scenario. What’s important to measure? Use your best judgement, tempered by availability of data. Two good starting points are those shown in our example:<br>Frequency : # of ‘work units’ produced via this scenario over a certain time (a month, a quarter, a year).<br>%C/A : percent complete & accurate; this is a percentage of work items that are both complete (nothing missing or broken) and accurate (correct) as they exit each scenario.<br>Not shown here, but much more powerful, is to also measure %C/A for each process step. In this case, you’d want to measure how often work items enter the given process step without quality issues.<br>This can also be a good moment for a conversation about accuracy and how it is or should be determined.<br>Frequency & quality data for scenarios (right columns); scenarios count for...