Diese Seite wird nicht mehr gepflegt. Bitte besuchen Sie www.PROJECT-CONSULT.de
This website is no longer updated. Please visit www.PROJECT-CONSULT.de
Workflow-gestützte Steuerung von Unternehmensprozessen Prozeßstrukturen und Systemfunktionalitäten
Einleitung
Das Workflow-Modell
Varianten von Prozesse und Anforderungen an die Modellierung
Ausblick
Von Martin Fichter
Profil_Fichter
Top
Einleitung
Mit der Bewältigung aktueller Anforderungen wie der Einführung des Euro und des Jahrtausendwechsels wird Workflow zu einem der wichtigsten Themen der nächsten Jahre für die Unternehmen. So prognostiziert die Gartner Group in ihrer neuesten Studie „State of the Document Technologies Industry: 1997-2003“ ein Wachstum von 42 Prozent allein für die Systeme, die speziell Production Workflow unterstützen. Hinzu kommt ein Wachstum von 24 Prozent für Systeme, die vorrangig Ad hoc-Workflow ermöglichen.
Wie aus dieser Prognose schon hervorgeht, lassen sich verschiedene Arten unternehmerischer Prozesse unterscheiden, die sich in den Anforderungen und schließlich in den Lösungen widerspiegeln. In der Vergangenheit konnten viele Workflow-Systeme schwerpunktmäßig nur bestimmte Prozeßarten unterstützten. Mittlerweile sind jedoch intensive Anstrengungen der Hersteller zur Bereitstellung flexibler Systeme zu beobachten, die ein breites Spektrum von Prozessen bedienen können. Welche Funktionalitäten notwendig sind, um die Anforderungen der verschiedenen Prozeß-Strukturen abdecken zu können, soll im folgenden an einem Workflow-Modell erläutert werden.
Top
Das Workflow-Modell
Das gewählte Modell erfüllt alle Voraussetzungen für die Integration von Applikationen in das Workflow-System. Damit erfüllt es auch alle Voraussetzungen für die Vorgangssteuerung im Sinne eines Workflow-basierenden Geschäftsprozesses. Es ist einer Client/Server-Architektur entsprechend in drei Schichten aufgebaut: der Anwendungsebene (Runtime), dem Versionsmanagement (Repository) und der Datenhaltung (Buildtime). Die Daten, die zur Modellierung der Prozesse notwendig sind, werden in unterschiedlichen Dateien abgelegt. Dadurch werden die Zugriffe für Anwender und Administrator ermöglicht
Standardmäßig werden in der Buildtime die einzelnen Aktionen und Aufgaben definiert, um anschließend im Rahmen eines Vorgangs zu einem Arbeitsablauf zusammengefügt zu werden. Aktionen sind Bestandteil der Aufgaben und dienen dem Direktaufruf von Fachanwendungen. Aufgaben beinhalten alle Steuerungsfunktionen für ihre Bearbeitung wie den zuständigen Mitarbeiter und Terminangaben.
Aktiviert ein Anwender einen Vorgang, wird die jeweils gültige Version der Ablaufdefinition in das Repository geladen. Auf Basis dieser Version wird der Vorgang in der Laufzeitumgebung verwaltet und kontrolliert.
In der Runtime wird der Anwender in seiner Vorgangsbearbeitung unterstützt. Mit der Initiierung eines Vorgangs überprüft das System den Definitionsbereich, lädt die aktuelle Version in das Repository, aktiviert selbstständig alle relevanten Aufgaben und bringt sie dem Anwender in sog. to-do-Listen zur Anzeige.
Top
Varianten von Prozesse und Anforderungen an die Modellierung
Damit das System das gesamte Prozeßspektrum von Ad hoc-Workflow bis Production Workflow bedienen kann, erlaubt das Modell neben dem Administrator auch den einzelnen Anwendern die Erstellung, Ergänzung und Änderung von Vorgängen. Während der Administrator die Definition in der Buildtime durchführt, ist dies dem Anwender allerdings nur auf Ebene des Repositories und der Runtime gestattet.
Variante 1: Fest strukturierte und unveränderbare Vorgänge
Diese Variante entspricht der Definition des Production Workflow der WfMC (Workflow Management Coalition). Die Vorgänge sind das Ergebnis von Prozeßanalysen und Vereinbarungen zur Bearbeitung. Sie werden stets in der gleichen Art und Weise bearbeitet. Abweichungen bzw. Ausnahmen vom Standard sind bekannt und werden ebenfalls über die Vorgangsdefinition abgefangen. Der Anwender erhält keine Handlungsalternativen und keine Möglichkeiten zur individuellen Ergänzung und Änderung des Ablaufs oder einzelner Aufgaben.
Variante 2: Fest strukturierte Vorgänge mit Entscheidungsspielräumen
Dem Anwender werden bestimmte Entscheidungsspielräume bei der Vorgangsbearbeitung zuerkannt. Das kann auf mehreren Wegen geschehen:
Dem Anwender wird mit Aufruf einer Aktion kein Eingabefeld oder ein bestimmtes Fachanwendungsprogramm zur Verfügung gestellt, sondern ein Submenü. In diesem wählt er das oder die benötigten Anwendungsprogramme aus.
Der Anwender darf bestimmte Attribute wie Terminvorgaben des Vorgangs oder der Aufgaben ändern.
Die zu einer Aufgabe hinterlegten Aktionen werden nicht als „Muß-„ sondern als „Kann“-Ausführung hinterlegt.
Die Reihenfolge der Bearbeitung von Aktionen innerhalb einer Aufgabe wird vom Anwender bestimmt.
Variante 3: Fest strukturierte, durch den Anwender veränderbare Vorgänge
Der Vorgang wird vom Administrator definiert und für die Bearbeitung zur Verfügung gestellt. Da im Rahmen des Vorgangs immer wieder unterschiedliche Spezifika auftreten können, wird dem Anwender die Möglichkeit eingeräumt, den realen und in Bearbeitung befindlichen Vorgang zu ändern. Dies erfolgt entweder über die Zuordnung einer weiteren Aktion zu einer Aufgabe, zum Einfügen einer komplett neuen Aufgabe, zur Deaktivierung einer Aufgabe oder zur Erstellung eines Teilvorgangs.
Variante 4: Unmittelbare und einmalige Vorgänge
Solche Vorgänge treten vorzugsweise im unternehmensinternen Bereich oder bei der Erschließung neuer Geschäftsfelder auf. Sie entsprechen der WfMC-Definition des Ad hoc-Workflow. In der Vergangenheit wurde oftmals die Meinung vertreten, daß sich solche Vorgänge in Charakter, Zielstellung und Einsatzbereich soweit von z. B. dem Production Workflow unterscheiden, daß sie auch in einem separaten (E-Mail) System funktionieren können. Dabei wurde übersehen, daß Workflow-Systeme nicht nur eine steuernde, sondern auch eine informatorische und protokollierende Funktion wahrnehmen. Durch die Historisierung der einzelnen Vorgänge werden elektronische Akten zu Kunden, Lieferanten oder Objekten beliebiger Art im System so gespeichert, daß der Anwender schnell auf die übersichtlich angeordneten Informationen zugreifen kann. Verlagert man einen Teil der Vorgangsbearbeitung in ein anderes System, werden dadurch auch die Informationen verteilt. Dies führt zum teilweisen Verlust einer wesentlichen Eigenschaft von Workflow-Systemen.
In dem vorgestellten Modell wird auch der Ad hoc-Workflow unterstützt. So hat der Anwender die Möglichkeit, im Repository über die vorhandenen Aufgaben- und Aktionsdefinitionen kleine Arbeitsabläufe selbst zu definieren und mit bestimmten Bedingungen zu ihrer Steuerung auszustatten. Dies wird durch den Einsatz von Schablonen und intelligenten Suchfunktionen unterstützt. Eine weitere Möglichkeit ist, daß er die benötigten Aufgaben nicht im Repository, sondern direkt in der Anwendungsebene definiert. Wesentlicher Unterschied ist, daß in der Anwendungsebene kein Ablauf graphisch modelliert wird, sondern die Aufgaben (vergleichbar E-Mails) direkt in die to-do-Listen der zuständigen Mitarbeiter eingestellt werden. Die Aufgaben sind damit generell gleichberechtigt. Das bedeutet, daß sie in ihrer Bearbeitung nicht voneinander abhängen. Ein Ablauf läßt sich allenfalls über die Vorgabe unterschiedlicher Erledigungstermine erreichen. Im Unterschied zu E-Mails befinden sich die Aufgaben komplett im Workflow-System, können unter einem Vorgang zusammengefaßt und angezeigt werden und sie kennen vor allem ihre Applikation. Der Anwender ist auch bei dieser Variante in der Lage, mit dem Aufruf der Aufgabe direkt in das benötigte Fachanwendungsprogramm oder in eine Office-Anwendung zu verzweigen.
Top
Ausblick
Ebenso wie die Anforderungen an eine kundenorientierte, schnelle und flexible Vorgangsbearbeitung steigen, wachsen die Erwartungen an die Leistungsfähigkeit und Flexibilität von Workflow-Systemen. In diesem Sinne stellt sich die berechtigte Frage, wie ein Sachbearbeiter kundenindividuell agieren soll, wenn das System nur standardisierte Vorgehensweisen zuläßt.
Zudem unterliegen Ablaufdefinitionen einem immer kurzfristigeren Wandel. So haben viele Unternehmen in den letzten Jahren aufwendige Business Process Reengineering-Projekte durchgeführt. Mit dem Aufkommen des Internet werden viele dieser Prozeß-definitionen bereits wieder einer Modifikationen unterzogen. Hierdurch ergeben sich zusätzliche Anforderungen an Workflow-Systeme, was das Change-Management sowohl der Ablaufdefinition als auch der Einbindung von Applikationen betrifft.
Die Entwicklungen der Hersteller dürfen in den nächsten Monaten mit Spannung betrachtet werden, zumal immer mehr große Systemhäuser wie Oracle und Hewlett Packard mit eigenen Produkten in den Workflow-Markt eintreten bzw. ihre Produktlinie durch Zukauf ergänzen, wie es jüngst Lotus Development mit ONEstone getan hat. Erfreulicherweise lassen die Produktentwicklungen deutliche Verbesserungen in der flexiblen Verwaltung von Production Workflow, Administrative Workflow und ad hoc-Workflow erwarten. Für eine Belebung des Markts ist zu hoffen, daß sich dieser Trend massiv fortsetzen wird.
Rechtshinweis
© CopyRight PROJECT CONSULT 2002, Autorenrechte Martin Fichter
Rechtshinweis
Autorenrechte

Top
Seitentitel: Artikel_WMS, Zitierung: http://www.PROJECT-CONSULT.com/home.asp?SR=431
Zuletzt aktualisiert am: 25.4.2002
CopyRight © 1992-2012 PROJECT CONSULT Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH
20251 Hamburg, Breitenfelder Str. 17, Tel.: +49-40-46076220, E-Mail, Rechtshinweis
Optimiert für MS Explorer 5.x, 6.x, 1024x768 Pixel, Cookies(on), JavaScript(on)
Diese Seite wird nicht mehr gepflegt. Bitte besuchen Sie www.PROJECT-CONSULT.de
This website is no longer updated. Please visit www.PROJECT-CONSULT.de