SAP S/4HANA is an integrated enterprise resource planning (ERP) system that manages various business functions, including Human Resources (HR), payroll, sourcing, procurement, product development, manufacturing, sales, and distribution.
SAP S/4HANA has certain distinctive features that sets it apart from other ERP systems like Oracle Fusion Cloud ERP, Oracle NetSuite ERP, and Microsoft Dynamics 365. These distinctions can have implications for auditing and compliance. The history of SAP S/4HANA came about is also unique.
A Brief History of SAP
Before the term "ERP" was even coined, SAP’s initial software, SAP R/1, can be considered one of the earliest ERP applications. SAP was established in 1972 by five ex-IBM employees who envisioned creating a real-time, integrated software solution for enterprises. They developed their own programming language, ABAP, and built the application from the ground up using this language. This approach led to the creation of several unique SAP models and principles, including the SAP authorization concept, which is a specialized user security model.
It’s interesting to note that the founders opted for extensive custom development rather than adopting existing standards of the time. or example, the Resource Access Control Facility (RACF) and Access Control Facility 2 (ACF2), well-known mainframe security tools, were developed following SAP's original releases in 1976 and 1978.For instance, Resource Access Control Facility (RACF) and Access Control Facility 2 (ACF2), popular mainframe security applications, were introduced after SAP's initial releases in 1976 and 1978, respectively. From an auditing perspective, SAP’s historical development approach means that its systems, including SAP S/4HANA, often operate differently from other ERP systems due to their early and unique development practices.
Hardware-Agnostic Architecture
In the early stages of software development, applications were often tightly coupled with the specific hardware and databases they ran on. This meant that changing from one database system, such as IBM Db2, to another, like Microsoft SQL Server, required the creation of an entirely new application. Although modern applications still exhibit some of this dependency—applications designed for macOS or Unix, for instance, often require separate versions for Windows—SAP's founders were notably ahead of their time. They engineered SAP to handle many tasks within the application that would typically be managed at a more technical level. A prime example of this is how SAP manages interactions with its underlying database.
In conventional applications, activities tied to specific databases, such as indexing, table creation, and performance monitoring, are handled directly within the database. However, SAP was designed so that most Database Administrator (DBA) tasks are carried out through the application rather than directly in the database. For instance, in SAP S/4HANA, DBAs can create tables and fields, index fields, and monitor database performance through specific transactions within the application. As a result, it’s rare for DBAs to access the database directly, usually only doing so for emergency or exceptional maintenance.
The separation between the SAP application layer and the database is even more pronounced in SAP ERP (including its predecessors, SAP R/3 and SAP R/2) compared to SAP S/4HANA. Certain table categories, such as cluster tables and pool tables, are not recognized by the database and table relationships are maintained within the SAP application layer, not the database itself. Consequently, using database-specific query tools won't reveal tables like BSEG (accounting document line items), MSEG (material movements by item), or CDPOS (change document logging). SAP application layer controls access to these tables. Specialized tools that interact with the SAP application layer, often via remote function calls (RFCs), are necessary for audit analysis. SAP S/4HANA mitigates some of these requirements by being Open Database Connectivity (ODBC)-enabled, thus reducing the number of application-specific tables.
Additionally, SAP's hardware-independent features include managing network activity. SAProuter functions similarly to a traditional router, facilitating network segmentation within the SAP application itself. Additionally, SAP components like SAP Gateway act as firewalls, allowing configuration files to specify permitted or denied IP addresses and define which external users and programs are allowed access.
Unified Application Environment
In some software systems, users or third parties are unable to perform development or configuration tasks due to the absence of developer tools. However, in SAP S/4HANA, all users have access to developer tools as there is no distinct application for developers, administrators, or business users. The SAP S/4HANA environment includes all necessary tools for development, administration, and business functions. Developers, administrators, and business users do not have the same security permissions as their roles differ from each other. From an auditing perspective, this integration can make it easier for users or third parties to inadvertently gain elevated access, unlike systems where development and administrative roles are divided among separate applications.
Transparent Source Code
SAP S/4HANA operates with visible source code for most of its functions, including all standard business processes. This transparency contrasts with many other applications where core functionality is opaque. In SAP S/4HANA, users with appropriate authorizations can view the source code, which is advantageous for auditing. It allows auditors to clearly determine the actions of specific SAP programs. However, this transparency does not extend to highly technical operations, such as work process prioritization or communication layer functions, which are less relevant for business processes and typically not included in audits.
Alignment of Source and Compiled Code
In many software applications, source code written by developers must be compiled into executable code for computers to execute. This compilation process can introduce discrepancies between the original source code and the compiled version. But in the case of SAP S/4HANA source code and compiled code are in sync. When an SAP S/4HANA server starts or reboots, there is no pre-existing compiled code. Instead, the system compiles the source code in real-time when a program is first run. This real-time compilation eliminates the risk of mismatches between source and executable code, making it a non-issue from an auditing perspective.
Gemini Consulting & Services can help enterprises to leverage the unique features of SAP S/4HANA to improve efficiency and optimize resources. Contact us to know how our consultants can customize S/4HANA to meet your business requirements.
Limited Greenfield Customizations
SAP S/4HANA allows for customizations but limits and structures them more than many other ERP systems. The SAP code is almost impossible to modify without permission from the company. When organizations develop custom functionalities due to gaps in standard SAP code, SAP often integrates these enhancements into future releases after working with the organization. What was once custom may become a standard feature in later updates.
SAP also anticipates the need for advanced or customized code by including user exits—sections of code that can interface with user-defined or third-party code. This approach allows for customized inputs without necessitating a complete rewrite of the core program. Additionally, SAP aims to keep customizations within the framework provided by the Implementation Management Guide (IMG), maintaining a structured approach to flexibility. This method of customization ensures that SAP S/4HANA remains a reliable system, avoiding the unpredictability of unrestricted user modifications.
