Go to the actual place and see the actual thing

By Iain, 07 Apr 2026

Somewhere in a Toyota plant in the early 1950s, a young engineer stood inside a chalk circle drawn on the factory floor. Taiichi Ohno, the architect of the Toyota Production System, had put him there with a single instruction. Watch. No clipboard, no agenda, just observe what happens in front of you, and do not leave until you can tell me something I did not already know.

This exercise, known as the Ohno Circle, was not a hazing ritual but the distillation of a management philosophy built on a heretical premise. You cannot fix what you have not personally witnessed breaking. Seventy years later, most organisations attempting to implement AI in their service operations are doing the precise opposite. They buy tools based on vendor demos, deploy them into processes they have never mapped, and then wonder why 95% of their generative AI pilots produce no measurable impact on the bottom line.

The Toyota Production System was designed for car factories, but its underlying logic, stripped of manufacturing jargon, is a set of rules about how organisations learn, improve, and stop making the same mistakes twice. That logic also maps onto the AI implementation problem in service organisations. The companies getting AI right are, whether they know it or not, rediscovering principles that Toyota codified before most of their staff were born.

Start with what your customer is paying for

The first of the five lean principles identified by James Womack and Daniel Jones in The Machine That Changed the World is deceptively simple. Define value from the customer’s perspective. Not what your team thinks is clever, nor what the technology can do, and not what the CIO saw at a recent conference. What does the person receiving your service actually need from you?

In manufacturing, this question has relatively clean answers, because a customer buying a car values reliability, safety, and the feeling of the steering wheel in their hands. In a service organisation, value is slipperier and harder to pin down. An insurance customer submitting a claim values speed, clarity, and the absence of bureaucratic friction. A law firm’s client values accuracy and the confidence that their solicitor has read every relevant document. A marketing agency’s client values creative work that moves their numbers, delivered without three rounds of scope renegotiation.

Most AI implementation projects skip this step entirely, beginning with the technology (we have access to GPT-5, what can we do with it?) rather than the customer’s need (where are our clients waiting longest, and why?). MIT’s NANDA initiative, which surveyed 350 workers and analysed 300 public AI deployments for its 2025 State of AI in Business report, found that more than half of generative AI budgets go to sales and marketing tools, while the biggest return on investment sits in back-office automation. The money flows toward what feels exciting, but the value generally sits where the work is dull.

Before you write a single prompt or evaluate a single vendor, map your service delivery from the client’s perspective and identify where they experience delay, confusion, or wasted effort. That map is your starting point.

Make the invisible work visible

Toyota’s production lines run on a system called kanban, a set of visual signals tracking where every component is in the manufacturing process. If something is stuck, you can see it stuck. If a station is overwhelmed, the pile of kanban cards tells you before anyone needs to write a report about it.

Service organisations have the opposite problem, because their work is largely invisible. A legal review sits in someone’s inbox while a client onboarding process often lives across four spreadsheets and two Slack channels. A compliance check may exist as a mental note in a senior partner’s head. When work is invisible, waste is invisible too, and when waste is invisible, AI gets deployed to automate the wrong things.

The practical step here is to map your value stream before you automate anything. Trace a single piece of work, say one client project from intake to delivery, and document every handoff, every wait state, every approval loop, every time someone reformats information that arrived in the wrong shape. In lean terminology, this is value stream mapping, and it distinguishes between activities that add value (the client would pay for them), activities that add no value but are currently required (regulatory steps, internal sign-offs), and pure waste (rekeying data, chasing approvals, correcting errors introduced upstream).

You will almost certainly find that a large proportion of your team’s time goes to work in the second and third categories. This is where AI can help, but only if you have identified these activities first. Deploying a chatbot at the front end of a broken onboarding process does not fix the onboarding process. It puts a friendly face on the same mess, and the mess will swallow whatever you bolt onto it.

Stop the line when something breaks

The second pillar of the Toyota Production System is jidoka, sometimes translated as “automation with a human touch.” The principle works like this. When a machine detects a defect, it stops. It does not keep producing faulty parts in the hope someone catches them at the end. This concept traces back to Sakichi Toyoda’s automatic loom, which would halt itself the moment a thread broke rather than weaving defective cloth.

The modern equivalent in AI-enabled service delivery is the “kill switch”. A marketing agency using AI to draft client analysis needs a process for catching hallucinated statistics before they reach the client. An accounting firm using AI to summarise financial documents needs a defined quality gate that catches misinterpretations before they inform advice. A recruitment consultancy using AI to screen CVs needs a mechanism that flags when the model starts producing obviously skewed shortlists.

Jidoka is not about distrusting the technology but about building quality into the process rather than inspecting for it at the end. In practical terms, this means establishing what Toyota calls “stop and fix” authority at every stage where AI-generated output feeds into human decisions. Define the conditions under which an AI-assisted process halts for human review, make those conditions explicit and written down, and treat them as non-negotiable. The RAND Corporation’s analysis of AI project failures found that the model itself rarely breaks, but what buckles is the invisible infrastructure around it, which is exactly the gap that jidoka was designed to fill.

The equivalent of Toyota’s andon cord, which any worker on the line can pull to stop production, should exist in your AI workflow too. Any team member who spots an AI output that looks wrong should have the authority and the mechanism to pause the process without needing to escalate through two layers of management first.

Pull work through the system, do not push it

Just-in-time production, the other pillar of TPS, operates on a pull system where work happens when the next stage in the process needs it, not when the preceding stage feels like producing it. Toyota’s assembly line does not build up piles of doors waiting for cars to attach them to. It produces a door when a car arrives that needs one.

Service organisations typically run push systems without realising it, generating work upstream (proposals written, reports drafted, analyses completed) and shoving it downstream whether or not the next stage is ready for it. The result is bottlenecks and a lot of partly-finished work sitting in various states of limbo.

AI makes push systems worse if you are not careful, because it is trivially easy to generate more output faster with these tools. A team that previously produced five client reports a week can now produce fifteen, but if the review bottleneck downstream can still only handle seven, you have not improved throughput. You have built a bigger pile of unreviewed work and created what lean practitioners call mura, or inconsistency, one of the three enemies of efficient production alongside muri (overburden) and muda (waste).

The practical application is to implement capacity constraints before you implement AI acceleration. Map the throughput of your entire delivery chain, not one step in it. If your review process can handle seven reports per week, your AI-assisted drafting process should produce seven reports per week. Producing more is overproduction, which in lean thinking is the worst form of waste because it consumes resources, creates storage problems, and masks the bottlenecks you should be fixing instead.

Go and see for yourself

Genchi genbutsu, which translates roughly as “go to the actual place and see the actual thing,” is the principle that Ohno considered the bedrock of the entire system. You cannot grasp a problem from a dashboard, and you cannot diagnose a workflow failure from a meeting room. You have to watch the work happening, talk to the people doing it, and form your own picture of where it breaks.

In service organisations implementing AI, this means the people making decisions about which processes to automate need to spend time watching those processes operate. Not reading about them in a process document or hearing about them in a stakeholder interview, but actually watching a team member work through a client onboarding, a claims triage, or a contract review, and counting the minutes they spend on each activity.

Ohno’s chalk circle exercise, where he would have new engineers stand in one spot and simply observe the production line for hours, has a direct equivalent for AI strategy. Pick a process you are considering automating and sit with the team that runs it for a full day. Note what they actually do versus what the process documentation says they should do. The gap between those two things is where your AI implementation will either succeed or fail, because the documented process is almost never the real process.

A 2011 Harvard Business Review article by Bradley Staats and David Upton on applying lean to knowledge work identified six principles for making the transition, and the first was to make tacit knowledge explicit. Service work runs on tacit knowledge that lives in people’s heads rather than in documents. The workaround that Sarah uses for difficult clients, the mental checklist that David runs before approving a report, the informal quality gate that exists nowhere in writing. AI cannot replicate or support what has not been articulated, and genchi genbutsu is how you surface it.

Improve continuously, not heroically

Kaizen, the principle of continuous incremental improvement, is perhaps the most misunderstood element of the Toyota system. It is not a programme or an initiative with a start date and a PowerPoint deck but a daily practice of making small adjustments based on observed results, carried out by the people closest to the work.

The opposite of kaizen is the big-bang AI transformation, which is how most service organisations approach implementation. They spend months building an AI strategy document, hire a consulting firm, launch a centre of AI Excellence, run a twelve-week pilot, and then attempt to roll the whole thing out at once. S&P Global research shows that 42% of companies abandoned the majority of their AI initiatives in 2025, up from 17% the year before, and the big-bang approach typically generates big-bang failures.

The kaizen alternative looks less impressive on a slide deck but works far more reliably. Pick one process, implement one AI-assisted change, and measure the result against a specific metric such as time saved, error rate reduced, or client satisfaction improved. Then adjust and repeat. The people running the process should be the ones suggesting and testing improvements, not a central AI team operating in isolation.

Toyota’s approach to this is captured in the Plan-Do-Check-Act cycle developed by Walter Shewhart and popularised by W. Edwards Deming. Plan the change and do it on a small scale, then check the results against your expectations and act on what you learned by either adopting the change, adjusting it, or abandoning it. Each cycle should be small enough that failure is cheap and learning is fast. If your AI pilot takes twelve weeks to produce results you can evaluate, your cycle is too long.

Respect the people doing the work

The Toyota Production System is sometimes reduced to a set of efficiency tools, but Toyota’s own description of TPS stresses that it rests on two pillars (just-in-time and jidoka) supported by the bedrock principle of respect for people. Workers on the Toyota line are not interchangeable parts but problem-solvers with authority to stop production, suggest improvements, and challenge processes that do not make sense.

This matters for AI implementation because the single biggest risk in service organisations is not that the technology fails but that the people doing the work disengage. NTT Data’s research on AI adoption found that trust among staff is a critical variable, and that distrust does more than slow adoption down. It breeds active resistance. People who fear being replaced by AI will not volunteer the tacit knowledge that makes AI implementation possible, will not flag when the AI gets things wrong, will not suggest process improvements, and will quietly let the project fail.

The lean approach inverts this dynamic by involving workers in the design of their own processes. In an AI context, that means the team members who currently run a process should be the ones defining where AI can help, testing whether it actually does help, and retaining the authority to reject tools that make their work worse. It means being honest about what AI is for, and in most service organisations the goal should be to remove tedious, repetitive work so that skilled people can spend more time on the work that requires human judgment. If your AI strategy cannot be explained to your team in those terms, you either have the wrong strategy or the wrong intention.

The assembly line that learns

Toyota did not invent the production line (Henry Ford did that) but it did invent a production line that could detect its own errors, adapt to changing demand, and improve itself through the accumulated wisdom of the people who worked on it every day. The Toyota Production System is, at bottom, a learning system, and the 1990 MIT study that popularised it coined the term “lean production” specifically because TPS was so different from the mass-production thinking that preceded it.

The AI implementation problem in service organisations is, likewise, a learning problem. The technology is not the constraint that holds most projects back. RAND’s analysis confirms that more than 80% of AI projects fail to reach production, and that the model itself is rarely the thing that breaks. What breaks is the organisational capacity to fold the technology into workflows operated by people who serve actual customers.

The Toyota Production System provides a tested framework for building that capacity. Define value from the customer’s perspective. Make the work visible before you attempt to improve it. Build quality controls into every step rather than catching errors at the end. Match your output to your downstream capacity rather than overproducing. Go and watch the work before you redesign it. Improve in small, measured increments rather than grand transformations. And treat the people doing the work as the experts they are, because they will be the ones who make or break whatever you build.

Ohno’s chalk circle is still there, drawn on factory floors and (increasingly) on the metaphorical floors of digital workplaces around the world. The instruction has not changed. Stand here, watch, and tell me what you see. It is not glamorous advice for an era obsessed with the infinite possibility of artificial intelligence, but the best advice rarely is.