I’ve spent a considerable part of my career working with systematic approaches to Operational Excellence: Lean, Six Sigma, DMAIC, Value Stream Mapping, root cause analysis, statistical methods, Kaizen, the whole daunting arsenal of tools and techniques. They’re all valuable. I’ve used them, taught them, seen them deliver real, serious, powerful improvements. I’ve also watched organisations awash in these tools get nothing out of them, and struggle to sustain a single improvement.
It’s not that the firms don’t struggle bravely. Indeed they do. They train their Green Belts and Black Belts with genuine rigour. They map their processes, calculate their capability, hold their Kaizen events, enter the ring of productivity like true prize fighters. Sometimes they even toss a knockout blow, and point to savings or improved run times with real numbers attached. The outcomes are serious and genuine.
And yet, nonetheless, slowly and quietly, after the celebratory spotlight, the same operational problems keep returning. Customer issues repeat. Processes drift back to where they started. Workarounds reappear like the weeds they are. Functions go on optimising in their own private universes.
Improvements erode a little at a time till they can no longer be ignored. Eventually somebody launches another project to solve, again, a problem the firm thought it had already solved.
Why? I came to understand that achieving Operational Excellence was not a matter of applying popular tools to isolated problems looking for a quick fix. It ran deeper. In fact, OpEx is a management system. A comprehensive platform addressing how an organisation continuously runs, improves and learns.
The tools matter. They matter enormously! They’re just not the system, any more than a stethoscope is a hospital, or medical science as a whole.
Tools Solve Immediate Problems. Systems Solve the Factors That Give Rise to Them.
Suppose a team has a recurring service problem. A properly structured improvement project can analyse it beautifully. It can map the process, gather the data, isolate the root causes, design the countermeasures, implement, measure. It may not only analyse the problem, it may even actually solve it. Everyone is happy. Bonuses abound.
But what happens six months later?
Once the project team has bagged its prey, they scatter to other assignments. Yes, they leave the process much improved, but who owns the improved process once the project team has moved on? Who maintains it? Which measures show that performance is drifting? Who responds when it does? Does anyone respond? What behaviour is now expected of the people running the process day to day?
Getting better is one thing. Staying better is quite another. Seeing how improvements in one area affect all the others is still another. Does the improved process have any impact at all on customer experience, for instance, or is it only an internal improvement? Does it genuinely lead to more sales, or greater profitability? A better product or process ought to lead to greater quarterly profits. But sometimes it doesn’t.
When questions like these aren’t even raised, much less addressed, the organisation has very likely completed an excellent project without building a stronger operating system. It’s made improvement a one-time event, not an ongoing, thoroughgoing, comprehensive way of addressing all problems. Excellence isn’t a matter of staggering from one problem to the next, even if one manages to resolve them for a while. It has to become a systematic way of managing. That may be a rather less photogenic ambition, but it’s a considerably more durable one.
An Observation From Practice
Don’t imagine that I lack respect for improvement teams that fix critical issues. Far from it! I’ve seen such teams deliver results that were genuinely impressive by any measure. Lead times cut, inventory reduced, yield improved, complaints down, capacity freed, processes simplified. Outcomes tangible and real, not mealy-mouthed consultant arithmetic. Bravo! It’s quite right to undertake such efforts, and right to celebrate them when they succeed.
But, every time, I’ve watched such project teams move on, as project teams do. The sponsor’s attention drifts away to whatever new crisis replaces this one. No one actually decides to reverse a single thing! Yet somehow a kind of corporate gravity pulls things back down, and the process wanders back to where it started.
In some ways, it’s a very human process. We need to lose ten pounds, so we diet and exercise, and, sure enough, we lose ten pounds! Then we go back into our former poor eating habits, and six months later those ten pounds are back. Despite our flow charts and AI analyses, corporations are still humanity writ large, and will be so long as businesses are still made up of human beings. So they reflect our inclinations. We make changes, but don’t put supports and management systems in place to protect our gains; and gravity does the rest. Eventually somebody notices performance sliding, and another expensive, time-consuming initiative is launched to rediscover what the last one had already found.
But sometimes important changes are sustained. What’s the difference in such cases? The business that keeps its gains realises an improved process doesn’t automatically sustain improvement. They know that improvement is sustained because the organisation changed how that process is managed. Instruments and activities were put in place to sustain it. The real challenge is stretching those efforts and that instinct across the whole enterprise, long after the project charter has been archived and forgotten.
Operational Excellence Should Live in the Line
Where does responsibility for improvement actually sit? Paradoxically, if improvement belongs primarily to the OpEx team, something is structurally wrong.
The OpEx team should facilitate, coach, train, provide methodology, challenge lazy thinking, bring specialist analytical firepower to the genuinely hard problems, and build capability across the organisation.
But the actual line, the plant manager, the supply-chain leader, the customer-service leader, the commercial leader, the process owner, the functional executive, should own performance. And therefore own improvement too. Operational Excellence is not like pizza delivery. You can’t order it over the phone and wait for it to just arrive. Business personnel should not be consumers of Operational Excellence. They should be practitioners of it.
That doesn’t mean every soul on the line needs to become a Black Belt. It does mean that they need to see performance clearly, identify gaps, tell signal from noise, solve problems methodically, manage standards, make decisions on evidence rather than instinct, develop their people’s capability, and keep improving the system they’re actually accountable for. They need to be shown and trained to do that, and to do it consistently. Operational Excellence shouldn’t be a department down the hall. It needs to become part of what management is.
The Daily Management System Matters More Than the Improvement Event
Large improvement programmes attract attention the way fireworks do: brightly, brilliantly and not for very long. Much of real Operational Excellence, by contrast, is unglamorous. It requires repeated management disciplines. Where did performance diverge from expectation? Why? Is this ordinary variation or a genuine signal? What needs to be done? By when? What did we learn, and has the standard changed as a result? Does the same problem exist somewhere else we haven’t yet looked?
Asked consistently enough, these unremarkable questions build an extraordinarily strong culture. That’s why visual performance boards, tiered accountability, clear ownership and structured problem solving work. That’s why regular review matters much more than its plodding reputation suggests. All these connect strategy to what actually happens on an ordinary Tuesday. Without such a connection to ordinary performance, improvement becomes halting and episodic. The organisation gets better while a project is actively running, then reverts to managing by fire brigade the moment the project team leaves the building. The goal should be to close the distance between running the business and improving it, until eventually the two are the same activity.
Standards Are the Foundation for Improvement
Continuous improvement can sound (mistakenly) like everything ought to be constantly in flux. It shouldn’t be. In fact, improvement requires stability: you can’t meaningfully recognise deviation from a standard you never bothered to define. A standard isn’t an instruction manual for dealing with every conceivable circumstance a process might encounter. It’s simply a clear statement of the current best-known way of doing something important.
Once that exists, and when you see performance diverge from expectation, you can ask why with precision. When somebody finds a demonstrably better method, the standard can be updated. Process drift becomes visible instead of invisible. When people change roles, the knowledge stays behind, rather than walking out the door with them.
Without a standard, innovation becomes indistinguishable from variation, and both get treated as though they’re the same thing. Which they most emphatically are not! Standardisation and improvement are not opposites: standardisation simply gives improvement somewhere to start from. Not that the standard itself should be treated as sacred. It isn’t. It only represents the best we know today; and today doesn’t last.
Operational Excellence Begins With Seeing Reality
There is something I value above almost any tool in the armoury, and that is the plain discipline of finding out what is actually happening. Not what the procedure claims, not what the dashboard implies, not what leadership wants to believe. What actually happens.
Follow the process. Talk to the people doing the work, not just their manager’s summary of what they do. Watch the handoffs. Understand the exceptions. Notice where people wait, where approvals pile up like unopened mail, where employees have invented their own private workarounds because the official process simply doesn’t work, where the customer is hit with the consequences, and how he or she responds.
It never fails to amaze me how remarkably sophisticated organisations become at massaging and managing representations of reality: the dashboards, reports, presentations, status indicators, all of them at several removes from reality, rather than reality itself. AI-generated summaries only make such representations easier to produce, more convincing and more destructive. That’s why simple, disciplined, direct observation matters more, not less.
Go and see! Data tells us a lot. Reality tells us a lot more.
Problem Solving Is a Management Capability
Let us praise Lean Six Sigma. Among the most valuable gifts it gave organisations was structured problem solving. Define the problem, measure what’s actually happening, analyse the evidence, understand the causes, make deliberate improvements, control the result. That discipline mattered because human beings are predictably human: we are constitutionally impatient, we recognise something, think we know what it means, form a hypothesis on the spot, and go with it. Sometimes we’re right! Often we’re not.
A mature system changes such instinctive responses. Instead of asking, Who caused this? (a question that produces defensiveness and fingers pointing at others), ask What caused this? What evidence do we have that that’s the true cause? Instead of saying, Get someone to fix it, rather ask How can we tell if the fix is real and not only superficial? How can we be sure it stays fixed?
That is not an old methodology dressed up in new language. It’s a different way of managing, full stop.
Not Every Problem Needs a Six Sigma Project
Let’s face it: Operational Excellence can become far too complicated for its own good. Not every problem needs DMAIC. Not every process needs a Value Stream Map. Not every improvement needs a project charter with a fully staffed kickoff meeting complete with catering.
Sometimes the cause really is obvious. Fine, fix it, move on with your day. Sometimes a small, cheap, quick-and-dirty experiment will tell you everything a six-month project would have told you at a hundred times the cost. Sometimes the standard simply isn’t being followed, with no negative impact at all. At times like that, the question shouldn’t be how to completely redesign things, but why bother? Sometimes the correct intervention for an obsolete process is to kill it, not improve it.
The method should always be proportional to the problem. Worthy as Lean Six Sigma and its brethren are, they all have a tendency to announce their sophistication by reaching for ever more complexity and ever more tools. But a genuinely world-class Operational Excellence system provides value, and demonstrates maturity, by doing the minimum required to actually solve the problem. Do you want a system that works fast and effectively, that is literally lean, or one that only looks impressive?
Operational Excellence Must Connect to Strategy
There’s another trap worth naming. Many an organisation can become very good at improving things that just don’t matter very much. Teams can quickly build a thick portfolio of easy successful projects that don’t, by themselves, produce much strategic impact at all. Manufacturing efficiency can improve while customer lead times stay exactly where they were. Cost may be cut in one place while product quality falls with it, and returns and complaints rise.
Operational Excellence needs to focus on the bottom line: business advantage. Which business outcomes actually matter? Where does genuine value lie, and where is it being lost? Which capabilities matter, and which are merely comfortable to work on? Improvement activity should connect to these questions clearly and explicitly.
Organisations can risk becoming remarkably efficient at improving all the wrong things. A very dangerous kind of failure, because, from the dashboard, it looks exactly like success.
Local Optimisation Is Not Operational Excellence
Which is one reason systems thinking earns its keep.
Suppose Procurement lowers unit cost by ordering in larger quantities. Procurement’s metric improves handsomely. Everyone else’s plunges. Inventory climbs. Warehouse capacity tightens. Obsolescence risk rises. Cash deteriorates. The enterprise, as a whole, has not improved one jot. It’s simply shuffled the cost to somewhere less visible, and called it a win.
It isn’t a win.
Operational Excellence has to look past the boundary of the function doing the reporting. Because the purpose of optimisation is never to optimise every part individually, but to improve the performance of the system those parts together make up, to improve the efficiency and profitability of the business as a whole, even when it means that one part takes a small step back for the whole to perform better. Of course, that’s a tough trade to sustain when the measures rewarding people remain stubbornly functional. Which is exactly why Operational Excellence has to become a leadership and operating-model conversation, rather than a purely technical one.
Customer Experience Belongs Inside Operational Excellence
I don’t like separating Customer Experience and Operational Excellence into two tidy boxes. It’s a mistake. Customers experience operations directly. They experience whether the product was available on time, whether the order was accurate, whether the invoice was correct, whether the issue actually got resolved. In short: whether the company’s promise was kept, and whether the customer can trust them enough to give them loyalty, and return.
A process can be internally efficient and still deliver a thoroughly poor customer outcome. Sure, an organisation can paper over mediocre processes with heroic frontline recovery. But that’s not excellence; not even excellence’s understudy. The only question is whether the operating system reliably delivers the customer outcome intended, at a level of performance the business can actually sustain economically. A business that fails customers drives them away, and without enough customers, that business dies. That’s why Customer Experience and Operational Excellence belong in the same room, and the same conversation.
Governance Is Part of Operational Excellence
Every process eventually meets an exception. Two objectives conflict, a decision exceeds someone’s authority, resources need reallocating on short notice. Something. At that point, process design alone runs out of road. The organisation needs governance: someone has to make the call. Who decides? Against what criteria, using what evidence, how quickly? And where does the decision get recorded, so the next person doesn’t have to relitigate it from scratch?
Operational Excellence can’t stop at process optimisation. It has to connect process and performance to decision rights, accountability and governance, and turn them into a single fabric. That’s what turns improvement from a series of good projects into an execution system.
Leadership Behaviour Determines Whether Operational Excellence Survives
Leaders can say Operational Excellence matters as often and as loudly as they like. Employees, being no fools, watch what leaders actually do. When performance deteriorates, do leaders ask for evidence, or do they only pound the desk and demand a solution by Friday? When somebody surfaces an inconvenient problem, are they thanked for it or quietly resented and relocated? When finding the root cause of a problem genuinely takes time, is the team allowed to take that time, or are they hurried into a guess? When an improvement conflicts with a senior leader’s personal preference, which one wins?
Small moments like these, repeated over and over, decide whether Operational Excellence is genuinely part of management or just a slogan on the wall. People learn astonishingly quickly which behaviour actually gets rewarded. Reward firefighting, with fanfare or not, and the organisation will manufacture firefighters in abundance.
Management gets more of what it genuinely supports and values. Reward problem solving, learning and prevention, and your people will invest their best efforts and their considerable ingenuity there. That can be transformative.
Improvement Should Create Organisational Knowledge
Every serious improvement generates knowledge worth keeping: what caused the problem, which assumptions turned out to be wrong, which intervention actually worked and which merely looked promising, what changed. Another site elsewhere in the business could learn from that. Too often that knowledge lives and dies inside the project, slowly becoming a fading memory in the handful of people who were actually there. Another team meets a nearly identical problem eighteen months later and begins from zero, having to reinvent the same wheel.
A mature system converts improvement into memory rather than forgetfulness. Not every lesson needs to graduate into a formal standard, but useful knowledge should at least be discoverable by those who weren’t in the room when it was learned. That’s how continuous improvement compounds rather than decays.
AI Could Significantly Change Operational Excellence
AI, used well, could genuinely democratise sophisticated problem solving. It can chew through enormous volumes of process data, spot patterns and anomalies, synthesise customer feedback at a scale no analyst ever could, support root cause hypotheses, surface similar historical problems, generate scenarios, help teams find methods and organisational knowledge that would otherwise stay buried, and watch for emerging drift long before a human notices.
But (and there is always a ‘but’ with AI), there is a real risk running alongside that promise. AI can produce a plausible root cause without ever proving it. It can generate a recommendation with no grasp of operational context whatsoever. Worst of all, it can automate a process that should have been abolished rather than accelerated, making a poorly designed routine run faster without making it any less poorly designed. AI is a Swiss Army knife that can easily cut off all your fingers.
That’s precisely why the traditional disciplines become more valuable, not less. As I said, use your own eyes, go and see, investigate the evidence directly, validate causes, test solutions, measure outcomes. AI can accelerate all of that considerably. It shouldn’t ever be allowed to replace any of it.
The Real Test Is What Happens Between Projects
How mature is an Operational Excellence function? There’s a simple way I’d assess it, and it doesn’t start with how many people have been trained, how many projects are currently active, or how much benefit the programme claims on its scorecard. Those numbers are useful, certainly. As useful as they’re easy to inflate. But there’s an easier way to find out how things are going.
Here it is. Just ask! With no one from the OpEx team around and no C-level executive at my elbow, I’d casually sit down in the company cafeteria with an ordinary manager and ask how he or she handles an ordinary performance problem on any ordinary Tuesday morning. Do they spot any problems early? Do they understand the standard well enough to notice a deviation from it? Can they tell signal from noise without being told? If something is off, do they implement a genuine countermeasure, verify it worked, mention it and capture what was learned for the next person? That tells me more about institutionalisation than any dashboard ever will.
A Question Worth Asking
If the Operational Excellence team vanished tomorrow, what would actually happen?
Would improvement simply stop? Would the quality of problem solving deteriorate? Would governance quietly vanish? Would managers keep using evidence, or revert to instinct within a fortnight? Would customer failures still trigger a genuine root cause investigation rather than a shrug and a workaround?
If the honest answer is no, the organisation has built an excellent Operational Excellence function. It has not yet built an Operational Excellence management system.
But it’s on its way.
Executive Reflection
When assessing Operational Excellence, I would ask whether improvement is genuinely owned by the line, whether daily management exposes performance gaps quickly enough to matter, whether standards are actually clear, whether problems are solved at root cause or merely at the symptom. Is the method proportional to the problem in front of it, and does improvement connect visibly to strategy? Customer impact should be visible in the numbers we actually see. Leaders, department heads, managers and sub-managers, need to reinforce, in their own behaviour, the things they say they want. For Operational Excellence is a matter of optimising the enterprise, not merely a collection of functions that happen to share a building.
And perhaps the most telling question of all: would the organisation keep getting better if the Operational Excellence programme stopped driving it to? That, more than any scorecard, is the maturity test.
Operational Excellence Should Eventually Become Less Visible
When Operational Excellence is new, it needs visibility: a programme, a team, training, branding, projects, governance, leadership sponsorship shouting from the rooftop. All of that generates the momentum a new initiative genuinely needs.
But as the organisation matures, Operational Excellence should become steadily less distinguishable. It should simply become good standard management. Problem solving should simply become the way problems get solved. Continuous Improvement should just become continuous, without the capital letters. Why do we have standards at all? Because that’s how work is ordered and evaluated, not because the auditor is coming. Leaders learn to ask better questions because asking good questions is simply part of what leadership is. At that point, Operational Excellence has outgrown the toolkit mentality entirely. It’s become the norm: the organisation’s operating system, indistinguishable from the way the place actually runs.
Continue the Conversation
People ask me: “Which Operational Excellence tools should we deploy?”
I’m happy to discuss the tools. There are some very good ones! But first I want to know exactly what is the management system you want those tools to strengthen? What is the context in which those tools will be operating? How will leadership and management know, with confidence, that the organisation is genuinely becoming better at improving itself?
Operational Excellence is not a toolkit. It’s a management system for continuously turning performance gaps across the board into better ways of working. A better way of building organisational capabilities that outlast whoever happened to build them.
A toolkit can help an organisation solve a great many individual problems one at a time. OpEx has such tools, and it can use them effectively to do just that. But it can do much, much more, and it is much more. It’s a management system that changes how the organisation responds to problems in the first place. It’s the difference between doing Operational Excellence and becoming an organisation capable of excellence.
James Amoah
Executive Observation #025
Operational Excellence
Executive Observations are practical reflections from more than twenty-five years of leading and supporting operational, supply chain and business improvement. They explore the connections between reliable execution, leadership, operational excellence and customer experience — and what those connections mean for those endeavouring to make their businesses better, stronger, more profitable leaders in their field.
