AI in SAP projects: coding is the smaller half
“What is our AI strategy for the S/4 programme?” — the question now comes up in every steering committee. The answer that comes back is usually a list of tools: a coding assistant for development, a chat tool for everyone else, maybe a pilot for test cases. Three pilots, three contracts, three conversations with security and the works council.
What that list leaves out is the larger part of the project.
A project has two halves
Writing ABAP, building Fiori, working through test cases, migrating data. Craft with a clear result — and served by good AI tooling that runs in the development system, with a human reviewing the output.
What does the system do today, what of it stays, what goes, what does the change cost, how do we document it. The part most project months are spent on — and the part almost nobody has a tool for.
For the left half, the AI question is largely settled. Mature coding assistants speed up developer work noticeably, and the usual setup — development system, tight scope, human review — is defensible. That half is not the problem.
The right half is. It carries the bigger effort block in a transformation, it ties up exactly the people you need for decisions, and in most AI strategies it is simply not covered.
Why generic tools fail there
The obvious move is a general chat assistant for everyone. It knows a great deal about SAP in general and nothing about yours. Asked which purchasing process variant carries your volume, it can only answer generically — and unfortunately it does so fluently.
The second move is an agent with a live connection into the system. That one knows your system, but it pays for the knowledge with an architecture that has to clear security, Basis and the works council; and it still does not know what it has not yet seen. Why that deserves its own discussion is covered in attached vs. detached and on the AI strategy page.
Both fail at the same point: the missing piece is not the model, it is the knowledge base. AI can only contribute where someone has first assembled what this system actually looks like — completely, structured and current. That groundwork is precisely what none of the pilots brings with it.
Once the foundation is there
With a structured as-is picture in place, “AI use case” stops being a project of its own. It becomes a property of the platform people are working in anyway:
- Questions about your own system. Which transaction is barely used in which company code, which feature usage has dropped to zero, which feature a custom development belongs to — answered on your data, not on general knowledge.
- Assessing custom developments. AI reads the source of your Z objects, describes their purpose and function and places them in business context — backed by anchors in the code such as tables, transactions and function modules, instead of a 0-to-100 score nobody can argue with (custom code analysis).
- Preparing scope decisions. What stays, what goes — with the real usage per company code right next to it, and measured against the scope items of the public cloud standard.
- Drafting functional specs and documentation. The assistant proposes chapters for your knowledge base, condenses them and checks them against the real data; what gets accepted is your call. How that works in detail is covered in Can AI write functional specs?.
That is the actual point: not four tools for four use cases, but one body of data that four questions reach into. The effort sits in the foundation, not in the next pilot.
The three questions every AI strategy has to answer
Picking tools is the easy part. An AI strategy gets approved — or doesn’t — on three other questions, and they come from your data protection officer, your works council and your controller, not from your architect.
1. Which data leaves the building, and where does it go? Not “are we using AI”, but: which classes of data go to which vendor. In Conjola you can store your own LLM key — your contract, your terms, your processing commitments; currently for Mistral, a European provider. And because the platform is detached throughout, the volume that could ever be in scope is defined upfront: the extract you released. No open line into production from which a model requests more at runtime.
2. Who may do what — and what may the machine do in their name? The assistant’s capabilities are assembled per request from the module licence and role permissions of the user asking. The sentence behind it: a skill never sees more than the person who triggered it. A setting can only narrow that boundary, never widen it — a misconfiguration cannot hand anyone access they would not have without AI.
And access is not the same as authority. “The editor may set dispositions” is a different statement from “the AI may do so unsupervised”. So the assistant in Conjola does not write on its own: it makes proposals, and nothing is saved until a person accepts it — with that person as the accountable author, not a system user.
3. What does it cost, and who sees the bill? Every request to a language model costs real money, and without a cap nobody slows down. Because the access is yours, consumption runs through your contract rather than an opaque flat fee; every request is logged with its token usage, and on top of that a monthly budget per tenant sets a fixed cap. Cost becomes something you set upfront — not something you discover in the first provider invoice after rollout.
Answer those three questions once for a platform and you don’t answer them again for every further use case. Answer them for three pilots and that is exactly what you do.
Assistance for everyone on the project, not just developers
The copilot pattern distributes AI along the development organisation: if you write code, you get an assistant. In a transformation the effort sits elsewhere — with the process owner who needs to know how often their workaround is really posted; with the consultant writing a functional spec; with the key user who has to justify a decision; with the project lead who needs a status report.
In the usual setup those roles get no assistance at all — or one that doesn’t know their system. Yet they are already working with the data. The assistant belongs where that work happens, and with the same rights those people have there.
What honesty requires
Conjola does not write code and does not migrate data. The left half stays the left half — there are other, good tools for it, and they rightly run elsewhere. We don’t solve the question by claiming to do everything.
AI produces drafts, not decisions. A generated spec, an assessment, a summary are solid first passes that save weeks of legwork. What is kept, cut and decided differently is on the people accountable. The difference from a pilot with a generic tool is this: you argue about content instead of about whether the basis holds at all.
An AI strategy for an SAP project is not a list of tools. It is the decision about where the machine learns what your system looks like.
That is exactly what Conjola is built for: read-only extracts from your system, and once they are in, a structured as-is picture of feature map, real usage and custom code is ready on the next business day, along with processes and master data quality. On top of it a knowledge base with an assistant that every project role uses, each with their own rights, through your own LLM key if you want. With no live connection into your SAP system — detached throughout.