Questions before commissioning SAP work.

The best fit is a problem that crosses boundaries: an order or invoice that cannot progress, recurring data repair, interfaces that are technically green but operationally unreliable, support cost that rises without an obvious volume explanation, or a change programme that creates more support work than it removes. The work begins with one visible failure pattern, then follows the dependencies around it.

Yes. The public record includes SAP SD, MM, logistics, O2C, Automotive, Retail/AFS, MDG-related work, ABAP, and integration troubleshooting. That does not mean every problem needs a broad investigation; it means the investigation can distinguish a process issue from a data, configuration, enhancement, interface, or ownership issue before work is sent to the wrong team.

Choose one representative slice: a repeated delivery block, a failed Business Partner replication, a billing backlog, a noisy interface, or a planning exception. Agree the business consequence, collect a small safe evidence set, trace the flow, and produce a decision-ready brief. A broad transformation can follow later if the evidence warrants it.

Usually a clear scope and symptom statement, an evidence checklist, an owner and dependency map, a reasoned split between quick controls and structural work, and a prioritised backlog. For support work, this may also include a KEDB structure or runbook. The intended result is not a slide deck that describes a problem; it is a practical basis for a business and delivery decision.

Fast closure is useful, but it can hide recurrence, undocumented workarounds, and fragile handovers. The better question is whether the next occurrence will be easier to diagnose, whether the accountable owner is clear, and whether the underlying control has improved. This is why incident patterns, evidence, and operational memory matter alongside SLA reporting.

No. MDG can be appropriate when governance, traceability, and controlled change are genuinely required. Middleware, APIs, events, and BTP services can be appropriate when boundaries and operating responsibilities are clear. They are not substitutes for an owner, a data rule, a recovery model, or a business decision. The first job is to make that distinction explicit.

Clean core is a decision about lifecycle burden, not a slogan about where code sits. Some logic should remain close to transactional truth; some should move to a side-by-side service with a clear contract; some should be retired. The meaningful test is whether the capability has a business owner, a support model, an upgrade path, and a reason to exist.

AI can help retrieve prior knowledge, summarize evidence, compare recurring patterns, and draft a recommendation for review. It should not independently post business transactions, approve financial or commercial decisions, alter master data, or make unreviewed recovery changes. When a deterministic rule or ordinary automation is sufficient, it is usually the better tool.

By making the handoffs inspectable. Each finding should identify the process owner, data owner, technical or interface owner, the evidence required for the next step, and the decision that remains open. That makes it easier for internal teams and partners to contribute without turning every issue into a long escalation chain.

The professional record and profile show public work history, domains, credentials, and publications. The Knowledge Atlas, scenarios, datasets, and publications show how the diagnostic and operating ideas are made concrete. Atlas and scenario pages keep their existing verification labels; they should be read with those boundaries in mind.

CV · profile · Knowledge Atlas · scenarios · datasets · publications