In 1950, W. Edwards Deming flew to Japan at the invitation of the Union of Japanese Scientists and Engineers. The country's manufacturing sector was producing goods so poor in quality that "Made in Japan" had become a global synonym for cheap and unreliable. Deming, an American statistician and management consultant who had been largely ignored by American industry, spent weeks teaching Japanese engineers a radically different way to think about quality.
His central argument was that most quality problems were not caused by careless workers — they were caused by management systems that did not support quality production. Fixing the workers was the wrong intervention. Fixing the systems was the right one.
Within a generation, Japanese manufacturers had not only achieved quality parity with their Western counterparts but had surpassed them. Toyota became the most studied manufacturing organization in history. "Made in Japan" became a mark of quality. The United States had exported expertise it then had to reimport.
What Japan learned — and what has since spread to industries far beyond manufacturing — is the foundation of operational excellence.
What Operational Excellence Actually Means
Beyond Slogans
Operational excellence is frequently used as corporate language for "we want to do better." In its more rigorous form, it describes a specific set of principles, frameworks, and cultural conditions that enable organizations to improve performance systematically and sustainably.
The operational definition that most practitioners would accept: operational excellence is the state in which every employee can see the flow of value to the customer, can identify when that flow is abnormal, and has the knowledge and authority to fix it.
This definition has three components that are each necessary:
- Visibility: Employees can see how work flows, where it slows, and what the standard is
- Abnormality detection: Employees can distinguish between normal and abnormal conditions
- Response capability: Employees are empowered and equipped to address problems at the source
Without visibility, problems go unnoticed. Without abnormality detection, everything seems equally acceptable. Without response capability, visible problems remain unfixed. Most organizations fail on at least one of these three conditions. The majority fail on all three simultaneously, which is why operational excellence programs that address only one dimension — installing visual management boards without providing response authority, for instance — produce limited and temporary results.
What It Is Not
Operational excellence is not:
- A one-time improvement project
- A cost-cutting exercise rebranded with improvement language
- A certification or award
- The exclusive domain of operations or manufacturing functions
- A consultant-delivered program with a defined end date
It is a permanent organizational capability — a way of working, not a program with a start and end date. Organizations that achieve it do not "do operational excellence"; they operate in a fundamentally different way than those that do not. James Womack, co-author of The Machine That Changed the World (1990) and founder of the Lean Enterprise Institute, has consistently argued that the most dangerous misunderstanding of lean is treating it as a toolkit rather than a management system built on specific principles about how value is created and how organizations learn.
The Origins: Toyota and the Production System That Changed Everything
The Context
Toyota in the 1950s was a small company with limited capital, constrained floor space, and a domestic market too small to support the mass production model that American manufacturers had perfected. Ford's River Rouge complex could produce a car from raw materials to finished product in 81 hours because it could afford to maintain enormous inventories of every component. Toyota could not.
Taiichi Ohno, Toyota's chief engineer, visited Ford's plants in the 1950s and came away with a counterintuitive conclusion: Ford's mass production model, far from being something to imitate, was built on waste. Enormous inventories of components sat unused. Defects were not caught until large batches had already been produced. Equipment was optimized for high volume but not for flexibility.
Ohno built a different system. His two foundational principles:
Just-in-time (JIT): produce what is needed, when it is needed, in the quantity needed — and no more. JIT required completely rethinking inventory management, supplier relationships, and production scheduling. It was a radical departure from the safety-stock logic that governed Western manufacturing, where buffers were treated as prudent risk management rather than waste.
Jidoka (autonomation): machines should be intelligent enough to detect abnormal conditions and stop production automatically, rather than continuing to produce defects. Critically, Ohno extended this principle to people: any worker on the Toyota production line could — and was expected to — stop the entire line when they identified a defect or problem.
The andon cord — a physical cord along the production line that workers could pull to stop production — became the most visible symbol of this philosophy. Most Western managers who visited Toyota could not believe it. Stopping the line cost money. Defects could be caught and corrected at the end. Why would you give workers the authority to stop everything?
Because stopping production for five minutes to fix a problem is dramatically cheaper than continuing to produce defective parts for eight hours and fixing them in rework. Because problems caught immediately can be analyzed and corrected; problems caught later have already propagated through hundreds of subsequent assemblies. The andon cord was not a worker empowerment gesture — it was an economically superior approach to quality control, grounded in the simple insight that the cost of a defect grows exponentially the later it is caught.
Shigeo Shingo, who worked closely with Ohno and later became the namesake of the Shingo Institute, formalized the concept of poka-yoke (mistake-proofing): designing processes so that errors are either impossible to make or immediately detectable. Shingo's 1986 book Zero Quality Control argued that statistical sampling for quality control was fundamentally the wrong approach — it accepted a certain defect rate as inevitable and focused on catching defects rather than preventing them. Poka-yoke aimed for zero defects by changing the system rather than inspecting the output.
The Eight Wastes
Ohno categorized non-value-adding activities into types of muda (waste). His original list of seven was later expanded to eight by lean practitioners:
| Waste Type | Description | Manufacturing Example | Knowledge Work Example |
|---|---|---|---|
| Overproduction | Producing more than needed | Making 100 units when 80 were ordered | Creating reports nobody reads |
| Waiting | Idle time caused by delays | Machine waiting for operator | Waiting for approval before proceeding |
| Transport | Unnecessary movement of materials | Moving parts across a facility | Emailing documents back and forth |
| Overprocessing | More work than required | Polishing a surface the customer cannot see | Six approval signatures for a routine expense |
| Inventory | More stock than needed | Excess components creating storage costs | Unread email backlogs; incomplete work queues |
| Motion | Unnecessary movement of people | Searching for tools | Searching for information across multiple systems |
| Defects | Producing incorrect output | Parts requiring rework or scrap | Errors requiring revision; miscommunicated requirements |
| Underutilized talent | Not using employees' skills | Skilled worker doing simple assembly | Front-line workers not involved in improvement |
The last waste — underutilized talent — was added by American lean practitioners and reflects a critical insight: the people closest to the work have the most detailed knowledge of how it actually functions. Operational excellence programs that treat improvement as a management or engineering function and exclude front-line workers from problem-solving are leaving their most important resource on the table. Womack and Jones (1996) documented this pattern repeatedly in their field research: organizations that succeeded sustained the involvement of front-line workers in kaizen events and standard work development; those that failed treated improvement as a staff function.
Lean vs. Six Sigma: Understanding the Difference
Lean Manufacturing
Lean refers to the management practices derived from the Toyota Production System, popularized by James Womack and Daniel Jones in their 1990 book The Machine That Changed the World and systematized in their 1996 Lean Thinking.
Lean's core concern is flow: value should flow smoothly from start to customer without interruption, delay, or wasteful detour. The primary analytical tool is value stream mapping — drawing out every step in a process, distinguishing value-adding from non-value-adding steps, and systematically eliminating or reducing the latter.
Lean's signature practices include:
- 5S (Sort, Set in order, Shine, Standardize, Sustain): organizing the workspace for efficiency and visibility
- Kanban: visual pull-based systems that signal when more work should be started
- Kaizen: continuous small improvement events involving front-line workers
- Standard work: documenting the current best method for performing a task as the baseline for further improvement
- Heijunka (production leveling): smoothing the volume and mix of work to reduce variation in demand on resources
Six Sigma
Six Sigma was developed at Motorola in the 1980s and popularized by Jack Welch at General Electric in the 1990s. Where Lean focuses on waste and flow, Six Sigma focuses on variation and defects.
The name refers to a statistical target: a process operating at six sigma produces fewer than 3.4 defects per million opportunities — an extremely high level of consistency. Achieving this requires rigorous statistical analysis of process variation. In practice, most processes operate at three or four sigma (roughly 67,000 or 6,200 defects per million opportunities respectively), and moving to six sigma requires not just effort but a fundamental redesign of the process.
Six Sigma's primary methodology is DMAIC:
- Define: identify the problem, the customer's requirements, and the scope of the project
- Measure: collect data on the current process to establish a baseline
- Analyze: use statistical tools to identify root causes of variation and defects
- Improve: design, test, and implement solutions
- Control: establish monitoring systems to sustain the improvement
Six Sigma creates certified practitioners — Green Belts, Black Belts, Master Black Belts — with progressive levels of statistical and project management expertise. GE's implementation under Welch in the 1990s trained over 100,000 employees at various belt levels and claimed $12 billion in cost savings over five years (Pande, Neuman & Cavanagh, 2000).
Lean Six Sigma
Most modern organizations that practice operational excellence use Lean Six Sigma — a combined approach that addresses both waste/flow (Lean) and variation/defects (Six Sigma). The two frameworks complement each other: Lean removes waste to speed flow; Six Sigma reduces variation to improve quality. Neither alone is sufficient for comprehensive operational improvement.
A process that flows fast but produces highly variable output needs Six Sigma's statistical tools. A process with low defect rates but enormous waiting times and unnecessary steps needs Lean's waste elimination. The combined framework enables organizations to pursue both simultaneously rather than choosing between speed and quality.
The PDCA Cycle: The Engine of Continuous Improvement
Shewhart, Deming, and the Learning Cycle
Walter Shewhart, a statistician at Bell Laboratories, developed the concept of the improvement cycle in the 1930s as part of his work on statistical process control — the use of statistical methods to monitor and control manufacturing processes. W. Edwards Deming popularized and extended it, and it became known as the Deming Cycle or PDCA (Plan-Do-Check-Act):
Plan: Define the problem, understand the current state, identify root causes, and develop a hypothesis for improvement. This is the analytical heavy lifting — the most important phase, and the one most frequently rushed. Japanese practitioners call this emphasis on the planning phase nemawashi (building consensus and shared understanding before acting), which explains why Toyota teams appear slow to start changes that then succeed dramatically once implemented.
Do: Implement the change on a small scale. The "Do" phase should be a controlled experiment, not a full rollout. Testing small preserves the ability to learn from failure without catastrophic consequences. The concept of a pilot in lean practice is not a political courtesy to skeptics — it is epistemically correct, because small-scale tests produce learning that large-scale rollouts destroy.
Check (or Study): Measure the results. Compare outcomes to the predictions from the planning phase. Did the change produce the expected improvement? What was unexpected? The "Check" phase is where organizational learning happens — and where most organizations shortcut, moving directly from Do to Act without pausing to understand what actually happened.
Act (or Adjust): If the change worked as expected, standardize it — update procedures, train people, build the improvement into the system. If it did not work as expected, iterate: revise the hypothesis and run the cycle again.
The word "cycle" is deliberate. PDCA is not a project plan — it is a learning loop. Organizations that internalize it develop a fundamentally different relationship with problems. Problems are not failures to be hidden; they are experiments waiting to happen. Every deviation from standard is an opportunity to understand the system better.
"Every system is perfectly designed to get the results it gets." — W. Edwards Deming
This aphorism captures the core insight of PDCA and operational excellence: if you want different results, change the system. Exhortations to try harder are not process improvements. When a system consistently underperforms, the responsible question is not "why aren't people trying hard enough?" but "what is the system doing that produces this result?"
A3 Thinking
A practical tool for PDCA that has spread widely from the Toyota system is the A3 report — named for the A3 paper size on which it fits. An A3 is a single-page structured problem-solving document that captures the entire PDCA cycle: current state, problem statement, root cause analysis, countermeasures, target state, implementation plan, and follow-up. Crucially, it fits on one page.
John Shook, who worked at Toyota for nearly a decade and later wrote Managing to Learn (2008), describes the A3 not as a reporting tool but as a thinking tool. The discipline of fitting the entire problem-solving process on one page forces clarity of thought and explicit statement of hypotheses. When a team cannot fit their analysis on an A3, they typically do not yet understand the problem well enough to solve it.
The Shingo Model and Culture
Beyond Tools and Techniques
The Shingo Institute at Utah State University, named for Toyota engineer Shigeo Shingo, has developed one of the most comprehensive frameworks for operational excellence — one that explicitly addresses a weakness in purely tool-based approaches.
Many organizations implement lean tools — 5S, kanban boards, value stream maps — and achieve limited, temporary improvement. The tools get installed but the thinking does not change. Within a few years, the visual management boards are ignored, the standard work documents are outdated, and the 5S program has been abandoned.
The Shingo model argues that sustainable operational excellence requires changing beliefs and principles, not just behaviors. Tools and behaviors are visible; principles and beliefs drive them. Organizations that install tools without changing underlying beliefs get "fake lean" — the appearance of improvement without the reality.
The Shingo model identifies several fundamental principles:
- Respect every individual (front-line workers are experts in their work)
- Lead with humility (leaders learn from the people doing the work)
- Seek perfection (every process can be improved; the standard is always temporary)
- Embrace scientific thinking (use PDCA; decisions are hypotheses, not commands)
- Focus on process (problems are usually system problems, not people problems)
- Think systemically (optimization of parts at the expense of the whole is not improvement)
- Create constancy of purpose (sustained improvement requires consistent leadership attention)
The last principle — constancy of purpose — was one of Deming's 14 Points, articulated in Out of the Crisis (1986). Deming argued that most organizational improvement programs fail not because they are poorly designed but because leadership attention is unstable. An improvement program that receives intense attention for two years and then recedes as leadership moves to the next priority cannot sustain the cultural change it requires.
Why Operational Excellence Programs Fail
The failure rate of lean and operational excellence programs is high. Surveys of manufacturing executives consistently suggest that fewer than 30% of lean implementations achieve their intended results on a sustained basis. Research by McKinsey & Company (2015) on organizational transformations found similar failure rates: roughly 70% of large transformation programs fail to achieve their intended objectives.
Common failure modes:
Leadership withdrawal: Senior leaders initiate improvement programs but do not personally participate in gemba walks (going to the actual workplace to observe), problem-solving sessions, or standard work reviews. The program becomes "something the quality department does." When leaders do not invest their own time in the work, the organization correctly concludes that improvement is not a genuine priority.
Tool focus without principles: Implementing 5S without changing the underlying belief that workers' judgment about workplace organization matters produces visible boards but no cultural shift. Mike Rother, in Toyota Kata (2010), argues that Western organizations imported Toyota's tools without the underlying management behaviors — the daily coaching routines, the scientific thinking habits, the problem-solving disciplines — that make the tools work. The tools are the visible surface; the kata (routines) are the substance.
Improvement without standardization: Improvements are made but not captured in updated standard work. The next person to do the job does it the old way. The improvement erodes. Toyota's emphasis on standard work is not bureaucratic rigidity — it is the mechanism by which improvements are preserved. Standard work documents the current best method; when a better method is found, the standard is updated. Without this cycle, improvements are temporary.
Punishing failure: PDCA requires experimentation, and experiments fail. Organizations that treat failed experiments as employee performance failures do not run experiments — they run theater. The psychological safety research of Amy Edmondson at Harvard Business School (1999, 2018) demonstrates that teams in psychologically safe environments report more errors, learn faster, and perform better than teams where error reporting is punished. The paradox is that teams that appear to have few problems often have many hidden ones; teams that surface many problems are usually learning more effectively.
Measuring activity instead of outcomes: Many operational excellence programs measure the number of kaizen events conducted, the percentage of 5S audits completed, or the number of people trained, rather than measuring actual performance improvement. Activity metrics do not drive improvement; outcome metrics do.
Operational Excellence Outside Manufacturing
Healthcare
The application of operational excellence principles to healthcare has produced some of the field's most striking evidence for the universality of the approach.
Virginia Mason Medical Center in Seattle began implementing the Toyota Production System in 2002 under CEO Gary Kaplan. The results over the following decade included:
- 85% reduction in the distance medical staff walked per day (eliminating non-value-adding motion)
- Significant reduction in medication errors through poka-yoke design of medication dispensing
- Reduction in surgical infection rates below national averages
- Inventory reduction that freed $11 million in capital previously tied up in excess medical supplies
- Patient wait times reduced by over 50% in multiple service lines
Virginia Mason's experience has been replicated — with similar results — by ThedaCare in Wisconsin, Intermountain Healthcare in Utah, and dozens of other health systems worldwide. John Toussaint, former CEO of ThedaCare and author of On the Mend (2010), documented ThedaCare's experience: over five years, the health system reduced costs by $27 million, improved patient outcomes measurably, and achieved staff engagement scores that improved year over year rather than declining with the workload pressure of improvement programs.
Healthcare is in many respects an ideal candidate for operational excellence: it involves complex, repeated processes; variation in practice produces wide variation in outcomes; defects (medical errors) cause serious harm; and front-line clinicians have enormous knowledge about how processes actually function. A 1999 Institute of Medicine report, To Err Is Human, estimated that medical errors caused between 44,000 and 98,000 deaths per year in the United States — a number that represents a systemic quality failure amenable to exactly the kind of systematic process improvement that operational excellence frameworks provide.
Software Development and DevOps
The Agile software development movement, which emerged in the early 2000s, is largely a translation of lean principles into software:
- Short cycles (sprints) rather than long waterfall projects = small batch sizes
- Continuous integration and deployment = rapid feedback, short cycle times
- User stories and frequent delivery = customer focus
- Retrospectives = PDCA applied to team process
- Definition of done = standard work applied to software delivery
The DevOps movement, which broke down the historical separation between software development and IT operations, draws explicitly on lean principles. The "Three Ways" described in Gene Kim, Kevin Behr, and George Spafford's The Phoenix Project (2013) map directly to lean concepts: flow (left to right across the value stream), feedback (right to left, enabling rapid learning), and continual learning and experimentation.
Dr. Nicole Forsgren, Jez Humble, and Gene Kim's 2018 book Accelerate, based on six years of research into software delivery performance, provided empirical evidence that lean-inspired DevOps practices — specifically trunk-based development, continuous delivery, and comprehensive monitoring — produced dramatically better outcomes in both software delivery speed and reliability. The highest-performing organizations in their study deployed code 46 times more frequently than low performers, with 2,555 times faster lead times for changes and 7 times lower change failure rates. The practices that drove these outcomes were operationally excellent software development.
Financial Services and Government
Banks, insurance companies, and government agencies have applied operational excellence frameworks to processes like loan origination, claims processing, and permit issuance. The waste categories translate directly: waiting times for approvals, overprocessing through redundant reviews, defects in the form of errors requiring rework.
Bank of America implemented lean across its mortgage servicing operations in the mid-2000s, reducing processing cycle times and error rates in a business where both have direct financial consequences. Insurance companies including Nationwide and Progressive have applied Six Sigma and lean methodologies to claims handling, reducing cycle time and improving accuracy simultaneously.
The City of Fort Wayne, Indiana became an often-cited case study for lean in government: applying lean tools to city services reduced process cycle times by 30-70% in several departments while improving accuracy. Ken Miller's We Don't Make Widgets (2006) documented multiple government applications of lean, arguing that the customer-value framing that underlies lean translates directly to public service: citizens are customers, and the processes government uses to deliver services are value streams full of waste.
Measuring Operational Excellence
One of the persistent challenges of operational excellence is measurement. The metrics that matter most are often not the ones that organizations naturally track. A comprehensive measurement framework for operational excellence typically includes:
| Dimension | Metric Examples | Why It Matters |
|---|---|---|
| Flow efficiency | Value-added time as percentage of total cycle time | Reveals how much of the process is actually creating value |
| Quality | First-pass yield; defects per million opportunities | Quantifies the cost of poor quality at the source |
| Delivery | On-time delivery rate; lead time | Reflects the customer experience of reliability |
| Cost | Cost of poor quality (COPQ); inventory turns | Tracks the financial impact of waste |
| Safety | Incident rates; near-miss reporting | Indicates both worker welfare and organizational learning |
| Engagement | Improvement ideas submitted per employee | Reveals whether front-line workers are engaged in improvement |
| Learning | PDCA cycles completed; problems permanently solved | Tracks whether the organization is actually improving its system |
The cost of poor quality (COPQ) deserves specific attention. First formalized by Joseph Juran in his 1951 Quality Control Handbook, COPQ captures the total cost of not doing things right the first time: rework, scrap, warranty claims, inspection costs, and customer defection due to poor quality. Juran estimated that COPQ typically represented 15-40% of total sales revenue in manufacturing — a figure that most organizations had never attempted to measure and therefore had no incentive to address. Making COPQ visible is frequently the catalyst for serious operational improvement investment.
Getting Started with Operational Excellence
For organizations beginning this journey, a few principles from the evidence:
Start with a pilot, not a rollout. Operational excellence cannot be mandated from the top and installed simultaneously across an organization. Choose a specific process, value stream, or department where leadership is genuinely committed, implement rigorously, learn from the experience, and use successes to build from. The pilot generates both learning and proof of concept; the proof of concept builds the organizational will to extend the work.
Go to the gemba. The term means "the actual place" in Japanese — the location where value-creating work happens. Leaders who understand operational excellence spend time observing work as it actually occurs, not as it is described in meetings or reports. Understanding the real process is a prerequisite for improving it. The gap between "work as imagined" and "work as done" is almost always larger than managers expect, and the gap itself is diagnostic: it reveals where standard work is absent, where training has failed, where tools are inadequate, and where the system creates workarounds that hide problems.
Focus on flow first. Before attacking variation and defects, map the value stream and identify where work waits, where bottlenecks form, and where non-value-adding steps occur. Flow improvement typically delivers faster, more visible results than statistical quality analysis and builds the organizational confidence to go deeper.
Make problems visible. Operational excellence cultures surface problems quickly; they do not hide them. Leaders who respond to visible problems with blame teach their organizations to hide problems. Leaders who respond with curiosity teach their organizations to surface them. This is one of the most important cultural interventions available, because problem visibility is the feedstock of all improvement: you cannot fix what you cannot see.
Invest in coaching, not just training. Operational excellence is a practice, not knowledge. Organizations that send teams to lean training and expect improvement are as mistaken as organizations that send managers to management training and expect better management. Mike Rother's research on Toyota's approach (Toyota Kata, 2010) found that the primary vehicle for capability development is daily coaching by immediate supervisors — brief, structured conversations about the current improvement challenge, the hypothesis being tested, and what was learned from the last experiment. This coaching routine is what builds the scientific thinking capability that sustains improvement.
Summary
Operational excellence is not a slogan or a program. It is a management philosophy with deep roots in Deming's work, the Toyota Production System, and decades of practice across industries. Its core insight — that performance problems are usually system problems, that the people doing the work are its most important experts, and that improvement is a continuous scientific process rather than a one-time event — has proven applicable wherever work is performed through repeatable processes.
The tools are learnable. The culture is harder. Organizations that sustain operational excellence do so because their leaders genuinely believe that every problem is an opportunity, that every employee's knowledge matters, and that the standard way of doing things is always a hypothesis about the best current method — not the final word.
The organizations that have most fully realized this philosophy — Toyota, Virginia Mason, ThedaCare, the best DevOps teams, and a growing list of government agencies and service businesses — share not a common toolset but a common way of seeing. They see flow. They see waste. They see the gap between current and possible. And they see that gap not as evidence of failure but as an invitation to improve.
References
- Deming, W. E. (1986). Out of the Crisis. MIT Press.
- Edmondson, A. C. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly, 44(2), 350-383.
- Edmondson, A. C. (2018). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley.
- Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
- Institute of Medicine. (1999). To Err Is Human: Building a Safer Health System. National Academies Press.
- Juran, J. M. (1951). Quality Control Handbook. McGraw-Hill.
- Kim, G., Behr, K., & Spafford, G. (2013). The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. IT Revolution Press.
- McKinsey & Company. (2015). Why do most transformations fail? A conversation with Harry Robinson. McKinsey Quarterly.
- Miller, K. (2006). We Don't Make Widgets: Overcoming the Myths That Keep Government from Radically Improving. Governing Books.
- Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
- Pande, P., Neuman, R., & Cavanagh, R. (2000). The Six Sigma Way. McGraw-Hill.
- Rother, M. (2010). Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results. McGraw-Hill.
- Shingo, S. (1986). Zero Quality Control: Source Inspection and the Poka-Yoke System. Productivity Press.
- Shook, J. (2008). Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor, and Lead. Lean Enterprise Institute.
- Toussaint, J., & Gerard, R. (2010). On the Mend: Revolutionizing Healthcare to Save Lives and Transform the Industry. Lean Enterprise Institute.
- Womack, J. P., & Jones, D. T. (1996). Lean Thinking: Banish Waste and Create Wealth in Your Corporation. Simon & Schuster.
- Womack, J. P., Jones, D. T., & Roos, D. (1990). The Machine That Changed the World. Free Press.
Frequently Asked Questions
What is operational excellence?
Operational excellence is a management philosophy and set of practices aimed at achieving superior performance through systematic process improvement, waste elimination, and a culture of continuous improvement across all functions of an organization. It draws on frameworks including the Toyota Production System, Lean manufacturing, Six Sigma, and the Shingo model. The goal is not a single improvement project but a permanent organizational capability: the ability to identify problems, analyze root causes, implement solutions, and sustain improvements reliably and repeatedly.
What is the Toyota Production System and why is it important?
The Toyota Production System (TPS) is the manufacturing philosophy and set of practices developed at Toyota Motor Corporation, primarily by Taiichi Ohno and Shigeo Shingo, from the 1950s through the 1970s. TPS introduced just-in-time production, jidoka (intelligent automation with human oversight), the concept of waste (muda) identification and elimination, and visual management systems. When James Womack and Daniel Jones studied TPS in the late 1980s, they coined the term 'lean manufacturing' to describe the approach, which became the foundation for operational excellence practices worldwide. TPS demonstrated that quality and efficiency were complementary rather than competing goals.
What is the difference between Lean and Six Sigma?
Lean focuses primarily on eliminating waste and improving flow — removing non-value-adding activities so that work moves through a process with less delay, effort, and cost. Six Sigma focuses on reducing variation and defects — using statistical methods to identify and control sources of process variability so that output quality is consistently high. Both approaches aim to improve quality and efficiency but from different angles. Many organizations use Lean Six Sigma, a combined framework that addresses both waste reduction and variance reduction simultaneously.
What is the PDCA cycle?
PDCA stands for Plan-Do-Check-Act (sometimes called Plan-Do-Study-Adjust). It is an iterative improvement cycle developed by Walter Shewhart and popularized by W. Edwards Deming. Plan: identify a problem, analyze root causes, and develop a hypothesis for improvement. Do: implement the change on a small scale. Check: measure the results and compare to the hypothesis. Act: if the change worked, standardize it; if not, begin the cycle again with revised understanding. PDCA is the structural backbone of continuous improvement — it institutionalizes learning from experiments rather than assuming large-scale changes will work as planned.
Can operational excellence work outside of manufacturing?
Yes — operational excellence frameworks have been successfully applied in healthcare (Virginia Mason Medical Center's adoption of the Toyota Production System reduced medication errors and patient wait times dramatically), financial services, logistics, software development (where Lean principles underlie the Agile and DevOps movements), and government. The core principles — eliminate waste, reduce variation, continuously improve, empower front-line problem-solvers — are universal. The translation from factory floor to office or hospital requires adapting the specific tools and language, but the underlying logic applies wherever work is performed through repeated processes.
