Procurement Operating Model: What Organisations Need to Decide Before Technology

What is a procurement operating model?

A procurement operating model describes how Procurement operates in practice. It defines:

• what Procurement is accountable for
• which decisions it owns and which remain with the business
• how categories, sourcing and suppliers are managed
• how Procurement works with Finance, Legal, Technology and operational teams
• how Source-to-Pay processes operate from demand through to payment
• which systems support those processes
• who owns procurement and supplier data
• how governance and controls operate
• which capabilities are required
• how performance and benefits are measured

This distinction matters because an organisation can redesign its Procurement structure without changing its operating model. A central team can still operate through fragmented processes. A business partnering model can still have unclear decision rights. A new Source-to-Pay platform can digitise an inefficient process rather than improve it. Effective procurement operating model design therefore starts with how the organisation wants Procurement to create value, before deciding how teams or technology should be structured around it. This end-to-end view is consistent with established operating model thinking that connects procurement strategy with process, organisation, capability, governance, technology, data and the wider Source-to-Pay lifecycle.[1]

Start with the Procurement mandate

Before designing processes or technology, leadership should be able to answer a basic question:

What is Procurement actually responsible for? The answer is often less clear than expected. An organisation may have a Procurement function while significant spend is committed directly by business teams. Procurement may lead sourcing but have limited involvement in demand management. Supplier onboarding may sit with Procurement, Finance or shared services. Contract management may remain with operational owners. Technology ownership may sit elsewhere entirely. The operating model should make those boundaries explicit. This includes determining:

• which categories and types of spend fall within Procurement's mandate
• where Procurement leads, advises, approves or has no involvement
• financial or risk thresholds that trigger Procurement involvement
• who can commit organisational spend
• who owns specifications and demand
• where commercial accountability sits
• how Procurement works with Finance and Legal
• who owns supplier performance once a contract is operational

Without a clear mandate, organisations create workarounds. Business teams involve Procurement too late. Buyers become administrative processors rather than commercial partners. Controls are bypassed because responsibilities are unclear. Procurement may report savings that Finance does not recognise. Suppliers receive conflicting instructions from different parts of the organisation. The design problem is therefore not simply, "Where should Procurement sit?" It is, "What decisions should Procurement own, influence or enable?"

Centralised, decentralised or hybrid is not the whole answer

Operating model discussions often begin with whether Procurement should be centralised, decentralised or hybrid. That is useful, but it is not enough. Two organisations can both describe themselves as operating a hybrid Procurement model while working very differently. One may centrally own category strategy and sourcing while local teams manage requisitioning and supplier performance. Another may delegate most commercial decisions to business units while retaining only policy, governance and major sourcing centrally. The meaningful questions sit underneath the structural label. Who owns category strategies? Who decides when requirements should be aggregated? Who approves supplier selection? Who owns strategic supplier relationships? Who challenges demand? Who performs operational buying? Which activities belong in shared services? Which decisions can business units make independently? A good procurement target operating model defines those responsibilities clearly enough that people do not have to interpret them differently each time a requirement arises.

Source-to-Pay must be designed end to end

Procurement cannot be designed effectively as a collection of isolated processes. An end-to-end Source-to-Pay model should consider the complete journey:

Demand → Sourcing → Contracting → Supplier Onboarding → Requisition → Approval → Purchase Order → Receipt → Invoice → Payment → Supplier Performance Decisions made at one stage affect what happens later. Poor supplier onboarding can create data problems that eventually surface during invoicing or reporting. Weak contracting processes can make purchase compliance difficult to enforce. Poor purchasing controls can create invoice exceptions. Inconsistent category structures can undermine spend analytics. The important question is not merely whether every individual step works. It is whether the whole value chain works together. That requires clearly defined ownership of the hand-offs between Procurement, Finance, suppliers and the business. Research into Source-to-Pay operating models similarly emphasises that sourcing, contracting, purchasing, payment and supplier management should be treated as interconnected rather than independent activities.[1]

The Procurement and Finance boundary needs deliberate design

The relationship between Procurement and Finance is one of the most important parts of the model. Both functions interact with expenditure, suppliers, controls and financial information, but their responsibilities are different. Problems emerge when the hand-offs are not explicit. Examples include:

• Procurement reports negotiated savings that never appear in budgets
• Finance creates supplier records without the controls Procurement expects
• invoices arrive without valid purchase orders
• Procurement owns the purchasing platform while Finance owns the ERP integration
• supplier payment issues are treated as Procurement problems even when the root cause sits elsewhere
• category decisions are made without sufficient budget information
• benefits are claimed without an agreed financial baseline

The operating model should define responsibilities across areas such as: Supplier master data: who requests, validates, creates, changes and deactivates supplier records? Budget: when must budget availability be confirmed and by whom? Approvals: which approvals represent commercial authority and which represent financial authority? Purchase orders: who owns policy, compliance and exception management? Invoices: who owns matching failures and invoice exceptions? Payment: where does Procurement responsibility stop and Accounts Payable responsibility begin? Savings and benefits: how are procurement benefits calculated, validated and recognised? If those boundaries remain ambiguous, implementing new technology will usually expose the ambiguity rather than solve it.

Data ownership is part of the operating model

Procurement transformation increasingly depends on reliable data. That makes data ownership an operating model issue, not simply a technology issue. Organisations should determine ownership for data including:

• suppliers
• category taxonomy
• contracts
• catalogue and pricing information
• purchase orders
• spend
• supplier performance
• supplier risk
• sourcing events
• benefits

They should also define which system is authoritative for each data object. If multiple platforms can independently create or maintain the same information, reconciliation becomes inevitable. For example, an organisation implementing separate ERP, Source-to-Pay, Contract Lifecycle Management and supplier management platforms should know exactly which system owns each critical record and which systems consume it. That decision should be made intentionally, before integrations are designed.

Technology should enable the operating model, not define it

Technology is a major enabler of modern Procurement. Source-to-Pay platforms can improve user experience, automate approvals, enforce controls, provide better spend visibility and connect processes that were previously fragmented. ERP, contract management, supplier management, analytics, identity, workflow and integration platforms can all play important roles. These choices should remain connected to the wider ERP transformation. But technology configuration embeds operating decisions. A workflow contains assumptions about authority. A supplier onboarding process contains assumptions about ownership and risk. A purchase approval contains assumptions about thresholds. A system integration contains assumptions about which application is authoritative. A role profile contains assumptions about responsibility. If those decisions have not been made explicitly, implementation teams will still have to make them. The difference is that they may then be made during configuration workshops rather than as conscious business design decisions. That is why procurement operating model design and technology design should be connected, but not confused.

Governance should define who can decide what

Good governance is not the number of committees an organisation has. It is clarity about how decisions are made. A procurement operating model should make important decision rights explicit. For example:

• Who can approve a sourcing strategy?
• Who can select a supplier?
• Who can approve an exception to Procurement policy?
• Who can create or change supplier master data?
• Who owns a category strategy?
• Who can approve contract variations?
• Who can extend a supplier relationship?
• Who decides whether a procurement technology change is implemented?
• Who approves changes to buying channels?
• Who validates reported procurement benefits?

Decision rights should then be reflected consistently across policy, process, systems and governance. If policy says one person owns a decision but system permissions allow somebody else to make it, the operating model is not functioning as designed.

Capability matters as much as structure

A future Procurement model should also consider whether the organisation has the capability to operate it. That includes more than headcount. A Procurement team may need capability across:

• strategic procurement
• category management
• sourcing
• commercial negotiation
• supplier relationship management
• contract management
• procurement operations
• analytics
• technology
• transformation and change
• business partnering

Different activities require different capabilities. Moving administrative work into shared services, for example, only creates value if strategic capacity is genuinely redirected towards higher-value work. Likewise, introducing sophisticated procurement technology without sufficient process ownership, data capability or change capacity can leave the organisation with more technology but little improvement in commercial performance. The target operating model therefore needs a realistic view of both future capability and the transition required to create it. Supporting analysis of next-generation procurement models similarly highlights organisation, governance and capabilities as critical enablers alongside process, digital and data considerations.[2]

Procurement performance should measure more than savings

Savings remain important, but they should not be the only measure of Procurement performance. Depending on the organisation's objectives, measures may also include:

• addressable spend under appropriate commercial management
• contract compliance
• purchase order compliance
• sourcing cycle times
• supplier performance
• supplier risk
• demand reduction
• working capital
• invoice exception rates
• user experience
• process efficiency
• benefits realised
• commercial value protected
• strategic supplier outcomes

The important principle is that measures should reflect what the operating model is intended to achieve. A function designed primarily around commercial value, supply resilience and strategic supplier management should not be managed solely against annual negotiated savings. Measures should also distinguish between activity, output and realised outcome. Completing a sourcing event is activity. Negotiating a saving is an output. Seeing that saving reflected in actual expenditure or budget performance is an outcome.

Ten procurement operating model decisions leadership should be able to answer

Before approving a new procurement target operating model, leadership should be able to answer these ten questions clearly:

1. What is Procurement's mandate?

Which spend and commercial activities does Procurement control, influence or support?

2. Who owns demand?

Who decides what the organisation genuinely needs before a sourcing exercise begins?

3. Where do decision rights sit?

Which commercial decisions are central, local or shared?

4. Who owns categories?

Are category strategies genuinely owned and managed, or does Procurement primarily respond to individual requests?

5. How does Procurement engage with the business?

Is Procurement transactional, advisory, embedded, business-partnered or different depending on the category?

6. Who owns each part of Source-to-Pay?

Are the boundaries between Procurement, Finance, shared services and the business explicit?

7. Who owns procurement and supplier data?

Is there a defined owner and authoritative system for every critical data object?

8. What should technology enable?

Are systems being configured around an agreed operating model, or is the operating model being created around system functionality?

9. How will performance and benefits be measured?

Can Procurement, Finance and the business agree when value has genuinely been realised?

10. How will the organisation move from today's model to the target model?

Are the required changes to people, process, data, technology, governance and capability understood and sequenced? If these questions cannot be answered consistently by the people leading the transformation, the operating model is probably not ready to be implemented.

A target operating model needs a transition model

Designing the future state is only half the work. Organisations must also determine how they will get there. A Procurement operating model transition may depend on:

• technology implementation
• organisational restructuring
• recruitment or capability development
• policy changes
• process redesign
• supplier migration
• data cleansing
• contract remediation
• Finance transformation
• ERP changes
• new integrations
• business adoption
• governance changes

These dependencies rarely move at the same speed. For example, an organisation may design central category ownership but lack the resource to implement it immediately. A new supplier onboarding process may depend on technology that will not be available for six months. A Source-to-Pay platform may go live before every category can adopt the new operating model. The transition therefore needs sequencing. A practical roadmap should identify: What can change immediately? What depends on technology? What depends on capability? What needs executive decisions? What must remain temporarily unchanged? Where is interim governance required? This makes the operating model implementable rather than aspirational.

What should a procurement operating model assessment examine?

Before designing or redesigning the model, organisations should understand how Procurement operates today. A meaningful procurement operating model assessment should examine more than organisational structure. It should consider:

Mandate and strategy

What Procurement is expected to achieve and whether its mandate supports those expectations.

Organisation and decision rights

How responsibilities are distributed and whether accountability is clear.

Process

How work actually moves across Source-to-Pay, including exceptions and hand-offs.

Technology

Which systems enable the process, where functionality overlaps and where manual work remains.

Data

Who owns critical information, where quality issues exist and which systems are authoritative.

Governance and controls

How commercial decisions, risk, exceptions and changes are governed.

Capability and capacity

Whether the organisation has the skills and resources needed to operate the intended model.

Performance

How Procurement's contribution is measured and how benefits are validated.

Interfaces

How Procurement works with Finance, Legal, Technology, operational teams and suppliers.

Change readiness

Whether the organisation can realistically transition from its current state to the proposed target model. The assessment should then translate findings into decisions. That means identifying material gaps, risks, dependencies, operating model choices, technology implications and a practical sequence for change.

From operating model design to implementation

The strongest procurement operating models are not necessarily the most complex. They are the ones people can understand and operate. Responsibilities are clear. Processes connect. Systems reinforce the agreed model. Data has defined ownership. Governance supports decisions rather than creating unnecessary delay. Performance measures align to outcomes. And the organisation has a realistic route from its current state to the target state. For organisations considering Procurement Transformation, a Source-to-Pay implementation or a broader Operating Model redesign, this work should happen early. Technology can then automate, enable and strengthen the model rather than becoming the mechanism through which fundamental business decisions are made.

How PearsonGoldman approaches procurement operating model design

PearsonGoldman approaches procurement operating model work as part of the wider transformation, rather than as an isolated organisational design exercise. We consider the interaction between:

• strategy and mandate
• organisation and accountability
• Source-to-Pay processes
• Finance and Procurement responsibilities
• governance and controls
• supplier and procurement data
• technology and integrations
• capability and capacity
• performance and benefits
• transition and implementation

Where organisations are still determining the scale or shape of the change, a structured Transformation Discovery or procurement assessment can establish the current state, identify material gaps and dependencies, define the key decisions required and determine whether operating model, process, technology or wider transformation activity should come first. The objective is not to produce a target operating model diagram. It is to design an operating model that can actually be implemented.

Related PearsonGoldman services

• Procurement Transformation
• Operating Model Design
• Transformation Discovery
• ERP Transformation
• Finance Transformation