Procurement & S2P · Evidence and improvement
Procurement Capability Assessment: How to Identify Skills, Process and System Gaps
Establish what your procurement function can do today, where delivery breaks down and what evidence supports the next improvement.
At a glance
Diagnose the cause
- Separate capability, skills and capacityDifferent gaps need different responses.
- Use three sources of evidenceCompare interviews, walkthroughs and operational measures.
- Turn findings into owned prioritiesRecord the consequence, uncertainty and next decision.
On this page
01 · Be precise about the gap
Capability, individual skills and available capacity are different
A procurement capability assessment examines whether the function can deliver the outcomes the business needs, using evidence about people, processes, systems, data and governance. It should explain what works, where performance depends on workarounds and what prevents improvement.
Before recommending training, recruitment or another platform, distinguish three questions:
- Organisational capability: can the function reliably deliver an outcome? Supplier onboarding, for example, requires an agreed process, suitable information, working controls, system support and accountable owners. One experienced colleague does not establish that the whole service is resilient.
- Individual skills: can a person carry out a task to the required standard? A platform administrator may need to diagnose an approval rule; a buyer may need to run a sourcing event. Check demonstrated work and support needs rather than relying on a job title or course attendance.
- Available capacity: is there enough usable time and cover to meet demand? A skilled team with a working process can still accumulate a backlog during peak demand or absence.
A supplier request might wait because nobody knows the escalation route, because the system routes it incorrectly, or because the only authorised reviewer is overloaded. Similar symptoms can require training, configuration changes or capacity cover. Several causes may coexist.
Assess the work before blaming the person. Missing access, unclear policy or incomplete request data can prevent a capable colleague from succeeding. Record these conditions separately from an evidenced development need.
02 · Set a useful boundary
Define the outcome, population and decision
Choose a service or process boundary that people can investigate. An initial assessment might cover new indirect supplier onboarding in one business unit, from request to an approved supplier record. State which entities, supplier groups, systems and transaction types are included and excluded.
Agree what the assessment will inform: a targeted process improvement, additional support, a training plan or investigation of system changes. Describe the required outcome and control expectations before judging a gap. This avoids treating every unused feature as a problem.
- Sponsor: who needs the findings and can resolve access or ownership issues?
- Participants: include procurement, AP/finance, system and data owners, business requesters and relevant approvers. Include legal, risk or suppliers where their hand-offs are in scope.
- Evidence period and sample: cover routine work, exceptions and relevant peaks. Record how cases were selected and which populations they do not represent.
- Outputs: an evidence register, agreed findings, unknowns, owners and recommended next decisions.
Keep the scope proportionate. A short review of one process can identify actionable gaps, but it cannot establish the capability of every team, entity or category.
03 · Compare what people say with what happens
Gather evidence through three complementary methods
1. Stakeholder interviews
Ask people to describe a recent transaction: what they needed, where it waited, what they corrected and how they obtained help. Ask what works well too. Speak to the people doing the work as well as managers; senior views and operational experience may differ.
Useful prompts include: “Show me the last exception”, “Who decided what happened next?” and “What would stop this working if your usual colleague were absent?” Treat each account as a lead to investigate, not proof of frequency or cause.
2. Process walkthroughs
Trace selected examples across the full journey, including an ordinary case and an exception. Compare the documented process with the actual steps, data, hand-offs and approvals. Observe workarounds and find out what problem they solve.
For system-dependent work, inspect the relevant configuration, access and support evidence with an authorised owner. Use an approved test environment for demonstrations that would otherwise change live records. A product feature being available does not mean it is configured, supported or used successfully here.
3. Operational measures
Review evidence such as arrival volumes, backlog age, elapsed time, rework, incomplete records, approval exceptions and support requests. Define the population, time window and start/end points. Separate time waiting from active effort, and distinguish missing timestamps from genuinely fast completion.
The procurement reporting guide develops measure definitions and data-source requirements. Where a metric is unreliable, document the limitation and use a controlled sample while its source is validated.
Triangulate before concluding. If requesters report slow onboarding, trace recent cases and examine queue age. Delays may concentrate in missing information, approval waiting or specialist review. If the sources disagree, keep the cause provisional and investigate the difference.
For each finding, retain the evidence source, date, sample, observation, business consequence and limitations. Distinguish observed facts from explanations that still need testing.
04 · Follow the outcome across the function
Assess five connected dimensions
Use these prompts as an illustrative assessment checklist, adapted to the process and controls you actually need. They are not a validated maturity benchmark or a formal Denova scoring product. A strong result in one dimension cannot compensate for a critical gap in another.
Dimension 1 · People
Can the team perform and sustain the work?
Assess: Check task-specific skills, access to specialist help, knowledge transfer, cover and the time available for recurring work. Separate a development need from a workload or authorisation constraint.
Evidence to seek: Observed task demonstrations, recent work, role expectations, support routes, training follow-up, demand and availability by period.
Illustrative signal: A trained administrator can resolve routine queries, but all configuration knowledge sits with one person. The gap may be continuity and knowledge transfer rather than basic user training.
Dimension 2 · Processes
Does the process work from start to finish?
Assess: Look for defined inputs, hand-offs, exception routes and acceptance criteria. Compare the intended flow with how routine and difficult cases actually move.
Evidence to seek: Process maps, walkthroughs, sampled transactions, returned requests, approval waiting and rework reasons.
Illustrative signal: An onboarding form is complete from the requester’s perspective but repeatedly lacks the information finance needs. Investigate the input definition and hand-off before adding another approval.
Dimension 3 · Systems
Does the configured system support the required work?
Assess: Examine workflow logic, permissions, integration reliability, error handling, support and controlled changes. Distinguish a platform limitation from an unused, misconfigured or unsupported capability.
Evidence to seek: Configuration demonstrations, interface and error records, support tickets, test evidence and change history.
Illustrative signal: Requests reach a previous approver because rules no longer match an agreed responsibility. Validate the rule and owner, then test a correction; replacing the platform is not an established conclusion.
Dimension 4 · Data
Is the information fit for the decisions and controls?
Assess: Check completeness, validity, duplicates, definitions and ownership against agreed requirements. Trace important fields from capture to downstream use and reporting.
Evidence to seek: Sample records, validation rules, reconciliation, data dictionaries, rejected transactions and source-to-report checks.
Illustrative signal: Supplier records contain values, but inconsistent category codes prevent reliable reporting. A completeness percentage alone would conceal the problem.
Dimension 5 · Governance
Can decisions, controls and improvements be maintained?
Assess: Establish who owns the process, accepts exceptions, approves configuration changes, validates outcomes and resolves competing priorities. Look for evidence that these responsibilities operate in practice.
Evidence to seek: Approval records, exception decisions, change logs, owner acceptance, service reviews and tracked actions.
Illustrative signal: The team fixes urgent issues, but no owner approves or records production changes. The weakness is the control over change, even if individual fixes work.
05 · Keep uncertainty visible
Record an evidence status, not a false sense of precision
A simple set of local finding labels can make discussion clearer:
- Demonstrated in the sample: the required outcome or control operated in the cases reviewed; state the limits of that evidence.
- Partly demonstrated: it operated for some cases, roles or conditions, with specific exceptions recorded.
- Gap evidenced: the observed result falls short of an agreed requirement, with supporting examples.
- Unknown: sufficient evidence is missing, inaccessible or contradictory. Name the person and action needed to resolve it.
These labels describe findings within your review. Do not average them into an overall maturity number or present them as an industry standard. Absence of evidence is a reason to investigate; it does not automatically prove that a control is absent.
Review provisional findings with the people responsible for the work. Record disagreements and additional evidence rather than changing a conclusion simply to reach consensus.
06 · Make the next action clear
Turn findings into priorities with owners and dependencies
For each evidenced gap, describe the business consequence, affected population, plausible cause, confidence in the evidence and next action. Assess urgency and control exposure alongside effort, dependencies and available capacity. Keep mandatory controls distinct from optional efficiency improvements.
A high-consequence unknown may deserve early investigation. A well-evidenced but low-impact inconvenience may wait. A configuration change may be blocked until a process owner agrees the required rule. This is more useful than treating every finding with the same score as equally urgent.
Illustrative finding 1: incomplete onboarding requests
Evidence: six of 24 recent requests reviewed were returned for missing business-owner or cost-centre information. Requester interviews describe uncertainty, and a walkthrough shows those fields are optional. This small selected sample does not establish a population-wide failure rate.
Consequence and next action: repeated correction delays the hand-off. The procurement process owner and finance owner should agree the required inputs and legitimate exceptions. Then the application owner can test appropriate validation and clearer guidance. Configuration depends on that agreed requirement.
Validation: review a comparable sample after the change, checking returned requests and any new workarounds. Set the success criterion with the owners before implementation.
Illustrative finding 2: users cannot resolve an exception
Evidence: two users in a walkthrough cannot find the approved escalation route. The route exists in an outdated guide; broader team knowledge has not been tested.
Next action and owner: the operations lead updates the guide, confirms the support route and checks understanding through a task demonstration. Broader training remains a hypothesis until its need is evidenced. This finding does not justify labelling the whole team unskilled.
Illustrative finding 3: backlog grows at a recurring peak
Evidence: arrival and completion records show a queue growing during month-end, while staff availability is lower. Active handling-time evidence is incomplete, so a staffing estimate is not yet reliable.
Next action and owner: the service owner validates effort, rework and usable capacity, then considers operational cover, timing changes or removal of avoidable work. Recheck the queue through a comparable peak. Do not assume recruitment is the only response.
These are fictional examples, not Denova client findings or promised outcomes. They show how different evidence can lead to process, system, development or capacity actions.
Practical client experience
What the Ariba and Zip cases support
The following cases illustrate practical gap diagnosis and improvement. Neither published account describes a formal scored procurement capability assessment. Keep that distinction when using them as evidence.
Client example
Configuration gaps and training in SAP Ariba
A UK company in a regulated sector had outdated approval flows, manual supplier processes and no dedicated platform support. Denova’s embedded specialist began by understanding configuration gaps and business requirements, then worked on approval logic, supplier performance surveys and segmentation.
The published case also describes training the operations team to handle day-to-day queries. For an assessment, this illustrates why system configuration and the skills to sustain it should be examined together. It does not establish a formal maturity score or a benchmark for another organisation.
Read the published account of the issues identified and the practical support delivered.
Client example
User pain points and process diagnosis in Zip
The Zip case describes a global business with unclear system ownership, incomplete integrations, inconsistent approvals and manual workarounds. The consultant mapped existing processes, gathered pain points from business users and prioritised gaps between the setup and operational needs.
Work included process documentation, required-field controls, integration fixes, change records and knowledge transfer. The account explicitly says formal metrics were not in place at the time. It supports a practical diagnostic approach, but not an invented before-and-after capability score or quantified assessment benefit.
Read the published account of the issues identified and the practical support delivered.
07 · Copy and adapt
A copyable assessment brief and finding checklist
Use this illustrative template for a bounded review. It is a planning aid, not a validated assessment instrument. Keep evidence references alongside the findings so another owner can challenge the conclusion.
ASSESSMENT BRIEF
Business outcome and decision to inform: ___
Process boundary, entities and transaction types: ___
In scope / out of scope: ___
Sponsor, assessment lead and process owner: ___
Required outcomes and control expectations: ___
EVIDENCE PLAN
Interview roles, including users and hand-off owners: ___
Walkthroughs: routine case / exception / peak or absence: ___
Operational measures, definitions and source owners: ___
Review period, sample selection and limitations: ___
Access, data availability and unresolved evidence gaps: ___
FIVE-DIMENSION CHECK
People: demonstrated skills, support, cover and usable time: ___
Processes: inputs, hand-offs, exceptions and observed rework: ___
Systems: configuration, permissions, interfaces and support: ___
Data: required fields, validity, reconciliation and ownership: ___
Governance: decision authority, change control and follow-through: ___
ONE RECORD PER FINDING
Required outcome / observed gap: ___
Evidence reference, date, sample and limitation: ___
Status: demonstrated / partly demonstrated / gap evidenced / unknown: ___
Business consequence and affected population: ___
Skill / capacity / wider capability issue, or cause still to test: ___
Proposed next action and accountable owner: ___
Dependencies, effort and capacity needed: ___
Unknowns: validation action, owner and date: ___
Priority rationale and decision requested: ___
Success evidence and review date: ___
REVIEW AND AGREEMENT
Owners who reviewed the findings: ___
Disagreements or further evidence required: ___
Actions approved, deferred or requiring investigation: ___
Next review and person maintaining the record: ___
Do not turn every blank into an adverse finding. Use “unknown” where necessary and make the evidence-gathering action explicit.
08 · Use the findings
Move from diagnosis to an improvement decision
Finish with a short set of owned findings and a clear request: approve a targeted fix, validate an important unknown, provide temporary cover or investigate a larger investment. Retain strengths as well as gaps so changes preserve what already works.
Use the procurement transformation strategy guide to compare priorities and make the investment case. Once changes are agreed, the procurement transformation roadmap develops delivery order, testing and readiness gates. Detailed organisation design remains a separate decision.
Revisit the assessment after agreed actions have had time to operate. Check observed outcomes and resilience, rather than counting completed training sessions or configured features alone.
Practical support