DE19612688A1 - Verfahren und Vorrichtung zur dynamischen Anpassung von Computer-gesteuerten Geschäftsprozessen - Google Patents

Verfahren und Vorrichtung zur dynamischen Anpassung von Computer-gesteuerten Geschäftsprozessen

Info

Publication number
DE19612688A1
DE19612688A1 DE1996112688 DE19612688A DE19612688A1 DE 19612688 A1 DE19612688 A1 DE 19612688A1 DE 1996112688 DE1996112688 DE 1996112688 DE 19612688 A DE19612688 A DE 19612688A DE 19612688 A1 DE19612688 A1 DE 19612688A1
Authority
DE
Germany
Prior art keywords
process model
version
model version
events
versions
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE1996112688
Other languages
English (en)
Inventor
Kurt Dr Bandat
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to DE1996112688 priority Critical patent/DE19612688A1/de
Publication of DE19612688A1 publication Critical patent/DE19612688A1/de
Ceased legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur dynamischen Anpassung eines Geschäftsprozesses, bei dem der Geschäftsprozeß mittels mindestens einem Prozeßmodell als eine Abfolge von Ereignissen darstellbar ist, mindestens zwei voneinander verschiedene Versionen des Prozeßmodells existieren, die sich in einem oder mehreren Ereignissen, deren Abfolge oder der Abfolge gleicher Ereignisse unterscheiden, und die als eine erste und eine zweite Prozeßmodell-Version darstellbar sind, wobei der Geschäftsprozeß auf der Basis der Prozeßmodell-Versionen durch digitale Daten in einem Workflow-Management-Computersystem repräsentiert wird, und der Geschäftsprozeß durch das Computersystem gemanagt wird.
Kooperative Geschäftsprozesse sind Kern der Arbeitsorganisationen von Unternehmen in Wirtschaft und öffentlicher Verwaltung. Zur Unterstützung der Abarbeitung kooperativer Geschäftsprozesse werden Workflow-Systeme benutzt. Mittels dieser Workflow-Systeme werden die Geschäftsprozesse durch digitale Daten in einem Workflow-Management-Computersystem, welches die Geschäftsprozesse managt, repräsentiert.
In I. Damschik und I. Häntschel: "Evaluierung von Workflow-Systemen", Wirtschaftsinformatik, 37, 1995, Seite 18-23, werden verschiedene Workflow-Systeme in einem Laborversuch auf der Basis eines Bewertungsmodells untersucht. Als ein wichtiges Kriterium zur Bewertung verschiedener Workflow-Systeme werden Formalziele, wie Produktivität und Flexibilität eines Workflow-Systems definiert. Um die Flexibilität eines Workflow-Systems meßbar zu machen, werden die Teilkriterien Änderbarkeit, Anpassungsfähigkeit und Erweiterbarkeit eingeführt.
Die besondere Bedeutung der Flexibilität eines Workflow-Systems und ihrer Teilkriterien ergibt sich aus der Tatsache, daß Geschäftsprozesse Veränderungen unterworfen sind, wenn sie über längere Zeiträume (Monate, Jahre) ablaufen. So werden Geschäftsprozesse durch die Reorganisation eines Unternehmens in ihrem Ablauf beeinflußt. Die Reorganisation wird im allgemeinen durchgeführt, um verschiedene Ressourcen-Parameter des Geschäftsprozesses bezüglich des Geschäftszieles zu optimieren, wobei unter Ressourcen Maschinen, Menschen, Computerprogramme usw. alle Teilnehmer zu verstehen sind, die an dem Ablauf des Geschäftsprozesses beteiligt sind.
In Mehandjiev et. al: "User enhancability for fast response to changing office needs", Proceedings of the 27th Hawaii International Conference on System Sciences, Vol. IV, Information Systems: Collaboration Technology Organizational Systems and Technology, Seite 673-683, wird ein Workflow-System auf der Basis einer visuell orientierten Programmiersprache vorgestellt. Ein mittels dieser Programmiersprache erstelltes Workflow-System erlaubt die benutzerfreundliche Anpassung des Workflow-Systems an veränderte Parameter des Geschäftsprozesses. Hierbei können einzelne Ereignisse des Ablaufes des Geschäftsprozesses und/oder Verbindungen zwischen den Ereignissen an neue Gegebenheiten angepaßt werden. Es ist hierdurch möglich, den Geschäftsprozeß mittels verschiedener Prozeßmodell-Versionen durch digitale Daten in einem Workflow-Management-Computersystem zu repräsentieren.
Der Nachteil des bekannten Workflow-Systems besteht darin, daß bei dem Wechsel von einer Prozeßmodell-Version auf eine andere Prozeßmodell-Version der Geschäftsprozeß stets von neuem begonnen werden muß. Die Kontinuität des Geschäftsprozesses ist hierdurch entscheidend gestört. Das ist ein besonderer Nachteil, wenn der Geschäftsprozeß zum Zeitpunkt der Veränderung der Prozeßmodell-Version seit einem längeren Zeitraum abläuft.
Der Erfindung liegt deshalb die Aufgabe zugrunde, ein Verfahren und eine Vorrichtung für ein von einem Computersystem gemanagten Geschäftsprozeß zu erstellen, welche einerseits eine flexible Anpassung eines Workflow-Systems an veränderbare Parameter des Geschäftsprozesses ermöglichen und andererseits die Kontinuität des Geschäftsprozesses unterstützen.
Diese Aufgabe wird erfindungsgemäß dadurch gelöst, daß nach einem Beginn des Geschäftsprozesses mindestens einmal ein Umschalten von der ersten auf die zweite Prozeßmodell-Version oder umgekehrt im Workflow-Management-Computersystem stattfindet, ohne den Geschäftsprozeß neu zu starten.
Der wesentliche Vorteil, welcher mit der Erfindung gegenüber dem Stand der Technik erreicht wird, besteht in der Möglichkeit, während des Ablaufes des Geschäftsprozesses zwischen verschiedenen Prozeßmodell-Versionen, auf deren Basis der Geschäftsprozeß in dem Workflow-Management-Computersystem gemanagt wird, umschalten zu können. Es kann hierdurch in flexibler Weise auf dynamische Veränderungen des Geschäftsprozesses reagiert werden. Auch ein mehrmaliges Umschalten zwischen Prozeßmodell-Versionen ist möglich, ohne die Kontinuität des Ablaufes des Geschäftsprozesses zu stören. Bei Geschäftsprozessen, die über mehrere Jahre ablaufen, ist eine Anpassung an geänderte Regeln, Standards, Gesetze oder Normen möglich.
Ein weiterer wesentlicher Vorteil des erfindungsgemäßen Verfahrens und der erfindungsgemäßen Vorrichtung ist, daß eine nach dem Beginn des Geschäftsprozesses erstellte zusätzliche erweiterte oder angepaßte Prozeßmodell-Version zu jedem Zeitpunkt des Ablaufes des Geschäftsprozesses und ohne Unterbrechung oder Abbruch des Geschäftsprozesses als die dem Management des Geschäftsprozesses durch das Workflow-Management-Computersystem zugrunde liegende Prozeßmodell-Version einführbar ist. Dies erlaubt es, auf eintretende Veränderung von Ressourcen-Parameter während des Ablaufes des Geschäftsprozesses in kurzer Zeit zu reagieren. Solche Ressourcen-Parameter können die einzuhaltenden gesetzlichen Regeln, auch in Abhängigkeit vom jeweiligen Datum, geänderte Strategien des Unternehmens oder neue Erkenntnisse über vorteilhafte Ausprägungen des Geschäftsprozesses sein. Handelt es sich bei dem Geschäftsprozeß beispielsweise um den Produktionsprozeß eines Personenkraftwagens, so kann mittels ähnlicher Prozeßmodell-Versionen für den Bau verschiedener Automodelle eine Produktionsstraße zu einem bestimmten Zeitpunkt so umgestellt werden, daß bei sonst weitgehend gleichem und weiter fortlaufendem Geschäftsprozeß ein Umschalten zwischen zwei Prozeßmodell-Versionen stattfindet. Würde ein Umschalten des Prozesses nicht dynamisch erfolgen können, so hätte das zur Folge, daß die Produktion des alten Automodells erst auslaufen müßte, bevor mit der Produktion des neuen Automodells begonnen werden kann.
Bei einer vorteilhaften Ausführung der Erfindung kann vor dem Beginn des Umschaltens zwischen den beiden Prozeßmodell-Versionen, eine Definition der ersten und der zweiten Prozeßmodell-Version durchgeführt werden, wobei beide Prozeßmodell-Versionen mit einem Versionen-Namen benannt werden und die Versionen-Namen in einen Versionen-Katalog eingetragen werden. Die Benennung der Prozeßmodell-Versionen mit Versionen-Namen und die Eintragung der Versionen-Namen hat den Vorteil, daß der Umschaltprozeß zwischen verschiedenen Prozeßmodell-Versionen besonders einfach gestaltet werden kann, da eine Rückbeziehung auf die in dem Versionen-Katalog eingetragenen Versionen-Namen möglich ist. Des weiteren ist die Auswertung und Dokumentation bestehender Prozeßmodell-Versionen mittels der Versionen-Namen im Versionen-Katalog optimierbar.
Bei einer zweckmäßigen Ausführung der Erfindung werden in den Versionen-Katalog alle vor Beginn eines Ablaufes des Geschäftsprozesses und während des Ablaufes des Geschäftsprozesses definierten Prozeßmodell-Versionen in einer geordneten Reihenfolge eingetragen, wodurch die Eintragung und die Abfrage der Eintragungen im Versionen-Katalog entsprechend der logischen und zeitlichen Abfolge der Prozeßanpassungen mittels Erstellung neuer Prozeßmodell-Versionen ermöglicht ist.
Vorteilhaft kann vorgesehen sein, daß die erste und die zweite Prozeßmodell-Version im Anschluß an ihre Definition editierbar sind und das nach dem Abschluß eines Editiervorganges einer der Prozeßmodell-Versionen die innere Konsistenz derselben Prozeßmodell-Version überprüft wird.
Mittels Editieren können Veränderungen an einer Prozeßmodell-Version vorgenommen werden, ohne eine neue Prozeßmodell-Version definieren zu müssen.
Die Konsistenzprüfung gewährleistet, daß auch in der nach dem Editieren gültigen Prozeßmodell-Version die Kontinuität der Abarbeitung der Ereignisse der Prozeßmodell-Version erfüllt ist.
Eine vorteilhafte Weiterbildung der Erfindung kann sein, daß eine Abarbeitung von Ereignissen einer Prozeßmodell-Version beginnt, während ein späteres Ereignis und/oder eine Abfolge späterer Ereignisse derselben Prozeßmodell-Version editiert werden, spätere Ereignis und/oder die Abfolge späterer Ereignisse mittels einer vorzugsweise verschiebbaren Ausführungsgrenze von den Ereignissen getrennt sind und das Editieren des späteren Ereignisses und/oder der Abfolge späterer Ereignisse zu einem Zeitpunkt abgeschlossen sein muß, zu dem die Abarbeitung des späteren Ereignisses und/oder der Abfolge späterer Ereignisse begonnen wird.
Hierdurch kann die Abarbeitung der Ereignisse beginnen bevor genau feststeht, wie die späteren Ereignisse der Prozeßmodell-Version gestaltet werden müssen. Der genaue Inhalt von späteren Ereignissen ist insbesondere bei langjährigen Geschäftsprozessen nicht am Beginn des Geschäftsprozesses absehbar.
Eine zweckmäßige Ausführung der Erfindung sieht vor, daß ein Prozeß-Interpreter fortlaufend die Ereignisse ermittelt und speichert, welche zu einem bestimmten Zeitpunkt des Geschäftsprozesses ablaufen, hierbei insbesondere den Elemente-Namen und den Versionen-Namen der Prozeßmodell-Version ermittelt und speichert, die während des Ablaufes des jeweiligen Ereignisses den Geschäftsprozeß managt. Die Informationen welche Ereignisse zu einem bestimmten Zeitpunkt abgearbeitet werden, sind für eine Echtzeitdokumentation und eine spätere Verifizierung des Ablaufes des Geschäftsprozesses vorteilhaft nutzbar.
Bei einer weiteren vorteilhaften Ausgestaltung der Erfindung kann vorgesehen sein, daß vor dem Beginn des Umschaltens zwischen der ersten und der zweiten Prozeßmodell-Version, ein Vergleich zwischen der ersten und der zweiten Prozeßmodell-Version durchgeführt wird, um in der ersten und der zweiten Prozeßmodell-Version jeweils mindestens einen neuen abgeschlossenen Bereich und mindestens einen alten abgeschlossenen Bereich zu unterscheiden, wobei der alte abgeschlossene Bereich der ersten Prozeßmodell-Version und der alte abgeschlossene Bereich der zweiten Prozeßmodell-Version ein Ereignis oder eine Abfolge von Ereignissen des Geschäftsprozesses umfassen, die in beiden Prozeßmodell-Versionen identisch ablaufen, und der neue abgeschlossene Bereich der ersten Prozeßmodell-Version und der neue abgeschlossene Bereich der zweiten Prozeßmodell-Version ein Ereignis oder eine Abfolge von Ereignissen des Geschäftsprozesses umfassen, die sich in beiden Prozeßmodell-Versionen unterscheiden.
Mit Hilfe des Vergleiches der beiden Prozeßmodell-Versionen kann der Umschaltprozeß auf effiziente Weise vorbereitet werden. Die Kenntnis der neuen und alten abgeschlossenen Bereiche ist eine besonders wichtige Voraussetzung, um ein fehlerfreies Umschalten zwischen den Prozeßmodell-Versionen zu erreichen.
Bei einer vorteilhaften Ausgestaltung der Erfindung kann vorgesehen sein, daß ein Umschalten von der ersten Prozeßmodell-Version auf die zweite Prozeßmodell-Version nur zu einem Zeitpunkt des Ablaufes des Geschäftsprozesses durchführbar ist, zu dem ein Ereignis abläuft, welches sich in dem alten abgeschlossenen Bereich der ersten Prozeßmodell-Version befindet, wodurch verhindert wird, daß im Anschluß an das Umschalten in die zweite Prozeßmodell-Version Ereignisse bearbeitet werden müssen, die in keinem koordinierten Zusammenhang zu Ereignissen stehen, die unmittelbar vor dem Umschalten in der ersten Prozeßmodell-Version bearbeitet wurden.
Vorteilhaft kann vorgesehen sein, daß die Definition der ersten Prozeßmodell-Version vor dem Beginn des Ablaufes des Geschäftsprozesses und die Definition der zweiten Prozeßmodell-Version nach dem Beginn des Ablaufes des Geschäftsprozesses durchgeführt werden. Anforderungen an eine zweite Prozeßmodell-Version, die am Beginn des Geschäftsprozesses noch nicht bekannt sind, können so bei der Definition und Konfigurierung der zweiten Prozeßmodell-Version berücksichtigt werden. Weiterhin können Fehlerquellen, die erkennbar sind, während der Geschäftsprozeß auf der Basis der ersten Prozeßmodell-Version gemanagt wird, bei der Definition der zweiten Prozeßmodell-Version vermieden werden. Außerdem kann die zweite Prozeßmodell-Version aufgrund der gemachten Erfahrungen mit der ersten Prozeßmodell-Version optimiert werden.
Bei einer zweckmäßigen Ausführung der Erfindung kann die zweite Prozeßmodell-Version mittels einer Kopie der ersten Prozeß­ modell-Version definiert werden und die zweite Prozeßmodell-Version im Anschluß an die Definition derselben durch Editieren der Kopie verändert werden. Hierdurch kann die erste Prozeßmodell-Version an veränderte Prozeßbedingungen angepaßt werden.
Eine vorteilhafte Ausführung der Erfindung kann dadurch gebildet sein, daß der Ablauf des Geschäftsprozeß auf einem Anzeigesystem darstellbar ist, wodurch eine anschauliche Darstellung zur fortlaufenden Information der am Geschäftsprozeß beteiligten Personen möglich ist.
In einer weiteren Ausgestaltung weist die Erfindung die Merkmale gemäß den Patentansprüchen 12 bis 20 auf. Hierfür gelten die Vorteile, die zu den zugehörenden Verfahrensansprüchen angeführt sind, entsprechend.
Ein Ausführungsbeispiel der Erfindung ist in der Zeichnung dargestellt und wird nachfolgend näher beschrieben.
Fig. 1 zeigt eine erste Prozeßmodell-Version "ANTRAG 1" eines Geschäftsprozesses am Beispiel eines Kreditantrages,
Fig. 2 zeigt eine zweite Prozeßmodell-Version "ANTRAG 2" eines Geschäftsprozesses am Beispiel eines Kreditantrages, und
Fig. 3 zeigt die Prozeßmodell-Version "ANTRAG 1" mit einem neuen abgeschlossenen Bereich.
Das in den Figuren gezeigte Ausführungsbeispiel der Erfindung beschreibt den Ablauf eines Geschäftsprozesses bei der Beantragung eines Kredites. Der Geschäftsprozeß ist in den Fig. 1, 2 und 3 mittels eines gerichteten Workflow-Diagramms dargestellt. Ein derartiges gerichtetes Workflow-Diagramm repräsentiert ein Netzwerk von Aktivitäten (A1, . . . , An; n2), welche durch Richtungsvektoren verbunden sind. Zwischen den Richtungsvektoren können Spaltungen (19) in mehrere Nachfolgevektoren und Vereinigungen (21) mehrerer Vektoren zu einem Nachfolgevektor eingefügt sein. Bei einer Spaltung (19) können Bedingungen einbezogen werden, wobei mit Hilfe solcher Bedingungen erreicht wird, daß der Geschäftsprozeß nur entlang bestimmter Nachfolgevektoren, für welche eine Bedingung erfüllt ist, weiterläuft.
Gemäß Fig. 1 beginnt die Abarbeitung der Aktivitäten des Geschäftsprozesses mit der Aktivität A1.1 (10) und setzt sich fort bis zu der Aktivität A9.1 (18). Nach dem Spaltpunkt S1.1 (19) spaltet der Richtungsvektor in zwei Nachfolgevektoren auf. Im Vereinigungspunkt V1.1 (21) vereinigen sich zwei Richtungsvektoren zu einem Nachfolgevektor. Im Rahmen jeder Aktivität (A1.1, . . . , A9.1) werden eine oder mehrere Aufgaben des Geschäftsprozesses gelöst. Zwischen aufeinanderfolgenden Aktivitäten werden vorzugsweise Arbeitsmittel, Daten und/oder Informationen übergeben. Das Ergebnis einer Aktivität an dem einen Ende eines Richtungsvektors ist die Eingabe für die Aktivität an der Pfeilspitze des Richtungsvektors. Beliebige Kombinationen von Aktivitäten, Richtungsvektoren, Spaltungen (19) und Vereinigungen (21) sind möglich.
Die koordinierte Abfolge der Aktivitäten im Rahmen der in Fig. 1 dargestellten Bearbeitung eines Kreditantrages wird auf der Basis einer ersten Prozeßmodell-Version mit dem Versionen-Namen "ANTRAG 1" in einem Workflow-Management-Computersystem gemanagt. In dem in Fig. 1 dargestellten Beispiel stellt ein Kunde einen Kreditantrag bei einem Mitarbeiter eines Geldinstitutes. Dieser Antrag ist der Inhalt der ersten Aktivität A1.1 (10) des Geschäftsprozesses. Im Anschluß an die Aktivität A1.1 (10) verzweigt sich der Geschäftsprozeß. In einem ersten Zweig werden die Aktivitäten A2.1 bis A4.1 (11, 12, 13) bearbeitet. Diese Aktivitäten dienen im wesentlichen dazu, Informationen über die Bonität des antragstellenden Kunden zu aquirieren. Im Rahmen der Aktivität A2.1 (11) wird der Bargeldfluß auf den Konten des antragstellenden Kunden analysiert. Hat der antragstellenden Kunde Konten bei dem Geldinstitut, bei welchem er seinen Antrag eingereicht hat, so ist diese Kontenprüfung eine interne Prüfung. Es ist aber auch möglich, daß eine Anfrage an ein anderes Geldinstitut erfolgen muß. Anschließend an die Aktivität A2.1 (11) wird im Rahmen der Aktivität A3.1 (12) die Kreditgeschichte des antragstellenden Kunden überprüft, d. h. es werden Informationen über abgezahlte und laufende Kredite des antragstellenden Kunden eingeholt. Mit Hilfe der in den Aktivitäten A2.1 (11) und A3.1 (12) gesammelten Informationen wird dann im Rahmen der Aktivität A4.1 (13) ein Gutachten zur Bewertung der Kreditwürdigkeit des antragstellenden Kunden erstellt.
Zeitlich parallel zu den Aktivitäten A2.1 bis A4.1 (11, 12, 13) laufen die Aktivitäten A5.1 bis A7.1 (14, 15, 16) ab. In der Aktivität A5.1 (14) werden die vom antragstellenden Kunden angebotenen Sicherheiten für den beantragten Kredit analysiert. Anschließend in der Aktivität A6.1 (16) werden die Ergebnisse der Analyse in der Aktivität A5.1 (15) mit den internen Richtlinien des Geldinstitutes, bei dem der Kunde seinen Antrag gestellt hat, verglichen. Basierend auf den Ergebnissen dieses Vergleiches wird in der Aktivität A7.1 (16) ein Votum für oder gegen den Kreditantrag erarbeitet. Das Vorliegen der Ergebnisse der Aktivitäten A4.1 (13) und A7.1 (16) ist Voraussetzung für die Erstellung eines Schreibens zur Bestätigung oder Ablehnung des beantragten Kredites im Rahmen der Aktivität A8.1 (17). In der Aktivität A9.1 (18) geht bei dem Geldinstitut ein Antwortschreiben des antragstellenden Kunden auf die Bestätigung/Ablehnung seines Kreditantrages ein.
Während des Ablaufes des in Fig. 1 dargestellten Geschäftsprozesses könnten zusätzliche Aktivitäten in die Prozeßmodell-Version "ANTRAG 1" integriert werden. Voraussetzung für eine derartige Einbindung späterer Aktivitäten ist, daß die Definition und Erstellung dieser späteren Aktivitäten zu einem Zeitpunkt abgeschlossen ist, zu dem im Rahmen des Geschäftsvorganges die Abarbeitung der späteren Aktivitäten beginnen soll. So wäre es möglich, daß nach Erstellung des Schreibens an den Kunden in der Aktivität A9.1 (18) eine weitere Unterschrift eingeholt werden soll. Das Einfügen dieser Aktivität wäre auch nach dem Beginn des Geschäftsvorganges durchführbar.
Es soll im folgenden angenommen werden, daß das Geldinstitut seinen Abwicklungsvorgang für einen Kreditantrag verändert, weil die interne Prüfung der Kreditwürdigkeit im eigenen Hause keine ausreichenden Beurteilungsergebnisse mehr liefert. Aus diesem Grund setzt das Geldinstitut zur Prüfung der Kreditwürdigkeit eine unabhängige Prüfungsagentur ein. Diese Änderung des Geschäftsprozesses soll aber nur solche Anträge betreffen, bei denen die bisherige interne Prüfung noch nicht angelaufen ist. Eine Zurücksetzung der Bearbeitung bereits laufender Anträge soll zur Vermeidung zusätzlicher Kosten nicht erfolgen.
Aufgrund des geänderten Vorgehens des Geldinstitutes bei der Prüfung des Kreditantrages, d. h. der Anfrage bei der Kreditagentur, muß dem Management des Geschäftsprozesses in dem Computersystem eine neue veränderte Prozeßmodell-Version mit dem Versionen-Namen "ANTRAG 2" zugrunde gelegt werden. Das Umschalten von der Prozeßmodell-Version "ANTRAG 1" auf die Prozeßmodell-Version "ANTRAG 2" soll erfolgen, ohne laufende Geschäftsprozesse zu unterbrechen. Hierdurch wird ein Verlust sämtlicher Informationen und damit verbundener Arbeitsaufwände bei bereits laufenden Geschäftsprozessen, für die die Kreditantragsprüfung noch nach der ersten Prozeßmodell-Version "ANTRAG 1" erfolgte, vermieden.
Zunächst wird eine zweite Prozeßmodell-Version defeniert, indem ein Versionen-Namen "ANTRAG 2" in den Versionen-Katalog eingetragen wird. Die Versionen-Namen werden hierbei in einer Reihenfolge entsprechend ihrem Entstehungszeitpunkt im Verlauf des Geschäftsprozesses gespeichert. Das Umschalten ist vorzugsweise nur zwischen aufeinanderfolgenden Prozeßmodell-Versionen erlaubt. Soll zwischen zwei nicht aufeinanderfolgenden Prozeßmodell-Versionen umgeschalten werden, so kann dies durch mehrmaliges Umschalten zwischen aufeinanderfolgenden Prozeßmodell-Versionen realisiert werden.
Da Veränderungen der zweiten Prozeßmodell-Version "ANTRAG 2" gegenüber der ersten Prozeßmodell-Version "ANTRAG 1" nicht sehr umfangreich sind und die Prozeßmodell-Versionen nach ihrer Definition editierbar sind, wäre es sinnvoll, die erste Prozeßmodell-Version zunächst identisch für die Definition der zweiten Prozeßmodell-Version zu übernehmen. Hierdurch werden die wesentlichen Merkmale, d. h. zum Beispiel die Anzahl und Reihenfolge der Aktivitäten, durch die zweite Prozeßmodell-Version zunächst übernommen. Die erste Prozeßmodell-Version "ANTRAG 1" darf nachdem sie zur Definition der zweiten Prozeßmodell-Version kopiert wurde nicht mehr editiert werden. Die notwendigen Veränderungen der Prozeßmodell-Version "ANTRAG 2" werden anschließend ausgeführt. Nachdem diese Veränderungen eingefügt sind, muß eine Konsistenzprüfung der Prozeßmodell-Version "ANTRAG 2" durchgeführt werden, um zu gewährleisten, daß die Aktivitäten in einer logischen Weise verknüpft sind, so daß ihre Abfolge koordiniert abläuft. Es wäre natürlich auch möglich, eine zweite Prozeßmodell-Version "ANTRAG 2" zu definieren, bei welcher zunächst keine Merkmale der ersten Prozeßmodell-Version übernommen werden, und diese dann anzupassen. Mit Hilfe des erfindungsgemäßen Verfahrens ist es möglich, diese Anpassung stückweise durchzuführen, wobei die Prozeßmodell-Version mehrmals, vorzugsweise zu verschiedenen Zeitpunkten, verändert wird. Hierbei muß nach jeder abgeschlossenen Anpassung eine Konsistenzprüfung durchgeführt werden.
Gemäß Fig. 2 weist die neue Prozeßmodell-Version "ANTRAG 2" die neue Aktivität A11.2 (26) auf. Im Rahmen dieser Aktivität beauftragt das Geldinstitut eine unabhängige Prüfungsagentur, die Kreditwürdigkeit des antragstellenden Kunden zu begutachten. Die interne Prüfung A4.1 (13), die Bestandteil der Prozeßmodell-Version "ANTRAG 1" (Fig. 1) war, entfällt. Weitere Änderungen in der Prozeßmodell-Version "ANTRAG 2" gegenüber der Prozeßmodell-Version "ANTRAG 1" sind ein veränderter Spaltungspunkt S1.2 (23) und ein zusätzlicher Vereinigungspunkt V2.2 (30). Im Spaltungspunkt S1.2 (23) teilt sich der Richtungsvektor in drei Nachfolgevektoren, da die Prüfung der Kreditwürdigkeit in der Aktivität A11.2 (26) zeitlich parallel zu den Aktivitäten A2.2 (24) und A3.2 (25) ausgeführt wird. Dies macht es andererseits notwendig den zusätzlichen Vereinigungspunkt V2.2 (30) einzubinden, da sowohl die Ergebnisse der Aktivitäten A2.2 (24) und A3.2 (25) als auch das Ergebnis der Aktivität A11.2 (26) Voraussetzung für die Abarbeitung der Aktivität A4.2 (31) sind. Der Inhalt der weiteren Aktivitäten Ax.2 (x=5, . . . ,9) der Prozeßmodell-Version "ANTRAG 2" entspricht dem jeweiligen Inhalt der Aktivitäten Ax.1 der Prozeßmodell-Version "ANTRAG 1".
Es ist davon auszugehen, daß viele Geschäftsvorgänge gleichzeitig ablaufen, so daß ein Anhalten oder Zurücksetzen bereits laufender Prozesse zu nicht vertretbaren Verzögerungen, Mehraufwand und Überlastung führen wird. Deshalb muß der Übergang zum Einsatz der Prozeßmodell-Version "ANTRAG 2" dynamisch erfolgen. Die Dynamik des Umschaltprozesses besteht insbesondere darin, daß die neue Prozeßmodell-Version nicht für alle Teilbereiche gleichzeitig eingeführt wird, sondern in Abhängigkeit von Bedingungen zeitversetzt für verschiedene abgeschlossene Bereiche einer Prozeßmodell-Version.
Um das zu erreichen, wird vor dem Beginn des Umschaltens zwischen denreßmodell-Versionen "ANTRAG 1" und "ANTRAG 2", ein Vergleich zwischen den beiden Prozeßmodell-Version durchgeführt wird, um in den Prozeßmodell-Versionen jeweils neue und alte abgeschlossene Bereiche zu unterscheiden, wobei die alten abgeschlossenen Bereiche Aktivitäten des Geschäftsprozesses umfassen, die in beiden Prozeßmodell-Versionen identisch ablaufen, und die neuen abgeschlossenen Bereiche Aktivitäten umfassen, die sich in beiden Prozeßmodell-Versionen unterscheiden. Wird zu einem Auslösezeitpunkt von einem Nutzer entschieden, daß ein Umschalten von von "ANTRAG 1" auf "ANTRAG 2" beginnen soll, kann zu diesem Auslösezeitpunkt nur innerhalb der alten abgeschlossenen Bereiche umgeschalten werden. Wird zum Auslösezeitpunkt auch eine Aktivität in dem neuen abgeschlossenen Bereich der Prozeßmodell-Version "ANTRAG 1" bearbeitet, so müssen alle daran anschließend zu bearbeitenden Aktivitäten, die sich ebenfalls in dem neuen abgeschlossenen Bereich befinden, noch in der Prozeßmodell-Version "ANTRAG 1" ausgeführt werden. Erst zu dem Zeitpunkt, zu dem die Grenze zwischen dem neuen und einem sich daran anschließenden alten abgeschlossenen Bereich überschritten wird, kann das Umschalten von "ANTRAG 1" auf "ANTRAG 2" durchgeführt werden. Das bedeutet, daß das Umschalten für diesen Teilbereich zeitlich verzögert wird. Werden zum Auslösezeitpunkt Aktivitäten aus mehreren alten und neuen abgeschlossenen Bereichen bearbeitet, so werden alle alten abgeschlossenen Bereiche zum Auslösezeitpunkt umgeschalten, während die neuen abgeschlossenen Bereiche zu verschiedenen späteren Zeitpunkten umgeschalten werden.
In Fig. 3 ist das Ergebnis des Vergleiches für die Prozeßmodell-Version "ANTRAG 1" dargestellt. Der neue abgeschlossene Bereich, der in Fig. 3 mit einer gestrichelten Linie umrahmt ist, umfaßt die Aktivitäten A2.1 bis A4.1 (11, 12, 13), den Spaltungspunkt S1.1 (19) und den Vereinigungspunkt V1.1 (21). Der alte abgeschlossene Bereich beinhaltet die nicht im neuen abgeschlossenen Bereich enthaltenen Aktivitäten.
Das Umschalten in allen alten abgeschlossenen Bereich ist stets möglich, unabhängig davon, welche Aktivität bereits abgearbeitet wurde und welche Aktivitäten noch auszuführen sind. Wird in dem dargestellten Geschäftsvorgang zum Auslösezeitpunkt parallel zu einer Aktivität aus dem alten abgeschlossenen Bereich die Aktivität A2.1 (11) aus dem neuen abgeschlossenen Bereich der Prozeßmodell-Version bearbeitet, so müssen alle daran anschließend zu bearbeitenden Aktivitäten A3.1 (12), A4.1 (13) und V1.1 (21), die sich auch in dem neuen abgeschlossenen Bereich befinden, noch in der Prozeßmodell-Version "ANTRAG 1" ausgeführt werden. Erst zu dem Zeitpunkt, zu dem die Grenze zwischen dem neuen und dem alten abgeschlossenen Bereich (zwischen dem Vereinigungspunkt V1.1 (21) und der Aktivität A8.1 (17)) überschritten wird, kann das Umschalten von "ANTRAG 1" auf "ANTRAG 2" durchgeführt werden.
Bezugszeichenliste
10, 22 Kreditantragstellung durch einen Kunden
11, 24 Analyse des Bargeldflusses
12, 25 Verifizierung der Kreditgeschichte des Kunden
13, 31 Bewertung der Kreditwürdigkeit des Kunden
14, 27 Analyse der Sicherheiten
15, 28 Vergleich der angebotenen Sicherheiten mit den Richtlinien des Geldinstitutes
16, 29 Votum für oder gegen Kreditantrag
17, 33 Erstellung eines Bestätigungs- oder Ablehnungsschreibens
18, 34 Eingang des Antwortschreibens des Kunden
19, 23 Spaltungsknoten
21, 30, 32 Vereinigungsknoten
26 Anfrage an unabhängige Kreditagentur.

Claims (20)

1. Ein Verfahren zur dynamischen Anpassung eines Geschäftsprozesses, bei dem
der Geschäftsprozeß mittels mindestens einem Prozeßmodell als eine Abfolge von Ereignissen darstellbar ist,
mindestens zwei voneinander verschiedene Versionen des Prozeßmodells existieren, die sich in einem oder mehreren Ereignissen, deren Abfolge oder der Abfolge gleicher Ereignisse unterscheiden, und die als eine erste und eine zweite Prozeßmodell-Version darstellbar sind, wobei
der Geschäftsprozeß auf der Basis der Prozeßmodell-Versionen durch digitale Daten in einem Workflow-Management-Computersystem repräsentiert wird, und
der Geschäftsprozeß durch das Computersystem gemanagt wird,
dadurch gekennzeichnet, daß
nach einem Beginn des Geschäftsprozesses mindestens einmal ein Umschalten von der ersten auf die zweite Prozeßmodell-Version oder umgekehrt im Workflow-Management-Computersystem stattfindet, ohne den Geschäftsprozeß neu zu starten.
2. Das Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß
vor dem Beginn des Umschaltens zwischen den beiden Prozeßmodell-Versionen, eine Definition der ersten und der zweiten Prozeßmodell-Version durchgeführt wird, wobei
beide Prozeßmodell-Versionen mit einem Versionen-Namen benannt werden und die Versionen-Namen in einen Versionen-Katalog eingetragen werden.
3. Das Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß
in den Versionen-Katalog alle vor Beginn eines Ablaufes des Geschäftsprozesses und während des Ablaufes des Geschäftsprozesses definierten Prozeßmodell-Versionen in einer geordneten Reihenfolge eingetragen werden.
4. Das Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß
die erste und die zweite Prozeßmodell-Version im Anschluß an ihre Definition editierbar sind und das
nach dem Abschluß eines Editiervorganges einer der Prozeßmodell-Versionen die innere Konsistenz derselben Prozeßmodell-Version überprüft wird.
5. Das Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß
eine Abarbeitung von Ereignissen einer Prozeßmodell-Version beginnt, während ein späteres Ereignis und/oder eine Abfolge späterer Ereignisse derselben Prozeßmodell-Version editiert wird,
spätere Ereignis und/oder die Abfolge späterer Ereignisse mittels einer vorzugsweise verschiebbaren Ausführungsgrenze von den Ereignissen getrennt sind und
das Editieren des späteren Ereignisses und/oder der Abfolge späteren Ereignisse zu einem Zeitpunkt abgeschlossen sein muß, zu dem die Abarbeitung des späteren Ereignisses und/oder der Abfolge späterer Ereignisse begonnen wird.
6. Das Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß ein Prozeß-Interpreter fortlaufend die Ereignisse ermittelt und speichert, welche zu einem bestimmten Zeitpunkt des Geschäftsprozesses ablaufen, hierbei insbesondere den Elemente-Namen und den Versionen-Namen der Prozeßmodell-Version ermittelt und speichert, die während des Ablaufes des jeweiligen Ereignisses den Geschäftsprozeß managt.
7. Das Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß
vor dem Beginn des Umschaltens zwischen der ersten und der zweiten Prozeßmodell-Version, ein Vergleich zwischen der ersten und der zweiten Prozeßmodell-Version durchgeführt wird, um in der ersten und der zweiten Prozeßmodell-Version jeweils mindestens einen neuen abgeschlossenen Bereich und mindestens einen alten abgeschlossenen Bereich zu unterscheiden, wobei
der alte abgeschlossene Bereich der ersten Prozeßmodell-Version und der alte abgeschlossene Bereich der zweiten Prozeßmodell-Version ein Ereignis oder eine Abfolge von Ereignissen des Geschäftsprozesses umfassen, die in beiden Prozeßmodell-Versionen identisch ablaufen, und
der neue abgeschlossene Bereich der ersten Prozeßmodell-Version und der neue abgeschlossene Bereich der zweiten Prozeßmodell-Version ein Ereignis oder eine Abfolge von Ereignissen des Geschäftsprozesses umfassen, die sich in beiden Prozeßmodell-Versionen unterscheiden.
8. Das Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß
ein Umschalten von der ersten Prozeßmodell-Version auf die zweite Prozeßmodell-Version nur zu einem Zeitpunkt des Ablaufes des Geschäftsprozesses durchführbar ist, zu dem ein Ereignis abläuft, welches sich in dem alten abgeschlossenen Bereich der ersten Prozeßmodell-Version befindet.
9. Das Verfahren nach einem der Ansprüche 2 bis 8, dadurch gekennzeichnet, daß die Definition der ersten Prozeßmodell-Version vor dem Beginn des Ablaufes des Geschäftsprozesses und die Definition der zweiten Prozeßmodell-Version nach dem Beginn des Ablaufes des Geschäftsprozesses durchgeführt werden.
10. Das Verfahren nach Anspruch 9, dadurch gekennzeichnet, daß
die zweite Prozeßmodell-Version mittels einer Kopie der ersten Prozeßmodell-Version definiert wird und
die zweite Prozeßmodell-Version im Anschluß an die Definition derselben durch Editieren der Kopie verändert wird.
11. Das Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß
der Ablauf des Geschäftsprozeß auf einem Anzeigesystem darstellbar ist.
12. Eine Vorrichtung zur dynamischen Anpassung eines Geschäftsprozesses, wobei
der Geschäftsprozeß mittels mindestens einem Prozeßmodell als eine Abfolge von Ereignissen darstellbar ist,
mindestens zwei voneinander verschiedene Versionen des Prozeßmodells existieren, die sich in einem oder mehreren Ereignissen, deren Abfolge oder der Abfolge gleicher Ereignisse unterscheiden, und die als eine erste und eine zweite Prozeßmodell-Version darstellbar sind,
der Geschäftsprozeß auf der Basis der Prozeßmodell-Versionen durch digitale Daten in einem Workflow-Management-Computersystem repräsentiert wird,
der Geschäftsprozeß durch das Computersystem gemanagt wird, und
die Vorrichtung folgendes aufweist:
Mittel zur Definition der ersten und der zweiten Prozeßmodell-Version, sowie
Mittel zum Umschalten von der ersten auf die zweite Prozeßmodell-Version oder umgekehrt, ohne den Geschäftsprozeß neu zu starten.
13. Eine Vorrichtung nach Anspruch 12, weiterhin aufweisend:
Protokolliermittel zur Erfassung der Prozeßmodell-Versionen und der Versionen-Namen,
Mittel zur Eintragung der Versionen-Namen in den Versionen-Katalog, sowie
Speichermittel zur Speicherung des Versionen-Kataloges.
14. Eine Vorrichtung nach Anspruch 12, weiterhin aufweisend:
Editiermittel zum Editieren der Prozeßmodell-Versionen, sowie
Prüfmittel, um die innere Konsistenz der Prozeßmodell-Versionen zu prüfen.
15. Eine Vorrichtung nach Anspruch 12, weiterhin aufweisend:
Interpretiermittel zur fortlaufenden Ermittlung, welche Ereignisse zu einem bestimmten Zeitpunkt des Geschäftsprozesses ablaufen, sowie
Speichermittel zur Speicherung der Element-Namen und Versionen-Namen der ermittelten Ereignisse.
16. Eine Vorrichtung nach Anspruch 12, weiterhin aufweisend:
Mittel, um die erste und die zweite Prozeßmodell-Version zu vergleichen und um in der ersten und der zweiten Prozeßmodell-Version jeweils mindestens einen neuen abgeschlossenen Bereich und mindestens einen alten abgeschlossenen Bereich zu unterscheiden.
17. Eine Vorrichtung nach Anspruch 12, weiterhin aufweisend:
Mittel zum Kopieren der ersten oder zweiten Prozeßmodell-Version.
18. Eine Vorrichtung nach Anspruch 12, weiterhin aufweisend:
Mittel zur Dokumentation des Ablaufes des Geschäftsprozesses.
19. Eine Vorrichtung nach Anspruch 12, weiterhin aufweisend:
Anzeigemittel zur Darstellung des Ablaufes des Geschäftsprozesses.
20. Eine Vorrichtung nach einem der Ansprüche 12 bis 19, dadurch gekennzeichnet, daß die Vorrichtung in das Workflow-Management-Computersystem integriert ist.
DE1996112688 1996-03-29 1996-03-29 Verfahren und Vorrichtung zur dynamischen Anpassung von Computer-gesteuerten Geschäftsprozessen Ceased DE19612688A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE1996112688 DE19612688A1 (de) 1996-03-29 1996-03-29 Verfahren und Vorrichtung zur dynamischen Anpassung von Computer-gesteuerten Geschäftsprozessen

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE1996112688 DE19612688A1 (de) 1996-03-29 1996-03-29 Verfahren und Vorrichtung zur dynamischen Anpassung von Computer-gesteuerten Geschäftsprozessen

Publications (1)

Publication Number Publication Date
DE19612688A1 true DE19612688A1 (de) 1997-10-02

Family

ID=7789951

Family Applications (1)

Application Number Title Priority Date Filing Date
DE1996112688 Ceased DE19612688A1 (de) 1996-03-29 1996-03-29 Verfahren und Vorrichtung zur dynamischen Anpassung von Computer-gesteuerten Geschäftsprozessen

Country Status (1)

Country Link
DE (1) DE19612688A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000046705A1 (en) * 1999-02-02 2000-08-10 Lombard Risk Management Plc Business optimisation
DE19911373A1 (de) * 1999-03-15 2000-10-12 Hewlett Packard Co Einrichtung und Verfahren zum Betrieb von Geschäftsprozessen in einem verteilten Informationsnetz

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0684573A2 (de) * 1994-05-26 1995-11-29 Fuji Xerox Co., Ltd. Informationsverarbeitungssystem und Verfahren für das Management des Arbeitsflusses

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0684573A2 (de) * 1994-05-26 1995-11-29 Fuji Xerox Co., Ltd. Informationsverarbeitungssystem und Verfahren für das Management des Arbeitsflusses

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000046705A1 (en) * 1999-02-02 2000-08-10 Lombard Risk Management Plc Business optimisation
DE19911373A1 (de) * 1999-03-15 2000-10-12 Hewlett Packard Co Einrichtung und Verfahren zum Betrieb von Geschäftsprozessen in einem verteilten Informationsnetz

Similar Documents

Publication Publication Date Title
DE69729926T2 (de) Netzwerkbrowser
EP0855062B1 (de) Informationssystem und verfahren zur speicherung von daten in einem informationssystem
EP0635792B1 (de) Verfahren zur Koordination von parallelen Zugriffen mehrerer Prozessoren auf Resourcenkonfigurationen
DE19844071A1 (de) Verfahren zum Lösen von Datenkonflikten in einem gemeinsamen Datenumfeld
WO2004061709A2 (de) Hilfesystem, automatisierungsvorrichtung mit einem hilfesystem sowie verfahren zum bereitstellen von hilfedaten
DE19960048A1 (de) Zeitgesteuerte Startbedingungen für Aktivitäten in Workflow-Management-Systemen
WO2000023923A1 (de) Verfahren zur datenbankgestützten selektion von produkten für electronic-commerce-anwendungen im internet
DE102007009737A1 (de) Verfahren, Drucksystem und Computerprogramm zum automatischen Bearbeiten von Auftragsbegleitdaten eines Druckauftrages
EP0990984A2 (de) Verfahren zum Vermitteln von Prozessdaten sowie Verfahren zum Erstellen von anwenderspezifischen Daten und mit diesem Verfahren erstellte Daten
DE19612688A1 (de) Verfahren und Vorrichtung zur dynamischen Anpassung von Computer-gesteuerten Geschäftsprozessen
DE10335326A1 (de) Verfahren und Vorrichtung zur Simulation von Prozessabläufen in der graphischen Industrie
EP3966723A1 (de) Verfahren und anordnung zur bereitstellung von daten einer industriellen automatisierungsanordnung zu einer externen anordnung
DE10108564A1 (de) Verfahren zur Suche nach in einem verteilten System aktuell oder früher gespeicherten Daten oder Daten enthaltenden Ressourcen unter Berücksichtigung des Zeitpunkts ihrer Verfügbarkeit
EP1234231B1 (de) Verfahren zur erzeugung grafischer benutzerschnittstellen für computerprogramme
DE60213008T2 (de) Anordnung und verfahren zum unterstützen der prozess-/anwendungssteuerung
DE10310886B3 (de) Verfahren und System zum gleichzeitigen Anzeigen desselben Inhalts auf zu verschiedenen Computern gehörenden Bildschirmen, sowie Web-Seite mit einem Link zu einem Dienst
DE60225272T2 (de) Netzwerk-basierte Informationenverwaltung
DE10220283B4 (de) Methode und System für lokale Operationen in einer Transaktionsumgebung
DE60320395T2 (de) Methode und Computersystem zum Archivieren von Datenobjekten
EP4092496A1 (de) Engineering-system zum projektieren einer bedien-beobachtungssicht für eine automatisierungseinrichtung
DE202021004368U1 (de) Kompartimentierung eines Prozesses
DE19807436B4 (de) System und Verfahren zur Steuerung und Überwachung von Programmen in einem Rechnerverbund
DE19911373A1 (de) Einrichtung und Verfahren zum Betrieb von Geschäftsprozessen in einem verteilten Informationsnetz
EP3877926A1 (de) Vorrichtung und verfahren zum umwandeln von daten aus einer digitalen kundenschnittstelle eines rechnernetzsystems
EP1674957A1 (de) Regelbasiertes, verteiltes Engineering

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8131 Rejection