DEV Community: Deshan Ranchhod

What SAP Change Teams Can Expect From AI in the Next Year

Deshan Ranchhod — Wed, 11 Nov 2026 10:22:43 +0000

I get asked a lot about what AI will do for SAP change teams. Some people expect it to run whole releases on its own. Others think it is all noise. From what I have seen, the truth sits in the middle. AI can take real work off a team's plate today. But it works best on narrow jobs, with a person still making the final call.

Here is how I see the next year, written for SAP leads and Basis teams, not data scientists.

Where AI already helps

Reading and explaining code. A lot of time in SAP change goes into working out what a piece of ABAP does. Someone wrote it years ago, and they have moved on. AI is good at reading that code and giving a plain summary. It won't always be right, but it gives a reviewer a fast head start.

Code checks. Teams already run static checks before a change moves on. AI can add a second layer. It can flag code that looks risky, point out where a change touches sensitive tables, or suggest a cleaner way to write something. The key word is "flag". It raises the issue. A person decides.

Writing the boring parts. Change records need descriptions, test notes and links to the right tickets. People rush these because they are dull. AI can draft them from the change itself, and the developer just checks and fixes them. That leads to better records and happier auditors.

Finding things. Big SAP landscapes have years of transports, docs and tickets. Asking a plain question and getting pointed to the right place saves a lot of hunting.

Where it is still early

Retrofit. During a large project, changes made in one system often need to be copied into another. AI can help spot what needs to move and where conflicts might be. But retrofit errors can break things in quiet ways. I would treat AI here as a helper that suggests, not a tool that acts.

Making release decisions. Deciding whether a release is ready depends on business timing, risk and people. AI can gather the facts. It should not be the one to approve.

Compliance on its own. AI can help prepare evidence for audits and check that the right steps were followed. It can't replace the controls. If anything, AI actions need the same approvals and audit trail as people. I wrote about that in an earlier post.

How to start without adding risk

If you lead an SAP change team and want to try AI, here is a short list I would follow.

Pick one narrow job. Code summaries or change notes are good first steps. They save time and the risk is low.
Keep a person in the loop. Every AI output should be reviewed before it counts.
Log what the AI did. Record what it suggested and who accepted it. Auditors will ask.
Test it on your own code. A tool that looks great in a demo may struggle with your custom code. Try it on real examples first.
Measure plainly. Track whether reviews get faster or records get better. If not, change course.

The bigger picture

SAP change work has always been about control. Who changed what, when, and with whose approval. AI doesn't change that. What it can do is take away some of the slow, manual work around it, so people spend more time on the decisions that matter.

Over the next year, I expect the teams that do well will be the ones that start small, keep their controls tight and build trust step by step. Not the ones chasing the biggest promise.

AI Should Follow the Same Rules as People

Deshan Ranchhod — Wed, 11 Nov 2026 10:22:08 +0000

Here is a simple rule I use when I think about AI in a big company. If a person would need sign-off to do something, the AI needs sign-off too. If a person's action gets logged, the AI's action gets logged too. No shortcuts just because the work was done by a model.

It sounds obvious. But it's easy to forget once a demo looks good.

Why the rule matters

In most large companies, change is tightly controlled. That's very true in the SAP world, where I've spent most of my career. A change to a live system goes through steps. Someone builds it. Someone else checks it. Someone with the right authority approves it. Every step is recorded, so an auditor can see who did what and when.

Those steps exist for good reasons. They catch mistakes. They stop one person from pushing a risky change on their own. They give the business a clear record when something goes wrong.

Now add an AI that can write code, suggest a fix or move a change along. If it can skip the checks that bind people, you have opened a gap. It doesn't matter how smart the model is. A gap in your controls is still a gap.

What this looks like in practice

When I plan an AI feature, I ask a few plain questions.

Who would normally approve this? If the answer is "a team lead" or "the change board", the AI's output goes to that same person or group. The AI can prepare the work. It doesn't get to approve it.
What gets recorded? The audit trail should show that the AI took part. It should note what it suggested, what a person changed and who said yes. Hiding the AI's role makes the record less useful, not more.
What can it touch? An AI helper should only have the access it needs for the task. Not more than the person using it, and often less.
How do we undo it? If a person can roll back a change, the same path should work for anything the AI produced.

None of this is new thinking. It's the same control model companies already trust. The only change is that one more kind of worker now follows it.

It also decides what ships first

This rule shapes the roadmap, not just the design. Features that fit inside the current approval flow are easier to ship. They are easier for customers to trust, and easier for their auditors to accept.

So the early wins tend to be helpers. Drafting, checking, summing up, flagging risks. The AI does the slow parts and a person makes the call. Features that would act on their own come later, once there is a track record and the controls are proven.

That can feel slow next to the hype. But in my experience, trust is what gets AI from a demo to daily use. A tool that people don't trust doesn't get used, no matter how clever it is.

The bottom line

Treat AI like a new team member. Give it clear limits. Make its work visible. Have a person sign off on anything that matters. Keep the record clean.

If you do that, the conversation with risk, audit and compliance teams gets much easier. You aren't asking them to accept a new set of rules. You're showing them the old rules still hold.

How to Test AI That Never Gives the Same Answer Twice

Deshan Ranchhod — Wed, 28 Oct 2026 14:25:20 +0000

Most software tests work on a simple idea. You give the system an input, and you check that you get the right output. If the answer matches, the test passes. If it doesn't, something broke.

AI doesn't play by that rule. Ask the same question twice and you may get two different answers. Both might be fine. One might be wrong in a way that's hard to spot. This is one of the first things that catches teams out when they move an AI feature from a demo into daily use.

Here's how I think about testing AI features, in plain terms.

1. Test for "good enough", not "exactly right"

You can't check for one fixed answer. You need to check for qualities instead. Does the answer use the right facts? Does it stay on topic? Does it follow the format the user needs? Does it avoid things it should never say?

Write these down as a short list of checks for each feature. This list becomes your test, not a single expected reply.

2. Build a sample set from real work

Collect a set of real questions or tasks your users actually bring. Include the easy ones, the tricky ones and the odd ones. Keep the set small enough that a person can review the results, then grow it over time.

Every time the AI gets something wrong in real use, add that case to the set. This way your tests get better as the product does.

3. Run each test more than once

Because answers change from run to run, one pass tells you very little. Run the same case several times and look at the spread. If it gets it right every time, great. If it gets it right most of the time, you need to decide if that's good enough for this task. For a draft email, it might be. For a change going into a live SAP system, it isn't.

4. Match the checks to the risk

Not every AI feature needs the same level of care. A feature that suggests a summary can have lighter checks. A feature that takes an action, or helps someone approve one, needs much tighter checks and a person in the loop.

I find it useful to sort features by what happens if the AI is wrong. The worse the outcome, the stricter the test and the more human review you keep.

5. Use people and tools together

Automated checks are fast and catch a lot. They can flag missing fields, wrong formats or banned words. But some things only a person can judge, like whether an answer is actually helpful.

Set up a simple review habit. Have someone who knows the work look at a sample of results on a regular basis. Keep the review light so it actually happens.

6. Keep a record

Log what the AI was asked, what it said and what happened next. When something goes wrong, this is how you find out why. In large companies, this record also matters for audit. People need to see what the AI did, just as they would for a person.

7. Re-test when anything changes

A new model version, a change to your prompts or new data can all shift how the AI behaves. Treat each of these like a code change. Run your sample set again before it goes live.

The bottom line

Testing AI is less about proving it's perfect and more about knowing how it behaves. Clear checks, real examples, repeat runs and human review will get you most of the way. That's what lets people trust an AI feature enough to use it every day.

I'm Deshan Ranchhod, an AI Product Manager in Melbourne. You can find more of my work at deshanranchhod.com, on LinkedIn, on Medium and on my blog.

From SAP Consulting to AI Product Management: What AI Agents Need to Get Right in SAP Change

Deshan Ranchhod — Mon, 26 Oct 2026 01:43:14 +0000

For years my job was to help SAP changes reach production safely. I was a senior SAP technical consultant across APAC. In September 2026 I moved into a new role as an AI Product Manager at Rev-Trac, which makes SAP change and release software.

The move has made me look at old problems with fresh eyes. These are my own views, not a product plan. But I think they hold for anyone building AI tools for SAP teams.

Where I'm coming from

SAP change work is careful work. A small change in one system can break a process somewhere else. So teams review transports, test, check what else a change might touch, and write release notes. Then someone signs off.

A lot of that work is slow and repetitive. It is also high stakes. You can't skip steps just because you are busy. That mix is exactly where AI agents look useful. It is also where they can do the most harm if we get them wrong.

Where AI agents could help

Here are three places I think agents could take real weight off SAP teams.

Reviewing transports. An agent could read what is in a transport and flag things a person should look at. Missing objects. Odd sequencing. Changes that clash with other work in flight. It would not approve anything. It would point a human at the right spot faster.

Impact analysis. When someone asks "what will this change touch?", the answer often lives in many places. An agent could pull that together into a short list of likely risks. The person reviewing it still decides what matters.

Release notes. Writing clear notes from technical changes is tedious. An agent could draft them in plain words. A person then checks and fixes the draft before it goes out.

In each case the agent does the legwork. A person keeps the judgement.

What an AI PM has to get right

Moving into product, I have learnt that the clever part is not the hard part. The hard part is making the tool safe and useful every day. Four things stand out to me.

1. Evaluation

You can't improve what you don't test. For an AI feature, that means building a set of real examples with known good answers. Then you run the agent against them every time something changes. A new model, a new prompt or a new data source can all shift the results.

I like to start small. Pick one task, such as drafting release notes. Collect real cases. Agree with users on what "good" looks like. Then measure against that, not against a demo that worked once.

2. Guardrails

An agent should only be able to do what it needs to do. If its job is to read and suggest, it should not be able to move a transport. Limits like this should be built in, not left to good behaviour.

Guardrails also cover what the agent says. It should show where its answer came from. It should say when it is not sure. A confident wrong answer is worse than "I don't know".

3. Human sign-off

In SAP change, sign-off is not red tape. It is how an organisation stays in control and passes audits. AI should make sign-off easier, not remove it.

So I think the agent should prepare the work and the person should approve it. The approval should be clear and on the record. If something goes wrong, you need to know who decided what, and why.

4. Trust

Trust is earned slowly and lost fast. SAP teams have seen plenty of tools promise a lot. They will judge an AI feature on its worst day, not its best.

That means being honest about limits. Start with low-risk tasks. Let users see the agent's reasoning and correct it. Listen to their feedback and act on it. Trust grows when people feel the tool works for them, not the other way round.

What I'd tell other SAP people

If you work in SAP and wonder where AI fits, your knowledge matters more than ever. Someone has to know what a safe change looks like. Someone has to spot when the agent is wrong. That someone is you.

You don't need to become a data scientist. Learn how these tools fail. Learn how to test them. Ask hard questions of anyone who says their tool "just works".

For me, the shift from consulting to product has been less about new tech and more about new questions. Not "can we build this?" but "should we, and how will people know they can rely on it?" That is the work I want to do well.

Deshan Ranchhod is an AI Product Manager in Melbourne, Australia. Connect with him on LinkedIn or read more on his blog. Back at uni he built a kebab shop finder app, and SBS Food wrote about Deshan Ranchhod's Get Me HSP app.