Modellierung und Analyse von Fraud in elektronischen ...

Universität Mannheim
Lehrstuhl für Praktische Informatik 1
in Kooperation mit der
PricewaterhouseCoopers AG
Modellierung und Analyse von Fraud in
elektronischen Geschäftsprozessen
Diplomarbeit
im Fachgebiet Computerforensik
Prof. Dr. Felix C. Freiling
Lehrstuhl für Praktische Informatik 1
Fakultät für Mathematik und Informatik
Universität Mannheim
vorgelegt von
Alexander Pster
Betreuer (Lehrstuhl PI 1):
Betreuer (PricewaterhouseCoopers):
Erstgutachter:
Zweitgutachter:
Dipl.-Inf. Christian Gorecki
Dipl.-Betriebsw. (FH) Florian Buschbacher
Prof. Dr. Felix C. Freiling
Prof. Dr. Armin Heinzl

Erklärung der Urheberschaft
Hiermit versichere ich, dass ich die Arbeit selbständig verfasst und keine anderen als die
angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Die
Arbeit wurde bisher in gleicher oder ähnlicher Form in keiner anderen Prüfungsbehörde
vorgelegt und auch noch nicht veröentlicht.
Ludwigshafen am Rhein, den 30. April 2009
Unterschrift Alexander Pster
III

Zusammenfassung
Wie mehrere Studien von anerkannten Wirtschaftsprüfungsgesellschaften zeigen, stellt
wirtschaftskriminelles Verhalten eine immer gröÿere Bedrohung für Unternehmenswerte
und die Existenz von Unternehmen dar. Dieser Gefährdung kann einerseits durch
präventive Maÿnahmen wie dem Einsatz und der Kontrolle von Corporate Compliance
und andererseits durch reaktive Maÿnahmen ähnlich einer strukturierten Datenanalyse
begegnet werden.
In dieser Diplomarbeit wird zum einen eine theoretisch fundierte Erweiterung der Ereignisgesteuerten
Prozessketten (EPK) um Elemente der Datenmodellierung erstellt.
Zum anderen wird auf dieser soliden Basis ein Vorgehensmodell entwickelt, das das
Aunden von prozesskonträren Datenbeständen vereinfacht und gleichzeitig die gezielte
Suche nach wirtschaftskriminellen Vorfällen unterstützt. Beide Einsatzgebiete
werden durch die Erstellung einer abstrakten Datenmenge anhand des als algebraische
erweiterte Ereignisgesteuerte Prozesskette (aEPK) modellierten Geschäftsprozesses
ermöglicht.
V

Abstract
Dierent studies of approved auditing companies show that business fraud is a growing
threat for the shareholder value and the existence of the whole company. One possibility
to avert this threat is, rst, by preventive measures like the implementation and
control of Corporate Compliance and, second, by reactive measures like a structured
data analysis.
In this diploma thesis, I will design an extension of the event-driven process chain with
data-modelling elements on a rm scientic foundation. Furthermore, I will develop
a procedure model on an equally rm basis. This model simplies the detection of
a noncompliant dataset and supports simultaneously the targeted search for fraud
scenarios. Both elds of application are supported by the creation of an abstract data
volume out of a business process model modellized by an algebraic event-driven process
chain.
VII

Inhaltsverzeichnis
Abbildungsverzeichnis
Listenverzeichnis
Denitionsverzeichnis
Abkürzungsverzeichnis
XIII
XV
XVII
XIX
1. Einführung 1
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Ziel, Vorgehen und Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Einführendes Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Kapitelübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Theoretische Betrachtung 9
2.1. Petri-Netze (PN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1. Algebraische Petri-Netze (aPN) . . . . . . . . . . . . . . . . . . 11
2.2. Ereignisgesteuerte Prozessketten (EPK) . . . . . . . . . . . . . . . . . . 14
2.2.1. Einführung in die EPK . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2. Formale Denition der EPK . . . . . . . . . . . . . . . . . . . . 16
2.2.3. Erweiterte Ereignisgesteuerte Prozesskette (eEPK) . . . . . . . 19
2.3. Algebraische Ereignisgesteuerte Prozessketten (aEPK) . . . . . . . . . 19
2.3.1. Formale Denition der aEPK . . . . . . . . . . . . . . . . . . . 20
2.3.2. Abbildung der aEPK auf aPN . . . . . . . . . . . . . . . . . . . 22
3. Wirtschaftskriminalität 29
3.1. Was ist Wirtschaftskriminalität? . . . . . . . . . . . . . . . . . . . . . . 29
3.2. Ausprägungen von Wirtschaftskriminalität . . . . . . . . . . . . . . . . 30
3.3. Gegenmaÿnahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1. Organisatorische/Präventive Maÿnahmen . . . . . . . . . . . . . 31
3.3.2. Konkrete präventive Maÿnahmen . . . . . . . . . . . . . . . . . 32
3.4. AntiFraudSolutions von PwC . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.1. Erkennbarkeit von Fraud . . . . . . . . . . . . . . . . . . . . . . 36
IX

Inhaltsverzeichnis
3.5. Indikatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.1. Indikatorndung . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.2. Indikatordenition . . . . . . . . . . . . . . . . . . . . . . . . . 38
4. Datenerhebung und -analyse 41
4.1. Das Unternehmen und sein Umfeld . . . . . . . . . . . . . . . . . . . . 41
4.2. Datenzusammenhänge . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3. Datenerhebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4. Datenanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.1. Indikatorbasierte Analyse . . . . . . . . . . . . . . . . . . . . . 43
4.4.2. Prozessbasierte Analyse . . . . . . . . . . . . . . . . . . . . . . 44
5. Identikation von Fraud in Geschäftsprozessen 47
5.1. Modell für Fraud in Geschäftsprozessen . . . . . . . . . . . . . . . . . . 47
5.1.1. Datenmenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2. Detailliertes Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.1. Syntax zur Denition der Informationsobjekte . . . . . . . . . . 51
5.2.2. Vorgehen bei Verknüpfungen . . . . . . . . . . . . . . . . . . . . 51
5.2.3. Vorgehen bei Schleifen . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.4. Erstellung der Datenmenge . . . . . . . . . . . . . . . . . . . . 56
5.2.5. Auswertung der Datenbestände . . . . . . . . . . . . . . . . . . 56
5.3. Manipulationsarten innerhalb eines Geschäftsprozesses . . . . . . . . . 57
5.4. Untersuchung und Entwicklung von Fraud-Szenarien . . . . . . . . . . 61
5.4.1. Auswertung von Unterschieden . . . . . . . . . . . . . . . . . . 62
5.5. Verarbeitung von Untersuchungsresten . . . . . . . . . . . . . . . . . . 64
5.6. Ausführliches Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.6.1. Fraud-Szenarien am Beispiel . . . . . . . . . . . . . . . . . . . . 69
6. Weitere Datenmodellierungssprachen 75
6.1. Business Process Modelling Notation (BPMN) . . . . . . . . . . . . . . 75
6.2. Unied Modeling Language (UML)-Aktivitätsdiagramme . . . . . . . . 76
6.3. Message Sequence Charts . . . . . . . . . . . . . . . . . . . . . . . . . 77
7. Zusammenfassung 79
7.1. Zusammenfassung und Ergebnis . . . . . . . . . . . . . . . . . . . . . . 79
7.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.2.1. Automatische Modellerstellung . . . . . . . . . . . . . . . . . . 81
7.2.2. Untersuchung von Schleifen . . . . . . . . . . . . . . . . . . . . 82
7.2.3. Erkennung weiterer Eingabeformate . . . . . . . . . . . . . . . . 82
Literaturverzeichnis
XXI
A. Erweiterung des Beispiels XXVII
X

Inhaltsverzeichnis
B. Skriptsammlung XXXI
B.1. Grundlegendes zu den Werkzeugen . . . . . . . . . . . . . . . . . . . . XXXI
B.1.1. Grakwerkzeug Dia . . . . . . . . . . . . . . . . . . . . . . . . . XXXI
B.1.2. Analyseumgebung Picalo . . . . . . . . . . . . . . . . . . . . . . XXXII
B.2. Übersicht der einzelnen Skripte . . . . . . . . . . . . . . . . . . . . . . XXXIII
B.2.1. Traverse-aEPK.py . . . . . . . . . . . . . . . . . . . . . . . . . . XXXIII
B.2.2. Funktion.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXXV
B.2.3. Objekte.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXXVI
B.2.4. Parsen.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXXVI
B.2.5. Untersuchungsscript.py . . . . . . . . . . . . . . . . . . . . . . . XXXVI
XI

Abbildungsverzeichnis
1.1. Einführungsbeispiel - Prozessdiagramm . . . . . . . . . . . . . . . . . . 4
1.2. Einführungsbeispiel - Manipulation der Überweisung . . . . . . . . . . 5
1.3. Einführungsbeispiel - Manipulation der Barauszahlung . . . . . . . . . 6
2.1. Elemente eines Kanal-/Instanz-Netzes . . . . . . . . . . . . . . . . . . . 10
2.2. Beispiel für ein Kanal-/Instanz-Netz . . . . . . . . . . . . . . . . . . . . 10
2.3. Elemente in EPKs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4. Zusätzliche Elemente einer eEPK . . . . . . . . . . . . . . . . . . . . . 19
2.5. Erweiterte Ereignisgesteuerte Prozesskette . . . . . . . . . . . . . . . . 20
2.6. Algebraische erweiterte Ereignisgesteuerte Prozesskette . . . . . . . . . 22
2.7. Umwandlung von zwei aufeinander folgenden Konnektoren [vdA99] . . 23
2.8. Umwandlung der Konnektoren [vdA99] . . . . . . . . . . . . . . . . . . 25
2.9. Mögliche ODER-Verknüpfungen . . . . . . . . . . . . . . . . . . . . . . 26
2.10. Ersetzung des ∨-Konnektors mittels ∧- und XOR-Konnektoren . . . . 27
5.1. Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2. Syntaxdenition der Informationsobjekte . . . . . . . . . . . . . . . . . 51
5.3. Schleifen in aEPKs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4. Umgebungsdatenmanipulation durch Schleifen . . . . . . . . . . . . . . 56
5.5. Manipulationsart: zusätzlicher Prozessschritt . . . . . . . . . . . . . . . 58
5.6. Manipulationsart: Prozessschritte überspringen . . . . . . . . . . . . . . 59
5.7. Manipulationsart: vorzeitiges Prozessende . . . . . . . . . . . . . . . . 60
5.8. Manipulationsart: geänderte Informationsobjekte . . . . . . . . . . . . 60
5.9. Kombination der Manipulationsarten . . . . . . . . . . . . . . . . . . . 61
5.10. Geschäftsprozessdiagramm ohne Informationsobjekte . . . . . . . . . . 65
5.11. Geschäftsprozessdiagramm mit Informationsobjekten . . . . . . . . . . 66
5.12. Prozessmanipulation mit Informationsobjekten - Überweisung . . . . . 70
5.13. Prozessmanipulation mit Informationsobjekten - Barauszahlung . . . . 72
A.1. Geschäftsprozessdiagramm mit Informationsobjekten . . . . . . . . . . XXVII
B.1. Diagrammwerkzeug Dia
B.2. Analysewerkzeug Picalo
. . . . . . . . . . . . . . . . . . . . . . . . . . XXXIII
. . . . . . . . . . . . . . . . . . . . . . . . . . XXXIV
XIII

Listenverzeichnis
5.1. Alle zu einem Pfad durch das aEPK gehörenden Elemente . . . . . . . 67
5.2. Abstrakte Datenmenge des manipulierten Barzahlungsprozesses . . . . 67
5.3. SQL-Anweisung zur Selektion von Datensätzen . . . . . . . . . . . . . . 68
5.4. SQL-Anweisung für die Markierung von Datensätzen . . . . . . . . . . 69
5.5. Abstrakte Datenmenge des manipulierten Überweisungsprozesses . . . . 70
5.6. Abstrakte Datenmenge des manipulierten Barzahlungsprozesses . . . . 71
A.1. Pfade durch das Diagramm . . . . . . . . . . . . . . . . . . . . . . . . XXVIII
A.2. Informationsobjekte des Beispielszenarios . . . . . . . . . . . . . . . . . XXVIII
A.3. Generierte SQL Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . XXX
B.1. XML-basiertes Dia Dateiformat . . . . . . . . . . . . . . . . . . . . . . XXXI
B.2. Parameter und Aufruf von Traverse-aEPK.py . . . . . . . . . . . . . . XXXIV
B.3. Dateiformat von Informationsobjekte.csv . . . . . . . . . . . . . . . . . XXXV
B.4. Formaterläuterung zur Datei Informationsobjekte.csv . . . . . . . . . . XXXV
XV

Denitionsverzeichnis
1. Petri-Netz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Variablenmenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Terme einer Algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Auswertung von Termen mit Belegung . . . . . . . . . . . . . . . . . . . . 12
6. Multimenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Algebraische Petri-Netze . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Ereignisgesteuerte Prozesskette . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Direkter Pfad, elementarer Pfad . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Zusätzliche Mengen für EPKs . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Einschränkungen bei EPKs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. Erweiterte Ereignisgesteuerte Prozesskette . . . . . . . . . . . . . . . . . . 19
13. Algebraische Ereignisgesteuerte Prozesskette . . . . . . . . . . . . . . . . . 21
14. Einschränkung aEPK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
15. Menge der Dierenzen zwischen D und ˜D . . . . . . . . . . . . . . . . . . 63
XVII

Abkürzungsverzeichnis
ACL
aEPK
∧
B-/E-Netz
DBMS
ERP
IKS
ITU
IWi
K-/I-Netz
MSC
ODBC
OMG
∨
P-/T-Netz
PwC
SOX
SQL
S-/T-Netz
UML
Audit Command Language
algebraische erweiterte Ereignisgesteuerte Prozesskette
und - Konjunktion
Bedingungs-/Ereignis-Netz
Datenbankmanagementsystem
Enterprise Resource Planning
Internes Kontrollsystem
International Telecommunicaion Union
Institut für Wirtschaftsinformatik an der Universität
des Saarlandes
Kanal-/Instanz-Netz
Message Sequence Chart
Open Database Connectivity
Object Management Group
inklusives oder - Adjunktion
Prädikat-/Transitions-Netz
PricewaterhouseCoopers
Sarbanes Oxley Acts
Structured Query Language
Stellen-/Transitions-Netz
Unied Modeling Language
XIX

Abkürzungsverzeichnis
XML
XOR
Extensible Markup Language
exclusives oder - Disjunktion
XX

Kapitel 1.
Einführung
Begonnen wird diese Arbeit mit einer Motivation, die ein Gefühl für die Brisanz des
Themas vermitteln soll. Darüber hinaus erlauben die Abschnitte Ziel und Vorgehen
und Einführendes Beispiel einen sanften Einstieg in den behandelten Themenkomplex:
Wirtschaftskriminalität in Geschäftsprozessen.
1.1. Motivation
In unserer heutigen Zeit wird das mittelständische, familiengeführte Unternehmen mit
einer kleinen Zahl handverlesener Mitarbeiter, die dem Unternehmen sehr eng verbunden
sind, mehr und mehr von Konzernen verdrängt. Bei diesen ständig wachsenden,
weltweit agierenden Gesellschaften, wächst mit der Anonymität des Groÿunternehmens
auch die Gefahr, selbst Opfer einer wirtschaftskriminellen Straftat zu werden.
So ist es bei kleinen Unternehmen selten möglich wirtschaftskriminelle Handlungen,
auch dolose Handlungen genannt, unentdeckt durchzuführen, da häug eine direkte
Kontrolle durch den Firmeninhaber möglich ist. In Groÿkonzernen hingegen muss
über mehrere Hierarchiestufen hinweg eine ständige Kontrolle des anonym gewordenen
Mitarbeiters vorgenommen werden. Diese Anonymität ist nicht allein für die steigende
Zahl der wirtschaftskriminellen Handlungen verantwortlich. Auf der anderen Seite
tragen dazu auch eine gesteigerte Sensibilisierung für diese Thematik, ausgeweitete
Kontrollen und die Null-Toleranzstrategie (jedes Vergehen wird nach der Entdeckung
konsequent verfolgt) vieler Konzerne bei. Nach einer repräsentativen Umfrage [NSB07]
der PricewaterhouseCoopers Wirtschaftsprüfungsgesellschaft aus dem Jahr 2007 unter
weltweit mehr als 5000 Unternehmen hatten 49% dieser Unternehmen im Untersuchungszeitraum
von zwei Jahren mindestens einen Fall von Wirtschaftskriminalität.
Allerdings gaben nur 44% der kleinen Unternehmen (bis 200 Mitarbeiter) an, Opfer
einer dolosen Handlung geworden zu sein. Im Vergleich dazu waren gut 61% der
Groÿkonzerne betroen. Aufgrund der Brisanz dieses Themas wird vermutet, dass es
zusätzlich zu dieser hohen Zahl noch eine entsprechend hohe Dunkelzier gibt. Die
1

Kapitel 1. Einführung
daraus resultierende sehr hohe Fallzahl lässt die Studie zu dem Ergebnis kommen,
dass als Untergrenze des entstandenen Schadens für den deutschen Wirtschaftsraum
sechs Milliarden Euro angenommen werden können. Aufgrund der hohen Dunkelzier
und nicht erfasster Verluste von Privatpersonen im Zuge der wirtschaftskriminellen
Straftaten kann davon ausgegangen werden, dass der tatsächliche Schaden noch um
einiges über dem errechneten Wert liegt.
Diese sehr hohe Zahl führt vor Augen, dass es dringend erforderlich ist, ein wirksames
Mittel im Kampf gegen Betrug/Unterschlagung, Bestechung, Bilanzfälschung
und dergleichen zu haben. Wirtschaftskriminelle Handlungen werden entsprechend
der Studie [NSB07] von PricewaterhouseCoopers (PwC) vermehrt in Groÿunternehmen
ausgeübt. Diese pegen gleichzeitig eine gut dokumentierte Prozesslandschaft und
unterstützen sehr viele Geschäftsprozessabläufe durch Rechner, wodurch hier die idealen
Voraussetzungen für eine prozessorientierte Fraud-Erkennung (Kapitel 5) gegeben
sind.
1.2. Ziel, Vorgehen und Ergebnis
Das Ziel dieser Arbeit besteht darin, eine prozessbasierte Analysemethodik zu entwickeln,
mit Hilfe derer auf Basis vorhandener elektronischer Daten ein Geschäftsprozess
auf die Anfälligkeit für dolose Handlungen hin untersucht werden kann. Um dieses
Ziel zu erreichen, wurde im ersten Schritt eine Prozessmodellierung entwickelt, welche
neben der reinen Prozess-Sicht auch eine Daten-Sicht beinhaltet und zusätzlich die
Weiterverarbeitung und Veränderung von Daten darstellen kann.
Diese Voraussetzung wurde durch die Weiterentwicklung der Ereignisgesteuerten Prozesskette
(EPK), die ein intuitiv verständliches und weitverbreitetes Konzept darstellen,
geschaen. In der Petri-Netz-Theorie, diese wird in Kapitel 2.1 näher ausgeführt,
gibt es bereits seit 1991 ein höheres Petri-Netz, welches die geforderte Datenmodellierung
aufweist. Da Petri-Netze sich aber aufgrund ihres eher technischen Charakters
und ihrer beschränkten Verbreitung für kaufmännische Geschäftsprozessmodellierung
nicht für die Nutzung empfehlen, baut diese Diplomarbeit Ereignisgesteuerte Prozessketten
entsprechend diesem Vorbild zu einer algebraischen erweiterten Ereignisgesteuerten
Prozesskette (aEPK) aus.
Anschlieÿend wurde ein Vorgehensmodell entwickelt und in Software umgesetzt, durch
das eine Auswertung der elektronisch vorhandenen Daten auf ihre Prozesstreue möglich
ist. Hierzu werden die modellierten Prozessdiagramme eingelesen und zu einer abstrakten
Datenmenge weiterverarbeitet. Diese Datenmenge stellt nur noch die durch
den Prozessablauf entstehenden elektronischen Daten und ihre modellierten Ausprägungen
dar. Im weiteren Verlauf des Vorgehensmodells werden die Ergebnisse der
2

1.3. Einführendes Beispiel
abstrakten Datenmenge mit den existierenden elektronischen Daten verglichen und
Abweichungen markiert. Diese Markierung hilft anschlieÿend prozesskonforme Datensätze
von nicht prozesskonformen zu unterscheiden. Ist diese Unterscheidung getroen,
kann für die prozesskonträren Datensätze begonnen werden, Muster wirtschaftskrimineller
Szenarien zu erarbeiten. Dies führt dazu, einen tieferen Einblick in die Vorgehensweise
von Wirtschaftsstraftätern zu erhalten. Dieses Wissen kann danach für die
gezielte Prävention oder Aufdeckung dieser Delikte eingesetzt werden.
Neben dieser Vorgehensweise, die eine Analyse von unbekannten Prozessen erlaubt, ist
es mittels der erarbeiteten Modellierung von aEPKs auch möglich, bereits bekannte
wirtschaftskriminelle Szenarien in Geschäftsprozessen zu modellieren und durch diese
Darstellung die Vorgehensweisen anschaulicher zu machen. Dies führt dazu, dass
dieser manipulierte Prozess einerseits mit dem korrekten Prozess auf der Ebene der
abstrakten Datenmenge verglichen werden kann und somit eine Entscheidung möglich
ist, ob das modellierte Wirtschaftsdelikt mit Hilfe der vorhandenen elektronischen
Daten entdeckt werden kann. Andererseits kann dieser manipulierte Prozess ebenfalls
in das Vorgehensmodell eingespeist werden, wodurch am Ende alle mit diesem Prozess
konformen Datensätze und somit die verdächtigen Datensätze markiert werden
würden.
Sowohl die theoretische und praktische Umsetzung der aEPK als auch das in zweierlei
Hinsicht benutzbare Vorgehensmodell und die dazugehörende Modellierung von
dolosen Handlungen sind direkte Ergebnisse dieser Diplomarbeit. Zusätzlich wurde
eine Skriptsammlung in der Programmiersprache Python [Fou09] erstellt, welche die
automatisierte Durchführung des Vorgehensmodells erlaubt. Die Details der Skriptsammlung
können im Anhang B nachgeschlagen werden.
1.3. Einführendes Beispiel
Um einen ersten Eindruck der praktischen Problemstellung zu bekommen, wird hier
ein realitätsnahes Szenario entworfen. Anhand dieses Szenarios wird in Kapitel 5.6
ein ausführliches Vorgehensbeispiel mit Ausschnitten der dazu gehörenden Zwischenergebnissen
gezeigt. Im Anhang A werden die vollständigen Zwischenergebnisse bereitgestellt.
Ausgangspunkt für dieses Szenario ist eine Einrichtung, welche Karten für kulturelle
Veranstaltungen vertreibt, wobei es unerheblich ist, ob diese Veranstaltungen selbst
durchgeführt werden oder die Durchführung an Dritte abgegeben wird. Wichtig ist,
dass die Möglichkeit besteht, bereits gekaufte und bezahlte Karten vor oder mit triftigem
Grund auch nach dem Veranstaltungstermin zurückzugeben und stornieren zu
lassen.
3

Kapitel 1. Einführung
Abbildung 1.1.: Einführungsbeispiel - Prozessdiagramm
Dies führt dazu, dass der Kunde entscheiden kann, ob er den Kartenpreis zurückerstattet
bekommen möchte, oder den Betrag alternativ kulturellen Projekten spendet. Die
Rückerstattung ist entweder bar oder als Überweisung auf das Bankkonto des Kunden
möglich. Ideengeber für dieses Szenario war die Prozesslandschaft des Praxispartners
dieser Diplomarbeit, dem Festspielhaus Baden-Baden.
Die dargestellte Grak in Abbildung 1.1 wurde nach Grundsätzen der aEPKs modelliert
und zeigt den vereinfachten Stornoprozess des zuvor angeführten Szenarios.
Nun gibt es neben dem in der Abbildung 1.1 dargestellten korrekten Prozess mögliche
Prozessmanipulationen. Im Anschluss werden zwei denkbare Manipulationen beispielhaft
vorgestellt, welche im Prozess des beschriebenen Szenario vorgenommen werden
könnten. Bei beiden Manipulationen wird als gemeinsame Grundannahme davon ausgegangen,
dass der Kunde den Kartenpreis nicht erstattet bekommen möchte, sondern
bereit ist, diesen für kulturelle Zwecke zu spenden, der Mitarbeiter diesen Betrag aber
für private Zwecke unterschlägt.
4

1.3. Einführendes Beispiel
Abbildung 1.2.: Einführungsbeispiel - Manipulation der Überweisung
Bei der ersten Manipulation wird vor der Erstellung der Auszahlung die Bankverbindung
des Empfängers auf eine vom Täter gewählte geändert. Anschlieÿend wird die
Auszahlung getätigt und die Bankverbindung zur Verschleierung der Tat wieder auf
die ursprüngliche zurückgesetzt. Bei diesem Vorgehen hinterlässt der Täter, wie man
an der Abbildung 1.2 anhand der grau markierten Elemente sehen kann, einige digitale
Datenspuren. Diese lassen sich anschlieÿend mit einer strukturierten Datenanalyse
nden und können die Tat somit beweisen. Im zweiten Manipulationsszenario wird die
Auszahlung ebenfalls vorgenommen, allerdings ndet keine Überweisung sondern eine
Barauszahlung statt. In diesem Fall stellt man anhand des geänderten Prozessmodells
in Abbildung 1.3 fest, dass keine digitalen Datenspuren erzeugt werden, wodurch offenkundig
wird, dass diese Art, den Betrug zu realisieren im Nachhinein kaum noch
aufgedeckt geschweige denn bewiesen werden kann.
Deshalb müsste an dieser Stelle durch zusätzliche organisatorische Kontrollen dafür
gesorgt werden, dass diese Art der Manipulation ausgeschlossen ist. Wie diese Art
der Kontrollen aufgebaut werden kann ist nicht Gegenstand dieser Arbeit, wird aber
ansatzweise in Kapitel 3.3.1 gezeigt.
5

Kapitel 1. Einführung
Abbildung 1.3.: Einführungsbeispiel - Manipulation der Barauszahlung
1.4. Kapitelübersicht
Diese Arbeit beginnt im Kapitel 2 die theoretischen Grundlagen für eine algebraische
Modellierung der Geschäftsprozesse zu legen. Das Kapitel teilt sich auf in eine kurze
Einführung zu Petri-Netzen im Allgemeinen und algebraischen Petri-Netze im Speziellen.
Zusätzlich gibt es eine Einführung in die klassische Modellierungssprache der EPK,
welche anschlieÿend zu aEPKs erweitert wird. Der darauf folgende Abschnitt deniert
eine Transformationsmethode, mit welcher aEPKs in algebraische Petri-Netze (aPN)
übertragen werden können, was hauptsächlich der semantischen Überprüfbarkeit der
Modellierung dient.
Das Kapitel 3 widmet sich einer Einführung in die allgemeine Thematik der Wirtschaftskriminalität
zusammen mit einem Überblick über mögliche Gegenmaÿnahmen
und dem aktuellen Forschungsstand auf diesem Gebiet. Zusätzlich wird das von PwC an-
6

1.5. Danksagung
gebotene fraudbekämpfende Dienstleistungspaket AntiFraudSolutions vorgestellt und
ein kurzer Einblick in die dem Fraud Scan ® zugrundeliegende Technik der Indikatornutzung
gewährt.
Kapitel 4 enthält eine Beschreibung des praktischen Analyseumfeldes zusammen mit
den für den Praxisteil denierten Indikatoren und einer kurzen Einführung in die
Skriptsammlung, welche im Zuge der Entwicklung des Vorgehensmodells entstand.
Im darauolgenden Kapitel 5 wird das erarbeitete Vorgehensmodell vorgestellt und einerseits
die Analyse der erstellten Diagramme zusammen mit möglichen Sonderfällen
und deren Behandlung beschrieben. Andererseits wird auf mögliche Modellierungen
von Prozessmanipulationen und deren Auswirkungen auf die gewählten Geschäftsprozesse
eingegangen. Abschlieÿend zu diesem Kapitel ndet sich in Abschnitt 5.6 die
Anwendung des Vorgehensmodells auf das Einführungsbeispiel aus dem vorhergehenden
Abschnitt.
Kapitel 6 beinhaltet eine Auistung und Bewertung von drei Modellierungsalternativen
zu aEPKs.
Abschlieÿend enthält Kapitel 7 eine Zusammenfassung inklusive einer kritischen Betrachtung
des Vorgehensmodells und eine Auistung möglicher Ansätze zur vertiefenden
Forschung.
1.5. Danksagung
In diesem kleinen Teil der Arbeit möchte ich ein persönliches Anliegen zum Ausdruck
bringen und mich bei all jenen lieben Menschen bedanken, die mir bei der Erstellung
dieser Arbeit auf die ein oder andere der vielfältig möglichen Arten geholfen haben. Ein
paar von ihnen möchte ich auÿerdem namentlich erwähnen und ihnen so für jeweils spezielle
Hilfestellungen danken. An erster Stelle darf ich mich deshalb bei Herrn Professor
Dr. Freiling dafür bedanken, dass er mir diese praxisnahe Diplomarbeit in Kooperation
mit PricewaterhouseCoopers ermöglicht hat. Ebenso dankbar bin ich Herrn Florian
Buschbacher und Herrn Matthias Rott, die beide auf Seite von PwC meine Betreuung
übernommen und mich im praktischen Bereich dieser Arbeit unterstützt haben. Auch
Christian Gorecki, der von Seiten des Lehrstuhls für Praktische Informatik 1 meine
Diplomarbeitsbetreuung übernahm möchte ich für sein Engagement und so manche
bereichernde Diskussionsrunde und Gedankenaustausch danken. Bedanken möchte ich
mich auch bei Frau Maier, die das Festspielhaus Baden-Baden vertreten hat und von
dort aus einige Steine aus dem Weg räumen konnte. Auch den Vertretern von CTS
Eventim Solutions, die die Daten für meine Analysen zur Verfügung stellten, möchte
ich ganz herzlich für ihr Verständnis und ihre Geduld in Bezug auf meine Anfragen
danken. Zusätzlich gebührt mein Dank Laura Itzel und Thomas Schulze, die beide
7

Kapitel 1. Einführung
mit ihren Fachkenntnissen hinsichtlich des wirtschaftsinformatiklastigen Themenkomplexes
meine Diplomarbeit Korrektur gelesen haben und interessante und hilfreiche
Anmerkungen machen konnten. Meiner Kommilitonin Sabine Born danke ich, für das
Korrekturlesen hinsichtlich sprachlicher und grammatikalischer Belange. Last but not
least danke ich meinen Eltern, die mir das Studium überhaupt erst ermöglicht und
mich moralisch in den letzten Tagen unterstützt haben und meiner Freundin Carina,
die mich während des Schreibens dieser Arbeit ertragen, die schlimmsten Rechtschreibfehler
ausgemerzt und mir bei so mancher Formulierung Alternativen vorgeschlagen
hat.
8

Kapitel 2.
Theoretische Betrachtung
In diesem Kapitel werden die theoretischen Grundlagen zur exakten Modellierung von
Prozessen und den begleitenden Daten erläutert. Hierzu werden als erstes Petri-Netze
(PN) im Allgemeinen und algebraische Petri-Netze (aPN) im Besonderen vorgestellt.
Zusätzlich werden Ereignisgesteuerte Prozessketten (EPKs) eingeführt und in ihrer
bisherigen Form betrachtet. Anschlieÿend wird die für algebraische Petri-Netze entwickelte
Theorie auf EPKs übertragen und damit algebraische erweiterte Ereignisgesteuerte
Prozessketten (aEPKs) neu geschaen. Der Abschluss des Kapitels beschäftigt
sich mit der Überführung einer aEPK in ein aPN. Die in diesem Kapitel vorgestellten
Denitionen entstammen den angegebenen Quellen. Hierbei ist allerdings zu beachten,
dass teilweise zum besseren Verständnis Variablenbezeichnungen und Notationen
geändert oder im weiteren Verlauf dieser Arbeit benötigte Aussagen hinzugefügt wurden.
2.1. Petri-Netze (PN)
Petri-Netze wurden in den 1960er Jahren durch den späteren Namensgeber Carl Adam
Petri entwickelt [BR06]. Dessen Netztheorieforschung wird heute noch von vielen Wissenschaftlern
weitergeführt. Einer dieser Wissenschaftler ist Wolfgang Reisig, welcher
unter anderem die algebraischen Petri-Netze [Rei91] deniert hat. Petri-Netze selbst
sind eine sehr schlanke und je nach Ausprägung einfach zu verstehende Möglichkeit
zur Prozessmodellierung. Hierbei spielt es keine Rolle, ob es sich um maschinen- oder
personenunterstützte Prozesse handelt. Die einfachste Ausprägung der Petri-Netze ist
das Kanal-/Instanz-Netz (K-/I-Netz). Dieses Netz besteht ausschlieÿlich aus Stellen
(Abbildung 2.1(a)) und Transitionen (Abbildung 2.1(b)), welche durch Kanten miteinander
verbunden sind. Ein Beispielprozess ist in Abbildung 2.2 zu nden.
Zusätzlich zur in Abbildung 2.2 gezeigten graphischen Darstellung eines beispielhaften
Petri-Netzes existiert auch eine abstrakte Denition, welche sich für theoretische Betrachtungen
sehr gut eignet. In Denition 1 wird gezeigt, dass sich Petri-Netze mit drei
9

Kapitel 2. Theoretische Betrachtung
(a) Stelle
(b) Transition
Abbildung 2.1.: Elemente eines Kanal-/Instanz-Netzes
Abbildung 2.2.: Beispiel für ein Kanal-/Instanz-Netz
Mengen darstellen lassen. So existiert eine Menge S, welche alle Stellen eines Netzes
enthält, eine weitere Menge T enthält alle Transitionen eines Netzes und die dritte
Menge V ′ enthält alle vorhandenen Verbindungskanten zwischen den Elementen aus
S und T.
Denition 1 (Petri-Netz):
Ein Petri-Netz [WWV + 97, vdA99](im Speziellen auch K-/I-Netz) P N = (S, T, V ′ )
besteht aus zwei disjunkten Mengen S (Stellen) und T (Transitionen), welche durch
Kanten (V ′ ) miteinander verbunden sind. Für die Menge der Kanten (V ′ ) gilt V ′ ⊆
V = (S × T ) ∪ (T × S) .
Neben diesen K-/I-Netzen existieren weiterentwickelte Netze, welche um Marken, also
Elemente, die sich durch das Netz bewegen können, erweitert wurden. Dieses Netz
heiÿt, solange sich nur eine Marke im Netz bendet, Bedingungs-/Ereignis-Netz (B-
/E-Netz). Sind zwei oder mehr Marken im Netz enthalten und existieren an den Kanten
Gewichte, welche angeben, wie viele Marken diese Kante auf einmal passieren
können, wird es als Stellen-/Transitions-Netz (S-/T-Netz) bezeichnet. Zusätzlich zu
diesen einfachen Petri-Netzen gibt es einige als höhere Petri-Netze bezeichnete Weiterentwicklungen.
Hierzu gehört das Prädikat-/Transitions-Netz (P-/T-Netz), auch
gefärbtes Netz genannt, das zeitbehaftete Netz, das hierarchische Netz oder das alge-
10

2.1. Petri-Netze (PN)
braische Netz. Diese höheren Petri-Netze sind alle durch zusätzlich denierte Elemente
oder Verhaltensweisen modizierte einfache Petri-Netze. So wird bei P-/T-Netzen den
Marken eine höhere Bedeutung beigemessen. Sie können nun zusätzliche Attribute,
beispielsweise eine Farbe oder einen Wert, annehmen. Auÿerdem werden die Schaltregeln
so angepasst, dass nun Bedingungen auf Grundlage dieser Werte abgefragt und
als Schaltbedingung überprüft werden können. Zeitbehaftete Petri-Netze besitzen die
Möglichkeit, das Schalten der Transitionen entsprechend einer zeitlichen Vorgabe zu
verzögern. Hierarchische Petri-Netze wurden für sehr groÿe und komplexe Netze entwickelt,
um diese mittels Aggregation übersichtlicher darzustellen. Die algebraischen
Petri-Netze, welche nun näher erläutert werden, sind mit den P-/T-Netzen (gefärbten
Netzen) verwandt [Bil88, Bil90].
2.1.1. Algebraische Petri-Netze (aPN)
Algebra und Terme
Um algebraische Petri-Netze zu verstehen, ist es notwendig, die verwendete Algebra
(Denition 2) und die weiteren Begriichkeiten näher zu betrachten und eindeutig zu
denieren. Neben der Algebra wird eine Variablenmenge X (Denition 3) deniert.
Denition 2 (Algebra):
Eine Algebra [WWV + 97] A = (U, Op) besteht aus zwei Mengen, einem Zeichenvorrat
U und einer Operationenmenge Op. Die Menge U enthält alle zur Algebra gehörenden
Zeichen. Die Menge Op besteht aus den für die Algebra gültigen Operationen op ∈ Op.
In diesem Zusammenhang ist eine Operation eine Funktion der Gestalt op : U 1 × U 2 ×
· · · × U n → U n+1 mit U i ⊆ U ∀i ∈ {1, 2, . . . , n, n + 1}. Falls n = 0, heiÿt op Konstante.
Denition 3 (Variablenmenge):
Eine Variablenmenge[WWV + 97] X = (Y, dom) besteht aus y ∈ Y , welche alle verwendbaren
Variablen beinhaltet, und einer Funktion dom. Diese Funktion dom : Y →
2 U ermöglicht eine Zuordnung von möglichen Zeichen U, welche eine Variable aus Y
annehmen kann. Das Ergebnis der Funktion dom(y) mit y ∈ Y bezeichnen wir kurz
mit U y .
Diese Menge U y wird als Sorte (Englisch: domain) bezeichnet und beschreibt ein
Element der Potenzmenge über dem Zeichenvorrat U der Algebra (A). Um zukünftig
exibler mit den verschiedenen Elementen einer Algebra (Variablen, Konstanten und
Operatoren) umgehen zu können, führen wir hier den Begri des Terms einer Algebra
11

Kapitel 2. Theoretische Betrachtung
ein. Diese Terme werden über die Algebra (A), die Variablenmenge (X ) und eine Sorte
(U ′ ) deniert.
Denition 4 (Terme einer Algebra):
Die Menge aller Terme über einer Algebra A und einer Variablenmenge X mit der
Sorte U ′ wird mit T (A, X , U ′ ) bezeichnet und induktiv wie folgt deniert:
1. Wenn y ∈ Y und U y ⊆ U ′ , dann gilt y ∈ T (A, X , U ′ ).
2. Wenn f ∈ Op mit f : U 1 × U 2 × · · · × U n → U n+1 und u i ∈ T (A, X , U i ) für
i = 1 . . . n und U n+1 ⊆ U ′ , dann gilt f ∈ T (A, X , U ′ ). [WWV + 97]
Ein Term kann sowohl aus Variablen y ∈ Y bestehen als auch zusätzlich ein Tupel
(f, u 1 , u 2 , . . . , u n ) enthalten, wodurch die Menge aller Terme T (A, X , U ′ ) sehr heterogen
aufgebaut ist. Allerdings erhält man auf diese Weise auch die Flexibilität, um
sowohl Elemente (Variablen) als auch Operatoren in den Term aufzunehmen und so
ebenfalls Wertveränderungen modellieren zu können.
Belegungen und Multimengen
Eine Auswertung der Terme wird erst möglich, wenn jeder Variablen ein Wert aus ihrer
jeweils zugehörenden Sorte zugeordnet wurde. Diese Zuordnung wird als Belegung β
bezeichnet. Eine Belegung ist eine Funktion β : X → U, die jeder Variablen y ∈ Y
einen Wert aus der zugehörigen Wertemenge U y zuweist, damit gilt β(y) ∈ U y . Um
einen Term T unter einer gegebenen Belegung β auszuwerten, wird eine Abbildung ¯β
induktiv über die Denition eines Terms deniert (Denition 5).
Denition 5 (Auswertung von Termen mit Belegung):
Die Abbildung ¯β : T (A, X , U) → U wertet einen Term T mit gegebener Belegung β
aus und ist induktiv wie folgt deniert:
1. Falls y ∈ Y , dann gilt ¯β(y) = β(y).
2. Falls (f, u 1 , u 2 , . . . , u k ) ∈ T (A, X , U), dann gilt
¯β((f, u 1 , u 2 , . . . , u k )) = f( ¯β(u 1 ), ¯β(u 1 ), . . . , ¯β(u k )), wobei f ∈ Op gilt.
Für ein t ∈ T (A, X , U ′ ) und eine Belegung β gilt ¯β(t) ∈ U ′ [WWV + 97].
Nach der Denition der Belegung wird als letzter Baustein, vor der formalen Denition
der algebraischen Petri-Netze, der Begri und die Denition einer Multimenge
benötigt.
12

2.1. Petri-Netze (PN)
Denition 6 (Multimenge):
Eine Multimenge [WWV + 97] m ist eine Abbildung m : H → N.
Eine Multimenge ist genau wie eine normale Menge eine Ansammlung von Elementen.
Allerdings kann eine Multimenge dasselbe Element mehrfach enthalten. Formal
deniert ist die Multimenge m eine Abbildung die allen Elementen einer Menge H die
Häugkeit ihres Vorkommens zuordnet. Zusätzlich gilt für die Abbildung, dass sie nur
an endlich vielen Stellen unterschiedlich von 0 sein darf. Somit könnte eine Multimenge
als ein endliches assoziatives Array verstanden werden. Auf diese Interpretation deutet
auch die Schreibweise von Multimengen hin, die einer besseren Unterscheidung von
anderen Abbildungen dienen soll. So werden die Häugkeiten eines Elements a einer
Multimenge m mittels h = m[a] bezeichnet. N H bezeichnet die Menge aller Multimengen
über einer Menge H. Diese Menge ist wiederum eine Art Potenzmenge über den
Abbildungen m einer Multimenge. Für die Denition der algebraischen Petri-Netze soll
diese Ausführung über Multimengen ausreichen. Dem interessierten Leser sei an dieser
Stelle der Artikel von Weber et al. [WWV + 97] zur vertiefenden Lektüre empfohlen.
Algebraische Petri-Netze
Im Folgenden werden, nach den Grundlagen der vergangenen Unterabschnitte, nun
die algebraischen Petri-Netze (aPN) formal deniert. Die verwendeten Denitionen
sind der Veröentlichung von Weber et al. [WWV + 97] entnommen, zusätzlich gibt es
noch weitere Veröentlichungen, welche sich mit den aPNs beschäftigen [Peu01, Rei91,
KR96, KV97].
Denition 7 (Algebraische Petri-Netze):
Ein algebraisches Petri-Netz [WWV + 97] aP N = (S, T, V ′ , A, X , d, w, g, M 0 ) wird de-
niert durch:
i. Eine Menge Stellen S.
ii. Eine Menge Transitionen T.
iii. Eine Menge Verbindungen V ′ ⊆ V = (S × T ) ∪ (T × S).
iv. Eine Algebra A = (U, Op).
v. Eine sortierte Variablenmenge X = (Y, dom).
vi. Eine Funktion d : S → 2 U , die jeder Stelle s ∈ S eine Sorte U s = d(s) zuordnet.
13

Kapitel 2. Theoretische Betrachtung
vii. Eine Funktion w : V ′ → T (A, X , U), sodass für v = (s, t) ∈ V ′ oder v = (t, s) ∈
V ′ gilt: w(v) ∈ T (A, X , N Us ).
viii. Eine Funktion g : T → T (A, X , B), die jeder Transition eine Aktivierungsbedingung
zuordnet.
ix. Eine Anfangsmarkierung M 0 : S → N U .
Das algebraische Petri-Netz erweitert die Denition eines einfachen Petri-Netzes (De-
nition 1) um sechs Elemente. So wird eine Algebra A mit in die Denition aufgenommen,
die den verfügbaren Werte- und Funktionsumfang des Petri-Netzes beschreibt.
Auÿerdem wird eine Variablenmenge X hinzugefügt, welche die verschiedenen Werte
in Variablen zusammenfasst. So repräsentieren die Variablen y ∈ Y eine Teilmenge
der Potenzmenge 2 U des Wertevorrats. Zusätzlich zu diesen beiden Mengen wird eine
Abbildung in die Denition eingefügt, welche jeder Stelle des Petri-Netzes ebenfalls ein
Element der Potenzmenge 2 U zuweist und somit festlegt, welche Werte in dieser Stelle
abgelegt werden können. Um beschreiben zu können, welche Verbindung v ∈ V ′ welche
Werte transportieren kann, wird die Abbildung w deniert, welche einem Element aus
V ′ einen Term T (A, X , U) zuweist. Dieser Term repräsentiert eine Menge Elemente
aus U ebenso wie Operationen op ∈ Op. Somit kann mit diesem Werkzeug ebenfalls
die Veränderung von Werten durch op während der Ausführung des Petri-Netzes modelliert
werden. Zusätzlich zu den beiden bisher vorgestellten Abbildungen wird die
Funktion g deniert, welche jeder Transition t ∈ T eine Aktivierungsbedingung zuweist.
Hierdurch kann während der Ausführung des Petri-Netzes eindeutig entschieden
werden, ob die Transition schalten kann oder wegen nicht erfüllter Vorbedingungen
blockiert ist. Zum Abschluss der Denition weist ein algebraisches Petri-Netz eine Anfangsmarkierung
auf, welche aus einer Abbildung einer Stelle s ∈ S auf die Menge aller
Multimengen über dem Zeichenvorrat U besteht und somit jeder Stelle s Startwerte
in Form einer Multimenge über U zuweist.
2.2. Ereignisgesteuerte Prozessketten (EPK)
Ereignisgesteuerte Prozessketten wurden 1992 von einer Arbeitsgruppe am Institut
für Wirtschaftsinformatik an der Universität des Saarlandes (IWi) unter Leitung von
Prof. Dr. August-Wilhelm Scheer entwickelt. Anhand der Veröentlichungen
[KKNS91, KNS92, HKS93] aus dieser Zeit kann man die Entwicklungsgeschichte der
Ereignisgesteuerten Prozessketten nachvollziehen. So wurden sie entwickelt, um die
in der Aris-Architektur [Sch97] bis dahin bestehenden Daten-, Funktions- und Organisationssichten
um eine Steuerungssicht zu ergänzen und damit die Architektur zu
komplettieren. Die Aris-Architektur ist eine von Scheer entwickelte Darstellungsweise
14

2.2. Ereignisgesteuerte Prozessketten (EPK)
des Unternehmens aus Sicht der Wirtschaftsinformatik. Ein weiterer positiver Eekt
der neu geschaenen intuitiv verständlichen und eindeutigen Modellierungsmethode
war die Ablösung der damals vorherrschenden, semantisch sehr heterogenen Daten-
ussdarstellungen. Auÿerdem ermöglichen EPKs eine Aussage über den zeitlichen und
logischen Ablauf eines Prozesses zu treen.
2.2.1. Einführung in die EPK
Ereignisgesteuerte Prozessketten (EPKs) basieren auf Petri-Netzen [SNV95]. Im Forschungsbericht
des IWi [HKS93] stellen die Autoren den Zusammenhang zwischen
Ereignisgesteuerten Prozessketten und Petri-Netzen dar. Hierzu wählen sie das B-/E-
Netz. Allerdings kann fast jedes weitere Petri-Netz für diesen Vergleich herangezogen
werden. So wird in dieser Diplomarbeit gezeigt, dass auch algebraische Petri-Netze
(aPN) mit EPKs verwandt sind und aEPKs in aPNs transformiert werden können.
Der Aufbau von EPKs ist einfach, denn es existieren nur drei Elementarten (Ereignisse,
Funktionen und Operatoren). Mit diesen Elementen können alle denkbaren Prozessabläufe
modelliert werden. Ereignisse (Abbildung 2.3(a)) sind die passiven Elemente dieser
Modellierungssprache. Sie sind meistens Ergebnisse der vorangegangenen Funktionen.
Nur zu Beginn gibt es ein Ereignis, welches als Initialereignis den Startpunkt des
Prozesses markiert. Die aktiven Elemente heiÿen Funktionen (Abbildung 2.3(b)). Diese
beschreiben Umwandlungsaktivitäten innerhalb eines Prozesses. Als dritte Elementklasse
existieren die Operatoren (Abbildung 2.3(c)), derer drei verschiedene verwendet
werden können (und - Konjunktion (∧), inklusives oder - Adjunktion (∨), exclusives
oder - Disjunktion (XOR))[HKS93].
(a) Ereigniselement (b) Funktionselement (c) Operatoren in EPKs
Abbildung 2.3.: Elemente in EPKs
Um ein Prozessmodell zu erhalten, müssen diese drei Elementarten miteinander kombiniert
werden. Hierbei sollten folgende wichtige Punkte beachtet werden. Grundsätzlich
beginnt und endet jedes Prozessmodell mit einem Ereignis. Auÿerdem werden Ereignisse
und Funktionen immer abwechselnd benutzt. Zwischen den Elementen werden
Verbindungen mit Richtungspfeilen eingezeichnet, um die Richtung des Prozessusses
15

Kapitel 2. Theoretische Betrachtung
zu verdeutlichen. Zwischen Ereignissen und Funktionen können beliebig viele Operatoren
eingefügt werden. Hierbei ist allerdings darauf zu achten, dass die Operatoren
korrekt verwendet werden. So darf es nicht vorkommen, dass ein Prozess mittels eines
∧-Operators aufgetrennt wird und die daraus entstehenden Teilprozesse später wieder
mittels eines XOR-Operators zusammengefügt werden. Diese Modellierungsweise
führt zu Inkonsistenzen und Fehlern im Prozessablauf [vdA99]. Des Weiteren muss
darauf geachtet werden, dass Ereignisse als passive Elemente keine Entscheidungen
treen können, wodurch die Verknüpfung von einem Ereignis mit mehreren Funktionen
mittels einer Adjunktion (∨) oder einer Disjunktion (XOR) nicht vorkommen
darf.
2.2.2. Formale Denition der EPK
Die im vorhergehenden Abschnitt beschriebene intuitive graphische Erstellung von
EPKs kann auch formalisiert werden. Dies hat van der Aalst bereits 1999 gezeigt
[vdA99].
Denition 8 (Ereignisgesteuerte Prozesskette):
Eine beliebige Ereignisgesteuerte Prozesskette (EPK) besteht aus einem Fünf-Tupel
EP K = (E, F, C, t, V ′ ) [vdA99]:
i. Eine Menge Ereignisse E.
ii. Eine Menge Funktionen F.
iii. Eine Menge Operatoren C.
iv. Einer Funktion t : C → {∨, ∧, XOR}, diese ordnet jedem Operator c ∈ C eine
Bedeutung zu.
v. Eine Menge V ′ ⊆ V , wobei V = (E × F ) ∪ (E × C) ∪ (F × E) ∪ (F × C) ∪ (C ×
C) ∪ (C × F ) ∪ (C × E).
Mit dieser Denition kann eine einfache EPK vollständig beschrieben werden. Die
Mengen der Funktionen, Ereignisse und Operatoren bilden die verschiedenen verwendbaren
Elemente ab. Mittels der Funktion t wird jedem Operator c ∈ C eine
Operatorenausprägung zugeordnet, damit deniert werden kann, welcher Operator die
anderen Elemente wie verbindet. Die Verbindungen selbst werden mittels der Menge
V ′ abgebildet. Die Menge V enthält hingegen alle zwischen den Elementen möglichen
Verbindungen.
Im vorhergehenden Abschnitt wurden die Einschränkungen, bezogen auf die Modellierung
von EPKs, kurz dargestellt. Um diese nun ebenfalls formal korrekt abzubilden,
16

2.2. Ereignisgesteuerte Prozessketten (EPK)
sind die nachfolgenden Denitionen notwendig:
Denition 9 (Direkter Pfad, elementarer Pfad):
Sei EP K = (E, F, C, t, V ′ ) eine Ereignisgesteuerte Prozesskette [vdA99].
Dann ist der direkte Pfad p vom Knoten n 1 zum Knoten n k eine Sequenz 〈n 1 , n 2 , · · · , n k 〉,
so dass gilt: 〈n i , n i+1 〉 ∈ V ′ für 1 ≤ i ≤ k − 1.
Zusätzlich ist p ein elementarer Pfad, wenn alle Knoten n i auf dem Pfad p paarweise
verschieden sind. Mit P wird ein elementarer Pfad zwischen dem Startereignis und
dem Endereignis der EPK beschrieben.
Mittels dieser Denition eines direkten/elementaren Pfades kann die Menge der Operatoren
weiter zerlegt werden.
Denition 10 (Zusätzliche Mengen für EPKs):
Es sei EP K = (E, F, C, t, V ′ ) eine Ereignisgesteuerte Prozesskette [vdA99]. Daraus
lassen sich nun die folgenden Elemente denieren:
i. N = E ∪ F ∪ C ist die Menge aller Knoten eines EPKs.
ii. C ∨ = {c ∈ C|t(c) = ∨}
iii. C ∧ = {c ∈ C|t(c) = ∧}
iv. C xor = {c ∈ C|t(c) = XOR}
v. Für n ∈ N gilt:
•n = {m|(m, n) ∈ V ′ }
n• = {m|(n, m) ∈ V ′ }
vi. C J = {c ∈ C| |•c| ≥ 2}
vii. C S = {c ∈ C| |c•| ≥ 2}
viii. C EF = {c ∈ C|∃p = 〈n 1 , n 2 , · · · , n k−1 , n k 〉, n 1 ∈ E, n k ∈ F, n 2 , · · · , n k−1 ∈ C
und c ∈ {n 2 , · · · , n k−1 }} ⊆ C
ix. C F E = {c ∈ C|∃p = 〈n 1 , n 2 , · · · , n k−1 , n k 〉, n 1 ∈ F, n k ∈ E, n 2 , · · · , n k−1 ∈ C
und c ∈ {n 2 , · · · , n k−1 }} ⊆ C
Die Menge aller Knoten wird deniert als N. Die Menge der Operatoren C wird aufgeteilt
in die disjunkten Mengen C ∨ , C ∧ und C XOR . Somit gilt C ∨ ∪ C ∧ ∪ C XOR = C.
Analog wird C durch C EF und C F E vollständig partitioniert. Dies gilt deshalb, da die
Menge C EF alle Operatoren enthält, die auf einem, nur aus Operatoren bestehenden
17

Kapitel 2. Theoretische Betrachtung
Pfad zwischen einem Ereignis und einer Funktion liegen. Die Menge C F E ist ebenfalls
diesem Muster entsprechend deniert, nur enthält sie alle Operatoren zwischen einer
Funktion und einem Ereignis. Zusätzlich gilt, dass ein Operator nur Elemente eines
Typs als Vorgänger und Elemente eines anderen Typs als Nachfolger haben darf. Ausgenommen
hiervon ist der Typ Operator, dieser darf sowohl als Vorgänger als auch
als Nachfolger existieren [HKS93]. Die Mengen C J und C S dienen dazu, Teilungs- und
Vereinigungsoperatoren zu denieren (join- und split-Operatoren).
Mit diesen Denitionen gerüstet, werden im Folgenden die Modellierungseinschränkungen
für EPKs deniert.
Denition 11 (Einschränkungen bei EPKs):
Eine Ereignisgesteuerte Prozesskette EP K = (E, F, C, t, V ′ ) muss folgende Bedingungen
erfüllen [vdA99]:
i. Die Mengen E, F, C sind paarweise verschieden. E ∩ F = ∅, F ∩ C = ∅ und
E ∩ C = ∅.
ii. ∀e ∈ E : |•e| ≤ 1 und |e•| ≤ 1
iii. ∀f ∈ F : |•f| = 1 und |f•| = 1
iv. ∀c ∈ C : |•c| ≥ 1 und |c•| ≥ 1
v. ∃!e ∈ E : |•e| = 0 (Startereignis)
vi. ∃!e ∈ E : |e•| = 0 (Endereignis)
vii. C J und C S partitionieren C, es gilt also C J ∩ C S = ∅ und C J ∪ C S = C.
viii. C EF und C F E partitionieren C, es gilt also C EF ∩ C F E = ∅ und C EF ∪ C F E = C.
ix. C s ∩ C EF ∩ C xor = ∅ und C s ∩ C EF ∩ C ∧ = ∅
Es ist nun sichergestellt, dass eine Ereignisgesteuerte Prozesskette je ein Start- und
ein Endereignis haben muss. Ebenso ist sichergestellt, dass einer Funktion jeweils nur
ein Element vorausgehen und nachfolgen kann. Dasselbe gilt für alle Ereignisse mit
Ausnahme der Start- und Endereignisse. Bei den Operatoren hingegen darf mehr als
ein Element vorausgehen beziehungsweise nachfolgen. Im vorherigen Abschnitt wurde
angesprochen, dass die Operatoren ∨ und XOR nicht direkt nach einem Ereignis stehen
dürfen. Dies verhindern die Restriktionen C s ∩C EF ∩C xor = ∅ und C s ∩C EF ∩C ∧ = ∅.
Damit ist die formale Denition von EPKs abgeschlossen.
18

2.3. Algebraische Ereignisgesteuerte Prozessketten (aEPK)
2.2.3. Erweiterte Ereignisgesteuerte Prozesskette (eEPK)
Zu den hier denierten Ereignisgesteuerten Prozessketten existiert eine Erweiterung.
Diese umfasst zusätzlich die aus der Aris-Architektur bekannten Daten- und Organisationselemente,
welche mit den Funktionselementen verbunden werden können
[HKS93, SNV97]. Damit können nun auch Informationsobjekte (Abbildung 2.4(a))
und Organisationseinheiten (Abbildung 2.4(b)) übersichtlich in das Prozessmodell eingebunden
werden.
(a) Informationsobjekt
(b) Organisationseinheit
Abbildung 2.4.: Zusätzliche Elemente einer eEPK
Ein vollständig modellierter Prozess wird in Abbildung 2.5 dargestellt. Damit diese
erweiterten Elemente ebenfalls formal korrekt abgebildet werden können, werden zwei
zusätzliche Mengen deniert: je eine für Informationsobjekte und eine für Organisationsobjekte.
Auÿerdem muss eine Funktion, welche die Zuordnung zwischen Funktionselementen
und Informations- und Organisationsobjekten zulässt, deniert werden.
Denition 12 (Erweiterte Ereignisgesteuerte Prozesskette):
Eine erweiterte Ereignisgesteuerte Prozesskette (eEPK) eEP K = (F, E, C, k, V ′ , I, O, l)
wird deniert durch:
i. Eine Ereignisgesteuerte Prozesskette EP K = (F, E, C, t, V ′ ).
ii. Eine Menge der Informationsobjekte I.
iii. Eine Menge der Organisationsobjekte O.
iv. Eine Funktion l : F → I ∪ O.
2.3. Algebraische Ereignisgesteuerte Prozessketten
(aEPK)
Nachdem nun Petri-Netze im Allgemeinen und algebraische Petri-Netze im Besonderen
und die eher für Beschreibungen geeigneten und auf Petri-Netzen basierenden
19

Kapitel 2. Theoretische Betrachtung
Abbildung 2.5.: Erweiterte Ereignisgesteuerte Prozesskette
(erweiterten) Ereignisgesteuerten Prozessketten bekannt sind, wird sich der kommende
Abschnitt mit der Weiterentwicklung der eEPKs befassen. Diese eEPKs umfassen
noch keinerlei Möglichkeiten, die Weitergabe von Datenobjekten zu beschreiben, weshalb
im Folgenden gezeigt wird, wie (erweiterte) Ereignisgesteuerte Prozessketten um
eine Algebra, ähnlich der algebraischer Petri-Netze, erweitert werden können. Diese
Erweiterung wird im weiteren Verlauf für die Analyse und exakte Modellierung von
Prozessen von Bedeutung sein.
2.3.1. Formale Denition der aEPK
Die nachfolgend vorgestellte exakte Denition einer algebraischen erweiterten Ereignisgesteuerten
Prozesskette (aEPK) soll den beschreibenden und intuitiv verständlichen
Charakter von eEPKs um die Modellierung von Daten erweitern. Somit wird es
möglich, einen Prozess sowohl allgemein verständlich zu zeichnen als auch in Textform
zu denieren. Der Beispielprozess wurde um die Algebra erweitert und ist in
Abbildung 2.6 zu sehen.
20

2.3. Algebraische Ereignisgesteuerte Prozessketten (aEPK)
Denition 13 (Algebraische Ereignisgesteuerte Prozesskette):
Eine algebraische erweiterte Ereignisgesteuerte Prozesskette (aEPK)
aEP K = (F, E, C, k, V ′ , I, O, l, A, X , d e , d c , w) wird deniert durch:
i. Eine erweiterte Ereignisgesteuerte Prozesskette eEP K = (F, E, C, t, V ′ , I, O, l).
ii. Eine Algebra A = (U, Op).
iii. Eine sortierte Variablenmenge X = (Y, dom).
iv. Eine Funktion d e : E → 2 U .
v. Eine Funktion d c : C → 2 U .
vi. Eine Funktion w : V ′ → T (A, X , U).
ˆ Wenn v ∈ {(e, f), (f, e), (c, e), (e, c)}, dann w(v) ∈ T (A, X , U e ).
ˆ Wenn v ∈ {(c, f), (f, c)}, dann w(v) ∈ T (A, X , U c ).
ˆ Wenn v ∈ {(c 1 , c 2 )}, dann w(v) ∈ T (A, X , U c1 ).
Eine aEPK besteht aus einer eEPK, welche um eine Algebra A ergänzt wird. Diese
Algebra ist analog zu der algebraischer Petri-Netze (aPN) deniert. Auch die sortierte
Variablenmenge X ist äquivalent zu diesen. Ein elementarer Unterschied zu den aPNs
besteht darin, dass bei einer aEPK sowohl die passiven Elemente als auch die Konnektoren
Daten bevorraten können. Bei algebraischen Petri-Netzen kommt diese Aufgabe
nur den Stellen zu. Ebenso ist die Funktion w insoweit anders, als dass nur Funktionen
Veränderungen an den Daten vornehmen können, Konnektoren leiten diese Daten
lediglich weiter. Aus diesem Grund muss die folgende Einschränkung zusätzlich zu der
oben beschriebenen Denition gelten:
Denition 14 (Einschränkung aEPK):
Es sei eEP K = (F, E, C, k, V ′ , I, O, l, A, X , d e , d c , w) eine algebraische erweiterte Ereignisgesteuerte
Prozesskette und v ∈ {(e, c), (c, e), (c, c), (c, f), (e, f)} mit e ∈ E, f ∈
F und c ∈ C, dann muss ∀op ∈ Op: op /∈ w(v) gelten.
Diese Einschränkung muss gemacht werden, da nur innerhalb von Funktionen Variablenbelegungen
geändert und so Werte verarbeitet werden können. Deshalb gilt für alle
Verbindungen, die keine Funktion als Ursprungspunkt haben (v ∈ {(e, c), (c, e), (c, c),
(c, f), (e, f)} mit e ∈ E, f ∈ F und c ∈ C), dass die zugeordneten Terme w(v) keine
Operationen op ∈ Op enthalten dürfen.
21

Kapitel 2. Theoretische Betrachtung
Abbildung 2.6.: Algebraische erweiterte Ereignisgesteuerte Prozesskette
Als weiterer groÿer Unterschied zu den aPNs wurden bei den aEPKs auf die Ausführungseigenschaften
und somit die Semantikprüfung verzichtet. Um dennoch die modellierten
Prozesse ausführen und auf Deadlocks und ähnliches untersuchen zu können,
wird im nächsten Abschnitt eine Methode zur Abbildung einer aEPK auf ein algebraisches
Petri-Netz (aPN) deniert.
2.3.2. Abbildung der aEPK auf aPN
In diesem Abschnitt wird nun eine Möglichkeit aufgezeigt, die denierten aEPKs in
aPNs zu übertragen. Diese Transformation kann dazu genutzt werden, um die Vorteile
hinsichtlich der semantischen Korrektheitsprüfung und der Simulierbarkeit von algebraischen
Petri-Netzen einsetzen zu können. Die einfache Transformation von EPKs
in Petri-Netze hat van der Aalst [vdA99] bereits sehr ausführlich beschrieben. Diese
Transformation wird als Grundlage genutzt und um die algebraischen Teile erweitert.
Neben van der Aalst gibt es noch weitere Forschergruppen [LSW97, CS94], die
sich schon früh mit der Umwandlung von EPKs in Petri-Netze befasst haben. Unter
anderem ist dabei auch eine Diplomarbeit entstanden, welche die automatisierte
22

2.3. Algebraische Ereignisgesteuerte Prozessketten (aEPK)
Transformation unter bestimmten Voraussetzungen beschreibt [Brö96]. Van der Aalst
[vdA99] sieht eine Transformation in zwei Schritten vor. Zur Vereinfachung werden
im Folgenden nur Konnektoren der Gestalt ∧ und XOR genutzt. Der Konnektor ∨
nimmt eine Sonderstellung ein und wird im nächsten Abschnitt näher betrachtet.
Schritt 1
Entsprechend dieser Einschränkung werden im ersten Schritt alle Vorkommen von zwei
oder mehr aufeinander folgenden Konnektoren der Art ∧ oder XOR durch das Einfügen
von Dummy-Funktionen und -Ereignissen voneinander getrennt. Dieses Vorgehen
wird von der Abbildung 2.7 illustriert.
Abbildung 2.7.: Umwandlung von zwei aufeinander folgenden Konnektoren [vdA99]
Formal werden alle Vorkommen von v = (c 1 , c 2 ) mit c 1 , c 2 ∈ C und •c ∈ F durch
v 1 = (c 1 , e neu ), v 2 = (e neu , f neu ), v 3 = (f neu , c 2 ) innerhalb der Menge V ′ ersetzt. Den
Mengen E und F werden die Elemente f neu und e neu hinzugefügt. Falls •c ∈ E gilt,
wird v = (c 1 , c 2 ) durch v 1 = (c 1 , f neu ), v 2 = (f neu , e neu ), v 3 = (e neu , c 2 ) ersetzt und
ebenfalls die Elemente f neu und e neu den Mengen F beziehungsweise E hinzugefügt.
23

Kapitel 2. Theoretische Betrachtung
Schritt 2
Der zweite Schritt der Transformation sieht vor, alle Funktionen auf Transitionen und
alle Ereignisse auf Stellen abzubilden. Auÿerdem werden die Konnektoren entsprechend
der in Abbildung 2.8 denierten Übergangsvorschriften in Übergänge innerhalb
von Petri-Netzen überführt. Diese Übergangsvorschriften hat bereits van der Aalst
[vdA99] 1999 veröentlicht und formalisiert. Sie sollen an dieser Stelle zum grundlegenden
Verständnis des zweiten Transformationsschrittes beitragen.
Formal werden bei dieser Transformation die Elemente aus F in Elemente von T umgewandelt,
wobei die Zuordnung der Terme erhalten bleibt. Ebenso werden die Elemente
aus E in Elemente aus S umgewandelt. Auch hier bleibt die Zuordnung der Sorten
erhalten. Da während dieser Umwandlung alle Konnektoren verloren gehen und durch
eine Kombination aus Transitionen und Stellen ersetzt werden, erhalten hier die Stellen
die vorher den Konnektoren zugeordnete Sorte. Die Transitionen erhalten Terme,
welche die einfache Weitergabe der Daten von vorhergehenden Stellen in nachfolgende
Stellen beschreiben. Die in Abbildung 2.8 gezeigte graphische Transformationsvorschrift
ndet sich im Artikel von van der Aalst [vdA99] zusätzlich in formal korrekter
Form.
Durch diese beiden Umwandlungsschritte ist ein neues algebraisches Petri-Netz entstanden,
welches nun Aussagen nach der Petri-Netz-Theorie über Lebendigkeit, Semantiktreue,
et cetera erlaubt. Um diese Aussagen erhalten zu können, müssen allerdings
noch, wie in Denition 7 aufgezählt, eine Aktivierungsbedingung und eine
Anfangsmarkierung für das neu entstandene aPN erstellt werden.
Behandlung des Konnektors ∨
Der Konnektor ∨ nimmt in der gesamten Theorie über Ereignisgesteuerte Prozessketten
eine Sonderstellung ein, denn er kann als Kombination aus den Konnektoren ∧
und XOR betrachtet werden [LSW97], wodurch die Bedeutung nicht exakt bestimmbar
ist. Für diese Sonderrolle existiert innerhalb der Petri-Netz-Theorie kein Pendant,
was dazu führt, dass vor der Transformation von aEPKs in aPNs, der ∨-Operator
ersetzt werden muss. Dieses Problem ist bekannt und wurde bereits von van der Aalst
[vdA99] und Langer et al. [LSW97] formuliert und grundsätzlich diskutiert. Zunächst
müssen die möglichen Verknüpfungssituationen eines ∨-Operators deniert werden.
Derer existieren vier, wovon allerdings nur drei verwendet werden können. Die Situation
II (Abbildung 2.9(b)), in welcher der ∨-Operator nach einem Ereignis in zwei
Funktionen aufsplittet, kann in EPKs nicht verwendet werden, da ein Ereignis nicht
über den Fortgang des Prozesses entscheiden kann [HKS93]. Somit bleiben die Situationen
I, III und IV, welche betrachtet werden müssen.
24

2.3. Algebraische Ereignisgesteuerte Prozessketten (aEPK)
Abbildung 2.8.: Umwandlung der Konnektoren [vdA99]
25

Kapitel 2. Theoretische Betrachtung
(a) ODER-Teilung an einer Funktion (I) (b) ODER-Teilung an einem Ereignis (II)
(c) ODER-Zusammenführung in eine
Funktion (III)
(d) ODER-Zusammenführung in ein Ereignis
(IV)
Abbildung 2.9.: Mögliche ODER-Verknüpfungen
Zusätzlich zu den möglichen Verknüpfungen muss innerhalb von EPKs davon ausgegangen
werden können, dass keine oensichtlichen Deadlocks enthalten sind. Dies
wäre zum Beispiel der Fall, wenn eine ∨-Teilung durch eine ∧-Vereinigung wieder zusammengeführt
wird. Denn die ∨-Teilung lässt neben der ∧-Teilung auch eine XOR-
Teilung zu, wodurch bei der Vereinigung ein Deadlook entstehen kann. Dieser entsteht
dann, wenn durch einen XOR-Operator geteilt wird, aber durch einen ∧-Operator
vereinigt werden soll. Somit muss ein teilender Operator durch denselben Operator
oder einen Operator, der dieselbe Funktionalität aufweist, zusammengeführt werden.
Hier wäre die Substitution eines ∧- oder eines XOR-Operators durch den ∨-Operator
möglich, allerdings nicht umgekehrt. Weiter kann davon ausgegangen werden, dass ein
beliebiger önender Operator an irgendeinem Punkt im weiteren Verlauf der Prozesskette
durch einen weiteren Operator geschlossen wird. Denn laut Punkt (v.) und (vi.)
in Denition 9 darf nur je ein Start- und ein Endereignis existieren. Dies hat zur Folge,
dass einmal aufgespaltene Prozessschritte an irgendeinem Punkt wieder zu einem
Prozess vereinigt werden müssen, um im Endereignis zu terminieren. Diese Tatsache
impliziert, dass jeder Teilungsoperator mindestens einen zugehörigen Vereinigungsoperator
hat. Dass ein Teilungsoperator auch mehrere zugehörige Vereinigungsoperatoren
haben kann, liegt daran, dass diese Zusammenführung schrittweise geschehen kann.
Der Teilungsoperator kann den Prozess in n Teilprozesse aufteilen. Die zugehörigen
26

2.3. Algebraische Ereignisgesteuerte Prozessketten (aEPK)
Vereinigungsoperatoren führen aber nur jeweils zwei Prozessstränge zusammen. Dadurch,
dass wir diese Vereinigungsoperatoren aber in ihrer Bedeutung zusammenführen
können, entsteht am Ende ein zugehöriger Operator.
Unter diesen Annahmen werden nun die verbleibenden drei Situationen einzeln näher
beurteilt.
ODER-Teilung an einer Funktion (I)
Einer ∨-Teilung nach einer Funktion (Abbildung 2.9(a)) können in der Theorie, ebenso
wie den anderen Operatoren auch, n Ereignisse folgen. Wollte man diese Adjunktion
nun durch eine Kombination aus ∧- und XOR-Operatoren ersetzen, was theoretisch
möglich ist, dann müssen weiterhin alle vorher möglichen Wege durch den Prozess
beschritten werden können. Dies kann gewährleistet werden, wenn an jedem Ausgang
des ersten XOR-Operators einer der 2 n − 1 möglichen Prozessfortsetzungen der n-
fachen ∨-Teilung angelegt wird. Daher ist eine Ersetzung des ∨-Operators zwar sehr
aufwändig, aber auf jeden Fall möglich. Diese Trennung muss auf umgekehrte Weise
vom zugehörigen Vereinigungsoperator vorgenommen werden. Der Vereinigungsoperator
kann hier nun ebenfalls ein ∨-Operator oder eine passende Kombination aus ∧-
und XOR-Operatoren sein. Wie genau eine Ersetzung des ∨-Operators vorgenommen
wird, zeigt die Abbildung 2.10.
(a) OR-Verknüpfung
(b) Transformation der OR-Verknüpfung
Abbildung 2.10.: Ersetzung des ∨-Konnektors mittels ∧- und XOR-Konnektoren
27

Kapitel 2. Theoretische Betrachtung
ODER-Vereinigung in eine Funktion (III) oder ein Ereignis (IV)
Entsprechend den Ausführungen muss auch jeder Vereinigungsoperator einen zugehörigen
Teilungsoperator besitzen. Ist dem nicht so, ist der betrachtete Vereinigungsoperator
nur in Kombination mit anderen Operatoren ein Gegenstück des Teilungsoperators.
Aufgrund dieser Argumentation ist ein ∨-Operator als Vereinigungsoperator an
allen Stellen zwar denkbar, allerdings verrichtet er jeweils nur die Aufgaben, welche der
Teilungsoperator ebenfalls verrichtet. Somit kann auch an dieser Stelle der ∨-Operator
entsprechend dem zugehörigen Teilungsoperator in die verbleibenden beiden Operatoren
transformiert werden. Dies gilt unabhängig davon, ob dem Operator eine Funktion
oder ein Ereignis folgt. Die Entscheidung darüber, ob eine Funktion oder ein Ereignis
folgt, ist nur davon abhängig, welches Element auf jedem Pfad das letzte vor dem
Vereinigungsoperator ist. Sind diese Elemente alle derselben Art, ist das auf die Operatoren
folgende Element das komplementäre Element zu den Vorgängerelementen.
Hierbei werden Operatoren nicht als Elemente betrachtet.
28

Kapitel 3.
Wirtschaftskriminalität
In diesem Kapitel wird das Phänomen Wirtschaftskriminalität betrachtet und der aktuelle
Stand der möglichen Gegenmaÿnahmen vorgestellt. Auÿerdem wird das Konzept
der Indikatoren beschrieben.
3.1. Was ist Wirtschaftskriminalität?
Für den Begri Wirtschaftskriminalität sind in der Literatur viele verschiedene Denitionen
gebräuchlich. Je nach Fachgebiet, welchem die jeweilige Denition entstammt,
wird ein anderer Schwerpunkt zugrunde gelegt [Mai01]. Die erste betrachtete Denition
zu diesem sehr weiten Themengebiet kommt aus der Soziologie und beschäftigt
sich hauptsächlich mit den Tätern, ihrer gesellschaftlichen Stellung und den Tatmodalitäten.
Eine weitere Denition entstammt der Rechtswissenschaft und beschäftigt
sich aus diesem Grund sehr stark mit der Verletzung der Rechtsgüter und der Schäden
durch Wirtschaftskriminalität. Zusätzlich zu den Denionen aus diesen beiden Fachgebieten
existiert noch eine Denition aus dem betriebswirtschaftlichen Bereich, welche
versucht, aufgrund eines interdisziplinären Indikatormodells, die juristische Denition
auf betriebsinterne Vereinbarungen und Regeln auszuweiten. Somit umfasst diese
betriebswirtschaftliche Denition nach Bologna et al. [Mai01] alle kriminellen Vorgänge,
welche darauf abzielen, dem Betrüger einen nanziellen Vorteil zu verschaen.
Diese sehr allgemein gehaltene Denition wird vom Institut der Wirtschaftsprüfer in
Deutschland e.V. wie folgt konkretisiert:
Fraud beinhaltet beabsichtigte Handlungen einer oder auch mehrerer Personen
aus dem Kreis der gesetzlichen Vertreter, der Mitglieder des Aufsichtsorgans,
der Mitarbeiter oder Dritter, um sich durch diese Handlungen
ungerechtfertigte oder rechtswidrige Vorteile zu verschaen. (Denition
gemäÿ Institut der Wirtschaftsprüfer in Deutschland e.V.)[Pri09a]
29

Kapitel 3. Wirtschaftskriminalität
Diese Denition bildet die Grundlage der in dieser Arbeit vorgenommenen Untersuchung
auf wirtschaftskriminelle Schwachstellen. Der englische Begri fraud bedeutet
wörtlich übersetzt Betrug. Allerdings wird er heute im allgemeinen Sprachgebrauch
gleichwertig für alle Straftaten, welche mit Wirtschaftskriminalität und der oben angeführten
Denition zusammenhängen, gebraucht. Deshalb werden in dieser Arbeit
die Begrie Wirtschaftskriminalität und Fraud synonym verwendet. Zusätzlich zu diesem
Verständnis von Wirtschaftskriminalität, gibt es ein sogenanntes Robin Hood-
Phänomen [Bus09]. Dieses beschreibt ein psychologisches Selbstverständnis, mit welchem
Personen wirtschaftskriminelle Handlungen begehen, ohne dabei von äuÿeren
Anreizen oder innerem Druck getrieben zu werden und sich selbst zu bereichern. Diese
Personengruppen begehen dolose Handlungen aus einer Art falschverstandenem
Mitleid gegenüber persönlich unbekannten Dritten.
3.2. Ausprägungen von Wirtschaftskriminalität
Die möglichen Ausprägungen der Wirtschaftskriminalität, welche sich aus der vorangegangenen
Denition ergeben, sind sehr vielfältig und lassen sich unter den folgenden
Oberbegrien zusammenfassen. Diese Aggregationen wurden teilweise den oziellen
polizeilichen Jahresberichten zur Kriminalitätsentwicklung und der Studie zur Wirtschaftskriminalität
von PwC entnommen [BW07b, BW07a, NSB07].
ˆ Unterschlagung/Betrug
ˆ Diebstahl
ˆ Falschbilanzierung
ˆ Wettbewerbsvergehen
ˆ Arbeitsdelikte (z.B. Schwarzarbeit)
ˆ Insolvenzdelikte
ˆ Korruption
ˆ Geldwäsche
ˆ Produktpiraterie
ˆ Industriespionage
ˆ ...
Je nach betrachtetem Unternehmen und aktueller Unternehmenssituation nehmen die
genannten Kategorien einen anderen Stellenwert ein. So kann es vorkommen, dass
gesunde Unternehmen keinerlei Gefahr bei Insolvenzdelikten sehen, welche sich beispielsweise
durch Kapitalentziehung aus der Insolvenzmasse und damit verbundenen
Schädigungen von Gläubigern darstellen. Für wirtschaftlich angeschlagene Unternehmen,
beziehungsweise für Gläubiger dieser Unternehmen, nimmt diese Thematik eine
wesentlich gröÿere Bedeutung an. Dasselbe Verhältnis lässt sich auch in den anderen
30

3.3. Gegenmaÿnahmen
Kategorien wiedernden. Aufgrund dieses sehr unterschiedlichen Blickwinkels eines jeden
Unternehmens ist es um so wichtiger, die Gegenmaÿnahmen, beziehungsweise die
präventiv zur Verhinderung von Wirtschaftskriminalität ergrienen Maÿnahmen, auf
die konkrete Situation abzustimmen.
3.3. Gegenmaÿnahmen
In diesem Abschnitt sollen wissenschaftliche und praktische Ansätze zur Prävention,
Aufdeckung und Verfolgung von wirtschaftskriminellen Straftaten näher betrachtet
und ausgeführt werden.
3.3.1. Organisatorische/Präventive Maÿnahmen
Zu diesem Punkt zählen alle Maÿnahmen, welche von Unternehmen eingeleitet werden,
um wirtschaftskriminellen Delikten im eigenen Unternehmen vorzubeugen.
Interne Revision
Die Einrichtung einer konzern-/unternehmensübergreifend agierenden internen Revisionsabteilung
[Del05], welche als Stabsabteilung direkt bei der Unternehmensleitung
angesiedelt sein sollte, kann sehr dazu beitragen, das Risiko, Opfer einer Wirtschaftsstraftat
zu werden, zu verringern. Falls dieser Fall bereits eingetreten ist, kann die
Interne Revision betriebsinterne Ermittlungen aufnehmen und so die adäquate Verfolgung
der Straftat sicherstellen. Die Hauptaufgabe der Internen Revision besteht
allerdings darin, ein Internes Kontrollsystem (IKS) zu entwickeln, einzuführen und
zu überwachen. Dies bedeutet, die betrieblichen Abläufe ständig zu analysieren und
mögliche Prozessschwächen zu nden und zu beheben.
Corporate Compliance
Corporate Compliance [Jan08] sind eine Folge der verschärften Gesetze im Rahmen des
Sarbanes Oxley Acts (SOX) [Lan04], welcher börsennotierten Unternehmen in Amerika
das Implementieren weitreichender Kontrollmechanismen im Finanzbereich auferlegt.
Diese hierdurch entstandenen Financial Compliance können auf das gesamte Unternehmen
ausgeweitet werden und so zur Einhaltung sich ständig ändernder Vorschriften
in den verschiedenen Bereichen beitragen. Somit bedeuten Corporate Compliance
nichts anderes, als das Implementieren und Nachweisbar machen von vorgenommen
Kontrollen die sicherzustellen, dass rechtliche Vorgaben eingehalten werden. Dies führt
31

Kapitel 3. Wirtschaftskriminalität
indirekt zu einer Verbesserung des Schutzes gegen wirtschaftskriminelle Handlungen.
Gerade durch die Organisation von internen Kontrollmechanismen werden zusätzliche
Kontrollen geschaen und somit die unentdeckte Ausnutzbarkeit durch wirtschaftskriminelles
Verhalten erschwert.
Anti Fraud Management
Unter dem Begri Anti Fraud Management [BS08, HFP07] werden viele Einzelmaÿnahmen
zusammengefasst. Auÿerdem deniert ein Anti Fraud Management System
gleichzeitig einen Prozess, durch welchen das Thema Wirtschaftskriminalität im Unternehmen
ganzheitlich betrachtet werden kann und muss. Zusätzlich wird durch den
denierten Prozess ein hohes Maÿ an Qualitätssicherung gewährleistet. Teil des Anti
Fraud Managements sind auch sogenannte Notfallpläne, durch welche das Verhalten
im Fraudfall deniert und somit vorgegeben wird. Durch diese Maÿnahme kann garantiert
werden, dass Mitarbeiter im Falle der Aufdeckung von wirtschaftskriminellen
Handlungen angemessen reagieren und keine Beweise durch Unachtsamkeit vernichtet
werden.
Proling
Dieser Ansatz ist unabhängig von eventuell vorhandenen Massendaten und zielt darauf
ab, potentielle Wirtschaftsstraftäter anhand eines psychologischen Prols [Mül08] zu
nden, beziehungsweise vor einer Einstellung den personalverantwortlichen Entscheidungsträger
hinsichtlich einer, um wirtschaftskriminelle Aspekte bereicherte, Personalauswahl
zu unterstützen. Entsprechend einem ähnlichen Ansatz in der Kriminalistik
wird auch in diesem Bereich anhand verschiedener empirisch erhobener Wesensmerkmale
ein allgemeines Prol eines Wirtschaftsstraftäters erstellt, welches anschlieÿend
auf die Persönlichkeit von Bewerbern beziehungsweise von Mitarbeitern angewendet
werden kann. Zu dieser Thematik gibt es bereits eine Pilotstudie, welche in eine Feldstudie
erweitert werden soll.
3.3.2. Konkrete präventive Maÿnahmen
Unter konkreten präventiven Maÿnahmen werden alle Verfahren und Vorgehensweisen
subsumiert, welche darauf ausgerichtet sind, wirtschaftskriminelle Straftaten aufzuarbeiten.
Die hier aufgeführten Verfahren eignen sich einerseits für den Einsatz bei
einem konkreten Verdacht, andererseits aber auch bei einer, zum Beispiel im Rahmen
der Jahresabschlussprüfung, durchgeführten strukturierten Datenanaylse.
32

3.3. Gegenmaÿnahmen
Data Mining
Der Begri Data Mining [Rie09] bezeichnet im Allgemeinen die Suche nach Mustern
innerhalb einer Datenmenge. Dieser Ansatz kann auch dazu verwendet werden, innerhalb
einer Datenmenge charakteristische Attribute für einen bestimmten Sachverhalt
zu identizieren. Wenn man dies nun auf Fraud bezieht, wird mittels Data Mining
Techniken auf einer Trainingsmenge, in welcher die einzelnen Datensätze bereits nach
dem Kriterium Fraud und Good klassiziert sind, für die einzelnen Attribute der
Datensätze ein stochastischer Wert berechnet. Dieser spiegelt den Zusammenhang zwischen
dem Attribut und dem Kriterium Fraud beziehungsweise Good wieder. Mittels
der Trainingsmenge können Attribute herausgeltert werden, welche sich für die
Klassikation eines Datensatzes gut eignen. Anschlieÿend werden diese gefundenen
Attribute auf einer ebenfalls klassizierten Testmenge veriziert. Sollte sich hierbei
zeigen, dass die Attribute die Testmenge ähnlich der vorgegebenen Klassikation aufteilen,
ist die Attributsmenge dazu geeignet, auf unbekannten Daten ebenfalls eine
zuverlässige Klassikation zu erstellen. Dies hilft wiederum dabei, Fraudfälle, ähnlich
den zu Trainingszwecken verwendeten, auf unbekannten Daten zu erkennen. Zur vertiefenden
Lektüre sei auf die Diplomarbeit von Michael Riecker [Rie09] verwiesen.
Bayes-Netze
Im Rahmen einer Diplomarbeit [Nor08] in Kooperation mit der Daimler AG wurde an
der Hochschule für Technik und Wirtschaft Karlsruhe eine Methodik entwickelt, die
auf Bayes-Netzen basiert. Grundlegender Ansatz dieser Arbeit war, jeden Beleg innerhalb
eines Enterprise Resource Planning (ERP)-Systems als einen eigenen Zustand
aufzufassen. Diese Zustände wurden anschlieÿend entsprechend des gültigen Beleg-
usses, welcher durch Expertenwissen oder aus einem Prozessmodell ermittelt werden
kann, untereinander verbunden. Diese Verbindungen stellen gültige Belegüsse durch
das System dar. Nachdem dieses Modell aufgestellt war, wurden die vorhandenen elektronischen
Daten soweit bearbeitet und ausgewertet, dass jeder Verbindung der Anteil
Belege zugeordnet werden konnte, der im Verhältnis zu anderen Zuständen innerhalb
eines Teilnetzes auf diese Verbindung entfällt. Zusätzlich können aufgrund dieser praktischen
Auswertung auch Verbindungen zwischen den Zuständen, welche im gültigen
Beleguss nicht existieren, hinzugefügt und mit einem entsprechenden Wert versehen
werden. Diese zusätzlichen Verbindungen repräsentieren Abweichungen im Beleguss,
die potentiell verdächtig sind und deshalb einzeln veriziert werden müssen.
Eine weitere Ausprägung dieser Methodik erlaubt nicht nur die einmalige Betrachtung
der Zusammenhänge, wie gerade beschrieben, sondern eine vergleichende Betrachtung
zwischen verschiedenen Perioden. Hierbei geht es darum, dieselbe Auswertung für
unterschiedliche zeitliche Perioden zu machen. Die daraus resultierenden Bayes-Netze
33

Kapitel 3. Wirtschaftskriminalität
können danach untereinander verglichen werden, wobei stark abweichende beziehungsweise
stark schwankende Wahrscheinlichkeiten einer näheren Betrachtung bedürfen.
Diese Auswertung setzt allerdings voraus, dass sich über die Perioden hinweg kaum
Änderungen im Geschäftsmodell ergeben. Sollte dies doch der Fall sein, so müssen die
Einüsse dieser Änderungen auf das Ergebnis mitbetrachtet werden.
Risikobasierte Betrachtung von Wirtschaftskriminalität
Diese Methode wurde in einer Masterarbeit in Zusammenarbeit mit der SAP AG,
dem Marktführer im Bereich Unternehmenssoftware, entwickelt und wird aktuell seitens
der SAP AG zur Marktreife geführt [Bit09]. Die Methodik sieht eine Analyse der
Tätervorgehen vor, welche zur Erstellung einer Falldatenbank beiträgt, die wiederum
in Kategorien geordnet geführt wird. Im nächsten Schritt ist eine Risikoanalyse der
Geschäftsprozesse des betrachteten Unternehmens notwendig, was zur Erstellung von
Risikoindikatoren beiträgt, die ihrerseits auf Buchungsdaten angewendet, im anschlieÿenden
Scoring-Verfahren zu aussagekräftigen Werten aggregiert und mit Metainformationen
angereichert werden, so dass eine gezielte Häugkeitsauswertung stattnden
kann. Zusätzlich zur Aufbereitung und Aggregation der Daten wird eine Mindestansprechschwelle
deniert, welche irrtümlicherweise erkannte Verstöÿe weitestgehend
verhindern soll.
Benford Analyse
Frank Benford, der Namensgeber dieser Analysemethode [Nig99], hat bereits in den
20er Jahren des letzten Jahrhunderts erkannt, dass kleine Zahlen weit häuger vorkommen
als groÿe. Er erkannte, dass die Zahlen einer festen Häugkeitsverteilung folgen.
Die Zier 1 zum Beispiel steht an der ersten Stelle einer beliebig groÿen Zahl mit
einer Wahrscheinlichkeit von 30,103%. Die Zier 9 kommt an gleicher Stelle nur mit
einer Wahrscheinlichkeit von 4,576% vor. Für alle anderen Zahlen fand Benford eine
ähnlich feste Häugkeit und leitete eine Formel ab, welche heute als Benfords Gesetz
bezeichnet wird. Diese Gesetzmäÿigkeit kann auch zur Aundung von Wirtschaftskriminalität
herangezogen werden. Denn die Höhe von gebuchten Geldbeträgen folgt
im Normalfall ebenfalls diesem Muster. Wird bei der Analyse der gebuchten Beträge
eine Abweichung zu der durch Benford entdeckten Wahrscheinlichkeitsverteilung
festgestellt, so ist dies ein Indiz für eine dolose Handlung. Davon abgesehen ist auch
diese Analyse nur ein Werkzeug, um Auälligkeiten zu nden. Keinesfalls muss jede
Auälligkeit sofort eine dolose Handlung bedeuten.
34

3.4. AntiFraudSolutions von PwC
3.4. AntiFraudSolutions von PwC
Unter AntiFraudSolutions versteht man den von PwC entwickelten Maÿnahmenkatalog
zur Bekämpfung wirtschaftskrimineller Vorfälle in Unternehmen. Dieser Maÿnahmenkatalog
besteht aus vier Teilen: FraudPrevention, FraudDetection, FraudInvestigation
und FraudResponse. Jeder dieser vier Teile des Maÿnahmenkatalogs ist auf spezielle
Bedürfnisse von Unternehmen in unterschiedlichen Fraud-Situationen zugeschnitten.
Im Folgenden werden die einzelnen Teile näher erläutert und ihre Zielsetzung erklärt.
FraudPrevention
FraudPrevention umfasst alle Maÿnahmen, die der Fraud-Vorbeugung dienen. So sind
in diesem Bereich sowohl eine Beratung im Hinblick auf Compliance als auch Workshops
und Prozessanalysen auf Schwachstellen und zusätzlich notwendigen Kontrollen
angesiedelt. So kann bei einer Prozessanalyse aufgrund langjähriger Erfahrung bereits
erkannt werden, an welchen Stellen im Prozess zusätzliche Kontrollen zur Fraud-
Vermeidung sinnvoll sind.
FraudDetection
FraudDetection wird dann durchgeführt, wenn nur eine wage Vermutung oder ein
Hinweis besteht und es gilt, die vorhandenen Daten präventiv auf Fraud-Muster zu
untersuchen. Hierbei werden die Daten mittels zuvor denierter Indikatoren überprüft
und die Ergebnisse interpretiert. Indikatoren basieren ebenfalls zumeist auf Erfahrungen
oder speziellen Ermittlungswünschen. Das in dieser Phase eingesetzte Produkt
heiÿt Fraud-Scan ® [Pri09b] und stellt eine auf Indikatoren basierende Methodik zum
präventiven oder investigativen Einsatz gegen Wirtschaftskriminalität dar.
FraudInvestigation
Wurde nun im Rahmen der FraudDetection eine dolose Handlung erkannt, so kann in
die Phase der FraudInvestigation eingetreten werden. In dieser Phase werden Beweise
gerichtsverwertbar gesichert und bereits erlangte Ergebnisse für eine strafrechtliche
Anzeige oder Disziplinarmaÿnahmen aufbereitet und zu einem Bericht ausgearbeitet.
35

Kapitel 3. Wirtschaftskriminalität
FraudResponse
Die Phase FraudResponse hat die Aufgabe aus einem Fraudfall zu lernen. Deshalb
werden hier alle Maÿnahmen zusammengefasst, die ergrien werden können, um zukünftige
dolose Handlungen nach dem gleichen oder ähnlichen Muster zu verhindern.
Hierunter fallen sowohl die Einrichtung neuer Kontrollen als auch die Veränderung der
rmeninternen Compliance.
Diese vier Phasen sind als ganzheitliche Betreuung von Unternehmen hinsichtlich des
jeweiligen Fraud-Risikos konzipiert. Wie aus den kurzen Beschreibungen ersichtlich
ist, kann allen denkbaren Unternehmenssituationen mittels eines Maÿnahmenkatalogs
begegnet werden.
3.4.1. Erkennbarkeit von Fraud
Trotz der vielfältigen Ausprägungen von Fraud-Delikten gibt es nur drei konkrete
Arten, durch die dolose Handlungen erkannt und somit einer Aufklärung zugeführt
werden können. Da wäre zum einen der Zufall zu nennen. Häug fallen kriminelle
Handlungen dadurch auf, dass sich ein Zeuge meldet oder zufällige Abweichungen
erkannt werden. Zum anderen kann auch ein konkreter Verdacht dazu führen, dass
dolose Handlungen erkannt werden. Die dritte Möglichkeit ist die strukturierte Suche
nach Abweichungen. Dies wird bei Unternehmen hauptsächlich während der Jahresabschlussprüfung
durchgeführt. Fallen in diesem Zusammenhang Abweichungen auf,
können diese, wie bei einem konkreten Verdacht, näher und spezieller untersucht werden.
Zusätzlich zur Prüfung während des Jahresabschlusses ist auch eine Überprüfung
auÿerhalb dieses Turnusses denkbar, denn die Jahresabschlussprüfung fokusiert nur
auf Umstände mit wesentlichem Einuss auf die Vermögens-, Finanz- und Ertragslage
eines Unternehmens. Allerdings muss diese Prüfung dann wesentlich breiter angelegt
werden, da hier erst nach Auälligkeiten gesucht und diese anschlieÿend interpretiert
werden müssen. PwC arbeitet in diesem Bereich mit sogenannten Indikatoren. Dies
sind denierte Muster mit deren Hilfe interessante Geschäftsvorfälle von uninteressanten
Standardvorfällen getrennt werden. Allerdings setzt die Denition dieser Muster
die Kenntnis von potentiellen Schwachstellen und somit die Kenntnis der potentiellen
Fraud-Szenarien voraus, was viel Erfahrung, Kreativität und Wissen erfordert. In den
nachfolgenden Abschnitten wird das Problem der Indikatorerzeugung näher beschrieben.
36

3.5. Indikatoren
3.5. Indikatoren
Ein Indikator repräsentiert eine Auälligkeit. Er kann einerseits speziell auf eine dolose
Handlung zugeschnitten sein, wodurch mit Hilfe dieses Indikators nur dolose
Handlungen, welche die speziellen Merkmale aufweisen, gefunden werden. Ein Beispiel
hierfür wäre ein Indikator, welcher nach stornierten Aufträgen sucht, bei denen
die Versandkosten mit storniert wurden. Die Versandspesen werden normalerweise
nicht wieder ausbezahlt, weshalb dieser Spezialfall als Indikator modelliert werden
kann. Die bei dieser Art der Indikatoren angewendete Technik ist dem Whitelisting
im IT-Sicherheitsumfeld sehr ähnlich. So wird genau speziziert, wie die Datensätze
aussehen müssen, um in die Ergebnismenge zu gelangen. Bei dieser Betrachtung ist
es wichtig, dass White- und Blacklisting unabhängig von Fraud oder nicht Fraud zu
sehen sind. Somit kann sowohl White- als auch Blacklisting zur Erkennung von dolosen
Handlungen führen.
Eine zweite Art der Indikatoren repräsentiert zielgerichtete Suchvorgänge mit allgemein
gehaltenen Einschränkungen der Attribute. Zu dieser Kategorie der Indikatoren
zählt zum Beispiel die Gegenkontenanalyse oder die Analyse der Buchungszeiten. So
wird bei diesen Indikatoren, im Gegensatz zur vorhergehenden Art, eine Blacklist
geführt. Dieses Blacklisting schlieÿt bei der Gegenkontenanalyse beispielsweise Kontenpaare
aus, welche korrekterweise immer in Kombination vorkommen. Bei den Buchungszeiten
werden die normalen Geschäftszeiten ausgeschlossen. Auf diese Art erhält
man bei beiden Indikatoren eine Menge Datensätze, welche nicht durch eine Blacklist
abgedeckt sind. Anschlieÿend muss der Analyst die verbleibenden Datensätze auf
Unregelmäÿigkeiten prüfen und im Bedarfsfall die Blacklist erweitern.
Aus dieser Denition ergibt sich, dass Indikatoren der Whitelisting-Gruppe spezieller
sind und ohne viel Anpassung und nachträglicher Analyse passgenaue Ergebnisse liefern.
Die Indikatoren der Blacklisting-Gruppe bieten eine sehr viel breitere Möglichkeit
für den Betrachter einen groben Überblick über die vorhandenen Daten und deren Zusammenhänge
zu erhalten. Zusätzlich können sie bisher unbekannte Fraud-Szenarien
erkennbar machen, da Fraud-Szenarien bewusst ausgeschlossen werden müssen. Durch
den Einsatz beider Verfahren in einer abgestimmten Kombination wurden in meinen
Untersuchungen die besten Ergebnisse erzielt, da die Vorteile beider kombiniert werden
konnten.
3.5.1. Indikatorndung
Das Erstellen der Indikatoren ist einer der aufwändigsten Teile der Analyse. So müssen
Indikatoren bei neuen Branchen oder neuen Abteilungen meist komplett überarbeitet
37

Kapitel 3. Wirtschaftskriminalität
oder neu erstellt werden. Der Gewinn aus dieser Tätigkeit ist der, dass diese Indikatoren
in meist standardisierten Prozessen mit standardisierten Tabellen in vielfacher
Weise wiederverwendbar sind.
Grundsätzlich beginnt die Indikatorndung mit einer detaillierten Prozessanalyse. So
wird im Gespräch mit dem Prozessverantwortlichen der Prozessverlauf und die damit
verbundenen Datenobjekte geklärt. Ein Datenobjekt repräsentiert für gewöhnlich
eine Tabelle oder einen Verbund von Tabellen, was sehr vom Abstraktionsgrad des
Prozesses abhängt. Nach der eigentlichen Denition der Datenobjekte können diese
alles beinhalten, was sich als Datum bezeichnen lässt, und sind somit mit Klassen eines
Unied Modeling Language (UML) Diagramms vergleichbar. Diese Datenobjekte
werden vordringlich während der Prozessaufnahme erfragt, da sich hieran die eigentlichen
Indikatoren orientieren. Anschlieÿend an diese Prozessanalyse muss über mögliche
zu untersuchende Ereignisse gesprochen werden, da anhand dieser Erkenntnisse eine
Entscheidung über die Art der Indikatoren getroen werden kann. Bei unklaren Ereignissen
und Abwesenheit von Verdachtsmomenten ist der Einsatz von Blacklisting-
Indikatoren, zur Sondierung der Daten, empfehlenswert. Sollte allerdings schon ein
konkreter Verdacht vorhanden oder bereits kritische Ereignisse identizierbar sein, so
empehlt sich der Einsatz von Whitelisting-Indikatoren. Wurden auf diese Art mögliche
Indikatoren identiziert, so muss anschlieÿend geklärt werden, ob die Auswertung
dieser Indikatoren mit der vorliegenden Datenmenge möglich ist oder ob entscheidende
Daten für eine Auswertung fehlen.
3.5.2. Indikatordenition
Bei der herkömmlichen Indikatordenition ist die Standardvorgehensweise die folgende.
Nachdem der beschriebene Indikatorndungsprozess durchlaufen wurde, muss nun
der Indikator deniert und umgesetzt werden. Dazu stehen aktuell mehrere Softwareprodukte
zur Auswahl. Je nach gewähltem Werkzeug unterscheidet sich die konkrete
Umsetzung. Die Vorgehensweise ist für alle Werkzeuge aber dieselbe. So müssen zuerst
die Datenbanktabellen/Dateien und die Spalten/Felder deniert werden, welche
die Daten enthalten, auf Grundlage welcher der Indikator Ergebnisse produzieren soll.
Diese Felder werden anschlieÿend aufgelistet. Je nach Art des Indikators werden jetzt
Black- oder Whitelists von möglichen Werten, welche das Feld annehmen kann, erstellt.
Auÿerdem müssen Fremdschlüsselbeziehungen zu anderen Dateien/Datenbanktabellen
identiziert werden. Anschlieÿend werden die Indikatoren mit dem gewählten
Werkzeug umgesetzt. Nach der Umsetzung wird eine erste Datenanalyse durch den implementierten
Indikator ausgeführt, um festzustellen, ob der Indikator die gewünschten
Ergebnisse liefert. Bei Abweichungen kann weiter feinjustiert werden, um den Indikator
so weit zu entwickeln, dass möglichst exakte Ergebnisse produziert werden. Die
hierzu verwendbaren Werkzeuge werden im Anschluss einzeln beschrieben.
38

3.5. Indikatoren
ACL/IDA
Das aktuell durch PwC eingesetzte Werkzeug besteht aus einer auf Audit Command
Language (ACL) [Ltd09] basierenden Softwareanwendung, welche in Verbindung mit
dem für PwC entwickelten Bedienungsframework IDA eingesetzt wird. ACL ist sowohl
ein Werkzeug, mit welchem groÿe Datenmengen verarbeitet und gezielt geltert
werden können, als auch eine Skriptsprache, mit welcher Skripte für die Verarbeitung
von Daten im Werkzeug ACL verfasst werden können. Auÿerdem bietet ACL den
Vorteil, als Revisionssicher eingestuft zu sein. Dies bedeutet, dass eine Datenveränderungen
durch die Untersuchung ausgeschlossen ist und alle Aktionen gerichtsverwertbar
protokolliert werden. Die Möglichkeit, eigene Skripte für ACL einzusetzen, wird
vom IDA-Framework, welches eine ACL-Skriptsammlung inklusive Benutzeroberäche
darstellt, genutzt. So können ACL-Skripte verfasst und in das IDA-Framework eingebunden
werden. Bei einer Analyse müssen zusätzlich die jeweils speziell auf das zu
untersuchende Unternehmen abgestimmten Parameter für das Skript eingestellt und
die Datenquellen selektiert werden. Anschlieÿend werden die Ergebnisse automatisch
aufbereitet und zur weiteren Analyse bereitgestellt.
Picalo Framework
Das Picalo Framework [Alb09] ist ein in Python [Fou09] geschriebenes Programmpaket,
welches als Open Source Software veröentlicht wurde. Das Programm bietet die
Möglichkeit, mittels in Python verfasster eigener Skripte und wahlweise über eine Benutzeroberäche
oder Kommandozeile, vorliegende Daten zu analysieren. Zu diesem
Zweck stellt Picalo eine Bibliothek bereit, welche ein Tabellenobjekt deniert, welches
die Flexibilität besitzt, groÿe Datenmengen aufnehmen zu können und gleichzeitig dazu
geeignet ist, diese Daten im Zuge einer Analyse zu verarbeiten. Zusätzlich werden
Schnittstellen zu den gängigsten Datenbanken geboten. So sind Datenbankverbindungen
zu MySQL [SM09], Postgre [Gro09b] und über einen beliebigen Open Database
Connectivity (ODBC)Treiber bereits standardmäÿig implementiert. Auÿerdem bietet
Picalo neben bereits implementierten grundlegenden Analysemethoden wie Min/Maxoder
Benford-Analysen ein Plug-In-Konzept, mit welchem vordenierte oder eigene
sogenannte Detectlets eingebunden werden können. Detectlets stellen eine Art vorde-
nierten Indikator dar, welcher durch Anpassungen, entsprechend der Voraussetzungen
der jeweiligen Analyse, kongurierbar ist. Zusätzlich zu diesen Detectlets lassen
sich Daten aber auch über die Verknüpfung von Tabellen oder das Filtern aufgrund
von regulären Ausdrücken und ähnlichem manuell weiterbearbeiten. Auÿerdem können
durch den Einsatz von eigenen Skripten in der Programmiersprache Python auch eigene
Indikatoren deniert und umgesetzt werden. Auällig ist die aktuell noch langsame
Verarbeitung von groÿen Datenmengen.
39

Kapitel 3. Wirtschaftskriminalität
SQL
Structured Query Language (SQL) bietet im Gegensatz zu den anderen beiden Werkzeugen
weitaus weniger Analysemöglichkeiten und ist nur in Verbindung mit einer
relationalen Datenbank einsetzbar. Im Vergleich zu Picalo hat SQL allerdings einen
entscheidenden Geschwindigkeitsvorteil. Auÿerdem werden gestellte Anfragen vom jeweiligen
Datenbankmanagementsystem (DBMS) vor der Ausführung optimiert, was
weitere Geschwindigkeitsgewinne bringt. Zusätzlich lassen sich auf einzelne Spalten
der Tabellen Indizes denieren, was eine Verknüpfung deutlich beschleunigt. Diese
Möglichkeit bietet neben SQL nur noch ACL/IDA.
40

Kapitel 4.
Datenerhebung und -analyse
Im Rahmen der Diplomarbeit wurde sowohl die erarbeitete prozessbasierte Analysemethode
als auch die rein indikatorbasierte Analysemethode an Realdaten des Festspielhauses
Baden-Baden durchgeführt. Durch diese praktische Datenanalyse war es
möglich zielgerichtete Maÿnahmen zur Verbesserung der Prozesse vorzuschlagen.
4.1. Das Unternehmen und sein Umfeld
Zur strukturierten Datenanaylse wurden Auftrags- und Zahlungsdaten des Bereichs
Ticketingvertrieb des Festspielhauses Baden-Baden verwendet. Das Festspielhaus in
Baden-Baden ist ein Unternehmen im kulturellen Bereich und richtet als solches hauptsächlich
kulturelle Veranstaltungen aus, für die Eintrittskarten (Tickets) vertrieben
werden. Das Unternehmen veranstaltet jährlich ca. 120 Ballettauührungen, Opern,
Konzerte und vieles mehr. Dafür werden ungefähr 200.000 Tickets pro Jahr verkauft.
4.2. Datenzusammenhänge
Das Festspielhaus verwendet für den Vertrieb der Tickets die vom Unternehmen CTS
Eventim Solutions bereitgestellte Desktopsoftware eventim.inhouse [Gmb09]. Diese
Software verfügt über eine strukturierte Benutzeroberäche und ist im Hintergrund
mit den zentral gehaltenen Datenbeständen bei der Firma CTS Eventim Solutions
verbunden. Dieselbe Software wird für die beiden direkten Vertriebswege Telefon und
Kasse genutzt. Für den Vertriebsweg über das Internet bietet CTS Eventim Solutions
eine speziell angepasste auf Java basierende Webapplikation, welche auf denselben
Datenbeständen wie die Desktopsoftware arbeitet, allerdings einen beschränkten Funktionsumfang
bietet. So ist neben der Veranstaltungssuche und der Platzauswahl nur
41

Kapitel 4. Datenerhebung und -analyse
noch die Bezahlung und der Ticketdruck (print@home) möglich. Über die Desktopversion
dieser Software können alle für den Vertrieb der Tickets notwendigen Funktionen
erreicht und ausgeführt werden. So ist sowohl das Verkaufen/Reservieren von
Tickets, das Stornieren von Tickets, die Verwaltung der Kundendaten, alle durch den
Verkauf anfallenden Zahlungsvorgänge sowie die Abbildung von Sicherungsscheinen
und Pausenarrangements möglich. Sicherungsscheine sind eine Art Veranstaltungsrücktrittsversicherung,
welche die Möglichkeit erönen, bereits gekaufte Tickets unter
bestimmten Bedingungen umtauschen oder stornieren zu können. Hinter Pausenarrangements
verbirgt sich der Service, in der Vorstellungspause im angenehmen Ambiente
eine kulinarische Stärkung zu sich nehmen zu können. Zusätzlich können Veranstaltungen
verwaltet und abgeschlossen werden. Die eigentliche Finanzbuchführung und
die Buchhaltung werden nicht über diese Software abgewickelt, was einerseits einen
Abschluss der Veranstaltungen mit Übernahme der Zahlen in die Buchhaltung notwendig
macht, andererseits aber für diese Diplomarbeit eine Abgrenzungsmöglichkeit
des Untersuchungsbereichs darstellt. So beschränkt sich die strukturierte Datenanalyse
auf diejenigen Datenbestände, welche beim Vertrieb von Tickets anfallen, d.h. all
jene Daten, welche durch die Software der Firma CTS Eventim Solutions verwaltet
werden.
4.3. Datenerhebung
Aufgrund dieser Aufteilung der Datenhaltung war es im Rahmen des Projekts, welches
in Kooperation mit PwC durchgeführt wurde, erforderlich mit der Firma CTS Eventim
Solutions eng zusammenzuarbeiten. Hierbei erstreckte sich die Beteiligung auf den
Bereich der Datenbeschaung und Bereitstellung entsprechender Dokumentationen.
Nach einer in Abstimmung mit dem Festspielhaus entstandenen Prozessdenition war
es notwendig, alle Daten des Ticketingvertriebs bei CTS Eventim Solutions anzufordern.
Neben den Stamm- und Verkehrsdatenbeständen wurde auch eine Beschreibung
der Datenstruktur bereitgestellt, ohne die eine Datenanalyse von vollkommen unbekannten
Daten nicht durchführbar ist.
4.4. Datenanalyse
Die Datenanalyse umfasst alle Tätigkeiten, von der Erstellung eines Prozessmodells
über die Denition der Indikatoren bis hin zur Durchführung der indikatorbasierten
Analyse. So wurde von den beiden wichtigsten Prozessen innerhalb des Ticketvertriebs,
dem Vertriebsprozess selbst sowie dem Stornoprozess, eine detaillierte Prozessbeschreibung
in Form einer Ereignisgesteuerten Prozesskette (EPK) erstellt. Dieser
42

4.4. Datenanalyse
Prozessablauf sowie die in diesem Zusammenhang denierten Datenobjekte und das
Datenbankschema erlaubten es problemorientierte Indikatoren aufzustellen. Sehr hilfreich
bei dieser Tätigkeit waren auch die Hinweise der Prozessverantwortlichen im
Festspielhaus, welche dazu beigetragen haben, die Indikatoren noch zielorientierter zu
gestalten. So wurden etwa sechs Bereiche deniert, welche insgesamt 17 Indikatoren
enthalten. Diese Bereiche werden jeweils durch verschiedene Indikatoren auf bestimmte
Attribute hin überprüft.
4.4.1. Indikatorbasierte Analyse
Die indikatorbasierte Analyse nutzt wie in Kapitel 3.5 beschrieben speziell denierte
Indikatoren. Hierbei können sowohl Blacklisting- als auch Whitelisting-Indikatoren
eingesetzt werden. Beide Verfahren arbeiten mit denierten Attributen auf einer bereitgestellten
Datenmenge, um durch die Attribute denierte Szenarien aus der Datenmenge
zu extrahieren.
Verwendete Indikatoren
Im Fall des Festspielhauses Baden-Baden beziehen sich die Indikatoren auf folgende
Bereiche:
ˆ Ticketingprozess als Ganzes
ˆ Stammdaten
ˆ Auftragsbearbeitung
ˆ Stornobearbeitung
ˆ Ersatzdruck
ˆ Sicherungsscheine
Diesen Bereichen wurden die im Folgenden aufgezählten Untersuchungsthemen zugeordnet:
ˆ Gedruckte Ersatzkarten
ˆ Stornoaufträge
ˆ Auftragszeiten
ˆ Referenzprüfung von Aufträgen zu Stornoaufträgen
ˆ Festspielhaus-Kundennummer
ˆ Sicherungsscheine
ˆ Rabattstufen (Verkaufsarten)
ˆ Bankverbindungen
ˆ Spenden
ˆ Preise
43

Kapitel 4. Datenerhebung und -analyse
ˆ Gutscheine
ˆ Freikarten
Innerhalb der jeweiligen Bereiche und Themengebiete kommen teilweise mehrere Indikatoren
zum Einsatz. So gibt es im Bereich Gedruckte Ersatzkarten einen Indikator,
welcher die Häugkeit der Ersatzdrucke entsprechend der Attribute Benutzer und
Zeitpunkte auswertet. Im Bereich der Festspielhaus-Kundennummer gibt es hingegen
drei Indikatoren: Der erste analysiert Stornoaufträge, welche auf der Festspielhaus-
Kundennummer aufgelaufen sind. Der zweite listet die Einsatzzeitpunkte in Verbindung
mit den Benutzergruppen auf und der dritte ermittelt die Zahlungsarten, welche
über die Festspielhaus-Kundennummer abgewickelt wurden. Anhand dieser Beispiele
lässt sich ablesen, dass für verschiedene Bereiche auch in der Anzahl und dem Umfang
verschiedene Indikatoren verwendet werden.
4.4.2. Prozessbasierte Analyse
Diese Analyse ist sowohl eine Unterstützung bei der Indikatorndung, als auch in gewisser
Weise eine Alternative zur Indikatordenition. So wird einerseites durch die Untersuchung
und Markierung der prozesskonformen Daten die Indikatorndung durch
die Reduktion der zu betrachtenden Datenmenge erleichtert. Andererseits existiert
durch die Modellierung von Fraud-Szenarien als Prozess die Möglichkeit, diesen manipulierten
Prozess über das Vorgehensmodell auf den Daten auszuführen und so die
dazugehörigen Datensätze zu nden. Die exakte Arbeitsweise des Vorgehensmodells
wird in Kapitel 5 beschrieben. Auÿerdem werden im Abschnitt 5.6 anhand eines Beispiels
beide Vorgehensweisen erläutert. In diesem Abschnitt wird die zur Umsetzung
des Vorgehensmodells genutzte Software kurz vorgestellt und die entwickelten Skripte
beschrieben.
Praktische Umsetzung
Die praktische Umsetzung des Vorgehensmodells geschieht durch den kombinierten
Einsatz des Modellierungswerkzeugs Dia [BML09a] mit einer MySQL [SM09] Datenbank
die mit dem Analysewerkzeug Picalo [Alb09] zusammenarbeitet und einer selbstentwickelten
Skriptsammlung, welche die drei Elemente verbindet. Die Vorgehensweise
sieht entsprechend dem Vorgehensmodell, welches in Kapitel 5 beschrieben wird, vor,
dass mittels Dia der Geschäftsprozess visualisiert wird. Durch das Extensible Markup
Language (XML) basierte Dateiformat von Dia kann auf die einzelnen Grakobjekte,
deren Inhalte und Verknüpfungen untereinander, problemlos zugegrien werden. Mittels
des ersten Skriptes, welches in der Programmiersprache Python entwickelt wurde,
wird das erstellte Diagramm weiterverarbeitet. So werden zu Beginn alle Pfade des
44

4.4. Datenanalyse
Diagramms extrahiert und anschlieÿend auf die enthaltenen Datenobjekte kummuliert.
Das Ergebnis dieses Schrittes ist eine nach Pfaden getrennte Auistung der Datenobjekte,
die exakt der abstrakten Datenmenge, welche das Vorgehensmodell für diesen
Schritt vorsieht und im Kapitel 5.1.1 ausführlich deniert wird, entspricht. Daran anschlieÿend
wird ein zweites Pythonskript innerhalb der Picalo-Umgebung gestartet,
welches aus der abstrakten Datenmenge SQL -Anfragen generiert und direkt auf der
Datenbank ausführt. Das Ergebnis hieraus wird wahlweise als Tabelle angezeigt, falls
das Vorgehensmodell mit einem Fraudmodell betrieben wird, oder nur als Markierung
der gefundenen Datensätze in der Datenbank hinterlegt. Damit sind die automatisierbaren
Schritte des Vorgehensmodells abgeschlossen. Die noch folgenden dienen der
näheren Begutachtung und Untersuchung der generierten Ergebnisse. Falls die Eingabe
aus einem Fraudmodell bestand, muss geprüft werden, ob die ausgewiesenen Datensätze
fraudbehaftet sind oder ob auch nicht fraudbehaftete Datensätze selektiert wurden.
In dem Fall, dass die Eingabe aus einem herkömmlichen Prozessmodell bestand, muss
die Komplementärmenge der markierten Datensätze auf Merkmale doloser Handlungen
untersucht werden. Wird hierbei ein Fraud-Muster erkannt, so kann daraus ein
neuer Indikator erstellt werden.
Eine ausführliche Beschreibung der Skriptsammlung ist in Anhang B zu nden. Ein
Beispiel für das Vorgehensmodell, sowohl in Bezug auf fraudfreie als auch auf fraudbehaftete
Szenarien ndet sich in Kapitel 5.6 und im Anhang A.
45

Kapitel 5.
Identikation von Fraud in
Geschäftsprozessen
5.1. Modell für Fraud in Geschäftsprozessen
Ein beliebiger Geschäftsprozess innerhalb eines Unternehmens erzeugt elektronische
Daten. Diese sehr einfach erscheinende Aussage ist für die strukturierte Datenanalyse
von zentraler Bedeutung. So impliziert dieser Satz den folgenden Zusammenhang:
aEP K → D
Aus einer algebraischen Ereignisgesteuerten Prozesskette (aEPK) können mittels noch
zu beschreibender Verfahren Datenzusammenhänge extrahiert werden. Diese Datenzusammenhänge
repräsentieren jeweils die Veränderungen der elektronisch gespeicherten
Daten als Tupel. Für jeden Pfad durch die Prozesskette existiert eine separate Menge,
da es sehr unwahrscheinlich ist, dass ein Pfad dieselbe Datenmenge wie ein anderer
erzeugt. Sollte dies doch der Fall sein, so existiert die Tupelmenge in der Datenmenge
D nur einmal.
Ausgehend von dieser Implikation kann nun in einer abgewandelten Form ebenfalls
ein Fraudfall modelliert und entsprechend dargestellt werden. Hierzu ist es notwendig,
den Prozess entsprechend den Vorkommnissen des Fraudfalles zu verändern. Diese
Veränderungen können analog der in Abschnitt 5.3 betrachteten Prozessmanipulationen
ausgeprägt sein. Somit kann man zeigen, dass die veränderte aEPK ( aEP ˜K) aus
der aEPK des normalen Prozesses besteht, welche um die Prozessmanipulationen (Q)
ergänzt wurde. Q besteht aus einem Tupel ähnlich dem einer aEPK. Der Unterschied
besteht darin, dass das Tupel Q nur die zusätzlich eingebrachten Elemente mit den
jeweiligen Ausprägungen und Verbindungen enthält, so dass aEP ˜K = aEP K ∪ Q
gilt. Aus dieser veränderten aEPK ergibt sich in den meisten Fällen eine ebenfalls
veränderte Datenmenge ( ˜D).
47

Kapitel 5. Identikation von Fraud in Geschäftsprozessen
˜ aEP K → ˜D
Bei der Betrachtung der Datenmenge ( ˜D) fällt auf, dass grundsätzlich zwei mögliche
Ausprägungen dieser Menge existieren, beide mit unterschiedlichen Bedeutungen. Zum
einen kann D = ˜D gelten. Wenn dies gilt, zeigt die durch Q in aEP ˜K vorgenommene
Veränderung keine Auswirkungen auf die elektronisch gespeicherten Daten. Dies
bedeutet in der Konsequenz, dass der Fraudfall nicht ohne zusätzliche Daten erkennbar
ist. Damit lässt sich aus dieser Situation der Schluss ziehen, dass die Kontrollen in
diesem Teilprozess verbessert, beziehungsweise zusätzliche Log-Daten zur Datenanalyse
hinzugezogen werden müssen, um verlässliche Aussagen über wirtschaftskriminelle
Handlungen machen zu können. Zum anderen kann aber auch D ≠ ˜D gelten. Dies
impliziert einen Unterschied zwischen den beiden Datenmengen, was darauf hinweist,
dass die in aEP ˜K vorgenommenen Veränderungen bis auf die elektronisch gespeicherten
Daten durchschlagen und somit bei einer strukturierten Datenanalyse erkannt
werden könnten. Zusätzlich zu dieser Aussage ist es möglich aus der Schnittmenge
¯D = D ∩ ˜D Informationen zu gewinnen, welche für die Erarbeitung zusätzlicher Indikatoren
herangezogen werden können. Demnach lässt sich auch zukünftig bei ähnlich
gelagerten Prozessen dieser Indikator, leicht angepasst, für das Aunden von dolosen
Handlungen nutzen.
Die konkrete Ausprägung eines aEPK ist aus Kapitel 2.3 bekannt und kann sowohl in
der graphischen als auch in der textuellen Form genutzt werden. Die Datenmenge (D)
ist hingegen noch nicht bekannt und wird im Anschluss deniert.
5.1.1. Datenmenge
Die Datenmenge (D) ist eine Menge von Mengen. Jedes einzelne Element von D ist
eine Menge P i mit i ∈ {1, . . . , n}, welche die einzelnen Pfade durch das aEPK repräsentiert.
Die Elemente der Menge P i wiederum sind einzelne Tupel, welche die auf
dem Pfad i liegenden Variablen y ∈ Y aus der zugehörigen aEPK darstellen. Somit hat
diese Menge P i ebenso viele Elemente wie auf dem Pfad i vom Start- zum Endereignis
des aEPK verschiedene Variablen y ∈ Y verwendet werden. Beim Durchlaufen der
aEPK wird nun das Tupel der entsprechenden Variablen mit dem im Prozess vorgesehenen
Wert belegt. Auch eine Belegung mit Funktionen und Variablen ist denkbar,
denn dieser Prozess wird in seiner abstrakten Form durchlaufen ohne jegliche konkrete
Ausprägung. Durch diese Vorgehensweise entsteht am Ende eine Menge dieser Tupel,
welche jedes für sich ein y ∈ Y repräsentiert. Für jeden Pfad durch die aEPK entsteht
eine eigene Menge P i . Sollten zufällig zwei Mengen dieselben Werte aufweisen, werden
sie aufgrund des Mengencharakters von D durch eine Repräsentation der Menge
ersetzt. Gleiches gilt für die Tupel, welche die Menge P i enthalten. Zusätzlich zu den
48

5.2. Detailliertes Vorgehensmodell
Werten, welche die Variable y beim Durchlauf durch den Prozess annimmt, werden
weitere Metadaten modelliert und gespeichert, welche es später ermöglichen, die konkrete
Datenanalyse durchzuführen. So wird zu jeder Variablen deniert, für welche
Tabelle und für welches Feld sie als Platzhalter genutzt wird. Des Weiteren wird vermerkt,
ob das Feld in der Tabelle ein Schlüsselfeld ist, was später für die eziente
Auswertung sehr hilfreich ist. Auÿerdem werden den Variablen abstrakte Datensätze
zugeordnet, wodurch festgelegt wird, welche Variablen und somit deren Feld in der
entsprechenden Tabelle zusammen zu einem Datensatz gehören. Diese Zuordnung ist
notwendig, da mehrmals auf das gleiche Tabellenfeld in unterschiedlichen Datensätzen
referenziert werden kann.
Die Datenmenge D hat dadurch folgende grundlegende Form:
D = {P 1 , P 2 , P 3 , ...}
Die verwendeten Platzhalter P i mit i ∈ {1, 2, 3, . . . , n} stehen jeweils für einen weiteren
Pfad durch die aEPK. Diese stellen, wie oben bereits erwähnt, Mengen von Tupeln dar,
welche wiederum die Variablen y auf dem jeweils durchlaufenen Pfad repräsentieren.
Die Menge P weist folgende Form auf:
P = {y 1 , y 2 , y 3 , ...}
Wobei hier y i mit i ∈ {1, 2, . . . , n} für die Variablen y i des Pfades durch die algebraische
Ereignisgesteuerte Prozesskette stehen. Diese wiederum werden als Tupel dargestellt
und haben die folgende Form:
(Variablenbezeichnung = a, Wert, Tabelle, Feld, Datensatz, Schlüssel)
Ein ausführliches Beispiel ist in Kapitel 5.6 zu nden.
5.2. Detailliertes Vorgehensmodell
Nachdem nun das allgemeine Vorgehensmodell aufgestellt wurde und der Begri der
Datenmenge näher deniert ist, wird in diesem Abschnitt die detaillierte Vorgehensweise
zusammen mit Lösungsstrategien für verschiedene auftretende Probleme beschrieben.
Um im Folgenden den Ablauf transparenter zu gestalten, werden für das Modell
Zwischen- und Erweiterungsschritte eingeführt.
49

Kapitel 5. Identikation von Fraud in Geschäftsprozessen
Abbildung 5.1.: Vorgehensmodell
Die Abbildung 5.1 zeigt den konkreten Ablauf einer prozessbasierten Datenanalyse,
welche durchgeführt werden kann, um erste Anzeichen für dolose Handlungen zu erkennen.
Der erste Schritt ist eine vollständige Abbildung des Prozesses in eine algebraische
Ereignisgesteuerte Prozesskette. Auf Grundlage dieser aEPK können nun
mittels Durchlaufen des Diagramms die verschiedenen Pfade ermittelt werden. Bei
dieser Ermittlung muss zu Beginn die Behandlung von diversen Elementen der aEPK
geklärt werden. So werden neben den Kernelementen (Funktionen und Ereignissen)
auch Operatoren gefunden. Diese wiederum bestimmen den Ablauf eines Pfades mit.
Ein XOR-Operator teilt einen Pfad in zwei Pfade auf. Das führt dazu, dass im Ergebnis
zwei Pfade enthalten sein müssen, da nach dem Auftrennen der Pfade verschiedene
Operationen auf den Daten ausgeführt werden könnten, was wiederum zu
unterschiedlichen Datentupeln führen würde. Diese Probleme werden in den nächsten
Unterabschnitten eingehender erläutert und Lösungsvorschläge vorgestellt. Nachdem
alle Pfade aus dem Diagramm extrahiert sind, muss aus jedem Pfad ein abstraktes
Datentupel erzeugt werden. Dies wird mit Hilfe der den Funktionen angegliederten
Informationsobjekten und den ebenfalls vorhandenen Datenfunktionen, welche die Algebra
bereitstellt, durchgeführt. Nachdem auf diese Art für jeden Pfad eine Menge von
Tupeln geschaen wurde, welche die internen Abhängigkeiten der Elemente untereinander
visualisiert, kann im Anschluss diese Menge als Muster auf konkrete Datensätze
50

5.2. Detailliertes Vorgehensmodell
angewendet werden. Diese Anwendung hat zur Folge, dass nun eine Entscheidung
möglich ist, ob der betrachtete Datensatz dem Muster entspricht und somit durch den
Pfad erzeugt werden konnte oder nicht. Sollte der konkrete Datensatz mit dem Muster
übereinstimmen, ist eindeutig, dass dieser Datensatz durch den Prozess, speziell
durch den Pfad des Prozesses, erzeugt wurde. Stimmt der Datensatz nicht überein
oder existieren weitere Datensätze, welche durch kein Muster abgedeckt werden können,
so wurden diese Datensätze nicht durch den beschriebenen Prozess erzeugt. Dies
kann nun bedeuten, dass der Prozess nicht eindeutig und vollständig beschrieben und
somit Sonderfälle nicht modelliert wurden. Anderererseits kann das auch bedeuten,
dass dieser Datensatz auÿerhalb eines denierten Prozesses erzeugt wurde, was ein
starker Hinweis auf dolose Handlungen ist.
5.2.1. Syntax zur Denition der Informationsobjekte
Damit, wie im Vorgehensmodell beschrieben, die abstrakte Datenmenge automatisiert
erstellt werden kann, ist es notwendig eine Syntax zu entwickeln, welche es erlaubt
alle relevanten Informationen im Diagramm zu denieren. Als Zeichenelement für die
Denition der Variablen werden die bereits vorhandenen Informationsobjekte genutzt,
da sie, wie die Bezeichnung bereits vermuten lässt, für die Modellierung von Daten
und Informationen geschaen wurden.
Die Syntax besteht aus mehreren Teilen und ist grundlegend wie folgt aufgebaut:
Abbildung 5.2.: Syntaxdenition der Informationsobjekte
5.2.2. Vorgehen bei Verknüpfungen
In Kapitel 2 wurden bereits die drei vorhandenen und in EPKs eingesetzen Operatoren
vorgestellt. Potentiell können alle drei Operatoren für die Modellierung von Diagrammen
verwendet werden, weshalb in diesem Abschnitt deren Behandlung innerhalb des
Vorgehensmodells erarbeitet werden.
Vorgehen bei XOR-Verknüpfungen
Wie bereits angedeutet, wird durch eine XOR-Verknüpfung ein Pfad durch den Prozess
in mindestens zwei Pfade aufgesplittet. Diese Aufteilung führt dazu, dass im jeweiligen
Prozess nur ein Pfad zum weiteren Durchlaufen verwendet werden kann. Der
51

Kapitel 5. Identikation von Fraud in Geschäftsprozessen
A Variablenbezeichnung
B Tabellenbezeichnung
C Feldbezeichnung
-K Schlüsselattribut - Falls dieses Element vorhanden ist, ist das Feld (C) in der
Tabelle (B) ein Schlüsselfeld.
D Datensatznummer - Dient der Unterscheidung verschiedener Datensätze einer
Tabelle.
E Wertzuweisung - An dieser Stelle kann sowohl eine bereits denierte Variable
eingesetzt werden als auch ein mittels Grundrechenarten ermitteltes Ergebnis
zwischen zwei bereits denierten Variablen. Abgesehen davon können hier
auch Ergebnisse komplexer Funktionen einer Variablen zugewiesen werden.
Allerdings ist es dazu noch notwendig, eine Syntax für die Denition dieser
Funktionen zu entwickeln.
Algorithmus, welcher die Pfadsuche implementiert, verfährt mit XOR-Trennungen so,
dass einer der Verzweigungen als bereits durchlaufen markiert und mit diesem als
nächsten Schritt fortgefahren wird. Ist der Algorithmus am Ende der Prozesskette angelangt,
so wird der durchlaufene Pfad gespeichert und rückwärts wieder aufgerollt.
Diese Rückschritte erfolgen solange, bis der Algorithmus auf einen XOR-Operator
trit, bei welchem noch nicht alle Verzweigungen als durchlaufen markiert sind. An
dieser Stelle wählt der Algorithmus die nächste, noch nicht durchlaufene Verzweigung
und durchläuft den daraus resultierenden Pfad bis zum Ende der Prozesskette. Die
Pfadsuche ist abgeschlossen, sobald der Wurzelknoten (Startereignis der Prozesskette)
nach einem rückwärts gerichteten Durchlauf wieder erreicht wird.
Vorgehen bei AND-Verknüpfungen
Neben den XOR-Verknüpfungen existieren auch AND-Verknüpfungen. Diese verknüpfen
mehrere Teilpfade in einer Prozesskette, indem diese Teilpfade jeweils parallel
ausgeführt werden. Das Durchlaufen des Diagramms erzeugt am Ende ein rein sequenzielles
Ergebnis, wozu diese Parallelität nicht passt. Betrachtet man eine AND-
Verknüpfung näher, so fällt auf, dass keiner ihrer Teilpfade dieselben Daten manipulieren
sollte. Angenommen, es werden in einem Teilpfad dieselben Daten, was theoretisch
möglich wäre, manipuliert, so muss eine klare Reihenfolge deniert werden, da sonst
das Datenergebnis zufällig entsteht. Je nach dem, welcher der beiden Teilpfade zuletzt
auf das Datenobjekt schreibend zugreift, kann das Ergebnis einmal von Teilpfad a und
einmal von Teilpfad b stammen, ohne das genau speziziert ist, welcher Pfad das Ergebnis
erzeugt hat. Da ein solch zufälliges Verhalten innerhalb einer EDV-gestützten
Prozesskette nicht gewünscht ist und auch nicht toleriert werden sollte, muss hier eine
klare Sequenzialisierung modelliert werden, welche die Reihenfolge der um ein Daten-
52

5.2. Detailliertes Vorgehensmodell
objekt konkurrierenden Pfade festlegt. Dies führt zwangsläug dazu, dass eine parallele
Abarbeitung dieser Teilpfade nicht mehr möglich ist. Aufgrund dieser Zusammenhänge
kann bei einer AND-Verknüpfung davon ausgegangen werden, dass in den jeweiligen
Zweigen der Verknüpfung nicht um ein und dasselbe Datenobjekt konkurriert wird.
Deshalb kann eine solche parallele Teilpfadausführung für die Pfaderstellung auch sequenzialisiert
werden. Hierbei ist es unerheblich, welcher der Zweige zuerst durchlaufen
wird, da die veränderten Datenmengen voneinander unabhängig sind.
Vorgehen bei OR-Verknüpfungen
Zusätzlich zu AND- und XOR-Verknüpfungen existiert, wie in Kapitel 2.3 beschrieben,
noch ein dritter Operator, der OR-Operator. Dieser stellt die Analyse von algebraischen
Ereignisgesteuerten Prozessketten vor einige Probleme (bereits in Kapitel 2.3
beschrieben). Aus diesem Grund wird an dieser Stelle eine Bereinigung der aEPK
um OR-Verknüpfungen bereits vorausgesetzt. Somit enthält die an diesem Punkt vorhandene
aEPK keine OR-Verknüpfungen mehr, was direkt dazu führt, dass diese Art
Operator nicht mehr betrachtet werden muss.
5.2.3. Vorgehen bei Schleifen
Die Behandlung von Schleifen innerhalb einer algebraischen Ereignisgesteuerten Prozesskette
bei der Pfadanalyse stellt eine Herausforderung dar. So können Schleifen nicht
komplett ignoriert werden, da innerhalb der Schleifen Datenveränderungen durchgeführt
werden können, welche sich unter Umständen auch auf gespeicherte Daten niederschlagen.
Zusätzlich existiert für Schleifen nur selten eine fest denierte und für
alle Ausprägungen der Prozesskette gleiche Abbruchbedingung. Diese wäre eine direkte
Voraussetzung dafür, Schleifen als spezielle Wege durch den Prozess betrachten zu
können. Da diese gleiche Abbruchbedingung aber nicht existiert, müssen Schleifen mit
variabler Iterationszahl deniert und an dieser Stelle eingesetzt werden.
Der erste Schritt der Behandlung von Schleifen ist der, sie in aEPKs zu erkennen.
Sind die Schleifen erkannt, so kann für die jeweilige Schleife separat die Datenmenge
ermittelt werden. Anschlieÿend kann die Schleife in zwei Arten unterteilt werden, wobei
für die erste Art (Schleifen ohne Einuss auf Umgebungsdaten) im nächsten Abschnitt
ein Vorschlag für die Behandlung ausgearbeitet wird. Für die zweite Art (Schleifen
mit Einuss auf Umgebungsdaten) ist noch weiterer Forschungsaufwand notwendig,
weshalb an dieser Stelle das Problem beschrieben und eine Idee als Lösungsansatz
präsentiert wird.
53

Kapitel 5. Identikation von Fraud in Geschäftsprozessen
Schleifendarstellung in aEPKs
Abbildung 5.3.: Schleifen in aEPKs
Wie die Abbildung 5.3 zeigt, können Schleifen als eine sich wiederholende Folge von
Prozessschritten mit einem Verknüpfungspunkt zum Prozess gesehen werden. Zusätzliche
Voraussetzung für einen Teilprozess, welcher als Schleife bezeichnet wird, ist, dass
für alle Wege durch diesen Teilprozess der Anfangs- und Endpunkt identisch sind.
Im gezeigten Teilprozess in Abbildung 5.3 ist der Verknüpfungspunkt der erste XOR-
Operator. Die Prozessschritte Sitzplatz wählen und weiterer Sitzplatz gewünscht stellen
den Schleifenrumpf (Schleifenteilprozess) dar, wobei in diesem Beispiel beachtet
werden muss, dass der Prozessschritt Sitzplatz wählen unabhängig von den Schleifendurchläufen
mindestens einmal durchlaufen werden muss, um den Prozess beenden zu
können. Aus diesem Grund ist auch nur der erste XOR-Operator als Verknüpfungspunkt
zu sehen und nicht der zweite oder beide.
Der Begri Umgebungsdaten fasst alle Datendenitionen zusammen, welche auÿerhalb
eines Schleifenrumpfes bestehen. Unter Einuss auf Umgebungsdaten ist der Zustand
zu verstehen, dass innerhalb der Schleife Daten manipuliert werden, welche vor der
Schleife ausgelesen wurden und/oder nach der Schleife im dann aktuellen Stand weiterverwendet
werden. Dies führt dazu, dass die Anzahl der Schleifendurchläufe eine
direkte Auswirkung auf umgebende Daten hat. Was wiederum verhindert, dass für den
die Schleife umgebenden Prozess kein Schleifendurchlauf angenommen werden kann
und die eventuell vorhandenen Schleifendurchläufe in einem zweiten Schritt geprüft
werden. Kein Einuss auf Umgebungsdaten hingegen bedeutet, dass die innerhalb des
Schleifenrumpfes verarbeiteten Daten keine Auswirkungen auf die Umgebungsdaten
haben.
Schleifen ohne Einuss auf Umgebungsdaten
Schleifen ohne Einuss auf Umgebungsdaten kommen in der Praxis sehr selten vor,
da fast jede Schleife in irgendeiner Form Auswirkung auf die anderen Daten des Prozesses
hat. Die Abbildung 5.3 zeigt einen Teilprozess, in dem die integrierte Schleife
54

5.2. Detailliertes Vorgehensmodell
frei von Auswirkungen auf die umgebenden Daten ist, was anhand der modellierten
Informationsobjekte dargestellt wird.
Liegt nun ein Prozess mit einer Schleife ohne Einuss auf die Umgebungsdaten vor, so
wird die Schleife als eigener Prozessweg erkannt. Dadurch ist klar, dass eine Schleife
nur mittels eines Operators an den umgebenden Prozess angebunden sein kann. Die
Besonderheit hierbei ist, dass der Operator, welcher den Schleifenteilprozess einleitet,
gleichzeitig auch dessen Endpunkt sein muss (siehe Kapitel 5.2.3). Durch diese Anomalie
können Schleifen bei einem einzigen Durchlauf durch den Prozess erkannt werden.
Sobald der Zeiger des Iterators auf einen Operator trit, wird eine Schleife erkannt.
Dieser Operator muss in den Vergangenheitsdaten des Iterators, welche den Verlauf
des aktuellen Weges durch den Prozess aufzeichnen, bereits enthalten sein. Anschlieÿend
wird der Schleifenprozess aus dem Verlauf extrahiert und durch eine Markierung
mit dem entsprechenden Schleifenidentikator ersetzt. Durch dieses Vorgehen kann die
Schleife separat gespeichert werden und ist für jeden Prozessweg referenzierbar. Auÿerdem
muss so im Voraus nicht bekannt sein, wie oft die Schleife durchlaufen wird,
sondern dies kann von der Beschaenheit der Daten abhängig gemacht werden.
Wurden nun abschlieÿend alle Pfade durch den Prozess ermittelt, wird auch für den
Teilprozess, welcher die Schleife darstellt, bei der Ermittlung der jeweiligen Datenmenge
vorgegangen, wie in Kapitel 5.2.4 beschrieben, und eine abstrakte Datenrepräsentation
erstellt. Diese abstrakte Datenrepräsentation wird in die Pfade integriert,
aber gesondert ausgewertet.
Schleifen mit Einuss auf Umgebungsdaten
Bei Schleifen mit Einuss auf Umgebungsdaten gibt es ein oder mehrere Datenattribute,
welche innerhalb des Schleifenteilprozesses (Schleifenrumpf) verändert oder
initialisiert und im umgebenden Prozess weiterverwendet werden. Diese Verknüpfung
von Daten innerhalb der Schleife und Daten auÿerhalb der Schleife führt dazu, dass
der umgebende Prozess nicht mehr unabhängig von der Anzahl der Schleifendurchläufe
behandelt werden kann. Denn jeder Schleifendurchlauf verändert die gemeinsam
genutzten Daten, wodurch die Inhalte dieser Daten von der Zahl der Schleifendurchläufe
abhängig sind und somit ohne das Wissen um die Anzahl der Durchläufe nicht
überprüft werden können.
Aus diesem Grund ist das nachträgliche Prüfen der Daten innerhalb der Schleife auf
Konsistenz mit dem vorab geprüften Hauptprozess nicht möglich. Um diese Prozesse
trotzdem zu überprüfen, können Schleifen mit Einuss auf Umgebungsdaten zu solchen
ohne umgebaut werden. Es ist möglich den Prozess dahingehend zu optimieren, dass
die Auswertung zum Wohle einer integrierten Schleifenbetrachtung manipuliert wird,
allerdings um den Preis eines Verlustes an Aussagekraft. So kann das Datum, welches
55

Kapitel 5. Identikation von Fraud in Geschäftsprozessen
Abbildung 5.4.: Umgebungsdatenmanipulation durch Schleifen
die Schleife mit der Umgebung verbindet, von der Auswertung ausgeschlossen werden.
Abhängig von der Wichtigkeit dieses Datums für eine Klassikation in Fraud oder
nicht Fraud muss über die Manipulation des Prozesses in jedem Einzelfall entschieden
werden. Dieses Vorgehen kann aber aufgrund der entstehenden Ungenauigkeit nur eine
Zwischenlösung sein. Zukünftig könnten durch die Betrachtung der Dateneigenschaften
nach einem Schleifendurchlauf eventuell bessere Lösungen gefunden werden.
5.2.4. Erstellung der Datenmenge
Zur Erstellung der abstrakten Datenmenge ist es notwendig bereits alle Pfade durch
das aEPK extrahiert bereitgestellt zu bekommen. Jeder Pfad wird einzeln nochmals
durchlaufen und jedes Informationsobjekt, das einer Funktion zugeordnet ist, wird
analysiert und in die Menge, die diesen Pfad innerhalb der abstrakte Datenmenge
repräsentiert aufgenommen. Hierbei hilft die in Kapitel 5.2.1 denierte Syntax zur
Modellierung der Daten im Diagramm, denn dadurch wurden die Daten bereits in
einer maschinenlesbaren Form beschrieben und können automatisiert weiterverarbeitet
werden. Die erkannten Schleifenteilprozesse, welche separat gespeichert wurden,
werden ebenfalls erneut durchlaufen. Die dadurch gefundenen Daten innerhalb der
Informationsobjekte werden den jeweiligen Datenmengen der Pfade, in welchen die
Schleifen vorkommen, hinzugefügt.
5.2.5. Auswertung der Datenbestände
An diesem Punkt des Vorgehensmodells wurde bereits der zugrundeliegende Prozess
als aEPK modelliert und mit Hilfe der beschriebenen Behandlungen der einzelnen
Elemente aller Pfade durch das Diagramm einzeln gefunden und gesichert. Zusätzlich
existierende von Schleifen erzeugte, Teilpfade wurden mit einer Referenz zu den Stellen
innerhalb der Pfade ebenfalls gesichert. Auÿerdem ist der Schritt, in dem aus den
56

5.3. Manipulationsarten innerhalb eines Geschäftsprozesses
Informationsobjekten entlang der Pfade eine in Kapitel 5.1.1 beschriebene abstrakte
Datenrepräsentation sowohl für die Pfade als auch für die Schleifen ohne Einuss
auf Umgebungsdaten erstellt wurde bereits abgeschlossen. Nach diesen Vorbereitungen
wird aus jeder Datenmenge, die einen Pfad repräsentiert, eine SQL-Anweisung erzeugt.
An dieser Stelle sei anbemerkt, dass auch eine Implementierung, mit welcher jeder Datensatz
einer zu untersuchenden Datenmenge mit der abstrakten Datenrepräsentation
abgeglichen wird, um so die passenden Datensätze zu nden, möglich ist. In dieser
Arbeit wurde der Weg über eine SQL-Anweisung deshalb gewählt, da die zu analysierenden
Daten idealerweise bereits in einem Datenbank Management System (DBMS)
zur Verfügung stehen und somit das DBMS die Verknüpfung und Filterung der Datensätze
ezient vornehmen kann. Ebenso ezient kann durch das DBMS auch eine
Markierung der gefundenen Datensätze erzeugt werden, welche die Filterung im Anschluss
erleichtert. Zusätzlich zur Auswertung des Pfades werden, falls Schleifen ohne
Einuss auf Umgebungsdaten auf dem Pfad liegen, auch deren abstrakte Datenrepräsentation
in eine SQL-Anweisung überführt und verknüpft mit dem Pfad ausgewertet.
Dadurch wird das Ergebnis um die in den Schleifen vorhandenen Daten aufgebläht
und es kann zu Mehrfachnennungen der Pfaddatensätze kommen. Dies ist allerdings
vernachlässigbar und verfälscht das Ergebnis deshalb nicht, weil die Schleifendaten in
Datenbanken, die dem relationalen Modell folgen in jeweils eigenen Datensätzen stehen.
Diese werden den Datensätzen, welche den umgebenden Prozess repräsentieren,
nur hinzugefügt. Für Schleifen mit Einuss auf Umgebungsdaten ist dieses Vorgehen
nicht möglich.
Wurden die Datenbestände bis zu dieser Stelle bearbeitet, existiert jetzt eine Menge
D, welche alle Datensätze enthält, die in den vorangegangenen Schritten als Ergebnis
gezeigt wurden und somit mit dem Prozess konform sind. Auÿerdem gibt es eine
Komplementärmenge ¯D, welche alle anderen Datensätze enthält. Die Untersuchung
der Menge ¯D wird in Kapitel 5.5 näher beschrieben.
5.3. Manipulationsarten innerhalb eines
Geschäftsprozesses
Entsprechend des in Kapitel 5.1 denierten Modells kann Fraud nicht nur über das
Ausschlussverfahren mit der Betrachtung der Datenbasis auf Prozesskonformität und
anschlieÿender Komplementanalyse aufgedeckt werden, sondern es gibt ebenfalls die
Möglichkeit über eine Modellierung des Fraudereignisses und dem Abgleich mit dem
korrekten Prozess Whitelisting Indikatoren zu erstellen und so gezielt nach Fraudereignissen
zu suchen. Dies wird in Kapitel 5.4 erläutert. In diesem Abschnitt wird von
konkreten Geschäftsvorfällen abstrahiert und die grundlegenden Manipulationstechni-
57

Kapitel 5. Identikation von Fraud in Geschäftsprozessen
ken aufgezeigt. Zur Veranschaulichung gehört zu jedem Baustein ein Teilprozess, der
als Beispiel dienen soll.
Einfügen zusätzlicher Prozessschritte
Das Einfügen zusätzlicher Prozessschritte ist die häugste Manipulationsart. Sie umfasst
Tätigkeiten, welche als Funktionen aufgefasst werden können und zusätzlich zu
den eigentlichen Prozessschritten ausgeführt werden.
Abbildung 5.5.: Manipulationsart: zusätzlicher Prozessschritt
Das Beispielszenario sieht vor, dass ein Lieferant eine überhöhte Rechnung für gelieferte
Waren stellt. Diese Waren sind mit einem, vom zentralen Einkauf genehmigten und
durch Angebote ermittelten Preis hinterlegt. Der beteiligte Einkäufer, manipuliert die
Stückpreise der Waren im System, somit ndet der Mitarbeiter innerhalb des Rechnungswesens,
welcher die Rechnung prüft, nur die erhöhten Stückpreise im System,
vergleicht diese und begleicht den fälligen Rechnungsbetrag. Anschlieÿend werden die
manipulierten Stückpreise vom beteiligten Einkäufer wieder auf die ursprünglichen
Werte gesetzt. Dieses Szenario ist in der Abbildung 5.5 durch graue Schattierung vom
normalen Prozess abgehoben. Es ist erkennbar, dass durch das Einfügen zusätzlicher
Prozessschritte die Möglichkeit entsteht, das Unternehmen gemeinschaftlich um entsprechende
Geldbeträge zu betrügen.
Überspringen von Prozessschritten
Überspringen von Prozessschritten bedeutet für die Modellierung, den zu überspringenden
Teilprozess im manipulierten Diagramm weg zu lassen. Soll sowohl der manipulierte
Ablauf als auch der prozessgegebene in einer Prozesskette abgebildet werden,
so empehlt es sich zwei zusätzliche XOR-Operatoren einzufügen: einen zu Beginn des
zu überspringenden Bereichs und einen am Ende. Zusätzlich wird ein Pfad direkt vom
58

5.3. Manipulationsarten innerhalb eines Geschäftsprozesses
einen zum anderen Operator eingefügt. Auf diese Weise ist es möglich, sowohl dem
korrekten Pfad zu folgen als auch den Teilprozess zu überspringen.
Abbildung 5.6.: Manipulationsart: Prozessschritte überspringen
Im Beispiel wird die Manipulation einer Spesenabrechnung dargestellt. Mit welchen
Mitteln die Prüfung der Abrechnung genau umgangen wird, muss hier nicht deniert
werden. So gäbe es beispielsweise die Möglichkeit einer Unterschriftenfälschung oder
die, dass durch eine Vertretungsregelung der Spesennutznieÿer gleichzeitig zum Prüfer
wird und so die Möglichkeit hat, eine manipulierte Spesenabrechnung ausbezahlt zu
bekommen.
Vorzeitiges Prozessende
Das vorzeitige Prozessende stellt einen Spezialfall des Überspringens von Teilprozessen
dar. So wird hier die Prozessbearbeitung abgebrochen und der Prozess direkt beendet.
Auch hier ist eine gemeinsame Modellierung mit dem korrekten Prozess über
das Einfügen der beiden XOR-Operatoren (wie unter Überspringen von Teilprozessen
beschrieben) möglich.
Das Beispiel modelliert einen Fall von Wirtschaftsspionage und der Weitergabe von
Aufträgen an einen Wettbewerber. So wird der vorgesehene Prozess nach dem Startereignis
abgebrochen und der Auftrag unbearbeitet an den Wettbewerber weitergegeben.
Manipulation der Eingabeparameter
Bei der Manipulation der Eingabeparameter geht es darum, dass noch bevor Daten
in das System eingegeben werden, Manipulationen an diesen Daten vorgenommen
werden. In aEPKs kann dies durch Manipulation der Informationsobjekte dargestellt
werden.
59

Kapitel 5. Identikation von Fraud in Geschäftsprozessen
Abbildung 5.7.: Manipulationsart: vorzeitiges Prozessende
Abbildung 5.8.: Manipulationsart: geänderte Informationsobjekte
Im Beispiel (Abbildung 5.8) ist eine Unterschlagungssituation abgebildet. So besteht
bei einem Barverkaufsprozess die Möglichkeit, das bar erhaltene oder ausgezahlte Geld
zu beeinussen, was einer Manipulation des Informationsobjekts Betrag gleichkommt.
Im vorliegenden Fall wird ein Betrag von 8 EUR verlangt, in der Kasse landen allerdings
nur 2 EUR.
Kombinationen
Diese Manipulationsarten müssen nicht in ihrer Reinform auftreten, sondern können
auch in jeglicher Kombination miteinander vorkommen. So ist zum Beispiel die Kombination
aus zusätzlichen Prozessschritten und einem undenierten Prozessende im
Bereich Wirtschaftsspionage denkbar. Dabei wird ein zusätzlicher AND-Operator in
die Ereignisgesteuerte Prozesskette eingebracht. In einem Zweig wird der Prozess wie
vorgesehen ausführt, im anderen aber die Informationen an einen Wettbewerber wei-
60

5.4. Untersuchung und Entwicklung von Fraud-Szenarien
tergegeben. Zum Schluss werden beide Zweige kurz vor dem abschlieÿenden Ereignis
wieder miteinander kombiniert. Ein Beispiel zur Kombination der Manipulationsarten
ist in Abbildung 5.9 dargestellt.
Abbildung 5.9.: Kombination der Manipulationsarten
5.4. Untersuchung und Entwicklung von
Fraud-Szenarien
Durch die im vorhergehenden Abschnitt näher beschriebenen Manipulationsarten kann
nun auf Grundlage des originalen Prozesses (aEP K) ein veränderter Prozess ( aEP ˜K)
geschaen werden, welcher einen Fraud-Fall modelliert. Hierzu kann auf zwei Arten
vorgegangen werden. Im ersten Fall wird das wirtschaftskriminelle Vorgehen mit in
das Modell modelliert. Auf diese Art und Weise entsteht ein Modell, welches sowohl
den originalen Prozess als auch das modellierten Fraud-Szenario enthält. Im anderen
Fall besteht die Möglichkeit nur die wirtschaftskriminelle Vorgehensweise als Prozess
zu modellieren und den normalen, denierten Prozessverlauf auÿen acht zu lassen.
Durch diese eingeschränkte Sichtweise auf den Fraud-Fall wird dieser besonders deutlich
dargestellt. Ein Beispiel für die Modellierung eines Fraud-Szenarios ndet sich in
Abschnitt 1.3 in gekürzter und in Abschnitt 5.6 in detaillierter Form.
61

Kapitel 5. Identikation von Fraud in Geschäftsprozessen
5.4.1. Auswertung von Unterschieden
Die Auswertung der Unterschiede ist die erste Stufe zu einem neuen Indikator. So kann
über diese Auswertung die Abweichung zwischen dem denierten und dem Fraud-
Prozess festgestellt werden, was dazu führt, dass ein Indikator zur Erkennung der Abweichungen
deniert werden kann. Dieser Indikator kann anschlieÿend zur Erkennung
der Fraud-Szenarien auf der vorhandenen Datengrundlage herangezogen werden.
Unterschiede zwischen den Prozessen können auf verschiedenen Ebenen des Vorgangsmodells
untersucht werden. So könnten bereits die Prozessdiagramme auf eventuelle
Abweichungen hin überprüft werden. Da allerdings jede Art von Prozessveränderung
durch das Fraud-Szenario im Prozessmodell modelliert werden kann, aber bei weitem
nicht alle denkbaren Szenarien auch auf den Daten erkennbar sind, wäre es nicht sinnvoll,
an dieser frühen Stelle der Verarbeitung auf Unterschiede zu untersuchen. Erst
am Ende des Vorgehensmodells die konkreten Datensätze auf Unterschiede zwischen
den beiden Ausgangsmodellen hin zu untersuchen, ist allerdings auch nicht sinnvoll,
da hier in einem nicht notwendigen Detaillierungsgrad verglichen würde, was den Vergleich
aufwändig und fehleranfälliger macht. So müssten alle markierten, dadurch als
gefunden gekennzeichneten Datensätze mit jenen, durch den Fraud-Prozess beschriebenen,
verglichen und im nächsten Schritt die abweichenden Datensätze auf ein erkennbares
Muster untersucht werden, so dass daraus ein fertiger Indikator entstehen
kann.
Aus den beschriebenen Gründen wird beim Vergleich nicht direkt beim Prozessmodell
allerdings auch nicht erst bei den Datenausprägungen angesetzt. Für diese Aufgabe
wird die erstellte abstrakte Datenrepräsentation in Form der Datenmenge D für den
denierten Original-Prozess und der Datenmenge ˜D für den Fraud-Prozess benutzt.
Im eigentlichen Vergleich werden die einzelnen Prozesspfade, welche in D als einzelne
Elemente (P i mit i ∈ {1, 2, . . . , n}) repräsentiert sind, wiederum tupel- und paarweise
mit den Elementen aus ˜D verglichen. Hierbei können Abweichungen in verschiedenen
Formen auftreten. Die Formen der Abweichungen orientieren sich an den grundsätzlichen
Manipulationsarten aus Kapitel 5.3. Dies bedeutet, dass Abweichungen entweder
einzeln vorkommen oder Kombinationen aus zusätzlich vorhandenen Datentupeln, fehlenden
Datentupeln oder Datentupeln mit abweichenden Werten existieren. Die am
häugsten vorkommenden Formen der Abweichungen sind wahrscheinlich Kombinationen
aus den beschriebenen Formen.
62

5.4. Untersuchung und Entwicklung von Fraud-Szenarien
Denition 15 (Menge der Dierenzen zwischen D und ˜D):
Die Menge der Dierenzen Diff besteht aus den Elementen Diff ˜Pi
mit i ∈ {1, . . . , | ˜D|}.
Jede Menge Diff ˜Pi
besteht ihrerseits aus den Elementen E i,j für ein festes i und
∀j ∈ {1, . . . , |D|}, wobei die Elemente E i,j die Unterschiede zwischen der Menge P i
und der Menge P j darstellen und wie folgt berechnet werden: E i,j = (P j \ ˜P i )∪( ˜P i \P j ).
Entsprechend dieser Denition enthält die Menge Diff wiederum Mengen Diff ˜Pi
,
welche als Elemente wiederum Mengen E i,j beinhalten. Damit enthält die Menge E i,j
die Tupel aus P i und P j , welche nicht in beiden Mengen enthalten sind und damit
die beiden Prozesswege voneinander unterscheiden. Diese Dierenzmengen (E i,j ) werden
zusammengefasst zur Menge Diff ˜Pi
, die alle Dierenzmengen des Prozesspfades
˜P i und alle Prozesspfade aus der aEP K vereinigt. Anschlieÿend werden alle Mengen
Diff ˜Pi
zur Menge Diff zusammengefasst. Somit enthält die Menge Diff in strukturierter
Form alle Unterschiede zwischen der abstrakten Datenmenge D und ˜D.
Auf Grundlage der Menge Diff kann entschieden werden, ob das in ˜ aEP K modellierte
Fraud-Szenario auf den Daten erkannt werden kann oder nicht. Auÿerdem kann eine
Aussage darüber getroen werden, wie aufwändig die Indikatorerstellung ist und wie
genau die erhaltenen Ergebnisse sein werden.
Hierzu können drei Fälle unterschieden werden.
Fraud ist nicht erkennbar
Dazu betrachten wir die Elemente E i,j zur Menge Diff ˜Pi
. Falls gilt ∃E i,j für j ∈
{1, . . . , |D|} mit E i,j ≡ ∅, dann existiert ein Pfad P j , welcher dieselbe abstrakte Datenmenge
liefert wie der Pfad ˜P i . Dies hat zur Konsequenz, dass diese beiden Pfade
auf den Daten nicht unterschieden werden können. Dies wiederum führt dazu, dass das
modellierte Fraud-Szenario auf den gegebenen Daten nicht erkannt werden kann, da
jeder gefundene Datensatz auch durch den Pfad P j des originalen Geschäftsprozesses
erzeugt worden sein kann.
Fraud ist sicher erkennbar
Zur sicheren Erkennbarkeit ist es notwendig, dass folgendes gilt: ∃e ∈ E i,j mit ∀j ∈
{1, . . . , |D|}. Dies bedeutet, dass es ein Datentupel gibt, welches in allen Mengen E i,j
enthalten ist. Das weist darauf hin, dass dieses Datentupel, diese Variable, entweder
63

Kapitel 5. Identikation von Fraud in Geschäftsprozessen
in allen Pfaden des originalen Prozesses enthalten ist, aber im Pfad durch den Fraud-
Prozess fehlt, oder dass es ausschlieÿlich im Pfad durch den Fraud-Prozess, nicht aber
im originalen Prozess vorhanden ist.
Fraud ist erkennbar
Nachdem nun sowohl die sichere Erkennbarkeit als auch die nicht Erkennbarkeit deniert
ist, lässt sich in allen anderen Fällen das Fraud-Szenario auch erkennen, allerdings
ist dafür wesentlich mehr Aufwand notwendig und das Ergebnis wird nicht eindeutig
sein. Dies soll bedeuten, dass es einige, fälschlicherweise als Fraud klassizierte, Fälle
enthalten wird. Zusätzlich ist die Indikatorerstellung wesentlich komplexer, da die
Indikatorerstellung pfadweise vorgenommen werden muss. Dabei gelten auch auf dieser
nächsten Detaillierungsstufe dieselben Kriterien für eine sichere Erkennbarkeit des
Fraud-Szenarios.
5.5. Verarbeitung von Untersuchungsresten
In diesem Abschnitt wird die Weiterbehandlung der Datensätze innerhalb der Menge
¯D, diese entspricht der Komplementärmenge zur Menge der als prozesskonform
markierten Datensätze D, betrachtet. Im Unterschied zur Behandlung der Daten aufgrund
eines modellierten Fraud-Szenarios, wie es im Kapitel 5.4 beschrieben wurde,
gilt es in diesem Fall, den von der Markierung durch die Pfade des Original-Prozesses
übriggebliebenen Datensätzen eine Bedeutung zu geben und sie in die Gruppen fraudverdächtig
oder erklärbar aufzuteilen. So können in ¯D Datensätze existieren, welche
Sonderfälle repräsentieren, die bei der Modellierung vergessen oder absichtlich, aus
Vereinfachungsgründen, nicht modelliert wurden. Diese Datensätze müssen gefunden
und auf ihre Kompatibilität mit den Sonderprozessen überprüft werden, um sie so
der Menge D, falls eine Kompatibilität vorliegt, zuzuordnen oder in der Menge ¯D
zu belassen. Wurde auch dieser Validierungsschritt abgeschlossen, kann davon ausgegangen
werden, dass die Datensätze, welche noch in ¯D verblieben sind, potentielle
Fraud-Ereignisse repräsentieren.
Diese Datensätze müssen nun einer detaillierten manuellen Prüfung unterzogen werden
müssen, um Muster festzustellen oder sie aufgrund erklärbarer Einzelereignisse ausltern
zu können. Basierend auf den Erkenntnissen dieser manuellen Mustererkennung
können neue Blacklisting Indikatoren erzeugt werden, die alle Datensätze, welche das
erkannte charakteristische Muster aufweisen, auf den Datenbeständen nden. Ist das
erkannte Muster so charakteristisch, dass ein dadurch erstellter Blacklisting-Indikator
keine weiteren als die bekannten potentiell fraudverdächtigen Ereignisse liefert, kann
64

5.6. Ausführliches Beispiel
auch ein Whitelisting-Indikator erzeugt werden, der auch zukünftig ein qualitativ hochwertiges
spezielles Ergebnis erzeugen wird.
5.6. Ausführliches Beispiel
An dieser Stelle werden anhand des in Kapitel 1.3 eingeführten Szenarios die verschiedenen
Schritte des Vorgehensmodells ausführlich gezeigt und Besonderheiten erläutert.
Beginnend mit dem ersten Schritt wird aus Interviewdaten ein Geschäftsprozessdiagramm
erstellt. Dies enthält in der ersten Version noch keine Informationsobjekte
(vergleiche Abbildung 5.10), da diese Version zunächst dazu dient, in Zusammenarbeit
mit dem Interviewpartner das Modell zu verizieren und festzustellen, ob alle
wichtigen Prozessschritte abgebildet wurden. Die Programmausgaben im Folgenden
beziehen sich nur auf den in Abbildung 5.10 grau schattierten Pfad. Alle weiteren Details
und die vollständigen Programmausgaben zu diesem Beispiel sind in Anhang A
zu nden.
Abbildung 5.10.: Geschäftsprozessdiagramm ohne Informationsobjekte
Im Anschluss an diesen Verikationsschritt wird die Datenhaltung näher betrachtet.
Besonderes Augenmerk liegt dabei auf der Fragestellung, wie Daten, welche innerhalb
des Prozesses entstehen, gespeichert werden. Das Ergebnis dieser Betrachtung gibt
65

Kapitel 5. Identikation von Fraud in Geschäftsprozessen
Aufschluss über die Datenbank- oder Logdateistrukturen, welche anschlieÿend in die
Modellierung der Informationsobjekte einieÿen. Hierbei muss für die automatisierte
Auswertung eine spezielle Syntax, welche in Abschnitt 5.2.1 deniert wurde, beachtet
werden. Diese Syntax ermöglicht es, Beziehungen zu einzelnen Tabellen und Feldern
innerhalb einer Datenbank sowie Datenbankschlüssel und Funktionsauswertungen zu
modellieren. Auf das Beispielszenario angewendet, entsteht das, in Abbildung 5.11
gezeigte Diagramm.
Abbildung 5.11.: Geschäftsprozessdiagramm mit Informationsobjekten
Nachdem dieses wesentlich detaillreichere Diagramm erstellt wurde, sollte nochmals
ein Abstimmungsschritt folgen, um sicher zu gehen, dass bei der Erstellung keine Fehler
modelliert worden sind. Das fertiggestellte Diagramm muss, falls es nicht bereits
mit dem Werkzeug Dia [BML09a, BML09b] modelliert wurde, in das XML basierte
Dateiformat dieses Modellierungsswerkzeugs transformiert werden. Weitere Dateiformate
werden zur Zeit noch nicht unterstützt, können aber bei Bedarf kurzfristig in das
Auswertungsskript (siehe Anhang B) integriert werden. Sobald diese Vorbereitungen
abgeschlossen sind, wird das Auswertungsskript gestartet, welches, unter Berücksichtigung
der in Abschnitt 5.2 beschriebenen Behandlung der verschiedenen Diagrammelemente,
die Pfade im Geschäftsprozessdiagramm sucht und entsprechend aufbereitet
66

5.6. Ausführliches Beispiel
ausgibt.
Passend zum Beispiel ist nachfolgend ein Pfad des Prozesses dargestellt.
1 Pfad 1:
2 ID: O0 - Text: #Kartenstorno gewünscht# (E)
3 ID: O18 - Text: #Kartendaten einlesen# (F)
4 ID: O19 - Text: #Kartendaten eingelesen# (E)
5 ID: O1 - Text: #Zahlart wählen# (F)
6 ID: O4 - Text: Operator: XOR (Op)
7 ID: O24 - Text: #Bar# (E)
8 ID: O26 - Text: #Barauszahlung an den Kunden vornehmen# (F)
9 ID: O10 - Text: Operator: XOR (Op)
10 ID: O14 - Text: #Storno durchgeführt# (E)
Auistung 5.1: Alle zu einem Pfad durch das aEPK gehörenden Elemente
Die mit ID bezeichnete Zeichenfolge stellt einen eindeutigen Identikator des jeweiligen
Zeichenobjekts dar. Anhand des Text-Elements des jeweiligen Zeichenobjekts
lassen sich die ausgegebenen Objekte eines Pfades jenen im Diagramm zuordnen (der
Elementtext wird in #-Zeichen eingeschlossen ausgegeben). Hierdurch ist eine abschlieÿende
Verikation der Skriptausgabe möglich. Die Zeichen innerhalb der Klammern
am Ende einer jeden Zeile zeigen an, um welche Art Objekt es sich handelt. So steht (E)
für Ereignis, (F) für Funktion und (Op) für Operator. Auf dem jeweiligen Pfad enthaltene
Schleifen würden an der Stelle, an welcher die Schleife beginnt in den Pfadablauf
eingeblendet und durch die einleitende Zeichenfolge -----Loop Start----- und
die abschlieÿende Zeichenfolge -----Loop Ende------ vom übrigen Pfadablauf
sichtbar getrennt.
Nachdem das Skript als Zwischenschritt alle Pfade berechnet hat, können als nächstes
zu jedem Pfad die jeweiligen Informationsobjekte berechnet werden. Bei dieser
Berechnung gehen jegliche Zuordnungs- und Reihenfolgeinformationen der Pfade verloren.
Das Ergebnis dieser Auswertung kann, angewendet auf das Beispiel, nachfolgend
betrachtet werden.
1 Informationsobjekte Pfad 1:
2 a => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’kdnr’}
3 c => {’table’:’tb1’, ’wert’:"’storniert’", ’datensatz’:’1’,´’field’:’
status’}
4 b => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’auftragsnr’}
5 e => {’table’:’tb3’, ’datensatz’:’2’, ’field’:’kontonr’}
6 d => {’table’:’tb3’, ’wert’:’a’, ’datensatz’:’2’, ’field’:’kdnr’}
7 g => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’auftrag_neu’}
8 f => {’table’:’tb3’, ’datensatz’:’2’, ’field’:’blz’}
9 i => {’table’:’tb1’, ’wert’:"’Storno’", ’datensatz’:’3’, ’field’:’status
’}
10 h => {’table’:’tb1’, ’wert’:’b’, ’datensatz’:’3’, ’field’:’auftragsnr’}
11 k => {’table’:’tb2’, ’wert’:"’bar’", ’datensatz’:’4’, ’field’:’zahlart’}
12 j => {’table’:’tb1’, ’wert’:’a’, ’datensatz’:’3’, ’field’:’kdnr’}
67

Kapitel 5. Identikation von Fraud in Geschäftsprozessen
13 l => {’table’:’tb2’, ’wert’:’b’, ’datensatz’:’4’, ’field’:’auftragsnr’}
Auistung 5.2: Abstrakte Datenmenge des manipulierten Barzahlungsprozesses
Jedem neuen Informationsobjekt wird innerhalb des Diagramms eine Variable zugewiesen,
mit deren Hilfe im weiteren Verlauf des Prozesses der zugewiesene Wert referenziert
werden kann. Das bedeutet gleichzeitig, dass jede Variable für ein Datenfeld
innerhalb einer Datenbank oder einer Logdatei steht und somit für die nähere Beschreibung
des zugehörigen Datenfeldes eindeutig ist. Dementsprechend können einer
Variablen zusätzlich Attribute, beispielsweise table, wert, datensatz, eld und schluessel,
wie in der Ausgabe gezeigt, zugewiesen werden. Diese Attribute enthalten die innerhalb
des Diagramms denierten Werte, beziehungsweise denierte und zugewiesene
Funktionen. Aktuell werden nur die rudimentären Funktionen Addition, Subtraktion,
Multiplikation und Division unterstützt. Allerdings ist eine Erweiterung durch komplexere
Funktionen denkbar. Hierfür müsste zusätzlich eine Syntax entworfen und in
die Skripte eingebunden werden, welche die Denition dieser komplexeren Funktionen
innerhalb des Diagramms ermöglicht.
Ist das Vorgehensmodell an diesem Schritt angelangt, so existiert nun die in Abschnitt
5.1.1 denierte abstrakte Datenmenge, welche direkte Voraussetzung für die
Generierung einer SQL-Anfrage ist. Diese Anfragen werden, basierend auf den Detailangaben
der Variablen, für jeden der Pfade generiert und sind dafür geeignet, alle
passenden Datensätze aus der Datenbank zu ltern.
Für das betrachtete Beispiel werden die folgenden Anfragen durch ein weiteres Skript
automatisch generiert:
1 #Anfrage zu Pfad 1:
2 SELECT *
3 FROM tb1 a1, tb1 a3, tb3 a2, tb2 a4
4 WHERE a1.status = ’storniert’ AND a2.kdnr = a1.kdnr
5 AND a3.status = ’Storno’ AND a3.auftragsnr = a1.auftragsnr
6 AND a4.zahlart = ’bar’ AND a3.kdnr = a1.kdnr
7 AND a4.auftragsnr = a1.auftragsnr
Auistung 5.3: SQL-Anweisung zur Selektion von Datensätzen
Als Ergebnis werden Datenbanktabellen zurückgeliefert, die alle Datensätze enthalten,
welche die entsprechenden Einschränkungen aufweisen. Hier ist die Auswertung des
anfänglich denierten Prozesses abgeschlossen. Für jeden Pfad durch das Diagramm
wurden die zugehörenden Datensätze ausgegeben.
Zur Aufdeckung wirtschaftskrimineller Straftaten müssen an dieser Stelle weitere Auswertungsschritte
vorgenommen werden, da bisher nur die prozesskonformen Datensätze
ausgewertet wurden. Um aus den gesamten Datenmengen die Datensätze zu erhalten,
welche nicht prozesskonform sind, muss vom gesamten Datenbestand die prozesskonforme
Datenmenge (D) abgezogen werden, so dass man die nicht prozesskonforme
68

5.6. Ausführliches Beispiel
Datenmenge ¯D und damit die Komplementärmenge, bezogen auf den gesamten Datenbestand,
erhält. Diese Aufteilung der Datensätze wird dadurch realisiert, dass mittels
einer SQL-Anfrage jeder gefundene Datensatz markiert wird. Hierzu ist es erforderlich,
dass jeder Tabelle eine neue Spalte hinzugefügt wird, welche die Markierung in Form
eines Wahrheitswertes aufnimmt.
Für den ersten Pfad des Beispiels sieht diese Anfrage wie folgt aus. Für alle weiteren
Pfade wird die Anfrage analog erzeugt.
1 UPDATE tb1 a1, tb1 a3, tb3 a2, tb2 a4
2 SET a1.mark = true, a2.mark = true, a3.mark = true, a4.mark = true
3 WHERE a1.status = ’storniert’ AND a2.kdnr = a1.kdnr
4 AND a3.status = ’Storno’ AND a3.auftragsnr = a1.auftragsnr
5 AND a4.zahlart = ’bar’ AND a3.kdnr = a1.kdnr
6 AND a4.auftragsnr = a1.auftragsnr
Auistung 5.4: SQL-Anweisung für die Markierung von Datensätzen
Ist diese Markierung für alle Pfade des Diagramms durchgeführt, so können mittels
einer weiteren SQL-Anfrage alle unmarkierten Datensätze herausgesucht werden. Diese
Datensätze können anschlieÿend kategorisiert und somit auf Auälligkeiten untersucht
werden. Das Vorgehen hierzu wird in Abschnitt 5.5 beschrieben.
5.6.1. Fraud-Szenarien am Beispiel
Im Abschnitt 1.3 werden neben dem eigentlichen Beispielszenario auch zwei Manipulationsszenarien
beschrieben. Diese werden hier ausführlich betrachtet und es wird
anhand der Beispiele erläutert, wie entschieden werden kann, ob ein Fraud-Szenario
erkennbar ist oder nicht.
Manipulierte Überweisung
Beginnend mit der ersten Manipulation wird auch hier die erste EPK-Modellierung
um die aEPK konforme Modellierung der Informationsobjekte erweitert. In Abbildung
5.12, welche nur die zusätzlich zu Abbildung 5.11 enthaltenen Informationsobjekte
modelliert, ist durch die grau schattierten Informationsobjekte zu sehen, dass bei der
Manipulation mittels Lastschrift zusätzliche Datensätze erzeugt werden.
Das Auswertungsskript erzeugt aus dem vollständigen Prozessmodell mit allen Informationsobjekten
die folgende abstrakte Datenmenge, wobei hier auf die vollständige
Darstellung der Pfade 1 und 3 verzichtet wurde, da an diesen Stellen keine Manipulationen
vorgenommen wurden und somit die Darstellungen von oben genutzt werden
können.
69

Kapitel 5. Identikation von Fraud in Geschäftsprozessen
Abbildung 5.12.: Prozessmanipulation mit Informationsobjekten - Überweisung
1 Pfad 1:
2 a,b,c,d,e,f,g,h,i,j,k,l
4 Pfad 2
5 a,b,c,d,e,f,g,h,i,j,k,l,m,n
6 o => {’table’:’tb3’, ’datensatz’:’5’, ’field’:’kontonr’}
7 q => {’table’:’tb3’, ’wert’:’a’, ’datensatz’:’5’, ’field’:’kdnr’}
8 p => {’table’:’tb3’, ’datensatz’:’5’, ’field’:’blz’}
9 s => {’table’:’tb3’, ’datensatz’:’6’, ’field’:’blz’}
10 r => {’table’:’tb3’, ’datensatz’:’6’, ’field’:’kontonr’}
11 u => {’table’:’tb3’, ’wert’:’v’, ’datensatz’:’5’, ’field’:’aendDatum’}
12 t => {’table’:’tb3’, ’wert’:’a’, ’datensatz’:’6’, ’field’:’kdnr’}
13 w => {’table’:’tb3’, ’wert’:’v’, ’datensatz’:’6’, ’field’:’aendDatum’}
14 v => {’table’:’tb2’, ’datensatz’:’4’, ’field’:’aendDatum’}
16 Pfad 3:
17 a,b,c,d,e,f,g,h,i,j,k,l
Auistung 5.5: Abstrakte Datenmenge des manipulierten Überweisungsprozesses
70

5.6. Ausführliches Beispiel
Mit Hilfe dieser abstrakten Datenmenge und dem in Abschnitt 5.4.1 erläuterten Vorgehen,
wird nun eine Menge Diff erzeugt, welche dabei unterstützt, zu entscheiden,
ob dieses Fraud-Szenario erkennbar ist oder nicht. Die Menge Diff wird durch einen
paarweise erfolgenden Vergleich der abstrakten Datenmengen der einzelnen Pfade erzeugt
und sieht für das behandelte Beispiel wie folgt aus:
Diff = {Diff ˜P1
, Diff ˜P2
, Diff ˜P3
}
Diff ˜P1
= {E 1,1 , E 1,2 , E 1,3 }
Diff ˜P2
= {E 2,1 , E 2,2 , E 2,3 }
Diff ˜P3
= {E 3,1 , E 3,2 , E 3,3 }
E 1,1 = ∅
E 1,2 = {k, l, m, n}
E 1,3 = {k, l}
E 2,1 = {k, l, m, n, o, p, q, r, s, t, u, v, w}
E 2,2 = {o, p, q, r, s, t, u, v, w}
E 2,3 = {k, l, m, n, o, p, q, r, s, t, u, v, w}
E 3,1 = {k, l}
E 3,2 = {k, l, m, n}
E 3,3 = ∅
Anhand dieser Menge Diff und den Ergebnissen aus Abschnitt 5.4.1 kann man nun
folgern, dass das Fraud-Szenario im zweiten Pfad auf jeden Fall innerhalb der Daten
erkannt werden kann, da die Elemente o, p, q, r, s, t, u, v und w in allen Mengen E 2,j
mit j ∈ {1, 2, 3} enthalten sind. Zusätzlich eignen sich diese Elemente hervorragend
als Basis für einen neuen Indikator.
Manipulation Barauszahlung
Bei der zweiten in Abschnitt 1.3 beschriebenen Manipulation des Einführungsbeispiels
werden dieselben Schritte angewendet wie bei der Manipulation der Überweisung im
vorangegangenen Unterabschnitt. Wie die Abbildung 5.13 zeigt, beinhaltet die Manipulation
(grau schattiert) keine geänderten Informationsobjekte. Die eingezeichneten
Informationsobjekte sind ebenfalls für die alternative Funktion Barauszahlung an den
Kunden vornehmen vorhanden.
An der Grak kann bereits erkannt werden, dass ein Pfad durch das Diagramm hinzugekommen
ist. Wird nun das Auswertungsskript darauf angewendet, zeigt sich, dass
der zusätzliche Pfad identisch mit dem vormaligen Pfad 1 ist. Im Folgenden wird
das aggregierte Ergebnis des Auswertungsskriptes dargestellt, wobei auch hier nur der
zusätzliche Pfad 4 detailliert aufgeschlüsselt wird.
1 Pfad 1:
2 a,b,c,d,e,f,g,h,i,j,k,l
71

Kapitel 5. Identikation von Fraud in Geschäftsprozessen
Abbildung 5.13.: Prozessmanipulation mit Informationsobjekten - Barauszahlung
4 Pfad 2
5 a,b,c,d,e,f,g,h,i,j,k,l,m,n
7 Pfad 3:
8 a,b,c,d,e,f,g,h,i,j,k,l
10 Pfad 4:
11 a => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’kdnr’}
12 c => {’table’:’tb1’, ’wert’:"’storniert’", ’datensatz’:’1’, ’field’:’
status’}
13 b => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’auftragsnr’}
14 e => {’table’:’tb3’, ’datensatz’:’2’, ’field’:’kontonr’}
15 d => {’table’:’tb3’, ’wert’:’a’, ’datensatz’:’2’, ’field’:’kdnr’}
16 g => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’auftrag_neu’}
17 f => {’table’:’tb3’, ’datensatz’:’2’, ’field’:’blz’}
18 i => {’table’:’tb1’, ’wert’:"’Storno’", ’datensatz’:’3’, ’field’:’status
’}
19 h => {’table’:’tb1’, ’wert’:’b’, ’datensatz’:’3’, ’field’:’auftragsnr’}
20 k => {’table’:’tb2’, ’wert’:"’bar’", ’datensatz’:’4’,’field’:’zahlart’}
21 j => {’table’:’tb1’, ’wert’:’a’, ’datensatz’:’3’,’field’:’kdnr’}
72

5.6. Ausführliches Beispiel
22 l => {’table’:’tb2’, ’wert’:’b’, ’datensatz’:’4’,’field’:’auftragsnr’}
Auistung 5.6: Abstrakte Datenmenge des manipulierten Barzahlungsprozesses
Um eine verlässliche Aussage über die Aundbarkeit des untersuchten Fraud-Szenarios
zu treen, muss wiederum die Menge Diff über den paarweise erfolgenden Vergleich
der Pfade erstellt werden. Das Ergebnis dieser Zusammenführung der Unterschiede
zwischen den einzelnen Pfaden des Fraud-Prozesses und des Referenzprozesses ist im
Anschluss zu nden.
Diff = {Diff ˜P1
, Diff ˜P2
, Diff ˜P3
, Diff ˜P4
}
Diff ˜P1
= {E 1,1 , E 1,2 , E 1,3 }Diff ˜P2
= {E 2,1 , E 2,2 , E 2,3 }
Diff ˜P3
= {E 3,1 , E 3,2 , E 3,3 }Diff ˜P4
= {E 4,1 , E 4,2 , E 4,3 }
E 1,1 = ∅
E 1,2 = {k, l, m, n}
E 1,3 = {k, l}
E 2,1 = {k, l, m, n}
E 2,2 = ∅
E 2,3 = {k, l, m, n}
E 3,1 = {k, l}
E 3,2 = {k, l, m, n}
E 3,3 = ∅
E 4,1 = ∅
E 4,2 = {k, l, m, n}
E 4,3 = {k, l}
Anhand der Menge Diff lässt sich jetzt ablesen, dass alle vier Elemente Diff ˜Pi
mit i ∈
{1, 2, 3, 4} von Diff einmal die leere Menge (∅) enthalten. Dies deutet darauf hin, dass
es einen Pfad innerhalb des manipulierten Prozesses gibt, der mit einem Pfad aus dem
Referenzprozess identisch ist, was direkt dazu führt, dass keine Aussage mehr darüber
möglich ist, ob der Referenzprozess oder der manipulierte Prozess durchlaufen wurde.
Somit kann diese Manipulation auf den Daten nachträglich nicht ohne zusätzliche
Informationen erkannt werden. Die Denition und nähere Erläuterungen der Menge
Diff ndet sich in Kapitel 5.4.1.
73

Kapitel 6.
Weitere Datenmodellierungssprachen
Neben den Ereignisgesteuerten Prozessketten (EPK) gibt es weitere Notationen, welche
für die Prozessmodellierung verbreitet sind oder zukünftig weit verbreitet sein
werden. Da für die Umsetzung des Vorgehensmodells weniger die Modellnotation als
die Tatsache, dass theoretisch fundiert Daten modelliert werden können, von Bedeutung
ist, wurden in diesem Abschnitt zwei bekannte Notationen auf ihre Tauglichkeit
als Modellnotation hin untersucht.
6.1. Business Process Modelling Notation (BPMN)
Business Process Modelling Notation, kurz als BPMN bezeichnet, ist eine seit knapp
fünf Jahren entwickelte Beschreibungssprache für Geschäftsprozessmodelle. Im Jahr
2004 wurde die erste Spezikation 1.0 [Gro04] von der Object Modelling Group (OMG)
herausgegeben. Die OMG ist nach eigenen Angaben das weltweit führende Konsortium
im Bereich Software. Dieses Konsortium bemüht sich darum lieferantenunabhängige
Schnittstellendenitionen zu erstellen, um so den Unternehmen bei der internen
Integration zu helfen. Eines der Ergebnisse dieser Gruppe ist die Beschreibungssprache
BPMN, für welche inzwischen eine Ausschreibung für die Version 2.0
vorliegt [Gro08a]. BPMN wurde vorrangig entwickelt, um ähnlich wie EPKs eine intuitiv
lesbare Beschreibungssprache darzustellen, welche von allen Prozessbeteiligten
verstanden und angewendet werden kann. Zusätzlich stellt BPMN eine Interpretation
für XML-basierte Ausführungsssprachen von Business Process Managment Systemen
(BPEL4WS) bereit.
Diese Modellierungssprache besteht aus Flussobjekten (Ereignisse, Aktivitäten und
Gateways), Verbindungsobjekten (sequenzielle Verbindungen, Nachrichtenverbindungen
und Assoziationen), Verantwortlichkeitsbereichen und Artefakten (Datenobjekte
und Gruppen). Mit Hilfe dieser vier Elementkategorien lassen sich nun beliebige Geschäftsprozesse
modellieren. Zusätzlich lassen sich diese Prozesse durch den Einbau von
zeitverzögernden Objekten oder der Modellierung des Nachrichtenverkehrs zwischen
75

Kapitel 6. Weitere Datenmodellierungssprachen
einzelnen Modellelementen beliebig verfeinern. Detailliertere Beschreibungen und exakte
Elementdarstellungen können der Spezikation [Gro08b] entnommen werden. Die
seit Mitte 2007 verfügbare Ausschreibung, welche zu einer Erweiterung von BPMN 1.2
auf BPMN 2.0 führen soll, erwähnt als Hauptforschungsgebiete die Umwandlung von
BPMN in eine einheitliche Modellaustauschsprache Business Process Denition Metamodel
(BPDM) sowie eine abstrakte Darstellung des graphischen Layouts.
Aus dieser kurzen Zusammenfassung der Inhalte von BPMN ergibt sich in Bezug
auf das Untersuchungsgebiet in dieser Arbeit noch kein signikanter Unterschied zu
Ereignisgesteuerten Prozessketten. Natürlich bietet BPMN wesentlich mehr Modellierungselemente
und eine detaillreichere Darstellungsweise, weil einzelne Elemente spezialisierte
Unterelemente enthalten. Allerdings fehlt ebenso wie in der Ursprungsform
der Ereignisgesteuerten Prozessketten eine Modellierung von Datenüssen durch das
Diagramm. Die Autoren von BPMN weisen deutlich darauf hin, dass dies nicht Ziel
der Modellierungssprache ist. Trotzdem bietet BPMN für die reine Modellierung ein
deutlich breiteres Elementspektrum, was dazu führt, dass BPMN zukünftig auch in
den Produkten der SAP, dem Marktführer im Bereich Unternehmenssoftware, deutlich
an Einuss, im Hinblick auf Geschäftsprozessmodellierung, gewinnen wird. Bereits
Mitte 2008 wurden in den Netweaver von SAP zwei Anwendungen integriert, die das
Modellieren von Diagrammen innerhalb einer Entwicklungsumgebung erlauben. Zusätzlich
zu dieser Modellierbarkeit existieren weitere Anwendungen, welche es dem
Programmentwickler erlauben, die gestalteten BPMN Diagramme direkt auszuführen
und so unmittelbar für die Benutzer verfügbar zu machen. Eventuelle Interaktionen
mit einem Backend-System werden durch XML-basierte Webschnittstellen bereitgestellt
[AG08].
6.2. Unied Modeling Language
(UML)-Aktivitätsdiagramme
UML-Aktivitätsdiagramme sind Teil der UML-Diagrammfamilie, welche von der Object
Management Group (OMG) standardisiert wurde und aktuell weiterentwickelt
wird. Verfügbar ist die UML-Spezikation in der Version 2.2 [Gro09a] und widmet
sich vor allem der strukturierten Softwareentwicklung. So existieren neben dem Aktivitätsdiagramm
noch 13 weitere Diagramm-Arten, welche alle dazu dienen, Abläufe
und Struktur einer Softwareanwendung zu beschreiben und visuell darzustellen. Speziell
Aktivitätsdiagramme bieten die Möglichkeit, Abläufe detailliert und strukturiert
darzustellen, weshalb sie auch zur Darstellung von Geschäftsprozessen geeignet sind.
Im Gegensatz zu EPKs wurden sie aber nicht speziell zu diesem Zweck entwickelt.
Aktivitätsdiagramme verfügen genau wie EPKs über Symbole, mit denen Aktivitäten
modelliert werden können. Des Weiteren gibt es Elemente, mit denen AND-,
76

6.3. Message Sequence Charts
XOR- und OR-Verknüpfung dargestellt werden können. Auÿerdem gibt es innerhalb
der UML-Aktivitätsdiagramme eine natürliche Ordnung, was bedeutet, dass mit Hilfe
von Pfeilen die Aktivitäten aneinander gereiht werden und so eine implizite, zeitliche
Abfolge haben. Zusätzlich zu diesen grundlegenden Symbolen existieren mögliche
Darstellungsformen für Datenobjekte und den Datenaustausch zwischen zwei Aktivitäten.
Neben dieser Möglichkeit Datenobjekte und -üsse zu modellieren, gibt es seit
der Version 2.0 einen Datenspeicher, im Englischen Data Store Node genannt. Mithilfe
dieses Datenspeichers und zusätzlicher Bemerkungen an den Verbindungspfeilen können
inzwischen auch Datenüsse und die Verbindung zur dauerhaften Datenhaltung
modelliert werden. Allerdings gibt es auch hier noch keine explizite Modellierungsmöglichkeit
für die Datenveränderung. Behelfsweise könnte dies an den Verbindungspfeilen
durch Bemerkungen zusätzlich modelliert werden, was einer noch nicht vorhandenen
theoretischen Fundierung bedürfte. Somit ist, was den Funktionsumfang betrit, das
UML-Aktivitätsdiagramm bis auf die Modellierung von Datenveränderungen eine Alternative
zu aEPKs. Allerdings gibt es noch keine theoretische Betrachtung der Datenüsse,
was eine Voraussetzung für den aEPK-äquivalenten Einsatz ist. Bezüglich
der Verständlichkeit sind beide Notationen gleichwertig. UML-Diagramme werden im
Bereich Softwareentwicklung sehr stark eingesetzt, weshalb eine weit gröÿere Anzahl
Werkzeuge, welche die Erstellung dieser Diagramme sowohl in der Modellierung als
auch in der Syntaxprüfung unterstützt existiert. Zusätzlich können diese so erstellten
Aktivitätsdiagramme in den meisten Fällen automatisiert weiterverarbeitet werden,
was einen Vorteil gegenüber EPKs darstellt.
6.3. Message Sequence Charts
Ein Message Sequence Chart (MSC) [Uni04] ist ein für die Darstellung von Kommunikationsprozessen
von der International Telecommunicaion Union (ITU) denierter
Standard, welche ihn pegt und weiterentwickelt. Aus der Sicht von Geschäftsprozessen
eignet sich die Darstellungweise, die das MSC vorsieht nur bedingt. So müssten
Kommunikationspartner deniert werden, zwischen denen Nachrichten ausgetauscht
werden können. Behelfsweise könnte man diese Kommunikationspartner durch die
Funktionen innerhalb eines Geschäftsprozesses ersetzen und so eine Kommunikation
zwischen diesen Funkionen modellieren. Abgesehen davon bietet die Modellierungssprache
aber alles, was benötigt wird. So ist es möglich, Daten zu modellieren, sogar
die Verknüpfungen von einzelnen Variablen mittels der grundlegenden mathematischen
Operationen und der Einsatz von selbstdenierten Funktionen ist bereits im
Modell vorgesehen. Ebenso gibt es eine Möglichkeit alternative Verläufe darzustellen.
Dies ist sogar abhängig von einem Variablenwert modellierbar. Ein weiterer Aspekt
dieser Notation ist der, dass sowohl eine graphische als auch eine rein Text-basierte
77

Kapitel 6. Weitere Datenmodellierungssprachen
Modellerstellung möglich ist. Diese textuelle Modelldenition ähnelt sehr stark einer
Programmiersprache.
Somit würde diese Sprache alle Voraussetzungen erfüllen. Leider ist die Darstellungsweise
sehr technisch und so für nicht technische Benutzergruppen nicht intuitiv verständlich.
Dagegen ist die Versorgung mit Softwarewerkzeugen, die diese Modelliersprache
beherrschen sehr gut. So existieren neben kommerziellen Werkzeugen auch
solche, die auf Open-Source-Basis entwickelt und verbreitet werden.
78

Kapitel 7.
Zusammenfassung
Zum Abschluss dieser Arbeit wird das erarbeitete Konzept kritisch betrachtet. Auÿerdem
werden Denkanstöÿe für zukünftige Forschungen in diesem Bereich und Weiterentwicklungen
des Vorgehensmodells gegeben.
7.1. Zusammenfassung und Ergebnis
In dieser Arbeit wurde als theoretische Grundlage des Vorgehensmodells eine Erweiterung
der Prozessmodellierungssprache EPK entwickelt. Die hierbei betrachtete Theorie
macht es erst möglich, innerhalb des Vorgehensmodells Daten als direkten Bestandteil
des Geschäftsprozessmodells zu modellieren und nicht wie in der Aris-Architektur
[Sch97] vorgesehen auf die Dreiteilung zwischen Daten, Prozess und Organisation zu
bestehen. Zusätzlich wurde für die entwickelte algebraische Ereignisgesteuerte Prozesskette
eine Transformation hin zu algebraischen Petri-Netzen deniert. Somit ist die
Möglichkeit gegeben, das Geschäftsprozessmodell mit Hilfe der Petri-Netz-Theorie zu
simulieren und auf Semantik-Probleme zu untersuchen. Darauf aufbauend wurde das
in Kapitel 5 beschriebene Vorgehensmodell entwickelt, mit dessen Hilfe basierend auf
den beschriebenen Geschäftsprozessen, eine Konformitäts-Analyse durchgeführt werden
kann. Dies bedeutet, dass die durch den Prozess erzeugten elektronischen Daten
mit jenen, durch einen ordnungsgemäÿen Ablauf des Prozesses erzeugten, abgeglichen
werden. Anhand dieses Abgleichs lassen sich die elektronischen Daten in prozesskonforme
und in nicht prozesskonforme Daten trennen. Die nicht prozesskonformen und
damit Fraud-verdächtigen Daten werden anschlieÿend weiter bearbeitet, indem sie auf
Muster hin untersucht werden, welche bei der Aundung dieser Datensätze auf Daten
desselben Prozesses helfen können. Dies ist insofern ein groÿer Fortschritt, als dass
anhand dieser Muster das Fraud-Szenario rekonstruiert werden kann und so wichtige
Erkenntnisse zum Vorgehen des Täters und dadurch auch Erkenntnisse zum sinnvollen
Einsatz von zusätzlichen Kontrollen gewonnen werden können.
79

Kapitel 7. Zusammenfassung
Für das reine Vorgehensmodell wurde eine Skriptsammlung, diese wird im Anhang B
ausführlich beschrieben, entwickelt, welche angewendet auf ein speziell vorbereitetes
Prozessmodell die automatisierte Sortierung hinsichtlich der Prozesskonformität übernimmt.
Zusätzlich wurde zu Vergleichszwecken eine Analyse der Projektdaten mittels
der bisher von PwC angewendeten Indikatormethode durchgeführt und Indikatoren
anhand der Prozessbeschreibung ohne Kenntnis der Datenmenge entwickelt, umgesetzt
und auf der Datenmenge ausgewertet.
Die vorliegende Arbeit ist im Zuge eines Fraud-Analyse-Projekts der Wirtschaftsprüfungsgesellschaft
PwC entstanden. Dementsprechend wurden beide Vorgehensweisen,
sowohl die indikatorbasierte Analyse mit herkömmlicher Indikatorndung als auch mit
prozessbezogener Indikatorndung praktisch umgesetzt. Leider können konkrete Ergebnisse
aufgrund von Verschwiegenheitsvereinbarungen hier nicht aufgeführt werden.
Allerdings wird eine Zusammenfassung und Bewertung der Chancen und Einschränkungen
durch eine prozessbasierte Fraud-Analyse gegeben. Hinsichtlich des Arbeitsaufwandes
bei der Erstellung von Indikatoren bei einem vollkommen unbekannten Prozess
sind beide Verfahren, die klassische Indikatorndung und die prozessbasierte Analyse,
vergleichsweise aufwändig. Bei beiden Verfahren muss eine Prozessbeschreibung mit
anschlieÿender Prozessanalyse durchgeführt werden. Auÿerdem muss in beiden Fällen
die Datenstruktur näher betrachtet werden. Der groÿe Unterschied besteht darin, dass
bei der klassischen Indikatordenition aufgrund von Fachwissen und Erfahrung ein
Indikator geschaen und ausgewertet wird. Bei der prozessbasierten Analyse wird der
gesamte Indikatordenitionsprozess strukturiert. Einerseits kann durch den Ausschluss
der prozesskonformen Datensätze die Analysemenge deutlich reduziert werden. Die als
nicht prozesskonform klassizierten Datensätze müssen danach ebenfalls mittels Fachwissen
und Erfahrung betrachtet werden. Andererseits besteht die Möglichkeit mittels
der prozessbasierten Analyse in das erstellte Prozessmodell einen erarbeiteten Fraudfall
graphisch mittels des Softwarewerkzeugs Dia[BML09a] hinein zu modellieren und
anschlieÿend auswerten zu lassen. Dieser Ansatz ist der klassischen Indikatordenition
sehr ähnlich, aber insofern einfacher zu realisieren, als dass hierbei nichts programmiert
werden muss, sondern die Zusammenhänge in einem Geschäftsprozessmodell mittels
aEPKs graphisch modelliert werden können. Somit ist zumindest für ein prozessbasiertes
Fraud-Szenario die Vorgehensweise mittels einer prozessbasierten Analyse dem
klassischen Verfahren überlegen. Für alle anderen Fraud-Szenarien, welche nicht direkt
an einen Prozess angelehnt sind, ist das klassische Verfahren vorzuziehen.
Die Chancen des prozessbasierten Ansatzes bestehen darin, eine Prozessabweichung
zuverlässig festzustellen. Eingeschränkt wird der Ansatz allerdings durch die bisher
schlechte Unterstützung von Schleifen innerhalb der Prozesse. Schleifen werden deshalb
noch unzureichend unterstützt, da sie die einzigen kritischen Komponenten innerhalb
der Prozesskette sind. Es kann auf der abstrakten Ebene nicht prognostiziert
werden, wie oft eine Schleife durchlaufen und wie sich die daraus resultierenden Änderungen
der Umgebungsdaten auf jeden einzelnen Datensatz auswirken. Um diese
80

7.2. Ausblick
Auswirkungen sicher darstellen zu können, wäre ein Abrollen der Schleifen notwendig,
was aber wegen der fehlenden allgemeinen Abbruchbedingung sehr aufwändig ist. Eine
zusätzliche Einschränkung ergibt sich aus der Modellierung. Aktuell werden komplexe
Funktionen innerhalb der Modellierung noch nicht unterstützt. Dies ist aber notwendig,
um zum Beispiel einen Wert aufgrund von anderen Attributswerten zu berechnen
und somit den korrekten Zusammenhang zwischen den Attributswerten modellieren
und prüfen zu können, falls der Zusammenhang über die vier Grundrechenarten hinausgeht.
7.2. Ausblick
Neben der Zusammenfassung, im vorherigen Abschnitt, werden im kommenden Abschnitt
Themenfelder aufgezeigt, die während der Bearbeitung aufgefallen sind und
einer weiteren Bearbeitung bedürfen. Hierzu gibt es zu jedem Thema eine kurze Beschreibung
zusammen mit ersten Denkanstöÿen und Lösungsskizzen.
7.2.1. Automatische Modellerstellung
Dies ist eine Idee, welche am Ende des Vorgehensmodells anzusiedeln ist. So kann es
zum Schluss vorkommen, dass Datensätze unmarkiert bleiben, die anschlieÿend auf
Fraud-Merkmale untersucht werden sollten. An dieser Stelle wäre es sehr hilfreich,
wenn aus diesen Datensätzen direkt ein Diagramm generiert werden könnte, ähnlich
der UML-Klassendiagrammgenerierung aus vorhandenem Code. Damit wäre es deutlich
einfacher, die gefundenen Anomalien zu bewerten und einzustufen. Denn in einem
Diagramm lässt sich leichter eine Abweichung im Prozess feststellen und erklären
als anhand der rohen Daten. Hierzu gibt es, bis auf die Veröentlichungen im Hinblick
auf UML-Diagrammgenerierung, noch keine Forschungsergebnisse. Gerade für
die Geschäftsprozessmodellierung wäre ein solches Ergebnis ein enormer Fortschritt
und würde die Klassizierung von Fraudfällen deutlich vereinfachen. Da anhand des
Diagramms Fraud-Merkmale erarbeitet werden könnten, die dazu dienen diese Szenarien
zu klassizieren und somit am Ende eventuell eine Aussage über die Wichtigkeit
einzelner Kontrollen innerhalb bestimmter Prozessschritte möglich wären. Was diese
Modellierung allerdings so kompliziert gestaltet, ist die Tatsache, dass bei vorhandener
abstrakter Datenrepräsentation noch kein direkter Verweis auf den zugrundeliegenden
Pfad durch das Diagramm gegeben is, da anhand konkreter Daten zwar eine
abstrakte Datenrepräsentation erstellt werden kann, aber damit nur ein Pfad durch
ein nicht näher bestimmtes Diagramm bekannt ist. Zusätzlich enthält die in dieser
Arbeit denierte abstrakte Datenmenge keine Informationen über die Reihenfolge der
81

Kapitel 7. Zusammenfassung
Datenobjekte, wie sie im Prozessverlauf erstellt werden. Dieser Umstand erschwert die
automatische Modellgenerierung.
7.2.2. Untersuchung von Schleifen
Im Bereich Schleifen gilt es die Schleifenvariante mit Einuss auf die Umgebungsvariablen
näher zu betrachten. Diese Art der Schleifen innerhalb der aEPKs wurde im
Abschnitt 5.2.3 zwar deniert, allerdings gibt es noch keine Lösung des aufgezeigten
Problems, das darin besteht, dass die Funktionen, innerhalb einer Schleife Variablen
modizieren, welche auÿerhalb der Schleife deniert, beziehungsweise weiter verarbeitet
werden. Aus diesem Grund ist das Ergebnis direkt abhängig von der Anzahl der
Schleifendurchläufe. Da allerdings im Vorgehensmodell von der Anzahl der Durchläufe
abstrahiert wird, besteht hier noch Bedarf eine Lösungsstrategie zu entwicklen.
Ein erster Ansatz könnte sein, die aEPKs abzurollen, was allerdings die Denition
einer maximalen Anzahl Durchläufe voraussetzen würde. Aufgrund der Tatsache, dass
die Anzahl der Schleifendurchläufe innerhalb von Geschäftsprozessen in der Realität
eigentlich immer endlich sind, ist es realistisch aEPKs abrollen zu können. Dieses Abrollen
bedeutet, dass für jede Anzahl Durchläufe zwischen Null und der denierten
Maximalanzahl ein separater Pfad berechnet wird. Dadurch ist es möglich, nacheinander
unterschiedlich lange Schleifendurchläufe und deren Auswirkungen auf die Umgebungsvariablen
innerhalb der abstrakten Datenmenge zu denieren und damit auf
den Datenbeständen aundbar zu machen. Allerdings besteht das Problem bei dieser
Vorgehensweise darin, dass die Pfade und dadurch auch die abstrakten Datenmengen
unnötig kompliziert und groÿ werden, da durch die unterschiedlich langen Schleifen
viele redundante Informationen enthalten sind. Zusätzlich muss eine optimale Maximalanzahl
der Durchläufe gefunden werden, die es einerseits ermöglicht möglichst
wenig Spezialfälle (mehr Durchläufe als die Maximalanzahl), die einer Sonderbehandlung
bedürfen, zu erhalten, und gleichzeitig die Pfadberechnung und -darstellung durch
möglichst wenig Schleifendurchläufe ezient zu halten.
Ein weiterer Ansatz ist, die Eigenschaften der innerhalb der Schleife veränderten Daten
nach Schleifen-Ende zu betrachten. Eventuell lassen sich hierbei zusätzliche Erkenntnisse
gewinnen, die dazu führen, dass es zukünftig doch möglich ist, Schleifen mit
Einuss auf die Umgebungsdaten zu betrachten und auszuwerten.
7.2.3. Erkennung weiterer Eingabeformate
Zur Erstellung der EPKs wurde als Modellierungswerkzeug die Open-Source-Software
Dia [BML09a] verwendet. Die Parse-Routinen der, im Zuge der Arbeit entwickelten,
Skriptsammlung unterstützen aktuell nur das XML -basierte Format, welches von
82

7.2. Ausblick
Dia als Dateiformat verwendet wird. Da Dia nur ein Nischenprodukt und in seinem
Funktionsumfang gegenüber professionellen Werkzeugen wie Microsoft Visio eingeschränkt
ist, wäre es sinnvoll die Unterstützung auf weitere Werkzeuge auszuweiten.
Denn der Vorteil der prozessbasierten Analyse steht und fällt mit der automatisierten
Auswertung von Diagrammen und damit mit der Unterstützung der Modellierungsumgebung.
Problematisch bei dieser Forderung könnte allerdings sein, dass Microsoft
Visio ein proprietäres Dateiformat hat und dieses nicht ohne gröÿeren Aufwand ausgelesen
werden kann. Eventuell lässt sich dieser Herausforderung durch die Exportierbarkeit
der erstellten Diagramme in andere, lesbare Formate begegnen.
83

Literaturverzeichnis
[AG08] SAP AG. SAP kündigt Werkzeuge für das Geschäftsprozessmanagement
an. http://www.sap.com/germany/about/press/
archive/press_show.epx?ID=4316, May 2008. Zuletzt besucht am
11.03.2009.
[Alb09] Conan Albrecht. Picalo. http://www.picalo.org/
whatispicalo.spy, 2009. Zuletzt besucht am 21.04.2009.
[Bil88]
[Bil90]
[Bit09]
[BML09a]
Jonathan Billington. Extending coloured petri nets. Technical Report
UCAM-CL-TR-148, University of Cambridge, Computer Laboratory, September
1988.
Jonathan Billington. Extensions to coloured petri nets and their application
to protocols. Technical Report UCAM-CL-TR-222, University of
Cambridge, Computer Laboratory, 1990.
Gunter Bitz. Risikogesteuerte Prävention und Detektion von Wirtschaftskriminalität
mittels Informationstechnologie. Zeitschrift Risk, Fraud und
Governance (ZRFG), 4(1):4647, 2009.
Hans Breuer, Steen Macke, and Alexander Larsson. Dia für Windows.
http://dia-installer.de/index_de.html, 2009. Zuletzt besucht
am 18.04.2009.
[BML09b] Hans Breuer, Steen Macke, and Alexander Larsson. EDPC Shapes
für Dia. http://dia-installer.de/shapes/edpc/index_de.
html, 2009. Zuletzt besucht am 26.04.2009.
[Brö96]
[BR06]
A. Bröcker. Transformation Ereignisgesteuerter Prozeÿketten in Prädikat-
Transitions-Netze sowie Vergleich der Modellierungstools ARIS-Toolset
und INCOME. Diplomarbeit, Hochschule für Gestaltung, Technik und
Wirtschaft, 1996.
Wilfried Brauer and Wolfgang Reisig. Carl Adam Petri und die Petrinetze.
Informatik Spektrum, 29(5):369381, 2006.
XXI

Literaturverzeichnis
[BS08]
[Bus09]
[BW07a]
[BW07b]
[CS94]
[Del05]
[Fou09]
[Gmb09]
J. Brombacher and Elmar Schwager. Anti-Fraud-Management-Systeme
und Aufgaben der Internen Revision. Zeitschrift Risk, Fraud und Governance
(ZRFG), 3(5):222230, 2008.
Florian Buschbacher. Robin Hood- Phänomen. Persönliches Gespräch
vom 29.04.2009, 2009.
LKA BW. Jahresbericht Korruptionskriminalität. Technical report, Landeskriminalamt
Baden-Württemberg, 2007.
LKA BW. Jahresbericht Wirtschaftskriminalität. Technical report, Landeskriminalamt
Baden-Württemberg, 2007.
R. Chen and August-Wilhelm Scheer. Modellierung von Prozeÿketten mittels
Petri-Netz-Theorie. Forschungsberichte des Instituts für Wirtschaftsinformatik
der Universität des Saarlandes, 107:130, February 1994.
Wolfram Deling. Dolose Handlungen und Interne Revision - Herausforderung
oder Kapitulation? http://www.revision-online.de, 2005.
Python Software Foundation. Python Programming Language. http:
//www.python.org/, 2009. Zuletzt besucht am 27.04.2009.
CTS Eventim Solutions GmbH. eventim.inhouse Benutzerhandbuch. Internes
Benutzerhandbuch, 2009.
[Gro04] Object Management Group. Business Process Modeling Notation 1.0.
Technical report, Object Management Group, May 2004.
[Gro08a] Object Management Group. Business Process Model and Notation 2.0
- Request for Proposal. Technical report, Object Management Group,
February 2008.
[Gro08b]
[Gro09a]
[Gro09b]
Object Management Group. Business Process Modeling Notation V1.1.
Technical report, Object Management Group, February 2008.
Object Management Group. UML Superstructure Spezikation Version
2.2. Technical report, Object Management Group, January 2009.
PostgreSQL Global Development Group. PostgreSQL. http://www.
postgresql.org/, 2009. Zuletzt besucht am 27.04.2009.
[HFP07] Frank Hülsberg, Steen Feller, and Christian Parsow. Anti-Fraud-
Management. Zeitschrift Risk, Fraud und Governance (ZRFG), 2(5):204
208, 2007.
XXII

Literaturverzeichnis
[HKS93]
[Jan08]
[KKNS91]
[KNS92]
[KR96]
W. Homann, J. Kirsch, and August-Wilhelm Scheer. Modellierung mit
Ereignisgesteuerten Prozeÿketten. Forschungsberichte des Instituts für
Wirtschaftsinformatik der Universität des Saarlandes, 101:131, January
1993.
Günter Janke. Bekämpfung der Wirtschaftskriminalität - Wichtige Aufgabe
der Corporate Compliance. Zeitschrift Risk, Fraud und Governance
(ZRFG), 3(4):173178, 2008.
G. Keller, J. Kirsch, M. Nüttgens, and August-Wilhelm Scheer. Informationsmodellierung
in der Fertigungssteuerung. Forschungsberichte des
Instituts für Wirtschaftsinformatik der Universität des Saarlandes, 80:1
40, August 1991.
G. Keller, M. Nüttgens, and August-Wilhelm Scheer. Semantische Prozeÿmodellierung
auf der Grundlage Ereignisgesteuerter Prozeÿketten
(EPK). Forschungsberichte des Instituts für Wirtschaftsinformatik der
Universität des Saarlandes, 89:131, January 1992.
Ekkard Kindler and Wolfgang Reisig. Algebraic System Nets for Modelling
Distributed Algorithms. Petri Net Newsletter, 51, November 1996.
[KV97] Ekkard Kindler and Hagen Völzer. Flexibility in algebraic nets.
Informatik-Berichte 89, Humboldt-Universität zu Berlin, November 1997.
[Lan04]
[LSW97]
[Ltd09]
[Mai01]
[Mül08]
Guy P. Lander. What is Sarbanes-Oxley? McGraw-Hill, New York [u.a.],
2004.
Peter Langner, Christoph Schneider, and Joachim Wehler. Prozeÿmodellierung
mit Ereignisgesteuerten Prozeÿketten (EPKs) und Petri-Netzen.
Wirtschaftsinformatik, 39(5):479489, 1997.
ACL Services Ltd. ACL - Technology for Business Assurance. http:
//www.acl.com/products/, 2009. Zuletzt besucht am 27.04.2009.
Kilian Maier. Wirtschaftskriminalität und Interne Revision. PhD thesis,
Universität St. Gallen, 2001.
Lothar Müller. Wirtschaftsstraftäter - Täterpsychologie und Persönlichkeitsprol.
Zeitschrift Risk, Fraud und Governance (ZRFG), 3(3):111
119, 2008.
[Nig99] Mark J. Nigrini. I've Got Your Number. Journal of Accountancy,
187(5):7983, May 1999.
[Nor08]
Nicole Noreik. Evaluierung der Einsatzmöglichkeiten von Beleguÿanalysen
in Corporate Audit. Hochschule für Technik und Wirtschaft, Karlsruhe
in Kooperation mit der Daimler AG, Stuttgart, August 2008.
XXIII

Literaturverzeichnis
[NSB07]
Claudia Nestler, Steen Salvenmoser, and Kai-D. Bussmann. Wirtschaftskriminalität
2007, March 2007.
[Peu01] Sibylle Peuker. Halbordnungsbasierte Verfeinerung zur Verikation
verteilter Algorithmen. Dissertation, Humboldt-Universität zu Berlin,
Mathematisch-Naturwissenschaftliche Fakultät II, July 2001.
[Pri09a] PricewaterhouseCoopers. AntiFraudSolutions. http://www.pwc.
de/portal/pub/cxml/04_Sj9SPykssy0xPLMnMz0vM0Y_
QjzKLd4p3dgrTL8h2VAQAkxfsGA!!?topNavNode=
49c4e38420924a4b&siteArea=49c4e38420924a4b&content=
e5e3e24ab3c9fcc, 2009.
[Pri09b] PriceWaterhouseCoopers. Fraud-Scan ® . http://www.pwc.de/
redirect/49c4e38420924a4b/e5d00b005d9d801, 2009. Zuletzt
besucht am 26.04.2009.
[Rei91] Wolfgang Reisig. Petri Nets and Algebraic Specications. Theoretical
Computer Science, 80:134, 1991. NewsletterInfo: 38,39.
[Rie09]
[Sch97]
[SM09]
[SNV95]
[SNV97]
[Uni04]
[vdA99]
Michael Riecker. Forensische Datenanalysen mit Data Mining. Diplomarbeit,
Universität Mannheim, March 2009.
August-Wilhelm Scheer. Wirtschaftsinformatik. Springer, Berlin ; Heidelberg
[u.a.], 7., durchges. au. edition, 1997.
Inc Sun Microsystems. MySQL. http://www.mysql.com/, 2009. Zuletzt
besucht am 26.04.2009.
August-Wilhelm Scheer, M. Nüttgens, and V.Zimmermann. Rahmenkonzept
für ein integriertes Geschäftsprozessmanagement. Wirtschaftsinformatik,
37:426234, 1995.
August-Wilhelm Scheer, M. Nüttgens, and V.Zimmermann. Objektorientierte
Ereignisgesteuerte Prozeÿketten (oEPK) - Methode und Anwendung.
Forschungsberichte des Instituts für Wirtschaftsinformatik der Universität
des Saarlandes, 141:124, May 1997.
International Telecommunication Union. Z.120 Message Sequence Chart.
Technical report, International Telecommunication Union, April 2004.
W. M. P. van der Aalst. Formalization and verication of event-driven process
chains. Information and Software Technology, 41(10):639650, July
1999. http://www.sciencedirect.com/science/article/B6V0B-3YJYTT0-
2/2/6e146708936b058a52a576f053f9c811.
XXIV

Literaturverzeichnis
[WWV + 97] Michael Weber, Rolf Walter, Hagen Völzer, Tobias Vesper, Wolfgang
Reisig, Sibylle Peuker, Ekkard Kindler, Jörn Freiheit, and
Jörg Desel. DAWN: Petrinetzmodelle zur Verikation Verteilter
Algorithmen. Informatik-Berichte 88, Humboldt-Universität
zu Berlin, December 1997. Errata: http://www.informatik.hu-
berlin.de/top/download/publications/WeberWVVRPKFD1997_hub_tr88-
errata.ps.
XXV

Anhang A.
Erweiterung des Beispiels
Um den Abschnitt 5.6 zu entlasten, ndet sich in diesem Teil des Anhangs die vollständige
Programmausgabe und weitere Details des vorgestellten Beispielszenarios.
Die Abbildung A.1 zeigt den Beispielprozess mit allen modellierten Datenobjekten.
Dieser wird als Eingabe zu dem in Abschnitt B.2.1 beschriebenen Skript verwendet.
Abbildung A.1.: Geschäftsprozessdiagramm mit Informationsobjekten
XXVII

Anhang A. Erweiterung des Beispiels
Das Skript Traverse-aEPK.py sucht im ersten Schritt alle Pfade durch das Diagramm.
Diese sind in der Auistung A.1 vollständig abgebildet.
1 Pfad 1:
2 ID: O0 - Text: #Kartenstorno gewünscht# (E)
3 ID: O18 - Text: #Kartendaten einlesen# (F)
4 ID: O19 - Text: #Kartendaten eingelesen# (E)
5 ID: O1 - Text: #Zahlart wählen# (F)
6 ID: O4 - Text: Operator: XOR (Op)
7 ID: O24 - Text: #Bar# (E)
8 ID: O26 - Text: #Barauszahlung an den Kunden vornehmen# (F)
9 ID: O10 - Text: Operator: XOR (Op)
10 ID: O14 - Text: #Storno durchgeführt# (E)
12 Pfad 2:
13 ID: O0 - Text: #Kartenstorno gewünscht# (E)
14 ID: O18 - Text: #Kartendaten einlesen# (F)
15 ID: O19 - Text: #Kartendaten eingelesen# (E)
16 ID: O1 - Text: #Zahlart wählen# (F)
17 ID: O4 - Text: Operator: XOR (Op)
18 ID: O3 - Text: #Überweisung# (E)
19 ID: O9 - Text: #Überweisung anstoßen# (F)
20 ID: O10 - Text: Operator: XOR (Op)
21 ID: O14 - Text: #Storno durchgeführt# (E)
23 Pfad 3:
24 ID: O0 - Text: #Kartenstorno gewünscht# (E)
25 ID: O18 - Text: #Kartendaten einlesen# (F)
26 ID: O19 - Text: #Kartendaten eingelesen# (E)
27 ID: O1 - Text: #Zahlart wählen# (F)
28 ID: O4 - Text: Operator: XOR (Op)
29 ID: O2 - Text: #Spende# (E)
30 ID: O11 - Text: #Spende verbuchen# (F)
31 ID: O10 - Text: Operator: XOR (Op)
32 ID: O14 - Text: #Storno durchgeführt# (E)
Auistung A.1: Pfade durch das Diagramm
Im nächsten Schritt werden aus diesen Pfaden alle den Funktionen zugeordneten Informationsobjekte
extrahiert und, wie in der Auistung A.2 anschaulich aufbereitet,
für den Nutzer bereitgestellt. Zur Weiterverarbeitung werden diese Daten im, in der
Auistung B.3, gezeigten Format abgespeichert.
1 Informationsobjekte Pfad 1:
2 a => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’kdnr’}
3 c => {’table’:’tb1’, ’wert’:"’storniert’", ’datensatz’:’1’, ’field’:’
status’}
4 b => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’auftragsnr’}
5 e => {’table’:’tb3’, ’datensatz’:’2’, ’field’:’kontonr’}
6 d => {’table’:’tb3’, ’wert’:’a’, ’datensatz’:’2’, ’field’:’kdnr’}
7 g => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’auftrag_neu’}
XXVIII

8 f => {’table’:’tb3’, ’datensatz’:’2’, ’field’:’blz’}
9 i => {’table’:’tb1’, ’wert’:"’Storno’", ’datensatz’:’3’, ’field’:’status
’}
10 h => {’table’:’tb1’, ’wert’:’b’, ’datensatz’:’3’, ’field’:’auftragsnr’}
11 k => {’table’:’tb2’, ’wert’:"’bar’", ’datensatz’:’4’, ’field’:’zahlart’}
12 j => {’table’:’tb1’, ’wert’:’a’, ’datensatz’:’3’, ’field’:’kdnr’}
13 l => {’table’:’tb2’, ’wert’:’b’, ’datensatz’:’4’, ’field’:’auftragsnr’}
15 Informationsobjekte Pfad 2:
16 a => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’kdnr’}
17 c => {’table’:’tb1’, ’wert’:"’storniert’", ’datensatz’:’1’, ’field’:’
status’}
18 b => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’auftragsnr’}
19 e => {’table’:’tb3’, ’datensatz’:’2’, ’field’:’kontonr’}
20 d => {’table’:’tb3’, ’wert’:’a’, ’datensatz’:’2’, ’field’:’kdnr’}
21 g => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’auftrag_neu’}
22 f => {’table’:’tb3’, ’datensatz’:’2’, ’field’:’blz’}
23 i => {’table’:’tb1’, ’wert’:"’Storno’", ’datensatz’:’3’, ’field’:’
status’}
24 h => {’table’:’tb1’, ’wert’:’b’, ’datensatz’:’3’, ’field’:’auftragsnr’}
25 k => {’table’:’tb2’, ’wert’:"’last’", ’datensatz’:’4’, ’field’:’zahlart
’}
26 j => {’table’:’tb1’, ’wert’:’a’, ’datensatz’:’3’, ’field’:’kdnr’}
27 m => {’table’:’tb2’, ’wert’:’e’, ’datensatz’:’4’, ’field’:’kontonr’}
28 l => {’table’:’tb2’, ’wert’:’b’, ’datensatz’:’4’, ’field’:’auftragsnr’}
29 n => {’table’:’tb2’, ’wert’:’f’, ’datensatz’:’4’, ’field’:’blz’}
31 Informationsobjekte Pfad 3:
32 a => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’kdnr’}
33 c => {’table’:’tb1’, ’wert’:"’storniert’", ’datensatz’:’1’, ’field’:’
status’}
34 b => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’auftragsnr’}
35 e => {’table’:’tb3’, ’datensatz’:’2’, ’field’:’kontonr’}
36 d => {’table’:’tb3’, ’wert’:’a’, ’datensatz’:’2’, ’field’:’kdnr’}
37 g => {’table’:’tb1’, ’datensatz’:’1’, ’field’:’auftrag_neu’}
38 f => {’table’:’tb3’, ’datensatz’:’2’, ’field’:’blz’}
39 i => {’table’:’tb1’, ’wert’:"’Storno’", ’datensatz’:’3’, ’field’:’status
’}
40 h => {’table’:’tb1’, ’wert’:’b’, ’datensatz’:’3’, ’field’:’auftragsnr’}
41 k => {’table’:’tb2’, ’wert’:"’spende’", ’datensatz’:’4’, ’field’:’
zahlart’}
42 j => {’table’:’tb1’, ’wert’:’a’, ’datensatz’:’3’, ’field’:’kdnr’}
43 l => {’table’:’tb2’, ’wert’:’b’, ’datensatz’:’4’, ’field’:’auftragsnr’}
Auistung A.2: Informationsobjekte des Beispielszenarios
Im darauf folgenden letzten Schritt werden die abgespeicherten Informationsobjekten
von einem neuen Skript (in Abschnitt B.2.5 beschrieben) innerhalb der Picalo
Umgebung eingelesen und zu den in der Auistung A.3 aufgeführten SQL-Anfragen
weiterverarbeitet. Diese werden anschlieÿend durch ein DBMS ausgeführt. Die er-
XXIX

Anhang A. Erweiterung des Beispiels
haltenen Resultate beinhalten alle prozesskonformen Datensätze. Diese können nun
entsprechend der in dieser Arbeit beschriebenen Arten weiterverarbeitet werden.
1 #Anfrage zu Pfad 1:
2 SELECT *
3 FROM tb1 a1, tb1 a3, tb3 a2, tb2 a4
4 WHERE a1.status = ’storniert’ AND a2.kdnr = a1.kdnr
5 AND a3.status = ’Storno’ AND a3.auftragsnr = a1.auftragsnr
6 AND a4.zahlart = ’bar’ AND a3.kdnr = a1.kdnr
7 AND a4.auftragsnr = a1.auftragsnr
9 #Anfrage zu Pfad 2
10 SELECT *
11 FROM tb1 a1, tb1 a3, tb3 a2, tb2 a4
12 WHERE a1.status = ’storniert’ AND a2.kdnr = a1.kdnr
13 AND a3.status = ’Storno’ AND a3.auftragsnr = a1.auftragsnr
14 AND a4.zahlart = ’last’ AND a3.kdnr = a1.kdnr
15 AND a4.kontonr = a2.kontonr AND a4.auftragsnr = a1.auftragsnr
16 AND a4.blz = a2.blz
18 #Anfrage zu Pfad 3:
19 SELECT *
20 FROM tb1 a1, tb1 a3, tb3 a2, tb2 a4
21 WHERE a1.status = ’storniert’ AND a2.kdnr = a1.kdnr
22 AND a3.status = ’Storno’ AND a3.auftragsnr = a1.auftragsnr
23 AND a4.zahlart = ’spende’ AND a3.kdnr = a1.kdnr
24 AND a4.auftragsnr = a1.auftragsnr
Auistung A.3: Generierte SQL Anfragen
XXX

Anhang B.
Skriptsammlung
Dieser Anhang zur Diplomarbeit bietet einen vollständigen Überblick über alle Teile
der Skriptsammlung mit Ausschnitten aus dem Programmcode. Diese Skriptsammlung
ermöglicht die automatisierte Auswertung des Vorgehensmodells aus Kapitel 5.
B.1. Grundlegendes zu den Werkzeugen
Wie bereits in Kapitel 4.4.2 erwähnt, basiert die Automatisierung des Vorgehensmodells
auf der Zusammenarbeit zwischen dem Diagrammwerkzeug Dia, der Analyseumgebung
Picalo und des DBMS MySQL [SM09]. Diese drei Komponenten werden zum
Zweck der Automatisierung mittels kurzer Skripte, welche auf der Programmiersprache
Python basieren, miteinander verbunden.
B.1.1. Grakwerkzeug Dia
Das Diagrammwerkzeug Dia [BML09a] ermöglicht es mittels einer zusätzlichen Elementpalette
[BML09b], welche Dia um die für EPKs typischen Grakelemente erweitert,
algebraische Ereignisgesteuerte Prozessketten (aEPK) zu modellieren. Diese
modellierten Diagramme können anschlieÿend im Dia eigenen XML -basierten Dateiformat
gespeichert werden. Dieses XML -Format hat die folgende ausschnittsweise
dargestellte Form:
892 ...
893
894
895
896
XXXI

Anhang B. Skriptsammlung
897 <
/dia:attribute>
898
899
900
901
902
903
904
905
906 #Kartendaten einlesen#
907
908
909
910
911
912
913
914
915
916
917 ...
Auistung B.1: XML-basiertes Dia Dateiformat
B.1.2. Analyseumgebung Picalo
Für eine Charakterisierung der Analyseumgebung Picalo [Alb09] wird an dieser Stelle
auf das Kapitel 3.5.2 dieser Arbeit verwiesen. Hier wird diese Zusammenfassung um
einen Screenshot des Picalo Frameworks ergänzt.
XXXII

B.2. Übersicht der einzelnen Skripte
Abbildung B.1.: Diagrammwerkzeug Dia
B.2. Übersicht der einzelnen Skripte
In diesem Abschnitt werden die erstellten Skripte im Einzelnen vorgestellt und in
Ausschnitten näher erläutert.
B.2.1. Traverse-aEPK.py
Dieses Skript ist das Herzstück innerhalb der Skriptsammlung. Es ist auf die Nutzung
über die Kommandozeile beschränkt und verarbeitet das mit Dia erstellte Diagramm
zu einer abstrakten Datenmenge entsprechend der in Kapitel 5.1.1 beschriebenen.
XXXIII

Anhang B. Skriptsammlung
Abbildung B.2.: Analysewerkzeug Picalo
1 Usage: Traverse-aEPK.py [Optionen]
3 Options:
4 -h, --help show this help message and exit
5 -v, --verbose Detailierte Ausgabe
6 -i INPUTFILE, --inputfile=INPUTFILE
7 Eingabedatei im Dia Dateiformat
8 -o OUTPUTFOLDER, --outputfolder=OUTPUTFOLDER
9 Ordner fuer die Ausgabedateien
10 -d, --debug Debugmode - zur Programmkontrolle einschaltbar.
Auistung B.2: Parameter und Aufruf von Traverse-aEPK.py
Im ersten Verarbeitungsschritt wird die Eingabedatei im Dia-Format eingelesen und
mit Hilfe einer entsprechenden Funktion geparst. Anschlieÿend wird ein Graph, ähnlich
dem Diagramm, im Speicher aufgebaut, wobei hier die einzelnen Knoten den Ereignissen,
Funktionen und Operatoren entsprechen. Danach wird sowohl der Startknoten als
auch der Endknoten ermittelt. Dies ist notwendig, um dem Algorithmus einen Startpunkt
und Endpunkt übergeben zu können. Im zweiten Schritt werden vom entwickelten
Algorithmus alle Pfade und Schleifen innerhalb des Graphen ermittelt und zur
Weiterverarbeitung abgespeichert. Im dritten Schritt werden die Informationsobjekte
aller gefundenen Funktionen jeweils zu den Pfaden ausgewertet und in der Datei Informationsobjekte.csv
mit dem in Abbildung B.3 dargestellten Format abgespeichert. Als
XXXIV

B.2. Übersicht der einzelnen Skripte
formatierte Ausgabe zur direkten Weiterverarbeitung werden die gefundenen Pfade in
der Datei Wege.txt (Format entsprechend Auistung A.1) und die dazugehörenden
Informationsobjekte in der Datei Informationsobjekte.txt (Format entsprechend der
Auistung A.2) abgelegt.
1 a;tb1;kdnr;1;;N
2 c;tb1;status;1;’storniert’;N
3 b;tb1;auftragsnr;1;;N
4 e;tb3;kontonr;2;;N
5 d;tb3;kdnr;2;a;N
6 g;tb1;auftrag_neu;1;;N
7 f;tb3;blz;2;;N
8 i;tb1;status;3;’Storno’;N
9 h;tb1;auftragsnr;3;b;N
10 k;tb2;zahlart;4;’bar’;N
11 j;tb1;kdnr;3;a;N
12 l;tb2;auftragsnr;4;b;N
13 ===
14 a;tb1;kdnr;1;;N
15 c;tb1;status;1;’storniert’;N
16 ...
Auistung B.3: Dateiformat von Informationsobjekte.csv
Dieses Dateiformat ist der Darstellung der Informationsobjekte angepasst und setzt
sich wie folgt zusammen:
1 A;B;C;D;E;F
2 A= Variablenbezeichnung
3 B= Tabellenbezeichnung
4 C= Feldbezeichnung
5 D= Datensatznummer
6 E= Wert
7 F= Schlüssel (J/N)
9 === Pfadtrenner
Auistung B.4: Formaterläuterung zur Datei Informationsobjekte.csv
B.2.2. Funktion.py
Dieses Skript wird innerhalb von Traverse-aEPK.py eingebunden und hat die Aufgabe,
Funktionen zur Verfügung zu stellen, welche während der Diagramm- Verarbeitung
häuger benötigt werden. So werden zum Beispiel Funktionen zur Ausgabe von Daten
in einem denierten Format in eine Datei oder auf die Kommandozeile bereitgestellt.
XXXV

Anhang B. Skriptsammlung
B.2.3. Objekte.py
Das Skript Objekt.py unterstützt den objektorientierten Ansatz und stellt Objekte
bereit, welche für den Aufbau des diagrammabbildendenden Graphen im Speicher
benötigt werden. Die Objekte Object, Line, Operator, Function und Ereignis
werden innerhalb dieser Datei deniert. Wie bereits die Bezeichnung vermuten lässt,
repräsentieren diese Objekte unterschiedliche Elemente aus dem Diagramm. Allen gemeinsam
ist das Objekt Object, welches grundlegende Attribute und Methoden, wie
beispielsweise das Attribut id oder die Methode toString, an die anderen vier Objekte
vererbt und somit überall verfügbar macht.
B.2.4. Parsen.py
Dieses Skript ist dafür vorgesehen, verschiedene Routinen für das Analysieren der
unterschiedlichen Dateiformate der Diagrammwerkzeuge bereitzustellen. Aktuell wird
nur die Analyse des XML-basierten Dateiformats von Dia unterstützt. Vorgesehen ist
aber bereits eine Funktion, welche das Format von Microsoft Visio analysiert. Um diese
Analyse vorzunehmen, wird für das Dia-Format ein Baum entsprechend der XML-
Datei aufgebaut und die benötigten Informationen über XPath-Ausdrücke daraus extrahiert
und in eigenen Objekten gespeichert. XPath ist eine auf XML-Strukturen
arbeitende Anfragesprache, welche denierte Informationen extrahieren kann.
B.2.5. Untersuchungsscript.py
Das Analysewerkzeug Picalo stellt neben diversen anderen Funktionalitäten (näher in
Kapitel 3.5.2 beschrieben) auch eine Tabellenrepräsentation und eine Datenbankanbindung
bereit. Beides ist für die Auswertung notwendig, weshalb dieses Skript innerhalb
der Picalo-Umgebung ausgeführt werden sollte, sofern die Picalo-Pakete nicht in die
Python-Umgebung integriert wurden. Ist dies geschehen, sollte auch eine erfolgreiche
Ausführung über die Kommandozeile möglich sein. Dieses Skript, mit Verweis auf die
Picalo-Funktionalität, liest die von Traverse-aEPK.py erstellte Datei Informationsobjekte.csv
ein und interpretiert den Inhalt. Im nächsten Schritt werden auf Grundlage
der eingelesenen Informationen die notwendigen SQL-Anfragen generiert und mit Hilfe
der MySQL-Datenbank ausgewertet. Falls der Select-Modus verwendet wurde, werden
die als Antwort des DBMS erhaltenen Tabellen abgespeichert und so zur späteren
Analyse bereitgestellt.
XXXVI