Insights / Procurement Transformation
Procurement & S2P · Organisation and ownership
Procurement Operating Model: How to Define Roles, Ownership and Delivery
Decide how procurement should be organised to deliver the strategy: who makes decisions, who does the work and how the functions work together.
By Denova · Procurement & S2P
At a glance
Make ownership work
- Choose the right balanceDecide which responsibilities belong centrally and locally.
- Separate decisions from deliveryName the authority, contributors and people doing the work.
- Design the hand-offsAgree escalation, review and support arrangements.
On this page
01 · Start with the work
What a procurement operating model needs to define
A procurement operating model describes how people, decision rights, processes, systems and governance work together to deliver procurement outcomes. It covers the relationship between procurement, the business, finance, legal and IT, as well as any external support.
An organisation chart shows reporting lines. The operating model must also explain who can approve a purchase, who resolves an incomplete supplier request, who owns the process and who acts when performance falls short.
The current model is how work happens today, including informal hand-offs and workarounds. A procurement target operating model is the agreed future arrangement needed to deliver the strategy. It should be achievable with the skills, capacity, technology and authority the organisation can provide.
Start with the outcomes agreed in your procurement transformation strategy. Then use evidence from the procurement capability assessment to identify gaps between current and required delivery. Changing reporting lines alone will not repair unclear inputs or an unsupported approval workflow.
For example, reducing unnecessary executive approvals requires explicit delegated authority, a reliable routing process and exception handling. Moving every buyer into one team may or may not help. Test the proposed arrangement against the work it must perform.
02 · Decide what belongs where
Compare centralised, decentralised and centre-led structures
These structures describe where procurement authority and activity sit. They do not determine whether delivery must be internal or external. Different categories, entities and processes may need different arrangements within one organisation.
Structure choice
Centralised
A central procurement function controls most procurement policy, category decisions and delivery. Business teams still define requirements and retain the approvals assigned to them.
Potential fit: Useful where common requirements, consolidated spend or scarce specialist skills favour a shared approach. It can improve consistency and make ownership easier to locate.
Design trade-off: A central queue can become remote from local needs or slow routine work. Define service routes, local input, authority limits and capacity before consolidating activity.
Structure choice
Decentralised
Business units or regions hold more procurement responsibility and carry out their own activity, within applicable corporate controls.
Potential fit: Useful where markets, requirements or operating conditions differ materially and local teams need informed decisions close to the work.
Design trade-off: Separate teams may duplicate effort, fragment supplier information or apply inconsistent practices. Agree minimum controls, reporting definitions and routes for sharing specialist expertise.
Structure choice
Centre-led
A central team sets common policy, standards, selected category strategies and shared capabilities; local teams deliver agreed activities within those boundaries.
Potential fit: Useful where the business needs both common controls and local responsiveness. The centre might manage strategic suppliers while local teams handle routine demand.
Design trade-off: Ambiguous boundaries can create two approval chains or decisions that nobody owns. State which decisions are reserved centrally, delegated locally or escalated, including who resolves a disagreement.
Make the choice specific
Allocate responsibilities by category and process
Compare spend concentration, local variation, supplier risk, transaction volumes, specialist skills and system coverage. Ask where a common decision adds value and where it only adds delay.
Illustrative centre-led arrangement: a central category team agrees a group framework; local buyers order against it within their authority; finance retains budget controls; a shared operations team maintains supplier records. New requirements outside the framework follow an explicit exception route. This is a design example, not a universal recommendation.
Document these boundaries in a service catalogue: what procurement provides, for whom, through which route, with which required inputs and exclusions. Confirm cover for smaller entities and peak periods rather than assuming the organisation chart creates sufficient capacity.
03 · Be explicit about authority
Separate accountability, approval and execution
An accountable owner answers for an outcome and makes or obtains the necessary decision. A delivery role performs the agreed work. Contributors provide requirements, specialist advice or evidence. One person may hold several roles, but the distinction should remain visible.
Build the decision-rights map around actual decisions, not broad labels such as “owns procurement”. State the decision, scope, authority limit, required evidence, consulted roles, escalation route and record of approval.
- Procurement: define sourcing routes, commercial evaluation and supplier-management responsibilities within the organisation’s delegations.
- Finance and budget holders: distinguish affordability, budget approval, authority to commit spend and payment controls. Completing a procurement process does not itself authorise expenditure.
- Legal: define review triggers and who can approve a legal deviation or advise on its acceptance. Legal review and authority to sign a contract are separate decisions.
- IT and relevant control owners: specify security, access, architecture and integration requirements, and who can authorise a system change or accept an exception.
Use the organisation’s approved delegations and control requirements to settle these boundaries. A supplier coordinator or external specialist should not acquire spending, legal or risk-acceptance authority simply because they operate the workflow. Record any permitted delegation explicitly, including limits and supervision.
04 · Join the functions together
Give the process an owner and each hand-off a definition
A process owner maintains the end-to-end design, measures, documentation and improvement priorities. This role needs the authority to convene the functions and escalate unresolved conflicts. It does not replace finance, legal or IT approval authorities. For supplier onboarding, identify who owns the journey from a valid request to a usable supplier record. Then define each hand-off:- Entry: what information and evidence must the requester provide?
- Acceptance: how does the next team confirm that the request is complete?
- Decision: which review is required, who performs it and where is the result recorded?
- Exception: what happens when information is missing, reviewers disagree or the system fails?
- Completion: who confirms the record is ready and tells the requester what happens next?
Use the procurement change management guide to turn agreed responsibilities into role-specific communications, training and ongoing adoption support.
05 · Adapt this map
An illustrative responsibility map for procurement delivery
The cards below show one possible allocation for an indirect-procurement environment. Adapt the roles, approval limits and control requirements to your organisation. Each card separates the decision owner from contributors and delivery; it is not a universal authority schedule.
Where several approvals are required, record them as separate decisions rather than making everyone jointly accountable for the same step. Add named role-holders, deputies and escalation details to the agreed version.
Responsibility 01
Select the sourcing route
Decision owner: Procurement authority designated for the category and value.
Contributors: Business requester, category lead, finance and relevant specialists.
Delivery role: A buyer or agreed delivery team prepares options and runs the approved route.
Evidence and boundary: Record the route, rationale and any approved exception.
Responsibility 02
Authorise the financial commitment
Decision owner: Budget holder or financial delegate with the required authority.
Contributors: Finance, business owner and procurement.
Delivery role: The requester or operations team assembles the evidence and routes approval.
Evidence and boundary: Check the limit and evidence before commitment; preparation is not approval.
Responsibility 03
Approve a contract deviation
Decision owner: The client authority specified for that legal or risk decision.
Contributors: Legal, commercial owner and relevant risk specialists.
Delivery role: Procurement or contract support coordinates review and records the decision.
Evidence and boundary: Escalate outside the approved playbook; use the separately authorised signatory for execution.
Responsibility 04
Approve technology and access requirements
Decision owner: The designated client IT or security control owner for the requirement.
Contributors: Business owner, procurement, data owners and supplier technical contacts.
Delivery role: IT or authorised specialists gather evidence, test requirements and implement approved access.
Evidence and boundary: Document required clearances and unresolved exceptions before activation.
Responsibility 05
Maintain the supplier-onboarding process
Decision owner: The named client process owner.
Contributors: Procurement operations, finance, legal, IT and other relevant control owners.
Delivery role: An internal team, embedded specialist or agreed managed service operates defined steps.
Evidence and boundary: Changes to the process must preserve the separate functional approvals.
Responsibility 06
Agree supplier performance actions
Decision owner: The designated business or supplier relationship owner within their authority.
Contributors: Category lead, service users, finance and relevant control owners.
Delivery role: An SRM role gathers evidence, coordinates reviews and follows up agreed actions.
Evidence and boundary: Commercial changes and risk exceptions go to their own authorised decision-makers.
Responsibility 07
Approve a production workflow change
Decision owner: The designated client change authority under the agreed control process.
Contributors: Process owner, IT, affected approval owners and users.
Delivery role: Authorised internal or external specialists configure, test and document the change.
Evidence and boundary: Obtain business acceptance and release approval; retain change and rollback records.
06 · Keep the model working
Design escalation and performance reviews around decisions
Agree escalation triggers before a queue becomes a crisis: an overdue decision, a control exception, a supplier issue affecting operations or a disagreement over ownership. Specify the first owner, deputy, next authority and the evidence needed. Different urgency and risk levels may need different routes.
For an urgent request missing a required review, the operations team should identify the missing approval and notify the designated owner. Urgency should activate the agreed exception process, not silently bypass the control. Keep the decision and any conditions visible.
Give review forums a clear purpose. A short operational review can address ageing cases, blocked hand-offs and capacity. A service review can consider trends, recurring defects and agreed improvements. A sponsor review resolves matters beyond operational authority, such as scope, funding or competing functional priorities. Set a cadence proportionate to demand and risk.
- Flow: elapsed time by request type, waiting time at hand-offs and backlog age.
- Quality: incomplete requests, returned work, data defects and repeat incidents.
- Control: required approvals evidenced, open exceptions and overdue remedial actions.
- Supplier outcomes: performance issues, agreed actions and verified closure.
- Resilience: demand against available capacity, cover and reliance on individual knowledge.
Define each measure’s population, source, owner and review period. Pair speed with quality and control so teams do not improve a headline number by shifting work downstream. Record the decision, action owner and follow-up date after each review.
07 · Choose support for the work
Where internal teams and Denova’s delivery models fit
Keep enough internal capability to set objectives, own policy and risk decisions, manage relationships and assess whether delivery is working. External support can add capacity, specialist expertise or responsibility for a defined service. The arrangement should fit the operating model’s boundaries. Denova’s three delivery models support different needs. They can sit within a centralised, decentralised or centre-led structure; choosing a provider does not settle the organisation’s decision rights.For the decision about which activities to retain or support externally, see procurement outsourcing services.
Denova delivery model
Specialists working within your team
Embedded Delivery: Denova provides specialists who work as part of your team. You direct their day-to-day priorities; Denova manages their employment, training and ongoing support.
Illustrative use: An embedded supplier relationship specialist could coordinate reviews, improve records and build documented routines alongside your category team.
Make explicit: Name the client manager, work priorities, access permissions, escalation route and knowledge-transfer expectations. The specialist’s delivery responsibilities do not automatically include client approval authority.
Denova delivery model
Ownership of an agreed recurring service
Managed Services: You set business objectives and retain oversight. Denova manages people, processes and day-to-day delivery for an agreed service, with defined quality and performance measures.
Illustrative use: A defined supplier-onboarding administration or procurement-system administration service could provide recurring delivery within the client’s controls.
Make explicit: Agree scope, volumes, inputs, exclusions, client decisions, service measures, escalation and change control. Service levels and capacity need to be agreed for the engagement; they are not assumed package guarantees.
Denova delivery model
A defined change through acceptance and handover
Project Delivery: Denova coordinates a defined scope and outcome, with agreed responsibilities and milestones, involving your team in decisions, testing, adoption and sign-off.
Illustrative use: A focused workstream could map the current and future onboarding process, document roles and controls, and support workflow changes and training.
Make explicit: Name the sponsor, acceptance owners, dependencies and future operational owner. Agree documentation, handover and any follow-on support before the project closes.
Retain the client’s decision-making capability
Agree the boundary between support arrangements
A project may establish a process, an embedded colleague may help the team adopt it, and a managed service may later operate agreed recurring activities. That is a possible arrangement to discuss, not a prescribed sequence or a promise that every engagement includes all three.
Before appointing support, identify who accepts outputs, supplies access and data, approves exceptions and owns the service after handover. Include cover, retained documentation and exit or transition requirements in the agreement. A delivery contract cannot resolve an internal ownership dispute unless the client first makes the necessary decisions.
A related procurement client story
Building a dedicated supplier relationship function
Denova’s published case describes a large UK company in a regulated sector where supplier queries went directly to category leads, records were fragmented and no dedicated SRM function coordinated the work.
An embedded Supplier Relationship Manager developed process flows and procedures, established a single supplier communication contact, supported data consolidation and delivered supplier training. Stakeholder concerns were addressed directly, with escalation through appropriate channels where needed.
Client story · Supplier management
A dedicated SRM function
Clear responsibilities, process mapping and supplier communication.
Read how an embedded expert built structure around supplier relationships, records and training.
08 · Copy and adapt
Check that the model is ready to operate
Use this illustrative brief to capture the decisions. Test it with a routine request, an exception, a peak in demand and an absent key colleague. If participants disagree about who decides or acts, resolve the gap before treating the design as complete.
OPERATING MODEL BRIEF
Business outcomes and strategy priorities: ___
Entities, categories and process boundaries: ___
Current arrangements and evidenced gaps: ___
Central / local / shared responsibilities and rationale: ___
OWNERSHIP AND DELIVERY
Process owner, authority and deputy: ___
For each decision — owner, limits, contributors and evidence: ___
For each activity — delivery role, inputs and completion criteria: ___
Required functional approvals and authorised signatories: ___
Internal capability and capacity to retain: ___
External support scope, client dependencies and exclusions: ___
CONTROL AND CONTINUITY
Exception triggers, escalation route and decision record: ___
Measures, definitions, source owners and review cadence: ___
Cover, knowledge transfer and transition arrangements: ___
Open design decisions, owners and due dates: ___
Sponsor approval and next review: ___
Once roles and boundaries are agreed, use the procurement transformation roadmap to plan the transition, testing and readiness gates. Revisit the operating model as demand, systems or business priorities change.
Practical support