Digitization does not solve process problems.

Before deciding on technology, we should first have a clear understanding of how procurement should fundamentally work. Not as a meticulously detailed model of the target process, but as a process vision: Which decisions should be made where? Which processes should be as simple, standardized, and automated as possible? What role should data and systems play?

The target image does not have to be static. The specific implementation can change – the process vision provides the direction.

The next step is to reflect today's world against this vision.

Where do media breaks occur? Which work steps actually create value? Where is reliable data lacking? Who makes the decisions? Which interfaces are not working?

And most importantly: What fundamental process errors would we merely digitize with new software?

We shouldn't simply migrate such structural problems. Unclear responsibilities, unnecessary approval loops, systematic duplication of effort, or fundamental data and interface problems must be addressed before any migration.

This explicitly does not mean, however, spending months perfecting processes on the drawing board. Lift and shift can be a sensible implementation strategy when it comes to quickly transitioning to a new system environment. This means transferring existing processes and structures to a new system environment largely unchanged, rather than fundamentally redesigning them before migration. It just shouldn't be a blind lift and shift.

The other mistake would be to design the future process completely independently of the technology. Modern ERP, e-procurement, and SaaS solutions bring with them standard processes, best practices, and new use cases. These capabilities should be consciously leveraged instead of trying to replicate old processes as faithfully as possible.

My guiding principle is therefore: Have a clear process vision and understand what obstacles currently separate us from it. Then use new technology in a use-case-oriented manner, eliminate key process errors before migration, and consciously continue further optimization in the new system environment.

Process and system must therefore be considered together. The process vision sets the direction; technology opens up additional possibilities. The final, concrete target process emerges from both.

However, this only fulfills one prerequisite for successful digitalization.
The second point is at least as important: The people who will later work with the system must understand and support the change.

Many years ago at BCG, I learned a term for this that I still like today: "Self-Discovered Logic".

The idea behind it is simple: solutions are not developed for the people who will later implement them, but with them.

BCG describes the principle as the collaborative development of the best approach by the client and consultant. This is based on the experience that jointly developed solutions are better suited to the specific situation and are therefore easier to implement.

That's exactly what I consider crucial in digitization projects.

Anyone who works with a process on a daily basis is familiar with problems and special cases that aren't reflected in any process diagram. If these people are only confronted with a finished solution at the end, the well-known "not invented here" problem quickly arises: solutions that come from outside are more likely to be rejected or only half-heartedly implemented – even if they make technical sense.

Therefore, I would involve future users early on.

Not because everyone has to vote on everything.
But because their knowledge is needed – and because people need to understand why their work is changing.

What are the practical implications of this?

For me, this results in a five-step approach for greater digitalization in purchasing:

1. Define the process vision: How should purchasing work in principle – regardless of current system boundaries?
2. Understanding today's obstacles: Where do processes, responsibilities, data, or interfaces prevent this vision from becoming reality?
3. Eliminating structural process errors before migration: What should we absolutely not transfer 1:1 to the new system?
4. Using technology consciously: Which standard processes, functions, and use cases of the software help to achieve the process vision more easily or better?
5. Pragmatic implementation and further development: What needs to be resolved before go-live, what can be deliberately optimized in the new system environment – and how do we involve the future users in the process?

If we cannot answer these questions, at least in their basic outlines, then in my view it is too early to select software.

In one of our projects for an international company with a procurement volume of around €350 million, we applied this logic: First, we worked with the client to analyze the existing purchasing processes, developed a target model, and simplified processes where fundamental problems were identified. Then, a suitable SaaS provider for a cloud-based e-procurement solution was selected, the contract was negotiated, and the system was subsequently customized and implemented.

The crucial point was not to perfect every process down to the last detail before selecting the software. What was crucial was knowing the overall direction, avoiding major problems, and further developing the specific implementation with the chosen solution.

The result was significantly faster and more transparent procurement processes.

This applies to e-procurement and ERP systems – and even more so to AI. The more technology automates, the less we can simply automate unclear processes, poor data, and ambiguous responsibilities.

Especially with AI, new use cases can simultaneously lead to thinking about processes differently than was possible in the previous system world.

Therefore, for me, the same basic principles apply to AI: a clear process vision, suitable processes, reliable data and the early involvement of relevant stakeholders.

Therefore, the crucial question before the next digitization project is not just: Which software can do it?

But first: How should our process fundamentally work, what is preventing us from doing so today – and what possibilities offered by new technology can help us get there better?