DE19948028A1

DE19948028A1 - Verfahren und System zum Optimieren des Anforderungsschickens in Workflow Management Systemen

Info

Publication number: DE19948028A1
Application number: DE19948028A
Authority: DE
Inventors: Frank Leymann; Dieter Roller
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1998-11-20
Filing date: 1999-10-06
Publication date: 2000-05-31
Also published as: US6832201B1

Abstract

Vorgeschlagen wird ein Verfahren zum Optimieren des Anforderungsschickens innerhalb einer Vielzahl von verteilten, vernetzten Rechnersystemen, einschließlich einer verteilten Applikation, deren Benutzung ein dieser Applikation zugrundeliegendes Prozeßmodell realisiert, in dem das Prozeßmodell einen Geschäftsablauf beinhaltet, bestehend aus einer Vielzahl von Aktivitäten, die auf den Applikationssystemen durch eine Vielzahl von Anwendern ausgeführt werden müssen, einschließlich des Schickens von Aktivitätsanforderungen zwischen einem örtlichen Applikationssystem, dem der Geschäftsablauf zugeeignet ist, und einer Vielzahl von Fernapplikationssystemen, die die Aktivitäten mit Hilfe einer Vielzahl Anwender ausführen. DOLLAR A Die Grundidee ist das Optimieren der Zuweisung der Anwender zu den geeigneten Applikationssystemen auf eine Weise, daß die Anzahl der Fernarbeitselementanforderungen optimiert wird. Das erfindungsgemäße Verfahren kann vorteilhaft auf Workflow Management Systeme angewandt werden. Der betroffene Optimierungsprozeß beinhaltet die Anwendung einer sogenannten "Optimierungsfunktion", die die Gesamtkosten für die Anforderungsschicken und zusätzliche Kosten für die Durchführung des Geschäftsablaufs wiedergibt (Figur 4).

Description

DER ERFINDUNG ZUGRUNDELIEGENDER ALLGEMEINER STAND DER TECHNIK 1.1 BEREICH DER ERFINDUNG

Die vorliegende Erfindung betrifft die Verbesserung des An forderungsschickens in verteilten Applikationen, insbesondere in Workflow Management Systemen, im folgenden WMS bezeichnet, die in einer verteilten Umgebung in einem vernetzten Rechnersystem arbeiten. Insbesondere bezieht sich die vorliegende Erfindung auf ein Verfahren und ein System zum Optimieren des Anforderungsschickens in solchen Systemen.

1.2 BESCHREIBUNG UND NACHTEILE DES STANDES DER TECHNIK

Zwar ist der Gegenstand der Erfindung anwendbar auf die ver schiedensten Applikationen, d. i. wenn immer eine Applikation mit der grundlegenden Struktur und Terminologie der WMS be schrieben werden kann, jedoch wird die vorliegende Erfindung hier beispielhaft als Anwendung auf ein WMS beschrieben.

Ein neues Gebiet der Technologie mit steigender Bedeutung ist die Domäne der WMS. WMS, wie sie z. B. vom IBM FlowMark implementiert werden, unterstützen die Modellierung und Ausführung von Geschäftsvorgängen. Geschäftsvorgänge regeln, welcher Arbeitsteil eines Arbeitsteilnetzes von wem durchgeführt wird und welche Betriebsmittel für die Arbeit eingesetzt werden, d. h., ein Geschäftsablauf beschreibt, wie ein Unternehmen seine geschäftlichen Ziele erreicht. Die einzelnen Arbeitsteile können auf eine Vielzahl verschiedener Rechnersysteme verteilt sein, die über irgendeine Art Netzwerk zusammengeschlossen sind.

Der Prozeß des Konstruierens, Entwickelns und Fertigens eines neuen Produkts und der Prozeß des Änderns oder Anpassens eines bereits existierenden Produkts ist eine Herausforderung für Produktmanager und Ingenieure, das Produkt mit den geringsten Kosten und innerhalb des Zeitplans auf den Markt zu bringen und dabei die Produktqualität zu wahren oder sogar noch zu verbessern. Vielen Firmen ist klar, daß der herkömmliche Produktkonstruktionsprozeß nicht ausreicht, um diesen Forderungen gerecht zu werden. Sie brauchen frühzeitige Anforderungen an die Fertigungstechnik, kostenbewußte Techniker, logistische Planung, Beschaffung, Fertigung, Dienstleistung und Unterstützung durch konstruktive Bemühun gen. Ferner erfordern sie Planung und Regelung der Produkt daten durch Konstruktion, Freigabe und Fertigung.

Die korrekte und wirksame Ausführung von Geschäftsvorgängen innerhalb einer Firma, z. B. Entwicklungs- oder Produktions prozesse, ist von enormer Bedeutung für eine Firma und hat einen signifikanten Einfluß auf den allgemeinen Erfolg der Firma auf dem Markt. Somit müssen diese Prozesse ähnlich wie technische Prozesse angesehen werden und müssen getestet, optimiert und verfolgt werden. Die Verwaltung solcher Pro zesse wird üblicherweise von einem rechnergestützten Prozeß d. i. WMS ausgeführt und unterstützt.

In D. J. Spoon: "Project Management Environment", IBM Techni cal Disclosure Bulletin, Bd. 32, Nr. 9A, Februar 1990, S. 250-254, wird eine Prozeßverwaltungsumgebung einschließlich Betriebsumgebung, Datenelemente und Applikationsfunktionen und -prozesse beschrieben.

In R. T. Marshak: "IBM's FlowMark, Objet-Oriented Workflow for Mission-Critical Applications", Workgroup Computing Report (USA), Bd. 17, No. 5, 1994, S. 3-13, wird der Objektcharakter des IBM FlowMark als Client/Server-Produkt, aufgebaut auf ein echtes Objektmodell, beschrieben, dessen Ziel eine einsatzkritische Produktionsprozeß-Applikations entwicklung und -einsatz ist.

In H. A. Inniss und J. H. Sheridan: "Workflow Management Based on an Object-Oriented Paradigm", IBM Technical Disclosure Bulletin, Bd. 37, Nr. 3, März 1994, Seite 185 werden weitere Aspekte der objektorientierten Modellierung für kunden spezifische Anpassung und Änderungen beschrieben.

In F. Leymann und D. Roller: "Business Process Management with FlowMark", Digest of Papers, Cat. No. 94CH3414-0, Spring COMCON 94, 1994, S. 230 bis 234, wird das Verwaltungswerkzeug für Rechnerprozesse des IBM FlowMark auf dem Stand der Technik beschrieben. Das Metamodell des IBM- FlowMark sowie auch die Implementierung des IBM-FlowMark wird vorgestellt. Die Möglichkeiten des IBM-FlowMark für die Modellierung von Geschäftsvorgängen sowie deren Ausführung werden diskutiert. Das Produkt IBM-FlowMark ist auch verfügbar für andere Computer-Plattformen und die Dokumentation für den IBM-FlowMark ist in jeder IBM-Branche verfügbar.

In F. Leymann: "A meta model to support the modeling and execution of processes", Proceedings of the 11^th European Meeting on Cybernetics and System Research EMCR92, Wien, Österreich, 21.-24. April 1992, World Scientific 1992, S. 287-294, wird ein Metamodell zum Steuern von Geschäfts vorgängen vorgestellt und detailliert diskutiert.

Der "IBM FlowMark for OS/2", Unterlage Nr. GH 19-8215-01, IBM Corporation, 1994, erhältlich in jedem IBM-Verkaufsbüro, stellt ein typisches, modernes, hochentwickeltes und mäch tiges WMS dar. Es unterstützt die Modellierung von Geschäftsvorgängen als Netzwerk von Aktivitäten; siehe z. B. "Modeling WorkFlow", Unterlage Nr. SH 19-8241, IBM Corporation, 1996. Als weitere Informationen über Workflow Management Systeme, erhältlich in IBM Verkaufsbüros, könnte man anführen: IBM MQSeries Concepts and Architecture, Unterlage Nr. GH 12-6285; IBM MQSeries Getting Started with Buildtime, Unterlage Nr. SH 12-6286; IBM MQSeries Getting Started with Runtime, Unterlage Nr. SH 12-6287. Dieses Netzwerk von Aktivitäten, das Prozeßmodell, ist aufgebaut als ein gerichteter, azyklischer, gewichteter, farbiger Graph. Die Knoten des Graphen stellen die Aktivitäten der Arbeitselemente dar, die ausgeführt werden. Die Ränder des Graphen, die Steuerverbinder, beschreiben die potentielle Reihenfolge der Ausführung der Aktivitäten. Die Definition des Prozeß-Graphen geschieht mittels der IBM FlowMark Definitionssprache (Definition Language - FDL) oder dem eingebauten Graphikeditor. Die Runtime-Komponente des Workflow Manager interpretiert den Prozeßgraphen und teilt die Ausführung der Aktivitäten an die richtige Person am richtigen Ort auf, z. B. durch Zuweisung des Tasks zu einer Arbeitsliste der entsprechenden Person, wobei die Arbeitsliste als digitale Daten im Arbeitsablauf oder im Prozeßverwaltungs-Rechnersystem abgespeichert sind.

In F. Leymann und W. Altenhuber: "Managing business processes as an information resource", IBM Systems Journal, Bd. 32(2), 1994, wird die dem IBM-Produkt FlowMark zugrundeliegende mathematische Theorie beschrieben.

In D. Roller: "Verifikation von Workflows im IBM FlowMark", in J. Becker und G. Vossen (Herausg.): "Geschäftsablauf modellierung und Workflows", International Thompson Publishing, 1995, wird die Anforderung und Möglichkeit der Verifikation von Arbeitsabläufen beschrieben. Ferner wird das Merkmal der graphischen Animation für die Verifikation der Prozeßlogik dargestellt, wie sie im IBM-Produkt FlowMark implementiert ist.

Zum Implementieren eines rechnergestützten Prozeßverwaltungssystems müssen als erstes die Geschäftsprozesse analysiert werden, und als Ergebnis dieser Analyse muß ein Prozeßmodell als Aktivitäten-Netzwerk entsprechend dem Geschäftsablauf aufgebaut werden. Im IBM- Produkt FlowMark werden die Geschäftsmodelle nicht in ein lauffähiges Modell umgewandelt. Bei Laufzeit wird ein Muster des Prozesses aus dem Prozeßmodell erstellt, genannt eine Prozeß-Instanz. Diese Prozeßinstanz wird dann vom IBM- Produkt FlowMark dynamisch interpretiert.

Ein Anwender kommuniziert in der Regel im Dialog mit dem WMS über eine graphische Endanwender-Schnittstelle, die die vom Anwender auszuführenden Tasks als Icons darstellt. Die Aus führung eines bestimmten Tasks läuft an, wenn der Anwender auf das betreffende Icon doppelklickt, was seinerseits das Programm zum Implementieren der Aktivität anlaufen läßt.

Diese Aktivitäten sind im allgemeinen Schritte innerhalb eines bestimmten Geschäftsablaufs. Jede Aktivität stellt einen Arbeitsteil dar, den die angesprochene Person durch Starten eines Programms oder eines anderen Prozesses ab schließen kann.

Die auszuführenden Arbeiten weisen in der Regel eine Fein struktur auf:
Eine Aktivierungsbedingung definiert, wann die Aktivität zur Ablaufsteuerung durch den Workflow Manager bereit ist; eine Ausstiegsbedigung definiert, wann eine Aktivität durch den Workflow Manager als abgeschlossen behandelt werden soll. Der Kern der Aktivität ist der Task, der aus der eigentlichen Aktivität und einer Anfrage an eine Organisationsdatenbank besteht. Die eigentliche Aktivität weist die Aktivität einem Programmobjekt zu. Das . Programmobjekt definiert für jedes Betriebssystem, und möglicherweise auch für jeden Anwender, den Namen und die operativen Merkmale für ein ausführbares Stück Software. Das ausführbare Stück Software läuft an, wenn die Aktivität durch einen Anwender ausgeführt wird. Die Anfrage an die Organisations-Datenbank definiert die Personen, die für die Ausführung der Aktivität zuständig sind. Wenn die Aktivität zur Aufnahme in den Programmablauf bereit ist, führt das Workflow Management die spezifische Abfrage an die Organisations-Datenbank durch. Diese Abfrage gibt einen Satz Personen zurück, denen die Aktivität zugewiesen ist. Der Task wird in einen Satz Arbeitselemente umgewandelt, jeweils eines für jede Person, die als Ergebnis der Anfrage an die Organisations-Datenbank ausgewählt wird. Das Arbeitselement enthält den Namen der Person und das auszuführende Programm. Diese Arbeitselemente werden Teil der Arbeitsliste der Anwender.

Jede der Aktivitäten wird durch eine Aktivitätenimplemen tierung ausgeführt. Die Aktivitätenimplementierungen sind in der Regel Programme, sie können aber auch der Aufruf eines Verfahrensobjekts oder einer in einer relationalen Datenbank abgespeicherte Prozedur sein. Das wird später unter Bezug nahme auf Fig. 2 beschrieben.

Die Ergebnisse, die im allgemeinen von der von einer Aktivi tät repräsentierten Arbeit produziert werden, werden in der Regel in einen Ausgangscontainer gelegt, der jeder Aktivität zugeordnet ist. Da eine Aktivität im allgemeinen einen Zugriff auf Ausgangscontainer anderer Aktivitäten erfordert, wird jede Aktivität auch zusätzlich einem Eingangscontainer zugeordnet. Zur Laufzeit repräsentieren die wahren Werte für die formalen Parameter, die den Eingangscontainer einer Aktivität bilden, den wahren Kontext einer Instanz der Aktivität. Jeder Datencontainer wird durch eine Datenstruktur definiert. Eine Datenstruktur ist eine geordnete Liste von Variablen, genannt Strukturglieder, die einen Namen und einen Datentyp aufweisen. Datenverbinder repräsentieren die Übertragung von Daten aus dem Ausgangscontainer auf die Eingangscontainer. Wenn ein Datenverbinder einen Ausgangscontainer mit einem Eingangscontainer verbindet und die Datenstrukturen der zwei Container ganz genau übereinstimmen, bildet der FlowMark Workflow Manager die Daten automatisch ab.

Ein Geschäftsablaufmodell beinhaltet ferner die Beschreibung des Aktivitätenflusses selbst zwischen den Betriebsmitteln ("resources"), die die betreffenden, von den einzelnen Aktivitäten dargestellten Arbeitsteile tatsächlich ausführen. Ein Systemelement kann als ein besonderes Programm, eine Person, eine Rolle oder eine organisatorische Einheit spezifiziert sein. In der Laufzeit werden die Tasks in Aufforderungen zur Durchführung bestimmte Aktivitäten an bestimmte Personen aufgelöst, was zu Arbeitselementen für diese Personen führt. Personalzuordnungen sind das Mittel, um Aktivitäten in der durch den Steuerflußaspekt eines Ge schäftsablaufmodells vorgeschriebenen Folge an die richtigen Leute aufzuteilen. Die Art und Weise, wie dem Personal Arbeit zugewiesen wird, wird später im Kapitel 4.1 in weiteren Einzelheiten beschrieben. Jede Aktivität in einem Prozeß wird einem oder mehreren Personalmitgliedern zugewiesen, die in der FlowMark-Datenbank definiert sind. Ob eine Aktivität manuell vom Anwender oder automatisch vom FlowMark Workflow Manager gestartet wird, und ob sie des Eingriffs des Anwenders zur Fertigstellung der Arbeit bedarf, oder die Arbeit selbständig fertigstellt, es muß immer ein Personalmitglied zugewiesen werden. Die FlowMark Personaldefinition beinhaltet mehr als die Identifizierung von Leuten in Ihrem Unternehmen in der FlowMark-Datenbank.

Für jede definierte Person können Sie eine Stufe, eine Organisation und vielfache Rollen spezifizieren. Diese Attribute können in der Laufzeit benutzt werden, um Leuten mit geeigneten Attributen dynamische Aktivitäten zuzuweisen.

Eine Grundannahme solcher Systeme auf dem Stand der Technik ist, daß ein spezifisches WMS der Eigner des Arbeitsablaufs ist. Für andere Arbeitsabläufe kann ein anderes WMS der Arbeitsablaufeigner sein. Das Eigner-WMS läuft an und steuert die Ausführung des geeigneten Arbeitsablaufs. Dieses WMS heißt das "örtliche" WMS weil dieses der übliche Ort für die Ausführung des Arbeitsablaufs ist.

Eine weitere Grundannahme ist, daß ein Anwender immer nur einem WMS zugewiesen wird, für das der Anwender identifiziert ist, z. B. durch seine/ihre Anwender-ID.

Wenn ein Anwender für eine bestimmte Aktivität ausgewählt ist und dieser Anwender einem anderen WMS zugewiesen wird, muß eine entsprechende Information an das andere WMS geschickt werden, damit es in der Lage ist, diese Aktivität auszuführen. Dieses Schicken von Informationen wird nachstehend als "Anforderung schicken" bezeichnet. Aus offensichtlichen Gründen wird dieses andere WMS als "Fern"- WMS bezeichnet.

Wenn nur ein einziger Anwender ausgewählt wird, kann eine entsprechende Arbeitsanforderung einschließlich der zuge hörigen Aktivitätsdaten direkt an dieses andere WMS geschickt werden. Diese Aktivitätsdaten beinhalten den Eingangscontainer, den teilweise mit voreingestellten Werten gefüllten Ausgangscontainer, die Personal-spezifischen Daten und die Aktivitäts-spezifischen Daten.

Im einzelnen lassen sich die bei Wahl eines Anwenders vom örtlichen WMS übernommenen Aktionen, die einem Fern-WMS zugewiesen werden, wie folgt zusammenfassen:
Als erstes wird eine Personalaufteilung durchgeführt, die später im einführenden Kapitel 4.1 in weiteren Einzelheiten beschrieben wird. Zwecks Vereinfachung wird angenommen, daß genau ein Anwender zum Arbeiten an der Aktivität gewählt wird. Wenn der einzige gewählte Anwender nicht Teil des örtlichen WMS ist, wird das geeignete Arbeitsablaufsystem bestimmt. Als nächstes wird eine Anforderung einschließlich dieser Aktivitätsdaten an das Fern-WMS geschickt. Dann wird auf Anwort gewartet. Sobald die Antwort eingeht, führt das örtliche WMS die geeigneten Aktionen durch, wie z. B. Abspeichern des Ausgangscontainers in der Datenbank, Abspeichern der Prüfpfadinformationen (in ein Ausführungsprotokoll, auch Audit Trail genannt) und Fortsetzen der Navigation.

Das Fern-WMS führt die folgenden Aktionen durch:
Es empfängt die Anforderung vom örtlichen WMS. Dann werden diese Aktivitätsdaten in einer Datenbank gespeichert. Als nächstes wird für den angegebenen Anwender ein Arbeitselement erzeugt und wird auf die Arbeitsliste dieses Anwenders gesetzt.

Dann muß das System warten, bis der Anwender sein Arbeits element wählt. Die Container müssen von der Datenbank abgerufen werden und die Aktivitätsimplementierung muß aufgerufen werden. Dann werden die Prüfpfadaufzeichnungen erzeugt, Containeranforderungen werden erfüllt, und das System muß warten, bis die Aktivitätsimplementierung abgeschlossen ist.

Als nächstes wird der Container und der Prüfpfad zurück an das örtliche WMS geschickt und etwaige Rückstände werden ausgeräumt.

Ein viel komplizierteres Verfahren wird erforderlich, wenn bei der Personalauflösung Anwender von mehr als einem WMS angewählt werden. In diesem Fall muß sichergestellt sein, daß ein und nur ein Anwender die Aktivität ausführt. Das setzt voraus, daß das betroffene WMS neben dem einfachen Anforderungsschicken noch weitere Informationen austauscht. Wie im einfachen Fall stimmt das örtliche WMS alle Wechselwirkungen zwischen den betroffenen WMS ab.

In diesem Fall werden die nachstehenden Schritte ausgeführt. Zwecks Vereinfachung wird angenommen, daß kein Anwender aus dem örtlichen WMS gewählt wurde.

Das örtliche WMS sendet eine Arbeitselementanforderung an alle Fern-WMS, die wenigstens einen gewählten Anwender aufweisen. Die Arbeitselementanforderung beinhaltet eine Liste aller Anwender, die dem Ziel-WMS zugeordnet sind, plus Informationen, die es dem Fern-WMS ermöglichen, Arbeits elemente für die gewählten Anwender zu erzeugen.

Die Fern-WMS erzeugen Arbeitselemente für jeden Anwender und setzen diese Arbeitselemente auf die richtigen Arbeitslisten der Anwender. Da das von einem Fern-WMS gemacht wird, werden diese Arbeitselemente vom örtlichen WMS als Fern-Arbeits elemente angesehen.

Wenn ein Anwender ein Arbeitselement wählt, löscht das zuständige WMS zunächst dieses aus den Arbeitslisten aller Anwender, die dem gleichen WMS zugeordnet sind, und informiert dann das örtliche WMS, daß das Arbeitselement gewählt wurde.

Das örtliche WMS bestimmt das Fern-WMS, auf dem die Aktivität zunächst gewählt wurde, und schickt dann eine "Anforderung zum Ausführen" an das gewählte Fern-WMS. Diese Anforderung enthält alle der Aktivität zugeordneten Informationen.

Das örtliche WMS sendet an die anderen Fern-WMS eine Meldung, daß ihre Anforderungen nicht mehr länger erfüllt werden. Die nicht gewählten WMS löschen die Arbeitselemente aus ihren entsprechenden Arbeitslisten. Für den Fall, daß ein Anwender sein Arbeitselement bereits gewählt hat, wird der Anwender darüber informiert, daß jemand anderer das Arbeitselement gewählt hat.

Sobald das Arbeitselement vom gewählten Anwender abgeschlos sen ist, schickt das Fern-WMS den Ausgangscontainer und die Prüfpfadinformationen zurück.

Das örtliche WMS speichert den Ausgangscontainer in seiner Datenbank, speichert die Prüfpfadinformationen und fährt mit der Navigation fort.

Das der vorliegenden Erfindung zugrundeliegende Problem be steht daher in einer großen Anzahl "verteilter" oder "Fern"- Arbeitselemente, weil aus der vorhergehenden Beschreibung ersichtlich ist, daß die Verwaltung der verteilten Arbeitselemente, d. i. das Hinundherschicken der Arbeits anforderungen zwischen den verschiedenen WMS teuer wird. Die dieser Verarbeitungsart zuzuordnenden Kosten sind propor tional der Anzahl WMS, die an der Bearbeitung einer Aktivität beteiligt werden müssen.

1.3 AUFGABEN DER ERFINDUNG

Es ist daher die allgemeine Aufgabe der vorliegenden Erfin dung, ein Verfahren und ein System bereitzustellen zum Optimieren von Versandaufforderungen in verteilten Applika tionen, und insbesondere in Workflow Management Systemen.

2. ZUSAMMENFASSUNG UND VORTEILE DER ERFINDUNG

Die Aufgabe der vorliegenden Erfindung wird gelöst durch die Merkmale, die in den beiliegenden unabhängigen Ansprüchen 1, 7 und 8 angeführt sind. Weitere vorteilhafte Anordnungen und Ausführungsformen der Erfindung sind in den entsprechenden Unteransprüchen aufgeführt.

Vorgeschlagen wird ein Verfahren zur Optimierung des Anforderungsschickens innerhalb einer Vielzahl von verteilten, vernetzten Rechnersystemen, das eine verteilte Applikation beinhalten, deren Anwendung ein Verfahrensmodell als Grundlage dieser Applikation realisiert, wobei das Prozeßmodell einen Geschäftsablauf bestehend aus einer Vielzahl von Aktivitäten beinhaltet, die in dem Applikationssystem durch eine Vielzahl Anwender ausgeführt werden müssen, einschließlich Schicken von Aktivitätsanforderungen zwischen einem örtlichen Applikationssystem, das der Eigner dieses Geschäftsablaufs ist, und einer Vielzahl von Fernapplikationssystemen, die diese Aktivitäten mit Hilfe der Vielzahl Anwender ausführen.

Die Grundidee ist, die Zuordnung der Anwender zu den ge eigneten Applikationssystemen zu optimieren durch Neuzu weisung von Anwendern zu einem anderen WMS auf eine Weise, daß die Anzahl der Fernarbeitselementanforderungen optimiert wird. Die erfindungsgemäße Methode kann vorteilhaft auf Workflow Management Systeme (WMS) angewandt werden. Der betreffende Optimierungsprozeß enthält das Anwenden einer sogenannten "Optimierungsfunktion", die die Gesamtkosten für das Anforderungsschicken und zusätzliche Kosten zur Durch führung des Geschäftsablaufs wiedergibt.

Hierbei ist ein wesentlicher Parameter die Anzahl der betroffenen Applikationssysteme, insbesondere WMS, weil diese die Empfänger der "teueren" Arbeitselementanforderungen sind, die im übergeordneten System verschickt werden. Der zweite wesentliche Parameter ist die Anzahl der Arbeitselementanforderungen, die im System verschickt werden.

U. a. sind weitere zusätzliche Zwänge, die die Kosten beein flussen, Hardwarekosten, verfügbare Bandbreite auf Daten übermittlungsverbindungen zwischen bestimmten Applikations systemen bzw. WMS, Wartungskosten und individuelle Produkt qualitätskosten, die für jeden Geschäftsablauf und jedes Unternehmen spezifisch sind.

Also müssen Gesamtkosten, einschließlich aller obigen Para meter, durch das erfindungsgemäße Verfahren innerhalb ver nünftiger Grenzen minimiert werden, die von der Unternehmensverwaltung bestimmt werden.

Zur Durchführung dieser Optimierungsfunktion ist ein Opti mierungsdatenerfassungsschritt erforderlich. In diesem Schritt werden eine Vielzahl Fakten gesammelt, wobei einige dieser Fakten statistische Daten und die übrigen nicht statistische Daten sind.

Dann werden die individuellen Optimierungsdaten gewichtet und die Gesamtoptimierungsfunktion kann aufgestellt werden oder eine bereits bestehende Funktion kann ausgewählt und angewandt werden. Als Ergebnis der Optimierung werden einige Anwender möglicherweise einem anderen Applikationssystem zugewiesen, insbesondere einem anderen WMS. Damit verringert sich die Anzahl der Arbeitselementanforderungen mit der Neuzuweisung.

DAS verfahren der vorliegenden Erfindung mit den Merkmalen des Anspruchs 1 hat in Bezug auf die in der Diskussion des Standes der Technik skizzierte Methode den Vorteil, daß sich das Anforderungsschicken verringert und somit die der Aus führung des Geschäftsvorgangs zugeordneten Kosten sinken.

In einer bevorzugten Ausführungsform der erfindungsgemäßen Methode umfaßt der Datensammelschritt das Ausziehen der Optimierungsdaten aus dem Prüfgfad des örtlichen WMS.

In einer bevorzugten Ausführungsform der erfindungsgemäßen Methode wird die Anzahl der WMS durch Zusammenlegen mehrerer WMS reduziert. Somit vermindert sich das Anforderungsver schicken noch weiter und die Kosten können weiter reduziert werden.

3. KURZE BESCHREIBUNG DER ZEICHNUNGEN

Die vorliegende Erfindung wird beispielhaft illustriert und ist nicht beschränkt durch die Form der Figuren der beglei tenden Zeichnungen; in diesen ist

Fig. 1 ein Einführungsdiagramm, das die erste Phase der Ausführung einer Aktivität in einem WMS wiedergibt, das das Erzeugen von Arbeitselementen gemäß einer herkömmlichen Technik zeigt;

Fig. 2 ist ein Einführungsdiagramm, das die zweite Phase der Ausführung einer Aktivität in einem WMS wiedergibt, und das die Ausführung einer Aktivitätsimplementierung und den Zu griff auf Systemelement/Objekte durch die Aktivitätsimplementierung gemäß einer herkömmlichen Technik zeigt;

Fig. 3 ist ein Blockdiagramm, das die wesentlichen Schritte einer bevorzugten Ausführungsform des Verfahrens gemäß der vorliegenden Erfindung zeigt;

Fig. 4 ist eine Schemaskizze der Zuordnungen zwischen ört lichen WMS und einer Vielzahl von Fern-WMS, deren jedes zugeordnete Anwender aufweist, und zwar im oberen Teil der Zeichnung vor Anwenden der erfindungsgemäßen Methode, im unteren Teil nach Anwenden der erfindungsgemäßen Methode; und

Fig. 5 ist eine Schemaskizze gemäß Fig. 4, die in einer weiteren bevorzugten Ausführungsform der vorliegenden Erfin dung das Merkmal des WMS-Zusammenlegens zeigt.

4. DETAILLIERTE BESCHREIBUNG DER ERFINDUNG 4.1 EINFÜHRUNG IN DAS ERFINDUNGSGEMÄSSE KONZEPT

Das folgende ist eine kurze Übersicht über die grundlegenden Konzepte eines Workflow Management Systems auf der Grundlage des FlowMark WMS von IBM, und führt direkt zum erfindungs gemäßen Konzept:
Vom Gesichtspunkt eines Unternehmens aus wird die Verwaltung von Geschäftsabläufen immer wichtiger: Geschäftsabläufe oder kurz ein Prozeß regeln, welcher Teil der Arbeit ausgeführt wird und von wem, und welche Systemelemente für diese Arbeit genutzt werden, d. h. ein Geschäftsablauf beschreibt, wie ein Unternehmen seine Geschäftsziele erreicht. Ein WMS kann beides unterstützen, das Modellieren von Geschäftsvorgängen und ihre Ausführung.

Das Modellieren eines Geschäftsablaufs als syntaktische Einheit auf eine Weise, die direkt von einem Softwaresystem unterstützt wird, ist extrem wünschenswert. Ferner kann das Softwaresystem auch als Interpretierer arbeiten, der ein solches Modell als Eingang bekommt: Das Modell, genannt Prozeßmodell oder Arbeitsablaufmodell, kann dann instantiiert werden und die individuelle Aufeinanderfolge von Arbeitsschritten in Abhängigkeit von dem Kontext der Instantiierung des Modells kann bestimmt werden. Ein solches Modell eines Geschäftsablaufs kann als Mustervorlage für eine Klasse ähnlicher Vorgänge betrachtet werden, die innerhalb des Unternehmens ausgeführt werden; es ist ein Schema, das alle möglichen Ausführungsvarianten einer bestimmten Art eines Geschäftsablaufs beschreibt. Eine Instanz eines solchen Modells und seine Interpretation stellt einen individuellen Prozeß dar, d. h. eine konkrete, kontextabhängige Ausführung einer Variante, die vom Modell vorgeschrieben wird. Ein WMS ermöglicht die Verwaltung von Geschäftsvorgängen. Es sieht ein Mittei vor, um Modelle der Geschäftsvorgänge zu beschreiben (Aufbauzeit) und es treibt Geschäftsvorgänge auf der Grundlage eines zugeordneten Modells an (Laufzeit). Das Metamodell des WMS FlowMark von IBM, d. i. die syntaktischen Elemente, die für die Beschreibung von Geschäftsablaufmodellen vorgesehen sind, und die Bedeutung und Interpretation dieser syntaktischen Elemente werden als nächstes beschrieben.

Ein Prozeßmodell ist eine komplette Darstellung eines Pro zesses, enthaltend ein Prozeßdiagramm und die Einstellungen, die die Logik hinter den Komponenten des Diagramms defi nieren. Durch das Anwenden verschiedener Dienste, die vom FlowMark mit diesen Aufbauzeitdefinitionen bereitgestellt werden, werden die Prozeßmodelle dann in Prozeßmustervorlagen zum Anwenden durch FlowMark in Laufzeit umgewandelt. Wichtige Komponenten eines FlowMark- Prozeßmodells sind:

- Prozesse
- Aktivitäten
- Blöcke
- Steuerflüsse
- Verbinder
- Datencontainer
- Datenstrukturen
- Bedingungen
- Programme
- Personal

Nicht alle diese Elemente werden nachstehend beschrieben.

Vor diesen Hintergrund ist ein Prozeß, der durch eine Prozeßmodellierung im FlowMark modelliert wird, eine Folge von Aktivitäten, die ausgeführt werden müssen, um den Task zu erfüllen. Der Prozeß ist das oberste Element eines FlowMark-Modells. In einem FlowMark-Prozeß kann man definieren:

- Wie die Arbeit von einer Aktivität zur nächsten fort schreiten muß
- Welche Personen die Aktivitäten ausführen müssen und welche Programme sie benutzen müssen
- Ob weitere Prozesse, genannt Unterprozesse, im Prozeß verschachtelt sind.

Natürlich können mehrfache Instanzen eines FlowMark parallel ablaufen.

Aktivitäten sind die grundlegenden Elemente des Metamodells. Eine Aktivität stellt eine Geschäftsaktion dar, die aus einer gewissen Perspektive für sich allein eine semantische Einheit ist. Mit dem Modell des Geschäftsprozesses kann sie eine Feinstruktur aufweisen, die dann ihrerseits durch ein Modell repräsentiert wird, oder ihre Einzelheiten sind vom Standpunkt einer Geschäftsablauf-Modellierung überhaupt nicht von Interesse. Die Verfeinerung der Aktivitäten über Prozeßmodelle läßt Modellieren von Geschäftsprozessen sowohl von unten nach oben als auch von oben nach unten zu. Aktivitäten, die einen Schritt in einem Prozeß ausmachen, repräsentieren ein Stück Arbeit, das die zugewiesene Person durch Anlaufenlassen eines Programms oder durch einen anderen Prozeß ausführen kann. In einem Prozeßmodell, werden die folgenden Informationen jeweils einer Aktivität zugeordnet:

- Welche Bedingungen müssen erfüllt sein, bevor die Aktivität anlaufen kann.
- Muß die Aktivität durch einen Anwender von Hand ange lassen werden oder kann sie automatisch starten.
- Welcher Zustand zeigt an, daß die Aktivität abgeschlossen ist.
- Kann die Steuerung automatisch aus der Aktivität aus steigen oder muß die Aktivität zuerst von einem Anwender als abgeschlossen bestätigt werden.
- Wie viel Zeit ist zulässig für den Abschluß der Aktivi tät.
- Wer ist verantwortlich für den Abschluß der Aktivität. Welches Programm bzw. welcher Prozeß wird zum Abschließen der Aktivität benutzt.
- Welche Daten sind zur Eingabe in die Aktivität bzw. zur Ausgabe aus derselben erforderlich.

Ein FlowMark-Prozeßmodell besteht aus den folgenden Aktivi tätstypen:
Programmaktivität: Ihr ist ein Programm zum Ausführen zuge ordnet. Das Programm wird beim Anlaufen der Aktivität auf gerufen. In einem voll automatisierten Arbeitsablauf führt das Programm die Aktivität ohne menschlichen Eingriff durch. Ansonsten muß der Anwender die Aktivität durch Auswählen derselben aus einer Laufzeit-Arbeitsliste anlaufen lassen. Der Ausgang vom Programm kann im Ausgangszustand für die Programmaktivität und für die Übergangsbedingungen zu anderen Aktivitäten benutzt werden.
Prozeßaktivität: Ihr ist ein (Unter-)Prozeß zur Ausführung zugeordnet. Der Prozeß wird aufgerufen, wenn die Aktivität anläuft. Eine Prozeßaktivität stellt einen Weg dar, einen Satz Aktivitäten, die verschiedenen Prozessen gemeinsam sind, wiederholt zu benutzen. Der Ausgang aus dem Prozeß kann in der Ausgangsbedingung für die Prozeßaktivität und für die Übergangsbedingungen zu anderen Aktivitäten benutzt werden.

Der Steuerfluß, d. h. der Steuerfluß durch einen laufenden Prozeß, bestimmt die Reihenfolge, in der Aktivitäten ausge führt werden. Der FlowMark Workflow Manager fährt einen bestimmten Pfad durch den Prozeß, der bestimmt wird durch die Bewertung der Startbedingungen, Ausgangsbedingungen und Übertragungsbedingungen als wahr.

Verbinder verbinden Aktivitäten in einem Prozeßmodell. Durch Anwenden von Verbindern definiert man die Folge von Aktivi täten und die Datenübertragung zwischen den Aktivitäten. Da Aktivitäten nicht willkürlich ausgeführt werden können, sind sie über Steuerverbinder miteinander verbunden. Ein Steuer verbinder kann als gerichteter Rand zwischen zwei Aktivitäten angesehen werden; die Aktivität am Endpunkt des Verbinders kann nicht anlaufen, bevor die Aktivität am Startpunkt des Verbinders (erfolgreich) beendet ist. Steuerverbinder modellieren somit den potentiellen Steuerfluß innerhalb eines Geschäftsablaufmodells. Vorgabeverbinder geben an, wohin die Steuerung fließen soll, wenn die Übertragungsbedingungen keines anderen Verbinders, der eine Aktivität verläßt, als wahr bewertet werden. Vorgabeverbinder setzen ein Arbeitsablaufmodell in die Lage, mit Ausnahmeereignissen fertig zu werden. Datenverbinder spezifizieren den Datenfluß in einem Arbeitsablaufmodell. Ein Datenverbinder entsteht aus einer Aktivität oder einem Block, und hat eine Aktivität oder einen Block als Ziel. Man kann vorschreiben, daß Ausgangsdaten zu einem Ziel oder zu mehreren Zielen gehen müssen. Ein Ziel kann mehr als einen Verbinder für ankommende Daten aufweisen.

Bedingungen sind die Mittel, durch die es möglich ist, den Steuerfluß in einem Prozeß zu spezifizieren. In FlowMark Prozeßmodellen können logische Ausdrücke definiert werden, die vom FlowMark bei Laufzeit bewertet werden zum Bestimmen, wann eine Aktivität anlaufen, enden und die Steuerung an die nächste Aktivität übergeben kann. Startbedingungen sind Be dingungen, die bestimmen, wann eine Aktivität mit eingehenden Steuerverbindern anlaufen kann. Die Startbedingung kann vorschreiben, daß alle eingehenden Steuerverbinder als wahr bewertet werden müssen, oder sie kann vorschreiben, daß mindestens einer von ihnen als wahr bewertet werden muß. Unabhängig von der Startbedingung müssen alle ankommenden Verbinder bewertet sein, bevor die Aktivität anlaufen kann. Wenn eine Aktivität keine eingehenden Steuerverbinder aufweist, wird sie bereit, sobald der Prozeß oder der Block, der sie beinhaltet, anläuft. Zusätzlich wird jedem Steuerverbinder ein Boolescher Ausdruck, genannt Übertragungsbedingung, zugeordnet. Parameter von Ausgangscontainern von Aktivitäten, die ihre Ergebnisse bereits erzeugt haben, werden als Parameter, auf die in Übertragungsbedingungen Bezug genommen wird, weiterverfolgt. Wenn bei Laufzeit eine Aktivität erfolgreich abschließt, werden alle Steuerver binder, die diese Aktivität verlassen, bestimmt und der Wahrheitswert der zugeordneten Übergangsbedigungen wird auf der Grundlage der wahren Werte ihrer Parameter errechnet. Nur die Endpunkte der Steuerverbinder, deren als WAHR bewertete Übergangsbedigungen als Aktivitäten betrachtet werden, gelten als Aktivitäten, die auf der Grundlage des augenblicklichen Zusammenhangs des Geschäftsprozesses ausgeführt werden können. Übergangsbedingungen modellieren so den kontextabhängigen wahren Steuerfluß innerhalb eines Geschäftsprozesses (d. i. eine Modellinstanz). Geschäftsprozesse beinhalten im allgemeinen lang laufende Aktivitäten; eine solche Aktivität muß zulässigerweise unterbrochen werden können. Somit zeigt die Beendigung einer Aktivität nicht notwendigerweise an, daß der zugeordnete Task erfolgreich abgeschlossen wurde. Um das Messen des Erfolges der von einer Aktivität ausgeführten Arbeit zu ermöglichen, wird jeder Aktivität ein Boolescher Ausdruck, genannt Ausgangsbedingung zugeordnet. Eben die Aktivitäten, deren Ausgangsbedingungen im augenblicklichen Kontext als wahr bewertet wurden, werden als erfolgreich abgeschlossen behandelt. Zur Bestimmung des aktuellen Steuerflusses werden eben die erfolgreich abgeschlossenen Aktivitäten betrachtet. Also muß der logische Ausdruck einer Ausgangsbedingung, wenn angegeben, als wahr bewertet werden, damit die Steuerung von einer Aktivität oder einem Block übergeht.

Die Prozeßdefinition beinhaltet das Modellieren von Aktivi täten, Steuerverbindern zwischen den Aktivitäten, Eingangs/ Ausgangs-Containern und Datenverbindern. Ein Prozeß wird repräsentiert als ein gerichteter azyklischer Graph mit den Aktivitäten als Knoten und den Steuer/Datenverbindern als Ränder des Graphen. Der Graph wird über einen eingebauten, ereignisgetriebenen, CUA-verträglichen Graphik-Editor behandelt. Die Datencontainer sind als benannte Daten strukturen spezifiziert. Diese Datenstrukturen selbst werden über die "DataStructureDefinition"-Einrichtung spezifiziert. FlowMark unterscheidet drei Haupttypen von Aktivitäten: Programmaktivitäten, Prozeßaktivitäten und Blöcke. Programm aktivitäten werden durch Programme implementiert. Die Pro gramme sind über die Programmdefinitionseinrichtung regi striert. Blöcke enthalten die gleichen Konstrukte wie Prozesse, wie z. B. Aktivitäten, Steuerverbinder usw. Sie sind jedoch nicht benannt und haben ihre eigene Ausgangsbedingung. Wenn die Ausgangsbedingung nicht erfüllt ist, läuft der Block wieder an. Der Block implementiert somit ein "Do Until" Konstrukt. Prozeßaktivitäten werden als Prozesse implementiert. Diese Unterprozesse werden gesondert als ein regulärer, benannter Prozeß mit allen seinen üblichen Eigenschaften definiert. Prozeßaktivitäten bieten eine große Flexibilität für die Prozeßdefinition. Diese erlaubt nicht nur den Aufbau eines Prozesses durch eine permanente Verfeinerung der Aktivitäten in Programme und Prozeßaktivitäten (von oben nach unten), sondern auch den Aufbau eines Prozesses außerhalb eines Satzes existierender Prozesse (von unten nach oben). Insbesondere helfen Prozeßaktivitäten, die Modellierarbeit zu organisieren, wenn mehrere Prozeßmodellierer zusammenarbeiten. Das erlaubt den Team-Mitgliedern unabhängig an unterschiedlichen Aktivitäten zu arbeiten. Programm- und Prozeßaktivitäten können mit einer Frist einander zugeordnet werden. Die Frist spezifiziert, wie lange die Aktivität dauern darf. Wenn die Frist überschritten wird, wird eine bestimmte Person unterrichtet. Wenn diese Person nicht innerhalb einer weiteren Frist reagiert, wird der Prozeßadministrator unterrichtet. Das hilft nicht nur, eine kritische Situation zu erkennen, sondern auch, Prozeßfehler zu entdecken, weil alle Meldungen in einem Prüfpfad verzeichnet werden.

Alle Datenstrukturen, die als Mustervorlagen für die Contai ner der Aktivitäten und Prozesse benutzt werden, werden über die Datenstrukturdefinitionsvorrichtung definiert. Daten strukturen sind Namen und werden als Elementardatentypen wie Gleitkomma, Ganzzahl oder Zeichenfolge und Bezugnahme auf existierende Datenstrukturen definiert. Das Verwalten von Datenstrukturen als gesonderte Einheiten hat den Vorteil, daß alle Schnittstellen von Aktivitäten und ihrer Implementierungen konsistent an einem Ort verwaltet werden (ähnlich der Kopfdateien in Programmiersprachen).

Alle Programme, die Programmaktivitäten implementieren, sind über die Programmregistrierungsvorrichtung definiert. Regi striert für jedes Programm ist der Name des Programms, sein Ort, und die Aufrufzeichenfolge. Die Aufrufzeichenfolge besteht aus dem Programmnamen und der Befehlszeichenfolge, die für das Programm vergeben wurde.

Bevor Prozeßinstanzen geschaffen werden können, muß das Prozeßmodell übersetzt werden, um die Richtigkeit und Voll ständigkeit des Prozeßmodells sicherzustellen. Die übersetzte Version des Modells wird beim Schaffen einer Prozeßinstanz als Mustervorlage benutzt. Das ermöglicht das Einfügen von Änderungen in das Prozeßmodell ohne ausführende Prozeßinstanzen zu beeinflussen. Eine Prozeßinstanz wird gestartet entweder über die graphische Schnittstelle oder die abrufbare Prozeßapplikationsprogrammierschnittstelle. Wenn ein Prozeß gestartet wird, werden die Startaktivitäten lokalisiert, die richtigen Leute werden bestimmt und die Aktivitäten werden als Arbeitselemente auf die Arbeitsliste der ausgewählten Leute gesetzt. Wenn ein Anwender das Arbeitselement, d. i. die Aktivität, anwählt, wird die Aktivität ausgeführt und von der Arbeitsliste jedes anderen Anwenders gestrichen, auf die die Aktivität gesetzt worden war. Nach Ausführen einer Aktivität wird ihre Ausstiegsbedingung bewertet. Wenn sie nicht erfüllt ist, wird die Aktivität erneut zur Ausführung auf den Plan gesetzt, anderenfalls werden alle ausgehenden Steuerverbinder und die zugehörigen Übergangsbedingungen bewertet. Ein Steuerverbinder wird gewählt, wenn die Bedingung mit WAHR beurteilt wird. Dann werden die Zielaktivitäten des ausgewählten Steuerverbinders bewertet. Wenn ihre Startbedingungen WAHR sind, werden sie auf die Arbeitsliste von ausgewählten Leuten gesetzt. Ein Prozeß gilt als beendet, wenn alle Endaktivitäten abgeschlossen sind. Um sicherzustellen, daß alle Endaktivitäten abgeschlossen sind, wird ein Totpfadausschluß durchgeführt.

Dieser beseitigt alle Ränder im Prozeßgraph, die wegen der gestörten Übergangsbedingungen nie erreicht werden können. Jede Information über den augenblicklichen Zustand eines Prozesses wird in der Datenbank gespeichert, die vom Server unterhalten wird. Das ermöglicht eine Vorwärtswiederherstellung bei Abstürzen.

Wie oben bereits angegeben, unterstützen die WMS die Defini tion und Ausführung von Geschäftsprozessen. Diese Geschäfts prozesse bestehen aus einem Satz Aktivitäten, die von ver schiedenen Leuten an verschiedenen Stellen ausgeführt werden; Geschäftsprozesse werden daher in den meisten Fällen in einer verteilten Umgebung bearbeitet, die ein Netzwerk einer Vielzahl von Rechnersystemen beinhaltet. Die Aktivitäten werden im allgemeinen über Programme implementiert, die der Anwender im Dialogverfahren benutzt und die die dem Prozeß zugeordneten Daten verwalten. Ein Anwender setzt sich in der Regel über einen graphischen Endanwender in Verbindung mit dem Workflow Management System, der die durch den Anwender auszuführenden Tasks als Icons darstellt. Die Arbeit für einen bestimmten Task läßt ein Anwender durch Doppelklicken auf das entsprechende Icon anlaufen, das seinerseits das Programm startet, das die Aktivität implementiert.

Die Ausführung einer Aktivität innerhalb eines Prozesses wird in zwei Phasen ausgeführt, die in Fig. 1 und Fig. 2 veranschaulicht sind. Fig. 1 zeigt die erste Phase, in der die Personalaufteilung ausgeführt wird. Wenn ein Prozeß definiert ist, wird jeder Aktivität ein Ausdruck zugeordnet (Personalzuordnung), der beschreibt, wer die Aktivität ausführen soll. Die Personalzuordnung wird ausgedrückt als Abfrage an die Organisationsdatenbank, die Teil des Workflow Management System ist. Wenn sich das Workflow Management System auf eine Aktivität zu bewegt, benutzt es diese Abfrage, um die Leute zu finden, die die Aktivität ausführen sollen (Personalaufteilung). Für jede ausgewählte Person wird ein Arbeitselement 101, 102, 103 geschaffen. In Abhängigkeit von einigen Einstellungen wird das Arbeitselement unverzüglich auf die Arbeitsliste 104, 105 einer gewählten Person gesetzt oder wird Teil der Arbeitsliste des Anwenders als Ergebnis einer ausdrücklichen Anfrage.

Fig. 2 zeigt den Steuerungsablauf, wenn der Anwender ein Arbeitselement aus der Arbeitsliste anlaufen läßt, die die zweite Phase der Ausführung einer Aktivität darstellt. Nach Doppelklick auf das Arbeitselement, das die Ausführungs anforderung der Aktivität auf der Arbeitsliste 201 darstellt, materialisiert das Workflow Management System den Eingabecontainer 202 und/oder den Ausgabecontainer 203 und aktiviert das Programm 205, das die Aktivität 204 implementiert. Das ausgeführte Programm bestimmt in der Regel seinen Kontext durch Bilden einiger oder aller Felder im Eingabecontainer, tritt mit dem Anwender in Dialog oder modifiziert einige Betriebsmittel/Objekte 206, oder kurz ausgedrückt Daten, modifiziert den Kontext durch Speichern dieser Informationen im Ausgabecontainer, und endet dann. Das ist der Abschluß der Aktivität, und der Durchlauf durch den Prozeßgraphen wird fortgesetzt.

Bei näherer Betrachtung von Aspekten, die näher am Brennpunkt der vorliegenden Erfindung liegen, kann das Workflow Management, wie es z. B. vom IBM FlowMark implementiert wird, so betrachtet werden, daß es drei Dimensionen aufweist.

Die erste Dimension, die Prozeßlogikdimension, beschreibt die auszuführenden Aktionen, von wem sie auszuführen sind, mit welchem Programm sie auszuführen sind, und in welcher Reihenfolge sie auszuführen sind.

Die zweite Dimension beschreibt die organisatorische Struk tur, die Leute und die Rollen, die diese Leute spielen.

Die dritte Dimension beschreibt die IT-Infrastruktur, wie die Arbeitsablaufserver und die von den Anwendern benutzten Workstationen/Programme.

Die wahre Ausführung eines Arbeitsablaufs ist dann eine Reihe von Punkten im dreidimensionalen Arbeitsablaufraum. Jeder Punkt stellt die Ausführung einer Aktivität durch eine Person mit einem Rechner unter Verwendung eines bestimmten Programms dar.

Jeder Anwender, der an einem solchen Arbeitsablauf beteiligt ist, wird einem WMS zugewiesen. Dieses WMS wickelt alle Dialogprozesse mit dem Anwender ab. Als solches ist es auch verantwortlich für die Verwaltung der Bearbeitung einer Aktivität, die vom Anwender ausgeführt werden muß. Es hat seine eigene Datenbank, die alle ausführungsrelevanten Informationen zur Unterstützung der Ausführung eines Arbeitsablaufs enthält. Hier muß darauf hingewiesen werden, daß die WMS, die sich in die gleiche physikalische Datenbank teilen, im Wortlaut der Anwendung der vorliegenden Erfindung nicht als unterschiedliche WMS betrachtet werden.

Wenn sich zwei WMS in die Ausführung eines Arbeitsablaufes teilen, dann bearbeitet jedes WMS bestimmte Aktivitäten im Arbeitsablauf. Welche Aktivitäten überhaupt ausgeführt werden, hängt ab vom Kontext, in dem der Arbeitsablauf aus geführt wird. Beim IBM FlowMark z. B. hängt es ab vom Wert der Felder im Eingabe- und Ausgabecontainer des Prozeßmodells oder von den einzelnen Aktivitäten und ihrer Anwendung unter Übergangsbedingungen, die den Steuerverbindern zugewiesen sind.

Welches der WMS verantwortlich ist für die Bearbeitung einer bestimmten Aktivität hängt vom Anwender ab, der der bestimm ten Aktivität zugewiesen ist. Der Anwender wird üblicherweise durch Durchführen der Personalaufteilung ausgewählt. Bei der Personalaufteilung wird jede Aktivität im Prozeß einem oder mehreren Personalangehörigen zugewiesen, die in der FlowMark-Datenbank definiert sind. Ob eine Aktivität manuell vom Anwender oder vom FlowMark- Arbeitsablaufmanager automatisch gestartet wird, und ob es zum Abschluß der Arbeiten des Eingriffs eines Anwenders bedarf oder diese automatisch abgeschlossen wird, es muß immer ein Personalmitglied zugewiesen sein. Für jede definierte Person können eine Ebene und eine Organisation und Vielfachrollen vorgegeben werden. Diese Attribute können bei Laufzeit des WMS benutzt werden, um Aktivitäten bestimmten Leuten mit geeigneten Attributen dynamisch zuzuteilen.

Diese gemeinsame Ausführung eines Arbeitsablaufs durch Mehr fach-WMS ist typisch für Arbeitsabläufe, die in einer Firma ablaufen. Sie setzt voraus, daß alle teilnehmenden WMS über die gleichen Informationen, wie das zugrundeliegende Arbeitsablaufmodell, die organisatorischen Informationen, und das auszuführende Programm verfügen.

Das geschieht üblicherweise durch Weitergeben der geeigneten Informationen von einem WMS, das als primäres System bestimmt ist, an die anderen WMS.

Begrifflich bilden alle beteiligten WMS ein einziges WMS. In den meisten Fällen sind die unterschiedlichen WMS einfach unterschiedliche Instanzen des gleichen WMS. Die Forderung nach mehrfachen Instanzen eines einzigen WMS ist üblicher weise vorgegeben von der verteilten Natur der Rechnerbe triebsmittel.

Die Verarbeitung von unterschiedlichen Aktivitäten innerhalb eines Arbeitsablaufs durch verschiedene WMS setzt eine Wechselwirkung zwischen den betroffenen WMS voraus. Die erforderlichen Wechselwirkungen können in einer großen Mannigfaltigkeit unterschiedlicher Wechselwirkungsprotokolle implementiert werden.

Die beispielhafte Anordnung und Beziehungen zwischen den hier beschriebenen WMS dient nur der Illustration; wirkliche Implementierungen können viel weiter entwickelt sein.

4.2 DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGS FORMEN

Unter allgemeiner Bezugnahme auf die Figuren, und spezifisch anhand der Fig. 3 und 4, wird eine bevorzugte Ausführungsform des Verfahrens laut der vorliegenden Erfindung beschrieben.

In einem ersten Block 110 werden die Sendeanforderungs optimierungsdaten für den Geschäftsablauf erfaßt. Im allge meinen werden alle relevanten statistischen Daten betreffend Aktivitäten, einschließlich Wahrscheinlichkeiten, erfaßt, z. B. daß ein bestimmter Zweig in den Arbeitsablauf aufge nommen wird. Ferner werden nichtstatistische Daten betreffend die Hardwarekosten, Bandbreitenkosten, Wartungskosten, wie oben erwähnt, erfaßt.

Insbesondere wird die Anzahl der Aktivitäten, die für den betreffenden Prozeß ausgeführt werden, in einem Schritt 112 bestimmt.

In einem weiteren Schritt 113 ergibt die Ausführung der Personalaufteilung für jede der Aktivitäten die Anwender gruppe, die während der Ausführung des Prozesses Arbeits elemente erhalten. In Fig. 4 (und Fig. 5, wie später erklärt wird), sind die Arbeitselemente als ovale Symbole darge stellt. In Fig. 4 und 5 wird ein "Schnappschuß" einer Aktivität mit den zugeordneten Prozessen zum Verschicken der Anforderungen dargestellt.

In einem nächsten Schritt 114 wird für jeden der Anwender 1 bis 6 das zugeordnete WMS bestimmt. Im vorliegenden Fall wird für die Anwender 1 und 2 das WMS 1, für die Anwender 3 und 4 das WMS 2, und für die Anwender 5 und 6 das WMS 3 bestimmt.

Dann wird in einem Schritt 115 die Anzahl der Fernarbeits elementanforderungen bestimmt, und weiter, für welche Aktivitäten sie erforderlich sind. Diese Fernarbeitselement anforderungen sind in den Zeichnungen als kleine Rechtecke dargestellt.

Dann wird in Schritt 120 eine Optimierungsfunktion angewandt. Diese Funktion ist spezifisch für jedes Unternehmen und deckt alle relevanten Fakten für die Dienstleistungsqualität ab. Alle Daten und alle Parameter, die oben im zusammenfassenden Kapitel angeführt wurden, können in Betracht gezogen werden, sowie auch noch andere, die nicht ausdrücklich genannt wurden. Dann werden alle Daten gewichtet zum Festlegen ihrer individuellen Relevanz in bezug auf das allgemeine Optimierungsergebnis, das der Funktion entnommen werden soll. Als Alternative kann auch eine bereits existente Optimierungsfunktion angewandt werden.

Erfindungsgemäß wird diese Funktion berechnet und ergibt ein Kostenminimum der Optimierungsfunktion mit einer entsprechenden möglichen neuen Anwenderverteilung über die WMS im System. Das wird dargestellt im unteren Teil der Fig. 4, in der die Anwender 1 und 4 dem Fern-WMS 1, die Anwender 2 und 3 dem Fern-WMS 2, und die Anwender 5 und 6 weiterhin dem Fern-WMS zugeordnet werden. Damit werden die Anwender in Schritt 130 ihren WMS gemäß dem optimalen Ergebnis neu zugeordnet, wie in Fig. 3 im Zweig unten links dargestellt wird.

Nehmen wir jetzt Bezug auf Fig. 5 und Fig. 3; hier wird eine weitere bevorzugte Ausführungsform der erfindungsgemäßen Methode beschrieben, in der eine Einschränkung im Vergleich zur Grund-Optimierungsfunktion nach obiger Beschreibung aufgehoben wird, wodurch die Optimierungsfunktion in Schritt 140 mehrere Workflow-Management-Systeme zu einem einzigen Workflow-Management-System zusammenlegen kann. Das kann geschehen, nachdem - siehe Fig. 3 unten rechts - oder bevor die oben beschriebenen Schritte ausgeführt wurden/werden. Wie in Fig. 5 dargestellt ist, werden als entsprechendes Optimierungsergebnis die Anwender 1 bis 4 dem sich ergebenden zusammengelegten WMScom zugeordnet während die Anwender 5 und 6 verbleiben wie vorher.

Somit reduziert sich die Anzahl der verschiedenen WMS, was automatisch das Verschicken von Fernarbeitselementanforde rungen minimiert.

Schließlich kann Schritt 140 zum Zusammenlegen mehrerer WMS zu einem WMS ausgeführt werden, auch ohne den Schritt der Neuzuweisung der Anwender. Das wird dargestellt im Zweig unten Mitte in Fig. 3 für eine Situation, in der die Opti mierungsfunktion bereits angewandt wurde. Trotzdem kann auch Schritt 140 angewandt werden, ohne Block 110 und Schritt 120 aus Fig. 3 durchlaufen zu müssen.

Im allgemeinen sind zum Erfassen der Optimierungsdaten als Elemente der Optimierungsfunktion, wie in Block 110 be schrieben wird, verschiedene Alternativen möglich.

Zum Bestimmen der Anzahl Aktivitäten kann eine analytische und diskrete Simulation angewandt werden, die für jeden der betroffenen Prozesse ausgeführt wird. Hier wird darauf hin gewiesen, daß die Zahlen, die von der Simulation betroffen sind, wie z. B. Wahrscheinlichkeiten, daß ein bestimmter Zweig im Prozeß eingeschlagen wird, durch Analyse des Prüfpfads später nachgeprüft werden können.

Ebensogut kann der Prüfpfad der örtlichen WMS als Datenquelle genommen werden, weil alle relevanten statistischen Daten aus diesem erhältlich sind, wenn die Beobachtungszeit lang genug ist.

Die oben beschriebene Methode kann vorteilhaft in einem Arbeitsablaufoptimierungswerkzeug implementiert werden, das sich auf bereits verteilte Anwendungen anwenden läßt. Sogar eine Art Anwenderausgang, der als Zusatz zu jeder der betroffenen Aktivitäten programmiert ist, kann auch zum Generieren der Optimierungsdaten hergenommen werden. Auch diese Methode kann während der Entwicklung des Geschäfts modells für eine künftige Anwendung angewandt werden. Dann werden die Eingangsdaten durch Simulation erzeugt.

In der obigen Beschreibung wurde die Erfindung unter Bezug nahme auf eine spezifische beispielhafte Ausführungsform beschrieben. Es ist jedoch offensichtlich, daß verschiedene Modifikationen und Änderungen vorgenommen werden können, ohne von Umfang und Wesensart der Erfindung abzuweichen, die in den anhängigen Ansprüchen dargelegt sind. Die Beschreibung und die Zeichnungen sind daher illustrativ und nicht im einschränkenden Sinn zu verstehen.

BEZUGSZEICHENLISTE

101, 102, 103

Arbeitselemente

104, 105

Arbeitslisten

201

Arbeitsliste

202

Eingabe-Container

203

Ausgabe-Container

204

Aktivität

205

Programm

206

Systemelemente/Objekte

110

bis

140

Schritte des erfindungsgemäßen Verfahrens

Claims

1. Ein Verfahren zum Optimieren des Anforderungsschickens innerhalb einer Vielzahl von verteilten, vernetzten Rechnersystemen einschließlich einer verteilten Anwen dung, deren Benutzung ein Prozeßmodell realisiert, das der genannten Applikation zugrunde liegt,
wobei das Prozeßmodell einen Geschäftsablauf beinhaltet,
der aus einer Vielzahl von Aktivitäten besteht, die in den Applikationssystemen durch eine Vielzahl von Anwen dern ausgeführt werden müssen, und
der das Schicken von Aktivitätsanforderungen zwischen einem örtlichen Applikationssystem, dem der Geschäfts ablauf zugeeignet ist, und einer Vielzahl von Fern applikationssystemen, die diese Aktivitäten ausführen, bewirkt,
wobei das Verfahren die folgenden Schritte beinhaltet:
Erfassen (110) von Optimierungsdaten für das Schicken der Applikationen,
Anwenden (120) einer Gesamtoptimierungsfunktion ein schließlich dieser Optimierungsdaten, und
Neuzuweisen (130) von Anwendern zu einem anderen Applikationssystem, so daß das Anforderungsschicken optimiert wird.

2. Das Verfahren gemäß Anspruch 1, dadurch gekennzeichnet, daß die verteilte Applikation ein Workflow Management System (WMS) ist,
der Schritt des Erfassens (110) von Optimierungsdaten für das Anforderungsschicken die Anwenderverteilung über das WMS reflektiert, und
Anwender einem anderen WMS neu zugewiesen (130) werden, so daß das Anforderungsschicken optimiert wird.

3. Das Verfahren gemäß Anspruch 2, wobei der Schritt des Erfassens (110) der Optimierungsdaten für das Anforde rungsschicken umfaßt:
Bestimmen (112) der Anzahl der Aktivitäten, die für den betroffenen Geschäftsablauf ausgeführt werden,
Bestimmen (113) der Gruppe der Anwender, die während der Ausführung des Geschäftsprozesses Arbeitselemente erhalten,
Bestimmen (114) der Anzahl der zugeordneten WMS, die Fernarbeitselemente erhalten,
Bestimmen (115), für welche Aktivitäten Fernarbeits elemente generiert werden.

4. Das Verfahren gemäß Anspruch 2, wobei der Schritt des Erfassens (110) der Optimierungsdaten für das Anforde rungsschicken umfaßt
das Benutzen einer analytischen und/oder diskreten Simulation zum Bestimmen von Optimierungsdaten.

5. Das Verfahren gemäß Anspruch 2, wobei der Schritt des Erfassens (110) der Optimierungsdaten für das Anforde rungsschicken umfaßt
das Anwenden von Prüfpfadinformationen zum Bestimmen der Optimierungsdaten.

6. Das Verfahren gemäß einem beliebigen der vorstehenden Ansprüche, das ferner die folgenden Schritte beinhaltet:
Reduzierung der Anzahl der Applikationssysteme durch Zusammenlegen verschiedener Applikationssysteme.

7. Ein Workflow Management System, in dem das Verfahren gemäß einem der vorstehenden Ansprüche angewandt wird.

8. Ein Arbeitsablaufoptimierungswerkzeug, das ein Rechner programm zum Implementieren des Verfahrens gemäß einem der vorstehenden Ansprüche 1 bis 6 enthält.

9. Ein Anwenderausgang (User Exit) zum Ankoppeln an ein WMS, enthaltend ein Rechnerprogramm, das wenigstens einen der Optimierungserfassungsschritte gemäß Anspruch 3 oder 5 implementiert.

10. Ein auf einem Datenträger abgespeichertes Programm, das das Verfahren gemäß den Ansprüchen 1 bis 6 implementiert, wenn es in eine Rechnervorrichtung eingelesen wird.