Ask a business owner what’s broken and you’ll usually get one of two answers: “our process is a mess” or “we need a new system.” Half the time, they’ve got it backwards. The process is fine — the steps make sense on paper — but the system around it makes those steps impossible to follow consistently. Or the reverse: leadership invests in a shiny new system (new software, a reorganisation, a fresh reporting structure) while the actual sequence of steps someone follows to fulfil an order or close a hire never gets examined, and the new system just runs the same broken workflow a little faster.
The words get used interchangeably in most conversations, and that’s the problem. They’re not the same thing, and treating them as synonyms is why a lot of “fixes” don’t actually fix anything.
What a process actually is
A process is specific. It’s a defined, repeatable sequence of steps that turns an input into an output — a customer inquiry into a signed contract, a job application into a hire, a raw material into a finished product. You can draw it as a flowchart. It has a start, an end, and a set of decision points in between. When someone says “our onboarding process takes three weeks,” they’re describing something bounded and traceable: step one happens, then step two, then a handoff, then a delay, then step three.
Processes are where most operational complaints actually live, because they’re visible. You can watch a process fail. You can point to the exact step where the delay happens.
What a system is — and why it’s harder to see
A system is the larger structure that determines whether any given process can actually perform the way it’s designed to. It includes the people running the process, the incentives that shape their behaviour, the tools and information they have access to, the feedback loops that tell them whether they’re doing well, and the way authority and accountability are distributed around them. Peter Senge’s work on systems thinking — the discipline he built much of The Fifth Discipline around — makes a point that’s easy to nod along to and hard to actually apply: components don’t fail in isolation. A process breaks down not because the steps were wrong, but because the system around it — the incentives, the information flow, the feedback loop that should have caught the problem — didn’t support it.
This is the part that’s genuinely hard to see from inside a business, because a system doesn’t show up on an org chart the way a process shows up on a flowchart. It’s the space between the boxes.
That’s almost literally the argument Geary Rummler and Alan Brache made in Improving Performance: How to Manage the White Space on the Organization Chart — still one of the more useful frameworks for this distinction, decades on. They argued performance has to be examined at three levels at once: the organisation level (strategy, structure, major functions), the process level (the actual workflows that cross those functions), and the job or performer level (the individuals doing the work). Most org charts are drawn around the first and third — departments and people — and say almost nothing about the second. Processes cut horizontally across departmental boxes; org charts are drawn vertically, by function. The “white space” is what falls between the boxes — the handoffs, the accountability gaps, the points where a process moves from one department’s ownership to another’s and nobody’s quite sure who owns the outcome. Fix the individual boxes and the white space stays broken.
That’s a reasonably clean way to hold the distinction: a process is what happens inside and across the boxes. A system is the boxes, the white space between them, and the rules — spoken and unspoken — that govern how work actually moves through both.
[ Read More: Process and System Design Services ]
Why blaming the process (or the person) usually misses the point
There’s a line commonly attributed to W. Edwards Deming — “a bad system will beat a good person every time” — that gets quoted often enough that it’s worth a caveat before using it: the wording traces back to notes from a 1993 seminar, not a published text, and Deming reportedly phrased the idea somewhat differently across different talks over the years. So treat the exact sentence as approximate. But the underlying point holds regardless of which version you use, and it’s the one worth keeping: put a capable person into a system with bad incentives, no feedback loop, and unclear accountability, and they will produce the system’s output, not their own potential. Swap in a different capable person and you’ll get the same broken outcome, because the constraint was never the individual.
This is the mistake behind a lot of failed “process fixes.” A business notices late deliveries, rewrites the SOP for the fulfilment process, trains the team on the new steps — and three months later, deliveries are late again. Not because the new process was badly designed, but because nothing about the system changed: the same person is still juggling five roles because the org never assigned clear ownership of fulfilment, the same lack of a feedback loop means nobody notices a bottleneck until a customer complains, the same incentive structure still rewards speed of intake over accuracy of handoff. The process document changed. The system that process sits inside didn’t.
The reverse mistake is just as common, and arguably more expensive: a business restructures — new reporting lines, a new department, new software — without ever examining whether the specific process steps inside that new structure actually make sense. This is where a lot of ERP and CRM rollouts go quietly wrong. The system gets rebuilt around a process that was never actually mapped, just assumed, and the new software ends up digitising the same confusion it was meant to replace — just with better formatting.
Why the distinction matters for how you approach fixing either one
Practically, this means process design and system design are two different exercises that have to happen together, not one after the other and not in isolation. Process design asks: what are the actual steps, in what order, with what handoffs, and where are the decision points? System design asks a different question: given the incentives, the accountability structure, and the feedback mechanisms this business actually has, will people be able to follow that process consistently — and will anyone notice when they can’t?
Skip the system question and you get a well-drawn flowchart that nobody follows past week two. Skip the process question and you get a well-intentioned reorg running the same undocumented, inconsistent workflow it always had, just under a new set of job titles.
This is, in practice, a lot of what process and system design work actually involves — not handing a business a new flowchart or a new org chart in isolation, but working through both together: mapping how work actually moves today, finding where the white space is swallowing accountability, and then redesigning the process and the structure around it as one connected piece rather than two separate projects. It’s slower than either fix alone. It’s also the difference between a change that holds and one that quietly reverts within a quarter.
[ Read More: Brand Management Services: Build a Strong, Clear, and Consistent Brand ]
If you’re looking at a recurring operational problem right now, it’s worth asking which of the two you’re actually dealing with before you commit to a fix. A process that keeps breaking under a stable system is a process problem. A process that keeps breaking under a shifting, unclear, or misaligned system is a system problem wearing a process disguise — and no amount of SOP rewriting will fix it until the system underneath it gets addressed too.
