Symptoms
What leaders usually see
- Global design, local workarounds
- Unclear category, country, shared-service and business ownership
- Too much escalation for decisions that should be designed into the model
Executive search path
Procurement Operating Model Design for complex execution across multiple business units.
Procurement operating models break when roles, governance and decision rights are described but not made executable.
Diagnosis
What I diagnose
- Accountability gaps
- Governance layers that slow value
- Operating logic required to move work across entities
Output
What you leave with
A pragmatic blueprint for ownership, decision flow and governance that can be executed.
Definition
What a procurement operating model actually is
A procurement operating model is the working system that turns a strategy and an org chart into repeatable execution. It answers four questions a structure diagram never does. Who is allowed to decide. On what. Within which limits. And what happens when the answer is unclear.
Concretely, it defines the mandate procurement holds, how ownership is split across category, supplier, country and business unit, which decisions are designed into the model rather than escalated, and the rhythm by which value is governed. When those are explicit, work moves across entities without a meeting to authorise every step. When they are implicit, every non-standard case becomes an escalation.
Two expensive confusions
It is not an org chart, and it is not a procurement strategy
Shows reporting lines. It says nothing about decision rights, handoffs or governance cadence. Two organisations with identical charts can execute completely differently.
Sets direction: categories to prioritise, savings ambition, supplier posture, digital agenda. A strategy without an operating model is a set of intentions with no mechanism to carry them.
The layer in between. It is the one most transformations skip, and the one where value is actually won or lost.
Schaubild
The eight components of an executable operating model
A model is executable when all eight are defined together. The failure pattern is almost never a missing component. It is components designed separately.
01MandateWhat procurement is authorised to own and decide, and where its authority ends.
02Organisational structureHow teams are grouped, and whether that grouping serves the mandate or tradition.
03Decision rightsWho decides, who is consulted, who is informed, at what thresholds.
04GovernanceBoards, gates and cadence that steer value without taxing speed.
05Category and supplier ownershipClear accountability where central and local interests compete.
06S2P and P2P processThe flows the model runs through, including every handoff where ownership changes.
07Data and technologyThe ERP, S2P suite and master data that enable the model or quietly overrule it.
08Performance and rhythmMetrics and reviews that keep the model alive after the design workshop.
Designed together, these eight behave as one system. Designed separately, a governance model assumes decision rights the systems do not enforce, and category ownership loses to the escalation culture.
The wrong first question
Centralised, decentralised, center-led, hybrid
Most operating-model debates collapse into one question: centralise or decentralise. It is the wrong question to lead with.
The label is not the decision. A center-led model with unclear decision rights behaves as decentralised in every contested case. What determines behaviour is not the name on the chart. It is where authority sits when two legitimate interests disagree.
Failure pattern
Where operating models break
- Global design on paper, local workarounds in practice.
- Unclear category, country, shared-service and business ownership, so accountability lands nowhere.
- Too much escalation for decisions that should have been designed into the model.
- Governance layers that add sign-offs faster than they add value.
- Systems that enforce a different model than the one leadership agreed.
Each of these is a design gap, not a discipline problem. That is why more training and more effort rarely fix them.
Made concrete
Decision rights, on one decision at a time
Decision rights are the component that most often reads well and works badly. Making them concrete means naming, for a given decision type and threshold, exactly who decides and who is consulted. Pick a decision below to see the shape an executable answer takes.
A strategic category, above the agreed value threshold.
- Decides
- Category owner, within the agreed sourcing strategy.
- Consulted
- Business unit, on requirements and service impact.
- Informed
- Procurement governance, reviewing exceptions only.
- Below threshold
- Same decision, delegated, never escalated.
An existing contract reaching its renewal window.
- Decides
- Category owner, if commercial terms stay inside the agreed band.
- Consulted
- Legal and the budget owner, on term changes and liability.
- Informed
- The business unit using the contract.
- Outside the band
- One named escalation step, with a decision date attached.
A site needs something the central framework does not cover.
- Decides
- Local procurement, inside a defined exception envelope.
- Consulted
- Category owner, so the exception feeds back into the strategy.
- Informed
- Governance, through the exception log rather than a meeting.
- If exceptions repeat
- The framework is wrong, not the site. Redesign, do not police.
A change to the system that enforces the process.
- Decides
- Process owner together with IT, against the agreed operating model.
- Consulted
- Category, finance and the affected business units.
- Informed
- Everyone whose handoff changes, before the change lands.
- The trap
- Configuring a system before the decision rights are settled freezes the ambiguity.
The point is not this specific split. It is that the split is decided once, in the model, instead of re-litigated in every case.
Complexity
Multi-entity and shared-service logic
Complexity rises sharply the moment work crosses legal entities, countries or a shared-service centre. Ownership that was clear inside one business becomes contested across several. A shared-service centre introduces a handoff where accountability can quietly disappear.
An executable multi-entity model makes three things explicit. Which decisions are reserved centrally and which are held locally. How work and data pass between entities and the service centre without losing an owner. And where governance sits when local and central interests legitimately conflict. Without that, the service centre becomes a place work goes to wait rather than a place it moves through.
System reality
ERP, S/4HANA, AI and automation
An operating model does not live in a document. It lives in the systems that run procurement every day. ERP and S2P tooling either enforce the agreed decision rights and handoffs, or they silently enforce a different model.
An S/4HANA programme hard-codes ownership, approval flows and master-data logic. If the operating model is unresolved when it lands, the system freezes the ambiguity into place. The same holds for AI. Automating a process before the decision rights behind it are clear does not remove the ambiguity. It scales it. Readiness for AI in procurement is, in large part, operating-model readiness: clear ownership, clean master data, and decisions defined well enough that a system can act on them.
Questions leaders ask first
Before you commission anything
Is a procurement operating model the same as a target operating model?
A target operating model is the intended future-state design. The operating model is how that design actually runs once decision rights, governance, process and systems are made executable. A TOM that stops at the design layer is exactly where most value is lost.
Do we need to choose centralised or decentralised first?
No. The leverage-versus-fit choice matters, but it is not where behaviour is decided. Decision rights are. A model with clear decision rights behaves predictably regardless of the label. A model without them behaves as decentralised in every contested case.
Our roles are already documented. Why does execution still break?
Documented roles describe accountability. They do not enforce it. Execution breaks at the handoffs, thresholds and contested decisions the documentation never resolved, and that the systems quietly decide instead.
Should we fix the operating model before or during an S/4HANA rollout?
Before, wherever possible. A systems programme hard-codes ownership and approval flows. If the operating model is unresolved when it lands, the ambiguity becomes permanent and far more expensive to change afterwards.
Where does this start?
With one senior diagnosis of where your intended model and your executed model diverge, before any new program, tool or consulting layer.
Proof
Proof before methodology.
Use the proof stack to reduce buying risk, then start with one senior diagnosis before adding another program, tool, workshop or consulting layer.
Open Proof