SemProj - Ein Semantic Web-basiertes System zur Unterstützung von Workflow- und Projektmanagement

Inhaltsverzeichnis

Zusammenfassung

Abstract

Danksagung

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1. Die Vision des Semantic Web
1.1. Motivation
1.2. Beschränkungen des heutigen Internets
1.3. Das Semantic Web
1.4. Zielsetzung der Arbeit
1.5. Aktueller Stand

2. Grundlegende Betrachtungen
2.1. Wozu Projektmanagement?
2.2. Begriffsdefinitionen
2.2.1. Projekt
2.2.2. Phase
2.2.3. Prozess
2.2.4. Workflow
2.2.5. Aktivität
2.2.6. Projektmanagement
2.2.7. Prozessmanagement
2.2.8. Workflowmanagement
2.2.9. Groupware
2.2.10. Knowledgemanagement
2.3. Modellierungsansätze
2.3.1. Ereignisgesteuerte Prozessketten
2.3.2. Flussdiagramme
2.3.3. Petri Netze
2.3.4. Unified Modeling Language
2.3.5. Business Process Modeling Notation
2.3.6. Zusammenfassung
2.4. Anwendungsszenarien
2.4.1. Motivation
2.4.2. Spaghetti kochen
2.4.3. Abendessen mit Freunden
2.4.4. Diplomarbeit schreiben
2.4.5. Entwicklung einer neuen Webseite
2.4.6. Workshop organisieren
2.5. Evaluierung gängiger Systeme
2.5.1. Herangehensweise
2.5.2. Projektmanagementsysteme
2.5.3. Workflowmanagementsysteme
2.6. Vergleich von Workflow- und Projektmanagementsystemen

3. Konzeption eines semantikbasierten Projektmanagementsystems
3.1. Was bedeutet Semantik?
3.2. Wissensbeschreibung
3.3. Überblick über Technologien zur Repräsentation von Semantik
3.3.1. Motivation
3.3.2. RDF
3.3.3. N-Triples
3.3.4. RDFS
3.3.5. DAML+OIL
3.3.6. OWL
3.3.7. XML Topic Maps (XTM)
3.3.8. XOL
3.3.9. Layer-Architektur
3.4. Einbettung von Semantik in (X)HTML-Dokumente
3.4.1. Motivation
3.4.2. SHOE
3.4.3. Meta-Angaben
3.4.4. Verlinkung auf externe RDF-Beschreibung
3.4.5. Einbettung in Kommentarbereiche
3.4.6. eRDF
3.4.7. RDFa
3.4.8. Microformats
3.4.9. Vergleich von Microformats und RDFa
3.5. Nutzbare Ontologien
3.6. Entwurf einer geeigneten Ontologie

4. Implementierung eines Prototypen
4.1. Festlegung der Systemumgebung
4.2. Semantische Frameworks
4.3. Wünschenswerte Funktionalitäten
4.4. Systemarchitektur
4.5. Lizenzmodell

5. Praxistest
5.1. Installation
5.2. Performance
5.3. Bedienung
5.4. Testfälle

6. Diskussion
6.1. Beurteilung des Systemsentwurfs
6.2. Vergleich zu bisherigen Managementsystemen
6.3. Weiterentwicklungsansätze
6.4. Zukunft des Semantic Web

Literaturverzeichnis

Index

A. Anhang
A.1. Getestete Projektmanagementsysteme
A.2. Getestete Workflowmanagementsysteme
A.3. Verwendete RDF Schemata zur Abbildung der Projekt- und Workflowmanagementdomain
A.4. Analyse und Spezifikation der zu entwickelnden Anwendung

Abbildungsverzeichnis

Abbildung 2: Gartners Hype Cycle für aufstrebende Technologien 2006

Abbildung 3: Methoden der Prozessmodellierung nach Gadatsch

Abbildung 4: Vergleich grundlegender Elemente verschiedener Modellierungsansätze

Abbildung 5: Entwicklung von Workflowbeschreibungsformaten

Abbildung 6: Screenshot PHProject

Abbildung 7: Screenshot Double Choco Latte

Abbildung 8: Screenshot dotProject

Abbildung 9: Screenshot WebCollab

Abbildung 10: Screenshot PHPCollab

Abbildung 11: Screenshot BaseCamp

Abbildung 12: Screenshot JaWE Java XPDL Editor

Abbildung 13: Screenshot Bonita

Abbildung 14: Screenshot Imixs

Abbildung 15: OSWorkflow

Abbildung 16: Screenshot RunaWFE

Abbildung 17: Screenshot Oryx

Abbildung 18: Wissenspyramide nach Bodendorf

Abbildung 19: Reusability-usability trade-off Problem

Abbildung 20: Semantisches Architekturmodell

Abbildung 21: Naives Modell einer Projekt- und Workflowmanagementontologie

Abbildung 22: Verzeichnishierarchie des Projektmanagementsystems

Abbildung 23: Ausschnitt aus HTML-Datei und daraus abgeleiteten RDF statements

Abbildung 24: Startseite von SemProj

Abbildung 25: Kontaktseite eines Nutzers mit Exportmöglichkeit

Abbildung 26: Zentrale Übersichtsseite

Abbildung 27: Projekteditor mit geöffnetem Eigenschaftenfenster

Abbildung 28: Transformation semantischer Metainformationen nach RDF

Abbildung 29: Attribute einer XPDL-Beschreibung

Abbildung 30: "Spaghetti kochen" als XPDL-Beschreibung

Abbildung 31: Evolution of Web Technologies

Tabellenverzeichnis

Tabelle 1: Kategorisierung von Workflows nach der Struktur

Tabelle 2: Kriterienkatalog für die Evaluierung von Workflow- und Projektmanagementsystemen

Tabelle 3: Typische Objekteigenschaften von Projekten

Tabelle 4: Typische Objekteigenschaften von Aufgaben

Tabelle 5: Vergleich von Microformats und RDFa

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Zusammenfassung

Mit mehr als 120 Millionen registrierten Internetadressen (Stand: März 2007) symbolisiert das Internet heutzutage das größte Informationsmedium unserer Zeit. Täglich wächst das Internet um eine unüberschaubare Menge an Informationen. Diese Informationen sind häufig in Dokumenten hinterlegt, welche zur Auszeichnung die Hypertext Markup Language verwenden. Seit Beginn der Neunziger Jahre hat sich dieses System bewährt, da dadurch der einzelne Nutzer in die Lage versetzt wird, auf einfache und effiziente Weise Dokumentinhalte mit Darstellungsanweisungen zu versehen und diese eigenständig im Internet zu veröffentlichen. Diese Layoutinformationen können bei Abruf der entsprechenden Ressource durch ein Computerprogramm leicht ausgewertet und zur Darstellung der Inhalte genutzt werden. Obwohl sowohl die Layoutinformationen als auch die eigentlichen Dokumentinhalte in einem textuellen Format vorliegen, konnten die Nutzertextinhalte durch eine Maschine bisher nur sehr eingeschränkt verarbeitet werden. Während es menschlichen Nutzern keinerlei Probleme bereitet, die Bedeutung einzelner Texte auf einer Webseite zu identifizieren, stellen diese für einen Rechner prinzipiell nur eine Aneinanderreihung von ASCII-Zeichen dar.

Sobald es möglich werden würde, die Bedeutung von Informationen durch ein Computerprogramm effizient zu erfassen und weiterzuverarbeiten, wären völlig neue Anwendungen mit qualitativ hochwertigeren Ergebnissen im weltweiten Datennetz möglich. Nutzer könnten Anfragen an spezielle Agenten stellen, welche sich selbstständig auf die Suche nach passenden Resultaten begeben; Informationen verschiedener Informationsquellen könnten nicht nur auf semantischer Ebene verknüpft, sondern daraus sogar neue, nicht explizit enthaltene Informationen abgeleitet werden. Ansätze dazu, wie Dokumente mit semantischen Metadaten versehen werden können, gibt es bereits seit einiger Zeit. Lange umfasste dies jedoch die redundante Bereitstellung der Informationen in einem eigenen Dokumentenformat, weswegen sich keines der Konzepte bis in den Privatbereich durchsetzen konnte und als Endkonsequenz in den vergangenen Monaten besonderes Forschungsinteresse darin aufkam, Möglichkeiten zu finden, wie semantische Informationen ohne großen Zusatzaufwand direkt in bestehende HTML-Dokumente eingebettet werden können.

Im Rahmen der vorliegenden Publikation werden diese neuen Möglichkeiten im Bereich des kollaborativen Arbeitens näher untersucht. Ziel ist es dazu, eine Webapplikation zur Abwicklung typischer Projektmanagement-Aufgaben zu entwickeln, welche jegliche Informationen unter einem semantischen Gesichtspunkt analysieren, aufbereiten und weiterverarbeiten kann und unabhängig von der konkreten Anwendungsdomain und Plattform systemübergreifend eingesetzt werden kann. Die Konzepte Microformats und RDFa werden dabei besonders herausgestellt und nach Schwächen und zukünftigen Potentialen hin analysiert.

Abstract

The World Wide Web supposably symbolizes with currently more than 120 million registered internet domains (March 2007) the most comprehensive information reference of all times. The amount of information available increases by a storming bulk of data ever day. Those information is often embedded in documents which utilize the Hypertext Markup Language. This enables the user to mark out certain layout properties of a text in an easy and efficient fashion and to publish the final document containing both layout and data information. A computer application is then able to extract style information from the document resource and to use it in order to render the resulting website. Although layout information and data are both equally represented in a textual manner, a machine was hardly capable of processing user content so far. Whereas human consumers have no problem to identify and understand the sense of several paragraphs on a website, they basically represent only a concatenation of ASCII characters for a machine.

If it were possible to efficiently disclose the sense of a word or phrase to a computer program in order to process it, new astounding applications with output results of high quality would be possible. Users could create queries for specialized agents which autonomously start to search the web for adequate result matches. Moreover, the data of multiple information sources could be linked and processed together on a semantic level so that above all new, not explicitly stated information could be inferred. Approaches already exist, how documents could be enhanced with semantic meta-data, however, many of these involve the redundant provision of those information in a specialized document format. As a consequence none of these concepts succeeded in becoming a widely used method and research started again to find possibilities how to embed semantic annotations without huge additional efforts in an ordinary HTML document.

The present publication focuses on an analysis of these new concepts and possibilities in the area of collaborative work. The objective is to develop the prototype of a web application with which it is possible to manage typical challenges in the realm of project and workflow management. Any information available should be processable under a semantic viewpoint which includes analysis, conditioning and reuse independently from a specific application domain and a certain system platform. Microformats and RDFa are two of those relatively new concepts which enable an application to extract semantic information from a document resource and are therefore particularly exposed and compared with respect to advantages and disadvantages in the context of a “Semantic Web”.

Danksagung

"Whatever you do will be unimportant, but it is very important that you do it." ~ Mahatma Gandhi

An dem vorliegenden Buch haben viele Personen einen direkten oder indirekten Einfluss gehabt, denen ich diesen kurzen Abschnitt widmen möchte. Die Aufgabe, eine erste eigene Publikation herauszugeben, scheint zu Beginn lang und das gewählte Thema scheint das einzig Wichtige zu sein, was den Inhalt der Arbeit bestimmt. Ich persönlich habe während der Anfertigung des Buches Erfahrungen gemacht, die über diesen inhaltlichen Fokus weit hinausgehen. Sicherlich stand zu Beginn die Frage nach einiger geeigneten Thematik im Raum; und ich bin froh dieses sehr zukunftsträchtige Thema gewählt zu haben, da ich mich sonst sicherlich nicht derart intensiv damit auseinander gesetzt hätte. Viel interessanter war für mich jedoch zu sehen, wie ich mich persönlich weiterentwickelt habe. Die Anfertigung war dabei ein dynamischer Prozess, der durch Erfolge aber auch durch kleine und große Probleme geprägt war, die zu Beginn nicht immer abzusehen, aber letztendlich alle überwunden werden konnten. Ich habe im Zuge dessen neue, interessante Methoden, Ansätze und Kontakte kennen gelernt, die im späteren Berufsleben von großem Nutzen sein können.

An erster Stelle möchte ich mich dazu bei Prof. Dr. Martin Gaedke von der Technischen Universität Chemnitz bedanken, der wesentlichen Anteil an der gemeinsamen Entwicklung des Themas hatte und mehrfach seinen Feierabend entfallen ließ, um mit mir stundenlang aktuelle Ergebnisse bis in die Nacht zu diskutieren. Außerdem danke ich dem gesamten Forschungsteam der Professur Verteilte und Selbstorganisierende Rechnersysteme, welche sich in der zurückliegenden Zeit bemerkenswert einsetzten, um mit neuen Lehrmethoden alle Studierenden dazu zu ermutigen, über den Tellerrand hinauszuschauen und die zugrunde liegenden Zusammenhänge zu begreifen, um diese in der Praxis später eigenständig anwenden zu können.

Mein weiterer Dank gilt meinen Großeltern, welche mich in der Anfertigungzeit mit allen nur erdenklichen Hilfen unterstützten. Ebenso möchte ich mich bei meinen Freunden bedanken, die mich immer wieder ermutigt und motiviert haben, mein Ziel zu verfolgen. Insbesondere seien hier Maja Heidrich, bei der ich mich für das Korrekturlesen der Studie bedanken möchte, sowie Thomas Fichtner genannt, der mir immer wieder Feedback bei der Implementierung des Prototypen gab.

Mein abschließender Dank gilt dem Unternehmen der 09111 Studio Chemnitz GmbH&Co. KG, welche auch in den letzten zwei Monaten eine sehr flexible Arbeitszeitgestaltung ermöglichten sowie der Stiftung der Deutschen Wirtschaft, bei der ich mich für die Förderung im Rahmen des Stipendiatenprogramms in den zurückliegenden vier Jahren und das entgegengebrachte Vertrauen bedanken möchte.

Die Thematik in dem vorliegenden Dokument habe ich versucht, von verschiedenen Blickrichtungen so zu bearbeiten, sodass sich ein geschlossenes Gesamtbild ergibt, welches auch für Unbeteiligte interessant und gut verständlich ist. Wenn das vorliegende Buch in Zukunft auch für andere Personen und Institutionen von Nutzen ist und zu neuen Erkenntnissen beiträgt, würde ich mich freuen.

André Langer im November 2007

1. Die Vision des Semantic Web

“Things are only impossible until they're not.” ~ Star Trek: The Next Generation - When The Bough Breaks, Jean-Luc Picard, Season 1, 1988

1.1. Motivation

Ein junger Unternehmensberater sitze an einem Dienstagmorgen in der Cafeteria eines namhaften Hotels irgendwo im Herzen von Deutschland. Während er mit einem Löffel in der linken Hand die Tasse Kaffee vor sich auf dem Tisch umrührt, hält er in der rechten Hand bereits seinen PDA, um sich einen Überblick über die Termine des kommenden Tages zu verschaffen. Nach einem Klick auf „ heutige Termine anzeigen “ liefert das System die Beschreibung: „ Sie haben heute um 10.00 Uhr ein Treffen mit Dr. Müller in der Ulmenstraße 5. Um 15.30 Uhr ist eine Telefonkonferenz mit der Arbeitsgruppe Asterisk angesetzt. 17.00 Uhr haben Sie einen Termin mit Herrn Holger Schmidt vorgemerkt. Um 18.20 Uhr schließlich startet ihr Flug nach Grenoble. “ Der Berater überlegt, dass es besser wäre, den Termin mit Herrn Schmidt zu verlegen, um rechtzeitig auf dem Flughafen zu sein. Er verschiebt den Termin um zwei Tage, was durch das System zunächst abgelehnt wird mit der Begründung, dass sich Herr Schmidt zu dieser Zeit auf einer Dienstreise befindet. Nach einer Bestätigung legt das System das Treffen auf den nächstmöglichen Termin und versendet an Herrn Schmidts Emailadresse eine entsprechende Nachricht. Die nächste Anfrage, worum es bei der Telefonkonferenz geht, beantwortet das System mit einer Meldung „ Die Firma Meier möchte diskutieren, was ein Umstieg auf SCCP für Vorteile bringt. “SCCP ist dem Berater unbekannt, worauf ihm das System den Begriff definiert^[1] und weitere Informationen liefert. Nach dem Frühstück macht sich der Berater auf zu seinem ersten Termin, lässt von dem System automatisch ein Taxi rufen und fragt auf dem Weg nach draußen noch schnell ab, wann und wo er Dr. Müller letztmalig getroffen und wo sein Geschäftspartner den letzten Urlaub verbracht hat.

Das skizzierte Szenario scheint auf dem ersten Blick in ferner Zukunft zu liegen. Derartige Interaktionen zwischen Mensch und Maschine werden häufig im Bereich der Science-Fiction angesiedelt. Zu allgegenwärtig scheinen eigene Erfahrungen, wie aufwändig es sein kann, eine Suche nach spezifischen Daten im Internet mit Computerunterstützung durchzuführen. Jegliche Informationen, welche nicht explizit in einer Organizer-Software gespeichert sind und entsprechend angezeigt werden können, scheinen für einen Rechner nicht auswertbar. Zu groß wäre der Suchaufwand in der Informationsfülle des heutigen Internets – ganz abgesehen von der Fragestellung, wie ein Rechner Beziehungen zwischen Informationen herstellen solle, Mehrdeutigkeiten auflösen und eine auf die Fragestellung zugeschnittene, für den Menschen verständliche und vereinfachte Ausgabe zurückliefern kann.

Dennoch ist eine derartige Anwendung heutzutage vorstellbar und nicht länger Fiktion. Der Traum von intelligenten Maschinen besteht schon seit langer Zeit. Beschränkt man sich nur auf Entwicklungen mit Bezug zur modernen Rechentechnik, so prägte Alan Turing 1950 erstmals die Vorstellung von intelligenten Maschinen [Tur50]. Der sich daran anschließende Optimismus unter KI-Forschung bis Ende der 60er Jahre wurde durch eine Phase der Ernüchterung beendet, als man zunehmend die Beschränkungen grundlegender Konzepte und der darauf basierenden Algorithmen erkannte. Während in den Siebziger und Achtziger Jahren neue Erfolge bei der Entwicklung kommerzieller Expertensysteme erzielt worden, lag der Fokus bei der Verbreitung des World Wide Webs nach Einführung des Hypertext-Konzepts durch Sir Tim Berners-Lee im Jahr 1989 zunächst auf der öffentlichen Bereitstellung von Informationen in Dokumenten, welche auch für Endanwender einfach zu realisieren sein sollte. Die Hypertext Markup Language (HTML) als Anwendung der Standard Generalized Markup Language (SGML), mit der Dokumentstrukturen syntaktisch beschrieben werden konnten, schuf dabei die Grundlage für einen Dokumenttyp, über den mithilfe einiger zusätzlicher Auszeichnungen zur Angabe von Textformatierungen alle Dokumentinformationen in einem unitären Dokumentformat in einer einheitlichen Struktur gespeichert, verbreitet und zur Darstellung bereitgestellt werden konnten. Nutzer wurden dadurch in die Lage versetzt, Textinhalte einfach formatieren und mit anderen Dokumenten und Multimediadateien verknüpfen zu können. Verbunden mit der einfachen Erlernbarkeit und Einsetzbarkeit von HTML durch Privatanwender war jedoch die Einschränkung, einen festen Satz an vordefinierten Auszeichnungselementen („Tags“) vorzugeben, welchen eine explizite Bedeutung zugeordnet wurde. Im Bezug auf die Rücktransformation von Dokumentinhalten in Informationsstrukturen stellte dies ein Problem dar, da Informationen über die Natur der dargestellten Inhalte nicht gespeichert wurden (es konnten bzw. sollten keine eigenen Auszeichnungselemente hinzugefügt werden), sondern HTML in erster Linie die Dokumentdarstellung unterstrich. Durch den einfachen Syntax und die schnelle Bereitstellung von Entwicklungswerkzeugen (WYSIWYG-Editoren) verbreitete sich das Hypertext-Konzept binnen kurzer Zeit und fand breite Akzeptanz^[2], dennoch wurden besonders im Bereich der rechnergestützten Dokumentverarbeitung Anforderungen immer wichtiger, nicht nur Darstellungsinformationen sondern auch syntaktische Dokumentstrukturinformationen in einem universellen, einheitlichen Format speichern und übertragen zu können. Als Folge davon wurde die eXtensible Markup Language (XML) entwickelt, welche sich bis heute als Austauschformat in unterschiedlichsten Anwendungsbereichen etabliert hat.

HTML und XML (und weitere Konzepte wie CSS) widersprechen dabei nicht einander, sondern können sich gegenseitig ergänzen und ineinander überführt werden (XSLT) , da beide der gleichen Sprachfamilie entstammen und mit der Spezifikation von XHTML1.0 dies sogar eine Untermenge von XML mit einem dedizierten Anwendungsfeld darstellt. Je nach Anwendungsfall mit Schwerpunkt auf Layout, Struktur oder Inhalt wird man sich für eine konkrete Umsetzungsmöglichkeit entscheiden, wodurch eine gewisse Trennung in einen layoutorientierten oder strukturorientierten Ansatz vorhanden ist. Trotz dass XML im letzteren Fall schon den Anschein erweckt, Informationen über Dokumentinhalte perfekt abbilden zu können, reichte aber auch dies nicht aus, um Inhalte für einen Computer verständlich werden zu lassen, da damit zwar eine syntaktische Korrektheit sichergestellt werden konnte, nicht jedoch eine semantische Korrektheit.^[3]

1.2. Beschränkungen des heutigen Internets

Das World Wide Web ist im Wesentlichen ein Medium zur Veröffentlichung und Distribution von Informationen. Ende Dezember 2006 waren weltweit 120 Millionen Domains registriert. Pro Monat kommen statistisch 3,2 Millionen neue Domains hinzu. [Ver07]. Die Anzahl der tatsächlich im Internet vorhandenen Dokumente kann nur geschätzt werden, wobei Millionen privater Homepages mit wenigen Unterseiten und Webseiten großer Unternehmen mit womöglich mehr als 100.000 Dokumenten gleichermaßen ins Gewicht fallen. Eine Hochrechnung basierend auf Daten des Archivierungsdienstes www.archive.org im Frühjahr 2006 geht von einer kumulativen Summe von insgesamt 55 Milliarden (1 Petabyte) Dokumenten seit 1996 aus mit einem Zuwachs von 20 Terabyte an Daten pro Monat. Andere Statistiken sehen diese Schätzungen als zu pessimistisch an und sprechen von einer zwei Drittel höheren Dokumentenanzahl. [Wen06] Diese Zahl von über 160 Milliarden Dokumenten im World Wide Web basiert auf der Annahme, dass aktuelle Suchmaschinen real nur ca. 35 % aller tatsächlich vorhandenen Dokumente indiziert haben (Abbildung 1). Im Umkehrschluss bedeutet dies, dass ein Großteil potentiell relevanter Informationen entweder gar nicht oder nur indirekt gefunden werden kann. Selbst die Informationen, auf die durch Suchmaschinen öffentlich zugegriffen werden kann, existieren unabhängig voneinander. Abgesehen von Techniken wie Web Scraping oder explizit angebotenen Web Services ist der Datenbestand einer Webapplikation auf die eigene Anwendung bzw. Domain begrenzt, über die der zuständige Entwickler zusätzliches Hintergrundwissen besitzt. Könnte man den Inhalt der Milliarden Dokumente miteinander verknüpfen, daraus Informationen abrufen, den Inhalt und Wahrheitswert überprüfen und mitunter sogar neue Informationen ableiten, wären ein Informationsgewinn und Anwendungen denkbar, die derzeit noch nicht vorstellbar sind, da das spezifische Suchen, Vergleichen und Ableiten von Informationen bisher menschliche Interaktion erfordert.

Ein weiteres Problem stellt darauf aufbauend die Art und Weise der Suche nach Informationen dar. Moderne Algorithmen, die in heutigen Suchmaschinen zur Anwendung kommen, sind zwar hochkomplex und haben sich in den vergangenen zwei Jahrzehnten qualitativ kontinuierlich weiterentwickelt, doch ist das Grundkonzept dahingehend gleich geblieben, dass alle Suchanfragen in der Regel auf einzelnen Schlüsselwörtern basieren und deren Vorkommen im (Volltext-)Index des Suchmaschinendatenbestandes überprüft wird. Die Konsequenz daraus ist, dass zwar syntaktische Analysen durchgeführt können und nach ähnlichen Wörtern gesucht werden kann, in aller Regel auch die Anzahl des gemeinsamen Vorkommens der Schlüsselwörter im Zieldokument sowie die Popularität der Seite eine Rolle spielt, doch bleibt die Bedeutung der Anfrage in aller Regel verborgen. So ist aus einem einzelnen Schlüsselwort wie etwa Flügel nicht ableitbar, ob der Nutzer eine Webseite sucht, die Musikinstrumente anbietet, eine Anleitung für eine mechanische Konstruktion sucht, oder in ein zoologisches Lexikon schauen möchte. Dementsprechend bieten heutige Suchmaschinen in einer Übersicht häufig die „geeignetsten“ Treffer an, worunter derartige Begriffsdeutungen zumeist miteinander vermischt sind. In manchen Situationen hilft es, mehrere Schlüsselwörter in die Suchanfrage aufzunehmen (+ wie +spielt +man +auf +einem +Flügel), wodurch Dokumente gefunden werden könnten, die die Begriffe spielen und Flügel enthalten, doch wäre es intuitiver, die Frage in dieser Form direkt an einen Suchdienst stellen zu können, der diese Frage als Ganzes versteht und nur passende Resultate zurückliefert (auch solche, in denen das Wort Flügel nie erwähnt wird, dafür aber vielleicht von einem Klavier gesprochen wird).

Dass dies technisch nicht trivial umzusetzen ist, liegt wie in Abschnitt 1.1. bereits kurz beschrieben darin begründet, dass Dokumentinhalte im World Wide Web größtenteils im (X)HTML – Format vorliegen. Der Fokus auf einer einfachen Layoutbeschreibung brachte jedoch den Nachteil mit sich, dass die Beschreibung des Inhalts von HTML-Dokumenten nur zweitrangig betont wurde (Meta-Tagging). Die Folge davon ist, dass die entstandenen HTML-Dokumente zwar in ihrer Struktur durch einen Computer gut verarbeitbar sind, der Inhalt computergeschützt aber nicht trivial Konzepten der realen Welt zuzuordnen ist (die Tags zur Auszeichnung können entfernt werden, der resultierende Text an sich ist strukturlos und kann nur mithilfe von String-Operationen verarbeitet werden), was wiederum zu dem angesprochenen Problem führt, bestimmte Sachverhalte bei einem Indexierungsvorgang semantisch voneinander unterscheiden zu können. Einige Suchmaschinen verwenden dafür zwar Algorithmen, welche den Inhalt bestimmter Textmarken wie von (h1 -) Überschriften stärker wichten und als Beschreibung des weiteren Dokumentinhalts ansehen, doch entspricht jeder weitere Schritt im Grunde genommen einer syntaktischen Volltextsuche.

Um eine einfach zu benutzende, stärker inhaltszentrierte Verarbeitung zu ermöglichen, wurde die eXtensible Markup Language entwickelt. Durch XML wird es möglich, Daten im Text logisch voneinander zu trennen und separat beliebig auszuzeichnen (zu benennen). Ebenso können syntaktische Regeln für die ausgezeichneten Daten definiert werden (via DTD/XSD). Die rechnergestützte Verarbeitung der Daten wird damit vereinfacht, da auf einzelne Dokumentinhalte nach einem standardisierten Schema gezielt zugegriffen werden kann. Nichtsdestotrotz blieben einige Probleme bestehen, die auch mithilfe von XML nicht gelöst werden können, um Dokumentinhalte durch ein Computersystem anhand der Bedeutung der Inhalte verarbeiten zu lassen. Diese seien nachfolgend genannt:

- Die enthaltenen Informationen in einem XML-Dokument sind für einen Rechner weiterhin Zeichenketten ohne explizite Bedeutung. Dokumentinhalte sind zwar mithilfe von XML syntaktisch ausgezeichnet und orientieren sich mehr am Textinhalt als an der Darstellung des Inhalts, doch ist die konkrete Bezeichnung der ausgezeichneten Bereiche für den Computer an sich beliebig wählbar und nur durch den Menschen deutbar.
- Mithilfe definierter Datentypen in XML Schema ist es zwar möglich, Abhängigkeiten zwischen einzelnen Elementen zu definieren (eine Adresse besteht aus Name, Straße, Postleitzahl, Ort), diese sind jedoch ebenfalls nur syntaktischer Natur
- XML-Dokumente sind zwar strukturell alle auf gleiche Art und Weise verarbeitbar, doch bedeutet dies nicht, dass eine Aussage über die reale Welt in einem XML-Dokument eindeutig auf eine bestimmte Art und Weise beschrieben werden kann. Vielfach kann die gleiche Information mithilfe unterschiedlicher Attribut- und Knotenschachtelungen in einem Dokument abgebildet werden. Für eine rechnergestützte Verarbeitung von Informationen sind jedoch eindeutige Repräsentationen für Aussagen mit gleichem Inhalt zwingend erforderlich.
- Syntaktische SNHI AHE l auf ein Dokument beschränkt. Weitere XML-Dokumente können zwar eingebunden werden (XInclude), welche dann jedoch zu der verwendeten Schemadefinition kompatibel sein müssen. Weitere Anforderungen an Beziehungen zwischen verschiedenen Strukturen (beispielsweise eine ist ein – Relation) können nur unbefriedigend abgebildet werden.
- XML ist ein in der Praxis gut einzusetzendes Austauschformat, welches eine Kompatibilität zwischen mehreren Institutionen schafft, doch fehlen für eine domainübergreifende inhaltliche Auswertung einige Möglichkeiten. Eine Suchmaschine kann in einem Dokument nach einem gängigen Tag <title></title> suchen, wobei bei einem positiven Suchergebnis nicht feststeht, ob der Elementinhalt wirklich den Titel der Webseite angibt, oder vielleicht den Titel eines darin behandelten Buches oder vielleicht etwas ganz anderes. Ebenso ist bei Nichtauffinden des Elements nicht gesagt, dass nicht die Titelinformation unter einer anderen Bezeichnung in dem Dokument existiert.
- Die Extraktion von Informationen aus einem XML-Dokument geschieht in XML-Anwendungssoftware nach einem festen Schema. (Um den Titel einer Webseite zu ermitteln, suche nach einem Element title und nutze die darin enthaltenen Daten) Änderungen an den XML-Markupdaten ziehen direkte Änderungen im Programmcode der Anwendungssoftware nach sich.
- Zuletzt sollte das Aufwand-Nutzen-Verhätlnis für die Bereitstellung von Informationen in einem XML-Dokument in die Überlegungen einbezogen werden. Der einzelne Endanwender wird nur in seltenen Fällen private Informationen als XML-Datei öffentlich bereitstellen, da dafür in vielen Fällen das Wissen fehlt, oder es doppelten Aufwand erfordert, sowohl die Informationen in einer HTML-Datei mit Darstellungsangaben zu versehen und diese zusätzlich in einer XML-Datei für eine maschinelle Verarbeitung zu hinterlegen. In einigen Fällen macht dies Sinn (bspw. FOAF, vCards), stellt in jedem Fall jedoch einen Zusatzaufwand auf Nutzerseite dar. Techniken wie XSLT existieren, um Inhalte einer XML-Datei in einem einzelnen Prozess mit Styleangaben zu versehen und zur Darstellung zu bringen, doch können diese die klassische Bereitstellung von Informationen auf einer Webseite nicht ersetzen. Denn letztendlich ist der eigentliche Erfolg des Internets darauf zurückzuführen, dass Nutzer bereit sind, eigene Inhalte zu veröffentlichen, da sie wiederum Inhalte von anderen Nutzern nutzen können und sich die Zeit, die sie in das Veröffentlichen eigener Dokumente investieren, im Vergleich zu den Vorteilen und Möglichkeiten, die im Internet geboten werden, rentiert.

Während der vergangenen 18 Jahre hat sich das World Wide Web rasant weiterentwickelt. Einige Wissenschaftler sprechen bei der „ Evolution des Internets vom größten technologischen Fortschritt der Geschichte “ [Lac05, p. 2]. Inzwischen existieren Applikationen, welche vor Jahren nicht denkbar waren – angefangen bei der Möglichkeit, Internetseiten dynamisch mithilfe von Programmiersprachen wie PHP, Java oder .NET erstellen zu können bis hin zu Web-Services und Technologien wie AJAX, welche im Rahmen der Web 2.0 – Entwicklung an Bedeutung gewonnen haben.

Was die gerade geschilderten Schwächen des heutigen Internets angeht, so scheint es möglich, dass auch dafür neue Lösungen gefunden werden können, mit deren Hilfe der Informationszugriff durch zukünftige Anwendungen in einer noch nicht da gewesenen Art und Weise ablaufen könnte. Dazu ist im Grunde genommen kein vollkommen „neues“ Internet mit anderen Basistechnologien nötig, da die eXtensible Markup Language an sich dafür flexibel genug ist und dafür in den vergangenen Jahren eine Vielzahl an ausgereiften Werkzeugen entwickelt wurden, die auch in Zukunft nutzbar sein sollten. Dass semantikbasierte Anwendungen bisher noch nicht verbreitet sind, ist primär auf eine unbefriedigende Informationsrepräsentationen zurückzuführen, die Inhalte in einer allgemeingültigen, maschinenverständlichen Form auszeichnen können. Der leitende Forscher zur Entwicklung der DARPA Agent Markup language (DAML) schilderte dies wiefolgt: „ The current web is a victim of its own success. […] The web must be terraformed to allow automated software agents to explore its expanses “ [Lac05, p.6].

1.3. Das Semantic Web

Erste Bestrebungen, Inhalte besser beschreiben und über Anwendungsgrenzen hinaus für automatische Verarbeitungen bereitstellen zu können, gab es bereits 1995, wo mithilfe des XML-basierten Meta Content Frameworks (MCF) versucht wurde, Informationsstrukturen einheitlich zu beschreiben. Eine drei Jahre später daraus entwickelte, allgemeinere Methode zur Beschreibung von Informationen – das Ressource Description Framework (RDF) – ermöglichte es „ to say anything about anything “, indem mithilfe von Metadata Aussagen über Objekte getroffen werden konnten.

Der Begriff eines Semantik-basierten Internets schließlich wurde maßgeblich durch die Ideen von Sir Tim Berners-Lee geprägt. So schilderte Berners-Lee in Weaving the Web [Ber99] : „ I have a dream for the Web ... and it has two parts. In the first part, the Web becomes a much more powerful means for collaboration between people. […] In the second part of the dream, collaborations extend to computers. Machines become capable of analyzing all the data on the Web - the content, links, and transactions between people and computers. A ’Semantic Web’, which should make this possible, has yet to emerge, but when it does, the day-to-day mechanisms of trade, bureaucracy, and our daily lives will be handled by machines talking to machines, leaving humans to provide the inspiration and intuition.”

Seitdem wird weltweit geforscht, um diese Vision Realität werden zu lassen. Sowohl in den USA, als auch in Europa wurden erste Ansätze entwickelt, um Inhalte so zu beschreiben, dass sie sowohl von Menschen als auch Computern verstanden werden können. Das United States Department of Defence entwickelte dazu im Jahr 2000 die DARPA Agent Markup Language, während in Europa parallel dazu an einer expliziten Repräsentation von Semantik durch die Ontology Inference Language (OIL) geforscht wurde. Beide Konzepte lieferten wichtige Erkenntnisse für weitere Forschungsarbeiten und wurden schließlich zu DAML+OIL vereint.

Die Web Ontology Group des World Wide Web Consortiums (W3C) schließlich versuchte im Februar 2004 unter der Leitung durch Sir Tim Berners-Lee eine semantische Auszeichnungssprache für zukünftige Anwendungen zu standardisieren. Aus der Kombination verschiedener Vorschläge ging schließlich die Web Ontology Language (OWL) hervor, die inzwischen eine breite Unterstützung gefunden hat. Dennoch existieren weitere semantische Sprachen und Dialekte und es scheint bisher noch unklar, welches Konzept sich auf Dauer durchsetzen wird, auch wenn die Konzeption hinter OWL schlüssig scheint und zunehmend anerkannt wird.

Insgesamt gesehen ist die Forschung an einem Semantic Web noch recht neu. Grundlagenforschung wurde zwar bereits vor Jahrzehnten im Bereich der Künstlichen Intelligenz betrieben, doch ist die Übertragung der Konzepte auf das Internet nicht einfach, weswegen zunächst viel über theoretische Grundlagen, Begrifflichkeiten, Modelle und Zielsetzungen des Semantic Web diskutiert wurde. Der Begriff des „Semantic Web“ ist dahingehend zu einer Art buzzword geworden, von dem jeder spricht und eine eigene Vorstellung dazu hat, was es umfasst. Den Begriff des Semantic Web eindeutig zu definieren ist daher schwierig und bisher hat sich auch keine eindeutige Definition durchgesetzt. Mögliche Ansätze sind:

- “The Semantic Web is not a separate Web but an extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation” [Ber01]
- “[The Semantic Web is an] International effort to make the vast data resources of the World Wide Web available in a format amenable to automated processing by intelligent agents and other computer programs. […] However, most Semantic Web technology will be transparent to users” [Pas04]
- “The Semantic Web will give you software agents that will tackle your daily needs quietly, effectively, even with common sense, finding the information they need and negotiating with other agents on your behalf. Or, the Semantic Web will be a little more of what we have now – a little faster, a little smarter, with more complex software. Or, the Semantic Web is all hype” [Pas04]
- “The Semantic Web provides a common framework that allows data to be shared and reused across application, enterprise, and community boundaries. It is a collaborative effort led by W3C with participation from a large number of researchers and industrial partners. It is based on the Resource Description Framework” (W3C, http://www.w3.org/2001/sw/)
- “The Semantic Web [is] a vast object-oriented distributed database with machine-understandable schemas. Information representations will be distributed on geographically-distributed servers controlled by diverse authors of content. Just as its value grew as more sites were linked, the Semantic Web will become more valuable as information representations are connected” [Pas04]
- “The aim of the Semantic Web is to turn the web from a large hyperlinked book into a large interlinked database” (Semantic Web Advanced Development for Europe, http://www.w3.org/2001/sw/Europe/)
- “The Semantic Web concept is to do for data what HTML did for textual information systems: to provide sufficient flexibility to be able to represent all databases and logic rules to link them together to great added value” (proposal for a Semantic Web Logic Language, W3C 2000, http://www.w3.org/2000/01/sw/DevelopmentProposal)
- “The vision of Semantic Web is to let computer software relieve us of much the burden of locating resources on the Web that are relevant to our needs and extracting, integrating, and indexing the information contained within” [Cra01]

Die vorgestellten Definitionsansätze lassen sich prinzipiell in zwei Kategorien einteilen. Entweder wird versucht, das Konzept des Semantic Web anhand des Verhaltens darin vorstellbarer Applikationen zu beschreiben („ data linked together to provide new services “), oder es wird näher auf die technische Realisierungsbasis eingegangen, inwieweit sich das Semantic Web vom heutigen Internet unterscheiden soll („ requires joining together data that is located in independent application domains “). Insgesamt wird ersichtlich, dass der Begriff des Semantic Webs nicht einfach abzugrenzen ist und dessen inhaltliche Deutung sich auch in der kommenden Zeit noch ändern kann.

Im Folgenden wird unter dem Begriff des Semantic Webs ein zukunftsträchtiger Ansatz gesehen, der sich an folgender Definition orientiert:

Definition 1: Semantic Web

Das Semantic Web stellt ein Konzept dar, bestehende Internetinhalte um Informationen zu ergänzen, mit welchen autonome Softwaresysteme in die Lage versetzt werden, den Sinngehalt von Daten eigenständig extrahieren, aufzubereiten und mit anderen Informationsquellen domainübergreifend kombinieren zu können mit dem Ziel, aus verteilten Wissensbasen qualitativ hochwertige Ergebnisse zu extrahieren, wozu bisher die Interaktion mit einem menschlichen Nutzer nötig war.

Abbildung in dieser Leseprobe nicht enthalten

1.4.Zielsetzung der Arbeit

Das Ziel der vorliegenden Studie ist es, die in den vergangenen Jahren entwickelten Technologien und Konzepte des Semantic Web auf Ihre praktische Anwendbarkeit zu testen. Die praktische Umsetzbarkeit wird an der Realisierung eines prototypischen Webapplikation aufgezeigt, welche grundlegende Projekt- und Workflowmanagementaktivitäten ermöglichen soll. Diese Anwendungsdomain ist momentan im Kontext des kollaborativen Arbeitens verbunden mit einer semantikbasierten Umsetzung hochaktuell, gleichzeitig aber auch so gut erforscht, dass auf eine Reihe fester Konzepte und Begrifflichkeiten zurückgegriffen werden kann, welche sich semantisch gut beschreiben lassen. Der Hype-Cycle in Abbildung 2 veranschaulicht die momentane Präsenz des Themas.

Alle zu verarbeitenden Informationen in dem zu entwickelnden System werden in einem Pool aus verteilten (Web-)Dokumenten bereitgestellt, wobei die darin enthaltenen Daten mit zusätzlichen Informationen zur Beschreibung der Semantik versehen sind. Das gesamte System wird darauf ausgelegt, den kollaborativen Gedanken des Semantic Web bestmöglich umzusetzen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Gartners Hype Cycle für aufstrebende Technologien 2006, Quelle: http://www.geospatialsemanticweb.com/wp-content/uploads/2006/08/hypecycle2006.jpg

Es soll demonstriert werden, welche Möglichkeiten existieren, eine Problemstellung in einem lauffähigen System praktisch abzubilden, modellrelevante Informationen aus dazugehörigen Webdokumenten zu extrahieren und diese so aufzubereiten, dass sie einen Mehrwert für den Nutzer liefern können. Die Grundlagen von Projektmanagementsystemen sind in den letzten Jahrzehnten bereits gut erforscht worden, wodurch eine Vielzahl an Vergleichssystemen zur Verfügung steht, deren Stärken und Schwächen zunächst untersucht werden können und aus denen ein entsprechendes Grundvokabular abgeleitet werden kann. Das zu entwickelnde System hat schließlich der Anforderung zu genügen, durch eine einfache Bedienung den Menschen bei der täglichen Arbeit zu unterstützen, was im Kern das Grundanliegen der Informatik ist (vgl. [Wah06]).

Nachdem in diesem Einführungskapitel dazu zunächst ein Überblick über den aktuellen Forschungsstand gegeben wurde, sollen in Kapitel 2 zunächst grundlegende Begriffe zur Realisierung eines Projektmanagementsystems geklärt sowie ein Überblick über im Einsatz befindliche Managementsysteme gegeben werden. Besonderer Wichtigkeit kommt dabei der Definition eines Grundvokabulars zu, welches für alle Beteiligten wohl unterscheidbare Konzepte umfasst. In Kapitel 3 schließlich werden die Ideen des Semantic Webs aus Kapitel 1 mit den Grundlagen des Projektmanagements aus Kapitel 2 verknüpft und ein Konzept erarbeitet, wie ein Semantic Web – basiertes System zur Unterstützung von Workflow- und Projektmanagement aussehen könnte. Kapitel 4 beschreibt die konkrete Umsetzung des Konzeptes basierend auf einem ersten Applikations-Prototypen in C# / ASP.NET. Nachdem in Kapitel 5 die Funktionalität und Bedienung im praktischen Einsatz vorgestellt wird, werden in Kapitel 6 die gewonnenen Erkenntnisse diskutiert und Vergleiche zu herkömmlichen Projektmanagementsystemen angestellt. Abschließend wird ein Ausblick auf mögliche Weiterentwicklungsmöglichkeiten des Prototypen gegeben und eine Vermutung aufgestellt, welche Entwicklungen im Rahmen der Semantic Web – Bewegung in den kommenden Monaten zu erwarten sind und welche Probleme dabei mitunter noch gelöst werden müssen, welche in dieser Studie aufgefallen sind. Zu betonen ist dabei, dass in dieser Arbeit die Entwicklung eines akademischen Prototyps im Mittelpunkt steht, der grundlegende Funktionen bereitstellt, der die Funktionalitäten von herkömmlichen, über mehrere Jahre professionell entwickelten Systemen jedoch nicht erreichen kann und möchte.

1.5. Aktueller Stand

Das Angebot an Literatur zu klassischem und modernen Projektmanagement ist nahezu unüberschaubar. Allein eine Suche bei Amazon.com nach dem Begriff „ Project Management “ liefert knapp 32.000 Treffer zurück (durchgeführt am 27.07.2006). In der gleichen Größenordnung liegen Veröffentlichungen zu dem Thema Process- oder Workflow-Management sowie Knowledge Management. Im Gegensatz zu der interdisziplinären Ausrichtung dieser Veröffentlichung liegt der Schwerpunkt der Mehrheit aller erhältlichen Publikationen jedoch im wirtschaftswissenschaftlichen Bereich. Daraus entstandene Projekt- oder Workflowmanagementsysteme sind in großer Vielzahl sowohl in kommerziellen Versionen vorhanden als auch frei verfügbar. Eine entsprechende Übersicht bietet beispielsweise http://www.softguide.de/software/projektmanagement.htm. Die informationstechnische Umsetzung eines derartigen Systems wird unter anderem in [Kir94] und [Hab98] behandelt. Neuere Arbeiten aus dem Bereich der Informatik konzentrieren sich insbesondere auf die Modellierung von Prozessen mittels UML [Pet99] und anderen deskriptiven, XML-basierten Ansätzen [Hun06]. Möglichkeiten, Ontologie-basierte Systeme zum Workflow- und Projektmanagement einzusetzen, werden von vielen Autoren aufgezeigt, jedoch bisher selten vertieft [Pel06]. Besonderer Bedeutung kommt dabei der Wissensvernetzung in Organisationen [Sch06] und dem kollaborativen Wissensmanagement [Sur06] zu.

Nachdem vor allem im Bibliotheksbereich frühzeitig die Auszeichnung von Informationen erprobt wurde [Sch00], finden sich seit einiger Zeit eine Reihe weiterer Anwendungen im Internet, welche mithilfe eines semantischen Markups Informationen bereitstellen oder vorhandene Informationen aufbereiten und aggregieren (als Beispiel sei unter anderem der Suchdienst www.kartoo.com genannt). Im Bereich des Wissensmanagements wurde frühzeitig versucht, die Idee des Semantic Web auf Wiki-artige Systeme zu übertragen und daraus Semantische Wikis mit neuartigen Funktionen zu entwickeln (siehe http://wiki.ontoworld.org/wiki/Category:Semantic_wiki und http://platypuswiki.sourceforge.net/) . Die Weiterentwicklung zu einem vollwertigen System zur Unterstützung von Wissensmanagement wurde unter anderem in dem Ike Wiki – Projekt [Ike06] angestrebt, die aktuell verfügbare Testumgebung lässt jedoch keinen Schluss auf die Weiterentwicklung dieser Idee zu. Aufgrund des großen Interesses im Anwenderbereich an einem derartigen System zur Unterstützung von Wissens- und Projektmanagement ist die Forschung an diesem Thema hochrelevant. Neue Veröffentlichungen zeigen dabei unter anderem auf, wie eine Kooperation zwischen Projekt- und Workflowmanagementsystemen aussehen könnte [Bau04]. Darin wird vorgestellt, inwieweit Projektmanagement und Workflowmanagement sich von unterschiedlichen Blickpunkten um die Realisierung und Überwachung von Abläufen kümmern. Projektmanagement könnte dabei auf einer abstrakteren Ebene ablaufend angesehen werden als Workflowmanagement. Mit einem semantikbasierten Ansatz könnten diese beiden Systemwelten nun auf inhaltlicher Ebene vereint werden, was nachfolgend in dieser Arbeit demonstriert werden soll.

2. Grundlegende Betrachtungen

„Sag mir, wie ein Projekt beginnt und ich sage Dir, wie es endet.“ ~ Gero Lomnitz, Institut für praktische Psychologie und Organisationsberatung, Köln

2.1. Wozu Projektmanagement?

Sobald mehrere Menschen zusammenarbeiten, um ein gemeinsames Ziel zu erreichen, spricht man umgangssprachlich von einem Projekt. Dementsprechend sind Methoden zur Aufteilung von Aufgaben und zur Überwachung von Arbeitsabläufen schon seit langer Zeit bekannt. Bereits in der Antike sollen große Vorhaben wie der Bau der ägyptischen Pyramiden oder der Chinesischen Mauer im Kontext eines Projektes durchgeführt worden sein. [Möl00]

Die Vorstellungen des heutigen Projektmanagements gehen bis in das 18. Jahrhundert zurück und wurden maßgeblich durch den aus Schottland stammenden Ökonomen Adam Smith (1723 - 1790) geprägt. Besondere Bedeutung kommt dabei dem Buch „Der Wohlstand der Nationen“ (1776) zu, in dem Smith Möglichkeiten aufzeigt, die Produktivität von Arbeitskräften um ein Vielfaches zu steigern und damit gleichzeitig Produktions- und Warenkosten maßgeblich zu senken. Im anbrechenden Zeitalter der Industriellen Revolution wurden darauf aufbauend verstärkt neue Firmenstrukturen und standardisierte Betriebsabläufe geschaffen. Ständig wiederkehrende Handlungsabläufe wurden im Zuge dieser Standardisierung identifiziert, in abgegrenzte Zuständigkeitsbereiche aufgeteilt und die Ergebnisse dokumentiert, sodass sie von hoch spezialisierten Arbeitskräften mit klar formulierten Aufgabenbereichen ausgeführt werden konnten und etwaige Abweichungen oder Probleme sofort erkannt wurden. Der gesamte Arbeitsablauf wurde durch diese Optimierungen effizienter, zuverlässiger, sicherer und vor allem vorhersagbar.

Während die Vorteile dieser Herangehensweise nicht zu bestreiten sind und sich schnell in anderen Unternehmen und Arbeitsbereichen durchsetzten, entwickelte sich ein neues Problem: Je nach Sichtweise stand nun nicht mehr das Projekt mit seinem Projektergebnis („ Die Mitarbeiter der Firma fertigen gemeinsam ein Produkt “) im Mittelpunkt, sondern vielmehr der Arbeitsprozess mit seinen verschiedenen Arbeitsphasen. Die Effizienz der Produktion war maßgeblich von der Qualität der Planungen der Arbeitsabläufe abhängig. Wurde ein Engpass nicht rechtzeitig erkannt, oder gingen Informationen und Teilergebnisse von einem Produktionsabschnitt zum nächsten verloren oder kamen verspätet hat, so hatte dies gravierende Konsequenzen auf die gesamte Produktion. Der Präsident von General Motors, Alfred P. Sloan jr. (1875-1966), erkannte dies und schuf ein erstes Managementsystem, auf dessen Basis Arbeitsabläufe überwacht und koordiniert werden konnten.

Parallel dazu wurden neue Unternehmensbereiche geschaffen, welche abgegrenzt vom reinen Produktionsbetrieb den Projektfortschritt analysierten, Planungsaufgaben durchführten und anhand vorliegender Daten den Arbeitsablauf steuern und geeignete Maßnahmen ergreifen konnten – woraus der Tätigkeitsbereich des Controllings maßgeblich hervorging. [Käm00]

Obwohl das „moderne Projektmanagement“ besonders auf militärischem Gebiet Mitte des 20. Jahrhunderts einen enormen Aufschwung erhielt, blieben die grundlegenden Ideen bis weit in die 80er Jahre hinein paradigmisch bestehen. Ein Wandel zu neueren Prozessmethoden wurde nötig, als man erkannte, dass sich das Marktumfeld zu stark veränderte und die strikte Trennung von Arbeitsaufgaben nicht länger haltbar war. Kollaboratives Arbeiten über Tätigkeitsgrenzen hinweg rückte stärker in den Mittelpunkt, und neue Managementmethoden wurden entwickelt, um vormals getrennte Aufgabenbereiche in einem kohärenten Unternehmensprozess modellieren zu können [Ham93]. Weiterhin schienen etablierte Managementstrukturen als immer häufiger aufgebläht und zu sehr auf Zahlen als auf Objekte der realen Welt fixiert. Eine Neuorganisation wurde nötig, welche sich stärker an Geschäftsprozessen orientierte und in der insbesondere der Begriff des Workflows eine zentrale Rolle einnahm.

Inzwischen findet man derartige moderne Organisationsformen nicht nur in großen Unternehmen. Während sich Projektplanung in früheren Jahren vorwiegend auf große, überaus komplexe Projekte bezog, findet man dies heutzutage in nahezu allen gesellschaftlichen Bereichen, ob nun im Geschäftsalltag von Großunternehmen, bei der Antragsabwicklung in kleinen und mittelständischen Unternehmen (KMUs), bei der Realisierung von Softwareprojekten im Software- Engineering oder auch im Privatsektor, wo durch eine Reihe von Organizer-Software besonders das Zeitmanagement im Mittelpunkt steht. Alle Anwendungen beweisen, dass Projektmanagement den effizienten Einsatz von Ressourcen ermöglicht, eine Rahmenstruktur für die Umsetzung eines Projektes vorgibt und ein optimales Ergebnis anstrebt, wobei ein Zugewinn im Mittelpunkt steht, der ohne entsprechende Nutzung womöglich nicht vorhanden wäre.

Aufgrund der Komplexität des Themas ist inzwischen eine unüberschaubare Anzahl an Büchern zum Thema Projektmanagement am Markt vorhanden. Vielfach werden im Alltag dabei die Begriffe Projektmanagement und Workflowmanagement oder Prozess und Workflow als Synonym gebraucht, obwohl im Kern wesentliche Unterschiede erkennbar sind. Vor der Analyse der Anforderungen an ein Projekt- und Workflowmanagementsystem soll daher zunächst eine klare Definition der Begriffe in diesem Zusammenhang erfolgen.

2.2. Begriffsdefinitionen

Begrifflichkeiten in Zusammenhang mit Projektmanagement werden im Alltag häufig mit unterschiedlichen inhaltlichen Deutungen angewendet. Die Abgrenzung ist meist unscharf – so kommt es vor, dass Konzepte mitunter widersprüchlich verwendet werden oder in einem falschen Kontext. Ursache dafür mag sein, dass sich in der vielfältigen Literatur zum Thema Projektmanagement unterschiedliche Vokabularien durch verschiedene Autoren und deren Standpunkt parallel entwickelt haben und dadurch in der Geschäftswelt eher flüchtig gebraucht werden. Die folgenden Begr-iffsdefinitionen sollen in erster Linie dazu dienen, einzelne Begriffe aus dem Gebiet des Projektmanagements klar voneinander abzugrenzen und zu Konzepten des realen Lebens Assoziationen herzustellen. Dies soll im nächsten Schritt dazu benutzt werden, die Begriffe hierarchisch zueinander in Beziehung zu setzen (Taxonomie) und darauf aufbauend in Kapitel 3 ein einfaches Modell (Ontologie) zu entwickeln, welches auf diesen Begriffen basiert und das zu realisierende System im Kern beschreibt.

2.2.1. Projekt

Der Brockhaus definiert den Begriff Projekt als „ ein geplantes oder bereits begonnenes, groß angelegtes Vorhaben “. Die Ableitung vom lateinischen Begriff projectum für etwas „nach vorn geworfenes“ suggeriert dabei die Zielstellung, mit dem Abschluss des Projektes eine Entwicklung vorangebracht zu haben, die es vorher in dieser Form nicht gab. Die ursprüngliche Bedeutung des Wortes Projekt bezog sich jedoch zunächst auf etwas vorangegangenes (lat. Pro – vorher), im Speziellen auf die Aufstellung eines Projektplanes, nicht auf die sich daran anschließende, konkrete Ausführung des Projektes. Die Bedeutung wechselte im anbrechenden Zeitalter der Industrialisierung, als ein Projekt nun als die Gesamtheit aller Vorgänge aufgefasst wurde, die zum Erreichen einer vorgegebenen Zielstellung nötig sind. Diese Definition ist dahingehend zu spezialisieren, dass verschiedene Disziplinen das Ziel eines Projektes unterschiedlich auffassen. So wird in wirtschaftswissenschaftlichen Publikationen ein Projekt als ein betriebliches Vorhaben mit einem definierten Start- und Endtermin und einem klaren Auftrag (vgl. QM-Lexikon unter www.qm-world.de) gesehen, welches kosten- und abrechnungsmäßig separat erfasst werden kann. Anderorts wird der Begriff Auftrag durch ein Kriterium ersetzt, dass ein Projekt zu einer Veränderung der Strukturen führen muss. Stärker technisch geprägte Definitionen sehen darin eher die Realisierung einer Menge definierter Ergebnisse entsprechend vereinbarter Anforderungen (Definition der International Project Management Association). In der DIN 69901 (Projekt-Management, 1987) wird der Begriff Projekt offiziell als ein Vorhaben, das im wesentlichen durch eine Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, definiert. Aber auch diese Definition ist nicht in allen Fällen schlüssig genug, und wir unter anderem von Berner [Ben01] als „unsauber und nichtssagend“ abgetan.

In allen Definitionen finden sich dennoch Gemeinsamkeiten, die sich wiefolgt zusammenfassen lassen:

Definition 2: Projekt

Ein Projekt ist eine zeitlich begrenzte, längerfristige Unternehmung mit einmaligem Charakter, die unter einer wohl definierten, komplexen Aufgabenstellung ein neues Resultat erreichen möchte.

Abbildung in dieser Leseprobe nicht enthalten

Ein Projekt wird damit über den Projektinhalt und Projektumfang definiert. Der Lösungsweg ist zu Beginn häufig unbekannt, nur eine Zielrichtung existiert, da aufgrund der Komplexität die gesamten Ausmaße eines Projektes mit allen Abhängigkeiten und gegensätzlichen Zielen nicht sofort zu erkennen sind. Ein Projekt zerfällt deshalb in der Regel in mehrere Phasen, die zusammen den Projektlebenszyklus bilden. Jede Phase besitzt eine entsprechende Zielsetzung, deren Erreichen den Abschluss einer Phase charakterisiert. Unterschiedliche Aufgaben im Projekt können dabei von verschiedenen Personen bearbeitet werden, sodass die kollaborative und interdisziplinäre Arbeit im Team eine zentrale Rolle einnimmt.

2.2.2. Phase

Eine Projektphase ist ein Möglichkeit, Projekte in zeitlich, logisch oder organisatorisch abgegrenzte Sinnabschnitte zu unterteilen. Eine Phase fasst eine Menge von Aktivitäten und Ereignissen zu einer Einheit zusammen. Am Ende jeder Phase steht eine Zielsetzung (oft als Meilenstein bezeichnet), die das zu realisierende Ergebnis zum Abschluss der Phase kennzeichnet. Ist dieses Ziel erreicht, so wird die Phase als abgeschlossen betrachtet. Phasen in einem Projekt müssen sich voneinander abgrenzen lassen und inhaltlich voneinander unterscheiden, das heißt, das Auftreten einer konkreten Phase im Projektverlauf muss eindeutig sein (einzelne Projektabschnitte können jedoch mehrfach (inkrementell) durchlaufen werden). Ziel der Aufteilung in Phasen ist es, das Gesamtprojekt besser planen und den Projektfortschritt besser überwachen zu können. In jeder Phase werden Prozesse festgelegt, welche zum Abschließen der Phase durchzuführen sind. Typische Phasen eines Projektes sind beispielsweise eine Analyse- oder Planungsphase, Implementierungsphase und Testphase. Die Abgrenzung von Phasen muss dabei nicht nur auf einer zeitlichen, sequentiellen Trennung beruhen, sondern kann sich auch auf anderen Kriterien stützen, zum Beispiel auf der Unterscheidung in unterschiedliche, zu realisierende Objekte.

Definition 3: Phase

Eine Phase ist die abstrakte Zusammenfassung einzelner Projektaktivitäten nach zeitlichen, logischen, oder organisatorischen Merkmalen zu voneinander trennbaren Projektabschnitten, an deren Ende ein konkretes Ergebnis vorliegt, welches im weiteren Projektverlauf weiterverwendet werden kann.

Abbildung in dieser Leseprobe nicht enthalten

2.2.3. Prozess

Etymologisch stammt der Begriff aus dem Lateinischen (lat. processus = Bewegung, procedere = voranbringen) und kennzeichnet eine Abfolge von Tätigkeiten zur Erreichung eines Zieles oder zur Durchführung einer Aufgabe. Die jeweiligen Aktivitäten sind in der realen Welt durchführbar und hinsichtlich ihrer Durchführbarkeit und ihres Ergebnisses präzise beschreibbar. Modellhaft führt jede Ausführung einer Aktivität innerhalb eines Prozesses zu einem Zustandsübergang in dem beschriebenen System. Prozesse sind dabei zu einem beliebigen Zeitpunkt wiederholbar, stellen also feste, vordefinierte Handlungsanweisungen dar, was sie damit grundlegend von dem konzeptionellen Inhalt eines Projektes unterscheidet. Die Menge möglicher Ergebnisse eines Prozesses als logische Verknüpfung mehrerer Aktivitäten ist in der Regel deterministisch, kann andernfalls zumindest stochastisch beschrieben werden. Die Abarbeitung eines Prozesses wird durch Eintreten einer oder mehrerer Ereignisse ausgelöst (getriggert). Als Konsequenz daraus existiert ein Prozess nicht eigenständig, sondern muss einem konkreten Kontext zugeordnet sein, das heißt, es müssen bei den Eintreten des Ereignisses die zu bearbeitenden Objekte bekannt sein sowie eine Vorstellung vom Endprodukt nach Abschluss des Prozesses existieren. Im Gegensatz zu einem Projekt kann für einen Prozess häufig kein absolutes Start- und Enddatum angegeben werden. Vielmehr müssen in den übergeordneten Projektphasen Zeitspannen eingeplant werden, im Rahmen derer der konkrete Prozess zur Ausführung kommt. Ziel des Prozessmodells ist es, Planungsaufwand zu reduzieren, indem auf abstrakterer Ebene eine Folge fester, immer wiederkehrender Handlungsanweisungen zu einem Oberbegriff zusammengefasst werden kann. Jede Handlung in einem Prozess kann selbst wiederum einen Prozess darstellen, das heißt, Prozesse können schrittweise verfeinert werden. Ein elementarer Prozessschritt (Aktivität) ist erreicht, wenn eine weitere Unterteilung der Tätigkeit nicht möglich oder sinnvoll erscheint und die Tätigkeit direkt durchgeführt werden kann. Mehrere Prozesse können sowohl sequentiell als auch parallel von einem oder mehreren Beteiligten ausgeführt werden.

Abbildung in dieser Leseprobe nicht enthalten

Ein Prozess ist eine wiederholbare, im Kern eindeutig beschreibbare Tätigkeitsanweisung und kennzeichnet eine Abfolge von Arbeitsschritten zur Durchführung einer konkreten Aufgabe.

Abbildung in dieser Leseprobe nicht enthalten

Besonderer Bedeutung kommt im Projektmanagement-Umfeld dem Begriff des Geschäftsprozesses zu, der von einem physikalischen oder technischen Prozess abzugrenzen ist und bei dem im Speziellen das Erreichen eines Geschäftsresultates im Vordergrund steht. Ein Geschäftsprozess ist eine Abfolge von Aktivitäten, die der Erbringung einer Dienstleistung dient. Er wird durch ein oder mehrere Ereignisse gestartet und durch ein oder mehrere bestimmte Ereignisse abgeschlossen. Die Besonderheit im Gegensatz zu anderen Prozesstypen liegt darin, dass unter dem Hintergrund des wirtschaftlichen Bezugs ein Geschäftsprozess nicht auf eine homogene Projektgruppe oder Betriebsabteilung beschränkt ist, sondern bewusst das Arbeiten über Abteilungsgrenzen hinweg betont.

So definiert Davenport 1993 einen Geschäftsprozess als „ a structured, measured set of activities designed to produce a specific output for a particular customer or market. It implies a strong emphasis on how work is done within an organization, in contrast to a product focus’s emphasis on what. A process is thus a specific ordering of work activities across time and space, with a beginning and an end, and clearly defined inputs and outputs: a structure for action” [Dav93] .

Diese Strukturierung eines Geschäftsprozesses ist jedoch nicht mit einer real ausführbaren Arbeitsanweisung für eine beteiligte Person innerhalb dieses Prozesses zu verwechseln. Vielmehr liegt der Schwerpunkt auf einer konzeptionellen Trennung der verschiedenen Tätigkeiten innerhalb einer Organisation.

2.2.4. Workflow

Der Begriff Workflow und Prozess stehen zueinander in enger Beziehung. So wird ein Workflow im Brockhaus auch als die „ prozessorientierte Abwicklung arbeitsteiliger Vorgänge […] mit dem Ziel größtmöglicher Effizienz “ definiert, weswegen beide Begriffe häufig sogar in Synonymie verwendet werden. Vom informationstechnischen Standpunkt aus gesehen besteht jedoch dahingehend ein wesentlicher Unterschied, dass ein Workflow im engeren Sinne einer technischen Modellierung eines Prozesses entspricht, und damit eine direkt ausführbare Tätigkeitsanweisung darstellt. Das Fraunhofer Institut definiert den Begriff Workflow dahingehend, als dass er „ die an einem Arbeitsprozess beteiligten Personen und Arbeitsprozesse in einem Prozessmodell abbildet “ [Joh06]. Dem im Namen betonten „ Arbeitsablauf “ kommt dabei entscheidende Bedeutung zu, da innerhalb eines Workflows versucht wird, einzelne Arbeitsschritte (Aktivitäten) zu identifizieren und diese zueinander in Beziehung zu setzen. Sowohl die Arbeitsschritte als auch die Beziehungen sind hierbei eindeutig. Die Abfolge der Arbeitsschritte kann im Gegensatz zu einem Geschäftsprozess von einer beteiligten Person direkt umgesetzt werden, da diese von operativer Seite möglichst genau beschrieben wird. Rusinkiewicz beschreibt Workflows deshalb als „ Aktivitäten, welche die koordinierte Ausführung einer Reihe von Aufgaben durch unterschiedliche Verarbeitungseinheiten umfassen “ [Rus95]. Ziel eines Workflows ist es, den Arbeits- oder Informationsfluss mithilfe technischer Systeme so weit überwachen zu können, dass der Arbeitsverlauf für alle Beteiligten transparenter wird, die Durchführung qualitativ verbessert wird (indem keine vorab geplanten Tätigkeiten vergessen oder übergangen werden) und bestimmte Rahmenaufgaben automatisiert durchgeführt werden können und nicht mehr das Eingreifen eines Menschen erfordern, was wiederum einer Effizienzsteigerung des zugrunde liegenden Prozesses entspricht. Durch den engen Zusammenhang zwischen Workflows und Prozessen können Workflows ebenfalls beliebig verfeinert und wiederum in Workflows unterteilt werden, bis eine weitere Unterteilung nicht weiter möglich ist oder sinnvoll erscheint. Die beschriebene Tätigkeit ist dann elementar und kann eigenständig ausgeführt werden.

Abbildung in dieser Leseprobe nicht enthalten

Hinter einem Workflow verbirgt sich die informationstechnische Realisierung eines Prozesses in Form einer direkt ausführbaren Tätigkeitsanweisung, welche aus einzelnen durchzuführenden Aktivitäten besteht.

Abbildung in dieser Leseprobe nicht enthalten

Workflows lassen sich auf unterschiedliche Art und Weise klassifizieren und beschreiben. Eine mögliche Klassifikation beruht auf der Beschreibbarkeit des auszuführenden Workflows. Neben gut strukturierten Workflows existieren dabei auch strukturlose Workflows, die nicht in eine Abfolge von Tätigkeiten zerlegt werden können. Sowohl bei elementaren Tätigkeiten als auch bei strukturlosen Workflows ist eine textuelle Beschreibung der Tätigkeit in irgendeiner Form nötig. Eine Übersicht über eine mögliche Kategorisierung des Workflow-Begriffs zeigt Tabelle 1.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Kategorisierung von Workflows nach der Struktur

Daneben lassen sich Workflowmodelle in objektbasierte und aktivitätsbasierte Workflows einteilen. Objektbasierte (entity-based) Workflow beschreiben im Kern Dokumente, welche bis zu Ihrer endgültigen Fertigstellungen verschiedene Zustände durchlaufen. Im Mittelpunkt der Beschreibung steht der einzelne Arbeitsschritt („ work item “), wie das entsprechende Objekt in dem jeweiligen Zustand verändert wird. Dem gegenüber stehen aktivitätsbasierte Workflows, welche eine Abfolge durchzuführender Tätigkeiten in den Mittelpunkt stellen, um die Gesamtaufgabe abzuschließen. Beide Konzepte werden kontrovers diskutiert, wobei die Meinung vertreten wird, dass objektbasierte Workflows für einfache Sachverhalte sehr geeignet sind, sehr komplexe Tätigkeiten aber nur mit einem aktivitätsbasierten Workflowkonzept realisiert werden könnten. Parallel dazu gibt es Meinungen, dass im Grunde beide Konzepte auf einer niedrigeren Ebene ineinander überführbar sind^[4].

Als letztes Klassifikationsmerkmal können Workflows in zustandsbasierte und nachrichtenorientierte Workflows eingeteilt werden, je nachdem, nach welchem Prinzip die Abarbeitung eines Workflows geschieht. Zustandsbasierte Workflows sehen einen Workflow als Abfolge einzelner Aktivitäten an, zwischen welchen Übergänge existieren, wobei der aktuelle Ausführungszustand durch eine Workflow-Engine verwaltet wird. Im Gegensatz dazu existieren ebenso Workflowausführungsmodelle, welche auf das Eintreffen von Nachrichten reagieren, mit anderen Systemen ständig in Kontakt stehen, und der Workflow basierend auf eintreffenden Ereignissen voranschreitet.^[5]

2.2.5. Aktivität

In den vergangenen Definitionen wurde bereits mehrmals der Begriff Aktivität verwendet. Dieser Begriff kann wiefolgt aufgefasst werden:

Abbildung in dieser Leseprobe nicht enthalten

Beschrieben werden kann eine Aktivität innerhalb eines Workflows durch den Zeitpunkt der Ausführung, benötigte Ressourcen zur Durchführung, einer Beschreibung der Tätigkeit mit einer eventuellen Spezifikation zu benutzender, externer Systeme und durch eine Auflistung der an der Ausführung beteiligten Personen. In manchen Publikationen wird statt des Begriffs „Aktivität“ eher der Begriff Aktion verwendet mit dem Verweis darauf, dass bei Verwendung der Bezeichnung Aktivität nicht eindeutig herausgestellt wäre, ob man in einem Workflow damit den Zustand oder den Zustandsübergang meint. Im Folgenden sei der Begriff Aktivität mit dem Wort Tätigkeit oder Arbeitsschritt gleichgesetzt und beziehe sich auf eine jeweilige auszuführende Aufgabe in einem konkreten Zustand des Workflows.

2.2.6. Projektmanagement

Zur Einordnung des Begriffes Projektmanagement diene erneut eine lexikalische Definition aus dem Brockhaus, der Projektmanagement definiert al die Gesamtheit der Planungs-, Steuerungs- und Kontrollaktivitäten, die bei relativ innovativen und risikobehafteten Vorhaben mit komplexer Struktur, vorgegebenen Terminen und limitierten Kosten anfallen, sowie für die fachbereichsübergreifende Koordination dieser Führungstätigkeiten. Im Wesentlichen umfasst diese Definition Methoden zur Durchführung eines Projektes. Im PMBOK Guide des Projektmanagement-Instituts wird dies weiter ausgeführt als „ the application of knowledge, skills, tools and techniques to project activities to meet project requirements” [PMI04].

Projektmanagement ist damit eine Tätigkeit, welche sowohl konzeptionelle Aufgaben wie das Identifizieren von Projektzielen und dem Abschätzen der Projektkomplexität, eine Beschreibung des Projektverlaufs sowie entsprechenden Ressourcenbedürfnissen, als auch die Überwachung der Projektdurchführung, eventuelle Umplanung, das Erreichen des Projektergebnisses, die Qualitätssicherung und auch eine Nachbetrachtung des durchgeführten Projektes umfasst. Daneben spielen weitere Aufgaben aus anderen Disziplinen – beispielsweise die Führung und Motivation eines Projektteams – eine wesentliche Rolle. Ziel ist es, durch den Einsatz von Projektmanagement die Fertigstellung eines Projektes unter begrenzten Ressourcen (Rahmenbedingungen bezüglich Zeit, Geld, Personal, Qualität u.a.) sicherzustellen. Für weitere Betrachtungen aus wirtschaftlicher Sicht sei auf weiterführende Literatur verwiesen; im Folgenden stehe vor allem die softwarebasierte Unterstützung von Projektmanagementaufgaben durch Projekt-Management-Systeme im Mittelpunkt. Diese sind in der Regel auf wohl definierte Anwendungsdomains spezialisiert und reichen in ihrer Komplexität von einfachen, kostenfreien Editoren bis hin zu komplexen und preisintensiven kollaborativen Softwaresystemen. Universelle Projekt-Management-Systeme, welche die Abwicklung von Projekten aus beliebigen Anwendungsbereichen erlauben, werden oftmals in Ihrer Einsetzbarkeit in Frage gestellt („ One size doesn’t fit all “). Vielmehr ist die Wahl eines geeigneten Projektmanagementtools von entscheidender Bedeutung – zu kleine Systeme genügen nicht den gestellten Anforderungen, zu ausgereifte Systeme können dem gegenüber zu einer zu komplizierten Bedienung für den konkreten Anwendungsfall führen. Im Allgemeinen bieten alle Projektmanagement-Systeme gewisse Funktionalitäten zur Verwaltung der Aufgaben von Projektbeteiligen, zur Projektplanung, der Dokumentenverwaltung und der Projektsteuerung. Gantt-Diagramme, Aufgabenlisten, Fortschrittsüberwachung, Terminplaner, Kontrollmechanismen, Kostenverwaltungsmodule und Reportfunktionen gehören zu typischen Funktionalitäten, welche durch Projektmanagement-Systeme geboten werden. In Kapitel 2.5 und 2.6 werden diese Softwaretools genauer untersucht.

2.2.7. Prozessmanagement

Während sich Projektmanagement auf die Umsetzung von Projekten beschränkt, umfasst Prozessmanagement die Überwachung von Prozessverläufen. Im Mittelpunkt steht die kosteneffektive Durchführung von Prozessen als Abfolge verschiedener Aktivitäten. Dazu ist eine genaue Beschreibung, Darstellung und Überwachung des Ablaufs einer Aktivität nötig, welcher durch Einsatz von Prozessmanagementmethoden stetig optimiert werden kann. Ein Prozess ist dabei im engeren Sinne als Geschäftsprozess zu sehen, das heißt, es stehen weniger sequentielle Arbeitsanweisungen im Mittelpunkt als vielmehr bereichsübergreifende Aufgaben, welche ausgeführt werden, um in ihrer Gesamtheit ein gemeinsames Ergebnis zu erreichen. Um den Fluss zwischen den einzelnen Instanzen zu verbessern und damit den Prozess zu optimieren, sind zum einen eine genaue Planung der Geschäftsprozesse, als auch die Verwendung vergleichbarer Messgrößen nötig.

2.2.8. Workflowmanagement

Im Mittelpunkt des Workflowmanagements steht die Unterstützung von Arbeitsabläufen durch technische Systeme (Workflow-Management-Systeme) mit dem Ziel der Effizienzsteigerung. Dies beinhaltet die Modellierung, Ausführung und Überwachung von Arbeitsprozessen in Form von Workflows. Modellierung umfasst hierbei die Darstellung von Teilen eines Geschäftsprozesses in Form von sequentiellen oder parallelen Arbeitsschritten, Ausführung die computergestützte Durchführung dieser Arbeitsschritte (möglicherweise durch Integration anderer Softwaresysteme), sowie Überwachung in erster Linie die Sicherstellung des Arbeitsfortschrittes durch Bereitstellung von Informationen über den bisherigen Prozessverlauf. Im Prinzip ist ein ähnliches Herangehen auch bei Projektmanagementsystemen, allerdings auf einer abstrakteren Ebene, wiedererkennbar. Basierend auf den vorgestellten Definitionen von Projekt und Prozess und der hierarchischen Beziehung zwischen diesen beiden Begriffen wäre es vorstellbar, ein Workflowmanagement als Teil eines Projektmanagementsystems aufzufassen. Dies war in der Praxis bis vor kurzem jedoch eher die Ausnahme. Eine Vielzahl von Workflowmanagementsystemen wurde zur operationalen Durchführung prozessorientierter Abläufe genutzt, während Projektmanagementsysteme vor allem zur Projektplanung genutzt worden. Die Vorteile der Kombination beider Systeme wurden unter anderem durch Bauer [Bau04] analysiert. Darin wird davon ausgegangen, dass Projektmanagementsysteme und Workflowmanagementsysteme teils vollkommen unterschiedliche Datenrepräsentationen verwenden und gleichzeitig unterschiedliche Funktionen bereitstellen, sodass eine direkte Systemintegration häufig nicht möglich sei. Sinnvoll wäre dies aber, da darüber Projektplanungsdaten für die Prozessbearbeitung bereitgestellt werden könnten, andererseits aber auch der aktuelle Bearbeitungszustand für die Projektplanung verfügbar wäre. Um dies zu erreichen, wird ein möglicher Weg in der Einführung einer Zwischenschicht gesehen, welche die Aggregation und Verteilung der Daten übernimmt.

2.2.9. Groupware

Im Zusammenhang mit Projektmanagement und kollaborativen Systemen wird häufig der Begriff Groupware genannt, welcher schlicht mit „Gruppenprogramme“ übersetzt werden könnte. Statt einer Reihe autarker Programme verbirgt sich daher aber häufig ein System zur Unterstützung kollaborativen Arbeitens, welches die Koordination von Aufgaben und Terminen sowie den systematischen Austausch von Dokumenten im Team ermöglicht. Der Fokus von Groupware liegt in der Bereitstellung von Funktionalitäten, welche die gemeinsame Arbeit an einer Ressource (bspw. mittels Multi-User-Editoren) ermöglichen und dafür vielfältige Interaktionsmöglichkeiten bieten. Im Gegensatz dazu wird in Workflow-Management-Systemen vor allem die Prozessstruktur und der Arbeitsfortschritt betont, während Groupwaresysteme häufig auf beliebigen, unstrukturierten Daten arbeiten können.

2.2.10. Knowledgemanagement

Ein letzter Aspekt, welcher bei der Verwaltung von Prozessen in Unternehmen und Institutionen eine wesentliche Rolle spielt, findet sich im Wissensmanagement (Knowledge Management). Dies ist darin begründet, dass die Durchführung von Arbeitsvorgängen möglichst gut dokumentiert werden muss, um eine erneute Ausführung zu einem späteren Zeitpunkt zu ermöglichen, ohne dass bisher gewonnene Erkenntnisse verloren gehen oder erneut erworben werden müssen (was unmittelbar zu einer Effizienzverschlechterung führt). Wissensmanagement umfasst jedoch nicht nur die Sicherung und den Einsatz vorhandenen Wissens, sondern ebenso die Generierung und Dokumentation neuen Wissens, welches in eine Wissensbasis einfließt, auf die immer wieder zurückgegriffen werden kann. Wissen ist ein relativ unscharfer Begriff, welcher in entsprechender Literatur zum Thema Knowledge Management unterschiedlich gedeutet wird. Im Folgenden umfasst die Wissensbasis neben der Beschreibung von Arbeitsabläufen auch alle damit verbundenen Daten, auf welche im Idealfall jeder Mitarbeiter zugreifen und darauf aufbauend die Wissensbasis erweitern kann. Dieser Ansatz ist für die Entwicklung eines Projekt- und Workflowmanagementsystems in jedem Fall zu berücksichtigen, wenn einzelne Aktivitäten definiert, beschrieben und in verschiedenen Prozessen verwendet werden.

2.3. Modellierungsansätze

Nachdem in 2.2. grundlegende Begriffe geklärt worden, ist zu einer Umsetzung in einem realen System zunächst eine geeignete Notations- und Darstellungsform zu suchen. Verschiedene Ansätze zur Darstellung von Workflows wurden dazu in den vergangenen Jahren entwickelt. Diese seien in diesem Kapitel näher vorgestellt. Im Gegensatz dazu finden sich im Projektmanagementbereich kaum standardisierte grafische Notationen oder Austauschformate. Im Hinblick auf die Entwicklung eines semantikbasierten Projektmanagementsystems soll dieser Abschnitt daher nach einer geeigneten Notation suchen, welche auch im Projektmanagementbereich sinnvoll nutzbar sei.

Die Durchführung verschiedener Aufgaben kann durch eine Aufschlüsselung in einzelne Arbeitsschritte (Aktivitäten) beschrieben werden, welche zeitlich zueinander in Beziehung gesetzt sind (sequentielle, parallele oder alternative Abarbeitungsmöglichkeiten). Die Modellierung dieser Aufgabenliste als Workflow basiert in der Regel auf einer Umsetzung als gerichteter, endlicher Graph mit einem (oder mehreren) ausgezeichneten Start- und Endzuständen. Dabei erfolgt modellbedingt eine Abstraktion verschieden starken Ausmaßes, da Tätigkeiten der realen Welt nur bis zu einem gewissen Grad strukturell dargestellt werden können. Im Mittelpunkt der Modellierung steht die Darstellung der Prozessausführung, die technisch bestmöglich unterstützt wird. Daneben spielen aber auch Daten über die modellierten Prozesse eine wesentliche Rolle.

Dies führt zu einer semiformalen Darstellung des zugrunde liegenden Arbeitsablaufs, da die Beziehung zwischen einzelnen Arbeitsschritten visuell abgebildet wird (das bedeutet, für einen Menschen einfach zu verstehen), die Graphstruktur selbst auch algorithmisch abbildbar ist, zusätzliche Informationen über die einzelnen Arbeitsvorgänge aber häufig den entsprechenden Knoten informell (das heißt, als textuelle Beschreibung) zugeordnet werden. Für eine computergeschützte Überwachung einer Tätigkeit ist eine rein formale Beschreibung der Tätigkeiten geeigneter, welche jedoch häufig aufwändiger zu formulieren und für einen Menschen schwieriger zu verstehen ist. Als Kompromiss verwenden aktuelle Workflow-Managementsysteme semiformale Beschreibungen, deren Vertreter Gadatsch entsprechend Abbildung 1 in die Kategorien Objektorientiert, Datenflussorientiert und Kontrollflussorientiert einordnet [Gad03]. Zoll [Zol06] erweitert dieses Schema um regelbasierte Methoden. In der Kategorisierung finden sich sowohl das klassische Modell der Ereignisgesteuerten Prozessketten (EPKs) als auch Modellierungsansätze basierend auf UML wieder. Darüber hinaus existiert seit 2002 neben UML eine weitere, zunehmend häufig benutzte Notationssprache in Form der Business Process Modelling Notation (BPMN).

Alle Modellierungsansätze haben gemeinsam, dass sie von einem Grundvokabular mit elementaren Bausteinen ausgehen (welches sich an den vorgestellten Definitionen aus Abschnitt 2.2 orientiert), aus denen komplexere Workflows aufgebaut sind. Den elementaren Bausteinen können Metainformationen wie etwa zu Beginn benötigte Ressourcen, Ausgabeobjekte und Transformationsregeln zugeordnet werden. Primäres Ziel ist es, Funktionsabfolgen für den Betrachter übersichtlich darzustellen. Darüber hinaus muss das Modell so formal aufgebaut sein, dass eine Teilautomatisierung durch andere Software ermöglicht wird. Im Folgenden sind wesentliche Modellierungsmethoden genauer vorgestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Methoden der Prozessmodellierung nach Gadatsch [Gad03]

2.3.1. Ereignisgesteuerte Prozessketten

Ereignisgesteuerte Prozessketten (EPKs) bieten ein Modell zur Darstellung von Arbeitsabläufen, welches 1992 in Deutschland an der Universität des Saarlandes entwickelt wurde und seitdem vielfach eingesetzt wird.^[6] Grundidee hinter EPKs ist die Unterteilung von einzelnen Arbeitsschritten in auszuführende Tätigkeiten (Funktionen) und Ereignisse, welche die Ausführung der Folgetätigkeiten auslösen und mehrere Funktionen miteinander verbinden. Eine EPK ist damit ein gerichteter, bipartiter Graph aus Ereignissen und Funktionen. Daneben sind Informationsobjekte Bestandteil des Prozessmodells, auf welche durch Funktionen zurückgegriffen werden kann. Weiterhin finden sich logische Operator-Bausteine zur Ausführung einer Tätigkeit in Abhängigkeit mehrerer, vorausgegangener Funktionen, sowie Bindeglieder, welche neben einer sequentiellen Durchführung auch eine parallele oder alternative Ausführung von Funktionen im Prozessmodell ermöglichen. Erweiterte EPKs (eEPKs) können darüber hinaus weitere zusätzliche Objekte enthalten. Mithilfe der XML-basierten Event-driven Process Chain Markup Language (EPML) wird ein plattformübergreifendes Austauschformat bereitgestellt. Wesentlicher Vorteil von EPKs ist die einfache Handhabung. Kritiker sehen dem gegenüber in EPKs ein wesentliches Problem, dass deren Syntax und Semantik formal nicht ausreichend definiert ist und daher in der Praxis beliebige und vor allem mehrdeutige Strukturen auftreten können. Dies erschwere den Austausch und die Analyse in Workflow-Management-Systemen. So zeigt beispielsweise van der Aalst auf, dass Ereignisgesteuerte Prozessketten als Untermenge von Petri-Netzen aufgefasst und damit in diese überführt werden können und dies eine Reihe von Vorteilen bringt [Aal98]. Darüber hinaus beschäftigt sich Kindler mit dem Problem, nicht-lokale Semantiken für EPKs zu definieren, indem er dazu ein mathematisches Grundgerüst schafft [Kin03].

2.3.2. Flussdiagramme

Ein Flussdiagramm ist eine grafische Darstellungsmöglichkeit für beliebige Arbeitsabläufe. Es fand vor einigen Jahren besondere Anwendung bei der Darstellung von Programmabläufen (Algorithmen), ist prinzipiell aber zur Darstellung beliebiger Prozesse geeignet. Im Mittelpunkt steht eine sequentielle Abarbeitung verschiedener Tätigkeiten, um von einem Startzustand in einen Endzustand zu gelangen. Neben der Möglichkeit, einzelne Operationen sowie Ein- und Ausgabewerte zu definieren ermöglicht ein Verzweigungsoperator, Alternativen während der Abarbeitung zu berücksichtigen, die in der Regel binär beantwortbar sind. Weiterhin existiert die Möglichkeit, Sprungstellen in andere Flussdiagramme zu definieren.

Alle gültigen Symbole eines Flussdiagramms sind in der DIN 66001 genormt. In der Gesamtbewertung bieten Flussdiagramme zur Darstellung von Workflows jedoch nicht genügend Möglichkeiten, da parallele Ausführungen als auch die objektorientierte Modellierung nicht ausreichend unterstützt werden, was nicht zuletzt in dem Entwicklungszeitpunkt Ende der Vierziger Jahre begründet ist. Dennoch existieren genügend Werkzeuge zur Erstellung von Flussdiagrammen. Im Mittelpunkt steht dabei die grafische Darstellung des Prozesses. Daraus resultierend haben sich im Gegensatz zu anderen Modellierungsmethoden für Prozesse keine Beschreibungssprachen zum Austausch und zur automatischen Verarbeitung von Flussdiagrammen durchgesetzt.

2.3.3. Petri Netze

Petri-Netze wurden 1968 durch Carl Adam Petri entwickelt und sollen es ermöglichen, beliebige Prozesse formal zu beschreiben. Anstatt sich auf einen sequentiellen Kontrollfluss zu beschränken, erweitern Petri-Netze das klassische Ausführungsmodell dahingehend, dass mit Ihnen nebenläufige Anweisungen in verteilten Systemumgebungen problemlos modelliert werden können. Die aus der klassischen Automatentheorie bekannten Knoten werden dazu um eine Markierung (token) erweitert, welche generiert oder entfernt werden kann. Die von diesen Knoten ausgehenden gerichteten Kanten treffen sich in einem (oder mehreren) Übergangsobjekt(en) (transition), welches erst durchlaufen werden kann, wenn genügend Markierungen vorhanden sind. Übertragen auf das Konzept eines Workflows kann dies dahingehend gedeutet werden, dass erst eine Reihe vorausgehender paralleler Aktivitäten durchgeführt worden sein muss, ehe der Gesamtprozess ab einem bestimmten Punkt weiter fortschreiten kann. Mit diesen Mitteln sind Petri-Netze einfach und ausdrucksstark, aber gleichzeitig formal genug, um damit Geschäftsprozesse in Workflow-Management-Systemen modellieren zu können. Ähnlich wie bei EPKs existieren zum Austausch und zur Analyse von Petri-Netzen eine Reihe von Werkzeugen und Dokumentenformaten. Interessant ist dabei neben Varianten der Graphical XML Schema Definition Language (GXSL) vor allem die (XML-basierte) Petri Net Markup Language (PNML), welche die Modellierung höherer (dann als XML-Netze bezeichneter) Petri-Netze ermöglicht. Daneben existiert als Open-Source Projekt eine Workflow-Beschreibungssprache unter der Bezeichnung Yet Another Workflow Language (YAWL), welche in erster Linie eine bestmögliche Umsetzung gängiger Workflow Patterns verfolgt und dazu auf Petri-Netzen aufsetzt.

[...]

^[1] Skinny Client Control Protocol, ein von Cisco Systems Inc. entwickeltes, proprietäres Protokoll zur Abhaltung von Telefonkonferenzen über VoIP in Echtzeit

^[2] An manchen Stellen wird in HTML dadurch sogar der wohl bedeutendste Schritt gesehen, der erst das Internet in der heutigen Realisation ermöglichte, da die Auszeichnungssprache weltweit akzeptiert wurde [Lac05, p. 1]. Vielfach wurde versucht, weitere Standardsprachen („lingua franca des Internets“) für andere Anwendungsbereiche einzuführen, die jedoch alle mehr oder weniger an unterschiedlichen Auffassungen verschiedener Organisationen und Länder gescheitert sind oder modifiziert werden mussten.

^[3] Breitman, Casanova und Truszkowski bezeichnen in diesem Zusammenhang das heutige Internet als „Syntactic Web“ im Gegensatz zum angestrebten „Semantic Web“ [Bre07, p.5 ]

^[4] vgl. http://wiki.zope.org/zope3/TryingToUnifiyWorkflowConcepts

^[5] vgl. http://www.jboss.com/products/jbpm/stateofworkflow

^[6] So wurden EPKs lange Zeit im SAP R/3-Systemen zur Prozessdokumentation verwendet.