Spezialisierung von Geschäftsprozessen am Beispiel der Bearbeitung von Kreditanträgen 1 von
Peter KUENG und Michael SCHREFL e-mail: {kueng | schrefl}@dke.uni-linz.ac.at Universität Linz Institut für Wirtschaftsinformatik Data & Knowledge Engineering Altenbergerstraße 69, A-4040 Linz
Herausgeber: o. Univ.-Prof. Dr. Lutz J. Heinrich o. Univ.-Prof. Dr. Gustav Pomberger o. Univ.-Prof. Dr. Michael Schrefl
Institutsbericht 95.01 März 1995 __________________________________________________ 1. Eine gekürzte Fassung dieses Institutsberichtes ist erschienen in: HMD: Theorie und Praxis der Wirtschaftsinformatik, Jg. 32, Heft 185 (September 1995), S. 78-94; ISSN 0939-2602.
Zusammenfassung In diesem Beitrag wird gezeigt, wie das aus der Datenmodellierung und objektorientierten Programmierung bekannte Prinzip der Vererbung von Eigenschaften in Klassenhierarchien auf die Spezialisierung von Geschäftsprozessen vorteilhaft übertragen werden kann. Dazu wird zunächst ein objektorientierter Ansatz zur Modellierung der Geschäftsfalldaten, der Geschäftsprozeßabläufe und der Entscheidungsregeln eines Geschäftsprozesses vorgestellt. Anhand des Beispiels der Bearbeitung von Kreditanträgen wird illustriert, wie Geschäftsfalldaten mit Hilfe von Objektdiagrammen, Geschäftsprozeßabläufe mit Hilfe von Verhaltensdiagrammen (erweiterte Petri-Netze) und Entscheidungsregeln mit Hilfe von Handlungsgeboten und -verboten beschrieben werden können. Anschließend wird das Prinzip der Spezialisierung vorgestellt. Dabei wird der allgemeine Geschäftsprozeß "Bearbeitung eines Kreditantrages" in die spezielleren Geschäftsprozesse "Bearbeitung eines Antrages auf einen Privatkredit" und "Bearbeitung eines Antrages auf einen Hypothekarkredit" überführt.
Inhalt 1 Problemstellung 2 Begriffe und Definitionen 2.1 Welche Arten von Geschäftsprozessen gibt es? 2.2 Welche Arten von Geschäftsregeln gibt es? 3 Modellierung von Geschäftsprozessen 3.1 Modellierung von Geschäftsfalldaten 3.2 Modellierung von Geschäftsabläufen 3.3 Modellierung von Entscheidungsregeln 4 Spezialisierung von Geschäftsprozessen 4.1 Spezialisierung von Geschäftsfalldaten 4.2 Spezialisierung von Geschäftsabläufen 4.3 Spezialisierung von Entscheidungsregeln 5 Schlußfolgerungen und Ausblick 6 Literatur
P. Kueng / M. Schrefl
Institutsbericht 95.01
Seite 2
1.0 Problemstellung Zur Abwicklung von Geschäftsprozessen existieren in den Unternehmen viele Einzellösungen - und zwar sowohl auf organisatorischer als auch auf technischer Ebene. Ferner sind Geschäftsregeln oft nur partiell dokumentiert. Sie befinden sich im Programmcode der Applikationen, in Datenbanken, in Organisationshandbüchern oder zu einem gewissen Teil gar nur in den Köpfen der Mitarbeiter. Diese Situation ist insofern unbefriedigend, als die Gefahr besteht, daß gleiche Sachverhalte (z.B. die Kreditanträge zweier “vergleichbarer” Kunden) unterschiedlich behandelt werden. Damit eng verbunden ist der Nachteil, daß die Bearbeitung eines Geschäftsfalles ex-post manchmal nur schwer nachvollzogen werden kann. Hinzu kommt, daß die zerstückelte, teilweise redundante “Speicherung” von Geschäftprozeßbeschreibungen und ihren zugehörigen Regeln das Ändern sehr zeitaufwendig macht; vgl. dazu auch [Knolmayer/Herbst 93]. Vor diesem Hintergrund stellen sich also die beiden folgenden Fragen: Wie können Geschäftsprozesse allgemeingültig formuliert werden (so daß sie für die einzelnen operativen Systeme spezialisiert und als Bausteine wiederverwendet werden können) und wie können Geschäftsprozesse durchschaubar und modular formuliert werden? Um diese beiden Fragen zu beantworten, wird im unserem Beitrag untersucht, inwiefern das aus der objektorientierten Modellierung bekannte Konzept der Spezialisierung auf Geschäftprozesse übertragen werden kann. Am Rande sei vermerkt, daß die Problematik einer möglichen Implementierung im vorliegenden Beitrag nicht behandelt wird; einige interessante Anhaltspunkte hierzu können [Herbst 95] entnommen werden. Des weiteren betrachten wir nur einen einzigen Geschäftsprozeß und gehen daher auf die Problematik der Kopplung mehrerer Geschäftsprozesse nicht ein. Im nachfolgenden Beitrag orientieren wir uns an einem realen, jedoch verkürzt wiedergegebenen Geschäftsprozeß. Um die nachfolgenden Gedankengänge nachvollziehen zu können, wird der Geschäftsprozeß kurz geschildert: Eine Geschäftsbank vergibt Kredite, und zwar Privatkredite und Hypothekarkredite. Für die Bearbeitung eines Kreditantrages gilt allgemein folgender Ablauf: Beantragt ein Kunde einen Kredit, so holt die Bank eine Lohnbestätigung ein und prüft die Kreditwürdigkeit des Kunden, indem sein verfügbares Einkommen (der monatliche Lohn minus Fixausgaben für Miete, Auto, übrige Lebenskosten) zur monatlichen Rückzahlungsrate in Beziehung gesetzt wird. Ist die Bonitätsprüfung abgeschlossen, wird der Kreditantrag vom Sachbearbeiter gutgeheissen (d.h. der Kredit gewährt) oder abgelehnt oder an den Vorstand weitergeleitet. Dieser entscheidet nach einer weiteren Prüfung über Gewährung oder Ablehnung. Je nach Entscheidung erhält der Kunde einen Bestätigungs- oder einen Ablehnungsbrief. Bei Privatkrediten wird zur Bonitätsprüfung noch eine Anfrage beim Kreditschutzverband durchgeführt und das pfändbare Gehalt ermittelt. Handelt es sich um einen Hypothekarkredit, so muß zur Bonitätsprüfung noch die Liegenschaft geschätzt, ein Grundbuchauszug eingeholt und die Belehnungsgrenze ermittelt werden. Bei der Bearbeitung eines Kreditantrages fallen allgemein folgende Geschäftsfalldaten an: die Antragsnummer, die Kredithöhe, die Rate, die Lohnbestätigung des Kreditwerbers, das berechnete verfügbare Einkommen und der Bearbeitungsstatus. Bei Privatkrediten sind zusätzlich das Ergebnis der Kreditschutzverbandabfrage und die Höhe des pfändbaren Gehaltes von Bedeutung. Bei Hypothekarkrediten fallen die beiden letztgenannten Daten nicht an, hinzu kommen jedoch die Grundstücksdaten, der Grundbuchauszug, der Schätzwert des Grundstücks, die Vorbelastungen und die ermittelte Belehnungsgrenze. Für den Sachbearbeiter gelten - unabhängig von der Art des Kredites - folgende Entscheidungsregeln: (1) Er muß den Kredit ablehnen, wenn das verfügbare Einkommen des Kunden kleiner als 50% der Rate ist. (2) Er darf einen Kredit keinenfalls gewähren (d.h. er kann ihn ablehnen oder an der Vorstand weiterleiten), wenn das verfügbare Einkommen kleiner als 70% der Rate ist.
P. Kueng / M. Schrefl
Institutsbericht 95.01
Seite 3
(3) Er darf einen Kredit keinenfalls ablehnen (d.h. er kann ihn gewähren oder an der Vorstand weiterleiten), wenn das verfügbare Einkommen größer oder gleich die dreifache Rate ist. (4) Er muß den Kredit gewähren, wenn das verfügbare Einkommen größer oder gleich die dreifache Rate ist und der gewünschte Kredit 100 000 öS nicht übersteigt. (5) Er muß den Kredit an den Vorstand weiterleiten, wenn das verfügbare Einkommen größer oder gleich die dreifache Rate ist und der gewünschte Kredit 900 000 öS übersteigt. Diese Entscheidungsregeln werden bei Privatkrediten und Hypothekarkrediten durch weitere ergänzt. Aus Platzgründen wollen wir hier nur eine exemplarisch anführen: Der Sachbearbeiter muß einen Privatkredit gewähren, wenn der beantragte Kredit den Betrag von 100 000 öS nicht übersteigt und das verfügbare Einkommen größer oder gleich 80% der Rate und der pfändbare Gehaltsanteil größer oder gleich 100% der Rate ist. (Anmerkung: Der Kreditwerber kann sich aufgrund seines aktuellen Lebensstils den Kredit möglicherweise nicht leisten, aber eine Sicherstellung durch eine Gehaltspfändung ist gegeben).
In der obigen textuellen Beschreibung sind bewußt bereits die Gemeinsamkeiten und Unterschiede der Geschäftsprozesse "Bearbeitung eines Antrags auf einen Privatkredit" (kurz: "Privatkreditantrag") und "Bearbeitung eines Antrags auf einen Hypothekarkredit" (kurz: "Hypothekarkreditantrag") herausgearbeitet. Diese sollen auch in der Darstellung in einem Geschäftsprozeßmodell zum Ausdruck kommen, um eine kompakte, redundanzfreie und gut überschaubare Beschreibung von Geschäftsprozessen zu ermöglichen.
2.0 Begriffe und Definitionen Bevor wir das Konzept der Spezialisierung auf Geschäftsprozesse anwenden, wollen wir die für diesen Beitrag zentralen Begriffe kurz erläutern.
• Aktivität = Arbeitsschritt = Tätigkeit = Teilprozeß: “Eine Aktivität ist eine betriebliche Tätigkeit mit einem definierten Ergebnis. Sie wird von Menschen und/oder Maschinen durchgeführt” [Österle 93, S. 13].
• Geschäftsprozeß = Prozeß = Geschäftsprozeß-Beschreibung = Geschäftsprozeß-Definition = Prozeßkette: Unter einem Geschäftsprozeß verstehen wir die potentiellen Arbeitsschritte die zur Erfüllung eines geschäftlichen Ziels notwendig sind. Ähnliche Definitionen finden wir in [Elgass/Krcmar 93, S. 43] und [Bauer et al. 94, S. 101]: “Ein Prozeß ist eine Folge von Aktivitäten, die in einem logischen Zusammenhang zueinander stehen und inhaltlich abgeschlossen sind”, beziehungsweise “... a business process may be seen as a bundle of goal directed actions that are performed by actors.”
• Geschäftsregeln beschreiben, welche Arbeitsschritte in einer gegebenen Situation durchzuführen sind. Oder in Anlehnung an [Herbst/Knolmayer 94] machen Geschäftregeln Aussagen über die Art und Weise der Geschäftsabwicklung. Geschäftsregeln legen also fest, wann und wie ein System auf ein Ereignis reagiert. Um Geschäftsregeln auf Computern ablaufen lassen zu können, wurde das sogenannte Event-Condition-Action-Konstrukt (ECA) vorgeschlagen: Wenn das Ereignis (E) eintritt, wird die Bedingung (C) vom Informationssystem evaluiert und - falls sie erfüllt ist - die entsprechende Aktion (A) ausgelöst; vgl. dazu [Hsu et al. 88, p. 173].
• Geschäftsfalldaten: Im Kontext der Geschäftsprozeßmodellierung kann zwischen Geschäftsfall- und Referenzdaten unterschieden werden. Geschäftsfalldaten sind Daten, die bei der Abarbeitung eines Geschäftsfalles erzeugt werden. Der Output dieser Daten kann
P. Kueng / M. Schrefl
Institutsbericht 95.01
Seite 4
auf eine Datenbasis erfolgen oder die Daten können in Form von Dokumenten in Erscheinung treten. Referenzdaten sind Daten die unabhängig vom Geschäftsfall existieren können, wie dies etwa bei Kunden- oder Artikeldaten der Fall ist.
2.1 Welche Arten von Geschäftsprozessen gibt es? Geschäftsprozesse können anhand vieler verschiedener Kriterien eingeteilt werden. Als erstes Strukturmerkmal kann die Häufigkeit aufgeführt werden: Einerseits gibt es Geschäftsprozesse, bei denen sehr viele Geschäftsfälle abgearbeitet werden müssen; zu nennen wären etwa der Ankauf und Verkauf von Devisen in einer Bank. Andererseits gibt es Prozesse die jährlich nur einmal zum Tragen kommen, wie dies etwa bei der Konsolidierung einer Konzernbilanz der Fall ist. Zwei weitere wichtige Strukturmerkmal betreffen die Stabilität und die Komplexität der Geschäftsprozesse; vgl. dazu Tab. 1.
Komplexität
Stabilität
niedrige Stabilität der Prozesse
mittlere Stabilität der Prozesse
hohe Stabilität der Prozesse
hohe Komplexität der Prozesse
Erstellung von Offerten im Anlagenbau
Abwicklung von Rechtsgutachten
Ermittlung der Steuer in international tätigen Unternehmen
mittlere Komplexität der Prozesse
Beurteilung von Forschungsvorhaben
Kreditvergabe in Banken
Bearbeitung von Stipendiengesuchen
niedrige Komplexität der Prozesse
(Prozesse mit diesen Merkmalen existieren kaum)
Erstellen von Tätigkeitsberichten in einer Universität
Erstellung der täglichen Bilanz (AktivenPassiven)
Tab. 1: Positionierung einiger Geschäftsprozesse; in Anlehnung an [Schulz 85], [Rathgeb 94] Aus Tab. 1 geht hervor, daß zwischen neun Arten von Geschäftsprozessen unterschieden werden kann. Es stellt sich nun die Frage, welche der neun Geschäftsprozeßarten für die nachfolgende Diskussion besonders relevant sind. Aus erkenntnistheoretischer Sicht ist zu sagen, daß das Konzept der Spezialisierung auf alle Arten von Geschäftsprozessen angewendet werden kann. Aus betriebswirtschaftlicher Sicht - und mit einem Seitenblick zu den Workflow-Management-Systemen - sind jedoch diejenigen Prozesse von besonderer Bedeutung, welche relativ viele Geschäftvorfälle aufweisen, eine mittlere bis hohe Stabilität haben und mindestens teilweise strukturiert sind, vgl. dazu die Resultate der empirischen Untersuchungen von [Damschik/Häntschel 94] und [Gappmaier 94].
2.2 Welche Arten von Geschäftsregeln gibt es? Die Überschrift weist bereits darauf hin, daß zwischen verschiedenen Arten von Geschäftsregeln unterschieden werden kann. [Herbst/Knolmayer 94, S. 10f] teilen die Geschäftsregeln nach ihrer Herkunft in unternehmensexterne und -interne Regeln ein: Die unternehmensexternen Geschäftsregeln werden in die beiden Kategorien naturgegebene Fakten (z.B. das Geburtsdatum einer Person ist immer kleiner als das aktuelle Datum) und Normen (das Alterslimit für Kinderarbeit liegt z.B. bei 14 Jahren) eingeteilt. Bei den unternehmensinternen P. Kueng / M. Schrefl
Institutsbericht 95.01
Seite 5
Geschäftsregeln unterscheiden die erwähnten Autoren zwischen Primärquellen (die Geschäftsregel ist nicht aus einer anderen Geschäftsregel abgeleitet) und abgeleiteten Quellen (die Geschäftsregel wurde aus einer Primärquelle abgeleitet). Andere Autoren betrachten die Modellierung und Verwaltung von Geschäftsregeln eher aus Datenbank-technischer Perspektive und kommen naheliegenderweise zu anderen Ergebnissen. So unterscheiden etwa [Diaz et al. 91, p. 323] drei Arten von Regeln, nämlich user-definedrules, integrity-rules und propagating-rules: Während die erste Kategorie von den Anwendern definiert wird, werden die beiden anderen, aufgrund einer deklarativen Spezifikation, vom System generiert. Die Diskussion um die Geschäftsregeln entspringt zwei Wurzeln: die erste ist diejenige der Informationssysteme (einige Vertreter wurden oben erwähnt); die zweite Wurzel ist bedeutend älter und kann mit dem Begriff Ablauforganisation charakterisiert werden. Als ein möglicher Vertreter sei hier Grochla aufgeführt. In Anlehnung an [Grochla 82, S. 90f] können folgende Kategorien von Geschäftsregeln gebildet werden:
• Ablaufregeln: Sie definieren, in welcher Reihenfolge bestimmte Arbeitsschritte/Aktivitäten ausgeführt werden müssen. Die Ablaufregeln bestimmen den Geschäftsprozeßablauf.
• Entscheidungsregeln: Sie legen fest, welche Entscheidung in einer bestimmten Situation (Datenkonstellation) zu treffen ist.
• Kompetenzregeln: Sie machen Aussagen darüber, welche Personen welche Rollen1 ausführen. Ferner legen sie die Verteilung von Entscheidungsbefugnissen auf Personen und/oder Rollen fest.
• Kooperationsregeln: Sie definieren welche Personen welche Tätigkeiten ausführen und machen damit auch Aussagen darüber, bei welchen Tätigkeiten welche Personen zusammenzuarbeiten haben.
• Methodenregeln: Sie machen Aussagen darüber, wie bestimmte Arbeitsschritte/Aktivitäten ausgeführt werden und welche Sachmittel zu verwenden sind.
• Zeitregeln: Sie haben vor allem im Zusammenhang mit der Diskussion um “Computer integrated Manufacturing” und “Just in Time” besondere Aktualität erlangt; sie sind im Zusamenhang mit Geschäftsprozeßmodellierung aber nicht minder wichtig. Mögliche Parameter wären etwa: “maximale Liegezeit vor Bearbeitungsbeginn”, “maximale Zeit bis eine Anfrage erstmals beantwortet werden muß” oder “maximal zulässige Durchlaufzeit eines Geschäftsfalles”. Es liegt auf der Hand, daß im vorliegenden Beitrag nicht auf sämtliche oben erwähnten Kategorien von Geschäftsregeln eingegangen werden kann. Da die beiden Kategorien Ablaufregeln und Entscheidungsregeln im hier behandelten Geschäftsprozeß “Bearbeitung von Kreditanträgen” von besonderer Bedeutung sind, konzentrieren wir uns im folgenden auf diese beiden.
1. Unter einer Rolle wird die Zuweisung von bestimmten Funktionen auf bestimmte Personen verstanden.
P. Kueng / M. Schrefl
Institutsbericht 95.01
Seite 6
3.0 Modellierung von Geschäftsprozessen Es ist naheliegend für die Modellierung von Geschäftsprozessen einen objektorientierten Ansatz zu wählen, der eine integrierte Daten- und Prozeßmodellierung unterstützt. Diesbezüglich wurden bereits verschiedene Methoden und Darstellungsmittel vorgeschlagen. Zu nennen wären etwa das semantische Objektmodell (SOM) von [Ferstl/Sinz 93], das Trigger Modeling nach [Joosten 94], die Object Modeling Technique (OMT) nach [Rumbaugh et al. 91] und [Bauer et al. 94], die visuelle Objektmodellierung (VOM) von [Schauer et al. 93], die ARISMethode nach [Scheer 94], die Process Analysis and Design Method (PADM) nach [Wastel et al. 94] oder das Actor Dependency/Issue Argumentation Model von [Yu/Mylopoulos 94]. Es ist nicht die Zielsetzung dieses Beitrags, die unterschiedlichen vorgeschlagenen Modelle zu vergleichen, sondern an einem Modell exemplarisch die Spezialisierung von Geschäftsprozessen vorzustellen. Wir haben diesbezüglich erweiterte Objekt/Verhaltensdiagramme [Kappel/ Schrefl 91] ausgewählt, um auf eigene Erfahrungen und Vorarbeiten aufzubauen. Objekt/Verhaltensdiagramme wurden ursprünglich für den konzeptuellen Entwurf objektorientierter Datenbankschemata vorgestellt. Sie sind aber bereits in ihrer Grundform, wie in [Herbst et al. 94] untersucht, für die Modellierung von Geschäftsfalldaten und Ablaufregeln von Geschäftsregeln sehr gut geeignet. Erweiterte Objekt/Verhaltensdiagramme (vgl. [Bichler/Schrefl 94]) bieten zudem die Möglichkeit, Entscheidungsregeln darzustellen. Wie werden einzelne Aspekte eines Geschäftsprozesses repräsentiert? Eine Antwort darauf ist in Tab. 2 zu finden: Eine Geschäftsprozeßbeschreibung - sie besteht aus den Komponenten Geschäftsfall, Geschäftsfalldaten, Ablauf- und Entscheidungsregeln - wird auf konzeptueller Ebene durch ein Objekt/Verhaltensdiagramm beschrieben. Ein einzelner Geschäftsfall wird durch ein Objekt repräsentiert. Die Geschäftsfalldaten werden mit Objektdiagrammen, die auf Konzepten semantischer Datenmodellen basieren, dargestellt. Ein Geschäftsprozeßablauf (Ablaufregeln) wird durch ein Verhaltensdiagramm bestehend aus Aktivitäten mit Vor- und Nachzuständen beschrieben, wobei die Aktivitäten den Transitionen und die Zustände den Stellen eines Petri-Netzes entsprechen. Entscheidungsregeln werden durch Handlungsgebote und Handlungsverbote ausgedrückt, die einzelnen Aktivitäten des Verhaltensdiagramms zugeordnet werden können. Für die Umsetzung des konzeptuellen Modells in ein Implementierungsmodell bieten sich aktive objektorientierte Datenbanken (vgl. [Reinwald 93], [Kappel et al. 94]) an. Das Prinzip dieser Umsetzung ist überblicksmäßig in der zweiten und dritten Spalte von Tab. 2 dargestellt: Objektdiagramme werden in die Struktur von Objektklassen (Instanzvariable), Verhaltensdiagramme in das Verhalten von Objektklassen (Methoden), und Handlungsverbote und Handlungsgebote in Regeln umgesetzt, welche Transaktionen auslösen (Auslöseregeln) bzw. unzulässige Transaktionen abbrechen. modellierte Sachverhalte
konzeptuelles Modell
Implementierungsmodell (aktive objektorientierte DB)
Geschäftsprozeßbeschreibung
Objekt/Verhaltensdiagramm
Objektklasse
Geschäftsfall
Objekt
Instanz einer Objektklasse
Geschäftsfalldaten
Objektdiagramm
Struktur der Objektklasse
Ablaufregeln: Aktivitäten zeitliche Abhängigkeiten
Verhaltensdiagramm (Petri-Netz): Aktivitäten (Transitionen) Zustände (Stellen)
Verhalten der Objektklasse: Methoden Vor- und Nachzustände der Meth.
Entscheidungsregeln: Handlungsgebote (HG) Handlungsverbote (HV)
Aktivitäten zugeordnete HG Aktivitäten zugeordnete HV
Verhalten der Objektklasse: Auslöseregeln (Event-Trigger) Abbruchregeln (Abort-Trigger)
Tab. 2: Einordnung der verwendeten modell- und implementierungstechnischen Begriffe P. Kueng / M. Schrefl
Institutsbericht 95.01
Seite 7
In den folgenden Abschnitten veranschaulichen wir die Modellierung von Geschäftsfalldaten, Ablaufregeln und Entscheidungsregeln im einzelnen. Es sei angemerkt, daß durch die notwendigermaßen sequentielle Beschreibung der einzelnen Modellaspekte keine Aussage über die Reihenfolge der einzelnen Schritte des Modellierungsprozesses selbst ausgedrückt wird: Die Modellierung der Geschäftsfalldaten muß der Modellierung der Ablaufregeln nicht notwendigerweise vorausgehen. Sowohl eine umgekehrte Reihenfolge als auch ein paralleles oder iteratives Vorgehen sind möglich.
3.1 Modellierung von Geschäftsfalldaten Zur Darstellung von Geschäftsfalldaten haben sich semantische Datenmodelle, deren prominentester Vertreter sich im Entity-Relationship-Model (ERM) von [Chen 76] findet, sehr gut bewährt. Die von objektorientierten Modellen angebotenen Konzepte zur Modellierung der Struktur von Objektklassen basieren im wesentlichen auf den grundlegenden Konzepten semantischer Datenmodelle. Dies trifft auch auf Objektdiagramme zu. Ein Objektdiagramm beschreibt die Daten eines Geschäftsfalles durch eine Menge von Attributen (oval gezeichnet) und eine Menge von Beziehungen (rechteckig gezeichnet). Attribute stellen unmittelbare Datenwerte dar, Beziehungen verweisen auf Referenzdaten oder Geschäftsfälle, die durch eigene Objektdiagramme näher beschrieben werden. Abb. 1 zeigt die für den Geschäftsprozeß "Bearbeitung von Kreditanträgen” notwendigen Objektdiagramme. Das Objektdiagramm “Kreditantrag” wird durch die Attribute "Antragsnummer", "Kredithöhe", "Rate", "verfübares Einkommen" und "Bearbeitungsstatus", sowie den Beziehungen "Antragssteller" und "Lohnbestätigung" beschrieben. Im Objektdiagramm sind die Wertebereiche der einzelnen Attribute (z.B. öS für "Kredithöhe") und die Beziehungen (z.B.: KUNDE für "Antragssteller") ersichtlich. In ihrer erweiteren Form bieten Objektdiagramme die Möglichkeit, verschiedene Arten von Beziehungen mit unterschiedlicher vordefinierter Semantik zu unterscheiden (siehe dazu: [Kappel/Schrefl 91]).
KREDITANTRAG Antrags-Nr.
Kredithöhe
INT
öS
verfügbares Eink.
Bearb.status CHAR
Antragssteller
öS
KUNDE
KUNDE
LOHNZETTEL
Rate
Kunden-Nr.
Tel.-Nr.
öS
INT
CHAR
INT
CHAR
Name
Anschrift
Bruttogehalt
Nettogehalt
Lohnbestätigung LOHNZETTEL
CHAR
Lohnzettel-Nr.
CHAR
öS
Arbeitgeber
öS
Abb. 1: Objektdiagramme für die Geschäftsfalldaten
3.2 Modellierung von Geschäftsprozeßabläufen (Ablaufregeln) Zur Modellierung des dynamischen Verhaltens von Informationssystemen haben sich PetriNetze [Reisig 90] und verschiedenste Erweiterungen (z.B. [Jensen 92]) gut bewährt. Geschäftsprozeßabläufe können gleichfalls mit Hilfe von Petri-Netzen sehr leicht simuliert werden. Zur Modellierung der Ablaufregeln eines Geschäftsprozesses verwenden wir Verhaltensdiagramme, die auf Petri-Netzen basieren. Ein Verhaltensdiagramm eines Geschäftsprozesses besteht aus einer Menge von Aktivitäten und Zuständen - sie entsprechen den
P. Kueng / M. Schrefl
Institutsbericht 95.01
Seite 8
Transitionen und Stellen eines Petri-Netzes - sowie aus gerichten Kanten, die Aktivitäten mit deren Vor- und Nachzuständen verbinden. Geschäftsfälle werden durch individuelle Marken repräsentiert. Eine Aktivität kann für einen bestimmten Geschäftsfall dann ausgeführt werden, wenn alle Vorzustände mit einer Marke versehen sind. Im Gegensatz zu Transitionen in Petri-Netzen die automatisch feuern, wenn alle Eingangsstellen eine Marke enthalten, müssen Aktivitäten in Verhaltensdiagrammen vom Benutzer oder vom Anwendungsprogramm angestoßen werden. Wird eine Aktivität für einen bestimmten Geschäftsfall angestoßen, so wird dessen Marke aus allen Vorzuständen entnommen und in einen impliziten Aktivitätszustand, der nach der Aktivität benannt ist, versetzt. Die Ausführung einer Aktivität nimmt - im Gegensatz zu Transitionen eines Petri-Netzes - eine bestimmte Zeit in Anspruch, die durch den Aktivitätszustand repräsentiert wird. Wird die Aktivität abgeschlossen, wird die Marke aus dem Aktivitätszustand entnommen und in alle Nachzustände eingefügt. Abb. 2 zeigt das Verhaltensdiagramm des Geschäftsprozesses "Bearbeiten eines Kreditantrages": Aktivitäten werden durch Rechtecke, Zustände durch Kreise und Kanten durch Pfeile repräsentiert. Durch das gezeigte Verhaltensdiagramm können hinsichtlich des genannten Geschäftsprozesses die drei folgenden Fragen beantwortet werden:
• Welche Aktivitäten (Arbeitsschritte) müssen ausgeführt werden? Dem Verhaltensdiagramm können wir entnehmen, daß u.a. die Arbeitsschritte "Kredit beantragen", "Lohnbestätigung einholen" und "Kreditwürdigkeit prüfen" ausgeführt werden müssen.
• Welche Arbeitsschritte werden sequentiell, parallel oder alternativ ausgeführt? Aus Abb. 2 geht hervor, daß die Aktivitäten "Kredit gewähren", "Gesuch an den Vorstand weiterleiten" und "Kredit ablehnen" alternativ ausgeführt werden, die Aktivitäten "Ablehnungsbrief erstellen" und "Kunde informieren" jedoch sequentiell.
• In welchen Zuständen kann sich ein Geschäftsfall befinden? Ein Geschäftsfall kann sich bspw. im Zustand "Kredit beantragt" oder "Bonität geprüft" befinden. Da die Ausführung der Aktivitäten eine gewisse Zeit in Anspruch nimmt, sind z.B. auch die Zustände "Kreditwürdigkeit prüfen" oder "Bestätigungsbrief erstellen" möglich. Wir möchten nochmals darauf hinweisen, daß Abb. 2 den Geschäftsprozeß "Bearbeiten eines Kreditantrages" keineswegs vollständig wiedergibt. Das gezeigte Verhaltendsdiagramm macht nämlich keine Aussagen darüber, welche Daten und Dokumente während des Prozeßablaufes erzeugt werden, welche Sachmittel und Referenzdaten für die einzelnen Arbeitsschritte benötigt werden und welche organisatorischen Einheiten und Personen die einzelnen Arbeitsschritte ausführen. Ferner finden sich im gezeigten Verhaltensdiagramm keine Angaben darüber, wie lange die einzelnen Arbeitsschritte dauern. Das Faktum, daß einige in der Geschäftsprozeßmodellierung wichtigen Sachverhalte im Verhaltensdiagramm nicht modelliert wurden, liegt nicht an der ungenügenden Ausdrucksmächtigkeit, sondern daran, daß durch die Wiedergabe sämtlicher für Geschäftsprozesse wichtiger Elemente das Verhaltensdiagramm in Abb. 2 über Gebühr strapaziert würde und kaum mehr interpretiert werden könnte. Der Sinn der Modellbildung liegt ja nicht in einer wirklichkeitsgetreuen Wiedergabe sämtlicher Sachverhalte, sondern darin, zu abstrahieren und einige für die Diskussion wichtige Elemente in den Vordergrund zu heben. In [Kappel/Schrefl 91] werden Verhaltensdiagramme auf der hier vorgestellten Abstraktionsstufe als Lebenszyklusdiagramme bezeichnet. Eine detailliertere Modellierung, auf die wir hier verzichten, ist jedoch mit Hilfe von Aktivitätsspezifikationsdiagrammen, Aktivitätsrealisierungsdiagramme und Zustandsdiagrammen, wie in [Kappel/Schrefl 91] vorgestellt, möglich.
P. Kueng / M. Schrefl
Institutsbericht 95.01
Seite 9
Ablehnungsbrief erstellen Vorstand lehnt Kredit ab Kredit ist abgelehnt
Kredit ablehnen
Vorstand prüft Kreditgesuch An Vorstand weitergeleitet
An Vorstand weiterleiten Kredit beantragen
Kredit beantragt
Lohnbestätigung einholen
Lohnbestätigung eingeholt
Kreditwürdigkeit prüfen
Kreditwürdigkeit geprüft
Bonitätsprüfung abschließen
Bonität geprüft
Kredit gewähren
Kredit ist gewährt
Vorstand gewährt Kredit
Vorstand hat Gesuch geprüft
Bestätigungsbrief erstellen
Informationsbrief erstellt
Kunde informieren
3.3 Modellierung von Entscheidungsregeln
Abb. 2: Der Geschäftsprozeß “Bearbeiten eines Kreditantrages” als Verhaltensdiagramm P. Kueng / M. Schrefl
Geschäftabläufe sind nicht immer rein sequentiell; gewisse Aktivitäten werden parallel abgewickelt und wieder andere sind alternativ. Entscheidungsregeln geben an, welche von mehreren alternativen Aktivitäten - unter gegebenen Ausprägungen der Geschäftsfalldaten - zur Ausführung ausgewählt werden dürfen bzw. ausgewählt werden müssen. Für einen Kreditantrag im Zustand "Bonität geprüft" ist z.B. die Entscheidung zwischen den Aktivitäten "Kredit gewähren", "Kredit ablehnen" und "an den Vorstand weiterleiten" zu treffen. Um Entscheidungsregeln strukturiert modellieren und spezialisieren zu können, ist es sinnvoll, zwischen zwei Kategorien von Entscheidungsregeln zu unterscheiden: Die erste Kategorie - wir nennen sie Handlungsgebote - macht Aussagen darüber, unter welchen Bedingungen eine bestimmte Aktivität unbedingt ausgeführt werden muß. Beispielsweise sind die eingangs erwähnten Entscheidungsregeln 1, 4 und 5 Handlungsgebote. Die zweite Kategorie von Entscheidungsregeln - wir bezeichnen sie als Handlungsverbote - macht Aussagen darüber, unter welchen Bedingungen eine bestimmte Aktivität nicht ausgeführt werden darf. Hierzu gehören bspw. die Entscheidungsregeln 2 und 3. Derjenige Bereich, der weder von Handlungsgeboten noch von Handlungsverboten abgedeckt wird, nennen wir Handlungsspielraum. Warum ist bei der Modellierung von Geschäftsprozessen das Konzept des Handlungsspielraumes notwendig? Aus naheliegenden Gründen kann nicht für alle Entscheidungssituationen im voraus eindeutig bestimmt werden, welche von mehreren alternativen Aktivitäten für einen Geschäftsfall ausgeführt werden soll. Dies hängt damit zusammen, daß nicht allen Aktivitäten vollständig operationalisierbare Entscheidungsregeln zugewiesen werden können; sei es, daß die zur Beurteilung relevanten Parameter nicht alle im voraus bestimmt werden können oder die Quantifizierung einzelner Parameter nur bedingt möglich ist. Die nicht vollständige Operationalisierbarkeit führt dazu, daß ein gewisser Handlungsspielraum besteht.1
1. Um diesen Handlungsspielraum korrekt einzugrenzen, werden teilweise entscheidungsunterstützende Systeme eingesetzt, vgl. etwa [Glaser et al. 94].
Institutsbericht 95.01
Seite 10
In unserem Bankbeispiel besteht, entsprechend den eingangs angegebenen Entscheidungsregeln, unter anderem dann ein Handlungsspielraum (zwischen den Aktivitäten "gewähren" und "weiterleiten"), wenn die Kredithöhe zwischen 100 000 und 900 000 öS liegt und das verfügbare Einkommen des Kreditwerbers größer oder gleich die dreifache Rate ist. Dieser Handlungsspielraum ist in Abb. 3 graphisch veranschaulicht. Zudem zeigt diese Abbildung, welche Handlungsgebote und Handlungsverbote für einen Geschäftsfall im Zustand “Bonität geprüft” Gültigkeit haben. Der Übersichtlichkeit wegen wurden Handlungsverbote im Überlappungsbereich mit einem Handlungsgebot nicht explizit ausgewiesen. Aus der Abbildung geht ferner hervor, daß neben dem oben erwähnten Handlungsspielraum noch weitere Handlungsspielräume bestehen. Kredithöhe
Handlungsspielraum (gewähren, weiterleiten)
Handlungsspielraum (ablehnen, weiterleiten)
[in 1000 öS]
1000
HG: Kredit weiterleiten
HV: Kredit gewähren
800
600 HG: Kredit ablehnen
HV: Kredit ablehnen
Handlungsspielraum (gewähren, ablehnen, weiterleiten)
400
200 HG: Kredit gewähren
0.5
1.0
1.5
2.0
2.5
3.0
3.5
frei verfügbar / Rate
Abb. 3: Entscheidungsregeln für das Bearbeiten von Kreditanträgen Um die für Geschäftsprozesse relevanten Entscheidungsregeln darstellen zu können, besteht die Möglichkeit, Handlungsverbote als Vorbedingungen (bzw. Abbruchregeln) und Handlungsgebote als Auslöseregeln den jeweiligen Aktivitäten im Verhaltensdiagramm zuzuordnen (vgl. dazu: [Bichler/Schrefl 94]). Alternativ dazu bietet sich bei komplexen Prämissen die Darstellung als Entscheidungstabelle an; vgl. dazu etwa [Liebelt/Sulzberger 93, S. 146f]. Zum Schluß dieses Abschnittes sei darauf hingewiesen, welche Bedingungen erfüllt sein müssen, damit eine Menge von Entscheidungsregeln widerspruchsfrei ist. Dies sind die beiden folgenden:
• Besteht unter einer bestimmten Bedingung ein Handlungsgebot für ein bestimmte Aktivität, so darf unter dieser Bedingung kein Handlungsverbot für diese Aktivität bestehen.
• Wenn unter einer bestimmten Bedingung ein Handlungsgebot für eine Aktivität besteht, so besteht unter derselben Bedingung ein Handlungsverbot für jede alternative Aktivität.
P. Kueng / M. Schrefl
Institutsbericht 95.01
Seite 11
4.0 Spezialisierung von Geschäftsprozessen Nachdem veranschaulicht wurde, wie Geschäftsprozesse mittels Objektdiagrammen, Verhaltensdiagrammen und Handlungsgeboten/-verboten modelliert werden können, soll nachfolgend gezeigt werden, wie sich das Konzept der Spezialisierung auf Geschäftsprozesse anwenden läßt. Die grundlegende Idee der Spezialisierung liegt darin, daß Klassen in einer Hierarchie angeordnet werden, wobei übergeordnete Klassen ihre Eigenschaften auf untergeordnete Klassen vererben. Nach diesem Prinzip werden die bei einer Klasse definierten Attribute und Methoden auf alle ihre untergeordneten Klassen vererbt. Attribute und Methoden die nur für die untergeordneten Klassen relevant sind, werden direkt bei den entsprechenden Klassen modelliert. In ähnlicher Form können Geschäftsprozesse in einer Spezialisierungshierarchie angeordnet werden, wobei speziellere Geschäftsprozesse die Eigenschaften allgemeinerer Geschäftsprozesse erben und diese "konsistent" ergänzen. "Konsistent" ist hier in dem Sinne zu verstehen, daß die neu hinzugekommenen Eigenschaften den ererbten Eigenschaften nicht widersprechen dürfen. Eine weitere Form der Spezialisierung bestünde darin, ererbte Eigenschaften zu verfeinern. Diese Möglichkeit wird hier aber nicht weiter verfolgt. Worin liegen die maßgebenden Vorteile, welche durch die Spezialisierung von Geschäftsprozessen erreicht werden können? Auf der Managementebene wirkt sich das Konzept der Spezialisierung insofern positiv aus, als dadurch der Top-down-Entwurf von Geschäftsprozessen unterstützt wird. Dies erleichtert es, in der Prozeßentwurfsphase die Übersicht zu behalten, Redundanz zu vermeiden und damit eine widerspruchfreie Menge von Teilprozessen aufbauen zu können. In der Betriebsphase wirkt sich das Konzept der Spezialisierung insofern positiv aus, als Geschäftsprozesse leichter - weil schneller lokalisierbar - angepaßt werden können. Hinsichtlich der Systementwicklung bringt die Spezialisierung von Geschäftsprozessen den Vorteil, daß Teilprozesse hierarchisch verifizierbar werden. Ist beispielsweise der allgemeingültige Geschäftsprozeß für die Bearbeitung von Kreditanträgen korrekt formuliert und implementiert, so kann dieser sowohl für die Abarbeitung eines Privatkredites als auch für die Abwicklung eines Hypothekarkredites oder eines Geschäftskredites wiederverwendet werden. Nachfolgend behandeln wir die Spezialisierung von Geschäftsfalldaten, Geschäftsprozeßabläufen und Entscheidungsregeln im Detail. Als Beispiel dient uns der Geschäftsprozeß "Kreditantrag", welcher für die Geschäftsprozesse "Privatkreditantrag" und "Hypothekarkreditantrag" spezialisiert wird.
4.1 Spezialisierung von Geschäftsfalldaten Die Spezialisierung von Datenstrukturen ist bereits aus der Datenmodellierung mit erweiterten Entity-Relationship-Diagrammen, die Klassenhierarchien unterstützen, bekannt. Dabei erben Subklassen die bei Superklassen definierten Attribute und Beziehungen. Dasselbe gilt für die Modellierung von Geschäftsfalldaten mit Hilfe von Objektdiagrammen. Die für Privatkredite und Hypothekarkredite gemeinsamen Attribute und Beziehungen wurden bereits im Objektdiagramm "KREDITANTRAG" (vgl. Abb. 1) modelliert. Das Objektdiagramm "PRIVATKREDITANTRAG" in Abb. 4 zeigt die für Privatkredite zusätzlichen Attribute, nämlich "Kreditschutzverbandabfrage" und "pfändbares Gehalt". Das Objektdiagram "HYPOTHEKARKREDITANTRAG" zeigt die für Hypothekarkredite zusätzlichen Attribute "Schätzwert" (des Grundstücks), "Vorbelastung", und "Belehnungsgrenze", sowie die zusätzlichen Beziehungen "Grundstück" und "Grundbuchauszug".
P. Kueng / M. Schrefl
Institutsbericht 95.01
Seite 12
HYPOTHEKARKREDITANTRAG
PRIVATKREDITANTRAG KSV-Abfrage CHAR
pfändbares Gehalt öS
Schätzwert
Vorbelastung
Belehnungsgrenze
öS
öS
öS
Grundstück GRUNDSTÜCK
subclass of: KREDITANTRAG
Grundbuchauszug GB-AUSZUG
subclass of: KREDITANTRAG
Abb 4: Spezialisierung von Geschäftsfalldaten mittels Objektdiagrammen
4.2 Spezialisierung von Geschäftsprozeßabläufen (Ablaufregeln) In Abb. 2 wurde gezeigt, wie der Geschäftsprozeßablauf "Bearbeiten eines Kreditantrages" durch ein Verhaltensdiagramm beschrieben werden kann. Im folgenden soll nun das Beispiel wieder aufgegriffen und gezeigt werden, wie der allgemeine Ablauf für die Bearbeitung von Privatkreditanträgen und Hypothekarkreditanträgen spezialisiert werden kann; vgl. dazu die Abb. 5 und 6. Dabei beziehen wir uns auf den mit einer unterbrochenen Linie markierten Ausschnitt von Abb. 2. Die Bearbeitung eines Antrags auf einen Privatkredits unterscheidet sich gegenüber der allgemeinen Beschreibung der Bearbeitung eines Kredites insofern, als bei einem Privatkredit vor der Beendung der Bonitätsprüfung zwei zusätzliche Aktivitäten ("Kreditschutzverband abfragen" und "pfändbares Gehalt ermitteln") erledigt werden müssen; vgl. dazu die Abb. 2 und 5. Da diese zusätzlichen Aktivitäten parallel zu den bisherigen ausgeführt werden können, muß die Abwicklung eines Privatkredites also nicht notwendigerweise länger dauern als dies bei einem allgemeinen Kredit der Fall ist. Um den Geschäftsprozeßablauf eines Hypothekkarkreditantrags zu modellieren, kann wiederum der allgemeine Geschäftsprozeßablauf für die Bearbeitung eines Kreditantrags aus Abb. 2 spezialisiert erden. Stellt man die Abb. 2 und 6 einander gegenüber, so fällt auf, daß in Abb. 6 drei Aktivitäten hinzugekommen sind ("Liegenschaft schätzen", "Grundbuchauszug einholen" und "Belehnungsgrenze" ermitteln), die wiederum parallel zu den bereits aufgeführten Aktivitäten ausgeführt werden können - ein Sachverhalt, der hilft die Durchlaufzeit eines Geschäftsfalles niedrig zu halten. Wie einleitend dargelegt, ist bei der Spezialisierung von Ablaufregeln die Frage der Widerspruchsfreiheit zwischen dem spezielleren und dem allgemeineren Geschäftsprozeßablauf von großer Bedeutung. Deshalb sollen hier die wichtigsten Kriterien, die zu einer konsistenten Spezialisierung führen, erläutert werden. Informell ausgedrückt fordern wir für eine konsistente Spezialisierung eines Geschäftsprozeßablaufes, daß jeder mögliche Lauf eines Geschäftsfalles nach der spezielleren Geschäftsprozeßbeschreibung - auf höherer Ebene betrachtet - auch ein gültiger Lauf nach der allgemeineren Geschäftsprozeßbeschreibung ist. Formal betrachtet kann der Lauf eines Geschäftsfalles durch eine Folge von Prozeßzuständen dargestellt werden, wobei ein Prozeßzustand jeweils die eigentlichen Zustände und die Aktivitätszustände umfaßt, in denen sich ein Geschäftsfall gerade befindet. So wäre z.B. {"Kreditwürdigkeit geprüft", "Belehungsgrenze ermittelt"} ein möglicher Prozeßzustand eines Hypothekarkreditantrags, der beim Beginn der Aktivität "Bonitätsprüfung abschließen" in den Prozeßzustand "Bonität geprüft" übergeht. Eine Spezialisierung eines Verhaltensdiagramms P. Kueng / M. Schrefl
Institutsbericht 95.01
Seite 13
P. Kueng / M. Schrefl
Grundbuchauszug einholen Kredit beantragt (3)
Entschuldungsauszug eingeholt
Belehnungsgrenze ermitteln Liegenschaft schätzen Kredit beantragt (2)
Liegenschaft geschätzt
Kreditwürdigkeit prüfen Lohnbestätigung eingeholt Lohnbestätigung einholen Kredit beantragt (1) Kredit beantragen
Kredit beantragen
Abb. 5: Spezialisierung von Ablaufregeln für Privatkredit
Belehnungsgrenze ermittelt
Bonitätsprüfung abschließen Kreditwürdigkeit geprüft
Pfändbarkeit und Kreditschutz geprüft pfändbares Gehalt ermitteln Kreditschutzverband abfragen Lohnbestätigung eingeholt (2)
Kreditschutz abgefragt
Lohnbestätigung eingeholt (1) Kredit beantragt
Lohnbestätigung einholen
Kreditwürdigkeit prüfen
Kreditwürdigkeit geprüft
Bonitätsprüfung abschließen
Bonität geprüft
Bonität geprüft
ist dann widerspruchsfrei, wenn aus jeder gültigen Folge von Prozeßzuständen der Subklasse eine gültige Folge von Prozeßzuständen der Superklasse entsteht. (indem aus den Prozeßzuständen neu hinzugekommen Zustände und Aktivitäten entfernt werden.) Diese Widerspruchsfreiheit ist in unserem Beispiel gegeben, denn die Folge von Prozeßzuständen (vgl. Abb. 5 und 6) "Belehungsgrenze ermittelt", "Bonitätsprüfung abschließen", "Bonitätsprüfung abgeschlossen" ist nach dem Verhaltensdiagram "Kreditantrag" (siehe Abb. 2) gültig.
Abb. 6: Spezialisierung von Ablaufregeln für Hypothekarkredit
Institutsbericht 95.01
Seite 14
Gibt es allgemeine Kriterien, um zu überprüfen, ob das Verhaltensdiagramm einer Subklasse das Verhaltendiagramm einer Superklasse konsistent spezialisiert? In [Kappel/Schrefl 94] wurden dazu drei Prüfkriterien vorgestellt. Diese Prüfkriterien sind, wie in [Kappel/Schrefl 94] bewiesen wird, hinreichend, d.h. wenn sie erfüllt sind, liegt eine konsistente Spezialisierung vor und auch notwendig, d.h. wenn ein Prüfkriterium weggelassen oder abgeschwächt würde, wären diese nicht mehr hinreichend. Die Prüfkriterien sind:
• Vererbungskriterium: Ist ein Zustand ein Vorzustand einer Aktivität der Superklasse, so ist dieser Zustand auch Vorzustand der Aktivität bei der Subklasse.
• Unmittelbarkeitskriterium: Ist ein Zustand ein Vorzustand einer Aktivität der Subklasse und gehören dieser Zustand und diese Aktivität auch zur Superklasse, so ist dieser Zustand auch Vorzustand der Aktivität bei der Superklasse.
• Erweiterungskriterium: Ist ein Zustand ein Vorzustand einer Aktivität der Subklasse und gehört diese Aktivität nicht zur Superklasse, so gehört auch dieser Zustand nicht zur Superklasse. Diese Kriterien gelten analog für Nachzustände. Die Verhaltensdiagramme "Privatkreditantrag" (Abb. 5) und "Hypothekarkreditantrag" (Abb. 6) erfüllen diese Prüfkriterien hinsichtlich dem Verhaltendsdiagramm "Kreditantrag" (Abb. 2) und sind daher widerspruchsfrei spezialisiert.1
4.3 Spezialisierung von Entscheidungsregeln Wie Geschäftsprozeßabläufe wollen wir auch Entscheidungsregeln konsistent spezialisieren. Die Entscheidungsregeln der Subklasse sollen einerseits die Entscheidungsregeln der Superklasse, die ja an die Subklasse vererbt werden, umfassen, und anderseits sollen die Entscheidungsregeln der Subklasse den Entscheidungsregeln der Superklasse nicht widersprechen. Auf unser Bankenbeispiel bezogen bedeutet dies zum Beispiel, daß ein Privatkreditantrag auf jeden Fall gewährt werden muß, wenn er bereits unter den für einen Kreditantrag genannten Bedingungen gewährt würde. Ferner darf er auf keinen Fall gewährt werden, wenn er unter den für einen Kreditantrag genannten Bedingungen nicht gewährt werden dürfte. Betrachten wir dies genauer: Eine Menge von Entscheidungsregeln gibt an, ob für eine gegebene Bedingung und eine gegebene Aktivität, die Aktivität ausgeführt werden muß oder ob sie nicht ausgeführt werden darf oder ob ein Handlungsspielraum besteht. Mit anderen Worten: die Entscheidungsregeln sind dann konsistent spezialisiert, wenn die Entscheidungsregeln der Subklasse nur dann anders entscheiden wenn in der Superklasse ein Handlungsspielraum besteht. Dies bedeutet, daß bei der Spezialisierung Handlungsgebote als auch Handlungsverbote - als logische Bedingungen betrachtet - schwächer werden und daher auf mehr mögliche Ausprägungen von Geschäftsfalldaten zutreffen. Was bedeutet dies auf unser Kreditbeispiel bezogen? Ein Sachbearbeiter muß einen Privatkredit gewähren, wenn (1) das verfügbare Einkommen größer gleich die dreifache Rate ist und der gewünschte Kredit 100 000 öS nicht übersteigt, oder wenn (2) die Kredithöhe 100 000 öS nicht übersteigt und das verfügbare Einkommen größer oder gleich 80% ist und der pfändbare
1. Ähnliche Spezialisierungskriterien wurden für die Modellierung von Objektlebensläufen mit Hilfe von Automaten in [Ebert/Engels 94], [McGregor/Dyer 93] und [Saake et al. 94] vorgestellt.
P. Kueng / M. Schrefl
Institutsbericht 95.01
Seite 15
Gehaltsanteil größer oder gleich 100% der Rate ist. Entsprechend den Entscheidungsregeln für einen "Kreditantrag" besteht hinsichtlich der ersten Bedingung ein Handlungsgebot, hinsichtlich der zweiten Bedingung ein Handlungsspielraum. Kreditart “Kredit”
Privatkredit
Hypothekarkredit
Kreditablehnung geboten (muß)
v=K]
An Vorstand weiterleiten geboten (muß)
v>=3R und K>=900
[v>=3R und K>=100] oder [v>=0.8R und p>=R und K>=100]
[v>=3R und K>=900] oder [v>=0.8R und 0.7B>=K und K>=900]
An Vorstand weiterleiten verboten
[v=3R und K
