The foundation must be in place

Automations often only work selectively, forecasts are used cautiously and trust in data-based decisions is fragile. The problem rarely lies in the AI itself. It lies deeper - in the architecture. In my practice at the interface of data architecture and corporate management, I have learned one thing: the shiny surface of new technologies is worthless if the engine room underneath is not working.

Operational stability

Anyone who takes a closer look at S/4 transformations will recognize a familiar pattern. Priority is given to what secures operations: stable processes, clean releases, a go-live that is as trouble-free as possible. Analytics is considered complex, potentially risky or a topic for a later phase. Go live first - then see what happens next.

After the go-live, however, the cost of this decision becomes apparent. Historical data is missing or can only be used to a limited extent. Key figures were redefined, often without a comprehensible transition logic. Reports deliver different values than before, without anything having changed operationally. This is exactly where the AI problem begins. Models require stable time series, consistent logic and reproducible data statuses. AI then becomes an experiment rather than a productive force. The mistake lies in the approach: operational architecture and analytical architecture are thought of separately. AI is seen as an add-on to a finished system. Architectural decisions are made without considering their analytical consequences.

AI arises between systems

Relevant AI applications are almost never created in a single system. They are created between systems. Transactional data from S/4 provides the business context. Sensor and event data provide temporal dynamics. External data supplements market or supply chain information. This data speaks different languages. Time reference, granularity and meaning differ - often historically grown and only implicitly known. Without clear decoupling, fragile dependencies arise. In technical terms, this is reflected in missing or unversioned interfaces, so-called data contracts.

A data contract is more than just a technical document; it is a digital handshake between operational IT and the data users. It bindingly defines the data quality and semantics to be delivered from the ERP. If this „contract“ is missing, the chain breaks with every small system update. A practical maintenance project illustrates this: the aim was to predict machine failures. After an S/4 release, material logic changed in the ERP. For the specialist departments, everything remained the same, but for the model, the predictions drifted without an error being visible. The cause was trivial: an integration break because a relevant change had neither been versioned nor communicated.

This pattern is intensified with generative AI. Language-based models are particularly dependent on consistent context and historicized information. If data changes its meaning with every release, results remain superficial. Without stable semantics - i.e. clearly defined meanings of key figures and time references - generative AI becomes a mere textual assistant, but not a decision-making tool.

The focus is often on real-time. However, something else is crucial for learning AI: persistence. Models that primarily react to current streams lose historical patterns and seasonal effects. Real-time controls behavior, but persistence creates the necessary understanding for real business intelligence.
Organization beats technology: Who owns the data? An often underestimated factor is the organization. Responsibility for data is often unclear or only distributed on a project basis. IT is optimized for system operation, costs and availability. When figures no longer fit, the search for the culprit begins. Governance often exists on paper, but does not apply in everyday life. Added to this is a fragmented skills landscape: BW experts understand data models, functional consultants know processes and data scientists work model-driven - often without a deep insight into ERP semantics. Everyone is good in their own area, but little is created in between.

Real change starts with functional ownership. Data responsibility must not be an IT ticket. You need people in the specialist departments who are not only responsible for the process (e.g. goods receipt), but also for data quality and its analytical significance. Only when the business recognizes that data is an asset will technological modernization become sustainable.

Three strategic levers for 2026

Specific opportunities can be derived from these observations:

1. analytics as a design criterion: Analytical requirements must be part of the architecture from the outset - on an equal footing with operational stability.

2. explicit semantics: Data contracts and versioned interfaces are not a theory, but the blueprint for ensuring that data retains its meaning across S/4 Hana releases.

3. permanent responsibility: Data sovereignty requires clear, permanently anchored professional ownership.

Those who continue to optimize architecture primarily for operations will continue to see impressive AI demos in the future - but will achieve little impact in everyday life. If you clean up the substructure now, you will gain a company that is not only ready for AI, but that can finally control its own reality precisely. (Source: Stefan Maxones)