Für die Gewinnung neuen Wissens muß aber in einem Entwicklungsprozeß nicht nur das Wissen aus dem Entwicklungsbereich systematisch und planmäßig angewendet werden, sondern das Produkt, das in diesem Prozeß entsteht, muß in sich eine Fülle von Wissen vereinigen, das auf die verschiedensten Stellen und Unternehmensbereiche verteilt ist. Bei der Definition der Anforderungen an das zu entwickelnde Produkt muß das Wissen aus dem Marketing, dem Vertrieb, der Technik, der Fertigungsplanung, dem Finanzwesen, dem Einkauf, der Wartung oder der Produktentsorgung berücksichtigt werden. Bei der Realisierung dieser Anforderungen muß technisches Spezialwissen aus dem Entwicklungsbereich ebenso wie Wissen aus anderen entwicklungsfremden Bereichen sowie das Fremdwissen von z.B. Zulieferern integriert werden. Damit dieser komplexe Prozeß transparent bleibt, ist es erforderlich, daß kontinuierlich Wissen über den Ablauf des Prozesses akquiriert und für seine Steuerung verfügbar gemacht und verarbeitet wird. Mit der vorliegenden Arbeit und dem dabei entwickelten Softwareprototypen soll genau dieser komplexe Prozeß mittels Wissenskondensierung (siehe Kapitel 3.2) unterstützt werden.

Die Wissenskondensierung kann durch den Einsatz von Methoden entlang des Produktentstehungsprozesses strukturiert erfolgen. Es muß erreicht werden, daß die Projektmitarbeiter durch den Einsatz der Methoden nicht zusätzlich belastet werden, sondern die Anwendung als sinnvolles Hilfsmittel erlebt wird.

Die Formalisierung des Produktplanungsprozesses bei Anwendung von z.B. Quality Function Deployment führte bisher häufig auch dazu, daß sich der Anwender einem starr vorgegebenen methodischen Rahmen gegenübersah, indem unkonventionelle aber bewährte Vorgehensweisen keinen Platz fanden. Sie ist deshalb mitverantwortlich für die mangelnde Akzeptanz und das Scheitern vieler QFD–Vorhaben.

Es wird also deutlich, daß viele QM–Probleme ihren Ursprung im Mißmanagement des Faktors Information haben. In der modernen Informationsgesellschaft gruppieren sich derartige Probleme meist um die Begriffe Wissen und Informationsaustausch:

Die genannten Defizite lassen sich auf ein Grundproblem zurückführen: Mangelnde Integration in einem übergreifenden System zur Unterstützung der QM – Aufgaben. Dabei ist mangelnde Integration in verschiedener Hinsicht zu verstehen:

Keines der diskutierten Konzepte behandelt das Problem so umfassend, daß von einem wirklichen Durchbruch gesprochen werden kann. Mit dem in dieser Arbeit vorgestelltem Konzept sollen dazu wichtige Bausteine geliefert werden, um den bisherigen Defiziten begegnen zu können. Daher zunächst im folgenden Kapitel 3.2 die klar und vollständig formulierte Zielsetzung und Aufgabenstellung.

Das in Kapitel 1.2 knapp formulierte Ziel soll nach den zusammengefaßten Erkenntnissen der Situationsanalyse (Kapitel 3.1) nun konkretisiert werden.

Ziel sollte es sein, das Produktentwicklungsteam mit Hilfe der Informations- und Kommunikationstechnik in der Weise bei der Produktplanung und Produktentwicklung zu unterstützen, daß das durch Methodeneinsatz strukturierte Wissen zum richtigen Zeitpunkt und am richtigen Ort zur Verfügung steht. Es muß also aus dem System der Informations- und Kommunikationstechnik eine Steuerung des geschaffenen Wissens im Projektgeschehen, eine integrierte Methodenunterstützung sowie die umfassende Organisation der Arbeitspakete des Projektes möglich sein.

Darüber hinaus sollte das Team durch sinnvolle Bereitstellung von bereits abgelegtem Erfahrungswissen aus abgeschlossenen Projekten lernen können. Als Basisstruktur sollte zur Sicherstellung der Eindeutigkeit das zu konstruierende Produkt dienen. Die Systemanalyse des Produktes sollte jedoch auch bereits vor der ersten Konstruktion in einem CAD-System darstellbar sein, und im Laufe des Produktentstehungsprozesses durch die geometrische Repräsentation aktualisiert sowie vervollständigt werden.

Unter Wissen soll dabei nicht die Verwaltung von Dokumenten und deren Metadaten verstanden werden, wie sie moderne Produktdatenmanagement-Systeme oder Produktionsplanungs- und –steuerungs Systeme verwalten. Hier werden in der Regel lediglich Attribute der Dokumente als formatierte Datensätze mit Hilfe der Datenbank gespeichert. Eine Wissensstrukturierung der in den Dokumenten enthaltenen Informationen erfolgt nicht, so daß ausschließlich ein Dokumentenmanagement aber kein Wissensmanagement, wie in Kapitel 1.2 gefordert, erfolgt.

Kern der Arbeit wird also die Realisierung eines Softwaresystems zur Steuerung der integrierten methodenunterstützten Produktplanung und Produktentwicklung sein. Im Laufe der Entwicklung des Konzeptes wurde diesem Softwareprototypen der Name "Q-Step" gegeben, der auch im Rahmen dieser Dissertation benutzt wird. Das Q in Q-Step steht dabei für die Unterstützung der sicheren Qualitätszielerreichung und mit Step in Q-Step soll auf die enge Anbindung an die Produktmodelldaten, die jedoch aufgrund der fehlenden Normierung in Richtung qualitätsrelevanter Informationen unter STEP noch nicht standardisiert wurden, hinweisen. Außerdem soll Step auch den kontinuierlichen Schritt zu einer ständigen Verbesserung in der Produktentwicklung, der unterstützt wird, andeuten.

Der Methodenverbund sowie die Methodenintegration mit Hilfe von Q-Step soll durch sogenannte Informationsobjektklassen und notwendige Verknüpfungstypen realisiert werden (Kapitel 4.1). Dabei sollen durch Analyse der Methoden erforderliche Informationsobjektklassen einer Methode gefunden werden, wodurch die so geschaffenen Wissensinhalte einer Methode grundsätzlich auch immer für andere Methoden zur Verfügung stehen. Methodenverbund bedeutet dabei zunächst, einen inhaltlich sinnvollen Verbund zwischen den betrachteten Methoden zu schaffen. Die Methodenintegration ist schließlich die Verwirklichung der Verbindung zwischen den Informationsobjektklassen und den Produktmodelldaten eines volumenorientierten CAD-Systems. Der Ansatz besteht also darin, durch Informationsobjektklassen prinzipiell alle denkbaren Methoden langfristig abbilden zu können, diese in einem Software-System zu integrieren und damit keinerlei Schnittstellenprobleme aus technischer sowie kultureller Sicht zu haben.

m Rahmen der Erarbeitung des in Kapitel 4 vorgestellten Konzeptes wird der knapp beschriebene Ansatz ausgeführt. Der Grund für die Wahl genau dieses Weges ist, daß Versuche, die Idee in bisher kommerziellen Produkten wie PPS - SAP R/3, PDMS – CADIM/EDB von Eigner & Partner oder auch Expertensystemen wie enginObject von camos. darzustellen, zu konfigurieren oder sogar zu programmieren, fehlgeschlagen waren. In Kapitel 7 soll diese Begründung mit einer zusammenfassenden Beschreibung des grundsätzlich neuen Ansatzes von Q-Step abgerundet werden.

Durch Einsatz von Q-Step im Geschäftsprozeß der Produktentwicklung soll also eine Kondensierung des Wissens an dem Produkt selbst stattfinden. An der Metapher der Abbildung 3-1 soll dieses verdeutlicht werden.

Der Kunde hat zunächst eine gewisse Vorstellung des Produktes, die ihm auch durch die Marketingabteilung bzw. durch die Werbung suggeriert werden kann. Bildhaft gesprochen bedeutet das, daß die Sonne diese Abteilung sein könnte, die im Falle des Wasserkreislaufes dafür sorgt, daß das Wasser verdunstet und in höheren Luftschichten wieder zu Wolken kondensiert. Das Unternehmen muß sich jetzt genau wiederum diesen vielleicht auch aktuelleren Produktvorstellungen des Kunden annehmen und eine neue Produktidee mit dem Vertrieb sowie der Entwicklung schaffen.

Im Wasserkreislauf passiert jetzt nichts anderes als die weitere Verdichtung der kondensierten Wolken, bis diese sich wiederum an anderer Stelle abregnen. Gleiches passiert im Unternehmen mit der Produktidee, die sich im Laufe der Produktentwicklung immer weiter konkretisiert und schließlich in der Fertigung in Serie produziert werden kann. Dabei muß das dabei anfallende Wissen über das Produkt immer wieder diesem auch zugeordnet werden. Es passiert also nichts anderes als die Kondensierung des Wissens an dem Produkt. Ist der Serienstart geglückt, "regnet" sich das Produkt über dem Kunden "ab", so daß es ihm zur Produktnutzung zur Verfügung steht.

Q-Step muß also genau diesen Prozeß der Wissenskondensierung unterstützen, wodurch das Produktteam und der Projektleiter die geforderte Nachvollziehbarkeit der Produktentwicklung (Kapitel 1.2) erhält.

Ziel dieser Arbeit wird es also nicht sein, die Organisation von Methoden in der Produktentwicklung zu beschreiben. Hierzu gibt es bereits umfangreiche Literatur, die von Unternehmen angewendet und angepaßt werden kann. Gleiches gilt für die Unternehmenskultur über die mindestens genau soviel geschrieben wurde. Voraussetzung für den Einsatz des vorgestellten Softwareprototypen Q-Step ist eine Unternehmenskultur, in der ein gesundes Verhältnis zwischen Geben und Nehmen existiert. Der erarbeitete Prototyp lebt natürlich nur von dem Wissen, daß ihm eingegeben wird. Zur Akquisition des Wissens werden die integrierten Methoden helfen (Kapitel 2.3), trotzdem steht und fällt der Erfolg des Einsatzes mit der Konsequenz, mit der eine solche Software im Unternehmen angewendet wird.

Im nun folgenden Kapitel 3.3 soll der rote Faden durch die gesamte Arbeit vermittelt werden.

Nach der Einleitung in Kapitel 1 mit der Problemstellung und den Anforderungen an eine softwaretechnische Unterstützung des Geschäftsprozesses, der Produktentwicklung und der Situationsanalyse bisheriger Ansätze in Kapitel 2 folgt in Kapitel 3.1 die zusammenfassende Betrachtung der Defizite bisheriger Arbeiten und daraus eine vollständige Formulierung der Aufgabenstellung und Zielsetzung in Kapitel 3.2.

Die Abbildung 3-2 zeigt einen Überblick über den kompletten Aufbau der Arbeit. Zentraler Punkt ist der eigene Ansatz von Kapitel 4 und den Rahmen bilden die Kapitel 1 bis 3 sowie die Kapitel 5 bis 7.

Dabei wird in Kapitel 4.1 zunächst das Datenmodell für die untersuchten Methoden analysiert. Das Kapitel 4.2 wird diese Methoden inhaltlich sinnvoll miteinander verbinden, und die Integration zu den Produktmodelldaten eines volumenorientierten CAD-Systems ausführen. Das Kapitel 4.3 wird schließlich die Übertragung der in Kapitel 2.3 genannten Merkmale des Wissensmanagements vollziehen.

Das Konzept soll zeigen, wie die Produktmodelldaten für die Wissensakquisition, die Wissenswiederverwendung, die Wissensweiterverwendung und die Wissensrückführung genutzt werden. Hierzu wird eine Methodenintegration realisiert und durch den Verbund der Methoden die Anforderungen des Wissensmanagements erfüllt. Das Produktteam wird also in der Produktentwicklung durch eine projektspezifische Wissenskondensierung (Kapitel 3.2) unterstützt und schafft dadurch eine sichere Erreichung der gesteckten Qualitätsziele.

In Kapitel 5 wird schließlich, aufbauend auf dem Konzept, der Softwareprototyp Q-Step vorgestellt, der exemplarisch im Rahmen einer laufenden Produktentwicklung bei Becker Autoradio GmbH eingesetzt wurde (Kapitel 6). Über die Kapitel 4 bis 6 wird man einen Eindruck erhalten, welche Flexibilität die Software bereits in ihrem jetzigen Zustand besitzt. Man wird erkennen, wie zunächst in Kapitel 4 und 5 ein allgemein gültiges Projektmanagement mit Methodeneinsatz aufgebaut wird und dieses dann unternehmensspezifisch in Kapitel 6 an die Unternehmensbelange angepaßt wird.