A good process analysis finds the cause behind a symptom. When quotes take a long time, it may be the costing. Often, though, every quote is simply waiting for an approval. To see that, you need metrics that explain something, such as idle time per case. You also need the view of several people involved, so the picture is complete. This way the analysis leads to a change that holds up in everyday work.
This guide covers the definition and goal of process analysis, the methods that suit companies with 10 to 500 employees and a five-step approach. It adds an example from wholesale, advice on communicating the analysis to your team and the common mistakes. A process analysis builds on process documentation that shows how a workflow runs today.
What is a process analysis? Definition and goal
A process analysis systematically examines an existing workflow to find weaknesses, risks and starting points for improvement. It shows where a process loses time, where errors arise and why.
The goal of a process analysis is an evidence-based foundation for decisions. Typical questions it answers:
- How long is the lead time, and how much of it is actual work?
- Where do errors, follow-up questions and rework arise?
- At which handoffs between people, departments or IT systems does information get lost?
- Which steps depend on a single person, so the workflow stalls during vacation or illness?
- Where is work done twice or retyped by hand?
The result is a prioritized list of findings, each with a cause, evidence and an action.
Process mapping and process analysis: the difference
Process mapping delivers the raw material: who does what, in what order and with which tools. Process analysis evaluates that material and asks which of it is a problem, and why.
The order matters: map first, evaluate second. If you judge while mapping, you get more cautious answers. When the conversation stays open, people describe their work more freely, including detours and workarounds. How to capture the as-is state accurately is covered in detail in the guide on as-is process mapping.
There is also a clear line to process optimization. The analysis shows you where things get stuck and why. What you do with that comes next: change the workflow, introduce software or reassign responsibility, as described in the guide on process optimization. How AI helps with that next step is covered in the guide on AI process optimization.
Process analysis methods at a glance
For small and mid-sized companies, four core methods are enough in practice, plus process mining when the data is available. None of them requires a certification course.
Weak-point analysis
What it's for: The best-known method. You walk through a process step by step and ask at each one: where does it snag? What takes too long, what goes wrong, what costs the people involved extra effort? Weak-point analysis is a good starting point when you don't yet know where the problem is.
Effort: Low to medium. Plan one to two days per process if the mapping is already done. A lot depends on the questions. "What do you do when the customer doesn't return the order confirmation?" yields more than "Is the process working well?"
Typical outcome: A prioritized list of weak points with root causes. A typified example from a metal fabrication shop: quotes take two weeks. The costing is done quickly. Yet every quote waits for sign-off from the owner, who spends three days a week on job sites.
Value stream analysis light
What it's for: The method comes from lean management. Here you use a streamlined variant without symbol catalogs and takt-time calculations. You follow one concrete case from start to finish, such as an order, a complaint or a purchase. Along the way you record two times: how long is it actually being worked on, and how long does it wait?
Effort: Medium. You need real cases to trace, ideally five to ten, to spot outliers. Plan for two to three days per process.
Typical outcome: The ratio of processing time to idle time, which often comes as a surprise. An order that spends 14 days in-house is frequently worked on actively for only a few hours. The rest of the time it waits for approvals, for clarifications or for the colleague who's back from vacation. That last one is a case for a proper vacation cover plan. The idle times are your starting points.
Handoff analysis
What it's for: Many problems arise at the handoffs between departments. Think of the path from sales to production planning, from production to shipping or from service to accounting. Handoff analysis looks at exactly these transfer points: what is handed over, in what form, with what information, and what is regularly missing?
Effort: Medium. You interview both sides of every handoff, separately, because perceptions often diverge here. Sales is certain the order folder is complete. Production planning still calls back on every other order because the delivery dates are missing.
Typical outcome: A handoff matrix that shows which interface needs which information and where it snags. The most common finding: the two sides mean different things by "done".
Media-break analysis
What it's for: A media break is any point where information changes systems and gets transferred by hand. The service technician fills out the timesheet on paper, and accounting types it into the billing system. The order comes in by email, and someone keys it into the ERP. Every one of these breaks costs time and produces errors.
Effort: Low. You find media breaks quickly when you ask for them directly: "Where do you retype something that already exists digitally somewhere?" Half a day per process is often enough.
Typical outcome: A list of all system switches with their frequency. It is a good foundation for digitalization decisions. A media break that occurs five times a day justifies automation. For one that occurs once a quarter, a clear instruction is usually enough.
Process mining: analysis from system data
What it's for: Process mining reconstructs workflows from the log data of your IT systems. ERP, CRM or ticketing systems store which activity happened when for each case. From these event logs, a process mining tool calculates the actual paths. You see which variants exist, where loops occur and how long cases sit between two steps.
Effort: Medium to high. You need logs with three details per entry: case ID, activity and timestamp. Preparing this data usually takes longer than the analysis itself. The method pays off with high case volumes, such as thousands of orders a month.
Typical outcome: A process graph with all variants and their frequencies. A typified finding might read: a third of all orders pass through the price check twice. Process mining only sees what happens inside the system, though. Whatever happens by phone, by word of mouth or in an Excel list is missing from the log. That is why conversations with the people involved complement the system data. They explain why a case goes round the loop.
Classic methods from lean and quality management
If you want to go deeper or work in a QM environment, you will come across further tools. They complement the methods above, and each one answers its own question:
| Method | Answers the question | Useful when | Effort |
|---|---|---|---|
| SIPOC | Who delivers what to whom? (Supplier, Input, Process, Output, Customer) | You first need to scope a process before examining it | Low, one page in an hour |
| Swimlane diagram | Who does which step, and where does responsibility change hands? | You suspect the problems sit at handoffs between departments | Medium |
| Value stream mapping (full) | How do material and information flow, where do inventory and waiting build up? | Production and logistics with recurring workflows | High, several days with on-site measurements |
| Ishikawa (fishbone) diagram | Which causes could explain a known problem? | The symptom is clear, the cause is not | Low to medium, one workshop |
| 5 Whys | What lies behind the first explanation? | You want to trace a single weak point to its actual root cause | Low |
| SWOT analysis | What are the strengths and weaknesses of the process, and which outside factors affect it? | You are deciding whether to rebuild, outsource or keep a process | Low, one to two hours in a small group |
| Continuous improvement cycle (PDCA) | Did the action work, and what is the next step? | Findings should move into a continuous improvement process | Ongoing, short meetings at fixed intervals |
To get started, SIPOC as a scoping exercise before step 1 and the 5 Whys for each finding are enough. Full value stream mapping pays off mainly in production. For office and administrative processes the light variant is usually sufficient. The PDCA cycle (Plan, Do, Check, Act) belongs at the end of every analysis, so that findings turn into verified improvements.
Which process analysis tools you need
For most methods, a whiteboard and a spreadsheet are enough. A table with the columns step, role, system, duration and finding carries an entire weak-point analysis. Modeling tools for BPMN help when you share results with many people. For the mapping itself, meaning the many conversations, AI-led interviews are now an option.
How to conduct a process analysis in 5 steps
You conduct a process analysis in five steps: scope the process, map the as-is state, apply a method, resolve contradictions and derive actions. Each step builds on the one before.
Step 1: Select and scope the process, name the stakeholders
Start with one clearly bounded process. "Order processing from order intake to invoice" works, "our sales department" is too broad. Pick the process that grinds most often or ties up the most money. If you first need an overview of your processes, a process map helps.
Then name the relevant stakeholders. They include the person responsible for the process, everyone who performs individual steps and the areas before and after it. Often someone from IT belongs in the group too, because data from IT systems is needed. Also decide how you will measure success, for example by lead time or the number of follow-up questions.
Step 2: Map the as-is state
Talk to the people who execute the process every day, because they know the current workflow best. Which method fits, whether interview, workshop or observation, is compared in the guide on as-is process mapping.
Ask about the concrete last case: "Take the last order. What exactly did you do?" The last case is tangible and shows the workflow as it actually runs. The "typical case", by contrast, is often a smoothed summary.
Step 3: Apply the method
Choose the right method or combine several. Weak-point analysis as the base, with media-break analysis as a targeted second look, has proven itself. Back up every insight with evidence. "The handoff to manufacturing is a problem" is an assessment. "In 4 of 6 orders we examined, manufacturing had to ask for missing measurements, with an average delay of 2 days" is a finding.
Step 4: Resolve contradictions
If three people describe the same process differently, that is a valuable result. Maybe three variants of the process really do exist. Maybe one person knows something the others don't. Put the contradictions openly on the table and resolve them together with the people involved.
Step 5: Prioritize findings, derive actions and hand them to continuous improvement
Prioritize the findings by frequency and damage. An error that occurs daily and affects customers comes before a blemish that stays internal. Give each finding one action with an owner and a deadline.
Then hand the actions over to your continuous improvement process. After six to eight weeks, check whether the metric from step 1 has moved. Recurring, rule-based steps are candidates for process automation. Capture the improved workflow in a process description and add it to your process documentation. That way the change reaches everyday work.
Checklist before you start
- The process has a clear start and a clear end.
- One person is responsible for the analysis and has time for it.
- The stakeholders are named, including the areas before and after the process.
- There is a metric by which you will measure success later.
- The team knows what it is about and what happens to their statements.
- The works council is informed, if there is one.
- Time is set aside to implement the first actions.
Communicating a process analysis in your company
A process analysis succeeds when the team knows in advance what it is about, what happens to their statements and what comes next. People who know the purpose also talk about detours and workarounds.
Inform the team in advance
Announce the analysis before the first conversation takes place. A short message from management or the head of the department is enough. It answers four points: which process is being examined, why this one, who will be interviewed and how much time it takes per person.
An example of such a message: "Over the next three weeks we are taking a closer look at order processing, because our orders take four days on average until shipping. We will talk to everyone involved, about 20 minutes each. It is about the workflow, systems and handoffs. We will present the results to the team at the end of the month."
Clarify the purpose and how statements are handled
Say clearly that the analysis describes workflows and does not evaluate individual people. Explain who sees the results and in what form. Someone who knows that "I retype this every morning" will be read as a pointer to a media break is happy to say it.
Involve the works council
If there is a works council, inform it early; in Germany, Section 80(2) of the Works Constitution Act (BetrVG) gives it a right to timely information. If you use software for the interviews or the evaluation, co-determination under Section 87(1) no. 6 BetrVG usually applies. It covers technical systems designed to monitor employees' behavior or performance, and according to the Federal Labour Court (BAG) it is enough that a system is objectively capable of doing so. Process mining with personal log data and AI-led interviews typically fall under it. A short description of purpose, data and evaluation makes the conversation easier, as does the commitment that no individual performance or behavior will be assessed. That commitment does not replace co-determination; clarify the details with legal counsel where in doubt.
Share the results
Present the findings to the team before actions are decided. The people involved spot errors in the picture immediately and add what is missing. Afterward, show which actions follow and who owns them.
Process analysis example: order processing in wholesale
The following example is typified. It is composed of situations that occur in similar form at many wholesale businesses and does not describe any single company.
Starting point: A plumbing and heating wholesaler with around 60 employees. Orders take four working days on average from intake to shipping. The target is two days. The analysis covers order processing from receipt of the order to handover to the carrier.
Approach: Seven people from inside sales, accounting, warehouse and shipping are interviewed, about 20 minutes each. On top of that, ten real orders from the previous month are traced. Methods: weak-point analysis, value stream analysis light and media-break analysis.
The individual steps and findings:
| Step | Who | System | Finding |
|---|---|---|---|
| Order intake | Inside sales | Inbox, phone, ERP | 40% of orders arrive as PDFs by email and are typed into the ERP by hand (media break) |
| Price check | Inside sales | ERP, Excel list | Special prices for key accounts exist only in an Excel list maintained by one colleague |
| Availability check | Inside sales, warehouse | ERP, phone | ERP stock levels for small parts are off, so inside sales calls the warehouse |
| Credit check | Accounting | ERP | Orders above the credit limit wait one day on average for approval, and only one person may approve |
| Order confirmation | Inside sales | ERP | No issues |
| Picking | Warehouse | Paper list | Follow-up questions on special items, because the item name on the list is abbreviated |
| Shipping | Shipping | Carrier portal | Address data is transferred from the ERP to the portal by hand |
The value stream analysis shows that an order is in active processing for around 45 minutes on average. For the rest of the four days it waits, longest for the credit approval and the reply from the warehouse.
Three prioritized actions:
- Reorganize credit approval: up to a fixed amount above the limit, inside sales approves itself. Above that, accounting decides, with a named deputy. This addresses the longest idle time.
- Move special prices into the ERP: the Excel list is transferred once, and afterward there is only one source. This reduces errors and removes the dependence on one person.
- Stock reconciliation for small parts: a monthly spot-check inventory for the twenty most frequent small parts, so inside sales can trust the ERP stock again.
Email orders and the carrier portal go into the second round as candidates for automation. After eight weeks, the team measures lead time again on ten orders.
Common mistakes in process analysis
Mistake 1: Analyzing the to-be instead of the as-is
This is the most common mistake. What gets analyzed is the procedure from the QM manual, which describes how the process was intended. In everyday work the workflow has often evolved. The colleague who did an intermediate step has left. The new system made two steps obsolete and three new ones necessary. So analyze the workflow as it runs today.
Mistake 2: Only asking management
The department head knows the process from a bird's-eye view. The tricks, workarounds and shortcuts are known mainly to the people who carry it out every day. For example, the clerk maintains her own side spreadsheet because the ERP can't handle tiered pricing. Or the warehouse worker books goods receipts in the afternoon because the trucks arrive in the morning. Many insights live in these details, so it pays to ask at every level.
Mistake 3: Taking one person's account as the truth
Often the most experienced employee describes the process, and his version becomes the official one. Yet even the most experienced person mainly sees his own slice. Sometimes he describes how he thinks it should be done. Interview several people along the process and compare their accounts. Contradictions are often the most valuable find of the entire analysis.
Mistake 4: Looking only at system data
Metrics from the ERP or a process mining report show that a case is waiting. Why it waits is rarely in the system. The Excel list next to the ERP, the call to the warehouse and the approval given by word of mouth appear in no log. So always combine data with conversations.
Mistake 5: Analyzing without consequences
An analysis raises the expectation that something will change, because employees have put time and knowledge into it. When something visibly follows, they are happy to take part in the next round of interviews too. So plan the implementation from the start, even if it's just two small actions.
How wissa supports process analysis
The biggest effort in an analysis is the collecting and cross-checking: conducting many interviews, comparing accounts, finding contradictions, backing up findings. wissa.ai takes over a large part of this, while the assessment and the decisions stay with you.
An AI interviews your employees in a chat, around 15 to 20 minutes per conversation and whenever it suits them. How this works in detail is covered in the guide on AI process documentation. Following the snowball principle, it follows the knowledge from person to person. If someone mentions "that gets sorted out by our colleague in purchasing," wissa.ai suggests inviting that colleague next.
The conversations produce insights with evidence:
- Media breaks, meaning points where information is transferred between systems by hand, together with the statement it was derived from.
- Duplicate work, when two people independently describe maintaining the same data.
- Knowledge risks, meaning process steps that only a single person has mastered. That is the bus factor, each with its source.
- Contradictions, when two employees describe the same workflow differently. wissa.ai places both statements side by side so you can clear them up together.
Every statement is traceable, and every finding has a source. After every interview the documentation is updated and shows the changes against the previous version. The page on our process documentation software shows what else it does.
wissa.ai is hosted in Germany, a data processing agreement under Art. 28 GDPR is included, and the interviews describe workflows, roles and systems. A free trial package to start with (10 credits, once per company, terms) usually covers a first interview, and interviewees don't need an account of their own. Try one interview for free
FAQ
What is the goal of a process analysis?
The goal of a process analysis is an evidence-based foundation for improvements. It shows where a workflow loses time, where errors and follow-up questions arise, which handoffs snag and which steps depend on a single person. The result is a prioritized list of findings with cause, evidence and action, on which you base your decision about what to change or automate.
Which steps are part of a process analysis?
A process analysis has five steps: scope the process and name the stakeholders, map the as-is state with the people who do the work, apply a suitable method, resolve contradictions between accounts and prioritize the findings. From the most important findings you derive actions with an owner and a deadline and hand them over to the continuous improvement process.
What is the difference between process mapping and process analysis?
Process mapping documents how a workflow actually runs: who does what, in what order, with which tools. Process analysis evaluates that material and identifies weaknesses, risks and starting points for improvement. Thorough mapping is the foundation of every reliable analysis.
How do process analysis and process mining differ?
Process mining is one method of process analysis that reconstructs workflows from the log data of IT systems. It reliably shows which paths cases take in the system and where they wait. What happens outside the systems, such as agreements made by phone or Excel lists, it does not capture. A complete process analysis therefore combines system data with conversations.
Which process analysis method is the right one to start with?
For most companies, weak-point analysis, complemented by media-break analysis. Both can be applied without prior training and quickly produce concrete findings. Value stream and handoff analysis are worthwhile as a second step, when you want to understand idle times or handoff problems in more detail.
How long does a process analysis take?
For a clearly scoped process with five to eight people involved, the mapping takes about one to two weeks, spread over several short sessions. The analysis itself takes two to three days. With AI-led interviews, it's mainly the mapping that gets shorter, because conversations happen in parallel and without scheduling.
Who should I interview for the process analysis?
Above all, the people who execute the process every day, and several of them along the entire workflow. Management provides the frame, and the important details live in the operational work. Include the areas before and after the process too, because that is where the handoffs are.
How do I inform the team about a process analysis?
Inform the team before the first conversation with a short message: which process is being examined, why, who will be interviewed and how much time it takes. Say clearly that the analysis is about workflows and systems and does not evaluate individual people. Involve the works council early and present the results to the team before actions are decided.
What do I do when employees' accounts contradict each other?
Take contradictions seriously as a result: either several process variants exist side by side, or a shared agreement is missing. Put the accounts next to each other and resolve them together with the people involved. That is often where the most effective improvements come from.
Sources
- Rother, M.; Shook, J.: Learning to See. Value Stream Mapping to Add Value and Eliminate Muda. Lean Enterprise Institute, 1998
- Ohno, T.: Toyota Production System. Beyond Large-Scale Production. Productivity Press, 1988
- van der Aalst, W.: Process Mining. Data Science in Action. 2nd edition, Springer, 2016
- Deming, W. E.: Out of the Crisis. MIT Press, 1986
- German Works Constitution Act (Betriebsverfassungsgesetz, BetrVG), Section 80(2) and Section 87(1) no. 6