“BPM” is three different things, and articles on this subject routinely mix them up. Business Process Management is designing and improving how work flows. Business Process Monitoring is watching those processes run and noticing when they go wrong. Business Performance Management is tracking whether the organisation is hitting its targets. This page is about the second, and the distinction matters because they need different tools and answer different questions.
Monitoring answers one question well
Is the work actually completing, at the pace and quality it should?
That sounds obvious until you notice how many organisations cannot answer it without asking someone. Applications sit unprocessed because a step has no owner. Orders stall between two systems that each believe the other has them. A weekly report shows a healthy total while a fifth of cases quietly took four times as long as the rest. Monitoring exists to surface those before a customer does.
What is worth measuring
| Measure | What it tells you |
|---|---|
| Cycle time | How long a case takes end to end. Track the spread, not just the average |
| Throughput | How many complete per period, against how many arrive |
| Work in progress | How much is open at once. Rising WIP with flat throughput is a queue forming |
| Error and rework rate | How often a case goes backwards. Usually the largest hidden cost |
| Wait versus work time | The split between being worked on and sitting still |
| Exception volume | How often the process is bypassed — the strongest signal it does not fit reality |
Two of those repay attention disproportionately. Wait versus work time is where nearly all the delay lives: in most processes the actual work occupies a small fraction of the elapsed time and the rest is queuing. Cutting effort makes little difference; cutting waiting transforms the number.
Exception volume is the honest one. When people routinely go around the official process, the process is wrong, not the people. That signal is usually available and almost never looked at.
Averages hide the problem
An average cycle time is the most reassuring and least useful number available. If most cases complete in two days and a tenth take three weeks, the average looks acceptable while the tenth generates every complaint you receive.
Look at the distribution instead. Track a high percentile alongside the median, and the outliers stop being invisible — because the outliers are the ones people remember and talk about.
Alerts that get read
The failure mode of monitoring is not too little data, it is alerts nobody acts on. An alert earns its place only if someone owns it, it means something has genuinely gone wrong, and there is a defined response. Anything that fires routinely and is routinely dismissed is training people to ignore the channel, which is worse than having no alert at all.
Practical test: for every alert you have configured, name the person who acts on it and what they do. Alerts that fail that test should be deleted rather than tuned.
Starting without buying anything
Monitoring gets sold as a platform purchase, and for a large organisation with many systems that may be right. For most, the first useful version is far smaller.
Pick the one process that generates the most complaints. Establish where a case starts and where it finishes. Get timestamps for those two points out of whatever system already holds them, even if that means a spreadsheet export. Plot the distribution of elapsed time for the last few hundred cases. That single chart usually identifies the bottleneck immediately, and it costs an afternoon rather than a procurement cycle.
Buy tooling once you know what you need it to watch. Buying first tends to produce dashboards nobody opens, measuring what was easy to instrument rather than what matters.
Frequently asked questions
What is business process monitoring?
Observing processes as they run to see whether work is completing at the expected pace and quality, and surfacing problems before customers encounter them.
How is it different from business process management?
Management is designing and improving the process. Monitoring is watching the version you have actually got. They share an acronym and very little else.
What should I measure first?
Cycle time, including its spread rather than only its average, and the split between waiting and working. Those two locate most bottlenecks.
Why are averages misleading?
Because they hide the tail. A healthy average with a slow tenth produces most of your complaints while the reported number looks fine.
Do I need dedicated software?
Not to start. Timestamps from systems you already run, charted properly, will identify the bottleneck. Buy tooling once you know what to watch.
What does a high exception rate mean?
That the official process does not fit the work. When people routinely bypass it, the design is wrong rather than the people.
