Procurement transformation: how it works and what to require
This is for the procurement excellence or transformation lead who owns the operating-model change. Proconomy supports a workflow-led sequence: start with the highest-friction process, encode existing policy as executable governance, prove the change with real operating metrics, then expand across the same platform foundation.
This fails for reasons. None of them technology.
Scope, sequence and adoption — each with a recognisable shape.
Scope failures
- Everything in scope, so nothing finishes
- Designed for the policy you wish you had
- Every entity in wave one
- All modules before any value
- Requirements gathered from everyone
- The pilot chosen because it was easy
Sequence failures
- Data cleansing before any workflow runs
- Integration completed before first use
- Full ERP alignment as a precondition
- Training before there is anything to use
- Go-live dated before scope is settled
- Value promised only at the end
Adoption failures
- A process slower than the workaround
- Plants told rather than consulted
- No local authority left in the design
- Suppliers asked to do more for nothing
- Buyers measured on the old behaviour
- No named owner after go-live
What a good first phase looks like
- One workflow, one entity, real transactions
- Policy encoded as it actually operates today
- A named process owner who can decide
- Evidence produced within the first phase
- Plants keeping the authority they need
- A widening plan based on what the record shows
Six design choices. Value before the programme ends.
What a workflow-led sequence does differently from a module-led one.
| Mechanism | What it has to do |
|---|---|
| Workflow-led, not module-led | One governed workflow goes live and produces evidence while the rest is still being configured. Value arrives before the programme completes. |
| Policy transcribed, not redesigned | Configuration starts from the thresholds and approvals you already operate. Redesigning policy and deploying software at the same time is what makes both fail. |
| One entity first | The first phase proves the model in one place. Widening is a configuration exercise rather than a second programme. |
| Data quality handled in flight | Classification improves through use and correction rather than requiring a cleansing project before anything runs. |
| Integration scoped, then phased | Read access first, write-back scoped separately, with the objects agreed in writing before build. |
| Adoption by speed, not mandate | The governed route has to be faster than the workaround. Where it is not, people route around it regardless of policy. |
A description of what the practice requires, not a feature list.
One first workflow. Different one by sector.
Where the pressure already exists, by industry.
Automotive
Supplier corrective action, because it is the workflow with the most chasing and the clearest evidence gap.
Building materials
Spend consolidation across plants, because the opportunity is visible immediately in connected data.
Medical devices
Supplier qualification, because audit readiness is the pressure that already exists.
Industrial equipment
Intake, because project and MRO demand competing in one inbox is the daily complaint.
Five questions. Settled before day one.
Answer these and the programme has a shape. Skip them and it does not.
- Which single workflow, in which single entity, goes first — and who decided that?
- What is the policy as it actually operates today, not as the document describes it?
- Who can settle a process question in a day rather than a month?
- What evidence will exist at the end of phase one, and who will review it?
- What are you prepared to leave unchanged in wave one?
Definitions. Asked and answered.
Your scope, entity count, data quality and integration landscape set the pace, and we size all four before committing to a date. What the sequence is built for is operating change ahead of full deployment — one governed workflow live and producing evidence while the rest is still being configured.
Usually the one consuming the most buyer time rather than the one with the most executive attention. Intake, sourcing coordination and supplier onboarding are the three most common starting points.
No. Encode the policy you already have, then use the operating data to decide what is worth redesigning. Redesigning first delays value and usually redesigns the wrong things.
By being explicit about what is genuinely group policy and what is local configuration. Resistance usually comes from a central process that ignores real operating constraints, not from an objection to governance.
Manual touches per workflow, cycle time by stage, first-time-complete rate, exception and escalation rate, policy-compliant routing and agent-completed actions. These are operating measures the platform produces as work runs.
Yes, and it often does. The ERP programme consolidates the transactional record; Proconomy changes how the work around it is executed. Neither depends on the other completing first.
Procurement transformation is a change to how procurement work is executed and governed, rather than a change of software alone. It typically covers the operating model, policy, process ownership and the systems that carry the work — which is why it fails when treated as an implementation.
Most commonly because scope is too wide to finish, value is promised only at the end, or the new process is slower than the workaround it replaces. Technology is rarely the cause; sequence and adoption usually are.
It depends entirely on scope, entity count, data quality and integration landscape, and any vendor quoting a duration before assessing those four is guessing. The more useful question is when operating change first becomes visible, which a workflow-led sequence brings forward substantially.