Business process management

Why it matters

Most of the problems owners complain about are process problems wearing a disguise. Late invoices, missed follow-ups, jobs that run over, customers who call twice about the same thing: each one traces back to a step nobody owns, a hand-off that leaks information, or work that is done differently each time. Fixing the process fixes the symptom permanently, and it is usually cheaper than hiring another person to absorb the chaos.

What a process actually is

A process is a repeatable sequence of steps that turns an input into an output a customer or colleague values. "Customer enquiry" goes in one end; "accepted quote" comes out the other. Processes have a trigger (what starts them), an owner (who is accountable for the result), steps, hand-offs between people or systems, and an end state you can recognise.

It helps to think in layers. At the top sit a handful of core processes every business shares: win work, deliver work, get paid, and support everything else. Each core process breaks down into sub-processes, and each of those into tasks. You do not need to document the whole pyramid. Start at the level where the pain is.

Map the current state honestly

The first and most valuable step is to map a process as it really runs, not as you wish it ran. Get the people who do the work in a room, pick one real example from last week, and follow it from trigger to finish. Write each step on a sticky note or in a simple flowchart tool. Mark who does it, how long it waits before the next step, and where things typically go wrong.

Owners are usually surprised by what appears. A "simple" invoice might touch four people, sit in an inbox for three days, and be retyped twice. The map does not need to be pretty. It needs to be true, because every improvement decision rests on it.

• Follow a real, recent example rather than describing the ideal.
• Record elapsed time (how long the step waits) separately from work time (how long it takes to do).
• Mark every hand-off between people or systems: that is where information is lost.
• Note the workarounds people use; they reveal where the official process fails.

Measure before you change anything

A process you cannot measure, you cannot improve with confidence. The useful measures are few: how long the process takes end to end (cycle time), how much of that is waiting, how often the output needs rework or correction, and what it costs in labour hours. Take a baseline over two or three weeks before you touch anything, so you know whether a change actually helped.

Measurement does not have to be sophisticated. A tally sheet, a timestamp column in a spreadsheet, or the dates already sitting in your job management or accounting software are enough to start.

Prioritise improvements by impact and effort

Once the map and the numbers are in front of you, the problems tend to be obvious and there will be more of them than you can fix at once. Sort them on two axes: how much they cost you in time, money or customer goodwill, and how hard they are to fix. Quick wins (high impact, low effort) go first and build momentum. Big projects (high impact, high effort) get planned. Low-impact items are left alone, no matter how annoying.

Typical quick wins include removing an approval step nobody reads, moving a form online so data is entered once, agreeing a single place where job information lives, and giving one person clear ownership of the hand-off that keeps leaking. Software and automation come later, once the process is stable enough to be worth automating; automating a messy process just produces mess faster.

How to start managing your processes

1. List your core processes Write down the ten or so processes that make up win work, deliver work, get paid and run the business.
2. Pick the one that hurts most Choose by cost, customer complaints or owner frustration. One at a time.
3. Map it with the people who do it Follow a real recent example from trigger to finish and record every step and hand-off.
4. Measure a baseline Cycle time, waiting time, rework rate and labour hours over two to three weeks.
5. Choose one or two improvements Favour quick wins: remove, combine or clarify steps before adding technology.
6. Test, then standardise Run the new version for a month, compare the numbers, then write it up as the standard.
7. Assign an owner and a review date Every process needs one accountable person and a date to check it still works.

Real-world example

A Newcastle plumbing business fixes job-to-invoice

Reid Plumbing has five tradespeople and an office manager. Invoices routinely go out ten to fourteen days after a job is finished, and about one in six comes back with a query because the parts or hours are wrong. The owner maps the process with the team: the tradie writes the job on a paper docket, drops it at the office on Friday, the office manager types it into the accounting system the following week, and calls the tradie if anything is unclear.

The map shows three hand-offs and an average of nine days of waiting. They make two changes: tradies complete the job record in the existing job management app before leaving site, and the office manager invoices daily from the app instead of weekly from paper. After a month, invoices go out in an average of two days, queries fall to about one in twenty, and the business is paid roughly a week earlier, which eases its cash flow without a single new customer.

Common mistakes

• Mapping the ideal instead of the real A flowchart of how things should work hides the workarounds and delays that are costing you. Always follow a real example.
• Buying software first Automating a process you have not simplified locks the mess in place. Fix the process, then automate the stable version.
• Trying to fix everything at once Teams can absorb one or two changes a month. Ten changes at once means none of them stick.
• No process owner If nobody is accountable for the outcome, the process drifts back to old habits within weeks.
• Measuring nothing Without a baseline you cannot tell improvement from noise, and you cannot defend the change when someone wants to go back.

KPIs to track

• Cycle time Elapsed time from trigger to finished output. Track it per process and aim to shorten it steadily.
• Waiting ratio Share of cycle time spent waiting rather than working. In unmanaged processes it is often most of the total.
• Rework rate Percentage of outputs that need correction. Falling rework is the clearest sign a process is improving.
• Labour hours per unit Hours spent per job, order or invoice. Compare before and after each change.
• Processes with a named owner Simple but telling: how many of your core processes have one accountable person and a documented standard.

Frequently asked questions

Is BPM only for big companies?

No. Large companies have whole departments for it, but the underlying habit of mapping, measuring and improving works for a two-person business. The smaller you are, the faster changes take effect.

Do I need special software to map processes?

Not to start. Sticky notes, a whiteboard or a free diagramming tool are enough. Software becomes useful when you have many processes to keep current and several people who need to see them.

How is this different from writing SOPs?

An SOP documents how to do one procedure correctly. Process management is the wider discipline of deciding which processes matter, measuring them and improving them. SOPs are usually the output of the standardise step.

How often should processes be reviewed?

Set a review date when you standardise, typically six to twelve months out, and review sooner whenever volume, staff or systems change significantly.

Key takeaways

• Every recurring problem in a business is usually a process problem; fix the process and the symptom goes away for good.
• Map processes as they really run, with the people who run them, using a real recent example.
• Measure a baseline before changing anything so you can prove the improvement.
• Prioritise by impact and effort and change one or two things at a time.
• Simplify before you automate, and give every process a named owner and a review date.