Tabellenorientiertes Prüfen des SAP P2P-Prozesses auf SoD Konflikte

Ein Gastbeitrag des Data Scientists und Auditors Marcus Herold (IBS Schreiber) beantwortet drei elementare Fragen für die Überprüfung, ob die Funktionstrennung (SoD / Segregation of Duties) bei der SAP-Rechtevergabe eingehalten wird:

Was sind wichtige Grundsätze der Datenanalyse in SAP? Wie finde ich die richtige Tabelle? Wie überprüfe ich tabellenorientiert die Einhaltung von SoD-Vorgaben im Beschaffungsprozess? Hier erfahren Sie mehr:

 

Wichtige Grundsätze der Datenanalyse in SAP

Durch langjährige Erfahrungen in der Durchführung von Datenanalysen haben sich folgende Grundsätze herauskristallisiert, die bei Durchführung von (Massen-) Datenanalysen von zentraler Bedeutung sind:

1. Wenn möglich, tabellenorientiert (Rohdaten) prüfen
2. Daten eigenhändig aus dem SAP-System exportieren
3. Nicht nur stichtagsbezogene Analysen durchführen, sondern auch die Veränderungen über die Zeit analysieren
4. Standardisierung der Analysen
5. Ausführliche Dokumentation der Analysen

 

Tabellenorientiert Rohdaten prüfen

Wenn Datenanalysen durch Einsatz von Transaktionen und Reports durchgeführt werden, arbeitet man bereits auf von SAP verarbeiteten Daten. In dieser Verarbeitung können Fehler passieren. Um dies auszuschließen, ist es besser mit den in den Tabellen gespeicherten Rohdaten zu arbeiten. Transaktionen und Reports liefern häufig aggregierte Werte – für die professionelle Datenanalyse benötigt man jedoch die einzelnen Datensätze.

Wenn man auf der Grundlage der Tabellen arbeitet, ist man nicht in den datenanalytischen Fragestellungen beschränkt. Durch Auswahl und Verknüpfen der richtigen Tabellen kann ein Geschäftsprozess vollständig abgebildet werden. Das ganze Datenuniversum des Prozesses liegt vor einem und kann nach vielfältigen Aspekten ausgewertet werden.

Eine Massenanalyse von Daten kann nur auf der Grundlage von Tabellen durchgeführt werden.

SAP-Daten eigenhändig exportieren

Lässt man den Daten-Export durch Dritte durchführen, kann man nicht sicher sein, ob das fehler- und manipulationsfrei durchgeführt wurde. Es ist daher anzuraten, den Export selbst durchzuführen.

Ferner ist zu empfehlen, für den Export großer Datenmengen aus SAP spezielle Tools einzusetzen (SmartExporter oder dab:Exporter).

 

Veränderungen im zeitlichen Verlauf analysieren

Eigene Erfahrungen zeigen, dass die „Musik“ der Datenanalyse in den Veränderungen über die Zeit spielt.

Wenn stichtagsbezogen (Snapshot-Informationen) analysiert wird, kann der Prüfer nur eine Aussage zum Stichtag machen. Besonders bei forensischen Analysen ist es aber so, dass versucht wird, die Spuren betrügerischer Handlungen nach ihrer Ausführung zu beseitigen. Solche Sachverhalte können nur durch die Analyse von Veränderungen herausgefunden werden.

Beispiel: Die Kontoverbindung eines Kreditors wird vor dem Zahllauf auf die eigene geändert, nach dem Zahllauf wird diese auf den ursprünglichen Zustand gebracht. Im Snapshot ist dies nicht sichtbar, in den Änderungsbelegen dagegen schon!

 

Standardisierung und Dokumentation

Professionelle Datenanalysen arbeiten mit komplexen Algorithmen und einer Vielzahl von Verarbeitungsschritten. Um eine Vergleichbarkeit und Reproduzierbarkeit der Analysen zu gewährleisten, ist eine Standardisierung durch Analyseroutinen (Programme, Makros) unumgänglich.

Alle Prüfschritte sind ausführlich zu dokumentieren, um das Ziel der einzelnen Analyse, ihre Datengrundlage, die verwendeten Verfahren, sowie das Ergebnis und dessen Interpretation einem sachkundigen Dritten vermitteln zu können und damit Transparenz zu schaffen.

 

Wie finde ich die richtige Tabelle?

Eine Hauptschwierigkeit beim tabellenorientierten Prüfen ist die Ermittlung der Tabellen und Felder, die die prüfungsrelevanten Informationen speichern. Da die benötigten Informationen meistens über mehrere Tabellen verteilt sind, muss in einem weiteren Schritt geklärt werden, über welche Schlüsselfelder die Tabellen miteinander zusammenhängen.

Um diese Informationen zu gewinnen, sind in der folgenden Tabelle einige Tabellen und Transaktionen aufgeführt, die einem bei der Tabellenanalyse wertvolle Hilfestellung leisten können.

 

Tool / Informationsquelle	Beschreibung
Transaktion SQVI	Werkzeug zur einfachen Generierung von Listen Arbeitet auf Tabellen, Tabellen-Joins, logischen Datenbanken und Infosets. QuickViews können sehr gut als Kontrollinstrument eingesetzt werden.
Tabelle DD09L	Technische Einstellungen von Tabellen Das Feld „PROTOKOLL“ gibt Auskunft darüber, ob eine bestimmte Tabelle protokolliert wird. Diese Information ist besonders wichtig bei unternehmenseigenen Tabellen.
Transaktion SD11	Der Data Modeler ist ein Entwicklungswerkzeug, mit dem man Datenmodelle nach der SAP-SERM-Methode (SERM = Strukturiertes Entity-Relationship-Modell) erstellen kann.
Transaktion SE11	Über das ABAP Dictionary können Beziehungen zwischen Programmen (Reports, Transaktionen) und Tabellen über die Funktion „Verwendungsnachweis“ analysiert werden. In den technischen Einstellungen der Tabellenfelder kann geprüft werden, ob für ein bestimmtes Feld Änderungsbelege geschrieben werden
Transaktion SE84	Das Repository Infosystem stellt umfangreiche Such- und Analysefunktionen für Tabellen zur Verfügung. Neben der direkten Tabellensuche und –anzeige kann hierüber auch nach einzelnen Tabellenfeldern gesucht werden. Beziehungen zwischen Tabellen können grafisch angezeigt werden.
Transaktion SLDB	Wichtige Informationsquelle bezüglich der datentechnischen Zusammenhänge zwischen prozessbezogenen Stamm- und Bewegungsdaten.
Transaktion ST05	Mit der Performance-Trace lässt sich der Datenverkehr (beteiligte Tabellen, SQL-Statements) analysieren, der bei der Ausführung eines Programmes entsteht.

 

Die nachfolgende Abbildung zeigt eine Übersicht der verschiedenen Suchoptionen zum Nachvollziehen von Datenstrukturen in SAP.

 

An dieser Stelle sei auch auf den Artikel „Wie finde ich die richtige SAP®-Tabelle?“ in der PRev 4/2010 verwiesen, in dem einige der oben aufgeführten Suchoptionen nähert erläutert werden.

 

Wie überprüfe ich tabellenorientiert die Einhaltung von SoD-Vorgaben im Beschaffungsprozess?

Tabellenstrukturen

Wie ein Geschäftsprozess durch Datenstrukturen abgebildet werden kann, wird nachfolgend am Beschaffungsprozess (P2P) dargestellt.

In der folgenden Abbildung sind die relevanten SAP-Tabellen aufgeführt, die zu einer Datenanalyse des gesamten Geschäftsprozesses herangezogen werden.

In den folgenden Übersichten sind die wichtigsten Tabellen des Beschaffungsprozesses aufgeführt:

Exemplarisch wird nachfolgend eine Fragestellung aus dem Beschaffungsprozess auf der Grundlage von Tabellen durchgeführt.

 

Vorgehensweise:

1. Die benötigten Tabellen werden exportiert.
   EBAN sowie die Kopftabellen EKKO, MKPF, RBKP und EKBE. Die Tabelle LFA1 wird nur für die Bereitstellung von Zusatzinformationen zum Lieferanten benötigt.
2. Die Tabellen werden in eine Datenbank (z.B. MS Access) oder Analyse-Software (z.B. IDEA oder ACL) eingelesen.
3. Die Tabellen werden miteinander verknüpft.
   Problem: Es gibt keine einheitliche Belegnummer, die sich durch den ganzen Beschaffungsprozess durchzieht.
4. Es werden entsprechende Abfragen erstellt, um mögliche SoD-Konflikte zu finden.

Problematik der verschiedenen Belegnummern

Im folgenden Beispiel wird ein Bestellvorgang dargestellt. Man erkennt, dass der Bestellung in den verschiedenen Phasen des Bestellprozesses drei verschiedene Belegnummern zugeordnet werden.

Bestellung (Belegnr. 4500013964):

Wareneingang (Belegnr. 5000006371):

Rechnungseingang (Belegnr. 5105606072)

Woher weiß man, welche Belegnummern man verknüpfen muss, wenn es keine eindeutige Belegnummer gibt? Die Lösung ist die Tabelle EKBE (Historie zum Einkaufsbeleg)!

Aus dieser Tabelle (siehe nächste Abbildung obere Tabelle) wird ersichtlich, welche Belegnummer aus dem Wareneingang (Vorgangsart 1) und welche Belegnummer aus dem Rechnungseingang (Vorgangsart 2) dem Einkaufsbeleg zugeordnet sind.

Nach dem Exportieren der Tabelle EKBE (Achtung! Diese Tabelle ist sehr groß) müssen zwei neue Tabellen generiert werden. Diese zwei neuen Tabellen benötigen nur die Spalten „EKBE-EBELN (Einkaufsbeleg)“, „EKBE-VGABE (Vorgang)“ und „EKBE-BELNR (Materialbeleg)“.

In der ersten Tabelle (Umsteiger zwischen Bestellnummer und Wareneingangsnummer) werden alle Belege mit der Vorgangsart = 1 (Wareneingang) abgespeichert. In der zweiten Tabelle (Umsteiger zwischen Bestellnummer und Rechnungseingangsnummer) werden alle Belege mit der Vorgangsart = 2 (Rechnungseingang) abgespeichert.

Nun hat man alle erforderlichen Tabellen zusammen und kann sie in einem Softwaretool (z.B. MS Access, IDEA) miteinander verbinden:

Mit einer Abfrage können nun für die jeweiligen Teilprozesse die Benutzer-IDs ermittelt und die einzelnen Bestellungen auf Funktionstrennungskonflikte geprüft werden.

Eine mögliche Ergebnisliste ist in der nachfolgenden Abbildung dargestellt:

 

Literatur

Chuprunov, Maxim (2019). Handbuch SAP-Revision. 3., aktualisierte und erweiterte Auflage. SAP PRESS, Bonn.

Hartke, Hohnhorst, Sattler (2010). SAP Handbuch Sicherheit und Prüfung. 4., völlig überarbeitete und aktualisierte Auflage. IDW Verlag, Düsseldorf.

Herold, Marcus (2010). „Wie finde ich die richtige SAP-Tabelle“. Erschienen in PRev – Praxis in der Revision, Heft 4/2010. Boorberg Verlag, Stuttgart.

Klindwort, Holger (2006). Handbuch der Datenprüfung. Boorberg Verlag, Stuttgart.