Problem Decomposition is the structured breakdown of a broad problem into smaller, measurable parts.
Instead of asking:
Why is productivity poor?
the team asks:
Which product, process step, shift, loss category, or condition contributes most to the gap?
Decomposition reduces the risk of investigating a problem that is too broad to solve effectively.
Start with a defined gap
Problem Statement helps define:
- expected condition;
- actual condition;
- gap;
- scope;
- timing;
- impact.
Decomposition should begin only after the team agrees on the problem being measured.
Choose logical dimensions
A broad problem can often be separated by:
- product;
- machine;
- process step;
- customer;
- shift;
- defect type;
- loss category;
- location.
Problem Stratification uses the same principle of separating data into meaningful groups to reveal concentration.
The categories should reflect realistic process differences.
Use a decomposition tree
A simple tree can move from a high-level gap to increasingly specific subproblems.
For example:
Delivery misses
→ late production / material shortage / transport delay
→ late production
→ Line A / Line B / Line C
→ Line B
→ changeover / breakdown / speed loss
The team continues until one branch is specific enough for focused investigation.
Quantify each branch
The branches should add back to the larger problem where practical.
If total lost time is 500 minutes, the major categories should explain most of those 500 minutes.
Production Loss Analysis is useful when the problem concerns output or capacity loss.
Quantification prevents the decomposition tree from becoming a brainstorming exercise.
Prioritize the largest or highest-risk branch
Pareto Analysis helps identify the few categories creating most of the impact.
The largest branch is often a good starting point, but risk may change the priority.
A smaller safety-related issue may deserve attention before a larger low-risk loss.
Move from location to cause carefully
Decomposition tells the team where the problem is concentrated.
It does not automatically prove why the problem occurs.
If 70% of defects occur on Machine 4, Machine 4 is the investigation focus, not necessarily the root cause.
Cause Verification should test suspected causal relationships.
Keep the problem level manageable
A branch should be:
- measurable;
- specific;
- actionable;
- meaningful.
If the team decomposes too far, the result can become dozens of trivial categories.
Stop when the selected branch is narrow enough for focused root cause work.
Common mistakes
Starting with a vague problem, creating categories that overlap, decomposing without data, assuming the largest category is automatically the root cause, selecting a branch before quantifying impact, and continuing decomposition until the tree becomes unnecessarily complex are common mistakes.
Practical sequence
- define the performance gap.
- identify logical dimensions.
- split the problem into major branches.
- quantify each branch.
- identify the dominant or highest-risk branch.
- decompose that branch further if needed.
- confirm the selected subproblem is measurable.
- investigate causes.
- verify the cause.
- repeat on the next important branch if the total gap remains.
The practical lesson
Problem Decomposition turns a broad performance gap into a focused investigation.
Solve the part of the problem you can define and measure before trying to solve everything at once.