Process Analysis: Definition, Template, Example
· DigifyNow
A process analysis follows one workflow from trigger to outcome using real, completed cases. For each step, you record who does it, in which system, how long it takes and how long the case sits waiting before it. Then you give each step a decision: eliminate, standardize, automate, build into software or leave as is. Start with a single process, talk to the people who actually do the work, and use a spreadsheet.
What is process analysis? Definition and how it differs from related terms
Process analysis is the systematic examination of a business workflow, from a clearly named trigger to a clearly named outcome. It records which steps actually happen, who performs them, which system or document is used, how long each step takes, and where the case waits, gets sent back or is entered twice. Three terms are often mixed up here. Process modeling is the representation, for example as a diagram. Process optimization is the change that comes afterward. Process mining is a method for reconstructing workflows from the log data of IT systems. Process analysis comes before all three and supplies the facts they build on. One pair of terms helps when you evaluate the results: processing time is the time someone actively spends working on a case. Cycle time runs from trigger to outcome and includes every period the case sits idle. If the two are far apart, the problem almost always lies in handoffs and waiting time, not in the work itself. If you then want to move workflows into software, the approach is laid out in the article Digitizing business processes: steps and examples.
How do you do a process analysis step by step?
At DigifyNow, a process analysis always follows the same sequence, whether it ends up leading to an app, an automation or no software at all. What matters is that you work with the current state (the as-is process), not with the workflow your operations manual describes.
- Define the scope of the process: exactly one trigger and exactly one outcome, for example from "inquiry comes in" to "quote has been sent." A process like "sales" is too big for an analysis.
- Interview the people who do the work: a separate conversation for each role, ideally right at their workstation and long enough to walk through several real cases on screen. Management describes how the workflow is supposed to run; the staff handling it describe how it really runs.
- Trace real cases: take a sample of completed cases from the past few weeks, large enough to include exceptions, with timestamps from emails, the ERP, calendars or file storage.
- Count the variants: Which path is the standard, how many exceptions are there, and what triggers them?
- Flag the weak spots: waiting time, media breaks (switching between paper, email and systems), duplicate data entry, follow-up questions, approval bottlenecks.
- Assign a decision to every step: eliminate, standardize, automate, build into software or leave unchanged.
What you end up with is a table of these decisions, not a diagram that disappears into a folder after the workshop.
If the decision for a step is "use AI," for example an AI assistant that pre-sorts inquiries, the EU AI Act comes into play. It requires providers and deployers of AI systems to take measures that support the AI literacy of the employees who work with the system. They are not required to guarantee any specific level of literacy. High-risk applications are subject to their own, stricter rules. Whether a planned system falls into that category has to be assessed case by case. The process analysis supplies the description needed for that: exactly what the system is used for and who works further with its output.
What does a process analysis template look like?
You don't need an elaborate template for a process analysis. A spreadsheet in which each row describes one step is enough. Above the table go three details: process name, trigger and outcome. It also helps to add the frequency per month, because a short step that happens many times a day carries different weight than a long one that comes up only occasionally during the year. These are the ten columns DigifyNow uses in practice:
| Column | What goes in it | Typical mistake |
|---|---|---|
| No. | Order of the step | Parallel steps are recorded as sequential |
| Step | Activity as verb plus object, e.g. "check price" | Too vague, e.g. "processing" |
| Role | Who performs the step | A person's name instead of a role |
| System/medium | Email, Excel, ERP, paper, phone | Left out because it's "obvious" |
| Input | What the step needs | Missing information goes unnoticed |
| Output | What the step produces | Result with no storage location |
| Processing time | Active minutes per case | Estimated instead of measured on real cases |
| Wait time before | Waiting time until the step starts | Not recorded at all |
| Frequency | Cases per month | Exceptions counted in |
| Problem/follow-up | What goes wrong here and why | Only the symptom, not the cause |
If you want to sketch out the boundaries roughly first, you can create a SIPOC before the table: Supplier, Input, Process, Output, Customer. These five columns let you narrow the process down to a few main steps before the detailed mapping begins.
What tools do you need for process analysis?
At DigifyNow we work in three stages and only move to the next one when the previous one isn't enough. Stage one is a whiteboard or sticky notes in a session with the team. That's the fastest way to move steps around, and nobody gets slowed down by software. In stage two, we transfer the result into the table described above and, if several roles are involved, into a BPMN diagram. BPMN is a standardized graphical notation for business processes. Each role gets its own lane, and decisions are shown as diamonds (gateways). That makes handoffs between departments visible. Stage three is process mining. It only works if a system provides an event log in which every entry contains a case ID, the name of the activity and a timestamp. In many small and midsize businesses, though, the workflow runs through an inbox and Excel, and then that log simply doesn't exist. If process mining evaluates data that allows conclusions about individual employees, data protection and, where one exists, the works council need to be involved. That review has to happen inside the company; the tool doesn't take care of it.
Process analysis example: what does it look like in a real workflow?
A typical example from the trades and service businesses is the path from inquiry to quote. Here is what the as-is workflow often looks like: inquiries come in by phone, email and contact form. Phone inquiries end up on a scrap of paper. Someone calls back and schedules an on-site visit. The quote is written in a Word template, with prices copied from an Excel list. Then it waits for management approval, gets saved as a PDF and sent by email. Follow-up happens if someone remembers. The analysis uncovers four things: several intake channels with no shared list, prices maintained in two places, approval as a bottleneck because only one person can give it, and no status for open quotes. That leads to concrete decisions: a central intake list, a single source for prices, quotes generated from that data, and a follow-up reminder. The on-site visit and the professional approval are deliberately not automated, because that is where experience makes the call. Whether an off-the-shelf solution is enough in the end or a custom back office with CRM makes sense, like the one we built for Mundo Marketing, is something only this analysis can answer. The trade-offs are covered in the article Custom software: when it pays off for small businesses.
If the decision is to build your own software, at DigifyNow the analysis table becomes the scope of an MVP: every row marked "build into software" turns into a feature, and everything else stays out. How long implementation takes in a specific case depends on the integrations with existing systems, the condition of the existing data and the number of roles with their own permissions. How timeline and effort come together is explained in the article MVP entwickeln lassen: Kosten und Dauer (in German). If you'd like your finished table assessed, you can request a free assessment of your project.
Why do process analyses fail, and when aren't they worth it?
Most process analyses don't fail because of the method, but because of a handful of recurring mistakes:
- The intended (to-be) workflow gets documented instead of the actual one. Cause: only management was interviewed, not the people who do the work.
- The scope is too big. Cause: there is no clear trigger or no clear outcome, and the analysis never gets finished.
- Exceptions are ignored. Cause: only the standard case was walked through, and it is exactly the special cases that later bring the automation to a halt.
- The analysis ends without a decision. Cause: nobody is responsible for turning the weak spots into actions.
- The process is in the middle of changing. Cause: a transition is still underway, for example to e-invoicing, and the documentation is outdated before it is finished.
A detailed analysis isn't worth it for workflows that happen only a few times a year or that a single person handles in a few minutes. There, writing everything down costs more time than you could ever win back later. If, on the other hand, a step is frequent, rule-based and already receives its data digitally, it is a candidate for automation. Which workflows are suited to that is covered in the article Business process automation: what pays off for small businesses.
Frequently asked questions
What does BPMN mean in process analysis?
BPMN stands for Business Process Model and Notation, a standardized graphical language for workflows. Roles appear as lanes, activities as rectangles and decisions as diamonds (gateways). For a process with only one role, a table is usually enough for the process analysis; BPMN pays off where cases are handed off between departments and those handoffs need to be made visible.
What data do you need for process mining?
Process mining needs an event log in which every entry contains a case ID such as the order number, the name of the activity and a timestamp. From these entries, the software reconstructs the actual workflow. If the process runs through email and spreadsheets instead of an ERP or CRM system, that log is missing, and interviews with the people doing the work are the more realistic route for the process analysis.
Who should take part in a process analysis?
The process analysis should include the people who carry out the workflow every day, plus one responsible person with decision-making authority. The people doing the work know the as-is state with all its exceptions; management knows the intended to-be workflow. Without the first group, the analysis describes an operations manual instead of reality; without the second, it ends without a decision on the weak spots it found.