adesso Blog

In the first two parts of this series, we demonstrated why the partnership between SAP and Snowflake is fundamentally transforming the data strategies of many organisations, and how SAP BDC Connect for Snowflake can be set up from a technical perspective. In this third part, we take the decisive next step: we build an AI-powered agent within the existing infrastructure that queries both SAP and non-SAP data, and demonstrate how this has a tangible impact on day-to-day corporate management.

The scenario

For our use case, we are using a real-world setup that many companies will recognise in a similar form: our German subsidiaries work with SAP S/4HANA and use it to manage the entire order-to-cash process, from order creation through to delivery and invoicing. Our Polish subsidiary, on the other hand, uses a standalone, local ERP system that is not integrated with SAP.

This presents a classic problem for central management. Anyone wishing to know the company’s total turnover must consolidate data from two systems. Until now, in practice, this meant that the IT department first had to set up ETL processes, harmonise data models and implement transformation logic – a process that could take weeks or even months.

Three data sets are now available in Snowflake:

  • SAP Order-to-Cash: orders, invoices and business partners, made available via SAP BDC Connect as a catalogue-linked database
  • SAP exchange rates: the SAP exchange rate table TCURR with historical conversion rates, also made available via BDC Connect
  • Non-SAP sales data: orders from the subsidiary, loaded into a separate Snowflake database

We want to find out how quickly we can set up an AI agent from this that understands all three sources and can answer questions from business users without a data engineer having to build a dimensional data model.

Semantic views instead of a data warehouse

Before the agent can start work, it needs to understand the data. At this point, we are deliberately deviating from the traditional approach. Instead of modelling a complete data warehouse with fact and dimension tables, we use semantic views.

This simply involves describing the existing data semantically – i.e. which column represents a sales figure, which one a customer name, and how tables are related. The data itself is neither transformed nor copied. The effort involved is reduced from a modelling project lasting several weeks to just a few hours.

For SAP data, the semantic view is created automatically when the data product is mounted. SAP provides the business logic, dimensions and descriptions directly, so that the technical table name ‘ad_hdlf_sd_lt_billingdocitem’ is transformed into a comprehensible structure with fields such as ‘NetAmount’, ‘SoldToParty’ and ‘BillingDocumentDate’. There is no need to manually re-model the SAP semantics.


Figure 1: Semantic View of the SAP data in Snowsight with dimensions, facts and metrics

The same applies to the SAP exchange rate table TCURR, which is provided as a standalone data product via BDC Connect. Here, too, the Semantic View is created automatically upon mounting and provides the exchange rate information that the agent will later require for currency conversions.

For the subsidiary’s non-SAP data, we create a separate Semantic View. As the table already has descriptive column names (ORDER_ID, CUSTOMER_NAME, NET_AMOUNT), the semantic description is set up in less than an hour. In doing so, we define dimensions such as customer, product category and sales representative, store facts for amounts in PLN and EUR, create metrics for total turnover and average order value, and add Verified Queries as reference queries for the agent.

Setting up the agent

The Snowflake Cortex Agent is configured directly within the Snowflake interface via Snowflake CoWork. To do this, three semantic views are integrated as Cortex Analyst tools: the SAP Order-to-Cash data containing orders, invoices and business partners; the SAP exchange rate table TCURR for currency conversions; and the subsidiary’s non-SAP sales data. Each semantic view is an independent data source that the agent can query as required.


Figure 2: Agent configuration in Snowflake CoWork with the three Semantic Views as tools

In the Orchestration Instructions, we define when the agent should use which data source. If a user asks for SAP order data, the agent accesses only the SAP data. If someone asks for the company-wide total turnover, it combines all three sources and converts the figures to EUR using the TCURR table. Via the Response Instructions, we specify that the agent must reply in German, always state the currency when quoting figures, and clearly indicate which data originates from which system.


Figure 3: Agent configuration in Snowflake CoWork, specifying what to consider when providing a response

The entire set-up process – from creating the agent through to configuring the tool and carrying out the first test – takes less than 30 minutes and requires no code, no deployment and no pipeline.

The moment of truth

It is not the set-up that matters, but the result. We tested the agent using typical questions from day-to-day controlling tasks.

  • “Which business partners have the highest invoiced turnover in the SAP system?”

The agent accesses the Billing Documents and the BusinessPartner table in the SAP system, links the invoice items to the customer master data and provides a ranking of the business partners with the highest turnover, including customer names and net invoiced turnover.


Figure 4: Agent’s response showing the business partner ranking from the SAP system

  • “What is the company’s total turnover in EUR across all subsidiaries?”

The agent recognises that the question relates to all three data sources. It first queries the SAP Billing Documents, converts foreign currency amounts into EUR using the TCURR table, then queries the Polish non-SAP data and adds the amount already converted into EUR there. In the response, it transparently breaks down which proportion comes from which system.


Figure 5: Agent’s response to the company-wide turnover query, broken down by SAP and non-SAP

What this means for corporate management

For corporate management, this setup changes a fundamental dynamic. The time between question and answer is reduced from days to seconds.

Anyone wishing to know, during the monthly closing, how the group’s turnover is developing across all companies no longer has to wait for a report from IT. The question is asked, the agent autonomously searches through SAP and non-SAP data, and the answer takes both ERP environments into account. If the initial answer raises a follow-up question, the next question can be asked immediately.

This is the real paradigm shift: decision-makers are empowered to query the data independently. They no longer have to wait for others. The IT department is no longer needed as a bottleneck for every ad hoc analysis, but can instead focus on what it does best: ensuring the data infrastructure and governance.

Where the agent excels – and where it doesn’t

The agent delivers its best results for exploratory and ad hoc queries. “How did the Polish subsidiary’s turnover develop last month?”, “Which customers have the highest outstanding order volumes in the SAP system?” or “How is turnover distributed across sales organisations?” are typical questions that can be answered reliably, provided the underlying data is clearly described in the Semantic Views. It is precisely these spontaneous questions – for which the effort involved in creating a dedicated report has not previously been worthwhile – that are its forte.

Limitations arise where complex calculation logic spanning both data sources is required, or where joins demand domain knowledge that is not apparent from the data itself. For example, anyone needing to perform a customer-specific contribution margin calculation using SAP cost data and the pricing data from the Polish subsidiary will have no choice but to carry out some modelling.

A good example of this type of complexity is currency conversion. Even if an exchange rate table is stored in the Semantic View, the business-specific question remains as to which conversion method is the correct one. Depending on whether calculations are based on spot rates, monthly averages or historical accounting rates, different results will be produced. Different rules apply in the consolidated financial statements than in operational sales reporting. An agent cannot make this decision independently; it must be defined in advance in the Semantic View or the Agent Instructions. A positive point worth highlighting is that, in our test, the agent independently identified such gaps and reported them transparently, rather than producing incorrect totals. This behaviour is a clear advantage over rigid reports, which, when in doubt, silently ignore such gaps.

Data quality in the Semantic Views also plays a key role. The agent is only as good as the semantic description on which it operates. Cryptic SAP field names such as VBELN or MATNR should be provided with meaningful labels and descriptions via the Semantic Views; otherwise, the agent will understand the data just as little as a new employee without training. The good news is that BDC Connect already handles this translation automatically for SAP data. In practice, however, it is still worth taking a look at the automatically generated Semantic View to remove irrelevant or empty tables and ensure the agent focuses on the data sets that are actually relevant.

Conclusion

The combination of SAP BDC Connect and Snowflake Cortex Agent significantly lowers the barrier to entry for cross-data-source analyses. Realistically, it still takes hours, but no longer weeks. And that is often precisely the point at which companies decide whether a project will go ahead or disappear into the backlog.

What was still framed as an architectural promise in the first two parts of this series becomes a tangible reality here. A business user asks a question in natural language; the agent autonomously searches SAP and non-SAP data, combines the results and delivers a transparent answer. No SQL, no ticket to IT, no waiting for the next sprint.

Would you like to implement this approach in your organisation? At adesso SE, we support you every step of the way – from your first SAP data product in the BDC, through the setup of semantic views, right through to a production-ready Cortex Agent. Our SAP Analytics team and our Snowflake team work hand in hand to ensure that your SAP data doesn’t just become a cloud copy, but a genuine tool for data-driven decision-making. Get in touch with us.

Picture Jonas Thiele

Author Jonas Thiele

Jonas Thiele is a Senior Consultant in the Snowflake Data Platforms Competence Centre within the Data & Analytics division at adesso. For several years, he has been supporting companies on their journey towards a modern data strategy – from architecture through to implementation in the Snowflake AI Data Cloud. His strength lies in quickly getting to the heart of clients’ problems and translating them directly into viable solutions.