Archive | Upgrade to Premium | Sponsor

The Monthly Take

“Can we bring AI into ECC and SRM?”

Technically, yes. You can connect legacy SAP systems to external AI services. But in most production environments, it becomes a lot of work, expensive, and the value often remains surface-level unless you fix the foundations first. And that’s not because AI isn’t powerful. It’s because ECC and SRM were designed long before modern AI architectures existed.

In SRM-enabled procurement landscapes, transactions often originate in SRM and are then replicated into ECC. In our environment, purchase orders created through eSpree are replicated to ECC PR2, and the process is designed so changes are controlled from the SRM side for consistency.

This matters because many “AI automation” conversations assume you can automate directly inside the core ERP. In reality, if you bypass the transaction backbone (SRM→ECC controls), you don’t just risk a bad recommendation, you risk breaking the process.

So the safest and most realistic AI posture in legacy stacks is advisory and side-by-side, not deeply embedded and autonomous.

Legacy ECC often contains years of historical baggage - inconsistent master data standards, duplicates, missing context, and “whatever it took to keep operations running.” When AI output is only as good as the data underneath, that messy foundation becomes the bottleneck.

The outcome: teams spend more time cleaning/mapping data than building anything “intelligent,” and trust collapses if the AI is wrong often enough that users revert to manual habits.

This isn’t just a technical issue; it’s operational behavior. Without reliable data and lineage, AI becomes a demo.

Legacy SAP procurement stacks are not built around modern event streaming or flexible APIs. They’re often built around tight dependencies and deterministic integration patterns.

Examples from familiar landscape:

Vendor master data replication from ECC to SRM is done through RFC, with defined cadence and prerequisites that must be met (classification, org setup alignment, etc.).

Approvals depend on real-time RFC calls from eSpree into ECC DOA services to retrieve limits and approval hierarchy data.

This is why many AI initiatives in ECC/SRM end up feeling like “AI bolted on top of old plumbing.” The integration work, failure modes, latency, monitoring, and control design can outweigh the AI benefit.

Most mature ECC/SRM environments have years of enhancements, custom logic, and process variants. They are “clever fixes”, until they aren't. They may have saved the business at the time, but they become roadblocks for modern capabilities.

In practice, AI struggles when:

So even if the model is good, the system context it needs to act correctly may not be accessible or consistent.

Most enterprise AI patterns for ECC require side‑by‑side processing - extracting data into a modern cloud environment and running models there.

But procurement data is sensitive, and moving data out of on‑prem landscapes introduces real questions:

Meanwhile, SRM procurement process controls are already role-driven and tightly governed (who can do what, where, and under which conditions). So AI adds an additional “audit surface” - even when it’s only recommending actions.

One of the fastest ways to lose credibility is to disrupt buying. In SRM landscapes, buying experience is often tied to vendor punchouts, browser behavior, certificates, and environment differences.

We’ve seen this with HTTPS enablement and the practical user impacts around prompts and catalog connectivity in SRM/VDM/UWL access.

So any AI that sits in the “shopping” layer must adopt one rule: Do no harm to transactional continuity and vendor connectivity.

SAP’s official timelines matter:

Mainstream maintenance for SAP Business Suite 7 core apps (including SAP ERP 6.0 / ECC) runs until Dec 31, 2027, followed by optional extended maintenance until Dec 31, 2030.

SAP’s innovation commitment is clearly oriented toward newer environments; for example, Joule enablement is described through SAP BTP “Integration with Joule” formations and supported system types such as SAP S/4HANA Cloud.

Internally, we also discuss ECC and SRM being maintained into the 2030 horizon while long-term replacements mature. So the real leadership question is: Do we want to spend heavily embedding AI into a platform approaching the end of mainstream maintenance, or focus on AI value that survives the transition?

If your goal is ROI without rebuilding the world, the rational approach would be: AI next to the core,” not “AI inside the core” This means AI supports humans and improves decisions, but does not bypass SRM→ECC controls.

The best-fit areas can be:

Use AI to detect missing prerequisites, inconsistent fields, incomplete context - the kinds of issues that cause replication or workflow friction. (In practice, this is where time disappears.)

Vendor Data Management processes include tracking, approvals, notifications, and attachments flowing into ECC records - rich territory for summarization, completeness checks, and reviewer support.

Where the system is complex, AI can accelerate understanding: summarize tickets, correlate symptoms with known changes (e.g., security upgrades/downtime windows), and guide troubleshooting - without touching transactional execution.

One of the most practical AI can win in ECC landscapes is enabling faster delivery via code assistance (ABAP, integration artifects, test scripts) - because it improves speed without introducing new transactional risk.

Yes, people are trying AI in legacy ERP landscapes.

But without a strong data foundation and a modern integration layer, AI in ECC/SRM often becomes expensive stitching - and the outcomes can feel like a demo rather than something trustworthy in production.

The smarter move is to map where AI efficiency is real, avoid embedding AI into the transaction backbone, and where strategic change is already underway, consider aligning AI investment to the future platform rather than reinforcing the past.

From the Frontline