Process Mining Business Case: Four Numbers for Finance

A process mining business case gives finance four figures to assess: the size of the problem, the cost of the fix, the pilot cost, and the time to first evidence. Three of those four can come from one export of your own process data. Where a figure is still an estimate, label it as one and say when it will be measured.

A request to “introduce process mining” is hard to assess because it does not name a problem, a decision, or a date for evidence. Most cases that fail were built on what someone hoped the tool would produce rather than on what the process actually does. That is why this page keeps the case on one process: what you will measure, what the change will cost, and when you will know.

What four numbers does a process mining business case need?

Name all four before you argue for any of them, and give each one a basis you can point to.

1. Problem size: what the process costs you now, in a unit your business already tracks, such as cycle-time days, late fees, days sales outstanding, or FTE hours. Base it on your own volume and your own timings.
2. Cost of the fix: what it takes to change the process, not to analyze it. A policy change and a round of retraining are a different size of job from a system change, and the estimate belongs to whoever owns the change.
3. Pilot cost: the license, the data work, and the internal time needed to establish the facts.
4. Time to first evidence: the date you expect a result to review, and the measure you will review it against.

Three of the four usually come from the same place. A process data export gives you the problem size, the effort of preparing that data, and how long the analysis takes. The cost of the fix is the one that depends on a decision you have not made yet, which is why it needs a named owner and a date rather than a number you invent.

Mark every figure in the case as measured or estimated. Finance will ask which is which, and a case that answers that question is harder to dismiss than four confident numbers with no visible basis.

Why do process mining business cases lose support?

Cases rarely fail because a figure is wrong. A business case for process mining fails when there is nothing to check.

They ask for a capability instead of a decision. “We will gain visibility across order-to-cash” does not tell finance what it is funding or how you will judge the result. “We will find out whether the second approval step adds a week to a third of orders, and report the result by November 15” does.

They rely on benchmark percentages. A claim that process mining typically reduces cycle time by a certain percentage says nothing about your process. Your own baseline is more useful, even when it is less impressive.

They leave out the data work. Extracting data, identifying cases, ordering timestamps, and setting up refreshes take time. If your case lists only the license, it understates the pilot. Read the cost breakdown first for a closer look at the cost lines.

They use an average that hides the problem. An average handling time spreads a five-day wait evenly across every case, so the number looks small and any improvement looks smaller. Say where the time sits instead: which step, how many cases, how long. “About 12,000 orders a quarter; roughly a third miss the promised date, and the cause is unclear” gives a reviewer something to test. “Significant inefficiency in order management” does not.

What do process mining projects typically deliver?

Knowing the shape of the evidence makes the case easier to write. A first analysis of one process from its event data usually answers questions like these:

• Where the time goes: waiting time per activity next to the work time at that activity, so the gap between the two is visible.
• How often the process repeats itself: loops and rework counts, including steps a documented model does not show.
• How many hands a case passes through: handover counts between teams and systems.
• How much the process varies: how many distinct paths exist, and what share of cases follow the most common one.
• Where the process leaves the rules: conformance gaps against the process you intended to run.
• Which steps are candidates for automation: high-volume, rule-based, low-variance steps with a measured baseline behind them.
• What each step costs in effort: time per step and per case, so a proposed change can be priced.

Which of these you get depends on your process and your data. A log with a case id, an activity, and a timestamp answers the first four. The rest need more detail, and some need a model to compare against. See how Process Mining analyzes your process data, and if the data is not usable yet, the intelligence path covers what has to be in place first.

One thing is worth stating plainly: the tool does not give you the answer. It gives you the evidence, and the evidence is what you turn into a business case. Nothing in that list tells you what a change is worth, whether a step should exist at all, or how much capacity your team can really give back. Those remain business decisions, and they are easier to make once the measurements exist. Process mining benefits are only as large as the change those decisions support.

If the log covers only part of the process, or only part of the period, say so where you state the figures. A partial measurement is still evidence, as long as the reader knows what it covers and what it leaves out.

How do you build the benefit side from your own measures?

Problem size becomes a benefit only when you say what changes. Process mining value comes from the decision the evidence changes, so keep the case tied to a decision your organization has to make. To justify process mining investment, two models cover most first cases:

Cash or working capital:

days removed × cases affected × value per case-day × cost of capital

Capacity:

hours removed per period × fully loaded hourly cost

Keep three distinctions clear:

• Use a unit your business already uses. Express the benefit in cycle-time days, late fees avoided, DSO reduced, or hours returned. “Efficiency” on its own cannot be verified.
• Separate cash from capacity. Releasing capacity does not create cash by itself. Say whether the value comes from handling more volume with the same team or from a staffing decision, and name who makes that decision.
• Name the assumption you are least sure of. State which part of the estimate is weakest and how you will test it.

A measured baseline makes the rest of the calculation easier to defend. If the hours came out of your own event data, the only assumption left is the size of the reduction, and that is a number a reviewer can argue with. A benefit built on an assumed baseline and an assumed reduction rarely survives the meeting. If you cannot defend a reduction percentage, quote the range you tested and say which end of it you used.

You can put those inputs into the ProcessMind ROI calculator: annual case volume, average handling time, a fully loaded hourly rate, the reduction you expect, incidents and their average cost, plus the plan inputs for the license. It returns total annual benefits, net benefit, return on investment, and a payback period.

It is a general model, and that is the value of it: it shows how the inputs combine. It becomes your case only once you replace the defaults with your own volumes, timings, and costs. The calculator also leaves implementation effort and data preparation out of the cost side, so add those separately. A model you cannot make specific to your own situation is not a case yet.

What does a four-number business case look like in practice?

The figures below are illustrative. Use the method, not the values.

Situation: A process handles 12,000 orders per quarter. Median cycle time is 18 days, and P90 is 41 days. About a third of orders wait more than five days at one approval step, which takes around four minutes of actual work.

1. Problem size: The wait affects about 4,000 orders per quarter. If the average wait at that step is six days, that is 24,000 order-days of cycle time per quarter. The work that step actually requires is about 270 hours in the same period. Which of the two belongs in the case depends on whether the delay costs you money, service levels, or both, and either figure should be checked against your own data before you use it. Note the unit as well: order-days are not the same as euros, so if the case has to end in money, that conversion is another assumption to state and test.

2. Cost of the fix: One possible change is to raise the threshold so the approval step applies to 8 percent of orders instead of 33 percent, and assign a delegate when the approver is absent. Confirm the policy, control, and implementation costs with the people responsible before treating this as a low-cost fix.

3. Pilot cost: Scope the pilot to one process and a defined period. Include the license, analyst time for data preparation, and the process owner’s time. Mark data preparation as an estimate if you have not confirmed the effort. A cost benefit process mining case that lists only the license will understate the work involved.

4. Time to first evidence: Set a date to review cycle time for the affected segment. If the wait does not change, you will still have a baseline to inform the next decision.

What could change the conclusion? If the approval step exists to catch a control failure, changing the threshold could weaken that control. Include that risk in the case and involve the control owner before recommending a change.

Put the four numbers and the finance questions on one page:

Every line in that table should point at something you measured or something a named owner estimated. A process mining ROI calculation is no different: do not present an estimate as a saving until your own data and the proposed change support it.

To find the steps that may be worth changing in the first place, read how to find automation opportunities with process mining.

Why should your first business case be a pilot?

The first business case is for a pilot, not for a platform. That is what the four numbers are sized for: one process, one decision, and a period short enough to review the result before committing to anything larger. Treat it as a process mining proof of value: a measurement exercise, not a small rollout.

Try it small and keep the bar honest: the business case should be a no-brainer. If it is not, you are thinking too big. Let the data speak first, then scale up where it matters. A pilot that costs a few seats and a few weeks of analyst time has to clear a much lower bar than a platform programme, and it produces something a platform programme cannot: your own baseline.

Starting small is also a software decision. If a tool only makes sense as an enterprise deployment, the case has to be big before it is written. ProcessMind is priced per seat, with a free tier after the trial and a 14-day free trial that needs no credit card, so the first analysis does not require an enterprise agreement. See what each plan costs.

Four things to fix before you start a process mining pilot:

• One process: narrow enough that a single question drives the scope.
• One decision: the decision the findings are meant to inform.
• Exit criteria: agreed in advance, what would support continuing and what would support stopping.
• A review date: the date you assess the evidence and decide what happens next.

If the pilot supports further work, use its findings to make the case for the next process. If it does not, you still have a baseline and a clearer reason to change direction. Either way, write the three possible outcomes into the case before you start: the evidence supports this change, it supports a different change, or it supports stopping. A case that can only end one way is not a measurement exercise.

What if the numbers are not ready?

Then the investment may not be justified yet, and saying so is a finding rather than a failure. Three reasons usually explain it: the process has too little volume for the work to matter, the data is not available in a usable form, or no one is waiting on the decision.

If the data exists and the process is small, measure a baseline by hand. If the data is not usable, scope the data work instead of requesting a license, and say what would have to change before you revisit the case.