After my previous blog What’s so Simple about SAP Software (Part 1), I want to continue going down this journey of SAP’s intent to simplify their enterprise solutions. I was prompted to blog on that topic because we frequently field questions from customers looking at upgrading to S/4HANA. A few years ago when SAP initially labeled S/4HANA’s initial changes to the financial areas as Simple Finance, it led to the obvious question, what is so simple about SAP? What does SAP mean by ‘simple’? Let’s keep finding out.
History
If SAP is simple now, was it complex before? Let me cover that topic.
The thing that I find most intriguing about SAP’s push towards simplification is that SAP has now come full circle with the design and technical architecture of the finance solution (I’m referring to FI/CO). What do I mean? From R/2, to R/3, and finally to mySAP ERP (aka, ECC), SAP’s financial solution relied on a dual ledger solution. Financial data for external accounting purposes that required a fully balanced set of books was recorded in the Financial Accounting module (FI). Data that was used for internal reporting purposes and management accounting was posted in the Controlling module (CO). Some data was in FI, some was in CO, and some was in both. Considering that the majority of the SAP customers that were implementing SAP for the first time were usually running some sort of a mainframe solution with a single coding block, this was a big change. They were used to including so many financial related codes to properly assign the costs that it was difficult for them to wrap their heads around this “here, there, sometimes everywhere” design that FI/CO presented. And to be fair, it wasn’t just the customers… it took me a solid year to see the big picture of FI versus CO to the point that I could talk accurately consult on it.
Have you seen these slides before? FI and CO have always been separate modules.
FI and CO also have separate use cases and audiences.
And finally, you can see how the chart of accounts was split across the two separate modules. Keep in mind that the chart of accounts is the backbone of every financial solution so this is a major architectural issue for SAP and a significant design issue for implementations.
Making the GL Newer
This started to change with the introduction of the NewGL in mySAP ERP 2004 (ECC circa 2005). The NewGL made a series of changes that got us away from SAP’s dual ledger solution. Most importantly, it introduced a new element to the traditional FI coding block; Ledger. The fundamental benefit of this is that it lets you segment your balance sheet so that you maintain values in parallel ledgers. Additionally, SAP wanted to move away from having the financial data spread out over so many different modules. The data had become fragmented across the Material Ledger, Special Purpose Ledger, Profit Center Accounting, the GL itself, and other industry specific areas (mostly Funds Management). At the same time, the accounting requirements around parallel valuation were coming into play which required SAP to track all postings under different accounting valuation rules at the same time. The introduction of the Ledger accomplished this so we could track US GAAP, IAS/IFRS, HGB, GASB and other industry valuation/ledger requirements for the same singular journal entry.
The point of the slide below was to show that the accounting interface (RWIN) was used to post documents to the same modules listed previously. Now with the NewGL (the current name is SAP General Ledger), SAP was able to handle the bulk of the work directly in the GL. PCA and SL, to name the some of the most prominent modules, were no longer needed.
Next?
Next, I’ll cover the big introduction in S/4HANA that took this solution even further.
Making SAP Software Simpler (Part 3): Technical Simplification
