CH701481B1 - Prozessmanagement. - Google Patents

Abstract

Die Erfindung betrifft ein Verfahren zum Modellieren, Dokumentieren und Validieren eines Systems, vorzugsweise einer Firma. Das Verfahren beinhaltet die folgenden Schritte: Anbringen von einem oder mehreren Sensoren in einem System, Definieren von zu erfassenden Informationen, Parametrisieren der zu erfassenden Informationen, Transformieren der parametrisierten Informationen zu Objekten mit Parametern, Verknüpfen der Parameter der Objekte über standardisierte Beziehungen, Überprüfen und falls erforderlich Ergänzen oder Ändern der erfassten Objekte und deren Parameter, Erfassen der parametrisierten Informationen mittels der Sensoren, standardisierte Auswertung der Beziehungen der Objekte, Ausgabe der Resultate der standardisierten Auswertung in Form von Ausdrucken oder in elektronischer Form. Die Schritte werden in zeitlichen Abständen wiederholt.

Description

[0001] Die Erfindung liegt auf dem Gebiet des Prozessmanagements, insbesondere dem dynamischen Prozessmanagement mittels Computerprogrammen und Sensoren für die Erfassung, Modellierung, Dokumentation und Validierung von komplexen Abläufen und Systemen. Sie betrifft ein Verfahren gemäss dem Oberbegriff des Patentanspruchs 1 sowie einen Datenträger gemäss Patentanspruch 7.

[0002] Bei komplexen Situationen, Abläufen und Systemen, die eine Vielzahl von miteinander verknüpften Parametern aufweisen, ist es sehr schwierig, den Einfluss von Veränderungen einzelner Parameter auf das Verhalten des Gesamtsystems vorherzusagen. Zum Beispiel beim Führen eines Unternehmens, oder bei der Organisation von grossen Projekten, stellt die Entscheidungsfindung ein Problem dar. Da die Anzahl der Einflussgrössen mit der Grösse einer Unternehmung oder eines Projektes zunimmt, können die Einflussgrössen oft nicht mehr gesamtheitlich überblickt werden. Deshalb ist es sehr schwierig, relevante Grössen von nichtrelevanten Grössen zu unterscheiden, zu gewichten und diese im Kontext auszuwerten. Entscheidungen auf der Managementebene werden heute aus den obengenannten Gründen häufig willkürlich getroffen. Ein weiteres Problem besteht darin, dass Einflussgrössen nicht objektiv erfasst werden können. Aufgrund von sich ändernden Umständen und Gegebenheiten und infolge mangelnder Standardisierung werden Einflüsse unterschiedlich eingeschätzt und interpretiert. Dies stellt ein weiteres Problem bei der Entscheidungsfindung dar, das eine Lösung erfordert.

[0003] Ein standardisiertes Erfassen der relevanten Einflussgrössen, deren Qualifizierung und Auswertung ist heute praktisch nicht möglich oder mit sehr hohem Zeitaufwand und Ressourcenverbrauch verbunden. Eine dynamische Erfassung und Auswertung einer Vielzahl von Messungen scheitert an den vorgenannten Problemen, an der Komplexität, an der Qualität und Konsistenz der relevanten Informationen.

[0004] Aufgabe der Erfindung ist es, ein automatisiertes, computerbasiertes Verfahren zu zeigen, das eine standardisierte Erfassung, Auswertung, Überprüfung und Darstellung von komplexen Systemen und Abläufen erlaubt.

[0005] Die Umsetzung der Erfindung erfolgt bevorzugt in Form von einem oder mehreren Computerprogrammen und mittels zugeordneter respektive wirkverbundener Sensoren. Das erfindungsgemässe Verfahren kann zur Steuerung sämtlicher Aspekte in einem komplexen System, insbesondere einem Unternehmen, verwendet werden. Das Ziel besteht darin, die Abläufe und Vorgänge im betrachteten System mit ihren relevanten Parametern zu erfassen, abzubilden und miteinander in Beziehung zu setzen. Durch das Verwenden von standardisierten Abläufen und Algorithmen bei der Modellbildung und deren Verifizierung, zum Beispiel durch Vergleich mit alternativen Modellen, wird ein dynamisches Bild erzeugt, welches die Abläufe anhand ihrer relevanten Grössen darstellt. Durch die Formulierung mittels eines Metamodells können abstrakte Vorgänge vereinfacht dargestellt werden. Durch den Aufbau als Framework ist auch die Skalierbarkeit gewährleistet.

[0006] Um das Verständnis für die Erfindung zu fördern, soll als Vergleich aus der Praxis ein Cockpit/Flugsimulator eines Flugzeuges dienen. Die Erfindung basiert vereinfacht dargestellt auf denselben Prinzipien wie die Instrumentierung eines Cockpits/Flugsimulators. Der Pilot kann alles steuern und überwachen, wird dabei aber nicht mit unnötigen Informationen versorgt, die er nicht braucht. Der Pilot hat aber dennoch zu allen Informationen in jedem Detaillierungsgrad Zugriff, wenn er diese braucht. Der Pilot kann somit im Normfall mit wenigen relevanten Informationen, Anzeigen und Handgriffen das komplexe System Flugzeug sicher steuern. Er kann im Flugsimulator Strategien durcharbeiten, Varianten ausarbeiten, Verhalten überprüfen und Simulationen durchführen und mögliche Folgen daraus verifizieren.

[0007] Die Erfindung beinhaltet vereinfacht betrachtet im Wesentlichen drei Teile. Diese Teile können einzeln oder als gesamtes Paket angewendet werden. Bei einem ersten Teil handelt es sich um ein skalierbares Softwarepaket, das individuell nach den Wünschen eines Betreibers eines komplexen Systems konfiguriert wird. Bei einem zweiten Teil handelt es sich um ein pragmatisches und praxisorientiertes Vorgehensmodell, das eine Weiterentwicklung eines bekannten Vorgehensmodells mit der Bezeichnung «OOW» (Objekt Orientierter Weg) darstellt, das im Buch «Der objektorientierte Weg» (ISBN 3-9521597-0-0) der Autoren Roland Pulfer und Urs Schmid beschrieben ist. Ein dritter Teil beinhaltet eine normierte Vorgehensweise, die einem Anwender hilft, zu einem festen Termin und mit definierbarem Aufwand und Kosten zu standardisierten Resultaten zu gelangen.

[0008] Die Erfindung kann einen sogenannten elektronischen Berater beinhalten. Bei diesem elektronischen Berater handelt es sich vereinfacht dargestellt um eine Automatisierung eines klassischen Beraters. Dieser elektronische Berater weiss Bescheid über Referenzmodelle, kann Informationen aufnehmen und alternative Lösungsszenarien vorschlagen. Der elektronische Berater hilft einerseits die Zusammenhänge in einem komplexen System aufzuzeigen und transparent zu machen, andererseits hilft er, im Moment nicht erforderliche Informationen auszufiltern. Bevorzugt sollen alle betroffenen und beteiligten Sensoren, Stellgrössen und Schaltstellen schnell erreichbar sein, derart, dass der oder die Prozesse beeinflusst und optimiert werden können. Der Informationsfluss soll dadurch optimal unterstützt werden. Die betroffenen und beteiligten Sensoren, Stellgrössen und Schaltstellen dürfen aber nicht mit unwesentlichen Informationen überhäuft werden. Die Bedeutung eines elektronischen Beraters wird nachfolgend anhand einer Unternehmung erläutert. Im Fall einer Unternehmung soll der elektronische Berater wenn immer möglich einen bedingten Austausch und Vergleich (Benchmarking) zwischen Unternehmen auf einer neutralen Plattform unterstützen. Da viele Unternehmungen, die mit den unterschiedlichsten Gütern und Dienstleistungen beschäftigt sind, ähnliche interne Strukturen und Prozessabläufe aufweisen, ist ein Vergleich von einem Prozessmodell einer Unternehmung mit einem Prozessmodell einer anderen Unternehmung durchaus sinnvoll. Durch eine standardisierte Betrachtungsweise können die Modelle ausgetauscht respektive gehandelt werden. Die Motivation, einen solchen elektronischen und persönlichen Assistenten und Berater anzubieten, erfolgt zum Beispiel auf der Grundlage der Verschmelzung von internen und externen Beratern. Sehr viele Firmen haben Angestellte, die jahrelang in der Beratung gearbeitet haben und über ein grosses Wissen verfügen. Dies führt dazu, dass der externe Berater immer mehr unnötig wird. Ein Nachteil von externen Beratern besteht darin, dass diese viel zu lange benötigen, um fundierte Kenntnisse über wichtige interne Abläufe zu erarbeiten.

[0009] Die Erfindung will einerseits die Innovation, das Engineering, das Projektmanagement und die Umsetzung von Vorgaben unterstützen und andererseits den Betrieb eines Unternehmens steuern helfen. Das Cockpit/Flugsimulator für den Unternehmer ist eine gute Darstellung des Erfindungsgedankens. Ein komplexes System wie z.B. ein Unternehmen muss gesamtheitlich betrachtet und geleitet werden, und es sollen schon auf Modellbasis Überprüfungen durchgeführt werden können. Damit die Vielschichtigkeit der Probleme den Leiter einer Unternehmung nicht am Arbeiten hindert, müssen gewisse Informationen, in Analogie zum Cockpit/Flugsimulator, in dem ein Pilot sitzt, nur zu einem bestimmten Moment, in einem bestimmten Detaillierungsgrad vorhanden sein. Im Normalfall hat der Pilot nur ein paar wichtige Messgeräte und Visualisierungen zu beobachten und zu bedienen. Tritt eine Unregelmässigkeit ein, muss er aber via geeignete Prozeduren («Drill down»-Prozeduren) an jegliche Detailinformationen gelangen, um seine Handlungen zu unterstützen. Es werden ihm Szenarien vorgeschlagen, Alternativen berechnet und seine Auswirkungen aufgezeigt.

[0010] Die Erfindung wird anhand der nachfolgenden Figuren näher erläutert. Es zeigen schematisch und stark vereinfacht: <tb>Fig. 1<sep>Abläufe in einem komplexen System; <tb>Fig. 2<sep>eine Überwachung von Prozessen mit Parametern gemäss Fig. 1 <tb>Fig. 3<sep>eine Übersicht über Sensoren und deren Anordnung; <tb>Fig. 4<sep>eine serverbasierte Anwendung; <tb>Fig. 5<sep>Anbindung an eine Wissensdatenbank; <tb>Fig. 6<sep>eine Verarbeitung von Informationen; <tb>Fig. 7<sep>eine mögliche Grundstruktur; <tb>Fig. 8<sep>Schlüsselergebnisse in einer Würfeldarstellung; <tb>Fig. 9<sep>Workprodukte auf verschiedenen Metaebenen; <tb>Fig. 10<sep>die verwendeten Dimensionen in einer vereinfachten Darstellung; <tb>Fig. 11<sep>eine Strategie- und Zielaufteilung; <tb>Fig. 12<sep>das Modellieren von Anforderungen; <tb>Fig. 13<sep>ein Produktmodell; <tb>Fig. 14<sep>ein mögliches Projektmanagement; <tb>Fig. 15<sep>eine mögliche Form von Qualitätsmanagement; <tb>Fig. 16<sep>eine mögliche Form von Risikomanagement; <tb>Fig. 17<sep>Abhängigkeiten, wie sie bei einer Modellbildung auftreten; <tb>Fig. 18<sep>einen Vergleich zwischen Arbeitsprodukten und Produkten; <tb>Fig. 19<sep>eine Analyse von Auswirkungen; <tb>Fig. 20<sep>Risiken und deren Zusammenhänge; <tb>Fig. 21<sep>eine Generierung von Szenarien und Varianten; <tb>Fig. 22<sep>eine mögliche Form eines Kostenmanagements; <tb>Fig. 23<sep>die Beziehungen zwischen verschiedenen Systemen; <tb>Fig. 24<sep>ein Risikomanagement und die dabei verwendeten Berechnungsalgorithmen; <tb>Fig. 25<sep>eine Abhängigkeit zwischen mehreren Prozessen; <tb>Fig. 26, 27<sep>ein Referenzmodell respektive einen Referenzmodellprozess; <tb>Fig. 28<sep>verschiedene Berichte, die anhand des beschriebenen Verfahrens erstellt werden können.

[0011] Fig. 1 zeigt schematisch die Abläufe, wie sie in einem komplexen System, z.B. einer Unternehmung, auftreten können. Der bereits erwähnte Vergleich zu einem Cockpit/Flugsimulator ist in Fig. 1 auf eine andere Art und Weise sichtbar gemacht. Diese Übersicht zeigt nur einige der wichtigsten Grundlagen des Frameworks auf, das beliebig erweitert werden kann.

[0012] Für ein Zielpublikum 1 werden Strategien 2, Anforderungen 3, Prozesse 4, Prozessunterstützung 5 (Infrastruktur, Software, Organisation, Standardprodukte), Geschäftsvorfälle 6, Produkte 7, deren Vernetzung und Abhängigkeiten 8 erfasst, modelliert, dokumentiert und validiert. Weiter werden bei Bedarf ein Risiko- und Qualitätsmanagement 9, 10 unterstützt.

[0013] Die bereits erwähnten Modelle sind statische Betrachtungen und beziehen sich auf einen bestimmten Zeitpunkt (Slot). Für diesen Zeitpunkt werden alle Ziele, Definitionen, Beschreibungen, Regeln, Ausnahmen, Zustände und Verhalten beschrieben. Die Veränderung über die Zeit wird mittels der Veränderung zwischen zwei Zeitpunkten (Slots) ermittelt. Durch Vergleichen und Zusammenführen mittels Compare-&-Merge-Algorithmen wird ein Projektportfolio (Handlungsbedarf) errechnet. Eine Liste aller Veränderungen kann anschliessend zur Definition von Projekten 12 herbeigezogen werden. Diese Arbeiten werden alle durch den Approach mittels Ergebnislisten, Methoden und Techniken, Checklisten usw. begleitet.

[0014] Fig. 2 zeigt schematisch eine Überwachung von Prozessen mit Parametern gemäss Fig. 1. Damit ein nachhaltiger Nutzen von einem Engineering gemäss Fig. 1 in einem Unternehmen entsteht, werden an definierten Stellen im Unternehmen Sensoren 13 oder Adapter 14 installiert. Diese Sensoren 13 können auf manueller oder elektronischer Basis funktionieren. Die Sensoren 13 dienen dazu, um relevante Information aktiv oder passiv abzutasten und an die Prozessüberwachung 15 zu melden. Zu diesem Zweck werden Schwellenwerte resp. Grenzwerte definiert.

[0015] Mit den gesammelten Informationen können, basierend auf der Konfiguration der Prozessüberwachung, Aktionen ausgelöst werden. Die Informationsverbreitung kann auf konventionelle Art, z.B. mittels Papier 16 oder aber auf andere Art und Weise, z.B. elektronisch oder unter Ausnutzung bestehender Netzwerke (z.B. Mobilfunknetz), verteilt werden. Je nach Einstellungen und Schwellwerten wird eine Aktion ausgelöst, z.B. eine SMS, ein Dokumentenversand via E-Mail, ein Transferieren von Informationen auf ein Mobil-Gerät, z.B. PalmTop 17 oder portabler Computer 18 oder eine Sprachnachricht via Telefon übermittelt. Selbstverständlich soll von aussen auch auf Situationen agiert und reagiert werden können. Es sollen z.B. Schwellwerte, Parameter und Konfigurationen verstellt werden können. Diese Veränderungen sind manuell oder elektronisch (z.B. über ein Mobil-Gerät) realisierbar. Bei Bedarf besteht somit die Möglichkeit, weitgehend ortsunabhängig alle wichtigen Informationen beziehen, abfragen und darauf reagieren zu können.

[0016] Fig. 3 zeigt schematisch eine Übersicht über Sensoren und deren Anordnung in einem komplexen System.

[0017] Sensoren 13 werden bevorzugt in Form von Softwareprodukten in einen Betrieb eingefügt. Andere Arten von Sensoren (z.B. Embeded Systems) sind möglich. Die Erfindung erlaubt zudem, eine passive und aktive Datenbank-Abfrage oder Store Procedure zu realisieren. Zudem besteht bei Bedarf die Möglichkeit, Online-Bewegungen auf Anteilen (Shares) oder Foldern zu analysieren, um z.B. aktuelle Daten, die via Flat-File zur Verfügung gestellt werden, einzubeziehen. Es besteht somit erstmals die Möglichkeit, Veränderungen von Modellinformation oder Kennzahlen automatisch zu überwachen und zu kontrollieren. Basierend auf diesen aktuellen Kennzahlen und Modellinformationen können Informationen aus dem laufenden Betrieb für das Modellieren von weiteren Sollzuständen massive Erleichterungen bringen. Dies bedingt aber, dass nach dem Engineering ein Betriebsmodell zur Überwachung und Steuerung des laufenden Betriebs aus dem Engineeringmodell erzeugt wird.

[0018] Fig. 4 zeigt schematisch eine Verwendung eines Servers. Ein Aspekt der Erfindung besteht darin, sämtliche relevante Grundlagen via einen Server, zum Beispiel über das Internet, zur Verfügung zu stellen. Auf diesem Server ist die gesamte Software installiert. Dadurch kann verhindert werden, dass Software im Unternehmen selbst installiert werden muss. Mit einer serverbasierten Plattform ist es zudem möglich, dass Applikationen und Workflows direkt generiert werden können. Diese generierten Applikationen können auch direkt auf dieser Plattform für den Betrieb zur Verfügung gestellt werden. Will jemand Applikationen oder Modelle nicht auf dieser Plattform betreiben, kann er diese nach dem Generieren herunterladen. Eine serverbasierte Installation (ASP) soll bei Bedarf auch zum Vergleich mit andern genutzt werden können (Benchmarking). Dies erfolgt durch das Anbieten von Vergleichsmodellen, die in einer Datenbank (Repository) abgelegt sind. Als weitere Schritte werden Kunden oder Gäste auf dieser Plattform ihre optimale Lösung («Best Practices») anderen zum Kauf anbieten können oder solche Muster von anderen herunterladen können. Als letzte bis heute definierte Funktionalität sollen auch Modelle nur zur Qualitätssicherung auf die Plattform geladen werden können. Mit der ASP-Version folgt ein weiterer Schritt in Richtung elektronischem Ingenieur/Berater. Über eine solche Plattform, die gleichzeitig ein Telefonberatungszentrum (Call Center) und/oder ein Forum (Chat, FAQ, News Group) anbieten kann, können ohne weiteres auch manuelle, durch Menschen erstellte Resultate, zur Komplettierung der verfügbaren Informationen, zur Verfügung gestellt werden. Mit dieser Funktionalität steht die erste Version eines elektronischen oder anonymen Engineers/Consultants zur Verfügung.

[0019] Fig. 5 zeigt eine Anbindung an eine Wissensdatenbank 51. Die Erfindung erlaubt es, mit einem Knowledge-Management-System verbunden zu werden. Diese Verbindung ermöglicht das Navigieren und das Zugänglichmachen von Informationen an ein grösseres Zielpublikum. Mit einfachen Suchbegriffen sollten so Informationen abgefragt und modelliert werden können. Gerade die stetige Prozessverbesserung und die Qualität der Dokumentation sollte durch diese Funktionalität erhöht werden.

[0020] Fig. 6 zeigt vereinfacht dargestellt die Verarbeitung von Informationen. Die Informationsverarbeitung erfolgt in der Regel mittels eines Input-basierten Metamodells, das mittels mathematischer Funktionen und basierend auf voreingestellten oder konfigurierten Parametern Modelle, Files, Daten, Grafiken und Dokumente als Output zur Verfügung stellt. In der linken Bildhälfte sind die Eingangsdaten dargestellt. Sie basieren auf Sensoren und anderen Quellen. Als andere Quellen kommen portable Geräte (mobile Telefone), Datenbanken, Personen usw. in Frage. Auf der rechten Seite sind die Ausgangsgrössen schematisch dargestellt. Es handelt sich hierbei um Zwischenresultate, Resultate, Informationen für Datenbanken, Berichte und Flussdiagramme.

[0021] Fig. 7 zeigt schematisch die Grundstruktur des Verfahrens. Diese basiert bevorzugt auf objektorientierten Konzepten. Die Implementation erfolgt daher mittels einer geeigneten Programmiersprache wie z.B. Java. Essentiell sind die konsequent angewandten Konzepte der Objekt-Orientierung in den definierten Ergebnissen (z.B. Prozess, Geschäftsvorfall, Produkt usw.). Neben den Objekt-orientierten Konzepten (z.B. Kapselung, Vererbung, Objekt, Klasse usw.) ist auch die Praxisorientierung (z.B. Reduktion der Komplexität), die Wiederverwendung, der Pragmatismus (Transparenz, Konsistenz) und die Vernetzung zu erwähnen.

[0022] Die Grundlage zeichnet sich besonders dadurch aus, dass mit dem erfindungsgemässen Verfahren nicht nur Modelle modelliert und dokumentiert, sondern dass sämtliche Modelle auch validiert werden können. Je nach Fertigstellungsgrad können Modelle mit Betriebsinformationen versehen (online) oder verglichen (ASP, Benchmarking) werden.

[0023] Fig. 8 zeigt schematisch anhand von Würfeln 81, 82 Schlüsselergebnisse zu verschiedenen Zeitpunkten. Diese Schlüsselergebnisse und deren Vernetzung können nach Bedarf erweitert werden. Im Kern sind hier sechs Schlüsselergebnisse enthalten, die mit den restlichen Ergebnissen verknüpft sind. Die Schlüsselergebnisse sind auf den Seiten eines Würfels dargestellt. In der schematischen Würfeldarstellung ist ersichtlich, wie diese Schlüsselergebnisse zusammenhängen. Alle Modelle können einzeln erstellt (modelliert) und dokumentiert werden. Der essentielle Vorteil liegt jedoch darin, dass zwei durch eine Kante miteinander verbundene Modelle mittels eines dritten Modells, welches ebenfalls durch eine Kante mit den beiden anderen verbunden ist, validiert werden kann. Somit können Auswertungen von Kanten (Beziehungen) wie auch Knoten (Objekte) durchgeführt werden. Somit kann jegliche Art von Informationen modelliert, dokumentiert und validiert werden.

[0024] Auf dem grossen 80 wie auch auf dem kleinen Würfel 81 sind sechs Modelle ersichtlich. Prozess 82, Element 83, Information, Funktion 84, Wertschöpfungsketten 85, Produkt 86 und 87. Um diesen Würfel herum sind schematisch Ergebnisse wie Qualitätssicherung 88 und Risikomanagement 89 dargestellt, die durch oder aus einem oder mehrere anderen Ergebnissen erzeugt oder abgeleitet worden sind (Matrizen, Qualitäts- und Risikografiken). Es gibt aber auch Ergebnisse, die auf alle anderen Ergebnisse einwirken Strategie 810, Anforderungen 811 oder eine einfache Beziehung haben. Entlang diesen Beziehungen wird später Auswirkungsanalyse gemacht.

[0025] Der grosse Würfel 80 stellt ein komplexes System, z.B. eine Firma, zu einem bestimmten Zeitpunkt dar (Slot) und der kleine Würfel 81 dieselbe Firma zu einen anderen Zeitpunkt. Zwischen diesen zwei Würfeln 80, 81 entsteht ein Handlungsbedarf der mittels Projekt-Portfolio konkreten Projekten zugeteilt werden kann. Der Handlungsbedarf kann zum Beispiel mittels eines Merge-&-Compare-Algorithmus auf verschiedene Art und Weise erzeugt werden (Optimale Synergie, wenig Schnittstellen, minimale Veränderung).

[0026] Bei den Beziehungen untereinander spielt das Arbeitsprodukt 87 eine elementare Rolle. Ein Arbeitsprodukt, auch Workprodukt genannt, ist ein Objekt, das zwischen zwei oder mehreren Prozessen, Elementen, Geschäftsvorfällen usw. als Informations- und Funktionsbehälter charakterisiert ist. Das bedeutet, dass Objekte hin- und hergeschoben werden (Interfaceobjekt). Ein Workprodukt kann irgendwo entstehen und auch wieder enden. Ein Workprodukt kann auch eine definierte Beziehung zu einem Produkt besitzen.

[0027] Fig. 9 zeigt schematisch Workprodukte auf drei verschiedenen Metaebenen 90, 91, 92. Das Workprodukt ist eines der essentiellen Ergebnisse des erfindungsgemässen Konzepts. Auf diesem Ergebnis und seinen Abhängigkeiten und Prinzipien baut einerseits das Prozess-Engineering und andererseits ein Teil des Qualitätsmanagements auf. Als weiterer Punkt ist auch das umfassende Risikomanagement zu erwähnen, das durch das Zusammenspiel von Knoten (Objekte) und Kanten (Beziehungen) aufbaut. Zwischen einem Workprodukt und einem Produkt und zwischen Workprodukten untereinander bestehen eindeutige formulierbare Beziehungen. Diese Beziehungen können sich auch über mehrere unterschiedlichen Ebenen auswirken. Diese Abhängigkeiten können Typen, Aggregate, Kompositionen oder einfache Beziehungen sein. Durch diese Betrachtung von Ergebnissen, die in einer Firma benutzt oder erzeugt werden und in einem Engineering als Workprodukt modelliert werden, entsteht ein Netz. Wie bereits erwähnt, können unter Mithilfe einzelner Objekte und des Netzes eindeutige Aussagen (z.B. Qualität, Auswirkung) gemacht werden. Diese Objekte tragen auch für das Engineering und später für eine Workflow-Simulation essentielle Information wie Mengen, Häufigkeiten, die Art und Weise des Transportes (manuell, elektronisch) oder z.B. zeitliche Verhaltensweisen.

[0028] Fig. 10 vereinfacht die verwendeten Dimensionen. Die dargestellte Betrachtungsweise stützt sich dabei zum Teil auf das obenerwähnte Buch «Der Objekt Orientierte Weg» (OOW) desselben Anmelders (ISBN 3-9521597-0-0) ab. Damit Ergebnisse eindeutiger definiert und positioniert werden können, ist bei der dargestellten Betrachtung von Zusammenhängen der Übersichtlichkeit halber eine Dimension weggelassen worden, indem die Dimension Methoden/Techniken mit der Dimension Ergebnisse/Aktivitäten verschmolzen wurde. Da Methoden und Techniken vor allem Ergebnisse/Aktivitäten-bezogen sind, bleibt die Aussagekraft dennoch weitgehend erhalten. Die vierte Dimension, Vorhaben, wurde auf die zweite Dimension als Ersatz von Methoden/Techniken gelegt. Das Vorhaben bezieht sich dabei immer auf Ergebnisse und Aktivitäten. Bei dieser Dimension handelt es sich eigentlich nur um Vorlagen. In diesen Vorlagen wird festgehalten, welche Ergebnisketten in welchem Detaillierungsgrad zu welchem Gesamtergebnis führen und welche Aktivitäten dazu verwendet werden. Implizit in dieser Betrachtung wird auch definiert, nach oder mit welchen Methoden und Techniken diese Ergebnisse erarbeitet werden. Die dritte Dimension, Architektur, blieb unverändert. Durch diese Veränderung bleibt die Gesamtaussage erhalten, die Komplexität wird jedoch erheblich reduziert und die Betrachtung und Nutzung vereinfacht.

[0029] Fig. 11 zeigt schematisch eine Darstellung von Strategie und Zielaufteilung. Einer der grossen Vorteile des erfindungsgemässen Konzepts besteht darin, dass über einfache Regeln Objekte miteinander in Beziehung gesetzt werden. Dieser Grundsatz ist der Natur abgeschaut, bei der auch fast jedes Element eine Beziehung zu einem anderen pflegt und über dieses beeinflusst werden kann. Wenn man diese gegenseitigen Abhängigkeiten richtig betrachtet und definiert, können aus den Resultaten interessante Aspekte abgeleitet werden. Erstens kann mittels dieser Verknüpfungen etwas zur Qualität ausgesagt werden, anderseits vollständige Auswirkungsanalysen durchgeführt werden. Damit diese Aussagen auch tatsächlich einen Nutzen aufweisen, müssen diese sehr einfach hergestellt und eindeutig definiert werden können. Es muss definiert werden, was die einzelnen Beziehungen bedeuten, wie diese aufgebaut sind und welche Wirkung sie auf andere ausüben können. Wenn man dieses Netzwerk von Objekten beherrscht, das bedeutet, über jedes Objekt die wichtigste Information und Partner kennt, lassen sich mit einfachen Algorithmen essentielle Aussagen mit einem hohen Mehrwert machen. Die verwendeten Algorithmen sind sehr einfach. Sie beruhen auf den Gesetzen von Klasse/Objekt, Aggregation, Komposition, Vererbung, Summenbildung und der Wahrscheinlichkeit. Wie bereits erwähnt wurde, ist das erfindungsgemässe Konzept als Framework aufgebaut. Mit dieser Grundlage wird ermöglicht, dass die nachfolgend aufgeführten Modelle und Definitionen ohne grossen Aufwand jederzeit erweitert werden können.

[0030] Eine Strategie beim Beeinflussen resp. Führen eines komplexen Systems, z.B. einer Firma, besteht in der Regel aus verschiedenen Thesen 110. Thesen 110 können untereinander in Beziehung stehen. Diese 110 Thesen können wieder aus Thesen oder aus verschiedenen Zielen 111 bestehen. Die Ziele einer These sind definiert, qualifiziert, quantifiziert, stehen in einer Reihenfolge, sind priorisiert und können untereinander in Beziehung stehen. Die einzelnen Ziele 111 einer These ergeben immer hundert Prozent. Das bedeutet, dass neben den bereits erwähnten Eigenschaften auch eine relative und eine absolute Gewichtung eines Zieles innerhalb einer These und einer Strategie erhalten ist. Dies ergibt sich daraus, dass auch die Summe aller Thesen einer Strategie hundert Prozent ergeben. Mittels einer Präferenzmatrix 112 kann neben der absoluten und relativen Gewichtung auch eine Reihenfolge ermittelt und definiert werden. Nach dieser Definition werden die einzelnen Zielsetzungen oder Thesen anderer Objekte innerhalb des erfindungsgemässen Konzepts zugeteilt. Diese Zuteilung kann zu einem Externen Agenten, Prozess, Element auf der Unterstützungsebene einem Workprodukt, einer Anforderung usw. zugeteilt werden. Mit diesen Verknüpfungen kann definiert werden, zu wie viel Prozent ein Objekt von dieser Strategie betroffen sowie zu wie viel Prozent eine Strategie vom Objekt anhängig ist oder abgedeckt wird.

[0031] Fig. 12 zeigt schematisch, wie Anforderungen 120 modelliert werden können. Damit eine Strategie erfolgreich umgesetzt werden kann, müssen Anforderungen 120 definiert werden. Diese Anforderungen werden z.B. in funktionale, sachliche, terminliche, personelle und/oder soziale Aspekte unterteilt. Anschliessend werden diese Anforderungen in quantifizierbare 121 und nicht quantifizierbare 122 typisiert derart, dass sie über eine Beziehung 123 mit anderen Objekten verknüpft werden können. Wie bereits beschrieben, gibt es verschiedene Arten von Verknüpfungen. Was die Folge aus diesen Verknüpfungsarten ist, wird weiter unten erläutert. Anforderungen können auch wie Ziele untereinander in Beziehung stehen, definiert, priorisiert, sortiert und anderen Objekten zugeteilt werden. Somit ist es relativ einfach herauszufinden, wie und in welcher Form Anforderungen verknüpft sind, wie und was für Auswirkungen diese auf andere Objekte ausüben können.

[0032] Fig. 13 zeigt schematisch den Aufbau eines Produktmodells. Im schon erwähnten Buch «Der Objekt Orientierte Weg», fortan OOW genannt, sind Prozesse, Geschäftsvorfälle, Komponenten und Klassen detailliert beschrieben. Die darin erwähnten Definitionen werden bei den nachfolgenden Erläuterungen zum Teil übernommen.

[0033] Bei den Prozessen bleibt die Definition wie gehabt. Die Geschäftsvorfälle sind klarer definiert und stärker mit den anderen Objekten in Beziehung gebracht. Vgl. hierzu die Beschreibung der Figuren (Kapitel 9.2 und 10). Die im Buch «OOW» beschriebenen Komponenten haben sich stark auf die Entwicklungen im Bereich IT fokussiert. Dieser Fokus wurde um Infrastruktur, Organisation, elektronische und mechanische Bausteine und Sachmittel erweitert. Diese Ebene wird neu (Prozess)-Unterstützungsebene genannt. Basierend auf diesen Erweiterungen können bei der Auswirkungsanalyse dieser Ebene wesentlich mehr Aussagen gemacht werden. Auch die Betrachtung, Aussagekraft und Bewertung von Schnittstellen zwischen den verschiedenen Objekten wird durch diese Erweiterung aufgewertet. Aus reiner Verständlichkeit wurde die Klassenebene zu Informations- und Funktionsebene umgetauft. Die Konzepte der Objektorientierung werden dennoch konsequent auf allen Objekten angewendet aber zu besseren Verständlichkeit anders bezeichnet. Als neue Elemente sind das Produkt, die Strategie, das Projektportfolio und die Anforderung dazugekommen.

[0034] Fig. 13 zeigt schematisch ein Produktmodell vereinfacht dargestellt als mathematisches Modell. Das Produktmodell ist eine neuartige Betrachtungsweise im Framework. In einem Produktbaukasten werden verschiedene Arten und Teile von Produkten und Dienstleistungen in Beziehung zueinander gesetzt. Eine Produkt-Klasse 131 repräsentiert dabei eine Kategorisierung von Produkten. Diese sogenannten vereinten Produkte (combined products) 132 können aus elementaren Produkten 133 und zusammengesetzten Produkten (composite products) 134 oder aus bereits definierten vereinten Produkten 135 zusammengesetzt werden. Mit diesem vereinten Produkt kann ein Tarif, ein Medium oder eine weitere Eigenschaften verknüpft werden. Diese werden bevorzugt durch eine Klassencharakteristik repräsentiert. Es sind zwei Repräsentanten von vereinten Produkten bekannt. Das eine wird Produkt 136 und das andere Service 137 genannt. Mit diesem Modell kann nun jedes noch so komplizierte Produkt zusammengestellt oder konstruiert werden. Selbstverständlich können die bereits beschriebenen Objekte Ziele und Anforderungen oder auch andere mit den einzelnen Teilen dieses Baukastens verknüpft werden.

[0035] Fig. 14 zeigt schematisch ein mögliches Projektmanagement. Wie bereits erwähnt, wird das Projektmanagement als Handlungsbedarf zwischen zwei Zuständen definiert. Dieses Prinzip wird im hierin diskutierten Verfahren durch eine Szenarien- und Variantenbildung erweitert. In diesem Zusammenhang wird daher von Business-Improvement gesprochen. Das Modell wird weiter durch die Verknüpfung zum Produktmodell ergänzt, was wiederum eine weitere Betrachtungsweise ermöglicht. Die auf den verschiedenen Ebenen definierten Modelle (Prozess, Element, Information/Funktion) und Objekte ergeben oder repräsentieren einen gesamtheitlichen Zustand eines komplexen Systems, z.B. einer Firma. Diese Zustände können kopiert erweitert und oder reduziert werden und stellen entweder ein Szenario oder eine Variante dar. Durch einen ausgeklügelten Algorithmus können sämtliche Unterschiede auf allen Ebenen und allen Objekten ermittelt werden und als Change-&-Compare-Liste dargestellt werden. Diese Liste mit Abweichungen (Delta Liste) stellt den sogenannten Handlungsbedarf zwischen zwei Zuständen dar, der anschliessend z.B. einem Projekt zugeteilt und auf dieses angewandt werden kann. Die einzelnen Differenzen können anschliessend Ergebnisse oder Templates (Summe von aufeinanderfolgenden Ergebnissen, Vorhaben) zugeteilt werden, was als Resultat einem Projektplan entspricht. In diesem Projektplan sind einerseits Ergebnisse wie auch Aktivitäten sichtbar, mit denen die ausgewiesene Differenz ausgearbeitet werden kann. Somit lassen sich mit dem erfindungsgemässen Konzept von der Strategie bis zum konkreten Projekt Auswirkungen analysieren, dokumentieren und auch validieren. Mit diesem Vorgehen ist es möglich, Projekte viel höher zu standardisieren, was seinerseits wieder eine höhere Stabilität, Wiederverwendbarkeit und Sicherheit zur Folge hat. Mit diesem Vorgehen können Risiken in der Unternehmensentwicklung massiv reduziert, die Effizienz gesteigert, die Effektivität und die Wirtschaftlichkeit erhöht werden.

[0036] Fig. 15 zeigt schematisch eine mögliche Form von Qualitätsmanagement. Das Qualitätsmanagement im offenbarten Konzept beruht auf der Verknüpfung von Objekten. Diese vernetzte Betrachtungsweise ermöglicht es, die modellierten und dokumentierten Modelle zu validieren. Unter Validieren wird das Prüfen von Zuständen, Abläufen und Modellen mittels mindestens eines weiteren Modells verstanden. Wenn als Beispiel die Summe aller definierten Geschäftsvorfälle mit dem Prozessmodell und derer Definition verglichen wird, kann eine Aussage zur Qualität des Prozessmodells oder des Geschäftsvorfalles gemacht werden. Das Prinzip der Qualitätssicherung besteht demzufolge darin, die Qualität eines Modells mittels eines oder mehrerer anderer Modelle zu ermitteln und auszuweisen. Die Ausweisung der Qualität kann einerseits als Kennzahl oder mittels Detailinformationen erfolgen.

[0037] Eines der elementaren Objekte, das betrachtet wird, ist der Geschäftsvorfall. Beim Geschäftsvorfall handelt es sich um eine systematische Aneinanderreihung von Ereignissen und Aktionen. Durch die Erweiterung der reinen Ereignis/Aktionsbetrachtung mittels Workprodukts entsteht auch die Möglichkeit, eine Aussage zur Qualität z.B. eines Prozesses zu machen. Diese erfolgt auf der Grundlage, dass jeder Input und jeder Output eines Prozesses mittels Geschäftsvorfall erzeugt wird.

[0038] In einer Matrix dargestellt werden auf jeder Seite die Prozesse aufgelistet und in den entsprechenden Feldern das Workprodukt eintragen, das von einem Prozess zum anderen verschoben wird. Dadurch erhält man eine Übersicht über sämtliche Schnittstellenobjekte. Wenn dieselbe Matrix verwendet wird, um darauf die Workprodukte einzutragen, die durch einen Geschäftsvorfall verwendet werden, kann eine gewisse Überdeckung festgestellt werden. Bei einem Workprodukt, das keine Überdeckung aufweist, ist entweder die Prozessdefinition oder die Definition des Geschäftsvorfalls unvollständig. Dasselbe Prinzip kann auch über die Modellebene hinaus angewendet werden, wobei auch dabei eine Aussage zur Qualität abgeleitet werden kann. Zusammengefasst heisst das, die Qualität eines Modells wird immer mit einem oder mehreren anderen Modellen überprüft. Mit dieser Methode lässt sich die Vollständigkeit, die Konsistenz als auch bedingt die Richtigkeit von Modellen überprüfen. Weiter wird sehr transparent aufgezeigt, wer was wann verwendet. Bei einer Richtigkeit wird davon ausgegangen, dass diese höher ist, wenn zwei unabhängige Definitionen (Modelle) zum gleichen Resultat führen. Dieses Prinzip kann auch über verschiedene Ebenen oder Objekttypen angewendet werden. Zum Beispiel wird ein Geschäftsvorfall auf Stufe Prozess und der gleiche Geschäftsvorfall auf Stufe Unterstützung miteinander verglichen. Bei dieser Betrachtung, unter Berücksichtigung, dass der Prozess und das unterstützende Element miteinander verbunden sind, kann eine Qualitätsaussage über Objekte auf verschiedenen Ebenen gemacht werden. Implizit natürlich auch über die Güte des Geschäftsvorfalles selbst.

[0039] Fig. 16 zeigt schematisch eine mögliche Form des Risikomanagements. Für die Berechnung und das Propagieren von Risiken gelten vereinfacht dargestellt die folgenden Prinzipien.

[0040] Für jedes Objekt 161 werden, falls erforderlich, ein oder mehrere Risiken 162 definiert. Für jedes Risiko wird wiederum eine Definition, z.B. eine Eintrittswahrscheinlichkeit, eine Tendenz, ein Frühwarnindikator, Netto- und Brutto-Risiko, Kosten, ein oder mehrere Aktionen zur Verhinderung des Risikos sowie Grundlagen und Abhängigkeiten des Risikos selbst, definiert. Diese Abhängigkeiten können entlang des bereits definierten Netzwerkes laufen, können aber auch anders definiert werden. Die Berechnung der Risiken erfolgt anschliessend basierend auf dem Netzwerk und der prozentualen Verteilung von demselben. Will man das Risiko entlang einer Kette rechnen (z.B. Geschäftsvorfall), gilt das grösste ermittelte Risiko als das Risiko der ganzen Kette, sofern die Beeinflussung immer positiv 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. Man spricht an dieser Stelle auch vom Risikoappetit. Beim Risikoappetit wird die Sensibilität eines Objektes, auf ein Risiko zu reagieren, beschrieben. Abhängig von diesem Netzwerk erfolgt später auch die Alarmierung.

[0041] Fig. 17 zeigt schematisch die bei der Abstrahierung und Modellbildung auftretenden Abhängigkeiten. Vereinfacht dargestellt basiert das Grundkonzept auf drei Grundlagen. Erstens auf einem Metamodell, zweitens auf den Grundkonzepten der Objektorientierung (Kapselung, Vererbung, Klasse/Objekt usw.) und drittens auf dem Gedankengut des vernetzten Denkens und Handelns. Sämtliche Objekte stehen in einer definierten Abhängigkeit zueinander und weisen eine klare Definition auf. Betreffend der Vernetzung der einzelnen Objekte ist zu bemerken, dass es Beziehungen gibt, die aus der methodischen Betrachtung heraus bereits abhängig vom Objekttyp existieren (z.B. Geschäftsvorfall/Workprodukt, Prozess/Workprodukt, Prozess/Element) und solchen, die vom einem Anwender eingegeben werden (z.B. Ziel/Anforderung, Anforderung/Element). Im ersten Fall entstehen die Beziehungen per Definitionen (als Gesetz), im zweiten Fall wird diese durch den Benutzer definiert, hergeleitet (z.B. Externer Agent/Anforderung).

[0042] Jede Beziehung zwischen zwei Objekten, die von einem Anwender erstellt oder durch das System erzeugt wird, kann verschiedene Definitionen annehmen. Welche Definition Sinn macht, kann der Anwender bestimmen oder werden vom System definiert und/oder eingeschränkt, da sie keinen Sinn machen. Ein Prozess, der auf einem Modell basiert, kann zum Beispiel nur dekomponiert werden. Der Prozess auf der dekomponierten Stufe wird aus diesem Grund auch Subprozess genannt. Eine Typisierung von Prozessen auf der Prozessmodellebene macht absolut keinen Sinn. Im Falle eines Geschäftsvorfalles kann frei gewählt werden, ob der child Geschäftsvorfall ein Typ oder ein Aggregat, eine Dekomposition oder nur in einer Beziehung zum parent steht. Erstellt man einfache Abhängigkeit (z.B. zwischen Risiken), ist neben der Richtung, der Beeinflussung (positiv, negativ), der Bedeutung auch noch die Gewichtung zu definieren. Werden durch das System Berechnungen durchgeführt, werden je nach Beziehungstyp andere Resultate entstehen. Wird als Beispiel ein Geschäftsvorfall durchgerechnet, wird je nach Beeinflussung und Richtung addiert oder subtrahiert. Entstehen Schlaufen, wird mit Faktoren gerechnet. Es ist zu beachten, dass es auch Beziehungen gibt, bei denen eine Qualifizierung nicht sinnvoll ist (z.B. Prozess/Element Unterstützung).

[0043] Fig. 18 zeigt schematisch einen Vergleich zwischen Workprodukten und Produkten. Das Workprodukt und das Produkt nehmen bei der Modellbildung eine besondere Stellung ein. Das Workprodukt und das Produkt sowie die Workprodukte untereinander können in verschiedenen Verhältnissen zueinander stehen. Wesentlich ist dabei, dass dieses Zusammenwirken genau definiert werden muss, damit nicht falsche Informationen aus den gebildeten Modellen abgeleitet werden. In Fig. 18sind einige dieser Definitionen dargestellt, die zeigen, wie vorhandene Objekte zusammenwirken. Dieses Zusammenwirken kann auf die Qualitäts-, auf das Risiko- sowie auf das Kostenmanagement Einfluss nehmen. Wesentlich ist, dass ein Workprodukt auf unterschiedlichen Ebenen gleich oder aber sehr verschieden sein kann. Im Extremfall kann es sogar einen Teil vom Produktmodell oder einem Produkt selber entsprechen. Im Weiteren kann ein Workprodukt auch jede definierte Form von Beziehung zu einem anderen Workprodukt einnehmen (Aggregation, Komposition usw.). Selbstverständlich können ein Workprodukt sowie auch ein Produkt mehrere Zustände annehmen. Diese Zustände können bei einem Workprodukt Auftrag, zum Beispiel Auftrag in Arbeit, Auftrag sistiert, Auftrag abgeschlossen, sein. Während der Modellierung bedeutet dies, dass nicht für jeden Zustand ein eigenes Workprodukt erstellt werden muss, sondern nur seine Eigenschaft geändert wird. Dies ist eine wichtige Grundlage zur Reduzierung einer unermesslichen Vielfalt eines Workprodukts. Bei dem Arbeiten mit Workprodukten ist es immer wichtig zu wissen, ob man von einer Definition (Auftrag) oder von einer Instanz (z.B. Auftrag von A) spricht. Modelliert werden normalerweise nur Definitionen. In diesem Zusammenhang ist es wesentlich zu erwähnen, dass Zustände eines Workprodukts oft durch einen Geschäftsvorfall entstehen und verändert werden.

[0044] Fig. 19 zeigt schematisch eine Analyse von Auswirkungen. Das in der Modellbildung definierte Netzwerk dient zur Analyse von Auswirkungen. Auswirkungen können aber nicht nur entlang der Beziehungen errechnet werden, sondern auch über Zustände von verknüpften Objekten. Zum Beispiel weist jedes Workprodukt zu einem bestimmten Zeitpunkt einen bestimmten Zustand (state) auf. Diesen Zustand hat das Objekt durch bestimmte Vorbedingungen, Regeln usw. erreicht. Dieser Zustand kann durch ein Ereignis verändert werden. Durch die Beziehung zum Produkt kann sich implizit auch das Produkt verändern. Durch die Definition bei der Modellbildung, dass ein Geschäftsvorfall vereinfacht dargestellt eine Wertschöpfungskette oder ein Teil einer solchen ist, entsteht eine Beziehung zwischen einem Schritt eines Geschäftsvorfalls und einem Workprodukt. Da ein Schritt eines Geschäftsvorfalls immer einem Prozess zugeteilt ist, entsteht eine starke Bindung zum Prozess.

[0045] Wenn diese Grundlage etwas genauer betrachtet wird, können somit die Zustände eines Workprodukts entlang eines Geschäftsvorfalls eine gesamtheitliche Wirkung auf ein Produkt wiedergeben. Aus diesen und weiteren Ableitungen von Beziehungsketten können sehr effizient gute und qualifizierte Aussagen zu Abhängigkeiten und Auswirkungen gemacht werden. Dieser Zusammenhang zwischen Produkt/Workprodukt und Geschäftsvorfall und die Interpretation aus diesem Zusammenwirken ist aber nur einer von vielen Vorteilen des gewählten Vorgehens.

[0046] Fig. 20 zeigt schematisch Risiken und deren Zusammenhänge. Bei der Betrachtung von Risiken gelten in der Regel dieselben Gesetzmässigkeiten, die bereits weiter oben erwähnt wurden. Einerseits ist die Art der Beziehung wichtig, andererseits die Beeinflussung. Basierend auf diesen zwei Grundlagen können Risiken ermittelt werden. Durch die Verknüpfung von Elementen und durch die Möglichkeit, dass ein Objekt nur einer Repräsentanz (Aggregation) mehrerer anderer Objekte entsprechen kann, können auch Schlaufen (Loops) entstehen. Diese Schlaufen können Gesamtrisiken beeinflussen. Mit diesem Beispiel soll ersichtlich gemacht werden, wie schwer es ist, Risiken zu berechnen. Aus diesem Grund ist es in der Regel vorteilhaft, ein Abhängigkeitsdiagramm zu erstellen, damit die Auswirkungen auch visuell erkennbar sind.

[0047] Fig. 21 zeigt schematisch eine Generierung von Szenarien und Varianten. Wenn eine Prozesslandschaft aufgrund des oben erläuterten Modellbildungsprozesses erstellt ist, kann eine ideale Unterstützung durch Systeme nach verschiedenen Gesichtspunkten erzeugt werden. Diese Bildung von Szenarien erfolgt unter Anwendung unterschiedlicher Algorithmen. Dabei ist es vorteilhaft, so wenige Schnittstellen wie möglich zu verwenden. Ideale Prozessunterstützung, ideale Geschäftsvorfall-Unterstützung, geringe Kosten usw.

[0048] In Fig. 21 ist vereinfacht eine Variante einer solchen generierten Lösung abgebildet. Die erfindungsgemässe Vorgehensweise erstellt bei solchen Generierungen eigene Account-Modelle, die mittels Merge & Compare miteinander verglichen werden können. Die einzelnen Lösungen werden aufgrund vordefinierter Best Practices (patterns) erstellt. Es werden also theoretisch mögliche Resultate wegen ungenügender Praxisrelevanz ausgeschlossen.

[0049] Fig. 22 zeigt vereinfacht ein Kostenmanagement und die dabei bevorzugt verwendeten Berechnungsalgorithmen. Berechnungen von Kosten basieren immer auf den Arten des Netzwerks oder der Beziehungen. Wie aus Fig. 22 zu ersehen ist, errechnet sich z.B. die Summe von drei Systemen je nach Art der Beziehung anders. Sind die beiden Child-Aggregate 221 abhängig vom Parent-Aggregat 222 und das Parent-Aggregat 222 besitzt selber einen Wert, so ist der Wert des Parent-Aggregats die Differenz zur Summe der beiden Child-Aggregate 221. Sind die beiden Child-Aggregate Typen vom Parent-Aggregat, ist der Wert des Parent-Aggregats irrelevant. Stehen jedoch die beiden Child-Aggregate in einer normalen Beziehung zum Parent-Aggregat, werden alle drei Werte addiert.

[0050] Die Kosten auf einem Element können sich verschieden zusammensetzen. In Fig. 22 ist eine mögliche Unterteilung vereinfacht dargestellt. Wenn z.B. errechnet werden soll, ob in einer bestimmten Periode die zur Verfügung stehenden Ressourcen ausreichen, kann dies durch ein Verrechnen der vorhanden Ressourcen mit den Investitionen erfolgen. Durch die Tatsache, dass in der Regel drei verschiedene Beziehungsmengen vorhanden sind, errechnet sich bei jedem Szenario ein anderer Wert. Einmal geht es gerade auf. Einmal wird eine Überdeckung und das andere Mal eine Unterdeckung errechnet.

[0051] Fig. 23 zeigt vereinfacht verschiedene Systeme, die in Beziehung untereinander stehen und einen oder mehrere Prozesse unterstützen. In dem gezeigten Beispiel wird ein Prozess nur von einem Geschäftsvorfall durchlaufen, was in der Praxis eher einer Ausnahme entspricht. Um die Prozesskosten zu errechnen, werden hier die im Verhältnis zu der prozentualen Unterstützung stehenden Systemkosten summiert und als Prozesskosten ausgewiesen. Dabei wird auch addiert wenn der Unterstützungsgrad mehr oder weniger als hundert Prozent beträgt. Erst wenn in der umgekehrten Richtung gerechnet wird, kommen in der Regel die Differenzen zur Geltung. In diesem Fall wird gerechnet, wie viel der Kosten eines Systems an wen weiterverrechnet werden können. Unterstützt ein System keinen Prozess, werden die Kosten nur auf den Geschäftsvorfall verteilt. Wenn die Kosten aller Geschäftsvorfälle mit den Prozesskosten verglichen werden, entsteht eine Abweichung (Delta), die sich aufgrund dieser Situation ergibt. Die Kosten eines Geschäftsvorfalles errechnen sich in der Regel aus den prozentualen Anteilen der Prozesskosten. Tritt der Fall auf, dass die Summe der Geschäftsvorfälle kleiner als hundert Prozent eines Prozesse ist, wird der Wert der Performance eines Prozesses einen dramatischen Einbruch erleben. Basierend auf diesen einfachen Rechnungsmodellen kann bereits Wesentliches zu den Prozesskosten und deren Entstehung ausgesagt werden.

[0052] Fig. 24 zeigt vereinfacht ein Risikomanagement und die dabei verwendeten Berechnungsalgorithmen. Bei der Berechnung von Gesamtrisiken gibt es verschiedene Ansätze. Zum Beispiel wenn die in Fig. 24 gezeigten einzelnen Risiken betrachtet werden, kann daraus Verschiedenes ableitet werden. Ein typischer Geschäftsvorfall wird, dadurch dass er keine eigenen Risiken definiert, auf Prozessebene gelb. Dies aus dem Grund, dass sechzig Prozent von einem gelben Prozess abhängig sind. Er könnte auch rot sein, da hundert Prozent des dritten Prozesses durch ein rotes System unterstützt wird und eine positive Abhängigkeit aufgeführt ist. Der Geschäftsvorfall auf Stufe System ist eindeutig rot, weil er durch ein rotes System läuft. Dies, obwohl das rote System nur einen Anteil von zehn Prozent ausweist. Die aus dieser Situation entstehenden Brutto- und Netto-Risikokosten können gemäss der Kostenformel ermittelt werden.

[0053] Fig. 25 zeigt vereinfacht die Abhängigkeit zwischen mehreren Prozessen. Schon durch einfache Modelle können sehr komplexe Abhängigkeiten entstehen. Aus diesem Grund ist es wichtig, die Abhängigkeiten von Risiken zu visualisieren und zu diskutieren, gerade wenn es um Tendenzen und Gesamtrisiken geht. Das in Fig. 24 gezeigte Beispiel weist von jedem Objekttyp nur maximal zwei Instanzen auf. Dennoch kann das Risiko nur schwer ermittelt werden, weil einerseits starke Abhängigkeiten und andererseits Schlaufen vorhanden sind. Aus diesem Grund wird bei der Berechnung von Risiken über die Abhängigkeiten immer das schlechteste verwendet. Wir sind uns bewusst, dass daraus immer vom schlechtesten Fall ausgegangen wird.

[0054] Fig. 26 zeigt ein Referenzmodell, respektive Fig. 27einen Referenzmodellprozess. Wenn im Umfeld der Erfindung von einem Referenzmodell gesprochen wird, wird auf einen Idealzustand Bezug genommen. Das Referenzmodell stellt dabei zum Beispiel eine Standardlösung im Bereich ERP dar. Der Lösungsbauer (z.B. SAP) baut seine Lösung entlang eines Idealzustandes auf. Somit sind die unterstützten Prozesse, die definierten Komponenten sowie die Informationshaltung und die Funktionsverteilung ideal. Diese Grundlage bereitet in der Regel Probleme während der Konfiguration und Einführung eines Modells in einem komplexen System. Wenn davon ausgegangen wird, dass die Modellbildung den Idealzustand darstellt und der Systembetreiber (z.B. Manager, Kunde) den aktuellen Zustand dokumentiert, kann ohne grossen Aufwand aufgezeigt werden, mit welchem Integrations-Szenario am wenigsten Aufwand entsteht. Zudem kann aufgezeigt werden, wo die Risiken liegen, was für Kosten entstehen und welche Qualitätsveränderungen zu erwarten sind. Dieses Vorgehen erspart dem Systembetreiber wie auch dem Integrator grosse Aufwände während der Analyse-/Designphase sowie der Implementierungsphase.

[0055] Allfällige Abweichungen (Delta) werden über die gleichen Merge-&-Compare-Algorithmen ermittelt, die bei der Szenarien- und Variantenbildung bereits zur Anwendung erwähnt wurden. Was hinzu kommt ist ein Mappingverfahren, das vereinfacht als Glossar bezeichnet wird. Mit Hilfe dieses Glossars können einerseits Definitionen und andererseits auch unterschiedliche Begriffe, Definitionen, Modelle auf unterschiedlichen Ebenen zusammen verglichen werden. Durch dieses Vorgehen ist es nicht erforderlich, dass das Referenz-Modell dem Kundenzustand angepasst wird, sondern kann interaktiv aufgebaut werden. Basierend auf diesen Resultaten kann der Systembetreiber schnell das erforderliche Migrationsprojekt definieren und die Auswirkungen aufzeigen.

[0056] Ein weiterer Vorteil von diesem Verfahren besteht darin, dass z.B. ein komplexes System wie eine Firma ideal auf einen Einführungszeitpunkt transformiert werden kann. Die gleichen Prinzipien können auch für ein Release-Management verwendet werden. Vor Einführung kann auf einfachste Art und Weise aufgezeigt werden, was für eine Auswirkung der neue Release auf den aktuellen Zustand haben wird, welche Funktionen verwendet oder nicht verwendet werden können/sollen und wer davon betroffen ist. Mit der gleichen Funktionalität können auch Auswirkungen auf Mandanten analysiert werden.

[0057] Fig. 28 zeigt verschiedene Berichte (Reports) 281, die anhand des beschriebenen Verfahrens und der das Verfahren umsetzenden Software erstellt werden können. Auf der einen Seite lassen sich Listen und Detailauswertungen mit Beziehungen (Links) der einzelnen Elemente erstellen. Die Dokumentation erfolgt bevorzugt in einem Textprogramm wie Word oder in HTML oder in einem neutralen Format wie z.B. Rich Text Format (rtf). In diesen Formaten werden auch sämtliche Cross-Referenzen ausgegeben. Zur Dokumentation sind des Weiteren Darstellungen in Form von Matrizen besonders geeignet. Matrizen werden vor allem dort verwendet, wo das Aufzeigen oder Auswerten von Verknüpfungen im Vordergrund steht. Weiter können Modelle auch grafisch ausgegeben werden. Informationen können auch an andere Werkzeuge übergeben werden. Dabei werden bevorzugt Schnittstellen basierend auf XML (extended markup language), Flat-File, API oder anderen Datenbankformaten verwendet. Selbstverständlich können auch bilaterale Schnittstellen auf Wunsch realisiert werden. Diese Schnittstellen basieren bevorzugt auf einem Metamodell und dem beschriebenen Framework aufgebaut und erstellt.

Claims (7)

1. Verfahren zum Modellieren, Dokumentieren und Validieren eines Systems, vorzugsweise einer Firma, unter Einsatz eines Computers sowie mindestens eines Sensors, welches die folgenden Schritte beinhaltet: a) Anbringen von einem oder mehreren Sensoren (13) im System, b) Bestimmen von mit den Sensoren (13) zu erfassenden Informationen, c) Parametrisieren der zu erfassenden Informationen, d) Darstellen der parametrisierten Informationen durch Objekte mit Parametern, e) Verknüpfen der Parameter der Objekte über standardisierte Beziehungen, f) Überprüfen und, nach Massgabe des Ergebnisses der Überprüfung, Ergänzen oder Ändern der erfassten Objekte und deren Parameter, g) Erfassen der parametrisierten Informationen mittels der Sensoren (13), h) standardisierte automatische Auswertung der Beziehungen und Eigenschaften der Objekte, i) Ausgabe der Resultate der standardisierten Auswertung in Form von Ausdrucken oder in elektronischer Form.

2. Verfahren gemäss Patentanspruch 1, dadurch gekennzeichnet, dass die Schritte e) bis g) periodisch wiederholt werden.

3. Verfahren gemäss einem der Patentansprüche 1 oder 2, dadurch gekennzeichnet, dass Schwellwerte für Parameter definiert werden, welche Schwellwerte zum Auslösen einer Aktion dienen, indem Informationen an ein Gerät übermittelt werden.

4. Verfahren gemäss einem der vorangehenden Patentansprüche, dadurch gekennzeichnet, dass die verwendeten Sensoren (13) Computer mit darauf installierten Softwareprodukten, mobile Geräte oder Eingabegeräte für Personen sind.

5. Verfahren gemäss einem der vorangehenden Patentansprüche, dadurch gekennzeichnet, dass die erfassten Informationen Geschäftsvorgänge in einer Firma betreffen.

6. Verfahren gemäss einem der vorangehenden Patentansprüche, bei welchem die Funktionalität einer Software zur Durchführung des Verfahrens auf einem Server installiert ist und über das Internet zur Verfügung gestellt wird.

7. Datenträger für Computersoftware, welcher Datenträger eine Computersoftware zur Durchführung der Verfahrensschritte eines Verfahrens gemäss einem der vorangehenden Patentansprüche beinhaltet.