Contents
Many companies invest in AI without yet deriving a reliably measurable business benefit from it. A decisive reason often lies not in the algorithm itself, but in the data foundation it works with.
SAP offers Joule, Business AI, embedded analytics. The promises are big: intelligent automation, predictive processes, autonomous decision support. The availability of these features alone, however, does not yet guarantee reliable benefit. What matters is whether the underlying data can withstand AI use.
Clean Core Is Necessary. But Not Enough
SAP’s Clean Core strategy has a clear technical core: the SAP standard is meant to stay as unmodified and upgrade-capable as possible. Extensions are implemented through released, upgrade-safe mechanisms – depending on the scenario, also via SAP BTP. That makes sense, and it is a necessary condition for AI readiness. But not a sufficient one.
A company can have reduced custom modifications, implemented its extensions in an upgrade-safe way, and brought the system to Clean Core level technically – and still work with duplicates in business partner data, incomplete material masters, or inconsistencies between plants that skew every automated evaluation.
Clean Core secures the architecture. Data quality secures the substance. Miss either one, and the technology’s potential stays limited.
What AI Readiness in SAP Really Means
AI readiness in SAP takes more than a modern system architecture. What matters is a suitable data foundation, clear responsibilities, and traceable processes.
Semantic consistency and completeness are the foundation. When an AI model accesses material master data, “kilogram” has to mean “kilogram” everywhere. Not “KG” in one plant, “kg” in another, and a free-text field in a third. That sounds trivial at first. In practice, it is not, especially in SAP systems that have grown over decades, through mergers and carve-outs.
At the same time, AI models are sensitive to missing data. A material master at 70 percent completeness might work fine for day-to-day business, because people often fill the gaps with experience. AI and analytics systems, by contrast, can only compensate for such gaps to a limited extent and need a data foundation that is as complete and structured as possible.
Regulatory requirements add to that. For high-risk AI systems in particular, the EU AI Act, for example, raises the bar for data governance, traceability, and handling potential bias. Depending on the use case, companies should therefore be able to document which data is used, where it comes from, how it was prepared, and how its suitability is ensured.
The Gap Between Technical Capability and Reliable Use
SAP’s vision of embedded AI is compelling: Joule supports users in their work context, predictive analytics can forecast demand, and automated methods can detect anomalies in large data sets.
In practice, these features fail because of data quality problems that have nothing to do with the AI itself.
Joule cannot give a meaningful answer to a stock inquiry when material master data is incomplete.
Predictive analytics delivers forecasts that are only as good as the input data.
Anomaly detection hits its limits when the anomalies are already baked into the master data.
This is not a theoretical risk. It is arguably the norm.
In practice, AI pilot projects can look convincing on carefully prepared test data, while scaling to production data stalls. The reason: the data foundation in the live system often carries different quality problems, dependencies, and edge cases than the limited pilot data set.
Bring the Data Foundation Into AI Planning Early
Many companies plan their technology roadmap this way: define the AI strategy first, then evaluate the right tools, then prepare the data. The correct order is exactly the reverse.
It makes more sense to align data condition, possible AI scenarios, and investment decisions early on:
A systematic data quality check shows quickly, and without a data export, whether your SAP system meets the prerequisites for AI scenarios. Not estimated, not based on a sample, but measured automatically with hundreds of validation rules directly in the system.
The underlying paricon solutions are built SAP-native and Clean Core-compliant. That way, you can assess the data foundation without creating new technical dependencies in the core system.
What You Can Do Now
Before you sign the next AI vendor contract, before you release budget for an AI pilot, invest a week in one question: can your SAP data deliver what the AI strategy promises?
If the answer is “yes,” you have a defensible basis for your investment decision. If the answer is “no,” you know where you need to start before the investment can deliver results.
Either way, measuring is the better choice than relying on assumptions.
From our experience at paricon: companies that run a data quality check before an AI investment do not just make better decisions. They also save budget, because they can prioritize AI scenarios. Instead of investing broadly in AI and hoping the data cooperates, they focus on the areas where data quality already suffices and cleanse specifically where the most promising AI applications would otherwise fail on data quality.
This is not a sequential process. It is informed prioritization. And it starts with targeted measurement and transparency about your SAP data.
