Wissensbasiertes und Prozessorientiertes Innovationsmanagement WPIM

Größe: px
Ab Seite anzeigen:

Download "Wissensbasiertes und Prozessorientiertes Innovationsmanagement WPIM"

Transkript

1 Wissensbasiertes und Prozessorientiertes Innovationsmanagement WPIM Innovationsszenarien, Anforderungen, Modell und Methode, Implementierung und Evaluierung anhand der Innovationsfähigkeit fertigender Unternehmen Dissertation zur Erlangung des akademischen Grades Doktor-Ingenieur (Dr.-Ing.) der Fakultät für Mathematik und Informatik der FernUniversität in Hagen von Tobias Vogel Diplom Wirtschaftsinformatiker aus München Referent: Prof. Dr.-Ing. habil. Matthias L. Hemmje Koreferent: Prof. Dr.-Ing. habil. Joachim Warschat Tag der Einreichung: Tag der mündlichen Prüfung: München 2012

2

3 Zusammenfassung und Abstract Zusammenfassung Wissensbasiertes und Prozessorientiertes Innovationsmanagement (WPIM) zielt auf die Integration von Prozessstrukturen und Wissen ab. Konkret werden bei WPIM Aktivitäten der Innovationsprozesse mit Ressourcen, wie z. B. Expertendaten und Dokumenten, annotiert. Für die innovative Produktentwicklung ergeben sich bei der Durchführung zukünftiger Prozessinstanzen Nutzenpotenziale und Synergieeffekte durch die Wiederverwendung sowie die Instanziierung der annotierten Musterprozesse. Eine Besonderheit beim WPIM stellt das semantische Schema der WPIM-Anwendung dar, das auf dem Resource Description Framework (RDF) basiert. Die hinterlegte Semantik bietet Vorteile, wie z. B. beim Einsatz von semantischen Suchen mit der SPARQL Protocol and RDF Query Language (SPARQL). Um einen Praxisbezug herzustellen und zur Evaluation von WPIM, wird die erhobene Datenkollektion zum Ideation Process bei Philips Consumer Lifestyle Advanced Technology (PCLAT) in der WPIM- Anwendung modelliert und analysiert. Anhand des Szenarios Projektübergabe und der Methode InnoScore [PAS1073] erfolgt der Nachweis zum Nutzen der sozio-technischen WPIM- Anwendung. Abstract Knowledge-based and Process-oriented Innovation Management (WPIM) aims to integrate process structures and specific knowledge. Therefore, activities in the innovation master process are annotated with resources, such as experts and documents. Future developments of innovative products will profit from reusing and instancing these annotated master processes. The advanced semantic schema of the WPIM-Application is based on the Resource Description Framework (RDF) and enables semantic-based searching by using SPARQL Protocol and RDF Query Language (SPARQL). Philips Consumer Lifestyle Advanced Technology (PCLAT) provides their Ideation Process and an appropriate set of processed data. In order to facilitate the scenario of a project handover this data set and the process are modeled within the WPIM-Application. The method InnoScore [PAS1073] is used to explore and evaluate both, the improved user interaction and technical benefit of the WPIM-Application. III

4

5 Danksagung Die vorliegende Arbeit entstand an der Fakultät für Mathematik und Informatik, am Lehrstuhl für Multimedia- und Internetanwendungen der FernUniversität Hagen. Mein erster und herzlicher Dank gilt Professor Dr.-Ing. Matthias Hemmje. Ihm danke ich für seine zahlreichen Anregungen, die unzähligen Telefonate und das Interesse, mit dem er mich und meine Arbeit förderte. Gerade bei der Vorbereitung von Kongressbeiträgen setzte sich Professor Hemmje methodisch für mein Unterfangen ein, ließ seine Expertise gezielt einfließen und investierte viel Geduld in die gemeinsamen Veröffentlichungen. Weiterhin möchte ich Professor Dr.-Ing. Joachim Warschat für die systematische Beratung und die Reflektion der Evaluation danken. Auch möchte ich mich für die freundliche Unterstützung durch das Philips Consumer Lifestyle High Impact Innovation Center in Eindhoven bedanken. Im Rahmen des SHAMAN-Projekts ermöglichte Herr Kees Tuinenbreijer dort eine Befragung zudem gilt mein Dank Frau Emma Forsgren, für die persönliche Durchführung der Interviews und die Datenerhebung. Besonders hilfreich empfand ich während meiner Arbeit das Netzwerk des Lehrgebietes Multimedia und Internetanwendungen der FernUniversität Hagen zu Doktoranden und Experten. Durch diesen gezielten Gedankenaustausch bereitete mir die Zusammenarbeit persönlich wie auch inhaltlich große Freude. Während meiner gesamten Arbeit konnte ich gut vom Erfahrungsschatz und der Expertise in diesem wissenschaftlichen Netzwerk profitieren und hoffe, langfristig darin selbst einen Nutzen stiften zu können. Von ganzem Herzen danke ich meinen Eltern, die mich während meines gesamten Studiums und meiner Dissertation in jeder Hinsicht unterstützten und förderten. Vielen Dank Tobias V

6

7 Inhaltsverzeichnis Zusammenfassung und Abstract... III Danksagung... V Abkürzungsverzeichnis... XIV Tabellenverzeichnis... XX Codeverzeichnis... XXII Definitionsverzeichnis... XXIII 1 Einführung und Motivation Zielsetzung und Gliederung der Arbeit Begriffsklärung Information und Informationssystem Wissen, Aufgabe und Kontext Invention, Innovation, Innovationsmanagement und Innovationsprozess Szenarien und Herausforderungen bei Innovationen Szenario: Projektübergabe und Nachfolger-Regelung Szenario: Radikaler Technologietransfer und Kollaborationen Szenario: Informationsflut bei Innovationen Szenario: Dokumentation per Gesetzeszwang Szenario: Die Rolle von Experten bei Innovationsprozessen Conclusio und zusammengefasste Herausforderungen Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Wissenschaftliche Modelle zum Wissensmanagement Wissenstreppe North TOM-Modell Bullinger et al Bausteine des Wissensmanagements Probst et al SEKI-Modell und Wissensspirale Nonaka/Takeuchi Prozessorientiertes Wissensmanagement Fraunhofer IPK Kommunikationsdiagnose Fraunhofer IMS Münchener Modell Reinmann-Rothmeier/Mandl Prozessmanagement mit Werkzeugen Workflow-Managementsysteme Concurrent Engineering und Simultaneous Engineering Collaboration Engineering Change Management PROMOTE Methode und Werkzeug Hinkelmann et al Expertise Platform, Finebrain AG Innovationsmanagement und organisatorische Instrumente Wissens- und Innovationsmanager WiPro Anreizsysteme Balanced Scorecard Total Productive Maintenance Lessons Learned Produktlebenszyklusmanagement Sprachen und Notationen zur Modellierungen von Prozessen BPM mit BPD BPML BPEL BPEL4WS BPMN VII

8 VIII 2.5 Visuell-gestützte Prozess-Modellierungswerkzeuge Visio, Microsoft ARIS, IDS Scheer ebpmn, Soyatec BPMN/BPMS Designer, Intalio BPEL Designer, Eclipse Business Process Visual Architect, Visual Paradigm Enterprise Architect, Sparx Systems Kriterien und Vorselektion Abgrenzung verwandter und verbundener Arbeiten Entscheidungen in wissensintensiven Geschäftsprozessen Prozessorientiertes Wissensmanagement SHAMAN Daffodil Abgleich und identifizierte Anforderungen an WPIM Anforderung: Prozessbaukasten und standardisierte Musterprozesse Anforderung: Virtuelle Treffen und virtuelle Entwicklungsumgebungen Anforderung: Wissenssicherung und Anreizsysteme Anforderung: Informationsflut und Informationsdetaillierung Anforderung: Wissensstrukturierung und Wissensdimensionierung Anforderung: Dynamische Wissenserweiterung und Fortschreibung Anforderung: Lessons Learned und lernende Prozesse Anforderung: Expertenmanagement Conclusio: Übersicht der abgeleiteten Anforderungen an WPIM WPIM Modellbildung und Methodenentwurf Ausgangspunkt für die konzeptuelle Modellbildung Begriffe zur Modellbildung Prozessbegriff und Prozesskonzepte Ordnungsrahmen der modellbasierten Gestaltung nach [TLDF07] Vorgehen bei der Modellbildung Analyse der Anwendungsszenarien Analyse von Szenario 1: Projektübergabe und Nachfolger-Regelung Analyse von Szenario 2: Radikaler Technologietransfer und Kollaboration Analyse von Szenario 3: Informationsflut bei Innovationen Analyse von Szenario 4: Dokumentation per Gesetzeszwang Analyse von Szenario 5: Die Rolle von Experten bei Innovationsprozessen Identifizierte Konzepte, Doppelungen und Kernkonzepte Innovationsprozess: Deklarative Spezifikation und mathematische Formalisierung Modellierung von Strukturen Ausgangspunkt in die Modellierung: Die identifizierten WPIM-Kernkonzepte Mathematischer und mengentheoretischer Formalismus Prozessstruktur als mengentheoretischer Formalismus Einführung einer (strukturell) zeitlichen Dimension Prozesse, Prozessstrukturen und deren Verfeinerung Phasenmodell zum Innovationsprozess Einführung einer (inhaltlichen) Ressourcen-Dimension Typisierung von Prozessen zu Innovationsprozessen Einführung einer (orthogonalen) Aktivitäten-Ebene Aktivitäten-Modell: Typen, Instanzen und Bibliothek Prozess-Modell: Typen, Instanzen, Schemata und Baukasten Einführung einer (maschinenlesbaren) Semantik-Dimension Exkurs: Formalisierte Abläufe in einem Prozess Exkurs: Regeln, Status zur Steuerung sowie Konnektoren Grafischer Meta-Formalismus Anwendungsszenarien zur Spezifikation von Diensten Szenario 1: Projektübergabe und Nachfolger-Regelung... 95

9 3.3.2 Szenario 2: Radikaler Technologietransfer und Kollaborationen Szenario 3: Informationsflut bei Innovationen Szenario 4: Dokumentation per Gesetzeszwang Szenario 5: Die Rolle von Experten bei Innovationen Zentraler Use Case: semantische Suche Vorgehensmodell und Entwurf der Benutzungsschnittstellen Vorgehensmodell Entwicklung des WPIM-Vorgehensmodells Definitionen zu den Phasen im Vorgehensmodell Entwurf der Benutzungsschnittstellen auf den WPIM-Methoden Wissensstruktur mit vier Wissensebenen Musterprozess und Prozessinstanzen Nutzung gemeinsamer Prozessbausteine und Prozessbibliotheken Entwurf des Expertennetzwerks E2E Erster kognitiver Walk-Through durch die WPIM-Pipeline Prozessidentifikation und Analyse Annotation der Prozessrepräsentation Experten repräsentieren und annotieren Ressourcen insbesondere Dokumente annotieren Prozessbausteine mit Ressourcen anreichern Prozess- und Aktivitätenbibliothek Semantische Annotation und (semantische) Suche Conclusio des kognitiven Walk-Through Operationalisierung der WPIM-Pipeline Basistechnologien der Implementierung URI, URIref und Namespaces extensible Markup Language, XML Document Type Definition, DTD XML-Schema-Definition, XSD DTD vs. XSD XSL, XSLT, XQL und XML-Werkzeuge SAX vs. DOM Semantic-Web-Technologien Grundlagen und Schichtenmodell des Semantic Webs Glossare, Thesauri, Taxonomien, Ontologien Ontologien Meta-Wissen Resource Description Framework, RDF RDF Graph RDF/XML-Syntax RDF-Schema, RDFS Web Ontology Language, OWL Historie und Entwurfsziele von OWL Sprachdialekte von OWL: Light, DL und Full Semantic Web: Risiken und Ausblick Vokabulare und bei WPIM verwendete Basisvokabulare SKOS für maschinenverarbeitbare Thesauri Dublin Core als Basisvokabular für WPIM FOAF als Basisvokabular für WPIM Entwicklung des WPIM-Vokabulars DC, PICS, CC/PP und FOAF ein Ausblick Auswahl der Technologien und Vokabulare Semantische Suche RDF- und OWL-Abfragesprachen RDF Query, RDFQ RDF Query Language, RQL RDQL SPARQL IX

10 Process Query Language, PQL OWL-QL DL Query zur kontextspezifische Suche nach Patenten Schlussfolgern, Inferenz und Reasoner FaCT Pellet Conclusio und Auswahl Technische Realisierung des WPIM-Prototyps Transformation der mathematischen Formalismen in eine DTD Technische Spezifikation und Implementierung von Ressourcen Technische Spezifikation und Implementierung der Dokumente Technische Spezifikation und Implementierung der Expertenontologie Systemarchitektur Paradigmen Client-Server-Architektur Peer-to-Peer (P2P) Schichtenarchitekturen Grundlagen Schichtenarchitektur Schichtenarchitektur Model View Controller (MVC) Modell Controller View Modale Grundtypen Kombinierte Modi Schichtenarchitektur und Mehrschichtenarchitekturen Serviceorientierte Architektur (SOA) Conclusio und Architekturauswahl WPIM-System-Spezifikation Spezifikationssprache Unified Modeling Language (UML) UML, Anwendungsfälle, Sichten und Diagrammtypen UML-Werkzeuge WPIM Use Case modelliert in UML Entwicklung des WPIM-Systemmodells Aufbau des WPIM-Systems WPIM Modell konzeptuelle Infrastruktur Deklaratives Datenmodell Technisches Datenmodell WPIM-Controller konzeptuelle Anwendungsmiddleware Core Infrastruktur des WPIM-Prototyps Controller mit Services Controller mit Semantik-Services WPIM Views konzeptuelle Benutzungsschnittstelle View mit Such- und Visualisierungs-Services Entwicklung der technischen WPIM-Systemarchitektur Ausgangspunkt: WPIM als Black-Box Modell WPIM-System und verbundene Anwendungen MVC-Module des WPIM-Systems Software-Module und Software-Komponenten zum WPIM-System Verfeinerung und Interaktion des WPIM-Systems Conclusio und Ausblick WPIM-Interaktion auf einer SOA mit Diensten SOA zur Operationalisierung der WPIM-Dienste Basisdienste auf der Infrastruktur Semantik-Dienste auf der Middleware Benutzungsschnittstelle mit Diensten zur Visualisierung Entwicklung von Ontologien für Prozesse und Ressourcen Werkzeuge zur Entwicklung von Ontologien OntoBroker OntoStudio, Ontoprise GmbH X

11 K-Infinity, Intelligent Views GmbH SemanticWorks, Altova GmbH Protégé, Stanford University Weitere Ontologiewerkzeuge Conclusio, Kriterien und Auswahl eines Ontologiewerkzeugs Bestandsaufnahme und Klassifizierung von Ontologien Upper Level, Mid Level und Domain Ontologien DARPA- und DAML-Ontologie-Bibliothek Protégé-Upper-Ontologies-Bibliothek WebOnto, Knowledge Media Institute (KMI) Ontologie-Entwicklung: Konzepte, Spezifikation, Formalisierung Technische Formalisierung der WPIM-Prozessontologie und der Relationen Prozesse mit RDF beschreiben und validieren Prozesse mit OWL beschreiben Ontologie-Entwicklung mit SemanticWorks Ontologie-Entwicklung mit Protégé Serialisierte Prozessontologie in OWL-DL Exkurs: Zugriff und Manipulation von Ontologien auf Datenebene Werkzeuge zur Visualisierung von (semantischen) Strukturen Treebolic Generator mit Browser Werkzeuge zur Visualisierungen von Ontologien SkillMap zur Visualisierung von Expertise und Expertennetzwerken Experten, Netzwerke und bestehende Ontologien Bestehende Experten-Ontologie Professional Learning Ontology ExperOnto, Fraunhofer IITB Soziale- und Experten-Netzwerke sowie deren Anreizsysteme Machbarkeitsstudie: Auslesen von Profildaten aus Facebook Anreizsysteme in Sozialen-Netzwerken zur Wissensteilung Implementierung des semantischen Expertennetzwerks (E2E) Komponenten des E2E-Expertennetzwerks Dienst zum Hochladen von Bildbeschreibungen Dateisystem und Speicherung der Daten Implementierung der WPIM-Pipeline Modellierung des Innovationsprozesses Export und Speicherung des modellierten Prozesses als XML Extraktion der WPIM-Konzepte des Prozesses Aufbau des WPIM-Klassenmodells repräsentiert in RDF Erweiterung des Prozesses um Ressourcen Semantische Beschreibung von Ressourcen Integration semantischer Ressourcen in das Prozessmodell Semantische Repräsentation in RDF und semantische Suche Zusammenfassung zur implementierten WPIM-Pipeline Weiterentwicklung zur sozio-technischen WPIM-Anwendung Benutzer Walk-Through durch die WPIM-Pipeline Begriff und Einordnung von sozio-technischen Werkzeugen Erweiterung der WPIM-Pipeline um sozio-technische Werkzeuge Werkzeug 1: Datenspeicherung Werkzeug 2: Prozessbausteine, Prozess-Muster und Bibliotheken Werkzeug 3: Visualisierung von syntaktischen Suchergebnissen Werkzeug 4: Ergebnisvisualisierung bei Experten- und Prozess-Suche Erweiterung Werkzeug 5: Experten-Status und regelbasierter Statuswechsel Conclusio und Erweiterung der WPIM-Pipeline um OWL-DL Prototypische WPIM-Anwendung mit Baukasten Qualitativ-funktionale Evaluation und Potenzial-Analyse Prozessbaukasten und standardisierte Musterprozesse Testfall A Testfall B Testfall C XI

12 Virtuelle Treffen und virtuelle Entwicklungsumgebungen Testfall D Testfall E Wissenssicherung und Anreizsysteme Testfall F Testfall G Informationsflut und Informationsdetaillierung Testfall H Wissensstrukturierung und Wissensdimensionierung Testfall I Dynamische Wissenserweiterung und Fortschreibung Testfall J Testfall K Lessons Learned und lernende Prozesse Testfall L Testfall M Expertenmanagement Testfall N Teiltestfall N_001: Verfügbarkeit von Kontaktdaten der Experten Teiltestfall N_002: Suche von Ansprechpartnern bei Innovationen Teiltestfall N_003: Auffinden vergleichbarer und identischer Konzepte Testfall O Ergebnisse der qualitativ-funktionalen Tests Evaluation der WPIM-Anwendung Evaluationspartner Unternehmen der Industrie Evaluationspartner: FESTO GmbH & Co. KG, Esslingen Evaluationspartner: BMW Group, München Evaluationspartner: ALTRAN GmbH & Co. KG, Frankfurt Evaluationspartner: SOLIN AG, München Evaluationspartner: Ein Unternehmen der Energiebranche Evaluationspartner: PHILIPS PCLAT, Eindhoven, NL Zusammenfassung der Ergebnisse mit den Evaluationspartnern Wirtschaftlichkeitsanalyse der WPIM-Investition Kostenstrukturen Kosten für Entwicklung, Einführung und Wartung von WPIM Kostenschätzung zur Implementierung der WPIM-Anwendung Lizenzkosten für Technologien, Standards und Werkzeuge Nutzenanalyse Nutzenkategorien Problematik der Nutzenmessung Methoden zur Bewertung der Wirtschaftlichkeit Kosten-Nutzen-Analysen Investitionsrechnung Return-on-Investment Methoden zur monetären Bewertung von Zeiteinsparungen Times Saving Times Salary Arbeitswertmethode Hedonic Wage Model Conclusio Übergeordnete generische Rahmenwerke CMMI, ISO/IEC, SPICE für Unternehmensprozesse OSEK und AUTOSAR bei Kooperationen der Automobilindustrie STEP und ProSTEP ivip Wasserfallmodell V-Modell Einordnung und Kompatibilität von WPIM Bewertungs- und Evaluationsmethoden Grundlagen Leistungsindikatoren und Leistungskennzahlen Basis Likert-Skala XII

13 5.4.4 Innovationsbenchmark Innovationsgrad und Innovationsreifegrad Methode I²MM Integriertes Innovationsmanagement InnoScore Begründung zur Auswahl der Evaluationsmethode Simulation zur Ermittlung des InnoScores mit und ohne WPIM Zeitvorteile, Indikatoren und InnoScore bei WPIM Hypothese, Annahmen und Conclusionen Simulation und Rahmenbedingungen InnoScore ohne WPIM InnoScore mit WPIM Codierung, Auswertung und Ergebnis der Simulation Mögliche Anpassungen des InnoScores an WPIM Konkrete Evaluation der WPIM-Anwendung mit Philips PCLAT Befragung, Datenerhebung und Datenkollektion von PCLAT Ideation Process und Datenkollektion von PCLAT Philips PCLAT Ideation Prozess Philips PCLAT Experten, Funktionen, Rollen in der Organisation Philips PCLAT Ideation Process in der WPIM-Anwendung Philips PCLAT semantische Suche Evaluation von WPIM mit der Datenkollektion von PCLAT Standardisierungen, Referenzen, Vokabulare und Baukasten Szenario: Informationsflut und Datenfragmentierung Szenario: Dokumentation per Gesetzeszwang Szenario: Projektübergabe und Nachfolgeregelung Zentraler Use Case: Semantische Suche Zusammenfassung zu den Ergebnissen der Evaluation Zusammenfassung und Ausblick Abgleich gegen die zentralen Herausforderungen Kritische Würdigung Offene Forschungsfragen und mögliche Weiterentwicklungen Verwertung und konkrete Weiterentwicklungen Appendix Anhang A: SOA, Referenzarchitektur, Registry, Repository Anhang B: Einrichtung der Entwicklungsumgebung Anhang C: E2E Grundlagen der Implementierung Anhang D: Expertenprofile in FOAF und HTML Anhang E: Komplexe und unternehmensübergreifende Suchen Anhang F: Anreizsysteme Anhang G: Logik-Ansatz für die Modellierung mit OWL DL Anhang H: Relationen und Abbildungen Anhang I: Synergien durch WPIM Literaturempfehlung... XXV Lebenslauf Tobias Vogel... XLIX XIII

14 Abkürzungsverzeichnis API Application Programming Interface ARIS Architektur integrierter Informationssysteme ASCII American Standard Code for Information Interchange BAM Business Activity Monitoring BOM Bill of Materials BPD Business Process Diagram BPEL Business Process Execution Language BPL Business Process Language BPM Business Process Management BPMI Business Process Management Initiative BPMN Business Process Model and Notation BPMS Business Process Management Systems BPVA Business Process Visual Architect CAD Computer Aided Design DC Dublin Core DL Description Logic DOM Document Object Model DT Drill Through DTD Document Type Definition E2E Expert to Expert Expertennetzwerk EDV Elektronische Datenverarbeitung F&E Forschung und Entwicklung FOAF Friend-of-a-Friend GUI Graphical User Interface GPO-WM Geschäftsprozessorientiertes Wissensmanagement i. O. In Ordnung IP Innovationsprozess IKT Informations- und Kommunikations-Technologie ILM Information-Lifecycle-Management IM Innovationsmanagement IPEP Innovativer Produktentwicklungsprozess IS Informationssystem IT Information Technology IuK Informations- und Kommunikation IUM Integrierte Unternehmensmodellierung J2EE Java 2 Platform Enterprise Edition K3 Kollaboration, Kommunikation und Kompetenz LL Lessons Learned MbO Management by Objectives MM Münchener Modell Mgt. Management MO 2 GO Methode zur objektorientierten Geschäftsprozessoptimierung MuF Material und Fremdleistungen MVC Model-View-Controller n. i. O. Nicht in Ordnung OKBC Open Knowledge Base Connectivity Protocol OMG Object Management Group OO Objekt-Orientierung OWL Web Ontology Language (nicht WOL) OWL-DL OWL Description Logic XIV

15 PEP Produktentwicklungsprozess PIP Produktinnovationsprozess PLM Product-Lifecycle-Management PO Prozess-Orientierung PROMOTE Processoriented Methods and Tools for Knowledge Management pwm prozessorientiertes Wissensmanagement R2D2 RDF to database too RAP RDF API for PHP RDF Resource Description Framework RDFS Resource Description Framework Schema ROI Return on Investment RSS RDF Simple Syndication SAX Simple API for XML SBPM Semantic Business Process Management SECI Socialisation, Externalization, Combination, Internalization SINA Storage Networking Industry Association SOA Serviceorientierte Architektur sog. Sogenannt STEP STandard for the Exchange of Product model data T3P Trusted-3rd-Party TOM Technik-Organisation-Mensch-Modell TQM Total Quality Management UDDI Universal Description, Discovery and Integration UI User Interface UML Unified Modeling Language up Unterprozess URI Unified Resource Identifier URIref URI-Referenz URL Unified Resource Locator VIKEV Virtual Information and Knowledge Environment Framework W3C World Wide Web Consortium W-BPM Web Business Process Modelling WfM Workflow Management WfMC Workflow Management Coalition wigp Wissensintensiver Geschäftsprozess WIT Wissensintensiver Task WM Wissensmanagement WPIM Wissensbasiertes Prozessorientiertes Innovationsmanagement WYSIWYG What You See Is What You Get XML extensible Markup Language XPDL XML Process Definition Language XSL extensible Stylesheet Language XSLT XSL-Transformation XV

16 Abbildungsverzeichnis Abb. 2.1: Die Wissenstreppe nach North [Nort02, S. 39] Abb. 2.2: TOM-Modell nach Lucko/Trauner [LuTr02 in VoHe06, S. 14] Abb. 2.3: Bausteine des Wissensmanagements von Probst [Prob99, S. 58; VoHe06, S. 15] Abb. 2.4: Die Wissensspirale von Nonaka/Takeuchi [Thie01, S. 18; NoTa95, S. 72] Abb. 2.5: GPO-WM Gestaltungsgrade [Heisig 2002 in Gron06, S. 17] Abb. 2.6: Zuordnung von Best-Practice zu den Geschäftsprozessen [Remu02, S. 60] Abb. 2.7: Beschreibungsmodell zur Methode KODA [Gron06, S. 31] Abb. 2.8: Das Münchener Modell [Wett02, S. 19] Abb. 2.9: Überlappender Innovationsprozess: Simultaneous Engineering [Weih05] Abb. 2.10: Wissensflüsse zwischen wissensintensiven Tätigkeiten [Hink02 in Gron06, S. 7] Abb. 2.11: Finebrain Expertise Plattform [www.finebrain.com] Abb. 2.12: Prozess: Von der Idee zum Prototyp dargestellt im BPEL Designer Abb. 2.13: Bedienelemente und Arbeitsfläche im Werkzeug BPVA Abb. 2.14: Business Domain Model im Werkzeug Enterprise Architect Abb. 2.15: BPMN Prozess technische Kalkulation in [LBMS08] Abb. 2.16: Innovationsprozess mit Informations-Bedürfnissen [LVKH08; LVKH08a] Abb. 2.17: Innovationsprozess mit Information-Retrieval-Ansatz [LVKH08a] Abb. 3.1: Ordnungsrahmen der modellbasierten Gestaltung von SOA [TLDF07] Abb. 3.2: Die vier Wissensebenen der WPIM-Wissensinfrastruktur Abb. 3.3: Wiederverwendung der Aktivität Test [VoHe06c, S. 13] Abb. 3.4: Visuelle Modellierung einer Aktivität als Menge von Aufgaben Abb. 3.5: Visuelle Modellierung von Aktivitäten und Relationen Abb. 3.6: Visuelle Modellierung von parallelen Aktivitäten Abb. 3.7: Visuelle Modellierung einer Sequenz von Aktivitäten Abb. 3.8: Visuelle Modellierung zur Phasenzuordnungen von Aktivitäten Abb. 3.9: Visuell modellierter Prozess Abb. 3.10: Aktivitäten und Relationen der beiden Unterprozesse up_1 und up_ Abb. 3.11: Zerlegung einer komplexen Aktivität A in den Unterprozess up Abb. 3.12: Exemplarische Phasen in Innovationsprozessen [Meix03; VoHe06c] Abb. 3.13: Aktivitäten-Pool mit drei Aktivitäten Abb. 3.14: Relationale Zuordnung einer Aktivitäten zu einem Pool Abb. 3.15: Business Process Modeling Language Abb. 3.16: Frühes Meta-Modell zu Prozessen [VoHe06f, S. 21] mit Kardinalitäten Abb. 3.17: Anwendungsfall: Erfassen, Speichern und Durchsuchen von Profildaten Abb. 3.18: Anwendungsfall: Kollaboration und Datenaustauschformat Abb Anwendungsfall: Strukturierung und Zuordnung von Ressourcen Abb Anwendungsfall: Prozess-Baukasten und gesetzliche Anforderungen Abb Anwendungsfall: Annotation von Ressourcen und Prozessstruktur Abb. 3.22: WPIM Use Case: semantische Suche Abb. 3.23: Konzeptuelle Benutzungsebenen im WPIM-Prototyp [VoHe06c, S. 21] Abb. 3.24: Musterprozess und Prozessinstanzen [VoHe06f] Abb. 3.25: Bausteinbibliothek [VoHe06c] Abb. 3.26: E2E Eingabemaske und Experteninstanz Abb. 4.1: Schichtenmodell des Semantic Webs [vgl. in Bos05] Abb. 4.2: Attribute für Dokumente aus dem Dublin Core aus [VoHe07] Abb. 4.3: FOAF-Formular als Eingabemaske der FOAF-a-Matic Abb. 4.4: Screenshot der WPIM-Homepage mit dem WPIM-Vokabular Abb. 4.5: Eine Übersicht und Vergleich von Abfragesprachen Abb. 4.6: Modellierte und instanziierte Ontologie in Protégé Abb. 4.7: DL-Query-Abfrage und das Ergebnis als Query Result belegt mit Patent_ XVI

17 Abb. 4.8: Semantic Reasoner Abb. 4.9: Architektur und Komponenten beim Reasoner Pellet [Siri05, S. 6] Abb. 4.10: XML Schema WPIM.xsd in XMLSpy von Altova Abb. 4.11: Beschreibung des Elements Ersteller (engl. creator) aus dem [DCES09] Abb. 4.12: Ausschnitt der Implementierung der Klasse:Dokumente in Protégé Abb. 4.13: Ausschnitt der implementierten Klasse:Experten Abb. 4.14: Architekturmuster MVC Abb. 4.15: Use Case Diagramm, erstellt mit Dia, in Anlehnung an [Tabe06, S. 362] Abb. 4.16: Konzeptueller Aufbau des WPIM-Systems Abb. 4.17: Konzeptuelle Repräsentation des WPIM-Datenmodells Abb. 4.18: Digitale Objekte in der Aufgabenteilung von RDF und RDFS [vgl. Zapo02] Abb. 4.19: RDF-Schema mit Vokabular und Klassenhierarchie [vgl. Zapo02] Abb. 4.20: Ausschnitt des WPIM-Datenmodells tabellarisch dargestellt [vgl. Zapo02] Abb. 4.21: Multiple Präsentationssicht im WPIM-System Abb. 4.22: WPIM-System als Black-Box Abb. 4.23: Modell WPIM-System und verbundene Anwendungen Abb. 4.24: Konzeptueller Aufbau des WPIM-Systems Abb. 4.25: UML-Modell zum WPIM-System Abb. 4.26: UML-Darstellung des WPIM-Systems ohne Interaktion Abb. 4.27: WPIM-Programmarchitektur mit Technologien nach [Küsg11] Abb. 4.28: Datenfluss und Interaktion des technischen WPIM-Systems Abb. 4.29: Dienste in der serviceorientierten Architektur bei WPIM Abb. 4.30: Basisdienste bilden die WPIM-Pipeline Abb. 4.31: OntoBroker Architektur aus [StAD99, S. 8] Abb. 4.32: Import Fenster im Knowldge-Builder Abb. 4.33: Sprachen und Sprachlevel bei SemanticWorks [SeWo07, S. 4] Abb. 4.34: SemanticWorks in der Graph-Ansicht Abb. 4.35: Protégé Projekt anlegen mit Suffix.pont und.pins Abb. 4.36: Namespaces für die Ontologie Abb. 4.37: Darstellung der URIref in der XML-Textansicht Abb. 4.38: Beziehung zwischen zwei Klassen mit rdf:subclassof Abb. 4.39: Klassen-Hierarchie in Protégé Abb. 4.40: Projekt-Prozesse WPIM in Protégé Abb. 4.41: OWL-DL Ontologie, serialisiert in der XML-/RDF-/OWL-Notation Abb. 4.42: Mapping zweier Welten: Java und RDF [Völk06] Abb. 4.43: Treebolic Browser: Hierarchischer WPIM-Innovationsprozess in XML Abb. 4.44: Treebolic Browser, Dateisystem in hyperbolischer Darstellung Abb. 4.45: Graphenstruktur des SkillMap Systems [SpMH05, SpMe06] Abb. 4.46: SkillMap mit aktivem sozialen Netzwerk einer Person Abb. 4.47: SkillMap: Experten mit Arbeitsschwerpunkt Wissensmanagement Abb. 4.48: Überblick zur Professional-Learning-Ontologie [ScKu06] Abb. 4.49: WPIM-Applikation integriert bei Facebook.com Abb. 4.50: PHP-Skript Test-App zum auslesen von Facebook-Profilen Abb. 4.51: Experten-Profile und Experten-Übersicht A-Z Abb. 4.52: Exemplarischer Innovationsprozess modelliert im Werkzeug BPVA Abb. 4.53: Hierarischer Ausschnitt aus dem Prozessmodell Abb. 4.54: Prozessmodell exportiert nach XML, dargestellt im Werkzeug XMLSpy Abb. 4.55: Extraktion der Prozesselemente aus dem BPVA XML mittels indatei.php Abb. 4.56: Ergebnis des PHP-Skripts sind extrahierte Konzepte Abb. 4.57: Extraktion der Prozesselemente und Aufbau der Konzept-Hierarchie Abb. 4.58: Hierarisch-geordnete XML-Elemente, dargestellt in XMLSyp XVII

18 Abb. 4.59: Erweiterung um hierarische Beziehungen und Experten-Konzepte Abb. 4.60: DCdot: Dokumente semantisch annotieren mit dem Dublin Core Element Set Abb. 4.61: FOAF-a-Matic [Dodd06]: Semantische Beschreibung von Experten mit FOAF Abb. 4.62: WPIM Web-GUI zur Zuordnung digitaler Ressourcen zu Prozesselementen Abb. 4.63: Verwendung semantischer Relationen aus dem WPIM-Vokabular Abb. 4.64: Komplexe SPARQL-Anfrage in Protégé Abb. 4.65: Web-Interface zum Pellet-Reasoner [http://pellet.owldl.com] Abb. 4.66: WPIM-Pipeline des WPIM-Systems I Abb. 4.67: WPIM-Pipeline des WPIM-Systems II Abb. 4.68: Implementierte Datenmodelle der WPIM-Pipeline Abb. 4.69: Einordnung von Werkzeugen Abb. 4.70: Datenmodell mit Tabelle Experten Abb. 4.71: Zwei Beispiele für Prozess-Muster, visuell modelliert in BPVA Abb Visualisierung zu syntaktischen Suchbegriffen mittels Skript markieren.php Abb. 4.73: Integrierte Experten-Visualisierung mit Tag-Cloud Abb. 4.74: Aktivitätsindex bei XING.de Abb. 4.75: WPIM-Anwendung mit Menü- und Baumansicht Abb. 4.76: WPIM-Anwendung mit Baukasten Abb. 4.77: Aktivität in der Detailansicht im BPVA Abb. 4.78: Ergebnisliste zur SPARQL-Suchanfrage nach Namen von Experten Abb. 4.79: Organisations-Ontologie mit äquivalenten Klassen Abb. 4.80: Vorgegebene Klassen und Instanzen sowie inferierte Instanzen mit owlsight Abb. 5.1: Projekt De-Briefing bei FESTO Abb. 5.2: Innovationsprozess zur Erstellung sicherheitskritischer Software (modifiziert) Abb. 5.3: Dateistruktur zu einem Innovationsprozess Abb. 5.4: DiPP zur Verwaltung und Visualisierung von Geschäftsprozessen Abb. 5.5: Entwicklungsplanung und Entwicklungsprozess der SOLIN AG Abb. 5.6: V-Modell der SOLIN AG, modelliert im Enterprise Architect mit SysML Abb. 5.7: Prozess der Energiebranche modelliert in ARIS Abb. 5.8: Konkrete Implementierung der Domänen-Ontologie im Energiesektor Abb. 5.9: Ergebnis der SPARQL Abfrage in Protégé Abb. 5.10: Innovationsprozess bei Philips PCLAT Abb. 5.11: Kategorisierung nach direktem und indirektem Nutzen [nach Quaa05, S.15] Abb. 5.12: Standard Risiko-Nutzen-Matrix der Risikoanalyse nach [Quaa05] Abb. 5.13: Innovationsprozess als Wasserfallmodell mit Phasen modelliert in BPVA Abb. 5.14: Das V-Modell zur Innovationsdurchführung [V-Modell Dokumentation] Abb. 5.15: Allgemeines V-Modell bei der SW-Entwicklung [Homm06, S. 20] Abb. 5.16: Die neun Gestaltungsfelder entlang des Innovationsprozesses [SSKS07, S. 16] Abb. 5.17: Gestaltungsfelder, Erfolgsfaktoren und Indikatoren [Wars06, S. 33] Abb. 5.18: Auszug aus dem entwickelten Fragebogen zur Datenfragmentierung Abb. 5.19: Philips PCLAT: Grafische Modellierung zum Ideation Prozess [JaMo09] Abb. 5.20: Natürlichsprachliche Beschreibung zum Ideation Prozess [JaMo09, S. 4] Abb. 5.21: Aktivitäten mit Beschreibung in semi-formaler, tabellarischer Darstellung Abb. 5.22: Input/Aktion/Output Betrachtung zu einzelnen Aktivitäten Abb. 5.23: Philips Ideation Process modelliert in BPVA Abb. 5.24: Aktivitäten des Ideation Process als Instanzen der Klasse:Aktivität Abb. 5.25: Überführung der Funktionsbeschreibung bei Philips in xls und digitale Objekte Abb. 5.26: Philips Ideation Process in der WPIM-Anwendung [Küsg11, S. 39] Abb. 5.27: Semantische Suche im Philips Ideation Process [vgl. Küsg11, S. 43] Abb. 7.1: Localhost Omin HTTPd Abb. 7.2: XAMPP Control Panel XVIII

19 Abb. 7.3: Mathematische Logik und Prädikatenlogik Abb. 7.4: Darstellung zur Surjektivität [Woll10] Abb. 7.5: Darstellung zur Injektivität [Woll10] Abb. 7.6: Darstellung zur Bijektivität [Woll10] XIX

20 Tabellenverzeichnis Tab. 2.1: Übersicht, Auswahl und Entscheidung für ein Prozessmodellierungs-Werkzeug Tab. 3.1: Elementare Ausführungsformen zur Parallelität [vgl. BöMS96, S. 5] Tab. 3.2: Elementare Ausführungsformen zur Reihenfolge [vgl. BöMS96, S. 5] Tab. 3.3: Ressourcen und Ressourcen-Hierarchie Tab. 3.4: Ressourcen und Zuordnung zu Aktivitäten Tab. 3.5: Relationen der Aktivitäten-Dimension Tab. 4.1: WPIM-Vokabular: Attribute und Beschreibung von Elementen [Küsg11, S. 23] Tab. 4.2: Beschreibungsrahmen zur Formalisierung von Diensten Tab. 4.3: Dienst Ablage der Muster Datei Tab. 4.4: Dienst XML-Export Tab. 4.5: Dienst Extraktion der Konzepte Tab. 4.6: Dienst Expertenkontakt Tab. 4.7: Dienst Dokumente integrieren Tab. 4.8: Dienst Datenspeicherung Tab. 4.9: Dienst Datenrepräsentation Tab. 4.10: Dienst semantische Prozessrepräsentation Tab. 4.11: Dienst Harmonisierung Tab. 4.12: Dienst Validierung Tab. 4.13: Dienst Ontologie aufbauen Tab. 4.14: Dienst Ontologie instanziieren Tab. 4.15: Dienst semantische Abfragen Tab. 4.16: Dienst Inferenz Tab. 4.17: Dienst Rückführung Prozessmodelle Tab. 4.18: Dienst Visualisierung Tab. 4.19: Auswahl semantischer Werkzeuge Tab. 4.20: Übersicht zu den Anforderungen an WPIM Tab. 4.21: Anforderung WPIM_001: Prozessbaukasten und standardisierte Musterprozesse Tab. 4.22: Testfall A Tab. 4.23: Testfall B Tab. 4.24: Testfall C Tab. 4.25: Anforderung WPIM_002: Virtuelle Treffen u. virtuelle Entwicklungsumgebung Tab. 4.26: Testfall D Tab. 4.27: Testfall E Tab. 4.28: Anforderung WPIM_003: Wissenssicherung und Anreizsysteme Tab. 4.29: Testfall F Tab. 4.30: Testfall G Tab. 4.31: Anforderung WPIM_004: Informationsflut und Informationsdetaillierung Tab. 4.32: Testfall H Tab. 4.33: Anforderung WPIM_005: Wissensstrukturierung und Wissensdimensionierung Tab. 4.34: Testfall I Tab. 4.35: Anforderung WPIM_006: Dynamische Wissenserweiterung und Fortschreibung Tab. 4.36: Testfall J Tab. 4.37: Testfall K Tab. 4.38: Anforderung WPIM_007: Lessons Learned und lernende Prozesse Tab. 4.39: Testfall L Tab. 4.40: Testfall M Tab. 4.41: Anforderung WPIM_008: Expertenmanagement Tab. 4.42: Testfall N Tab. 4.43: Testfall O Tab. 4.44: Zusammenfassung der Testergebnisse XX

21 Tab. 5.1: Prozessbeschreibung des Innovationsprozesses bei Philips PCLAT Tab. 5.2: Arbeitspakete bei der WPIM-Entwicklung Tab. 5.3: Kriterien zur Auswahl: Technologien und Standards zum Datenaustausch Tab. 5.4: Verfügbarkeit und Lizenzkosten für verwendete Erstellungswerkzeuge Tab. 5.5: Lizenzkosten (grob) für das Prozess-Frontend von WPIM Tab. 5.6: Jährliche Kosten der IT-Infrastruktur für einen Client-PC Tab. 5.7: Geschätzte Kosten der IT-Infrastruktur für einen WPIM-Server Tab. 5.8: Kostenschätzung der IT-Infrastruktur für das WPIM-System Tab. 5.9: Investitionsrechnung zur WPIM-Anwendung, orientiert an [Oehl08, S. 18] Tab. 5.10: Mitarbeiterprofile bei Philips PCLAT Tab. 5.11: Exemplarische Tätigkeitsprofil-Matrix bei Philips PCLAT Tab. 5.12: Bewertung und Codierung nach der Likert-Skala Tab. 5.13: Exemplarische Fragen zu KPI nach [PAS1073] Tab. 5.14: Bewertung und Codierung von KPIs XXI

22 Codeverzeichnis Code 4.1: XSD Namensraum Code 4.2: Namespaces Code 4.3: Präfixes bei Namespaces Code 4.4: Beschreibung Testphase in RDF/XML-Notation Code 4.5: Zwei Personen-Klassen werden durch die FOAF-Relation foaf:knows verbunden Code 4.6: Konzepte zu Object Property und Datatype Property Code 4.7: Object und Datatype Property in OWL Code 4.8: WPIM.xml eine mögliche Prozess-Instanz in XML Code 4.9: Die WPIM.dtd Code 4.10: Erweiterte WPIM.dtd Code 4.11: Klassen, Hierarchien und Vererbung bei Dokumenten Code 4.12: Exemplarische Beschreibung eines Buches mit dem Dublin Core Code 4.13: Klassen, Hierarchien und Vererbung bei Dokumenten Code 4.14: Namensräume zur WPIM Prozess-Ontologie Code 4.15: POST-Methode bei PHP-Formularen Code 4.16: Bildbeschreibung in Textformat Code 4.17: Übermittlung von Daten an den Server in das File indatei.php Code 4.18: UpLoadOptionen: Festlegen von FileSize für Dokumente Code 4.19: Überprüfen des UpLoads und Ausgabe der Ergebnisse der Prüfung Code 4.20: Ausschnitt aus dem Skript extraktion.php Code 4.21: Darstellung der XML-Tags Pool und Aufgabe mit Ausprägungen Code 4.22: Klassen-Hierarchie in RDF erstellt mit dem Werkzeug Protégé Code 4.23: SPARQL-Anfrage Code 4.24: Generische Zuordnung auf Klassenebene: Status und Aktivität zu Experten Code 4.25: Konkrete Zuordnung eines Status und einer Aktivität zum Experten AMüller Code 4.26: Zuordnung von Autor und Erstellungsdatum zu einem Patent Code 4.27: Bewertung von Experten, deren Engagement und Reputation Code 4.28: Regelbasierter Ansatz zum Schlussfolgern aus Prämissen Code 4.29: Mehrfachvererbung bei Vertreterregelung istvertreter Code 4.30: SPARQL-Anfrage Code 4.31: Äquivalente (engl. equivalent) Klassen in OWL Code 5.1: SPARQL Abfrage: ist_experte_für?aktivität Code 7.1: Visualisierung von Eingabe-Pflichtfeldern mit JavaScript Code 7.2: POST-Befehl bei PHP Code 7.3: Speicherung von Mitarbeiter-Profilen in Dateien Code 7.4: Codierung von Profil-Daten im HTML-Format Code 7.5: UTF-8 Codierung bei HTML Code 7.6: Integration und Codierung mit dem FOAF-Namespace Code 7.7: Attribute semantisch mit dem FOAF-Vokabular beschreiben Code 7.8: Semantische Relation bei FOAF mit foaf:knows Code 7.9: Semantische Beschreibung eines Experten-Profils mit FOAF und HTML Code 7.10: Suchanfrage in FOAF-Notation XXII

23 Definitionsverzeichnis Definition 1.1: Information... 5 Definition 1.2: Informationssystem... 5 Definition 1.3: Aufgaben-Modellierung... 6 Definition 1.4: Kontext-Modellierung... 7 Definition 1.5: Wissensbasiertes und Prozessorientiertes Innovationsmanagement... 9 Definition 3.1: WPIM-Prozessmodell Definition 3.2: Erweitertes WPIM-Prozessmodell Definition 3.3: WPIM-Methode Definition 3.4: WPIM-Dienst Definition 3.5: WPIM-Werkzeug Definition 3.6: WPIM-Architektur Definition 3.7: WPIM-System Definition 3.8: WPIM-Pipeline Definition 3.9: WPIM-Prototyp Definition 3.10: WPIM-Anwendung Definition 3.11: WPIM-Vorgehensmodell Definition 3.12: Aufgabe Definition 3.13: Aktivität Definition 3.14: Relation Definition 3.15: Parallele Aktivitäten Definition 3.16: Sequenz Definition 3.17: Phase Definition 3.18: Prozess Definition 3.19: Unterprozess Definition 3.20: Komplexe Aktivität Definition 3.21: Elementarprozess und Aufgabe Definition 3.22: Experte Definition 3.23: Dokument Definition 3.24: Verweis Definition 3.25: Systeme Definition 3.26: Organisationseinheiten Definition 3.27: Ressource Definition 3.28: Innovationsprozess Definition 3.29: Aktivitäten-Pool Definition 3.30: Pool-Aktivität Definition 3.31: Pool-Relation Definition 3.32: Aktivitäten-Modell Definition 3.33: Aktivitäten-Instanz Definition 3.34: Merkmal Definition 3.35: Eigenschaft Definition 3.36: Aktivitäten-Kategorie Definition 3.37: Aktivitäten-Typen Definition 3.38: Muster-Aktivität Definition 3.39: Aktivitäten-Bibliothek Definition 3.40: Prozess-Modell Definition 3.41: Prozess-Instanz Definition 3.42: (Inhaltliche) Prozess-Typen Definition 3.43: (Strukturelle) Prozess-Schemata Definition 3.44: Muster-Prozess und Prozess-Pattern Definition 3.45: Prozess-Baukasten XXIII

24 Definition 3.46: Ressourcen-Instanzen Definition 3.47: Analyse und Identifikation des Wissensbedarfs Definition 3.48: Prozessorientierte Wissensakquise Definition 3.49: Erweiterte Wissens- und Expertensuche Definition 3.50: Selektion der Ergebnisse Definition 3.51: Neue Erkenntnisse durch Wissenskombination oder Lessons Learned Definition 3.52: Prozessorientierte Wissensablage Definition 3.53: Erweiterung und semantische Annotation der Wissensbasis Definition 5.1: Nutzen Definition 5.2: Erwartungswert Definition 5.3: Nettonutzen Definition 5.4: Wirtschaftlichkeit Definition 5.5: Nutzenanalyse Definition 5.6: Nutzenwertanalyse Definition 5.7: Kosten-Nutzen-Analyse Definition 5.8: Evaluation Definition 5.9: Hypothese Definition 5.10: Verifikation Definition 5.11: Leistungsindikatoren Definition 5.12: Benchmarking Definition 5.13: Kognitive Befragung Definition 7.1: Surjektiv Definition 7.2: Injektiv Definition 7.3: Bijektiv XXIV

25 Einführung und Motivation 1 Einführung und Motivation Die Ressource Wissen gewinnt bei Innovationen an Bedeutung es existiert eine zunehmende Tendenz hin zur Wissensgesellschaft. Im Zuge der Globalisierung verändern sich die Märkte, kürzere Produktlebenszyklen und der Preisverfall fordern schnellere Entwicklungen und effiziente Produktivität. Kunden verlangen nach Individualisierung und immer ausgereifteren Ideen in neuen Geschäftsfeldern. Die Produkte und Dienstleistungen werden zunehmend intelligenter, die Prozesse wissensintensiver. [vgl. Wegg99, S. 20] Um immer schneller besser zu werden, müssen alle Wissensressourcen im Unternehmen mobilisiert werden [vgl. Nort02, S. 9]. Experten sind sich einig: Wissen ist der Erfolgsfaktor der Zukunft. Mit einer Neuausrichtung auf die Ressource Wissen als Basisfaktor der Organisation sind erhebliche Chancen verbunden [Prob99, S. 82]. Grundsätzlich geht es darum, die Ressource Wissen bewusst zu nutzen, um Wettbewerbsvorteile zu realisieren [vgl. LuTr02, S. 9]. Die vorliegende Arbeit beschreibt demnach den gezielten Einsatz der Ressource Wissen bei Innovationen. Moderne Unternehmen müssen sich der Aufgabe stellen, geeignete Systeme zum Wissensmanagement in der Organisation einzuführen. Manager haben bereits erkannt wie erfolgsentscheidend Wissensmanagement für das Unternehmen ist und dass Mitarbeiter die Träger des Expertenwissens sind. Das Kapital des Unternehmens sind seine Mitarbeiter [KSLK03, S. 183], daher sieht Probst im Weggang von zentralen Mitarbeitern die Gefahr, Wissensverluste zu erleiden [Prob99, S. 41]. Mit jedem erfahrenen Mitarbeiter, der das Unternehmen verlässt, geht Wissen über Kunden und Wissen über technische Details (der Maschinen) unwiederbringlich verloren. [KSLK03, S. 132] Diese Arbeit stellt einen Ansatz vor, wie Unternehmen bestehende Erkenntnisse sichern und Wissen nachhaltig verwalten können. Innerhalb von Organisationen können verstärkt Veränderungen der Mitarbeiterstruktur sowie die zunehmende Projektorientierung beobachtet werden. Der strukturelle Wandel von der Informations- zur Wissensgesellschaft geht auch mit einer tiefgreifenden Veränderung der Arbeitsbeziehungen einher. [Nort02, S. 17] Gerade in Zeiten schwieriger wirtschaftlicher Lage tendiert das Management zu flexiblerem Personalmanagement und setzt auf Fremdfirmen und temporäres Personal [Wegg99, S. 19; Lutz97, S. 130]. Auch Beratungsprojekte gewinnen zunehmend an Bedeutung [vgl. Roth05, S. 4]. Häufig wird ein Aspekt nicht ausreichend beleuchtet: Beratungsprojekte enden per Definition zu einem Stichtag, ebenso wie befristete Anstellungsverhältnisse. Die Experten und ihr Wissen stehen schlagartig dem Unternehmen nicht mehr zur Verfügung. Erfolgreiche Unternehmen mit temporären Mitarbeitern müssen sich vor allem mit dem Sichern von (bestehendem) Wissen beschäftigen, um Wissensverlusten [KSLK03, S. 189] vorzubeugen. Die vorliegende Arbeit beschäftigt sich mit der Sicherung von Wissen bei Projektübergaben, personellen Veränderungen und Nachfolgeregelungen. Bestehende Anreizsysteme in Organisationen müssen um Aspekte der Wissensbewahrung und Wissensorientierung erweitert werden. Kompetenzeinbußen sind nicht auf Einzelfälle beschränkt. Gerade im Zuge von Restrukturierungsmaßnahmen führen Massenentlassungen ohne Rücksicht auf die Wissensbasis des Unternehmens zu katastrophalen Verlusten [vgl. Prob99, S. 42]. Wissensbeeinträchtigend sind auch Downsizing, Outsourcing und Reengineering innerhalb der Organisation [vgl. Nort02, S. 1]. Teilweise werden unter der Überschrift Lean Management Teile der Kernkompetenz nach außen verlagert [Prob99, S. 133]. Wissen ist personengebunden und steckt in den Köpfen der Mitarbeiter [Rumm05, S. 3]. Freigesetzte Mitarbeiter hinterlassen Wissenslücken im Unternehmen oder schließen sich gar der Konkurrenz an [Wegg99, S. 91]. Das Management sollte sich folglich Gedanken machen, wie Wissen nachhaltig an die Organisation geknüpft werden kann, ohne den Mitarbeiter auszubeuten 1

26 Einführung und Motivation [Will04, S. 36]. Den Kern der Überlegungen von [NoTa97, S. 20] bildet die Externalisierung von implizitem Wissen. Mitarbeiter wollen und dürfen [LuTr02, S. 63] derzeit ihr wertvolles Wissen nicht oder nur bedingt, preisgeben, um ihre darauf begründete Machtposition und Stellung in der Organisation nicht zu gefährden [vgl. Prob99, S. 258]. Viele fürchten, und manche zu Recht, dass sie sich selbst überflüssig machen [Will04, S. 35]. Unternehmer und Mitarbeiter fordern nach geeigneten Anreiz-, Vergütungs- und Beurteilungssystemen zur Freigabe von Wissen. Aktuelle Publikationen thematisieren Handlungsbedarf zur Schaffung von Anreizsystemen zur Wissensexternalisierung [LuTr02, S. 62; Nort02, S. 12]. Konkrete wissensorientierte Vorschläge und pragmatische Lösungen zur Schaffung von Anreizsystemen konnten nicht identifiziert werden [Prob99; Nort02; Will04]. Die vielzitierte Unternehmenskultur [Will04, S. 68] und das Schaffen von Vertrauen [Prob99, S. 74 u. S. 383; Nort02, S. 28] helfen an dieser Stelle nicht weiter. Diese Arbeit unterbreitet Vorschläge wie Anreizsysteme um Aspekte des Wissensmanagements erweitert werden können. Durch die verteilte und redundante Ablage von Information entstehen Datenfragmentierungen sowie Informationsfluten. Anreizsysteme könnten Mitarbeiter motivieren Wissen untereinander zu teilen und im Unternehmen verfügbar zu machen [vgl. Prob99, S. 76]. Das externalisierte Wissen wird als Information in Dokumenten und Speichermedien archiviert [vgl. NoTa97]. Ordnungsvorschriften und Kontextabhängigkeiten finden häufig nicht ausreichend Beachtung, Transparenz fehlt [vgl. Prob99, S. 103]. Aus Datenbeständen, Intranet und Informationssystemen entstehen Informationsfluten mit (redundanten) Daten im Unternehmen. Informationsflut bewirkt paradoxerweise einen Wissensmangel [Stei02, S. 14], denn die Selektion des benötigten Wissens aus der Informationsfülle fällt schwer. Weggemann zitiert Führungskräfte: Ich habe alle Informationen, außer denen, die ich brauche [Wegg99, S. 104]. Steiger stellt fest, Information stellt keinen Wert an sich dar, vielmehr gilt es, Information im Aufgabenkontext gezielt verfügbar zu machen und einzusetzen. Folgende Fragestellungen drängen sich auf: Wie lässt sich die Informationsflut beherrschen und wie kann vorhandene Information rationell und nutzbringend eingesetzt werden [Stei02, S. 15]? Wie können Mitarbeiter die bereit sind, ihr Wissen im Unternehmen zu teilen diesen Transfer strukturiert, überschaubar, kontextbezogen, aktuell und erweiterbar vornehmen? Die vorliegende Arbeit beschäftigt sich mit der Fragestellung: Welche Strukturen sind geeignet, zeitnah und aufgabenbezogen die Wissenssicherung am Ort des Wissensbedarfs zu unterstützen? Um Arbeitsabläufe effizienter zu gestalten, folgen innovative Unternehmen der Prozessorientierung. Vor diesem Hintergrund, Produktionsprozesse effizienter zu gestalten, entwickelte Frederick Taylor die Unterteilung des Arbeitsprozesses in einfache sich wiederholende Bestandteile. Diese Aufgabenteilung und Spezialisierungsstrategie wurde als Taylorismus bekannt [Wegg99, S. 12]. Im Zuge des Orientierungs-Hypes 1 entwickelte sich daraus die prozessorientierte Sichtweise. Der Fokus von Produktionsprozessen wird hierbei auf Informationsprozesse erweitert. Willke postuliert: 2 Kein Vorgesetzter verfügt mehr über das für komplexe Geschäftsprozesse oder verzweigte Produktionsprozesse erforderliche Wissen. Vielmehr ist das relevante Wissen dezentral verteilt, auf viele Personen. [Will04, S. 18] Wissen ist also dezentral verteilt und wird dezentral benötigt. Somit bietet sich an, Wissen auch dezentral zu externalisieren, zu dokumentieren, dynamisch fortzuschreiben und zu sichern. Dazu ist es notwendig, Wissen mithilfe von Technologien, Prozessbeschreibungen sowie Netzwerken zu strukturieren und zu bündeln, um von der physischen Anwesenheit des 1 Der Wahn (engl. hype) bezieht sich auf eine Modeerscheinung hinsichtlich der Begrifflichkeit der Orientierung, z. B. der objektorientierten Programmierung oder auch der serviceorientierten Architekturen.

27 Einführung und Motivation ursprünglichen Wissensträgers unabhängig zu werden [vgl. Stei02, S. 57]. Zur Dimensionierung von Wissen werden in dieser Arbeit Prozesse vorgeschlagen. Die Abbildung von Wissen soll sich an den betrieblichen Prozessen orientieren. Wissen der Mitarbeiter soll als externalisierte Information integrativ mit dem Prozess verknüpft werden. So wird Wissen dort dokumentiert, wo es benötigt wird. Das Wissen der Mitarbeiter wird prozessorientiert mit den Prozessphasen, in welchen es benötigt wird, in Beziehung gesetzt und ist zugleich in den Kontext der Aufgabe einzugliedern. Iterative Plausibilisierung und Fortschreibung der kontextbezogenen Wissensinhalte unterstützen bei der prozessorientierten Aufgabenerfüllung. Unternehmerische Wettbewerbsfähigkeit setzt unternehmensübergreifende Wertschöpfungsketten und eine zunehmende Innovationsfähigkeit [vgl. SSKS07] voraus. Mit dem steigenden Wissensanteil in den betrieblichen Geschäftsprozessen wird Wissen zunehmend zur Basis der Wettbewerbsfähigkeit, welche die Innovationsgeschwindigkeit, die Effizienz von Prozessen, die Qualität der Produkte, das Erkennen von Kundenpotenzialen usw. bestimmt [in Thie01, S. 1: Bach/Österle 1999; Nurmi 1998; Davis/Botkin 1994]. In Zeiten kürzer werdender Innovationszyklen hängen Geschwindigkeit und Erfolgsquote bei der Durchführung von Projekten u. a. in der Produktentwicklung in hohem Maß von der Fähigkeit einer Unternehmung ab, in der Vergangenheit gemachte Erfahrungen und erzielte Ergebnisse für zukünftige Entwicklungen nutzen zu können [Thie01]. Die Fähigkeit, Innovationen hervorzubringen, stellt eine Schlüsselfähigkeit von Unternehmen dar, um erfolgreich und zukunftsorientiert zu agieren [KeEr08, S. 1]. Zudem hat die Innovationsfähigkeit Einfluss auf das Wachstum von Unternehmen [Bürg07, S. 2]. Da Prozesse häufig überbetrieblich verlaufen [vgl. Thie01], erstrecken sich auch Wertschöpfungsketten über Unternehmensgrenzen hinweg. Diese müssen zunehmend effizienter ausgestaltet werden, um wettbewerbsfähig zu bleiben. Die vorliegende Arbeit bezieht verbundene Unternehmen sowie Kunden- und Lieferantenbeziehungen in unternehmensübergreifende Wertschöpfungsketten ein [vgl. Thie01] und unterstützt die Modellierung von überbetrieblichen Prozessen. Das prozessorientierte Wissensmanagement bei Innovationsprozessen wird in dieser Arbeit so ausgestaltet, dass Prozesse zwei zentrale Rollen einnehmen Wissensdimension und Wissensobjekt gleichermaßen. Dimension zur Strukturierung von implizitem Wissen und Prozesse als Wissensobjekte, die mit expliziter Information und Wissen angereichert werden. Im Folgenden werden wissensintensive Prozesse betrachtet, welche einen projektähnlichen Charakter besitzen. Dazu finden Entwicklungsprozesse der fertigenden Industrien exemplarisch Verwendung. Diese Prozesse stellen besondere Herausforderungen dar, da sie schwer strukturierbar, besonders innovativ und extrem wissensintensiv sind [vgl. Rupp03, S. 1]. Für diese innovativen Entwicklungsprozesse sollen Standards und wiederverwendbare Prozesssequenzen definiert werden, die mit Wissensinhalten und Ressourcen angereichert werden können. So sollen bei zukünftigen Entwicklungsprojekten Wissensinhalte verfügbar sein und Fehl- und Doppelentwicklungen vermieden werden. Die Ressource Wissen soll so nachhaltig in Entwicklungsprozessen zur Verfügung stehen und Nutzen stiften. Durch die computergestützte Sicherung und Visualisierung der Wissensbestände sowie die Einführung von Standardprozessen in der Entwicklung wird der Grundstein für erfolgreiches Wissensbasiertes und Prozessorientiertes Innovationsmanagement gelegt. Die Betrachtung wird durch Implementierung des Wissensbasierten und Prozessorientierten Innovationsmanagement abgerundet. Der Vielzahl an wissensmanagementbezogenen Publikationen steht derzeit ein auffälliger Mangel an implementationsorientierten Konzepten zur Einführung von Wissensmanagement im Unternehmen gegenüber [Nort98, S. 176 in Thie01, S. 2]. Thiesse ergänzt, dass ebenso neuartige und leistungsfähige Informations- und Kommunikationstechnologien nicht ausreichend ins Kalkül mit einbezogen werden [Thie01, 3

28 Einführung und Motivation S. 2]. Durch die Implementierung einer IT-Infrastruktur kann die organisationale Wissensbasis gestaltet bzw. gezielt verändert werden und zur Erfüllung der Unternehmensziele beitragen [vgl. Nort02, S. 181]. Über die Motivation der Arbeit wird im weiteren Verlauf der Diskurs hin zur identifizierten wissenschaftlichen Lücke aufgebaut. Die Zielsetzung wird festgeschrieben und planerisch die Vorgehensweise bei der Durchführung der Arbeit festgelegt. Nach der Darstellung von Szenarien bei Innovationsprozessen in der fertigenden Industrie, z. B. der Automobilindustrie, werden allgemeingültige Herausforderungen identifiziert sowie Lösungsansätze zur Methodenbildung Wissensbasiertes und Prozessorientiertes Innovationsmanagement (WPIM) aufgezeigt. Nach Klärung der Motivation, Hinführung zur Problemstellung und Festlegung des Ausgangspunktes des Diskurses soll nun zunächst der Aufbau der Arbeit knapp umrissen werden. 1.1 Zielsetzung und Gliederung der Arbeit Es soll eine prozessorientierte Methode entwickelt und implementiert werden, mit der sich Innovationsprozesse abbilden und mit Wissen anreichern lassen. Gewonnene Erkenntnisse (engl. Lessons Learned) und Wissen können so vom Mitarbeiter entkoppelt werden und stehen dem Unternehmen im Prozesskontext der Innovation zur Verfügung. Gefordert wird die explizite Integration der Wissensperspektive in das Prozessmodell. Eine derartige Arbeit und eine zugehörige Implementierung liegen bisher nicht in der wissenschaftlichen Literatur vor. Diese Arbeit zum WPIM hat den Anspruch diese bestehende Lücke zu schließen. Das erste Kapitel ist der Problemstellung und Zielsetzung gewidmet es werden die zentralen Begriffe wie Wissen, Prozesse und Innovationen abgegrenzt. Die WPIM-Definition wird bestimmt und typische Szenarien bei Innovationen ausgeführt. Im zweiten Kapitel werden entlang des Standes der Wissenschaft und der Technik systematisch Modelle, Methoden und Anwendungen analysiert. Im Anschluss werden bestehenden wissenschaftlichen Herausforderungen dargelegt und konkrete Anforderungen an WPIM abgegrenzt. Kapitel drei zeigt den konzeptuellen Methodenentwurf sowie die Spezifikation und Formalisierung zum mathematischen WPIM-Modell. Anhand der Anwendungsszenarien werden das WPIM- Vorgehensmodell und die Benutzungsschnittstellen der WPIM-Pipeline entworfen. Im vierten Kapitel, werden die semantischen Technologien eingeführt, das WPIM-System spezifiziert sowie die WPIM-Pipeline implementiert. Die WPIM-Pipeline [vgl. Kap. 4.11] ist die zentrale softwaretechnische Operationalisierung dieser Arbeit. Ein kognitiver Walk-Through durch die WPIM-Pipeline zeigt ihren Einsatz und die Potenziale der WPIM-Anwendung auf. Das fünfte Kapitel evaluiert WPIM hinsichtlich Wirtschaftlichkeit und, mittels der Methode InnoScore, auf Innovationsfähigkeit. Mit der bei Philips PCLAT erhobenen Datenkollektion wird die WPIM- Anwendung auf Nutzen und Mehrwerte evaluiert. Kapitel sechs fasst die Ergebnisse von WPIM zusammen und schlägt konkrete Weiterentwicklungen vor. Um den gezielten Einstieg in die vorliegende Arbeit und WPIM zu erleichtern, werden die benötigten Begriffe eingeführt und erläutert. Insbesondere wird auf Information, Informationssysteme, Wissen sowie Innovationen und das Innovationsmanagement eingegangen. 1.2 Begriffsklärung Um eine wissenschaftliche Diskussionsgrundlage zu schaffen, werden nachstehend Begriffe eingeführt, die in Verbindung mit dieser Arbeit stehen. Zu besonders relevanten Begriffen, die für die weitere Modellbildung relevant sind, werden darüber hinaus Definitionen getroffen. Besonders wird auf die Definition Wissensbasiertes und Prozessorientiertes Innovationsmanagement (WPIM) eingegangen und die Herleitung erläutert. 4

29 Einführung und Motivation Information und Informationssystem Den pragmatischen Informationsbegriff leitet Kuhlen im Vergleich zu dem meisten anderen wissenschaftlichen Arbeiten nicht von kontextuierten Daten, sondern von Wissen her und fordert: Wissen muss in irgendeiner Weise dargestellt werden, da es noch keinen direkten Gehirntransfer gibt. [Kuhl04] In Publikationen zum Wissenstransfer und Wissensaustausch zwischen Personen wird dies als Externalisierung von Wissen, die über ein Medium wie Luft z. B. für Sprache oder multimedial bis rechnergestützt, erfolgen kann [vgl. NoTa97], aufgeführt. Die technische Repräsentation des Wissens nimmt in dieser Arbeit eine entscheidende Rolle ein. Kuhlen formuliert allgemein, durch die Darstellung des Wissens in einem Zeichensystem, das in syntaktischer Hinsicht z. B. in Form einer Grammatik und eines Wortschatzes, formal beschrieben werden kann, verwandeln sich Wissensstrukturen wieder in Daten, die in der realen Welt wahr- und aufgenommen werden können und zwar, für den vorliegenden Zusammengang entscheidend, über Information [Kuhl04]. Kuhlen, Seeger und Strauch definieren Information [EnFo06a]: Definition 1.1: Information Information ist ein referentieller, pragmatischer Begriff, der sich auf zugrundeliegendes Wissen bezieht und seine Relevanz erst durch eine aktuelle Entscheidung bzw. einen aktuellen Handlungskontext gewinnt. Information referenziert demnach auf das Wissen, das, um handeln zu können, in einem aktuellen Kontext benötigt wird. [Kuhl04] Der Informationsbegriff begründet seinen Ausgang im Wissensbegriff. Information gibt es nicht als Objekt für sich 2, sondern kann nur in einer Repräsentations-/Kodierform von Wissen aufgenommen werden. Wissen selbst ist eine interne, kognitive Struktur. Information ist ein referenzielles Konzept. Information referenziert nicht nur auf repräsentiertes Wissen, sondern entfaltet diese Bedeutung nur mit Referenz auf die aktuelle Benutzungssituation. Information bedeutet etwas, aber und das macht das pragmatische Grundverständnis aus sie existiert nicht losgelöst von ihrer Nutzung. [Kuhl04; EnFo06]. Von Information sollte man nur im aktuellen Kontext ihrer Verwendung sprechen, unter Berücksichtigung der verschiedenen Rahmenbedingungen ihrer Benutzung. Dieses pragmatische Verständnis von Information als aktiv gewordenes Wissen, wird zuweilen ausgedrückt in der Formel Information ist Wissen in Aktion [EnFo06a]. Dazu soll in dieser Arbeit die Aktion in einen Kontext sowie in Prozesse und Aufgaben überführt werden, um das informationalisierte Wissen prozessorientiert abbilden zu können. Definition 1.2: Informationssystem In der Praxis gibt es gewisse terminologische Unstimmigkeiten, da Datensammlungen in der Regel als Informationssysteme bezeichnet werden, obwohl sie an sich keine Information enthalten [vgl. Kuhl04]. Vielmehr sollten Systeme danach benannt werden, was darin enthalten ist bzw. welches Potential extrahiert werden kann. Daten sind und damit rechtfertigt sich die Verwendung von Informationssystem virtuelle Information, Daten haben das Potential zur Information zu werden. Zu Information werden Daten, wenn sie in einem bestimmten Kontext und/oder zu einem bestimmten Zweck wahrgenommen oder gezielt aus Daten/Informationssystemen abgerufen werden. [Kuhl04] 2 Information ist nicht zählbar, daher gibt es keine Mehrzahl von Information. 5

30 Einführung und Motivation Somit geht die Definition von Information und Informationssystem eng verzahnt einher. Acht weitere (technische) Definitionen zum Informationssystem stellen Festl und Sinz vor [FeSi98, S. 8]. Zudem sei an dieser Stelle auf die dynamische Definition bzw. das erweiterbare Online Glossar von Kuhlen im EnForum 3 [EnFo06] verwiesen Wissen, Aufgabe und Kontext Kuhlen arbeitet die pragmatische Dimension von Information heraus und definiert Information als Wissen in Aktion und Wissen im Kontext [vgl. Kuhl04], aufbauend auf der allgemein akzeptierten, hierarchischen Unterscheidung von Daten, Information und Wissen wie in der Wissenstreppe nach North [Nort02, S. 39]. Weiterführend grenzt Kuhlen den Wissensbegriff aus einer human orientierten Sichtweise ab: Gespeicherte Daten sollten nicht als Information angesprochen werden, denn so wird dem Informationsbegriff jede semantische, kontextuelle und pragmatische Konnotation entzogen. Dann fällt es nicht schwer, den Gegensatz zwischen Information als Computerkonzept und Wissen als genuin menschlichem Privileg aufrecht zu erhalten [Kuhl04]. Das Zitat nach Kuhlen Information ist Wissen in Aktion hat zur Konsequenz, dass die Aktion zu repräsentieren ist, damit aus Wissen Information entstehen kann. Die Aktion soll beim Wissensbasierten und Prozessorientierten Innovationsmanagement in den Kontext sowie den Prozess mit seinen Aufgaben überführt werden. Geeignete Modelle aus dem Aufgaben- und der Kontext-Modellierung der Informatik sind heranzuziehen. Der Begriffsvorschlag zu Wissen von Kuhlen, Seeger und Strauch [EnFo06] ist zweigeteilt. Aufbauend auf individuellem Wissen wird erweiternd auch Wissen in Unternehmen betrachtet: Wissen nimmt im Kontext von Individuen und insbesondere bei Experten eine zentrale Rolle ein. Wissen wird als Phänomen kognitiver Systeme aufgefasst, das als Gesamtheit der Kenntnisse, Erfahrungen, Fähigkeiten, Fertigkeiten und Wertvorstellungen verstanden wird. Damit stellt es einerseits den Strukturrahmen für die Aufnahme, Bewertung und Eingliederung neuer Erfahrungen und Information, andererseits ist es handlungsleitend für Individuen (bei WPIM als Experten bezeichnet) [EnFo06]. Auch im Kontext von Unternehmen hat Wissen einen hohen Stellenwert. Wissen kann darüber hinaus als emergentes Phänomen 4 in kollektiven Systemen (beispielweise in Organisationssystemen) auftreten. In Unternehmen wird Wissen vielfach in Form von Information in Dokumenten und Informationssystemen gespeichert, welche damit eine wichtige Unterstützungsfunktion für das Wissensmanagement bieten. Auf der organisationalen Ebene fließt Wissen in Routinen, Prozesse oder Normen ein [EnFo06c]. Definition 1.3: Aufgaben-Modellierung Basierend auf der Aufgabenteilung ist bei der Aufgaben-Modellierung (engl. Task Modelling) die Basisaufgabe darin zu sehen, alle betrieblichen Aufgaben (engl. Tasks) abzubilden und in logischer, chronologischer Abfolge darzustellen. Hierbei unterstützen Prozessmodellierungs- und den Arbeitsablauf unterstützende Werkzeuge (engl. workflow tools). Eine entscheidende Herausforderung ist darin zu sehen, die Aufgaben den 3 Das EnForum (enzyklopädisches Forum der Informationswissenschaften) [Grie04, S. 22] ist ein virtuelles kollaboratives Wörterbuch mit enzyklopädischen Eigenschaften auf dem weiteren Gebiet der Informationswissenschaft (Informationswissenschaft, Dokumentation, Archiv, Bibliothek, angrenzende Gebiete wie Informatik, Wirtschaftsinformatik, Kommunikationswissenschaft etc.) [EnFo06]. 4 Emergenz Theorie: Emergente Eigenschaften eines Systems lassen sich nicht auf die Eigenschaften der isolierten Elemente des Systems zurückführen. Auch als Übersummativität und Fulguration bezeichnet. 6

31 Einführung und Motivation Aufgabenträgern zuzuordnen. Hierbei muss unterschieden werden zwischen nicht-, teil- und vollautomatisierten Aufgaben. Diese Zuordnung der Aufgaben zu den Aufgabenträgern erhöht die Komplexität der Aufgabenmodellierung erheblich. [vgl. FeSi98, S. 8] Definition 1.4: Kontext-Modellierung Als Kontext wird in dieser Arbeit ein Wissensfeld (Wissensdomäne) verstanden, indem durch Abstraktion bestehender Information neue Erkenntnisse, Verbesserungen und Innovationen in einem Produktentstehungsprozess (PEP) umgesetzt werden können. Der Kontext ist nicht exklusiv auf ein Unternehmen begrenzt, sondern kann gezielt für unternehmensübergreifende Innovationen auf mehrere Organisationen und deren Umwelten erweitert werden. Bestehendes Wissen (individuelles Wissen und organisationales Wissen) kann somit in verschiedenen Kontexten gültig sein, bzw. zeitlich gesehen in neue Kontexte integriert werden und diese erweitern. [vgl. FeSi98, S. 8] Abschließend bleibt festzustellen, dass der Unterschied zwischen Information und Wissen darin besteht, dass ein Lernvorgang im Menschen stattgefunden hat. Diese Arbeit möchte Wege aufzeigen, wie Information, Wissen und Ressourcen gezielt bereitgestellt werden können, um Innovationen im technischen Umfeld in fertigenden Industrien zu beflügeln Invention, Innovation, Innovationsmanagement und Innovationsprozess Eine Invention ist eine Erfindung im klassischen Sinn und insofern in dieser Arbeit eine Neuerung aus dem technischen Umfeld. Der grundlegende Unterschied, der die Erfindung (engl. Invention) von der Innovation unterscheidet ist der, dass bei der Innovation das innovierte Produkt einen marktreifen Zustand erreicht hat und zudem erfolgreich am Markt eingeführt wurde [vgl. GrPa04; Meix04]. Auf radikale und inkrementelle Innovationen wird folgend eingegangen. Der Innovationsprozess umfasst die Entwicklung neuer (bzw. die Verbesserung existierender) Produkte, Dienstleistungen und/oder Prozesse sowie ihre Einführung auf den Markt. Dabei werden sowohl innerbetriebliche Vorgänge als auch Außenbeziehungen des Unternehmens integriert. [vgl. Haus97, S. 22] [VöSS07, S. 14] unterscheiden beim Innovationsmanagement zwischen Produkt- und Prozessinnovationen. Unter Innovationsmanagement fasst diese Arbeit alle wissensbasierten und prozessorientierten Maßnahmen zusammen, die geforderte technische Lösungen z. B. bis zu einem Einsatztermin (engl. start of production, SOP) eines Fahrzeugs in einen marktreifen bzw. serienreifen Stand der Technik überführen. Im Weiteren folgt die Herleitung der WPIM Definition. Die Begriffsdefinition Wissensbasiertes und Prozessorientiertes Innovationsmanagement lässt sich nicht ohne weiteres aus bestehenden Definitionen zusammentragen bzw. ableiten. Auf eine simple Auflistung weiterer verwandter Definitionen wird daher an dieser Stelle verzichtet. Vielmehr soll die Definition im weiteren Verlauf aus den beiden zentralen Perspektiven der Wissensperspektive und der Prozessperspektive entwickelt werden. Die daraus entstehende Definition Wissensbasiertes und Prozessorientiertes Innovationsmanagement soll möglichst alle aktuellen und relevanten Gestaltungsaspekte beinhalten und somit zur Grundlage für den vorgestellten Ansatz werden. Für zukünftige, ergänzende Überlegungen zeichnen sich diesbezüglich durchaus noch Gestaltungsfreiräume ab, sodass die Definition aus wissenschaftlicher Sicht keinesfalls als abgeschlossen betrachtet werden darf. Herleitung und Definition WPIM wurden der Fachwelt in 7

32 Einführung und Motivation Veröffentlichungen [VoHe06a, S. 172; VoHe06b, S. 289] sowie auf der Konferenz KnowTech 2006 vorgestellt [VoHe06c]. Diese daraus resultierenden fachlichen Diskussionen mit Experten konnten die Definitionen um wertvolle Anregungen positiv ergänzen. Die Begriffsdefinition WPIM wird zunächst aus der Wissensperspektive abgeleitet. Nähert man sich dem Konzept des Wissensbasierten und Prozessorientierten Innovationsmanagement aus dem Forschungsgebiet der Wissensdomänen und des Wissensmanagements, dann liegt folgende Feststellung nah: Ein Großteil des Wissens in Innovationsprozessen tragen die Experten in sich. Verlassen Experten ein Unternehmen, so geht wertvolles Innovationswissen ersatzlos und ohne Dokumentation verloren. Weggemann empfiehlt, wissenssichernde Maßnahmen zu etablieren [vgl. Wegg99]. Konkurrenzfähige Unternehmen mit innovativen Produkten nehmen diese Herausforderung an und fordern nach geeigneten Instrumenten zur Wissenssicherung [vgl. Meix03]. Dabei wurde bereits ersichtlich: Bestehendes Wissen ist schwer strukturierbar. Eine Abbildung oder Modellierung des Prozesswissens Wissen zu Prozessen und Wissen über Prozesse mit herkömmlichen Abbildungsvorschriften und Abbildungsstrukturen ist ungeeignet [Jabl01]. Such- und Gliederungsoperatoren sind nicht umgesetzt oder nicht verfügbar. Hierin liegt die erste zentrale Herausforderung: Zur Unterstützung von Innovationsprozessen muss zunächst eine geeignete Struktur zur Wissensrepräsentation des Innovationsprozesses selbst sowie aller benötigter Ressourcen gefunden werden. [VoHe06b, S. 288] Die Begriffsdefinition WPIM wird weiter aus der Prozessperspektive abgeleitet. Dieser Ansatzpunkt zum Wissensbasierten und Prozessorientierten Innovationsmanagement basiert auf der Erweiterung des Status-Quo der Prozessplanung und der Prozessverwaltung. Eine weitverbreitete Technik, um Abläufe in Unternehmen zu erklären, ist die Prozessmodellierung [Remu02]. Betrachtet man ein Prozessmodell, so kann man leicht den Ablauf und die Prozessphasen nachvollziehen. Bestehende Prozessmodelle sind zwar zur Strukturierung von Abläufen gut geeignet, möchte man aber die Prozessaktivitäten selbst ausführen, so sind im Prozessmodell weder zielführende Dokumente noch Informations- oder Wissensressourcen hinterlegt. Willke erklärt, Vorgesetzte verfügen nicht mehr über das vollständige, für komplexe Geschäftsprozesse oder verzweigte Produktionsprozesse, erforderliche Wissen. Vielmehr ist das relevante Wissen dezentral verteilt, auf viele Personen [Will04, S. 18] und folglich auch auf deren informationelle Ressourcen sowie auf deren implizites Wissen und deren Fähigkeiten. Im Bedarfsfall sind parallel zum Prozessmodell Handbücher und Dokumente mühsam einzusehen, Organigramme sind zu analysieren, um z. B. Prozessspezialisten oder Experten für konkrete, fachliche Fragestellungen identifizieren zu können. Dazu ist es notwendig, Wissen mithilfe von Technologien, Prozessbeschreibungen und Netzwerken auf geeignete Art und Weise zu explifizieren, zu strukturieren und zu bündeln, um stärker unabhängig von der physischen Verfügbarkeit der menschlichen Wissensträger zu werden. [vgl. Stei02, S. 57] Die zweite zentrale Herausforderung ist darin zu sehen, implizites Wissen von Mitarbeitern auch in expliziter Form verfügbar zu machen und Wissen prozessorientiert an Innovationsprozesse zu knüpfen bzw. das Wissen in den Innovationsprozess zu integrieren. [VoHe06b, S. 288] Im Weiteren folgt die hergeleitete Definition zum facettenreichen Begriff WPIM Wissensbasiertes und Prozessorientiertes Innovationsmanagement. Diese Definition wird für Unternehmen mit komplexen Innovationsprozessen, wie z. B. Hersteller (engl. original equipment manufacturer, OEM) und Zulieferer in der Automobilindustrie, getroffen. Ziel der Definition ist es, nicht Worthülsen zu beschreiben, sondern vielmehr die Aktionen [vgl. Kuhl04] und die Vorgänge in Unternehmen, die sich hinter den Begriffen verbergen, zum Ausdruck zu bringen: 8

33 Einführung und Motivation Definition 1.5: Wissensbasiertes und Prozessorientiertes Innovationsmanagement WPIM fördert die Integration, die Strukturierung und das Auffinden von relevantem Wissen, von Ressourcen und Experten in und für Innovationsprozesse, deren Kontext, innerhalb und zwischen Unternehmen. Da Innovationen aus Wissen und Erkenntnissen hervorgehen, also wissensintensiv sind, wird mit wissensbasiert beschrieben, dass Wissen, Erkenntnisse und Ressourcen die Basis für Innovationen und Produktentwicklungen darstellen. Unter prozessorientiert wird verstanden, dass Unternehmen in Innovationsprozesse, Teilprozesse und Prozessbausteine unterteilt und als solche dargestellt werden können. Innovationsprozesse (bzw. im weiteren Sinn auch Abläufe, Verfahren und engl. workflows) werden dabei zur Dimensionierung des vorhandenen, aktuellen und zukünftigen Wissens herangezogen. Als Wissen wird entwicklungsrelevante Information, Daten, Lessons Learned, Patente, implizites und explizites Wissen der Mitarbeiter sowie auf Wissensmärkten verfügbares Know-how und Expertise verstanden. Wissensbasiertes und Prozessorientiertes Innovationsmanagement zielt darauf ab, die vielfältigen Entwicklungsaufgaben, Innovationsprozesse und Kooperationen von Unternehmen, z. B. der Automobilindustrie, mit handlungs- und entscheidungsrelevantem Wissen und Ressourcen innovationsfördernd zu unterstützen. Exemplarisch wird im nun weiteren Verlauf der Arbeit anhand von Anwendungsszenarien in Innovationsprozessen aufgezeigt, dass in der betrieblichen Praxis, z. B. in der Automobilindustrie, Handlungsbedarf besteht, Innovationsprozesse mit Wissen zu unterstützen. Nach der Einführung der Begriffe Szenario, Herausforderung und Lösungsansatz soll deren Zusammenhang erläutert werden. 1.3 Szenarien und Herausforderungen bei Innovationen Szenarien (auch Anwendungsszenarien) beruhen auf der Analyse zeitlicher und inhaltlicher Rahmenbedingungen. Anwendungsszenarien sind Ergebnisse der Szenariotechnik 5 und beruhen in dieser Arbeit auf typischen Entwicklungen bei Innovationen und in Innovationsprozessen in der Automobilindustrie. Innerhalb der im Folgenden vorgestellten Szenarien können unter Berücksichtigung von Vorgaben und Rahmenbedingungen Herausforderungen abgeleitet werden. Herausforderungen sind dabei anspruchsvolle Aufgaben oder Arbeiten, deren Lösung (noch) nicht bekannt ist oder als nicht etabliert angesehen wird. Sofern Herausforderungen bekannt sind, kann versucht werden, Lösungen oder Lösungsansätze für eine Herausforderung zu suchen. Lösungsansätze zielen darauf ab, Lösungen für bekannte Herausforderungen in einem Szenario anzubieten. In den folgenden Szenarien werden Herausforderungen identifiziert und [in Kap bis Kap ] erste Lösungsansätze angeboten Szenario: Projektübergabe und Nachfolger-Regelung Innovationen für Fahrzeuge dauern häufig mehrere Jahre bis zur Serienreife. Somit ist es nicht unüblich, dass ein Innovationsprojekt an einen neuen Projektleiter bzw. (Teil-) Innovationsprozesse an zeitliche Nachfolger übergeben werden. Um den Übergabevorgang besonders reibungslos und vollständig zu gestalten, werden in der Automobilindustrie häufig zwei Maßnahmen ergriffen: Innovationsprozesse werden visualisiert und zudem ausführliche Dokumentationen, z. B. Verfahrensanweisungen und Handbücher, erstellt. Gerade die Prozessvisualisierung ermöglicht Nachfolgern, einen Überblick über die Weitläufigkeit, Art und 5 Die Szenariotechnik ist eine Planungsmethode, die auf der Analyse möglicher (betriebswirtschaftlicher) Entwicklungen in der Zukunft beruht. Dazu werden etwa Extreme wie das Best-Case-Szenario oder das Worst- Case-Szenario betrachtet. Häufig werden auch Trendszenarien untersucht. Dies sind besonders relevante (z. B. wahrscheinliche) oder typische Szenarien. 9

34 Einführung und Motivation Umfang der Aufgabe sowie Schnittstellen zu anderen Abteilungen und Unternehmen zu gewinnen. Leider werden in der betrieblichen Praxis, oft aus Zeitmangel, Prozessmodellierung und -dokumentationen vernachlässigt, bzw. nicht ausreichend gepflegt. Um Wissen optimal bereitzustellen, müssen Verfahrensanweisungen entlang des Innovationsprozesses verfügbar gemacht werden. Eine Dokumentation, die dem Nachfolger nicht zur Verfügung steht, stiftet wenig Nutzen. Der Ablageort des Prozessmodells im Dateisystem muss auch die begleitende Dokumentation aufnehmen bzw. bereitstellen. Durch die Einbindung der Prozessdokumentation in den Innovationsprozess können sich Nachfolger bei Projektübergaben schnell und gezielt einarbeiten. Herausforderung: Projektübergabe und Nachfolger-Regelung Die Methoden zur Implementierung von WPIM müssen die Prozessmodellierung und Visualisierung von Innovationsprozessen unterstützen. Dazu soll eine Benutzungsoberfläche entstehen, welche es ermöglicht, Innovationsprozesse in Aktivitäten und Relationen zu gliedern, um so Bezüge, Abhängigkeiten, Schnittstellen, Verzweigungen und Zusammenführungen darzustellen. Darüber hinaus muss für jede Prozessphase, also prozessorientiert, eine Wissensstruktur geschaffen werden, welche es ermöglicht, Daten, Information und Wissen im Kontext des Innovationsprozesses abzulegen, erneut zu ändern, darauf zuzugreifen und zu nutzen. Einen weiteren Anspruch sieht der Ansatz zur Unterstützung von WPIM darin, Wissen am Ort der Entstehung und zugleich am Ort des Bedarfs zu sichern und Wissen geeignet zu strukturieren sowie zu dimensionieren. So kann Wissen systematisch gesucht und gefunden werden. Im Folgenden werden Innovationsprozesse als Spezialisierung eines betrieblichen Prozesses betrachtet. Vertreter und Nachfolger können sich durch die Navigation im Prozessmodell einen Überblick über den zeitlichen und organisatorischen Ablauf des Innovationsprojekts verschaffen und erhalten durch das im Prozessmodell formalisierte Wissen aufgabenbezogene Unterstützung bei der Innovationsdurchführung. Wichtig ist auch, dass sich das Prozessmodell durch die Nachfolger verändern und verbessern lassen muss, also nicht starr sein darf, um die Akzeptanz und Anpassungsfähigkeit zu gewährleisten Szenario: Radikaler Technologietransfer und Kollaborationen Bei Innovationsprozessen muss zunächst unterschieden werden, ob es sich um radikale Innovationen oder inkrementelle Innovationen handelt [vgl. Meix03, S. 124], bei [PaNH04; PaNH04a] auch als evolutionär und revolutionär klassifiziert. Technologiegetriebene Innovationen sollen diese Unterscheidung verdeutlichen. Als inkrementelle Entwicklung (Anpassungsentwicklung [vgl. GrPa04] oder repetive Entwicklung [Thie01]) in der Automobilindustrie kann die Variantenbildung eines Bauteils oder die Parametrisierung von Software verstanden werden. Radikale Innovationen hingegen stellen neuartige und bisher nicht verfügbare Entwicklungen dar. Die Luft- und Raumfahrt nimmt technologisch eine Vorreiterrolle ein. Ihr entstammen u. a. die radikalen Entwicklungen der X-by-wire 6 Technologien, also einem radikalen Technologiebruch von mechanischen zu elektronischen Komponenten. Für den Automotivesektor wurden daraus folgende radikalen Entwicklungen abgeleitet: Drive-by-wire, steer-by-wire und zukünftig auch shift- und break-by-wire. Weitere radikale Innovationen verkörpern das adaptive Kurvenlicht bei der BMW AG oder die Nachtsicht-Kamera 7 (engl. Night-Vision), ein Kooperationsprojekt der Robert Bosch GmbH und der DaimlerChrysler AG (heute Daimler AG). Auch zwischen den Fahrzeugherstellern existieren Kooperationen. Im Bereich der Hybriden-Antriebe kooperieren z. B. die OEMs General Motors, 6 X.by-wire: Wire ist die englische Bezeichnung für Draht, Leitung oder Kabel. By-Wire steht für die Verwendung elektrischer, elektronischer oder optischer Technologien zur Signalleitung, insbesondere in der Fahrzeugtechnik, oder der Luft- und Raumfahrttechnik. 7 Night-Vision - 10

35 Einführung und Motivation Daimler AG und BMW AG. Daraus wird ersichtlich, wie essenziell der Wissensaustausch unternehmens- oder gar branchenübergreifend ist, um neuartige Technologien gewinnbringend einzusetzen. Salma et al. sehen in der fehlenden Verfügbarkeit modernster Technologien mögliche Leistungsmängel, prolongierte Innovationszeiten und erhöhte Kosten. [SKWO06, S. 130] Durch die Zusammenführung bzw. die Einbringung von neuartigen Technologien in bestehende Forschungsfelder wurden in der Automobilindustrie bahnbrechende Innovationen erzielt. Beispielhaft sind optische Elemente zu erwähnen, die Hindernisse beim Einparken feststellen, Fahrzeuge erkennen und den Abstand wahren oder Insassen im Crash-Fall klassifizieren sowie für eine sicherheitsoptimale Airbag-Auslösung sorgen. Als eine wichtige Initiative von Herstellern und Zulieferern ist AUTOSAR 8 zu nennen. Dabei werden gezielt kooperative Entwicklungen durchgeführt, die in ihrer Funktionalität kostenabhängig für den OEM parametrisiert werden. Basierend auf dem Konzept AUTomotive Open System ARchitecture für den Fahrzeugsektor. Herausforderung: Radikaler Technologietransfer und Kollaborationen Prozesse und Prozessmodelle sollten auf Kollaborationen ausgerichtet sein und prinzipiell die Erweiterung und Überwindung organisatorischer Grenzen wie Projekte, Abteilungen, Unternehmen und Branchen, aber auch entlang der Prozesskette also mit Lieferanten und Kunden zulassen. Erlangte Erkenntnisse zu Technologien sollten gezielt dokumentiert und formalisiert werden, um diese auf andere Arbeitsfelder, Domänen und Forschungsgebiete übertragen zu können. Es müssen Repräsentationsformen und Vokabulare gefunden werden, durch die Innovationsprozess und Wissen eindeutig und strukturiert darstellbar sind. Wissen und Prozess sollen (bei Bedarf) über Unternehmensgrenzen austauschbar sein, eine weitere Bearbeitung soll den am Innovationsprozess beteiligten Experten offen stehen. Ein standardisiertes Datenaustauschformat soll verwendet werden, um die Akzeptanz und Austauschbarkeit des Wissens zwischen den kollaborierenden Unternehmen zu erhöhen Szenario: Informationsflut bei Innovationen Dokumentenverwaltungs- und Informationssysteme erzeugen Informationsfluten mit (oft redundanten) Daten oder Datenfragmentierung im Innovationsprozess. Informationsflut induziert paradoxerweise einen Wissensmangel, denn die Selektion des benötigten Wissens aus der Informationsfülle fällt schwer. Steiger stellt fest, Information stellt keinen Wert an sich dar, vielmehr gilt es, Information im Aufgabenkontext gezielt verfügbar zu machen und einzusetzen. [Stei02, S. 14] Eine typische Fragestellung in einem Innovationsszenario lautet: Wie lässt sich die Informationsflut beherrschen und wie kann vorhandenes Wissen rationell, nutzbringend und innovationsförderlich eingesetzt werden? Dieses gesammelte und stetig wachsende Innovationswissen muss im Innovationsprozess abgelegt und vor allem wiedergefunden werden. Experten nehmen derzeit eine Filterfunktion wahr. Sie entscheiden, welches Wissen tatsächlich für den Innovationsprozess relevant ist und im Kontext der Innovationsaufgabe abgelegt werden soll bzw. welches gefundene Wissen tatsächlich relevant ist. Als Zeittreiber und Risiko bei Innovationen gilt u. a. eine langwierige und unstrukturierte Wissenssuche. [SKWO06, S. 126] Herausforderung: Informationsflut bei Innovationen Eine allgemeine Herausforderung ist in der Strukturierung von vorhandenem Wissen zur Unterstützung der Wissensablage und der Wissenssuche zu sehen. Dabei ist eine Gratwanderung zwischen zu detaillierter Information und zu hohem Abstraktionsgrad zu bewerkstelligen. Relevantes Wissen soll zunächst entlang des Innovationsprozesses geordnet und diesem 8 AUTOSAR: AUTomotive Open System ARchitecture ist ein internationaler Verbund von Unternehmen mit dem Ziel, einen offenen Standard für Software-Architekturen in Kraftfahrzeugen zu etablieren. Mitglieder sind Automobilhersteller und Zulieferer von Elektronikkomponenten - 11

36 Einführung und Motivation zugewiesen werden i. S. d. prozessorientierten Innovationsmanagements. Weiterführend sollen Innovationen wissensbasiert unterstützt werden, dazu muss das Wissen innerhalb der Prozessbausteine 9 einer Ordnungs- bzw. Gliederungsvorschrift unterzogen werden. Wissen muss für unterschiedliche Anwendergruppen optimal aufbereitet und nach konkreten Abstraktionsgraden, z. B. Sub- und Superklassen, sortiert werden. Die Informationsflut kann so bewerkstelligt werden und die Anwendergruppen erhalten das Wissen in der entsprechenden Detaillierung Szenario: Dokumentation per Gesetzeszwang Auflagen durch den Gesetzgeber sind in fertigenden Industrien sowie insbesondere der Automobilindustrie relevant und erfordern systematische Weiterentwicklung von Komponenten und Systemen. Können die Auflagen nicht erfüllt werden, erhalten Komponenten oder ganze Produktlinien/Baureihen keine Zulassung. Diese Auflagen sind immer terminkritisch und können länderspezifisch divergieren, typisch sind Umweltauflagen und Emissionsgesetze oder erhöhte Sicherheitsstandards, wie einst Sicherheitsgurte und zukünftig Fußgängerschutz oder Überschlagsensoren im Crash-Fall. Zudem existieren herstellerunabhängige Anforderungen, wie die Crash-Test-Normen nach European New Car Assessment Programme 10 (Euro NCAP), bei dem Neu-Fahrzeuge eine Bewertung für den Schutz von Fahrzeuginsassen erhalten. Das Erhalten der besten Bewertung (maximal fünf Sterne) hat enorme Auswirkungen auf die Absatzzahlen der Neufahrzeuge. Somit werden den Herstellern und Zulieferern Innovationen auf Knopfdruck aufgebürdet und das Vorhalten von Dokumentationen aufgezwungen. Hierbei geht es weniger darum, Neuerungen zu entwickeln, sondern vielmehr darum, systematisch praktikable und preiswerte Lösungen hervorzubringen. Die Umsetzung der gesetzlichen Auflagen betrifft alle Hersteller und Zulieferer. Weiterentwicklungen von Komponenten sind somit keine technische Finesse oder Spielerei im Sinne des Erfindens oder Entdeckens. Es geht vielmehr darum, eine serientaugliche Lösung bis zum Einsatztermin zu präsentieren. Die eingeforderte Weiterentwicklung knüpft häufig an eine freigegebene, in Serie befindliche Lösung des Automobilbaus an. Herausforderung: Dokumentation per Gesetzeszwang Die Herausforderung besteht darin, die geforderte Innovation mit dem Wissen und bestehenden Erkenntnissen der Basisentwicklung so zu unterstützen, dass ähnliche Probleme, Herausforderungen und Rahmenbedingungen rechtzeitig erkannt und umgangen werden. Die zeitliche und strukturelle Austauschbarkeit von Aktivitäten wird eingefordert. Nimmt man den bestehenden Innovationsprozess der Basiskomponente zur Hand, so sollen sich begangene Fehler, zu erwartende Herausforderungen und Rahmenbedingungen sowie bewährte Entwicklungsansätze, mit geringem Aufwand für die aktuell durch den Gesetzgeber eingeforderte Innovation, erkennen lassen. Der Analyseaufwand, um den technischen Stand zu erfassen, soll reduziert werden. Die Weiterentwicklung und der Innovationsprozess sollen systematisch durchführbar bzw. nachvollziehbar sein und müssen entsprechend langfristig 11 dokumentiert und archiviert werden. 9 Prozessbausteine und Prozessschritte wurden in frühen Veröffentlichungen [VoHe06, VoHe06a, VoHe06b] i. S. von Überbegriffen behandelt. Im Folgenden differenzieren wir Prozessbausteine exakter in Aufgaben, Aktivitäten und Pools sowie Prozessschritte in Prozessphasen und Sequenzen [vgl. Kap. 3]. 10 Euro NCAP: Ein herstellerunabhängiges Crashtest-Programm. European New Car Assessment Programme ist eine Vereinigung europäischer Verkehrsministerien, Automobilclubs und Versicherungsverbänden Beispielsweise in der Luftfahrtindustrie müssen Dokumentationen 30 Jahre vorgehalten werden. 12

37 Einführung und Motivation Szenario: Die Rolle von Experten bei Innovationsprozessen Experten nehmen zwei entscheidende Rollen ein: Sie sind es, die Handlungsbedarf erkennen, Analysen betreiben, Innovationen durchführen und bis zur Serienreife begleiten. Weiterführend und ebenso wichtig dokumentieren sie ihre Entwicklungen und machen diese so nachvollziehbar und wieder verwendbar. Die Produktvielfalt wächst kontinuierlich und Entwicklungen müssen immer schneller und besser sein als die der Konkurrenz. In den vergangenen Jahren wurden die Entwicklungen zunehmend prozessorientiert ausgerichtet, diese Prozesse laufen parallel statt nacheinander ab. Wissen kann nicht erst nach Projektende dokumentiert werden, sondern muss umgehend anderen Innovationsprojekten zur Verfügung gestellt werden. Mitarbeiter sind parallel an der Entwicklung mehrerer Fahrzeugprojekte beteiligt, entsprechend sind sie heute in das eine, morgen in einem anderen Team eingebunden permanenter Wissensaustausch ist hier eine grundlegende Voraussetzung. Herausforderung: Die Rolle von Experten bei Innovationsprozessen Wissen und Experten sind derzeit an vielen Stellen in innovativen Unternehmen als Einheit zu sehen. Es wird als notwendig erachtet, ein Expertenmanagement in das Innovationsmanagement zu integrieren. In kritischen Situationen und bei heiklen Entscheidungsprozessen sollten Experten auf direktem Weg kontaktierbar sein. 1.4 Conclusio und zusammengefasste Herausforderungen Nicht zwingend müssen alle hier identifizierten expliziten Herausforderungen in die Unterstützung der Methode WPIM sowie in die entstehende prototypische Anwendung integriert werden. Auf welcher Unternehmensebene die Funktionen ihre Wirkung optimal entfalten können, ist unternehmensabhängig und bedarf einer Diskussion. Bereits die Umsetzung bzw. Integration einzelner Funktionen in bestehende Anwendungen kann Innovation fördern und diese positiv beeinflussen. Im Überblick sind die beiden zentralen Herausforderungen dargestellt: zur Unterstützung von innovativen Produktentwicklungsprozessen zunächst eine geeignete Struktur zur Wissensrepräsentation des Innovationsprozesses selbst sowie aller benötigten Ressourcen finden, implizites Wissen von Mitarbeitern auch in expliziter Form verfügbar zu machen und Wissen prozessorientiert an Innovationsprozesse zu knüpfen bzw. das Wissen in den Innovationsprozess zu integrieren. Die allgemeingültigen Herausforderungen wurden auf der Konferenz KnowTech 2006 mit Experten der Domänen Wissens- und Innovationsmanagement diskutiert und in [VoHe06b, S. 288] veröffentlicht. Im Folgenden sind die identifizierten Herausforderungen aufgeführt: Projektübergabe und Nachfolger-Regelung, Radikaler Technologietransfer und Kollaborationen, Informationsflut bei Innovationen, Dokumentation per Gesetzeszwang, die Rolle von Experten bei Innovationsprozessen. Zur weiteren, detaillierteren Anforderungsanalyse identifiziert die vorliegende Arbeit im weiteren Verlauf die wissenschaftlichen Felder, die zu diesen Herausforderungen weiterführende Unterstützungs- und Lösungsansätze bieten. Auf das Wissensmanagement (engl. Knowledge Management, KM), das Prozessmanagement sowie das Organisations- und Innovationsmanagement (engl. Innovation Management, IM) wird daher im Überblick in [Kap. 2 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement] eingegangen. Das Technologiemanagement mit semantischen Technologien wird im Rahmen der Implementierung in [Kap. 4 Operationalisierung der WPIM-] erläutert. 13

38 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement 2 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Zur Definition und Spezifikation der Anforderungen an das Wissensbasierte und Prozessorientierte Innovationsmanagement werden nun zunächst bestehende Methoden im Bereich Prozessmanagement und Wissensmanagement erläutert. Anhand der Analyse des Standes der Wissenschaft und Technik wird dargelegt, welche Aspekte bereits beleuchtet sowie erarbeitet wurden und welche Ansätze und Methoden aktuell verfolgt werden bzw. hohe Potenziale für zukünftige Verbesserungen in Innovationsprozessen bergen. Die Analyse wird in drei Bereiche unterteilt: Wissenschaftliche Modelle zum Wissensmanagement zur theoretischen Grundlagenbildung, Prozessmanagement mit Werkzeugen, die sich in der unternehmerischen Praxis bewährt haben sowie Innovationsmanagement und organisatorische Instrumente. Angemerkt sei, dass die Abgrenzung zwischen wissenschaftlichen Modelle, den Werkzeugen im Prozessmanagement sowie den organisatorischen Instrumenten nicht immer eindeutig ist. Einige Werkzeuge sind dem theoretischen Bereich entwachsen und haben sich in der Praxis bewährt, somit ist eine exklusive Zuordnung nicht eindeutig möglich. Eine Diskussion rundet die Betrachtung ab. 2.1 Wissenschaftliche Modelle zum Wissensmanagement Zu den grundlegenden Modellen des Wissensmanagements gehören die Wissenstreppe nach North [Nort02, S. 37], das Technik-Organisation-Mensch (TOM)-Modell nach Bullinger et al. [vgl. LuTr02, S. 22; vgl. BuWP97], die Bausteine des Wissensmanagements nach Probst et al. [Prob99, S. 52] sowie das SEKI Modell und die Wissensspirale nach Nonaka und Takeuchi [NoTa97, S. 84]. Aufbauend auf dem Referenzmodell Wissensmanagement wurde am Fraunhofer IPK eine Methode zum geschäftsprozessorientierten Wissensmanagement (GPO-WM ) von Heisig entwickelt [Heis02, S. 47]. Zur Modellierung wissensintensiver Geschäftsprozesse (wigp) wird die Methode der integrierten Unternehmensmodellierung (IUM) verwendet [vgl. Heis02, S. 49]. Das Softwarewerkzeug und die Methode zur objektorientierten Geschäftsprozessoptimierung (MO 2 GO) unterstützen diesen Ansatz [vgl. Diet05, S. 18]. Die Kommunikationsdiagnose (KODA), ebenfalls Fraunhofer Gesellschaft, und dort am Institut für Manufacturing Strategies (IMS) entwickelt, integriert zu den reinen Wissensmanagementaufgaben eine weiterführende Sicht auf Kommunikationsprozesse, deren Analyse und Optimierung [vgl. DäHB02, S. 136]. Das Münchener Modell von Reinmann- Rothmeier und Mandl ergänzt das Wissensmanagement um die Perspektive des Lernens [vgl. Rein01, S. 15; vgl. ReMa00]. Dazu wird der kollaborative Ansatz Kollaboration, Kommunikation und Kompetenz (K3) von Kuhlen untersucht, der Wissensproduktion und Wissensaustausch in Lernumgebungen und zur akademischen Ausbildung betrachtet [Grie04; Kuhl03; vgl. Sema04]. K3 12 und das Portal EnForum wurden an der Universität Konstanz zum Wissensaustausch erprobt und konnten sich bei dynamischen Definitionen als besonders hilfreich erweisen [vgl. EnFo06]. 12 K3 is an open software system that supports collaborative and distributed production of conceptual knowledge in academic learning environements by using heterogeneous resources and moderated electronic communication forums.( ) This knowledge is strongly linked, structured by context and semantics as well as visualized to ensure comfortable navigation [Sema04, S. 406 ff.]. 14

39 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Wissenstreppe North Die Wissenstreppe wurde von Prof. Klaus North an der Fachhochschule Wiesbaden entwickelt, um Unternehmen wissensorientiert zu führen, und formuliert: Ziel wissensorientierter Unternehmensführung ist es, aus Information Wissen zu generieren und dieses Wissen in nachhaltige Wettbewerbsvorteile umzusetzen, die als Geschäftserfolge messbar werden [Nort02, S. 37]. Die Wissenstreppe zählt zu den grundlegenden Theorien im Wissensmanagement. Abb. 2.1: Die Wissenstreppe nach North [Nort02, S. 39] Wissensorientierte Unternehmensführung bedeutet, alle Stufen der Wissenstreppe zu gestalten. Ist eine Stufe der Treppe nicht ausgebildet (z. B. durch fehlende Datenkompatibilität, unvollständige Informationsverfügbarkeit, fehlende Handlungsmotivation), so stolpert man beim Begehen der Wissenstreppe [Nort02, S. 41]. Zur Vertiefung der stark betriebswirtschaftlichen Begriffe der Wissenstreppe wie Wettbewerbsfähigkeit, Handeln und Können wird an dieser Stelle auf Wissensorientierte Unternehmensführung von North verwiesen. Die Begriffe Daten, Information und Wissen der Wissenstreppe nach North sind abzugrenzen von den Definitionen, wie sie Kuhlen verwendet [Kuhl03, Kuhl04, Sema04]. Darüber hinaus finden bei North erste Prozessgedanken im Wissensmanagement Beachtung, er spricht von drei Handlungsfeldern [vgl. Nort02, S. 41 ff.]: Strategisches Wissensmanagement durchläuft die Wissenstreppe von oben nach unten, um die Frage zu beantworten, welche Kompetenzen und daraus abgeleitet, welches Wissen und Können benötigt wird, um wettbewerbsfähig zu sein. Die Aufgabe besteht darin, ein Unternehmensmodell zu entwickeln, in dem die motivationalen und organisationalen Strukturen und Prozesse konzipiert werden, um das Unternehmen fit für den wissensbasierten Wettbewerb zu machen. [Nort02, S. 41] Operatives Wissensmanagement beinhaltet insbesondere die Vernetzung von Information zu Wissen, Können und Handeln. Für den Erfolg wissensorientierter Unternehmensführung ist entscheidend, wie der Prozess individuelles in kollektives Wissen und kollektives in individuelles Wissen gestaltet wird. Ohne wirksame Anreize findet dieser Prozess nicht statt. Operatives Wissensmanagement hat daher die Aufgabe Rahmenbedingungen zu schaffen, die Anreize für Wissensaufbau, -teilung und -nutzung bieten. [Nort02, S. 41] 15

40 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Informations- und Datenmanagement ist eine Grundlage des Wissensmanagements. Bei Betrachtung der Wissenstreppe ist die Bereitstellung, Speicherung und Verteilung von Information Voraussetzung für Wissensaufbau und -transfer. In Untersuchungen stellte North fest, dass Informations- und Kommunikationstechnologie für Informationund Datenmanagement ohne entsprechende organisatorische und motivationale Rahmenbedingungen nur ungenügend genutzt wird. [vgl. Nort02, S. 42] Die Wissenstreppe nimmt Bezug auf semiotische Ebenen des Wissensmanagements und nähert sich Wissen über Daten sowie Information aus der Bottom-Up-Sicht. In der Top-Down-Sicht werden grundlegende Themen der Unternehmensführung beleuchtet und um Wissensaspekte ergänzt. Eine differenzierte Betrachtung von Geschäftsprozessen und Wissensprozessen wird nicht vorgenommen TOM-Modell Bullinger et al. Eine Orientierung im breiten Feld der Wissensmanagementkonzepte bietet die dichotome Klassifizierung in Technikorientierung versus Humanorientierung nach Schüppel [vgl. Schü96, S. 187]. Bullinger, Wörner und Prieto entwickelte daraus 1997 die Dreiteilung Menschen- Organisation-Technologie für erfolgreiches Wissensmanagement in Unternehmen [vgl. BuWP97, S. 10]. De facto steht dieser Ansatz für drei verschiedene Bildungsbereiche und deren Perspektiven. Lucko und Trauner leiten daraus das TOM-Modell (Technik, Organisation, Mensch) ab, die Ursprünge sind jedoch bei Bullinger et al. zu sehen [vgl. LuTr02, S. 22; vgl. BuWP97]. Technologie: Wissensmanagement als Wissensrepräsentation Eine technische Auslegung sieht Wissen als Objekt. Rationalisierungs- und Effektivierungsbestrebungen sollen durch eine bessere maschinelle Identifizierung und Verarbeitung von Wissen erzielt werden. Relevant sind insbesondere der Zugang und die Verfügbarkeit expliziten Wissens [vgl. Schü96, S. 187] auf organisationaler Ebene. Die praktische Auseinandersetzung mit dem Thema Wissensmanagement geht hier von der Organisations- und EDV-Abteilung eines Unternehmens aus [Schü96]. Wissensmanagement umfasst dabei hauptsächlich das Management angereicherter Information mithilfe moderner Informationstechnologien (IT). Wissensorientierte Entwicklung, Implementation und Einsatz stehen im Zentrum dieser Betrachtungen [Schü96]. Menschen: Wissensmanagement als Lernprozess Die humanorientierte Sichtweise versteht Wissen als einen Prozess, der dynamisch, kontextgebunden und personalabhängig ist. Wissen kann durch gemeinsam geteilte Konstruktionen objektiviert werden. Daher steht die Gestaltung und Nutzung der Interaktionsprozesse sowie des Lernens der Mitarbeiter als primäre Wissensträger im Zentrum des Wissensmanagement. In der Unternehmenspraxis gehen hier die Wissensmanagementaktivitäten vom Personalwesen bzw. von der Personalentwicklung aus und zielen vorrangig auf den Ausbau und die Nutzung der Fähigkeiten, Erfahrungen und Kenntnisse der Menschen im Unternehmen. [vgl. Schü96, S. 188] Organisation: Wissensmanagement als Organisationsgestaltung Im Gegensatz dazu ist aus Sicht der Organisationslehre die vollständige Erfassung und Explizierung von Wissen nur in einigen wenigen Anwendungsbereichen möglich und sinnvoll, in denen Wissen als weitgehend stabil und gesichert angesehen werden kann. Gestaltungsobjekt des Wissensmanagements ist aus diesem Grund hier nicht das Wissen 16

41 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement selbst, sondern vielmehr all jene Prozesse einer Organisation, in denen Wissen verarbeitet wird. [Thie01, S. 12] Die Technikfokussierung vernachlässigt insbesondere die kognitiven Gesichtspunkte und Potenziale individuellen Wissens. Auch wird der Einfluss organisatorischer Regelungen, der Bereitschaft und Fähigkeiten der Mitarbeiter sowie der Normen und Werte im Unternehmen nicht berücksichtigt. [vgl. Schü96, S. 18] Thiesse kontert: Gestaltungsobjekt des Wissensmanagements ist aus diesem Grund hier nicht das Wissens selbst, sondern vielmehr all jene Prozesse einer Organisation, in denen Wissen verarbeitet wird. [Thie01, S. 12] Das TOM- Modell wird immer häufiger zitiert, des Weiteren wurde dem Modell sowohl auf der Know Tech 2006 als auch auf den Stuttgarter Wissensmanagement Tagen 2006 große Beachtung gewidmet. Die häufige Zitierung ist darin zu sehen, dass eine Vielzahl an technischen IT-Lösungen am Markt erhältlich ist. Die Akzeptanz der Werkzeuge im Unternehmen ist gering oder scheitert, in Konsequenz rücken Mitarbeiter und Organisationen stärker in den Fokus der Wissensforscher. Durch die wissensorientierte Ausrichtung von Prozessen und Unternehmenskulturen sollen die entsprechenden Strukturen für Wissensmanagement gelegt und systematisch etabliert werden. Das TOM-Modell ist sehr allgemein gehalten, eine Unterstützung bei der Einführung von konkreten Wissensmanagement-Aktivitäten kann es nur bedingt leisten. Abb. 2.2: TOM-Modell nach Lucko/Trauner [LuTr02 in VoHe06, S. 14] Bausteine des Wissensmanagements Probst et al. Das Konzept der Bausteine des Wissensmanagements wurde am Lehrstuhl von Prof. Gilbert Probst an der Universität Genf entwickelt. Mit diesem liegt ein praxisbezogenes Rahmenwerk zur Gestaltung des Wissensmanagements einer Organisation vor [vgl. Romh98, S. 31]. Bereits 2004 spricht Trillitzsch vom populärsten Konzept im deutschen Sprachraum [Tril04, S. 55]. 17

42 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Abb. 2.3: Bausteine des Wissensmanagements von Probst [Prob99, S. 58; VoHe06, S. 15] Die einzelnen Handlungsfelder oder Aktivitäten des Wissensmanagements werden in zwei Kreisläufen miteinander in Beziehung gesetzt [vgl. Abb. 2.3], wobei gesteuerte Wirkungen und ungesteuerte Rückwirkungen auftreten. Der innere Kreislauf, die Kernprozesse [Prob99, S. 52], umfasst Identifikation, Erwerb, Entwicklung, Verteilung, Bewahrung und Nutzung von Wissen. Der äußere Kreislauf besteht aus den Prozessen Wissensziele, Umsetzung des inneren Kreislaufs sowie Wissensbewertung. Den einzelnen Bausteinen werden verschiedene Instrumente des Wissensmanagements zugeordnet. [Diet05, S. 16] Die Bausteine des Wissensmanagements werden vorgestellt [vgl. Romh98, S. 77 ff.; vgl. Prob99, 53 ff.]: Wissensidentifikation: Durchführung von Maßnahmen zur internen und externen Wissensidentifikation sowie Analyse des Wissensumfeldes des Unternehmens. Durch diese Analyse wird Transparenz im Unternehmen bezüglich vorhandener Information und Wissen geschaffen, so können Fehlentscheidungen, Ineffizienzen und Doppelspurigkeit vermeiden werden. Wissenserwerb: Beschaffung von neuem Wissen, welches nicht aus eigener Kraft entwickelt werden kann. Dies kann u. a. durch die Rekrutierung von Experten oder die Akquisition innovativer Unternehmen erfolgen. Der Erwerb bezieht sich auf Wissensquellen die außerhalb des Unternehmens liegen. Wissensentwicklung: Komplementär zum Wissenserwerb. Im Mittelpunkt steht die Produktion neuer Fähigkeiten, neuer Produkte, besserer Ideen und leistungsfähigerer Prozesse. [Romh98, S. 12] Motivation, Freiräume und Kreativität der Mitarbeiter stellen entscheidende Faktoren dar. Wissens(ver-) teilung: Bereitstellung und Austausch von isolierter Information oder Erfahrungen im gesamten Unternehmen. Analyse und Optimierung der Übergänge von individuellen Wissensbeständen auf Gruppen- und Organisationsebene. Wissensnutzung: Produktiver Einsatz der Ressource Wissen im Unternehmen z. B. die Nutzung von Patenten. 18

43 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Wissensbewahrung: Prozesse der Wissensselektion, der Bewahrung, des Vergessens, der Speicherung und der Aktualisierung werden gestaltet, damit das einmal vorhandene Wissen auch in Zukunft dem Unternehmen zur Verfügung steht. Probst ergänzte folgende pragmatische Bausteine des Wissensmanagements und schafft einen sehr theoretischen Regelkreis: Wissensziele: Sie geben den Aktivitäten des Wissensmanagements auf normativer, strategischer und operativer Ebene eine Richtung und legen fest, welche Fähigkeiten aufgebaut werden sollen. [vgl. Romh98, S. 7] Wissensbewertung: Entsprechend den formulierten Wissenszielen werden Methoden zur Bewertung der Zielerreichung nötig [vgl. Romh98]. Maßnahmen des Wissensmanagements beanspruchen Ressourcen und insofern sollten ihre Qualität und ihre Wirksamkeit belegt werden. Dies geschieht im dargestellten Feedback. Somit baute Probst das Konzept zu einem Managementregelkreis aus [vgl. Prob99, S ]. Die Bausteine des Wissensmanagements fanden sowohl in der Theorie, als auch der Unternehmenspraxis eine weite Verbreitung. Trillitzsch konstatiert: Allerdings zeigt sich bei der praktischen Arbeit mit ihnen, dass sie sich eher als Heuristik, nicht als Arbeitsleitfaden eignen, denn bei der Zuordnung von konkreten Wissensproblemen auf einzelne Bausteine zeigt sich deren fehlende Trennschärfe. [Tril04, S. 55] Die Kernprozesse weisen mehr oder weniger enge Verbindungen zueinander auf. Von einer isolierten Optimierung in einzelnen Bereichen ohne Berücksichtigung seiner Auswirkungen sollte abgesehen werden. [Prob99, S. 53] Die Potenziale der Informationstechnologie werden im Wissensmanagement-Ansatz nach Probst nicht berücksichtigt. Insgesamt werden IT-Aspekte als nicht entscheidend für den Erfolg eines Wissensmanagement-Projekts gesehen [Romh97 nach Thie01, S. 45]. Das Konzept ist zur ganzheitlichen Analyse von Unternehmen aus wissenstheoretischer Sicht geeignet, bei der praktischen Umsetzung kann es allerdings nur bedingt unterstützen SEKI-Modell und Wissensspirale Nonaka/Takeuchi Das SEKI-Modell (Sozialisation, Externalisierung, Kombination, Internalisierung) ist ein von den japanischen Managementforschern Nonaka und Takeuchi vorgestelltes Modell zur Modellierung der Wissenserzeugung, das als Grundlage des Wissensmanagements dient. Das Modell wurde erstmals 1995 in ihrem Buch The Knowledge Creating Company (deutsch 1997 als Die Organisation des Wissens) vorgestellt, das großen Einfluss auf die folgende Literatur und Forschung zum Thema Wissensmanagement ausübt und als der Klassiker dieser noch relativ jungen Disziplin angesehen werden kann Es beschreibt die vier Wissenserzeugungs- und Wissenstransformationsprozesse [Nort02, S. 50] zwischen implizitem und explizitem Wissen. Der Lerneffekt und die Weiterentwicklung der Wissensbasis ergibt die Wissensspirale, die sich bei mehreren Durchläufen des SEKI-Prozesses einstellt und bei Weggemann als (organisationaler) Lernprozess beschrieben wird [Wegg99, S. 45]. Das in diesem Zusammenhang mit Abstand am häufigsten zitierte Modell ist die sog. Wissensspirale nach [NoTa97, S. 84], in der die vier Grundmuster des Wissenstransfers beschrieben werden, dargestellt in [VoHe06, S. 16]. Nonaka/Takeuchi unterscheiden hier einerseits explizites Wissen, welches in Medien abgelegt ist und mit Mitteln der Informationsund Kommunikationstechnologie aufgenommen, übertragen und gespeichert werden kann. 19

44 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Andererseits wird implizites Wissen betrachtet, welches auf Idealen, Werten und Gefühlen einzelner Personen beruht, und nur schwer zu formulieren und weiterzugeben ist. [Thie01, S. 18] Kern dieses Modells sind die Wechselwirkungen zwischen explizitem und impliziten sowie individuellem und kollektiven Wissens zur Generierung von Wissen und Innovation. [Tril04, S. 55] 20 Abb. 2.4: Die Wissensspirale von Nonaka/Takeuchi [Thie01, S. 18; NoTa95, S. 72] Nach Nonaka/Takeuchi erfolgt dies in vier Schritten, die auch als SEKI-Prozess beschrieben werden. Die Schritte benennen sie mit Sozialisation (S), Externalisierung (E), Kombination (K) und Internalisierung (I). Das zyklische Durchlaufen der vier Schritte bildet die Wissensspirale die Ressource Wissen befindet sich in einem kontinuierlichen, dynamischen Veränderungs- Prozess [vgl. NoTa97]: Sozialisation: Implizites Wissen (auch stillschweigendes, personelles oder engl. tacit knowledge genannt) wird zwischen personellen Wissensträgern ausgetauscht, neues implizites Wissen entsteht in den Köpfen der Mitarbeiter. Das getauschte sowie neu erschaffene, implizite Wissen steht der Unternehmung aber nicht offen und gesamtheitlich zur Verfügung, sondern nur den Mitarbeitern, die an der Sozialisation und Kommunikation des Wissens aktiv beteiligt waren. Externalisierung: Dabei wird implizites Wissen in explizites Wissen umgewandelt und das Wissen in expliziter Form der ganzen Organisation zur Verfügung gestellt. Dieses geschieht durch Dokumentation des impliziten Wissens in Form von Modellen und Diagrammen, aber auch Metaphern, Analogien oder bildhafter Sprache. Kombination: Durch die Zusammenführung von vorhandenem, explizitem Wissen z. B. aus unterschiedlichen Wissensdomänen wird in der Unternehmung neue Information generiert. Hierbei handelt es sich definitiv noch nicht um Wissen, sondern lediglich um Information im Kontext der Unternehmung. Internalisierung: Das dokumentierte explizite Wissen in der Organisation wird in der Phase der Internalisierung von den Mitarbeitern durch Adaption, Erweiterung und Verknüpfung in implizites Wissen transformiert. Das ist der entscheidende, dem

45 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Menschen vorbehaltene Schritt kognitiver Wertschöpfung die Wissensgenerierung. Bei der Wissensgenerierung unterscheiden Nonaka/Takeuchi zudem verschiedene Ebenen. Die Individuen-, Gruppen- und Organisationsebene sowie die organisationsübergreifende Ebene [vgl. NoTa97, S. 84]. Die Dimension der Organisationsstufe wird als ontologisch bezeichnet Die Dimensionierung bzw. der Grad der Formalisierung von Wissen in impliziter oder expliziter Form wird als epistemologisch angeführt Mit ihrem Ansatz liefern Nonaka/Takeuchi ein gut ausgearbeitetes und wissenschaftlich fundiertes Erklärungsmodell für die Wissensgenerierungsprozesse im Unternehmen, gehen allerdings nicht explizit auf konkrete Management-Aktivitäten zur Einführung dieser Prozesse ein. [Tril04, S. 57] Die angesprochenen Ebenen stellen keinen Bezug zu Prozessen im Allgemeinen bzw. Geschäftsprozessen und Innovationsprozessen im Besonderen her. Dieser Ansatz müsste hinsichtlich der aktuellen Betrachtungen von Projekt- und Prozessorganisationen adaptiert oder erweitert werden Prozessorientiertes Wissensmanagement Fraunhofer IPK Das am Fraunhofer Institut für Produktionsanlagen und Konstruktionstechnik (Fraunhofer IPK) entwickelte Referenzmodell Wissensmanagement führt die Interventionsebenen Controlling, Führungssysteme, Informationstechnologie, Personalmanagement und Prozessorganisation auf. Letztere steht insbesondere im Mittelpunkt einer Methode zum geschäftsprozessorientierten Wissensmanagement (GPO-WM ) von Heisig [Heis02, S. 47]. Heisig beschreibt mit dem GPO- WM eine Methode des geschäftsprozessorientierten Wissensmanagement. GPO-WM umfasst neben einem Vorgehensmodell auch unterstützende Instrumente. Neben der Speicherung und Verteilung werden auch die Anwendung und Erzeugung von Wissen abgebildet. Sowohl explizites als auch implizites Wissen wird in Wissensdomänen geordnet und als Ressourcen der einzelnen Prozesse dargestellt. [vgl. Heis02, S ] Das allgemeine Vorgehensmodell sowie die konkreten Analyseschritte im GPO-WM können in [AHMM02] nachvollzogen werden. Basis dafür bildet das prozessorientierte Wissensmanagement (pwm). Die Gestaltung von Wissensprozessen in Verbindung mit den anderen Ebenen zur Unterstützung von wertschöpfenden Geschäftsprozessen ist Ziel des pwm [vgl. Heisig 2001 in Remu02, S. 42]. Abb. 2.5: GPO-WM Gestaltungsgrade [Heisig 2002 in Gron06, S. 17] Den Kern des Referenzmodells stellen die Geschäftsprozesse als Anwendungsbereich von 21

46 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Wissen dar. Die Aktivitäten des Wissen -erzeugen, -speichern, -verteilen und -anwenden, die zusammen einen geschlossenen Kernprozess bilden, beziehen sich auf den Geschäftsprozess [Heis02, S. 53]. Die vier Kernaktivitäten wurden von Unternehmenspraktikern als unabdingbar und wichtig eingeschätzt [Heisig/Vorbeck 2001 in AHMM02, S. 53] Beim Prozessorientierten Wissensmanagement werden, ausgehend von der Analyse wissensintensiver Geschäftsprozesse (wigp), die Geschäftsprozesse systematisch gestaltet und verbessert. Dabei wird besonderer Wert darauf gelegt, die einzelnen Aktivitäten des Wissensmanagements zu modellieren und in die entsprechenden Geschäftsprozesse zu integrieren [AHMM02]. Zur Modellierung wird die ebenfalls am Fraunhofer Institut bereits in den 80er Jahren entwickelte Methode der integrierten Unternehmensmodellierung (IUM) verwendet. Die IUM wurde entwickelt, um Prozesse in Unternehmen abzubilden, zu beschreiben, zu analysieren und gestalten zu können. [Heis02, S. 49] Das Softwarewerkzeug MO 2 GO (Methode zur objektorientierten Geschäftsprozessoptimierung) unterstützt diese Methode [vgl. Diet05, S. 18]. Zentral sind hier die drei Objektklassen Produkt, Auftrag und Ressource, die durch Aktionen innerhalb eines generischen Aktivitätenmodells mit Hilfe von fünf Verbindungselementen verknüpft werden können. [Heis02, S. 50] Wissen kann mit allen Objekttypen in Beziehung gesetzt werden. Wissen als Subklasse der Klasse Ressource ist beispielsweise notwendig, um ein Produkt oder eine Dienstleistung zu erstellen (Wissen als Teil der Objektklasse Produkt). Die Subklasse Wissen kann wiederum hierarchisch verfeinert und anderen Subklassen der Klasse Ressourcen zugeordnet werden (z. B. Mitarbeitern, Datenbanken oder Dokumenten). Die Objektklasse Auftrag wird mit Wissenszielen verknüpft. Um die Objekte genauer bzw. angepasst an Modellierungsziele beschreiben zu können, lassen sich zu jeder Objektklasse Attribute zuordnen. [Remu02, S. 43] Das Prozessorientierte Wissensmanagement ist ein Konzept, das durch Modellierung und Analyse von wigp Verbesserungspotenziale analysiert, die anschließend durch geeignete Gestaltungsbausteine des Wissensmanagements (Best-Practices) erschlossen werden können. [Heis02, S. 55] Die rund 30 vorgeschlagenen Best-Practices entstammen Benchmarkingstudien des Informationszentrums Benchmarking und des Competence Centers Wissensmanagement am Fraunhofer IPK, vertiefende Literatur Mertins, Heisig, Vorbeck mit ihrem Werk Best-Practices in Europe. Abb. 2.6: Zuordnung von Best-Practice zu den Geschäftsprozessen [Remu02, S. 60] Positiv auffallen konnte das ganzheitliche Konzept der IUM Methodik mit einer Vielzahl von Perspektiven ebenso wie die implementierten Anwendungen MO 2 GO und GPO-WM. Das 22

47 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement hier betrachtete Prozessorientierte Wissensmanagement kann als Erweiterung der Methode IUM gesehen werden. IUM ist objektorientiert [Heis02, S. 50]. IUM und Prozessorientiertes Wissensmanagement dienen beide der objektorientierten Abbildung von Wissen. Kern bilden die Prozessanalyse, -auswahl und -optimierung. Bei der Modellierung mit IUM wird nicht ausreichend auf die Prozesse und Prozessorientierung eingegangen. Die kontinuierliche Prozessfortschreibung und Erweiterung wird im Modell Prozessorientiertes Wissensmanagement nicht bedacht. Auch eine geeignete Repräsentationsform für Wissen bzw. Wissensstrukturen konnten nicht identifiziert werden. Beim Prozessorientierten Wissensmanagement wird auf die Modellierung wissensrelevanter Beziehungen, z. B. Kommunikationsbeziehungen verzichtet. [Remu02, S. 44] Kommunikationsdiagnose Fraunhofer IMS Die Kommunikationsdiagnose (KODA) wurde von der Fraunhofer Gesellschaft entwickelt und dort am Institut für Manufacturing Startegies (IMS) in zahlreichen Projekten eingesetzt und wissenschaftlich untersetzt [DäHB02, S. 136]. Kühnle, Sternemann und Harz stellten fest, dass das Aufdecken von Schwachstellen in Kommunikationsnetzwerken die Voraussetzung für die bedarfsgerechte Neugestaltung und Optimierung betrieblicher Abläufe bildet. KODA unterstützt neben der Prozessmodellierung auch die Modellierung der Kommunikationsstrukturen, die wiederum prozessbezogen abgebildet werden können [vgl. KüSH98]. Die Ziele nach Dämmig et al. sind u. a. in der Abbildung des Ist-Zustandes der Kommunikation, der Gestaltung transparenter, unkomplizierter Abläufe, der Reduktion von Schnittstellen, der Erhöhung von Informationsqualität und dem Abbau von Informationsdefiziten sowie der Mitarbeiterintegration zu sehen [DäHB02, S. 139]. Abb. 2.7: Beschreibungsmodell zur Methode KODA [Gron06, S. 31] Nach Martinez und Mertens können die nachstehenden Indikatoren wichtige Anhaltspunkte für Kommunikationslücken, Schwachstellen und Optimierungspotenzial in der Kommunikation liefern [vgl. MaMe98, S ]: Anzahl der Kommunikationskanäle: Nähert sich eine Struktur einer Vollstruktur, so nimmt die Zahl der Kommunikationskanäle zu. Existenz von Kommunikationsschnittpunkten: Je mehr Kommunikationsschnittpunkte vorhanden sind, desto vermaschter ist das Kommunikationsnetz. Stark vermaschte Strukturen funktionieren auch nach Entfernung/Wegfall eines Schnittpunktes voll. Bei 23

48 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement schwach vermaschten Strukturen droht hingegen der Zerfall in Teilstrukturen beim Entfall eines Kommunikationspunktes. Hierarchischer Aufbau: Dabei wird zwischen baumartigen, hierarchischen Gebilden und Netzen mit gleichberechtigten Kommunikationspartnern differenziert. Entfernung oder Weglängen in der Struktur: Bei Bäumen ist die Entfernung zwischen oberstem und unterstem Knoten relativ groß. Bei Netzen ist durch die Verbundenheit die Entfernung zwischen einzelnen Knoten gering, die Gesamtentfernung im Netz allerdings hoch. Kommunikationsrichtung: Bei stark formalisierter Kommunikation ist die Kommunikationsrichtung hoch. Typisch sind Befehlswege in Bäumen von oben nach unten. Den Ablauf beschreibt Remus folgendermaßen: Zunächst wird der Ist-Zustand der Kommunikation erfasst und beschrieben, danach wird die Strukturkomplexität als Funktion der Elemente und der Art ihrer Beziehungen ermittelt und versucht, die Strukturkomplexität zu reduzieren. Die Kommunikationsbewertung mit Parametern (Häufigkeit, Art, Vorgang, Medium, Zeit, Qualität, Kosten) liefert Hinweise zur Reduktion von Kommunikationselementen und - beziehungen. Die Parameter zur Bewertung von Kommunikationsstrukturen werden bereits bei der Modellierung berücksichtigt und erhoben. Nach der Analysephase wird ein Soll-Zustand definiert, dieser bewertet und schließlich in Form eines Soll-Konzepts umgesetzt. [Rem02a, S. 110ff.; Remu02 S. 47] Eine ausführliche Anleitung zur Vorgehensweise bei der Kommunikationsdiagnose sowie zur darauf aufbauenden Fachsoftware KODA geben Dämmig, Hess und Borgmann [DäHB02, S ]. In Ansätzen verfügt auch der umfassende Modellierungsansatz ARIS über ein Kommunikationsmodell. [Remu02a, S. 103] Die KODA ist eine integrierte Vorgehensweise zur dynamischen Modellierung von Geschäftsprozessen und Kommunikationsstrukturen. [DäHB02, S. 139] Mit Hilfe der KODA wird die Kommunikation zwischen Agenten verbessert. Die verbesserte Kommunikation führt schließlich indirekt zu einer Verbesserung der Wissensverarbeitung in den zugrundeliegenden Geschäftsprozessen [Remu02a, S. 112], auch informelle Kommunikationsbeziehungen über Abteilungsgrenzen und Geschäftsprozesse hinweg werden aufgezeigt. [Remu02, S. 48] Die Kommunikation ist eine wichtige Voraussetzung zum Austausch und zum Transfer von Wissen. Die KODA kann zwar Art und Umfang der Kommunikationsbeziehungen messen, nicht aber Aussagen zu ausgetauschten Inhalte treffen noch hinsichtlich der Adaption von Wissen bei den Kommunikationspartnern [DäHB02]. Die Autoren selbst sprechen das Informationsparadoxon an also das Missverhältnis von Informationsflut und der Relevanz der Information. [DäHB02, S. 138] Durch die Menge der getauschten Information kann kein Rückschluss auf die Relevanz der Information gezogen werden. Zudem erfordert die KODA eine partizipative Unterstützung aller Mitarbeiter und Manager. [Remu02a, S. 125] Der Mitarbeiter modelliert seine Kommunikationsbeziehungen selbst. Damit setzen sich die Mitarbeiter aktiv mit ihren Prozessen und ihrem Prozesswissen auseinander, was zu einer stärkeren Beteiligung und Motivation zur Verbesserung der Prozesse führen kann. [Remu02, S. 48] Wie spezifische Wissensprozesse gestaltet werden sollen, wird nicht beschrieben, ebenso wenig wie die Einführung von Wissensstrukturen Münchener Modell Reinmann-Rothmeier/Mandl Das Münchener Modell (MM) wurde von Reinmann-Rothmeier und Prof. Mandl entwickelt am 24

49 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Lehrstuhl für Empirische Pädagogik und Pädagogische Psychologie. Ausgangspunkt des Münchener Wissensmanagement-Modells ist die Zielrichtung des Lernens sowie die Vorstellung von Wissen als einem variablen Zustand zwischen Information und Handeln. [Rein01, S. 2] Insbesondere geht es auf die bereits im TOM Modell angesprochene Perspektive Mensch bzw. Personal oder Human Resources ein [vgl. Rein01, S. 15]. Wissen wird beim Münchener Modell sowohl ein Prozesscharakter als auch ein Objektcharakter zugesprochen und somit in Informationswissen und Handlungswissen differenziert [vgl. Rein01, S. 11]. Wissen als Objekt: Die in einer Enzyklopädie festgehaltenen Erkenntnisse wissenschaftlicher Forschung oder die in einem Intranet verwalteten Best-Practice- Berichte über erfolgreiche Projekte, sind als Informationswissen materialisiert. [Rein01, S. 11] Wissen als Prozess: Ist die im Handeln eines Experten erkennbare langjährige Erfahrung oder die im Team-Handeln aufscheinende kollektive Wissensbasis also sein Handlungswissen [ReMa00]. Weiter verwenden Reinmann-Rothmeier/Mandl zur Veranschaulichung des Wissensbegriffs die Analogie des Wassers und dessen Aggregatzustände. Dabei beschreiben sie Eis als feste Information und Informationswissen, Dampf als gasförmiges Handlungswissen und zugehöriges Handeln sowie Wasser als den flüssigen Wissensalltag. [vgl. Rein01, S. 12 u. 13] Dazu treffen Reinmann-Rothmeier/Mandl einige bemerkenswerte Aussagen: Im gefrorenen Zustand lässt sich Wissen von einem kalten Ort zu einem anderen transportieren und der Versuch fließendes Wasser bzw. Wissen zu greifen muss fehlschlagen. [vgl. Rein01, S. 16] Zur vereinfachenden Darstellung formulieren die Autoren: Erkenntnistheoretisch ist diese Kategorisierung, einschließlich der analogen Darstellungsweise, möglicherweise wenig zufriedenstellend, für praktische und empirische Fragen des Wissensmanagements in Organisationen allerdings eine griffige Grundlage für die interdisziplinäre und bereichsübergreifende Zusammenarbeit [vgl. Rein01, S. 12]. Nach North favorisiert das Münchener Modell eine Doppelperspektive auf das Management: Algorithmische Denkmodelle zur Steuerung von Geschäftsprozessen stehen hier neben konstruktivistischen Vorstellungen von Ermöglichen, Fördern und Unterstützen in der Mitarbeiterführung. Bewährte Vorgehensweisen sind in berechenbaren Systemen nicht zu streichen, sondern durch pädagogisch-psychologisches Denken und Handeln zu ergänzen nämlich dort, wo es um Menschen und Kultur und somit um nicht berechenbare Systeme in der Organisation geht. [vgl. Nort02, S. 189] Eine notwendige Bedingung für das Lernen der gesamten Organisation besteht in der Lernbereitschaft und -fähigkeit der beteiligten Individuen. Denn auch für Organisationen gilt, dass der Ort des Wandels allein der Mensch sein kann anders formuliert: Der individuelle Lernzyklus und die ihn begleitenden psychologischen Prozesse sind die Essenz der lernenden Organisation. [vgl. Senge et al in Rein01, S. 7] Die Organisation hingegen bildet den Ort des Handelns [vgl. Senge et al in Nort02, S. 189]. Eine lernende Organisation entsteht, wenn der individuelle und der organisationale Lernzyklus miteinander verbunden werden. [Nort01, S. 189] Die Integration des technisch orientierten Informationsmanagements mit dem Human Ressource-orientierten Kompetenzmanagement wird von [ReMa00; Rein01] im Münchener Modell verfolgt. Mit den vier Phänomenbereichen [vgl. ReMa00; Wett02] 25

50 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Wissensrepräsentation, -nutzung, -kommunikation und -generierung will das Münchener Modell psychologische, organisationale und technische Aufgaben des Wissensmanagement konzeptgeleitet aufeinander beziehen. Communities bilden die Keimzelle des Wissensmanagements und verstärken die Integrationsfunktion des Modells. [Rein01, S. 2] Abb. 2.8: Das Münchener Modell [Wett02, S. 19] Prozesse der Wissensrepräsentation: Dadurch wird Wissen sichtbar, zugänglich, transportierbar und besser begreifbar. Repräsentationsprozesse zielen darauf ab, Wissen einzufrieren, für bestimmte Zeit zu konservieren und zum Auftauen bereit zu halten. Somit ist Wissen mit einer Bewegung verbunden, in der Wissen in Richtung Information geht. [vgl. Nort02, S. 190] Prozesse der Wissensnutzung haben das Potenzial, Wissen in einen Zustand zu bringen, der von Wissensträgern und den dazugehörigen Kontexten kaum mehr zu trennen ist, weil hier aus Wissen Handeln wird. Diese Prozesse machen Wissen anwendbar und lassen dem Wissen Entscheidungen und Handlungen folgen. [vgl. Rein01, S. 20]. In der Analogie des Wassers bedeutet das, Wissen aufsteigen und an geeigneter Stelle kondensieren zu lassen. Prozesse der Wissenskommunikation führen dazu, dass Wissen ausgetauscht, geteilt, vernetzt und in Bewegung gebracht wird. Kommunikationsprozesse bringen Wissen folglich in Bewegung, zum Fließen und sorgen dafür, dass sich dieser Fluss ungehindert fortbewegen und ausbreiten kann. Somit ist Wissenskommunikation Wissensbewegung pur, die in jedem Wissenszustand möglich ist. [Nort02, S. 190] Prozesse der Wissensgenerierung versuchen den Rohstoff Information zu handlungsrelevantem Wissen zu verarbeiten und auf diesem Wege Wissen allein oder zusammen mit Kollegen zu konsolidieren, folglich neues Wissen aufzubauen und dadurch innovative Ideen hervorzubringen [ReMa00]. Man könnte auch sagen, Prozesse der Wissensgenerierung sind in ihrer Eigenschaft als Treiber und Generator Basis jedweder Wissensbewegung, indem sie den Stoff, der bewegt werden soll, erst 26

51 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement hervorbringen. [Rein01, S. 20]. Mit Rückbezug auf die Wasser-Analogie liegt folgender Schluss nahe: Generierungsprozesse sorgen dafür, dass dem fließenden Wasser seine Quelle erhalten bleibt, dass der Fluss nicht dem Schicksal des Versiegens erliegt. [Rein01, S. 21; Wett02]. Das Münchener Modell ist ein prozessorientierter Ansatz, der sich die Gestaltung von Lernprozessen und besonders das organisationale Lernen zur Aufgabe gesetzt hat. Damit es auch in Organisationen zu Prozessen einer kreativen Wissensgenerierung kommt, müssen Menschen Möglichkeiten haben, bestehendes Wissen in Frage zu stellen, noch nicht relevantes Wissen in die Zukunft zu projizieren und Neugier und Kreativität überhaupt ausleben zu dürfen [vgl. Rein01, S. 21]. Menschen sind in ihrem Handeln, Wollen und Glauben meist sehr beharrlich. Wenn also der Mensch als Ort des Wandels gelten kann, heißt das noch lange nicht, dass er diesen Wandel auch eigenverantwortlich und selbstorganisiert anstößt und steuert. [Rein01, S. 8] Motivationalen Anreizen, Kreativität, Communities und Teams sowie dem kulturellen Umfeld wird ein hoher Stellenwert beigemessen [vgl. Rein01, S. 21 u. Nort02, S. 191]. Ein Vorgehensmodell wird nicht vorgestellt, auf die IT als wegbereitende Technologie wird nicht weiter eingegangen. 2.2 Prozessmanagement mit Werkzeugen Zunächst werden Workflow Managementsysteme und die beiden Ansätze Concurrent Engineering und Collaborative Engineering vorgestellt. Im Bereich der Prozessmodellierung und Prozessvisualisierung ist die Methode und das Werkzeug PROMOTE [in AHMM02, S. 457] process-oriented methods and tools for knowledge management [Hink02, S. 66] zu sehen. Diese sind an das Business Process Management System (BPMS) und Business Knowledge Management (BKM) angelehnt [Hink02, S. 68; Thie01; Remu02; Remu02a]. In diesem Kontext stehen auch die Ansätze Business Process Management (BPM) sowie das webbasierte Business Process Management (W-BPM). BPM beschreibt technische Infrastrukturen, mit denen sich Geschäftsprozesse und Anwendungen miteinander verbinden lassen [BPL]. Mit der ARIS Platform for Process Excellence bietet IDS Scheer ein integriertes und vollständiges Werkzeug- Portfolio für Strategie, Design, Implementierung und Controlling von Geschäftsprozessen [ARIS06] Workflow-Managementsysteme Gerade bei repetitiven Projekten werden Prozesse immer stärker durch Workflow- Managementsysteme (WfM) unterstützt. Workflows enthalten eine vordefinierte Reihenfolge von Aufgaben. Dabei ist eine Teilautomatisierung denkbar bzw. werden die Aufgaben durch einen oder mehrere Aufgabenträger ausgeführt. Im Mittelpunkt steht die Kommunikation, da immer die jeweils nächste Person im Prozess davon in Kenntnis gesetzt werden muss, wann sie in Aktion treten soll, so Walker [RDBS02, S. 20]. Ziele bestehender WfM-Werkzeuge sind es, den definierten Innovationsprozess zu steuern, Engpässe aufzuzeigen, zu monitoren sowie Entwicklungszeiten und Entwicklungskosten bei zunehmender Qualität zu reduzieren [vgl. GrPa04; WFMC]. Unter den WfM-Werkzeugen existieren viele praxiserprobte Werkzeuge, die bei der Abbildung, Simulation und Überwachung von Prozessen unterstützen wie z. B. das Werkzeug Arena der Firma Rockwell [Rock06]. 27

52 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Concurrent Engineering und Simultaneous Engineering Entscheidend für die Wettbewerbsfähigkeit eines Produktes sind neben dem hohen Innovationsgrad vor allem eine kurze Entwicklungszeit und ein frühzeitiger Markteintritt. [WaWa91, S. 24] Beim Concurrent Engineering [Bush06] und Simultaneous Engineering [WaWa91; BuWa96; BuWa97] werden Projekte und Prozesse parallel ausgeführt. Ziel dabei ist es, die Entwicklungszeit eines Produktes zu verkürzen und die konsequente Nutzung von Zeitpotentialen. [WaWa91, S. 22] Die Prozesse sind organisatorisch voneinander getrennt, sind sich aber inhaltlich oft ähnlich. Meist handelt es sich dabei um die Produktion von Produktvariationen oder -verbesserungen (...) Dazu ist in diesem Kontext ist ein prozessübergreifendes Wissensmanagement hilfreich. [Bush06, S. 36] Ähnliche Entwicklungsprojekte, die parallel durchgeführt werden, sollen so von den intermediären Ergebnissen, Problemen und Lösungsvorschlägen profitieren. Ziel ist, alle Projekt und Prozessbeteiligte in die Problemlösung einzubinden, lange Diskussionsschleifen zu verhindern und alle Aspekte und Bedürfnisse der Teilnehmer direkt zu berücksichtigen. Gerade im Bereich der Anforderungsmodellierung kann so in frühen Projektphasen Konsens und Konsistenz erreicht werden kann. Abb. 2.9: Überlappender Innovationsprozess: Simultaneous Engineering [Weih05] Traditionelle Innovationsprojekte [vgl. Abb. 2.9] laufen zeitlich getrennt (ohne Überschneidungen der Entwicklungsphasen) ab. Beim Concurrent Engineering überschneiden sich die Phasen und sind zeitlich parallel angeordnet. Auch werden mehrere Entwicklungszyklen, im Sinne von Weiterentwicklungen berücksichtigt, in [Abb. 2.9] durch die vertikalen Korrekturschleifen dargestellt. Simultaneous Engineering zielt nicht allein auf die Synchronisation der Produkt- und Produktionsmittelentwicklung und die intensive Einbeziehung der prozessbeteiligten Stellen ab. Vielmehr muss Simultaneous Engineering als Integrationskonzept [vgl. BuWa96; BuWa97] aufgefasst werden, das durch eine ganzheitliche Betrachtungsweise die Effizienz der Produktentwicklung steigert [WaWa91, S. 24]. Bei 28

53 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement derzeitigen Workflow-Werkzeugen besteht oft keine Möglichkeit, sich über Teil- oder Endergebnisse ähnlicher Prozesse zu informieren. STMicroelectronics analysierte diese Anforderung und entwickelte ein Workflow-Werkzeug, das parallele Prozesse unterstützt und dabei Wissensmanagementaspekte integriert [vgl. Bush06, S. 36]. Aufbauend auf dem Concurrent Simultaneous Engineering (CSE) entwickelten [BuWa96] den integrierten Ansatz, das sog. Concurrent Simultaneous Engineering System (CONSENS) [vgl. BuWa96] Collaboration Engineering Collaboration Engineering [Psch06] beschäftigt sich mit der engen Verzahnung und der Zusammenarbeit von Entwicklungspartnern mit dem Ziel, erfolgreich Innovationen durchführen und etablieren zu können. Pschera geht dabei auf die Notwendigkeit in der Automobilindustrie ein, mehrere räumlich getrennte Partner am Produktentwicklungs- und Beschaffungsprozess zu beteiligen. Dies kann mit dem Werkzeug SupplyOn Collaboration Folder welches virtuelle Projekträume bereitstellt geschehen. In den virtuellen Räumen können sämtliche Projektdaten über Unternehmensgrenzen hinweg effizient verwaltet und ausgetauscht werden. Fast 2000 Unternehmen der Automobilbranche nutzen SupplyOn 2003 im Engineering zur Verwaltung von Normen- und Zeichnungsänderungen. [Psch06, S. 38 u. S. 39] Weiterhin existieren für die virtuelle Zusammenarbeit von Entwicklungspartnern, die über mehrere Standorte verstreut sind, Überlegungen, virtuelle Umgebungen einzurichten, um den Wissens- und Datentransfer zu beschleunigen. So können Innovationen nach dem 8/8/8-Prinzip, in drei Entwicklungsschichten bzw. Zeitzonen zu acht Stunden, rund um die Uhr betrieben werden. Dieses Verfahren wird häufig beim Rapid Prototyping und der Entwicklung von (Steuergeräte-) Software eingesetzt. Eine solche virtuelle Umgebung bietet u. a. der Secure DataRoom der Brainloop AG 13 für hochsicheren Datenaustausch und Dokumentenmanagement in globalen Entwicklungsprojekten [Gaje05, S. 25] Change Management Change Management ist als Teilumfang des Projektmanagements anzusiedeln. Häufig werden bereits in der Angebotsphase von Projekten denkbare Änderungen soweit möglich berücksichtigt. Eine typische Anwendung des Change Managements tritt aber in der Praxis erst ein, wenn ein Projekt nicht länger in der der definierten Zeit, zu gewünschten Kosten oder der definierten Qualität abgeschlossen werden kann. Häufig sind auch Lösungsansätze der Projektpartner nicht realisierbar oder der Erfolg des gesamten Projekts kann aufgrund veränderter Rahmenbedingungen, wie auch nicht betrachteter Ausgangsbedingungen, gefährdet sein. Die Pioniertheorie zum Change Management nach Lewin [Lewi47; Lewi58] mit den Phasen unfreezing, moving und refreezing beschäftigt sich im Rahmen der Organisationstheorie mit den Phasen von Veränderungen. Die Theorie wurde im Rahmen dieser Arbeit für Projekte und Innovationen adaptiert. Als Ausgangspunkt der ersten Phase, die als Phase des Auftauens (engl. unfreezing) bezeichnet wird, besteht die Einsicht, dass die Erwartungen an die zu erbringende Projekt-Leistung nicht mehr der Realität entsprechen. Die Notwendigkeit einer Veränderung tritt langsam als Möglichkeit (bei einem Unternehmen, Experten- oder Projektteam) ins Bewusstsein und altes Verhalten wird in Frage gestellt. Addiert man nun die gewisse und nötige Flexibilität dazu, kann 13 Brainloop AG - 29

54 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement die Bereitschaft für Veränderungen entstehen. Das generelle Ziel dieser Phase besteht darin, die nach Veränderung strebenden Kräfte zu stärken sowie zu unterstützen und so ein Veränderungsbewusstsein (nach Möglichkeit bei allen Projektpartnern) zu induzieren [Lewi58]. Unfreezing steht dabei bildlich für das Auftauen des eingefrorenen Gleichgewichtes (bzw. der gemeinsam definierten Anforderungen auch engl. Requirements). In der zweiten Phase der Veränderungsphase (engl. moving) daher auch Movingphase genannt (gerade bei Innovationen und Projekten als engl. Change Request beschrieben), werden Lösungen generiert, neue Verhaltensweisen ausprobiert und das Problem wird in Teilprojekten gelöst. Der Status-quo (bzw. gemeinsam definierte Methoden, Vorgehensweisen oder die Verwendung beschlossener Technologien) wird verlassen und es wird eine verändernde Bewegung hin zu einem neuen Gleichgewicht (neuen Lösungsansätzen) vollzogen. Ziel der dritten Phase, der Phase der Festschreibung (engl. refreezing) oder Wieder-Einfrieren (bei technischen Entwicklungsprojekten Festschreibung genannt), ist die Implementierung der gefundenen Problemlösungen und damit der zumindest vorläufige Abschluss des Veränderungsprozesses [nach Lewi47]. Ziel ist es, die gemeinsam definierten Kriterien und Anforderungen bei Innovationen festzuschreiben, um nach erfolgreicher Entwicklungsleistung eine Abnahme durch den Auftraggeber zu ermöglichen und diese positive abzuschließen. Change Management besitzt noch weitere entscheidende Dimensionen: Bei Werkverträgen 14, bei denen Entwicklungs-Verzögerungen in Projekten oder bei Innovationen entstehen, werden diese Verzögerungen üblicherweise nicht unmittelbar an den Auftraggeber kommuniziert 15. Weitere zeitliche Verzögerungen entstehen. Die bereits verursachten Mehraufwendungen und Mehrkosten verursacht durch Doppel- und Fehlentwicklungen werden hierdurch noch verstärkt. Entstandene Kosten müssen zwischen den Projektpartnern aufgeteilt werden und erwachsen häufig zum Streitpunkt zwischen Auftraggeber und Auftragnehmer. Konventionalstrafen 16 sind denkbar und gefährden den gemeinsamen Projekterfolg. Ein Risikomanagement 17, verankert im Projektmanagement, kann helfen, derartige Veränderungen, wie hier im Change Management beschrieben, vorherzusehen, frühzeitig zu erkennen oder bereits bei Angebotslegung zu berücksichtigen. Change Management geht also deutlich über rein innovative Aspekte innerhalb von Projekten hinaus PROMOTE Methode und Werkzeug Hinkelmann et al. Hinkelmann entwickelte als Leiter der Forschungsgruppe Wissensmanagement am Deutschen Forschungszentrum für Künstliche Intelligenz und ab 2000 als Professor der Fachhochschule Solothurn in der Nordschweiz Methode und Werkzeug PROMOTE [AHMM02, S. 457]. PROMOTE steht für Pocess-Oriented Methods and Tools for Knowledge Management [Hink02, 66] und ist an die Business Process Management System (BPMS) Methode angelehnt [Hink02, 68]. Zielsetzung von PROMOTE, entwickelt im Rahmen eines EU-Projektes und als Produkt der 14 Werkvertrag im Vergleich zu Dienstverträgen: Bei Werkverträgen übernimmt ein Projektpartner sowohl Risiken als auch unternehmerischer Erfolge. Abnahmen werden in Form von Meilensteinen organisiert. 15 Hintergrund ist, die eigene Kompetenz und das Image zu wahren. Dies variiert sehr stark je nach Unternehmenskultur und auch interkulturellen Unterschieden bei internationalen Unternehmungen, wie z. B. Off-Shore-Projekten. 16 Eine solche Vertragsstrafe (auch Konventionalstrafe oder Konventionsstrafe genannt) ist eine dem Vertragspartner fest zugesagte Geldsumme für den Fall, dass der Versprechende seine vertraglichen Verpflichtungen nicht oder nicht in gehöriger Weise erfüllt. Sie wird auch als Pönale (engl. penalty) bezeichnet. 17 Risikomanagement ist die systematische Erfassung und Bewertung von Risiken sowie die Steuerung von Reaktionen auf festgestellte Risiken. Risikoarten sind u. a. Unternehmensrisiken, Kreditrisiken, Finanzanlagerisiken, Umweltrisiken, aber auch technische Risiken. 30

55 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement BOC GMBH verfügbar, ist die Entwicklung von Methoden und eines Systems zum prozessorientierten Wissensmanagement, welches bestehende Geschäftsprozesse integriert [KaWo02]. Eines der vorrangigen Ziele des PROMOTE-Ansatzes besteht darin, herauszufinden, welche Prozesse der Wissensgenerierung und -suche existieren, wie diese in geeigneter Weise modelliert und mit den Geschäftsprozessen im Rahmen einer Softwarelösung integriert werden können. [Hink02, S. 67] Schmaltz und Hagenhoff beschreiben PROMOTE als Vorgehensmodell zur Einführung von Wissensmanagement sowie als Softwarewerkzeug zur Modellierung von Wissensstrukturen und Geschäftsprozessen. Innerhalb der Prozesse werden wissensintensive Tätigkeiten identifiziert und daraus Wissensflüsse abgeleitet, beschrieben und optimiert. [vgl. ScHa03, S. 21] Hinkelmann, Karagiannis und Telesko zeigen Anwendungsszenarien des Werkzeugs auf [vgl. Hink02]: Unterstützung bei der Bearbeitung von wissensintensiven Aktivitäten in Geschäftsprozessen durch kontextspezifische Aktivierung von Wissensprozessen. Konfiguration von Wissensmanagement-Instrumenten durch Modellierung von Wissenslandkarten und Topic Maps, Koordination von Wissensflüssen oder Aggregation von Wissensmanagementzahlen im sog. Wissensmanagement Cockpit. Unterstützung der Geschäftsprozesse durch Verwaltung von Prozesswissen. Unterstützung von Content Management durch modellbasierte Indizierung und Suche nach Dokumenten mit prozess- und rollenspezifischen Zugriffsrechten. [vgl. Hink02, S. 68] Weiterhin treffen Hinkelmann et al. Grundannahmen [Hink02, S. 69 und Abb. 2.10]: Wissen wird in der täglichen Arbeit in Geschäftsprozessen genutzt. Wissensprozesse können ebenso wie Geschäftsprozesse modelliert werden. Wissen, das in einer Aktivität erzeugt wird, kann in einer anderen benötigt werden. Gronau ergänzt: Die Methode PROMOTE gründet sich auf die Annahme, dass Wissensprozesse zur Transformation von Wissen existieren (z. B. Akquisition, Suche, Retrieval, Speicherung, Verwaltung). Diese sollen analog zu Geschäftsprozessen mit einem Modellierungswerkzeug beschrieben und durch Informationstechnik unterstützt werden. [Gron03, S. 4] Zudem zeigen die Autoren um Hinkelmann vier Arten von Wissensflüssen zwischen wissensintensiven Tätigkeiten auf [vgl. Hink02, S. 70]: (a) Wissensfluss von extern, z. B. durch Schulung, Einstellung von Mitarbeitern mit speziellen Kompetenzen oder Recherche im Internet. (b) Wissensfluss innerhalb der Aktivitäten eines Geschäftsvorfalls, z. B. Hintergrundwissen über den Kunden. (c) Wissensfluss zwischen verschiedenen, auch zeitlich versetzten Instanzen des gleichen Prozesses, z. B. die Übertragung von Erfahrungen und Problemlösungen auf ähnliche Fälle. (d) Wissensfluss zwischen verschiedenen Geschäftsprozessen, z. B. die Berücksichtigung von Fehlermeldungen und Kundenwünschen bei der Produktentwicklung. [Hink02, S. 70] Kernaufgabe des Geschäftsprozessorientierten Wissensmanagements ist es, die Wissensflüsse zwischen den wissensintensiven Aktivitäten oder wissensintensiven Tasks (WIT) [vgl. Gron06] möglichst optimal zu ermöglichen [Hink02, S. 70]. 31

56 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Abb. 2.10: Wissensflüsse zwischen wissensintensiven Tätigkeiten [Hink02 in Gron06, S. 7] Die PROMOTE-Vorgehensweise basiert auf einem Top-Down-Ansatz. Zunächst werden strategische Ziele definiert, im nächsten Schritt die relevanten Wissensprozesse identifiziert. Diese werden im weiteren Vorgehen detailliert erfasst und modelliert. Im nächsten Schritt wird das PROMOTE-System implementiert, dabei geht es vorrangig um die Gestaltung der organisationsbezogenen Wissensbasis und der Szenarioentwicklung für die Unterstützung von Wissensprozessen durch IT. [Gron03, S. 4] Hinkelmann et al. beschrieben die Phasen der PROMOTE-Methodologie: 1. Aware Enterprise Knowledge: Festlegen von Zielen, Kernkompetenzen, Risiken und Geschäftsprozessen. 2. Discover Knowedge Process: Identifikation von kritischen Aufgaben und Wissensträgern; Definition der Wissensmanagement-Instrumente. 3. Modelling Knowledge Process and Organisational Memory: Beschreibung von Unternehmenswissen mit (prozessorientierten) Modellen. 4. Making Knowledge Process and Organisational Memory operational: Koordinieren der Wissensmanagement-Instrumente. 5. Evaluate Enterprise Knowledge: Evaluieren der Veränderungen bei der Durchführung von Geschäftsprozessen und bei den Wissensträgern. Die erste Phase legt die strategischen Wissensziele fest. Die Phasen zwei bis vier beziehen sich auf die Planung und Ausführung der operativen Wissensmanagementaktivitäten, die direkt mit den Geschäftsprozessen verknüpft sind. Phase fünf unterstützt das integrierte Controlling und die Identifikation von Schwachstellen in Geschäfts- und Wissensprozessen [Hink02, S. 74]. PROMOTE verfügt über ein Vorgehensmodell sowie eine implementierte Lösung. Zur Modellierung der Prozesse mit dem Werkzeug PROMOTE wird allerdings empfohlen, einen Experten heranzuziehen. Auch liegen keine Erfahrungen bei der Modellierung von unstrukturierten Prozessen vor. Als Beispiel der Prozessmodellierung wird bei Hinkelmann et. al. die Vergabe eines Kredits herangeführt ein wohlstrukturierter Prozess. Hilfreich bei der Unterscheidung von Wissensflüssen und wissensintensiven Tätigkeiten wurde eine Abgrenzung bzw. Klassifikation eingeführt. Hinkelmann schreibt: Der Aufbau und die Pflege spezifischer Kernkompetenzen kann einem Unternehmen einen Wettbewerbsvorsprung eröffnen [Hink02, 75]. Auf die Herausforderung, Mitarbeiter für das Wissensmanagement zu sensibilisieren und zur aktiven Teilnahme am Wissensaustausch zu motivieren, beziehen die Autoren keine Stellung. 32

57 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Expertise Platform, Finebrain AG Die Expertise Platform Finebrain AG 18 ist bereits in einigen Unternehmen implementiert. Im Rahmen dieser Arbeit wurde die Plattform bei einem Automobilhersteller, in der Betriebsphase, eingesehen. Finebrain ist Mitglied im europäischen Semantic Web Konsortium Virtual Information and Knowledge Environment Framework 19 (VIKEF). Unter dem Motto schnell finden statt lange suchen bietet Finebrain Lösungen im Bereich des Expertise Managements. Im besuchten Unternehmen werden im F&E Bereich aus verschiedenen Abteilungen stammende Informationssysteme und die darin beinhaltete Information mit den Menschen im Unternehmen vernetzt. Dadurch wird die automatisierte und intelligente Vernetzung von Fachinformation und Experten hergestellt. Die Lösung für ein Großunternehmen im Automobilsektor wurde auf Basis der Finebrain Expertise Platform mit Integration der Xerox Annotation Pipeline entwickelt. Die Finebrain Software beschlagwortet und verknüpft automatisch Inhalte mit Themenstrukturen (sog. Taxonomien). Die für die einzelnen Themen relevanten Personen werden automatisch benachrichtigt (Informations-Push). Zudem verbindet die Software Inhalte aus unterschiedlichsten Quellen über eine gemeinsame Themenstruktur. Die Inhalte werden damit navigier- und auffindbar, unabhängig davon, ob es sich dabei um interne oder externe Quellen und Inhalte handelt (engl. Taxonomy-based Content Integration). Kombiniert mit der automatischen Erfassung und Strukturierung von Inhalten im (offenen) Internet, womit diese für den individuellen Unternehmenszweck gefiltert und nutzbar gemacht werden (engl. Virtual Content Integration), eröffnet die Finebrain Technologie 20 aktuellsten Zugang zur relevanten Information. Abb. 2.11: Finebrain Expertise Plattform [www.finebrain.com] Navigieren die Benutzer über die Wissenslandkarte in einen Themenbereich, dann wird ihnen die kontext-relevante Information angezeigt. Klicken die Benutzer auf eine Information, so werden neben dem eigentlichen Inhalt auch entsprechende Meta-Information, wie z. B. verwandte Themen, wichtige Dokumente, empfohlene Experten etc. angezeigt. Benötigen die Benutzer individuelle Information oder Antworten von Experten, so werden seine Fragen direkt per Mail dem richtigen Ansprechpartner notifiziert. Die Frage mit zugehöriger Antwort wird zusammen mit dem jeweiligen Kontext im Finebrain- System verwaltet. 18 Homepage der Finebrain AG in der Schweiz VIKEF Details zur Verwendung der Finebrain Technologie - 33

58 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Bei dem besuchten Automobilhersteller wird die Expertise Plattform Finebrain zur Technologiebeobachtung hinsichtlich des Themas Wasserstoff eingesetzt. Dazu wurden Benutzergruppen angelegt, denen z. B. Leserechte, zugewiesen werden. Sowohl die Themengebiete innerhalb der Domäne Wasserstoff als auch die Experten werden als Taxonomien repräsentiert. Relevante Newsletter, z. B. vom Verein Deutscher Ingenieure 21 (VDI), werden dort nur ein einziges Mal angefordert und zentral in der Expertise Plattform abgelegt. Die Expertengruppe, für die diese Information relevant ist, wird per Mail über den Zugang eines neuen Dokuments informiert. Die Experten können das Dokument bei Interesse einsehen und die Netzlast wird durch den Wegfall der Verteilung umfangreicher Dokumente reduziert. Zudem werden Dokumente mit einem Status versehen, der z. B. auf publiziert und/oder gültig, lauten kann. Interessant ist auch der Ansatz innerhalb der Expertise Plattform, Kontaktdaten von Zulieferern und Kunden zu verwalten, die zudem mit Angaben zum letzten Kontakt sowie zum Initiator dieses Kontakts angereichert werden. Abschließend bleibt festzuhalten: Experten betreuen Themen und legen dazu Themengruppen und Untergruppen an. Der Experte entscheidet, welche Mitarbeiter einer Gruppe beitreten können. Mehrfachnennungen in unterschiedlichen Gruppen sind möglich. Allerdings sind nur die Experten befugt, Fragen innerhalb der Themengruppe zu beantworten. Anzumerken ist, dass der Aufbau der Themengruppe innerhalb der Expertise Plattform hierarchisch ist und als Taxonomie verstanden werden kann. Ein ontologischer Ansatz konnte nicht identifiziert werden. 2.3 Innovationsmanagement und organisatorische Instrumente Die folgenden Methoden des Innovationsmanagements sind aufgrund der hohen Komplexität nicht als käufliche Produkte verfügbar, sondern müssen als Strategie oder eben organisatorische Instrumente verstanden werden. Sichtweisen und Ansätze werden dargelegt und sollen zur wissenschaftlichen Reflektion anregen Wissens- und Innovationsmanager WiPro WiPro 22 ist ein multimedialer Werkzeugkasten für das wissensbasierte Produktinnovationsmanagement in kleinen oder mittelständischen Unternehmen (KMU) [vgl. WiPro ist ein Verbundprojekt, das im Rahmen des Programms Wissensmedia durch das Bundesministerium für Wirtschaft und Arbeit 23 gefördert wird und an der RWTH Aachen entsteht. WiPro befindet sich noch in der Entstehungsphase, folgende Ziele 24 sollen mit dem Werkzeug verfolgt werden: Entwicklung von Referenzmodellen, die den Soll-Zustand des Wissensmanagements in der Produktinnovation abbilden. KMU spezifische Lösungen für die Erfassung, Strukturierung und Visualisierung der Wissensflüsse im Innovationsprozess werden erarbeitet. Die so gewonnene Transparenz ermöglicht den Vergleich des unternehmensspezifischen Ist-Zustands mit dem Referenzmodell. Zudem können so Handlungsbedarfe abgeleitet werden. Erstellung einfacher Methoden und Instrumente für die Erweiterung und Pflege der Wissensbasis, für die bedarfsgerechte Verteilung von Wissen im Prozessablauf und für die verbesserte Nutzung von Wissen, die für KMUs unterschiedlicher Größe geeignet sind. Die Verbreitung von Wissen über Wissensmanagement soll gefördert werden, indem eine 21 Verband Deutscher Ingenieure Heute Bundesministerium für Wirtschaft und Technologie Die Ziele von WiPro sind einsehbar im Online Forum - 34

59 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Software sofort interaktiv anwendbare Wissensmanagementlösungen bereit stellt und diese um multimedial präsentierte Information (z. B. zu Zielen, Wirkungsweisen, Anwendungszusammenhängen oder Alternativen) ergänzt. Als Kernfunktion kann zu einzelnen projektspezifischen Prozessphasen aus den rund 100 Methoden des Wissens- und Innovationsmanagements gewählt werden. Zu den Methoden gibt es multimediale Präsentationen, um deren Arbeits- und Wirkungsweise in der aktuellen Prozessphase einschätzen zu können Anreizsysteme Als Anreizsysteme werden in der betrieblichen Praxis zumeist monetäre Vergütungssysteme verstanden. Diese sollen die Mitarbeiter motivieren, im Sinne des Unternehmens, pro-aktiv zu handeln und somit die Unternehmensziele zu fördern. [Sema05, S. 8] Diese Anreiz- und Vergütungssysteme sind meist leistungsbezogen, auf die Arbeitsleistung der Mitarbeiter, ausgerichtet [Merg99; Sema05, S. 8]. Zwischen den Zielen der Organisation und des Individuums soll durch den bewussten Einsatz von Anreizen eine Übereinstimmung erzielt werden. Grundsätzlich sind intrinsische Motive wie Anerkennung und Eigeninitiative nachhaltiger als monetär oder materiell gesetzte Anreize zur Wissensfreigabe [Merg99; Sema05]. Mergel verschafft einen Überblick über Bedürfnisse, Motive, Anreize und Anreizsysteme im Wissensmanagement. Anreizsysteme im Bereich des Wissensmanagements sind schwer zu definieren. Das liegt daran, dass es äußerst anspruchsvoll ist, relevantes Wissen und den Wert von Wissen zu bestimmen. Ein Gegenwert in Form eines Anreizes kann deshalb nicht einheitlich vergeben werden. In der Wissensbewertung liegt der Kern des Problems [vgl. Merg99]. Das System K3 von Kuhlen stellt einen hilfreichen Ansatz vor: K3 bewertet über ein flexibles Anrechnungsverfahren (Credit-/Rating-System) Beiträge von Studenten in einer wissenschaftlichen Lernumgebung [Sema05]. Zur Bewertung der Qualität der Einträge bedarf es weiterhin des Urteils der User bzw. der Experten. Unabhängig von der Bewertung können geeignete Anreizsysteme die Wissensarbeit sowie die Sensibilisierung für Wissensaspekte im betrieblichen Umfeld positiv beeinflussen [vgl. VoHe06a] Balanced Scorecard Die Balanced Scorecard (BSC) nach Kaplan/Norton dient als Führungsinstrument zur Ausrichtung der Organisation an strategischen Zielen in den unterschiedlichen Perspektiven (Finanzen, Kunden, Prozesse, Mitarbeiter). Im Gegensatz zu Unternehmensleitbildern und anderen unscharfen Formulierungen versucht die Balanced Scorecard die Erreichung von strategischen Zielen messbar und über die Ableitung von Maßnahmen umsetzbar zu machen. Im Gegensatz zu klassischen Kennzahlensystemen lenkt die BSC den Blick über die unterstellten Ursache-Wirkungs-Zusammenhänge aber auch auf nicht-finanzielle Indikatoren. [BSC; KaNo01, S. 88ff.; KaNo04; Bürg07, S. 43; KrAr08;] Die BSC bietet für Unternehmen einen praxistauglichen Ansatz zur Bewertung kaum oder schwer messbarer Ressourcen, z. B. von Wissen. Die Balanced Scorecard (BSC) ist eine ganzheitlich orientierte, ziel- und kennzahlenbasierte Managementmethode. Vision und Strategie eines Unternehmens werden auf Ziele und Kennzahlen in meist vier Bereichen (Finanzen, Kunden, interne Geschäftsprozesse, Lernen und Entwicklung) abgebildet [KaNo04]. Dadurch soll eine einseitige Ausrichtung auf finanzielle Aspekte vermieden und eine Ausgewogenheit erreicht werden Total Productive Maintenance Im Total-Productive-Maintenance (TPM)-Konzept von Specht und Mieke werden als zentrale Innovationsgegenstände Produktinnovationen und Prozessinnovationen vorgestellt [SpMi05]. 35

60 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Technologie getrieben sind beide, darüber hinaus sind Produktinnovationen marktgetrieben und Prozessinnovationen organisationsgetrieben. Gerade im Instandhaltungsbereich von Produktionsabteilungen wird bemängelt, dass wichtiges Wissen zur Ausführung originärer Aufgaben sowie zur Generierung von Innovationen im Bereich der Prozesstechnologie fehlt [SpMi05]. Daran wird ersichtlich, dass häufig Prozessinnovationen aus organisatorischer Sicht nicht ausreichend gewürdigt werden Lessons Learned Arbeitsorganisatorisch bedarf es Überlegungen zu Lessons Learned (LL), da sie jedes Projekt begleiten bzw. dieses zeitlich überdauern oder darüber hinaus einen Mehrwert für Innovationen stiften können gezogene Lehren oder auch gesammelte Erfahrungen (engl. Lessons Learned) ist ein Fachbegriff des Projektmanagements und Wissensmanagements. Bezeichnet wird das systematische Sammeln, Bewerten, Verdichten und die schriftliche Aufzeichnung von Erfahrungen, Entwicklungen, Hinweisen, Fehlern, Risiken etc., die in einem Projekt gemacht werden und deren Beachtung/Vermeidung sich unter Umständen als nützlich für zukünftige Projekte erweisen könnte. [LeLe06] Lessons Learned wurden erstmalig bei Großprojekten der Luft- und Raumfahrtindustrie eingesetzt und später in die Projektorganisationen aller fertigenden Industrien, u. a. auch in die Automobil- und Zulieferindustrie übernommen. Die Lessons Learned, sollten Teil der Projektabschlussdokumentation sein. Das sind zunächst unstrukturierte Informationssammlungen die für das das abgeschlossene Projekt kaum noch hilfreich sind [LeLe06]. Bei Beratungsprojekten spricht man auch vom De-Briefing [VoHe06]. Projektmanagement und Lessons Learned werden in vielen Ansätzen gemeinschaftlich betrachtet. Pannek fordert, Wissensmanagement als festen Bestandteil in Projekten zu implementieren und so einen Regelkreis von Wissensbewahrung und wiederverwendung zu schließen [Pann05]. Dazu schlägt er die IT-gestützte Wissenssicherung und wiederverwendung mit ProX vor, um so zukünftig auf De-Briefing Erfahrungen, Lessons Learned, Best-Practices und Handlungsempfehlungen zurückgreifen zu können [Pann05]. Unternehmen der Automobilindustrie überführen gewonnene Erkenntnisse in unternehmensweite Standards, wie z. B. den GroupStandard oder im Bereich der Software den StandardCore, beide bei der BMW AG im Einsatz. Diese Standards haben unternehmensweite Gültigkeit und werden zwingend bei allen zukünftigen Innovationen eingefordert Produktlebenszyklusmanagement Produktlebenszyklusmanagement (PLM) ist als der Vorreiter des Informationslebenszyklusmanagement (ILM) und des Lebenszyklus des Innovationswissens (engl. innovation knowledge life cycle, IKLC) [Pauk03; PaNH04; PaNH04a] zu sehen. PLM (engl. product lifecycle management) bezeichnet ein IT-Lösungssystem [vgl. PLM06], mit welchem alle Daten, die bei der Entstehung, Lagerhaltung und dem Vertrieb eines Produkts anfallen, einheitlich gespeichert, verwaltet und abgerufen werden. Im Idealfall greifen alle Systeme, die mit einem Produkt in Berührung kommen, auf eine gemeinsame Datenbasis zu und dies von der Planung (PPS/ERP) über Konstruktion (CAD), Fertigung (CAM) bis zum Controlling, Vertrieb und Service [vgl. PLM06]. Dieser Gedanke wird durch das Informationslebenszyklusmanagement von Produkten und deren Produktdaten, -information und -wissen übertragen. ILM (information lifecycle management) sind Strategien, Methoden und Anwendungen, um Information automatisiert, entsprechend ihrem Wert und ihrer Nutzung, optimal auf dem jeweils kostengünstigsten Speichermedium bereitzustellen, zu erschließen und 36

61 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement langfristig sicher aufzubewahren. [Info06] Laut der Storage Networking Industry Association (SINA) besteht ILM aus Richtlinien, Prozessen und Technologien, mit denen Information gemäß ihrem Wert für das Unternehmen, vom Zeitpunkt ihres Eintritts bzw. Entstehens, bis zur endgültigen Nutzung auf einer geeigneten IT-Infrastruktur abgelegt werden [Wedl06]. Weiterführend werden ILM-Strategien verwendet, um Information und Wissen im weiteren Sinne definiert als Inhalte (engl. Content) so zu klassifizieren, damit diese automatisch hierarchisch abgelegt bzw. aufbereitet werden können. Wedlich empfiehlt weiter, für die Inhalte vom Einklang über Klassifizierung und Ablage bis hin zur Migration, Archivierung und Löschung einen automatischen, technologieübergreifenden Prozess zu etablieren. [vgl. Wedl06, S. 21; DMS04]. Diese Analyse zum Stand der Wissenschaft und Technik von Prozess- und Wissensmanagement wurde als Bestandteil des Beitrags: Heranführung an Wissensbasiertes und Prozessorientiertes Innovationsmanagement anhand von Herausforderungen in dynamischen Innovationsprozessen komprimiert veröffentlicht und diskutiert [VoHe06a, S ]. 2.4 Sprachen und Notationen zur Modellierungen von Prozessen Bei den Modellierungssprachen zur Abbildung von statischen Prozessmodellen sind die Methoden Entity-Relationship-Modell (ERM), strukturiertes ERM (SERM), Semantisches Objekt-Modell (SOM) sowie die Ansätze der Algebren, Kalküle und die Mengenlehre [FeSi98, KaKl05] zu nennen. Im Folgenden ein Überblick zu Modellierungssprachen für Prozesse und insbesondere Innovationsprozesse. Business Process Modeling Language (BPML), Business Process Execution Language (BPEL), BPEL for Web Services (BPEL4WS) und Business Process Modeling Notation (BPMN) dienen zur Repräsentation und Modellierung von Prozessen BPM mit BPD Business Process Management (BPM) ist ein systematischer Ansatz, Geschäftsprozesse effektiv und effizient an veränderliche Umgebungen anzupassen [www.bpmi.org]. Van der Aalst beschreibt dieses technischer: Business-Prozess Management beinhaltet Methoden, Techniken und Werkzeuge, die in den Phasen Durchführung, Steuerung und Analyse von operativen Geschäftsprozessen unterstützen [Aals03]. Die Diagramme in der Business Process Modeling Notation (BPMN) nennen sich Business Process Diagramme (BPD). So einfach diese durch Menschen gezeichnet oder interpretiert werden können, so schwer fällt es Computern, die grafische Notation direkt für die Ausführung eines Geschäftsprozess zu übernehmen. Maschinen-lesbare Prozessbeschreibungen sind insofern meistens in sogenannte Ausführungssprachen für Geschäftsprozesse festgehalten zum Beispiel in der Business Process Execution Language (BPEL) oder in der XML Process Definition Language (XPDL), beides XML-Anwendungen für die Beschreibung von Prozessen. BPMN, BPEL und XPDL ergänzen sich gegenseitig, indem BPEL und XPDL dort eingesetzt werden, wo BPMN Defizite aufweist [BPMN]. So definiert der BPMN-Standard, wie ein BPMN-Diagramm in BPEL übersetzt wird, damit die beschriebenen Prozesse durch einen Computer ausgeführt werden können. Eine analoge Transformation definiert die Workflow Management Coalition (WfMC) für BPMN und XPDL [vgl. BPMN]. Abbildungen auf weitere Sprachen, wie zum Beispiel auf ebxml Business Process Specification Schema, sind geplant, aber noch weniger weit fortgeschritten BPML Die Business Process Modeling Language (BPML) ist eine Meta-Sprache zur abstrakten Modellierung von Geschäftsprozessen. Somit beschreibt BPML keine konkreten Prozesse, 37

62 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement sondern vielmehr, wie Prozesse mithilfe dieser Sprache bzw. Notation modelliert werden sollen. Ein zugehöriges, abstraktes Ausführungsmodell beschreibt, wie die Zusammenarbeit und Ausführung verschiedener Geschäftsprozesse erfolgen kann. In BPML wird eine große Anzahl von Aktivitäten verbunden und zu einem Prozess zusammengefasst, wobei ein Prozess aus mehreren Teilprozessen zusammengesetzt sein kann. Nach Auffassung der BPMI besteht ein E- Business-Prozess mit zwei Teilnehmern aus einer öffentlichen Schnittstelle, die beiden Businesspartnern gemeinsam ist, und zwei privaten Implementierungen eine für jeden Geschäftspartner. Zur Beschreibung der privaten Implementierungen wird BPML verwendet. Die öffentliche Schnittstelle wird von Protokollen wie zum Beispiel ebxml 25, RosettaNet 26 und BizTalk 27 unterstützt. Auf den öffentlichen Plattformen müssen die zwei Teilnehmer ihre privaten Implementierungen veröffentlichen und ausführen können. Eine solche Plattform wurde von der BPMI 28 erstellt, nämlich die Business Process Query Language 29, in welche auch ein standardisierter Zugang zur Universal Description, Discovery and Integration (UDDI) integriert ist [vgl. DOno07, S. 4] BPEL Bisherige Ablaufmodelle unterstützten nur die Abbildung von Prozessen, nicht aber deren Ausführung und auch nicht das Einführen von Regeln. Diese Funktionen können auch nicht nachträglich integriert werden somit ging bisher bei der Prozessanalyse und Dokumentation sehr viel Energie verloren. Ziel musste es somit sein, eine Sprache zu entwickeln, welche die Ausführung der Funktionen unterstützt. BPEL ist ein sehr mächtige Sprache, namentlich die Business Process Execution Language. Weiterhin ist BPEL eine XML-basierte Sprache alle Aktivitäten sind als WebServices implementiert. Folglich wurde diese Sprache für Rechner und nicht den Menschen entwickelt. BPEL gilt heute als Standard und gerade vom Standpunkt des Datenmanagements als eine sehr komplexe Spezifikation. Besonders die Synchronisation von BPEL und Web Services Description Language (WSDL) Files sorgte für Probleme. Eine Higher- Level-Notation für BPM Projekte wurde benötigt. Die Sprache BPML sollte durch BPEL abgelöst werden. Da sich kein gemeinsamer Standard finden konnte, wurde BPMN, BPM und BPM 2.0 entwickelt BPEL4WS Die Business Process Modeling Notation (BPMN 30 ) ist eine grafische Notation zur Beschreibung von Geschäftsprozessen in einem Business Process Diagram (BPD). BPMN ist eine Notation, die sowohl für Betriebsanalysten als auch für Programmierer verständlich ist [Whit03]. Zudem sollen einfache Prozesse schnell und pragmatisch darstellbar sein und gleichzeitig die grafischen Werkzeuge zur Verfügung stehen, um komplexe Abläufe wiederzugeben [BPMI06]. In der von der Business Process Modeling Initiative (BPMI) in Zusammenarbeit mit dem Object Management Group (OMG) erarbeiteten Spezifikation werden die Sprachelemente und die Semantik von BPMN definiert, wie auch das Mapping zu der XML-basierten Sprache Business Process Execution Language for Web Services (BPEL4WS). BPMN entspricht somit auch der Visualisierung von BPEL4WS. Ein BPD enthält wesentlich weniger Information als die für elektronische Geschäftsprozess-Transaktionen sowie die Erweiterung der betrieblichen Supply Chain. 27 BizTalk - - BizTalk Server dienen der Integration, Verwaltung und Automatisierung von Geschäftsprozessen innerhalb eines Unternehmens, indem sie elektronische Nachrichten abrufen, konvertieren und die Kommunikation zwischen den verschiedenen Systemen durchführen und überwachen. 28 Business Process Management Initiative (BPMI) BPMN - 38

63 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement entsprechende Beschreibung in BPEL4WS, denn ein BPD, das sämtliche Information aus der BPEL4WS Beschreibung enthalten würde, wäre zu unübersichtlich. Trotzdem ist diese Information für eine korrekte Übersetzung nach BPEL4WS nötig. Deshalb wird ein BPD, das in BPEL4WS übertragen werden soll, mit einer Modellierungsanwendung gezeichnet, welche das Eingeben der zusätzlichen, für die BPEL4WS Beschreibung erforderlichen Information im Hintergrund erlaubt BPMN Die Business Process Management Initiative trifft folgende Aussage: A standard Business Process Modeling Notation (BPMN) will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner. Furthermore, the graphical notation will facilitate the understanding of the performance collaborations and business transactions between the organizations. This will ensure that businesses will understand themselves and participants in their business and will enable organizations to adjust to new internal and B2B business circumstances quickly. [BPMI 31 ] Die Business Process Modeling Notation (BPMN 32 ) ist eine grafische Spezifikationssprache und entstammt der Wirtschaftsinformatik (WI). Diese Sprache stellt Symbole zur Verfügung, mit denen Fach- und Informatikspezialisten Geschäftsprozesse modellieren können [BPMN]. Die BPMN wurde 2002 durch Stephen A. White, Mitarbeiter von IBM, erarbeitet und durch die Business Process Management Initiative (BPMI), einer Organisation, die Standards im Bereich Geschäftsprozessmodellierung definiert hatte, veröffentlicht. Sie wurde im Juni 2005 durch die Object Management Group zur Weiterentwicklung übernommen. Die BPMI fusionierte parallel mit der OMG, sodass die BPMN ähnlich wie die Unified Modeling Language (UML) zum Standard der OMG wurde. Der Schwerpunkt der BPMN liegt auf der Notation, das heißt, auf der grafischen Darstellung von und zu Geschäftsprozessen. Der Standard zur BPMN definiert auch die Semantik (Bedeutung der Symbole), aber er misst diesem Aspekt weniger Gewicht bei und legt keinen Wert auf formale Definitionen. Über ein standardisiertes Format für die Speicherung und den Austausch von Diagrammen der BPMN schweigt sich die Spezifikation gänzlich aus. Eine Erweiterung zum BPM wird durch das Semantic Business Process Management (SBPM) vorgeschlagen: Business Activity Monitoring (BAM) enables continuous, real-time performance measurement of business processes based on key performance indicators (KPI). The performance information is employed by business users but prior support from IT engineers is required for setting up the BAM solution. Semantic Business Process Management (SBPM) tries to minimize the needed support from IT staff throughout the business process lifecycle. [WeML08] Die Grundlegenden Konzepte von BPMN 33 : Eine Activity beschreibt dabei eine Aufgabe, die innerhalb eines Geschäftsprozess zu erledigen ist. Diese wird dargestellt als Rechteck mit abgerundeten Ecken. Aus elementaren Aktivitäten werden durch Kombination komplexere Aktivitäten, auch als Subprozesse bezeichnet, generiert. Subprozesse unterscheiden sich innerhalb der Notation durch ein + Symbol und können in kollabiertem oder expandiertem Zustand dargestellt werden. [vgl. Whit04] Ein Gateway stellt einen Entscheidungspunkt dar, an dem verschiedene Kontrollflüsse 31 BPMI Wikipedia.de Suchbegriff BPMN

64 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement zusammentreffen [Whit04]. Dieses Gateway wird als Raute dargestellt. Je nach Symbol im Inneren der Raute steht diese für einen AND-, einen OR-, einen XOR- oder einen Eventbasiertes Gateway [Allw08]. Ein Event ist ein Ereignis, das sich in einem Geschäftsprozess ereignen kann. Das kann z. B. das Eintreffen eines Briefes, das Erreichen eines bestimmten Datums oder das Auftreten einer Ausnahmesituation sein [vgl. BPMN]. Events werden nach zwei Klassifikationen eingeteilt: Nach ihrer Position innerhalb des Geschäftsprozesses, in Start-, Intermediate- und End- Event [BPMN]. Nach ihrer Art in Timer-, Message-, Exception-Event. Dazu wird in der Notation ein eigenes Symbol, das im Innern des Kreissymbols steht, für den Event verwendet [BPMN]. Swimlanes: BPMN unterstützt die Orchestrierung von Web-Services, die Ausführung von Workflow Tasks (Aufgaben) durch menschliche Mitarbeiter, und die parallele und multiple Ausführung von Geschäftsprozessen durch die sog. swim lane Metapher [Allw08]. Wobei einzelne Prozesssequenzen unabhängig vom Kernprozess ausgeführt werden können und nach deren Beendigung an den Kernprozess berichten bzw. die Steuerung übergeben. BPMN wird von den Schwergewichten in der Industrie unterstützt, wie z. B. IBM, somit konnte eine Umsetzung des Standards bewirkt werden [vgl. Whit04; Allw08]. 2.5 Visuell-gestützte Prozess-Modellierungswerkzeuge Veranschaulicht werden Modellierungswerkzeuge, insbesondere zur softwaregestützten Modellierung von Prozessen, mit visuell-gestützten Benutzungsoberflächen. Die Modellierungs- Werkzeuge werden zunächst untersucht und dahingehend überprüft, ob sie für die Modellierung von WPIM-Prozessen geeignet bzw. zu den Implementierungen der WPIM-Pipeline kompatibel sind. Anhand eines Kriterienkatalogs wird eine Vorselektion getroffen. Als Kriterien werden die Verfügbarkeit der Werkzeuge ohne Lizenzkosten, darin bereitgestellte Exportfunktionen der Modelle in standardisierte Austauschformate und insbesondere in das XML- Datenaustauschformat untersucht Visio, Microsoft Visio ist eine Visualisierungssoftware entwickelt von Microsoft. Visio unterstützt bei der rechnergestützten Visualisierung verschiedener betrieblicher Abläufe. Hierzu stehen eine Vielzahl von Vorlagen, Symbolen, Gegenstandstypen und Beziehungen bereit, die mit passenden Werkzeugen per ziehen und fallenlassen (engl. drag and drop) in ein Dokument integriert werden können. Prädestiniert ist Visio für Flussdiagramme, Workflows und Geschäftsprozesse. Gerade Flussdiagramme sind in der Informatik beliebt, um den Ablaufplan eines Programms zu skizzieren. Auch die Erstellung einfacher technischer Zeichnungen wird unterstützt. Bestehende Prozessmodelle der Entwicklung können dort weiterverwendet werden bzw. das Abbilden noch nicht visualisierter Prozesse wird sehr gut unterstützt. Visio bietet hohe Kompatibilität für die Zusammenführung bestehender Prozesse und genießt hohe Akzeptanz in Unternehmen, da es bei vielen Automobilherstellern bereits aktiv genutzt wird. Kostenlose Anwendungen mit vergleichbarer Funktionalität bestehen mit Dia (Gnome) oder Kivio (KDE) [VISI]. Visio ist ein bedeutendes Werkzeug zur Prozessmodellierung. Leider ist das Datenmodell nicht einsehbar und der Quellcode von Microsoft geschützt. Somit ist es nicht möglich, die Daten zu manipulieren. Die Datei wird im speziellen Visio Format.vsd abgelegt. Prozessmodelle lassen sich sehr einfach abbilden und Relationen sind mit magnetischer Hilfsfunktion zu setzen. Eine Benennung der Relationen ist nicht vorgesehen, ebenso wenig wie die Integration semantischer Beziehungen oder von Meta-Daten. Noch anzumerken ist: In Visio können zu einzelnen Prozessbausteinen Ressourcen bzw. Restriktionen abgelegt werden. Somit kann z. B. bei der Abbildung eines zeitkritischen Prozesses für den kritischen Pfad, also die Prozessfolge, bei der es keinesfalls 40

65 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Verzögerungen bei der Durchführung geben darf (vgl. Netzplantechnik), eine Maximaldauer angegeben werden. Diese Unterfenster ermöglichen es, zu kritischen Ressourcen (im Projektmanagement Zeit, Kosten, Qualität) Restriktionen zu hinterlegen. Eine Ablauf-Simulation des Prozesses über diese Werte ist nicht möglich. Das ist nur Hintergrundinformation, die einzeln abgerufen werden muss. Zur Anreicherung von Innovationsprozessen stehen keine Strukturen oder Such- und Gliederungsoperatoren zur Verfügung. Visio ist einfach handhabbar bei der Modellierung und Visualisierung von Prozessen, deren Umgestaltung, Reduktion und Erweiterung. Als Nachteile sind zu sehen, dass weder ein direkter Zugriff auf die Datenstruktur möglich ist, noch können Meta-Daten zu einzelnen Prozessbausteinen hinzugefügt werden auch können Relationen nicht benannt bzw. semantisch benannt werden. Für Visio wird eine Reihe von Plug-ins angeboten. Eine solche Rucksacklösung erscheint für den breiten Einsatz in Forschungs- und Entwicklungsabteilungen der Automobilbranche wenig geeignet. Eine Simulation bzw. automatische Durchführung der Aufgaben in einem Geschäftsprozess, wie z. B. einem Innovationsprozess, wird nicht unterstützt weder in der Standard- noch in der Professional-Edition ARIS, IDS Scheer Das ARIS-Konzept (Architektur integrierter Informationssysteme) von Scheer 34 soll erreichen, dass ein betriebliches Informationssystem vollständig seinen Anforderungen gerecht werden kann. Dieser Ordnungsrahmen geht von einer Aufteilung des Modells in Beschreibungssichten und -ebenen aus, die eine Beschreibung der einzelnen Elemente durch dafür speziell vorgesehene Methoden ermöglicht, ohne das gesamte Modell einbeziehen zu müssen. ARIS stützt sich hauptsächlich auf seine eigene Fünf-Sichten-Architektur [vgl. Aris06], das sog. ARIS- Haus. Diese fünf Sichten sind die Organisations-, Daten-, Leistungs-, Funktions- und Steuerungssicht auf einen betrieblichen Geschäftsprozess. Die Einteilung erfolgt, um die Komplexität des Modells in fünf Facetten aufzubrechen und so die Prozessmodellierung und Übersichtlichkeit einfacher zu gestalten [vgl. Ghal06]. Jede der fünf Sichten des ARIS- Konzeptes gibt das Modell eines betrieblichen Geschäftsprozesses unter einem bestimmten Aspekt wieder [vgl. Aris06]: Funktionssicht: Alle funktionalen Elemente, ihre Gruppierungen und hierarchischen Beziehungen im entsprechenden Funktionsbaum. Organisationssicht: Alle Ressourcen, wie z.b. menschliche Arbeitskräfte, Maschinen, Hardware sowie alle Organisationseinheiten/Abteilungen und ihre Beziehungen im Organigramm. Datensicht: Alle Ereignisse, die Daten oder Kontextdaten generieren, wie Schriftwechsel und Dokumente. Das sind somit alle unternehmensrelevanten Informationsobjekte. Leistungssicht: Alle Dienst-, Sach- und finanziellen Leistungen [Aris06; Ghal06] im Produktbaum. Steuerungssicht: Dabei erfolgt eine Integration der vorangegangenen Sichten in einen logischen und zeitlichen Ablaufplan. [Aris06] Zur Verbreitung des ARIS-Konzepts: ARIS bildet die Grundlage von verschiedenen Software- Produkten, beispielsweise dem ARIS Toolset der IDS Scheer AG. Ende 2004 floss das Konzept in Teilen in die grafischen Prozessintegration der SAP Exchange Infrastructure 35 ein. Die Geschäftsprozess-Notation ARIS von Scheer wird positiv bewertet, als größtes Manko ist das proprietäre Format zu sehen, das von keinem einzigen Werkzeug außer von IDS Scheer ARIS unterstützt wird. [Ghal06, S. 16] 34 Prof. August-Wilhelm Scheer, Institut für Wirtschaftsinformatik an der Universität des Saarlandes

66 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement ebpmn, Soyatec ebpmn ist ein frei verfügbares BPMN-Modellierungs-Werkzeug. Die Zielgruppe sind Business- Analysten und Software-Entwickler. Business-Analysten können Geschäftsprozesse auf funktionaler Ebene in der BPMN-Notation entwickeln und abbilden. Dadurch können sie besser mit dem IT-Bereich kommunizieren und diese Bereiche können somit effektiver sowie enger zusammenarbeiten. Softwareentwicklern stehen zudem BPEL4WS 36 und jbpm 37 zur Verfügung, um die erstellten Lösungen in unterschiedliche workflow engines zu integrieren, so die Einstufung der Eclipse Plug-in Centrale 38. Ein kostenloser Download ist verfügbar 39. Zum Anlegen eines ersten Projekts sowie zur Modellierung eines beispielhaften Geschäftsprozesses gibt es ein Web-Demo inklusive Tutorial 40. Der ebpmn Designer ist eine Eclipse Rich Client Platform 41 (RCP) Anwendung und erfordert das JDK 1.5 für Details siehe Übersicht zu aktuellen Projekten BPMN/BPMS Designer, Intalio Der Business Process Management System (BPMS) Designer 43 ist ein Eclipse Plug-in. BPMS unterstützt bei der Erstellung von ausführbaren (engl. executable) Business-Prozessen. Allerdings geht die BPM 2.0 über eine reine Prozessmodellierung und eine Prozessausführung mit simpler Simulation hinaus. Eine Einführung in BPM 2.0 verschafft Ghalimi [Ghal06]. Ein BPMS muss Web-Services unterstützen sowie die menschlichen Eingriffe in den Workflow. Vollständigere BPMS verfügen über drei weitere Eigenschaften: die Unterstützung komplexer Business Regeln, einen Business Activity Monitoring (BAM) und die Möglichkeit, Dokumente innerhalb von Prozessinstanzen zu versionieren. Zusätzlich sind folgende Funktionen denkbar: ein vollständiger Enterprise Service Bus (ESB), ein Meta-Daten Repository und eine Business Intelligent Suite, die beim Würfeln und Stückeln (engl. slicing and dicing) der Daten des BAM unterstützen. Dem Process Design Tool dient die untergelegte Eclipse-Platform als Workbench. Die größten Vorteile bei der Entwicklung von BPMS-Werkzeugen durch die Benutzung von IDE 44 bestehen darin, dass existierende Komponenten und Werkzeuge wiederverwendet und ebenso Komponenten von dritten Herstellern miteinbezogen werden können. Intalio nutzt z. B. den Regeleditor von Corticon, einen KPI Designer von Celequest und einen WYSIWYG Xforms Editor entwickelt von Orbeon die alle als Eclipe Plug-in zur Verfügung stehen [vgl. IDE] BPEL Designer, Eclipse Ein BPEL Editor ist ein Editor für BPEL Code. Frühe BPM Produkte, die die BPEL 36 BPEL4WS jbpm Eclipse Plug-in Central Soyatech Demo Soyatec Tutorial Rich Client Platform (RCP) RCP Projekte BPMS Designer IDE Integrated Development Environments ähneln sehr stark Betriebssystemen bzw. einer Workbench, d. h. Softwareentwickler können ihre Werkzeuge weiterverwenden. 42

67 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Spezifikation nutzen, bieten einen BPEL Editor als grundlegendes Entwicklungswerkzeug anstatt eines echten Werkzeugs zum Design von Geschäftsprozessen an. [Ghal06, S. 18] Durch eine Design-Schnittstelle können eigene Codierungen schnell und einfach umgangen werden, durch das Zeichnen von Diagrammen wie z. B. aus Microsoft Visio bekannt. Per drag und drop können Entities und Relationen eingefügt werden. BPMN Designer erzeugen BPEL Code. Ist ein geeigneter Designer ausgewählt, so muss nicht länger direkt im BPEL Code editiert werden. Das Werkzeug BPM 2.0 unterstützt das Ziel Zero Code. [Ghal06, S. 19] Der BPEL Designer ist ein Plug-in für Eclipse und ist als Download kostenlos verfügbar. 45 Abb. 2.12: Prozess: Von der Idee zum Prototyp dargestellt im BPEL Designer Die Darstellung erfolgt sowohl als Diagramm als auch in einer Baumstruktur [siehe rechts in Abb. 2.12]. Eine Exportfunktion in das XML-Format konnte nicht identifiziert werden Business Process Visual Architect, Visual Paradigm Business Process Visual Architect (BPVA) ist eine Modellierungsumgebung [vgl. Abb. 2.13] für Prozesse. Das Werkzeug BPVA kann 30 Tage als Vollversion kostenlos getestet werden. Zudem gibt es Hochschullizenzen, die ebenfalls den vollen Funktionsumfang bereitstellen. Der visualisierte Prozess kann als Visual Paradigma Projekt (.vpp) Datei abgelegt werden. Die Speicherung erfolgt in ein Arbeitsverzeichnis. 45 BPEL Designer - 43

68 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Abb. 2.13: Bedienelemente und Arbeitsfläche im Werkzeug BPVA Beim Visual Architect 2.0 lassen sich Exporte einzelner Prozesse aber auch des gesamten Projekts in XML realisieren. Der entstehende XML-Export ist schon bei sehr kleinen Prozessmodellen äußerst umfangreich. Allerdings sind die Aufgaben, Pools und Schnittstellen einzeln identifizierbar sowie den Prozessen und Unter-Prozessen (engl. sub-process) zugeordnet. Es können also nicht nur alle bestehenden Aufgaben identifiziert werden, diese sind auch in einem logischen bzw. hierarischen Zusammenhang abgebildet, der über eine chronologische Erstellungsreihenfolge deutlich hinausgeht Enterprise Architect, Sparx Systems Advanced Modeling with UML ist ein UML Design Tool, welches als 30-tägige Testversion 46 bereit steht. Enterprise Architect is a comprehensive UML analysis and design tool, covering software development from requirements gathering, through to the analysis stages, design models, testing and maintenance. EA is a multi-user, Windows based, graphical tool designed to help you build robust and maintainable software. It features flexible and high quality documentation output. The user manual is available online. [Spar06] Enterprise Architect (EA) in der Version 6.5 unterstützt die UML 2.1 Spezifikation. Ein UML Tutorial findet sich unter folgender URL 47. Als hoch-performantes Werkzeug mit selbsterklärenden Benutzungsschnittstellen verfolgt es das Ziel, ein fortschrittliches Modellierungswerkzeug für Entwicklungs- und Implementierungsteams zu stellen. Durch das breite Funktionsangebot richtet sich EA sowohl an Analysten, Tester, Projekt- und Qualitätsmanager von Softwareentwicklungsprojekten. 46 Sparx Testversion UML Tutorial - 44

69 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Abb. 2.14: Business Domain Model im Werkzeug Enterprise Architect 6.5 EA ist als Entwicklungsumgebung für große verteilte SW-Entwicklungsprojekte ausgelegt. Die kostenlose Demoversion ist für kleinere Projekte wenig geeignet und verfolgt das Ziel, Mehrbenutzer-Umgebungen zu unterstützen. Durch das breite Spektrum an Funktionen und die Vorbereitung zur Benutzung für verschiedene Benutzergruppen ist die Bedienung in der Startphase nicht immer intuitiv. EA ist für die Erstellung von UML-Diagrammen gut geeignet Kriterien und Vorselektion Nachstehende Modellierungs-Werkzeuge wurden untersucht. Folgende Kriterien an die visuellgestützten Modellierungs-Werkzeuge für die Modellierung der Innovationsprozesse wurden herangezogen: Verfügbarkeit der Werkzeuge ohne Lizenzkosten, Export-Funktion für Prozessmodelle nach Standards/Austauschformaten, Exportfunktion in das Datenaustauschformat.xml. Werkzeug Hersteller Verfügbarkeit Export Xml-Export Visio Microsoft ja nein ab V.2007 ARIS IDS Scheer ja ja ja ebpmn Soyatec ja Demoversion ja ja 45

70 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement BPMN/BPMS Designer Intalio nein nein nein Freeware BPEL Designer Eclipse Freeware ja nein Business Process Visual Paradigm ja ja ja Visual Architect (BPVA) Demoversion Enterprise Architect (EA) Sparx Systems ja Demoversion ja ja Tab. 2.1: Übersicht, Auswahl 48 und Entscheidung für ein Prozessmodellierungs-Werkzeug Für die Modellierungen der WPIM-Prozesse und die Entwicklung der WPIM-Pipeline wird der Business Process Visual Architect (BPVA) genutzt. Eine kostenfreie Demo-Version, die einfache Handhabung, die visuell-gestützte Modellierung der Prozesse und vor allem die problemlose Konvertierung der modellierten Konzepte in die XML-Notation konnten diese Entscheidung positiv beeinflussen. Ausschlaggebend für die Entscheidung zugunsten von BPVA ist die vollständige XML-Unterstützung. Das XML-Format stellt die Basis für die WPIM- Anwendung und findet als zentrales Datenmodell zu Modellierung und Repräsentation der Prozesse Einsatz. Ebenso geeignet wäre der Enterprise Architect, welcher im SHAMAN Projekt eingesetzt wird und auch ARIS, das im Umfeld der WPIM-Anwendung bei [Woll10] erprobt und verwendet wird. Ausblick: Bestehende Prozessmodelle in Unternehmen fertigender Industrien, die in XML- Notation verfügbar sind, sollen durch WPIM weiter- und wiederverwendet werden können. Das Prozessmodell in XML bildet den zentralen Ausgangspunkt bei der Extraktion von Prozessbausteinen, Aktivitäten und Konzepten, die in taxonomische, hierarische und ontologische Beziehungen gesetzt und mit zusätzlichen Ressourcen erweitert werden sollen. WPIM nutzt weitere Werkzeuge die Prozesse im XML-Format repräsentieren. Durch Transformation der XML-Repräsentationen, z. B. durch XSLT, können Schemata sowie XML- Instanz-Dokumente ineinander transformiert werden. 2.6 Abgrenzung verwandter und verbundener Arbeiten Die verwandten Arbeiten Entscheidungsunterstützung in wissensintensiven Geschäftsprozessen nach [LBMS08] und das Prozessorientierte Wissensmanagement nach [Thie01] werden vorgestellt und eine Abgrenzung zu WPIM getroffen. Zudem wird der Standard for Exchange of Product Modeldata (ProSTEP) zur integrierten virtuellen Produktentstehung (ivip) beleuchtet. Zudem werden zwei verbundene Projekte des Lehrgebietes Multimedia und Internetanwendungen der FernUniversität Hagen vorgestellt: SHAMAN steht für Sustaining Heritage Access through Multivalent ArchiviNg und Daffodil. Mit diesen Projekten werden Synergien im Rahmen gemeinsamer Forschungsschwerpunkte eröffnet, gefolgt von Veröffentlichungen und ebenso bei der Evaluation zu WPIM Entscheidungen in wissensintensiven Geschäftsprozessen Lütke et al. stellen ein Vorgehensmodell zur Entscheidungsunterstützung in wissensintensiven Geschäftsprozessen auf Basis von Produktdaten vor [LBMS08]. Ziel ist es, Wissen, gespeichert als historische Daten in Dokumenten, durch eine Suchmaschine, die unterschiedliche Dokumentund Datentypen unterstützt, aufzufinden und in aktuellen Geschäftsprozessen zu nutzen. Kern dabei bilden die wissensintensiven Geschäftsprozesse. Als Anwendungsdomäne wird die Automobilzulieferindustrie, gewählt mit Fokus auf geometrische Daten wie z. B. CAD- Dokumente, herausgegriffen. Unter dem Stichwort Business Process Reengineering (BPR) 48 Mittlerweile gibt es den Process Modeler von BizAgi, einen gratis verfügbaren Prozessmodellierer (nicht nur als Demoversion) - - abgerufen, am

71 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement werden die Leistungen am Bedarf des Kunden ausgerichtet. Um diesem Bedarf gerecht zu werden, sind hohe Innovationsfähigkeiten sowie kurze Reaktions- und Entwicklungszeiten notwendig [LBMS08]. Innovations- und Entwicklungsprozesse sind aber äußerst wissensintensiv [Remu02 in LBMS08] Wissen gewinnt an Bedeutung. Durch die Flut elektronischer Dokumente entsteht eine Herausforderung beim Auffinden von relevantem Wissen. Die Entscheidungsfindung im aktuellen Problem soll sich an ähnlichen, historischen Vorfällen und Objekten in den Unternehmensdaten orientieren. Das entstehende Suchsystem wird als Vorgehensmodell vorgestellt und die zugrundeliegende Software-Architektur beleuchtet. Eine detaillierte Darstellung des Angebotsprozesses eines Automobilzulieferers, als Beispiel eines wissensintensiven Prozesses, ist in [BaES07] zu finden, mit besonderem Fokus auf den Komponenten der Phasen, die durch ihre Wissensintensität eine Unterstützung durch Suche und Wiederverwendung notwendig erscheinen lassen. Eine Darstellung der generischen Vorgehensweise des Suchprozesses sowie der unterschiedlichen Analysemetriken für verschiedene Datentypen wurde in [BaES06] vorgestellt. Die detaillierte Beschreibung der Vorgehensweise bei der Analyse und Identifizierung wissensbezogener Daten und der darauf aufsetzenden Auswahl der Suchmetriken ist in [LüBS06] aufgeführt. Der Aspekt der kollaborativen Entwicklungsarbeit und die Anwendung der Ähnlichkeitssuche in verteilten Umgebungen sind in [LMMB06] beschrieben [LBMS08]. Im Rahmen der Wissenserfassung einzelner bei einzelnen Prozessen werden speziell historische Produkte und Herstellungsprozesse mit einer Ähnlichkeitssuche und möglicher Wiederverwendung bedacht. Die Autoren stellen fest. Die Kombination von Prozessmodellen und Wissen ist bisher formal wenig fortgeschritten. [LBMS08]. Gängige Modellierungsarten für Wissen, wie semantische Netze oder Ontologien sind gut geeignet zur Identifizierung der Wissensarten und Klassifizierung die Integration in ein Prozessmodell beschränkt sich allerdings bisher auf die Annotation von Objekten mit Texten, die das Wissen repräsentierenden [Remu02 in LBMS08]. Eine Integration von Wissen in BPMN- Prozessmodelle wird konzeptionell in Erwägung gezogen. Stehen Dokumente als Vorlagen aus zurückliegenden Projekten zur Verfügung, kann die Aktivität substanziell durch Anpassung der Struktur des gefundenen ähnlichen Teils verkürzt werden unter gleichzeitiger Erhöhung der Prozesssicherheit anhand der Beachtung der Erfahrungen aus dem Vorgänger-Produkt [LBMS08]. Die Autoren verweisen darauf, dass Prozessbearbeiter auf Erfahrungen blicken, die nicht (explizit) in Dokumenten abgebildet sind. Die vorgestellte Suche unterstützt somit nicht die limitierten und personengebundenen [LBMS08] Wissensumfänge. Wird in den Produktdaten eine Ähnlichkeitssuche angestoßen, so basiert diese auf einer Repräsentation in den Produktdaten. Suchattribute können einige oder alle Attribute einer Tabelle sein. Dokumente stehen im Vordergrund der Suche. In [LBMS08] wird ein Kalkulationsprozess in der BPMN- Notation vorgestellt, der konzeptuell mit Wissen angereichert wird. 47

72 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement 48 Abb. 2.15: BPMN Prozess technische Kalkulation in [LBMS08] Die Autoren stellen fest, dass anhand des Datentyps auf den entsprechenden Suchalgorithmus geschlossen werden kann. Es müssen insofern verschiedene Verfahren zur Suche in unterschiedlichen Datenquellen zum Einsatz kommen können darunter numerische, alphanumerische oder geometrische Daten (meist CAD-Daten) in Form von Dateien. Mit dem ermittelten Verfahren lassen sich dann in den Daten, die zum aktuellen Problem die jeweils ähnlichsten historischen Vorfälle ermitteln und zur Entscheidungsunterstützung verwenden [LBMS08]. Ob die ähnlichsten Vorfälle auch gleichzeitig den Besten (also der engl. Benchmark oder engl. Best Practice) entsprechen, ist gesondert zu prüfen. Inwieweit Lessons Learned einfließen, wird nicht erwähnt. WPIM hingegen legt größten Wert auf ein lernendes Verhalten innerhalb von Prozessen und Entscheidungen, um begangene Fehler kein zweites Mal zu begehen. Die Abgrenzung zu WPIM ist darin zu sehen, dass WPIM verfügbares Wissen mit semantischen Vokabularen annotiert und somit semantische Suchen über die ontologischen Begriffe sowie auch innerhalb von Innovationsprozessen ermöglicht Prozessorientiertes Wissensmanagement Thiesse stellt seinen Ansatz zum Prozessorientierten Wissensmanagement vor [vgl. Thie01]. Aufbauend auf folgender Ausgangssituation begründet er seinen Ansatz: Im Zuge aktueller betriebswirtschaftlicher (gesteigerte Kunden- und Prozessorientierung) und technologischer (Internet, Multimedia) Trends haben Unternehmen unterschiedlichster Branchen die Notwendigkeit erkannt, mit sowohl internem als auch von außen bezogenem Wissen effizienter und effektiver umzugehen, als dies in der Vergangenheit der Fall war. Mit dem steigenden Wissensanteil in den betrieblichen Geschäftsprozessen wird Wissen zunehmend zur Basis der Wettbewerbsfähigkeit, die die Innovationsgeschwindigkeit, die Effizienz von Prozessen, die Qualität der Produkte, das Erkennen von Kundenpotentialen usw. bestimmt. [in Thie01, S. 1; Bach/Österle 1999; Nurmi 1998; Davis/Botkin 1994]. Die Organisation eines Unternehmens orientiert sich an den Leistungen der Prozesse und optimiert damit den Gesamtablauf, statt nur einzelne Aufgaben zu verbessern. Thiesse spricht von repetitiven Prozessen und postuliert: Prozessorientierung hat das Ziel, Prozesse leistungsorientiert zu betrachten und somit den Leistungserstellungsprozess in seiner Gesamtheit, anstatt einzelner Aufgaben, zu verbessern. [Thie01] Dabei wird insbesondere auf Wissen in Prozessen sowie auf Wissen als wiederverwendbare Erfahrungen eingegangen.

73 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Wissen in Prozessen: Ein effektives Prozessmanagement ist unverzichtbar für das Erkennen von Optimierungspotenzialen und die kontinuierliche Verbesserung der Aufbau- und Ablauforganisation einer Unternehmung. Voraussetzung dafür ist das Wissen über die eigenen Geschäftsprozesse sowie über die in Referenzprozessen kodifizierten Best-Practices [vgl. Thie01]. Wissen als wiederverwendbare Erfahrungen: In Zeiten kürzer werdender Innovationszyklen hängen Geschwindigkeit und Erfolgsquote bei der Durchführung von Projekten u. a. in der Produktentwicklung in hohem Maß von der Fähigkeit einer Unternehmung ab, in der Vergangenheit gemachte Erfahrungen gleichsam in einem Unternehmensgedächtnis speichern und zu einem späteren Zeitpunkt wieder verfügbar machen zu können, um einmal gemachte Fehler nicht zu wiederholen und Ergebnisse wiederzuverwenden. [vgl. Thie01] Die häufig betrachteten Kunden- und Lieferantenbeziehungen sollen unter dem Aspekt der Prozessorientierung miteingebunden werden. Denn Prozesse verlaufen häufig überbetrieblich. Um Erkenntnisse auch auf andere Lieferanten oder Neukunden anwenden zu können und um sich nicht in Abhängigkeiten zu begeben, ist das erlangte Wissen zwingend im eigenen Unternehmen zu führen idealtypisch ist dieses Wissen mit dem überbetrieblichen Prozess zu integrieren. Die Nutzung von Wissen ist in vielen Geschäftsprozessen (z. B. Forschung und Entwicklung, Kundenservice, Marketing) nicht allein auf die Verarbeitung stark strukturierter Daten beschränkt. Die Verfügbarkeit von Dokumenten oder Know-how der Experten sind hier kritische Einflussfaktoren für Effizienz und Qualität von Prozessen. Die Aufgabe des Wissensmanagements nach [Thie01, S. 109] ist es, Wissen in anwendungsgerechter Form zur Verfügung zu stellen, den Zugang zu Wissen erleichtern und die Wiederverwendung des in den Prozessen entstehenden Wissens zu sichern. [Thie01, S. 109] Typischerweise werden in den Methoden gewisse Fragen zwar explizit angesprochen, ohne aber ein Konzept zu deren Lösung anbieten zu können. Dazu zählen, z. B. die Entwicklung von Wissensstrukturen oder die Abstimmung von Prozess und Informationssystem. [Thie01, S. 80] Für einige der erörterten Problemstellungen gibt es zurzeit noch keine abschließenden Antworten. Die hier vorliegende Arbeit erkennt diese Herausforderungen von Thiesse an und möchte ebenfalls neben einem reinen methodischen Vorgehensmodell eine softwaretechnische Lösung implementieren SHAMAN SHAMAN 49 steht für Sustaining Heritage Access through Multivalent ArchiviNg und ist ein Forschungs- und Entwicklungsprojekt im 7. EU-Rahmenprojekt. In SHAMAN werden Entwicklungen aus den Bereichen digitaler Bibliotheken, Daten-Grids und Archivsystemen zusammengeführt, um eine vollständige technische Infrastruktur für die digitale Langzeitarchivierung aufzubauen. Dazu wird ein entsprechendes Rahmenwerk entwickelt

74 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Ziel von SHAMAN ist, die Entwicklung einer gridbasierten Vernetzung von Langzeitarchivierungs-Systemen für die zukünftige digitale Archivierung. Dazu entstehen Testumgebungen zur Langzeitarchivierung mit zugehörigen Diensten. Diese Dienste werden nicht nur die Langzeitarchivierung digitaler Inhalte ermöglichen, sondern auch den Zugriff und die weiterführende Nutzung der Inhalte. Als Endergebnis entsteht ein offenes und erweiterbares Digital Preservation Framework, welches innovativen digitalen Bibliotheksanwendungen bereitgestellt wird. Zwischen WPIM und SHAMAN insbesondere Teilprojekt 2 wurden Synergien und Adaptionspotenziale für den WPIM-Prototyp identifiziert. Eine ähnliche Ausrichtung der beiden Arbeiten ermöglicht diese konkreten und gemeinschaftlichen Ansätze: Innovationen in fertigenden Industrien und WPIM-Innovationsprozesse Gemeinsamkeiten bilden die Informationsrecherche, die Netzwerke mit Innovationsexperten (bei SHAMAN als Social Ontology bezeichnet) sowie die Kollaborationen über Unternehmensgrenzen hinweg aus. Innovationskontexte Design und Engineering Gerade der Innovationskontext birgt gemeinsame Forschungsinteressen. SHAMAN und WPIM berücksichtigen bestehende Rahmenwerke und Vorgehensmodelle sowie branchenübliche Standards aus der Domäne Design und Engineering in fertigenden Industrien. SHAMAN hat WPIM einen Zugang zu den Use Cases der fertigenden Industrie, insbesondere zu denen bei Philips PCLAT ermöglicht. Das Unternehmen Philips PCLAT [siehe Kap ] ist ein an SHAMAN beteiliger Entwicklungs- und Evaluationspartner. Im Verlauf dieser Arbeit wird insbesondere der Ideation Process von Philips PCLAT zur Evaluation der WPIM-Methoden herangezogen Daffodil Das Daffodil 50 System stellt ein nutzerorientiertes Zugangs- und Suchsystem für heterogene digitale Bibliotheken zur Verfügung. Daffodil is a digital library system targeting at strategic support during the information search process. For the user, mainly high-level search functions, so-called stratagems, implement this strategic support, which provide functionality beyond today's digital libraries. [Fuhr02] Das Projekt Easy Access to Digital Libraries 51 (EZDL) ist die Weiterentwicklung zu Daffodil. Synergien zwischen Daffodil und WPIM entstehen in den Bereichen der Informations- und Patentrecherche in Innovationsprozessen. Hierbei wird in beiden Arbeiten von einem konkreten Informationsbedürfnis (Use Case) ausgegangen, dem durch geeignete Suchen und Recherchen, über verteilten und annotierten Daten, begegnet werden soll

75 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Abb. 2.16: Innovationsprozess mit Informations-Bedürfnissen [LVKH08; LVKH08a] In den einzelnen Phasen des Innovationsprozesses werden Informationsbedürfnisse erkannt. Bei dem IRF Symposium [LVKH07], der Konferenz ECKM [LVKH08, LVKH08a] sowie der Veröffentlichung im EJKM The Electronic Journal of Knowledge Management 54 [LVKH09] und im Elsevier World Patent Information Journal 55 [LVKH09a] gehen Landwich/Vogel/Klas/Hemmje auf Informationsbedürfnisse und im Speziellen auf Patent- Information im Bereich der Patent-Recherche ein. Abb. 2.17: Innovationsprozess mit Information-Retrieval-Ansatz [LVKH08a] Hierzu wurde der Information-Retrieval-Ansatz aus dem System Daffodil in jede Prozessphase eines Innovationsprozesses integriert. Die speziellen Anforderungen von WPIM an eine semantische Suche werden in der vom Autor betreuten Bachelorarbeit von [Trög12] umgesetzt. Diese verwandten und verbundenen Arbeiten unterstreichen die bestehenden wissenschaftlichen Herausforderungen. Im weiteren Verlauf der Arbeit werden aber nun die konkreten Anforderungen an WPIM ausgeführt

76 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement 2.7 Abgleich und identifizierte Anforderungen an WPIM In den Analysen zum Stand der Wissenschaft und Technik in den Feldern Wissens-, Prozess und Innovationsmanagement konnten Ansätze, Methoden und Werkzeuge identifiziert werden, welche die allgemeingültigen Herausforderungen bereits teilweise abdecken und/oder erste Lösungsansätze bieten. Weiterführend werden die aufgedeckten und bestehenden wissenschaftlichen Lücken untersucht. Diese werden durch den Abgleich der allgemeingültigen Herausforderungen mit den Anforderungen an WPIM sowie mit dem Stand der Wissenschaft und Technik aufgeworfen. Die verbleibenden Anforderungen an WPIM werden im Folgenden beschrieben und dienen als Diskussionsgrundlage. Durchaus ist es möglich, dass weitere zentrale oder allgemeingültige Herausforderungen (engl. requirements) im Bereich des Innovationsmanagements existieren es sei darauf hingewiesen, dass dies keine abschließende Betrachtung darstellen kann. Auf erste Lösungsansätze wird an dieser Stelle bewusst verzichtet. Dadurch sollen zunächst Freiräume für weitere Überlegungen und Ideen eingeräumt und somit der wissenschaftliche Diskurs zum Wissensbasierten und Prozessorientierten Innovationsmanagement beflügelt werden Anforderung: Prozessbaukasten und standardisierte Musterprozesse Bei Innovationen in der Automobilindustrie sollen bestehende Prozessmodelle automatisch in ein geeignetes, standardisiertes Format überführt werden mit dem Ziel diese so weiterhin nutzen zu können, bzw. vollständig in ein einheitliches Abbildungskonzept übernehmen zu können. Es soll möglich sein, Innovations- und Entwicklungsprozesse, welche bereits visualisiert wurden, fortzuschreiben, bzw. um die gewünschten Aspekte des Wissensmanagements zu erweitern. Bestehendes explizites Wissen, wie z. B. in Handbüchern, soll ebenfalls aufbereitet und in die bestehenden Prozessmodelle übernommen werden. Doppelarbeit bei der Prozessmodellierung ist soweit möglich zu vermeiden. Sofern es notwendig ist, sollen auch Teilprozesse verbind- oder integrierbar sein, um so Musterprozesse oder unternehmensweite Prozesse als Kombination von Teilprozessen darstellen zu können. Teilprozesse dienen als Bausteine für Innovationsprozesse. Aktivitäten und Teilprozesse, die bereits mit Wissen angereichert wurden, sollen auch für parallele (andere) Entwicklungsprozesse uneingeschränkt zur Verfügung stehen. Eine dokumentierte Aktivität soll mit allen Wissensinhalten in Parallelprojekte übernehmbar sein. Somit können Aktivitäten und Teilprozesse nach dem Baukastenprinzip ausgetauscht, zusammengefügt oder als Vorlage verwendet werden. Eine Herausforderung stellt dar, standardisierte Musterprozesse aufzusetzen, die zukünftigen Entwicklungen und Innovationsprojekten als Referenzprozesse dienen Anforderung: Virtuelle Treffen und virtuelle Entwicklungsumgebungen Innovationen, z. B. in der Automobil- sowie Luft- und Raumfahrtindustrie, werden zunehmend der Internationalisierung und Globalisierung unterworfen. Kunden und (System-) Lieferanten werden in die Entwicklungsprozesse der Automobilhersteller einbezogen. Kooperationen mit Partnerunternehmen unter Einbeziehung aller verfügbaren Ressourcen nehmen zu. Plattformkonzepte und Prozessbaukästen werden seit vielen Jahren in der Automobilindustrie genutzt. Die Initiative AUTOSAR unterstützt die herstellerübergreifende Entwicklung von Funktionen. The objective of the partnership is the establishment of an open standard for automotive E/E (Elektrik/Elektronik) architecture. It will serve as a basic infrastructure for the management of functions within both future applications and standard software modules. [Auto06] 52

77 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Diese Kooperationen werden durch eine Vielzahl (inter-) nationaler Standorte erschwert. Standortübergreifende Kollaborationen (teils im eigenen Unternehmen) gewinnen an Bedeutung. Um Geschäftsreisen reduzieren zu können, werden oftmals Telekonferenzen eingesetzt. Für eine nahtlose Zusammenarbeit in F&E ist der Daten-, Informations- und Wissensaustausch essenziell. Wissensaspekte und Prozessänderungen müssen jederzeit von allen berechtigten Entwicklungspartnern einsehbar und erkennbar sein, um auf einem konsistenten Entwicklungsstand aufsetzen zu können. Nicht zu vernachlässigen sind bei derartigen Kooperationen Vertraulichkeits- und Geheimhaltungsaspekte. Eine Kernfrage lautet: Welche Daten werden in die Entwicklung eingebracht und welche als Kernkompetenz (der eigenen Organisation) bewusst zurückgehalten? Sicherheitslücken können die Zusammenarbeit gefährden und einen ungewollten Wissensabfluss an die Konkurrenz bewirken. Aus Sicht eines Wissensbasierten und Prozessorientierten Innovationsmanagements besteht die Herausforderung darin, Entwicklungsdokumente standort- und unternehmensübergreifend, vor Dritten geschützt, zeitnah verteilen, austauschen und bearbeiten zu können Anforderung: Wissenssicherung und Anreizsysteme Für Unternehmen wird es zunehmend wichtiger, Wissen im Unternehmen zu sichern, um es ohne Zeitverlust für F&E innovativ einsetzen zu können. Anreizsysteme können Mitarbeiter motivieren, Wissen untereinander zu teilen und im Unternehmen für Innovationen verfügbar zu machen. Der Ansatz Wissensbasiertes und Prozessorientiertes Innovationsmanagement sieht die Herausforderung der Wissenssicherung in Folgendem: Wissen und Ressourcen weitestgehend von den personellen Aufgabenträgern zu lösen und zu formalisieren. Die Prozessorientierung bei WPIM fordert weiter: Formalisiertes Wissen ist nicht nur im Unternehmen zu archivieren, sondern auch in den spezifischen Prozesskontext der Entwicklung zu integrieren. Zur Integration von Expertenwissen in Unternehmen, bzw. weiterführend in Prozesse, sind im Rahmen eines WPIM entsprechende Anreizsysteme nötig, um die Experten zur Wissensfreigabe und Externalisierung ihres impliziten Wissens zu bewegen. Aus Sicht des WPIM ist es herausfordernd, die Experten zur Wissensarbeit, also zum kollegialen Wissensaustausch sowie zum Wissenstransfer hin, zur Organisation zu motivieren. Es sollte nicht über einzelne Anreize, sondern über ein Anreizsystem nachgedacht werden, welches die persönlichen Motive der Mitarbeiter berücksichtigt und besonders auf kollegialen Wissenstransfer und Erfahrungsaustausch abzielt. Dadurch kann das Unternehmensziel, nämlich der Aufbau einer innovationsfördernden Wissenskultur optimal bedient werden. Als Ergebnis sollte eine organisationale Wissensbasis entstehen, auf die Mitarbeiter der Innovationsprojekte zugreifen und davon profitieren können Anforderung: Informationsflut und Informationsdetaillierung Bei der Entwicklung von Innovationen in Unternehmen, z. B. bei Automobilherstellern und Zulieferern, stehen permanent neue Entwicklungen und einzigartige Kaufanreize (engl. uniqueselling propositions) den konkurrenzeigenen Entwicklungen gegenüber. Zudem werden kontinuierlich durch die Gesetzgeber neue Auflagen, Vorgaben und (Umweltschutz-) Richtlinien auferlegt. Dazu entstehen in den F&E Abteilungen mengenmäßige Fluten an technischen und organisatorischen Datensammlungen/Dokumenten, wie z. B. Lastenhefte, Group-Standards, technische Zeichnungen, Verbauungspläne, Projektnachträge und Freigabedokumente. Information hat keinen Wert an sich, vielmehr gilt es, Information im Aufgabenkontext verfügbar zu machen und gezielt einzusetzen. Folgende Fragestellung drängt sich auf: Wie lässt sich die Informationsflut bei innovativen Produktentwicklungen beherrschen und wie können vorhandenes Wissen und Ressourcen rational und nutzbringend eingesetzt werden? Der Ansatz Wissensbasiertes und Prozessorientiertes Innovationsmanagement erkennt die Herausforderung an: Wissen kontextbezogen, aktuell, reduzier- oder erweiterbar fortzuschreiben. Die 53

78 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Gratwanderung bei der Wissensrepräsentation zwischen zu detaillierter Information und zu hohem Abstraktionsgrad ist dabei zu bewerkstelligen Anforderung: Wissensstrukturierung und Wissensdimensionierung Experten benötigen bei Innovationsprozessen, innerhalb der einzelnen Aktivitäten, das verfügbare und relevante Wissen des (gesamten) Unternehmens und ggf. noch Ressourcen der Entwicklungspartner. In gewissem Umfang haben die Aufgabenträger dieses Wissen als Expertenwissen und Erfahrungswissen inne [Thie01]. Das darüber hinaus benötigte Wissen, sei es das Wissen der Kollegen, das formalisierte Wissen im Unternehmen oder das Wissen bei Kooperationspartnern, müssen die Mitarbeiter derzeit selbstständig und ohne definierten Suchprozess auffinden. Sie laufen Gefahr, entscheidendes Wissen zu übersehen bzw. schlicht nicht zu finden. Daraus resultieren folgende Herausforderungen: Geeignete Strukturen, die bei der Wissensablage und Wissensfindung hinreichend unterstützen, sind zu entwickeln. Ressourcen (auch Wissenscontainer genannt) wie Dokumente, Handbücher und Verfahrensanweisungen sind nur sinnvoll, wenn sie in den Kontext des wissensintensiven Prozesses eingebunden sind. Nur dort leiten sie parallel zum Innovationsprozess die Aufgabenträger bei der Aufgabenerfüllung an. Weiterführend, als Herausforderung, steht die Wissensicherung am Ort der Entstehung und zugleich die Wissensbereitstellung am Ort des Bedarfs [VoHe06a]. Dazu müssen geeignete Strukturen, Dimensionen und Abbildungsvorschriften gefunden werden. Zwei grundlegende Gedanken bestehen darin, entweder Ressourcenhierarchien aufzubauen oder gleichwertige Ressourcen über Relationen zu verknüpfen Anforderung: Dynamische Wissenserweiterung und Fortschreibung Möglicherweise erkennen Experten unzureichende Dokumentation im Innovationprozess oder möchten diesen um Hinweise oder wissenswerte Aspekte erweitern. Für die Nutzung in zukünftigen Prozessinstanzen sollten diese Freiheitsgrade der Wissensanpassung zwingend zur Verfügung stehen. Idealtypisch sollte der Prozess mit Wissen angereichert bzw. das Wissen dynamisch an den Innovationsprozess koppelbar sein. Mit dynamisch ist hier gemeint, dass Wissen, also neue oder erweiterte Erkenntnisse, jederzeit und aktuell in die Aktivität integriert werden kann. Ebenso muss die Möglichkeit bestehen, falsches oder hinfälliges Wissen aus der Prozessbeschreibung zu entfernen. Wissen soll nicht starr abgebildet bzw. nicht ausschließlich mit dem Innovationsprozess verknüpft werden, sondern agil und flexibel gemäß den beschriebenen Anforderungen neu kombinierbar sein. Innovationen entstehen durch die Einbringung in bzw. Verknüpfung von bekanntem Wissen mit neuartigen Kontexten. Die Anforderung an WPIM ist darin zu sehen, wissensintensive Prozessdokumentationen und strukturelle Prozessveränderungen parallel zu etablieren. Bei der Wissensrepräsentation muss die Möglichkeit bestehen, die Semantik der Prozessbausteine an neue Rahmenbedingungen und Entscheidungssituationen der Entwicklung anzupassen Anforderung: Lessons Learned und lernende Prozesse Herausfordernd ist es, gezogene Lehren (engl. Lessons Learned, LL) zu erkennen, zu formalisieren und in den Innovationsprozess zu integrieren. Gerade in der Automobilindustrie werden häufig ähnliche Fahrzeugprojekte, Nachfolgefahrzeuge, Facelifts (Produktüberarbeitungen) und Re-Designs entwickelt. Die Anforderungen und Spezifikationen an technische Systeme variieren nur geringfügig. Teilweise ändern sich nur Abmessungen oder Verschraubungspunkte von Steuergeräten bzw. es gilt, Funktionalitäten in Steuergeräten zusammenzufassen. Besonders häufig sind Iterationen bei Entwicklungsprozessen. Dabei wird ein Innovationsprozess mehrfach durchlaufen und mit dem Produkt quasi parallel entwickelt. 54

79 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement Diese ähnlichen, zeitlich verschobenen Prozesse bezeichnen wir als Prozessinstanzen [VoHe06b]. Aus Wissenssicht müssen in zukünftige Prozessinstanzen die LL als positive oder auch negative Erfahrungen einfließen. Dort helfen sie bei der Risikoerkennung und Vermeidung von kosten- und zeitintensiven Fehlentwicklungen. Der Prozess soll lernen, indem kontinuierlich Wissen zum Innovationsprozess gesammelt und im Prozesskontext dokumentiert wird. Der Prozess erfährt aus Wissenssicht eine Wertsteigerung und wird zum sogenannten lernenden Prozess [VoHe06b]. Das WPIM muss sicherstellen, dass die mitentwickelte Prozessdokumentation als Richtlinie und Prozessanleitung (technisch bisher oft als Verfahrenshandbuch bezeichnet) für zukünftige Prozessinstanzen bereit steht Anforderung: Expertenmanagement Wissen und Experten sind derzeit an vielen Stellen in innovativen Unternehmen als Einheit zu sehen, z. B. den Unternehmen der Automobilindustrie. Wir erachten es als notwendig, ein Expertenmanagement in das Innovationsmanagement zu integrieren. Die Herausforderung besteht darin, die wahren Experten im Unternehmen zu identifizieren, Kontaktdaten zu erhalten, um mit ihnen in Verbindung zu treten, um so aktiven Wissensaustausch zu betreiben. Erst einmal identifiziert und gefunden, können diese Experten unterstützen und beraten, wenn es gilt Innovationen zeitnah, kostengünstig und ressourcenschonend durchzuführen. WPIM erkennt die Herausforderung: In kritischen Situationen und bei heiklen Entscheidungsprozessen sollten Experten auf direktem Weg kontaktierbar sein, unabhängig von geografischem/organisatorischem Standort oder persönlich-hierarchischem Status. Auch Experten, die zwischenzeitlich andere (Entwicklungs- oder Innovations-) Projekte (in- oder außerhalb des Unternehmens) begleiten, sollten bei heiklen und kritischen Pfaden im Innovationsprozess mit ihrem Erfahrungswissen über ein Expertensystem auffindbar sein. 2.8 Conclusio: Übersicht der abgeleiteten Anforderungen an WPIM Zur Abgrenzung unterscheiden wir im weiteren Verlauf der Arbeit Herausforderungen und Anforderungen. Herausforderungen sind allgemein, z. B. in einer Domäne oder für ein Problem, gültig. Anforderungen sind spezifisch auf das vorliegende Problem und den gewählten WPIM- Lösungsansatz festgeschrieben, zu implementieren und zu evaluieren. In der Informatik werden häufig Anforderungen an Anwendungen und Anforderungen an IT-Systeme unterschieden. Exemplarische Anforderungen an IT-Systeme sind: Flexibilität, Erweiterung und Agilität, Insellösungen vs. Integration, Performance. IT-System-Anforderungen werden in dieser Arbeit nicht aufgegriffen. Diese richten sich meist an die Leistungsfähigkeit, Integration und Verfügbarkeit von IT-Systemen. Im Folgenden werden die bestehenden Herausforderungen des Prozess- und Wissensmanagements analysiert. Nach der Reflektion der Herausforderungen [vgl. Kap. 1.4 Conclusio und zusammengefasste Herausforderungen]: Projektübergabe und Nachfolger-Regelung, Radikaler Technologietransfer und Kollaborationen, Informationsflut bei Innovationen, Dokumentation per Gesetzeszwang, die Rolle von Experten bei Innovationsprozessen 55

80 Stand der Wissenschaft und Technik von Prozess-, Wissens- und Innovationsmanagement und Abgleich dieser mit dem Stand der Wissenschaft und Technologie verbleiben Anforderungen, die nachfolgend im Rahmen der Arbeit aufgegriffen werden. Aus den Herausforderungen lassen sich folgende Anforderungen [vgl. Tab. 4.20] an die folgende WPIM- Modellbildung herauskristallisieren: Prozessbaukasten und standardisierte Musterprozesse, virtuelle Treffen und virtuelle Entwicklungsumgebungen, Wissenssicherung und Anreizsysteme, Informationsflut und Informationsdetaillierung, Wissensstrukturierung und Wissensdimensionierung, dynamische Wissenserweiterung und Fortschreibung, Lessons Learned und lernende Prozesse, Expertenmanagement. Diese Anforderungen werden im anschließenden Kapitel genutzt, um das WPIM-Modell zu entwickeln, die WPIM-Methode zu spezifizieren und eine geeignete Systemarchitektur für die Implementierung zur WPIM-Anwendung vorzubereiten. 56

81 WPIM Modellbildung und Methodenentwurf 3 WPIM Modellbildung und Methodenentwurf Prozesse sind ein essenzieller Bestandteil der Wertschöpfung fertigender Unternehmen. Wir betrachten daher nun zunächst Prozesse, insbesondere Innovationsprozesse, um zu deren Repräsentation das zentrale Prozessmodell für WPIM aufzubauen. Dieses WPIM-Prozessmodell soll im Folgenden mit Repräsentationen von Ressourcen angereichert werden. Dazu entwickeln wir Modelle zur Repräsentation von Ressourcen, wie z. B. zu Experten und Dokumenten. Bei der WPIM-Modellbildung werden diese Ressourcen-Modelle in das Prozessmodell integriert es entsteht somit ein erweitertes Modell über Prozesse der realen betrieblichen Welt und deren Ressourcen. Als Grundlage für die Entwicklung eines WPIM-Systems wird nun also im weiteren Verlauf der Arbeit das WPIM-Modell definiert und anschließend deklarativ eine generische Repräsentation dafür spezifiziert. Dazu wird zunächst auf die mathematische Modellierung von Prozessen und insbesondere auf die Modellierung der Innovationsprozesse eingegangen. Modellierungsansätze der fertigenden Industrien werden aufgegriffen und hinsichtlich der speziellen Anforderungen an Innovationsprozesse und die Repräsentation deren Ressourcen spezialisiert. Das konzeptuelle Architektur-Modell für WPIM-Systeme wird, auf diesem Ansatz aufbauend, vorgestellt. Wir verfolgen anschließend einen modularen, sowie ebenfalls prozessorientierten Grundgedanken bei der Entwicklung der Methoden zum WPIM. Erklärtes Ziel ist es, die Methoden und das Modell unabhängig voneinander zu gestalten. Dies ermöglicht es, bei der im weiteren Verlauf der Arbeit nachgelagerten Implementierung, Methoden und Modell flexibel und getrennt voneinander zu realisieren und anzupassen. Dies schafft Freiräume für unterschiedliche technische Repräsentationen des Modells sowie verschiedene (z. B. softwaretechnische) Realisierungen der Methoden als Dienste. 3.1 Ausgangspunkt für die konzeptuelle Modellbildung Wir beginnen mit der Modellierung von Innovationsprozessen und mit den zugehörigen Konzepten. Dazu werden Formalismen zur Beschreibung von Prozessstrukturen und Abläufen eingeführt. Durch gezielte Erweiterungen wird das WPIM-Prozessmodell hinsichtlich der Anforderungen der Methode WPIM entwickelt und erweitert. Speziell soll die Semantik der Prozesse berücksichtigt werden, um eine spätere Operationalisierung als Prozess-Ontologie zu ermöglichen. In der Mathematik und der Informatik existieren Methoden zur Beschreibung von Prozessen. Zur WPIM-Modellbildung werden die Szenarien aus [Kap bis 1.3.5] aufgegriffen und Lösungsansätze vorgestellt. Einzelne Funktionen werden abgeleitet und als WPIM-Dienste spezifiziert, um diese für eine Implementierung in der WPIM-Pipeline und in der WPIM-Anwendung vorzubereiten Begriffe zur Modellbildung Die bei WPIM verwendeten Begriffe zur Entwicklung von Modellen, Methoden, der WPIM- Pipeline, dem WPIM-System bis hin zur Semantic-Web-Anwendung, der sog. WPIM- Anwendung werden aufeinander aufbauend definiert und durch eine Erklärung eingeführt. Definition 3.1: WPIM-Prozessmodell Das WPIM-Prozessmodell (kurz WPIM-Modell) repräsentiert einen Prozess der betrieblichen Realität. Das mathematische WPIM-Prozessmodell ist Ergebnis der WPIM-Modellbildung. Hierbei liegt der Fokus auf der Repräsentation der Prozessstrukturen und Hierarchien der Prozesselemente. Im weiteren Verlauf der Arbeit wird das WPIM-Prozessmodell semantisch repräsentiert und kann z. B. durch RDF/RDFS zum semantischen Prozessmodell oder mittels OWL zur WPIM- Prozessontologie erweitert werden. 57

82 WPIM Modellbildung und Methodenentwurf Definition 3.2: Erweitertes WPIM-Prozessmodell Das erweiterte WPIM-Prozessmodell beinhaltet integriert, neben dem Datenmodell für Prozesse (WPIM-Prozessmodell), auch erweiternde Modelle zu Ressourcen (sog. Ressourcen-Modelle), insbesondere Datenmodelle zu Experten und Dokumenten. Auch bei diesen ergänzenden Modellen sind semantische Erweiterungen bis hin zu Ontologien berücksichtigt und möglich. Definition 3.3: WPIM-Methode Eine Methode bei WPIM beschreibt ein strukturiertes, systematisches Vorgehen im Umgang mit Konzepten (oder auch digitalen Objekten) aus dem erweiterten WPIM-Prozessmodell. Eine WPIM-Methode beschreibt beispielsweise, wie das Datenmodell zu einem Dokument semantisch annotiert werden kann. Methoden der Visualisierung beschreiben, wie z. B. Suchergebnisse grafisch für den Benutzer aufbereitet werden können. Definition 3.4: WPIM-Dienst Ein WPIM-Dienst ist auf technischer Ebene die Implementierung einer WPIM-Methode. Dienste arbeiten auf digitalen Objekten. Oft kommen mehrere Dienste zum Einsatz um eine einzige Methode zu implementieren. Je nach Ausrichtung der Anwendung spricht man von Funktionen oder Diensten bei serviceorientierten Architekturen eben von Diensten. Eine Methode zur semantischen Annotation eines Dokuments kann z. B. durch einen softwaretechnischen Dienst zur semantischen Annotation oder einen Dienst zur Hinterlegung von Meta-Information erfüllt werden. Dienste stehen zudem flexibel zur Verfügung und können von diversen Anwendungen aufgerufen und genutzt werden. Definition 3.5: WPIM-Werkzeug WPIM-Werkzeuge werden aus WPIM-Diensten komponiert. Sie bündeln Dienste, um den Benutzern die Nutzung dieser Dienste komfortabel anzubieten. Bei nutzungs-zentrierten Betrachtungen stehen Benutzer und Werkzeuge im Vordergrund. Werkzeuge sind auf Benutzung ausgelegt und bilden das Bindeglied zwischen dem technischen System und dem Benutzer. Werkzeuge haben das Potenzial, Systeme zu sozio-technischen Systemen zu erweitern. Definition 3.6: WPIM-Architektur Die WPIM-Architektur ist an der Model-View-Controller-Architektur orientiert und um Dienste erweitert, die auf eine serviceorientierten Architektur ausgelegt sind. Die genannten Architekturen werden in [Kap. 4.5] vorgestellt und deren Auswahl begründet. Eine Architektur beschreibt die strukturellen Komponenten eines Systems. Das Verhalten des Systems (z. B. der funktionale Nutzen der Dienste) wird auf die strukturellen Komponenten abgebildet. 58

83 WPIM Modellbildung und Methodenentwurf Definition 3.7: WPIM-System Das WPIM-System ist der Kern der Eigenentwicklung beim WPIM. Es folgt der WPIM- Architektur, die WPIM-Dienste stellen die Funktionalität des WPIM-Systems dar. Das WPIM- System arbeitet auf digitalen Objekten. Die Funktionalität des WPIM-Systems wird durch die WPIM-Dienste bereitgestellt. Diese operieren auf dem erweiterten WPIM-Prozessmodell (welches Prozesse, Experten und Dokumente beinhaltet). Im WPIM-System werden die digitalen Objekte verwaltet, verarbeitet und (semantisch) repräsentiert. Definition 3.8: WPIM-Pipeline Die WPIM-Pipeline wird über das WPIM-System hinaus um weitere unterstützende (kommerzielle) IT-Werkzeuge ergänzt. Diese IT-Werkzeuge helfen bei der Aufbereitung von Information sowie bei der Datenverarbeitung entlang/durch der/die gesamte/-n WPIM-Pipeline. Bei der WPIM-Pipeline steht der reibungslose Datenfluss durch das WPIM-System zuzüglich den unterstützenden IT-Werkzeuge im Vordergrund zudem die Kompatibilität der verwendeten Datenformate sowie die Integration der Datenmodelle durch die gesamte WPIM-Pipeline. Die (kommerziellen) IT-Werkzeuge sind nicht Entwicklungsleistung dieser Arbeit und auch kein Bestandteil des WPIM-Systems. Dieses sind allgemeine informationsverarbeitende IT- Werkzeuge zur Aufbereitung, Transformation, Repräsentation, Speicherung und Visualisierung von Information und Wissensressourcen. Definition 3.9: WPIM-Prototyp Die WPIM-Pipeline wird prototypisch implementiert und es entsteht der sog. WPIM-Prototyp (auch als WPIM-Basissystem) bezeichnet. Der WPIM-Prototyp zeigt eine mögliche Interpretation und Implementierung der WPIM- Pipeline. An diesem Prototyp kann punktuell die Funktionalität der Dienste nachgewiesen werden. Die Benutzung sowie die Benutzungsoberflächen sind zunächst nur bedingt ausgearbeitet. Der WPIM-Prototyp kann zukünftig um zusätzliche Dienste erweitert werden. Definition 3.10: WPIM-Anwendung Die WPIM-Anwendung ist ein sozio-technisches System, bzw. die Semantic-Web-Anwendung verkörpert das Wissensbasierte und Prozessorientierte Innovationsmanagement. Die WPIM-Anwendung stellt Benutzungsschnittstellen sowie Werkzeuge bereit und kann somit als sozio-technische Anwendung klassifiziert werden. Der funktionale Nutzen der spezifizierten Dienste und Werkzeuge stehen den Benutzern zur Verfügung. Dies stellt im Rahmen dieser Arbeit die finale Ausbaustufe der softwaretechnischen Umsetzung der WPIM-Modelle und WPIM-Methoden dar. Die Evaluation der WPIM-Anwendung erfolgt in [Kap. 5] anhand der vorgestellten Szenarien [vgl. Kap. 1.3]. Definition 3.11: WPIM-Vorgehensmodell Ein Vorgehensmodell zur sequenziellen Festlegung der Reihung und des Ablaufs der Dienste im WPIM-System. 59

84 WPIM Modellbildung und Methodenentwurf Entkoppelt von der Entwicklung der WPIM-Anwendung ist das WPIM-Vorgehensmodell zu verstehen. Als Vorgehensmodell beschreibt und spezifiziert es die grundlegende Vorgehensweise zur Entwicklung der WPIM-Modelle, der WPIM-Methoden sowie deren Reihenfolge. Daraus lässt sich die Sequenz der Dienste in der WPIM-Pipeline und im WPIM- System ableiten Prozessbegriff und Prozesskonzepte Ein holistischer Ansatz ermöglicht es, Phänomene von Prozessen zu erklären. Ein Prozess ist mehr als die Summe seiner Teile. Die Emergenz-Theorie befasst sich mit Phänomenen, die erst durch die Zusammenführung von Subsystemen entstehen und in den Subsystemen nicht nachweisbar sind, bzw. dass sich bestimmte Eigenschaften eines Ganzen nicht aus seinen Teilen erklären lassen. Läderach beschreibt Emergenzen als Ordnungskonzept [vgl. Läde00]. Der Prozessbegriff nach Hesselle: Ein Prozess ist eine Abfolge von Aktivitäten innerhalb der Unternehmung, die über mindestens ein Anfangs- und Endereignis verfügt, bereichsübergreifend ablaufen kann und aus einem Input einen Output generiert. Der Prozess besitzt einen Prozessverantwortlichen. Sowohl interne als auch externe Anfangsereignisse können den Prozess auslösen. Zu den internen zählt bspw. die Beendigung eines vorgelagerten Prozesses, zu den externen das Versenden einer Information an einen Kunden. Die Aktivitäten innerhalb des Prozesses transformieren den Input zu einem Output. [HESS07a] Prozesse werden daher oft abstrakt als Black-Box-System betrachtet, mit einem Eingang und einem Ausgang In der Box selbst findet die Verarbeitung statt (gem. dem EVA- Prinzip: Eingabe, Verarbeitung, Ausgabe). Für den Prozess werden entsprechende Ziele definiert, formuliert und diese als einzelne Parameter gemessen. Durch den Unterschied zwischen Eingang und Ausgang werden, im Sinne eines Regelkreises, Zielabweichungen festgestellt. Ein Stellglied steuert und regelt je nach Zielabweichung die Verarbeitung nach spezifizierten Regeln. Diese nachstehende und fertigungsnahe Beschreibung eines Prozesses enthält die (minimalen) Kriterien, die wir an einen Prozess richten Eingang: Dieses können Rohmaterialien/Ressourcen sein, bezogen auf den Prozess spricht man von Eingangszuständen. Verarbeitung: Dieses sind definierte Teilschritte. Bei Prozessen wird ein Eingang in ein Ausgangsergebnis gewandelt. Ausgang: Dieses sind Endprodukte, bezogen auf den Prozess die sog. Ausgangszustände. Ziele: die Anforderungen bezogen auf den Prozess. Parameter: Durch Parametrierung kann Einfluss auf den Prozess und dessen Ablauf genommen werden kann. Steuern und Regeln: Dadurch wird die Verarbeitung gezielt gesteuert, unter den Vorgaben einer hohe Stabilität in der Verarbeitung sowie des Erreichens eines optimalen Prozessziels. Diese Sicht auf den Prozess wird häufig auch als sog. Regler oder Regelkreis interpretiert. Durch Verkettung von Verarbeitungsschritten sog. Aktivitäten entstehen Prozesse im Sinne des WPIM. Zur Modellierung von Prozessen bietet der Ordnungsrahmen der modellbasierten Gestaltung [TLDF07] einen Einstieg. 60

85 WPIM Modellbildung und Methodenentwurf Ordnungsrahmen der modellbasierten Gestaltung nach [TLDF07] Der in [Abb. 3.1] dargestellte, dreischichtige Ordnungsrahmen nach [TLDF07] lässt sich aus der Perspektive der zugrundeliegenden Prozesse, konstruierten Modelle und verwendeten Sprachen betrachten. Detailliert möchten wir auf die Ereignisgesteuerte Prozesskette (EPK), die Unified Modeling Language (UML) und die Business Process Modeling Notation (BPMN) eingehen: Abb. 3.1: Ordnungsrahmen der modellbasierten Gestaltung von SOA [TLDF07] Bezogen auf die zugrunde liegenden Prozesse können in Abhängigkeit der Nähe zur Informationstechnik [vgl. Abb. 3.1] eine Gestaltungsebene, eine Konfigurationsebene und eine Ausführungsebene unterschieden werden. [TLDF07, S. 7] Auf der Gestaltungsebene können Informationsmodelle mithilfe einer Sprache, wie z. B. der Ereignisgesteuerten Prozesskette (EPK), konstruiert werden. Die Ereignisgesteuerte Prozesskette wurde 1992 von einer Arbeitsgruppe unter Leitung von August-Wilhelm Scheer vorgeschlagen [TLDF07, S. 7]. Auf der Ebene der Konfiguration kann die mit der Anpassung von Informationssystemen einhergehende Komplexität mithilfe von Anwendungsmodellen reduziert werden, sodass Informationssysteme modellbasiert konfiguriert werden können [TLDF07, S. 8]. Die Unified Modeling Language [vgl. Kapitel 4.6.1], wurde 1996 von Grady Booch, Ivar Jacobson und James Rumbaugh vorgeschlagen. UML wird unter Aufsicht der Object Management Group (OMG) laufend überarbeitet und liegt in Version 2.2 vor. Dazu kann beispielsweise die Business Process Modeling Notation (BPMN) [vgl. Kapitel 2.4.5] zur Konstruktion von Modellen verwendet werden, die sowohl die Ablauflogik der Informationsmodellebene enthalten als auch über Attributierungen die technischen Details der Ausführungsmodellebene berücksichtigen [vgl. TLDF07]. Die Business Process Modeling Notation wurde 2001 von Stephen A. White vorgestellt und von der Business Process Management Initiative (BPMI) veröffentlicht. Auf der Ebene der Ausführung von Prozessen enthalten Modelle schließlich alle zur technischen Ausführung notwendigen Informationen [TLDF07], z. B. kann die Business Process Execution Language (BPEL) [vgl. Kapitel 2.4.3] auf dieser Ebene eingesetzt werden. Nach [TLDF07] unterstreichen die vertikalen Verbindungen zwischen den Betrachtungsebenen in [Abb. 3.1] die Bedeutung der bidirektionalen Kopplung von Informationsmodellen mit Ausführungsmodellen über Anwendungsmodelle. Die horizontalen Verbindungen symbolisieren lose Assoziationen zwischen Elementen der gleichen Nähe zur Informationstechnik in verschiedenen Bereichen des Ordnungsrahmens. Ihre Richtung ergibt sich aus der Anordnung 61

86 WPIM Modellbildung und Methodenentwurf der Bereiche des Ordnungsrahmens. Diese wurden von links nach rechts entsprechend den Stufen der Konkretisierung angeordnet. Während der linke Bereich die konzeptionellen Aspekte enthält, werden im mittleren Bereich die zu deren Beschreibung verwendeten Abstraktionen in Form von Modellen dargestellt und im rechten Bereich die zur Explikation dieser Abstraktionen verwendeten Sprachen. [TLDF07, S. 8] Bei der Modellbildung WPIM greifen wir auf die Ebene des Anwendungsmodells mit der Sprache BPMN [vgl. Abb. 3.1] zurück Vorgehen bei der Modellbildung Bei der Modellbildung stehen wir vor der Aufgabe, zunächst relevante Konzepte zu identifizieren, diese zu definieren und anschließend formal zu beschreiben also deren formale, maschinenlesbare Repräsentation zu spezifizieren. Für die Modellbildung haben wir Szenarien der betrieblichen Praxis ausgewählt, welche die relevanten Konzepte in sich bergen. Nach der Identifikation und Formalisierung der Konzepte (zu Prozessen und Ressourcen, wie z. B. zu Experten und Dokumenten) können diese innerhalb der Repräsentation des Prozessmodells verknüpft und miteinander strukturell in Beziehung gesetzt werden. Wir nutzen bei der Formalisierung der Konzepte zunächst einen mathematischen Ansatz, der den Aufbau eines mathematischen Prozessmodells ermöglicht. In das mathematische Prozessmodell, welches als zentrales Modell dient, werden im Verlauf dieser Arbeit die mathematisch beschriebenen Ressourcen (wie z. B. Experten und Dokumente) integriert. Die Vorteile bestehen darin, ein formales und erweiterbares WPIM-Prozessmodell anbieten zu können. Um während der Modellbildung einen Praxisbezug herzustellen, setzen wir die Szenario- Methode ein. Die vorgestellten und beschriebenen Szenarien [insbesondere vgl Szenario: Projektübergabe und Nachfolger-Regelung] sind in dieser Form, z. B. in der fertigenden Industrie bei Philips Consumer Lifestyle Advanced Technology (PCLAT), anzutreffen. Dies belegt die empirische Befragung mit Erhebung der Datenkollektion in [Kap ] sowie die auswertende Studie [Kret12], welche begleitend zu dieser Arbeit durchgeführt wurden. Somit kann die Relevanz der Szenarien sowie der Bedarf an WPIM in fertigenden Industrien konkret nachgewiesen werden. Anhand der Szenarien leiten wir die relevanten Konzepte ab und modellieren aufbauend auf diesen Konzepten das WPIM-Modell. Wir verwenden diesen empirischen Ansatz und können dadurch einen direkten Bezug zu den Herausforderungen in fertigende Industrien herstellen. Den Praxisbezug sehen wir hiermit exemplarisch als erwiesen an und schließen damit die Modellbildung ab. Die vorgetragene Extraktion der Konzepte lässt sich aber auch auf weitere reale Szenarien [vgl. Kap bis sowie Kap bis ] ausweiten. Bei einer möglichen erweiterten Modellbildung kann das Modell um zusätzliche Konzepte aus den genannten zusätzlichen Szenarien ergänzt werden Analyse der Anwendungsszenarien Anhand real existenter Anwendungsszenarien werden nun im weiteren Verlauf der Arbeit die Anforderungen an die WPIM-Methode weiter konkretisiert. Durch eine Verallgemeinerung und Formalisierung der in den Szenarien und Anforderungen auftretenden Konzepte können die identifizierten Anforderungen systematisch für eine Modellierung und Repräsentation aufbereitet werden. Die Konzepte werden identifiziert, vorgestellt und zueinander in Verbindung gesetzt. Somit wird die Modellierung begonnen und die wesentlichen Konzepte für eine nachfolgende Spezifikation und prototypische Implementierung vorbereitet. Aufbauend auf der Struktur- Definition der Prozesse, deren Modellierung und Formalisierung der mit den Prozessen verbundenen Ressourcen und Konzepte wird so im weiteren Verlauf eine Repräsentation für das WPIM-Modell entwickelt. 62

87 WPIM Modellbildung und Methodenentwurf Analyse von Szenario 1: Projektübergabe und Nachfolger-Regelung Personen wirken in Organisationen zielorientiert zusammen. Wir betrachten Unternehmen der fertigenden Industrien und deren personelle Ressource, die Mitarbeiter. Besonderes Augenmerk legen wir auf das Wissen, die Erfahrungen und Lessons Learned, welche die Mitarbeiter über die Jahre hinweg in Unternehmen gesammelt haben. Ansatz zur Modell- und Methodenbildung: WPIM-Prozessmodell mit Wissensstruktur für Ressourcen Allgemein bekannt ist, dass Mitarbeiter im Sinne einer Ressource 56 nicht uneingeschränkt im Unternehmen zur Verfügung stehen. Mitarbeiter nehmen bspw. Urlaub oder können krank werden. In Unternehmen werden hierzu Vertretungen oder auch Vertreter-Rollen vorgehalten. Aktivitäten, mit denen ein Mitarbeiter im Rahmen der Prozessdurchführung betraut ist, müssen an einen/seinen Vertreter delegierbar sein. Ebenso existiert die Rolle des Nachfolgers. Hierbei wird im Idealfall der ausscheidende Mitarbeiter durch einen Nachfolger quasi ersetzt. Dabei soll das beim ausscheidenden Mitarbeiter verfügbare Wissen, die Erfahrungen und Lessons Learned (zukünftig automatisiert) an den Nachfolger übergeben werden. Hierzu muss eine geeignete Wissensstruktur bereitgestellt werden, in der die Wissensressourcen gezielt abgelegt werden können. Es wird das Ziel verfolgt, Wissen langfristig im Unternehmen verfügbar zu halten und das Wissen von Experten zu sichern. Im Folgenden werden die in Szenario 1 für die WPIM-Modellbildung als relevant identifizierten Konzepte im Überblick vorgestellt. Kernkonzepte, die in diesem und in weiteren Szenarien auftreten, werden durch Fettschrift hervorgehoben: Organisationen: Eine Organisation ist eine soziale Struktur, die aus dem planmäßigen und zielorientierten Zusammenwirken von Personen entsteht und sich zur Umwelt abgrenzt. Unternehmen zählen zu den Organisationen und stellen folglich eine Untermenge dar. Personen: Das Konzept Person repräsentiert reale existente Personen. Mitarbeiter: Mitarbeiter sind eine Untermenge von Personen, mit der Eigenschaft, einer Organisation anzugehören. Experte: Eine Person, die über besonderes Fachwissen oder Expertise verfügt. Ressource: Als Ressourcen werden hier sowohl personelle Ressourcen also Mitarbeiter als auch Wissensressourcen wie Erfahrungen und Lessons Learned bezeichnet. Erfahrungen: Mitarbeiter haben Erfahrungen z. B. in ihrem Unternehmen gemacht. Lessons Learned: Eine spezielle Form der Erfahrung (gezogene Lehren), die Mitarbeiter zumeist aus Fehlern oder Fehlentwicklungen gemacht haben. Wissen: Mitarbeiter verfügen über implizites Wissen. Wissensstruktur: Ordnungsrahmen in dem Wissen und Wissensressourcen strukturiert abgelegt werden können. Prozess: Prozesse in Organisationen bestehen aus Aktivitäten, die von Mitarbeitern durchgeführt werden. Aktivität: Aktivitäten sind Aufgaben oder Aufgabenpakete, die einem Mitarbeiter zur Durchführung/Abarbeitung zugewiesen sind [vgl. Definition 3.13 Aktivität]. Rollen: Personen können Rollen übertragen werden. Das Konzept Rolle klassifiziert Personen, z. B. als Vertreter oder Nachfolger. Vertreter: Ein Mitarbeiter mit der Rolle Vertreter vertritt einen Mitarbeiter z. B. im Urlaubs- oder Krankheitsfall. Nachfolger: Ein Mitarbeiter wird zum Nachfolger eines Mitarbeiters z. B. nach dessen altersbedingtem Ausscheiden. 56 Im Englischen werden Mitarbeiter als human resource und somit als HR bezeichnet. 63

88 WPIM Modellbildung und Methodenentwurf Analyse von Szenario 2: Radikaler Technologietransfer und Kollaboration Für die Zusammenarbeit über Unternehmensgrenzen hinweg, sog. Kollaborationen 57, ist ein gezielter Austausch (engl. transfer) von Daten und Dokumenten nötig. Um die Weiterverarbeitung der ausgetauschten Dokumente zu gewährleisten, sind standardisierte Datenaustausch-Formate zu verwenden. Häufig werden Kollaborationen hinsichtlich Technologie-Partnerschaften etabliert. Ansatz zur Modell- und Methodenbildung: WPIM-Datenaustauschformate Die im weiteren Verlauf dieser Arbeit entwickelten Modelle und Methoden zum WPIM sollen es ermöglichen, Aktivitäten mit einheitlicher Visualisierung, definierten Modellen aus Schemata und eindeutiger aber erweiterbarer Struktur darzustellen. Vor dem Ziel der Kollaboration und dem Datenaustausch kann zur Strukturierung der Aktivitäten [vgl. Definition 3.13 Aktivität] auf Datenebene eine standardisierte Sprache oder ein Datenaustausch-Format (engl. data exchange format) verwendet werden. Aktivitäten werden als eine Einheit beschrieben und folgen zudem einem Schema. Erfahrungen, Lessons Learned sowie Wissensressourcen können in die Prozessbausteine eingefügt werden. Diese Struktur soll für zukünftiges Wissen und Attribute erweiterbar sein. Um die Wissensressourcen innerhalb der Prozessbausteine auch übergreifend in Beziehung setzen zu können, werden (weit) verbreitete Standards aus dem Semantic-Web- Umfeld [vgl. Kap. 4.2] eingesetzt. Zum Austausch vertraulicher Dokumente bei Innovationen können virtuelle Räume eingesetzt werden. Bei Kollaborationen empfiehlt sich ein Schutzmechanismus, wie z. B. eine vertrauenswürdige dritte Partei (engl. Trusted 3 rd Parties, T3P), einzusetzen. Die für die WPIM-Modellierung in Szenario 2 als relevant identifizierten Konzepte lauten: Prozesse: Prozesse sind betriebliche Abläufe. Prozessbausteine: Das Konzept der Prozessbausteine 58 fasst Konzepte zusammen, die zur Modellierung von Prozessen benötigt werden, wie z. B. Aktivitäten. Aktivitäten: Aktivitäten folgen einer definierten Struktur, einem sog. Schema, und ihnen sind Eigenschaften zugeordnet. Attribute: Das Konzept Eigenschaften (engl. attribute) bezieht sich auf Aktivitäten und bietet die Möglichkeit, eine Aktivität genauer zu beschreiben. Beziehungen: Beziehungen (engl. relation) werden zur relationalen Verbindung von Konzepten, wie z. B. Aktivitäten eingesetzt. Schemata: Schemata definieren Strukturen für einzelne Aktivitäten, aber auch ganze Prozesse. Im Umkehrschluss haben Prozesse oder Aktivitäten Gültigkeit für ein Schema. Ressourcen: Hier werden Wissensressourcen beschrieben, darunter fallen Ressourcen, die Wissen, Erfahrungen oder Lessons Learned beinhalten, wie z. B. Dokumente oder Mitarbeiter. Dokumente: In Dokumenten kann Wissen externalisiert, Information abgelegt sowie die Vorgehensweise in Prozessen (Verfahrensanweisung) beschrieben werden. Virtuelle Räume: Virtuelle Räume bieten Möglichkeiten zum Datenaustausch. Der Datenzugriff erfolgt über Zugangsdaten und Anmeldeverfahren. Im weitesten Sinn können auch (Semantic-) Web-Anwendungen als virtueller Raum fungieren. 57 Kollaboration ist die Mitarbeit oder Zusammenarbeit mehrerer Personen oder Gruppen von Personen, z. B. über Unternehmensgrenzen hinweg. 58 Prozessbausteine auch als Prozesselemente oder kurz Elemente im Kontext von Prozessen bezeichnet. 64

89 WPIM Modellbildung und Methodenentwurf Analyse von Szenario 3: Informationsflut bei Innovationen Die Daten- und Informationsmenge für einzelne Aktivitäten und Prozesse stellt eine zunehmende Herausforderung dar. Die fragmentierten Daten sind für einzelne Experten nicht mehr trivial erkenn- und nachvollziehbar. Ansatz zur Modell- und Methodenbildung: Vier WPIM-Wissensebenen. Die Überlegung des folgenden Absatzes besteht darin, einzelne Prozesse als Menge von Prozessbausteinen, wie z. B. Aktivitäten, zu modellieren und zudem eine geeignete Infrastruktur bereit zu stellen, um in diesen Aktivitäten alle relevante Information, Wissen, Erfahrungen und Lessons Learned abzulegen. Daten und Information sind in Unternehmen planerisch verteilt und fragmentiert 59. Wissen ist mit unterschiedlichem Abstraktionsgrad in den Aktivitäten abzulegen. Dieses Wissen soll auf vier Wissensebenen gesichert und gefunden werden. Die sogenannten Vier Wissensebenen [VoHe06b] und [vgl. Abb. 3.2] helfen den Experten bei der Wissensfindung. Experten können diese Wissensebenen im sogenannten Drill-Through- Verfahren [VoHe06b], von (höheren) beschreibenden Ebenen hin zu (tieferen) detaillierten Ebenen, durchdringen. Der Abstraktionsgrad nimmt dabei ab, die Detaillierung des Wissens hingegen zu. Abb. 3.2: Die vier Wissensebenen der WPIM-Wissensinfrastruktur Hofer-Alfeis interpretiert eine solche Prozessgliederung mit entsprechender Suche als Mehrdimensionales Lexikon [Hofer06]. Durch das Drill-Through-Verfahren kann der Experte sich auf höheren Ebenen [Abb. 3.2, Ebene null und eins] einen Überblick über den Prozess und dessen Schnittstellen verschaffen, um ein Verständnis für den Prozess aufzubauen. Detaillierte Dokumente auf tieferen Ebenen [Abb. 3.2, Ebene zwei und drei] helfen, die Aktivitäten selbst durchzuführen. Der prozessverantwortliche Experte selbst befüllt diese Strukturen und zeichnet verantwortlich für die verknüpften Inhalte denn nur er als Innovator kann sinnvolles Wissen von Informationsballast trennen. Zur Reduktion der Informationsflut bei Innovationen wird ausschließlich Wissen an den Prozess gekoppelt, welches der Experte für hilfreich, erklärend bzw. unterstützend erachtet. Nach der Selektion ordnet der Experte dieses Wissen, je nach Detaillierungsgrad, einer der vier Wissensebenen zu. Aus Szenario 3 lassen sich für die WPIM-Modellierung folgende Konzepte als relevant identifizieren: Prozess: Prozesse sind betriebliche Abläufe, aufgebaut auf einer Menge von Aktivitäten. Aktivität: In Aktivitäten werden verfügbare Wissensressourcen strukturiert zugeordnet, bzw. abgelegt. Information: Information zu und über Aktivitäten wird anhand der Wissensebenen strukturiert. Wissensebene: Die Wissensebenen dienen zur Strukturierung von Wissen. Die einzelnen Ebenen haben aussagekräftige Benennungen und zugehörige Beschreibungen es können Ressourcen, wie z. B. Dokumente, direkt zugeordnet bzw. referenziert werden. 59 In Unternehmen als Datenfragmentierung bezeichnet, diese zieht in Konsequenz Datenfragmente nach sich. Verteilte Daten und Redundanzen hingegen sind das Produkt einer planerischen Aufteilung von Daten. 65

90 WPIM Modellbildung und Methodenentwurf Wissensstruktur: Diese stellt die Gesamtheit der Wissensebenen dar. Meta-Wissen: Wissen über die Aktivität sog. Meta-Wissen kann optional hinterlegt werden. Hierbei wird z. B. beschrieben, in welcher Sprache Benennung und Beschreibung verfasst werden. Benennung: Eine Aktivität wird mit einem eindeutigen und aussagekräftigen Namen benannt. Beschreibung: Eine Aktivität erhält eine Beschreibung, darin wird textuell Information zur Aktivität hinterlegt. Zuordnung: referenzielle Zuordnung von Dokumenten und Dateien zu Aktivitäten. Experten: Experten können sich durch die Wissensstruktur, exakter durch die Wissensebenen arbeiten und werden so auf der Suche nach Wissen und Information unterstützt. Dokumente: Das Konzept Dokumente beschreibt Ressourcen die explizites Wissen verkörpern. Das können Dokumente im klassischen Sinn, aber auch digitale Dokumente sein. Ein Dokument hat z. B. das Attribut Autor. Verantwortung: Dieses Konzept beschreibt, dass ein Mitarbeiter Verantwortung z. B. für einen Prozess oder eine Aktivität übernimmt. Die Verantwortung kann dem Mitarbeiter durch ein Rollenkonzept zugeordnet werden. Ebenso sind hier die Rollen der Erstellers oder des Bearbeiters denkbar Analyse von Szenario 4: Dokumentation per Gesetzeszwang Der Gesetzgeber sieht gerade bei der Einführung technischer Innovationen eine Vielzahl gesetzlicher Regelungen und Vorschriften vor, die dem einzelnen Experten so nicht mehr geläufig sein können. Zudem fordert der Gesetzgeber exakte Dokumentationen (und somit beschreibende Dokumente) zu Innovationen und Innovationsprozessen ein, die noch Jahrzehnte später verfügbar sein müssen. Ansatz zur Modell- und Methodenbildung: Nutzung bewährter WPIM- Entwicklungsansätze Häufig bildet der Gesetzeszwang den Ausgangspunkt für die Etablierung und Einführung von Standards und standardisierten Prozessen in Unternehmen. Bestehende Innovationsprozesse müssen ganzheitlich austauschbar sowie auch einzelne Innovationsschritte (auch als Aktivitäten bezeichnet) samt inkludiertem Wissen auf andere Projekte und Prozesse (von Prozess A und Prozess B) in [Abb. 3.3] übertragbar sein. Alle benötigten Ressourcen sind an die Aktivität zu koppeln, um diesen Austausch zu ermöglichen. Eine Innovationsaktivität 60, z. B. das Absicherungs- und Testmanagement für eine Folgeinnovation, kann also im einfachsten Fall für ein Folgeprojekt übernommen, adaptiert und wiederverwendet werden. Exemplarisch wird die Aktivität Test in [Abb. 3.3] in Prozess A aufgegriffen und in Prozess B wiederverwendet. Abb. 3.3: Wiederverwendung der Aktivität Test [VoHe06c, S. 13] Ein reduzierter Standardprozess kann als Basis- oder Musterprozess für ähnliche Innovationen 60 Eine Aktivität im Innovationsprozess. 66

91 WPIM Modellbildung und Methodenentwurf dienen. In diesem Musterprozess sollten die Phasen: Idee-Konzept-Produkt-Test-Einführung enthalten sein. Diese Phasen mit Gültigkeit für Produktentwicklungen schlägt Meixner nach einer Analyse von Modellen zur Neuproduktentwicklung (NPE) vor [Meix03, S. 82]. Diese Phasen sind von WPIM anzunehmen unter der Voraussetzung der Erweiterbarkeit und der Detaillierbarkeit der Phasen, die wiederum WPIM sicherstellt. Die für die WPIM-Modellierung in Szenario 4 als relevant identifizierten Konzepte lauten: Projekte: Projekte können mehrere Prozesse zusammenfassen. Prozesse: Prozesse sind betriebliche Abläufe und beinhalten Aktivitäten. Aktivitäten: Dieses sind abgegrenzte Aufgaben, die zukünftig wiederverwendbar und auf andere Prozesse übertragbar sein sollen. Ressourcen: Zur Durchführung von Aktivitäten werden Ressourcen benötigt, die mit der Aktivität zu verbinden sind, dass die Wiederverwendung der Aktivität sichergestellt ist. Dokumente: sind das Ergebnis der gesetzlich eingeforderten Dokumentation zu Prozessen oder Produkten. Innovationsprozesse: Innovationsprozesse stellen eine Untermenge von Prozessen dar mit dem Ziel, Innovationen hervorzubringen. Phasen: Das Konzept der Phase beschreibt die zeitliche Strukturierung von Prozessbausteinen bzw. Aktivitäten. Musterprozess: Musterprozesse bilden Schemata zu Prozessen. Musterprozesse können wiederverwendet werden und werden bei konkreter Ausführung von einer Prozessinstanz instanziiert. Prozessinstanzen: Das Konzept der Prozessinstanz beschreibt die konkrete Ausprägung eines Musterprozesses Analyse von Szenario 5: Die Rolle von Experten bei Innovationsprozessen Experten mit ihrem Fachwissen und ihrer Expertise nehmen eine entscheidende Rolle in Innovationsprozessen und Innovationen ein. Ansatz zur Modell- und Methodenbildung: WPIM-Expertenprofile Ziel des WPIM-Expertenmanagements ist es, bestehende Expertenprofile, z. B. die aus sozialen Netzwerken bzw. Unternehmensnetzwerken, zu nutzen. Hier sind besonders die Auflagen und rechtlichen Vorgaben des Datenschutzes zu berücksichtigen. Experten können in den Mitarbeiterprofilen neben Kotaktdaten ihre Rollen und Expertise 61 hinterlegen. Auch können Experten benennen, mit welchen Aktivitäten sie im Innovationsprozess beauftragt sind. Dies dient zur Beschreibung der menschlichen (engl. human) Ressource: den Mitarbeitern oder spezieller den Experten. In modernen Unternehmen können Mitarbeiter in bestehenden Expertennetzwerken, nach einer gewissen Teilnahme (Aktivitätsindex) an Innovationsprozessen und qualitativem Engagement (Reputation 62 ) einen Statuswechsel, z. B. hin zum Expertenstatus [NoRe05], durchlaufen. Der kollaborative Ansatz: Kollaboration, Kommunikation und Kompetenz (K3) von Kuhlen stellt dazu hilfreiche Überlegungen vor [Sema04]. 61 Expertise ist dem bereits eingeführten Konzept der Erfahrungen gleichzusetzen. 62 Reputation: Bei Unternehmen zählt Reputation zum immateriellen Vermögen, wie beispielsweise auch Patente und Markenrechte. Einer Umfrage unter Führungskräften zufolge gilt Reputation inzwischen als wichtigstes immaterielles Gut, das in der Lage ist, zukünftig entscheidende Wettbewerbsvorteile zu schaffen; Konkretisierung in Verbindung mit dem Konzept des Nutzens: Reputation entsteht dadurch, dass Experten mithilfe des Wissens von anderen Experten einen Nutzen ziehen und dafür eine Referenz erweisen, als Fürsprecher dienen oder als Leumund agieren - 67

92 WPIM Modellbildung und Methodenentwurf Im Folgenden werden die in Szenario 5 für die WPIM-Modellbildung als relevant identifizierten Konzepte im Überblick vorgestellt: Prozesse: Sind aus Aktivitäten aufgebaut und geben einen betrieblichen Ablauf vor. Aktivitäten: Aktivitäten sind Bestandteil von Prozessen und werden z. B. von Experten durchgeführt. Kontaktdaten: Dies sind mitarbeiterbezogene Kontaktdaten wie Name, Vorname, Abteilung, und Durchwahl. Status: Mitarbeiter können unterschiedliche Status haben, wie z. B. den Expertenstatus. Aktivitätsindex: Dieser gibt an, wie aktiv ein Experte sein Profil nutzt und aktualisiert. Reputation: Ein qualitatives und subjektives Maß zur Beurteilung der Expertise. Mitarbeiter: Das sind Personen, die in einer Organisation oder einem Unternehmen arbeiten. Mitarbeiterprofil: In Mitarbeiterprofilen können Mitarbeiter ihre Kontaktdaten, eine Beschreibung ihrer Aufgaben (genauer Aktivitäten) im Unternehmen sowie ihre Expertise beschreiben. Dort wird Status, Aktivitätsindex und Reputation abgelegt. Experten: Ein Mitarbeiter mit speziellem Wissen oder Erfahrungen gilt als Experte. Er hat den Status Experte. Der Experte kann durchaus auch ein Mitarbeiter eines anderen Unternehmens sein. Experten sind eine Untermenge von Mitarbeitern. Expertenprofile: Neben den Umfängen des Mitarbeiterprofils beinhalten Expertenprofile Angaben zum Wissen und der Expertise von Experten. Expertenprofile sind Spezialformen von Mitarbeiterprofilen, genauer ein Mitarbeiterprofil mit der Ausprägung des Status Experte. Ressource: Unter Human Ressourcen (engl. human resource) werden die Mitarbeiter einer Organisation zusammengefasst. Dazu zählen beispielsweise die (unternehmensinternen) Experten Identifizierte Konzepte, Doppelungen und Kernkonzepte Bei der Analyse der Szenarien [Kap bis Kap ] wurden Konzepte identifiziert, die für die Modell- und Methodenbildung von WPIM relevant sind. Dabei fiel auf, dass einige Konzepte, die sog. Kernkonzepte, in mehreren Szenarien auftreten und somit von besonderer Relevanz sind. Durch diese Doppelungen der Konzepte in den Szenarien können wir Zusammenhänge zwischen Szenarien und deren Verbundenheit nachweisen. Zu den Kernkonzepten zählen wir Prozesse mit Aktivitäten, ebenso Ressourcen wie Experten und Dokumente. Diese Kernkonzepte sind für alle vorgestellten Szenarien von zentraler Bedeutung, daher beginnen wir genau mit diesen Kernkonzepten die formale Modellierung. Sie bilden den Kern des WPIM-Modells und werden im Verlauf der (formalen) Modellierung um die weiteren identifizierten Konzepte ergänzt. 3.2 Innovationsprozess: Deklarative Spezifikation und mathematische Formalisierung Die in den Szenarien identifizierten WPIM-Konzepte werden deklarativ spezifiziert. In dieser Spezifikation wird bereits auf Eigenschaften und Merkmale der Konzepte eingegangen. Die Spezifikationen werden weiter analysiert und systematisch in mathematische und mengentheoretische Formalisierungen überführt. In den formalen Repräsentationen werden den Konzepten die definierten Attribute zugeordnet. In dieser formalen Repräsentation werden Aktivitäten und Relationen zu Prozessstrukturen zusammengeführt. Durch die Einführung verschiedener Dimensionen werden die formalen Konzepte und Ressourcen zu einem erweiterten mathematischen WPIM-Prozessmodell vereint. Die Typisierung von Aktivitäten und 68

93 WPIM Modellbildung und Methodenentwurf die Instanziierung des Prozessmodells runden die Betrachtung ab. Im weiteren Verlauf dieser Arbeit werden die mathematischen Formalisierungen in softwaretechnische Schemata und Ontologien überführt, um dadurch eine Operationalisierung vorzubereiten Modellierung von Strukturen Zur Beschreibung von dynamischen Vorgängen finden Graphen, Automaten, Petri-Netze, Neuronale-Netze, Markov-Graphen und weitere Modelle, die auf die Simulation und das Durchlaufverhalten von Prozessen abzielen, Einsatz [FeSi98, KaKl05]. Einen Überblick zur Modellierung von Geschäftsprozessen, Methoden, Modellbegriffen und Modelltypen auf den Ebenen Business Engineering, Strategie und Technik, der Prozessebene, sowie den System- und Applikationsebenen gibt Winter [Wint02]. Karstens und Kleine-Büning geben einen detaillierten Einblick zur Modellierung mit Wertebereichen, Modellierung mit Graphen sowie zur Modellierung von Strukturen und Abläufen. Im Bereich der Modellierung von Strukturen sehen die Autoren das Entity- Relationship-Modell (ER-Modell) als Grundlage für weitergehende Beschreibungsmittel. Die Strukturen und Beziehungen der Daten, die eine objektorientierte Datenbank erhalten soll, das sog. konzeptionelle Schema, beschreibt man mit Begriffen des ER-Modells. Auf den Grundlagen des ER-Modells ist die Unified Modeling Language (UML) zu einer umfassenden Spezifikationssprache für den Softwareentwurf und Softwarestrukturen entwickelt worden. [KaKl05, S. 178] Ausgangspunkt in die Modellierung: Die identifizierten WPIM- Kernkonzepte Die identifizierten Kernkonzepte können weiter um relevante Attribute und Eigenschaften erweitert werden. Folgende Kernkonzepte wurden anhand der Szenarien als relevant erkannt und lassen sich nach der Ressource Prozess und der Ressource Person gliedern. Im weiteren Verlauf werden Beispiele der formalen Modellierung, wie Arten von Beziehungen und Arten von Attributen, erläutert. Daran kann analog abgeleitet werden, wie die formale Modellbildung im Detail durchgeführt wird. Prozesse sind aus Prozessbausteinen, wie z. B. Aktivitäten, aufgebaut. Prozesse haben einen eindeutigen Namen und eine ID. Aktivitäten repräsentieren reale Aktivitäten in (Innovations-) Prozessen. Zur eindeutigen Identifikation sind Aktivitäten (die Attribute) ID und Name zugeordnet zudem weitere Eigenschaften wie Ersteller und Verantwortlichkeit. Das Konzept Person repräsentiert eine realexistente Person. Personen haben eine ID und einen Namen und Vornamen, über die sie eindeutig identifizierbar sind zudem sind Personen eine E- Mail-Adresse und eine Telefonnummer zugeordnet. Mitarbeiter sind Unterkonzepte zum Konzept Person, die beschriebenen Attribute und Eigenschaften bzw. Elemente werden vom Konzept der Person vererbt. Mitarbeiter haben die Spezialisierung und somit die Eigenschaften bzw. Elemente Mitarbeiternummer, Durchwahl und ein Eintrittsdatum ins Unternehmen. Mitarbeiter können verschiedene fachlich-temporäre Rollen (wie z. B. wie Projektleiter, Verantwortlicher, Vertreter) und permanent-organisatorische Rollen (z. B. Bearbeiter, Nachfolger) im Unternehmen einnehmen. Auch ein Aktivitätsindex einzelner 69

94 WPIM Modellbildung und Methodenentwurf Mitarbeiter, z. B. mit den Ausprägungen Kenner, Könner, Experte 63, ist denkbar. Relationen und formale Modellierung: Wir haben die Konzepte Personen, Mitarbeiter und Aktivitäten, woran sich exempl. Modellbildung aufzeigen lässt, vorgestellt. Anhand von hierarchischen Konzepten wie Person und Mitarbeiter kann Vererbung ausgeführt bzw. der Gedanke der Typisierung verdeutlicht werden. Anhand nicht-hierarchischer (funktionaler) Konzepte kann der Begriff Relation aufgezeigt werden. Mitarbeiter erstellen bzw. sind verantwortlich für Aktivitäten. Daraus lassen sich die Relationen IstErstellerVon und IstVerantwortlichFür ableiten. Modellierung von Konzepten und Attributen: Dokumente haben einen Autor/Ersteller. Dokumente haben ein Erstellungsdatum. Mitarbeiter haben eine Mitarbeiternummer. Mitarbeiter haben eine -Adresse. Modellierung mit Konzepten und Relationen: Dokumente sollen an Mitarbeiter mit der Rolle Nachfolger übergeben werden. Mitarbeiter erstellen/bearbeiten/verantworten Aktivitäten. Aktivitäten sollen an Mitarbeiter mit der Rolle Vertreter übergeben werden. Innovationsprozesse bestehen aus Aktivitäten. Dokumente sind Aktivitäten zugeordnet. Modellbildung: Ausgehend von den identifizierten Konzepten wird über die Szenarien hinweg eine kleinste gemeinsame kritische Masse dieser Konzepte identifiziert: Dies sind Prozesse mit Aktivitäten sowie die Ressourcen, also Experten und Dokumente. Das Zusammenspiel dieser drei unterschiedlichen Konzepte lässt sich so argumentieren: Prozesse bilden strukturell Abläufe in Unternehmen ab und sind aus Aktivitäten aufgebaut. Daher sind Prozesse gut geeignet, um Ressourcen am Ort des Bedarfs zu allokieren. Experten und Dokumente können eben als solche Ressourcen interpretiert und subsummiert werden. Folglich bietet sich die Betrachtung an, Prozesse als strukturelles Gerüst zu sehen, in das die Ressourcen Experten und Dokumente integriert, danach prozessorientiert strukturiert und in diesem Gerüst verwaltet werden. Der Zusammenhang von Prozessen und den Ressourcen Experten und den Ressourcen Dokumenten kann daran dargestellt werden. Die Ausleitung von Konzepten aus Szenarien als Basis, darauf aufbauend die Modellierung über den Konzepten und der inhaltlich logische Zusammenhang der Konzepte kann so verdeutlicht werden stets vor dem Ziel der Arbeit, fragmentierte Daten, verteilte Information, benötigtes Wissen und Ressourcen zu strukturieren und zu integrieren. Ausblick: Klassen und Instanzen: Relationen lassen sich über Klassen entwickeln. Allerdings müssen bei der Modellbildung Instanzen, bzw. Objekte erzeugt werden, die konkrete reale Personen oder Aktivitäten repräsentieren. Die Relationen können auf die Instanzenebene vererbt werden und ermöglichen die konkrete Zuordnung und Allokation von Instanz Person zu Instanz Aktivität. So entsteht ein konkretes Modell auf Schema-/Klassenebene ebenso wie auf Instanz- /Objektebene. Relationen helfen, Konzepte ebenso wie konkrete Instanzen zu verbinden. Ziel ist es, auf dem Modell, das auf realen Instanzen operiert, mit geeigneten Methoden zu rechnen Mathematischer und mengentheoretischer Formalismus Die mathematische Repräsentation ermöglicht die Vorbereitung einer Implementierung und dies 63 Hier muss unterschieden werden: Experten können als Unterkonzept von Mitarbeitern interpretiert werden oder als Mitarbeiter mit der Eigenschaft/in der Rolle des Experten. 70

95 WPIM Modellbildung und Methodenentwurf unabhängig von einer Programmiersprache. Vorteile sehen wir darin, dass durch den formalen Ansatz eine eindeutige mathematische Beschreibung des Modells erreicht wird, diese aber offen ist für unterschiedlichste technische Realisierungen und zukünftige Implementierungen. Schwickert und Fischer geben einen Vergleich zu Prozessen aus der Sicht der Informatik und den Geschäftsprozessen in der Wirtschaftsinformatik. In der Informatik werden Prozesse unter formalen Prozessbegriffen abgehandelt und als Folge von Aktionen in einem Zustandsraum definiert. In der Wirtschaftsinformatik, so die Autoren, existiert keine einheitliche Definition zu Geschäftsprozessen, vielmehr wird eine Vielzahl von Ansätzen vertreten, die unterschiedliche Aspekte der Geschäftsprozesse beleuchten. Im Bereich der Wirtschaftsinformatik werden den Rahmenbedingungen und vorgegebenen Regeln, (u. a. auch als engl. business rules bezeichnet), ein hoher Stellenwert beigemessen [ScFi96]. Exkurs Formale Sprachen: Untrennbar verbunden mit dem systematischen Aufbau strukturierter Form [vgl. Tabe06] ist der Begriff der Sprache. Dabei ist zunächst zwischen dem umgangssprachlichen Begriff im Sinne der natürlichen Sprache und den sog. formalen Sprachen zu unterscheiden. Letztere stellen Ausprägungen formaler Systeme (hierbei steht System für einen bestimmten Typ statischer Systeme) dar und bilden eine Grundlage für den Aufbau von Programmiersprachen und anderer technischer Sprachen im Bereich informationeller Systeme. Ein Bedarf nach (formalen) Sprachen entsteht in der Technik immer dann, wenn Beschreibungen regelhaft aufgebaut werden müssen. Dies ist typischerweise dann der Fall, wenn eine systematische Verarbeitung komplexer Beschreibungen durch die Maschine erfolgen soll. [Tabe06, S. 20] Strukturen und mathematische Strukturen: Unter einer Struktur im allgemeinen Sinn wird ein Gebilde verstanden, welches aus Objekten besteht, die bestimmte Attribute aufweisen und in bestimmten Beziehungen zueinander stehen [Tabe06, 45]. Unter einer Struktur (S) im mathematischen Sinn verstehen wir ein Gebilde aus Mengen M {M 1, M 2,, M n } und Relationen R {R 1, R 2,, R m } wobei die Relationen auf denen zur Struktur zählenden Mengen definiert sind [vgl. Tabe06, 46]. Mathematische Struktur dargestellt als Tupel: S=(M 1, M 2,, M n ; R 1, R 2,, R m ) In Anlehnung an Tabeling gelingt, ausgehend von Objekten, Attributen und Beziehungen, der Schritt hin zu mathematischen Strukturen. Die Mengen ergeben sich aus den Objekten sowie den zugeordneten Attributen. Experte E = {Dieter Müller, Rita Müller, } Abteilung A = {Forschung, Vorentwicklung, Entwicklung, } Die Relationen ergeben sich aus den Beziehungen und der Zuordnung von Attributen zu Objekten: Zuordnung: Experte zu Abteilung e E A [Tabe06]. Diese verwendeten Konzepte werden im Folgenden definiert und strukturell verknüpft. Relationen ordnen Objekten Attribute zu bzw. erzeugen Beziehungen zwischen Objekten. 71

96 WPIM Modellbildung und Methodenentwurf Attribute, Typen und Beziehungen: Attribute sind Merkmale, welche die Objekte näher charakterisieren und unterscheidbar machen. Attribut: Experte hat das Name-Attribut Beziehungen: Experte_betreut_Aktivität-Beziehung Beziehung: Experte_IstVertreterVon_Experte-Beziehung Dabei gilt typischerweise die Vorstellung, dass ein Attribut untrennbar mit seinem Objekt verbunden ist, d. h. nicht losgelöst von ihm gedacht werden kann. [Tabe06, S. 45] Bei Attributen wird zwischen Eigenschaften und sonstigen Attributen unterschieden. Mit Eigenschaften ist die Vorstellung der Messbarkeit verbunden, während bei sonstigen Attributen bzw. bei Beziehungen nur entschieden werden kann, ob sie zutreffen oder nicht. [Tabe06, S. 46] Attribute lassen sich gedanklich zerlegen in Attributtyp 64 und Attributwert 65. Die Klassifikation bei der Objektorientierung basiert nicht auf Attributen sondern Attributtypen. Farbe wird üblicherweise als Attribut bezeichnet. Unter Typ wird ein abstraktes Objekt verstanden, welches ausgewählte kennzeichnende Merkmale einer Menge von Objekten aufweist, aber keine Merkmale darüber hinaus, wobei bei der Objektorientierung die Typisierung 66 anhand der Attribute und Methoden geschieht. [Tabe06, S. 334] Prozessstruktur als mengentheoretischer Formalismus In der Literatur ist eine Trennung der Begrifflichkeiten nicht immer eindeutig: In konzeptuellen und grafischen Darstellungen wird für Aktivitäten auch Aufgabe [vgl. FeSi98], Prozessteil [vgl. HESS07a] oder Prozessbaustein [vgl. VoHe06] verwendet. Daher definieren wir die zentralen Konzepte, die eine Modellierung und Formalisierung von Prozessen und insbesondere von Innovationsprozessen ermöglichen für diese Arbeit. Im Verlauf der Arbeit überführen wir diese Konzepte in digitale Objekte. Bei den Definitionen und der Modellierung von Prozessstrukturen sei nochmals angemerkt, dass wir zunächst den strukturellen Aufbau der Prozesse betrachten: Definition 3.12: Aufgabe Eine Aufgabe (Aufg.) ist ein nicht-teilbarer betrieblicher Vorgang innerhalb eines wirtschaftlichen Ablaufs. Definition 3.13: Aktivität Eine Aktivität (A) ist eine Menge von Aufgaben, die einen Eingangszustand in einen Ausgangszustand überführt. Aktivitäten haben die Attribute: ID, Titel, Beschreibung, Start, Ende, Version, Schlagworte, Eingabedokumente, Ausgabedokumente, Ansprechpartner, Verantwortlicher, Vertretung, Links, Details, Vorgänger, Nachfolger, Abteilung. 64 Farbe als Attributtyp. 65 Grün als Attributwert. 66 Typisierung: Zuordnung eines Typs zu einem Exemplar/Instanz. Der Übergang von Typ zu Exemplar wird als 72 Inkarnation bezeichnet [Tabe06].

97 WPIM Modellbildung und Methodenentwurf Abb. 3.4: Visuelle Modellierung einer Aktivität als Menge von Aufgaben [Abb. 3.4] zeigt den Aufbau einer Aktivität aus mehreren Aufgaben. Die nachstehenden Definitionen folgen aufbauend auf den gegebenen Definitionen zu Aufgabe und Aktivität. Mathematische Formalisierung zu Aktivitäten: Die Aktivitäten können als Aktivitäten-Menge A dargestellt werden. Für die Aktivitäten a gilt a A. A:= {a 1, a 2, a 3,,a n }; a n A; n + ; Die Aktivitäten-Menge wird in mathematischen Ansätzen auch als Zustandsraum Z bezeichnet [ScFi96]. Definition 3.14: Relation Allgemein setzt eine (binäre) Relation zwei Konzepte in Beziehung. Im Rahmen der Modellierung von Prozessstrukturen setzt eine Relation zwei Aktivitäten in Beziehung. Eine vertiefende Betrachtung zu injektiven, surjektiven und bijektiven Relationen findet sich in [Kap. 7.8 Anhang H: Relationen und Abbildungen]. Mathematische Formalisierung der Relationen: Die (binären) Relationen können als Relationen-Menge (R) dargestellt werden. Für Relationen r gilt r R. R:= {r 1,r 2, r 3,,r m }; r m R; m + ; Relationen [Abb. 3.5] werden in mathematischen Ansätzen als Berechnungen bezeichnet [SCFi96]. Hier die Konzepte zur visuellen Modellierung: Abb. 3.5: Visuelle Modellierung von Aktivitäten und Relationen Die Einführung weiterer struktureller Operatoren führt an dieser Stelle zu weit, das WPIM- Modell kann aber dahingehend erweitert werden. Bei der Operationalisierung wird zudem der Split bzw. der Konnektor umgesetzt. 73

98 WPIM Modellbildung und Methodenentwurf Einführung einer (strukturell) zeitlichen Dimension Definition 3.15: Parallele Aktivitäten Parallel beschreibt zeitliche Parallelität von Aktivitäten, d. h., mindestens zwei Aktivitäten werden dabei parallel oder teilweise parallel (überlappend) durchgeführt. In [Abb. 3.6] folgt die visuelle Modellierung zu parallelen Aktivitäten. Die Aktivitäten A02 und A03 sind parallele Aktivitäten: Abb. 3.6: Visuelle Modellierung von parallelen Aktivitäten Böhm/Meyer-Wegener/Schulze geben eine Einsicht in die Ausführungsformen von Aktivitäten. Anbei folgt ein tabellarischer Auszug aus den Elementaren Ausführungsformen mit Parallelität der Aktivitäten a 1, a 2 A [BöMS96]. Ausführungsform Relation Visuelle Modellierung gleichzeitig EQUAL (a 1, a 2 ) [1 ] [2 ] überlappend OVERLAPS (a 1, a 2 ) [1 ] [2 ] während DURING (a 1, a 2 ) [1] [2 ] gleicher Start STARTS (a 1, a 2 ) [1 ] [2 ] gleiches Ende ENDS (a 1, a 2 ) [1 ] [2 ] Tab. 3.1: Elementare Ausführungsformen zur Parallelität [vgl. BöMS96, S. 5] Definition 3.16: Sequenz Stehen mindestens zwei Aktivitäten in einer linearen zeitlichen Reihenfolge (ohne Überschneidungen) zueinander und sind durch Relationen verbunden, so können diese als Prozesssequenz zusammengefasst werden. Die Modellierung zu einer Sequenz in [Abb. 3.7] bestehend aus drei Aktivitäten A01, A02 und A03: Abb. 3.7: Visuelle Modellierung einer Sequenz von Aktivitäten 74

99 WPIM Modellbildung und Methodenentwurf Die Ausführungsform, Relation sowie die visuelle Modellierung zur zeitlichen Reihung von Aktivitäten in der Übersicht: Ausführungsform Relation Visuelle Modellierung vor PHASE (a 1, a 2 ) [1] [2] (direkt) anschließend SEQUENZ (a 1, a 2 ) [1][2] Tab. 3.2: Elementare Ausführungsformen zur Reihenfolge [vgl. BöMS96, S. 5] Definition 3.17: Phase Sind Aktivitäten in zeitlicher Reihenfolge geordnet, so spricht man von Phasen t. Dabei grenzen Phasen t und t+1 direkt aneinander, Lücken oder Sprünge zwischen Phasen sind nicht zulässig. Aktivitäten einer Phase müssen nicht zwingend durch Relationen verbunden sein. Aktivitäten in zeitlicher Reihenfolge und Unterteilung in Phasen: Abb. 3.8: Visuelle Modellierung zur Phasenzuordnungen von Aktivitäten Die Abbildung [Abb. 3.8] zeigt beispielhaft vier Phasen (t 1 bis t 4 ) mit fünf Aktivitäten (A00 bis A04). Da Sequenzen die strengere Ordnung als Phasen darstellen, wird nachfolgend auf Sequenzen eingegangen. Die Überlegungen gelten ebenfalls für die PHASEN-Reihung von Aktivitäten. R:={SEQUENZ (a 1,a 2 ), SEQUENZ (a 2,a 3 ),,SEQUENZ (a n-1,a n )}; Beispiel zu Phasen: Soll z. B. in der Phase t 3 in der Aktivität A03 ein elektronisches System bestehend aus den Komponenten Software und Hardware entstehen, so sind die Entwicklungen dieser Komponenten vorher in der Phase t 2 abzuschließen, in einem Komponenten-Freeze festzuhalten und durch ein Freigabedokument freizugeben. In Phase t 2 geschieht dies für die Software in Aktivität A01 für die Hardware in A02, erst dann kann in Phase t 3, die Entwicklung des elektronischen Systems durchgeführt, ein System-Freeze initiiert und die Freigabe für das System erfolgen. Reihenfolge und Überlappungen von A01 und A03 sind nicht relevant. Entscheidend ist, dass alle Aktivitäten einer vorgelagerten Phase t-1 vor der Phase t abgeschlossen sind. In der Automobilindustrie werden diese Phasen, die sich über mehrere Monate hinziehen können, häufig als Integrationsstufen (I-Stufen) bezeichnet. Diese dienen als unternehmensübergreifende Zeitpläne, takten für Fahrzeugprojekte die Entwicklung, Serienfertigung und Vertrieb (bereichsübergreifend) sowohl für eigene Abteilungen als auch für Lieferanten (organisationsübergreifend). 75

100 WPIM Modellbildung und Methodenentwurf Prozesse, Prozessstrukturen und deren Verfeinerung Eine Prozessstruktur ist eine modellhafte Anordnung von Konzepte eines realen Prozesses. Bei einem rein strukturellen Ansatz zählen zu diesen Konzepten Aktivitäten A und Relationen R. Definition 3.18: Prozess Ein Prozess (P) ist eine durch Parallelität, Sequenzen und Phasen strukturierte Menge von Aktivitäten a n, die durch eine Menge von Relationen in Beziehung stehen. Zudem kann ein Prozess weitere Prozesse enthalten 67. Prozesse besitzen die Attribute: ID, Titel, Beschreibung, Start, Ende, Version, Schlagworte, Eingabedokumente, Ausgabedokumente, Ansprechpartner, Verantwortlicher, Vertretung, Abteilung, Links. Mathematische Formalisierung des Prozesses Abb. 3.9: Visuell modellierter Prozess P:= {A, R}; mit A, R P; A:= {a 1, a 2, a 3,,a n }; R:= {r 1, r 2, r 3,,r m }; Weiterführend sind Struktur bzw. Relationstypen denkbar. So können auch Musterprozesse abgeleitet oder entwickelt werden. Binäre Relationen R über Aktivitäten A können folgendermaßen dargestellt werden: a 1 Ra 2 oder R(a 1,a 2 ) R A 1 A 2 mit A 1 A 2 := {(a 1,a 2 ) (a 1 A 1 ) (a 2 A 2 )} Eine binäre Relation R ist eine Teilmenge des kartesischen Produkts zweier Mengen A 1 und A 2. Beispiel: Zur Entwicklung eines elektronischen Systems in der Automobilindustrie müssen mehrere Aktivitäten durchgeführt werden, die in einem strukturellen Zusammenhang stehen. In [Abb. 3.9] wird z. B. in der Aktivität A00: die Anforderungen spezifiziert, A02: ein Funktionsmuster gebaut, A01: ein Prototyp entwickelt, A03: Komponenten-, System- und Integrationstests durchgeführt und A04: das System für die Serienfertigung freigegeben. 67 Dies ist eine rekursive Definition zu Prozessen. Ziel ist es, die Skalierbarkeit zu erreichen, welche in der Praxis 76 gefordert wird.

101 WPIM Modellbildung und Methodenentwurf Definition 3.19: Unterprozess Eine Untermenge der Aktivitäten (ua) eines Prozesses, die durch eine Untermenge der Relationen (ur) eines Prozesses alle untereinander verbunden 68 sind (in Zusammenhang stehen), bezeichnet man als Unterprozess (up). Unterprozesse haben identische Attribute wie Prozesse: ID, Titel, Beschreibung, Start, Ende, Version, Schlagworte, Eingabedokumente, Ausgabedokumente, Ansprechpartner, Verantwortlicher, Vertretung, Abteilung, Links. Mathematische Formalisierung eines Unterprozesses: up:= {ua, ur}; ua A mit A:= {a 1, a 2, a 3,,a n }; ur R mit R:= {r 1, r 2, r 3,,r m }; Visuelle Modellierung von Unterprozessen: Zunächst wird ein Prozess gezeigt. Dieser [Abb. 3.10] wird in zwei Unterprozesse up_1 und up_2 zerlegt. Abb. 3.10: Aktivitäten und Relationen der beiden Unterprozesse up_1 und up_2 Fügt man diese beiden Unterprozesse erneut zusammen, so kann der Ausgangsprozess durch die beiden verbundenen Unterprozesse dargestellt werden. Beispiel Unterprozesse zur Strukturierung: In [Abb. 3.10] werden einzelne Aktivitäten den Unterprozessen zugeordnet. Weist ein Akteur/Experte zwei Aktivitäten auf, z. B. A00: die Implementierung einer Software (SW) und A01: die Dokumentation der SW, so können die Aktivitäten im Unterprozess up_1 zusammengefasst werden. Der up_2 besteht hier aus drei Aktivitäten. 68 In der mathematischen Graphen-Theorie spricht man vom Zusammenhang von Graphen: Ein Graph ist zusammenhängend, wenn jeder Knoten des Graphen von jedem anderen Knoten aus über einen Weg erreichbar ist. 77

102 WPIM Modellbildung und Methodenentwurf Definition 3.20: Komplexe Aktivität Eine komplexe Aktivität A kann weiter in mehrere (einfache) Aktivitäten, verbunden durch Relationen, unterteilt werden. Diese einfachen Aktivitäten mit den verbindenden Relationen können als Unterprozess der komplexen Aktivität modelliert werden. Die Struktur einer komplexen Aktivität wird als Unterprozess (bestehend aus Aktivitäten und Relationen) gem. den Definitionen zu Unterprozess und Aktivität verfeinert dargestellt. Abb. 3.11: Zerlegung einer komplexen Aktivität A in den Unterprozess up Durch die Zerlegung einer Aktivität A in einen Unterprozess up kann die Skalierbarkeit von Prozessstrukturen gezeigt werden. Beispiel Unterprozess zur Skalierung: Am Beispiel der Entwicklung eines elektronischen Systems hatten wir konstatiert, dass Komponenten wie Software (SW) und Hardware (HW) entwickelt werden müssen, bevor ein System aus den Komponenten entstehen kann. Ein Unterprozess Software kann, wie z. B. in [Abb. 3.11], die Aktivitäten A0: Anforderungsanalyse, A01: Testfall-Entwicklung, A02: SW-Entwicklung, A03: SW-Test und A04: SW-Freigabe enthalten. Erst nachdem Aktivität A04, die Freigabe der SW abgeschlossen und beglaubigt durch die Unterschrift des Entwicklers ist, darf die SW verwendet werden und erst damit gilt der up SW als abgeschlossen. Ebenso ist ein up zur HW Entwicklung denkbar. Die Struktur und Aktivitäten des up HW können sich von denen des up SW stark unterscheiden. An den beiden Beispielen zu Unterprozessen konnte der up als strukturierendes (gruppierendes) Konzept bei Prozessen veranschaulicht werden. Entscheidend ist die Möglichkeit zur Skalierung und Verschachtelung von Aktivitäten in bzw. zu Unterprozessen. Definition 3.21: Elementarprozess und Aufgabe Werden Unterprozesse bis auf die unterste Ebene zerlegt, so spricht man von einem Elementarprozess bei nicht-teilbaren betrieblichen Vorgängen spricht man von einer Aufgabe. Beispiel Elementarprozess mit zwei Aufgaben: Bei einem Freigabe-Prozess eines Sensors müssen zwei verantwortliche Experten, einer beim beauftragenden Fahrzeughersteller und einer beim fertigenden Auftragnehmer, dem Zulieferer, die Fertigungsfreigabe unterzeichnen. Die Reihenfolge der Unterschriften ist vorgegeben. Der Freigabe-Prozess ist in zwei Aufgaben Unterschrift_Auftraggeber und Unterschrift_Auftragnehmer unterteilt. Dies sind zwei nichtteilbare Vorgänge, welche durch die vorgegebene Reihenfolge einen (sequenziellen) Elementarprozess darstellen. 78

103 WPIM Modellbildung und Methodenentwurf Phasenmodell zum Innovationsprozess Das in [Abb. 3.12] gezeigte Phasenmodell ist repräsentativ für Innovationsprozesse. Die Entwicklung dieses Phasenmodells erfolgte in zwei Vorträgen und Diskussionen innerhalb der Berata Akademie 69 mit Beratern der Automobilindustrie. Dieses Modell für die Entwicklung von Komponenten 70, wie z. B. Steuergeräten, wird von Experten der Automobilindustrie als exemplarisches Modell betrachtet und ist an das V-Modell 71 [Vers99; VuGl03] angelehnt. Für die Automobilindustrie werden die Trennung und die bestehenden Schnittstellen von Fahrzeugherstellern und Zulieferern als beispielhaft für Kooperationen angesehen. Produktkonzept und Produktspezifikation werden üblicherweise durch die Fahrzeughersteller vorgegeben, die Produktentwicklung (auf Komponentenebene) geschieht wiederum bei den Zulieferern. Diese Trennung wird vom vorliegenden Prozessmodell unterstützt. Abb. 3.12: Exemplarische Phasen in Innovationsprozessen [Meix03; VoHe06c] Je nach Ausrichtung und Umfeld der Innovation sind noch weitere Phasen denkbar. Allgemeine Phasenmodelle für die Entwicklung von der Idee bis zum Produkt lassen sich nach [Schnieder in VuGl03, S. 7] schwerpunktartig meistens in fünf bis sieben Phasen einteilen: Problemanalyse und Anforderungsdefinition Systementwurf und Systemspezifikation Komponentenentwurf und Komponentenspezifikation Implementierung und Installation Betrieb und Instandhaltung. [Schnieder in VuGl03, S. 7] Ressourcen wurden in der bisherigen Betrachtung zu Phasen- und Prozessmodellen noch nicht berücksichtigt. Die Einführung und Modellierung von Ressourcen erfolgt im weiteren Verlauf der Arbeit Einführung einer (inhaltlichen) Ressourcen-Dimension Die Ressourcen-Dimension ermöglicht die Zuordnung von Ressourcen zu Aktivitäten. Die Prozessstruktur steht im Mittelpunkt der Modellierung. Daher werden die Ressourcen den Prozessen, genauer den Aktivitäten, zugeordnet. Die Ressourcen-Dimension ermöglicht die Erweiterung der Prozesse um Ressourcen. Im Speziellen werden Ressourcen durch Relationen den Aktivitäten zugeordnet. 69 Berata Akademie ist die interne Vortrags- und Weiterbildungsplattform der Berata GmbH - heute Komponente wird hier stellvertretend für Elektronikbaustein verwendet. 71 V-Modell Dokumentation - 79

104 WPIM Modellbildung und Methodenentwurf Definition 3.22: Experte Experten (E) sind eine Menge menschlicher Akteure, die am Innovationsprozess beteiligt sind, die innerhalb der Domäne der Innovation Expertise aufweisen und zudem über Branchenkompetenz in fertigenden Industrien, insbesondere der Automobilindustrie verfügen. Experten haben die Attribute: ID, Anrede, Vorname, Nachname, Bild, , Telefon, Beschreibung, VertreterVon, Rolle, Expertise. Abstrakte E:={experte1, experte2, experte3, }; Mit den Ausprägungen bzw. Rollen {Abteilungsleiter, Projektleiter, Entscheider, Verantwortlicher, Ersteller, Vertreter,...} in Abhängigkeit vom betrachteten Unternehmen und Kontext. Konkrete Experten sind identifizierbar über Personalnummern (auch ID) oder Namen. Konkrete E:={Anton_Müller, Bernd_Maier,...}; Derartige Ressourcen sind in Innovationsprozessen zu allokieren, um einen maximalen Nutzen bezüglich der Innovationskraft zu stiften. Definition 3.23: Dokument Dokumente (D) können als Menge sowohl digitaler als auch nicht-digitaler Schriftstücke, Patente, Prozessbeschreibungen und Verfahrensanweisungen verstanden werden, die innerhalb eines Innovationsprozesses einen Nutzen oder Mehrwert stiften können. Typischerweise betrachten wir Dokumente, die einem Unternehmen zur Verfügung stehen und digitalisierbar sind. Dokumente haben die Attribute: ID, Titel, Datum, Autoren, Herausgeber, Beschreibung. Anmerkung: Es kommen verschiedene Typen von Dokumenten vor, wie z. B. Patente oder Handbücher. Diese können in unterschiedlichen Versionen oder Sprachen vorliegen und zudem unterschiedliche Dateiformate haben, z. B..doc,.xls,.pdf, aber auch spezielle/proprietäre Formate wie CAD-Dateien. Auch Templates (.dot oder.xlt) im Sinne eines Meta-Files sind denkbar. Wir setzen die elektronische Verfügbarkeit voraus und modellieren: D:={Patente, Prozessbeschreibungen, Verfahrensanweisungen, Lessons Learned }; Beispielsweise sind Patente instanziierbar durch Patent:= {patent1, patent2, patent3, }; Die Instanzen vom (Datei-) Typ {.doc,.xls,.pdf,.cad, }; Definition 3.24: Verweis Verweise (V) bzw. URLs verweisen auf lokale oder entfernte Ressourcen. Über Verweise können externe Ressourcen für den Innovationsprozess nutzbar gemacht werden. Verweise können auf im Intra- oder Internet verfügbare Seiten (Web-Ressourcen) oder Dateien und Dienste referenzieren. Das können z. B. Patent-Dateien auf einem Patent-Server sein. 80

105 WPIM Modellbildung und Methodenentwurf Weitere Herausforderungen zur Patentrecherche sowie zur visuellen Aufbereitung der Suchergebnisse zeigen [LVKH07]. Die Instanziierung zu Verweis (V): Verweis V:= {verweis1, verweis2, verweis3, }; Links ist typischerweise ein Protokoll-Typ vorangestellt: Protokoll-Typen {http:, https:, ftp:, mailto:, }; Definition 3.25: Systeme Darunter verstehen wir Systeme (S) die bei der Durchführung der Aktivitäten unterstützen. Das können z. B. Softwarewerkzeuge, Programme, Entwicklungsumgebungen oder (Semantic-) Web-Anwendungen sein. Definition 3.26: Organisationseinheiten Das sind Strukturen innerhalb von Organisationen, diese dienen als strukturierendes Ordnungskonzept innerhalb einer Organisation. Beispielsweise sind das lokale, räumliche oder virtuelle Einheiten in einer Organisation wie Standorte, Gebäude oder Abteilungen. Definition 3.27: Ressource Wissensressourcen im Kontext von Innovationsprozessen sind Dokumente, Verweise, Systeme Organisationseinheiten oder Prozesse, aber ebenso menschliche Wissensträger (Experten). Mathematische Formalisierung zu Ressourcen: Einer Aktivität können beliebig viele Ressourcen aus der Ressourcenmenge RES zugeordnet werden. Zu den Ressourcen zählen u. a.: RES := {E,D,V,S,O,P}; mit E:= Experten, D:= Dokumente, V:= Verweise, S:= Systeme, O:= Organisationseinheiten; P:= Prozesse; Dass Prozesse den Ressourcen zugeordnet werden, unterstützt die rekursive Definition von Prozessen. Somit können einem Prozess weitere Prozesse im Sinne einer Ressource zugeordnet werden. Je nach Domäne sind ggf. weitere Ressourcen aufzunehmen. [Tab. 3.3] zeigt exemplarische Ressourcen und den Aufbau einer Ressourcen-Hierarchie: Typen und Sub-Typen Relation Erklärung Dokument is-a (document 1, resource) document 1 ist eine Ressource Experte is-a (expert 1, resource) expert 1 ist eine Ressource SUB: Patent is-a (patent 1, document) patent 1 ist ein Dokument Tab. 3.3: Ressourcen und Ressourcen-Hierarchie Anhand der is-a Relation werden z. B. Dokumente und Experten als Ressourcen klassifiziert. Im weiteren Verlauf der Arbeit wird die Typisierung von Prozessen zu Innovationsprozessen erläutert. 81

106 WPIM Modellbildung und Methodenentwurf Typisierung von Prozessen zu Innovationsprozessen Grundlegende Konzepte, Struktureigenschaften sowie eingeführte Ebenen werden für Innovationsprozesse von den Prozessen übernommen. Innovationsprozesse bilden eine Typisierung der Prozesse aus. Hierbei sind die Aktivitäten sowie das Prozessergebnis auf die Hervorbringung von Innovationen ausgelegt und sollen dabei durch verfügbare Ressourcen unterstützt werden. Definition 3.28: Innovationsprozess Innovationsprozesse (ip) sind Prozesse mit der Erweiterung um Ressourcen, wobei die Ressourcen gezielt den Aktivitäten zugeordnet werden. Bedingung und mathematische Formalisierung zu Innovationsprozessen ip: Ein ip beinhaltet mindestens zwei (n=2) bis beliebig vielen (n>2) Aktivitäten a n. A:= {a 1, a 2, a 3,,a n }; ip A A mit A A := {(a i,a j ) (a i A) ip:= {a k } mit 2 k n; (a j A)} Ein ip beinhaltet mindestens eine (m=1) bis beliebig viele (m>1) Relation r m. R:= {r 1, r 2, r 3,,r m }; ip R R mit R R := {(r i,r j ) (r i R) ip:={r k }; mit 1 k m; (r j R)} Jede Aktivität a x steht somit mit mindestens einer weiteren Aktivität a y in Relation r u, mit a x, a y A und r u R. Eine Relation verbindet genau zwei Aktivitäten. Einer Aktivität im Innovationsprozess können Ressourcen zugeordnet werden, die bei der Durchführung der Aktivität unterstützen. [Tab. 3.4] zeigt die Zuordnung von Konzepten/Ressourcen zu Aktivitäten: Konzepte der Dimension Relation Erklärung Ressource RESSOURCE (ressource 1, a) ressource 1 wird der Aktivität a zugeordnet Dokumente DOCUMENT (document 1, a) document 1 wird der Aktivität a zugeordnet Experte EXPERT (expert 1, a) expert 1 wird der Aktivität a zugeordnet Tab. 3.4: Ressourcen und Zuordnung zu Aktivitäten Zunächst wird generell die Zuordnung von Ressourcen zur Aktivität a aufgezeigt. Weiterführend werden Dokumente und Experten der Aktivität a zugeordnet. Im weiteren Verlauf der Arbeit beleuchten wir organisatorische Zusammenhänge zwischen Aktivitäten Einführung einer (orthogonalen) Aktivitäten-Ebene Die Aktivitäten-Ebene ist eine orthogonale Ebene zu den strukturell-zeitlichen Ebenen der Prozesse. Ziel der Aktivitäten-Ebene ist es, Zusammenhänge zwischen Aktivitäten auszudrücken und Aktivitäten nach organisatorischen Gesichtspunkten zu gruppieren. 82

107 WPIM Modellbildung und Methodenentwurf Definition 3.29: Aktivitäten-Pool Ein Aktivitäten-Pool gruppiert Aktivitäten, die in einem organisatorischen Zusammenhang stehen. Ein Aktivitäten-Pool stellt eine echte Teilmenge der Aktivitäten eines Prozesses dar. Unter organisatorisch subsumieren wir thematisch, inhaltlich, projektlich, aktivitätenträgerspezifisch und örtlich gruppierbare Aktivitäten. Die Analogie Pool für Gruppen oder Cluster von Aktivitäten sowie Swimlane für Sequenzen entstammt dem Modellierungs-Werkzeug BusinessProcess VisualArchitect [BPVA], bzw. der BPMN 72 [Allw08, BPMN]. In der Praxis kommt eine Vielzahl von Begriffen vor, die für organisatorische Zusammenhänge und Strukturen von Aktivitäten in Prozessen und Arbeitsabläufen (engl. workflows) verwendet werden. Ein Aktivitäten-Pool hat die Attribute: ID, Titel, Beschreibung, Start, Ende, Version, Schlagworte, Eingabedokumente, Ausgabedokumente, Ansprechpartner, Verantwortlicher, Vertretung, Links, Details, Vorgänger, Nachfolger, Abteilung und als Besonderheit Aktivitäten. Darunter werden alle im Pool enthaltenen Aktivitäten gelistet. Mathematische Formalisierung zu Aktivitäten-Pools: Pool P mit A:= {a 1, a 2, a 3,,a n }; Ein Pool kann z. B. eine Matrixorganisation innerhalb eines Automobilherstellers wiedergeben. Pool:= {pool 1, pool 2, pool 3,, pool j }; pool n Pool; j + ; Ein Prozess kann keine bis beliebig viele Pools enthalten. P:= {pool 1, pool 2, pool 3,, pool j }; Einschränkung: Ein Pool enthält mindestens zwei (j=2) oder mehrere (j>2) Aktivitäten a n. A:= {a 1, a 2, a 3,,a n }; Pool:= {a 1, a 2, a 3,, a j }; mit 2 j; Konkret können Pools {Matrix-Strukturen, Projekte, Fahrzeugprojekte, Baureihen, Fertigungslinien, externe Organisationsstrukturen,...} sein. Ein minimaler Pool besteht aus zwei Aktivitäten a 1, a 2 und einer homogenen Relation 73 R: R(a 1, a 2 ); mit a 1, a 2 A Pool min = {A R} mit a 1, a 2 A und r 1 R. 72 BPMN: Die Business Process Modeling Notation (engl. Modellierungs-Notation für Geschäftsprozesse) ist eine grafische Spezifikationssprache der Wirtschaftsinformatik. Mit den Symbolen ist es möglich, Geschäftsprozesse und Arbeitsabläufe (techn./engl. workflows) modellieren zu können. 73 Homogene Relation: eine Relation über den Elementen einer Menge. 83

108 WPIM Modellbildung und Methodenentwurf Abb. 3.13: Aktivitäten-Pool mit drei Aktivitäten Beispiel Aktivitäten-Pool: Sind mehrere Aktivitäten einem Projekt oder einer Abteilung zuzuordnen, so können diese Aktivitäten in einem Pool zusammengefasst werden. Müssen neue Komponenten aus verschiedenen (hier drei) Entwicklungsabteilungen (mit jeweils einer der Aktivitäten A00, A02, A04) in einem Fahrzeug erprobt werden, so werden die Komponenten von einer zentralen Werkstatt (hier modelliert als Pool) fachmännisch in dem Fahrzeug (sog. Versuchsträger) verbaut und der Versuchsträger danach den Experten (bzw. hier Test- Ingenieuren) zur Verfügung gestellt. Der Pool steht hierbei für eine zentrale Abteilung oder auch einen zentralen Dienst. Beispiel: Pool-Konzept unterstützt flexible Organisationsformen: Ein Aktivitäten-Pool kann ebenso eine Projekt-Organisation erfassen und über starr-hierarchische Organisationsformen hinausgehen: In der Automobilindustrie ist es üblich, von Fahrzeugprojekten zu sprechen der Pool kann als solches Fahrzeugprojekt interpretiert werden. Um das Fahrzeugprojekt erfolgreich durchführen zu können, sind die Aktivitäten (A00; A02, A04) mit den verbundenen Ressourcen gem. dem WPIM-Ansatz zu allokieren. Ein Experte ist nach wie vor seiner Abteilung mitsamt Abteilungsleiter zugeordnet, hat aber eine weitere organisatorische Zuordnung zu einem Fahrzeugprojekt (hier dem Pool) mit einem Projektleiter. Flexible und matrixartige Organisationsformen können das Pool-Konzept unterstützen. Beispiel: Pools bei Kollaboration: Für die Entwicklung eines Steuergeräts müssen die Aktivitäten A00-A04 durchgeführt werden. Der Fahrzeughersteller beauftragt die Aktivitäten A00, A02 und A04 bei einem Zulieferer, so kann der Zulieferer hier als Pool interpretiert werden also als eine externe kollaborierende Organisation, der die Aktivitäten A00, A02 und A04 übertragen werden. Ein Pool ermöglicht auch die Modellierung von organisatorischen Einheiten außerhalb des zu betrachtenden Unternehmens. Definition 3.30: Pool-Aktivität Die Aktivitäten die einem Aktivitäten-Pool (kurz Pool) zugeordnet sind, bezeichnet man als Pool- Aktivitäten (a pool ). Mathematische Formalisierung zu Pool-Aktivitäten: a pool Pool; Definition 3.31: Pool-Relation Die Relation R(POOL) ordnet eine Aktivität a einem Aktivitäten-Pool zu. 84

109 WPIM Modellbildung und Methodenentwurf Abb. 3.14: Relationale Zuordnung einer Aktivitäten zu einem Pool Mathematische Formalisierung zu Pool-Relationen: Pool P; a A; R(POOL) A Pool Die Überlegungen gelten ebenfalls für spezifischere Zusammenhänge und Gruppierungen von Aktivitäten zu den Konzepten Thema, Kontext/Inhalt, Projekt und Ort. Die Aktivitäten stehen im Mittelpunkt der Betrachtung und daher werden die Aktivitäten den Konzepten der Aktivitäten- Dimension zugeordnet. Typen der Dimension Relation Erklärung Aktivitäten-Pool POOL (a, pool 1 ) Aktivität a wird dem Pool pool 1 zugeordnet Thema TOPIC (a, topic 1 ) Aktivität a wird dem Thema topic 1 zugeordnet Kontext/Inhalt CONTEXT (a, context 1 ) Aktivität a wird dem Kontext context 1 zugeordnet Projekt PROJECT (a, project 1 ) Aktivität a wird dem Projekt project 1 zugeordnet Ort LOCATION (a, location 1 ) Aktivität a wird dem Ort location 1 zugeordnet Tab. 3.5: Relationen der Aktivitäten-Dimension Hinweise zur Modellierung mit Beispielen zur Ausprägung: Mögliche Pool-Typen: POOL:={Verantwortungsbereich, Kostenstelle, } TOPIC:={Methoden, Kreativmethoden, Brainstorming, } CONTENT:={Testmanagement, Patentmanagement, } PROJECT:={project 1, project 2, }; LOCATION:={Abteilung, Standort, München, }; 85

110 WPIM Modellbildung und Methodenentwurf Aktivitäten-Modell: Typen, Instanzen und Bibliothek Ausgehend vom Aktivitäten-Modell zeigen wir die Typisierung und Instanziierung zu Aktivitäten auf. Dies erfolgt in Analogie zum Begriff der Klasse 74 in der objektorientierten Programmierung mit der Abgrenzung, dass wir auf die Modellierung der Eigenschaften von Aktivitäten (Attributen) eingehen und die Methoden zur Manipulation der Eigenschaften zurückstellen. Definition 3.32: Aktivitäten-Modell Das Aktivitäten-Modell beschreibt die wesentlichen und notwendigen Eigenschaften von Aktivitäten. Notwendige Eigenschaften bei WPIM sind z. B.: Identität, Name, Beschreibung, Experten, Ressourcen, Ergebnis. Ressourcen und Experten werden explizit durch folgende Eigenschaften gekennzeichnet: Experten (Ersteller, Verantwortung, Besitzer, Vertreter); Ressourcen (Dokumente, Verweise, Systeme, Prozesse). Das Aktivitäten-Modell wird auf technischen Ebenen durch das Datenmodell repräsentiert. Definition 3.33: Aktivitäten-Instanz Eine Aktivitäten-Instanz a ni ist eine (konkrete) Belegung/Ausprägung zu einem (abstrakten) Aktivitäten-Modell. Der Aktivität a n, die eindeutig identifiziert werden kann, wird bei der Instanziierung zu jedem Attribut ein Attributwert zugeordnet 75. Mathematische Formalisierung zu Instanzen: A:= {a 1, a 2, a 3,,a n }; a n A; a n := {a n1, a n2, a n3,,a ni }; a ni a n ; Beispiel: Aus den Aktivitäten wird die Aktivität SW-Test ausgewählt und für jeden durchgeführten Durchlauf der i-durchläufe eine Instanz sw-test i angelegt. A:= {...,SW-Test, SW-Freigabe,...} SW-Test:= {sw-test 1, sw-test 2, sw-test 3,, sw-test i }; Das Aktivitätenmodell wird instanziiert und mit konkreten Werten belegt. Allgemein bezeichnen wir Instanzen als digitale Objekte. In Analogie zur Datenspeicherung: Ein Datenmodell wird auf ein Schema abgebildet und das Schema dann konkret instanziiert. Zu beachten ist die Reihenfolge: Zunächst entsteht ein 74 Klasse steht in der objektorientierten Programmierung als abstrakter Oberbegriff für die Beschreibung der gemeinsamen Struktur und des gemeinsamen Verhaltens von realen Objekten (Klassifizierung). Die Klasse dient als Bauplan für digitale Instanzen von realen Objekten und fasst hierfür notwendige Eigenschaften (Attribute) und zur Manipulation der Eigenschaften notwendige Methoden zusammen. 75 Werden Attributen Attributwerte zugeordnet, spricht man von Typisierung. Häufig werden zur Vereinheitlichung zuordenbare Werte verwendet, ein vordefinierter Wertebereich wird als Vokabular eines Attributs bezeichnet. 86

111 WPIM Modellbildung und Methodenentwurf Aktivitätenmodell. Gefolgt von konkreten (Aktivitäten-) Instanzen. Aus der Menge aller Instanzen kann dann ein Schema abgeleitet werden. Diese Struktur von Aktivitätenmodell, Schema und Instanz haben wir für WPIM übernommen ebenso wie den zeitlichen Aufbau von Aktivitätenmodell, Instanzen und abgeleiteten Schemata. Definition 3.34: Merkmal Merkmale 76 haben eine konkrete Ausprägung bzw. einen Wert. Die Aktivitäten haben eine unterschiedliche Anzahl und Art von Merkmalen. Einige Merkmale sind allen Aktivitäten gemein, andere sind typ-spezifisch. So entstehen Aktivitäten-Typen mit den benötigten Eigenschaften und Instanzen mit den konkreten Ausprägungen der Merkmale. Definition 3.35: Eigenschaft Eigenschaften von Aktivitäten bei WPIM sind z. B. ID, Name, Beschreibung, Experten, Ressourcen, Ergebnis. Eigenschaften werden u. a. in der objektorientierten Programmierung auch als Attribute bezeichnet. Definition 3.36: Aktivitäten-Kategorie Eine Aktivitäten-Kategorie beinhaltet Instanzen mit gleichen Merkmalen. Somit definieren Merkmale eine Kategorie. Definition 3.37: Aktivitäten-Typen Ein Aktivitäten-Typ fasst Eigenschaften einer bestimmten Kategorie zusammen. Dabei bildet ein Aktivitäten-Modell verschiedene Typen aus. Jede Instanz ist von einem Aktivitäten-Typ. Unter Ähnlichkeit wird hierbei die Ähnlichkeit von Typen 77 (auf der Ebene der Eigenschaften von Aktivitäten) verstanden. Mathematische Formalisierung: a n A; a n vom Aktivitäten-Typ := {...; SW-Spezifikation, SW-Test; Freigabe;... } Typ1: Typ(SW-Spezifikation) hat Eigenschaften {Entwickler, Dauer, Risiken,...} Typ2: Typ(SW-Test) hat Eigenschaften {Entwicklungsumgebung, Skript-Sprache,...} Typ3: Typ(Freigabe) hat Eigenschaften {Freigabe-Hierarchie, Benachrichtigung,...} Beispiel: SW-Spezifikation, SW-Test oder Freigabe sind Typen von Aktivitäten. Die Aktivitäten haben eine unterschiedliche Anzahl und Art von Merkmalen und bringen (z. B. unterschiedliche Ergebnisse) wie Dokumente, SW oder Testergebnisse hervor. Einige Merkmale sind allen Aktivitäten gemein, andere typ-spezifisch. 76 Bei der Merkmalextraktion werden Werte von Objekten analysiert. Ein (digitales) Objekt hat eine Eigenschaft mit einem konkreten Merkmal (auch Ausprägung) der Eigenschaft. Somit ist ein Merkmal auch eine Eigenschaftsausprägung. 77 Der Unterschied zwischen Klasse und Typ besteht darin, dass mit einer Klasse eine aktuelle, möglicherweise veränderliche Auswahl von Objekten gemeint ist, während der Typ unabhängig davon erhalten bleibt. So ändert sich z. B. die Klasse der roten Äpfel, wenn Äpfel reifen (also das Attribut rot erlangen und somit Klassenmitglied werden) oder gegessen werden. Der Typ roter Apfel bleibt dagegen unverändert, da er sich nicht auf einen bestimmten Apfel bezieht [Tabe06, S. 49]. 87

112 WPIM Modellbildung und Methodenentwurf Anmerkung zur Modellierung: Wird in einem Prozessmodell eine Aktivität, z. B. Freigabe benötigt, so entsteht ein Aktivitäten-Typ mit den benötigten Merkmalen und eine Instanz mit den konkreten Ausprägungen der Merkmale. Definition 3.38: Muster-Aktivität Eine Muster-Aktivität (ma), auch als Schema bezeichnet, ist die inhaltliche Zusammenfassung bzw. Klassifizierung existenter Instanzen von Aktivitäten. Zu jedem Instanz-Typ gibt es genau eine Muster-Aktivität. Für zukünftige Instanziierungen dient die Muster-Aktivität als Schema. Mathematische Formalisierung: ma A; ma 1 ma 2 = { }; ma t vor ma t+t Hierbei stellt t die zeitliche Abhängigkeit dar. Ziel ist es, ähnliche Instanzen von Aktivitäten inhaltlich und strukturell zu klassifizieren, um Muster-Aktivitäten zu erzeugen. Die strukturelle Klassifizierung kann gut durch die Aktivitäts- Typen erbracht werden. Die Muster-Aktivitäten sollen zukünftig wieder verwendet und instanziiert werden. So kann ein Wissenstransfer von einer Aktivität über das Muster im Sinne eines Wissensspeichers auf eine spätere Instanz der Aktivität erfolgen. Beispiel: Eine Software wird getestet und in einer Entwicklungsumgebung ein Testskript geschrieben. Der Innovationsprozess wird in WPIM abgebildet und für den Softwaretest eine Aktivität Softwaretest (vom Typ Softwaretest) instanziiert. Hierzu wird in der Aktivität z. B. als System-Ressource eine Entwicklungsumgebung und das Testskript referenziert. Diese Instanz kann als Muster-Instanz Softwaretest (vom Typ Softwaretest) betrachtet werden. Wird die SW weiterentwickelt, so muss erneut der Innovationsprozess und auch die Aktivität Softwaretest durchlaufen werden. Der Entwickler kann auf die Muster-Aktivität Softwaretest zugreifen und diese instanziieren. In der Instanz beschrieben, findet er die Referenz auf die zu verwendende Entwicklungsumgebung und auch das Testskript. Dieser Durchlauf lässt sich nun iterativ wiederholen. Anmerkungen: Eventuell muss ein weiteres Testskript in die Instanz Softwaretest aufgenommen werden, die dann auch in die Muster-Instanz Softwaretest übernommen werden muss. Inhaltliche Änderungen von Instanz zu Instanz lassen sich über die Muster-Aktivität erfassen. Ebenso kann die vorbildliche Praxis (engl. best practices) in die Muster-Aktivität einfließen. Für verschiedene Typen von Aktivitäten entstehen jeweils Muster-Aktivitäten. Wie hier abgehandelt, entsteht eine Muster-Aktivität zu Softwaretest, ebenso kann eine Muster- Aktivität zu Hardwaretest usw. entstehen. Zu jeder Klasse von Instanzen einer Aktivität kann eine Muster-Instanz gebildet werden. Definition 3.39: Aktivitäten-Bibliothek Die Sammlung der Muster-Aktivitäten mit zugehörigen, bedateten und versionierten Aktivitäten- Instanzen. 88

113 WPIM Modellbildung und Methodenentwurf Die Muster-Aktivitäten sind eindeutig gekennzeichnet, die Instanzen versioniert bzw. über eine ID eindeutig identifizier- bzw. referenzierbar. Die Aktivitätenbibliothek kann auch als Sammlung von Verlinkungen und Verlinkungen zwischen Muster und Instanzen aufgebaut werden. Diese Bibliothek hat das Ziel, bei der Modellierung zukünftiger Prozesse zu unterstützen Prozess-Modell: Typen, Instanzen, Schemata und Baukasten In Analogie zum Begriff Modell können Prozess-Modelle als zweckorientierte, vereinfachte Abbildungen von Prozessen aufgefasst werden. Bei der Prozessmodellierung (engl. process modeling) werden Prozesse oder Ausschnitte abstrahiert, z. B. grafisch dargestellt und modelliert. Wir betrachten Innovationsprozesse, die eine Typisierung zu (Geschäfts-) Prozessen darstellen. Definition 3.40: Prozess-Modell Das Prozess-Modell beschreibt die relevanten Eigenschaften eines Prozesses. Bei WPIM zählen zu diesen Prozess-Eigenschaften: ID, Name, Beschreibung, Ressourcen mit Experten. Zudem enthält dieses Prozess-Modell die untergeordneten Modelle von Aktivität, Unterprozess, Pool und weiteren Prozesselementen, wie z. B. Konnektoren bzw. Splittern. Anmerkungen zur Modellierung des Prozess-Modells: Mögliche Attribute und Ressourcen eines Prozesses: Prozess (ID, Name, Beschreibung, Experten, Ressourcen). Die folgende rekursive Definition zu einem Prozess erlaubt, dass eine Ressource ein Prozess ist. Durch das Hinzufügen einer Ressource, genauer eines Prozesses, wird die Rekursion unterstützt und somit auch alle untergeordneten Konzepte eines Prozesses: Prozess(Aktivitäten, Unterprozesse, Pools, Prozesse) Definition 3.41: Prozess-Instanz Eine Prozess-Instanz ist eine (konkrete) Belegung/Ausprägung zu einem (abstrakten) Prozess, die eindeutig identifiziert werden kann. Die Modellierung von Prozessen unterliegt der Verwendung der erörterten Konzepte und den beschriebenen Regeln, dennoch stehen bei der Modellierung von Komplexität Freiheitsgrade zur Verfügung. Wir unterscheiden auf Prozess-Instanz-Ebene zwischen inhaltlich-ähnlichen Prozess- Typen und strukturell-ähnlichen Prozess-Schemata: Definition 3.42: (Inhaltliche) Prozess-Typen Entstehen bei der Ausprägung von Instanzen (der Typisierung von Instanzen des Prozess- Modells) inhaltlich-ähnliche Instanzen des Prozess-Modells, so spricht man von Prozess-Typen. Unter inhaltlicher Ähnlichkeit wird hierbei die Ähnlichkeit von Attributwerten (auf der Ebene der Repräsentation von Daten die Zuordnung von Werten zu Attributen) verstanden. 89

114 WPIM Modellbildung und Methodenentwurf Beispiel: Prozess-Typen sind z. B. SW-Innovationsprozesse oder HW-Innovationsprozesse. Instanzen des selben Prozess-Typs sind inhaltlich-ähnlich bei möglicher abweichender Struktur. Instanzen von einem Typ weisen bei identischen Merkmalen ähnliche Inhalte auf. Definition 3.43: (Strukturelle) Prozess-Schemata Auf den Prozess-Typen lassen sich unter Berücksichtigung struktureller Eigenschaften Prozess- Schemata entwickeln. Hierbei werden bei der Modellierung insbesondere strukturelle Eigenschaften von Prozessen berücksichtigt. Beispiel: Instanzen vom selben Prozess-Schema sind strukturell identisch. So enthalten alle SW- Innovationsprozesse inhaltlich-ähnliche Aktivitäten bei gleicher Struktur. Strukturelle Besonderheiten sind z. B. Schnittstellen von Prozessen zu Organisationseinheiten oder Zuliefer- Unternehmen. Definition 3.44: Muster-Prozess und Prozess-Pattern Alle Prozess-Instanzen zu einem Prozess mit identischer Struktur bilden ein Schema, den sog. Muster-Prozess aus. Dies ist ein Muster eines Prozesses, das als Vorlage hinsichtlich Struktur und Inhalten dient und bei zukünftigen Prozessdurchläufen instanziiert werden kann. Teilstrukturen werden als Prozess-Pattern bezeichnet [vgl. Aals03]. In diesem Rahmen sprechen wir von der sog. Evolution von Prozessen [vgl. Aals03]. Definition 3.45: Prozess-Baukasten Eine Sammlung von Muster-Prozessen (engl. prozess pattern) und der Aktivitäten-Bibliothek. Der Prozess-Baukasten hat das Ziel, bei zukünftigen Innovationen und inkrementellen Entwicklungen Muster-Prozesse und Prozess-Instanzen bereitzuhalten, um Instanziierungen schnell und kosten-reduziert sowie qualitativ hochwertig (fehlerreduzierend) durchzuführen. Definition 3.46: Ressourcen-Instanzen Konkrete Exemplare von Ressourcen, die eindeutig identifiziert und referenziert werden können, bezeichnen wir als Ressourcen-Instanz. Die Zusammenführung von Schemata (engl. schema integration) stellt eine grundlegende Herausforderung der Datenmodellierung dar. Namensräume (engl. namespaces), z. B. für XML, unterstützen bei der eindeutigen Zusammenführung und helfen verschiedene Konzepte mit identischen Bezeichnern zu unterscheiden, mehr dazu unter [Kapitel URI, URIref und Namespaces]. Prozesstypisierung, Ordnungen und Einordnung: Ausgehend von der Unterscheidung in geordnete (strukturierte) oder ungeordnete (unstrukturierte) Prozesse nach [HESS07a], betrachten wir strukturierte Prozesse mit definierter Anzahl von Aktivitäten, Transformationen und festgelegter Reihenfolge. Als vollständige Untermenge gehen wir auf Innovationsprozesse ein, die wir in der Domäne der fertigenden Industrien und im Speziellen der Automobilindustrie 90

115 WPIM Modellbildung und Methodenentwurf betrachten. Innovationsprozesse sind zerlegbar in Unterprozesse die wiederum aus Aktivitäten aufgebaut sind. Eine hierarchische Ordnung vom (allgemeinen) Konzept Prozess hin zum (speziellen) Konzept Aktivität lässt sich somit nachvollziehen [BPVA]. Erweitert man diese taxonomische Struktur um weitere Relationen und ergänzt diese mit Ressourcen, so sind Überlegungen dahingehend notwendig, die Prozess-Taxonomie zur Prozess-Ontologie zu erweitern. [VoHe07] Die definierten Konzepte können in digitale Objekte, exakter in XML (Daten)-Strukturen überführt werden. Einen Ansatz hierzu bieten die Document Type Definition (DTD) und das XML Schema (XSD), beschrieben in [4.1.7 SAX vs. DOM] Einführung einer (maschinenlesbaren) Semantik-Dimension Semantiken können auf verschiedenen Modell-Ebenen eingeführt werden. Die Ausprägung von Semantik-Dimensionen erscheint sinnvoll in dem Datenmodell, dem Aktivitätenmodell und dem Prozessmodell. Einen Einstieg in die Semantik und das Resource Description Framework bietet [Kap. 4.2]. Im Folgenden gehen wir auf diese möglichen Ausprägungen von Semantik- Dimensionen ein. Die Semantik-Dimension im Datenmodell ermöglicht semantische Repräsentationen von Konzepten und Attributen. Durch Namespaces [vgl. Kapitel 4.1.1] und Vokabulare kann die eindeutige Vergabe von Namen sichergestellt werden. Die Semantik von Vokabeln ist somit innerhalb des Namespaces sichergestellt und kann durch Namespaces über Anwendungen hinweg ausgetauscht werden. Die Semantik-Dimension im Aktivitätenmodell zielt auf die semantische Beschreibung von Aktivitäten und Relationen ab. Dazu ein Beispiel: Verantwortet ein Experte einen Pool, so zeichnet er auch verantwortlich für die darin enthaltenen Aktivitäten a pool. Die im Pool enthaltenen Aktivitäten können untereinander als gleichwertige Konzepte betrachtet werden, d. h. ohne hierarchische Abstufung. Der Pool ist ein den Aktivitäten (virtuell) übergeordnetes Konzept. Zwischen dem Pool und den im Pool enthaltenen Aktivitäten entsteht eine Sub- Beziehung für die Aktivitäten und eine Super-Beziehung für den Pool. In Unternehmen sind identische Strukturen anzutreffen. Nicht alle Aufgabenträger kennen sich. Ein Kontakt (gleichwertiger Aufgabenträger) zueinander kann aber über einen übergeordneten Gesamtverantwortlichen (Super-Beziehung) hergestellt werden. Ein Wissensaustausch zwischen den Aufgabenträger kann so gezielt über diese Organisationshierarchien hergestellt werden. Eine Aktivität a hat mindestens einen Verantwortlichen v u Mitarbeiter aus der Menge aller Mitarbeiter (V). Diese Mitarbeiter sind somit verantwortlich für die Aktivität. av:= {v 1, v 2, v 3,,v u }; V u V; u + ; u max := ist begrenzt durch die Anzahl der Mitarbeiter im Unternehmen. Die semantische Relation sr zwischen diesen beiden Konzepten wird mit sr 1 : hatverantwortlichen sr 2 : istverantwortlichfuer 91

116 WPIM Modellbildung und Methodenentwurf bezeichnet und kann als semantische Tripel st mit dem Ressource Description Framework (RDF) wiedergegeben werden: st 1 := {A; sr 1 ; V} st 2 := {V; sr 2 ; A} sr 1 und sr 2 verhalten sich invers. Inverse Relationen stellen eine Spezialform von Relationen dar. Die Semantik-Dimension im Prozessmodell ermöglicht semantische Repräsentationen zu Prozessen und Ressourcen. Die Semantik im Prozessmodell kann z. B. durch die Verwendung von BPMN bzw. BPML vorgegeben werden. Abb. 3.15: Business Process Modeling Language 78 [Abb. 3.15] entstammt den XML Cover Pages 79 und dort der [BPML-2002, S. 17]. Es werden detaillierte Beschreibung zu Simple Activity, Complex Activity, Activity Set sowie Process im Sinne der BPML mit zugehörigen Relationen und Kardinalitäten gegeben. Als Besonderheit und Erweiterung werden bei WPIM alle Relationen und Ressourcen im Innovationsprozess mittels RDF semantisch annotiert. Durch RDF können alle Ressourcen eindeutig identifiziert und semantische beschrieben werden. Eine Ressource, die mit unterschiedlichen Namen/Bezeichnern ausgestattet ist, kann dadurch als semantisch einzig erkannt werden Exkurs: Formalisierte Abläufe in einem Prozess Aktivitäten haben Ein- und Ausgangsgrößen. Über Bedingungen wird eine Aktivität gestartet. Wurde ein Startzustand in einen Endzustand überführt, so werden Bedingungen an Folge- Aktivitäten übergeben, um diese zu starten. Dazu werden Zustandsübergänge mathematisch beschrieben: Eine Relation r überführt einen Anfangszustand a start in einen Endzustand a ende. Um eine Folgeaktivität (hier: a ende ) zu starten, müssen Anfangsbedingungen für diese Folgeaktivität abgefragt und übergeben werden. Diese Aktivität ist den Zuständen Q bzw. Zustandsübergangsfunktionen ( δ ) zuzuschreiben 78 Unter - - Business Process Modeling Language. November 13, 2002; abgerufen Coverpages.org: The Cover Pages is a comprehensive online reference collection supporting the XML family of markup language standards, XML vocabularies, and related structured information standards. Edited by Robin Cover since abgerufen

117 WPIM Modellbildung und Methodenentwurf [vgl. Mart03, Mart04]. Erst wenn diese Startbedingungen für die Folgeaktivität erfüllt sind, kann die Folgeaktivität gestartet werden. a start δ a ende mit a start, a ende A; und δ Q; Relationen geben nur den Ablaufpfad vor und achten auf die Erfüllung der Start- und Endbedingung der verknüpften Aktivitäten bzw. vergleichen diese. Die Kardinalitäten haben zulässige Wertebereiche mit definierten [min, max] Werten: a start [1,1] genau eine Start-Aktivität a i [0,*] keine bis beliebig viele Aktivitäten a ende [1,*] Mindestens eine Ende-Aktivität, auch mehrere zulässig δ [1,*] mindestens eine Zustandsübergangsfunktion Kardinalitäten für ER-Modelle werden ausführlich bei [FeSi98] erläutert. Ein Tripel (T) und die Tripel-Notation werden vorgestellt: Gerichtete Zustandsübergangsfunktion ( δ ) lassen sich in der Form a i δ a i+1 darstellen, dadurch wird impliziert, dass die Aktivität a i der Aktivität a i+1 vorgelagert vor() ist und a i+1 nachgelagert nach() ist. Dabei sind Mehrfachnennungen möglich. Die beiden Aktivitäten sind durch den Zustand δ auch die sog. Zustandsübergangsfunktion verbunden. vor(a i ) nach(a i+1 ) Mit Beendigung der Aktivität a i stehen alle Inputgrößen für die Folgeaktivität a i+1 bereit und diese kann begonnen werden. Führt man diesen Gedanken zu Ende, so wird deutlich: a start δ 1 a 1 δ 2 a 2 δ 3 δ i 2 a i-1 δ i 1 a i δ i a ende Ziel ist es, die schließende Aktivität a ende zu erreichen. Eine weitere Prozess-Formalisierung bieten Tripel der Form: T={a x ; δ i ; a y } mit a x, a y A; und δi Q. Diese Tripel stellen jeweils zwei Aktivitäten und eine Relation bzw. einen Zustandsübergang dar. Durch die freie Verknüpfung solcher Tripel lassen sich beliebig komplexe Innovationsprozesse modellieren und mathematisch abbilden [vgl. FeSi98]. In Anlehnung an Schwickert und Fischer [ScFi96] nutzen wir die Tipel-Notation und formalisieren den Prozess P formal als Tripel: P formal = (Z, f, s) Wobei Z den Zustandsraum, f die Aktionsfunktion und s Z eine Menge von Anfangszuständen darstellt. Der Prozess erzeugt alle Berechnungen, die durch die Aktionsfunktion aus den Anfangszuständen entstehen. [ScFi96, S. 4] 93

118 WPIM Modellbildung und Methodenentwurf Exkurs: Regeln, Status zur Steuerung sowie Konnektoren Regeln und regelbasierte Ansätze werden knapp vorgestellt. Prinzipiell könnten beliebige Aktivitäten durch beliebige Relationen frei miteinander kombiniert werden. Regeln, Definitionsund Wertebereiche grenzen diese Freiräume ein. Die freie Kombination von Aktivitäten und Relationen macht nur bedingt Sinn und sollte deshalb erfahrenen Modellierern überlassen werden, die den Innovationsprozess kennen. Bei regelbasierten Ansätzen können ungewünschte Konstellationen eben durch Regeln eingeschränkt oder unterbunden werden (negative Regeln). Positive Regeln definieren sinnvolle Kombinationen. Regel_l:= {vor(spezifikation), nach(lastenhefterstellung)}; Aktivität Spezifikation ist der Aktivität Lastenhefterstellung vorgelagert und Lastenhefterstellung ist der Spezifikation nachgelagert. Regel_2:= {wartet[freigabe_spec(true), nach(lastenhefterstellung)]}; Nachgelagerte Aktivität Lastenhefterstellung wartet auf Relation Freigabe_Spec, die zudem den Wert true übergeben muss. Einen solchen regelbasierten Ansatz verfolgt [Broc07 und Mena12]. Ziel ist es, implementierungsunabhängig aufzuzeigen, wie Prozesse und Innovationsprozesse beschreibbar sind. Eine mögliche, automatisierte relationale Verknüpfung von Ressourcen mit Prozessen kann auf Basis von Regeln geschehen. [Mena12] nutzt einen regelbasierten Ansatz um automatisiert personelle Nachfolger zu Aktivitäten zuzuordnen. Eine Einführung zum internen Status und Steuerungen. Sowohl Aktivitäten als auch Relationen sollten über einen internen Status zur Verfolgung des Prozessfortschritts verfügen. Ein binärer Status im Sinne einer Go/No-Go Regel könnte lauten: Aktivität (erledigt/nicht_erledigt). Relation: (durchlaufen/nicht_durchlaufen). [Mena12] zeigt dies an einem Relevanz-Status. Dieser Status zeigt personenbezogen, welche Person als Vertreter z. B. für eine Aktivität besonders geeignet ist. Es folgt ein Überblick zu Konnektoren, Splittern und Folgen: Einen guten Überblick zu Konnektoren, XOR- sowie UND-Konnektoren jeweils öffnend und schließend ODER-Verteiler und ODER-Verknüpfer sowie Pfade und Folgen, Ereignis-Prozess-Ketten (EPK) und Ereignis- Methoden-Ketten, vermittelt [Ritt99]. Zu Workflow-Musterabläufen 80 gibt van der Aalst [Aals03] einen detaillierten Einblick. Die Beziehungstypen lassen sich gut durch Muster beschreiben, so gibt es Muster, die einer Aktivität zwei oder mehrere Folgeaktivitäten zuordnen, sog. Splitter. Ebenso gibt es Beziehungstypen die zwei Aktivitäten bündeln, sog. Kombinatoren. [vgl. Ritt99]

119 WPIM Modellbildung und Methodenentwurf Grafischer Meta-Formalismus Um Prozesse mit konkreten Aktivitäten eindeutig identifizieren, annotieren und durchsuchen zu können, empfehlen wir den folgenden Meta-Formalismus. Durchaus sind weitere anwendungsspezifische Attribute und adaptierte Kardinalitäten denkbar. Abb. 3.16: Frühes Meta-Modell zu Prozessen [VoHe06f, S. 21] mit Kardinalitäten Das Meta-Modell dient als Rahmenwerk und ermöglicht die Erstellung von Prozessmodellen, insbesondere von Modellen zu Innovationsprozessen. Diese Prozessmodelle können in softwaretechnischen Anwendungen bearbeitet und ausgewertet werden. Bei der Entwicklung wird darauf geachtet, dass die Prozessmodelle in eine XML-Darstellung überführt werden können daher nehmen die Kardinalitäten eine entscheidende Rolle ein. Auf dem Prozessmodell sollen Methoden und Dienste operieren. Dazu folgt nun eine Analyse der Anwendungsszenarien vor dem Ziel, geeignete Dienste abzuleiten und diese Dienste zu spezifizieren. 3.3 Anwendungsszenarien zur Spezifikation von Diensten Die Anforderungen an das WPIM werden in [Kap. 2.7] aus den Innovationsszenarien bzw. den Anwendungsszenarien [vgl. Kap. 1.3] abgeleitet. Die Anwendungsszenarien wurden zudem [in Kap. 3.1] herangezogen um die Konzepte und Kernkonzepte für die WPIM-Modellbildung zu extrahieren. Im folgenden Abschnitt werden die Szenarien erneut aufgegriffen und diese weiter in Anwendungsfälle detailliert. Daraus kann dann der Bedarf an Methoden analytisch abgeleitet werden. Die so identifizierten WPIM-Methoden werden weiter definiert und spezifiziert. So können auf technischer Ebene einzelne Dienste (D) abgeleitet werden. Diese werden, im Verlauf der Arbeit, im WPIM-Prototyp implementiert und erprobt und kommen darauffolgend in der WPIM-Anwendung zum Einsatz Szenario 1: Projektübergabe und Nachfolger-Regelung Den [in Abb. 3.17] hinterlegten Experten-Profilen können über eine Web- Benutzungsschnittstelle Profil,- Kontakt- und Projektdaten zugewiesen werden. Auf diesem Weg kann auch ein Profilphoto im Expertenprofil hinterlegt werden. Diese Profile werden in der 95

120 WPIM Modellbildung und Methodenentwurf Expertendatenbank (Experten-DB) gespeichert. Eine weitere Schnittstelle ermöglicht den Experten, über den gespeicherten Profildaten zu suchen (Profil-Suche). Abb. 3.17: Anwendungsfall: Erfassen, Speichern und Durchsuchen von Profildaten Die in UML modellierte Legende [in Abb. 3.17] hat Gültigkeit für alle nachfolgenden in UML modellierten Anwendungsfälle. Dienst 1: Erfassen von Profildaten und Auffinden von Vertretern und Nachfolgern Der Dienst weist folgende Leistungsmerkmale auf: Die Erfassung von Personendaten ist vorgesehen. Über ein Formular werden die Profildaten zu einer Person erfasst. Die personenbezogenen Daten werden einer Aktivität zugeordnet. Zudem werden diese personenbezogenen Daten gespeichert und können z. B. in einer Datenbank abgelegt werden. Die personenbezogenen Daten werden einer semantischen Annotation unterzogen und in einem maschinenlesbaren Format, wie z. B. im HTML-Format, bereitgestellt. Dies erfolgt vor dem Ziel, die annotierten Profile im Intra- oder Internet zu publizieren. Unterstützt werden soll eine semantische Suche, z. B. mittels Inferenz oder semantischen Abfragesprachen, um Vertreter und Nachfolger gezielt zu finden Szenario 2: Radikaler Technologietransfer und Kollaborationen Um den Datentransfer und die Kollaboration über Unternehmensgrenzen hinweg zu ermöglichen, wird in [Abb. 3.18] der Austausch von Prozessdaten aufgezeigt. Experten hinterlegen dazu Prozessdaten und speichern diese Daten in Datenspeichern. Um einen gezielten Austausch der Daten zu ermöglichen, werden im WPIM-System die Prozessdaten in ein geeignetes Datenaustauschformat überführt. Den Experten der beteiligten Unternehmen (Experten aus Unternehmen A und B) werden die Prozessdaten über Schnittstellen bereitgestellt und somit wird die Zusammenarbeit über Unternehmensgrenzen hinweg unterstützt. 96

121 WPIM Modellbildung und Methodenentwurf Abb. 3.18: Anwendungsfall: Kollaboration und Datenaustauschformat Dienst 2: Datenaustausch und Kollaboration Leistungsmerkmale des Dienstes: Ein weitverbreitetes und offenes Datenaustauschformat soll mit dem Ziel unterstützt werden, organisatorische/unternehmensweite Grenzen problemlos zu überwinden. Zur Förderung der Kollaboration wird ein Multi-Anwender-Ansatz angestrebt, z. B. durch eine webbasierte softwaretechnische Lösung. Dabei sollen insbesondere Innovationsprozesse mit Wissen annotiert werden. Die annotierten Inhalte werden den Experten über geeignete Suchen bereitgestellt. Hierbei kommen insbesondere semantische Suchen über den angereicherten Inhalten zum Einsatz Szenario 3: Informationsflut bei Innovationen Um die Innovationskraft von Unternehmen zu fördern, weisen Experten in [Abb. 3.19] Ressourcen, wie Dokumente und Experten, gezielt einzelnen Prozess-Aktivitäten zu. Durch die Selektion von Ressourcen und die expertenbasierte Zuordnung zu Aktivitäten wird die bestehende Informationsflut (von Expertendaten und Dokumenten) positiv begrenzt. Die Aktivitäten, angereichert mit den Ressourcen, werden in die Prozesse integriert und in einem Datenspeicher für Prozesse (Prozess-DB) persistiert. Abb Anwendungsfall: Strukturierung und Zuordnung von Ressourcen 97

122 WPIM Modellbildung und Methodenentwurf Dienst 3: Auffinden von Dokumenten und strukturierte Recherche über die vier Wissensebenen Der Dienst weist folgende Leistungsmerkmale auf: Die Prozess-Aktivitäten dienen zur Strukturierung von Wissen. Der Dienst unterstützt bei der Einordnung von Dokumenten sowie von Expertenwissen in die vier Wissensebenen. Dokumente, Expertenprofile und Links werden den Aktivitäten und (Aktivitäten-) Pools im Prozessmodell zugeordnet. Dazu können Dokumente und Verweise in einem Datenspeicher, wie z. B. einer Prozess-Datenbank (Prozess-DB), als redundantes Dokument oder Verknüpfungspfad abgelegt werden. Durch semantische Annotationen erfolgt eine Anreicherung der Inhalte. Das systematische Suchen entlang der vier Wissensebenen gem. dem Drill-Through-Ansatz wird unterstützt Szenario 4: Dokumentation per Gesetzeszwang Gesetzliche Anforderungen haben Einfluss auf gesamte Unternehmen, deren Produkte und Prozesse. In [Abb. 3.20] werden Prozessdaten durch Experten gespeichert und im Prozess- Baukasten abgelegt. Bereits bei der Standardisierung von Prozessen und Aktivitäten sind Anforderungen der Gesetzgebung zu berücksichtigen. Ein Beispiel für eine Anforderung ist die Dokumentationspflicht z. B. bei der Entwicklung und zur Freigabe von elektronischen Erzeugnissen (nach CE-Konformitätserklärung 81 ), bei sicherheitskritischen Komponenten [vgl. IEC ] oder sicherheitskritischer Software [siehe RTCA 83 DO-178B 84 ]. Abb Anwendungsfall: Prozess-Baukasten und gesetzliche Anforderungen Dienst 4: Rückführung der angereicherten Inhalte in das visuelle Prozessmodell Der Dienst weist folgende Leistungsmerkmale auf: Unterstützt wird die Wiederverwendung von Prozessbausteinen mit dem Ziel, Prozesse zu standardisieren, und eine Bibliothek von Musterprozessen aufzubauen. Die Prozessmodelle werden für zukünftige Innovationen bereitgestellt und werden dazu instanziiert. Hierbei fließen z. B. gesetzliche Änderungen oder Neuerungen ein. Die Prozessmodelle sollen dann einer persistenten Speicherung, z. B. in einer Prozess-DB, unterzogen werden. Der Dienst unterstützt die Rückführung von Wissen in das Mustermodell/Ausgangsmodell des Innovationsprozesses. Eine geeignete Versionskontrolle des Prozessmodells, z. B. automatisiert durch das Hinzufügen eines Erstellungsdatums, ist gefordert

123 WPIM Modellbildung und Methodenentwurf Szenario 5: Die Rolle von Experten bei Innovationen [Abb. 3.21] zeigt, wie Experten über Schnittstellen Ressourcen, wie Dokumente und Experten, annotieren und diese gezielt den Aktivitäten zuordnen. Die Experten nehmen hierbei eine entscheidende Aufgabe ein, da sie es sind, die eine fachlich richtige und innovationsfördernde Zuordnung treffen müssen. Insbesondere die Zuordnung von Expertenprofilen und deren Kontaktdaten zu Aktivitäten ist für die erfolgreiche Durchführung von Innovationsprozessen essenziell. Die Annotationen der Aktivitäten unterstützen weiterhin bei der Erstellung einer vollständigen Dokumentation [vgl.trög12] und somit, Experten zukünftig über Details und Sachverhalte besser zu informieren. Prozesse werden aus Teilprozessen und diese aus Aktivitäten aufgebaut und diese dann wiederum mit Ressourcen annotiert. Durch eine Ablage in der Prozess-DB und im Prozessbaukasten wird die Wiederverwendung der Prozesse und Aktivitäten gefördert. Abb Anwendungsfall: Annotation von Ressourcen und Prozessstruktur Dienst 5: Zuordnung von Profildaten zu Aktivitäten und Prozessen im Innovationsprozess Leistungsmerkmale des Dienstes: Projektmitarbeiter können unterschiedliche Rollen 85 im innovativen Unternehmen einnehmen. Diese Rollen sind [im Abschnitt ] bereits identifiziert und für die Modellierung in der Ontologie definiert. In der Spezifikation können die Rollen weiter untergliedert bzw. erweitert werden, wie z. B. in Funktionen. In der Spezifikation werden die Ausprägungen von Rollen festgelegt. Zudem kann einzelnen Personen ein Aktivitätsindex 86 zugeordnet werden. So werden z. B. die Status 87 Kenner/Könner/Experte als Ausprägungen des Aktivitätsindex spezifiziert. Der Aktivitätsindex wird bei der Implementierung dann als Attribut angelegt, zugeordnet und befüllt. Die Mitarbeiterrollen Ersteller/Bearbeiter/Verantwortlicher werden ebenso bereits im Modell definiert, spezifiziert und im Rahmen des Implementierung in das Schema übernommen. Dieses Wissen über Rollen von 85 Bei WPIM kommen Rollen zum Einsatz, die z. B. folgende Ausprägungen annehmen können: Abteilungsleiter, Projektleiter, Entscheider, Verantwortlicher, Ersteller, Vertreter. In Unternehmen werden hierarchische Rollen von Mitarbeitern häufig als Funktionen (Positionen oder Stellen) bezeichnet und so in den Organigrammen abgebildet. 86 In der Praxis wurde erkannt, dass in Unternehmen (Mitarbeiter-) Rollen unterschiedlich aufgefasst werden und häufig nur temporär zugeordnet werden. Ein Beispiel hierfür ist die Rolle Projektleiter, die nur für die Dauer eines Projekts zugewiesen wird. 87 Status ist das lateinische Wort für Zustand. Der Plural lautet Status nach der lateinischen U-Deklination und nicht Stati - 99

124 WPIM Modellbildung und Methodenentwurf Mitarbeitern wird an den Innovationsprozess geknüpft und im Schema abgelegt 88. Experten können auch als Entscheider gekennzeichnet werden und somit Entscheidungs- und Eskalationswege verkörpern. Nach erfolgreicher Annotation des Prozesses wird eine persistente Speicherung des erweiterten Prozesses angestrebt Zentraler Use Case: semantische Suche Durch Verfeinerung und Zusammenführung der Anwendungsfälle, passend zu den Szenarien, wird der zentrale Use Case zur semantischen Suche entwickelt und in UML modelliert. Die WPIM-Wissensbasis [in Abb. 3.22] ist der Ausgangspunkt für die semantische Suche. Die WPIM-Wissensbasis besteht aus dem erweiterten Prozessmodell (entwickelt aus Datenschemata und Ontologie), das mit Ressourcen annotiert wird. Ein Anwender (engl. user) kann über eine Benutzungsschnittstelle semantische Suchen an die Wissensbasis richten. Bei der semantischen Suche wird zwischen semantischen Anfragen (ähnlich wie SQL) und dem Reasoning (einem automatisierten Schlussfolge- oder Inferenzmechanismus unterschieden) [vgl. Kap. 4.3 Semantische Suche]. Abb. 3.22: WPIM Use Case: semantische Suche Die WPIM-Wissensbasis ist der zentrale Ausgangspunkt für semantische Suchen eben über dieser Wissensbasis. Im Mittelpunkt steht somit die Entwicklung und Repräsentation der WPIM- Wissensbasis. Anhand der zuvor dargestellten Anwendungsfälle konnten die benötigten Dienste abgeleitet werden. Ausgehend von den Diensten wird im Verlauf der Arbeit der Übergang des technischen Systems hin zum sozio-technischen System WPIM deutlich gemacht. Anhand der Anwendungsfälle und dem zentralen Use Case konnten die, zum Aufbau der Wissensbasis, benötigten Benutzungsschnittstellen identifiziert werden. Diese Benutzungsschnittstellen werden nun entworfen und werden im Verlauf der Arbeit implementiert. 88 Dieses Wissen muss für jede Organisation individuell erhoben und modelliert werden. Berücksichtigt werden muss u. a. die Aufbau- und Ablauforganisation des Unternehmens. [Mena12] hat aufbauend auf dieser Arbeit eine Lösung entwickelt, die es ermöglicht, die Ontologie einer Organisation in die WPIM-Anwendung zu laden. 100

125 WPIM Modellbildung und Methodenentwurf 3.4 Vorgehensmodell und Entwurf der Benutzungsschnittstellen Das WPIM-Vorgehensmodell existiert an dieser Stelle bisher nur als gedankliches Konstrukt im Kopf des Autors. Dieses Vorgehensmodell muss also zunächst definiert und entwickelt werden, bevor die abgeleiteten WPIM-Methoden eingesetzt und validiert werden können. Das Vorgehensmodell beschreibt somit zunächst kein bestehendes reales Vorgehen 89 aus der betrieblichen Praxis, sondern eine planerisch-kreative Vorgehensweise, deren Anwendbarkeit noch unter Beweis gestellt werden muss. Dennoch erfolgt die grobe Gliederung der Phasen im WPIM-Vorgehensmodell am Innovation Process Model (IPM) von [Pauk03, PaNH04, PaNH04a], das bereits in den Domänen Innovation und Wissensmanagement unter Beweis gestellt wurde. Anhand des WPIM-Vorgehensmodells wird analysiert, wie Experten die WPIM- Methoden anwenden. Daraus kann abgeleitet werden, wie das WPIM-System mit den zugehörigen Komponenten und den Benutzungsschnittstellen (engl. user interface, UI) auszusehen hat (benutzungszentrierter Ansatz 90 ), um darauffolgend mit dem Entwurf der Benutzungsschnittstellen beginnen zu können. Neben den bestehenden Anforderungen aus den Szenarien [vgl. Kap. 1.3 bis 1.4] und der WPIM-Modellbildung [vgl. Kap bis 3.1.6] ergeben sich beim Entwurf der Benutzungsschnittstelle neue technische Anforderungen an das WPIM-System Vorgehensmodell Vorgehensmodelle beschreiben die notwendigen Aktivitäten zur Umsetzung bestimmter Vorhaben [LBMW08]. Diese Aktivitäten werden analog eines Prozessmodells gemäß ihrer zeitlichen Abfolge geordnet und ausgeführt, z. B. in Phasen. Vorgehensmodelle sind somit ein systematischer und formaler Ansatz, durch deren Einsatz Produktivität und Qualität erhöht sowie Komplexität verringert wird. [LBMW08] Das WPIM-Vorgehensmodell wird im weiteren Verlauf der Arbeit entwickelt, entsteht jedoch in Anlehnung an [Pauk03, PaNH04, PaNH04a] und orientiert sich am Stand der Wissenschaft und Technik zum Wissensmanagement [vgl. Kap. 2.1]. Das Modell Innovation Process Model (IPM) von [Pauk03, PaNH04, PaNH04a] mit den Phasen Problem Identification, Ideation, Approach Development, Operationalisation, Evaluation und Exploitation berücksichtigt eine grundlegende sequenzielle Reihenfolge. Für WPIM wird in [Kap. 3.2] ein eigenes Vorgehensmodell entwickelt somit ist eine deutliche Abgrenzung zum Vorgehensmodell von Paukert gegeben. Das WPIM-Vorgehensmodell wird zum konkreten Entwurf der Benutzungsschnittstellen, dem Entwurf der WPIM-Pipeline sowie zur Implementierung der WPIM-Anwendung genutzt. Dazu werden die WPIM-Methoden aus dem Vorgehensmodell abgeleitet, die in implementierbare WPIM-Dienste überführt werden Entwicklung des WPIM-Vorgehensmodells Das WPIM-Vorgehensmodell wird von Grund auf und aus Anwendersicht entworfen. Die Gliederung in Phasen und auch die Grobphasen sind jedoch am bestehenden und erprobten Innovation Process Model (IPM) orientiert. Überlappungen und Iterationen zwischen den Phasen sowie Rückschritte zu früheren Phasen sind bei IPM [vgl. PaNH04a] wie auch beim WPIM- Vorgehensmodell möglich. Nach [PaNH04a] ist das IPM als Ergebnis der Studie von Theorien aus den Domänen Innovation und Wissensmanagement und durch einen Evaluationsprozess validiert [Pauk03]. Die Vorgehensweise bei der Studie sowie die zugehörigen Ergebnisse der Evaluation liefern [Paukert et al. 91 ]. Die eingeführten Konzepte zum WPIM-Modell [vgl. Kap ] und der WPIM-Methoden [vgl. Kap ] ermöglichen eine durchgängige Anwendung 89 Das WPIM-Vorgehensmodell basiert nicht auf Beobachtungen, sondern zielt auf eine Verbesserung zukünftiger Innovationsprozesse ab. 90 Die Benutzung mit den Bedürfnissen der benutzenden Akteure, z. B. (menschliche) Benutzer oder auch SW- Agenten, steht im Mittelpunkt des Entwurfs und der Implementierung des Systems. 91 Paukert et al

126 WPIM Modellbildung und Methodenentwurf des WPIM-Vorgehensmodells bis hin zum Entwurf der WPIM-Pipeline. Das Vorgehensmodell kann für unterschiedliche Phasen im Innovationsprozess eingesetzt werden sowie auch für spezielle Phasen iterativ wiederholt werden. Im weiteren Verlauf sind die sieben Phasen des WPIM-Vorgehensmodells dargestellt und geben einen systematischen Überblick zur Vorgehensweise bei der Annotation von Innovationsprozessen mit Ressourcen: 1. Analyse und Identifikation des Wissensbedarfs 2. Prozessorientierte Wissensakquise 3. Erweiterte Wissens- und Expertensuche 4. Selektion der Ergebnisse 5. Generierung neuer Erkenntnisse durch Wissenskombination und Lessons Learned 6. Prozessorientierte Wissensablage 7. Erweiterung und semantische Annotation der Wissensbasis Das WPIM-Vorgehensmodell unterstützt die Anwender folglich bei der synergetischen Zusammenführung [Phase 1 und 2] von Wissen und Innovationsprozessen. Es erleichtert Experten das Suchen und Auffinden von Wissen [Phase 3] sowie die Interaktion [z. B. Phase 4 Selektion] und Kollaboration von Mensch und Maschine [Phase 5]. Innovationsprozesse werden dazu in Aktivitäten und Relationen zerlegt und so benutzerfreundlich visualisiert [Phase 6]. Das Ziel des Vorgehensmodells besteht darin, die Anwender insofern zu unterstützen, Wissen kontextbezogen 92, aktuell, reduzier- oder erweiterbar (semantisch annotiert) fortzuschreiben [Phase 6 und 7] Definitionen zu den Phasen im Vorgehensmodell Bei den Definitionen zu den sieben Phasen im Vorgehensmodell handelt es sich nicht um beobachtbare Handlungen. Ein derartiges Vorgehensmodell konnte weder dem Stand der Wissenschaft und Technik entnommen werden [vgl. Kap. 2] noch ist ein solcher Ansatz aus der Praxis bekannt. Die Definitionen sind somit vielmehr originäres Ergebnis der vorliegenden Arbeit und helfen beim Entwurf der Schnittstellen und deren Komponenten. Vorgestellt werden dazu zunächst die Definitionen zu den Phasen im Vorgehensmodell: Definition 3.47: Analyse und Identifikation des Wissensbedarfs Festgestellte Wissensbedarfe bei der Durchführung einer Aktivität im Innovationsprozess, werden durch Experten manuell mit verfügbaren (Wissens-) Ressourcen abgeglichen. Fehlende Ressourcen werden dazu identifiziert (wissensbasiert). Diese Phase beschreibt aus Anwendersicht den Wissensbedarf. WPIM ist wissensbasiert da die Wissensressourcen und die Wissensbasis den Kern der entstehenden Anwendung bilden. Definition 3.48: Prozessorientierte Wissensakquise Die Akquise von Ressourcen durch Experten erfolgt innerhalb der aktuell durchzuführenden Aktivität im Innovationsprozess. Ein Experte hat im Innovationsprozess eine konkrete Aktivität durchzuführen. Hierzu sucht der Experte entlang des Prozesses orientiert (der Prozessorientierung folgend) die relevante Aktivität im Prozess. Dort angelangt durchsucht er die Aktivitäten nach vorhandenen bzw. benötigten Ressourcen. 92 Der Kontext dieser Arbeit sind Prozesse, insofern trifft prozessbezogen noch konkreter zu. 102

127 WPIM Modellbildung und Methodenentwurf Definition 3.49: Erweiterte Wissens- und Expertensuche Benötigte Ressourcen wie Experten oder Dokumente sind durch zusätzliche oder erweiterte Suchen zu identifizieren. Der Anwender benötigt geeignete Suchmethoden und semantische Suchen [vgl. 4.3], um die benötigten Ergebnisse aus der Datenbasis extrahieren zu können. Definition 3.50: Selektion der Ergebnisse Identifizierte Ressourcen mit potenziellem Nutzen für den Innovationsprozess müssen durch die Experten ausgewählt werden. Definition 3.51: Neue Erkenntnisse durch Wissenskombination oder Lessons Learned Experten generieren neues Wissen durch Kombination bestehender Wissensressourcen und aus explizit dokumentiertem Wissen. Experten können neues Wissen durch Kombination bestehender Ressourcen hervorbringen insbesondere Lessons Learned, also Dokumente, die gezogene Lehren beinhalten. Lessons Learned sollen direkt in zukünftige Innovationen und Entwicklungen einfliessen. Definition 3.52: Prozessorientierte Wissensablage Die Ablage von Wissensressourcen, neu abgeleitetem Wissen sowie explizit dokumentiertem Wissen erfolgt innerhalb der Aktivität im Innovationsprozess. Gefordert wird an dieser Stelle die Prozessorientierung, somit hat die Ablage von Ressourcen gezielt im Prozess, bzw. noch exakter in der jeweiligen Aktivität zu erfolgen. Definition 3.53: Erweiterung und semantische Annotation der Wissensbasis Wissensressourcen sind semantisch zu beschreiben. Durch die semantische Beschreibung können Ressourcen eindeutig identifiziert und aufgefunden werden. Neu generierte Wissensressourcen werden gezielt um (semantische) Annotationen erweitert. Zur semantischen Annotation werden sog. semantische Vokabulare, wie z. B. DC, FOAF oder das WPIM-Vokabular [vgl. Kap ] eingesetzt. Aufbauend auf diesem kreativen Entwurfsakt zur WPIM-Vorgehensweise wird im Folgenden die Anwendung der Vorgehensweise und somit die sog. WPIM-Pipeline entwickelt. Begonnen wird mit den Entwurfsaktivitäten zu den Benutzungsschnittstellen gefolgt von der WPIM-Pipeline und deren Implementierung Entwurf der Benutzungsschnittstellen auf den WPIM-Methoden Ausgehend von konzeptuellen Benutzungsschnittstellen wird durch gezielte Analyse ermittelt, welche Komponenten und Schnittstellen im WPIM-System benötigt werden. Dazu werden aus den Methoden Anforderungen an WPIM-Dienste und WPIM-Werkzeuge abgeleitet und diese weitestmöglich konkretisiert. Durch Beispiele werden die Benutzungsschnittstellen weiter 103

128 WPIM Modellbildung und Methodenentwurf beschrieben und somit auf eine konkrete Implementierung im WPIM-System vorbereitet. Zur Integration von Wissen und Innovationsprozessen wird eine methodische Strukturierung des Wissens entlang den sog. vier Wissensebenen [VoHe06] vorgeschlagen. Dabei können Experten relevantes Wissen in der entstehenden Wissenshierarchie in einzelnen Aktivitäten ablegen. Die vier Wissensebenen dienen dazu, das Wissen nach Art, Umfang, Aktualität und (subjektiver) Relevanz (festgelegt, z. B. durch die Benutzer) an den Innovationsprozess zu koppeln. In Konsequenz können die vier Wissensebenen als hierarchische Ablagestruktur (also Grundlage für ein Datenschema) für Wissen und Ressourcen interpretiert werden. Dem Wissenssuchenden bzw. dem Aufgabenträger wird durch das sog. Drill-Through-Verfahren [VoHe06] die Möglichkeit eröffnet, systematisch von höheren abstrakteren Wissensebenen hin zu tieferen, detaillierten Wissensebenen vorzudringen. Dieser Drill-Through erfolgt nach dem Top-Down Prinzip. Wie in der Modellierung beschrieben, sind dazu die methodischen Grundlagen beim Entwurf der WPIM-Pipeline nötig. Dazu zählen die vier Wissensebenen, das Drill-Through- Verfahren, die semantische Beschreibung der Wissensinhalte sowie ein integriertes Expertennetzwerk Wissensstruktur mit vier Wissensebenen Nach der allgemeinen Einführung zu Innovationsprozessen und Prozessbausteinen 93 (Aktivitäten, Pools, Ressourcen usw.) wird zu den Ablagestrukturen der vier Wissensebenen eine beispielhafte konzeptuelle Benutzungsschnittstelle entworfen. Innovationsprozesse werden in Aktivitäten und Relationen 94 zerlegt und so visualisiert. Diese Prozesse mit ihren Aktivitäten sollen, wie bereits bei der WPIM-Modellbildung [in Kap ] erörtert, mit Ressourcen angereichert werden. Zudem sollen Prozesse in ihrer Struktur, also um weitere Aktivitäten [vgl. mit der Modellierung in Kap ] erweiter- bzw. reduzierbar sein. Zudem sollen diese Prozesse um Wissen und Erkenntnisse Ergänzung finden [vgl. Kap ]. Übergang von den Anforderungen an Methoden hin zu Diensten im WPIM-System: Ausgehend von diesen konkreten Anforderungen an die WPIM-Methoden leiten wir über zu konkreten Diensten. Diese Dienste werden im digitalen WPIM-System implementiert, welches wiederum nach den Vorgaben entwickelt wird, die aus den Anforderungen an das WPIM-Modell resultieren. Die Anforderungen an die Methoden lauten: Es muss die Möglichkeit bestehen, veraltetes Wissen von den Aktivitäten zu lösen, zu entfernen oder durch neue Lessons Learned zu ersetzen. Im digitalen System sind hierfür entsprechende Dienste vorzuhalten, die eine Löschung veralteten Wissens ermöglichen oder auch die Neuanlage neuer Erkenntnisstände unterstützen. Hieran wird die Brückenbildung von dieser WPIM-Methode hin zum implementierten WPIM-Dienst im digitalen WPIM-System ersichtlich. Die grafische Modellierung der Prozessbausteine ist in [Abb. 3.23] konzeptuell dargestellt: 93 Aus Prozessen und Bausteinen im Modell entstehen bei der Implementierung digitale Objekte, die einem Schema folgen und in Datenbanken abgelegt werden können. Hierin ist der Übergang von der Modell-Spezifikation hin zur Implementierung zu erkennen. Prozessbausteine sind Konzepte, bzw. digitale Objekte, die bei der Implementierung zu Prozessen zusammengefügt werden. 94 Ausprägungen von Relationen sind mathematisch im Anhang dieser Arbeit definiert. 104

129 WPIM Modellbildung und Methodenentwurf Abb. 3.23: Konzeptuelle Benutzungsebenen im WPIM-Prototyp [VoHe06c, S. 21] Das exemplarische Prozessmodell [mittig, in Abb. 3.23] wurde mit Microsoft Visio 95 [vgl. Kap 2.5.1] erstellt. Die weiteren Benutzungsebenen wurden grafisch hinzugefügt es sind noch keine Funktionalitäten hinterlegt. Die in [Abb. 3.23] dargestellten konzeptuellen Benutzungsebenen stellen den Ausgangspunkt für den Entwurf der Komponenten und Benutzungsschnittstellen des WPIM-Systems dar. Ausgehend von diesen konzeptuellen Benutzungsschnittstellen werden mittels der Anforderungsanalyse die Anforderungen an die Benutzungsschnittstelle, die Methoden, Dienste und Werkzeuge ermittelt und grob spezifiziert. Ziel ist es dabei, die Anforderungen zu konkretisieren, mit Beispielen zu unterlegen und somit auf eine prototypische Implementierung vorzubereiten. Die vier Wissensebenen sind strukturierende Wissensebenen und können im WPIM-Prototyp, z. B. in fünf Benutzungsebenen, gegliedert und als solche visualisiert werden [vgl. Abb. 3.23]: 1. Oberfläche zur Modellierung und Visualisierung von Prozessen und Prozessbausteinen Bei der Aktivierung eines Prozessbausteins soll in einem Fenster Wissen zu diesem Prozessbaustein (editierbar) angezeigt werden. Beispielsweise sollen die Bezeichnung einer Aktivität, der Verantwortliche und die Experten sowie eine kurze Beschreibung sichtbar sein. 3. Über den Button Details [vgl. Abb. 3.23] soll eine Liste mit Dokumenten einsehbar sein, die in direkter Verbindung mit dem Prozessbaustein stehen (Verfahrensanweisungen, Handbücher usw.). 4. Nach der Auswahl von potenziellen Ressourcen, insbesondere Dokumenten sollen diese bzw. Links zu diesen Dokumenten (z. B. auch zu externen Patenten) mit gängigen Anwendungen und Werkzeugen einsehbar sein. 5. Die Experten zu diesem Prozessbaustein sollen direkt kontaktierbar sein, z. B. per Mail oder Telefon. Weiterführend soll durch die Auswahl eines Experten automatisch das im Expert-to-Expert Netzwerk (E2E) hinterlegte Expertenprofil dargestellt werden. 95 Visio ist eine Visualisierungs-Software von Microsoft für Windows Wir verwenden hier bewusst den Überbegriff Prozessbaustein, der z. B. Aktivitäten, Aufgaben, oder Pools umfassen kann. 105

130 WPIM Modellbildung und Methodenentwurf Wird es nötig, eine neue Aktivität in den Entwicklungsprozess aufzunehmen, z. B. eine Absicherungsmaßnahme, so wird das Prozessmodell um eine Aktivität erweitert. Zugleich wird zu dieser Aktivität eine entsprechende Datenstruktur angelegt. Diese Struktur wird zur Dokumentation und Wissensablage innerhalb der Aktivität genutzt. Das Prozessmodell und die Prozessdokumentation werden synchron angepasst und mit Wissen befüllt. Das Strukturwissen des Prozesses ist im Prozessmodell gebunden, das Verhalten des Prozesses wird durch die Beschreibung und die angehängten Dokumente erläutert. Die Synergie besteht in der quasi parallelen Entwicklung von Innovationsprozess, Wissensbasis und natürlich des innovativen Produktes. Hinsichtlich der Formalisierung sind Strukturen zu definieren, die es ermöglichen, Dokumente, wie z. B. Patente und deren Autoren, direkt an den Innovationsprozess zu knüpfen Musterprozess und Prozessinstanzen Bei radikalen Innovationen können aus Prozesssicht bei Entwicklungsstart nur sehr allgemeine Prozessmodelle mit grundsätzlichen Phasen, wie z. B. Ideenfindung und Bewertung, Produktkonzept oder Testphase, herangezogen werden. Erfahrungswerte und ähnliche Innovationen zur Orientierung fehlen oft gänzlich bei radikalen Entwicklungen. Inkrementelle Entwicklungen hingegen zeichnen sich dadurch aus, dass die Innovation in kleinen Schritten systematisch vorgenommen und abgesichert wird. Bereits bei der Modellbildung, bei der Analyse der Szenarien [vgl. Kap insbesondere Kap ] sind wir auf Musterprozesse und Prozessinstanzen eingegangen. Entsprechend wird auf die Standardisierung von Prozessen, Musterprozesse und die Entwicklung einer Prozessbibliothek in [Kap Szenario 4: Dokumentation per Gesetzeszwang] verwiesen. Übergang von den Anforderungen an Methoden hin zu Diensten im digitalen System: Ein korrespondierender Entwurf zu einer Benutzungsschnittstelle (engl. user interface, UI) für die Verwaltung von Musterprozessen und Prozessinstanzen existiert an dieser Stelle noch nicht. In [Abb. 3.24] wird das methodische Zusammenspiel von Musterprozessen und deren Instanziierung zu Prozessinstanzen vorgestellt. Daraus können konkrete technische Anforderungen zur Realisierung der WPIM-Dienste und WPIM-Werkzeuge abgeleitet werden. Im Rahmen dieser Analyse wurde erkannt, dass hierbei weniger die Benutzungsschnittstelle, sondern vielmehr bereits die technisch konkrete Methode und dann auch der WPIM-Dienst ausschlaggebend sind. Die Methode wird im weiteren Verlauf der Arbeit vorgestellt, modelliert und abschließend im System operationalisiert. Grafischer Entwurf zum Zusammenspiel von Musterprozess und Prozessinstanz: Aus Sicht des Innovationsprozesses sprechen wir von einem Musterprozess [VoHe06b], der mit jedem Entwicklungszyklus adaptiert wird. 106

131 WPIM Modellbildung und Methodenentwurf Abb. 3.24: Musterprozess und Prozessinstanzen [VoHe06f] So entstehen in [Abb. 3.24] sogenannten Prozessinstanzen [VoHe06b]. Diese Prozessinstanzen werden bei inkrementellen Entwicklungen parallel zum Produkt (mit-) entwickelt, fortgeschrieben und Verbesserungen dokumentiert. Prozessinstanzen zeichnen sich dadurch aus, dass sie auf einer vorgelagerten Prozessinstanz bzw. ursprünglich auf dem Musterprozess aufsetzen. Ein entsprechender Dienst wird in [Kap. 4] im Rahmen der Operationalisierung des digitalen WPIM-Systems implementiert. Formal beschrieben, können zu einem Musterprozess (M) beliebig viele Prozessinstanzen (I) entstehen, wobei eine Prozessinstanz genau einem Musterprozess zugeordnet wird, bzw. genauer von diesem abstammt. Wir bezeichnen eine Instanz I zum Musterprozess M mit I M. Als Besonderheit ist zu beachten, dass die Instanzen sich inhaltlich unterscheiden können, sofern der Musterprozess einer (strukturellen und/oder inhaltlichen) Weiterentwicklung unterzogen wird. Die Instanzen mit I:= {i 1, i 2, i 3,, i n } sind somit chronologisch geordnet, wobei i 1 vor i 2 usw. erzeugt wird. Für die Instanzen von I M gilt somit I M := {i M1, i M2, i M3,, i Mn } ebenfalls mit der beschriebenen Ordnungsrelation i M1 vor i M2. Eine aktuelle Prozessinstanz bildet in diesem Beispiel die Basis für eine zeitlich nachgelagerte Prozessinstanz. Die aktuellste Prozessinstanz dient somit als Referenz und kann durch Adaption kontinuierlich verbessert werden. Jede Instanz wird versioniert und so kann bei Fehlentwicklungen auf vorgelagerte Prozessinstanzen zurückgegriffen werden. Je kürzer dabei die Entwicklungszyklen angelegt sind, desto geringer fallen Zeitbedarf und Kosten bei Fehlentwicklungen und für die nötigen Rückschritte aus Nutzung gemeinsamer Prozessbausteine und Prozessbibliotheken Bereits in [Kap und Kap ] insbesondere in [Abb und Abb. 3.21] wurde bei der Analyse der Szenarien auf die Entwicklung einer Prozessbibliothek eingegangen, sowie davor bei der WPIM-Modellbildung [vgl. Kap ]. Für den Entwurf der Prozessbibliothek greifen wir darauf zurück und unterziehen die methodische Vorgehensweise einer weiterführenden 107

132 WPIM Modellbildung und Methodenentwurf Analyse mit dem Ziel, technische Anforderungen an Dienste und Werkzeuge für deren Operationalisierung zu erhalten und eine Operationalisierung vorzubereiten. Detaillierter betrachtet, werden in der Entwicklung von Steuergeräten für Fahrzeuge häufig unterschiedliche aber ähnliche Varianten entwickelt, z. B. in Abhängigkeit der Produktlinie oder der Baureihe. Auch innerhalb eines Fahrzeugs werden mehrere Steuergeräte verbaut, die oftmals gleichen Testbedingungen unterliegen oder über identische Diagnosefunktionen für den Service verfügen müssen. Bei den Automobilherstellern gibt es für jedes Steuergerät (SG) ein Lastenheft und zudem Lastenhefte die für Produktlinien oder das ganze Unternehmen (z. B. der sog. BMW Group Standard) gültig sind. Bei der Absicherung von Steuergeräten sind identische Tests und Testprozesse zu absolvieren, wie z. B. Kälte- und Klimatests oder Tests zum Einschlaf- und Aufstartverhalten von Steuergeräten. Ebenso wie bei den methodischen Überlegungen zu Musterprozessen und Prozessinstanzen [vgl ] sehen wir hier die technischen Anforderungen im konkreten Entwurf der Methode und nicht in der zugehörigen Benutzungsschnittstelle. Grafische Modellierung zum methodischen Zusammenspiel von Prozessen mit gemeinsamen Aktivitäten: Betrachtet man nun separate Entwicklungsprozesse für zwei Steuergeräte, so fällt auf, dass in [Abb. 3.25] beide Prozesse (Prozess A und Prozess B) über eine Aktivität Test verfügen und dass innerhalb dieses Prozessbausteins identische Aktivitäten durchzuführen sind. Abb. 3.25: Bausteinbibliothek [VoHe06c] Übergang von den Anforderungen an Methoden hin zu Diensten im digitalen System: Die Überlegung und Anforderung besteht darin, Lessons Learned und Erfahrungen beim Testen von Steuergeräten als einen zentralen redundanzfreien (Muster-) Prozessbaustein zu modellieren [vgl. Kap ], der allen Entwicklungsprozessen für Steuergeräte zur Verfügung gestellt wird. Der zentrale Prozessbaustein ist wesentlich leichter auf dem aktuellen Stand im Sinne einer Versionskontrolle zu halten und mit spezifischem Wissen der parallelen SG-Entwicklungen anzureichern als redundante, verteilte Versionen. Ziel ist es, für einzelne Prozessbausteine eine Bausteinbibliothek [vgl. Abb. 3.25] zu erstellen. Die Anforderung an diese WPIM-Methode kann im Verlauf der Arbeit in [Kap ] als WPIM-Dienst implementiert werden. Doppelarbeit wird durch nicht vorhandene Redundanzen stark eingeschränkt. Entsteht neues Wissen oder Lessons Learned, können diese synergetisch damit innovationsübergreifend in die Innovationsprozesse einfließen. Im Sinne einer Formalisierung ist für einzelne Bausteine eine innere Struktur zu definieren. Bei der Entwicklung einer Bausteinbibliothek (Bib) ist bei der Instanziierung der Prozessbausteine ebenfalls streng auf die chronologische Reihenfolge zu achten. Die Formalisierung der 108

133 WPIM Modellbildung und Methodenentwurf Bibliothek mit exemplarischen Bausteinen X n erfolgt durch Bib:={X 00, X 01, X 02, X 03, X Test, }. Bei der Instanziierung der Bausteine im Prozess A entstehen die Instanzen: Bib A :={a 00, a 01, a 02, a 03, a Test } oder für den Prozess B die Bib B :={b 00, b 01, b 02, b 03, b Test }. Zudem muss überlegt werden, wie zwischen Vorgänger- und Nachfolger-Bausteinen eine Sequenz definiert und softwaretechnisch realisiert werden kann. Dies kann nur über die Bibliothek selbst erfolgen. In diesem Beispiel wird zunächst Prozess B mit der Instanz Test b Test vor Prozess A mit a Test vor Prozess M mit m Test erstellt, so muss in der Bibliothek für den Baustein Test festgehalten werden Bib Test :={Test b1, Test a2, Test m3,, Test ni } mit n für die Instanz des Prozesses N und i für die fortlaufend nummerierte i-te Instanziierung des Bausteins Test. Somit liegt der Baustein Test in der soweit zuletzt verwendeten Version ni also Test ni vor. Das sind konkrete technische Anforderungen an die zu implementierenden Dienste und Werkzeuge Entwurf des Expertennetzwerks E2E Heindl und Pauschert geben einen guten Überblick über die Begrifflichkeiten Spezialist, Experte und Wissensexperte [HePa98]. Wir gehen davon aus, dass in der Automobilbranche ein am Innovationsprozess beteiligter Mitarbeiter über Wissen, Erfahrung und Kompetenz verfügt und somit Experte auf diesem Arbeitsgebiet ist. Ziel des E2E ist es, genau diese Experten zu vernetzen. Der berufliche Alltag zeigt, die Großzahl der Experten sind hochqualifizierte Personen mit dem Wunsch nach Anerkennung und Reputation [vgl. Merg99]. Ziel des E2E ist es, diese intrinsische Motivation der Experten so für das Unternehmen und den Wissensaustausch zu nutzen, dass sowohl für die Experten, als auch den Wissenstransfer ein synergetisches Plus verzeichnet werden kann. Genau diese Überlegung greift das System WPIM auf und zeigt, wie ein geeignetes Expertennetzwerk mit Anreizsystem diesen synergetischen Effekt erzeugt. Das Expert-to-Expert (E2E) Expertennetzwerk wird vorgestellt. Das sog. Expert-to-Expert Netzwerk ermöglicht es, dass sich Experten in Innovationsprozessen miteinander virtuell vernetzen und kollaborativ austauschen können. [VoHe06] Im E2E- Netzwerk werden Expertenprofile und Kontaktinformation der Experten hinterlegt. Diese Expertenprofile enthalten u. a. aktuelle Arbeits- und Aufgabengebiete, erlangte Fachkenntnisse, Spezial- und Wissensgebiete der Experten (speziell z. B. zu Aktivitäten oder Prozessen). Tätigen Experten Einträge oder fügen sie Dokumente im WPIM zu einem Innovationsprozess hinzu, so können zukünftig diese Beiträge datiert werden und verweisen zudem direkt auf das Expertenprofil und somit den menschlichen Experten. Die Semantik zum Konzept Experte wird bereits teilweise bei der WPIM-Modellbildung und dort durch die Modellierung der Ressource Experte repräsentiert. Bei der Modellbildung wird in [Kap ] zudem auf die Ressourcen, insbesondere Experten mit deren konkreten Eigenschaften, eingegangen. Auch werden die Typisierung und die Rollen von Experten vorgestellt. Weiterhin werden Relationen erläutert, die Experten mit weiteren Ressourcen und Prozessen verbinden. Durch diese tiefergehende Analyse werden die Anforderungen an eine technische Implementierung zu Experten und der zugehörigen Semantik weiter konkretisiert. Die Semantik stellt einerseits ein Bindeglied zwischen realer Welt und konzeptueller Modellierung 109

134 WPIM Modellbildung und Methodenentwurf dar. Andererseits erweitert die Semantik 97 die modellierten Konzepte um die Dimension der Bedeutung und stellt Eindeutigkeit sicher. Dies ist der entscheidende Zwischenschritt von der Modellbildung hin zur Operationalisierung. Auf diese Weise können die WPIM-Methoden als Dienste und die Konzepte als digitale Objekte implementiert werden. Das Expert-to-Expert Netzwerk wird vor dem Ziel modelliert, dass sich Mitarbeiter miteinander vernetzen und austauschen. Anhand des Mitarbeiterprofils können durch Kollegen das aktuelle Arbeitsgebiet, Rollen, Verantwortung, Expertise und Kompetenzen eingesehen werden. Ziel ist, dass sich Mitarbeiter untereinander kollaborativ vernetzen [Kap. 4.10] und austauschen. Dazu werden von jedem Mitarbeiter die Kontaktdaten, wie z. B. Telefon, , usw. bereitgestellt. Abb. 3.26: E2E Eingabemaske und Experteninstanz Entsprechende Eingabemasken [vgl. Abb. 3.26] werden in Rahmen einer webbasierten Anwendung, dem sog. Expert-to-Expert (E2E) Expertennetzwerk erstellt. Den deutschen 98 und europäischen 99 Datenschutzbestimmungen gerade bei persönlichen Daten ist hierbei unbedingt Folge zu leisten. Die Erweiterung des Modells besteht darin, dass Mitarbeiter innerhalb des Netzwerks verschiedene Expertise-Stufen durchlaufen können und ihr Status veränderlich ist. Dies entsteht in Anlehnung an das Expertisemodell Kenner-Könner-Experte nach [NoRe05, S. 52]. Als höchster Status kann nach Kennerstatus, und Könnerstatus der Expertenstatus erreicht werden. Entsprechende Definitionen werden in [NoRe05, S. 53 ff.] gegeben. 97 Semantik und formale Methoden vermeiden Unvollständigkeit und Mehrdeutigkeiten durch eindeutige Zuordnung von Begriff (auch Konzept) und Bedeutung. 98 Virtuelles Datenschutzbüro

135 WPIM Modellbildung und Methodenentwurf Übergang von den Anforderungen an Methoden hin zu Diensten im digitalen System: Auch können einem Status unterschiedliche Regeln und Rechte zugeordnet werden, z. B. dass man nur Personen mit gleichem oder niedrigerem Status in sein persönliches Netzwerk mye2e einladen kann. Personen bzw. Experten auf höheren Ebenen können nicht in das eigene Netzwerk eingeladen werden. Allerdings können alle Mitarbeiter die Profile einsehen und auch die Kontaktdaten zu den Experten nutzen. Es soll definitiv keine Wissensrückhaltung betrieben oder eine Kommunikation unterbunden werden. Es soll lediglich ein Anreiz gesetzt werden, sich selbst als Experte in diesem Netzwerk verewigen zu können. So können sich motivierte Experten, für alle Teilnehmer sichtbar, im positiven Sinne als Experten positionieren und profilieren [Merg99]. Es erscheint sinnvoll, dass Foren und Gruppen nur von Experten geleitet werden können, somit wird parallel zum Netzwerk auch eine Qualitätssicherung der ausgetauschten Inhalte und des Wissens sichergestellt. Durch die Administration eines Forums durch einen Experten, kann dieser z. B. entscheiden, welche Mails an die gesamte Gruppe weitergeleitet werden. Existente Groupware-Lösungen wie Wikis, Groupwise 100, OpenGroupware 101 oder Mailingwerkzeuge wie MailMan 102 unterstützen bei derartigen Aktivitäten. Nach der Formalisierung werden diesem Status eindeutige Werte oder Gewichtungen zugeordnet [vgl. Mena12], um bei späterer Inferenz oder semantischen Suchen eindeutige Ergebnisse erzielen zu können. Somit schlagen wir vor, den Mitarbeiter M mit den Instanzen M:={m 1, m 2, m 3,, m n }, wobei n den Namen oder auch die Personalnummer eines Mitarbeiters im Unternehmen wiedergeben kann, einen Status zuzuweisen. Den Mitarbeitern können die drei kodifizierten Zustände: Kenner=1, Könner=2, Experte=3 zugeordnet werden. In diesem Beispiel wird Mitarbeiter Müller mit Könnerstatus formal dargestellt als m Müller2. oder Experte Meier als m Meier3. Weiterführend ist auch eine Klassifikation der Mitarbeiter in drei Klassen Kenner, Könner und Experten denkbar. Diese Klassen- und Attribut-Struktur ist besser geeignet, um in einer Ontologie implementiert zu werden. 3.5 Erster kognitiver Walk-Through durch die WPIM-Pipeline Der im Folgenden beschriebene kognitive Walk-Through 103 zeigt das Zusammenspiel des technischen Systems WPIM der sog. WPIM-Pipeline mit den Benutzern auf und evaluiert das entstehende System in einer frühen Phase der Entwicklung auf granularen Ebenen. Das Vorgehen beim Walk-Through ist grundlegend am IPM [vgl. PaNH04a] orientiert und im Detail am WPIM-Vorgehensmodell [vgl. Kap ] ausgerichtet. Der Walk-Through ist deshalb ein kognitiver Walk-Through, da die WPIM-Pipeline bisher nur als gedankliches Konstrukt existiert. Konkret verfügbar sind jedoch die konzeptuellen Benutzungsschnittstellen, die es ermöglichen, in einem benutzungs-zentrierten Ansatz gedanklich Ressourcen und Prozesse zu beschreiben und diese gedanklich weiterführend zu verknüpfen. Dabei wird stets das konkrete WPIM-Modell berücksichtigt und auf Anwendbarkeit überprüft. Im Folgenden wird die WPIM-Pipeline konzeptuell beschrieben und einzelne WPIM-Module 104 der Pipeline werden vorgetragen. Ein Modul geht dabei über einen einzelnen Dienst oder auch ein Werkzeug hinaus. Bei Modulen Mailman ist eine Software zur Verwaltung von -Diskussionen und Mailinglisten; Die aktuelle stabile GNU Mailman Version ist 2.1.9, Veröffentlicht am The cognitive walkthrough method is a usability inspection method used to identify usability issues in a piece of software or web site, focusing on how easy it is for new users to accomplish tasks with the system. Whereas cognitive walkthrough is task-specific, heuristic evaluation takes a holistic view to catch problems not caught by this and other usability inspection methods [vgl Module sind die Bestandteile des Architekturmodells entwickelt auf der Grundlage des Systemmodells. 111

136 WPIM Modellbildung und Methodenentwurf werden sowohl Struktur (WPIM-Modell und Architektur) als auch das Verhalten (Dienste und Werkzeuge) als Einheit betrachtet. Ein Modul hat allerdings einen spezifischen Fokus 105 und betrachtet sozusagen gekapselt (eben modular) einzelne Aspekte der Pipeline. Einen besonderen Aspekt bei WPIM stellt der semantik-zentrierte Entwurf, der sich entlang der gesamten WPIM- Pipeline erstreckt, dar. Denn bei der späteren Überführung der Konzepte in digitale Objekte werden nicht nur Objekte implementiert, sondern diese folgen Semantiken, welche bereits im WPIM-Modell [siehe Kap ] und im WPIM-Vokabular spezifiziert werden. Eine konkrete prototypische Implementierung der Module und der WPIM-Pipeline erfolgt im Anschluss an diese hier vorliegende konzeptuelle Beschreibung Prozessidentifikation und Analyse Zentrales Element in der WPIM-Pipeline bildet der Innovationsprozess. Die Repräsentation eines Innovationsprozesses ist der Ausgangspunkt dieser muss über eine Benutzungsschnittstelle, z. B. über einen Dienst, hochladen, in die WPIM-Pipeline eingebracht werden. Der modellierte Prozess muss den in [Kap. 3.2] definierten Konzepten entsprechen und zudem dem Schema, abgeleitet aus dem mathematischen WPIM-Modell, gehorchen. Die Benutzungsschnittstelle muss neben dem Dienst hochladen weitere Dienste wie prozess_visualisierung und semantische_prozess_annotation unterstützen. Entscheidend beim Hochladen von Prozessen, z. B. in eine WPIM-Anwendung, ist die Auswahl eines geeigneten Prozesses. Es folgt eine Zusammenfassung der gezogenen Lehren bei der Auswahl geeigneter Innovationsprozesse in fertigenden Unternehmen. Unterstützung finden strukturierte und semistrukturierte Prozesse bei technischen Innovationen in fertigenden Industrien, z. B. Automobilindustrie, Luft- und Raumfahrt. Als ungeeignet sind Prozesse aufgefallen, die zu stark strukturiert sind, denn so werden Experten zu geringe Freiheitsgrade für Kreativität eingeräumt. Innovative Ideen können sich in stark stringenten Entwicklungsprozessen nicht/nicht ausreichend entfalten. Fehlt im Gegensatz eine Grobplanung der Abläufe und Aktivitäten, sind Verantwortliche oder Experten nicht benannt, fehlen Entscheidungs- und Eskalationshierarchien, so können Innovationen nicht systematisch hervorgebracht werden. In der Automobilindustrie sind die soeben erläuterten Extreme nicht üblich. Die Prozesse der Automobilindustrie sind in eine intakte unternehmerische Infrastruktur eingebettet und verfügen über den nötigen IT- Support. Prozesse sind dort in digitalen Formaten modelliert, einem Prozessbesitzer zugeordnet, und einer zeitlichen Ablaufplanung, z. B. Integrationsstufen, unterzogen. Weiterhin ist zu beachten, dass diese Prozesse auf unterschiedlichste Einflüsse und Rahmenbedingungen zeitnah reagieren müssen. Vorhandene Muster-Prozesse der Automobilindustrie sollen erneut genutzt und einer Wiederverwendung unterzogen werden. Bullinger zeigt Indikatoren auf, welche als Kostentreiber in innovativen Prozessumgebungen gelten [Bull06], wie z. B. Prozesse mit vielen Schnittstellenpartnern, eine Vielzahl an Dokumenten ohne konkrete Zuordnung und ähnliche Entwicklungen sowie inkrementelle Entwicklungen, wie sie häufig in der Automobilindustrie vorkommen. Abschließend bleibt festzuhalten: Die Benutzungsschnittstelle der WPIM-Pipeline soll das Hochladen beliebiger Prozesse unterstützen, die aus den für WPIM definierten Konzepten 105 Spezifischer Fokus im Sinne einer heuristischen Evaluation; kein ganzheitlicher Ansatz. 112

137 WPIM Modellbildung und Methodenentwurf aufgebaut sind und dem WPIM-Schema gehorchen. Die Auswahl und das Hochladen von geeigneten Prozessen in die WPIM-Pipeline liegen bei den Innovationsexperten Annotation der Prozessrepräsentation Nach dem Hochladen des Innovationsprozesses über eine Benutzungsschnittstelle wird in der WPIM-Pipeline eine Repräsentation des Prozesses visualisiert. Durch die Visualisierung des Prozesses werden in der WPIM-Pipeline diese Ziele verfolgt: Erstens wird durch die Abbildung des Prozesses ein Überblick für den Anwender geschaffen, in dem ersichtlich wird, welche Aktivitäten durchzuführen sind, in welcher Beziehung und Reihenfolge (z. B. Prozessphasen) diese zueinander stehen und wie diese miteinander interagieren (z. B. Unterprozesse). Dadurch werden Prozess-Start und Prozess-Ende sowie Meilensteine und Schnittstellen zu anderen Abteilungen oder unterstützenden Werkzeugen ersichtlich. Zweitens setzen sich die Experten bei der Prozessmodellierung intensiv mit ihrer Arbeit und Vorgehensweise bei der Prozessdurchführung auseinander. Durch dieses Vorgehen können sie neue Erkenntnisse gewinnen, bzw. den Zusammenhang eines Prozesses, dessen Eingliederung in den vollständigen Produktentstehungsprozess oder in das gesamte Unternehmen verstehen. Der visualisierte Prozesse und die Prozessbausteine können nun in der WPIM-Pipeline über die Benutzungsschnittstelle einzeln selektiert (technischer Dienst selektion) und annotiert (semantischer Dienst annotation) werden. Dazu wird durch die Benutzer Information zum und über den Prozess, z. B. in den Aktivitäten, abgelegt. Beispielsweise werden nach Selektion einer Aktivität die Durchführungsdauer sowie der Name der Aktivität eingetragen. Für den Benutzer nicht ersichtlich werden zusätzliche Relationen zwischen den digitalen Objekten (in diesem Beispiel ein Objekt Aktivität mit den Attributen Durchführungsdauer und Name) angelegt und semantisch repräsentiert. Ein Dienst (speichern) sorgt für die persistente Speicherung der annotierten Prozesse. Grundsätzlich gilt: Desto umfangreicher und präziser Prozesse, Pools und Aktivitäten durch die Anwender über die Benutzungsschnittstelle der WPIM-Pipeline annotiert werden, desto leichter können der Prozess bzw. dessen Bausteine identifiziert und wiedergefunden werden. In der WPIM-Pipeline wird über weitere Dienste (anpassen, erweitern und löschen) sichergestellt, dass auch spätere Anpassungen, Löschungen und Erweiterungen der Annotationen in die Repräsentation einfließen können Experten repräsentieren und annotieren Experten nehmen in der WPIM-Pipeline eine zentrale Rolle ein. WPIM will Experten bei der Erstellung innovativer Produkte unterstützen. Dazu ist es notwendig, dass Experten voneinander und von ihren Kompetenzen wissen, sich vernetzen und austauschen. Es wurde erkannt, dass Wissen und Experten nicht völlig voneinander zu lösen sind. [Lutz97; Wegg99; LuTr02; KSLK03] Daher ist es notwendig, für einzelne Prozessbausteine (wie Aktivitäten oder Pools) Experten anzugeben, die bei Herausforderungen und heiklen Entscheidungssituationen [vgl. Kap ] konsultiert werden können. Die Profildaten mit Kontaktdaten der Experten sind dazu in der Wissensbasis zu hinterlegen. Benutzungsschnittstellen zur Erstellung und Pflege von Expertenprofilen mit Kontaktdaten bieten die Dienste profil_erstellen und profil_anpassen an. Zunächst erstellt ein Experte einen Account (Dienst account_anlegen), um sich in der WPIM- Anwendung zu registrieren und anzumelden. Danach kann er über eine Eingabemaske sein Profil mit Kontaktdaten anlegen sowie seine Kompetenzen und Expertise einpflegen. Dazu ist es nicht nur notwendig, Namen zu hinterlegen, vielmehr sollen alle verfügbaren Kontaktdaten der Experten abrufbar bzw. die Experten direkt kontaktierbar sein. Hierzu sollen die vollständigen 113

138 WPIM Modellbildung und Methodenentwurf Kontaktdaten integriert werden. Die Experten hinterlegen ihr persönliches Profil, z. B. auch mit aktuellen Arbeitsgebieten oder Forschungsaufgaben. Im Sinne eines sozialen Netzwerks können sich Experten untereinander virtuell verbinden (Dienst experten_vernetzen). Um diese Profile auch maschinenverständlich aufzubereiten, werden die eingegebenen Daten automatisch semantisch aufgewertet. Dazu werden die Daten mit dem Friend-of-a-Friend (FOAF) Vokabular beschrieben [BrMi06]. Auch bestehende Profile aus sozialen Netzwerken können über URIs referenziert und über Benutzungsschnittstellen (mit dem Dienst externes_profil_referenzieren) in die WPIM-Pipeline eingebunden werden Ressourcen insbesondere Dokumente annotieren Weitere relevante Ressourcen, wie z. B. Dokumente, insbesondere Patente, Verknüpfungen und Beschreibungen können dem Prozessmodell und einzelnen Pools, Aktivitäten und Aufgaben zugeordnet werden. Dazu sind Ressourcen wie Dokumente über URIs zu referenzieren bzw. direkt in das WPIM-System hochzuladen (über Dienste dokumente_referenzieren, dokumente_hoch laden). Wir stellen die Annotation von Dokumenten (Dienst dokument_annotieren) in der WPIM-Pipeline nun beispielhaft vor: Dokumente haben einen Ersteller und ein Erstellungsdatum. Diese Attribute können nach dem Hochladen eines Dokumentes durch den Anwender befüllt bzw. annotiert werden. Auch Relationen zwischen Dokumenten und Autoren sind anzulegen, z. B. hat ein Patent mindestens einen Erfinder; oder auch Tutorials und Veröffentlichungen haben jeweils mindestens einen Ersteller, Tutor oder Verfasser. Die Namen dieser Personen werden manuell über die Benutzungsschnittstelle eingetragen. Ein deutlicher Mehrwert kann allerdings erzielt werden, wenn ein Dokument über die Relation hat_autor direkt mit dem Expertenprofil des entsprechenden Autors verknüpft wird. Über die Benutzungsschnittstelle wird demnach nicht nur die Zeichenkette für den Namen des Autors hinterlegt sonder direkt eine Referenz auf dessen Profil mit Kontaktdaten. In der Datenbasis kann später der Anwender durch das semantische Netz navigieren und gelangt so über Referenzen zu den Repräsentationen der Ressourcen. Besonders geeignet erscheint die Zuordnung von Ressourcen durch semantische Verknüpfungen mit den Aktivitäten und den Experten. Duplikate und ungewollten Redundanzen sowie veraltete Versionen von Dokumenten werden durch Referenzen reduziert/eliminiert. Beispielsweise gibt zu einem Patent (an zentraler Stelle) genau eine aktuelle mit Versionsnummer versehene Fassung, die aus unterschiedlichen Prozessen von Experten referenziert wird. Auch hier werden zur Annotation Semantiken eingesetzt. Für Dokumente verwenden wir das semantische Vokabular dem sog. Dublin Core [Dubl06, DCES06; DCES06a; BaFi05] das in [Kap ] vorgestellt wird. Über die Benutzungsschnittstelle kann zu einem Dokument, genauer zu einem referenziellen URI, eine Zusammenfassung des Dokuments annotiert werden. Über eine Referenz kann letztendlich das gesamte Dokument angezeigt werden. So wird im weiteren Verlauf der Arbeit die Methode der vier Wissensebenen mit der Drill-Through-Verfahren konkret im Dienst der Benutzungsschnittstelle der WPIM-Pipeline umgesetzt Prozessbausteine mit Ressourcen anreichern Die WPIM-Methoden sind darauf ausgelegt, Wissen prozessorientiert abzulegen und dem Wissenssuchenden bedarfsgerecht anzubieten und aufzubereiten. Prozessbausteine werden in der WPIM-Pipeline einzeln selektiert und über die Eingabemaske kann relevante Information der Aktivität zugeordnet werden. Vorgesehen sind u. a. die Attribute Name, Durchführungsdauer sowie eine Kurzbeschreibung der Aktivität. Neben der reinen Annotation von Prozessen (durch die Dienste prozesse_annotieren, aktivitaeten_annotieren) können über Benutzungsschnittstellen der WPIM-Pipeline den Prozessen Ressourcen zugeordnet werden. Die Zuordnung erfolgt relational und die zu verwendenden Relationen sind ebenfalls im semantischen WPIM- 114

139 WPIM Modellbildung und Methodenentwurf Vokabular hinterlegt. Der Prozess bildet im Rahmen dieser WPIM-Prozessorientierung den zentralen Ablageort und die zentrale Struktur für die Zuordnung von Ressourcen zum Prozess. Die Benutzungsschnittstelle stellt Dienste bereit, um speziell Dokumente und Experten den Prozessbausteinen, wie z. B. den Aktivitäten, zuzuordnen. Diese referenzielle und relationale Zuordnung erfolgt bei der WPIM-Pipeline durch die Experten. Diese ordnen zudem relevantes Wissen, gewonnene Erkenntnisse und Lessons Learned prozessspezifisch, i. S. eines prozessorientierten Wissensmanagements, den Innovationsprozessen zu. Um die Interaktion zwischen Anwendern und Maschine synergetisch zu unterstützen, wird das eigens entwickelte WPIM-Vokabular [vgl. Kap ] sowie die Technologien Resource Description Framework (RDF) und Web Ontology Language (OWL) genutzt [HeHe07]. In der semantischen Wissensrepräsentation ist der Kern der Interaktion zwischen Mensch und technischem System zu sehen. Die Beschreibung und Annotation der Prozesse, Pools und Aktivitäten mit Ressourcen erfolgt durch Experten über die Benutzungsschnittstellen durch Dienste. Soweit nötig und möglich wird referenziell auf bestehende digitale Objekte zurückgegriffen. Die Prozesse, Ressourcen sowie bestehende digitalen Objekte mit den verbindenden Relationen werden abschließend durch den Dienst rdf/xml_serialisierung in eine semantische Repräsentation überführt Prozess- und Aktivitätenbibliothek In die WPIM-Pipeline werden Prozesse hochgeladen, beschrieben und mit Ressourcen annotiert. Weiterführend werden dazu in der Pipeline Attribute sowie Relationen in Semantiken repräsentiert. Die ressourcen-erweiterte Prozessbeschreibung wird somit ebenfalls semantisch repräsentiert. Im Rahmen des kognitiven Walk-Through wurde erkannt, dass Aktivitäten in mehreren Prozessen parallel auftreten können [vgl. Kap ] und Muster-Prozesse für Folgeentwicklungen lediglich instanziiert [vgl. Kap ] werden. Um die Wiederverwendung der semantisch annotierten Prozesse und Prozessbausteine, wie z. B. Aktivitäten, sicherzustellen, sind Prozess- und Bausteinbibliotheken umzusetzen. Dazu sind neben den Bibliotheken Dienste vorzuhalten, die eine Selektion, Speicherung, Bearbeitung und Löschung von Prozessen und Aktivitäten in/aus den Bibliotheken ermöglichen. Hierzu sind für die WPIM-Pipeline geeignete Datenstrukturen und Benutzungsschnittstellen zu entwerfen. Ein Versionsmanagement für Prozesse und Aktivitäten der Bibliotheken ist in zukünftigen Implementierungen zu etablieren Semantische Annotation und (semantische) Suche Der semantik-zentrierte Entwurf stellt eine grundlegende Ausrichtung der gesamten WPIM- Pipeline dar. Die Semantiken dienen zur Sicherung von Eindeutigkeit (der späteren digitalen Objekte) und unterstützen zudem die semantische Suche [Kap Semantische Annotation und (semantische) Suche sowie Kap. 4.3 Semantische Suche]. Der semantik-zentrierte Entwurf fördert die Interaktion und Kollaboration von Mensch und Maschine. Dabei werden Prozessbausteine und integrierte Wissensbestandteile einer semantischen Beschreibung unterzogen. Ausgangspunkt der WPIM-Pipeline bilden die Prozessmodelle. Diese werden zunächst über eine Benutzungsschnittstelle durch die Benutzer selbst annotiert 106. Dazu steht eine geeignete Semantik (das sog. WPIM-Vokabular) bereit. Ebenso werden die Ressourcen (wie z. B. Experten und Dokumente) einer semantischen Annotation unterzogen. Die annotierten Prozessmodelle und die Beschreibungen der Ressourcen (Experten und Dokumente) werden integrativ zusammengeführt. Dies geschieht über geeignete Benutzungsschnittstellen. Hierbei werden einzelnen Aktivitäten, z. B. Ressourcen, relational zugeordnet. Auch für die Relationen 106 Bei der Annotation von Prozessen spricht man auch von Meta-Wissen über den Prozess. Typische Attribute für Meta-Annotationen sind Erstellungsdatum des Prozesses und Ersteller. 115

140 WPIM Modellbildung und Methodenentwurf sind spezielle semantische Bezeichner im Vokabular vorgehalten. Es entstehen integrierte Prozessmodelle 107, in denen sowohl die Prozessbausteine, die Ressourcen und die verbindenden Relationen semantisch annotiert sind und eindeutig repräsentiert werden (spätere Serialisierung in RDF/XML). Diese semantisch angereicherten Prozesse können nun nach benötigten Wissensund Ressourcenbestandteilen über eine Benutzungsschnittstelle durchsucht werden. Darüber hinaus entstehen semantische Suchen (Dienst semantische_suche), um Wissen/Information aus den Prozessmodellen, dem Expertennetzwerk und den verbundenen Ressourcen zu extrahieren bzw. inferentiell abzuleiten. Die semantischen Repräsentationen und semantischen Suchen stellen den Benutzern der WPIM-Pipeline ebenjenes Wissen bereit und schaffen so beim Wissenssuchenden einen Mehrwert gegenüber einer rein syntaktischen Suche. Auch bietet die zentrale Prozessorientierung einen geeigneten Fokus auf die, in den Unternehmen oft sehr umfangreiche, Wissensbasis. Die Verifikation der erzielten Suchergebnisse obliegt den Anwendern Conclusio des kognitiven Walk-Through Der kognitive Walk-Through durch die WPIM-Pipeline hilft, die geplante Vorgehensweise, die Benutzungsschnittstellen, die technische Arbeitsweise und das Zusammenspiel der Komponenten im Sinne einer ersten groben Evaluation der technischen Machbarkeit, Sinnhaftigkeit und Vollständigkeit 108 zu überprüfen. Weiterhin wird das Potenzial der technischen WPIM-Pipeline hinsichtlich der Erweiterbarkeit zum sozio-technischen WPIM- System dargestellt. Erkenntnisse bezüglich Anwendung und Bedienbarkeit fließen in Dienste und Benutzungsoberflächen ein, um die Interaktion zwischen technischer Implementierung und Anwendungssicht zu verbessern. Anhand des Walk-Throughs durch die WPIM-Pipeline werden die WPIM-Methoden weiterentwickelt. Die Notwendigkeit von Prozess- und Bausteinbibliotheken wird erkannt und entsprechende Anforderungen an Dienste und Benutzungsoberflächen abgeleitet. Der Entwurf der WPIM-Pipeline mit Benutzungsschnittstellen ist somit abgeschlossen. Der semantik-zentrierte Entwurf wird durchgängig bei der Operationalisierung WPIM-Anwendung verfolgt. Im Verlauf der Arbeit wird RDF 109, das Resource Description Framework [RDF; Hjel01] sowie OWL 110, die Web Ontology Language [OWL; Diec03; Sema06; HeHe07] eingesetzt. Experten werden mittels des Vokabulars FOAF und Dokumente mit dem Vokabular DC annotiert, eine begründete Auswahl dazu erfolgt im Rahmen der Operationalisierung [siehe Kap. 4]. Der Innovationsprozess, die Ressourcen und das Expertenwissen sollen systematisch in eine maschinenverständliche RDF- /XML-Notation überführt werden. Durch die durchgängig hinterlegte Semantik im WPIM- Modell werden Nutzenpotenziale in der Mensch-Maschine-Interaktion und somit auch in der sozio-technischen WPIM-Anwendung erwartet. Daher wird im nächsten Kapitel mit der systematischen Implementierung der Benutzungsoberflächen und der Operationalisierung der sozio-technischen WPIM-Pipeline begonnen. 107 Integriert werden in das Prozessmodell die Ressourcenmodelle, im Speziellen Expertenmodell und Dokumentenmodell. Das Prozessmodell wird zum sog. erweiterten WPIM-Prozessmodell. 108 In Bezug auf die Szenarien und Anwendungsfälle. 109 RDF: Formale Sprache zur Beschreibung von Metadaten OWL: Spezifikation des W3C, um Ontologien anhand einer formalen Beschreibungssprache erstellen, publizieren und verteilen zu können

141 Operationalisierung der WPIM-Pipeline 4 Operationalisierung der WPIM-Pipeline Die softwaretechnische Implementierung der WPIM-Pipeline mit ihren Benutzungsoberflächen, Diensten und Werkzeugen wird vorgestellt. Die Implementierung wird in [Kap. 4] durch entsprechende Abbildungen und Code-Ausschnitte 111 nachgewiesen. Die WPIM-Pipeline besteht aus dem WPIM-System und verbundenen IT-Werkzeugen. Die zwischen dem System und den Werkzeugen liegenden technischen Schnittstellen sowie der verbindende Datenfluss durch die WPIM-Pipeline werden vorgestellt. Insbesondere wird von Struktur und Verhalten des WPIM- Modells und der WPIM-Methoden auf die Architektur und die Dienste der WPIM-Pipeline übergeleitet. Die Struktur der WPIM-Pipeline wird aufbauend auf bestehenden Systemarchitektur-Paradigmen entwickelt. Die entstehende WPIM-Systemarchitektur wird zunächst spezifiziert und dann schrittweise verfeinert. Das Verhalten des WPIM-Systems wird in Form von technischen Diensten entworfen und spezifiziert. Im Rahmen der Implementierung können diese Dienste zu sozio-technischen Werkzeugen kombiniert werden. Im Sinne einer frühen Evaluation wird ein kognitiver Walk-Through durch die WPIM-Pipeline durchgeführt. Dieser dient zur Ableitung möglicher Erweiterungen hinsichtlich Benutzung und Funktionalität. Ausgehend von den vorliegenden Spezifikationen und der prototypischen Implementierung der WPIM-Pipeline wird eine WPIM-Anwendung realisiert. Die Wirksamkeit der WPIM-Methoden und sowie der erzielte Nutzen durch die WPIM-Anwendung zeigt die Evaluation in [Kap. 5]. Erweiterungen der WPIM-Pipeline sowie weiterführende Implementierungen über diese Arbeit hinaus werden von den Autoren ausdrücklich begrüßt. 4.1 Basistechnologien der Implementierung Die Basistechnologien der Implementierung werden vorgestellt und darüber hinaus semantische Technologien eingeführt. In der WPIM-Pipeline nimmt XML als Datenaustauschformat und Sprache zur Strukmturierung der Ressourcen eine zentrale Rolle ein. Die erweiterbare Auszeichnungs-Sprache (engl. extensible Markup Language, XML) ist ein Standard zur Erstellung maschinen- und menschenlesbarer Dokumente. Diese werden dargestellt in einer Baumstruktur, die vom World Wide Web Consortium (W3C) spezifiziert wird. XML definiert dazu Regeln für den Aufbau dieser XML-Dokumente [W3C]. Für die konkrete WPIM-Pipeline und die Umsetzung in einer Web-Anwendung müssen die Elemente der jeweiligen XML- Dokumente spezifiziert werden. Dies betrifft insbesondere die Festlegung der Strukturelemente und deren Anordnung. XML ist damit ein Standard zur Definition von beliebigen, in ihrer Grundstruktur jedoch stark verwandten Auszeichnungssprachen [vgl. W3C]. Eine Sprache wie XML zur Definition anderer Sprachen wird als Meta-Sprache bezeichnet. XML ist zudem eine vereinfachte Teilmenge von SGML [W3C]. Zudem wird auf Uniform Resource Identifier, Namespaces sowie die mit XML verbundenen Document Type Definitionen und XML-Schema Definition eingegangen. Diese Umfänge werden für die Operationalisierung der WPIM-Pipeline [in Kap. 4.11] zwingend benötigt URI, URIref und Namespaces Im Datenmodell von RDF spielt die Verwendung von Uniform Resource Identifier (URI) eine zentrale Rolle, da dadurch eine einfache, flexible und weit verbreitete Möglichkeit zur Identifizierung von Ressourcen geboten wird. [Brüg03, S. 8] Im Kontext von URI wird der Begriff Ressource als ein Objekt definiert, welches über eine eigene Identität verfügt. [Bern98] Anders ausgedrückt sind Uniform Resource Identifier 112 (URI) die universale Menge der Namen zur Benennung von Objekten im Internet. URIs werden von den Inhabern der Objekte vergeben. 111 Detailliert sind Skripte, Modelle und Dateien im Anhang der Arbeit beigefügt. 112 URI

142 Operationalisierung der WPIM-Pipeline Eine weitverbreitete Untermenge von URIs sind URLs, die Uniform Resource Locator [Fürn05], diese dienen der Referenz von Netzwerkressourcen und zur Adressierung von Internet-Seiten. URLs stellen somit eine Untermenge der URI dar. Der Vorteil der URLs besteht darin, dass bereits das zu verwendende Protokoll bzw. der Mechanismus, mit denen auf die Ressource zugegriffen werden soll, angegeben wird, z. B. ftp:// oder [vgl. Brüg03]. Bei RDF gilt alles als Ressource, was mit RDF-Ausdrücken beschrieben werden kann und über einen URI eindeutig identifizierbar ist. Besonders leicht kann man sich dieses für Web-Seiten vorstellen, wie z. B. bei ein HTML Dokument mit der eindeutigen URL Fürnkranz formuliert die Fragestellung, wie URIs auf Personen anwendbar sein können [Fürn05]. Als Lösungsvorschlag bieten sich -Adressen an, die im Internet eindeutig vergeben sind und somit der Eindeutigkeits-Forderung des URI-Konzepts sehr nah kommen. [Fürn05] Das URI-Konzept kann somit auch auf real verfügbare Ressourcen, wie z. B. Prozessdokumentationen (Objekte) oder Experten (Subjekte) angewendet werden. Ein URI soll derartige Ressourcen eindeutig beschreiben und auffindbar machen. Trotzdem können auch mehrerer URI eine Ressource identifizieren. In XML können eigene Elemente definiert und verwendet werden. Damit es zu einem Elementnamen nicht mehrere Definitionen gibt, werden die Elemente mit einem Namensraum versehen. Ein Namensraum ist ein URI und wird dem Elementnamen vorangestellt. Ein weiterer Effekt, der durch die Benutzung von Namensräumen entsteht, ist die Gruppierung der XML- Elemente, denn Elemente aus dem gleichen Namensraum decken meistens ähnliche Anwendungsgebiete ab. In einem XML-Dokument können die Elemente entweder mit ihrem vollen Namensraum oder in einer verkürzen Form angegeben werden. Die Schreibweise der kurzen Form verlangt zuerst eine Namensraum-Deklaration, wobei dem Namensraum eine Abkürzung zugeordnet wird. Danach kann diese Abkürzung dem Elementnamen vorangestellt werden, wodurch die Schreibarbeit verkürzt und vor allem die Übersicht erhöht wird. [Bade04, S. 8] Beispielsweise in RDF werden URIs nur in Form von sogenannten URI-Referenzen verwendet [LaSW99 in Brüg03]. Eine URI-Referenz (URIref) kann entweder ein absoluter oder relativer URI sein. Zudem ist es möglich mittels eines angehängten Identifikators (engl. fragment identifier) noch zusätzliche Referenz-Information zu übergeben. Solch ein Fragment- Identifikator wird von der eigentlichen, absoluten bzw. relativen URI durch das Rautensymbol (#) abgetrennt. Die Information, die dieser Identifikator enthält, gehört nicht zur eigentlichen URI. Wie diese Information von einem Programm interpretiert wird, geschieht in Abhängigkeit vom verwendeten Medien-Typ der identifizierten Ressource [Bern98 in Brüg03]. Falls es sich beispielsweise um eine normale Internetseite handelt, ist es meistens so, dass ein Fragment- Identifier den Bereich der Seite kennzeichnet, zu dem der Internet-Browser springen soll, deshalb auch Sprungadresse genannt. Die Verwendung eines solchen Identifikators ist daher auch nur bei Ressourcen sinnvoll, die auch wirklich abrufbar sind. [Bern98 in Brüg03] extensible Markup Language, XML Die Auszeichnungssprache XML hat sich in den vergangenen Jahren zum anerkannten Standard zur Strukturierung von Information entwickelt. Sie bildet ebenfalls die Grundlage für spätere Standards des Semantic Webs (auch als Web 2.0 betitelt). Da in dieser Arbeit Inhalte (wie Wissen und Information) nicht nur als syntaktisch korrekt, sondern auch semantisch verknüpft, durchsuch- und auswertbar betrachtet werden, nehmen die zentralen Gedanken des Semantic Web, insbesondere die Strukturierung und semantische Suche von Information und Wissen, eine entscheidende Rolle ein. 118 Im Gegensatz zu HTML identifizieren XML Tags Daten, wohingegen HTML Tags nur Formatierungsangaben beinhalten. Ein XML-Dokument muss wohlgeformt sein. Wohlgeformtheit beschreibt eine Reihe von Bedingungen und Regeln, die als Mindestanforderungen erfüllt sein müssen, um ein XML-Dokument mit XML-Werkzeugen

143 Operationalisierung der WPIM-Pipeline verarbeiten zu können. Zur Wohlgeformtheit gehört, dass es zu jedem öffnenden auch einen schließenden Tag geben muss. Weiterhin gehört dazu, dass jedes XML-Dokument genau ein Wurzelelement hat, welches das gesamte Dokument umschließt. Alle Elemente, die im Inneren des Dokuments angewendet werden, sind hierarchisch in das Wurzelelement eingeschlossen und somit direkte oder indirekte Kindelemente. Ein Element muss jedoch nicht zwingend Kindelemente haben. Es kann auch vollständig leer sein. In diesem Fall ist eine Kurzschreibweise erlaubt, welche nur ein Tag benötigt und für das Tag element wie folgt aussieht: <element />. [Bade04, S. 9] XML erlaubt die Verschachtelung von Elementen, wobei alle Elemente in ein sog. Root- Element eingebettet werden müssen. Im Gegensatz zur Verschachtelung sind Überlappungen nicht zugelassen. XML-Dokumente können als Baumstruktur angesehen werden, wobei jedes Element ein Knoten ist. Die unmittelbar in einem <Element> enthaltenen Elemente sind die Nachfolgerknoten von diesem <Element>. An den Blättern dieses Baumes steht dann die Information in den einzelnen Tags. [Fürn05] Auf Prozesse übertragen stellt man sich das Wurzelelement, das sog. Prozess-Tag vor und tiefer in der Baumstruktur als Nachfolgerknoten die Prozesselemente 113 (Prozess, Pool, Aktivität), welche wiederum z. B. ein Ersteller-Tag und ein Bezeichner-Tag nach sich ziehen. In diesen Blättern stehen dann die Attribute, z. B. der konkrete Name des Erstellers bzw. die Bezeichnung des Prozesselements. Sprachen zur Adressierung von Knoten in XML-Dokumenten wie XPointer und XLink werden in Eckstein/Eckstein [EcEc04, S. 9] erörtert. XML hat sich vom ursprünglichen Zweck, eine verbesserte Markup-Sprache für Dokumente zu bieten, zu einem generellen Datenaustausch- Format entwickelt, viele Applikationen können ihre Daten in XML exportieren und aus XML importieren. [Fürn05, S. 25] Ein Problem beim Datenaustausch zwischen Austauschpartnern bzw. Applikationen ist jedoch, dass beide, die Empfangende wie die Sendende, eine gemeinsame XML-Struktur sowie enthaltene Elemente festlegen müssen. Zudem ist es notwendig, dass die XML-Struktur maschinenlesbar ist. Sprachen zur Beschreibung von XML-Strukturen sind die Formalismen Document Type Definition (DTD) oder das vielfältigere XML-Schema (XSD) Document Type Definition, DTD Zunächst wird die Document Type Definition (DTD) vorgestellt. Die XML-DTD ist wie ein XML-Dokument modular aufgebaut. Anhand der DTD können XML-Instanzen erzeugt bzw. diese Instanzen auf ihren korrekten, syntaktischen Aufbau und Struktur hin überprüft werden. Eine DTD legt eine Reihe von Einschränkungen für ein XML-Dokument fest. Ein XML-Dokument gilt als zulässig, wenn es den Einschränkungen gehorcht, die die DTD für die Formatierung der XML-Daten auferlegt. [Dalh01, S. 6] Prinzipiell sind in Verbindung mit DTDs zwei zentrale Maßnahmen zu erwähnen: Deklaration: Eine DTD ist immer als ein zusätzlich anzulegendes Dokument mit eigener Syntax. Dabei wird zwischen externer DTD und interner DTD unterschieden. Interne DTDs werden direkt in die XML-Datei eingebunden. Externe DTDs werden als zusätzliche Datei mit dem Suffix.dtd angelegt und müssen referenziert werden. Referenz: Zur Referenz muss in der XML-Datei ein Referenzpfad auf die externe DTD angegeben werden. Bei internen DTDs wird auf eine Referenz verzichtet, da XML und DTD bereits gemeinsam in einer Datei verankert sind. 113 Prozesselemente werden in dieser Arbeit auch als Prozessbausteine bezeichnet, darunter werden z. B. Aktivitäten, Pools sowie Splitter und Konnektoren subsumiert. 119

144 Operationalisierung der WPIM-Pipeline Zur Validierung der XML-Instanz kann gegen die DTD (ob intern oder extern) eine Syntax- und Konsistenz-Überprüfung vorgenommen werden, z. B. durch einen Parser [Dalh01, S. 6; BeMi98]. Ein Parser überprüft (engl. validation) das XML-Dokument gegen die DTD. Dabei wird die syntaktische Korrektheit (auch Wohlgeformtheit) der XML-Daten sowie die Gültigkeit (engl. valid) der XML-Datei als eine mögliche Instanz der DTD überprüft. Parser sind in XML- Softwareprodukte, wie z. B. XMLSpy 114, eingebunden. Informell kann der Inhalt einer DTD folgendermaßen erklärt werden: Sie enthält Information darüber, welche Elementtypen es gibt, welchen Inhalt sie haben dürfen, welche Attribute erlaubt sind und welche Werte sie annehmen dürfen. [BeMi98, S. 72] Eine DTD definiert unabhängig von den eigentlichen Daten die Regeln für erlaubte Elemente, Attribute und Verschachtelungsmöglichkeiten. Somit ist eine Validierung von XML Daten bezüglich der DTD möglich und garantiert, dass die XML Daten sich auch genau an die spezifizierten Regeln hält. Nur so ist es möglich, dass sich verschiedene Autoren und verschiedene Software-Produkte an die Konventionen einer Sprache halten und die Sprache nicht durch spontane, undefinierte Erweiterungen verwässert und für interpretierende Software unbrauchbar wird. Um neue Elemente oder Regeln in eine XML Sprache einzufügen, muss daher zuerst die entsprechende DTD erweitert werden, um die Tags verwenden zu können. [Bade04, S. 8] Bei planerischen oder wissenschaftlichen Vorgehensweisen entstehen im zeitlichen Verlauf zuerst die DTD bzw. die XSD und dann die XML-Instanzdokumente. Bei Entwicklungen in der industriellen Praxis ist dies oftmals genau umgekehrt, auch können DTD/XSD und XML iterativ oder parallel entwickelt werden XML-Schema-Definition, XSD XML-Schema-Definitionen (XSD), kurz Schemata, sind die jüngere Form einer Darstellung dessen, was in einem XML-Dokument enthalten sein darf und was nicht. Schemata bezeichnen häufig definierte Vokabulare [Cham01]. Wie bereits DTDs sind auch XSD-Schemata ein W3C- Standard 115 und können wie DTDs dazu verwendet werden ein XML-Dokument zu validieren. [Jako06; KaBM08, S. 92] Soll ein XML-Dokument in ein bestehendes Schema eingeordnet werden, so ist vor den eigentlichen Daten das Schema im XML-Dokument zu referenzieren. Im Gegensatz zu DTDs kann ein Schema nicht im XML-Dokument selbst enthalten sein, sondern ist immer eine eigenständige Datei [Jako06]. Schemata sind viel leistungsstärker, übernehmen aber den gleichen Zweck wie DTDs: Sie validieren XML-Dokumente auf gültige Struktur (Wohlgeformtheit 116 und Gültigkeit 117 ). XML-Parser können Dokumente, die nicht wohlgeformt sind, ohnehin nicht verarbeiten. Die Gültigkeit eines XML-Dokuments geht über Wohlgeformtheit des Dokuments hinaus und XSD-Schemata sind ein hervorragendes Mittel, die Struktur der XML-Dokumente zu beschreiben. 114 XMLSpy der XML-Editor von Altova XSD-Schemata sind seit 2001 eine W3C-Empfehlung. 116 Wohlgeformtheit: Ein XML-Dokument muss der XML-Konvention entsprechen und darf, z. B. nur ein Root-Element besitzen. 117 Gültigkeit: Ein XML File ist dann gültig (für ein XSD-Schema oder eine DTD), wenn die Struktur und die Verwendung der Elemente diesem Schema bzw. der DTD folgt. 120

145 Operationalisierung der WPIM-Pipeline Nach Jakobs leistet ein Schema folgendes [Jako06]: definiert die Elemente, die in einem Dokument vorkommen dürfen, legt die Attribute fest, die vorkommen dürfen, legt fest, welche Kind-Elemente ein Element haben darf, legt die Reihenfolge der Kind-Elemente eines Elements fest, legt die Anzahl der Kind-Elemente fest, legt fest, ob ein Element leer sein darf, legt Datentypen fest, legt Default-Werte und voreingestellte Werte fest. Gerade bei der Übergabe von Daten sind XML-Schnittstellen und Schemata besonders sinnvoll: Zum Datenaustausch können das Datenformat, die Elemente und Attribute genau festgelegt werden und die sendende sowie die empfangende Applikation kennen die zu verarbeitenden Strukturen DTD vs. XSD XML-Schemata als Nachfolger von DTDs bieten besondere Vorteile [vgl. Jako06]: sind erweiterbar, sind aussagekräftiger und hilfreicher als DTDs, sind selbst in XML geschrieben, unterstützen viele Datentypen (nicht nur PCDATA), kennen reguläre Ausdrücke, unterstützen Namensräume. Der Namensraum (engl. namespace) zu xsd 118 sowie Element-Typen in XML-Schema: <xsd:schema xmlns:xsd= > <xsd:complextype> <xsd:element name= Kopf >... </xsd:element>... </xsd:complextype> </schema> Code 4.1: XSD Namensraum Weitere Beispiele zu wohlgeformten DTD-Konzepten in XML-Schemata, Elementtypen Datentypen und Kardinalitäten finden sich bei Eckstein/Eckstein [EcEc04, S. 84 ff.]. Es ist möglich, unterschiedliche XML-Schemata in einem XML-Dokument zu implementieren. Damit es bei der Zusammenführung der Vokabulare nicht zu Überschneidungen und Problemen kommt, werden Namespaces verwendet, diese erlauben eine Disambiguation der Quellen. [EcEc04] xmlns:ns1= xmlns:ns2= Code 4.2: Namespaces Die Elemente der unterschiedlichen Schemata können dann über das jeweilige Präfix (z. B. ns1 und ns2) adressiert werden. Die gleichbenannten Elemente Name, für Prozesse bzw. für Personen, können somit eindeutig unterschieden werden: 118 Der XML-Namespace xmlns zu XSD lautet: xmlns:xsd= 121

146 Operationalisierung der WPIM-Pipeline <ns1:name>dr. Schmied</ns1:name> <ns2:name>testprozess </ns2:name> //ein (Personen)Name nach Schema n1 //ein (Prozess)Name nach Schema n2 122 Code 4.3: Präfixes bei Namespaces Ein erstgenannter Namensraum kann als default-namensraum festgelegt werden. Mit den Anweisungen import und include können weitere Namensräume implementiert, bzw. bestehende Namensräume überschrieben werden. [Cost06; Schö03] XSL, XSLT, XQL und XML-Werkzeuge Es sind noch die Sprachen extensible Stylesheet Language (XSL), XSL Transformation (XSLT) und XML Query Language (XQL) zur erwähnen: XSL dient zur Spezifikation der Formatierung eines XML-Dokuments sowie XSLT Spezifikation für Transformation von XML-Dokumenten, z. B. kann ein Stylesheet realisiert werden, indem man eine Transformation von XML in HTML spezifiziert. Mit XSLT können Sichten auf XML-Dokumente erzeugt werden, die Sicht stellt einen Ausschnitt aus der Ausgangs-XML-Datei dar. Diese Sicht kann z. B. im HTML-Format im Browser angezeigt werden. XQL ist eine einfache Abfragesprache für XML-Dokumente und der Vorläufer von XQuery. XQL basiert auf der XPath-Spezifikation. XPath ist in diesem Sinn keine Abfragesprache, eröffnet aber die Möglichkeit, auf bestimmte Teile von XML-Dokumenten und deren Attribute zuzugreifen. XPath bietet zudem die Möglichkeit, aus Programmiersprachen, z. B. aus PHP 119 heraus, XML-Bäume nach Ausdrücken und Elementen zu durchsuchen. Die Ergebnisse werden als Zeichenketten extrahiert und zurückgegeben. Eine gute Übersicht zu XML-Verarbeitungs-Werkzeugen (engl. processing tools) und XML-Editoren wird bei XML.com 120 aufgestellt. Für weitere XML-Processing-Werkzeuge und weiterführende XML- Ressourcen sind die Webseiten von Robin Cover 121 zu SGML 122 /XML empfehlenswert SAX vs. DOM Das Simple API für XML (SAX) ist eine für Java entwickelte Schnittstelle für das Parsen, also die Syntaxanalyse von XML-Dateien. Weitere Implementierungen sind existent für Programmiersprachen, wie C++, Python oder Perl. SAX ist eine Open-Source-Entwicklung, die u. a. durch SourceForge 123 getrieben wurde. Ebenfalls ein Parser ist der DOM-Tree, basierend auf dem Dokument Object Model 124 (DOM) mit der Sprache XPath zur Navigation und zur eindeutigen Identifikation von Objekten in einem DOM-Tree, die schlicht den Pfad zu dem gewünschten Element bzw. dessen Inhalt beschreibt. Im Gegensatz zu SAX liest DOM das XML-Dokument im Ganzen als Baumstruktur ein und speichert es zwischen. Dies ermöglicht schnelleren Zugriff auf beliebige Baumknoten und Teilbäume, benötigt dazu aber Ressourcen im Speicher. Bei SAX wird das XML-Dokument sequenziell durchlaufen. Somit ist es nicht notwendig, das ganze Dokument in den Arbeitsspeicher zu laden und zusätzlich eine Baumstruktur aufzubauen. DOM ermöglicht es zudem, neue XML-Dokumente zu erstellen bzw. das bestehende XML-Dokument zu manipulieren. SAX ist auf ereignisgesteuerte Zugriffe ausgelegt, somit ist es möglich, dass Anwendungen ein Ereignis auslösen und Knoten, Inhalte oder Teilbäume aus dem XML-Dokument ausgelesen werden. Auch eine umgekehrte, ereignisgesteuerte Ansteuerung ist denkbar: SAX unterstützt eine ereignisgesteuerte 119 PHP steht für Hypertext Preprocessor bzw. für Personal Home Page und ist eine Skriptsprache mit einer an C und Perl angelehnten Syntax XML Robins Cover Homepage Standard Generalized Markup Language SourceForge Hompepage DOM Homepage -

147 Operationalisierung der WPIM-Pipeline Verarbeitung der XML-Dokumente, das heißt, wenn ein Knoten im Baum vom Parser gelesen wird, wird ein Ereignis ausgelöst, das von Anwendungsprogrammierern entsprechend behandelt werden kann. [Skou02, S. 7] 4.2 Semantic-Web-Technologien Das Semantische Web (engl. Semantic Web) ist die semantische Erweiterung des World Wide Web (WWW) um maschinenlesbare Daten. Diese Daten spezifizieren formal die Semantik, also die Bedeutung der Inhalte (engl. content). Das Semantic Web stammt von WWW-Begründer Tim Berners-Lee [Bern98; Stab01; Stab01b]. Information soll zusätzlich zu der für Menschen lesbaren Form auch formal, in einer für Maschinen verarbeitbaren Form repräsentiert werden, damit Programme darauf operieren können, so dass Anfragen aufgrund ihres Bedeutungsinhalts anstelle ihrer Schreibweise bearbeitet werden können. [Sema06a] An dieser Stelle sei auch auf das 7-Schichten-Modell des Semantic Web verwiesen [Fürn05, S. 15]. Der Nutzen entsteht jedoch erst, wenn Inhalte (engl. content) mit Semantik angereichert werden und zudem semantische Suchmaschinen diese Semantik verarbeiten. Die bestehenden Anfragen (engl. queries) sollen zukünftig durch semantische Antworten ergänzt bzw. ersetzt werden. So kann bei steigender Precision (Prozentsatz der relevanten Dokumente in den gefundenen Dokumenten) auch der Recall (Prozentsatz der gefundenen Dokumente unter allen relevanten Dokumenten) reduziert werden. Denn eigentlich geht es doch darum, möglichst wenige dafür besonders relevante Ergebnisse aufgezeigt zu bekommen. [Fürn05, S. 6] Zur semantischen Beschreibung von Ressourcen, wie z. B. Dokumenten, Personen, Bildern oder elektronischen Geräten (engl. devices), stehen Dublin Core (DC), Platform for Internet Content Selection (PICS) und Simple Knowledge Organisation System Core (SKOS) zur Verfügung. Für die Modellierung von maschinenverarbeitbaren Thesauri und Vokabularen werden Friend-of-a- Friend (FOAF) und Composite Capability Preference Profiles (CC/PP) diskutiert. Die semantischen Technologien RDF/OWL sowie die Vokabulare DC und FOAF werden im praktischen Teil dieser Arbeit, in der WPIM-Pipeline [vgl. Kap. 4.11] genutzt und implementiert Grundlagen und Schichtenmodell des Semantic Webs Nach Bos [Bos05] sind Techniken, die für die Repräsentation von Information im World Wide Web (www) benötigt werden, auf der untersten Stufe in [Abb. 4.1] anzusiedeln. Für die Darstellung von einzelnen Zeichen wird Unicode 125 verwendet. Zur eindeutigen Identifikation von unterschiedlichen Ressourcen im www wird dagegen von, sog. Uniform Resource Identifiers (URI) Gebrauch gemacht. Den Begriff Universal Resource Identifier führte ursprünglich Berners-Lee ein [Stab01, Bern94] und darauf aufbauend die XML-basierte [vgl. EcEc04] zweitunterste Schicht, die eine strukturierte Darstellung von Dokumenten sowie das Hinzufügen von Meta-Daten ermöglicht. Anhand dieser Meta-Daten kann zwar der interne strukturelle Zusammenhang eines Dokuments festgelegt werden, doch sie reichen nicht aus, um explizit Bedeutung zu definieren oder Beziehungen zwischen Web-Ressourcen darzustellen [Roth02; Bos05]. 125 The Unicode Consortium

148 Operationalisierung der WPIM-Pipeline Abb. 4.1: Schichtenmodell des Semantic Webs [vgl. in Bos05] Nach [Bos05] werden dazu die Ebenen RDF mit rdfschema und Ontology vocabulary benötigt. Der Standard RDF [MaMi04 in Bos05] wird verwendet, um einfache inhaltliche Zusammenhänge auszudrücken. Mit der Erweiterung von RDF-Schema [BrGu02; KaBM08; HKRS07; Hitz08] werden zusätzliche Beschreibungsmöglichkeiten einer semantischen Struktur zur Verfügung gestellt. Da aber auch die Ausdrucksfähigkeit von RDF-Schema nicht ausreicht, komplexe Sachverhalte zu modellieren, wird die Verwendung von Ontologien in einer nächsten, höheren Schicht vorgesehen. Mit der Benutzung von Ontologien ist es möglich, eine Semantik zu den einzelnen Web-Ressourcen bereitzustellen, die sowohl von Menschen als auch von Maschinen interpretiert werden kann. Auch in der darüber liegenden Schicht der Logik (engl. logic) wird zusätzliche Semantik bereitgestellt, die für eine maschinelle Verarbeitung benötigt wird. Für diese und die darüber liegenden Schichten des Semantic Web [BrGu02; KaBM08; HKRS07; Hitz08] wird derzeit noch Grundlagenforschung betrieben [Stab01; Stab01b; Roth04; Bos05] Glossare, Thesauri, Taxonomien, Ontologien Ein Glossar ist eine Sammlung von spezifischen Vokabeln in einem Handlungskontext 126. Ein Glossar dient dazu, durch die Definition verbreiter Vokabeln in einem Unternehmen eine einheitliche Diskussionsgrundlage zu schaffen. In der fertigenden Industrie ist es in Projekten durchaus üblich, nach dem Kickoff erst einmal eine einheitliche Sprache, ein einheitliches Glossar zu Entwickeln, um ein einheitliches Verständnis zu Vokabeln z. B. zwischen verschiedenen Fachbereichen zu etablieren. Spricht eine Entwicklungsabteilung bspw. von Codierung, so ist die Codierung eines speziellen Steuergeräts gemeint. Spricht eine Fertigungsabteilung oder auch ein Werk von Codierung, so ist die initiale Codierung des gesamten Fahrzeugs angedacht. Eine Serviceabteilung hingegen versteht darunter die erneute Codierung nach einer Reparatur oder das Aufbringen neuer Codierdaten im Sinne eines Updates. Die IT-Abteilung assoziiert die Implementierung von Software mit Codierung. Thesauri beschäftigen sich mit Synonymen 127 und Homonymen 128 und dienen dazu, Worte mit 126 Rekursive Definition von Glossar über Wikipedia, das wiederum ein (online) Glossar ist: Ein Glossar ist eine Liste von Wörtern mit Erklärungen Zwei Ausdrücke sind synonym, wenn sie die gleiche (ähnliche) Bedeutung haben Als Homonym bezeichnet man ein Wort, das für verschiedene Begriffe oder unterschiedliche Einzeldinge steht

149 Operationalisierung der WPIM-Pipeline gleicher Bedeutung identisch zu interpretieren. Es ist nur wenig sinnvoll, wenn in einem Automobilunternehmen ein Entwicklerkreis von Experten und ein anderer von Fachleuten spricht. Wird ein Ansprechpartner als Experte im Internet angepriesen, so wird dieser bei Suchen nach Fachmann nicht gefunden. Thesauri werden in Anwendungen häufig durch Auswahllisten oder Autovervollständigung bei der Eingabe in Formulare unterstützt. [Rach05] Taxonomien dienen zur Beschreibung von Ressourcen im Semantic Web. Eine Taxonomie dient der Klassifizierung eines Objektes, d. h. dass etwas einen bestimmten Namen erhält und hierarchisch in einer Wissensbasis eingeordnet wird. Dabei erfolgt die Klassifizierung in Form einer einfachen Hierarchie, i. d. R. dargestellt als Baumstruktur mit Knoten und Zweigen. [vgl. Rach05] Innerhalb der Hierarchie hat jeder Knoten nur einen Vorgängerknoten. Taxonomien sind sehr hilfreich, um Informationseinheiten semantisch zu klassifizieren. Tiefer verschachtelte Zweige der Taxonomie enthalten spezifischeres Wissen, während Knoten, die näher an der Wurzel liegen, allgemeinere Information enthalten. Durch diese Klassifizierung von Wissensbereichen innerhalb einer Hierarchie entsteht eine einfache Semantik. [Taxo06, Rach05] Ontologien Für die Repräsentation von komplexen Wissensbeziehungen hat sich in der Informatik der Begriff der Ontologie eingebürgert. Der Unterschied zur Taxonomie ist der, dass die Ontologie ein Netzwerk aus Information darstellt, während die Taxonomie eine einfache Hierarchie bildet. Des Weiteren enthält eine Ontologie auch logische Relationen, d. h. es werden bestimmte Eigenschaften und Beziehungen von semantisch zusammenhängenden Elementen erzeugt. Ontologien bestehen aus verschiedenen Komponenten wie Klassen, Instanzen und Relationen. Eine Ontologie stellt somit ein Modell der Welt oder eines Teils der Welt dar, über deren Begriffe und Zusammenhänge eine Gruppe von Experten/Nutzern Einigkeit erreichte. Die Ontologie soll dazu eine Wissensstruktur abbilden, wobei durch diese Formalisierung Mehrdeutigkeit vermieden wird. Ontologien sind üblicherweise in Taxonomien, also in einer Baumstruktur mit mehrfacher Vererbung und disjunkten Unterkategorien organisiert. Diese Kategorien (Konzepte) können mit anderen Kategorien über Relationen verknüpft oder mit Attributen detailliert beschrieben werden. [StSN01, S. 10] Ontologien stellen zusätzlich zur Navigationsunterstützung Modellierungsmöglichkeiten zur Verfügung, welche zusätzliche Funktionen des Wissensmodells ermöglichen. So kann nicht nur eine Beziehung zwischen den Konzepten Mitarbeiter und Thema definiert, sondern diese zusätzlich qualitativ belegt werden [vgl. StSN01, S. 11], z. B. Mitarbeiter ist ein Experte zu einem Thema. Durch die Verwendung von Regeln über diese Beziehungen können logische Schlussfolgerungsketten aufgebaut und abgebildet werden. Somit werden implizite Beziehungen definiert, die in einer Inferenzmaschine ausgewertet werden können. [vgl. StSN01, S. 11] Die Annotation der HTML/XML-Seiten im Web geschieht, z. B. mittels Repräsentationssprachen wie RDF oder der darauf aufbauenden Web Ontology Language (OWL). Dadurch werden verbesserte Kategorisierungsmöglichkeiten zur Verfügung gestellt, z. B. wird die Bedeutung von WWW-Links durch deren Annotation eindeutig beschrieben [Onto06]. Ontologien bilden neben den hierarischen Beziehungen zwischen den Konzepten einer Taxonomie auch horizontale sog. semantische Relationen aus [Onto06]. Taxonomien können im Sinne einer Baumstruktur mittels Tiefen- oder Breitensuche durchsucht werden. Bei Ontologien hingegen können gezielt Anfragen sog. semantische Suchen an die Ontologie gerichtet werden zudem kann automatisiert neues Wissen, z. B. per Inferenz [vgl. Buch04] oder geeigneten Abfragesprachen, abgeleitet werden. 125

150 Operationalisierung der WPIM-Pipeline Meta-Wissen Meta-Wissen ist in der Begriffshierarchie über der Wissensebene angeordnet. Das kann z. B. Wissen über Quellen und Adressaten des Wissens [Naum99, S. 48] sein. Meta-Texte oder Meta- Inhalte sind Beschreibungen zu einem Text oder dem Inhalt eines Dokuments. Es sind Schlagworte, die aus dem Inhalt abgeleitet werden, um diesen knapp wiederzugeben, ähnlich der Schlagworte (engl. key oder meta words), welche meist zu Beginn an einer definierten Stelle von Dokumenten stehen. Üblicherweise erfolgt die Wiedergabe nicht als zusammenhängende Beschreibung im Sinne eines Referates. Gerade im Internet stehen in HTML-Dokumenten oft spezielle Meta-Tags zur Verfügung, um die inhaltliche Beschreibung mittels Schlagworten zu realisieren. Bei Suchanfragen im Internet werden genau diese Meta-Tags durchsucht und auf Treffergüte und Häufigkeit bewertet. Dokumente mit hoher Trefferzahl werden als erfolgreiche Suchergebnisse präsentiert. Soll Information über Informationssysteme bereitgestellt werden, ist die Beschreibung des Dokuments von enormer Bedeutung, denn: Die wichtigste Information ist ohne Nutzen, wenn sie im Unternehmen nicht gefunden wird. Meta-Wissen beschreibt in dieser Arbeit Wissen über Ressourcen, also u. a. Dokumente, Prozesse und Personen. Zur Beschreibung von Dokumenten können Schlagworte herangezogen werden, die im Dokument abgelegt werden und das Dokument selbst beschreiben. Da diese Schlagworte von Mitarbeitern oft manuell eingepflegt werden, sind sie nicht eindeutig, da jeder Mitarbeiter andere Begriffe mit dem Dokument assoziiert bzw. unterschiedliche Schlagworte heranzieht. Zudem ergibt sich das Problem, wenn ein Schlagwort einen typografischen Fehler enthält oder schlicht vergessen wird. Das Dokument wird von konkreten Suchanfragen nicht identifiziert. Diese Verschlagwortung von Ressourcen, wie z. B. von Dokumenten und Internetseiten, wird als Tagging bezeichnet und stammt ab von den Markierungen (engl. Tags) der Auszeichnungssprachen, wie z. B. HTML 129 und XML 130 [BeMi98, Dalh01, Cost06, EcEc04]. Dabei wird ein Schlagwort Innovation als Markierung <Innovation> repräsentiert. Viele Unternehmen und Lösungsanbieter denken über Schlagwortkataloge nach, die über mehrere Ebenen strukturiert und erweiterbar sein können. Einer Studie zufolge, umfassen derartige Taxonomien in der Praxis zwischen 200 und Begriffe zur Verschlagwortung [MFOW06]. Vorteile dieser Schlagwortkataloge sind darin zu sehen, dass: Schlagworte vorgegeben werden und nicht jedes Mal durch die Mitarbeiter neu festgelegt und angelegt werden müssen, Schlagworte eindeutig sind und Funktionen Schlagworte automatisch vorgeben bzw. diese automatisch (auto- Vervollständigung) bei der Eingabe vervollständigen. Der Verschlagworter erhält so mehr oder minder sinnvolle Schlagworte zur Auswahl. Diese Tagging-Methode mag für einzelne Unternehmen ausreichend sein. Eine Herausforderung ist darin zu sehen, in strukturierten Schlagwortkatalogen eine geeignete Schlagwortebene zu finden [vgl. ScSe06]. Ein Mittelweg zur Beschreibung von Ressourcen zwischen zu generisch und zu detailliert muss gefunden werden. Problematisch wird es zudem, bei der Verwendung bzw. Kombination solcher Kataloge über Unternehmensgrenzen hinweg. Als Ausweg wurden Top-Down-Vokabulare identifiziert, die solche Schlagworte standardisiert und global zur Verfügung stellen. Schormann und Seidel erachten Tagging erst bei einem großen 129 HTML: Hypertext Markup Language (Hypertext-Auszeichnungssprache) oder auch als Hypertext bezeichnet, ist eine textbasierte Auszeichnungssprache zur Strukturierung von Inhalten wie Texten, Bildern und Hyperlinks in Dokumenten. HTML-Dokumente sind die Grundlage des WWW und können durch Web-Browser dargestellt werden XML: extensible Markup Language (erweiterbare Auszeichnungssprache) ist eine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten in Form von Textdaten

151 Operationalisierung der WPIM-Pipeline Mitarbeiterstamm bzw. einer weltweiten Usergroup als sinnvoll. Denn bei einer großen Anzahl an Usern werden diese ähnliche und identische Tags zur Annotation heranziehen. Zudem sehen sie im Tagging den Vorreiter von RDF [ScSe06]. Anzumerken ist, dass diese semantischen Ansätze wie Dublin Core [Dubl06; DCES06; DCES09; BaFi05] oder RDF über ein einfaches Tagging hinausgehen und zudem Ressourcen in Beziehungen setzen [vgl. ScSe06] Resource Description Framework, RDF Resource Description Framework (RDF) ist ein Standard des W3C und wurde im Jahre 1999 verabschiedet. Es ist eine Weiterentwicklung von XML, um Komponenten zum Anlegen von Meta-Daten zu Information bereitzustellen. Während XML sich vornehmlich auf die Strukturierung von Daten durch die Zuordnung zu XML-Tags beschränkt. Als grundlegendes Modell bei RDF sind drei Objekttypen vorgesehen, die zur Spezifikation von Fakten dienen: Subjekt, (auch Ressource, Klasse), Prädikat, (auch Eigenschaft, engl. property), Objekt, (auch Wert). Ressourcen wurde bereits mit dem URI-Konzept beschrieben. Eine Prädikat bzw. eine Eigenschaft ist ein bestimmter Aspekt oder eine Charakteristik, ein Attribut oder ein Verhältnis, durch welche Ressourcen beschrieben werden können. Jede Eigenschaft besitzt eine besondere Bedeutung: Sie definiert Wertebereiche, die Typen oder das Verhältnis zu anderen Eigenschaften. Eine bestimmte Ressource mit einer genannten Eigenschaft und dem Wert dieser Eigenschaft in Bezug auf die Ressource ist eine RDF-Aussage. Die drei individuellen Teile einer Aussage sind als Subjekt, Prädikat und Objekt benannt. Das Objekt einer Aussage kann eine andere Ressource oder eine Zeichenkette (benannt als Literal 131 ) sein. [Skou02, S. 19] Das Resource Description Framework (RDF) bildet ein Modell zur Repräsentation von Meta- Daten. Diese Meta-Daten können Information über Webseiten und andere Objekte sein im vorliegenden Fall zu Prozessen, Wissen, Experten und Innovationen. Am weitesten verbreitet ist die Serialisierung von RDF in XML. In Verbindung mit RDF-Schema und der Web Ontology Language soll RDF als grundlegendes Format zur Repräsentation von Taxonomien (Thesauri, Glossare) und Ontologien (Domänen und Fachbereichen), also formalen Vokabularen im Allgemeinen, dienen. Der Hauptanwendungsbereich von RDF ist das semantische Web, das eine Erweiterung des bestehenden Webs mit maschinenverarbeitbaren Inhalten darstellt. Konkrete Einsatzbereiche für RDF sind beispielsweise Content-Syndication 132 und RDF Simple Syndication (RSS), soziale Netzwerke wie Friend-of-a-Friend (FOAF) oder auch Kommentierungssysteme (wie das W3C Annotea Project) und Blogs (Web-Eintrag mit Log-File) [vgl. RDF]. RDF ist eine Grammatik zur OWL. RDF-Graphen treffen Aussagen der Form Subjekt-Prädikat-Objekt (S-P-O), dabei sind Knoten Subjekte und Objekte, Kanten die Prädikate. Somit werden Aussagen über Aussagen (engl. statements) und Relationen möglich, darin ist die Basis des Semantic Webs zu sehen [VoHe06; ETea06]. An dieser Stelle sei bereits angemerkt, dass alle Daten und Werkzeuge des Semantic Webs, wie auch die hier betrachteten XML-Schema, RDF, RDF-Schema und OWL häufig in XML kodiert sind. [Fürn05, S. 25] 131 Literale sind Buchstaben bzw. bezeichnen in Programmiersprachen Zeichenfolgen, die zur Darstellung der Werte von Basistypen zugelassen sind. 132 Content-Syndication: Der Austausch oder die Mehrfachverwendung medialer Inhalte. 127

152 Operationalisierung der WPIM-Pipeline RDF Graph Aussagen in RDF können als gerichteter Graph mit beschrifteten Kanten dargestellt werden. In einem RDF-Graphen repräsentieren die Knoten Ressourcen, und die Kanten repräsentieren benannte Eigenschaften. Knoten, die Zeichenketten repräsentieren, werden mit Rechtecken gezeichnet. [Skou02] Die Kanten drücken Beziehungen aus und können als semantische Relation oder auch Bindeglied zwischen Ressourcen und zugehörigen Werten verstanden werden. Mehrstellige Prädikate: N-stellige Relationen können auf 2-stellige Relationen zurückgeführt werden [Fürn05, S. 41]. Reifikation: Statements können ebenfalls Ressourcen sein, das heißt, man kann Statements über Statements machen, dies wird als sog. Reifikation bezeichnet [Fürn05, S. 43]. Mehr zur grafischen Notation von RDF, den RDF-Graphen und weitere Beispiele unter [Sönn04, S. 27ff., Brüg03, Skou02]. Es gibt auch einige bedeutende Werkzeuge zur Darstellung von RDF- Graphen, wie z. B. K-Infinity von Intelligent Views GmbH 133 für Business Semantics und Knowledge Portale oder SemanticWorks von Altova GmbH 134 zur Modellierung und Überführung von Ressourcenbeschreibungen in RDF-Graph und RDF/XML-Syntax mit Syntaxund Semantik-Check RDF/XML-Syntax Die XML Repräsentation des grafischen RDF-Models wird durch die Syntax-Spezifikation 135 des W3C beschrieben. Darin wird festgelegt, dass Aussagen über Ressourcen in sogenannten Description-Elementen erfolgen, wobei die Ressource selbst in ein Attribut eines solchen Elements referenziert wird, während ihre Eigenschaften als im Prinzip frei definierbare Elemente und ihre Werte als die zugehörigen Elementinhalte angegeben werden. [EcEc04, S. 241] Das weitere Beispiel zeigt die Serialisierung der WPIM-Aktivität Testphase, die unter der URI referenzierbar ist. Eine Aktivität ist in diesem Beispiel die Ressource die näher beschrieben wird. Prozesselemente werden jeweils Name, Version, Datum, Verantwortlichkeit, Kurzbeschreibung, Schlagworte, Ansprechpartner und Format angeführt. Innerhalb des Wurzelelements RDF, das immer benötigt wird, werden beide Namensräume (rdf und wpim) deklariert. Der Namensraum rdf: ist durch die RDF-Spezifikation vorgegeben. Die hier verwendeten Elemente mit dem Präfix rdf: sind innerhalb der RDF-Spezifikation beschrieben. Bei folgender Beschreibung der Aktivität Testphase sind das: RDF, Description mit Attribut about, Seq und li. Im Element RDF müssen sich die Ressourcenbeschreibungen befinden, während man mit Description die einzelnen Ressourcenbeschreibungen markieren kann. Das Attribut about gibt an, über welche Ressource Aussagen getroffen werden. Die zweite Namensraumdeklaration wpim beinhaltet eine RDF- Schema-Beschreibung mit den für diese Anwendungsdomäne definierten Elementnamen. Die Elemente Name, Version, Datum, Verantwortlich, Kurzbeschreibung, Schlagworte, Ansprechpartner und Format werden verwendet und durch das Präfix wpim: eindeutig gekennzeichnet. Das Ansprechpartner-Element enthält zwei Experten, die im Listen-Element rdf:li beschrieben werden. 133 Homepage der Intelligent Views GmbH Homepage der Altova GmbH Das World Wide Web Consortium regelt die Syntax Spezifikation von RDF

153 Operationalisierung der WPIM-Pipeline <?xml version= 1.0?> <rdf:rdf xmlns:rdf= xmlns:wpim= > <rdf:description about= > <wpim:name>testphase</wpim:name> <wpim:version>1.3</wpim:version> <wpim:datum> </wpim:datum> <wpim:verantwortlichkeit>dr. Schmied</wpim:Verantwortlichkeit> <wpim:kurzbeschreibung>hier sind die Testspezifikationen zur Absicherung des Systems ABS08 hinterlegt </wpim:kurzbeschreibung> <wpim:schlagworte>test, Testspezifikation, Klimatest</wpim:Schlagworte> <wpim:ansprechpartner> <rdf:seq> <rdf:li>herr S.Hinz</rdf:li> <rdf:li>herr D.Kunz</rdf:li> </rdf:seq> </wpim:ansprechpartner> <wpim:format>text/xml</wpim:format> </rdf:description> </rdf:rdf> Code 4.4: Beschreibung Testphase in RDF/XML-Notation Möchte man Ressourcen beschreiben, die im Web verfügbar oder zumindest über eine URI identifizierbar sind, so nimmt man das about-attribut und setzt als Wert die URI. Über diesen Mechanismus kann man (...) auch Begriffe, die schon an anderer Stelle beschrieben worden sind, aufgreifen und um weitere Beschreibungen ergänzen. [EcEc04, S. 243] URI existieren auch für reale Ressourcen, wie z. B. Bücher oder Prozessdokumentationen, die so direkt und eindeutig referenziert werden können. Sollten Sie sich an den fiktiven URI stören, so kann statt dem rfd:description about-attribut das ID-Attribut verwendet werden. Die Ressource kann dann über ihren Namen bzw. eine eindeutig festzulegende Identifikation beschrieben werden. Für die beschriebene Testphase könnte z. B. der Name bzw. die ID _Testphase_ABS08 festgelegt werden RDF-Schema, RDFS RDF-Schema (RDF-S, RDFS) ist eine Erweiterung, um Bedeutung in einem RDF-Dokument auszudrücken. Dazu bietet RDFS zusätzlich die Möglichkeit, eigene Vokabulare zu definieren und diese mittels RDF auszudrücken sowie anzuwenden [KaBM08]. Das RDF-Modell und die RDF/XML-Syntax erzeugen nur XML-Dokumente, die sich an zusätzliche Regeln bezüglich der Struktur und der Benennung von Elementen und Attributen halten müssen. Diese Dokumente können syntaktisch überprüft werden und bieten bei geschickter Wahl der Namen hilfreiche Information. Zur automatischen Weiterverarbeitung genügt dies jedoch noch nicht [http://w3c.org/tr/2000/cr-rdf-schema in EcEc04, S. 258]. RDF-Schema nutzt die Syntax von RDF/XML, ein Vergleich von RDF-Schema mit XML-Schema ist jedoch nur bedingt möglich. XML-Schema gibt syntaktische Strukturen von wohlgeformten XML-Instanzen vor. Zum einen schränkt RDF-Schema die RDF/XML-Syntax ein, zum anderen ermöglicht RDF- Schema die semantische Einordnung der verwendeten Begriffe. Die semantische Beschreibung übertrifft XML-Schema somit bei weitem [vgl. EcEc04, S. 259]. RDF-Schema wurde entwickelt, um Begriffe zueinander in Beziehung zu setzen. Wesentliche Konzepte von RDF-Schema sind Klasse-Unterklasse-Beziehungen sowie Eigenschaft-Untereigenschaft-Beziehungen. Klassen fassen einerseits, wie in der objektorientierten Modellierung, Objekte mit gleicher Eigenschaft zusammen und bestimmen andererseits Begriffe. Unterklassen sind spezielle Untermengen von Oberklassen. Entsprechendes gilt für Eigenschaft-Untereigenschaft-Beziehungen [EcEc04, S. 259]. RDF-Schema erlaubt außerdem die Bildung von Begriffshierarchien, den sog. Ontologien für die semantische Einordnung von Begriffen [EcEc04, S. 235]. RDF-Schema- 129

154 Operationalisierung der WPIM-Pipeline Dokumente müssen der RDF/XML-Syntax genügen und die Namensraumdeklaration <xmlns:rdfs= > für RDF-Schema enthalten. Charakteristisch für RDF-Schema-Dokumente sind die Typen Class und Property sowie die Eigenschaften subclassof und subpropertyof [vgl. EcEc04, S. 260 ff.], zusätzliche Kontextbetrachtungen werden in Modell RDF S-3 zum Ausdruck gebracht Web Ontology Language, OWL Web Ontology Language (OWL nicht WOL) ist eine Spezifikation des W3C zur Erstellung, Publikation und Verteilung von Ontologien anhand einer formalen Beschreibungssprache. Es geht darum, Wissen einer Domäne und dessen Relationen so zu formalisieren, dass auch (Software-) Agenten die Bedeutung verarbeiten bzw. weiterführend verstehen 136. OWL wird dadurch zum Kern des Semantic Webs der bedeutungsvollen Fortschreibung des heutigen Internets. OWL basiert technisch auf der RDF-Syntax, geht historisch aus DAML+OIL (Darpa Agent Markup Language plus Ontology Inference Layer) hervor und übersteigt die Ausdrucksmächtigkeit von RDF-Schema. Zusätzlich zu RDF und RDF-Schema werden die Sprachkonstrukte (Sprachdialekte wie OWL Lite, DL und Full) eingeführt, die es erlauben, Ausdrücke ähnlich der Prädikatenlogik 137 zu formulieren [OWL; SEMA]. Ontologien dienen zur Spezifikation von Vokabularen, ermöglichen Interoperabilität für menschliche und maschinelle Kommunikation sowie ontologiebasierte Suchen. [vgl. Bull06, S. 235] Historie und Entwurfsziele von OWL Die Web Ontology Language ist als Erweiterung von RDF-Schema zu sehen. OWL ist stark an der Sprache SHOE und DAML+OIL orientiert [vgl. Eich04, Diec03]. Die erste (für das WWW bzw. XML relevante) Sprache zur Formulierung von Ontologien war SHOE (Simple HTML Ontology Extension). Mit SHOE versuchten seine Erfinder, die Technik des semantischen Markups mithilfe von Ontologien so einfach wie möglich zu gestalten, indem sie die Anmerkungen und Ontologien direkt als HTML-Erweiterungen definierten. [vgl. Luke et al in Diek03, S. 8]. DAML ist die Kurzform für DARPA Agent Markup Language. OIL steht für Ontology Inference Layer und fügt DAML-Logik sowie Möglichkeiten für Schlussfolgerungen hinzu. Beide sind Grundlage für OWL und von der grundlegenden Struktur sehr ähnlich: eine Unterteilung in Klassen, Unterklassen, Individuen und Properties ist auch hier schon möglich. Zu den Properties ist außerdem die Definition von Restriktionen möglich, wie in OWL auch. DAML+OIL erweitert RDF mit Klassenfunktionalitäten und Eigenschaften und ist als direkter Vorgänger von OWL anzusehen, wobei der Übergang von DAML+OIL nach OWL fließend ist, d. h. OWL vereinigt die Funktionalität von DAML und OIL in einer Sprache. Die Unterscheidungen sind marginal und beschränken sich auf erweiterte Klassenbeziehungen in OWL. [Stei04, S. 5] Eckstein/Eckstein stellen acht Entwurfsziele von OWL vor, die von RDF/RDF-Schema nicht ausreichend erfüllt werden [vgl. EcEc04, S ]: Auf verteilte Ontologien (die öffentlich zugänglich sein werden) sollen sich unterschiedliche Datenquellen beziehen können. In diesem Sinne soll auch die Evolution von Ontologien unterstützt werden, da sich durch 136 Verstehen im Sinne einer Interpretation der oder Einordnung in die Begriffswelt. 137 Das charakteristische und wichtigste Sprachmittel der Prädikatenlogik ist der Quantor oder Quantifikator. Quantoren erlauben es, Aussagen darüber zu machen, auf wieviele Individuen ein Prädikat zutrifft. 130

155 Operationalisierung der WPIM-Pipeline das stetige Wachsen von Ontologien viele Änderungen ergeben werden. Insbesondere die Kompatibilität, aber auch die Inkompatibilität zu vorhergehenden Versionen soll spezifiziert werden können. Verschiedene Ontologien modellieren identische Konzepte zum Teil unterschiedlich. Für die Interoparabilität von solchen Ontologien müssen dementsprechend Konzepte zur Verfügung stehen, die dieses berücksichtigen. Häufig sind Ontologien zueinander inkonsistent, da keine kontrollierende Autorität existiert. Inkonsistenzen müssen automatisch erkannt und verarbeitet werden können. Große Ausdrucksmächtigkeit und gute Skalierbarkeit sind zwei wichtige, aber entgegengesetzte Ziele, sodass für die OWL eine gute Balance zwischen diesen gefordert wird. Für die weite Verbreitung und den tatsächlichen Einsatz des Semantic Web im großen Maß ist es essenziell, dass die OWL einfach zu nutzen ist. Die OWL soll mit anderen existierenden Entwicklungen wie XML, RDF, aber auch Modellierungsstandards wie der UML kompatibel sein. Ansonsten wäre die Benutzung und Integration im Entwicklungsprozess nur unnötig erschwert. Wie bei allen anderen Spezifikationen des W3C ist die Internationalisierung ein Basisziel. Hier sollen mehrsprachige Ontologien und möglicherweise unterschiedliche kulturelle Sichten ermöglicht werden [EcEc04, S ]. OWL (Web Ontology Language), die von der Web Ontology working group des W3C herausgegebene Sprache, ähnelt DAML+OIL sehr stark. Sie liegt in drei Sprachdialekten vor (OWL Lite, OWL DL, OWL Full), die sich in der Anzahl der Syntaxelemente unterscheiden. Das W3C gibt hier als Begründung für die Trennung an, OWL Lite vorgesehen zu haben, um einfachere Implementierungen zu unterstützen [Diec03] Sprachdialekte von OWL: Light, DL und Full Der Namensraumname für OWL lautet owl, wobei der Namensraum die URI besitzt. Das Kopfelement lautet owl:ontology, weiter können owl:versioninfo, owl:priorversion und ein owl:imports-element folgen. Einige sehr gute Tutorials zu OWL finden sich auf den Seiten des Cooperative Ontologies Programme 138. Die nachstehenden Beschreibungen der drei Sprachversionen (OWL Light, DL und Full) können nachgelesen werden im OWL Web Ontology Language Guide von [Sema06]: OWL Lite unterstützt jene User, die in erster Linie eine Klassifikationshierarchie und lediglich einfache Beschränkungsmöglichkeiten benötigen. Zum Beispiel unterstützt OWL Lite zwar Kardinalitätsschranken, aber nur für die Werte 0 oder 1. Es dürfte einfacher sein, Werkzeuge (und einen schnellen Migrationspfad für Thesauri und andere Taxonomien) für OWL Lite als für seine ausdrucksstärkeren Verwandten bereitzustellen. [Sema06] Der Name OWL DL rührt von der Entsprechung zur description logic [EcEc04, S. 275] her. In OWL DL sind alle Konstrukte der Sprache enthalten. Bei der Benutzung dieser Konstrukte müssen aber teilweise Beschränkungen eingehalten werden. Es wird die maximale Ausdrucksmöglichkeit zur Verfügung gestellt, die unter der Vorgabe möglich ist, dass die Berechnungen von Reasonern vollständig und entscheidbar sein sollen. Der Hauptunterschied zu OWL Lite ist, dass OWL DL mehr Möglichkeiten zur Beschränkung von Eigenschaften zur Verfügung stellt. Für die Benutzer sollte sich die Beantwortung der Frage, welche der beiden Versionen zu verwenden ist, danach richten, ob ihnen die Möglichkeiten von OWL Lite zur Beschränkung von Eigenschaften genügen. OWL DL ist eine Teilmenge von OWL Full. Jede 138 CO-ODE: 131

156 Operationalisierung der WPIM-Pipeline gültige OWL DL Ontologie ist eine gültige OWL Full Ontologie. [Eich04, S. 23] OWL Full ist für jene User, die maximale Ausdrucksstärke und die syntaktische Freiheit von RDF möchten, allerdings gibt es dafür keine Garantien hinsichtlich logischer Auswertbarkeit. Beispielsweise kann in OWL Full eine Klasse gleichzeitig als eine Sammlung von Individuals und für sich selbst als ein Individual behandelt werden. Ein weiterer signifikanter Unterschied zu OWL DL ist darin zu sehen, dass ein owl:datatypeproperty als owl:inversefunctionalproperty markiert werden kann. OWL Full erlaubt einer Ontologie, die Bedeutung der vordefinierten (RDF oder OWL) Vokabulare zu erweitern. Es ist nicht zu erwarten, dass eine schlußfolgernde Software jedes Feature von OWL Full unterstützen kann. [Sema06] Die Entscheidbarkeit ist nicht zwingend gegeben Semantic Web: Risiken und Ausblick Als zentrale Herausforderung im Semantic Web wird der Umgang mit widersprüchlichen Aussagen gesehen. Im Semantic Web können zwei oder mehrere Aussagen z. B. in Tripel-Form S-P-O auftreten die widersprüchlich sind. Welcher Aussage bzw. welcher Quelle ist dann mehr Vertrauen zu schenken? Was geschieht mit veralteten Aussagen, die aber nach wie vor im Web verfügbar sind, z. B. ein Experte hat die Verantwortung für einen neuen Bereich übernommen, ein Kollege hat den Bereich gewechselt und seine Kontaktdaten geändert. Solange die veralteten semantischen Beschreibungen zu den Experten noch parallel verfügbar sind, führt dies unweigerlich zu Widersprüchen oder Doppelauskünften. Die Suche nach einer Rolle, z. B. dem Vorstand würde alle Vorstände der Historie als Treffer zurückliefern. Die Qualität der Aussagen leidet, die Vertrauenswürdigkeit sinkt. Eine Versionierung von Tripel-Aussagen durch Zeitstempel kann dabei unterstützen, Eindeutigkeit zu schaffen. Dazu wird z. B. zu einer Rolle wie dem Vorstand im Unternehmen hinterlegt, welche Person diese Rolle von wann bis wann inne hatte. Durch SPARQL-Queries kann dann gezielt über die Suche nach Rolle und Datum eindeutig herausgefunden werden, welche Person zu einem Zeitpunkt für Entscheidungen verantwortlich zeichnet. Das Web 3.0 (auch Web-of-Trust genannt), wird stärkere Auswirkungen und Bindung an bzw. auf die Realität haben. [vgl. Bade04, S. 57] Künftig können soziale Netzwerke genutzt werden, um die reale Existenz von Personen zu verifizieren. Wer in ein soziales Netz eingebunden ist und mit einigen Dutzend Personen, die wiederum virtuell vernetzt sind, verbunden ist, hat eine Vertrauensbasis geschaffen und somit einen guten Anhaltspunkt hinterlassen, tatsächlich real existent zu sein. Denkbar ist, dass zukünftig ein Nutzerprofil aus einem sozialen Netzwerk als Log-On-Schlüssel bei Web-Diensten wie Flugund Reisediensten oder auch zum Online-Banking genutzt werden kann. Soziale Netzwerke in Verbindung mit dem Semantic Web haben somit das Potenzial zum Ausgangspunkt für das Webof-Trust zu werden Vokabulare und bei WPIM verwendete Basisvokabulare Vorgestellt werden Vokabulare zur Beschreibung von Ressourcen. Bei WPIM finden insbesondere der Dublin Core zur Beschreibung von Dokumenten sowie Friend-of-a-Friend zur Annotation von Experten Einsatz. Diese beiden Vokabulare werden zu den zentralen Vokabularen gezählt und als Basisvokabulare bezeichnet. Da zur Beschreibung und Annotation von Prozessen kein geeignetes Vokabular identifiziert werden konnte, wurde ein eigenes Vokabular, das sog. WPIM-Vokabular entwickelt. Das WPIM-Vokabular erweitert zudem die bestehenden Ansätze zur Annotation von Ressourcen. Bei der Entwicklung des WPIM- Vokabulars wurde auf Kompatibilität zu RDF, OWL-DL sowie den Dublin Core und Friend-ofa-Friend geachtet. 132

157 Operationalisierung der WPIM-Pipeline SKOS für maschinenverarbeitbare Thesauri Der Simple Knowledge Organisation System Core (SKOS) dient der Erstellung von maschinenverarbeitbaren Thesauri [SKOS05]. Baker und Fischer fassen zusammen: Wo der Dublin Core sich für die Beschreibung dokumentähnlicher Objekte eignet, eignet sich der SKOS Core für die Beschreibung von abstrakten Begriffskonstruktionen wie Thesauri und Klassifikationssystemen. Wie auch Dublin Core beruht der SKOS Core auf einer gemeinsamen Meta-Datengrammatik und stellt dabei einen kleinen Satz allgemein gültiger Kernbegriffe in den Mittelpunkt. [BaFi05] Der SKOS Core wurde in enger Kooperation zwischen Teilnehmern der Semantic-Web-Arbeitsgruppe beim W3C und Experten in der Thesauruskonstruktion entwickelt. Anlass dieser Zusammenarbeit war die Erkenntnis, dass sich existierende Thesauri nicht ohne weitere Interpretation und Nachbearbeitung in die neuen, streng logischen Sprachen der Ontologien (wie z. B. OWL, die Web Ontology Language) übersetzen lassen. Würde man zum Beispiel in einem herkömmlichen Thesaurus die semantische Beziehung zwischen einem engeren Begriff und einem weiteren Begriff in OWL als sub-class bezeichnen, dann würde man der Begriffsbeziehung eine logische Genauigkeit zuschreiben, die mit den losen Begriffen enger und weiter vielleicht nicht gemeint ist. Indem er die Begriffe enger (engl. narrower) und weiter (engl. broader) direkt übernimmt, ist der SKOS Core also gut dafür geeignet, herkömmliche Thesauri mit all ihren gemeinten und letztlich auch hilfreichen Ungenauigkeiten sinngetreu in Semantic Web-fähiger Form abzubilden. [BaFi05] Im DCMI- Zusammenhang bietet sich der SKOS Core an, kontrollierte Vokabulare für die Nutzung mit dem Dublin-Core-Element Subject zu definieren Dublin Core als Basisvokabular für WPIM Der Dublin Core 139 (DC) ist Basisvokabular bei WPIM und zählt zu den bekanntesten Standards unter den Entwicklungen von Meta-Daten [Dubl06; DCES06; DCES06a; BaFi05]. Durch die Dublin Core Metadata Initiative 140 (DCMI) in Dublin, Ohio initiiert, wurde diese Metadaten- Initiative nach dem Ort seiner Entstehung benannt. Der DC ist als interoperabler domänenunabhängiger Metadaten-Standard bzw. als Metadaten-Vokabular zu sehen. [Dubl06] Er soll es intelligenten Suchmaschinen (die sich derzeit parallel in Entstehung befinden) ermöglichen, mit Metadaten beschriebene Ressourcen in grundlegende domänenunabhängige Strukturen einzugliedern und die Entstehung von domänenspezifischen Metadaten-Mengen weiterführend zu unterstützen wichtig ist dabei, die domänenspezifischen Entwicklungen sollen konsistent in die allgemeinen Entwicklungen integrierbar sein und diese sinnvoll erweitern. Da das Dublin Core Element Set (DCES) eindeutige URIs für die wichtigsten Meta- Datentypen bereitstellt, ist die Information der so ausgezeichneten Ressourcen auch für Computerprogramme als Metadaten identifizierbar und entsprechend interpretierbar, also z. B. ein Autor als ebensolcher [DCES06; DCES06a]. Der DC definiert eine Vielzahl an Kernelementen, das sog. Dublin Core Metadata Element Set (DCMES), anhand dieses Sets sollen speziell Dokumente und Datenquellen beschrieben werden. So steht eine grundlegende Menge an Metadaten zur Verfügung. Zusätzlich werden Verfeinerungen zu einigen dieser Kernelemente angeboten. Neben dem Kernelement dc:creator (zur Beschreibung des Erstellers einer Ressource) existiert u. a. auch ein Element dc:author. Somit kann explizit verdeutlicht werden, dass der dc:creator zugleich der dc:autor des zu beschreibenden Dokuments ist [vgl. EcEc04, S. 286]. 139 Dublin Core: Standardisiertes Set von Konventionen zur Beschreibung von Dokumenten und anderen Objekten im Internet. Ziel ist, diese Objekte mithilfe von Metadaten einfacher auffindbar zu machen. Urheber des Schemas ist die Dublin Core Metadata Initiative (DCMI) Dublin Core Metadata Initiative

158 Operationalisierung der WPIM-Pipeline Abb. 4.2: Attribute für Dokumente aus dem Dublin Core aus [VoHe07] Durch Verfeinerungen gemeinsam mit den Kodierungsschemata zu einigen Eigenschaften erhält man den qualifizierten Dublin Core (engl. Dublin Core Qualifiers). Die Kodierungsschemata dienen der semantischen Ordnung von Eigenschaften oder der Einschränkung von Werten der Eigenschaften [Dubl06]. Ausgehend von der vermeintlich simplen Aufgabe, Webseiten auf einfache Art zu beschreiben, hat sich ab 1997 in gegenseitiger Beeinflussung mit der sich entwickelnden Webtechnik von HTML bis hin zu XML und RDF ein allgemeines Modell für Metadaten herauskristallisiert. Es hat eine gemeinsame Wurzel mit dem Modell des Semantic Web beim W3C und teilt dessen Grundstruktur, bleibt jedoch absichtlich einfacher als die voll entwickelten Ontologiesprachen des letzteren. [BaFi05] FOAF als Basisvokabular für WPIM Das Friend-of-a-Friend (FOAF) Projekt 141 entstand im Rahmen der Semantic Web Initiative des World Wide Web Consortiums (W3C). Ziel dabei ist es, maschineninterpretierbare Webseiten zu erstellen, die Personen, ihre Tätigkeiten und Interessen darlegen und darüber hinaus virtuelle Beziehungen zwischen Personen beschreiben. Zur Beschreibung der Experten wird ein Vokabular eingesetzt, das sog. FOAF-Vokabular. Das FOAF-Vokabular erlaubt es, konkrete Angaben über die eigene Person (Alter, Namen, etc.) und über Bekanntschafts- Verhältnisse zu anderen Personen zu treffen. Eine Referenz auf eine bekannte Person wird mit einem URI auf die FOAF-Datei dieser Person gelöst [vgl. Foaf06]. Die FOAF-a-Matic ist eine webbasierte Anwendung zur Beschreibung von Personen mit dem FOAF-Vokabular, erstellt von Dodds, deutsche Übersetzung von Höke 142. FOAF-a-Matic wird als schneller und einfacher Weg angeboten, eine FOAF-Beschreibung zu erstellen und sich somit selbst zu beschreiben. [Dodd06] Dazu ist online das FOAF-Formular 143 auszufüllen und Details anzugeben, welche zur Beschreibung der eigenen Person dienen bzw. offengelegt werden sollen. 141 FOAF-Projekt - - und für die FOAF-Spezifikation Übersetzung zur FOAF-a-Matic FOAF-a-Matic

159 Operationalisierung der WPIM-Pipeline Abb. 4.3: FOAF-Formular als Eingabemaske der FOAF-a-Matic Bei der FOAF-a-Matic werden über Eingabemasken personenbezogene Daten eingegeben. Personen werden eindeutig über -Adressen identifiziert. Durch foaf:knows können zudem Relationen zu Freundschaften ausgedrückt werden. FOAF stellt einen Baustein bereit, der die semantische Verknüpfung von Freundschafts-Beziehungen sicherstellt. FOAF ist auf Freundschaftsnetzwerke ausgelegt und nicht explizit auf Expertennetzwerke der Industrie oder zwischen Organisationen. KLASSE:Person FOAF:knows KLASSE:Person Code 4.5: Zwei Personen-Klassen werden durch die FOAF-Relation foaf:knows verbunden Interessant für WPIM ist der Aufbau von semantische Beziehungen zwischen Personen (bei WPIM speziell Experten) und darüber hinaus die semantische Verknüpfungen von Konzepten wie Personen dieser Instanzen der KLASSE:Person. FOAF dient als vorbildliche Umsetzung einer FOAF:kennen-Verknüpfung (engl. FOAF:knows) zwischen Personen diese wird als semantische Relation zwischen in FOAF repräsentierten Profildaten von Personen realisiert. Abschließend, über den Button FOAF mich! (engl. FOAF me!) kann der Anwender eine semantische Beschreibung seiner Person mit dem FOAF-Vokabular erstellen. Diese Formalisierung kann z. B. in die persönliche Internetseite integriert werden und dort einen semantischen Mehrwert stiften. Die aktuelle Spezifikation des FOAF-Vokabulars von Brickley und Miller ist bei [BrMi06] und unter [http://xmlns.com/foaf/0.1/] zu finden. RDF eröffnet in diesem Zusammenhang den Vorteil, dass sich mit Hilfe von Namensräumen weitere Vokabulare zur Beschreibung von Personen einbinden lassen. [Heid04, S. 43] Da zur semantischen Beschreibung von Prozessen kein geeignetes Vokabular identifiziert werden kann, wird ein eigenes Vokabular, das sog. WPIM-Vokabular entwickelt Entwicklung des WPIM-Vokabulars Für die WPIM-Pipeline [vgl. Kap. 4.11] wird ein eigenes WPIM-Vokabular entwickelt. Das WPIM-Vokabular ermöglicht es, einzelne Klassen (im Sinne der Ontologie) und Typen (im Sinne des Datenmodells) eindeutig beschreiben und referenzieren zu können. Hierzu muss eine eindeutige URI-Referenz (URI-Ref.) festgelegt werden. Entscheidend ist, dass einzelne URI- 135

160 Operationalisierung der WPIM-Pipeline Referenzen auch bei WPIM auf dem Gedanken der Einzigartigkeit beruhen. Dazu kann eine fiktive Internetadresse angesetzt werden. Sollen allerdings die Inhalte und Referenzen kontrollierbar sein, so ist, wie geschehen, eine eigene Internetadresse zu nutzen. Unter [http://www.inknowvation.de/wpimvokabular] ist u. a. folgende URI-Referenz #Process abrufbar bzw. referenzierbar über: Abb. 4.4: Screenshot der WPIM-Homepage mit dem WPIM-Vokabular Das WPIM-Vokabular ist abrufbar unter [http://www.inknowvation.de/wpimvokabular 144 ]. Die Definition des WPIM-Vokabulars, genauer zu einzelnen Vokabeln, über eine Internetpräsenz erscheint im Sinne der Eindeutigkeit von Referenzen sinnvoll, da die Inhalte kontrolliert und dokumentiert werden können. Die Beschreibung der Vokabeln sowie deren Veränderung unterliegen ausschließlich dem Inhaber der Seite. Das Vokabular beschreibt Ressourcen und Relationen, ist an RDF/RDFS orientiert und ergänzt diesen semantischen Ansatz. Das WPIM-Vokabular wurde in dieser Arbeit spezifiziert und in der WPIM-Anwendung umgesetzt. Die Attribute zu Prozesselementen, Dokumenten und Personen/Experten werden in [Küsg11] in tabellarischen Übersichten vorgestellt. [Tab. 4.1] stellt einen Ausschnitt aus dem WPIM-Vokabular und listet Attribute zur Beschreibung von Prozesselemente wie Aktivitäten und Pools. Eigenschaft Kardinalität Wertebereich Kommentar RDF-Eigenschaft Abteilung 0,1 Text wpim:department Ansprechpartner 0,1 [alle Mitarbeiter] wpim:contact Anweisung 0,* Text wpim:instruction Ausgabedokumente 0,* [alle Dokumente] wpim: inputdocuments BenutztInProzess 1,1 Prozess Verweist auf den Prozess, in dem das Prozesselement ursprünglich verwendet wpim:usedinprocess 144 Auf der Seite - - sind zudem zu dieser Arbeit gehörige Konferenzbeiträge, Präsentationen und Veröffentlichungen abrufbar. 136

161 Operationalisierung der WPIM-Pipeline wurde (relevant für den Baukasten). Beschreibung 0,1 Text wpim:description Erstellungsdatum 0,1 Datum wpim:created Dauer 0,1 Zahl Dauer der Aktivität. wpim:duration Details 0,1 Text wpim:details Ende 0,1 Datum Ende des wpim:start Prozessschritts. Eingabedokumente 0,* [alle Dokumente] wpim: inputdocuments Links 0,* Link Weiterführende Links wpim:links zur jw. Aktivität. LessonLearned 0,* Text wpim:lessonlearned Nachfolger 0,* [alle Verweis auf die wpim:successor Prozesselemente] nachfolgende Aktivität. Schlagworte 0,* Text wpim:keywords Start 0,1 Datum Beginn des wpim:start Prozessschritts. Titel 1,1 Text rdfs:label Verantwortlicher 0,1 [alle Mitarbeiter] wpim: responsperson Version 1,1 Zahl wpim:version Vertreter 0,1 [alle Mitarbeiter] Aufgabenbezogener Vertreter des wpim:agent Vorgänger 0,* [alle Prozesselemente] Verantwortlichen. Verweis auf vorhergehende Aktivität. wpim:predecessor Tab. 4.1: WPIM-Vokabular: Attribute und Beschreibung von Elementen [Küsg11, S. 23] Diese Attribute werden durch die WPIM-Anwendung den Modellierungselementtypen Task, Pool, Process und Gateway zugeordnet, die somit den Definitionsbereich der Attribute bilden. Die konkreten Typen können zusätzliche spezifische Eigenschaften besitzen, diese Eigenschaften sind jedoch in diesem Prototyp noch nicht festgelegt. [vgl. Küsg11, S. 23 ff.] Das WPIM-Vokabular ist nicht starr und kann bei Bedarf flexibel erweitert werden. Das Vokabular findet in der WPIM-Pipeline einen ersten Einsatz, wird dort erprobt und erweitert. Auch die WPIM-Anwendung bedient sich der im WPIM-Vokabular definierten Klassen und Relationen DC, PICS, CC/PP und FOAF ein Ausblick Die meist beachteten Vertreter sind der Dublin Core und die Platform for Internet Content Selection (PICS). Der DC definiert 15 Elemente zur Erschließung von Publikationen in digitalen Bibliotheken, während PICS versucht, die Basis für Filterregeln von Webinhalten zur Verfügung zu stellen. So lassen sich unerwünschte Seiten im Vornherein ausblenden, um es zum Beispiel Eltern zu ermöglichen, jugendgefährdend bewertetes Material für ihre Kinder zu sperren [Erba02, S. 30]. Für diese Arbeit nicht relevant aber kurz zu erwähnen, ist das Metadatenformat CC/PP Composite Capability/Preference Profiles. Dieses richtet sich an mobile Endgeräte wie Personal Digital Assistants (PDAs) und ist spezifiziert unter [KlRe04]. Diese mobilen Klienten bzw. Endgeräte sind in ihren Möglichkeiten beschränkt, wie z. B. Displaygröße und Leistungsfähigkeit. Das CC/PP möchte diese Fähigkeiten beschreiben aber auch benutzungsspezifische Präferenzen berücksichtigen. [EcEc04, S. 291] Ziel ist es, mobile Web- Endgeräte mit maßgeschneiderten Inhalten (engl. tailored content) [StNM in EcEc04] zu versorgen. 137

162 Operationalisierung der WPIM-Pipeline CC/PP uses a common vocabulary and structure, defined in terms of RDF classes, to distinguish different elements of a profile, so that a schema-aware RDF processor can handle CC/PP profiles embedded in other XML document types. Being based on RDF, CC/PP has at its core, a standard-based, general purpose meta-data description language and a framework which supports vocabulary extensibility and interoperability. In CC/PP a profile refers to the documents exchanged between devices that describe the capabilities of a device. Defines the important information which is used to guide the adaptation of content presented to that device. [StNM, S. 5 in EcEc04]. Der Begriff, der den Zusammenhang beschreibt, ist Ubiquitous Computing verwendet. Ubiquitous Computing bedeutet so viel wie allgegenwärtiges Rechnen und meint, die feste Eingliederung von mobilen Geräten in den Alltag und die Kommunikation untereinander über diese Geräte. [Stei05, S. 12] Für FOAF und sog. FOAF-Nauten schlägt Heider weitere Einsatzgebiete vor [vgl. Heid04]: Die Registrierung auf Webseiten kann stark vereinfacht und zeitlich verkürzt werden, indem nur noch eine Referenz auf das eigene FOAF-File angegeben wird und somit das Ausfüllen von Formularen entfällt [Heid04]. Es gibt bereits eine große Zahl an sozialen Netzwerken im Web, wie z. B. [www.asmallworld.net] oder [www.openbc.de]. Diese funktionieren aber nach dem Prinzip der realen persönlichen Kontakte und manuellen Verlinkung. Sollte es zukünftig Werkzeuge geben, die automatisch soziale Netzwerke erzeugen und Personen mit z. B. gleichen Interessen und aus der unmittelbaren Umgebung einander vorstellen [Heid04]? Auch Spam-Filter sind denkbar, die s von bekannten Personen eben nicht versehentlich als Spam deklarieren [Heid04]. In Bezug auf WPIM und den produktiven Einsatz in fertigenden Industrien sehen wir einen entscheidenden Vorteil darin, dass innovative Unternehmen über FOAF-Files ein Netzwerk zu ihren ehemaligen Mitarbeitern und Experten aufbauen und langfristig nutzen können. Beispielsweise in komplexen Entscheidungssituationen können ehemalige Mitarbeiter als Berater fungieren. Dadurch entsteht ein potenzieller finanzieller Anreiz, der diese (ehemaligen) Mitarbeiter motivieren kann, ein persönliches (semantisches) FOAF-Profil im Ehemaligen- oder im Firmen-Netzwerk anzulegen. Dies gelingt in ähnlicher Form bereits erfolgreich in bisher nicht semantischen Netzwerken Auswahl der Technologien und Vokabulare Für die WPIM-Pipeline sind geeignete Technologien und Vokabulare zu wählen. Diese werden prototypisch in der WPIM-Pipeline eingesetzt und bei der implementierung der WPIM- Anwendung verwendet. Bei den Analysen fiel aufn, dass das W3C kein spezielles Vokabular zur Beschreibung von Prozessen vorhält. Ein derartiges Vokabular konnte derzeit nicht identifiziert werden. Die Arbeiten des W3C sind vornehmlich auf Ressourcen des WWW bzw. des Web 2.0 ausgerichtet. Vokabulare zum Prozessmanagement, Wissensmanagement und Innovationsmanagement wie diese von Unternehmen der fertigenden Industrien eingesetzt werden, liegen bisher nicht vor. Als Basistechnologie zur semantischen Annotation von Ressourcen speziell für Prozesse, Experten und Dokumente ist die Entscheidung auf RDF gefallen. RDF stellt in der entstehenden WPIM-Pipeline eine größtmögliche Skalierbarkeit, Austauschbarkeit und Wiederverwertbarkeit sicher. 138

163 Operationalisierung der WPIM-Pipeline The Resource Description Framework, or RDF, enables data to be decentralized and distributed. RDF models can be merged together easily, and serialized RDF can be simply exchanged over HTTP 145. Zur Beschreibung von Experten wird in der WPIM-Pipeline zudem das FOAF-Vokabular verwandt, das auf RDF basiert, mit diesem vollständig integrierbar ist und speziell auf die Bedürfnisse der Beschreibung von Personen insbes. Experten mit Kontaktdaten, Kompetenzen sowie deren Arbeits- und Projektsituationen ausgerichtet sind. Der Dublin Core wird in der WPIM-Pipeline eingesetzt, um Ressourcen wie Dokumente zu beschreiben. Neben den beiden bestehenden Vokabularen FOAF und DC entwickeln wir ein eigenes WPIM-Vokabular zur Beschreibung von Prozessen in der WPIM-Pipeline [vgl. Kap. 4.11]. Zur Entwicklung der Ontologien für Prozesse und Ressourcen (Experten und Dokumenten) setzen wir RDF/RDF(S). Sofern benötigt greifen wir auf OWL DL zurück. Ausschlaggebend ist, das sowohl RDF/RDF(S) und OWL DL vollständige Entscheidbarkeit gewährleistet. Dieser Aspekt ist für die angestrebte semantische Suche (z. B. Schlussfolgerungen, engl. reasoning oder Inferenz bzw. semantische Abfragen) in der WPIM-Pipeline und in der webbasierten WPIM-Anwendung essenziell. 4.3 Semantische Suche In der WPIM-Pipeline sollen semantische Suchen über den semantisch repräsentierten Daten erfolgen. Die semantische Suche ist der Oberbegriff zum Durchsuchen und Auffinden von Wissen auf der Basis semantischer Technologien. Zum einen werden unter semantischen Suchen konkrete Anfragen an Datenspeicher verstanden, die ähnlich wie Structured Query Language 146 (SQL)-Anfragen aufgebaut sind. Zum Anderen werden unter semantischen Suchen Inferenz- Mechanismen eingeordnet. Der Ausdruck semantische Suche wird im Folgenden im Sinne des Schlussfolgerns (engl. inference, reasoning) verwendet. Beim Schlussfolgern können Ergebnismengen zurückgegeben werden, die für menschliche Betrachter gut nachvollziehbar sind. Durchaus sind aber auch Ergebnismengen denkbar, die nicht explizit im Datenspeicher hinterlegt sind und maschinell abgeleitet wurden. Es folgt eine Betrachtung zu RDF- und OWL- Abfragesprachen die sodann in der WPIM-Pipeline [vgl. Kap. 4.11] prototypisch implementiert werden RDF- und OWL-Abfragesprachen Es gibt eine Vielzahl verschiedener RDF-Abfragesprachen. Im Folgenden werden die geläufigsten in einer Übersicht nach [Bade04, S. 14 ff.] vorgestellt. Zudem gibt es eine Übersicht zu RDF-Abfragesprachen (engl. RDF Query Languages) unter [http://www.aifb.unikarlsruhe.de/wbs/pha/rdf-query/], von dort entstammt die nachstehende Abbildung und dort sind auch online Demonstratoren verfügbar, welche Ergebnisse der Abfragen zurückgeben. Im Folgenden werden einige ausgewählte Abfragesprachen beleuchtet:

164 Operationalisierung der WPIM-Pipeline Abb. 4.5: Eine Übersicht und Vergleich von Abfragesprachen RDF Query, RDFQ Um mit RDF Query (RDFQ) eine Abfrage durchzuführen, ist zuerst eine Anfrage in RDF notwendig. Diese Anfrage entspricht einem RDF-Template, welches mit vorhandenen RDF- Graphen und Subgraphen verglichen wird, um übereinstimmende Teile zurück zu gegeben. Der RDF-Graph kann entweder in XML oder in Turtle geschrieben sein. RDFQ wird bei Nokia produktiv eingesetzt. [Bade04] RDF Query Language, RQL RQL basiert auf OQL und ist eine Abfragesprache mit vielen vordefinierten Funktionen. So ist zum Beispiel die Abfrage von Unterklassen mit der Funktion subclassof() möglich. Die Funktion subclassof() kann ohne logische Schlussfolgerungen (Reasoning) ausgeführt werden, da nur die direkten Unterklassen durchsucht werden. [BrKH05, S. 204] Möchte man nach allen Unterklassen suchen, also auch Unterklassen von Unterklassen, muss das Zeichen ˆ verwendet werden, um die Funktion zu transitivieren. Eine transitive Funktion kann nicht mehr ohne logische Schlussfolgerungen ausgeführt werden, da die gesuchten Relationen nicht direkt vorhanden sind. Ein Beispiel für eine transitive Funktion in RQL ist subclassofˆ(). RQL unterstützt noch eine weitere Kategorie von Funktionen, welche parameterlose Anfragen an den RDF Baum zulassen wie topclass oder leafclass. RQL ist eine umfassende und somit nicht ohne Vorkenntnisse verwendbare Abfragesprache. [vgl. Bade04] RDQL Diese Sprache ähnelt von der Syntax her SQL, da sie auch SELECT-FROM-WHERE- Konstrukte besitzt. Transivitivität wird jedoch nicht explizit unterstützt, sie muss von Hand in das Query einbezogen werden. RQL macht keine Unterschiede zwischen berechneten Tripel und Basis-Tripel. Prominente Anwendung findet RDQL im Jena Framework SPARQL Für RDF- und OWL-Konstrukte wurde die Anfragesprache SPARQL Protocol and RDF Query Language (SPARQL) entwickelt. Das SPARQL-Protokoll unterstützt somit die RDF Query Language. Mit SPARQL lassen sich Abfragen für in RDF spezifizierte Information erstellen und die Darstellung der Resultate konstruieren. SPARQL basiert auf einfachen RDF-Anfragen die als Graph-Muster zu verstehen sind. Diese RDF-Anfragen oder auch Graph-Muster werden in der Turtle-Syntax 148 angegeben. [Hitz08] Jena ist ein Java Framework zur Erstellung von Semantic-Web-Anwendungen und stellt eine programmierbare Entwicklungsumgebung für RDF, RDFS und OWL, SPARQL und zudem eine regelbasierte Inferenzmaschine. 148 Turtle-Syntax, vgl. Hitzler, P. et al., Semantic Web, Aufl. 1 Heidelberg 2008, S

165 Operationalisierung der WPIM-Pipeline Beschreibung der SPARQL-Schlüsselwörter: PREFIX SELECT WHERE deklariert den benutzen Namensraum. bestimmt allgemein das Ausgabeformat und den Rückgabewert anhand der Variablen. hier wird die eigentliche Datenbasis zur Verfügung gestellt, in der gesucht werden soll. Dies wird in der Triple-Notation bzw. als Graph-Muster durchgeführt [Hitz08 in Woll10]. Entwickelt durch die RDF Data Access Working Group (DAWG) des W3C, aufbauend auf ARQ A SPARQL Processor for Jena. Dazu ist eine Online-Demo 149 verfügbar. Die Spezifikation der SPARQL Query Language für RDF stellt das W3C 150 bereit und gibt zudem reichliche Beispiele zur wohlgeformten Verwendung dieser Abfragesprache die stark an SOL angelehnt ist. SPARQL-Anfragewerkzeuge (engl. query tools) Die SPARQL-Spezifikation existiert nicht isoliert, es gibt eine Reihe von Werkzeugen und APIs, welche die SPARQL-Funktionalität unterstützen. Anbei folgt eine Auswahl der Werkzeuge, die die aktuelle Spezifikation unterstützen: ARQ, ein SPARQL-Prozessor für Jena, Rasqal, die RDF Query Library und dem Comprehensive Redland Framework RDF::Query von David Beckett 151, twinql, ein SPARQL Prozessor für Lisp, Pellet, Open Source OWL DL Reasoner in Java unterstützt teilweise SPARQL Query, KAON2, ein weiterer OWL DL Reasoner mit Teilunterstützung von SPARQL, Twinkle, ein SPARQL Query Tool Twinkle mit GUI Interface zur ARQ Library, unterstützt viele Output-Formate sowie das Editieren, laden und Speichern von Queries. Vorgestellt durch Leigh Dodds in Introducing SPARQL 152 mit sehr vielen Beispielen. Auch Protégé unterstützt SPARQL, siehe hierzu [Abb. 4.64: Komplexe SPARQL-Anfrage in Protégé] es stehen Plug-ins zur Integration von SPARQL-Abfragen sowie zur Visualisierung der Ergebnisse der Abfragen z. B. als RDF-Graph zur Verfügung Process Query Language, PQL PQL ist eine Abfragesprache, die spezialisiert auf Prozesse ist. Badertscher sieht darin einen grundsätzlichen Unterschied zu den weiteren hier angesprochenen Abfragesprachen, da PQL als Datenbasis beispielsweise Prozessontologien verwendet. Als bekanntes Beispiel nennt er das Prozess-Handbuch des MIT. Darin werden Prozesse nach einem fest definierten Schema beschrieben. So besitzt ein Prozess Resources, Ports, Exceptions, Subtasks und weitere Attribute. In PQL kann dann nach diesen fest definierten Relationen gesucht werden [Bade04]. Durch die stringente Vorgabe von Schema für Prozesse leidet aus Sicht der Autoren die Flexibilität bei der Prozessmodellierung. Inwieweit PQL für schema-freie Prozesse noch geeignet ist, muss an anderer Stelle geklärt werden This is a demonstration of using Rasqal to perform queries in either of the RDQL or SPARQL languages over RDF data. The data is loaded into a Redland model and then queried and results accessed via the Redland Perl language binding. 152 Introducing SPARQL: Querying the Semantic Web, von Leigh Dodds abgerufen am

166 Operationalisierung der WPIM-Pipeline OWL-QL Die OWL-Abfragesprache ist eine Weiterentwicklung der Sprache DQL (DAML Query Language). Sie hat zum Ziel, eine generische Abfragesprache für das Semantic Web zu sein. OWL-QL ist ebenso ein Protokoll, welches die Kommunikation zwischen dem Webserver und dem Klient auf höchster Ebene beschreibt. Dies ist eine Besonderheit unter den Abfragesprachen und wird benötigt, um Anfrage-Antwort-Dialoge zu realisieren. So kann in OWL-QL der Klient beispielsweise die maximal gewünschte Anzahl an Resultaten angeben und danach weitere Resultate anfordern oder die Suche abbrechen. [Bade04, S. 14] DL Query zur kontextspezifische Suche nach Patenten WPIM unterstützt durch geeignete Suchen beim Auffinden von Dokumenten (z. B. Patenten) nach vorgegebenen Suchkriterien in einem spezifischen Innovations- bzw. Prozesskontext. Konkret soll nach einem Dokument, genauer einem Patent mit vorgegebenem Suchtext (z. B. Name, Autoren, Patentnummer oder Erstellungsdatum etc.) gesucht werden. Die Patentsuche erfolgt in einem spezifischen Kontext, hier innerhalb einer Aktivität. Neben dem Patentnamen wird der Name des Autors angegeben, um die Suche noch weiter einzugrenzen und um möglichst wenige, dafür aber exakte Treffer zu erreichen. Hierzu wird eine zusammengesetzte DL Query Abfrage angewendet. Dies stellt ein reales Szenario dar und kann somit als Anwendungsfall (engl. use case) angesehen werden. Im Folgenden werden die grundlegenden Konzepte zur Patentsuche vorgestellt und in OWL überführt. Object Property [Domain; Range]: hatautor[patent; Autor] zugeordnet[patent; Aktivität] Datatype Property [Domain] hatnummer[integer] Code 4.6: Konzepte zu Object Property und Datatype Property Die Konzepte hier ausgelegt für OWL können in OWL implementiert und instanziiert werden. <owl:objectproperty rdf:about="#hatautor"> <rdfs:range rdf:resource="#autor"/> <rdfs:domain rdf:resource="#patent"/> </owl:objectproperty> <owl:objectproperty rdf:about="#zugeordnet"> <rdfs:range rdf:resource="#aktivität"/> <rdfs:domain rdf:resource="#patent"/> </owl:objectproperty> <owl:datatypeproperty rdf:about="#hatnummer"> <rdfs:domain rdf:resource="#patent"/> </owl:datatypeproperty> Code 4.7: Object und Datatype Property in OWL Die Abfragesprache DL Query und das DL Query Tab werden als Protégé Plug-in angeboten. Die Abfrage als DL Query und in Tripel-Notation lautet: Zugeordnet value Aktivität_B and hatnummer value "123" and hatautor value Tobias_Vogel In [Abb. 4.6] ist die instanziierte Ontologie dargestellt, die mit der DL Query durchsucht werden soll. Die beschriebene Informationsflut wird durch gezielte Vorgaben des Kontexts in Form von Attributen, z. B. hatnummer und hatautor belegt, mit konkreten Werten reduziert bzw. eingegrenzt. 142

167 Operationalisierung der WPIM-Pipeline Abb. 4.6: Modellierte und instanziierte Ontologie in Protégé In [Abb. 4.7] ist nochmals die DL Query im Protégé Plug-in DL QueryTab sowie das erzielte Ergebnis der semantischen Suche dargestellt. Abb. 4.7: DL-Query-Abfrage und das Ergebnis als Query Result belegt mit Patent_1 Als Ergebnis wird in [Abb. 4.7] zu der vorgestellten Suche eine konkrete Instanz zu einem Patent, namentlich Patent_1, also ein sog. digitales Objekt zurückgegeben. Die kontextspezifische Suche zu einem Dokument erfolgt innerhalb eines Innovationsprozesses. Die gezeigte Abfrage ermöglicht überhaupt erst das Durchsuchen der modellierten und instanziierten Prozessontologie Schlussfolgern, Inferenz und Reasoner Das Beweisen (engl. reasoning) von Zusammenhängen ist anwendungsgetrieben und wird prototypisch in der WPIM-Pipeline erprobt [vgl. Kap. 4.11]. Beim Erstellen der WPIM- Ontologie dient Reasoning dazu, Konsistenz innerhalb der Klassen nachzuweisen und Seiteneffekte, wie z. B. unerwünschte Zugehörigkeit oder unerwünschte Vererbungen bei der Modellierung von Ontologien, zu detektieren. Bei der Integration oder dem Zusammenführen von Ontologien (wie der WPIM-Expertenontologie und der WPIM-Prozessontologie) hilft das Reasoning beim Aufzeigen von Beziehungen zwischen diesen Ontologien. Folgende Eigenschaft von Ontologien machen sich softwaregestützte Reasoner zu Nutze. OWL- Ontologien basieren auf Logik 1. Stufe, auch als Beschreibungslogik (engl. description logic, DL) bekannt. Hier betrachten wir insbesondere OWL DL, also den OWL-Description-Logic- 143

168 Operationalisierung der WPIM-Pipeline Umfang. Ziel ist es, mittels Reasoning also mathematisch logischen Verfahren, die zudem softwaretechnisch implementiert sind (sog. Reasonern), fehlerhafte Zustände innerhalb der Ontologie zu erkennen sowie nicht offensichtliches 153 aber vorhandenes Wissen abzuleiten. Aufgeführt werden nun Eigenschaften zu OWL: Die Beschreibungssprache OWL dient der Veröffentlichung und dem Austausch von Ontologien, die Austausch-Syntax ist RDF/XML gestützt, taxonomische Beziehungen zwischen den Klassen werden unterstützt, unterschiedliche Eigenschaften und Datentypen finden Unterstützung, Objekteigenschaften (Eigenschaften von Individuen) sowie Instanzen von Klassen und Eigenschaften werden berücksichtigt. Im weiteren Verlauf setzen wir auf Reasoning (i. S. des Einsatzes von softwaregestützten Reasonern), das Anwendungen auf RDF/RDFS-Modelle und OWL-Ontologien findet. Dabei dient das Reasoning zum Abgleich, ob neue Fakten mit einer gegebenen Ontologie konsistent sind, Individuen zu einer gegebenen Ontologie gehören (im Sinne einer Suchmaschine) und um neues Wissen aus der Ontologie abzuleiten. Die nachstehende Übersicht [Abb. 4.8] zu Semantic Reasonern ist unter Wikipedia verfügbar. Abb. 4.8: Semantic Reasoner 154 In [Abb. 4.8] ist eine Übersicht zu Inferenzmechanismen insbesondere DL Reasoner für OWL (DL) entnommen aus Wikipedia dargestellt. Voraussetzung für deren Einsatz ist, dass die Modelle in RDF(S), bzw. die Ontologien in OWL Light oder OWL DL vorliegen. OWL Full ist nicht entscheidbar und somit ist dafür der Einsatz von Reasonern derzeit nicht geeignet. 153 Zumindest für Menschen nicht offensichtlich. 154 Semantic Reasoner eine Übersicht aus Wikipedia [http://en.wikipedia.org/wiki/semantic_reasoner]. 144

169 Operationalisierung der WPIM-Pipeline CEL FaCT FaCT++ Hoolet KAON2 MSPASS Pellet RacerPro SimDL Bossam RACER Jena SweetRules für nicht kommerzielle Zwecke freigegeben, LISP-basiert ein Beschreibungslogik (engl. description logic, DL) Klassifizierer Weiterentwicklung des FaCT OWL-DL Reasoner, freier open-source C++ basierter Reasoner. Implementierter OWL DL Reasoner freie (für den nicht-kommerziellen Gebrauch) Infrastruktur zum managen von OWL DL, SWRL, und F-Logic Ontologien freier, open-source C Reasoner für verschiedene Beschreibungslogiken freier, open-source Java-basierter Reasoner für OWL DL kommerzieller Reasoner (Demo- und Forschungs-Versionen verfügbar) freier, open-source Java-basierter Reasoner für die Sprache ALCHQ, verfügbar als Protégé Plug-in, Funktion zur Bestimmung zur Verschiedenheit und mit Distanzmaß von Konzepten RETE-basierte Regel Engine, unterstützt Reasoning über OWL- Ontologien Semantic Web Reasoning System und Information Repository ein open source Semantic Web Framework für Java integriertes Set von Werkzeugen für Semantic Web Rules und Ontologien Protégé als freier, Open-Source-Ontology-Editor verwendet DL Reasoner über ein DIG Interface 155. DL Reasoner (für OWL DL), wie z. B. FaCT, FaCT++, RACER und Pellet, basieren auf der Analytic Tableau Methode [vgl. Kret08]. Innerhalb von Protégé wurden zwei Inferenzmechanismen erprobt, FaCT++ und Pellet FaCT++ Ein bekanntes beschreibungslogisches System, das auf der Tableau-Methode 156 basiert, ist FaCT 157 (Fast Classification of Terminologies). Als Nachfolger von FaCT fungiert mittlerweile das als Teil des EU WonderWeb-Projekts 158 entwickelte FaCT++; es wurde in C++ statt in LISP implementiert, basiert jedoch auf denselben Tableau-Algorithmen wie das Original [vgl. Kret08]. Der Namenszusatz ++ ist auf die C++ Implementierung zurück zu führen. Mit FaCT++ existiert ein moderner, performanter und flexibel erweiterbarer DL-Reasoner, der durch seine interne Datenstruktur auch für die Handhabung komplexer Wissensbasen geeignet ist. Die traditionelle auf den Reasoner ausgelegte Architektur bietet wenig Benutzungsinteraktivität und unterstützt keine Anfragesprachen 159. Zusätzlich bietet FaCT++ noch das Feature, dass es prädikatenlogische Probleme für Subsumtions- und Erfüllbarkeits-Checks generieren kann, die dann von First-Order-Theorembeweisern 160 als Eingabe akzeptiert werden. [vgl. Buch04, S. 2] 155 DIG Implementation: DIG ist eine XML Schnittstelle zu DL-Systemen, empfohlen von der DL Implementation Group. DIG 2.0 ist eine Weiterentwicklung für einen DIG interface Standard. 156 Analytische Tableau Methode (engl. Method of analytic tableaux) A graphical representation of a partially built propositional tableauin proof theory, the semantic tableau is a decision procedure for sentential and related logics, and a proof procedure for formulas of first-order logic. The tableau method can also determine the satisfiability of finite sets of formulas of various logics. It is the most popular proof procedure for modal logics [Girle 2000 in 157 Von Ian Horrocks an der Universität Manchester in LISP implementiert und auf ausschließlich T-Box- Schlussfolgerungen ausgelegt, weiterentwickelt von Dmitry Tsarkov [TsHo01]. 158 Website WonderWeb-Projekte Unter dem Begriff Theorembeweiser wird oftmals jegliche Form von Tools für maschinelles Schlussfolgern eingeordnet. Soll betont werden, dass es nur um Prädikatenlogik erster Stufe geht, spricht man teilweise auch von First-Order-Theorembeweisern [Buch04, S. 3 ff.]. 145

170 Operationalisierung der WPIM-Pipeline FaCT++ is the new generation of the well-known FaCT OWL-DL reasoner. FaCT++ uses the established FaCT algorithms, but with a different internal architecture. Additionally, FaCT++ is implementated using C++ in order to create a more efficient software tool, and to maximise portability. New optimisations have also been introduced, and some new features added. [http://owl.man.ac.uk/factplusplus/] Pellet Pellet ging aus vorhandenen Reasonern hervor, die die Beschreibungslogik von OWL (SHOIN(D)) bereits behandeln konnten. Die bekanntesten davon sind FaCT und Racer. Die Leistung der Reasoner war gut, jedoch sind einige für das Semantic Web notwendige Eigenschaften, wie A-Box Reasoning, conjuctive A-Box Queries und Unterstützung von XML- Schema-Datentypen, nicht vorhanden. Pellet erfüllt diese Anforderungen und bietet eine gute bis sehr gute Leistung an, wobei es der erste Reasoner ist, der ganz OWL DL verarbeiten kann. [vgl. Kret08, S. 81] Pellet, wurde von Evren Sirin und Bijan Parsia entwickelt und ist in Java implementiert. Der Reasoner kann OWL Lite und OWL DL Syntax (beide OWL-Sprachdialekte basieren auf Description Logic) verarbeiten und arbeitet dabei mit Tableaux-Algorithmen für A-Box- und T- Box-Reasoning korrekt und vollständig. Die Bedienung erfolgt über Kommandozeilen, APIs für OWL, die Manchester OWL-API library und Jena sind verfügbar. Ein DIG Server ermöglicht die Einbindung in unterschiedliche Clients wie den Protégé-OWL-Editor. Pellet ist Bestandteil des offiziellen SWOOP Editors für OWL und ist in den Protégé-OWL-Editor (Version Protégé 4.0) integriert [http://www.mindswap.org/2003/pellet/]. Pellet kann für OWL-DL einen vollständigen Konsistenz- sowie Syntaxtest durchführen. Als OWL-DL Reasoner sollte Pellet die Standardanforderungen für logische Schlussfolgerungen anbieten. [Kret08, S. 82] Dazu gehören nach Sirin et al. [Siri05] und [TsHo01]: Konsistenztest, der sicherstellt, dass eine Wissensbasis keine widersprüchlichen Aussagen enthält. Eine ABox wird gegen eine TBox auf Konsistenz geprüft. Konzept Erfüllbarkeit, testet, ob zu einer Klasse Instanzen bestehen können. Wenn nicht, ist durch die Definition einer solchen Instanz die ganze Ontologie unvereinbar. Klassifikation, berechnet Klassenbeziehungen und so eine komplette Klassenhierarchie. Realisation, errechnet die direkten Typen für jedes Individuum. Dies ist jedoch erst nach der Klassifikation möglich, da die direkten Typen im Bezug auf die Klassenhierarchie beschrieben sind [Siri05 und Kret08]. 146

171 Operationalisierung der WPIM-Pipeline Abb. 4.9: Architektur und Komponenten beim Reasoner Pellet [Siri05, S. 6] Eine detaillierte Beschreibung zu den Pellet-Komponenten findet sich unter Sirin et al. [Siri05, S. 6 ff.]. Wie auch dort beschrieben, stehen für Pellet multiple Schnittstellen (engl. multiple interfaces) zu diesem Reasoner zur Verfügung. Pellet ermöglicht unterschiedlich Zugänge zu den Reasoning-Fähigkeiten, ein webbasierter Demonstrator findet sich auf der Seite OWLSight 161 : Queries can be formulated using SPARQL. The SPARQL query forms SELECT, CONSTRUCT, and ASK are supported; DESCRIBE isn t, neither are OPTIONAL or FILTER. It s possible to answer such queries using Jena s SPARQL query engine on a Pellet-backed inference model. [http://pellet.owldl.com/features/#datatype] Pellet unterstützt SPARQL-Anfragen und kommt in der WPIM-Pipeline zum Einsatz. Details zur WPIM-Anwendung sind beschrieben in [Kap ] insbes. in [Abb. 4.65] Conclusio und Auswahl Semantische Suchen, z. B. mit SPARQL, sind gut geeignet, um aus umfangreichen Dateien mit semantisch annotierten Inhalten (z. B. RDF-Dateien), Instanzen (mit speziellen Eigenschaften) oder Klassen als Ergebnisse zu extrahieren. Im weitesten Sinn ist die Funktionsweise von SPARQL ähnlich wie von SQL für Datenbanken oder große Datenspeicher. Von Vorteil ist allerdings, dass RDF-Dateien einfach in Webseiten eingebunden oder über das Web verteilt und auch dort durchsucht werden können. Reasoning geht darüber hinaus. Wir verwenden Inferenzmechanismen, um Klassenhierarchien bzw. Ontologien zu durchsuchen. Anhand der verwendeten Suchkriterien werden Ausschnitte dieser Hierarchien bzw. Ontologien als Ergebnis ausgegeben. Inferenzmechanismen sind darüber hinaus gut geeignet, neue Klassen zu identifizieren und auch potenzielle Beziehungen zwischen Klassen abzuleiten. Natürlich sind diese Inferenzmechanismen auch auf Instanzen-Ebene anwendbar. Inferenzmechanismen verwenden wir vornehmlich auf Klassenebene. Für semantische Suchen auf Instanzebene setzen wir die semantische Abfragesprache SPARQL ein. Innerhalb von Protégé wurden zwei Inferenzmechanismen erprobt, FaCT++ und Pellet. Beide arbeiten auf Basis der Tableau- Methode [vgl. Kret08]. Die Ergebnisse der beiden Reasoner sind damit direkt vergleichbar. Abweichungen beim Reasoning über der WPIM-Ontologie für Prozesse und Experten, z. B. repräsentiert in OWL-DL, konnten nicht festgestellt werden. Beide Protégé Plug-ins arbeiten mit gleichwertiger Genauigkeit und Qualität. Der Zugriff von Reasonern setzt eine implementierte und befüllte ontologische Datenbasis in der

172 Operationalisierung der WPIM-Pipeline WPIM-Pipeline voraus. Daher bereiten wir im weiteren Verlauf der Arbeit die technische Realisierung des WPIM-Prototyps vor. Ziel wird sein, die mathematische Formalisierung in softwaretechnische Modelle und Implementierungen zu überführen. 4.4 Technische Realisierung des WPIM-Prototyps Im WPIM-Prototyp wird der in [Kap. 3.2] vorgestellte, mathematische Formalismus als Grundkonzept zur Repräsentation von Innovationsprozessen und Ressourcen softwaretechnisch realisiert. Die realen Konzepte sollen systematisch klassifiziert und sodann als digitale Objekte 162 in der WPIM-Pipeline repräsentiert werden. Dazu entsteht anhand der Spezifikation des Prozessmodells eine DTD, die grundlegende strukturelle Vorgaben für XML- Instanzdokumente enthält. Im Rahmen dieser technischen Spezifikation wird der mathematische Formalismus in rechnergestützte Repräsentationsformate überführt. Um eine semantische Annotation vorzubereiten, wird das WPIM-Vokabular auf technischen Ebenen definiert, spezifiziert und implementiert. Diese Überlegungen und die ersten Realisierungen des WPIM- Prototyps fliessen im Verlauf der Arbeit in den WPIM-Prototypen und später in die WPIM- Anwendung ein Transformation der mathematischen Formalismen in eine DTD Um eine maschinenverarbeitbare Auswertung der semantischen Prozessbeschreibungen sicherzustellen wird eine DTD entwickelt. Die Ausdrucksmächtigkeit ist ausreichend, um die benötigten Freiheitsgrade und Anforderungen an ein formalisiertes Prozessmodell zu unterstützen. Für zukünftige maschinenlesbare Prozessformalismen können auch XSD und RDF- Schemata (RDFS) sowie OWL verwendet werden. Deren Ausdrucksstärke übersteigt die der DTDs. Für die Anforderungen von WPIM sind DTDs ausreichend, diese unterstützen die geforderte Maschinenlesbarkeit und den Austausch der Daten zwischen Applikationen. [Code 4.8] zeigt die DTD namens WPIM.dtd, die aus dem mathematischen Modell [beschrieben in Kap ] abgeleitet wird. Bei der Erstellung wird als Hilfsmittel das Werkzeug XMLSpy 163 verwendet. Folgende Begriffe sind auf je ein Konzept in der Industrie zurückgeführt und können stellvertretend durch mehrere XML-Elemente repräsentiert werden: Projekt und Prozess, Pool und Swimlane sowie Aktivität (engl. activity) und Aufgabe (engl. task). <?xml version="1.0" encoding="utf-8"?> <!--XML-Beispieldatei von XMLSpy generiert v2008 sp1 (http://www.altova.com)--> <!DOCTYPE PROJEKT SYSTEM "WPIM.dtd"> <PROZESS>Projekt_WPIM <AUFGABE>Eine_Aufgabe_ohne_pool</AUFGABE> <POOL>Ein_Aufgaben_Pool <AUFGABE>a_Eine_Aufgabe</AUFGABE> <AUFGABE>b_Eine_Aufgabe</AUFGABE> <AUFGABE>c_Eine_Aufgabe</AUFGABE> <AUFGABE>d_Eine_Aufgabe</AUFGABE> </POOL> AUFGABE>Eine_Aufgabe_ohne_pool</AUFGABE> <POOL>Ein_zweiter_Aufgaben_Pool <AUFGABE>e_Eine_Aufgabe</AUFGABE> <AUFGABE>f_Eine_Aufgabe</AUFGABE> <AUFGABE>g_Eine_Aufgabe</AUFGABE> </POOL> <AUFGABE>Eine_Aufgabe_ohne_Pool</AUFGABE> <POOL>Ein_dritter_Aufgaben_Pool <AUFGABE>h_Eine_Aufgabe</AUFGABE> <AUFGABE>i_Eine_Aufgabe</AUFGABE> </POOL> <AUFGABE>Eine_Aufgabe_ohne_Pool</AUFGABE> 162 Instanzen von Klassen, also konkrete Ausprägungen oder Belegungen werden auch als Objekte oder genauer als digitale Objekte bezeichnet. 163 XMLSpy der XML Editor von Altova

173 Operationalisierung der WPIM-Pipeline <AUFGABE>Eine_weitere_Aufgabe_ohne_Pool</AUFGABE> </PROZESS> Code 4.8: WPIM.xml eine mögliche Prozess-Instanz in XML Hervorzuheben sind die Vorgehensweise und das Ergebnis der DTD-Entwicklung, beide werden vorgestellt in [Voge08]. Dazu wurde das mathematische Prozessmodell in eine DTD und eine XSD-Datei überführt. Danach wurde die dargestellte XML-Datei mit dem Werkzeug XMLSpy gegen die WPIM.dtd validiert. Das mathematische Modell kann erfolgreich in eine DTD überführt werden. Zudem können für die XML-Datei folgende Ergebnisse hinsichtlich des Abgleichs mit der DTD erzielt werden: Wohlgeformtheit und Gültigkeit. Erreicht werden diese grundlegenden Eigenschaften die XML-Datei genügt somit der DTD. Im Folgenden ist ein Ausschnitt der Prozess-Struktur in der zugehörigen DTD WPIM.dtd hinterlegt. Die DTD ist mittels der sog. Binding-Methode in den Kopf der XML-Datei eingebunden. <?xml version="1.0" encoding="utf-8"?> <!--DTD erstellt mit XMLSpy v2008 sp1 (http://www.altova.com)--> <!ELEMENT PROZESS (#PCDATA POOL AUFGABE)*> <!ELEMENT POOL (#PCDATA AUFGABE)*> <!ELEMENT AUFGABE (#PCDATA)> Code 4.9: Die WPIM.dtd Um Kardinalitäten zwischen den Konzepttypen detaillierter beschreiben zu können, wird weiterführend eine XML-Schema-Definition (XSD) entwickelt. Die WPIM.xsd ist in [Abb. 4.10] repräsentiert und mit dem Visualisierungs-Werkzeug XMLSpy von Altova grafisch dargestellt: Abb. 4.10: XML Schema WPIM.xsd in XMLSpy von Altova Im WPIM-Prototyp findet die weniger ausdruckstarke WPIM.dtd Verwendung. Für die WPIM- Anwendung wird eine eigene XSD entwickelt [vgl. Küsg11]. In [Code 4.9] ist die DTD zur benötigten Prozessbeschreibungen in XML dargestellt und daran kann eine Validierung durchgeführt werden. Weitere Attribute, zugehörige Kardinalitäten und Typisierungen sind in [Code 4.10] abgebildet, zudem sind dort Erklärungen der Form // (Kommentar) enthalten: <?xml version="1.0" encoding="iso "?> <!--DTD generated by XMLSPY v2004 rel. 3 U (http://www.xmlspy.com)--> <!ELEMENT PROZESS (POOL)+> //(0 oder * optional) <!ELEMENT POOL (NAME, BESCHREIBUNG, ERSTELLER, VERANTWORTUNG, VERTRETER)> <!ELEMENT NAME (#PCDATA)> <!ELEMENT BESCHREIBUNG (#PCDATA)> <!ELEMENT ERSTELLER (#PCDATA)> 149

174 Operationalisierung der WPIM-Pipeline <!ELEMENT VERANTWORTUNG (#PCDATA)> <!ELEMENT VERTRETER(#PCDATA)> <!ELEMENT PROJEKT (AUFGABE)+> //(2 mit start und ende oder * optional) <!ELEMENT AUFGABE (NAME, BESCHREIBUNG, ERSTELLER, VERANTWORTUNG, VERTRETER)> <!ELEMENT NAME (#PCDATA)> <!ELEMENT BESCHREIBUNG (#PCDATA)> <!ELEMENT ERSTELLER (#PCDATA)> //(Person vom Typ Experte) <!ELEMENT VERANTWORTUNG (#PCDATA)> //(Person vom Typ Experte) <!ELEMENT VERTRETER(#PCDATA)> <!ELEMENT DOKUMENT(#PCDATA)> <!ELEMENT LESSONLEARNED(#PCDATA)> <!ELEMENT WEBLINK(#PCDATA)> <!ELEMENT PROJEKT (RELATION)+> <!ELEMENT RELATION (NAME)> <!ELEMENT NAME (#PCDATA)> //(vom Typ add) //(1 oder * nötig) <!ELEMENT POOL (AUFGABE)+> //(1 oder * nötig) <!ELEMENT AUFGABE (NAME, BESCHREIBUNG, ERSTELLER, VERANTWORTUNG, VERTRETER)> <!ELEMENT NAME (#PCDATA)> <!ELEMENT BESCHREIBUNG (#PCDATA)> <!ELEMENT ERSTELLER (#PCDATA)> <!ELEMENT VERANTWORTUNG (#PCDATA)> <!ELEMENT VERTRETER(#PCDATA)> <!ELEMENT POOL (RELATION)+> //(1 oder * nötig) <!ELEMENT RELATION (NAME, VOR, NACH)> <!ELEMENT NAME (#PCDATA)> <!ELEMENT VOR (#PCDATA)> //(vom Typ Element Aktivität) <!ELEMENT NACH (#PCDATA)> //(vom Typ Element Aktivität) //(Weitere optionale * Elemente vom Typ Element Experte ) <!ELEMENT EXPERTE (NAME, VORNAME, ABTEILUNG, , TELEFON > //(2 mit start und ende oder * optional) <!ELEMENT NAME (#PCDATA)> <!ELEMENT VORNAME (#PCDATA)> <!ELEMENT ABTEILUNG (#PCDATA)> <!ELEMENT (#PCDATA)> //(vom Typ Element Mail) <!ELEMENT TELEFON(#PCDATA)> //(vom Typ Element TelNr) Code 4.10: Erweiterte WPIM.dtd Die in [Code 4.10] dargestellte XML-Datei dient zur Darstellung der Kardinalitäten und Typzuweisungen. Prozess, Pool und Aufgaben werden aus dem in BPVA modellierten Prozessmodell extrahiert. Die Expertenbeschreibung kann entweder manuell vorgenommen werden oder es können bestehende Profildateien, z. B. aus sozialen oder Experten-Netzwerken wie XING, Facebook, LinkedIn oder asmallworld, übernommen werden. Wir empfehlen bestehende Expertenbeschreibungen aus den genannten frei verfügbaren sozialen Netzwerken oder Firmenkontaktdatenbanken (sog. Gelbe Seiten) zu nutzen. Die Akzeptanz kann so gesteigert und der Erstellungsaufwand reduziert werden. Auch unternehmenseigene Profildaten aus Profildatenbanken können verwendet werden. Der Aufwand zur Integration der Profildaten begrenzt sich auf die einmalige Anpassung der Schnittstelle zwischen dem WPIM-System und der bestehenden Datenquelle. Exkurs und Ausschluss von XSLT: Grundlagen zu XSLT finden sich unter [vgl. Kap XSL, XSLT, XQL und XML-Werkzeuge]. Zur Ausleitung der Konzepte aus einer XML-Datei wurde XSLT prototypisch untersucht. Die einfache Anwendung von XSLT konnte überzeugen. Die Weiterverarbeitung der Ergebnisse konnte nicht sichergestellt werden, da XSLT nur eine (reduzierte) Sicht im Sinne einer Transformation auf die XML-Daten gewährt, und z. B. im Browser darstellt. Die Ausleitung der Transformation im XML-Format zur Weiterverarbeitung dieser extrahierten Daten, wie sie die WPIM-Pipeline fordert, konnte mit XSLT nicht erzielt werden. Die nächsten Schritte bei der technischen Realisierung des WPIM-Prototyps stellen die technische Spezifikation und die Implementierung der Ressourcen dar. 150

175 Operationalisierung der WPIM-Pipeline Technische Spezifikation und Implementierung von Ressourcen Von der technischen Spezifikation wird auf eine Implementierung übergeleitet. Stets vor dem Ziel, eine technische Realisierung des WPIM-Prototyps zu erwirken. Neben der Klasse:Prozesse steht die Klasse:Ressource zur Verfügung. Im Weiteren untersuchen wir Ressourcen und insbesondere die Unterteilung der SuperKlasse:Ressource in die SubKlasse:Dokument und die SubKlasse:Experte. Schwerpunkt bildet die Implementierung der Klassenhierarchien als Modell bzw. Ontologie in Protégé. An dieser Stelle sei anzumerken, dass unter der Klasse:Ressource auch noch weiter (Sub-) Klassen zu Ressourcen denkbar sind. Das können z. B. Klassen wie Klasse:Budget oder Klasse:Methode sein. Im nächsten Abschnitt wird insbesondere die Ressource Dokument und somit die Klasse:Dokument betrachtet Technische Spezifikation und Implementierung der Dokumente Die WPIM-Methode integriert Ressourcen in Prozesse. Unter Ressourcen verstehen wir an dieser Stelle Dokumente, wie z. B. Patente, die direkt den Aktivitäten des Innovationsprozesses zugeordnet werden. Unter anderem kann eine Prozess-Ontologie (mit entsprechenden Konzepten zu den hier beschriebenen Ressourcen) als Rahmenwerk dienen, um die Ressourcen direkt zuwiesen zu können. Die Ressourcen werden als Dokumente oder Verweise auf Dokumente dem Prozessmodell bzw. der Prozessontologie zugeordnet. Eine inhaltliche Durchsuchung der Ressourcen (Dokumente, Patente) ist beim Ansatz WPIM zunächst nicht vorgesehen. Dies ist nicht Bestandteil der Arbeit. Die betrachteten Ressourcen werden in einer Klasse Klasse:Dokument zusammengefasst. Diese Klasse kann als Unterklasse der Klasse Klasse:Ressource interpretiert werden. Darstellung zu einer ersten Formalisierung und Typisierung: Klasse:Dokumente [Handbuch Lessons Learned Patent CAD-File Link 164 ] Aufbauend auf diesen technischen Spezifikationen wird eine (Klassen-) Hierarchie mit Vererbung entwickelt und implementiert: SuperKlasse(Ressource) SubKlasse(Dokument) SubKlasse(Handbuch) SubKlasse(Patent) SubKlasse(Leitfaden) SubKlasse(Lessons_Learned) SubKlasse(Best_Practice) SubKlasse(CAD-File) SubKlasse(Anweisung) SubKlasse(VerfahrensAnweisung) SubKlasse(Link) Code 4.11: Klassen, Hierarchien und Vererbung bei Dokumenten Die Klasse:Ressource dient dazu, Ressourcen, wie z. B. hier Dokumente, in die Prozessontologie (durch diese Klasse der Ressource) integrieren zu können. Die hier formalisierten SubKlassen zur Klasse:Dokument sind nicht abgeschlossen bzw. vollständig. Je nach Domäne können diese beliebig ergänzt werden, z. B. um Leitfäden oder Gesetzestexte. Die Elemente des Dublin Core Element Set 165 [vgl. Abb. 4.2] werden in dieser Arbeit zur Annotation von Dokumenten herangezogen. Diese Elemente werden als beschreibende Attribute eingesetzt und der Klasse:Dokument zugeordnet. Zudem werden die Elemente an die unterliegenden SubKlassen der Klasse:Dokument vererbt. Die einzelnen Elemente des DC sind ausführlich beschrieben unter [http://dublincore.org/documents/dces/]. 164 Ein Link stellt hier eine Referenz auf ein Dokument dar. 165 Dublin Core Metadata Element Set, Version und

176 Operationalisierung der WPIM-Pipeline Abb. 4.11: Beschreibung des Elements Ersteller (engl. creator) aus dem [DCES09] Es folgt, formal dargestellt, die Klasse:Dokument, die beispielhaft mit einigen Elementen ausgestaltet wurde. Klasse:Dokument (Titel, Creator, Description, Publisher, Date, Format, Language) Die Belegung der vorgestellten und implementierten Elemente bzw. der Attribute in der Klasse:Dokument erfolgt nun mit den konkreten Daten eines Handbuchs. <?xml version="1.0"?><rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"> <rdf:description rdf:about="http://www.books.com/handbuchwpim"> <dc:title>handbuchwpim</dc:title> <dc:creator>t. Vogel</dc:creator> <dc:description>ein Buch zum Thema WPIM</dc:description> <dc:publisher>tbd</dc:publisher> <dc:date> </dc:date> <dc:format>text/html</dc:format> <dc:language>de</dc:language> </rdf:description> </rdf:rdf> Code 4.12: Exemplarische Beschreibung eines Buches mit dem Dublin Core SubKlassen von Dokument, wie z. B. SubKlasse(Anweisung), erben diese Attribute und können um weitere benötigte Attribute erweitert werden. Solche Erweiterungen können ebenfalls an tiefere SubKlassen, wie z. B. SubKlasse (VerfahrensAnweisung), weitervererbt werden. In [Abb. 4.12] findet sich ein Ausschnitt der implementierten Klassenhierarchie in Protégé. 152 Abb. 4.12: Ausschnitt der Implementierung der Klasse:Dokumente in Protégé Gut zu erkennen in [Abb. 4.12] ist das Präfix dc: stellvertretend für den Dublin Core, im Sinne der Nutzung und der Erweiterung des definierten DC Element Sets. Bei weiterführenden Betrachtungen der Dokumente haben wir das Augenmerk auf Patente gelegt [LVKH07; LVKH08; LVKH08a; LVKH09; LVKH09a]. Patente sind Ressourcen oder exakter Dokumente, die bei Innovationen im Umfeld der WPIM-Anwendung besonders großen Nutzen stiften. Darauf aufbauend wird die Erweiterung der Ontologie z. B. um verbundene Patente, Patentfamilien oder generell, externalisiertes geistiges Eigentum (engl. intellectual property) wie Gebrauchsmuster entwickelt.

177 Operationalisierung der WPIM-Pipeline Zudem erweitern Lessons Learned die Dokumente, die im Rahmen des Musterprozesses und der Prozessinstanzen bei der Hervorbringung neuer Produktinnovationen unterstützten. Die Verknüpfung der Ressourcen mit dem Prozessmodell kann unterschiedlich erfolgen, z. B. durch: Properties/Relationen, die Ressourcen in die Prozessmodell integrieren oder durch Ontology-Mapping [KaSc05], dabei wird z. B. die Ressourcen-Ontologie mit der Prozess-Ontologie verbunden. Sind Prozess und Ressourcen ontologisch verbunden, wird durch die semantische Annotation all dieser Ressourcen (die Prozesskonzepte eingeschlossen) eine semantische Suche und das semantische Auffinden aller enthaltenen Wissen-Ressourcen sichergestellt Technische Spezifikation und Implementierung der Expertenontologie Die Experten-Ontologie in OWL stellt die Zusammenhänge zwischen einzelnen Experten, präziser einzelnen Experten-Profilen dar. Hierbei geht es nicht ausschließlich um die syntaktische Beschreibung von Experten wie aus Expertennetzwerken oder Sozialen Netzwerken bekannt. Vielmehr geht es um die Kompetenzen und Innovationsleistungen der konkreten Persönlichkeiten. Auch die Betrachtung von persönlichen geistigen Leistungen und Reputationen ist zentrale Überlegung bei WPIM. Im WPIM-Datenmodell werden unter anderem Erweiterungen zu persönlichen Profilen betrachtet: Erweiterungen im WPIM-Datenmodell Für die Klasse Person werden Attribute festgelegt, für die Relationen je ein Definitions- und ein Wertebereich. Person [Mitarbeiter Experten Bearbeiter Vertreter] Verantwortlichkeit [Domain:Person Range:Aufgabe] Die Darstellung als (Klassen-) Hierarchie mit Vererbung: SuperKlasse(Ressource) SubKlasse(Person) SubKlasse(Mitarbeiter) SubKlasse(Experte) SubKlasse(Fachmann) SubKlasse(expert) Code 4.13: Klassen, Hierarchien und Vererbung bei Dokumenten Die konkrete Umsetzung einer Unternehmenshierarchie variiert je nach Unternehmen. Zudem können einzelne Mitarbeiter verschiedene Rollen einnehmen. Rollen sind z. B. Projektleiter, ISO-Beauftragter oder Vertretungsrollen für Kollegen. Nachfolgend findet sich die grundsätzliche Einordung von SuperKlasse:Ressource und der Klasse:Experte. Im unteren Teil der [Abb. 4.13] wird mit der Klasse foaf:pastproject belebt, in welchen Projekten ein Experte bereits/zuletzt tätig war. 153

178 Operationalisierung der WPIM-Pipeline 154 Abb. 4.13: Ausschnitt der implementierten Klasse:Experten In [Abb. 4.13] tragen Experten das Präfix foaf: und nutzen/erweitern somit das FOAF- Vokabular. Personen als Superklasse sollen im Sinne verschiedener Personengruppen aufgeteilt werden. Experten, Mitarbeiter und Vorgesetzte sowie Chefs sind denkbar. Auch die Verantwortlichkeit kann im Rahmen der Ontologie unterteilt werden. Die Domain entstammt dem Bereich Person der Range den Aufgaben. Somit wird dieser konkreten Person aus der Klasse:Person eine Instanz Aufgabe aus der Klasse:Aufgabe zugeordnet. Diese Zuweisung soll im WPIM-Prototyp semantisch erfolgen. Zuordnungen können im Rahmen einer semantischen Suche analysiert werden. Das WPIM-Datenmodell wird dementsprechend erweitert, semantisch hinterlegt und in der WPIM-Pipeline [vgl. 4.11] implementiert. Für die WPIM-Pipeline und die spätere WPIM-Anwendung ist im konkreten weiteren Verlauf der Arbeit eine geeignete Systemarchitektur auszuwählen und umzusetzen. 4.5 Systemarchitektur Paradigmen Die Auswahl eines Systemmodells für WPIM stellt ein allgemeines Paradigma der Informatik dar. Im Folgenden werden Systemmodelle mit dem Ziel vorgestellt, ein geeignetes Systemmodell für die Implementierung der WPIM-Methoden zu identifizieren. Dieses Systemmodell ist so zu gestalten, dass darauf auch die WPIM-Pipeline und im weiteren Verlauf der Arbeit die WPIM-Anwendung operationalisiert werden kann Client-Server-Architektur Dabei erfolgt die Strukturierung des Anwendungssystems gem. dem ADK-Strukturmodell in die Teilsysteme Anwendungsfunktion (A), Datenverwaltung (D) und Kommunikation (K) mit Personen und Rechnern. Die Vorteile begründen Ferstl/Sinz in erhöhter Flexibilität, Reduzierung der Komplexität des Systems sowie in der Standardisierung und Portierbarkeit. [FeSi98, S. 301] Das ADK-Strukturmodell ist getrieben aus technisch-systemischer Sicht. Je nach Strukturierung von ADK über die C-S-Architektur (auch als C-S-Prinzip oder C-S-Konzept betitelt) wird von Thin-Clients oder Fat-Clients gesprochen [FeSi98]. Diese Aufteilung über physische Strukturen der Client-Server-Systeme setzt sich fort in der Verteilung der Software- Komponenten, Anwendungen und Programmen über die C-S-Architektur. Aus der Sicht der Anwendung im Rahmen des Client-Server-Konzepts ist ein Server ein Programm, das einen Dienst anbietet. Web Programme, die z. B. auf dem (Web-) Client ausgeführt werden, können diese Dienste nutzen. Zur Kommunikation zwischen Client und Server können in Abhängigkeit vom Dienst unterschiedliche Protokolle eingesetzt werden, die den Datenaustausch zwischen Client und Server ermöglichen. Der Server mit seinen Diensten ist in Bereitschaft, um jederzeit auf die Kontaktaufnahme der Clients reagieren zu können. Im Unterschied zum Client, der aktiv einen Dienst anfordert, verhält sich der Server passiv und wartet auf Anforderungen. Die Regeln der Kommunikation für einen Dienst (Format, Aufruf des Servers, und die Bedeutung der zwischen Server und Client ausgetauschten Daten), werden durch ein Protokoll festgelegt, und das Protokoll ist spezifisch für den jeweiligen Dienst [CSKo08]. Das Client-Server-Modell ist das Standardkonzept für die Verteilung von Aktivitäten innerhalb eines Netzwerkes. Aktivitäten werden mittels Server auf verschiedene Rechner verteilt und können bei Bedarf von mehreren

179 Operationalisierung der WPIM-Pipeline Clients zur Lösung ihrer eigenen Aktivitäten oder Tasks angefordert werden. Der Client kann auf Wunsch eine Aktivität oder eine Ressource vom Server anfordern. Der Server, der sich auf einem beliebigen anderen Rechner im Netzwerk befindet, beantwortet die Anforderung, d. h. er stellt die Ressource bereit [CSMo08]. Eine Aktivität wird im Client-Server-Modell häufig auch als Dienst (engl. service) bezeichnet. Ein Client-Server-System ist eine Software (Anwendungssystem), welche für ihre Aktivitäten und Funktionen vom Client-Server-Modell Gebrauch macht. Anders ausgedrückt, wird die Software so entwickelt, dass sie das Client- Server-Modell nutzen kann. Die Client-Server-Architektur bezeichnet ein Systemdesign, bei dem die Verarbeitung einer Anwendung in zwei separate Teile aufgeteilt wird. Ein Teil läuft auf dem Server (Backend-Komponente), der andere Teil auf einer Workstation (Client oder Front- End) [CSMo08]. Die Bezeichnung Client-Server-Architektur bezieht sich in diesem Fall auf die Verteilung von Anwendungen Peer-to-Peer (P2P) Im Peer-to-Peer-Modell (P2P) nimmt ein beteiligtes Programm innerhalb des Netzwerkes gleichzeitig Client- und Server-Funktionalität ein [vgl. PtoP05]. Zur Abgrenzung: Im Client- Server-Modell sind die Komponenten Client und Server getrennt zu betrachten und die entsprechende Funktionalität ist auf verschiedene Programme verteilt. Peer-to-Peer kann als bilaterale Kommunikation zwischen zwei oder mehr gleichberechtigten Partnern verstanden werden, die beide gleichwertige Fähigkeiten und Verantwortlichkeiten haben. Eine klassische Rollenverteilung wie im Server-Client-Modell existiert im P2P-System nicht mehr. [CMOW02, S. 23] Zu den wohl beliebtesten Anwendungen im Internet haben sich in den letzten Jahren besagte Peer-to-Peer Anwendungen entwickelt. Dabei handelt es sich um Software, die es ermöglicht, auf einfache Art und Weise Dateien aller Art zwischen einzelnen Rechnern auszutauschen. Die erste bekanntere Anwendung dieser Art war Napster 166, die hauptsächlich zum Austauschen von Musikstücken im MP3-Format 167 verwendet wurde [PtoP05]. Eine Peer-to-Peer Architektur ist nicht ein fest aufgebautes Netz wie etwa das Internet, sondern eine Ad-hoc-Umgebung, in der die Partner spontan miteinander in Verbindung treten, ohne auf eine zugrunde liegende Infrastruktur angewiesen zu sein. Zudem wird von P2P-Netzen gefordert, dass sie adaptiv und selbstkonfigurierend sind. [CMOW02] P2P-Dienste habe besonders weite Verbreitung beim Teilen/Verteilen (engl. sharing) von multimedialen Files erreicht. Industrien haben zum Schutz urheberrechtlicher Inhalte klassische C-S-Dienste zum Download von Musik und Filmen im Internet verboten und abgeschaltet. Die Internetgemeinde entwickelt immer neue Peer-to-Peer Software, die eine noch höhere Flexibilität und Funktionalität anbietet, und die auch das einfache Abschalten von Diensten unmöglich macht. Zu erwähnen sind hier vor allem Kazaa 168, Bearshare 169, Edonkey 170, Emule 171 und Bittorrent 172 [PtoP05]. Diese Peer-to-Peer Anwendungen werden zudem unterstützt durch spezielle Suchmaschinen, wie Sharereactor 173 oder Suprnova 174. Damit ist es möglich, fast alles, was in digitaler Form MP3: MP3 ist eine Dateinamenserweiterung (Suffix). Dahinter verbirgt sich ein Verfahren zur verlustbehafteten Kompression digital gespeicherter Audiodaten

180 Operationalisierung der WPIM-Pipeline erhältlich ist, einfach aus dem Internet zu laden, egal ob Musik, Filme, Bücher oder Software [PtoP05] Schichtenarchitekturen Grundlagen Schichtenarchitekturen dienen der Unterteilung eines Softwaresystems in Schichten. Deren Abhängigkeitsbeziehungen zueinander finden Einschränkung durch die Architektur. Vorteile liegen in der Abgrenzung der Schichten und Schnittstellen. Durch diese Modularisierung kann die Komplexität reduziert werden und die Wiederverwendbarkeit der Komponenten kann auch systemübergreifend erhöht werden. Die Komponenten oder Schichten (engl. tier) werden dabei sinnbildlich übereinander angeordnet, eine Komponente darf dabei nur auf Schichten unter ihr zugreifen. Dadurch können Zyklen in den Abhängigkeiten vermieden werden. Die Arbeitsteilung zwischen Client und Server kann auf sehr unterschiedlichen Ebenen einer Systemanwendung erfolgen. Um die Aktivitätentrennung besser beschreiben zu können, wird oft versucht, verteilte Anwendungen in ein Schichtenmodell zu unterteilen. [Naum06] Im Gegensatz zum ISO-OSI-Referenzmodell 175 [FeSi98, S. 300; CSMo08] gibt es aber noch kein standardisiertes Modell für verteilte Anwendungen. Solche Modelle nutzen die Ebene 7 des OSI-Modells. Bei der Anordnung der Schichten stehen zwei Paradigmen zur Auswahl [Naum06]: Der Bottom-up-Ansatz beginnt auf der Schicht der Datenhaltung und integriert nach oben hin zu den Benutzern. Eine Anforderung dieser Sichtweise kann sein, verschiedene Datenquellen integriert betrachten oder verarbeiten zu wollen. Der Top-Down-Ansatz startet auf oberster Schicht mit den Anforderungen der (menschlichen) Anwender an das Softwaresystem, z. B. ausgelöst durch einen globalen Informationsbedarf, und arbeitet sich systematisch zu den unteren, den Datenhaltungsschichten vor [vgl. Naum06, S. 25]. Bei linearen Schichtenarchitekturen dürfen keine Schichten übersprungen werden, bei Schichtenarchitekturen mit strikter Ordnung hingegen ist es möglich, einzelne Schichten auszulassen bzw. diese zu überspringen [vgl. BaCK03]. Die Anzahl der Schichten ist auf dann auf die Anwendungsfälle abzustimmen Schichtenarchitektur Diese Architektur wird der Vollständigkeit halber nochmals aufgegriffen, wurde aber bereits unter der Client-Service-Architektur abgehandelt. Die zweischichtige Architektur (engl. two tier architecture) ist eine Client-Server-Architektur, die softwareseitig als zweischichtiges System aufgebaut ist. Die Rechenkapazität wird dabei weitestgehend auf die Client-Rechner ausgelagert, um den Server zu entlasten. Klassisch finden gepaart einige Clients und ein Fat-Server Einsatz. Die Datenbankanwendung wird auf dem Server vorgehalten, mehrere Clients übernehmen individuell die von Benutzern geforderte Logik sowie die Darstellung der verschiedenen Ansichten (engl. Views) für die Benutzungsschnittstelle Schichtenarchitektur Model View Controller (MVC) [Burk97, 60] zeigt die Modellierung des MVC-Architekturmusters in der Unified Modeling Language (UML) [siehe FoKe98]. Die Bezeichnung Modellklasse entstammt dem Prinzip Model-View-Controller, das im Zusammenhang mit Smalltalk 176 relativ bekannt wurde. Heute 174 Das größte P2P-Netzwerk Die Smalltalk Homepage - Smalltalk ist eine dynamisch typisierte objektorientierte Programmiersprache und zugleich eine vollständige Entwicklungsumgebung. Mit Einfluss auf spätere Programmiersprachen, wie z. B. Objective-C, Java und Ruby. Smalltalk wurde die erste populäre objektorientierte Programmiersprache. Smalltalk ist im Gegensatz zu Sprachen wie C++ oder Java eine rein objektorientierte Programmiersprache, somit sind auch Datentypen wie Integer, Character ebenfalls vollwertige Objekte. 156

181 Operationalisierung der WPIM-Pipeline wird dieses Entwurfsprinzip als Architekturmuster bezeichnet [Buschmann96 in Burk97, 62]. Abb. 4.14: Architekturmuster MVC Die [Abb. 4.14: Architekturmuster MVC] wurde übernommen von [http://assets.devx.com/articlefigs/18289.jpg], dort wird neben dem MVC auch das Model-View- Presenter (MVP) Architekturmuster dargestellt. Das MVC Architekturmuster beinhaltet eine Architektur für Benutzungsschnittstellen, bei der eine Anwendung aufgeteilt ist in die darunterliegende Applikationsschicht (sog. Modell), eine Anzahl verschiedener Ausschnitte des Modells, die darstellbar sind (sog. Views) und Kontrolleinheiten, welche Veränderungen des Modells und der Views synchronisieren. Somit wird eine weitgehende Trennung zwischen den Benutzungsoberflächen und dem eigentlichen Anwendungsinhalt erreicht. In Bezug auf UML beschreibt Burkhardt bei MVC die Modellklassen als Schaltzentren zwischen den Darstellungsklassen (sog. Views) und den Kontrollklassen (externe und interne Schnittstellen). Bei einer Modellklasse treffen Ereignisse ein, die die in der Modellklasse enthaltene oder von der Modellklasse verwaltete anwendungsspezifische Information beeinflusst. Daraufhin initiiert die Modellklasse in einer etwaigen Darstellung der Daten in einem Fenster zum Beispiel die Aktualisierung dieses Fensters. Dies zeigt den allgemeinen Charakter von Modellklassen, die in aller Regel Beziehungsklassen sind. [vgl. Burk97, S. 63] Singer beschreibt Schwierigkeiten bisheriger Applikationen: Dabei war die Programmlogik mit dem Graphical-User-Interface (GUI) Code verwoben, was sowohl die Erweiterung als auch die Wartung erschwerte. Als Lösung zeigt er die Aufteilung in drei Komponenten nach dem MVC-Architekturmodell. Die Vorteile sind in der einmaligen Erstellung der Programmlogik, die beliebige Kopplung von GUIs und die Kommunikation zwischen Model und View durch den Controller zu sehen. Zudem wird eine Arbeitsteilung bei der Erstellung von Software besser unterstützt. [Sing04] Modell Das Datenmodell operiert auf einer vollständig, gekapselten Darstellung von Objekten bzw. Daten, die von der Anwendung bearbeitet werden. Dazu stellt das Datenmodell gewisse Dienste zur Verfügung, um die Daten zu manipulieren, z. B. Neuberechnung und Abspeicherung. Man sollte unbedingt das Modell und die Dienste, die es zur Verfügung stellt, so implementieren, dass diese vom Application Programming Interface (API) unabhängig sind. Das Modell fungiert dann als eine Virtuelle Maschine oder Kernel der Anwendung. [Knau03, S. 10] Das Datenmodell kann somit als Daten mit zugehörigen Datenverarbeitungsmethoden verstanden werden. Die Daten werden von den Views beobachtet bzw. benachrichtigen die Views bei Änderungen. Das Datenmodell ist unabhängig von den Views sowie dem Controller, 157

182 Operationalisierung der WPIM-Pipeline es stellt lediglich über eine Schnittstelle die Daten bereit. Daher ist es hilfreich, ein Model Interface festzulegen, um die Modelle leicht austauschen zu können. [Sing04, S. 8] Controller Knauer postuliert, der Controller auch Anwendungsmiddleware (engl. Application Logic) reagiert auf Benutzungseingaben und verwendet Information aus dem View, um das Modell- Objekt bzw. die Modell-Daten zu modifizieren. Zudem ist diese Application Logic verantwortlich für die Interaktion. [Knau04] Der Controller interpretiert die Events aus der Benutzungsschnittstelle (auch Sicht oder Präsentation, engl. view) und leitet diese an das Modell weiter. Somit ist für jede Sicht ein individueller Controller zu erstellen, allerdings sind beliebig viele Model-View-Paare für ein Modell denkbar. [Sing04] View Die Präsentation des Modells stellt eine Sicht auf das Modell für die Benutzung bereit und kann darüber hinaus als Benutzungsschnittstelle (engl. user interface) interpretiert werden. Die View bietet eine Sicht auf das Datenmodell und beobachtet dieses auf Veränderungen. Treten Veränderungen ein, so wird die View dementsprechend aktualisiert. Singer beschreibt Views als schachtelbar (engl. composite pattern) die zudem einfach ausgetauscht werden können. [Sing04] Es ist durchaus üblich, mehrere Präsentationen zu implementieren und diese durch Anwender zu evaluieren. Durch dieses Vorgehen kann jene Präsentation ausgewählt werden, welche durch die Anwender die größte Akzeptanz erfährt Modale Grundtypen Für den Entwurf der Benutzungsschnittstellen werden drei ausgewählte modale Grundtypen vorgestellt: formularbasierte, workflow- oder dialog-orientierte und grafische Views. Formularbasierte Benutzungsschnittstellen: Der Prozess des Erfassens von neuen Fakten muss möglichst einfach und elegant in den täglichen Arbeitsprozess der Nutzer eingebettet sein. Die Eingabe der Fakten erfolgt z. B. über eine formularbasierte Schnittstelle. [StSN05, S. 14] Eingabemasken mit optionalen und Pflichtfeldern dienen der Erfassung von Faktenwissen und Information. Workflow-, Dialog-orientierte Benutzungsschnittstelle: Die Benutzungsschnittstelle ist stark am Workflow orientiert und folgt den einzelnen Workflow-Schritten. Erst wenn ein Workflow- Schritt abgeschlossen wurde, kann der nächste Schritt bearbeitet werden. Problematisch bei dieser sequenziellen Vorgehensweise sind Rückschritte und Iterationen. Grafische Benutzungsschnittstelle: Bei Graphical User Interfaces (GUI) können auf rein visueller Basis Entitäten per Drag and Drop auf einer Arbeitsfläche hinzugefügt, entfernt oder bearbeitet werden. Bei grafischen Benutzungsschnittstellen bilden die Fenstertechnik und What You See Is What You Get (WYSIWYG) die Grundlage. Die Informationsvermittlung erfolgt mittels Bildern, Icons, Diagrammen etc. diese sind realitätsnah und leicht verständlich [Ande98] Kombinierte Modi Diese Grundtypen können zu komplexeren Benutzungsschnittstellen aggregiert werden auf der Grundlage des: 158

183 Operationalisierung der WPIM-Pipeline sog. Multimodalen Ansatzes sowie des Ansatzes der Multiple View. Multimodale Benutzungsschnittstelle: Die Benutzungsschnittstelle kombiniert mehrere der drei modalen Grundtypen. Dies geschieht durch Fenster, die nebeneinander geöffnet sind und eine Art Arbeitsfläche bilden. Multimodale Benutzungsschnittstellen werden durch die Verwendung mehrerer Eingabemodalitäten definiert, durch die ein Interaktionspartner mit einem Computersystem in Kontakt treten kann. Multimodale Informationsvisualisierung beschäftigt sich ausdrücklich mit der Möglichkeit, Alternativen und Kombinationsmöglichkeiten mit visuellen Abbildungen zu schaffen [Bald02]. Es ist denkbar, dass eines dieser Module einen Überblick über die zu erledigenden Aktivitäten gibt, ein weiteres Modul konkrete Anfragen und Eingaben zu einem Arbeitsschritt anbietet. Somit kann in der Übersicht, z. B. entlang eines Workflows, navigiert werden und zudem sind detaillierte Angaben zu treffen. Der Arbeitsschritt kann so im Kontext der Aktivität erledigt werden. Multiple View: Bei Benutzungsschnittstellen mit multiplen [Trie07, StSN05] oder auch sog. tightly-coupled [Robe99] Views werden in einem View getroffene Einträge sofort in den anderen View-Modulen der Benutzungsschnittstellen sichtbar bzw. es können noch zusätzliche Eingabemasken auf dem Monitor erscheinen. Dies geht über den Umfang von multimodalen Benutzungsschnittstellen hinaus Schichtenarchitektur und Mehrschichtenarchitekturen Implementierungstechnisch existieren zahlreiche Varianten von MVC, u. a. für multi-user Umgebungen. In der Praxis finden sich häufig Varianten, bei denen Control und View vermischt sein können. Nach Buschmann et al. gibt es neben MVC noch PAC Presentation Abstraction Control beschrieben im Buch Gang-of-five Design Patterns. Bei Mehrschicht-Architekturen werden nach Kühn zusätzlich zur 3-Schichtarchitektur ein Web-Server und ein Web-Browser (auf einem Web-Client) zwischengeschaltet [Kühn07]. Auch bei Datenbanksystemen (DBS) und DB-Schemata werden in der Praxis mehrschichtige Architekturen eingesetzt Serviceorientierte Architektur (SOA) Melzer beschreibt SOA als Systemarchitektur zur Repräsentation unterschiedlicher Methoden und Anwendungen als wiederverwendbare und auch offen zugreifbare Dienste (engl. services). [Melz07, S. 11] Ziel der SOA ist es, dass Unternehmen innerhalb einer kurzfristigen und kostengünstigen Reaktionszeit auf veränderte Geschäftsbedingungen reagieren können. Dazu werden der (Wieder-) Einsatz und die Kopplung von (Web-) Services angestrebt. [KrBa05] (Web-) Services können automatisiert sein und für die jeweiligen Aktivitäten in einem Geschäftsprozess zur Verfügung gestellt werden. Auch bestehende Alt-Systeme 177 (engl. legacy systeme) können durch die Kapselung zu Services [vgl. Hess07] in SOA integriert werden. Erst die Unterstützung einzelner Aktivitäten bzw. Aktivitätsbündel in einem (Geschäfts-) Prozess durch verschiedene, flexibel austausch- und orchestrierbare Services [WebM07, S. 8] kommt dem Anspruch einer SOA nahe, jeglichen betriebswirtschaftlich sinnvollen Prozess unterstützen zu können [Hess07]. Der Einsatz serviceorientierter Architekturen bietet hier sinnvolle Ansätze, die Schnittstellenproblematik durch Einsatz von Konnektoren abzudecken. Dabei werden die 177 Der Begriff Altsystem (engl. legacy system) bezeichnet in der Wirtschaftsinformatik eine etablierte, historisch gewachsene Anwendung im Bereich Unternehmenssoftware. Legacy ist hierbei das englische Wort für Vermächtnis, Hinterlassenschaft, Erbschaft, auch Altlast. Aufruf unter

184 Operationalisierung der WPIM-Pipeline auszutauschenden Systeme nach außen gekapselt, indem eine Zwischenschicht aus verschiedenen Quellsystemen eine gemeinsame Schnittstelle betreibt [Lega08]. Um diese Unterstützung zu gewährleisten, ist es notwendig, Kenntnisse über die zu unterstützenden (Geschäfts-) Prozesse [vgl. Melz07] oder auch Innovationsprozesse zu generieren und zu nutzen. Weitere Anmerkungen zu SOA Referenzarchitekturen im [Anhang Kap. 7.1] Conclusio und Architekturauswahl Die aufgezeigten Architekturen entsprechen dem Stand der Technik. Produktive Informationssysteme in fertigenden Industrien, z. B. der Automobilindustrie und in der Luft- und Raumfahrt orientieren sich an diesen Systemarchitekturen. Gemäß den gesetzten Anforderungen, soll die Architektur des WPIM-Systems so gewählt werden, dass eine spätere Integration, Adaption und Erweiterung einfach möglich ist. Aus den vorgestellten Systemmodellen und Systemarchitekturen erfolgen nun Auswahl und Aufbau einer geeigneten Systemarchitektur für das WPIM-System. Gemäß einer Trade-off-Analyse setzen wir eine Sequenz von Argumenten an und erläutern die Entscheidung für die 3-Schichtarchitektur: Die 3-Schichtenarchitektur nach MVC ist ausreichend flexibel die Komplexität und die Anzahl der Schichten sowie Schnittstellen gegenüber dem 5-Schichtarchitekturmodell sind geringer. Zudem findet die 3-Schichtenarchitektur einen breiten Einsatz in der Praxis und es sind eine Vielzahl von Referenzimplementierungen verfügbar. Die 3-Schichtenarchitektur unterstützt ferner den Einsatz der Service-Orientierung, der in den letzten Jahren einen enormen Zulauf/Akzeptanz erfahren hat. Gerade bei (semantischen) Web-Applikationen erfreuen sich Architekturen nach SOA enormer Beliebtheit und sind gut an die Herausforderungen im Web angepasst. Die Implementierung des WPIM-Systems orientiert sich somit an der 3-Schichtenarchitektur nach MVC, in Kombination und Ergänzung mit Services der SOA. Die Architektur wird von nun an konsequent in der WPIM-Pipeline erprobt und weiterführend in der WPIM-Anwendung genutzt. 4.6 WPIM-System-Spezifikation Ziel ist es, unterstützende Dienste für die Benutzung der WPIM-Pipeline [vgl. Kap. 4.11] abzuleiten. Daher werden einem benutzungszentrierten Ansatz folgend, Anwendungsszenarien der Methode WPIM aufgegriffen und in konkrete Anwendungsfälle heruntergebrochen. Die Formalisierung der Anwendungsfälle erfolgt in UML. UML-Werkzeuge helfen, die Anwendungsfälle weiter in Dienste zu zerlegen und formal darzustellen. Somit können die Dienste für die spätere Implementierung vorbereitet werden, vgl. hierzu [Kap. 3.3 Anwendungsszenarien zur Spezifikation von Dienste] Spezifikationssprache Unified Modeling Language (UML) Die Unified Modeling Language (UML) ist eine der dominierenden Sprachen für die Modellierung von betrieblichen Anwendungs- bzw. Softwaresystemen [vgl. FoKe98]. Es folgt eine allgemeine Einführung zu Anwendungsfällen, eine Vorstellung der Spezifikations-, Formalisierungs- und Modellierungssprache Unified Modeling Language (UML). Zudem werden Werkzeuge zur Modellierung von Anwendungsfällen mit UML beleuchtet UML, Anwendungsfälle, Sichten und Diagrammtypen Die Unified Modeling Language (UML) ist eine Sammlung primärer grafischer 160

185 Operationalisierung der WPIM-Pipeline Beschreibungsmittel zur Modellierung von Softwaresystemen, die vor allem im Bereich der objektorientierten, werkzeuggestützten Softwareentwicklung eine starke Verbreitung gefunden hat [Burk97, FoKe98, Sütt01, Tabe06]. Aufgrund dieser Verbreitung und der Tatsache, dass es sich um einen Standard der Object Management Group 178 (OMG) handelt, wird UML in Teilen vorgestellt und speziell zur Modellierung von Anwendungsfällen (engl. use cases) für das Softwaresystem WPIM eingesetzt. Süttenbach gibt folgenden Überblick: UML bietet sechs verschiedene Sichten auf ein System und neun verschiedene visuelle Modellierungssprachen, um diese Sichten auszudrücken. Eine Sicht wird als Menge von Modellierungskonstrukten angesehen, die einen bestimmten Aspekt eines Systems beschreibt. [Sütt01, S. 187] Bei UML2 179 kommen noch weitere Diagramme hinzu, siehe dazu [http://www.uml.org/]. UML2 kennt zudem sieben Strukturdiagramme: das Klassendiagramm, das Kompositionsstrukturdiagramm, das Komponentendiagramm, das Verteilungsdiagramm, das Objektdiagramm, das Paketdiagramm und das Profildiagramm. Dazu kommen sieben Verhaltensdiagramme: das Aktivitätsdiagramm, das Anwendungsfalldiagramm, das Interaktionsübersichtsdiagramm, das Kommunikationsdiagramm, das Sequenzdiagramm, das Zeitverlaufsdiagramm und das Zustandsdiagramm. Exemplarisch stellen wir das Anwendungsfalldiagramm und das Verteilungsdiagramm vor. Vorab grundlegende Erläuterungen zu Anwendungsfällen: Anwendungsfälle wurden von Ivar Jacobson [Jaco92 in Burk97, S. 135] als Rahmen für den gesamten Software-Entwicklungszyklus eingeführt. Zusätzliche Umfänge die den Anwendungsfall überschreiten, können sofort identifiziert und abgegrenzt werden. Diese pragmatische Herangehensweise ist für Praxisprojekte außerordentlich gut geeignet. [Burk97, S. 135] Vorteile sind darin zu sehen, dass der Ausgangspunkt für Use Cases und deren Modellierung ein realer Prozess des Geschäftslebens ist. Des Weiteren legt der Use Case von Anbeginn des Projekts eine Hülle um alle Modelle, mit der er eine klare Zielausrichtung unumgänglich macht. [vgl. Burk97] Bei WPIM werden Anwendungsfälle in UML modelliert und formalisiert. Die UML-Anwendungsfall Sicht (auch Nutzfall oder engl. use case) entspricht der zu modellierenden Sicht für WPIM und wird stellvertretend für die voranstehenden Sichten vorgestellt. Die Anwendungsfallsicht beschreibt das Verhalten eines Systems aus der Sicht außerhalb des Systems stehender Aktoren. [Sütt01, S. 191] Diese Systemsicht wird häufig auch als sozio-technisches System bezeichnet. Berücksichtigt werden typischerweise Aktoren, das sind (menschliche) Benutzer des Systems. Grundsätzlich können Aktoren auch andere Systeme oder z. B. Agenten sein. Die Funktionalität, die sich dem Anwender bietet, wird 178 Die OMG Homepage UML2 exakter UML abgerufen

186 Operationalisierung der WPIM-Pipeline Anwendungsfall genannt. [Sütt01, S. 191] Im Use-Case-Diagramm werden menschliche Akteure als Strichmännchen dargestellt, sonstige Akteure als Rechtecke (gekennzeichnet mit <<keyword>>). Anwendungsfälle werden als Ellipsen [vgl. Tabe06, S. 362] repräsentiert. Verbindungen zwischen Akteuren und Anwendungsfällen bedeuten, dass der Akteur mit dem System bei den entsprechenden Anwendungsfällen interagiert. Zur Modellierung gibt Süttenbach eine Übersicht zu den verfügbaren Konzepten [Sütt01, S. 287 ff.]. Beispiele zu UML Anwendungsfällen finden sich in [Sütt01, S. 291; Tabe06, S. 362 ff.]. UML-Verteilungsdiagramme auch als Einsatzdiagramme oder Deployment-Diagramme bekannt, beschreiben die dynamische Zuordnung von Software-Komponenten auf Hardware- Einheiten, die auch als Knoten bezeichnet werden. Neben der dynamischen Zuordnung der Software-Komponenten auf Hardware-Einheiten werden die Kommunikationsverbindungen und Abhängigkeiten zwischen diesen Knoten beschrieben. Das Verteilungsdiagramm gehört zu den Diagrammen der statischen Modellierung 180. Die Verteilung kann die Installation, Konfiguration, die Bereitstellung oder Ausführung von Informationseinheiten umfassen. Die Notation kann Artefakte, Knoten, Einsatzspezifikation und Beziehungen zwischen den Knoten enthalten UML-Werkzeuge Es existiert eine Vielzahl von UML-Werkzeugen 182. Weitere Werkzeug-Übersichten zu UML und UML 2.0 Tools finden sich bei OOSE 183 sowie bei Jeckle 184. Nachstehend werden exemplarisch drei Werkzeuge vorgestellt: BOUML 185 Release ist ein UML-Ansatz für Programmierer. Bereits bei der grafischen Erstellung der Softwareprojekte müssen Parameter für die verschiedenen Programmiersprachen zur Erstellung des Sourcecodes mitgegeben werden (Bsp. Variablendeklarationen: Int, Enum, Enum_def,...). Alle UML-2.0-Diagramm-Typen finden Unterstützung. TAU 186 ist ein Logik-getriebener-Ansatz mit Unterstützung aller UML-2.0-Diagramme. Verbindungen zwischen Einzelkomponenten können direkt, ohne Kenntnisse zu den verwendeten Programmiersprachen logisch verknüpft werden. DIA 187 ist ein GTK+ 188 basiertes unter GNU lizenziertes Softwarewerkzeug zum Modellierung von Diagrammen. Zu Gnome 189 ist ein Tutorial verfügbar. Verwendet wird das UML-Plug-in UML Vers das im Download enthalten ist. DIA ist ein reines Zeichenprogramm zur grafischen Darstellung von Systemen auf Basis der UML-Notation. Die erstellten UML-Befehle konnten nicht nach Bouml Release portiert 180 UML Verteilungsdiagramm oder oder GTK+ ist ein Toolkit zur Erstellung von grafischen Benutzungsoberflächen. Unterstützt wird Cross-Plattform-Kompatibilität mit einer benutzungsfreundlichen API. GTK+ ist selbst in C geschrieben, kann gut mit Programmiersprachen wie C++, Python und C# genutzt und erweitert werden. GTK + ist lizenziert unter der GNU LGPL 2.1 dadurch wird die Entwicklung freier und proprietärer Software mit GTK + ermöglicht, ohne dass Lizenzgebühren oder Tantiemen entstehen

187 Operationalisierung der WPIM-Pipeline werden. Die Ausgabeformate von DIA in der Version erscheinen bei der vorliegenden Problemstellung als ungeeignet kein ausgegebenes Format von DIA kann durch Bouml eingelesen werden. Ab UML 2.0 ist es möglich, das Modell an Visio zu übergeben und die Diagramme fehlerfrei erstellen zu lassen. Dies geht auch mit dem kostenfrei verfügbaren DIA, doch DIA unterstützt nicht alle Diagrammtypen. DIA wurde genutzt, um die WPIM Use Cases sowie die WPIM-Systemarchitektur und die zugehörigen Module zu modellieren. DIA steht kostenfrei zur Verfügung WPIM Use Case modelliert in UML Eine Use Case Instanz ist die konkrete Realisierung je nach Anwendungsgebiet eines technischen oder betriebswirtschaftlichen Prozesses. [Burk97, S. 138] Für WPIM steht der benutzungszentrierte Ansatz der Modellierung durch Use Cases im Vordergrund. Gefolgt von Aspekten sozio-technischer und technischer Systemmodellierungen. Anwendungsfälle dienen zunächst für die Benutzung des Softwaresystems WPIM. Eine Instanz eines Use-Case-Typs beinhaltet ein konkretes Anwendungs-Szenario. Der Ansatz ist anwendungsgetrieben und stellt sicher, dass die Anforderungen direkt berücksichtigt werden. Abb. 4.15: Use Case Diagramm, erstellt mit Dia, in Anlehnung an [Tabe06, S. 362] Use Case Typen bei UML sind zwar bereits für die Beschreibung dynamischer Aspekte geeignet, formal aber noch stark deklarativ geprägt. Somit sind Use-Case-Instanzen ganz auf die Wirkung zur Laufzeit der fertigen Anwendung WPIM ausgerichtet. Besonders können dabei Vor- und Nachbedingungen i. S. von In- und Outputs berücksichtigt werden. Somit können auch Zeitbedingungen und Prioritäten modelliert werden. [vgl. Burk97, S. 139] Ausgehend von [Abb. 4.15] werden die Use Cases weiter verfeinert Entwicklung des WPIM-Systemmodells Zum Aufbau des WPIM-Systemmodells werden die getroffenen Spezifikationen aufgegriffen. Die Spezifikationen werden aus den Anforderungen an die Methode [Kap. 2.7] sowie aus der Definition des Modells [Kap. 3] abgeleitet. Die zentralen Spezifikationen sind teilweise weiter gefasst. Sie gelten für das WPIM-Systemmodell, können aber durchaus auch weitere Umfänge des entstehenden Softwaresystems betreffen. Das System ist so auszulegen, dass es mit einer Serviceorientierten Architektur korreliert, ein modularer Aufbau des strukturellen Systemmodells unterstützt wird, eine Aufteilung in Module und Dienste (die auf diese Module ausgerichtet sind) erfolgt, Werkzeuge aus den Diensten komponiert werden können. 163

188 Operationalisierung der WPIM-Pipeline Insbesondere aus technischer Sicht wird auf die Implementierung der Dienste 190 (engl. services) eingegangen. Im Folgenden wird unterschieden in Basisdienste, die den Kern der WPIM- Implementierung darstellen und darüber hinaus fortgeschrittene Dienste (z. B. visualisierende Dienste), die speziell auf Anwendergruppen zugeschnitten sind und unabhängig von der Basis- Implementierung weiterentwickelt werden können Aufbau des WPIM-Systems Das Systemmodell zum WPIM-System beschreibt die Struktur, präziser die Systemgegenstände (auch Module) und den Aufbau des Systems. Die Systemgegenstände des WPIM-Systems werden in einem Schichtenmodell angeordnet [Abb. 4.16], das einem hierarchischen Bottom-up- Ansatz nachempfunden ist. Die unterste Schicht bildet eine Infrastruktur, gefolgt von einer Anwendungsmiddleware, auf oberster Schicht sind Werkzeuge angesetzt. Das Systemmodell repräsentiert auf den drei angesprochenen Schichten die Daten, das Wissen sowie die Ressourcen im WPIM-System. Die Unterteilung in die drei Schichten folgt einem Modulansatz. Dadurch wird die Austauschbarkeit einzelner Module sichergestellt und somit die Flexibilität des entstehenden WPIM-Prototyps erhöht. Abb. 4.16: Konzeptueller Aufbau des WPIM-Systems In der mittleren Schicht [vgl. Abb. 4.16] der Controllerschicht (engl. application logic) findet die logische Verarbeitung der Daten statt. Je nach Orientierung und Ausrichtung der Programmiersprache handelt es sich bei einer prozessorientierten (PO) Vorgehensweise um Funktionen, bei der Objektorientierung (OO) um Methoden und bei einer Serviceorientierten Systemarchitektur (SOA) um Dienste. Das Softwarewerkzeug WPIM wird nach dem Model-View-Controller (MVC) Architekturmodell aufgebaut. Dabei werden drei unabhängige Komponenten erstellt: Das Datenmodell, die Steuerung oder auch engl. application Logic sowie die Schnittstelle zu den Nutzern, auch Präsentation, Ansicht oder engl. View genannt. Diese drei Komponenten werden für das im Rahmen der Methode WPIM entstehende Softwarewerkzeug im Anschluss beleuchtet. Ziel dieses MVC-Architekturmodells ist ein flexibles Programmdesign, um spätere Änderungen oder Erweiterungen einfach zu halten und die Wiederverwendbarkeit der einzelnen Komponenten zu ermöglichen [Gamm04]. Zudem ermöglicht MVC mehrere Ansichten desselben Datensatzes, dies wird meist als sog. Model-Delegate 191 realisiert [Knau04]. 190 Im Folgenden wird von Services im Rahmen einer Serviceorientierten Architektur (SOA) berichtet. Objekt- und Funktions-orientierte Ansätze finden in der Modellierung und Programmierung Betrachtung. 191 Model-Delegate is a variation of the Model View Controller (MVC) pattern. Two of the three responsibilities 164

189 Operationalisierung der WPIM-Pipeline WPIM Modell konzeptuelle Infrastruktur WPIM betrachtet verschiedene Datenquellen bzw. Datenmodelle zu Ressourcen wie Prozessen, Experten, Dokumenten und insbesondere Patenten [LVKH07, LVKH08, LVKH08a, LVKH09, LVKH09a]. Diese Informations- und Patent-Ressourcen können sowohl Datenbanken als auch Ontologien, also die semantische Beschreibung von Datenbeständen sein. Das benötigte Wissen liegt in unterschiedlichen Datenformaten vor. Abb. 4.17: Konzeptuelle Repräsentation des WPIM-Datenmodells Um Wissen nutzbar zu machen und dem Innovationsprozess zuzuführen, müssen informationstechnische Wege (z. B. Dienste) auf einer geeigneten WPIM-Infrastruktur gefunden werden, um diese Information gezielt zu extrahieren bzw. zu bündeln. In [Abb. 4.17] wird XML als das zentrale Datenmodell zur Strukturierung und Verwaltung von Daten eingeführt. Durch die gezielte Annotation des Innovationsprozesses mit Information aus der Eingabemaske für Experten entsteht aus Dokumentations- und Wissenssicht ein Mehrwert. Für den Zugriff und die Manipulation der Datenbestände in XML oder Datenbanken sind existente APIs zu nutzen. Das XML-Format dient zur Speicherung der Daten. Bei der Verwendung von XML wird für alle Aktivitäten ein festes Schema vorgegeben, das über die Eingabemaske befüllt wird. Bei semantischer Erweiterung wird das Schema bzw. die Ontologie um die Umfänge von RDF oder OWL ergänzt Deklaratives Datenmodell Die Vererbungshierarchie von RDF und RDFS wurde für die Implementierung der WPIM- Anwendung übernommen, um die semantischen Vererbungen (hier speziell von Hierarchien) darstellen zu können. Insbesondere wird die Vererbung von Klassen auf Unterklassen mittels der Relation subclassof vorgestellt. In den Abbildungen [Abb und Abb. 4.19] wird u. a. die grundlegende Unterscheidung von RDF-Schema und RDF-Data dargestellt. Mittels RDF- Schema wird eine Schema-Datei beschrieben, die den Aufbau von RDF vorgibt. Mit RDF-Data werden konkrete Instanzen von Ressourcen beschrieben. from MVC, namely the view and controller part, are brought together in a so-called User Interface (UI) Delegate abgerufen

190 Operationalisierung der WPIM-Pipeline Abb. 4.18: Digitale Objekte in der Aufgabenteilung von RDF und RDFS [vgl. Zapo02] Das Vererbungsschema mit konkreten Instanzen ist in [Abb. 4.19] dargestellt. Die type Beziehung stellt den Übergang von Klassen (RDF Schema) auf konkrete Instanzen (RDF Data) dar. Abb. 4.19: RDF-Schema mit Vokabular und Klassenhierarchie [vgl. Zapo02] In Anlehnung an [Zapo02]: Für das Property IstVerantwortlich wird die Domäne aller Mitarbeiter mit dem Wertebereich (engl. range) aller Aktivitäten verknüpft. Auf Instanzenebene (RDF-Data) wird die Ressource, genauer die Person namens Vogel mit der Ressource, genauer der Aktivität Freigabe durch die Relation IstVerantwortlich verknüpft Technisches Datenmodell Aus der Sicht der konzeptionellen Architektur auf den Prototyp verkörpert die Datenhaltung und das damit verbundene konzeptuelle Datenmodell die unterste Schicht in dem gewählten Bottomup-Ansatz. Das konzeptuelle Datenmodell betrachtet die zu integrierenden Dateiformate der Wissensressourcen sowie die zur persistenten Speicherung vorgesehenen Dateiformate und Datenbanken [KaBM08]. Das Datenmodell muss der Anwendungsmiddleware ermöglichen, mit Basisdiensten Daten zu speichern, zu extrahieren und zu manipulieren. Diese Daten-Basisdienste müssen den Import und Export der Daten sicherstellen. Das Datenmodell hat die Aufgabe, die Integration von implizitem und explizitem Wissen, Information und Daten aus unterschiedlichen (in und außerhalb des Unternehmens liegenden) Quellen (wie z. B. Datenspeichern und Informationssystemen) zu unterstützen. Dazu definieren wir Schnittstellen und unterstützen diese durch geeignete Dienste. Daten im XML-Format sollen mit zusätzlichem Wissen (z. B. aus sozialen Netzwerken, z. B. im XML- oder HTML-Format) annotiert werden. Zudem werden Ressourcen aus dem Intra- und Internet eingebunden, wie z. B. Design- und Engineering-Daten der fertigenden Industrien. Auch sollen die verfügbaren Daten mit Strukturwissen (z. B. aus XML-Taxonomien oder RDF-, RDFS-, OWL-Ontologien) verknüpft werden. Die (manuell oder automatisch) angereicherten Daten sind einer Speicherung in einem Datenspeicher zu 166

191 Operationalisierung der WPIM-Pipeline unterziehen, um die Verfügbarkeit und persistente Speicherung zu gewährleisten. Das Datenmodell der WPIM- Anwendung unterstützt die von [vgl. KaBM08] vorgeschlagenen Dienste Datenspeicherung, Datenzugriff und Datenintegration. Abb. 4.20: Ausschnitt des WPIM-Datenmodells tabellarisch dargestellt [vgl. Zapo02] In [Abb. 4.20] ist ein Ausschnitt des WPIM-Datenmodells dargestellt. Vorgestellt werden Klassen sowie SubKlassen, Properties sowie Domain- und Range-Zuordnungen. Anmerkung: Das Property istverantwortlich gehört nicht zum Basisumfang von RDF/RDFS sondern wurde über wpim:istverantwortlich definiert und ist durch einen URI eindeutig identifizier- und referenzierbar WPIM-Controller konzeptuelle Anwendungsmiddleware Zuzüglich zu den Methoden von WPIM entsteht ein Softwarewerkzeug, das deren Einsatz und Anwendung unterstützt. Dieses Werkzeug hat zum Ziel, den Anwendern die Modellierung und die Annotation von Innovationsprozessen zu erleichtern. Nach der Abbildung von Prozessen werden die Experten über Views aufgefordert, relevantes Wissen an die Innovationsprozesse zu knüpfen. Dabei wird systematisch Information zu den Aktivitäten gesammelt und im Datenmodell zugeordnet. In mehreren Detaillierungs-Schritten können die Experten immer spezifischeres Wissen und Erfahrungen zu den Innovationsprozessen ablegen. Entscheidend ist, dass die WPIM-Applikation automatisiert den Prozess annotiert und im RDF-/XML-Format maschinenlesbar aufbereitet. Somit können Wissen über Prozesse sowie Attribute zu Ressourcen zukünftig automatisiert im Intra- bzw. Internet veröffentlicht werden. Das Wissen wird in doppelter Hinsicht integriert. Dies geschieht zunächst für den Menschen gut ersichtlich (über die vier Wissensebenen hinweg strukturiert) und an Prozesse geknüpft. Zudem geschieht dies auch noch maschinen-verständlich durch die Verwendung von RDF und dem eigenen WPIM- Vokabular. Semantische Suchen über annotierte Innovationsprozesse werden folglich durch WPIM Initial etabliert und unterstützt Core Infrastruktur des WPIM-Prototyps Die Basisinfrastruktur von WPIM stellt die grundlegende Bearbeitung von Prozessmodellen im XML-Format sicher. Die Extraktion der Prozesselemente (Prozess, Pool, Aktivität und Aufgabe) erfolgt mittels der Exportfunktion des Softwarewerkzeugs Business Process Visual Architect (BPVA) in der Version 2.0. Die Extraktion der Konzepte wird mittels dem PHP-Skript (Test.php) vorgenommen und orientiert sich an der BPVA spezifischen DTD sowie der BPVA- Notation und Tag-Benennung, z. B. für eine Aktivität mit der Benennung erste_aktivität wird das Tag <BPTask>erste_Aktivität</BPTask> verwendet. Als Ergebnis liefert das erstellte Skript die Ergebnisdatei Konzepte.txt und Konzepte.xml, die den (wissens-) strukturrelevanten Umfang (die Konzepte) aus der weitaus umfangreichern XML-Datei extrahiert. Bei der Extraktion werden die Tags in WPIM spezifische Tags überführt und <BPTask> wird an das Konzept 167

192 Operationalisierung der WPIM-Pipeline Aktivität angepasst und in <Aktivität> überführt. Neben den Konzepten werden auch die Instanzen übernommen. Die Bezeichnungen sowie die Hierarchien werden beibehalten. Die unübersichtliche Ausgangs-Datei wird auf den für WPIM relevanten Umfang reduziert und in einem Datenspeicher abgelegt Controller mit Services In [Kap. 3] sind Konzepte definiert und spezifiziert, die in [Kap. 4] in Klassen mit Instanzen bzw. in digitale Objekte überführt werden. Die Kernfunktion von WPIM ist darin zu sehen, dass die Prozess-Instanzen mit den Instanzen von Profildaten von Personen und Meta-Daten zu Dokumenten in Verbindung gesetzt werden. Dazu werden reale, am Innovationsprozess beteiligte Personen über ein PHP-Skript in Verbindung mit einem HTML-Formular gebeten, sich selbst konkrete Aktivitäten, Pools und Prozesse zuzuordnen. Dies geschieht in der Form, dass sich eine Person selbst (in ihrem eigenen Online-Profil) über ein Select-Menü Instanzen der Klassen Aktivität, Pool oder Prozess zuweisen kann und zudem über ein weiteres Select Menü den Grad ihrer Expertise (IstMitarbeiter, IstExperte, HatVerantwortung) angeben kann. Auch können Personen konkrete Instanzen von Dokumenten zu Aktivitäten zuordnen. Diese Ressourcen und Relationen zu einer Aktivität werden sodann über das PHP-Skript an den Server übermittelt und in eine MySQL-Datenbank gespeichert. Vor dem Absenden des erweiterten Profils können client-seitig z. B. JavaSkript Routinen gestartet werden, welche die Eingaben auf Konsistenz, Vollständigkeit und Syntax überprüfen Controller mit Semantik-Services Als semantische Kernfunktion wird unterstützt, dass die Daten zu den Prozess-Objekten aus der Datenbank extrahiert werden und in eine RDF-/XML-Notation überführt werden. Die Ausdrucksmächtigkeit von OWL-DL darf dabei nicht überschritten werden. Besonders relevant ist hierbei die semantische Beziehung SubClassOf, die Hierarchien zwischen den Klassen und insbesondere auch den Instanzen von (Prozess, Pool, Aktivität) unterstützt. Semantische Relationen zwischen den Klassen und Instanzen (Prozess, Pool, Aktivität) und den Objekten Person und Dokument können durch das spezielle WPIM-Vokabular 192 eindeutig referenziert werden. Den Kern der WPIM-Anwendung bilden die Services der Contoller Ebene. Deren Funktionalität besteht darin, die Prozess-Objekte aus XML zu extrahieren, mit Instanzen von Personen und Dokumenten zu verknüpft, persistent zu speichern und in RDF/XML zu serialisieren WPIM Views konzeptuelle Benutzungsschnittstelle Der Begriff der Benutzungsschnittstelle ist dem Begriff der Benutzerschnittstelle vorzuziehen. Gerade im Rahmen des Semantic Web sind zukünftig weitere Software-Agenten zu erwarten. Die Begrifflichkeit Benutzungsschnittstelle steht maschinellen Nutzern und Software-Agenten weitaus offener gegenüber. Deshalb verfolgen wir neben der wissensbasierten und prozessorientierten Sichtweise einen benutzungszentrierten Aufbau der Benutzungsschnittstelle. Dazu fließen die Anforderungen an die WPIM-Methoden sowie die Vorgaben der Zielgruppe der Anwender 193 belegt in der Studie [Kret12] als Überlegungen ein. Das WPIM-System, mit der menschlich-wissensbasierten Sichtweise und dem computer-prozessorientierten Vorgehen erhält eine praxistaugliche, intuitive und webbasierte Präsentation. 192 Abrufbar unter Hierzu gab es Gespräche mit Partnern aus der Industrie wie BMW, FESTO, PHILIPS und ALTRAN. 168

193 Operationalisierung der WPIM-Pipeline Abb. 4.21: Multiple Präsentationssicht im WPIM-System Die [Abb. 4.21] zeigt die konzeptuellen multiplen Views im WPIM-System mit vier Views. Der View mit [Markierung (1)] dient der Graph- [Trie07] oder Prozessvisualisierung, der View mit [Markierung (2)] stellt in einer grafischen Benutzungsoberfläche (engl. Graphical User Interface, GUI) Werkzeuge zur Prozessmodellierung bereit. In [Abb. 4.21] ist exemplarisch ein Innovationsprozess mit fünf Prozessbausteinen dargestellt. In der Eingabemaske [Markierung (3)] werden beschreibende Eingaben, hier zum Prozessbaustein Produktentwicklung getroffen. Über den Details-Button [Markierung (4)] kann ein weiteres Eingabefenster geöffnet werden, über das weiteres Wissen zum selektierten Prozessbaustein abgefragt und eingegeben werden kann View mit Such- und Visualisierungs-Services Der View wird bei WPIM als Benutzungsschnittstelle umgesetzt. Dazu werden Werkzeuge über der erweiterten Infrastruktur im Folgenden als höhere Dienste, z. B. semantische Dienste, implementiert. Betrachtet werden Werkzeuge als Kombination und vollendete Zusammenführung von Diensten. Durch die Etablierung von Werkzeugen erweitern wir die technische dienst-orientierte Sicht auf das WPIM-System um die Aspekte der Anwendbarkeit und Benutzung hin zum sozio-technischen System. Die Überlegungen zu diesen höheren Diensten folgen der Dienste-Orientierung der SOA [vgl. Kap Serviceorientierte Architektur (SOA)]. 4.7 Entwicklung der technischen WPIM-Systemarchitektur In diesem Abschnitt wird sukzessive die WPIM-Systemarchitektur präzisiert und implementiert. Dazu werden die statischen Aspekte der Module um dynamische Interaktionen ergänzt. Mit dem Begriff IT-Architektur werden alle statischen und dynamischen Aspekte der IT in einer Organisation bezeichnet. Besonders wird auf die funktionalen Aspekte, Schnittstellen und Dienste eingegangen. Architekturen legen die Grundstrukturen fest und definiert Regeln, die das dynamische Zusammenspiel aller Komponenten koordinieren. Für das WPIM-System starten wir mit den drei Modulen aus dem MVC-Architekturmodell und ergänzen diese um Dienste (engl. services) nach der SOA-Architektur Ausgangspunkt: WPIM als Black-Box Modell Als Ausgangspunkt zur Entwicklung des WPIM-Systems verwenden wir einen Black-Box Als Black Box bezeichnet man in Kybernetik und 169

194 Operationalisierung der WPIM-Pipeline Ansatz. Dabei finden lediglich Eingaben (engl. input) und Ausgaben (engl. output) Betrachtung. Der Black-Box-Ansatz ist Teil der Systemtheorie 195. Ziel der Anwendung im Sinne eines Outputs ist es, einen annotierten Innovationsprozess (soweit möglich automatisiert) zu generieren. Somit ist der WPIM-Ansatz getrieben durch ein Backtracking. Das Ziel der Anwendung steht fest, die Inputgrößen können definiert werden und eine geeignete Verarbeitung der Inputs muss durch das Black-Box-System gewährleistet werden. Nur so kann der gewünschte Output des Systems generiert werden. Nachstehend als Ausgangspunkt der Systementwicklung, die Input-Output-Darstellung des WPIM-Systems als Black-Box. Abb. 4.22: WPIM-System als Black-Box WPIM-System und verbundene Anwendungen Um die Anwendung WPIM zu entwickeln, haben wir Rahmenwerke untersucht, die hinsichtlich semantischer Anwendungen eine vorbildliche Rolle einnehmen. Rahmenwerken zur Erstellung von Architekturen zu Softwaresystemen mit Fokus auf semantische Umfänge bieten VIKEF 196 [vgl. VIKE06] und bei SHAMAN 197 insbesondere das zweite Teilprojekt. SHAMAN geht vertiefend auf die Harmonisierung und Extraktion von Inhalten sowie deren semantische Aufbereitung und Anreicherung ein. An dieser Vorgehensweise orientieren sich die fortgeschrittenen (z. B. semantischen) Dienste beim WPIM-System, die sowohl die Annotation über als auch die semantischen Suche innerhalb der Innovationsprozesse unterstützen. Systemtheorie ein (möglicherweise sehr komplexes) System, von welchem im gegebenen Zusammenhang nur das äußere Verhalten betrachtet werden soll. Die innere Struktur mag bekannt sein. Man beschränkt sich bei der Untersuchung und Beschreibung auf die Messung der Input-Output-Beziehungen. 195 Die Systemtheorie ist ein interdisziplinäres Erkenntnismodell, in dem Systeme zur Beschreibung und Erklärung unterschiedlich komplexer Phänomene herangezogen werden. Die Analyse von Strukturen und Funktionen soll häufig Vorhersagen über das Systemverhalten erlauben VIKEF Im Rahmen des EU-geförderten Projektes SHAMAN (Sustaining Heritage Access through MultivalentArchiviNg) wird ein digitales Archivierungssystem der nächsten Generation unter Einbeziehung von grid-basierten, multivalenten und semantischen Methoden entwickelt. Im Rahmen des Projektes werden dabei insbesondere Aspekte der Langfrist-Archivierung von Publikationen (wissenschaftlicher Publikations- und Bibliotheksbereich sowie Regierungsarchive), von industriellen Entwicklungs- und Engineering-Daten sowie von wissenschaftlichen Daten als Applikationsgebiete untersucht. Mehr unter

195 Operationalisierung der WPIM-Pipeline Abb. 4.23: Modell WPIM-System und verbundene Anwendungen Zunächst wird die Anwendung WPIM von unterstützenden Anwendungen und visualisierenden Anwendungen abgegrenzt. Im Folgenden entwickeln und verfeinern wir die WPIM-Anwendung weiter MVC-Module des WPIM-Systems Das WPIM-System besteht aus der WPIM-Anwendung und unterstützenden Anwendungen. Die WPIM-Anwendung selbst wird in [Abb. 4.24] dem MVC-Ansatz folgend verfeinert und in weitere Systembestandteile zerlegt. Abb. 4.24: Konzeptueller Aufbau des WPIM-Systems Nachfolgend in [Abb. 4.25] wird der Aufbau des WPIM-Systems modelliert in UML dargestellt. Abgebildet wird die WPIM-Anwendung mit verbundenen Anwendungen, 198 die sich gemeinsam zum WPIM-System ergänzen farblich getrennt, der Umfang der WPIM-Anwendung abgegrenzt von den unterstützenden und den visualisierenden Anwendungen. Der WPIM- Umfang, in [Abb. 4.25] mittig dargestellt, wird in die drei Module Benutzungsschnittstelle, Anwendungsmiddleware und Datenhaltung gekapselt. Abb. 4.25: UML-Modell zum WPIM-System Die Modellierung in UML unterstützt eine weitere Verfeinerung und die spätere softwaretechnische Implementierung. 198 Zu verbundenen Anwendungen zählen unterstützende Anwendungen wie Werkzeuge und Entwicklungsumgebungen sowie visualisierende Anwendungen, z. B. Browser. Weiter gefasst sind neben verbundenen Anwendungen auch genutzte Services und Web-Services einzubeziehen. 171

196 Operationalisierung der WPIM-Pipeline Software-Module und Software-Komponenten zum WPIM-System In [Abb. 4.26] werden der Kern des WPIM-Systems (also die WPIM-Anwendung) als auch die begleitenden Anwendungen in Module und Software-Komponenten heruntergebrochen. Abb. 4.26: UML-Darstellung des WPIM-Systems ohne Interaktion Eine Interaktion der Komponenten und Module, wie auch zwischen Anwendungen, wird explizit gefordert. Eine Realisierung der Interaktionen wird in Diensten und Werkzeugen realisiert. Im Rahmen der vom Autor betreuten Masterarbeit von [Küsg11] wurde die Programmarchitektur dergestalt mit Technologien entwickelt: Abb. 4.27: WPIM-Programmarchitektur mit Technologien nach [Küsg11] Die Programmarchitektur in [Abb. 4.27: WPIM-Programmarchitektur mit Technologien nach [Küsg11] wird im weiteren Verlauf der Arbeit zum WPIM-System verfeinert. 172

197 Operationalisierung der WPIM-Pipeline Verfeinerung und Interaktion des WPIM-Systems [Abb. 4.28] zeigt die Module und Komponenten sowie die eingesetzten Technologien und Daten-Austauschformate. Hierbei wurden auch Aspekte der Daten und Schema-Verarbeitung berücksichtigt. Insbesondere wird auf die Interaktion sowie den Datenaustausch im Sinne einer Pipeline eingegangen, um im weiteren Verlauf der Arbeit einen durchgängigen Datenfluss zwischen verbundenen Anwendungen und der WPIM-Anwendung sicherzustellen. Abb. 4.28: Datenfluss und Interaktion des technischen WPIM-Systems Die Modellierung der Architektur, also der strukturelle Aufbau (Struktur) der WPIM- Systemarchitektur ist damit abgeschlossen. Die Interaktion (Verhalten) wird in Dienste unterteilt. Die Dienste folgen einem Input-Output getriebenen Aufbau. Aufbauend auf dem Zusammenspiel von Struktur und Verhalten werden die Methoden WPIM als softwaretechnisches System WPIM prototypisch, die sog. WPIM-Pipeline, implementiert Conclusio und Ausblick An dieser Stelle möchten wir einen Ausblick auf den Umgang mit Views, die Benutzung des Systems und auf die Werkzeuge im WPIM-System geben. Im sozio-technischen System WPIM sollen den Benutzern (oder auch Agenten) Werkzeuge über die Benutzungsschnittstelle zur Verfügung gestellt werden. Denn im sozio-technische System WPIM nimmt die Interaktion und somit die Benutzungsschnittstelle zwischen Mensch und Maschine eine erfolgskritische Rolle ein. Bisher werden WPIM-Model, WPIM-Controller und WPIM-View strukturell unabhängig voneinander vorgestellt. Es ist bereits jetzt zu erkennen, dass es zwischen den drei Modulen zu Interaktionen kommen muss, um die volle Leistungsfähigkeit der WPIM-Systems zu entfalten. Die Vorstellung der strukturellen Umfänge des WPIM-Systems ist abgeschlossen. Im weiteren Verlauf der Arbeit wird auf das Verhalten, die Interaktion und die verarbeitenden Methoden und Dienste des WPIM-Systems eingegangen. Für die WPIM-Pipeline [vgl. Kap. 4.11] und die entstehende WPIM-Anwendung wird neben der Interaktion und der Implementierung von WPIM- Diensten die Nutzung einer Serviceorientierten Systemarchitektur (SOA) angestrebt. 173

198 Operationalisierung der WPIM-Pipeline 4.8 WPIM-Interaktion auf einer SOA mit Diensten Die entwickelten Methoden WPIM soll durch Services im WPIM-System implementiert und die Interaktion der Anwendungen, Module und Komponenten ermöglichen. Diese Services werden entsprechend der beschriebenen Systemarchitektur unterteilt in: Basisdienste der Infrastruktur, fortgeschrittene Dienste, u. a. semantische Dienste der Anwendungsmiddleware und Dienste der Visualisierung auf der Benutzungsschnittstelle. Die Dienste können sowohl als WPIM-Pipeline geordnet aufgebaut werden oder zu Werkzeugen aus den Diensten komponiert werden. Hieran wird zudem der Übergang, von der technischsystemischen Sicht der WPIM-Pipeline, hin zur benutzungs-orientierten Sicht mit Werkzeugen, also dem sozio-technischen WPIM-System verdeutlicht SOA zur Operationalisierung der WPIM-Dienste Die Serviceorientierte Architektur (SOA) zum Systemmodell beschreibt das Verhalten des Softwaresystems WPIM. Dazu werden die Dienste (engl. Services) beschrieben, um die Funktionalität des Systems zu beschreiben. Zur Strukturierung und dem modularen Aufbau der Systemarchitektur folgend wird der strukturelle, dreischichtige Aufbau der Systemgegenstände herangezogen. Des Weiteren werden die drei Schichten des WPIM-Systemmodells beschrieben. Die systemtechnischen Schichten bauen aufeinander auf. Die Strukturierung erfolgt nach den Bestandteilen der systemtechnischen Schichten, den darauf laufenden Diensten sowie den Ergebnissen der Dienste. Dienste 199 werden gleichbedeutend mit den engl. Services verwendet und folgen auch dem Ansatz der SOA. Abb. 4.29: Dienste in der serviceorientierten Architektur bei WPIM Der Infrastruktur werden Basisdienste, der Anwendungsmiddleware fortgeschrittene, u. a. semantische Dienste zugeordnet und als Werkzeuge werden u. a. Dienste der Visualisierung den Benutzern zur Hand gegeben. Neben der natürlich sprachlichen, konzeptuellen Beschreibung der Dienste wird eine weitestgehende Formalisierung bzw. eine semi-formale Beschreibung vorgenommen. Durch diese Formalisierung wird eine Umsetzung der Dienste im Sinne einer mathematischen Beschreibung vorbereitet, um softwaretechnische Implementierungen zu ermöglichen. An dieser Stelle ist anzumerken, dass das beschriebene Modell und die zugehörigen Dienste auf eine zukünftige Implementierung ausgelegt sind, bisher jedoch bewusst losgelöst von einer konkreten Implementierung beschrieben sind, um zukünftigen unterschiedlichen Implementierungen (z. B. verschiede Klassen von Algorithmen) offen zu 199 Dienste auf konzeptionellen Ebenen werden auch als Methoden bezeichnet. 174

199 Operationalisierung der WPIM-Pipeline begegnen. Die Basisdienste bauen aufeinander auf. Dienste folgen der semi-formalen, tabellarischen Beschreibung in [Tab. 4.2]: [Dienst, Typ, Input, Funktionsweise, Ziel, Ergebnisdatei] Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Name des Dienstes [B H V] Diensttyp [basis höherer visueller] Eingabedatei Methode, mathematische Vorgehensweise, Algorithmus Verfolgtes Ziel, Aktivität Outputdatei, Ergebnis des Dienstes D# In# D#[In#; Out#] Out# Out# Tab. 4.2: Beschreibungsrahmen zur Formalisierung von Diensten Ein strukturierter Zusammenhang kann über Input-Output Relationen hergestellt werden. Nach der Bearbeitung der Inputs in einem Dienst wird der erzeugte Output den nachstehenden Diensten als Input-Datei zur Verfügung gestellt. Durch die Verknüpfung der Basisdienste werden die Inhalte einer Annotation unterzogen und die konzeptuelle WPIM-Pipeline systematisch aufgebaut. Unter (Dienst-) Typ werden in [Tab. 4.2] drei Ausprägungen unterschieden, basis (B), höhere (H) und visuelle (V) Dienste. Basisdienste ergänzen sich zur WPIM-Pipeline. Diese sind nummeriert um eine Reihenfolge bzw. einen groben Programmablauf vorzugeben. Höhere Dienste, z. B. semantische oder visualisierende Dienste, können optional verwendet werden Basisdienste auf der Infrastruktur Auf der Infrastruktur (engl. core infrastructure) werden Basisdienste (auch Systemfunktionen oder Basisfunktionen) definiert, die im Sinne der WPIM-Pipeline eine Werkbank mit verschiedenen Werkzeugen (engl. Workbench) darstellen. Prozessdatei/Prozessmodell: Dieser Dienst speichert die Musterdatei bzw. das Prozessmodell als.prj-datei ab. Ziel ist es, das Prozessmodell bei zukünftigen Innovationen erneut verwenden zu können. Die sog. Prozessdatei soll dazu bei zukünftigen Innovationen instanziiert werden. Die Wiederverwendung bezieht strukturelle Änderungen des Prozessmodells und auch inhaltliche Änderungen und Erweiterungen der Prozessphasen und Prozesselemente mit ein. Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Ablage der Basisdienst Projekt.prj Prozess-Datei Modell in BEPL; Prozess- und Struktur-wissen Speichern des Prozessmodells im BPVA 200 Datenformat.prj Wiederverwendung und spätere Instanziierung B1 start B1[In1; Out1] Out1 Tab. 4.3: Dienst Ablage der Muster Datei Import/Export: Der Dienst Export nach XML (Export-Dienst im Werkzeug BusinessProcess VisualArchitect, BPVA) öffnet und liest die XML-Repräsentation eines Prozessmodells ein. Eine Überführung und vollständige Übergabe aus der.prj-datei in die XML-Notation wird vollzogen. Als Ergebnis entsteht eine XML-Repräsentation des Prozessmodells. 200 BusinessProcess VisualArchitect. 175

200 Operationalisierung der WPIM-Pipeline Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Export Basisdienst Modell in BPVA; Prozess- und Struktur-wissen Speichern des Prozessmodells in der XML- Repräsentation. Prozess repräsentiert im XML- Format Projekt.xml B2 Start Out1 B2[In2; Out2] Out2 Tab. 4.4: Dienst XML-Export Prozessrepräsentation und Extraktion der Instanzen: Mit dem Dienst Test.php werden die Instanzen aus der XML-Datei (in die Datei Prozess.xml) extrahiert. Verfolgt werden die Ziele der Extraktion, der Instanzen und Klassen, Bildung von Klassen-Hierarchien zwischen den Klassen (z. B. Prozess, Pool, Aktivitäten). Dies erfolgt durch das PHP-Skript in Verbindung mit Xpath. Test.php erwirkt die Speicherung in den Dateien Konzepte.txt, Konzepte.xml und auch als Konzepte.html mit einem Select-Menü zur Auswahl der Instanzen. Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Extraktion Basisdienst Projekt.prj der Instanzen Projekt.xml 176 Extrahiert die Instanzen der Klassen aus der.prj Datei Instanzen und Klassen extrahiert B3 Out2 B3[In3; Out3] Out3 Tab. 4.5: Dienst Extraktion der Konzepte Prozess.xml Prozess.txt Prozess.html Social Netzwerk Dienst und Expertennetzwerk: Benutzer des WPIM-Systems hinterlegen personenbezogene Daten über ein HTML/PHP-Formular über die webbasierte Eingabemaske E2E.htm. Zudem werden weitere Statusdaten der Experten hinterlegt. Für jeden Benutzer entsteht ein eigenes Profil, der File-Name enthält den Namen des Benutzers name.html und name.txt. Neben der Bereitstellung von Daten durch den Benutzer sollen zukünftig auch bestehende Profildaten z. B. aus sozialen Netzwerken über APIs wie OpenSocial oder Facebook genutzt werden. Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Expertenkontakt Basisdienst Personen ID, semantische Anfrage (engl. query) Kontaktdaten erfassen und mit Aktivitäten (Instanzen) relational verbinden Kontakt- u. Personendaten, Vertreter o. Vorgesetzte finden B4 Out3 B4[In4; Out4] Out4 Tab. 4.6: Dienst Expertenkontakt Profil.html Orga.html name.html name.txt Dokumente integrieren: Der Dienst unterstützt die Integration von innovations- und prozessrelevanten Dokumenten in das Prozessmodell. Dateien können direkt oder auch per Link/Referenz hinterlegt werden. Der Dienst unterstützt die Integration von Dateien unabhängig vom Dateityp oder Format. Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Dokumente Basisdienst Final.html integrieren Dokument Name oder Link Dokumente sowie Links erfassen und an Prozessinstanz knüpfen Prozesse mit Dokumenten aufwerten B5 Out4 B5[In5; Out5] Out5

201 Operationalisierung der WPIM-Pipeline Tab. 4.7: Dienst Dokumente integrieren Datensicherung: Der Dienst dient zur persistenten Speicherung der zusammengetragenen Daten, u. a. den Prozess-, Personen- und Wissensressourcen sowie dem expliziten Wissen in Dokumenten. Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Datenspeicher Basisdienst WPIM.DB ung XML, Ressoucen, Formular-, Modell- und Prozessdaten Speicherung des erfassten Wissens in einem Datenspeicher Speicherung der verfügbaren Daten B6 Out5 B6[In6; Out6] Out6 Tab. 4.8: Dienst Datenspeicherung Die WPIM-Pipeline kann als Verknüpfung der genannten Basisdienste interpretiert werden. Aus Prozesssicht liefert der Output eines Dienstes den Input für den nachgelagerten Dienst. Im Folgenden wird exemplarisch die Beschreibung zum Dienst D3 und der Übergang von Dienst D3 auf Dienst D4 beleuchtet. Die Inputs und Outputs sind in der semi-formalen tabellarischen Beschreibung zu den Diensten enthalten. D3 [Out2; Out3] D3 [In3; Out3] D4[Out3; Out4]; Die Basisdienste stehen in Beziehung, Output Dienst 3 (Out3) liefert Input für Dienst 4 (In4 entspricht Out3). Dieser Systematik folgend wird die WPIM-Pipeline aufgebaut. Abb. 4.30: Basisdienste bilden die WPIM-Pipeline Die grün gekennzeichneten Basisdienste entstehen im Rahmen der Entwicklung der WPIM- Pipeline. Gelb markierte Umfänge sind (Teil-) Dienste bestehender oder unterstützender Anwendungen. Nach den Basisdiensten werden nun die höheren semantischen Dienste der Middleware vorgestellt. Auch diese Dienste werden prototypisch in der WPIM-Pipeline [Kap. 4.11] operationalisiert Semantik-Dienste auf der Middleware Höhere Dienste oder auch fortschrittliche Dienste können z. B. semantische Dienste wie semantische Anfragen, Inferenz 201, regelbasierte 202 oder Information-Retrieval (IR)-Dienste sein. 201 Schlussfolgern (engl. inference), dabei wird auf der Basis von Aussagen (Prämissen und einer Konklusion) ein logischer Schluss gezogen. In der Informatik werden Schlussfolgerungen automatisiert bzw. computergestützt durchgeführt. 202 Ein regelbasiertes System ist ein wissensbasiertes System in dem regelbasiertes Schließen stattfindet. 177

202 Operationalisierung der WPIM-Pipeline Hierbei stehen besonders Anfrage und Ergebnis sowie das zugehörige Matching über den Ontologien und der Datenbank im Vordergrund. Im WPIM-System wird insbesondere über den Einsatz der Inferenz-Dienste, also einem mathematischen Algorithmus mit Regeln nachgedacht. Regelbasierte Dienste können auf mathematischen Gesetzen, wie z. B. der Transitivität 203, aufbauen. Brocks verfolgt einen regelbasierten Ansatz [Borc07]. Inwieweit die bei [Broc07] beschriebenen Formalisierungen, Vektorraum-Modelle oder statistischen Ansätze zur Zuordnung der WPIM-Algorithmen in Klassen geeignet sind, wird nicht weiter untersucht. Datenrepräsentation: Durch PHP-Skripte und SQL/mySQL wird die Befüllung des Datenspeichers/Datenbank (DB) vorgenommen. Ebenso wird die Extraktion der Instanzen aus der DB unterstützt. Zudem können Triplestores 204 die Ablage, das Bearbeiten und Manipulieren sowie das Auslesen der semantischen S-P-O Aussagen unterstützen. Auch die Instanziierung der Ontologie als XML/RDF/RDFS wird unterstützt. Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Datenrepräsentation Höher Dienst WPIM.DB DB-Tabellen 178 WPIM.rdf Person.html Prozess.html Abbilden der Klassen, Objekte und des Wissens in DB Instanziierung und Befüllung der DB H7 Out6 H7[In7; Out7] Out7 Tab. 4.9: Dienst Datenrepräsentation Semantische Prozessrepräsentation: XML-/RDF-/RDFS-Files werden den Aktivitäten im Prozessmodell zugeordnet. Eine Ontologie zur Beschreibung der Prozessstruktur wird somit bereitgestellt. Diese Struktur dient zur Vereinheitlichung der Aktivitäten und ermöglicht zudem deren Anreicherung mit Ressourcen. Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Semantische Prozessrepräsentation Höher Dienst WPIM.rdf Person.html Prozess.html Abbilden der Klassen, Objekte und des Wissens in DB Instanz-iierung und Befüllung der DB WPIM.DB DB-Tabellen H8 Out7 H8[In8; Out8] Out8 Tab. 4.10: Dienst semantische Prozessrepräsentation Höher Dienst WPIM.rdf Prozesselemente auf die Ontologie mappen Harmonisierung der Inhalte: Ziel ist die Übernahme der Klassen, Objekte und Relationen aus der Prozessrepräsentation in die Ontologie. Dazu erfolgt eine Anpassung der XML- Prozessrepräsentation. Beispielsweise werden die vorliegenden Hierarchien durch in subclassof-beziehung überführt. Dadurch wird eine Standardisierung und Harmonisierung der Objekte in einer ontologischen Repräsentation erreicht. Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Harmonisierung WPIM.rdf Standardisierte Repräsentation der Objekte Regelbasierte Systeme bestehen aus einer Faktenbasis, einer Menge von Regeln (engl. Business-Rule-Repository) und einem Regelinterpreter, z. B. einer Inferenzmaschine Transitivität bei einer zweistelligen Relation (R) auf einer Menge ist dann gegeben, wenn aus xry und yrz stets xrz folgt. Dann ist die Relation transitiv. Transitivität ist eine der Voraussetzungen für Äquivalenzrelationen oder Ordnungsrelationen. 204 A triplestore is a purpose-built database for the storage and retrieval of Resource Description Framework (RDF) data - - abgerufen

203 Operationalisierung der WPIM-Pipeline H9 Out8 H9[In9; Out9] Out9 Tab. 4.11: Dienst Harmonisierung Validierung: Das mathematische Prozessmodell bzw. die mathematische Prozessrepräsentation wird in maschinenverarbeitbare Formate wie DTD/XML bzw. XSD/XML überführt. Voraussetzungen für den Dienst sind, dass die Überführung des mathematischen Prozessmodells in eine WPIM.dtd oder WPIM.xsd bereits abgeschlossen ist und diese vorliegt. Darauf aufbauend folgt die Überprüfung der Datei Konzepte.xml gegen die.dtd und die.xsd. Bei einem ersten Test wurde folgendes Ergebnis erzielt: Die Datei Konzepte.xml wurde validiert und für wohlgeformt und gültig befunden. Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Validierung höherer Dienst Projekt.xml WPIM.DTD WPIM.XSD Überprüfung der XML-Datei auf Wohlge-formtheit und Gültigkeit Validierung der XML- Datei Projekt.xml oder ABBRUCH H10 Out9 H10[In10; Out10] Out10 Tab. 4.12: Dienst Validierung Prozessontologie: Die Prozess-Konzepte und Prozess-Strukturen (Prozess, Pool, Aktivität) dienen zur Strukturierung von zusätzlichem Wissen und den digitalen Objekten wie (Person, Dokumente usw.). Diese können Eigenschaften (engl. properties) haben, wie z. B. hatverantwortung, hatbearbeiter oder hatvertreter. Alle Strukturen über den Konzepten werden in Protégé als Ontologie modelliert das semantisch-ontologische Prozessmodell entsteht. Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Ontologie Basisdienst Ontologisches WPIM.rdf aufbauen Datenmodell Konzepte, Klassen und Objekte Ontologie aus Konzepten aufbauen und als Datenmodell bereitstellen H11 Out10 H11[In11; Out11] Out11 Tab. 4.13: Dienst Ontologie aufbauen Ontologie instanziieren: Dieser Dienst unterstützt bei der Population und Instanziierung der Ontologie. Dies ist ein wichtiger Schritt, denn die folgende Annotation erfolgt auf eben den hier entstehenden digitalen Objekten. Als Input dient die Ontologie WPIM.rdf, die durch den Sprachumfang OWL zur Output-Datei WPIM.owl wird. Zudem sind in der Ontologie WPIM.owl konkrete Ausprägungen zu den Klassen, also die sog. digitalen Objekte hinterlegt. Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Ontologie WPIM.owl instanziieren Basisdienst WPIM.rdf Einzelnen Konzepten konkrete Daten zuweisen Ontologie mit Datensätzen populieren H12 Out11 H12[In12; Out12] Out12 Tab. 4.14: Dienst Ontologie instanziieren Semantische Abfragen: Die semantischen Abfragen (auch semantischen Suchen) können u. a. durch Querying realisiert werden. Dieser Dienst ist ein höherer, fortschrittlicher Dienst und nutzt den semantischen Ansatz durch die Verwendung von semantischen Abfragesprachen. 179

204 Operationalisierung der WPIM-Pipeline Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Semantische Query.html Abfragen Höherer Dienst Suchanfrage Ähnlich wie bei SQL werden Anfragen an die XML/RDF-Datei gestellt Match der Suche und Rückgabe der Werte H13 Out12 H13[In13; Out13] Out13 Tab. 4.15: Dienst semantische Abfragen Inferenz: Auch die Inferenz ist ein höherer und fortschrittlicher Dienst, der den semantischen Suchen zugeordnet wird und maschinelles Schließen unterstützt. Neues Wissen kann per Inferenzmechanismus abgeleitet bzw. geschlossen werden. Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Inferenz Höherer Dienst WPIM.rdf Inferenz.html Suchanfrage Aus der XML/RDF-Datei wird neues Wissen maschinell geschlussfolgert Gewinnung neuen Wissens und neuer Erkennt-nisse H14 Out13 H14[In14; Out14] Out14 Tab. 4.16: Dienst Inferenz Rückführung der Prozessmodelle: Dieser Dienst ermöglicht es, die annotierten Prozessmodelle als XML/RDF abzuspeichern und in die Prozess-Modellierungswerkzeuge, wie z. B. den BPVA zurückzuführen (technisch exakter formuliert zu re-importieren). Dadurch wird ein geschlossener Entwicklungszyklus für die Modellierung, Annotation, Standardisierung und Rückführung der annotierten Prozessbausteine in die Prozess-Modellierungswerkzeuge geschaffen. Dienst Typ Input Funktionsweise Ziel Ergebnisdatei Prozess-modell WPIM.bpva Rück-führung Höherer Dienst WPIM.rdf XML/RDF-Daten in den BPVA re-importieren Rückführung der sem. Prozessmodelle nach BPVA H15 Out11 H15[In15; Out15] Out15 Tab. 4.17: Dienst Rückführung Prozessmodelle WPIM ermöglicht somit nicht nur eine gerichtete Weiterentwicklung (engl. forward engineering) und Annotationen der Innovationsprozesse, sondern vielmehr einen geschlossenen Entwicklungskreis. Dieser verbindet die beteiligten Werkzeuge integrativ und erzielt einen bidirektionalen Austausch der Modelle. Es folgen nun Betrachtungen zu den Benutzungsschnittstellen mit den höheren Diensten zur Visualisierung der Ergebnisse Benutzungsschnittstelle mit Diensten zur Visualisierung Auf der Benutzungsschnittstelle der WPIM-Pipeline sind Dienste zu etablieren, die zur Visualisierung von Strukturen, Anfragen und Ergebnissen dienen. Dies können Dienste sein, die Ergebnisse farblich aufwerten bzw. Strukturen grafisch wiedergeben. Auch Visualisierungen die durch die Benutzer adaptiert werden können, sind denkbar. Farbliche Visualisierung: Der Dienst der Visualisierung ermöglicht eine Volltextsuche über einer Ergebnisdatei und markiert die gefundenen Suchbegriffe farblich. Dienst Typ Input Funktionsweise Ziel Ergebnisdatei 180

205 Operationalisierung der WPIM-Pipeline Visualisierung Visueller Dienst Ergebnis.html Überprüfung der HTML-Datei auf den Suchbegriff Farbliche Markierung des Suchbegriffs Visuell.html V15 WPIM.DB V15[In15; Out15] Out14 Tab. 4.18: Dienst Visualisierung Durchaus sind weitere grafisch-visualisierende Dienste denkbar. Die fortgeschrittene Methode WPIM ermöglicht höhere Dienste, insbesondere als semantische Dienste auch als semantische Such-Dienste benannt. Somit sind unterschiedliche Reasoning Dienste durch Aufrufe auf der Benutzungsschnittstelle denkbar. Ebenso wie die gezielte Suche nach Personengruppen (insbesondere Experten) oder nach Dokumenten (insbesondere Patenten). Auch hierfür können eigene Dienste implementiert werden. Die Spezifikation der Dienste ist somit abgeschlossen. Im weiteren Verlauf der Arbeit muss nun die Datenbasis modelliert werden, auf der die soeben vorgestellten Dienste dann operieren können. Die Zusammenführung der Datenbasis mit den Diensten erfolgt in der prototypischen WPIM-Pipeline [vgl. Kap.4.11]. Begonnen wird hierzu mit der Entwicklung einer Ontologie zu Prozessen und Ressourcen gefolgt von einer Ontologie zu Experten. 4.9 Entwicklung von Ontologien für Prozesse und Ressourcen Um die beschriebenen Dienste operativ auf der WPIM-Pipeline einsetzen zu können, muss eine Datenbasis mit konkreten digitalen Objekten entstehen. Um Dienste und Datenbasis getrennt voneinander entwickeln zu können, muss eine klar definierte Struktur der Daten entstehen. Zur Referenzierung und Strukturierung von Daten sind Vokabulare, Schemata und Ontologien zu verwenden. Bei WPIM werden dazu insbesondere semantische Technologien wie RDF und OWL berücksichtigt. Untersucht werden Entwicklungssysteme und Werkzeuge zur Erstellung von Ontologien. Teilweise unterstützen die untersuchten Werkzeuge bereits semantische Suchen, Reasoning oder Abfragesprachen. Untersucht wurden OntoStudio mit OntoBroker, K-Infinity, SemanticWorks und Protégé. Im Mittelpunkt semantischer Anwendungen liegt die Bedeutung von Information und deren Kontext, hinterlegt in Ontologien. Nachstehend einige Software- Entwicklungssysteme zur Entwicklung und Pflege von Ontologien. Teilweise unterstützen diese Werkzeuge bereits während der Erstellung von Ontologien beim Aufdecken von Inkonsistenzen. Die getroffene Auswahl der Ontologie-Werkzeuge für WPIM wird entsprechend begründet Werkzeuge zur Entwicklung von Ontologien Verfügbare Ontologiewerkzeuge zur Modellierung von Ontologien werden im Folgenden vorgestellt und erprobt. Die Auswahl eines Werkzeuges kann anhand der definierten Auswahlkriterien und der Gegenüberstellung der Werkzeuge nachvollzogen werden OntoBroker Die On-To-Knowledge-Methodologie ist Bestandteil eines Konzepts zur Entwicklung eines ontologiebasierten Wissensmanagementsystems, das erstmals 2000 von Schnurr, Studer, Sure und Akkermanns vorgestellt wurde [vgl. ApDi03, 43; StAD99]. OntoBroker der Firma Ontoprise basiert darauf und stellt eine Inferenzmaschine zur Verarbeitung von regelbasierten Ontologien und ermöglicht den Aufbau semantischer Anwendungen. Der OntoBroker besteht aus einer Inferenzmaschine, welche die Ontologien lesen und die darin abgebildete Logik verarbeiten kann. Er unterstützt gängige semantische Sprachen, darunter die W3C Standards RDF und OWL-DL (eine Teilmenge von der OWL Untersprache OWL DL Description Logic) [vgl. sowie die logikbasierte Ontologiesprache F-Logic [Flog04]. Der OntoBroker 181

206 Operationalisierung der WPIM-Pipeline beruht auf einem offenen Framework zur Anbindung von Datenquellen (Datenbanken, Dokumentmanagementsysteme etc.) und zur Ansteuerung durch Anwendungen, wie z. B. Web- Services mittels PHP, ZOPE oder Java. Dabei sind APIs und Schnittstellen zu vielen gängigen Systemen bereits implementiert. Der OntoBroker ist ein einigen Projekten bereits im produktiven Einsatz [vgl. Onto07]. Abb. 4.31: OntoBroker Architektur aus [StAD99, S. 8] OntoBroker verwendet Ontologien, um Zugriffe auf heterogene Datenquellen zu unterstützen. Die zentralen Komponenten stellen Studer et al. vor: Inferenzmaschine: Als Kernkomponente von OntoBroker verarbeitet diese das in der Ontologie und in der Faktenbasis bereitgestellte Wissen. Ziel ist es, an das System gestellte Anfragen zu beantworten. Die Inferenzmaschine basiert auf einem Übersetzungsansatz, der Frame Logic in mehreren Schritten in Logikprogramme transformiert, so dass bekannte Techniken aus dem deduktiven Datenbankbereich eingesetzt werden können. [StAD99, S. 9] OntoCrawler: Gebündelt werden die in den Wissensquellen vorhandenen bzw. aus diesen extrahierbaren ontologischen Fakten. Die Fakten werden sodann in einer zentralen Faktenbasis abgelegt. Dabei werden ontologische Fakten in drei verschiedenen Varianten bereitgestellt [StAD99]: 1. HTML-Quellen können mit semantischer Information annotiert werden, z. B. durch Verwendung der Annotationssprache HTML A. Das angestrebte Entwurfskriterium ist dabei, redundante Information soweit möglich zu vermeiden. 2. Metadaten, die mit dem RDF-Framework beschrieben sind, werden nach dem Einlesen in Frame Logic [Flog04] übersetzt und dann in der Faktenbasis gespeichert. 3. Für regelmäßig strukturierte Wissensquellen können zudem Wrapper eingesetzt werden, die die relevante semantische Information aus diesen Quellen extrahieren [vgl. StAD99]. Benutzungsschnittstelle: Ontologien werden darauf in einer hyperbolischen Darstellung visualisiert. Bei dieser hyberbolischen Darstellung werden Konzepte im Zentrum groß, Konzepte am Rande hingegen klein abgebildet. In die hyperbolische Darstellung ist eine tabellarische Schnittstelle zur Spezifikation von Anfragen integriert. Anfragen können durch den Anwender an OntoBroker formuliert werden, ohne mit der spezifischen Anfragesyntax vertraut zu sein. 182

207 Operationalisierung der WPIM-Pipeline RDF-Maker: Aus den bestehenden Fakten in der Faktenbasis werden entsprechende Fakten in RDF-Notation erzeugt. Durch den Einsatz der Inferenzmaschine können aus den bestehenden RDF-Fakten weitere neue Fakten abgeleitet werden, die wiederum in RDF-Fakten transformiert werden können. Der RDF Maker bildet durch die Erstellung der RDF-Fakten die Schnittstelle zum Semantic Web mit dem Quasi-Standard RDF des W3C OntoStudio, Ontoprise GmbH OntoStudio Version 1.6 ist als 3-monatige Demoversion [Onto07] kostenlos abrufbar. Dies ist der Nachfolger des Ontologie-Editors OntoEdit. OntoEdit entstand im Rahmen von Forschungsprojekten und wurde zu einem kommerziell vermarktbaren Produkt entwickelt. Im industriellen Umfeld werden die Nachfolgeprodukte OntoBroker und OntoStudio sowie die Anwendungen SemanticMiner, SemanticIntegrator und SemanticGuide eingesetzt [Lauf06 in Bull06; Onto07]. Die Entwicklungsumgebung OntoStudio dient der Modellierung von Ontologien und dem Aufbau semantischer Anwendungen. Basis für OntoStudio bildet die Entwicklungsumgebung Eclipse von IBM, die als Quasi-Standard für Editoren-Frameworks gilt [vgl. Onto07]. Datenbankschemata können durch OntoStudio importiert und in Ontologien umgewandelt werden. Eine grafische Mapping-Komponente ermöglicht die Verbindungen zwischen Inhalten unterschiedlicher Datenbanken [Onto07]. Zudem können Datenbankinhalte durch Regeln miteinander in Beziehung gesetzt werden. OntoStudio unterstützt als Ontologie-Sprachen sowohl OWL und RDF, als auch F-Logic. OWL ist vom W3C für die Beschreibung von Ontologien vorgesehen, F-Logic ist für die logikbasierte Verarbeitung von Ontologien optimiert. Als Einund Ausgabeformate sind Import- und Exportfunktionalitäten für verschiedene Formate vorhanden. Die unterstützten Formate sind F-Logic, OXML (objektorientiertes XML), OWL und RDF(S). [Lauf06, S,239; Oxml07] K-Infinity, Intelligent Views GmbH K-Infinity der Intelligent Views GmbH 205 besteht aus einem Modellierungswerkzeug, dem Knowledge-Builder, mit dem das Schema eines Wissensnetzes gebaut wird. Grundsätzlich kann auf jedes Wissensnetz mit einem Standard-Web-Browser zugegriffen werden. Über dieses Frontend kann nicht nur auf dem Wissensnetz gesucht und navigiert werden sondern über Pflegeseiten können beliebige Knoten eines Netzes erzeugt bearbeitet und gelöscht werden. Ein Wissensnetz kann als eine äußerst effiziente, redaktionell gepflegte Zugriffsstruktur für den Nutzer verstanden werden. Im Unterschied zu anderen Ansätzen des Wissensmanagements ist dabei der Index vollkommen von den Inhalten entkoppelt und stellt einen Wert an sich dar. [KnBu04] Dateien im RDFS-Format (Resource Description Framework Schema) kann der Knowledge-Builder sowohl importieren als auch exportieren

208 Operationalisierung der WPIM-Pipeline Abb. 4.32: Import Fenster im Knowldge-Builder Falls eine Ressource bereits importiert wurde, wird bei erneuten Importen die Ressource im Netz aktualisiert. K-Infinity ist nach eigenen Angaben des Herstellers gut geeignet zur Erstellung von Business Semantics und Knowledge Portalen SemanticWorks, Altova GmbH Altova SemanticWorks 2007 ist ein visueller RDF/OWL Editor zur Erstellung von RDF-Instanz- Dokumenten, RDF-Schema-Vokabularen und OWL-Ontologien für das Semantic Web. Bei deren Erstellung unterstützt SemanticWorks durchgängig bei der Prüfung und Verifizierung von Syntax und Semantik. Zudem gibt es kontext-sensitive Eingabehilfen, die aufgrund des gewählten RDF/OWL-Sprachlevels eine Liste mit erlaubten bzw. nicht erlaubten Eingaben anbieten und somit sicherstellen, dass ausschließlich gültige Dokumente entstehen. Folgende Sprachlevels und Dialekte werden unterstützt: RDF, RDF Schema, OWL Lite, OWL DL, und OWL Full [vgl. Abb. 4.33]. Abb. 4.33: Sprachen und Sprachlevel bei SemanticWorks [SeWo07, S. 4] Das in [Abb. 4.33] dargestellte Auswahlfenster für Classes, Properties, Instances, alldifferent, und Ontologies ermöglicht es, auf spezifische Umfänge der Ontologie-Entwicklung zu fokussieren. Während der Entwicklung von Ontologien kann jederzeit von der grafischen RDF/OWL-Sicht in die textbasierte Sicht bzw. in die N-Tripel-Darstellung wechseln, um zu sehen, wie die Ontologie repräsentiert bzw. serialisiert wird. 184

209 Operationalisierung der WPIM-Pipeline Abb. 4.34: SemanticWorks in der Graph-Ansicht Ebenso sind Exporte und Sicherungen der Ontologie-Datei im Text- bzw. Tripel-Format möglich. In SemanticWorks können zudem semantische Vokabulare und Ontologien erstellt werden. Die semantischen Tripel können in der grafischen Repräsentation per drag and drop zusammengefügt werden. Abschließend kann eine rein textbasierte Repräsentation (sog. Serialisierung) erstellt und in bestehende Web-Seiten integriert werden. Auch Altova SemanticWorks 2007 steht in einer 30 Tage Demoversion zum Download bereit [www.altova.de] Protégé, Stanford University Protégé ist eine Open-Source-Plattform mit einer Reihe an Werkzeugen, die bei der Erstellung von Domänen-Modellen (engl. domain models), wissensbasierten Anwendungen (engl. knowledge-based applications) und Ontologien unterstützt. Kern von Protégé bildet ein Set von wissensbasierten Strukturen und Funktionen, die bei der Erstellung, Visualisierung und Manipulation von Ontologien unterschiedlichster Formate unterstützen. Darüber hinaus kann Protégé mittels Plug-ins (z. B. Protége-OWL-Plug-in) sowie Wizards (wie z. B. OWLViz) [vgl. Horr04 in Prot07] und durch das Java-basierte Application Programming Interface (API) gut erweitert bzw. als Basis für wissensbasierte Applikationen verwendet werden [vgl. Prot07]. In den.pont-dateien werden die Klassen abgelegt, in den.pins-dateien die Instanzen [vgl. Abb. 4.35]. Abb. 4.35: Protégé Projekt anlegen mit Suffix.pont und.pins Protégé-Frames erleichtert die Ontologieerstellung sowie deren Instanziierung. Dabei kommt das Open Knowledge Base Connectivity Protokoll (OKBC) zum Einsatz [Prot07]. Hier besteht eine Ontologie aus einem Set von Klassen, zusammengefasst in einer Hierarchie. Klassen können sowohl als abstrakte Klassen mit und ohne SubKlassen, aber auch als konkrete Klassen mit Instanzen definiert werden. Zur Beschreibung der Klassen werden dann sog. Slots an die Klassen angefügt, die zur Beschreibung von Eigenschaften und Beziehungen dienen. Weiter 185

210 Operationalisierung der WPIM-Pipeline stehen Instanzen zur Verfügung, also Exemplare oder Individuen der Klassen, denen spezifische Werte bezogen auf Eigenschaften zugeordnet sind [Prot07]. Der Protégé-OWL-Editor unterstützt bei der Erstellung von Ontologien für das Semantic Web genauer in der Web Ontology Language (OWL). An OWL ontology may include descriptions of classes, properties and their instances. Given such an ontology, the OWL formal semantics specifies how to derive its logical consequences, i.e. facts not literally present in the ontology, but entailed by the semantics. These entailments may be based on a single document or multiple distributed documents that have been combined using defined OWL mechanisms. [OWL in Prot07] Das Protégé Programming Development Kit (PDK) ist eine Dokumentation und Ansammlung von Beispielen, welche aufzeigen, wie Erweiterungen (engl. Plug-ins) für Protégé entwickelt und eingebunden werden. Zudem wird darin beschrieben, wie Protégé APIs zu verwenden sind. Protégé selbst kann als Sammlung von Plug-ins verstanden werden, die einzeln aber auch komplett ausgetauscht werden können. Protégé verfügt über eine core API sowie eine erweiternde OWL-API, über die direkt auf OWL-Ontologien zugegriffen werden kann [http://protege.stanford.edu/doc/dev.html]. Anmerkungen zur Verwendung von OWL-Ontologien: Besonders muss bei der Installation von Protégé bzw. Protége-OWL darauf geachtet werden, dass z. B. die Sprache OWL selektiert wird. Nur dann finden Ontologien im OWL Format Unterstützung [http://protege.stanford. edu/doc/owl-faq.html]. Ergänzend sind eine Vielzahl an Plug-ins verfügbar, die z. B. weitere Formate oder grafische Repräsentationen für Ontologien unterstützen. Mehr dazu unter: [http://protege.stanford.edu/download/plugins.html] und im sog. Tutorial 206 Get Started. WebProtégé ist die neueste webbasierte Weiterentwicklung von Protégé. WebProtégé 207 ist ein leichtgewichtiger, webbasierter, open-source Ontology-Editor. Ziel der Entwicklung von WebProtégé war es, den kollaborativen Erstellungsprozess von Ontologien in einer Web- Entwicklungsumgebung zu unterstützen. Auf dem Protégé Demo Server 208 steht dazu die Version V0.5 bereit Weitere Ontologiewerkzeuge Filmar/Kellner stellen in der Marktstudie Ontologiewerkzeug weitere Ontologiewerkzeuge vor, z. B. Ontolingua 209 der KSL Stanford University, WebODE der Ontology Group UPM, WebOnto KMI der freien Universität England sowie der Ontosaurus 210 ISI University of South California. Diese bewerten Filmar/Kellner anhand eines ausführlichen Kriterienkatalogs, in dem Kriterien, wie z. B. das Ontologie-Speicherungsformat, Im- und Exportmöglichkeiten von Ontologien, die Erweiterbarkeit, Schlussfolgemöglichkeiten, Mehrfachvererbung und Konsistenzchecks bedacht sind [vgl. FiKe03, S ]. An diesen Kriterienkatalog angelehnt, treffen wir die Auswahl der Ontologiewerkzeuge für die weitere Entwicklung von WPM Conclusio, Kriterien und Auswahl eines Ontologiewerkzeugs Die vorgestellten semantischen Werkzeuge sind gut geeignet, um die Ontologien für WPIM aufzubauen und diese zu instanziieren. SemanticWorks und Protége unterstützt zudem eine 206 Protégé Tutorial WebProtégé - - abgerufen Ontolingua: KSL Stanford University Ontosaurus: 186

211 Operationalisierung der WPIM-Pipeline Repräsentation der WPIM-Ontologien in den für das Semantic Web geforderten Ausgabeformaten. Die Serialisierung der Ontologie und der digitalen Objekte erfolgt in RDF/XML oder OWL-DL. Diese ermöglichen es, die Schemata, ontologischen Modelle und semantisch beschriebenen Ressourcen für semantische Suchen bei WPIM vorzubereiten. Bei der Auswahl der (semantischen) Werkzeuge sind folgende Kriterien für WPIM ausschlaggebend: kostenlose/freie Verfügbarkeit, Unterstützung der Standards RDF/RDFS bzw. OWL-DL, Import- und Export-Funktionen für XML-/RDF- bzw. OWL-Konstrukte. Werkzeug Hersteller Logo Import/ Export Lizenzkosten OntoStudio mit OntoBroker Ontoprise / Ja K-Infinity SemanticWorks Protégé Intelligent Views GmbH Altova GmbH Stanford University / Ja Demoversion RDF/XML OWL RDF/XML OWL Ja 30-Tage Demo Nein Tab. 4.19: Auswahl semantischer Werkzeuge Auf Basis der nicht vorhandenen Lizenzkosten und der freien Verfügbarkeit, zudem der weiten Verbreitung und der Kompatibilität zu RDF/XML setzen wir zur Modellierung der WPIM- Ontologien das Werkzeug Protégé ein. Zur Erstellung und Validierung von XML/DTD- und XSD-Dateien nutzen wir SemanticWorks. Bevor mit der Modellierung der Schemata und Ontologien begonnen wird, erfolgt eine Bestandsaufnahme bereits existenter Ontologien und deren Klassifizierung Bestandsaufnahme und Klassifizierung von Ontologien Zunächst wird die Klassifizierung von Ontologien in die drei Ebenen höhere (engl. upper), mittlere (engl. mid) und Bereichs-Ontologien (engl. domain) vorgestellt. Eine Bestandsaufnahme verfügbarer Ontologien wird vorgenommen. Dazu werden bestehende Bibliotheken, Ontologien, und Ontologieprojekte untersucht Upper Level, Mid Level und Domain Ontologien Das Konzept zu Upper-Level und Mid-Level Ontologien ist im OntologyPortal 211 nachzulesen. Die Suggested Upper Merged Ontology (SUMO) mit ihren Domain-Ontologien bildet die größte formalisierte und frei verfügbare Ontologie aus. Diese Ontologien finden Einsatz in der Forschung und dabei im Speziellen in den Bereichen der Suche, der Linguistik (Sprachforschung) und der Schlussfolgerung. SUMO wurde zudem als formalisierte Ontologie in das WordNet Lexikon abgebildet. SUMO wurde in der Sprache SUO-KIF erstellt und befindet sich im Besitz Besitz der IEEE 212. Dennoch ist SUMO frei verfügbar. Mit dem SUMO Search IEEE - The world's leading professional association for the advancement of technology

212 Operationalisierung der WPIM-Pipeline Tool kann man sich z. B. für englischsprachige Begriffe Synonyme anzeigen lassen, die im WordNet Lexikon 213 enthalten sind. Für man gibt es elf synonyme Bedeutungen bzw. was, wie sich zeigt, eher verwandte Begriffe sind: Für man erhält man folgende Treffer: human (dt. menschliches Wesen), male (dt. männlich) oder soldier (dt. Soldat). [http://sigma.ontologyportal.org:4010/sigma/wordnet.jsp?word=man&pos=1]. Die MILO (MId-Level Ontology), soll als Ontologie die Brücke bilden zwischen dem abstrakten Inhalt der SUMO 214 und den stark detaillierten und vielfältigen Domain Ontologien. MILO ist die größte freie formale Ontologie, mit mehr als Termen und Axiomen. Die Rechte der MILO (MId-Level Ontology) liegen bei Teknowledge DARPA- und DAML-Ontologie-Bibliothek DARPA die Agent Markup Language (DAML) DAML hat den Anspruch, sowohl Sprache als auch Werkzeug zur Umsetzung des Konzepts des Semantic Webs zu sein. Mehr dazu erläutert Pagels unter [http://www.daml.org/]. Der DAML-Validator [http://www.daml.org/validator/] wird leider nicht länger gepflegt, daher haben wir den OWL-Validator 216 erprobt. Die Personen- Ontologie, verfügbar unter [http://daml.umbc.edu/ontologies/ittalks/person], beschreibt eben Personen. Die aufgeführten semantischen Bestandteile der Ontologie sind aber nur ein ausgewählter Teil des Visitenkarten-Formats vcard. Die Ontologie ist in den Formaten hyperdaml und auch dumpont abrufbar 217. Aus der Personen-Ontologie werden nun einige Klassen und Properties vorgestellt: Classes: Edu, Education, ProfessionalExperience, ProfExp Properties: Degree, description-position, employer, examen-date, school, thesis-title Eine Sammlung weiterer Ontologien modelliert in DAML 218 ist online verfügbar Protégé-Upper-Ontologies-Bibliothek Diese Bibliothek stellt Ontologien in folgenden Kategorien bzw. Formaten bereit: Frame-based, OWL sowie weitere Formate. Diese sind abrufbar unter [http://protege.cim3.net/cgibin/wiki.pl?protegeontologies Library]. Frame-based-Ontologien sind Ontologien, die mit dem Protégé-Frames-Editor entwickelt wurden. Der Protégé-Frames Editor [http://protege.stanford.edu/overview/ protege-frames.html] implementiert ein Wissens-Model, das kompatibel zum Open Knowledge Base Connectivity protocol (OKBC) ist, siehe dazu die OKBC Homepage [http://www.ai.sri.com/~okbc/]. Ontologien erstellt in OWL. Weitere Möglichkeiten nach OWL-Ontologien zu suchen, sind Google mit der Suche bzw. dem Filetype OWL [http://www.google.com/search? q=filetype:owl+owl], oder die semantische Suchmaschine Swoogle 219. Ontologien erstellt in weiteren Formaten, wie z. B. DAML + OIL und RDF Schema. In den Ontologien der Protégé Ontologies Bibliothek konnten keine Ontologien identifiziert werden, die als Upper-Ontologies für die Methode WPIM, die Beschreibung von Innovationsprozessen oder das Expertennetzwerk geeignet sind SUMO Semantic-Web Serach

213 Operationalisierung der WPIM-Pipeline WebOnto, Knowledge Media Institute (KMI) WebOnto wurde am Knowledge Media Institute 220 entwickelt, dort gibt es zudem eine Übersicht zu den entwickelten Projekten 221 aus den Bereichen Wissensmanagement und Semantic Web. WebOnto wurde als Teilumfang der Projekte PatMan 222, HCREMA 223 und Enrich 224 entwickelt. Zudem findet WebOnto Anwendung in PlanetOnto 225 und ScholOnto 226. Einen guten Überblick gibt zudem die Internetseite Sharing Ontologies on the Web 227 oder auch die Dokumentation zu WebOnto 228. WebOnto wurde implementiert von Domingue unterstützt durch Motta, Eisenstadt und Zdrahal. Um bei Bedarf eigene Wissensmodelle (engl. knowledge models) zu erstellen, kann von John Domingue 229 ein Login und Benutzername angefordert werden. WebOnto ist ausgelegt für die Nutzung über PC- oder Unix-Arbeitsplätze mit Netscape. Weitere Hinweise finden sich auf der offiziellen WebOnto-Seite. Nun folgt die konkrete Ontologie-Entwicklung für die WPIM-Pipeline und die WPIM- Anwendung. Dabei wird von den Konzepten, über die Spezifikation, zur formalisierten WPIM- Ontologie übergeleitet Ontologie-Entwicklung: Konzepte, Spezifikation, Formalisierung Konzepte der WPIM-Prozessstruktur sowie für WPIM relevante Konzepte zu Ressourcen werden aufgezeigt und unabhängig voneinander spezifiziert und technisch formalisiert. Dabei wird insbesondere auf bestehende Strukturen, wie z. B. hierarchische Klassenstrukturen, in Prozessen eingegangen. Die WPIM-Konzepte werden durch exakter werdende Spezifikation und technische Formalisierung auf eine ontologische Implementierung als Klassen vorbereitet. Die Vereinbarkeit von Prozessklassen mit Ressourcenklassen wird dargestellt. Anschließend werden für WPIM die Klassen mit Werkzeugunterstützung semantisch modelliert und instanziiert Technische Formalisierung der WPIM-Prozessontologie und der Relationen Zunächst werden die hierarchischen Konzepte des WPIM-Prozessmodells in Klassen der WPIM- Prozessontologie abgebildet. Um diese Taxonomie zu erweitern, werden Properties und Relationen eingeführt, welche die Klassen (auf logisch-semantische Art) verbinden. Auf Instanzebene werden die Klassen instanziiert und mit konkreten Datensätzen befüllt. Angestrebtes Ziel der Formalisierung ist es, das Strukturwissen zu den Prozessen in eine Ontologie zu überführen. Dieses Strukturwissen ist in den Prozessmodellen (z. B. modelliert in BPVA) bzw. den zugehörigen XML-Repräsentationen der Prozessmodelle erhalten. Der Begriff Strukturwissen bezieht sich auf die Konzepte und deren Ordnung zueinander 230. Dazu sind die zentralen Konzepte im WPIM-Prozessmodell und aus der Konzepthierarchie aufgelistet. Hierauf aufbauend soll die WPIM-Prozessontologie spezifiziert und formalisiert werden: Prozess, 220 KMI PATient Workflow MANagement System Health-Care Resource Management Enrich Representation for Organisational Learning PlanetOnto unter ScholOnto unter WebOnto unter John Domingue mailto In Ontologien werden Konzepte als Klassen bezeichnet. Allgemein sprechen wir im Rahmen der Implementierung und der Instanziierung dann von digitalen Objekten. 189

214 Operationalisierung der WPIM-Pipeline 190 Teilprozess, Sequenz, Phasen, Pool, Aktivität, Aufgabe. Diese zentralen WPIM-Konzepte werden zunächst als Klassen und Unterklassen (auch Subklasse) in der sog. Klassenhierarchie modelliert hierzu einige ausformulierte Beispiele ohne Anspruch auf Vollständigkeit: Eine Klasse Prozess und auch eine Klasse Pool haben Unterklassen. Solche Unterklassen von Prozessen sind, z. B. die Klassen Teilprozess oder Aktivität. Ein Pool hat z. B. als Unterklasse die Klasse Aufgabe. So wie es Unterklassen gibt, gibt es zugehörig Oberklassen, die auch als Superklassen bezeichnet werden. Die Klassen mit Subklassen werden im Folgenden spezifiziert und formalisiert. Eine technische Spezifikation und Implementierung dazu erfolgt in [Kap ]. Für eine erste Formalisierung wird folgende Darstellung zur Beziehung von Klassen und Unterklassen verwendet. Eine Klasse hat eine Subklasse: Klasse(Subklasse) und weitere Verschachtelungen sowie Mehrfachnennungen sind möglich. Aktivität (Aufgabe) Personen (Experte, Bearbeiter, Vertreter) Ressource (Dokumente (Handbuch, Patent, Lastenheft, CAD-File)) Einführung der formalen SubClassOf-Beziehung als sog. hierarchische Relation. Diese zentralen Klassen bei der Modellierung von Innovationsprozessen stehen in (hierarchischen) Relationen zueinander. Betrachtet man eine streng hierarchische Relation, die das Enthaltensein oder mathematisch eine Teilmengen-Beziehung ausdrückt, so wird diese Beziehung in RDFS oder OWL als SubClassOf zum Ausdruck gebracht. Ein Pool kann eine SubClassOf eines Prozesses, eine Aufgabe kann wiederum eine SubClassOf eines Pools sein. Mittels Inferenz soll später transitiv gefolgert werden können, dass eine Aufgabe somit eine SubClassOf eines Prozesses ist. Diese Schlussfolgerung soll auf Klassenebene möglich sein ebenso aber auch auf Instanzenebene. Properties (auch Rollen, bei RDF als Prädikate bezeichnet) kommen zwischen Klassen und auch zwischen Individuen dieser Klassen zum Einsatz. Es folgen Beispiele auf Klassenebene, Instanzenebene sowie zu weiteren Properties, Statements und inversen Beziehungen: Properties auf Klassenebene zwischen den Klassen Personen und Aufgaben: hatverantwortungfür (Person, Aktivität) Properties auf Instanzenebene: hatverantwortungfür (AntonMüller, ReportingAufgabe) Weitere Properties, im Sinne einer direkten Zuordnung von Klassen und Attributen: hatname (Person) DokumentWirdBenötigtFür (Dokument, Aktivität) Mögliche Ausprägungen zu Dokument sind z. B. Handbuch, Patent, Lastenheft, CAD-File. Auf Instanzenebene kann z. B. die Aussage (engl. statement): Das Patent FlexRay wird benötigt, um die Serienfertigung zu starten abgegeben werden. DokumentWirdBenötigtFür (PatentFlexRay, Serienfertigung)

215 Operationalisierung der WPIM-Pipeline Ein Beispiel zu zwei zueinander inversen Zuordnungen auch als inverse Relation bezeichnet. bearbeitetaktivität (Person, Aktivität) AktivitätWirdBearbeitetDurch (Aktivität, Person) Die hier bezeichneten Relationen und Properties werden in der Prozessontologie implementiert. Weitere Ontologien, wie z. B. die unter [Kap ] beschriebene Ressourcenontologie, kann mittels Ontology-Mapping [KaSc05] über beispielsweise ein zentrales Konzept Ressource in die Prozessontologie integriert werden. Auf die Konzepte bzw. auf die implementierten Klassen beider Ontologien kann dann bei der Instanziierung zugegriffen werden. Hierauf aufbauend folgt eine Betrachtung zur Modellierung von Prozessen mit RDF und OWL. Dies erfolgt in den ausgewählten Werkzeugen SemanticWorks und Protégé. In diesen Werkzeugen werden im weiteren Verlauf der Arbeit die Prozesse repräsentiert sowie semantische Modelle zu den WPIM-Prozessen entwickelt. In der entstehenden WPIM-Ontologie werden insbesondere die Klassen, Relationen und Properties mit RDF und OWL beschrieben Prozesse mit RDF beschreiben und validieren Ziel ist es, die entstehende WPIM-Prozessontologie aus Klassen (bisher auch als Konzepten bezeichnet) aufzubauen und die Prozesse semantisch zu beschreiben. Nach einer Instanziierung und Befüllung mit Wissensressourcen erfolgt eine Repräsentation als RDF (.rdf Datei) bzw. im OWL-Format. So entsteht eine OWL-DL-Ontologie mit Instanzen die in RDF-/XML- oder OWL-/XML-Notation serialisiert wird. Diese RDF-Dateien können mittels einem RDF- Validator 231 bezüglich Syntax und RDF-Konformität überprüft werden. Der Service ARP 232 Validator (another RDF-Parser von Hewlett Packard) checkt und visualisiert RDF-Dokumente. Diesen Online-RDF-Validator nutzen wir zur Validierung von RDF-Dokumenten. Zudem können mit diesem Dienst RDF-Dateien in N-Tripel-Notation oder als RDF-Graph wiedergegeben werden. Auch zu weiteren Sprachen sind Online-Validatoren verfügbar, z. B. zu CSS ein CSS-Validator 233 und zu Xhtml ein Xhtml-Validator 234. Beide Validatoren entstammen der Markup Validation Service 235 Initiative des W3C Prozesse mit OWL beschreiben Für die Beschreibung von WPIM-Prozessen und WPIM-Prozessbausteinen in RDF wurde das Softwarewerkzeug SemanticWorks von Altova eingesetzt. Dazu wird das Sprachlevel OWL Lite herangezogen. OWL DL wird deshalb verwendet, da dieser OWL-Sprachdialekt und somit die damit erstellten Ontologien vollständig entscheidbar sind. Parallel dazu wird zur Erstellung der WPIM-Prozessontologie das Werkzeug Protégé eingesetzt. Die Anwendbarkeit der beiden Werkzeuge und die Ergebnisse der parallelen Entwicklungen werden verglichen. Die Werkzeuge werden erprobt und es werden erste Ontologien entwickelt, die dann in der WPIM-Pipeline konkret umgesetzt werden. Zur weiterführenden Entwicklung des WPIM-Prototyps werden wir Protégé einsetzen Ontologie-Entwicklung mit SemanticWorks In den folgenden sechs Schritten werden der prinzipielle Aufbau und die Entwicklung einer Ontologie in SemanticWorks gezeigt

216 Operationalisierung der WPIM-Pipeline 1. Anlegen und Speichern einer neuen Ontologie Die Ontologie wird in der (Teil-) Sprache bzw. unter dem Sprachlevel OWL-Lite erstellt. Das RDF/OWL-Level kann nachträglich verändert, bzw. auf die umfangreicheren Sprachlevel OWL- DL oder OWL-Full erweitert werden. Der Dateiname zum Ontologie-File ist Prozesse.rdf. Als Dateierweiterung kann.rdf oder.owl verwendet werden. Die Erweiterung (engl. suffix).rdf ist erlaubt, da OWL-Ontologien wiederum RDF-Dokumente sind. Die Online-Hilfe von Altova SemanticWorks [SeWo06] empfiehlt die stark verbreitete.owl Extension zu verwenden. 2. Festlegen der Namensräume (engl. namespaces) Zur Erstellung der OWL-Lite-Ontologie für Prozesse wird ein eigenes WPIM-Vokabular (engl. custom-made vocabulary) erstellt, auf das über einen einzigartigen Namensraum (engl. unique namespace) zugegriffen wird. Bevor das Vokabular in der Ontologie verwendet werden kann, muss im Sinne der guten Praxis, der Namensraum des Vokabulars festgelegt werden. Dementsprechend müssen auch alle anderen Namensräume, die Verwendung finden sollen, festgelegt werden [vgl. Abb. 4.36]. Abb. 4.36: Namespaces für die Ontologie SemanticWorks generiert automatisch das Wurzelelement (root element) rdf:rdf, welches genau einmal in der OWL-Ontologie vorkommen darf. Es beinhaltet zudem drei Namespace Deklarationen (für den RDF-, RDFS-, und OWL-Namensraum). SemanticWorks fügt die RDF-, RDFS- und OWL-Namensräume automatisch als Default hinzu. Diese werden benötigt, um RDF-, RDFS- sowie OWL-Elemente und -Attribute im Ontologie-Dokument benutzen (genauer referenzieren) zu können. Das Prozess-Vokabular erhält als (fiktive) URIref der Namensraum muss deklariert werden. Zudem wird der XML-Schema-Namespace deklariert, damit die XML-Schema-Datentypen (engl. Datatypes) als sog. OWL datatype properties genutzt werden können. Dazu müssen die Namensräume, wie nachfolgend beschrieben, deklariert werden. Den URIref, also den URI Referenzen, wird jeweils ein Prefix zugeordnet. Die URIref für den XML-Schema-Namensraum lautet als Prefix verwenden wir xsd. Die URIref für das Prozess-Vokabular bzw die Prozess-Ontologie legen wir mit der Adresse fest. Als Prefix wird proz, als freiwählbare Abkürzung für Prozess, angegeben. Abb. 4.37: Darstellung der URIref in der XML-Textansicht 192

217 Operationalisierung der WPIM-Pipeline Zudem haben wir in [Code 4.14] die Namensräume :xsd und :proz definiert: <?xml version="1.0" encoding="utf-8"?> <rdf:rdf xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd="http://www.w3.org/2001/xmlschema#" xmlns:proz="http://www.wpim.com/ontologies/prozess#"/> Code 4.14: Namensräume zur WPIM Prozess-Ontologie Die Namensräume werden der Prozess-Ontologie hinzugefügt und die Elemente (z. B. Prozessbausteine) der Ontologie Prozesse.rdf können erstellt werden. Namensräume müssen zu Beginn der Erstellung einer Ontologie angelegt werden. Dadurch wird sichergestellt, dass die URIref-Präfixe Bestandteil der Benennung der Begriffe der Ontologie sind und korrekt expandiert werden. Diese Expansion stellt sicher, dass dem relevanten Namensraum ein Begriff der Ontologie eindeutig zugeordnet wird. Üblicherweise wird ein URIref-Präfix zu einem Namensraum expandiert dargestellt. 3. Anlegen von Klassen Durch Owl:Class werden einzelne Klassen der OWL-Ontologie angelegt. Für diese Ontologie werden die Klassen Prozess und Prozessbaustein erstellt und in der Serialisierung mit der Typbezeichnung Klasse versehen werden. Die Klassen erhalten ein Deskriptions-Element und werden als Klassen vom Typ owl:class also als OWL-Klasse beschrieben. 4. Erstellung der Klassen-Hierarchie Die Klassen Prozess, und Prozessbaustein können als einer ersten einfachsten Hierarchie zugehörig dargestellt werden. Prozessbaustein ist eine Sub- oder Unterklasse (engl. SubClassOf) von Prozess, was wiederum zum Ausdruck bringt, dass jede Instanz der Prozessbaustein-Klasse eine Instanz der Klasse Prozess sein muss. Die Klassen Ersteller und Verantwortlicher werden verwendet, um die Werte der Eigenschaften proz:hatersteller sowie proz:hatverantwortlichen auszudrücken sowie zur Erstellung von Instanzen zu Ersteller bzw. Verantwortlicher heranzuziehen. Abb. 4.38: Beziehung zwischen zwei Klassen mit rdf:subclassof Die Klasse Ersteller hat zwei Aufgaben: Zunächst wird über sie der Wertebereich einer Eigenschaft proz:hatersteller (z. B. stehen nur potenzielle Experten aus einem Mitarbeiterverzeichnis zur Verfügung) definiert. Zudem sollen Instanzen der Klasse Ersteller erzeugt werden. 193

218 Operationalisierung der WPIM-Pipeline 5. Definition von Eigenschaften (engl. properties) Properties werden auf globaler Ebene definiert und danach mit verschiedenen Klassen in Beziehung gesetzt. 6. Deklaration von Instanzen und von AllDifferent Instances Zunächst können einzelne Instanzen angelegt werden. Zudem können Aussagen zu Beziehungen zwischen einzelnen Instanzen, z. B. Gemeinsamkeiten oder auch Unterschiede im Sinne der mathematischen Mengenlehre, getroffen werden. Nach dem Einstieg in die Entwicklung von Prozesshierarchien und ersten Ontologien mit SemanticWorks folgt nun die WPIM-Ontologie-Entwicklung mit Protégé Ontologie-Entwicklung mit Protégé Protégé wird verwendet, um die Ontologie zu Innovationsprozessen und die Ontologie für Experten aufzubauen. Diese Ontologien fliessen in die WPIM-Ontologie und somit die WPIM- Anwendung ein. Konkret werden die Ontologien Prozesse.pprj und Experten.pprj erstellt. Protégé unterstützt dabei bei der Erstellung von Klassen (abstrakt/nicht abstrakt) sowie der Entwicklung von Klassen-Hierarchien und Vererbungsbeziehungen (einfach/mehrfach). Abb. 4.39: Klassen-Hierarchie in Protégé Die Wurzel des hierarchischen Klassen-Baums [vgl. Abb. 4.39] bildet das Wurzel-Element Thing und die Klasse:SYSTEM-CLASS [vgl.abb. 4.40]. 194

219 Operationalisierung der WPIM-Pipeline Abb. 4.40: Projekt-Prozesse WPIM in Protégé Die zentralen Sichten und Konzepte im Werkzeug Protégé werden vorgestellt und erklärt: Classes die hier markierte Klasse Ansprechpartner erbt Eigenschaften (slots) wie Personal_ID, Name und Nachname von der Superklasse Mitarbeiter. Slots können nicht nur Eigenschaften, sondern auch Beziehungen sein, wie hier verantwortlich_fuer. Slot-Facets treffen Aussagen über die Art der Ausprägung der Slots. Den Slots werden Kardinalitäten (min/max Häufigkeit), Typen (Datentypen wie z. B. String oder Integer) und weitere Fakten (Pull-Down-Menu als Auswahlliste oder Default-Werten) zugeordnet. Der Slot Name ist hier vom Datentyp String; Personal_ID ist eine Zahl mit Kardinalität eins, d. h. bei der Instanziierung muss einer Person, genauer einem Mitarbeiter exakt eine Zahl vom Typ Interger als ID zugeordnet werden; Forms ermöglichen das Erstellen von Masken für die Eingabe von Datensätzen für Instanzen der Klassen. Dabei wird die grafische Anordnung der einzugebenden Daten festgelegt. Die Forms ermöglichen den Aufbau und die Gestaltung einer benutzungsfreundlichen Oberfläche. Instances darüber werden Eingabefenster aufgerufen, die es ermöglichen zu einer Klasse Instanzen anzulegen. Die Slots (Eigenschaften und Beziehungen) werden von der/den Superklassen und der selektierten Klasse vorgegeben und können über Eingabefenster befüllt werden. Dabei werden die Eingaben auf die erlaubten Kardinalitäten und Datentypen überprüft. Queries ermöglichen Abfragen über die Tripel aber auch zu Relationen und Slots. Auf diese erste Einführung in Protégé folgt nun die konkrete Modellierung und Serialisierung der WPIM-Prozessontologie in XML/RDF/OWL Serialisierte Prozessontologie in OWL-DL Protégé als Werkzeug unterstützt bei der Modellierung der Ontologie zu den WPIM- Innovationsprozessen. Das Prozessmodell WPIM wird in die WPIM-Prozessontologie überführt 195

220 Operationalisierung der WPIM-Pipeline und im Sprachdialekt OWL-DL modelliert und abschließend in XML/RDF serialisiert. Protégé ermöglicht die Überführung der Klassen-Taxonomie in die maschinenverarbeitbare XML-/RDF- /OWL-Serialisierung. 196 Abb. 4.41: OWL-DL Ontologie, serialisiert in der XML-/RDF-/OWL-Notation Als Ergebnis der Entwicklung liegt, wie in [Abb. 4.41] dargestellt, die in XML/RDF/OWL serialisierte WPIM-Prozessontologie vor. Eine Validierung der WPIM-Ontologie hinsichtlich Syntax und Semantik ist erfolgt. Die entstandene WPIM-Ontologie kann nun mittels semantischen Suchen weiterführend analysiert werden. Auch durch die folgenden grafischen Visualisierungen der Ontologie lassen sich, durch menschliche Benutzer, erste Zusammenhänge, Klassen und Ressourcen in der WPIM-Ontologie erkennen Exkurs: Zugriff und Manipulation von Ontologien auf Datenebene Gerade bei der Zusammenführung von Ontologien bestehen noch allgemeine Herausforderungen. Bei WPIM ist u. a. die Zuordnung von Experten aus der Experten-Ontologie zur Superklasse Aufgabe in der Prozess-Ontologie nötig. Protégé unterstützt die Speicherung der Ontologie in RDF-/XML-Notation. Auch ist es möglich, die S-P-O Tripel in sog. Triplestores abzulegen. Für Anwendungen ist ein Zugriff auf die Tripel zwingend nötig. Zur Bearbeitung und Manipulation der RDF-Tripel und OWL-Ontologien stehen einige Werkzeuge zur Verfügung, u. a. APIs, RDF-Triplestores und Datenbank-Werkzeuge für RDF-Modelle und Instanzen. RAP RDF API für PHP V0.9.5 RAP ist ein Softwarepaket zum Parsen, Abfragen und Manipulieren sowie zur Serialisierung und Bereitstellung von RDF-Modellen. Weitere Information und die Dokumentaton finden sich auf der RAP Homepage 236. ARC Appmosphere RDF Classes Eine Kombination aus RDF-Modellen und der Abfragesprache SPARQL für LAMP-Systems (Linux, Apache, MySQL, PHP). Bereitgestellt werden RDF-Klassen für die Bearbeitung unter PHP. ARC ist somit ein flexibles RDF-System für die Verwendung im Semantic Web und PHP- Anwender weiteres auf der ARC Homepage

221 Operationalisierung der WPIM-Pipeline R2D2 RDF to Database too R2D2 238 bietet Unterstützung beim Ablegen, Editieren, Verändern und Abfragen von RDF- Daten und RDF-Tripeln in Datenbanken. R2D2 ist ein Plug-in für RAP. AllegroGraph 64-bit RDFStore AllegroGraph 239 eine hochperformante, persistente, lokale RDF-Graph Datenbank. Unterstützt werden die Sprachen SPARQL, RDFS++, sowie das Reasoning mittels Prolog aus Java- Applikationen über einer Menge von RDF-Tripeln. RDFReactor Mit RDFReactor 240 lassen sich Ontologien in RDF-Schema und OWL in ein dynamisches, objektorientiertes Java-API transformieren lassen. Somit wird den Java-Entwicklern der korrekte, effektive und effiziente Umgang mit Semantic Web Anwendungen ermöglicht. [Völk06]. Die beiden Welten RDF und Java werden durch diesen Ansatz zusammengeführt. Abb. 4.42: Mapping zweier Welten: Java und RDF [Völk06] Völkel explains the mapping from the object-oriented Java world to the tripleoriented RDF world. Basically, we map RDFS (or OWL) classes to Java classes and RDF properties to Java properties, accessed through get() and set(value) methods. [Völk06] RDFReactor übersetzt eine Ontologie in eine Reihe domänen-spezifischer Klassen. Dazu werden Ontologie-Klassen in domänen-spezifische Klassen und Beziehungen (Relationen) auf Eigenschaften (Properties) abgebildet. Der Code-Generator bedient sich einer Reihe von Funktionen, wodurch gewöhnliche Java-Entwickler zu Entwicklern semantischer Web- Anwendungen werden ohne weit mehr als das URI-Konzept verstanden zu haben [Völk06, S. 42]. Jede generierte Java-Klasse erbt direkt oder indirekt von ReactorBaseImpl. Jede ReactorBaseImpl-Instanz kennt ihre URI (oder leeren Knoten) und die RDFS-Klasse, die sie in der API darstellt. Zur Manipulation des RDF-Modells wird eine Abstraktions-Schicht RDF2Go 241 verwendet, welche die Anbindung zu Jena, Sesame, YARS und anderen Werkzeugen bereitstellt [Völk06]. Nach diesem Exkurs zur Manipulation von Ontologien folgen nun Werkzeuge zur Visualisierung von semantischen Strukturen und Ontologien. 238 R2D AllegroGraph RDFReactor, entwickelt am Forschungszentrum Informatik FZI RDF2Go

222 Operationalisierung der WPIM-Pipeline Werkzeuge zur Visualisierung von (semantischen) Strukturen Vorgestellt werden verfügbare Werkzeuge zur Visualisierung von Hierarchien, semantischen Strukturen und Ontologien. Besonders wird auf die Visualisierung von XML-Dateien, wie z. B. die WPIM-Ontologie sowie auf die Visualisierung von Strukturen aus Dateisystemen eingegangen. Ziel ist es, aufzuzeigen, dass die bei WPIM erzeugten Strukturen u. a. direkt in Dateisysteme überführt/abgebildet werden können. Zudem wird die SkillMap, ein Werkzeug zur Visualisierung von Expertennetzwerken auf Basis von XML-Daten vorgestellt. Die Visualisierung von Ontologien stellt das Bindeglied und den Übergang von der WPIM- Prozessontologie hin zur Entwicklung der WPIM-Expertenontologie dar Treebolic Generator mit Browser Der Treebolic Generator ermöglicht die Visualisierung von Information, z. B. von strukturierter Information aus XML-Dokumenten. Der zugehörige hyperbolische Browser von Bou ist verfügbar unter der GNU Genaral Public License (GPL) und kostenfrei abrufbar 242. Mit dem Treebolic Generator können sehr einfach Taxonomien erzeugt und grafisch dargestellt werden. Durch klicken auf einzelne Konzepte wird das ausgewählte Konzept dynamisch zum zentralen Konzept in der Darstellung. Je nach Anzahl der eingeblendeten Untergruppen verschwinden Konzepte, die zu weit entfernt sind, vom zentralen Konzept. Ebenso kommen neue Konzepte hinzu, die mit dem ausgewählten Konzept in enger Verbindung stehen. 198 Abb. 4.43: Treebolic Browser: Hierarchischer WPIM-Innovationsprozess in XML In der Bedienleiste [vgl. Abb. 4.43] kann, angefangen beim Generator über die (abgebildete) grafische Darstellung bis hin zur Darstellung als DOM mit NoteID und Labels gewählt werden. Zudem stehen Darstellungen als XML, Text sowie HTML zur Verfügung. Treebolic Generator und der Browser sind Java-Applikationen und laufen auf allen Java2-enabled-Plattformen. 242 Treebolic -

223 Operationalisierung der WPIM-Pipeline Abb. 4.44: Treebolic Browser, Dateisystem in hyperbolischer Darstellung Treebolic [vgl. Abb. 4.44] kann XML-Beschreibungen als Baumstrukturen grafisch aufbereiten. Die Beschreibung muss wohlstrukturiert sein und konform zum XML-Schema. Derartige XML- Dateien können mit Standard-XML-Werkzeugen oder auch den meisten Texteditoren erzeugt werden. Zudem gibt es anwendungsspezifische Werkzeuge, aus denen XML-Code ausgeleitet werden kann, zu diesen XML-Generatoren zählt der Treebolic Generator 243. Treebolic ist ein Java-Applet, mit dem Ziel, hierarchische Daten hyperbolisch 244 aufzubereiten. Eine Baumstruktur wird dargestellt durch Knoten und Kanten, die Relationen zwischen Knoten werden als gewölbte Kanten visualisiert daher die Bezeichnung hyperbolisch Werkzeuge zur Visualisierungen von Ontologien TouchGraph Visualization (TGViz 245 ) ist ein Plug-in, ein sog. Tab für Protégé. Der TGViz Tab ermöglicht es, Ontologien mit der TouchGraph 246 Bibliothek zu visualisieren und stellt dazu Java-Bibliotheken zur Renderung von Netzwerken und für interaktive Graphen zur Verfügung. Die TouchGraph-Bibliothek wurde im Rahmen dieser Arbeit als Tab Plug-in in Protégé eingebunden und für WPIM erprobt. OWLViz wurde als Protégé-OWL-Visualisierungs-Plug-in 247 an der University of Manchester entwickelt und setzt auf dem Protégé-OWL-Plug-in auf. Die Klassenhierarchien der kreierten OWL-Ontologie können mit OWLViz abgebildet und mit der inferentiell ermittelten Klassenhierarchie der Ontologie verglichen werden. Dabei werden unterschiedliche 243 Der Treebolic Generator bei Sourceforge Hyperbolische Darstellung TGViz Version 1.4.2, Stand April TouchGraph

224 Operationalisierung der WPIM-Pipeline Farbschemata verwendet und Inkonsistenzen in roter Farbe markiert. Die erstellten und die inferierten Views der Klassenhierarchie können in verschiedenen Grafikformaten gespeichert werden, u. a..png,.jpeg und.svg [http://www.co-ode.org/downloads/owlviz/]. OWLViz wurde als Teilumfang des CO-ODE Projekts 248 von Horridge entwickelt und ist unter der Lesser GNU Public License lizenziert. OWLViz nutzt die Darstellungs-Algorithmen bereitgestellt durch die Graph Visualization 249 Bibliotheken und die Batik Libraries 250 der Apache Software Foundation SkillMap zur Visualisierung von Expertise und Expertennetzwerken Die SkillMap 251 nach [SpMH05; SpMe06] der Humboldt Universität (HU) in Berlin ist ein webbasiertes, verteiltes System zur Visualisierung von Organisationen, ihrem Wissen und der Expertise ihrer Mitglieder. Die SkillMap kann unter [http://ioe-skillmap.hu-berlin.de] als web basierte Java-Anwendung in einem Gastzugang erprobt werden. Passwort: guest und Benutzername: guest sind ebenfalls der Webseite zu entnehmen. Benötigt wird das Java Runtime Environment 252 (JRE) sowie Java-WebStart 253. Abb. 4.45: Graphenstruktur des SkillMap Systems [SpMH05, SpMe06] Es gibt drei Ansichten in der SkillMap-Anwendung. In [Abb. 4.46] ist das social Network, also das soziale Netz des Wissensaustausches zwischen den Nutzer/-innen zu sehen. Jeder gibt für sich an, mit wem er Wissen austauscht und wie intensiv dieser Austausch ist. Es können nur Austauschbeziehungen angelegt oder verändert werden, die einen selbst betreffen. Der Graph repräsentiert das soziale Netzwerk auf Basis des Wissensaustausches der Personen untereinander. Die Intensität des Wissensaustausches ist durch die Stärke der Kanten zwischen den Personen gekennzeichnet. Fährt man mit dem Mauszeiger über eine Kante kann man in der Statuszeile am unteren Rand des Bildschirms die Intensität ablesen. [SkMa07] Die Intensität wird durch x von sechs ausgedrückt, wobei x gleich sechs die maximale Intensität wiedergibt. 248 CO-ODE SkillMap Flyer JRE, frei verfügbar unter

225 Operationalisierung der WPIM-Pipeline Abb. 4.46: SkillMap mit aktivem sozialen Netzwerk einer Person In [Abb. 4.47] sind zwei Sichten der SkillMap integriert gezeigt. Zum einen ein hierarchischer Baum der Kompetenzen, die in der Organisation vorhanden sind, das sog. Skill Inventory. All das, womit sich ihre Mitglieder auskennen und wofür sie sich interessieren. Wenn ein Spezialoder Interessensgebiet nicht vorhanden ist, kann dieses hinzugefügt werden. Zum anderen in [Abb. 4.47] integriert dargestellt, wird das bereits vorgestellte soziale Netzwerk abgebildet. Alle Nutzer/-innen des Systems können dieses Netzwerk verändern oder erweitern [vgl. SkMa07]. Abb. 4.47: SkillMap: Experten mit Arbeitsschwerpunkt Wissensmanagement 201

226 Operationalisierung der WPIM-Pipeline [Abb. 4.47] zeigt die Ansicht SkillMap. Darin sind die Arbeitsgebiete und Expertisen von Projektmitgliedern und deren Austausch untereinander als Netzwerk visualisiert. Die SkillMap ist eine Kombination aus dem Social Network [vgl. Abb. 4.46] und dem Skill Inventory. Alle Nutzer/-innen können dieses Netzwerk verändern und sich selbst, aber auch anderen Expertisefelder hinzufügen, diese ändern oder entfernen [SkMa07]. Die Betrachtung zur Entwicklung und Visualisierung der WPIM-Ontologie zu WPIM-Prozessen und Ressourcen schliessen wir hiermit ab. In der WPIM-Pipeline werden darauffolgend die WPIM-Prozessontologie und die WPIM-Expertenontologie zusammengeführt und gemeinsam erweitert [vgl. Kap. 4.11]. Im weiteren Verlauf der Arbeit wird nun die WPIM- Expertenontologie entwickelt. Diese ermöglicht den Aufbau eines semantischen Expertennetzwerks Experten, Netzwerke und bestehende Ontologien In Unternehmen der fertigenden Industrie werden zur Identifikation von Experten sog. Gelbe Seiten 254 oder Abteilungsverzeichnisse verwendet. In diesen Verzeichnissen sind die Profildaten der Experten hinterlegt. Suchfunktionen werden häufig auf Basis syntaktischer Volltextsuchen unterstützt. Semantische Experten-Netzwerke werden bisher nur selten in Unternehmen der fertigenden Industrien eingesetzt. Das im Rahmen des WPIM-Prototyps entwickelte semantische Expertennetzwerk Expert-to-Expert (E2E) bietet ebendiese semantischen Erweiterungen. Das E2E mit den semantisch annotierten Expertenprofilen nimmt im weiteren Verlauf der Arbeit eine zentrale Rolle ein. Das E2E stellt einerseits den Zugang der Experten zur prototypischen WPIM- Anwendung bereit. Andererseits werden eben die im E2E hinterlegten Profile (als Repräsentation eines realexistenten Experten) verwendet, um den Aktivitäten im Innovationsprozess, einen Aufgabenträger, Ansprechpartner oder Verantwortlichen zuzuweisen. Das E2E zeigt zudem grundlegend die wesentlichen Komponenten sowie Strukturen und Funktionsweisen von semantischen Netzwerken auf. Die Benutzung von syntaktischen und semantischen Netzwerke ist identisch: Zunächst legen die Experten Profile zu ihrer Person an und vernetzen sich dann über Referenzen (engl. links) mit weiteren Personen, wie z. B. Experten, Arbeitskollegen oder Geschäftsfreunden. Um jeden Experten entsteht somit ein Netzwerk, in welchem der Experte selbst das Zentrum ausbildet Bestehende Experten-Ontologie Im Folgenden werden Ontologien aus den Bereichen Personal- und Expertenmanagement sowie zu den Themenbereichen Lernen und Engineering untersucht. Benötigte Klassen und Relationen sollen identifiziert und auf das Expertennetzwerk und die Experten-Ontologie von WPIM übertragen werden. Vorgestellt werden nun Ansätze und Ontologien aus den Bereichen Expertenmanagement und professionelles Lernen. Eine Ontologie, die sich mit den Strukturen und Hierarchien von Experten und Mitarbeitern in fertigenden Industrien befasst, konnte bisher nicht identifiziert werden Professional Learning Ontology Die Ontologie wurde von Schmidt/Kunzmann vom Forschungszentrum Informatik in Karlsruhe am Institut Information Prozess Engineering 255 (IPE) im Projekt Lernen in Prozessen entwickelt. Die Professional Learning Ontology ist eine Top-Level-Ontology für Kompetenz-Management 254 Gelbe Seiten: Eine besondere Form von Wissensträgerkarten, in denen das Zusammenspiel von Fach-, Methoden- Sozial- und personaler Kompetenz der Mitarbeiter beschrieben wird. Sie tragen ganz wesentlich zur innerbetrieblichen Kommunikation bei [http://www.community-of-knowledge.de/cp_artikel.htm?artikel_id=39]

227 Operationalisierung der WPIM-Pipeline und technologiegetriebenes Lernen am Arbeitsplatz. Die Competency.owl Ontologie wurde in OWL erstellt und ist online abrufbar 256. Dabei werden folgende typische Szenarien betrachtet [vgl. ScKu06]: Arbeitsbegleitende Empfehlung von Lern-Ressourcen, Expertensuche und Planung von Trainingsprogrammen. Abb. 4.48: Überblick zur Professional-Learning-Ontologie [ScKu06] Ein Import der Competency.owl Ontologie in Protégé konnte technisch realisiert werden. Einer Weiterverarbeitung steht technisch somit nichts im Weg. Für diese Arbeit fließen einige Konzepte und Klassen der Competency.owl zur Kompetenz und Expertise von Mitarbeitern in das E2E, die Expertenprofile und die WPIM-Expertenontologie ein ExperOnto, Fraunhofer IITB Leuchter, Reinert und Schönbein [LeRS06] beschreiben die ontologische Repräsentation von ingenieurwissenschaftlicher Expertise. Semantische Anwendungen verwenden für die in ihnen gespeicherte und verarbeitete Information eine explizite Repräsentation der zugrunde liegenden Konzepte und Relationen in Form einer Ontologie. [LeRS06] Dazu wurde eine Ontologie zur Repräsentation ingenieurwissenschaftlicher Expertise entwickelt. Bei der Konstruktion der Ontologie kommt die empirische Methode, die Card Sorting Task zur Auswertung einer Clusteranalyse zum Einsatz. Die webbasierte prototypische Anwendung ExperOnto zur Expertensuche in virtuellen Organisationen wird in [LeRS06] erläutert. Als Anwendungsbeispiel wird die Zusammenstellung von interdisziplinären Projektteams in großen, verteilten Organisationen und virtuellen Unternehmen herangezogen. Dazu müssen die Profile

228 Operationalisierung der WPIM-Pipeline der Mitarbeiter erfasst sein und auf semantischer Ebene die zugehörigen Kompetenzen/Expertisen repräsentiert und verarbeitet werden. Als Expertise bezeichnen die Autoren sowohl deklaratives Wissen ( was ) als auch prozedurales Wissen ( wie ) [LeRS06]. Als Beispiele für deklaratives Wissen nennen sie: Fakten, Konzepte, Beziehungen zwischen Konzepten, Regeln und einschränkende Bedingungen. Für prozedurales Wissen führen sie Fähigkeit zu Schlussfolgerungen, Auswahl geeigneter Vorgehensweisen und Anwendung von Problemlösungsprinzipien an [LeRS06, S. 22]. Einen weiteren Anknüpfungspunkt zu Experten in Innovationsprozessen bei WPIM sehen wir in der Aussage von Leuchter et al.: Problemstellungen im Bereich der Ingenieurwissenschaften, die durch Expertenwissen gelöst werden, sind anwendungsorientiert. [LeRS06] Leuchter et al. beschreiben ExperOnto als Top-Level-Ontology: Für die Anwendung zur Expertensuche wurde ein Modell zur Repräsentation ingenieurwissenschaftlicher Expertise, in Form einer Top-Level Ontologie, die leicht erweitert bzw. angepasst werden kann, entwickelt. [LeRS06] Über die Ontologie werden Personen mit Technologien, Projekten und weiteren Konzepten verknüpft. [Rein06, S. 12] ExperOnto ist eine Java 2 Platform Enterprise Edition (J2EE) Anwendung, die Wissensrepräsentation erfolgt in OWL mit dem Werkzeug Protégé. Die Ontologie wurde mit 480 Konzepten und 190 Relationen implementiert [vgl. LeRS06]. Auch hieraus werden Klassen und Konzepte in die WPIM-Expertenontologie übernommen. Im weiteren Verlauf werden Soziale- und Experten-Netzwerke vor dem Ziel analysiert, Konzepte aus diesen in die WPIM-Anwendung einfliessen zu lassen, bzw. entsprechende Profile weiter zu nutzen und diese in die Anwendung zu integrieren Soziale- und Experten-Netzwerke sowie deren Anreizsysteme Lokalisten.de 257, asmallworld.net 258, StudiVZ.net 259 ermöglichen es den Nutzen, ein Profil ihrer Person zu erstellen. Diese (Experten-) Profile können virtuell mit (Experten-) Profilen weiterer Nutzer/Experten verlinkt werden. Ein soziales oder auch ein Experten-Netzwerk entsteht. Diese Netzwerke basieren auf dem 6-Ecken-Theorem, welches besagt, dass sich die gesamte Menschheit über maximal sechs Ecken kennt. Einige soziale Netzwerke sind Netzwerke zur Pflege von Kontakten. Mangelnde Seriosität disqualifiziert einige als Experten-Netzwerke. Bei wissenschaftlichen Experten-Netzwerken qualifizieren Veröffentlichungen erst zu einer Teilnahme im Netzwerk. Die Mitglieder werden kategorisiert, allerdings kann man seinen Status durch finanzielle Aufwendungen verändern bzw. verbessern. Das Konzept, rein über Reputation den Status zu beeinflussen, greift somit nicht ausschließlich. Bei einigen Netzwerken steht auch das finanzielle Streben der Betreiber im Vordergrund. Solange der Nutzer keine Premium- Mitgliedschaft erworben hat, sind nicht alle Funktionen verfügbar. Alumni-Netzwerke stehen nur einem begrenzten Teilnehmerkreis zur Verfügung, bzw. der Beitritt ist an konkrete Voraussetzungen gekoppelt. Das von E2E angestrebte Konzept, alle Mitarbeiter in- und außerhalb des Unternehmens jederzeit erreichen zu können, wird von den aufgeführten sozialen Netzwerken stark begrenzt. Wie die meisten Firmennetzwerke lassen diese sozialen Netzwerke die Erstellung von individuellen Profilen zu, semantische Beschreibungen werden jedoch gänzlich vernachlässigt oder nicht berücksichtigt. Somit sind diese Netzwerke nur bedingt zur maschinellen Auswertung und auch nicht zum Durchsuchen mittels Softwareagenten oder semantischen Suchen geeignet. BrainGuide.de 260 und auch Xing.com 261 gelten als Experten- 257 Soziales Netzwerk Soziales Netzwerk Studenten Netzwerk Experten Netzwerk

229 Operationalisierung der WPIM-Pipeline Netzwerke. Eine Positionierung über Expertise und kommerzielle Verknüpfung durch verschiedene kostenpflichtige Profile ist möglich. Weitere Eigenschaften können hinterlegt werden, z. B. Bilder, zusätzliche Kategorien, in denen ein Experte über Know-how verfügt, können angelegt werden. Die vorgenannten Ansätze sind webbasierte Online-Netzwerke offen für verschiedene Benutzungsgruppen. Es gibt aber auch Ansätze, die speziell auf Personengruppen eines Unternehmens oder Vereinigungen von Organisationen begrenzt sind, wie z. B. Absolventen Netzwerke, Alumni- und Ehemaligen Netzwerke, wie z. B. WiAi.de 262 der Otto Friedrich Universität in Bamberg. Es folgt eine Machbarkeitsstudie zum Auslesen bestehender Profildaten Machbarkeitsstudie: Auslesen von Profildaten aus Facebook Exemplarisch wird eine kleine Applikation (facebook.php) implementiert, die es ermöglicht, aus einem persönlichen Sozialen Netzwerk die Namen der verbundenen Freunde zu extrahieren. Dies erfolgt über eine speziell von Facebook zur Verfügung gestellte Schnittstelle, die Facebook-API. Abb. 4.49: WPIM-Applikation integriert bei Facebook.com Persönliche Kontaktdaten wie oder Telefonnummern werden von Facebook über die Facebook-API allerdings nicht bereitgestellt. Das verfolgte Ziel, umfassende Experten-Profile inklusive Kontaktdaten aus diesem Netzwerk extrahieren zu können, konnte somit leider nicht vollständig realisiert werden. Grund hierfür sind die vorherrschenden Datenschutzbestimmungen und Richtlinien des Betreibers. Die Extraktion durch die implementierte PHP-Datei (WPIM_Test_App) hat die technische Machbarkeit der Datenextraktion aus sozialen Netzwerken grundlegend demonstriert. Somit kann der Auslesevorgang trotz Unvollständigkeit als technisch machbar und als Erfolg gewertet werden. 261 Experten Netzwerk WiAi Alumni Netzwerk Wirtschafts- und Angewandte Informatik, Otto-Friedrich Universität, Bamberg. 205

230 Operationalisierung der WPIM-Pipeline Abb. 4.50: PHP-Skript Test-App zum auslesen von Facebook-Profilen In [Abb. 4.50] werden aus einem individuellen Profil Daten, wie z. B. die ID zu einer Person sowie alle in dem persönlichen Netzwerk enthaltenen Personen ausgelesen. Die Nutzung bestehender Daten in sozialen Netzwerken und der Zugriff über den WPIM-Prototyp wird im Sinne der Evaluation in [Kap. 5] aufgegriffen. Die Machbarkeit des Daten-Zugriffs über ein Web-Interface auf Profildaten in sozialen Netzwerken wird hierbei demonstriert. Des Weiteren gibt es ein OpenSocial-API, die Zugriffe auf soziale Netzwerke ermöglicht. OpenSocial 263 API Developer's Guide (v0.6) beschreibt diese API für soziale Netzwerke. Die Entwicklung wird von Google getrieben. Our doors are open to OpenSocial developers titelt die zugehörige OpenSocial-Homepage 264 am 4. Februar 2008 und ruft offiziell zur Weiterentwicklung der Schnittstellen (engl. interfaces) auf Anreizsysteme in Sozialen-Netzwerken zur Wissensteilung Personalfachleute und Kommunikationsspezialisten können in diesen (z. B. grafischrepräsentierten) sozialen Netzwerken analysieren, welche Mitarbeiter als sog. Kommunikatoren agieren und dadurch die Zusammenarbeit von Abteilungen im/zwischen Unternehmen begünstigen. Solche Kommunikatoren sollten dann auf entsprechenden Schlüsselpositionen eingesetzt werden. Hingegen sind sog. Isolatoren, das sind Personen, die wenig oder kaum Kontakt zu Kollegen haben/pflegen, stärker einzubinden oder mit zusätzlichen Kommunikationsmitteln auszustatten, um erwünschte Kommunikationswege gezielt aufzubauen. Durch Etablierung eines geeigneten Anreizsystems können Experten zur Wissensfreigabe in diesem Netzwerk motiviert werden. Völker, Sauer und Simon berichten zur Wissensteilung und zum Einsatz von Anreizsystemen: Die generelle Verwendung von Anreizsystemen in Unternehmen bezogen auf das Wissensmanagement ist rückläufig. [VöSS07] Dies begründen [VöSS07] über die Erkenntnis des Nutzens der Wissensteilung bei den Mitarbeitern und werten dies als weit stärkere Motivation bei einem Konzern als sämtliche Anreizsysteme. [vgl. VöSS07, S. 123] Weiter berichten die Autoren [VöSS07], bei dem analysierten Automobilhersteller soll eine Kultur der Offenheit und des Vertrauens sowie des Wissenstransfers durch Management by Objectives erreicht werden. Klare Ziele sind zu vereinbaren und ein permanenter Wissensaustausch ist zu dieser Zielerreichung notwendig

231 Operationalisierung der WPIM-Pipeline [VöSS07, S. 126] Der Gedanke, eine wissensorientierte Unternehmenskultur zu prägen, ist nicht neu [Will04, S. 68], ebenso wie das Schaffen von Vertrauen [Prob99, S. 74 u. S. 383; Nort02, S. 28]. Die angesprochenen Zielvereinbarungen zur Wissensteilung sind ggf. einzeln mit den Mitarbeiter zu vereinbaren, um ein individuell-ausgerichtetes Anreizsystem aufzubauen. Ob monetär oder nicht-monetär soll hierbei offen bleiben. Unternehmensgesteuerte Motivation und Anreize sind wichtig, um den Erfolg von WPIM langfristig zu sichern. WPIM stellt softwaregestützte Methoden in der WPIM-Anwendung zur Wissensteilung zur Verfügung, deren Einsatz vom Management ggf. durch Anreize gefördert werden sollte. Im weiteren Verlauf folgt zunächst die technische Implementierung des semantischen Expertennetzwerks, das dann in die WPIM-Pipeline eingebunden wird Implementierung des semantischen Expertennetzwerks (E2E) Im Rahmen dieser Arbeit wird das sog. Expert-to-Expert Netzwerk (E2E) prototypisch implementiert. Das E2E fließt direkt in die WPIM-Pipeline [vgl. Kap. 4.11] und später in die WPIM-Anwendung ein. Semantische Expertennetzwerke sind Netzwerke über und zwischen Experten. Als Besonderheit sind die Experten-Profile und die zugehörigen Relationen semantisch beschrieben. Das E2E wurde implementiert um den Aufbau, den Zugriff sowie die Vernetzung von Experten untereinander aufzuzeigen. Da Experten bei WPIM und in Innovationsprozessen eine entscheidende Rolle einnehmen, hilft das E2E, den Aufbau von Experten-Ontologien und Organisations-Hierarchien besser zu verstehen. Neben der Implementierung des Expertennetzwerks wird erweiternd auf semantische Umfänge in und semantische Verknüpfung (engl. relation) zwischen den Expertenprofile eingegangen Komponenten des E2E-Expertennetzwerks Beim E2E-Expertennetzwerk wird über ein Web-Frontend ein Eingabeformular für die Expertendaten und Expertenkontakte bereitgestellt. Die eingetragenen Daten der Experten werden über das Formular POST-Methode und ein PHP-Skript an den localhost übergeben. Nachstehend die zugehörige HTML-Anweisung: <form method="post" action="//localhost/indatei.php"> Code 4.15: POST-Methode bei PHP-Formularen Der Konsistenzcheck der Eingaben, z. B. dass s enthalten müssen, wird vor dem Absenden des Formulars durch klientseitige Java-Skripte sichergestellt. Danach werden die Eingabedaten, in dieser Applikation, an das PHP-Skript mit dem Dateinamen (indatei.php) übergeben. Dieses serverseitige Skript übernimmt u. a. die Aufgabe, die vom Experten eingegebenen Daten in einem persistenten Datenspeicher abzulegen. Zudem bereitet dieses PHP- Skript die Daten auf, beschreibt sie mit dem FOAF-Vokabular und legt diese semantischrepräsentierten Daten (als visualisierbares Profil) in einer HTML-Datei ab. Die einzelnen semantischen (Experten-) Profile [vgl. Abb. 4.51] können bei Bedarf über den Browser angezeigt werden. 207

232 Operationalisierung der WPIM-Pipeline Abb. 4.51: Experten-Profile und Experten-Übersicht A-Z Die Experten-Profile werden als.html und.txt Datei abgelegt. Bilddateien werden zudem als.jpg gesichert. Eine zusätzliche Übersichtsseite Experten A-Z, verfügbar als AlleExperten.htm [vgl. Abb. 4.51], beinhaltet Referenzen zu allen angelegten Experten-Profilen. Diese Übersicht wird nach dem Absenden eines neuen Formulars/Profils durch einen Experten automatisch generiert, aktualisiert und im Dateisystem abgelegt Dienst zum Hochladen von Bildbeschreibungen In der WPIM-Anwendung soll es möglich sein, Profil-Bilder direkt einzubinden, ebenso aber auch Referenzen auf anwendungsexterne Bilder zu setzen. In der FOAF-a-Matic ist keine Funktion zum Hochladen von Bildern vorgesehen. Die FOAF-a-Matic läuft rein serverseitig ab, und bietet deshalb keine Speichermöglichkeit für Profil-Bilder. Im Formular ist nur die Möglichkeit gegeben, einen Link zu einer Bildbeschreibung (engl. depiction) anzugeben. Dazu wird die Datei E2E.htm mit dem Texteditor geöffnet und modifiziert: <td>link zur Ihrem Bild</td> <td><input type="text" name="depiction"></td> Code 4.16: Bildbeschreibung in Textformat Für das E2E wird das Formular mit dem Namen friends entsprechend erweitert. Die Methode post zum Versenden des ausgefüllten Formulars an des PHP-Skript indatei.php zur Ablage der Daten, bleibt unverändert. Hinzu kommt enctype= multipart/form-data, damit wird erschlossen, dass innerhalb des Formulars auch von type= text abweichende Daten also in diesem Fall Bild-Dateien, wie z. B. im JPEG-Format an den Server gesendet werden können [vgl. KoÖg06]. <form name="friends" accept-charset="utf-8" action="indatei.php" method="post" enctype="multipart/form-data"> Code 4.17: Übermittlung von Daten an den Server in das File indatei.php Mit <input type="file" name="datei"> wird ein neues Eingabefeld im Formular angelegt mit dem Namen datei. Durch type="file" wird automatisch hinter diesem Eingabefeld eine Schaltfläche (engl. button) Durchsuchen angelegt, mit dem der Experte seine lokale Dateistruktur nach seiner Bildbeschreibungsdatei durchsuchen kann. Sofern er eine Bilddatei hinzugefügt hat, erscheint der zugehörige Link im Eingabefeld des Formulars und die Datei wird beim Versenden des Formulars an das PHP-Skript übergeben. <input type="hidden" value="204800" name="max_file_size"> <td>bild UpLoad (max. 200kB)</td><td><input type="file" name="datei"></td> 208 Code 4.18: UpLoadOptionen: Festlegen von FileSize für Dokumente

233 Operationalisierung der WPIM-Pipeline Die hochgeladene Datei wird serverseitig zunächst nur temporär gespeichert und muss noch in die Ablagestruktur für Expertendaten auf dem Server persistent gespeichert werden. Dazu wird in der Datei (indatei.php) das PHP-Skript erweitert: if (move_uploaded_file($_files['datei']['tmp_name'], '/htdocs/experten/'. $surname. '_'. $firstname. '.jpg')) {echo 'Ok.';} else{echo 'Fehler, Datei konnte nicht geladen werden.';} Code 4.19: Überprüfen des UpLoads und Ausgabe der Ergebnisse der Prüfung Das Skript prüft, ob die Datei korrekt hochgeladen wurde und speichert die Bildbeschreibung mit der Methode move_uploaded_file in das Verzeichnis /htdocs/experten/ mit dem instanziell bedingten Dateinamen Nachname_Vorname.jpg, der aus den eingegebenen Variablen des Formulars generiert wird. Ein ähnliches Beispiel zum Hochladen von Bildern unterschiedlicher Dateitypen bieten Kofler/Öggl in [KoÖg06] Dateisystem und Speicherung der Daten Eine Schnittstelle wurde geschaffen, um die inhaltlichen Daten der FOAF-Beschreibung als.txt- Datei sowie als.htm in ein Datei-System auszugeben und zu archivieren. Dazu wird für jede Person ein eigener Ordner, der den Vor- und Zunamen der Person trägt, angelegt, indem beide Dateien (NachnameVorname.txt und NachnameVorname.htm) aufbewahrt werden. Eine inhaltliche Änderung der Dateien ist derzeit nicht möglich, vielmehr muss die FOAF- Beschreibung neu angelegt werden und überschreibt dann die bestehende veraltete FOAF- Beschreibung einer Person. Je nach Zugriffsrechten werden Details zu den Experten gelistet. Wir fassen diese Expertenübersicht in einer A-Z Übersicht der Expertenprofile [vgl. Abb. 4.51] zusammen. Per Klick kann alphabetisch gesucht werden. Die Suche erfolgt alphabetisch nicht phonetisch 265 oder semantisch. Ein Herr Maier mit abweichender Schreibweise, z. B. ei, ay, wird somit nicht gefunden [Borm04]. Entsprechend phonetische Algorithmen, wie z. B. Sondex 266, sind in der Praxis bereits implementiert. Das semantische Expertennetzwerk E2E nimmt für die WPIM-Pipeline eine zentrale Rolle ein, da der Zugang und Einstieg in die entstehende WPIM- Anwendung eben über das eigene Expertenprofil mit den personenbezogenen Zugangsdaten erfolgt. Im weiteren Verlauf der Arbeit ist die Implementierung der WPIM-Pipeline dargestellt Implementierung der WPIM-Pipeline Dieser Abschnitt stellt die zentrale Entwicklung und Implementierung der prototypischen WPIM-Pipeline (auch als WPIM-Prototyp bezeichnet) vor. Die WPIM-Pipeline setzt die einzelnen Methoden und Ansätze von WPIM in Diensten 267 softwaretechnisch um. Dabei werden nicht länger Konzepte betrachtet, sondern gezielt Klassen und digitale Objekte zu Innovationsprozessen und Ressourcen. Ziel der WPIM-Pipeline ist es, Prozessmodelle und Ressourcenmodelle zu entwickeln, diese zu repräsentieren, zu integrieren und (semantisch) zu erweitern. Die Dienste der WPIM-Pipeline zeigen die Machbarkeit des Datenhandlings über verschiedene Formate und Repräsentationen sowie die zugehörige Benutzerinteraktion auf. Die nachgelagerte Implementierung der WPIM-Anwendung als Semantic Web Anwendung kann als vertiefende Engineering-Aufgabe betrachtet werden. Es bleibt zu hoffen, dass Erweiterungen zu WPIM sowie weitere und weiterführende Implementierungen der WPIM-Methoden, WPIM- Dienste und WPIM-Modelle folgen. Im weiteren Verlauf der Arbeit werden die einzelnen Schritte durch die WPIM-Pipeline im Detail entwickelt und in einer Übersicht dargestellt. 265 Bei herkömmlichen also syntaktischen Suchen spricht [Borm04] vom String-Matching, bei phonetischen Ansätzen vom phonetischen Abgleich [Borm04] Dienste im Sinne der Funktionalität der WPIM-Pipeline. 209

234 Operationalisierung der WPIM-Pipeline Modellierung des Innovationsprozesses Als ersten Schritt in der WPIM-Pipeline gilt es, den Innovationsprozess zu modellieren. In [Kap. 2.5] wurden verschiedene Modellierungswerkzeuge für die Modellierung von Prozessen und insbesondere Innovationsprozessen untersucht. Die Wahl ist auf das Werkzeug Business Process Visual Architect (BPVA) gefallen. Die [Abb. 4.52] zeigt einen exemplarischen Prozess (2008_WPIM_Projekt.bpva) modelliert mit dem Werkzeug BPVA. Gezeigt wird die Prozessstruktur sowie die Reihenfolge und die Abhängigkeit von acht Aktivitäten. Zur Visualisierung wird für eine Aktivität in BPVA ein gelbes Rechteck, für eine Entscheidung eine orange Raute verwendet. Abb. 4.52: Exemplarischer Innovationsprozess modelliert im Werkzeug BPVA Des Weiteren wird in [Abb. 4.52] ein Pool modelliert als türkises Rechteck dargestellt. Darin sind drei Aufgaben (engl. activities) sequenziell in diesem Aufgaben-Pool zusammengefasst. Mögliche Eigenschaften des Aufgaben-Pools sind u. a., dass dieser Aufgaben-Pool, z. B. von einem Aufgabenträger bearbeitet, an einem Standort durchgeführt, auf ein Dokument oder Patent angewiesen ist oder durch einen Mitarbeiter verantwortet wird. Der in [Abb. 4.53] modellierte Ausschnitt des Prozessmodells zeigt drei Aufgaben (Aufg_1, Aufg_2, Aufg_3) als Bestandteile des Pools (WPIM_Pool_1). Dieser Pool kann z. B. als Phase mit drei Aktivitäten verstanden werden, auch eine Interpretation des Pools als Abteilung mit drei Aufgaben ist möglich. Abb. 4.53: Hierarischer Ausschnitt aus dem Prozessmodell Die intuitiv erkennbaren Konzepte (Aufg_1, Aufg_2, Aufg_3 und WPIM_Pool_1) sind nochmals 210

235 Operationalisierung der WPIM-Pipeline zusätzlich zur Veranschaulichung als Strukturblöcke in die [Abb. 4.53] integriert. Diese Darstellung wird in [Abb. 4.55] aufgegriffen und in [Abb. 4.59] erweitert Export und Speicherung des modellierten Prozesses als XML Nach der Modellierung des Innovationsprozesses in BPVA erfolgt die Extraktion der modellierten Prozessbausteine als nächster Schritt in der WPIM-Pipeline. Als strukturierende Sprache wird auf das Datenaustauschformat XML zurückgegriffen. XML steht als Export- Format bei PBVA zur Verfügung, wird von den Im- und Export-Funktionen in Protégé unterstützt und kann durch die semantischen Umfänge von RDF zu RDF/XML erweitert werden. Nach der Überführung der Prozess-Konzepte aus BPVA in XML-Notation erfolgt die lokale Speicherung der Exporte. Durch einen Import der in XML serialisierten Prozesskonzepte kann in Protégé ein Prozessmodell in RDF/RSDS oder eine Prozess-Ontologie in OWL erzeugt werden. Zur Darstellung des Prozessmodells repräsentiert in XML in [Abb. 4.54] wird XMLSpy gewählt. Prinzipiell ist jeder XML-Editor zur Darstellung geeignet. Auch eine rückwärtige Überführung dieses XML-Baums in die grafische Darstellung im Werkzeug Business Process Visual Architect ist möglich. Dabei treten keinerlei Verschiebungen, Vermischungen oder Verluste bei den Konzepten oder Attributen (z. B. technische Attribute zur Positionierung der Prozesselemente) auf. Abb. 4.54: Prozessmodell exportiert nach XML, dargestellt im Werkzeug XMLSpy Der modellierte generische Innovationsprozess wird in das XML-Format exportiert. Hieran wird veranschaulicht, wie das grafische Prozessmodell in die hierarchische XML-Baumstruktur überführt werden kann. Das Prozessmodell wird in umfangreicher XML-Repräsentation, mit Zusatzinformation aus BPVA, in das Dateisystem gespeichert Extraktion der WPIM-Konzepte des Prozesses Aus der umfangreichen XML-Datei werden nun im nächsten Schritt der WPIM-Pipeline 211

236 Operationalisierung der WPIM-Pipeline exemplarisch die zentralen Konzepte extrahiert werden. Nach der Speicherung 268 des Prozessmodells als XML erhalten wir eine sehr aufgeblähte XML-Datei. Dargestellt im Hintergrund der [Abb. 4.55]. Zur Vereinfachung haben wir entschieden, zunächst nur einige zentrale Konzepte und Attribute in der WPIM-Pipeline zu nutzen [vgl. Abb. 4.53]. Anhand dieser ausgewählten Elemente kann die Machbarkeit der (semantischen) Annotation und die geplante Erweiterung des Prozessmodells um Ressourcen dargestellt werden. Abb. 4.55: Extraktion der Prozesselemente aus dem BPVA XML mittels indatei.php Zu den zentralen XML-Elementen zählen, u. a. wie in [Abb. 4.55] dargestellt, die Konzepte Pool und Aufgabe. Zudem auch die Elemente Prozess und Aktivität. Technische Attribute (die zur Positionierung der Prozesselemente in der BPVA-Anwendung benötigt werden) werden zunächst nach XML exportiert, diese werden aber nicht für die Weiterverwendung in der WPIM-Pipeline extrahiert. Die Extraktion der Prozesselemente erfolgt selektiv durch das PHP-Skript indatei.php. Das Skript analysiert (engl. parse) zunächst die exportierte XML-Datei, danach wird mit dem PHP-Skript Extraktion.php nach den benötigten Elementen gesucht. Diese Elemente (exakter die digitalen Objekte zu den Konzepten) werden im Kontext der für WPIM relevanten XML-Struktur extrahiert. Die Ergebnisse der Extraktion sind im linken unteren Teil der [Abb. 4.56] dargestellt: 268 Der Export eines Prozesses als XML ist eine Standardfunktion im Werkzeug BPVA. Auch weitere Werkzeuge wie der Enterprise Architect, Visio oder Aris unterstützen den Export von Prozessmodellen nach XML und sind somit als vorgelagerte Modellierungswerkzeuge für die WPIM-Pipeline geeignet [vgl. Woll10 und Küsg11]. 212

237 Operationalisierung der WPIM-Pipeline Abb. 4.56: Ergebnis des PHP-Skripts sind extrahierte Konzepte In [Abb. 4.56] sind die zentralen Elemente extrahiert und nummeriert ausgegeben. Zudem werden die extrahierten Elemente den hierarchischen Elementen bei WPIM, hier den Aufgabenpools, zugeordnet. Damit kann demonstriert werden, dass der zunächst visuellmodellierte Innovationsprozess (2008_WPIM_Projekt.bpva) exportiert aus dem BusinessProcess VisualArchitect in die XML-Notation (2008_WPIM_Projekt.xml) überführt werden kann. Aus dieser XML-Datei können anschließend gezielt (in der WPIM-Anwendung dann auch gesamt) die für WPIM relevanten XML-Elemente extrahiert werden und stehen für die folgende Annotation zur Verfügung. Bei der Extraktion unterstützt das PHP-Skript Extraktion.php, dargestellt in [Code 4.20]. Mit diesem Skript wird in der XML-Datei nach den XML-Elementen Prozess mit den zugehörigen Pools und Aufgaben gesucht. // schleife fuer Pools $xml = simplexml_load_file("project.xml"); $_result1 = echo "<hr>"; // schleife fuer Pools for($x=0;$x<sizeof($_result1);$x++) { echo ".. ". key($_result1)." - ".current($_result1). "\n"; $Pool = current($_result1); echo "<br>"; //schleife fuer Tasks $xml = simplexml_load_file("project.xml"); $_task = for($i=0;$i<sizeof($_task);$i++) { echo " ".key($_task)." - - ".current($_task). "\n"; echo "<br>"; next($_task); } Code 4.20: Ausschnitt aus dem Skript extraktion.php Das Durchsuchen des XML-Baums erfolgt über eine Volltextsuche. Dazu wird gezielt nach BPVA-spezifischen XML-Tags wie <BPtask>, <BPprocess> oder <BPpool> gesucht. Diese 213

238 Operationalisierung der WPIM-Pipeline XML-Elemente (auch XML-Tag) sind eindeutig in der DTD bzw. XSD-Datei des Werkzeugs BPVA hinterlegt. Das XML-Tag <BPtask> zeichnet Aufgaben aus, <BPpool> die Pools und <BPprocess> kommt in BPVA für Prozesse zum Einsatz Aufbau des WPIM-Klassenmodells repräsentiert in RDF Im folgenden Schritt der WPIM-Pipeline wird das Klassenmodell entwickelt und in RDF repräsentiert. Die extrahierten XML-Elemente enthalten sowohl den Element-Namen sowie die konkrete Ausprägung. In [Code 4.21] ist das XML-Element Aufgabe mit der Ausprägung Aufg_1 dargestellt. Aus softwaretechnischer Sicht stellt das XML-Tag Aufgabe die Klasse dar und die Ausprägung Aufg_1 eine Instanz. <Pool> WPIM_Pool_1 <Aufgabe> Aufg_1 </Aufgabe> <Aufgabe> Aufg_2 </Aufgabe> <Aufgabe> Aufg_3 </Aufgabe> </Pool> Code 4.21: Darstellung der XML-Tags Pool und Aufgabe mit Ausprägungen Die Idee besteht nun darin, XML-Tags und Ausprägungen in Klassen mit Instanzen zu überführen. Zudem können aus DTD-Strukturen und XSD-Hierarchien zunächst XML-Elemente abgeleitet und diese dann in Klassen-Hierarchien überführt werden, vgl. [Abb. 4.58]. Mit einem weiteren PHP-Skript (test.php) wird also eine neue kompakte XML-Datei (Project.xml) erzeugt, die der WPIM.dtd [vgl. Code 4.9 und Code 4.10] gehorcht und zudem die Konzepte, hierarchisch geordnet, im Browser ausgibt, vgl. [Abb. 4.57]. Abb. 4.57: Extraktion der Prozesselemente und Aufbau der Konzept-Hierarchie 214

239 Operationalisierung der WPIM-Pipeline Das Ergebnis ist eine kompakte XML-Datei (Projekt.xml) mit den zentralen XML- Prozesselementen des Innovationsprozesses. Zur weiteren Überprüfung der Vollständigkeit wurde eine Nummerierung der hierarchischen Ebenen und der zugeordneten Aufgaben eingefügt. Die Bezeichner der Aufgaben werden aus dem BPVA-Prozessmodell übernommen. Abb. 4.58: Hierarisch-geordnete XML-Elemente, dargestellt in XMLSyp Im rechten Fenster der [Abb. 4.58] sind die verfügbaren und verwendeten XML-Elemente aufgelistet. Die konkreten Elemente, bzw. Ausprägungen sind im linken Fenster der [Abb. 4.58] dargestellt. Daran wird belegt, dass die hierarischen Prozesselemente sowie die zugehörigen Instanzen der BPVA-Modelle vollständig in XML-Syntax überführbar und darstellbar sind. Aus technischer Sicht kann das BPVA-Schema (XSD) hinsichtlich der zentralen Elemente in das WPIM-Schema (DTD) überführt werden. Für die WPIM-Anwendung wird ebenfalls eine XSD entwickelt, die eine gesamthafte Verwendung der BPVA-XSD ermöglicht. An dieser Stelle geben wir einen Einblick zur Machbarkeit der Überführung von hierarchischen XML-Elementen nach RDF. In [Code 4.22] werden zunächst die benötigten Namensräume deklariert. Danach werden einzelne Aufgaben einem Pool zugeordnet wie konzeptionell bereits in [Abb. 4.53] dargestellt. Technisch konkret werden die Aufg_1, Aufg_2, Aufg_3 über die rdfs:subclassof- Beziehung 269 dem WPIM_Pool_1 zugewiesen. <?xml version="1.0"?> <rdf:rdf xmlns="http://www.owl-ontologies.com/ontologywpim.owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xsd="http://www.w3.org/2001/xmlschema#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://www.w3.org/2002/07/owl#" xml:base="http://www.owl-ontologies.com/ontologywpim.owl"> <owl:ontology rdf:about=""/> <rdfs:class rdf:id="aufg_1"> <rdfs:subclassof> <rdfs:class rdf:id="wpim_pool_1"/> </rdfs:subclassof> </rdfs:class> <rdfs:class rdf:id="aufg_2"> <rdfs:subclassof rdf:resource="#wpim_pool_1"/> </rdfs:class> <rdfs:class rdf:id="aufg_3"> 269 Bei der prototypischen Implementierung der WPIM-Pipeline haben wir mit RDF/RDFS und auch OWL gearbeitet. Für den WPIM-Prototyp reicht die Ausdrucksmächtigkeit von RDF/RDFS aus. Bei der implementierten, webbasierten WPIM-Anwendung kommt darüber hinaus OWL-DL zum Einsatz [vgl. Küsg11]. 215

240 Operationalisierung der WPIM-Pipeline <rdfs:subclassof rdf:resource="#wpim_pool_1"/> </rdfs:class> </rdf:rdf> <!-- Created with Protege (with OWL Plugin 3.2.1, Build 365) --> Code 4.22: Klassen-Hierarchie in RDF erstellt mit dem Werkzeug Protégé Die rdfs:subclassof-beziehung, eine Klassenbeziehung, ermöglicht eine hierarchische Zuordnung der Klassen Aufgabe und Pool, bzw. auf Instanzenebene der Elemente Aufg_1, Aufg_2, Aufg_3 zum Aufgaben-Pool WPIM_Pool_1. Durch die Verwendung von RDF/RDFS kann die Klassenhierarchie semantischen Suchen unterzogen werden. Die Überführung der XML-Datei (Projekt.xml) in die RDF-Notation erfolgt ebenfalls skriptbasiert. Die RDF-Datei wird in den Dateien Konzepte.txt, Konzepte.xml 270, Konzepte.html gespeichert zunächst mit identischem Inhalt. Die unterschiedlichen Dateitypen ermöglichen z. B. die Visualisierung in einem Browser. Speziell in der HTML-Datei wurde nachträglich zusätzlich ein Auswahlmenü zur Selektion und Zuordnung der Elemente, z. B. einer Aufgabe oder eines Pools implementiert, vgl. hierzu [Abb. 4.62]. Über diese Auswahl können in der WPIM-Anwendung einzelne Elemente gezielt ausgewählt und einer Annotation unterzogen werden. Am [Code 4.22] in Verbindung mit [Abb. 4.53] können wir die angestrebte Überführung des grafischen Prozessmodells zunächst in die verbreitete XML-Repräsentation und darauffolgend in die RDF- /XML-Syntax aufzeigen. Dies sind die Schritte in der WPIM-Pipeline, um bestehende grafische Prozessmodelle auf technischen Ebenen repräsentieren und mit Ressourcen annotieren zu können Erweiterung des Prozesses um Ressourcen Nun werden die Prozesse in der WPIM-Pipeline um Ressourcen erweitert. In [Abb. 4.59] aufbauend auf [Abb. 4.53] sind (hierarische) Beziehungen zwischen dem Aufgabenpool (WPIM_Pool_1) und den Aufgaben (Aufg_1, Aufg_2, Aufg_3) eingefügt. Abb. 4.59: Erweiterung um hierarische Beziehungen und Experten-Konzepte Zudem wird das Konzept Experte aufgenommen und in [Abb. 4.59] sind die Instanzen Exp_1, Exp_2, Exp_3 zur Klasse Experte dargestellt. Über Beziehungen (engl. relation) werden die Experten (Exp_1, Exp_2, Exp_3) mit den Aufgaben (Aufg_1, Aufg_2, Aufg_3) verknüpft. Die Interpretation der Darstellung: Jeder Aufgabe ist ein Experte zugeordnet. Auch jedem Aufgabenpool ist ein Experte zugeordnet. Kardinalitäten wurden hier nicht betrachtet. Die Zuordnungen erfolgen über Relationen. Dieser Vorgang der (semantischen) Zuordnung ist 270 Das Suffix der XML-Datei kann auch auf.rdf oder.owl lauten. Entscheidend ist, dass die Repräsentation des 216 Prozesses in XML-Notation vorliegt.

241 Operationalisierung der WPIM-Pipeline beschrieben in [Kap ] und dort insbesondere in [Abb. 4.63] Semantische Beschreibung von Ressourcen In der WPIM-Pipeline werden u. a. Experten und Dokumente als Ressourcen subsummiert. Der Schritt der semantischen Beschreibung von Ressourcen erfolgt daher zweigeteilt: Experten werden mit FOAF semantisch beschrieben und Dokumente mit den Metadaten des Dublin Cores annotiert. Das Dublin Core Element Set (DCES) stellt URIs für die wichtigsten Meta-Datentypen zur Beschreibung von Ressourcen, insbesondere von Dokumenten bereit. Der DC definiert eine Menge an Kernelementen, das sog. Dublin Core Metadata Element Set (DCMES). Damit ist es möglich, Dokumente mit maschinen-identifizierbaren und entsprechend interpretierbaren Meta- Daten zu annotieren. Somit wird ein Autor (eines Dokuments) eben als solcher interpretiert [DCES06, DCES06a]. Abb. 4.60: DCdot: Dokumente semantisch annotieren mit dem Dublin Core Element Set Auf der Seite DCdot 271 von Powell kann über Eingabemasken eine semantische Beschreibung, (engl. annotation) einer Ressource, z. B. eines Dokuments oder einer Webseite, vorgenommen werden. Die Elemente des Dublin Cores werden als Schlagworte vorgeschlagen und können manuell über eine Eingabemaske mit beschreibender Information gefüllt werden. Die Elemente werden als <Tags> repräsentiert und die Information als Inhalte in den entstehenden Containern (engl. tag) abgelegt. Die entstehende textuelle Beschreibung kann z. B. direkt in den HTML- Header der zu beschreibende Webseite kopiert werden. Die Meta-Daten sowie die Beschreibung der Ressourcen bleibt dem menschlichen Auge verborgen, wird aber von (semantischen) Suchen oder Web-Crawlern 272 gefunden. Experten (als Spezialform von Ressourcen) werden mit dem FOAF-Vokabular 273 beschrieben. Notwendige Pflichteinträge zur eindeutigen Identifikation sind Name und -Adresse. Weitere beschreibende Meta-Daten zu Personen bzw. Experten werden durch das FOAF- Vokabular bereitgestellt. Zur Erstellung eines FOAF-Profils steht die FOAF-a-Matic von Leigh Web-Crawler oder auch Web-Spider durchsuchen das Internet und erzeugen Index-Seiten. Dabei nehmen sie eine wichtige Rolle ein, bei der Positionierung von Webseiten im Index von Suchmaschinen und der Suchmaschinenoptimierung. 273 Das FOAF-Vokabular

242 Operationalisierung der WPIM-Pipeline Dodds [vgl. Abb. 4.61] bereit. Eine Besonderheit stellt dabei die foaf:knows-relation dar. Durch sie können sich zwei Experten miteinander semantisch verbinden. Diese Relation geht über eine bisherige reine Annotation (von DC und auch FOAF) durch Meta-Daten hinaus. Diese Relation setzt zwei mit FOAF beschriebene Personen in Verbindung. Durch diese Relation können beliebig viele Experten-Profile mit dem eigenen FOAF-Profil semantisch verbunden werden. Auf technischer Ebene setzt der FOAF-Indexierer die eigene FOAF-Beschreibung mit den Beschreibungen befreundeter Experten zu einem Netzwerk von in FOAF repräsentierten Individuen [vgl. Dodd06] zusammen. Die FOAF-a-Matic von Leigh Dodds [vgl. Abb. 4.61] ist unter der Creative Commons License 274 veröffentlicht und darf unter entsprechenden Bedingungen weiterverwendet werden. In der WPIM-Pipeline wird daher die rein serverseitige FOAF-a-Matic als Ausgangspunkt für Erweiterungen genutzt. Ergänzend erfolgt die Beschreibung von Experten nun auch lokal. Durch gezielte Erweiterung der FOAF-Meta-Daten können nun auch Profilbilder in die Beschreibung integriert werden. Zudem wurde ein Dateisystem zur Verarbeitung und zur persistenten Speicherung der Benutzerdaten angelegt. Die semantisch beschriebenen Experten-Profile mit Profilbild können über das Web in die WPIM- Anwendung geladen und dort visualisiert werden. Dadurch können die erweiterten semantischannotierten Experten-Profile in das Prozessmodell integriert, untereinander vernetzt und zudem maschinen-lesbar bereitgestellt werden. Somit entsteht im WPIM-Prototyp ein funktionsfähiges Expertennetzwerk mit semantisch interpretierbaren FOAF-Beschreibungen für eine maschinelle Auswertung. Abb. 4.61: FOAF-a-Matic [Dodd06]: Semantische Beschreibung von Experten mit FOAF Das HTML-Formular [vgl. Abb. 4.61] der FAOA-a-Matic sowie das bestehende Java-Skript wurden abgeändert und an die Anforderungen an Expertenbeschreibung in der WPIM-Pipeline angepasst. Zusätzlich wurde lokal eine Funktion implementiert, um das Hochladen von Bildern in die WPIM-Anwendung zu ermöglichen. Die Beschreibung der softwaretechnisch gestützten Implementierung zur semantischen Annotation der Experten-Profile wird in [Kap. 7.4 Anhang D] ausgelagert. Dort wird u. a. beschrieben, wie PHP-Skripte die Experten-Profile automatisiert annotieren sowie semantisch in FOAF-Notation und HTML repräsentieren. In diesem Abschnitt

243 Operationalisierung der WPIM-Pipeline kann dargelegt werden, wie Ressourcen insbesondere Experten mit FOAF, und Dokumente mit den Metadaten des Dublin Cores annotiert bzw. semantisch beschrieben und vernetzt werden. Die Ressourcen sind semantisch beschrieben und identifizierbar. In der WPIM-Pipeline sind die digitalen Objekte zu den repräsentierten Ressourcen nun erweiternd in das Prozessmodell zu integrieren Integration semantischer Ressourcen in das Prozessmodell Die nächsten Schritte in der WPIM-Pipeline bestehen darin, die Daten, die ein User (bzw. hier ein Experte) über sich bereitstellt (sog. Experten-Profile), in das Prozessmodell zu integrieren. In der WPIM-Pipeline sind dazu die Ressourcen, z. B. die annotierten Expertenprofile (repräsentiert mit dem FOAF-Vokabular) und die semantisch mit DC beschriebenen Dokumente, mit den Prozesselementen (repräsentiert in RDF/XML) zu integrieren. Diese digitalen Objekte zu Ressourcen, repräsentiert in FOAF und DC, werden in das RDF/XML-Prozessmodell integriert. Zudem soll das um Ressourcen erweiterte semantisch annotierte Prozessmodell semantischen Suchen unterzogen werden. Hier der Vorschlag, der in der WPIM-Pipeline beschritten wird: [Abb. 4.62] zeigt eine Eingabemaske, die bereits externalisiertes Wissen des Prozessmodells repräsentiert und die es dem Anwender ermöglicht, weitere persönliche Angaben, Attribute sowie Ressourcen zum Prozessmodell zuzuordnen. Die Zuordnung zwischen Klassen und Instanzen erfolgt hierbei über semantische Relationen die das WPIM-Vokabular bereitstellt. Abb. 4.62: WPIM Web-GUI zur Zuordnung digitaler Ressourcen zu Prozesselementen Die extrahierten Elemente aus dem Prozessmodell werden über die Eingabemaske (Process_Experten.htm) den Experten zur Verfügung gestellt. Ein Experte weist sich Aktivitäten/Aufgaben zu, an denen er mitwirkt bzw. Aufgaben/Aufgabenpools für die er Verantwortung übernimmt. Die Zuweisung wird in XML abgebildet und softwaretechnisch in die semantische RDF/XML-Notation überführt. Eine entsprechende Annotation der 219

244 Operationalisierung der WPIM-Pipeline Expertenprofile erfolgt über das Skript ExpertenAnnotation.php. In [Abb. 4.62] stehen zwei Auswahl-Menüs zur Verfügung. Das erste Menü (verantwortet/betreut/bearbeitet) ermöglicht den Anwendern die Auswahl aus drei Optionen istbearbeitervon, istexpertefür, hatverantwortungfür. Im zweiten Auswahlmenü können Aufgaben/Pools/Prozesse des Prozessmodells ausgewählt werden. Durch die beiden Selektionen wird eine Zuordnung getroffen und die gewählten Elemente (Experte und Prozesselement) relational durch die Aufgaben-Beziehung miteinander verknüpft. Eine Zuordnung erfolgt exemplarisch in [Abb. 4.62], hier wird für einen Experten die Relation hatverantwortungfür eine Aufgabe und konkret die Instanz Aufgabe8 ausgewählt. Mehrfachzuordnungen sind möglich. Die Auswahloptionen zu Klassen, Instanzen und Relationen sind durch die WPIM-Prozessontologie vorgegeben. 220 Abb. 4.63: Verwendung semantischer Relationen aus dem WPIM-Vokabular Der Vorgang der (semantischen) Zuordnung, wie in [Abb. 4.63] dargestellt, wird im Folgenden näher erläutert: Ausgangspunkt ist das Prozessmodell. In dieses in RDF/XML serialisierte Prozessmodell werden die Ressourcenmodelle zu Experten und Dokumenten, ebenfalls als XML-Repräsentationen verfügbar, integriert. Eine grundsätzliche Integration der Prozesse und Ressourcen wird in der DTD bzw. XSD-Datei auf Klassenebene vorgehalten. Die verfügbaren Relationen, die eine semantische Zuordnung ermöglichen, sind im WPIM-Vokabular angelegt. Die konkrete Zuordnung von digitalen Objekten (wie Experten und Dokumenten) zu den Prozesselementen (wie Aufgaben und Pools) erfolgt z. B. über die in [Abb. 4.62] gezeigte webbasierte grafische Benutzungsoberfläche. Das Prozessmodell (zukünftig auch die Prozessontologie) für einen konkreten Prozess wird also zunächst annotiert und dann um Ressourcen (konkret digitale Objekte, also Repräsentationen zu Experten und Dokumenten) mittels semantischen Relationen erweitert. Nach erfolgreicher Zuordnung stehen Experten in direkter semantischer Relation zu Aufgaben, z. B. über die Relationen #WirdBearbeiterDurch und #HatVerantwortungfür [vgl. Abb. 4.63]. Die beschriebenen Zuordnungen durch semantische Relationen lassen sich durch semantische Suchen eindeutig auswerten. Beabsichtigte Mehrfachzuordnungen, fehlerhafte Zuordnungen und (unbeabsichtigt) fehlende Zuordnung können analysiert und behoben werden Semantische Repräsentation in RDF und semantische Suche Wie in der WPIM-Pipeline dargestellt, wird das Prozessmodell mit Attributen beschrieben sowie

245 Operationalisierung der WPIM-Pipeline um Ressourcen wie Experten und Dokumenten erweitert. Die Prozesse und Ressourcen sind mit speziellen Vokabularen semantisch beschrieben, die Instanzen werden als digitale Objekte bezeichnet. Für Dokumente nutzen wir das Vokabular DC, für Personen/Experten das Vokabular FOAF und Prozesse beschreiben wir mit dem WPIM-Vokabular. In der WPIM-Pipeline werden die Repräsentationen der Ressourcen (Dokumente und Experten) in das Prozessmodell integriert. Als Besonderheit in der WPIM-Pipeline wird auf technischen Ebenen die Integration der Repräsentationen und Annotationen mit weiteren semantischen Relationen des WPIM- Vokabulars durchgeführt. Somit entsteht ein ressourcen-annotiertes Prozessmodell, das in serialisierter Form in RDF-/XML-Notation vorliegt. So etwas ist einzigartig und bisher in fertigenden Industrien nicht im Einsatz. In diesem erweiterten semantischen Prozessmodell kann gezielt mittels semantischer Suche nach digitalen Objekten gesucht werden. Zudem können z. B. per Inferenz neue Erkenntnisse zum Modell bzw. zur Ontologie abgeleitet werden. Dies können Erkenntnisse zu bisher unbekannten oder nicht offensichtlichen Strukturen, Klassen und Instanzen sein. Der Aufbau einer semantischen Suche, z. B. einer SPARQL-Anfrage (engl. query) hat einen Aufbau, wie dargestellt in [Code 4.23].?subject?predicate?object Code 4.23: SPARQL-Anfrage Diese komplexe Anfrage in [Abb. 4.64] stellt eine semantische Suche nach einem Dokument dar. Gesucht wird ein Dokument, das einer Aktivität (Aktivität_B) über eine Relation (zugeordnet) zugewiesen ist. Zudem soll das Dokument eine die Ziffernfolge 123 in der ID bzw. in der ISBN- Nummer enthalten (hatnummer). Weiterhin soll das Dokument über eine Relation zu einer Klasse Autor (hatautor) mit der instanziellen Ausprägung Tobias_Vogel haben. Abb. 4.64: Komplexe SPARQL-Anfrage in Protégé Als Treffer werden nicht nur Instanzen der Klasse Dokument zurückgegeben, sondern ebenfalls Instanzen aus Unterklassen der Klasse Dokument. In [Abb. 4.64] werden zur komplexen Anfrage entsprechende Patente gefunden. Neben der semantischen Suche können auch Inferenzmechanismen und Reasoner auf die ressourcen-annotierten Prozessmodelle bzw. Prozess-Ontologien angewendet werden. Einige Reasoner, wie z. B. der Reasoner Pellet 275, unterstützt zudem SPARQL-Anfragen vgl. [Kap ]. Über das Pellet-Web-Interface können Ontologien direkt eingegeben oder hochgeladen werden. Verbundene (engl. asserted) Super- und Sub-Klassen zu einer Klasse sowie auch Individuen werden aufgeführt. Zudem werden abgeleitete (engl. inferred) Instanzen ausgegeben [vgl. Abb. 4.65]. 275 Reasoner Pellet: 221

246 Operationalisierung der WPIM-Pipeline Abb. 4.65: Web-Interface zum Pellet-Reasoner [http://pellet.owldl.com] Eine Erläuterung zur Inferenz im Detail: Nach Selektion der Klasse Experte im linken Teil in [Abb. 4.65] werden im rechten Teil der Abbildung Behauptungen (engl. assertion) zu verbundenen Klassen und Instanzen abgebildet. Abgeleitet wird automatisch die Superklasse Mitarbeiter sowie gleichwertige Klassen (engl. equivalent classes) zur Klasse Experte, hier die Klassen Fachmann und die Klasse expert. Zudem wird eine Instanz Mueller zu Klasse Experte angezeigt. Die Besonderheit besteht in den abgeleiteten Instanzen (engl. inferred instances). Denn über die äquivalenten Klassen werden auch alle Instanzen dieser äquivalenten Klassen gelistet. In [Abb. 4.65] wird automatisiert erkannt, dass ein Fachmann einem Experten gleichzusetzen ist. Was auf Klasseneben abgeleitet wird, setzt sich auf Instanzenebene fort: Denn ebenfalls die Instanzen Huber und Vogel der Klasse Fachmann werden als Experten (exakter Instanzen zur Klasse Experte) erkannt. Nachdem alle relevanten Schritte der WPIM-Pipeline im Detail vorgestellt wurden, folgt nun eine zusammenfassende Darstellung der implementierten Pipeline Zusammenfassung zur implementierten WPIM-Pipeline Die WPIM-Pipeline stellt die zentrale Entwicklung dieser Arbeit dar. In den Abbildungen [Abb und Abb. 4.67] wird dazu die WPIM-Pipeline zusammenfassend präsentiert. In der linken Spalte der Abbildungen sind Screenshots der einzelnen durch den Nutzer einsetzbaren Benutzungsoberflächen bzw. Werkzeuge dargestellt in der rechten Spalte in [Abb und Abb. 4.67] eine Kurzbeschreibung und die eingesetzten Technologien. 222

247 Operationalisierung der WPIM-Pipeline Abb. 4.66: WPIM-Pipeline des WPIM-Systems I Abb. 4.67: WPIM-Pipeline des WPIM-Systems II Es wurde somit ein vollständiger Durchlauf durch die WPIM-Pipeline dargelegt. In dieser anwenderorientierten Darstellung sind weder Technologie- noch Medienbrüche aufgetreten und die WPIM-Methoden konnten erfolgreich prototypisch implementiert werden. In [Abb. 4.68] sind die entwickelten und implementierten Skripte und Schemata sowie die Daten- und Ressourcen- Modelle mit Instanzen dargestellt. Auf der vertikalen Achse sind auf unterster Ebene die zu integrierenden Datenmodelle, darüber die erstellten Skripte und Schema und auf oberster Ebene die Umfänge der WPIM-Pipeline (auch als WPIM-Prototyp bezeichnet) dargestellt. 223

248 Operationalisierung der WPIM-Pipeline Abb. 4.68: Implementierte Datenmodelle der WPIM-Pipeline Eine Unterteilung in [Abb. 4.68] wurde für Struktur- und Prozesswissen, aufgabenbezogenes Wissen, z. B. das der Experten, für die Ontologien und die angelegten Datenbanken getroffen. Diese Übersicht fasst die implementierten WPIM-Methoden zusammen. Zwei Aspekte werden durch die WPIM-Pipeline ermöglicht: Erstens dient die Pipeline dazu, die prototypische Implementierung zusammenfassend darzustellen. Zweitens kann anhand der Pipeline ein gedanklicher Walk-Through durch das technische System vorgenommen werden. Anhand dieses Walk-Throughs kann der Einsatz der WPIM-Methoden hinsichtlich Praxisbezug, Praxistauglichkeit und Wirksamkeit untersucht werden. Durch diese Analyse des technischen Systems hinsichtlich Einsatz und Anwendbarkeit können Rückschlüsse auf notwendige Erweiterungen gezogen werden. Das rein technische System soll im Verlauf der Arbeit zum sozio-technischen System erweitert werden Weiterentwicklung zur sozio-technischen WPIM-Anwendung Anhand der Benutzungswerkzeuge wird der Übergang der rein technischen WPIM-Pipeline hin zur sozio-technischen WPIM-Anwendung verdeutlicht. Die Werkzeuge sind auf Benutzung durch die Anwender auszulegen. Zu berücksichtigen sind Nutzer, wie z. B. SW-Agenten 276 oder menschliche Benutzer. Bei WPIM sind Werkzeuge und insbesondere grafische Benutzungsschnittstellen auf menschliche Benutzer mit konkreten Informationsbedürfnissen ausgerichtet. In [Kap. 3.3 Anwendungsszenarien zur Spezifikation von Dienste] werden Anwendungsszenarien zur Ableitung von technischen Diensten vorgestellt. Diese Szenarien helfen, den Aufbau und Nutzen von Benutzungswerkzeugen zu verstehen. Werkzeuge sind Kompositionen aus eben diesen (technischen) Diensten, mit dem Ziel den Benutzern einen möglichst einfachen Zugang und Einsatz des WPIM-Prototyps anzubieten. Das können sowohl Eingabeformulare mit grafischen Benutzungsoberflächen, ebenso aber visualisierte Information oder aufbereitete Ergebnisse von Suchen sein. Die Schnittstelle der Wissensdyaden implizit und explizit kann auch als Schnittselle zwischen dem Experten als originärem Wissensträger und dem technischen System zur Informationsverarbeitung und -speicherung gesehen werden. Besonderes Augenmerk gilt also der Mensch-Maschine-Kommunikation. Da WPIM sich mit Innovationsprozessen befasst, sind grafische Darstellungen der Prozesse notwendig. Das Graphical User Interface (GUI) und Visualisierungswerkzeuge genießen deshalb einen besonderen Stellenwert im vorgestellten WPIM-Prototyp und ebenso in der WPIM- Anwendung. 276 Software-Agenten kommen zunächst nicht zum Einsatz. Aber die technischen Datenformate/ Datenaustauschformate RDF/XML sind speziell auf maschinelle Such- und Analysemechanismen ausgelegt. 224

249 Operationalisierung der WPIM-Pipeline Benutzer Walk-Through durch die WPIM-Pipeline Die vorgestellten Schritte der entwickelten WPIM-Pipeline werden nun aus Anwendersicht durchlaufen. Dabei sollen Weiterentwicklungen hinsichtlich Benutzungsfreundlichkeit und Bedienbarkeit abgeleitet werden. In der WPIM-Pipeline erfolgt zunächst die Prozessmodellierung mit dem Modellierungs-Werkzeug Business Process Visual Architect 2.0. Dazu wird ein grafisches Modell des Innovationsprozesses erzeugt. Einzelne Prozessbausteine (wie Aktivitäten, Pools, Teilprozesse) werden per drag and drop hinzugefügt und über Relationen in zeitliche oder strukturelle Verbindungen gesetzt. Zudem können Aktivitäten durch den Baustein Pool zusammengefasst werden. Das Klicken auf einzelne Bausteine (z. B. Aufgaben oder Pools) öffnet Datensichten und zu dem so selektierten Baustein werden Beschreibung und Erweiterung durch Attribute, Dateien oder Links ersichtlich. Diese hierarchische Struktur der einzelnen Bausteine korrespondiert mit den geforderten vier Wissensebenen [vgl. Abb. 3.2] und ermöglicht die Ablage von Detailinformation z. B. zu Aktivitäten. Der Export des Modells zum Innovationsprozess in das XML-Austauschformat. erfolgt über die Exportfunktion innerhalb des Werkzeugs Business Process Visual Architect, z. B. über einen rechten Mausklick auf das Modell. Als Ergebnis wird eine XML-Datei an der gewünschten Stelle in der lokalen Verzeichnisstruktur erzeugt. Die Daten und Datenstrukturen des Prozessmodells sind somit (direkt) über XML zugänglich und können im Browser oder auch in jedem Text-Editor betrachtet und bearbeitet werden. Umgekehrt ist auch ein Re-Import der annotierten XML-Modelle und somit eine Informationsvisualisierung der bearbeiteten bzw. erweiterten XML-Dateien in BPVA möglich. Zur Manipulation des XML-Datenmodells werden die Prozessbausteine (Aktivitäten, Pools, Teilprozesse) einzeln und weiter verarbeitbar extrahiert. Dies erfolgt mittels PHP-Skript aber auch Transformationen mit XSLT wurden experimentell erprobt und sind geeignet. Darauffolgend findet eine Erweiterung der WPIM-Prozessontologie um Ressourcen und Relationen statt. Dazu wird das exportierte XML-Modell in Protégé eingelesen und als Ontologie gespeichert. Die Ontologie wurde zunächst konzeptuell definiert und in RDF/XML bzw. experimentell in OWL modelliert. Zugehörig wurde eine DTD bzw. XSD entwickelt, welche die Basis für die Ontologie darstellt. Die DTD sowie die XSD wurden im Werkzeug Protégé implementiert. Weitere Ontologien, z. B. für Ressourcen (bspw. Dokumente und deren interne Struktur wie im DC Dot beschrieben) und auch domänenspezifische Ontologien wurden entwickelt (z. B. Unternehmens-Ontologien/Strukturen für fertigende Industrien und den Energiesektor [Woll10]). Als Ergebnis können aus Protégé RDF/XML-Serialisierungen exportiert werden, die strukturell und inhaltlich Innovationsprozesse wiedergeben. Die in OWL erstellten Ontologien verwenden wir zunächst nicht weiter. Die Ontologien werden durch digitale Objekte instanziiert. Bereits in Protége können einzelne Klassen instanziiert werden bzw. Instanzen angelegt werden. Zudem können über die WPIM-Web-Schnittstelle (engl. interface) aus dem E2E oder auch aus Facebook oder sozialen Netzwerken personenbezogene Daten an den Innovationsprozess geknüpft werden. Die Zuweisung erfolgt dadurch, dass sich ein Experte selbst einzelne Aktivitäten zuordnet. Zudem setzt der Experte eine Aktivität mit allen relevanten Ressourcen, wie Dokumenten und Links, in relationale Verbindung. Hierzu verwendet der Experte die im WPIM-Vokabular beschriebenen Relationen. Das Prozessmodell wird auf diese Weise mit Ressourcen angereichert und die verfügbare Information direkt im Prozess, exakter in dessen Bausteinen hinterlegt. Die Speicherung der annotierten Prozessmodelle erfolgt in RDF/XML-Notation, z. B. im XML-Format oder in einem Triplestore. Die semantische Suche über dem RDF-/XML Prozessmodell kann in Protégé oder über Webschnittstellen mittels Abfragesprachen wie SPARQL erfolgen. Ebenso können Reasoning-Verfahren über Plug-ins oder geeignete WebServices eingesetzt werden. Die Beschreibungen und Erweiterungen der Bausteine, z. B. zu einer Aktivität, erfolgen in der RDF/XML-Datei. Diese kann mit ihren Erweiterungen wiederum als grafisches Prozessmodell im BPVA importiert und dargestellt werden. Die Erweiterungen können in BPVA, z. B. als 225

250 Operationalisierung der WPIM-Pipeline Attribute der Aktivitäten, in speziellen Attribut-Fenstern abgebildet werden. Im WPIM-Prototyp erhält eine einzelne Aktivität eine RDF/XML-Datei. Somit können einzelne Aktivitäten mit ihren Beschreibungen direkt im Dateisystem selektiert und wiederverwendet werden. Dies bildet die Basis für eine Baustein- und Prozess-Bibliothek. Auch ist es möglich, die RDF/XML-Datei zum Prozess oder zu einer einzelnen Aktivität im Intra-/Internet zu publizieren. Dort werden die RDF/XML-Dateien mit integrierten Annotationen von (semantischen) Suchmaschinen gefunden und analysiert. Die RDF/XML-Dateien können im Rahmen der geforderten Rückspeisefähigkeit in den BPVA, also das Prozess-Modellierungswerkzeug, bidirektional reintegriert werden. Hierdurch wird der integrative Austausch zwischen den Werkzeugen und der WPIM-Pipeline sichergestellt. Die in diesem Walk-Through erkannten Schlussfolgerungen und Effekte für Anwender werden zusammenfassend dargestellt: Innovatoren haben einen enorm hohen Zeitbedarf für das Suchen von Patenten, Spezifikationen und Dokumenten, die eigentlich sie bei der Innovation von Produkten unterstützen sollen. Auch fällt es derzeit schwer, Experten in großen Organisationen zu identifizieren. Die WPIM-Anwendung unterstützt Entwickler bei der Experten- und Wissensfindung. Wissen zu Innovationen ist dabei direkt im Innovationsprozess abgelegt oder verweist daraus auf entsprechende Ressourcen. Das Wissen ist strukturiert und auf verschiedenen Detaillierungsebenen verfügbar. Somit ist sichergestellt, dass Innovatoren dieses Wissen bei Bedarf finden. Die Aktivitäten sind wiederverwendbar und dynamisch angelegt, so unterstützen sie gemeinschaftliche Entwicklungen und Kollaborationen. WPIM integriert Detailinformation, Expertenkontakte und Verfahrensanweisungen in den visualisierten Innovationsprozess und unterstützt die Innovatoren und Entwickler bei ihrer Arbeit entscheidend. Dazu stellt die WPIM-Anwendung erforderliche Werkzeuge bereit Begriff und Einordnung von sozio-technischen Werkzeugen Die Werkzeuge des WPIM-Prototyps werden den Anwendern angeboten. Als Werkzeuge verstehen wir in der WPIM-Anwendung die Komposition aus Diensten, die durch den Anwender wahrgenommen werden und diesen beim prozessorientierten Management von Wissen entlang von Innovationsprozessen unterstützen. Sozio-technische Werkzeuge stellen die Weiterentwicklung von technischen Diensten, bzw. deren Komposition dar. Diese Weiterentwicklung der technischen Dienste erfolgt vor dem Hintergrund der Bedien- und Benutzbarkeit der WPIM-Anwendung durch die Anwender. Dabei werden speziell soziotechnische Aspekte der Interaktion von Anwendung und Anwendern berücksichtigt. Beim Aufbau der Werkzeuge ist darauf zu achten, dass diese die initialen Innovationsszenarien hinreichend bedienen und einen Mehrwert durch den Einsatz der Werkzeuge bei den Benutzern oder in den innovierenden Unternehmen bewirken. 226 Abb. 4.69: Einordnung von Werkzeugen Im weiteren Verlauf der Arbeit werden exemplarisch einige der Werkzeuge des WPIM-Prototyps vorgestellt.

251 Operationalisierung der WPIM-Pipeline Erweiterung der WPIM-Pipeline um sozio-technische Werkzeuge Nach dem Walk-Through durch die WPIM-Pipeline wird nun neben rein technischen Aspekten die Anwendbarkeit im Rahmen eines benutzungszentrierten Ansatzes beleuchtet. Technische Dienste werden zu Benutzungswerkzeugen kombiniert. Derartige Werkzeuge werden im weiteren Verlauf der Arbeit vorgestellt. Somit kann das technische System (der sog. WPIM- Prototyp) in die sozio-technische WPIM-Anwendung überführt werden. Die WPIM-Pipeline wird neben der Erweiterungen in dieser Arbeit auch als Semantic Web Anwendung WPIM unter [http://www.inknowvation.de] implementiert [vgl. Küsg11] und erweitert [vgl. Mena12; Trög12] Werkzeug 1: Datenspeicherung Das WPIM-Werkzeug zur Datenspeicherung ist aufgebaut aus verschiedenen Services, z. B. der Service, der den Zugriff auf das DB-System ermöglicht, sowie der Service, der die Konsistenz der Daten sicherstellt. Vorteilhaft sind Services, die den Benutzern eine visuell-gestützte Eingabe ermöglichen sowie eine Kontrolle der Eingabe in unterschiedlichen Sichten anbieten. Abb. 4.70: Datenmodell mit Tabelle Experten Zielsetzung von Dokumentations-, Informations-, Wissensmanagement-Werkzeugen und somit bei der WPIM-Anwendung ist, implizites und unstrukturiertes Wissen explizit zu repräsentieren. Die WPIM-Anwendung ermöglicht es, explizites Wissen zu Innovationen und Innovationsprozessen fertigender Industrien hinzufügen, dieses semantisch zu annotieren, das erweiterte Prozessmodell persistent zu speichern, durchsuchbar anzubieten und rechnergestützt zu visualisieren Werkzeug 2: Prozessbausteine, Prozess-Muster und Bibliotheken Wie sich gezeigt hat, treten bei der Modellierung von Prozessen häufig Teilprozesse auf, die strukturell ähnlich oder identisch sind. Diese Erkenntnis unterstützt zudem den Ansatz, dass in der Industrie und bei inkrementellen (bei [Thie01] repetitiven) Innovationen, Prozessstrukturen nur minimal verändert oder erweitert werden. Bei Folgeinnovationen werden komplette Innovationsprozesse erneut durchlaufen, Prozess-Muster erscheinen somit hilfreich: innerhalb von Prozessen mit wiederkehrenden Strukturen, bei inkrementellen Innovationen mit minimaler Veränderung der Prozessstruktur und 227

252 Operationalisierung der WPIM-Pipeline bei Folgeinnovationen, bei denen Musterprozesse nicht verändert, sondern lediglich instanziiert werden. 228 Abb. 4.71: Zwei Beispiele für Prozess-Muster, visuell modelliert in BPVA In [Abb. 4.71] sind exemplarisch zwei Prozess-Muster dargestellt: Die Verzweigung (engl. split) und die Vereinigung (engl. union). Beim Split werden nach erfolgreicher Durchführung einer Aufgabe Test die Aufgaben Dokumentation und Freigabe ausgelöst und durchgeführt. Bei der Vereinigung werden entwickelte Komponenten A, B, C zu einem Endprodukt zusammengefügt. Das sind einfache Beispiele für Muster 277 innerhalb von Innovationsprozessen, die wiederholt auftreten können. Die Modellierung von Muster-Prozessen ist hiermit geschildert. Die modellierten Prozessmuster können problemlos innerhalb des Werkzeugs BPVA wiederverwendet werden und z. B. bei der Modellierung gänzlich neuer Innovationsprozesse eingesetzt werden. Die Wiederverwendung von Prozessmustern ist in die WPIM-Anwendung zu übernehmen. Betrachtet man die modellierten Prozessmuster als Strukturvorlagen, so können diese für inkrementelle Innovationen versioniert und erneut verwendet werden. Alle in den Prozessbausteinen hinterlegten Ressourcen und Eigenschaften sind vollständig in neue Prozess- Instanzen zu übernehmen. Dies ist für Teilstrukturen, wie für die beiden Beispiele in [Abb. 4.71] möglich aber auch für gesamte Innovationsprozesse. Ein entscheidender Schritt für die Erstellung einer Prozess- und Bausteinbibliothek in der WPIM-Anwendung kann hierdurch realisiert werden. Die Innovationsprozesse und Bausteine können somit als Muster- oder Prozess-Vorlagen wiederverwendet sowie einer Instanziierung und Weiterentwicklung unterzogen werden. Erweiterungen und Reduktionen innerhalb der modellierten Strukturen sind denkbar. Die Voraussetzung für Lernende Prozesse sowohl hinsichtlich struktureller Anpassungen, als auch bei der Integration von neuem Wissen, weiterführenden Referenzen auf Ressourcen und inhaltlichen Lessons Learned sind somit gegeben. Diese Anforderungen zur Etablierung von Aktivitäten-Bibliotheken und zum Prozess-Baukasten fließen bei der Implementierung in die WPIM-Anwendung ein [vgl. Küsg11] Werkzeug 3: Visualisierung von syntaktischen Suchergebnissen In diesem Abschnitt werden zwei WPIM-Services angesprochen zuerst ein reiner Visualisierungs-Service zur farblichen Kennzeichnung von Suchergebnissen umgesetzt im Skript markieren.php. Die Ergebnisse einer syntaktischen Suche, hier nach einem Spitznamen Tobi, werden durch den Service farblich hervorgehoben, siehe [Abb. 4.72]. Selbstverständlich machen Suchbegriffe nach Kompetenzen, z. B. Projektmanagement oder Erfahrungen, z. B. mit Java deutlich mehr Sinn. Die Markierung der Suchergebnisse lässt sich auch auf die Markierung der Ergebnisse auf semantische Suchen ausweiten. Somit können bei einer semantischen Suche nach dem Begriff Experten auch Fachmann oder expert farblich hervorgehoben werden. Die Verknüpfung dieser Begriffe erfolgt über Relationen zwischen den Klassen, hinterlegt im RDF- /RDFS-Prozessmodell bzw. der Ontologie repräsentiert in OWL-DL. Die farbliche 277 Muster und Vorlagen in Prozessen, mehr unter - Diese Muster werden vorgeschlagen durch Wil van der Aalst [Aals03].

253 Operationalisierung der WPIM-Pipeline Kennzeichnung/Visualisierung in [Abb. 4.72] kann problemlos auf weitere stilistische Hervorhebungen, wie Textfarbe, Schriftart und Farbe des Text-Hintergrunds erweitert werden. Unterstützt werden alle stilistischen Mittel die in HTML zur Verfügung stehen. Abb Visualisierung zu syntaktischen Suchbegriffen mittels Skript markieren.php Ein zweiter Service zur Visualisierung hinterlegter Funktionalität für Telefon-, Fax- und Skype- Nummern wurde in [Abb. 4.72] integriert. Telefonnummern werden einerseits grau markiert, anhand der Vorwahl wird zudem die Länderkennung ermittelt und dargestellt. Diese Funktionalität kann im Browser hinterlegt werden. Bei der Nutzung von Skype 278 oder Voiceover-IP 279 (VoIP), wie z. B. durch SwyxIT 280 wird per Klick ein Verbindungs-Service aktiviert und eine VoIP-Verbindung aufgebaut. Hieran werden das direkte Zusammenspiel und der Übergang der Visualisierung hin zur hinterlegten Funktionalität ersichtlich. Beide Services fließen zunächst nur in den WPIM-Prototyp nicht jedoch in die WPIM-Anwendung ein Werkzeug 4: Ergebnisvisualisierung bei Experten- und Prozess-Suche Für das Expertennetzwerk E2E zur Erstellung und zum Abrufen der Expertenprofile wurde eine HTML-basierte Web-Schnittstelle erstellt, die bequem über gängige Browser zugänglich ist. Die Expertendaten können durch Formulare an das serverseitige Dateisystem übergeben werden. Zudem besteht die Möglichkeit einer Bild-Beschreibung, mit der englischen Wortschöpfung aus description und picture kurz als depiction bezeichnet. In der Beschreibung vorkommende Begriffe werden in sog. Begriffswolken (engl. tag cloud), wie in [Abb. 4.73] dargestellt, aufgenommen. Basis hierfür bildet eine syntaktische Suche. Ein Mehrwert wird generiert, indem häufig vorkommende Begriffe durch veränderte Schriftgröße und Farbe hervorgehoben werden und dem Suchenden sehr gut eine Übersicht zum gefundenen Experten oder auch einer Prozessbeschreibung verschaffen Skype ein kostenfreier Anbieter von VoIP für Telefonie, Videotelefonie, Instant-Messaging und Dateiübertragung. 279 IP-Telefonie (Internet-Protokoll-Telefonie) oder Voice-over-IP (VoIP) ist das Telefonieren über das Internet

254 Operationalisierung der WPIM-Pipeline Abb. 4.73: Integrierte Experten-Visualisierung mit Tag-Cloud Zur Visualisierung der Suchergebnisse in Begriffswolken können auch Schriftfarbe, farblicher Schrifthintergrund oder farbliche Kontraste, als Grundlage für die visuelle Kodierung zusätzlicher Eigenschaften der Begriffswolken, eingesetzt werden. Hierfür wurde das Online- Tag-Cloud-Werkzeug TagCrowd 281 verwendet, der generierte textbasierte HTML-Code kann in die WPIM-Anwendung eingebunden und im Web publiziert werden Erweiterung Werkzeug 5: Experten-Status und regelbasierter Statuswechsel Um Experten einen Status zuweisen zu können, gilt es, dafür automatisierte Mechanismen zu etablieren. Dazu werden drei Zustände eingesetzt: Kenner-, Könner- und Expertenstatus. Zur Realisierung können verschiedene Indizes herangezogen werden, beispielsweise der Aktivitätsindex. Dabei wird zukünftig softwaretechnisch über die Log-On-Information festgehalten, wie oft und wie lange ist ein Experte im E2E bzw. der WPIM-Anwendung angemeldet ist. Eine Log-On-Datei wird derzeit bereits erstellt, die anwenderbezogene Information wird aber noch nicht vollständig ausgewertet. Xing.de [vgl. Abb. 4.74] bietet zur Benutzeraktivität eine Visualisierung mit Aktivitätsbalken: TagCrowd ist ein Online-Werkzeug zur Generierung von visuellen Tag-Clouds aus URL, hochgeladenen Dateien oder bereitgestelltem Text. 230

255 Operationalisierung der WPIM-Pipeline Abb. 4.74: Aktivitätsindex bei XING.de Die hinterlegte Logik sollte ebenfalls semantisch repräsentiert werden. In [Code 4.24 und Code 4.25] folgen entsprechende Formalisierung und Vorbereitung zur Umsetzung in RDF: <Klasse:Experte> hatstatus <Klasse:Experte> hataktivität <Klasse:Status> <Klasse:Aktivität> Code 4.24: Generische Zuordnung auf Klassenebene: Status und Aktivität zu Experten <AMüller> hatstatus <Könner> <AMüller> hataktivität <90Prozent> Code 4.25: Konkrete Zuordnung eines Status und einer Aktivität zum Experten AMüller Um Beiträge und Dokumente eindeutig zu Innovationsprozessen zuordnen, bewerten und honorieren zu können, ist eine namentliche und zeitliche Kennung derselben nötig. Eine semantische Repräsentation ist folgendermaßen sinnvoll möglich: <AMüller> istautorvon <Patent123> <Patent123> haterstellungsdatum < > Code 4.26: Zuordnung von Autor und Erstellungsdatum zu einem Patent In [Code 4.26] ist die formale und technische Kennzeichnung von Beiträgen, z. B. eines Patents, als Vorbereitung zur Serialisierung in RDF-Notation gezeigt. Die entsprechenden Klassen Experte, Dokument und Datum werden vorausgesetzt und sind in der WPIM-Ontologie modelliert. Bei WPIM und einem expertenzentrierten Ansatz erachten wir weniger Aktivitätszeiten und Dauer als ausschlaggebendes Merkmal der Bewertung hinsichtlich der Statusverbesserung, sondern vielmehr die Werthaltigkeit der Beiträge, die inhaltliche Reputation also das qualitative Engagement der Experten. In [Code 4.27] findet sich eine mögliche semantische Formalisierungen zur Vorbereitung der Implementierung, z. B. in RDF-Notation: <AMüller> QualitätBeiträge <1> <AMüller> hatreputation <gut> <AMüller> zeigtengagement <gut> <AMüller> hatveröffentlichungen <3> Code 4.27: Bewertung von Experten, deren Engagement und Reputation Hierbei ist eine (meist subjektive) Bewertung, z. B. durch Vorgesetzte, Personalabteilung oder auch Mitarbeiter nötig. Um Experte in der WPIM-Anwendung zu werden, ist es nötig, z. B. einen freiwilligen Vortrag zu halten oder ein Fachartikel zu verfassen. Auch das Verfassen von 231

256 Operationalisierung der WPIM-Pipeline Kurzberichten oder die Vorstellung eines Prozess- oder Projektstatus kann dienlich sein, die Treppe zum Experten um eine Stufe zu verkürzen. Auf Meta-Ebene können diese Vorgaben als Regeln [vgl. Code 4.28] interpretiert werden, die für unterschiedliche Systeme verschieden ausgerichtet und aufgebaut sein können. 232 WENN <AMüller> hatstatus <Könner> (Annahme) UND <AMüller> hältvortrag <VortragABC> (Annahme) DANN <AMüller> hatstatus <Experte> (Folgerung) Code 4.28: Regelbasierter Ansatz zum Schlussfolgern aus Prämissen Über die in [Code 4.28] (semantisch) formalisierte Regel soll zukünftig in der WPIM- Anwendung auch (semantisch) geschlossen (also abgeleitet bzw. inferiert) werden. Die WPIM- Anwendung kann in zukünftigen Implementierungen durch regelbasierte Ansätze [vgl. Broc07] und (semantische) Regeln, z. B. modelliert mit RuleML [Rule11], zur regelbasierten Anwendung erweitert werden. Ein möglicher Einsatz der regelbasierten Inferenz [Bull06, S. 256] mittels der Semantic Web Rule Language (SWRL) 282 [Bull06, S. 260] wird bei der Ermittlung von benötigten Fachkompetenzen und zeittreibende Konstellationen [Bull06, S. 259] über sog. Quinn-Level [Quinn 1996 in Bull06] vorgeschlagen Conclusio und Erweiterung der WPIM-Pipeline um OWL-DL Neben der WPIM-Pipeline mit ihren prototypischen technischen Diensten wurden soziotechnische Benutzungsschnittstellen und Werkzeuge, z. B. für menschliche Benutzer, vorgeschlagen. Entscheidend ist, dass WPIM nicht nur für menschliche Benutzer zugänglich sein soll, sondern auch für technische Benutzer, wie z. B. Agenten, Crawler oder semantische Suchen und Inferenz-Mechanismen. Durch den Einsatz von weiterführenden Werkzeugen, komponiert aus den technischen Diensten, lässt sich der Übergang von der technischen WPIM-Pipeline hin zur sozio-technischen WPIM-Anwendung verdeutlichen. Erkannt wurde zudem, dass die Ausdrucksmächtigkeit von RDF/RDFS an einigen Stellen der WPIM-Pipeline an ihre Grenzen stößt. Wird in der WPIM-Pipeline eine Suche für den Begriff Fachmann gestartet, werden syntaktisch abweichende Synonyme wie Experte oder Spezialist nicht als Ergebnis der semantischen Suche zurückgegeben. Bei der weiterführenden Implementierung der WPIM-Anwendung ist daher eine Erweiterung der Ausdrucksmächtigkeit um Umfänge von OWL nötig [vgl. Küsg11]. Um weiterhin die Entscheidbarkeit der Ontologien und der semantischen Suchen zu sichern, kommt OWL-DL zum Einsatz. Die synonymen Klassen Experte, Fachmann oder Spezialist werden in OWL-DL durch owl:equivalentclass als äquivalente Klassen relational verbunden und somit zukünftig bei semantischen Suchen als gleichwertig identifiziert und somit gefunden. OWL bietet noch zahlreiche weitere Konstrukte, um semantische Beziehungen zwischen Konzepten zu definieren [vgl. Kap ] und um somit Anfragen in der WPIM-Anwendung einfacher zu gestalten und erzielte Ergebnisse vollständiger zu erhalten. Auch eine Erweiterung der WPIM-Anwendung um regelbasierte Ansätze, z. B. mit RuleML 283, ist geplant Prototypische WPIM-Anwendung mit Baukasten In [Abb. 4.76] ist die prototypisch implementierte WPIM-Anwendung und insbesondere der Baukasten der Anwendung dargestellt. In der WPIM-Anwendung [vgl. Abb. 4.75] werden die Reiter Startseite, Prozesse, Baukasten, Personen und Dokumente abgebildet. Die Prozesse und Prozesselemente sind in der Baumansicht dargestellt. 282 Die Semantic Web Rule Language stellt eine Logik erster Stufe für die Abbildung statischer Regeln zur Verfügung [vgl. Bull06, S. 260]. 283

257 Operationalisierung der WPIM-Pipeline Abb. 4.75: WPIM-Anwendung mit Menü- und Baumansicht In der WPIM-Anwendung wird zwischen Produktivumgebung und dem (archivierenden) Baukasten unterschieden. In der Produktivumgebung, die unter dem Reiter Prozesse [Abb. 4.76] aufzurufen ist, werden die (importierten) Prozesse grafisch (i. S. d. Prozessvisualisierung) und als strukturierte Baumansicht dargestellt. Abb. 4.76: WPIM-Anwendung mit Baukasten Die Webanwendung unterstützt die Wiederverwendbarkeit von annotierten Prozesselementen durch den Baukasten [Woll11]. Aus der Produktivumgebung [Abb. 4.76] können Prozesse bzw. auch einzelne Prozesselemente, wie z. B. Aktivitäten, in den Baukasten [Abb. 4.75] übernommen werden. Bei einer Folgeentwicklung wird ein Prozess wiederum durch die Entnahme aus dem Baukasten in der Produktivumgebung instanziiert. Auch kann in der Produktivumgebung, z. B. eine neu angelegte Aktivität, über eine Auswahl [vgl. Abb rechter Teil], mit den Eigenschaften also den Daten und Metadaten einer bestehenden Aktivität belegt werden. Dazu wird in der Auswahl eine im Baukasten existenten Aktivität ausgewählt und die neu angelegte Aktivität mit diesen Daten bewusst überschrieben. Der Baukasten trägt wesentlich zur Beschleunigung der Abläufe bei, indem die Webanwendung die Übertragung der Metadaten für die Benutzer übernimmt. [vgl. Küsg11, S. 54] Um die Metadaten in BPVA weiterverwenden zu können, speichert die WPIM-Anwendung Links auf die jeweilige Detailseite zu jedem Modellierungselement und stellt den Prozess zum Download im BPVA-Ausgangsformat zur Verfügung. Der betreffende Link befindet sich in der Spezifikation des jeweiligen Modellierungselements unter der Registerkarte Referenzen. [Küsg11, S. 40] 233

258 Operationalisierung der WPIM-Pipeline Abb. 4.77: Aktivität in der Detailansicht im BPVA Durch die in [Abb. 4.77] gezeigte Speicherung der Beschreibung wird die Rückspeisefähigkeit (engl. closed loop development) ermöglicht. Ein Prozess, modelliert in BPAV wird im XML- Format gespeichert und in die WPIM-Anwendung importiert. In der WPIM-Anwendung kann der Prozess semantisch annotiert und dessen Eigenschaften instanziiert werden. Eine Dokumentation zum Prozess bzw. zu einzelnen Prozesselementen kann im XML/RDF-Format ausgeleitet werden und wird zudem als Link in der Spezifikation des Prozesses und den Prozesselementen verankert. Wird der Prozess erneut im BPVA geöffnet (auch re-importiert), so steht dort die Dokumentation zum Prozess bzw. die Beschreibung der Prozesselemente zur Verfügung. Dies stellt den geschlossenen Entwicklungskreislauf der WPIM-Anwendung dar. Mit den Semantic Web Technologien RDF und OWL ist es gelungen, eine Webanwendung zu realisieren, die die Beschreibung der Ressourcen in einer gemeinsamen Datenstruktur speichert und eine zentrale Benutzungsschnittstelle bereitstellt, über die alle Ressourcen aufrufbar und bearbeitbar sind. [Küsg11, S. 55] Durch die Verwendung von RDF, standardisierten Vokabularen und Ontologien in der Webanwendung wird eine einheitliche semantische Suche über den Prozessen mit den zugehörigen Ressourcen überhaupt erst ermöglicht. [Woll11] Die Implementierung der WPIM-Anwendung ist bezüglich der an diese Arbeit gerichteten Anforderungen abgeschlossen und unter [http://www.inknowvation.de] verfügbar. Ob die identifizierten Anforderungen umgesetzt sind und die WPIM-Anwendung diese mit ihren Diensten und Werkzeugen auch vollständig abdeckt, wird in der nachfolgenden qualitativfunktionalen Evaluation untersucht Qualitativ-funktionale Evaluation und Potenzial-Analyse Neben der qualitativ-funktionalen Evaluation werden die quantitativ evaluierbaren Potenziale bei der Nutzung von WPIM identifiziert. Im Folgenden werden Testfälle und Testergebnisse vorgestellt, die zeigen, wie die WPIM-Pipeline qualitativ, also funktional, arbeitet und dabei gleichzeitig identifizieren, in welchen Dimensionen sie dem Anwender einen Nutzen stiftet. Durch den Abgleich der Anforderungen mit den funktional erzielten Ergebnissen der Testfälle und der Identifikation von deren Nutzendimensionen wird darüber hinaus eine weitergehende Evaluation der WPIM-Methoden und der WPIM-Anwendung vorbereitet. Req.ID WPIM_001 WPIM_002 WPIM_003 WPIM_004 Benennung Prozessbaukasten und standardisierte Musterprozesse Virtuelle Treffen und virtuelle Entwicklungsumgebungen Wissenssicherung und Anreizsysteme Informationsflut und Informationsdetaillierung 234

259 Operationalisierung der WPIM-Pipeline WPIM_005 WPIM_006 WPIM_007 WPIM_008 Wissensstrukturierung und Wissensdimensionierung Dynamische Wissenserweiterung und Fortschreibung Lessons Learned und lernende Prozesse Expertenmanagement Tab. 4.20: Übersicht zu den Anforderungen an WPIM Nachstehend werden die nummerierten Anforderungen (Req.ID) an WPIM aus [Kap. 2.8 Conclusio: Übersicht der abgeleiteten Anforderungen an WPIM] aufgegriffen Prozessbaukasten und standardisierte Musterprozesse Benennung Beschreibung Req.ID: WPIM_001 Prozessbaukasten und standardisierte Musterprozesse Wiederverwendung von bestehenden Prozessen; Überführung in ein standardisiertes Format; Wiederverwendung von Aktivitäten. Tab. 4.21: Anforderung WPIM_001: Prozessbaukasten und standardisierte Musterprozesse Testfall A Ziel Input Ablauf Soll-Output Ist-Output Ergebnis Testfall B Ziel Input Ablauf Soll-Output Ist-Output Ergebnis Testfall C Ziel Input Ablauf Req.ID: WPIM_001 Der Testfall wurde erstellt, um die Wiederverwendung bestehender Prozesse zu prüfen. ARIS Modell der Energiebranche [Woll10] Das Prozessmodell wird mit ARIS geöffnet. Speicherung/Export des Prozessmodells in XML- oder BPMN-Notation. ProzessEnergiebranche.xml ProzessEnergiebranche.xml bestanden Tab. 4.22: Testfall A Req.ID: WPIM_001 Der Testfall wurde erstellt, um die Überführung eines Prozessmodells in ein standardisiertes (Datenaustausch) Format zu prüfen _Philips.EAP ein EA bzw. BPVA-Prozessmodell Das Prozessmodell wird mit dem EA geöffnet. Export des Prozessmodells in XMI/XML-Notation _Philips.xml _Philips.xml bestanden Tab. 4.23: Testfall B Req.ID: WPIM_001 Der Testfall wurde erstellt, um die Wiederverwendbarkeit von Aktivitäten zu prüfen _Philips.EAP ein EA bzw. BPVA-Prozessmodell Das Prozessmodell mit der Aktivität wird mit dem EA geöffnet. 235

260 Operationalisierung der WPIM-Pipeline Soll-Output Ist-Output Ergebnis Export des Prozessmodells mit der Aktivität in XML-Notation. Import (des Prozessmodells mit der) Aktivität in Protégé. Speicherung der Aktivität unter Klasse: Aktivitäten in Protégé. Serialisierung (des Prozesses mit) der Aktivität in XML/RDF. Serialisierung der Aktivität in XML/RDF _ Philips.rdf _Aktivität_Philips.rdf _ Philips.rdf _Aktivität_Philips.rdf bestanden Tab. 4.24: Testfall C Virtuelle Treffen und virtuelle Entwicklungsumgebungen Benennung Beschreibung Req.ID: WPIM_002 Virtuelle Treffen und virtuelle Entwicklungsumgebungen Nutzung von virtuellen, unternehmensübergreifenden Entwicklungsumgebungen und Austausch von Prozessmodellen; Zugriff und Verknüpfung von digitalen Objekten über ein WebInterface. Tab. 4.25: Anforderung WPIM_002: Virtuelle Treffen u. virtuelle Entwicklungsumgebung Testfall D Req.ID: WPIM_002 Ziel Der Testfall wurde erstellt, um die Kollaboration und den virtuellen, unternehmensübergreifenden Austausch von Prozessen zu prüfen. Input WPIM_BusinessProcessDiagram.vpp ein PBVA-Prozessmodell Ablauf Upload des Prozessmodells in ProjectPlace 284. Soll-Output Verteilte Instanzen des WPIM_BusinessProcessDiagram.vpp Ist-Output Verteilte Instanzen des WPIM_BusinessProcessDiagram.vpp Ergebnis bestanden Testfall E Tab. 4.26: Testfall D Req.ID: WPIM_002 Ziel Der Testfall wurde erstellt, um den Zugriff und die Verknüpfung Zugriff von digitalen Objekten über ein WebInterface zu prüfen. Input Konzepte.html Ablauf Das Prozessmodell wird mit ARIS geöffnet. Speicherung/Export des Prozessmodells in XML- oder BPMN-Notation. Beleg [Abb. 4.62: WPIM Web-GUI zur Zuordnung digitaler ] Soll-Output Konzepte.xml Ist-Output Konzepte.xml Ergebnis bestanden Tab. 4.27: Testfall E 284 ProjectPlace

261 Operationalisierung der WPIM-Pipeline Wissenssicherung und Anreizsysteme Benennung Beschreibung Testfall F Ziel Input Ablauf Beleg Soll-Output Ist-Output Ergebnis Testfall G Ziel Input Ablauf Soll-Output Ist-Output Ergebnis Abweichung Req.ID: WPIM_003 Wissenssicherung und Anreizsysteme Die mit Wissen annotierten Prozessmodelle dienen als Wissensspeicher; Motivations-/Anreizsystem zur Förderung des Wissensaustausches. Tab. 4.28: Anforderung WPIM_003: Wissenssicherung und Anreizsysteme Req.ID: WPIM_003 Der Testfall wurde erstellt, um zu prüfen, ob die annotierten Prozessmodelle als (RDF Tripel) in Wissensspeicher wie Datenbanken überführt werden können. WPIM_BusinessProcessDiagram.vpp ein PBVA-Prozessmodell Konzepte.xml WPIM_Experten.xml Speicherung einzelner RDF Tripel in der Access DB WPIM.mdb [Abb. 4.70: Datenmodell mit Tabelle Experten] Populierte Tabelle Experten in der WPIM.mdb Populierte Tabelle Experten in der WPIM.mdb bestanden Tab. 4.29: Testfall F Req.ID: WPIM_003 Der Testfall wurde erstellt, um die Etablierung eines Motivations- /Anreizsystem zur Förderung des Wissensaustausches zu prüfen. N/A Nicht anwendbar N/A N/A N/A Hierbei handelt es sich um eine organisatorische Herausforderung, die nicht im Rahmen dieser Arbeit umgesetzt werden kann Tab. 4.30: Testfall G Informationsflut und Informationsdetaillierung Benennung Beschreibung Req.ID: WPIM_004 Informationsflut und Informationsdetaillierung Die Aktivitäten des Innovationsprozesses dienen zur Strukturierung der anzufügenden Ressourcen. Tab. 4.31: Anforderung WPIM_004: Informationsflut und Informationsdetaillierung Testfall H Req.ID: WPIM_

262 Operationalisierung der WPIM-Pipeline Ziel Input Ablauf Beleg Soll-Output Ist-Output Ergebnis Der Testfall wurde erstellt, um zu prüfen, ob die Aktivitäten des Innovationsprozesses zur Strukturierung der anzufügenden Ressourcen dienen. Ressourcen _Philips.xml Process_Ontologie.owl Die Prozessstruktur/Prozesshierarchie (Prozess mit Aktivitäten) wird nach Protégé importiert. Aktivitäten sind eine SubKlasse zu Prozess. Die Klasse Aktivität wird mit Instanzen von Aktivitäten populiert. Über Relationen (z. B. hat_dokument) werden den Aktivitäten Ressourcen zugeordnet. [Abb. 4.13: Ausschnitt der implementierten Klasse:Experten] WPIM_Process_Ontologie.owl WPIM_Process_Ontologie.owl bestanden Tab. 4.32: Testfall H Wissensstrukturierung und Wissensdimensionierung Benennung Beschreibung Req.ID: WPIM_005 Wissensstrukturierung und Wissensdimensionierung Die Aktivitäten des Innovationsprozesses dienen zur Dimensionierung des Wissens. Tab. 4.33: Anforderung WPIM_005: Wissensstrukturierung und Wissensdimensionierung Testfall I Ziel Input Ablauf Soll-Output Ist-Output Ergebnis Req.ID: WPIM_005 Der Testfall wurde erstellt, um zu prüfen, ob die Aktivitäten des Innovationsprozesses zur Dimensionierung des Wissens dienen. Beschreibungen.txt oder Kommentat.txt _Philips.xml Process_Ontologie.owl Die Prozessstruktur/Prozesshierarchie (Prozess mit Aktivitäten) wird nach Protégé importiert. Aktivitäten sind eine SubKlasse zu Prozess. Die Klasse Aktivität wird mit Instanzen von Aktivitäten populiert. Über Relationen (z. B. Beschreibung oder Kommentar) werden den Aktivitäten Ressourcen zugeordnet. WPIM_Process_Ontologie.owl WPIM_Process_Ontologie.owl bestanden Tab. 4.34: Testfall I Dynamische Wissenserweiterung und Fortschreibung Benennung Dynamische Wissenserweiterung und Fortschreibung Req.ID: WPIM_

263 Operationalisierung der WPIM-Pipeline Beschreibung Erweiterbarkeit des Prozessmodells und Fortschreibung der Ontologie. Tab. 4.35: Anforderung WPIM_006: Dynamische Wissenserweiterung und Fortschreibung Testfall J Ziel Input Ablauf Soll-Output Ist-Output Ergebnis Testfall K Ziel Input Ablauf Soll-Output Ist-Output Ergebnis Req.ID: WPIM_006 Der Testfall wurde erstellt, um die Erweiterbarkeit des Prozessmodells zu prüfen. Aktivitäten.xml _Philips_V1.xml Das Prozessmodell wird um zusätzliche Aktivitäten erweitert. Das Prozessmodell wird erneut gespeichert und dabei versioniert _Philips_V2.xml _Philips_V2.xml bestanden Tab. 4.36: Testfall J Req.ID: WPIM_006 Der Testfall wurde erstellt, um die Fortschreibung der Ontologie zu prüfen. Aktivitäten.xml _Philips_V2.xml WPIM_Process_Ontologie_V1.owl Die Ontologie wird um zusätzliche Instanzen der Aktivitäten erweitert. Das Prozessmodell wird erneut gespeichert und dabei versioniert. WPIM_Process_Ontologie_V2.owl WPIM_Process_Ontologie_V2.owl bestanden Tab. 4.37: Testfall K Lessons Learned und lernende Prozesse Benennung Beschreibung Testfall L Ziel Input Ablauf Soll-Output Ist-Output Ergebnis Req.ID: WPIM_007 Lessons Learned und lernende Prozesse Die Struktur der Aktivitäten sowie deren Inhalte sind erweiterbar. Tab. 4.38: Anforderung WPIM_007: Lessons Learned und lernende Prozesse Req.ID: WPIM_007 Der Testfall wurde erstellt, um die Erweiterbarkeit von Struktur der Aktivitäten zu prüfen. Aktivitäten.xml Weiteres Attribut Kommentar XML Modell wird strukturell um Attribut (z. B. Kommentar) erweitert Aktivitäten_strukturell_erweitert.xml Aktivitäten_strukturell_erweitert.xml bestanden 239

264 Operationalisierung der WPIM-Pipeline Testfall M Ziel Input Ablauf Soll-Output Ist-Output Ergebnis Tab. 4.39: Testfall L Req.ID: WPIM_007 Der Testfall wurde erstellt, um die Erweiterbarkeit der Inhalte von Aktivitäten zu prüfen. Aktivitäten_strukturell_erweitert.xml Kommentat.txt XML Attribut Kommentar wird um einen Kommentarinhaltlich erweitert Aktivitäten_inhaltlich_erweitert.xml Aktivitäten_inhaltlich_erweitert.xml bestanden Expertenmanagement Benennung Beschreibung Testfall N Ziel Input Ablauf Beleg Soll-Output Ist-Output Ergebnis Tab. 4.40: Testfall M Req.ID: WPIM_008 Expertenmanagement Kontaktdaten der Experten sind verfügbar; Bestehende Kontaktdaten können übernommen werden. Tab. 4.41: Anforderung WPIM_008: Expertenmanagement Req.ID: WPIM_008 Der Testfall wurde erstellt, die Verfügbarkeit von Kontaktdaten der Experten zu überprüfen. Manuelle Eingabe der Kontaktdaten über WebInterface E2E.html (Kontaktformular) Die Kontaktdaten werden über das HTML-Kontaktformular eingegeben [Abb. 4.51: Experten-Profile und Experten-Übersicht A-Z] Vogel_Tobias.txt Vogel_Tobias.html Vogel_Tobias.txt Vogel_Tobias.html bestanden Tab. 4.42: Testfall N Die bisher vorgestellten Testfälle können weiter in Teiltestfälle (sog. technische Testfälle) aufgeteilt werden. Im Folgenden wird exemplarisch der Testfall N in drei Teiltestfälle unterteilt. Eine Strukturierung der Teiltestfälle erfolgt in die Teiltestfälle N_001 bis N_003 ausgelagert auf die Anforderung Expertenmanagement [Req.ID: WPIM_008] aus [Kap. 2.8] Teiltestfall N_001: Verfügbarkeit von Kontaktdaten der Experten Die Wiederverwendung und der daraus resultierende Nutzen wird anhand zweier Aspekte bei WPIM beleuchtet: Der Wiederverwendung von bereits softwaretechnisch modellierten Prozessen sowie die Wiederverwendung existenter Profildaten der Experten. 240

265 Operationalisierung der WPIM-Pipeline Angeforderte Funktion: Expertenmanagement Req.ID: WPIM_008 [vgl. Kap. 2.8] insbesondere Verfügbarkeit von Kontaktdaten der Experten. Ziel: Wiederverwendung und weitere Nutzung existenter Datenbestände und Datenstrukturen, insbesondere von Prozessmodellen und personenbezogenen Profildaten. Anwendungsnutzen der Funktion im Detail: Unternehmen achten bei der Einführung neuer softwaretechnischer Systeme auf eine nahtlose Integration in die bestehende IT-Infrastruktur sowie die Weiter- und Wiederverwendung bestehender Systeme und Daten. Datenbestände sind mit geringem Aufwand zu migrieren und neue Systeme nahtlos und mit geringem Adaptionsaufwand zu integrieren. Daten und Profildaten von Experten aus sozialen Netzwerken sollen wiederverwendet werden. Methode (Klassen von Methoden) zur Implementierung der Funktion: Einsatz weitverbreiteter Datenaustauschformate wie XML Standardisierung von Profildatenstrukturen Verwendung der semantischen Beschreibungssprache FOAF Nutzung von APIs zu sozialen Netzwerken Qualitativer Funktionstest: Prozessmodelle deren Erstellung mit großem Abstimmungs- und Modellierungsaufwand verbunden ist, sollen wiederverwendet werden. Wir überführen daher bestehende Prozessmodelle nach XML. Somit kann unabhängig vom (visuellen) Modellierungswerkzeug auf eine standardisierte Serialisierung in XML zurückgegriffen werden, die von einer Vielzahl an aktuellen Prozessmodellierungswerkzeugen unterstützt wird. Prozessmodelle können somit direkt wiederverwendet werden oder können über geeignete Exportfunktionen maschinell in XML-Serialisierung überführt werden. Manuelle (ggf. fehlerträchtige) Eingriffe sowie zeitintensive Überführungen können somit umgangen werden. Zur Nutzung von Profildaten kann mittels APIs z. B. auf das soziale Netzwerk Facebook zugegriffen werden. Ziel dieser Herangehensweise ist es, weniger den technischen Zugriff auf die Profildaten zu zeigen, sondern vielmehr der Wiederverwendung existenter Daten und Datenstrukturen zu zeigen. Ebenso wie auf Daten in sozialen Netzen zugegriffen werden kann, so sollen zukünftig auch Datenbestände wie Profildaten in Unternehmen wiederverwendet werden. Wir haben demonstriert, wie über ein Webinterface eben auf diese Profildaten des sozialen Netzwerks zugegriffen werden kann und personenbezogene Daten wie ID, Name, Standort und ausgelesen werden können. Die Wiederverwendung der Profildaten von Facebook zeigt die Möglichkeit auch uneigene Datenstrukturen nachbilden und nutzen zu können. Somit kann, in einem weiteren kognitiven Schritt, der erneuten Nutzung von Profildaten in Unternehmen der Weg geebnet werden. Quantitative Nutzendimension: Durch die Wiederverwendung bestehender Profil- und Prozessdaten entfallen Zeiten und Kosten für erneute Prozessmodellierung bzw. bei der erneuten Dateneingabe bzw. Datenerfassung. Wir verwenden daher die Prozessmodelle und Daten aus dem BusinessProcess VisualArchitect wieder. Zudem nutzen wir exemplarisch den Zugriff auf existente Profildaten. Prozesse müssen nicht erneut modelliert werden. Profildaten können übernommen werden Teiltestfall N_002: Suche von Ansprechpartnern bei Innovationen Angeforderte Funktion: Expertenmanagement Req.ID: WPIM_008 [vgl. Kap. 2.8] insbesondere Nachfolger und Vertreterregelung. Ziel: Relevante fachliche Vertreter (bzw. auch Experten und Ansprechpartner) werden schneller identifiziert und aufgefunden. 241

266 Operationalisierung der WPIM-Pipeline Anwendungsnutzen der Funktion im Detail: Dadurch werden personenbezogene und/oder aktivitätenbezogene Vertreterregelung etabliert und die Nennung mehrerer Vertreter (sog. Mehrfachvererbung) 285 wird ermöglicht. Zirkuläre Bezüge zwischen Vertretern werden durch die aufgeführten Relationen ausgeschlossen, zudem kann die Nennung eines Vertreters eingefordert werden oder per Default gesetzt werden. Bei Vertretersuchen werden dadurch ausbleibende Ergebnismengen (sog. NULL-Ergebnisse) unterbunden. Methode (Klassen von Methoden) zur Implementierung der Funktion: Semantische Suche Reasoning/Inferenz Abfragen Qualitativer Funktionstest: <Experte rdf:about="#huber"> <rdf:type rdf:resource="&owl;thing"/> <istvertreter rdf:resource="#schmidt"/> </Experte> <Experte rdf:about="#schmidt"> <rdf:type rdf:resource="&owl;thing"/> <istvertreter rdf:resource="#meier"/> </Experte> Code 4.29: Mehrfachvererbung bei Vertreterregelung istvertreter Die Suche über <foaf:person> ermöglicht es, Personen zu identifizieren, alle gefundenen Personen werden angezeigt. Eine Übersicht zu allen Experten im Sinne das E2E findet sich in [Abb. 4.51], die sog. Experten A-Z. Anzugeben ist die URI mit den Personenbeschreibungen in RDF. Unter dieser Adresse findet sich die URI zur Personenbeschreibung mittels des Vokabulars FOAF abgelegt im File foaf.rdf über das Web abrufbar 286. Nachstehend die SPARQL-Anfrage: PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT DISTINCT?name WHERE {?x rdf:type foaf:person.?x foaf:name?name } ORDER BY?name Code 4.30: SPARQL-Anfrage Die semantische Suche, aufgebaut als SPARQL-Anfrage, an die RDF-Datei hinterlegt unter der URI kann, z. B. über den Redland Rasqal RDF Query Demonstration 287 durchgeführt werden. Als Ergebnis erhält man wie gefordert die Namen (?name) aller beschriebenen Personen in alphabetischer Reihenfolge (ORDER BY?name). Duplikate werden ausgeblendet (DISTINCT?name). 285 Mit Mehrfachvererbung ist keine Vererbung im Sinne von Klassenhierarchien gemeint, sondern gezielte Verweise zwischen Instanzen im Sinne einer Kette von Vererbungen (sog. Vererbungskette). 286 FOAF.rdf unter Rasqal Online SPARQL Query demonstrator

267 Operationalisierung der WPIM-Pipeline Abb. 4.78: Ergebnisliste zur SPARQL-Suchanfrage nach Namen von Experten Der Auszug aus der Ergebnisliste der SPARQL-Suchanfrage listet die identifizierten Personen namentlich auf. Entscheidend ist, dass diese SPQRQL-Anfrage auf alle RDF-Dateien (auch bei Erweiterungen um das FOAF-Vokabular) angewendet werden kann. Somit kann auch die Datei WPIM.rdf mit den in FOAF annotierten Experten durchsucht werden. Ebenso kann mit SPARQL auch über weitere Vokabulare, wie z. B. dem WPIM-Vokabular, nach Namen von Experten (?name)) mit Verantwortlichkeit (?istverantwortlichfür) unter Verwendung der entsprechenden URI gesucht werden. Suchanfragen und Wissensbasis können getrennt voneinander betrachtet und entwickelt werden. Dadurch wird die Wiederverwendbarkeit von Suchanfragen gewährleistet [vgl. Trög12]. Quantitative Nutzendimension: Es kann gezeigt werden, dass nicht nur das systematische Auffinden von fachlichen Ansprechpartnern möglich ist, sondern zudem, durch die maschinelle Suche, ein schnelleres Auffinden (gegenüber manuellen Suchen in gr. Datenbeständen) von Vertretern möglich ist. [vgl. Woll10] Ist kein geeigneter Ansprechpartner im Unternehmen verfügbar, so wird ein sog. NULL- Ergebnis durch die maschinelle Suche zurückgegeben. Endlose manuelle Suchen können dadurch unterbunden bzw. diese vorzeitig abgebrochen werden. Auch findet so die Mehrfachvererbung Unterstützung und zirkuläre Bezüge zwischen Vertretern sind identifizierbar Teiltestfall N_003: Auffinden vergleichbarer und identischer Konzepte Angeforderte Funktion: Expertenmanagement Req.ID: WPIM_008 [vgl. Kap. 2.8] insbesondere das Auffinden vergleichbarer und identischer Konzepte. Ziel: WPIM unterstützt beim Schlussfolgern (engl. reasoning bzw. engl. inferencing) über identischen Konzepten (Klassen von Synonymen) sowie Mehrsprachigkeit innerhalb von Innovationsprozessen. Anwendungsnutzen der Funktion im Detail: Häufig wird essenzielles Wissen in Unternehmen nicht gefunden, da kein einheitliches Glossar besteht, bzw. unterschiedliche Begriffe für ein und dasselbe Konzept verwendet werden. Suchen bleiben ergebnislos da bei der Wissensrepräsentation und Annotation unterschiedliche Begriffe im Vergleich zu Suchbegriffen verwendet werden. Ziel muss es sein, Synonyme semantisch korrekt einzuordnen, damit keine gewünschten Ergebnisse der Suche übersehen werden. Ein 243

268 Operationalisierung der WPIM-Pipeline Beispiel: Eine Suche wird für den Begriff Fachmann gestartet und bisher werden syntaktisch abweichende Synonyme wie Experte oder Spezialist nicht als Ergebnis der semantischen Suche zurückgegeben. Ebenso soll WPIM dabei unterstützen, Konzepte, bzw. Klassen digitaler Objekte zu verbinden. Ein Szenario hierbei ist die Verschieden- oder Mehrsprachigkeit. Die Klassen Experte und z. B. engl. expert. Methode (Klassen von Methoden) zur Implementierung der Funktion: Semantische Suche Inferenz OWL Technologie mit den Konzepten <owl:class rdf:about="#experte"> <owl:equivalentclass rdf:resource="#fachmann"/> <owl:equivalentclass rdf:resource="#expert"/> <rdfs:subclassof rdf:resource="#mitarbeiter"/> </owl:class> Code 4.31: Äquivalente (engl. equivalent) Klassen in OWL Inferenzmechanismen bzw. Ontologie-Browser wie OwlSight 288 basieren auf Pellet 289. Qualitativer Funktionstest: Die in Protégé modellierte Ontologie zu Organisationen mit Mitarbeitern und den Subklassen Fachmann, Experte und der integrierten Klasse (engl.) expert. Die drei Klassen wurden durch den OWL-Ausdruck equivalentclass verbunden. Das Individuum (auch als Instanz bezeichnet) Mueller wird der Klasse Experte zugeordnet. Die Individuen Huber der Klasse Fachmann und Vogel der Klasse (engl.) expert. Abb. 4.79: Organisations-Ontologie mit äquivalenten Klassen Mittels OwlSight werden zunächst die verbundenen äquivalenten Klassen zur Klasse Experte ermittelt. Als Ergebnis werden Asserted Equivalent Classes ausgegeben: Fachmann und expert. Mueller wird als direkte Instanz der Klasse Experte erkannt. Als weitere Inferenzleistung werden die Individuen Huber und Vogel als Inferred Instanzes erkannt und in [Abb. 4.80] ausgegeben owlsight is a lightweight ontology browser Pellet: The Open Source OWL Reasoner. Pellet is an open source reasoner for OWL 2 DL in Java. It provides standard and cutting-edge reasoning services for OWL ontologies. 244

269 Operationalisierung der WPIM-Pipeline Abb. 4.80: Vorgegebene Klassen und Instanzen sowie inferierte Instanzen mit owlsight Quantitative Nutzendimension: Konzepte bzw. Klassen mit unterschiedlichen Bezeichnungen können integriert werden und alle Individuen (ohne Ausnahmen) dieser Klassen können zusammengefasst werden (owl:equivalentclass 290 ). Dies ist hilfreich, wenn in einer Organisation für ein Konzept unterschiedliche Bezeichnungen verwendet werden. Häufig ist dies der Fall, wenn verschiedene Bereiche oder Abteilungen kooperieren sollen. Auch die Zusammenführung von Klassen unterschiedlicher Sprachen ist möglich, dies ist von Nutzen, wenn internationale Organisationen auf einer gemeinsamen Datenbasis bzw. hier Ontologie arbeiten möchten. Dieses Vorgehen wird häufig unter dem Begriff Ontology Mapping 291 verstanden. Dies ist nicht nur auf Klassen sondern auch auf äquivalente Properties (owl:equivalentproperties) anwendbar Testfall O Ziel Input Ablauf Beleg Soll-Output Ist-Output Ergebnis Req.ID: WPIM_008 Der Testfall wurde erstellt, die Wiederverwendbarkeit von Kontaktdaten zu Experten zu überprüfen. Facebook.API Facebook.php Die Kontaktdaten werden aus Facebook ausgelesen Ablage der Daten in Profile.txt oder Profile.xml [Abb. 4.50: PHP-Skript Test-App zum auslesen von Facebook] Profile.txt Profile.xml Profile.txt Profile.xml bestanden Tab. 4.43: Testfall O Ergebnisse der qualitativ-funktionalen Tests Die Anforderungen und deren Erfüllbarkeit können, wie dargestellt, anhand von qualitativfunktionalen Testfällen überprüft werden. Die nachstehende Zusammenfassung zeigt die 290 Owl:equivalentClass gilt für Klassen, für Individuen ist owl:sameas zu verwenden. 291 Wikipedia Ontology Mapping: It will be challenging to merge a collection of ontologies. To tie together a set of component ontologies as part of a third it is frequently useful to be able to indicate that a particular class or property in one ontology is equivalent to a class or property in a second ontology. 245

270 Operationalisierung der WPIM-Pipeline Ergebnisse der einzelnen Testergebnisse auf ebenso wie das Ergebnis des Tests hinsichtlich der Anforderungen. Testfälle können in mehrere Anforderungen einfliessen, siehe z. B. den Testfall I und H. Es folgt die Zusammenfassung der Testergebnisse: Req.ID Testfall Testfall Ergebnis Ergebnis zur Anforderung WPIM_001 A, B, C bestanden bestanden WPIM_002 D, E bestanden bestanden WPIM_003 F, (G) teilw. bestanden bestanden WPIM_004 H, I bestanden bestanden WPIM_005 H, I bestanden bestanden WPIM_006 J, K bestanden bestanden WPIM_007 I, L, M bestanden bestanden WPIM_008 N, O bestanden bestanden Tab. 4.44: Zusammenfassung der Testergebnisse Die Ergebnisse der Tests sind in [Tab. 4.44] zusammengefasst dargestellt und hinsichtlich der Erfüllung der Anforderungen als bestanden zu bewerten. Eine Ausnahme stellt der Testfall G dar. Dieser Testfall konnte nicht durchgeführt werden, da es sich bereits bei der Anforderung um eine Anforderung an die Anpassung der Organisation handelt. Dieser Anpassung konnten wir im Rahmen dieser Arbeit nicht nachgehen die Anforderung stellt keine spezifische Anforderung an WPIM dar sondern vielmehr eine allgemeingültige Herausforderung. Anforderungen (Req.ID) können durch mehrere Testfälle überprüft werden. So wird z. B. Req.ID WPIM_001 durch drei Testfälle (A, B, C) abgedeckt. Nach der positiven Belegung der Testfälle mit bestanden kann abgeleitet werden, dass die Anforderungen durch WPIM bedient und zudem abgedeckt ist. Wie anhand der Tests erwiesen, erfüllt WPIM die gesetzten technischen Anforderungen und Ziele. Für den Nachweis des konkreten Nutzens, der durch die WPIM-Methoden und die WPIM- Anwendung erzielt wird, reichen diese technischen Testfälle und Tests (auch sog. Unit-Tests) nicht aus. Im weiteren Verlauf der Arbeit wird daher die Evaluation der WPIM-Anwendung unter Verwendung realer betrieblicher Datenkollektionen angestrebt, und durchgeführt. 246

271 Evaluation der WPIM-Anwendung 5 Evaluation der WPIM-Anwendung Zur Evaluation von WPIM werden Methoden zur Messung von Verbesserungspotenzialen und des Nutzens durch WPIM untersucht. Zunächst werden Methoden zur Wirtschaftlichkeit von WPIM vorgestellt und dabei die Aspekte Kosten und Nutzen durch WPIM analysiert. Zudem erfolgt eine Einordnung und Kompatibilitätsprüfung von WPIM in übergeordnete Rahmenwerke wie Normen, Standards und Vorgehensweisen. Zur Bewertung der Ergebnisse und zum Mehrwert von WPIM werden entsprechende Evaluationsmethoden betrachtet. Bei der Methodenauswahl wird speziell auf die Auswirkung von WPIM auf die Innovationsfähigkeit von Unternehmen [Bürg07, S. 2; KeEr08, S. 1] und zugehörige Leistungsindikatoren (engl. Key Performance Indicator, KPI) eingegangen. Dazu wird eine Hypothese formuliert, die einen positiven Zusammenhang zwischen WPIM und der Innovationsfähigkeit von Unternehmen herstellt. Da sich WPIM bisher in keinem Unternehmen im produktiven Einsatz befindet, wird die Einführung von WPIM durch entsprechende Gedankenexperimente simuliert und auch Teile der Evaluation zu WPIM basieren auf dieser Simulation. Bei diesem gedanklichen Experiment, der sog. Simulation wird ein fiktives Unternehmen (einmal ohne und einmal mit WPIM) mit dem InnoScore bewertet. Diese Methode und der zugehörige InnoScore zielen auf die standardisierte Messung der Innovationsfähigkeit von Unternehmen ab [SSKS07]. WPIM wird sodann anhand dieser Simulation auf Praxistauglichkeit, positiven Nutzen und die Verbesserung der Innovationsfähigkeit von Unternehmen hin evaluiert. Zudem folgt eine konkrete hypothesenbasierte Evaluation der WPIM-Methoden und der WPIM-Anwendung mit den Daten der empirischen Befragung bei Philips PCLAT. Die dabei erhobenen Daten werden als die sog. PCLAT-Datenkollektion bezeichnet. Hierbei wird insbesondere auf die bestehenden Szenarien, Anforderungen und Use Cases eingegangen. Aus den Ergebnissen der Evaluation werden Voraussetzungen und Handlungsempfehlungen für die Einführung von WPIM in die unternehmerische Praxis abgeleitet. Für eine inhaltliche Evaluation von WPIM und zur Bereitstellung von Testdaten, den sog. Datenkollektionen wurden Gespräche mit möglichen Evaluationspartnern geführt. Im Folgenden werden zunächst die Evaluationspartner vorgestellt, die von Fachgesprächen bis hin zur Bereitstellung von Datenkollektionen die Entwicklung, Erprobung und Evaluation von WPIM unterstützt haben. 5.1 Evaluationspartner Unternehmen der Industrie Die Evaluation erfolgt zu den WPIM-Methoden und der WPIM-Anwendung. Ein erster Cognitive Walk-Through aus Anwendersicht ist in [Kap ] dargestellt. Die Idee zum Wissensbasierten und Prozessorientierten Wissensmanagement entstand während einer Projekttätigkeit bei einem Fahrzeughersteller in der Entwicklungsabteilung für Airbag- Elektroniken. Parallel wurden die Anforderungen in 2006 in zwei Vorträgen in der BERATA GmbH Akademie (einem Unternehmen der ALTRAN Group) mit Kollegen und technischen Beratern (32 und 28 Teilnehmer) der Automobilindustrie weiter konkretisiert. Auf diversen nationalen und internationalen Kongressen zu semantischen Technologien [VoHe06a; VoHe06b; VoHe06e; VoHe07a; VoHe07c] wurde bei Vorträgen und Diskussionen der Fokus auf die semantische Annotation von Prozessen und das Prozesswissen weiter geschärft. Mit der Finebrain AG 292 gab es ebenfalls ein Arbeitstreffen zum Einsatz von semantischen Technologien in kommerziellen Software-Systemen und dem Wissensmanagement in der Automobilindustrie. Bei der freundlichen Einladung der FESTO GmbH und Co. KG 293 wurde mit über 40 internationalen Experten der Automobilindustrie die Methode WPIM diskutiert und ein möglicher Einsatz in der unternehmerischen Praxis ausgelotet. Auch 2007 bei Philips 294 PCLAT Philips Consumer Lifestyle Advanced Technology (PCLAT)

272 Evaluation der WPIM-Anwendung in Eindhoven, NL wurde der Einsatz des WPIM-Systems erläutert und der Nutzen bei projekthaften und parallelen Entwicklungsprozessen diskutiert. Mit Mentor Graphics 295 folgte in 2008 eine Diskussion zur kommerziellen Umsetzung von WPIM in ein Softwarewerkzeug. Mit der InConTec 296 GmbH gab es 2010 ein Arbeitstreffen bei dem Entwicklungskosten und Lizenzkosten bei einer marktreifen Implementierung der WPIM-Anwendung im Mittelpunkt der Diskussion standen. Erfahrungen bei der Etablierung eines Produktentstehungsprozesses bei der SOLIN AG 297 sind in diese Arbeit eingeflossen ebenso wie die erhobenen Datenkollektionen von Philips PCLAT [vgl. Kap ]. Philips PCLAT ist zudem Entwicklungs- und Evaluationspartner im Projekt Sustaining Heritage Access through Multivalent ArchiviNg (SHAMAN) Evaluationspartner: FESTO GmbH & Co. KG, Esslingen Bei der FESTO GmbH & Co. KG gibt es in der weltweit verteilten Competence Group Automotive (CGA) ein formularbasiertes De-Briefing-Werkzeug, um Erfolgsgeschichten (engl. success stories) zu Projekten zu erfassen. Die Daten werden automatisiert aus einer PDF-Datei in eine Datenbank übernommen und allen Teilnehmern der CGA zur Verfügung gestellt. Abb. 5.1: Projekt De-Briefing bei FESTO Die Idee zu diesem De-Briefing-Werkzeug, dargestellt in [Abb. 5.1] entstammt bei FESTO dem Vertriebsbereich. Es wird versucht, (Lern-) Erfolge aus Projekten, z. B. beim Vertrieb und der Inbetriebnahme von Komponenten, sowie gemachte, positive Erfahrungen aus den Ländermärkten in den zentralen Vertrieb zurückzuführen und dort zu nutzen. Diese Erfahrungen sollen zukünftig auch der FESTO Entwicklungsabteilung zugeführt werden, um im Sinne eines lernenden Entwicklungsprozesses innovative Impulse, z. B. von Kunden, in Weiterentwicklungen einfließen zu lassen. Ein De-Briefing kann im Rahmen der WPIM- Anwendung als zusätzliche Aktivität im Innovationsprozess etabliert werden und soll bei WPIM alle Lessons Learned systematisch in der zugehörigen WPIM-Aktivität oder dem WPIM- Musterprozess dokumentieren Evaluationspartner: BMW Group, München Geschildert wird ein Innovationsprozess für elektronische Steuergeräte (engl. Electronic Control Unit, ECU) der Automobilindustrie. Der Prozess wurde aus Gründen der Geheimhaltung abgeändert. Die gezeigten Prozessstrukturen sind aber ähnlich. Die Arbeitsteilung zwischen zwei Abteilungen und den Zulieferern (vertikale Aufteilung) ist gut geeignet, um die Modellierung

273 Evaluation der WPIM-Anwendung von Unterprozessen und Pools i. S. v. WPIM aufzuzeigen. Abb. 5.2: Innovationsprozess zur Erstellung sicherheitskritischer Software (modifiziert) Auch die farbliche Zuordnung von Aufgaben kennzeichnet unterschiedliche Verantwortlichkeiten bzw. Ausrichtungen der Aufgaben. Bei diesem Prozess-Template wird zu jeder Aktivität ein Dokument (eine sog. textuelle Verfahrensanweisung) hinterlegt. Dies ist eine, der bei WPIM verfolgten Möglichkeiten, explizites Wissen und Ressourcen in das Prozessmodell einzubinden. Die vier Wissensebenen von WPIM werden durch die Verlinkung der Prozessbausteine mit Ressourcen realisiert. Die semantische Annotation des Modells und der Ressourcen gelingt aber erst durch den Einsatz der semantischen WPIM-Methoden. Für WPIM ist es weiterführend denkbar, dem Innovationsprozess folgend, automatisiert eine Ordner- bzw. Dateistruktur auszuleiten. Dabei können Aufgabenpools als Ordnerstruktur und Aktivitäten als Unterordner in der Ordnerstruktur ausgeleitet und genutzt werden. 249

274 Evaluation der WPIM-Anwendung Abb. 5.3: Dateistruktur zu einem Innovationsprozess In [Abb. 5.3] werden einzelne Bausteine als Verzeichnisse angelegt und Dokumente, wie z. B. Freigaben oder Patente können in dieser Struktur parallel zum Innovationsprozess als digitale Objekte abgelegt werden. Die Struktur ist als Prozess-Ontologie semantisch beschrieben. Somit ist das Auffinden und Durchsuchen der Dateistruktur sowie der hinterlegten Ressourcen sichergestellt. Bei WPIM ergibt sich folgender Verbesserungsvorschlag: Die Dateistruktur muss bisher bei erstmaliger Prozessdurchführung händisch angelegt werden. Es ergeben sich Fehlerquellen hinsichtlich der vollständigen und korrekten Umsetzung der Prozessstruktur in eine Ordnerstruktur. Bei Anpassungen der Prozessstruktur muss die Ordnerstruktur nachträglich erweitert, reduziert oder angepasst werden. Bei der Umbenennung einzelner Aktivitäten im visualisierten Prozessmodell muss die Ordnerstruktur ebenfalls (nachträglich) händisch erweitert und zudem mit der Prozessstruktur abgeglichen werden. Durch eine bei WPIM automatisiert generierte Ordnerstruktur, z. B. in der WPIM-Anwendung als XML-Baum realisiert, können zum einen der Erstellungsaufwand reduziert und zum anderen fehlerhafte Visualisierungen der Prozessstrukturen vermieden werden Evaluationspartner: ALTRAN GmbH & Co. KG, Frankfurt ALTRAN nutzt zur Dokumentation der eigenen Geschäftsprozesse im technologischinnovativen Umfeld in der ALTRAN Automotive Division (vormals BERATA GmbH) das Prozessverwaltungs-Werkzeug DiPP DiPP ist ein Qualitätsmanagement-Werkzeug, mit dem Prozesse modelliert, beschrieben, dokumentiert und verwaltet werden. Abrufbar unter

275 Evaluation der WPIM-Anwendung Abb. 5.4: DiPP zur Verwaltung und Visualisierung von Geschäftsprozessen In [Abb. 5.4] sind Prozesse grafisch visualisiert Abläufe, Tätigkeiten, Werkzeuge, Verantwortung und Unterstützung (üblicherweise durch personelle Aufgabenträger) sind gesondert ausgewiesen. Wie hier gezeigt, liegen Prozesse der Industrie oftmals modelliert als Prozessmodelle vor. Das DiPP-Werkzeug unterstützt bei der Modellierung und Verwaltung von Geschäftsprozessen [DIPP]. Diese Modelle können bei DiPP in XMI/XML-Notation überführt werden. Es gilt als erwiesen, dass Industrieunternehmen wie ALTRAN ihre Prozesse softwaregestützt modellieren und mit Werkzeugen wie DiPP, BPVA, Enterprise Architect oder ARIS verwalten. Dies wird z. B. in den Referenzen- und Kundenlisten 299 der SW- Werkzeughersteller ersichtlich. [DIPP] wirbt mit verkauften Kundenlizenzen. Den Werkzeugen BPVA und Enterprise Architect liegt ein XML-Datenmodell [BPVA] zugrunde. Bzw. aus den Werkzeugen wie DiPP 300 oder ARIS sind Exporte der Modelle nach XMI 301 oder XML möglich [Woll10]. Somit unterstützen diese Werkzeuge den WPIM-Ansatz beim standardisierten Austausch und der Wiederverwendung von bestehenden Prozessmodellen und modellierten Ressourcen. Am Beispiel ALTRAN kann dargestellt werden, dass das DiPP- Werkzeug geeignet ist, alle Geschäftsprozesse und Prozesse von ALTRAN 302 (einem Unternehmen mit Mitarbeitern weltweit) zu verwalten. Innovationsprozesse sind eine Untermenge von Geschäftsprozessen bzw. von Prozessen im Allgemeinen. Anhand des DiPP- Werkzeugs wird deutlich, dass der Aufbau von Innovations- und Geschäftsprozessen identischen Regeln unterliegt und mittels identischen Modellierungskonzepten gelingt. Hieran kann veranschaulicht werden, dass der WPIM-Ansatz skalierbar und von Innovationsprozessen auf allgemeine Geschäftsprozesse unterschiedlichster Bereiche von Unternehmen übertragbar ist. 299 Auszug aus der ARIS Kundenreferenz: IDS Scheer-Software wird von namhaften internationalen Unternehmen wie British Telecom, Daimler, AG, Deutsche Bank, Nestlé oder Siemens aber auch von mittelständischen Firmen zur Optimierung ihrer Geschäftsabläufe eingesetzt DiPP ist datenbankbasiert. Die DiPP-Applikation arbeitet intern auf XML. Der DiPP-Standard legt beim Export eines Prozesses eine XML-Datei an. Die Importfunktion von DiPP liest wiederum das XML in die DB ein und stellt den Prozess sodann als Ablaufdiagramm dar. 301 XMI: XML Metadata Interchange (XMI) ist ein Standard der Object Management Group (OMG) und wird als Datenaustauschformat zwischen Software-Entwicklungswerkzeugen verwendet. XMI basiert auf dem XML- Format. Mit der kommenden Version 2.0 wird auch der Austausch von grafischen Diagrammen möglich sein. 302 Altran GmbH &Co. KG

276 Evaluation der WPIM-Anwendung Erstens wird dies daran belegt, dass einzelne Werkzeuge wie DiPP sowohl geeignet sind, spezielle Prozessmodelle, wie die zu Innovationsprozessen, aber auch Prozesse anderer Fachbereiche, wie zu Personal oder Vertrieb abzubilden. DiPP unterstützt die Modellierung von Prozessen auf unterschiedlichen Ebenen des Unternehmens und ermöglicht eine Einordnung und Verlinkung von allgemeinen Prozessen bis hin zu den detaillierten Prozessen mit Ressourcenzuordnung. Zweitens können generische Prozesse und auch detaillierte Prozesse wie Innovationsprozesse auf eine einheitliche Notation zurückgeführt werden. Das kann z. B. die Sprache BPMN 1.1. sein. Weitergedacht gelingt eine Rückführung aller Prozessmodelle auf das einheitliche und standardisierte Datenaustauschformat XMI/XML. Drittens wird hieran belegt, dass Prozesse der (fertigenden) Industrie in visualisierten, maschinenlesbaren Prozessmodellen vorliegen. Einige dieser Modelle können automatisiert in die XMI/XML-Notation übertragen werden können. Zudem kann die Übertragbarkeit des Ansatzes WPIM auf weitere Domänen und Prozesse neben der Domäne der Innovationen und Innovationsprozesse veranschaulicht werden. WPIM ist in zwei Richtungen skalierbar. Der WPIM-Ansatz ist geeignet, um: von speziellen Innovationsprozessen hin zu Geschäftsprozessen verschiedener Domänen und ganz allgemein, hin zu Prozessen, zu aggregieren (sog. Bottom-up-Ansatz). allgemeine Prozesse, Geschäftsprozesse und spezielle Innovationsprozesse auf standardisierte Austauschformate (BPMN und XMI/XML sowie RDF/XML) zurückzuführen (sog. Top-Down-Ansatz). Werkzeuge wie DiPP unterstützen dabei, Prozesse einzuordnen und referenzierende Prozesshierarchien bei [DIPP] sog. Prozesslandschaften zu bilden. Gedanklich kann WPIM auch diese Hierarchien und Relationen unterstützen. Derzeit liegt der Fokus von WPIM jedoch auf der Domäne der Innovationsprozesse Evaluationspartner: SOLIN AG, München Die SOLIN AG hat im Rahmen der ISO: Zertifizierung ihren Entwicklungsprozess visualisiert. Zudem werden im Rahmen der ISO-Zertifizierung mehr als 30 Prozesse abgebildet. Die vorliegenden modellierten Prozesse bilden die real gelebten Geschäftsprozesse der SOLIN AG ab. Bei der SOLIN AG wurden direkte Parallelen zur Prozessorientierung erkannt. Die Prozessorientierung gilt als einer der sieben Grundsätze im Qualitätsmanagement (QM) nach ISO ISO:9001 ist speziell auf das Qualitätsmanagementsystem ausgelegt. 252

277 Evaluation der WPIM-Anwendung Abb. 5.5: Entwicklungsplanung und Entwicklungsprozess der SOLIN AG Die entstandene Prozesslandschaft soll zudem zur Einführung eines Enterprise Ressource Planning (ERP) konkret dem Produkt Abacus 304 genutzt werden. Zudem hat die SOLIN AG einen eigenen Produktentstehungsprozess (PEP) für die Domäne Engineering entwickelt. Dieser Innovationsprozess orientiert sich am V-Modell [Kap ] und stellt Vorlagen (eng. templates) und Checklisten bereit, welche die Entwickler bei der Arbeit entlasten und hilfreiche Anleitungen bieten. Zwischen den Phasen sind sog. Qualitygates eingeführt. Zudem fordert ein sog. Projektaufsichtsrat Entwicklungsergebnisse ein, um die Qualität und Vollständigkeit von Ergebnissen zu überprüfen. Erst nach erfolgreicher Abnahme der Qualitygates durch den Projektaufsichtsrat kann die nächste Entwicklungsphase gestartet werden. Jedes nach ISO:9001 zertifizierte Unternehmen ist verpflichtet, alle qualitätsrelevanten Prozesse (darunter fallen insbesondere Entwicklungsprozesse und Produkt-Entstehungs-Prozesse, PEP) in einer Prozesslandschaft darzustellen und die entsprechenden Prozesse zu modellieren. Dazu sind Vorlagen (bei ISO als Formblätter bezeichnet) und Verfahrensanweisungen (bei ISO als Arbeitsanweisungen bezeichnet) zu erstellen. Personenbezogene Rollen und QM-bezogene Ansprechpartner sind definiert und müssen zugewiesen werden. ISO trifft jedoch keinerlei Vorgaben hinsichtlich der zu verwendenden Modellierungssprachen. Der WPIM-Ansatz ist kompatibel zu ISO und stellt eine mögliche normkonforme Implementierung sicher

278 Evaluation der WPIM-Anwendung Projektskizze Anforderungen Festlegen Validierung und Instalation Produkt Anforderungsmodell Lastenheft Gate: Lastenheft Gate: Produkverifikation System Spezifizieren Zusammenbau und Systemtests Projektplan Systemmodell Gate: Grobkonzept Gate: Modulverifikation Feinentwurf Modultests Module 1..* Gate: Feinentwurf Modulrealisierung- / Aufbau Abb. 5.6: V-Modell der SOLIN AG, modelliert im Enterprise Architect mit SysML WPIM unterstützt die prozess- und rollentechnischen Anforderungen und geht konform mit ISO:9001: Der WPIM-Ansatz verwendet die PBMN und XML-nahen Sprachen. Diese sind konform zu den Vorgaben durch ISO:9001. Rollenkonzepte sind in der Expertenontologie sowie im E2E berücksichtigt. ISO:9001- Rollen wie der Beauftragte der obersten Leitung (BdoL), der Quality Manager (QM) und weitere Mitarbeiterrollen können in der WPIM-Anwendung eingeführt und modelliert werden. Der Ansatz WPIM ermöglicht die prozessorientierte Integration, der von der ISO geforderten Dokumente (wie z. B. Arbeitsanweisungen und Formblätter), in die Prozessbausteine (z. B. Aktivitäten oder Entscheidungsbausteine) sowie in die modellierten Prozesse. Die Prozessorientierung und die Modellierung von Prozessen sind weit verbreitete Ansätze, wie an der Vielzahl der nach ISO:9001 zertifizierten und somit diesen Grundsätzen folgenden Unternehmen belegt werden kann Evaluationspartner: Ein Unternehmen der Energiebranche Im Rahmen der vom Autor betreuten Masterarbeit von Wollborn [Woll10] wurde an einem konkreten Prozess der Energiebranche die Kopplung von (Prozess-) Aktivitäten und den Ressourcen (Experten und Dokumente) real evaluiert. Ziel dabei ist es, die WPIM-Methoden zu verifizieren und die WPIM-Pipeline zu erproben. Als Besonderheit wurde das Prozessmodell aus dem Energiesektor in ARIS modelliert. ARIS unterstützt (ebenfalls wie der BPVA) Exporte der Prozesse und Aktivitäten (bei ARIS sog. Aktivitäten und Funktionen) nach XML. ARIS als Prozess-Frontend ist somit kompatibel zur prototypischen WPIM-Pipeline. Die im Folgenden vorgestellten Implementierungen, die SPARQL-Anfragen und Ergebnisse entstammen der Masterarbeit von [Woll10]. Die Arbeit [Woll10] wurde im Rahmen dieser Arbeit ausgeschrieben und betreut. 254

279 Evaluation der WPIM-Anwendung Abb. 5.7: Prozess der Energiebranche modelliert in ARIS Bei dem in [Abb. 5.7] gezeigten Prozess können Aktivitäten anhand der Formen (z. B. Rechtecke mit abgerundeten Ecken) sowie der Farben (z. B. grün) leicht identifiziert werden. Das ARIS Modell kann ebenfalls nach XML exportiert werden und erfüllt somit die WPIM- Anforderung der XML-Kompatibilität. Abb. 5.8: Konkrete Implementierung der Domänen-Ontologie im Energiesektor Die entstandene Ontologie mit Klasse:Aktivitäten, Klasse:Experten und Klasse:Dokumente wurde mit konkreten Aktivitäten, Experten und Dokumenten populiert. Im weiteren Verlauf wird eine SPARQL-Anfrage an die Ontologie sowie das gelieferte Ergebnis der Abfrage gezeigt [vgl. Woll10]. Die natürlichsprachliche Fragestellung lautet: Für welche Aktivitäten ist Claus Theil- Dallaire Experte? Die entsprechende SPARQL-Abfrage dazu lautet: PREFIX owl: <http://www.owl-ontologies.com/ontology owl#> SELECT?Aktivität WHERE { foaf:claus_theil_dallaire owl:ist_experte_für?aktivität.} Code 5.1: SPARQL Abfrage: ist_experte_für?aktivität 255

280 Evaluation der WPIM-Anwendung Das Ergebnis der SPARQL-Abfrage ist in [Abb. 5.9] dargestellt: Abb. 5.9: Ergebnis der SPARQL Abfrage in Protégé Das Ergebnis kann so interpretiert werden: In [Abb. 5.9] werden die beiden Aktivitäten B_Relevante_RLM_Zeitreihen_berücksichtigen und E_Meldung_an_BKN_vorbereiten als Ergebnis zurückgegeben. Für diese beiden Aktivitäten ist Claus Theil-Dallaire der Experte. Dazu eine Anmerkung sowie die Bewertung der Ergebnisse: Den Aktivitäten wurde manuell bei der Modellierung ein alphabetisches Suffix z. B. B_ oder E_ vorangestellt. Dieses dient dazu, die Aktivitäten eines Prozesses (soweit möglich) alphabetisch, dem Ablauf folgend, zu ordnen und nicht auf die Sortierung im Werkzeug Protégé vertrauen zu müssen. Hieran wird auch das Szenario [3.3.1 Szenario 1: Projektübergabe und Nachfolger- Regelung] untermauert. Experten werden zu Aktivitäten zugeordnet und können durch die gezeigte SPARQL-Abfrage als Experte für eine Aktivität identifiziert werden. Auch Beratungsunternehmen für die Energiebranche und Unternehmen der Energiebranche [Woll10] nutzen Prozessmodellierungen, z. B. in ARIS. Hieran wird demonstriert, dass der WPIM-Ansatz auch für Unternehmen weiterer Industrien (neben denen der fertigenden Industrien) und Branchen (über die der Automobilindustrie hinaus) geeignet ist. In [Woll10] werden weitere typische Fragestellungen bei der Hervorbringung von Innovationen aufgegriffen und als SPARQL-Anfrage formuliert. Die semantischen Suchen mit erzielten Ergebnissen sind in [Woll10] ausführlich dargestellt. Zu den Fragestellungen zählen u. a.: Wer sind die Experten zu einer konkreten Aktivität? Zu welchen Aktivitäten ist ein konkreter Mitarbeiter der Experte? Welche Dokumente gehören zu einer konkreten Aktivität? Welche Kommentare sind einer einzelnen Aktivität zugeordnet? Welche Fachbegriffe sind einer einzelnen Aktivität zugeordnet? Diese Fragestellungen sind in [Woll10] in Anlehnung an die Abfragen [vgl. Code 5.1] und die Ergebnisse [vgl. Abb. 5.9] aufbereitet. Durch die semantischen Suchen über dem semantischen WPIM-Prozessmodell kann erstmals der Nutzen der semantischen Technologien im Bereich von WPIM demonstriert und technisch evaluiert werden Evaluationspartner: PHILIPS PCLAT, Eindhoven, NL [Abb. 5.10] zeigt einen Muster-Prozess, wie er bei Innovationsprojekten bei Philips Consumer Lifestyle Advanced Technology (PCLAT) in Eindhoven, NL zum Einsatz kommt. Dieser Muster- Prozess wird derzeit für ca. 100 Innovationen als Entscheidungsgrundlage und für Reviews, z. B. zur Bewertung von Marktchancen einzelner Innovationen, eingesetzt. 256

281 Evaluation der WPIM-Anwendung Abb. 5.10: Innovationsprozess bei Philips PCLAT Im Anschluss folgt die Beschreibung der einzelnen Schritte bei Innovationen. 257

282 Evaluation der WPIM-Anwendung Activity Description Triangle meetings: Each triangle has a triangle owner. He chairs the triangle and is responsible for the minutes. In the triangles the various roadmaps are presented and discussed. Benchmark results are part of the input for the discussion. The process is iterative, and on the function feature roadmap agreed items and wish items are marked as such, while the agreed technology roadmap reflects the agreed function feature roadmap. Prepare Proposals in Global triangles: From these roadmaps specialist from the triangles identifies proposals for Know-how (KH) programs. For every proposal an owner is determined who prepares the GT input. This is done in a global meeting (per competence area). Proposals are clustered to packages where considered useful to improve the total overview. For the proposals a short description (a few lines) is made, estimates for the required manpower are made for all involved Function Teams, including subcontracting, as well as major investments necessary. If possible, Bill of Materials (BOM) cost are estimated. Golden Triangles (GT): The GT is organized two times a year before (typically a few months) the Global Program Board (GPB). On the GT all proposals are presented per triangle or cluster, and reviewed. Specific purchasing issues are presented as part of a triangle. The GT prioritizes the total list of proposals and selects the proposal which fits the overall business objectives best. The GT decides on allocating resources for selected KH projects. Allocating resources for certain projects can be delayed. Create assignments: An assignment will be generated of the agreed proposals. If it is a small project, the assignment will be used as project plan. For larger project a complete project plan will be written. The assignment will be reviewed with and agreed with the receiving party. Execute plan: The KH will be executed. Between the phases a feedback loop is made with the KH program manager. This is illustrated by the not ready arrow. Requests for changes, including their implications for resources/deliverables/timing, are escalated to the Innovation Lab Steering Board for decision making. Project review meeting: In the project review meetings (held monthly) projects will presented and discussed with the Eindhoven innovation lab management. The program manager can represent the technical project leader. 258 Tab. 5.1: Prozessbeschreibung des Innovationsprozesses bei Philips PCLAT In [Tab. 5.1] ist die natürlichsprachliche Prozessbeschreibung zum Innovationsprozess bei Philips gezeigt. In den sog. Triangle Meetings bestehend aus drei Personengruppen aus der Entwicklung, der Fertigung und dem Vertrieb wird anhand definierter Kriterien über die Fortführung einzelner Projekte entschieden. Die Beurteilung einzelner Entwicklungen erfolgt in festgelegten zeitlichen Abständen. Im Folgenden wird das Skalierungsproblem bei WPIM aufgegriffen und eine entsprechende Lösung zur Skalierungs-Herausforderung vorgestellt. Die (Top-Down) Skalierbarkeit des generischen Prozessmodells [vgl. Abb. 5.10] hin zu den Prozessinstanzen bei PCLAT kann anhand der mehr als 100 Innovationsprojekte belegt werden. Der WPIM-Ansatz ist mit dem praxiserprobten Innovationsansatz von Philips PCLAT vereinbar. Es ist möglich, den generischen Innovationsprozess von Philips mit den WPIM-Methoden zu beschreiben. Somit können auch die einzelnen Innovationsprozesse (genauer die Instanzen des Innovationsprozesses) mit WPIM modelliert, annotiert und semantisch durchsucht werden. Daran wird deutlich gemacht, dass WPIM nicht nur für einen einzelnen Innovationsprozess

283 Evaluation der WPIM-Anwendung Gültigkeit besitzt, sondern für eine Vielzahl von unterschiedlich gearteten Innovationen im technischen Umfeld eingesetzt werden kann. Die Bandbreite dieser 100 Innovationsprojekte bei Philips PCLAT (mit unterschiedlicher Komplexität, Umfang, Innovationstiefe) und die Kompatibilität zu WPIM zeigt somit auch die Skalierbarkeit des WPIM-Ansatzes, der WPIM- Methoden und der WPIM-Anwendung auf Zusammenfassung der Ergebnisse mit den Evaluationspartnern Die WPIM-Methoden werden mit den Evaluationspartnern punktuell erprobt und evaluiert. Darüber hinaus wurde die WPIM-Pipeline auch in ihrer Gesamtheit getestet und durchlaufen [vgl. Woll10]. Durch die Einbindung potenzieller Benutzer in frühe Gestaltungsphasen der WPIM-Benutzungsschnittstellen gelang es rechtzeitig, das Design der Schnittstellen zu reflektieren und die Funktionalität und Bedienbarkeit der WPIM-Anwendung anzupassen. Besonderer Dank gilt Philips PCLAT und dem SHAMAN-Projekt, die sowohl detaillierte Prozessbeschreibungen und auch Organisations- und Rollenstrukturen bereitgestellt haben. Mit dem Golden Triangle Prozess bei Philips PCLAT ist es zudem gelungen, weitere übergeordnete Evaluationsziele wie die Skalierbarkeit der WPIM-Methoden aufzuzeigen. Philips PCLAT nutzt diesen Musterprozess für ca. 100 Produktinnovationen, für welche jeweils eine Instanziierung des Musterprozesses vorgenommen wird. Daran gelingt es, die frühe Idee und Herausforderung dieser Arbeit, Musterprozess und Prozessinstanzen im Umfeld von Innovationen [Abb. 3.24] anzulegen, in der Praxis nachzuweisen. Die semantischen Suchen mit SPARQL konnten in realen Szenarien erprobt werden und liefern gute Ergebnisse. In der betreuten Masterarbeit [Woll10] werden die WPIM-Methoden und der WPIM-Prototyp neben der fertigenden Industrie auch auf Prozesse der Energiewirtschaft angewendet. Zudem werden weitere Prozessmodellierungs-Frontends wie ARIS [in Woll10] erprobt und auch Visio [VISI], DiPP [DIPP] sowie XML/XMI-Formate aus der betrieblichen Praxis auf Kompatibilität zu WPIM untersucht. Der Übergang von Innovationsprozessen auf allgemeine generische Prozesse ermöglicht Erklärungen zur Skalierbarkeit der WPIM-Anwendung. Ebenso wird der potenzielle Einsatz der WPIM-Methode in weiteren Branchen und Domänen nachgewiesen. Im weiteren Verlauf der Arbeit wird hierzu eine branchen- und unternehmensunabhängige Betrachtung zur Wirtschaftlichkeit der WPIM-Anwendung vorgestellt. 5.2 Wirtschaftlichkeitsanalyse der WPIM-Investition Bei der Einführung von WPIM handelt es sich um die Einführung der neuen Methoden zum WPIM und der WPIM-Anwendung. Im folgenden Abschnitt betrachten wir Kosten und Nutzen zur WPIM-Anwendung. Kosten und Nutzen werden dabei zunächst von einem technischqualitativen Standpunkt aus beleuchtet. Danach legen wir eine ökonomische Betrachtung an, quantifizieren den Nutzen und ziehen für Kosten und Nutzen eine monetäre Bewertung heran. Dabei stehen Kosten zur Entwicklung der Anwendung sowie für mögliche Softwarelizenzen im Vordergrund. Hierzu wird im Folgenden eine Kostenstrukturanalyse sowie eine Return-On- Investment (ROI)-Betrachtung aufgestellt. Die Nutzenbetrachtung und Nutzenbewertung bei der Einführung von WPIM bilden den Kern dieser Wirtschaftlichkeitsbetrachtung. Für den schwer quantifizier und somit schwer oder kaum monetär bewertbaren Nutzen wird u. a. die Methode der Arbeitswerte (engl. Hedonic Wage Model) vorgestellt. Begonnen wird mit der Betrachtung zu Kosten und Kostenstrukturen Kostenstrukturen Zunächst wird bei der WPIM-Investition nach Einmal- und nach Folgekosten unterschieden. Im Besonderen wird auf Kosten für kommerzielle Entwicklungswerkzeuge, Standards und 259

284 Evaluation der WPIM-Anwendung Technologien eingegangen. Die Auswahlentscheidungen für Werkzeuge und Technologien werden nachvollziehbar aufgezeigt. Die grob geschätzten Anschaffungskosten (für Kauf- Software und Standard-Software) fließen in die Auswahlentscheidung ein, sind aber aufgrund der Schätzung und der vielen weiteren Einflussfaktoren nicht das einzige Auswahlkriterium. Zudem werden Lizenzkosten für kommerzielle Prozessmodellierungs-Werkzeuge (die das sog. WPIM-Frontend bilden) untersucht. Weitere Differenzierungen nach Erstellungskosten der WPIM-Anwendung und den Kosten für die benötigte IT-Infrastruktur und die verbundenen Werkzeuge werden im Rahmen der ROI-Entscheidung diskutiert Kosten für Entwicklung, Einführung und Wartung von WPIM Wir unterscheiden zwei Kategorien die der einmaligen Erstellungskosten und die der (über die Zeitachse) laufenden Kosten. Diese zeitliche Betrachtung ist für Return-On-Investment- Betrachtungen von Interesse, da (zinslich bewertete) Zahlungsflüsse im Zeitverlauf berücksichtigt werden. Die Unterscheidung beruht auf der Kostenanalyse von Stucky/Sommer [StSo05] und ist für den Einsatz von Standardsoftware konzipiert. Dieser Aufteilung folgend werden Kostenblöcke und Kostentreiber identifiziert. Nach [StSo05] entstehen einmalige Erstellungskosten für: 260 Implementierung, Technologien, Standards, Entwicklungswerkzeuge, Prozessmodellierungs-Werkzeuge (sog. Prozess-Frontend), Kauf-Software (engl. Commercial Off-The-Shelf, COTS), Anpassungen an ein Unternehmen, Lizenzkosten Server, Lizenzkosten Client, IT-Systemumstellung und Migration. Laufende Kosten so [StSo05] werden verursacht durch: Laufende Lizenzen, Training/Schulungen, Anlegen neuer Nutzer, Hotline und IT-Support, Maintenance Server, Maintenance Client, Maintenance Backup. Im Folgenden werden grob die wichtigsten Kostentreiber für die Erstellung der WPIM-Methode und des WPIM-Prototyps geschätzt. Dieses sind die Kosten der Implementierung [vgl ] und Lizenzkosten [vgl ]. In [Tab. 5.8] sind diese geschätzten Kosten für die IT- Infrastruktur zusammenfassend dargestellt, quantifiziert und monetär grob bewertet Kostenschätzung zur Implementierung der WPIM-Anwendung Eine typische Schätzung zum Erstellungsaufwand einer Software (wie auch hier für die WPIM- Methoden, die WPIM-Pipeline und die WPIM-Anwendung) erfolgt über eine Projekt- bzw. Zeitplanung. Die Zeiten für die Entwicklung und Implementierung von Methoden und softwaretechnische Implementierung der WPIM-Anwendung sind der Kostentreiber schlechthin und verursachen den größten Kostenblock.

285 Evaluation der WPIM-Anwendung Ausgangspunkt einer groben Kostenschätzung bildet die qualitative Betrachtung der zu erledigenden Aufgaben. Dazu werden zunächst Arbeitspakete (AP) mit konkreten Aufgabenbeschreibungen definiert. Die Arbeitspakete stehen in (z. B. zeitlichen) Beziehungen zueinander und können sich bedingen. Die Arbeitspakete werden sodann einer quantitativen Betrachtung unterzogen. Dazu wird eine zeitliche Bewertung der AP vorgenommen. Üblicherweise werden solche Arbeitspakete mit Manntagen (MT), Mannmonaten (MM) oder auch Mannjahren (MJ) bemessen. AP werden zudem häufig mit Faktoren 305 gewichtet. Somit kann zunächst der zeitliche Umfang einzelner APs und darauf aufbauend auch der Umfang des gesamten SW-Projektes ermittelt werden. Bei der monetären Bewertung von Arbeitspaketen sind zudem einige Annahmen zu treffen. Die monetäre Kalkulation erfolgt auf der Basis von Stunden- oder Tagessätzen. Diese lassen sich wiederum aus den Brutto-Gehältern zzgl. Lohn- und Lohnnebenkosten (in Deutschland ca. 21 %) zzgl. eines anteiligen Aufschlags an Gemeinkosten errechnen. Als Faustregel der Automobilindustrie werden grob etwa 100kEUR für ein Mannjahr (bei 210 Arbeitstagen pro Jahr) veranschlagt. Allerdings kann der erste grobe Schätzwert für die Kosten eines Mannjahrs aber stark abweichen je nach Branche, Tätigkeit, Qualifikation und Berufserfahrung. Dieser erste Schätzwert wird für eine grobe monetäre Bewertung der Arbeitspakete herangezogen und soll vielmehr die Vorgehensweise der Bewertung als die tatsächliche Kostenermittlung darlegen. Arbeitspaket (AP) WPIM Bewertung quantitativ (MM) Monetär (EUR) Idee 0, Anforderungen 0, Spezifikation Methodenentwurf Systemarchitektur Modellbildung Implementierung Test/Absicherung 0, Iterative Verbesserung 0, Evaluation 0, Dokumentation Ergebnisse 0, Summe 10,0 MM EUR Tab. 5.2: Arbeitspakete bei der WPIM-Entwicklung Die in [Tab. 5.2] vorliegende zeitliche Bewertung und grobe monetäre Kalkulation der APs (orientiert an den Phasen des V-Modells) beruht auf den oben getroffenen Annahmen und zudem darauf, dass ein 306 Entwickler Vollzeit mit Durchführung betraut ist. Dies sind wünschenswerte Voraussetzungen und idealtypische Annahmen, wie sie in der Praxis leider nur selten anzutreffen sind. Wäre WPIM im Kundenauftrag, z. B. für einen Evaluationspartner, als Auftragsarbeit entstanden, würde in der Praxis häufig ein dreistufiges Verfahren angewandt: Zunächst eine Konzeptphase, gefolgt von einem Grobentwurf (auch Funktionsmuster genannt) und 305 Ein unerfahrener Mitarbeiter benötigt ca. 1,2 bis 1,5-mal länger (sog. Faktor), um ein AP abzuarbeiten. 306 Wie die Praxis zeigt, kann bereits die Aufteilung der Arbeitspakete auf mehrere Entwickler zu erhöhtem Abstimmungsbedarf und einem verzögerten Entwicklungsablauf führen. 261

286 Evaluation der WPIM-Anwendung abschließend im Feinentwurf die Prototyperstellung. Üblicherweise werden die einzelnen Phasen durch den Kunden (sog. Qualitygates) abgenommen, um so das Risiko von Fehlentwicklungen zu minimieren. Diese organisatorischen Aufgaben sind aber nicht der WPIM- Anwendungsentwicklung, sondern der Projektierung und dem Projektmanagement zuzuordnen Lizenzkosten für Technologien, Standards und Werkzeuge Für die kommerzielle Etablierung der WPIM-Anwendung sind neben den Erstellungskosten der Software auch die entstehenden Lizenzabhängigkeiten und Lizenzkosten der Erstellungswerkzeuge sowie der kostenpflichtigen unterstützenden Anwendungen zu beachten. Es folgt die Übersichten zu Technologien und Standards, Werkzeugen und insbesondere Prozessmodellierungs-Werkzeugen (den sog. Prozess-Frontend Werkzeugen): Technologien u. Standards Auswahlkriterium Offener Standard Kosten XML ja nein DTD ja nein XSD ja nein XSLT, XPATH, DOM ja nein RDF/RDF(S) ja nein Dublin Core (DC) ja nein Friend-of-a-Friend (FOAF) ja nein OWL (Light, DL, Full) ja nein BPMN ja nein BPML ja nein HTML ja nein PHP ja nein SQL ja nein SPARQL ja nein Summe keine Kosten Tab. 5.3: Kriterien zur Auswahl: Technologien und Standards zum Datenaustausch Der für die Entwicklung der WPIM-Anwendung geforderte und berücksichtigte Einsatz freiverfügbarer und offener Standards macht sich nun positiv auf der Kostenseite bemerkbar. Für die verwendeten Standards und Technologien sind keine Lizenz- oder Nutzungskosten zu entrichten. Werkzeuge Auswahlkriterium frei verfügbar Kosten XML Spy (optional*) nein* 400 EUR* SemanticWorks (optional*) nein* 100 EUR* DiaGnome ja nein Protégé GNU nein Xampp für PHP GNU nein Xampp mit mysql GNU nein OmnitHttpD Server ja nein Pellet GNU nein FaCT++ GNU nein Eclipse GNU nein Summe (optional*) keine Kosten Tab. 5.4: Verfügbarkeit und Lizenzkosten für verwendete Erstellungswerkzeuge 262

287 Evaluation der WPIM-Anwendung Auch bei den eingesetzten Entwicklungswerkzeugen entstehen keine Kosten. Die beiden Werkzeuge XML-Spy und SemanticWorks in [Tab. 5.4] mit * als (optional*) markiert wurden zwar erprobt, haben aber für die Entwicklung der WPIM-Pipeline keine zwingende Notwendigkeit. Sie erleichtern zwar die Entwicklung haben aber keinen Anspruch auf Verwendung. Frontend Auswahlkriterium Auswahlentscheidung frei verfügbar Kosten Visio, Microsoft nein 260 EUR** ARIS, IDS Scheer nein EUR** ebpmn, Soyatec ja nein BPMN Designer, Intalio nein 600 EUR** BPEL Designer, Eclipse ja nein BPVA, Visual Paradigm nein 600 EUR** EA, Sparx Systems nein 600 EUR** Summe (Auswahl**) 600 EUR** Tab. 5.5: Lizenzkosten (grob) für das Prozess-Frontend von WPIM In [Kap ] und [Tab. 2.1] fällt die begründete Entscheidung anhand eines Kriterienkatalogs auf den BusinessProcess VisualArchitect (BPVA). Wie in [Tab. 5.5] dargestellt, wählen wir eines der Werkzeuge zur Modellierung von Prozessen aus (in der Auswahl gekennzeichnet mit **) und setzen 600 EUR für das Prozess-Frontend an. Die Praxis so [Woll10] sowie die Studie mit Philips PCLAT [vgl. Kret12] zeigt, dass potenzielle Evaluationspartner neben den in [Tab. 5.5] gelisteten Werkzeugen auch andere/weitere Prozessmodellierungs-Werkzeuge 307 verwenden. Bei den Lizenzkosten ist anzumerken, dass keine weiteren zeitbezogenen Kosten, wie z. B. jährliche Lizenzkosten, anfallen. Die grob dargelegten Lizenzkosten in [Tab. 5.5] sind einmalige Kosten beim Kauf der Modellierungs-Werkzeuge. Auf die Betrachtung der Kosten und Kostenstrukturen folgt nun die Nutzenanalyse Nutzenanalyse Bei der sozio-technischen Erprobung der WPIM-Methoden sowie WPIM-Anwendung mit ihren Werkzeugen wird im Cognitiven Walk-Through der Nutzen aus Sicht der Anwender aufgezeigt. Eine empirisch-orientierte systematische Erprobung der Anwendung mit Testpersonen wurde bisher nicht vorgenommen. Im Folgenden werden Methoden zu Nutzenmessung aufgeführt. Während im Rahmen der Wirtschaftlichkeitsanalyse die Einmal- und Folgekosten der IT- Investition relativ gut ermittelt und mit akzeptablem Aufwand zu bestimmen sind, bereitet die Abschätzung der Nutzeneffekte von IT-Projekten und insbesondere deren monetäre Bewertung den Unternehmen größere Schwierigkeiten. [TrBe01 in Quaa05, S.9] Neben der Definition von Nutzen werden Nutzenkategorien sowie deren Unterscheidung dargestellt. Insbesondere wird auf den quantifizierbaren Nutzen und die monetäre Bewertung von Nutzen eingegangen. Im Rahmen der Nutzenanalyse wird zwischen Brutto- und Nettonutzen unterschieden. 307 [Tab. 4.2] zeigt, dass durchaus eine Reihe weitere Prozessmodellierungs-Werkzeuge einsetzbar sind. Diese Prozessmodellierungs-Werkzeuge bilden aus WPIM Sicht das Frontend des Prototyps und unterstützen die Benutzer bei der Prozessmodellierung bzw. -verwaltung und -visualisierung bestehender Prozessmodelle. 263

288 Evaluation der WPIM-Anwendung Nutzenkategorien Quaas [Quaa05] hat eine Übersicht zu Nutzenkategorien erarbeitet und stellt bestehende Ansätze detailliert vor. Wir haben drei Ansätze aufgegriffen, die wir im Folgenden vorstellen werden. Abschließend folgt die schematische Übersicht zur Kategorisierung von Nutzen nach [Quaa05]. Definition 5.1: Nutzen In der ökonomischen Theorie versteht man unter dem Nutzen das Maß für die Fähigkeit eines Gutes, die Bedürfnisse eines wirtschaftlichen Akteurs zu befriedigen. [DeMT01] Nach [Quaa05] verfolgt [Park86] die Einteilung in Bezug auf die Nutzenwirkung. Dies entspricht in weiten Teilen dem Ansatz von [Krcm05]. [Krcm05] unterscheidet den Nutzen der Informationstechnologie (IT) nach den drei folgenden Kategorien: Nutzen aus Kosteneinsparungen, Nutzen aus Produktivitätssteigerungen, Nutzen aus strategischen Wettbewerbsvorteilen. Die Systematisierung des Nutzens nach [MeBo91] unterscheidet nach der Quantifizierbarkeit, also der mengenmäßigen Erfassung des Nutzens [vgl. Quaa05]. Die Aufteilung erfolgt ebenfalls in drei Nutzenkategorien: direkt (leicht) quantifizierbarer Nutzen, schwer quantifizierbarer Nutzen, nicht quantifizierbarer Nutzen. Weitere Ansätze beschäftigen sich mit der Unterscheidung von: finanziellem, nicht-finanziellem und direktem Nutzen. Hieran lässt sich schon der Übergang von Nutzen hin zu quantifizierbarem Nutzen erkennen. Weiter kann quantifizierbarer Nutzen, wie z. B. Zeiteinsparungen oder Produktivitätssteigerungen, z. B. über die Bewertung mit den Lohnkosten in finanzielle Messgrößen oder monetäre Größen überführt werden. Dem zuletzt vorgestellten Ansatz folgt auch [Piet03]. Er unterscheidet zwischen quantifizierbarem und nicht-quantifizierbarem Nutzen und unterteilt diesen weiter nach der Monetarisierbarkeit. Es ergeben sich folgende Kombinationen: quantifizierbarer und monetarisierbarer Nutzen, quantifizierbarer und nicht-monetarisierbarer Nutzen, nicht-quantifizierbarer und nicht-monetarisierbarer Nutzen. Die theoretische Kombinationsmöglichkeit Nicht-quantifizierbarer und monetarisierbarer Nutzen führt [Piet03] in seinem Ansatz nicht auf. Daraus wird ersichtlich, dass einer Monetarisierung des Nutzens zwingend dessen Quantifizierung vorausgehen muss. [vgl. Piet03 in Quaa05, S.14]. [Schu92, Schu93] unterscheiden weiter in direkten und indirekten Nutzen: 264

289 Evaluation der WPIM-Anwendung Abb. 5.11: Kategorisierung nach direktem und indirektem Nutzen [nach Quaa05, S.15] Für WPIM, mit den beiden Ansätzen wissensbasiert und prozessorientiert, werden folgende Nutzenkategorien abgeleitet: Produktivitätssteigerungen, Prozessverbesserungen. Da es sich um Schätzwerte handelt, ist es im weiteren Verlauf der Arbeit das Ziel, exemplarisch beide Ansätze der Methode WPIM wiederzugeben. Die beiden vorgestellten Nutzenkategorien bilden auf diese Ansätze ab. Es gibt eine Vielzahl weiterer Nutzenkategorien und Ansätze. Wir runden die Betrachtung mit zwei weiteren Definitionen nach [DeMT01] ab: Definition 5.2: Erwartungswert Ist aufgrund von Unsicherheit der Nutzen eines Gutes nicht quantifizierbar, so spricht man vom Erwartungsnutzen. [DeMT01] Definition 5.3: Nettonutzen Dem Nutzen stehen die Kosten gegenüber. Die Differenz zwischen Nutzen und Kosten wird als Nettonutzen bezeichnet. [DeMT01] Gerade der Begriff des Nettonutzens dient als Ausgangpunkt für die Messung von Nutzen und die Kosten-Nutzen-Analyse. Im Folgenden wird die Problematik der Nutzenmessung aufgezeigt Problematik der Nutzenmessung Die Messung des Nutzens der Informationstechnologie, insbesondere der indirekten Nutzeneffekte, erweist sich als schwierig [Quaa05, S. 20]. Grundlegend wird die Frage diskutiert, inwieweit sich der Nutzen von IT-Investitionen zu denen wir auch das WPIM- Informationssystem zählen in monetären Einheiten ausdrücken lässt [vgl. Quaa05]. Als Schwierigkeiten bei der Messung von Nutzeneffekten führt [Hube99 in Quaa05, S. 22 ff.] fünf wesentliche Gründe an, die nun vorgestellt werden: 1. Hoher Abstand der IT zur Wertschöpfung Die Informationstechnologie weist häufig einen hohen Abstand zu den eigentlichen Wertschöpfungsprozessen des Unternehmens auf. 265

290 Evaluation der WPIM-Anwendung 2. Kommunikationsproblem Zwischen der IT-Abteilung und den Fachabteilungen existieren fachliche sowie inhaltliche Herausforderungen in der Kommunikation. 3. Zuordnungsproblem Nutzenwirkungen lassen sich oft nicht unmittelbar der Informationstechnologie zuordnen. Mehrere Einflussfaktoren könnten die beobachtete Wirkung herbeigeführt haben. Deshalb ist unklar, ob die entsprechende Nutzenwirkung dem Einsatz der IT tatsächlich zuzurechnen ist, oder ob der Effekt durch andere Gegebenheiten zustande gekommen ist. 4. Prognoseproblem Die IT-Abteilungen haben oft Schwierigkeiten, eine detaillierte Nutzenabschätzung bereit zu stellen und es werden häufig nur direkt ersichtliche Nutzenauswirkungen untersucht. 5. Nicht-Nutzung von Ex-post-Betrachtungen Die Nutzenabschätzung aus vergangenen Projekten wird oftmals nur unzureichend einbezogen. Im Detail sind die Schwierigkeiten bei der Nutzenmessung bei den Autoren [Quaa05; Hube99] nachzulesen. Im folgenden Abschnitt setzen wir hierauf aufbauend Methoden zur Bewertung der Wirtschaftlichkeit von WPIM und des WPIM-Informationssystems ein Methoden zur Bewertung der Wirtschaftlichkeit Wurden bisher Kosteneinsparungen als Hauptgrund für die Investition in die Informationstechnologie aufgeführt, so stehen heute andere Aspekte im Vordergrund. Eine europaweite Untersuchung unter 700 IT-Managern im Jahr 2004 ergab, dass noch 16 Prozent der Befragten lediglich aus Kosteneinsparungsgründen investieren. [Fryb04 in Quaa05, S. 9]. Diese Nutzeneffekte, welche zur Verbesserung des Geschäftsnutzens beitragen, also qualitativer und strategischer Natur sind, entziehen sich jedoch einer systematischen Erfassung und Bewertung [vgl. Quaa05]. Dies ist darin begründet, dass sowohl qualitative als auch strategische Nutzeneffekte eines IT-Systems mindestens prozess- und sogar unternehmensübergreifende Einflüsse besitzen. Daher können diese nicht isoliert am Entstehungsort der Effekte betrachtet werden [vgl. Quaa05]. Die Informationstechnologie wird zudem häufig als Voraussetzung (also als sog. Enabler) für die Durchführung von Geschäftsprozessen [vgl. Quaa05; MeZK03] gesehen. Im weiteren Verlauf der Arbeit werden daher zunächst Kosten-Nutzen-Analysen betrachtet Kosten-Nutzen-Analysen Kosten-Nutzen-Analysen werden für Wirtschaftlichkeitsuntersuchungen herangezogen. Die Ergebnisse dienen zur Entscheidungsunterstützung, z. B. bei Investitionen. Aufbauend auf den mehrdimensionalen Methoden wie der Nutzenanalyse sowie der Nutzenwertanalyse wird die Kosten-Nutzen-Analyse (engl. Cost-Benefit-Analysis) vorgestellt. Definition 5.4: Wirtschaftlichkeit Wirtschaftlichkeit bringt zum Ausdruck, wenn durch eine Gegenüberstellung finanzieller Größen eine aussagefähige Verhältniszahl des Erfolgs geschaffen wird. [Piet03] [Piet03] sieht weiter die Wirtschaftlichkeit durch die Verhältniszahl von in Geld bewertetem Ertrag zu dem in Geld bewerteten Mitteleinsatz (Aufwendungen), innerhalb eines abgegrenzten Betrachtungszeitraums, gegeben. 266 Definition 5.5: Nutzenanalyse

291 Evaluation der WPIM-Anwendung In der Nutzenanalyse wird versucht, die Realisierungschancen von Nutzenpotenzialen systematisch abzubilden. [vgl. Antw95] Als Entscheidungsgrundlage dient eine Nutzen-Risiko-Matrix [vgl. Antw95]. Definition 5.6: Nutzenwertanalyse Die Nutzwertanalyse findet immer dann Anwendung, wenn rein qualitative bzw. nichtmonetarisierbare Nutzeneffekte (indirekter Nutzen) bewertet werden sollen. [vgl. Quaa05] Die Nutzwertanalyse wurde von [Zang76 in Quaa05] entwickelt und hat das Ziel, komplexe Handlungsalternativen bewertbar zu machen. Definition 5.7: Kosten-Nutzen-Analyse In einer Kosten-Nutzen-Analyse werden prinzipiell anfallende Kosten und prognostizierte Nutzen in Geldeinheiten ausgedrückt. Danach werden diese jeweils addiert und ins Verhältnis zueinander gesetzt. Verglichen wird also der monetär bewertete Nutzen mit den zu erwartenden Kosten des Projekts 308. [Scho06] Scholtes zeigt folgende Charakteristika der Kosten-Nutzen-Analyse auf [Scho06]: Gesamtwirtschaftliche Kosten und Nutzen werden einbezogen. Die Methode ist auf eine ökonomische Rationalität (Erreichen der Ziele mit dem geringsten Geldeinsatz) ausgerichtet 309. Zur Orientierung dienen Marktpreise, sodass unterschiedliche Maßnahmen auf Geldniveau kardinal skaliert werden können [Sch006]. Roth/Doluschitz stellen den Ablauf der Kosten-Nutzen-Analyse im Detail vor [RoDo07]: 1. Identifizierung des Nutzens 2. Bewertung der Nutzenaspekte 3. Ermittlung der Kosten 4. Kumulierung der Kosten- und Nutzenaspekte 5. Abfrage der individuellen Zahlungsbereitschaften Quaas [Quaa05] und Roth/Doluschitz [RoDo07] zeigen neben dem Ablauf auch anhand von Beschreibungen und praktischen Beispielen den Einsatz der Kosten-Nutzen-Analyse. Diese Matrix gibt die entsprechende Standardaufteilung zur Nutzenanalyse wieder. Die Felder 1 bis 9 sind nach deren Wertigkeit aufgeteilt [Abb. 5.12]. Die Rangfolge ergibt sich aus der Annahme, dass das Risikogefälle zwischen den Nutzenkategorien geringer ist als das Gefälle zwischen den Realisierungschancen, und weiterhin aus dem Aspekt, dass eine höhere Erfassbarkeit eine höhere Wertigkeit mit sich bringt. [Antw95 in Quaa05] 308 Unter Projekt ist hier die Einführung der WPIM-Methode und des WPIM-Prototyps zu verstehen. 309 Diese Methoden können auch auf eine soziale (Erreichen der Ziele mit niedrigster unerwünschter Umverteilung zwischen sozialen Gruppen) oder ökologischen Rationalität (Erreichen der Ziele mit geringster Beanspruchung natürlicher Ressourcen) ausgerichtet sein. 267

292 Evaluation der WPIM-Anwendung 268 Abb. 5.12: Standard Risiko-Nutzen-Matrix der Risikoanalyse nach [Quaa05] Wie in [Abb. 5.12] dargestellt, ist Feld 1 am besten bewertbar und weist die höchste Realisierungschance auf. Das Feld 9 hingegen ist nur sehr schwierig zu erfassen und weist auch nur wenige Chancen zur Realisierung auf. Hieran wird ersichtlich, dass eine andere Nutzeneinteilung nur dann sinnvoll ist, wenn auch zwischen den Nutzenkategorien eine eindeitige Reihenfolge besteht [vgl. Quaa05]. Sind die Nutzenkategorien gleichwertig, so kann die dargestellte Rangfolge nicht eingehalten werden. Werden die Werte zeilenweise für jede Nutzenkategorie einzeln interpretiert, so können die Werte von links nach rechts als pessimistische, neutrale und optimistische Einschätzung für die Nutzenrealisierung gedeutet werden. Dies ergibt sich daraus, dass der monetäre Wert von links nach rechts zunimmt, jedoch die Wahrscheinlichkeit der Realisierung fällt. [Quaa05, S. 32] Da bei WPIM die Kosten der Einführung nur grob geschätzt und der Nutzen nicht quantifizierbar (und somit auch nicht-monetarisierbar) sind, nehmen wir an dieser Stelle Abstand von besagter quantitativen Erhebung und der Anwendung der Kosten-Nutzen-Analyse in Verbindung mit der Risiko-Nutzen-Matrix. Zur weiteren wirtschaftlichen Evaluation von WPIM folgt eine Investitionsrechnung zur WPIM-Anwendung Investitionsrechnung Return-on-Investment IT-Manager stehen zunehmend in der Pflicht, den Wertschöpfungsbeitrag ihrer Investitionen in die Informationstechnologie (IT) nachzuweisen [vgl. Geri03]. Dabei spielt die Frage nach der Wirtschaftlichkeit von IT-Projekten bzw. deren Return-On-Investment (ROI) eine zentrale Rolle. Diese mögliche Investitionsrechnung für WPIM orientiert sich an Investitionsrechnungen bei der Einführung von Business Intelligence (BI) Lösungen oder der Einführung von Informationssystemen. Die Zahlenwerken der ROI-Methode bauen auf der Kapitalwertmethode auf. In der Betrachtung wird ein fester Zinsfuß angenommen und eine Nettobarwertrechnung nach [Oehl08] vorgenommen. Zur Abgrenzung: Im engeren Sinn bezeichnet BI nur die Methodik der Datenerfassung, im weiteren Sinn versteht man unter Business Intelligence die Gesamtheit von Managementgrundlagen, wie z. B. Wissensmanagement, Customer-Relationship-Management oder die Balanced-Scorecard [vgl. MeZK03], die bei einem prozessorientierten Begriffsverständnis auch die permanente Datenpflege und Anpassung an ein veränderndes Umfeld umfassen (engl. strategic alignment) 310 [MeZK03]. In diesem Zusammenhang wird die 310 Abgrenzung und Begriffsverständnis BI und Wissensmanagement unter -

293 Evaluation der WPIM-Anwendung WPIM-Anwendung als semantische Komponente von BI-Lösungen bzw. als semantisches Informationssystemen im Umfeld der fertigenden Industrien betrachtet. Als Produktivitätssteigerungen verstehen wir die verbesserten Zeiten und dadurch reduzierten Kosten bei der Suche nach Wissen und Dokumenten, also den wissensbasierten Umfang nach der WPIM-Definition. Unter Prozessverbesserung sehen wir die zentrale Prozessorientierung bei der Ablage und Integration von Ressourcen im Umfeld der Innovationsprozesse bei WPIM. Auf die Verbesserung der Innovationsfähigkeit wird gesondert in [Kap. 5.5] eingegangen. Ausgangspunkt bietet die erarbeitete grobe Kostenbetrachtung aus [Kap ]. Anzumerken ist, dass in Unternehmen bei der Einführung neuer Methoden, Anwendungen oder Systeme üblicherweise Kosten der bestehenden IT zugeschlüsselt werden. Ein Beispiel: Eine neue Anwendung wird auf bestehende Server aufgespielt. Bestehende Client-PCs der Anwender werden genutzt. Der IT-Support wird für die neue Anwendung ausgeweitet. Die bestehenden Systeme und Strukturen verursachen laufende Kosten (IT-Bereich als engl. Cost Center), die durch Controlling-Methoden auf alle bestehenden und eben auch die neue Anwendung aufgeschlüsselt (IT-Bereich als engl. Profit Center) werden. Mit den zugreifenden Fachbereichen wird (im Sinne einer Dienstleistungsorientierung) aufwandsbezogen abgerechnet. Bei den Zahlen in den folgenden Tabellen handelt es sich nur um Rechenbeispiele auf ersten groben Schätzwerten. Client IT-Infrastruktur Kriterien Für einen Client Zeitraum Kosten Leasingrate Client-PC pro Jahr 400 EUR Kosten Client Basis SW pro Jahr 500 EUR Client IT-Support pro Jahr 600 EUR Summe pro Jahr EUR Tab. 5.6: Jährliche Kosten der IT-Infrastruktur für einen Client-PC Betrachtet werden in [Tab. 5.6] die grob geschätzten Kosten der IT-Infrastruktur für einen (den ersten) Client-PC. Solche Kosten entstehen auch für jeden weiteren Client-PC. Die Kosten der IT-Infrastruktur und für das WPIM-System [Tab. 5.7] entstehen hingegen einmalig für das System und nicht je Client-PC. Die Kosten sind grob geschätzt und geben nur einen ersten Richtwert vor. IT-Infrastruktur Kriterien Für den Server Zeitraum Kosten Anteilige Serverkosten einmalig EUR Wartungskosten Server pro Jahr EUR Summe Im ersten Jahr EUR Tab. 5.7: Geschätzte Kosten der IT-Infrastruktur für einen WPIM-Server Waren die unternehmenseigenen IT-Bereiche historisch vielfach als eigenständige Kostenstellen (sog. Cost Center) organisiert, vollzieht sich gegenwärtig ein Wandel zu serviceorientierten Profit Centern mit klarem Ertragsziel in einigen Fällen in direkter Konkurrenz zum Markt. [MeZK03] Intelligence. 269

294 Evaluation der WPIM-Anwendung IT Infrastruktur Kriterien Kosten für 3 Clients Zeitraum Kosten 1. Client-PC pro Jahr EUR 2. Client-PC pro Jahr EUR 3. Client-PC pro Jahr EUR Serverkosten einmalig EUR Wartungskosten Server pro Jahr EUR Summe im ersten Jahr EUR Tab. 5.8: Kostenschätzung der IT-Infrastruktur für das WPIM-System Die Kostenschätzung in [Tab. 5.8] erfolgt grob und exemplarisch für eine IT-Infrastruktur bestehend aus einem Server und drei WPIM-Arbeitsplätzen. Durch den Einbezug und die Befragung von Stakeholdern [Frie06, S. 35 in RoDo07] sowie durch die Berücksichtigung der Interessen und Erwartungen der Anspruchsgruppen [MeZK03, S. 446] können die Schätzungen weiter konkretisiert und Erfahrungswerte ermittelt werden. Herausfordernd gestaltet sich die empirische Ermittlung von Produktivitätssteigerungen sowie die Messung der Prozessverbesserung zum Nachweis von Einsparungen [vgl. Tab. 5.9]. Kategorien Jahr 0 Jahr 1 Jahr 2 Jahr 3 Jahr 4 mit Bewertung in EUR Kosten Lizenzkosten Kauf SW einmalig 600 Entwicklungsaufwand WPIM Serverkosten Trainingskosten Clients Leasingrate inkl. Wartung Wartungskosten Server Summe Kosten Einsparungen Produktivitätsseigerung Prozessverbesserung Summe Einsparungen Überschuss Formel mit Zinssatz (i=0,1) 10 % *(1+i) -1 *(1+i) -2 *(1+i) -3 *(1+i) -4 Errechneter Abzinsfaktor 1,1 1,21 1,331 1,4641 Barwerte (abgezinst) Kumulierter Nutzen Payback Investition (n) = 0, , , ,25042 Nutzen (n)/ einmalige Kosten Payback Investition in % 25 % 56 % 90 % 125 % Nettobarwert d. Einsparungen Einmalige Investitionskosten Kapitalwert der Investition ROI=Totalerfolg/Investitionskosten 25 % Tab. 5.9: Investitionsrechnung zur WPIM-Anwendung, orientiert an [Oehl08, S. 18] Nochmals möchten wir betonen, dass die vorliegende Betrachtung von Kosten und Zahlungsströmen nur auf ersten groben Schätzungen basiert. In Anlehnung an [StSo05] lautet die zentrale Frage bei der ROI-Betrachtung: 270

295 Evaluation der WPIM-Anwendung Wie viel Prozent meiner ursprünglich in das WPIM-System investierten Summe, habe ich nach einer gegebenen Periode von 4 Jahren als zusätzliche Rückzahlung zu erwarten? Folgenden Annahmen werden getroffen, um die Kalkulation des ROI zu ermöglichen: Der interne Zinsfuß 311 beläuft sich auf exemplarische 10 %. Die Laufzeit der Investitionsrechnung auf 4 Jahre. In diesem Rechenbeispiel [vgl. Tab. 5.9] beträgt der positive Kapitalwert EUR und der ROI von etwa 25 % zeigt den erzielbaren Vorteil der Investition auf. Das Zahlenwerk (auf Basis grob überschlagener Kosten) kann sowohl in monetären Größen aber auch als Verhältnis von Kosten und Überschuss interpretiert werden. Da hier ein positiver Kapitalwert erzielt wird, erübrigen sich die Anwendung der von Oehler vorgeschlagenen Optionswertermittlung und der Realoptionsansatz [Oehl08]. Weiterhin referenziert Oehler die Studie [IDE02] mit Schwankungen bezüglich des Erfolgs bei der Einführung von BI-Implementierungen: Der Return-On-Investment schwankt von 17 bis über Prozent [IDE02 und IDE02 in Oehl08]. In der Automobilindustrie bspw., sollte der zu erwartender ROI bei über 21 % liegen. Dies stellt häufig den mindest ROI für positive Investitionsentscheidungen dar. Bei ROI-Schätzungen werden Projekte mit geringerem zu erwartenden ROI nicht gestartet. Ein branchenüblicher ROI sollte ex-post bei 6-7 % liegen, um ein zufriedenstellendes finanzielles Ergebnis zu erzielen. Erfahrungswerte zeigen, dass durch nicht vorhersehbare Risiken der ROI um bis zu 2/3 negativ beeinflusst werden kann. Somit dienen in der Automobilindustrie 14 % Punkte des ROI als Puffer für Fehleinschätzungen oder Verzögerungen bei großen Investitionsprojekten. Von klassischen finanzmathematischen Verfahren [vgl. RoDo07; Oehl08] nehmen wir an dieser Stelle Abstand. Dazu zählt auch die Berechnung des ROI für WPIM. Bei diesen Verfahren werden u. a. zukünftige Zahlungsströme betrachtet [vgl. RoDo07, S. 7]. Aufgrund der Tatsache, dass sich der WPIM-Prototyp am Anfang der Entwicklung befindet, also noch nicht am Markt ist, können zukünftige Kosten und der Nutzen derzeit nur sehr grob geschätzt und bezüglich ihrer Strukturen nur reflektiert und diskutiert werden. Daten und Zahlungsströme zu vergleichbaren Implementierungen konnten in der Literatur nicht identifiziert werden. Auch [RoDo07] distanzieren sich von der Erreichung reiner finanzieller Kennzahlen für IT-Systeme, wie z. B. dem Return-on-Investment oder der Cost-Income-Ratio und plädieren für eine stärkere gesamtheitliche Wertorientierung der Unternehmen [vgl. RoDo07]. Im Folgenden werden deshalb Methoden zur Bewertung von Zeiteinsparungen vorgestellt und mit der WPIM Datenkollektion in Bezug gebracht Methoden zur monetären Bewertung von Zeiteinsparungen Eine monetäre Bewertung von Informationssystemen wird mit den Bewertungsverfahren Times Saving Times Salary Model (TSTS-Model) und dem Hedonic Wage Model (HWM) angestrebt. Beide sind speziell auf die monetäre Bewertung von Zeiteinsparungen ausgerichtet und damit für die monetäre Bewertung der durch WPIM erzielten Zeiteinsparungen geeignet. Übersichten zur Einordnung wissenschaftlicher Methoden zur monetären Bewertung finden sich bei Pietsch [Piet03], bei Ebener [Eben03, S. 28] und bei Quaas [Quaa05], speziell mit Kriterien zur Bewertung zum Hedonic Wage Model. Die beiden Methoden TSTS-Model sowie HWM werden im Folgenden vorgestellt und auf die Datenkollektion von Philips PCLAT angewendet. 311 Der Zinsfuß entspricht den Zinsen der Anlage bei einer Bank und wird häufig als indirektes Maß für das Projektrisiko interpretiert. Üblich sind Zinssätze zwischen 3 % und 25 %. 271

296 Evaluation der WPIM-Anwendung Times Saving Times Salary Bei Ebener [Eben03] wird aus der Primärliteratur [Boczany 1983; Sassone 1987 in Eben03] deutlich: Das Times Saving Times Salary Model ist eine in den USA entwickelte Methode, bei der davon ausgegangen wird, dass durch den Einsatz eines Informationssystems die Arbeitszeit in einer Organisation messbar verkürzt wird [vgl. Boczany 1983 in Eben03]. Die bewertete Zeitersparnis wird dabei als der Wert eines Informationssystems angesehen. Werden durch den Einsatz eines Informationssystems beispielsweise 10 % Arbeitszeit in einer Organisation eingespart, so entspricht der jährliche monetäre Wert des Informationssystems 10 % der durch die Mitarbeiter jährlich entstehenden Kosten [Sassone 1987 in Eben03]: Wert = [ eingesparte Zeit / Arbeitszeit ] * Gehalt Die Formel nach [Sassone 1987 in Eben03] wird in [Eben03] vorgestellt. Durch den Vergleich von Personalkosten, die vor und nach Einführung eines Informationssystems, z. B. der WPIM- Anwendung, aufzubringen sind, kann die Wirtschaftlichkeit eines Informationssystems einfach, schnell und nachvollziehbar berechnet werden. Damit die Methode in der Praxis aussagekräftige Ergebnisse liefert, müssen die beiden folgenden Bedingungen zutreffen: Eine Zeitersparnis muss in der Organisation tatsächlich eintreten und gemessen werden können, der ermittelte monetäre Wert muss sich tatsächlich realisieren lassen. Dazu müssen durch Rationalisierung Personalkosten in entsprechender Höhe gesenkt oder die Produktivität in der Organisation gesteigert werden. Es besteht also die Gefahr, dass der ermittelte monetäre Wert zu ungenau ist oder nicht realisiert werden kann und deshalb lediglich als latent vorhandenes Potential in der Organisation verbleibt. [Steidler 1994 und Pietsch 2003 in Eben03]. Bei dem Streben nach einer reinen Messung von Zeiteinsparungen ist die tatsächliche Realisierbarkeit der Zeiteinsparungen, z. B. durch Rationalisierungen, nicht immer angestrebt. Es folgt daher eine Betrachtung der Arbeitswertmethode Arbeitswertmethode Hedonic Wage Model Bei [Piet03] werden die wichtigsten in der Betriebswirtschaftslehre anerkannten Verfahren zur Bewertung der Auswirkungen, bei der Einführung von Informations- und Kommunikationssystemen untersucht und eingeteilt. Das Hedonic Wage Model wird dabei den prozessorientierten Bewertungsmethoden zugesprochen. Bei der Anwendung des Hedonic Wage Models [Sassone 1984 in Piet03] auch als Arbeitswertmodell bekannt [vgl. Piet03] wird der monetäre Wert der eingesparten Zeit in Abhängigkeit von ihrer Verwendung ermittelt. Berücksichtigt wird, dass sich das Gesamttätigkeitsspektrum einer beschäftigten Person im Unternehmen meist aus mehreren Aufgaben zusammensetzt. Das Spektrum von Experten kann beispielsweise aus deren Haupttätigkeit und zusätzlich aus höherwertigen Führungstätigkeiten, Tätigkeiten aus dem Bereich der Sachbearbeitung und Unterstützung sowie aus Anteilen unproduktiver Tätigkeiten 312 bestehen [siehe Tab. 5.11] vgl. [Piet03; Quaa05]. Zur Ermittlung der Anteile einzelner Tätigkeiten kann als Analysemethode, z. B. die sog. Tätigkeitsprofil- Analyse (engl. work profile analysis), angewendet werden, deren Ergebnis eine Tätigkeitsprofil- Matrix ist [Eben03]. Da Philips PCLAT Partner-Unternehmen im SHAMAN-Projekt ist [vgl. Kap ] und auch für diese Arbeit als Evaluationspartner zur Verfügung steht [vgl. Kap ], wird neben dem Ideation Prozess eine Vielzahl weiterer Dokumente und Ressourcen aus 312 Die Tätigkeiten stehen in Einklang mit allgemeinen Beschreibungen zu den Aufgaben einzelner Mitarbeiter im 272 Rahmen der Aufbauorganisation.

297 Evaluation der WPIM-Anwendung dem Kontext der Innovationen bereitgestellt. Dazu gehören auch die bei Philips PCLAT im Einsatz befindlichen Tätigkeitsprofile bei Innovationen. Folgende Rollen, auch als Profile, Mitarbeiterprofile oder Tätigkeitsprofile betitelt [vgl. Tab. 5.10] werden bei Philips PCLAT verwendet. Mitarbeiterprofile bei PCLAT Philips Consumer Lifestyle Advanced Technology BG-TV Programm Manager CM Manager IP Manager Account Manager Project Manager Project Officer Idea author / Idea owner / Inventor Systems Architect Systems Designer Software Engineer Beschreibung At AT-E the same person that is BG-TV program manager is also account manager. The skill set of the BG-TV program manager is: Pre-Development Processes, Product Development, Innovation Improvement. The Consumer Market Manager is part of the ideation board and does apart from this also help the action holders to explore commercial interest in the ideas. There is one CMM manager for every topic/triangle. AT-E has an IP manager acting as contact person for IP&S in the department. One of his assignments is to help AT-E employees during the disclosing and filing procedures of ideas and to act as support for AT-E during IP process. Skills in Optics, Patents, Intellectual property, KnowHow Generation During the execution of the project major changes have to be agreed by the customer via the account manager. Management of the Project with overview activities: 1. Open Project: obtain a project number and add the project to the resource database. 2. Assign resources: process the (changes to the) allocation of resources in the proper databases. 3. Monitoring: for every project keep track of the planned budget versus the actual budget, the deadlines of deliverables, the tasks achieved, and the status of risks. 4. Close Project: upon closure of a project the archive will be finalized (make sure all necessary documents are stored), the project number will be closed, and the lessons learned (from the evaluation form) will be documented. A project officer assists the project managers with their administrative tasks. The idea author does usually also becomes action holder, which is why they would have the same skill sets. The most important thing is that the action holder has a lot of knowledge within the domain that the idea revolves around. This means that the action holder does not necessarily have to be a project manager. Responsible for Systems Architecture with skills in: Digital TV Systems, Conditional Access Systems, DVD Video Recording, DVD Playback, BlueRay Recording, DVD+RW, Optical Recording Video Compression and MPEG Design of Systems with skills in IEEE802.11, MIMO techniques, Radio Propagation Characterization, UWB, Smart Antennas / Antenna Beam-forming, Risk analysis Development of Software with skills in Embedded CE technologies, Softwaretesting, Development of TV systems, SW System architecting, SW Testing, JPEG decoding, Intellectual Property protection Tab. 5.10: Mitarbeiterprofile bei Philips PCLAT Auf diese Tätigkeitsprofile von Philips PCLAT wird die Arbeitswertmethode angewendet. Dazu werden [in Tab. 5.11] auf der horizontalen Achse die jeweiligen Tätigkeiten (T) T1 bis T5 273

298 Evaluation der WPIM-Anwendung inklusive der unproduktiven Tätigkeiten T6 und auf der vertikalen Achse [in Tab. 5.11] (fünf ausgewählte) Mitarbeiterklassen (MK) aufgeführt. In den einzelnen Zeilen sind die Anteile der Tätigkeit an der Gesamtarbeitszeit der entsprechenden Mitarbeiterklasse eingetragen. In [Tab. 5.11] sind dazu zeilenweise die spezifischen Tätigkeitsprofile dargestellt [vgl. Quaa05]. Das Hedonic Wage Model wird in [Tab. 5.11] auf die Mitarbeiter 313 im Innovationsbereich beim Evaluationspartner Philips PCLAT 314 angewendet. Diese Betrachtung ist nicht abschließend, d. h. es gibt bei PCLAT durchaus weitere Mitarbeiterklassen (auch sog. Rollen) ebenso wie weitere Tätigkeiten. Anzumerken ist, dass die realen prozentualen Verteilungen der Tätigkeiten sowie die realen Zuordnungen der Tätigkeiten zu den Mitarbeitern bei Philips PCLAT nicht bekannt sind und auf Schätzungen beruhen. Um die Vorgehensweise zu verdeutlichen, ist in [Tab. 5.11] für Philips PCLAT eine exemplarische Tätigkeitsprofil-Matrix für einige aus [Tab. 5.10] ausgewählte Profile dargestellt: Tätigkeitsprofil-Matrix für Philips PCLAT T1 Führungstätigkeit T2 Kreative Ideenfindung T3 Entwicklungstätigkeit T4 Dokumenten u. Expertensuche T5 Servicetätigkeit T6 Unproduktive Tätigkeiten Summe Project Manager 70 % 5 % 5 % 10 % 5 % 5 % 100 % IP Manager 10 % 5 % 0 % 50 % 25 % 10 % 100 % Systems Architect / Designer 10 % 10 % 30 % 30 % 10 % 10 % 100 % Software Engineer 0 % 10 % 40 % 30 % 10 % 10 % 100 % Project Officer 0 % 5 % 0 % 30 % 50 % 15 % 100 % Tab. 5.11: Exemplarische Tätigkeitsprofil-Matrix bei Philips PCLAT Anzumerken ist, dass von jedem Mitarbeiter bei PCLAT innovative Beiträge erwartet werden: As mentioned, everybody at Advanced Technology Eindhoven (AT-E) has to produce a certain number of ideas every year. This complicates the description of skill sets since they can vary a lot depending on area of expertise and work role. [Philips PCLAT AT-E] Der Nutzen der WPIM-Methoden sowie der WPIM-Anwendung muss darin liegen, den Suchaufwand nach Prozesswissen zu reduzieren. Dieser Nutzen ist aufgrund der komplexen und kombinierten Suchanfragen schwer messbar. Es gibt unterschiedliche Schätzungen zum prozentualen Zeitaufwand (in Relation zur Arbeitszeit) bei der Suche nach Ressourcen. Werte zwischen 10 % und 30 % werden häufig angesetzt und sind auch in [Tab. 5.11] schätzungsweise herangezogen. Nur für den IP Manager wird ein deutlich höherer Zeitaufwand für die Suche nach bestehenden Patenten und Dokumenten (T4 mit 50 %) weiterhin aufgrund seiner Servicetätigkeit/Zuarbeit an AT-E, beschrieben in [Tab. 5.10], ein Wert von 35 % für T5 angesetzt. Dieser Zeitaufwand kann monetär proportional zur Vergütung des jeweiligen Mitarbeiters bzw. der hinterlegten Rolle angesetzt werden. [Piet03] 313 Mitarbeiter: Explizit sind Mitarbeiterprofile gemeint. Im Umfeld WPIM und bei Philips PCLAT sprechen wir von Mitarbeiterfunktionen in der Aufbauorganisation und von Rollen in der Projektorganisation. 314 PCLAT: Philips Consumer Lifestyle Advanced Technology. 274

299 Evaluation der WPIM-Anwendung Conclusio Die umfassende Bewertung von Informations- und Kommunikationssystemen gilt bis heute als nicht gelöstes Problem. [Piet03]. Bei der Betrachtung von Nutzen und Kosten existiert das grundsätzliche Problem der Investitionsentscheidung. Entweder müssen Kosten und Nutzen für einen zukünftigen Zeitraum geschätzt werden und sind deshalb mit Planungsunsicherheiten, Fehleinschätzungen und Risiken behaftet oder die Betrachtung erfolgt ex-post. Nur bei einer nachträglichen Betrachtung können Nutzen und Kosten überhaupt erfasst und quantifiziert werden. Somit stehen diese Daten noch nicht zum Zeitpunkt der Entscheidung zur Verfügung. Für die Ermittlung von Nutzen und Wert von Informationssystemen ist weitere Forschungsarbeit nötig. Ein weiteres grundsätzliches Problem besteht darin, dass der Wert von Information und Wissen nur schwer erfassbar ist. Selbst Patente ermöglichen nur bedingt eine Wertermittlung. Wie soll der Nutzen/Wert eines Systems erfasst werden das Information bereitstellt, wenn schon der Nutzen/Wert der Information nicht erfassbar ist? [KaNo01; KaNo04] Diese Frage beschäftigt u. a. das Forschungsfeld der Balanced Scorecard [KaNo01; KaNo04] sowie auch Steuerberater und Wirtschaftsprüfer, die sich mit der Bewertung von IP-Rechten, Patenten und immateriellen Vermögensgegenständen auseinandersetzen. Nutzen und Wert von Information und Informationssystemen sind demnach schwer zu erfassen. Daher möchten wir im folgenden Abschnitt eine Einordnung von WPIM in bestehende generische Rahmenwerke vornehmen. Anhand der Einordnung kann die Kompatibilität von WPIM zu eben diesen Rahmenwerken nachgewiesen werden. Zudem wird die WPIM-Anwendung als Informationssystem klassifiziert und dementsprechend kann grundlegend der Nutzen von WPIM in Analogie zum Nutzen von Informationssystemen argumentiert werden. 5.3 Übergeordnete generische Rahmenwerke WPIM wird im Folgenden in Rahmenwerke (engl. framework) fertigender Industrien eingeordnet. Die untersuchten Rahmenwerke sind in fertigenden Industrien etabliert und bieten Unterstützung bei Innovationen, Innovationsprozessen und in Produkt-Entstehungs-Prozessen (PEP). Durch Prüfung der WPIM-Methoden auf Konformität und Nutzen in den Rahmenwerken kann der Mehrwert des WPIM-Ansatzes veranschaulicht werden. Durch die Einordung der WPIM-Methoden in existente Rahmenwerke der Industrie und insbesondere der Automobil- und der fertigenden Industrie wird die Kompatibilität und Adaptionsfähigkeit von WPIM an die vorherrschenden generischen Rahmenwerken aufgezeigt. Im weiteren Verlauf der Arbeit werden die entsprechenden Standards und Rahmenwerke vorgestellt CMMI, ISO/IEC, SPICE für Unternehmensprozesse Das Capability Maturity Model Integration (CMMI) ist ein Prozessmodell. Im Gegensatz zu einer konkreten Prozessbeschreibung definiert CMMI Anforderungen an eine gute Produktentwicklung (das Was ), aber keine konkreten Schritte (das Wie ). Das primäre Ziel von CMMI ist es, eine kontinuierliche Prozessverbesserung zu unterstützen, indem Anforderungen bzw. Kriterien einer professionellen Produktentwicklungsorganisation definiert werden. Das Modell ist auf ein optimales Verfahren der Industrie [CMMI07] bezogen. CMMI geht die Messung und Verbesserung innerhalb eines Prozessgebiets durch sog. Fähigkeitsgrade (engl. capability levels) an. Ein Fähigkeitsgrad bezeichnet den Grad der Institutionalisierung eines einzelnen Prozessgebiets. [CMMI07; Bürg07, S. 47] Im Rahmen der Einführung eines Qualitäts Management Systems (QMS) nach DIN EN ISO:9001 Stand 9001:2008 werden direkte Parallelen zur Prozessorientierung erkannt. Die Prozessorientierung gilt als einer der sieben Grundsätze im Qualitätsmanagement (QM) nach 275

300 Evaluation der WPIM-Anwendung ISO. Jedes nach ISO:9001 zertifizierte Unternehmen muss somit alle qualitätsrelevanten Prozesse (darunter fallen insbesondere Entwicklungsprozesse und Produkt-Entstehungs- Prozesse) in einer Prozesslandschaft darstellen sowie die einzelnen Prozesse abbilden bzw. modellieren. Vorgaben hinsichtlich Modellierungssprachen werden nicht getroffen. ISO/IEC stellt einen Rahmen für Prozesse im Lebenszyklus von Software (Software Life- Cycle Processes) dar. Dieser beschreibt auf hoher Ebene alle wichtigen Prozesse des Lebenszyklus, von der Ideenfindung bis zur Stilllegung und deren Beziehungen untereinander. Prozesse bestehen aus Aktivitäten und diese wiederum aus einzelnen Aufgaben. Ein bestimmtes Lebenszyklusmodell oder eine bestimmte Entwicklungsmethode wird nicht festgelegt [www.iso.org]. Der internationale Standard IEC dient der Schaffung von elektrischen, elektronischen und programmierbar elektronischen (E/E/PE) Systemen, die eine Sicherheitsfunktion ausführen. Der Standard wird von der International Electrotechnical Commission (IEC) herausgegeben und betrachtet die Gesamtheit der Phasen des Lebenszyklus von sicherheitskritischen Systemen [www.iec.ch]. Software Process Improvement and Capability Determination (SPICE) oder ISO/IEC ist ein internationaler Standard zur Durchführung von Bewertungen von Unternehmensprozessen mit Schwerpunkt auf der Softwareentwicklung. CMMI tritt somit in Konkurrenz zu SPICE. [Wlok05] SPICE ist als internationaler Standard weiter gefasst und formuliert Anforderungen an Prozessreferenzmodelle (PRM). Konkrete und verbindliche Prozesse werden weder bei SPICE noch bei CMMI definiert. Automotive SPICE ist eine domänenspezifische Variante des internationalen Standards ISO/IEC (SPICE). Der Zweck von Automotive SPICE 315 besteht in der Bewertung der Leistungsfähigkeit von Entwicklungsprozessen, z. B. seitens der Steuergerätelieferanten in der Automobilindustrie [vgl. SPIC07]. Automotive SPICE wird durch die SPICE User Group und die AUTOSIG (engl. Automotive Special Interest Group) entwickelt und gepflegt [www.iec.ch]. STEP (STandard for the Exchange of Product Model Data) ist ein Standard zur Beschreibung von Produktdaten. Kern bei STEP (ISO 10303) und ProSTEP ivip bildet die ganzheitliche organisationen- und domänenübergreifende Betrachtung von Daten, Prozessen und Systemen. [PROS07] OSEK und AUTOSAR bei Kooperationen der Automobilindustrie Bei OSEK (Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug) mit OSEK-OS als Operating System, handelt es sich um die Spezifikation eines echtzeitfähigen Betriebssystems für eingebettete Systeme. Diese Spezifikation ist ausgerichtet auf die Serienfertigung von Steuergeräten. Mit Implementation Language (OSEK-OIL) werden Betriebssystemobjekte angelegt und beschrieben, wie z. B. Aufgaben, Interrupts, und Ressourcen. Mit OIL können Betriebssystemdienste normiert beschrieben werden. Damit wird der Wechsel zwischen verschiedenen OSEK-konformen Betriebssystemen erleichtert [vgl. OSE07]. OSEK und OSEK/VDX 316 wurde in die ISO-Norm überführt. Die Arbeiten der OSEK Gremien finden ihre Fortsetzung im AUTOSAR-Projekt. Basierend auf dem Konzept AUTomotive Open System ARchitecture 317 (AUTOSAR) für den Fahrzeugsektor werden gezielt

301 Evaluation der WPIM-Anwendung kooperative Entwicklungen durchgeführt, die in ihrer Funktionalität kostenabhängig für den Original Equipment Manufacturer (OEM) parametriert werden. Im Bereich der kooperativen Entwicklungen gibt es eine Vielzahl an Konsortien, vermehrt bei On-Board-Bussystemen, wie z. B. Byteflight, FlexRay, LIN, MOST, JASPAR oder das DC-BUS-Konsortium STEP und ProSTEP ivip Die Vereinigung Standard for Exchange of Product Modeldata (ProSTEP) zur integrierten virtuellen Produktentstehung (ivip) stellt seinen gebührenpflichtigen Mitgliedern (Anwendern, IT-Herstellern und Forschungseinrichtungen) eine Informations- und Kommunikationsplattform zur Produktentwicklung zur Verfügung. Dabei steht das reibungslose Zusammenspiel (in einer wettbewerbsfreien Zone) von Produktdaten, Systemen und Prozessen im Vordergrund. Ursprünglich lag der Fokus des Zusammenschlusses auf dem Austausch von CAD-Daten, aus dieser Zeit stammt der ISO Standard auch als STEP bekannt. STEP und ProStep ivip verfolgen die drei klassischen Ziele der Produktentwicklung: Verbesserung der Qualität, Reduktion der Kosten und Verkürzung der Entwicklungszeiten. Zentrales Organ des Vereins ist eine gemeinsame Datenbasis, auf die alle Mitarbeiter der beteiligten Organisationen zugreifen können. Auf dieser Datenbasis sollen die Prozesse der virtuellen Produktentwicklung beschleunigt werden. Der Ablauf der ProStep ivip Methode lässt sich wie folgt beschreiben: 1. Spezifikation: Verschiedene Workshops werden durch den Verein auf Initiative einzelner Mitglieder initiiert. Stößt die Thematik bei anderen Mitgliedern auf Interesse, kann sie in Form eines Projekts mit fester Laufzeit und festem Ziel fortgeführt werden. 2. Harmonisierung: Auf Basis erster Ergebnisse wird eine Harmonisierung mit anderen Projekten herbeigeführt. Das Hauptaugenmerk liegt hierbei auf evtl. Ähnlichkeiten zwischen verschiedenen Projekten. Ziel ist es, vorangegangene Lösungen auf das aktuelle Projekt anzuwenden. Ist die Diskussion des Problems abgeschlossen, legt der Verein eine Empfehlung (engl. Recommendation) zur optimalen Anwendung der Ergebnisse vor. Diese bildet die Grundlage für die folgende Pilotphase, in der die erarbeiteten Ergebnisse einem ersten Praxistest unterzogen werden. Die Umsetzung in marktfähige Produkte wird von sog. Implementorforen unterstützt, die sich auf die aus der Pilotphase abgeleiteten Best-Practices beziehen. 3. Integration: Die letzte Phase stellt die Integration der erzielten Ergebnisse in kommerzielle Produkte dar. Die Qualität wird durch Standardisierung sichergestellt. Die von den Mitgliedern erarbeiteten Lösungen sind prozessorientiert und anwendungsgetrieben. Diese Grundlage garantiert Lösungen im Interesse der beteiligten Industrien, wie z. B. der Automobil-, der Luft- und Raumfahrt, von Systemanbietern und Forschungsinstituten. Als Leitthemen werden: Prozessmanagement, Systemintegration, Standardisierung, Engineering Collaboration und Knowledge Transfer verfolgt. Die Projektgruppen beschäftigen sich mit Product Lifecycle Management (PLM), Collaborative Project Management (CPM), Requirements Management und Secure Product Creation Processes. Die verfolgten Ziele von STEP und ProStep ivip sowie deren Ausrichtung auf Innovationsprozesse ist vollständig vereinbar mit WPIM und der prozessorientierten Sichtweise. Die STEP-Leitthemen wie Standardisierung, Collaboration und Knowledge Transfer sind zudem fester Bestandteil in den

302 Evaluation der WPIM-Anwendung Innovationsprozessen bei WPIM Wasserfallmodell Der modellierte Innovationsprozess ist an der Vorgehensweise des Wasserfallmodells orientiert. Nach Abnahmen einzelner Phasen ist ein Rückschritt in eine vorgelagerte Phase nur mit großem Aufwand und hohen Kosten möglich. Abb. 5.13: Innovationsprozess als Wasserfallmodell mit Phasen modelliert in BPVA Die Phasen werden in der Automobilindustrie als Integrationsstufen (I-Stufen) bezeichnet. Integrationsstufen werden rückwärtsterminiert und finden somit ihren zeitlichen Abschluss im Fertigungsstart (engl. Start-of-Production, SOP). Innerhalb der Phasen werden bereits erste Tests und Integrationstests vorgenommen, wobei eine iterative Vorgehensweise zu einer Reifung der Vor- und Zwischenprodukte beiträgt. Durchaus ist es in der Automobilindustrie üblich, einzelne Entwicklungsschritte oder gesamte Phasen an Zulieferer auszulagern oder Bedarfsspitzen über Fremdfirmen und Zulieferer abzufangen. Aus Wissenssicht stellt dies eine Verschiebung der Kompetenzen sowie eine Verlagerung des Know-hows dar. Das Wasserfallmodell schränkt die grundlegende Modellierung von Prozessen dahingehend ein, dass ein stringent vorwärtsorientierter Ablauf entsteht. Da die grundlegende Modellierung von Prozessen kompatibel zur Prozessmodellierung bei WPIM ist, sind auch eingeschränkte Umfänge der Prozessmodellierung wie hier am Beispiel des Wasserfallmodells gezeigt kompatibel zu WPIM V-Modell Das V-Modell und das V-Modell XT 319 wird bei Produkt-Entstehungs-Prozessen (PEP) und Innovationsprozessen, z. B. in der Automobilindustrie, eingesetzt. Das wesentliche Prinzip ist seine ziel- und ergebnisorientierte Vorgehensweise. Diese Grundphilosophie ist an vielen Stellen im V-Modell sichtbar. Die Produkte stehen im Mittelpunkt des V-Modells und die Produkte sind die zentralen Ergebnisse. Eine grundlegende Einführung in das V-Modell gibt die zugehörige Dokumentation V-Modell XT: Das Werk und Teile daraus können unter Hinweis auf den Urhebervermerk: Das V-Modell XT ist urheberrechtlich geschützt durch die Bundesrepublik Deutschland. Alle Rechte sind vorbehalten. Weitere Information und Lizenzvereinbarungen V-Modell Dokumentation unter

303 Evaluation der WPIM-Anwendung Struktur und Zielsetzungen im V-Modell: Das V-Modell ist als Leitfaden zum Planen und Durchführen von Entwicklungsprojekten unter Berücksichtigung des gesamten Systemlebenszyklus konzipiert. Im V-Modell wird detailliert geregelt, Wer, Wann, Was in einem Projekt zu leisten hat. Somit dient das V-Modell als Vertragsgrundlage, Arbeitsanleitung und Kommunikationsbasis in vielen Unternehmen der Automobil- und Zulieferindustrie. [Vers99; VuGl03]. Zudem gibt es strategische Aktivitäten bei der Durchführung von Innovationsprojekten. Eine Strategie wird benötigt, um das Wann, also die Reihenfolge der zu erstellenden Produkte bzw. durchzuführenden Aktivitäten, festzulegen. Abb. 5.14: Das V-Modell zur Innovationsdurchführung [V-Modell Dokumentation] Ein Vorgehensbaustein gibt vor, Was in einem konkreten Projekt zu tun ist, also welche Produkte zu erstellen und welche Aktivitäten durchzuführen sind. Darüber hinaus legt der Vorgehensbaustein fest, Wer für welches Produkt verantwortlich ist. Im V-Modell sind zudem Schnittstellen für die Zusammenarbeit von Entwicklungspartnern vorgesehen. Einsatz des V-Modells in der Automobilentwicklung: Vorgehensmodell zur Integration informationstechnisch geprägter Komponenten im Fahrzeug werden in der Automobilindustrie bereits seit einigen Jahren eingesetzt [vgl. VuGl03; Vers99]. Hieraus erwachsen immer wieder neue Erkenntnisse insbesondere im Bereich der verteilten Entwicklung vernetzter Steuergeräte, den automotiven Anforderungen an Beschreibungsmittel, dem Einsatz von Werkzeugketten zur Unterstützung von Entwicklungsprozessen und auch zu den Entwicklungsprozessen selbst. [VuGl03, S. 3] Das Anforderungsmanagement ist, z. B. bei der BMW Group, nach dem V-Modell in den Fahrzeug-Entwicklungsprozess eingebettet, mit Schnittstellen nach oben hin zu allgemeinen, strategischen und technischen Zielen, sowie nach unten hin zur technischen Spezifikation und Design des Entwicklungsstandes. [vgl. Vers99] Einsatz des V-Modells bei Software-Innovationen: Hommel zeigt die Verwendung des V- Modells in der Automobilindustrie bei der Entwicklung von Steuerungssoftware für Controller auf [vgl. Homm06]. Das V-Modell findet bei der Softwareerstellung sowohl in der Phase Entwicklung (V-Modell linker Ast) als auch in der Phase Test (V-Modell rechter Ast) Einsatz [vgl. Abb. 5.15]. 279

304 Evaluation der WPIM-Anwendung Das Verwenden eines Vorgehensmodells kann das Testen erheblich vereinfachen und die Qualität der Software maßgeblich positiv beeinflussen. Das V-Modell löst das sog. Wasserfallmodell der Softwareerstellung welches ein reines Phasenmodell ist, ab, da dieses den Nachteil hat, dass das Testen der Software selbst in einer zu späten Phase erfolgt. [Homm06, S. 19] 280 Abb. 5.15: Allgemeines V-Modell bei der SW-Entwicklung [Homm06, S. 20] Hommel gibt in Parallelisierte Simulationsprozesse für virtuelles Prototyping in der Automobilindustrie einen Ausblick auf zukünftige Modelle in der Entwicklung: In Zukunft fließen die Entwicklungsphasen von Hard- und Software bei der Entwicklung mechatronischer Systeme immer mehr ineinander über, so dass der rein sequenzielle Prozess der Entwicklung mechatronischer Systeme abgelöst wird durch einen Prozess der virtuellen Entwicklungsmethodik. Dieser Prozess wird nach der englischen Bezeichnung Virtual Prototyping oder Frontloading genannt. [vgl. Homm06, S. 20] Tailoring bezeichnet die Anpassung des V-Modells an ein konkretes Innovationsprojekt, dies erfolgt im Normalfall durch das Hinzufügen von Vorgehensbausteinen. Tailoring ist aber nicht auf die Zunahmen der Komplexität und die Erweiterung des Modells ausgelegt. Vielmehr handelt es sich um eine Anpassung bzw. Adaption des Modells an die konkrete Innovation. Ein Tailoring kann durchaus auch eine Reduktion des Modells bewirken. Ziel ist es, ein maßgeschneidertes Modell zur (bzw. abgestimmt mit der zu bewältigenden) Innovation zu kreieren das V-Modell sowie das Tailoring wird von WPIM voll unterstützt. Durch die weite Verbreitung des V-Modells in fertigenden Industrien und insbesondere der Automobilindustrie erhoffen wir auch für WPIM eine hohe Akzeptanz Einordnung und Kompatibilität von WPIM Bei der Einführung der WPIM-Methoden in fertigenden Industrien sind die organisatorischen Rahmenwerke und technische Infrastrukturen, Normen, branchenübliche Modelle sowie die Empfehlungen standardisierender Gremien und Vereinigungen unbedingt zu berücksichtigen. Dies fördert die Akzeptanz. Bestehende Ansätze werden durch WPIM bewusst unterstützt und ergänzen diese. Diese Eingliederung kann zudem als empirische Überprüfung der Kompatibilität von WPIM zur gelebten Praxis verstanden werden. Erste Schnittstellen zu den bestehenden Modellen der Praktiker erlauben nach Fertigstellung des Systems eine Eingliederung ins produktive unternehmerische Umfeld der fertigenden Industrien. Sowohl das Wasserfallmodell als auch das V-Modell mit ihren wohldefinierten Phasen sind gut geeignet, um einen Muster- Prozess für Innovationen i. S. v. WPIM vorzuschlagen. Einzelne Phasen können in Unterprozesse und Aktivitäten zerlegt werden, die in WPIM volle Unterstützung finden. Geforderte standardisierte Vorgaben zur Prozessdokumentation wie bei CMMI oder SPICE sind

305 Evaluation der WPIM-Anwendung auf die in WPIM modellierten Prozesse und integrierte Ressourcen ebenfalls anwendbar. Die STEP- und ProStep ivip-leitthemen wie Standardisierung, Collaboration und Knowledge Transfer sind fester Bestandteil bei WPIM. Die gezeigten Ansätze ergänzen sich mit WPIM gegenseitig. WPIM kann in die aufgeführten Rahmenwerke eingeordnet werden und auch die Kompatibilität kann daran positiv belegt werden. Im weiteren Verlauf der Arbeit werden folgend konkrete Bewertungs- und Evaluationsmethoden zur Nutzenermittlung der WPIM-Anwendung vorgestellt und eingesetzt. 5.4 Bewertungs- und Evaluationsmethoden Aufbauend auf den Grundlagen zur Evaluation werden Methoden vorgestellt, die für die Evaluation von Innovationen und Innovationsprozessen entwickelt wurden und in der unternehmerischen Praxis zum Einsatz kommen. Die Methoden werden erprobt und ihre Anwendbarkeit auf WPIM überprüft. Insbesondere wird auf Bewertungsskalen und Leistungsindikatoren eingegangen. Darauf aufbauend wird auf Methoden zum Messen von Innovations(reife)graden und standardisierte Verfahren zur Messung der Innovationsfähigkeit, wie z. B. den InnoScore, eingegangen. Zudem werden Methoden vorgestellt, die Aussagen und Leistungsvergleiche über Unternehmensgrenzen hinweg (sog. benchmarking) ermöglichen. Die begründete Auswahl der Evaluationsmethode für WPIM rundet die Betrachtung ab Grundlagen Für die nun folgende Evaluation von WPIM, auf Basis realer Daten (sog. Datenkollektionen) sowie einem gedanklichen Experiment (sog. Simulation), werden vorab die benötigten Begriffe definiert. Definition 5.8: Evaluation Die Evaluation (auch Evaluierung) erfasst und wertet das Ergebnis einer Arbeit aus. Dabei wird überprüft, ob Interventionen die gewünschten Ergebnisse bzw. Wirkungen erzielen. Dies kann z. B. auf Basis von (objektiven) Leistungsindikatoren erfolgen. Definition 5.9: Hypothese Eine These stellt eine Behauptung dar. Ein Hypothese ist eine Aussage, deren Gültigkeit für möglich erachtet wird, welche aber noch erwiesen (verifiziert) werden muss. Die Überprüfung kann z. B. gegen tatsächlich beobachtete (sog. empirische) Ereignisse erfolgen. Definition 5.10: Verifikation Die Verifizierung einer Hypothese erbringt den Nachweis, dass diese Hypothese richtig ist. Kann dieser Nachweis nicht erbracht werden wird die Hypothese abgelehnt und somit falsifiziert. Diese Definitionen und Grundlagen werden im Folgenden zur Evaluation der WPIM-Methoden und der WPIM-Anwendung herangezogen. Dazu wird zusätzlich der Begriff des Leistungsindikators benötigt und eingeführt Leistungsindikatoren und Leistungskennzahlen Der Begriff Leistungskennzahl 321 (engl. Key Performance Indicator, KPI) bezeichnet in der 321 Leistungsindikator und Leistungskennzahl werden synonym verwendet. 281

306 Evaluation der WPIM-Anwendung Betriebswirtschaftslehre Kennzahlen, anhand derer der Fortschritt oder der Erfüllungsgrad hinsichtlich wichtiger Zielsetzungen oder kritischer Erfolgsfaktoren innerhalb einer Organisation gemessen und/oder ermittelt werden kann 322. Im klassischen Sinn kommt die Messung von Performance-Größen aus der Prozess- und Verfahrenstechnik. Hierbei wird z. B. die erzielte Auslastung der theoretisch-maximalen Auslastung gegenübergestellt. Leistungsindikatoren stehen in direktem Zusammenhang zur Unternehmensstrategie und werden zur operativen Steuerung von Organisationseinheiten und Prozessen genutzt. [Maut09, S. 5] Bei der Balanced Score Card (BSC) [vgl. Kap ] sind die strategischen Ziele in den vier Perspektiven der Score Card umgesetzt [Maut09, S. 7], beim InnoScore [vgl. Kap ] in den neun Gestaltungsfeldern [Wars06]. Definition 5.11: Leistungsindikatoren Leistungsindikatoren (engl. Key Performance Indicator, KPI) stehen im Zusammenhang mit der Qualifizierung und Quantifizierung von leistungskritischen Kennzahlen. [Maut09, S. 3] Weitere betriebswirtschaftliche KPIs und Controlling-Kennzahlen sind in deutscher und englischer Sprache definiert in [KrAr08]. Leistungsindikatoren sind Kennzahlen die zur Beurteilung der Leistung des betrachteten Objekts dienen. [Maut09, S. 4] Die zu beurteilenden Objekte sind in dieser Arbeit die WPIM-Methoden und die WPIM-Anwendung. Bei den Leistungsindikatoren handelt es sich entsprechend der verfolgten Ziele um Zeit-, Mengen- oder Wertgrößen. [Maut09, S. 4] KPIs messen die kritischen Erfolgsfaktoren (engl. Key Success Factor, KSF). Ein Erfolgsfaktor kann durch mehr als einen Leistungsindikator quantifiziert werden. ( ) KPI bestehen aus Kennzahlen oder sind eine Ansammlung oder Verknüpfung von Kennzahlen. [Maut09, S. 5] KSF bzw. bei [Wars06, S. 33] die neun Gestaltungsfelder sind den KPIs übergeordnet und korrelieren mit der strategische Zielsetzung des Unternehmens. Die Messung hierzu erfolgt über die Likert-Skala Basis Likert-Skala Die Likert-Skala 323 nach Rensis Likert ist ein Skalierungsverfahren zur Messung persönlicher Einstellungen, die mittels sog. Items, wie z. B. Leistungsindikatoren, abgefragt werden. Die Methode basiert auf dem Interesse an der Einstellung einer Versuchsperson zu einem bestimmten Sachverhalt. Entsprechende Bewertungskriterien werden dann als strikt positive oder strikt negative Aussagen formuliert [Like11]. Der Likert-Skala liegt der Gedanke zu Grunde, dass diese Versuchsperson eine Aussage zu einem Item umso mehr ablehnt, je weiter ihre Einstellung von der Formulierung des Items entfernt liegt. In Summe werden sodann die Antworten auf diesen Grad der Einstellung abgebildet. Man erhofft sich durch diese Vorgehensweise eine methodisch haltbare Messung der Einstellung. Eine Aussage und die auf der Antwortskala gewählte Zahl stellen somit einen Indikator für die Einstellung dar. Ziel ist es, eine konsistente und trennscharfe Finalskala beziehungsweise Itemmenge zu bilden, mit der ein möglichst valides (gültiges) Ergebnis zur untersuchten Fragestellung erzielt werden kann. [Like11] Es soll bewusst keine Bewertung in prozentualen Erreichungsgraden verwendet werden, um die subjektive Einschätzung nicht willkürlich werden zu lassen. Die mögliche Option, einen Wert von 0 bis 100 % zu wählen, könnte die Beurteilung der KPIs verzerren. Daher wird die Skala trifft zu gar nicht, eher wenig, eher ja oder voll mit folgender Codierung gewählt. 322 Vgl

307 Evaluation der WPIM-Anwendung Bewertung Codiert gar nicht 1 eher wenig 2 eher ja 3 voll 4 Tab. 5.12: Bewertung und Codierung nach der Likert-Skala Durch die Verwendung der Likert-Skala kann die Einstellung einer befragten Person zu einem Thema, hier zu WPIM und der Innovationsfähigkeit erfasst werden. Eine Likert-Skala stellt mehrere wertende Aussagen zur Auswahl bereit. Befragte Personen stimmen diesen Aussagen zu oder lehnen diese ab. Da in [Tab. 5.13] eine Likert-Skala mit vier Ausprägungen [nachpas1073] gewählt wird, müssen bewertende Personen entscheiden, ob positive oder negative Ausprägungen gewählt werden. Eine unentschlossene Auswahl, das sog. (engl. stuck-in-themiddle) Dilemma wird so verhindert. Die vorgegebenen Ausprägungen erzielen klare Ergebnisse bei der Auswahl. Für die Berechnung und die angestrebte Vergleichbarkeit sind bei Erhebungen stets alle Fragen zu beantworten. Exemplarisch werden beispielhaft drei Fragen vorgestellt: KPI Frage I 15 ) Wir können bei Innovationsprojekten diejenigen Mitarbeiter zu Projektteams zusammenführen, die über die benötigten Qualifikationen verfügen. I 23 ) I 31 ) In unserem Unternehmen herrscht ein besonders offener und transparenter Umgang mit den in Innovationsprojekten benötigten Informationen. Unsere Innovationsprojekte orientieren sich an einem dokumentierten Innovationsprozess, der alle Funktionsbereiche mit einbezieht. Messung gar nicht eher wenig eher ja trifft voll zu gar nicht eher wenig eher ja trifft voll zu gar nicht eher wenig eher ja trifft voll zu Tab. 5.13: Exemplarische Fragen zu KPI nach [PAS1073] In [Tab. 5.13] sind exemplarisch drei der 36 Fragen aufgelistet, die anhand der Likert-Skala mit den Ausprägungen gar nicht, eher wenig, eher ja oder voll einzuschätzen sind Innovationsbenchmark Die bestmögliche Gestaltung (engl. benchmarking) ist ein in der Praxis weit verbreiteter Ansatz zur Leistungsbewertung und zum Leistungsvergleich. Definition 5.12: Benchmarking Benchmarking ist eine allgemeine Methode zur Leistungsbewertung und Leistungssteigerung von Unternehmen mit dem Ziel, systematisch nach Wettbewerbsvorteilen zu streben. [Bala05] Das Verfahren Innovationsbenchmark generiert nach [KeEr08, S. 4] ein sehr detailliertes Entwicklungsstufenkonzept, bei dem selbst Zeit- und Kostenschätzungen integriert werden. Ferner bietet dieses Modell ein auf die Unternehmensziele speziell ausgerichtetes Handlungskonzept. Zunächst werden die Gestaltungsfaktoren des Innovationssystems (z. B. 283

308 Evaluation der WPIM-Anwendung Einsatz von Methoden zur Zukunftsvorausschau) definiert. Da die Gestaltungsfaktoren einander bedingen, werden sie nach der Analyse der gegenseitigen Beeinflussung (Einflussanalyse) priorisiert [GaFi99 in KeEr08]. Zunächst werden Oberziele formuliert und Gestaltungsfaktoren ausgewählt, die möglichst stark vernetzt sind und einen möglichst hohen Zielbeitrag in Aussicht stellen. Dann werden Entwicklungsstufen pro Gestaltungsfaktor definiert und die Kombination von Entwicklungsstufen mit der höchsten Zielwirkung ermittelt (Zielbeitragsanalyse). [KeEr08, S. 5] Diese Kombination ist die bestmögliche Gestaltung des Innovationsmanagements (sog. Benchmark) und stellt das Soll-Profil. Die Erhebung des realen Ist-Profils zum Innovationsmanagement erfolgt, z. B. anhand von Interviews und Workshops, entlang der ausgewählten Gestaltungsfaktoren. Zur Beschreitung des Wegs vom Ist- zum Soll-Profil, so Kespohl/Erett weiter, werden die Entwicklungsstufen auf Konsistenz überprüft. Außerdem wird der zeitliche und monetäre Aufwand zur Erreichung der nächsten höheren Entwicklungsstufe ermittelt. Es ergibt sich ein Aufwand-Nutzen-Portfolio mit verschiedenen Wegen als mögliche Handlungskonzepte für die Steigerung der Innovationskraft. [KeEr08] Bei der Umsetzung des Handlungskonzepts ist typischerweise die Unternehmensführung (engl. management) eingebunden. Dadurch wird sichergestellt, dass Rahmenbedingungen, wie z. B. die aktuelle Budgetsituation sowie die zeitliche Dringlichkeit des Erreichens bestimmter Entwicklungsstufen berücksichtigt bzw. eingehalten werden. Mit dem Erreichen und dem Zielerreichungsgrad angestrebter Größen beschäftig sich auch der Innovationsgrad Innovationsgrad und Innovationsreifegrad Der Innovationsgrad kann als bereits erreichte oder angestrebte Größe angesehen werden. Als erreichter Innovationsgrad ist er ein Ergebnis, im Sinne einer abhängigen Variablen, die durch das Innovationsmanagement beeinflusst wird. Ein angestrebter Innovationsgrad ist eine strategische Steuerungsgröße, die die Aktivitäten des Innovationsmanagements lenkt. [Haus04, S. 278] Der Innovationsgrad einer Produktinnovation ist das Ausmaß aller im Vergleich zum Status ante des sozio-technischen Systems des innovierenden Unternehmens beurteilten Veränderungen, das durch die Entwicklung und Einführung eines neuen Produktes entstehen soll bzw. entstanden ist, aus der Perspektive dieses Unternehmens. Der Status ante ist durch die vorhandenen Ressourcen des Unternehmens und die Erfahrungen und Fähigkeiten der Organisationsmitglieder gekennzeichnet. [Schl99, S. 36] Dieser Definition zufolge ist nicht nur die für den Konsumenten sichtbare Veränderung Gegenstand der Betrachtung, so [Bürg07, S. 22]. Aufbauend auf dem InnoScore-Modell und dem Innovationsbenchmark-Modell wurde das Innovationsreifegrad-Modell [vgl. KeEr08] entwickelt. Charakteristisch für das Innovationsreifegrad-Modell ist die Messung der Innovationsfähigkeit anhand von Innovationsleveln. Vergleichbar zum Capability Maturity Model, das den Reifegrad einer Softwareentwicklungsorganisation definiert [vgl. Kneu03; Bürg07, S. 47; CMMI07], kann sich ein Unternehmen von Stufe zu Stufe weiterentwickeln. Voraussetzung dazu ist, dass zunächst alle Anforderungen an eine Stufe zu erfüllen sind. Die Durchführung zum Innovationsreifegrad-Modell nach [KeEr08, S. 6] beruht auf drei Schritten: Bestimmung des Ist-Zustands, Ableitung von Maßnahmen zur Erreichung des nächst höheren Levels, Maßnahmen-Umsetzung und erneute Einstufung im Levelmodell [KeEr08, S. 6]. Mit der Feststellung des Innovationslevels und der Definition von Stärken und Schwächen ist die Grundlage für die Weiterentwicklung der Innovationsfähigkeit geschaffen. [KeEr08]. 284

309 Evaluation der WPIM-Anwendung Weitere Methoden zur Messung der Innovationsfähigkeit, zu Innovationsaudit, Innovationsassessment und Innovation Scorecard sowie zu Reifegradmodellen bei Innovationssystemen finden sich bei [Bürg07, S ] Methode I²MM Das integrierte Reifegradmodell, das sog. Integrated Innovation Maturity Model for Lean Assessment of Innovation Capability (I²MM) wurde von Pumacy Technologies 324 entwickelt. Der zugrundeliegende Lean-Ansatz zur Bewertung der Innovationsfähigkeit wurde auf der Tagung International Society for Professional Innovation Management 325 (ISPIM) vorgestellt. Die Entwicklung des I²MM-Reifegradmodells erfolgt im Rahmen des Verbundforschungsprojekts ISYPROM 326. ISYPROM wird vom Bundesministerium für Bildung und Forschung (BMBF) innerhalb des Rahmenkonzeptes Forschung für die Produktion von morgen gefördert. I²MM ist am weitverbreiteten und anerkannten Referenzmodell Capability Maturity Model Integration 327 (CMMI) [vgl. CMMI07; Bürg07, S. 47] ausgerichtet und als Reifegradmodell explizit auf die frühen Phasen bei Innovationen ausgelegt [vgl. Puma11]. Neben den fünf Reifegraden werden vier Prozessgebiete berücksichtigt: Ideengenerierung mit Produktentwicklung, Innovationsmanagement, Anforderungsmanagement (engl. Requirements Engineering) und Qualitätsmanagement. Das Reifegradmodell fokussiert im Kern auf die Evaluation der Innovationsfähigkeit auf Basis des vorhandenen Innovationsprozesses eines Unternehmens und dessen Flexibilität gegenüber Marktveränderungen und Wandlungen im Unternehmensumfeld. [Puma11] Integriertes Innovationsmanagement Das in [WaSO06] entwickelte Modell zum integrierten Innovationsmanagement stellt auf mehreren Ebenen den gesamten Innovationsprozess, das Innovationsverhalten und die Innovationsfähigkeit von Unternehmen dar. Als bestimmende Größe für den Erfolg einer Innovation und damit eingeschlossen auch einer Invention wird der Faktor Zeit beleuchtet. [WaSO06, S. 51] Der Faktor Zeit ist die bestimmende Größe für den Erfolg einer Innovation. [WaSO06] Erst die effiziente und systematische Ausrichtung des Innovationsprozesses ermöglicht eine rasche und konsequente Umsetzung innovativer Ideen in marktfähige Produkte und Dienstleitungen. [vgl. WaSO06, S. 52] Warschat/Spat/Ohlhausen schlagen im Rahmen des integrierten Innovationsmanagements vor, zunächst ein Innovationsaudit durchzuführen um den Ist-Zustand zu erfassen und daraus erste Handlungsempfehlungen abzuleiten. Um Innovationen zu beschleunigen werden sog. Zeittreiber mittels Zeittreiberanalysen und Zeittreiberdiagnosen ermittelt. Die Wirkzusammenhänge zwischen kritischen Erfolgsfaktoren in Projekten und den Zeittreibern bilden den Kern des integrierten Innovationsmanagements nach [Wars06, S ; WaSO06, S. 54]. Um den Ist-Zustand und mögliche Verbesserungen im Innovationsprozess zu 324 Homepage der Pumacy Technologies AG - - abgerufen Homepage der Jahrestagung der International Society for Professional Innovation Management, kurz ISPIM - - abgerufen Homepage des Verbundforschungsprojekts ISYPROM - - abgerufen Ziel von ISYPROM ist die Modellbasierte Prozess- und Systemgestaltung für die Innovationsbeschleunigung. 327 Capability Maturity Model Integration (CMMI) - - abgerufen

310 Evaluation der WPIM-Anwendung dokumentieren wird ein Innovationscontrolling z. B. im Sinne einer InnovationCard [WaSO06; Bull06, S. 86] oder einer ScoreCard [KaNo01; KaNo04] vorgeschlagen. Hieraus wird in weiteren Arbeiten [Spat06, SSKS07] der standardisierte InnoScore 328 (IS) entwickelt InnoScore In der Studie Überholspur Innovation stellen [SSKS07, S. 6] die Steigerung der Innovationsfähigkeit als den wichtigsten Hebel zur Profitabilitäts- und Wachstumssteigerung vor. Der InnoScore ist passend dazu eine Methode zur Messung und Bewertung der Innovationsfähigkeit von Unternehmen [SSKS07] und wurde am Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO) erarbeitet. Die Öffentlich Verfügbare Spezifikation (engl. Publicly Available Specification, PAS) PAS 1073 und ebenso das Europäische Komitee für Normung (franz. Comité Européen de Normalisation, CEN) stellt im CEN Workshop Agreement (CWA) CWA ein Verfahren zur Messung und Bewertung der Innovationsfähigkeit produzierender Unternehmen vor. Abb. 5.16: Die neun Gestaltungsfelder entlang des Innovationsprozesses [SSKS07, S. 16] Die neun Gestaltungsfelder für die Bewertung der Innovationsfähigkeit [Abb. 5.16] werden in [Spat06; Wars06, S. 31; WaSO06; SSKS07; PAS1073] detailliert vorgestellt. Diese neun Gestaltungsfelder erlauben die Messung, die Bewertung und die gezielte Steigerung der Innovationsfähigkeit. Anhand der Ausprägung innerhalb der neun Gestaltungsfelder lassen sich innovative von weniger innovativen Unternehmen unterscheiden. [vgl. SSKS07] Dabei können die neun Gestaltungsfelder durch Erfolgsfaktoren und zugehörige Indikatoren beschrieben werden. Da der Hauptzweck die Bewertung und schließlich die Steuerung der Innovationsfähigkeit ist, können die Zusammenhänge als gewichtete Mittelwerte der Indikatoren in den Gestaltungsfeldern beziehungsweise über die einzelnen Gestaltungsfelder hinweg dargestellt werden. Damit können statistische Methoden angewendet und daraus entsprechende Ergebnisse abgeleitet werden. [Wars06, S. 32] 328 Vgl

311 Evaluation der WPIM-Anwendung Abb. 5.17: Gestaltungsfelder, Erfolgsfaktoren und Indikatoren [Wars06, S. 33] Die Bottom-Up-Zusammenhänge [vgl. Abb. 5.17] und der Einfluss von Indikatoren auf Erfolgsfaktoren und weiter auf Gestaltungsfelder ist in [Wars06, S. 33] beschrieben. Ebenso wird bei [Wars06] eine Baumstruktur vorgeschlagen, in der jeweils eine Verdichtung der unterliegenden Indikatoren bzw. Erfolgsfaktoren auf die nächsthöhere Ebene stattfindet [Abb. 5.17]. Indikatoren bzw. kritische Erfolgsfaktoren können auch mehreren Gestaltungsfeldern zugeordnet werden. Die Interdependenz der neun Gestaltungsfelder kann daran gezeigt werden [vgl. Spat06]. Die Anwendung der Methode InnoScore, mit Ablaufdiagramm, zugehörigem Fragebogen sowie KPIs ist ebenso in [PAS1073] beschrieben wie die Codierung, die Berechnungsformeln und die Auswertung/Bewertung der Ergebnisse. Aus den eben vorgestellten Evaluationsmethoden soll nun eine geeignete Methode zur Evaluation der WPIM-Methoden und der WPIM-Anwendung ausgewählt werden Begründung zur Auswahl der Evaluationsmethode WPIM als Kern des Innovationsmanagements fördert die Innovationsfähigkeit von Unternehmen. Zum Nachweis des Nutzens und zum Einfluss von WPIM auf die Innovationsfähigkeit in Unternehmen muss eine geeignete Methode zur Messung und Bewertung gewählt werden. Die Innovationsfähigkeit von Unternehmen kann z. B. mit dem I²MM- Reifegradmodell oder dem InnoScore ermittelt werden. Aussagen zu ökonomischen Kenngrößen von Unternehmen können jedoch auf dieser Basis noch nicht getroffen werden. Bei der Auswahl zur Messung der Innovationsfähigkeit in Unternehmen ist die Entscheidung auf den InnoScore gefallen. Dies hat mehrere Gründe, die ebenfalls in [WaSO06; SSKS07; PAS1073] belegt sind: Die wissenschaftliche erarbeitet Methode InnoScore wurde bereits mit Partnern und Unternehmen in der Praxis erprobt. Zum Produktiveinsatz von InnoScore in der Industrie gibt es eine Vielzahl von Beispielen [www.innoscore.de], die die Akzeptanz des InnoScores belegen. Weitere Vorteile des InnoScores sind im standardisierten Aufbau, dem fixierten Bewertungsrahmen, den festgeschriebenen KPIs und dem methodischen Ablauf bei Bewertung und Codierung zu sehen, 287

312 Evaluation der WPIM-Anwendung zudem in der sichergestellten Vergleichbarkeit der Innovationsfähigkeit von Unternehmen durch das einheitliche Set von KPIs sowie dem normierten Wert des InnoScores. Ausschlaggebend ist, dass der InnoScore als Standard [CWA 15899:2008] und [CWA15899] zur Verfügung steht, somit als europaweite Norm anerkannt ist und in Unternehmen bereits eingesetzt wird. Abschließend bleibt festzuhalten, die Methode InnoScore ist generisch gut geeignet, den Einfluss von WPIM auf die Innovationsfähigkeit von Unternehmen anhand von qualitativen Eigenschaften zu messen und diese quantitativ zu bewerten. In einem Gedankenexperiment (der sog. Simulation) wird der InnoScore ermittelt, der wiederum die Förderung der Innovationsfähigkeit durch WPIM zum Ausdruck bringt. 5.5 Simulation zur Ermittlung des InnoScores mit und ohne WPIM Ziel der InnoScore-Methode ist die standardisierte Ermittlung des InnoScores eines Unternehmens, um Aussagen zur Innovationsfähigkeit treffen zu können. Über die Zeitachse und die mehrfache Ermittlung des InnoScores können somit Veränderungen der Innovationsfähigkeit gemessen und somit Maßnahmen auf deren Wirksamkeit überprüft werden. Dies gilt für einzelne der neun Gestaltungsfelder wie auch auf das gesamte Unternehmen. [vgl. Spat06] Da sich WPIM bisher nicht in einem Unternehmen im produktiven Einsatz befindet, wird der InnoScore auf Basis simulierter Daten (sog. simulierte Datenerhebung) errechnet (sog. Simulation). Die Zielerreichung für WPIM wird als Hypothese zur Steigerung der Innovationsfähigkeit festgelegt. Diese Vorgehensweise ermöglicht auf Basis der simulierten Daten eine Auswertung und Bewertung hinsichtlich der Zielerreichung. Der Nachweis, dass der Einsatz von WPIM die Innovationsfähigkeit zu steigern vermag, wird auf Basis der simulierten Daten erbracht. Die Evaluation der WPIM-Anwendung erfolgt anhand von Leistungsindikatoren, erzielten Ergebnissen und der Verifikation der aufgestellten Hypothesen (sog. hypothesenprüfende Methode). Die Simulation wird zweifach durchgeführt. Zunächst werden Daten für ein Unternehmen ohne WPIM simuliert und dann die Datenerhebung erneut simuliert für dasselbe Unternehmen nach der Einführung von WPIM, also mit WPIM. Dabei gilt es, über Indikatoren z. B. Zeitvorteile bei der Prozessdurchführung zu ermitteln Zeitvorteile, Indikatoren und InnoScore bei WPIM Der positive Einfluss/Nutzen der entwickelten WPIM-Anwendung auf die Innovationsfähigkeit von Unternehmen soll nachgewiesen werden. Unter Nutzen sind dem magischen Dreieck des Projektmanagement [Rutt 1991 in SKWO06, S. 113] folgend, die Reduktion von Zeit (z. B. Entwicklungszeit), der Kosten (z. B. Entwicklungskosten) sowie die Steigerung der Qualität zusammengefasst. Subsumierend lässt sich festhalten: Optimierte Prozesse, Standardisierungen und Werkzeuge zielen im Innovationskontext auf die Reduktion von Zeiten insbesondere auf die Verkürzung von Entwicklungszeiten also den zeitlichen Vorsprung bei Innovationen [vgl. SKWO06, S. 112] ab. Zeit wird zum Wettbewerbsfaktor. [Bull06] Wird eine Zeitersparnis z. B. durch den Einsatz von WPIM realisiert, so steht es dem Unternehmen offen, wie mit dieser Zeitersparnis umgegangen werden soll. Unternehmen steht es dann offen, Kostenvorteile (finanzoptimiert: Kostenreduktion, Gewinnmaximum) zu realisieren, die gewonnene Zeiten in die Produktverbesserung oder Qualitätssteigerungen (Werthaltigkeit: Qualität, Nachhaltigkeit) zu auszugeben oder in neue Ideen, Innovationen und Produkte 288

313 Evaluation der WPIM-Anwendung (zukunftsgerichtete Investition) zu investieren. Ein Qualitästmerkmal 329 im Sinne eines Indikators kann auch die Fehlervermeidung oder die Fehlerreduktion sein. Zeit und angestrebte Zeiteinsparungen sind somit der Schlüsselfaktor schlechthin und können mit der jeweiligen Ausrichtung von Unternehmen und der Unternehmensstrategie in Einklang gebracht werden. Die WPIM-Methode und auch die WPIM-Anwendung gehen einher mit den globalen Zielvorgaben: Zeitersparnis, Kostenreduktion, und Prozessverbesserung. Dem Bottom-up- Ansatz in [Abb. 5.17] folgend, kann der Einfluss der WPIM-Anwendung auf den InnoScore gezeigt werden. Der Einfluss wird anhand der 36 Key Performance Indikatoren (KPI) qualitativ erfasst und quantitativ belegt. Die KPIs fließen in die neun Gestaltungsfelder [nach Wars06] ein. Ein KPI kann auch in mehrere Gestaltungsfelder einfließen. Im theoretischen Extremfall könnte ein KPI in alle neun Felder einfließen. Ein vermuteter KPI, der in kein einziges der neun Gestaltungsfelder einfließt, ist sicherlich kein KPI. Aufbauend auf den Berechnungen und dem Ablaufdiagramm nach [Wars06] lässt sich nun der InnoScore bestimmen. Ziel hierbei ist es, mögliche, durch WPIM erzielte Verbesserungen, hinsichtlich der Innovationsfähigkeit in Unternehmen aufzuzeigen. Diese Verbesserungen müssen vor einen Überprüfung zunächst als Hypothese formuliert werden Hypothese, Annahmen und Conclusionen In der empirischen Wissenschaft haben Hypothesen 330 den Status von Annahmen, die dann nach dem deduktiv-nomologischen Modell (also durch Verknüpfung von Aussagen herleitbar sind) überprüft werden können. Hypothesen, die keiner empirischen Überprüfung unterzogen werden können, gelten nicht als wissenschaftliche Hypothese. Wie der Name bereits sagt, ist WPIM auf ein Prozessorientiertes Wissensbasiertes Innovationsmanagement ausgerichtet. Das Innovationsmanagement i. S. von WPIM zielt direkt auf die Verbesserung der Innovationsfähigkeit von Unternehmen ab. Dieser Zusammenhang sowie die vermutete und noch zu zeigende Verbesserung lassen sich als Hypothese formulieren. Die Hypothese zur Erhöhung der Innovationsfähigkeit durch WPIM wird durch die Anwendung des InnoScores auf die Daten der Simulation überprüft. Die positiv formulierte Hypothese lautet: Hypothese 5.1: Innovationsfähigkeit Die Innovationsfähigkeit in einem Unternehmen wird durch die Anwendung von WPIM erhöht. Die Hypothese soll im Rahmen dieser Evaluation untersucht werden. Vorab werden folgende Annahmen getroffen: Die Innovationsfähigkeit in einem Unternehmen kann als InnoScore gemessen werden. Der InnoScore zeigt die Innovationsfähigkeit eines Unternehmens an. Auf Basis der Hypothese und der Annahmen ist folgende Conclusio möglich: Wenn die Anwendung von WPIM in einem Unternehmen einen Einfluss auf den InnoScore hat, so hat der Hypothese folgend, die Anwendung von WPIM in einem Unternehmen einen Einfluss auf die Innovationsfähigkeit des Unternehmens. 329 Dazu sind z. B. die Kosten von Fehlern (präziser Kosten pro Fehler) zu ermitteln. Durch den Nachweis einer verringerten Fehleranzahl, in einem Beobachtungszeitraum, kann dann der direkte (monetäre) Nutzen der reduzierten Fehleranzahl errechnet werden. 330 Vgl. Wikipedia, Suche Hypothese - - abgerufen

314 Evaluation der WPIM-Anwendung Zur Wenn-Dann-Conclusio noch ein konkretes Beispiel: Wenn die Anwendung von WPIM in einem Unternehmen einen positiven Einfluss auf den InnoScore hat, dann hat die Anwendung von WPIM in einem Unternehmen einen positiven Einfluss auf die Innovationsfähigkeit des Unternehmens. Wie an der Hypothese veranschaulicht, sind auch weitere untergeordnete Hypothesen mit verfeinerten Annahmen und zugehörigen Conclusionen denkbar. Solche untergeordneten Hypothesen können, z. B. auf die Überwindung von Barrieren durch WPIM oder auch investierte Entwicklungszeiten im Vergleich zur realisierten Zeitersparnis durch den Einsatz von WPIM abzielen. Mit der erhöhten Innovationsfähigkeit gehen weitere Vorteile, wie z. B. Zeitvorteile, schnelle Innovationen durch einen beschleunigten Time-to-Market Prozess [Wars06, S. 30] sowie generell der zeitliche Vorsprung bei Innovationen [dargestellt in Bull06, S. 112] einher. Im Folgenden wird die geplante Simulation mit entsprechenden Rahmenbedingungen vorgestellt Simulation und Rahmenbedingungen Bei der Simulation wird gedanklich eine erste Erhebung und Bewertung des fiktiven Unternehmens mit dem InnoScore (IS Basis ) durchgeführt. Nachdem in diesem Unternehmen gedanklich WPIM eingeführt wurde, folgt ein zweite Erhebung und Bewertung mit dem InnoScore (IS WPIM ). Definition 5.13: Kognitive Befragung Die Ergebnisse dieser Befragung beruhen auf dem subjektiven Vorstellungsvermögen, der Erkenntnis (engl. cognition) und Einschätzung eines Experten. Bei der Simulation werden also zwei Durchläufe der Methode durchgeführt und die Ergebnisse dieser beiden kognitiven Instanzen miteinander verglichen. Aus den beiden gewonnenen InnoScores (IS Basis und IS WPIM ) wird der Einfluss von WPIM auf die Innovationsfähigkeit des fiktiven Unternehmens errechnet. Folgende Rahmenbedingungen werden bei der Simulation berücksichtigt: WPIM wurde bisher nicht in Unternehmen eingeführt und ist somit noch nicht in einer Produktivumgebung erprobt. Eine repräsentative Umfrage unter Benutzern ist somit bisher nicht möglich. Für beide Methodendurchläufe wird jeweils nur eine kognitive Befragung zu den KPIs erhoben. Es liegt keine quantitative Studie vor. Die kognitiven Befragungen sind ausreichend für die Simulation und ermöglichen den Nachweis der Verbesserung der Innovationsfähigkeit durch WPIM. Hintergrund zur Akzeptanz der Rahmenbedingungen und der vereinfachten Ermittlung des InnoScores: Um konkret den Nutzen von WPIM nachzuweisen, hätte ein identisches Projekt, bzw. eine Innovation einmal mit und einmal ohne WPIM erfolgen müssen. Parallel dazu hätte der InnoScore ermittelt werden müssen. Das sind unrealistische Voraussetzungen für eine Erhebung in der betrieblichen Praxis. Die Einführung von WPIM im betrieblichen Umfeld sowie die Messung des InnoScores eines Unternehmens, welches WPIM nutzt, kann jederzeit nachgeholt werden. Daher ist die Entscheidung auf eine Simulation zur Ermittlung des InnoScores in Bezug auf mögliche Verbesserungen durch WPIM gefallen. Um den Einfluss von und die Verbesserung durch WPIM in dieser Simulation nachzuweisen, ist die Entscheidung auf ein zweistufiges Verfahren gefallen. Für ein fiktives Unternehmen wird der InnoScore zunächst 290

315 Evaluation der WPIM-Anwendung ohne WPIM (IS Basis ) und dann nach Einführung von WPIM (IS WPIM ) ermittelt InnoScore ohne WPIM Zunächst wird für das fiktive Unternehmen ohne WPIM ein erster Durchlauf durch den Fragebogen [vgl. Tab. 5.14] gedanklich vorgenommen und aufgrund der Bewertung ein Basis InnoScore (IS Basis ) errechnet. Um die Komplexität zu reduzieren, werden für das fiktive Unternehmen allen Fragen und somit KPIs eine einheitliche Bewertung als Basiswerte zugeordnet. Erste konservative Überlegungen ergaben, in einer einheitliche Bewertung allen 36 Fragen bei trifft zu ein gar nicht zuzuordnen. Der so errechnete Basis InnoScore ist der niedrigste InnoScore, der überhaupt zulässig ist, da alle 36 Fragen zwingend zu beantworten sind [vgl. PAS1073]. Bei der Festlegung der niedrigsten Bewertung gar nicht entsteht bei genauer Betrachtung das größte absolute wie auch relative Potenzial für Verbesserungen in der Innovationsfähigkeit. Dies liegt darin begründet, dass der InnoScore grundsätzlich durch Minimal- und Maximalwerte begrenzt wird. Dazu folgt die Formel zur Berechnung des Innovationsfähigkeitswertes, InnoScore, über alle neun Gestaltungsfelder und mittels den 36 Indikatoren: IS = I z z= 1 mit IS := InnoScore; I := Indikatorwert; I := {1, 2, 3, 4}; z:= {1,, 36} nach [PAS1073]. Der Codierung in [Tab. 5.12] folgend kann der IS somit minimal IS min =1 und maximal IS max =4 annehmen. Somit wird der IS begrenzt durch IS Def = [1,00; 4,00]. Obwohl bei der Ermittlung des IS Basis eine konservative Beantwortung des Fragekatalogs angestrebt wird, hat dies den gegenteiligen Effekt. Denn beim Verbesserungspotenzial hinsichtlich Innovationsfähigkeit ist ein theoretisches Maximum von absolut 3,00 Punkten von IS min zu IS max denkbar. Eine nachteilige Entwicklung kann nicht erfasst werden. Aus diesen Gründen wird bei der Beantwortung der 36 Fragen für alle KPIs die Basisbewertung eher nein vergeben. Somit liegt der hier ermittelte IS nach der Codierung bei IS Basis = 2,00 und bietet eben Verbesserungspotenzial sowie Handlungsraum nach unten bei nachteiligen Entwicklungen InnoScore mit WPIM Dann wird ein zweiter Durchlauf durch den Fragebogen [siehe Tab. 5.14] gestartet. Die Fragen werden nun für das fiktive Unternehmen mit WPIM beantwortet. Aufgrund der veränderten Ausgangslage mit Einfluss auf die Ergebnisse der Befragung wird sodann erneut der InnoScore beim Einsatz von WPIM (IS WPIM ) errechnet. Um die Methode durchgängig und nachvollziehbar anzuwenden wird bei wahrnehmbaren Verbesserungen eine Heraufstufung bei der Beantwortung der Fragen vorgenommen. Bei nachteiligen Entwicklungen gibt es die Möglichkeit einer Herabstufung. Anzumerken ist, dass die Veränderungen durch WPIM nicht subjektiv bewertet werden. Heraufstufungen bzw. Herabstufungen finden jeweils zur nächsten angrenzenden Kategorie statt. Das Überspringen von Kategorien ist im Rahmen dieser Arbeit nicht angedacht, wird aber grundsätzlich von der Methode unterstützt. Bei erkannten Verbesserungen durch WPIM wird lediglich eine Verbesserung in die nächsthöhere Kategorie eher ja erteilt. Bei negativen Entwicklungen wird eine Herabstufung in die nach unten angrenzende Kategorie gar nicht vorgenommen. Es folgt die Codierung der KPIs sowie die Auswertung samt Ergebnissen zur Simulation. 291

316 Evaluation der WPIM-Anwendung Codierung, Auswertung und Ergebnis der Simulation Die Ergebnisse der Befragung werden gem. [PAS1073] und [Tab. 5.12] codiert und ausgewertet. Bei der Bewertung zu den 36 KPIs im Fragebogen [PAS1073] ist aufgefallen, dass WPIM nur auf zehn der 36 KPIs einen Einfluss ausübt: WPIM Einfluss = {I 5, I 7, I 8, I 13, I 15, I 16, I 22, I 23, I 24, I 31 } Diese übrigen 26 KPIs werden durch WPIM nicht beeinflusst und im Fragebogen als unverändert konstant also weiterhin mit eher nicht bewertet. WPIM Kein_Einfluss = { I 1, I 2, I 3, I 4, I 6, I 9, I 10, I 11, I 12, I 14, I 17, I 18, I 19, I 20, I 21, I 25, I 26, I 27, I 28 I 29, I 30, I 32, I 33, I 34, I 35, I 36 } Hierfür werden keine Abhängigkeit und somit auch kein Einfluss von WPIM auf dies KPIs identifiziert. Diese 26 KPIs bleiben in Ausprägung und Wert konstant und verändern den InnoScore nicht. Frage/KPI ohne WPIM mit WPIM Bewertung Codiert Bewertung Codiert 1 eher nicht 2 eher nicht 2 2 eher nicht 2 eher nicht 2 3 eher nicht 2 eher nicht 2 4 eher nicht 2 eher nicht 2 5 eher nicht 2 eher ja 3 6 eher nicht 2 eher nicht 2 7 eher nicht 2 eher ja 3 8 eher nicht 2 eher ja eher nicht 2 eher ja 3 32 eher nicht 2 eher nicht 2 33 eher nicht 2 eher nicht 2 34 eher nicht 2 eher nicht 2 35 eher nicht 2 eher nicht 2 36 eher nicht 2 eher nicht 2 Summe Tab. 5.14: Bewertung und Codierung von KPIs Im Rahmen der Simulation werden zehn KPIs von WPIM positiv beeinflusst und diese werden im Fragebogen jeweils eine Kategorie heraufgestuft, also besser bewertet mit: eher ja. Auf keinen einzigen KPI konnte durch WPIM negative Auswirkungen durch WPIM festgestellt werden. Dementsprechend findet im Fragebogen und bei der Bewertung keine Herabstufung von KPIs statt. Nach der Codierung beider Fragebögen lassen sich folgende IS errechnen: IS Basis = 2,00 IS WPIM = 2,27 In einer detaillierten Analyse und Berechnung kann zudem der Einfluss von WPIM auf einzelne der neun Gestaltungsfelder nachgewiesen werden. Ebenso kann für einzelne Gestaltungsfelder 292

317 Evaluation der WPIM-Anwendung durch den Vergleich Gestaltungsfeld Basis gegen Gestaltungsfeld WPIM die Verbesserung durch WPIM aufgezeigt werden. Diese Wirkzusammenhänge der KPIs auf die neun Gestaltungsfelder erfolgt auf Basis empirischer Erhebungen und bildet den wissenschaftlich Kern beim InnoScore [PAS1073] aus. Auf Basis dieser beiden InnoScores wird die Verbesserung = IS WPIM - IS Basis errechnet: 2,27-2,0 = 0,27. Der Einsatz von WPIM erwirkt eine absolute Verbesserung des InnoScores um 0,27 Punkte. Die prozentuale Verbesserung IS WPIM gegen IS Basis nach der Formel (IS WPIM - IS Basis ) / IS Basis liegt bei (2,27-2,0) / 2,0 = 0,135 = 13,5 %. Somit wird durch den Einsatz von WPIM in dieser Simulation eine Verbesserung des InnoScores um 13,5 % erzielt. Da der InnoScore die Innovationsfähigkeit von Unternehmen nach standardisierten Vorgaben [PAS1073] bemisst, erwirkt der Einsatz von WPIM in dieser Simulation eine Steigerung der Innovationsfähigkeit um 13,5 % auf einen InnoScore mit WPIM (IS WPIM ) von 2,27. WPIM erzielt somit eine messbare Verbesserung des InnoScores. Der InnoScore trifft Aussagen zur Innovationsfähigkeit. Somit erwirkt WPIM eine Steigerung der Innovationsfähigkeit von Unternehmen. Die aufgestellte Hypothese zur Evaluation von WPIM wird somit als korrekt bestätigt und positiv belegt. Die Verifikation der Evaluation bezüglich der Hypothese ist abgeschlossen und es folgen Vorschläge zu einer möglichen Erweiterung der Methode InnoScore Mögliche Anpassungen des InnoScores an WPIM Die Methode InnoScore ist generisch gut geeignet, den Einfluss von WPIM auf die Innovationsfähigkeit von Unternehmen anhand von qualitativen Eigenschaften zu messen und diese quantitativ zu bewerten. Darüber hinaus werden im Folgenden zwei Ideen zur Erweiterung des InnoScores speziell im Umfeld von WPIM vorgestellt: Eine erste Idee besteht darin, eine Bewertung zugeschnitten auf Potenziale bzw. Verbesserungen durch Werkzeuge und Informationssysteme wie WPIM vorzunehmen. Verknüpft mit dem bestehenden Bewertungsschema und den KPIs besteht die Idee darin, ein Gestaltungsfeld Werkzeug zu etablieren, in welches die aus den bestehenden KPIs Gestaltungsfeld Werkzeug = {I 5, I 7, I 8, I 13, I 15, I 16, I 22, I 23, I 24, I 31 } nach [Wars06] einfließen sollen. Diese Idee wurde verworfen, da die Wirkzusammenhänge der Indikatoren auf das zusätzliche Gestaltungsfeld Werkzeuge weder empirisch noch wissenschaftlich belegt sind. Für den InnoScore wurden in [PAS1073] exakt 36 KPIs entwickelt, neun Gestaltungsfelder definiert und eben genau die Wirkzusammenhänge dieser KPIs auf die einzelnen Gestaltungsfelder untersucht und hergeleitet. Weiterhin wird überlegt, zusätzliche KPIs einzuführen, die speziell bei der Messung zur Etablierung von Werkzeugen und Informationssystemen wie WPIM genutzt werden sollen. Diese weiteren KPIs würden allerdings zusätzlich in die neun Gestaltungsfelder 293

318 Evaluation der WPIM-Anwendung und somit auch den InnoScore einfließen. Der maximal erzielbare InnoScore bleibt zwar unverändert, dies widerspricht aber der einheitlichen Bewertung der Gestaltungsfelder, unterbindet die Vergleichbarkeit der codierten Ergebnisse (engl. Scores) und untergräbt den gesetzten InnoScore-Standard [vgl. PAS1073]. Daher sehen wir ebenfalls von der Aufnahme zusätzlicher und der Erweiterung der bestehenden KPIs ab. Beide Ideen zur Weiterentwicklung wurden verworfen. Die bestehende Bewertungsmethode mit ihren 36 KPIs, den neun Gestaltungsfeldern und ihrer Aussagekraft soll als vergleichbarer Standard-InnoScore gewahrt bleiben. Die KPIs, die neun Gestaltungsfelder sowie die Mittlung und Berechnung des InnoScores bleiben unangetastet. Dennoch ergeben sich Fragestellung für zukünftige wissenschaftliche Arbeiten. Bei der Einführung neuer IT-Werkzeuge oder Informationssysteme ist der Nachweis zum Nutzen nicht trivial. Neben Entwicklungs-, Einführungs- und Wartungskosten sind auch KPIs zur Zeitersparnis, Kostenamortisation und Qualitätsverbesserungen zu erfassen. Hilfreich wäre hier ein einheitlicher standardisierter ImprovementScore für IT-Systeme der in Anlehnung an den InnoScore mittels KPIs den Nutzen von IT-Systemen erfasst und ebenso Kostenaspekte mit ins Kalkül zieht. Das sind nur Vorschläge, konkret setzen wir die Evaluation mit erhobenen Daten, der sog. Datenkollektion, von Philips PCLAT fort. 5.6 Konkrete Evaluation der WPIM-Anwendung mit Philips PCLAT Die Auswahl für den Evaluationspartner ist auf den SHAMAN Projektpartner Philips PCLAT [vgl ] gefallen. Diese Entscheidung beruht darauf, dass im Rahmen der Kooperation und den Experten-Interviews geeignete Testdaten (die sog. Testkollektion) aus dem Umfeld fertigender Industrien bereitgestellt werden. Die durchgeführten Experteninterviews zur Datenfragmentierung, Ressourcenintegration und Innovationsfähigkeit werden in [Kret12] ausgewertet und die Ergebnisse zusammenfassend in [Kap ] vorgestellt. Die bei den Interviews bei PCLAT gewonnen Daten und Ressourcen (die Datenkollektion) zum Philips Ideation Process werden im Rahmen der konkreten Evaluation mit PCLAT [vgl. Kap 5.6.2] in die WPIM-Anwendung eingepflegt und darin erprobt. Der Philips Ideation Process wird mit der Testkollektion annotiert im Anschluss werden in der WPIM-Anwendung semantische Suchen durchgeführt. Die formulierte Hypothese zur verbesserten Daten- und Ressourcenintegration wird einer Verifikation unterzogen. Zudem werden das Verbesserungspotenzial der WPIM- Anwendung und der positive Einfluss auf die Szenarien, Anforderungen und Use Cases dieser Arbeit aufgezeigt. Zunächst werden die Befragung sowie die Erhebung der Datenkollektion bei Philips PCLAT behandelt Befragung, Datenerhebung und Datenkollektion von PCLAT Im Rahmen dieser Arbeit wurde ein Fragebogen [vgl. Abb. 5.18] entwickelt und mit diesem bei Philips PCLAT eine empirische Befragung durchgeführt. An dieser Stelle gilt der besondere Dank Philips Consumer Lifestyle Advanced Technology für die freundliche Unterstützung bei der Durchführung und für die Teilnahme der 13 Interviewpartner an den persönlichen Gesprächen. 294

319 Evaluation der WPIM-Anwendung Abb. 5.18: Auszug aus dem entwickelten Fragebogen zur Datenfragmentierung Die Befragung wurde an drei Standorten von Philips durchgeführt. Die Auswertung der Fragebögen sowie die erzielten Ergebnisse werden ausführlich in der hiermit verbundenen Arbeit von [Kret12] vorgestellt. Für diese Arbeit werden zwei wesentliche Ergebnisse festgehalten: Anhand der erhobenen Daten kann nachgewiesen werden, dass die Szenarien [Kap. 1.3], die ausgewählten Herausforderungen [Kap.1.4] und der zentrale Use Case der semantischen Suche [Kap ] so in der betrieblichen Praxis bei Philips PCLAT vorliegen. Der bestehende Handlungsbedarf für eine Anwendung wie WPIM ist somit erwiesen. Des Weiteren werden durch die Philips-PCLAT-Interviewpartner Daten, Informationen und Ressourcen (wie Dokumente, Patente, Präsentationen, Vorlagen, Zeitpläne etc.), die sog. Datenkollektion bereitgestellt. Diese PCLAT-Datenkollektion bildet gemeinsam mit dem Philips Ideation Prozess den Kern für die folgende Evaluation Ideation Process und Datenkollektion von PCLAT Besonders hilfreich sind die im Rahmen der Interviews [vgl ] bereitgestellten Daten, Dokumente, wie Patente und Zeitpläne sowie Werkzeug- und Systembeschreibungen die sog. Datenkollektion. Anhand dieser Datenkollektion und der Fülle an verfügbaren Systemen kann in der WPIM-Anwendung die Integration von Ressourcen und die Integration von Information bei PCLAT aufgezeigt werden. Ziel ist es, anhand der identifizierten Herausforderungen und mit den Testdaten in den beschrieben Szenarien die Praxistauglichkeit der WPIM-Anwendung nachzuweisen. Dazu soll die WPIM-Methode ganzheitlich vor dem Ziel der Ressourcenintegration betrachtet werden. Anzumerken ist, dass die WPIM-Anwendung bisher 295

320 Evaluation der WPIM-Anwendung nicht bei Philips eingeführt wurde. Anhand der Umfrage und der erhobenen Daten liegen aber eine Analyse der derzeitigen Datenfragmentierung [Kret12] und eine Anforderung der Praxis zur vollständigeren Daten- und Ressourcenintegration [vgl. Kret12] vor. Um die Praxistauglichkeit und die angestrebte Integration von Ressourcen in Innovationsprozesse nachzuweisen, wird zunächst der Philips Ideation Process in BPVA (nach-) modelliert und in die WPIM- Anwendung importiert. In der WPIM-Anwendung werden sodann punktuell die Daten und Informationen aus den Befragungen bzw. Datenkollektion an die Aktivitäten des Ideation Process geknüpft. Zudem werden die benötigten Experten-Rollen angelegt und die zugehörigen Instanzen generisch erzeugt. Im Folgenden werden die bereitgestellten Daten der Datenkollektion von PCLAT vorgestellt Philips PCLAT Ideation Prozess Philips PCLAT ist (Evaluations-) Partner im SHAMAN Projekt [vgl. Kap und Kap ] und hat neben den beantworteten Fragebögen zusätzliche Dokumente der täglichen Arbeit bereitgestellt. Kern bei der Überprüfung der WPIM-Anwendung auf Praxistauglichkeit und hinsichtlich vollständiger Integration von Ressourcen in Innovationsprozesse bildet der Philips Ideen-Prozess (engl. Philips Ideation Process) [vgl. Abb. 5.19] bereitgestellt durch Philips [in JaMo09]. Abb. 5.19: Philips PCLAT: Grafische Modellierung zum Ideation Prozess [JaMo09] Neben der grafischen Prozessmodellierung [Abb. 5.19] gibt es bei Philips eine Beschreibung zum Ideation Process [vgl. JaMo09]. Darin werden sequenziell die einzelnen Aktivitäten im Ideation Process vorgestellt und beschrieben. Das Prozessmodell liegt nur als grafisches Ablaufdiagramm vor und muss daher mit einem Prozessmodellierungswerkzeug erneut modelliert werden. 296

321 Evaluation der WPIM-Anwendung Abb. 5.20: Natürlichsprachliche Beschreibung zum Ideation Prozess [JaMo09, S. 4] Der Philips Ideation Process und die zugehörige Beschreibung werden ausführlich vorgestellt in [Küsg11, S. 9]. Prozessmodell und Beschreibung werden in eine semi-formale Repräsentation in Excel überführt [vgl. Abb. 5.21]. Diese Repräsentationen dienen zur Strukturierung der natürlichsprachlichen Information [vgl. Abb und Küsg11] und helfen bei der Zuordnung zu den Aktivitäten des Prozessmodells. Den Aktivitäten werden die genannten Ressourcen im Zwischenformat Excel zugeordnet. Abb. 5.21: Aktivitäten mit Beschreibung in semi-formaler, tabellarischer Darstellung Besonders werden bei der Zuordnung Aktivitäten und Ressourcen betrachtet [vgl. Abb. 5.21]. In das Zwischenformat Excel wird nur Information aus der natürlichsprachlichen Beschreibung [vgl. Küsg11, S. 11] aufgenommen. Zudem entsteht in [Abb. 5.22] je Aktivität eine Input/Aktion/Output-Betrachtung. 297

322 Evaluation der WPIM-Anwendung Abb. 5.22: Input/Aktion/Output Betrachtung zu einzelnen Aktivitäten Um die Aktivitäten mit den zugehörigen Ressourcen besser in BPVA darstellen zu können werden in [Abb. 5.22] zunächst die Aktivität und dann die Inputs und Outputs modelliert. In [Abb. 5.23] sind die in PBVA modellierten Aktivitäten und Pools des Philips Ideation Process aufgeführt. 298

323 Evaluation der WPIM-Anwendung Abb. 5.23: Philips Ideation Process modelliert in BPVA Das in [Abb. 5.23] in BPVA repräsentierte Prozessmodell zum Philips Ideation Process wird nach XML exportiert und dann in Protégé als Ontologie importiert. Die Aktivitäten aus dem textuellen Prozessmodell werden so aus einer natürlichsprachlichen Beschreibung in digitale Objekte überführt. Abb. 5.24: Aktivitäten des Ideation Process als Instanzen der Klasse:Aktivität 299

324 Evaluation der WPIM-Anwendung In [Abb. 5.24] sind die Aktivitäten als Instanzen der Klasse:Aktivität aufgeführt. Zudem werden die Ressourcen aus der natürlichsprachlichen Beschreibung [JaMo09; Küsg11], mittels der WPIM-Pipeline, in digitale Objekte überführt. Beispielsweise bilden die Dokumente die Instanzen zur Klasse:Dokumente. Die Klasse:Dokumente ist eine SubKlasse zur Klasse:Ressource. Ebenso sind die weiteren Ressourcen beschreibbar und werden in das Prozessmodell zum Ideation Process integriert Philips PCLAT Experten, Funktionen, Rollen in der Organisation In [Tab. 5.10] werden Rollen und Mitarbeiterprofile bei Philips mit zugehöriger Beschreibung vorgestellt und in [Abb. 5.25] werden zudem zu den Funktionsbeschreibungen Aufgaben- und Anforderungsprofile bereitgestellt. Diese natürlichsprachlichen Beschreibungen von Funktionen und Rollen der Organisation bei Philips PCLAT werden ebenso in das Zwischenformat Excel überführt [vgl. Abb. 5.25] und somit auf eine Digitalisierung vorbereitet. Funktionen sind im Kontext von Aufbauorganisationen als feste Strukturen wie Abteilungen zu verstehen. Funktionen (auch Linienfunktion) beschreiben eine Stelle in dieser starren Struktur mit exakt definierter Hierarchie-, Eskalations- und Vorgesetztenstruktur. Rollen hingegen sind deutlich flexiblere Konstrukte. Rollen können temporär vergeben werden und gehen häufig mit Projektstrukturen einher. Typischerweise nimmt ein Mitarbeiter neben seiner Linienfunktion noch weitere Rollen ein, z. B. als Projektleiter oder Qualitätsbeauftragter. Bei Philips kommen neben Funktionsbeschreibungen in der Aufbauorganisation auch Rollenkonzepte zum Einsatz [vgl. Tab. 5.10]. Abb. 5.25: Überführung der Funktionsbeschreibung bei Philips in xls und digitale Objekte Zunächst werden natürlichsprachliche Beschreibungen zu Rollen und Funktionen bei Philips [links oben in Abb. 5.25] in eine semi-formale Repräsentation in Excel überführt. Auch werden Beschreibungen, wie z. B. Fähigkeiten (engl. skills), oder Zuordnungen von Aktivitäten zu Funktionen/Rollen in Relationen wie has_skills, has_activity und, has_contact_with überführt [mittig unten in Abb. 5.25]. Die verwendeten Relationen sind [rechts oben in Abb. 5.25] dargelegt und entstammen ebenfalls aus der natürlichsprachlichen Beschreibung in [Abb linker Teil]. Die hier gezeigte Vorgehensweise ermöglicht den Aufbau einer Rollen-Ontologie gültig für PCLAT basierend auf bzw. das WPIM-Vokabular ergänzend. 300

325 Evaluation der WPIM-Anwendung Philips PCLAT Ideation Process in der WPIM-Anwendung Der in BPVA modellierte Philips Ideation Process [Abb. 5.23] wird in BPVA in ein proprietäres XML-Format umgewandelt und in die WPIM-Webanwendung hochgeladen. Nach dem Upload findet eine XSLT-Transformation in eine HTML-Darstellung sowie die Deserialisierung in programmierbare Objekte statt. [vgl. Küsg11, S. 31] Das Resultat wie auch die XML-Baumstruktur zum Prozessmodell [linker Teil in Abb. 5.26] und eine Sicht auf die Eigenschaften [rechter Teil in Abb. 5.26] des Philips Ideation Process sind in [Abb. 5.26] dargestellt. Abb. 5.26: Philips Ideation Process in der WPIM-Anwendung [Küsg11, S. 39] In [Abb. 5.26] sind zur Veranschaulichung der Leistungsumfänge der WPIM-Anwendung mehrere Darstellungen integriert abgebildet. Von gesonderter Bedeutung ist die Menüleiste in [Abb oben]. Dort können zunächst einzelne Prozesse, hier der Philips Ideation Process selektiert werden und zu einzelnen Aktivitäten Beschreibungen, Informationen und (mittels Referenzen) Ressourcen hinterlegt werden. Auch können über dieses Menü einzelne Ressourcen wie Personen, z. B. Experten sowie Dokumente/Patente, hinterlegt werden. Diese Dienste und Werkzeuge (sog. Funktionalitäten) werden genutzt, um die in der Befragung erhaltenen Dokumente und Daten an den Ideation Process zu knüpfen. Daran kann das Potenzial der WPIM-Anwendung hinsichtlich der vollständigen Integration von Ressourcen in Prozesse aufgezeigt werden. Die WPIM-Anwendung hinterlegt zudem automatisiert semantische Relationen um eine semantische Suche [vgl. Abb. 5.27] zu unterstützen. Durch die Selektion einzelner Aktivitäten können die referenziell integrierten Ressourcen direkt eingesehen und bearbeitet werden. Die WPIM-Anwendung ermöglicht die Einbindung der in den Umfragen bereitgestellten Daten und Ressourcen [vgl. Kret12]. Zudem können Referenzen auf zusätzlich genutzte Systeme und Anwendungen gesetzt werden. Bei den Experten-Interviews werden keine Daten- oder Ressourcentypen [vgl. Kret12] identifiziert, die nicht direkt oder per Referenz in der WPIM-Anwendung an den Ideation Process gekoppelt werden können. Die WPIM-Anwendung stellt für den Philips Ideation Process einen praxistauglichen Ansatz, der die vollständige Integration von Daten, Information, Dokumenten und Ressourcen bietet. 301

326 Evaluation der WPIM-Anwendung Philips PCLAT semantische Suche Das offene und erweiterbare semantische WPIM-Datenmodell bietet die Möglichkeit, den Philips Ideation Process abzubilden und mit allen bei der Umfrage erwirkten Daten und Ressourcen (der Datenkollektion) direkt oder referenziell zu annotieren bzw. zu erweitern. Um die Vollständigkeit besser belegen zu können, wird eine exemplarische semantische Suche [siehe Abb. 5.27] vorgestellt, die wiederum da maschinenbasiert vollständige und darüber hinaus semantisch-vollständige Suchergebnisse zurückliefert. Die Ergebnisse sind also nicht nur syntaktisch vollständig, sondern auch semantisch vollständig hinsichtlich dem zu Grunde liegenden WPIM-Modell bzw. der WPIM-Ontologie. Abb. 5.27: Semantische Suche im Philips Ideation Process [vgl. Küsg11, S. 43] Das Ergebnis der SPARQL-Abfrage in [Abb. 5.27] listet alle Personen 331 im Ideation Process vom Typ Experte, deren Expertise bei 3D Scaler liegt. Weitere Beispiele für semantische Suchen mittels SPARQL-Abfragen an den Ideation Process finden sich bei [Küsg11 und Woll10]. Die hier gezeigte semantische Suche nach Experten mit Expertise 3D Scaler ist derzeit bei Philips nicht möglich. Somit sind der integrierte Datenstand und das Ergebnis der Suche in der WPIM- Anwendung vollständiger als bisher bei Philips ohne WPIM. Hinsichtlich der Evaluation der Hypothese bleibt festzuhalten, derzeit sind bei Philips Daten und Ressourcen im Kontext des Ideation Process zwar vorhanden, jedoch stark fragmentiert und verteilt in verschiedenen Anwendungen auffindbar. Die Gefahr, benötigte Information oder Ressourcen zu übersehen oder nicht zu finden, ist in [Kret12] belegt. Die Daten und Ressourcen sind also bei Philips verfügbar, aber eben nicht integriert. Dies gilt z. B. für die Kontaktdaten von Personen und auch die Zuordnung von Experten zu Aktivitäten. Auch ist der Ideation Prozess bei Philips zwar als grafisches Modell mit Beschreibung verfügbar. Nicht jedoch als durchsuchbares XML-Modell mit hinterlegten Beschreibungen zu den einzelnen Aktivitäten, wie es die WPIM-Anwendung bietet. Daher wird die Hypothese positiv belegt und somit verifiziert. Die WPIM-Anwendung integriert Daten und Ressourcen vollständiger in den Philips Ideation Process als bisher in der Empirie bei Philips PCLAT möglich. Der Nutzen durch die vollständige Integration entsteht aber erst durch die semantische Suche. Beides, vollständige-semantische Integration und semantische Suche, wird in dieser Form derzeit bei Philips nicht unterstützt. Durch die WPIM-Methoden und die WPIM-Anwendung wird somit neben der angestrebten Vollständigkeit (eindeutig und lückenlos nach [Küsg11, S. 53]) bei der Integration von Ressourcen ein zusätzlicher Mehrwert erzielt. 331 Die Namen und Kontaktdaten von Personen in der WPIM-Anwendung sind nur generische Beispiele. 302

327 Evaluation der WPIM-Anwendung Evaluation von WPIM mit der Datenkollektion von PCLAT Die bei Philips PCLAT in Eindhoven, NL erhobenen Daten und der Ideation Process von PCLAT sind in der WPIM-Anwendung abgelegt. Der Ideation Process verfügt über eine ausführliche Beschreibung der Aktivitäten und deren Zusammenspiel. Zudem liegt ein Rollenkonzept zu denen am Ideation Process beteiligten Mitarbeitern vor. Bei den Interviews bei PCLAT wurden verwendete Dokumente, z. B. Projekt- und Zeitpläne, Patente und Dateitypen sowie genutzte Anwendungen identifiziert und als PCLAT-Datenkollektion bereitgestellt. Daraus lässt sich konstruktiv ein Durchlauf durch den Ideation Process aufbauen. Es liegt kein vollständiger Durchlauf durch den Ideation Process vor, aber anhand der erhobenen Daten und Dokumente kann punktuell und funktionsspezifisch der Nutzen der WPIM-Anwendung für konkrete Innovationsaktivitäten evaluiert werden. Auf Basis der Experteninterviews bei Philips PCLAT und der in der Datenkollektion bereitgestellten Daten wird die Evaluation an ausgewählten Herausforderungen, bestehenden Szenarien sowie dem zentralen Use Case semantische Suche vorgenommen. Zu den ausgewählten Herausforderungen und den bestehenden Szenarien belegt in [Kret12] ebenso wie zum zentralen Use Case werden im Folgenden Hypothesen aufgestellt. Anhand des Modells und der hinterlegten Daten werden die WPIM-Methoden bzw. in der WPIM-Anwendung die Dienste und Werkzeuge technisch erprobt und getestet. Auf Basis der so gewonnenen Erkenntnisse und erzielten Ergebnisse werden sodann die aufgestellten Hypothesen überprüft und die Ergebnisse sowie die Auswertung (sog. Evaluation) vorgestellt. Zudem wird aufgezeigt, welchen Mehrwert der Einsatz von WPIM bei PCLAT bewirken kann Standardisierungen, Referenzen, Vokabulare und Baukasten Bei Philips wurde im Bereich der Innovationen insbesondere beim Ideation Process erkannt, dass Ressource nicht immer leicht und eindeutig identifizierbar sind [vgl. Kret12]. Zudem wurde in [Kap ] festgestellt, dass bei Folgeinnovationen jedes Mal eine erneute Modellierung des Prozesses nötig wird. In diesem Abschnitt wird die WPIM-Methode hinsichtlich ihrer Fähigkeit evaluiert, Ressource eindeutig zu adressieren und zu referenzieren. Weiterhin wird dargelegt, wie die Wiederverwendbarkeit von Prozesselementen gesteigert und die Fehleranfälligkeit bei der Prozessmodellierung reduziert werden kann. Bei der Allokation von Ressourcen (bei WPIM zu Innovationsprozessen) ist deren eindeutige Identifikation zwingend nötig. Nur so können Ressourcen eindeutig und exklusiv für Aktivitäten bereitgestellt werden. Bei WPIM helfen Vokabulare bei der Adressierung von und die Referenzierung auf Ressourcen. Die nachfolgende behauptende Hypothese soll dazu getestet und verifiziert werden. Hypothese 5.2: Vokabular Durch das WPIM-Vokabular wird eine eindeutigere Adressierung/Referenz von Ressourcen und digitalen Objekten erzielt als ohne das WPIM-Vokabular. Das WPIM-Vokabular [Tab. 4.1] erwirkt Eindeutigkeit bei der Identifikation, Adressierung und Referenz von Ressourcen und digitalen Objekten [vgl. Abb und Abb. 5.25]. Das WPIM- Vokabular folgt dem Konzept der Namensräume (engl. namespace) [Kap ] und ist als eben solcher mit dem Präfix wpim: [Abb. 4.4] implementiert. Somit ist die geforderte Eindeutigkeit sichergestellt. Für alle am Prozess beteiligten Akteure ist es somit eindeutig, auf welche Ressource z. B. zugegriffen werden soll. In der Praxis, bei Philips und dem Ideation Process kommen derzeit nur begrenzt Vokabulare bei 303

328 Evaluation der WPIM-Anwendung der Allokation von Ressourcen und digitalen Objekten zum Einsatz. Sowohl die Auswahl als auch die Zuordnung der digitalen Objekte erfolgt in manuellen Schritten. Eindeutigkeit kann aufgrund der bei PCLAT verwendeten natürlichsprachlichen Bezeichnungen nicht sichergestellt werden. Auch kann derzeit bei PCLAT nicht überprüft werden ob eine Ressource, z. B. ein Experte, für eine konkrete Aktivität überhaupt zur Verfügung steht. Wird bei PCLAT konkret nach einem Experten für 3D Scaler gesucht [vgl. Abb. 5.27] muss gesondert geprüft werden ob die gefundenen Experten z. B. auch dem entsprechenden Standort zugeordnet sind. Dies wird in der WPIM-Anwendung über eindeutige Auswahllisten sichergestellt. Im Rahmen weiterer Forschungsarbeiten zu WPIM werden z. B. von [Mena12; Trög12; Baue12; Verr12] Aussagen zur Allokation, Dauer der Allokation und zum Auslastungsgrad, z. B. bei personellen Ressourcen, erwartet. Resultat: PCLAT hat bisher keine eindeutige Adressierung (bzw. Referenz) auf Ressourcen und digitale Objekte. Die WPIM-Methode und die WPIM-Anwendung basieren auf XML und RDF. Beide Technologien arbeiten auf Namensräumen und somit dem Konzept der eindeutigen Referenzierbarkeit. Referenzen auf Prozesse, Aktivitäten, Ressourcen und digitale Objekte sind bei WPIM eindeutig und verwenden das WPIM-Vokabular. Die Hypothesen zur eindeutigeren Adressierung von Ressourcen und digitalen Objekten durch das WPIM-Vokabular werden positiv belegt und sind somit verifiziert. Der WPIM-Baukasten ist ein Novum, denn bisher wurde bei Philips PCLAT ohne einen Baukasten für annotierte Prozesselementen (z. B. Aktivitäten) und (Unter-) Prozesse gearbeitet [vgl. Kret12]. Hypothese 5.3. Baukasten: Der WPIM-Baukasten ermöglicht eine schnellere Prozessmodellierung durch Wiederverwendung von annotierten Prozesselementen als ohne den Baukasten. Der Baukasten in der WPIM-Anwendung ermöglicht, bei der Instanziierung von Innovationsprozessen (sog. Prozessinstanzen) und Folgeentwicklungen, bestehende identische Prozesselemente mit annotierten Inhalten sowie modellierte Prozessstrukturen [vgl. Küsg11, S. 52] aufzugreifen und wiederzuverwenden. Gerade diese Möglichkeiten bringen im Ideation Process einen deutlichen Zeitgewinn und ermöglichen eine schnellere Prozessmodellierung. Bisher werden bei PCLAT Ideation Prozesse jedes Mal neu und einzeln modelliert. Eine Wiederverwendung bereits bestehender Prozessmodelle wird derzeit bei Philips in den Ideation Prozessen nicht genutzt [siehe Kret12]. Bei WPIM wird für eine Folgeentwicklung eine Prozessinstanz mit allen enthaltenen Aktivitäten aus dem WPIM-Baukasten bzw. der Bibliothek [Kap ] in die WPIM- Produktivumgebung [Kap ] übernommen [vgl. Küsg11]. Neben der Zeitersparnis durch die Übernahme von Prozessinstanzen mit zugehörigen Aktivitäten aus dem Baukasten wird zudem Vollständigkeit und Fehlerfreiheit bei der Übernahme der verbundenen Ressourcen und Annotationen aus dem Baukasten sichergestellt. Resultat: Zeitvorteile werden durch die schnellere Prozessmodellierung und die Wiederverwendung von Prozessen durch den WPIM-Baukasten realisiert. Dies wird durch den geringen Aufwand beim Ablegen oder Entnehmen von Prozessen und Aktivitäten in bzw. aus dem Baukasten ermöglicht. [vgl. Küsg11, S. 52] Der WPIM-Baukasten schließt zudem Fehler bei der erneuten Modellierung aus, da auf bestehende Strukturen zurückgegriffen wird. Weiterhin reduziert der Baukasten Fehler bei den Eingaben und den Annotationen, da annotierte 304

329 Evaluation der WPIM-Anwendung Aktivitäten wiederverwendet werden und entsprechende Eingaben entfallen. Auch trägt der Baukasten wesentlich zur Beschleunigung der Abläufe bei, indem die WPIM-Anwendung die Übertragung der Metadaten für den Benutzer übernimmt. [Küsg11, S. 54] Szenario: Informationsflut und Datenfragmentierung Bei Philips wurde im Bereich der Innovationen, insbesondere beim Ideation Process, eine Informationsflut identifiziert [vgl. Kap und Kret12]. Die bereitgestellten Daten der Datenkollektion sind zudem fragmentiert und die im Ideation Process benötigten Ressourcen über mehrere Standorte bei Philips sowie über Unternehmensgrenzen (z. B. bei Partnern und weiteren Geschäftsentitäten) hinweg verteilt [vgl. Kret12]. Daher wird in diesem Abschnitt die WPIM-Methode hinsichtlich ihrer Fähigkeit evaluiert, durch Datenintegration und der Behebung von (ungewollten) Redundanzen der Informationsflut sowie der erkannten Datenfragmentierung [Kret12] entgegenzuwirken. Die Evaluation der WPIM-Methoden erfolgt im Zusammenspiel mit der WPIM-Anwendung. Dazu wird die Datenkollektion in den Ideation Process der bereits modelliert in der WPIM-Anwendung vorliegt eingebracht. In der WPIM-Anwendung wird der Ideation Process mit den Daten der Datenkollektion annotiert. Ressourcen der Datenkollektion werden integrativ durch Relationen mit dem Ideation Process verknüpft. Die WPIM-Anwendung verwaltet alle Ressourcen in einem gemeinsamen zentralen Datenspeicher. Alle Daten zu Ressourcen (Personen, Dokumente, Prozesse) sind durch die WPIM-Anwendung über den zentralen Datenspeicher aufrufbar und bearbeitbar. [vgl. Küsg11, S. 52] Durch das Setzen von Referenzen innerhalb der WPIM-Anwendung, z. B. auf Dokumente, werden Redundanzen gezielt vermieden. Somit entsteht ein konsistenterer Datenstand als vor und ohne den Einsatz von WPIM. Voraussetzung hierfür ist jedoch eine konsequente Digitalisierung aller Ressourcen. Dazu sind z. B. die Dokumente, die lediglich in Papierform vorliegen, zu digitalisieren, das Wissen, das lediglich in den Köpfen von Personen existiert, ist zu externalisieren. Hypothese 5.4: Redundanzen Durch die WPIM-Anwendung werden mehr Redundanzen erkannt als ohne WPIM. Der durch WPIM erzielte Mehrwert für den Ideation Process liegt also darin, dass alle Daten nur noch einmal und nicht länger an unterschiedlichen Stellen gepflegt, gespeichert und gesucht werden müssen. Wird wie bisher bei PCLAT ein Dokument an mehreren Stellen abgelegt, muss es permanent abgeglichen und auf einen einheitlichen Stand gebracht werden. Das birgt eine große Fehlerquelle, denn die Aktualisierung von Dokumenten geschieht i. d. R. zeitverzögert, wenn sie nicht sogar gänzlich vergessen wird. Mehrfacher Aktualisierungsaufwand bei Dokumenten entfällt ebenso wie ein Abgleich von abweichenden Dokumentenständen. In den Szenarien Informationsflut und Datenfragmentierung [vgl. Kap ; Kap ; Kap ] bei Philips PCLAT werden Redundanzen, z. B. von Dokumenten, mittels semantischer Suche erkannt und können dann eliminiert werden. Die semantische Suche gibt eine dezidierte Trefferliste aus, in der Redundanzen (automatisiert) erkannt werden. Durch den semantikbasierten Suchansatz bei WPIM werden mehr Redundanzen erkannt als auf rein syntaktischer Basis. Zusätzliche und neue Redundanzen werden in der WPIM-Anwendung durch das Setzen von Referenzen auf bestehende Ressourcen, wie z. B. Dokumente, vermieden. Die absolute Anzahl an Redundanzen nimmt somit nicht zu und ist bei konsequenter Befolgung des WPIM-Referenzkonzepts sogar rückläufig. Das WPIM-Referenzkonzept ist auf die Informationsflut sowie die Datenfragmentierung im Ideation Prozess bei Philips PCLAT (auch Standort- und Unternehmensübergreifend) anwendbar und somit praxistauglich. 305

330 Evaluation der WPIM-Anwendung Resultat: Durch den integrativen Ansatz WPIM können redundante Ressourcen eliminiert und über Referenzen adressiert werden. Die absolute Anzahl der Redundanzen ist somit rückläufig und Ressourcen, wie z. B. Dokumente, werden nicht länger redundant vorgehalten, sondern über Referenzen in den Prozessablauf eingebunden. So entsteht ein konsistenter Datenstand. Die Informationsflut wird durch die Reduktion an Redundanzen ebenfalls eingedämmt. Durch die semantischen Suchen werden (auf semantischen Ebenen) zusätzliche Redundanzen zu Prozessen und Ressourcen überhaupt erst erkannt. Eine schnellere Abarbeitung des Prozesses (da die gesamte Information an einem zentralen Speicherort in der WPIM-Anwendung abgelegt ist) ist möglich und es wird eine geringere Fehleranfälligkeit bei der Prozessdurchführung aufgrund eines konsistenten Datenstands erreicht. [vgl. Küsg11, S. 53] Hypothese 5.5: Datenintegration Durch das WPIM-Datenmodell wird ein vollständigerer Integrationsgrad von Ressourcen (sog. Ressourcenintegration) in Innovationsprozesse erreicht als ohne das WPIM-Datenmodell. Das WPIM-Prozessmodell berücksichtigt Prozessdaten und Datenmodelle zu Ressourcen, wie z. B. Dokumente und Experten (sog. digitale Objekte). Das WPIM-Prozessmodell [Kap ] ermöglicht die Integration bestehender Datenmodelle auf standardisierter XML-Ebene. Die Ressourcen sind durch das überschneidungsfreie WPIM-Vokabular [vgl. Kap und Abb. 4.4] eindeutig adressier- und referenzierbar. Das WPIM-Vokabular nutzt bestehende semantische Sprachen wie RDF und OWL und integriert standardisierte Vokabulare wie DC und FOAF. Dadurch wird die Integration von Ressourceninstanzen, also von digitalen Objekten, wie z. B. von Dokumenten und Experten, erreicht. Das erweiterte WPIM-Prozessmodell wird in [Kap ] vorgestellt. Wie in der Studie [Kret12] erkannt, verfügt PCLAT derzeit über keine einheitliche (maschinenverarbeitbare) Struktur zur Integration von Ressourcen in den Ideation Process. WPIM verwendet zur strukturierten Ablage von Ressourcen Prozesse, die mit den maschinenverarbeitbaren Technologien XML und RDF modelliert sind. In der WPIM-Anwendung werden die Ressourcen und über semantische Relationen in den Ideation Process, konkret in die Aktivitäten des Ideation Process integrativ eingebracht. Die Ressourcen und digitale Objekte der Philips PCLAT-Datenkollektion werden somit in der WPIM-Anwendung basierend auf dem WPIM-Datenmodell integrativ miteinander verknüpft. Resultat: Wie gezeigt, ermöglicht das WPIM-Datenmodell eine vollständigere Ressourcenintegration in den Ideation Process, als dies bisher bei PCLAT möglich war. Diese beiden positiven Eigenschaften werden erst durch den Einsatz des WPIM-Datenmodells sowie des WPIM-Vokabulars erzielt. Die Hypothesen zur vollständigeren Ressourcenintegration durch das WPIM-Datenmodell werden folglich verifiziert. Dies lässt sich mit der verbesserten Kompatibilität 332 durch die Verwendung der standardisierten Vokabulare und der Etablierung des WPIM-Vokabulars begründen. Die Ressourcenintegration wird durch die WPIM- Anwendung überhaupt erst ermöglicht und stellt einen entscheidenden Mehrwert dieser Arbeit dar. 332 Kompatibilität beschreibt die Eigenschaften des Miteinanderfunktionierens, der Vereinbarkeit und der Austauschbarkeit. Diese Eigenschaften werden, z. B. durch Standards und bei WPIM, durch Vokabulare sichergestellt. 306

331 Evaluation der WPIM-Anwendung Szenario: Dokumentation per Gesetzeszwang Bei technischen Innovationen ist eine Projektdokumentation nötig bzw. wird durch Normen und Gesetzgebung eingefordert. Gerade bei elektronischen Geräten, wie Sie bei PCLAT entwickelt werden, wird explizit die CE-Konformität 333 gefordert. Diese muss erbracht und dokumentiert werden. Darüber hinaus ist es sinnvoll, für Folgeprojekte und Zwischenberichte bei PCLAT eine aussagekräftige und durchgängige Dokumentation zu erstellen. Hypothese 5.6: Dokumentation Die WPIM-Anwendung fördert eine projektbegleitende und durchgängige Dokumentation, die mit geringerem Aufwand erstellt werden kann, als ohne die WPIM-Anwendung. Die WPIM-Anwendung bietet eine projektbegleitende und durchgängige Dokumentation im XML/RDF-Format. Diese Dokumentation kann jederzeit angezeigt und ausgeleitet werden [vgl. Küsg11; Trög12]. Zudem kann in den einzelnen Aktivitäten die den Ideation Process begleitende Dokumentation eingesehen werden. Der von WPIM geforderte Drill-Through- Ansatz [VoHe06b; Kap ] wird hierdurch voll unterstützt. Dabei wird von höheren Wissensebenen hin zu detaillierteren Dokumenten navigiert. Dieser Drill-Through erfolgt u. a. über den Detail-Button [vgl. VoHe06c; Küsg11 und Abb. 3.23]. So kann beispielsweise von der Aktivität Idea Generation [vgl. Abb und Abb. 5.27] zur Beschreibung der Durchführung (engl. work instruction) bis hin zur Aktivität mit konkreten Methodenvorschlägen i. S. e. Methodenbaukastens navigiert werden. Auch gelangt man durch den Drill-Through von Musterprozessen zu Prozessinstanzen sowie von Klassen hin zu digitalen Objekten. Die Top- Down-Navigation erfolgt z. B. von der Klasse Dokumente zur SubKlasse Patente und von dort aus weiter hin zu den konkreten digitalen Patenten bei PCLAT [vgl. Abb. 4.7]. Resultat: Die WPIM-Anwendung bietet auf Basis der hinterlegten XML-/RDF-Datei eine kontinuierliche und durchgängige Dokumentation zum Prozessstatus, den hinterlegten Ressourcen und den digitalen Objekten. Nach jeder inhaltlichen Änderung oder strukturellen Erweiterung des Ideation Prozesses kann projektbegleitend gespeichert und eine maschinenlesbare Dokumentation als XML/RDF erzeugt werden. Hierzu ist kein weiterer manueller Aufwand oder eine händische Niederschrift bzw. Nacharbeit nötig. Dies war so bei PCLAT bisher nicht möglich und die WPIM-Anwendung bietet hier eine projektbegleitende und durchgängigere Prozessdokumentation bei geringem Aufwand an. Als Erweiterung der Dokumentation bei WPIM ist die Transformation des XML/RDF z. B. mittels Formatting Objects Processor 334 (FOP) in eine Dokumentation im PDF-Format denkbar [vgl. Trög12]. Mehrwert: Als Besonderheit unterstützt die WPIM-Anwendung einen geschlossenen gesamtheitlichen Entwicklungsansatz (engl. closed loop development). Die annotierten RDF- /XML-Dateien können als.txt-datei abgespeichert und in das Prozess-Modellierungswerkzeug (auch Prozess-Frontend), z. B. den Business Process Visual Architect (BPVA) [Kap ] oder den Enterprise Architect (EA) [Woll11] zurückgegeben (präziser re-importiert) werden. Dies ist ein Alleinstellungsmerkmal beim WPIM-Ansatz, da eine umfangreiche Integration der visuellen Prozesssicht und der semantischen RDF-/XML-Sicht ermöglicht wird. Diese Verknüpfung der Anwendungen kann als rückspeisefähiges 335 System (engl. closed loop oder engl. back loop system) bezeichnet werden FOP konvertiert XSL-FO, z. B. in das PDF-Format. Details unter Rückspeisefähig bezieht sich auf die Eigenschaft der Rückkopplung von Systemen. Diese Eigenschaft kann auch als Integration in beide Richtungen verstanden werden und bezieht sich auf den bidirektionalen Informationsund Wissensaustausch (sog. Wissens-Rückkopplung) zwischen WPIM und weiteren Anwendungen. 307

332 Evaluation der WPIM-Anwendung Szenario: Projektübergabe und Nachfolgeregelung Projektübergaben laufen in der betrieblichen Praxis nicht ohne Reibungsverluste ab. Die Übergabe von klar zugewiesenen Aktivitäten wird z. B. vergessen oder auf mündlicher Basis häufig fehlinterpretiert [vgl. Kret12]. Aufgaben und Kompetenzen sind nicht klar festgelegt und Rollen werden falsch oder nicht vollständig zugewiesen. 308 Hypothese 5.7: Projektübergabe Durch die WPIM-Anwendung sind Projektübergaben an Nachfolger vollständiger als ohne den Einsatz von WPIM. Dadurch, dass in der WPIM-Anwendung alle Aktivitäten und Rollen des Ideation Processes durch (semantische) Relationen zu Personen zugeordnet sind, kann durch das einmalige gezielte Ersetzen einer Person durch den Nachfolger ausgeschlossen werde, dass Aktivitäten und Rollen nicht übergeben werden. Eine automatisierte Übergabe ist in [Trög12; Mena12] angedacht, hierbei können zudem termingerechte Übergaben (über terminierte Zuordnung von Personen, Rollen und Rechten) arrangiert werden. Entsprechende Rollenkonzepte [Kap ] werden durch die PCLAT-Experten-Interviews bereitgestellt [vgl. JaMo09; Kret12; Kap ]. Im Ideation Process (modelliert in der WPIM-Anwendung) können z. B. mittels SPARQL- Abfrage zu einem scheidenden Mitarbeiter, alle Fähigkeiten (engl. skills) und dessen Ausscheidedatum abgefragt werden [vgl. Küsg11]. Auf Basis der geforderten Qualifikationen kann gezielt nach einem geeigneten Nachfolger mit ebenso besonderen Fähigkeiten und zudem auch die benötigte Verfügbarkeit des Nachfolgers (also der engl. human resource) gesucht werden. Dies ist in dieser Form derzeit bei PCLAT für den Ideation Process nicht möglich [vgl. Kret12]. Zudem können in der WPIM-Anwendung für einen scheidenden Mitarbeiter alle zugewiesenen Rollen und Rechte (z. B. für IT-Systeme) ermittelt werden. Diese benötigten Rollen und Rechte müssen bei Projektübergaben vollständig auf den Nachfolger übertragen werden, um sicherzustellen, dass der Nachfolger Zugriff und Rechte in den Systemen erhält. Diese werden benötigt, um die zugewiesenen Aktivitäten durchführen zu können. Durch eine automatisierte regelbasierte Zuordnung [vgl. Bull06; Broc07; Rule11; Mena12; SWRL] der Rollen in der WPIM-Anwendung wird z. B. zum Stichtag der Projektübergabe, die vollständige Übergabe der Rollen sichergestellt. Diese Weiterentwicklungen werden ausführlich bei [Mena12; Trög12; Verr12] behandelt. Resultat: Derzeit ist es bei PCLAT im Ideation Process nicht möglich, alle Rechte und Rollen eines Mitarbeiters mit einer einzigen SPARQL-Anfrage zu ermitteln. Eine Übertragung der Rechte und Rollen erfolgt zudem derzeit bei PCLAT als manuelle Aufgabe. WPIM ermöglicht die Ermittlung und Übergabe der Rollen und Rechte an Nachfolger. Somit arbeitet die WPIM-Anwendung bei der Projektübergabe insbesondere bei der regelbasierten Übergabe von Rollen an Nachfolger im Ideation Process vollständiger als die derzeitige fehleranfällige manuelle Projektübergabe bei PCLAT. WPIM erzielt ein maschinenmögliches Maximum an Vollständigkeit bei der Rollen-Übergabe an Nachfolger und verbessert somit die lückenhaften Projektübergaben [vgl. Kret12] in der betrieblichen Praxis. Nachfolger- und Vertreterregelungen werden benötigt, um Mitarbeitern im Innovationsprozess eindeutige Ansprechpartner bereitzustellen. Alle Prozessbeteiligten müssen sich über Veränderungen im Projekt, Nachfolger von Mitarbeitern sowie Vertreter informieren können.

333 Evaluation der WPIM-Anwendung Hypothese 5.8: Nachfolger- und Vertreterregelung Durch die WPIM-Anwendung sind Nachfolgerregelungen und Vertreterregelungen inhaltlichsinnvoller festgelegt als ohne den Einsatz von WPIM In der betrieblichen Praxis werden häufig Vertreter zu Mitarbeitern oder Nachfolger von Mitarbeitern definiert. Auch bei PCLAT sind derartige Nachfolger- und Vertreterregelungen anzutreffen [vgl. Kret12]. Bei der Entwicklung von WPIM wurde erkannt, dass in Innovationsprozessen eine Zuordnung von Vertretern und Nachfolgern nicht auf Aufgabenträgerebene sondern auf Aufgabenebene [FeSi98] sinnvoller ist. In der WPIM- Anwendung werden daher die Vertretungs- und Nachfolgeregelungen den Aktivitäten zugewiesen und nicht länger an personelle Akteure geknüpft. Ein Negativbeispiel der betrieblichen Praxis besteht darin, dass ein Mitarbeiter einen Nachfolger angegeben hat. Dieser ist wiederum im Urlaub und hat keinen oder einen aufgabenfremden Vertreter hinterlegt. Durch die direkte Zuordnung von Vertretern zu Aktivitäten werden in der WPIM-Anwendung derartige und umständliche Wirkzusammenhänge sowie lange Kausalketten vermieden. Resultat: Durch die in der WPIM-Anwendung etablierten semantischen Relationen zu Nachfolgern und Vertretungen werden diese eindeutig und für alle bei PCLAT am Prozess beteiligten Akteure nachvollziehbar angelegt. Auch sind die hinterlegten Nachfolger und Vertreter inhaltlich-sinnvoll, da zu einer Aufgabe/Aktivität ein Mitarbeiter der inhaltlich mit der Aufgabe vertraut ist zugeordnet wird. Weitergedacht sind ebenso sinnvolle Eskalationswege und Entscheidungshierarchien wünschenswert. Somit können diese ebenso eindeutig, nachvollziehbar und inhaltlich sinnvoll angelegt werden. Zu diesen Konzepten besteht noch Potenzial für Weiterentwicklungen der WPIM-Anwendung Zentraler Use Case: Semantische Suche Durch die Zusammenführung der Ressourcenbeschreibungen und Prozesse in einer gemeinsamen Datenstruktur und die Transformation in das RDF-Format wird die Ausgangsbasis für eine semantische Suche geschaffen. Dadurch wird das Auffinden von Information nochmals verbessert. [Küsg11, S. 54] Im Folgenden wird die semantische Suche an den Beispielen der Dokumentensuche und Patentrecherche verdeutlicht. Durch Ontologien kann die Suche nach Informationen erleichtert und die Treffsicherheit von Suchmaschinen verbessert werden. Sie sind in der Lage, nicht mehr nur nach bloßem Schlagwortvorkommen, sondern auch nach Assoziationen und Beziehungen zwischen Dingen zu suchen. [Bull06, S. 236] Diese Aussagen werden in der nachfolgenden Hypothese konkretisiert. Hypothese 5.9: Semantische Suche Durch die Annotation mit dem WPIM-Vokabular werden bei Suchen über annotieren Prozessen semantisch vollständigere Ergebnisse erzielt als ohne WPIM-Vokabular. Durch die Verwendung von RDF, standardisierten Vokabularen und dem WPIM-Vokabular [Kap ] in der WPIM-Anwendung wird eine semantische Suche über den Prozessen mit den zugehörigen Ressourcen überhaupt erst ermöglicht. Durch die Überführung der Daten nach XML/RDF werden Metainformationen über Ressourcen in maschinenlesbarer Form abgelegt. Im 309

334 Evaluation der WPIM-Anwendung Rahmen dieser Arbeit wird das WPIM-Vokabular zur Beschreibung des Wissensbasierten und Prozessorientierten Innovationsmanagements erstellt. Darüber hinaus werden die bereits vorhandenen, weit verbreiteten Vokabulare DC für Dokumente und FOAF für Personen eingesetzt. Der Vorteil dieser standardisierten Vokabulare ist die Kompatibilität zu einer breiten Masse von Anwendungen, die diese Namensräume verwenden. Weiterer Vorteil der semantischen und standardisierten Vokabulare besteht darin, dass über den damit annotierten Prozessen automatisierte Schlussfolgerungen, z. B. durch Reasoner [Kap ] vorgenommen werden können. Für den Ideation Prozess bringt dies Vorteile mit sich. Syntaktisch unterschiedliche aber semantisch als gleichwertig bezeichnete Konzepte, wie z. B. Prozesselement und Prozessbaustein oder Fachmann und Experte, werden durch die semantische Suche als eben semantisch gleichwertig erkannt. Ergebnisse derartiger semantischer Suchen sind bedingt durch die zugrundeliegenden semantischen Vokabulare und das WPIM-Vokabular folglich semantisch vollständiger als rein syntaktische Suchen. Für das Projektübergabe-Szenario [vgl. Kap ] werden durch den Einsatz des WPIM- Vokabulars weitere gezielte Suchen nach Ressourcen überhaupt erst ermöglicht. [Küsg11] gibt ein Beispiel: In der WPIM-Anwendung wird bei Personen das Attribut VertreterVon gepflegt. Im Rahmen des Projektübergabe-Szenarios ist jedoch der umgekehrte Fall gesucht, und zwar der bzw. die Mitarbeiter, die VertreterVon einer Person sind. Um den Inferenzmechanismus des Reasoners auszunutzen, wird im WPIM-Vokabular und der Ontologie ein zweites Attribut HatVertreter angelegt und eine symmetrische (auch inverse) Beziehung zwischen den Attributen VertreterVon und HatVertreter definiert. So kann im Projektübergabe-Szenario mit einer einfachen Abfrage herausgefunden werden, wer die VertreterVon einer konkreten Person sind, vgl. Codeausschnitt und SPARQL-Abfrage in [Kap mit Code 5.1] und [Abb. 5.9] sowie [Küsg11, S. 50]. Resultat: Syntaktisch unterscheidbare aber gleichwertige Konzepte können durch das WPIM- Vokabular als semantisch gleichwertig ausgezeichnet werden. Durch den Einsatz des WPIM-Vokabulars werden somit bei entsprechenden Suchen über den annotierten Prozessen semantisch vollständigere Ergebnisse erzielt als dies ohne den Einsatz des WPIM-Vokabulars möglich ist. Derartige semantische Suchen waren bisher im Prozessumfeld des Ideation Process nicht möglich. Zudem sind die Ergebnisse der Suchen reproduzierbar. Darüber hinaus werden im Projektübergabe-Szenario alle Vertreter zu einer Person durch die semantische Suche maschinell, lückenlos und semantisch vollständig identifiziert. Der Nutzen von standardisierten Vokabularen und des WPIM-Vokabulars ist für die Etablierung von semantischen Suchen über Prozesse unumgänglich und unbestritten. Der erweiternde Einsatz einer Ontologie minimierte zudem die (explizit zu speichernden) Angaben zu den Ressourcen und reduzierte die Komplexität der SPARQL-Abfragen. [Küsg11, S. 54] Alle Ergebnisse der Evaluation werden nun in einer Zusammenfassung dargelegt Zusammenfassung zu den Ergebnissen der Evaluation Im Rahmen des Cognitve-Walk-Through durch die WPIM-Pipeline wurde bereits in [Kap ] eine gedankliche Evaluation zum Zusammenspiel der Anwendungen sowie Ablauf und Anwendbarkeit der WPIM-Methoden erbracht. Ziel der gezeigten Evaluation (sog. Auswertung) ist es, den Nutzen und den Mehrwert von WPIM nachzuweisen. Hierzu werden die erzielten Ergebnisse durch den Einsatz von WPIM in den bestehenden Szenarien und bei den 310

335 Evaluation der WPIM-Anwendung ausgewählten Herausforderungen der betrieblichen Praxis [siehe Kret12] mit den aufgestellten Hypothesen dieser Arbeit [vgl. Kap ] abgeglichen (sog. Verifikation). Darüber hinaus werden die erzielten Ergebnisse gegen die Anforderungen, die Szenarien und den zentralen Use Case der Arbeit evaluiert. Die dazu aufgestellten Hypothesen sind durchgängig und argumentativ gegen die realen Daten und Testergebnisse aus der PCLAT-Datenkollektion verifiziert. Weitere Arbeiten zur Evaluation mit der Datenkollektion von Philips PCLAT und dem Ideation Process folgen derzeit in [Mena12] sowie zur Datenkollektion mit Innovationsund Entwicklungsprozessen aus dem SHAMAN-Projekt in [Trög12]. In dem hier vorliegenden Abgleich mit empirisch erhobenen Daten ist die Praxistauglichkeit von WPIM aufgezeigt. Insbesondere kann belegt werden, dass die Anwendung von WPIM bei den bestehenden Szenarien [Kap , Kap und Kap ], den ausgewählten Herausforderungen [Kap ] und dem Zentralen Use Case semantische Suche [Kap ] gute Ergebnisse sowie Unterstützung für den Anwender bietet. Zusammenfassend zeigt das Projektübergabe-Szenario, dass die WPIM-Webanwendung einen erheblichen Mehrwert schafft. Die Informationsbeschaffung konnte mittels Abruf und Pflege der Ressourcenbeschreibungen über eine zentrale, einheitliche Oberfläche stark verbessert werden. [Küsg11, S. 54] Im Überblick dargestellt, erwirken die WPIM-Methoden und die WPIM-Anwendung positiven Nutzen und Mehrwerte im Rahmen von: zeitlichen Einsparungen bei der Modellierung von Prozessen, qualitativen Verbesserungen durch die Reduktion von Redundanzen, projektbegleitenden und durchgängigeren Prozessdokumentationen, vollständigeren Ressourcenintegrationen, verbesserter Kompatibilität, integrativen Verknüpfungen von Prozessen und Ressourcen, eindeutigen Referenzen, vollständigeren Projektübergaben, sinnvolleren Nachfolgerregelungen und Vertreterregelungen sowie semantisch vollständigeren Ergebnissen bei den Suchen. Der erhoffte Mehrwert der entstandenen Webanwendung wurde anhand eines Projektübergabeszenarios in einem konkreten Prozess evaluiert und belegt. Der Prozessablauf konnte deutlich beschleunigt und die Fehleranfälligkeit aufgrund konsistenter Daten herabgesetzt werden. [Küsg11, S. 55] Wie in der Simulation in [Kap. 5.5 insbesondere Kap ] gezeigt, wird der InnoScore durch den Einsatz der WPIM-Anwendung positiv beeinflusst. Dadurch wird eine konkrete Verbesserung des InnoScores um 13,5 % erzielt [Kap ]. Der InnoScore und dessen Belegungen werden nach standardisierten Methode errechnet, damit Aussagekraft und Vergleichbarkeit uneingeschränkt besteht. Im Rahmen einer Simulation wird die Einführung der WPIM-Anwendung bei PCLAT simuliert und entsprechende Daten erhoben und codiert. Die aufgestellte Hypothese zur Verbesserung der Innovationsfähigkeit durch WPIM [vgl. Kap ] wird durch den Abgleich von InnoScore Basis mit dem InnoScore WPIM belegt und in der Evaluation als korrekt bestätigt und somit verifiziert. WPIM ist ausschlaggebend für die Verbesserung des InnoScores. Durch diese Verbesserung des InnoScores wird der positive Einfluss von WPIM auf die Innovationsfähigkeit von PCLAT nachgewiesen. 311

336 Evaluation der WPIM-Anwendung Die erzielten Vorteile hinsichtlich der Innovationsfähigkeit sowie die Praxistauglichkeit der WPIM-Methoden und der WPIM-Anwendung sind somit nachgewiesen. Zudem werden durch die WPIM-Methoden der Drill-Through, semantische Suchen, der Prozessbaukasten sowie die Rückführung annotierter Prozessmodelle in die Modellierungswerkzeuge (sog. rückspeisefähiges System, engl. closed loop development) bei den PCLAT-Innovationsprojekten überhaupt erst möglich. WPIM etabliert hierdurch Neuerungen, Erweiterungen und Mehrwerte, die deutlich über den Stand der Wissenschaft und der Technik [vgl. Kap. 2] hinaus führen. Es folgt eine Zusammenfassung der Arbeit mit Ausblick auf geplante weiterführende Entwicklungen. 312

337 Zusammenfassung und Ausblick 6 Zusammenfassung und Ausblick WPIM basiert auf einem sog. Technology Push, und nutzt dabei insbesondere die semantischen Technologien RDF/RDFS und OWL sowie die semantischen Suchen mit SPARQL. Die entwickelte WPIM-Anwendung wird gegen die beiden zentralen Herausforderungen [vgl. Kap. 1.4] dieser Arbeit abgeglichen und der Nutzen und Mehrwert der Anwendung dargestellt. Zudem werden die Beiträge der Arbeit in den Forschungsfeldern Wissensmanagement, Prozessmanagement und Innovationsmanagement dargelegt. Zusammenfassend werden die erzielten Ergebnisse der Arbeit dargestellt und einer kritischen Betrachtung unterzogen. Über den Umfang dieser Arbeit hinaus werden erkannte, offene Forschungsfragen und mögliche Weiterentwicklungen aufgezeigt. Abschließend wird die konkrete Verwertung von WPIM und der WPIM-Anwendung diskutiert und es wird auf die konkreten Weiterentwicklungen in fortführenden Arbeiten [Kret12; Menau12; Trög12; Baue12, Verr12] verwiesen. Der Ausblick schließt mit Überlegungen zur Einführung (sog. Pilotbenutzung) der WPIM-Anwendung und Weiterentwicklungen hin zu einem marktfähigen Produkt. Im Folgenden wird ein Abgleich, des durch WPIM Erreichten, gegen die zentralen wissenschaftlichen Herausforderungen vorgenommen. 6.1 Abgleich gegen die zentralen Herausforderungen Die beiden zentralen Herausforderungen aus [Kap. 1.4] werden durchgängig in der Arbeit berücksichtigt. An dieser Stelle werden die entworfenen Ansätze, die entwickelten Modelle und Methoden sowie die durchgeführten Implementierungen mit diesen Herausforderungen abgeglichen. Dazu werden die Herausforderungen aufgegriffen und den Ergebnissen dieser Arbeit gegenübergestellt. Ein Ausblick zeigt Anknüpfungspunkte für weitere wissenschaftliche Arbeiten und mögliche Ergänzungen zum WPIM. Die erste zentrale Herausforderung entwächst dem wissensbasierten Ansatz bei WPIM und fordert eine zentrale Struktur zur Wissensrepräsentation. Diese Herausforderung wird aufgegriffen: Zur Unterstützung von innovativen Produktentwicklungsprozessen muss zunächst eine geeignete Struktur zur Wissensrepräsentation des Innovationsprozesses selbst sowie aller benötigten Ressourcen gefunden werden. In der Modellbildung [Kap. 3] werden die Strukturen zur Repräsentation von Wissen und Innovationsprozessen vorgestellt. Diese Strukturen werden um Wissen- und Ressourcenmodelle, insbesondere um Datenmodelle wie DC für Dokumente und FOAF für Experten, erweitert. XML/RDF und OWL werden als Technologien eingesetzt und ermöglichen eine Wissensrepräsentation und darüber hinaus eine semantische Beschreibung von Ressourcen auf technischen Ebenen. Das um Ressourcen erweitere WPIM-Prozessmodell stellt die geforderte Struktur zur Prozess- und Wissensrepräsentation und es entsteht eine zentrale Wissens-, Ressourcen- und Prozessdatenbasis. In der WPIM-Pipeline und in der WPIM-Anwendung kann gezeigt werden, dass das WPIM-Prozessmodell neben Innovationsprozessen auch auf Produktentstehungsprozesse und Ideation-Prozesse angewendet werden kann. [Baue12 und Verr12] zeigen die Ausweitung von WPIM auf Software Engineering Prozesse und Software Requirements Prozesse. Der WPIM-Prozessbaukasten bietet die Möglichkeit, Musterprozesse zu instanziieren und bei Folgeinnovationen diese Prozessinstanzen erneut zu durchlaufen. Zudem können strukturelle Prozessmuster (sog. Unterprozesse) aus dem Prozessbaukasten [vgl. Kap ] in neue Prozesse übertragen werden. Die Skalierbarkeit des WPIM-Prozessmodells auf weitere Prozesstypen kann hiermit, insbesondere [vgl. Bau12] belegt werden. Die mit den Prozessen und Aktivitäten verknüpften Ressourcen werden dabei ebenso mit in den und aus dem Prozessbaukasten übernommen. Zur zukünftigen Erweiterung des WPIM-Prozessmodells sind weitere Ressourcen, wie z. B. Fähigkeiten oder Methoden, denkbar. Speziell kann in einer 313

338 Zusammenfassung und Ausblick Aktivität eine Auswahl an Methoden [vgl. Mena12] hinterlegt werden, die zur Durchführung der Aktivität geeignet sind. Beispielsweise können bei der Ideenfindung spezielle Kreativmethoden hilfreich sein, ebenso wie Methoden zur Bewertung und Auswahl von Ideen. Zukünftige wissenschaftliche Arbeiten können das WPIM-Modell um Modelle zusätzlicher Prozesstypen erweitern und ebenso das bestehende Prozessmodell um weitere Ressourcen, wie z. B. um Methoden, in einem Methodenbaukasten ergänzen [vgl. Bull06, S. 91]. Die zweite zentrale Herausforderung widmet sich der Prozessorientierung bei WPIM und fordert: 314 Implizites Wissen von Mitarbeitern auch in expliziter Form verfügbar zu machen und Wissen prozessorientiert an Innovationsprozesse zu knüpfen bzw. das Wissen in den Innovationsprozess zu integrieren. Die WPIM-Methoden, Dienste und Werkzeuge unterstützen das Ablegen von Wissen und Ressourcen direkt im Innovationsprozess und dessen Aktivitäten. Die semantisch beschriebenen Wissensressourcen werden durch semantische Relationen integrativ mit den Prozessbausteinen verknüpft. Bei einem prozessorientierten Vorgehen also entlang des Innovationsprozesses werden die Ressourcen so abgelegt, dass sie bei einem erneuten Prozessdurchlauf auch wieder im Prozesskontext, also am Ort des Wissensbedarfs, aufgefunden werden. In der WPIM- Anwendung bilden die grafischen Benutzungsschnittstellen Sichten auf detaillierte Daten, Dokumentationen und Wissensressourcen. Diese leiten die Experten bei der Durchführung von Aktivitäten prozessorientiert an und unterstützen bei der Abwicklung. Experten haben zudem die Möglichkeit, direkt auf weitere Experten zurückzugreifen, die bereits Erfahrungen bei der Durchführung einer speziellen Aktivität haben. Da die Prozessmodelle, Ressourcen und Relationen mit semantischen Technologien realisiert sind, wird bei der Suche nach Wissen, Ressourcen und Experten Unterstützung durch semantische Suchen angeboten. Insbesondere SPARQL-Abfragen sind implementiert [Trög12; Mena12] und ermöglichen gezielte Suchen. Die Anwendung von Inferenz-Mechanismen wird im WPIM-Prototyp aufgezeigt, eine Integration von Inferenz-Mechanismen in die WPIM-Anwendung wird bei anknüpfenden Implementierungen angestrebt. Prozessmanagement mit Wissensmanagement verbinden und dann den Rest einfach nachziehen. Hofer-Alfeis [Hofe06] auf der KnowTech am Abschließend stellen wir fest, die WPIM-Modelle und WPIM-Methoden, die WPIM-Pipeline und die WPIM-Anwendung ermöglichen die geforderte Integration der beiden Sichten Wissensmanagement und Prozessmanagement in der Domäne der Innovationsprozesse. Die eingesetzten semantischen Technologien RDF und OWL bieten entscheidende Vorteile bei der Beschreibung, Annotation und Suchen zu Prozessen und Wissensressourcen. Für die Etablierung von regelbasierten Ansätzen und automatisierten Umfängen in die WPIM-Anwendung sehen wir Anknüpfungspunkte und Handlungsbedarf für weitere wissenschaftliche Arbeiten. 6.2 Kritische Würdigung Zunächst werden erkannte Voraussetzungen und Handlungsbedarfe bei der Einführung von WPIM thematisiert. Als notwendige Voraussetzung (engl. enabler), um die genannten Mehrwerte erzielen zu können, ist eine konsequente Digitalisierung aller Ressourcen und Prozesse (als digitale Objekte) in den Unternehmen nötig. Auch müssen entsprechende Schnittstellen zu verbundenen Systemen für die WPIM-Anwendung zur Verfügung stehen, um den Datenaustausch und die Integration der digitalen Objekte zu ermöglichen. Zudem muss

339 Zusammenfassung und Ausblick durch geeignete Anreize die Verwendung der WPIM-Anwendung gefördert werden. Dazu wird Handlungsbedarf in den Unternehmen identifiziert, die WPIM nutzen möchten. Eine entsprechende Beflügelung durch die Unternehmensführung, geeignete Anreize und Vorgaben sowie eine ganzheitliche IT-Systemplanung sind unerlässlich. Die entwickelte WPIM-Anwendung ermöglicht die visuelle Darstellung von Prozessen auch die Online-Modellierung [vgl. Mena12] und insbesondere die Beschreibung von Ressourcen (Dokumente, Personen) in fertigenden Unternehmen durch Annotationen und mit semantischer Information. Die Beschreibungen zu den Ressourcen wird zentral in der WPIM-Anwendung im XML-Format gespeichert. [vgl. Küsg11, S. 52] Durch Transformation der Ressourcen in das RDF-Format und Anreicherung mit einer Ontologie schafft die WPIM-Anwendung die Basis für eine semantische Suche. Diese Suche erfolgt über einen eingebetteten Reasoner und die Abfragesprache SPARQL mit einer Query Library [vgl. Trög12]. Der modulare Aufbau der Anwendung schafft zudem die Voraussetzungen, die Dienste der Anwendung i. S. der Skalierbarkeit auf verschiedene Anwendungsbereiche (Domänen, Prozesse, und Industrien etc.) zu übertragen. Durch den MVC-Ansatz ist es möglich, die Darstellungs-Schicht auf einfache Weise auszutauschen und z. B. ein Plug-in für Prozessmodellierungstools zu erstellen, indem eine direkte semantische Annotation des Prozesses möglich ist. [vgl. Küsg11, S. 52] Nachweise zur Implementierung der WPIM-Anwendung finden sich in [Kap. 4.11]. Die Funktionalität der technischen Dienste [Kap. 4.8] und sozio-technischen Werkzeuge [Kap ] sind in den durchgeführten Tests [Kap. 4.13] belegt. Diese Tests weisen ebenfalls die softwaretechnische Implementierung der WPIM-Methoden sowie exemplarisch deren Einsatzmöglichkeit und Funktionsfähigkeit nach. Begleitend zur Entwicklung der eigentlichen WPIM-Anwendung wurden folgende Ergebnisse erarbeitet: das mathematische Modell zu Prozessen und Ressourcen [Kap. 3.2], das WPIM-Vokabular [Tab. 4.1] mit semantischen Relationen [Kap ], das XML/RDF-basierte Schema zum Prozess- und Ressourcenmodell [Kap ], das um Ressourcen erweiterte und integrierte WPIM-Prozessmodell [Kap ], die WPIM-Methoden sind als technische Dienste [Kap. 4.8] und sozio-technische Werkzeuge [Kap ] implementiert. Das erweiterte und integrierte WPIM-Prozess- und Ressourcenmodell bildet den Kern dieser Arbeit und vereint die Sichten des Wissensbasierten und Prozessorientierten Innovationsmanagements [Kap ]. Dieses mathematisch formalisierte und implementierte Modell würde ohne die Entwicklungen von WPIM nicht vorliegen. Das Modell leistet zudem Beiträge in den aufgezeigten Forschungsfeldern Wissensmanagement [Kap. 2.1], Prozessmanagement [Kap. 2.2] sowie dem Innovationsmanagement [Kap. 2.3] und schließt die dort identifizierten Forschungslücken [vgl. Kap. 2.7]. Die WPIM-Methoden zur semantischen Annotation von Geschäftsprozessen sind der Ansatz, um die Vorteile des Semantic Web mit dem seit langem bestehenden Forschungsfeld der Prozessmodellierung zusammenzubringen [vgl. Küsg11]. Bei den WPIM-Methoden sind insbesondere folgende Ergebnisse hervorzuheben: das Drill-Through-Verfahren [VoHe06b; Kap ], die Rückspeisefähigkeit [Tab u. Kap ] aus der WPIM-Anwendung in Prozess-Modellierungswerkzeuge wie den BPVA [Kap ], die integrierte semantische Suche mit DL-Query [Kap u. Abb. 4.7] oder SPARQL [Abb u. Abb. 4.78]. 315

340 Zusammenfassung und Ausblick 316 der eingebettete RDF-Reasoner mit SPARQL über die Bibliothek SemWeb.Net 336 [Küsg11, S. 27], die Query Library [Trög12] und der Reasoner Pellet [Kap u. Abb. 4.65], der WPIM-Prozessbaukasten [Kap ] zur Wiederverwendung von Musterprozessen, das Vererbungskonzept [Kap ] vom Musterprozess zu Prozessinstanzen [Kap ], die Visualisierungen zu Innovationsprozessen [Abb. 4.76] und den Ergebnissen (semantischer) Suchen [Abb. 4.72], die Online-Modellierung von Prozessen [vgl. Mena12], die Annotations- und Verknüpfungsmethoden [Abb. 4.63] realisiert durch semantische Relationen [Kap ], das Rollenkonzept [Kap ] zur Übergabe von Rollen auf Nachfolger, prototypisch implementiert bei [Mena12]. Die WPIM-Methoden unterstützen bei der Dokumentation [vgl. Trög12] von Innovationsprojekten und Prozessen, der Integration von Ressourcen in Innovationsprozesse und bei Projektübergaben. Semantische Suchen über Prozessdaten und Ressourcen werden durch die WPIM-Methoden überhaupt erst ermöglicht. Mit dieser Arbeit und den entwickelten WPIM- Methoden [Kap. 3.5] und Diensten [Kap. 4.8] werden die in [Kap. 1.3 u. Kap. 1.4] identifizierten Herausforderungen und abgeleiteten Anforderungen [Kap. 2.7 u. Kap. 2.8] bei Innovationsprojekten in der unternehmerischen Praxis geschlossen. Dies wird anhand der Evaluation der WPIM-Methoden nachgewiesen, insbesondere durch die Betrachtung der empirischen Datenkollektion von Philips PCLAT in der implementierten WPIM-Anwendung. 6.3 Offene Forschungsfragen und mögliche Weiterentwicklungen Im Rahmen der durchgeführten Analyse, Entwicklung und der Evaluation sind Fragestellungen aufgetreten, welche in der vorliegenden Arbeit nicht abschließend behandelt werden konnten. Folgenden technische Weiterentwicklungen der WPIM-Anwendung schlägt Küsgens vor, Details dazu sind in [Küsg11, S. 55 ff.] dargelegt: Entwicklung einer Benutzungsoberfläche für die semantische Suche. Importmöglichkeit für weitere XML-/UML-Prozessformate. Übernahme von weiteren Metadaten aus dem Musterprozess (engl. master process). Import von Profilen aus Expertennetzwerken und z. B. über OpenSocial [Kap ]. Im Rahmen der hier vorliegenden Arbeit identifizierte und besonders nutzenstiftende Weiterentwicklungen zu den WPIM-Methoden, dem WPIM-Modell und der WPIM-Anwendung werden in den verbundenen Arbeiten von [Mena12; Trög12; Baue12; Verr12] umgesetzt: Export einer Dokumentation zu einer Prozessinstanz, z. B. über XML/FOP [Kap ], Vertretungs- und Eskalationsregelungen die an Aktivitäten geknüpft sind [Kap ], Einführung und Zuordnung weiterer Rollen, Funktionen [Kap und Kap ] und von Eskalationswegen [Kap ], Eingabemasken zum Anlegen von Ontologien zu Organigrammen von Unternehmen, Einführung der zeitlichen Verfügbarkeit von Experten [Bull08], Einführung weiterer Ressourcen, z. B. von Werkzeugen oder Methoden [Bull08, S. 271], Abfragen zur Ermittlung der Qualifikation, Allokation und Verfügbarkeit von Experten, 336

341 Zusammenfassung und Ausblick Automatisierte regelbasierte Übergabe von Aktivitäten auf Nachfolger [Broc07; Rule11; SWRL]. Folgende Forschungsfragen in Verbindung mit der WPIM-Anwendung bleiben derzeit offen und bieten Handlungsbedarf für zukünftige wissenschaftliche Aktivitäten: die WPIM-Anwendung ist in einem Unternehmen einzuführen (sog. Pilot-Benutzung), in der Pilot-Benutzung sind Experimente zur Praxistauglichkeit durchzuführen, in der Pilot-Benutzung ist die intuitive Bedienung experimentell zu ermitteln, Nachweise zur Reduktion von Fehlern durch WPIM in Prozessen (i. S. d. Qualitätsverbesserung) in der betrieblichen Praxis [vgl. Kap ] z. B. durch Wiederverwendung und den WPIM-Baukasten [Kap ], Ermittlung der Kosten pro Fehler sowie Einsparungen durch die Fehlerreduktion [vgl. Kap ], Ermittlung von (monetären) Vorteilen durch den produktiven Einsatz von WPIM. Sind diese Fragestellungen und Weiterentwicklungen gelöst, steht der WPIM-Anwendung eine Qualifizierung als Software-Produkt offen. Auf Basis der Pilot-Benutzung im Sinne einer ersten Referenz aus dem betrieblichen Umfeld kann dann ebenfalls über eine Markteinführung von WPIM nachgedacht werden. 6.4 Verwertung und konkrete Weiterentwicklungen Die WPIM-Anwendung soll bei Innovationsprojekten in der betrieblichen Praxis zum Einsatz kommen und dort erprobt werden. Die dabei gewonnenen Verbesserungsvorschläge sollen in die WPIM-Anwendung einfließen. Die technische Machbarkeit, die Schnittstellen zwischen den Werkzeugen, der Einsatz der Technologien XML/RDF/OWL sowie deren Transformationen sind in der prototypischen WPIM-Pipeline erprobt und konsequent in der WPIM-Anwendung implementiert [vgl. Küsg11]. Die WPIM-Anwendung wird über diese Arbeit hinaus kontinuierlich weiterentwickelt. Derzeit werden in den wissenschaftlichen Arbeiten von [Mena12; Trög12; Baue12; Verr12] die technischen Dienste und sozio-technischen Werkzeuge der WPIM-Anwendung erweitert und anhand der Datenkollektionen von Philips PCLAT sowie dem SHAMAN-Projekt weiter evaluiert. Eine Pilot-Benutzung der WPIM-Anwendung bahnt sich im Bereich der Software Requirements und der Software-Engineering-Prozesse an. Durch diese Erprobung und die Weiterentwicklungen entsteht ein WPIM-Informationssystem, das den Herausforderungen des Wissens-, Prozess- und Innovationsmanagements gewachsen ist und in fertigenden Industrien einen positiven Beitrag leisten wird. 317

342 Appendix 7 Appendix 7.1 Anhang A: SOA, Referenzarchitektur, Registry, Repository SOA Referenzarchitektur und OASIS Serviceorientierte Architektur Das SOA-Referenzmodell wurde aufgestellt vom OASIS-Open Consortium 337 : This Reference Model for Service Oriented Architecture is an abstract framework for understanding significant entities and relationships between them within a service-oriented environment, and for the development of consistent standards or specifications supporting that environment. It is based on unifying concepts of SOA and may be used by architects developing specific service oriented architectures or in training and explaining SOA. [OASIS06] Das OASIS-Open Consortium zur Notation und Referenz Architekturen: The notion of Service Oriented Architecture (SOA) has received significant attention within the software design and development community. The result of this attention is the proliferation of many conflicting definitions of SOA. Whereas SOA architectural patterns (or reference architectures) may be developed to explain and underpin a generic design template supporting a specific SOA, a reference model is intended to provide an even higher level of commonality, with definitions that should apply to all SOA. [OASIS06] Weiterhin bietet [WebM07] einen Überblick zu SOA und stellt zudem eine weitere SOA Referenzarchitektur 338 mit Fokus auf Services, Messaging, Registry, Services, Management, Orchestration, Analysis und User Interaction bereit. SOA Registry und SOA Repository Information zu den einzelnen Services sowie zugehörige Definitionen können in der Funktion einer Registry [vgl. WebM07, S. 7] im Repository abgelegt werden [KrBa05, S. 60 in Hess07]. Somit fällt dem Repository eine Schlüsselrolle in der Architektur zu [Wood06, S. 193]. Hierbei ist zwischen einem Repository, das die Daten für ein Unternehmen verwaltet, und einem Repository, auf das mehrere Unternehmen zugreifen können zu unterscheiden [vgl. KrBa05], rechtliche Aspekte bedürfen dabei einer gesonderten Betrachtung [Hess07]. Neben den Beschreibungen von möglichen Anwendungsszenarien in dem Repository können weiterführende Daten abgelegt werden. Diese ergänzen die Daten der sog. Service Level Agreements, die ebenfalls im Repository hinterlegt werden können. Ein Service Level Agreement stellt dabei eine Übereinkunft über die Serviceleistung zwischen dem Anbieter des Services und dem Kunden dar [vgl. Melz07, S. 290] und garantiert die Dienstgüteeigenschaften der Services. [BeHe05, S. 269] Unter Dienstgüteeigenschaften können Verfügbarkeit, Leistungsfähigkeit, Fehlerhäufigkeit und Sicherheit zusammengefasst werden [BeHe05, S. 269]. Darüber hinaus wären hier Daten des jeweiligen Service-Anbieters, Aufrufgebühren, Sicherheitsfeatures und Information über die Dienstgüte des jeweiligen Service [KrBa05, S. 61, vgl. Hess07] denkbar. Abschließend konstatiert Hesselle: Das Repository stellt eine Informationsbasis für die elektronische Ausführung bzw. Unterstützung der Geschäftsprozesse der jeweiligen Unternehmung dar und bildet dabei das Herzstück des SOA- Ansatzes. 337 Die OASIS-Open Consortium Homepage - - OASIS (Organization for the Advancement of Structured Information Standards) ist ein Non-Profit-Consortium, das die Entwicklung, Konvergenz und Anpassung von offenen Standards für die globale Informationsgesellschaft treibt. 338 SOA Referenzarchitektur unter

343 Appendix 7.2 Anhang B: Einrichtung der Entwicklungsumgebung Virtueller Server Localhost von Omnicron Server OMNI HTTPd Der lokale bzw. virtuelle Server ist in das Paket OmniSecure in der Version v3.0a5 für Windows XP/2000 eingebunden. Der Server OHTTPD.exe wurde über oadmin.exe so konfiguriert, dass für PHP-Scripte ein Path-Variable angelegt wird, um serverseitige PHP-Scripte als.php-exe bzw..php-cgi.exe ausführen zu können. Die Bereitschaft und Funktionsfähigkeit des Servers, mit der default ServerIP und dem Servernamen localhost kann in der MS-DOS Eingabeaufforderung unter C:\> mit dem ping Befehl überprüft werden. Abb. 7.1: Localhost Omin HTTPd Über OMNISecure idle werden Zugriffe auf den Server und die serverseitige Bearbeitung der Anfragen angezeigt und als Pfad (engl. trace) abgebildet. Zur Erprobung von Verknüpfungen von HTML-Formularen mit.php-skripten sowie zur Überprüfung der Übergaben von Variablen in File- und Dateistrukturen ist das eine empfehlenswerte Unterstützung. Der OmniHTTPd Server ist auf der Omnicron Technologies Corporation OmniHTTPd Hompage 339 verfügbar. Abb. 7.2: XAMPP Control Panel

BPMN. Suzana Milovanovic

BPMN. Suzana Milovanovic BPMN Suzana Milovanovic 2 Übersicht Klärung von Begriffen, Abkürzungen Was ist BPMN? Business Process Diagram (BPD) Beispielprozess Entwicklung von BPMN BPMN in der Literatur 3 Grundlegende Begriffe Business

Mehr

P