A total hides where a problem lives. "Invoice errors are 4%" could mean every department is at 4%, or one channel is at 20% and the rest are fine. Stratification splits the data into groups so you can see which.
Where it comes from
Stratification is on the classic list of seven basic quality tools. ASQ notes that more current lists put the flowchart in its place, but the habit matters more than the list. It isn't a chart of its own. It's the habit of keeping a label on every data point (which shift, which supplier, which machine, which customer) so you can split any chart by it later.
How a bot helps
Take the credit-memo tally from a check sheet. A bot splits it by sales channel, product line, order entry clerk team, and whether the order was changed after entry. It reports each group's rate, not just its count: 30 errors from 300 orders is a different story from 30 from 3,000.
A bot can try every split quickly. That's a strength and a risk. Try enough splits and one will look different by chance. So decide the likely splits first, then treat any surprise as a lead to check, not a finding.
On the bots' own work
Split a bot's failed tasks by model, by skill, by input source, or by time of day. "The bot is unreliable" often turns into "the bot is unreliable on one connector".
When to use it
Right after counting, before choosing causes. It's light: minutes once the data carries its labels. It feeds the Pareto chart and tells the fishbone where to look.
Where bots differ
People tend to split by the group they already suspect. A bot has no favorite suspect, which helps. But it also has no sense of which splits are plausible, so it will happily report that errors are higher on Tuesdays. A person decides which differences are worth a check.
Sources: ASQ: seven basic quality tools.
Back to Engineering tools for bots.
Short outline
Stratification: short outline
What it's for
Stratification splits one set of data into groups to find where a problem is concentrated. Each group keeps its own denominator, so rates can be compared, not just counts.
Columns
| Column | What goes in it |
|---|---|
| Measure | What is being compared, such as error rate or days late |
| Split by | The grouping: shift, supplier, product, department, channel |
| Why this split | Why it could plausibly matter, written before looking |
| Group | One row per group |
| Count | Occurrences in the group |
| Denominator | How many opportunities the group had |
| Rate | Count divided by denominator |
| Difference | How far the group is from the overall rate |
| Read | Lead to check, no difference, or too few to tell |
Steps, each with its "done when"
- Name the measure and its denominator. Done when the measure is defined and every data point has a denominator to go with it.
- Pick the splits before looking. Done when each planned split has a written reason it could matter.
- Split and compute rates. Done when every group shows count, denominator and rate, and the groups add up to the total.
- Mark each group. Done when each group is marked lead to check, no difference, or too few to tell, and splits added after looking are labeled as found by searching.
- Hand the leads on. Done when each lead has an owner and the next tool, such as a fishbone, a reconciliation or an observation.
Common mistakes
- Comparing counts instead of rates.
- Groups that don't add back up to the total.
- Trying every possible split and reporting the one that looks different as a finding.
- Calling a group with a handful of items a problem area.