Bachelor-Thesis Konzeption einer Anwendung als Instrument zur Prozesssteuerung auf Basis der Qualitätsmanagementmethode Six Sigma und die prototypische Realisierung als Webanwendung.

(1)

Fakultät für Wirtschaftswissenschaften

Bachelor-Thesis

Konzeption einer Anwendung als Instrument zur Prozesssteuerung auf Basis der

Qualitätsmanagementmethode Six Sigma und die prototypische Realisierung als Webanwendung.

Abschlussarbeit zur Erlangung des Grades eines Bachelor of Science (B.Sc.)

in Wirtschaftsinformatik der Hochschule Wismar

eingereicht von: Frank Haake

geboren am 05. Juli 1979 in Wismar Studiengang Wirtschaftsinformatik Matrikelnummer: 116330

Erstgutachter: Prof. Dr. Jürgen Cleve Zweitgutachter: Prof. Dr. Erhard Alde

Wismar, den 09.10.2013

(2)

Sperrvermerk

Die vorgelegte Bachelorarbeit mit dem Titel “Konzeption einer Anwendung als In- strument zur Prozesssteuerung auf Basis der Qualitätsmanagementmethode Six Sig- ma und die prototypische Realisierung als Webanwendung.” beinhaltet vertrauliche Informationen und Daten des Unternehmens PPI AG.

Diese Bachelorarbeit darf nur vom Erst- und Zweitgutachter sowie berechtigten Mit- gliedern des Prüfungsausschusses eingesehen werden. Eine Vervielfältigung und Ver- öffentlichung der Bachelorarbeit ist auch auszugsweise nicht erlaubt.

Dritten darf diese Arbeit nur mit der ausdrücklichen Genehmigung des Verfassers und des Unternehmens zugänglich gemacht werden.

(3)

Inhaltsverzeichnis

Abbildungsverzeichnis v

Tabellenverzeichnis vi

Abkürzungsverzeichnis vii

1 Einleitung 1

1.1 Aufbau der Arbeit . . . 1

1.2 Zielsetzung . . . 2

2 Grundlagen 3 2.1 Grundlagen des Prozessmanagements . . . 3

2.2 Grundlagen von Six Sigma . . . 5

2.2.1 Historische Entwicklung . . . 6

2.2.2 Verbesserungsmethodik bei Six Sigma-Projekten . . . 6

2.2.3 Zentrale Kennzahlen von Six Sigma . . . 10

3 Konzeption 12 3.1 Erfassung der Grundidee . . . 12

3.2 Anforderungsanalyse Sparkasse . . . 16

3.3 Funktionale Endkonzeption . . . 19

3.4 Datenbeschreibung . . . 25

4 Entwicklung 30 4.1 Oracle Application Express (APEX) . . . 31

4.2 Datenimport und Konvertierung . . . 33

4.3 Prozessanzeige . . . 35

4.4 Verwaltungsfunktionen . . . 39

5 Schlussbemerkungen und Ausblick 45 Literaturverzeichnis ix Ehrenwörtliche Erklärung xi A Anhang xii A.1 Umrechnungstabelle von Six Sigma-Kennzahlen (eigene Darstellung) . xii A.2 ER-Modell der Datenstruktur (eigene Darstellung) . . . xiii

A.3 Relationales Dankenbankmodell der Datenstruktur (eigene Darstellung) xiv A.4 PL/SQL-Skript für die PPS-Konvertierung . . . xiv

(4)

Inhaltsverzeichnis

A.5 PL/SQL-Skript für die Vorlagen-Konvertierung der manuellen Excel- Datei . . . xvi A.6 Abfrage zur Realisierung von Texteinfärbung und Bildzuordnung . . . xviii A.7 XML-Code des Tachometerdiagrammes . . . xix A.8 SQL-Code der Ausreißer-Funktion . . . xx A.9 PL/SQL-Code des Historisierungstrigger für CTQ . . . xxii

(5)

Abbildungsverzeichnis

2.1 Zwei Ansätze von Six Sigma (Quelle: Tavasli 2007, S. 75.) . . . 7

2.2 DMAIC-Zyklus (Quelle: Tavasli 2007, S. 79.) . . . 8

2.3 DICOV-Zyklus (Quelle: Tavasli 2007, S. 90.) . . . 8

2.4 DMAIC-Logik und Methodenzuweisung (Quelle: Gamweger et al. 2009, S. 8.) . . . 9

2.5 Six Sigma Rollenverteilung (Quelle: Tavasli 2007, S. 98.) . . . 9

3.1 Beispiel einer Prozesshierarchie (eigene Darstellung) . . . 13

3.2 Erste Skizze einer möglichen grafischen Oberfläche (eigene Darstellung) 15 3.3 Anwendungsdiagramm der Projektumgebung (eigene Darstellung) . . 16

3.4 Skizze der Prozessanzeige von Nichtblätterprozessen (eigene Darstel- lung) . . . 19

3.5 Oberste Ebene der Prozessansicht (eigene Darstellung) . . . 21

3.6 Tiefergehen in “Privatgiro” (eigene Darstellung) . . . 22

3.7 Tiefergehen in “Privatgiro eröffnen” (eigene Darstellung) . . . 23

3.8 Ausschnitt aus Beispieldatensatz der PPS-Importdatei (eigene Dar- stellung) . . . 26

3.9 Vereinfachte Darstellung der Datenstruktur (eigene Darstellung) . . . 27

3.10 Vereinfachte Darstellung der Datenstruktur (eigene Darstellung) . . . 29

4.1 Bausteine der Ausreißer-Funktion (eigene Darstellung) . . . 32

4.2 Systemvoraussetzungen von APEX (Quelle: http://docs.oracle.com) . 34 4.3 Vorlage für manuellen Import mit Beispieldaten (eigene Darstellung) 35 4.4 Standort der Importfunktion (eigene Darstellung) . . . 35

4.5 Standort der Konvertierungsskripte (eigene Darstellung) . . . 36

4.6 Umsetzung der ersten Ebene der Prozessansicht (eigene Darstellung) . 37 4.7 Umsetzung der zweiten Ebene der Prozessansicht (eigene Darstellung) 38 4.8 Umsetzung einer parametrisierten Tachometerdarstellung (eigene Dar- stellung) . . . 39

4.9 Umsetzung der dritten Ebene der Prozessansicht (eigene Darstellung) 39 4.10 Übersicht Verwaltungsfunktionen (eigene Darstellung) . . . 40

4.11 Beispiel Ausreißer-Funktion (eigene Darstellung) . . . 41

4.12 Ansicht “Oberprozesse verwalten” (eigene Darstellung) . . . 41

4.13 Ansicht “Oberprozesse zuordnen” (eigene Darstellung) . . . 42

4.14 Ansicht “Setzen der Bewertungsgrenzen” (eigene Darstellung) . . . . 42

4.15 Ansicht “CTQ-Verwaltung” (eigene Darstellung) . . . 44

4.16 Ansicht der nicht umgesetzten Soll-Kriterien (eigene Darstellung) . . 44

(6)

Tabellenverzeichnis

2.1 Erfolgskennzahlen beispielhafter Six Sigma Unternehmen (Quelle: Ta-

vasli 2007, S. 69.) . . . 6

2.2 Das Sigma-Niveau und die zu erwartende Fehlerquote (Quelle: Reh- behn 2008, S. 18.) . . . 10

2.3 FpMM Beispielrechnung (eigene Darstellung) . . . 11

3.1 Beispielprozesse der Sparkasse (eigene Darstellung) . . . 17

3.2 Kernprozesse der Sparkasse (eigene Darstellung) . . . 18

(7)

Abkürzungsverzeichnis

APEX Oracle Application Express BI Business Intelligence

BPM Business Process Management CRUD Create, read, update und delete CSS Cascading Style Sheets

CTQ Critical to Quality CTB Critical to Business

DPMO Defects per million opportunities ERM Entity Relationship Model FpMM Fehler pro Million Möglichkeiten GAA Geldausgabeautomat

HTML Hypertext Markup Language

PL/SQL Procedural Language/Structured Query Language PPS PROCESS PERFORMANCE SUITE^R

SQL Structured Query Language TQM Total Quality Management URL Uniform Resource Locator XML Extensible Markup Language

(8)

Kapitel 1. Einleitung

1 Einleitung

Die vorliegende Bachelorthesis hat die Konzeption und prototypische Neuentwick- lung einer Cockpitanwendung zur Prozesssteuerung auf Basis der Qualitätsmanage- mentmethode Six Sigma zum Ziel. Sie wurde in Zusammenarbeit mit der PPI AG in Hamburg angefertigt. Angeregt wurde die Idee vom Six Sigma Experten des Un- ternehmens, welcher ein Nachfragepotential in einer solchen Anwendung sieht und dem die Existenz eines solchen Produkts unbekannt ist. Verstärkend kommt hinzu, dass mit der PROCESS PERFORMANCE SUITE¹^R (PPS) das Unternehmen eine Software entwickelt hat mit deren Hilfe die benötigen Prozessdaten erfasst werden können.

1.1 Aufbau der Arbeit

Die Thematik des Prozessmanagements ist ein wichtiger Bestandteil großer und mit- telständischer Unternehmen. Der erste Teil des Grundlagenkapitels beschäftigt sich mit dessen Geschichte, der Definition diverser Grundbegriffe und den Bausteinen der verschiedenen Aufgabenfeldern. Im zweiten Teil des Kapitels wird die Quali- tätsmanagementmethode Six Sigma vorgestellt und deren Einsatzmöglichkeiten als Instrumentarium für das Prozessmanagement. Neben der Methodik von Six Sigma werden die für die Anwendung relevanten Kennzahlen und deren Bestimmung prä- sentiert. Das Konzeptionskapitel beschreibt die drei großen Schritte auf dem Weg zur finalen Konzeption. Zuerst wird der Grundgedanke und die ursprünglichen Ide- en zur Funktionsweise und Aussehen der Anwendung dargestellt. Um im zweiten Schritt diese Ideen bei einem potentiellen Kunden² zu hinterfragen und konkrete Anforderungen für die Anwendung herauszuarbeiten. Im letzten Teil des Kapitels wird das Ergebnis der schrittweisen Veränderung und Ergänzung der Anforderungen

1http://www.ppi.de/consulting-versicherungen/prozessmanagement/process-performance-suite- pps/

2In der vorliegenden Arbeit wird bei Verwendung der männlichen oder weiblichen Form bei Per- sonenbezeichnungen immer das jeweils andere Geschlecht mit einbezogen.

(9)

Kapitel 1. Einleitung

und Datenbeschreibung präsentiert. Das Kapitel vier beschäftigt sich mit der Umset- zung des Prototypen unter Verwendung des Frameworks APEX (Oracle Application Express). Dabei wird das Framework APEX vorgestellt und auf die Funktionsweisen der Import- und Konvertierungsfunktion, der Prozessanzeige und der Verwaltungs- funktion eingegangen. In Kapitel fünf wird der Ist- mit dem Sollzustand verglichen, das eingesetzte Framework APEX bewertet und es werden Verbesserungsmöglichen für eine Weiterentwicklung dargestellt.

1.2 Zielsetzung

In erster Linie wird das Ziel verfolgt den funktionalen Aufbau und die Datenbe- schreibung der Cockpit-Anwendung so detailliert wie möglich zu erfassen. Diese Konzeption sollte die Weiterentwicklung des Projektes problemlos ermöglichen. Der Fertigstellungsgrad des Prototypen kann von einem Klick-Dummy³ bis zu einer voll funktionsfähigen Anwendung reichen. Des weiteren sollte untersucht werden, ob sich das verwendete Umsetzungswerkzeug, zum Beispiel ein Framework, für die Entwick- lung der Anwendung eignet.

3Rudimentärer, interaktiver Prototyp zur vereinfachten Demonstration von Verknüpfungen und Teilprozessen

(10)

Kapitel 2. Grundlagen

2 Grundlagen

Dieses Kapitel hat den Anspruch, sowohl die Grundlagen des Prozessmanagements als auch die von Six Sigma aufzuzeigen. Six Sigma kann dabei als spezielles Werkzeug zur Umsetzung des Prozessmanagements angesehen werden.

2.1 Grundlagen des Prozessmanagements

Das Prozessmanagement stellt seit Jahrzehnten ein Schlüsselelement zur Optimie- rung der Leistungserstellung in Unternehmen dar. Aufgrund des starken Einflusses auf den industriellen Sektor wurden viele Ansätze und Methoden durch den sachgut- spezifischen Bezug des Prozessmanagements bedeutend geprägt. Da in den letzten Jahren der Dienstleistungssektor immer mehr an Bedeutung gewonnen hat, findet das Prozessmanagement in Bezug auf Dienstleistungen immer größere Beachtung.

In der Literatur des Prozessmanagements lassen sich viele Definitionen der Begriffe Prozess und Prozessmanagement finden.¹

Schmelzer und Sesselmann verstehen unter einem Prozess eine Abfolge von Schrit- ten, welche aus einer Reihe von Inputs einen Output erzeugen.²Ein Geschäftsprozess präzisiert diese Eigenschaft, indem beginnend von den Kundenanforderungen gewis- se Aufgaben des Leistungserstellers zu einem Mehrwert für den Kunden führen.³ Nordsieck definiert diesen Begriff in Hinblick auf die Ziele einer Unternehmung: “Ein Geschäftsprozess ist ein spezieller Prozess, der der Erfüllung der obersten Ziele der Unternehmung (Geschäftsziele) dient und das zentrale Geschäftsfeld beschreibt.”⁴ Im weiteren Verlauf dieser Thesis wird der Begriff Prozess synonym mit dem Be- griff des Geschäftsprozesses und seiner Bedeutung verwendet. Ein Prozess wird in unterschiedliche Klassifikationen eingeteilt, welche ihren Beitrag zur Wertschöpfung widerspiegeln:

1Vgl. Hartmann 2012, S. 1.

2Vgl. Schmelzer und Sesselmann 2010, S. 62.

3Vgl. Schmelzer und Sesselmann 2010, S. 62.

4Nordsieck 1972, S. 8f..

(11)

• Kernprozesse

• Managementprozesse

• Unterstützungsprozesse

Diese grundlegende Differenzierung der Begriffe ist notwendig, um Prozesse hinsichtlich ihrer Bedeutung für das Unternehmen mit verschiedenen Prioritäten betrachten, steuern und optimieren zu können. Kernprozesse stehen im Fokus der Leistungser- stellung und zeichnen sich durch einen direkten Bezug zum Produkt (Dienstleis- tung) aus. Managementprozesse ermöglichen der Unternehmensführung mittels eines Regelkreises, die Leistungserstellung zu planen, zu kontrollieren und zu steuern.

Unterstützungsprozesse werden die Prozesse genannt, welche keinen unmittelbar wertschöpfenden Charakter aufweisen. Jedoch wäre keine Leistungserstellung ohne eine adäquate Verfügbarkeit und Funktionalität von Unterstützungsprozessen mög- lich.⁵

“Prozessmanagement umfasst planerische, organisatorische und kontrollierende Maß- nahmen zur zielorientierten Steuerung der Wertschöpfungskette eines Unternehmens hinsichtlich Qualität, Zeit, Kosten und Kundenzufriedenheit.”⁶ Schlüsselfaktoren für die Anwendung des Prozessmanagements stellen die Kontinuität und die Ganzheit- lichkeit des benutzten Ansatzes dar. Somit wird das Prozessmanagement für eine kontinuierliche und umfassende Analyse, Planung, Gestaltung, Kontrolle und Steue- rung von Prozessen eingesetzt. Oftmals zahlt sich dieser Einsatz erst im weiteren Verlauf der Geschäftstätigkeit aus, weshalb der kontinuierliche Betrieb unbedingt sicherzustellen ist. Der nächste wichtige Schritt besteht in der Analyse der verschiedenen Aufgabenfelder des Prozessmanagements. Das Australien BPM Community of Pratice⁷ definiert die Bausteine des Prozessmanagements wie folgt:

1. Prozessverständnis

Jeder Mitarbeiter des Prozessmanagements sollte allgemein befähigt werden in Prozessen zu denken und sowohl vor- als auch nachgelagerte Prozessschritte seines Aufgabengebietes betrachten und nachvollziehen zu können.

2. Prozessdokumentation bzw. -modellierung

Um Verbesserungen an Prozessen vornehmen zu können, muss eine geeignete Notationsform für diese Prozesse gefunden werden.

5Hartmann 2012, S. 32.

6Gaitanides et al. 1994.

7Eine Forschergruppe der Queensland University of Technology aus Brisbane in Australien.

http://www.bpm.scitech.qut.edu.au/

(12)

3. Prozessanalyse

Anhand von Ist-Modellen sind Prozesse hinsichtlich ihrer Verbesserungspoten- tiale zu analysieren und anschließend sind diese Verbesserungen umzusetzen.

4. Prozesssimulation

Die Simulation dient der praxisnahen Erprobung von Soll-Prozessmodellen und erleichtert damit die Auswahl von zweckdienlichen Alternativen.

5. Prozessverbesserung

Die Prozessdurchführung ist kontinuierlich auf Verbesserungspotentiale und Zielabweichungen hin zu überprüfen.

6. Prozessausführung

Es sind die geplanten Richtlinien bei der Ausführung der Prozesse gemäß der Soll-Konzeption einzuhalten.

Zahlreiche Ansätze in der Literatur betrachten diese vorgestellten Bausteine mit einer unterschiedlichen Gewichtung. Jedoch wird einheitlich davon ausgegangen, dass diese Bausteine im Wesentlichen die Aufgabenfelder des Prozessmanagements darstellen.⁸

Der Impuls für den Einsatz eines Prozessmanagements kann aus unterschiedlichen organisatorischen und thematischen Bereichen des Unternehmens kommen. Das Un- ternehmen könnte beispielsweise eine Änderung in seiner Unternehmensstrategie vornehmen, das Informationssystem umstellen, Änderungen im Bereich Controlling vornehmen oder ein Qualitätsmanagementsystem, wie Six Sigma, einführen.

2.2 Grundlagen von Six Sigma

Wie das Prozessmanagement hat die Qualitätsmanagementmethode Six Sigma seinen Ursprung in der Fertigungsindustrie und findet nun verstärkt Einzug in den Dienstleistungssektor. “Six Sigma ist ein strikt top-down durchgeführtes Prozess- verbesserungskonzept, welches mit ausgewählten Experten in strukturierter Weise und mithilfe von Methoden und Techniken finanziell messbare Verbesserungsprojek- te umsetzt.”⁹

8Hartmann 2012, S. 33-36.

9Vgl. Gamweger et al. 2009, S. 5.

(13)

2.2.1 Historische Entwicklung

Six Sigma basiert ursprünglich auf den Qualitätsansätzen von Deming und Juran.

Und auf den später entwickelten Ansatz des Total Quality Management (TQM), welches sich erstmals eine Null-Fehler-Qualität als Ziel setzte. Six Sigma entstand in den frühen 80er Jahren bei der Motorola Corporation. Aber erst im Jahr 1996 trieb Jack Welch, der CEO von General Electrics, Six Sigma als Qualitätsoffensive voran. Die großen Erfolge dieser Initiative ebneten den Weg für die Verbreitung von Six Sigma entlang verschiedener Industrien. Tabelle 2.1 zeigt die Gewinnentwicklung namhafter Unternehmen unter dem Einsatz von Six Sigma.¹⁰

Tabelle 2.1:Erfolgskennzahlen beispielhafter Six Sigma Unternehmen (Quelle: Tavasli 2007, S. 69.)

Firma Zeitraum Net-Benefit Gewinnspanne vorher Gewinnspanne nachher

Motorola 1981 - 1991 2,4 Mrd. US$ k.A. k.A.

General Electric 1995 - 1999 2 Mrd. US$ 13,6 % (1995) 16,7 % (1999) AlliedSignal 1994 - 1999 2 Mrd. US$ 12 % (1998) 14,2 % (1999)

2.2.2 Verbesserungsmethodik bei Six Sigma-Projekten

Die Verbesserungsmethodik von Six Sigma umfasst fünf Kernelemente:

• Null-Fehler-Philosophie

• Prozessorientierung und Messbarkeit

• Straffes Projektmanagement

• Problemlösungsmethoden und statische Methoden

• Promotorenkonzept

Die Reduktion oder Elimination von Fehlern sind fest in zahlreichen Managemen- tansätzen verankert. Es wird davon ausgegangen, dass jeder Fehler grundsätzlich einen Verlust darstellt, wobei die Fehlerwirkung unterschiedlich ausfallen kann.

Six Sigma stellt die Fehlerbeseitigung in den Mittelpunkt der unternehmenswei- ten Verbesserungsaktivitäten. Die Definition eines Fehlers erfolgt zumeist direkt

10Vgl. Schurig 2011, S. 23.

(14)

anhand von Kundenanforderungen (CTQ¹¹) oder anhand von internen Spezifika- tionen (CTB¹²). Der Ausgangspunkt für Six Sigma-Verbesserungen stellen Prozesse dar. Dabei ist es egal ob es sich um Produktions- oder Serviceprozesse handelt.

Fehlerfreie Prozesse wirken sich über eine hohe Kundenzufriedenheit, den damit verbundenen Wettbewerbsvorteil und der Umsatzsteigerung auf den Unternehmens- gewinn aus. Die benötigten kontinuierlichen Messungen können immer nur dann erfolgen, wenn entsprechende Messsysteme zur Verfügung gestellt wurden. Das Six Sigma-Projektmanagement findet auf zweierlei Arten statt. Bei bereits vorhandenen Prozessen wird der sogenannte DMAIC-Zyklus angewendet, wobei undefinierte Pro- zesse mithilfe des DICOV-Zyklus durchlaufen werden. Das Zusammenspiel beider Zyklen wurde in Abbildung 2.1 dargestellt.

Abb. 2.1: Zwei Ansätze von Six Sigma (Quelle: Tavasli 2007, S. 75.)

Aus dieser wird ersichtlich, dass von der “Measure”-Phase des DMAIC-Zyklus und der “Optimize”-Phase des DICOV-Zyklus in den jeweils anderen Zyklus übergegan- gen werden kann. Dies zeigt deutlich, dass beide Verfahren nicht strikt voneinander getrennt werden können. Die Funktionsweise beider Zyklen werden in Abbildung 2.2

& 2.3 dargestellt. Das Konzept des DFSS-Modells wird im Rahmen dieser Arbeit nicht erläutert. In jeder Problemlösungsphase des DMAIC-Zyklus können eindeutig unterschiedliche Techniken und Methoden angewendet werden. Abbildung 2.4 zeigt Beispiele für Methoden und Techniken der einzelnen Phasen des Zyklus. Im Wesentlichen werden zwei Arten von Methoden unterschieden. Zum einen können teamorientierte Problemlösungsmethoden eingesetzt werden, die vor allem das struk- turierte, zielgerichtete Vorgehen und somit die Kreativität des Teams unterstützen.

11Critical to Quality - Ein qualitätskritisches Merkmal eines Prozesses

12Critical to Business - Ein unternehmenskritisches Merkmal eines Prozesses

(15)

Abb. 2.2: DMAIC-Zyklus (Quelle: Tavasli 2007, S. 79.)

Abb. 2.3: DICOV-Zyklus (Quelle: Tavasli 2007, S. 90.)

Beispiele für dieses Vorgehen sind unter anderem Ursache-Wirkungs-Diagramme, Flussdiagramme oder die Rangreihenmethode. Zum anderen werden zusätzlich sta- tistische Methoden genutzt, um Zahlen und Fakten in die Verbesserungsarbeit mit einzubeziehen. Zumeist erhält der Six Sigma-Ansatz durch diese Ergänzung erst seine volle Kraft. Der besondere Schwerpunkt liegt dabei auf der statistisch signi- fikanten Untermauerung der Expertenmeinungen. Beispiel hierfür sind die Bestim- mung der Messmittelfähigkeit, die Regressionsrechnung oder die Varianzanalyse.

Das Promotorenkonzept wurde geschaffen, um ein nahezu ideales Kompetenzteam aus geschulten Six Sigma-Personal für das Projekt einzusetzen. Die Vielzahl der Kompetenzbezeichnungen tragen dem Kampfsport entnommene Gürtelfarben. In Abbildung 2.5 ist der Aufbau dieser Six Sigma-Funktionen in Form einer Pyrami-

(16)

Abb. 2.4: DMAIC-Logik und Methodenzuweisung (Quelle: Gamweger et al. 2009, S. 8.)

denstruktur zu sehen. Personen mit dem dem Ausbildungsgrad “Green Belt“ und

“Black Belt” haben operativ dafür Sorge zu tragen, dass Projekte ordnungsgemäß abgewickelt werden. Dabei werden bei größeren Projekten Black Belts und bei klei- neren Projekten Green Belts eingesetzt. Die Spitze der Pyramide bildet stets das Management der Unternehmung. Für ein Vorankommen von Six Sigma-Aktivitäten in der oberen Managementebenen werden sogenannte Machtpromotoren eingesetzt.

Der “Six Sigma-Champion” oder “Projektsponsor” begleitet das Projekt als Macht- promotor seit dem Beginn der Projektdefinition und unterzeichnet unter anderem auch die Verabschiedung der Projektcharta. Bei Veränderung der Rahmenbedin- gungen oder beim Auftreten von Schwierigkeiten können die Machtpromotoren für Unterstützungsleistungen eingeschaltet werden.¹³

Abb. 2.5: Six Sigma Rollenverteilung (Quelle: Tavasli 2007, S. 98.)

13Vgl. Gamweger et al. 2009, S. 6-10.

(17)

2.2.3 Zentrale Kennzahlen von Six Sigma

Das Sigma-Niveau stellt eine universelle Messmethode dar, mit dessen Hilfe bestimmt werden kann, wie gut ein Prozess funktioniert. Der Begriff Sigma stammt aus der Statistik und steht für die Standardabweichung. Je besser ein Prozess ist, desto kleiner ist dabei seine Streuung. Die Standardabweichung passt bei einem gu- ten Prozess also weitaus häufiger zwischen die Spezifikationsgrenzen eines Prozesses als die eines schlechten Prozesses. Damit besitzt ein Prozess mit vielen Fehlern ein niedriges Sigma-Niveau. Dieser Zusammenhang wird in Tabelle 2.2 gezeigt.

Tabelle 2.2:Das Sigma-Niveau und die zu erwartende Fehlerquote (Quelle: Rehbehn 2008, S. 18.)

Das Sigma-Niveau Fehlerquote (in %)

Defekte pro 1 Million Möglichkeiten

1 69 691.462

2 31 308.538

3 6,7 66.807

4 0,62 6.210

5 0,023 233

6 0,00034 3,4

7 0,0000019 0,019

So entspricht ein hoher Sigma-Wert einer hohen Leistungsfähigkeit der Prozesses.

Basierend auf der Gauß’schen Normalverteilung soll die Prozessvarianz so stark re- duziert werden, dass die Spezifikationsgrenzen einen Abstand von 6σvom Nullpunkt haben. Die Kennzahl FpMM (engl. DPMO) bezeichnet die Anzahl der Fehler, die bei einer Million Fehlermöglichkeiten erfasst werden. Diese Kennzahl zeichnet sich durch ihre Einfachheit und langfristige Anwendbarkeit aus und stellt eine gute Möglichkeit dar Verbesserungsentwicklungen nachzuvollziehen. Tabelle 2.3 zeigt die schrittwei- se Berechnung eines FpMM-Wertes. Der Sigma-Wert kann nach der Bestimmung des FpMM-Wertes einer Umrechnungstabelle entnommen werden. Zur besseren Ver- anschaulichung wird dem Sigma-Wert gerne der Ertrag oder Erfüllungsgrad eines Prozesses gegenübergestellt. In Tabelle A.1 des Anhangs ist eine umfangreiche Um- rechnungstabelle der Werte FpMM, Sigma und Erfüllungsgrad zu sehen.

(18)

Tabelle 2.3: FpMM Beispielrechnung (eigene Darstellung)

Schritt Kennzahlen Theoretische Formel aktuelle Berechnung

A Gesamtanzahl gemessene Prozesse 120 120

B Anzahl der Prozesse ohne Fehler 80 80

C Anteil der fehlerfreien Prozesse B/A 0,666666667

D Anteil an fehlerhaften Prozessen 1-C 0,333333333

E Anzahl der CTQ 70 70

F Anteil an fehlerhaften Prozessen je CTQ D/E 0,004761905

G FpMM F * 1000000 4761,904762

H Ertrag 100 - F 99,99523810 %

I Sigma Niveau aus Tabelle ablesen ≈4,1

(19)

Kapitel 3. Konzeption

3 Konzeption

Grundsätzlich bestand die Konzeptionsphase der Anwendung aus drei Phasen. Ers- tens der betriebsinternen Erfassung der Grundidee, zweitens dem Sammeln von An- forderungen aus Sicht einer Sparkassen-Filiale und drittens der Erarbeitung der Endkonzeption. Die Phasen eins und zwei beinhalteten vor allem die Analyse von fachlichen Anwendungsanforderungen, während bei der Endkonzeption der Schwer- punkt vor allem auf den Anforderungen an den zu realisierenden Prototypen lag.

Somit ergaben sich anfänglich kaum technische Anforderungen, aufgrund der fachlichen Fokussierung. Die Konzeptions- und Realisierungsphase waren von einem in- krementellen Vorgehen geprägt. Die inkrementelle Vorgehensweise basiert auf der Grundidee, dass ein System in seiner Gesamtheit geplant, aber in Teilen realisiert wird. Und sie mit einem ständigen, stufenweisen Zuwachs an Funktionalität ein- hergeht. Dieses Vorgehen hatte einen stetigen Wandel der Anforderungen und des Entwicklungsstandes vom Prototyp zur Folge. Aufgrund dessen werden sich manche konzeptionelle Ideen nicht zwingend im darauffolgenden Konzeptionsschritt wieder- finden, da nur die drei wesentlichsten Momentaufnahmen dargelegt werden. Ziel der schrittweisen Dokumentation der Ergebnisse ist es, Fehler für eine erneute Konzep- tion aufzudecken und den zeitlichen Aufwand einer Neukonzeption zu verringern .

3.1 Erfassung der Grundidee

Die anfängliche Aufgabenstellung bestand aus einer Idee, welche erst im Laufe der Zeit konkrete Formen annehmen sollte. Der Grundgedanke ist die Entwicklung einer Software mit deren Hilfe die Auswertung von Arbeitsprozessen ermöglicht wird.

Grundsätzlich wird die Auswertung auf Basis der Qualitätsmanagementmethode Six Sigma erfolgen und branchenunabhängig sein. Die erste Konkretisierung der Aufgabenstellung erfolgte bei einem Gespräch mit dem Ideengeber und Six Sigma Experten von PPI. Dabei stellte sich heraus, dass es eine beträchtliche Anzahl von Software zur Prozesssteuerung für Produktionsbetriebe gäbe, aber kaum speziali- sierte Programme für den Dienstleistungssektor. Der Unterschied liegt vor allem in

(20)

der Art der betrachteten Prozesse, welche im Dienstleistungssektor vornehmlich aus Arbeitstätigkeiten der Mitarbeiter bestehen. Diese Prozesse müssen Hierarchieebe- nen aufweisen, um betriebliche Strukturen abbilden zu können. Zum Beispiel (siehe Abbildung 3.1) könnte ein oberer Prozess den Namen “Schalterdienst” tragen und diesem Prozess wären die Prozesse “Kontoeröffnung”, “Barauszahlung” und “Über- weisung” untergeordnet. Diesen Prozessen könnten wiederum andere Prozesse untergeordnet sein. Beispielsweise könnte der Prozess “Kontoeröffnung” die Unterprozesse

“Kundengespräch”, “Prüfen des Antragsformulars” und “Bestätigungsschreiben für Kunden” besitzen. Mit einer solchen Baumstruktur könnte ein Unternehmen die Prozesslandschaft aller Mitarbeiter abbilden. Dabei wären lediglich Messungen der untersten Ebene (Blätter des Baumes) notwendig, da sie kumuliert die Messergeb- nisse der nächsthöheren Ebene darstellen. Wurde zum Beispiel die Dauer der drei Prozesse aus Ebene 3 gemessen, so ergibt deren Summe die Dauer des Prozesses

“Kontoeröffnung”.

Abb. 3.1: Beispiel einer Prozesshierarchie (eigene Darstellung)

Als zweiter Schritt wurde eine Skizze der grafischen Oberfläche der Anwendung erstellt (siehe Abbildung 3.2), um dem Besprochenen ein erstes Gesicht zu geben. Die Startanzeige der Anwendung soll die Ermittlung der Six Sigma-Größe “Erfüllungs- grad” für jeden einzelnen Prozess und eine Bewertung dieser Grade beinhalten. Die Bewertung soll dabei nach den drei Ampelfarben rot, gelb und grün erfolgen. Wo- bei rot einen kritischen, gelb einen gefährdeten und grün einen effizienten Prozess symbolisiert. Grundlage für die Bewertung ist eine Zuteilung von Zahlenbereichen in Prozentwerten. Zum Beispiel wird in Abbildung 2 der kritische Bereich von 0 bis 80 Prozent, der gefährdete Bereich von 80 bis 90 Prozent und der effiziente Bereich von 90 bis 100 Prozent definiert. Die Oberfläche der Anwendung teilt sich in einen statischen Kopfteil und die eigentliche Prozessanzeige. Der Kopfteil beinhaltet die

(21)

Navigation zwischen der Verwaltung der Prozessdaten und der Erfüllungsgradan- zeige, die Möglichkeit die Prozessanzeige durch verschiedene Parameter zu filtern und eine Übersicht über die allgemeine Prozessverteilung. Da an dieser Stelle generell noch keine genauen Anforderungen vorlagen, sind die Inhalte des Kopfteils als rein exemplarisch anzusehen. Im Gegensatz dazu wurde die Prozessanzeige nach ersten fachlichen Informationen strukturiert. Die Abbildung 3.2 stellt drei Prozesse der höchsten Hierarchieebene (Wurzeln eines Baumes) dar. Mit den Bezeichnungen

“GAA¹”, “Kasse” und “Servicepoint”. Zu allen Prozessen wurde der Erfüllungsgrad berechnet und eine Bewertung in Tachometerform vorgenommen. Über den Button

“Detail” kann eine Prozessebene tiefer gegangen werden, wobei nur Unterprozesse des betrachteten Oberprozesses (z.B. GAA) angezeigt werden. Auch bei den Un- terprozessen würden die separaten Erfüllungsgrade genau wie zuvor berechnet und bewertet werden. Ziel dieser Prozessanzeige soll es also sein, sich zwischen den Pro- zessebenen hin und her bewegen zu können. Zum Beispiel könnte nun untersucht werden, welche Unterprozesse eine kritische Bewertung des Prozesses “Kasse” auslö- sen. Sollte nur ein Unterprozess den kritischen Gesamtzustand auslösen, wird dieser in Klammern unter dem Prozessnamen angezeigt. In diesem Beispiel wäre das der Unterprozess “Barauszahlung”. Da in der Regel einem Wurzelprozess im Unterneh- men ein Abteilungsleiter vorsteht, sollte diesem direkt eine E-Mail geschickt werden können.

Neben einer fachlichen Konzeption, wurden auch erste Ansätze der technischen Um- setzung auf hohem Abstraktionsniveau festgehalten. Aus diesen Informationen entstand das in Abbildung 3.3 zu sehende Anwendungsfalldiagramm. Es zeigt sowohl die involvierten Personentypen und möglichen Datenquellen am Rand des Diagramms, als auch Bausteine für die technische Umsetzung im Innern (Rechteck). Die Per- sonentypen entstanden bei der Überlegung, das Unternehmen einer gewissen In- formationshierarchie folgen. Auf der einen Seite gibt es die Unternehmensführung (Top-Management) bei der alle Informationen zusammenlaufen und auf der anderen Seite Abteilungsleiter (Prozessverantwortlichen) die lediglich für einen bestimmten Bereich zuständig sind. Diese beiden Akteure benötigen unterschiedliche Zugriffs- rechte. Die Abteilungsleiter haben nur in Prozesse Einsicht, denen sie unterstellt sind. Da von seitens PPI keine Support-Leistung geplant ist, wird im Unterneh- men mindestens eine Person benötigt, welche die Software administriert und als Ansprechperson zur Verfügung steht. Da es nicht Aufgabe der Anwendung ist, Pro- zessdaten zu erheben, wird voraussichtlich Mitarbeitern unterhalb der Informati-

1Geldausgabeautomat

(22)

Abb. 3.2: Erste Skizze einer möglichen grafischen Oberfläche (eigene Darstellung)

onshierarchie eines Prozessverantwortlichen kein Zugang ermöglicht. Die Messdaten der Prozesse können diversen Ursprungs sein. Als Hauptdatenquelle wird, vor allem in Hinsicht auf den Prototypen, das Modul WEB DATA COLLECTOR^R der PROZESS PERFORMANCE SUITE^R dienen. Des Weiteren soll die Anwendung so konzipiert werden, dass über eine Konverter-Funktion eine beliebige Anzahl von Datenquellen hinzugefügt werden kann. Das betrifft verschiedene Programme und Dateiformate. Zum Beispiel sollte eine händisch erstellte Excel-Datei genauso importiert werden können, wie eine XML-Datei aus einem Workflow-Management-System.

Dabei soll der Konverter eine für den Entwickler einfache und schnelle Möglichkeit darstellen, eine Konvertierungsroutine für eine neue Datenquelle in das System zu integrieren. Die konvertierten Daten werden im nächsten Schritt in die Anwendungs- datenbank übertragen, welche als Basis für die Anwendung selbst dient. Das Recht auf die Datenbank zuzugreifen, sollte aufgrund benötigter Fachkenntnisse nur der

(23)

Administrator erhalten. Aufgrund der diversen Profile der Personentypen wird eine spezifische Oberfläche für den Administrator angestrebt. Ein Prozessverantwortli- cher sollte nur den Prozessbaum, der ihm unterstellt ist, betrachten können. Die Bezeichnung “Webanwendung” in Abbildung 3.3 ist als exemplarisch anzusehen, da zu diesem Zeitpunkt noch nicht über die Art der Anwendung entschieden wurde.

Abb. 3.3: Anwendungsdiagramm der Projektumgebung (eigene Darstellung)

3.2 Anforderungsanalyse Sparkasse

Im Rahmen der Konzeptionsphase war es möglich, einen Termin bei einem leitenden Angestellten in einer Sparkassen-Filiale wahrzunehmen. Ein gegenseitiges Interesse entstand durch den Umstand, dass mithilfe des WEB DATA COLLECTOR^R Daten zu Qualitätsmanagementzwecken in der Sparkasse erfasst wurden. Dieser Abschnitt beinhaltet die wesentlichen Erkenntnisse aus diesem Gespräch und hat daher nicht den Anspruch umfassend alle Inhalte darzulegen. Es wurde angestrebt grundsätz- lich noch nicht bedachte Anforderungen in Erfahrung zu bringen und ein Feedback zu den in Abschnitt 3.1 verfassten Grundideen zu erhalten. Als Basis für weitere Diskussionen wurde die grundlegende Struktur der Arbeitsprozesse innerhalb der Bankfiliale besprochen. In Tabelle 3.1 lässt sich erkennen, dass die betrachte Pro- zesslandschaft in keinem Widerspruch zu der konzeptionierten Baumstruktur steht.

Jedoch wurde die Frage nach einer Gewichtung der Prozesse aufgeworfen, da die

(24)

in Tabelle 3.2 gezeigten Kernprozesse weitaus zahlreicher durchlaufen werden als andere. Diese Gewichtung könnte aufgrund einer Vorgabe durch den Administrator oder durch Einbeziehung der Anzahl der gemessenen Prozesse in die Erfüllungsgrad- berechnung erfolgen. Zweites würde sich dann unterscheiden in Blätterprozesse und die aller anderen Prozesse, welche sich aus dem kumulierten Wert berechneter Erfül- lungsgrade zusammensetzt. Weiterhin wurde festgehalten, dass ein manueller Import von neuen Daten ausreichen würden, da es nicht Ziel des Managements sei Monito- ring zu betreiben. Das eigentliche Bestreben der Datenerfassung stellt die Analyse der Langzeitentwicklung und den Wechselwirkungen zwischen Prozessen dar. Per- sönlich für den Befragten wäre eine aussagekräftige Grafik und/oder Bericht für seinen Jahresbericht an den Vorstand von oberster Priorität. Nach der Präsentati- on der Nutzerrollen (Top-Management, Prozessverantwortlicher und Administrator) kristallisierte sich eine andere Denkweise des Befragten zu diesem Thema heraus.

Dieser präferierte einen einzigen Nutzertyp, welcher auf alle Funktionen, wie Ver- waltung, Import und Prozessanalyse, ohne Einschränkung Zugriff hat.

Tabelle 3.1: Beispielprozesse der Sparkasse (eigene Darstellung) Beispiel Hauptprozess Beispiel Prozesse

Inzahlungsverkehr Überweisungen im Euro-Zahlungsverkehrsraum abwickeln Lastschrift inkl. Rückgaben abwickeln

Scheck inkl. Rückgaben bearbeiten

Privatgiro Privatgiro eröffnen Konditionen erfassen Privatgiro schließen

Die Verwaltungsfunktion müsste nach Ansicht des Gesprächspartners die Speiche- rung von Bewertungskriterien und eine Ausreißerbehandlung umfassen. Zum Bei- spiel könnte zehnfach die Dauer des Prozesses Kontoeröffnung gemessen und als Bewertungskriterium “Dauer < 15 Minuten” festgelegt worden sein. Dabei könnten neun von zehn Messungen im Bereich von 10 bis 30 Minuten liegen und einer aus unbekannten Gründen 15 Stunden betragen. An dieser Stelle sollte es dem Nutzer möglich sein, diesen Ausreißer als solchen zu kennzeichnen, um eine Herausnah- me aus den Berechnungen zu bewirken. Im Folgenden wurde diesbezüglich auch die Notwendigkeit einer Historisierung der Daten besprochen. Dabei sollten Gültigkeits- bereiche von Bewertungskriterien eingeführt werden, um diese mit dem Messdatum der Prozesse zu verbinden. Geht man zum Beispiel davon aus dass das Kriterium

“Dauer < 15 Minuten” mit Gültigkeitsbereich “01.01.2013 - 15.07.2013” und “Dauer

(25)

Tabelle 3.2: Kernprozesse der Sparkasse (eigene Darstellung)

Prozessbündel Prozess

Produktübergreifende Beratung planen und durchführen Vertriebsaufgaben Finanzkonzept durchführen

Giro / Dienstleistungs- Überweisungen im Euro-Zahlungsverkehrsraum /Serviceaufgaben Kassentransaktionen ausführen

Privatgiro eröffnen Onlinebanking einrichten

Kundendaten Vollmachten bearbeiten

Geldanlage-/ Passivgeschäft Wertpapier-Aufträge bearbeiten

Aktiv Firmen- und Gewerbefinanzierung abschließen Baufinanzierung abschließen

Kontokorrentkredit einrichten

< 17 Minuten” mit Gültigkeitsbereich “16.07.2013 - 31.12.2013” vorliegen. So wür- de ein Prozess dem Messstart-Datum “01.06.2013” mit dem Kriterium “Dauer < 15 Minuten” bewertet werden. Eine detaillierte Darstellung der Historisierung erfolgt im Unterkapitel 3.4.

Des Weiteren gäbe es die Möglichkeit die Anwendung über einen betriebsinternen Server zu betreiben. Jedoch wird durch den höheren administrativen Aufwand und der relativ geringen Anzahl von Importen pro Jahr ein lokaler Betrieb präferiert.

Einen großen Teil der Gesprächszeit nahm die Diskussion über die graphische Dar- stellung der Prozessanzeige in Anspruch. Als Grundlage für Diskussionen diente die Abbildung 3.2. Der Kopfteil sollte als Filterparameter eine Zeitraumangabe aufweisen, wobei weitere Felder als optional betrachtet wurden. Das Visualisieren von Datengrafiken (in Abbildung 3.2 ein Tortendiagramm) wurde generell als weniger wichtig erachtet, aber die Darstellung von Langzeitentwicklungen und Wechselwir- kungen an anderer Stelle durchaus befürwortet. Der Aufbau der Prozessanzeige wurde prinzipiell für Blätterprozesse begrüßt, jedoch für höhere Hierarchieebenen als ungeeignet befunden. Abbildung 3.4 skizziert die Vorstellungen des Sparkassenmit- arbeiters. Neben dem Namen des Prozesses und einem Button zum Tiefergehen in der Hierarchieebene, werden zwei waagerechte Ampelkonstrukte für CTQ und CTB dargestellt. Die Ziffern im Inneren der Ampel für CTQ können folgendermaßen in- terpretiert werden. Insgesamt sind dem Prozess “Inzahlungsverkehr” fünf Prozesse untergeordnet. Drei von Ihnen wurden als effizient, einer als gefährdet und einer als

(26)

kritisch bewertet.

Abb. 3.4: Skizze der Prozessanzeige von Nichtblätterprozessen (eigene Darstellung)

Zusammenfassend lässt dich sagen, dass das Vorhandsein einer Historisierungsfunk- tion und eine modifizierte Prozessanzeige auf den Nichtblätterebenen die wichtigsten Erkenntnisse des Gespräches darstellten.

3.3 Funktionale Endkonzeption

Die in den Unterkapiteln 3.1 und 3.2 beschriebenen Analysen bildeten im Folgen- dem den Startpunkt für die Konzeption eines ersten Prototypen. Dieser Prototyp sollte in erster Linie dazu dienen, einem Kunden die Idee einer Cockpitsoftware zur Prozesssteuerung bzw.-kontrolle präsentieren zu können. Wodurch es leichter wäre konkrete grafische und funktionale Anforderungen zu ermitteln und zu überprüfen, welche Nachfrage für ein solches Produkt besteht. In zweiter Linie soll in Erfahrung gebracht werden, ob das gewählte Framework zur Umsetzung der Anwendung geeignet ist. Dieser Thematik widmet sich das Kapitel 4. Da die Art der vorliegenden Informationen noch sehr abstrakt waren, bot sich die Erstellung eines klassischen Lasten- oder Pflichtenheftes nicht an. Die Eckpfeiler für die Entwicklung des Pro- totypen bildeten zum einen die Zusammenstellung von funktionalen Anforderungen samt Rahmenbedingungen und zum anderen Skizzen der funktionalen Inhalte der Prozessanzeige.

Als Rahmenbedingungen werden die Anforderungen betrachtet, welche keine funktionale Bedeutung für den Prototypen aufweisen und somit als Eigenschaften der Anwendung verstanden werden können. Diese Eigenschaften können sowohl techni- scher als auch rechtlicher Natur sein.

Festgelegte Rahmenbedingungen 1. keine Lizenzgebühren

2. keine Wartungs- und Weiterentwicklungsverpflichtungen für PPI

(27)

3. benutzerfreundlich aufgrund schlanker Verwaltungsfunktion 4. Cockpit muss ergonomisch sein

5. neutrale Farbgebung

Um die Erwerbskosten für den Kunden zu minimieren, darf die Anwendung keine Lizenzgebühren beinhalten. Des weiteren sieht das Entwicklungsunternehmen PPI nicht vor einen Wartungsvertrag mit dem Kunden abzuschließen oder eine wie auch immer geartete Weiterentwicklungsverplichtung nach dem Verkauf der Anwendung einzugehen. Es wird auch davon ausgegangen, dass die Umsetzung einer kompakten Verwaltungsfunktion zur Steigerung der Benutzerfreundlichkeit, entscheidend für die Akzeptanz beim Kunden sein wird. Ebenso entscheidend wird die Konzeption der Prozessanzeige bezüglich ihrer Ergonomie sein. Ziel der Anforderungen drei und vier ist es die Anwendung intuitiv bedienbar und somit selbsterklärend zu gestalten.

Aufgrund dessen sollte die Bedienungsanleitung nicht länger als zwei Seiten sein. Als letzte Rahmenbedingung muss grafische Oberfläche der Anwendung eine neutrale Farbgebung besitzen und darf keine Kundenlogos oder ähnliches enthalten.

Die funktionalen Anforderungen werden in die Kategorien Muss-, Soll- und Kann- Kriterien unterteilt. Dabei beschreiben die Muss-Kriterien die funktionalen Mindest- anforderungen der Anwendung.

Muss-Kriterien

1. Anzeige von Prozessdaten auf drei Ebenen nach Skizze 2. Bewegen in den Prozessebenen

3. Ausreißer-Behandlung ermöglichen 4. Verwaltung von Bewertungskriterien 5. Verwaltung von Oberprozessen

6. unterschiedliche Gewichtung der CTQ und CTB eines Prozesses

7. Import und Zusammenführung von Basisdaten aus verschiedenen Daten- quellen

8. nicht automatisierte Importfunktion

9. keine Veränderung importierter Daten zulässig 10. Historisierung von den Bewertungskriterien

(28)

Das Cockpit muss als seine Grundfunktionalität eine Anzeige von Prozessdaten auf drei Ebenen aufweisen. Der Inhalt der Prozessübersicht spiegelt die Analyse von gemessenen Prozessen gegenüber deren Erwartungswerten wider. Das Instrument dieser Analyse ist die Qualitätsmanagementmethode Six Sigma. Der Zweck der An- zeige wird es sein, die Geschäftsprozesse des betrachteten Unternehmens zu optimieren, um die Kundenzufriedenheit und Effizienz der Mitarbeiter bzw. Maschinen zu maximieren. Abbildung 3.5 zeigt die oberste Ebene der Prozessansicht, welche exemplarisch diverse Hauptprozesse darstellt. Wie ein solcher Prozess, wie “Inzah- lungsverkehr”, zu lesen ist, wurde bereits in Abbildung 3.4 erklärt.

Abb. 3.5: Oberste Ebene der Prozessansicht (eigene Darstellung)

Die Abbildung 3.6 visualisiert exemplarisch ein Tiefergehen in den Prozess “Privat- giro”. Auf dieser Ebene wird eine Einzelansicht des Prozesses “Privatgiro”, sowie Darstellungen seiner untergeordneten Prozesse angezeigt. In diesem Beispiel besteht

“Privatgiro” aus den Unterprozessen “Privatgiro eröffnen”, “Privatgiro schließen”

und “Konditionen erfassen”. Da diese untergeordneten Prozesse Blätter der Baum- struktur darstellen, wurden für sie eine bestimmte Anzahl von Messungen vorgenommen aus denen sich Erfüllungsgrade berechnen lassen. Diese Grade werden, unterteilt nach CTQ und CTB, als eingefärbter Prozentwert neben dem Prozessna-

(29)

men darstellt. Ihre Einfärbung visualisiert die Bewertung des Erfüllungsgrades. Eine rote Färbung kennzeichnet kritische, schwarz gefährdete und grün effiziente Pro- zesse. Beispielsweise wurden für den Prozess “Privatgiro schließen” 54 Messungen vorgenommen, welche einen gefährdeten CTQ-Erfüllungsgrad von 87% und einen effizienten CTB-Erfüllungsgrad von 91% aufweisen. Neben den Prozentwerten lässt sich in einem Tachometer-Diagramm erkennen, wie dicht der Erfüllungsgrad an den Grenzen der Bewertungsmaßstäben kritisch, gefährdet und effizient liegt. Der CTB- Erfüllungsgrad von 91% ist nur knapp effizient, wobei der CTQ-Erfüllungsgrad kurz davor ist effizient zu sein. Wie ein solcher Erfüllungsgrad im Detail zustande kommt und welche Daten dazu benötigt werden, wird im Unterkapitel 3.4 erläutert. Grund- sätzlich besteht ein Erfüllungsgrad aus mindestens einem Bewertungskriterium.

Abb. 3.6: Tiefergehen in “Privatgiro” (eigene Darstellung)

Um herauszufinden welches oder welche Bewertungskriterien das sind, wird ein Tiefergehen in eine dritte Ebene ermöglicht. Abbildung 3.7 zeigt dies exemplarisch für den Prozess “Privatgiro eröffnen”. Generell werden bei dieser Anzeige alle Bewer- tungskriterien des Prozesses angezeigt. Um einen Vergleich zwischen dem erwarteten und realisierten Ergebnis anstellen zu können, wird zu jedem Kriterium der Erwar- tungswert nach CTQ bzw. CTB, der Durchschnitt und der Median dargestellt. Ein Bewertungskriterium bezieht sich immer auf ein konkretes Messattribut, wie die

(30)

Dauer des Prozesses. Auf der dritten Ebene der Prozessansicht wird die Bezeich- nung des Prozessattributes in Klammern nach dem Bewertungstyp angezeigt. In der erste Zeile der Abbildung 3.7 wäre das “CTQ(Dauer)”. Bei diesem Kriterium lässt sich erkennen, dass der Durchschnitt von 14,8 Minuten und einem Median von 15,2 Minuten über dem Erwartungswert von 10 bis 13 Minuten liegen. Ein nahezu ähnli- ches Ergebnis liefert auch der zweite CTQ “Mitarbeiterbewertung” und zusammen ergibt sich aus den beiden Messattributen ein Erfüllungsgrad von 70%. In diesem Beispiel würden beide CTQ zu relativ gleichen Anteilen eine kritische Bewertung ver- antworten. Es wäre jedoch auch eine Konstellation denkbar bei der einer der CTQ sehr viele und der andere fast keine Fehler aufweist und im Mittel auch der Wert von 70% Erfüllungsgrad sich errechnet. In diesem Fall käme es zu völlig anderen Korrekturmaßnahmen innerhalb der Unternehmung. Mit der Verwirklichung einer Visualisierung der drei Prozessebenen und der Bewegung zwischen ihnen, würden die Muss-Kriterien eins und zwei umgesetzt werden.

Abb. 3.7: Tiefergehen in “Privatgiro eröffnen” (eigene Darstellung)

Der zweite Baustein, bestehend aus mehreren Muss-Kriterien, stellt die Realisierung von Verwaltungsfunktionen dar. Diese sollten über Eingabemasken der technischen

(31)

Realisationsvariante gesteuert werden können und ein Pflegen von Bewertungskrite- rien, Bewertungsgrenzen und Oberprozessen in der Datenbasis ermöglichen. Im We- sentlichen beinhaltet die Pflege von Daten das Anlegen, Ändern und Löschen. Und Bewertungsgrenzen kennzeichnen den effizienten, gefährdeten und kritischen Bereich der Erfüllungsgrade. Zum Beispiel könnte definiert werden, dass der kritische Be- reich zwischen 0 und 70 Prozent liegt. Weiterhin muss zum einen eine Zuordnung von Prozessen zu einem Oberprozess angeboten werden, um die Erstellung einer Baum- struktur der Prozesse realisieren zu können. Und zum anderen muss eine Möglichkeit zur Gewichtung von CTQ oder CTB geschaffen werden, welche die Berechnung des Erfüllungsgrades beeinflussen. Detaillierte Zusammenhänge der Anforderungen der Verwaltungsfunktionen sind wiederum dem Unterkapitel 3.4 zu entnehmen. Eine besondere Stellung unter den Verwaltungsfunktionen nimmt die Ausreißer-Behandlung ein. Da es laut Muss-Kriterium neun nicht möglich sein wird Messungsdaten nach dem Import zu verändern oder zu löschen, ermöglicht diese Funktion das Markieren von einzelnen Messwerten als Ausreißer. In die Erfüllungsgrad-Berechnung gehen lediglich Messwerte ein, die keine Ausreißer darstellen.

Der Import und die Zusammenführung von Daten aus den verschiedenen Datenquel- len, wie der PPS, MS EXCEL und Workflowsystemen, sind der dritte und letzte Bau- stein der Muss-Kriterien. Die Hauptaufgabe dabei stellt die Zusammenführung von Prozesswerten dar, obwohl diese unterschiedliche Einheiten und/oder Datentypen besitzen. Die Dauer eines Prozesses kann zum Beispiel in Sekunden oder Minuten hinterlegt worden sein, sowie eine Mitarbeiterbewertung durch den Kunden in Form eines Wortes oder Skalenwertes. Da kein permanentes Monitoring der Prozessdaten erfolgt, ist großer zeitlicher Abstand zwischen den Importzeitpunkten ausreichend.

Ausgegangen wird von Zyklen im Bereich von Monaten, Quartalen oder einer jährli- chen Datenerhebung. Im Rahmen der Erstellung eines Prototyps sollen Prozessdaten der PPS und eines manuell erstellten Excel-Sheets importiert werden können.

Eine Besonderheit stellt die geforderte Historisierung der Bewertungskriterien CTQ und CTB dar. Diese Kriterien müssen mit Attributen versehen werden, welche einen Gültigkeitszeitraum angeben. Dem Löschen oder Verändern der Bewertungskriterien muss ein Abspeichern des “alten” Bewertungskriteriums folgen.

Soll-Kriterien

1. Drucken und PDF-Erzeugung

2. Vordefinierte Reports als Zusatzfunktion

(32)

Soll-Kriterien stellen keine Mindestanforderungen dar, steigern jedoch deutlich den Nutzen der Anwendung. Das Ausdrucken der angezeigten Prozessansicht und die Er- zeugung eines PDF-Dokumentes über diese Darstellung werden dem Nutzer ermög- licht. Vordefinierte Reports über die Langzeitentwicklungen von Six Sigma Kenn- zahlen, Wechselwirkungen einzelner Prozesse und ein Report “Jahresübersicht für die Geschäftsführung” werden ebenfalls im Funktionsumfang des Cockpits enthalten sein.

Kann-Kriterien

1. Rollen und Rechte

2. Permanenter Zugriff auf Tool

Als Kann-Kriterien werden wünschenswerte Anforderungen mit mäßigem Nutzen- zuwachs betrachtet. Die Anwendung wird mit einer Login-Prozedur starten, welche nur autorisierten Personen den Zugang erlaubt. Dabei wird dem Nutzer eine Rollen- und Rechteverwaltung zur Verfügung gestellt. Es wird eine technische Umsetzung bei der jederzeit auf die Anwendung über das Internet zugegriffen werden kann, realisiert.

3.4 Datenbeschreibung

Nach der Erfassung und Priorisierung von funktionalen Anforderungen und Rah- menbedingungen stell die Beschreibung der benötigten Daten den finalen Schritt der Konzeption dar. Für die Beschreibung der Daten ist zunächst ein Blick auf die zu konvertierenden Importdaten notwendig. Wie in der Endkonzeption dargelegt wurde, soll die Prototyp-Anwendung die Datenquellen WEB DATA COLLECTOR^R und einer manuell auszufüllenden Excel-Datei konvertieren können. Abbildung 3.8 zeigt einen Auszug eines Beispieldatensatzes, welcher sieben gemessene Prozesse des Prozesstyps “Bestand” enthält. Zunächst ist ersichtlich dass eine eindeutige Iden- tifizierung eines Prozesses über das Attribut “Vorgang ID” realisiert wurde. Über das Attribut “Prozess” lässt sich Prozesstyp bestimmen, während “Fallabschluss”

und “Erstbearbeitung” als Filter für die Konvertierung betrachtet werden können.

Denn ein Prozess muss bei beiden Attribute “ja” enthalten um als fehlerfrei erfasster Prozess zu gelten. Ein mögliches Zustandekommen eines “nein” bei der Erstbearbei- tung ist die stetige Messung des Prozesses unter dem Parameter “Folgebearbeitung”

(einzige Alternative der Parameter “Erstbearbeitung”), welchen ein PPS-Nutzer vor jeder Messung festlegt. Ein “nein” bei dem Attribut “Fallabschluss” entsteht durch

(33)

die fehlende Kennzeichnung als abgeschlossener Prozess durch den Nutzer. Entwe- der wurde dabei die Messung nicht beendet oder die Kennzeichnung vergessen. Des weiteren enthalten die Daten Informationen über den genauen Start- und Endzeit- punkt der Messung. Die für Bewertungskriterien relevante Attribute stellen “Dauer (ms)”, “Pause (ms)” und “Durchlaufzeit (ms)” dar. Das in den Klammern stehende

“ms” steht für die Einheit Millisekunden. Alle drei Zeiten sind als aggregierte Grö- ßen zu verstehen, welche aus vielen kleinen Einzelzeiten entstanden. Da nur diese aggregierten Größen für den Prototypen von Bedeutung sind, wird an dieser Stelle auf eine detaillierte Erläuterung der Herkunft verzichtet. Es sei jedoch erwähnt das die Subtraktion der Startdatumszeit von Enddatumszeit die Durchlaufzeit ergibt.

Und die Diskrepanz zwischen Durchlaufzeit und Dauer, die Liegezeit darstellt. Aus Gründen des Betriebsschutzes werden die Attribute “Standort” und “OE” (Organi- sationseinheit) nicht verwendet.

Abb. 3.8: Ausschnitt aus Beispieldatensatz der PPS-Importdatei (eigene Darstellung)

Basierend auf diesen Anfangsbetrachtungen kristallisierte sich nach mehreren Ent- würfen eine Datenstruktur heraus, welche es ermöglichen sollte alle funktionalen Anforderungen umzusetzen. Eine vereinfachte Darstellung der vorgesehenen Daten- struktur diente dem leichteren Verständnis und als Diskussionsgrundlage. Um An- sätze für die Entwicklung der Anwendung und für eine eventuell eintretende Weiter- bzw. Neuentwicklung schaffen, dienen ein ER-Modell² und relationales Datenbank- modell. Abbildung 3.9 zeigt das vereinfachte Diskussionsmodell, welches alle Enti- täten mit Beispielen enthält.

Den Ausgangspunkt der Datenstruktur bildete die Entität Prozess. Ein Prozess beinhaltet die importierten Daten von verschiedenen Quellen, den Quellennamen und das Importdatum. Aufgrund der Tatsache, dass die Anzahl an Prozesswerten von Importquellen unterschiedlich sein kann, wird jedem Prozess eine variable Anzahl von Prozesswerten zugeordnet. Es erfolgt eine Auflistung dieser Prozesswerte in der Tabelle Prozesswert mit den Attributen Prozesswertname, Messwert und Einheit.

2Ein ER-Modell oder ERM (Entity Relationship Model) ist ein grafisches Hilfsmittel für den Ent- wurf von Datenbanken. In diesem Modell werden die realen Zusammenhänge von Ereignissen, Handlungen, Objekten oder Anwendungen modelliert und diese in Relation zueinander gesetzt.

(34)

Abb. 3.9: Vereinfachte Darstellung der Datenstruktur (eigene Darstellung)

Um alle Prozesswerte ihrem dazugehörigen Prozess zuordnen zu können, dient der Vergleich der Prozessnummer der Tabelle Prozess und Prozesswert. Jede Quelle muss eine Information über eine Art Buchungsnummer, hier “Vorgangsnummer”, und einen Prozesstypnamen zum referenzieren der Prozesse aus anderen Quellen besitzen. Über die Buchungsnummer ist dann es möglich Prozesswerte aus verschiedenen Quellen einem Prozess zuzuordnen. Und durch den Prozesstypnamen wird die Aggregation von Prozessen aus verschiedenen Importquellen unter einem Prozesstyp gesteuert. Die Attribute Vorgangsnummer, Prozesstypnamen und die Informationen über Start und Ende der Messung eines Prozesses werden durch ihre Unabdingbar- keit aus den Quelldaten gefiltert und direkt als Attribute der Tabelle Prozess zugeordnet. Diese vier Attribute, der Importquellenname und das Importdatum können somit als Ergebnisse einer Konverter-Funktionalität verstanden werden, welche die Importdaten verschiedener Quellen und Messstrecken einer Quelle zusammenführt.

Obwohl zusammengeführte Prozesse in der Tabelle “Prozess” getrennt aufgenom- men werden, um ihre Quellenidentität und Importdatum separat zu speichern, wird die Hauptfunktionalität der Anwendung diese zwei Tabellenelemente als einen Pro- zess betrachten. Zu sehen in der Abbildung bei Prozess 1 und 3, die die gleiche Vorgangsnummer “5001” aufweisen. Das Attribut “Ausreißer?” ist nötig um eine Ausreißerbehandlung zu ermöglichen. Dabei steht der Wert 0 für: kein Ausreißer

(35)

und der Wert 1 für: Prozess ist ein Ausreißer und soll nicht in Reports und Be- rechnungen mit einfließen. In die Tabelle Prozesstyp werden alle unterschiedlichen Prozessnamen von der Tabelle Prozess einmalig als ein Element erfasst. Jedes Ele- ment enthält neben dem Prozesstypnamen, eine Information über die Wertung von Erfüllungsgraden und ob dieser Prozesstyp einem Oberprozess untergeordnet wurde.

Da die Anwendung eine Darstellung von Erfüllungsgraden für jeden Prozesstypen nach dem Ampelsystem mit den Farben Grün, Gelb und Rot anstrebt, werden die Attribute “Start-gelb” und “Ende-gelb” benötigt. Die Tabelle Oberprozess entsteht durch das Anlegen von übergeordneten Prozessen, bezüglich eines Prozesstyps, durch den Nutzer. Neben der Vergabe des Namens für den Oberprozess, werden Prozess- typen ausgewählt welche Unterprozesse dieses Oberprozesses sein sollen. Realisiert wird dies durch die Zuordnung des Attributes “Oberprozessnummer” in den Ta- bellen Prozesstyp und Oberprozess. Somit wird eine inhaltliche Gruppierung von Prozessen ermöglicht. Jeder Prozess kann einem oder keinem Oberprozess zugeordnet werden. Weiterhin ist es möglich, dass einem Oberprozess als untergeordnete Oberprozesse zugeordnet werden. Hierbei würde man von unterschiedlichen Hier- archiestufen innerhalb von Oberprozessen sprechen. Eine solche Hierarchie ergibt durch das Setzen des Attributes “Unterprozess von”. Zu jedem Prozesstyp können eine Reihe von CTQ und CTB angelegt werden. Die Zuordnung von CTQ und CTB zu einem Prozesstyp erfolgt über das Attribut Prozesstypname. Jedes Element der Tabellen CTQ und CTB beinhaltet alle Informationen eines Bewertungskriteriums.

Die Namen dieser Kriterien können dabei einzelne Wörter, wie Dauer und Pause, oder Wortgruppen oder ganze Sätze sein. Von enormer Wichtigkeit ist das korrek- te Eintragen des Attributes Vergleichswertname. Dieser dient zur Ermittlung des Prozesswertes, für den geprüft wird, ob er im Bereich der Erwartungen des Kunden bzw. Unternehmens liegt. Diesen Bereich beschreiben die Attribute CTQ/B-Typ und Erwartung-Wert(e). Für jeden einzelnen CTQ/B-Typ erfolgt eine spezielle al- gorithmische Auswertung. Um einen Vergleich von Prozess- und Erwartungswerten mit unterschiedlichen Einheiten zu ermöglichen, enthalten die Tabellen CTQ, CTB und Prozesswerte das Attribut Einheit. Vorgesehen ist der Umgang mit Zeitein- heiten von Millisekunden bis Tage, ein ja/nein Typ und der Einheit “Skala 1 bis 10”. Die Einheit “Skala 1 bis 10”wird z.B. für eine Mitarbeiterbewertung verwendet, wobei mögliche Messwerte für 1 (sehr schwach) bis 10 (sehr gut) stehen würden.

Sollte der gewünschte Vergleichswertname nicht als Prozesswert vorliegen, wie die Liegezeit nach PPS-Import. So ist es möglich diese als Differenz aus den Prozesswer- ten “Durchlaufzeit” und “Dauer”, händisch als Excel-Import in der Datenbank zu hinterlegen. Die Bewertungskriterien CTQ und CTB unterliegen in gewissen Zeit-

(36)

abschnitten einem stetigen Wandel. Da jedoch Berichte über Prozessdaten immer zu der Zeit gültigen CTQ und CTB bewertet werden, erhält jedes CTQ- und CTB- Element das Attribut Gültigkeitsbereich. Dieses Attribut wird durch einen Algorith- mus verwaltet, welcher nach jeder Änderung eines Elementes, einen neuen CTQ oder CTB anlegt. Beim alten Element wird das aktuelle Datum als Enddatum und beim neuen Element als Anfangsdatum gesetzt. Danach wird dem Enddatum des alten Elementes ein Tag abgezogen. Bei neuen Elementen wird “offen” als Enddatum ein- getragen, was ein nicht näher spezifiziertes Enddatum symbolisieren soll. Abbildung 3.10 zeigt genau ein solches Ergebnis bei der Betrachtung von “CTQ-Nummer” 1 und 2. Durch den Vergleich der Attribute “Messungsstart” und “Messungsende” der Tabelle Prozess und dem Gültigkeitsbereich der Tabelle CTQ bzw. CTB, werden die Bewertungskriterien den Prozessen zeitlich zugeordnet. Sollte ein CTQ oder CTB gelöscht werden, so verschwindet das Element nicht, sondern das Enddatum wird auf den heutigen Tag gesetzt.

Abb. 3.10: Vereinfachte Darstellung der Datenstruktur (eigene Darstellung)

Das ER-Modell (Anhang A.2) und das relationale Datenbankmodell (Anhang A.3) enthalten, zusätzlich zum Rest der Konzeption, die Rohimporttabellen der Quellen

“PPS” und “Excel”. Aus diesen beiden Tabellen werden die Tabellen “Prozess”,

“Prozesswerte” und zum Teil die Tabelle “Prozesstyp” generiert.

(37)

Kapitel 4. Entwicklung

4 Entwicklung

Die Aufgabenstellung sah vor ein lizenzfreies Framework einzusetzen, welches eine dem Entwickler bekannte Programmier- bzw. Auszeichnungsprache verwendete. Zu- nächst lag es nahe über Open-Source BI-Tools¹ zu recherchieren, da sie in Regel für Datenberichte und Cockpitbau geeignet sind. Es wurde nach einem Tool gesucht, mit dem die benötigten Verwaltungsfunktionen möglichst schnell und die Anforderungen an die Prozessanzeige inhaltlich, umzusetzen wären. Alternativ wurde die Möglich- keit verfolgt ein Java basiertes Framework zusammen mit BIRT einzusetzen. BIRT, ausgesprochen: Business Intelligence and Reporting Tools, ist ein frei verfügbares Projekt, welches Berichts- und BI-Funktionalitäten für verschiedene Schnittstellen bereitstellt. An dieser Stelle hatten sich die zeitlichen Ressourcen derart verknappt, dass die Minimierung der Einarbeitungszeit an Priorität gewann. Das eigentliche Problem bei den Recherchen stellten die fehlenden präzisen Beschreibungen dar- über, wie bestimmte Funktionen zu erstellen seien dar. Die gefundenen Anleitungen beschrieben zumeist sehr umfangreich was alles zu realisieren wäre, aber nicht wie.

Dabei liegt die Vermutung nahe, dass Open-Source Frameworks ihre Einnahmen über Support-Leistung oder den Verkauf der kommerziellen Variante ihres Frame- works generieren möchten. Mit viel Glück können jedoch Foren befunden werden, die genau die eigene Problemstellung diskutieren. Es wurde vom Entwickler die Entscheidung getroffen aus Mangel an Zeit auf ein bekanntes Framework zurück- zugreifen. ORACLE APPLICATION EXPRESS, kurz APEX, stützt sich vor allem auf den Einsatz von SQL²-Abfragen, PL/SQL³, HTML⁴, CSS⁵ und XML⁶-Objekten.

Mit diesem Entwicklungstool lassen sich sehr schnell Weboberflächen gestalten und Verwaltungsfunktionalitäten umsetzen, welche als Grundlage eine Datenbank nutzen. Fraglich waren allerdings der Grad der Einflussnahme auf die Gestaltungsmög- lichkeiten der graphischen Benutzeroberfläche, das Vorhandensein einer Navigations- möglichkeit zwischen hierarchischen Daten und die Realisierungsmöglichkeiten einer

1Business Intelligence-Werkzeuge

2Structured Query Language

3Procedural Language/Structured Query Language

4Hypertext Markup Language

5Cascading Style Sheets

6Extensible Markup Language

(38)

Konvertierungs- nebst Importfunktion. Zu den Funktionalitäten Navigation und Im- port konnten sehr schnell Lösungen gefunden werden. Die Gestaltungsmöglichkeiten der Benutzeroberfläche ist jedoch auf vorgefertigte Templates⁷ beschränkt, auf die jedoch Einfluss genommen werden kann. Die Umsetzung einer Konvertierungsfunk- tion kann durch PL/SQL-Skripte realisiert werden. Aufgrund dieser Erkenntnisse und aufgrund der kostenlosen Verfügbarkeit wurde APEX als Framework für die Entwicklung bestimmt.

4.1 Oracle Application Express (APEX)

APEX dient der deklarativen Entwicklung von datenbankzentrierten Webanwendun- gen auf der Basis von ORACLE. Als deklarativ wird das Definieren von Eigenschaf- ten mittels Editor verstanden. Für die Entwicklung wurde die Version 4.0.2.00.09 verwendet. Komplexe Anwendungsfälle werden über SQL-Funktionen oder Proze- duren implementiert. Die APEX-Applikation wird immer als eine Instanz mit kon- kreter Sitzungsnummer gestartet. Die Grundelemente einer APEX-Applikation sind die Seite, die Region und das Element. Die Applikation definiert sich als Menge von Seiten, welche über Registerkarten, Schaltflächen und Hypertextlinks miteinan- der verbunden sind. Eine Seite wird nach der Art ihrer Verarbeitung definiert. Die Verarbeitung umfasst Ereignisse und Logik, die an diese Ereignisse gebunden sind.

Aufgrund dessen sich Berechnungen, Validierungen oder zeitliche Abfolgen definieren lassen. Auf Grundlage von veränderlichen Metadaten erfolgt eine dynamische Sei- tenwiedergabe. Das Aussehen einer Seite bestimmen sogenannte “Page Templates”.

Sowie eine Applikation aus diversen Seiten, besteht eine Seite aus Regionen. Eine Region entspricht einem bestimmten Typ und besitzt dabei jeweils eine bestimmte Aufgabe. Beispiele für Seiten-Typen wären: HTLM Text, Berichte oder Charts.

Die Art der Darstellung und die Position einer Region wird durch ein zugeordne- tes “Region Template” bestimmt. Es existieren verschiedene Arten von Elementen innerhalb einer Applikation. Auf der einen Seite können globale Elemente definiert werden, auf die von überall zugriffen werden kann. Auf der anderen Seite können Seiten-Elemente erstellt werden, auf die nur innerhalb einer bestimmten Seite zugegriffen werden kann. All diese Elemente werden vorrangig dafür benutzt dynamisch HTML zu generieren. In zirka 50 verschiedene Typen unterteilt sich die Bandbrei- te von Elementen. Diese Typen sind mitunter Texteingabe-Felder, Pop-up-Listen, Checkboxen oder Auswahllisten. Der Wert einer Elementes wird automatisch im

7Eine Mustervorlage oder Schablone für ein Dokument, das die wesentlichen Layout-Elemente enthält und mit Grafiken und Texten gefüllt werden kann.

(39)

“Session State” einer Anwendung gespeichert und kann von überall in der Benutzer- sitzung referenziert werden. In Abbildung 4.1 ist ein Ausschnitt aus der realisierten Ausreißer-Funktion zu sehen. Auf dieser Seite wurden die zwei Regionen “Filter- parameter” und “Ausreisserbehandlung” angelegt. In der ersten Region vom Typ HTML können Filter-Parameter für einen Bericht eingegeben werden, welcher über das Button-Element “P11_FILTERN_LOS” erzeugt wird. Der Bericht selbst wurde in der zweiten Region vom Typ Bericht definiert, welcher auf einer SQL-Abfrage basiert. Die Filterparameter sind Elemente vom Typ Zahlenfeld, Kalenderdatum und Auswahlliste. Eine detaillierte Erläuterung der Ausreißer-Funktion ist in Unterkapi- tel 4.3 nachzulesen.⁸

Abb. 4.1: Bausteine der Ausreißer-Funktion (eigene Darstellung)

Eine Anwendung wird generell in Echtzeit aus den Meta- bzw. Benutzerdaten generiert und in HTML angezeigt. Statt der Generierung von Code werden bei der Erzeugung oder der Erweiterung einer Anwendung die modifizierten Metadaten in einer Datenbank gespeichert. Eindeutig identifiziert wird eine Anwendung über eine Applikationsnummer oder einen alphanumerischen Alias. Dasselbe gilt auch für die Seiten einer Applikation. Beim Start der Applikation, generiert die APEX-Engine eine Sitzungsnummer, welche als Schlüssel für den Session-State⁹ des Anwenders genutzt wird. Die angezeigte URL¹⁰ verweist auf den Ort der APEX-Engine, die

8vgl. Kudraß o.J., S.1

9Beinhaltet Werte über das Verhalten einer APEX-Applikation.

http://docs.oracle.com/cd/E23903_01/doc/doc.41/e21674/concept_ses.htm

10Uniform Resource Locator