This blog series is split into three parts and is essential guidance for any finance professional working with SAP.
The first part focuses on SAP origins and some of the basic working logic of the system. Before you can automate SAP effectively, you should understand why SAP works as it works. If you are a seasoned SAP veteran, you have probably lived through the days I will describe in the first part.
In the second part, I will define the financial area processes you can typically automate.
In the final part, I will provide practical insights on to how an intelligent automation solution like Aico integrates with SAP to deliver high efficiency key record-to-report accounting processes, such as account reconciliations, period close, journals, and request documents like manual invoices and payments.
A short history of SAP
Origins of SAP
SAP was founded by five ex-IBM employees in Germany in 1973. They named their company “Systemanalyse und Programmentwicklung” which means “System Analysis and Program Development” in English. Personally, I was born in 1980 and lived happily without knowing about ERP systems, until I heard the acronym SAP first time in 2006. In 2007, I got my first SAP job. Nowadays, the acronym SAP is widely known, but still quite often, I need to explain what SAP means.
The first SAP version was a mainframe-based business application (mainframe means a large computer; check more definitions and cool images from Wikipedia). Nowadays, we have many supercomputers that can also be considered mainframe computers, but in the earlier era, those computers had less calculation power than cheapest smartphones have now. If you look at photos from 1970s, you can see that back then, computer operators wore suits with ties, not hoodies like IT guys nowadays. In those days, everything was developed from an engineer to an engineer and no one talked about user experience or usability.
In 1990s, the Berlin wall collapsed and Cold War ended. SAP released R/3, which was based on server-client architecture. Some companies had used the server–client model earlier, but for SAP R/3 was a crucial factor for success. When clients finally connected all offices to the main server, there was no longer need for data transfers. I remember the stories of my senior colleagues describing how they had to use a taxi to transport disks and paper calculations between two offices. Usually the biggest and strongest man in the office was selected for these missions. When R/3 was launched in 1992, the product changed so that it was from an engineer to an accounting specialist. Normal accountants still used a few dozens of transaction codes and ran some reports, and everything else demanded a technically skilled user.
R/3 means that the system is divided into three different parts:
-
Presentation layer, which is SAP GUI in user computer
-
Application layer, which contains all the functionalities and coded applications
-
Database layer, in this level all details are in tables
In 2004, a new ERP Central Component was launched. You have probably already noticed that both Germans and engineers really like acronyms. If it is possible to save a couple of characters, they will do it. In case you are not familiar with all SAP R/3 modules related to Financials area, here is a short list.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
The modules listed below are logistics modules, but they also have an important link to SAP Financials area:
|
|
The following technical modules are also important:
|
|
|
I mentioned the term “transaction code” earlier. In case you have ever spoken with an SAP user, you probably remember them talking about t-codes. Before the age of internet, it was hard to get t-code lists, so companies’ intranets were full of lists containing different kind of transactions. Even nowadays, many consulting companies are publishing lists of most used transaction codes of their customers. The length of a t-code is usually four characters (both letters and numbers are allowed). Each code opens one SAP functionality, for example, FB01 is used to post a document and FS10N to run a report.
Transition to user-friendly interface
After the last financial crisis (the Great Recession) something strange happened in the IT industry. A new generation of employees entered the job market and started demanding easier ways of doing things. No one was interested about learning hundreds of t-codes or seeing unnecessary fields when posting documents to SAP. The change also affected general IT use, people started to speak about seamless user experience and wanted a possibility to do business transactions with smartphones using just fingertips.
SAP was surprised about these new demands, but they reacted quite fast. HANA S4 is coming (support for R/3 is ending in 2025) and there will be some changes in modules. For example, Simple Finance and Universal Documents are changing the ERP core. HANA is an abbreviation for High Performance Analytic Appliance. HANA Cockpit is also changing the game, and knowing that many transactions are becoming irrelevant, you should select the correct application which will do the trick.
SAP integrations
A good thing about SAP is that there are many ways to integrate to it. You can use IDocs, Batch Files, RFC, OData, SOAP web services, and so on. In addition, there is even a dedicated module XI/PI/PO that you can use to change integration types. For example, you can have a XISOAP servlet for a web user, but finally you will run Remote Function call in SAP.
Indirect usage
Nowadays, when someone talks about integrations to SAP, you should think how indirect usage would affect your way of working. If you want to make a CIO to get more grey hair, you can ask if our SAP really follows indirect usage guidelines. That question is almost as good as asking if you are absolutely sure that all your data systems are GDPR-compliant.
In 1990s or beginning of the millennium SAP was not that interested in how their customers integrated to SAP. The world was different, and no one was interested in creating web pages where you could fill in data straight to the ERP system. Everyone was talking about IDoc, which is an acronym for Intermediate Document. IDoc is meant for transferring messages (information) from an SAP system to other systems and vice versa. IDoc is still a popular way to send data. However, the main problem is that IDoc doesn’t work in real-time. You need to first send an IDoc, then receive it, and finally process it. There are many hundreds of different IDoc types and configuration is complex, so IDoc in SAP was and still is one of the most common areas to monitor.
There has always been a need for an instant integration to SAP, and finally, when certain new technologies started to become more popular, SAP woke up. If everyone started using only integrations, finally there would be only technical user IDs in the SAP system and that would not be good for business. In 2017, news of a major lawsuit between SAP UK and Diageo Company emerged. Diageo was judged to pay over 54 million pounds of compensation to SAP. In 2018, Computer Weekly published a story that US Securities and Exchange Commission (SEC-20 F) filing revealed that Belgian brewer giant Anheuser-Busch InBev had settled their indirect usage with SAP. According to the article, the settlement cost a whopping 600M$ to the world’s largest brewery group.
Final words
I hope that you now have an overall understanding SAP Financial history. In addition, you should also know which SAP modules there are in the Financials area. In the next part of my blog series, I will introduce a few finance automation cases and tell you more about ways to integrate with SAP in real-time.