What it is

A structured approach to problem solving that helps the team move from "what is happening?" to "what do we change to prevent it from happening again?"

Why it is needed

• Stops "firefighting" and helps focus on root causes.
• Ensures that the solution is tested (PDCA) and standardized.
• Helps manage actions: responsibilities, deadlines, measurements.

How to use

1. Describe the problem with facts (where, when, how much).
2. Set a goal (what we will improve and by when).
3. Gather data and describe the current state.
4. Analyze the causes (5 Whys / Fishbone).
5. Select solutions, conduct PDCA testing, standardize.

Common mistakes

• Starting with solutions without defining the problem.
• Action plan without responsible parties, deadlines, and KPIs.

What it is

A one-page format that encapsulates all the logic: problem → current state → cause → measures → measurement.

Why it is needed

• Clear communication: one page – one story.
• Quick agreement on direction and responsibilities.
• Easy to track progress and KPIs.

How to use

1. Describe the problem + impact (time/€ /quality/safety).
2. Include 1–2 facts (graph, numbers).
3. Identify the root cause.
4. Describe measures and the measurement plan (KPIs, when you will check).
5. Standardize: what changes in the process.

Common mistakes

• Too much text, too few facts.
• Measures without a measurement plan.

What it is

A quick method for identifying the root cause by asking "why" several times until reaching the process/management cause.

Why it is needed

• Helps move from symptom to cause.
• Reduces "guesswork" solutions.
• Creates a clear action that eliminates the cause.

How to use

1. Write down the problem as a fact.
2. "Why?" → answer #1.
3. Repeat 4–5 times.
4. Check if the cause is manageable (not "human error").
5. Assign action + verification.

Common mistakes

• "Human error" left as the final cause.
• Answers not validated by facts.

What it is

A cause map where the team lists possible causes by categories (People, Process, Equipment, etc.).

Why it is needed

• Helps systematically avoid "blind spots".
• Allows agreement on what to check with data.
• Works well as a team brainstorming structure.

How to use

1. Write the problem in the center.
2. Select categories.
3. List the causes.
4. Highlight 2–3 most likely.
5. Plan the verification (data/test/gemba).

Common mistakes

• Generic phrases without specificity.
• Not selecting what to check in reality.

What it is

A prioritization method: helps find which few problems create the greatest impact (80/20 principle).

Why it is needed

• Helps focus on the greatest benefits.
• Decisions based on data, not intuition.
• Quickly identifies "top" focus.

How to use

1. Group problem types under the same names.
2. Input frequency or losses.
3. Sort from highest.
4. Select 2–3 most important.
5. Address the "top" problem using A3 or 8 steps.

Common mistakes

• Different names for the same problem.
• Guesses instead of data.

What it is

A matrix for solution selection: ideas are evaluated based on impact and effort.

Why it is needed

• Quickly identify "quick wins".
• Easy to align priorities.
• Creates a clear backlog.

How to use

1. List ideas.
2. Agree on criteria (what is "impact" and "effort").
3. Evaluate and place in quadrants.
4. Select quick wins and plan actions.

Common mistakes

• No common criteria (subjective).
• All solutions labeled as "high impact".

What it is

A form that helps turn an idea into action: problem, proposal, benefit, effort, responsible, deadline.

Why it is needed

• Ideas do not linger in the "mind" – they become actions.
• Easy to assess benefits and efforts.
• Clear who is responsible and by when.

How to use

1. Describe the problem.
2. Write the proposal.
3. Assess the benefit (time/€ /quality/safety).
4. Assess the effort.
5. Assign responsible, deadline, and status.

Common mistakes

• No responsible/deadline – the idea "sleeps".
• No result recording upon closure.

What it is

A one-page board for the daily rhythm of the team: KPIs, deviations, actions, responsible parties, deadlines.

Why it is needed

• Transparency: everyone sees deviations and actions.
• Faster response and fewer "lost" tasks.
• Actions are closed with verification.

How to use

1. Input 3–6 KPIs.
2. Record deviations daily.
3. Assign action + responsible + deadline.
4. Close only with a fact (what changed).
5. Raise 1 serious problem to A3/8 steps.

Common mistakes

• The board turns into a "status list" without solutions.
• Too many KPIs or unclear goals.

What it is

A standardized "go to the place" to see the process in reality and record facts and follow-up actions.

Why it is needed

• In reality, you see obstacles that are not visible in reports.
• Strengthens problem-solving and team trust.
• Encourages small, frequent improvements.

How to use

1. Set a goal (what to observe).
2. Record facts (what you see).
3. Ask 1–3 "why" questions.
4. Write down actions and deadlines.
5. Next time start with verification.

Common mistakes

• Turns into blaming/audit rather than learning.
• No follow-up and closure.

What it is

A support tool for the 5S standard: checklist + scores + actions.

Why it is needed

• 5S does not sustain without regular checks.
• Clear what needs fixing and who is responsible.
• Visible progress over time (scores).

How to use

1. Select a zone and audit date.
2. Evaluate criteria based on 5S.
3. Select 1–5 most important deviations.
4. Assign actions and deadlines.
5. Repeat the audit and compare scores.

Common mistakes

• Different auditors evaluate differently (no criteria).
• Actions are not closed (audit is meaningless).