SAP Project Knowledge on Demand: The Value of AI for SAP Environments

Germany is facing a significant loss of expertise. According to calculations by the Federal Statistical Office, by 2040, approximately 13 million people in the labor force will have reached the statutory retirement age. This represents 30 percent of today’s labor force. As a result, a wealth of practical knowledge built up over decades will be lost. Deloitte is already referring to this as a „knowledge exodus.“.

According to its own survey, 92 percent of the companies surveyed do not consistently capture and document the knowledge of their employees who are about to retire. As a result, critical knowledge often remains in the minds of individual experts rather than in the systems. Gartner also sees a growing „expertise gap“ caused by retirements and technological change and urges companies to organize their knowledge transfer as an ongoing process.

This is also a critical issue for many SAP environments that have been built up over the years, because here, too, a large part of the expertise resides in the minds of experienced developers and consultants. This problem is usually addressed with extensive documentation and staff redundancy, but the challenge lies in retrieving information: Having to wade through a mountain of documents just to understand a small program is not only tedious but also time-consuming and costly. Generative AI now offers the possibility of not only documenting some of this experiential knowledge but also making it immediately available within the development process.

Knowledge has several levels

In AI-powered software development within the SAP environment, three levels are interlinked:

General knowledge of the AI model: A language model is familiar with programming languages, typical software architectures, and many common development methods. It can generate, explain, or verify code and is familiar with numerous publicly documented procedures. However, this knowledge is general in nature. Initially, the model knows neither what software a particular company uses nor how processes are organized there or how applications have been customized.

SAP-specific knowledge: On top of that comes knowledge of the SAP world. SAP therefore supplements generative AI with its own information and functions, for example in Joule for Developers. This enables the AI to take SAP-specific development rules into account or, during an S/4 transformation, to analyze and adapt existing in-house developments. This layer, then, understands the technical rules and specifics of SAP—but not yet the specifics of a particular SAP installation at a customer site.

Customer and Project Knowledge: This third layer is created within each individual company. It includes the company’s own definitions, custom extensions, interfaces, development standards, and decisions made in previous projects. This also includes the question of why a particular process was implemented exactly that way years ago. Neither SAP nor a new, more powerful language model can automatically possess this knowledge, as it stems from the specific customer and project history.

The third level is particularly important for SAP users. While SAP provides the general technological and functional foundation, consulting firms such as Abat expand on this foundation with their knowledge of how a specific customer’s SAP landscape is actually configured.

Project knowledge in machine-readable form

The SAP service provider Abat has developed its own approach for this, in which a large portion of the developers’ and consultants’ knowledge is stored in a machine-readable format. This is done using two levels of knowledge: The first consists of what are known as “skills.” These are based on Markdown files in which developers describe rules and experiences in a way that allows the Development Assistant to automatically take them into account. This includes technical development knowledge as well as AI behavior: if information is missing, the assistant should ask for it rather than inventing a supposedly plausible answer. Knowledge that used to be disseminated through training, wikis, or personal sharing now flows directly into the development process. New insights gained from the projects, in turn, are fed back into the skills.

The second layer is an embedding or vector database operated by Abat itself. More extensive company and customer knowledge can be stored there: documentation, terminology, project-specific details, or information about how certain processes actually work. This database can be connected to various language models. This creates a strategically important separation: the development and customer knowledge built up over many years—one of the company’s most important assets—remains within the company. Nevertheless, companies can still participate in technological AI development, as the underlying language model can be replaced at any time.

Development Guidelines

This approach becomes particularly evident when it comes to SAP-specific rules. Abat, for example, defines skills for RAP development, Clean Core, or HANA-compatible coding. In addition, there are proprietary standards regarding modularity, interfaces, and maintainability. As a result, the purpose of this information changes.

A Clean Core guideline is no longer just something outlined in an architecture document that a developer needs to be familiar with. It can be incorporated directly into code generation as a machine-readable guideline. In S/4 conversions, for example, rules can take into account which older ABAP constructs are problematic in HANA. SAP is also continuing to pursue this direction. The roadmap includes, among other things, AI support for Clean Core-related ATC findings as well as agent-based functions for ABAP.

This is particularly interesting for SAP users because new developments almost always interact with existing extensions and customer-specific rules. The more of this information is available in a machine-readable format, the less the quality depends on the developer's specific knowledge.

However, machine-readable knowledge is not automatically correct knowledge. The same principle applies here: „Garbage in, garbage out.“ Outdated documentation may occasionally be misinterpreted. An erroneous machine-readable rule, on the other hand, is applied again and again to every task that matches it and can have serious consequences.

Conversely, the body of knowledge must also be continuously expanded. At Abat, developers first test new ideas before they become standard practice. Only after an idea has been thoroughly tested and approved by the responsible „gatekeeper“ does a central rollout take place. So the more development is automated, the more important clear responsibilities and authorities for maintenance and approval become.

Transition to the Knowledge Problem

For the CIOs of SAP users, the primary benefit lies in continuity. When new developers join a project, part of this project knowledge is immediately available to them through the Development Assistant. This also sets it apart from traditional knowledge transfer: machine-readable knowledge can be replicated. If a rule is improved or an error is corrected in the knowledge base, the change is available to all instances working with it. A new employee, on the other hand, must first be oriented and trained. Especially in large SAP projects with changing teams, this replicability can provide a significant advantage.

But it is not only people who expand knowledge about a given SAP installation; the development environment itself does so as well. This facilitates knowledge transfer, reduces dependence on individual experts, and makes a portion of the project knowledge—which was previously tied to specific individuals—permanently available.

Stress Test in the SAP System

A recent Abat project illustrates just how relevant this can be. The starting point is an existing SAP landscape with a large amount of code that the new team did not write themselves—in other words, a situation that is part of everyday life for many SAP users. For the first of seven work packages, the effort required was more than 50 percent below the original estimate.

While working, the development assistant gradually gains a better understanding of the existing system, thereby expanding their knowledge. Later, an error was reported in this system. The assistant then provided the developer with a clue as to where to start, and the error was quickly resolved.

Knowledge as a Strategic Asset

As the use of AI grows, context is becoming increasingly important alongside the model itself. Strategic knowledge management is becoming more critical for CIOs: experiential knowledge must be captured and maintained in such a way that it remains available even after personnel changes or provider transitions. This creates a new asset for SAP users. It’s not just the code that matters, but also the machine-readable representation of why processes, code, and architecture look the way they do. An established SAP landscape becomes a machine-readable memory. Looking ahead, this approach extends far beyond coding. Abat is currently experimenting with incorporating specifications, decisions, protocols, and glossaries as well. New team members could then gain a targeted understanding of the project’s history by asking specific questions, rather than having to read through large volumes of historical documentation.

To the partner entry: