Implementation Guide
Yokoten.
Yokoten is the Lean practice of spreading a proven improvement or countermeasure sideways, from the line or plant that developed it to every place with the same problem. The working rule: adopt the standard, adapt the method, keep the result. Copy-paste rollouts ignore local conditions and breed quiet rejection; reinventing everywhere wastes the learning. The receiving team must understand why the practice works, then decide how to run it locally, and prove the same result.
What yokoten means
Yokoten is the lateral deployment of proven practice. When one line, one shift or one plant develops something that verifiably works, a faster changeover method, a cleaner escalation routine, a fixture that prevents a defect, yokoten is the discipline of carrying that learning sideways to every place with the same problem. It covers two streams: improvements, where a better way spreads, and countermeasures, where a verified cause found on one line triggers every sister line to check itself.
Yokoten fails in both directions. Copy-paste rollouts mandate the source's solution everywhere, ignore local conditions, and breed the quiet rejection every plant knows: the new standard is displayed, signed and worked around. Reinvention everywhere is the opposite failure: each site solves the same problem from scratch, at full cost, and the organization pays for the same learning five times. The working rule that avoids both: adopt the standard, adapt the method, keep the result. The receiving site must understand why the practice works before deciding how to run it locally, and the result it commits to is not negotiable.
The carrier of yokoten is standardized work. A practice that exists only in someone's head, or only in a slide deck, cannot travel. A practice captured as a living standard, with its conditions and its measured result, can be seen, taught, trialed and verified somewhere else.
Where yokoten sits in the transformation roadmap
On the TeamGuru deployment roadmap, yokoten belongs to the Standardize & Scale practice in the Scale stage, and it is the payoff of everything standardized before it. The kaizen pipeline produces verified improvements worth spreading, standard work makes them portable, and the review rhythm built in the Obeya and management reviews practice gives transfers a place to be chosen, tracked and verified. Without those foundations, yokoten degenerates into a best-practice newsletter.
- Before Kaizen
- Before Obeya & Management Reviews
- You are here Standardize & Scale
- In parallel Skills Matrix
When not to spread
The most common yokoten mistake happens before any transfer starts: spreading a practice that is not yet stable at its source. A practice needs to survive contact with normal life, absences, model changes, a bad week, before it is worth exporting. One site running a practice well for 90 days beats a corporate rollout of a prototype, because the 90 days produce the two things a receiver needs most: evidence that the result holds, and knowledge of the conditions it depends on. A rollout of a prototype spreads the bugs along with the feature, and every receiving site debugs them separately, at full price, while confidence in the whole idea drains away. Do not spread when:
- The practice is younger than roughly 90 days at the source. It may still be riding the attention of its creators rather than standing on its standard.
- The source cannot name the conditions the result depends on. Without conditions, the receiving site cannot judge what applies and what does not.
- The result was declared, not measured. A practice without before-and-after data spreads a story, not a method.
- No receiving site actually has the problem. Spreading for the sake of alignment produces shelfware and resentment in equal measure.
How to run a transfer
A yokoten transfer is a small project with six steps and named owners, not an email with an attachment. To make the steps concrete, follow one illustrative transfer at the 450-person components manufacturer used across this site: machining line 2 cut its changeover from 47 to 18 minutes with a SMED project and has held the new standard for four months. A sister line in a second plant runs similar machines with a smaller crew and a heavier product mix, and its changeovers still take around 45 minutes.
| Step | What good looks like | Owner |
|---|---|---|
| Document the practice at the source | The source team writes down the standard, the measured before-and-after result, and the conditions the result depends on: machine type, crew size, product mix, batch profile. A practice that cannot state its conditions is not ready to travel. | Source team leader |
| Receiving site visits and sees it run | Two or three people from the receiving team watch the practice live through at least one full cycle, ask why each element exists, and list what is different back home. Reading the document is not a substitute; most of what makes a practice work is visible only at the process. | Receiving team leader |
| Local trial with the source as coach | The receiving team runs the practice on one line or one shift for two to four weeks, with someone from the source visiting or on call. The trial separates the elements that carry the result from the elements that were local habit at the source. | Receiving team, coached by the source |
| Local standard written by the receiving team | The receiving team writes its own standard in its own words: the result-carrying elements stay, layout, roles and timing adapt to local conditions. A standard written by the source or by headquarters gets filed politely and ignored. | Receiving team leader |
| Result verified against the source baseline | Same metric, same measurement method, compared with the source's verified result after the local standard has run for several weeks. The transfer closes when the numbers hold, not when the documents are signed. | Receiving area manager |
| Both sites review learnings | One short review: what transferred cleanly, what had to change, what the source takes back. The practice document gets updated with the new conditions and contacts, so the third site starts smarter than the second. | Transfer sponsor with both team leaders |
Two rules make the sequence work. First: people travel, documents follow. Seeing the practice run beats reading about it, because the document records what the source team thought to write down, while the visit shows everything else: how the cart is staged, what the operator checks without being told, where the timing actually comes from. Budget the travel; it is the cheapest part of the transfer and the first thing finance wants to cut.
Second: the receiving team owns its adoption. The source coaches, the sponsor removes obstacles, but the local trial, the local standard and the verified result belong to the people who will live with the practice. Ownership is not a courtesy. It is the mechanism that turns a foreign solution into a local standard that survives the night shift, the vacation season and the next reorganization.
Copy-paste vs yokoten
The changeover transfer shows the split in practice. What transfers: the separation of internal and external work, the quick clamps, the standardized first-piece check, and the result target of a changeover under 20 minutes. What adapts: the external prep is staged differently because the receiving crew is two people instead of three, and the fixture rack sits on the opposite side of the aisle. What must never adapt: changeover minutes measured the same way, from last good part to first good part, against the source's baseline. That three-way split, transfer, adapt, verify, is the whole method in one table:
| Element | Copy-paste rollout | Yokoten |
|---|---|---|
| The standard and its logic | Mandated word for word, including details that only made sense at the source | Transfers, together with the reasoning: the receiving team learns why each element carries the result before deciding anything |
| The result target | Rarely stated; distributing the documents counts as done | Transfers unchanged: the receiver commits to the source's verified result before adapting anything else |
| Layout, roles, timing | Copied even where lines, crews and shift patterns differ | Adapted deliberately by the receiving team, with the source as coach |
| Verification | Skipped, or replaced by a rollout-complete checkbox | Never adapted: same metric, same measurement method, compared to the source baseline weeks after go-live |
The verification row is the one organizations negotiate away first, and the one that makes everything else honest. A transfer whose result is measured differently at the receiver is not a transfer. It is two unrelated projects with the same name.
Countermeasure yokoten
The second stream of yokoten moves faster and is easier to justify: spreading verified causes, not just improvements. When one line proves a root cause, an under-torqued fitting traced to a missing check in standard work, for example, every sister line and every similar product family checks itself against that cause within days, not at the next audit cycle. The question each line answers is short: can this happen here, and what is the evidence? An answer of opinion does not count; someone looks at the process, the standard and the data.
Formal problem-solving methods build this in. Discipline D7 of an 8D report, prevention, is a yokoten instruction: update the FMEA and control plan, then look across similar parts, lines and plants for the same failure mode. A defect found on one product and checked across the family the same week is yokoten working at its cheapest, because the cost of the learning was already paid on the line that found it. For causes worth watching longer, the check can join the question set of the plant's layered process audits for a quarter, so the lookacross is verified by more than one pair of eyes.
Speed separates the streams. A practice transfer deserves the full six-step checklist and takes weeks. Countermeasure yokoten is measured in days and needs three steps: the verified cause travels with its evidence, each sister line answers the question at the process, and the answers are recorded where the original problem case can see them.
Making it systematic
One transfer is a project. A yokoten system needs three standing pieces. The first is a shared practice library that earns its existence: each entry carries the standard, the measured result, the conditions it depends on, and a named contact who will host a visit. An entry missing any of the four is dead weight, and a library of dead weight is why most best-practice portals go unopened. Fifty entries that meet the bar beat five hundred that do not.
The second piece is a feed. The kaizen pipeline already ends in a standardize-and-share step; that step is where candidates for the library are nominated, along with closed problem cases whose countermeasures changed a standard. Nobody should have to remember to feed the library. The improvement and problem-solving systems do it as part of closing their own loops.
The third piece is a rhythm. Quarterly exchange reviews bring sites together to show verified transfers and pick the next ones, with the visits scheduled before the meeting ends. And the monthly management review asks one standing question: which of our verified improvements has a second site adopted, and what is blocking the rest? The question costs two minutes and keeps the system honest, because a quarter with no transfers is a finding, not a coincidence.
Common failure modes
Yokoten fails in recognizable patterns, and almost all of them come from skipping either the visit, the local ownership, or the verification.
What bad looks like
- A corporate best-practice portal with hundreds of entries, no conditions, no contacts, and no recorded visits
- Mandated copying on a corporate deadline, which dies quietly on the night shift within a month
- Success theater: transfer results declared in a review slide, never measured at the receiving line
- Transfers with no named owner on the receiving side, so adoption belongs to everyone and no one
- Sites rewarded for exporting practices and quietly punished for adapting them
What good looks like
- Every practice travels with its conditions, its measured result and a named contact who hosts visits
- Receiving teams see the practice run before deciding how to run it locally
- Local standards written by the people who will be audited against them
- The same metric, measured the same way, verified against the source baseline
- Both sites review learnings and the practice library gets the update
What happens next
Yokoten sits at the end of the roadmap because it multiplies whatever the earlier stages built. A plant that standardizes, improves and verifies can spread; a network of plants that spreads can learn at a pace no single site can match. The quiet prerequisite is comparability: spreading is only visible when sites measure the same things the same way, which is why a common set of KPI definitions matters more to yokoten than any portal. If two plants define changeover time differently, no one can say whether the transfer worked.
The other prerequisite is that standards live somewhere they can be adopted rather than forwarded. This is where TeamGuru fits the chain: with document management, practices stay versioned with cross-site visibility, so adopting a standard means adopting a working, current document with its conditions and its history, not receiving a PDF that was out of date the day it was attached. The receiving site writes its local standard next to the source's, and both stay findable when the third site comes asking.
On the Scale stage of the roadmap, yokoten runs alongside the skills matrix work of building capability deliberately: transfers move faster when the receiving site already has people qualified on the underlying standards, and every completed transfer creates the next generation of coaches.
