Get 15% Discount on every Course. Use Coupon Code : 
Search Available Exams
www.exactprep.com
16 03 2024 05:14 PM
In essence, ERP systems are applications that are designed to run the entire enterprise—from human resources (HR) and payroll to sourcing and procurement, product development, manufacturing, sales, and distribution. Despite being in the same broad category as other ERP systems such as Oracle Fusion Cloud ERP, Oracle NetSuite ERP, and Microsoft Dynamics 365, SAP S/4HANA has current and historic differences that are important to understand. Each of these differences have audit-related implications (or at least can help explain issues/questions that may come up during an audit). Said another way, if you’re scratching your head at times and wondering, “Why the heck does it work this way?” or “What were they thinking?”, sometimes the answer lies in these differences, which we will discuss in this blog post.
While the term ERP had not been coined yet, SAP’s first software product SAP R/1 was arguably the world’s first ERP application. SAP was founded in 1972 by five former IBM employees with the bold vision to create the first real-time, standardized, integrated enterprise software solution. The founders developed their own programming language and wrote the application from scratch in this language (ABAP). In fact, the founders developed a lot of models and principles that are unique to SAP, including the SAP authorization concept (a user security model).
We have periodically wondered why the founders of SAP did so much custom development, rather than rely on computerized standards that existed at the time. For example, Resource Access Control Facility (RACF) and Access Control Facility 2 (ACF2) were very popular mainframe security applications. Why didn’t SAP use those instead of writing their own security model? It turns out, both of these security applications were developed after SAP’s first release (in 1976, and 1978, respectively). From an audit perspective, the main implication of SAP’s history is that that SAP developers had to create their own models/practices/processes for doing things well before the convergence of standards, and thus in many technical areas, SAP S/4HANA works differently from other ERP applications.
In the early days of software development, most software packages were beholden to the computer hardware and databases upon which they ran. This means that if an organization decided they wanted to switch from a legacy database like IBM Db2 to a database like Microsoft SQL Server, a whole new application was required. We even see this in modern applications, to some extent, where applications designed to run on macOS or Unix are often not compatible with Windows operating systems, and thus require a separate set of code. The founders of SAP were well ahead of their time; they developed SAP to execute many things within the application that would normally be done at a more technical layer. The most classic example of this is how SAP interacts with the underlying database.
In many applications, database-specific activities (such as adding indexes, creating custom tables/fields, doing performance monitoring/tuning, etc.) are done directly in the database. SAP was developed in a way that most database administrator (DBA) activities are performed not within the database itself, but within the application. In SAP S/4HANA, specific transactions exist for DBAs to create tables and fields, index fields, create views, and monitor database performance. From an audit perspective, this means that it’s very uncommon for a DBA to have to log into the database directly, and typically when they do so, it’s related to emergency or non-standard maintenance purposes.
The role of the SAP application layer to the database is even more pronounced in SAP ERP (and SAP R/3 and SAP R/2 before that) than it is in SAP S/4HANA. For example, there are categories of tables, specifically cluster tables and pool tables, that aren’t known to the database at all. Additionally, table relationships are not maintained in the database, but rather in the SAP application layer. To be clear, this means that using a query tool specific to the database upon which your SAP system is running, you won’t see tables like table BSEG (accounting document line items), table MSEG (material movements by item), or table CDPOS (change document logging details by field)—those are only accessible by going through the SAP application layer instead of the database layer. As such, special tools that go through the SAP application layer (often through a remote function call [RFC]) have been required for audit analytic purposes. SAP S/4HANA takes away some of this requirement by being Open Database Connectivity (ODBC)-enabled, and eliminating tables that are known to only the application and not the database.
Another example of SAP having hardware-agnostic functionality relates to restricting network activity. Not only does SAProuter act very much like a traditional router and allow for network segmentation defined within the SAP application itself, other components of SAP act as a firewall. SAP Gateway, which is also configured directly within the SAP S/4HANA application, can accept configuration files containing things like permitted/denied IP addresses, as well as files that define not only which programs external users (applications) can work with, but also which server hosts those external users. While we’d never expect an organization to leave router and firewall configurations open because “SAP S/4HANA already does it,” a strength of this model is that, if a router or firewall setting changes outside of SAP, the application can still maintain some basic protections.
In some applications, you may find comfort that end users or third parties can’t perform development or configuration functions because they don’t have developer tools installed on their system. Technically in SAP S/4HANA, every user has developer tools installed. In fact, every user has every administrative tool installed because there isn’t a different application for developers versus Basis administrators versus database administrators versus security administrators versus business users—it’s all in the SAP S/4HANA application. The only thing that truly makes a developer a developer, an administrator an administrator, and a business user a business user are the permissions that have been granted through their security authorizations. From an audit perspective, this means that it’s easier for users or third parties to erroneously receive elevated access than in applications in which development and administrative functions are physically separated within different applications.
Most of SAP S/4HANA, including all code that performs standard business activities that we are aware of, runs from code that is completely visible to users with the proper authorizations. Unlike many applications where the code performing core functionality is a black box, SAP makes the SAP S/4HANA code transparent. From an audit perspective, this is a huge benefit. If there are questions about what a specific SAP program is doing, the auditor (likely assisted by someone who can read ABAP code) can make this determination definitively. The only exception to this “visible code” statement relates to very technical operations (such as how SAP prioritizes work processes or operates at the communication layer), which is due to their very technical nature and the fact that they don’t directly impact the outcome of a business process and are often not in scope for an audit anyway.
In many common computer applications, developers use a computer programming language to write lines of code, the final version of which is known as the original source code. While the source code defines the order and logic of the computer operations to be performed by the application, the underlying computers themselves cannot directly read the source code. Once ready to run, the source code must be compiled, which is a process that turns the code from something a programmer can understand to something a computer can understand. Compiling the source code ultimately generates the executable code that the computers then run.
Because of this “code first and then compile” process, many computer applications are subject to the risk that the compiled (executable) version of the code is different from the final source code the developer intended. This could be the result of the developer forgetting to compile the code, the computer application being pointed to an older version of the compiled code (and not updated to point to the newest compiled code), an attacker inserting their own compiled code that doesn’t represent what the developer wrote, or a myriad of other similar factors. Thus, it’s common that during a code-related IT audit, the auditor may perform testing to ensure that the executable files are current and related to the most recently approved version of the source code.
In SAP S/4HANA, the source code and the compiled code will always be in sync, so there is no risk of the two being different. This is because SAP always starts with the source code. More specifically, when a server running the SAP S/4HANA application starts (or reboots), there is no existing compiled code. The first time a user runs a program after startup, SAP S/4HANA will read the source code and compile it in real time. From an audit perspective, this means that the risk of source code not being consistent with compiled code is not relevant.
If you’ve ever run a transaction or program in SAP and noticed a clock in the status bar with the caption “compiling,” it means that you are the first person to run that program on the SAP server since a reboot.
While SAP S/4HANA, like other ERP systems, allows for user organizations to make customizations, true greenfield customizations are both limited (at least compared to other ERP systems we’ve worked with), and more structured. First, SAP protects its own code from modification, and using standard SAP functionality, it’s impossible to modify SAP-delivered code without receiving permission and assistance from SAP. Where organizations have had to develop their own set of functionalities because SAP-delivered code was lacking, SAP does a pretty good job of identifying these areas, subsequently working with the organization to understand and enhance what has been developed (often by bringing relevant customer team members to SAP headquarters in Germany), and ultimately incorporating this new functionality into future releases. As such, what once was custom often becomes standard in later releases.
SAP also does a good job of anticipating where more advanced/customized code might be needed, and incorporating user exits (sections of code that can call out to user-defined or third-party code and return values back to the main code block) into standard programs so the core program can run with customized input, without requiring a complete rewrite. Lastly, SAP attempts to keep as much customization as possible within standard forms provided in the Implementation Management Guide (IMG). The IMG is akin to the “options” area of Microsoft products, where through checking boxes, filling out fields, and selecting dropdown lists, you can effectively have your Microsoft products behave differently from your neighbor’s (without ever having to write a single line of code).
We often hear frustrated IT or business users complaining about SAP creating inflexible software that is difficult to customize to the way an organization works. In our experience, we would argue that SAP is very flexible, but only in a highly structured way. While it’s true that SAP S/4HANA generally doesn’t allow things that some organizations deem as requirements, our experience is that often those requirements are based on outdated legacy ways of doing business that really aren’t good practices to begin with. For example, we’ve worked with organizations that have claimed a requirement to put newly purchased goods into the manufacturing process before the related goods receipt has been entered into SAP. That to us feels indicative of a broken receiving process. We believe that the highly structured way in which SAP S/4HANA allows customizations makes it a much more reliable program than one that allows end users to effectively customize it in whatever they want.
To close our introduction to SAP S/4HANA, we leave you with some fun facts about the suite.
The original German name for the company, SystemAnalyse Programmentwicklung, translates to English as System Analysis Program Development. Several years after inception, SAP renamed itself to Systeme Anwendungen und Produkte in der Datenverarbeitung, which translates to Systems, Applications, and Products in Data Processing. The company now goes by its initials, SAP.
SAP is headquartered in a small German town called Walldorf, which has an estimated population of 15,545 people as of 2020. If every employee in SAP were to move to Walldorf, the town population would increase roughly sevenfold (SAP has nearly 110,000 employees worldwide).
The second major release of SAP’s flagship software was known as SAP R/2, and the third release was known as SAP R/3. While not technically the name at the time, many now refer to the initial release as SAP R/1. The “R” stands for real-time, which was fairly unique to SAP as most applications at that time used periodic batch processing. The “2,” and later the “3,” stands for the number of tiers in the architecture. With SAP R/2 being the mainframe version, the database layer was separate from the application layer making a two-tier architecture. SAP R/3 moved from the mainframe to the PC and included not only the separate database layer and application (server) layer, but it also moved the presentation layer (client) to the PC, making it a three-tier architecture.
SAP supports more languages than any other ERP system on the market. At the time of writing, SAP S/4HANA supports 39 languages, and SAP Translation Hub supports 45 languages.
SAP is one of oldest still-operating software companies in the world. While IBM and Hewlett-Packard were around well before SAP was founded, SAP as a company is older than Microsoft, Apple, and Oracle. In fact, SAP is 22 years older than Amazon and, at the time of this publication, twice the age of Google, and more than three times the age of X and Workday.
Editor’s note: This post has been adapted from a section of the book Auditing SAP S/4HANA by Steve Biskie.
Use Online Chat Option
(Bottom Right Side)
