First the Process, Then SAP. Why SLA Alone Is Not Enough?

A System Change Is Only One Possible Solution

Let’s imagine a situation that regularly occurs in various forms when working with ERP systems. Users report issues related to the same stage of a process. Support analyzes the ticket, identifies a solution and closes the case. Everything is handled according to the agreed SLA.

At the level of a single incident, it is difficult to say that anything went wrong. The user received support, the issue was resolved and both response and resolution times met the required targets. A few weeks later, however, another ticket appears concerning the same area. Then another one follows.

This is the point where it becomes worthwhile to look at the situation more broadly. We can resolve each ticket quickly and in line with the SLA, yet still fail to improve the situation in the long run. A report showing the scale and frequency of similar issues can also be extremely valuable.

The Ticket Is Solved. The Problem Still Exists

SLAs are important. They establish the rules of cooperation, allow response and resolution times to be measured and provide both parties with a clear point of reference. Most importantly, they help determine whether an incident has been handled properly. However, metrics alone do not tell the entire story.

From the perspective of the overall service, it is equally important to understand whether our work reduces the likelihood of similar situations occurring in the future. This does not mean that every incident should result in a root cause analysis or a major improvement project. That would be inefficient and often unnecessary. However, when we notice a recurring pattern, it is worth paying attention to it. A series of similar tickets may indicate that the source of the issue lies deeper than a single error.

In such situations, it is worth reviewing previous cases together, identifying relationships and determining whether the applied solutions actually eliminate the root cause or merely allow work to continue. Increasingly, analytics and AI-powered tools are helping to perform this type of analysis.

What Are We Actually Trying to Fix?

At first glance, this may seem like a simple question. In practice, it is not. A user reports that they cannot proceed. The business says the process is too slow. The consultant sees a system error. The developer receives a request for a change. All of them may be correct, but each is viewing the situation from a different perspective.

The challenge appears when we start solving a technical issue before fully understanding the business need. In our example, recurring incidents may suggest the need for a change in SAP, but they may just as easily point to unclear working practices, data quality issues, a lack of responsibility for a particular process step, or a solution that no longer reflects the actual way the organization operates.

Initially, all these situations may look similar, appearing to be simply “an SAP issue.” In reality, however, they can lead to very different solutions, ranging from a configuration change to a system enhancement.

SAP Is Part of the Process

An ERP system does not operate independently of the organization. Behind every workflow, validation, form, or automation are people, responsibilities, and established ways of working. Therefore, a problem visible in SAP does not necessarily originate in SAP.

It may result from the way data is prepared, a lack of clear ownership, or the fact that different teams understand the same process step differently. Sometimes the cause lies in history. A process was designed years ago, the organization evolved, new roles and requirements emerged and additional exceptions appeared. The system was modified step by step to keep pace with those changes.

Each individual decision may have been justified at the time. After several years, however, the overall process can look very different from its original design. That is when it becomes valuable to take a step back. Not to look for someone to blame, but to verify whether we still understand how the entire process is supposed to work. This applies equally to SAP ERP, SAP ECC, and SAP HANA environments.

Taking a Step Back Does Not Mean Stopping

In IT environments, it is easy to assume that every need should immediately become a development task. However, development is not always the best first step.

Sometimes it is more productive to speak with the process owner, walk through the entire journey with the user, or investigate what happens before the point where the issue appears. It is also worth examining how the process works in practice, not only how it is described in documentation.

Only then is it easier to determine whether a system change is truly required. Although this approach may seem slower, it often helps avoid work that later proves unnecessary. It is also an important aspect of project planning, project execution, and effective change management.

Not Every Change Is Neutral

A change in SAP does not end when it is deployed. It must be planned, tested and documented. In some cases, users also need training. New dependencies emerge, which can affect future modifications. There is also another factor that is not always visible when decisions are made: the cost of maintaining the solution.

Today, we introduce one exception to handle a specific case. A few months later, another exception is required, followed by another one. Over time, the SAP system may begin to reflect not a well-designed process but rather the history of every issue we attempted to solve through individual changes.

Of course, not every modification leads to this outcome. The point is to remain aware that every technical decision has consequences. Before implementing another change, it is worth considering not only whether it is feasible, but whether it is actually the most appropriate way to solve the problem. This becomes especially important during implementations, system rollouts and major IT transformations.

Where Does Service Support Fit Into All of This?

For me, this is where the more interesting part of the job begins. Support should not be merely a place where problems arrive and disappear once a ticket is closed.

Daily operations must function properly. Users need answers, the business requires continuity and agreed SLAs must be met. At the same time, a project team or support team that works with a service over an extended period develops knowledge that cannot be found in documentation alone. They know which issues keep returning, where users most often encounter difficulties and which process elements require the most attention.

When another similar ticket appears, they may recognize patterns that are invisible when reviewing a single incident. Such observations can become the starting point for meaningful improvements, trend monitoring and more effective reporting.

SLA and Continuous Improvement Should Complement Each Other

I do not see SLA and Continuous Improvement as two separate approaches. SLA helps us evaluate how effectively we deliver a service today. The analysis of incidents, problems and processes helps us understand how the service can operate more effectively tomorrow.

One without the other may be insufficient. We can achieve excellent SLA results while still dealing with a high number of recurring incidents. Conversely, we may have only a few tickets while relying on a process that is complex, manual and dependent on the knowledge of individual employees.

This is why KPIs alone do not always reveal where real improvement opportunities exist. Sometimes numbers need to be combined with the experience of people who work with the service every day. This is particularly important in organizations undergoing migration projects, SAP implementations, or SAP modernization initiatives.

Continuous Improvement Does Not Mean Constant Change

This is probably one of the most important lessons I have learned from working with processes.

Improvement does not always mean a new feature, additional automation, or another project. Sometimes the improvement is removing an unnecessary step, organizing data, or clarifying responsibilities. In other cases, it may involve updating instructions that no longer reflect how the process actually works. Sometimes it is simply better communication between teams.

And occasionally, it means deciding not to change anything in SAP for the time being.

This can be particularly challenging because, in the IT world, change is often associated with progress. In reality, not every change improves a process and not every automation simplifies work. Sometimes optimizing data and processes delivers greater value than continuously expanding system functionality.

Ultimately, It Is About Making the Right Change

I am not an advocate of the approach:”Let’s avoid changing SAP because the problem might be in the process.” System changes are often necessary and can deliver tremendous value. The key point is the sequence.

First, understand what we are truly trying to improve. Then examine the process and identify the underlying cause. Only after that should we decide what the best solution is: a change in SAP, a process adjustment, data cleansing, better communication, or perhaps a combination of these elements.

I have the impression that it is becoming increasingly easy to forget this order. The pace of work, pressure for quick solutions and expanding technological capabilities encourage us to move directly from problem to answer. Especially today, with cloud technologies and evolving SAP solutions offering more possibilities than ever before. Sometimes it is worth taking a step back. Not to slow down change, but to gain greater confidence that we are changing the right thing.

A good change, therefore, does not begin with the question: “What should we change in SAP?” It begins with a simpler question: “What are we actually trying to improve?” Only then can we consciously plan a new implementation, further develop the SAP ERP landscape and effectively support the organization’s future growth.