Smart use of AI in SAP teams. One real ticket done by 5 pm.

Why your SAP developers say AI does not work

When SAP developers copy a piece of ABAP into a chat window and paste the answer back, the answer is usually weak, and there is a plain reason. Your code lives inside the SAP system, not in files on a disk. The model doesn't see your Z-tables, DDIC structures, includes or naming rules, so it writes textbook ABAP that does not fit your system. The developer concludes that AI does not work for SAP.

SAP is not the problem and neither is the model. The model gets one snippet. Give it the package and the house rules and the same model writes code that compiles against your system. Exporting the package to files is enough for that; no AI has to connect into SAP. That is what the day is for.

What changes after the day

Every participant leaves with two things: a setup where Claude reads their exported SAP code, and one ticket from your backlog done with AI. Four weeks later we compare the cycle time of that ticket type with the baseline we measured on the prep day. If the number did not move, you will know which part of the setup to fix.

Already working in an 18-person SAP team

In an SAP team I work with (18 people, ABAP and reporting, client under NDA), the median cycle time in the implementation phase fell from 19 days to about 5.5 in five weeks. Resolution time on SLA tickets fell from 2.72 days to about 1.4 in the same five weeks. The average spec scored 3.3 out of 10 when we started. I can't split the 71% between the spec gate, the skills, the pairing and the incident agent, they started in the same weeks; the team's own answer is the spec gate: how it works, with the scoring rubric.

• Specs before code. SAP-related skills read the codebase to find the contracts and the relevant bugs before anyone implements.
• A spec evaluator. A specification rated below 8 out of 10 doesn't go to the team.
• An incident agent. Categorisation used to depend on one person's knowledge. The agent that took it over was built in 3 hours; the person still handles the 20% of tickets where its confidence is low, and the logs land in the Jira issue.
• AI buddies. Every developer pairs with someone more advanced in AI, with one shared set of skills and an installation guide.

The skills, the spec evaluator and the installation guide are one plugin in a private GitHub repo. Workshop teams get access, and I share it with other teams on request.

The hypothesis, in numbers

Every workshop starts with a hypothesis we can prove wrong. Below is an example for a team of 12, with targets set well below what the 18-person team reached: 30% instead of 71%. The "today" column is an example; on the prep day your real baseline replaces it, and we agree the targets together.

What it is worth. Going from 5 to 3.5 days saves 1.5 days per ticket. If each developer closes one such ticket every three weeks, that is half a day a week per developer, or 6 days a week for a team of 12. At an internal cost of 400 EUR a developer day (an assumption, your number will differ), that is 2,400 EUR a week: the workshop pays back in its first week.

When we call it wrong. If cycle time moves less than 10% by week 4, we look at which step broke: the setup (the agent can't read your code), the context (house rules missing), or the review (seniors rewrite what AI produced).

The prep day

I prepare the SAP specifics together with your SAP lead. Without this day the workshop stays generic and the first hour goes on installs.

1. 60-minute kickoff call with you and your SAP lead: the landscape (ECC, S/4HANA, BW, HANA), Jira or Azure DevOps, which AI licences people have, what may leave your network, and whether your IT allows any AI connection into SAP. Many on-premise SAP IT teams allow none, and the workshop does not need one.
2. 4 to 6 real tickets picked from your backlog. For each one we write down how long that kind of ticket takes today. That is the baseline.
3. Your code exported to files the packages we will work on, exported through abapGit or as Z-code and DDIC structures in a repo, plus a Jira or Azure DevOps export. We check that Claude Code reads them on a developer laptop. Where your IT approves it, we also test SAP's ADT MCP server as an optional second route. Whatever will not work, we know before the day.
4. House rules for AI (CLAUDE.md) with your conventions: Z/Y naming, Clean ABAP, authority checks, banned patterns.
5. A checklist for participants a week before: licences, access, installs.

The workshop day

People work in pairs on their own tickets. There are fewer than ten slides; the rest of the day runs on your exported code. The spec block uses the same rubric the 18-person team scores with, published in the spec-driven development post.

The whole IT team in one day: up to 50 people

For teams where SAP and IT infrastructure or helpdesk should start together. Up to 50 people, run by me and an assistant, after a shared opening in two tracks. The opening takes 75 minutes for everyone: a live build of a small app, from the request to a running application, and the numbers from the 18-person team above. Then each pair, one person experienced in AI and one beginner, goes to its track. Nothing on the day writes into SAP or Jira; both tracks run on exports.

Before the day. A 60-minute call about your tooling (IDE, connectors, SAP landscape) and your data (a 6-month Jira export with the Jira structure), then half a day of data preparation: the export cleaned, names replaced by initials, sample Z-code and DDIC structures exported to files. Price in the block below.

What AI can see in your SAP stack

State of the tools in October 2026. We check every row on your own exports during the prep day.

Claude Code and Eclipse. Claude Code has no Eclipse plugin. In the workshop it works on your code exported to files: a package exported through abapGit, or Z-code and DDIC structures exported to a repo. No connection into SAP is needed, and many on-premise SAP IT teams allow none. Where your IT approves it, SAP's ADT MCP server is an optional second route that reads the code live. If neither route reads your code reliably on the prep day, GitHub Copilot in Eclipse is the fallback.

Private AI accounts put your code outside your control

Developers often buy AI themselves and use it on company code. On private Claude accounts (Free, Pro, Max), chats are used for model training since 28 August 2025 unless the user switches it off, and are then kept for up to five years. The company cannot see that setting or enforce it. When someone leaves, the history with your code stays on their private account. ST22 dumps and table extracts can also contain personal data.

The fix does not have to be expensive. The workshop runs on the licences you have, and we go through the options:

For an SAP team I recommend Claude Team. The company owns the accounts, so when someone leaves you close the account and the history stays with you. Chats are not used for training by default and nobody has to police it. An admin sets the SAP rules, and where allowed the Jira or Confluence connections, once for the whole team. Prices from claude.com/pricing, October 2026.

The minimum, today, whatever you decide: switch training off on every private account and keep production data and dumps with personal data out of AI.

What your team keeps

• One shared setup: Claude Code over your exported code, the same on every laptop. No more pasting, and no connection into SAP.
• CLAUDE.md with your house rules: for SAP work, shared across the team and every new licence.
• Two reusable agents: one for code review, one for documentation.
• A spec scorer on your Jira or Azure DevOps export: the 8 of 10 gate, with a live connection to Jira or Confluence only where your IT allows it.
• Team rules for AI: written by the people who follow them.
• A baseline and a metric: for the next four weeks.

What I need from you

• A Claude licence with Claude Code for each participant (Pro is enough), with model training switched off on private accounts. We check it in the checklist.
• Approval to export the packages we will work on: through abapGit, or as Z-code and DDIC structures in a repo. No connection from AI into SAP is needed. If your IT approves SAP's ADT MCP server, we test it on the prep day as an optional route.
• An export from Jira or Azure DevOps, the last 6 months with its structure (projects, issue types, workflow, custom fields). A live connection is optional: Atlassian's official MCP server covers Atlassian Cloud only, for Data Center we use a community one, and Azure DevOps needs a Microsoft Entra app registration for Claude Code.
• Your SAP lead on the kickoff call, plus 4 to 6 tickets from the backlog.
• A room with a projector and one laptop per pair.

Who runs it

I am Marian Kamenistak. Since 2019 I have done 35+ engagements as a fractional CTO and mentored 317 engineering and product leaders across 3,662 sessions. AI adoption came up in 44% of my recorded 2026 mentoring sessions (19 of 43); the board side of it is on my AI adoption pressure page.

I am not an ABAP developer, and the workshop does not pretend otherwise. The SAP specifics come from your SAP lead on the prep day; I bring the AI setup, the agents and the way to make a team use them.