What a Business Process Owner actually does in the Mittelstand
To the point: A Business Process Owner (BPO) is the named person with decision and budget authority for an end-to-end business process. They own the goals, the KPIs, the documentation, and continuous improvement. ISO 9001:2015 (clauses 4.4 and 5.3) makes such an assignment a normative requirement. In the DACH Mittelstand the role is frequently delegated informally — and that is exactly where the friction starts.
When was the last time someone in your company raised their hand — with a name, a budget, and decision authority — for an end-to-end process? In a project with a south German machine builder (320 employees) we watched that exact question land in eight seconds of silence. That is where the discussion about the Business Process Owner role really starts — not in the textbook, but in the practice of the Mittelstand.
In corporate environments the Business Process Owner is a senior governance role with explicit time release. In the Mittelstand the responsibility falls on a department head in more than half of cases — without dedicated time, without budget authority, without a mandate that crosses silo lines. ISO 9001:2015 closes that gap normatively in clauses 4.4 and 5.3: top management must assign and communicate responsibility and authority for achieving process outcomes.
In practice a Business Process Owner is responsible for a clearly delimited end-to-end process — Order-to-Cash, Source-to-Pay, or Hire-to-Retire. They define the process goal, agree on KPIs with management, and make sure the process works across departmental boundaries. The ABPMP CBOK formulates it canonically: the BPO "defines mission, vision, tactics, goals, selects the KPIs and monitors process performance against them".
In a German family-run business with 180 employees the reality looks different. The person who "owns" the process is often simultaneously head of sales, member of the executive committee, and the technical contact for three customer groups. The Bitkom survey from January 2026 puts the consequence plainly: roughly half of German mid-market firms still steer processes entirely manually. That is exactly where the designated role is missing. Closely related — and in the lived Mittelstand reality often filled by the same person — is the operational Process Owner; the BPO carries the additional strategic and budgetary bracket.
Our take: The role should not be set up as a full-time function but as a formally named part-time function with reserved time budget and an explicit escalation line to management. Anything else stays folklore.
Duties and competences — methodically considered
To the point: The duties compress into five non-negotiables — goal definition, KPI authority, documentation ownership, interface clarification, and continuous improvement. Methodically anchored in PDCA, BPMN 2.0, and the APQC Process Classification Framework.
First: goal definition. The BPO formulates the business goal of the process in one sentence and anchors it with management. If you cannot state the goal in one sentence, you do not have a process — you have a collection of activities.
Second: KPI authority. They select two to four lead indicators — lead time, first-pass yield, complaint rate, time-to-quote — and report them monthly. More than four KPIs dilute the steering effect; fewer than two make the process invisible to management.
Third: documentation ownership. Modelling in BPMN 2.0, maintenance in a repository, version state traceable at any time. In the Mittelstand a simple diagramming tool plus a versioning system is usually enough — what matters is the maintenance, not the tool.
Fourth: interface clarification. This is where most projects fail. The BPO negotiates handovers with the owners of adjacent processes, documents them, and makes them measurable. Across 50+ projects we see the same pattern: three to five clean handovers matter more than eight detailed sub-processes.
Fifth: continuous improvement via the PDCA cycle — not as an annual ritual but as a monthly 60-minute routine. As a taxonomy anchor we use the APQC Process Classification Framework. It provides an unambiguous label for every end-to-end process category and makes it clear what exactly the BPO is responsible for.
Our take: Competences follow from duties — not the other way round. First the duty, then the build-up of the necessary competence.
The BPO in ERP selection: why a requirements specification fails without one
To the point: In ERP selection projects the Business Process Owner is the only person who can defend the requirements specification on its merits. Without named owners, requirements get written from an IT perspective — and fall over in acceptance with the business units.
In ERP selection projects in the Mittelstand we keep seeing the same pattern: a requirements specification gets written by an internal IT project lead together with external consultants. It contains 800 functional requirements. At the demo the board asks: "Who actually signed this off?" Silence. That is the gap a named BPO closes.
Our consulting approach therefore intervenes before vendor selection: KPIs and business logic are fixed with the BPOs of the affected end-to-end processes. This sequence reduces project risk by up to 30 percent based on our experience. The DSAG Investment Report 2026 confirms it: process modernisation is the central investment driver in the DACH region.
In a project with a technical-component manufacturer (260 employees) we named three BPOs before the vendor evaluation began — for Order-to-Cash, for Source-to-Pay, and for Hire-to-Retire. Each of the three was charged with owning KPIs, target model, and acceptance criteria for their process. Vendor demos were tested against those three target models — not against an 800-point list. The selection process shortened by six weeks, and the customising estimate from the chosen vendor came in 22 percent below the mean for comparable projects.
Process Owner vs. Department Head — the time-allocation dilemma
To the point: Standard literature recommends that a Process Owner is released for up to 25 percent of their working time. In Mittelstand reality that target is effectively never met. This is the lever we negotiate honestly upfront.
The boundary between Process Owner and department head is clean in theory and blurry in practice. The department head owns a team and its operational output. The Process Owner owns an end-to-end process that spans multiple teams. Bundling both in one person requires clarity on which role the person is acting in at any moment — and which role takes precedence when goals conflict.
In the Mittelstand this dual role is the norm, not the exception. The honest way to handle it is not to define the role away but to fix the time allocation in writing and have management underwrite it. In our projects, 10 to 20 percent of working time is usually sufficient for the ownership function — provided the allocation is binding, calendar-effective, and protected by a deputy arrangement for the department.
If the reserved time falls below 10 percent, the role should not be assigned. It will be crowded out by the first operational crisis, the process will lose its owner, and investments in methodology and documentation will evaporate. That is the most common failure pattern we see in process management projects.
Our take: Negotiate the time allocation first — not the job description. A written commitment from management for 15 percent of time is worth more than a 12-page role profile without a mandate.
Practical example: family-run component manufacturer, around 280 employees
To the point: A family-run manufacturer of mechanical components (around 280 employees) introduced formal BPO roles for three end-to-end processes before an ERP changeover. The managing owner negotiated a binding time allocation between 12 and 18 percent with each BPO. Result after nine months: the customising estimate from the selected ERP came in 22 percent below industry mean; requirements specification iterations dropped from a typical three rounds to one.
The manufacturer was facing an ERP changeover. An internal pre-selection with 800 requirements had taken six months and had collapsed at three handovers between IT and the business units in acceptance. The diagnosis: nobody was technically legitimised to defend the requirements specification. In the first management session we delimited three end-to-end processes — Order-to-Cash, Source-to-Pay, and Plan-to-Produce — and identified a BPO candidate for each.
The managing owner negotiated a binding time allocation with each candidate in one-on-one meetings — 18 percent for Order-to-Cash (highest complexity, heavy variant configuration), 15 percent for Source-to-Pay, 12 percent for Plan-to-Produce. Each allocation was fixed in the calendar and protected by a deputy arrangement for the respective department. The three BPOs defined process goal, three to four KPIs, and a target model on a single A3 sheet per process within six weeks.
Only then was the requirements specification written — against the respective target model, with the BPOs as the technical owners of every requirement. Vendor demos were run against those three target models, not against a feature list. Nine months later, three findings were measurable. First: the customising estimate from the selected ERP came in 22 percent below the industry mean for comparable projects. Second: requirements specification iterations dropped from a typical three rounds to one — the technical defence by the BPOs held. Third, and most important to management: business-unit acceptance of the chosen solution was there from day one because the named BPOs had co-signed the selection.
Effort for role introduction and accompaniment came in at roughly 24 consulting days over twelve weeks. The most expensive measure was organisational — the owner's negotiation of time allocations — not methodological.
Frequently Asked Questions
The Business Process Owner is strategically responsible for the end-to-end process — goal, KPIs, target model, continuous improvement. The Process Manager steers operational execution day-to-day, coordinates staff, and monitors live performance against agreed targets. In corporations these are two people. In the Mittelstand both roles are often covered by one person — which only works if the time allocation for the ownership function is formally protected.
ISO 9001:2015 does not name the term Business Process Owner literally, but clause 4.4.1(e) requires the assignment of responsibilities and authorities for QMS processes. Clause 5.3 obliges top management to assign and communicate responsibility and authority for achieving process outcomes. That is the normative basis for a named BPO role — even though ISO uses a different label.
The orientation value established in BPM literature is up to 25 percent of working time. In DACH Mittelstand practice this is rarely achieved. A realistic range is 10 to 20 percent, depending on process complexity and maturity. What matters is not the exact figure but the written commitment from management. Below 10 percent the role should not be assigned.
Across 50+ projects we see four core competences: first, deep technical understanding of the end-to-end process they own; second, analytical capability for defining and interpreting KPIs; third, negotiation and conflict skills for clarifying handovers across departmental boundaries; fourth, a basic grasp of the IT landscape, without needing to be an IT expert. Method knowledge in BPMN 2.0 and PDCA is helpful but learnable.
The BPOs of the affected end-to-end processes are named before the requirements specification is written. They define the process goal, the KPIs, and the target model. Only on that basis are functional requirements derived. During vendor evaluation the BPOs act as technical gatekeepers: they assess demos against their own KPIs, check fit against the target process, and own acceptance. This sequence reduces project risk by up to 30 percent based on our experience.
Next steps
If you want to set up the Business Process Owner role effectively, we recommend three concrete steps. First: delimit two to four end-to-end processes cleanly using the APQC PCF as anchor. Second: identify a candidate for each process — preferably from the department that owns the process outcome most strongly. Third: negotiate the time allocation in writing with management, calendar-effective, with a deputy arrangement. For the three steps together we recommend a 30-minute initial conversation — no sales pitch, an honest assessment instead of method overhead.
