Harvesting the business context hidden in SAP BW
Give AI a table of revenue figures and it can calculate, compare and produce a convincing explanation. But those numbers alone cannot tell it what your company recognizes as revenue, which transactions are excluded or which business rules produced the result.
When we move only the numbers, we leave AI to fill in the business meaning. It may apply a familiar formula and return a precise answer that is wrong for our business. More reasoning cannot reliably recover a company-specific rule that was never supplied.
In SAP BW, much of that logic is already implemented. The treatment of internal transactions, the reporting hierarchy and the calculation of a month-end balance are decisions the organization has already made and built into its systems.
That is why harvesting the SAP BW semantic layer matters to our work at Cirql One. It gives a practical answer to the question in our article on making business context explicit: how do we capture the knowledge already embedded in enterprise systems and make it usable for AI?
Business meaning is spread across the BW landscape
When I talk about harvesting the SAP BW semantic layer, I mean the connected definitions and behavior behind the reports people use. That includes much more than the labels on fields.
InfoObjects describe characteristics and measures, including units and currencies. Transformations determine how source values become reporting values. Custom ABAP implements additional rules. Providers bring data together, while BEx queries add calculations, restrictions, variables and aggregation behavior.
Hierarchies determine how the organization is represented. Analysis authorizations control which parts a person may see.
Consider a profitability report. One part of its meaning may live in a transformation that assigns costs. Another may sit in a query that excludes certain transactions. The reporting structure may come from a hierarchy with a particular validity date.
Each object explains part of the result. Understanding the number means connecting them.
That is the first difficulty with harvesting: there is no single export that explains the entire business definition. An inventory tells you which objects exist. You still need their dependencies, their detailed rules and the way those rules work together.
A field definition does not explain how a number behaves
Imagine a stock report with daily closing balances of 100, 110 and 105 units. Adding the three records gives 315. If the question is the closing stock at the end of that period, the answer is 105.
An AI assistant can generate perfectly valid SQL that sums those records. The query runs, the arithmetic is correct, and the business answer is wrong. The missing piece is the rule defining what stock means over time.
BW can already hold the rule that explains the difference: add stock across locations, but take the closing balance across time. Harvesting needs to capture that behavior together with the measure. Otherwise, the next application receives the values without the instructions needed to use them correctly.
Similar questions arise with restricted key figures, currency conversion and ratios. Which transactions are included? Which conversion date applies? Is a percentage calculated for each row and averaged, or calculated from the totals?
A field name such as “margin” cannot answer those questions. Neither can a plausible formula generated from the name alone.
This makes semantic migration demanding. The target implementation has to reproduce the intended behavior under the relevant filters and levels of detail. Valid SQL is only one check; matching business results requires more.
Code and time make the context harder to recover
Custom code adds another layer. A transformation routine may call a function module, which reads a lookup table or applies a company-specific exception. Extracting only the visible routine leaves a gap in the explanation.
The person reviewing it needs to follow the dependency far enough to understand what affects the result. Otherwise, a translation can look reasonable while missing a rule applied somewhere else.
Time creates a different problem. A cost center might belong to one division today and another in last year’s reporting structure. To reproduce a historical report, we need the hierarchy that applied on the relevant reporting date. Copying only today’s structure can put the right figures under the wrong division.
Access rules need similar care. Permission to see a branch of a hierarchy has to be represented and tested in the target security model. Copying the hierarchy does not establish the corresponding permission.
These details become visible when a controller questions a total, a historical comparison changes, or a user sees information outside their remit. Finding them during harvesting gives the team a chance to resolve them before they become production problems.
Harvest the connected business logic behind the numbers
At Cirql One, we harvest the business logic and context implemented across BW: measure definitions, query restrictions, transformation rules, custom code, hierarchies and access logic, together with the dependencies that connect them.
The scope is the full chain of logic behind a business result. A measure must remain connected to its calculation, the exceptions that affect it, the organizational structure it uses and the restrictions on who may see it. That is the context an AI application needs to use the number correctly.
Read-only discovery captures the source definitions and code. Following transformation dependencies and called routines brings the pieces together. Lineage and generated documentation let reviewers trace a proposed business definition back to its implementation in BW.
Automation can recover what the system implements. It cannot always explain why the business chose it.
A routine may exclude a customer group because of an approved policy, a temporary workaround or a decision nobody has revisited. The code shows the exclusion. A business owner may need to supply the reason and confirm whether it still applies.
That is why the Review Center matters. Experts validate the proposed meaning, add missing context and approve what should be carried forward. A gap in extraction or interpretation needs to remain visible until it is resolved.
Experts connect the harvested implementation with policies, approval authority and knowledge held outside BW. The resulting business context combines what the system does with the business meaning your team has confirmed.
Migration gives the harvested context an immediate job
Once those definitions are explicit and reviewed, a BW modernization becomes a concrete use for them.
Moving the records gives the target data to work with. Carrying over the approved business logic gives it the definitions needed to reproduce the result. Without that context, the next dashboard or AI assistant faces the same unanswered questions about calculations, exceptions and access.
In Cirql One, the workflow connects harvesting and expert review with target generation, technical checks and reconciliation against BW. Row counts help establish that data arrived. Key-figure totals, grouped comparisons and query results help establish whether the logic survived.
For the stock example, I would want to check the period-end result as well as totals across locations. For a hierarchy change, I would include historical key dates. Access restrictions need their own tests.
That is also where migration effort becomes clearer. The team can work from connected source evidence and review proposed translations, with discrepancies recorded against the relevant objects. There is less need to rediscover the same definition separately in development, testing and handover.
Make BW knowledge available beyond BW
At Cirql One, reviewed definitions are retained in the Business Context Layer as governed Business Data Products. The aim is to make that knowledge maintainable and reusable across analytics, applications and AI, with a clear connection to its source.
An AI assistant answering a stock question can work from an approved definition of closing balance, with its aggregation rule and reporting scope. A new dashboard can use the agreed treatment of historical hierarchies. Both can trace those definitions to the source logic and the review that approved them.
This follows the issue we explored in the hidden cost of losing SAP context: moving data creates work if the meaning behind it has to be reconstructed afterwards.
I would begin with one measure your business relies on. Trace its definition, calculations, dependencies and access rules. Then ask what a new application would need to reproduce the answer without relying on someone who knows BW by heart.
That is a useful scope for a first harvesting exercise, whether a migration is already planned or still being discussed. Get in touch with Cirql One to explore it with us.