In der letzten Veranstaltung habe ich den WCHC Teilnehmer KNIME (www.knime.org) für ihre Analysen der Gesellschaften empfohlen. KNIME hat aus meiner Sicht vor allem zwei Vorteile. Einerseits können die Analysen in Form von visuell verständlichen Workflows angelegt werden und andererseits können diese Analysen dann reproduzierbar ausgeführt werden.

Damit das ganze aber nicht nur eine Empfehlung bleibt, möchte ich hier die Gelegenheit nutzen einen Beispielworkflow auf Basis meines angelegten Fraudfalls zu erläutern.

Wie war der Fraudfall gestrickt:

Basis für den Fraudfall war ein bestehender Lieferant, bei dem viele Bestellungen durchgeführt werden. Zunächst wurden etliche Bestellungen, Wareneingänge und Rechnungen im System erfasst. Ergänzend wurde der Fraudfall implementiert. Es wurde, während die Bestellungen weiter ausgeführt wurden, kurzfristig die Bankdaten des Lieferanten auf ein fiktives Konto umgestellt. Nach ein paar Minuten drehte ich die Bankdaten wieder auf ihren Ursprungswert zurück. Während und im Nachgang dieser Änderungen, wurden weitere Bestellungen, Wareneingänge und Rechnungen für diesen Lieferanten gebucht. Die Hoffnung als Fraudster war, dass eine Bestellung bei dem Lieferanten mit meinen fiktiv eingepflegten Bankdaten auch tatsächlich bestellt, geliefert und bezahlt wird. Die Bezahlung würde dann auf mein Konto laufen. In der Realität würde ein solcher Fall zwar schnell auffallen, da Lieferanten bei fehlender Bezahlung Mahnungen an meine Firma schicken würden und hierdurch andere Abteilungen auf den Misstand aufmerksam werden würden.

Analysetätigkeit des studentischen Teams in der Challenge:

Während der Analysephase kamen die Studenten relativ schnell auf den Fraudfall, auch wenn Sie nicht genau wussten wie der Fraudfall entstanden ist. Die Studierenden sind auf den Beleg aufmerksam geworden, da ich alle Buchungen mit einer Umsatzsteuer gebucht habe, mit Ausnahme meines Fraudfalls.
Wie man sieht zeigt sich, dass man noch so akribisch unterwegs sein kann. Ein Flüchtigkeitsfehler langt schon aus und schon ist man im Fokus der Untersuchung.

Wie könnte man die Analyse mittels KNIME vornehmen:

Es stellt sich nun die Frage, wie man die Analyse dieses Fraudfalls in KNIME vornehmen kann, um diese Art von dolosen Handlungen generisch finden zu können. Zunächst muss überlegt werden, wie die Analyse am besten manuell vorgenommen werden kann, um dann diese Schritte in KNIME zu automatisieren.

Folgende Schritte dienen der Analyse:

  1. Auswertung der Änderungsbelege der Lieferantenstammdaten speziell auf Bankdaten.
  2. Identifikation der Zeitintervalle pro Änderung, in der Änderung- und Rückänderung stattgefunden hat.
  3. Selektion der durchgeführten Zahlungen, die in diesem Intervall entstanden sind.

Das Ergebnis der Analyse sollte nun alle Ausgangszahlungen liefern, die zwischen Änderungsintervallen an Bankstammdaten an die jeweiligen Lieferanten gezahlt wurden.

Wichtig dabei ist das Verständnis, dass die Ergebnismenge nicht zwingend Fraudfälle sein müssen, sondern eher Indizien für Unregelmäßigkeiten liefern und diesen zunächst nachgegangen werden muss.

Wie bildet man nun die Analyseschritte in KNIME ab?

Nachstehende Abbildung zeigt den fertigen Workflow zur Identifikation der Belege, die in einem Änderungsintervall gezahlt wurden.

Knime WF ChangeDoc

Der Workflow wurde in 6 Bereiche und einen Loop-Knoten aufgeteilt.

  • Datenbeschaffung
  • Ermittlung der Zahlungsbelege an Lieferanten
  • Ermittlung der Ausgleichsbelege, um die Zahlung einem Ausgleichsbeleg zuzuordnen
  • Ermittlung der Änderungsbelege an Lieferantenstammdaten mit Bankinformationen
  • Ermittlung der Zeitdifferenz zwischen Hin- und Rückänderung von Stammdaten, um diese dann als Input für den Loop zu verwenden
  • Loop-Knoten zur Identifikation der Zahlungsbelege die in einem Änderungsintervall erzeugt wurden
  • Reporting zur Aufbereitung der Analyseergebnisse

Datenbeschaffung:

In dieser Sektion werden alle Daten, die für die Analyse notwendig sind, aus den SAP System extrahiert. Hierbei wird auf einen selbstentwickelten SAPConnector-Node für KNIME zurückgegriffen, der die Daten per RFC aus dem SAP herauslädt und KNIME zur Verfügung stellt. (Genaueres zu dem Node werde ich noch in einem extra Beitrag erläutern).

Für die einzelnen Informationen sind folgende Tabellen aus SAP notwendig:

  • Zahlungsbelege: Tabelle BKPF und BSAK
  • Änderungsbelege: Tabelle CDHDR und CDPOS

Um die Datenmenge einzuschränken, wurden bei den Zahlungsbelegen die Extraktion auf den zu untersuchenden Buchungskreis und auf das Geschäftsjahr 2014 eingeschränkt.

Die Änderungstabellen müssen zwingend eingeschränkt werden, da diese sehr groß sind und somit eine Extraktion nur unter Schwierigkeiten möglich ist. Da wir nur bestimmte Änderungsbelege für diese Analyse brauchen, wird die Extraktion der Änderungsbelege wie folgt eingeschränkt: Objektklasse des Änderungsbelege muss „KRED“ sein, der Änderungsbeleg muss ein Updatebelge und kein Einfügebeleg sein (Kennzeichen „U“), die Änderung muss für die Tabelle „LFBK“ vorgenommen werden und es müssen Änderungen am Feld „Key“ und „BKONT“ vorgenommen worden sein. Die beiden letzten Kriterien wurden in eigenen Extraktionsknoten abgebildet und danach wieder zu einem Datensatz gejoined, da die Änderung in dem Key Feld die Kontoinformation, während die Änderung am BKONT Feld das ursprüngliche Bankkonto enthält. Durch diese Vorgehensweise können wir in einem Datensatz sowohl die geänderte Bankinformation als auch die ursprüngliche Information darstellen.

Tranformation der extrahierten Daten

Damit die extrahierten Daten weiterbearbeitet werden können, müssen diese zunächst in eine adäquate Form gebracht werden. Hierzu wird über zwei gesonderte Abläufe die Zahlungsbelegpositionen mit den Zahlungsbelegköpfen gejoint sowie der Zeitstempel in der Ergebnismenge von einem String in ein Date/Time-Fromat konvertiert. Parallel hierzu wird ebenfalls die Änderungsbelegköpfe mit den gejointen Änderungsbelegpositionen zusammengeführt. Auch hier finden einzelnen Typumwandlungen sowie eine Extraktion der eingefügten und gelöschten Bankinformationen statt.

Transformation der Änderungsbelege um die Zeitintervalle von Hin- und Rückänderungen zu identifizieren

Um Hin- und Rückänderungen zu identifizieren, joine ich die Ergebnistabelle der Änderungsbelege mit sich selbst. Join-Kriterien sind einmal „Eingefügte Bankdaten = Gelöschte Bankdaten“ und „Gelöschte Bankdaten = Eingefügte Bankdaten“. Hierdurch ermittle ich die Stammdatenänderungen, die verändert und wieder in ihren Ursprungszustand gebracht wurden. Nachteilig bei dieser Lösung ist vor allem der Aspekt, dass hierdurch die Treffer immer doppelt in der Ergebnismenge vorhanden sind. Diese werden durch weitere Nodes eliminiert.

Loop um Belege zu identifizieren, die in den ermittelten Intervallen vorhanden sind.

Da auf diese Weise mehr als ein Treffer an Änderungen auftauchen können, müssen nun für jedes identifizierte Intervall mögliche Zahlungen identifiziert werden. Hierzu greife ich auf ein Loop-Element von KNIME zurück. Die Änderungsintervalle werden als Floating Variables, während die Ausgangszahlungsbelege als Datenelement in den Loop übergeben werden.

Knime_WF1_1

Mittels des Java Snippet Nodes werden nun alle Datenelemente herausgefiltert, die im Zeitintervall einer Änderung lagen. Dies wird solange wiederholt, bis keine weiteren Änderungen mehr vorliegen.

Reporting

Die bis dahin ermittelten Belege werden dann an die Reporting-Nodes übergeben, die folgende drei wesentliche Informationen beinhalten:

Bildschirmfoto 2014-11-18 um 14.45.08

KNIME bietet unterschiedlichste Outputformate für das Berichtswesen. So können Webseiten, PDF, Worddokumente, aber auch Exceldateien als Ergebnismenge ausgegeben werden.

In meinem fiktiven Beispiel findet man über diese Vorgehensweise nun tatsächlich den Beleg mit der Belegnummer 5100000031, der eine Fraudrechnung darstellt. Man sieht ebenfalls, wer die Lieferantenstammdaten geändert hat und wann diese Änderung vorgenommen wurde. Zur Übersichtlichkeit habe ich noch die Ausgleichsbelege (Zahlungsbelege) mit dargestellt, um zu sehen, wie viele Ausgangszahlungen mit diesem Lieferanten vorgenommen wurden.

KNIME bietet eine einfach und transparente Möglichkeit Analysen aufzubauen.