in: Vossen, G.; Becker, J. (Hrsg.), Geschäftsprozeßmodellierung und Workflow-Management, (Verlag International Thomson Publishing, ISBN 3-8266-0124-6) Bonn-Albany 1996, S. 163-175. 9 Geschäftsprozeßadäquate Informationssystemadaption durch generische Strukturen P. Loos Abstract Wandelnde Geschäftsprozesse erfordern von den unterstützenden Informationssystemen die Fähigkeit, sich flexibel an Änderungen anpassen zu können. Während dies bei Workflow- Managementsystemen durch ihre spezielle Architektur gewährleistet ist, sind operative Anwendungssysteme in der Regel verhältnismäßig starr in den unterstützten Abläufen. Der Beitrag beschreibt ein Konzept, das eine einfache Adaption von operativen Informationssystemen ermöglicht. Das Konzept basiert auf generischen Strukturen, die mit Geschäftsprozeßmodellen instantiiert werden. Dadurch wird erst bei der Installation das Informationsmodell des Anwendungssystems festgelegt. Das Prinzip der generischen Strukturen wird anhand statischer und dynamischer Aspekte von Prozeßstrukturen sowie am Beispiel konkreter Anwendungen beschrieben. 9.1 Einleitung Fließende Unternehmensstrukturen als Reaktion auf veränderte Marktbedingungen erfordern eine Anpassung der betrieblichen Geschäftsabläufe. Im Rahmen der Geschäftsprozeßmodellierung werden die bestehenden Abläufe erfaßt und neue, optimierte Sollabläufe gestaltet. Das Geschäftsprozeßmanagement hat die Aufgabe, diese verbesserten Abläufe mit Hilfe der Informationstechnik umzusetzen und die operative Ausführung zu steuern. Für die Durchführung werden unterschiedliche Informationssysteme eingesetzt. Workflow-Managementsysteme als neue Middleware können die Aufgabe der Koordination der einzelnen betrieblichen Funktionen im Sinne ganzheitlicher Prozesse übernehmen (vgl. [Jab95] und Kapitel 17-19). Sie bedienen sich dabei bestehender Applikationen für die Durchführung von einzelnen Funktionen oder von Teilprozessen. Daraus ergibt sich die Notwendigkeit, nicht nur die Ablaufstrukturen der Workflow-Managementsysteme, sondern auch die der übrigen Informationssysteme flexibel an neue Anforderungen anzupassen. Während diese flexible Anpaßbarkeit bei Workflow-Managementsystemen durch ihre spezielle Architektur gegeben ist, können operative Informationssysteme meist nur im Rahmen der Konfigurierung adaptiert werden. Notwendig ist allerdings eine weitreichendere Anpaßbarkeit. So kann es z. B. erforderlich sein, neue, bisher nicht enthaltene Prozesse und Systemobjekte in ein Informationssystem einzufügen. Dabei muß der durch konventionelle Umprogrammierung entstehende Anwendungsstau vermieden werden. Auch Konzepte zur Entwicklung neuerer Informationssysteme aus existierenden Bausteinen sind häufig aus Zeit- und Kostengründen nicht möglich. Daher sollten Informationssysteme mit solchen Grundstrukturen ausgestattet sein, die eine Adaption ohne Umprogrammierung erlauben. Um diesen Anforderungen gerecht zu werden, müssen bei der architektonischen Gestaltung von Anwendungssystemen die Ziele Flexibilität und Wiederverwendbarkeit Berücksichtigung finden. Unter Flexibilität soll hierbei die Fähigkeit verstanden werden, die Software an unterschiedliche Geschäftsprozesse anpassen zu können. Dies
gilt sowohl für die Änderung von bestehenden Abläufen im Rahmen von Business Process Reengineering als auch für die Erschließung neuer Anwendungsfelder bestehender Informationssysteme. Die Wiederverwendung von Software ergibt sich aus der Notwendigkeit, nicht für jede Problemstellung eine vollständig neue Systementwicklung und -implementierung vornehmen zu können. Hier hat sich Standardsoftware als eine Art der Wiederverwendung durchgesetzt. Da Standardsoftware für eine breite Kundengruppe entwickelt wird, ist hier die flexible Anpassung an die individuellen Kundenbedürfnisse besonders wichtig. Aber auch für kundenspezifische Software sollte bei der Entwicklung auf das Wiederverwendungspotential geachtet werden. Im folgenden Abschnitt werden kurz die Konzepte Komposition, Generierung, Konfigurierung und generische Strukturen [Loo95] als Lösungsansätze zur flexiblen Anpassung von Informationssystemen an sich ändernde Geschäftsprozesse vorgestellt. Die Konzeption der generischen Strukturen wird im Abschnitt 9.3 anhand eines Beispiels erläutert, wobei sowohl die statische als auch die dynamische Sicht berücksichtigt wird. Abschnitt 9.4 vergleicht anhand der Bewertungskriterien Mächtigkeit und Generalität die Konzeption der generischen Strukturen mit den übrigen Lösungsansätzen und beschreibt deren Einsatzmöglichkeiten und -hindernisse. Im anschließenden Abschnitt 9.5 wird am Beispiel zweier Anwendungsfälle gezeigt, wie die Konzeption der generischen Strukturen ansatzweise bereits in praktische Applikationen umgesetzt wurde. Im Ausblick wird auf offene systemtechnische und methodische Fragestellungen hingewiesen, wobei insbesondere die Notwendigkeit eines Vorgehensmodells im Sinne eines durchgängigen Geschäftsprozeßmanagements motiviert wird. 9.2 Lösungsansätze Die Wiederverwendung von Software ist seit geraumer Zeit Forschungsgegenstand der Informatik (ein Überblick wird gegeben in [BiP89]). Verschiedene Ansätze zur Wiederverwendung sowie zur Anpassung von Informationssystemen werden nachfolgend charakterisiert, um eine Einordnung generischer Strukturen zu ermöglichen. 9.2.1 Komposition von Bausteinen Bei den meisten Ansätzen steht die Wiederverwendung von Bausteinen im Vordergrund. Dadurch ergibt sich die Notwendigkeit, für das Errichten einer speziellen Anwendung bzw. für die Anpassung einer bestehenden Anwendung den Programmcode neu zu kombinieren oder zu ändern, wofür detaillierte Programmierkenntnisse erforderlich sind. So unterscheidet Endres zwischen den Formen Programmadaptierung, Schablonentechnik und Bausteintechnik [End88]. Charakteristisches Merkmal dieser Formen stellt die Wiederverwendung von Implementierungsergebnissen dar. Anwendungsspezifische Bausteine zielen dagegen auch auf die Wiederverwendung von Designergebnissen. Dafür werden domänenspezifische Strukturen identifiziert [Lin92, Kue94] oder anwendungsbezogene Klassenbibliotheken und Frameworks [Hes93] bereitgestellt. Die Flexibilität resultiert bei der Bausteinwiederverwendung durch den wesentlich geringeren Aufwand gegenüber einer Neuentwicklung und damit einer schnelleren Reaktion auf Geschäftsprozeßänderungen. Man kann davon ausgehen, daß es heute kaum größere Softwareprojekte gibt, in denen nicht auf bereits existierende Bausteine zurückgegriffen wird. Stark unterschiedlich sind allerdings der Gegenstand und die zielgerichtete Planung der Wiederverwendung. 2
9.2.2 Generierung Bei der Generierung wird ein Softwaresystem nach bestimmten Regeln aus anwendungsspezifischen Vorgaben abgeleitet. Wie bei der Wiederverwendung von Bausteinen entsteht neuer Softwarecode. Im Gegensatz zur Bausteinwiederverwendung handelt es sich hierbei nicht um die Komposition bestehender, sondern um die Erzeugung neuer Strukturen [BiR89]. Die Generierung von Software ist für interaktive, datenintensive und algorithmenschwache Anwendungen mit nicht-komplexen Strukturen geeignet [Win93], was typisch ist für betriebliche Informationssysteme. Idealtypisch für die Generierung wäre eine automatische Überführung von Geschäftsprozeßmodellen und anderen fachlichen Informationsmodellen in lauffähige Informationssysteme. Dieser Weg wird zwar durch unterschiedliche Werkzeuge im Rahmen von I-CASE unterstützt, auf softwaretechnisches Knowhow in Form von Programmierung kann aber nicht verzichtet werden. Auch sind die Informationsmodelle formal meist nicht hinreichend präzise, da sie in der Regel als fachlicher Entwurf und nicht als DV-technische Spezifikation anzusehen sind. 9.2.3 Konfigurierung Die Konfigurierung zielt darauf ab, aus von der Software vorgegebenen Alternativen eine problemadäquate auszuwählen. Dabei werden Abläufe sowie Eigenschaften und Verhaltensweisen von Systemobjekten wie Datentabellen und Funktionen in beschränktem Umfang beeinflußt. Die Anpassung erfolgt über Parametereinstellungen, meist in Form manueller oder programmgeführter Eintragungen in Tabellen oder Konfigurationsdateien. Häufig werden hierfür auch Begriffe wie Parametrisierung oder Adaption verwendet [Haa92]. Bei Standardsoftwaresystemen, die von den Herstellern für einen anonymen Markt angeboten werden, ist die Konfigurierbarkeit das wohl meistgenutzte Hilfsmittel, um das System bei der Installation und Einführung an die für die konkrete Anwendung notwendige Funktionalität anzupassen. Die Konfigurierung ist bei großen Systemen eine langwierige und schwierige Aufgabe. Oft sind mehrere tausend Parameter anzupassen. Deshalb werden Methoden entwickelt, um die Parametereinstellungen mit Hilfe der im Rahmen der Unternehmensmodellierung festgelegten Funktionalität zu automatisieren [Pie93, SHW94, LoS95]. 9.2.4 Generische Strukturen Beim Einsatz generischer Strukturen ist das Anwendungssystem so aufzubauen, daß der Anwender neue, bisher nicht enthaltene Geschäftsprozesse und Systemobjekte in das Informationssystem einfügen kann. Das Informationssystem ist dafür mit Grundstrukturen auszustatten, die diese Adaptionen ohne Umprogrammierung zulassen. Damit ähnelt dieser Ansatz der Konfigurierung, da für eine spezifische Implementierung prinzipiell keine Programmierkenntnisse erforderlich sind, sondern die Anpassungen während der Installation erfolgen. 9.3 Konzeption generischer Strukturen Die Konzeption von generischen Strukturen basiert auf dem Prinzip der Abstraktion. Wie bei der Generalisierung bzw. Spezialisierung der Datenmodellierung [SmS77] oder den Klassenhierarchien der Objektorientierung [Hes93] werden, ausgehend von speziellen Anwendungsfällen, allgemeine Strukturen abgeleitet. Allerdings werden nur die oberen Ebenen der Hierarchien durch den Entwickler auf Modellebene dargestellt und in der Implementierung als Strukturen materialisiert. Die 3
konkrete Ausgestaltung der speziellen Informationsstrukturen wird dagegen dem Anwender überlassen. Die Anforderungen sind während der Systeminstallation in die generischen Strukturen einzufügen, d. h. die generischen Strukturen sind mit den Anwendungsmodellen zu instantiieren. Die abzubildenden Geschäftsprozesse sind als Inhalt der generischen Strukturen in leicht modifizierbarer Form enthalten. Damit besitzen die Informationsstrukturen des Anwendungssystems Eigenschaften eines Metamodells. Während Metamodelle im allgemeinen zur Beschreibung von Unternehmensmodellierungsmethoden und -prozessen [z. B. AtT93, Jar92, Loo92, Sch92a] dienen, bilden sie in diesem Ansatz einen Teil des Anwendungssystems. Anhand eines Beispiels aus dem Fertigungsbereich soll die Anwendung generischer Strukturen für Geschäftsobjekte und -prozesse veranschaulicht werden. Als Geschäftsobjekte sollen Fertigungsaufträge verwaltet werden, die sich aus einzelnen Arbeitsgängen zusammensetzen. Ein Arbeitsgang ist immer eindeutig einem Fertigungsauftrag zugeordnet. Einem Arbeitsgang kann immer eine Maschine zugeordnet werden, auf der er ausgeführt wird. Ein Arbeitsgang selbst kann wiederum aus einzelnen Arbeitsschritten bestehen. Ein Arbeitsschritt wird eindeutig einem Arbeitsgang zugeordnet. Für die Bearbeitung von Arbeitsschritten werden unterschiedliche Werkzeuge benötigt. Fertigungsaufträge können in ein Netz eingebunden sein (FA-Netz), um den Fertigungsfluß über mehrere Stücklistenstufen verfolgen zu können. Mit der Verknüpfung von Arbeitsgängen über Beziehungen (AG-Bez) kann parallele Fertigung verschiedener Arbeitsgänge dargestellt werden. Arbeitsschritte eines Arbeitsganges sollen immer sequentiell bearbeitet werden und können mit Hilfe von Folgen (AS-Fol) gereiht werden. Die entsprechende spezielle Datenstruktur des logischen Modells der Geschäftsobjekte wird in Abbildung 9.1 gezeigt. In dem generischen Modell werden Tätigkeitsklassen abgebildet. Eine Klasse kann entsprechend dem Beispiel entweder ein Fertigungsauftrag, ein Arbeitsgang oder ein Arbeitsschritt sein. Einer Tätigkeitsklasse können Ressourcenklassen zugeordnet werden (RS-TK-Klasse), die für die Bearbeitung notwendig sind. Die Beziehungen der Tätigkeitsklassen untereinander können mit Hilfe der Tätigkeitsklassenhierarchie (TKlasse-Hier) dargestellt werden. Die Zulässigkeit der Verknüpfungen von Tätigkeiten der einzelnen Klassen untereinander wie Auftragsnetze, Arbeitsgangbeziehungen oder Schrittfolgen wird durch die Beziehungsklasse (TKlasse-Bez) ausgedrückt. Nachdem eine Möglichkeit zur Definition der Klassen gegeben ist, müssen noch Strukturen für die Ausprägungen, z. B. 'Fertigungsauftrag 15', 'Arbeitsgang X' oder 'Werkzeug W1', geschaffen werden. Dafür sind die Entity- und Beziehungstypen Ressource, Tätigkeit, Ressourcentätigkeitszuordung (RS-TK), Tätigkeitshierarchie (TK-Hier) und Tätigkeitsbeziehung (TK-Bez) vorgesehen. Über die Beziehungen Ressourcenklassenzuordnung (RKZ) und Tätigkeitsklassenzuordnung (TKZ) werden die Verbindungen zu den jeweiligen Klassen hergestellt. Um das oben genannte Beispiel darzustellen, müssen die Klassen instantiiert werden. So muß bsw. die Ressourcenklasse die beiden Ausprägungen 'Maschine' und 'Werkzeug' aufweisen. 4
Anwendungsspezifische Struktur Generische Struktur Maschine Werkzeug MA- AG WZ- AS 1,1 Tätigkeitsklasse Fertigungsauftrag FA- AG 1,1 AG- AS 1,1 FA- Netz AG- Bez AS- Fol Abb. 9.1: Generische Strukturen, statische Sicht Typen Ausprägungen Instanzen Ressourcenklasse: Werkzeug Maschine RKZ 0,1 Arbeitsgang Arbeitsschritt Ressourcenklasse 1,1 1,1 0,1 Tätigkeitsklasse: Fertigungsauftrag Arbeitsgang Arbeitsschritt Ressourcen-Tätigkeitsklasse: Maschine-Arbeitsgang, (Typ n:1) Werkzeug-Arbeitsschritt, (Typ n:n) Tätigkeitsklassenhierarchie: Fertigungsauftrag-Fertigungsauftrag Arbeitsgang-Arbeitsschritt RS-TK- Klasse TKlasse- Hier TKZ TK-Hier Tätigkeitsklassen-Beziehung: Fertigungsauftrag-Fertigungsauftrag, (Typ n:n) Arbeitsgang-Arbeitsgang, (Typ n:n) Arbeitsschritt-Arbeitsschritt, (Typ 1:1) RS- Ressource Tätigkeit TK TKlasse- Bez TK-Bez Zusätzlich sind in den Klassen die Kardinalitäten bezüglich der Instanzen der jeweiligen Klasse aufzunehmen. Darüber hinaus sind noch weitere Integritätsbedingungen zu beachten. So muß bsw. sichergestellt werden, daß nur solche Tätigkeiten über Anordnungsbeziehungen verbunden werden, bei denen die entsprechenden Tätigkeitsklassen bereits über die Anordnungsbeziehungsklasse verbunden sind, z. B. keine Tätigkeiten der Klasse Fertigungsauftrag und Arbeitsschritt. Solche Integritätsbedingungen können als Erweiterungen zu der ER-Methode abgebildet und in Datenbankbeschreibungen überführt werden [Jar92, Loo92, Win93]. Neben den statischen Systemstrukturen sind auch die dynamischen Strukturen der Geschäftsprozesse, die sich in den Funktionen und der Ablaufsteuerung dokumentieren, in einer generischen Form zu gestalten. Im Beispiel soll der Geschäftsprozeß 'Fertigungsauftragsbearbeitung' betrachtet werden. In Abbildung 9.2 ist der Prozeß stark vereinfacht in Form einer Ereignisgesteuerten Prozeßkette (vgl. Kapitel 2) dargestellt. Für den Prozeß sind die drei Funktionen Fertigungsauftragsterminierung, Fertigungsauftragsbelegungsplanung und Fertigungsauftragsverfügbarkeitsprüfung dargestellt, die von den Organisationseinheiten Arbeitsvorbereitung, Fertigungssteuerung und Lager durchgeführt werden. Der zeitliche Ablauf der Prozeßschritte und die Möglichkeit der Parallelbearbeitung sind durch die Kantenverknüpfung dargestellt. Der Geschäftsprozeß bearbeitet als Objekte Fertigungsaufträge, deren Aufbau durch die Instantiierung der generischen Strukturen festgelegt ist (z. B. Instanzen Fertigungsauftrag, Arbeitsgang und Arbeitsschritt im Entitytyp Tätigkeitsklasse). Aufgrund der generischen Strukturen der Objekte müssen auch die Verarbeitungsfunktionen in der Lage sein, diese Instanzen zu verarbeiten. Alle vom 5
System angebotenen Funktionen, die auf mögliche Instanzen der Tätigkeitsklasse (evtl. auch anderer Objektklassen) angewandt werden können, z. B. Terminierung, Belegungsplanung, Verfügbarkeitsprüfung, Verzugsermittlung, etc. (vgl. Abbildung 9.2), werden im generischen Modell im Entitytyp Grundfunktion verwaltet. Durch die Zuordnung zu der Tätigkeitsklasse (Beziehungstyp Funktion) kann festgelegt werden, welche dieser generischen Funktionen für welche Instanzen als anwendungsbezogene Funktionen möglich sein sollen. Geschäftsprozeß "Fertigungsauftragsbearbeitung" Generische Struktur Organisationseinheit Fertigungsauftrag ist eingetroffen OE-FK Fertigungsauftragsterminierung Arbeitsvorbereitung Funktion Tätigkeitsklasse Grundfunktion Fertigungsauftrag ist terminiert Vorgänger Nachfolger Fertigungssteuerung Fertigungsauftragsbelegungsplanung Fertigungsauftragsverfügbarkeitsplanung Lager Instanzen Ereignis Organisationseinheit: Arbeitsvorbereitung Fertigungssteuerung Lager Grundfunktion: Terminierung Belegungsplanung Verfügbarkeitsprüfung Funktion: Fertigungsauftragsterminierung Fertigungsauftragsbelegungsplanung Fertigungsauftragsverfügbarkeitsprüfung Organisationseinheit-Funktion: Arbeitsvorbereitung-FA-Terminierung Fertigungssteuerung-FA-Belegungsplanung Lager-FA-Verfügbarkeitsprüfung Vorgänger: FA-Terminierung-Fertigungsauftrag ist eingetroffen Nachfolger: FA-Terminierung-Fertigungsauftrag ist terminiert FA-Belegungsplanung-Fertigungsauftrag ist terminiert... FA-Verfügbarkeitsprüfung-Fertigungsauftrag ist terminiert Abb. 9.2: Generische Strukturen, Ablaufsteuerung Weiterhin müssen für den Geschäftsprozeß die Ablaufsteuerung und die durchführenden Organisationseinheiten festgelegt werden können. Für die Zuordnung zu den Organisationseinheiten wird neben dem Entitytyp Organisationseinheit der Beziehungstyp OE-FK eingeführt, der die Einheiten mit den anwendungsbezogenen Funktionen verbindet, z. B. die Arbeitsvorbereitung mit der Fertigungsauftragsterminierung. Der Ablauf der Funktionen im Geschäftsprozeß wird über den Entitytyp Ereignis und die Beziehungstypen Vorgänger und Nachfolger dargestellt. Die durch die Übernahme des Typs Ereignis etwas umständlich erscheinende Darstellung läßt auch die Verwendung einer Funktion (z. B. Fertigungsauftragsverzugsermittlung) in verschiedenen Geschäftsprozessen (z. B. Fertigungsauftragsterminierung und Fertigungsauftragsüberwachung) zu. Nicht eingegangen wird hier auf die Verknüpfungsoperatoren der Ereignisgesteuerten Prozeßkette, z. B. zur Unterscheidung von alternativen und parallelen Arbeitsfolgen. Damit bilden die generischen Strukturen gemeinsam mit den Instanzen den Sachverhalt der logischen Anwendungsmodelle ab. Die Anwendungslogik kann im Rahmen des Geschäftsprozeßmanagements leicht an die Bedürfnisse eines Unternehmens angepaßt werden. Sie bilden damit ein mächtiges Instrumentarium für das operative Change-Management von Geschäftsprozessen. Entfallen bsw. in einem Unternehmen die Arbeitsschritte, wodurch die Werkzeuge direkt den Arbeitsgängen 6
zugeordnet werden, kann das Anwendungsmodell durch Löschen bzw. Ändern von vier Ausprägungen der statischen Strukturen sowie der entsprechenden Ausprägungen der Ablaufsteuerung im generischen Modell erfolgen. Ebenso lassen sich neue Anforderungen einfügen, z. B. ein Geschäftsprozeß Projektbearbeitung mit Objekten wie Projektaufträgen, Aktivitäten, Arbeitsplätzen und Projektterminierung. 9.4 Kritische Würdigung Die Instantiierung generischer Strukturen soll in der von Biggerstaff/Richter aufgestellten Bewertung, die die konkurrierenden Ziele Mächtigkeit und Generalität darstellt [BiR89], eingeordnet werden (vgl. Abbildung 9.3). Generische Strukturen M ä c h t i g k e i t Generierung APPLICATION GENERATORS POLS Komposition CODE SKELETONS LIBRARIES OBJECT ORIENTED KNOWLEDGE BASES NATURAL LANGUAGE APPLICATIVE LANGUAGE DATA FLOW LANGUAGES OBJECT ORIENTED TRANSFORMATIONS VHILLS FORMAL METHODS HILLS ASSEMBLY Generalität in Anlehnung an: Biggerstaff/Richter Abb. 9.3: Charakterisierung der Flexibilitäts- und Wiederverwendungstechniken Sie kann als mächtiger als die Generierung und Bausteinwiederverwendung angesehen werden. Gleichzeitig weist sie eine geringere Generalität auf. Gegenüber der Konfigurierung hat sie eine höhere Generalität, da neue, nicht vom Entwickler vorgesehene Objekte eingefügt werden können. Dennoch ist sie nicht weniger mächtig als diese. In der Praxis sind die Übergänge zwischen dem Generieren, Konfigurieren und Instantiieren jedoch eher fließend. So können bsw. durch Konfiguration neue Objekte generiert oder durch Konfigurationsparameter die Instanzen einer Tabelle als Typen interpretiert werden. Trotz der aufgezeigten Vorteile generischer Strukturen sind auch kritische Anmerkungen anzufügen, die bei der Entwicklung betrieblicher Informationssysteme zu berücksichtigen sind. Die Verallgemeinerung von Funktionen zur Verarbeitung generischer Strukturen stellt sicherlich einen höheren Implementierungsaufwand dar, der eventuell nur bei einfachen algorithmischen Problemen gerechtfertigt ist. 7
Da das Anwendungssystem nur die generischen Strukturen kennt, müssen während der Laufzeit des Systems die Instanzen interpretiert werden. Damit wird eine zusätzliche Architekturebene in die Anwendungssysteme eingeführt. Während üblicherweise mindestens zwei Abstraktionsebenen unterschieden werden müssen, weisen Informationssysteme mit generischen Strukturen mindestens drei Ebenen auf (vgl. Abbildung 9.4). Das logische Anwendungsmodell ist teilweise in den generischen Strukturen auf der Ebene des Metamodells, teilweise als Instanz des generischen Modells auf der Ebene der Informationsmodelle definiert. Deshalb muß das Informationssystem die Instanzen der Metaebene zur Laufzeit interpretieren, um das logische Anwendungsmodell zu identifizieren. Diese zusätzliche Ebene wird folglich negative Auswirkungen auf die Performance nach sich ziehen. Systemtechnisch könnte man diesen Effekt durch einen Generierungs- oder Übersetzungsvorgang kompensieren, wobei die Instanzen als Strukturen materialisiert und eine Interpretation zur Laufzeit entfallen würde. Die Nutzung generischer Strukturen führt dazu, daß das Anwendungswissen nicht mehr im Informationssystem immanent verankert ist. Deshalb ist ein Vorgehensmodell zur Instantiierung der generischen Strukturen notwendig (vgl. 1 in Abbildung 9.4). Um der Gefahr zu begegnen, daß der Anwender die logischen Anwendungsmodelle bei der Installation selbst definieren muß, sollten Referenzmodelle in Form von Default-Instanzen vorhanden sein. Die instantiierten Strukturen müssen, ähnlich einem neu entwickelten System, Tests unterzogen werden, um festzustellen, ob das durch die Instantiierung implementierte logische Anwendungsmodell sowohl auf der Typebene (z. B. Instanzen des Typs TK-Klasse in Abbildung 9.4) als auch auf Ausprägungsebene (z. B. Instanzen des Typs TK in Abbildung 9.4) konsistent ist. Auch wenn die Instantiierung ohne Programmänderungen durchzuführen ist, kann sie, ebenso wie die Konfigurierung von Standardsoftware, aufgrund der Komplexität nur in geringem Umfang vom Anwender selbst durchgeführt werden. 8
Anwendungsspezifische Struktur Generische Struktur AC-class TK-Klasse TKZ Tätigkeit Metamodell 1 TKlasse- Hier 1 TK-Hier Informationsmodell Arbeitsgang Fertigungsauftrag FA-AG Fertigungsauftrag Arbeitsgang Fertigungsauftrag- Arbeitsgang Instanzenmodel Auftrag 51 Auftrag 63 AG X AG Y AG Z Auftrag 51 Auftrag 63 AG X AG Y AG Z Auftrag 51-AG X Auftrag 63-AG Y Auftrag 63-AG Z Abb. 9.4: Abstraktionsebenen der Modelle 9.5 Beispielanwendungen Die kurze Skizzierung zweier existierender Anwendungen, in denen Teile mit generischen Strukturen realisiert wurden, soll die prinzipielle Realisierbarkeit des Ansatzes verdeutlichen. Die in dem ESPRIT-Projekt CAPISCE entwickelte Software SPINE stellt Bausteine für die Produktionssteuerung in der Prozeßindustrie bereit [LoS94], die als Modul PP-PI in das Standardsystem R/3 eingehen. Diese müssen an Fremdsoftware, z. B. für die Prozeßsteuerung, angeschlossen werden. Die Verbindung zu der externen Software wird in Form von Nachrichten realisiert. Dafür können unterschiedliche Nachrichtentypen genutzt werden, z. B. Nachrichten, um eine Charge zu starten, um realisierte Istdaten der Charge anzufordern oder um Prozeßstörungen mitzuteilen. Die Nachrichtentypen sind nun nicht in einer festen Form implementiert, sondern als Instanzen in generischen Strukturen enthalten. Die generischen Strukturen bestehen u. a. aus den Objekttypen 'Empfänger', z. B. mit Instanzen wie interne Module, externe Module oder Benutzer 'Meldungsart' mit einer Kurzbeschreibung der Nachricht, 'Merkmal', die die betroffenen Attribute beschreibt (z. B. Chargennummer oder Status) und 'Prozeßvorgaben', die die entsprechenden Werte enthalten (z. B. '4711' oder 'gestoppt'). Dadurch ist sichergestellt, daß neue Nachrichtentypen, die im System enthaltene Informationen betreffen, ohne Programmänderungen über eine sogenannte Customizing-Funktion in das System integriert werden können. 9
Das zweite Beispiel beschreibt die interne Repräsentation der Unternehmensmodelle in dem Geschäftsprozeßmodellierungswerkzeug ARIS-Toolset [Sch94b]. Das Werkzeug basiert auf der Architektur integrierter Informationssysteme [Sch92a]. Die Unternehmensmodelle können nach unterschiedlichen Methoden wie Ereignisgesteuerte Prozeßketten, Entity-Relationship-Diagramme, Funktionsbäume, Organigramme, Object Models, Dynamic Models u. v. a. dargestellt werden. Ziel bei der Implementierung war es, das Toolset unabhängig von den einzelnen Methoden zu realisieren. Deshalb wurde das Repository auf Metaebene angelegt. So gibt es u. a. einen Objekttyp 'Objekttyp', der als Instanzen Einträge wie 'Entitytyp', 'Beziehungstyp', 'Funktionstyp' oder 'Ereignistyp' enthält. Sie dienen zur Beschreibung der angebotenen Methoden. In dem Objekttyp 'Objekte' werden von dem Anwender die Objekte der Unternehmensmodelle als Instanzen abgelegt, z. B. 'Kundenstamm', 'Lagerzuordnung', 'Auftragsbearbeitung' oder 'Auftrag abgeschlossen'. Der Vollständigkeit halber sei angefügt, daß die Abbildungsebene des Geschäftsprozeßmodellierungswerkzeuges eine Abstraktionsebene über der eines 'normalen' betrieblichen Informationssystems liegt, d. h. die Ausprägungsebene des Modellierungswerkzeuges stellt die Typebene eines betrieblichen Anwendungssystems dar. Somit ist die Metaebene des Modellierungswerkzeuges aus Sicht eines betrieblichen Anwendungssystems die Meta-Meta-Ebene. 9.6 Ausblick Es wurde gezeigt, daß generische Strukturen die Möglichkeit eröffnen, Informationssysteme flexibel an spezifische Anforderungen unterschiedlicher Unternehmen, die sich aus der aktuellen Gestaltung der Geschäftsprozesse ergeben, anzupassen. Dabei weisen sie gegenüber anderen Ansätzen einige Vorteile, aber auch gewisse Beschränkungen auf. Für die Erstellung von Informationssystemen mit generischen Strukturen müssen geeignete Entwicklungswerkzeuge bereitgestellt werden. Teilweise unterstützen die heute angebotenen Funktions- und Klassenbibliotheken die Entwicklung generischer Strukturen, z. B. Bibliotheken für die Gestaltung graphischer Benutzeroberflächen. Hierfür bieten insbesondere objektorientierte Entwicklungsumgebungen die notwendigen Konzepte. Auch Workflow-Managementsysteme stellen aufgrund ihrer Architektur eine Art generisches System zur Steuerung von Abläufen dar, die im Rahmen des Geschäftsprozeßmanagements mit konkreten Geschäftsprozessen instantiiert werden [SLA94]. Um das Konzept einer breiten Anwendung zugänglich zu machen, sind neben systemtechnischen Fragen wie der zweckmäßigen Kombination der verschiedenen Konzepte oder der Aufgabenteilung zwischen Build-time-System und Run-time-System auch methodische Fragen, z. B. bezüglich der Möglichkeit eines Ebenenkonzeptes generischer Strukturen oder der Bereitstellung generischer Referenzbausteine, zu klären. Das Erkennen und Aufdecken von Strukturanalogien in Informationsmodellen [Bec95] scheint hierzu ein vielversprechender Weg zu sein. Auch die Bereitstellung eines Vorgehensmodells zur Erzeugung einer spezifischen Anwendung im Sinne eines durchgängigen Geschäftsprozeßmanagements, d. h. wie man aus den Geschäftsprozeßmodellen und -objekten die Instantiierung der generischen Strukturen ableitet, ist aus Sicht des Anwenders von besonderer Bedeutung. Insbesondere sind dabei Migrationsstrategien zu berücksichtigen, die eine Anpassung der Strukturen bei in Betrieb befindlichen Systemen und ein Changemanagement ermöglichen. Literatur [AtT93] Atzeni P., Torlone R.: A metamodel approach for the management of multiple models and the translation of schemes. Information Systems 18 (1993), 349-362. 10
[Bec95] Becker J.: Strukturanalogien in Informationsmodellen. In: [Koe95], 133-150. [BiP89] Biggerstaff T. J., Perlis A. J. (Hrsg.): Software Reusability, Volume 1, Concepts and Models, Reading, MA: Addison-Wesley (1989). [BiR89] Biggerstaff T. J., Richter C.: Reusability Framework, Assessment, and Directions. In: [BiP89], 1-17. [End88] Endres A.: Software-Wiederverwendung: Ziele, Wege und Erfahrungen. Informatik-Spektrum 11 (1988), 85-95. [Haa92] [Hes93] [Jab95] [Jar92] [Koe95] [Kue94] [Lin92] Haaks D.: Anpaßbare Informationssysteme - Auf dem Weg zu aufgaben- und benutzerorientierter Systemgestaltung und Funktionalität. Göttingen: Verlag für Angewandte Psychologie (1992). Heß H.: Wiederverwendung von Software - Framework für betriebliche Informationssysteme, Wiesbaden: Gabler-Verlag (1993). Jablonski S.: Workflow-Management-Systeme: Motvation, Modellierung, Architektur. Informatik- Spektrum 18 (1995), 13-24. Jarke M.; Metamodellierung: Werkzeuge für das Engineering von Unternehmensprozessen, in: Hansmann K.-W., Scheer A.-W. (Hrsg.), Praxis und Theorie der Unternehmung, Wiesbaden: Gabler- Verlag (1992). König W. (Hrsg.): Wirtschaftinformtik '95. Wettbewerbsfähigkeit, Innovation, Wirtschaftlichkeit, Heidelberg: Physica-Verlag (1995). Küffmann K.: Software-Wiederverwendung - Konzeption einer domänenorientierten Architektur, Braunschweig: Vieweg Veralg (1994). Lindtner P.: Domänenwissen in Methoden zur Analyse betrieblicher Informationssysteme, Disseration, Hochschule St. Gallen (1992). [Loo92] Loos P.: Datenstrukturierung in der Fertigung, München: R. Oldenbourg-Verlag 1992. [Loo95] Loos P.: Metainformationen - Generische Strukturen für Informationssysteme. EMISA Forum, 1 (1995), 56-58. [LoS94] [LoS95] [Pie93] Loos P., Scheer A.-W.: CAPISCE - A System Architecture for Production Management in Process Industries. In: Proc. of the World Batch Forum 1994, Phoenix AZ (1994), 18.1-18.8. Loos P., Scheer A.-W.: Vom Informationsmodell zum Anwendungssystem - Nutzenpotentiale für den effizienten Einsatz von Informationssystemen. In: [Koe95], 185-201. Pietsch M.: PAREUS-RM - ein Tool zur Unterstützung der Konfiguration von PPS-Parametern im SAP- System R/2. Wirtschaftsinformatik 35 (1993), 434-445. [Sch92a] Scheer A.-W.: Architektur integrierter Informationssysteme - Grundlagen der Unternehmensmodellierung, 2. Aufl., Berlin: Springer-Verlag (1992). [Sch94b] Scheer A.-W.: ARIS Toolset: A Software Product is Born. Information Systems 19 (1994), 609-626. [SHW94] Scheer A.-W., Hoffmann W., Wein R.: Customizing von Standardsoftware mit Referenzmodellen. HMD Theorie und Praxis der Wirtschaftsinformatik 31 (1994), 92-103. [SLA94] [SmS77] [Win93] Scheer A.-W., Loos P., Allweyer Th., Klabunde St., Kraus M., Zimmermann V.: Modellbasiertes Geschäftsprozeßmanagement. m&c-management & Computer 2 (1994), 287-292. Smith J. M., Smith D. C.: Database Abstractions: Aggregation and Generalization. ACM Transaction on Database Systems 2 (1977), 105-133. Winter, R.: Generation of individual Software for Distributed, Hierarchical Production Management Systems, Arbeitspapier Nr 93-05, Universität Frankfurt, Institut für Wirtschaftsinformatik (1993). 11