At the end of September, the process management community meets in Stuttgart for All about Process Management. Two days of keynotes, masterclasses and round tables, and if the agenda is any indication, one theme will run through most of them: AI agents, and what it takes to let them act inside a business process. We will be there as an exhibitor, and this is the argument we intend to make.
It begins with something that has nothing to do with software. In most companies, finding out what is actually going wrong in a process requires someone to suspect it first.
Think about how these things usually surface. A supplier complains about a late payment. A manager notices that approvals seem to be taking longer than they used to. A team feels like it is doing the same work twice. Somebody raises the question, and only then does the work begin: pull the data, build the analysis, present the findings, agree on a measure. Weeks later there is an answer, and it is usually a good one.
But notice what had to happen before any of that. Someone had to have a hunch. And a hunch only forms where somebody is close enough to the work to feel that something is off. Everything nobody happens to feel stays invisible: the department that never complains, the process step nobody owns, the exception that has quietly become the norm. Not because the data is missing, but because no one thought to ask.
The standard answer is a dashboard. Put the numbers on a screen, refresh them regularly and let people look.
It helps, and it does not fix the underlying problem. A dashboard still waits to be interrogated. It rewards the person who already knows which chart to open, which filter to set and which number is unusual for this time of year. It gives you a way to check a suspicion faster, but it does not give you the suspicion. So the same blind spots survive, now behind a nicer interface.
You can see this in how dashboards are actually used. A handful of specialists use them constantly. Nearly everyone else opens them when asked to, glances at the top line and closes them again. Not out of disinterest, but because scanning a process view for anomalies is genuinely hard work and most people have another job.
There is a step almost everyone skips, because it feels administrative rather than clever. If you want a system to tell you when something has gone wrong, you have to tell it what right looks like.
Most organisations have this knowledge, but it lives in the wrong places: in a quality manual nobody reads, in a policy document, in the head of the person who has done the job for eleven years. It exists as intention. It does not exist in a form anything can check.
Written down properly, it turns out to be surprisingly simple and surprisingly concrete. An invoice should not be paid before it has been approved. An order should not be changed three times after it has been confirmed. The person who requests something should not be the person who signs it off. A customer request should not sit untouched for more than five days. None of that is sophisticated. It is what people in the process already believe, made explicit.
In Process.Science Intelligence, that is what Process Norms are: your own expectations about a process, written as rules and then checked against what actually happened in your systems, in every case rather than in a sample. Where the data does not allow a clear verdict, that is stated rather than quietly counted as fine.
That is the whole precondition. Once it is in place, the direction of the work can be reversed.
The conventional path runs from dashboard to insight. A person opens a view, looks for something that seems wrong, forms a hypothesis, filters, drills down and eventually arrives at a root cause. That path depends entirely on someone deciding to look, knowing where to look and looking often enough. It scales with the number of available specialists, which is to say it does not scale.
Process.Science Intelligence has a function called Alerts that runs the path in the other direction. Instead of waiting to be interrogated, the system checks the process against your norms and points you at the places where reality has diverged: here, in this part of the business, against this rule, this many times, this often lately. From that alert you move straight into the relevant analysis, and from there into the root cause: which cases are affected, what they have in common, what it is costing in time. You do not have to reconstruct the path, because it has already been laid out for you.
Not dashboard to insight. Insight to the right place in the dashboard, with the root cause already in view. And where the analysis shows that deviations cluster around one supplier, one site or one document type, it says exactly that. A strong indication of where to look next is worth a great deal, and it is not the same thing as proof, so we do not present it as proof.
The consequence is a change in who process work is for. The old path served specialists who knew the tool, the data and the process well enough to navigate all three at once. The new one serves the people who own the process: team leads, controllers, department heads and shared service managers. They do not need to know how to build an analysis. They need to be told where to look and then be able to follow the trail themselves.
For years this was a matter of efficiency. Fewer blind spots, faster answers, less dependence on a few overloaded analysts. Worth doing, but not pressing.
Automation changes that. Software that approves, orders, books and answers on its own does not have a hunch. It does not notice that a supplier is unusual, that an approval chain was circumvented or that a step was skipped because someone was on holiday. People absorb that kind of ambiguity constantly and silently. A machine absorbs none of it. So the moment you let software act inside a process, the unwritten rules have to become written ones, not for the sake of the analysis but to define the boundary: where is the machine allowed to decide, and where does it have to hand back? An organisation that has never stated what correct looks like has no way to answer that, and no way to tell whether its answer still holds six months later.
The value shows up in three places. Problems are found while they are still cheap, because a deviation is visible in the week it happens rather than in the quarter someone finally asks about it. The people who own the process can act on it themselves, which means improvement stops queueing behind the availability of an analyst and starts happening where the work is. And the organisation ends up with something it did not have before: a written, tested standard for how its processes are supposed to run. That standard is what makes the next step defensible, whether the next step is a target agreement, an audit or handing part of the process to a machine.
None of it depends on a large programme. It depends on being willing to write down what you already believe about your process and then letting the data disagree with you.
We would rather discuss this than assert it, because the interesting part is always the specific process: which rules a company is confident enough to write down, and which ones turn out to be more negotiable than anyone expected.
We will be at All about Process Management on 30 September and 1 October 2026 at the ICS in Stuttgart, and we will happily show Alerts live, starting from a single deviation and following it through to the root cause. Come by the stand for that conversation.
Prefer to talk sooner? Use Speak with an Expert to arrange a demo and we will do it on a process of yours. We are looking forward to the discussions.
