ai newsMo., 26. Okt.

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

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 ey

dev.toMontag 02:43 · 26.10.4 Min. Lesezeit
Bild: dev.to

Posted on Oct 26 • Originally published at Medium

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.

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.

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.

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.

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.

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".

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.

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.

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.

Quelle: dev.to (dev.to). Original öffnen