As I continue reviewing SAP’s simplification effort, we’ve reached a major junction. I previously talked about how SAP’s simplification effort is built around two fronts. The first was covered in the first blog; SAP is simplifing the frontend. Customers are moving (and will most likely have to move) from SAPGUI to Fiori and UX. Soon.
The second front that SAP is using to simplify their solutions is at a more technical level. They are using S/4HANA as a justification to re-architect and simplify some of the most critical areas of the ERP solution.
Earlier blogs:
What’s so Simple about SAP Software (Part 1)?
Making SAP Software Simpler (Part 2): The Journey Continues
The Problem and Opportunity with SAP Finance?
If SAP wants to be a key component of the digital enterprise and assist customers in innovating around better enterprise solutions, they needed to re-focus on the most important areas of their ERP product. The most logical place to start innovating is on the GL since it’s the intersection of so many financial processes. SAP has taken this opportunity to simplify the tables that store FI transactional details and has introduced a new singular table to track all financial line items. Note, that it’s not just GL but line item details from other financial areas as well.
Let me back up and start from the beginning.
SAP had several concerns with their existing financial data model if it was going to be nimble enough going forward. SAP is under pressure to come to be the bedrock solution… a foundational piece… of customer’s plans for the digital enterprise that they wish to become. But in order for that to happen, their solutions must be much more powerful and flexible.
What were SAP’s concerns in this area? The first one with the existing financial data model was the amount of redundancy that existed. There were line item tables and separate summary tables above them that were used for reporting. Within fixed assets, we had table ANLC that stored aggregate calculated figures based on the line item values in ANEP and ANEA. A big problem with this design is the space that it takes up. What is a less obvious problem with this model is the amount of effort that is required to reconcile these two separate bodies of data. You have to have tools, checks, and reports in place to ensure that the two are reconciled. The data must remain consistent between the two and this leads to increased maintenance and sometimes very advanced administration to fix any problems that might come up.
SAP’s previous data model for the financial area also included a large series of similar transactional tables. BSEG stored GL line items but certain line items were stored in BSIS and BSAS as well (just one example). This was done without providing any additional level of detail… it was all just the same GL line item but from a slightly different perspective.
By removing these reporting tables, SAP would have to perform more on-the-fly calculations against the detailed line item tables. How can that be done?
Enter HANA.
It was only because of HANA — it’s massive performance increase, compression, columnar storage, in-memory storage, increased efficiency, increased data management, and data architecture simplification — that has enabled the idea to even think of joining multiple line items tables within FICO. Here’s a good quote from Verena Stuetz of SAP: “It was only with the introduction of the SAP HANA database technology that the last logical step could be taken, namely to unite the FI and CO components into one physical table (table ACDOCA).” That leaves us with the new S/4HANA data model for Simple Finance.
Stepping outside the GL, we can start to see the how other modules within FICO would interact with it. Each of these other modules had their own line item and summary tables storing the details of their data from their point of view. Obviously, with similar data stored multiple times in different areas, there is a lot of redundancy which requires a lot of reconciliation as well.
In this image below, you can imagine how a series of cost center postings in CO would be stored with very specific CO level details that are used to support reporting for that (CO) community. But this same journal entry would also be stored in the GL. Fiscal year end roll forwards have to be separately run in each module, reconciled, aggregated, etc. Once this design is replicated for fixed assets, material ledger, and CO-PA, the solution requires increased administration to ensure that all of this data reconciles and is consistent.
This was the old design. It served it’s purpose… no one is saying it was wrong because coming from the mainframe era of a singular code block that was limited in detail, this was the right approach. However it presented several challenges such as…
- You can only view the ‘true’ financial results if you combine all of this data together. As I’ve said earlier, this distributed data model requires that the data be reconciled on a consistent basis.
- Each module has it’s own separate data model to track line items as well as summary values…
- … yet each module was defined differently making reconciliation harder,
- … and cross-application reporting extremely difficult.
- There was no consistent approach to extend the tables for unique customer, industry, or country requirements. FI-AA had their approach and CO-PA had theirs.
The Journey to the ‘Truth’ is a Long and Hard One
In order to get the truth… the singular viewpoint of all financial activity… you would have to join all of this data together. SAP split it up and now you have to bring it back together! If you dive into the weeds of something such as customer profitability or global spend analysis (“Who are we spending the most money with and what is it for?”), you’ll quickly realize how difficult the task is when you have to source data from so many different financial and logistical modules, clean it, and then make sense of it in a uniform way. SAP never talks about this much in S/4HANA but this old cross-application reporting requirement, which every customer has a need for, is extremely difficult. Honestly, it’s a tremendous task for a billion dollar international corporation that has a normal amount of data to sift through. That’s a custom ABAP report that will spin for a long time.
The issue with this was that it wasn’t possible to get a total view of the data across these modules. Material Ledger does not store the GL account and profit center. Same thing in Asset Accounting for the totals tables… it’s not stored in asset line items either. CO has different levels of detail due to the 999 line item limit. CO-PA and the GL store profitability figures on different objects and at different business events. Lastly, even if you could align all of the data correctly for a given process, it wasn’t possible to quickly report on it across such disparate modules.
S/4HANA and the Universal Journal
The answer? The Universal Journal (table ACDOCA). ACDOCA is a single financial table that stores all of the line items details from the GL, CO-PA, CO, FI-AA, and the ML. Furthermore, the line item and summary tables that previously existing in those modules are no longer needed. If you post a new invoice to a cost center or capitalize an asset, the line items are only stored in ACDOCA. There is no summary table that exists above ACDOCA that aggregates the data for this department or that one. One table with all of the details.
Why did SAP do this?
For starters, SAP is serious about cleaning up the old architecture of R/3 that was previously based on a dual ledger design. As I said above, this older data model required lot of reconciliation, timing, aggregation of data and most importantly, a dis-jointed / fragmented set of data. For instance, there is a fundamental question in every organization to report on revenue. But who owns revenue? SD? FI? Combining the financial data into a single table as the singular destination for financial activity is a good way to solve that problem.
When SAP started on developing this new approach, they came up with a motto: “Financial reporting by any dimension. Available at any point in time with meaningful data“. In a more detailed way, SAP wanted to do the following:
- Build a “single source of truth”. This makes the technical architecture simpler to work with but also lays the foundation where SAP could come up with consistent solutions for multi-GAAP requirements, increased currency requirements, and most important, process simplification.
- Reduce the memory footprint. HANA is fast but having less data to read has an obvious benefit.
- Provide meaningful and richer data at any point in time
- Provide uniform extensibility with customer fields
- Be “non disruptive”
Benefits of Simplification
Let’s review. What are the practical and business oriented benefits of this? To an accountant, changing a bunch of tables might not mean much so here is a top-10 list of benefits that the business users can expect.
- With ACDOCA serving as a single repository of financial journal entries across multiple applications, it’s far easier for reporting. Where once we had to combine data from different sources and hope that there was enough uniformity in how they were defined (ex: GL vis-à-vis FI-AA), now we can just report off of ACDOCA.
- Increased detail. At first, it might not make sense that removing lots of detailed and summary tables would increase reporting detail but that’s what SAP has built-in to ACDOCA. Because all of the relevant reporting characteristics are stored on each line item, we can report across all of these dimensions regardless of the source. For instance, for a single asset posting we’ll get all of the asset details (that’s obvious) but we’ll also get all of it by profit center, by project, by account etc. Plus, it will have multiple currencies and GAAP valuations as well.
- The next big benefit is we’ve carved out a lot of redundant data. Yes, I know HANA is fast… SAP reminds us about that all the time… but having less data to report against is another easy lever to pull if you are searching for faster reporting performance. If car companies want to shave weight off a sports car to make it go faster, SAP can do the same with ANLC, ANLP, ANEK et al.
- With less data duplication, the data model is far superior. It’s easier for SAP Development to work with, but from our point of view, less redundancy means less administration. There is no more Reconciliation Ledger in CO, no more aggregate tables that have to be rebuilt, and no more CO-PA summarization levels to design. This results in an easier solution to support and administer.
- No more reconciliation. I don’t have to track down GL-to-asset reconciliation issues because both sets of data are stored on the same line item… and the line item exists in only one place (ACDOCA).
- HANA enables much faster reporting by itself but it should be even faster with a data model that is optimized for it.
- We expect to see a faster close process. There is less reconciliation to perform (either technically or manually), no more rebuild jobs, and faster reporting. All of that should make it easier and quicker to close.
- The solution is non-disruptive. SAP is pulling off a major switch with this new data model and they’ve done it in a way that ensure that existing reports, either SAP delivered or customer defined custom ABAPs, will continue to work. The original line item tables (such as ANEP) are still there but they’re defined differently. I’ll get to that in a future blog, but for now, rest assured that you can migrate your data to this model without giving up all of your custom reports.
- If you’re a big BI user, the extraction of data should be easier. Rather than having to schedule multiple line item delta loads, you can just worry about a single datasource built on ACDOCA. If you are asking your BI team to deliver a new report, it should be easier to investigate where the source data lies and how to get it.
- There are several benefits depending on which of these affected modules you are most concerned about. For CO-PA, there are new options if you are concerned about multi-dimensional CO-PA. For fixed assets, the first thing that comes to mind is that our depreciation run has been enhanced. Whereas we previously had an aggregation of asset values in the GL document, we can now see posted depreciation per asset… within the FI document. There are other specifics improvements for the other modules.
Looking Forward
What’s next? One thing to keep in mind is that SAP is still simplifying other modules within S/4HANA. For the areas that Serio Consulting focuses in, we’re keeping our ears to the ground so we are prepared when simplePS comes out. If you read the simplification list for each S/4HANA release, it’s clear that SAP is working on this. RPSCO and CJEN are clearly not going to be around much longer and I’m curious what they do for all of the plan/budget/commitment tables as well.
