Business Process Engineering

Inhaltsverzeichnis

1 Einleitung
1.1 Zielsetzung dieser Arbeit
1.2 Problematik und Motivation
1.3 Abgrenzung
1.4 Aufbau dieser Arbeit

2 Grundlagen der Prozessmodellierung
2.1 Definition
2.1.1 Prozesse
2.1.2 Geschäftsprozess
2.1.3 Geschäftsprozessmodellierung
2.2 Modelle
2.2.1 Ereignisgesteuerte Prozessketten (EPK/eEPK)
2.2.2 Unified Modeling Language (UML)
2.2.3 Petri-Netz
2.3 Tools
2.3.1 Visio
2.3.2 ArgoUML
2.3.3 ARIS (Architektur integrierter Informationssysteme)

3 Herangehensweise bei der Aufnahme bzw. Gestaltung von Geschäftsprozessen
3.1 Erarbeitung einer Zielhierarchie
3.2 Analyse der Prozesskette
3.3 Entwicklung einer Informations- und Organisationsstrategie
3.4 Realisierung der Informations- und Organisationsstrategie

4 Ausgangssituation der readyBAU GmbH
4.1 Beschreibung der Rahmenbedingungen
4.2 Beschreibung des Geschäftsmodells

5 Geschäftsprozesse der readyBAU GmbH
5.1 Übersicht der Geschäftsprozesse
5.2 Einkauf
5.2.1 Der Bestellvorgang bei der readyBau GmbH
5.2.2 Einkaufsprozess Rechnungsprüfung
5.3 Vertrieb
5.3.1 Der Auftragsprozess der readyBau GmbH
5.3.2 Der Rechnungsprozess der readyBau GmbH
5.4 Produktion
5.4.1 Produktionsvorgang
5.4.2 Qualitätssicherung
5.5 Lager
5.5.1 Einlagerung
5.5.2 Versandabwicklung
5.6 Buchhaltung
5.6.1 Aufwandserfassung
5.6.2 Zahlungseingang

6 Kontrollmechanismen / Process Management
6.1 Prozessmanagement
6.2 Prozesscontrolling
6.3 Zertifizierung

7 Fazit

8 Literatur- und Quellenverzeichnis

Abbildungsverzeichnis

Abb. 1: Wertekette nach Porter

Abb. 3: Screenshot ArgoUML

Abb. 4: Sichten des ARIS-Hauses

Abb. 5: Integrierte Informationssysteme

Abb. 6: Ausschnitt der IST-Funktionsstruktur einer Vertriebslogistik Prozesskette

Abb. 7: Entscheidungstabelle Verwendbarkeit Angebote

Abb. 8: Darstellung von Nutzen in Abhängigkeit von erkannten Schwachstellen und eingeleiteten Maßnahmen

Abb. 9: Prozesslandkarte

Abb. 10: Einkaufsprozess Bestellung

Abb. 11: Einkaufsprozess Rechnungsprüfung

Abb. 12: Angebotsprozess im Vertrieb

Abb. 13: Rechnungsprozess Vertrieb

Abb. 14: Prozess Produktionsvorgang

Abb. 15: Prozess Qualitätssicherung in der Produktion

Abb. 16: Lagerprozess Einlagerung

Abb. 17: Lagerprozess Versandabwicklung

Abb. 18: Prozess Aufwandserfassung (Buchhaltung)

Abb. 19: Prozess Zahlungseingang (Buchhaltung)

1 Einleitung

1.1 Zielsetzung dieser Arbeit

Das Ziel dieser Arbeit ist das Darstellen theoretischer Ansätze zur Geschäftsprozessmodellierung und die anschließende praktische Ausarbeitung konkreter Prozesse der readyBau GmbH.

Am Ende der Fallstudie werden verschiede Prozesse aus dem Bereich Einkauf, Vertrieb, Buchhaltung, Produktion und Lager in Form von ereignisgesteuerten Prozessketten vorliegen.

Darüber hinaus werden theoretische Ansätze untersucht und Software-Werkzeuge aktiv eingesetzt.

1.2 Problematik und Motivation

Im Rahmen einer Fallstudie sollen die Geschäftsprozesse der readyBau GmbH, eine Firma mit dem Unternehmenszweck der Herstellung von Fertig-Häusern, modelliert werden. Die Ausarbeitung der Geschäftsprozesse erfolgt innerhalb eines dafür gegründeten Projektteams. Für eine zielführende Ausarbeitung der Prozesse ist es notwendig den Gesamtprozess in Arbeitspakete zu gliedern und diese den Projektmitgliedern zur Ausarbeitung zuzuteilen. Des Weiteren wird der Projektverlauf durch regelmäßige Projektmeetings und klar definierte Meilensteine begleitet. Eine Annäherung an das Thema erfolgt durch Schaffung theoretischer Grundlagen im Bereich der Geschäftsprozess- modellierung. Die gewonnen Ergebnisse werden in Form einer Präsentation aufbereitet und bilden somit den Abschluss der Fallstudie.

1.3 Abgrenzung

Aufgrund der Vielzahl der im Unternehmen vorhandenen Geschäftsprozesse kann im Rahmen dieser Arbeit nur eine Darstellung ausgewählter Kernprozesse erfolgen. Die modellierten Prozesse sind Soll-typische Idealprozesse, die sich unter Umständen aus verschiedenartigen Restriktionen nicht auf reale Unternehmen übertragen lassen. Die Untersuchung der Software-Werkzeuge und Modelle erhebt keinen Anspruch auf Vollständigkeit, sondern soll einen groben Überblick verschaffen.

1.4 Aufbau dieser Arbeit

Die Erarbeitung theoretischer Grundlagen stellt den ersten Aspekt der Arbeit dar. Hierbei werden zunächst Begrifflichkeiten definiert und in den Gesamtkontext eingebracht. Im Folgenden Abschnitt wird eine Auswahl von Werkzeugen und Tools zur Prozess-

Modellierung untersucht. Anschließend wird mittels eines Phasenmodells die Basis zum Verständnis zur Prozessmodellierung geschaffen.

Es folgt die konkrete Modellierung der Geschäftsprozesse der readyBau GmbH anhand der eigens dafür erstellten Prozesslandkarte.

Am Ende der Arbeit wird ein kleiner Überblick über das Geschäftsprozessmanagement und die Zertifizierung gegeben.

Ein Fazit fasst die Erkenntnisse zusammen und bildet den Schlussteil der Arbeit.

2 Grundlagen der Prozessmodellierung

2.1 Definition

Um eine einheitliche Basis und ein genaues Verständnis zu schaffen, werden im Folgenden Abschnitt die Begriffe Prozess, Geschäftsprozess und die Geschäftsprozessmodellierung erläutert.

2.1.1 Prozesse

Der Begriff Prozess stammt aus dem Lateinischen und lässt sich am besten mit Vorgang, Verlauf bzw. Entwicklung übersetzen¹. Bezogen auf eine betriebswirtschaftliche Betrachtungsebene ist ein Prozess eine Menge von Mitteln und Tätigkeiten. Zu diesen Mitteln zählen Personal, Geldmittel, Anlagen, Einrichtungen, Techniken und Methoden. Generell stehen diese Mittel und Tätigkeiten in einer Wechselbeziehung. Prozesse fordern in der Regel Eingaben und geben entsprechende Ergebnisse aus².

2.1.2 Geschäftsprozess

Geschäftsprozesse ermöglichen die betriebliche Leistungserstellung.„Ein Geschäftsprozess besteht aus einer Folge von Tätigkeiten (Aktivitäten), die zur Erfüllung einer betrieblichen Aufgabe notwendig sind. Die Tätigkeiten werden von Aufgabenträgern in organisatorischen Einheiten unter Nutzung der benötigten Produktionsfaktoren geleistet³“. Dabei wird die Abwicklung von Geschäftsprozessen durch in Unternehmen vorhandene Informations- und Kommunikationssysteme unterstützt. Allgemein spricht man in diesem Zusammenhang auch von der betrieblichen Leistungserstellung durch die zusammengehörige Abfolge von Unternehmensverrichtungen⁴.

Beispiele für Geschäftsprozesse sind:

- Angebotserstellung
- Auftragsvergabe
- Beschaffung
- Mahnwesen

Im Allgemeinen gibt es eine Unterscheidung im Unternehmen zwischen den primären Aktivitäten der Leistungserstellung, also den Kernprozessen, und den unterstützenden sekundären Aktivitäten. Dabei wird das Unternehmen nicht als geschlossene Einheit betrachtet, sondern auch die Schnittstellen zur Umwelt berücksichtigt. Dies ist konsequent, weil die Leistungserstellung gewöhnlich aufgrund von externen Aufträgen erfolgt. Die Wertekette von Porter stellt diese Aktivitäten, sprich Geschäftsprozesse, in einer grafischen Form dar, und ist somit der Schritt zur Geschäftsprozessmodellierung.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Wertekette nach Porter

2.1.3 Geschäftsprozessmodellierung

Geschäftsprozessmodellierung ist die modellhafte Beschreibung eines Geschäftsprozesses. Ein Geschäftsprozessmodell ist die Abstraktion von realen Prozessen, meist in grafischer Form. Für die Erstellung von Modellen gibt es verschiedene Vorgehensweisen und Techniken. Diese hängen vom gewünschten Fokus der Modellierung ab, also ob das Modell eher prozess- bzw. vorgangslastig ist, oder ob beispielsweise die Organisation im Vordergrund steht. Als Bestandteil des Geschäftsprozessmanagements bildet die Geschäftsprozessmodellierung die Grundlage für die Implementierung von IT-gestützten Anwendungssystemen⁵.

2.2 Modelle

Geschäftsprozesse können mit unterschiedlichen Herangehensweisen betrachtet und modelliert werden. Im Folgenden Abschnitt werden die Modellierungsmodelle EreignisGesteuerte Prozesskette, Unified Modeling Language und Petri-Netze näher beschrieben sowie deren Einsatzmöglichkeiten voneinander abgegrenzt.

2.2.1 Ereignisgesteuerte Prozessketten (EPK/eEPK)

Ereignisgesteuerte Prozessketten (kurz: EPK) sind grafische Darstellungen, die für die Analyse und Modellierung von Geschäftsprozessen in den 90er Jahren vom Institut für Wirtschaftsinformatik der Universität Saarland unter Leitung von August-Wilhelm Scheer im Rahmen des ARIS (Architecture of Integrated Information Systems)-Konzeptes entwickelt wurden.

Aufgrund hoher Akzeptanz und stark wachsender Bedeutung „prozessorientierter Organisationsstrukturen“ dienen EPKs zunehmend als Grundlage für ein integriertes Geschäftsprozessmanagement. Weite Verbreitung dieser Methodik ist auch darauf zurückzuführen, dass die SAP AG diese Technik zur Modellierung der kompletten R/3- Prozesse verwendet.⁶

Ereignisgesteuerte Prozessketten können für folgende Aufgaben eingesetzt werden:

- Evaluation und Implementierung von Standardsoftware
- Darstellung von Abläufen bei Eigenentwicklungen
- Prozessoptimierung beim Business Process Reengineering
- Analyse und Optimierung von Geschäftsprozessen im Rahmen des Process Performance Management
- Veranschaulichung von Abläufen bei Anwenderschulungen
- Geschäftsprozessmodellierung (Standard in kleinen und mittleren Unternehmen)
- Prozesskostenrechnung
- Modellierung von BPEL-Prozessen
- Simulation von Workflows
- Prozessdokumentation nach ISO 900x

Die Modellierung von Geschäftsprozessen folgt einer gewissen Aufbaulogik. Dabei werden Prozesse als eine Abfolge von Funktionen und Ereignissen betrachtet, wobei Funktionen durch Ereignisse ausgelöst werden und als Ergebnis von Funktionen wiederum Ereignisse entstehen. Somit repräsentieren Ereignisse entweder das Auslösen oder den Abschluss einer Tätigkeit, wo hingegen eine Funktion die aktive Tätigkeit darstellt.⁷ Ereignisse und Funktionen treten somit immer alternierend auf, so können niemals zwei Ereignisse oder Funktionen direkt aufeinander folgen.

Eine erweiterte Form der EPK-Modellierung stellt die erweitere Ereignisgesteuerte Prozesskette (eEPK) dar. Hierbei findet eine Erweiterung der logischen Abläufe eines Geschäftsprozesses um Elemente wie Organisations-, Daten und Leistungsmodellierung erweitert. Die erweiterten Prozessketten werden im Wesentlichen um die Elemente der Beziehungen des Funktionszuordnungsdiagramms ergänzt um zusätzlich die Abbildung von Datenflüssen, Organisationseinheiten oder Anwendungssystemen zu ermöglichen.

Die einzelnen Modellierungselemente sind im Folgenden dargestellt und erläutert:⁸

Ein Ereignis ist eine eingetretene Zustandsänderung und kann eine Vorbedingung für eine Funktion und/oder das Resultat einer Funktion sein. Ereignisse werden mit einer sechseckigen Figur dargestellt und beinhalten immer ein Substantiv, auf das ein Partizip Perfekt folgt. Beispiele: "Ware ist eingetroffen, "Auftrag wurde angenommen" usw.

Eine Funktion ist eine konkrete Aufgabe, die als Teil eines Geschäftsprozesses zu bearbeiten ist. Funktionen beschreiben Teilprozesse. Diese sind zeitraumbezogen. Funktionen werden als betriebswirtschaftliche Vorgänge bezeichnet und beschreiben, was gemacht werden soll. Als Text beinhaltet die Funktion immer ein Substantiv als Objekt und ein Verb, welches die Verrichtung an diesem Objekt beschreibt. Beispiele dafür wären z.B. "Kundenanfrage prüfen", "Bestellung erfassen" usw.

Eine Organisationseinheit kann ein Aufgabenträger, eine Abteilung oder ein Unternehmensbereich sein, der direkt oder indirekt Funktionen bearbeitet. In EPKs werden Organisationseinheiten verwendet, um den Ort der Tätigkeitserledigung festzuhalten. Um eine Organisationseinheit darzustellen, verwendet man eine Ellipse, welche den Namen der Organisationseinheit beinhaltet. Beispiele dafür wären "Einkauf", "Produktion", "Verkauf" oder "Marketingleiter".

Ein Informationsobjekt stellt ein Element der realen Welt, wie z.B. einen Kundenstamm, eine Rechnung oder ein Adressverzeichnis dar. Hierbei handelt es sich um betriebswirtschaftlich relevante Informationen, die zur Bearbeitung einer Funktion benötigt werden oder die von einer Funktion erzeugt werden.

Konnektoren dienen als logische Verknüpfungen zwischen Ereignissen und Funktionen. Mithilfe dieser Konnektoren ist es möglich, alternative (OR), parallele (AND) und zusätzlich exklusiv- alternative (XOR) Abfolgen von Aktionen zu beschreiben.

1. OR
- Die Gesamtaussage ist wahr, wenn mindestens eine Aussage wahr ist

2. AND
- Die Gesamtaussage ist wahr, wenn alle Aussagen gleichzeitig wahr sind

3. XOR
- Die Gesamtaussage ist wahr, wenn genau eine Aussage zutrifft

Abbildung in dieser Leseprobe nicht enthalten

Konnektoren können einen Ablauf in mehrere Teilabläufe unterteilen (Split) oder mehrere Teilabläufe zu einem einzigen Ablauf zusammenführen (Join).

Für die Erstellung von EPKs gelten folgende allgemeine Regeln:

1. EPK werden immer vertikal dargestellt.
- Organisationseinheiten werden links von Funktionen dargestellt.
- Informationsobjekte werden rechts von Funktionen dargestellt.

2. Eine EPK beginnt immer mit einem Ereignis.

3. Es existieren keine isolierten Knoten (Knoten ohne Verbindungen).

Auch die Verbindung zwischen den einzelnen Elementen unterliegt gewissen Regeln, die im Folgenden dargestellt werden:

1. Ein Konnektor hat entweder mehrere Ausgänge oder mehrere Eingänge, aber keinesfalls beides.

2. In einen Konnektor dürfen nur gleichartige Elemente führen (Ereignisse oder Funktionen).

3. Ereignisse und Funktionen müssen auch über einen Konnektor hinweg alternierend sein.

- Fliessen Funktionen in einen Konnektor, muss das Ergebnis ein Ereignis sein.
- Fliessen Ereignisse in einen Konnektor, muss das Ergebnis eine Funktion sein.

4. In einen Konnektor dürfen nur gleichartige Elemente führen (Ereignisse oder Funktionen).

5. Ein Ereignis ist ein passives Element.

- Da passive Elemente keine Entscheidungen treffen können, muss auf ein Ereignis immer der AND-Konnektor folgen.

Ereignisgesteuerte Prozessketten bieten durch die freie Platzierung der Elemente auf der Zeichenfläche Vorteile bei der Darstellung von alternativen oder parallelen Abläufen und bei Rückschleifen sowie bei der Ausnutzung der vorhandenen Zeichenfläche. Die Tool- Unterstützung ist sehr umfangreich und die Beschreibung standardisierter Abläufe ist möglich.

Nachteile hingegen ergeben sich Bei der Erkennung von Organisationsbrüchen (Wechsel der Organisationseinheit), Systembrüchen (Wechsel des Anwendungssystems) oder Datenbrüchen (Wechsel des Datenträgers oder Datenformats).

Des Weiteren ergeben sich Probleme bei der Abbildung kreativer und komplexer Tätigkeiten oder bei der Modellierung von Überwachungs- und Kontrolltätigkeiten.

2.2.2 Unified Modeling Language (UML)

Die Unified Modeling Language ist eine objektorientierte und grafische

Beschreibungssprache zur Visualisierung, Spezifikation, Konstruktion und Dokumentation primär von Softwaresystemen. UML kann somit in verschiedenen Ebenen der Modellierung und Phasen der Softwareentwicklung eingesetzt werden.⁹

Die UML-Techniken werden in Verbindung mit Projektmethoden zu einer objektorientierten Entwicklungsmethode verbunden. Von besonderer Bedeutung sind hierbei das Spiral- und Wasserfallmodell, der Objectory Process, SEPP/OT und das V-Modell. Die UML-Notation wurde von der Objekt Management Group (OMG) standardisiert und ist über ISO zertifiziert UML definiert innerhalb der Sprache Bezeichner für die meisten Begriffe, die für die Modellierung notwendig sind.

UML ist eine für die Modellierung von betrieblichen Anwendungs- bzw. Softwaresystemen die dominierende Methode. Meist erfolgt die Modellierung durch UML-Diagramme. Diese zeigen eine grafische Sicht auf einzelne Ausschnitte.

Reale Geschäftsprozesse können im Rahmen der Geschäftsprozessmodellierung erfasst werden. Im Mittelpunkt stehen dabei Aktivitätsanalysen, nicht Zustandsdarstellungen. Die Geschäftsprozessmodellierung in Verbindung mit dem UML-Instrumentarium kann zur übersichtlichen objektorientierten Darstellung komplexer Abläufe genutzt werden.¹⁰ Folgende UML-Diagramme können zur Modellierung verwendet werden (vgl. hierzu Kapitel 2.3.2):

Abbildung in dieser Leseprobe nicht enthalten

2.2.3 Petri-Netz

Petri-Netze gehören zu den Methoden der Modellierung von Systemen oder von beliebigen Prozessen, insbesondere von Produktionsprozessen. Carl Adam Petri verwendete erstmals 1962 diese Darstellungstechnik und gilt somit als der Erfinder der Petri-Netze.¹¹ In der ursprünglichen Form werden Petri-Netze auch als Bedingungs- oder Ereignisnetze bezeichnet. Vorteile liegen in der formalen mathematischen Fundierung sowie in der klaren Regelung für Zustandsänderungen.¹²

Ein Petri-Netz ist ein Graph, der aus Stellen (Places) und Übergängen (Transitions) besteht, die nicht direkt sondern nur über gerichtete Kanten miteinander verbunden sind. Stellen werden dabei als Kreise und Transitionen als Rechtecke dargestellt. Jede Stelle hat eine Kapazität, die wiederum entsprechende Marken (Token) enthalten. Die Belegung der Stellen heisst Markierung und gibt den Zustand des Petri-Netzes an.

Petri-Netze können für folgende Aufgaben eingesetzt werden:

- Datenanalyse
- Nebenläufige Programmierung
- Paralleler Algorithmus
- Softwareentwurf
- Verwaltung von Arbeitsabläufen
- Verifikation von nebenläufigen Prozessen
- Automatisierung (Steuerungstechnik)
- Schaltkreise

2.3 Tools

Zur Modellierung von Prozessen können verschiedene Software-Werkzeuge eingesetzt werden. Im nächsten Abschnitt werden die Tools Visio, ArgoUML und ARIS dargestellt.

2.3.1 Visio

Visio ist Bestandteil der Microsoft-Office Produktfamilie und ist eine weltweit sehr verbreitetSoftwarezur Visualisierung von Daten, Informationenoder Ergebnissen. Visio liegt in der aktuellen Version 2007 vor und wir nur von Microsoft Windows XP Betriebssystemen oder höher unterstützt. Seit der Visio-Version2003 unterscheidet man zwischen der

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Beispiel einer Workflow-Darstellung mit Visio 2003¹

Standard- und einer Professional-Version, die um einige Funktionalitäten erweitert wurde. Zu den herausragenden Eigenschaften von Visio zählen:

- Visualisierung und Kommunikation von Systemen, Ressourcen, Prozessen und den zugrunde liegenden Daten mit vielfältigen Diagrammtypen
- Integration von Informationen aus unterschiedlichen Quellen
- Reduzierung von wiederholten manuellen Eingaben durch Automatisierungs-
Mechanismen der Daten
- Vielfältige Art der visuellen Darstellung durch bereits vorhandene Vorlagen (Shapes)
- Ausgabe in unterschiedlichen Formaten möglich

Die Funktionsweise von Visio ist sehr intuitiv und erfolgt größtenteils per Drag & Drop. Mit Hilfe unterschiedlicher Vorlagen, die entsprechende Symbole und Werkzeuge beinhalten, können grafische Darstellungen erzeugt werden. Diese Grafiken können wiederum in andere Dokumente eingebettet oder im Visio Format (*.vsd) sowie weiteren Grafikformaten gespeichert werden. Besonders geeignet ist Visio zur Darstellung von Geschäftsprozessen und Flussdiagrammen, sowie technischer Zeichnungen oder UML-Diagrammen.

2.3.2 ArgoUML

ArgoUML ist ein auf Java basierendes Tool zur grafischen Modellierung. Mit ihm lassen sich Standard Diagramme der Unified Modeling Language (UML) erstellen¹³. Mit ArgoUML können diese Diagramme erstellt werden. Eines der Features von ArgoUML ist, dass sich erstellte Diagramme direkt in Programmode umwandeln lassen. Dadurch kann Entwicklungszeit eingespart werden und die Dokumentation des Programms wird als „Nebenprodukt“ mit angefertigt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Screenshot ArgoUML¹⁴

Bei ArgoUML handelt es sich um eine Open Source Software. Sie unterliegt der Berkley Software Distribution (BSD) Lizenz. Es ist somit erlaubt die Software kostenlos zu benutzen und zu verbreiten. Da ArgoUML auf Java basiert, lässt sich die Software plattformunabhängig einsetzten.

[...]

---

¹ Vgl. Brockhaus' Kleines Konversations-Lexikon, fünfte Auflage, Band 2. Leipzig 1911., S. 464.

² Vgl. Herausforderungen der Wirtschaftsinformatik, herausgegeben von René Riedl, Thomas Auinger

³ Staud, Josef, Geschäftsprozessanalyse, 2006, S. 9.

⁴ Vgl. Scheer, Aris Modellierungsmethoden, S. 3.

⁵ Vgl. Scheer, Aris Modellierungsmethoden, S. 4.

⁶ Vgl. Brugger, R.: IT-Projekte strukturiert analysieren (2005), S. 332.

⁷ Vgl. Ferschl, Fink, Schneidereit, Voß: Grundlagen der Wirtschaftsinformatik (2005), S. 122.

⁸ Vgl. Bächle, Kolb: Einführung in die Wirtschaftsinformatik (2007), S.43 ff..

⁹ Vgl. Ferschl, Fink, Schneidereit, Voß: Grundlagen der Wirtschaftsinformatik (2005), S. 130.

¹⁰ Vgl. Westermann (Hrsg.): IT-Handbuch (2005), S. 195.

¹¹ Vgl. Brugger, R.: IT-Projekte strukturiert analysieren (2005), S. 352.

¹² Vgl. Ferschl, Fink, Schneidereit, Voß: Grundlagen der Wirtschaftsinformatik (2005), S. 125.

¹³ Gläßer L.: Open Source Software (2004), S.99.

¹⁴ http://argouml.tigris.org/tours/bdUseCaseDiagram.html (Stand: 11.01.2009)