What process analysis really means in the DACH Mittelstand
To the point: Process analysis is the systematic examination of a business process along time, quality, cost, and handover dimensions, performed to enable defensible decisions about change. Done well, it shortens debate. Done badly, it generates slides that no one acts on.
A south German kitchen manufacturer, around €80M revenue and 320 employees, came to us with a deceptively simple question: "Why does it take thirteen business days to confirm an order?" The textbook answer would have been a full business process analysis with BPMN modelling. We flipped the question and asked first whether anyone in the organisation actually knew how many handovers the order confirmation passed through. That is where process analysis really starts — with the question, not the tool.
In the Mittelstand, process analysis is not an academic exercise. It is a decision-support tool. It reveals where time, money, and attention are lost between order intake and delivery — and supplies the evidence base for investments in people, ERP, or automation. From our experience across more than 50 mid-market projects in the DACH region, the real bottleneck is not method but sustainment. The pattern is consistent with Tier-A research — Bitkom's Digitalisation of Business 2025 finds 64% of companies struggling with process documentation. Method is rarely the missing piece.
Academic and vendor literature describe business process analysis as a sub-discipline of business process management. IBM Think's "Business Process Analysis" overview defines BPA as the systematic examination of existing processes to identify bottlenecks, inefficiencies, and improvement areas. That framing is correct, but incomplete for mid-market reality. In the DACH Mittelstand, an as-is process analysis is almost always a preparatory step for a concrete downstream investment — ERP selection, MES rollout, document management, or a structural reorganisation. Treated as an end in itself, it burns budget.
We therefore draw a sharp boundary. Process management is the standing governance discipline. Process optimisation is the execution phase. Process analysis is the diagnostic step that connects them. This sequence sounds academic but matters in projects because it determines the level of detail required. More on our wider approach in our overview of process management at Dreher Consulting and in the role definition process owner.
How we approach process analysis methodically
To the point: We work in four lean steps because the Mittelstand does not tolerate corporate-style overhead. Target clarification → as-is recording → analysis with three core methods → measure derivation with priorities.
Step one is target clarification with the management board: is the goal cost reduction, throughput time, quality, or preparation for an ERP selection? Without this clarification, every analysis becomes busywork without a use case.
Step two is the as-is recording. We sit down with the process owners and the operating teams, sketch the flow on A3 paper or in a simple diagramming tool, and reconcile it with actual ERP transactional data. The first cracks usually appear here — processes are almost always leaner on paper than in real life. Where data volumes allow, we add process mining; the Everest Group "Process Mining State of the Market 2025" quantifies the waste-reduction effect of data-driven techniques at 37%. We use these tools selectively, not reflexively.
Step three is the actual analysis. SIPOC for the outer edges, 5-Why for root causes, value stream mapping for handovers. From our experience three methods are almost always sufficient in the Mittelstand — additional techniques produce more slides, not more insight. The trap that most process-analysis-method discussions miss is that techniques accumulate but rarely substitute one another.
Step four is the measure derivation with priorities. The Mittelstand needs a list of five to eight actions, not eighty. Those five to eight must be sorted by impact versus effort, with named owners and a realistic window of six to twelve months. A structured improvement cycle (PDCA) and a clear definition of process excellence both help here — both are wiki entries in preparation.
Between these four steps lies a discipline that is rarely discussed: active omission. We typically cut two-thirds of the originally requested depth because it does not influence any decision. A process analysis that documents everything documents nothing usable in the end. Reduction is therefore as important as collection — and considerably harder to facilitate. Our broader methodology is laid out in our consulting approach.
Practical example: south German kitchen manufacturer, 320 employees
To the point: A south German kitchen manufacturer (€80M revenue, 320 employees) reduced order-confirmation lead time from 13 to 6 business days over nine months — a 54% reduction. Effort: 28 consulting days over ten weeks. The most expensive measure was organisational, not technical.
Back to the kitchen manufacturer mentioned at the start. Working with the managing director and six Process Owners, we mapped the order-handling flow from the configurator through to shipping notification. Seven business days were lost to back-and-forth between Sales, Engineering, and Production Planning alone — three handovers nobody owned. After eight weeks of analysis we had a seven-point action list. Three actions were organisational (clear Process Owner roles, a shared configuration standard, an escalation rule); four were ERP-related.
Over the following nine months, order-confirmation lead time fell from 13 to 6 business days — a 54% reduction, with no new hires. Effort for the pure process-analysis phase: roughly 28 consulting days spread over ten weeks. The most expensive measure was organisational, not technical — a pattern we have seen repeat across the DACH Mittelstand.
Common mistakes in mid-market process analysis
To the point: Five mistakes recur across our 50+ Mittelstand projects — and every one of them can be prevented in the scoping conversation, not in the analysis itself.
- Analysis without a target picture. Starting without a clear question produces data no one reads. The ifo Institute study "Costs of Bureaucracy" (November 2024) estimates Germany's bureaucratic burden at up to 146 billion euros in lost economic output — a portion of that comes from precisely such purposeless data gathering.
- Too many methods in parallel. SWOT, Ishikawa, BPMN, process mining and SIPOC in the same engagement. Participants lose the thread and management loses confidence.
- No process owners. Without named owners every measure remains a suggestion. The role is described in our process owner wiki entry.
- Neglected data hygiene. An analysis on stale ERP data is the most expensive form of attractive slideware.
- No follow-on plan. Not knowing whether the analysis feeds an ERP selection, a headcount decision, or an automation initiative produces a list, not a plan. Our ERP advisory practice is built around exactly this connection.
Our take: Three of these five are governance mistakes, not method mistakes. Anyone who ignores that is buying methodology against a leadership problem — and that never works. In our projects, consultants are less method-suppliers than sparring partners for the managing directors.
Frequently Asked Questions
Process analysis is the diagnostic phase in which the as-is process is recorded, bottlenecks identified and root causes derived. It ends with a prioritised action list. Process optimisation is the subsequent implementation phase in which these actions are realised technically and organisationally. The two belong together methodologically but differ sharply in effort, participation and tool mix. From our experience in the DACH Mittelstand, the clean separation matters because it gives management the chance to make a real investment decision after the analysis. Mixing the two risks implementing measures whose impact has never been understood — the single most common cause of the post-analysis fade described above.
For the DACH Mittelstand, three to four methods are sufficient in the vast majority of cases: SIPOC to frame the outer edges of a process, a simple value stream or flow diagram for the handovers, 5-Why for root cause analysis, and selectively process mining where the ERP system delivers reliable event logs. BPMN 2.0 only where downstream automation actually requires the notation standard. From our experience, every additional method block adds more complexity than insight — an observation echoed academically by the Springer "Process Mining Handbook" (van der Aalst et al.).
Almost always. Selecting a new ERP system without knowing the as-is state of the core processes is the most expensive form of hope. We recommend a lean process analysis of four to eight weeks ahead of requirements documentation — it provides the language in which the requirements must be written and protects against six-figure customisation costs. The BMWE programme "Mittelstand-Digital" (formerly BMWK) offers free initial advisory for SMEs that can support this step. In our projects, mid-market process analysis is almost never isolated — it is the run-up to a follow-on decision. More in our digitalisation services overview.
Next steps
If you are considering a process analysis, we recommend a 30-minute initial conversation. We test whether a lean value stream workshop is enough, whether a companion process mining angle adds value, or whether the analysis belongs inside a larger ERP decision. No sales pitch — a focused review of your current situation.
