In this post, let's explore why enterprise SAP needs a shared language for autonomy — and the five levels that provide it.
Every vendor keynote now promises an “autonomous enterprise.” Every roadmap has AI stamped across it. And yet, walk into almost any SAP operations team on a Tuesday morning, and you will find engineers manually scanning backup logs, hand-running system refreshes, and firefighting the same alerts they were chasing a decade ago.
That distance—between the autonomy we claim and the manual reality we live in—is the most underdiscussed problem in enterprise SAP today. I call it the “Operational Autonomy Gap.” And the reason it persists is embarrassingly simple: we have no agreed way to measure it.
Ask three SAP leaders whether their landscape is “automated” and you will get three confident yesses, each describing three completely different realities. One means a handful of scheduled jobs. Another means a monitoring dashboard that pages a human. A third means a self-healing system that refreshes non-production landscapes overnight without anyone touching them.
They are all “automated.” The word has collapsed under its own weight.
Compare that to the automotive world. Before the SAE published its levels of driving automation, “self-driving” meant everything and nothing. After its publication, the entire industry could say precisely what a car could and could not do without a human. The scale created clarity. It let people locate themselves honestly and argue about the right things.
SAP operations need the same instrument. That is what the five levels of autonomous SAP operations provide: a common, diagnosable scale from fully manual to fully autonomous. Here is the climb.
Let’s take a look at each level briefly.
Every task is performed by a person. Tools exist, but they are passive: a transaction you run, a log you read, a screen you watch. Nothing happens unless a human makes it happen. Most teams live here for more of their work than they would care to admit, especially in Basis housekeeping, refreshes, and patch cycles.
Tools begin to help, but only by informing. Monitoring surfaces alerts, dashboards highlight anomalies, and reports recommend action. The judgment and the execution remain entirely human. This is where most “we have monitoring” organizations actually sit—better informed, but no less hands-on.
Specific, well-defined tasks now execute on their own (such as a scheduled system copy, an automated kernel deployment, or a scripted health check) but under continuous human supervision. Someone still watches, approves, and stands ready to intervene. The work is faster; the responsibility has not moved.
The system begins to act on its own within defined boundaries. It can respond to conditions, make bounded decisions, and complete workflows end-to-end, calling a human only when it meets an exception it was not designed to handle. This is the level where the psychology shifts: for the first time, the default is that the system acts and the human supervises by exception.
The system self-manages the large majority of scenarios. Routine operations, most recoveries, and most refreshes proceed without human involvement, and exceptions grow rare. Human attention moves from doing the work to governing the system that does the work: setting policy, not pressing buttons.
Operations are self-governing and end-to-end, with no routine human intervention required. The landscape provisions heal, refresh, protect, and recover itself. No SAP estate is fully here yet, and that is exactly the point. L5 is the horizon that makes the climb legible, not a box to tick this quarter.
The value of a maturity model is not the label. It is the honesty it forces.
Take disaster recovery, my own home ground. At L0, disaster recovery is a runbook in a binder and a team that hopes the person who wrote it still works here. At L1, monitoring tells you a node is down, and a human decides what to do about it. At L2, failover is scripted, but a person triggers and watches it. At L3, the system detects the failure condition and executes failover within defined parameters, escalating only the cases it does not recognize. At L4, it recovers, validates, and reports, with you finding out it happened from the summary. There is no ambiguity about where a team stands once you ask the question this way.
Run the same exercise across your own operations: patching, system copy, data masking, capacity management, etc. Something uncomfortable usually emerges: most organizations are not at one level. They are L3 in one process and L0 in another, with no map of the terrain in between. The scale does not just rate you. It shows you where the next honest step is.
To effectively address the question of which level a business is at, leaders must be willing to accept these three ideas.
The autonomous enterprise is coming to SAP whether or not we have the vocabulary to describe it. AI capabilities are arriving faster than the operational maturity to wield them, and the gap between the two is where the next decade of SAP operations will be won or lost.
The teams that thrive will not be the ones with the most tools. They will be the ones who can say, honestly, where they stand today—and then climb deliberately, one level at a time, choosing their targets rather than chasing a buzzword.
So here is the only question that matters in your morning meetings: not whether your SAP operations will become more autonomous, but whether you can describe the journey clearly enough to make the climb on purpose.
This post was originally published 7/2026.