Process Discovery: The Three Ways to Find Out How a Process Actually Runs

Key takeaways

‍

• Process discovery is the work of establishing how a process really runs, so that improvement, automation and documentation start from evidence.

• It’s done in one of three ways: workshops and interviews, log-based discovery, or observation of desktop activity, and each sees a different part of the work.

• Process mining is one method of process discovery, the one that reconstructs a process from records that systems already keep.

• Every method has a blind spot, so knowing what yours can’t see matters as much as knowing what it can.

• The right method depends on the systems you have, and many mid-market organizations don’t have the event logs that process mining needs.

‍

Before you can improve a process, automate it or write it down properly, you need to know how it runs today. Process discovery is how you find out, and the first decision you make is which way to look.

‍

There are three options:

1. A workshop tells you what people believe they do.

2. System logs show everything that passed through a system that keeps records.

3. Desktop activity shows the whole path, including the parts that never reached a system at all.

‍

The discovery method you choose sets the ceiling on what you can find. Pick one that can’t see the problem, and the problem stays invisible.

‍

What is process discovery?

‍

Process discovery is the practice of establishing how a business process really runs, as opposed to how it was designed or how the people involved describe it, using evidence from workshops, system records or observed activity. The result is a map or model of the process as it’s performed, and it becomes the starting point for any decision about changing it.

‍

That map gets used in four main ways:
‍

• Improvement work needs it so the team fixes the process people follow, instead of a version that stopped being accurate months ago.

• Automation needs it because a bot built on the documented version tends to break on the first exception nobody wrote down.

• Documentation needs it so written procedures describe the work as it’s done.

• Compliance teams need it to show what happened, which isn’t always what the policy says should have happened.
  
  

Business process discovery is the same activity under a longer name, and it tends to turn up in enterprise and audit settings.

‍

Discovery also comes before two pieces of work it’s often confused with. Process mapping and process modeling both take what discovery finds and turn it into a diagram or a formal model, often in a notation such as BPMN, and neither can be more accurate than the discovery underneath it.

‍

The three methods

‍

Most discovery work uses one of three methods. Each suits some situations and not others, so it helps to know what each one can see before you commit to it.

‍

Workshops and interviews. You bring the people who run the process into a room, or talk to them one at a time, and ask them to walk through it. It’s quick to set up and needs no technology, which is why most teams start here. What you get back is the process people believe they run, and that’s usually close to the intended version.

Exceptions, workarounds and rework tend to be missing, because people describe the normal case when asked how something works. Use it when the goal is shared understanding across a team, or a first sketch you can test other evidence against.

‍

Log-based discovery. Here the process is rebuilt from records systems already keep: timestamped events tied to a case, such as an order or a claim. This is the approach usually called process mining, which reconstructs a process from system records. It’s precise about anything that passed through a system that logs, and it can cover thousands of historical cases at once.

It can’t see work that happens between systems, and it depends on the quality of the logs and on extracting them before there’s anything to look at. It works best when the relevant systems log consistently, cases can be followed across them, and the question sits inside those systems.

‍

Observation-based discovery. This method captures activity at the desktop level, across the applications people use to do the work. It sees the full path a case takes, including the steps no system records, which is often where the time goes. Because it works across applications, it doesn’t depend on each system in the chain keeping its own records.

It needs a clearly agreed scope and an open rollout, so the teams involved know what’s being captured and why. Reach for it when work crosses several systems, when there are no usable logs, or when the process changes too often for a one-time picture to stay useful.
‍

There are process discovery tools for all three approaches, from structured workshop formats to software that builds a model from logs or from desktop activity. The right kind of tool follows from the method, so it pays to choose the method first.

‍

Process mining vs process discovery

‍

Process discovery is the goal, and process mining is one method of reaching it. Discovery covers any way of establishing how a process runs. Mining is the log-based technique within it.

‍

So when people ask about process mining vs process discovery, or process discovery vs process mining, they’re usually comparing a method with the job it does. Every process mining project is a process discovery project. Plenty of discovery projects never use mining, because workshops and observation don’t need system logs at all.

‍

‍

Task mining sits close by. It captures detailed interactions at the user interface, usually to find repetitive desktop tasks worth automating, and it looks at individual tasks more than whole processes.

‍

Mixing the terms up has a practical cost. A team that decides it needs process mining, then finds its systems don’t produce usable logs, often concludes that discovery will have to wait. It doesn’t. One method is unavailable and two remain, and treating the terms as interchangeable is what turns a missing log into a missing option.

‍

What matters in the end is which method fits the systems and questions you have. A team with clean, well-structured logs and a question that lives inside one system should use those logs. Where the work runs across email, spreadsheets and three different tools, you need a method that can see all of that. Both are doing process discovery.

‍

Automated process discovery

‍

Automated process discovery uses software to keep discovering a process over time, where a manual effort produces a single snapshot. It can work from logs or from desktop activity, and it changes three things.

‍

It keeps running, so the picture updates as the process shifts and drift shows up when it happens, instead of at the next review. It covers far more ground than a team could interview or sit alongside by hand. It also doesn’t rely on anyone remembering how the process worked last quarter, or on finding a slot in everyone’s calendar.

‍

Two things stay the same. Someone still has to decide which process to discover and where its edges are, because software can’t judge which process matters most to the business. The output still has to be read by people who understand the context, too. A process map doesn’t explain itself, and two teams looking at the same one can reasonably reach different conclusions about what to change.

‍

Say a claims process picks up a new approval step after a policy change. Last year’s workshop won’t know about it, and neither will a one-off extraction unless someone reruns it. A continuous view shows the new step in the week it appears.

‍

Automation makes it much easier to keep the picture current. The judgment about what to do with it stays with you.

‍

What discovery misses, by method

‍

Every discovery method has a blind spot. Saying so plainly is more useful than pretending the method you prefer doesn’t have one.

‍

Workshops miss the exception path. When you ask people to describe a process, they describe the version that’s supposed to happen. Ask a team how an invoice gets approved and you’ll hear the three-step version. The invoice that arrived without a purchase order and sat in someone’s inbox for a week won’t come up unless someone happens to remember it, or the facilitator asks about exceptions directly.

‍

Logs miss the queue, the rekeying and the spreadsheet in the middle. A log records when a case entered a system and when it left. It doesn’t record the hours the case waited for someone to pick it up, the details copied by hand from one system into another, or the spreadsheet used to reconcile two tools that don’t connect. Those gaps are often where most of the elapsed time sits.

‍

Observation misses intent. Desktop activity shows what happened. It can’t show why. Telling rework apart from a case that legitimately needed a second pass takes someone who understands the process to interpret the pattern, and that’s where observation leans hardest on judgment. A short conversation with the team doing the work usually settles it.

‍

A discovery effort built on one method inherits that method’s blind spot, and nothing in the output warns you, because the map looks complete either way. Using two methods, or at least knowing which gap yours leaves open, usually beats searching for the single best one.

‍

How to choose a discovery method

‍

Five questions usually settle it:

‍

1. Do your systems already emit timestamped events with a case identifier?

‍

2.How much of the work happens between systems rather than inside one?

‍

3. Do you need a one-off answer or a continuous view?

‍

4. How quickly do you need a first result

‍

5. What is your appetite for an integration project before you see anything?

‍

The first question decides whether log-based discovery is available at all. An event log needs every event to carry a timestamp and belong to an identified case, which is the structure IEEE 1849, the standard for event logs, sets out. A system can hold years of data and still fail that test.

‍

The second decides how much a log could show even if you had one. Work done in email, on paper or in spreadsheets never appears in a system log, however clean that log is.

‍

The third and fourth are about timing. A one-off documentation project can live with a workshop. A process you want to keep improving needs something that keeps running, and how soon you need a first result narrows the options further.

‍

The fifth is about sequencing. Log-based discovery needs the data extracted and prepared before it shows anything, so it suits organizations that already have that pipeline, or plan to build it.

‍

Many mid-market organizations answer the first question with no. Their systems don’t log consistently, or there’s no shared case identifier to connect events across them. That rules out log-based discovery as a starting point, whatever its merits elsewhere.

‍

Discovering a process without the logs

‍

If your systems can’t produce an event log, the choice comes down to workshops or observation. Workshops will give you the intended process. Observation is how you see the one people run.

‍

Insightful is a work data platform, and its Workflow Optimization product discovers a process by capturing activity and interactions at the desktop level, across the applications people actually work in. It produces a first map without an event log extraction project, and it covers the work that happens between systems.

‍

That speaks to two of the questions above. There’s no integration project between deciding to look at a process and seeing a first picture of it, which matters most to organizations that answered no to the first question. And because it works at the desktop, it sees what sits between systems: the wait before a case gets picked up, the spreadsheet in the middle, the handoff from one team to the next.

‍

It works at the level of the process and the team, and it doesn’t replace the judgment the earlier sections describe. Someone still sets the scope and clears it with the teams involved, and someone still reads the output. What it supplies is evidence for those decisions, where otherwise there would only be a workshop’s account.

‍

It also pairs well with a workshop. The workshop gives you the intended process, and the observed activity shows where practice has moved away from it, which is usually the conversation worth having.

‍

Start where the evidence is

‍

The method you choose sets the ceiling on what you can find, so choose it against the systems you have today. A workshop, a set of logs and a record of desktop activity each answer a different question, and a method that can’t see your problem will leave it hidden however carefully the rest of the work is done.

‍

If you have clean logs for part of the process, use them for that part. If your systems can’t produce an event log, start with a method that works without one and add others as the evidence builds. The processes most worth discovering tend to be the ones that change often, so continuous observability is key for keeping the picture current.

‍

Workflow Optimization is currently in beta. Request beta access to see how your processes actually run.

‍

Frequently asked questions

‍

What is process discovery?

Process discovery is the practice of establishing how a process really runs, as opposed to how it was designed or how people describe it. It draws on workshops, system records or observed desktop activity to build that picture, and the result supports process improvement, automation, documentation and compliance work.

‍

What is the difference between process mining and process discovery?

Process discovery is the goal, and process mining is one method of achieving it. Discovery covers any way of establishing how a process runs, including workshops and observation. Process mining is the log-based technique that reconstructs a process from timestamped system records, so every mining project is a discovery project, though not the other way around.

‍

What are the process discovery methods?

There are three: workshops and interviews, which capture the process people believe they run; log-based discovery, which rebuilds a process from system records; and observation-based discovery, which captures activity at the desktop level. Each one sees a different part of the work, and each has a blind spot the others can help cover.

‍

What is automated process discovery?

Automated process discovery uses software to discover a process continuously, where a manual effort produces a one-off snapshot. It covers more ground and doesn’t depend on anyone’s memory of how the work used to run. A person still has to set the scope, though, and the output still needs interpreting by someone who understands the business.

‍

What is business process discovery?

Business process discovery is the same thing as process discovery under a longer name. The term is more common in enterprise and audit settings, but the practice is identical: establishing how a process really runs, using evidence from workshops, system records or observed desktop activity.

‍

Which process discovery method should you use?

Choose based on the systems you have. If they emit timestamped events with a case identifier and the work stays inside them, log-based discovery is a strong option. If they don’t, or the work moves between systems, a workshop or observation-based discovery will make a better starting point.

‍