Systematik zur Gestaltung und Optimierung von wissensintensiven, kooperativen Problemlösungsprozessen in der Produktentwicklung Von der Fakultät Konstruktions-, Produktions- und Fahrzeugtechnik der Universität Stuttgart zur Erlangung der Würde eines Doktor-Ingenieurs (Dr.-Ing.) genehmigte Abhandlung Vorgelegt von Dipl.-Ing. Kristina Wagner aus Stuttgart Hauptberichter: Prof. Dr.-Ing. habil. Prof. e. h. Dr. h. c. Hans-Jörg Bullinger Mitberichter: Prof. Dr.-Ing. Dr. h. c. Engelbert Westkämper Tag der mündlichen Prüfung: 18. Januar 2008 Institut für Arbeitswissenschaft und Technologiemanagement (IAT) der Universität Stuttgart, 2008 Berichte aus dem Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA), Stuttgart, Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), Stuttgart, Institut für Industrielle Fertigung und Fabrikbetrieb (IFF), Universität Stuttgart und Institut für Arbeitswissenschaft und Technologiemanagement (IAT), Universität Stuttgart Herausgeber: Univ.-Prof. Dr.-Ing. Prof. E.h. Dr.-Ing. E.h. Dr. h.c. mult. Engelbert Westkämper und Univ.-Prof. Dr.-Ing. habil. Prof. E.h. mult. Dr. h.c. mult. Hans-Jörg Bullinger und Univ.-Prof. Dr.-Ing. Dieter Spath IPA-IAO Forschung und Praxis Systematik zur Gestaltung und Optimierung von wissens- intensiven, kooperativen Problemlösungsprozessen in der Produktentwicklung Nr. 471 Kristina Wagner Fachverlag · 71296 Heimsheim D 93 ISBN (10) 3-939890-29-4, ISBN (13) 978-3-939890-29-4 Jost Jetter Verlag, Heimsheim Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheber- rechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils gültigen Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. © Jost Jetter Verlag, Heimsheim 2008. Printed in Germany. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Sollte in diesem Werk direkt oder indirekt auf Gesetze, Vorschriften oder Richtlinien (z. B. DIN, VDI, VDE) Bezug genommen oder aus ihnen zitiert worden sein, so kann der Verlag keine Gewähr für die Richtigkeit, Vollständigkeit oder Aktualität übernehmen. Es empfiehlt sich, ge- gebenenfalls für die eigenen Arbeiten die vollständigen Vorschriften oder Richtlinien in der jeweils gültigen Fassung hinzuzuziehen. Druck: printsystem GmbH, Heimsheim Dr.-Ing. Kristina Wagner Institut für Industrielle Fertigung und Fabrikbetrieb (IFF), Universität Stuttgart Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA), Stuttgart Univ.-Prof. Dr.-Ing. habil. Prof. E.h. mult. Dr. h.c. mult. Hans-Jörg Bullinger ord. Professor an der Universität Stuttgart Präsident der Fraunhofer-Gesellschaft, München Univ.-Prof. Dr.-Ing. Dieter Spath ord. Professor an der Universität Stuttgart Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), Stuttgart Univ.-Prof. Dr.-Ing. Prof. E.h. Dr.-Ing. E.h. Dr. h.c. mult. Engelbert Westkämper ord. Professor an der Universität Stuttgart Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA), Stuttgart Geleitwort der Herausgeber Über den Erfolg und das Bestehen von Unternehmen in einer marktwirtschaftlichen Ordnung entscheidet letztendlich der Absatzmarkt. Das bedeutet, möglichst frühzeitig absatz marktorientierte Anforderungen sowie deren Veränderungen zu erkennen und darauf zu reagieren. Neue Technologien und Werkstoffe ermöglichen neue Produkte und eröffnen neue Märkte. Die neuen Produktions- und Informationstechnologien verwandeln signifikant und nachhaltig unsere industrielle Arbeitswelt. Politische und gesellschaftliche Ver ände - rungen signalisieren und begleiten dabei einen Wertewandel, der auch in unseren Indu - striebetrieben deutlichen Niederschlag findet. Die Aufgaben des Produktionsmanagements sind vielfältiger und anspruchsvoller ge - worden. Die Integration des europäischen Marktes, die Globalisierung vieler Industrien, die zunehmende Innovationsgeschwindigkeit, die Entwicklung zur Freizeitgesellschaft und die übergreifenden ökologischen und sozialen Probleme, zu deren Lösung die Wirt- schaft ihren Beitrag leisten muss, erfordern von den Führungskräften erweiterte Perspek - tiven und Antworten, die über den Fokus traditionellen Produktionsmanagements deutlich hinausgehen. Neue Formen der Arbeitsorganisation im indirekten und direkten Bereich sind heute schon feste Bestandteile innovativer Unternehmen. Die Entkopplung der Arbeitszeit von der Betriebszeit, integrierte Planungsansätze sowie der Aufbau dezentraler Strukturen sind nur einige der Konzepte, welche die aktuellen Entwicklungsrichtungen kennzeich- nen. Erfreulich ist der Trend, immer mehr den Menschen in den Mittelpunkt der Arbeits- gestaltung zu stellen - die traditionell eher technokratisch akzentuierten Ansätze weichen einer stärkeren Human- und Organisationsorientierung. Qualifizierungspro - gramme, Training und andere Formen der Mitarbeiterentwicklung gewinnen als Diffe - renzierungsmerkmal und als Zukunftsinvestition in Human Resources an strategischer Bedeutung. Von wissenschaftlicher Seite muss dieses Bemühen durch die Entwicklung von Methoden und Vorgehensweisen zur systematischen Analyse und Verbesserung des Systems Pro- duktionsbetrieb einschließlich der erforderlichen Dienstleistungsfunktionen unterstützt werden. Die Ingenieure sind hier gefordert, in enger Zusammenarbeit mit anderen Disziplinen, z. B. der Informatik, der Wirtschaftswissenschaften und der Arbeitswissen - schaft, Lösungen zu erarbeiten, die den veränderten Randbedingungen Rechnung tragen. Die von den Herausgebern langjährig geleiteten Institute, das - Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA), - Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), - Institut für Industrielle Fertigung und Fabrikbetrieb (IFF), Universität Stuttgart, - Institut für Arbeitswissenschaft und Technologiemanagement (IAT), Universität Stuttgart arbeiten in grundlegender und angewandter Forschung intensiv an den oben aufgezeig- ten Entwicklungen mit. Die Ausstattung der Labors und die Qualifikation der Mitarbeiter haben bereits in der Vergangenheit zu Forschungsergebnissen geführt, die für die Praxis von großem Wert waren. Zur Umsetzung gewonnener Erkenntnisse wird die Schriften - reihe „IPA-IAO - Forschung und Praxis“ herausgegeben. Der vorliegende Band setzt diese Reihe fort. Eine Übersicht über bisher erschienene Titel wird am Schluss dieses Buches gegeben. Dem Verfasser sei für die geleistete Arbeit gedankt, dem Jost Jetter Verlag für die Auf- nahme dieser Schriftenreihe in seine Angebotspalette und der Druckerei für saubere und zügige Ausführung. Möge das Buch von der Fachwelt gut aufgenommen werden. Engelbert Westkämper Hans-Jörg Bullinger Dieter Spath Vorwort Die vorliegende Arbeit entstand während meiner Tätigkeit als Mitarbeiterin am Fraunhofer- Institut für Arbeitswirtschaft und Organisation (IAO) und dem Institut für Arbeitswissenschaft und Technologiemanagement (IAT) der Universität Stuttgart. Meinem Doktorvater Herrn Prof. Dr.-Ing. habil. Prof. e.h. Dr. h.c. Hans-Jörg Bullinger, Präsi- dent der Fraunhofer Gesellschaft, ehemaliger Leiter des Instituts für Arbeitswirtschaft und Or- ganisation (IAO) und des Instituts für Arbeitswissenschaft und Technologiemanagement (IAT) der Universität Stuttgart, danke ich ganz herzlich für die wissenschaftliche Unterstützung und die wohlwollende Förderung dieser Arbeit. Herrn Prof. Dr.-Ing. Dr. h.c. Engelbert Westkämper, Leiter des Fraunhofer-Instituts für Produk- tionstechnik und Automatisierung (IPA) und des Instituts für Industrielle Fertigung und Fabrik- betrieb (IFF) der Universität Stuttgart, gilt mein Dank für die Übernahme des Mitberichts, die eingehende Durchsicht meiner Dissertation und das Interesse an der Arbeit. Herrn Prof. Dr.-Ing. habil. Joachim Warschat danke ich in ganz besonderer Weise für die vie- len wertvollen Diskussionen und die ingenieurwissenschaftlichen Ratschläge. Allen ehemali- gen Kollegen und wissenschaftlichen Hilfskräften, die zum Gelingen dieser Arbeit beigetragen haben, danke ich für die gute Zusammenarbeit und die stete Hilfsbereitschaft. Mein Dank gilt insbesondere Hannah Flügel, Aurelia Leuze und Florian Hanne für die tatkräftige Unterstüt- zung, die wertvollen Hinweise und Denkanstöße, sowie die Durchsicht der Arbeit. Insbesondere danke ich meinen Eltern, Inge und Rudolf Wagner, für die uneingeschränkte Unterstützung und die stetige Ermutigung. Sie ermöglichten mir die Voraussetzungen zu mei- nem wissenschaftlichen Werdegang. Vor allem möchte ich mich an dieser Stelle bei meinem Mann Ilja Hauß für die konstruktiven Diskussionen und wertvollen Beiträge zur Arbeit ganz herzlich bedanken. Ohne seinen Rückhalt und seine Geduld wäre diese Arbeit nicht möglich gewesen. Stuttgart, im Januar 2008 Kristina Wagner Inhalt Abkürzungsverzeichnis 14 Abbildungsverzeichnis 15 Tabellenverzeichnis 17 1 Einleitung 18 1.1 Problemstellung und Motivation 18 1.2 Ziel, Innovationscharakter und Nutzen 20 1.3 Vorgehensweise und Aufbau 21 2 Grundlagen zum Management von wissensintensiven, kooperativen Problemlösungsprozessen 23 2.1 Definition des Begriffs Produktentwicklung 23 2.2 Inhaltliche Abgrenzung des Wissensbegriffs 23 2.3 Definition des Begriffs Kooperation 25 2.4 Inhaltliche Abgrenzung des Problembegriffs 26 2.4.1 Problem 26 2.4.2 Problem vs. Aufgabe 27 2.4.3 Symptom und Ursache 28 2.5 Inhaltliche Abgrenzung des Prozessbegriffs 28 2.5.1 Prozess 28 2.5.2 Wissensintensive Prozesse und Tätigkeiten 29 2.5.3 Problemlösungsprozess vs. Entscheidungsprozess 30 2.5.4 Wissensintensive, kooperative Problemlösungsprozesse 31 2.6 Anforderungen an die Gestaltung wissensintensiver, kooperativer Problemlösungsprozesse 32 3 Stand der Forschung: Ansätze und Methoden zur Problemlösung 34 3.1 Ansätze zur Typologisierung und Klassifikation von Problemen 34 3.2 Ansätze zur Problemprävention 39 3.3 Ansätze zur Problemlösung 41 3.3.1 VDI Richtlinien 2220, 2221 und 2222 41 10 3.3.2 IDEALS 42 3.3.3 TRIZ 43 3.3.4 Wertanalyse 43 3.3.5 REFA 6-Stufen Methode 44 3.3.6 Systems Engineering 45 3.3.7 Simultaneous Engineering & Concurrent Engineering 46 3.3.8 Prototyping & Rapid Product Development 47 3.3.9 Ansatz nach Gomez & Probst 47 3.3.10 Ansatz nach Primus 48 3.4 Wissensbasierte Systeme zur Unterstützung der Problemlösung 49 3.5 Zusammenfassende Bewertung des Stands der Forschung und Ableitung von Bedarfen für die Systematik zur Problemlösung 50 4 Ableitung eines Gestaltungsrahmens für die wissensintensive, kooperative Problemlösung 55 4.1 Vorgehen zur Ableitung eines Gestaltungsrahmens 55 4.2 Schema zur Problem- und Aufgabenklassifikation 56 4.3 Beschreibungsmodell für Probleme im Engineering-Umfeld 58 4.3.1 Problemdefinition 58 4.3.2 Problemkategorien 60 4.3.3 Hypothesen und Ziel der Untersuchung 64 4.3.4 Methodisches Vorgehen 65 4.3.4.1 Untersuchungsrahmen und Untersuchungsdesign 65 4.3.4.2 Stichprobe 66 4.3.4.3 Fragebogenaufbau 66 4.3.4.4 Statistische Auswertungsverfahren 67 4.3.5 Ergebnisse 67 4.4 Implikationen der Problemklassifikation für die Gestaltung und Optimierung von wissensintensiven, kooperativen Problemlösungsprozessen 70 5 Entwicklung der Systematik zur Optimierung und Gestaltung von wissensintensiven, kooperativen Problemlösungsprozessen 73 5.1 Ableitung von Gestaltungselementen 73 5.2 Gestaltungselement „Organisation und Koordination von Problemlösungsprozessen“ 75 5.2.1 Funktionsmodell des Problemlösungsprozesses 75 5.2.1.1 Phase I: Problemerfassung 76 5.2.1.2 Phase II: Lösungssuche 77 5.2.1.3 Phase III: Situationsanalyse 79 11 5.2.1.4 Phase IV: Lösunganpassung und –entwicklung 82 5.2.1.5 Phase V: Lösungsverifizierung und Auswahl 84 5.2.1.6 Phase VI: Lösungsumsetzung 85 5.2.1.7 Phase VII: Evaluation 86 5.2.2 Organisationsstruktur und Rollenmodell 86 5.2.3 Beschreibung der Quality-Gates im Problemlösungsprozess 88 5.2.4 Methodenunterstützung 92 5.2.5 Integration in die Unternehmensprozesse – der Problemlösungsprozess als Unterstützungsprozess 95 5.2.6 Gestaltungsempfehlungen für die Organisation und Koordination von Problemlösungsprozessen 97 5.3 Gestaltungselement „Kommunikation und Wissensaustausch“ 98 5.3.1 Problemlösung im Team 98 5.3.2 Kommunikationsbeziehungen 100 5.3.2.1 Informationstechnologische Medien zur Unterstützung der Kommunikation 102 5.3.2.2 Organisatorische Medien zur Unterstützung der Kommunikation 102 5.3.3 Wissensaustauschprozesse 103 5.3.4 Wissensbarrieren als Hemmnisse des Wissensaustausch 105 5.3.5 Expertenvernetzung durch Kompetenzprofile 106 5.3.5.1 Ziel und Nutzen von Kompetenzprofilen 106 5.3.5.2 Bedeutung des Expertiselevels für die Problemlösung 107 5.3.5.3 Aufbau der Kompetenzprofile 108 5.3.6 Gestaltungsempfehlungen für die Kommunikation und den Wissensaustausch 111 5.3.6.1 Gestaltungsempfehlungen für das Individuum 111 5.3.6.2 Gestaltungsempfehlungen für das Team 113 5.4 Gestaltungselement „Wissensintegration und Wissensgenerierung“ 114 5.4.1 Wissens- und Lernprozesse im Problemlösungsprozess 114 5.4.1.1 Organisation von Wissen im Problemlösungsprozess 114 5.4.1.2 Problemlösungsprozess als Lernprozess 116 5.4.2 Wissensintegration als Basis für die Wissensgenerierung 118 5.4.2.1 Die Bedeutung von Ontologien für die Wissens- integration bei der Problemlösung 118 5.4.2.2 Wissenskarten als graphische Form der Wissensrepräsentation 119 5.4.3 Kollektive Wissensgenerierung 121 12 5.4.4 Gestaltungsempfehlungen für die Wissensintegration und die Wissensgenerierung 123 6 Softwaretechnische Realisierung eines Problemlösungsassistenten 124 6.1 Ableitung von Anforderungen an eine informationstechnologische Unterstützung 124 6.1.1 Funktionale Anforderungen zur Abbildung des Problemlösungsprozesses 124 6.1.2 Funktionale Anforderungen zur Unterstützung der Kommunikation und des Wissensaustauschs 124 6.1.3 Funktionale Anforderungen zur Unterstützung der Wissens- integration und -entwicklung 125 6.2 Architektur des Systems 125 6.3 Verwendete Hard- und Softwareplattform 127 6.4 Spezifikation des Problemlösungsassistenten 128 6.4.1 Problemdatenbank 128 6.4.2 Problemticket 129 6.4.3 Problemwizard 130 6.4.4 Rollenkonzept 130 6.4.4.1 Rollen 130 6.4.4.2 Berechtigungen 131 6.4.4.3 Benachrichtigungen 131 7 Der Problemlösungsassistent in der praktischen Anwendung bei einem mittelständischen Automobilzulieferer 133 7.1 Ausgangssituation und Zielstellung 133 7.2 Ansatz und Vorgehensweise 134 7.3 Einsatz des Problemlösungsassistenten 135 7.4 Zusammenfassende Bewertung 136 8 Zusammenfassung und Ausblick 138 9 Literatur 140 10 Anhang 159 10.1 Fragebogen der Umfrage zum Problembeschreibungsmodell 159 10.2 Ergebnisse der Umfrage zum Problembeschreibungsmodell 176 10.3 Funktionale Anforderungen zur softwaretechnischen Realisierung der Phasen im Problemlösungsprozess 180 13 10.3.1 Problemerfassung: 180 10.3.2 Lösungssuche 180 10.3.3 Situationsanalyse, Lösungsentwicklung, Lösungsverifizierung, Lösungsumsetzung 180 10.4 Abbildung der Problemlösungsphasen im Problemlösungsassistenten (Problemticket) 181 10.4.1 Problemerfassung 181 10.4.2 Lösungssuche 182 10.4.3 Situationsanalyse 183 10.4.4 Lösungsanpassung und -entwicklung: 184 10.4.5 Lösungsbewertung 185 10.4.6 Lösungsumsetzung 186 10.5 Datenmodell 186 14 Abkürzungsverzeichnis AMEX American Express bzw. beziehungsweise CBR Case-based Reasoning CE Concurrent Engineering CSCW Computer Supported Cooperative Work CSE Concurrent Simultaneous Engineering DB Datenbank d.h. das heißt DIN Deutsches Institut für Normung ff. folgende FMEA Failure Mode and Effect Analysis HR Human Ressource IDEALS Ideal Development of Effective And Logical Systems i.d.R. in der Regel I&K Technologie Informations- und Kommunikationstechnologie IP Internet Protocol ISO International Standard Organisation IT Informationstechnologie KVP kontinuierlicher Verbesserungsprozess OS Operative System PHP Hypertext Reprocessor (Programmiersprache) QFD Quality Function Deployment REFA Reichsausschuss für Arbeitszeitermittlung, Verband für Arbeitsgestaltung, Betriebsorganisation und Unterneh- mensentwicklung RPD Rapid Product Development SE Simultaneous Engineering TCP Transmission Control Protocol TRIZ Theorie des erfinderischen Problemlösens TQM Total Quality Management u.a. unter anderem VDI Verein deutscher Ingenieure vgl. vergleiche vs. versus www World Wide Web z.B. zum Beispiel 15 Abbildungsverzeichnis Abbildung 1: Prozessbeteiligte bei der Problemlösung in der Produktentwicklung am Beispiel der Prototypenbeschaffung 19 Abbildung 2: Aufbau der Arbeit 22 Abbildung 3: Matrix implizit/explizit vs. individuell/organisational nach /169/, /67/ 25 Abbildung 4: Problemdefinition nach Autoren 26 Abbildung 5: Ansätze und Methoden zur Problemlösung 34 Abbildung 6: Problemtypen (vgl. Sell/Schimweg /142/; Dörner /41/; Fricke /48/,/49/; Kersting /81/) 36 Abbildung 7: Anforderungsstruktur eines konstruktiv-schöfperischen Problems nach Schroda /135/ 39 Abbildung 8: Lösungsfindung in der TRIZ-Methode (vgl. /155/) 43 Abbildung 9: Problemlösungszyklus nach Haberfellner /24/, S. 48 46 Abbildung 10: Problemlösungsprozess nach Primus /117/, S. 147 48 Abbildung 11: Ableitung der Zielsetzung für die Entwicklung der Systematik 53 Abbildung 12: Vorgehen zur Ableitung eines Gestaltungsrahmens 56 Abbildung 13: Problem-Aufgaben-Matrix 57 Abbildung 14: Wissensmodell 63 Abbildung 15: Verteilung der Mittelwerte der Problemkategorien von einer Skala von 1 (trifft überhaupt nicht zu) bis 5 (trifft ganz genau zu) 68 Abbildung 16: Gestaltungselemente für die Gestaltung und Optimierung von wissensintensiven, kooperativen Problemlösungsprozessen 74 Abbildung 17: Phasen des Problemlösungsprozesses 76 Abbildung 18: Symptom und Ursache eines Problems 81 Abbildung 19: Stellen und Gremien im Problemlösungsprozess 88 Abbildung 20: Entscheidungsabläufe bei einem Quality Gate (in Anlehnung an /110/) 89 Abbildung 21: Datenblatt für die Methode „Einflussfaktorenanalyse“ 93 Abbildung 22: Methoden und Werkzeuge zur Unterstützung der Problemlösung 95 Abbildung 23: Zusammenhang zwischen betrieblichem Prozess und Problemlösungs- prozess nach Primus /117/ 96 Abbildung 24: Zusammenhang zwischen Geschäftsprozess und Problemlösungsprozess 97 Abbildung 25: Kommunikationsbeziehungen im Problemlösungsprozess 101 Abbildung 26: Technische Systeme der Kommunikation 102 Abbildung 27: Organisatorische Medien zur Unterstützung von Kommunikation 103 16 Abbildung 28: Wissens- und Lernbarrieren im Überblick (nach Schüppel /137/) 106 Abbildung 29: Inhaltsstruktur eines Kompetenzprofils 110 Abbildung 30: Transfermatrix von Wissen nach Hartlieb /63/ 116 Abbildung 31: Wissenserwerb durch Lernen bei der Ausführung des Problemlöse- prozesses in Anlehnung an Weggemann /171/ 117 Abbildung 32: Beziehungsdiagramm für wissensintensive Probleme 118 Abbildung 33: Ontologie für den Bereich Werkstoffe/Verfahren im Rapid Prototyping 119 Abbildung 34: Wissensarten im Problemlösungsprozess am Beispiel der Phase „Situationsanalyse“ 121 Abbildung 35: Abbildung der Wissensstruktur für die Problemlösungsphasen 121 Abbildung 36: Gestaltungsmöglichkeiten des Lösungsdesigns 122 Abbildung 37 Architektur – Schalendiagramm 126 Abbildung 38: Beziehung zwischen den Elementen im MVC 127 Abbildung 39: Komponenten des Problemlösungsassistenten 128 Abbildung 40: Problemdatenbank 129 Abbildung 41: Problemlösung im Praxisbeispiel – Problemlösungsassistent realisiert als Modul einer Plattform für Wissensnetzwerke 135 Abbildung 42: Beispiel eines Problemtickets – Oberflächendefekt bei grauen Abgussteilen 136 Abbildung 43: Datenmodell des Problemlösungsassistenten 187 17 Tabellenverzeichnis Tabelle 1: Bewertung der untersuchten Ansätze 51 Tabelle 2: Beschreibung der identifizierten Überkategorien von Problemen (Faktoren) 70 Tabelle 3: Beschreibung der aus den Problemklassen abgeleiteten Handlungsfelder für den Problemlösungsprozess 72 Tabelle 4: Kriterienkatalog zur Erfassung eines Problems 77 Tabelle 5: Kriterien für Quality Gate 1- Problemerfassung 90 Tabelle 6: Kriterien für Quality Gate 2 - Lösungssuche 91 Tabelle 7: Kriterien für Quality Gate 3 - Situationsanalyse 91 Tabelle 8: Kriterien für Quality Gate 4 – Lösungsanpassung und -entwicklung 92 Tabelle 9: Kriterien für Quality Gate 5 – Lösungsverifizierung und Auswahl 92 Tabelle 10: Kriterien für Quality Gate 5 – Lösungsverifizierung und Auswahl 92 Tabelle 11: Wissensaktivitäten in den Problemlösephasen 115 Tabelle 12: Angesetzte Qualitätskriterien für den Problemlösungsassistenten 128 Tabelle 13: Rechterollen im Problemlösungsassistent 130 Tabelle 14: Nutzerrollen im Problemlösungsassistent 131 Tabelle 15 Berechtigungen im Problemlösungsassistenten 131 Tabelle 16: Reliabilitäten der Skalen 176 Tabelle 17: Erklärte Gesamtvarianz der gewonnenen Faktoren 177 Tabelle 18: Rotierte Komponentenmatrix 178 Tabelle 19: Faktoren, Problemkategorie und Ladung 179 Tabelle 20: Signifikante Korrelationen der Problemkategorien 179 Tabelle 21: Initialisierung Eingabefelder 181 Tabelle 22: Lösungsuche Eingabefelder 183 Tabelle 23: Situationsanalyse Eingabefelder 184 Tabelle 24: Lösungsanpassung Eingabefelder 185 Tabelle 25: Lösungsbewertung Eingabefelder 185 Tabelle 26: Lösungsumsetzung Eingabefelder 186 1 Einleitung „Nur wenn es uns gelingt, das Wissen über Lösungen in bestimmten Prob- lemsituationen, über Vorgehensweisen und mögliche Barrieren sowie über die Wissensträger, deren Bereitschaft und Können zu erfassen, werden wir in Zukunft effizient Probleme lösen können. Dann lernt das Unternehmen als Ganzes aus seinen Problemlösungsprozessen, bildet ein kollektives Ge- dächtnis, erhöht seine Handlungsfähigkeit und -geschwindigkeit und wird so wettbewerbsfähiger.“ Gomez und Probst, 1995 1.1 Problemstellung und Motivation Wettbewerbsvorteile können zukünftig nur durch die Unternehmen realisiert werden, welche es schaffen, schnell auf sich ändernde Marktbedingungen und deren neue Problemstellungen zu reagieren und innovative Problemlösungen für differenzierte Kundenbedürfnisse zu entwi- ckeln (Gomez/Probst /55/). Diese veränderten Rahmenbedingungen stellen neue Anforderungen an die Mitarbeiter und deren tägliche Arbeit. Die Rolle des Mitarbeiters entwickelt sich mehr und mehr von der aus- führenden Stelle hin zum Problemlöser, mit welchem die Innovationskraft und die Leistung des Unternehmens steht oder fällt. Durch die steigende Produktkomplexität wird sich dabei eine starke Verschiebung weg von den einfachen Routineproblemen hin zu komplexen und kreativ-schöpferischen Problemen ergeben (Gomez/Probst /55/,), die einen hohen Wissensanteil verarbeiten und nur noch ver- teilt in interdisziplinären Teams zu lösen sind (Allweyer /6/, Hoffmann/Goesmann et al. /71/). Große Bedeutung kann dem Problemlösungsprozess insbesondere in der Produktentwicklung beigemessen werden, da hier zwar nur 3-10% der Gesamtkosten anfallen, jedoch 70% der späteren Kosten für ein Produkt festgelegt werden (Baur/Ohe /8/, Ehrlenspiel /44/). Entschei- dend für den Erfolg eines Unternehmens sind dabei auch die Produktentwicklungszeiten („time to market“), so kann eine Verzögerung der Entwicklung von sechs Monaten die Kosten um über 50% erhöhen (VDI /161/). Problemlösungsprozesse spielen insbesondere in den frühen Phasen der Produktentwicklung eine große Rolle, da gerade diese durch einen hohen Anteil an komplexer, konzeptioneller Arbeit, einem hohen Anteil der Wissensverarbeitung und –generierung gekennzeichnet sind. Ingenieure müssen die unterschiedlichsten Technologien zu innovativen, funktionierenden Systemen zusammenführen, dafür benötigen sie oft Wissen aus mehreren Fachgebieten und aus verschiedensten Anwendungen (Westkämper /173/). Bedingt durch die zunehmende ver- teilte Entwicklung von Produkten wächst zudem der projektbegleitende Kommunikationsauf- wand mit Entwicklungspartnern, Zulieferern und Kunden erheblich und der Abstimmungsauf- wand sowie die Änderungshäufigkeit steigt enorm. Dies stellt hohe Anforderungen an die an der Produktentwicklung beteiligten Ingenieure. 19 Ein Beispiel aus der Praxis soll dies illustrieren (vgl. Abbildung 1): Bei einem Engineering- Dienstleister sind bei der Produktion von Prototypteilen für einen Systemlieferanten mit dem Vakuumgussverfahren auf der Oberfläche der grauen Abgussteile weiße Flecken entstanden. Das Problem ist zum ersten Mal aufgetreten, sowohl Ursache als auch mögliche Wege zur Lösung des Problems waren den Entwicklungsingenieuren nicht bekannt. Zu Beginn erfolgte eine unstrukturierte und unsystematische Suche nach der Problemlösung, welche die Ausfüh- rung des Kundenauftrags stark verzögerte. Nach einigen ergebnislosen Versuchen, die Proto- typen mit veränderter Materialzusammensetzung ohne Defekt herzustellen, wurde mit den relevanten Partnern im Netzwerk die Veränderung der Prozessparameter im Rahmen eines systematischen Problemlösungsprozesses strukturiert diskutiert. Es ergab sich, dass das Problem aufgrund einer zu hohen Luftfeuchte in der Produktionshalle sowie einer zu heißen Temperatur im Werkzeug entstanden ist. Das Problem konnte schließlich durch eine Reduzie- rung der Werkzeugtemperatur sowie einer Anpassung der Luftfeuchtigkeit in der Fertigungs- halle durch eine Klimaanlage gelöst werden. Abbildung 1: Prozessbeteiligte bei der Problemlösung in der Produktentwicklung am Beispiel der Prototypenbeschaffung Da effiziente und strukturierte Problemlösungsprozesse des Einzelnen eine wichtige Grundla- ge für die Innovationsfähigkeit darstellen, birgt eine Steigerung der Problemlösungsfähigkeit und -kapazität der Ingenieure durch eine schnelle, systematische und methodische Unterstüt- zung des Problemlösungsprozesses ein viel versprechendes Potenzial zur Verbesserung der Qualität der Entwicklungsergebnisse und vor allem zur Beschleunigung des Entwicklungspro- zesses in sich. Doch gerade die Suche nach innovativen Problemlösungen erfolgt oft ineffizient und unsyste- matisch und die im Unternehmen vorhandenen Kreativitätspotenziale werden nur unzurei- chend ausgeschöpft, obwohl die Fähigkeit, Innovationen frühzeitig am Markt zu platzieren, ein wesentlicher Schlüsselfaktor ist. Bisher fanden zudem Problemlösungsprozesse auf der indi- Original Equipment Manufacturer (OEM) Systemlieferant z.B. Cockpit Systemlieferant z.B. Tür Konstrukteur Unternehmen A Werkzeugbauer Unternehmen B Prototypteile- fertigung Unternehmen C Auftragsspezifische temporäre Kooperation Auftrag Komponenten- lieferant z.B. Radio Kooperationsnetzwerk Teilprozess Prototypenfertigung Oberflächendefekt bei Vakuumgußteilen, Ursache und Lösung des Problems unbekannt Problemlösung im Netzwerk Problemlösung im Netzwerk Materiallieferant Hersteller Vakuum- gußanlage 20 viduellen Ebene, deren systematische Gestaltung sowie effizientes Management im Unter- nehmen kaum Beachtung. Vornehmlich standen Aktivitäten zur Gestaltung des Entwicklungs- prozesses im Vordergrund. Für die Unterstützung von Problemlösungsprozessen reichen jedoch die Anstrengungen des Business Process Reengineering bzw. der Geschäftsprozessoptimierung nicht mehr aus. Es wurden bisher unter diesen Begriffen vor allem die Klasse der Prozesse optimiert, die durch wieder verwendbare, deterministische, strukturierbare und formalisierbare Abläufe, bzw. Rou- tineabläufe gekennzeichnet sind und eine geringe Änderungsdynamik aufweisen. In der Regel umfasst dies betriebswirtschaftliche Routineprozesse, Verwaltungsabläufe oder definierte Produktionsprozesse, da hier der Einsatz der erforderlichen Ressourcen - Rohstoff, Arbeit und Kapital - bekannt und vorhersehbar ist. Es fehlt ein Ansatz, der die Ingenieure bei der individuellen oder kooperativen Lösung von Problemen, die im Rahmen der Arbeit im Entwicklungsprozess auftreten, unterstützt. Daher stehen in dieser Arbeit komplexe, wissensintensive und verteilte Problemlösungsprozesse in den frühen Phasen der Produktentwicklung, die nicht über klassische Workflows abgebildet werden können, im Vordergrund. 1.2 Ziel, Innovationscharakter und Nutzen Neuartige Probleme, die sich in ähnlicher Form wiederholen sind bisher nicht als Standardpro- zess festgelegt. Sie können jedoch bei optimaler Gestaltung die operative Innovations- und Leistungsfähigkeit des Entwicklungsingenieurs sowie die Qualität des Ergebnisses der Prob- lemlösung wesentlich beeinflussen. Das Ziel der Arbeit ist es daher, eine Systematik zu entwickeln, welche die verteilte, qualitativ hochwertige Lösung wissensintensiver Probleme von Entwicklungsingenieuren in der Pro- duktentwicklung unterstützt. Damit steht die Gestaltung und Optimierung von Problemlö- sungsprozessen auf der Ebene des Einzelnen sowie die Etablierung eines ganzheitlichen, integrierten Problemlösungsmanagements im Vordergrund. Die zu entwickelnde Systematik dient dem Problemlöser als Assistenzsystem bei der verteilten Lösung von komplexen, wissensintensiven Problemstellungen. Er wird systematisch und strukturiert durch den Problemlösungsprozess geführt und methodisch angeleitet. Er erhält entsprechend der jeweiligen Phase im Problemlösungsprozess aufgabenorientiert und kon- textabhängig Unterstützung bei der Gestaltung der Lösung. Teilziele umfassen • die Entwicklung eines Modells zur Beschreibung und Klassifikation von Problemen in den frühen Phasen der Produktentwicklung • die Ableitung eines Gestaltungsrahmens für − die Organisation von Problemlösungsprozessen (Aufbau- und Ablauforganisati- on) entsprechend den Anforderungen aus der spezifizierten Klassifikation, − Beschreibung von Kommunikations-, Wissens- und Lernprozessen im Problem- lösungsprozess − die organisatorische Integration des Problemlösungsmanagements in beste- hende Geschäftsprozesse • die prototypische Umsetzung der Systematik als Problemlösungsassistent. 21 Im Gegensatz zu bestehenden Ansätzen wird in vorliegender Arbeit das Thema Problemlö- sung sowohl unter individuellen als auch kooperativen Aspekten bearbeitet. Dabei spielen beispielsweise der Wissensaustausch zwischen den Beteiligten und die Kompetenzerweite- rung im Laufe der Problemlösung eine wichtige Rolle. Auswirkungen des Einsatzes eines Problemlösungsmanagements entstehen auch im Bereich der Qualitätssicherung. Es werden daher die Bereiche des Wissens- und Kompetenzmanagements, des Human Resource Mana- gements und des Qualitätsmanagements aufgegriffen und in den Gestaltungsrahmen mit ein- bezogen. Die Verknüpfung zwischen Problemklassifikation und Problemlösung wird als weiteres Allein- stellungsmerkmal angesehen. So bildet die Ermittlung und Klassifikation von real im Arbeits- umfeld auftretenden Problemen die Grundlage für die Entwicklung des Problemlösungspro- zesses, da die Gestaltungselemente aus den empirischen Ergebnissen abgeleitet werden. Neuartig ist weiter die Umsetzung eines Problemlösungsprozesses als Assistenzsystem. Die Bereitstellung eines Assistenzsystem erleichtert die direkte Anwendbarkeit und Integration der in die Prozesswelt. Der Problemlösungsprozess ist jederzeit aus jedem, beliebigen Geschäfts- prozess heraus anwendbar. Der Nutzen einer solchen Systematik liegt vor allem in der Steigerung der Effizienz des Ent- wicklungsprozesses. Denn der gewählte Ansatz fördert die Beschleunigung und Absicherung der Lösung wissensintensiver Probleme und die synergetische Nutzung des kreativen Potenti- als aller am Problemlösungsprozess Beteiligten. Damit dient er einer gezielten, systemati- schen Generierung von Innovationen. Durch die Bereitstellung allen zur Ausführung eines Problemlösungsschrittes notwendigen (Meta-)Wissens und aller Erfahrungen und notwendigen Ansprechpartner können Entschei- dungen fundierter getroffen werden. Damit wird die Handlungs- und Problemlösungskompe- tenz der beteiligten Entwicklungsingenieure erhöht. Die problemorientierte Bereitstellung von Wissen, Ansprechpartnern und Vorgehensweisen trägt zudem sowohl zur Verbesserung bzw. zur Optimierung der Aufgabenbewältigung innerhalb eines bestehenden Problemlösungspro- zesses als auch zum problembezogenen, praxisorientierten Lernen („training on the job“) bei. Durch den Zugriff auf bestehende, dokumentierte Problemlösungen und systematische Vor- gehensweisen zur Problemlösung haben Entwicklungsingenieure die Möglichkeit, in aktuellen Arbeitssituationen effektiver zu (re-)agieren und ihr zukünftiges Handeln besser zu planen (Ruprecht/Rose et al. /126/). Dies erhöht sowohl die Produktivität der Mitarbeiter als auch die Qualität der Ergebnisse. 1.3 Vorgehensweise und Aufbau Der Aufbau und die Vorgehensweise der Arbeit wird durch die Abbildung 2 zusammengefasst dargestellt: Im Kapitel 2 werden die Grundlagen zum Management von Problemlösungsprozessen be- schrieben. Dies umfasst eine Abgrenzung der Begrifflichkeiten sowie eine thematische Ein- ordnung der Arbeit. Auf die Rahmenbedingungen aufbauend werden Anforderungen an eine Systematik zur Gestaltung und Optimierung von wissensintensiven, kooperativen Problemlö- sungsprozessen abgeleitet. Im Kapitel 3 werden bestehende Ansätze zur Problemlösung analysiert, klassifiziert und an- hand der in Kapitel 2 definierten Anforderungen an die zu entwickelnde Systematik bewertet. 22 In Kapitel 4 wird ein inhaltlicher Rahmen für die Gestaltung von wissensintensiven, kooperati- ven Problemlösungsprozessen erarbeitet. Dabei wird zuerst ein Beschreibungsmodell für Probleme entwickelt und empirisch überprüft. Aufbauend auf den empirischen Ergebnissen werden Gestaltungselemente für die Problemlösung abgeleitet. Abbildung 2: Aufbau der Arbeit In Kapitel 5 erfolgt die Entwicklung einer Systematik für die Gestaltung und Optimierung von wissensintensiven, kooperativen Problemlösungsprozessen anhand der im vorhergehenden Kapitel definierten Gestaltungselemente. In Kapitel 6 wird die Erarbeitung eines Konzepts zur informationstechnologischen Realisierung eines Problemlösungsassistenten beschrieben. In Kapitel 7 wird die betriebliche Umsetzung anhand eines Praxisbeispiels veranschaulicht. Das letzte inhaltliche Kapitel fasst die wesentlichen Ergebnisse der Arbeit zusammen und zeigt mögliche Anknüpfungspunkte für weitere Forschungsarbeiten. Zielsetzung Entwicklung einer Systematik zur Gestaltung und Optimierung von wissensintensiven, kooperativen Problemlösungsprozessen in der Produktentwicklung Aufbau der Arbeit Grundlagen zum Management von Problemlösungsprozessen, Ableitung von Anforderungen an die wissensintensive, kooperative Problemlösung Diskussion methodischer Ansätze Problemtypologien Problemprävention Problemlösung Systeme Ableitung eines Gestaltungsrahmens für die wissensintensive, kooperative Problemlösung Beschreibungsmodell für Probleme in der PE Empirsche Validierung der Problemtypen und Hypothesen - Implikationen für die Gestaltung und Optimierung von Problemlösungsprozessen - Ableitung von Gestaltungs- elementen Entwicklung der Systematik zur Optimierung und Gestaltung von wissensintensiven, kooperativen Problemlösungsprozessen Organisation und Koordination von Problemlösungs- prozessen Kommunikation und Wissens- austausch Wissensintegration und Wissens- generierung Softwaretechnische Realisierung eines Problemlösungsassistenten Der Problemlöseassistent in der praktischen Anwendung bei einem mittelständischen Automobilzulieferer 2 Grundlagen zum Management von wissensintensiven, koopera- tiven Problemlösungsprozessen Kapitel 2 gibt eine Einführung in begriffliche Grundlagen für die Gestaltung und Unterstützung wissensintensiver, kooperativer Problemlösungsprozesse sowie in das Management von Problemlösungsprozessen. 2.1 Definition des Begriffs Produktentwicklung Die Produktentwicklung umfasst als Obergriff den Zeitraum von der Ideensuche bis zur Her- stellung eines Produkts (Ulrich/Eppinger /160/). Die frühere Organisation der Produktentwicklung ist sequentiell orientiert, also tayloristisch. Jede Abteilung von Spezialisten löste ihre Aufgabe und gibt sie dann an die nächste Abteilung weiter. Die Entwicklung hin zur integrierten Produktentwicklung steht im klaren Gegensatz dazu und wird von Ehrlenspiel /44/ wie folgt definiert: Bei der integrierten Produkterstellung arbeiten, im Gegensatz zu der konventionellen Produkterstellung, alle am Entstehungsprozess beteiligten Abteilungen und die betroffenen Spezialisten eng und unmittelbar zusammen. Hierbei wird versucht, durch eine gemeinsame Zielrichtung Qualität, Zeiten und Kosten der Produkterstellung und des Produkts positiv zu beeinflussen. Zur Zeiteinsparung wird zusätz- lich eine Parallelisierung von früher sequentiell bearbeiteten Tätigkeiten angestrebt, insbeson- dere die Parallelisierung von Produkt-, Produktion- und Vertriebsentwicklung. Simultaneous und Concurrent Engineering sind Beispiele für eine solche integrierende Vorge- hensweise (Bullinger/Warschat /20/). Für diese Arbeit gilt die Definition in Anlehnung an Siegwart /146/: Produktentwicklung ist die Gesamtheit der technischen, mark- und produktionsorientierten Tätigkeiten einer industriellen Unternehmung, die auf die Schaffung eines neuen oder verbesserten Produkts ausgerichtet ist. 2.2 Inhaltliche Abgrenzung des Wissensbegriffs Der Aspekt Wissen fand in den letzten Jahren zunehmend Berücksichtigung in verschiedenen Managementmodellen. Ziel des Wissensmanagements ist hierbei, Wissen in den Wertschöp- fungsprozess des Unternehmens zu integrieren, um nachhaltige Wettbewerbsvorteile zu errei- chen. Wissensmanagement wird dabei als Konzept gesehen, welches sich mit Möglichkeiten zur Gestaltung, Entwicklung und Lenkung der organisatorischen Wissensbasis befasst (Nona- ka/Takeuchi /106/, North /107/, Probst/Gilbert et al. /118/, Romhardt /125/). Ein häufig gewählter Ausgangspunkt zur Definition des Wissensbegriffs liegt in der Beschrei- bung der Elemente Daten, Informationen und Wissen. Nach Diemer /33/ sind Daten alles, was “wir durch die Reflexion unserer Sinne wahrnehmen”. Daten werden durch Zeichen repräsentiert und sind Gegenstand von Verarbeitungsprozessen (DIN 44300 /35/; Lehner /94/). 24 Informationen sind zweckgerichtet und liefern eine gegenwarts- und praxisbezogene Mitteilung über Dinge (Bullinger /19/), Seiffert /139/). Information ist darüber hinaus auch wissenswert und bedeutungstragend, wie auch aus der Definition des Begriffs von Heinrich & Burgholzer /65/ hervorgeht. Weggemann /171/ und Picot /113/ sehen die Information als die Sammlung von Daten. Informationen werden dabei durch die Bedeutungszuweisung des Menschen er- zeugt, d.h. wenn die Daten in einen Kontext gestellt werden. Eine grundlegende Unterscheidung der Wissensbegriffe lässt sich durchführen, indem Wissen entweder als Objekt oder als Prozess betrachtet wird. Im Kontext der objektorientierten Be- trachtung wird Wissen ähnlich einem Produktionsfaktor als statische Größe angesehen, wel- che das Ergebnis eines Prozesses ist (Keller/Novak /80/, Köck/Ott /89/, Steinmüller /149/, Re- häuser/Krcmar /123/, Strohner /151/, Akkermans /5/). Bei der prozessorientierten Betrachtung wird Wissen wird als ein Vorgang bzw. eine Tätigkeit angesehen. Wissen besitzt einen dyna- mischen Charakter, durch den sich eine Person reale Sachverhalte bewusst macht und ihr Handeln danach ausrichtet (Davenport /27/, Heckert /64/, Kleinhans /87/, Neuweg /103/, No- naka/Takeuchi /106/, North /108/, Romhardt /125/, Weggemann /171/). In beiden Unterscheidungskategorien kommt der handlungsorientierte Charakter von Wissen zum Ausdruck. Die objektbasierte Betrachtung fand vornehmlich in Ansätzen der Informations- technologie Beachtung, während sich die prozessbasierte Betrachtung bei philosophischen, psychologischen und soziologischen Ansätzen durchgesetzt hat. Quinn unterscheidet Wissen in vier Ebenen, die aufeinander aufbauen. Das Know-what stellt Grundlagenwissen im Fachgebiet dar, das Know-how umfasst die Fähigkeit das Fachwissen anzuwenden, das Know-why beschreibt das Verständnis für systemische Zusammenhänge und das Care-why umfasst das selbst initiierte, kreative Handeln (Quinn/Anderson /121/). Nonaka und Takeuchi unterscheiden implizites und explizites Wissen (Nonaka/Takeuchi /106/). Explizites Wissen ist beschreibbares, verbalisierbares, reproduzierbares und zeitlich stabiles Wissen, welches standardisiert, strukturiert und methodisch in sprachlicher Form in Dokumentationen, Datenbanken, Patenten, Produktbeschreibungen, Formeln, aber auch in Systemen, Prozessen oder Technologien angelegt werden kann (Nonaka/Takeuchi /106/, Po- lanyi /115/). Implizites Wissen ist weitgehend aktionsgebunden, kontextspezifisch, persönlich und subjektiv (Nonaka/Takeuchi /106/, Polanyi /115/) und steht in einem bestimmten prakti- schen Kontext. Es muss daher mittels Metaphern, Bildern und Analogien greif- und erfassbar gemacht werden (Jackson Grayson /76/). Die Verknüpfung des impliziten und expliziten Wissens mit der Dichotomie individu- ell/organisational (Romhardt /125/) ergibt folgende Aspekte: Das implizite Wissen des Indivi- duums ist zeitlich und sozial an den Besitzer gebunden und somit privat. Das implizite Wissen der Organisation ist im Gegensatz zum privaten impliziten Wissen des Individuums zur glei- chen Zeit in mehreren Köpfen vorhanden, also kollektiv. Das explizite Wissen des Individuums ist analog zum impliziten Wissen des Individuums privat, wenn es durch Verschluss o. ä. nur für ein Individuum zugänglich ist. Wenn explizites Wissen mehreren Individuen im Unterneh- men zugänglich ist, so ist es kollektiv und der Organisation zugänglich. 25 Abbildung 3: Matrix implizit/explizit vs. individuell/organisational nach /169/, /67/ Weitere dichotomische Unterscheidungen von Wissensarten sind unter anderem bei Bür- gel/Zeller /23/, Kogut/Zander /90/, Zack /178/ zu finden. In dieser Arbeit wird Wissen als Vernetzung von Informationen, bzw. Informationen im Kontext verstanden, welche es dem Träger ermöglichen, Handlungsvermögen aufzubauen und Aktio- nen in Gang zu setzen. Wissen ist daher das Ergebnis der Verarbeitung von Informationen durch das Bewusstsein und kann als ‘verstandene’ Information bezeichnet werden. Wissen ist somit die Gesamtheit der Kenntnisse, Fähigkeiten und Erfahrungen die zur Bewältigung von Aufgaben bzw. zur Lösung von Problemen notwendig ist (Probst /118/). Im Kontext von Problemlösungsprozessen spielt insbesondere das Erfahrungswissen (implizi- tes Wissen) eine große Rolle. Erfahrung ist dabei als ein Prozess des individuellen Erfassens zu verstehen (Wehner/Waibel /172/). Es entsteht über die Anwendung von Konzeptwissen bei der Lösung von Problemstellungen aus der unmittelbaren Unternehmenspraxis (Tritt- mann/Mellis/157/). Erfahrungswissen umfasst im Sinne Polanyis /115/ zudem die Fertigkeiten und die Fähigkeit in einem sozialen System zu handeln, sowie die Beeinflussung der sozialen Regeln durch Reflektion. Erfahrungswissen dient damit als Hintergrundwissen beim Treffen von Entscheidungen und Ausüben von Tätigkeiten im Problemlösungsprozess. Es tritt nur in seiner Anwendung zu Tage und kann im Rahmen der Problemlösung bewusst werden (Expli- kation) bzw. ist für Dritte beobachtbar. Als Erfahrungswissen wird in dieser Arbeit das Wissen bezeichnet, welches durch das indivi- duelle Erleben und Erfahren bestimmter Situationen oder Sachverhalte und deren persönliche Bewertung generiert wird. Die Generierung von Erfahrungswissen und dessen Anwendung auf komplexe Probleme hängt von der Expertise des Einzelnen und der Kombination von dessen Fertigkeiten und schon vorhandenen Erfahrungen ab. 2.3 Definition des Begriffs Kooperation Kooperationen gelten als ein wichtiges Lösungskonzept zur Reduzierung auftretender Prob- leme in den Strukturen von Märkten und Hierarchien (Bullinger/Warschat /21/). Unter Kooperation wird allgemein die (freiwillige) Zusammenarbeit zwischen zwei oder mehre- ren Unternehmen verstanden mit dem Ziel, bei grundsätzlicher Aufrechterhaltung ihrer wirt- schaftlichen Selbstständigkeit gewisse Vorteile aus der Zusammenarbeit zu ziehen (Beiersdorf /25/). Die Kooperation beschreibt daher die freiwillige wechselseitige Verflechtung von Hand- lungsentscheidungen der beteiligten Kooperationspartner (Müller-Stewens/Gocke /101/) und ist durch ein hohes Maß an Interaktionen zur gemeinsamen Zielerreichung zwischen Subjek- ten gekennzeichnet (Schlingmann /131/). implizites Wissen explizites Wissen individuelles Wissen organisationales Wissen z. B. »Bauchgefühl« in neuen Situationen, Erfahrungswissen z. B. gemeinsame Werte, Unternehmenskultur z. B. Wissen über Produkteigenschaften, techn. Fachwissen z. B. festgelegte Prozeßschritte, Unternehmensvision 26 Dabei können nach Sydow /153/ vier Betrachtungsebenen unterschieden werden: Die Umwelt, das Kooperationsnetzwerk selbst, die organisationale Ebene sowie die individuelle bzw. Team-Ebene. Der Kooperationsbegriff in dieser Arbeit konzentriert sich ausschließlich auf die individuelle bzw. Team-Ebene. Im Sinne der Arbeit wird damit unter Kooperation die interdisziplinäre Zu- sammenarbeit von einzelnen Individuen verstanden, die im Rahmen ihrer Interaktion gemein- same Ziele verfolgen. 2.4 Inhaltliche Abgrenzung des Problembegriffs 2.4.1 Problem Heutige Definitionen des Problembegriffs bauen auf der Begriffsbestimmung nach Dewey /30/ auf, welche als eine der ersten modernen Definitionen bezeichnet werden kann. Vogt definiert ein Problem als Unzufriedenheit mit einer bestimmten Situation (Vogt /165/). Dabei handelt es sich beispielsweise - um ein undifferenziertes Unbehagen über einen bestimmten Zustand - um die Chance, einen bisher befriedigenden Zustand in einen noch besser einge- schätzten überführen zu können - um unbeantwortete Fragen bzw. einen bestimmten Wissenstand, der verbessert wer- den soll. Demzufolge nach sind Probleme nicht einfach naturgegeben, sondern entstehen durch die (Be-)Wertung bestimmter Situationen und Zustände. Ein Problem ist nach Strauß/Kleinmann /150/ dagegen gegeben, wenn es eine Schwierigkeit zwischen einem Ziel und den verfügbaren Mitteln zur Verwirklichung des Zieles gibt. Neuere Definitionen ordnen dem Begriff Problem drei Komponenten zu: einen Anfangszu- stand, auch Ist-Zustand genannt, einen Endzustand bzw. einen Soll-Zustand sowie eine im folgenden beschriebene dritte Komponente (Daenzer/Huber et al. /24/, Dörner /41/, Kersting /81/, Sell /141/, Vogt /165/). Abbildung 4: Problemdefinition nach Autoren Dörner /41/ bezeichnet diese dritte Komponente als Barriere, welche die Transformation vom unerwünschten Anfangszustand in den erwünschten Endzustand verhindert. Kersting /81/ in- IST-Zustand SOLL-Zustand Barriere Trans- formation Differenz Dörner Sell Daenzer Problem im weiteren Sinne Kersting Bezeichnungsweisen der dritten Komponente innerhalb der Problemdefinition nach Autoren 27 terpretiert diese Barriere sogar als Problem im weiteren Sinne. Nach Sell /141/ ist die dritte Komponente die Transformation als Weg vom Anfangszustand in den Endzustand. Die dritte Komponente ist nach Haberfellner /24/ die Differenz zwischen einem vorhandenen Ist-Zustand einerseits und der Vorstellung eines Soll-Zustandes andererseits. Aus dieser Differenz entstehen die Anforderungen, die das Problem an den Problemlöser stellt. Für die vorliegende Arbeit stellt sich eine Situation für ein Individuum dann als Problem dar, wenn es eine Differenz zwischen einem unerwünschten gegenwärtigen oder prognostizierten Ist-Zustand und einem erwünschten Soll-Zustand feststellt (wobei bezüglich Soll- und Ist- Zu- stand nur vage Vorstellungen vorhanden sein können) und die Transformation des Ausgangs- zustands in den Zielzustand unklar ist. 2.4.2 Problem vs. Aufgabe Aufgaben sind nach Dörner /41/ geistige Anforderungen für deren Bewältigung Methoden be- kannt sind. Eine Aufgabe erfordert reproduktives Denken, d.h. es erfolgt ausschließlich die Anwendung bekannter und bereits angewandter Lösungsmethoden. Im Duden wird ein Problem als eine Schwierigkeit oder eine zu lösende Aufgabe respektive Fragestellung betrachtet, die Bekanntheit der Lösungsmethoden wird hierbei nicht berücksich- tigt. Nach Ninck /104/ besteht ein Problem, wenn sich ein Individuum in einem äußerem oder inne- rem Zustand befindet, den es nicht für wünschenswert hält, aber im Moment nicht über Mittel verfügt, den unerwünschten Zustand in einen wünschenswerten Zielzustand zu überführen. Nach Sell/Schimweg /142/ ist bei einem Problem im Gegensatz zu einer Aufgabe produktives Denken erforderlich, um von einem Ist-Zustand zu einem Soll-Zustand zu gelangen. Bielenberg /11/ stellt fest, dass bei komplexen Problemstellungen einzelne Mitarbeiter nicht mehr in der Lage sind, das Problem adäquat zu beurteilen und die Summe der problemrele- vanten Informationen zu bewerten. Daher sind seiner Ansicht nach multipersonale Vorge- hensweisen der kreativen Problemlösung zu entwickeln. Bei einer Aufgabe ist nach Schroda /135/ eine Suche nach geeigneter Transformation nicht erforderlich, die Transformation ist vielmehr direkt aus dem vorhandenen Wissen einer Person abrufbar. Die benötigten Mittel, Methoden für die Bewältigung der Aufgabe sind bekannt, der Bearbeiter geht aufgrund eigener Erfahrungen routinemäßig vor. Das Ergebnis einer Aufgabe ist klar, und eine Aufgabe ist in einem kalkulierbarem Zeitraum und Aufwand lösbar. Im Ge- gensatz dazu besteht bei einem Problem ein unerwünschter Ausgangszustand, der in einen Zielzustand überführt werden muss, der Bearbeiter jedoch noch nicht weiß, mit welchen Mit- teln das Problem zu lösen ist und wie das Ergebnis überhaupt aussehen soll. Auch hier wird festgestellt, dass ein Problem nur durch produktives Denken lösbar ist, d.h. die Beteiligung generalisierbaren heuristischen Wissens sowie zusätzlicher Erwerb problemspezifischen Wis- sens ist dazu notwendig, ansonsten liegt eine Aufgabe vor. Zusammenfassend erfordert ein Problem produktives Denken, da etwas Neues geschaffen werden muss. Aufgaben hingegen erfordern nur reproduktives Denken, da bei Aufgaben der Lösungsweg bekannt ist. Aufgaben werden durch ausreichende Erfahrungen routiniert gelöst, sind in einem kalkulierbaren Zeitraum und Aufwand lösbar, und das Ergebnis ist klar. Die Vor- 28 erfahrungen legen fest, ob es sich für den Einzelnen um ein Problem oder eine Aufgabe han- delt. 2.4.3 Symptom und Ursache Symptome sind nach Franke /45/ Anzeichen für Probleme, jedoch nicht Probleme im engeren Sinn. So bedeutet ein Symptom zu behandeln nicht gleichzeitig ein Problem zu lösen. Daher ist es notwendig zwischen Symptom, als allgemeine Zustandsabweichung und Problem zu differenzieren. Nach Gomez/Probst /55/ ist die „... Unterscheidung zwischen Symptom und Problem grundlegend für den ersten Schritt des Problemlösungsprozesses. Sie wird das Vor- gehen entscheidend prägen“. Dies bedeutet, dass im Rahmen der ersten Schritte der Prob- lemlösung sowohl die Erfassung von Symptomen als auch deren Rückführung auf mögliche Gründe für das Erscheinen des Problems erfolgen muss. Im Zuge der Rückführung von Symptomen kommt es zumeist zur Identifikation der Relationen, die als potenzielle Auslöser für ein Problem in Frage kommen (beispielhaft sei hier auch die Anwendung der FMEA-Methode genannt). Diese werden als Ursachen bezeichnet. In der Re- gel kommt nur eine begrenzte Anzahl möglicher potentieller Ursachen als eigentliche Auslöser eines Problems in Frage. Um diese zu ermitteln, kann eine Herausarbeitung der Vernetzung zwischen den Ursachen nützlich sein (beispielhaft sei hier die Anwendung der Methode zur Vernetzung von Einflussfaktoren genannt). 2.5 Inhaltliche Abgrenzung des Prozessbegriffs 2.5.1 Prozess Der Begriff „Prozess“ stammt von dem lateinischen Wort „procedere“ ab, was soviel wie „vor- wärts schreiten“ bedeutet /88/. Dieses „vorwärts schreiten“ kommt in der heutigen Definition der ISO 9000-1 noch zum Ausdruck. Dort heißt es: „Der Prozess selbst ist (oder sollte sein) eine Umwandlung, die Wert hinzufügt“. „Die Ergebnisse sind Produkte, materielle oder imma- terielle,“ die das Ergebnis einer menschlichen Handlung oder eines technischen Vorgangs sind /38/. Anders ausgedrückt, laut ISO 9000 ist ein Prozess ein „Satz von in Wechselbezie- hung oder Wechselwirkung stehenden Tätigkeiten, der Eingaben in Ergebnisse umwandelt.“ (DIN EN ISO 9000/37/). Unter einem Prozess wird in dieser Arbeit eine Folge von Handlungen, Teilschritten, Aufgaben oder Aktivitäten verstanden, die in einer bestimmten kausal-zeitlichen Beziehung zueinander stehen (Binner /12/, Scheer /130/) Hierbei kann die Abwicklung der Aufgaben über mehrere organisatorische Einheiten verteilt sein (Vogt /165/). Das Ergebnis der Wertschöpfung eines Prozesses ist die Leistung. Die relevanten Aufgaben (Aktivitäten) eines Prozesses werden in eine Ablauffolge gebracht, die eine Aufgabenkette bilden. So genannte Ereignisse sind in der Regel die Auslöser für Aufgaben. Prozessvariablen und Indikatoren nach Schwarz /138/ sind hierbei: − Komplexität: Zahl der Teilaufgaben, Anordnung der Teilaufgaben (sequentiell, parallel), Abhängigkeiten und Rückkopplungsbedarf, Rollen der involvierten MA − Grad der Veränderlichkeit: Wiederholungshäufigkeit ohne Strukturveränderungen, Planbar- keit der Kommunikation während der Informationsbeschaffung, Offenheit des Prozesser- 29 gebnisses, Änderungsanfall bedingt durch organisationsinterne bzw. –externe Anforderun- gen − Detaillierungsgrad: Möglichkeit der Zerlegung des Gesamtprozesses in einfache Teilschrit- te, Eindeutigkeit des erforderlichen Inputs, der Transformationsschritte und des Outputs − Grad der Arbeitsteilung: Anzahl der am Prozess beteiligten Mitarbeiter, Koordinationsbedarf des Gesamtprozesses − Interprozessverflechtung: Schnittstellen zu anderen Prozessen, Gemeinsame Datennut- zung mit anderen Prozessen, Prozesshierarchie (Beitrag zu über-, unter-, neben-, vor-, nachgelagerten Prozessen) Innerhalb eines Unternehmens laufen eine Vielzahl an Prozessen ab, die über Aufgaben ab- gewickelt werden, in denen Probleme auftreten können. Im Rahmen dieser Arbeit wird der Problemlösungsprozess damit als Unterstützungsprozess betrachtet. 2.5.2 Wissensintensive Prozesse und Tätigkeiten Während bei den klassischen operativen Prozessen meist der Ablauf im Vordergrund steht, so sind wissensintensive Prozesse bei der Leistungserstellung stark auf Wissen angewiesen und verarbeiten im Rahmen der Prozessdurchführung einen hohen Wissensanteil (Allweyer /6/, Hoffmann/Goesmann et al /71/). Dieser Prozesstyp ist dabei gekennzeichnet durch (Hoff- mann/Goesmann et al /71/; Davenport /26/): − unplanbare Wissensbedarfe und häufige Anpassungserfordernisse (dynamisch, flexibel) − Vielfältigkeit und Ungewissheit bzgl. In- und Output (unsicher) − flexible, ad-hoc Abläufe (spontan) − unstrukturierte und individualisierte Arbeitsregeln und Routinen (individuell) − unterschiedliche, zum Modellierungszeitpunkt nur teilweise vorherzusehende Ergebnisse (nicht-deterministisch) − starken Wissenstransfer zwischen beteiligten Personen und Geschäftsfällen (kommunika- tiv, kooperativ) − hohes Maß an individuellen Fähigkeiten und Expertise, sowie hohe Mitarbeiterautonomie bzw. Entscheidungsspielräume der Mitarbeiter (kreativ) Es werden folgende Typen von wissensintensiven Prozessen unterschieden (Remus /124/): − Wissensintensiver, operativer Geschäftsprozess: Bei der Leistungserstellung ist dieser Pro- zesstyp sehr stark auf Wissen angewiesen und verarbeitet im Rahmen der Prozessdurch- führung einen hohen Anteil an Wissen. − Wissensprozess als sekundärer Unterstützungsprozess: Dieser Prozesstyp unterstützt und regelt den Wissensfluss zwischen verschiedenen wissensintensiven operativen Geschäfts- prozessen. − Wissensprozesse: Wissensprozesse werden als Abfolgen von Aktivitäten verstanden, die dazu führen, dass Wissen bei der Bearbeitung von Geschäftsprozessen nutzbringend ein- gesetzt wird, d.h. entwickelt, genutzt, verteilt, gesichert, wieder verwendet oder evaluiert wird. „Wissensprozesse erzeugen ebenso wie Geschäftsprozesse Zwischenergebnisse und können in Teilaktivitäten zerlegt werden. ... Als Ergebnis liefern Wissensprozesse einen 30 Mehrwert für die Geschäftsprozessbearbeitung, bspw. durch die Einsparung der Ressour- cen in Folge der Wiederverwendung von Wissen, durch die Erhöhung der Produktquali- tät.....“ (Hoffmann /71/). Hoffmann /71/ definiert neben den Wissensprozessen noch zwei weitere sekundäre Prozesse: − Prozesse zur kontinuierlichen Pflege der organisationalen Wissensbasis: Diese Art Prozess sorgt für die Entwicklung und Pflege der Ressourcen für die Wissensarbeit in Geschäfts- prozessen, z.B. Aktualisierung vorhandener Wissensressourcen. − Metaprozesse: Metaprozesse umfassen die Gestaltung der Medien, durch die organisatori- sche, technische und informatorische Ressourcen der Wissensarbeit vermittelt werden, z.B. Softwareentwicklungs- und Einführungsprozesse, Organisations- und Personalentwick- lungsprozesse. Wissensintensive Tätigkeiten sind Aktivitäten eines wissensintensiven Prozesses und sind vornehmlich abhängige Tätigkeiten, d.h. die Tätigkeitsabarbeitung ist von der Interaktion mit anderen abhängig, bzw. sequentiell abhängige Tätigkeiten, d.h. die Tätigkeitsabarbeitung ist nur in bestimmter Reihenfolge in der Interaktion mit anderen möglich (vgl. dazu auch Petkoff /112/, der dies allerdings nur auf Entscheidungen bezieht). Wissensintensive Tätigkeiten innerhalb des Problemlösungsprozesses werden nach Fuchs /50/ nicht durch das System bestimmt, so dass die Kontrolle über den Arbeitsablauf vollständig bei den beteiligten interagierenden Personen liegt. Typische Merkmale von wissensintensiven Tätigkeiten nach Schwarz /138/ sind: − Unvorhersehbare Verhaltensmuster, d.h. vielfältige und stark ad-hoc entstehende Verhal- tensmuster und Vorgehensweisen (d.h. es sind situativ definierbare Prozessmuster erfor- derlich, ggf. die Definition von sehr groben Standardvorgehensmustern bzw. Checklisten) − Kommunikationsorientiert, d.h. variable Kommunikationsnetzwerke mit vielfältigem Medien- einsatz − Interdisziplinär, d.h. Expertise vieler Fachrichtungen und Unternehmensbereiche ist erfor- derlich. − Informationslastig, d.h. Verarbeitung großer Mengen von Informationen und Dokumenten − Argumentationsbasiert, d.h. kontinuierliches Argumentieren und Verhandeln entlang, Kern- fragen, Handlungsoptionen, etc. − Iterativ, d.h. zyklische und inkrementelle Bearbeitung. 2.5.3 Problemlösungsprozess vs. Entscheidungsprozess Die Überwindung des Problems im weiteren Sinne oder der Prozess, der notwendig ist, um von einem gegebenen Ist-Zustand zu einem Soll-Zustand zu gelangen wird als Problemlösen bezeichnet (Beiersdorf /9/, Dörner /41/, Vogt /165/). Dieser zur Lösung eines Problems zu durchlaufende Problemlösungsprozess besteht aus Teilprozessen, diese wiederum aus einer Folge von Aktivitäten, Tätigkeiten und Handlungen, die in einer bestimmten kausal-zeitlichen Beziehung zueinander stehen. Die Tätigkeit ist dabei nach Vogt die Realisierung einer Aufgabe bzw. die Lösung eines Problems (Vogt /165/). Sell/Schimweg /142/ sprechen von Operatoren, um die allgemeine Form der Handlung, die den Ist-Zustand in den Soll-Zustand überführt (Was muss getan werden?), zu beschreiben. 31 Die konkrete Umsetzung der Handlung geschieht durch Operationen (Wie muss es getan wer- den?). Sachverhalte, Operatoren und das Zusammenwirken von beidem stellen den Realitäts- bereich von Problemlösungen dar. Ausgehend von der Gleichartigkeit der geistigen Operationen bei Entscheidungs- und Prob- lemlösungsprozessen finden sich in der Literatur meist ähnliche Ablaufschemata. In der Regel werden die Begriffe Entscheidungsprozess und Problemlösungsprozess synonym verwendet, nur wenige Autoren verwenden dieses Begriffe unterschiedlich (Kirsch /84/ „Entscheidungs- prozesse“, Girgenson /54/ „Entscheidungen“). Der Unterschied zwischen Problemlösungsprozess und Entscheidungsprozess kann wie folgt beschrieben werden: Eine Entscheidung verlangt definitionsgemäß wenigstens zwei Hand- lungsalternativen, während für die Existenz eines Problems eine Alternative als ausreichend angesehen wird (Girgenson /54/). Girgenson /54/ betont einen weiteren möglichen Unterschied: Entscheidungsprozesse können auch in Gang gesetzt werden, ohne dass eine Entscheidung getroffen, d.h. das Ende des Ent- scheidungsprozesses erreicht wird. Insbesondere in schlecht strukturierten, bzw. schlecht de- finierten Entscheidungssituationen sind Verhaltensweisen wie Prozessabbruch oder Neudefi- nition der Entscheidungssituation denkbar. Im Unterschied dazu weist der Terminus Problem- lösungsprozess auf einen Prozessabschluss, d.h. die Lösung des vorliegenden Problems, hin. Im Rahmen der Prozessbetrachtung erscheinen die Unterschiede zwischen diesen beiden Begriffen unerheblich, so dass an dieser Stelle der gängigen synonymen Begriffsverwendung gefolgt wird. Petkoff /112/ dagegen sieht unter dem Begriff Entscheidung nicht nur die Auswahl von Hand- lungsalternativen bei der Problemlösung, sondern auch deren Vorbereitung. Damit wird der Entscheidungsbegriff auch auf den im Zeitablauf davor oder simultan stattfindenden Wissens- akquisitionsprozess erweitert. Der Entscheidungsprozess ist in diesem Fall eingebettet in ei- nen verallgemeinerten Problemlösungsprozess. In dieser Arbeit wird der Begriff Entscheidung im Sinne der klassischen Entscheidungstheorie verstanden, nämlich als Wahlakt zwischen Verhaltensalternativen. 2.5.4 Wissensintensive, kooperative Problemlösungsprozesse Der Problemlösungsprozess kann entsprechend der Definition des Problembegriffs und der Definition eines wissensintensiven Prozesses als wissensintensiv angesehen werden. Denn zur Lösung wird umfangreiches Wissen benötigt (Wissensinduktion) und ein Großteil dieses Wissens muss durch produktives Denken neu entwickelt werden (Wissensentwicklung), da die Lösung keinem gängigen Lösungsweg folgt. Auch Franke /45/ sieht den Wissensaspekt als zentralen Baustein bei der Problemlösung. Er sieht in einem Problem eine bestehende Wissenslücke, die eine Veränderung verhindert. Wis- sen bzw. ein Wissensdefizit wird hier als Problemursache identifiziert. Aber Wissen ist zugleich auch die Voraussetzung für die Problemlösung. So wird von Hussy beim Lösen von Problemen die Entwicklung von Wissen als grundlegende Voraussetzung anerkannt, da es sich ansonsten um kein wirkliches Problem handelt (Hussy /75/) Damit erhöht Wissen die Problemlösungsfähigkeit der Akteure (Primus /117/). Insbesondere komplexe Probleme im Entwicklungsbereich sind nur noch verteilt in interdis- ziplinären Teams zu lösen. So ist Frankenberger /46/ der Ansicht, dass es kaum ein Problem gibt, das in völliger Abgeschiedenheit von einem Konstrukteur oder Ingenieur unabhängig von 32 Kollegen bearbeitet werden kann. Im Vergleich zu der von einem einzelnen Individuum durch- geführten Problemlösung werden der Problemlösung in Teams nach Franke /45/ zudem Leis- tungsvorteile, wie beispielsweise ein größeres Wissensspektrum oder eine höhere Problemlö- sewahrscheinlichkeit durch die Problembetrachtung durch verschiedene Disziplinen und Sicht- weisen, zugesprochen. Auch Schlingmann betont den positiven Einfluss von kooperativen Interaktionssituationen bei der mehrpersonalen Problemlösung insbesondere auf die Problem- lösequalität (Schlingmann /131/). Im Rahmen der Arbeit ist unter einem wissensintensiven, kooperativen Problemlösungspro- zess ein Prozess zu verstehen, der zur Lösung eines Problems auf individueller Ebene dient. Dieser Prozess ist durch einen hohen Wissensbedarf und ein hohes Maß an zu verarbeiten- den und zu generierenden Wissens gekennzeichnet und die Erarbeitung der Problemlösung erfordert die interdisziplinäre Zusammenarbeit zwischen verteilten Experten. 2.6 Anforderungen an die Gestaltung wissensintensiver, kooperativer Problemlö- sungsprozesse Wissensintensive, kooperative Problemlösungsprozesse stellen besondere Anforderungen an deren organisatorische sowie informationstechnologische Gestaltung und Optimierung, welche im folgenden diskutiert werden. − Ausrichtung der Problemlösung an praxisorientierten Problemen im Arbeitsumfeld in der Produktentwicklung (A1) Um reale, im Arbeitsumfeld auftretende Probleme strukturiert lösen zu können, ist eine Ver- knüpfung zwischen den Problemtypen und dem Problemlösungsprozess erforderlich. Dies bedeutet, dass die Charakteristiken der verschiedenen, in der Praxis relevanten Problem- klassen, die in den frühen Phasen der Produktentwicklung auftreten, und deren Anforde- rungen an die Problemlösung Berücksichtigung bei der Entwicklung des Ansatzes zur Ges- taltung von Problemlösungsprozessen finden müssen. − Verwendung eines breiten Problembereichs mit Fokus auf komplexe, unstrukturierte Probleme (A2) Ziel der Arbeit ist es, den Problemlöser nicht nur bei der Lösung von konstruktiv- schöpferischen Problemen sondern bei Problemen in allen Bereichen seiner täglichen Ar- beit in der Produktentwicklung zu unterstützen. Dies betrifft sowohl organisatorische als auch technische Probleme. Entsprechend des definierten Problembegriffs liegt dabei der Fokus der Arbeit auf komplexen Problemen, deren Lösung nur unter hohem Wissensein- satz möglich ist (die Ziele und Mittel zur Lösungserreichung sind unscharf bzw. unbekannt). − Orientierung am individuellen bzw. teamorientierten Problemlösen (Mikro-Logik) (A3) Wesentlicher Betrachtungsgegenstand dieser Arbeit ist die Problemlösung auf der Ebene des Individuums als Mikro-Logik. Die zu entwickelnde Systematik muss dabei sowohl die Problemlöseschritte des einzelnen Problemlösers als auch die kooperative, verteilte Lösung von Problemen im Team unterstützen. − Assistenz bei der Führung durch den Problemlösungsprozess (A4) Der Strukturierungsgrad des Prozesses ist für die Art der Unterstützung wesentlich. Bei stark strukturierten Prozessen ist eine aktive Unterstützung durch das System im Sinne ei- nes Workflow Management sinnvoll. Im Gegensatz dazu ist bei schwach strukturierten Pro- zessen wie bei wissensintensiven Problemlösungsprozessen in den frühen Phasen der Produktenstehung ein Assistenzsystem ohne aktive Steuerung des Prozesses erforderlich 33 (Dieffenbruch /32/). Ziel ist, dass der Problemlöser strukturiert durch den Problemlösungs- prozess geführt und zur Lösung seines Problems angeleitet wird. − Berücksichtigung und Bereitstellung von Metawissen (A5) Die Beschleunigung des Wissensverfalls nimmt zu, 90% des derzeit relevanten Wissens wurden in den letzten 20 Jahren geschaffen (Primus /117/). Deshalb wird ein direkter Zugriff auf Problemlösungswissen selbst, im Sinne von Expertensystemen, nicht als sinn- voll erachtet. Im Gegensatz zu einer solchen Anhäufung von Wissen soll vielmehr die Be- reitstellung von Metawissen bzw. die flexible Verfügbarkeit und Anwendung von Wissen im Mittelpunkt stehen. − Kontext- bzw. aktivitätsbezogenes Wissensangebot (A6) Der Problemlöser muss durch das System bei der Durchführung eines Problemlösungspro- zesses kontextabhängig unterstützt werden. Dazu muss genau das Wissen zur Verfügung gestellt werden, welches zur Bearbeitung eines Problemlösungsprozesses bzw. eines Problemlösungsschrittes notwendig ist (Dieffenbruch /32/, Remus /124/). Im Rahmen eines Problemlösungsschrittes können dies beispielsweise Problemlösestrategien, strukturierte Vorgehensweisen und Hilfsmittel bzw. Werkzeuge sein. − Berücksichtigung verschiedener Expertisestufen (A7) Nach Dreyfus/Dreyfus /43/ erbringt das Individuum die aktuell bestmöglichen Leistungen jeweils auf der ihm angemessenen Stufe. Entsprechend seiner Expertenstufe nimmt das Individuum seine Aufgabe und/oder die Modalitäten seines Entscheidungs- bzw. Problem- lösungsprozesses jeweils in einer qualitativ anderen Weise wahr. − Unterstützung kooperativer Abstimmungs- und Kommunikationsprozesse (A8): Je nach ihren Eigenschaften erfordern verschiedene Prozesse unterschiedliche Funktionen und Mechanismen zur Kooperation, Kommunikation und Koordination. Eine Unterstützung kooperativer Problemlösungsprozesse sollte daher unterschiedliche Informations- und Kommunikationsmedien und entsprechende Möglichkeiten zur Navigation und Suche für die verteilte Problemlösung bereitstellen (Dieffenbruch /32/). − Beitrag zur Qualitätssicherung (A9) Der Problemlösungsprozess ist ein sehr dynamischer, komplexer Prozess, in welchem die einzelnen Prozessschritte iterativ und zyklisch abgearbeitet werden. Daher ist eine Quali- tätssicherung über ein entsprechendes Reifegradmodell mit definierten Quality Gates sinn- voll. − Verknüpfung von Problemprävention und Problemlösung zu einem ganzheitlichen Problemlösezyklus (A10) Ein durchgehender Problemlösezyklus von der Beurteilung und Einschätzung möglicher auftretender Probleme über die Unterstützung der Problemlösung bis zur Umsetzung durch Maßnahmen sowie deren Bewertung unter Einbeziehung der in der Präventionsphase ge- troffenen Aussagen ist die Basis eines ganzheitlichen Problemlösungskonzepts. − Integration der Problemlösungsprozesse in die Prozesswelt (A11) Ziel der Systematik ist es, Probleme in Aufgaben zu transferieren, damit die Fortführung der Geschäftsprozesse gewährleistet werden kann. Um den erarbeiteten Lösungsweg in eine Problemlösung zu transferieren und diese schließlich nachhaltig in die Abläufe des Unter- nehmens zu integrieren, muss eine Einbindung des Problemlösungsansatzes in die beste- hende Prozesswelt sowie in die bestehenden Unternehmensstrukturen erfolgen. 3 Stand der Forschung: Ansätze und Methoden zur Problemlö- sung Dem Problemlöser stehen etliche formal differierende Schemata und Ansätze zur Problemlö- sung zur Verfügung. Diese beschreiben entweder die Typologisierung und Klassifikation von Problemen oder die Phasen im Prozess der Lösungsfindung. Bei den prozessorientierten An- sätzen wiederum können Ansätze zur Problemprävention und zur Problemlösung unterschie- den werden. Abbildung 5: Ansätze und Methoden zur Problemlösung In diesem Kapitel wird eine Übersicht über die für die Arbeit relevanten Ansätze gegeben, wel- che dann im Hinblick auf die in Kap. 2.6 definierten Anforderungen bewertet werden. 3.1 Ansätze zur Typologisierung und Klassifikation von Problemen Um allgemeingültige Aussagen über die Vielzahl unterschiedlicher Probleme treffen zu kön- nen, ist es notwendig, diese zu typologisieren, bzw. zu klassifizieren und diese Unterschiede zu beschreiben (Schroda/135/). Unter einer Klassifikation von Problemen wird in dieser Arbeit die Einordnung in Klassen auf der Basis definierter Merkmale und ihre ähnliche bzw. unähnli- che Einstufung verstanden. Einige häufig zitierte und relevante dichotomische Gliederungskriterien werden an dieser Stel- le in Anlehnung an Brauchlin/Heene /16/ angeführt: − Gut vs. schlecht strukturiert: Es kann, je nach Art und Umfang der zu Beginn des Problem- lösungsprozesses zur Verfügung stehenden Informationen, zwischen gut und schlecht strukturierten Problemen unterscheiden werden. Im Gegensatz zu schlecht strukturierten Problemen enthalten gut strukturierte Probleme bereits alles zur Problemlösung notwendi- ge Wissen. − Einfach vs. komplex: Bei der Unterscheidung zwischen einfachen, komplexen und äußerst komplexen Problemen wird die Anzahl der bei der Problemlösung zu berücksichtigenden Variablen und die Anzahl deren Verknüpfungen betrachtet. Problemprävention Problemlösung Problemtypologie und -klassifikation Systeme zur Unterstützung der Problemlösung 35 − Repetitiv vs. neuartig: Entsprechend der Häufigkeit oder Wiederholbarkeit des Auftretens der Probleme unterscheidet man zwischen repetitiven und neuartigen bzw. innovativen Problemen. − Offen vs. geschlossen: Bei offenen Problemen müssen alle Kriterien, welche die Lösung eines Problems bewerten, generiert werden. Im Gegensatz zu offenen Problemen sind ge- schlossene Probleme solche, bei denen klar definiert ist, wann das Problem gelöst ist. Miller /99/ unterscheidet Aufgaben nach Funktion, Inhalt Bedingungen und Übungsgrad (im Sinne von Eingangsvoraussetzungen). Von Johnson /77/ werden Charakteristika wie Komple- xität, Bekanntheit, Abstraktheit und Einbettung genannt. Bourne/Ekstrand et al. /15/ verwen- den bereits drei Dimensionen zur Klassifizierung von Problemen: 1. Klarheit der Zieldefinition 2. Vorhandensein einer oder mehrerer Lösungen 3. Abruf oder Erzeugung der Lösung. Für Sydow /152/ stehen voneinander abgrenzbare Teilprobleme mit ausreichender Formali- sierbarkeit im Mittelpunkt der Betrachtung. Dabei unterscheidet er zwischen Transformations-, Kompositions- bzw. Dekompositions- und Klassifikationsproblemen. Sell /141/, Kersting /81/, Beiersdorf /9/ und Vogt /165/ unterscheiden in Anlehnung an Dörner /41/ zwischen Problemen deren Lösungsweg unbekannt ist und denen, deren Lösungsweg bekannt ist. Die Klassifikation von Problemen nach Dörner beruht auf Typen von Barrieren, die die Trans- formation des Ausgangszustands in den Endzustand verhindert. Dabei ergibt sich eine Typi- sierung von Problemen aus der Differenzierung des Zielzustandes einerseits und der Be- kanntheit der Mittel andererseits (Dörner /41/, Sell/Schimweg /142/, vgl. Abbildung 6). So besteht bei der Klarheit über das angestrebte Ziel und Bekanntheit der zur Lösung verfüg- baren Mittel ein klar definiertes, strukturiertes analytisches (Sell/Schimweg /142/) bzw. Interpo- lationsproblem (Dörner /41/). Bei Arbeiten mit diesen Problemen steht meist die Analyse des kognitiven Problemlösungsprozesses im Vordergrund (Schaub/Reiman /129/). Bei Interpolati- onsproblemen geht es lediglich darum, die richtige Kombination oder Folge aus einer Reihe bekannter Operationen zu bilden (Dörner /41/). Weniger gut definierte bzw. unstrukturierte Problemtypen sind synthetische und dialektische Probleme sowie die Kombination beider Ty- pen. Bei den synthetischen Problemen sind die Ziele klar definiert und die verfügbaren Mittel entweder völlig unbekannt oder nur ungenügend bekannt. Hauptaufgabe ist die Findung oder Synthese eines brauchbaren Bestandes von Operationen bzw. Mittel. Dialektische Probleme liegen vor, wenn die Zielvorgaben unscharf aber die Kenntnis der Mittel vorhanden ist. Dialek- tische und synthetische Probleme liegen vor, wenn sowohl Unklarheit über die Ziele als auch die verfügbaren Mittel besteht. Fricke /49/ überträgt diesen Ansatz auf Konstruktionsaufgaben (vgl. ebenfalls Abbildung 6). Zur genaueren Beschreibung von Problemen verwendet Dörner /41/ die Kriterien Komplexität, Intransparenz, Vernetztheit, Eigendynamik, Polytelie, Unbestimmtheit und Grad des Vorhan- denseins freier Komponenten. 36 Abbildung 6: Problemtypen (vgl. Sell/Schimweg /142/; Dörner /41/; Fricke /48/,/49/; Kersting /81/) Die klassische Problemlösungsforschung beschäftigte sich bisher überwiegend mit Interpolati- onsproblemen wie bspw. dem Turm von Hanoi (Kersting /81/, Klauer /85/). Analytische Prob- leme oder Interpolationsprobleme sind vorwiegend aus der Mathematik bekannt. Sie werden auch als künstliche Probleme bezeichnet, da es diesen an Alltagsnähe fehlt und sie zu stilisiert und zu akademisch sind (Dörner /41/, Kersting /81/). In der Problemlöseforschung erfolgte in der letzten Zeit ein Schwerpunktwechsel weg von In- terpolationsproblemen hin zu synthetischen und/oder dialektischen Problemen (Kersting /81/). Erst seit der Verfügbarkeit von Computersimulationen wurde die Erforschung menschlichen Verhaltens in synthetischen und/oder dialektischen Problemsituationen möglich. Wie bereits erwähnt schreibt die Literatur den synthetischen und/oder dialektischen Problemen die Praxis- nähe zu. Diese Problemtypen werden von der Literatur auch als komplexe Probleme bezeich- net (Kersting /81/; Dörner /41/). Synthetische Probleme liegen bei einem Großteil der Denksportaufgaben vor. Dialektische Probleme sind in der Regel in komplexen Problemsituationen anzutreffen, wie z.B. bei der Teamarbeit zur Bewältigung von Ingenieuraufgaben (Sell/Schimweg /142/).Fricke /49/ hat die- sen Ansatz später auf Begriffe aus der Konstruktionstätigkeit übertragen. Altshuller /155/ teilt Probleme in 5 Problemklassen: Klasse 1: Probleme, deren Lösung durch Methoden erhalten wird, die im eigenen Umfeld be- kannt sind, es bedarf keiner Erfindungen. Klasse 2: Probleme, deren Lösung in kleinen Verbesserungen eines bestehenden Systems besteht. Es werden in dem Umfeld gängige und im Betrieb bekannte Methoden eingesetzt. Klasse 3: Probleme, deren Lösung grundsätzliche Verbesserungen eines bestehenden Sys- tems bringt. Es werden Methoden und Mittel verwendet, die außerhalb des eigenen Bereichs kommen. Die Lösungsquelle liegt innerhalb der eigenen Industriesparte, des eigenen Tätig- keitsfeldes. Klasse 4: Probleme, deren Lösung eine neue Generation von Systemen entstehen lässt. Die Primärfunktionen dieser Systeme werden durch das neue Prinzip erfüllt. Die Lösungsquelle Klarheit der Ziele gering hoch gering hoch Bekanntheit der Mittel Dialektische Probleme  Ziel unscharf  Mittel bekannt z.B. Entwicklungsstudie Dialekt. u. synth. Probleme  Ziel unscharf  Mittel unbekannt z.B. Neukonstruktion Synthetische Probleme  Ziel bekannt  Mittel unbekannt z.B. Anpassungskonstruktion Analytische Probleme  Ziel bekannt  Mittel bekannt z.B. Variantenkonstruktion 37 liegt meist außerhalb der eigenen Industriesparte, des eigenen Tätigkeitsfelds. Die Lösung wird mehr im wissenschaftlichen als im technologischen Bereich gefunden. Klasse 5: Probleme, deren Lösung durch eine wissenschaftliche Entdeckung möglich wird. Diese Lösungen sind im Bereich des gesamten verfügbaren Wissens zu finden. Entsprechend gering ist ihr Anteil an den gesamten angemeldeten Patenten Picot /114/ unterscheidet drei „Aufgabenkategorien“: − Routinefall: Hohe Planbarkeit, niedrige Komplexität, definierter Informationsbedarf und Lö- sungsweg, Kooperationspartner festgelegt, niedrige Kommunikationsintensität − Sachbezogener Fall: Erhöhte Komplexität, verringerte Planbarkeit, Lösungsweg nicht mehr geregelt, Informationsbedarf und Kooperationspartner nicht mehr eindeutig bestimmt − Einzelfall: Hohe Komplexität, niedrige Planbarkeit, Informationsbedarf und Lösungsweg sind offen, Kooperationspartner offen, hohe Kommunikationsintensität. Müller /100/ typologisiert Problemsituationen nach ihren Anforderungen und Unterstützungs- möglichkeiten. Er unterscheidet Aufgabe, Routineproblem, geläufiges (Teil-)Problem, An- spruchsproblem, Kompetenzproblem und Über-Kompetenz-Problem. Dabei sind bei einer Aufgabe die Informationen vollständig gegeben und die Struktur ist trans- parent. Bei einem Routineproblem sind die Informationen fast vollständig bzw. verfügbar. Die Struktur ist bekannt. Liegt ein geläufiges (Teil-)Problem vor, sind die Sachinformationen un- vollständig aber abrufbar, das Ziel ist abgesteckt, die Prozedurinformationen sind verfügbar und die Struktur ist meist bekannt. Bei einem Anspruchsproblem bestehen relativ viele, in der Regel vernetzte, teilweise geläufige Teilprobleme nebeneinander, der Zielraum ist nicht ein- deutig, die Sachinformationen sind lückenhaft, die Prozedurinformationen nur bei sehr großer Erfahrung vollständig. Die Struktur ist noch transparent, teilweise aber bereits unscharf. Beim Kompetenzproblem ist der Zielraum nur vage. Die Informationen sind sehr unvollständig. Viele Teilaufgaben sind ungeläufig, stark vernetzt und intransparent. Beim Über-Kompetenz- Problem ist der Zielraum zu klären und die problembezogenen Informationen fehlen fast voll- ständig. Die Struktur ist nicht überschaubar und sehr unscharf. Als Kriterien zur Beschreibung von Problemen verwendet Müller /100/ Ziel, Sach-, Prozedur-, Ziel- und Steuerinformationen, Kompliziertheit, Komplexität und Transparenz. Diese Problem- taxonomie ist empirisch an Forschungs- und Entwicklungsaufgaben, vor allem aus der Schweißtechnik, erstellt worden. Die bisherigen Merkmale in leicht abgeänderter Form beschreibt auch Kersting /81/. Er unter- teilt in einer zusätzlichen Klassifikationsebene Personen- und Situationsmerkmale . Er stellt die in vorherigen Kapiteln beschriebene Typisierung und Klassifikation in zweiter und dritter Ebene dar. In seinem Ansatz wurde das Merkmal der widersprüchlichen Ziele dem Komplexi- tätskriterium untergeordnet. Der Wissensaspekt fließt bei Kersting /81/ allgemein gehalten in alle Merkmale ein. Kersting /81/ weist auch dem Punkt der Transparenz kein eigenständiges Merkmal zu, sondern lässt dies ebenfalls in alle Merkmale einfließen. Die Personenmerkmale hingegen erscheinen bei Kersting /81/ als eigenständiger Teil, wohin- gegen Dörner /41/, Schroda /134/ und weitere Autoren diesen Aspekt nur erwähnen, jedoch nicht strukturiert in Beziehung setzen. Personenmerkmale werden von Kersting/81/ unterteilt in die Persönlichkeitsmerkmale im engeren Sinn (Selbstsicherheit, Ängstlichkeit), emotionale und motivationale Merkmale (Betroffenheit) und die kognitiven Merkmale (generelle intellektuelle Fähigkeiten und gegenstandsspezifisches Wissen). 38 In Problemsituationen können sich Personen mit unterschiedlichen Ausprägungen von Perso- nenmerkmalen befinden. Personen als Problemlöser sind ein Teilelement der Problemsituati- on. Je nach Stärke oder Ausprägung der Personenmerkmale kann sich ein Problem als durch- schaubar oder undurchschaubar darstellen. Beispielsweise kann je nach Ausprägung der kognitiven Merkmale einer Person ein Problem durch die subjektive Betrachtungsweise klar oder unklar, stark komplex oder weniger komplex sein. Ehrlenspiel /44/ klassifiziert ähnlich wie Kersting /81/ Probleme nach Objektmerkmalen (Sach- system), Zielmerkmalen (Zielsystem), Mittelmerkmalen (Handlungssystem) und Zeitmerkma- len. Innerhalb der Mittelmerkmale wird dabei noch zwischen Personen- und Gruppenmerkma- le unterschieden. Für die Produktentwicklung definiert er drei Problembereiche: − Organisatorische Probleme, z.B. hinsichtlich Zusammenarbeit, Motivation, Verfügbarkeit von Hilfsmittel − Prozessorientierte Probleme, z.B. hinsichtlich der Klärung der Anforderungen, der Suche nach Lösungen sowie der zeitlichen und inhaltlichen Steuerung der Prozesse − Technisch-wirtschaftliche Probleme, z.B. hinsichtlich Funktion, Fertigung, Werkstoffe, Kos- ten Mehrmann /97/ definiert vier Gruppen von Problemen: − Analyseprobleme: Hier besteht die Hauptanforderung darin, Strukturen zu erkenne und sichtbar zu machen. Zusammenhänge werden dabei beschreiben und verständlich ge- macht. Dies erfordert eine weit reichende Kenntnis des Problemgebiets, d.h. es ist Exper- tenwissen gefragt. − Suchprobleme: Bei Suchproblemen wird der Schwerpunkt auf das Suchen von Alternativen oder Lösungen gelegt. Es wird nach einer Strukturvielfalt gesucht, die gleich oder ähnlich ist. Dabei kommt das Gedächtnis verstärkt zum Einsatz, welches auf die vom Problem ge- forderten Merkmale hin überprüft wird. − Konstellations- und Konsequenzprobleme: Bei Konstellationsproblemen besteht die Anfor- derung darin, Elemente so anzuordnen, dass die Systemstruktur entsteht, die der Problem- lösende als Sollzustand anstrebt. Bei Konsequenzproblemen wird der Schwerpunkt auf die logischen Verknüpfungen von Strukturen gelegt. − Auswahlprobleme: Bei Auswahlproblemen besteht die Anforderung darin, aus einem Ziel Bewertungskriterien abzuleiten, anhand derer die Alternativen gemessen werden. Hesse et al. /70/ integrieren den Wissensaspekt in die Untersuchung von Problemen. Dem- nach gibt es: − Probleme ohne spezielle Anforderungen an die Wissensbasis − Probleme mit speziellen Anforderungen an die Wissensbasis und − Probleme mit Anforderungen an die Informationsaufnahme, -selektion und –speicherung. Schroda /135/ betrachtet ebenfalls den Wissensaspekt. Sie beschreibt für die Klassifikation von Konstruktionsaufgaben die Kriterien Widersprüchliche Ziele, Komplexität, Transparenz, Freiheitsgrade, Dynamik und erforderliches Wissen (vgl. Abbildung 7). Bei dem Kriterium er- forderliches Wissen werden dabei sachspezifisches Wissen, problemspezifische Vorgehens- weisen und allgemeine Lösungsstrategien unterschieden. 39 Abbildung 7: Anforderungsstruktur eines konstruktiv-schöfperischen Problems nach Schroda /135/ Arbinger /7/ differenziert Probleme nach dem zur Lösung erforderlichen Wissen. Er unter- scheidet in seinem Modell dabei drei verschiedene Wissenskategorien: Bereichsbezogenes Wissen, strategisches Wissen und metakognitives Wissen. Bisherige Ansätze zur Problemklassifizierung beziehen sich kaum auf praktische, industrielle Probleme (Schroda /135/) und sind für die Praxis unzureichend, da nur zum Teil grob operati- onalisierte Vorgehensweisen zur Problemklassifikation vorliegen. Computersimulierte Proble- me (Dörner /41/) sind speziell für Forschungszwecke entwickelt worden, d.h. die Anforderun- gen an die Lösung von Problemen wurden nicht analysiert sondern konstruiert. Darüber hin- aus standen bei einigen Ansätzen (Müller /100/) standardisierte, umfangreiche Aufgabenbe- schreibungen aus dem Bereich der Forschung zur Verfügung, wie sie in der industriellen Pra- xis selten vorkommen. Andere Ansätze beschränken sich nur auf einen Teilbereich der Pro- duktentwicklung und versuchen bestehende theoretische Klassifikationskriterien lediglich auf konstruktiv-schöpferische Probleme zu übertragen und zu validieren (Schroda /135/, Fran- ke /45/). Daher werden die bisherigen Ansätze zur Klassifikation von Problemen den Anforde- rungen aus der industriellen Praxis, insbesondere dem Bereich der Produktentstehung, nur bedingt gerecht. Zudem erfolgte bisher in keinem der betrachteten Ansätze eine Verknüpfung der unterschiedlichen Problemtypen mit dem Problemlösungsprozess. 3.2 Ansätze zur Problemprävention Ansätze zur Problemprävention stammen vornehmlich aus dem Bereich Qualitätsmanagement und konzentrieren sich auf die Vermeidung von Problemen und/oder zur Verbesserung von Prozessen. Zur Untersuchung der Ursachen von Fehlern und ihrer Auswirkungen werden Verhaltensana- lysen der Elemente, wie beispielsweise FMEA (Failure Mode and Effect Analysis) oder die Fehlerbaumanalyse vorgenommen. Sie dienen zur Berechnung der Wahrscheinlichkeit, in wie wider- sprüchliche Ziele Komplexität Transparenz Freiheits-grade Dynamik erforderliches Wissen Zahl der Ziele Anzahl der widersprüchlichen Ziele Stärke des Widerspruchs Anzahl der Teil- funktionen Anzahl der Verknüpfungen Informationen zu Ausgangs- und Randbedingungen Informationen zum Lösungsweg Informationen zum angestreben Ziel Anzahl der Lösungsvarianten Anzahl der Lösungswege Veränderlichkeit der Ausgangs- bedingungen Kalkulierbarkeit der Wirkung von Entscheidungen und Eingriffen Einwirkung äußerer Grössen problemspe- zifisches Wissen Konstruktiv-schöpferische Probleme sachspezifisches Wissen Stärke der Verknüpfungen allgemeine Lösungs- strategien 40 weit Systeme und deren Elemente innerhalb der Systemgrenzen während einer vorgegebenen Zeitspannen Gefährdungen verursachen. Die FMEA ist ein präventiver Qualitätssicherungsansatz und entstand in der Raumfahrtindust- rie, da die Produkte im Weltall für eine Nachbesserung nach der Herstellung nicht mehr zu- gänglich waren. Das Grundprinzip beruht auf dem systematischen Hinterfragen nach mögli- chen Schwachstellen und damit verbunden die Auswirkung, Ursache, mögliche Erkennung des Fehlers (BOSCH Arbeitskreis AK-LS /14/, Frehr /47/). Daraus lässt sich eine Risikopriori- tätszahl ermitteln. Wenn diese einen zuvor festgelegten Grenzwert überschreitet, müssen Maßnahmen zur Fehlervermeidung bzw. –reduktion erfolgen. Die Durchführung der FMEA erfolgt innerhalb eines Teams, welches zumeist aus erfahrenen Konstrukteuren, aber auch aus Teilnehmern aus anderen Bereichen besteht. Folgende FMEA-Arten können unterschieden werden (Schubert /136/): − System FMEA: Die System FMEA untersucht das funktionsgerechte Zusammenspiel der Systemkomponenten auf Basis des System-Pflichtenhefts. Das Ziel ist, Fehler bei der Sys- temauswahl und –auslegung zu vermeiden. − Konstruktions-FMEA: Diese FMEA untersucht die pflichtenheftgerechte Gestaltung und Auslegung der einzelnen Komponenten in Bezug auf die Erfüllung beschriebener Teilfunk- tionen zur Vermeidung von Entwicklungsfehlern und konstruktiv beeinflussbaren Prozess- fehlern. − Prozess-FMEA: Im Rahmen der Prozess-FMEA wird die Prozessplanung und –ausführung der Teile und Baugruppen zur Vermeidung von Fertigungs- und Montagefehlern untersucht. Im Vordergrund steht der Prozessschritt innerhalb der Abfolge der Herstellung. Als Schwachpunkte können der hohe personelle Aufwand, der erforderliche Zeitaufwand, die für alle Beteiligten gleichzeitige Bereitstellung der notwendigen Informationen und Quellen, sowie der hohe Dokumentationsaufwand gesehen werden (Kunz/Müller /92/). Bei der Fehlerbaumanalyse werden auf der Basis eines unerwünschten Endereignisses über Und- bzw. Oder-Verknüpfungen von internen und externen Einflüssen mögliche Ausfallursa- chen durch die verschiedenen Systemebenen zurückverfolgt. Dabei werden Ursachenketten und Fehlerstammbäume entwickelt (DIN 25424 /34/). Ein weiterer Ansatz, Fehler im Vorfeld zu vermeiden, ist das QFD (Quality Function Deploy- ment), mit dem die integrierte und gezielte Umsetzung von Anforderungen im gesamten Pro- dukterstellungsprozess möglich ist. Nach Akao /4/ konnten in etlichen Fallbeispielen mit QFD die Probleme zu Beginn der Produktentwicklung gar um bis zu 50% reduziert werden. Grund- legender Ansatz ist die Verbindung verschiedener Modellierungsstufen der Produkteigen- schaften über Matrizen (House of Quality). Die im QFD festgehaltene Beschreibung der Pro- duktfunktionen auf der Grundlage der Kundenanforderungen ist dabei die Voraussetzung für eine methodische Lösungsfindung. Aufbauend darauf werden die Anforderungen an die Herstellungs- und Prüfprozesse abgeleitet (Ehrlenspiel /44/). Engpassbereiche, Zielkonflikte und mögliche Fehlerquellen werden dabei verdeutlicht, indem Zusammenhänge zwischen den einzelnen Qualitätsmerkmalen in Form positiver oder negativer Beeinflussung symbolisch dar- gestellt werden. Das QFD Verfahren ist allerdings mit einem hohen Aufwand verbunden, da die Schritte sowie ihr Zusammenhang produkt- und erstellungsprozessabhängig sind. Sie müssen daher an das jeweilige Unternehmen angepasst werden. 41 Die kontinuierliche Verbesserung aller Leistungen und Tätigkeiten im Unternehmen ist Ziel des TQM (Total Quality Management). Der kontinuierliche Verbesserungsprozess (KVP), der auch unter dem Begriff „KAIZEN“ bekannt geworden ist, steht für ein systematisch betriebenes Ver- besserungsmanagement, welches gleichermaßen auf die Steigerung der Kundenzufrieden- heit, die Ergebnisverbesserung und die höhere Mitarbeitermotivation gerichtet ist. Unter Ver- besserung im Sinne von TQM versteht Frehr /47/ dabei beispielsweise die Beseitigung von Fehlleistungen, von unrationellen Arbeitsabläufen, Behinderungen oder Kommunikations- und Informationslücken. Die Innovation an Produkten, Prozessen und Einrichtungen wird dabei nicht berücksichtigt. Da das Verhalten der Mitarbeiter und deren Mitwirkung eine zentrale Rol- le spielen, muss eine kontinuierliche Verbesserung durch eine entsprechende Unternehmens- kultur entstehen. Alle untersuchten Ansätze sind trotz des teilweise sehr hohen Aufwands und des Anpas- sungsbedarfs für die Problemprävention und für die Qualitätssicherung gut geeignet. Aller- dings existiert kein umfassender Ansatz, der sich sowohl auf die Problemprävention als vor- beugende Maßnahme, als auch auf die Problemlösung als Interventionsmaßnahme bezieht. 3.3 Ansätze zur Problemlösung 3.3.1 VDI Richtlinien 2220, 2221 und 2222 Der Konstruktionsprozess wird als technischer Problemlösungsprozess bezeichnet, die Tätig- keit des Konstruierens analog dazu als „entwerfendes“ Problemlösen (Sachse /127/). Als Grundlage werden hierfür die Richtlinien VDI 2220 „Produktplanung, Ablauf, Begriffe und Or- ganisation“, VDI 2221 „Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte“ sowie VDI 2222 „Konstruktionsmethodik - Methodisches Entwickeln von Lösungs- prinzipien“ herangezogen. Die Produktfindung ist ein wesentlicher Bestandteil der Richtlinie VDI 2220. Der Prozess der Produktfindung wird in die Schritte Ideenfindung, Ideenselektion und schließlich die Produkt- definition aufgeteilt, wobei unter Ideenfindung „das Ermitteln neuer Produktideen innerhalb vorgegebener Suchfelder unter Berücksichtigung des Unternehmenspotentials“ verstanden wird. In der Ideenselektion werden dann die einzelnen Ideen in drei Stufen bewertet und ent- sprechend ausgewählt. Die Detailliertheit und die Ausarbeitung der einzelnen Ideen steigt über diese drei Stufen hinweg immer mehr an, die Anzahl der betrachteten Ideen nimmt zugleich ab. In der letzten Phase der Produktfindung „werden die Funktion, das Arbeitsprinzip und die charakteristischen Daten“ des zur Realisierung vorgeschlagenen Produktes definiert (VDI- Richtlinien VDI 2220 /162/). Die Richtlinie VDI 2221 stellt eine branchenübergreifende Methodik zum Entwickeln und Kon- struieren technischer Systeme und Produkte vor, sowie einige konkrete Umsetzungsbeispiele aus verschiedenen Branchen. Das generelle Gesamtvorgehen ist in sieben Arbeitsschritte aufgeteilt und läuft nach dem Grundprinzip vom „Abstrakten zum Konkreten“ und „vom Wesentlichen zum weniger Wesent- lichen“ ab. Die einzelnen Arbeitschritte können mehrmals iterativ durchlaufen werden, so wird das Produkt sukzessive verbessert. Die einzelnen Zwischenresultate, die Prototypen, dienen dabei wieder der Verifizierung und Fehlererkennung. Sämtlichen „Arbeitsabschnitten ist ge- meinsam, dass bei ihnen jeweils mehrere Lösungsvarianten untersucht, gegebenenfalls in Mustern bzw. Prototypen erprobt und anschließend beurteilt werden müssen.“ (VDI-Richtlinien 42 VDI 2221 /163/). Es handelt sich in allen Arbeitsschritten um Beurteilungen, Optimierungen und Entscheidungen. Die einzelnen Schritte können weiter, beispielsweise in wieder ähnliche Entwicklungsprozes- se, aufgegliedert werden. Ein Vor- und Rückspringen zwischen den einzelnen Schritten, wobei gegebenenfalls ein Schritt komplett ausgelassen wird, ist möglich. Generell sind die Übergän- ge zwischen den einzelnen Arbeitsschritten fließend (VDI-Richtlinien VDI 2221 /163/). Neben generellen Vorgehensempfehlungen zur Gestaltung des Konstruktionsprozesses wer- den dem Konstrukteur eine Reihe von Methoden zur Durchführung der einzelnen Arbeits- schritte (z.B. Kreativitätstechniken, Bewertungsmethoden) zur Verfügung gestellt. Ähnlich hierzu werden in der Richtlinie VDI 2222 Hilfestellungen zum methodischen Entwi- ckeln von Lösungsprinzipien gegeben, welche neben den methodischen Vorgehensschritten auch Methoden und Hilfsmittel anbietet (VDI-Richtlinien VDI 2222 /164/). Die Anwendung der Konstruktionsmethodik ist auf die Konstruktion von Systemen des Ma- schinenbaus und der Verfahrenstechnik beschränkt und ist in der Praxis relativ gering verbrei- tet (Jorden/Havenstein et al. /78/). Dies wird unter anderem auf einen mangelnden Bezug auf den individuellen Arbeitsstil des Konstrukteurs und auf die Probleme der Arbeitsteilung im Konstruktionsteam zurückgeführt (Schnurr/Staab et al. /133/). 3.3.2 IDEALS Das von Nadler /102/ entwickelte IDEALS Concept (Ideal Development of Effective And Logi- cal Systems) beschreibt ein Konzept zur schöpferischen Gestaltung eines Wirksystems, auf- setzend auf der Lehre von der Beschreibung der Arbeit. Das IDEALS Vorgehensmodell bein- haltet zehn Schritte, die zu vier wesentlichen Kernschritten zusammengefasst werden können: − Definition einer Funktion − Entwurf des Ideals − Entwicklung des Optimums − Frühzeitige Realisierung von Ergebnissen Wie aus den Schritten erkennbar, spielt der Funktionen- und Systembegriff in dem Konzept eine zentrale Rolle. Im ersten Schritt wird einem zu gestaltenden System Funktionen zugeord- net, auf dessen Basis schließlich die Erarbeitung eines Idealsystems erfolgt. In weiterer Folge wird das Idealkonzept so lange „reduziert“ bis ein akzeptierbarer Kompromiss zwischen den Anforderungen des Ist-Zustandes und den Möglichkeiten der Ideallösung gefunden ist. Die Ideallösung und nicht die aktuelle Situation steht dabei im Vordergrund, in dem sie die Grund- lage für die Untersuchung und Strukturierung des Ist-Zustandes bildet. Ein wesentlicher Vorteil dieser Vorgehensweise ist dabei nach Haberfellner, dass eine Be- zugsbasis für die Analyse des Ist-Zustandes gegeben ist (Daenzer/Huber et al. /24/). Dadurch können die Aufnahme des Ist-Zustandes strukturiert und zielorientiert durchgeführt und auch traditionelle Denkbarrieren leichter übersprungen werden. Ein Nachteil besteht darin, dass der Ist-Zustand ausschließlich aus dem Blickwinkel einer gegebenenfalls übereilt gewählten Ideal- lösung gesehen wird. 43 3.3.3 TRIZ Die von Altshuller entwickelte TRIZ Methode dient der systematischen Ideenfindung und zur Entwicklung innovativer Konzepte. Die Abkürzung TRIZ steht als russisches Akronym dabei für „Theorie des erfinderischen Problemlösens“ (Herb/Herb /68/). Ziel von Altshuller war es, innovative Prozesse zu systematisieren und vom Zufall auszuschließen. Er verfolgte den Leit- gedanken, Erfindungszeiten zu verkürzen und Problemlösungsprozesse zu strukturieren, so dass Durchbruchsdenken ermöglicht wird (Klein /86/). Der Grundansatz ist es dabei, keine Kompromisse zuzulassen, sondern auf einer technisch-naturwissenschaftlichen Grundlage Widersprüche zu lösen (Teufelsdorfer /155/). Abbildung 8: Lösungsfindung in der TRIZ-Methode (vgl. /155/) Klein /86/ definiert TRIZ als „Methodik, die Entwicklern ein Erfahrungs- und Wissenskonzentrat mit Benutzerleitfaden zum systematischen Innovieren zur Verfügung stellt. Die Strukturierung ist dabei besonders geeignet, hochgradige Erfolge zu provozieren“. Damit unterscheidet sich die Methodik von der klassischen Konstruktionsmethodik, die nach Klein /86/ eher verbesserte Varianten einer Entwicklung hervorbringt. Der Problemlösungsprozess von TRIZ lässt sich in vier Schritte unterteilen (Herb/Herb /68/): 1. Problemerkennung, Problemanalyse und Problemformulierung 2. Ideenfindung, Ideenvorselektion, Ideenausarbeitung 3. Bewertung, Entscheidung, Auswahl 4. Realisierung Der Fokus des Konzepts liegt dabei ausschließlich auf der Lösung von technischen, bzw. pro- duktspezifischen Problemen, deren Widersprüche mit Hilfe von 39 definierten technischen Parametern und 40 Entwicklungs- bzw. Verfahrensprinzipien aufgelöst werden. 3.3.4 Wertanalyse Das Ziel der Wertanalyse nach DIN 69910 /36/ ist es in erster Linie, ausgehend von einer be- stehenden Konstruktion, deren Kosten zu senken. Sie verknüpft erstmals mehrere bereits be- Verfahrensauswahl Identifizieren und Analysieren des Problems, S-Field Analyse, Ideale Maschine, etc. Principles Die vier Lösungs- ansätze Laws of Development of Systems Physical Effects and Phenomena Technischer Widerspruch identifiziert Physikalischer Widerspruch identifiziert Zukünftige Trends gesucht Naturwissen- schaftliche Effekte gesucht Bewertung der Lösungsansätze Implementierung der Lösung Phase der Zielsuche  Situationsanalyse  Zielformulierung Phase der Lösungssuche  Analyse  Synthese Phase der Realisierung  Bewertung  Auswahl 44 kannte Instrumente zu einem Problemlösungssystem. Die Vorgehensweise besteht aus den Bausteinen Teamarbeit, systematisches Vorgehen sowie der Funktionenanalyse. Die Definition von Funktionen der mit der Wertanalyse betrachteten Objekte ist ein wesentli- cher Bestandteil derselben und beeinflusst die darauf folgenden Arbeitsphasen. Das Ziel der Definition und Formulierung von Funktionen ist dabei (VDI-GSP /179/): − die Strukturierung des Systems des Wertanalyse Objekts, um alle wichtigen Objekteigen- schaften vollständig zu beschreiben − das Loslösen von dem gegebenen Ist-Zustand durch die Analyse der Wirkungseinflüsse des Objekts − die abstrahierte Visualisierung des gewünschten Soll-Zustands, um möglichst viele Alterna- tivlösungen zu finden − die Identifikation der Abweichung zwischen dem unerwünschten Ist-Zustand und dem er- wünschten Soll-Zustand Das Vorgehen bei der Wertanalyse erfolgt nach dem Wertanalyse-Arbeitsplan (DIN 69 910) in folgenden Schritten: 1. Vorbereitung des Projekts 2. Analyse der Objektsituation 3. Beschreibung des Soll-Zustands 4. Entwicklung von Lösungsideen 5. Festlegung von Lösungen 6. Verwirklichung von Lösungen Der Arbeitsplan kann als Ablauf-Checkliste verstanden werden, der den ausführenden Indivi- duen der Wertanalyse als Orientierungshilfe zur Verfügung steht (VDI-GSP /179/). Die Wertanalyse ist für wenig umfangreiche Projekte geeignet, kann aber dem generellen An- spruch eines Ansatzes zur Lösung komplexer, wissensbasierter Probleme, nicht gerecht wer- den. 3.3.5 REFA 6-Stufen Methode Die REFA-6 Stufen Methode baut auf dem IDEALS Concept von Nadler /102/ auf und geht daher tendenziell von einem Idealkonzept aus. Alle Vorgehensaussagen werden dabei zu ei- nem einzigen Ablaufmodell verdichtet. Damit gibt es beispielsweise keine Unterscheidung verschiedener Entwicklungsphasen mit unterschiedlichem Detaillierungsgrad (Daenzer/Huber et al. /24/). Die REFA Methode beinhaltet folgende 6 Stufen: 1. Ziele setzen 2. Aufgabe abgrenzen 3. Ideale Lösung suchen 4. Daten sammeln und praktikable Lösungen entwickeln 5. Optimale Lösung auswählen 6. Lösungen einführen und Zielerfüllung kontrollieren. 45 Für kleinere Problemstellungen ist diese Methode ausreichend, genügt jedoch nicht den An- sprüchen und Anforderungen komplexer Probleme (Daenzer/Huber et al. /24/). 3.3.6 Systems Engineering Das Vorgehensmodell des Systems Engineering von Haberfellner zielt auf die zweckmäßige und zielgerichtete Analyse und Gestaltung komplexer Systeme. Es besteht aus vier Kompo- nenten, die modular miteinander kombiniert werden können (Daenzer/Huber et al. /24/): − Vom Groben zum Detail − Prinzip der Variantenbildung − Phasenweises Vorgehen (Projektphasen) − Problemlösungszyklus Das Vorgehensprinzip „Vom Groben zum Detail“ soll ausdrücken, dass es als sinnvoll erachtet wird, zuerst generelle Zielen und einen generellen Lösungsrahmen festzulegen und deren Detaillierungs- und Konkretisierungsgrad im Laufe der Lösungsentwicklung stufenweise zu vertiefen. Das Betrachtungsfeld wird zudem zunächst weiter gefasst und dann schrittweise eingeengt. Das Prinzip der Variantenbildung weist darauf hin, dass es notwendig ist, sich nicht mit der erstbesten Lösung zufrieden zu geben, sondern immer in Varianten bzw. Alternativen zu den- ken. Das Phasenmodell stellt eine Makro-Strategie dar und gliedert den Werdegang einer Lösung in überschaubare Teiletappen. Dadurch kann ein stufenweiser Planungs-, Entscheidungs- und Realisierungsprozess angeregt werden. Es dient als Planungsinstrument, indem der Blick zu- nächst auf die Ergebnisse, die man am Ende der jeweiligen Phasen erreichen möchte, richtet. Daraus leitet sich dann ein Katalog von Tätigkeiten ab, die dazu durchzuführen sind. Der Problemlösungszyklus ist als Mikro-Logik zu verstehen, welche das Phasenmodell er- gänzt. Er kann bei jeder Art von Problemen und in jeder Projektphase zur Anwendung kom- men, gegebenenfalls mit unterschiedlicher Gewichtung der Schritte. Die Schritte des Problem- lösungszyklus sind in Abbildung 9 dargestellt. Phasenmodell und Problemlösungszyklus werden als wesentliche und gedanklich voneinan- der trennende Elemente des Vorgehensmodells betrachtet. Gedankliche Vor- oder Rückgriffe sowie Wiederholungszyklen bzw. eine überlappte Bearbeitung bleiben dem Anwender dabei freigestellt. Die Systematik ist sehr umfassend und komplex und daher ist der praktischen Einsatz als Problemlösungsmethodik mit einem erheblichen Aufwand verbunden. Allerdings wird die indi- viduelle Problemlösung (Mikro-Logik) berücksichtigt und in den Gesamtablauf (Entwicklungs- prozess) gut integriert. Ebenfalls die methodische Unterstützung der einzelnen Problemlö- sungsphasen durch Werkzeuge und Instrumente stellt einen großen Mehrwert des Ansatzes gegenüber den anderen untersuchten Ansätzen dar. 46 Abbildung 9: Problemlösungszyklus nach Haberfellner /24/, S. 48 3.3.7 Simultaneous Engineering & Concurrent Engineering Das Konzept Simultaneous Engineering dient dem Unternehmen zur Optimierung seines Pro- duktentstehungsprozesses. Im Vordergrund steht hier deshalb die Beschleunigung des Ent- wicklungsprozesses durch drei Handlungsweisen (Stanke/Berndes /147/): − eine weitgehende Parallelisierung von Abläufen durch die zeitgleiche Durchführung von Prozessen die keine Abhängigkeiten untereinander haben. Bei vorhandenen Abhängigkei- ten, wird der abhängige Prozess schon begonnen, bevor der Vorgängerprozess abge- schlossen ist; − eine Standardisierung, um Wiederholungen und unnötige Arbeiten zu vermeiden und aus den Erfahrungen der Vergangenheit zu lernen. Die Unterstützung von Routineaufgaben mit Standards führt hierbei zu mehr Zeit für innovative und kreative Aufgaben; − die Integration von verschiedenen Unternehmensbereichen in die Produktentwicklung mit dem Ziel, Schnittstellenprobleme und damit verbundene unnötige Mehrarbeit zu vermeiden. Dies erfolgt beispielsweise durch die Einführung von interdisziplinären Teams. Im Gegensatz zum Konzept des Simultaneous Engineering, bei dem der Hauptaspekt auf der Parallelisierung des Entwicklungsprozesses liegt, liegt der Schwerpunkt des Concurrent Engi- neering auf der Integration aller am Produktentwicklungsprozess beteiligten Unternehmensbe- reiche und aller produktspezifischen Subsysteme (Stanke/Berndes /148/). Aufgrund der Ähn- lichkeit des Simultaneous Engineering (SE) Konzepts zum Konzept des Concurrent Enginee- ring (CE) wurden beide zum Concurrent Simultaneous Engineering (CSE) verknüpft. Das Konzept des Simultaneous Engineering kann als anwendungsorientiertes, überlapptes Phasenkonzept interpretiert werden, welches sich ausschließlich auf die Optimierung des Entwicklungsprozesses selbst bezieht, jedoch den individuellen Problemlösungsprozess als „Mikro-Logik“ außer Acht lässt. Zielsuche Lösungs- suche Auswahl Situationsanalyse Zielformulierung Synthese von Lösungen Bewertung Entscheidung Analyse von Lösungen Anstoß Ergebnis/Anstoß In fo rm at io n sb es ch a ffu n g Lö su n gs or ie n tie rt Pr ob le m or ie n tie rt D ok u m e n ta tio n 47 3.3.8 Prototyping & Rapid Product Development Das Prototyping Vorgehensprinzip fand erstmals Anwendung in der Informatik und wird im Sinne einer evolutionären Entwicklungsstrategie eingesetzt. Die Grundidee ist dabei, mög- lichst frühzeitig Prototypen bzw. Versionen des Zielsystems als Kommunikationsmittel zwi- schen Entwicklern und Anwendern zu erstellen (Selig /140/, Mertens /98/). Dem Prototyping Ansatz sehr ähnlich ist das Konzept des Rapid Product Development (RPD) im Engineering, welches auf dem Ansatz des SE aufbaut. RPD setzt ebenfalls auf eine evolu- tionär-iterative Vorgehensweise mit schnellen Rückkopplungen und kleinen Regelkreisen (Bul- linger/Warschat /22/). Der Schwerpunkt dieses Ansatzes liegt auf den frühen Phasen der Pro- duktentstehung. Neben der gezielten Nutzung schneller Iterationszyklen ist RPD durch die situationsgerechte Verwendung von virtuellen und generativen Prototypen sowie durch die selbstorganisierten Entwicklungsteams gekennzeichnet (Dittmar/Scholl et al. /39/). Die Iterationszyklen, vereinfachend durch die Phasen „plan, do, check, act“ beschrieben, müs- sen dabei nicht notwendigerweise sequentiell oder in ihrer Gesamtheit abgearbeitet werden (Bender/Tegel et al. /10/). Die Zyklen können sich dabei auf ein Bauteil, eine Baugruppe, ein Modul, oder aber auf das gesamte Produkt beziehen. Diese Vorgehensweise weicht somit vom klassischen Produktentwicklungsprozess gemäß VDI-Richtlinie 2221 ab, da dieser nicht mehr durchlaufen wird (Bullinger/Warschat /22/). Beide Ansätze streben nach raschen Lösungen, auch wenn sie noch nicht vollständig und perfekt sind. Diese Lösungen werden dann zyklisch weiterentwickelt, verändert und ange- passt. Dabei besteht nicht nur die Gefahr der Improvisation sondern auch der Möglichkeit, dass Lösungen „quick and dirty“ bleiben (Daenzer/Huber et al. /24/). Eine explizite Orientie- rung an der Problemlösung als Mikro-Logik erfolgt nicht, allerdings ist die Zusammenarbeit im Entwicklungsteam ein wesentlicher Bestandteil des Ansatzes. 3.3.9 Ansatz nach Gomez & Probst Gomez/Probst /55/ kritisieren bestehende Ansätze vor allem in der einseitigen Ausprägung hinsichtlich der Aspekte Sach- oder Verhaltens- bzw. Aktionsorientierung. Der von ihnen ent- wickelte Ansatz fordert daher ein ganzheitliches Problemlösen, welches beide Aspekte aus- gewogen kombiniert. Ihrer Ansicht nach ist es nicht mehr ausreichend, nur passende Gedan- kenmodelle zu komplexen Problemsituationen durch vernetztes Denken zu entwickeln. Viel- mehr fordern sie als weitere ergänzende Dimensionen ihrer Methodik das unternehmerische Handeln und das persönliche Überzeugen. Unternehmerisch handeln bedeutet in diesem Kon- text, die entwickelten Konzeptionen im Interesse des Ganzen in der Praxis umzusetzen. Das persönliche Überzeugen erfolgt schließlich durch persönliches Beispiel, welches zur Motivati- on beteiligter Mitarbeiter und zur Durchsetzung der Problemlösung erforderlich ist, da bei der Umsetzung ein guter Wille allein nicht ausreichend ist. Die Problemlösungsmethodik beinhaltet hierbei fünf Schritte: 1. Probleme entdecken und identifizieren 2. Zusammenhänge und Spannungsfelder der Problemsituation verstehen 3. Gestaltungs- und Lenkungsmöglichkeiten erarbeiten 4. Mögliche Problemlösungen beurteilen 5. Problemlösungen umsetzen und verankern. 48 Die genannten drei Dimensionen stehen dabei im gesamten Problemlösungsprozess im Vor- dergrund. 3.3.10 Ansatz nach Primus Primus /117/ allein berücksichtigt bei seinem Vorgehensmodell zur Problemlösung das Thema Wissensmanagement. Aufgrund des speziellen Fokus von Wissensmanagement bei der Ent- wicklung des Analysemodells und der Gestaltungsansätze bezeichnet Primus den aus dem Modell ableitbaren Prozess der Problemlösung als wissensbasiert. Insbesondere die Aspekte Adaptivität, Effizienz und Effektivität liegen dabei im Zentrum seiner Betrachtung. Das Vorgehensmodell zur Entwicklung eines wissensbasierten Prozesses zur Problemlösung umfasst dabei die drei Phasen − Problemanalyse − Lösungsentwicklung − Wissenssicherung Im Rahmen dieser Phasen ergeben sich insgesamt neun Prozessschritte, die, zu einer Ge- samtstruktur zusammengeführt, für eine Analyse und Gestaltung von Problemlösungsaktivitä- ten zur Anwendung kommen können. Durch das Vorgehensmodell zur Entwicklung eines wissensbasierten Prozesses zur Problem- lösung soll gewährleistet werden, dass im betroffenen System bereits bestehendes Wissen optimal genutzt wird, um den jeweiligen Entwicklungsschritt auszuführen. Dabei beschreiben die Arbeitsschritte keinen Arbeitsablauf zur idealen Problemlösung, vielmehr dienen sie zur Verbesserung von Problemlösungsaktivitäten, indem sie auf einige, aus wissensorientierter Sicht relevanten Untersuchungsaspekte hinweisen. Für diese ausgewählten Untersuchungs- aspekte wurden Gestaltungsempfehlungen entwickelt. Abbildung 10: Problemlösungsprozess nach Primus /117/, S. 147 Die Unterstützung des Problemlösungsprozesses erfolgt bei Primus /117/ durch die detaillierte Beschreibung des Problemlösungsprozesses aus Wissenssicht sowie durch Gestaltungsemp- fehlungen. Problemlösung Problem- analyse Wissens- sicherung Erfassung Vernetzung Bewertung Lösungs-initiierung Lösungs- design Lösungs- auswahl Um- setzungs- initiierung Umsetzung Eva-luation SOLL IST SOLL = ISTSOLL = IST Lösungs- entwicklung 49 3.4 Wissensbasierte Systeme zur Unterstützung der Problemlösung Bei den wissensbasierten Systemen zur Unterstützung der Problemlösung stellen das Case Based Reasoning, Expertensysteme sowie Entscheidungsunterstützungssysteme vielverspre- chende Ansätze dar. Als Reasoning bezeichnet man die Suche nach Lösungen für eine konkrete Aufgabe unter Verwendung des zur Verfügung stehenden Wissens. Ausgehend von einer Problemstellung wird Wissen kombiniert und angewendet, um eine Lösung zu erreichen (Gottlob /57/). Beispie- le für die Anwendung von Reasoning sind: Ziehen von Schlussfolgerungen aus Fakten, Diag- nose von Ursachen ausgehend von Beobachtungen, Analyse von Daten und Problemlösestra- tegien für eine Aufgabe. Im Gegensatz zu anderen Ansätzen der Künstlichen Intelligenz, welche nur auf generelles Wissen einer Problemdomäne zurückgreifen, wird unter Case-based Reasoning (CBR) das fallbasierte Schließen verstanden, d.h. zur Lösung eines neuen Problems werden ähnliche, bereits aufgetretene Problemsituationen herangezogen und spezifische Informationen und Wissen von diesen konkreten Problemfällen wieder verwendet (Aamodt/Plaza /1/). Das Case-based Reasoning berücksichtigt vornehmlich strukturierte Probleme und unterstützt bei der Suche nach ähnlichen Problemfällen in konreten, abgegrenzten Wissensdomänen. Der Einsatz eines CBR-Systems erfolgt z.B. als Help-Desk-Anwendung. CBR bezieht den Prob- lemlöser nicht mit in die Lösung ein, d.h. es unterstützt den Problemlöser weder bei der Über- tragung des Wissens auf die eigene aktuelle Problemsituation noch bei der strukturierten Lö- sungsentwicklung des aktuellen, komplexen Problems, falls der über CBR gefundene Prob- lemfall nicht übertragen werden kann. Expertensysteme wenden Wissen und die Schlussfolgerungen von Experten an und sind ein Hauptanwendungsgebiet der KI (Künstlichen Intelligenz). So definiert Puppe /120/ Experten- systeme als „…Programme, mit denen das Spezialwissen und die Schlussfolgerungsfähigkeit qualifizierter Fachleute auf eng begrenzten Aufgabengebieten nachgebildet werden soll“. Ziel des Einsatzes eines Expertensystems ist es, in einem eng abgegrenzten Anwendungsbe- reich die Problemlösungsfähigkeiten eines menschlichen Experten mindestens annähernd zu erreichen oder sogar zu übertreffen (Schäffer /128/). Der Einsatz erfolgt beispielsweise im medizinischen Bereich bei der Diagnoseunterstützung oder im technischen Bereich bei der Fehlersuche in technischen Systemen oder aber auch bei der Steuerung von technischen Systemen (Gottlob /57/). Relevante Einsatzbereiche für Pro- duktentwicklung sind Planung und Konfiguration bzw. Entwurf. Ziel ist es, dem Anwender Wis- sen und Fertigkeiten zur Verfügung zu stellen, über die normalerweise nur speziell ausgebilde- te oder erfahrene Personen (Experten) verfügen. Unterscheidung von 3 Typen von Expertensystemen nach Puppe /120/: 1. eingebettete Expertensysteme zur Entscheidungsfindung, 2. interaktive Expertensysteme zur Entscheidungsfindung (Verantwortung für Problemlö- ser bei System oder Benutzer), 3. interaktive Expertensysteme zur Beratung (Benutzer trägt Verantwortung für Problem- lösung, System ist beratend). Die Grenzen von Expertensystemen (Hart /62/, Puppe /120/, Schäffer /128/;) werden vor allem in der Wahl der Domäne gesehen. Manche Probleme sind zu komplex, um über Expertensys- 50 teme abgebildet zu werden, die in der Regel sehr eingegrenztes Wissensgebiet beschreiben. Für Verhandlungen und Diskussion von Unstimmigkeiten, auch für länger währende Problem- lösungen, die viel Interaktion erfordern oder die von räumlich verteilten Beziehungen und Vor- gehensweisen abhängen, sind Expertensysteme nicht geeignet. Der Einsatz von Expertensys- temen ist daher nur sinnvoll bei stark strukturierbaren, statischen Abläufen. Ein weiterer Kritik- punkt betrifft die Akzeptanz von Expertensystemen. Manche ziehen die direkte, persönliche Diskussion mit einem Experten der Anwendung eines Computerprogramms vor. Zudem sind viele Daten unsicher und unvollständig. Der Unterschied zwischen Expertensystemen und Entscheidungsunterstützungssystemen besteht darin, dass Expertensysteme einen gut definierbaren Problembereich besitzen und operative Tätigkeiten unterstützt werden, während Entscheidungsunterstützungssysteme in einem weiten Problembereich agieren und meist strategische Tätigkeiten unterstützen. Die Kritik am zugrunde liegenden Entscheidungsprozessmodell betrifft vor allem die Gültigkeit für innovative, unstrukturierte Problemstellungen, weil es dabei zu einer Vielzahl sich überla- gernder und abhängiger Teilprozesse kommt, die eine klare Trennung der einzelnen Phasen verhindert. Entscheidungsunterstützungssysteme sind bei vollständig unstrukturierten Prob- lemstellungen nur bedingt sinnvoll, da der menschliche Entscheidungsträger bei der Beurtei- lung und Bewertung eine entscheidende Rolle spielt (Petkoff /112/). 3.5 Zusammenfassende Bewertung des Stands der Forschung und Ableitung von Bedarfen für die Systematik zur Problemlösung Die Defizite bestehender Ansätze zur Lösung von Aufgaben bzw. Problemen werden im fol- genden zusammengefasst. In Tabelle 1 ist die Bewertung der untersuchten Ansätze entspre- chend den in Kapitel 2.6 definierten Anforderungen dargestellt. Problemklassifizierung: Die meisten der aufgeführten Ansätze können den Anforderungen an die Klassifizierung von Problemen in dieser Arbeit nur unzureichend gerecht werden. So kann beispielsweise aus den beschriebenen Kriterien nicht auf die Anforderungen an die Gestaltung des Lösungswegs der Probleme geschlossen werden (A1). Zumeist konzentrieren sich die Klassifikationsansätze auf praxisferne, abstrakte Probleme oder auf konstruktiv-schöpferische Probleme. Eine Klassifika- tion die sowohl konstruktiv-schöpferische Probleme als auch organisatorische, technische Probleme betrachtet, existiert nicht (A2). Personenunabhängige und personenabhängige Merkmale werden oft vermischt; eine Problemklassifikation, welche das verteilte Arbeiten in der Produktentwicklungsprozesses ausreichend berücksichtigt, konnte nicht identifiziert wer- den (A3). Die Bewertung und Klassifikation der Probleme ist nur im Nachhinein, d.h. nach der Bearbeitung möglich. Der Wissensaspekt wird teilweise in die Klassifikation von Problemen mit einbezogen (A5). Um eine Klassifikation zu ermitteln, welche der Planung und Gestaltung eines wissensintensi- ven Problemlösungsprozesses ist es sinnvoll, diese zahlreichen, sehr heterogenen Klassifika- tionskriterien auf ihre Praxisrelevanz zu untersuchen, Primärkriterien zu identifizieren und die Kriterien zu gruppieren. 51 Anforderungen Ansätze A us ric ht u n g an pr ax is o rie n tie rte n Pr o bl em e n im Ar be its u m fe ld in PE Br e ite r Pr o bl em be re ic h, Fo ku s ko m - pl e xe Pr o bl em e (A 2) Fo ku s a u f i n di vi du e l- le s/ te am o rie n tie rte s Pr o bl e m lö se n (M ik ro - Lo gi k) A3 ) As si st en z be i d e r Fü hr u n g du rc h de n Pr o bl em lö su n gs pr o ze ss (A 4) Be rü ck si ch tig u n g u n d Be re its te llu n g vo n M e ta w is se n (A 5) Ko n te xt - bz w . ak tiv itä ts be zo ge n e s W is se n sa n ge bo t (A 6) Be rü ck si ch tig u n g ve rs ch ie de n e r Ex - pe rti se st u fe n (A 7) Un te rs tü tz u n g ko op . Ab st im m u n gs - u n d Ko m m u n ik a tio n sp ro ze ss e (A 8) Be itr a g zu r Qu a lit ät ss ic he ru n g (A 9) G a n zh ei tli ch e r Pr o bl e m lö se zy kl u s (P ro bl em pr äv e n tio n u n d – lö su n g) (A 10 ) In te gr at io n de r Pr o bl e m lö su n gs pr o - ze ss e in di e Pr oz es sw el t (A 11 ) Schroda - - - - - - - Kersting - - - - - - - Dörner - - - - - - - Altshuller - - - - - - - Picot - - - - - - - Müller - - - - - - - Ehrlenspiel - - - - - - - Mehrmann - - - - - - - Arbinger - - - - - - - Pr o bl em kl a ss ifik at io n Hesse - - - - - - - FMEA Fehlerbaumanalyse QFD Pr o bl em - pr äv en tio n KVP VDI 2220, 2221, 2222 IDEALS TRIZ Wertanalyse REFA 6-Stufen Systems Engineering SE/CE Prototyping und RPD Gomez und Probst Pr o bl em lö su n g Primus Case-based Reasoning Expertensysteme Sy - st e m e Entscheidungssysteme hoher Erfüllungsgrad teilweiser Erfüllungsgrad geringer Erfüllungsgrad - Kriterium nicht rele- vant Tabelle 1: Bewertung der untersuchten Ansätze 52 Vorgehensmodelle zur Problemprävention: Die Beschriebenen Ansätze zur Problemprävention können in der Produktentwicklung ange- wendet werden (A1) Insbesondere bei der Anwendung von FMEA, QFD und TQM werden kooperative Abstimmungs- und Kommunikationsprozesse genutzt (A8). Auch tragen alle be- trachteten Ansätze zur Qualitätssicherung (A9) bei. Allerdings ist der Einsatz der Ansätze zu- meist mit einem hohen Aufwand verbunden und sie müssen an die spezifischen Randbedin- gungen im jeweiligen Unternehmen angepasst werden. Darüber hinaus konnte keine Verknüp- fung eines Ansatz zur Problemprävention mit einem Ansatz zur Problemlösung identifiziert werden, so dass ein ganzheitlicher, umfassender Problemlösezyklus (A10) nicht möglich ist. Vorgehensmodelle zur Problemlösung: Es existieren Ansätze, welche das konstruktive Entwerfen als Problemlösungsprozess (u.a. VDI-Richtlinien VDI 2220 /162/, Pahl/Beitz /109/) oder den Innovationsprozess als erfinderi- schen Problemlösungsprozess (Klein /86/, Teufelsdorfer/Conrad /155/, Herb/Herb /68/) be- rücksichtigen. Doch diese Ansätze konzentrieren sich im Wesentlichen auf Probleme und Auf- gaben, welche sich auf die Konstruktion und Konzeption von Produkten beziehen. Der Lösung von generellen konzeptionellen Problemstellungen oder gar prozessspezifischen und koordi- nativen Problemstellungen wurde bisher in der Problemlöseforschung kaum Aufmerksamkeit gewidmet (A1, A2). Weiter sind die bestehenden Prozessmodelle nicht auf die Anforderungen realer Probleme im Arbeitsumfeld abgestimmt (Sell/Schimweg /142/, Daenzer/Huber et al. /24/, Dörner /41/). Ein weiterer Schwachpunkt der bestehenden Ansätze ist, dass die Problemlöseprozesse nicht für die individuelle bzw. Team-Ebene angewendet werden können (A3). Lediglich das System Engineering und der Ansatz von Primus bieten hier ausreichende Anknüpfungspunkte. Auch ist der Zusammenhang zwischen Problemlösungsprozess und des zur Lösung eines Problems vorhandenen bzw. notwendigen spezifischen Expertiselevels kaum berücksichtigt und er- forscht (u.a. Kersting /81/) (A7). Da die Lösung von Problemen durch die Nutzung, Verarbeitung und den oft spontanen Aus- tausch von Know-how und Erfahrungen durch die am Problemlösungsprozess Beteiligten be- stimmt ist, bedarf es geeigneter Hilfsmittel, Methoden und Informationstechnologien zur Unter- stützung der Wissensprozesse in der Problemlösung (Remus /124/). Bestehende Ansätze berücksichtigen die Wissensverarbeitung und -entwicklung in Problemlösungsprozessen nur in sehr geringem Maße (A5, A6). Allein Primus (Primus /117/) geht ausreichend auf die Integrati- on des Wissens in den Problemlösungsprozess ein, da er den Problemlösungsprozess aus Wissenssicht gestaltet. Aufgrund der Eigenschaften von wissensintensiven Problemlösungsprozessen ist eine Unter- stützung nach klassischen Methoden des Prozessmanagements nicht oder nur teilweise mög- lich, da es sich um komplexe, sich laufend ändernde, dynamische Systeme handelt, die sich der klassischen, statischen Modellierung weitgehend entziehen (Remus /124/). Es existieren zwar Ansätze zur Modellierung wissensintensiver Prozesse (u.a. Remus /124/, Schwarz/Abecker /138/), jedoch für das Feld der Problemlösungsprozesse nur grobe Ablauf- schemata (u.a. Daenzer/Huber et al. /24/, Dörner /41/, Sell/Schimweg /142/), welche dem Problemlöser weder eine Führung durch den Problemlösungsprozess bieten (A4), noch ko- operative Aspekte berücksichtigen (A8). Nur der Ansatz des Systems Engineering bietet dem Anwender ausreichend Detaillierungsgrad in der Beschreibung des Problemlösungsprozesses und bietet eine entsprechende Auswahl an Methoden zur Unterstützung der einzelnen Pro- zessschritte (A6). 53 Keiner der untersuchten Problemlösungsprozesse beinhaltete Quality Gates, um die Steue- rung und das Monitoring der Problemlösung zu gewährleisten und die Qualität der Problemlö- sung entsprechend abzusichern (A9). Die Untersuchung der bestehenden Methoden zeigt weiter einen Mangel an ganzheitlichen Vorgehensweisen zur systemweiten Problembearbeitung (Kirsch /84/), welche die Problem- prävention und gleichzeitig die Lösung eines Problems unterstützen (A10). Die Integration des Problemlösungsprozesses als Mikro-Logik in den Entwicklungsprozess (A11) erfüllen in aus- reichendem Maße lediglich das Systems Engineering, die VDI Richtlinien als auch der Ansatz von Primus. Für die Entwicklung der Systematik zur Planung und Gestaltung von wissensintensiven Prob- lemlösungsprozessen sind die Vorteile der untersuchten Ansätze zu integrieren. Die Anforde- rungen, welche durch die Ansätze nicht in ausreichendem Maße abgedeckt werden, wie z.B. der Berücksichtigung der Expertisestufen sowie der Qualitätssicherung durch Quality Gates, sind, müssen in der Entwicklung der Systematik besonders berücksichtigt werden. Systeme zur Unterstützung der Problemlösung Die untersuchten Systeme zur Unterstützung der Problemlösung sind für komplexe, wissens- intensive Probleme nur bedingt geeignet, da der menschliche Problemlöser bei der Lösungs- findung und -entwicklung weder angeleitet noch unterstützt wird (A4, A5, A6). Alle Ansätze unterstützen das individuelle Problemlösen (A3), eine Unterstützung der kooperativen Prozes- se ist nicht in ausreichendem Maße möglich (A8). Die Analyse der Systeme zur Unterstützung der Problemlösung hat gezeigt, dass hier ein großer Bedarf besteht, den Problemlöser mit einem geeigneten Assistenzsystem zu unterstützen. Aus der Bewertung der untersuchten Ansätze lassen sich für die Entwicklung der Systematik folgende Bedarfe zusammenfassen: Abbildung 11: Ableitung der Zielsetzung für die Entwicklung der Systematik Problemtypologie und –klassifikation Systeme zur Unterstützung der Problemlösung Kapitel 4 Kapitel 5 Kapitel 6 •Entwicklung eines Schemas zur Problem- und Aufgabenklassifikation •Entwicklung eines Beschreibungsmodells für Probleme im Engineering - Untersuchung der Klassifikationskriterien auf ihre Praxisrelevanz - Identifikation von Primärkriterien und Gruppierung zu Problemklassen •Ableitung eines Gestaltungsrahmens Problemprävention und Problemlösung • Integration und Kombination von Teilaspekten aus bestehenden Ansätzen zu einer ganzheitlichen Systematik mit den Schwerpunkten: - Organisation und Koordination von Problemlösungsprozessen - Kommunikation und Wissensaustausch - Wissensintegration und Wissensgenerierung • Entwicklung eines Problemlösungsassistenten 54 Ausgehend von dieser Bewertung wird in den folgenden Kapiteln anhand der Anforderungen eine Systematik zur Gestaltung und Optimierung wissensintensiver, kooperativer Problemlö- sungsprozesse abgeleitet. 4 Ableitung eines Gestaltungsrahmens für die wissensintensive, kooperative Problemlösung Im Kapitel 4 wird auf Basis der im Kapitel 3 beschriebenen Ansätze durch die Kombination verschiedener Klassifikationsmodelle zur Beschreibung von Problemen (z.B. Schroda /134/, Dörner /41/, Kersting /81/) mit den Problemlösungsmodellen (z.B. Primus /117/) ein Gestal- tungsrahmen abgeleitet, der den beschriebenen Anforderungen gerecht wird. Ziel ist, die bestehenden Klassifikationskriterien zu untersuchen und durch die Identifikation von Primärkriterien zu gruppieren. Dies liefert die Basis für die Entwicklung eines Beschrei- bungsmodells für Probleme im Engineering, welches wiederum die Grundlage für die Ablei- tung eines Gestaltungsrahmens für wissensintensive, kooperative Problemlösungsprozesse darstellt. 4.1 Vorgehen zur Ableitung eines Gestaltungsrahmens Das Vorgehen zur Ableitung des Gestaltungsrahmens umfasst folgende drei Schritte (vgl. Abbildung 12): 1. Entwicklung eines ersten Schemas zur Problem- und Aufgabenklassifikation 2. Entwicklung eines Beschreibungsmodells für Probleme im Engineering Umfeld 3. Ableitung des Gestaltungsrahmens für wissensintensive, kooperative Problemlösungs- prozesse. Zur Entwicklung des Schemas zur Problem- und Aufgabenklassifikation wurde im Rahmen von Experteninterviews mit Entwicklungsingenieuren im Arbeitsumfeld innerhalb einer Woche aufgetretene Problemsituationen protokolliert und aufgenommen sowie das Vorgehen zur Lö- sung von Problemen anhand eines Fallbeispiels festgehalten und analysiert. Dies diente dazu, ein umfassendes Bild der Arbeitssituation eines Entwicklungsingenieurs aufzunehmen und zu verstehen und bereits Primärkriterien für die Einteilung von Problemen zu definieren. Zur Entwicklung des Beschreibungsmodells wurden in Ergänzung dazu die in der Literatur beschriebenen Problemkategorien umfangreich analysiert. Die ermittelten 27 Problemkatego- rien wurden durch die Erstellung eines Fragebogens für den Engineeringbereich messbar ge- macht. Jede Kategorie wurde dabei durch ca. 3 Fragen operationalisiert. Das primäre Ziel der Untersuchung war, aus den bereits bestehenden Problemkategorien sinnvolle übergeordnete Kategorien zu finden, unter die sich die bestehenden, bereits be- schriebenen Kategorien unterordnen lassen. Deshalb wurden Hypothesen aufgestellt, um mögliche Zusammenhänge zwischen den Problemkategorien zu identifizieren. Die ermittelten Problemkategorien und Hypothesen wurden schließlich im Rahmen einer Befragung validiert, und die 27 Problemkategorien konnten zu 6 Problemklassen gruppiert werden. Die identifizierten Problemklassen wurden dann im Hinblick auf ihre Implikationen auf den Problemlösungsprozess untersucht, und es wurden Handlungsfelder zur Gestaltung des Prob- lemlösungsprozesses ermittelt. Diese Handlungsfelder dienten schließlich zur Ableitung des Gestaltungsrahmens für wissensintensive, kooperative Problemlösungsprozesse. 56 Abbildung 12: Vorgehen zur Ableitung eines Gestaltungsrahmens 4.2 Schema zur Problem- und Aufgabenklassifikation Zur Ableitung eines groben Klassifikationsschemas wurden zunächst Arbeitssituationen in den frühen Phasen der Produktentstehung untersucht. Dazu wurden insgesamt 18 Ingenieure aus dem Entwicklungsbereich von vier unterschiedlichen Unternehmen befragt. Als Untersuchungsmethode wurde das halbstrukturierte Interview zur Datenerhebung gewählt, um die theoretisch erarbeiteten Kriterien deduktiv zu überprüfen. Diese Form des Interviews bot die Möglichkeit, beschriebene Sachverhalte zu hinterfragen und damit später die genann- ten Probleme detailliert zu beschreiben. Als Kernfrage der Interviews diente die Frage nach den im Arbeitsalltag aufgetretenen Ar- beitssituationen im Entwicklungsbereich insbesondere hinsichtlich der verteilten Zusammen- arbeit und der Verfügbarkeit bzw. des Bedarfs von Wissen zur Lösung einer Aufgabe bzw. eines Problems. Vor den Interviews wurden die Experten gebeten, ein Wochenprotokoll anzu- legen, in dem sie so viele Problem- bzw. Aufgabenstellungen wie möglich strukturiert be- schrieben, die im Laufe einer Woche bei ihnen aufgetreten sind. Zudem wurden sie gebeten, anhand eines konkret in dieser Woche aufgetretenen Fallbeispiels aus ihrem Arbeitsalltag ihr Vorgehen zur Problemlösung zu beschreiben. Im Interview wurden dann diese Ergebnisse diskutiert und analysiert. Als Primärkriterien zur Einteilung der Arbeitssituationen der befragten Entwicklungsingenieure konnten der Strukturierungsgrad (strukturiert vs. unstrukturiert) sowie der Zeithorizont (ad-hoc vs. langfristig) identifiziert werden. Strukturierungsgrad – strukturiert vs. unstrukturiert Es hat sich gezeigt, dass bei allen untersuchten Unternehmen die unstrukturierten Arbeitsauf- träge, überwiegen. So liegt in etwa 50-62% der untersuchten Fälle ein geringer Strukturiert- heitsgrad vor, d.h. die Informationen zur Lösung und ein Vorgehensplan zur Lösung (ein Ver- Ableitung eines Gestaltungsrahmens für wissensintensive, kooperative Problemlösungsprozesse Schema zur Problem- und Aufgabenklassifikation Beschreibungsmodell für Probleme im Engineering Umfeld Definition von Problemkategorien Bildung von Hypothesen Validierung der Kategorien und Hypothesen durch empirische Erhebung Erhebung über 18 Interviews mit Entwicklungsingenieuren Ableitung von Problemklassen Identifikation von Handlungsfelder aus Problemklassen Ableitung von Gestaltungselementen: - Organisation und Koordination - Kommunikation und Wissensaustausch - Wissensintegration und -entwicklung 57 fahren, welches in endlicher Anzahl von Schritten zur Lösung führt) liegt nicht vor. Hierbei handelt es sich um ein Problem bzw. eine Problemstellung. Ein hoher Strukturiertheitsgrad liegt bei 38-50 % der Fälle vor. Dies bedeutet, dass alle zur Lösung erforderlichen Informatio- nen bereits vorliegen sowie der Lösungsweg bekannt ist. Diese Kategorie entspricht den Auf- gaben bzw. Aufgabenstellungen. Zeithorizont – ad-hoc vs. langfristig Die Untersuchung hat weiter ergeben, dass über alle Unternehmensgrößen hinweg Probleme und Aufgaben überwiegen, die sehr kurzfristig zu lösen sind. Allerdings ist das Kriterium Zeit bei etwa einem Drittel der Probleme und Aufgaben weniger relevant, d.h. für deren Lösung steht ausreichend Zeit zur Verfügung. Der hohe Anteil „ad-hoc“ Aufgaben und Probleme zeigt die für den Entwicklungsbereich typischen Zeitdruck sowie die hohe Dynamik bei den Prob- lemlösungsprozessen. Gleichzeitig nimmt die Schwierigkeit der Problemlösung zu, wenn sich die verfügbare Bearbeitungszeit z.B. aufgrund mangelnder Kapazität oder Termindruck redu- ziert (Ehrlenspiel /44/). Der Anteil der Probleme, die in gleicher oder ähnlicher Form wieder auftreten, liegt zwischen 70% und 75%. Nur eine sehr geringe Anzahl von Problemen tritt nicht wieder auf. Dies weist darauf hin, das eine Systematisierung des Problemlösungsprozesses sowie eine strukturierte Dokumentation sinnvoll sind. Die in den Interviews beschriebenen Problemsituationen der Entwicklungsingenieure wurden diesen beiden Primärkriterien zugeordnet. Aus der Untersuchung ergab sich somit folgende Problem-Aufgaben-Matrix (vgl. Abbildung 13): Abbildung 13: Problem-Aufgaben-Matrix Im ersten Quadranten (Q1) befinden sich gut strukturierte Aufgaben, welche in einem kurzen Zeitraum gelöst werden müssen. Das Vorgehen zur Lösung ist dabei bekannt. In den zweiten Quadranten (Q2) werden Aufgabenstellungen eingeordnet, die ebenfalls durch einen hohen Strukturiertheitsgrad gekennzeichnet sind, jedoch einen längeren Zeitraum zur Lösung bedür- fen. Im dritten Quadranten (Q3) befinden sich Probleme, die ad-hoc gelöst werden müssen. Zeithorizontad-hoc langfristig unstrukturiert strukturiert Strukturierungsgrad Q 4Q 3  Unbekannter Produktfehler  Unbekannter Materialfehler  Unbekannter Prozessfehler (z.B. bei Rapid Prototyping-Prozess)  Unbekannter Stand der Bemusterung  Machbarkeit nicht bekannt  Arbeitsabläufe nicht klar oder unbekannt  Synchronisation Prozesse/Aufträge unbekannt  Unbekannter Systemausfall  Unklare Konstruktionsänderungen  Unklare Zuständigkeiten  Unbekannter Fehler bei Zusammenbau von externen Bauteilen (Passung)  CAD-Konstruktion erstellen  Anpassung von Bauteilen bei Zusammenbau  Kontinuierliche Weitergabe von Änderungen des Montageablaufs  Prüfung von Bauteilen  Änderung d. Beschriftung e. Produkts  Fehlende Ausgangskontrolle  Verzug bei z.B. Werkzeugbeschaffung  Fehlende Prüfvorschriften  Fehlendes, bzw. unvollständiges Lastenheft Q 2Q 1 58 Das Vorgehen zur Lösung ist aber unbekannt. In den vierten Quadranten (Q4) werden Prob- leme eingruppiert, deren Lösung einige Zeit erfordert. Zudem ist der Lösungsweg unbekannt. 4.3 Beschreibungsmodell für Probleme im Engineering-Umfeld Da der Schwerpunkt dieser Arbeit auf der Untersuchung von Problemen bzw. Problemstellun- gen liegt (vgl. Abbildung 13), deren Lösung produktives Denken sowie die Schaffung von Neuem erfordert, wurde einen Einschränkung der weiteren Untersuchungen auf die Quadran- ten 3 und 4 vorgenommen. Hintergrund der Entwicklung des Beschreibungsmodells war die Überlegung, Probleme, die im Entwicklungsbereich auftreten können, zu kategorisieren und besser fassbar zu machen. In der wissenschaftlichen Literatur sowie in praktischen Überlegungen wurden bislang viele ver- schiedene Arten von Problemen beschrieben. So entstanden sehr unterschiedliche Definitio- nen und auch Kategorien von Problemen, was in der Praxis für Verwirrung gesorgt hat. Diese Studie sollte daher dazu dienen, herauszufinden, welche Formen von Problemen im Entwicklungsbereich wirklich auftreten können. Dazu wurden die Untersuchungsteilnehmer gebeten, einen Arbeitsauftrag und ein darin entstandenes Problem näher zu beschreiben und darauf bezogene Fragen zu beantworten. Die Fragen wurden den schon bestehenden Prob- lemkategorien aus der wissenschaftlichen Literatur bzw. eigenen Überlegungen entnommen. Zu jeder Kategorie gab es mehrere Fragen. Das Ziel war, durch die Antworten der Teilnehmer zu erfahren, ob es bestimmte übergeordne- te Kategorien gibt, unter die sich die schon bestehenden Kategorien unterordnen und die Probleme im Entwicklungsbereich einfacher beschreiben lassen. Diese machen es leichter, Probleme zu beschreiben und diese aufzudecken. Anhand dieser Überkategorien könnten z.B. Personen, die im Entwicklungsbereich arbeiten, angeleitet werden, ihre entstandenen Proble- me genauer zu betrachten, wodurch mehr Aufschluss darüber entstehen würde, um welche Art von Problem es sich gerade handelt. Diese Überkategorien dienen weiter dazu, Anforde- rungen an die Unterstützung des Problemlösungsprozesses zu spezifizieren. So kann der Problemlösungsprozess hinsichtlich der Bereitstellung von Methoden als auch notwendiger Wissensprozesse spezifisch an die jeweilige Problemkategorie angepasst werden. Im folgenden wird zuerst noch einmal der Begriff Problem für die Untersuchung definiert, an- schließend werden die ermittelten Problemkategorien, die Hypothesen, das Ziel der Untersu- chung, das methodische Vorgehen sowie zuletzt die Ergebnisse ausführlich beschrieben. 4.3.1 Problemdefinition Grundsätzlich wurden bei der Definition von Problemen zwei Problemarten abgegrenzt. Diese Abgrenzung entstand aus eigenen Überlegungen darüber, welche Art von Problemen in dieser Untersuchung von Bedeutung sein soll. Es wurde dabei unterschieden zwischen: • Problemen aufgrund des Arbeitsauftrages selbst: Probleme können direkt aufgrund des Arbeitsauftrages entstehen. Er ist eventuell zu kompliziert formuliert, die Ziele sind nicht klar abgesteckt oder er wurde schlecht kommuniziert. Auf dieser Art von Problem soll je- doch nicht der Fokus liegen, sondern viel mehr auf Problemen als Störgröße. • Problemen als Störgröße: Probleme als Störgröße entstehen mitten in einem Prozess. Der Arbeitsauftrag selbst ist dabei nicht das Problem, denn es wurde bereits begonnen ihn 59 zu bearbeiten. Während der Bearbeitung des Arbeitsauftrages tritt unvorhergesehen und ungeplant eine Störung auf, die das Problem hervorruft. Weiterhin beruht die Problemdefinition dieser Untersuchung auf einer Zusammenstellung be- stehender wissenschaftlicher Literatur sowie eigenen Überlegungen. In die Gesamtdefinition von Problemen fließen folgende Definitionen ein: • Ein Problem ist gegeben, wenn es eine Schwierigkeit zwischen einem Ziel und den verfüg- baren Mitteln zur Verwirklichung des Zieles gibt (Dewey /30/). • Ein Problem entsteht, weil eine Differenz zwischen einem unerwünschtem Ist-Zustand und einem erwünschten Soll-Zustand liegt (Daenzer/Huber et al. /24/, Dörner /41/, Kersting /81/, Sell /141/). • Ein Problem erfordert produktives Denken, da etwas Neues geschaffen werden muss. Auf- gaben erfordern nur reproduktives Denken, da der Lösungsweg bekannt ist. (Dörner /41/, Schroda /135/). • Ein Problem an sich gibt es nicht, sondern ein Problem muss immer aus der Perspektive des Problemlösers gesehen werden. Es ist abhängig von der Person, ob ein Problem als ein Problem gesehen wird oder nicht. Zum einen ist es abhängig von motivationalen und emotionalen Aspekten und zum anderen davon, welche Ressourcen eine Person hat. D.h. eine Person muss durch motivationale und emotionale Vorgänge erst einmal die Relevanz einer Situation bewerten und welche Mittel ihr zur Verfügung stehen um die Situation zu meistern. Erst dann wird eine Situation zu einem Problem oder nicht (Arbinger /7/). Aus diesen wissenschaftlichen Definitionen wurde eine Gesamtdefinition formuliert, die dieser Untersuchung zugrunde liegt: Ein Arbeitsauftrag wird mit bestimmten Anforderungen formuliert. Diese Anforderungen präzi- sieren den Soll-Zustand, der durch die Aufgabenerfüllung erreicht werden soll. Nachdem mit der Bearbeitung des Arbeitsauftrages begonnen wird, tritt ein Problem in Form einer unvor- hergesehenen und ungeplanten Störung auf. Der Soll-Zustand der Arbeitsauftragserfüllung entspricht nicht dem Ist-Zustand der Störung, weshalb ein Weg gefunden werden muss, diese Diskrepanz zu überbrücken. Diese Diskrepanz und der Fakt, dass der Lösungsweg zu dem gewünschten Soll-Zustand nicht bekannt ist, lässt ein Problem entstehen. Es muss erst etwas Neues geschaffen werden anstatt schon bekannte Verhaltensmuster zu reproduzieren. Des- halb handelt es sich auch um ein Problem und nicht um eine Aufgabe. Der Arbeitsauftrag wird auch aus dem Grund zu einem Problem, weil sich die Person, die den Auftrag ausführen soll, persönlich involviert fühlt. Aus emotionaler und motivationaler Sicht hat der Arbeitsauftrag ho- he Relevanz für die Person (sei es aus persönlichem Interesse oder aus Interesse des Unter- nehmens), daher ist ihr eine Erfüllung wichtig. 60 Die Kriterien eines Problems als Störgröße lassen sich daher wie folgt aufzählen: • Dem persönlichen Interesse und dem Interesse des Unternehmens, den Arbeitsauftrag zu erfüllen. • Der Diskrepanz zwischen Störung und Arbeitsauftragserfüllung Arbeitsauftragr eitsa ftra Arbeitsauftrags- erfüllung Soll-Zustand r eitsa ftra s- erf ll oll- ustand Diskrepanziskre a z Störung Ist-Zustand t r Ist- ustand • Dem unbekannten Lösungsweg, um einen Arbeitsauftrag erfüllen zu können Lösungsweg ist unbekannt etwas Neues muss geschaffen werden i t eka t t s s uss gesc ffen rden Arbeitsauftragr itsa ftr Störung Ist-Zustand t r Ist- ustan Arbeitsauftrags- erfüllung Soll-Zustand r it ftra s- rf ll ll- stan 4.3.2 Problemkategorien Aus bestehender wissenschaftlicher Literatur zu Problemlösung und Problemkategorien wur- den möglichst viele Klassifizierungen von Problemen gewonnen. Es sollte ein umfassendes Bild darüber entstehen, welche Arten von Problemen es gibt. Da die Ergebnisse der Untersu- chung der Praxis zugänglich gemacht werden sollen, wurden die eher theoretischen Problem- kategorien ergänzt. Die zusätzlichen Kategorien wurden der Praxis entnommen oder entstan- den durch eigene Diskussionen. Da der Fokus dieser Untersuchung auf der Erfassung von Problemkategorien liegt, beziehen sich die Kategorien meist auf das Problem als Störgröße. Bei einigen Kategorien ist dieser Bezug jedoch nicht möglich, in diesem Fall wurden die Fra- gen auf den Arbeitsauftrag bezogen. • Problem als Arbeitsauftrag vs. Problem als Störgröße (1): In dieser Untersuchung soll es ausschließlich um Probleme als Störgröße gehen. Diese Kategorie dient der Überprü- fung, um sicher zu gehen, dass die Untersuchungsteilnehmer wirklich die Definition von Problemen als Störgröße verstehen. Die Kategorie entstand durch eigene Überlegungen. • Kenntnis des Lösungswegs (2): In dieser Untersuchung wird von Problemen ausgegan- gen, bei welchen der Lösungsweg nicht bekannt ist. Diese Kategorie dient ebenfalls der Überprüfung, ob die Untersuchungsteilnehmer von der richtigen Definition von Problemen ausgehen. Die Kategorie geht von der Definition von Problemen im Gegensatz zu Aufga- ben aus (Dörner /41/, Schroda /135/). • Handlungsspielraum (3): Der Handlungsspielraum beschreibt die Möglichkeit, eigene Entscheidungen in Bezug auf Arbeitsverfahren, Verwendung von Arbeitsmitteln und die zeitliche Organisation der Arbeit zu treffen. Handlungsspielraum stellt eine Ressource der Stressvermeidung dar. Fragen sind dem standardisierten „Fragebogen zur Arbeitsanalyse – KFZA“ entnommen (Prümper et al. /119/). 61 • Kenntnis des Ziels (4): Diese Kategorie entstand aus der Überlegung, dass ein Problem entstehen kann, wenn Personen das Ziel ihrer Arbeit, bzw. ihres Arbeitsauftrags nicht ken- nen. • Klarheit des Ziels (5): Dörner /41/ und Kersting /81/ klassifizieren Probleme danach, ob Ziele klar sind. Diese Kategorie bezieht sich ebenfalls auf den Arbeitsauftrag: Ist das Ziel des Arbeitsauftrages klar, bzw. verständlich. • Mehrere/widersprüchliche Ziele (6): Schroda (/135/, /134/) beschreibt, dass Probleme dadurch entstehen können, dass jemand mehrere Ziele bearbeiten muss, die sich gegen- seitig jedoch widersprechen. Auf diese Untersuchung bezogen bedeutet dies, dass Prob- leme entstehen können, wenn ein Arbeitsauftrag mehrere widersprüchliche Ziele beinhaltet und wenn parallel andere Arbeitsaufträge bearbeitet werden sollen. • Transparenz über Ausgangsbedingungen und Ziel (7): Dörner /40/ und Schroda /135/ verweisen auf Probleme, die entstehen können, wenn die objektive Verfügbarkeit, also das Vorhandensein und die mögliche Beschaffbarkeit von Informationen zu den Ausgangsbe- dingungen und zum angestrebten Ziel fehlen. Auch bei dieser Kategorie liegt der Bezug auf der Ausgangsbedingung und dem Ziel des Arbeitsauftrags. • Wissensintegration (8): Übergang von implizitem Wissen einer Person in implizites Wis- sen mehrerer (Ganz/Warschat /51/). Diese Kategorie beschreibt Probleme, die entstehen, wenn mehrere Personen nicht das gleiche Verständnis vom selben Sachverhalt/Problem haben. Dies tritt häufig auf, wenn Personen aus unterschiedlichen Fachbereichen zusam- men arbeiten. • Kommunikation (9): Interaktion zwischen Individuen. Nach Ganz/Warschat /51/ können Probleme entstehen, wenn rege Kommunikation mit anderen fehlt. • Informationskoordination (10): Nonverbaler, oft schriftlicher, elektronischer Austausch von Informationen (Ganz/Warschat /51/). Oft fehlt Personen die notwendige Information zu einem Problem in schriftlicher Form. • Bekanntheit der Ressourcen/Mittel (11): Dörner /41/ und Kersting /81/ klassifizieren Probleme danach, ob die Mittel, bzw. die Ressourcen zur Problemlösung bekannt sind. • Technisches/fachliches Problem vs. Managementproblem (12): Auf der einen Seite kann es Probleme geben, die fachlicher Art sind, die also direkt durch das Produkt entste- hen, auf der anderen Seite können Probleme auch aus einem Prozess oder Arbeitsablauf entstehen (Managementproblem). Diese Kategorie entstand aus eigenen Überlegungen und Erfahrungen aus der Praxis. • Komplexität des Aufgaben- bzw. Anforderungsbereichs (13): Schroda (/135/, /134/) klassifiziert Probleme unter anderem auch danach, dass der Aufgabenbereich sehr kom- plex sein kann. Komplexität hängt einerseits von der Anzahl der Teilfunktionen und ande- rerseits von der Vielfalt der Verknüpfungen ab. Die Komplexität bezieht sich daher nicht di- rekt auf das Problem sondern auf den Arbeitsauftrag. • Dynamik des Problems (14): Ein Problem kann entstehen, wenn es sich ohne Zutun des Problemlösers, durch Änderungen in der Umwelt, verändert (Schroda /135/, Schroda /134/). • Abstraktheit des Problems (15): Ein Problem kann so abstrakt sein, dass es nur schwer eindeutig fassbar ist (Schroda /135/). 62 • Individuelles vs. kollektives Problemlösen (16): Brander et al. (zitiert nach Arbinger /7/) kategorisieren Probleme darin, wie viele Personen an der Bearbeitung des Problems betei- ligt sind. Die Frage ist dabei, ob die Zusammenarbeit für die Lösung des Problems notwen- dig war. • Problem mit vs. ohne Zeitdruck (17): Probleme können dadurch entstehen, dass Zeit- druck besteht, bzw. dass nicht genügend Zeit verfügbar ist (Brander et al.,zitiert nach Ar- binger /7/). Einige Problemkategorien beziehen sich auf das Wissen, das die Personen bei der Problem- bearbeitung verwenden. Um diese Kategorien sinnvoll in einen Zusammenhang zu bringen wurde ein Wissensmodell aufgestellt, anhand dessen die Kategorien abgeleitet wurden. Die- ses Wissensmodell orientiert sich ebenfalls an bestehender wissenschaftlicher Literatur zu Wissen im Problemkontext und fasst diese sinnvoll zu einem Modell zusammen. Nach Ha- mel/Prahalad (/61/,/116/) wird grundsätzlich die Unterscheidung von Wissen in Fachwissen, Methodenwissen und Sozialwissen vorgenommen. Diese Aufteilung geht in die drei für dieses Wissensmodell erstellten Wissensbereiche ein. Die drei Unterscheidungen von Wissen sind: Vorerfahrung und Wissensgenerierung Eine Person besitzt einen individuellen Wissensbestand durch Vorerfahrung. Bei mangelnder Vorerfahrung kann ein Problem entstehen, weil die Person keine Erfahrung hat, wie sie vorge- hen soll (in Anlehnung an Dörner /41/ und Sell /141/). Wenn keine Vorerfahrung besteht, muss die Person individuelles oder kollektives Wissen von außen generieren. Wenn das auch nicht ausreicht, muss die Person individuell oder kollektiv völlig neue Erkenntnisse gewinnen (Hes- se /69/, Hesse/Spies et al. /70/). Die Problemkategorien, die für diese Untersuchung verwen- det wurden, sind daher: • Wissen aufgrund von eigener Vorerfahrung (individuell) (18). • Wissensgenerierung (19): Wissen, das durch äußere Informationen gewonnen werden muss, weil eigenes Wissen nicht ausreicht (individuell und kollektiv) oder Wissen, das völlig neu gewonnen werden muss (individuell und kollektiv). Problembezogenes Wissen Die inhaltliche Aufteilung des Wissens erfolgt in Fach-, Methoden- und Sozialwissen mit Be- zug auf das konkrete Problem. Die Aufteilung lehnt sich an Schrodas (/135/, /134/) Unter- scheidung zwischen spezifischem Sachwissen (bzw. Fachwissen) und Methodenwissen. Die Problemkategorien sind demnach: • Problembezogenes Fachwissen (20): Wissen über Begriffe, Zustände, Ereignisse, ge- setzmäßige Zusammenhänge und Bedingungen des Problembereichs. • Problembezogenes Methodenwissen (21): Eindeutig definierte Verfahren, die in der Problemsituation zur 100%-igen Lösung führen. • Problembezogenes Sozialwissen (22): Wissen, dass die Zusammenarbeit mit anderen für die Lösung des Problems förderlich ist. 63 Hintergrundwissen Die inhaltliche Aufteilung wird hier nicht problembezogen betrachtet, sondern alles Fach-, Me- thoden- und Sozialwissen, das über den Problembezug hinausgeht (das jeweilige Hinter- grundwissen) steht im Fokus. Auch Arbinger /7/ unterscheidet Probleme, bei denen Hinter- grundwissen notwendig ist von jenen, bei denen dies nicht der Fall ist. Die aufgestellten Prob- lemkategorien dieser Wissensart sind: • Bezogen auf Fachwissen (23): Allgemeines Wissen über Eigenschaften von Materialien und Werkzeugen. • Bezogen auf Methodenwissen (24): Allgemeine Lösungsstrategien: heuristische Strate- gien oder Metaprozeduren, z.B. Organisieren und Planen von Handlungen. • Bezogen auf Sozialwissen (25): Sozialkompetenz, bzw. der allgemeine Umgang mit Men- schen. Problembezogenes Wissen roble bezogenes isse Hintergrundwisseni ter r d isse Vorerfahrung und Wissensgenerierung orerfahrung und isse s e erieru • Problembezogenes Fachwissen • Problembezogenes Methodenwissen • Problembezogenes Sozialwissen • roble bezogenes Fach issen • roble bezogenes ethoden issen • roble bezogenes ozial issen • Vorerfahrung (indiv.) • Wissensgenerierung durch äußere Informationen oder Wissen, das neu generiert werden muss (indiv.& kollekt.) • orerfahrung (indiv.) • issensgenerierung durch äußere Infor ationen oder issen, das neu generiert erden uss (indiv. kollekt.) • Bezogen auf Fachwissen • Bezogen auf Methodenwissen • Bezogen auf Sozialwissen • ezogen auf ach issen • ezogen auf ethoden issen • ezogen auf ozial issen Abbildung 14: Wissensmodell Weiterhin wurden zwei Kategorien in die Untersuchung einbezogen, die sich konkret auf die Problemlösung beziehen: • Freiheitsgrade bei der Problemlösung (26): Hoher Freiheitsgrad heißt es besteht eine hohe Menge an möglichen Lösungswegen oder Lösungsvarianten, welche alle zum ange- strebten Ziel führen (Dörner /40/ , Schroda /135/, /134/).). Probleme lassen sich danach klassifizieren, wie viele Freiheitsgrade bei der Problemlösung bestanden. • Ad-hoc vs. langfristiger Zeithorizont der Problemlösung (27): Eine weitere Unterschei- dung von Problemen kann nach dem Zeithorizont ihrer Lösung erfolgen. Besteht die Mög- lichkeit des wiederholten Auftretens eines Problems, so handelt es sich um ein repetitives Problem. Dabei treten in der Praxis Probleme oft in einer ähnlichen Form wieder auf, sie unterscheiden sich lediglich durch einige wenige Eigenschaften. Neuartige Probleme treten im Gegensatz dazu nach deren Lösung in der Regel nicht wieder auf. Brauchlin & Heene /16/ nehmen eine ähnliche Klassifikation vor. Treten Probleme wiederholt in ähnlicher Form wieder auf, sind also nicht einmaliger Einzelfall, so ist eine Implementierung bzw. Standar- disierung des Problemlösungsprozesses sinnvoll. Die beschriebenen Problemkategorien wurden durch die Erstellung eines Fragebogens für den Engineeringbereich messbar gemacht. Jede Kategorie wurde dabei durch 3 Fragen ope- rationalisiert (siehe Anhang Kap. 10.1). Die Untersuchungsteilnehmer geben in dem Fragebo- 64 gen zu Beginn ein Beispielproblem an, welches sie durch die Fragen zu den Problemkatego- rien einschätzen. Dadurch wird möglich, typische Probleme im Arbeitsalltag zu erfassen und übergeordnete Problemkategorien zu identifizieren. 4.3.3 Hypothesen und Ziel der Untersuchung Die im Abschnitt 4.3.2 beschriebenen Problemlösungskategorien zeigen, dass in der Literatur, sowie in der Praxis ein sehr differierendes Verständnis darüber vorliegt, welche Arten von Problemen bei der Arbeit vorliegen. Das primäre Ziel der Untersuchung ist daher, aus den bereits bestehenden Problemkategorien sinnvolle übergeordnete Kategorien zu finden, unter die sich die bestehenden, bereits beschriebenen Kategorien unterordnen lassen. Weiterhin gewährleistet die Untersuchung: • Ein verbessertes Verständnis von Problemen im Arbeitsalltag (mit spezifischem Bezug auf den Engineeringbereich) • Eine Übersicht über vorherrschende Probleme im Engineeringbereich • Erkenntnisse über Problemlösungsprozesse sowie die Erfassung von Problemen • Eine Bestätigung des verwendeten Wissensmodells Vor der Fragebogenerhebung wurden mehrere Hypothesen aufgestellt, die im Rahmen der Untersuchung getestet werden. Da die Untersuchung zum Ziel hat, eine Vereinfachung beste- hender Problemkategorien zu bekommen, steht folgende Hypothese im Zentrum der Untersu- chung: • Hypothese 1: Es gibt bestimmte Problemkategorien (Faktoren) unter die sich die erhobe- nen Kategorien unterordnen lassen. Alle weiteren Hypothesen wurden durch Überlegungen über mögliche Zusammenhänge oder Häufigkeiten der einzelnen Problemkategorien gewonnen. • Hypothese 2: Arbeitsaufträge, bei denen das Ziel nicht bekannt ist, mehrere, widersprüch- liche Ziele bestehen und Ziele nicht klar sind, sind häufiger. • Hypothese 3: Die Kenntnis des Ziels, das Verständnis des Ziels, die Bekanntheit der Res- sourcen und die Transparenz über Ziele korrelieren positiv miteinander. • Hypothese 4: Je weniger Vorerfahrung besteht, desto mehr Wissen muss generiert wer- den. • Hypothese 5: Je mehr Sozialwissen, desto besser ist die Wissensintegration. • Hypothese 6: Je besser die Wissensintegration ist, desto mehr Kommunikation findet statt. • Hypothese 7: Wissensintegration, Kommunikation und Informationskoordination korrelie- ren positiv miteinander. • Hypothese 8: Probleme, deren Ressourcen nicht klar sind, sind häufiger. • Hypothese 9: Je mehr problembezogenes Fachwissen, desto weniger technische Proble- me. • Hypothese 10: Je mehr Methodenhintergrundwissen, desto weniger Managementproble- me. • Hypothese 11: Je mehr widersprüchliche Ziele, desto höher die Komplexität. 65 • Hypothese 12: Komplexität, Dynamik und Abstraktheit der Aufgabe korrelieren positiv mit- einander. • Hypothese 13: Je mehr kollektives Problemlösen desto mehr Kommunikation und kollekti- ve Wissensgenerierung. • Hypothese 14: Kollektives Problemlösen ist häufiger als individuelles. • Hypothese 15: Je mehr Handlungsspielraum, desto mehr Freiheitsgrade bei der Problem- lösung. Aus der Untersuchung geht daher nicht hervor, welche Form von Problemen besonders schwierig für die Problemlösung war und was konkret zu einer verbesserten Problemlösung beigetragen hat. Durch eine Frage sollen erste Hinweise erkennbar werden, welche Form von Problemen förderlich oder hinderlich für die Problemlösung sind. Diese erfasst, wie viel Zeit die Personen benötigt haben, das Problem zu lösen. Dahinter steht die Annahme, dass es eine bestimmte Ausprägung von Problemen auf den Problemkategorien gibt, bei welchen län- ge Zeit für die Problemlösung benötigt wurde. Die Zeit der Problemlösung wird daher als Hin- weis der Schwierigkeit eines Problems gesehen. • Hypothese 16: Je mehr Handlungsspielraum, desto weniger Zeit war bei der Problemlö- sung notwendig. • Hypothese 17: Je mehr problembezogenes Wissen, Hintergrundwissen und Vorerfahrung, desto weniger Zeit war bei der Problemlösung notwendig. • Hypothese 18: Je mehr kollektives Problemlösen, desto weniger Zeit bei der Problemlö- sung war notwendig. 4.3.4 Methodisches Vorgehen Das folgende Kapitel gibt Aufschluss über die Untersuchungsdurchführung. In einem ersten Abschnitt ( 4.3.4.1) wird der Untersuchungsrahmen und das Untersuchungsdesign mit seinen Vor- und Nachteilen erläutert. Der zweite Abschnitt ( 4.3.4.2) beschreibt die untersuchte Stich- probe mit relevanten demographischen Daten näher. Im dritten Abschnitt ( 4.3.4.3) wird auf die Operationalisierung der erhobenen Variablen eingegangen, wodurch Aufschluss über das Er- hebungsinstrument gegeben wird. Im letzten Abschnitt ( 4.3.4.4) werden die zur Überprüfung der Hypothesen verwendeten statistischen Auswertungsverfahren beschrieben. 4.3.4.1 Untersuchungsrahmen und Untersuchungsdesign Der Fragebogen wurde, mit Ausnahme weniger Großunternehmen, hauptsächlich in kleinen und mittelständischen Unternehmen erhoben. Die Unternehmen sind über ganz Deutschland verteilt und wurden durch verschiedene Firmendatenbanken gewonnen. Der Fragebogen wur- de von Personen des Entwicklungsbereiches der befragten Firmen ausgefüllt und postalisch zurück geschickt. Insgesamt wurden 165 Fragebögen verschickt, 10 per Email gesendet und 15 an Projektpartner verteilt. Es handelt sich bei dem Untersuchungsdesign um eine quasiexperimentelle Fragebogenerhe- bung in der natürlichen Umgebung der Untersuchungsteilnehmer. Die Fragebögen wurden an die Teilnehmer der verschiedenen Firmen auf nicht randomisierte Weise verteilt. Das vorlie- gende Untersuchungsdesign lässt sich demnach als Static-Group Comparison Design (Judd et al. /79/) definieren. Der Vorteil dieser Art von Messung ist, dass die Untersuchungsteilneh- 66 mer in ihrer natürlichen Umgebung befragt werden und daher die externe Validität, also die Generalisierbarkeit, erhöht wird. Jedoch ist die Aussagekraft durch die nicht-repräsentative Stichprobe eingeschränkt. Eine Generierung weiterer Probleme, bzw. Einschätzungen weite- rer Personen zu Problemen in ihrem Arbeitsalltag, könnte ein anderes Bild hervorrufen. Wei- terhin ist zu bedenken, dass die Untersuchungsergebnisse lediglich Aussagen über den Engi- neeringbereich treffen können. 4.3.4.2 Stichprobe Von insgesamt 190 verteilten Fragebögen, gingen 21 in die Auswertung ein. Dies entspricht einer Responserate von 11%. Dabei sind sechs Fragebögen aus den Firmen des zugrunde liegenden Forschungsprojekts, die weiteren 15 entstammen anderen Firmen. Fünf Fragebö- gen sind aus einem Großunternehmen der Automobilbranche, die anderen 15 sind aus dem Entwicklungsbereich von kleinen und mittelständischen Unternehmen. Zwei Firmen sind aus der Elektronikbranche, zwei aus der Entwicklungsdienstleistung, und jeweils eine aus der Ge- sundheitsindustrie, der industriellen Automation, der Automatisierungstechnik, der Herstellung von Schneide- und Gießereimaschinen, der Forschung und der Automobilzulieferung. Die Teilnehmer sind zwischen 22 und 56, im Durchschnitt 39, Jahre alt und männlich. Von den 21 Teilnehmern hat einer einen Hauptschulabschluss, zwei haben Mittlere Reife, sieben Fachabitur, 10 das Abitur und einer enthält sich. 14 geben an, eine abgeschlossene Be- rufsausbildung zu besitzen und 16 ein abgeschlossenes Studium. Sie arbeiten seit durch- schnittlich 10 Jahren in ihrer jeweiligen Firma und sind häufig in einer Führungsposition (12 von 21). 4.3.4.3 Fragebogenaufbau Abgesehen von den Instruktionen für die Teilnehmer hat der Fragebogen „Problemlösungs- prozesse“ (siehe Anhang) vier Teile. Der erste Teil (A) umfasst demographische Fragen zu Alter, Geschlecht, schulischer Ausbildung und der aktuellen Arbeitsstätte bzw. dem aktuellen Beruf. Im zweiten Teil B „Problembeschreibung“ ist zunächst eine abstrakte Beschreibung der in der Untersuchung relevanten Probleme und anschließend eine konkretes Beispiel gegeben. Das Beispiel ist dem realen Arbeitsalltag entnommen und wurde von einem kleinen Unternehmen aus dem Prototypenbau beschrieben. Danach werden die Untersuchungsteilnehmer dazu auf- gefordert selbst ein Beispiel, das der vorangehenden Beschreibung entspricht, niederzu- schreiben. Die Teilnehmer sollen einen Arbeitsauftrag und ein Problem in Form einer Störung beschreiben, wobei der Arbeitsauftrag und das Problem zum Zeitpunkt der Erhebung erfüllt sein müssen. Eine Problembeschreibung von den Untersuchungsteilnehmern wird zum einen gefordert, um zu prüfen, ob die Teilnehmer die Problemdefinition verstanden haben und zum anderen, um den Teilnehmern die weitere Fragebogenbearbeitung zu vereinfachen. Alle wei- teren Fragen sind auf das von den Teilnehmern abgegebene Beispiel bezogen. So haben die Fragen einen konkreten Bezug und die Teilnehmer können die Fragen spezifischer beantwor- ten. Um das von den Teilnehmern beschriebene Problem besser zu fassen, sollen diese be- werten, wie viel Zeit sie zur Bearbeitung des Arbeitsauftrages und zur Behebung des Prob- lems benötigt haben. Dies ermöglicht außerdem eine Einschätzung, ob es eine bestimmte Charakteristik von Problemen gibt, die länger Zeit zur Bearbeitung in Anspruch nehmen. Um ganz sicher zu gehen, dass die der Untersuchung zu Grunde liegende Definition von Proble- 67 men von den Untersuchungsteilnehmern verstanden und im Beispiel umgesetzt wurde, wer- den insgesamt sieben weitere, selbst generierte Fragen zu den beiden Problemkategorien 1 und 2 gestellt. Der dritte Teil C „Fragen zum Arbeitsauftrag und dem Problem“ umfasst Fragen zu den Prob- lemkategorien 3 bis 26 (siehe unter 4.3.2). Die Fragen beziehen sich dabei meistens auf das Problem als Störgröße, in einigen Fällen jedoch auch auf den Arbeitsauftrag. Die ersten drei Fragen zu der Kategorie Handlungsspielraum wurden dem standardisierten Instrument „Fra- gebogen zur Arbeitsanalyse – KFZA“ (Prümper et al. /119/) entnommen. Alle weiteren Katego- rien wurden durch je ca. drei Items operationalisiert, die selbst generiert wurden und deren Güte im Anschluss überprüft wird. Der Fragebogen dient somit ebenfalls der Analyse, wie gut die Problemkategorien durch den Fragebogen erfasst werden konnten. Eine Berechnung der Reliabilität durch Cronbach’s Alpha wird durch die Auswertung gewährleistet. Der letzte Teil D „Fragen zu Problemlösungsprozessen“ umfasst insgesamt sieben Fragen, die sich alle auf den Problemlöseprozess direkt beziehen und so einen ersten Eindruck vermitteln sollen, wie die Teilnehmer mit ihrem beschriebenen Problem umgegangen sind. Die Fragen wurden von den Kategorien 26 und 27 abgeleitet und wurden ebenfalls selbst generiert. 4.3.4.4 Statistische Auswertungsverfahren Zunächst werden die Items der jeweiligen Problemkategorien auf deren Güte hin überprüft. Die Genauigkeit der Items, bzw. die Reliabilität, wird hierbei durch eine Interkorrelation der Items, Cronbach’s Alpha, überprüft. Eine hohe Interkorrelation der Items spricht dafür, dass die Items das Gleiche messen und zu einer Skala zusammengefasst werden können. Die Ska- len mit niedriger Reliabilität werden für die weitere Untersuchung ausgeschlossen. Es geht in dieser Untersuchung nicht um die Zusammenhänge zwischen einer abhängigen und einer unabhängigen Variablen, es werden vielmehr die Zusammenhänge in einer Gruppe von Variablen untersucht. Daher ist das statistische Auswertungsverfahren, das in dieser Un- tersuchung im Mittelpunkt steht, die Faktorenanalyse (Test der Hypothese 1). Die Faktoren- analyse ist ein Verfahren der Datenreduktion und bietet die Möglichkeit Variablen, die mitein- ander zusammenhängen, durch hypothetische, übergeordnete Variablen (Faktoren) zu bün- deln. Ausgangsbasis ist daher eine Korrelationsmatrix der erhobenen Variablen, in diesem Falle der Problemkategorien. Die Faktorenanalyse, bzw. genauer die explorative Faktorenana- lyse, „extrahiert“ aus der Korrelationsmatrix Faktoren, die die Zusammenhänge der einzelnen Problemkategorien erklären können. Dazu wird eine orthogonale Varimax-Rotation der Fakto- ren verwendet, die dadurch ausreichend, voneinander unabhängige, Faktoren extrahiert, um die erklärte Varianz zu maximieren. Die erklärte Varianz wird in % angegeben und bedeutet, dass x% der Zusammenhänge der Problemkategorien durch die errechnete Faktorenstruktur erklärt werden kann. Alle weiteren Hypothesen werden durch eine Produkt-Moment-Korrelation nach Pearson ge- testet bzw. durch Häufigkeiten dargestellt. 4.3.5 Ergebnisse Die Hypothese 1, dass es bestimmte Problemkategorien gibt, unter die sich die erhobenen Kategorien unterordnen lassen, konnte bestätigt werden. Die Hypothese 2, dass Arbeitsauf- träge häufiger sind, deren Ziele nicht bekannt sind, bei welchen mehrere, widersprüchliche Ziele eher bestehen und Ziele nicht klar sind wird in Abbildung 15 dargestellt. 68 Abbildung 15: Verteilung der Mittelwerte der Problemkategorien von einer Skala von 1 (trifft überhaupt nicht zu) bis 5 (trifft ganz genau zu) Da die Problemkategorien zur Kenntnis des Ziels und zu mehreren/widersprüchlichen Zielen aus der Untersuchung ausgeschlossen wurden, wird ausschließlich betrachtet, ob das Ziel der beschriebenen Arbeitsaufträge klar war oder nicht. In Abbildung 15 zeigt sich, wie die Problemkategorien in der Stichprobe ausgeprägt waren. Dabei wird deutlich, dass die Ziele fast vollständig verstanden wurden, die Hypothese 2 daher nicht bestätigt werde kann. Anhand der Graphik kann ebenfalls die Hypothese 8 und 14 über- prüft werden. Hypothese 8 nimmt an, dass es häufiger Probleme gibt, deren Ressourcen nicht klar sind. Der Mittelwert der Angaben der Versuchspersonen liegt bei dieser Problemkategorie bei etwas über dem Mittel. Die Teilnehmer geben daher eher an, die Ressourcen der Problem- lösung zu kennen als nicht zu kennen. Hypothese 8 muss daher ebenfalls verworfen werden. Hypothese 14 untersucht, ob kollektives Problemlösen bei der Stichprobe vorherrscht oder nicht. Die Antworten zu diesen Fragen liegen im Mittel über 4 (=trifft ziemlich zu), weshalb die Hypothese bestätigt werden kann. In den restlichen Hypothesen wird nach dem Zusammenhang zwischen verschiedenen Prob- lemkategorien gefragt. Eine Überprüfung dieser Hypothesen, bzw. der Zusammenhänge zwi- schen den Variablen zeigt, dass Hypothese 3 (Zusammenhang zwischen Kenntnis des Ziels, Verständnis des Ziels, Bekanntheit der Ressourcen und Transparenz) teilweise bestätigt wer- den kann. Es zeigt sich ein signifikant positiver Zusammenhang zwischen der Bekanntheit der Ressour- cen und der Transparenz der Ziele. Hypothese 4 (Zusammenhang zwischen Vorerfahrung und Wissensgenerierung) und Hypothese 5 (Zusammenhang zwischen Hintergrundsozialwissen M it te lw e rt 5 , 0 4 , 5 4 , 0 3 , 5 3 , 0 2 , 5 2 , 0 F rei h eitsg rad H inte rg r . s o z ialw iss e n H inte rg r . fach w is se n P roble m so zialw isse n P robl .m eth od e n w isse n P roble m fach w i ss e n W iss e n sg e n e rie ru n g V o re rfah r u ng Z eitd ru ck K ollektiv Dy n a m ik K o m ple xität B e k a n nth . R e s s o u rce n Inf ok o o rdin atio n K o m m u nika tio n W iss e n sinteg r atio n T ra n s p a re n z V e rstä nd nis Zi el K e n nt nis Ziel H a ndl u ng s spie lra u m 5 - Trifft ganz genau zu 1 - Trifft überhaupt nicht zu 3 - Mitte 69 sowie problembezogenem Sozialwissen und Wissensintegration) werden nicht bestätigt. Auch die Hypothese 6, die einen Zusammenhang zwischen Wissensintegration und Kommunikation annimmt sowie die Hypothese 7, die einen Zusammenhang zwischen Wissensintegration, Kommunikation und Informationskoordination postuliert, können nicht bestätigt werden. Hypo- these 9, 10 und 11 können nicht überprüft werden, da die Kategorie 12 sowie die Kategorie 6 nicht in die Untersuchung aufgenommen wurden. Bei einer Überprüfung der Hypothese 12 zeigt sich eine signifikante Korrelation zwischen Komplexität und Dynamik und kann somit teilweise bestätigt werden. Die Hypothese 13 kann ebenfalls teilweise bestätigt werden, es zeigen sich signifikante Korrelationen zwischen kollek- tivem Problemlösen und Kommunikation sowie kollektivem Problemlösen und kollektiver Wis- sensgenerierung, nicht aber zwischen Kommunikation und kollektiver Wissensgenerierung. Eine Überprüfung des Zusammenhangs zwischen Handlungsspielraum und den Freiheitsgra- den bei der Problemlösung zeigt ein signifikantes Ergebnis, weshalb die Hypothese 15 bestä- tigt werden kann. Die drei Hypothesen 16, 17 und 18, die überprüfen, ob verschiedene Prob- lemkategorien mit der Zeit für die Problemlösung zusammenhängen, können nicht bestätigt werden. Insgesamt können zwei zentrale Ergebnisse aus der Untersuchung gewonnen werden. Zum einen die Faktorenstruktur, die durch die Faktorenanalyse erzielt wurde und zum anderen die Zusammenhänge der Problemkategorien. Die Faktorenstruktur gibt darüber Aufschluss, wel- che übergeordneten Problemkategorien im Entwicklungsbereich auftreten können. Dabei wur- den die bestehenden Problemkategorien aus Literatur und praktischer Erfahrung untersucht und es wurden sechs unabhängige Faktoren gefunden, die erklären können, welche überge- ordneten Problemformen es gibt unter die sich die untersuchten, bereits bestehenden unter- ordnen lassen. Jede übergeordnete Problemkategorie gibt an, welche untergeordneten Prob- lemkategorien mit ihr in Verbindung stehen. In Tabelle 2 werden die einzelnen Faktoren aus- führlich beschrieben. 70 Klasse (Faktor) Problemkategorien Beschreibung K1= Handlungs- einschränkungen - Handlungsspielraum - Transparenz - Hintergrundfachwissen - Freiheitsgrade Es bestehen Handlungseinschränkungen der Problemlöser. Sie haben nicht genügend Handlungsspielraum, nicht genügend Transparenz über den Arbeitsauftrag, der Arbeitsauftrag fällt nicht in ihren fachlichen Bereich, es fehlt an Hintergrundfachwis- sen. Bei der Problemlösung müssen ausreichend Freiheitsgrade zur Handlungsausführung sowie Transparenz geschaffen wer- den. K2= fehlende problembezogene Strategie - Bekanntheit Ressourcen - Wissensgenerierung - Problembezogenes Fach- wissen - Problembezogenes Me- thodenwissen Es fehlt eine problembezogene Strategie der Problemlöser. Zu fehlender Bekanntheit der Mittel zur Problemlösung kommt feh- lendes Fachwissen bezüglich des Problems und fehlendes Wis- sen über den allgemeinen Umgang mit dem Problem hinzu. Bei der Problemlösung muss viel Wissen generiert werden. K3= kritischer Zustand des Ar- beitsauftrags und des Problems - Verständnis d. Ziels - Komplexität - Dynamik - Kollektive Problemlösung - Problembezogenes Sozi- alwissen Es besteht ein kritischer Zustand des Arbeitsauftrages, in Form von hoher Komplexität und einem mangelnden Verständnis des Ziels, als auch des Problems, in Form von einem dynamischen Problem. Diese Kategorie von Problemen erfordert das Wissen der Problemlöser, das für die Problemlösung die kollektive Bear- beitung und die Einbeziehung anderer in die Problembearbei- tung erforderlich ist. K4= Zeitdruck und Kompetenz - Zeitdruck - Problembezogenes Me- thodenwissen - Hintergrundsozialwissen Die Lösung der Probleme dieser Kategorie geschieht unter viel Zeitdruck. Die Problemlöser müssen eine hohe Methodenkom- petenz im Umgang mit Problemen und eine hohe Sozialkompe- tenz einbringen. K5= Zeitdruck und Kooperation - Kommunikation - Zeitdruck - Problembezogenes Sozi- alwissen Diese Probleme lassen sich dadurch beschreiben, dass viel Zeitdruck besteht und wenig mit anderen kommuniziert wird. Es fehlt das Wissen der Problemlöser, dass die Kooperation mit anderen für die Lösung des Problems förderlich ist. K6= fehlendes Wissen - Verständnis d. Ziels - Wissensintegration - Vorerfahrung Diese Probleme zeichnen sich durch mangelndes Verständnis des Ziels des Arbeitsauftrags aus. Viel Vorerfahrung muss vor- handen sein und es muss mit anderen an einer gemeinsamen Problemverständigung gearbeitet werden. Tabelle 2: Beschreibung der identifizierten Überkategorien von Problemen (Faktoren) Das zweite Ergebnis, das in dieser Untersuchung zentral ist, sind die Korrelationen zwischen den Problemkategorien. Die Hypothesen dazu ließen sich nur teilweise bestätigen, jedoch wiesen andere Problemkategorien Zusammenhänge auf. Eine ausführliche Auflistung der Kor- relationen ist im Anhang enthalten. 4.4 Implikationen der Problemklassifikation für die Gestaltung und Optimierung von wissensintensiven, kooperativen Problemlösungsprozessen Die Untersuchung der Problemkategorien bietet den Vorteil, dass die Ergebnisse für die Ges- taltung eines optimalen Problemlösungsprozesses genutzt werden können. Wenn Klarheit besteht, welche Formen von Problemen es gibt, kann der Problemlösungsprozess spezifisch auf die identifizierten Problemkategorien angepasst werden, je nach Handlungsbedarf, der sich aus den einzelnen Kategorien ableiten lässt. Da die Untersuchung nicht umfasst, welche Folgen die Ausprägung der einzelnen Problemkategorien hat und welches „der beste Weg“ ist, kann ausschließlich anhand von eigenen Überlegungen aufgestellt werden, wie die Problem- kategorien ausgeprägt sein sollten, um einen möglichst guten Problemlösungsprozess zu er- möglichen. Daraus lässt sich wiederum ableiten, welche Gestaltungsempfehlungen sich bei welcher Ausprägung der Problemkategorien an den Problemlösungsprozess ergeben. 71 Sind die Problemkategorien der Problemklasse K1 niedrig ausgeprägt, hat der Problemlöser also wenig Handlungsspielraum, wenig Transparenz über den Arbeitsauftrag, wenig Hinter- grundfachwissen und wenig Freiheitsgrade bei der Problemlösung, so lässt sich folgende Empfehlung ableiten: Durch ausreichende Handlungsmöglichkeiten kann ein Mitarbeiter Prob- leme lösen, bzw. es kommt vielleicht gar nicht erst zu einem Problem. Zugleich kann die Be- reitstellung von Informationen und Hintergrundwissen über den Arbeitsauftrag die Lösung des Problems unterstützen. Eine Einbettung des Problemlösungsmanagements in bestehende Organisationsstrukturen hilft zudem dabei, klare Verantwortlichkeiten zu definieren und den entsprechenden Rollen im Problemlösungsprozess den notwendigen Handlungsspielraum einzuräumen. Sind die Problemkategorien der Problemklasse K 2 niedrig ausgeprägt, so kennt der Prob- lemlöser die Mittel zur Problemlösung nicht, hat wenig problembezogenes Fachwissen und problembezogenes Methodenwissen. Das heißt, er muss im Rahmen der Problemlösung viel Wissen generieren: 1. darüber welche Mittel ihm zur Verfügung stehen, 2. Fachwissen über den Problembereich und 3. Wissen über allgemeine Lösungsstrategien. Dieses Wissen kann er auf mehrere Arten beschaffen. Er kann andere Personen fragen, bzw. Experten, die sich darüber auskennen. Außerdem kann er in Büchern oder im Internet mehr Informationen nach- lesen. Hilfreich wäre sicherlich auch, wenn z.B. der Umgang mit Problemen, also allgemeine Lösungsstrategien, oder auch Methoden zur Problemlösung auf einfache und leicht zugängli- che Weise dokumentiert wären. Sind die Problemkategorien der Problemklasse K 3, die den Zustand des Arbeitsauftrages beschreiben, hoch ausgeprägt, so ist der Arbeitsauftrag sehr komplex und das Problem dy- namisch. Auch daran kann der Problemlöser selbst wenig ändern. Bei diesem Faktor ist je- doch zusätzlich das Verständnis des Ziels niedrig ausgeprägt und es besteht eine hohe kollek- tive Komponente. Das hieße, dass durch mehr Verständnis über das Ziel des Arbeitsauftrages sich eventuell mehr Klarheit für den Problemlöser ergeben würde, was sich positiv auf den kritischen Zustand des Arbeitsauftrages auswirken könnte. Dieses Verständnis sollte er mög- lichst durch die Zusammenarbeit mit anderen aufbauen und andere in die Problemlösung ein- beziehen. Die Problemkategorien Problemklassen K 4 und 5 beinhalten beide Zeitdruck. Bei viel Zeit- druck müssen die Teilnehmer zwar die Kompetenzen zur Problemlösung und für den Umgang mit anderen Personen besitzen (K 4), jedoch scheinen sie dann andere Personen weniger in die Problemlösung einzubeziehen und weniger mit ihnen zu kommunizieren (K 5). Daraus lässt sich die Handlungsempfehlung ableiten, dass bei viel Zeitdruck nicht nur die Kompetenz zur Handlung bestehen sollte, sondern dass andere auch aktiv in die Problemlösung einbezo- gen werden müssen und mit anderen aktiv geredet werden muss. Dafür ist es dennoch wich- tig, dass die Personen die richtigen Kompetenzen besitzen. So wäre beispielsweise eine Schulung im richtigen Umgang mit anderen zur besseren Problemlösung eine sinnvolle Hilfe- stellung für Mitarbeiter. Gleichzeitig ist gerade bei hohem Zeitdruck wichtig, dass der Problem- löseprozess strukturiert abläuft und systematisch unterstützt wird. Bei der Problemklasse K 6 hat der Problemlöser das Ziel des Arbeitsauftrages unzureichend verstanden. Dies erfordert die Aktivierung von Vorerfahrungen und Arbeit mit anderen an einer gemeinsamen Verständigung des Problems. Es ist wichtig, diesen Prozess zu stärken, da so mehr Verständnis über das Ziel des Arbeitsauftrages entstehen kann. Es darf nicht auftreten, dass bei einem guten Zielverständnis davon abgesehen wird, mit anderen über ein gemein- sames Problemverständnis zu diskutieren und die eigene Vorerfahrung zu vergessen. 72 Klasse (Faktor) Mögliche Handlungsfelder K1= Handlungseinschränkungen - Bereitstellung von Informationen und Hintergrundwissen - Klare Definition von Verantwortlichkeiten - Einbettung des Problemlösungsprozesses in die Organisationsstruktur K2= fehlende problembezogene Strategie - Bereitstellung von Problembezogenen Fachwissen (ähnliche Probleme, Erfahrungen - Problembezogenes Methodenwissen (Hilfsmittel, Methodenbaukasten) - Unterstützung bei der Generierung von Wissen K3= kritischer Zustand des Ar- beitsauftrags und des Problems - Unterstützung des Wissensaustauschs und der Wissensintegration zur Erhöhung des Zielverständnisses - Integration von Experten K4= Zeitdruck und Kompetenz K5= Zeitdruck und Kooperation - Schulung der Mitarbeiter in Bezug auf das Teambuilding - Strukturiertes, systematisches Vorgehen bei der Problemlösung - Unterstützung der Kommunikation und des Wissensaustauschs - Bereitstellung von Controllinginstrumenten, wie z.B. Quality Gates K6= fehlendes Wissen - Unterstützung der Wissensintegration - Aktivierung der Vorerfahrung - Möglichkeit des Zugriffs auf die Erfahrung anderer Tabelle 3: Beschreibung der aus den Problemklassen abgeleiteten Handlungsfelder für den Problemlösungsprozess 5 Entwicklung der Systematik zur Optimierung und Gestaltung von wissensintensiven, kooperativen Problemlösungsprozessen In diesem Kapitel erfolgt die Beschreibung der Systematik zur Optimierung und Gestaltung von wissensintensiven, kooperativen Problemlösungsprozessen. Dazu werden aufbauend auf dem vorhergehenden Kapitel für die verschiedenen Problemklassen Gestaltungselemente abgeleitet. Bei der Ausgestaltung der einzelnen Gestaltungselemente werden Teilaspekte aus bestehenden Ansätzen, z.B. aus dem Prozess- und Wissensmanagement, sowie eigene Un- tersuchungen mit den Industrieunternehmen kombiniert und zu einer ganzheitlichen Systema- tik integriert. 5.1 Ableitung von Gestaltungselementen Die Bewältigung von wissensintensiven, kooperativen Problemlösungsprozessen stellt bedingt durch die Vielfalt und die Abhängigkeiten der Einflussgrößen hohe Anforderungen an den Be- arbeiter. Eine Möglichkeit, diese Komplexität handhabbar zu machen, ist die Vorstellung des Problems als Modell, damit es als Gesamtsystem (bestehend aus Elementen und Beziehungen) inter- pretiert werden kann. Der systemische Ansatz als Basis für eine leistungsfähige Unterstützung von Problemlösungsprozessen bietet den Vorteil, komplexe Sachverhalte zu strukturieren, um sie damit besser lösbar zu machen. Gleichzeitig dient er als Basis für die systematische Vor- gehensweise zur Gestaltung und Optimierung von Problemlösungsprozessen. Insbesondere liegt dabei der Fokus der Arbeit auf der Betrachtung des Wissensaspekts. Der Systembegriff an sich wird in dieser Arbeit nicht näher präzisiert, hierzu sei auf die um- fangreiche Literatur zur Systemtheorie verwiesen (Malik /95/, Senge /143/, Ulrich /158/, Ul- rich/Probst /159/, REFA /122/, Willke /177/). Einen ganzheitlichen Ansatz zum Management wissensintensiver, verteilter und hoch komple- xer Problemlösungsprozesse stellt die soziotechnische Systemgestaltung dar, da diese so- wohl den Technologieeinsatz, die Organisation sowie den Einsatz der Humanressourcen be- trachtet. Die Bezeichnung „soziotechnisch“ verdeutlicht die enge Wechselbeziehung zwischen der Tätigkeit von Problemlösern und dem Einsatz von Technologien und Methoden zur Prob- lemlösung. Basierend auf dem soziotechnischen Ansatz gilt es im ersten Schritt den Problemlösungspro- zess an sich, den Methoden- und Technologieeinsatz im Problemlösungsprozess, die Rollen und Aufgaben der am Problemlösungsprozess Beteiligten sowie die Integration des Problem- lösungsmanagements in das bestehende Unternehmensumfeld zu gestalten. Der Problemlöser kann als zentrales Element eines sozialen Teilsystems angesehen werden, der als Wissensträger Aufgaben und Handlungen ausführt. Als Wahrnehmungsprozesse kön- nen dabei je nach dem aussendenden Medium (Maschine oder Mensch) Information oder Kommunikation unterschieden werden. Dabei kann die Kommunikation, als konstituierende Relation sowohl verbal als auch non-verbal stattfinden. Im zweiten Schritt sind daher die betei- ligten Experten gezielt zu vernetzen, die Kommunikationsbeziehungen zwischen den Problem- 74 lösern bzw. Problemlösungsteams zu definieren und einen optimalen Wissensaustausch zu ermöglichen. Da soziale Systeme in der industriellen Praxis über die Bildung von Gruppen und Teams realisiert werden, gilt es zudem die verteilte Problemlösung im Team zu betrachten. Nach der Konstitution der Kommunikationsbeziehungen gilt es im dritten Schritt die Basis zu legen, um wissensintensive Probleme zu lösen. Da gerade diese durch einen hohen Anteil an komplexer, konzeptioneller Arbeit, einem hohen Anteil der Wissensverarbeitung und -generie- rung gekennzeichnet sind, müssen die Wissens- und Lernprozesse, die im Rahmen der Prob- lemlösung ablaufen, untersucht werden. Da die Integration der wesentlichen Wissensbasen und der Aufbau einer gemeinsamen Verständigungsbasis die Grundlage für die Entwicklung neuen, gemeinsamen Wissens z.B. durch Kombination vorhandenem Wissens darstellt, bein- haltet der Gestaltungsrahmen darüber hinaus die Bildung eines gemeinsamen Grundver- ständnisses sowie letztlich die kollektive Wissensgenerierung an sich. Damit können aufbauend auf den im vorhergehenden Kapitel abgeleiteten Problemklassen und deren Implikationen für Problemlösungsprozesse folgende drei Gestaltungselemente definiert werden (vgl. Abbildung 16): − Organisation und Koordination des Problemlösungsprozesses − Kommunikation und Wissensaustausch − Wissensintegration und -entwicklung Diesen drei Gestaltungsfeldern können schließlich die in Kap. 4.4 aus den Problemklassen K 1 bis K 6 abgeleiteten Handlungsfelder zugeordnet werden (vgl. Abbildung 16). Abbildung 16: Gestaltungselemente für die Gestaltung und Optimierung von wissensintensi- ven, kooperativen Problemlösungsprozessen Gestaltungsempfehlungen für Organisation und Koordination, Kommunikation und Wissensaustausch sowie Wissensintegration- und Entwicklung Wissensintegration und -entwicklung  Wissens- und Lernprozesse im Problemlösungsprozess  Wissensintegration als Basis für die Wissensgenerierung  Kollektive Wissensgenerierung Organisation und Koordination  Funktionsmodell (Prozessmodell)  Organisationsstruktur und Rollenmodell  Quality Gates  Methodenunterstützung  Integration in Unternehmensprozesse Auslösendes Ereignis Problemprozess Koordinator Problemprozess Koordinator N Problemprozess Manager Identif iziert Problem Problem- erfassung Lösungs- suche Situations- analyse Lösungs- entwicklung Lösungs- verifizierung Lösungs- umsetzung Problemlösungsprozess A Problemlöser Lösungsentw. Führungsaufgabe Auslösendes Ereignis Problem- erfassung Lösungs- suche Situations- analyse Lösungs- entwicklung Lösungs- verifizierung Lösungs- umsetzung Problemlösungsprozess N Problemlöser Lösungsverif. Problemlöser Realisierung Prozesstreiber Problemlöser Analyse Experte PL-Team Problem Owner . . . beauftragt meldet Ausführung meldet Ausführung meldet Ausführung benennt Koordinator meldet Ausführung meldet Ausführung zieht hinzu Problemlösungszirkel Problemprozess Manager Moderator QM Manager (FMEA) Bereichs- Leiter Projekt- Leiter Problemprozess Koordinator A Problemprozess Koordinator B Problemprozess Koordinator N . . . Problemprozess Manager Wissenstransfergruppe Problemprozess Koordinator A Problemprozess Koordinator B Problemprozess Koordinator N . . . Moderator Kommunikation und Wissensaustausch Problemprozess Koordinator Problem- erfassung Lösungs- suche Situations- analyse Lösungs- entwicklung Lösungs verifizierung Problemlösungsprozess A Problemlöser Lösungsentw. Problemlöser Lösungsverif. Prozesstreiber Problemlöser Analyse Experte PL-Team Problem Owner . . beauftragt meldet Ausführung meldet Ausführung meldet Ausführung zieht hinzu Search for competent experts and problem solvers via competence profile  Problemlösung im Team  Kommunikationsbeziehungen  Wissensaustauschprozesse  Wissensbarrieren als Hemmnisse für Wissensaustausch  Expertenvernetzung durch Kompetenzprofile Wissensintensives Problem Ursachen Problemlösungs- prozess Problemlösungs- tätigkeit Lösungswissen weist auf löst aus besteht aus benötigt Produktentwicklungs- prozess löst aus Eigenschaften hat Wissensdomäne Fachbereich Person/Org. Problemlöser/PL-Team Hilfsmittel/Methoden benötigt hat bestimmt durch bestimmt durch Lösungsstrategiebestimmt bestimmt Problemklassen K1, K2, K4, K5 Problemklassen K3, K4, K5, K6 Problemklassen K2, K6 75 Im Folgenden werden diese drei Elemente im Detail ausgearbeitet und es werden für jedes Element Empfehlungen zur Gestaltung gegeben. 5.2 Gestaltungselement „Organisation und Koordination von Problemlösungspro- zessen“ 5.2.1 Funktionsmodell des Problemlösungsprozesses Im Rahmen der Arbeit liegt ein besonderer Fokus gerade auf wissensintensiven, verteilten Problemlösungsprozessen, wie sie für die frühen Phasen der Produktentwicklung typisch sind. Der Problemlösungsprozess wird ausgelöst durch das Vorliegen eines Problems, definiert als Störgröße, da es den eigentlichen Produktentwicklungsprozess unterbricht. So können z.B. vorgenommene Konstruktionsänderungen unklar sein oder es kann ein Fehler beim Zusam- menbau von externen Bauteilen auftreten, dessen Ursache den Entwicklungsingenieuren un- bekannt ist. Diese Art von Problemen zeichnet sich dadurch aus, dass zur Lösung ein hoher Wissensbedarf oder hohes Maß an zu verarbeitenden und zu generierenden Wissens erfor- derlich ist und die Überwindung des Problems nur in interdisziplinärer Zusammenarbeit zwi- schen verteilten Experten in einem länger währenden Zeitrahmen erfolgen kann. Somit wird die Problemlösung selbst dabei als die Behandlung eines Ausnahmezustandes betrachtet, da die Lösung keinem gängigen Schema folgt. Da die Ergebnisse der in Kap. 4 beschriebenen Analyse gezeigt haben, dass der Anteil der Probleme, die in ähnlicher Form wieder auftreten, zwischen 70% und 75% liegt, ist eine Sys- tematisierung des Problemlösungsprozesses sowie eine strukturierte Dokumentation sinnvoll. Zur Ermittlung eines praxistauglichen Problemlösungsprozesses wurden Untersuchungen bei 4 Industrieunternehmen der Automobilbranche (1 Hersteller sowie 3 Zulieferer) im Bereich der Produktentwicklung durchgeführt. Es wurden über einen Zeitraum von einer Woche aufgetre- tene Probleme durch die Ingenieure beschrieben und anhand von insgesamt 6 Fallbeispielen das Vorgehen sowie die einzelnen Schritte bei der Lösung eines konkreten Problems unter- sucht (vgl. Kap. 4.3.4.1). Die im Rahmen dieser Untersuchung ermittelten Erfahrungswerte zeigen, dass bei der Prob- lembearbeitung, unabhängig vom Expertisestatus des Problemlösers, ähnliche Lösungsschrit- te absolviert werden. Ihre Reihenfolge wird überwiegend durch das Verhältnis von Aufwand (Mühen, Aktivitäten) und Nutzen (Wissenstransfer, Lösungsansätze) durch den Problemlöser bestimmt. Die Variation der Reihenfolge steht dabei in enger Abhängigkeit zu den individuellen Erfahrungen und den Einschätzungen der Erfolgschancen. Kriterien zur Bewertung sind u.a. Wissensangebot, Wissenstransparenz und Verfügbarkeit der Wissensquelle. Das entwickelte Phasenschema für den Problemlösungsprozess basiert auf den Gestaltungs- empfehlungen der ermittelten Problemklassen sowie den Vorgehensmodellen aus der Unter- suchung mit den Industrieunternehmen. Der Problemlösungsprozess ist in 7 Phasen unterteilt (vgl. Abbildung 17) und wird in den folgenden Kapiteln im Detail beschrieben. 76 Abbildung 17: Phasen des Problemlösungsprozesses 5.2.1.1 Phase I: Problemerfassung Das Ziel dieser Phase ist die Erfassung des Problems in seinem Kontext sowie die Einengung des Suchraums für die Anschließende Phase II „Lösungssuche“. Die Problemerfassung wird durch folgende Prozessschritte bestimmt: Problemidentifikation Der Problem Owner nimmt im Rahmen der Ausführung eines Geschäftsprozesses eine Zu- standabweichung oder einen unerwünschten Zustand wahr und ordnet diese Zustandsabwei- chung als Problem. Diese Wahrnehmung als Störgröße und die Bewertung der Abweichung findet subjektiv unter Einfluss der Persönlichkeitsmerkmale oder Affekten statt (z.B. bisherige Erfahrungen, Motivation, etc.). Das Ergebnis dieses Schrittes ist die Einordnung der Zustandsabweichung als Problem. Probleminitialisierung Bei Vorliegen eines Problems als Störgröße (vgl. Typ III und IV) startet der Problem Owner den Problemlösungsprozess. Dann erfolgt einen kurze Spezifikation des Problems durch den Problem Owner (Problem- Ticket). Die Ermittlung der Informationen zum Problem erfolgt über entsprechende Kriterien. Um den Aufwand für den Problem Owner so gering wie möglich zu halten, ist es empfehlens- wert, möglichst wenig Kriterien direkt abzufragen und viele Informationen indirekt bzw. auto- matisiert bereitzustellen. Folgende Kriterien werden für eine Spezifikation vorgeschlagen (vgl. Tabelle 4). Problem- erfassung Lösungs- suche Situations- analyse Lösungs- entwicklung Lösungs- verifizierung Lösungs- umsetzung Evaluation Trigger Event für Problem Typ I Typ II Typ III Typ IV Problemklassifikation QG6 QG5 QG4 QG 3 QG 2 QG 1 Problemlösungsprozess  Initialisierung Problemticket Zeithorizont ad-hoc vs. langfristig St ru kt u rie rth e its gr a d u n st ru kt u rie rt vs st ru kt u rie rt Problem als Störgröße Geschäftsprozess Recherche nach vorh. Lösungen Dokumentation und Verdichtung Definition Ansprechpartner Ermittlung Lösungsanforderungen Detailanalyse Zielformulierung Dokumentation und Verdichtung Generierung alt. Lösungsvorschläge Lösungsanalyse und –optimierung Dokumentation und Verdichtung Bewertung der Lösungsalternativen Auswahl und Entscheidung Dokumentation und Verdichtung Planung der Umsetzung Umsetzung der Problemlösung Abschließende Bewertung K2= fehlende problembezogene Strategie K1= Handlungseinschränkungen K3= kritischer Zustand des Arbeitsauftrags/Problems K4= Zeitdruck und Kompetenz K6= fehlendes Wissen K5= Zeitdruck und Kooperation Problemklassen 77 Kriterium Beschreibung Nummer Identifikationsnummer des Problems Titel Titel des Problems Problem Owner Name des Problem Owners Kurzbeschreibung Kurze textuelle Beschreibung des Problems und des Kontexts, in welchem das Problem aufgetreten ist Fach- bzw. Unter- nehmensbereich Fachbereich bzw. Unternehmensbereich, in welchem das Problem aufgetreten ist; Wis- sensdomäne, welche das Problem adressiert Expertise Selbsteinschätzung des Expertisestatus (Novize, Experte, ...) hinsichtlich des spezifi- schen Problems Prozess- bzw. Produktbezug Einschätzung des Problem Owners, ob das Problem ein prozessspezifisches oder ein produktspezifisches ist. Ggf. erfolgt die Angabe, in welchem Prozess/Prozessschritt bzw. Produkt/Produktteil das Problem aufgetreten ist Projekt ggf. Angabe, in welchem Projekt das Problem aufgetreten ist Zeitrahmen Startdatum der Problemlösung, geschätztes Enddatum Schlagworte Auswahl von thematischen Schlagworten, denen das Problem zugeordnet werden kann Tabelle 4: Kriterienkatalog zur Erfassung eines Problems Der Output dieses Prozessschrittes ist das ausgefüllte Problem-Ticket. In dieser Phase, wie auch in den folgenden Phasen, existieren Kriterien (in diesem Fall Pflichtfelder), welche aus- gefüllt sein müssen, um in die nächste Phase des Problemlösungsprozesses zu gelangen. Diese Felder sind generell gekennzeichnet. Es handelt sich hierbei sowohl um reine „Check – Felder“ als auch Fließtextfelder. 5.2.1.2 Phase II: Lösungssuche Unter der Suche nach bestehenden Problemlösungen versteht man hier die Überprüfung in- wieweit das aktuelle Problem in gleicher oder ähnlicher Form bereits in der Vergangenheit aufgetreten ist und wie es von welchem Wissensträger bearbeitet wurde. Die Prozessschritte dieser Phase können wie folgt beschrieben werden: Recherche nach vorhandenen Lösungen Falls eine Recherche über vorhandene bzw. ähnliche Probleme und deren Lösung notwendig ist, erfolgt dies im Rahmen einer Suche, z.B. über eine Suchmaschine. Zuerst erfolgt dabei die Definition von Suchkriterien, sowie die Definition des Suchraums, d.h. in welchen Datenbeständen die Suche nach bestehenden Lösungen erfolgen soll. Um die Su- che möglichst effizient zu gestalten, werden dem Problem Owner Hilfswerkzeuge, wie bei- spielsweise eine Checkliste oder Tipps zur Erstellung von Schlagwörtern, an die Hand gege- ben. Der Problem Owner führt dann anhand der Schlagworte eine Recherche nach vorhandenen Lösungen oder ähnlichen Problemen bzw. Problemlösungen durch. Ziel ist es, bestehende Problemdokumentationen zu identifizieren, die dem vorliegenden Problem möglichst ähnlich sind. Der Problem Owner bewertet dabei, welche Teile der gefundenen Problemlösungen auf das vorliegende Problem übertragbar sind und ob die Möglichkeit besteht, die Lösungen ent- 78 sprechend anzupassen (keine Lösung, Teillösung, vollständige Lösung). Wird bei der Über- prüfung ein Wissensträger bzw. ein ähnliches, bereits bearbeitetes Problem ausfindig ge- macht, so lässt sich der Ressourcenverbrauch der aktuellen Problemlösung senken. Die Vernetzung mit bestehenden, ähnlichen Problemlösungen dient somit der Einordnung des Problems in bestehende Wissensgebiete und einer Objektivierung des Problems. Denn, da es bei Problemen immer eine subjektive Sicht der Situation bzw. des Ist- und des Soll- Zustandes geben kann, kann mit der Vernetzung bereits eine Objektivierung des Sachverhaltes erfolgen. Neben der Checkliste mit Fragen können auch eine Vorgehensweise zur Suche, die Auflistung von Suchmöglichkeiten oder Linklisten als Hilfsmittel zur Durchführung dieses Schrittes die- nen. Generell bietet sich die Möglichkeit der Suche in − eigenen Datenbeständen (z.B. Projektdokumentation, Fileserver, etc.) − einer internen Problemdatenbank (FMEA-Dokumentation, etc.) − externen Quellen (Suchmaschine, etc.) Falls eine bereits dokumentierte Lösung auf die neue Problemstellung passt, erfolgt im Rah- men der Dokumentation noch eine genauere Beschreibung der Transformation der bestehen- den Lösung auf die neue Problemstellung. Falls das Problem und dessen Lösung dem Problem Owner unmittelbar bekannt ist, wird die bestehende Dokumentation dem Prozessschritt direkt zugeordnet. Oftmals bietet es sich an, auch bei bereits unmittelbar identifizierten Problemlösungsdokumentationen nochmals eine Recherche nach weiteren, ähnlichen Problemen und deren Lösungen durchzuführen, da so die Wissensbasis für die Lösung des vorliegenden Problems gegebenenfalls erweitert wird. Im Prinzip ist bereits eine existierende IT-Infrastruktur (Mail, Internetzugang, Intranet) der Ver- netzung äußerst dienlich. Eine weitere Möglichkeit zur Vernetzung ist durch eine existierende Wissens- bzw. Erfahrungsdatenbank gegeben. Die optimale Vernetzung ist dann gegeben, wenn eine zentrale Problemlösedatenbank in der Firma besteht, in welcher man, z.B. durch die Ausführung einfacher Suchoptionen, ähnliche bereits bearbeitete Probleme ausfindig ma- chen kann. Die eigentliche Suche erfolgt somit in der Regel über Werkzeuge wie Suchma- schinen im Internet, Intranet, Datenbanken etc. Der Output dieses Prozessschritts ist ein Suchergebnis z.B. in Form eines Dokuments oder eines Ansprechpartners Dokumentation und Verdichtung Dann erfolgt eine Dokumentation der Phase. Eine Checkliste hilft dabei, zu überprüfen, ob alle wichtigen Fragestellungen berücksichtigt wurden und dient gleichzeitig als Leitfaden für die Dokumentation. Die Checkliste kann beispielsweise Fragen nach dem Auftreten, der Form und des Zusammenhangs sowie der Vorgehensweise zur Problemlösung beinhalten: − Ist das Problem bereits schon einmal aufgetreten? − Wenn ja, in welcher Form und in welchem Zusammenhang ist es aufgetreten? − Wie erfolgte die Lösung des Problems (Vorgehensweise)? − Wurde ein FMEA-Check durchgeführt? − Welche internen/externen Informationsquellen wurden überprüft? 79 Zur Bewertung bzw. Beurteilung, ob und in wie weit die gefundenen Ergebnisse zu bestehen- den Lösungen sinnvoll bzw. verwendbar sind, ist sowohl eine Abgrenzung der Einflussmög- lichkeiten sinnvoll. Mögliche Fragen wären beispielsweise: − Wo ist der Eingriff aufgrund ausreichender Einflussmöglichkeiten möglich? − Wo gibt es technische/organisatorische Lösungsmöglichkeiten? − Wie dringlich ist eine Lösungsrealisierung? − Wo ist ein gutes Aufwand-/Nutzenverhältnis zu erwarten? Ebenfalls bietet sich eine Abgrenzung Lösungsbereichs (als Teilmenge des Eingriffsbereichs) und des Wirkungsbereichs (Bereich in dem durch Lösung Auswirkungen zu erwarten sind). Der Output dieses Schrittes ist eine Dokumentation und Bewertung der Suchphase. Definition von Ansprechpartnern Nach der Dokumentation der Suchphase, schickt der Problem Owner das ausgefüllte „Prob- lem Ticket“ an den zuständigen Problemprozessmanager zur Überprüfung und Freigabe. Die- ser definiert einen Problemkoordinator, der für die Bearbeitung der weiteren Phasen verant- wortlich ist. Zudem definiert er noch einen Zeitrahmen für die Problemlösung. In diesem Prozessschritt informiert sich der vom Problemprozessmanager definierte Problem- koordinator zuerst über den Status der Problemlösung (Problem-Ticket). Er hält ggf. nochmals Rücksprache mir dem Problem Owner bzw. dem Problemprozessmanager. Der definierte Problemkoordinator plant die weitere(n) Phase(n) und definiert für diese Prob- lemlöser, die die Ausführung übernehmen, ggf. werden Problemlösungsteams gebildet. Die nachfolgenden Schritte werden vom Problemlöser bzw. vom Problemlösungsteam bearbeitet. Der Output dieses Prozessschritts ist ein definierter Problemkoordinator sowie ein Zeitrahmen für die Problemlösung. 5.2.1.3 Phase III: Situationsanalyse Ziel dieser Phase ist zum einen, eine sachliche, von Fakten gestützte, logisch argumentierba- re, zieloffene, lösungsneutrale Interpretation der Situation zu geben und diese darzustellen. Dies dient als Grundlage für spätere Entscheidungen. Zum anderen erfolgt in der Situations- analyse die Formulierung von Zielen, welche die Lösungssuche steuern. Die Tragweite einer gut durchgeführten Situationsanalyse lässt sich daran erkennen, dass eine Problemlösung bei optimalem Informations- und Wissensbestand in der Ausgangspositi- on schneller, effektiver, fehlerfreier und somit kostengünstiger durchgeführt werden kann. Vorwissen spielt auch bei der Erstellung eines Modells der Situation eine große Rolle. Wenn ein Problem semantisch angereichert ist, und damit das Vorwissen nutzbar ist, ist dies eine günstigere Voraussetzung für die Organisation und Integration von Wissen bzw. Informatio- nen. Mit dem Vorwissen sind Strukturierungsprinzipien gegeben, die eine sinnvolle Ordnung der Informationen bzw. der Wissensbausteine ermöglichen, was wiederum die Modellbildung erleichtert. Allerdings besteht die Gefahr, dass eine neuartige Problemsituation mit einer be- kannten analogisiert wird, ohne dass dies ausreichend geprüft wird, wenn umfangreiches Wis- sen über den relevanten Realitätsbereich vorliegt. Im einzelnen zielt die Situationsanalyse auf 80 − die Erzeugung eines umfassenden Verständnisses über das Problem, dessen situativen Kontexts und dessen Ursachen, − die Schaffung von Transparenz über Zusammenhänge im Problemumfeld, − die Strukturierung des Problemfelds und die Definition des Gestaltungs- und Eingriffsbe- reichs, − die Formulierung von Zielen zur Steuerung der Lösungsentwicklung und -umsetzung, − die Schaffung einer Wissensbasis für die Lösungsentwicklung u.a. durch die Analyse des Wissensbedarfs/-angebots, die Identifikation von Kontaktpersonen und die Planung der Wissensbeschaffung ab. Somit erfolgt zum einen eine umfassende Analyse des Ist-Zustands des gegebenen Problems z.B. über die Spezifikation der gegebenen Problemstellung als auch eine Beschreibung des Soll-Zustands z.B. über die Definition von Zielen. Nachfolgend werden die Prozessschritte der Phase im Detail beschrieben. Ermittlung von Lösungsanforderungen Im Gegensatz zur beschreibenden Kurzspezifikation des Problems in der Phase „Problemer- fassung“ erfolgt hier eine ausführliche handlungsrelevante Beurteilung der Anforderungen des momentan vorliegenden Problems. Die Anforderungen an die Lösung müssen folgende Aspekte beinhalten: − Integration der Sicht des „Auftraggebers“ − „360-Grad-Analyse“ der Erwartungen an die Problemlösung entsprechend der Zielgruppen − Analyse der Idealvorstellungen für die Problemlösung − Klärung von Begriffen und das Erzeugen eines gemeinsamen Verständnisses Dies kann beispielsweise im Rahmen einer erweiterten 360-Grad-Analyse durchgeführt wer- den. Detailanalyse Da komplexe Problemsituationen mit eindimensionalen Betrachtungen und Darstellungen nur unzureichend erfasst werden können, werden zur Durchführung dieses Prozessschrittes so- wohl die möglichen Ursachen für das vorliegende Problem als auch mögliche Einflussfaktoren auf das Problem bzw. dessen Lösung analysiert. Ziel ist, Fakten, Informationen, Wissen zu sammeln, um umfassende Beschreibung bzw. Ein- ordnung der Problemsituation vornehmen zu können. Fakten//Informationen etc. dienen als Entscheidungsgrundlage für spätere Phasen. Aus Wissenssicht werden im Rahmen der Analyse der Problemsituation in erster Linie die Wissensprozesse der Wissensbeschaffung unterstützt. Im Rahmen der ursachenorientierten Problemanalyse erfolgt die Bewertung bzw. Einordnung, ob es sich um ein Problem, eine Problemursache oder nur ein Symptom handelt, die Ermitt- lung von Ursache-Wirkungsketten sowie die Festlegung der eigentlichen Ursachen des Prob- lems (vgl. Abbildung 18). Die Kenntnis eines Problems im engeren Sinne, d.h. die Kenntnis der Ursachen kann hierbei wertvolle Hinweise auf die zu wählende Lösungsstrategie geben. 81 Abbildung 18: Symptom und Ursache eines Problems Wenn die Problemursache beispielsweise in einer unzureichenden Kommunikation von prob- lemrelevantem Wissen aufgrund unbekannter Ansprechpartner liegt, so müssen im Lösungs- strategiefeld Kommunikation Maßnahmen ergriffen werden, welche die Ansprechpartner und deren Wissensbedarf genau definieren und welche auch den Zugang zu den Ansprechpart- nern über geeignete I&K Technologien ermöglichen. Zusätzlich zur Analyse der Ursachen wird eine Analyse der Einflussfaktoren durchgeführt. Hierbei erfolgt eine Beschreibung der Parameter, die Einfluss auf das Problem bzw. dessen Lösung haben. Zielformulierung Die Zielbildung ist die systematische Zusammenfassung der Absichten, die der Lösungsent- wicklung zugrunde gelegt werden sollen. Hierbei werden mehrere Zielalternativen und Zwi- schenzielalternativen gesucht und formuliert. Die Zielformulierung sollte folgende Bestandteile beinhalten (Daenzer/Huber et al. /24/): − Zielobjekt (WORAN sind die Ziele gebunden?) − Zieleigenschaften, bzw. Zielinhalte (WAS soll erreicht werden?) − Zielausmaß (WIEVIEL soll erreicht werden?) − Zeitaspekt (WANN soll es erreicht werden?) − Ortsbezeichnung (WO soll es wirksam werden?) − Zielverantwortliche(r), Zielformulierungsbeteiligte(r) (WER ist verantwortlich?) − Allgemeiner Zieltitel − Zielerreichungskriterien Die Zielformulierung sollte lösungsneutral sein, eine Feststellbarkeit der Zielerreichung sollte möglich sein (Zielerreichungskriterien) und für die einzelnen Zwischenziele sollten Prioritäten gesetzt sein. Zudem sollte die Zielformulierung beinhalten, was mit der zu gestaltenden Lö- sung erreicht werden bzw. nicht erreicht werden soll. Insgesamt sollte die Zielformulierung einer Vollständigkeit entsprechen, d.h. finanzielle, funkti- onale, personalrelevante, soziale und gesellschaftliche Zielinhalte beinhalten. Die Auswahl eines Zieles erfolgt erst nach dem nächsten Problemlösungsschritt, der Bewertung. Ursache Ursache Ursache Ursache Ursache Ursache Problem im weiteren Sinn Problem im engeren Sinn 1. Ermittlung möglicher Ursachen 2. Vernetzung möglicher Ursachen Symptom 82 Im Rahmen dieses Teilschrittes erfolgt zudem die Identifikation und Analyse von Schwierigkei- ten, Potenzialen, Chancen bzgl. der Problemlösung. Insbesondere das Erkennen von Schwächen und Stärken bzw. Chancen und Risiken setzt hierbei ein Vorwissen über durchschnittliche, normale oder erreichbare Zustände voraus. Als weitere Quellen für das Entwickeln von Handlungsansätzen können beispielsweise dienen: − Leitbilder − Vorgaben aus vorangegangenen Untersuchungen − Vergleiche mit ähnlichen Sachverhalten oder Systemen. Dokumentation und Verdichtung Dieser Prozessschritt schließt die Phase III ab. Ziel ist es dabei, abschließend wesentliche Kernaussagen festzuhalten, die Ergebnisse der gesamten Phase sowie die Dokumentation der Muss-Kriterien nochmals zu überprüfen. Wichtig ist hierbei eine kurze Bewertung hinsicht- lich des Ablaufs sowie eine kurze Beschreibung des momentanen Stands im Problemlösungs- prozess. Eine Checkliste hilft auch hier dabei zu überprüfen, ob alle wichtigen Fragestellungen berücksichtigt wurden und dient gleichzeitig als Leitfaden für die Dokumentation. Alle erstellten Dokumente werden dem Problem-Ticket zugeordnet. Nach der Durchführung der Phase schickt der Problemlöser bzw. das Problemlösungsteam den Status an den Prob- lemkoordinator. Dieser bewertet den Status und gibt den Vorgang für die nächste Phase frei. 5.2.1.4 Phase IV: Lösunganpassung und –entwicklung Diese Phase ist der zentrale kreative Teil im Problemlösungszyklus. Im Rahmen dieser Phase sollen Lösungsvarianten generiert werden. Falls durch die Lösungssuche in Phase II bereits geeignete Lösungen gefunden wurden, er- folgt deren Anpassung entweder durch den Problemlöser oder im Team (Umgestaltung). Falls keine Lösung gefunden wurde beginnt die Entwicklung einer komplett neuen Lösung im Team oder durch den Problemlöser (Neugestaltung). Diese Phase besteht aus den nachfolgend beschriebenen Schritten: Generierung von alternativen Lösungsvorschlägen Nach der Freigabe des Prozesses für die Phase IV durch den Problemkoordinator, legt der definierte Problemlöser nun eine geeignete Lösungsstrategie fest. Hierbei können generell folgende Lösungsstrategien unterschieden werden: − Begrenzung des Lösungsfelds (durch die Konzentration auf bestimmte Einflussfaktoren wie z.B. Performance-Variablen) − System-Melioration (System-Verbesserung im Hinblick auf die gestellten Ziele) − Unterschiedliche Ausgangspunkte für Lösungssuche (Systemverbesserung entweder vom Groben ins Detail, oder vom Kern des Problems ausgehend) − Suchstrategien (unterschieden werden hier: Trial and Error, lineare, zyklische und kombi- nierte Strategien) − Heuristiken (hier werden erprobte Methoden der Lösungsfindung zusammengefasst). 83 Ein weiterer wichtiger Schritt ist die Wissensbeschaffung. Dabei erfolgt zuerst eine Überprü- fung vorhandenen Lösungswissens und des Wissensangebots (z.B. die im Problem-Ticket angehängten Dokumentationen) sowie die Ermittlung des Wissensbedarfs zur Lösung der Aufgabe (z.B. über Wissenskarten). Anschließend erfolgt die Analyse und Bewertung des ge- sammelten Wissens hinsichtlich der zu lösenden Problemstellung. In der Regel finden die oben genannten Gestaltungsmöglichkeiten ihre Anwendung in Kombi- nation. Das Lösungsdesign kann im Rahmen folgender Organisationsformen erfolgen: − Lösungsdesign durch den Problemlöser selbst − Lösungsdesign durch Problem-Ower und Problemlösungsprozess-Owner − Lösungsdesign durch Problemlösungsteam. Für den Fall, dass das notwendige Lösungswissen für ein Problem nicht beschafft bzw. entwi- ckelt werden konnte, bietet sich die Erzeugung und Ausarbeitung von möglichen Handlungsal- ternativen, oder Varianten an. Lösungsanalyse und -optimierung Ziel dieses Schrittes ist die systematische Prüfung der Lösungen sowie die Identifikation von Ansatzpunkten zur Verbesserung der Lösungsvorschläge bzw. Argumentationen für deren Ausschluss. Die Inhalte der systematischen Analyse decken folgende Aspekte ab (Daenzer/Huber et al. /24/): − Analyse formaler Aspekte (Beurteilbarkeit, Erfüllung der Mussziele) − Analyse der Integrierbarkeit (wirkungsbezogene Betrachtung, Blick nach außen) − Analyse der Funktionen und Abläufe (Blick nach innen) − Analyse der Betriebstüchtigkeit (Benutzer-, Bedienungs-, Wartungsfreundlichkeit, Zuverläs- sigkeit, Sicherheit) − Analyse der Voraussetzungen und Bedingungen − Analyse der Konsequenzen. Im Rahmen der systematischen Analyse werden die erarbeiteten Lösungsvorschläge entspre- chend der oben beschriebenen Aspekte auf ihre Brauchbarkeit geprüft. Sofern die Analyse Ansatzpunkte für Verbesserungen ergibt, wird der Lösungsansatz weiter ausgearbeitet, bzw. optimiert. Wenn hinsichtlich Konkretisierungsstufe bzw. Bewertung aus- reichende Ergebnisse vorliegen, kann die nächste Phase gestartet werden. Dokumentation und Verdichtung Dieser Prozessschritt schließt die Phase IV ab. Im Rahmen der Dokumentation ist in dieser Phase wichtig, die Herangehensweisen und Hintergründe für die einzelnen Lösungsalternati- ven z.B. unter Zuhilfenahme einer Checkliste zu erfassen. Nach der Durchführung der Phase schickt der Problemlöser bzw. das Problemlösungsteam den Status an den Problemkoordinator. Dieser bewertet den Status und gibt den Vorgang für die nächste Phase frei. 84 5.2.1.5 Phase V: Lösungsverifizierung und Auswahl Die Phase Lösungsverifizierung hat die Aufgabe, den Entscheidungsprozess vorzubereiten, indem die entwickelten Lösungsalternativen bewertet werden. Im Gegensatz zum Schritt Lö- sungsanalyse und -optimierung der Phase III, in dem eine kritische Durchleuchtung der Taug- lichkeit jeder Variante für sich erfolgt, werden hier die Varianten vergleichend bewertet. Folgende Anforderungen müssen dabei erfüllt werden: − Vorliegen unterscheidbarer Lösungsvarianten: Die Lösungsvarianten wurden in der vorher- gehenden Phase erarbeitet bzw. ausgearbeitet. Ungeeignete Varianten gelangen nicht mehr in die Bewertungsphase. − Vorhandensein von Bewertungskriterien: Hierbei sind besonders die Teilziele geeignet, die als Soll- bzw. Wunschziele aufgelistet wurden. Gegebenenfalls ist diese Liste durch weitere Kriterien zu ergänzen, die sich unter Umständen auch erst aus der Kenntnis von Lösungs- konzepten ergeben. − Bewertungskompetenz von Seiten des Problemlösers bzw. Problemlösungsteams: Die Fä- higkeit zur Beurteilung von Varianten umfasst nicht nur eine umfassende Kenntnis der Situ- ation sondern auch Fachwissen bzgl. Eigenschaften und Einsatzbedingungen von Lö- sungsvarianten sowie Argumentations- und Urteilsfähigkeit. Im einzelnen werden folgende Schritte ausgeführt. Bewertung der Lösungsalternativen Nach der Festlegung einer Bewertungsmethode werden vom Problemlösungsteam und dem Problemprozesskoordinator Bewertungskriterien definiert, an hand derer die Handlungsalter- nativen unter Berücksichtigung der Zielerreichung geprüft werden. Eine gewichtete Teilzieler- füllung und der Nutzen können dabei auch rechnerisch ermittelt werden. Die Ergebnisse soll- ten plausibel sein und nicht im Widerspruch stehen. Eventuell kann auch eine Simulation mög- licher Ergebnisse (Szenarien) oder eine Prognose hinsichtlich der Wirkungsketten, der Vorteile und Nachteile ergänzend durchgeführt werden. Ebenfalls kann die Ermittlung der Wirtschaft- lichkeit der Gesamtlösung z.B. über die Durchführung einer Nutzwertanalyse, dazu dienen, möglichst umfassend die wirtschaftlichen Auswirkungen zu beurteilen. Als Ergebnis dieses Schrittes erstellt das Problemlösungsteam gemeinsam mit dem Problem- prozesskoordinator eine Liste mit den priorisierten Handlungsalternativen. Auswahl und Entscheidung In diesem Prozessschritt erfolgt durch den Problemprozesskoordinator gegebenenfalls ge- meinsam mit dem Problemprozess Manager die Auswahl einer Variante, die weiter zu detail- lieren oder zu realisieren ist. Bei größeren Problemlösungen, d.h. bei Lösungen, deren Um- setzung große kapazitative und finanzielle Aufwände erfordern, kann die Entscheidung auch durch den Problemlösungszirkel getroffen werden. Dabei ist von Vorteil, wenn die Entscheider bereits am Problemlösungsprozess selbst beteiligt waren. Sie sind dann bereits mit den den Lösungen zugrunde liegenden Sachverhalten ver- traut und haben in Folge dessen geringere Schwierigkeiten in der Entscheidungsphase. Mit der Entscheidung und Freigabe zur Umsetzung signalisiert die Entscheidungsebene die Veränderungsbereitschaft und auch die Übernahme von Verantwortung. 85 Dokumentation und Verdichtung Die Dokumentation beginnt bereits parallel zur Bewertung der Lösungsalternativen. Damit für die Entscheidung tragfähige Grundlagen vorhanden sind, ist es zweckmäßig, dass das Prob- lemlösungsteam die Historie, Empfehlungen und Ergebnisse angemessen dokumentiert. Auch die Entscheidung selbst wird mit den entsprechenden Begründungen und Überlegungen von den jeweiligen Entscheidern dokumentiert, damit später die Entscheidung auch für Außenste- hende nachvollziehbar ist. 5.2.1.6 Phase VI: Lösungsumsetzung In der Phase der Lösungsumsetzung geht es weitestgehend um die Dokumentation der Imp- lementierung der gewählten Problemlösung. Hierbei wird, vor allem in Bezug auf zukünftige Problemlösungsprozesse, der Status der Problemlösung (offen / erledigt) definiert, sowie eine Bewertung der Lösungsumsetzung dokumentiert. Die Wissenssicherung in Form einer umfas- senden Dokumentation der Lösungsumsetzung ist besonders wichtig, da die gewählte Lösung zukünftig (für ähnliche Probleme) verwendet werden soll. Abgesehen von der rein technischen Perspektive ist diese Phase auch wichtig, da Sie dem Management eine Aussage darüber liefert, wie erfolgreich die Problemlösungsprozesse im Unternehmen funktionieren (z.B. Anzahl offener Probleme, durchschnittliche Zeit von der Iden- tifikation eines Problems bis zur Umsetzung usw.). Diese Phase besteht aus den folgenden Schritten: Planung der Umsetzung Bereits während der Lösungsentwicklung werden die entsprechenden Rahmenbedingungen zur Umsetzung geschaffen, damit zügig mit der Umsetzung der Problemlösung begonnen werden kann. Deshalb kann die Planung der Umsetzung bereits parallel zur Phase der Lö- sungsentwicklung erfolgen. Die Planung beinhaltet dabei z.B. die Festlegung eines Zeitplans, die Definition von Meilensteinen, die Kalkulation der zu erwartenden Kosten als auch die Defi- nition eines Implementierers oder eines Teams, welches die Umsetzung durchführt. Die Be- setzung des Teams mit Problemlösern, die bereits in früheren Phasen im Problemlösungspro- zess involviert waren und somit wichtige Wissensträger sind, sichert den Wissenstransfer. Der Problemprozesskoordinator achtet bei der Umsetzung verstärkt auf die Sicherung der Umset- zungseffizienz und fördert die Teambildung im Umsetzungsteam mit entsprechenden Maß- nahmen. Dies ist besonders wichtig, wenn bei der Umsetzung auch Personen aus anderen Bereichen oder gar externe Dienstleister in das Team integriert werden müssen. Je nach Aufwand und terminlichen Zielen gibt der Problemlösungszirkel oder der Problempro- zessmanager die Freigabe zur Umsetzung. Die Integration in das Unternehmen kann abhän- gig von der Größe des Umsetzungsprojekts beispielsweise als Projektorganisation erfolgen. Umsetzung der Problemlösung Die Umsetzung der gewählten Lösungsvariante kann in eine revolutionäre und eine evolutio- näre Form differenziert werden. Da bei einer revolutionären Umsetzung im Vergleich zu einer evolutionären Umsetzung der zu erwartende kapazitative und finanzielle Aufwand höher sein wird, ist ein professionelles Projektmanagement empfehlenswert. Dabei werden die klassi- schen Prinzipien des Projektmanagements angewendet. Als Projektmanager kann beispiels- weise der Problemprozesskoordinator eingesetzt werden. 86 Bei einer evolutionären Umsetzung erfolgt die Realisierung der Lösung in kleinen Stufenpro- zessen, die langfristig angelegt werden. Dieses Vorgehen ist mit einer kontinuierlichen Ver- besserung vergleichbar, allerdings mit zeitlicher Begrenzung der Umsetzung. Da die Umset- zung der Problemlösung neben den organisatorischen Hauptaufgaben der Implementierer erfolgt, ist neben der Implementierung von guten Kommunikationsprozessen auch ein effizien- tes Controlling der Umsetzung durch den Koordinator erforderlich. 5.2.1.7 Phase VII: Evaluation Abschließende Bewertung Es ist empfehlenswert, nochmals eine Bewertung mit zeitlichem Abstand nach Umsetzung der Problemlösung, d.h. während des Betriebs der Lösung, bezüglich Kosten-Aufwand-Nutzen vorzunehmen. Zudem ist es im Kontext der Wissenssicherung wichtig, die im Verlauf des Be- triebs gewonnenen Erkenntnisse, Erfahrungen und Verbesserungspotenziale in Bezug auf die Problemlösung zu dokumentieren. So können zum einen die am Problemlösungsprozess be- teiligten für nachfolgende Probleme aus den Erfahrungen lernen. Zum anderen wird den Prob- lemlösern nachfolgender, ähnlicher Probleme umfassendes Wissen, von der Entwicklung der Lösung bis zu den Erfahrungen beim Betrieb der Lösung, bereitgestellt. Dies ermöglicht eine schnelle, praxisorientierte Lernkurve. 5.2.2 Organisationsstruktur und Rollenmodell Die Organisationsstruktur umfasst die Betrachtung der aufbauorganisatorischen Gestaltung des Problemlösungsprozesses. Eine typische Darstellungsart ist das Organigramm, in wel- chem die Funktionsbereiche und Stellen sowie deren Verknüpfungen untereinander dargestellt werden. Ein Rollenmodell dient grundsätzlich der näheren Beschreibung von Prozessen unter dem Gesichtspunkt der beteiligten Organisationseinheiten und deren Rolle (vgl. ARIS Konzept). Eine Rolle wird in diesem Kontext von einer Person wahrgenommen, die das Bindeglied zwi- schen dem Prozess und den beteiligten Ressourcen darstellt. Die Durchführung des Prozes- ses erfordert Kompetenzen, welche die beteiligte Rolle aufweisen muss. Um die Rollen pro- zessorientiert definieren zu können, müssen dazu die Anforderungen des Prozesses an die beteiligten Personen bestimmt werden. Dabei wird hier unter Anforderungen vornehmlich das Wissen und die Kompetenzen der beteiligten Personen verstanden. Im folgenden werden in Anlehnung an die Rollen im klassischen Prozessmanagement die Stellen und Gremien beschrieben, die im Rahmen der Gestaltung von Problemlösungsprozes- sen von Bedeutung sind (vgl. Abbildung 19). Problem Owner Als Problem Owner wird derjenige im Problemlösungsprozess bezeichnet, der ein Problem bzw. eine Zustandsabweichung wahr nimmt. Die Bezeichnung soll allerdings nicht suggerie- ren, dass derjenige bzw. diejenige auch automatisch verantwortlich für die Verfolgung und Bearbeitung des Problems ist. Nach der Feststellung eines Problems erfasst der Problem Owner das Problem (Phase I „Problemerfassung“). In dieser Phase erfolgt auch die Information des zuständigen Prozess 87 Managers. Dann sucht er nach bereits ähnlich aufgetretenen Problemen sowie mögliche vor- handene Lösungen (Phase II „ Lösungssuche“). Zu Beginn der dritten Phase „Situationsanalyse“ erfolgt auf der Basis der Ergebnisse und der betreffenden Wissensdomäne aus den Phasen I und II die Abstimmung der Organisation des Problemlösungsprozesses mit dem verantwortlichen Problemprozess Manager. Hierbei wird ein Koordinator definiert, der für die weitere Bearbeitung des Problems verantwortlich ist. Problemprozess Manager Der Problemprozess Manager fungiert als Prozesspromotor und ist für die Qualität der Prob- lemlösungsprozesse verantwortlich. Für die Problem Owner gilt er als erster Ansprechpartner nach der Identifikation eines Problems. Er benennt einen Koordinator für den jeweiligen Prob- lemlösungsprozess und übernimmt die Koordination zwischen den beteiligten Organisations- einheiten und die Verantwortung der Ergebnisse. Weiter sorgt er für die Weiterentwicklung des Prozesses anhand von Führungsgrößen und Erfolgsfaktoren. Der Problemprozess Manager entscheidet, in Abstimmung mit den Koordinatoren der Problemlösungsprozesse und der be- troffenen Entscheidungsebenen über die Bewertung einzelner Änderungsvorhaben, die auf- grund von Lösungsvorschlägen bzw. erarbeiteter Lösungen durchzuführen sind (vgl. Problem- lösungszirkel). Zudem entscheidet er über die Priorisierung einzelner Lösungsentwicklungen, welche aufgrund der erarbeiteten Problem- und Problemsituationsanalyse zur Bearbeitung anstehen. Problemprozesskoordinator Der Koordinator eines Problemlösungsprozesses agiert als Prozesstreiber, welcher die Bear- beitung des Problemlösungsprozesses sowie die Ergebniserstellung koordiniert und steuert. Er ist verantwortlich für die Gestaltung des Problemlösungsprozesses sowie für das Ergreifen entsprechender Aktivitäten zur Bearbeitung des Problems. Darüber hinaus entscheidet er auf der Basis der Ergebnisse der einzelnen Phasen (Phase III – Phase VI) über das weiteren Vor- gehen zur Lösung des Problems. Gleichzeitig dient er den im Problemlösungsprozess Invol- vierten als Ansprechpartner für Fachfragen sowie als Sozialpromotor. Problemlöser Für die einzelnen Phasen des Problemlösungsprozesses (Situationsanalyse, Lösungsanpas- sung und -entwicklung, Lösungsverifizierung und -auswahl, Lösungsumsetzung) werden vom Koordinator Problemlöser beauftragt. Diese Problemlöser übernehmen die Fachverantwortung für die betreffende Phase. Nach der Bearbeitung der jeweiligen Phase wird der Koordinator über das Ergebnis informiert. Problemlösungsteam Der Problemlöser kann während der Problembearbeitung nach Bedarf ein Problemlösungs- team bilden, in dem er weitere Experten aus weiteren Disziplinen zur Problemlösung hinzu- zieht. Unter einem Problemlösungsteam wird hierbei eine auf Zeit zur Lösung eines Teilas- pekts des Problems gebildete, interdisziplinäre und komplementär zusammengesetzte Gruppe von Personen verstanden. Diese kann ausgehend von einem Kernteam nach Bedarf um Ex- perten aus weiteren Disziplinen ergänzt werden. Geführt vom Problemprozesskoordinator ar- beiten die Problemlöser im Team selbständig und eigenverantwortlich. Wissenstransfergruppe Diese Gruppe setzt sich aus dem Problemprozess Manager und den Problemprozess Koordi- natoren zusammen. Das Ziel der Gruppe ist es, sich über die Problemlösungsprozesse auszu- 88 tauschen und einen Transfer von Problemlösungswissen sicher zu stellen. Dazu werden re- gelmäßig unter der Moderation des Prozessmanagers Meetings durchgeführt und über die erarbeiteten Wissensgebiete sowie Vorgehensweisen und eingesetzte Methoden diskutiert. Problemlösungszirkel Der Problemlösungszirkel setzt sich aus dem Problemprozess Manager, aus Führungskräften der beteiligten Organisations- und/oder Projekteinheiten sowie Stabsstellen wie z.B. Quali- tätsmanagement und je nach Bedarf den Koordinatoren der Problemlösungsprozesse zu- sammen. Abbildung 19: Stellen und Gremien im Problemlösungsprozess Im Kontext der Integration der Problemlösungsprozesse in die Geschäftsprozesse ist es erfor- derlich, bezüglich der Kosten und Leistungen bei der Lösung von Problemen ein entsprechen- des Konzept für die Leistungsverrechnung zu erstellen. 5.2.3 Beschreibung der Quality-Gates im Problemlösungsprozess Ein Problemlösungsprozess dient dazu, eine im Produktentwicklungsprozess aufgetretene Störgröße in strukturierter, systematischer Weise zu beseitigen, damit der Produktentwick- lungsprozess fortgeführt werden kann. In Anlehnung an den Produktentstehungsprozess ist es deshalb auch für den Problemlösungsprozess wichtig, dessen Reifegrad über Quality Gates transparent darzustellen, damit die Qualität der Ergebnisse in ausreichendem Maße sicherge- stellt ist und einer Synchronisation des Problemlösungsprozesses mit dem Produktentwick- lungsprozess nichts im Wege steht. Der Problemlösungsprozess trägt somit zu einer ganzheit- lichen Qualitätssicherung nach den Erfordernissen des Total Quality Managements (TQM) bei. Ein Quality Gate ist ein Kontrollpunkt, an dem die zuvor vereinbarten Leistungen zwischen Kunde und Lieferant gemessen und hinsichtlich ihrer Qualität und Vollständigkeit bewertet 89 werden (Parnov /110/, Wildemann /176/). Quality Gates markieren beispielsweise im Produkt- entwicklungsprozess den Anfang beziehungsweise das Ende wesentlicher Prozessabschnitte. Nur wenn zu diesen Fixpunkten spezifische Anforderungen an Produkt- bzw. Prozessreifegrad erfüllt sind, darf der jeweils nächste Prozessschritt angegangen werden. Wenn die Quality Gates nicht erfüllt werden, sind Maßnahmen zu ergreifen, die geeignet sind, das Quality Gate im zweiten Anlauf erfolgreich zu bestehen. Abbildung 20: Entscheidungsabläufe bei einem Quality Gate (in Anlehnung an /110/) Die Bewertung eines Quality Gates im Problemlösungsprozess erfolgt analog zum übergeord- neten Produktentstehungsprozess mit Hilfe der Ampelfarben grün, gelb, rot. Grün bedeutet, dass die Anforderungen erfüllt sind und die nächste Phase des Problemlö- sungsprozess frei geschaltet ist. Gelb zeigt an, dass die Anforderungen nicht vollständig erfüllt sind, also die nächste Phase nur bedingt frei geschaltet ist und ein konkreter Maßnahmen- und Zeitplan für die Sicherstel- lung der Anforderungserfüllung abgearbeitet werden muss. Rot bedeutet die Nicht-Erfüllung der Anforderungen. Die Ergebnisse sind nicht geeignet, die nächste Phase zu beginnen. Hier stellt sich die Frage nach einem Neustart oder einem Ab- bruch des Problemlösungsprozesses. Die inhaltliche Ausgestaltung der Quality Gates ist am Prozessgedanken orientiert, in dem die Anforderungen an das Quality Gate in Voraussetzungen strukturiert werden. Voraussetzungen beinhalten eine oder mehrere Messgrößen. Die Messgrößen wiederum besitzen einen eindeu- tigen Messwert, der den geforderten Sollwert oder den Zustand der Messgröße beschreibt. Er kann quantitativ (z.B. 1000€) oder qualitativ (z.B. ja/nein) definiert sein (Parnov /110/). Quality Gate 1 – Problemerfassung: Dieses erste Quality Gate schließt die Phase der Problemerfassung ab. QG n-1 QG n QG n+1passieren passieren mit Maßnahmen nicht passieren Maßnahmen abarbeiten ja ja, aber nein nein Prozessrück- stellung bei unver- ändertem Inhalt PLP abbrechen Prozessfort- schritt bei ge- ändertem Inhalt PLP weiter- führen jaja QG = Quality Gate PLP= Problemlösungsprozess 90 Voraussetzung Messgröße Messwert Vollständig beschriebenes Problem Ausgefülltes Problemticket mit Musskriterien: - Nummer - Titel - Problem Owner - Kurzbeschreibung - Projekt - Start-/Enddatum Mussfelder im Problemticket ausgefüllt: ja/nein Schweregrad des Problems hinsichtlich Zeit und Kosten Zeit: Dringlichkeit = geschätzte Zeit bis zur Lösung/Zeit bis zur Fälligkeit Schweregrad = Durch das Problem entstandene Kosten/ Umsatz des Unternehmensbereichs oder Schweregrad = Durch das Problem entstandene Kosten/Budget des Unternehmensbereichs oder Schweregrad = Durch das Problem entstandene Kosten/Projektvolumen Zahlenwert (indi- viduell festzule- gen) Tabelle 5: Kriterien für Quality Gate 1- Problemerfassung Als Anforderungen für die Freischaltung der zweiten Phase muss das Problemticket mit ent- sprechenden Feldern angelegt sein. Der Problem Owner muss beispielsweise beim Ausfüllen des Problemtickets mindestens zwei Schlagwörter mit dem Problem assoziieren. Dies dient einer besseren Dokumentation, auch hinsichtlich der Schlagwortsuche für zukünftige Problem- fälle. Zudem muss eine Abschätzung des Schweregrads des Problems hinsichtlich Zeit und Kosten erfolgen. Gegebenenfalls kann ein Koeffizient aus Kosten vs. Zeitfaktor ermittelt wer- den, um einen aggregierten Schweregrad zu erhalten. Der Schweregrad hinsichtlich Zeit kann über die Messgröße „Dringlichkeit“ gemessen werden. Um eine aussagekräftige Messgröße für den Schweregrad hinsichtlich Kosten zu erhalten, empfiehlt es sich, die Kosten auf eine andere Größe, eventuell den Umsatz oder das Projekt- volumen zu beziehen. Dabei ist zu definieren, ob der Umsatz der Produktgruppe, oder der Gesamtumsatz des Unternehmens zugrunde gelegt werden soll. Als zweite Möglichkeit kön- nen die Kosten, die das Problem verursacht, auf das Budget des Bereiches bezogen werden, in dem das Problem aufgetreten ist. In diesem Fall sieht man sehr schnell, wie groß das Prob- lem ist, jedoch muss man das Problem dann auch gezielt einem Bereich zuordnen können. Die Bestimmung der Schwere des Problems ist ein erfolgskritischer Faktor für die Lösung des Problems. Davon hängt beispielsweise ab, welche personelle Kapazitäten erforderlich sind, wie die Teamzusammensetzung aussehen muss, bzw. welche Hierarchieebenen involviert werden müssen. Quality Gate 2 – Lösungssuche Das Quality Gate 2 schließt die Phase der Lösungssuche ab. Wichtige Voraussetzung für die Problemlösung ist das Wissen darüber, ob das Problem neu ist oder bereits in ähnlicher Weise schon einmal aufgetreten ist. In jedem Fall muss eine Su- 91 che nach bestehenden Lösungen durchgeführt werden, gegebenenfalls existieren ähnliche Lösungen oder Teillösungen die auf das aktuelle Problem angepasst werden können. Dies vereinfacht und verkürzt die Problemlösung. Im Anschluss an eine Datenbankrecherche bzgl. des Problems erfolgt die Zuweisung eines Ansprechpartners. Dabei sollte als erstes natürlich Unternehmensintern nach einem Experten gesucht werden, eventuell über eine Wissensmanagement – Software oder Kompetenzdaten- bank. Abhängig vom Schweregrad des Problems muss auch die Möglichkeit in Betracht gezogen werden, externe Hilfe zu bekommen. Diese kann von Unternehmensberatungen, Ingenieurbü- ros oder auch wissenschaftlichen Instituten bezogen werden. Dabei sind jedoch individuelle Kriterien maßgeblich – nicht zuletzt die Unternehmensstrategie. Die Kriterien, die zum passieren dieses Quality Gates maßgeblich sind, sind also: Voraussetzung Messgröße Messwert Art des Problems: Neues oder altes Problem Ist das Problem in ähnlicher Weise bereits aufgetreten? ja/nein/weiß nicht Verwendung von beste- henden Lösungen Konnten ähnliche Lösungen gefunden wer- den? Nein/Teillösung/Vollständige Lösung Ansprechpartner Name des Problemprozesskoordinators Name Tabelle 6: Kriterien für Quality Gate 2 - Lösungssuche Quality Gate 3 - Situationsanalyse Dieses Gate schließt die Phase der Situationsanalyse ab. Als erstes ist es notwendig, die zur Verfügung stehenden Ressourcen zu prüfen, auch hin- sichtlich der durch das Problem gestellten Anforderungen (schätzt z.B. ein Experte, dass das Problem 800 Mann-Stunden zur Lösung braucht: reicht das Personal aus, das Problem recht- zeitig zu lösen?). Die möglichst umfassende Analyse der Einflussfaktoren ist sehr wichtig, da es dem Problem- lösungsteam ermöglicht, an den „richtigen Schrauben zu drehen“. Als die Maßgeblichen Kriterien zur Passage dieses Quality Gates werden gesehen: Voraussetzung Messgröße Messwert Anforderungsanalyse Ausgefüllter Anforderungskatalog vorhanden Ja/nein Einflussfaktorenanalyse Ausgefülltes Formular zur Einflussfaktorenanalyse vorhanden Ja/nein Zielanalyse Ausgefülltes Formular zur Zielanaylse vorhanden Ja/nein Machbarkeit in Bezug auf Dringlichkeit und Schwere- grad sowie der zur Verfü- gung stehenden Ressourcen Durchgeführte Machbarkeitsanalyse Machbar/nicht machbar/machbar unter Änderung der Rahmenbe- dingungen Tabelle 7: Kriterien für Quality Gate 3 - Situationsanalyse 92 Quality Gate 4 – Lösungsanpassung und -entwicklung Ausgehend von der Situationsanalyse (Ist/Soll-Zustand) sollen in diesem Schritt Lösungen gefundenen und auf ihre Realisierbarkeit geprüft werden. Folgende Voraussetzungen werden für dieses Quality Gate vorgeschlagen: Voraussetzung Messgröße Messwert Strukturierung und Analyse der Lösungsalternativen Ausgefülltes Formular zur Strukturierung und Ana- lyse der Lösungsalternativen vorhanden Ja/nein Generierte Lösungsalternati- ven Priorisierte Liste (Auswahlliste) von Lösungsalter- nativen vorhanden Ja/nein Tabelle 8: Kriterien für Quality Gate 4 – Lösungsanpassung und -entwicklung Quality Gate 5 – Lösungsverifizerung und Auswahl Das Quality Gate bewertet die ermittelten durchführbaren Lösungsalternativen bzw. –varianten auf ihren Einhaltungsgrad Bezug auf die gesetzten Anforderungen und Ziele sowie auf ihre Realisierbarkeit. Voraussetzung Messgröße Messwert Nutzen der durchführbaren Lösungsalternativen Durchgeführte Nutzwertanalyse vorhanden Ja/nein Abschätzung von Chancen und Risiken Chancen- und Risikoanalyse vorhanden Ja/nein Entscheidungsbegründung Dokumentation der Begründung für die Lösungs- auswahl vorhanden Ja/nein Tabelle 9: Kriterien für Quality Gate 5 – Lösungsverifizierung und Auswahl Quality Gate 6 – Lösungsumsetzung Dieses Quality Gate bewertet, in welchem Maße die umgesetzte Lösung zum Erfolg geführt hat, in welcher Weise die gesetzten Anforderungen an die Problemlösung in ihrer Gesamtheit erfüllt worden sind, in welcher Weise die Problemlösung Nutzen gestiftet hat, ob z.B. der vo- rausgehende Produktentwicklungsprozess fortgeführt werden kann. Voraussetzung Messgröße Messwert Erfolg und Nutzen der um- gesetzten Lösungsvariante Durchgeführte Nutzwertanalyse, Cost-Benefit Analyse oder Cost-Effectiveness Analyse vorhan- den Ja/nein Tabelle 10: Kriterien für Quality Gate 5 – Lösungsverifizierung und Auswahl 5.2.4 Methodenunterstützung Zur Unterstützung der Abarbeitung der einzelnen im Problemlösungsprozess beschriebenen Schritte bieten sich zahlreiche Methoden, Techniken und Hilfsmittel an. Hier sei beispielsweise auf die in der Literatur beschriebenen Sammlungen verwiesen. So beschreiben beispielsweise Daenzer/Huber et al. /24/ Methoden zur Unterstützung von Problemlösungsprozessen. Brauchlin/Heene /16/ beschreiben Methoden zur Unterstützung von Entscheidungen im Prob- lemlösungsprozess. Warnecke /166/ beschreibt die Einbindung von TRIZ-Werkzeugen in den Problemlösungsprozess. 93 Allerdings hat sich im Rahmen der Analyse bei den untersuchten Industrieunternehmen ge- zeigt, dass die Verbreitung und Nutzung von Methoden sehr gering ist. Zur Unterstützung der Problemlösung wurden lediglich die Methoden FMEA-Analyse, QFD, Nutzwertanalyse und Brainstorming eingesetzt. Als Gründe für die geringe Nutzung wurden unter anderem − die Unübersichtlichkeit und Vielfalt der Methoden − der teilweise sehr hohe Zeitaufwand bei der Verwendung der Methoden − eine zu geringe Praxistauglichkeit vieler Methoden − eine unzureichende Benutzerfreundlichkeit der Methoden genannt. Auch andere Untersuchungen (Landauer /93/) bestätigen dies. Diese Aussagen kön- nen jedoch nicht als eine grundsätzliche Ablehnung eines Methodeneinsatzes interpretiert werden, da von allen Befragten Handlungsbedarf in einer Unterstützung der Problemlöse- schritte durch ausgewählte, praxisorientierte Methoden gesehen wurde. Um den Problemlösungsprozess so einfach wie möglich zu halten wurde die methodische Unterstützung deshalb jeweils auf die Verwendung von nur einer geeigneten Methode be- schränkt. So wird den am Problemlösungsprozess Beteiligten eine praxistaugliche, einfach anzuwendende Methode vorgeschlagen. Dazu erhält der Problemlöser eine kurze Beschrei- bung über den Einsatz und die Funktionsweise der Methode sowie vorgefertigte Formulare und Tabellen, die nur noch auszufüllen sind. Ebenfalls erleichtert es den Methodeneinsatz, wenn der Problemlöser zu jeder vorgeschlagenen Methode ein Anwendungsbeispiel erhält. In der Abbildung 21 ist dies für die Methode „Einflussfaktorenanalyse“ beispielhaft dargestellt. Abbildung 21: Datenblatt für die Methode „Einflussfaktorenanalyse“ 94 Die Auswahl der Methoden zu den einzelnen Prozessschritten erfolgte nach der Art der jewei- ligen erforderlichen Tätigkeit im Prozessschritt. In Anlehnung an die Tätigkeiten in Prozessen (Ruprecht/Rose et al. /126/, Görner /56/) können im definierten Problemlösungsprozess grundsätzlich folgende Tätigkeiten bzw. kognitive Leistungen unterschieden werden: − Kreative Tätigkeiten wie Konzept- und Entwurfstätigkeiten − Bewertungs-, Kontroll- und Entscheidungstätigkeiten − Planungstätigkeiten − Recherchetätigkeiten, Tätigkeiten zur Informationsrecherche − Analysetätigkeiten − Optimierungstätigkeiten − Kommunikationstätigkeiten − Dokumentationstätigkeiten Diesen Tätigkeiten können Methoden zugeordnet werden. So können beispielsweise einer Analysetätigkeit Methoden wie z.B. Risikoanalyse, Fehlerbaumanalyse, Wertanalyse, Ent- scheidungstabellen oder einer Konzeptionstätigkeit Methoden wie z.B. Brainstorming, 635 Methode oder Szenario-Planung zugeordnet werden. Die Kriterien für die Zuordnung von nur einer Methode zu den einzelnen Problemlösungsschritten waren dabei: − Einfache, zeitsparende, benutzerfreundliche Anwendung − Praxistauglichkeit, d.h. Möglichkeit der Anpassung auf betriebliche Probleme − Bekanntheitsgrad bei den Anwendern Die Klassifikation der Problemprozessschritte in die jeweilige Art von Tätigkeit sowie die Zu- ordnung einer Methode Problemlösungsschritten ist in folgender Abbildung dargestellt (Abbildung 22): 95 Abbildung 22: Methoden und Werkzeuge zur Unterstützung der Problemlösung 5.2.5 Integration in die Unternehmensprozesse – der Problemlösungsprozess als Un- terstützungsprozess Der Problemlösungsprozess wird im Kontext dieser Arbeit als Unterstützungsprozess gese- hen. Die Einordnung des Problemlösungsprozesses als Unterstützungsprozess bedeutet, dass die Aufgabe, deren Bewältigung ein Problem verursacht, in einen Geschäftsprozess ein- geordnet sein kann. Dabei stellt sich die Frage, wo die Schnittstellen zwischen dem auslösen- den Prozess und dem Problemlösungsprozess als Unterstützungsprozess zu suchen sind. Als auslösender Prozess kommen dabei primär Führungs- und Leistungsprozesse, sekundär auch andere betriebliche Unterstützungsprozesse in Frage. Ein Problemlösungsprozess kann dabei in Gang gesetzt, wenn im geplanten Soll-Prozess im Rahmen der Bewältigung einer zumeist komplexen, schwierigen Aufgabe ein unerwünschter Zustand bzw. ein unerwünschtes Ereignis eintritt. Das Ziel ist es, als Output des Problemlösungsprozesses wieder eine Übereinstimmung von SOLL- und IST-Prozess zu erzielen, d.h. die Zustandsabweichung zu beseitigen. Problem- erfassung Lösungs- suche Situations- analyse Lösungs- entwicklung Lösungs- verifizierung Lösungs- umsetzung Evaluation QG6 QG5 QG4 QG 3 QG 2 QG 1 Problemlösungsprozess  Initialisierung Problemticket Recherche nach vorh. Lösungen Dokumentation und Verdichtung Definition Ansprechpartner Ermittlung Lösungsanforderungen Detailanalyse Zielformulierung Dokumentation und Verdichtung Generierung alt. Lösungsvorschläge Lösungsanalyse und –optimierung Dokumentation und Verdichtung Bewertung der Lösungsalternativen Auswahl und Entscheidung Dokumentation und Verdichtung Planung der Umsetzung Umsetzung der Problemlösung Abschließende Bewertung Methoden & Werkzeuge Formular zur Problem- beschreibung Anleitung, Suchmaschine Anleitung, Checkliste Anforderungskatalog 360° Analyse Ursachen-, Einflußfaktorenanalyse Zielkatalog, Chancen/Risikoanalyse Anleitung, Checkliste Anleitung, Brainwriting-Formular Anleitung, Strukturierung-Analyse Anleitung, Checkliste Anleitung, Nutzwertanalyse Anleitung, Checkliste Anleitung, Checkliste Anleitung, Checkliste Liste mit Ansprechpartner 96 Abbildung 23: Zusammenhang zwischen betrieblichem Prozess und Problemlösungsprozess nach Primus /117/ Der Problemlösungsprozess gilt als abgeschlossen, wenn die auslösende Zustandsabwei- chung zwischen einem SOLL und einem vergleichbaren IST durch Maßnahmen nachweislich beseitigt wurde. Aufgrund der zeitlichen Instabilität von Zuständen muss im laufenden Prob- lemlöseprozess ein permanenter Abgleich mit dem auslösenden Prozess stattfinden. Nach Frankenberger /46/ besteht ein Geschäftsprozess aus Arbeitsschritten, die in der Regel über einen längeren Zeitraum konstant sind. Im Gegensatz dazu beschreiben Problemlöse- schritte Prozesse der Informationsverarbeitung, mit denen die in den einzelnen Arbeitsschrit- ten beschriebene Teilziele erreicht werden. Die einzelnen Problemlöseschritte sind oft nur wenige Minuten konstant und können damit innerhalb eines Arbeitsschrittes mehrfach wech- seln. Kritische Situationen im Problemlösungsprozess liegen dann vor, wenn die Richtung der Prob- lembearbeitung in Bezug auf das Ergebnis positiv oder negativ beeinflusst wird, oder die Mög- lichkeit einer Beeinflussung besteht. Zur Entscheidungsfindung wird hier oft umfangreiches Wissen benötigt. Kritische Situationen können sich außer aus dem Problemlösungsprozess auch aus zusätzlichen Ereignissen ergeben (Störungen oder Konflikte). Im Kontext dieser Arbeit wird der Problemlösungsprozess in Anlehnung an Haberfellner als Mikro-Logik betrachtet. Dies bedeutet, dass der Problemlösungsprozess bei jeder Art von Problemstellung in jeder Projekt- bzw. Prozessphase und in jeder anderen, nicht- prozessspezifischen Situation im Arbeitsalltag angewendet werden kann. Die Abarbeitung kann sich zeitlich von mehreren Minuten (ad-hoc Problemlösung) bis zu mehreren Tagen (langfristige Problemlösung) hinziehen (Daenzer/Huber et al. /24/). Betrieblicher Prozess z.B. Entwicklungsprozess Problem- lösungs- prozess Input IST ≠ SOLL Output IST = SOLL Kontinuierlicher Abgleich 97 Abbildung 24: Zusammenhang zwischen Geschäftsprozess und Problemlösungsprozess Ziel der Problemlösung im Sinne dieser Arbeit ist es dabei, komplexe Problemstellungen mit unscharfem Ziel und unbekanntem Lösungsweg zu Aufgabenstellungen mit klarem Ziel und klarem Lösungsweg zu transformieren. Die Voraussetzung für eine solche Transformation ist ein systematisches, strukturiertes Vor- gehensmodell sowie die Dokumentation und Archivierung von Problemstellungen, Problembe- schreibungen und -lösungen. Der Fokus liegt somit auf der Bereitstellung des „Wie“ sowie Verweise auf das „Was“. Der Mehrwert des Problemlösers liegt hierbei in der Steigerung der Wissenstransparenz im Problembereich. Der Anwender wird durch das systematische Vorge- hensmodell befähigt, Lösungen strukturiert selbst zu entwickeln. Das Ergebnis des Problemlö- sungsprozesses ist somit nicht die konkrete Lösung selbst sondern vielmehr die Transparenz über den Lösungsweg und das hierzu benötigte Wissen. Nach der Transformation der Problemstellung in eine Aufgabenstellung, bzw. nach der Lösung des Problems wird der führende Geschäftsprozess fortgesetzt. Die Prozessführung kann da- bei beispielsweise wieder durch klassische Workflow-Systeme übernommen werden. 5.2.6 Gestaltungsempfehlungen für die Organisation und Koordination von Problem- lösungsprozessen Folgende Gestaltungsempfehlungen werden für die Organisation und Koordination von Prob- lemlösungsprozessen vorgeschlagen: − Die Verankerung des Problemlösungsprozesses in die bestehende Prozessstruktur als auch die organisatorische Integration des Rollenmodells in bestehende Organisationsstruk- turen sichern eine nachhaltige Implementierung des Problemlösungsmanagements. Auch Problem- analyse Problem- formulierung System- synthese System- analyse Beurteilung Entscheidung Problemlösungsprozess als Unterstützungsprozess Lösung des Problems Entwicklungsprozess Phasen und Aufgaben Angebotsphase Grobentwicklungsphase Konzeptphase Feínentwicklungsphase Realisierungsphase Anlaufphase Serie Produktionsphase 98 ist eine Verknüpfung zu angrenzenden thematischen Bereichen wie Qualitätsmanagement, Wissensmanagement und Prozessmanagement notwendig. Beispielsweise können im Be- reich Qualitätsmanagement Prozesse wie KVP oder Methoden wie FMEA sinnvoll einge- bunden werden. Im Bereich Wissensmanagement kann das Problemlösungsmanagement in Wissensnetzwerken integriert sein, die den aktiven, projektbegleitenden Erfahrungs-, Ideen- und Wissensaustausch zwischen kritischen Know-how Trägern unterstützen. Zentra- le Aufgabenstellungen im Wissensnetzwerk können hierbei zum einen die effiziente, inno- vationsorientierte Problemlösung sowie zum anderen die problemorientierte, fachliche Wei- terentwicklung von Kompetenzen sein. − Eine IT-Unterstützung ermöglicht eine effiziente Abwicklung verteilter Problemlösungspro- zesse im Wissensnetzwerk. Dies kann beispielsweise durch eine IT-Unterstützung des Problemlösungsprozesses in Form eines Problemlösungsassistenten erfolgen. Auch Wis- sensnetzwerk/Community Portale oder klassische CSCW können die kooperative, verteilte Arbeit des Problemlösungsteams beispielsweise durch Dokumentenmanagement, Mecha- nismen zum Informationsretrieval sowie Kommunikationswerkzeuge unterstützen. Durch die IT-gestützte Problemlösung können alle Phasen des Problemlösungsprozesses gezielt unterstützt und beschleunigt werden. Zudem erleichtert und gewährleistet die IT-Lösung die einfache Dokumentation von Problemlösungen. Um umfangreiche, zeitaufwendige Doku- mentationen zu vermeiden, erfolgt die Wissenssicherung teilautomatisch und in Form von strukturierten Abfragen. Dies ist insbesondere für die schnelle Wiederfindung und -verwen- dung von Lösungswissen entscheidend. Damit der Mitarbeiter dabei ohne Systembruch ar- beiten kann, sollten IT-Werkzeuge für die Problemlösung in die integrierte Arbeitsumge- bung des Unternehmens eingebettet sein. − Der Mitarbeiter sollte methodisch fundiert und strukturiert durch alle Phasen des Problem- lösungsprozesses aktiv geführt werden. Es ist sinnvoll, ihm neben Vorgehensweisen in je- der Phase Werkzeuge, Methoden und Hilfsmittel zur Lösungsentwicklung zur Verfügung zu stellen. Die methodische Unterstützung muss einfach sein, d.h. es empfiehlt sich, sich auf wenige, verständliche und im Unternehmensumfeld praktisch anwendbare Methoden zu konzentrieren. Das Aufzeigen von Fallbeispielen, welche die Anwendung der Methode bei- spielsweise anhand eines bereits gelösten Problems darstellen, erleichtert zudem den Ein- satz und die Nutzung der zur Verfügung gestellten Methoden. − Um den Erfolg des implementierten Problemlösungsmanagements im Unternehmen mess- bar zu machen und zu überprüfen, bietet sich die Bewertung des einzelnen Problemlö- sungsprozesses beispielsweise im Sinne eines Quality Gate Prozesses an. Sinnvolle Be- wertungsindikatoren können hier beispielsweise das Bedrohungspotenzial, die Problemlö- sungsqualität oder die realisierte Wertsteigerung sein. Eine übergeordnete Bewertung kann durch die Messung von Indikatoren wie beispielsweise die aggregierte Wertsteigerung bei Stakeholdern pro Zeiteinheit oder die Anzahl wahrgenommener bzw. identifizierter Proble- me pro Prozess und Mitarbeiter erfolgen. 5.3 Gestaltungselement „Kommunikation und Wissensaustausch“ 5.3.1 Problemlösung im Team Die Umgestaltungen der Arbeitsabläufe in der Produktentwicklung, z.B. durch Simultaneous Engineering oder Concurrent Engineering, führen zu einer stärkeren Verknüpfung mit anderen 99 Unternehmensbereichen durch überlappende und teilweise parallele Arbeitsabfolgen (Ehr- lenspiel /44/). Für den einzelnen Problemlöseprozess bedeutet dies, dass durch den erhöhten Informations- austausch und eine verstärkte Kooperation neben der Verrichtung von Problemlöseschritten in Einzelarbeit (individuelle Problemlösung) der Bewältigung von Teilschritten in Gruppenarbeit (Problemlösung im Team) eine immer größere Bedeutung zukommt. Das Problemlösungsteam, die für mehrpersonale Problemlösungsprozesse am häufigsten angewandte Systemform, ist durch folgende Merkmale charakterisiert (Högl /72/): − Ein Problemlösungsteam ist eine soziale Einheit von zwei oder mehr Personen. − Deren Mitglieder werden als solche erkannt und nehmen sich selber als Mitglieder wahr. − Die Mitglieder sind eingegliedert in eine Organisation. − Die Mitglieder erledigen durch unmittelbare Zusammenarbeit gemeinsame Aufgaben. Der besondere Wert der Teamarbeit besteht darin, dass Menschen Wissen aus unterschiedli- chen Wissensdomänen sowie verschiedenste Fähigkeiten und Erfahrungen in einen gemein- samen Problemlösungsprozess einbringen (Hungenberg /74/). Hierdurch können synergeti- sche Effekte geschaffen werden. Die in Teamarbeit erzielbaren Ergebnisse können so die Ergebnisse übertreffen, die erreicht werden, wenn nur ein einzelner Problemlöser sein wissen und seine Fähigkeit zur Problemlösung nutzt. Als Leistungsvorteile von Teams bzw. Gruppen können folgende Aspekte aufgezählt werden: − Größeres Wissensspektrum − Höhere Wahrscheinlichkeit der Betrachtung des Problems aus unterschiedlichen Blickwin- keln − Höheres Engagement der Beteiligten (gegenseitige Motivation) − Verbesserte Kontrolle − Einfache Lernprozesse Somit ist auch Aspekt der Teamarbeit ein wesentlicher Einflussparameter auf das Problemlö- sen. Das Ziel kann hierbei durch kooperatives oder kompetitives Verhalten erreicht werden (Schnurr/Staab et al. /131/). Grundsätzlich können dabei kooperative Interaktionssituationen als entlastend, kompetitive als belastend bezeichnet werden. In kompetitiven Interaktionssituationen wird das Problem als schwieriger beurteilt und stärker die Befürchtung geäußert, an der Aufgabe zu scheitern. Wettbewerb bewirkt sozial-interaktiven Stress und eine verstärkte Wahrnehmung von Zeit- druck und Kommunikationsschwierigkeiten. Mit der offenen Grundhaltung in kooperativen In- teraktionssituationen geht hingegen eine intensivere und breitere Kommunikation einher. Die größere Breite des Informationsflusses bei Kooperation führt zu einem intensiveren Gedan- kenaustausch und zu signifikant höherer Qualität der Problemlösung. Hinsichtlich der Leis- tungsnivellierung wird in kooperativen Interaktionssituationen die Problemlöse-Qualität der schwächeren Gruppenmitgliedern gestärkt. Zudem benötigen kooperative arbeitende Teams weniger Zeit für die Bearbeitung des Problems und bringen der gemeinsamen Problemlöse- leistung mehr Wertschätzung entgegen. Aus der Problemlösediskussion erzielen darüber hin- aus kooperative Teams größere Lerngewinne als die Mitglieder kompetitiv arbeitender Teams (Wetzel /174/), d.h. im Anschluss an den Problemlöseprozess liegt eine breitere gemeinsame Wissensbasis vor. 100 Dies bedeutet für die wissensbasierte Problemlösung, welche Kreativität erfordert und durch eine hohe Komplexität oder Vieldimensionalität gekennzeichnet ist, dass die Strategie der Ko- operation empfohlen wird. Diese setzt ein Berücksichtigen aller Vorstellungen an der Verifika- tion des Problems beteiligten Personen voraus. Denn eine demokratische Entscheidungsfin- dung führt zu einer höheren Identifikation der Teammitglieder mit der Entscheidung, so dass diese auch engagierter umgesetzt wird. Hinsichtlich der optimalen Problemlösungsteam-Größe wird die Kommunikation und die Koor- dination einzelner Beiträge mit steigender Mitgliederanzahl zunehmend aufwendig. Die Opti- male Teamgröße liegt bei drei bis zwölf Mitgliedern. Die Größe eines Teams ist immer in Rela- tion zur Schwierigkeit des zu lösenden Problems zu sehen. Wird die Größe des Teams im Verhältnis zum Problem als zu klein empfunden, sinkt der Teamglaube an eine Lösung. Ist das Team überbesetzt, besteht die Gefahr, dass das Problem vom Team als nicht motivierend empfunden wird. Bei zunehmender Verteiltheit von Produktentwicklungsprozessen über unterschiedliche Standorte und über Unternehmensgrenzen hinweg, sind auch für die Problemlösung räumlich und zeitlich verteilt arbeitende Problemlösungsteams, so genannte virtuelle Teams, erforder- lich. Diese können durch unterschiedliche I&K Technologien asynchron als auch synchron in ihrer Arbeit unterstützt werden. 5.3.2 Kommunikationsbeziehungen Kommunikation kann als Grundlage jeglichen kollektiven Handelns bei der Problemlösung angesehen werden. In diesem Kapitel wird auf die verschiednen Formen von Kommunikati- onsbeziehungen eingegangen als auch der Begriff selbst definiert. Es wird hier auf die vielfältigen Definitionen von Kommunikation verwiesen (Shannon/Weaver /144/, Shannon /145/). Für die vorliegende Arbeit wird Kommunikation nach Maturana/Varela /96/ definiert als das „...das gegenseitige Auslösen von koordinierten Verhaltensweisen unter den Mitgliedern einer sozialen Einheit...“ Kommunikation ist zentraler Gestaltungsparameter einer systemischen Intervention und kann dabei verbal als auch nonverbal stattfinden. Interaktionsbeziehungen existieren zum einen zwischen den am Problemlösungsprozess beteiligten Individuen (Kommunikation als semioti- scher Prozess). Zum anderen können sie entkoppelt voneinander durch Zugriff auf die Daten- ebene die Prozesse Information und Dokumentation auslösen (Kommunikation Mensch- Maschine), wenn sich Sender und Empfänger nicht in einem gemeinsamen sozialen System befinden. Damit existieren zwischen diesen Individuen und technischen Systemen, wie z.B. Datenbanksystemen Interaktionsbeziehungen in Form von Wahrnehmungsprozessen (Infor- mation) und Handlungen (Dokumentation). In diesem Kapitel wird insbesondere die Kommunikation zwischen Individuen im Problemlö- sungsprozess betrachtet, während im nachfolgenden Kapitel 5.3 im Rahmen der Wissensin- tegration und Wissensgenerierung auf die Wissensprozesse Information und Dokumentation näher eingegangen wird. Die Kommunikationsbeziehungen der im Problemlösungsprozess involvierten Personen sind in Abbildung 25 dargestellt. 101 Abbildung 25: Kommunikationsbeziehungen im Problemlösungsprozess Die Kommunikation kann zwischen den Beteiligten entweder − formell oder − informell erfolgen. Die Qualität der über formelle Kanäle, wie beispielsweise Problemstatusgespräche erhaltenen Informationen entspricht allerdings oftmals nicht den Anforderungen (Bismark/Held /13/). So wird zwar der formellen Kommunikation ein sehr hoher Stellenwert beigemessen, die Qualität wird allerdings nur eingeschränkt als gut bewertet. Deshalb macht die informelle Kommunikation einen bedeutenden Anteil der Kommunikation aus. Diese findet bei spontanen Treffen auf dem Gang, in der Kaffeeküche, Kantine, bei sozialen Anlässen oder im Büro statt. Die informelle Kommunikation fördert das Wohlbefinden am Arbeitsplatz und schafft Unter- nehmenskultur, hilft aber auch bei Konfliktvermeidung. Sie dient dem sozialen Klima und dem Teamgeist, fördert somit auch die Zusammenarbeit. Zudem werden viele Informationen schnell vermittelt. Die informellen Kommunikationssituationen betreffen in etwa der Hälfte der Fälle Gespräche zwischen Kollegen, seltener Gespräche zwischen Mitarbeiter und Vorgesetzten (Bismark/Held /13/). Auch bei informellen, spontanen Interaktionen überwiegen dabei deutlich fachliche The- men, bezogen auf die momentane Tätigkeit. Da die Verteiltheit der Zusammenarbeit zukünftig stark zunehmen wird (Bismark/Held /13/, Warschat/Wagner /170/), kommt insbesondere den informationstechnologischen Medien zur Unterstützung räumlich getrennt arbeitender Problemlöser, aber auch geeigneten organisato- rischen Medien eine große Bedeutung zu. Problemprozess Koordinator Problemprozess Manager Identifiziert und meldet Problem Problemlöser Führungsaufgabe Prozesstreiber Problemlöser Experte PL-Team Problem Owner beauftragt meldet Ausführung benennt Koordinator, entscheidet meldet Ausführung meldet Ausführung zieht hinzu Problemprozess Manager Wissenstransfergruppe Problemprozess Koordinator A Problemprozess Koordinator B Problemprozess Koordinator N . . . Problemlösungszirkel Problemprozess Manager QM Manager (FMEA) Bereichs- Leiter Projekt- Leiter Problemprozess Koordinator A Problemprozess Koordinator B Problemprozess Koordinator N . . . Moderator moderiert, entscheidet berichtet berichtet entscheidet 102 5.3.2.1 Informationstechnologische Medien zur Unterstützung der Kommunikation Im Rahmen einer Untersuchung /170/ wurde der Einsatz von I&K Systemen als auch von or- ganisatorischen Methoden in Unternehmen untersucht (Abbildung 26 und Abbildung 27). Un- terschiedliche I&K Systeme, wie z.B. E-Mail, Groupware, können die Kommunikation unter- stützen. Abbildung 26: Technische Systeme der Kommunikation 100 Prozent der Respondenten setzen die Email zur Unterstützung der Kommunikation in der Kooperation ein. Der Einsatz von Fax ist mit 98 Prozent trotz starkem Emailverkehr immer noch weit verbreitet. An dritter Stelle mit 96 Prozent folgen als häufig verwendete Medien zur Kommunikation das Telefon und das Handy. 47 Prozent der Unternehmen benutzen das Int- ranet als Kommunikationsplattform, aber nur 24 Prozent das Extranet. Dabei wurden die Bal- ken „Keine Angaben“ wegen der Redundanz der Informationen in der Grafik nicht dargestellt. Die Nutzung korrespondiert mit der Zufriedenheit. So erzeugen die vernetzten Medien wie Email die höchste Zufriedenheit, gefolgt von konventionellen Medien und Konferenzmedien. Insgesamt ist die höchste Zufriedenheit bei dem Medium E-Mail. Mit Abstand folgen das Fax und weitere vernetzte Medien wie Intranet, Internet, gemeinsame Datenverwaltung und ge- meinsame elektronische Terminplaner. Die Konferenzmedien schneiden hinsichtlich der Zu- friedenheit relativ schlecht ab. Bedingt können Application-Sharing, Audiokonferenzen und Desktop-Videokonferenzen Zufriedenheit erzeugen. 5.3.2.2 Organisatorische Medien zur Unterstützung der Kommunikation Organisatorische Methoden, zur Unterstützung der Kommunikation und deren prozentuale Anwendungshäufigkeit sind in der folgenden Abbildung dargestellt. Dabei wurden die Balken „Keine Angaben“ wegen der Redundanz der Informationen in der Grafik nicht dargestellt. 96% 24% 98% 47 % 9% 100% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Telefon, Handy Fax Intranet Extranet Groupware Email 103 Abbildung 27: Organisatorische Medien zur Unterstützung von Kommunikation Hier spielen nach wie vor Meetings in festen und losen Abständen eine große Rolle. Auch die Kommunikation durch die Teilnahme an Arbeits- und Expertenkreisen wird von fast zwei Drittel der Befragten genutzt. Auch Informationsveranstaltungen und informelle bzw. soziale Aktivitä- ten werden von etwa der Hälfte der Befragten zur Unterstützung der Kommunikation bevor- zugt. Allerdings zeigt sich, dass die informelle Kommunikation trotz ihrer Bedeutung tendenziell eher weniger gefördert wird. Nicht einmal ein Drittel der Befragten sind der Ansicht, dass sich das Unternehmen um diese Form der Kommunikationsbeziehung besonders bemüht. Die Kommunikation befähigt die Akteure im Problemlösungsprozess zum Wissensaustausch. Daher befasst sich das nachfolgende Unterkapitel mit dem Austausch von Wissen und dem Wissenstransfer im Problemlösungsprozess. 5.3.3 Wissensaustauschprozesse Der Begriff Wissensaustausch wird in dieser Arbeit als Prozess des wechselseitigen, bidirekti- onalen Austauschs von Gedanken, Meinungen, Wissen, Erfahrungen und Gefühlen verstan- den. Hingegen bezeichnet der Wissenstransfer die unidirektionale Übertragung und Weiterga- be von Erfahrungen und Wissen von einer Person zur Anderen. Der Fokus liegt hier auf dem Gegenstand der Kommunikationsaktivität, weniger auf der Form und Art der Übertragung. Die Verfügbarkeit von Wissen ist Erfolgsvoraussetzung bei der Lösung von Problemen. Für einen erfolgreichen Wissensaustausch ist es notwendig, dass die Teammitglieder in der Lage sind, das ihnen zur Verfügung stehende Wissen im Verlauf der Interaktionen aus dem Ge- dächtnis abzurufen. Frankenberger /46/ hat bei Konstruktionsprojekten vier verschiedene Möglichkeiten des Austauschs beobachtet: 20% 62% 64% 53% 31% 47 % 56% 16% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Informationsveranstaltungen Postwurfsendungen Arbeits-/Expertenkreise Meetings in festen zeitlichen Abständen Meetings in losen zeitlichen Abständen Informelle / soziale Aktivitäten Foren Seminare 104 − Ingenieure suchen gezielt bestimmte Informationen bei ihren Kollegen − Ingenieure suchen allein, z.B. in Katalogen oder Datenbanken nach wichtigen Informatio- nen − wichtige Informationen werden zusätzlich in Gesprächen ausgetauscht − Konstrukteure erhalten passiv von ihren Kollegen Informationen. Trittmann/Mellis /157/ sprechen hier von zwei Grundformen des Wissenstransfers: − dem kodifizierten Wissenstransfer und − dem personalisierten Wissenstransfer. Beim kodifizierten Wissenstransfer wird Wissen über den Zugriff des Empfängers auf Doku- mente bzw. Datenbanken transferiert. Ein Vorteil dieser Form ist, dass erfahrene Mitarbeiter von häufigen Anfragen entlastet werden, und Erfahrungen können einer beliebigen Anzahl von Mitarbeitern zur Verfügung gestellt werden. Bei einem personalisierten Wissenstransfer erfolgt der Austausch direkt über interpersonelle Kontakte. Dabei kann es sich um Gespräche aber auch um einen Transfer durch Nachahmung handeln. Auch hier können Informations- und Kommunikationsmedien wie Video-Conferencing räumliche Grenzen zwischen dem Sender und Empfänger überbrücken. Der Schwerpunkt der Betrachtung liegt in diesem Kapitel auf dem Wissensaustausch zwischen Personen. Beim Wissensaustausch werden also Informationen im Kontext übertragen. Zumeist ist dies jedoch nur durch Interaktion zwischen Personen möglich und kann nur bedingt durch maschi- nelle Interaktion erfolgen. Daraus lässt sich ableiten, dass die Wissensreichhaltigkeit einer Information mit der Nähe der Kommunikanten zunimmt(North /108/). Ein Wissenstransfer oder der Austausch von Wissen kommt zustande, sobald eine Wissens- lücke entsteht, und das Wissen zum Schließen der Lücke beschafft werden muss. Der Pro- zess der Wissensweitergabe wird nach Szulanski /154/ in vier Phasen eingeteilt: 1. Initiierung: Die Phase der Initiierung beschreibt die Idee, Informationen auszutauschen und das Abwägen des Sinns bzw. des Nutzens. 2. Implementierung: In dieser Phase werden die transfer-spezifischen Verbindungen zwi- schen dem Sender und Empfänger eingerichtet. Der höchste Fluss an Informationen findet dabei statt. 3. Ramp-up: Das neue Wissen wird in dieser Phase zum ersten Mal angewendet, die In- formationen werden integriert. 4. Integration: Hier wird die Entscheidung über die weitere Verwendung und Anwendung des neuen Wissens getroffen. Vier Faktoren steigern die Relevanz des Wissensaustauschs und die Suche nach neuen Mög- lichkeiten für einen Wissensaustauschs: − ähnliche Probleme an unterschiedlichen Orten − Wissensintransparenz − vermutete Synergien durch Erfahrungsaustausch und − das menschliche Grundbedürfnis nach Wissenteilung. Der Wissensaustausch lässt sich somit auch als Teil des Problemlösungsprozesses und Mittel des Problemlösens betrachten (kognitive Dimension).Eine weitere Dimension tut sich auf, 105 sieht man den Wissensaustausch weitergehend als „kooperatives Lernen“ an (pädagogische Dimension) (Buder /17/). 5.3.4 Wissensbarrieren als Hemmnisse des Wissensaustausch Häufig wird in der Praxis festgestellt, dass das potentiell zur Problemlösung erreichbare Wis- sensreservoir praktisch nicht nutzbar ist und somit nicht zur Erweiterung der individuellen und kollektiven Wissensbasis genutzt werden kann. Wissen, welches für die Problemlösung nicht zur Verfügung steht wird im günstigsten Fall ressourcenintensiv erneut und damit redundant entwickelt oder aber geht der Wertschöpfung schlicht und einfach verloren. Es existieren also offensichtlich Barrieren, welche einen effektiven und umfassenden Wis- sensaustausch erschweren oder ganz verhindern (Schüppel, /137/). Im folgenden werden zwei Unterscheidungsdimensionen von Barrieren in Hinblick auf indivi- duellen und kollektiven Wissenstransfer dargestellt. Die erste Unterscheidungsdimension be- trifft die Wissensträger und Formen des Transfers: − Das Wissen eines Individuums wird innerhalb seiner Arbeitsgruppe oder gegenüber Mit- gliedern der Organisation über einen personenbezogenen Wissenstransfer vermittelt. Ent- scheidend ist hier der einzelne und sein Wissenspotential. − Auf Gruppenebene haben Sozialisierungsprozesse und die Personalselektion zur Ausbil- dung von gruppentypischen Denkmustern, Werten und Standards geführt, welche durch ei- nen personenübergreifenden Wissenstransfer die Entstehung kollektiven Wissens ermögli- chen. Dieses Wissen kann weitgehend unabhängig von den Gruppenmitgliedern existieren. − Innerhalb einer Gesamtorganisation aus Gruppen und übergeordneten organisatorischen Bereichen tritt zum internen personenübergreifenden Wissenstransfer noch ein gruppen- und bereichsübergreifender Wissenstransfer hinzu, welcher durchaus auch über Organisa- tionsgrenzen hinaus wirken kann. − Individuelle Wissensbarrieren beeinträchtigen hier den personenbezogenen Wissenstrans- fer, was in einer mangelhaften Verbreiterung der Wissensbasis resultiert. − Kollektive Wissensbarrieren wirken einerseits negativ auf den personenübergreifenden Wissenstransfer, andererseits aber auch auf den gruppen- und bereichsübergreifenden Wissenstransfer. In der Folge bleiben nicht nur Wissensreservoirs innerhalb der Gruppe isoliert, auch Potentiale und alternative Sichtweisen verschiedener Gruppen leiden z.B. un- ter Kompatibilitäts- und Integrationsproblemen. Die zweite Dimension wird durch Barrieren der Wissenslogistik bestimmt: − Strukturelle Barrieren ergeben sich aus den materiellen Bedingungen von Systemen. Hier sind einerseits Aufgaben- und Kompetenzstrukturen zu nennen, die zur Auflösung des ganzheitlichen Bezuges und zur Schnittstellenproblematik führen. Andererseits existieren ggf. Prozessschemata, welche den Fluss eventuell vorhandenen Wissens durch geltende Vorgehensregelungen behindern. − Politisch-kulturelle Barrieren hingegen resultieren aus gewachsenen Doktrinen des Sys- tems. So wird häufig aus persönlichen oder machtpolitischen Gründen Wissen zurück- gehalten, manipuliert oder gar vernichtet. 106 Abbildung 28: Wissens- und Lernbarrieren im Überblick (nach Schüppel /137/) Die Transparenz über die potentiellen Bruchstellen ermöglicht schließlich Interventionen zum Abbau derartiger Wissens- und Lernbarrieren und dient einer optimalen Organisation des Wis- sens entlang des Problemlösungsprozesses. 5.3.5 Expertenvernetzung durch Kompetenzprofile Durch die Rollenzuweisung im Problemlösungsprozess (s.o.) wird im vorab eine Auswahl ge- troffen, welcher Mitarbeiter verantwortlich für die Lösung eines Problems ist, und welche Mit- arbeiter operativ das Problem lösen. Welcher Mitarbeiter in der Lage ist, ein Problem effizient und effektiv zu lösen, war in der Vergangenheit entweder ein stark intuitives Auswahlverfah- ren, oder, wie im klassischen Skill-Management, beruhte auf nicht praxisbezogenen Daten. Durch die Verbindung des Problemlösungsprozesses mit Kompetenzprofilen besteht die Mög- lichkeit, stets aktuelle Kompetenzdaten einzelner Mitarbeiter über die gesamte Unterneh- mensstruktur hinweg zu erhalten und somit stets den am besten qualifizierten Mitarbeiter für eine bestimmte Problemlösung zu identifizieren. Das führt dazu, dass das individuelle Wissen der Mitarbeiter optimal genutzt werden kann und eine unnötige Überlastung einzelner Indivi- duen im Problemlösungsprozess vermieden wird. 5.3.5.1 Ziel und Nutzen von Kompetenzprofilen Ziel ist es, die Vernetzung von Experten zu spezifischen Themen bzw. Kompetenzen zu för- dern und die Zusammenarbeit für die Problemlösung, zu erleichtern. Eine Voraussetzung für die Expertenvernetzung ist dabei, Transparenz über die Kompetenz der Mitarbeiter zu schaffen. So kann für die Problemlösung ein optimal geeignetes Problemlö- Überbetonung der Einheitskultur und Binnenorientierung Kulturelle Diversität Mythen, Traditionen und Groupthink Rollenzwang Audience learning Superstitious learning Learning under Ambiguity, Realitäts- und Aufklärungsdoktrinen Politisch- kulturelle Wissens- barrieren Vertikale, horizontale, laterale Informationsfilter Spezialisierung und Zentralisierung Machtverteilung und Partizipationsregeln Kooperationskonflikte Defensive Routinen Wahrnehmungs-, Verarbeitungs- und Lernkapazität Individualität und Vergangenheitsorientierung Emotional-motivationaler Aktivierungsgrad Intrapsychische Konflikte Skilled Inkompetence Strukturelle Wissens- barrieren Kollektive Wissensbarrieren Individuelle Wissensbarrieren 107 sungsteam zusammengestellt werden und es können auch für kritische Fragen die entspre- chenden Experten einfach in den Problemlöseprozess integriert werden. Daher wird für jeden Mitarbeiter ein Kompetenzprofil als sinnvoll erachtet, welches beispielsweise im Intranet oder auf ähnlichen IT-Plattformen (z.B. im Rahmen der „Gelben Seiten“) elektronisch dargestellt ist. Ziel des Kompetenzprofils ist es, die aktuellen Kompetenzen und Interessen des Experten transparent darzustellen. Insbesondere liegt dabei der Schwerpunkt auf • der dynamischen Pflege und Anpassung des Kompetenzprofils entsprechend der tat- sächlichen Aktion bzw. Interaktion eines Anwenders, z.B. in thematischen Experten- netzwerken • der kontinuierlichen Bewertung von Kompetenzen (Expertise-Level) aus unterschied- lichen Quellen, um einer 360° Beurteilung möglichst nahe zu kommen. Dabei werden arbeitsrechtliche Rahmenbedingungen (z.B. Mitarbeiterbewertung) im Besonderen berücksichtigt, um die Interessen des Anwenders zu wahren. Damit unterscheidet sich das Kompetenzprofil deutlich von statischen Skill-Beschreibungen bzw. Stellenbeschreibungen, wie sie in klassischen Skill-Management Systemen verwendet werden. Diese stellen in der Regel die vorhandenen praxisorientierten, aktuellen Kompeten- zen eines Mitarbeiters nicht dar. Der Nutzen des Kompetenzprofils für die am Problemlösungsprozess Beteiligten liegt vor al- lem: • im Finden des geeigneten Ansprechpartners zu spezifischen Themen anhand des Kompetenzprofils, • in der Nutzung des Kompetenzprofils für die personalisierte Informationsversorgung eines Anwenders (Hinweis auf neue Themen, auf Diskussionen oder ähnliche Arbei- ten) • in der automatische Zusammenführung (Vernetzung) von Experten im Sinne eines Vermittlungsdienstes (Reduzierung von Parallelentwicklungen und Doppelarbeiten) • in der mitarbeiterneutrale Auswertung von Kompetenzprofilen zur Kompetenzbewer- tung bzw. für das HR-Management. 5.3.5.2 Bedeutung des Expertiselevels für die Problemlösung Die Herangehensweise an die Lösung von Problemen ist entscheidend abhängig vom Experti- selevel des Problemlösers, bezogen auf die jeweilige Problemsituation. Nach Frankenberger /46/ führt geringe Erfahrung des Problemlösers zu verstärkter Informationssammlung, Prinzip- suche und häufigen Planungsoperationen, wohingegen hohe Erfahrung eine routinierte Bear- beitung mit zumeist zyklischem Vorgehen und wenigen Planungsschritten ermöglicht. Experten haben im Vergleich zu Novizen die Fähigkeit, Muster zu erkennen und sich zu erin- nern, d.h. ihr bereits im Gedächtnis gespeichertes Wissen entsprechen zu organisieren (Gru- ber /59/). Dies geschieht nach inhaltlicher Bedeutung, so dass es durch seine Abrufstruktur zugänglich wird. Der schnelle Zugriff auf im Wissen gespeicherte Muster erleichtert die Prob- lemwahrnehmung, d.h. Anforderungen an Problemlösung sinken. Zudem sind die von Exper- ten erstellten Problemrepräsentationen in der Regel besser als die von Novizen. 108 Damit hat der Expertiselevel entscheidenden Einfluss auf die Qualität der Problemlösung. Das von Ackermann /2/ entwickelte hierarchische Modell für die Entwicklung intellektueller Fähigkeiten unterscheidet dabei drei Expertiselevel, eine kognitive, eine assoziative und eine autonome Phase. Dreyfus/Dreyfus /43/ unterscheiden korrespondierend dazu fünf Expertise- stufen: − Novize: Zentral ist das lernen von Fakten und Mustern sowie von handlungsrelevanten Re- geln. − Fortgeschrittener: Diese sind imstande, bedeutungshaltige Muster zu erkennen und Ähn- lichkeiten wahrzunehmen. − Kompetenzstadium: Die Personen in dieser Stufe zeigen rational begründbare Verhaltens- weisen, es entstehen hierarchisch geordnete Entscheidungsprozeduren, Pläne werden er- stellt und ausgewählt. − Könner: Dieses Stadium zeichnet sich durch Anteilnahme der Personen an der Aufgabe aus. Sie sind imstande aus einem spezifischen Blickwinkel Betrachtungen durchzuführen und Nebenbedingungen für den Einsatz von Vorgehensweisen zu bedenken. Dieses „ge- wandte“ Vorgehen passiert offenbar aufgrund früherer Erinnerungen und Erfahrungen. − Experte: Auf dieser letzten Stufe sind Denk- und Wissensprozesse nicht mehr erkennbar. Das erfahrene und geübte Verständnis sagt dem Experten, was er zu tun hat. In seinem Fachgebiet handelt er engagiert, das Können des Experten ist Teil seiner Person gewor- den. Für die praktische Anwendbarkeit, eine bessere Verständlichkeit und transparente Nachvoll- ziehbarkeit werden für vorliegendes Problemlösungskonzept nur drei Level für die Expertise vorgeschlagen: interessiert, erfahren und Experte. Der Interessierte zeigt Interesse an dem entsprechenden Thema, kann hier durchaus aktiv wirken, hat aber keine tief greifende Erfahrungen auf diesem Gebiet. Es zeigt jedoch eine ge- wisse Motivation des Beteiligten, sich mit dem Thema auseinander zu setzen. Der Erfahrene beschäftigt sich in seiner direkten Arbeitswelt häufig mit dem Thema, hat be- reits Erfahrungen und Qualifikationen auf dem Gebiet gesammelt. Er ist bestimmten Problem- typen bereits mehrfach begegnet und ist in der Lage sie als Ganzes wahrzunehmen und zu entscheiden, welches eine angemessene Verhaltensweise für das jeweilige Problem ist. Der Experte beschäftigt sich ständig mit dem Thema in seiner Arbeitsumgebung, er hat bereits langjährige und tief greifende Erfahrungen und Qualifikationen auf dem Gebiet erworben. Der Erfahrungsschatz ist so groß, dass der Experte für jedes spezifische Problem intuitiv eine an- gemessene Verhaltensweise automatisch auslöst. Diese Expertisestufen sind wichtiger Bestandteil im Kompetenzprofil, welches nachfolgend in seinem Aufbau beschrieben wird. 5.3.5.3 Aufbau der Kompetenzprofile In der Fachliteratur (z.B. Green /58/, Prahalad /116/) wird die Kompetenz eines Mitarbeiters u.a. in die folgenden 4 Kompetenzarten unterteilt: 109 − Fach- oder Faktenkompetenz. Fachkompetenz dient der Erreichung von fachlichen Er- gebnissen, ohne dass Zusammenarbeit mit anderen Wissensträgern grundsätzlich notwen- dig ist. − Methodenkompetenzen. Diese Kompetenz beinhaltet die Fähigkeiten des Akteurs, seine instrumentellen Fähigkeiten zu Handlungszwecken einzusetzen. Motorische Verfahren wie auch Fähigkeiten der Informationsstrukturierung und -darstellung sind hier enthalten. − Sozialkompetenz. Sozialkompetenz dient primär dem Wissenstransfer bzw. Wissensab- gleich und der Koordination von Wissensträgern zur Zusammenarbeit auf ein gemeinsames Ziel. Sie entspricht den kommunikativen, kooperativen und kompetitiven Persönlichkeits- merkmalen des Akteurs (Teamfähigkeit, Einfühlungsvermögen und Konfliktlösungsbereit- schaft) − Persönlichkeitskompetenz oder Selbstkompetenz. Persönlichkeitskompetenz beinhaltet Fähigkeiten, welche an reflektive Persönlichkeit eines Individuums gekoppelt sind (Selbst- vertrauen, -bewusstsein und -wertgefühl). Prinzipiell ist die Darstellung der Sozialkompetenz und insbesondere der persönlichen Kompe- tenz innerhalb des Kompetenzprofils problematisch, da hier tief in den individuellen Persön- lichkeitsbereich eingegriffen wird und die notwendigen Informationen im Kontext des Problem- löseansatzes nicht zu erfassen sind. Die Sozialkompetenz wird teilweise über den indirekten Weg der „Mitarbeit in Netzwerken“ abgebildet, z.B. die Mitwirkung in Arbeitskreisen, Foren, Projekten. Entsprechend dem primären Ziel, den kompetenten Ansprechpartner zu einem bestimmten Thema zu finden, orientiert sich die Basisstruktur des Kompetenzprofils an Themengebieten. Die einzelnen Themengebiete werden dann durch die Beschreibung der Qualifikationen und Erfahrung des Mitarbeiters zu Fach- und Methodenkompetenz. Zusätzliche Beschreibungen wie Mitarbeit in Projekten/Gremien erweitern das Kompetenzprofil . Das Kompetenzprofil ist entweder direkt in der elektronischen Visitenkarte eines Mitarbeiters enthalten oder über die Visitenkarte mittels eines Links zu öffnen. Optional enthält das Kompe- tenzprofil eine Übersichtsdarstellung (Listendarstellung) der für einen Nutzer relevanten Kom- petenzgebiete mit einem zusammenfassenden Expertise-Level. Bei Auswahl eines Kompe- tenzgebiets öffnet sich dann die Detaillierung des Kompetenzprofils mit der Beschreibung der Fach- und Methodenkompetenz sowie Mitwirkung in Netzwerken (Teams/Projekten/Gremien). Das Vorschalten einer Übersichtsseite ist nur sinnvoll, wenn sehr viele Kompetenzgebiete abgebildet werden sollen. In der folgenden Abbildung 29 ist der Aufbau des Kompetenzprofils schematisch definiert und in den folgenden Kapitel sind die einzelnen Bestandteile näher beschrieben. 110 Kompetenzprofil „Mitarbeitername“ Themengebiet Fachkompetenz/Methodenkompetenz Mitwirkung in Netzwerken (Netzwerk / Teilnehmerstatus, Rolle) Qualifikation • Qualifikation 1 • Qualifikation n Teams/ Pro- jekte Projekteam xy Communities CoP xy Erfahrung • Erfahrung 1 • Erfahrung n Gremien Gremium xy Expertise-Level Selbst- einschätzung Kollegen- einschätzung Vorgabe Einschätzung d. Aktivität Experte Erfahren Themengebiet 1 Interessiert Anzahl Inhalte: Bewertungs- durchschnitt: Qualifikation Teams/ Pro- jekte Communities Erfahrung Gremien Expertise-Level Selbst- einschätzung Kollegen- einschätzung Vorgabe Einschätzung d. Aktivität Experte Erfahren Themengebiet n Interessiert Weitere Themengebiete hinzufügen ... Inhalte Namen Quelle Link Abbildung 29: Inhaltsstruktur eines Kompetenzprofils Neben der Definition der Themengebiete ist die Zuweisung bzw. Auswertung des Expertise- Levels zu einem Themengebiet die entscheidende Grundlage für das Kompetenzprofil. Wie oben beschrieben wurde der Expertise-Level für eine bessere Verständlichkeit und transpa- rente Nachvollziehbarkeit auf drei Level reduziert. Entscheidend ist hierbei, dass die Abgren- zung und Aussage der verschiedenen Level klar verständlich ist. Die Grundannahme ist hierbei u.a. das sich Erfahrene und Experten beruflich mit dem The- mengebiet beschäftigen, d.h. Qualifikationen und Erfahrungen vorweisen können. Während der Interessierte in dem Themengebiet durchaus aktiv wirken kann, aber eben keine Qualifika- tionen bzw. tief greifende Erfahrungen hat (die Felder Qualifikation und Erfahrungen sind leer). D.h. der Expertise-Level Experte kann nur dann zugeordnet werden, wenn auch die Felder Qualifikation und/oder Erfahrungen gepflegt sind. Eine Ausnahme stellt hierbei die Kollegen- einschätzung dar, die auch ohne diese Voraussetzung erfolgen kann. Die Einschätzung des Expertise-Levels erfolgt hierbei durch verschiedene Quellen. Die ver- schieden Einschätzungsquellen für den Expertise-Level werden direkt dargestellt und nicht zusammengefasst. Damit kann ein Dritter die Bewertungen entsprechend seiner Vorstellung gewichten. Vor allem dann, wenn sich durch unterschiedliche Quellen differenzierte Qualifizie- rungen des Expertise-Levels ergeben. Zum Beispiel für den Fall, dass bei der Selbsteinschät- 111 zung der Level „Interessiert“ und bei der Kollegeneinschätzung der Level „Experte“ definiert ist. Folgende Quellen für die Festlegung des Expertise-Levels für ein Themengebiet wurden iden- tifiziert: Selbsteinschätzung: Die Selbsteinschätzung wird durch den Nutzer manuell festgelegt und wird bei einem evtl. Ranking (Auswahlliste mehrer Experten zu einem Thema) am höchsten priorisiert. Kollegeneinschätzung: Prinzipiell sind zwei Verfahren zur Expertiseeinschätzung durch Kol- legen möglich. Erstens die manuelle, direkte Zuweisung im Kompetenzprofil des jeweiligen Nutzers. Diese manuelle Zuordnung eines Nutzers durch einen Kollegen, bspw. zum Experten für ein Themengebiet, hat die zweithöchste Priorität für die Beurteilung des Expertise-Levels. Die zweite Möglichkeit ist die indirekte Bewertung des Nutzers durch das Erfassen der Bewer- tung von Inhalten, Kommentaren, etc. durch andere Systemanwender. D.h. wird ein Inhalt als qualitativ hochwertig und nutzbringend für die aktuelle Arbeit bewertet, bekommt der An- sprechpartner für diesen Inhalt Expertenpunkte. Vorgabe: Dies ist eine rein optionales Qualifizierungsfeld und ermöglicht einem Dritten, z.B. einem Vorgesetzten, den Mitarbeiter als Experte für eine Kompetenzgebiet festzulegen. Ent- sprechend ist dieses Feld manuell zu pflegen bzw. aus einer bestehenden Datenquelle (falls vorhanden) zu übernehmen. 5.3.6 Gestaltungsempfehlungen für die Kommunikation und den Wissensaustausch Die Gestaltungsempfehlungen zur Optimierung der Kommunikation und des Wissensaus- tauschs können sowohl auf das Agieren des einzelnen Problemlösers als auch auf die Zu- sammenarbeit im Problemlöseteam bezogen werden. 5.3.6.1 Gestaltungsempfehlungen für das Individuum Folgende Gestaltungsempfehlungen werden für den Problemlöser als Individuum vorgeschla- gen: − Erfahrene Problemlöser bestimmen die Leistungsfähigkeit der Problemlösung entscheidend mit. Sie sind daher entsprechend zu motivieren, damit sie ihre Erfahrungen und ihr Wissen an neue oder unerfahrene Mitarbeiter weitergeben. Dies kann beispielsweise über monetä- re Anreize oder über motivierende Karrierepfade erfolgen. − Der Wissensaustausch zwischen den am Problemlösungsprozess Beteiligten ist für die Effizienz des Problemlösungsprozesses eine wichtige Voraussetzung. Der Wissensaus- tausch kann zum einen über die beschriebene formelle Organisationsstruktur (vgl. Kap. 5.2.2) erfolgen. So werden regelmäßige Treffen der Problemprozesskoordinatoren (Wis- sensaustauschgruppe) als auch termin- sowie ereignisgesteuerte Abstimmungstreffen zwi- schen dem Problemprozesskoordinator und den Problemlösern vorgeschlagen, um den Wissensfluss zu kanalisieren. Zum anderen fördert der informelle Wissensaustausch, z.B. im Rahmen von Kollegengesprächen, den schnellen und direkten Zugang zu Informationen. Auch haben die informellen Wege des Wissensaustauschs eine wichtige soziale Funktion bezüglich des Gruppenklimas. 112 − Für zufällige, informelle Gespräche sind Anreize zu schaffen. So können Kommunikations- zonen, Metaplanwände zum Aufhängen von Skizzen oder Zeichnungen die Diskussion ü- ber den Stand der Problemlösung anregen. Die Schaffung von Begegnungs- und Ge- sprächmöglichkeiten erleichtert den Mitarbeitern Anknüpfungspunkte für einen interdis- ziplinären Meinungs- und Erfahrungsaustausch über Fachgrenzen und Hierarchien hinweg zu bieten. Dazu gehören beispielsweise Sitzecken, gemeinsame Kaffeeküchen oder Markt- plätze zum informellen Treffen (Bismark/Held /13/). Auf organisatorischer Ebene sollte ge- zielt eine Kommunikationskultur mit Raum und Zeit für spontane Gespräche geschaffen werden. Bei Kommunikationsschwierigkeiten sind Schulungen und Trainings durch externe Berater zu empfehlen, um die individuelle Entwicklung der Kommunikationsfähigkeit gezielt zu fördern. − Der Wissenstransfer zwischen Erfahrenen und Unerfahrenen muss gefördert werden. Dazu können Konzepte wie das Mentor-Konzept oder das Patenprinzip eingesetzt werden. Der Wissenstransfer findet dabei durch die gemeinsame Arbeit an Problemstellungen statt. Der allgemeine Zugang zu Experten als „Auskunftsstelle“ sollte allerdings so weit wie möglich durch I&K Medien, wie beispielsweise das beschriebene elektronische Kompetenzprofil un- terstützt werden, um die Experten zu entlasten. Da durch direkte, informelle Kommunikation fast 30% der wichtigen Informationen ungeplant übertragen werden Frankenberger /46/, wird deutlich, dass die Kommunikation mit Kollegen durch Informationssysteme nicht er- setzt sondern allenfalls sinnvoll ergänzt werden können. − Die Problemlösungskompetenz hat ebenfalls großen Einfluss auf den Wissensaustausch. Kompetente Problemlöser werden entsprechend häufiger in wichtigen Situationen zu Rate gezogen. Kompetenz ist zudem die Voraussetzung, um in neuen Problemsituationen die entsprechenden Problemlösestrategien situationsgemäß anzupassen. Daher ist es wichtig, die Problemlöser darauf zu trainieren, ihr Wissen anzupassen. Dies kann beispielsweise über Personalentwicklungsmaßnahmen wie Job-Rotation unterstützt werden. Die Problem- lösekompetenz kann beispielsweise auch durch den Einsatz in thematisch unterschiedli- chen Projekten gefördert werden, welche neue Sichtweisen erfordern. Das Erlebnis der Unerfahrenheit sensibilisiert neu für die eigene Wissensdomäne und fördert das Verständ- nis für den Wissenstransfer. Zudem können „Querdenker“ mit anderem Hintergrund das kreative Klima in einem Problemlösungsteam verbessern. − Im Qualitätsanspruch des einzelnen Problemlösers zeigt sich die Güte der von ihm gestal- teten Problemlösung, die er akzeptieren kann und mit der er sich identifizieren kann. Der Qualitätsanspruch wird damit zum Antrieb für zusätzliche Anstrengungen, um die Problem- lösequalität sicher zu stellen. Der individuelle Qualitätsanspruch muss als Teil einer allge- meinen Motivation aufgefasst werden (Warschat et al. /168/). Dazu muss die Führung ein adäquates Qualitätsbewusstsein vermitteln. Zudem müssen Möglichkeiten für die Problem- löser geschaffen werden, eine entsprechende Rückmeldung zu erhalten, d.h. die umge- setzte Problemlösung in der Praxis mit ihren Vor- und Nachteilen zu erleben. Auch durch den Einsatz von Qualitätsmanagementmethoden kann ein Qualitätsbewusstsein vermittelt werden. − Die Kommunikation und der Austausch von Wissen kann zusätzlich durch eine transparen- te Darstellung der Gesamtsituation und Ziele der Problemlösung unterstützt werden. Denn eine derartige Transparenz sensibilisiert für Schnittstellen und reduziert bereichszentriertes Denken und Overengineerring (Bullinger et al. /18/). 113 5.3.6.2 Gestaltungsempfehlungen für das Team Folgende Gestaltungsempfehlungen werden für das Problemlösungsteam vorgeschlagen: − Da komplexe, wissensintensive Probleme unter kooperativen Bedingungen wesentlich ef- fektiver bearbeitet werden, sind kooperative Arbeitsbedingungen zu gewährleisten (Wet- zel /174/). Zur Förderung der Kooperation im Problemlöseteam empfiehlt sich, allen Team- mitgliedern die Grundregeln der Kommunikation und Konfliktlösestrategien als wesentliche Bestandteile einer Teamfähigkeit zu vermitteln. − Damit Defizite der mit Führungsaufgaben am Problemlösungsprozess betrauten Personen (z.B. Problemmanager, Problemprozesskoordinator) vermieden werden können, ist es empfehlenswert, Weiterbildungen zur Steigerung der allgemeinen Problemlösungskompe- tenz, wie beispielsweise Konfliktmanagement oder Führungsweiterbildungen, durchzufüh- ren. Darüber hinaus können Schulungen in Moderationstechniken oder Methoden zur Prob- lemlösung sinnvolle Maßnahmen darstellen. Wichtig ist auch, dass die mit Führungsaufga- ben betrauten Personen zu den Problemlösern Kontakt halten, um das Entstehen informel- ler Hierarchien zu vermeiden und den Stand der Problemlösung zu verfolgen und gegebe- nenfalls Terminpläne anzupassen. − Die konkrete Gestaltung von Problemlöseprozessen wird in erheblichem Maße von kulturel- len Faktoren beeinflusst (Dörner et al. /42/). So trägt ein Klima, welches die Bereitschaft zur Übernahme von Verantwortung im Sinne einer Fehlerkultur fördert, zur Problemlösung bei. Nach Untersuchungen (Frankenberger /46/) ist in 20% der kritischen Situationen mit positi- vem Ausgang ein gutes Gruppenklima die Ursache, bei erfolgreichen Lösungssuchen war die Einflussstärke des Klimas rund 75%. Dies bedeutet, dass bei der Auswahl der Mitglie- der des Problemlösungsteams neben den technischen Fähigkeiten verstärkt die sozialen Fähigkeiten wie Kooperation, Integration, Sensibilität im Sinne einer Teamfähigkeit zu be- rücksichtigen sind. Das Klima kann dabei durch gemeinsame Aktivitäten, Anreizsysteme, interdisziplinäre Gesprächsforen sowie geeignete Freiräume gefördert werden. − Gerade die Kommunikation mit Kollegen im Rahmen von Konsultationen weist eine hohe Erfolgsquote auf. In rund 70% aller Konsultationen ist das benötigte Wissen beim Angefrag- ten verfügbar. Eine wichtige Voraussetzung dazu ist, dass die richtigen Kollegen gefragt werden. Dazu ist soziales Wissen notwendig, das der Problemlöser erst nach einiger Zeit im Unternehmen erlangen kann. Die Informationsverfügbarkeit wird zu über 40% über die Erfahrung der am Problemlöseprozess Beteiligten sichergestellt. Damit hängt die Effektivi- tät des Problemlöseprozesses wesentlich davon ab, wie gut diese Wissensbestände zu- gänglich sind. Entsprechend sind informelle Gespräche durch Arbeitsteilung, räumliche Nä- he, ein gutes Klima und eine entsprechende Teamorganisation zu fördern. Da soziales Wissen Voraussetzung ist, um den richtigen Kollegen zu konsultieren ist es sinnvoll neuen Mitarbeitern einen erfahrenen Mentor zuzuweisen, der die richtigen Experten empfehlen kann. − Letztlich ist es sinnvoll insbesondere bei der verteilten, kooperativen Problemlösung den Einsatz unterstützender Informations- und Kommunikationstechnologien zu fördern. Teams, die trotz räumlicher Trennung an einer Problemlösung arbeiten, sind auf einen ganzheitli- chen Medienpool angewiesen. Da sie generell eine hohe Bereitschaft haben, innovative Medien zu nutzen, sollten ihnen diese Medien unbedingt zur Verfügung stehen. Die Nut- zung sollte zudem durch zusätzliche unternehmenspolitische Maßnahmen gefördert wer- den. 114 5.4 Gestaltungselement „Wissensintegration und Wissensgenerierung“ 5.4.1 Wissens- und Lernprozesse im Problemlösungsprozess 5.4.1.1 Organisation von Wissen im Problemlösungsprozess Insbesondere für die untersuchte Klasse der innovativen, wissensintensiven Problemstellun- gen spielt der menschliche Problemlöser eine entscheidende Rolle, denn er kann dabei nicht von einem Decision-Support-System oder einem Workflow-System unterstützt werden. Der Mensch als Problemlöser steuert sein Verhalten im Problemlösungsprozess mittels wis- sens- und informationsverarbeitender Prozesse (Kirsch /83/, Landauer /93/). Zur Systematisie- rung wissensverarbeitender Aktivitäten im Problemlösungsprozess ist es daher zweckmäßig, das bei Problemlösungsprozessen auftretende Verhalten der Wissensverarbeitung und - entwicklung zu gliedern. In Anlehnung an das von Landauer beschriebene Informationsverhalten (Landauer /93/) sowie an die von Probst/ Gilbert et al. /118/ beschriebenen Kernprozesse des Wissensmanagements werden folgende sechs wissensverarbeitende Aktivitäten für den Problemlösungsprozess de- finiert:  Ermittlung des Wissensbedarfs  Wissensbeschaffung  Wissensaufbereitung  Wissensgenerierung  Wissensabgabe  Wissensspeicherung. Eine Gegenüberstellung von Wissensaktivitäten und Problemlösungsphasen macht die Wis- sensprozesse deutlich, die in unterschiedlichen Phasen des Problemlösungsprozesses von besonderer Bedeutung sind. Phase 1: Problemerfassung Ermittlung des Wissensbedarfs Phase 2: Lösungssuche Wissensbeschaffung, Wissensspeicherung Phase 3: Situationsanalyse Wissensbeschaffung, Wissensaufbereitung, Wissensspeicherung Phase 4: Lösungsanpassung und -entwicklung Wissensaufbereitung, Wissensgenerierung, Wissensabgabe, Wissensspeicherung Phase 5: Lösungsverifizierung und Auswahl Wissensaufbereitung, Wissensabgabe Wissensspeicherung 115 Phase 6: Lösungsumsetzung und -evaluation Wissensaufbereitung, Wissensabgabe Wissensspeicherung Phase 7: Evaluation Wissensaufbereitung, Wissensabgabe Wissensspeicherung Tabelle 11: Wissensaktivitäten in den Problemlösephasen Zur Ausführung der Wissensaktivitäten und zur Übermittlung des Wissens stehen dem Prob- lemlöser als Individuum im Rahmen der Betrachtung des Problemlösungsprozesses als sozio- technisches System vier grundlegende wissensorientierte Relationen zur Verfügung. Es han- delt sich dabei um den Prozess  der Dokumentation  der Information  des Datentransfers  der Kommunikation Als Basis für alle nachfolgenden Prozesse dient hierbei der Prozess der Dokumentation, in der das Wissen von der Person gelöst und entsprechend aufbereitet wird, um es in schriftli- cher bzw. elektronischer Form speichern zu können. Diese Dokumentation soll „vor allem empfängerorientiert erfolgen“. Damit wird verstanden, dass bei der Dokumentation das Kon- textwissen des Empfängers berücksichtig werden muss. Der Empfänger ist in diesem Fall die- jenige Person, welche in der (nahen oder fernen) Zukunft auf die dokumentierten Daten zu- greift. Mit Kontextwissen des Empfängers ist zu verstehen, welchen Bedarf der Empfänger hat und über welche Vorkenntnisse dieser verfügt. Bezogen auf die Lösung von Problemen be- deutet dies, dass die Dokumentation der Problemlösungen stets vollständig und gewissenhaft durchgeführt werden muss. Das System wiederum muss das dokumentierte Wissen, also die Daten, dann problemspezifisch und problemrelevant zur Verfügung stellen, also die richtigen Daten zur richtigen Zeit der richtigen Person anbieten. Dabei kommt den Medien der Informa- tions- und Kommunikationstechnologie eine tragende Rolle zu. So kann das Wissen der Prob- lemlöser sowie die dokumentierte Problemlösung einer beliebigen Anzahl von Mitarbeitern einfach zur Verfügung gestellt werden. Erfahrene Experten werden von häufigen Anfragen entlastet. Jedoch ist zu beachten, dass explizites Wissen leichter Problemlöser-unabhängig kodifiziert werden kann als implizites Wissen oder Erfahrungswissen. Der Informationsprozess umfasst den Prozess der Wissensgewinnung aus Daten. Diese Daten werden i.d.R. von einer Maschine zum Menschen übertragen, da es sich ansonsten um einen Kommunikationsprozess handelt. Der Mensch versucht, die von der Maschine bereitge- stellten Daten zu interpretieren, um sein Wissen über die darin beschriebenen Sachverhalte zu erhöhen. Der Gestaltung der Schnittstelle zwischen Mensch und Maschine kommt dabei eine besondere Bedeutung zu, da durch die Bedienerfreundlichkeit der Maschine der Informa- tionsprozess maßgeblich beeinflusst wird. Der Prozess des Datentransfers geschieht auf der rein technischen Ebene. Hierunter wird der tatsächliche Datentransfer verstanden, also das Übermitteln von Daten zwischen ver- schiedenen technischen Systemen. Die vorangehenden Prozesse beschreiben den kodifizierten Wissenstransfer. Der Kommuni- kationsprozess hingegen geschieht zwischen Menschen, also auf der sozialen Ebene (vgl. dazu auch Kap. 5.3.2). Kommunikationsfähigkeit ist die Grundlage für kollektives Handeln. Im 116 Kommunikationsprozess werden Signale vom Sender kodiert und versandt, welche der Emp- fänger empfängt und entschlüsselt. Die Aufnahmefähigkeit beziehungsweise das Verständnis des Empfängers wird maßgeblich von zwei Parametern bestimmt, nämlich was der Empfänger aufnehmen kann (Können) und was er aufzunehmen bereit ist (Wollen). Abbildung 30: Transfermatrix von Wissen nach Hartlieb /63/ Diese Prozesse gilt es bei der informationstechnologischen Umsetzung des Problemlösungs- konzepts in einen Problemlösungsassistenten abzubilden und zu unterstützen. 5.4.1.2 Problemlösungsprozess als Lernprozess Die Bewältigung komplexer Probleme ist gleichzeitig ein Lernprozess, bei dem das Wissen über die Probleme und Lösungen im Laufe der Zeit zunimmt und damit einen großen Beitrag zum Kompetenzaufbau leistet (Thomke/Fujimoto /156/), nicht nur auf individueller sondern auch auf Ebene der Gesamtorganisation. Wissen und Lernen stehen dabei in einem engen Bezug zueinander. Lernen kann als das Durchlaufen eines Prozesses bezeichnet werden, durch den – implizit oder explizit – das Wissen bereichert wird. Ein Lernprozess kann damit als ein Wissenserzeu- gungsprozess betrachtet werden. Lernen im Problemlösungsprozess kann folgerichtig be- schrieben werden als das Einsetzen von verfügbaren Problemlösungswissen, um das Wissen besser für die Ausführung der Problemlöseschritte die sich mit der Zeit verändern, anzupas- sen. Während der Lösung von Problemen findet das Lernen von Individuen in einer zirkulären Ver- flechtung von vier Elementen statt: Wahrnehmung der Realität, Analyse und Reflexion des Erfahrenen, Entwicklung von Handlungskonzepten und Testen von Handlungskonzepten. Dieser Zyklus ist ein permanent laufender Prozess der Bewusstseinsbildung von Individuen (Schüppel /137/; Henschel /67/; Kolb /91/; Kim /82/). Das kollektive Lernen erfolgt durch die Ausbildung regelhafter Kommunikation als Folge der Interaktion von Individuen untereinander. Ziel des kollektiven Lernens im Problemlösungsprozess ist es, das individuelle Problemwissen abzuschöpfen und dieses Erfahrungswissen im organisationalen Gedächtnis vom Träger un- abhängig zu speichern. Dabei ist das kollektive Lernen mehr als die Summe der Lernprozesse der Individuen die Grundlage für die Entwicklung einer kollektiven Wissensbasis. Das Lernen im Problemlösungsprozess startet mit der Wahrnehmung des Problemkontexts. Es erfolgt zuerst eine aufgabenorientierte Strukturierung und ein Vergleich der vorliegenden Prozess der Kommunikation Prozess der Information Prozess der Dokumentation Datentransfer Individuum Maschine Individuum Maschine 117 Informationen, anschließend ein aufgabenorientiertes Suchen nach relativen Daten und Infor- mationen und letztlich eine aufgabenorientierte Anwendung von Wissen und die Übertragung von Informationen, welche schließlich zu Problemlösung führt. Das dabei durch die Lernpro- zesse gewonnene, neu entwickelte Wissen steht für die nächste Problemlösung wieder als verfügbares, persönliches Wissen zur Verfügung (vgl. Abbildung 31). Abbildung 31: Wissenserwerb durch Lernen bei der Ausführung des Problemlöseprozesses in Anlehnung an Weggemann /171/ Im Kontext der Problemlösung können drei Lerntypen differenziert werden: Das Adaptive Lernen (single-loop-learning), welches auf eine Abweichung von vorgegebenen Standards einen regulativen Reflex auslöst (Pawlowsky /111/). Die Interaktion der Problemlö- ser im Problemlösungsprozess führt zu ständigen Veränderungen der wahrgenommenen Rea- lität, da neues Wissen dazu kommt, Wissen sich in Gehalt und Qualität über den Problemlö- sungsprozess hinweg verändert. Das single-loop-learning bezeichnet die Reaktion auf diese Veränderungen mit einer Anpassung oder Korrektur des Problemlösungs- und Handlungspo- tenzials, ohne dass dabei die zugrunde liegende Wert- und Wissensbasis verändert wird. Da eine verbesserte Zielerreichung im Mittelpunkt steht, ist der Kern des sinlge-loop-learning der Optimierungs- und Effizienzgedanke, wonach bestehende Problemlösungen optimiert bzw. effizienter gestaltet werden (Agyris/Schön /3/). Bei substantiellen Veränderungen muss auch das Ziel selbst und die organisationale Wert- und Wissensbasis, d.h. die organisationalen Normen, Werte und grundlegenden Annahmen hinterfragt, neu priorisiert und gegebenenfalls verändert werden. Dabei spricht man vom um- weltorientierten Lernen (double-loop-learning). Im Mittelpunkt steht die Frage, ob die richtigen Dinge getan werden. Es kann dabei zu einem Auswechseln des Bezugsrahmens kommen, verbunden mit dem Verlernen überholter Verhaltensregeln und zur Abschaffung etablierter Regeln. Beim Problemlösungslernen (deutero-learning), als dritte Lernebene, ist die Verbesserung der Lernfähigkeit einer Organisation selbst Gegenstand des Lernprozesses. Ziel ist es, durch die Reflektion und Analyse vergangener Lernerfahrungen neue Lernstrategien zu entwickeln, so dass zukünftig sinnvoller, effektiver und nachhaltiger gelernt wird. Grundvoraussetzung ist dabei die Fähigkeit zur Selbstreflektion und Selbstkritik. Verfügbares persönliches Wissen Aufgaben- orientierte Strukturen und Vergleiche Aufgaben- orientiertes Suchen nach relativen Daten Aufgaben- orientierte Anwendung von Wissen und Informations- übertragung Kontext des Problems Problem- lösung Daten Information In fo rm at io n W iss en üb e r St ru kt u r- u n d Da te n ve rg le ich R e le va n te s W iss en sp e zif izi e re n W iss en üb e r Su ch en Au sg e w äh lte s W iss en „ lie fe rn “ En tw ick e lte s „ W iss en , e rw o rb e n a u s Le rn e n lernen lernen lernen lernen 118 5.4.2 Wissensintegration als Basis für die Wissensgenerierung Eine wesentliche Ursache für Problemsituationen sind Missverständnisse oder ungleiches Verständnis in Bezug auf den Arbeitsauftrag. So tragen beispielsweise ein unterschiedliches Verständnis über Ziele, unterschiedliche kulturelle oder fachliche Hintergründe zum Entstehen von Problemen bei. Für eine effiziente Wissensgenerierung bei der Lösung von Problemen ist daher notwendige Voraussetzung, dass die am Problemlösungsprozess Beteiligten über ein gleiches Grundver- ständnis, im Sinne eines „common sense“ verfügen. Dies kann über das Aufzeigen von Ab- hängigkeiten und logische Zusammenhänge innerhalb einer Wissensdomäne in Bezug auf die Begriffswelt erfolgen. Durch die Erstellung gemeinsamer mentaler Modelle, Metaphern und Analogien kann diese Integration von Wissen unterstützt werden. Durch die Wissensintegration erfolgt ein zumindest partieller Abgleich von heterogenem Wis- sen, der für die optimale Problemlösung notwendig ist. 5.4.2.1 Die Bedeutung von Ontologien für die Wissensintegration bei der Problemlösung Die Aufgabe der Wissensintegration kann durch die Entwicklung von Ontologien unterstützt werden (Gentsch /53/), welche eine „...formale, explizite Spezifikation einer gemeinsamen Konzeptionalisierung...“ darstellt (Gruber /60/). Eine Ontologie beschreibt die Gegenstände und Beziehungen, die für ein Individuum oder eine Gruppe begriffsbildend sind und sie legt die Struktur von Metadaten fest (Schnurr/Staab /132/). Die formelle Abbildung der Wissensdomä- nen bietet den Vorteil, dass sie maschinenverstehbar sind, d.h. als Grundlage für wissensba- sierte Systeme dienen können. Für die Lösung von wissensintensiven Problemen wurde folgendes Beziehungsdiagramm (vgl. Abbildung 32) als Metastruktur entwickelt. Abbildung 32: Beziehungsdiagramm für wissensintensive Probleme Hinter jedem Begriff liegen wiederum einzelne Wissensdomänen wie z.B. das Wissen über die am Problemlösungsprozess Beteiligten, das Wissen über Hilfsmittel und Methoden oder das Wissen über den Fachbereich. Diese wurden in einem weiteren Diskussionsprozess detailliert. Wissensintensives Problem Ursachen Problemlösungs- prozess Problemlösungs- tätigkeit Lösungswissen weist auf löst aus besteht aus benötigt Produktentwicklungs- prozess löst aus Eigenschaften hat Wissensdomäne Fachbereich Person/Org. Problemlöser/PL-Team Hilfsmittel/Methoden benötigt hat bestimmt durch bestimmt durch Lösungsstrategiebestimmt bestimmt 119 Für die Wissensdomäne Rapid Prototyping als Anwendungsfeld ist beispielhaft die entwickelte Ontologie für die Werkstoffen und Verfahren in Abbildung 33 dargestellt. Abbildung 33: Ontologie für den Bereich Werkstoffe/Verfahren im Rapid Prototyping Die Entwicklung der Ontologien dient zur Beschreibung der Abhängigkeiten der einzelnen Ob- jekte bei der Problemlösung sowie als Basis für die Wissensstruktur des zu entwickelnden Problemlösungsassistenten. Dieser Problemlösungsassistent sollte zur verteilten Problemlösung über Unternehmensgren- zen weg genutzt werden. Dabei war ein allgemein anerkanntes Verständnis der Wissensdo- mäne „Rapid Prototyping“, welches von Anwendungen und der am Problemlösungsprozess gemeinsam geteilt und wieder verwendet werden kann, sowohl für die Problembearbeitung als auch für die Suche nach bestehenden Problemlösungen anhand von Begriffen notwendig. 5.4.2.2 Wissenskarten als graphische Form der Wissensrepräsentation Damit der Problemlöser genau das Wissen zur Problemlösung zur Verfügung gestellt be- kommt, welches er benötigt, ist zur optimale Unterstützung der einzelnen Schritte bei der Lö- sung von Problemen eine genauere Betrachtung der Wissensarten im Problemlösungsprozess notwendig. Gleichzeitig muss dem Problemlöser Wissen bereit gestellt werden, welches ein effizientes Lernen entlang des Problemlösungsprozesses ermöglicht. Basierend auf der Wis- sensstruktur für die Lösung von Problemen von De Jong/Fergusson-Hessler /29/ sowie auf den Wissensarten, die im beschriebenen Lernzyklus abgebildet werden (Schüppel /137/, Werkstoffe/Verfahren Gießtechnologien Generative Fertigungsverfahren (GFV) Selective Laser Sintering (SLS) Stereolitographie (SLA) Laminated Object Manufacturing (LOM) Solid Ground Curing (SGC) Fused Deposition Modeling (FDM) Multi-Jet-Modeling (MJM) Analyseverfahren metalographic analysis micrographic analysis MaterialbehandlungWärmebehandlung Oberflächenbehandlung Werkzeugherstellung Keramische Werkstoffe Kunststoffe Polymere Elastomere Duroplaste Metalle Materialwirtschaft Supplier development Beschaffung allgemein 120 Kolb /91/, Geißler /52/) können für den Problemlösungsprozess vier unterschiedliche Wis- sensarten definiert werden: − Erfahrungswissen: Situationsbasiertes bzw. fallbezogenes Wissen erlaubt es dem Problemlöser durch selekti- ve Wahrnehmung relevante Features aus dem aktuellen Problemzustand herauszulösen und notwendiges Wissen zu ergänzen. Es kann dazu dienen eine Problemrepräsentation zu erstellen, von der aus andere Wissensarten (z.B. Konzeptwissen, Handlungswissen) aufgenommen werden können. Beispiel: Das Wissen, dass eine raue Oberfläche Friktionskräfte verursacht, welche gegen die Bewegungsrichtung wirkt. − Konzeptwissen: Konzeptwissen ist statisches Wissen über Fakten, Konzepte, Prinzipien, welche im Rah- men einer bestimmten Domäne angewendet werden bzw. zum Tragen kommen (De Jong/Fergusson-Hessler /29/). Konzeptwissen dient als zusätzliches, ergänzendes Wissen, welches der Problemlöser zum Problem hinzuzieht und welches er zur Ausführung der Lö- sung benutzt. Beispiel: Das Wissen, dass die Höhe der Friktionskraft gleich dem Produkt aus Friktionsko- effizient und der normalen Kraft ist, oder dass die Kraft gleich der Masse multipliziert mit der Geschwindigkeit ist. − Planungswissen: Strategisches, verhaltensanleitendes Wissen unterstützt den Problemlöser seinen Problem- löseprozess zu organisieren, z.B. durch die Ermittlung der Schritte, die bis zur Lösung zu durchlaufen sind. Beispiel: Strategisches Wissen betrifft das Wissen, wie die vorliegende Informationen zu organisieren und zu interpretieren sind, wie sie z.B. in einem Diagramm abbildbar sind, wie ein mechanisches System für eine Analyse aussehen muss. − Handlungswissen: Prozedurales Wissen beinhaltet Wissen über Handlungen oder Manipulationen die in einer bestimmten Wissensdomäne gültig sind. Das Handlungswissen hilft dem Problemlöser den Übergang von einem Problemzustand zum nächsten zu gestalten. Beispiel: Handlungswissen umfasst z.B. das Wissen, wie zwei interagierende mechanische Systeme identifiziert und voneinander abgegrenzt werden können. Konkrete Erfahrungen und das Testen von Handlungskonzepten bilden eine operationale Lernebene, die mit dem Erfahrungs- und Handlungswissen korrespondiert. Das Erfahrungs- und Handlungswissen versetzt einen Problemlöser in die Lage, Verhalten zu generieren, d.h. Problemlöseschritte auszuführen. Die Analyse von Erfahrungen und die Entwicklung von Handlungskonzepten bilden hingegen eine konzeptionelle Ebene, die vom Konzept- und Pla- nungswissen determiniert wird, gleichzeitig aber auch zur Entwicklung der beiden Wissensar- ten beiträgt. Beispielhaft für die Problemlösungsphase „Situationsanalyse“ werden die für den Problemlö- sungsprozess relevanten Wissensarten in Abbildung 34 dargestellt. 121 Abbildung 34: Wissensarten im Problemlösungsprozess am Beispiel der Phase „Situations- analyse“ Damit ergibt sich für die im Problemlösungsprozess abzubildenden und zu unterstützenden Wissensarten folgende Struktur (vgl. Abbildung 35): Abbildung 35: Abbildung der Wissensstruktur für die Problemlösungsphasen 5.4.3 Kollektive Wissensgenerierung Die Problemlösung ist ein kreativer Prozess, der vor allem durch Wissensentwicklung geprägt ist, d.h. ein Grossteil des zur Lösung erforderlichen Wissens wird erst während des Problem- lösungsprozesses kreativ entwickelt (z.B. Hussy /75/). Die Dauer dieser Wissensentwicklung bestimmt maßgeblich die Dauer des Problemlösungsprozesses. Zur Problemlösung bieten sich folgende Möglichkeiten (vgl. Abbildung 36):  Das Problem ist mit bestehendem individuell vorhandenem Wissen lösbar (Selbstinduktion von Wissen): Der Problemlöser verwendet sein vorhandenes Lösungswissen (z.B. durch Problemlöser Problem- lösungsteam Situationsanalyse Ermittlung Lösungsanforderungen Detailanalyse Zielformulierung Dokumentation und Verdichtung Erfahrungswissen z.B. Bereitstellung bestehender Situationsanalysen anderer Problem- lösungen als Beispiel Handlungswissen z.B. Unterstützung der Ausführung der Situations- analyse durch Formulare, Tabellen, Werkzeuge etc. Planungswissen z.B. Beschreibung der Schritte, die bei der Situationsanalyse abzuarbeiten sind Konzeptwissen z.B. Übersicht über Struktur und Aufbau der Situationsanalyse, Einbindung in Problem- lösungsprozess Beschreibung (Planungs- und Konzeptwissen) Wissen (Erfahrungswissen) Personen Werkzeuge, Methoden, Hilfsmittel (Handlungswissen) Sonstiges Problemphase 12.05.2008 - v3 Kurzbeschreibung der Phase Information zu den Prozessschritten Anleitung zum Vorgehen Beschreibung des Ziels und des Ergebnisses Leitfaden für Problemlösung Kritische Fragen (Fragenkatalog) Hinweis auf Ansprechpartner, Kontaktperson Tricks/Tipps Häufige Fehler Dokumentiertes Vorgehen zur Lösung des Problems Dokumentierte Einschätzungen, Überlegungen Dokumentierte Historie des Problems Begründung von Entscheidungen Dokumente (ausgefüllte Formulare, Checklisten, etc.) Bestehende Problemlösungen Problemlöser Problem Owner Problemprozesskoordinator Problemprozess Manager Problemlösungsteam Problemlösungszirkel Wissenstransfergruppe Formulare Checklisten Tabellen Methodenbeschreibung Datenbank (Suche) Referenzen, Verweise Links 122 die Aktivierung vorhandenen Erfahrungswissens), passt es im Zuge des Lösungsdesigns an die vorhandene Problemsituation an und wendet es über die Ausführung von Handlun- gen zur Lösung des Problems an.  Das Problem ist mit bestehendem externem Wissen lösbar (direkte Induktion von Wissen): Der Problemlöser muss sich das notwendige Lösungswissen von entsprechenden Wis- sensträgern durch Kommunikations- bzw. Informationsprozesse erst beschaffen, um das Problem lösen zu können.  Das Problem ist nur durch die Generierung von neuem Wissen lösbar (Wissensentwick- lung): Existiert kein Lösungswissen zum vorhandenen Problem, muss es neu entwickelt werden (unter umständen kann hier ein Problem auch als unlösbar abgeschlossen wer- den). Abbildung 36: Gestaltungsmöglichkeiten des Lösungsdesigns Die Neuentwicklung von Wissen ist dabei ein Prozess, in dem einzelne Wissensgebiete ver- knüpft und kombiniert werden. Die Verknüpfungen bauen hierbei nicht auf bereits erfolgten Verknüpfungen auf sondern sind neuartig. Wenn das neu entwickelte Wissen das Potenzial besitzt, ein bestehendes Problem zu lösen, so wird die Verknüpfung als kreativ verstanden. Je unterschiedlicher die Ausprägungen der Wissensebenen der am Problemlösungsprozess be- teiligten Mitarbeiter sind, desto höher ist die Wahrscheinlichkeit, dass eine der stattfindenden Verknüpfungen als kreativ zum Tragen kommt. Daher ist die kooperative Wissensentwicklung durch eine heterogene, interdisziplinäre Zusammensetzung des Problemlösungsteams aus wissensorientierter Sicht von Vorteil. Voraussetzung für die Entwicklung neuen Wissens ist dabei die Fähigkeit des Problemlösers, von ihm wahrgenommene Signale mit bestehendem Wissen so zu verknüpfen, dass aus der entstandenen Gesamtheit die Problemlösung ableitbar ist. Als Unterstützung können für die Wissensentwicklung beispielsweise Kreativitätsmethoden eingesetzt werden. Problem mit bestehendem "internen„ Wissen lösbar, z.B. durch Kombination eigener Erfahrungen Problem nur mit zu entwickelndem Wissen lösbar, z.B. durch Kompetenzaufbau Problem mit bestehendem "externem" Wissen lösbar, z.B. durch Kommunikations- oder Informationsprozess Wissensproblem tritt auf: -Wissensdefizit -Wissensbarrieren Wissensangebot Wissensbedarf zur Problemlösung Individuelles Wissen des Problemlösers Externes Wissens- angebot (Experten- netz, Internet, o.ä.) Individuelles Wissen des Problemlösers Externes Wissens- angebot (Experten- netz, Internet, o.ä.) Neu zu entwic- kelndes Wissen Problemlösung: 1. 2. 3. Abgleich 123 5.4.4 Gestaltungsempfehlungen für die Wissensintegration und die Wissensgenerie- rung − Auf Basis der Wahrnehmung eines Problems entsteht ein Wissensgebiet über das Problem (Problemwissen). Wichtig ist der Kontext in dem das Problem eingebettet ist. Erforderlich für Problemidentifikation ist dabei die entsprechende Wissensbreite und –tiefe bzgl. der re- levanten Wissensgebiete, um Anknüpfungspunkte zur Entwicklung von Problemwissen be- reit zu stellen. Als Basiswissen des Individuums kann individuelle Problemdefinition gese- hen werden. − Je nach semantischer Einbettung einer komplexen Problemsituation wird beim Individuum ein bestimmtes Vorwissen aktualisiert. Bei der Zieldefinition werden bei ausgeprägtem, zu- treffendem (Vor-)Wissen über den Realitätsbereich die kritischen Variablen leichter erkannt, was die Entwicklung und Ausarbeitung von Zielen vereinfachen kann. Dies bedeutet, dass die Problemsituation besser versteh- und steuerbar ist, wenn die Einbettung des Problems in einen semantischen Kontext, z.B. der vorliegende Prozessschritt oder das Entwicklungs- projekt, erfolgt. − Vorwissen spielt auch bei der Erstellung eines Modells der Situation eine große Rolle. Wenn ein Problem semantisch angereichert ist, und damit das Vorwissen nutzbar ist, ist dies eine günstigere Voraussetzung für die Organisation und Integration von Wissen bzw. Informationen. Mit dem Vorwissen sind Strukturierungsprinzipien gegeben, die eine sinnvol- le Ordnung der Informationen bzw. der Wissensbausteine ermöglichen, was wiederum die Modellbildung erleichtert. Allerdings besteht die Gefahr, dass eine neuartige Problemsitua- tion mit einer bekannten analogisiert wird, ohne dass dies ausreichend geprüft wird, wenn umfangreiches Wissen über den relevanten Realitätsbereich vorliegt. − Durch die Gestaltung individueller und kollektiver Lernprozesse, beispielsweise durch den Einsatz von Communities of Practice oder Wissensnetzwerken, kann die Problemlösefähig- keit von Individuen und ganzen Organisationen gesteigert werden. So initiieren und unter- stützen sie durch die ausgeprägte Interaktion und Kommunikation sowohl individuelles als auch kollektives Lernen und steigern die Qualität der Lernprozesse und Lernerfahrungen. − Voraussetzung für die Ausführung von Wissensprozessen ist eine gemeinsame Verständ- nisbasis bei den am Problemlösungsprozess beteiligten Mitarbeitern. Diese ermöglicht, dass der Empfänger aus den einzelnen Informationsbestandteilen das Wissens annähernd so rekonstruieren kann, dass es von der Bedeutung mit der übereinstimmt, die der Wis- sensträger ursprünglich hatte. Ohne diese gemeinsame Verständnisbasis kann es zu Be- deutungsverschiebungen und Fehlinterpretationen kommen. Diese lässt sich durch eine in- tensive Interaktion und Kommunikation über den gesamten Problemlösungsprozess schaf- fen. Ebenso helfen eine klare Definition der Ziele und die Erstellung eines Glossars sowie die Abbildung des betrachteten Gegenstandsbereichs über Ontologien. − Die Generierung von neuem Wissen wird insbesondere durch die Zusammenarbeit in inter- disziplinären, heterogenen Teams gefördert. Denn je mehr unterschiedliche Wissensgebie- te zur Problemlösung einfließen, desto umfangreicher ist die Wahrscheinlichkeit, dass durch die Kombination dieser Wissensgebiete neues Wissen zur Problemlösungen ent- steht. 6 Softwaretechnische Realisierung eines Problemlösungsassis- tenten Der Einsatz eines softwaregestützten Problemlösungsassistenten bietet die Möglichkeit, die entwickelte Systematik als Assistenzsystem abzubilden sowie umfangreiches Wissen struktu- riert bereitzustellen, zu verarbeiten, zu dokumentieren und die gespeicherten Problemlösun- gen für andere einfach verfügbar zu machen. Der Problemlösungsassistent unterstützt den Ingenieur bei der individuellen sowie kollektiven Abarbeitung von wissensintensiven Problemen, in dem der Ingenieur systematisch durch den Problemlöseprozess geführt und angeleitet wird. Im folgenden wird basierend auf den Anforderungen an eine informationstechnologische Un- terstützung die gewählte Hard- und Softwareplattform sowie die grundlegende Architektur des Problemlösungsassistenten beschrieben. Im Anschluss erfolgt die Spezifikation des Funkti- onsprototyps. 6.1 Ableitung von Anforderungen an eine informationstechnologische Unterstützung 6.1.1 Funktionale Anforderungen zur Abbildung des Problemlösungsprozesses Die Abbildung des Problemlösungsprozesses im Problemlösungsassistenten umfasst folgende allgemeine funktionale Anforderungen: Der Problemlösungsprozess soll graphisch visualisiert werden, wobei die aktuellen und bereits durch- laufenden Phasen optisch besonders markiert werden sollen. Der Problemlösungsprozess kann an jeder Stelle ausgesetzt und später fortgeführt werden. Der Problemlösungsprozess soll im Ganzen abgebrochen werden können. Der Problemlösungsprozess soll Pflichtteilfelder besitzen. Der Problemlösungsprozess soll als Reifegradmodell umgesetzt sein. Jeder Teilprozess des PLP soll durch den Nutzer bewertet werden können. Der abgeschlossene PLP muss in seinem Resultat durch einen Experten bestätigt werden. Weitere detaillierte Anforderungen beziehen sich auf die einzelnen Phasen im Problemlö- sungsprozess und können dem Anhang entnommen werden. 6.1.2 Funktionale Anforderungen zur Unterstützung der Kommunikation und des Wis- sensaustauschs Die Anforderungen hinsichtlich der Unterstützung der Kommunikation und des Wissensaus- tauschs sind wie folgt: 125 Dem Problemlöser sollten Kontakte zu Experten angeboten werden, die in der Vergangenheit ähnli- che Situationen gemeistert haben oder fachlich kompetent erscheinen. Eine einfache Kontaktaufnahme und Vernetzung von Experten durch Kompetenzprofile sollte bereit- gestellt werden. Die Angabe des Expertiselevels ist wichtig, um die Besetzung des Problemlösungsteams optimal zu gestalten. Der Nutzer benötigt die Möglichkeit, synchron oder asynchron mit den am Problemlösungsprozess beteiligten Personen zu kommunizieren. Der Problemlöser sollte die Möglichkeit haben, die einzelnen Phasen zu bewerten und Beurteilungen abzugeben. Im Problemlöseticket sollte zu jeder Phase der Bearbeiter angegeben werden, um eine direkte Kon- taktaufnahme zu erleichtern. Die Diskussion und der Austausch zu Problemlösungen sollte z.B. durch Kommentarfunktionalitäten oder Foren ermöglicht werden. 6.1.3 Funktionale Anforderungen zur Unterstützung der Wissensintegration und - entwicklung Die Wissensintegration und –entwicklung sollte im Problemlösungsassistent durch folgende Anforderungen berücksichtigt werden: Für jede Phase des Problemlösungsprozesses soll optional eine ausführliche Beschreibung und Hil- festellung angeboten werden. Dem Problemlöser soll in jeder Phase Wissen entsprechend der Wissensarten im Problemlösungs- prozess bereitgestellt werden. Es sollen Checklisten, Methoden, Werkzeuge, Anleitungen zur Bearbeitung des Problems geliefert werden. Jeder Teilprozess soll ausführlich kommentiert (Hilfetexte, Beispiele, Anleitungen) werden, um dem Problemlöser strukturierte Hilfestellung zu bieten. Der Problemlöser benötigt die Möglichkeit, die Erfahrungen und Ergebnisse entsprechend zu doku- mentieren. Ergänzende Informationen und Dokumente sollten integrierbar sein (Upload, Link). 6.2 Architektur des Systems Eine IT-Unterstützung ermöglicht die Beschleunigung der Abwicklung verteilter Problemlö- sungsprozesse. Deshalb wurde im Rahmen dieser Arbeit ein Softwarewerkzeug als flexibles Modul entwickelt, welches zum einen die Lösungs(wieder-)findung als auch die verteilte Ent- wicklung neuer Problemlösungen unterstützt. Das Modul des Problemlösungsassistenten wird in ein bereits bestehendes Gesamtsystem integriert. Als Framework zur technischen Realisierung wird das Produkt ProductivityNet V3.6 der Communardo Software GmbH verwendet. Dieses wird auf die speziellen Anforderungen hin angepasst (Customizing) bzw. erweitert (Implementierung). ProductivityNet ermöglicht mit seinem modularen Portalkonzept das integrierte Betreiben mehrerer Sub-Portale in einer An- wendung. Abbildung 37 verdeutlicht diesen Zusammenhang. Die einzelnen Wissensnetzwerke sind in einer Plattform integriert. Der Problemlösungsassistent stellt dabei ein Modul dar, auf 126 das von einem Wissens- und Kompetenznetzwerk heraus optional zugegriffen werden kann und spezielle Funktionen zur Verfügung stellt. Die objektorientierten Prinzipien Vererbung und Kapselung sichern die Übersichtlichkeit, die einfache Pflege und die Skalierbarkeit des Produktes. Die Veränderung oder Erweiterung von Funktionen oder Modulen bedarf nur der einmaligen Modifikation dieser, um im gesamten Produkt verfügbar zu sein /73/. Architektur der Basissoftware In Abbildung 37 ist die Architektur der Basissoftware als Schalendiagramm dargestellt. Es ist erkennbar, dass der Anwendungskern durch zusätzliche, optionale Module funktional erweitert werden kann. In der Praxis kann dies in Form von Leistungspaketen wahrgenommen werden. Abbildung 37 Architektur – Schalendiagramm Der Problemlösungsassistent ist in dieser Sicht als Modul einzuordnen. Die Vorteile dieser Struktur liegen in der nachträglichen Gestaltung des Funktionsumfanges ohne die Basisfunkti- onalitäten oder die Leistungsfähigkeit der anderen Module zu beeinträchtigen. Allgemeiner Aufbau des Moduls Die Integration neuer Komponenten in eine Basissoftware erfolgt generell als Modul. Dies be- deutet, dass Hier wird zwischen Plugin oder Applikation unterschieden. Die Umsetzung des Problemlösungsassistenten erfolgt im folgenden über die Schnittstellen der Applikation. Die Applikation besteht aus den drei Elementen Model, View und Controller (MVC). Die drei Elemente des MVC sind nicht allein funktionsfähig, sondern bauen auf einander auf. Wichtig bei der Umsetzung ist, das das Model unabhängig von den andern Elementen bleibt, damit es frei von den anderen Schichten entworfen und realisiert werden kann. Das Modul des Problemlösungsassistenten wird in die Basissoftware als Applikation integriert. Aus der bestehenden Architektur gehen deshalb nachfolgende Eigenschaften hervor: Der Problemlösungsassistent besteht aus mindestens einem Model, einem Controller und mindes- tens zwei Views (jeweils für die Datenein- und Datenausgabe). Bestandteile des Moduls Der Controller lädt das Model aus der Datenbank, dessen Eigenschaften abhängig von den Aktivitäten des Anwenders modifiziert werden können. Der Controller übersendet die Daten an die View. Zu jeder View ist mindestens ein Template zugehörig, das die konkrete Ausgabe- formatierung beschreibt. Anwendungs- kern Modul PLA Modul Modul Modul Modul Modul Modul 127 php Objekte in PHP tmp Templates html Hypertextdokumente Model ViewController htmlsendet Ereignisse wertet aus läd Model und steuert desen Manipulations- methoden an liefert Daten php php php tmp erzeugen Ausgabe Abbildung 38: Beziehung zwischen den Elementen im MVC Die Unterteilung in MVC bietet erhebliche Vorteile für die Verarbeitung der konkreten Anforde- rungen, da die Ausgabe oder Datenverarbeitung bzw. die Datensteuerung vom Model losge- löst betrachtet werden kann. Eine Modifikation der View ist somit einfach über Templates mög- lich. Separat von den anderen Bestandteilen der Anwendung kann auch die Umstellung der Datenbank erfolgen ohne das es Beeinträchtigungen in der Leistungsfähigkeit gibt. Integration des Moduls Die Einführung des Problemlösungsassistenten als Modul, auf Basis der Schnittstellen einer Applikation, stellt für das Produkt eine sichere Herangehensweise zur Weiterentwicklung des Funktionsumfanges dar, da die Leistungsfähigkeit anderer Module durch die Integration nicht beeinträchtigt wird. Die scharfe Abgrenzung der Module bietet einen Schutz gegen mögliche Schäden fehlerhafter Lösungsansätze. 6.3 Verwendete Hard- und Softwareplattform Der Problemlösungsassistent wurde als ein Modul in die Community-Software ProductivityNet der Communardo Software GmbH über Schnittstellen integriert. Die Implementierung erfolgte in PHP. Auf die Datenbank wird über ein Abstraktionsinterface zugegriffen werden. Zur Realisierung des Problemlösungsassistenten wurde eine Client-/Serverarchitektur auf TCP/IP– Basis gewählt. Ein Web-Client bietet den Vorteil, dass im Rahmen der verteilten Problemlösung über Systemgrenzen hinweg auf die Problemlösedatenbank zugegriffen wer- den kann. Für die verteilte Problemlösung war zudem die Verschlüsselung der Kommunikation für das Extranet von Bedeutung. Server − DB-Schnittstellen für Oracle, MS SQL − OS: Linux, Windows, Sun Solaris − Apache Web-Server 1.3.26 inkl. PHP 4.3 Client − Microsoft Internet Explorer 5.x, 6.x, Netscape 6.x, 7.x Bei der Auswahl der Hard- und Softwareplattform wurden folgende Qualitäts-Kriterien ange- setzt (vgl. Tabelle 12): 128 Qualitätsbewertung Qualitätskriterium sehr gut gut normal Funktionalität X Zuverlässigkeit X Benutzbarkeit X Effizienz X Änderbarkeit X Robustheit X Wartbarkeit X Übertragbarkeit X Skalierbarkeit X Geschwindigkeit X Integrierbarkeit X Vernetzung X Betreuung des Anwenders X Dokumentation X Tabelle 12: Angesetzte Qualitätskriterien für den Problemlösungsassistenten 6.4 Spezifikation des Problemlösungsassistenten In der Realisierung des Problemlösungsassistenten wurde der Schwerpunkt auf die Unterstüt- zung des Problemlösungsprozesses gelegt und die flexible Anpassung des Prozesses in der Priorität herunter genommen. Nachfolgend werden die Komponenten des Problemlösungsas- sistenten, die Problemdatenbank, das Problemticket und der Problemwizard sowie das hinter dem Problemlösungsassistenten liegende Datenmodell und das Rollenkonzept, beschrieben (vgl. Abbildung 39). Abbildung 39: Komponenten des Problemlösungsassistenten 6.4.1 Problemdatenbank Im Problemlösungsassistenten gibt es einem Menüpunkt „Problemdatenbank“. Dort gibt es eine Übersicht über neue Einträge, Meistgelesene Einträge analog zur Homepage des jeweili- gen Wissensnetzwerks. Problem- datenbank ProblemticketProblemticket-Wizard Speicherung des Problemlösetickets in der Problemlösungsdatenbank Anfrage an Datenbank nach bestehenden Lösungen Anlegen und Bearbeitung eines Problems 129 Darunter kann eine beliebige Problem-Themenstruktur in Form von Unterkategorien angelegt werden. Dazu wird ein „neuer Menüpunkt“ vom Typ „Problemlösung“ angelegt. In diesen Unter-Ordnern befinden sich die Problemtickets. Die Liste der Problemtickets ist nach folgenden Kriterien sortier- und gruppierbar: − Problemkoordinator − Phase − Status (offen oder erledigt) − Sowie alle Standardsortier- und Gruppierattribute − Thema/Fachbereich Die Suche über die Problemtickets mit den jeweiligen Datei-Anhängen ist über die „Schnellsu- che“ durch Produktfunktionalität sichergestellt. Abbildung 40: Problemdatenbank 6.4.2 Problemticket Das Problemticket kann im Bereich der Problemdatenbank angelegt werden. Das Problemti- cket beinhaltet die im Konzept beschriebenen ersten 6 Phasen (Problemerfassung, Lösungs- suche, Situationsanalyse, Lösungsentwicklung, Lösungsbewertung, Lösungsumsetzung) die abgearbeitet werden müssen. Die systematische und strukturierte Führung des Experten durch den Problemlösungsprozess erfolgt über Fragen. 130 Nur wenn alle Pflichtfelder gefüllt sind, kann man über „Weiter“ in die nächste Phase gelan- gen. Der Problemlöser sieht jeweils nur den Reiter der Phase, in der er sich befindet, dies gibt ihm Auskunft darüber, wie weit er mit der aktuellen Problemlösung bereits fortgeschritten ist. Zu jeder Phase gibt es eine ausführliche Anleitung und Beschreibung über Ziele der Phase, das Vorgehen, die einzelnen Schritte dazu sowie über das erwartete Ergebnis. Es besteht jederzeit die Möglichkeit den aktuellen Stand eines Problemtickets zu speichern und zu einem späteren Zeitpunkt die Bearbeitung wieder fortzusetzen. Weiter sind „Archivie- ren“, „Löschen“ und „Rechte ändern“ Standardfunktionalitäten, die auch beim Problemticket verfügbar sind. In der detaillierten Sicht des Problemtickets sind alle Daten zusammengefasst dargestellt. Weiterhin gibt es eine grafische Anzeige über den erreichten Prozessschritt. 6.4.3 Problemwizard Eine weitere Komponente des Problemlösungsassistenten stellt der Problemwizard dar. Er soll den Anwender unterstützen, sein zuletzt bearbeitetes Problemticket wieder zu finden und wei- ter zu bearbeiten. Die Funktionen des Problemwizard sind wie folgt: − Ticket in den Wizard einfügen (automatisch beim bearbeiten eines Tickets) − Problemticket aus Wizard entfernen − Gehe zum Problemticket − Problemticket anlegen − Verknüpfung einfügen Das Datenmodell, welches dem Problemlösungsassistenten zugrunde liegt, kann im Anhang in Kapitel 10.5 eingesehen werden. 6.4.4 Rollenkonzept 6.4.4.1 Rollen Die Im Problemlösungsassistent verwendeten Rechterollen sind in Tabelle 13 dargestellt: Rechterolle Beschreibung Einzelrechte Lesen Nutzer / Nutzgruppe können lesend auf die Anwendung zugreifen. Menüpunkt lesen Inhalte lesen Mitwirken Nutzer / Nutzgruppe können kommentieren etc. Benutzerseite (VCard) lesen Kommentieren Schreiben Nutzer / Nutzgruppe können Inhalte einstellen. Inhalte anlegen Inhalte ändern Inhalte löschen Verwalten Nutzer / Nutzgruppe können die Navigations- strukturen ändern usw. Menüpunkt anlegen Menüpunkt ändern Menüpunkt löschen Rechte ändern Ansprechpartner ändern Tabelle 13: Rechterollen im Problemlösungsassistent 131 Wie im Konzept beschrieben, beinhaltet der Problemlösungsassistent folgende Basis- Nutzerrollen: Problem Owner Ersteller Problemmanager Rechte Rolle Problemkoordinator Auswahl in Phase 2 Problemlöser Auswahl in der jeweiligen Phase Tabelle 14: Nutzerrollen im Problemlösungsassistent Die Rolle Problemmanager muss über die Rechteeinstellungen zugewiesen werden. In der Phase 2 gibt es zur Zuordnung des Koordinators eine Auswahl analog zu Ansprech- partner. Die ausgewählte Person wird automatisch zum neuen Ansprechpartner. In den Phasen Situationsanalyse, Lösungsentwicklung, Bewertung und Umsetzung gibt es eine Auswahl analog zur Auswahl des Ansprechpartners. Mit dem Unterschied, dass Mehr- fachauswahl zugelassen ist. Die zugewiesenen Personen haben dann die Rolle Problemlöser für diese Phase. 6.4.4.2 Berechtigungen Folgende Berechtigungen ergeben sich daraus: Funktion Problem Owner (erstellen) Problem- manager Problem- koordinator Problemlöser lesen X X X X Initialisierung anlegen X X bearbeiten X X Lösungssuche bearbeiten X X Koordinator zuweisen X Situationsanalyse Problemlöser 2 bearbeiten X X X Problemlöser zuweisen X X Lösungsentwicklung Problemlöser 3 bearbeiten X X X Problemlöser zuweisen X X Lösungsbewertung Problemlöser 4 bearbeiten X X X Problemlöser zuweisen X X Lösungsumsetzung Problemlöser 5 bearbeiten X X X Problemlöser zuweisen X X Tabelle 15 Berechtigungen im Problemlösungsassistenten 6.4.4.3 Benachrichtigungen Der Problemlösungsassistent berücksichtigt die Abstimmungsprozesse zwischen den am Problemlösungsprozess beteiligten Personen durch Benachrichtigungen: 132 Problemmanager: − bei neuem Ticket, wenn die Phase 2 erreicht wurde − Information entweder nach jeder Phase aber mindestens nach Fertigstellung der Phase Lösungsbewertung, da der Problemmanager letztendlich die Freigabe bzw. das Budget verantworten muss. Problemkoordinator − bei jedem Speichern, wenn die erreichte Phase höher ist, als vor der Speicherung des Problemtickets. Problemlöser: − Information durch den Problemkoordinator, „Auftrag“ für die entsprechende Phase. 7 Der Problemlösungsassistent in der praktischen Anwendung bei einem mittelständischen Automobilzulieferer 7.1 Ausgangssituation und Zielstellung Die Anwendung der Systematik sowie des Problemlösungsassistenten in der Praxis wird dar- gestellt am Beispiel eines international tätigen Anbieter von Engineering Dienstleistungen, der u.a. die Automobilindustrie sowie Weiße-Ware Hersteller bedient. Das Unternehmen beschäftigt ca. 330 Mitarbeiter in zahlreichen Standorten im In- und Aus- land. Der Leistungsumfang liegt in der Systementwicklung von der Idee bis zur Serie sowie in der durchgängigen Prozesskette im gesamten Entwicklungsablauf bis hin zur Herstellung von Modellen, Prototypen und Kleinserien. Der Wettbewerb insbesondere im Automobilsektor ist sehr intensiv und dynamisch, mit verur- sacht durch die wachsenden Märkte in China und Ost-Europa. Zudem verlangt der Kunde nach einer Steigerung der Effizienz bei der Produktentwicklung sowie ein kollaboratives Pro- jektmanagement in der Supply Chain. Das Unternehmen steht daher vor der Herausforderung, sich als innovatives Full-Service Engineering Unternehmen auch zum Global Player zu entwi- ckeln. Derzeit wird bereits eine Vielzahl der Aufträge in überregionalen bzw. internationalen Koopera- tionen abgewickelt. Im Vordergrund steht dabei die Erweiterung des Leistungsspektrums für ganzheitliche Kundenlösungen sowie die Möglichkeit, flexibel und dynamisch auf Kapazitäts- engpässe reagieren zu können. Der zentrale Stellhebel zur Erhöhung der Innovationsfähigkeit und der Produktivität ist für das Unternehmen das Humankapital. Das Know-how und die Erfahrung der Mitarbeiter sind der Garant für anspruchsvolle Lösungen für Kunden. Das wesentliche Wissen ist dabei das tech- nische Wissen der Konstruktion und Entwicklung von Produkten und Prozessen. Eine Analyse eines typischen Entwicklungsprojekts ergab, dass teilweise ein ungleicher Infor- mations- bzw. Wissensstand zu Konflikten führte. Auch war die Anforderung an die persönli- che Problemlösungskompetenz sowie die Problemlösung im Team hoch. Als Erfolgsfaktoren für erfolgreiche Problemlösung wurden im Rahmen der Analyse folgende Aspekte genannt: − Intensiver Austausch, Kommunikation − Gemeinsame Zielfindung − Qualifikatorische Problemlösungskompetenz − Soziale Kompetenz (Beziehungsebene) − Methodeneinsatz Bereits eingesetzt wurden Methoden wie beispielsweise QFD, Nutzwertanalyse oder FMEA. Jedoch war eine zeitnahe, projektbegleitende Dokumentation von Problemen erforderlich. Die Anforderungen an eine methodische Unterstützung umfassten eine Förderung des Wissens- 134 austauschs und der Vernetzung der weltweit verteilten Experten, die Bereitstellung von Fach- wissen sowie Projekterfahrungen und Erfahrungen zu bisherigen Problemlösungen, Hilfen zu Aufgabenabwicklung und die operative Unterstützung bei der Lösung von Problemen. Eine informationstechnologische Unterstützung für die Problemlösung wurde als sinnvolle Ergän- zung betrachtet. Die Ziele, die vom Unternehmen mit dem Problemlösungsassistenten verfolgt wurden, können in zwei Kategorien unterteilt werden. Aus Mitarbeitersicht verfolgte das Unternehmen folgende Ziele: − Anleitung zur strukturierten Lösung des Problems (z.B. durch Checklisten) − Bereitstellung von Werkzeugen zur Problemlösung − Anbieten von bestehenden Lösungen zum vorliegenden Problem − Unterstützung der Problemlösung im Team Aus Unternehmenssicht wurden folgende Ziele verfolgt: − Erhöhung und Sicherstellung der Qualität durch vollständige Fehlerdokumentation, struktu- riertes Vorgehen und durch die Unterstützung des implementierten KVP-Ansatzes − Erzielung schneller, praxisorientierter Lernkurven durch die Bereitstellung bisherig aufgetre- tener Probleme und deren Lösungen. 7.2 Ansatz und Vorgehensweise Basierend auf den identifizierten hohen Anforderungen an die Bündelung und das Manage- ment verteilten Wissens im Problemlösungsprozess wurde der Einsatz des Problemlösungs- assistenten von den Anwendern als nutzbringend angesehen. Der gewählte Ansatz des Problemlösungsassistenten bietet den Ingenieuren zum einen die Möglichkeit, sich kontinuierlich in ihrem Fachgebiet weiter zu entwickeln, sich mit anderen Ex- perten auf hohem Niveau über aktuelle Probleme und neue Konzepte, Verfahren, Methoden und Technologien zu deren Lösung auszutauschen. Dies erhöht die Geschwindigkeit der Lö- sungsentwicklung sowie die Qualität der Problemlösung, da die Experten schnell und gezielt auf verteilte Expertisen zugreifen können. Zum anderen bietet der Problemlösungsassistent die Möglichkeit, durch situatives, problem- bzw. aufgabenorientiertes Lernen die bestehenden Problemlösungskompetenzen der Mitarbei- ter bedarfsorientiert weiter zu entwickeln. Die in der Regel unstrukturierte und sehr intuitive Lösung von Problemen sollte durch folgende drei Elemente optimiert werden (vgl. Abbildung 41): − die Anleitung zur strukturierten Entwicklung von Problemlösungen durch die Bereitstellung entsprechender Vorgehensweisen − die Bereitstellung von Experten bzw. Ansprechpartner im Wissensnetzwerk, welche durch den Transfer eigener Erfahrungen und Beispiele zur schnellen Lösung von Problemen bei- tragen können oder im Team verteilt Lösungen entwickeln können sowie − die systematische, intelligente Bereitstellung entsprechender Wissensinhalte, die der Prob- lemlöser zur Lösung seines Problems benötigt. 135 Abbildung 41: Problemlösung im Praxisbeispiel – Problemlösungsassistent realisiert als Modul einer Plattform für Wissensnetzwerke 7.3 Einsatz des Problemlösungsassistenten Im Unternehmen wurde der Problemlösungsassistent im Bereich „Rapid Prototyping“ einge- setzt. Zielstellung war, mit einem Kooperationspartner unternehmensübergreifend und verteilt an Problemlösungen zu arbeiten, die sich im Rahmen von aktuellen Entwicklungsprojekten ergeben. Der Zugang zum Problemlösungsassistenten erfolgte über das Internet. Der Problemlösungs- assistent wurde als Modul in eine Plattform für Wissensnetzwerke eingebunden, auf die beide Unternehmen zugreifen. Von beiden Unternehmen wurden im Rahmen der 6-monatigen Testphase 69 Problemtickets im Problemlösungsassistenten angelegt. Die Bearbeitung des Problemtickets und die Lösung des Problems erfolgte durch die am Problemlösungsprozess beteiligten Ingenieure von beiden Unternehmen. Die folgende Abbildung zeigt ein im Problemlösungsassistenten angelegtes konkretes Problem, welches bei einem Gussteil des Unternehmens aufgetreten ist. Dhfjdhfj hsjfhfj jfshf jfmsdfj fjkdfh sjf hjdsfh jhfdshf shfh sfkhsk fhkjhgcjyhf fdfhs fjdshfjfh fsdfhfjh df jshfjkd shf skfhjkhfjkhffjhjf h kfhka sdhf ksfhfhfhfhkhf khf jkdshfkjshf shfjDhfjdhf j hsjfhf j jfshfj fmsdfj f jkdfh sjfhjdsfhjhfdshf shfh sfkhsk fhkjhgcjyhf fdfhs fjdshfjfh f sdfhfjh dfjshfjkdshf skfhjkhf jkhffjhjfh kfhkasdhf ksfhfhfh fhkhf hfdshfkjhfjkhf khfjkdshfkjshf shf j Wer hilft mir weiter? Expertennetzwerk/ Ansprechpartner Strukturierte Vorgehensweise durch Problemlösungsassistent Fundierter Inhalt z.B. durch Suchassistent Wissensdatenbank verteilte Problemlösung im Team Plattform für Wissensnetzwerke Dhfjdhfj hsjf hf j jf shfj fmsdf j fjkdfh sjfhjdsfhjhfdshf shfh sfkhsk fhkjhgcjyhf fdfhs fjdshfjfh fsdfhf jh dfjshf jkdshf skfh jkhfjkhffjhjfh kfhkasdhf ksfhfhfh fhkhf khfjkdshfkjshf shfjDhfjdhf j hsjfhfj jfshf jfmsdfj fjkdfh sjfhjdsfhjhfdshf shfh sfkhskfhkjhgcjyhf fdfhs fjdshf jfh fsdfhfjh df jshfjkd shf skfhjkhfjkhffjhjfh kfhka sdhf ksfhfhfh fhkhf hfdshfkjhf jkhf khfjkdshfkjshf shfj Wo finde ich ....? Problemlösungsassistent integriert als Modul Dhfjdhfj hsjfhfj jfshf jfmsdfj fjkdfh sjfhjdsfhjhfdshf shfh sfkhsk fhkjhgcjyhffdfhs fjdshfjfh fsdfhf jh dfjshfjkdshf skfhjkhfjkhff jhjfh kfhkasdhf ksfhfhfh fhkhf khfjkdshfkjshf shfjDhf jdhf j hsjfhfj jfshfj fmsdfj f jkdfh sjfh jdsfhjhfdshf shfh sfkhskfhkjhgc jyhf fdfhs fjdshfjfh fsdfhfjh df jshfjkdshf skfhjkhfjkhff jhjfh kfh kasdhf ksfhfhfh fhkhf hfdshfkjhfjkhf khfjkdsh fkjshf shfj 136 Abbildung 42: Beispiel eines Problemtickets – Oberflächendefekt bei grauen Abgussteilen 7.4 Zusammenfassende Bewertung Der Einsatz der Systematik zur Problemlösung und des Problemlösungsassistenten führte zum einen zu einer Verbesserung der individuellen Arbeitsprozesse. Durch die strukturierte, geführte Anleitung zur Problemlösungsentwicklung, die systematische Informationsrecherche und strukturierte Beantwortung von Fragen wird sowohl die Qualität der Aufgabenerledigung, die Abwicklungslogik als auch das Arbeitsergebnis entscheidend verbessert. Zum anderen unterstützt der Ansatz die fundierte Entscheidungsfindung. So wird die Ent- scheidungsqualität und -fähigkeit der am Problemlösungsprozess beteiligten Experten durch die schnelle Bereitstellung aller zur Problemlösung notwendigen Expertise maßgeblich ver- bessert und es können kurze Reaktionszeiten durch direkten Zugriff auf Experten- Informationen und innovative Beratungsdienstleistungen realisiert werden. Darüber hinaus fördert die Arbeit mit dem Problemlösungsassistenten die gezielte Entwicklung innovativer Lösungen, indem dezentral verfügbare Expertise über das Projektteam hinaus gebündelt wird. Das Zusammenführen von Experten mit gleichen Arbeitsschwerpunkten und Interessen trägt wesentlich dazu bei, eine Atmosphäre zu schaffen, in der kreativ gearbeitet werden kann. Effizienteres Lernen („learning on the job“) durch die globale Bearbeitung von Problemen er- möglicht eine gezielte individuelle Weiterbildung und bedarfsorientierte Entwicklung individuel- 137 ler Kompetenzen. Dadurch ergibt sich ein intensives Kennenlernen der Experten sowie ein gemeinsames Verständnis für Zusammenhänge. Auf strategischer, unternehmerischer Ebene konnten durch die bereichs- und projektübergrei- fende Zusammenarbeit in Problemlösungsprozessen komplexe Wissensgebiete erschlossen werden. So kann kritisches Know-how erfasst und gesichert und die Abwanderung von Know- how vermieden werden. Durch die Transparenz über verteilt verfügbarer Expertise konnten letztlich Synergiepotenziale realisiert werden, Redundanzen erkannt und Synergieeffekte gezielt transferiert werden. 8 Zusammenfassung und Ausblick Das Ziel der vorliegenden Arbeit war es, die verteilte Lösung von wissensintensiven Proble- men in den frühen Phasen der Produktentwicklung zu unterstützen. Dies umfasst sowohl indi- viduelle als auch kooperative Aspekte der Problemlösung. Im Vordergrund stand dabei die Betrachtung der Aufbau- und Ablauforganisation, die Betrachtung der für die Problemlösung relevanten Wissens- und Lernprozesse und die Etablierung eines ganzheitlichen, integrierten Problemlösungsmanagement. Ferner galt es, realen, in der Arbeitsumgebung auftretenden Problemen Rechnung zu tragen und die Unterstützung der Problemlösung darauf abzustim- men. Dieses Ziel wurde durch die Entwicklung einer Systematik zur Gestaltung und Optimierung von wissensintensiven, kooperativen Problemlösungsprozessen und die prototypische Umset- zung in einen Problemlösungsassistenten erreicht. Dazu wurde zuerst der Stand der Forschung darauf hin untersucht, inwieweit bestehende An- sätze zur Klassifikation von Problemen den Anforderungen der industriellen Praxis entspre- chen. Analog dazu wurde untersucht, inwieweit bestehende Ansätze zur Problemprävention und zur Problemlösung sowie Systeme zur Problemlösung den definierten Anforderungen an wissensintensive, kooperative Problemlösungsprozesse Rechnung tragen. Darauf aufbauend erfolgte die Entwicklung eines inhaltlichen Rahmens für die Gestaltung und Optimierung von wissensintensiven, kooperativen Problemlösungsprozessen. Dazu wurde ein Beschreibungsmodell für Probleme im industriellen Umfeld entwickelt und empirisch validiert. Dieses diente schließlich als Grundlage für die Ableitung und Ausgestaltung der drei Gestal- tungselemente − Organisation und Koordination von Problemlösungsprozessen − Kommunikation und Wissensaustausch − Wissensintegration und Wissensgenerierung. Um den Einsatz der entwickelten Systematik in Unternehmen zu erleichtern, erfolgte eine pro- totypische, informationstechnologische Umsetzung der Systematik in einen Problemlösungs- assistenten. Das abschließende Fallbeispiel dokumentiert den Einsatz des Problemlösungsassistenten in der Produktentwicklung eines Engineering Dienstleisters. In Kooperation mit einem Entwick- lungspartner wurden 69 Probleme im Problemlösungsassistenten angelegt und gelöst. Damit wurde die grundsätzliche Eignung der Systematik und des Problemlösungsassistenten für die Produktentwicklung erbracht. Es konnte gezeigt werden, dass der Nutzen des Problemlö- sungsassistenten für Unternehmen sehr hoch ist. Die beteiligten Unternehmen konnten Zeit- einsparungen durch eine effizientere, schnellere Lösungsfindung sowie durch eine strukturier- tere Lösungsentwicklung realisieren. Auch die Verbesserung der Kommunikation durch die Interaktion im Problemlösungsassistenten und die Verbesserung der Qualität durch das sys- tematische Vorgehen wurden von den untersuchten Unternehmen als Mehrwert identifiziert. Der in dieser Arbeit dargestellte Ansatz ist zwar für die frühen Phasen der Produktentwicklung im Bereich Rapid Prototyping ausgestaltet worden, er ist jedoch auch auf andere Bereiche 139 übertragbar. Beispielsweise kann der Problemlösungsassistent im Vertrieb eingesetzt werden. Vom Kunden eingehende Beschwerden und Probleme zu Produkten können strukturiert er- fasst, bearbeitet und dokumentiert werden. Auch wäre ein Einsatz des Problemlösungsassis- tenten bei Softwareherstellern im Second Level Support denkbar. Komplexere Probleme, die nicht durch das Call Center direkt lösbar sind, werden über den Problemlösungsassistenten erfasst und zur Bearbeitung an den entsprechenden unterstützenden Bereich weitergeleitet. Potenziale zur Weiterentwicklung werden zum einen im Bereich der Softwareunterstützung, z.B. in der semi-automatisierten Unterstützung von verteilten Problemlösungsprozessen über dynamische, ad-hoc Workflows gesehen. Auch ist die Abbildung der Bewertung von Proble- men beispielsweise über statistische Auswertungen in der Softwarelösung nicht berücksichtigt. Zudem könnte die informationstechnologische Abbildung von Routinen, Constraints, Ursache- Wirkungsketten im Sinne eines „Intelligent Problem Solvers“ die Auswahl von Lösungsalterna- tiven bzw. die Entwicklung geeigneter Lösungsstrategien unterstützen. Weitere Forschungsfragen betreffen sozialwissenschaftliche und (kognitions-)psychologische Aspekte. Hier bietet das menschliche Problemlösungsverhalten noch ein weites Feld für For- schungsarbeiten. Beispielhaft seien hier für die interorganisationale und interkulturelle Prob- lemlösung das Verhalten sozialer Systeme unter den Aspekten Motivation und Anreize sowie die Vertrauensbildung oder die Gestaltung einer Kooperationskultur genannt. 9 Literatur /1/ Aamodt, A.; Plaza, E.: Case-Based Reasoning: Foundational Issues, Methodological Variations and Sys- tem Approaches In: AI Communicaitons, IOS Press, Vol. 7: 1, 1994, S. 39-59 /2/ Ackermann, P. L.: Individual differences in skill learning: An integration of psychometric and informa- tion processing perspectives In: Psychological Bulletin 102, 1987, S. 3-27 /3/ Agyris, C.; Schön, A. D.: Organisational Learning: A Theory of Action Perspective Reading, MA: Addison-Wesley, 1978 /4/ Akao, Y.: Quality Function Deployment - Wie die Japaner Kundenwünsche in Qualität um- setzen Hrsg.: Prof. Günther Liesegang Landsberg/Lech: Moderne Industrie, 1992 /5/ Akkermans, J.: Kennis in kaart Inaugurele rede UT Enschede, 1995 /6/ Allweyer, T.: Modellbasiertes Wissensmanagement In: Information Management 1, 1998 /7/ Arbinger, R.: Psychologie des Problemlösens Darmstadt: Wiss. Buchges., 1997 /8/ Baur, C.; Ohe, C. v. d.: Slashing time – not costs – drives supplier product development success. In: WWW-Seiten von McKinsey & Comp., Bereich: Automotive & Assembly URL: http://autoassembly.mckinsey.com /9/ Beiersdorf, H.: Informationsbedarf und Informationsbedarfsermittlung im Problemlösungsprozess "Strategische Unternehmensplanung" Hrsg.: Steinle, Claus München; Mering: Hampp, 1995 Zugl.: Hannover, Univ., Diss., 1994 141 /10/ Bender, B.; Tegel, O.; Beitz, W.: Teamarbeit in der Produktentwicklung. In: Konstruktion 48 (1996) Nr.3; S. 73-76 /11/ Bielenberg, K. M.: Der kontinuierliche Problemlösungsprozess: Konzepte-Schwachstellenanalysen- Optimierungsansätze Wiesbaden: Gabler, 1996 Zugl.: München, Techn. Univ., Diss., 1995 /12/ Binner, H. F.: Integriertes Organisations- und Prozessmanagement 1. Aufl. München, Wien: Hanser, 1997 /13/ Bismark, W.-B.; Held, M.: Befragung zur Anwendung innovativer Kommunikationstechnologien URL: http://www.psychologie,uni-mannheim.de/psycho1/psycho1.htm 11.10.2000 /14/ BOSCH Arbeitskreis AK-LS: Bosch FMEA Grundseminar TQ 011 2. überarbeitete Ausgabe 2/1995 /15/ Bourne, L. E.; Ekstrand, B. R.; Dominowski, R. L.: The psychology of thinking Englewoods-Cliffs: Prentice-Hall, 1971 /16/ Brauchlin, E.; Heene, R.: Problemlösungs- und Entscheidungsmethodik: Eine Einführung 4., vollst. Überarb. Aufl. Bern; Stuttgart: Haupt, 1995 /17/ Buder, J.: Wissensaustausch und Wissenserwerb in Computerkonferenzen, Der Einfluss des Metawissens (2000). URL: http://w210.ub.uni- tuebingen.de/dbt/volltexte/2002/445/, 19.08.2005. /18/ Bullinger, H.-J., et al.: Rapid Product Development - ein ganzheitliches Produktentwicklungskonzept In: Konstruktion 48, S. 305-312, Berlin: Springer, 1996 /19/ Bullinger, H.-J.: Einführung in das Technologiemanagement. Modelle, Methoden, Praxisbeispiele Stuttgart: Teubner, 1994 /20/ Bullinger, H.-J.; Warschat, J.: Introduction In: Consens - Concurrent Simultaneous Engineering Systems Hrsg.: Bullinger, H.-J.; Warschat, J. London: Springer, 1996 S. 1-5 142 /21/ Bullinger, H.-J.; Warschat, J.: Technologiemanagement - Wettbewerbsfähige Technologientwicklung und Ar- beitsgestaltung Stuttgart: Teubner, 1997 /22/ Bullinger, H.-J.; Warschat, J.; Wörner, K.; Wissler, K.: Rapid Product Development. Ein iterativer Lösungsansatz zur Verkürzung der Entwicklungszeiten in dynamischen Umfeldern In: VDI-Z integrierte Produktion, Nr. 5; 1996, S. 38-41 /23/ Bürgel, H.D.; Zeller, A.: Forschung und Entwicklung als Wissenscenter. In: Bürgel, H.D. (Hrsg.); Wissensmanagement Berlin, u.a.: Springer, 1998 /24/ Daenzer, W. F.; Huber, F.; Haberfellner, R. (Hrsg.): Systems Engineering: Methodik und Praxis 7. Aufl. Zürich: Verlag industrielle Organisation, 1992 /25/ Dathe, J.: Kooperationen - Leitfaden für Unternehmen München: Hanser, 1998 /26/ Davenport, T. et al.: Improving Knowledge Work Processes In: Sloan Management Review 34 (4), 1996 /27/ Davenport, T. H.; Prusak, L.: Working Knowledge: How Organisations Manage What They Know Boston: Harvard Business School Press, 1998 /28/ Davis, G. A.: Current status of research and theory in human problem solving In: Psychological Bulletin, 66, 1966 S. 36-54 /29/ de Jong, T.; Ferguson-Hessler, M.: Types and Qualities of Knowledge In: Educational Psychologist, 31 (2), 1996 S.105-113 /30/ Dewey, J.: How we think Boston : Heath, 1933 /31/ Diefenbruch, M.: Einführung von Wissensmanagement in einem Dienstleistungsunternehmen – Eine Success-Story In: Proceedings des Congress VII, Online 2002: Content, Portal & Knowledge Ma- nagement. Düsseldorf, 28.01.-31.01.2002 Velbert: Online, 2002 143 /32/ Diefenbruch, M.; Goesmann, T.; Herrmann, T., Hoffmann, M.: KontextNavigator und ExperKnowledge - Zwei Wege zur Unterstützung des Pro- zesswissens in Unternehmen In: Proceedings der KnowTech, 1-3. November 2001 (CD) /33/ Diemer, A.: Die automatisierte elektronische Datenverarbeitung 2. Auflage Berlin: de Gruyter, 1968 /34/ DIN 25424 Fehlerbaumanalyse, Teil 1 Methode und Bildzeichen Berlin: DIN, 1981 /35/ DIN 44300 Elektronische Datenverarbeitung Berlin: DIN, 1972 /36/ DIN 69910: Wertanalyse Düsseldorf: DIN, 1987 /37/ DIN EN ISO 9000 Qualitätsmanagementsysteme – Grundlagen und Begriffe Dezember 2000 /38/ DIN EN ISO 9000-1: Normen zum Qualitätsmanagement und zur Qualitätssicherung/QM-Darlegung Teil 1: Leitfaden zur Auswahl und Anwendung August 1994 /39/ Dittmar, J.; Scholl, K.; Marx, P.; Koch, U.; Kempf, M.; Wörner, K.: Integration von Zeit, Kosten und Qualität als Regulativ im Produktentwicklungspro- zess In: FB/IE 46 (1997), Nr. 3, S. 10-13 /40/ Dörner, D. : Die kognitive Organisation beim Problemlösen Bern ; Stuttgart ; Wien: Huber, 1974 /41/ Dörner, D.: Problemlösen als Informationsverarbeitung 1. Aufl. Stuttgart, Berlin: Kohlhammer , 1976 /42/ Dörner, D.; Schaub, H.; Strohschneider, S.: Komplexes Problemlösen - Königsweg der theoretischen Psychologie? In: Psychologische Rundschau 50 (4), S. 198-205, 1999 144 /43/ Dreyfus, H. L.; Dreyfus, S. E.: Künstliche Intelligenz. Von den Grenzen der Denkmaschine und dem Wert der Intuition. Reinbeck: Rowohlt, 1987, S. 41 /44/ Ehrlenspiel, K.: Integrierte Produktentwicklung: Methoden für die Prozessorganisation, Produkter- stellung und Konstruktion München; Wien: Hanser, 1995, S. 46-116 /45/ Franke, H.: Problemlösen in Gruppen: Veränderungen in Unternehmungen zielwirksam reali- sieren 3. Auflage Leonberg : Rosenberger Fachverl., 1998 S. 8 /46/ Frankenberger, E.: Arbeitsteilige Produktentwicklung. Empirische Untersuchung und Empfehlungen zur Gruppenarbeit in der Konstruktion Fortschrittsbericht VDI Reihe 1 Nr. 291 Düsseldorf: VDI, 1997 /47/ Frehr, H.-U.: Total Quality Management In: Handbuch Qualitätsmanagement 4. überarb. und erw. Aufl. Hrsg.: Prof. Walter Masing München, Wien: Hanser, 1999, S. 31-47 /48/ Fricke, G.: Empirical Investigation of successful approaches when dealing with differently pre- cised desing problems. In: Roozenburg, N. (Hrsg.) Proceedings of ICED 1993, Schriftenreihe WDK 22 (S. 359-367) Zürich: Heurista 1993 /49/ Fricke, G.: Konstruieren als flexibler Problemlöseprozess - Empirische Untersuchung über erfolgreiche Strategien und methodische Vorgehensweisen beim Konstruieren Fortschrittsberichte VDI Reihe 1 Nr. 227, 1993 /50/ Fuchs-Kittowski, F.: Kooperative Wissenserzeugung und –nutzung in wissensintensiven Geschäftspro- zessen In: Professionelles Wissensmanagement. Erfahrungen und Visionen Hrsg.: Schnurr, H.-P.; Staab, S.; Studer, R.; Stumme, G.; Sure, Y. Aachen: Shaker, 2001; S. 44 ff. 145 /51/ Ganz, W.; Warschat, J.: Strategische Kooperation in Kleinbetrieben In: Produktentwicklung - innovativ und konkurrenzfähig Konferenzband Forum Kooperation im Engineering, 19. Juni 1996 Hrsg.: H.-J. Bullinger Stuttgart: Fraunhofer IRB Verlag, 1996 S. 67-91 /52/ Geißler, H.: Grundlagen des Organisationslernens Weinheim, 1994 /53/ Gentsch, P.: Wissenserwerb in Innovationsprozessen. Methoden und Fallbeispiele für die in- formationstechnologische Unterstützung 1. Aufl. Wiesbaden: Gabler, 2001 Zugl.: Koblenz, Wiss. Hochschule für Unternehmensführung, Diss., 2001 /54/ Girgensohn, T.: Unternehmenspolitische Entscheidungen Frankfurt a.M., Bern: Cirencaster, 1979 /55/ Gomez, P.; Probst, G.: Die Praxis des ganzheitlichen Problemlösens: vernetzt denken, unternehmerisch handeln, persönlich überzeugen Bern; Stuttgart; Wien: Haupt, 1995 /56/ Görner, R.: Zur psychologischen Analyse von Konstrukteur- und Entwurfstätigkeiten In: Die Handlungsregulationstheorie. Von der Praxis einer Theorie Hrsg.: Bergman, B. ; Richter, P. Göttingen: Hogrefe, 1994. S. 233-241 /57/ Gottlob, G.; Frühwirth, T.; Horn, W. (Hrsg.): Expertensysteme Wien; New York: Springer, 1990 /58/ Green, P.C.: Building Robust Competencies: Linking Human Resource Systems to Organiza- tional Strategies. Jossey-Bass, 1999 /59/ Gruber, H.: Wie denken und was wissen Experten? In: Wissen und Denken. Beiträge aus Problemlösepsychologie und Wissenspsy- chologie Hrsg.: Gruber, H.; Mack, W.; Zielgler, A. Wiesbaden: DUV, 1999 S. 197-209 146 /60/ Gruber, T. R.: A translation approach to portable ontologies In: Knowledge Acquisition, 1993, 5 (2), S. 199-200 /61/ Hamel, G.; Prahalad, C. K.: Competing for the future Boston, Mass.: Harvard Business School Press, 1994 /62/ Hart, A.: Knowledge Acquisition for expert systems London: Kogan 1986; S. 25; /63/ Hartlieb, E.: Zur Rolle der Wissenslogistik im betrieblichen Wissensmanagement Dissertation Zugl.: Graz, Techn. Univ., Diss., 2000, S. 80 /64/ Heckert, U.: Rolle und Einsatzmöglichkeiten der Informations- und Kommunikationstechnologie beim Wissensmanagement. Elemente eines Gestaltungsmodells für die Produkt- entwicklung in Unternehmen der verarbeitenden Industrie 1. Aufl. Wiesbaden: Dt. Univ.-Verl., 2002 Zugl.. Göttingen, Univ., Diss., 2001 /65/ Heinrich, L. J.; Burgholzer, P.: Systemplanung I 5. Auflage München: Oldenbourg, 1991 /66/ Heisig, P.: Business Process Oriented Knowledge Management – Methode zur Verknüpfung von Wissensmanagement und Geschäftsprozessgestaltung Beitrag der 1. Konferenz Professionelles Wissensmanagement – WM 2001, Ba- den-Baden 14.-16. März 2001 URL: http://sunsite.informatik.rwth-aachen.de/publications/CEUR-WS/Vol-37 /67/ Henschel, A.: Communities of Practice - Plattform für organisationales Lernen und den Wissens- transfer 1. Aufl. Wiesbaden: Dt. Univ.-Verl., Gabler, 2001 Zugl.. St. Gallen, Univ., Diss., 2000 /68/ Herb, T.; Herb, R.: Ideen finden, Produkte entwickeln mit TRIZ München, Wien: Hanser, 2000, S. 1 /69/ Hesse, F. W.: Analoges Problemlösen Weinheim: Psychologie-Verl.-Union, 1991 147 /70/ Hesse, F. W.; Spies, K.; Lüer, G.: Einfluss motivationaler Faktoren auf das Problemlöseverhalten im Umgang mit komplexen Problemen In: Zeitschrift für experimentelle und angewandte Psychologie, 30; 198 S. 400-424 /71/ Hoffmann, M; Goesmann, T.; Misch, A.: Wie man „verborgenen Wissensprozessen“ auf die Schliche kommt In: Professionelles Wissensmanagement. Erfahrungen und Visionen Hrsg.: Schnurr, H.-P.; Staab, S.; Studer, R.; Stumme, G.; Sure, Y. Aachen: Shaker, 2001; S. 59 ff. /72/ Högl, M.: Teamarbeit in innovativen Projekten Wiesbaden : Dt. Univ.-Verl.; Wiesbaden : Gabler, 1998 Zugl.: Karlsruhe, Univ., Diss., 1998 S. 108 /73/ Hüllenkremer, M.: Erfolgreiche Unternehmen arbeiten mit Produktkonfiguratoren. In: Industrie Manager 19 (2003), S. 37 - 40. Berlin: GITO-Verlag, 2003. /74/ Hungenberg, H.: Problemlösung und Kommunikation. Vorgehensweisen und Techniken 2. überarbeitete und erweiterte Auflage München, Wien: Oldenbourg 2002 /75/ Hussy, W.: Denken und Problemlösen Stuttgart; Berlin: Kohlhammer, 1998, S. 119 ff. /76/ Jackson Grayson, C.: Taking Inventory of Your Knowledge Management Skills URL: http:://www.apqc.org, Oktober 1996 /77/ Johnson, D. M.: Systematic introduction to the psychology of thinking New York: Harper & Row, 1972 /78/ Jorden, W.; Havenstein, G.; Schwarzkopf, W.: Vergleich von Konstruktionswissenschaft und Praxis; Teilergebnisse eines For- schungsvorhabens Proceedings of ICED 1985, Hamburg Zürich: Edition Heurista, 1985. /79/ Judd, C., Smith, E. & Kidder, L.: Research Methods in Social Relations Sixth edition. Fort Worth: Harcourt Brace Jovanovich College Publishing, 1991 148 /80/ Keller, J. A.; Novak, F.: Kleines Pädagogisches Wörterbuch Freiburg: Herder, 1995 /81/ Kersting, M.: Diagnostik und Personalauswahl mit computergestützten Problemlöseszenarien Göttingen; Bern; Toronto; Seattle: Hogrefe, 1999 Zugl.: Giessen, Justus-Liebig-Universität, Diss., 1998 /82/ Kim, D. H.: The Link between Individual and Organisational Learning In: Sloan Management Review, Fall, 1993, S. 37-50 /83/ Kirsch, W.: Entscheidungsprozesse II Wiesbaden: Gabler, 1977, S. 76 /84/ Kirsch, W.: Kommunikatives Handeln, Autopoiese, Realität 2., überarb. u. erw. Aufl. München : Kirsch, 1997 S. 192 /85/ Klauer, C.: Grundlagen der Problemlöseforschung. In: Computersimulierte Szenarien in der Personalarbeit Strauß Bernd (Hrsg.), Kleinmann Martin (Hrsg.) Göttingen: Verl. für Angewandte Psychologie, 1995 /86/ Klein, B.: TRIZ/TIPS – Methodik des erfinderischen Problemlösens Wien: Oldenbourg, 2002, S.1 /87/ Kleinhans, A. M. : Wissensverarbeitung im Management: Möglichkeiten und Grenzen wissensbasier- ter Managementunterstützungs-, Planungs- und Simulationssysteme Frankfurt: Lang, 1989 /88/ Kluge, F.: Etymologisches Wörterbuch der deutschen Sprache 23., erw. Aufl. Berlin; New York: de Gruyter, 1999 /89/ Köck, P.; Ott, H.: Wörterbuch für Erziehung und Unterricht Donauwörth: Auer, 1994 /90/ Kogut, B. ; Zander, U.: Knowledge of the Firm: Combinative Capabilities and the Replication of Technol- ogy In: Organisation Science 3, 3 1992 S. 383-397. 149 /91/ Kolb, D. A.: Experiental Learning: Experience as the Source of Learning and Development Englewood Cliffs, New Jersey: Prentice-Hall, 1984 /92/ Kunz, A.; Müller, S.: Einsatz der Informationstechnologie in der FMEA. IT-supported FMEA http://www.fmeainfocentre.com/download/itfmea.pdf 01.03.2006 (heruntergeladen) /93/ Landauer, G: Die Wirkung von Problemlösungstechniken auf Informationsverhalten un Entschei- dungseffizienz. Eine experimentelle Untersuchung am Beispiel der Nutzwertanaly- se Schriften zur empirischen Entscheidungs- und Organisationsforschung; Bd. 15 Frankfurt; Berlin: Lang, 1996 Zugl.: Bayreuth, Univ., Diss., 1994 /94/ Lehner, F.; Maier, R.: Information in der Betriebswirtschaftslehre, Informatik und Wirtschaftsinformatik Schriftenreihe des Lehrstuhls für Wirtschaftsinformatik und Informationsmanage- ment Forschungsbericht Nr. 11, WHU Koblenz, Koblenz, Mai 1994; S. 80f /95/ Malik, F.: Strategie des Managements komplexer Systeme 7. durchges. Auflage Stuttgart: Paul Haupt, 2002; S. 47 ff. /96/ Maturana, H. R.; Varela, F.J.: Der Baum der Erkenntnis - Die biologischen Wurzeln menschlichen Erkennens 10. Aufl. Bern/München: Goldmann, 2002, S. 210 /97/ Mehrmann, E.: Schnell zum Ziel Kreativitäts- und Problemlösungstechniken Düsseldorf, Wien: ECON, 1994 /98/ Mertens, P.: Lexikon der Wirtschaftsinformatik Berlin: Verlag, 1987 /99/ Miller, R. B. Development of a Taxonomy of Human Performance: Design of a System Task Vocabulary Washington: American Institutes for Research, 1971 /100/ Müller, J.: Methoden der Planung konstruktiver Arbeitsprozesse In: Konstruktion, 42, 1990 S. 173-180 150 /101/ Müller-Stewens, G.; Gocke, A.: Kooperation und Konzentration in der Automobilindustrie Chur : Verl. Fakultas, 1995 /102/ Nadler, G.: Arbeitsgestaltung – zukunftsbewusst München: Hanser, 1969, S. 36 /103/ Neuweg, G. H.: Könnerschaft und implizites Wissen. Zur lehr-lerntheoretischen Bedeutung der Erkenntnis- und Wissenstheorie Michael Polanyis. Münster; New York; München; Berlin: Waxmann, 1999 /104/ Ninck, A. et al.: Systemik: integrales Denken, Konzipieren und Realisieren Zürich: Industr. Organisation, 1998 /105/ Nonaka, I.: A Dynamik Theory of Organisational Knowledge Creation In: Organisational Science Vol. 5, No. 1, 2/1994 /106/ Nonaka, I.; Takeuchi, H.: Die Organisation des Wissens. Wie japanische Unternehmen eine brachliegende Ressource nutzbar machen. Frankfurt/Main; New York: Campus 1997. /107/ North, K.: Wissen schaffen in Forschung und Entwicklung In: Bürgel, H. D., Forschungs- und Entwicklungsmanagement 2000plus Berlin u.a.: Springer, 2000 /108/ North, K.: Wissensorientierte Unternehmensführung: Wertschöpfung durch Wissen 4., aktualisierte und erw. Aufl. Wiesbaden: Gabler, 2005 /109/ Pahl, G.; Beitz, W.: Konstruktionslehre - Methoden und Anwendung 4., neubearb. Aufl. Berlin, Heidelberg: Springer, 1997 /110/ Parnov, A.: Informations- und Assistenzsysteme im Auto benutzergerecht gestalten. Methoden für den Entwicklungsprozess Berichte der Bundesanstalt für Straßenwesen. Mensch und Sicherheit, Heft M11. Bergisch Gladbach: NW Wirtschaftsverlag, Februar 2000 /111/ Pawlowsky, P.: Integratives Wissensmanagement In: Wissensmanagement. Erfahrungen und Perspektiven, S. 9-46 Peter Pawlowsky (Hrsg.) Wiesbaden: Gabler, 1998 151 /112/ Petkoff, B.: Wissensmanagement – Von der computerzentrierten zur anwenderorientierten Kommunikationstechnologie Bonn: Adison-Wesley Longman, 1998 /113/ Picot, A.: Die Planung der Unternehmensressource "Information". In: Diebold Deutschland GmbH (Hrsg.) Tagungsband zum 2. Internationalen Management Syposium "Erfolgsfaktor Infor- mation" Frankfurt 1988, S. 223-250 /114/ Picot, A.; Rohrbach, P.: Organisatorische Aspekte von Workflow-Management-Systemen In: Information Management 1/95, 1995 /115/ Polanyi, M.: Implizites Wissen; Frankfurt: Suhrkamp, 1985 /116/ Prahalad, C.K.; Hamel, G.: Nur Kernkompetenzen sichern das Überleben In: Harvard Manager, 13. Jg. (1991), Heft 2, S. 66-78 /117/ Primus, A.: Wissensbasierte Problemlösungsprozesse - Zur Analyse und Gestaltung von Prob- lemlösungsprozessen im industriellen Management Zugl.: Graz, Technische Universität, Diss. Januar 2002 /118/ Probst, Gilbert, et al.: Wissen managen Wie Unternehmen ihre wertvollste Ressource optimal nutzen 4., überarb. Aufl. Frankfurt am Main: FAZ; Wiesbaden: Gabler, 2003 /119/ Prümper, J., Hartmannsgruber & Frese, M.: KFZA. Kurz-Fragebogen zur Arbeitsanalyse In: Zeitschrift für Arbeits- und Organisationspsychologie, 39, 3, 125 – 131, 1995 /120/ Puppe, F.: Problemlösungsmethoden in Expertensystemen Berlin, Heidelberg, New York: Springer 1990 /121/ Quinn, J. B. ; Anderson, P.; Finkelstein, S.: Das Potential in den Köpfen gewinnbringend nutzen In: Harvard Manager, III/3, 1996 /122/ REFA (Verband für Arbeitsgestaltung, Betriebsorganisation und Unternehmens- entwicklung e.V.): Grundlagen der Arbeitsgestaltung München: Verlag, 1993 S. 118 152 /123/ Rehäuser, J.; Krcmar, H.: Wissensmanagement im Unternehmen In: Managementforschung 6. Wissensmanagement Hrsg.: Schreyögg, G.; Conrad, P. Berlin, New York: de Gruyter, 1996; S. 2-40. /124/ Remus, U.: Integrierte Prozess- und Kommunikationsmodellierung als Ausgangspunkt für die Verbesserung von wissensintensiven Geschäftsprozessen In: Professionelles Wissensmanagement. Erfahrungen und Visionen Hrsg.: Schnurr, H.-P.; Staab, S.; Studer, R.; Stumme, G.; Sure, Y. Aachen: Shaker, 2001; S. 64 ff /125/ Romhardt, K.: Die Organisation aus der Wissensperspektive: Möglichkeiten und Grenzen der Intervention Wiesbaden: Gabler 1998 Zugl.: Genf, Univ., Diss., 1998 /126/ Ruprecht, C.; Rose, T.; Fünffinger, M.; Schott, H.; Sieper, A.; Schlick, C.; Mühlfe- der, M.: Management von Prozesswissen in Fahrzeugentwicklungsprojekten In: Professionelles Wissensmanagement. Erfahrungen und Visionen Hrsg.: Schnurr, H.-P.; Staab, S.; Studer, R.; Stumme, G.; Sure, Y. Aachen: Shaker, 2001; S. 29 ff. /127/ Sachse, P.: Unterstützung des entwerfenden Problemlösens im Konstruktionsprozess durch Prototyping In: Design Thinking. Analyse und Unterstützung konstruktiver Entwurfstätigkeiten Hrsg.: Sachse, Pierre; Specker, Adrian Zürich: vdf, Hochschlulverl. an der ETH Zürich, 1999 /128/ Schäffer, H.: Die Repräsentation von Managementwissen. Die Modellierung von Wissen für das Management von Expertensystemprojekten gemäß dem KADS-Ansatz Frankfurt a. Main, Berlin, Bern: Lang, 1996 Zugl.: Hohenheim, Univ., Diss., 1995 /129/ Schaub, H.; Reiman, R.: Zur Rolle des Wissens beim komplexen Problemlösen In: Wissen und Denken. Beiträge aus Problemlösepsychologie und Wissenspsy- chologie Hrsg.: Gruber, Hans; Mack, Wolfgang; Zielgler, Albert Wiesbaden: DUV, 1999 S. 169-191 /130/ Scheer, A.-W.: Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse 7. durchges. Auflage Berlin, Heidelberg: Springer, 1997 153 /131/ Schlingmann, S.: Kooperation und Wettbewerb in Problemlöseprozessen. Eine experimentelle Un- tersuchung Frankfurt am Main: Peter Lang, 1985. /132/ Schnurr, H.; Staab, S.; Studer, R.; Sure, Y.: Ontologiebasiertes Wissensmanagement - Ein umfassender Ansatz zur Gestaltung des Knowledge Life Cycles URL: http://www.aifb.uni-karlsruhe.de/WBS 16.01.2001 /133/ Schregenberger, J.: Erfolgreicher Konstruieren: aber wie? Umriss eines Forschungsfeldes In: Schweizer Maschinenmarkt, Nr. 23, 1986, S. 46-49 /134/ Schroda, F. ; Hacker, W.: "Über das Ende wird am Anfang entschieden" - Die Analyse der Anforderungs- struktur schöpferischer konstruktiver Arbeitsaufgaben In: Zeitschrift für Arbeitswissenschaft, 1998/3, 52(24 NF), S. 162-168 /135/ Schroda, F.: Die Analyse der Anforderungsstruktur konstruktiv-schöpferischer Probleme In: Design Thinking. Analyse und Unterstützung konstruktiver Entwurfstätigkeiten Hrsg.: Sachse, P.; Specker, A. Zürich: vdf, Hochschlulverl. An der ETH Zürich, 1999 /136/ Schubert, M.: Fehlermöglichkeits- und Einflussanalyse, Leitfaden Deutsche Gesellschaft für Qualität e.V. (DGQ) Berlin: DGQ, 1993 /137/ Schüppel, J.: Wissensmanagement: organisatorisches Lernen im Spannungsfeld von Wissens- und Lernbarrieren. Wiesbaden : Dt. Univ.-Verl.; Wiesbaden : Gabler, 1997 Zugl.: St. Gallen, Univ., Diss., 1996 /138/ Schwarz, S.; Abecker, A.; Sintek, M.: Anforderungen an die Workflow-Unterstützung für wissensintensive Geschäftspro- zesse In: Professionelles Wissensmanagement. Erfahrungen und Visionen Hrsg.: Schnurr, H.-P.; Staab, S.; Studer, R.; Stumme, G.; Sure, Y. Aachen: Shaker, 2001; S. 14 ff /139/ Seiffert, H.: Information über die Information 3. Auflage München: Beck, 1971 /140/ Selig, J.: EDV-Management Berlin; Heidelberg: Springer, 1986 154 /141/ Sell, R.: Angewandtes Problemlösungsverhalten 3. Aufl. Berlin: Springer, 1990 /142/ Sell, R.; Schimweg, R.: Probleme lösen. In komplexen Zusammenhängen denken 5., neubearb. und erw. Aufl. Berlin, Heidelberg, New York: Springer 1998 /143/ Senge, P.: Die fünfte Disziplin: Kunst und Praxis der lernenden Organisation 6. Aufl. Stuttgart: Klett-Cotta, 1998 /144/ Shannon, C.E., Weaver, W.: Mathematische Grundlagen der Informationstheorie München: Oldenbourg, 1976 /145/ Shannon, C.E.: A Mathematical Theory of Communication Part I In: Bell Systems Technical Journal, 27, 1948. S. 379 -423 /146/ Siegwart, H.: Produktentwicklung in der industriellen Unternehmung; Bern; Stuttgart: Haupt, 1989, S. 27 ff /147/ Stanke, A.; Berndes, S.: Simultaneous Engineering als Strategie zur Überwindung von Effizienzsenken In: Forschungs- und Entwicklungsmanagement. Simultaneous Engineering, Pro- jektmanagement, Produktplanung, Rapid Product Development Hrsg.: Bullinger, H.-J.; Warschat, J. Stuttgart: Teubner, 1997, S. 15-25 /148/ Stanke, A.; Berndes, S.: A.: Concept for Revitalisation of Product Development In: Consens - Concurrent Simultaneous Engineering Systems Hrsg.: Bullinger, H.-J.; Warschat, J. London: Springer, 1996 S. 15 /149/ Steinmüller, W.: Informationstechnologie und Gesellschaft: Einführung in die Angewandte Informa- tik Darmstadt: Wissenschaftliche Buchgesellschaft, 1993 /150/ Strauß, B.; Kleinmann, M.: Computersimulierte Szenarien in der Personalarbeit Göttingen: Verl. für Angewandte Psychologie,1995 155 /151/ Strohner, H.: Information, Wissen und Bedeutung In: Information und Kommunikation Hrsg.: Weingarten, R. Frankfurt: Campus, 1993 /152/ Sydow, H.: Zur Klassifikation von Problemen und Lösungsprozeduren In: Analyse und Synthese von Problemlösungsprozessen Hrsg.: Klix, F.; Krause, W.; Sydow, H. Berlin: Akademie, 1972 S. 11-27 /153/ Sydow, J.: Strategische Netzwerke: Evolution und Organisation 6. Nachdr. Wiesbaden : Gabler, 2005 /154/ Szulanski, G.: The Process of Knowledge Transfer: A Diachronic Analysis of Stickiness. In: Organisational Behavior and Human Decision Processes, 82 (1), 2000. S. 9-27 /155/ Teufelsdorfer, H.; Conrad, A.: Kreatives Entwickeln und innovatives Problemlösen mit TRIZ/TIPS: Einführung in die Methodik und ihre Verknüpfung mit QFD Hrsg.: Siemens Aktiengesellschaft, Berlin und München Erlangen; München: Publicis-MCD-Verl., 1998 /156/ Thomke, S.; Fujimoto, T.: The effect of front-loading problem-solving on product development performance In: Journal of Product Innovation Management, Vol. 17, No. 1, 2000 /157/ Trittmann, R.; Mellis, W.: Ökonomische Gestaltung des Wissenstransfers In: Industrie Management 15 (1999) 6, S. 64-68 /158/ Ulrich, H.: Die Unternehmung als produktives, soziales System. 2. Auflage Bern, Stuttgart: Haupt, 1970 S. 108 /159/ Ulrich, H.; Probst, G.: Anleitung zum ganzheitlichen Denken und Handeln 4., unveränd. Aufl. Bern : Haupt, 1995 /160/ Ulrich, K.T.; Eppinger, S. D.: Product Design and Development New York: McGraw-Hill, 1995 156 /161/ VDI: Virtuelle Produktentstehung in der Fahrzeugtechnik Veranstaltung 09 und 10.09.1999 in Berlin VDI-Gesellschaft Fahrzeug- und Verkehrstechnik Düsseldorf: VDI Verlag, 1999 /162/ VDI-Richtlinien VDI 2220-Produktplanung – Ablauf, Begriffe und Organisation. Düsseldorf: VDI, Mai 1980 /163/ VDI-Richtlinien VDI 2221-Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte. 2. Aufl. Düsseldorf: VDI, Mai 1993 /164/ VDI-Richtlinien VDI 2222, Blatt 1: Konstruktionsmethodik - Methodisches Entwickeln von Lö- sungsprinzipien Düsseldorf: VDI, Juni 1997 /165/ Vogt, R.: Individuelle, Innovative Problemlösungsprozesse: Erklärungsmodelle individueller, innovativer Problemlösungsprozesse im theoretischen Bezugsrahmen des Infor- mations-Verarbeitungs-Ansatzes und ihre wissenschaftstheoretische Einordnung. Frankfurt/Main: Haag und Herchen,1981 Zugl.: Berlin, Techn. Univ., Diss., 1979. /166/ Warnecke, G.; Jenke, K.; Benedix, G.: Innovative Wege in Problemlösungsprozessen. Neue Konzepte unter Einbindung von TRIZ In: ZWF, Jahrg. 97 (2002) 7-8, S. 400-403 /167/ Warnecke, G.; Stammwitz, G.; Hallfell, F.; Förster, H.: Evolutionskonzept für Referenzmodelle: Integration von Erfahrungswissen in den Modellierungsprozess Industriemanagement (IM) 14 (1998) 2, S. 60-64 /168/ Warschat, J. et al.: F&E heute - Bestandsaufnahme zur industriellen Forschung und Entwicklung in der Bundesrepubilk Deutschland Handbuch RKW 2910 Erich Schmidt, 1992 /169/ Warschat, J. et al.: Wissensmanagement im industriellen Umfeld In: Berechnung und Simulation im Fahrzeugbau Tagung Würzburg, 14.-15. 09.2000 Düsseldorf: VDI, 2000 157 /170/ Warschat, J.; Wagner, K.; et. al.: Wissensintensive Kooperationen in regionalen Netzwerken-Erfolgsfaktoren, Poten- tiale und Risiken Abschlussbericht des BMBF Projekts "Integration von heterogenem Wissen in an- passungsfähigen Produktionsnetzwerken (APN) in spezifischen, industriellen Dist- rikt-Strukturen (IDS)" Hrsg.:Fraunhofer IAO Stuttgart: Fraunhofer IRB, Juli 2001 /171/ Weggemann, M.: Wissensmanagement – Der richtige Umgang mit der wichtigsten Ressource des Unternehmens 1. Aufl. Bonn: MITP, 1999 /172/ Wehner, T.; Waibel, M.: Erfahrungsbegebenheiten und Wissensaustausch als Innovationspotentiale des Handelns. Die Analyse betreiblicher Verbesserungsvorschläge URL: http://www.rrz.uni-hamburg.de/psych.../Archiv/arbeit&erfahrung/mira.html, 2001 /173/ Westkämper, E.: Den Schlüssel zum Erfolg nicht verlegen In: wt Werkstattstechnik online Jahrgang 96 (2006) H.3 /174/ Wetzel, J.: Problemlösen in Gruppen: Auswirkungen von psychologischen Trainingsmaßnah- men und Expertenbeteiligung unter kooperativen und kompetitiven Arbeitsbedin- gungen. Dissertation Zugl.: Braunschweig, Techn. Univ., Diss., 1995 /175/ Wiig, K.M.: Knowledge Management Methods. Practical Approaches to Managing Knowledge Vol 3. Arlington: Schema Press, 1995. S. 257 /176/ Wildemann, H.: Quality Gates für Entwicklungsprozesse In: VDI-Z 143, Nr. 5, 2001, S. 31-34 /177/ Willke, H.: Systemtheorie Band 1 Grundlagen: Die Einführung in die Grundprobleme der Theorie sozialer Systeme 5. Auflage Stuttgart: G. Fischer, 1996, S. 30 /178/ Zack, M. H: Managing Codified Knowledge In: Sloan Management Review, 40 (1999) 4; S. 45-58 158 /179/ Zentrum Wertanalyse der VDI-Gesellschaft Systementwicklung und Projektgestal- tung (VDI-GSP): Wertanalyse. Idee-Methode-System 3. Auflage Düsseldorf: VDI, 1995, S. 56 10 Anhang 10.1 Fragebogen der Umfrage zum Problembeschreibungsmodell Fraunhofer-Institut Arbeitswirtschaft und Organisation (IAO) Frau Kristina Wagner und Frau Hannah Flügel Nobelstr. 12c D-70569 Stuttgart E-Mail: ina.wagner@iao.fhg.de/ hannah.fluegel@iao.fhg.de Tel.: +49 (0) 711/970-2215 Fax: +49 (0) 711/970-2299 Untersuchung Problemlösungsprozesse 161 Liebe(r) Teilnehmer(in), wir bitten Sie, an einer Untersuchung zum Thema „Problemlösungsprozesse“ teilzunehmen. Die Untersuchung findet im Rahmen eines Projektes des Fraunhofer Instituts für Arbeitswirtschaft und Organisation IAO in Stuttgart statt. Ziel der Untersuchung ist, zu überprüfen, wie Personen bei der Lösung von Problemen vorgehen. Die richtige Gestaltung von Problemlösungsprozessen ist für die Effizienz und die Innovationspotenziale von Unternehmen von großer Wichtigkeit. Um zu einer geeigneten Problemlösung zu kommen sind Informationen über Probleme, denen Sie im Alltag begegnen notwendig. Mit Ihrer Teilnahme können wir daher fundierte Ergebnisse bekommen, die der Praxis später zugänglich gemacht werden können. Im folgenden bitten wir Sie, Aussagen über die Situation an Ihrem Arbeitsplatz zu machen. Beden- ken Sie hierbei, dass es keine richtigen oder falschen Antworten gibt. Wichtig ist allein Ihre Sicht- weise. Der Fragebogen enthält zunächst einige Fragen zu Ihrer Person, die zur Vollständigkeit benötigt werden. Im Anschluss bitten wir Sie eine Beschreibung eines konkreten Arbeitsauftrags und eines Problems zu schildern, worauf weitere Fragen folgen werden. Ihre Antworten werden selbstverständlich anonymisiert behandelt und ausgewertet. Hinweise zum Ausfüllen des Fragebogens: • Nehmen Sie sich bitte ausreichend Zeit für das Durchlesen der Instruktionen und das Ausfüllen des Fragebogens. • Es ist wichtig für uns, dass Sie alle Fragen beantworten. Verlassen Sie sich bei den Fragen, die Sie nur schwer beantworten können, ganz auf Ihre Erfahrung und Ihr erstes spontanes Urteil. • Manche Fragen mögen Ihnen ähnlich vorkommen, sie unterscheiden sich jedoch im Detail und sind für das Verständnis Ihrer Einschätzung unbedingt notwendig. • Bei den meisten Fragen ist eine Skala vorgegeben, anhand derer Sie Ihre Einschätzung zu der jeweiligen Aussage abgeben sollen. Die Skalen haben abgestufte Antwortmöglichkeiten (z.B.     ). Kreuzen Sie dabei bitte nicht mehrere Zahlen und auch nicht die Zwischenräu- me zwischen den Zahlen an, sondern kreuzen Sie nur die eine Zahl an, die Ihrer Einschätzung entspricht. Die Ergebnisse der Studie werden Sie sicher interessieren. Damit wir Ihnen die Ergebnisse zusen- den können, sollten Sie auf dem letzten Blatt des Fragebogens Ihren Namen und Ihre Adresse einfügen. Die Angaben werden selbstverständlich vertraulich und anonym behandelt. 162 A Fragen zu Ihrer Person Im folgenden Abschnitt bitten wir Sie um Angaben zu Ihrer Person. A 1 Wie alt sind Sie? ____________ Jahre A 2 Welches Geschlecht haben Sie?  weiblich  männlich A 3 Welches ist Ihr höchster Schulabschluss?  kein Abschluss  Fachabitur  Hauptschulabschluss  Abitur  Mittlere Reife (Realschule)  andere: _______________________ A 4 Haben Sie eine abgeschlossene Ausbildung?  ja  nein  noch dabei Wenn ja, welche? _______________________ A 5 Haben Sie ein abgeschlossenes Studium?  ja  nein  noch dabei Wenn ja, welches? _______________________ A 6 Welchen Beruf üben Sie derzeit aus? _______________________ A 7 Wie heißt die Firma, in der Sie arbeiten? _______________________ A 8 Wie lange arbeiten Sie bereits in ihrer Firma? _______Jahre _______Monate A 9 Wie heißt die Abteilung, in der Sie arbeiten? _______________________ A 10 Welche Tätigkeit üben Sie in Ihrer Abteilung aus? ________________________ 163 B Problembeschreibung Diese Untersuchung widmet sich der Frage, wie Menschen mit komplexen Problemen umge- hen. Komplexe Probleme können entstehen, wenn Sie einen Arbeitsauftrag bekommen, des- sen Erfüllung für Sie und Ihr Unternehmen von großem Interesse ist. Sie beginnen damit den Arbeitsauftrag zu bearbeiten, es tritt jedoch während der Bearbeitung ein ungeplantes und unvorhergesehenes Problem in Form einer Störung auf. Dieses Problem hindert Sie daran, den Arbeitsauftrag weiter zu bearbeiten und fertig zu stellen, was eine Diskrepanz zu Ihrer gewünschten Auftragserfüllung darstellt. Außerdem ist Ihnen der Lösungsweg, wie der Ar- beitsauftrag erfüllt werden könnte, bzw. wie das Problem behoben werden könnte, nicht be- kannt. Ein nun folgendes konkretes Beispiel soll zum besseren Verständnis von Problemen beitragen. Angenommen Sie bekommen den Arbeitsauftrag, eine Stückzahl von 10-20 Kunststoffleisten in einem Prototypenprozess herzustellen. Diese dürfen eine bestimmte Toleranz nicht über- steigen. Es wird von Ihnen erwartet und es ist Ihnen selbst auch wichtig, dass Sie diesen Ar- beitsauftrag ausführen und erfüllen. Sie beginnen damit diesen Auftrag zu bearbeiten, indem Sie zuerst ein Urmodell aus Epoxydharz bauen. Dieses wird mit einer Silikonmasse umgos- sen, welches die Form für den Silikon-Vakuum-Guss des gewünschten Kunststoffteils dar- stellt. Aufgrund der üblicherweise auftretenden Schwindung erwarten Sie, dass die gegosse- nen Teile zu klein sind, was sie daher beim Guss mit einberechnen. Sie haben das Urmodell gemessen und es liegt eindeutig im Maß. Unvorhergesehen kommt es zu einem Problem in Form einer Störung, das Sie daran hindert, den Auftrag fertig zu bearbeiten: Sie messen das gegossene Kunststoffteil und bemerken, dass es wider Erwarten zu groß ist. Dies ist noch nie vorgekommen und Sie können sich das nicht erklären. Sie wissen also auf Anhieb nicht, durch welche Lösung Sie das Problem beseitigen und zur Auftragserfüllung kommen könnten. Es ist an Ihnen, neue Wege zu finden, wie Sie dieses Problem beheben und von Ihrer Ausgangslage dennoch zur Arbeitsauftragerfüllung (den Kunststoffleisten nach Maß) kommen können. Sie haben sicherlich schon eine ähnliche Situation bei Ihrer Arbeit erlebt. Bitte nehmen Sie sich etwas Zeit und überlegen, wie eine solche Situation in der letzten Zeit (ungefähr im Zeit- raum der letzten Wochen) für Sie ausgesehen hat. Beschreiben Sie im Folgenden bitte, wel- chen Arbeitsauftrag Sie bearbeitet haben und welches Problem (in Form einer unvorhergese- henen Störung) dabei aufgetreten ist. Der Arbeitsauftrag sollte zum jetzigen Zeitpunkt erfüllt sein und das Problem bereits behoben sein. 164 B 1 Beschreibung Ihres Arbeitsauftrages: ____________________________________________________________________ ____________________________________________________________________ ____________________________________________________________________ B 2 Beschreibung des aufgetretenen Problems in Form einer Störung: ____________________________________________________________________ ____________________________________________________________________ ____________________________________________________________________ Es folgen nun Fragen, die sich konkret auf die von Ihnen abgegebene Beschreibung ihres Arbeitsauftrages und des aufgetretenen Problems in Form einer Störung beziehen. Beantwor- ten Sie die Fragen bitte immer im Bezug auf diese Beschreibungen. Kreuzen Sie bei Fragen B 5 bis B 13 jeweils die Zahl der ausgewählten Antwortstufe in der rechten Spalte der Tabelle an, die Ihrer Meinung nach am ehesten zutrifft. B 3 Wie lange haben Sie insgesamt an dem Ar- beitsauftrag gearbeitet? _______________________ B 4 Wie lange haben Sie ungefähr gebraucht, um das Problem zu beheben? _______________________      B 5 AA_Stör Schon bei der ersten Bearbei- tung meines Arbeitsauftrages wusste ich nicht, wie ich verfah- ren sollte. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      B 6 Kennt_Lö Mir war beim Auftreten des Problems der Lösungsweg so- fort klar. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      B 7 AA_Stör Die ersten Schritte der Bearbei- tung meines Arbeitsauftrages liefen noch gut, bis ein unerwar- tetes Problem in Form einer Störung auftrat. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      B 8 Kennt_Lö Ich wusste beim Auftreten des Problems nicht mit welchem Lösungsweg ich meinen Ar- beitsauftrag erfüllen konnte. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu 165      B 9 AA_Stör Wäre kein ungeplantes Problem in meinem Arbeitsprozess auf- getreten, hätte ich meinen Ar- beitsauftrag problemlos zu Ende führen können. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      B 10 Kennt_Lö Das Problem bestand unter an- derem darin, dass ich den Lö- sungsweg nicht kannte. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      B 11 AA_Stör Das Problem bestand schon als ich meinen Arbeitsauftrag ange- fangen habe zu bearbeiten. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu C Fragen zum Arbeitsauftrag und dem Problem Im folgenden finden Sie weitere Fragen, die sich auf die von Ihnen abgegebenen Beschrei- bungen (Seite 5) zu Arbeitsauftrag und Problem beziehen. Sie sind in mehrere thematische Blöcke unterteilt. Beantworten Sie diese immer unter Berücksichtigung Ihre Beschreibungen. Bitte achten Sie darauf, die beiden Begriffe Arbeitsauftrag und Problem immer klar voneinan- der zu trennen. Kreuzen Sie bei den Fragen jeweils die Zahl der ausgewählten Antwortstufe in der rechten Spalte der Tabelle an, die Ihrer Meinung nach am ehesten zutrifft. Durch die ersten Fragen wollen wir einen Eindruck bekommen, wie die Voraussetzungen Ihres Arbeitsauftrages aussahen, z.B. ob Sie genügend Freiraum hatten oder ob das Ziel klar ver- mittelt wurde.      C 1 Handlsp Wenn ich die Tätigkeit meines Arbeitsauftrages insgesamt be- trachte, konnte ich die Reihen- folge meiner Arbeitsschritte selbst bestimmen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 2 Handlsp Ich hatte Einfluss darauf, dass mir dieser Arbeitsauftrag zuge- teilt wurde. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 3 Handlsp Ich konnte die Arbeit bei mei- nem Arbeitsauftrag selbständig planen und einteilen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu 166      C 4 Kennt_Zi Ich wurde über das Ziel meines Arbeitsauftrages in Kenntnis gesetzt. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 5 Me_Zi Durch meinen Arbeitsauftrag sollte ich gleichzeitig mehrere Ziele verfolgen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 6 Verst_Zi Mir war klar, welches Ziel ich durch meinen Arbeitsauftrag verfolge. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 7 Transp Es standen mir genügend In- formationen über die Aus- gangsbedingungen meines Ar- beitsauftrages zur Verfügung. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 8 Kennt_Zi Als mir mein Arbeitsauftrag ü- bertragen wurde, habe ich das Ziel nicht gekannt. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 9 Me_Zi Durch meinen Arbeitsauftrag sollte ich gleichzeitig mehrere Ziele verfolgen, die sich gegen- seitig widersprechen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 10 Verst_Zi Ich habe meinen Arbeitsauftrag übernommen ohne wirklich zu wissen, worauf er hinauslaufen soll. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 11 Kennt_Zi Ich kannte das Ziel meines Ar- beitsauftrages. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 12 Me_Zi Ich musste bei der Bearbeitung meines Arbeitsauftrages gleich- zeitig noch andere Arbeitsauf- träge bearbeiten. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 13 Verst_Zi Es war mir nicht klar, welches Ziel ich mit meinem Arbeitsauf- trag verfolgen sollte. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu 167      C 14 Transp Es standen mir genügend In- formationen über das Ziel mei- nes Arbeitsauftrages zur Verfü- gung. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu Die nun folgenden Fragen beziehen sich darauf, welche Form von Wissen Sie bei der Bear- beitung Ihres Arbeitsauftrages verwendet haben und welches Wissen Ihnen im Umgang mit Ihrem Problem geholfen hat.      C 15 Vorerf Es kam schon häufiger vor, dass ein unerwartetes Problem meinen Arbeitsprozess unter- bricht. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 16 Hiwi_Fa Mein Arbeitsauftrag fiel in mei- nen fachlichen Aufgabenbe- reich. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 17 Hiwi_Me Wenn ich allgemein vor einem Problem stehe, habe ich keine bestimmte Strategie, die ich verfolge, um zu einer Lösung zu kommen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 18 Hiwi_Soz Es macht mir Spaß, mit ande- ren Menschen zusammenzuar- beiten. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 19 Vorerf Das Problem ist in ähnlicher Weise bereits schon mal aufge- treten. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 20 Hiwi_Fa Ich hatte zur Bearbeitung mei- nes gesamten Arbeitsauftrages alle notwendigen Fachkennt- nisse. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 21 Hiwi_Me Bei Problemen plane und or- ganisiere ich meist meine Handlungen, um zu einem Er- gebnis zu kommen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 22 Hiwi_Soz Der Umgang mit anderen Men- schen fällt mir leicht. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu 168      C 23 Vorerf Ich konnte davon profitieren, dass es das aufgetretene Prob- lem in ähnlicher Weise schon einmal gab. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 24 Vorerf Das Problem war so neuartig, dass mir keine Lösung eines bereits aufgetretenen Problems weiterhelfen konnte. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 25 Wissgen Das Wissen, das ich selbst hatte, hat ausgereicht, um das Problem beheben zu können. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 26 Wissgen Um zur Arbeitsauftragserfül- lung zu kommen hat mein ei- genes Wissen nicht ausge- reicht, ich musste mir Informa- tionen von außen holen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu Wenn ja, nutzte ich dabei folgende Quellen:  Bücher  Internet  Andere Personen  Andere: ___________________________      C 27 Wissgen Selbst mein eigenes Wissen und Informationen von außen reichten nicht aus, zur Arbeits- auftragserfüllung zu kommen. Es war notwendig völlig neue Erkenntnisse zu gewinnen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu Wenn ja, gewann ich diese neuen Erkenntnisse:  Durch meine eigene Initiative  Mit der Hilfe anderer      C 28 Prob_Fa_ Wi Als das Problem auftrat hat mir mein fachliches Wissen (aus meiner Ausbildung und meiner Arbeitserfahrung) etwas ge- bracht. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 29 Prob_Me _Wi Als das Problem aufgetreten ist, wusste ich was ich zu tun hatte, um zum Lösungsweg zu kommen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu 169      C 30 Prob_Soz _Wi Als ich vor dem Problem stand, habe ich mir Hilfe durch andere Personen besorgt. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 31 Prob_Fa_ Wi Durch Wissen aus meiner Aus- bildung und Arbeitspraxis wusste ich besser, wie ich mit dem aufgetretenen Problem umgehen sollte. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 32 Prob_Me _Wi Als das Problem auftrat war ich ratlos und wusste nicht, was ich tun soll. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 33 Prob_Soz _Wi Die Zusammenarbeit mit ande- ren hat mir geholfen, das Prob- lem anzugehen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 34 Prob_Fa_ Wi Meine Ausbildung und Arbeits- praxis hat mich mit Wissen zu dem Problembereich ausges- tattet. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 35 Prob_Me _Wi Als das Problem entstand, hat- te ich geeignete Verfahren, um an einen adäquaten Lösungs- weg zu kommen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 36 Prob_Soz _Wi Um das Problem zu beheben, habe ich mit niemandem dar- über geredet, sondern habe lieber selber nach einer Lösung gesucht. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu Der nachfolgende Fragenblock konzentriert sich darauf, zu erfahren, ob Unklarheiten bei der Problembearbeitung vorlagen und welche Form von Informationen (mündlich oder schriftlich) Sie zur Behebung des Problems verwendet haben.      C 37 Wissint Ich hatte Schwierigkeiten da- mit, zu verstehen, worum es bei dem Problem geht. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu 170  Ja C 38 Wissint Zur Behebung des Problems arbeitete ich mit Kollegen aus anderen Fachbereichen.  Nein      Wenn ja, dann haben wir uns gut auf ein gemeinsames Ver- ständnis des Problems einigen können. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      Wenn ja, ist mir aufgefallen, dass es schwierig war einen gemeinsamen Konsens über das Problem selbst zu finden. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      Wenn ja, hatten wir das gleiche Verständnis, wie das Problem behoben werden könnte. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 39 Komm Ich habe mich mit meinem Vor- gesetzten viel über das Prob- lem unterhalten. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 40 Infokoord Ich hatte ausreichende schriftli- che Information zum besseren Verständnis des Problems zur Verfügung. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 41 Komm Ich habe mit meinen Kollegen viele Diskussionen über das Problem geführt. . trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 42 Infokoord Zum besseren Verständnis des aufgetretenen Problems zog ich schriftliche Informationen heran. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu Wenn ja, bezog ich diese schriftlichen Informationen zu meinem Arbeitsauftrag aus:  Datenbanken  Emails  Schriftstücken  Intranet/Internet  Einer anderen Informationsquelle: _________________________ 171      C 43 Infokoord Die Informationen, die ich durch oben genannte Informa- tionsquellen bezogen habe, reichte nicht zur Erfüllung mei- nes Arbeitsauftrages aus. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 44 Komm Als das Problem aufgetreten ist, habe ich mit anderen dar- über geredet. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu Im letzten Fragenblock des Abschnitts C geht es um den Zustand des Arbeitsauftrages bzw. des Problems. Durch Ihre Angaben zu den Fragen wollen wir einen Eindruck darüber bekom- men, wie man Ihren Arbeitsauftrag bzw. Ihr Problem konkreter beschreiben könnte, z.B. ob es komplex war oder ob Sie den Arbeitsauftrag selbst oder mit anderen bearbeitet haben.      C 45 Komplex Mein Arbeitsauftrag war sehr komplex, da er mit vielen ande- ren Aspekten zusammenhing. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 46 Komplex Mein Problem war dadurch gekennzeichnet, dass ich bei der Ausführung des Arbeitsauf- trages viele Dinge gleichzeitig berücksichtigen musste. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 47 Komplex Um meinen Arbeitsauftrag zu erfüllen musste ich viele damit zusammenhängende Dinge berücksichtigen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 48 Transp Es standen mir genügend In- formationen darüber zur Verfü- gung, wie ich mein Problem beheben könnte. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 49 Bek_Res Als das Problem aufgetreten ist, wusste ich nicht, welche Mittel ich habe, um es anzuge- hen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 50 Prod_Pro z Das aufgetretene Problem ent- stand aus dem Arbeitsablauf heraus. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu 172      C 51 Dynam Eine Schwierigkeit des Prob- lems war, dass es sich über eine gewisse Zeit auch ohne meinen Einfluss verändert hat. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 52 Abstr Das Problem war ganz eindeu- tig zu beschreiben. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 53 Ind_Koll Zur Behebung des Problems war die Zusammenarbeit mit anderen notwendig. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 54 Zeitdr Ich konnte mir bei der Bearbei- tung des Problems so viel Zeit nehmen wie nötig. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 55 Bek_Res Es fehlte mir die Kenntnis über die Mittel, die ich hatte, das Problem zu beheben. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 56 Prod_Pro z Das aufgetretene Problem war fachlicher/technischer Art. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 57 Prod_Pro z Das Problem entstand aufgrund einer Fehlerhaftigkeit im Ar- beitsablauf. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 58 Dynam Nach meiner Einschätzung könnte sich das Problem bei nochmaligem Auftreten durch äußere Bedingungen verändert haben. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 59 Abstr Das Problem kann ich nicht als abstrakt bezeichnen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 60 Ind_Koll Die Bearbeitung des Problems funktionierte besser durch Gruppenarbeit. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu 173      C 61 Zeitdr Die Behebung des Problems konnte ich in Ruhe angehen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 62 Bek_Res Mir war klar, welche Mittel mir zur Verfügung stehen, um zur Arbeitsauftragserfüllung zu kommen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 63 Prod_Pro z Das Problem entstand direkt aufgrund technischer Ursa- chen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 64 Dynam Das Problem ist auch daher aufgetreten, dass äußere Um- stände nicht mehr so waren wie am Anfang des Arbeitsauftra- ges. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 65 Abstr Das Problem war nur schwer erkennbar. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 66 Ind_Koll Das Problem verlangte Zu- sammenarbeit mit Anderen. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      C 67 Zeitdr Bei der Bearbeitung des Prob- lems stand ich unter Zeitdruck. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu 174 D Fragen zu Problemlöseprozessen Die Fragen des nächsten Abschnitts sollen uns einen konkreteren Eindruck darüber vermit- teln, wie Sie mit Ihrem beschriebenen Problem umgegangen sind. Bitte beantworten Sie auch diese Fragen immer unter dem Gesichtspunkt der von Ihnen abgegebenen Beschreibungen über das Problem in Form einer Störgröße. Kreuzen Sie jeweils die Zahl der ausgewählten Antwortstufe in der rechten Spalte der Tabelle an, die Ihrer Meinung nach am ehesten Ihrer Situation entspricht. Zum einen zielen die Fragen darauf ab, von Ihnen einen Eindruck über die Entscheidungs- möglichkeiten bei der Problemlösung zu bekommen und zum anderen welchen zeitlichen Rahmen Sie für die Problemlösung zur Verfügung hatten.      D 1 Freiheitsg Ich konnte selbst entscheiden, wie ich bei dem Problem vor- gehe. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      D 2 Freiheitsg Zur Lösung des Problems wur- de mir genau vorgegeben was ich tun soll. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      D 3 Freiheitsg Ich konnte selbst wählen, wel- che Lösungsvariante für das Problem am besten war. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu      D 4 Freiheitsg Zur Erfüllung meines Arbeits- auftrages hatte ich sehr viele Freiheiten. trifft überhaupt nicht zu trifft weniger zu trifft teils/teils zu trifft ziemlich zu trifft ganz genau zu  ja Zur Lösung des Problems hatte ich nur kurz Zeit.  nein D 5 Zeithor Wenn ja, betrug sie ca. __________.  ja Für die Lösung des Problems hatte ich mittelfristig Zeit.  nein D 6 Zeithor Wenn ja, betrug sie ca. __________.  ja Für die Lösung des Problems hatte ich langfristig Zeit.  nein D 7 Zeithor Wenn ja, betrug sie ca. __________. Wir bedanken uns für Ihre freundliche Unterstützung! 175 Damit wir Ihnen die Ergebnisse der Studie zusenden können, bitten wir Sie, uns Ihre Visiten- karte mitzusenden oder Ihren Namen und Ihre Anschrift hier zu vermerken. Diese Angaben werden selbstverständlich unabhängig von den Fragebogendaten und streng vertrau- lich behandelt. Dieser Fragebogen wurde bearbeitet von: Herrn/Frau Firmen-Adresse/Firmen-Stempel Telefon Telefax E-Mail 10.2 Ergebnisse der Umfrage zum Problembeschreibungsmodell Die Reliabilitäten der Skalen sind sehr gemischt. Darunter sind sechs Skalen, die aufgrund mangelnder Reliabilität (α<,60) aus der Untersuchung ausgeschlossen wurden. Dies sind die Skalen zu den Problemkategorien Kenntnis des Ziels (Kategorie 4), mehrere/widersprüchliche Ziele (Kategorie 6), Informationskoordination (Kategorie 10), Technisch/fachliches Problem vs. Managementproblem (Kategorie 12), Abstraktheit (Kategorie 15) und Hintergrundmethoden- wissen (Kategorie 24). Alle Skalen mit einem Cronbach’s Alpha von >,60 wurden in die Untersuchung einbezogen. Bei manchen Skalen ließ sich die Reliabilität durch Itemausschluss erhöhen. In der folgenden Tabelle werden die Reliabilitäten der einzelnen Skalen dargestellt. Problemkategorie Nummer der Kate- gorie Reliabilität nach Cronbach’s Alpha Handlungsspielraum 3 α=,79 Klarheit des Ziels 5 α=,65 Transparenz über Ausgangsbedingungen und Ziel 7 α=,71 Wissensintegration 8 α=,78 bei Ausschluss von Item C37 Kommunikation 9 α=,72 Bekanntheit der Ressourcen 11 α=,87 Komplexität 13 α=,86 Dynamik 14 α=,76 Individuelle vs. kollektive Problemlösung 16 α=,85 Zeitdruck 17 α=,82 Vorerfahrung 18 α=,87 bei Ausschluss von Item C15 Wissensgenerierung 19 α=,92 bei Ausschluss von Item C27 Problembezogenes Fachwissen 20 α=,72 Problembezogenes Methodenwissen 21 α=,69 Problembezogenes Sozialwissen 22 α=,78 Hintergrundfachwissen 23 α=,78 Hintergrundsozialwissen 25 α=,93 Freiheitsgrade 26 α=,83 Tabelle 16: Reliabilitäten der Skalen Bevor die Hypothesen im einzelnen getestet werden, werden die Fragen näher betrachtet, die mehrere Antwortalternativen hatten. Die Frage C26 fragt danach, ob das eigene Wissen zur Auftragserfüllung ausgereicht hat und wenn nicht, welche Quellen zur Informationsbeschaf- fung genutzt wurden. Einige Teilnehmer kreuzten mehrere Antwortalternativen an. Sieben Teilnehmer geben an, Bücher zur Informationsbeschaffung genutzt zu haben, sieben nennen das Internet, 16 geben an, andere Personen genutzt zu haben und einer gibt an, Kolle- gen/Experten gefragt zu haben. Die Frage C27 geht einen Schritt weiter und fragt die Teil- nehmer, ob neue Erkenntnisse zur Arbeitsauftragserfüllung notwendig waren. Dabei gaben sieben Personen an, durch eigene Initiative zu neuen Erkenntnissen gekommen zu sein, sie- ben gaben an, mit der Hilfe anderer zu neuen Erkenntnisse gelangt zu sein. Die Frage C42 beschäftigt sich damit, welche schriftlichen Informationen die Personen zum besseren Ver- 177 ständnis des Problems verwendet haben. Drei Personen geben an Datenbanken verwendet zu haben, sieben nennen Emails, sieben Schriftstücke, drei das Intranet/Internet, einer ein Lehrbuch und einer das Kundengespräch. Die Faktorenanalyse mit Varimax-Rotation ergibt insgesamt sechs voneinander unabhängige Faktoren. Insgesamt klären diese eine Varianz von 84% auf: der erste Faktor 19%, der zweite Faktor 16,7%, der dritte Faktor 16,6%, der vierte Faktor 12%, der fünfte Faktor 10,7% und der sechste Faktor 9,4%. Dies wird durch die Tabelle 17 dargestellt. 4,574 25,410 25,410 4,574 25,410 25,410 3,433 19,070 19,070 3,680 20,443 45,853 3,680 20,443 45,853 3,009 16,719 35,789 2,373 13,186 59,038 2,373 13,186 59,038 2,993 16,627 52,416 2,002 11,120 70,158 2,002 11,120 70,158 2,164 12,021 64,437 1,494 8,300 78,458 1,494 8,300 78,458 1,920 10,665 75,102 1,086 6,036 84,494 1,086 6,036 84,494 1,691 9,392 84,494 ,796 4,422 88,916 ,674 3,746 92,662 ,540 2,998 95,659 ,354 1,966 97,625 ,230 1,276 98,901 ,138 ,768 99,670 ,037 ,205 99,875 ,023 ,125 100,000 1,227E-16 6,819E-16 100,000 -1,30E-16 -7,231E-16 100,000 -2,95E-16 -1,636E-15 100,000 -1,59E-15 -8,825E-15 100,000 Komponente 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Gesamt % der Varianz Kumulierte % Gesamt % der Varianz Kumulierte % Gesamt % der Varianz Kumulierte % Anfängliche Eigenwerte Summen von quadrierten Faktorladungen für Extraktion Rotierte Summe der quadrierten Ladungen Extraktionsmethode: Hauptkomponentenanalyse. Tabelle 17: Erklärte Gesamtvarianz der gewonnenen Faktoren Die Tabelle 17 zeigt die Ladungen der einzelnen Problemkategorien auf den sechs Faktoren. Alle Skalen, die mit >,5 auf den Faktoren laden, werden zu diesem Faktor dazugerechnet. Daher kann die Hypothese 1 bestätigt werden. 178 Rotierte Komponentenmatrixa ,916 ,250 -,108 -,157 ,163 ,067 ,197 ,135 -,518 ,115 -,418 -,554 ,765 ,199 -,319 ,155 ,060 -,323 -,034 -,139 -,050 ,061 -,142 ,912 ,062 ,284 ,112 -,174 ,873 -,073 ,454 ,804 ,107 -,076 ,098 -,212 -,421 ,401 ,580 -,412 ,161 -,010 -,026 -,051 ,905 -,122 ,109 ,004 -,006 ,211 ,902 ,127 -,056 ,035 -,403 ,279 ,086 ,503 -,529 -,062 ,286 ,277 ,156 -,467 ,206 ,508 -,315 -,768 ,192 ,178 ,168 ,079 -,064 ,803 ,309 ,254 ,220 -,030 ,278 ,573 ,033 ,503 ,122 ,278 ,060 -,445 ,503 ,273 ,525 ,082 ,566 ,059 -,399 ,400 ,423 -,143 ,069 -,003 -,022 ,896 -,097 -,024 ,909 ,132 ,193 ,068 -,068 ,129 X_HANDL X_VERZI X_TRANSP X_WIINT X_KOMM X_BEKRES X_KOMPL X_DYNAM X_INDKO X_ZEITDR X_VORERF X_WIGEN X_PROBFA X_PROBME X_PROBSO X_HIWIFA X_HIWISO X_FREIH 1 2 3 4 5 6 Komponente Extraktionsmethode: Hauptkomponentenanalyse. Rotationsmethode: Varimax mit Kaiser-Normalisierung. Die Rotation ist in 20 Iterationen konvergiert.a. Tabelle 18: Rotierte Komponentenmatrix Welche Problemkategorie zu welchem Faktor gehört und mit welcher Ladung, wird in der fol- genden Tabelle übersichtlich dargestellt: Faktor Problemkategorie Ladung 1 Handlungsspielraum Transparenz Hintergrundfachwissen Freiheitsgrade ,916 ,765 ,566 ,909 2 Bekanntheit der Ressourcen Wissensgenerierung Problembezogenes Fachwissen Problembezogenes Methodenwissen ,804 -,768 ,803 ,573 3 Verständnis des Ziels Komplexität Dynamik Kollektive Problemlösung Problembezogenes Sozialwissen -.518 ,580 ,905 ,902 ,503 4 Zeitdruck Problembezogenes Methodenwissen Hintergrundsozialwissen ,503 ,503 ,896 179 Faktor Problemkategorie Ladung 5 Kommunikation Zeitdruck Problembezogenes Sozialwissen ,873 -,529 ,525 6 Verständnis des Ziels Wissensintegration Vorerfahrung -,554 ,912 ,508 Tabelle 19: Faktoren, Problemkategorie und Ladung Welche Korrelationen zwischen den Problemkategorien signifikant sind, zeigt die Tabelle 20. Korrelation Korrelation Handlungsspielraum  Transparenz ,733** Bekanntheit der Ressourcen – Problembez. Sozialwissen -,496* Handlungsspielraum - Bekanntheit der Ressourcen ,602** Bekanntheit der Ressourcen – Hin- tergrundfachwissen ,474* Handlungsspielraum – Wissensgene- rierung -,490* Bekanntheit der Ressourcen – Frei- heitsgrade bei Problemlsg. ,484* Handlungsspielraum – Hintergrund- fachwissen ,594** Komplexität – Dynamik ,502* Handlungsspielraum – Freiheitsgrade bei Problemlsg. ,727** Komplexität – Hintergrundfachwis- sen -,494* Verständnis der Ziele – Dynamik -,479* Dynamik – Hintergrundfachwissen -,455* Transparenz – Bekanntheit der Res- sourcen ,437* Kollektive Problemlösung – Wis- sensgenerierung ,580** Transparenz – Hintergrundfachwis- sen ,502* Kollektive Problemlösung – Problembez. Sozialwissen ,799** Transparenz – Freiheitsgrade bei Problemlösung ,460* Kollektive Problemlösung – Hinter- grundfachwissen -,506* Kommunikation – Kollektive Problem- lösung ,587** Wissensgenerierung - Problembez. Fachwissen -,464* Kommunikation – Problembez. Sozi- alwissen ,671** Wissensgenerierung – Problembez. Sozialwissen ,672** Bekanntheit der Ressourcen – Wis- sensgenerierung -,855** Wissensgenerierung – Hintergrund- fachwissen -,436* Bekanntheit der Ressourcen – Problembez. Fachwissen ,574** Problembez. Fachwissen – Problembez. Methodenwissen ,589** Bekanntheit der Ressourcen – Problembez. Methodenwissen ,498* Hintergrundfachwissen – Freiheits- grade bei Problemlsg. ,492* .** Die Korrelation ist auf dem Niveau von 0,01 (2-seitig) signifikant. .* Die Korrelation ist auf dem Niveau von 0,05 (2-seitig) signifikant. Tabelle 20: Signifikante Korrelationen der Problemkategorien 180 10.3 Funktionale Anforderungen zur softwaretechnischen Realisierung der Phasen im Problemlösungsprozess 10.3.1 Problemerfassung: Der Anwender (Problem Owner) startet den Problemlösungsassisten manuell (Link). Zur Initialisierung eines Problemlösungsprozesses soll eine Anmeldung des Anwenders erfolgen. Der Anwender gibt eine grobe Problembeschreibung (Textfeld), der Anwender muss das Problem durch strukturierte Dialoge beschreiben. Der Bezug zum Entwicklungsprojekt, in dem das Problem aufgetreten ist, sollte herstellbar sein. Der Nutzer sollte seinen Expertisenstatus angeben können. Der Nutzer kann geschätztes Anfangs- und Enddatum für die Problemlösung eingeben. Zuordnung von Schlüsselwörtern zur Beschreibung der Probleme soll überwiegend automatisch erfol- gen. Neben der Auswahl eines Schlüsselwortes aus einer Schlagwortliste sollte der Nutzer die Möglichkeit haben, neue Schlagworte zu definieren. Der Nutzer benötigt die Möglichkeit eine Volltextsuche zu starten. 10.3.2 Lösungssuche Der Anwender nutzt ein Recherchetool (Suchmaschine) für die Suche nach bereits bekannten Lösun- gen. Jedes gesichtete Suchergebnis muss bewertet werden. Die Beschreibungsmerkmale dienen gleichzeitig als Kriterien einer Suche in der Wissensbasis nach ähnlichen Problembeschreibungen Dem Nutzer werden die automatisch gefundenen ähnlich gelagerten Probleme bzw. Lösungen angebo- ten. Dem Nutzer können auch Kontakte zu Fachkräften angeboten werden, die in der Vergangenheit ähnli- che Situationen gemeistert haben oder fachlich kompetent erscheinen. Der Nutzer kann geschätztes Anfangs- und Enddatum für die Phase eingeben. Der Anwender erhält eine Checkliste, die Fragen zur Durchführung der Suche beinhaltet. Der Anwender benötigt ein Textfeld zur Dokumentation der Erfahrungen und Ergebnisse der Phase. Der Problem Owner sollte einen Ansprechpartner angeben können, der die Problemlösung als Prob- lemprozesskoordinator inhaltlich weiter betreut und zur Lösung führt. Das Problemticket mit ausgefüllten Phasen (Problemerfassung, Lösungssuche) wird automatisch an den Problem Manager geschickt, der über die Freigabe und den vorgeschlagenen Problemprozessko- ordinator entscheidet. 10.3.3 Situationsanalyse, Lösungsentwicklung, Lösungsverifizierung, Lösungsumset- zung Der PLA erhält einige Basis-Methoden, die der Anwender optional ansteuern kann. Je nach Paketum- fang sind weitere Methoden (inkl. Werkzeug) möglich. Werkzeuge (Templates) im Teilprozess sollen abgebildet und integriert werden. Die Werkzeuge sollen in ihrer Anzahl skalierbar sein. Der Nutzer benötigt die Möglichkeit, die ausgefüllten Templates als Dokumente dem Problemlösungsti- 181 cket anzuhängen. Dem Nutzer können auch Kontakte zu Fachkräften angeboten werden, die in der Vergangenheit ähnli- che Situationen gemeistert haben oder fachlich kompetent erscheinen. Die Eingabe des Bearbeiters ist erforderlich. Der Nutzer kann geschätztes Anfangs- und Enddatum für die Phase eingeben. Der Anwender erhält eine Checkliste, die Fragen zur Durchführung der Phase beinhaltet. Der Anwender benötigt ein Textfeld zur Dokumentation der Erfahrungen und Ergebnisse der Phase. 10.4 Abbildung der Problemlösungsphasen im Problemlösungsassistenten (Problem- ticket) 10.4.1 Problemerfassung Text für die Phase „Problemerfassung“: Sie befinden sich in der Phase der Initialisierung einer Problemlösung. Das Ziel dieser Phase ist die Erfassung und Dokumentation des vorliegenden Problems sowie dessen Kontext. Dazu ist es erforderlich, folgendes Problemticket auszufüllen. Bitte beschreiben Sie nachfolgend das Problem und den Zusammenhang, in welchem es aufgetreten ist: (Felder Titel, Beschreibung) In welchem Fach- bzw. Themenbereich ist das Problem aufgetreten? (Feld: Themenbereich) Wie schätzen Sie ihren Expertiselevel bezüglich des aufgetretenen Problems ein? (Feld: Experte, Erfahren, Inte- ressiert) Bezieht sich das Problem auf einen Prozessablauf oder ein konkretes Produkt bzw. eine Produktkomponente? (Feld: Produkt-Prozessspezifisch) Im Rahmen welches Projekts ist das Problem aufgetreten? (Feld Projekt) Möchten Sie nun eine Suche starten? Dann klicken Sie bitte auf „Suche starten“. Möchten Sie in die nächste Phase gelangen? Dann klicken Sie bitte auf „weiter“. Gehen Sie in das Menü „Werkzeuge“ auf der linken Seite und klicken Sie auf „Eintrag bearbeiten“ Feld Typ Beschreibung Titel* Textfeld Title des Problemes Problembeschreibung* HTML- Editor Beschreibung des Problemes Beziehung Radio Auswahl: Produkt/Prozess Expertiselevel Radio Auswahl: Experte, Erfahren, Interessiert Projekt* Textfeld Bezug zum Projekt Start-Termin Datumsfeld Start des Problemprojektes End-Termin Datumsfeld Ende des Problemprojektes Tabelle 21: Initialisierung Eingabefelder (* Pflichtfelder) Nach der Initialisierung wird das Problemticket gespeichert und die Suche wird geöffnet. Dabei ist der Suchstring vorinitialisiert: Der Titel und die Schlagworte sind bereits im Feld:Suchstring voreingetragen. 182 Wir hatten hier einiges diskutiert, was passiert, wenn er keine Suche starten will sondern direkt im Reiter „Lösungssuche“ Dateien auswählen möchte? Wie kommt er da rein? 10.4.2 Lösungssuche Texte für die Phase „Lösungssuche“: Sie befinden sich nun in der Phase der Lösungssuche. Im Rahmen dieser Phase überprüfen Sie, inwieweit das aktuelle Problem in gleicher oder ähnlicher Form bereits in der Vergangenheit aufgetreten ist und wie es bearbeitet und gelöst wurde. Ziel ist es, bereits bestehende Problemdokumentationen zu identifizieren, die dem vorliegenden Problem möglichst ähnlich sind. Bitte bewerten Sie nachfolgend, ob ähnliche Lösungen gefunden wurden und in wie weit diese auf das vorliegende Problem übertragbar sind bzw. die Möglichkeit besteht, die Lösungen entsprechend anzupassen. (Feld: Ergebnis- se) Bitte fügen Sie nun die gefundenen Lösungen ein: (Feld Verknüpfungen) Folgende Checkliste hilft Ihnen dabei zu überprüfen, ob alle wichtigen Fragestellungen berücksichtigt wurden. Sie dient gleichzeitig als Leitfaden für die abschließende Dokumentation dieser Phase (Dokumentationsfeld). Checkliste: − Ist das Problem bereits schon einmal in ähnlicher Form aufgetreten? − Wenn ja, in welcher Form und in welchem Zusammenhang ist es aufgetreten? − Wie erfolgte die Lösung des Problems (Vorgehensweise)? − Wurde ein FMEA-Check durchgeführt? − Welche Informationsquellen wurden überprüft?  eigene Datenbestände (e.g. Projektdokumentation, Fileserver, etc.)  eine internen Problemdatenbank (FMEA, etc.)  externe Quellen (Internet, Suchmaschine, etc.) − Falls bestehende Lösungen gefunden wurden:  wo ist Eingriff aufgrund Einfluß möglich?  wo gibt es technische/organisatorische Lösungsmöglichkeiten?  wie dringlich ist Lösungsrealisierung?  wo ist gutes Aufwand/Nutzenverhältnis zu erwarten?  kann eine Abgrenzung Lösungsbereichs (als Teilmenge des Eingriffsbereichs) und des Wirkungsbe- reichs (Bereich in dem durch Lösung Auswirkungen zu erwarten sind) erfolgen?  Wie müsste eine Anpassung der gefundenen Lösung auf die aktuelle Problemstellung aussehen? Wenn Sie die Phase der Lösungssuche abschließen möchten, klicken Sie nun bitte auf weiter. Das Dokument wird nun an den zuständigen Problemprozess Manager weitergeleitet. Textfeld nur für Problemprozess Manager sichtbar: Problemkoordinator Wenn Sie einen Problemkoordinator für das vorliegende Problem bestimmt haben, so klicken Sie bitte auf „Weiter“ Der Problemkoordinator sollte dann per e-mail eine Nachricht bekommen, dass er nun für die Koordination des Problems verantwortlich ist. Ergebnisse aus der Suche werden mittels Zwischenablage zu dem Problemticket verknüpft. 183 Feld Typ Beschreibung Ergebnisse* Radio Auswahl: keine Lösung/ Teillösung/ vollständige Lösung Dokumentation* HTML- Editor Dokumentaionen zu diesen Schritt Verknüpfungen Hier können Verknüpfungen wieder gelöscht werden. Hinweis: hinzufügen geht nicht im Bearbeitenmodus Problemmanager Auswahl einer Person, die die Koordinierung übernehmen soll. Diese Person wird per e-mail benachrichtigt Tabelle 22: Lösungsuche Eingabefelder 10.4.3 Situationsanalyse Diese Phase wird nun vom bestimmten Problemkoordinator weiter bearbeitet. Der Problem Owner, der das Problem zuvor identifiziert und die ersten beiden Phasen bearbeitet hat, hat jedoch nach wie vor Zugriff auf den Vorgang und die Dokumente. Ebenso sollte der Problem- prozessmanager Zugriff auf den Vorgang haben. Er wird vom Koordinator nach jeder Phase über den Stand informiert. Text für die Phase „Situationsanalyse“: Sie befinden sich in der Phase der Situationsanalyse. Ziel dieser Phase ist zum einen, eine sachliche, von Fakten gestützte, logisch argumentierbare, zieloffene, lösungsneutrale Interpretation der Situation zu geben und diese darzustellen. Dies dient als Grundlage für spätere Entscheidungen. Zum anderen erfolgt in der Situationsanalyse die Formulierung von Zielen, welche die Lösungssuche steuern. Bitte führen Sie nun folgende Arbeitsschritte durch:  Definition von Lösungsanforderungen (xls-file: Anforderungskatalog 360Grad_v2.xls) Text: Im Rahmen dieses Schrittes nehmen Sie die Anforderungen an die Problemlösung und skizzie- ren den Idealzustand. Bitte füllen Sie dazu folgendes Excel-Dokument aus. Dieses Formular enthält zudem eine Vorge- hensweise, die Ihnen die Definition der Anforderungen nach dem 360 Grad Prinzip erläutert.  Durchführung einer Detailanalyse (xls-file: Einflußfaktorenanalyse_v2.xls) Text: Im Rahmen der Detailanalyse untersuchen Sie sowohl die Ursachen für das vorliegende Prob- lem als auch mögliche Einflussfaktoren, welche die Lösung des Problems beeinflussen können. Bitte füllen Sie dazu folgendes Excel-Dokument aus. Dieses Formular enthält zudem eine Vorge- hensweise, die Ihnen die Durchführung der Analyse erleichtert.  Formulierung der Ziele für die Problemlösung (xls-file: Zielkatalog_v2.xls) Text: Dieser Schritt dient dazu, die Absichten, die der Lösungsentwicklung zugrunde gelegt werden sollen, genau fest zu halten, diese gegeneinander abzuwägen und zu priorisieren sowie Chancen und Risiken zu ermitteln. Bitte füllen Sie dazu folgendes Excel-Dokument aus. Dieses Formular enthält eine weitere Checklis- te, sie bei der Formulierung der Ziele unterstützt. Um die Vorgänge und Ereignisse zu aggregieren, bitten wir Sie nun abschließend um eine kurze Zusammenfas- sung der wichtigsten Punkte dieser Phase. Die nachfolgende Checkliste soll Ihnen dabei helfen, wesentliche Kern- aussagen festzuhalten. Wichtig ist hierbei eine kurze Bewertung hinsichtlich des Ablaufs sowie eine kurze Be- schreibung des momentanen Stands im Problemlösungsprozess. Checkliste: 184 − Konnten bestehende FMEA-Analysen herangezogen werden? − Wurden die Ursachen analysiert? − Welche wissensorientierten Aspekte konnten als Ursache für das vorliegende Problem identifiziert werden?:  Problem aufgrund mangelnder Wissenskoordination  Problem aufgrund unzureichenden Wissenstransfers bzw. mangelnder -kommunikation  Problem aufgrund mangelnder Wissensintegration − Wurden mögliche Einflußfaktoren untersucht? − Wurden alle Bestandteile der Zielformulierung berücksichtigt (s.a. Checkliste in xls-file. Zielkatalog_v2.xls)?  Zielobjekt (WORAN sind die Ziele gebunden?)  Zieleigenschaften, bzw. Zielinhalte (WAS soll erreicht werden?)  Zielausmaß (WIEVIEL soll erreicht werden?)  Zeitaspekt (WANN soll es erreicht werden?)  Ortsbezeichnung (WO soll es wirksam werden?  Zielverantwortliche(r), Zielformulierungsbeteiligte(r)  Allgemeiner Zieltitel  Zielerreichungskriterien − Welche Schwierigkeiten, Potentiale oder Chancen haben sich bzgl. der Problemlösung ergeben? − Welche Quellen für das Entwickeln von Handlungsansätzen wurden verwendet?  Leitbilder  Vorgaben aus vorangegangenen Untersuchungen  Vergleiche mit ähnlichen Sachverhalten oder Systemen Feld Typ Beschreibung Unterstützende Me- thoden Links zu Excel-Files Es sind verschiedene Exclefiles hinterlegt, die bei der Analy- se unterstützen sollen Hinweis: bearbeitete Dateien müssen erst lokal gespeichert werden und können da per Upload hinzugefügt werden Dokumente Datei Upload der bearbeiteten Exceldateien. Dokumentation* HTML- Editor Dokumentaionen zu diesen Schritt Bearbeiter Text feld Sollte später ein Azswahlfeld sein End-Termin Datumsfeld Ende des Problemprojektes Tabelle 23: Situationsanalyse Eingabefelder 10.4.4 Lösungsanpassung und -entwicklung: Texte für die Phase der Lösungsanpassung und -entwicklung: Sie befinden sich nun in dern Phase der Lösungsanpassung und –entwicklung. Ziel dieser Phase ist es, mögliche Lösungsvarianten für das vorliegende Problem zu generieren. Bitte führen Sie nun folgende Arbeitsschritte durch:  Generieren von alternativen Lösungsvorschlägen (xls-file: Brainwriting Formular_v2.xls, word-file. Methode Brainwriting.doc; Mind-Manager-file Brainwriting Mind Map.mmp) Text: Im Rahmen dieses Arbeitsschrittes werden unter methodischer Anleitung entweder in der Gruppe oder selbst mögliche Lösungen generiert.  Analyse und Bewertung der Lösung ((xls-file: Strukturierung und Analyse der Alternativen_v2.xls) Text: Ziel dieses Schrittes ist die Strukturierung und die systematische Prüfung der Lösungen sowie 185 die Identifikation von Ansatzpunkten zur Verbesserung der Lösungsvorschläge bzw. Argumentatio- nen für deren Ausschluss. Feld Typ Beschreibung Unterstützende Me- thoden Links zu Ex- cel-Files, Links zu Mindmanager- Files Es sind verschiedene Exclefiles hinterlegt, die bei der Lö- sungsanpassung unterstützen sollen Hinweis: bearbeitete Dateien müssen erst lokal gespeichert werden und können da per Upload hinzugefügt werden Dokumente* Datei Upload der bearbeiteten Exceldateien. Dokumentation HTML-Editor Dokumentationen zu diesen Schritt Bearbeiter Text feld Sollte später ein Azswahlfeld sein End-Termin Datumsfeld Ende des Problemprojektes Tabelle 24: Lösungsanpassung Eingabefelder 10.4.5 Lösungsbewertung Im Problemlösungsassistenten wurden die Phase „Lösungsverifizierung und –auswahl“ auf- grund der auf dem Reiter begrenzten Zeichenzahl in „Lösungsbewertung“ umbenannt. Text für die Phase der „Lösungsbewertung“: Sie befinden sich in der Phase der Lösungsbewertung. Die Phase hat die Aufgabe, den Entscheidungsprozess vorzubereiten, indem die entwickelten Lösungsalternativen bewertet werden. Bitte führen Sie nun folgenden Arbeitsschritt aus:  Lösungsbewertung (xls-file: Nutzwertanalyse_v2.xls) Text: Hier erfolgt die Bewertung der Lösungen anhand der in der Situationsanalyse definierten Ziele durch Methode der Nutzwertanalyse Bitte bewerten Sie nun abschließend die Durchführung dieser Phase sowie deren Ergebnisse. Bitte begründen Sie die Auswahl der Lösungsalternative (Dokumentationsfeld). Die nachfolgende Checkliste soll Ihnen dabei helfen, wesentliche Kernaussagen festzuhalten. Feld Typ Beschreibung Dokumentation* HTML- Editor Dokumentationen zu diesen Schritt Bearbeiter Textfeld Sollte später ein Auswahlfeld sein End-Termin Datumsfeld Ende des Problemprojektes Tabelle 25: Lösungsbewertung Eingabefelder 186 10.4.6 Lösungsumsetzung Feld Typ Beschreibung Status Radio Auswahl: offen/erledigt Dokumentation* HTML- Editor Dokumentationen zu diesen Schritt Bearbeiter Text feld Sollte später ein Auswahlfeld sein End-Termin Datumsfeld Ende des Problemprojektes Tabelle 26: Lösungsumsetzung Eingabefelder 10.5 Datenmodell Das Datenmodell, welches dem Problemlösungsassistenten zugrunde liegt, ist in Abbildung 43 dargestellt. 187 cd problemticket ContentObject ContentType::Co_ProblemTicket + m_iRelation: var = 0 + m_iComplexity: var = 0 + m_iResul ts: var = 0 + m_iState: var = 0 + m_iPhase: var = 0 + m_sProject: var = "" + m_sPTEditor: var = "" + m_sPTEditor3: var = "" + m_sPTEditor4: var = "" + m_sPTEditor5: var = "" + m_sPTEditor6: var = "" + m_sPTStart: var = "" + m_sPTEnd: var = "" + m_sEnd2: var = "" + m_sEnd3: var = "" + m_sEnd4: var = "" + m_sEnd5: var = "" + m_sEnd6: var = "" + m_sDoc2: var = "" + m_sDoc3: var = "" + m_sDoc4: var = "" + m_sDoc5: var = "" + m_sDoc6: var = "" + m_i Instance: var = 0 + Co_ProblemTicket(var, var, var, var, var) : var + getAdditionalTable() : var + getAdditionalFields() : var + loadValues(var, var, var) : var + storeValues(var) : var + _createReqTable() : var + _updateReqT able() : var + getSource() : var + setSource(var) : var + getRelation() : var + setRelation(var) : var + getComplexi ty() : var + setComplexity(var) : var + getProject() : var + setProject(var) : var + getPTEditor() : var + setPT Edi tor(var) : var + getPTEditor3() : var + setPT Edi tor3(var) : var + getPTEditor4() : var + setPT Edi tor4(var) : var + getPTEditor5() : var + setPT Edi tor5(var) : var + getPTEditor6() : var + setPT Edi tor6(var) : var + getPTStart() : var + setPT Start(var) : var + getPTEnd() : var + setPT End(var) : var + getEnd2() : var + setEnd2(var) : var + getEnd3() : var + setEnd3(var) : var + getEnd4() : var + setEnd4(var) : var + getEnd5() : var + setEnd5(var) : var + getEnd6() : var + setEnd6(var) : var + getResults() : var + setResul ts(var) : var + getDoc2() : var + setDoc2(var) : var + getDoc3() : var + setDoc3(var) : var + getDoc4() : var + setDoc4(var) : var + getDoc5() : var + setDoc5(var) : var + getDoc6() : var + setDoc6(var) : var + getState() : var + setState(var) : var + getPhase() : var + setPhase(var) : var + getObjectName() : var + getReadViewTemplateArray() : var + handleEvent(var) : var Conf_ContentObject ContentType:: Conf_ProblemTicket + getSubforms() : var + getSubformClass(var) : var + getTaskUserGroup() : var ContentType:: Conf_Subform_Data1v iew + getSubSubForms() : var ContentType:: Conf_Subform_Data2v iew + getSubSubForms() : var ContentType:: Conf_Subform_Data3v iew + getSubSubForms() : var ContentType:: Conf_Subform_Data4v iew + getSubSubForms() : var ContentType:: Conf_Subform_Data5v iew + getSubSubForms() : var FormView ContentType::ProblemTicket_FormView + m_iPhase: var = 1 + m_sPluginRoot: var = "" + m_sPluginT emplateRoot: var = "" + ProblemTicket_FormView(var*, var*, var) : var + setSubforms() : var + getNewSubForm() : var + getLinkList(var) : var SubForm_OptionView ContentType::ProblemTicket_SubForm_OptionView + ProblemT icket_SubForm_OptionView(var*, var*, var) : var + setSubforms() : var + bui ldSubForm(var, var, var) : var ContentType::ProblemTicket_SubForm_Data2View + ProblemTicket_SubForm_Data2View(var*, var*, var) : var + bui ldSubForm(var, var, var) : var + getSubFormElementsArray() : var + getLabelsSubformArray() : var + getSubformT emplateFile() : var + setFormToContent(var*) : var ProblemTicket_Data_Formview ContentType::ProblemTicket_SubForm_DataView + ProblemT icket_SubForm_DataView(var*, var*, var) : var + bui ldSubForm(var, var, var) : var + getSubFormElementsArray() : var + getLabelsSubformArray() : var + getSubformTemplateFi le() : var + setFormT oContent(var*) : var ContentType::ProblemTicket_SubForm_Data3View + ProblemT icket_SubForm_Data3View(var*, var*, var) : var + bui ldSubForm(var, var, var) : var + getSubFormElementsArray() : var + getLabelsSubformArray() : var + getSubformTemplateFi le() : var + setFormToContent(var*) : var ContentType::ProblemTicket_SubForm_Data4View + ProblemTicket_SubForm_Data4View(var*, var*, var) : var + bui ldSubForm(var, var, var) : var + getSubFormElementsArray() : var + getLabelsSubformArray() : var + getSubformTemplateFile() : var + setFormToContent(var*) : var ContentType::ProblemTicket_SubForm_Data5View + ProblemTicket_SubForm_Data5View(var*, var*, var) : var + bui ldSubForm(var, var, var) : var + getSubFormElementsArray() : var + getLabelsSubformArray() : var + getSubformT emplateFile() : var + setFormToContent(var*) : var ContentType::ProblemTicket_SubForm_Data6View + ProblemTicket_SubForm_Data6View(var*, var*, var) : var + bui ldSubForm(var, var, var) : var + getSubFormElementsArray() : var + getLabelsSubformArray() : var + getSubformTemplateFile() : var + setFormT oContent(var*) : var Abbildung 43: Datenmodell des Problemlösungsassistenten Summary The objective of this thesis was to support the distributed solution of knowledge intensive prob- lems in the product development. This comprises individual as well as cooperative aspects of problem solving. This work considers not only the organizational structure and the problem solving process itself. It comprises also the consideration of knowledge and learning proc- esses, which are relevant for problem solving as well as the implementation of a holistic inte- grated problem solving management. Further it was aimed to focus on real, practice-related problems, which occur in the daily work- ing environment of engineers. The problem solving activities were adjusted and aligned to this kind of problems. The objective was achieved by the development of a systematic for the configuration and op- timization of knowledge intensive, cooperative problem solving processes and the prototypic implementation of a problem solving assistant. Therefore the state of the art was analyzed in depth. It was analyzed, whether existing ap- proaches fort he classification of problems correspond to the requirements of the industrial practice. In analogy it was examined, to what extent existing approaches for the prevention of problems, for the problem solving as well as systems for the problem solving match to the de- fined requirements for knowledge intensive, cooperative problem solving processes. Based on the analysis of the state of the art a framework fort he configuration and optimization of knowledge intensive problem solving processes was developed. This includes the develop- ment of a model to describe industrial, practice-related problems, which was empirically vali- dated. This model served as basis for the deduction and definition of the following three design elements: − Organization and coordination of problem solving processes − Communication and knowledge transfer − Knowledge integration and knowledge generation. In order to ease the implementation of the developed approach into the companies, a problem solving assistant as IT-solution was developed and realized. Finally a case study documents the use of the problem solving assistant in the product devel- opment department of an engineering service provider. In cooperation with a development partner 69 problems were fed into the problem solving assistant and then worked on collabora- tively. In principle, this proves the applicability of the systematic, as well as of the problem as- sistant in the product development. It could be shown, that the advantage of the use of the problem solving assistant is high for manufacturing companies. The value added for the companies was as follows: The involved companies achieved time savings through a more efficient problem retrieval as well as a more structured problem solution development. Further the communication could be improved by 189 the high level of interaction during the problem solving process. The systematic procedure had furthermore an impact on the quality improvement. The approach presented in this thesis was designed for the product development in the area of rapid prototyping, however it is also applicable to other areas. For example the problem solving assistant can also be applied in the distribution and customer service. Customer com- plaints and problems can be identified, managed and documented in a structured way. An- other area of application is provided in the software sector, respectively in the second level support. More complex problems, which can not be easily and directly solved by the call center can be managed by using the problem solving assistant. Potential for further development is seen on the one hand with regard to the software support, e.g. semi-automatic support of distributed problem solving processes through dynamic, ad-hoc workflows. It could be also of value to further analyze the evaluation of problems, e.g. through statistic evaluation methods. The research could also be extended in order to develop IT- solutions for routines and constraints, as well as cause-and-effect chains. An intelligent prob- lem solver could support the selection of solution alternatives and the development of suitable solution strategies. Additional research questions refer to social and psychological aspects. The human behavior in the context of problem solving provides a huge field of research. In this context, inter- organizational and intercultural problem solving, considering aspects like motivation and incen- tives, can be mentioned as examples. Lebenslauf Persönliche Daten Geburtsdatum und Ort: 16. Januar 1970, Stuttgart Familienstand: verheiratet Staatsangehörigkeit: deutsch Berufstätigkeit Seit 03/2007 Manager im europäischen Innovationsteam bei der Unterneh- mensberatung A.T. Kearney 12/2001 – 02/2007 Leiterin des Competence Center Rapid Product Development am Fraunhofer Institut für Arbeitswirtschaft und Organisation (IAO), Stuttgart, Mitglied im Führungskreis des Fraunhofer IAO 07/1998 - 11/2001 Wissenschaftliche Mitarbeiterin im Competence Center Rapid Product Development am Fraunhofer Institut für Arbeitswirtschaft und Organisation (IAO), Stuttgart 06/1997 - 06/1999 Wissenschaftliche Mitarbeiterin an der Universität Stuttgart, Insti- tut für Arbeitswissenschaft und Technologiemanagement (IAT), Stuttgart Studium/Ausbildung 03/1991 – 04/1997 Studium des Maschinenwesens an der Universität Stuttgart Hauptfächer: Kunststoffkunde und Technologiemanagement 09/1994 – 04/1995 Auslandsstudium in Großbritannien an der University of London, Queen Mary and Westfield College