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 plants still post through a workaround, which feature usage has dropped to zero, where a custom development hangs off a process — answered on your data, not on general knowledge.
- Assessing custom developments. AI reads the source of your Z objects and returns findings with a location — cloud readiness, retirement candidates, business classification instead of a 0-to-100 score nobody can argue with (custom code analysis).
- Preparing scope decisions. What stays, what goes, how far a process sits from the public cloud standard — with the document volumes right next to it.
- Drafting functional specs and documentation. The assistant writes chapters in your knowledge base, condenses them and checks them against the real data. 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 configure your own LLM access — OpenAI, Gemini or Mistral, your contract, your terms, your processing commitments. 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 level of autonomy per capability group is its own setting, with three steps: off, draft only — the AI computes and proposes, nothing is persisted — or execute, within the rights of the user. Anyone who doesn’t reject AI write access outright but wants to release it after a settling-in period needs exactly that middle step. And whatever an AI capability creates or changes appears in the changelog as an AI action — with the human who triggered it 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 sit a monthly budget per tenant, an early warning before it runs out, and a comprehensible refusal in the chat instead of a stream that just dies. 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: one read-only extract from your system, turned within roughly 24 hours into a structured as-is picture of processes, feature map, custom code and master data — and on top of it a knowledge base with an assistant that every project role uses, each with their own rights, through your own LLM access. With no live connection into your SAP system — detached throughout.