Wissensmanagement in Entwicklung und Konstruktion

von Sassan Mottaghian und Ulrich Reetz

Im Entwicklungs- und Konstruktionsbereich von Industrieunternehmen – also dort, wo es um Innovation, um Wissensschaffung geht – zeigt sich, dass das Management von Wissen um ein Produkt und seinen Entstehungsprozess weit über die Anwendung von Software-Lösungen hinausgeht. Ziel sollte vielmehr ein Zusammenspiel von HR-Aspekten, Organisationsstrukturen, Strategie und IT sein. Sassan Mottaghian und Ulrich Reetz weisen mit Product Knowledge Management (PKM) einen Lösungsweg speziell für das verborgene Wissen, das im Entwicklungs- und Konstruktionsprozess entsteht.

Inhaltsübersicht:

• Heutige Vorgehensweise
• Dead-End-Knowledge bei der Produktkonzeption
• Verborgenes Wissen im Verlauf der Konstruktion
• Erweitertes PDM-Historienmanagement
• Product Knowledge Management (PKM)
• PKM ist kein Software-Tool

 

Immer mehr

Führungskräfte identifizieren die Ressource Wissen als

wesentlichen Wettbewerbsfaktor in unserer Gesellschaft. Begriffe

wie Data Warehouse, Knowledge Broker, Knowledge Mining suggerieren

dabei die Verfügbarkeit fertiger Lösungsansätze für

viele Branchen und Unternehmensbereiche. Insbesondere im Entwicklungs-

und Konstruktionsbereich von Industrieunternehmen zeigt sich jedoch,

dass das Management von Wissen um ein Produkt und seinen Entstehungsprozess

über die Anwendung von Software-Lösungen weit hinausgeht.

 

 

Heutige Vorgehensweise

 

 

Am Markt werden

derzeit mehrere Software-Lösungen präsentiert, die auf

den Entwicklungs- und Konstruktionsbereich abzielen. Ein Ansatz

ist unter dem Begriff wissensbasierte Konstruktionssysteme, aber

auch regelbasierte Systeme bekannt geworden. Diese Werkzeuge unterstützen

den Konstrukteur in ihrer Kernfunktionalität dadurch, dass

sie das unternehmensspezifische Konstruktions-Know-how, aber auch

einfache Konstruktions-, Fertigungs- und Bemessungsregeln erfassen

und – eingebettet in ein CAD-System – dieses regelbasierte

Wissen zur Verfügung stellen. Der Konstrukteur kann so frühzeitig

und durchgehend die vorgegebenen spezifischen Konstruktionsregeln

einhalten.

 

 

Ingenieursnetzwerke

stellen einen weiteren Ansatz dar, aktiv Wissensmanagement in die

Entwicklungs- und Konstruktionsabteilungen zu tragen. Hier sollen

auf E-Business basierende Konzepte unternehmensintern, aber auch

unternehmensübergreifend für F&E umgesetzt werden.

Elektronische Marktplätze sollen den Wissensaustausch zwischen

den Ingenieuren ermöglichen und fördern. Dazu werden mehrere

wissenschaftliche Systeme in Zusammenarbeit mit Industrieunternehmen

realisiert. Auch CAD-Anbeiter bieten jetzt solche Internet-Portale

an, die zunehmend an Verbreitung gewinnen.

 

Knowledge Gap in der Phase der Produktkonzeption

 

Neben diesen

recht spezifischen Vorgehensweisen werden im Rahmen der industriellen

Produktentwicklung immer wieder allgemeine Ansätze aufgeführt,

die im Prinzip oftmals erweiterte Data-Warehouse-Konzepte darstellen.

 

 

Aufgrund der

Erfahrungen bei Kunden der CSC Ploenzke AG, die zum Themenbereich

Produktdatenmanagement (PDM) beraten wurden, wird eine Beratungslösung

für die Unternehmensbereiche Entwicklung und Konstruktion propagiert,

die ein Gleichgewicht im Zusammenspiel von Human-Resources-Aspekten,

Methoden, Werkzeugen, Strukturen und Strategien zum Ziel hat. Im

folgenden Beispiel wird zunächst die heutige Vorgehensweise

aus unserer Erfahrung heraus beschrieben. Anschließend werden

die Schwachpunkte aufgezeigt, um den Handlungsbedarf zu erläutern.

Das Beispiel bezieht sich zu Anfang auf die Phase der Produktkonzeption.

Hier werden Funktionsprinzipien und deren Abhängigkeiten festgelegt.

 

Seitenanfang

 

Dead-End-Knowledge bei der Produktkonzeption

 

 

Einem Team

von Ingenieuren bei einem großen Getriebehersteller wird die

Aufgabe gestellt, ein technisches Konzept für eine neue Produktgeneration

zu entwickeln. Dabei sollen u.a. neue Ideen zur Gestaltung des Getriebes

verfolgt werden. Unterlagen über bisher realisierte Konzepte

sind den Ingenieuren zugänglich.

 

 

Nach dem ersten

Teammeeting zu diesem Thema wurden vier Lösungskonzepte vorgeschlagen.

Zwei weitere ergaben sich im Laufe der Produktkonzeption. Nach dem

zweiten Review-Meeting wurde eine Entscheidung zugunsten von Konzept

6 getroffen. Alle anderen Konzepte wurden nach eingehender Prüfung

verworfen. Im Rahmen dieser Verifikation haben die Ingenieure, die

an dieser Konzeption beteiligt waren, besonders bei interdisziplinären

Diskussionen die Vor- und Nachteile der verschiedenen Konzepte diskutiert

und abgewogen. Dieser Weg wurde zwar in Meeting-Minutes protokolliert,

aber nach der Entscheidungsfindung nicht weiter dokumentiert. Die

Folgen: Die wesentlichen Erfahrungen aus dieser Konzeptionsphase

liegen ausschließlich in den Köpfen der Prozessbeteiligten.

Das gänzlich oder fragmentiert vorhandene Entwicklungs-Know-how

steht späteren Entwicklungsteams ähnlicher Produkte bestenfalls

teilweise zur Verfügung; es verbleibt in einer Sackgasse und

wird daher im Folgenden als Dead-End-Knowledge bezeichnet.

Knowledge Gap in den Phasen Konstruktion und Arbeitsvorbereitung

 

Die derzeitige

Praxis gestaltet sich vielfach wie folgt: In den wenigsten Fällen

sind die Teammitglieder schon miteinander bekannt, die Dokumentationen

sind für Außenstehende oft nicht verständlich und

nachvollziehbar. Die damaligen Entwickler stehen selten auch heute

noch zur Verfügung. Oftmals ist dem neuen Team nicht einmal

bekannt, wer bisher schon an einem ähnlichen Konzeptentwurf

beteiligt war oder wann und wo diese Auswahl stattgefunden hat.

 

 

Dabei ist doch

gerade dieses Dead-End-Knowledge bedeutend:

 

• Sprachen fertigungstechnische, montage- oder wartungsbedingte Gründe gegen den Entwurf?
• Resultierten zu hohe Kosten oder sprachen Marketingaspekte für die andere Alternative?
• War die Lösung zu störanfällig?
• Fehlten die geeigneten Materialien zur Realisierung?

 

Dieses Wissen,

das über kausale oder standardisierte Zusammenhänge wissensbasierter

Systeme hinausgeht und ein unter Umständen marktrelevantes

Know-how einer einzelnen Unternehmung darstellt, gilt es zu bewahren

und zu managen. Denn hier sind die Potenziale für spätere

Konzeptionsphasen ähnlicher Produkte versteckt. Beispielsweise

kann die Fertigungsgenauigkeit im Zusammenspiel mit einem definierten

Werkstoff so entscheidend verbessert worden sein, dass dies bei

der nächsten Konzeption hin zu einer neuen Produktgeneration

beachtet werden sollte. Aus dem Dead-End-Knowledge wird so ein reversibles

Wissen, das im Zusammenhang mit aktuellen Erkenntnissen den entscheidenden

Vorsprung gegenüber der Konkurrenz erwirkt.

 

Seitenanfang

 

 

Verborgenes Wissen im Verlauf der Konstruktion

 

 

Bei der weiteren

Verfolgung des Produktentstehungsprozesses wird nun angenommen,

dass im Unternehmen bereits ein Produktdatenmanagement-System eingesetzt

wird. Dieses PDM-System ist in den gesamten Entwicklungs- und Konstruktionsprozess

eingebettet und unterstützt u.a. das Produktstrukturmanagement,

Versions- und Statusmanagement, das Freigabe- und Änderungsmanagement

sowie das Historienmanagement.

 

 

Unterstützt

von diesem Produktdatenmanagement durchlaufen die einzelnen Komponenten

des Getriebes verschiedene Versionen und werden revisioniert. Die

Funktionsgruppe "Getriebe" ist in drei Baugruppen realisiert

worden. Im Laufe des Konstruktionsprozesses werden mehrere Änderungsaufträge

durchgeführt. Im PDM-System wird automatisch bei jedem Wiedereinbringen

der Konstruktionsunterlagen eine neue Version generiert. Dementsprechend

liegen verschiedene Versionen der Teile im PDM-System vor. Die Änderungsgründe

waren vielfältig:

 

• Mehrfach wurden Bauraumbeschränkungen verändert.
• Ein Lager war falsch berechnet.
• Die Werkstoffpaarung zwischen Getriebekomponenten und Welle war ungünstig.
• Der Einkauf hatte nahegelegt, mehrere Zukaufteile bei einem anderen Lieferanten zu beziehen.
• Zusätzlich wurden die Baugruppen aufgrund unterschiedlicher gesetzlicher und technischer Anforderungen des US-amerikanischen und des asiatischen Markts noch zweimal revisioniert.

 

Das Historienmanagement

des PDM-Systems kann diese beschriebenen Versions- und Revisionsschritte

grafisch anzeigen. Auch können im Historienmodul einzelne Kommentare

zu den Versionen und Revisionen abgelegt werden.

 

Seitenanfang

Erweitertes PDM-Historienmanagement

 

 

Abgesehen davon,

dass manche Unternehmungen noch nicht über ein so umfangreich

implementiertes Historienmanagement verfügen, gibt es in den

seltensten Fällen ein Konzept, wie die Erkenntnisse aus der

Teilehistorie in nachfolgende Produktentstehungsprozesse eingefügt

werden können. Hier genügt es nicht, Gestaltungsregeln

abzuleiten. Vielmehr wird hier die Aufgabe gestellt, kontextbezogen

auf bisherige Erfahrungen hinzuweisen und dem Konstrukteur schon

während der Entwicklung eine Hilfestellung durch Wissensmanagement

zur Verfügung zu stellen.

 

 

Das PDM-Historienmanagement

sollte hier beispielsweise durch einen Post-Milestone im Entwicklungsprozess

erweitert werden. In diesem Post-Milestone wird das Team angehalten,

abgehoben vom aktuellen Entwicklungsprojekt ein Resümee zu

ziehen und dies geeignet zu dokumentieren. Dieses erweiterte Historienmanagement

soll dem Konstrukteur kontextbezogen, jedoch nicht zwingend produktbezogen

zur Verfügung stehen.

 

 

Die Vorteile,

die sich aus einem solchen Post-Milestone ergeben können, zeigen

sich auch in diesem Beispiel: Zum Zeitpunkt der Prototypen-Entwicklung

wurde festgestellt, dass die in der Konzeptphase ausgewählte

Lösung doch einige Schwächen hat und nur die zweitbeste

Lösung war. Da man schon zu weit im Produktentwicklungsprozess

fortgeschritten war, entschied man sich, diese zweitbeste Lösung

doch unter großem Aufwand durch Einsatz modernster CAD/CAM-

und FEM-Techniken zu realisieren. Die realisierte Lösung hatte

dann im Service zu nicht unerheblichen Schwierigkeiten geführt.

Die im Konstruktionsprozess gesammelten Erfahrungen wurden bei der

Folgekonzeption eingebracht und führten letztendlich zu einem

technisch ausgereifteren Produkt, mit dem man auch noch deutlich

Fertigungskosten einsparen konnte.

 

Wissensentstehung und -vernichtung im Entwicklungsprozess

 

 

Beide Phasen

des Beispiels zeigen ein Grunddilemma der Produktentwicklung auf:

Abgesehen von den heute üblichen Randbedingungen (verteilte

Entwicklung, interdisziplinäre Teams, Simultaneous Engineering,

Concurrent Engineering usw.) wird kontinuierlich Wissen identifiziert,

akquiriert, strukturiert und weiterentwickelt. Diese Flut an produktspezifisch

verknüpften Informationen gepaart mit Erfahrungen der am Produktentstehungsprozess

Beteiligten sollte in Hinsicht auf eine optimierte Produktentwicklung

verwaltet werden. Eine Verwaltung dieser produktbezogenen Entwicklungsdaten

würde neben den oben genannten Aufgabenfeldern (Identifikation,

Akquisition, Strukturierung, Evolution) auch die Wissensablage und

prozessorientierte Wissensverteilung einbeziehen. Das ist ein besonders

wichtiger Aspekt, da in bisherigen Projekten oft auffiel, dass die

Konstruktionsabteilungen durchaus wissen, was falsch gemacht wird

– daraus jedoch auch Handlungsalternativen zu entwickeln, ist

das Problem.

 

 

Die Ausgangsgrößen

des schematisch dargestellten Prozesses der Wissensentstehung und

Wissensvernichtung können in drei Bereiche unterschieden werden:

 

• reversibles Wissen
• irreversibles Wissen
• Produktinformationen

 

Strategien,

diese Produktinformationen auch und insbesondere im weiteren Produktlebenszyklus

zu managen, können im Rahmen von PDM- und ERP-Projekten weiter

verfolgt werden.

 

Seitenanfang

 

Product Knowledge Management (PKM)

 

 

Wesentlich

ist aber auch, reversibles und irreversibles Wissen zu unterscheiden.

Der weiterführende Lösungsweg ist deshalb ein Product

Knowledge Management (PKM). Damit wird das Ziel verfolgt, im Rahmen

der Schwerpunktaufgaben

 

• Identifikation
• Akquisition
• Strukturierung
• Evolution
• Ablage
• Distribution

 

eine Rückführung

des reversiblen produktbezogenen Entwicklungswissens zu ermöglichen

und irreversibles Wissen aus dem Prozess zu entfernen.

 

 

Dabei soll

PKM folgende Nutzenpotenziale erschließen:

 

• Aufschluss über die Gründe, die gegen ein Lösungskonzept sprachen
• Möglichkeit zu einer effektiven erneuten Bewertung verworfener Konzepte auf der Basis neuer Methoden und Technologien, Materialien etc.
• Rückgriff auf das implizite Wissen der damals Beteiligten durch eine projekt- und produktbezogene Personalisierung
• situationsbezogene Dokumentation von Fehlern in der Produktentwicklung
• Post-Milestone zur Resümierung von Erfahrungswissen im Historienmanagement
• Steigerung der Effizienz im Produktentwicklungsprozess
• Einbeziehung des Wissens aus dem gesamten Produktlebenszyklus in die Produktentwicklung

 

Um dieses Ziel

zu erreichen, schlagen wir folgenden Weg vor: Nach einer Analysephase

des Produktentstehungsprozesses im Hinblick auf das ein- und ausgebrachte

Wissen wird der Wissensoutput dahingehend klassifiziert, ob das

Wissen reversibel oder irreversibel ist. Hier werden dann die Nutzenpotenziale

für den Kunden identifiziert und in verschiedenen Teilstrategien

umgesetzt. Das Ergebnis dieser Vorgehensweise sollte sich dann in

den genannten Klassen darstellen lassen. Die Produktentwicklung

wird durch die bedarfsgerechte Rückführung des Wissens

aus vorhergehenden Entwicklungsprojekten unterstützt und von

unnötigem Wissensballast befreit.

 

Seitenanfang

 

PKM ist kein Softwaretool

 

 

Diese Vorgehensweise

ist mit geeigneten Tools zu unterstützen. Es soll jedoch der

Eindruck vermieden werden, dass PKM mit Tools und fertigen Konzepten

schnell eingekauft und verwirklicht werden könne. Vielmehr

ist PKM ein langfristiger strategischer Ansatz, der wie alle Wissensmanagement-Projekte

von den Führungskräften in die Entwicklungsabteilung hineingetragen

werden muss und mit Strategien des Human-Resources-Managements einhergeht.

Das heißt: Insbesondere auf das Personal, die im Unternehmen

verwendeten Methoden, die Techniken und Barrieren des Wissensmanagements

muss gründlich eingegangen werden, um ein solches Projekt nicht

schon am Anfang zu beenden.

 

 

So gilt es

im genannten Beispiel seitens der Führungskräfte, Motivationsfaktoren

zu schaffen, damit die Entwickler und Konstrukteure PKM-Methoden

und -Techniken bei der täglichen Arbeit anwenden. Zu Anfang

ist somit ein umfassendes Akzeptanzmanagement zu betreiben, da der

Nutzen gerade bei der Einführung von PKM nicht für jeden

Mitarbeiter transparent ist. Damit PKM zum Erfolg führt und

langfristig die technologische Führung eines Unternehmens im

Markt sichert, ist ein hoher Startaufwand seitens der Mitarbeiter

notwendig. Der Lohn der Mühe ist jedoch insbesondere für

jüngere Mitarbeiter sehr schnell ersichtlich.