Module 2 · Foundations

Process thinking

Every tool later in this course is a way of looking at a process. Before you compute a Cpk or draw a control chart you need to know where the process starts and ends, what actually moves through it, and whether what you are looking at is the process behaving the way it always does or something new. This module builds that vocabulary: SIPOC and process maps to draw the boundary, a value stream map to see time and inventory instead of just steps, the eight wastes to name what is not adding value, and the difference between common and special cause variation, in words, before Module 16 turns it into a chart.

Learning objectives

• Draw a SIPOC diagram for a process and use it to set the boundary of a project before mapping any detail.
• Build a simple current-state value stream map and compute lead time, takt time and process cycle efficiency from it.
• Name Ohno's seven wastes and Liker's eighth, and give a manufacturing example of each.
• Explain, in words and without a control chart, the difference between common cause and special cause variation.
• Use the red bead experiment to explain why ranking people on a stable system's output is a mistake.
• Predict, from the funnel experiment's four rules, which kinds of "correction" make a stable process worse.

Why this matters

On 16 May 1924, Walter Shewhart, working in the inspection engineering department at Western Electric, the group that became Bell Telephone Laboratories the following year, wrote a one-page memo to his manager. It contained the first control chart and the distinction this entire module is built on: some of the variation in a process is assignable to a specific, findable cause, and the rest is chance variation, the routine scatter of a system that has not changed.^[1] That is a hundred-year-old idea. It is also, according to a 2006 history of the memo and what followed it, an idea that spread slowly even inside Western Electric's own Hawthorne manufacturing plant, the company that had just invented it.^[1]

The tools in this course were never the bottleneck. A SIPOC diagram takes twenty minutes to draw. The arithmetic behind a value stream map is division. What is hard, and what separates a project that fixes the right thing from one that produces a good-looking report, is thinking about the process before reaching for a chart or a formula: what are its boundaries, where does time actually go, and is the variation you are looking at built into the system or a sign that something changed. This module has no control chart and no capability index. Modules 4 through 18 hand you the arithmetic; Define and the early part of Measure are about seeing clearly enough that the arithmetic has something real to work on.

SIPOC and process maps

Before you can improve a process you have to agree on what it is. A SIPOC diagram does that in one pass, in five columns: Suppliers, Inputs, Process, Outputs, Customers. The process column holds only four to eight high-level steps, deliberately coarse; a SIPOC is not a flowchart. Suppliers and inputs sit to the left of the process, outputs and customers to the right, and the boundary of the project is wherever you decide the first and last process steps are.

Two ways to fill it in. If the process already exists, start in the middle: list the main steps, then work outward to what each step consumes and produces. If you are scoping a new project and do not yet know the process well, start from the ends: who is the customer and what do they need, then work backward to the suppliers and inputs that make it possible, and let the process column fill in last. Either way, a SIPOC is a scoping tool. When you need step-by-step detail, a swim-lane process map is the next level down; when time and inventory matter as much as sequence, a value stream map (next section) is the level below that.

The example below is a constructed process, drawn for teaching. It is not a real production line.

Worked example 1: SIPOC for a brazed heat-exchanger line

This is the process the capstone project (Module 19) returns to: an aluminium heat-exchanger core, brazed in a furnace, that later fails its leak test at an inconvenient rate. Scoping that project starts here.

Notice what the SIPOC does not tell you: how long each step takes, how many cores sit waiting between steps, or which of the seven process steps is where the leak-test failures come from. That is not a flaw. A SIPOC's job is to fix the boundary (cut-to-length stock in, a packed core out to final assembly) and confirm everyone agrees what is inside the project and what is a supplier's or customer's problem. Everything downstream, including the capstone's root-cause work, builds on this boundary being right.

The eight wastes

Taiichi Ohno, developing the Toyota Production System, named seven categories of activity that consume resources without adding anything the customer would pay for.^[3] The Lean Enterprise Institute's standard list, with overproduction named as the worst of the seven because it hides and causes the other six, is reproduced in Table 2.^[2] Jeffrey Liker later added an eighth, the waste of unused employee skill and creativity, in The Toyota Way; that addition is Liker's, not Ohno's, and this course labels it as such.^[4]

The list is worth memorising, but naming a waste is only useful if it points at a specific fix: "inventory" tells you to look at batch sizes and changeover time, "motion" tells you to look at the layout of a workstation, "unused skill" tells you to look at whether the person doing the job gets asked. Lumping several of these together as "inefficiency" loses that pointer.

Value stream mapping

The term "value stream" comes from Womack and Jones's Lean Thinking: everything, value-adding and non-value-adding, that it takes to bring a specific product from raw material to a customer.^[5] A value stream map draws that on one page for one product family, including the flow of information (orders, schedules) alongside the flow of material; Rother and Shook's Learning to See is the method almost everyone uses to draw one.^[6][7] The difference from a plain process map is that a VSM attaches two numbers to every step: how long the step takes to do the work (cycle time), and how much sits waiting before it (work in process, WIP). Those two numbers convert into the quantity that a process map cannot show at all: how long a unit actually spends in the system.

Lead time, takt time, and process cycle efficiency

Three formulas, in the order you use them.

The data below is a constructed example, not a real production line.

Worked example 2: current-state map of a machining cell

A cell makes one bracket part number on one shift: turn, mill, deburr, inspect and pack. Demand is 400 pieces a day; the shift provides 27,000 seconds of operating time after breaks.

Takt time first, because it is the yardstick everything else is compared to: takt = 27,000 s / 400 pieces = 67.5 s per piece. Every step in Table 3 (45, 60, 30, 20 s) is comfortably under 67.5 s, so no single step is the pace-setting constraint; the delay is somewhere else.

Inventory time at each point, quantity divided by daily demand:

Sum of inventory time = 3.875 days. Sum of cycle time = 45 + 60 + 30 + 20 = 155 s, which converted to days (dividing by the 27,000 s available in a day) is 0.005741 days. Total lead time is the sum of both: 3.8807 days.

Every part passes every inspection in this constructed example; nothing here is a defect. And a part still spends, on average, about 676 seconds sitting for every one second actually being cut, milled, deburred or inspected. A capability study or a control chart, applied to any one of these four steps, would never reveal that number, because 99.85 % of the part's time in the building is spent in one of the five triangles in Figure 1, not on a machine. This is the case for value stream mapping before any statistical tool: some of the biggest improvements in a factory are in the triangles, not in the boxes.

Common cause and special cause, in words

Every process varies. The question that decides what to do about it is whether the variation is common cause or special cause, and you can answer that question, most of the time, without a control chart.

Common cause variation is built into the way the process currently works: the small differences between one part and the next that come from the machine, the material, the gauge, the method and the environment, all acting together, none of them dominant, none of them new. It is present in every unit, all the time, and no single person working inside the process can find "the cause" and remove it, because there isn't one cause; there are hundreds of small ones, and they are the system. Reducing common cause variation is a job for whoever can change the system: redesign the fixture, tighten the incoming material spec, retrain everyone, buy a better machine. Deming's language for this: an analytic problem, aimed at action on the process to change what happens in the future, as distinct from an enumerative one, which just counts or describes what is already there.^[8] A capability index or a control limit is always an analytic claim: it says something about parts you have not made yet.

Special cause variation means something changed: a tool broke, an operator substituted a different material, a setting drifted, a batch of gauge blocks was miscalibrated. It does not show up in every unit; it shows up in this shift, this operator, this lot, this hour. Because it is local and identifiable, the person closest to the process — the operator, the setup technician — is usually the right person to find it and fix it, and management does not need to redesign anything.

The two questions that tell them apart, before any chart: does this show up everywhere, all the time, for reasons built into how the process runs? Or did something specific change? Modules 16 and 17 build the control chart that answers this with arithmetic and a fixed false-alarm rate instead of a guess. The rest of this module is two demonstrations, one for each kind of mistake: mistaking common cause for a person's performance, and mistaking common cause for a special cause worth correcting.

Worked example 3: the red bead experiment

W. Edwards Deming used a bead-drawing exercise in his seminars from the early 1980s, a gift to him from Bill Boller of Hewlett-Packard, to make a single point: a "willing worker's" output is limited by the system they work in, not by how hard they try, and ranking or rewarding people on a stable system's output is a fallacy.^[9] A worker dips a paddle with a fixed number of holes into a box of beads, mostly white with some red, and the count of red ("defective") beads they draw is reported as the day's output.

The published descriptions of the exercise available to this course do not state the exact box size, colour split or paddle size Deming himself used in a given session; the numbers below are the course's own constructed version of a common form of the exercise (a paddle of 50 holes, a mix that is 20 % red), not a transcription of Deming's data.

With a fixed 20 % red mix and a paddle that always draws 50 beads, the count of red beads on any one draw follows a binomial distribution: 50 independent draws, each with a 0.20 chance of being red.

Now simulate five workers, four rounds each, one paddle draw per worker per round: twenty draws from that same distribution, nothing about the system changing between them.

Mean = 10.6 beads, median 11.0, s = 2.66, from 6 to 16 beads: close to the theoretical mean of 10.0 and SD of 2.83, and every value comfortably inside a ±3 SD band (about 1.5 to 18.5 beads). Nothing here is a signal. If a supervisor singled out Worker B's round 2 (16 red beads, the worst single result in the table) for a warning and Worker E's round 2 (6 red beads, the best) for a bonus, the supervisor would be wrong on both counts: every worker used the identical paddle on the identical mix, and a spread from 6 to 16 is exactly what a stable Binomial(50, 0.20) system produces by chance. The paddle, not the worker, decides the count. Improving it — a better mix, a different paddle, a visual inspection step — is management's job, because it is the system.

Calculator: descriptive statistics on the red bead results

Worked example 4: the funnel experiment and tampering

Deming's funnel experiment demonstrates the opposite mistake: reacting to common cause variation as though it were special cause. A marble is dropped through a funnel aimed at a target on a flat surface; the funnel is then moved according to one of four rules, and the experiment is repeated for at least 50 drops under each rule.^[10][11]

• Rule 1. Leave the funnel exactly where it is, aimed at the target. Never move it.
• Rule 2. After each drop, move the funnel, from wherever it currently sits, the same distance and in the opposite direction as the marble's miss.
• Rule 3. After each drop, move the funnel to the position that mirrors the miss, measured from the target rather than from the funnel's last position — the funnel effectively starts over from the target every time.
• Rule 4. After each drop, move the funnel to sit directly over wherever the marble just landed.

Rule 1 is "leave a stable process alone." Rules 2 through 4 are all versions of "the last part was off, so I adjusted the setup," the most common overreaction on a shop floor, and each one makes things worse in a different way. This is tampering: adjusting a process in response to noise it would have produced anyway.

The data below is a constructed simulation of the four rules described above, not a transcription of one specific historical demonstration; the point does not depend on the particular random numbers used.

Let e_k be the marble's own scatter on drop k if the funnel were not moved at all (independent, mean zero, the same spread every time). Rule 1 does nothing to the funnel, so its result is just x_k = e_k. Working through what each rule does to the funnel's position gives a one-line recursion for the others:

Applying that to the first five simulated drops (σ = 5.0 mm) shows the four rules already pulling apart:

Because e_k and e_k−1 are independent, Rule 2's variance is Var(e_k) + Var(e_k−1) = 2σ², exactly double Rule 1's σ², for every drop from the second on. Rules 3 and 4 do not have a fixed variance at all: working through the recursion, Var(x_k) = kσ², growing without bound as more drops accumulate. That is not a property of any particular random numbers; it follows from the recursion whatever the noise turns out to be.

Over this single run, Rule 1's variance was 19.35 mm² and Rule 2's was 36.94 mm², a ratio of about 1.9, close to the exact theoretical value of 2 (both rules are stable, so a single 100-drop run estimates their variance reasonably well). Rules 3 and 4 are a different matter: because their variance keeps growing, no single number describes "the" variance of a random walk, and one 100-drop path is too noisy to read a growth rate off directly — by chance, this particular run ended with Rule 3 at 25.69 mm and Rule 4 at -86.46 mm, but a different run could easily end somewhere else entirely. To check the kσ² growth claim properly, the course ran 150 independent repeats of a shorter, 40-drop experiment and averaged the squared position at two drop numbers across all 150 repeats, which is a proper estimate of the variance at that drop, unlike a single path's own spread.

Rules 1 and 2 barely move between drop 8 and drop 40, as a stable, constant variance predicts. Rules 3 and 4 both grow by roughly the fivefold factor the theory predicts (drop 40 is five times drop 8), confirming that this is not an artefact of one unlucky run but the behaviour the recursion guarantees. The practical reading: a stable process left alone (Rule 1) does about as well as physically possible. Compensating from the machine's current position (Rule 2) doubles the variance but at least stays bounded, which is why habitually "nudging" a machine after every part is merely twice as bad, not catastrophic. Resetting the correction from a fixed reference every time (Rule 3) or chasing the last result (Rule 4) both make a process actively unstable, with no ceiling on how far it can wander. Every one of Rules 2 through 4 starts from a supervisor or operator who saw one data point off target and corrected for it. The process was never broken; the correction broke it.

Common mistakes

1. Drawing a SIPOC or a process map from memory, at a desk. Consequence: the map shows how the process is supposed to work, and the project scopes around a version of the process that does not exist. Fix: walk the floor, watch the actual steps, and confirm the map with the people doing the work.
2. Treating a process map and a value stream map as the same tool. Consequence: a process map with more boxes on it gets mistaken for a VSM, and the project never finds out where the time actually goes. Fix: a VSM is not "more detail," it is time and inventory attached to the boxes; without those two numbers it is still just a process map.
3. Measuring cycle time only, and skipping inventory. Consequence: a step that takes 20 seconds looks fast, while 100 pieces sit in front of it for two days; the project "improves" the 20 seconds and lead time barely moves. Fix: count the piles, not just the stopwatch.
4. Reacting to every part that misses the target. Consequence: Rules 2 through 4 of the funnel experiment, applied on the shop floor: variance goes up, sometimes without bound. Fix: ask whether this one part is common cause (leave the setting alone) or special cause (find out what changed) before touching the machine; Modules 16 and 17 build the chart that answers this reliably.
5. Ranking, rewarding or disciplining people by a stable system's output. Consequence: the red bead lesson, applied to real people: the "best" and "worst" performer this month are often just the top and bottom of the same distribution, and rewarding or punishing them teaches nothing and wastes goodwill. Fix: look at whether performance varies more than the system's own common-cause spread before treating an individual result as meaningful.
6. Calling every kind of waste "inefficiency." Consequence: the fix stays vague ("be more efficient") instead of pointing at inventory, motion, over-processing or one of the other named wastes, each of which has a specific, different fix. Fix: name the waste from Table 2 before proposing a solution.
7. Assuming a process with zero defects has no waste. Consequence: a line that never ships a bad part can still have a process cycle efficiency under 1 %, as in Worked example 2, and nobody notices because the defect count looks fine. Fix: compute PCE; it measures something a pass/fail inspection cannot see.
8. Skipping straight to a capability study or a control chart before the process is even mapped. Consequence: a statistically correct Cpk on a step that is not the constraint, computed on data pulled from a database instead of walked and understood. Fix: SIPOC, then a map with time and inventory, then decide which step is worth the statistical tools in Modules 4 onward.

Exercises

Exercise 1: a second value stream map

Constructed data, not a real production line. Setting: a 3-step assembly and test cell (sub-assembly, final assembly, function test), one shift, demand 600 pieces a day, 25,200 seconds of operating time available.

Tasks. (a) Compute the takt time. (b) Compute the inventory time at each of the four points, in days. (c) Compute the total lead time and the total cycle time. (d) Compute the process cycle efficiency. (e) Is any process step's cycle time above takt? What would that mean if it were?

Exercise 2: a funnel run under Rules 1 and 2

Constructed simulation, σ = 4.0 mm, not a transcription of a real demonstration.

Tasks. (a) Under Rule 1, x_k = e_k. Write down x₁ through x₄. (b) Under Rule 2, x_k = e_k − e_k−1 for k ≥ 2, and x₁ = e₁. Compute x₁ through x₄. (c) Over the full 30-drop run (not just these 8 points), the sample variance came out to 12.70 mm² for Rule 1. What would you predict for Rule 2's variance, and why?

Quiz

Ten questions. Score 70 % or more to mark the module complete on this device.

Key takeaways

• A SIPOC diagram (Suppliers, Inputs, Process, Outputs, Customers) sets a project's boundary in four to eight process steps; it is a scoping tool, not a process map.
• A value stream map attaches cycle time and inventory to each step, and converts them into lead time and process cycle efficiency; a zero-defect process can still spend well under 1 % of its lead time adding value.
• Ohno named seven wastes (overproduction, waiting, conveyance, processing, inventory, motion, correction); Liker later added an eighth, unused employee skill. Naming the specific waste points at the specific fix.
• Common cause variation is built into the system and present in every unit; only changing the system reduces it. Special cause variation is a specific, findable, local change, usually fixable by the person closest to the process.
• The red bead experiment: when every worker draws from the identical system, the spread in their results is ordinary sampling variation, not a difference in skill or effort. Ranking people on it is a mistake.
• The funnel experiment: reacting to a single data point (tampering) never helps. Adjusting from the machine's current position roughly doubles variance but stays stable; resetting from a fixed reference or chasing the last result both make the process actively unstable, with variance that grows without bound.
• None of this needed a control chart. Modules 16 and 17 give you the chart that tells common cause from special cause with arithmetic; this module is the judgment that comes before it.

References

All web sources accessed 2026-09-09. Sources marked "secondary" were not read in the original by the course author; the claim is taken from the source shown.

1. Best, M., & Neuhauser, D. (2006). Walter A Shewhart, 1924, and the Hawthorne factory. Quality and Safety in Health Care, 15(2), 142–143. https://pmc.ncbi.nlm.nih.gov/articles/PMC2464836/
2. Lean Enterprise Institute. Lexicon: "Seven wastes." https://www.lean.org/lexicon-terms/seven-wastes/
3. Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press. https://books.google.com/books/about/Toyota_Production_System.html?id=QebEDwAAQBAJ
4. Liker, J. K. (2004). The Toyota Way. McGraw-Hill. https://books.google.com/books/about/The_Toyota_Way.html?id=eZutzPww02EC (secondary: catalogue-level; the eighth-waste attribution is cited from the book's description, not a full reading)
5. Womack, J. P., & Jones, D. T. (1996). Lean Thinking. Simon & Schuster. https://www.lean.org/the-lean-post/articles/lean-thinking-a-look-back-and-a-look-forward/ (secondary: catalogue-level; cited for the term "value stream")
6. Lean Enterprise Institute. Lexicon: "Value-stream mapping." https://www.lean.org/lexicon-terms/value-stream-mapping/
7. Rother, M., & Shook, J. (1999). Learning to See. Lean Enterprise Institute. https://www.lean.org/lexicon-terms/value-stream-mapping/ (secondary: catalogue-level; the method is described via [6], which confirms this book introduced it)
8. Deming, W. E. (1975). On probability as a basis for action. The American Statistician, 29(4), 146–152. https://deming.org/wp-content/uploads/2020/06/On-Probability-As-a-Basis-For-Action-1975.pdf
9. The W. Edwards Deming Institute. "Red Bead Experiment"; "The Red Bead Experiment with Dr. W. Edwards Deming." https://deming.org/explore/red-bead-experiment/ ; https://deming.org/deming-red-bead-experiment/ (the exact box size, colour split, paddle size and headcount are not stated on these pages; Module 2's numbers are the course's own constructed choice, not Deming's documented figures)
10. Deming, W. E. (1986). Out of the Crisis. MIT Center for Advanced Engineering Study, p. 327. https://archive.org/details/outofcrisisquali00demi (catalogue-level; the page reference is via [11])
11. SPC for Excel. "Over-controlling a process: the funnel experiment." https://www.spcforexcel.com/knowledge/variation/overcontrolling-process-funnel-experiment/ (secondary: a paraphrase of Deming's experiment, not the original)