WO2004083982A2

WO2004083982A2 - Modellierung eines komplexen systems

Info

Publication number: WO2004083982A2
Application number: PCT/CH2004/000160
Authority: WO
Inventors: Roland Pulfer
Original assignee: Roland Pulfer
Priority date: 2003-03-19
Filing date: 2004-03-18
Publication date: 2004-09-30
Also published as: US20060277022A1; US7941301B2; WO2004083982A8; CH698890B1

Abstract

Eine Modellierung eines komplexen Systems, wobei in Ereignisketten des Systems Einheiten wie Daten und/oder Produkte empfangen, verarbeitet und weitergeleitet werden, verwendet auf einer untersten Beschreibungsebene einen begrenzten Satz von Grundtypen zur Repräsentation der Einheiten und zur Beschreibung ihres Zusammenwirkens. Jeder Grundtyp verarbeitet Daten welche Werte von Eigenschaften der genannten Einheiten repräsentieren. Der Satz von Grundtypen weist auf einen Grundtyp "Weiterleiten", welcher eine Weiterleitung von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten durchleitet und einen Eingang sowie einen Ausgang aufweist, einen Grundtyp "Verschmelzen", welcher ein Kombinieren von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten miteinander verknüpft und zwei Eingänge sowie einen Ausgang aufweist, und einen Grundtyp "Aufteilen", welcher eine Auftrennung von Einheiten repräsentiert, Daten zur Charakterisierung von Einheiten, die aus einer Auftrennung hervorgehen, aus Daten einer aufzutrennenden Einheit ermittelt, und einen Eingang sowie zwei Ausgänge aufweist. Eingänge dienen zur Übernahme und Ausgänge zur Übergabe von Daten in den respektive aus dem jeweiligen Grundtyp. Computerbasierte datenverarbeitende Modelle des Systems werden gebildet durch Bildung einer Menge von Grundtypen und durch Verknüpfen von Ein- und Ausgängen dieser Grundtypen.

Description

MODELLIERUNG EINES KOMPLEXEN SYSTEMS

Die Erfindung betrifft die Modellierung komplexer Systeme. Ein System beliebiger Art, beispielsweise eine prozesstechnische oder fertigungstechische Anlage, weist eine Vielzahl von interagierenden und gegenseitig abhängigen Einheiten auf, die durch ihr Zusammenwirken ein gewünschtes Ergebnis erzeugen, beispielsweise ein physisches Produkt. Gleiches gilt für ein System welches auch oder vorwiegend menschliche Aktoren oder Handlungsträger aufweist und ein physisches Produkt und/oder eine Dienstleistung erzeugt. Die Erfindung ist ferner gerichtet auf das Gebiet der Datenerfassung, Datenorganisation, Datenauswertung und der Verwendung von in solcher Weise prozessierter Daten für die Steuerung und Überwachung von komplexen Systemen. Eine verwandte Anmeldung ist PCT/CH02/00516, deren Inhalt hiermit in seiner Gesamtheit mit aufgenommen wird.

Bei komplexen Systemen die eine Vielzahl von miteinander verknüpften Prozessen aufweisen, ist es sehr schwierig den Einfluss von Veränderungen einzelner Verknüpfungen und Parameter auf ein Verhalten des Gesamtsystems vorherzusagen. Beispielsweise stellt bei der Herstellung von hochkomplexen Gütern mit entsprechender Produktionsabläufen und ebenfalls entsprechender Organisation, die Umsetzung von Zielen, die Überwachung der Ausführung und die Entscheidungsfindung und Steuerung ein grosses Problem dar. Da die Anzahl der Einflussgrössen mit der Grosse eines Herstellungsprozesses, eines Unternehmens oder eines Projektes exponentiell zunimmt, können diese nicht mehr gesamtheitlich überblickt werden. Deshalb ist es sehr schwierig, relevante von nichtrelevanten Grossen, d.h. Parameter und Messwerte, zu unterscheiden, zu gewichten und im richtigen Kontext auszuwerten und/oder anzuwenden. Entscheidungen bei der Steuerung technischer und organisatorischer Prozesse werden deshalb häufig willkürlich getroffen.

Die Abbildung solcher Prozesse geschieht in der Regel mit spezialisierten Modellierungs- oder Verwaltungsprogrammen für ERP (enterprise resource planning), CRM (customer relationship management), SCM (supply chaiii management), etc. und massgeschneiderter Produktionssteuerungssoftware.

Diese sind jedoch einerseits in ihrer Darstellungsfähigkeit begrenzt, und weisen innerhalb dieser Grenzen eine sehr hohe Komplexität und Spezialisierung bestimmte Systeme und Aufgaben auf.

Es ist deshalb eine Aufgabe der Erfindung, ein Verfahren, ein Datenverarbeitungssystem und ein Computerprogramm zur Modellierung eines komplexen Systems zu schaffen, welche ein adäquate und flexible Repräsentation von verschieden gearteten Systemen erlaubt.

Diese Aufgabe wird durch den Gegenstand der unabhängigen Ansprüche gelöst. Die abhängigen Ansprüche betreffen vorteilhafte Ausgestaltungen der Erfindung.

Die Modellierung geschieht also auf einer untersten Beschreibungsebene mit einem begrenzten Satz von Grundtypen zur Repräsentation der Einheiten und zur Beschreibung ihres Zusammenwirkens. Die Grundtypen weisen Ein- und Ausgänge zur Übernahme und Weitergabe von Daten auf. Die Grundtypen sind:

o Ein Grundtyp "Weiterleiten", welcher eine Weiterleitung von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten durchleitet und einen Eingang sowie einen Ausgang aufweist.

• Ein Grundtyp "Verschmelzen", welcher ein Kombinieren von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten miteinander verknüpft und zwei Eingänge sowie einen Ausgang für die verknüpften Daten aufweist.

• Ein Grundtyp "Aufteilen" , welcher eine Auftrennung von Einheiten repräsentiert, Daten zur Charakterisierung von Einheiten, die aus einer Auftrennung hervorgehen, aus Daten einer aufzutrennenden Einheit ermittelt, und einen Eingang sowie zwei Ausgänge aufweist.

Die Erfindung hat den Vorteil, dass alle Vorgänge zwischen Einheiten auf jeder Detaillierungsstufe und Betrachtungsstufe auf diese Grundtypen zurückführbar sind, Dadurch ist der Modellierungsaufwand begrenzt, schematisierbar und zumindest teilweise automatisierbar. Ein weiterer Vorteil ist, dass auch verschiedene Analysen des Modells in vergleichsweise einfacher Weise standardisierbar und automatisierbar sind, da immer dieselben Grundtypen verarbeitet werden müssen, was eine Formalisierung und Programmierung der Analyse vereinfacht. Dadurch, dass immer die gleichen Grundtypen zur Systemdefinition angewendet werden, erhöhen sich auch die Vergleichsmöglichkeiten zwischen Systemen. Dies ist unabhängig davon, ob ein Vergleich automatisch oder manuell geschieht, und ob artverwandte oder nicht artverwandte Systeme verglichen werden. Ebenfalls wird eine Transparenz der Modelle auch bei hoher Komplexität erhöht. Die Verwendung der Grundtypen entspricht in der Denkweise einer Verwendung von Schaltelementen in der Elektrotechnik: mit einem begrenzten Satz von Schaltelementen wie Transistoren, Widerständen, Induktivitäten und Kondensatoren lässt sich eine immense Vielfalt von Schaltungen erstellen. Ähnliches gilt für die Logik von integrierten Schaltungen, wo alle denkbaren logischen Verknüpfungen nur durch NAND-Gatter realisierbar sind. Die Grundtypen finden ihren Ausdruck vorzugsweise in einer Klassenhierarchie einer objektorientierten Darstellung von Softwareobjekten, aus denen das Modell aufgebaut ist. Es sind also alle übrigen wesentlichen Softwareobjekte anhand dieser Grundtypen definiert, und weisen darüber hinaus natürlich weitere Attribute und Methoden auf. In einer bevorzugten Variante der Erfindung werden, basierend auf dem Grundtyp "weiterleiten", zwei weitere Grundtypen definiert und verwendet:

• Ein Grundtyp "Aufbewahren", welcher eine Speicherung von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten speichert und einen Eingang sowie einen Ausgang aufweist. • Ein Grundtyp "Erzeugen", welcher eine Quelle von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten erzeugt und einen Ausgang aufweist.

Zum besseren Verständnis der Erfindung werden einige weitere Begriffe definiert:

Ein System besteht aus einer Menge von zusammenwirkenden Einheiten, dessen Verhalten als Ganzes nachgebildet, untersucht und modifiziert und vorzugsweise auch überwacht werden soll. Vorzugsweise ist ein System eine technische Anlage, eine Maschine, ein Produktionsprozess oder ein Arbeitsprozess, wobei ein System auch mehrere dieser Aspekte beinhalten kann.

Die zusammenwirkenden Einheiten sind vorzugsweise elektromechanische, verfahrenstechnische und/oder informationsverarbeitende oder informationstragende Subsysteme oder Elemente, oder auch organisatorische Untereinheiten und Stellen einer Organisation. Beispielsweise sind als Einheit betrachtbar: eine Maschine als Teil einer Anlage, ein Prozessor als Teil einer Maschine, eine autonome Fertigungszelle, ein Produkt oder eine Produktkomponente, eine Computeranlage, eine Datenbank, ein Softwareobjekt, eine maschinenlesbare Datei, eine Abteilung einer Firma, eine Person, eine Funktion oder Rolle in einer Organisation, etc....

Der Begriff Modellierung betrifft sowohl eine erstmalige Bildung einer abstrakten, insbesondere einer maschinenlesbaren Repräsentation des Systems, als auch eine Nachführung dieser Repräsentation an einen tatsächlichen, realen Zustand des Systems. Letztere wird insbesondere bei einer online Prozessanalyse ("Monitoring") und/oder bei einer Steuerung des Systems durch im Modell bestimmte Steuerbefehle verwendet. Diese Repräsentation des Systems wird auch Modell genannt, und weist eine Modellstruktur sowie Modellparameter auf. Die Modellstruktur stellt Beziehungen zwischen modellierten Einheiten dar, währenddem die Modellparameter numerische und/oder textuelle Charakterisierungen von Eigenschaften der Einheiten oder Beziehungen sind. Das Modell weist Mechanismen und Regeln zur Verknüpfung und Verarbeitung von Daten, die Aspekte des Systems repräsentieren, auf. Das Modell ist also nicht nur ein Daten enthaltendes, sondern auch Daten verarbeitendes Modell.

In einer bevorzugten Variante der Erfindung weist jeder Grundtyp eine Historienoder Protokollfunktion auf, mit welcher er verarbeitete oder durchgeleitete Daten sowie den Zeitpunkt der Verarbeitung oder Durchleitung speichert. Damit wird das Erstellen von Statistiken und Analysen sowie eine spätere Rückverfolgung von Vorgängen möglich. In einer weiteren bevorzugten Variante der Erfindung werden die Grundtypen auf einer höheren Hierarchiestufe zu sogenannten Objekten zusammengefasst. Von den Ein- und Ausgängen der zusammengefassten Grundtypen bleibt eine Anzahl innerhalb des Objektes, wird also nicht ausserhalb des Objektes sichtbar. Andere Ein- und Ausgänge werden als Ein- und Ausgänge oder Schnittstellen des Objekts nach aussen sichtbar. In der Regel weist ein Objekt einen oder mehrere Eingänge und einen oder mehrere Ausgänge auf. Ein Objekt kann aber beispielsweise keine Eingänge respektive keine Ausgänge aufweisen, wenn es am Anfang respektive am Ende einer Ereigniskette steht. Der Begriff "Objekt", wie er in dieser Anmeldung verwendet wird, ist enger gefasst als der Begriff "Software-Objekt im Sinne der objektorientierten Programmierung": Objekte wie auch Grundtypen sind Software- Objekte. Objekte bestehen aus einer Menge von Grundtypen und verfügen über definierte Eigenschaften und Verhalten. Objekte werden später auch als "vordefinierte Objekte" bezeichnet, der Kürze halber aber in der Regel nur als Objekte.

Dies erlaubt eine strukturierte und - systematische Modellbildung und auch die Zuordnung von Informationen oder Eigenschaften zu einem Objekt als Ganzem. Ferner wird auch eine Wiederverwertung von häufig auftretenden Strukturen von Grundtypen als vordefinierte Objekte möglich, was wiederum eine effiziente Modellbildung ermöglicht.

Vorzugsweise weisen Objekte unterschiedliche Ausgestaltungen auf, das heisst, sie repräsentieren unterschiedliche Aspekte der Realität. Gemäss allgemein bekannten Prinzipien der objektorientierte Programmierung werden Objekte zur Darstellung von beispielsweise Produkten, Abläufen, Handlungsträgern, Produktionsmitteln etc. definiert, welche Eigenschaften und Methoden eines allgemeinen Objektes erben und diesen spezifische Eigenschaften und Methoden zufügen. Alle Objekte weisen jedoch mindestens einen der fünf Grundtpyen auf.

Zur weiteren Erklärung der Erfindung sind noch einige zusätzliche Definitionen erforderlich: Das System und sein Verhalten werden auf drei Betrachtungsebenen, genannt "Prozessebene", "Elementebene" und "Informations- und Funktionsebene", betrachtet. Die Prozessebene weist Prozesse auf. Das System wird als Gruppierung von Prozessen betrachtet. Dabei ist ein Prozess eine Gesamtheit von Aufgaben, Abläufen und Entscheidungen. Prozesse sind beispielsweise Produktionsprozesse oder Arbeitsprozesse wie "Fertigung", "Endmontage", "Energieerzeugung", "Druckmaschinenstrasse", "Acetylensynthese", "Lagerverwaltung", "Einkauf", "Personal Verwaltung", etc. Ein Prozess erhält von anderen Objekttypen, beispielsweise anderen Prozessen oder externen Agenten (siehe unten), über seine Eingänge Eingaben oder Input und produziert für die anderen Objekttypen Ausgaben oder Output. Ein Prozess kann in Subprozesse unterteilt werden.

Eine bestimmte Aufgabe eines Prozesses wird durch einen bestimmten Ablauf von Aktivitäten und einen entsprechenden Informationsfluss gelöst. Dieser Ablauf wird Ereigniskette genannt. Ereignisketten sind beispielsweise "Airbus A320 herstellen", "50 Tonnen Schwefelsäure herstellen", "Teil XY aus Hochregallager bereitstellen", "Druckmaschine konfigurieren", "Computerarbeitsplatz einrichten", "Mitarbeiter einstellen". Der Begriff Prozess beschreibt also eine Einheit, die bestimmte Aufgaben zu erfüllen in der Lage ist, währenddem der Begriff Ereigniskette einen bestimmten Ablauf in einem Prozess oder über mehrere Prozesse beschreibt Ein Prozess wird typischerweise von mehreren Ereignisketten benutzt..

Zur Modellierung von Abläufen werden vorzugsweise Aktivitätsdiagramme verwendet, die auf einem oberen Darstellungsniveau den bekannten Flussdiagrammen entsprechen. Ein Aktivitätsdiagramm beschreibt sequentiell und/oder verzweigt ablaufende Aktivitäten. Einzelne Aktivitäten, Verzweigungspunkte und Entscheidungspunkte eines Aktivitätsdiagramms sind Objekte und sind somit aus den Grundtypen aufgebaut. Beispielsweise wird ein Verzweigungspunkt durch einen Gruήdtypen "Aufteilen" mit entsprechenden inneren Regeln dargestellt. Eine Aktivität kann aus einer Menge von beliebig zusammengeschalteten Grundtypen oder aus einem separaten Aktivitätendiagramm aufgebaut sein. Ein Ablauf innerhalb eines Prozesses kann also einerseits direkt durch Grundtypen modelliert werde, andererseits auch durch Aktivitäten, welche wiederum aus Grundtypen bestehen. Externe Agenten sind Modellteile, die einen Aspekt der Realität repräsentieren, der im Modell oder von einem Teil des Modells aus gesehen nicht detailliert modelliert wird oder eine Aggregation von Objekten bestehend aus Grundtypen darstellt. Ein externer Agent stellt im Wesentlichen eine Schnittstelle, das heisst Ein- und Ausgänge zur Verfügung, und weist optional eine vereinfachte Modellierung eines an sich komplexeren internen Verhaltens auf, dessen Details aber nicht von Interesse sind.

Die Elementebene weist Elemente auf. Ein Element repräsentiert eine reale physische Einheit aus den Kategorien Informationstechnologie (IT), Organisation, Werkzeuge und mechanisch-elektronische Module. Ein Element unterstützt einen Prozess oder eine Aktivität eines Prozesses. Elemente sind beispielsweise Computer, eine IT-Abteilung, eine Person respektive ein Funktionsträger, eine Bearbeitungsmaschine, ein elektromechanisches Produkt oder dessen Einzelleile.

Die Informations- und Funktionsebene weist Informationen und Funktionen auf. Diese repräsentieren insbesondere mformationstechnische Einheiten wie Datenbanktabellen oder -attribute, Variablen, respektive deren Werte, sowie Prozeduren, Programme, Messwerte und Parameter.

Die fünf Grundtypen sind auf jeder der Betrachtungsebenen verwendbar. Das System wird also auf jeder der Betrachtungsebenen mit denselben Grundtypen modelliert, wobei die Einheiten, deren Repräsentation durch die Grundtypen dargestellt oder verarbeitet wird, je nach Betrachtungsebene unterschiedlicher Art sind. Zweckmässigerweise werden auch Objekte und vordefinierte Objekte auf allen Betrachtungsebenen verwendet.

Um Beziehungen zwischen Grundtypen, Objekten und untereinander zu repräsentieren, werden vorzugsweise verschieden geartete Beziehungstypen verwendet. Im Folgenden werden der Einfachheit wegen nur Objekte genannt, wobei Grundtypen als einfachste Formen von Objekten mitgemeint sind. Diese Beziehungstypen sind gruppiert als permanente Beziehungen, Interaktionsbeziehungen, Flussbeziehungen und Differenzbeziehungen. Permanente Beziehungen stellen eine einfache Referenz von einem Objekt zu einem anderen dar, oder die Tatsache, dass ein Objekt in einer anderen Betrachtungsebene einem anderen Objekt entspricht. Beispielsweise entspricht ein Prozess "Lagerverwaltung" einer Menge von mehreren Aktivitäten "einlagern", "auslagern", "Inventar erstellen", etc. Dies wird durch eine Menge von entsprechenden permanenten Beziehungen zwischen dem Prozess und den einzelnen Aktivitäten dargestellt.

Interaktionsbeziehungen oder Wechselwirkungen stellen eine Einflussnahme eines Objektes auf ein anderes dar. Dabei ist die Art der Einflussnahme oder Wechselwirkung zum Zeitpunkt der Modellbildung bekannt und wird durch die Art der Interaktionsbeziehung repräsentiert. Beispielsweise ist eine Systemausfallrate eines Produktes aus Ausfallraten von Produktkomponenten bestimmbar, wobei Abhängigkeiten des Systemausfalls von Ausfällen einzelner Komponenten durch jeweilige Wechselwirkungsbeziehungen dargestellt werden. In einem anderen Beispiel wird für eine Ereigniskette "Motor herstellen" durch zwei Wechselwirkungsbeziehungen festgehalten, dass dazu auf der Elementebene in einem bestimmten Zeitraum eine Werkzeugmaschine zu 70% und eine bestimmte Fertigungszelle zu 50% ausgelastet ist. In wieder einem anderen Beispiel drückt eine Wechselwirkungsbeziehung aus, dass ein bestimmter charakteristischer Wert, der beispielsweise ein Risiko, einen Erfüllungsgrad, Kosten, Zeitaufwand, Materialverbrauch, Energieverbrauch etc. repräsentiert, von einem ersten Objekt an ein zweites Objekt übermittelt wird. Im zweiten Objekt wird der Wert mit Werten von anderen Objekten verrechnet und wird ein charakteristischer Wert für das zweite Objekt berechnet. In einem weiteren Beispiel repräsentiert eine Wechselwirkungs- beziehung, dass ein erstes Objekt einem zweiten Objekt unter bestimmten Bedingungen eine Ereignisbotschaft sendet, welche im zweiten Objekt gegebenenfalls Änderungen oder Berechnungen auslöst.

Flussbeziehungen stellen eine Übermittlung von Informationen oder Inhalten von einem Objektes zu einem zweiten Objekt dar. Im Gegensatz zu einer Interaktionsbeziehung ist dabei die Art der daraus eventuell resultierenden

Einflussnahme auf das zweite Objekt zum Zeitpunkt der Modellbildung nicht bekannt. Beispielsweise wird entsprechend einer Flussbeziehung eine Datei übertragen, die im zweiten Objekt gemäss vorgegebenen Regeln oder Algorithmen analysiert wird und gegebenenfalls zu bestimmten Aktivitäten des zweiten Objekts führt. In einem anderen Beispiel wird entsprechend einer Flussbeziehung ein Ereignis oder ein Befehl übertragen, wobei die Verarbeitung des Ereignisses und eine allfällige Reaktion durch das empfangende Objekt bestimmt wird.

Differenzbeziehungen stellen Unterschiede zwischen gleichartigen Objekten dar, welche sich in einem unterschiedlichen Zustand befinden. Eine Differenzbeziehung erfasst alle diese Unterschiede und kann damit, entsprechend der Komplexität der Objekte, sehr umfangreich sein.

In einer bevorzugten Variante der Erfindung wird anhand von solchen Beziehungen bestimmt, wie sehr Ressourcen ausgelastet sind und/oder bis zu welchem Grad ein vorgegebenes Ziel des Systems erreicht wird. Beispielsweise besteht eine Ereigniskette auf der Prozessebene aus verschiedenen Einzelschritten oder Prozessschritten. Jeder Einzelschritt wird durch einen oder mehrere Elemente aus der Elementebene unterstützt, was durch entsprechende Beziehungen zwischen Prozessen und Elementen modelliert wird. Vorzugsweise sind solche Unterstützungsbeziehungen mit einem oder mehreren numerischen Werten assoziiert, die beispielsweise ausdrücken, wie sehr ein bestimmtes Element einen bestimmten Prozess unterstützt. Durch diese Art der Modellierung ist einerseits bestimmbar, dass ausreichend Unterstützung für eine oder mehrere bestimmte Ereignisketten besteht, und andererseits lässt sich eine Auslastung der unterstützenden Elemente bestimmen.

In einer weiteren bevorzugten Ausführungsform der Erfindung werden verschiedene Aspekte eines Systems, respektive seiner Prozesse und Ereignisketten auf mindestens zwei der Betrachtungsebenen modelliert, und es werden Beziehungen zwischen den dazu verwendeten Objekten modelliert. Durch diese Art der Modellierung, das heisst durch eine Vernetzung verschiedener Modellelemente, wird eine Kontrolle der Qualität des Modells ermöglicht. Beispielsweise ist prüfbar, ob das Modell nicht nur syntaktisch korrekt, sondern auch vollständig und konsistent über die unterschiedlichen Betrachtungsebenen ist. Resultate der Analysen werden durch Ausdruck oder Anzeigegeräte an einen Benutzer ausgegeben. Aufgrund der ausgegebenen Resultate wird vorzugsweise das Modell iterativ angepasst, d.h. korrigiert und/oder der Realität des modellierten Systems nachgeführt.

In einer weiteren bevorzugten Variante der Erfindung werden zwei Modelle desselben Systems verwendet. Ein Modell repräsentiert das System in einem ersten, beispielsweise einem Ist-Zustand, das andere Modell repräsentiert das System in einem zweiten, beispielsweise einem Soll-Zustand. Mittels eines automatischen Vergleichsalgorithmus werden Unterschiede zwischen den beiden Zuständen ermittelt, und es werden Handlungen bestimmt, die das System schrittweise vom ersten in den zweiten Zustand überführen.

Das Modell oder Teile des Modells werden entweder manuell oder automatisch erzeugt. Für die manuelle Erzeugung wird vorzugsweise ein graphischer Editor verwendet. Mit diesem werden beispielsweise Objekte und Beziehungen auf einem Anzeigemittel wie einem Bildschirm als Flächen respektive Verbindungslinien dargestellt und mit Hilfe eines Zeigemittels wie einer Computermaus positioniert und miteinander verbunden. Parameter von Objekten respektive Beziehungen werden beispielsweise über zugeordnete Darstellungs- und Eingabemasken dargestellt und geändert. Zur Änderung eines Parameters wird ein entsprechender Text eingegeben, oder es erscheint beim Anklicken eines zugeordneten Bildschirmelementes eine Liste oder ein Dialog zur Definition des Parameters nach Massgabe von bereits eingegebenen Modellelementen.

Für die automatische Erzeugung von Modellteilen werden vorzugsweise Programmeinheiten in ein bestehendes Datenverarbeitungssystem eingesetzt, welche automatisch Einheiten wie Verarbeitungseinheiten, Datenflüsse und Aufrufstrukturen des Datenverarbeitungssystems erfassen, analysieren, und im Modell entsprechende Objekte und Beziehungen zur Abbildung dieser Einheiten erzeugen.

In einer weiteren bevorzugten Variante der Erfindung werden zu einem Modell, dessen Struktur bekannt ist, Parameter ebenfalls durch in einem Datenverarbeitungssystem verteilte Programmeinheiten automatisch bestimmt und als Teil des Modells gespeichert. In einer weiteren Ausführungsform der Erfindung erlaubt sie die Analyse, Überwachung und Steuerung eines realen Systems. Dazu werden Messwerte aus dem System automatisch oder manuell dem Modell übermittelt und wird das Modell gemäss verschiedenen Verfahren aufdatiert und analysiert. Aufgrund der Verwendung einheitlicher Grundtypen und Beziehungstypen sind diese Verfahren, beispielsweise ein automatischer Vergleich verschiedener Modelle des gleichen Systems, auf verschiedenen Systemebenen und in verschiedenen Zusammenhängen anwendbar. Weitere Verfahren bestimmen beispielsweise Risiken, Qualität, Performance, Stabilität oder die Robustheit eines Systems und ihre Zusammenhänge. Dies geschieht durchgängig durch das gesamte Modell, dank der allem zugrundeliegenden Modellierung durch Grundtypen. Dies gilt auch für eine Modellierung und Analyse mittels der vordefinierten Objekte, die auf den Grundtypen basieren. Das Vorhandensein von Regeln und Ausnahmebedingungen in den Grundtypen erlaubt eine höchst flexible Überwachung des Systems, da Kontrollbedingungen und/oder Steuerverfahren an jedes Objekt und an jede Beziehung geknüpft werden können.

Die Erfindung hat unter anderem den Vorteil, dass eine Systemstruktur umfassend darstellbar ist und wichtige Kenngrössen eines Systems objektiv erfassbar sind. Bei traditionellen Ansätzen führt die Systemkomplexität aufgrund von Vernetzungen und dauernden Veränderungen dazu, dass solche Kenngrössen unterschiedlich eingeschätzt und interpretiert werden. Ein standardisiertes Erfassen der relevanten System- bzw. Prozessgrundlagen, deren Qualifizierung und Auswertung ist damit praktisch nicht möglich oder nur mit sehr hohem Zeitaufwand und Ressourcenverbrauch verbunden. Die Erfindung erlaubt eine - unter bestimmten Umständen automatische - Erfassung einer Vielzahl von Messungen und ihre Auswertung im Kontext eines Modells, welches die relevante Aspekte der Realität in zweckmässiger Weise abbildet. Einheiten, Abläufe und Vorgänge im betrachteten System werden mit ihren Parametern abgebildet und miteinander in Beziehung gesetzt, und dann entsprechend der Vernetzung analysiert. Durch das Verwenden von standardisierten Abläufen und Algorithmen bei der Modellbildung und deren Verifizierung durch Vergleich unterschiedlicher Modellaspekte resultieren qualitativ hochstehende Modelle. Als Resultat der Auswertung kann das reale System gesteuert werden und/oder das Modell dem realen System nachgeführt werden.

Die Erfindung eignet sich insbesondere zur Modellierung komplexer, multidimensionaler vernetzter Systeme. Diese real existierenden Systemeigenschaften sind durch die verschiedenen vordefinierten Objekte wie Betrachtungsebenen und -segmente, Ereignisketten, Prozesse, Produkt etc. erfassbar und können zueinander in Beziehung gebracht werden. Die Ausdrucksfähigkeit der Modellierung bei gleichzeitig einheitlicher Grundlage ermöglicht eine umfassende Repräsentation des Systems im Modell, die für verschiedene automatische Analyseverfahren verwendbar ist.

Die Erfindung ist vorzugsweise in Form von einem oder mehreren Computerprogrammen implementiert

Das Datenverarbeitungssystem gemäss der Erfindung weist Speichermittel mit darin gespeicherten Computerprogrammcodemitteln auf, welche ein Computerprogramm beschreiben, und Datenverarbeitungsmittel zur Ausführung des Computerprogramms, wobei die Ausführung des Computerprogramms zur Durchführung des Verfahrens gemäss der Erfindung führt.

Das Computerprogramm gemäss der Erfindung ist in einen internen Speicher einer digitalen Datenverarbeitungseinheit ladbar und weist Computerprogrammcodemittel auf, welche, wenn sie in einer digitalen Datenverarbeitungseinheit ausgeführt werden, diese zur Ausführung des erfindungsgemässen Verfahrens bringen. In einer bevorzugten Ausführungsform der Erfindung weist ein Computerprogrammprodukt ein computerlesbares Medium, einen Datenträger, auf, auf welchem die Computerprogrammcodemittel gespeichert sind. In einer bevorzugten Ausführungsform der Erfindung werden separate Teile des Computerprogramms in separaten Rechnern ausgeführt, beispielsweise gemäss einer bekannten Client/Server-Architektur und/oder unter Verwendung von über einem Netzwerk verteilten Datenbanken. Zur Alarmierung und Benachrichtigung von Bedienpersonenen oder Benutzern besteht eine Verbindung zu Nachrichtenverteil- Systemen wie e-mail, SMS (short message System), etc. KURZE BESCHREIBUNG DER FIGUREN

Im folgenden wird der Erfindungsgegenstand anhand von bevorzugten Ausführungsbeispielen, welche in den beiliegenden Zeichnungen dargestellt sind, näher erläutert. Es zeigen schematisch Fig.l Grundtypen;

Fig.2 eine Aufspaltung eines Objekts in Grundtypen ;

Fig.3 ein Prozessmodell;

Fig.4 ein Prozessmodell, aufgeteilt in Subprozesse;

Fig.5 Ereignisketten durch Prozesse und mit Unterstützung durch Elemente; F Fiigg..66 eine Übersichtsdarstellüng;

Fig.7 ein einfaches Beispiel mit vordefinierten Objekten "Prozess" und

"Externer Vertreter";

Fig.8 eine Darstellung eines Prozesses durch Aktivitäten;

Fig.9 ein vordefiniertes Objekt "Aktivität" in einem Aktivitätendiagramm; F Fiigg..1100 ein vordefiniertes Objekte "Arbeitsmittel";

Fig.ll ein vordefiniertes Objekt "Ereigniskette";

Fig.12 Betrachtungsebenen zur Validierung und Qualitätskontrolle;

Fig.13 ein Beispiel für eine Modellvalidierung;

Fig.14 Unterstützungsbeziehungen und Kostenverteilung; F Fiigg.. 1155 unterschiedliche Kostenverteilungsarten; und

Fig.16 einen Modellvergleich.

Grundsätzlich sind in den Figuren gleiche oder gleichgeartete Teile mit gleichen Bezugszeichen versehen.

WEGE ZUR AUSFÜHRUNG DER ERFINDUNG In der Folge werden zuerst gemäss der Erfindung verwendete Information und Strukturen beschrieben, und anschliessend darauf aufbauende Verfahren.

Ein System besteht aus einer Menge von zusammenwirkenden Einheiten, dessen

Verhalten als Ganzes nachgebildet, untersucht und modifiziert werden soll.

Vorzugsweise ist ein System eine technische Anlage, eine Maschine, ein Produktionsprozess oder ein Arbeitsprozess, wobei ein System auch mehrere dieser Aspekte beinhalten kann. Ein Produktionsprozess dient beispielsweise einer Erzeugung von physischen Produkten, oder Energie. Als grundlegender "Bausatz" für die Modellierung dient eine Menge von Grundtypen:

GRUNDTYPEN Figur 1 zeigt schematisch Grundtypen, die einen Kanon für die Modellbildung zur Darstellung eines Systems bilden. Die Grundtypen werden bezeichnet mit:

1. "erzeugen" oder "source", mit keinem Eingang und einem Ausgang;

2. "weiterleiten" oder "straight", mit einem Eingang und einem Ausgang;

3. "verschmelzen" oder "merge", mit zwei Eingängen und einem Ausgang; 4. "aufteilen" oder "split", mit einem Eingang und zwei Ausgängen; und

5. "aufbewahren" oder "störe", mit einem Eingang und einem Ausgang. Grundsätzlich sind die Grundtypen "erzeugen" und "aufbewahren" durch den Grundtyp "weiterleiten" darstellbar, so dass drei Grundtypen zu Modellierung ausreichen. Die beiden zusätzlichen Grundtypen sind für eine einfachere Darstellung zweckmässig.

Die erwähnten Eingänge und Ausgänge entsprechen einer Übernahme respektive einer Übergabe von Daten. Insbesondere kann ein Eingang und Ausgang ein einfaches Ereignis respektive Auslöser oder "trigger" sein, und/oder einen Inhalt oder "content" tragen. Die Eingänge und Ausgänge werden beim Aufbau eines Modells mit jenen von anderen Grundtypen verknüpft. Dadurch sind aus Grundtypen Netze beliebiger Art und Komplexität bildbar. Grundtypen weisen einen Zustand auf (wie "ein", "in Gebrauch", "gelöscht", "suspendiert", "verkauft", "bearbeitet", etc.), der sich verändern kann, Attribute, die Eigenschaften eines Grundtyps definieren, sowie

• Funktionen oder "descriptions", die ein sequentielles Verhalten des Grundtyps als prozessualen Ablauf beschreiben;

• Vorbedingungen oder "preconditions" zur Beschreibung einer Startsituation welche vorliegen muss, damit das Verhalten resp. die Funktion des Grundtyps auslösbar ist; und • Nachbedingungen oder "postconditions" zur Beschreibung einer Endsituation welche nach Ablaufen eines entsprechenden Verhaltens respektive einer Funktion des Grundtyps herrscht.

Während des Ablaufs einer Funktion werden beispielsweise Regeln oder "rules" und mathematische Operationen, die ein Verhalten beschreiben, ausgeführt, und werden Zustände, die vorgegebenen Ausnahmebedingungen oder "exceptions" entsprechen, speziell behandelt.

Beispielhaft wird in der folgenden Art ein Arbeitsprozess beschrieben. Eine Handlungsvorschrift für beispielsweise eine Maschinensteuerung wird in analoger Weise ausgedrückt und in einer geeigneten Syntax programmiert.

Vorbedingung: Eine Anmeldung trifft via Telefon, Fax, eMail ein.

Funktionen:

10 Sämtliche Anmeldungen werden in ein Einheitsformular eingetragen. 20 Die Anmeldungen werden registriert. 30 Die individuellen Einladungen werden aufgearbeitet.

40 Die Teilnehmerliste wird vervollständigt. 50 Die Einladungen werden zum Versand aufbereitet.

Nachbedingungen: eMail-Einladungen, Papier-Einladungen.

Regeln: zu 20 Betrifft die Anmeldung ein Mitglied: zur Einladung Rechnung über Fr. 50 beilegen.

Betrifft die Anmeldung nicht ein Mitglied: zur Einladung Rechnung über Fr. 250 beilegen.

Betrifft die Anmeldung VIP zur Einladung keine Rechnung beilegen. Ausnahmebedingung: zu 30

Ist die Adresse unvollständigreine telefonische Rückfrage wird durchgeführt und die Adresse vervollständigt.

Die verschiedenen Grundtypen sind wie folgt charakterisiert: Der Grundtyp Erzeugen oder "source" erzeugt basierend auf einem Ereignis einen bestimmten Inhalt und stellt diesen an seinem Ausgang einem anderen Grundtyp zur Verfügung. Der Grundtyp selber protokolliert mittels einer Gedächnis- oder Protokollfunktion seine Aktionen. Er weiss dadurch später, welchen Inhalt er aufgrund von welchem Ereignis und zu welchem Zeitpunkt erzeugt hat. Das Ereignis zum Aktivieren eines Ausganges respektive zum Erzeugen eines Inhaltes muss nicht zwingend von Aussen kommen, sondern wird beispielsweise durch einen internen Zeitauslöser generiert.

Der Grundtyp Weiterleiten oder "straight" stellt einen Inhalt, welchen er am Eingang erhalten hat mit oder ohne Veränderung an seinem Ausgang einem anderen Grundtypen zur Verfügung. Der Grundtyp selber weiss immer, welchen Inhalt er zu welchem Zeitpunkt weitergeleitet hat.

Der Grundtyp Verschmelzen oder "merge" vereinigt die Inhalte die er an seinen zwei Eingängen empfangen hat und erzeugt gemäss seinen Regeln einen neuen Inhalt. Diesen Inhalt stellt er an seinem Ausgang anderen Grundtypen zur Verfügung. Der Grundtyp selber weiss immer, welche Inhalte er zu welchem Zeitpunkt wie zusammengeführt hat.

Der Grundtyp Aufteilen oder "split" teilt den Inhalt den er am Eingang empfangen hat und erzeugt gemäss seinen Regeln neue Inhalte. Diese Inhalte stellt er an seinen Ausgängen anderen Grundtypen zur Verfügung. Der Grundtyp selber weiss immer, welche Inhalte er zu welchem Zeitpunkt wie aufgeteilt hat.

Der Grundtyp Aufbewahren oder "störe" speichert den Inhalt den er am Eingang empfängt und kann an seinem Ausgang für andere Grundtypen ein entsprechendes Ereignis zur Verfügung stellen. Das Ereignis beinhaltet beispielsweise die Information "ein Information vom Typ X wurde zum Zeitpunkt Y gespeichert" oder nur einen Zähler "es wurde bisher eine Anzahl Z mal die Information X erhalten". Der Grundtyp selber weiss immer, welchen Inhalt er zu welchem Zeitpunkt gespeichert hat. Als Beispiel für Grundtypen ist beispielsweise eine Darstellung von Prozessen in Figur 7, von Aktivitäten in Figur 9 und von Ereignisketten in Figur 13 gezeigt und weiter unten beschrieben.

OBJEKTE Zur Darstellung eines komplexeren Verhaltens werden mehrere Grundtypen über ihre Ein- und Ausgänge verknüpft und wird die Menge dieser verknüpften Grundtypen als Einheit betrachtet. Eine solche Kombination von Grundtypen wird Objekt genannt. Ein- und Ausgänge einer Untermenge der Grundtypen sind auch Ein- respektive Ausgänge des Objektes, währenddem andere Ein- und Ausgänge innerhalb des Objekts bleiben. Vorzugsweise wird die Vielfalt von solchen Objekten begrenzt, indem eine beschränkte Anzahl von vordefinierten Objekten mit fixer innerer Struktur und entsprechend eingeschränktem aber dafür bewährtem Verhalten verwendet wird, die wiederum miteinander kombinierbar sind.

Figur 2 zeigt eine Bildung eines Objektes 1 aus einer Menge 2 von mehreren Grundtypen. An Schnittstellen 3 des Objektes werden entsprechende Schnittstellen 4 der Grundtypen sichtbar, übrige Schnittstellen der Grundtypen bleiben im Objekt verbogen. Vorbedingungen für das Objekt sind gleich den Vorbedingungen desjenigen Grundtypen, dessen Eingang den Eingang des Objekts bildet.

Nachbedingungen für die beiden Ausgänge des Objekts sind gleich den Nachbedingungen der entsprechenden Grundtypen, deren Ausgänge die Ausgänge des Objekts bilden. Regeln des Objektes sind eine logisch herleitbare Kombination von Regeln der Grundtypen. Umgekehrt lassen sich eine Struktur von Grundtypen und Regeln dieser Grundtypen automatisch aus vorgegebenen Regeln des Objektes herleiten. Anstelle von den ausserhalb des Objektes liegenden Grundtypen können natürlich andere Objekte wie Externe Vertreter treten.

Wird ein Objekt zu komplex, um auf nur einer Ebene von Grundtypen effizient dargestellt werden zu können, so kann es in Objekte aufgeteilt werden, welche wiederum rekursiv aus Objekten oder Grundtypen bestehen. Durch diese Aufteilung, die in der Tiefe nicht limitiert ist, können auch sehr komplexe Zusammenhänge transparent dargestellt werden. Gemäss allgemein bekannten Prinzipien der objektorientierten Programmierung und Modellierung werden spezielle Objekte definiert und verwendet. Jedes solche Objekt erbt die bisher vorgestellten und weitere allgemeine Objekteigenschaften und weist darüber hinaus spezifische Eigenschaften auf. Es benutzt also einen Teil oder alle Definitionen eines allgemeinen Objektes. Weitere allgemeine Objekteigenschaften sind Attribute oder Funktionen zur

• Speicherung von Änderungen des Objekts selber;

• Erfassung und Integration von Daten aus dem modellierten realen Prozess;

• Darstellung von Notizen, Arbeitsanweisungen, Vorlagen, Checklisten und/oder Bewertungen, die das Objekt betreffen;

• Darstellung einer inhaltlichen Qualität des Objekts, beispielsweise Ergebnisse von automatischen Analysen der Vollständigkeit und Konsistenz der Obj ektbeschreibung.

• zur Darstellung von Risiko, Messung, Kosten, Kostenart, Metriken, etc Jede dieser Definitionen stellt in sich selber ein Objekt dar, welches aus den Grundlagentypen konstruiert wurde. Beispielsweise sind im Objekt "Risiko" die Grundtypen in folgender Weise verwendbar:

Grundtyp Verschmelzen: für jede Relation von einem anderen Risiko hält der Grundtyp eine entsprechende Abhängigkeiten fest, nimmt inhaltliche Informationen von diesem anderen Risiko entgegen und bestimmt daraus beispielsweise ein modifiziertes Risiko.

Grundtyp Aufteilen: für jede Relation zu einem anderen Objekt welches ein Risiko besitzt hält der Grundtyp eine Abhängigkeit fest und leitet entsprechende inhaltliche Informationen an dieses andere Objekt respektive an dessen Risikoobjekt weiter. Grundtyp Weiterleiten oder Erzeugen: für jedes Attribut stellt der Grundtyp eine Attributeigenschaft wie eine Tendenz, einen aktuellen Wert, eine Wahrscheinlichkeit, eine Gewichtung, Kosten, etc dar. In der Regel wird ein Grundtyp pro Attribut verwendet, ausser wenn mehrere Attribute in einer Analyse nicht unabhängig ausgewertet werden müssen. Der Grundtyp kann auch die Funktion eines Frühwarnsystems oder Monitors wahrnehmen, der mittels seiner Regeln und/oder Ausnahmebedingungen einen Wert überwacht und dabei einen Wert oder ein Signal bestimmt, das zur Beschreibung eines Risikos benötigt wird, andere Risiken interessieren könnte oder bei einer automatischen Analyse ausgewertet wird.

Eine zum Risiko gehörende Wechselwirkungsart Effekt, die einen gegenseitigen Einfluss oder eine Interdependenz ausdrückt, wird durch den Grundtyp Weiterleiten oder Erzeugen modelliert. Damit wird ein Richtung und eine Stärke des Effekts eines veränderten Risikos auf ein anderes Objekt modelliert.

BETRACHTUNGSEBENEN

Das Modell respektive das modellierte System wird vorzugsweise auf mehreren Ebenen betrachtet, auf denen die vordefinierten Objekte liegen: Das System wird insbesondere in drei Betrachtungsebenen, genannt Prozessebene, Elementebene und Informations- und Funktionsebene unterteilt. Die Prozessebene bildet eine oberste Abstraktion, die Aufgaben und Abläufe sowie deren Zusammenhänge untereinander und zu Partnersystemen darstellt. Die Elementebene repräsentiert die Unterstützung der Prozesse durch technische und/oder organisatorische Einheiten respektive Elemente. Somit wird auf dieser Ebene die gesamte Infrastruktur und Organisation des Systems abgebildet. Auf der dritten und zugleich untersten Ebene, der Informations- und Funktionsebene, werden Funktionen und Informationen der einzelnen Elemente im Detail repräsentiert.

Beispielsweise sei in einem administrativen System eine Ereigniskette " Mitarb eitereinführung" modelliert. Die Ereigniskette durchlaufe in einem Prozess "Personalverwaltung" einen Schritt respektive eine Aktivität "Mitarbeiter- Einführungsgespräch", der eine Datenerfassung beinhaltet. Auf der Prozessebene wird, was diesen Schritt betrifft, nur dargestellt, dass ein Gesprächsprotokoll erstellt wird. Auf der Elementebene ist die Ereigniskette ebenfalls beschrieben, jedoch mit Bezug auf benutzte Elemente, in diesem Fall Softwareapplikationen. Diese Beschreibung besagt beispielsweise, dass das Gesprächsprotokoll mit einer Textverarbeitungssoftware X erstellt, in einem Datenbanksystem Y abgespeichert und mit einem Mailsystem Z an bestimmte Personen übermittelt wird. Eine Repräsentation derselben Ereigniskette auf der Informations- und Funktionsebene beschreibt einen Dateityp und eine vorgegebene innere Struktur des Gesprächsprotokolls, sowie Regeln zur Namensgebung und Ablage der Datei.

In einem anderen Beispiel sei ein Prozess "Druckmaschinenanlage" definiert. In einer realen Druckanlage sind verschiedene Druckstationen, Falz- und Schneidemaschinen auf verschiedene Arten miteinander kombinierbar. Ein einzelner konkreter Druckauftrag "Glückspost herstellen" entspricht einer bestimmten Konfiguration der Anlage und einem bestimmten Papierfluss durch die Anlage, und wird durch eine Ereigniskette repräsentiert. Der konkrete Druckauftrag beansprucht ganz bestimmte Einzelmaschinen, die durch Elemente repräsentiert werden. Eine bestimmte Maschine wiederum wird nach Massgabe von Maschinenparametern und Regelfunktionen gesteuert, welche auf der Informations- und Funktionsebene modelliert werden.

In einem weiteren Beispiel werde eine Produktkomponente modelliert. Auf Prozessebene wird sie beispielsweise durch ein Objekt als Produkt "Komponentenlieferung" modelliert, auf der Elementebene durch ein Objekt als Produkt "Autotüre links", und auf der Informations- und Funktionsebene hält ein entsprechendes Objekt fest, wo und wie Daten zur Beschreibung der Autotüre gespeichert sind.

Die Zusammenhänge zwischen den einzelnen Ebenen, also der Sachverhalt, dass ein Prozess oder eine Ereigniskette durch bestimmte Einzelmaschinen unterstützt wird, und dass diese wiederum bestimmte Informationen und Funktionen benötigen, wird durch Unterstützungsbeziehungen modelliert. Dadurch sind beispielsweise Steuerparameter einer Maschine über die Maschine mit einem Druckauftrag assoziiert. Somit können Steuerparameter für einzelne Druckaufträge individuell spezifiziert werden. Entsprechend kann, ausgehend von beispielsweise einer Prozesssicht, durch Verfolgen der Beziehungen, ermittelt werden, welches konkrete Parameter sind und können diese geändert werden. Dies ergibt eine "drill-down" Funktionalität, das heisst, dass bei Bedarf, von einer allgemeinen Übersichtsdarstellung ausgehend, auf beliebig detaillierte Informationen des Systems zugegriffen werden kann.

BETRACHTUNGSSEGMENTE

Orthogonal zu den Betrachtungsebenen sind Betrachtungssegmente definiert. Diese sind als "Führungsebene", "Wertschöpfungsebene" und "Unterstützungsebene" bezeichnet. Jedes dieser Segmente kann Objekte der Prozessebene, Elementebene und der Informations- und Funktionsebene enthalten.

Die Wertschöpfungsebene beinhaltet Prozesse, Elemente etc., die zur Wertschöpfung einer Organisation oder einer Anlage beitragen, also direkt an der Erzeugung oder Bearbeitung eines Produkts beteiligt sind. Dies sind also Fabrikationsstrassen, Maschinen, Aussendienstabteilungen etc. mit zugeordneten Prozessen, Daten und Verfahren.

Die Unterstützungsebene beinhaltet Prozesse, Elemente etc., die zur Unterstützung der Abläufe auf der Wertschöpfungs- und Führungsebene dienen. Diese gehören beispielsweise zu einer Informatikabteilung, einer Personalverwaltung, einem Hochregallager, einer Rohstoffbeschaffung etc.

Die Führungsebene beinhaltet Prozesse, Elemente etc. die zur Führung der Wertschöpfungs- und Unterstützungsebene dienen. Dies sind insbesondere Managementfunktionen wie Betriebsführung, Controlling mit entsprechenden Organisationen, Informatikmitteln etc.

Durch die Aufteilung in diese Betrachtungssegmente und durch die Zuordnung von Kosten und Unterstützungsgraden lässt sich ermitteln, welche Einheiten in welchem Grade und mit welchem Aufwand zu einem Produkt und gegebenenfalls einem Profit beitragen. Figur 3 zeigt eine Darstellung eines Systems mit Modellellementen auf einer obersten Modellierungsebene oder Abstraktionsebene, beispielsweise auf der Prozessebene. Es sind einzelne Prozesse P1...P6 auf den drei Ebenen wie auch die Beziehungen zwischen den einzelnen Prozessen dargestellt. Mit EA1..EA6 sind sogenannte "Externe Vertreter" bezeichnet. Die Prozesse Pl, P2 liegen in der Führungsebene, die Prozesse P3, P4 und P5 in der Wertschöpfungsebene und der Prozess P6 in der Unterstützungsebene. Im Folgenden werden Prozesse und Externe Vertreter beschrieben:

PROZESSE

Ein Prozess ist eine zusammenfassende Darstellung einer definierten Gesamtheit von Aufgaben und Aktivitäten oder Abläufen und Entscheidungen. Ein Prozess hat bestimmte Eigenschaften und ein Verhalten und weist eine Anzahl von Grundlagentypen auf, die individuell zu einem Objekt kombiniert werden. Ein Prozess kann in Subprozesse aufgeteilt sein. Ein Prozess ist immer ein Bestandteil eines Prozessmodells und bildet auf jeder der drei Betrachtungsebenen eine oberste Abstraktionsstufe zur Beschreibung der Betrachtungsebenen. Ein Prozess erhält Input respektive Daten von anderen Objekttypen wie Prozessen oder Externen Vertretern und produziert Output respektive Daten für solche Objekttypen. Dieser Input und Output bilden eine Charakterisierung des Prozesses und von Qualität, Performance und Zusatznutzen ("added value") des Prozesses. Jeder Prozess weist Attribute zur Beschreibung von Kosten, Risiken, Messkennzahlen, Nutzen, Qualität, Anweisungen, Erfahrungswerten etc. auf. Alternativ dazu sind solche Informationen durch jeweils spezielle Beschreibungsobjekte anstelle von Attributen beschrieben.

Eine Beschreibung der von einem Prozess ausgetauschten Daten, das heisst Input und Output des Prozesses, wird als "Service Level Agreement" (SLA) oder Prozessschnittstellenbeschreibung bezeichnet. Das SLA ist eine Arbeitsmittel das zwischen zwei vordefinierten Objekten transportiert wird und somit der Beschreibung einer Schnittstelle entspricht und diese definiert.

Beziehungen eines Prozesses zu anderen Modellentitiäten beschreiben beispielsweise wechselseitige Abhängigkeiten von Risiken, Kosten, Beanspruchung oder Unterstützung, sowie Zusammenhänge mit einem Projekt, einer Ereigniskette, Planungszielen etc.

Zur semantisch und syntaktisch korrekten und vollständigen Beschreibung eines Prozesses wird vorzugsweise, ein vordefiniertes Objekt Aktivität verwendet. Auch eine Aktivität ist eine erweiterte Instanz eines allgemeinen Objekts, mit einer Untermenge der allgemeinen Objekteigenschaften und mit spezifischen Eigenschaften. Einem Prozess sind eine oder mehrere Aktivitäten zugeordnet....

Auf der rechten Seite der Figur 8 ist eine solche Beschreibung mittels eines Aktivitätendiagramms beispielhaft mit verschiedenen Typen von Aktivitäten Sequenz, Einzelschritt, Aufteilung, Nerzweigung, dargestellt. Die Darstellung beschreibt, in aus der Computertechnik bekannter Weise, einen Ablauf oder Kontrollfluss innerhalb eines Prozesses oder einer Ereigniskette.

EXTERNE VERTRETER

Liegt ein Objekt ausserhalb eines Betrachtungsrahmens respektive ausserhalb eines bestimmten Prozessmodells, so wird dieses Objekt "Externer Vertreter" oder auch

Partnerobjekt oder Fremdkomponente genannt. Ein Externer Vertreter ist wie ein

Prozess eine Instanz eines Objektes mit allgemeinen sowie spezifischen

Eigenschaften und Verhalten. Wird ein Prozess aufgeteilt und dadurch in

Subprozesse zerlegt, so entstehen damit neue, vom Standpunkt des Subprozesses aus gesehene Externe Vertreter. Eine derartige Zerlegung 5 ist in Figur 3 verkleinert gezeigt und in der Figur 4 vergrössert dargestellt: P3 ist aufgeteilt in P3.1 bis P3.4, und aus den Prozessen P2, P4 und P6, die auf der höheren Ebene gemäss der Ansicht von Figur 3 noch Prozesse waren, sind aus Sicht der Subprozesse von P3 Externe

Agenten entstanden. Externe Agenten können also je nach Kontext andere vordefinierten Objekte repräsentieren.

In einer weiteren Anwendung von Extern Agenten repräsentiert ein Externe Agent in einem ersten Modell ein komplettes anderes, zweites Modell. Dies bedeutet er vereinigt alle Eigenschaften und Verhalten eines Modells. Der externe Agent kann somit ein Repräsentant für viele verschiedene Objekte oder Objektmengen sein. Zum Beispiel:

• Ein Externer Agent "Markt" stellt einen Platzhalter für eine weiter nicht modellierte Entität dar.

• Ein Externer Agent "Partner" repräsentiert einen modellierten Prozess, durch welchen der "Partner" eine Rolle durch Outsourcing übernommen hat und direkt in eine Prozesskette eingebunden wird. • Ein Externer Agent "Abteilung" entspricht einem kompletten Teil eines Gesamtsystems, das in einem bestimmten Zusammenhang nicht im Detail interessiert. Der Externe Agent wird als Repräsentant anschliessend normalerweise mittels Flussbeziehung mit einem Objekt innerhalb einer Modellgrenze verbunden.

EREIGNISKETTE

Eine Ereigniskette repräsentiert einen wiederkehrenden Handlungsablauf innerhalb des Systems. Je nach Kontext werden Ereignisketten auch als Geschäftsvorfall, als "Use-Case" bezeichnet, als Wertschöpfungskette oder als "Business Value Chain".

Die einzelnen Schritte in einer Ereigniskette sind Aufgaben und Prozessschritte, die in einer Reihenfolge und mit gewissen Ausprägungen, ablaufen. Ein Datenfluss eines

Geschäfts Vorfalles beschreibt immer, woher und wohin eine bestimmte Information fliesst. Neben den grundlegenden Objektdefinitionen besitzt ein Objekt Ereigniskette die Besonderheit, dass es eine Kante und nicht einen Knoten eines Netzwerks, darstellt. Entlang dieser Kante oder Kette wird beispielsweise ein Produkt verarbeitet oder gefertigt. Allgemein betrachtet entsteht entlang einer Ereigniskette ein

Mehrwert. Zur Darstellung von dabei ablaufenden Veränderungen wird die

Ereigniskette in Teilflüsse oder Teilketten unterteilt, gemäss welchen einzelne

Produkte oder Arbeitsmittel manipuliert werden. Die einzelnen Teilflüsse sind

Prozessen und/oder Aktivitäten zugeordnet. Die Ereigniskette ist mittels Aktivitäten darstellbar respektive definierbar.

Zusammengefasst gesagt stellt ein Prozess einen Teil eines Systems dar, der in allgemeiner Weise zu verschiedenen Handlungen fähig ist, währenddem eine Ereigniskette oder eine Aktivität einmalig ausgeführte Handlungen bezogen auf einen konkreten Vorfall darstellen.

In der Figur 5 sind mehrere Modellaspekte überlagert dargestellt: Prozesse sind durch Ovale, Aktivitäten durch horizontale abgerundete Rechtecke, und Ereignisketten durch dicke Pfeile symbolisiert. Vertikale abgerundete Rechtecke repräsentieren Elemente, die weiter unten erklärt werden. Figur 5 zeigt also zwei Ereignisketten, deren einzelne Teilflüsse immer mit einem Prozess oder mit einer Aktivität innerhalb eines Prozesses korrelieren. Es können dabei auch mehrere Teilflüsse einer Kette demselben Prozess oder derselben Aktivität zugeordnet sein. Elemente können mehrere Prozesse unterstützen, und ein Prozess kann durch mehrere Elemente unterstützt sein. Dies entspricht dem Sachverhalt, dass beispielsweise eine Fertigungszelle für mehrere Herstellungsprozesse verwendet werden kann, und umgekehrt. Weiter ist sichtbar, wie gewisse Teilflüsse einer Ereigniskette vollständig innerhalb eines Prozesses ablaufen, und andere nur Verbindungen zwischen Prozessen repräsentieren.

ELEMENTEBENE

Ein weiteres spezielles vordefiniertes Objekt stellt das Element dar. Ein Element stellt dar, wie ein Prozess oder eine Aktivität durch reale Entitäten unterstützt wird. Vorzugsweise werden vier Typen von Elementen verwendet: 1. Informationstechnologie (IT), 2. Organisation, 3. Werkzeuge, und 4. mechanisch-elektronische Module.

In der Figur 5 wird diese Unterstützung von Prozessen und Aktivitäten durch ein oder mehrere Elemente (vertikale abgerundete Rechtecke) dargestellt. Indirekt wird also auch eine Ereigniskette durch ein oder mehrere Elemente indirekt unterstützt. Dabei muss die Ereigniskette auf der Prozessebene und diejenige auf der Elementebene nicht gleich unterteilt sein und müssen auch nicht die gleichen Arbeitsmittel dabei verwendet werden. Wesentlich ist aber, dass all die erwähnten Objekte in einer definierten Beziehung zueinander stehen, das heisst, dass durch entsprechende Beziehungen dargestellt wird dass eine bestimmte Ereigniskette aus bestimmten Aktivitäten besteht und diese wiederum bestimmten Prozessen und Elementen zugeordnet sind. .

INFORMATIONS- UND FUNKTIONSEBENE

Die Informations- und Funktionsebene modelliert Einheiten, welche die Elemente unterstützen. Dies sind insbesondere informationstechnische Einheiten wie Daten und Verfahren, und zwar sowohl Daten, welche die Realität im System abbilden, als auch Metainformation über diese Daten. Daten sind beispielsweise Werte von in Datenbanken oder Programmen gespeichert Attribute oder Variablen, sowie Messwerte und Steuerparameter von Anlagen und Maschinen. Metainformationen beschreiben eine Bedeutung von Daten, Datenstrukturen, Datenbankstrukturen, Ablageinformationen, logische Zusammenhänge oder Berechnungsvorschriften zu Umwandlung von Daten. Verfahren beschreiben Prozeduren oder Programme zu Datenverarbeitung und/oder Maschinensteuerung.

BEZIEHUNGSTYPEN

Grundtypen und Objekte werden untereinander in Beziehung gesetzt. Dabei verwendete Beziehungstypen definieren ein Verhalten von zwei in Beziehung stehenden Objekten respektive Grundtypen. Beziehungstypen werden selber auch als Objekte modelliert. Es werden dabei vier Beziehungstypen unterschieden, die anschliessend detailliert beschrieben werden:

a) Stehen zwei Objekte dauernd in Beziehung so wird der Beziehungstyp beständig oder "permanent" zur Beschreibung verwendet. Diese Beziehung entspricht einer gegenseitigen Referenz gleichzusetzen.

b) Löst ein Objekt bei einem anderen Objekt eine Reaktion aus, so wird der Beziehungstyp Wechselwirkung oder "interaction" verwendet. Hiermit können definierte Wirkungen bei einem andern Objekt erzielt werden.

c) Zur Darstellung einer dynamischen Situation wird der Beziehungstyp Fluss oder "flow" verwendet. Hiermit wird dargestellt, dass nicht nur eine Wirkung, sondern auch Inhalte zwischen Objekten in einem bestimmten Zustand verschoben werden.

d) Wird bei einer Verbindung zweier Objekte eine jeweilige Funktionalität dieser Objekte zueinander in Beziehung gesetzt, so wird der Beziehungstyp Differenz oder "Gap" Beziehung definiert.

Der Beziehungstyp "beständig": Es werden zwei beständige Beziehungstypen unterschieden, eine statische- und eine Umwandlungsbeziehung.

Eine statische Beziehung oder "static" stellt eine ständige gegenseitige Beziehung zwischen zwei Objekten dar. Beispielsweise wird eine gegenseitige Referenz zweier Objekte durch eine statische Beziehung repräsentiert. Dabei werden in beiden Objekten Zeiger auf das andere Objekt beispielsweise als navigierbarer Link instanziert und beispielsweise mit dem Namen des anderen Objektes verknüpft. Diese gleiche Art Beziehung wird auch verwendet, wenn ein Objekt mit einem anderen Objekt in einer statischen Korrelation oder "correlation" steht und diese Tatsache beständig aufgezeigt werden soll.

Die Umwandlungsbeziehung oder "Exchange" stellt eine Beziehung zwischen zwei unterschiedlichen vordefinierten Objekten dar, die festen Regeln, gemäss beispielsweise einer Typenwandlung, folgt. Es wird dabei ein Objekt umgewandelt in ein oder mehrere Objekte eines anderen vordefinierten Typs. In welchem Verhältnis und unter Anwendung welcher Regeln die Objekte zueinander stehen, wird in den jeweiligen betroffenen Objekten festgehalten. Über diese Beziehung kann nach der Instanzierung navigiert werden, und die in Beziehung stehenden Objekte kennen die Art der Umwandlung sowie die Details des jeweils anderen Objekts.

Beispielsweise stellen Umwandlungsbeziehungen dar, dass ein bestimmter Prozess mehrere bestimmten Aktivitäten aufweist. Ein Prozess "Fertigung" weist beispielsweise eine Menge von Aktivitäten wie "Produkt A fertigen", "Zwischenprodukt beschaffen" etc. auf. Diese wiederum sind jeweils einer oder mehreren Ereignisketten zugeordnet, was ebenfalls durch Umwandlungsbeziehungen dargestellt wird. Ein Prozess "Personalverwaltung" weist beispielsweise Aktivitäten "Mitarbeiter einstellen", "beurteilen", "entlassen".

Andere Umwandlungsbeziehungen stellen beispielsweise einen Zusammenhang zwischen einem Produkt und zwischen Serviceleistungen dar, die als Produkt betrachtbar sind. Der Beziehungstyp "Wechselwirkung " :

Bei einer Wechselwirkungsbeziehung nimmt ein Objekt auf ein anderes in irgendeiner Form Einfluss oder steht in einer Abhängigkeit von diesem. Es entsteht aber nicht ein eigentlicher Fluss von Inhalten zwischen diesen Objekten, sondern die Beziehung selber beschreibt eine bestimmte, bekannte Art der Einflussnahme. Das eine Objekt nimmt aufgrund seiner Eigenschaften und seines Verhaltens Einfluss auf das andere. Vorzugsweise werden fünf verschiedene Arten von Wechselwirkung unterschieden:.

Eine Wechselwirkungsart Einfluss oder "Influence" stellt eine prozentuale Abhängigkeit zwischen zwei Objekten dar, insbesondere einen prozentualer Verteilschlüssel oder Abhängigkeits-Schlüssel. Beispielsweise hält eine Einflussbeziehung fest, dass ein bestimmtes Leistungs- oder Produktionsziel wie "weniger als 2% Ausschuss" oder "weniger als 5% Fluktuation" einem Prozess, beispielsweise der "Fertigungsabteilung" zugeordnet wird. Die Zuordnung geschieht durch beispielsweise ein Strategieobjekt. Ein Strategieobjekt verteilt also Ziele an andere Objekte, zwecks späterer Kontrolle der Zielerreichung.

Eine Wechselwirkungsart Unterstützung oder "Support" stellt eine prozentuale Abhängigkeit oder einen Verteilungsschlüssel mit vorgegebenen Regeln und Definitionen zwischen Eigenschaften zweier Objekte dar. Dieser Beziehungstyp ist speziell interessant, wenn sich vordefinierte Objekte auf unterschiedlichen Betrachtungsebenen befinden. Dann ist eine mehr oder weniger starke Abhängigkeit oder Kopplung der Ebenen darstellbar oder sichtbar. Beispielsweise stellen Unterstützungsbeziehungen dar, dass 60% von total verfügbaren Informatikmitteln oder -Services und 50% der Arbeitsleistung eines Verwalters zur Unterstützung einer bestimmten Produktionsabteilung notwendig sind. In einem anderen Beispiel stellen sie dar, dass ein Fertigungsprozess 30% einer NC-Maschine und 40% einer bestimmten Fertigungszelle benötigt.

Eine Wechselwirkungsart Effekt oder "Effect" stellt eine Wirkung durch Auslösen einer Reaktion basierend auf festen Regeln und Definitionen dar. Ein Verfahren oder ein Algorithmus zur Bestimmung der Reaktion ist in dem Objekt definiert, in welchem die Wirkung stattfindet. Die Wirkung findet bedingungslos statt, die Reaktion je nach Ergebnis dieses Verfahrens. Beispielsweise wirkt ein erstes Objekt durch Vermittlung von Werten für Risiko, Performance, Kosten, Qualität, Erfüllungsgrad etc. auf ein zweites. Das zweite Objekt bestimmt gemäss ihm eigenen Verfahren beispielsweise ein Gesamtrisiko oder ein Prozessrisiko etc.

Die Beziehung ist einseitig, in dem Sinne, dass die Wirkung nur in einem Objekt stattfindet und das auslösende Objekt nicht tangiert wird. Demzufolge muss zur Modellierung einer gegenseitigen Wirkung eine zweite Beziehung in entgegengesetzter Richtung instanziert werden.

Eine Wechselwirkungsart Wechsel oder " Change " stellt eine Wirkung dar, mit der eine Veränderung nach frei oder fest definierbaren Regeln erfolgt. Dabei weiss ein Objekt, welches eine Botschaft übermittelt, nicht, ob und wie diese Botschaft beim empfangenden Objekt verarbeitet wird. Die Art der Botschaft ("Messdaten", "Fehlerparameter" etc.) ist jedoch im Voraus bekannt. Beispielsweise werden mit dieser Wechselwirkungsart dargestellt:

• eine Übermittlung von Messwerten an einen Regler;

• nach Auslösen eines Fertigungsauftrags für ein Produkt werden mehrere betroffene Fertigungseinheiten angestossen;

© eine optische Fehlererkennung respektive das zugeordnete Modellobjekt übermittelt Fehlerdaten an eine Fertigungsstrasse, je nach Fehlerart werden Teile nachbearbeitet, wenn zu viele Fehler auftreten, wird eine betroffene Maschine justiert;

• eine Anzahl demotivierten Mitarbeitern wird übermittelt. Wenn ein bestimmter Anteil von Mitarbeitenden demotiviert ist, werden Stelleninserate ausgelöst; • bei Einstellung eines neuen Mitarbeiters wird entsprechende Wechselinformation an verschiedene Objekte gesendet, welche darauf beispielsweise automatisch ein Stellenprofil erzeugen, ein e-mail-Konto einrichten, ein Eintrittsgespräch veranlassen etc.

Eine Wechselwirkungsart Verbinden oder "Join" stellt eine Vermittlung von Zielen oder Leistungsmerkmalen wie Risiko, Kosten, und verschiedene messbare Grossen dar. Die Ziele werden von einem übergeordneten Objekt mittels dieser Wechselwirkungsart auf mehrere untergeordnete Objekte heruntergebrochen oder verteilt, d.h. jedes der untergeordneten Objekte erhält dadurch ein eigenes Teilziel, das es zu erfüllen hat und das zur Beurteilung mit tatsächlichen Ergebnissen verwendbar ist.

Der Beziehungstyp "Fluss ":

Bis jetzt wurden nur statische Beziehung definiert, über welche Abhängigkeiten oder Berechnungen erstellt werden können. Die Art der Beziehung und der vermittelten Information war immer im Voraus bekannt. Die nachfolgenden zwei Definitionen definieren Abhängigkeiten bei dem ein Fluss dargestellt werden soll, wobei der wesentliche Unterschied zum Bisherigen darin liegt, dass zwischen zwei vordefinierten Objekten ein Inhalt verschoben wird, dessen Verarbeitung etwas Unvorhergesehenes auslösen kann. Dieser Inhalt entspricht wieder einem vordefinierten Objekt. Mittels dieser Flussbeziehungen lassen sich dynamische und inhaltliche Abhängigkeiten darstellen.

Eine Abhängigkeitsart Inhalt oder "Content" stellt eine inhaltliche Beziehung zwischen zwei vordefinierten Objekten dar, wobei ein übermittelter Inhalt, beispielsweise eine Datei, je nach Interpretation durch das empfangende Objekt eine Reaktion auslöst. Die Inhaltsbeziehung stellt also eine dynamische Verbindung auf unterschiedlichen Detaillierungsebenen dar. Bei einer Abhängigkeitsart Ereignis oder "Event" stellt der Inhalt nur einen Auslöser dar. Im Gegensatz zu einer Wechselbeziehung ist jedoch der Inhalt durch das empfangende Objekt definiert und vorgegeben.

Der Beziehungstyp " Differenz " :

Eine Differenzbeziehung stellt Unterschiede zwischen zwei vordefinierten Objekten dar und macht sie nachvollziehbar. Beispielsweise stellen die beiden Objekte einen Ist-Zustand und einen Soll-Zustand eines Systems dar, die Differenzbeziehung die Unterschiede zwischen den beiden Zuständen.

Als Übersicht ist im Folgenden für die verschiedenen Beziehungstypen angegeben, zwischen welchen Objekten sie vorzugsweise verwendet werden. Wichtige Beziehungstypen sind insbesondere die statische Beziehung, Einflussbeziehung und Inhaltsbeziehung.

Beziehungstyp Beteiligte Objekte

Beständig

- statisch alle Typen

- Umwandlung Prozess - Aktivität, Element - Interface, Interface - Service,

Service - Parameter

Wechselwirkung

- Einfluss Strategie - Objekt, Anforderung - Objekt

- Unterstützung Prozess - Element, Prozess - Ereigniskette, Aktivität -

Ereigniskette

- Effekt Interdependenz Risiko, Personelles, Kosten, andere

- Wechsel Target - Risk, Target - Measurement

- Verbinden Risiko, Messung, Anbindung

Fluss

- Inhalt Prozess - Externer Agent, Prozess - Prozess, Ereigniskette

- Objekt; wenn Inhalt transportiert wird

- Ereignis Prozess - Externer Agent, Prozess - Prozess, Ereigniskette

- Objekt; wenn nur Auslöser definiert wird

Differenz alle Typen, über compare & merge - Verbindungen

PRODUKT

Es werden zwischen drei Arten von Produkten unterschieden, die alle einen oder mehrere Zustände einnehmen können: Ein Produkt selbst, als höchste Abstraktion, sowie ein Arbeitsmittel und ein Ergebnis. Das Arbeitsmittel repräsentiert alle Arten von Inhalten, die in Zusammenhang mit der Unternehmensentwicklung und Prozessführung verwendet werden. Das Arbeitsmittel stellt auch die kleinste Einheit eines Produktes dar. Arbeitsmittel können isoliert oder in verschiedenen anderen Kombinationen vorkommen und können in unterschiedlichen Ebenen und verschiedenen Kombinationen entstehen. Ein Arbeitsmittel kann also beispielsweise ein physischer Teil eines Produktes sein, aber auch eine computerlesbare Datei respektive die darin enthaltene Information. Eine Menge von Arbeitsmitteln definiert ein Elementarprodukt. Das Elementarprodukt kann mit anderen Elementarprodukten zu einem (zusammengesetzten) Produkt oder "composite product" kombiniert werden. Ein Objekt "Produkt" repräsentiert eine zusammenfassende und/oder wechselnde Sicht mehrere Arbeitsmittel. Beispielsweise ist dies die Tatsache, dass ein Gegenstand aus einer Menge von Komponenten besteht respektive hergestellt wird, oder dass eine chemische Verarbeitung von Eingangsstoffen einen Ausgangsstoff ergibt, oder dass eine Aufstellung über Hard- und Softwarekosten auf einer anderen Betrachtungsebene als Gemeinkosten und wieder einer anderen Ebene als Investitionen betrachtet werden. .

ZUSAMMENFASSUNG Die bisher definierten Objekte stehen in einem Modell in verschiedenen Abhängigkeiten zueinander. Diese Abhängigkeiten sind in der Figur 6 in einer Übersicht für ein beispielhaftes Modell dargestellt. Ein Prozessmodell besteht aus Prozessen P1-P6 die mittels Flussbeziehungen miteinander verbunden sind. Besteht eine Beziehung über die Modellgrenze hinaus, erfolgt diese zu einem Externen Vertreter EA1-EA6. Über diese Beziehungen fliessen Arbeitsmittel oder Produkte in einem definierten Zustand. Alle diese Objekte können aufgeteilt (Prozess in Subprozess) oder mittels eines anderen Objekttyps beschrieben werden (Prozess durch Aktivität), was durch entsprechende Beziehungen darstellbar ist. Die Prozesse P1-P6, Externen Vertreter EA1-EA6 sowie Aktivitäten werden durch Elemente eines vordefinierten Typs unterstützt. Mit Prozessmodellen werden Aufgaben und Abläufe sowie Zusammenhänge charakterisiert, mit dem Elementmodell die Infrastruktur- und Organisationsunterstützung, und mit dem Informations- und Funktionenmodell spezifische Details. Diese drei Modelle bilden zugleich auch Betrachtungsebenen. Eine dreidimensionale Darstellung 9 visualisiert das Vorhandensein von Betrachtungssegmenten als auch Betrachtungsebenen. Um konkrete Anwendungsfälle und deren Wertveränderungen zu dokumentieren, können Ereignisketten 6 auf Stufe Prozess, Aktivität oder auf Stufe Element definiert werden. Die einzelnen Teilflüsse der Ereigniskette 6 werden mit den entsprechenden Objekten einer bestimmten Betrachtungsebene verbunden respektive in Beziehung gebracht. Das vordefinierte Objekt Ereigniskette stellt also spezifische Abläufe dar und kann auf allen Betrachtungsebenen verwendet werden. Es wird im Detail beispielsweise durch ein Aktivitätendiagramm 7 dargestellt. Aktivitätendiagramme sind auch zur Darstellung von Abläufen 8 innerhalb von Prozessen verwendbar. Ereignisketten bilden zusätzlich zu den Modellen eine zusätzliche Dimension und verknüpfen Objekte und Ebenen. Dadurch werden verschiedenen Analysen und Berechnungen vereinfacht oder überhaupt ermöglicht. Ferner wird das Produktmodell verwendet und das Projektmodell, welches sämtliche Veränderungen zwischen zwei Zeitpunkten abbildet.

Die Modellierungsprinzipien sind im Folgenden anhand eines sehr einfachen Beispiels dargestellt: Figur 7 zeigt vordefinierte Objekte Externer Vertreter EA und Prozesse PA.PB, sowie als Pfeile dargestellte gerichtete Beziehungen, und Arbeitsmittel 10, die für die Definition der Beziehungen relevant sind. Ferner ist eine Verwendung der Grundtypen in einer detaillierteren Darstellung des Externen Vertreters EA und in den Prozessen PA.PB abgebildet. Abhängig von der Instanzierung und den Eigenschaften ist die Komplexität grösser oder kleiner. Dies ist im Externen Vertreter EA durch die Verwendung von nur gerade zwei Grundtypen ausgedrückt. Würde ein gewisses Mass an Komplexität überschritten, so würden anstelle dieser Grundtypen verschiedene vordefinierten Objekte verwendet.

In der Figur 8 wird Prozess PB alternativ zu der Darstellung durch Grundtypen durch ein Aktivitätendiagramm definiert. Da es sich bei Aktivitäten wiederum um vordefinierte Objekte, handelt, weisen sie auch eine definierten Menge von Grundtypen auf, respektive sind durch diese ausgedrückt. Figur 9 zeigt eine vergrösserte Version des Aktivitätendiagramms, mit Verzweigungen, parallelen Pfaden, Sequenzen etc. und beispielhaft einer Darstellung einer einzelnen Aktivität durch eine Menge von Grundtypen.

In der Figur 10 sind die Arbeitsmittel 10 die über die Beziehungen verschoben werden, detailliert dargestellt. Ein Produkt 10 respektive ein Arbeitsmittel 10 kann wiederum aus mehreren anderen Arbeitsmitteln 11 bestehen, was über eine entsprechende objektorientierte Softwaredefinition darstellbar ist. Aus dieser Abbildung ist ebenfalls ersichtlich, dass die Arbeitsmittel zugleich auf der einen Seite den Output und auf der andern Seite den Input von Prozessen darstellen.

Bis zu diesem Punkt sind im Beispiel noch keine konkreten Anwendungsfälle definiert worden, sondern nur das ganze System, welches ein Potential zur

Bearbeitung von Anwendungsfällen aufweist. Mit Ereignisketten werden konkrete Anwendungsfälle dargestellt, die in der Praxis auftreten können und ein kleineren 83982

- 34 - oder grösseren Teil des Systems beanspruchen. In der Figur 11 ist eine solche Ereigniskette durch gestrichelte Pfeile dargestellt. Daraus ist ersichtlich, dass oft nur ein Teil der Systemdefinition, also beispielsweise der Prozesse und Aktivitäten, in einer bestimmten Ereigniskette Verwendung findet.

Basierend auf den eingeführten Modellelementen und -zusammenhängen aufgrund der vordefinierten Objekte können die im Folgenden beschriebenen weiteren Verfahren, Analysen und Berechnungen durchgeführt werden. Es wird dabei im Folgenden eingegangen auf

• Automatische Modellgenerierung und -aufdatierung; • Qualitätsprüfung von Modellen;

• Risikoanalysen

• Analyse von Kosten und deren Beziehungen; β Performancebewertung;

• Vergleich von Modellen respektive dargestellten Systemen; * Prozessteuerung; und

• Benutzerschnittstellen.

MANUELLE UND AUTOMATISCHE MODELLBILDUNG

Um ein konkretes System, also ein Fabrikationssystem oder ein Unternehmen oder eine Organisation darzustellen, werden verschiedene Informationen erhoben und als Instanzwerte vordefinierter Objekte abgebildet, und werden Zusammenhänge der Objekte ebenfalls im Modell dargestellt. Diese Informationserfassung geschieht manuell und/oder automatisch.

Bei der manuellen Erfassung werden vorzugsweise Ikonen, welche die Objekte darstellen, durch bekannte Zeigemittel wie eine Computermaus auf einem Bildschirm plaziert. Beziehungen werden durch Verbinden der Ikonen eingegeben. Zur Spezifikation respektive Instanzierung von Attributen sind beispielsweise zu jedem Objekt Eingabemasken darstellbar, welche Textfelder, Menülisten und andere bekannte Eingabehilfsmittel aufweisen. In einer bevorzugten Ausführungsform der Erfindung werden Objekte in einer Baumstruktur dargestellt und manipuliert. Vorzugsweise wird dabei folgendermassen vorgegangen: Als erstes werden Prozessmodelle erstellt, anschliessend werden Ereignisketten auf die Prozessebene gelegt, und werden diese Ketten durch Aktivitäten spezifiziert. In analoger Weise wird auch die Spezifikation der Prozesskontrollflüsse erstellt. Parallel zu diesen Prozessarbeiten werden auch Produktdefinitionen erstellt. Die Produktdefinitionen werden speziell bei Beziehungen zwischen zwei Objekten verwendet. Ist die Prozessebene vervollständigt, wird die Elementebene kreiert. Die benötigten Elementtypen werden erzeugt und in die korrekte Abhängigkeit zu den Prozessen und zueinander gestellt.

Mit diesen Schritten wird ein konkretes Elementmodell erzeugt. Die einzelnen Elemente werden anschliessend mit den Objekten auf der Prozessebene verknüpft. Anschliessend werden die Ereignisketten auf der Elementebene erfasst. Als letzte Ebene wird die Informations- und Funktionsebene kreiert und mittels spezieller vordefinierter Objekte beschrieben. Diese Objekte sind vorzugsweise speziell auf die Darstellung von Informatikgrundlagen respektive Daten und Funktionsbeschreibungen ausgerichtet. Sie beschreiben also beispielsweise Datenstrukturen, Zugriffsbeziehungen, Einzeldaten und ihre Bedeutung, Schnittstellen etc.

Die automatische Erfassung erfolgt durch spezielle Analyseprogramme, welche eine bestehende informationsverarbeitende Struktur oder Anlage durchsuchen, Zusammenhänge zwischen datenverarbeitenden und/oder datenspeichernden Einheiten ermitteln und verschiedene Arten von Objekten und Beziehungen zur Abbildung dieser Daten und Zusammenhänge im Modell erstellen. In einer bevorzugten Variante der Erfindung wird dabei das folgende Verfahren verwendet: Eine Informatiklandschaft oder ein Softwaresystem weise mehrere Verarbeitungseinheiten, das heisst Programme und/oder Datenbanken auf, wobei die Programme durch Aufrufe miteinander und den Datenbanken verknüpft sind.

Das Verfahren liest systematisch den Code aller Programme, beispielsweise einen COBOL-Quellcode, und hält in jedem Programm fest, welche anderen Programme mit welchen Übergabeparametern und welchen Resultaten aufgerufen werden. Ebenso wird festgehalten, auf welche Datenbanken und gegebenenfalls auf welche Tabellen der Datenbanken mit welchen Abfragen und Resultaten zugegriffen wird. Ebenso werden innere Verknüpfungen der Datenbanken erfasst. Das Verfahren wird rekursiv auf jedes Programm und jede Datenbank angewendet, bis alle durchlaufen sind und damit alle existierenden Verknüpfungen durch Aufrufe respektive Abfragen erfasst sind. Während der Erfassung werden in einem Modell automatisch Objekte zur Darstellung der jeweils gefundenen Programme, Datenbanken und Verknüpfungen erzeugt. Dafür werden vorzugsweise die vordefinierten Objekte Element, Interface und Arbeitsprodukt verwendet. Je nach Objekttyp wird der Scanner konfiguriert und füllt alle Objekte und Beziehungen zwischen den Objekten gemäss Definition ab. Beispielsweise werden ein reales Programm und eine Datenbank je durch Objekte dargestellt, Datenbankabfragen durch Beziehungstypen, und Resultate von Datenbankabfragen durch Arbeitsprodukte.

Die gefundenen Elemente und Verknüpfungen definieren einen Graphen. Dieser wird visuell, beispielsweise als Graph mit Knoten und Kanten, oder als Verknüpfungsmatrix dargestellt. Damit entsteht eine anschauliche Darstellung der Abhängigkeiten, die insbesondere kritische Komponenten des Informatiksystems erkennen lässt. Solche sind beispielsweise eine Datenbank oder eine Tabelle, auf die von einer grossen Anzahl anderer Programme zugegriffen wird. Eine Änderung einer Schnittstelle zu einer solchen Komponente würde somit einen grösseren Aufwand bedingen. Umgekehrt werden auch wenig oder gar nicht genutzte Komponenten ermittelt.

Modellteile sind alternativ dazu auch aus Daten von bekannten Management- Werkzeugen erzeugbar. Durch Konversionsprogramme werden solche Daten aus Datenbanken oder Exportdateien gelesen und Objekte zur Darstellung der relevanten Modellteile automatisch erzeugt. Umgekehrt lassen sich Modellinformationen zu Verwendung und/oder visuellen Darstellung in anderen Programmen exportieren.

Die oben betrachteten Modellierungsverfahren betreffen primär eine Modellierung von Strukturen und in zweiter Linie auch eine Erfassung von Modellparametern respektive von Attributen von Objekten, die in diese Strukturen eingebettet sind. Ist eine Struktur im wesentlichen bekannt, so lassen sich Parameter automatisch ermitteln. Dazu werden mehrere physikalische Sensoren, oder aber Hilfsprogramme, die zur Extraktion von Daten aus einem laufenden System dienen, eingesetzt. Im folgenden werden auch diese Hilfsprogramme als Sensoren bezeichnet. Von Sensoren erfasste Werte stammen also aus realen Komponenten des Systems und bewirken einen Abgleich des Modells mit dem real ablaufenden System. Die Werte werden entsprechenden Objekten im Modell zugeführt, welche diese Komponenten modellieren. Gemäss den im Modell enthaltenen Objekt- und benutzerspezifischen Regeln werden die Werte weiter verarbeitet, beispielsweise durch Speicherung im Objekt, Aufdatierung des Modells mit aktuellen Werten oder durch statistische Analysen der Werte, Regelung oder Steuerung des Systems, etc.

Bei der Modellbildung wird in einer bevorzugten Variante der Erfindung über ein Interface-Engine, welche ein Schema für die Objekterzeugung realisiert, eine Objekterzeugungs -Engine mit Befehlen zur Objektmanipulation angesteuert. Durch einen versierten Benutzer kann auch direkt auf die Objekterzeugungs-Engine zugegriffen werden. Die Objekterzeugungs-Engine greift auf ein Framework zu, welches die Grundtypen mit den vordefinierten Objekten in Beziehung setzt, und erzeugt respektive instanziert die benötigten Objekte, Verknüpfungen zwischen ihren Ein- und Ausgängen, und weitere Beziehungen zwischen den Objekten.

MODELLVERIFIKATION. QUALITÄTSPRÜFUNG

Nachdem ein Modell teilweise oder vollständig kreiert worden ist, wird es durch verschiedene Analysen auf die korrekte Verwendung einzelner Objekte und derer Beziehungen hin untersucht. Dies geschieht beispielsweise mit den folgenden Übe riifungsverfahren, die zusammengefasst auch als Prüfungen der Modellqualität bezeichnet werden:

Eine Modellüberprüfung kontrolliert, ob ein externer Agent, ein Prozess, ein Arbeitsprodukt und eine Prozessschnittstellenbeschreibung definiert wurden, und ob die Objekte gemäss ihrer Definitionen korrekt und vollständig mit anderen Objekten in Beziehung stehen, ob keine offenen Beziehungen definiert sind und ob Objekte nicht in einem Undefinierten Zustand verwendet werden.

Eine Vollständigkeitsprüfung kontrolliert, ob ein Prozess korrekt durch Elemente und Aktivitäten unterstützt wird und ob ein Prozess in einer Ereigniskette verwendet wird. Eine Konsistenzprüfung auf Objektebene kontrolliert, ob ein Objekt nicht unbenutzt und völlig ohne Beziehungen durch Referenzen oder Flussbeziehungen ist, ob es nichtexistierende Objekte referenziert.

Eine Transparenzprüfung kontrolliert ob Objekte ein Ziel und eine Beschreibung aufweisen. Konkret entspricht dies beispielsweise einer Prüfung, ob bestimmte Textfelder einer Maske zur Objektbeschreibung ausgefüllt worden sind, also einen Inhalt aufweisen.

Eine Qualitätsdefinitionsprürang kontrolliert, ob Qualitätsvorgaben an einzelne Objekte mittels einer Metrik definiert sind. Nur wenn diese vorliegen, ist eine spätere Beurteilung einer Qualität eines Prozesses oder einer Ereigniskette etc. möglich. Konkret entspricht dies beispielsweise einer Prüfung, ob Qualitätsvorgaben enthaltende Felder einer Maske zur Objektbeschreibung einen Inhalt aufweisen, und dieser Inhalt gegebenenfalls bestimmten Konventionen entspricht. Bei der Qualitätsbeurteilung werden unter Anwendung von Metriken Zusammenhänge, Beziehungen und Inhalte verifiziert und mittels Aussagen zur Qualität quantifiziert. Die Qualitätsvorgaben und Qualitätsmerkmale von Objekten sind zu unterscheiden von der hier betrachteten Prüfung der Qualität des Modelies selber!

Warnungen werden erzeugt, wenn ein Prozess nur einen eintretenden oder nur einen austretenden Fluss aufweist. Die erwähnten Analysen können durch Plug-In's und unter Anwendung benutzerspezifischer Regeln erweitert werden.

Die bisher genannten Prüfungen der Modellqualität betreffen also Konsistenz, Richtigkeit und Vollständigkeit des Modells.

Eine weitergehende Konsistenzprüfung wird durchgeführt, indem festgestellt wird, ob unterschiedliche Modellaspekte desselben Sachverhalts oder Aspekts der Realität miteinander übereinstimmen. Wenn somit das gleiche Objekt in zwei unterschiedlichen Modellen mit unterschiedlichem Detaillierungsgrad oder mit unterschiedlicher Sicht auf die Anwendung, verwendet wird, kann eine Aussage zur Richtigkeit gemacht werden. Insbesondere werden Ereignisketten mit Prozessschnit- tstellenbeschreibungen verglichen. Figur 12 zeigt schematisch eine Grundlage für Validierungsverfahren. Unter Validieren wird das Prüfen von Zuständen, Abläufen und Modellen mittels mindestens eines weiteren Modells oder eines anderen Modellaspekts verstanden. Teilmodelle auf Prozessebene 13, Element- oder Unterstützungsebene 14 und auf Informations- und Funktionsebene 15, sowie Ereignisketten BVG und Modelle externer Agenten 12 auf jeder dieser Ebenen und Produktedefinitionen 16 bilden jeweils verschiedene Aspekte des Systems im Modell ab. Diese Teilmodelle überschneiden einander in bestimmten Bereichen, und müssen, falls das Modell korrekt sein soll, in diesen Bereichen konsistent sein. Wenn also beispielsweise die Ereignisketten respektive Geschäftsvorfälle mit dem Prozessmodell und derer Definition verglichen werden, kann eine Aussage zur Qualität des Prozessmodells und der Geschäftsvorfallmodelle gemacht werden. Die Ausweisung der Qualität kann einerseits als Kennzahl oder mittels Detailinformationen über Widersprüche und Übereinstimmungen erfolgen.

Figur 13 illustriert ein konkretes Beispiel. In einem oberen Teil der Figur sind zwei Prozesse und P1,P2 und ein externer Vertreter EA1 dargestellt. Zwischen Pl und EA1 sowie zwischen P2 und EA1 sind Prozessschnittstellenbeschreibungen definiert. Diese beschreiben, welche Arbeitsmittel über die jeweilige Schnittstelle verschoben werden. In einem technischen System sind dies beispielsweise Produkte, Einzelteile, Fertigungsparameter, Bestelldaten, Maschinensteuerdaten, Messergebnisse etc. In einem administrativen Prozess sind dies beispielsweise Produkte, Quittungen, Zahlungen, Bestellungen etc.

In einem unteren Teil der Figur 13 ist eine Ereigniskette dargestellt, welche die erwähnten Prozesse P1.P2 und den externen Vertreter EA1 durchläuft. Die Ereigniskette wird vorzugsweise separat von den Prozessschnittstellenbeschreibun- gen definiert. Sie beschreibt eine systematische Aneinanderreihung von Ereignissen und Aktionen, sowie das Verschieben von Arbeitsmitteln respektive Produkten. Die Qualitätsüberprüfung hat zur Grundlage, das jeder Input und jeder Output eines Prozesses im Rahmen eines Geschäftsvorfalls erzeugt wird. In einer in der Figur 13 dargestellten Matrix werden Zeilen entsprechend Prozessen, die Arbeitsmittel abgeben (Output) bezeichnet, und Spalten entsprechend denselben Prozessen, aber als Empfänger von Arbeitsmitteln (Input). In den Feldern der Matrix werden etwaige Arbeitsmittel eintragen, die von einem Prozess zum anderen verschoben werden. Dadurch erhält man eine Übersicht über sämtliche Schnittstellen zwischen Objekten. Dieselbe Matrix wird verwendet, um darauf die Arbeitsmittel einzutragen, die durch einen Geschäftsvorfall verwendet werden. Nun kann festgestellt werden, ob eine Überdeckung vorliegt, das heisst, dass ein Arbeitsprodukt in beiden Definitionen auftritt. Bei einem Arbeitsmittel, das keine Überdeckung aufweist, ist entweder die Prozessdefinition oder die Definition des Geschäftsvorfalls unvollständig. In der Beispielmatrix sind Arbeitsprodukte, die nur in der Prozessschnittstellenbeschrei- bung verwendet wurden, in Normalschrift, jene, die nur in einer Ereigniskette verwendet wurden, und in Fettschrift jene, die in beiden Beschreibungen auftreten.

In der Figur 13 ist ferner dargestellt, wie Arbeitsmittel erzeugt ("create") und gespeichert ("störe") und Ereignisse übermittelt werden ("send event").

Dasselbe Prinzip wird auch für andere vordefinierte Objekte und andere Arten von Zusammenhängen angewendet: Vorzugsweise wird dabei die Konsistenz von Beschreibungen einer Ereigniskette auf verschiedenen Betrachtungs ebenen überprüft. Beispielsweise werden eine Ereigniskette auf Stufe Prozess und die gleiche Ereigniskette auf Stufe Element miteinander verglichen. Bei dieser Betrachtung, unter Berücksichtigung, dass Prozesse und ihre unterstützenden Element durch Beziehungen miteinander verbunden sind, kann eine Validierung und eine Qualitätsaussage über Objekte auf verschiedenen Ebenen gemacht werden. Dies im Gegensatz zu Figur 13, wo nur eine Ebene, aber eine Beschreibung mittels zweier verschiedener Objekte vorliegt.

Vorzugsweise wird dazu, wo einer ersten Schnittstelle zwischen Objekten auf einer ersten Modellierungsebene eine zweite Schnittstelle zwischen Objekten auf einer zweiten Modellierungsebene zugeordnet ist, zur Bildung einer Konsistenzaussage überprüft wird, ob ein Arbeitsmittel, welches über die erste Schnittstelle übergeben wird, und ein Arbeitsmittel, welches über die zweite Schnittstelle übergeben wird, einander zugeordnet sind respektive einander entsprechen. Für mehrere Schnittstellen, die zu jeweiligen Ereignisketten auf den beiden Modellierungsebene gehören, wird analog verfahren: es werden also die Schnittstellen in beiden Modellierungsebenen über die ganze Ereigniskette hinweg miteinander verglichen. RISIKOANALYSE

Für die Berechnung und das Propagieren von Risiken gelten die folgenden Prinzipien: Grundsätzlich kann jedem Objekt ein Risiko-Objekt zugeordnet sein. Insbesondere ist dies zweckmässig für Prozesse, Elemente, Arbeitsmittel, Ereignisketten u.a. Ein Risiko-Objekt weist auf eine numerische Repräsentation eines Risikos des Objekts, sowie Regeln oder Berechnungsvorschriften zur Bestimmung des Risikos anhand von Risiken und von sonstigen Attributen anderer Objekte, insbesondere von Messwerten von Grossen des Systems. Das Risiko ist ein Mass für die Wahrscheinlichkeit, dass das betreffende Objekt seine Funktion nicht erfüllt oder dass bestimmte seiner Eigenschaften nicht korrekt sind.

Das Risiko wird beispielsweise auf einer Skala zwischen 0 und 100 dargestellt. Zur graphischen Darstellung sind einzelnen Bereichen dieser Skala unterschiedliche Farben (grün/gelb/rot) zugeordnet und werden, den Objekten zugeordnet, in Tabellen, Matrixdarstellungen oder Diagrammen einem Benutzer oder Sy stemüberw acher dargestellt.

Regeln zur Risikoberechnung sind beispielsweise in textueller Form mit üblicher Syntax ausgedrückt, z.B. im Sinne von

WENN «Risiko von Prozess A» > 60 UND «Ausschuss von Fertigungszelle X» > 10% DANN «Risiko von Unterbruch der Gesamtfertigung um 10% erhöhen»

Regeln zur Handlung aufgrund von Risiken drücken beispielsweise aus, dass beim Überschreiten bestimmter Risikoschwellwerte Nachrichten via e-mails oder SMS (short message System) automatisch verschickt werden, Alarme ausgelöst werden oder in eine Produktionssteuerung eingegriffen wird- Letzteres geschieht beispielsweise durch Ausserbetriebnahme einer Maschine oder durch Anpassung von Steuerparametern, so dass langsamer aber mit besserer Qualität gearbeitet wird. Dabei ist zweckmässig, dass die Risiken entsprechend von aktuellen Messwerten aus dem System berechnet und laufend aktualisiert werden.

Für jedes Objekt sind auch andere Risiken definierbar. Für jedes Risiko werden vorzugsweise eine Beschreibung und beschreibende Attribute wie Eintrittswahr- scheinlichkeit, eine Tendenz, ein Frühwarnindikator, Netto- und Brutto-Risiko, Kosten, ein oder mehrere Aktionen zur Verhinderung des Risikos etc. definiert.

Will man das Risiko entlang einer Kette rechnen, zum Beispiel entlang einer Ereigniskette, so gilt das grösste entlang der Kette ermittelte Risiko als das Risiko der ganzen Kette, sofern die gegenseitige Beeinflussung der Risiken immer positiv ist und in der Flussrichtung erfolgt. Wirken auf eine Kette weitere Risiken als Einflussgrössen, wird abhängig von der Risikowirkung und der Richtung, der Risikowert ermittelt.

In einer bevorzugten Ausführungsform der Erfindung wird mit einer Monte Carlo Simulation eine Variation von Risiken und deren Abhängigkeiten durchgespielt und bestimmt, welche Objekte besonders anfällig oder sensitiv sind. In einer anderen automatischen Analyse wird beim Vorliegen von Schlaufen in der Risikoberechnung durch mehrere Objekte detektiert, ob sich die Risiken aufschaukeln, in Extremwerte laufen, oder sich stabilisieren.

BEZIEHUNGS ANALYSE

Figur 14 zeigt vereinfacht verschiedene Objekte eines Modells, die in Beziehung untereinander stehen. Ereignisketten respektive Geschäftsvorfälle BVC1-BVC4 auf der Prozessebene durchlaufen Prozesse P1-P3, wobei einzelne Geschäftsvorfälle auch einzelne Prozesse überspringen können. Auf der Elementebene entspricht den Ereignisketten BVC1-BVC3 die Ereigniskette BVC5, und der Ereigniskette BVC4 die Ereigniskette BVC6. Die Prozesse P1-P3 werden unterstützt durch Elemente El- E4. Diese Unterstützungsbeziehungen werden in der Figur 14 durch Linien dargestellt. Beispielsweise unterstützt Element E2 die Prozesse Pl und P2. Ein Grad der Unterstützung ist in der Figur durch Prozentzahlen ausgedrückt. So zeigt die Linie zwischen Pl und E2 an, dass 10% des Bedarfes von Prozess Pl durch Element E2 abgedeckt wird, und 10% der Leistung von E2 durch Pl verbraucht werden. Bedarf respektive Leistung werden einerseits durch absolute Werte, beispielsweise in Arbeitsstunden, Kosten, Stückzahlen, etc. ausgedrückt. Andererseits werden die Werte bei Betrachtung eines Prozesses, eines Elements, einer Ereigniskette etc. auf einen jeweiligen Gesamtbedarf des Prozesses respektive auf eine Gesamtkapazität des Elements etc. bezogen und durch Prozentzahlen ausgedrückt. So wird sichtbar, wie mehrere Elemente anteilsmässig zu einem Prozess beitragen, und umgekehrt, wie sich die Leistung eines Elements auf mehrere Prozesse verteilt. In der Figur 14 wird zur Vereinfachung der Darstellung angenommen, dass die Prozentzahlen bei allen Prozessen P1-P3 und Elementen E1-E4 auf denselben Wert bezogen sind. Prozess Pl wird nach dieser Analyse nicht vollständig unterstützt, Prozess P3 erfährt eine doppelt so grosse Unterstützung als eigentlich nötig wäre. Element E3 ist mit 130% überlastet, und Element El ist nur zu 70% ausgelastet.

Die Kosten eines Geschäftsvorfalles errechnen sich aus den prozentualen Anteilen der Prozesskosten: Ein Element unterstützt einen Prozess mit einem bestimmten Anteil der Elementkapazität, und der Prozess wird zu einem bestimmten Anteil seines Gesamtbedarfs durch das Element unterstützt. Daraus werden Gesamtkosten berechnet: Beispielsweise entfallen Kosten in BVC4 zu 40% auf den Prozess Pl und zu 60% auf den Prozess P3.

Von den Elementkosten werden so über die Prozesskosten die Gesamtkosten eines Geschäftsvorfalles berechnet. Unterstützt ein Element gar keinen Prozess, wie zum Beispiel El, so werden seine Kosten über die Geschäftsvorfälle verteilt. Gesamtkosten für einen Geschäftsvorfall sind mit einem erzielten Preis aus dem Verkauf des entsprechenden Produktes A,B,C,D vergleichbar.

Die Kosten des gleichen Geschäfts Vorfalls, aber auf Elementebene, also BVC6, entfallen zu 40% auf E2 und zu 60% auf E5. Element El trägt zwar zu 70% zu Prozess Pl bei, unterstützt aber keinen Prozess auf Elementebene.

Falls die Summe der Geschäftsvorfälle weniger als hundert Prozent eines Prozesses benötigt, erhält ein Wert für die Performance des Prozesses einen reduzierten Wert als Ausdruck einer ungenügenden Performance.

Basierend auf der erläuterten Modellierungsweise und Berechnungsprinzipien werden also wesentliche Aussagen über Prozesskosten und derer Entstehung gemacht. Das anhand der Kosten dargestellte Vorgehen wird vorzugsweise auch für andere Eigenschaften angewendet, die als prozentuale Abhängigkeiten zwischen Objekten darstellbar sind, beispielsweise Risiken.

Eine Modellierung von Kosten geschieht oft über verschiedene Stufen einer Objekthierarchie. Beispielsweise beschreibt die Objekthierarchie ein Produkt und seine Zusammensetzung aus Teilprodukten, oder ein hierarchisch gegliedertes Sortiment von Produkten. Bei der Modellerzeugung und Modellparametrierung werden Kosten an verschiedenen Stellen erfasst. Diese Kosten müssen konsistent sein und erlauben, unter Umständen fehlende Informationen automatisch zu bestimmen.

Fig.15 illustriert, wie dabei vorgegangen wird: Es sei eine Baumstruktur gegeben, in welcher ein Elternknoten 20 mehrere ihm zugeordnete Kindknoten 21 aufweist, und jeder Knoten 20,21 mit einem Attribut versehen ist. Das Attribut repräsentiert einen bestimmten Ressourcenbedarf, beispielsweise Kosten, Stückzahlen, Zeit, Materialbedarf, etc., im Folgenden der Einfachheit "Kosten" genannt. In den Figuren 15 a und 15b sind diese Kosten 620,250,300,0 und "nicht definiert", was durch <nil> bezeichnet ist. Für die Darstellung von Zusammenhängen und Propagationsregeln von diesen Kosten werden vorzugsweise die folgenden unterschiedlichen Arten von Objektbeziehungen mit dazugehörigen Berechnungsweisen verwendet: Aggregation, Vererbung und einfache Beziehung.

• Bei der Aggregation 22 ist die Summe der Kosten von Elternknoten 20 und Kindknoten 21 (in der Figur 15a: 250,300, 0,<nil>) gleich der einer dem Elternknoten 20 zugeordneten Kostensumme (620). Für Kosten des Elternobjektes alleine (70) verbleibt die Differenz zwischen dieser Kostensumme (620) und der Summe der Kosten der Kindknoten (250+300). In den Figuren 15a und 15b ist dieser Zusammenhang mit dem Bezugszeichen 22 bezeichnet. Diese Berechnungsart ist beispielsweise für Kosten von Produkten, entsprechend Elternknoten 20, aus Komponenten, entsprechend Kindknoten 21, zweckmässig,

• Bei der Vererbung 23 erhält ein Kindknoten 21, falls seine Kosten Undefiniert sind, die Kosten des Elternknotens 20 (620). Die Kostensumme (1790) ist gleich der Summe von den Kosten des Elternobjektes und den Kosten aller Kindknoten. Diese Berechnungsart ist beispielsweise für Kosten von verallgemeinerten Produkten in einem Produktekatalog, entsprechend Elternknoten 20, und spezifischen Produkten, entsprechend Kindknoten 21, zweckmässig. • Bei der einfachen Beziehung 24 bleiben Kosten unverändert, Undefinierte Kosten werden als Null betrachtet. Die Kostensumme (1170) ist gleich der

Summe von den Kosten des Elternobjektes und den Kosten aller Kindknoten.

Bei einer gegebenen Kapazität von beispielsweise 620 resultiert bei der Aggregation 22 eine Übereinstimmung mit den Kosten und bei den anderen beiden Berechnungsarten 23, 24 eine mehr oder weniger starke Unterdeckung. Figur 15b zeigt dieselben Berechnungsmechanismen wie Figur 15a, jedoch mit Kosten des Elternknotens 20 von 0 statt 620.

PERFORMANCEBEWERTUNG

Kenngrössen von Objekten werden im Betrieb des realen Systems durch das dem System nachgeführte Modell anhand von Messgrössen ermittelt. Anforderungen an solche Kenngrössen, die beispielsweise Leistungen, Stückzahlen, Geldbeträge, Produktequalität, Maschinenenauslastung etc. repräsentieren, werden in einem Strategieobjekt zusammengefasst. Dies geschieht in einer hierarchischen Form: Anforderungen an Kenngrössen werden als Ziele ("Goals") bezeichnet und zusammengefasst als "Thesen" bezeichnet. Innerhalb einer These sind die Ziele prozentual gewichtet, d.h. ihre Gewichte ergeben 100%. Thesen sind gleichermassen gewichtet zu Thesen auf einer höheren Stufe zusammenfassbar. Auf einer obersten Stufe wird eine Zusammenfassung aller Thesen als Strategie bezeichnet. Die Ziele einer These sind definiert, qualifiziert, quantifiziert, stehen in einer Reihenfolge, sind priorisiert und können untereinander in Beziehung stehen. Die einzelnen Zielsetzungen oder Thesen können mit anderen vordefinierten Objekten mittels einer Interaktionsbeziehung verknüpft werden. Diese Verknüpfung kann zu einem Externen Vertreter, Prozess, Element einem Arbeitsmittel, einer Anforderung usw. erstellt werden. Mit diesen Verknüpfungen wird beispielsweise definiert, zu wie viel Prozent ein Objekt von dieser Strategie respektive These betroffen sowie zu wie viel Prozent eine These von Objekt abhängig ist oder abgedeckt wird. Diese Verknüpfungen sind für Abhängigkeitsanalysen verwendbar. In einer bevorzugten Variante der Erfindung, bei welcher das Modell anhand von Messungen am realen System nachgeführt wird, wird ein Erfüllungsgrad der verschiedenen Ziele entsprechend den jeweiligen Anforderungen berechnet. Durch die Hierarchie der Thesen und anhand der Gewichtungen wird die Erfüllung der Thesen und der Strategie berechnet. Damit liegt laufend ein Wert vor, der eine Aussage über die Leistungsfähigkeit respektive den aktuellen Stand des Systems bezüglich Zielerreichung macht. Bei Bedarf kann interaktiv durch Navigation durch Thesenobjekte und ihre Abhängigkeitsbeziehungen festgestellt werden, wer oder was in welchem Mass zur Zielerreichung beiträgt.

MODELLVERGLEICH

Zum Vergleich eines Systems zu verschiedenen Zeitpunkten oder in verschiedenen Zuständen liegen mindestens zwei Modelle des Systems entsprechend den unterschiedlichen Zuständen vor, auch Betrachtungsräume genannt. Je nach Zusammenhang werden solche Zustände auch Ist-Zustand und Soll-Zustand genannt. Beispielsweise entspricht ein Soll-Zustand einem gewünschten System oder Referenzzustand nach Einführung einer neuen Betriebssoftware, nach einer Reorganisation von Strukturen und Abläufen, oder nach Installation einer neuen Maschine. Unterschiede zwischen den Modellen liegen einerseits in der Modellstruktur, also der Struktur von Beziehungen zwischen den Objekten, und andererseits in Werten von Parametern respektive Attributen von einander zugeordneten Objekten.

Durch die durchgehende Modellierung auf Basis der Grundtypen ist ein Vergleich unterschiedlicher Modelle letztlich auf einen Vergleich einer Struktur der Grundtypen zurückführbar. Dadurch lässt sich der Vergleich effizienter implementieren als bei Verwendung mehrerer verschiedener Modellierungsparadigmen für verschiedene Modellaspekte.

Um einen Zustand in einen anderen zu überführen, ist eine Menge von Handlungen respektive Änderungen des Systems respektive des Modells, meist über einen bestimmten Zeitbereich verteilt, notwendig. Diese Menge von Handlungen wird Projektportfolio genannt und weist mehrere Untermengen, Projekt genannt, auf. Das Projektportfolio wird vorzugsweise selber als ein eigenes Modell dargestellt, in welchem die Änderungen zwischen den betrachteten zwei Modellen zur Überprüfung durch Annehmen respektive Verwerfen aufbereitet werden. Die Bestimmung der Handlungen geschieht durch Vergleich einer Objekthierarchie der im Modell instanzierten Objekte mit sogenannten Compare & Merge Algorithmen. Fig.16 zeigt schematisch einen solchen Modellvergleich. Jeweils ein erster und zweiter Modellteil zur Beschreibung eines Prozessmodells 13, eines Elementmodells 14 und eines Modells einer Informations- und Funktionsebene 15 werden miteinander verglichen. Der Vergleich ergibt eine Aufstellung von Änderungen der jeweiligen Betrachtungsebenen. Die entsprechenden Handlungen sind in Projekten 18, 19 im Projektportfolio 17 zusammengefasst.

PROZESSSTEUERUNG

Zur Systemüberwachung und -Steuerung werden an definierten Stellen im System die bereits erwähnten Sensoren zur Datenerfassung installiert. Diese Informationssammler funktionieren in der Regel automatisch, können aber auch auf manuellen Benutzereingaben basieren. Ermittelte Messwerte der Sensoren werden im Modell nach Massgabe der im Modell definierten Verarbeitung verrechnet und mit anderen Daten kombiniert. Mit derart neu berechneten Werten wird der Prozess gesteuert. Falls bestimmte Werte vorgegebene Grenzwerte überschreiten, werden Notifikationen oder Alarmierungen ausgelöst. Beispielsweise wird dazu eine SMS, ein Dokumentenversand via E-mail, ein Transfer von Informationen auf ein Mobilgerät oder eine Sprachnachricht via Telefon übermittelt.

Mit der Erfindung wird eine pragmatische aber trotzdem komplette Basis zur Modellierung, Steuerung und Überwachung von komplexen technischen und organisatorischen Systemen und Abläufen geschaffen. Sie erlaubt... • Modelle immer konsistent, transparent und stufengerecht für verschiedene

Zielpubliken bereit zu haben, insbesondere um einen automatisierten oder manuellen Entscheidungsprozess maximal zu unterstützen. • Jederzeit Aussagen zur Qualität, Risiken, Kosten, Nutzen, Machbarkeit, etc. zu erhalten. • Notwendige Analysen maximal zu unterstützen und Veränderungen immer aktuell steuern zu können.

Claims

PATENTANSPRÜCHE

1. Verfahren zur Modellierung eines komplexen Systems, wobei in Ereignisketten des Systems Einheiten wie Daten und/oder Produkte empfangen, verarbeitet und weitergeleitet werden, dadurch gekennzeichnet, dass die Modellierung auf einer untersten Beschreibungsebene einen begrenzten Satz von Grundtypen zur Repräsentation der Einheiten und zur Beschreibung ihres Zusammenwirkens verwendet, wobei jeder Grundtyp Daten verarbeitet, welche Daten Werte von Eigenschaften der genannten Einheiten repräsentieren, und wobei dieser Satz von Grundtypen aufweist

- einen Grundtyp "Weiterleiten", welcher eine Weiterleitung von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten durchleitet und einen Eingang sowie einen Ausgang aufweist, - einen Grundtyp "Verschmelzen", welcher ein Kombinieren von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten miteinander verknüpft und zwei Eingänge sowie einen Ausgang aufweist,

- einen Grundtyp "Aufteilen", welcher eine Auftrennung von Einheiten repräsentiert, Daten zur Charakterisierung von Einheiten, die aus einer Auftrennung hervorgehen, aus Daten einer aufzutrennenden Einheit ermittelt, und einen Eingang sowie zwei Ausgänge aufweist, wobei jeweils Eingänge zur Übernahme und Ausgänge zur Übergabe von Daten in den respektive aus dem jeweiligen Grundtyp dienen, und wobei computerbasierte datenverarbeitende Modelle des Systems gebildet werden durch Bildung einer Menge von Grundtypen und durch Verknüpfen von Ein- und Ausgängen dieser Grundtypen.

2. Verfahren gemäss Anspruch 1, wobei der Satz von Grundtypen weiter aufweist

- einen Grundtyp "Erzeugen", welcher eine Quelle von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten erzeugt und einen Ausgang aufweist, - einen Grundtyp "Aufbewahren", welcher eine Speicherung von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten speichert und einen Eingang aufweist.

3. Verfahren gemäss einem der vorangehenden Ansprüche, wobei jeder der verwendeten Grundtypen aufweist

- Funktionen oder "descriptions", die ein sequentielles Verhalten des Grundtyps als prozessualen Ablauf beschreiben;

- Vorbedingungen oder "preconditions" zur Beschreibung einer Startsituation welche vorliegen muss, damit das Verhalten resp. die Funktion des Grundtyps auslösbar ist; und

- Nachbedingungen oder "postconditions" zur Beschreibung einer Endsituation welche nach Ablaufen eines entsprechenden Verhaltens respektive einer Funktion des Grundtyps herrscht.

4. Verfahren gemäss einem der vorangehenden Ansprüche, wobei jeder der verwendeten Grundtypen aufweist

- Regeln die eine Logik des Verhalten des Grundtyps beschreiben; und Ausnahmebedingungen, die ein Verhalten des Grundtyps in Ausnahme- zuständen beschreiben.

5. Verfahren gemäss einem der vorangehenden Ansprüche, wobei jeder Grundtyp mit einer Protokollfunktion speichert, wann er welche Daten in welcher Weise verarbeitet hat.

6. Verfahren gemäss einem der vorangehenden Ansprüche, wobei die Grundtypen auf einer höheren Abstraktionsstufe zu Objekten zusammengefasst werden, wobei ein Objekt jeweils keine bis mehrere Eingänge respektive Ausgänge aufweist und ein Verhalten des Systems durch das Objekt modelliert wird.

7. Verfahren gemäss einem der vorangehenden Ansprüche, wobei Beziehungen zwischen Grundtypen oder Objekten durch Beziehungstypen dargestellt werden, wobei diese Beziehungstypen umfassen

- Flussbeziehungen, welche eine Übermittlung von Informationen oder Inhalten zwischen Objekten darstellen.

8. Verfahren gemäss Anspruch 6, wobei die Beziehungstypen umfassen

- permanente Beziehungen, welche Referenzen oder Entsprechungen zwischen Objekten darstellen, und - Interaktionsbeziehungen, welche eine Einflussnahme eines Objektes auf ein anderes darstellen, wobei die Art der Einflussnahme bei der Modellbildung bekannt ist.

9. Verfahren gemäss Anspruch 7, wobei die Beziehungstypen umfassen - Differenzbeziehungen, welche Unterschiede zwischen Objekten repräsentieren.

10. Verfahren gemäss Anspruch 6 bis 9, wobei ein Objekt eine Aktivität in einem

Ablaufschema repräsentiert.

11. Verfahren gemäss Anspruch 6 bis 10, wobei ein Objekt einen Prozess in einer

Organisation repräsentiert.

12. Verfahren gemäss Anspruch 6 bis 11, wobei ein Objekt ein Element, das heisst, eine reale physische Einheit repräsentiert, welches einen Prozess oder eine

Aktivität unterstützt.

13. Verfahren gemäss Anspruch 6 bis 12, wobei ein Objekt eine Ereigniskette, das heisst, einen wiederkehrenden Handlungsablauf innerhalb des Systems repräsentiert. .

14. Verfahren gemäss Anspruch 6 bis 13, wobei Objekte zu Darstellung von

Produkten verwendet werden, die zwischen Prozessen, zwischen Elementen und/oder entlang Ereignisketten verschoben werden.

15. Verfahren gemäss Anspruch 6 bis 14, wobei das Modell durch einen Benutzer erstellt und/oder modifiziert wird, indem eine graphische oder textuelle Darstellung von Objekten und ihrer Beziehungen auf einem Visualisierungsgerät dargestellt und durch den Benutzer mittels eines Eingabegerätes geändert wird, und indem eine interne Darstellung der Objekte aufgrund der Grundtypen und weiterer Attribute nach Massgabe dieser Änderungen angepasst wird.

16. Verfahren gemäss Anspruch 7 bis 14, wobei zumindest ein Teil des Modells durch eine automatische Analyse eines Softwaresystems erstellt wird, insbesondere durch systematisches Durchsuchen eines Netzes von

Abhängigkeiten und Aufrufen in diesem Softwaresystem und durch Abbildung dieses Netzes im Modell durch Objekte und Beziehungen.

17. Verfahren gemäss einem der vorangehenden Ansprüche, wobei zum Abgleich des Modells mit einem real ablaufenden System Daten aus dem System erfasst und in das Modell verarbeitet werden.

18. Verfahren gemäss einem der Ansprüche 1 bis 17, wobei im Modell ermittelte Daten zur Steuerung des Systems verwendet werden, insbesondere einer technischen Einrichtung oder eines Produktionsprozesses.

19. Datenverarbeitungssystem zur Modellierung eines Systems, wobei das Datenverarbeitungssystem Mittel aufweist zur Durchführung des Verfahrens nach einem oder mehreren der Ansprüche 1 bis 18.

20. Computerprogramm zur Modellierung eines Systems, welches auf einer Datenverarbeitungseinheit ladbar und ausführbar ist, und welches bei der Ausführung das Verfahren nach einem oder mehreren der Ansprüche 1 bis 18 ausführt.

21. Datenträger, enthaltend ein Computerprogramm gemäss Anspruch 20.