What are processes?

A process is a repeatable sequence of steps that turns inputs into an output somebody wants. A patient arrives, is assessed, treated and discharged. An order comes in, is picked, packed, shipped and invoiced. A complaint is logged, investigated, answered and closed. Inputs go in one end; a result comes out the other; steps happen in between.

The word "repeatable" is doing the heavy lifting. A one-off project isn't a process. But if the same kind of thing happens more than a handful of times, it *is* a process — even if nobody has written it down, and even if it happens differently every time. Especially then.

Improvement people use a five-letter sketch called SIPOC to describe any process quickly: Suppliers provide Inputs to a Process that produces Outputs for Customers. Draw those five boxes for anything you do and you have a process — and, usually, the first surprise about who your customer really is.

Most organisations assume their results come from how good their people are. Mostly they come from how good their processes are. The same capable team will deliver late in a process full of hand-offs and queues, and on time in a clean one. Blaming individuals for a process problem is the single most common management mistake I see.

Here is the maths behind that claim. A rule called Little's Law links three things every process has:

$$L=\lambda W$$

In plain words: the amount of work sitting in your process ($L$) equals how fast work arrives ($\lambda$, the Greek letter lambda) times how long each piece stays ($W$). No assumptions, no exceptions. It means that if you count the work currently in progress and divide by how much you finish per week, you get your true lead time — whatever the plan or the dashboard claims. Delay is not a mystery. It is work-in-progress divided by throughput.

Processes don't usually break. They erode. A workaround gets invented for a problem that was never fixed, and becomes the normal way. A spreadsheet fills the gap between two systems, and becomes the system. A hand-off between two teams turns into a three-day wait that everyone plans around. Nobody decided any of it. It accreted.

Two forces do most of the damage. The first is *variation*: the same step taking wildly different times or giving different results on different days. The second is *utilisation pushed too high*: keeping everyone flat-out sounds efficient, but queueing maths says waiting time grows roughly like $\frac{\rho }{1-\rho }$, where $\rho$ (rho) is how busy a resource is. At 80% busy that factor is 4; at 95% it's 19. A team run at 95% doesn't wait a little longer — it waits about five times longer than one at 80%. Busy-ness and speed are not the same thing; past a point they are opposites.

You cannot improve a process you haven't seen — and the procedure manual is not the process. The only reliable way to see one is to walk it: follow one piece of work from start to finish, with the people who do it, noting where it moves and where it waits.

The tool for writing down what you find is a value stream map. It draws the steps in a line, and beneath them a timeline ladder with two levels: the minutes of actual work on the top step, the days of waiting on the bottom. Almost every first map shows the same shocking shape — a few hours of work spread across a few weeks of waiting. Ratios of 1 hour of work to 20 hours of elapsed time are ordinary.

Three numbers to collect on the walk: touch time versus elapsed time, first-time-right rate (how much work gets through without correction), and the cost of one week's delay. Those three turn "we're a bit slow" into a business case.

Process thinking has a failure mode of its own. Not everything repeatable should be standardised into a rigid script — judgement, care and creativity need room, and a process that removes it produces compliant, hollow work. The test is not "can we standardise this?" but "does variation here hurt the customer, or serve them?" A nurse's judgement at the bedside is variation worth protecting. A drug-dosing calculation done six different ways is not.

The other trap is the perfectly documented process that nobody follows. A process exists in what people actually do, not in the document. If the document and the floor disagree, the floor is the process and the document is fiction — and improvement starts from the floor.

Get the definition straight, walk the real thing, measure the three numbers, and respect the variation that matters. That's the whole of process thinking, and it is enough to change most organisations.