For years, the discussion was straightforward. Organisations selected an ERP or source-to-pay platform, implemented as much of the suite as they could justify, and added point solutions when important capability gaps remained.
Artificial intelligence is changing that equation.
Large enterprise platforms are rapidly extending their capabilities. At the same time, AI-native and specialist providers are introducing new capabilities in sourcing, negotiation, intake, spend intelligence, predictive analytics, decision intelligence, supplier management, risk, contracting and decision support that may exceed what the incumbent platform can provide today.
Each capability can be compelling on its own. The challenge for the CPO is that the number of potentially valuable additions to the technology stack seems almost endless.
That creates a deceptively simple question:
Do we continue evolving the technology environment we already have, or selectively introduce new capabilities and build a more composable architecture over time?
It is tempting to reduce that decision to suite versus best-of-breed. Framing misses the larger issue.
The real decision is what Procurement must accomplish and be capable of doing three to five years from now, what enterprise value it is expected to create, what architecture will enable those outcomes, and what the organisation is realistically prepared to support and absorb along the way.
Technology selection should follow those answers — not determine them.
Design backward from the future state
A CPO evaluating a new application will naturally ask whether its functionality is better than what exists today.
That matters, but it is not enough.
The more important question is:
Does this capability belong in the procurement organisation we are trying to build?
One useful discipline is to borrow from Understanding by Design: start with the desired result and work backward.
Applied to Procurement, the first question is not what technology is available. It is what the enterprise expects Procurement to contribute over the next three to five years and what the function must accomplish to meet that expectation.
Is Procurement expected primarily to provide effective sourcing, controls, and operational support? Or is it expected to become a material contributor to EBITDA, growth, risk management, resilience, and enterprise decision-making?
Those are different mandates, and they can justify different investment paths.
From there, the CPO should define the three-to-five-year vision, the business outcomes that matter, and the evidence that would demonstrate success.
If Procurement is expected to become a greater enterprise value contributor, what would prove that transformation occurred? Greater addressable spend? Better sourcing economics? Faster cycle times? Improved decision quality? Earlier identification of commercial opportunities? Stronger risk management? More measurable contribution to margin?
Only after those outcomes and success measures are clear should the organisation determine the future-state capabilities, operating model, governance, data, decision rights and technology architecture required to produce them.
The sequence matters:
Enterprise Expectations for Procurement → CPO 3–5 Year Vision & Business Outcomes → Evidence of Success → Future-State Capabilities → Enterprise Technology Strategy & Constraints → Organisational Change Capacity → Target Architecture → Sequenced Technology Roadmap
When the sequence is reversed, technology can begin defining the operating model. An application creates interest, its features suggest new possibilities, and the organisation then works backward to construct a use case.
Backward design reverses that logic.
The desired future state determines the capability requirement. The capability requirement informs the architecture. And the realities of the enterprise determine how quickly and in what sequence that architecture can be built.
Four dimensions the CPO has to reconcile
Once the future state is understood, the CPO has to reconcile at least four major dimensions before deciding what belongs in the technology stack.
1. Procurement’s enterprise mandate and value expectation
The enterprise’s view of Procurement matters.
A function viewed primarily as a sourcing and control organisation may require a different technology path from one expected to materially influence EBITDA, growth, risk, resilience, and strategic investment decisions.
The second environment may justify earlier investment in predictive analytics, decision intelligence, orchestration, and AI-enabled capabilities because the enterprise expects Procurement to create greater economic leverage.
The first may ultimately need many of the same capabilities, but the investment sequence may be different.
There is also a reinforcing cycle at work:
Perceived Value → Investment → Capability → Delivered Value → Greater Strategic Mandate
The more value Procurement demonstrates, the stronger the case becomes for investment in capabilities that enable even greater value.
2. Enterprise technology direction
The CPO does not design the procurement architecture in a vacuum.
The enterprise may already have standardised on a major ERP or source-to-pay platform. IT may have made substantial investments in integration, security, master data, support, and enterprise architecture around that ecosystem. The CIO may also be actively trying to reduce application proliferation rather than encourage it.
Those realities matter.
But enterprise technology strategy should be a design input and constraint — not automatically the answer.
“We already own the platform” is different from determining that the platform can support Procurement’s intended future state.
The better question is:
Can the enterprise’s preferred technology ecosystem provide the capabilities and expected outcomes Procurement requires within the timeframe in which they are needed?
If yes, evolving primarily within the incumbent environment may be exactly right.
If not, the organisation needs to decide whether to wait, augment selectively or reconsider the architecture.
3. Organisational capacity for change
A compelling future-state vision does not mean an organisation can implement everything at once.
Data may not be ready. Processes may be inconsistent. Integration resources may be limited. Stakeholders may already be absorbing other transformations. Procurement may lack the skills or bandwidth to manage several implementations simultaneously.
That does not mean the vision is wrong. It means the sequence has to be realistic.
The distinction is important:
The CPO’s three-to-five-year vision, goals and objectives determine the destination. The organisation’s capacity for change determines the pace and sequencing required to get there.
Change capacity should not define the vision. Otherwise, Procurement risks designing tomorrow’s operating model around today’s limitations.
But ignoring change capacity creates the opposite problem: a transformation agenda the organisation cannot realistically absorb.
4. Economic timing and capability lag
The final dimension is time.
Suppose a specialist application can provide a strategically important capability today, while the incumbent provider expects comparable functionality in three years.
The traditional evaluation may emphasise license cost, integration cost, implementation effort and the simplicity of waiting.
But another number belongs in the equation:
What is the economic consequence of operating without the capability for those three years?
That is capability-lag cost.
If the capability could improve sourcing outcomes, provide better pricing intelligence, identify opportunities earlier, accelerate cycle time, reduce leakage, improve compliance, lower risk or expand Procurement’s addressable spend, the value forgone while waiting belongs in the business case.
This does not automatically justify the specialist solution. But ignoring the cost of delay can make staying in place appear less expensive than it really is.
Two paths, neither automatically right
Consider a CPO who already has a major enterprise platform.
The provider is investing heavily in AI, expanding functionality and promising new capabilities across the procurement lifecycle.
Remaining primarily within that ecosystem has obvious advantages. Integration may be easier. Data governance may be more manageable. Users may already know the environment. IT may prefer a smaller vendor footprint. Existing investments can be extended rather than duplicated.
For many organisations, that may be exactly the right strategy.
But there is another legitimate path.
A CPO may conclude that certain capabilities are too strategically important to wait for the incumbent roadmap. A specialist may already provide materially better sourcing intelligence, negotiation capability, intake orchestration, predictive analytics, supplier insight or another function tied directly to the future operating model.
In that case, selective augmentation may create greater economic value even though it introduces another application into the environment.
Neither path is inherently more sophisticated.
A single-suite environment can be strategically sound or unnecessarily limiting. A multi-layer environment can be deliberately designed or needlessly fragmented.
The question is not how many applications Procurement has. It is whether each capability has an intentional place in the architecture.
Compare trajectories, not snapshots
Technology evaluations also suffer from a timing problem.
An incumbent provider may describe what its platform will be capable of doing in two or three years. A specialist provider can be evaluated against what it can do today.
That is not an equivalent comparison.
If the incumbent will improve over the next three years, the specialist certainly will as well.
CPOs therefore need to compare trajectories, not snapshots.
The relevant question is not:
What can the incumbent eventually do compared with what the specialist can do today?
It is:
At the point in time when we need the capability, what are both providers likely to be capable of delivering, and what role would each play in our architecture?
Roadmaps are not guarantees, and emerging providers carry their own risks. But comparing both alternatives at the same future point is more useful than comparing a promised future state with a competitor’s present state.
When more capability creates more fragmentation
The strongest argument against adding specialist applications is legitimate: complexity accumulates.
Every additional platform can introduce integration dependencies, master-data issues, overlapping workflows, additional supplier relationships, security requirements, training needs and support costs.
The growing range of predictive and AI-driven capabilities makes the architecture question even more important.
A spend-intelligence platform may identify an opportunity. A predictive analytics application may forecast pricing movement or recommend when to engage the market. A sourcing application may recommend a negotiation strategy. A contract-management platform may trigger a renewal. A supplier-risk application may recommend another course of action. An orchestration layer may determine where the work goes next.
Every one of those capabilities may create value.
But as the number of intelligent applications grows, so does the possibility that several systems are analysing, recommending, or acting upon the same commercial event.
At that point, integration alone is not enough.
The organisation must also determine:
Which system has the right to predict, recommend, trigger, make or override which decision?
That is decision-right architecture.
Without it, best-of-breed can gradually become best-of-fragmentation.
And the greatest risk may not be technology fragmentation.
It may be management fragmentation.
When ownership, governance and decision rights are distributed unintentionally across technologies and functions, no one is quite sure which application, process or executive owns the outcome.
That is why architecture is becoming a CPO issue, not merely an IT issue.
From TCO to TCO+
Traditional total cost of ownership remains important, but architecture decisions require a broader economic lens.
I think of this as TCO+.
In addition to software, implementation and support costs, the CPO should consider operating complexity, integration and data-management costs, change-management requirements, future transition cost and capability-lag cost.
Against those costs should sit the incremental business value enabled by the capability.
A point solution should not earn a place in the architecture because its predictive model, AI functionality or feature set is impressive. It should earn that place because its incremental business outcomes justify the incremental complexity.
Likewise, an incumbent should not automatically retain a capability because the organisation already owns the platform. Existing investment is relevant, but it does not make the economic consequence of a capability gap disappear.
The objective is not minimum technology cost.
It is the architecture that produces the greatest sustainable economic value at an acceptable level of complexity and change.
The decision CPOs really need to make
The procurement technology market will continue moving quickly.
AI, predictive analytics, and decision intelligence will accelerate that movement rather than simplify it. Enterprise providers will expand into capabilities currently associated with specialists. Specialists will broaden their platforms. Functional boundaries will blur. Agents will increasingly operate across applications rather than inside a single workflow.
The number of potentially valuable technology choices will continue to grow.
That makes the CPO’s vision more important, not less.
The useful question is no longer:
Should we stay with the suite or buy best-of-breed?
It is:
Given what the enterprise expects Procurement to contribute over the next three to five years, what capabilities and evidence of success will be required — and therefore what architecture should we build, within the context of the enterprise technology strategy, the organisation’s capacity for change and the economic consequences of acting or waiting?
The answer may be to evolve primarily within the existing platform.
It may be to selectively augment it with predictive, AI-native, or other specialist capabilities.
It may be a more composable environment.
All three can be legitimate.
The mistake is allowing a sequence of individual technology purchases — or a sequence of decisions to wait — to make the architecture decision by default.
Technology should enable the Procurement strategy.
The more technology choices a CPO has, the more important it becomes to know the destination before choosing the route.
And the next technology decision should follow that architecture — not create it.