System Change as an Organisational Question
Why a new system often doesn't solve a problem, even when the technology works flawlessly.
A new system is introduced, with the hope that many things will become easier afterwards. A few months, or even years, later the processes are indeed mapped in new software, but the actual frustration in daily operations is still there. That is not a sign of the wrong software choice. It is a sign that the real cause was never clarified.
The pattern behind the decision
A system often becomes a collecting point for frustration that actually comes from somewhere else. Unclear responsibilities, processes that nobody enforces consistently, interfaces between departments that were never cleanly defined. All of this is hard to pin down, whereas a new system is concrete, budgetable and easy to decide on. So the investment is made, on the assumption that the technology will solve the problem along with it.
What a system change makes visible, but does not solve
A system change makes existing problems visible. It does not solve them by itself. If two departments were already not in agreement about who is responsible for a process step, a new piece of software does not automatically settle that question, at most it forces the question to finally be answered, often in the middle of the rollout, under time pressure and without the care it deserves. The result is a system that works technically, but has only postponed the actual question rather than resolved it.
How we approach this in practice
That is why a system project with us does not start with selecting a provider, but with an as-is analysis. We go after problems, not symptoms, and clarify which requirements actually stand behind them before the market is evaluated. Only after that comes the structured evaluation, with a value-benefit analysis and support through to go-live or handover into operation. This order is deliberate. Selecting a provider without a clarified starting point almost always leads to a system that simply carries the old questions forward.
Typical situations
This shows up regularly in projects where an ERP system is introduced or a payroll process is outsourced, as well as in IT and process landscapes spanning multiple companies that have grown historically rather than being deliberately designed. In all of these cases, the software is ultimately a tool. The real work happens before that, in clarifying what the system is actually meant to achieve, and whose responsibility what is.
What this means for your next system project
Before a shortlist of providers is drawn up, it is worth asking which problem the new system is actually meant to solve, and whether it is really a technology problem. Often it only becomes clear during this clarification what a new system needs to deliver, so that it does not produce the same outcome as the old one.
If you are facing a system decision and are not sure whether the real cause is already clear, an initial, non-binding conversation is worthwhile. We clarify the starting situation together before anything is commissioned.