SAP Expert reveals what enterprise AI systems actually require to be reliable and efficient
A joint report by Cloudera and Harvard Business Review Analytic Services, published in March 2026, found that only 7% of enterprises consider their data completely ready for AI adoption, and more than a quarter say it is not ready at all. The gap between AI ambition and data reality won’t disappear on its own. Yet the conversation in enterprise technology continues to focus on AI models, platforms,, and vendors, often completely missing the underlying data infrastructure on which those tools depend.
Baris Özcan has spent nearly two decades working in exactly this infrastructure layer. A Senior SAP BW/BI Consultant and Architect based in Germany, he has delivered data and reporting projects across 28 SAP engagements spanning automotive, energy, banking, defense, and media — working for organizations including Mercedes-Benz and Volkswagen Financial Services, as well as leading SAP BI teams at Messe Berlin, Rödl & Partner, and a Dubai energy utility. He has also contributed a technical review to the SAP Press publication on SAP Web Intelligence. We talked to him about what AI integration in enterprise environments actually requires from the data layer, and why most organizations are not as ready as they think.
Many major vendors, SAP included, are positioning their platforms as AI-ready. But research keeps showing that most large organizations are struggling to move beyond pilots. From your perspective, working day to day within these systems, what is actually holding things back?
I think the main issue is that organizations are trying to add AI on top of data foundations that were never designed for it. The tools have moved faster than the infrastructure. What I see in practice is that the data is often incomplete, inconsistently structured, or spread across systems that were never properly connected. AI doesn’t fix those problems — it depends on not having them, so for it to function effectively, they need to be resolved first. So when a pilot fails or does not scale, the instinct is often to blame the technology. But in most cases, the technology is fine; the problem lies in the data that underlies it.
If you use data that is inconsistent, incomplete, or structured in a way that made sense for reporting five years ago and was never updated since, the model will either produce unreliable outputs or simply fail to work at all. However, models are the layer that is perceived as visible and exciting, while data infrastructure work isn’t. Nobody announces a new data governance initiative the way they announce a new AI feature. But from my experience, the data layer is where most of the real work is actually done — and where the actual risks are.
When you talk about data not being AI-ready, what does that actually look like inside a real SAP BW environment? What are the specific things that would make it difficult to put a reliable AI layer on top?
Several things tend to compound each other. Extractors — the connections that pull data from source systems into the data warehouse — are often misconfigured or have not been validated in years. Data models evolve over time without proper documentation, so some fields may end up meaning different things across different parts of the system. Then there are data inconsistencies, where the same customer or material appears under different identifiers in different systems. These issues produce manual workarounds — spreadsheets or offline processes that live outside the system — and create problems even with regular reporting, let alone AI implementation.
Hidden complexity is a recurring theme in enterprise data projects — organizations discover how fragmented their systems actually are only after work is underway. As a Solution Architect on a Mercedes-Benz After-Sales program involving around 300 consultants, you were right at that interface. What did that actually look like in practice?
At Mercedes-Benz, the programme was focused on replacing fragmented after-sales reporting with an integrated solution connecting SAP CRM, logistics, and finance data. Part of my role was translating business requirements into a technical data model, which meant I was often the first person to reconcile what the business thought the data looked like with what was actually in the system, and those two things are rarely the same. In one case, data from different sales and return channels had to be brought into a single reporting view. While it looked straightforward from the business side, it turned out to involve significant extractor work and custom logic on the technical side.
Your work there required bringing data from finance, logistics, and CRM into a single reporting layer. In an environment that large, how do you assess what a data landscape is actually ready for before you commit to building on top of it?
The first thing you have to accept is that not everything will be visible upfront. You can do a thorough assessment, but some of the real problems only appear once you start connecting the systems and the data actually starts moving. What I learned there is that the quality of your preparation is measured by how quickly you can identify and respond to what you didn’t know before starting. The more systems you are connecting, the more surprises you should expect. And the ones that catch most teams off-guard are not the technical issues, but process and ownership gaps that nobody flagged at the start because they seemed irrelevant.
You mentioned process and ownership gaps — and I imagine those become even harder to ignore once a system is in live operation. At Volkswagen Financial Services, you were responsible for keeping the automated data pipelines feeding risk management, credit scoring, and regulatory reporting running reliably for hundreds of users daily. What does it mean to keep a landscape like that stable?
When you are running something in production, reliable means it works every day — and when it fails, you need to understand why within minutes, not days. At Volkswagen Financial Services, the landscape covered applications like credit scoring, regulatory reporting, and automotive CRM across two separate BI streams. These are not systems where you can afford ambiguity about what went wrong or why. If a load fails overnight and nobody catches it before business hours, the consequences are immediate and concrete — the right data simply isn’t there when people need it, and in a banking environment, that has direct operational impact.
Does that kind of operational responsibility change how you think about what “reliable data” really means, and what it requires for AI readiness specifically?
That experience changed how I think about data quality. It is not a project milestone — it is a daily operational standard. And that same discipline is what AI readiness actually requires, because an AI tool working with inconsistent or incomplete data does not just produce a wrong number. The real risk is that it produces a confidently wrong number. Ultimately, much of what makes data truly reliable comes down to ownership — determining who is responsible when something goes wrong.
Knowing who is responsible when something is wrong is exactly the question that regulatory reporting forces organizations to answer honestly. You built that kind of system for a major energy utility in Dubai — a production-ready sustainability reporting framework covering CO₂ emissions, supplier data, and EV charging metrics, aligned to GRI and CSRD standards. What did making that actually work involve?
In Dubai, one of the more concrete examples was the CO₂ emission framework for suppliers: the formula itself had to be updateable, because reporting standards evolve, and the data feeding it had to be sourced in a way that was auditable end-to-end. The reporting also had to work across multiple departments simultaneously — we built self-service dashboards for different business units, each with their own KPI requirements, all drawing from the same governed data layer. And when the scope expanded to include EV charging station metrics, we built an integration with an external transport authority system to bring in EV registration data directly — because the KPI required it, and a manual export would not have met the governance standard. Every data source had to be traceable back to its origin.
Based on that experience, how far are most organisations from having data that meets that bar — and is that gap similar to what AI tools would require?
That level of discipline — data that is structured, traceable, and governed — is exactly what AI tools need to produce outputs you can actually rely on. For many organizations, the underlying issue is that data is stored in ways that made sense for operational reporting but were never designed for auditability or reuse. And once you recognize that, the next question is usually whether the architecture itself needs to change.
Across 28 SAP projects and sectors, ranging from automotive and energy to defense and financial services, you have seen a consistent gap between what organizations think their data can do and what it actually can. If you had to give one concrete recommendation to an IT or data leader who is trying to make that gap smaller before committing to an AI initiative, what would it be?
Start by finding out what your data actually looks like — not what your documentation says it looks like. In my experience, those two things are often quite different. Before any AI initiative, I would recommend a serious assessment of the data layer: where does the data come from, how is it transformed, who owns it when something is wrong, and how consistently does it arrive? That kind of assessment often surfaces problems that people would rather not see before a project starts. But it is significantly less painful than discovering those problems after you have already built something on top of them. The organizations that are genuinely ready for AI are those that have done the unglamorous work of understanding and governing their data first.
