AI and SAP Organization

AI won’t fix a broken SAP organization. It’ll just break it faster. 

Von ZPARTNERBDC, BW4/HANA, BWBLOG, Datasphere/DWC, SAC

I keep meeting SAP teams that work harder every quarter and still fall behind. Backlogs grow, decisions queue, good people burn out, and the easy explanations (too few hands, weak discipline, the wrong people) never quite fit. After years in this, my conclusion is the uncomfortable one: the people aren’t the problem, the structure they work inside is. SAP’s own platform shift is now exposing that structure faster than anything I’ve seen. So here’s the claim up front: AI plus the move to the cloud isn’t a tooling upgrade you can buy your way through. It’s a redesign of how an analytics practice thinks, decides, and delivers. 

  • SAP’s center of gravity has moved to cloud and AI: classic BW is winding down, Datasphere and SAP Analytics Cloud sell only inside Business Data Cloud now, and tools are being retired before a full replacement is ready. 
  • The real constraint isn’t budget or effort, it’s how teams are organized. A 1956 law of cybernetics says a system can only handle as much complexity as it can match internally. 
  • AI makes execution cheaper, so judgment matters more. Tuning agile ceremonies harder won’t help; the bottleneck was never how fast work moved. 
  • The fix is org design: push decisions to the edge, run small end-to-end pods, and let the team carry the load. Specialists get more valuable, not less. 
  • Roles shift: developers pick up architecture, design, and review; the classic project manager moves toward judgment and AI fluency or watches the coordinating get automated. The hopeful part from the research: in some cases AI narrows the gap between strong and weak performers. 

An old idea that still fits 

The one idea that I keep coming back to is old. Cybernetics states it in four words: “only variety can destroy variety.” Plainly, a system can regulate another only if it has at least as wide a range of responses as the disturbances coming at it. A regulator with fewer moves than the world throws at it gets overrun. The organizational reading is blunt: when the world grows more complex and your range of responses stays put, you don’t fail because you’re weak. You fail because you were built with too little variety to absorb what you now face. 

Most analytics teams I know were built for a stable world: a known stack, predictable releases, deep specialists who owned a layer for a decade. Excellent at the known thing. Much less suited to a platform rearranging itself underneath them. 

The platform is rearranging itself underneath me 

Here is what I mean. 

Classic SAP BW, which most of my customers still run, is on the clock: mainstream maintenance ends 2027, extended 2030. BW/4HANA is committed to 2040, so the product isn’t dying tomorrow. But the roadmap has already left it behind. SAP’s innovation and investment now flow to the cloud, to SAP Business Data Cloud (BDC), with Datasphere and SAP Analytics Cloud (SAC) inside it. Since 1 January 2026 you can’t buy or renew standalone Datasphere or SAC; they sell only as part of BDC (existing contracts run to the end of their term). Everything else is maintained, not advanced. 

What unsettles me more is how the old world is being retired. SAP Data Intelligence Cloud came off the eligible-services list in mid-2024 and is no longer sold, yet its capabilities are still being folded into Datasphere “to eventually cover” what it did. The replacement is still catching up: feature parity is not there yet, and SAP is closing the gap release by release rather than offering it day one. The tool was sundowned before its replacement was fully in place. The pace of the shift now outruns the tidy migration path we all wish for. 

Even the help that exists is conditional. SAP’s BW Data Product Generator, which publishes BW data into BDC, only serves you if you’re already cloud-adjacent (BW Private Cloud Edition). The large population I work with (customers still on-premise who can’t or won’t lift first) gets no automated path at all. The modernization aid assumes you’ve already made the move it’s meant to help you make. 

Why this shift is different from the last five 

My career has been one upskilling wave after another. BW 3.5 to 7.x to BW/4HANA. R/3 to S/4. ABAP to ABAP OO and Web Dynpro, then the cloud platforms (BigQuery, AWS, Azure) alongside SAP Data Intelligence, Python pipelines, Parquet, HANA native, HANA SQL in Datasphere, and to top it off SAP Business Objects to SAP Analytics Cloud. All that on top of the BW and S/4 systems. Every time, the answer was the same: learn the new thing, keep going. So why should this wave be different? 

Because each of those changed the stack: new tools, pretty much the same work. This one changes what the work is. Every wave handed me a new way to do the same craft: the object mapping, the modeling, the migration steps. AI absorbs that directly. When execution gets cheaper, the outcome turns on judgment rather than speed. Which model is right for this client? What architecture do I need? Is the roadmap I’m reading still up to date? What do I do when SAP changes the destination mid-engagement? Judgment isn’t suddenly scarce; I always had it. It used to be the easy part you reached once the typing was done. Now it’s a bigger part of the job. That’s not more of the old variety. It’s a different kind, and it lands where the old org chart is weakest. 

Which makes “BW/4HANA runs to 2040, so there’s no rush” the wrong idea. A long runway isn’t a reason to wait; it’s the (maybe last) window to rebuild deliberately instead of scrambling at the end. Talent will re-optimize around AI whether you plan for it or not. The other objection, “AI just makes my teams faster,” is true and still beside the point. Faster execution into the same approval queues, overcomplicated documentation, and endless discussion rounds just moves the bottleneck. A control-heavy structure throttles the faster pace quite effectively. You get a quicker engine bolted to the same old car, still hurtling toward a cliff. 

Same goes for the methods: agile, Scrum, Kanban, the ceremonies we all got good at. The precise version of the uncomfortable truth is this: tuning those frameworks even more will not carry teams through, because the bottleneck was never how fast work moved through them. Two things wear the name “agile.” Agile-the-ceremony (standups, sprints, the board) optimizes the throughput of execution work, and AI absorbs exactly that. Agile-the-principle (push decisions to the people doing the work, shorten the feedback loop, respond over plan) is the part that transfers, and the part most teams I know skipped altogether. The numbers said so before AI: Jeff Sutherland, co-creator of Scrum, popularized the figure that roughly 47 percent of agile transformations fall short, and the State of Agile survey saw satisfaction slide from 71 to 59 percent in a year, with only about a quarter saying agile helps them deliver value. The diagnosis is “agile theater”: keep the rituals, leave the real decisions on roadmap, staffing, and priorities exactly where they always were. That is keeping the obsolete part and skipping the essential one. The frameworks that survive will be about where decisions live, not how fast work crosses a board. 

What I think this asks of us 

Ashby tells you to add variety, not where to put it. The reason to push it outward rather than pile it at the center is speed: a central decider can be as good at his job as you like and will still lose, because the responses arrive too late. The binding constraint isn’t decision capacity, it’s decision latency. For a SAP team, distributing that capacity looks concrete: small pods that own a client problem end-to-end instead of handing it across silos. Decision rights that get escalated today pushed down to the people closest to the client. An approval layer removed and replaced by a shared, real-time picture so the pod decides without queuing. Consultants measured on outcomes they can shape. The manager moves from steering to enabling. From holding the answer to building the conditions so the answer forms where the knowledge sits. 

None of this is free, and it fails in predictable ways. Push decisions to the edge without a shared semantic layer and pods quietly build five versions of the same model. The first audit finds an inconsistent state, and the organization re-centralizes in a panic. That risk is real, and the agile numbers are a fair warning that redesigns underdeliver as often as they deliver. The guardrail is a thin governance spine. A shared picture plus a few non-negotiable standards, so autonomy doesn’t drift into fragmentation. The point isn’t to dismantle control; it’s to spend it where it buys something, and keep just enough to stay coherent. 

Adopt the AI as carefully as possible. The lesson from teams measuring it honestly: individual speedups don’t become organizational gains on their own; faster drafting just backs up reviews, CI, and QA unless those move too. Google’s DORA research keeps landing there, that AI shifts the thing worth measuring from the individual developer to the health of the system around them. So watch code churn, not just throughput. The share of fresh code that gets reverted has climbed sharply since AI spread, and standard metrics miss it because it rarely breaks production. And when it does, it can fail badly: Microsoft’s run of broken Windows 11 core features through 2025, set against its own claim that AI now writes a fifth to a third of its code, is the case the industry keeps pointing to. Put token cost into the calculation when you judge the return, because that cost is real, and it’s where the next part starts. 

The unit that holds more variety is the pod, not the person 

There’s a second effect I’m seeing, because it lands on careers, not just org charts. When AI absorbs the typing, what’s left is the work around the code: framing the problem, choosing the architecture, reviewing the output, owning whether it’s correct. In my world the “typing” is the boilerplate CDS view, the object mapping, the mechanical migration step. The parts AI is worst at are the parts that were always hard: reading a fifteen-year-old customized BW model, turning a client’s vague question into the right semantic one. So SAP analytics may have less cheap-execution middle to give away than green-field software, and more judgment-heavy work left over. 

The clearest evidence comes from software development, and it’s early and noisy, but it points one way. Demand is repricing toward people who can architect and review AI output, away from pure boilerplate implementation. One study of high-AI-adoption teams found them merging far more pull requests while review time rose roughly 91 percent. The work didn’t vanish. It has moved from producing code to judging it. I’d resist the cheerful reading. A developer reviewing their own AI output is the weakest possible reviewer, already primed to accept the model’s framing. That argues for keeping review a distinct pair of eyes, not folding it into one overloaded person. 

Which is the real point: that capacity has to live in the team, not in one heroic individual. Pile the architect’s, reviewer’s, and quality hats on one person and you don’t get a ten-times engineer. You get a shallow generalist heading for burnout, and an organization of locally sensible, globally inconsistent decisions (Conway’s law is unkind to that). What works is a small cross-functional pod that holds those hats between a few people, with the deep specialist not diminished but more valuable, because their judgment is exactly the input AI can’t (yet) supply. 

So where does that leave the classic project manager? In the most exposed seat, if the job stayed what it often was: 

  • chasing status 
  • maintaining the plan 
  • moving tickets 
  • assembling the report 

That relay work is exactly what AI agents are getting good at, and it was visible long before this wave: in 2019 Gartner predicted that by 2030, 80 percent of today’s project-management work would be eliminated as AI takes over data collection, tracking, and reporting. But “tasks automated” isn’t “role deleted,” and I don’t buy the clean split between coordination and judgment, because good coordination is judgment: which stakeholder to call first, which green status is real, which dependency is about to bite. Someone still has to be accountable to a client and an auditor, and you can’t hand that to an agent that drafts updates. So the role rebalances rather than vanishes: away from relay, toward stakeholder ownership, risk accountability, and governing the AI and its data. Cheaper relay makes the accountable human more leverageable, not redundant. The catch: the move isn’t automatic. Only about a fifth of project managers report solid hands-on AI experience, and roughly half little or none. My bet, plainly: the PMs who lean into judgment, stakeholders, and AI fluency gain ground; the pure coordinators watch the coordinating get automated around them. 

It’s tempting to read all this as a culling: AI arrives, the weaker get cut to fund the tokens the stars burn, and you just have to outrun the colleague the bear catches first. The economics aren’t nothing, the AI-attributed layoffs are real (tens of thousands of roles in 2025, approaching a hundred thousand since 2023), and firms say it plainly; Accenture’s chief executive framed it as reskill or be exited. But the research complicates the harsh version. The most careful studies find AI narrowing the gap between strong and weak performers, not widening it: in one large customer-service study an AI assistant lifted novices by around 34 percent, because it hands everyone the median expert’s playbook. What stays scarce is the judgment and the vision the playbook can’t encode: the deep, contextual call on a messy SAP system no model has seen or been trained on. So for now, the dividing line is less talent or speed than adoption. The bear isn’t your faster colleague; it’s obsolescence, and what outruns it is picking the tools up and moving toward the judgment work. 

What I’m looking into 

I won’t pretend I have this solved. What I have is a pile of questions and a hunger to keep learning, and I am testing both against the gaps that are real rather than the ones that demo well. The test I apply isn’t “can AI do this?” but “is this a gap worth closing?” The world does not need another chatbot. The shift tears concrete holes: tools retired before their replacements are feature complete, on-premise estates with no path forward, and unchecked vibe coding reaching production without guardrails (one AI agent infamously deleted a live production database during a code freeze). Underneath all of it, the gap between cheaper execution and decisive judgment. Where can AI close one of those gaps, used not as a feature inside a product but as a build partner beside me? The pattern I keep returning to is spec-first: write the intent down precisely, let AI carry the rule-bound work, and spend my own attention on the calls that need judgment. When it works, the busywork shrinks and the thinking grows. I’d rather take a real shot at a real problem than polish a solution nobody needs. 

Wrap-up 

The overwhelmed SAP team isn’t a failure of its people. It’s a structure built for a stable platform, meeting a platform that won’t hold still. AI and the move to the cloud don’t cause that mismatch; they make it impossible to ignore and expensive to leave alone. So I’ve stopped treating AI as a technology project. It’s a forcing function for how I organize. The teams that come out ahead won’t have the best models. They’ll be the ones that rebuilt themselves to think, learn, and decide at the speed the platform now moves. 

Where is the real bottleneck on your team right now: getting the work done, or getting the decisions made? I’d like to hear whether others are seeing the same shift. 

References 

  • Erik Brynjolfsson, Danielle Li, Lindsey Raymond, “Generative AI at Work”, NBER / Quarterly Journal of Economics (2025) (AI lifts novices ~34%, minimal effect on experts; narrows the performance gap). 

Folgendes könnte dich auch interessieren:

Seamless Planning

ZOCCER26 – Architectural Approaches for Business Logic with Seamless Planning

Factory Calendar

Factory Calendar in SAP Datasphere – It’s complicated

How We Are Showcasing SAP Business Data Cloud with ZOCCER26