ERP and source-to-pay programmes create strong pressure for change. Processes must be described, system roles assigned and approvals configured. That is both an opportunity and a significant risk.
If functional governance is unclear, the system digitizes the ambiguity. Workflows become precise without decisions becoming better.
An operating model is more than an organization chart
A procurement target operating model describes how the function creates impact. It covers strategy, organization and governance, roles and decision rights, category and supplier ownership, processes and interfaces, capabilities, KPIs, data and systems.
Technology is one component of the model, not its substitute.
Unclear governance becomes visible in the system – but not resolved
Who may set a category strategy? Who decides on suppliers? What is engineering’s role? Who owns savings, risk and contract coverage?
Without answers, system roles may be formally correct but functionally empty. Approval workflows then replace accountability with additional loops.
Category ownership before workflow
A core design question is how categories are governed across sites and legal entities. A centre-led model can combine common strategy, standards and transparency with local demand and market proximity.
Category leads need a clear mandate. Local buyers, stakeholders and technical functions need equally clear roles. Only then can the organization decide which work the system should support or enforce.
Separate strategic and operational work
Many organizations expect strategic impact while capacity remains tied up in order processing, expediting and exceptions. An operating model must therefore move, standardize or automate work – not merely rename roles.
Otherwise “strategic procurement” remains a job title without time to act strategically.
KPIs follow the mandate
A system can produce almost any metric. The relevant question is which decision the metric improves. Savings alone are not sufficient. Contract coverage, early involvement, supply, risk, cycle time, compliance and supplier development may be equally important.
The KPI architecture must match the target model and its accountabilities. Otherwise reporting expands without better steering.
Use the ERP window properly
Functional clarification cannot wait until system design is complete. Roles, approvals, master-data ownership, process variants and reporting dimensions must enter the programme early.
At the same time, the target operating model should not be derived solely from today’s system constraints. The right sequence is:
- Clarify business objectives and problems.
- Design governance, roles and processes.
- Derive system requirements.
- Decide deviations consciously.
Sequence the transformation
Not everything must be fully implemented before go-live. A robust blueprint separates prerequisites for core design, governance that can be activated quickly and longer-term capability or organization development.
Digitalization then becomes the accelerator of a functionally grounded model – rather than the technically clean preservation of historical weaknesses.