Process management is the practice of defining, measuring and improving the repeatable work a business does. It covers the whole life of a process: mapping how work actually flows today, agreeing how it should flow, measuring it against that standard, and changing it when the numbers say so. It is not a document. A managed process has an owner, a measure and a review date.

What process management actually involves

Most teams already have processes. What they usually lack is management of them. The difference shows up in four activities that have to keep happening, not happen once.

  • Map what happens now. Not the version in the handbook. The version where someone re-types an order into a second system because the integration broke in 2023.
  • Define the standard. What good looks like, who owns it, and what the process is supposed to produce.
  • Measure the gap. Cycle time, error rate, rework, cost per run, and how often it needs a human to unstick it.
  • Change it and re-measure. An improvement that is never verified is a guess.
Colleagues reviewing a workflow together at a desk
Map the process before automating it. Automating an unmanaged process just produces the wrong output faster.

Process management and business process automation are not the same thing

They are often sold together, which causes expensive mistakes. Process management decides what the work should be. Automation decides how much of it a machine does. Automating a process you have not managed makes a bad process run faster and produce more of the wrong output.

The order matters. Map first, fix the obvious, then automate what survives. Every technology audit we run finds at least one workflow where the answer is to delete steps rather than to automate them.

How to tell a process is worth managing

Not every task deserves this attention. A process earns it when it meets most of these tests.

  • It runs at least weekly.
  • It crosses more than one person or one system.
  • Its output feeds something else, so a failure spreads.
  • People have built private workarounds for it, usually in a spreadsheet.
  • You cannot answer how long it takes without asking someone.

That last one is the strongest signal. If nobody can state the cycle time, the process is not being managed, whatever the documentation says.

Analyst reviewing operational metrics on a laptop
Cycle time, touches, rework rate and wait time. Wait time is usually the majority and the cheapest to fix.

What to measure first

Start with four numbers, because they are the ones that convert into money and are hard to argue with.

  1. Cycle time. Request to finished, in elapsed hours, not touch time.
  2. Touches. How many people handle one run.
  3. Rework rate. The share of runs that go back a step.
  4. Wait time. How much of the cycle is a queue rather than work. In most back office processes this is the majority, and it is the cheapest thing to fix.

Where teams get stuck

The common failure is mapping the process to a level of detail nobody will maintain. A fifty step diagram is an artefact, not a management tool. Map to the level where you can see the handoffs, because handoffs are where the wait time and the errors live.

The second failure is measuring what is easy rather than what matters. Ticket counts are easy. Cycle time and rework are the ones that tell you whether the process is getting better.

A reasonable starting point

Pick the process your team complains about most, spend a week measuring it honestly, and price the gap. That number decides whether the fix is worth funding, and it is usually larger than people expect. Our IT audit does exactly this across a business and returns a written verdict in four weeks. Once a process is understood and stable, automation is the cheap part.