2000/9 | Fachbeitrag | Product Knowledge Management (PKM)
Wissensmanagement in Entwicklung und Konstruktion
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.
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.
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.
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.
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.
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.
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.