Transaktionale Datei- und Dokumentenverwaltung in Workflow-Management- Systemen

Transkript

1 Diplomarbeit Software-Labor Institut für Parallele und Verteilte Höchstleistungsrechner Fakultät für Informatik Universität Stuttgart Prüfer: Betreuer: Prof. Dr. Ing. Andreas Reuter Dipl. Inform. Hubert Bildstein begonnen am: 14. Februar 1996 beendet am: 14. August 1996 Diplomarbeit Nr.: 1380 Transaktionale Datei- und Dokumentenverwaltung in Workflow-Management- Systemen Wolfgang Täuber CR-Klassifikation: D.1.5, D.4.3, H.2.4, H.4.1

2 Aufgabenstellung Diese Arbeit wird im Rahmen des Software-Labors der Universität Stuttgart durchgeführt. Das Software-Labor ist eine Einrichtung, das die Entwicklung marktfähiger Software, im Rahmen einer engen Zusammenarbeit der Universität Stuttgart mit der Industrie, zum Ziel hat. Ein Teilprojekt des Software-Labors besitzt als Themengebiet die Weiterentwicklung des Workflow-Management- Systems FlowMark der Firma IBM. Für FlowMark sollen unter anderem transaktionale Konzepte ausgearbeitet werden. Ziel dieser Arbeit ist es, ein transaktionales Konzept auf die Eignung für Workflow- Management-Systeme zu prüfen. Dabei sollen bestehende Standards berücksichtigt werden. Desweiteren ist besonders auf die Fähigkeit zu achten, bestehende Alt- Software in das Workflow-Management-System zu integrieren. Konkret wird ein Verfahren vorgestellt, mit dem bestehende Software als greybox -Integration in ein transaktionales Workflow-Management-System integriert werden kann. Dieses Verfahren basiert auf einem transaktionalen Dateisystem. Damit Workflow-Management-Systeme auch im Bereich computergestützter Entwurf in verteilten Mehrbenutzerumgebungen eingesetzt werden können, werden zusätzliche Anforderungen an ein Workflow-Management-System a m Beispiel einer Software Entwicklungsumgebung spezifiziert. Da eines der größten Probleme von Entwicklungsumgebungen die zentrale Datenhaltung ist (gemeinsam genutzte, zumeist unstrukturierte Daten), werden vorwiegend die Anforderungen an das Workflow-Management-System bezüglich der zentralen Datenhaltung spezifiziert. Ein Teil der Anforderungen kann durch einige Dateisystemerweiterungen auch im transaktionalen Dateisystem berücksichtigt werden. Es soll ein Prototyp des transaktionalen Dateisystems implementiert werden. Ein Teil der Anforderungen an die Datenhaltung einer Entwicklungsumgebung wird im transaktionalen Dateisystem berücksichtigt und implementiert. Zur Demonstration der Funktionen des transaktionalen Dateisystems wird ein einfacher Texteditor entwickelt.

3 Inhaltsverzeichnis 1 Einleitung Motivation Ziele der Arbeit Organisation der Arbeit Workflow-Management-System Wirtschaftliche Motivation Ein Beispielprozeß und dessen Optimierungsmöglichkeiten Reisekostenrückerstattung als Beispielprozeß Mögliche Probleme bei der Durchführung dieses Beispielprozesses Lösungsmöglichkeiten durch Workflow-Management-Systeme Nachteile von Workflow-Management-Systemen Definiton eines Workflow-Management-Systems Funktionale Anforderungen an ein Workflow-Management-System Aspekte der Modellierung von Geschäftsprozessen Komponenten eines Workflow-Management-Systems Vorgangssteuerung Die zentrale Datenhaltung Das Vorgangsinformationssystem Integration der Anwendungen Workflow-Management-Systeme und die Objekt-Technologie Stabile Abwicklung von Geschäftsprozessen Transaktionen in Datenbanksystemen Anforderungen an Transaktionen in Workflow-Management-Systemen Erweiterte Transaktionsmodelle Sicherungspunkte Geschachtelte Transaktionen Verteilte Transaktionen Abgeschwächte Transaktionsmodelle (Design-Transaktionen) check-out und check-in Mischen von Dokumenten Split & Join - Transaktionen Sagas CORBA und OTS CORBA und das System Object Model (SOM) Objekte Elemente von CORBA Dienste des ORB Der Object Transaction Service (OTS) Begriffsbestimmungen für OTS Zusammenspiel der Komponenten im OTS Ein transaktionales Datei- und Dokumentenverwaltungssystem Allgemein Aspekte der Integration Integration der Darstellung Integration des Kontrollflusses Integration der Daten I

4 5.3 Abstufungen der Integriertheit grey-box - Integration von Alt-Software Anforderungen an die Datenhaltung eines Entwicklungssystems auf der Basis von Dateien Konzept für das objektstrukturierte Dateisystem Transaktionen im objektstrukturierten Dateisystem Einsatz der Datenhaltung in heterogenen Rechnernetzen Ein Modell zur Speicherung von hierarchisch gegliederten Dokumenten Realisierungskonzept Datenobjekte versus beliebige include -Struktur Begriffsbestimmungen Client-Server-Architektur des objektstrukturierten Dateisystems Virtuelle Datei- und Verzeichnisnamen für Objekte Objektnamen im Mehrbenutzerbetrieb Handhabung von Varianten Referenzen Sperren von Dokumenten Die Schnittstellen Die Schnittstelle zum Transaktionsverwalter Die Schnittstelle zum Sperrverwalter Die Schnittstelle zum Log-Verwalter Die Schnittstelle zum objektstrukturierten Dateisystem Die interne Schnittstelle Die externe Schnittstelle Funktionen für den Transaktionsverwalter Beispielanwendungen Ein Texteditor für das objektstrukturierte Dateisystem Die Standard-Dateisystemschnittstelle als Beispielanwendung Eine Anwendung als grey-box integrieren Implementierung des objektstrukturierten Dateisystems Das Ring-Konzept von OS/ Dateisysteme unter OS/ Das Ring 0, Ring 3 Konzept Portierbarkeit auf andere Plattformen Zusammenfassung Ergebnisse der Arbeit Analyse und Spezifikation Implementierung Projektverlauf Ausblick Danksagung Anhänge Literatur II

5 Verzeichnis der Abbildungen Abbildung 1: Beispielprozeß - Reisekostenrückerstattung....6 Abbildung 2: Struktur der Bearbeitungsprozesse Abbildung 3: Komponenten eines Workflow-Management-Systems...12 Abbildung 4: Object Management Architecture Abbildung 5: Von IDL zum Objekt in SOM Abbildung 6: Systemkomponenten und Schnittstellen einer OTS-Umgebung.28 Abbildung 7: Drei Stufen der Integriertheit Abbildung 8: Entfernter Zugriff auf Daten Abbildung 9: Physikalische und logische Sicht einer Datei im objektstrukturierten Dateisystem Abbildung 10: Darstellung eines hierarchisch gegliederten Dokuments im objektstrukturierten Dateisystem Abbildung 11: Varianten Abbildung 12: Bitvektoren kennzeichnen die Zugehörigkeit von Objekten zu Varianten Abbildung 13: Schnittstellen des Sperrverwalters Abbildung 14: Die Schnittstellen des objektstrukturierten Dateisystems...56 Abbildung 15: Vereinigen von zwei neuen Objekten Abbildung 16: Vereinigen eines alten und eines neuen Objekts...59 Abbildung 17: Vereinigung von zwei alten Objekten Abbildung 18: Das Anwendungsfenster des Beispiel-Editors Abbildung 19: Die OS/2 Ring-Architektur Abbildung 20: Übersicht über die Dateisystemschnittstellen Abbildung 21: Die zwei Schnittstellen zum objektstrukturierten Dateisystems.67 Abbildung 22: Erweitern eines bestehenden IFS mit der Ring 0 / Ring 3 - Zerlegung Abbildung 23: Shared Memory Abbildung 24: Shared Memory Verwaltung für das objektstrukturierte Dateisystem III

6 1 Einleitung 1.1 Motivation Das wohl bekannteste Beispiel für die Reduktion der Produktionskosten durch die Optimierung des Bearbeitungsprozesses hat Henry Ford mit der Einführung der Fließbandarbeit geliefert. Die Tin Lizzie [15], das erste Fließbandautomobil, war kein Luxusgut mehr wie alle anderen Automobile dieser Zeit, sondern ein Automobil für die breite Masse. Seither werden Bearbeitungsprozesse immer weiter optimiert um die Produktionskosten zu senken, und um damit die Konkurrenzfähigkeit zu erhalten. Bis heute wurden Optimierungen vorwiegend im Bereich der Produktion durchgeführt. Große Erfolge wurden durch den Einsatz von automatischen Steuerungen und Robotern erzielt. Die Produktionskapazität wurde vor allem durch die Prozeßoptimierungen im Bereich der Produktion gesteigert, was auch zu höheren Anforderungen an die Verwaltungen der Unternehmen führte. Die höheren Anforderungen wurden durch mehr Personal ausgeglichen. In den Industrieländern liegt der Anteil an Informationsbe- und Informationsverarbeitern bei weit über 50 % [14] der Beschäftigten. Forschungen haben ergeben, daß im Bereich der Bürotätigkeiten durch eine Neuorganisation bis zu 30% der Mitarbeiter eingespart werden kann und damit die Produktionskosten erheblich gesenkt werden können. Grundlage für die Neuorganisation von Geschäftsvorgängen (business processes)ist zunächst die Erfassung der Geschäftsvorgänge und Abbildung dieser auf ein Modell (process model). Nach der Erfassung können die Geschäftsvorgänge optimiert werden. Dieser Vorgang kann unter dem Stichwort Business Process Reengineering (BPR) zusammengefaßt werden. Ziel der Neuorganisation ist es, die Bearbeitungszeit zu senken, die Qualität zu steigern und dabei auch noch die Produktionskosten senken. Dies kann z.b. durch eine verbesserte Kooperation der Mitarbeiter erzielt werden. Gefördert wird eine verbesserte Kooperation durch eine automatische Koordination der Geschäftsprozesse. Das Büro kann dabei Stück für Stück auf ein papierloses Büro umgestellt werden, was die Transportwege der Information beschleunigt. Durch eine automatische Koordination wird auch die prozeßbezogene Kommunikation zwischen den Mitarbeitern gesenkt. Diese Aspekte des BPR sind Faktoren, die die Produktionskosten im Bereich der Bürotätigkeiten senken können. Die optimierten Modelle der Geschäftsvorgänge werden idealerweise einem Workflow-Management-System übergeben. Das Workflow-Management-System steuert den Bearbeitungsprozeß, überwacht den Prozeßfortschritt und koordiniert die Prozeßbearbeitung. Da die Geschäftsprozesse als Modelle dem Workflow- Management-System vorliegen, kann ein Geschäftsprozeß schnell an geänderte Anforderungen angepaßt werden, zum Teil auch ohne die Mitarbeiter zu benachrichtigen. Die Mitarbeiter müssen sich dann auch nicht eine Vielzahl von unternehmensspezifischen Richtlinien merken, die den Bearbeitungsprozeß betreffen. Diese Richtlinien können vom Workflow-Management-System bei der Prozeßsteuerung beachtet werden. 1

7 Workflow-Management-Systeme bringen aber nicht nur den Unternehmen Wettbewerbsvorteile, die das Workflow-Management-System einsetzen. Softwarehersteller, die Komponenten für Workflow-Management-Systeme entwickeln, profitieren ebenfalls von diesen Systemen. Durch diese Systeme wird die Entwicklung hin zur Baukasten-Software (Component-Ware) unterstützt. Baukasten- Software bezeichnet die Bestandteile eines Softwaresystems, in dem mehrere Komponenten zum Teil auch von unterschiedlichen Herstellern in einem definierten Rahmen integriert sind. Unter Verwendung von Baukasten-Software kann ein Software-System, durch Auswahl geeigneter Bausteine, individuell zusammengestellt werden, ohne daß dafür neu programmiert werden muß. Nicht benötigte Funktionalität kann durch die Auswahl der richtigen Komponente vermieden werden, bzw. bei geänderten Anforderungen an eine Komponente kann diese durch eine besser geeignete ausgetauscht werden. Das Rahmenwerk der Komponenten bildet das Workflow-Management-System. Da die Ablaufsteuerung durch das Workflow-Management-System gegeben ist und die Entwicklung sich oftmals auf das Zusammensetzen und wiederverwenden vieler kleiner Bausteine beschränkt, wird die Software-Entwicklung beschleunigt, sowie die Robustheit der einzelnen Softwarekomponenten erhöht. Außerdem werden die Investitionskosten in Software gesenkt und durch das robustere System die Ausfallzeiten verringert. Damit Softwarekomponenten als Baukasten-Software entwickelt werden können, muß die Schnittstelle zum Workflow-Management-System definiert sein. Sollen innerhalb eines Unternehmens unterschiedlichen Workflow-Management-Systeme eingesetzt werden, so müssen diese zusammenarbeiten, d.h. Prozeßinformationen austauschen können. Die dazu erforderliche Schnittstelle muß ebenfalls standardisiert sein. Für die Standardisierung von Schnittstellen wurde ein Gremium führender Softwarehersteller gegründet, die Workflow Management Coalition (WfMC). Ein weiteres Gremium, das sich mit der Standardisierung von Softwareschnittstellen beschäftigt, ist die Object Management Group (OMG). Ein Standard dieses Gremiums ist CORBA 1.Dieser Standard definiert eine einheitliche Kommunikation zwischen Objekten. Ein Standard dieser Art ist für die Erstellung von Baukasten- Software sehr wichtig, da damit die grundlegende Kommunikation zwischen dem Rahmenwerk (Workflow-Management-System) und der Softwarekomonente, sowie zwischen einzelnen Softwarekomponenten realisiert werden kann. In Workflow-Management-Systemen wird ein Aspekt bisher unzureichend behandelt: die Zuverlässigkeit. Zuverlässige Systeme sind unter anderem aus dem Bereich der Datenbanken bekannt, die Ihre Zuverlässigkeit vor allem durch Transaktionen erreichen. Transaktionen beschreiben ein Konzept, das kurz als alles oder nichts umschrieben werden kann (siehe Kap. 3 Stabile Abwicklung von Geschäftsprozessen). Durch die Integration von transaktionalen Konzepten erhofft man sich deshalb eine weitere Erhöhung der Zuverlässigkeit von Workflow- Management-Systemen. 1 steht für Common Object Request Broker Architecture 2

8 Die OMG hat als Teil von CORBA einen weiteren Standard erarbeitet: den Object Transaction Service (OTS). Dieser Standard definiert Schnittstellen für Objekte, die in einer transaktionalen Umgebung verwendet werden können. Es ist bei der Integration von transaktionalen Konzepten in Workflow-Management-Systemen angebracht, diesen Standard zu beachten. Damit können einzelne Softwarekomponenten auch in unterschiedlichen Workflow-Management-Systemen eingesetzt werden. 1.2 Ziele der Arbeit Der Schwerpunkt dieser Arbeit liegt darin, ein transaktionales Konzept auf die Eignung für Workflow-Management-Systeme zu prüfen. Besondere Aufmerksamkeit wird dabei auf die Integration bestehender Anwendungen in die transaktionale Umgebung eines Workflow-Management-Systems gerichtet. Hierfür wird ein Konzept erarbeitet, das im speziellen den Gesichtspunkt der Datenkonsistenz berücksichtigt. Die Grundidee dieses Verfahrens ist ein transaktionales Dateisystem. Dieses Dateisystem hat eine Standard-Dateisystemschnittstelle, über die Anwendungen auf das Dateisystem zugreifen können. Zusätzlich verfügt es über eine erweiterte Schnittstelle, über die u.a. Informationen zum transaktionalen Kontext übermittelt werden. Mit einem solchen Dateisystem können die persistenten Änderungen an Daten durch Alt-Software transaktional geschützt werden. Für eine Vielzahl von Alt-Software ist dieser Schutzmechanismus ohne spezielle Anpassung anwendbar. Bei Anwendungen in heterogenen Rechnernetzen funktioniert dieses Verfahren ebenfalls, da auf Dauer nur persistente Daten relevant sind, und diese transaktional geschützt werden können. Das neu entwickelte Dateisystem weist, außer dem transaktionalen Schutz, noch weitere Eigenschaften auf. Es ist auf die Verwaltung meist hierarchisch gegliederter Dokumente (allgemeiner: Dateien) in Mehrbenutzerumgebungen, speziell für die Datenhaltung von Entwicklungssystemen, ausgelegt. Die Datenhaltung für Entwicklungssysteme ist ein bis heute noch nicht zufriedenstellend gelöstes Problem. Im Gegensatz zu relationalen Datenbanken (viele Daten und wenige Strukturen) werden für die Datenhaltung von Entwicklungssystemen viele Strukturen mit nur wenigen Daten benötigt. Ein Lösungsansatz hierfür sind objektorientierte Datenbanken. Diese sind aber im Gegensatz zu relationalen Datenbanken nicht standardisiert. Mit dem in dieser Arbeit vorgestellten Dateisystem können einige dieser Probleme gelöst werden. Hierzu gehört neben dem transaktionalen Schutz unter anderem auch die Möglichkeit, Varianten und verschiedene Entwicklungsstände eines Dokuments zu verwalten. Zur Begründung der spezifizierten Anforderungen an eine Datenhaltung wurde für diese Arbeit ein Software- Entwicklungssystem als Beispiel herangezogen. Mit diesen Eigenschaften ist das neu entwickelte Dateisystem ein leistungsfähiges Hilfsmittel sowohl für die Integration von Alt-Software als auch für Entwicklungssysteme, welche mit einem Workflow-Management-System modelliert werden. Diese Arbeit ist Teil eines größeren Projekts, das die Integration von transaktionalen Aspekten in Workflow-Management-Systeme unter Berücksichtigung bestehender Standards zum Ziel hat. Dieses Projekt wird in Zusammenarbeit mit 3

9 der Firma IBM durchgeführt. Hierdurch orientiert sich die vorliegende Arbeit auch stark an den Produkten der Firma IBM, zumindest was die Implementierung der Standards CORBA und OTS betrifft. Ziel 1: Beschreiben der IBM-Produkte zu den Standards CORBA und OTS. Ziel 2: Da zu Beginn der Diplomarbeit keine stabile Implementierung des OTS- Standards der Firma IBM vorlag, ist ein Ziel dieser Arbeit die Implementierung des OTS-Standards mit eingeschränktem Funktionsum fang. Ziel 3: Für die Anbindung von Alt-Software an ein Workflow-Management-System wird die erforderliche Dateisystemerweiterung und die Erweiterungen für die Datenhaltung von Entwicklungssystemen entworfen und spezifiziert. Ziel 4: Soweit es der zeitliche Rahmen der Diplomarbeit erlaubt, wird die Implementierung des transaktionalen Dateisystems und Erstellung eines Texteditors vorgenommen. Mit Hilfe des Texteditors können einige der spezifizierten Funktionen des transaktionalen Dateisystems demonstriert w erden. 1.3 Organisation der Arbeit Die vorliegende Arbeit ist in vier Teile gegliedert. Im ersten Teil, Kapitel 2, werden die Grundbegriffe von Workflow-Management- Systemen erläutert, und die Eigenschaften dieser Systeme verdeutlicht. Kapitel 3 geht auf die stabile Abwicklung von Geschäftsprozessen ein. Im zweiten Teil, Kapitel 4, werden die Implementierungen der Standards CORBA und OTS der Firma IBM vorgestellt, und der Nutzen dieser Standards für Workflow-Management-Systeme aufgezeigt. Im dritten Teil, Kapitel 5, wird das Konzept eines transaktionalen Dateisystems vorgestellt, mit welchem Alt-Software als grey-box in Workflow-Management- Systeme integriert werden kann. An das Dateisystem werden weitere Anforderungen für ein transaktionales Dokumentenverwaltungssystem, speziell für Entwicklungssysteme, definiert. Viele der Anforderungen an Entwicklungssysteme können auch für Workflow-Management-Systeme übernommen werden. Im vierten Teil, Kapitel 6 bis 8, wird auf die Schnittstellen der einzelnen Komponenten und auf einige Details der Implementierung eingegangen. Eine Beispielanwendung wird vorgestellt, die einige Funktionen der Datenhaltung demonstrieren soll. 4

10 2 Workflow-Management-System 2.1 Wirtschaftliche Motivation Unternehmen müssen, damit sie konkurrenzfähig bleiben, wirtschaftlich produzieren. Diese Anforderung ist seit der Öffnung der nationalen Märkte unter Bezug auf einen regen internationalen Handel und dem damit gestiegenem Konkurrenzdruck immer mehr in den Vordergrund gerückt. Eine Möglichkeit die Produktionskosten zu senken ist, den Bearbeitungsprozeß zu optimieren. Angefangen hat die Optimierung mit der Erkenntnis, daß die Produktion von mehreren Teilen günstiger ist, als die Einzelanfertigung (economics of scale). Die Entwicklung ging über eine flexiblere (kundenbezogenere) Produktion (economics of scope) weiter, hin zu einer prozeßoptimierten und damit zu einer schnelleren Produktion (economics of speed). Das Interessante dieser Entwicklung aber ist, daß jede Optimierung nur solange einen Wettbewerbsvorteil erbrachte, bis die anderen Unternehmen diese Optimierung ebenfalls eingeführt hatten. Für Unternehmen ist es daher wichtig, Bearbeitungsprozesse immer weiter zu optimieren, um damit die Produktionskosten zu senken. Es wurden weitere Optimierungen durchgeführt, wie z.b. die Bestimmung des Zeitpunktes, wann ein Produkt auf dem Markt eingeführt wird sowie die Auswahl einer Gruppe von geeigneten Mitarbeitern zur Durchführung eines bestimmten Projekts. Die Mitarbeiter einer solchen Gruppe müssen dabei so ausgewählt werden, daß sie über die technologische Kompetenz verfügen, um ein Projekt erfolgreich durchzuführen. In der Gruppe sollte aber nicht unnötig viel Kompetenz gebunden sein, die unter Umständen an einer anderen Stelle besser eingesetzt werden könnte. Bei einer Vielzahl von Unternehmen ist in der heute noch üblichen Art, Geschäftsprozesse abzuwickeln, ein weiteres Optimierungspotential vorhanden. Optimierungen werden bezüglich der Bearbeitungszeit und der Verkürzung der Hierarchieebenen, für die Bearbeitung eines Geschäftsvorgangs, durchgeführt. Diese Optimierungen können als Ergebnis des Business Process Reengineering (BPR) gesehen werden. Das BPR hat als Ziel, Geschäftsvorgänge zu erfassen und an die geänderten Anforderungen anzupassen, bzw. zu optimieren. Das Überarbeiten der Geschäftsprozesse ist in den meisten Fällen eine Neuerfindung des Geschäftsprozesses, d.h. alte Regeln über Organisation und Durchführung von Geschäftsvorgängen werden gebrochen. Dies ist oftmals ein Vorteil, da die Regeln der Abwicklung von Geschäftsprozessen häufig nicht den aktuellen Anforderungen der Marktsituation angepaßt sind. Allerdings ist bei einer radikalen, und auch häufigen, Umstrukturierung mit erheblichem Widerstand der Mitarbeiter zu rechnen. Die Kosten, die durch eine Umstrukturierung entstehen, sind oftmals auch nicht zu vernachlässigen. Durch das Einführen eines Workflow-Management-Systems ist in einem Unternehmen häufig eine radikale Umstrukturierung erforderlich. Allerdings können oftmals spätere Änderungen des Bearbeitungsprozesses vor den Mitarbeitern verborgen werden. Bearbeitungsprozesse, die mittels BPR optimiert wurden, 5

11 können durch ein Workflow-Management-System gesteuert werden. Umstrukturierungen sind dann häufig nur Änderungen im Modell des Workflow- Management-Systems, wodurch der Bearbeitungsprozeß anders gesteuert wird. 2.2 Ein Beispielprozeß und dessen Optimierungsmöglichkeiten Reisekostenrückerstattung als Beispielprozeß U m die Möglichkeiten aufzuzeigen, die sich durch den Einsatz eines Workflow- Management-Systems ergeben, soll ein Beispielprozeß beschrieben, optimiert und die Möglichkeiten der Automation dargestellt werden. Als Beispielprozeß soll eine Reisekostenabrechnung dienen. Abbildung 1 verdeutlicht dies. Abbildung 1: Beispielprozeß - Reisekostenrückerstattung Der Prozeß Reisekostenrückerstattung läuft in einem fiktiven Unternehmen wie folgt ab: Vor dem Antritt der Dienstreise wird ein Antrag zur Genehmigung der Reise ausgefüllt. Dieser Antrag enthält persönliche Daten, Ziel und Zweck der Reise, sowie weitere Daten, welche hier nicht relevant sind. Während der Dienstreise werden die Belege der Ausgaben gesammelt, die zurückerstattet werden sollen. 6

12 Nach der Dienstreise wird ein Formular ausgefüllt in das die persönlichen Daten, die Ausgaben und die Kontonummer, auf das die Rückerstattung erfolgen soll, eingetragen werden. Dieses Formular wird dann dem Vorgesetzten vorgelegt, der die Reisekostenrückerstattung bestätigt. Das Formular wird an die zuständige Stelle weitergeleitet. Ein Mitarbeiter dieser Stelle prüft den Antrag und veranlaßt die Auszahlung, wenn der Betrag kleiner als eine bestimmte Summe ist (in Abbildung 1 wird dieser Betrag als 1.000,-- D M angenommen). Übersteigt der Betrag diese Summe, so muß die Auszahlung von einem Vorgesetzten veranlaßt werden. Die Rechnungsstelle prüft das Formular der Dienststelle für die Reiseanträge und zahlt den Betrag aus Mögliche Probleme bei der Durchführung dieses Beispielprozesses Typische Probleme bei der Abwicklung der Reisekostenrückerstattung sind nicht vollständig ausgefüllte Formulare. Damit werden Anträge von der nächsten Prüfstelle zurückgewiesen. Der Bearbeitungsprozeß wird dadurch verlängert und die Erstattung der Reisekosten unnötig verzögert. Ein weiteres Problem ist die Vertretung im Abwesenheitsfall eines Sachbearbeiters. Fällt ein Sachbearbeiter aus, so bleiben die Anträge oftmals auf seinem Schreibtisch liegen, bis er wieder seine Arbeit aufnimmt. Im allgemeinen sind lange Transport- und Liegezeiten ein Problem. Informationen über den momentanen Bearbeitungsstand des Antrags zu erhalten, ist ebenfalls ein großes Problem. Welche Stelle kann Auskunft über den momentanen Bearbeitungsstand geben? Die Änderung der Vorschriften, ab welchem Betrag ein Antrag auf Reisekostenrückerstattung auch noch von einem Vorgesetzten unterzeichnet werden muß, m u ß dem Sachbearbeiter mitgeteilt werden. Eine häufige Anpassung dieses Prozesses an neue Anforderungen kann beim Sachbearbeiter auf Ablehnung stoßen Lösungsmöglichkeiten durch Workflow-Management-Systeme Workflow-Management-Systeme können Formulare auf plausible Daten prüfen, und bekannte Daten selbständig einsetzen. Dazu gehören z.b. die persönlichen Daten des Antragstellers. Somit werden unnötige Korrekturschleifen im Bearbeitungsprozeß oftmals verhindert. Die Transportzeit eines Antrags wird durch die elektronische Datenübermittlung beschleunigt. Hierfür ist es erforderlich, daß die Belege am Arbeitsplatz des Antragstellers in eine elektronisch zu verarbeitende Form gebracht werden, also z.b. eingescannt werden können. Die Belege müssen als Anlage zum Antrag, zusammen mit dem Antrag, zu seinem Vorgesetzten geschickt werden. Das Problem, wer den Vorgesetzten im Abwesenheitsfall vertritt, kann ebenfalls vom Workflow-Management-System entschieden werden. Mit dem Ausfüllen des Antrags auf Reisekostenrückerstattung ist für den Antragsteller der Bearbeitungs- 7

13 prozeß abgeschlossen. Wer als Nächster den Antrag erhalten muß, also wie der Antrag weiter verarbeitet wird, muß nur das System wissen. Alle Anträge auf Reisekostenrückerstattung können für mehrere Sachbearbeiter in einer, für alle Sachbearbeiter zugänglichen, Warteschlange gehalten werden. Hat ein Sachbearbeiter einen Antrag fertig bearbeitet, so nimmt er den nächsten Antrag zur Bearbeitung aus der Warteschlange. Damit kann verhindert werden, daß Anträge bei einem nicht anwesenden Sachbearbeiter liegen bleiben. Hierfür benötigt das Workflow-Management-System einen Plan, der die Rollenverteilung der einzelnen Mitarbeiter regelt. Dieses Konzept wird auch als Rollen-Konzept bezeichnet. In diesem Plan werden Abhängigkeiten der Mitarbeiter untereinander beschrieben, also z.b. Vorgesetzer, Kollege oder Vertretung. Ein weiterer Vorteil eines Workflow-Management-Systems liegt in der Komponente zur Vorgangsinformation. Mit einer solchen Komponente kann sich der Antragsteller jederzeit selbst über den Bearbeitungszustand seines Antrags informieren. Dadurch wird unnötige Kommunikation verhindert. Aus diesem einfachen Beispielprozeß kann schon abgeleitet werden, daß ein Workflow-Management-System sehr flexibel an neue Anforderungen angepaßt, die Kommunikation reduziert, und die Synchronisation wesentlich verbessert werden kann. 2.3 Nachteile von Workflow-Management-Systemen Die größten Nachteile der Workflow-Management-Systeme liegen in ihrer Einführung. Der Einführung solcher Systeme geht häufig eine Neuorganisation der Geschäftsvorgänge voraus, die das Ergbnis des BPR sind. Die Umstrukturierung, die neuen Anforderungen an die Mitarbeiter und die Möglichkeit der Überwachung sind Gründe für eine schwierige Einführungsphase. Es ist zu erwarten, daß von vielen Mitarbeitern diese Nachteile in den Vordergrund gerückt und Vorteile ignoriert werden. Ein weiterer Nachteil sind sehr hohe Investitionskosten, die sich aus der Modellierung der Geschäftsvorgänge, einer Reihe neuer Software und eventuell auch neuer Hardware ergeben. Nicht zu vergessen sind die Kosten für Schulungen der Mitarbeiter mit den neuen Softwarekomponenten. U m eine höhere Akzeptanz zu erzielen, kann beispielsweise über Seminare den Mitarbeitern die Notwendigkeit der Umstrukturierung und die des Workflow-Management-Systems nahegebracht werden. Die Kosten dieser Seminare müssen ebenfalls berücksichtigt werden. Die bereits erwähnten Nachteile bei der Einführung der Workflow-Management- Systeme werden durch die noch fehlende Reife der Produkte weiter verstärkt. 2.4 Definiton eines Workflow-Management-Systems Bis jetzt existiert noch keine einheitliche Definition des Begriffes Workflow- Management-System. Daher sollen hier zwei Definitionen genannt werden. Die Definition der Workflow Management Coalition lautet [16]: 8

14 A System that completely defines, manages and executes workflow processes (computerized facilation of automated components of a process) through the execution of software whose order of execution is driven by a computer representation of the workflow process logic. Frei übersetzt ist ein Workflow-Management-System ein System, das Arbeitsabläufe vollständig definiert, verwaltet und ausführt. Ausgeführt wird der Arbeitsablauf durch Software, wobei die Ausführungsreihenfolge durch eine Darstellung des Arbeitsablaufs festgelegt ist, die durch den Computer verarbeitet werden kann. Im Gegensatz zur Definition der Workflow Management Coalition, die die Steuerung des Arbeitsablaufs in den Vordergrund stellt, wird in [3] eine Definition von Workflow-Management-Systemen geliefert, die die Funktionalität des Systems aus Benutzersicht beschreibt. Hierfür wird die Definition der Workflow Management Coalition um die im folgenden zusammengefaßten Eigenschaften erweitert: Das Workflow-Management-System verteilt die anstehenden Aufträge an die einzelnen Sachbearbeiter. Ist ein Auftrag bearbeitet, so wird der Auftrag durch das System weitergeleitet. Der Bearbeiter hat keine Information über den weiteren Bearbeitungsprozeß. Die Durchführung eines Auftrags wird überwacht. Vor dem Beginn der Bearbeitung und nach dem Beenden der Bearbeitung müssen die Daten in einem konsistenten Zustand sein. Dies kann oftmals nur aufgrund von Plausibilitätsprüfungen erfolgen. Das System überwacht den Zugriff auf Daten (Aspekt des Datenschutzes). Das System übernimmt die Koordination der an einem Geschäftsprozeß beteiligten Benutzer. Aus diesen Definitionen lassen sich gewisse Anforderungen an Workflow- Management-Systeme ableiten, die im nächsten Abschnitt beschrieben werden. 2.5 Funktionale Anforderungen an ein Workflow-Management- System Da Workflow-Management-Systeme eine entscheidende Rolle in einem Unternehmen spielen, sollen neben der Definition aus 2.4 auch noch weitere funktionale Anforderungen betrachtet werden. In [3] werden die folgenden drei Anforderungen definiert: Skalierbarkeit: Es ist zu erwarten, daß die Anzahl der Workflow-Benutzer, sowie die Anzahl der modellierten Geschäftsvorgänge ständig steigen wird. Integration von Alt-Software: Ein großer Kostenfaktor bei der Einführung eines neuen Softwaresystems ist oftmals nicht die Software oder Hardware selbst, sondern die Schulung der Mitarbeiter und die Portierung der Daten auf das neue System. Daher ist die Einführung eines Workflow-Management- Systems, das nur aus neuen Softwarekomponenten besteht, für ein Unterneh- 9

15 men kaum durchführbar. Alt-Software muß in ein Workflow-Management System integrierbar sein. Transparenz: Das Einsatzgebiet eines Workflow-Management-Systems sind heterogene Rechnernetze. Die Verteilung und die Heterogenität muß vor d e m Anwender verborgen werden. In [11] sind weitere Anforderungen spezifiziert. Zuverlässigkeit: Da die Informationen über den Bearbeitungsstand eines Geschäftsprozesses nur dem Workflow-Management-System bekannt sind, muß das System alleine die Konsistenz und Dauerhaftigkeit der Daten gewährleisten. Das System muß die korrekte Ausführung garantieren. Ein möglicher Ansatz hierfür sind transaktionale Konzepte, die in ein Workflow-Management- System integriert werden. Kompatibilität und Portabilität: Oftmals sind heterogene Rechnernetze in Unternehmen vorzufinden. U m alle Rechner in einem Unternehmen an das Workflow-Management-System anzubinden, ist es erforderlich ein System einzusetzen, das auf allen in einem Unternehmen vorkommenden Rechnerarchitekturen verfügbar ist. Datensicherheit: Alle Daten innerhalb eines Workflow-Management-Systems unterliegen dem Datenschutz und dürfen nur von autorisierten Personen eingesehen und bearbeitet werden. Wenn die eingesetzten (integrierten) Anwendungen keine Schutzmechanismen vorsehen, so muß das Workflow- Management-System den Datenschutz sicherstellen. Benutzerfreundlichkeit: Durch diese Anforderung wird der Schulungsaufwand gesenkt und die Akzeptanz der Anwender erhöht. Neben den Anforderungen an die Workflow-Management-Systeme sind auch noch weitere Aspekte der Modellierung von Arbeitsabläufen interessant. Diese Aspekte werden im nächsten Abschnitt beschrieben. 2.6 Aspekte der Modellierung von Geschäftsprozessen Die Grundlage zur Modellierung von Geschäftsprozessen bildet das BPR. Die dafür notwendigen Verfahren sollen hier nicht näher erläutert werden. Es soll lediglich ein Abriß über die Aspekte der Modellierung gegeben werden, damit die nachfolgenden Ausführungen verständlich werden. Die Grundfrage der Modellierung lautet: Was muß von wem mit welchen Daten durchgeführt werden? Die Frage nach dem Was liefert als Ergebnis die einzelnen Prozeßschritte und die Reihenfolge in der diese Schritte ausgeführt werden müssen. Die Teilschritte eines Prozesses bilden den funktionalen Aspekt.Die Reihenfolge, in der die Teilschritte ausgeführt werden müssen, bildet den abhängigkeitsbezogenen Aspekt. Beim 10

16 abhängigkeitsbezogenen Aspekt muß die Struktur eines Prozesses bestimmt werden. Strukturierte Prozesse sind Prozesse, bei denen man statisch für jeden Teilprozeß einen Nachfolgeprozeß bestimmen kann. Unstrukturierte Prozesse entscheiden nach jedem Bearbeitungsschritt, welcher der richtige Nachfolgeprozeß ist, d.h. es gibt mehrere Möglichkeiten für einen Nachfolgeprozeß. Teilweise strukturierte Prozesse enthalten sowohl Teile welche strukturiert sind, als auch unstrukturierte Teile. Abbildung 2 soll dies verdeutlichen. Abbildung 2: Struktur der Bearbeitungsprozesse Ist der funktionale Aspekt einmal beschrieben, kann die Frage von wem beantwortet werden. Hierbei kann es sich um Personen oder um Programme handeln, die die Teilprozesse bearbeiten. Sowohl Personen als auch Softwaresysteme werden in diesem Zusammenhang als Aktoren bezeichnet, und damit wird dieser Aspekt als aktorenbezogener Aspekt bezeichnet. Abhängigkeiten zwischen den Aktoren werden in einem Rollen-Modell aufgezeigt. Aufgrund dieses Modells kann das Workflow-Management-System z.b. die Vertretung für einen nicht anwesenden Mitarbeiter ermitteln, oder mehrere Sachbearbeiter bei der Vergabe von Aufträgen als gleichwertig ansehen. Durch das Beschreiben der Daten, die vor dem Beginn eines Teilschrittes benötigt werden, und den Daten die durch einen Teilschritt verändert werden, sowie d e m funktionalen und abhängigkeitsbezogenen Aspekt, wird der Datenfluß definiert. Dieser Aspekt wird als informationsbezogener Aspekt bezeichnet. Die Daten, die während der Bearbeitung entstehen oder verändert werden, können in drei verschiedene Kategorien eingeordnet werden: Anwendungsdaten (Application Data): Diese Daten werden nur von Anwendungen eines Workflow-Management-Systems verwendet. Durch diese Daten wird die Ablaufsteuerung nicht beeinflußt. Steuerdaten (Workflow Process Control Data): Steuerdaten sind Daten, die das Workflow-Management-System für die Steuerung des Bearbeitungsprozesses benötigt. Nur das Workflow-Management-System kann diese Daten verändern. Workflowrelevante Anwendungsdaten (Workflow Process Relevant Data): Diese Daten sind Anwendungsdaten, die auf die Steuerung des Bearbeitungsprozesses Einfluß nehmen. Im Beispiel der Reisekostenabrechnung ist dies der Gesamtbetrag der zu erstattenden Reisekosten. Dieser Betrag gehört zu den Anwendungsdaten. Abhängig vom Betrag muß entschieden werden, ob der Sachbearbeiter die Auszahlung genehmigen kann, oder nur dessen Vorgesetzter. Damit nehmen Anwendungsdaten Einfluß auf den Bearbeitungsprozeß. Neben diesen drei wichtigen Aspekten bei der Modellierung der Bearbeitungsprozesse gibt es noch eine Reihe von weiteren Aspekten, wie z.b. der historische Aspekt der Daten, oder der kausale Aspekt eines Prozesses. Der historische Aspekt, d.h. wie 11

17 die Daten im Laufe der Zeit verändert wurden, kann für einige Systeme sehr nützlich sein. Ein Beispiel hierfür ist die Information, welcher Bearbeiter ein Dokument als letzter verändert hat und welche Änderungen durchgeführt wurden. Der kausale Aspekt berücksichtigt Entscheidungen, warum ein bestimmter Bearbeitungsprozeß gewählt wurde. 2.7 Komponenten eines Workflow-Management-Systems Aus den funktionalen Anforderungen an ein Workflow-Management-System und den unterschiedlichen Aspekten der Prozeßbearbeitung, kann die Struktur, wie sie in Abbildung 3 vorgestellt wird, gewählt werden. Diese Struktur ist an die in [11] vorgeschlagene Struktur eines Workflow-Management-Systems angelehnt. Abbildung 3: Komponenten eines Workflow-Management-Systems Workflow-Management-Systeme können auf unterschiedliche Arten dargestellt werden. Die gewählte Darstellung verdeutlicht die Sichtweise eines Workflow- Management-Systems bezüglich der Schwerpunkte dieser Arbeit, sowie den Baukastenansatz der Softwarekomponenten eines Workflow-Management-Systems. Als Integrationsrahmen dieser Komponenten dient das Workflow-Management- System im Wesentlichen mit der Vorgangssteuerung und der zentralen Datenhaltung. Zum Austausch von Nachrichten zwischen den einzelnen Komponenten werden standardisierte Kommunikationskanäle verwendet. Ein möglicher Kommunikationskanal sind Netzwerkverbindungen über TCP/IP. In [11] werden Kommunikationssysteme als Elemente eines Workflow-Systems vorgeschlagen. Dabei handelt es sich nicht um die eben erwähnten Kommunika- 12

18 tionskanäle, die das Workflow-Management-System zur Kommunikation und Synchronisation zwischen den einzelnen Komponenten verwendet. Vielmehr handelt es sich um -Programme und andere Softwarekomponenten aus dem Groupware-Bereich, wie z.b. Terminkalender die als Softwarekomponenten integriert werden können Vorgangssteuerung Die Vorgangssteuerung ist die zentrale Komponente eines Workflow-Management- Systems. Die Vorgangssteuerung muß mit der zentralen Datenhaltung, mit den einzelnen Softwarekomponenten, sowie mit der grafischen Benutzeroberfläche zusammenarbeiten. Die Zusammenarbeit mit der einheitlichen Darstellung der grafischen Benutzeroberfläche bietet den Vorteil, daß Funktionen einer Softwarekomponente, die im gegenwärtigen Bearbeitungsschritt nicht benötigt werden, dem Benutzer auch nicht angeboten werden. Damit können eventuelle Fehlbedienungen vermieden werden. Die Zusammenarbeit mit der zentralen Datenhaltung ist aus mehreren Gründen wichtig. Es ist sinnvoll, die ausführbaren Prozeßmodelle und die Daten z u m Prozeßfortschritt durch die zentrale Datenhaltung verwalten zu lassen. Bei fest definierten Datenaustauschformaten können dann auch die Werkzeuge für die Simulation von Prozessen, Analysewerkzeuge, Spezifikationswerkzeuge, insgesamt alle Werkzeuge zur Bearbeitung und Analyse des Bearbeitungsprozesses als Softwarekomponenten realisiert werden. Damit können diese Komponenten auch zwischen einzelnen Workflow-Management-Systemen ausgetauscht, und besser geeignete Komponenten von Fremdanbietern integriert werden Die zentrale Datenhaltung An die zentrale Datenhaltung wird eine Vielzahl von Anforderungen gestellt. Datensicherheit, Datenschutz und Datenkonsistenz sind dabei die Hauptanforderungen. In [11] werden zwei unterschiedliche Systeme zur Datenhaltung vorgeschlagen: Ein Datenbank-Mangement-System für die Speicherung von Anwenderdaten, sowie ein Dokumenten-Management-System, mit dem Dokumente in verschiedenen Versionen und Bearbeitungsständen verwaltet werden können. Das Dokumenten-Management-System verfügt über ein Archivierungssystem, das auch das Suchen nach Dokumenten in verschiedenster Weise unterstützt. In Kapitel 5 wird ein Dokumentenverwaltungssystem auf der Basis eines Standard-Dateisystems vorgeschlagen. Mit diesem Dateisystem sind viele der Anforderungen aus [11], wie z.b. zusammengesetzte Dokumente, eine Versionenverwaltung, die Verwaltung von Notizen, usw. erfüllbar Das Vorgangsinformationssystem Das Vorgangsinformationssystem dient den Anwendern des Workflow- Management-Systems dazu, den momentanen Bearbeitungszustand eines Prozesses abzufragen. Ein Bearbeiter kann z.b. mit diesem System auf eine Anfrage von einem Kunden den Bearbeitungsstand, auch von einem Prozeß 13

19 erfragen, den er selbst normalerweise nicht bearbeitet, und sofort Auskunft geben. Die lästige und zeitaufwendige Suche nach dem Bearbeiter des Prozesses, der als einziger eine konkrete Auskunft über den Bearbeitungsstand geben kann, entfällt damit gänzlich Integration der Anwendungen Wie in den vorangegangenen Abschnitten bereits angeschnitten, muß ein Workflow-Management-System die Integration von Alt-Software zulassen. Für neue Softwarekomponenten sollte eine einheitliche Darstellung der Benutzerschnittstelle erreicht werden. Für die Integration von Software gibt es verschiedene Abstufungen, die in Kapitel 5 beschrieben werden. Mit dem in Kapitel 5 beschriebenen Dateisystem kann bereits eine Integration der Daten ( grey-box -Integration) erreicht, sowie die Datenkonsistenz trotz der Verwendung von Alt-Software gewährleistet werden. 2.8 Workflow-Management-Systeme und die Objekt-Technologie Durch den Einsatz von objektorientierter Programmierung unter der Beachtung bestehender Standards der Object Management Group (OMG), wird die Entwicklung von Baukasten-Software erst möglich. Ein wichtiger Standard der OMG ist CORBA 2, der die grundlegende Kommunikation zwischen Objekten definiert. Basierend auf diesem Standard sind noch weitere Standards definiert worden, wie z.b. OpenDoc, das unter anderem auch als Dokumenten-Austauschformat verwendet werden kann. Angelehnt an die IBM-Implementierungen SOM und DSOM wird in [2] der Vorteil bei der Programmierung von Softwarekomponenten für Workflow-Management-Systeme durch den Einsatz objektorientierter Techniken hervorgehoben. Die darin beschriebenen Vorteile liegen vorwiegend im Bereich der Wiederverwendung von Software, sowie im Bereich der Austauschbarkeit von Softwarekomponenten. In Kapitel 4 werden die von der OMG definierten Standards CORBA und OTS beschrieben. 2 CORBA steht für Common Object Request Broker Architecture 14

20 3 Stabile Abwicklung von Geschäftsprozessen Eine rechnergestützte stabile Abwicklung von Geschäftsprozessen ist unter anderem durch die folgenden Eigenschaften gekennzeichnet: Ergebnisse von korrekt abgelaufenen Geschäftsprozessen sind dauerhaft und gehen nicht verloren. Geschäftsprozesse, die nicht vollständig oder fehlerhaft ablaufen, hinterlassen keinen inkonsistenten Datenbestand. Allerdings ist hierbei zu beachten, daß ein Geschäftsprozeß lange dauern kann, und ein Zurücksetzen aller Änderungen nicht immer implizit geschehen darf. Bereits erledigte Arbeit sollte nur auf explizite Anweisung vernichtet werden (forward Recovery). Das Workflow-Management-System muß sehr zuverlässig sein und muß eine hohe Verfügbarkeit aufweisen. Das System muß robust sein, d.h. es muß tolerant gegenüber unerwarteten Eingaben sein und auch in Ausnahmesituationen funktionsfähig bleiben. Dadurch wird die Verfügbarkeit des Systems gesteigert. Die Forderung, daß keine Ergebnisse verloren gehen dürfen, ist damit zu begründen, daß dadurch ein inkonsistenter Datenbestand entsteht und damit die korrekte Prozeßausführung nicht gewährleistet werden kann. Ein Beispiel hierfür ist z.b. das Bezahlen einer Rechnung. Ist eine Rechnung bezahlt worden, und die Bestätigungsdaten gehen verloren, so wird der Betrag fälschlicherweise ein zweites Mal ausbezahlt. Damit dies nicht passieren kann, dürfen keine Ergebnisse verloren gehen. Analog zur ersten Forderung kann auch die zweite Forderung begründet werden. Diese Eigenschaften sind direkt aus den Anforderungen an stabile Datenbanksysteme abgeleitet. Große Datenbanksysteme, wie sie z.b. im Bankenbereich eingesetzt werden, sind als stabile Systeme konzipiert. Die Stabilität wird vorwiegend durch das eigens dafür entwickelte Konzept der Transaktionen erreicht. Im folgenden wird zunächst das Grundkonzept der Transaktionen, die ACID-Transaktionen vorgestellt. Basierend auf den ACID-Transaktionen wird dann ein Modell definiert, wie ACID- Transaktionen in Workflow-Management-Systemen eingesetzt werden können. Ausgehend von diesem Modell werden weitere transaktionale Konzepte vorgestellt, und deren Vorteile und Einsatzbereiche in Workflow-Management-Systemen beschrieben. 3.1 Transaktionen in Datenbanksystemen Hinter dem Begriff Transaktion steht ein Konzept, das man vereinfacht als alles oder nichts beschreiben kann. Ein B eispiel verdeutlicht dies: Ein Bankkunde möchte eine Überweisung von einem Konto auf ein anderes durchführen. Dabei muß der Betrag von dem einen Konto abgezogen werden und auf das andere Konto addiert werden. Wird nun der Vorgang nach dem Abziehen des Betrags von d e m einen Konto abgebrochen, z.b. durch einen Stromausfall, so hätte die EDV den Betrag verschluckt. U m einem solchen Fall vorzubeugen, sind Transaktionen 15