Der wohl größte und für viele Leute greifbarste Bereich in der SAP Prüfung stellt wohl der Einkauf dar. Etwas mehr als ein Drittel aller unser Indikatoren fokussiert diesen Bereich und ist damit Anlass genug für eine umfangreichere Blog Serie.
Bevor wir im nächsten Blog Artikel ins Detail gehen, beschreibt dieser Artikel nochmal alle Grundlagen, die für die Prüfung des Einkaufs in SAP notwendig sind. Von dem Wandel der Prüfung bis zu der notwendigen Datenstruktur des Einkaufs ist alles dabei:
- Der Wandel in der Prüfung
- Die Chancen der automatisierten Prüfung
- SAP Datenstruktur im Einkauf
- Financial Process Mining
- Rasterfahndung
- Das Konzept der Indikatoren
Der Wandel in der Prüfung
Bei der klassischen Prozessprüfung muss zunächst der Einkaufsprozess durch den Revisor erhoben werden. Dies passiert in der Praxis häufig durch Interviews im Zusammenhang mit der Auswertung vorhandener Prozessdokumentation. Im Anschluss kann man weitere Überlegungen zu Risiken im Einkaufsprozess und dem Internen Kontrollsystem anstellen und das Interne Kontrollsystem dann ausgiebig testen.
Dieser traditionelle Ansatz kostet viel Zeit und in aller Regel wird mit dem Vorgehen der Einkaufsprozess auch nur so verstanden, wie er theoretisch ablaufen sollte. Tatsächliche Abweichungen im Prozess werden nicht immer erkannt.
Die moderne Prüfung von Einkaufsprozessen stützt sich empirisch auf die tatsächlich vorhandenen Daten im SAP System. Durch intelligente Algorithmen kann man aus den SAP Daten die Abläufe im Einkauf rekonstruieren. Im Anschluss können mittels Datenindikatoren Prozessschwächen entdeckt werden, die den verschiedenen Prozessschritten zugeordnet werden können. Die digitalisierte datengestützte Prozessprüfung übersetzt somit das fachlich richtige Vorgehen in eine digitalisierte Prüfungsmethode:
- Erst werden algorithmisch die tatsächlichen Prozesse rekonstruiert und
- anschließend Prozessschwächen über Datenanalysen identifiziert, die auf Schwächen im Internen Kontrollsystem hinweisen. Dies geschieht mit sogenannten Indikatoren, die jeweils eine revisorische Fragestellung repräsentieren
Ein solch digitales Vorgehen wurde im Rahmen des vom Bundesministerium für Bildung und Forschung (BMBF) geförderten Projektes Virtual Accounting Worlds in den Jahren 2010 bis 2013 erforscht.
Die Chancen der automatisierten Prüfung
Durch eine automatisierte Daten- und Prozessprüfung im Einkauf können Sie erhebliche Effizienzgewinne ergeben. Die Beteiligten haben folgende Chancen:
- Die Interne Revision in Ihrem Unternehmen kann die üblichen Risiken im Einkauf sehr effizient prüfen und somit mehr Zeit mit unternehmensspezifischen Risiken verbringen, die einer Automatisierung und Standardisierung schwer zugänglich sind. Automatisieren Sie die Beantwortung von Standardfragestellungen und fokussieren Sie ansonsten auf die wesentlichen unternehmensspezifischen Risiken.
- Der Jahresabschlussprüfer kann mit Hilfe von automatisierten Daten- und Prozessanalysen des Einkaufs im Rahmen seiner Abschlussprüfung Aussagen über das Interne Kontrollsystem ableiten.
- Der Revisionsmitarbeiter wird stark von rein handwerklichen Aufgaben wie Datenabzug, Dokumentation und Datenauswertung entlastet und kann sich mehr dem Professional Judgement von Feststellungen widmen. Effektiv bedeutet das: Mehr Zeit zum Prüfen!
SAP Datenstruktur im Einkauf
Bevor wir erklären wie die Datenzusammenhänge hergestellt werden können, folgt eine Liste aller relevanten SAP Tabellen zur Prüfung des Einkaufs:
- EKKO: Kopfdaten von Bestellungen
- EKPO: Positionsdaten von Bestellungen
- EBAN: Positionen innerhalb von Bestellanforderungen
- BKPF: Kopfdaten eines Rechnungswesenbelegs
- BSEG: Kontierungszeile oder Position eines Rechnungswesenbelegs
- LFA1: Stammsatz für Lieferanten / allgemeiner Teil
- LFB1: Stammsatz für Lieferanten / buchungskreisspezifischer Teil
- LFBK: Bankkontenstamm der Lieferanten
Die Daten sind in SAP demnach in Tabellen angeordnet.
Zusammenhänge mit dem Rechnungswesen
Bestimmte Belege im Rechnungswesen verweisen auf Belege des Einkaufs. Solche Rechnungswesenbelege sind häufig kreditorische Rechnungen und Wareneingänge. Dabei verweist die Position eines Rechnungswesenbelegs (Tabelle BSEG) im Datenfeld EBELN (Einkaufsbelegnummer) auf den Bestellbelegkopf (in Tabelle EKKO). Mehr zur Rekonstruktion der Prozessabläufe wird in dem Abschnitt Financial Process Mining beschrieben. Doch bevor Prozesse ermittelt werden, müssen die notwendigen Daten aus dem SAP System extrahiert werden. Da kommt schnell die Frage auf: „Wie kommt man eigentlich an die Daten für eine Analyse?“
Datenbeschaffung aus Ihrem SAP System
Die Beschaffung der Daten aus einem SAP System ist nicht immer einfach, je nach Umfang und Ziel der Analysen. Es gibt verschiedene Tools auf dem Markt, die Datenextraktionen aus einem SAP System anbieten. In der Regel wird allerdings ein ABAP Programm auf dem SAP System eingespielt. Dies ist aber zugleich auch ein „Showstopper“ in vielen Unternehmen, da Transporte in ein SAP System einen Change Management Prozess benötigen, häufig lange dauern, da diverse Genehmigungsschritte durchlaufen werden müssen.
Eine weitere Möglichkeit ist das manuelle Herunterladen einzelner Tabellen im SAP Dialog. Hierfür können z.B. die Transaktion „SE16(n)“ oder „SQVI“ verwendet werden. Dies ist aber insgesamt mit vielen Handgriffen verbunden und sehr umständlich.
Die dritte Möglichkeit wäre das Extrahieren von Datentabellen per Remote Function Call (RFC). Bei diesem Vorgehen wird lediglich ein User mit entsprechenden Nutzerrechten für das Aufrufen von Remote Function Call Bausteinen benötigt. Es braucht dabei kein ABAP Programm in das SAP System transportiert zu werden. RFC ist zwar verhältnismäßig alt und in einigen wenigen Fällen langsam, jedoch etabliert und in jedem SAP System verfügbar. Bei diesem Vorgehen besteht allerdings die Möglichkeit die RFC Anfragen clever zu optimieren und somit bequem Daten für eine Analyse aus dem SAP System zu beschaffen. Initial ist der Aufwand unter Umständen etwas Größer, als z.B. durch die Extraktion per SE16N, dafür kann es schnell und einfach wiederverwendet werden, um wiederholte Prüfungen effizient umzusetzen.
Financial Process Mining
Bevor mit den verschiedenen Datenanalysen, die hinter den Indikatoren stehen, begonnen wird, werden alle in einem Geschäftsjahr durchgeführten Prozesse rekonstruiert. Darunter sind auch alle Prozesse mit Einkaufsbezug enthalten. Dieser Vorgang wird durch den Financial Process Mining Algorithmus durchgeführt. Der Financial Process Mining Algorithmus findet alle Prozesse in Ihrem SAP System, indem zusammengehörige Belege im Rechnungswesen nacheinander abgeschritten werden, bis der Prozess zu Ende ist.
Belege sind dabei zusammengehörig, wenn ein Beleg Posten eines anderen Belegs ausgeglichen hat. So wird in SAP im Einkauf häufig der Wareneingang durch die Eingangsrechnung ausgeglichen und die Eingangsrechnung durch die dazugehörige Ausgangszahlung. Der Financial Process Mining Algorithmus springt in einem solchen Fall vom Beleg des Wareneingangs zur dazugehörigen Rechnung und dann zur dazugehörigen Zahlung. Diese drei Belege sind dann in einer sogenannten Sequenz. Alle gefundenen Sequenzen werden dann im Folgenden für die Analyse mit den Indikatoren benötigt. Für den Financial Process Mining Algorithmus sind somit die offenen Posten geführten Konten in SAP gewissermaßen der Ort, wo zusammengehörige Belege ihr „Rendezvous“ haben. Diese Art von Konten sind die „Drehscheiben“ einer prozessorientierten Sichtweise auf Ihr Rechnungswesen. Die ursprüngliche Funktionsweise des Financial Process Mining Algorithmus finden Sie in meinem wissenschaftlichen Aufsatz „Basic Principles of Financial Process Mining – A Journey through Financial Data in Accounting Information Systems“. Nachdem alle Belege des Rechnungswesens in den Sequenzen gefunden wurden, werden den Sequenzen auch noch Bestellungen und Bestellanforderungen und auch alle relevanten Änderungsdokumente hinzugefügt. Für die Grundlagen des Process Minings verweisen wir an dieser Stelle auf das wissenschaftliche Paper in englischer Sprache, das wir ihnen zum kostenlosen Download anbieten:
Rasterfahndung
Wurden alle Sequenzen durch den Financial Process Mining Algorithmus ermittelt, wird die sogenannte Rasterfahndung durchgeführt. Rasterfahndung bedeutet, dass für jeden Beleg in Ihrem Buchungskreis geprüft wird, ob ein Indikator an dem Beleg „anschlägt“. Ein Indikator kann also für einen Beleg relevant sein oder nicht. Es gibt somit für jeden Beleg und Indikator nur zwei Möglichkeiten. Ist ein Indikator für einen Beleg relevant, so wird dieser Indikator an den Beleg geheftet. Der Beleg wird mit dem Indikator „getagged“. Dadurch, dass bekannt ist, welcher Beleg zu welcher Sequenz gehört, kann mit der Rasterfahndung festgestellt werden, ob eine Sequenz an mehreren Indikatoren „leidet“. So entstehen aussagekräftige Kombinationen von zutreffenden Indikatoren innerhalb Ihrer SAP Prozesse. Folgende Abbildung 1 zeigt, wie eine Sequenz mit Indikatoren „getagged“ wurde:
Die Abbildung 1 zeigt die in der Sequenz enthaltenen Belege (Bestellung, Wareneingang, Rechnung und Zahlung) mit den Belegnummern 100, 208, 301 und 405. An die Bestellung 100 wurde der Indikator A mit der Feststellungsnummer 1001 „getagged“ und die Rechnung 301 wurde mit dem Indikator B mit der Feststellungsnummer 2001 „getagged“. Der Indikator A könnte hierbei sein: „In der Bestellung wurde keine Zahlungsbedingung hinterlegt“ und der Indikator B könnte sein: „Es wurde ein gesperrter Kreditor verwendet“.
Das Konzept der Indikatoren
Indikatoren korrespondieren stets mit einer revisionsrelevanten Prüfungsfrage. Technisch gesehen handelt es sich um Datenabfragen (Database Queries), die Belege aus dem Datenbestand suchen, die bestimmten vordefinierten Kriterien genügen.
Es handelt sich also im weitesten Sinn um eine einfache Datenanalyse.
Allerdings muss der Indikator so definiert sein, dass er stets und ausschließlich auf die Ermittlung einer Menge von einzelnen Belege abzielt, d.h. alle Belege im Datenbestand werden daraufhin untersucht, ob der Indikator für einen Beleg relevant ist oder nicht (der Indikator teilt alle Belege also in eine Art „Schwarz-Weiß-Welt“ ein).
Nachdem der Indikator alle Sequenzen abgelaufen ist, werden alle einschlägigen Belege mit dem Indikator markiert. Betroffene Belege haben dann einen „Makel“ im Hinblick auf diesen Indikator.
Um besser in den Indikatoren navigieren zu können, ist jeder Indikator verschiedenen Dimensionen zugeordnet. Jeder Indikator gehört zu einem bestimmten Prozess, zu einem bestimmten Prozessbereich und hat ein bestimmtes Prüfungsziel, z.B.:
- Dimension Prozess: Einkauf, Verkauf, Anlage- und Vorratsvermögen, Prozessübergreifend
- Dimension Prozessbereich: Stammdaten, Wareneingang, Rechnung, Zahlung, …
- Dimension Prüfungsziel: Ordnungsmäßigkeit, Zugriffssicherheit, Wirtschaftlichkeit, Prozessstandardisierung
Weiterhin ist für jeden Indikator ein Risiko dokumentiert, aus welchem hervorgeht, was „schiefgehen“ könnte oder inwiefern eine bestimmte Gefahr besteht.
Welche Bereiche wir mittels Datenanalyse effektiv abdecken und automatisiert prüfen wird in dem nächsten Blog Post beschrieben. Gegebenenfalls präsentieren wir dann auch ein Vorgehen zur Datenextraktion mit Excel, um die ein oder andere Prüfungsfrage auch manuell auswerten zu können.
