Building a procurement analytics solution is not primarily a dashboard exercise. The real work happens earlier: understanding the S/4HANA source, modelling the procurement process correctly in SAP Datasphere, and reconciling the results back to the operational system before a single SAC dashboard is trusted. That was one of the most valuable lessons from a recent SAP analytics project I worked on.

The solution brought together data across the procurement lifecycle, including Purchase Requisitions, Purchase Orders, Goods Receipts, Supplier Invoices and GRIR, together with the relevant master data needed to give those transactions business context.

The source was SAP S/4HANA, with CDS views used as the primary extraction interface into SAP Datasphere. From there, we followed a layered architecture rather than placing transformation and reporting logic directly on top of replicated source data.

The first layer handled inbound data and replication from S/4HANA. The next layer harmonised and standardised the replicated datasets. Business rules and transformation logic were then applied in a separate propagation layer, before the final reporting views and analytical models were exposed from the reporting layer.

That separation became increasingly important as the solution grew. It gave us a clear path from source to consumption, made data lineage easier to understand, and allowed issues to be isolated without having to unravel one large model containing extraction, transformation and reporting logic in the same place.

One of the most demanding parts of the work was maintaining the correct level of granularity as procurement transactions were combined.

A Purchase Order item can have multiple Goods Receipts and multiple invoice transactions. A Purchase Requisition can also result in more than one Purchase Order. Individually, each dataset may be correct, but joining them without understanding the grain and cardinality can multiply records and overstate quantities or values.

The challenging part is that these issues do not always produce an obvious technical error. A view can execute successfully, return data and appear reasonable while still producing an incorrect business result.

That made reconciliation a core part of development rather than a final testing activity.

For significant modelling changes, we validated record counts, investigated join behaviour, traced individual procurement transactions and compared Datasphere results directly with the corresponding S/4HANA reports. When something did not balance, the objective was not simply to adjust the calculation until the number looked right. We needed to understand exactly where the difference originated and why.

This approach also changed the questions I ask when designing models. What does one row represent at this point in the flow? What is the real relationship between the datasets being joined? Should the record count increase after this join? If a value changes, can I explain the change from a business and technical perspective?

There were also cases where resolving an issue meant going beyond the Datasphere model itself. A missing field, unexpected value or extraction limitation sometimes required tracing the requirement back through the CDS layer and, where necessary, understanding the underlying S/4HANA application data.

That reinforced an important principle for me: the layer where a data issue becomes visible is not necessarily the layer where the issue originates.

Only once the Datasphere models reconciled to the relevant S/4HANA reports did we move into SAP Analytics Cloud.

At that stage, the focus changed. We were no longer trying to prove whether the underlying numbers were correct. The focus became how best to present trusted information to the business and answer questions such as how much had been received, what remained outstanding, where invoice or delivery delays existed, and how procurement activity compared across periods.

Building SAC on top of already reconciled models made that distinction very clear. Datasphere was responsible for providing a reliable analytical foundation, while SAC became the consumption layer through which users could explore and interpret that information.

My biggest takeaway from the project is that a successful analytics solution is built from the source upward.

It starts with understanding the business process and the S/4HANA data that represents it. It requires deliberate architecture, careful modelling of transaction grain, continuous reconciliation and the discipline to investigate numbers that do not make sense. Only then should the focus shift to visualisation and user experience.

For me, that intersection between SAP business processes, data architecture, modelling, troubleshooting and analytics is where this work becomes most interesting.

#SAP #SAPDatasphere #SAPAnalyticsCloud #SAPS4HANA #DataArchitecture #DataModelling #DataEngineering #BusinessIntelligence #ProcurementAnalytics