Dateneintöpfe vermeiden

Gerade in der kalten Jahreszeit kommen oft schmackhafte Eintöpfe mit verschiedensten Zutaten auf den Tisch. Bei Datenanalysen ist es aber manchmal besser, nicht zu viele Zutaten in einen einzigen Analysetopf zu werfen, bzw. genau zu wissen, welche Zutaten sinnvoll sind, um trotzdem noch eine klare Struktur erkennen zu können – oder gar zu dekonstruieren, um in der Kochmetapher zu bleiben.

Wir hatten uns in einem vergangenen Blogpost mit dem Thema „unvollständige Bestellungen“ beschäftigt. Manchmal stellt sich die Frage, welche Bestellbelege aus SAP® man überhaupt in Datenanalysen mit einbeziehen soll, und welche man bei Analysen ausschließt. Einige Anregungen dazu vermittelt dieser Artikel.

Die Datenbasis, von der wir hier ausgehen, findet sich im Schwerpunkt die Tabellen EKKO (Bestellbelegköpfe) und EKPO (Bestellbelegpositionen); Screenshots verwenden die Desktopvariante der Analysesoftware ACL™Analytics.

 

 

Bestellungen aus SAP® - Die Basics

 

Kurz zu den Basics: Bestellungen kann man mit Transaktion ME23n anzeigen lassen. Sie teilen sich auf in Kopfinformationen und Positionsinformationen. Wenn man nichts mit Datenmodellen am Hut hat (passenderweise symbolisiert übrigens in SAP® häufig das Hut-Symbol Kopfinformationen) kann man sich das an Hand einer papierbezogenen Bestellung vorstellen: Der Briefkopf enthält Informationen, die für die gesamte Bestellung gelten, z.B. an welchen Lieferant sie geschickt wird, zu wann sie datiert ist, aber auch welche Zahlungsbedingungen zutreffen und in welcher Währung die Bestellung gehalten ist. Positionsinformationen betreffen die einzelnen Artikel und können sich von Position zu Position unterscheiden, etwa Anzahl (10 Laptops vs. 8 Dockingstations) und den unterschiedlichen Preis je Position. Zu Bestellungen finden sich Kopfinformationen in Tabelle EKKO, Positionsinformationen in Tabelle EKPO. Gemeinsames Kriterium, um die Tabellen zu verbinden, ist die Einkaufsbelegnummer EBELN.

 

 

So können Sie Ihre Bestelldaten trennscharf analysieren

Liegen Ihnen diese Bestelltransaktionen nun in Ihrer Analysesoftware vor, so können für Sie beim Eingrenzen der Datenbasis folgende Aspekte von Bedeutung sein:

1. Es ist nicht (nur) das drin, was draufsteht
2. Gelöschtes sollte nicht ignoriert werden
3. Man kann bestimmte interne Vorgänge ausschließen

 

Betrachten wir diese drei Punkte nun im Detail

 

1. Es ist nicht das drin, was draufsteht

Ein wichtiger Punkt ist, dass die genannten SAP® Tabellen EKKO und EKPO zwar mit den Begriffen „Einkaufsbelegkopf“ und „Einkaufsbelegposition“ bezeichnet sind, sie aber auch andere Typen von Einkaufsbelegen enthalten. So finden sich auch Anfragen (Requests for Proposal), Kontrakte (Outline Agreements) oder Lieferpläne (Scheduling Agreements) in diesen Tabellen. Der Grund ist, dass sie aus technischer Sicht die gleichen Datenstrukturen aufweisen wie die Bestellungen an sich – obwohl es sich eigentlich um eine Art „Metadaten“ handelt, die zum Teil erst durch Bestellabrufe tatsächlich genutzt werden. Das reine Bestehen eines Kontraktes im SAP® System über 1.000.000,00 € etwa sagt noch nichts über dessen tatsächliche Nutzung aus. Man kann dies aus Sicht des Datenanalysten relativ einfach differenzieren, indem man das Feld BSTYP in der Tabelle EKKO betrachtet. Im Folgenden wurde über das Feld mit ACL™ Analytics verdichtet (bzw. über das Feld BSTYP, welches nur das Kürzel beinhaltet, und dessen Beschriftung, damit es besser lesbar ist).

Es zeigt gut die genannten Ausprägungen. Von 16.085 Bestellbelegen insgesamt sind nur 15.882 tatsächliche Bestellbelege, der Rest teilt sich auf 73 Kontrakte, 122 Lieferpläne und 8 Anfragen auf.

Um Fehler bei Datenanalysen zu vermeiden (es wäre z.B. sehr irreführend, Werte für Verträge und Bestellungen und Anfragen in einer einzigen Summe undifferenziert darzustellen) macht es Sinn, Analysen nach Belegtyp zu differenzieren, oder nicht relevante von vorneherein auszuschließen.

 

2. Gelöschtes sollte nicht ignoriert werden

Es gibt viele Beispiele, in denen bei Datenanalysen gelöschte Datensätze bzw. als gelöscht gekennzeichnete Datensätze ignoriert werden können. Ein echtes Löschen findet ja in den seltensten Fällen statt auf Grund der Aufbewahrungs- bzw. Aufzeichnungspflicht. Stattdessen weisen Daten (sowohl Stammdaten als auch Transaktionen) ein Attribut auf, welches häufig als „Löschvormerkung“ bezeichnet ist. Ist dies z.B. mit einem „X“ gefüllt, so wurde der Beleg oder das Stammdatum als gelöscht markiert. So wird der Begriff „gelöscht“ auch in diesem Artikel verwendet – wenn ich schreibe „gelöscht“ dann handelt es sich um Datensätze, die ein entsprechendes Löschkennzeichen aufweisen, sich aber durchaus noch in den Tabellen finden lassen. Dies trifft man weniger bei Finanztransaktionen, da hier eine Gegenbuchung bzw. ein Storno erfolgt, aber häufiger in den Vorprozessen wie Einkauf oder Vertrieb bzw. den zugehörigen Stammdaten. Bei Letzteren ist manchmal durchaus sinnvoll, als gelöscht markierte Datensätze auszuschließen: Analysiert man beispielsweise Duplikate bei Lieferantenstammsätzen, um Doppelzahlungen zu vermeiden oder die Datenqualität zu erhöhen, sollten gelöschte Stammsätze von der Analyse ausgeschlossen werden, da diese per se in Buchungen nicht genutzt werden können. Der Fachbereich würde nicht positiv reagieren, wenn die Liste mit potentiellen Lieferantenduplikaten auch bereits zur Löschung vorgemerkte Stammsätze enthält.

Anders verhält es sich dagegen bei Einkaufsbelegen. Hier findet sich eine mögliche Löschvormerkung sowohl auf Kopfebene (in der Tabelle EKKO) als auch auf Positionsebene (Tabelle EKPO). Die Logik ist i.d.R., dass einzelne Positionen als gelöscht markiert werden können, aber der ganze Beleg nur dann zur Löschung gekennzeichnet werden kann, wenn alle darin befindlichen Positionen „gelöscht“ sind.

Im Bereich Einkauf ist allerdings zu beachten, dass gelöschte Bestellungen oder Bestellzeilen nicht zwingend von Analysen ausgeschlossen werden sollen. Der Grund ist, dass häufig aus Sicht des Bestellwesens Bestellungen oder Bestellzeilen als gelöscht markiert werden, wenn sie als erledigt anzusehen sind. So soll verhindert werden, dass sie weiterhin verwendet werden, obwohl der Vorgang inhaltlich erledigt ist (auch wenn sich beispielsweise noch Restmengen in der Bestellung befinden, die noch nicht abgerufen wurden).

Das bedeutet aber wiederum, dass es durchaus sein kann, dass zu der Bestellposition ganz normal Waren- und Rechnungseingänge erfolgt sind, die entsprechend von Interesse bei Analysen sind. Würde man die als gelöscht markierten Bestellungen oder Bestellpositionen ausschließen, würden einem diese Vorgänge komplett entgehen und ein falsches Bild von Mengen- und Wertegerüst des Bestellwesens entstehen.

3. Man kann bestimmte interne Vorgänge ausschließen

Ein letzter Punkt auf den ich hinweisen will, sind die sogenannten Umlagerungsbestellungen. Sie haben i.d.R. Belegart UB für Umlagerungsbestellung (Stock Transport Order) und dienen internen Bestandsbewegungen bzw. Umlagerungen von Material zwischen Anlagen.