Explore phase

AI usage in companies is still at a very early stage. Companies and their developers are still in the learning phase. While it becomes more and more common to include AI in the daily tasks; be it from normal office work like e-mails, to app development, we are still in an early phase. Adoption is still rising and boundaries are shifted. What seemed like an almost impossible task a few months ago is now only the question of cost justification.

Looking from an ERP side, and specifically, from an SAP point of view, AI is currently used to speed up development. Time needed to get from idea to app or to improve an existing app. Promoted AI use cases are often what was once promoted as the citizen developer approach. A task needs an app, or an enhancement, and with AI this is done in no time. Once we had demos that promised us to get a (mobile) app in 5 minutes. Now we have demos focused on how to solve a business problem in 5 minutes. Set the boundaries, add the tools, write your goal down in a few sentences and problem solved. Difference is that not only the UI is build, but the underlying logic, data handling and integration. Good AI takes into consideration to build things enterprise ready, adds (unit) tests and follows coding standards.

Transformation of legacy solutions

One strength of this development focused approach is that it allows to work with legacy coding. LLMs are good when it comes down to text. Reading through thousand loc and documenting it, spotting (simple) errors? No big problem. When you have to improve your code in e.g. an S/4HANA transformation project, AI helps. What would have taken one person 1 day, the AI does in minutes. The same person finish the work of a week before lunch. The second half of the day can be focused on overall code quality by improving test data and coverage. This faster and better approach is bought by developers, consultants, managers, the company. It’s a win:win for all. Specially when a company needs to transform decades old apps to S/4HANA. The original team members are not available any longer, the code might do obscure things, documentation is outdated. AI can help to understand even why it is working.

AI can enable us to do things that currently are simply too much work. If currently a task to refactor an app is skipped as it means to bind too much resources that are otherwise needed, AI enables to get this refactoring done. From a report with WRITE statements to ALV usage? Create a CDS View on top of a table? Optimize SELECT statements? Done in a fraction of time. One sweet spot currently harvested by companies is to use AI to accelerate the transformation to S/4HANA. Legacy code is made ABAP Cloud ready.

This helps in renewing what a company already has. The problem with this approach is: it comes from a “legacy” problem. AI is used as a performance booster. You get faster, not necessarily better.

Improve

Remind yourself why companies opted to use an ERP system in the first place: to run their business processes. To be able to write a process in code. Enabling companies to do this is one of the benefits SAP offers and why it is chosen so many times. The business process is available in code, making it configurable and adjustable. SAP comes with a platform to capture new processes in code; including all the other benefits the SAP platform provides automatically.

Understanding how information is processed is important. Companies like to measure things, to know if they are meeting their expectations. Where is the information processed, how long does it take, is there a problem in the process? SolMan had this as a benefit for business analysts, Signavio or Celenos offer this too. Looking at the truth - the source code - AI can understand how information is processed by the current system. This is better compared to going through the external captured information like process, functional or architectural documentation. The external documentation states how it should be, or how it once was planned to be. The source code defines how it is. AI can go even further than just understanding when looking at the source code. It can find patterns and improve the business process by adjusting the coding.

The improvement is the important part. Instead of needing an army of business, requirements, technical analysts, AI can do this job. It knows more languages and patters than a person can do. Trained right, it knows how software works. No need to teach your AI what mutation testing 🔗 is. It knows it 🔗. The AI must “only” know how business process work and it can use that knowledge to check the current implement process in a company. And it can do so indepently from the technology. And that’s the benefit AI offers. It allows to focus back on the main reason why an ERP system is used at all: to have the business process transformed to code. Code can be run on a computer, it can be adjusted, changed, rewritten, measured, … Make a company perform.

While the assumption might be that a business process is stable and rarely changes: they change all the time. External or internal factors influence constantly how a process is designed. While the overall, higher-level processes like e.g. I2M 🔗, O2C do not change, the individual steps do. Currently, it is rather the static, monolitic nature of the (ERP) systems that make adjustments to a process rather complicted and time consuming. Maybe not so complicated outside the core ERP processes. Yet, even there, a change needs to be captured, prioritized, implemented, tested, approved, …

Understand

An AI that understands how a company works, what the requirements are and that can translate that context into code, changes how a business operates. People are not bound to work with a specific app / transaction. They work with information. Information needs to be transformed, adjusted, moved, stored: all of that is realized by code. When the AI knows what is needed, it can write that code. The more it knows, the better it gets at offering tailored solutions and apps. End users are rarely a fan of a software vendor or their solutions / apps. When they work at company A that uses Oracle and Microsoft Office, they are using that tooling. When they switch to company B, which uses SAP and Google Workspace, they are using those tools. That something needs to be done in a given system is bound by the current skillset available. An ABAP developer will develop an ABAP app for a task and not buy a SaaS solution or develop a new one in Java. Which also answers the question why some companies stick with their software provide. They could switch, but the effort of redoing things, retraining, hiring, … all the change management involved is just too much of an effort. Customers might be not satisfied with their ERP system. The pain is however not strong enough to go through the pain of changing it.

This skill shortage does not exist with AI. The AI knows several programming languages, the business processes. It can be trained to understand the context, the business and legal requirements. It can know how these are realized by different ERP vendors. The AI can be used to transform a business process to code. And make it run wherever it fits best. For the users, this means: they can focus to work on information. What is needed, what is the output, what is missing to make it work. The solution might be planned by the AI to run on the best fitting platform, with the best integration, deployment. The user might not necessarliy notice this. App A is on Azure, app B in SAP, app C on Google, Infor, Oracle, and all are consuming data exposed though an API Hub. The task of selecting the best fitting platform for an app can be outsourced to an AI that knows what the different vendors offer, and to which ones the company already has a contract. Or what is generally allowed: SAP, k8s, Azure, Java, …

This might sound like a nightmare for developers, consultants or architects. But we have to remind ourselfs: for the company, what counts, is that the process works. That the employees can work with the information provided to get their job done. If this means that one process is on SAP, another one non-SAP: this is irrelevant. The important questions are:

• Does the process work?
• Can the company later adjust easily the process and adopt to changes?
• Is it efficient?

The parameters are of course decided by humans. Realizing it, the AI supports. When all is documented and defined, switching ERP releases or vendor is then a task for the AI: rewrite the app to so it fits the requirement.

Imagine this scenario: a new (sub-)process needs to be implemented. The AI knows the base process, legal constraints, context, company archictural specifications, the available systems, capabilities, etc. The AI might capture the requirements and come to the conclusion that there is already a standard app available. Only an enhancement is needed. Or that from vendor A, which the company has a contract with, offers a solution that fits 90%. Or that a custom app is needed that is best run on-stack on SAP’s S/4HANA. And then starts the implementation. An app released, using the beset available option, in days or weeks. And when the context changes, the app changes too.

Yes, this means: best of breed. Best of breed based on business requirements. Not on available skills and resources. Of course, there is more to it than just being able to develop and run an app on several platforms. The UX is important. You still want to hide the complexity from the users. You want to benefit from this, so the apps and their runtime must be constantly evaluated. Processes must be measured, people must know how to use all this data. This approach implies that several parts are touched: frontend, integration, backend, storage, … This is an approach that is citizen developer or low-code/no-code on a new level. It solves the current LC/NC problem of missing APIs. The AI can create those, together with the frontend. It is a 360° approach.

Documentation

Today this is still not doable for (almost?) everyone. It might also not doable for time to come. Too many times the basics like documentation is missing. Or is outdated, in a proprietary format, sometimes not even accessible, as it is locked behind a closed vault only a few people have access to. Accessing the documentation is often already a long term project. And a costly one. Architecture diagrams available as a 30 year old gif first must be transformed so the AI can read it. Documentation locked in Word, PDF, PPT needs to be extracted. Functional documentation scattered accross 154 documents, of which 23 are missing. A TOC that lists 100 itens, but only 87 are in the document, and 20 of those describe facts that contradict the general assumptions outlined on page 3. Finding out from the vendor documentation what their software can do is a challenge harder than it should be. Sometimes access is restricted, forbidden, and / or incomplete. Training material might be better than the official documentation. At least here the reality helps: companies often created a impressive amount of internal training docs for their employees that well documents how the software and their processes work. And all must be transformed into an AI friendly format. On the source code side, challenges are not eliminated. Dead source code, strange interface decisions, a trigger done by email, background job run by a user that left the company 5 years ago, code distributed on several servers, in different versions, with no source code control in place.

Next challenge is that AI can be brutal: if it is not very well defined what a business process is expected to do, AI can will fail to deliver. It reveals what is missing. The specification gives the AI a few options too much and room to improvise? Nothing you want when it comes to important business processes. When your FI processes are on SAP, you might not wnat the AI create a new FI app outside that scope, adding integrations, security, etc, just because the requirements states: select the best platform for modern apps. The AI might interprete modern as cloud native and not as in modern SAP with Fiori Elements. Scope must be provided.

But this is also where the top-down approach - where you come from enterprise architecture and documentation - might fail. There are not 100% clearly defined documents at customers. Those were once written by humans, for humans. Here, the code-based approach is better. But it also needs documentation to understand if what is discovered, is correct. Context is important. The code won’t reveal that an app might be better run outside the platform, on e.g. Azure, and not inside SAP. The documentation, the architecture decisions, the context, might show this to the AI.

Both are needed. Architecture documentation will get more and more important. A good documentation will be the differentiator between usage of AI, and a good usage. Knowing how to implement a solution, understanding the code base, how the coding going to be used, that is what will bring an exceptional good AI usage.