Are We Implementing Technology or Are We Prepared to Change Procurement?

Blaming software is familiar territory. “I hate SAP.” “I hate Microsoft.” “We tried Coupa. It doesn’t work.” When a system or an agent asks for information we have already entered three times, the frustration is understandable.

Sometimes, it is entirely justified. Bad software exists. Bad implementations exist. But there is another situation that deserves attention: we replace the system, spend the money, train the people, and six months later find ourselves having exactly the same arguments.

Who should have involved Procurement? Who is allowed to choose the supplier? Why does the report disagree with the spreadsheet?

Before choosing the next technology, we need to be clear about what we are prepared to change. A successful launch can leave the way an organisation decides, leads and works almost entirely untouched.

1) The old process in a new system

Consider an illustrative example. A company introduces a new procurement technology with a clear ambition: better visibility, faster purchasing and more control. The project involves difficult workshops, extensive testing and plenty of late evenings. When the system goes live, the team has good reason to celebrate.

Three months later, a colleague needs an external service. She calls a familiar supplier, agrees the work and sends Procurement an email: “Could you quickly raise the purchase order?” The supplier has already started.

Procurement uses the new technology to record a decision that has already been made. Its involvement comes at exactly the same point as before. The old process has been given a new place to live.

At the next management meeting, someone asks why purchasing still happens outside the intended process. The explanation is that adoption is taking longer than expected. Another training session is scheduled.

Yet the colleague already knows how to use the system. She also knows that her manager expects the work to start immediately, which supplier will respond, and that Procurement will handle the paperwork afterwards.

From her perspective, the process works. She gets the service, her manager gets the result, and the organisation absorbs the extra work somewhere else.

A person can understand a new process perfectly and still have good reasons to follow the old one. If those reasons remain in place, another training invitation is unlikely to change much. The employee has been asked to adopt the technology, while the expectations shaping her behaviour remain unchanged.

Her manager’s adoption deserves just as much attention.

2) Having systems and digitalising work are separate achievements

PwC’s 2024 global digital procurement survey covered 1,000 procurement departments. Eighty-one per cent reported having both source-to-contract and procure-to-pay solutions. Roughly four out of five therefore had technology covering both sides of procurement.

Yet the reported level of process digitalisation was 36% for strategic processes and 43% for transactional processes. Both were below half.

These are different measures. They do not tell us that a particular percentage of implementations failed, and they do not establish why the gap exists. They do show that having systems and digitalising work are separate achievements.

That distinction matters when defining success. A system can be available while important decisions continue to happen elsewhere. People can log in every day while relying on email, personal relationships and parallel records to get their work done.

Understanding this requires looking at the work itself. Some parts of the intended process may be useful. Others may create unnecessary effort. People may have been given responsibility without the authority or time needed to fulfil it.

Counting logins or purchased features will not explain these differences.

Following a purchasing request from the initial need to the final payment provides a more useful perspective. Listening to the people handling it reveals where the process becomes difficult and why. The most challenging obstacle may be a decision that nobody has agreed to own.

3) What leadership teaches through exceptions

Suppose the new process requires Procurement to be involved before a commitment is made. The rule appears straightforward until a senior stakeholder says: “Yes, of course. But this case is different.”

Sometimes, it really is. A critical service may have failed, or a supplier may be unavailable. There can be sound reasons to take a different route. What matters is who makes that decision, on what basis, and who accepts responsibility for the consequences.

If “urgent” allows anyone to bypass the process, urgency becomes a very attractive description. If the person challenging an exception is blamed for slowing down the business, others learn to stay quiet.

This is what I mean by an operating model: who can decide, who does the work, and what happens when people disagree. It becomes visible in ordinary conversations, particularly when someone needs to say no to a powerful colleague.

A leader may ask everyone to follow an agreed purchasing route, then approve an off-process request because a familiar colleague calls. The approval takes thirty seconds. Its message lasts much longer.

The team learns that the published process is negotiable if you know the right person. Next time, people may avoid the argument and approach that person directly. Their behaviour reflects what leadership has demonstrated.

Procurement leaders are part of this too. Defending a standard becomes harder when it inconveniences our own team. Asking for transparency becomes less comfortable when it exposes the exceptions we approve.

Implementation partners also carry responsibility. They should provide credible advice and delivery, challenge requirements that recreate unnecessary complexity, and fix genuine failures in the technology. Shared accountability still leaves decisions that only the organisation’s leaders can make.

4) Three decisions that make transformation concrete

Before calling a project a transformation, I would ask the leadership team to make three decisions explicit.

A. Give people the authority to deliver what is expected

A category manager may be expected to develop a strategy, improve supplier performance and deliver value. Those expectations need to be supported by clear authority.

When a business unit chooses a different supplier, the category manager needs to know whether they can resolve the situation, which escalation route applies, and who will support the decision when it becomes uncomfortable.

The answer can vary by category, risk and business need. What matters is that the boundaries are explicit and that people receive support when acting within them.

Without that support, responsibility becomes a promise they have no practical way to keep.

B. Decide which existing work will stop

Adding technology is easy to describe. Removing work requires more specific decisions.

Which report will disappear? Which approval can be removed? Which duplicate record will no longer be maintained once the new process is reliable?

A leader might announce that a dashboard will become the shared source for a management review, then ask the team on Friday afternoon to put the same numbers into the usual Excel file. The dashboard becomes mandatory, and the spreadsheet remains mandatory too.

The extra work is still there.

If the dashboard cannot answer a legitimate management question, it should be improved, or another way of answering that question should be agreed. Additional work needs to be a deliberate choice. Every parallel request consumes time that someone could spend on the job they were hired to do.

C. Assign ownership of the result after go-live

The project team eventually moves on. Suppliers still need managing, data still needs attention, new colleagues join, and processes develop problems. Someone needs the time and authority to address these needs.

For a purchasing process, ownership might involve reviewing how long requests take and why they get stuck. For a sourcing initiative, it means following the commercial agreement through to what the business actually buys. For analytics, it means examining which decisions changed because information became available.

A small number of meaningful outcomes provides a practical starting point. Establish the baseline, assign an owner to each outcome, and review progress after launch.

The people using the process need to be part of that review. They can explain where an intended improvement has created more work.

Announcing that leadership supports the programme is insufficient on its own. People experience that support through the decisions leaders defend, the reports they stop requesting, and the time they make available to resolve problems. The commitment that feels hardest to make personally may be the most useful place to start.

5. How the same purchasing request could work

Return to the colleague who needs an external service. This time, the business has agreed when Procurement needs to be involved, and she knows where to bring her request.

For a routine requirement, there is a simple route using an approved supplier. Within agreed limits, she can move quickly.

For a more complex requirement, someone helps her define the need before a supplier is committed. She has a contact who can make a decision and does not need to collect five informal approvals simply to understand what happens next.

If there is a real emergency, an exception route is available. Someone with the appropriate authority accepts the trade-off, records the reason and takes responsibility. Afterwards, the team considers whether the same emergency keeps recurring. If it does, the standard process may need to change.

Exceptions can reveal weaknesses the project team missed. People sometimes work around a process because they have encountered a problem within it. Listening to their experience can improve the standard.

In this example, the improvement begins before the purchase order. The colleague can ask for help without assuming that doing so will delay everything. Procurement can influence the requirement while there is still something to influence. The manager understands which decisions can be delegated and which require attention. Problems have a clear place to be resolved.

These changes are visible in the work itself. Their effect on time and commercial outcomes can then be measured.

Technology can support this way of working by making the agreed route easier to follow, bringing relevant information into decisions, and showing where the process gets stuck. Its value becomes easier to explain when the people around it understand what they are trying to achieve.

6. Start where the problem is clear

Improvement does not require redesigning the entire company first. A bounded area with a clear problem is enough to begin.

Agree the decisions, try the new way of working, listen carefully and adjust. Keep the controls that matter and remove effort that has no clear purpose. Visible results help build confidence.

For the team, this could mean spending less time correcting purchase orders after the event or having enough time to prepare a supplier conversation properly. For the business, it could mean receiving the right help before a commitment becomes expensive to change.

The practical question is what has become easier, clearer or more effective for the people doing the work.

7. The questions leadership needs to answer

Milestones, interfaces and testing deserve attention in a steering committee. Alongside them, three questions need clear answers:

• Which decision will be made differently because of this project?
• Which old way of working will we stop?
• Who owns the result after go-live?

Where the answers are unclear, leaders need to stay with them: put names against decisions, agree the next steps, and identify what they personally must do differently for those commitments to hold.

The next time software causes frustration, some of that frustration may be deserved. Before buying another technology or scheduling another training session, however, it is worth examining the choices that have been left untouched.

If the technology went live, but the way we decide, lead and work stayed the same, what exactly did we transform?

---

I presented these ideas in my talk at Apadua’s Indirect Procurement Days 2026 in Cologne.