What the practice takes on

Large language models are part of how the software is written. Where it helps the work, a model can also sit inside the tool: answering from documents the client approves, lifting structured fields out of messy inputs, or preparing a draft for someone to review.

The process owner stays in place. When an output matters, it gets a check, a record, or both. The aim is software a team can explain, change, and support.

This is automation at the edges of SAP-centred work: approvals, notifications, validation, and the routine passing of data between people and systems. The shape of the work comes from the workflow the team describes.

Existing integration patterns are the starting point. Client-specific process designs stay in the engagement. They are not published on this site.

A narrow system is more useful than a wide promise. Delivery includes the software or automation, a plain description of what it will and will not do, and notes an operations or IT owner can keep after the engagement.

The handover is part of the work, not a closing formality. Someone on the client side should be able to say how the system behaves without calling it a black box.

Advisory work comes before a build, or when an idea needs a tighter brief. It asks whether a workflow should be automated, where a language model helps, and where a person should stay in the loop.

A poor fit is a useful result. The outcome is a clearer brief, including the decision to leave something alone.