|
Fachartikel
Portalbasierte, geschäftsprozessorientierte Wissenslogistik am Beispiel eines Prototypen
Autor: Thomas Rossbach | Artikel als PDF
Ein zunehmend an Wichtigkeit gewinnender Aspekt vor dem Kontext von Wissensmanagement ist die Nutzung von personalisierten Portalen zur Unterstützung von Geschäftsprozessen. Hierbei stehen also nicht Geschäftsprozesse als Instrument des Wissensmanagements, sondern die Unterstützung von Geschäftsprozessen durch Wissensmanagement im Vordergrund.
Die Wissenslogistik gehört zu den Teilaktivitäten des Wissensmanagements . Wissenslogistiksysteme sind somit Bestandteile von Wissensmanagementsystemen. Sie versorgen eine bestimmte Menge von Nutzern zur rechten Zeit am rechten Ort in der rechten Form mit Wissen aus verschiedenen Quellen und ermöglichen ihnen damit ein zielgerichtetes Handeln.
- Das Ziel des Handelns bestimmt die Inhalte der Informationsflüsse.
- Das Wissen wird i.a. zwischengespeichert und aufbereitet (veredelt).“
Insoweit ist es zulässig, von Wissenslogistiksystemen, anstatt von Informationslogistiksystemen zu sprechen. Selbst wenn aus Sicht der Semiotik lediglich Informationen transportiert werden, so ergibt sich doch durch den Zusammenhang mit einer konkreten Organisationseinheit ein spezifischer Handlungskontext. Aufgrund dieser pragmatischen Dimension wird die Organisationseinheit nicht mit Informationen, sondern mit Wissen versorgt.
„Geschäftsprozessorientierte Wissenslogistik wird durch adäquate IT-Systeme ermöglicht, beispielsweise durch
- Workflow-Systeme für strukturierte Prozesse,
- Groupware für unstrukturierte Prozesse,
- Communities für den prozessübergreifenden Austausch von Wissen oder
- Enterprise Information Portals (EIP) als Technologie für die System- und Ressourcenintegration.“
Grundsätzlich ist auch die gegebenenfalls ergänzende Konzeption als Dialogsystem möglich.
Für ein geschäftsprozessorientiertes Wissenslogistiksystem, das auf einer Portal-Plattform aufgebaut ist, hat die auf ITK spezialisierte Analysten- und Unternehmensberatungsfirma OVUM eine denkbare generische Architektur ermittelt. Die Ergebnisse der Untersuchung stammen aus dem Jahr 2000 . Sie wurden an die Erfordernisse aus und anwendungslogischer Sicht angepasst.
Abb. 01: Architektur eines portalbasierten geschäftsprozessorientierten Wissenslogistiksystems
Es handelt sich dabei um einen „bottom-up-Modellierungsansatz“, da die einzelnen Schichten aufeinander aufbauen.
Das „Gedächtnis“ des Systems (bzw. der Database-Layer) besteht aus Informationen und den zugehörigen Metadaten. Unter Metadaten sind Informationen über die Informationen, wie beispielsweise Name des Erstellers, Titel, Erstellungsdatum, eine Beschreibung mit Hilfe von Schlagwörtern usw. zu verstehen. Das Gedächtnis wird auch Organisational oder Corporate Memory, Knowledge Base oder Knowledge Warehouse genannt. Zu den Diensten zum Aufbau, zur Pflege und Weiterentwicklung des Gedächtnisses zählen neben den Basisdiensten für die Datenbank auch Funktionen des Dokumenten- und Content Management.
Zum Funktionieren des Gedächtnisses ist Wissensklassifizierung notwendig. Hierbei geht es sowohl um den Aspekt der Strukturierung – was wird wie klassifiziert – als auch um die Frage der Ablage und Wiederauffindbarkeit – wo ist was zu finden. Dies kann sich nach einer begrifflichen Taxonomie richten.
Den Input- und Outputfiltern der dritten Schicht liegt grundsätzlich ein Berechtigungs- und Rollenkonzept zugrunde. Vordefinierten Benutzergruppen werden damit vordefinierte Rechte und Zugriffsmöglichkeiten vergeben.
- Die Outputvorgänge liefern dabei explizites Wissen aus dem „Gedächtnis". Hierbei kommen Suchinstrumente zum Einsatz, beispielsweise Volltext-Suchmaschinen, semantische Suchmaschinen oder Data-Mining-Ansätze. Hierbei ergibt sich die Notwendigkeit von Outputfiltern, damit nur solche Inhalte verfügbar gestellt werden, die der Rechtekonfiguration des Benutzers entsprechen.
- Inputvorgänge können beispielsweise durch kontextabhängige Verschlagwortung in automatisierter Form oder mit Hilfe von Eingabemasken unterstützt werden. In beiden Fällen ist in der zweiten Schicht eine klare Taxonomie bzw. vorgegebene Wissensklassifikation erforderlich. Weiterhin muss durch Inputfilter sichergestellt sein, dass nur berechtigte Personen Inhalte einstellen, die vorbestimmten Qualitätsdefinitionen (Aktualität, Neutralität, Relevanz) entsprechen. Dies zu beurteilen kann schwerlich alleine der Maschine obliegen. Inputfilter bestehen deshalb nach Franken nicht nur in der IT-Konfiguration des Systems, sondern besonders in organisatorischen Regelungen (bsp. Redaktionsprozessen).
Die vierte Schicht wird durch Workflowmanagement-Funktionen gebildet. Ziel ist die „Steuerung des Arbeitsablaufs zwischen allen an der Bearbeitung eines Geschäftsprozesses beteiligten Arbeitsplätzen bzw. Personen, die man als Gruppe im Sinne des Workgoup Computing bezeichnen kann. Workflowmanagementsysteme unterstützen die Vorgangssteuerung, indem sie an jedem beteiligten Arbeitsplatz das zu bearbeitende Dokument, die damit auszuführenden Tätigkeiten und die anschließend erforderlichen Massnahmen am Bildschirm anzeigen.“ Hierzu sind „sie häufig mit Dokumentenmanagementsystemen integriert“.
Die Notwendigkeit einer Workflowkomponente in einem Wissensmanagementsystem ergibt sich daraus, dass auf der „operativen Ebene … der Umgang mit Wissen in die tägliche Arbeit zu integrieren (ist). Wissensmanagement muss daher mit den Geschäftsprozessen verzahnt werden ... Dabei hilft Wissen einerseits, die Geschäftsprozesse zu verbessern (Prozesswissen)’ , andererseits die Prozesse und einzelne Prozessschritte besser durchzuführen (Funktionswissen).“
Geschäftsprozessorientiertes Wissensmanagement ist demnach ein Synonym für die Kombination von Workflowmanagement- und Wissensmanagementsystemen. Wenn diese Integration gelingt, wird dadurch die Steuerung der jeweiligen Organisationseinheit verbessert, um Prozessparameter – insbesonders Zeit und Kosten – zu optimieren.
Die fünfte Schicht ist das User-Interface, welches hier durch ein Portal gebildet wird. Dieses ist der Zugang zu allen Instrumenten und Technologien der vier darunter liegenden Schichten hergestellt.
Unterschied man bisher hinsichtlich der Funktionalität beispielsweise zwischen Wissens- und Prozessportalen , so ist aktuell eine zunehmende Integration dieser beiden grundsätzlichen Konzepte in geschäftsprozessunterstützende, individualisierte, Portale festzustellen: „Die informationstechnische Unterstützung von Geschäfts- und Wissensprozessen wird heute zunehmend durch system- und anwendungsintegrierende Unternehmensportale (Corporate Portals oder Enterprise Information Portals) realisiert.“ „Unternehmensportale sind elektronische Plattformen, die unabhängig von Ort und Zeit einen zentralen Zugang (single access point) zu Ressourcen und Anwendungen unternehmensweit ermöglichen.
Ein wesentliches Merkmal der Portale ist die Möglichkeit, einen personalisierten „Arbeits- und Informationsraum“ zu schaffen. Besondere Bedeutung erhalten Unternehmensportale durch ihre Öffnung für Partner und damit für eine Prozessunterstützung entlang auch unternehmensübergreifender Wertschöpfungsketten. Über das Unternehmensportal können „verschiedene Werkzeuge für die Unterstützung bzw. Durchführung von unstrukturierten (z.B. Groupware-Systeme) und strukturierten Prozessen (z.B. Workflow-Systeme) verfügbar gemacht werden. Darüber hinaus können diverse Informationsressourcen (z.B. aus ERP-Systemen, Data Warehouses oder Datenbanken) in ein Portal eingebunden werden.“
In geschäftsprozessorientierten Wissenslogistiksystemen kann das Konzept des Arbeitspaketes zum Einsatz kommen:
Das Arbeitspaket enthält Dokumente, welche die Prozessteilnehmer zur Erledigung der ihnen zugedachten Funktionen benötigen bzw. voraussichtlich benötigen. Das Arbeitspaket wird im gesamten Verlauf der Prozessinstanz virtuell mitgeführt.
Es handelt sich technisch gesehen um einen Ordner, in den jedes Wissensartefakt publiziert werden kann. Dies kann wahlweise mittels Verlinkung oder Verschiebung aus dem bisherigen Speicherplatz geschehen.
Das Arbeitspaket ist für die gerade aktiven Prozessteilnehmer über einen Link im individuellen Portal zugänglich.
Das Zusammenstellen eines für alle Instanzen einer Prozessdefinition gültigen Arbeitspaketes erfolgt grundsätzlich durch den „Prozessdesigner“. Es ist aber auch möglich, dass eine am Prozess beteiligte Organisationseinheit Dokumente ins Arbeitspaket einer aktiven Prozessinstanz einstellt. Durch diese Flexibilisierung der Prozessdefinition ist eine Verfeinerung der mitgegebenen Informationen möglich, allerdings besteht auch die Gefahr, dass das Arbeitspaket zu umfangreich und komplex wird. Daher sollte nicht jeder Prozessteilnehmer das Recht zum Hochladen von Dokumenten erhalten.
Neben dem Recht, Dokumente einzustellen, können die auf den Inhalt des Arbeitspaketes vergebbaren Rechte auch das Lesen, Ändern und Löschen beinhalten. Die vorstehenden Ausführungen gelten dann vice versa. Schließlich können auch die Dokumente im Arbeitspaket der Versionskontrolle unterliegen, genauso wie alle anderen Dokumente auch.
Beurteilung des Nutzwertes anhand eines Prototypen:
Der Autor untersuchte dies mit Hilfe der Nutzwertanalyse anhand eines Prototypen. Dieser wurde in Zusammenarbeit mit einem mittelständischen Konstruktionsbüro erstellt und basierte auf der Software „Hyperwave Information Server Release 3.2“ der Hyperwave AG in München. Die Hyperwave AG bietet wie beispielsweise die Imperia AG, Typo3 oder eine ganze Reihe weiterer Anbieter webbasierte, integrierte DMS-, CMS- und Groupwaresysteme an. Ziel war, durch den Prototyp eine Diskussionsgrundlage zur Erstellung eines Lastenheftes für die endgültige Lösung zu erhalten.
Das Konstruktionsbüro beschäftigt ca. 90 Mitarbeiter, die in 10 Abteilungen organisiert sind. Unternehmensgegenstand ist das Planen und Konstruieren von Automationstechnik für Kfz-Hersteller und deren Zulieferer. Konstruiert werden vor allem automatische Fertigungsstraßen.
Als problematisch haben sich die je nach Kfz-Hersteller unterschiedlichen Voraussetzungen hinsichtlich Normen und Konstruktionssoftware erwiesen. Jeder Kfz-Hersteller – auch dessen Zulieferer – haben neben der DIN-Norm eigene Hausnormen. Zudem müssen vom Kfz-Hersteller vorgegebene CAD-Systeme eingesetzt werden - die untereinander inkompatibel sind. Dies führt dazu, dass für jedes CAD-Programm isoliert agierende Konstruktionsteams gebildet wurden. Innerhalb der Teams wird derzeit unstrukturiert gearbeitet. Die Konstruktionsprozesse sollten nun durch ein Wissenslogistiksystem strukturiert und jede Organisationseinheit genau mit den jeweils erforderlichen Wissenselementen versorgt werden. Mit der Geschäftsführung wurde vereinbart, zunächst den Prozess der Konstruktion von Roboter-Schweißzangen aufzugreifen.
Abb. 02: Industrieroboter und Schweißzange
Dessen Visualisierung erfolgte mit Hilfe des ARIS-Toolset®. Der Abstraktionsgrad wurde dabei so gewählt, dass die Prozessbeschreibung auf alle Konstruktionsgruppen und Projekte übertragbar ist. Die sich ergebende Prozessbeschreibung wurde dann im Prototyp implementiert.
Der Geschäftsprozess beginnt damit, dass das Konstruktionsbüro vom Kunden ein so genanntes Anlagenlayout erhält. Dieses zeigt die Anordnung der Fertigungsstraßen, Roboter usw.. Zu den für die Bearbeitung erforderlichen Unterlagen, die vom Kunden zur Verfügung gestellt werden, gehören ausser dem Analgenlayout auch Pläne der Aufnahmespannstellen sowie Angaben zur Fügefolge. Gegebenenfalls wird vom KFZ-Hersteller auch die Verteilung der Schweißpunkte vorentworfen.
Entsprechend der verwendeten Konstruktionssoftware wird nun der Auftrag an das darauf spezialisierte Team verwiesen [Abb. 03, Funktion 1]. Der Bearbeiter in diesem Team verteilt nun die Schweißpunkte auf den Blechüberlappungen und wählt diejenigen Zangengrundformen aus [Abb. 03, Funktion 2], welche das Erreichen der Schweißpunkte unter Beachtung der Positionen von Blechen und Spann- bzw Haltevorrichtungen ermöglichen.
Zunächst sind die Schweißzangen nur als so genanntes Grobmodell bekannt. Dieses enthält neben der Art der Zange wesentliche geometrische Grunddaten, vor allem das so genannte Zangenfenster. Hiermit werden die Länge der Zangenarme und deren Abstand voneinander angegeben.
Das Grobmodell dient Herstellern der Schweißzangen als Grundlage zur Erstellung einer Detailkonstruktion. Es ist jedoch vorher zu prüfen, ob bereits eine entsprechende Detailkonstruktion vorliegt, deren Daten denen des aktuellen Projektes entsprechen [Abb. 03, Funktion 3]. In diesem Fall kann der Bearbeiter optimalerweise aus dem Archiv sogleich die entsprechende Detailkonstruktion heranziehen [Abb. 03, Fall A]. Falls bisher noch keine derartige Zange konstruiert werden musste, gibt es auch keine Detailkonstruktion [Abb. 03, Fall B].
Im Fall B muss zunächst das so genannte Zangenfenster modelliert werden [Abb. 03, Funktion 4]. Hierzu wird eine alte Konstruktionsdatei verwendet und deren Geometrie den neuen Parametern angepasst. Das Grobmodell sowie das Zangenfenster wird nun an den Kfz-Hersteller bzw. den von diesem beauftragten Zangenlieferant weitergeleitet [Abb. 03, Funktion 5a] – dieser Schritt wird zwar in der Geschäftsprozessdefinition separat erfasst, wird jedoch durch das Workflowmanagementsysteme automatisch durchgeführt. Es ist dabei zu beachten, dass der Zangenlieferant keine Kenntnis von der Form des Bleches erhält, da diese der Geheimhaltung unterliegt. Die nun folgende Detailkonstruktion durch den Zangenlieferant [Abb. 03, Funktion 5b.1] dauert in der Regel zwei Wochen. Im Workflowmanagementsysteme kann diese Planzeit überwacht, sowie eine Erinnerung oder Eskalation im Falle der Nichteinhaltung vorgesehen werden [Abb. 03, Funktion 5b.2 und 5b.3]. Während der Zangenlieferant die Detailkonstruktion anfertigt, wird die Zangenausrichtung definiert [Abb. 03, Funktion 5c]. Dies ist die Position, in der die Zange an das Blech herangeführt wird. Schließlich wird die Aufnahmetechnik von dem darauf spezialisierten Konstrukteur erstellt [Abb. 03, Funktion 6].
Im Fall A – bei vorliegender Detailkonstruktion - muss jedoch nur noch die Zangenausrichtung definiert [Abb. 03, Funktion 5c] und die Aufnahmetechnik konstruiert [Abb. 03, Funktion 6] werden.
In beiden Fällen kann nun die dreidimensionale Endsimulation erfolgen [Abb. 03, Funktion 7a]. Ergibt die Endsimulation, dass Teile kollidieren, weist der Projektleiter den Vorgang derjenigen Organisationseinheit zu, welche das Problem am besten beheben kann [Abb. 03, Funktion 7b]. Falls keine Probleme auftreten, geht die Detailkonstruktion in die Planungsunterlagen der Fertigungsstraße ein und wird entsprechend archiviert [Abb. 03, Funktion 7c].
Abb. 03: Hyperwave-Prozessdefinition
Bei der Implementierung der Prozessbeschreibung in den Prototyp waren zusätzlich zu den oben genannten allgemeinen Aspekten auch fallbezogene Fragen betreffend die Kommunikation mit dem Kunden bzw. dessen Zangenlieferanten als externe Workflow-Beteiligte zu klären. Konkret stellte sich die Frage, in welcher Form der Kundenauftrag eingeht und wie der Kontakt zum Kunden bzw. dessen Zangenlieferant während des Prozesses gestaltet wird.
Durch das Konstruktionsbüro wurde insoweit keine Festlegung vorgenommen. Daher wurde im Prototyp ein vollständig elektronischer Prozess abgebildet. Es wurde angenommen, dass Konstruktionsaufträge vom Kfz-Hersteller per Mail mit angehängten Arbeitspaket-Dateien an das System geschickt werden und dann im Posteingangsordner eines Projektleiters erscheinen. Der Projektleiter prüfe dann die eingegangenen Unterlagen und starte einen Workflow.
Der Zangenlieferant ist als Prozessteilnehmer in den Workflow integriert. Dies wird relevant, wenn das Grobmodell an den Zangenhersteller zwecks Detailkonstruktion übermittelt werden, bzw. danach die Detailkonstruktion an das Konstruktionsbüro weitergegeben werden soll. Dies wird im Prototyp durch eine Funktion realisiert, so dass der Zangenlieferant als Organisationseinheit im Workflow die im Arbeitspaket enthaltenen Dokumente bearbeiten kann.
Die workflowspezifischen Wissensartefakte im spezifischen Arbeitspaket eines Vorganges sind wie erwähnt über das individualisierte Portal zugänglich. Hier befindet sich der „Workflow-Postkasten“ des Prototyps:
Abb. 04: Der Workflow-Postkasten
Aufgrund des Ansatzes als Enterprise Information Portal sind darüber hinaus alle relevanten Wissensartefakte, auch solche, die statisch bzw. nicht an Prozessstrukturen gebunden sind, enthalten.
Bei statischen Wissensartefakten handelt es sich um Dokumente, die sich nicht im Laufe eines Workflow inhaltlich verändern. Hierzu gehören beispielsweise Manuals oder Normen. Sie sind daher nicht notwendigerweise Bestandteil des Arbeitspaketes, sondern werden im Portal des Prototyps in einem Bereich mit festem Inhalt zur Verfügung gestellt.
Darüber hinaus gibt es wie erwähnt Wissen, das themenabhängig ist. Dies wird im Portal über ein Forum ausgetauscht. Dieses als „Wissensbörse“ in das Portal integrierte Element erlaubt themenorientierte Kommunikation.
Die Bewertung des Prototypen erfolgte mittels Nutzwertanalyse
Die Alternativen bestanden in der Implementierung des Wissenslogistik-Systemes sowie in der Beibehaltung der bisherigen Situation.
Die Ableitung von Kriterien erfolgte auf Basis des vorgenannten OVUM-Modelles. Den Schichten sind als hierfür relevant angesehene Kriterien in Anlehnung an Franken, Rolf und Maier, Ronald oder im Einzelfall anderen Autoren zugeordnet. Zusätzlich zu den fünf Schichten wurde als sechste Rubrik der zeitliche und finanzielle Aufwand untersucht. Nicht möglich ist es jedoch, die von Maier/Hädrich vorgeschlagenen Kriterien „Umfang der Systemnutzung“ und „Nutzerzufriedenheit“ anhand des Prototypen zuverlässig zu messen – diese Kennzahlen können bei Produktivbetrieb in das Kennzahlenportfolio aufgenommen werden.
Da festgestellt werden soll, ob sich die Software zur Unterstützung geschäftsprozessorientierter Wissenslogistik eignet, wurde die Punktesumme der vierten Schicht besonders gewichtet.
Die Kosten der Software dürfen die sich ggf. ergebenden Rationalisierungseffekte nicht kompensieren. Daher wurde die Punktesumme der Kostenrubrik ebenfalls überdurchschnittlich gewichtet. Bei den Kosten erwies sich einerseits der hohe Investitionsbedarf einer nicht freien Software als problematisch. Er schränkt die Anwendergruppe tendenziell auf größere Unternehmen ein.
Relevant war beispielsweise weiter die Verfügbarkeit von Dokumenten in mehreren Formaten für unterschiedliche Plattformen und die möglicherweise implementierbaren Metadaten. Entscheidend war weiterhin die Qualität der Strukturierung und Visualisierung der Wissenselemente aus. Beispielsweise müssen alternative Sichten auf den Content bzw. Mehrfachzuordnungen auf Ebene des Dokumentenmanagements möglich sein. Auch die funktionale Integration einer semantischen Suchmaschine eines dritten Herstellers wurde geprüft, ebenso die damit verbundenen zusätzlichen Administrationsaufwendungen. Wesentlich war auch der Aufwand zur Pflege der Inhalte, beispielsweise die automatische Einordnung von eingehenden Content-Objekte in die Ablagestrukturen des DMS.
Hinsichtlich der dritten Schicht war das Rollenkonzept ausschlaggebend. Hierzu muss es möglich sein, Benutzerrechte nicht (nur) auf Dokumentenebene zu vergeben, sondern funktionsorientiert. Ansonsten kann kein Rollensystem konstruiert werden.
Die vierte Schicht wird durch die Portal- und die Workflowkomponente repräsentiert. Hier ist die Unterstützung des Handlungskontextes des Benutzers durch relevanzgerankte und individualisierte Inhalte eine wichtige Forderung. Weiterhin muss der Inhalt des Dokumentenmanagementsystems dynamisch in das Arbeitspaket integriert werden, das Paket darf keine abgeschlossene Einheit bilden und damit möglicherweise doppelte Dokumentenbestände generieren. Zu bewerten ist auch, ob und wie die Workflowkomponente durch die Möglichkeit – innerhalb vordefinierter Grenzen - freier Vorgangs-Zuweisungen und mehrdimensionaler Workflows Stockungen vermeidet. Ein weiterer Aspekt stellte die Kommunikation entlang des Prozesses dar. Prozesse können als Treiber bzw. Wegweiser für zielgerichtete und bruchfreie Kommunikation genutzt werden.
Die Möglichkeit des single-sign-on sowie völliges Entfallen proprietärer Installationen stellt ebenso wie umfassende Browserkompatibilität Kriterien der fünften Schicht dar.
Fazit
Damit zeigte sich, dass grundsätzliche Anwendungsszenarien für geschäftsprozessorientierte Wissenslogistik solche sind, in denen sich Prozesse durch Wissensunterstützung effizienter gestalten lassen (beispielsweise durch Reduzierung des Aufwandes bei der Beschaffung von Dokumenten und Steigerung der Wiederfindegeschwindigkeit).
In gut vorstrukturierbaren Umgebungen ist eine workflow-orientierte Lösung - wie die Konfiguration des Prototypen - aufgrund klar definierbarer Ablaufregelungen und Zuständigkeiten gut geeignet.
Denkbar sind jedoch Situationen, in denen höhere Flexibilitätsgrade erforderlich werden. Hierbei muss es sich nicht um vollständig unstrukturierte Prozesse handeln, sondern beispielsweise um Geschäftsprozesse, die sich inkrementell ändern können. Bereits diese ließen sich mit der Workflow-Komponente zumindest in der derzeit vorliegenden Version nicht unterstützen.
Für proaktive, automatische Prozessunterstützung – die in interdependenten und sich schnell ändernden Organisationsstrukturen notwendig sein kann – werden in der Praxis bereits ontologiebasierte Systeme in Verbindung mit Geschäftsprozess- bzw. Workflowmanagement angestrebt und wissenschaftlich erforscht (beispielsweise das Projekt PREBIS – Pre-Built Information Space – der Universitäten Stuttgart und Leipzig, verschiedener Unternehmen wie beispielsweise die Karlsruher Ontoprise GmbH und des Fraunhofer Institutes) . „Ontologien sind (subjektive) Repräsentationen eines Weltausschnittes auf der Basis einer gemeinsamen Metasprache, die ein semantisches Verstehen zwischen den Nutzern der Metasprache unterstützt. Jede Repräsentation ist eine abstrakte, symbolische Sichtweise auf Phänomene des Weltausschnittes, Kommunikationspartner … sind Computer und Menschen.“
Ein Vorteil dieser Vorgehensweise ist, dass Kommunikation über Domänengrenzen bzw. Begriffswelten hinweg auf Basis eines von allen Kommunikationspartnern verstandenen formalen Modells möglich ist. Technisch gesehen, wird dies über XSL/XML realisiert.
Die Objekte der realen Welt können jedoch nicht nur in einem Modell abgebildet werden, sondern mit Hilfe von Attributen und Zielvorgaben kann Interaktion mit anderen Objekten möglich werden. Diese Interaktion kann prinzipiell verschiedene Automatisierungsstufen anstreben, beispielsweise dass
- die Funktionen sich anhand der Ontologien selbstständig organisieren, d.h. eine Funktion erkennt automatisch, welche die im Workflow folgende sein sollte. Dies würde die Komplexität von Workflow-Modellierungen vereinfachen, indem nur noch die relevanten Funktionen in einem Pool vorgehalten, Ablaufdefinitionen aber ad hoc und step by step vom System generiert werden.
- jede Organisationseinheit im Prozess durch eine Ontologie repräsentiert ist, welche aus einem vorkanalisierten Informationsfluss die relevanten Informationen herausfiltert und der Relevanz für den Nutzer entsprechend anzeigt.
|
