SAP’s ERP application R/3 is classified as a real time transaction processing system. However for most larger companies SAP R/3 is not suited for analytical purposes. These companies started with the building data warehouses. This is also where my “SAP analytics journey” started, in the early 1990ies as an employee of Shell. To load the data warehouses we wrote programs (SAP slang: ABAP) that selects and processes the data in batch. In fact my team has been doing something like that until last year at more than 50 companies. These batch programs are in most of the cases run overnight. So analytics for SAP could be a day behind the reality of the R/3 system.
For a long time my team wanted to solve that issue and build a solution that would keep the data warehouse in synch with the SAP R/3 transaction system. So we felt great when our first commercial release of the Teradata Analytics for SAP solutions that replicates data saw the light in the fall of 2014. I have written a series of blogs in which I have documented important learnings from our realization process.
In the first blog I explain why it took about 25 years to get from a batch oriented solution to something that makes it possible to replicate data from SAP R/3 to the data warehouse. Next (in post 2) I talk about the fact that near real time analytics requires more than a technical capability because of the limitations of SAP R/3. In post 3, I write about the advantage of the replication technique used . Obviously this makes it possible to run operational and managerial reports from the same source, but as always during innovative processes we have discovered (unexpected) other advantages. Then (in post 4) the technical complexities are discussed to complete the series. In post 5, I zoom into the most complex technical issue of all, SAP’s clustered and pooled tables.
Anyway I have enjoyed working on this project very much, I hope you enjoy my posts and I welcome your feedback!