Split Solving breaks a problem into measurable parts until only the root cause is left
It takes a team from an unclear problem to a root cause it can prove, then to a fix that lasts.
Split Solving
Split Solving is our root cause method
Split Solving, also called Variable Analysis, is our root cause method. It takes a team from an unclear problem to a root cause it can prove.
We use it in place of 5 Whys and fishbone diagrams on high-value constraints. Those tools suit simple problems, but not the hidden causes in complex manufacturing.
Use it when:
- nobody knows the root cause, and people are guessing at solutions
- earlier fixes treated the symptom, and the problem came back
- several factors may contribute, and you need to isolate which
- you need to prove you understand the problem before you change anything.
If you already know the root cause, skip it and plan the fix.
At Gü Desserts, we used Split Solving to find the root cause of the excess weight in the finished product.
We often start from a RAG study, which shows where the bottleneck’s time goes.
Step 1: define the problem before anyone splits it
This is the step teams skip most, and skipping it undermines everything after. A good problem statement says what is wrong, not why.
It is specific and observable, says when and where, and gives the size of the gap. For example: “Line 3 afternoon shift reject rate is 15%, against a normal 3%.”
Then pick one key variable with a target and an actual value. It must read “no problem” inside its range and “problem” outside it.
Step 2: describe the problem in detail
We look before we analyse, so experience does not jump to a familiar answer. We go to the line, take photos and video, and talk to operators.
We plot the data over time, because a graph shows patterns that a table of numbers hides. Then we ask four questions:
- What: what does the failure look like, and how do the cases differ?
- When: how often, at what times, since when, and before or after which events?
- Where: where is it first visible, and on which equipment?
- Which: which products, shifts, operators and batches are affected, and which are not?
If the problem happens naturally, its causes exist and can be changed. So we try to recreate it under control.
Step 3: split the key variable, one level at a time
Each split breaks a variable into parts that fully account for it. Every level must work as an equation.
Additive: Total Downtime = Planned + Unplanned
Multiplicative: Fill Volume = Flow Rate × Time Under Nozzle
| Rule | What it means | Why it matters |
|---|---|---|
| Mutually exclusive | No overlap between branches | Nobody counts effort on the same cause twice |
| Collectively exhaustive | All possibilities covered | The root cause cannot hide outside the tree |
| Measurable | Data can confirm each branch | Keeps the analysis on facts, not opinions |
| Functional or geographic | Splits follow how the system works or where things are, never both at one level | Lines the investigation up with how the system actually works |
We aim for three to seven splits per level. We rule branches out before we split further, so the tree stays small.
Step 4: compare target with actual and close each branch
| Mark | When | Next |
|---|---|---|
| ✓ Resolved | Actual matches target, or changing it has no effect within the normal range | Rule the branch out |
| X Root cause | Actual misses target, and we understand why | Find a solution |
| ? Unknown | Actual misses target and we do not know why, or we cannot measure it | Split it further |
We repeat steps 3 and 4 until every branch ends in ✓ or X. We assume a branch is out of specification until we prove it is not.
Then we explain how each X causes the problem and how the causes combine. The explanation must account for everything we saw in step 2.
Step 5: fix the root cause, not the symptom
Extra checks, extra inspections and extra people manage a symptom. A root cause fix removes the mechanism behind each X.
We judge each option on whether it removes the cause, lasts without upkeep, can be done with what you have, and pays back.
Afterwards we check that the key variable is back on target and stays there. If it is not, we go back to step 3.
An illustration: half-filled bottles. Since a changeover, every bottle holds 250ml against a 500ml target.
Fill Volume = Flow Rate × Time Under Nozzle. Flow rate is on target, but each bottle spends 30 seconds under the nozzle, not 60.
Time under the nozzle = distance ÷ belt speed. The distance is right, but the belt runs at 120 bottles a minute, not 60.
The root cause: the belt speed setting was not changed at the changeover. The fix adds the setting to the changeover checklist and checks the first bottles afterwards.
The tool takes you through Define, Split and Understand, and saves your progress in your browser.