Optimize or Change BPM System | brix Solutions AG - brix

The new process system is live – but the successes are absent. Before further budget is allocated, it's worth asking a question that is often asked too late: Is the problem with the system itself or with how it is implemented and used?

The implementation is complete, the budget is exhausted, and in everyday life, it becomes clear: The system does not deliver what was hoped for. Departments work with workarounds, documents are kept in parallel in Excel or on paper, and IT reports the need for adjustments – but there is no more money allocated for that. The obvious reaction – applying for additional budget or immediately tendering for a new system – requires an answer that usually no one knows yet.

Because whether a system is not the right one or just not used correctly looks the same from the outside. Those who do not clarify this question risk two wrong decisions: They continue to invest in a system that fundamentally does not fit. Or they replace a system that would have worked perfectly with a few adjustments. Both are expensive.

In this article, we show you how to clearly separate the causes, based on which criteria you decide between optimization and change, and where a structured inventory begins.

Is it the system – or the implementation?

A process system rarely fails due to a single cause. Usually, three levels overlap, which must be considered separately:

System capability: What can the system fundamentally do – regardless of how it is configured today?
Usage: Which of these functions are actually used, by whom, and with what acceptance?
Integration: How well is the system integrated into processes and the IT landscape – or do new media breaks arise at the interfaces?

The distinction sounds trivial, but it fundamentally changes the consequence. If functions are missing, only further development or change will help. If an existing function is not used or not used optimally, the solution lies in configuration, training, or clear responsibilities. Why common standards have more impact than any tool is shown in our article on process management in administration. If the cause lies in integration, often neither the system nor the users are the problem, but rather an integration that was not fully thought through during implementation.

Especially projects under time or budget pressure typically go «live too early»: the system runs, but roles, standards, and connections have not yet been fully considered. The symptoms then appear in operation: applications remain pending because no one is assigned the approval, or data is manually transferred between applications because the interface is missing. They are then attributed to the system.

Why a subsequent investment is rarely the best solution

More budget only solves a problem if it is clear which one. Without diagnosis, additional money typically flows into symptom treatment: further adjustments, additional modules, external support for individual cases. The actual cause remains.

Moreover, in the Business Process Management Study 2025 by ZHAW, the latest independent survey on process management in Switzerland, Germany, and Austria, 92% of respondents stated that software-based BPM tools will remain at least equally important or gain significance in the next five years. Process systems thus remain a fixed part of the organization – all the more reason to base the decision about their future on a thorough diagnosis. Only then can additional budget be justified – or a system change.

Optimize or switch? The five most important criteria

Whether an existing system should be optimized or replaced cannot be answered in general terms. The following five criteria are the most important and make the decision understandable – even to steering committees.

1. Technical Coverage

Does the system fundamentally meet the requirements? If central functions are missing and are not foreseeable on the manufacturer's roadmap, this suggests a change. If they are only missing in the current configuration, it speaks against it.

A first impression can be gained from a simple list of must-have requirements. For each requirement, it is noted: Does the system already fulfill it, could it be implemented through configuration, or is it completely missing? This quickly reveals where the actual gaps lie. For these, it is worth inquiring with the manufacturer whether they are on the roadmap.

2. Usage and Acceptance

Are the available functions actually being used? Parallel lists, manual workarounds, and low system usage are often signs of a lack of training, unclear responsibilities, or unintuitive user interfaces. These challenges can usually be addressed specifically – without changing systems.

Conversations with some users from different areas are often insightful: Which tasks do they perform outside the system, and why? If answers like «too complicated» or «I don't know how to do that» regularly come up, the cause is more likely related to training or configuration than to the system itself. Why acceptance is often more important than the method, you can read in our article «Why even the best methods fail when employees don't cooperate».

3. Integration into processes and IT landscape

Are specialized applications properly integrated, or is data transferred manually? If only a few integrations are missing, they can be retrofitted – this suggests optimization. If the system does not offer open interfaces through which specialized applications can be integrated, this suggests a change.

A simple system overview can be helpful: With which systems does the process system exchange data, and does each of these connections run automatically or manually? Every manual transfer is a potential starting point. Whether gaps can be closed also depends on whether the system offers documented programming interfaces.

4. Scalability and Operation

Does the system also hold up when additional processes, departments, or users are added? And is the operational effort – updates, maintenance, internal know-how – sustainable in the long term? Especially when the knowledge about a system is concentrated in a few individuals, operation becomes a risk. If this risk can be mitigated through documentation, training, and clear responsibilities, it speaks for optimization. If the system reaches technical limits with growing usage, it indicates a need for change.

A starting point can be to note who actually manages updates, permissions, and troubleshooting. If only one name is associated with a task, it's an indication that documentation and a deputy are missing. For scalability, the planned expansion – more processes, more users – can be matched with the manufacturer's performance specifications. In our article «When the Know-how Retires» you will learn, using the example of public administration, why it is worthwhile to strategically prepare here.

5. Exit capability: Can you take your process models with you?

Exit capability describes how easily an organization can detach itself from a system without having to rebuild its process models, data, and workflows. If it is lacking, it is referred to as vendor lock-in: a change becomes so cumbersome and expensive that the organization remains effectively tied to the manufacturer – even if the system no longer fits. This criterion is often overlooked during implementations and becomes crucial at the latest when considering a change. Are your process models available in an open standard like BPMN 2.0 or only in the manufacturer's proprietary format? Who owns the data, and can it be fully exported? Are central workflows dependent on functions that are only available from a single provider? For organizations that need to maintain control over their processes and data – such as in public administration or regulated industries – exit capability is not a technical detail but a governance issue.

The true extent of dependency is revealed, for example, by a test export: a typical process model is exported as a BPMN file and opened in another freely available BPMN tool. What is lost in the process makes the dependency on the manufacturer visible. Additionally, it is worth taking a look at the contract to see if the release of one's own data is regulated.

Whoever answers these five criteria can justify the decision, identify risks, and strategically allocate the budget. If the balance favors a change, the work begins with a structured overview of the suitable tool landscape – from low-code approaches to comprehensive BPM systems.

Conclusion: First the own system, then the market

Whether an overview of new tools is necessary at all is only revealed by a structured inventory of the existing system. It separates system boundaries from implementation and usage problems and shows whether targeted optimization is sufficient or a change is necessary – regardless of whether ADONIS, Camunda, TIM Flow, CIB flow, CIB seven or another system is in use. The five criteria provide an initial framework for this. However, the picture only becomes reliable when the answers are combined and externally reviewed: an external view recognizes patterns that have become habitual internally. This way, you allocate the budget where it is effective – and can justify the decision transparently to committees.

Does your process system still meet your requirements?

With a BPM system health check, we independently assess your setup before you reinvest or put out a new tender. Kevin Lang, Head of BPM, and his team will guide you from analysis to recommendation.

The system is running, but success is lacking – what now?