Published on September 1, 2026<\/p>\n<\/div>
New software can significantly speed up the purchasing process.
\nThat's the good news.<\/p>\n
The bad thing is that it can also cause a bad process to simply run faster.<\/p>\n
In digitization projects, I repeatedly encounter the same hope: once the new system is in place, processes will become simpler, data better, responsibilities clearer, and decisions faster.
\nThis hope becomes problematic when we expect the software to solve problems that we haven't yet understood from an organizational perspective.<\/p>\n
Software doesn't automatically clarify who has the authority to make decisions. It doesn't resolve conflicting responsibilities. And it doesn't turn bad data into good data.<\/p>\n
On the contrary: the more powerful the technology becomes, the more important the organization behind it becomes.<\/p>\n<\/div>
Therefore, my thesis is:<\/p>\n
Software doesn't solve process problems. It scales them.<\/b><\/p>\n<\/div> Let's take a purchasing process that has evolved over years.<\/p>\n Requirements come in through various channels. Approvals are complicated. Master data is incomplete. Purchasing, specialist departments, and IT have differing ideas about how the process should work. Some special procedures exist simply because they've always existed.<\/p>\n A new purchasing software is coming soon.<\/p>\n At best, its introduction will be the reason to question all of that.<\/p>\n In the worst case scenario, the existing processes are simply digitally replicated.<\/p>\n Then you have less Excel and fewer emails \u2013 but still the same bad process. Just faster.<\/p>\n Therefore, we do not begin digitization projects with the question: What software do we need?<\/b><\/p>\n But rather: How should our shopping process fundamentally work \u2013 and what is preventing us from doing so today?<\/b><\/p>\n<\/div><\/div><\/div> 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?<\/p>\n The target image does not have to be static. The specific implementation can change \u2013 the process vision provides the direction.<\/p>\n The next step is to reflect today's world against this vision.<\/p>\n 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?<\/p>\n And most importantly: What fundamental process errors would we merely digitize with new software?<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/b><\/p>\n 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.<\/p>\n However, this only fulfills one prerequisite for successful digitalization. Many years ago at BCG, I learned a term for this that I still like today: "Self-Discovered Logic".<\/p>\n The idea behind it is simple: solutions are not developed for the people who will later implement them, but with them.<\/p>\n 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.<\/p>\n That's exactly what I consider crucial in digitization projects.<\/p>\n 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 \u2013 even if they make technical sense.<\/p>\n Therefore, I would involve future users early on.<\/b><\/p>\n Not because everyone has to vote on everything. For me, acceptance is therefore not a soft factor that one only deals with after the technical implementation. What are the practical implications of this?<\/p>\n For me, this results in a five-step approach for greater digitalization in purchasing:<\/p>\n If we cannot answer these questions, at least in their basic outlines, then in my view it is too early to select software.<\/p>\n In one of our projects for an international company with a procurement volume of around \u20ac350 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.<\/p>\n 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.<\/p>\n The result was significantly faster and more transparent procurement processes.<\/p>\n<\/div> For me, that's the crucial point: Neither the software nor the perfect target process were present at the beginning. This applies to e-procurement and ERP systems \u2013 and even more so to AI. The more technology automates, the less we can simply automate unclear processes, poor data, and ambiguous responsibilities.<\/p>\n Especially with AI, new use cases can simultaneously lead to thinking about processes differently than was possible in the previous system world.<\/p>\n 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.<\/p>\n Therefore, the crucial question before the next digitization project is not just: Which software can do it?<\/p>\n But first: How should our process fundamentally work, what is preventing us from doing so today \u2013 and what possibilities offered by new technology can help us get there better?<\/b><\/p>\n<\/div> The best software can't save unresolved processes. But it can make them impressively fast.<\/b><\/p>\n<\/div> \ud83d\udc49<\/b> <\/b>More on this topic:Digitization is an amplifier<\/h3><\/div><\/div><\/div>
![](\"https:\/\/emarticon.de\/wp-content\/uploads\/11-Impuls-Foto.png\")
<\/span>Process vision instead of process perfection<\/h3><\/div>
\nThe second point is at least as important: The people who will later work with the system must understand and support the change.<\/b><\/p>\n<\/div><\/div><\/div>Acceptance is part of the system design.<\/h3><\/div>
\nBut because their knowledge is needed \u2013 and because people need to understand why their work is changing.<\/p>\n<\/div>
\nIt is part of the system design.<\/p>\n<\/div>Process beats Software<\/h3><\/div>
\n
\n<\/b>But rather a clear idea of how purchasing should work better in the future.<\/b><\/p>\n<\/div>
\nRead how Emarticon supports companies in digitizing their purchasing function:
\n\u2192 Digitalization in purchasing with Emarticon<\/a><\/p>\n<\/div><\/div><\/div><\/div><\/div>