TBP (Toyota Business Practice)

Definition

Toyota Business Practice (TBP) is Toyota’s formal, company-wide 8-step problem-solving method. It is the standardized approach Toyota expects all employees — from shop floor to executive level — to use when addressing problems, making improvements, and developing plans. TBP is essentially PDCA made explicit in a structured sequence:

The 8 Steps:

1. Clarify the problem — What is the ideal state? What is actually happening? What is the gap?
2. Break down the problem — Decompose the large problem into specific, manageable pieces. Identify the priority point of cause.
3. Set a target — Define a specific, measurable target for improvement with a deadline.
4. Analyze the root cause — Investigate why the problem occurs. Use 5-Why analysis and direct observation at the genba.
5. Develop countermeasures — Generate and evaluate potential solutions that address root causes, not symptoms.
6. Implement countermeasures — Execute the plan. Monitor progress.
7. Evaluate results and process — Did the countermeasures achieve the target? What was learned? What worked and what did not?
8. Standardize and share — If successful, establish the improvement as the new standard. Share the learning horizontally (yokoten) so others can benefit.

Steps 1-5 correspond to Plan. Step 6 is Do. Step 7 is Check. Step 8 is Act. The 8-step structure makes explicit what PDCA leaves implicit — particularly the discipline of breaking down the problem (Step 2) and setting a specific target (Step 3) before jumping to root cause analysis.

History

Before TBP

Before TBP was formalized, Toyota’s problem-solving approach was transmitted through on-the-job coaching and mentorship. Senior managers taught junior managers how to think through problems using PDCA, A3 reports, and direct genba observation. The method was effective but depended on the quality of individual mentors and varied across plants, divisions, and countries.

The Toyota Way 2001

In 2001, Toyota published an internal document titled The Toyota Way 2001 (トヨタウェイ2001), which codified Toyota’s management philosophy for the first time. This was driven by Toyota’s rapid global expansion — the company needed to transmit its thinking discipline to tens of thousands of new employees in new countries who did not have access to the decades of mentorship available in Japan.

TBP was developed as part of this codification effort. It took the implicit PDCA thinking that experienced Toyota managers practiced naturally and made it explicit in a teachable, repeatable 8-step format. The goal was not to replace PDCA or A3 but to make the thinking behind them accessible to people who had not grown up in Toyota’s culture.

TBP and A3

TBP and A3 problem solving are closely related but not identical:

• A3 is a format — a single sheet of paper (A3 size, 11×17 inches) that structures a problem-solving story. The A3 format predates TBP and remains Toyota’s preferred communication medium for problems, proposals, and status reports.
• TBP is the thinking process — the 8 steps that define how to work through a problem. TBP is typically documented on an A3 sheet, but the 8-step structure is more prescriptive than the traditional A3 format.

In practice, Toyota employees use both. An A3 report follows the TBP logic, and TBP is documented using the A3 format. They are complementary tools, not alternatives.

The 8 Steps in Detail

Step 1: Clarify the Problem

This is where most non-Toyota problem-solving efforts fail immediately. Toyota defines a problem as the gap between the ideal state (or standard) and the actual condition. If you cannot articulate the ideal state and the actual condition with specificity, you do not yet understand the problem.

• What should be happening? (Ideal state, standard, target)
• What is actually happening? (Current condition, measured data)
• What is the gap? (The problem, stated specifically and quantitatively)

Many organizations start problem-solving with a vague feeling that “something is wrong.” TBP forces precision before proceeding.

Step 2: Break Down the Problem

Large, vague problems cannot be solved directly. Step 2 decomposes the problem into smaller, specific, observable components. This is the step most people skip — and the step that most determines success.

Example: “Quality is bad” is not a problem that can be solved. Breaking it down: “Defect rate on Line 3, Part A, second shift, is 3.2% versus a target of 0.5%. The primary defect type is surface scratches, occurring at Station 7.” Now you have a specific, investigable problem.

Toyota uses genba observation, data stratification (Pareto analysis by product, time, location, type), and process mapping to identify the priority point of cause — the specific place in the process where the problem is most concentrated.

Step 3: Set a Target

Define what success looks like — a specific, measurable target with a deadline. “Reduce surface scratch defect rate at Station 7 from 3.2% to below 0.5% by March 15.” Without a clear target, there is no way to evaluate whether the effort succeeded (Step 7).

Step 4: Analyze the Root Cause

Go to the genba. Observe the actual process. Ask why repeatedly (5-Why analysis) to trace the chain of causation from symptom to root cause. Use data, not opinion. The cause-and-effect diagram (Ishikawa diagram) may be used to organize thinking, but the root cause must be verified through direct observation, not assumed from a brainstorming session.

Step 5: Develop Countermeasures

Generate potential countermeasures that address root causes. Evaluate them against criteria: effectiveness (will it eliminate the root cause?), feasibility (can we implement it?), and impact on other processes. Select the best option.

Toyota uses the word countermeasure (対策, taisaku) rather than “solution.” The distinction is deliberate: a “solution” implies the problem is permanently solved. A “countermeasure” acknowledges that our understanding may be incomplete and the measure may need adjustment. This language reinforces the iterative nature of PDCA.

Step 6: Implement Countermeasures

Execute the plan. Monitor implementation closely. Communicate with affected parties. This is the “Do” phase of PDCA — implementation, ideally on a limited scale first.

Step 7: Evaluate Results and Process

Compare results to the target set in Step 3. Did the countermeasure achieve the target? Also evaluate the process — what was learned during the effort? What would you do differently? This dual evaluation (results and process) is important for developing problem-solving capability, not just solving the immediate problem.

Step 8: Standardize and Share

If the countermeasure worked, make it the new standard: update standardized work documents, train all relevant personnel, and establish the new method as the baseline. Then share the learning horizontally (yokoten) — notify other lines, shifts, plants, or departments that may face similar problems.

If the countermeasure did not fully achieve the target, return to Step 1 with the new understanding and begin another cycle.

Common Mistakes

Starting at Step 4 (Root Cause Analysis). The most common failure. Teams assume they understand the problem and jump directly to analyzing causes. Without clarifying the problem (Step 1) and breaking it down (Step 2), root cause analysis addresses a vague or incorrect problem statement, producing countermeasures that do not solve the actual problem.

Skipping Step 2 (Break Down the Problem). Large problems feel urgent. The impulse is to analyze the big problem directly. But a broad problem has many potential causes, and root cause analysis scatters across all of them. Breaking down the problem focuses the investigation on the most impactful specific issue.

Weak targets in Step 3. “Improve quality” is not a target. “Reduce defect rate from 3.2% to below 0.5% by March 15” is a target. Without specificity and a deadline, there is no accountability and no way to evaluate success.

Countermeasures that address symptoms, not root causes. If the root cause of surface scratches is a worn fixture that allows the part to shift during processing, adding a final inspection step to catch scratches is not a countermeasure — it is a workaround. The countermeasure is replacing or redesigning the fixture. TBP’s structure forces the connection between root cause (Step 4) and countermeasure (Step 5).

Skipping Steps 7 and 8. After implementing a countermeasure, teams move on to the next problem without evaluating results or standardizing the improvement. Without Step 7, there is no learning. Without Step 8, the improvement is not retained — it erodes as people revert to old methods.