Industrieerprobte Lösungen und Werkzeuge für Produktentwicklung ...

Stephan Zelewski; Adem Alparslan (Hrsg.): 

Industrieerprobte Lösungen und Werkzeuge 

für Produktentwicklung, Engineering und 

Kompetenzmanagement 

Proceedings zum Abschlussworkshop der Verbundprojekte 

GINA, KOEFFIZIENT und KOWIEN, 5. und 6. Oktober 2004, 

Marketing Management Institut Braunschweig 

gefördert vom: betreut vom:

Impressum: 

Herausgeber: Univ.-Prof. Dr. Stephan Zelewski; Dipl.-Kfm. Adem Alparslan 

Institut für Produktion und Industrielles Informationsmanagement 

Universität Duisburg-Essen (Campus Essen), Universitätsstraße 9, 45141 Essen, 

E-Mail: {Stephan.Zelewski | Adem.Alparslan}@pim.uni-essen.de 

URL: http://www.pim.uni-essen.de 

ISBN 3-9809798-3-0 

Die Deutsche Bibliothek – CIP Einheitsaufnahme 

Essen 2004

Ganzheitliche Innovationsprozesse 

in modularen Unternehmensnetzwerken (GINA) 

http://www.gina-net.de/ 

Kooperationsassistent zur 

effizienten Gestaltung überbetrieblicher 

Produkt- und Prozessentwicklung (KOEFFIZIENT) 

http://www.koeffizient.org 

Kooperatives Wissensmanagement 

in Engineering-Netzwerken (KOWIEN) 

http://www.kowien.uni-essen.de 

gefördert vom: betreut vom:

Geleitwort des Projektträgers 

Beim Umgang mit den Herausforderungen des Markts muss die Gesamtstrategie eines produzierenden 

Unternehmens an mehreren Punkten gleichzeitig ansetzen. Dabei müssen so unterschiedliche 

Ziele wie Schnelligkeit bei der Produkt- und Prozessinnovation, Handhaben von 

Informationen und Wissen, unternehmensübergreifende Kooperation und Engineering mit geeigneten 

Instrumenten und Methoden parallel angegangen werden. Um insbesondere auch 

kleine und mittlere Unternehmen im Umgang mit diesen Herausforderungen zu unterstützen 

fördert das Bundesministerium für Bildung und Forschung (BMBF) im Themenfeld „Produktentwicklung“ 

des Rahmenkonzepts „Forschung für die Produktion von morgen“ fachdisziplinenübergreifende 

Kooperationen zwischen Forschungseinrichtungen und Industrieunternehmen 

(Verbundprojekte). Die drei Projekte 

• GINA – Ganzheitliche Innovationsprozesse in modularen Unternehmensnetzwerken, 

• KOEFFIZIENT – Kooperationsassistent zur effizienten Gestaltung innovativer Partnerschaften 

zur überbetrieblichen Produktentwicklung, 

• KOWIEN – Kooperatives Wissensmanagement in Engineering-Netzwerken 

haben in drei bzw. dreieinhalb Jahren Forschung und Entwicklung industrieerprobte Lösungen 

und Werkzeuge für Innovationsprozesse, Engineering und Kompetenzmanagement erarbeitet. 

Die gemeinsame Präsentation der Projektergebnisse leistet einen wichtigen Beitrag dazu, 

dass produzierende Unternehmen verschiedenster Branchen an den Lösungen partizipieren 

können. Der vorliegende Tagungsband dokumentiert die Veranstaltung mit ihrem umfangreichen 

Vortragsprogramm und der begleitenden Ausstellung. Die Projekte wurden jeweils von 

assoziierten Industriearbeitskreisen begleitet. Dies hat den Erfahrungsaustausch über die Projektpartnerschaft 

hinaus erfolgreich angeregt. Die Projektergebnisse wurden dort regelmäßig 

präsentiert und mit den Teilnehmern diskutiert. Gastvorträge aus angrenzenden Themengebieten 

bereicherten das Programm. 

Unser Dank gilt allen in den Verbundprojekten und Industriearbeitskreisen mitwirkenden Personen 

für ihren Einsatz und für die gute Zusammenarbeit. Besondere Anerkennung gebührt 

den Koordinatoren, Herrn Prof. Dr.-Ing. Hans-Joachim Franke, Herrn Dr.-Ing. Günter Staub 

und Herrn Univ.-Prof. Dr. Stephan Zelewski, sowie ihren Mitarbeitern. Ohne ihre praxisorientierte 

Unterstützung und ihr starkes persönliches Interesse an den Vorhaben hätten die eingangs 

skizzierten Zielsetzungen nicht erreicht werden können. Damit verbindet sich auch unser 

Dank an das BMBF, namentlich an Frau Dipl. oec. Susanne Clobes. 

Weitere Informationen zu den Verbundprojekten sind im Internet unter www.gina-net.de, 

www.kowien.uni-essen.de, www.koeffizient.org abrufbar. Informationen über das Themenfeld 

„Produktentwicklung“ und das BMBF-Rahmenkonzept „Forschung für die Produktion 

von morgen“ erhalten Interessierte unter www.fzk.de/pft. 

Karlsruhe, im September 2004 

Dr.-Ing. Ingward Bey/ Martina Kühnapfel, M.A./ Dipl.-Ing. Edwin Steinebrunner 

Projektträger des BMBF für Produktion und Fertigungstechnologien (PFT) 

Forschungszentrum Karlsruhe GmbH

Inhaltsverzeichnis 

Teil 1: 

Vorstellung der Verbundprojekte 

GINA, KOEFFIZIENT und KOWIEN ................................................................. 1 

STEFAN LÖFFLER 


in modularen Unternehmensnetzwerken (GINA)....................................................................... 3 

GÜNTER STAUB 

Kooperationsassistent zur effizienten Gestaltung überbetrieblicher 

Produkt- und Prozessentwicklung (KOEFFIZIENT) ................................................................... 11 

STEPHAN ZELEWSKI 

Kooperatives Wissensmanagement in Engineering-Netzwerken (KOWIEN)......................... 21 

Teil 2: 

Impulsvorträge .................................................................................................. 85 

ARNE SIMON 

Aspekte der Produktentwicklung im Rahmenkonzept 

„Forschung für die Produktion von morgen“ ........................................................................... 87 

TRAC TANG 

Von Informationstechnik zur Integrationstechnologie 

– am Beispiel der Virtuellen Produktentstehung...................................................................... 91 

WERNER SCHNITZLEIN 

Collaborative Engineering bei der ZF Group........................................................................... 97 

KAI ENGELMANN 

Wissensmanagement in der Produktentwicklung................................................................... 113

Industrieerprobte Lösungen und Werkzeuge für Produktentwicklung, Engineering und Kompetenzmanagement 

Teil 3: 

Erfahrungsberichte aus den Verbundprojekten.......................................... 115 

MARKO MULTHAUPT 

Controlling im Innovationsprozeß der Reifenentwicklung 

– ein Praxisbericht der Continental AG ..................................................................................117 

CHRISTIAN DECKER 

Wie die DESMA Schuhmaschinen GmbH ihren Innovationsprozess optimiert hat ..............127 

KARL HASLINGER; MAXIMILIAN REISCHL 

Produkte verteilt kooperativ entwickeln und produzieren ......................................................141 

MARIANNE SCHUMACHER; STEFAN ZUG 

Qualitätssicherung durch Kompetenzmanagementsysteme....................................................151 

CHRISTOF BÄUMGEN; ROGER HÜBBERS 

Ontologiebasiertes Kompetenzmanagementsystem auf Basis von infonea®.........................161 

STEFAN LÖFFLER; BURKHARD JAGUSCH 

„Methodos“ – ein Methodenbaukasten zur effizienten Produktentwicklung .........................175 

GÜNTER STAUB 

Der „Dynamische Kooperationsassistent“: 

IT-gestützte, unternehmensübergreifende Kommunikation im Engineering..........................189 

PHILLIP KOLLMAR 

KOEFFIZIENT im Maschinen- und Anlagenbau.......................................................................205 

HANS MEIER 

Das Vorgehen zur Konstruktion eines 

ontologiebasierten Kompetenzmanagementsystems...............................................................207 

THOMAS WEICHELT 

Die E-Learning-Anwendung des Projekts KOWIEN .............................................................217 

Autoren-, Herausgeber- und Referentenverzeichnis ................................... 235 

II

Teil 1: 

Vorstellung der Verbundprojekte 

GINA, KOEFFIZIENT und KOWIEN 

1 Teil 1 

1



in modularen Unternehmensnetzwerken (GINA) 

2 Ganzheitliche Innovationsprozesse 

1 Gegenstand des Projektes 

STEFAN LÖFFLER 

In den letzten Jahren haben sich die Wettbewerbsbedingungen aufgrund verkürzter Technologie- 

und damit Produktlebenszyklen sowie gestiegener Kundenanforderungen verschärft. 

Wettbewerbsfähigkeit und Wachstum werden mehr denn je davon bestimmt, die Fähigkeit zu 

besitzen, betriebswirtschaftlich abgesicherte Innovationen zu entwickeln und umzusetzen. In 

einem immer enger werdenden Wettbewerb dienen Innovationen dem Unternehmen als Differenzierungsmöglichkeit, 

um dem gestiegenen Anspruchsniveau der Kunden gerecht zu werden 

und einen Vorsprung gegenüber dem Wettbewerb gewinnen zu können. 

Obwohl die Notwendigkeit von Innovationsfähigkeit von vielen Unternehmen erkannt wurde, 

sind im betrieblichen Alltag erhebliche Defizite zu erkennen. Innovationsprozesse sind oftmals 

dem Tagesgeschäft untergeordnet und kein eigenwertiger Bestandteil des Unternehmens. 

Kleine und mittelständische Unternehmen (KMU) stehen aufgrund begrenzter Ressourcen vor 

einer besonderen Herausforderung, Chancen durch Innovation zu nutzen und gleichzeitig das 

mit einer Innovation verbundene technische und wirtschaftliche Risiko zu bewältigen. 

Einen Weg zur Nutzung der Chancen und Minimierung der Risiken von Innovationsprozessen 

stellen Kooperationen dar. Die Entwicklung neuer Produkte gehört zwar zum Alltag vieler 

Unternehmen, nicht jedoch die Erarbeitung innovativer Produkte und Technologien in einer 

Kooperation. Gründe hierfür sind sowohl fehlendes Vertrauen als auch ungenügende Methodenkenntnis 

für eine Zusammenarbeit. Dabei lassen sich ökonomisch und technologisch sinnvolle 

Projekte, die das Hervorbringen einer innovativen Lösung als Ziel haben, durch eine 

Nutzung von verteilten Ressourcen realisieren. Eine verteilte Innovation im Rahmen einer 

Kooperation (z.B. im Rahmen eines Netzwerkes) bietet vor allem KMU die Möglichkeit, eigenständig 

zu bleiben sowie gleichzeitig den Aktionsradius zu erweitern. 

Das Ziel des GINA-Projektes ist es, Innovationsprozesse innerhalb eines Unternehmens und 

zwischen verschiedenen Unternehmen umfassend zu untersuchen sowie Methoden und Werkzeuge 

für die Optimierung der Prozesse zur Verfügung zu stellen. Dazu wurden im Rahmen 

des Projektes vier interdisziplinäre, wissenschaftliche Schwerpunkte definiert: 

• Analyse und Optimierung der Innovations- und Kooperationsfähigkeit, 

• Entwicklung eines Methodenassistenzsystems zur Verbesserung des Methodeneinsatzes im 

(kooperativen) Entwicklungsprozeß, 

• Entwicklung von Instrumenten des innerbetrieblichen und unternehmensübergreifenden 

Controlling im Innovationsprozeß, 

• Durchführung und Analyse von Pilotprojekten mit konkreten Entwicklungszielen. 

3

Ganzheitliche Innovationsprozesse in modularen Unternehmensnetzwerken (GINA) 

2 Beteiligte Projektpartner zur Durchführung des Vorhabens 

Für die inhaltliche Durchführung des Projektes waren drei Institute der Technischen Universität 

Braunschweig verantwortlich, die mit vier wissenschaftlichen Mitarbeitern mitgewirkt haben: 

• Institut für Konstruktionstechnik (IK), 

• Institut für Werkzeugmaschinen und Fertigungstechnik (IWF), 

• Institut für Wirtschaftswissenschaften, 

Abt. Controlling und Unternehmensrechnung (CU). 

Alle drei Institute verfügen über weitgehende Projekt- und Forschungserfahrungen auf den für 

das Projekt erforderlichen Kompetenzfeldern. 

Das Institut für Konstruktionstechnik (IK) beschäftigt sich seit seiner Gründung mit den 

Grundlagen des methodischen Konstruierens und Entwickelns. In diesem Zusammenhang haben 

stets Fragen der industriellen Produktinnovation und dafür geeigneter Methoden und 

Hilfsmittel im Vordergrund der Forschungsaktivitäten gestanden. In zahlreichen Kooperationen 

zwischen Hochschule und Industrie wurden umfangreiche Erfahrungen bei der Optimierung 

von Innovationsprozessen aufgebaut. 

Das Institut für Werkzeugmaschinen und Fertigungstechnik (IWF) bearbeitet die Gebiete der 

Fertigungstechnik, der Fertigungsautomatisierung und Handhabungstechnik sowie des Umwelt- 

und Prozeßmanagement. Aufgrund verschiedener durchgeführter Industrie- und Forschungsprojekte 

zur Neugestaltung von Fertigungs- und Geschäftsprozessen, z.B. Neugestaltung 

des Produktentstehungsprozesses bei einem Aggregatehersteller, konnten vielfältige Erfahrungen 

in der Gestaltung von Prozessen, insbesondere von Innovationsprozessen, aufgebaut 

werden. 

Das Institut für Wirtschaftswissenschaften (CU) besitzt Erfahrungen aus verschiedenen Arbeiten 

und Projekten über industrienahes Controlling mit Schwerpunkt auf Kosten- und Leistungsrechnung, 

Berichtswesen sowie Projektsteuerung. Schwerpunkt dieser Projekte war stets 

die unternehmensspezifische Konzeption und meist EDV-unterstützte Implementierung von 

Controlling-Bausteinen wie Target Costing, Prozeßkostenrechnung, Kostenrechnungs- 

Datenbank, Berichtswesen, IV-Controlling usw. Ferner besitzt das CU Know-How auf dem 

Gebiet technisch-wirtschaftlicher Kennzahlensysteme zur zielorientierten Steuerung von Forschungs- 

und Entwicklungsvorhaben. 

In Tabelle 1 sind darüber hinaus alle am Projekt GINA geförderten Industriepartner aufgeführt. 

4


Institut für Konstruktionstechnik (IK) 

Langer Kamp 8 

38106 Braunschweig 

www.ikt.tu-bs.de 

Institut für Werkzeugmaschinen und 

Fertigungstechnik (IWF) 

Langer Kamp 19 b 


www.iwf.ing.tu-bs.de 

Institut für Wirtschaftswissenschaften, 

Abt. Controlling 

und Unternehmensrechnung (CU) 

Pockelsstr. 14, 38106 Braunschweig 

www.wiwi.tu-bs.de/controlling 

Volkswagen AG 

Brieffach 1895, 

38436 Wolfsburg 

www.volkswagen.de 

Hella KG Hueck und Co. 

Postfach 2840 

59538 Lippstadt 

www.hella.de 

Klöckner Desma Schuhmaschinen 

GmbH 

Desmastr. 3/5 

28832 Achim 

www.desma.de 

Metallgießerei Wilhelm Simon 

GmbH 

Otto-von-Guericke Straße 2 

38350 Helmstedt 

www.simon-helmstedt.de 

SBS-Softwaresysteme GmbH 

Jasperallee 13 


www.sbs-softwaresysteme.de 

5 

Dipl.-Ing. Stefan Löffler 

Dipl.-Ing. Markus Deimel 

Dipl.-Wirtsch.-Ing. 

Marc Mateika 

Dipl.-Wirtsch.-Ing. 

Joachim Fest 

Dr.-Ing. Thomas Gänsicke 

Dipl.-Ing. Karsten Eschment 

Dipl.-Ing. Reiner Gödecker 

Dr.-Ing. Roland Lachmayer 

Dipl.-Ing. Christian Decker 

Dipl.-Ing. Karl-Heinz Broistedt 

Dipl.-Ing. Knut Jerchel 

Burkhard Jagusch 

Uwe Lesta 

Tabelle 1: Übersicht aller geförderten GINA-Projektpartner


3 Planung und Ablauf des Projektes 

Die Thematik wurde arbeitsteilig in fünf Teilprojekten (TP) aufgeteilt, die von den Projektpartnern 

eigenständig im vorgesehenen Umfang bearbeitet wurden. Die TU Braunschweig hat 

während des gesamten Projektes die Koordination übernommen und sorgte durch regelmäßige 

Arbeits- und Projekttreffen für einen Informationsaustausch. 

Folgende Teilprojekte wurden bearbeitet: 

TP 1: Analyse der Innovationsprozesse in Unternehmen/ im Netzwerk 

TP 2: Methoden und Werkzeuge für Innovationsprozesse 

TP 3: Aufbau eines Controlling-System zur Steuerung der unternehmensinternen und über 

greifenden Innovationsprozesse 

TP 4: Implementierung neuer und optimierter Methoden 

TP 5: Pilotprojekte 

Das Institut für Werkzeugmaschinen und Fertigungstechnik (IWF) war für das Teilprojekt 1 

hauptverantwortlich und führte die Analyse der Innovationsprozesse bei allen geförderten Industriepartnern 

durch. 

Das Teilprojekt 2 wurde vom Institut für Konstruktionstechnik (IK) bearbeitet, und das Institut 

für Wirtschaftswissenschaften, Abteilung Controlling und Unternehmensrechnung (CU) 

bearbeitete das Teilprojekt 3. 

Die Teilprojekte 4/5 wurden von allen Instituten inhaltlich in Zusammenarbeit mit den Industriepartnern 

bearbeitet. Die Ziele der Pilotprojekte waren, den Einsatz von Produktentwicklungsmethoden 

zur Unterstützung unternehmensinterner und unternehmensübergreifender Innovationsprozesse 

in den Unternehmen der Projektpartner zu fördern. Unter der Förderung 

des Methodeneinsatzes ist zu verstehen, bereits in den Unternehmen eingesetzte Methoden in 

ihrer Anwendung zu verbessern, indem Methoden an die Randbedingungen der Entwicklungsaufgabe 

angepaßt werden, d.h. z.B. die räumliche Entfernung von Entwicklungspartnern 

berücksichtigt oder zeitaufwendige Methoden vereinfacht werden. Ein anderer Aspekt der 

Förderung des Methodeneinsatzes ist das Einführen und Etablieren von geeigneten, noch 

nicht in den Unternehmen eingesetzten Methoden. 

Durch die intensive Betreuung der Technischen Universität Braunschweig konnte der Methodeneinsatz 

in den Unternehmen verbessert und die Methodenkompetenz der Mitarbeiter sukzessive 

und nachhaltig aufgebaut werden. 

Die Anpassung und Neueinführung von Methoden erfolgte dabei zunächst nicht flächendeckend 

in den Unternehmen, sondern am Beispiel eines konkreten Produktentwicklungsprojekts, 

bei dem mehrere Partnerunternehmen kooperativ an einer Entwicklungsaufgabe arbeiteten. 

Im Rahmen des Pilotprojektes „Innovatives Frontendmodul“ entwickelten die Projektpartner 

Hella KGaA Hueck & Co., HBPO (Hella-Behr Plastic Omnium), Volkswagen AG 

und die Technische Universität Braunschweig im Verbund Konzepte für die Vorderwagenstruktur 

eines Niedrig-Verbrauch-Fahrzeugs. 

6


4 Erzielte Ergebnisse 

Die im Rahmen der einzelnen Teilprojekte erarbeiteten Ergebnisse sind im Folgenden aufgeführt. 

Eine detaillierte Beschreibung der Projektergebnisse erfolgt in einem gesonderten 

Fachbuch. 

Teilprojekt 1: Analyse der Innovationsprozesse in Unternehmen/ im Netzwerk 

• Entwicklung einer Methodik zur Analyse von Innovationsprozessen (Innovationsaudit) 

Teilprojekt 2: Methoden und Werkzeuge für Innovationsprozesse 

• Aufbau des Internetportals „Methodos“ – Assistenzsystem zur systematischen Methodenauswahl 

• Optimierung von Methoden, softwaretechnische Umsetzung ausgewählter Methoden 

(TRIZ-Tool, Funktionsgrößenmatrix) 

• Aufbau eines Bionik-Konstruktionskatalogs 

Teilprojekt 3: Aufbau eines Controlling-System 

• Entwicklung eines innovationsorientierten Projektcontrolling 

• Konzept einer Innovationserfolgrechnung 

• Definition eines Kooperationsprozesses zur Steuerung von F&E-Kooperationen 

• Konzept zur strategischen Make-or-Buy-Entscheidung in der Produktentwicklung 

• Entwurf einer aktivitätsorientierten Kooperationskostenrechnung 

• Konzept zur Anwendung von Kennzahlen im Kooperationsprozeß 

• Entwurf eines Risikomanagementsystem in F&E-Kooperationen 

• Entwicklung einer Methodik zur Partnersuche und -bewertung 

Teilprojekt 4/5: Implementierung neuer und optimierter Methoden/Pilotprojekte 

• Optimierung des Methodeneinsatzes in verteilten Entwicklungsprozessen in den Unternehmen, 

z.B. durch Vereinfachen zeitaufwendiger Methoden und gezieltes Einbringen von 

Teamarbeit 

• Systematische standortübergreifende Entwicklung von innovativen Konzepten für das 

Frontendmodul eines Niedrig-Verbrauch-Fahrzeugs 

• Erstellen von Teilkonzepten für den Zugang zum Frontraum, die Crashenergieaufnahme- 

Struktur, die Integration der Scheinwerfer und den Modulträger 

• Verbesserung der Kommunikation und des Datenaustauschs innerhalb eines verteilten 

Entwicklungsprojekts, z.B. durch Dokumenten-Management-System, Internet-Forum und 

Telefonkonferenzen 

• Durch Rapid Prototyping erstellter Demonstrator zur Funktionsüberprüfung des Scheinwerfer-Integrations-Konzepts 

7


• Virtual-Reality-Simulation der Montageprozesse der Frontends und der Ausfahrbewegung 

der integrierten Crash-Struktur 

Die beteiligten Institute haben mit der Bearbeitung des GINA-Projektes Fortschritte in Forschung 

und Entwicklung von Methoden zur Unterstützung von Innovationsprozessen in Unternehmensnetzwerken 

erzielt. Im Einzelnen waren dies: 

Institut für Konstruktionstechnik (IK) 

Bei der Entwicklung des Methodenassistenzsystem „Methodos“ wurde von Anfang an auf eine 

spätere Weiternutzung geachtet. Das System ist modular aufgebaut und ist somit beliebig 

erweiterbar. Das System kann somit für weitere Forschungstätigkeiten herangezogen werden 

und mit projektspezifischen Methodenwissen sukzessiv erweitert werden. 

Die Umsetzung des TRIZ-Tools, der Funktionsgrößenmatrix sowie des Konstruktionskatalogsystems 

„eKat“ wird über das Projekt Gina hinaus in anderen Projekten , sowie in der Lehre, 

bereits erfolgreich eingesetzt. 

Die angewendete Vorgehensmethodik sowie die Erkenntnisse zur Optimierung des Methodeneinsatzes 

bei verteilten Entwicklungsprojekten, die im Rahmen des Pilotprojektes „Entwicklung 

eines innovativen Car-Frontmoduls“ erarbeitet wurde, läßt sich über das Projekt 

hinaus auf verschiedenste Entwicklungsprojekte übertragen. 

Institut für Werkzeugmaschinen und Fertigungstechnik (IWF) 

Das entwickelte Softwarelösung „ImpAct“ eignet sich als Werkzeug für die Analyse von Innovationsprozessen 

und kann in anderen Forschungs- und Industrieprojekten eingesetzt werden. 

Auch die Bereitstellung von Lösungswissen in Form von Fallbeispielen, Literatur, etc. 

kann für die Entwicklung von Maßnahmen zur Optimierung des betrieblichen Innovationsprozesses 

in zukünftigen Projekten verwendet werden. 

Das im Rahmen des Projektes entwickelte Kriterienmodell eignet sich für die Bewertung von 

Innovationsprozessen. Bei der Programmierung des Softwarewerkzeuges wurden hohe Flexibilitätsanforderungen 

bei der Eingabe und Pflege des Kriterienmodells angestrebt und erreicht, 

so daß „ImpAct“ auch für die Anwendung anderer Kriterienmodelle geeignet ist. Große 

Synergien ergeben sich beispielsweise zum geplanten und zur Zeit in der Vorbereitungsphase 

befindlichem Projekt BMBF-PROFIL (Projektträger PFT). Die dort geplante Methodenauswahl 

zur integrierten Modernisierung anhand von Unternehmensprofilen kann mit der 

Systematik von ImpAct prinzipiell unterstützt werden. 

Institut für Wirtschaftswissenschaften - 

Abteilung Controlling und Unternehmensrechnung (CU) 

Durch die Interaktion zwischen den Industriepartnern und dem Institut wurden im Rahmen 

des unternehmensinternen Innovationscontrolling Erkenntnisse gewonnen, die für die weitere 

Forschungstätigkeit herangezogen werden können. Insbesondere das Konzept der Innovationserfolgsrechnung 

stellt hinsichtlich der immer stärkeren Fokuszierung auf eine wertorientierte 

Steuerung von Unternehmen ein interessanten Forschungsansatz dar. Zudem konnten 

durch die praxisorientierten Erkenntnisse bzw. Erfahrungen weitere Probleme, z.B. im Bereich 

des innovationsorientierten Projektcontrolling, identifiziert werden, die in der zukünftigen 

Forschung Berücksichtigung finden müssen. Bezüglich des unternehmensübergreifenden 

8


F&E-Controlling konnten ebenfalls praxisbezogene Erkenntnisse erarbeitet werden, wie z.B. 

im Hinblick auf Aufgaben, Instrumenten sowie möglicher Probleme innerhalb einer Forschungs- 

und Entwicklungskooperation. Besonders anhand des entwickelten Kooperationsprozeß 

wurden Instrumente zur Planung, Steuerung und Kontrolle der unternehmensübergreifenden 

Zusammenarbeit, z.B. eine Nutzwertanalyse zur Unterstützung der Make-or-buy- 

Entscheidung, entworfen, welches bereits in einem Unternehmen probehalber angewendet 

wurde. Diesbezüglich ergaben sich auch weitere Ansatzpunkte, welche zu einer über das GI- 

NA-Projekt hinausgehenden Zusammenarbeit mit der Praxis führte. 

Danksagungen 

An dieser Stelle möchten wir dem Bundesministerium für Bildung und Forschung (BMBF) 

sowie dem Projektträger des BMBF für Produktion und Fertigungstechnologien (PFT), Forschungszentrum 

Karlsruhe GmbH, unseren Dank für die Unterstützung des Verbundprojektes 

GINA zum Ausdruck bringen. 

Ein besonderes Dankeschön gilt Frau Martina Kühnapfel vom Projektträger PFT für die ausgezeichnete 

dreijährige Betreuung des Projektes. 

Wir möchten uns außerdem bei Herrn Dipl.-Ing. Robert Raulf von der Firma Hella-Behr Plastic 

Omnium (HBPO) recht herzlich für die gute Mitarbeit beim Pilotprojekt „Innovatives 

Frontendmodul“ bedanken. Als nichtgeförderter Projektpartner hat Herr Raulf durch sein Engagement 

entscheidend zum Gelingen des Pilotprojektes beigetragen. 

9


Veröffentlichungen, Vorträge, Referate 

Franke, H.-J.; Deimel, M.: Selecting and combining methods for complex problem solving 

within the design process, in: INTERNATIONAL DESIGN CONFERENCE - DESIGN 2004, 

Dubrovnik, 2004. 

Franke, H.-J.; Deimel, M.; Löffler, S.: Increasing the efficiency of Design Catalogues by using 

modern data processing technologies, in: INTERNATIONAL DESIGN CONFERENCE - 

DESIGN 2004, Dubrovnik, 2004. 

Herrmann, C.; Decker, C.; Mateika, M.: Life Cycle Strategy, in: INTERNATIONAL DE- 

SIGN CONFERENCE - DESIGN 2004, Dubrovnik, 2004. 

Franke, H.-J.; Deimel, M.; Löffler, S.: The Database “Methodos” assists an effective application 

of design methods, Research For Practice, International Conference on Engineering Design, 

ICED 03, Stockholm, 2003. 

Decker, C.; Mateika, M.: Ermittlung von Kundenanforderungen in den frühen Phasen der 

Produktentwicklung, in: Proceedings TQM Tag, 2004. 

Hesselbach, J.; Broistedt, K.-H.; Mateika, M.: Businessplan approach for new products, in: 

Proceedings ICED Conference, Stockholm, 2003. 

Herrmann, C.; Jagusch, B.; Mateika, M.: Werkzeug zur Auditierung von Innovationsprozessen, 

in: QZ (akzeptiert) 

Lachmayer, R.; Mateika, M.: Innovationsmanagement an der Schnittstelle von Forschung, 

Vor- und Serienentwicklung, in: Proceedings PLCM-Kongress, Frankfurt, 2003. 

Franke, H.-J.; Hesselbach, J.; Huch, B.; Deimel, M.; Fest, J.; Löffler, S.; Mateika, M.: Innovationsprozesse 

und F&E-Kooperationen ganzheitlich gestalten, in: wt Werkstatttechnik online, 

Heft 1/2, S., 87-90, 2003. 

Franke, H.-J.; Hesselbach, J.; Huch, B.; Firchau, N.; Löffler, S.; Mateika, M.: Erfolgreiche 

Innovation durch optimierte Kooperation, in Konstruktion 06/2003. 

Mateika, M.: „Das Projekt GINA“, Vorstellung des Projektes beim VDMA Cheferfahrungsaustausch 

am 27.11.2002 bei der Firma Klöckner DESMA Schuhmaschinen GmbH. 

10


Kooperationsassistent zur effizienten Gestaltung 

überbetrieblicher Produkt- und Prozessentwicklung 

(KOEFFIZIENT) 

5 Kooperationsassistent zur effizienten 

GÜNTER STAUB 

Zusammenfassung: Ziel von KOEFFIZIENT ist die Entwicklung eines dynamischen Kooperationsassistenten, 

der Unternehmen einfacher als heute möglich, zur IT-gestützten, unternehmensübergreifenden 

Kommunikation befähigt und damit den Aufbau und die Durchführung überbetrieblicher 

Entwicklungspartnerschaften unterstützt. Damit auch kleine und mittlere Unternehmen 

(KMU) von den entwickelten Lösungen profitieren können, wird bei der Konzeption des Kooperationsassistenten 

auf Einfachheit, Beherrschbarkeit und geringe Investitionskosten Wert gelegt. 

1 Ausgangssituation und Handlungsbedarf 

Die augenblickliche Situation ist gekennzeichnet durch global agierende Unternehmen, die im 

Zuge zunehmenden internationalen Wettbewerbs gezwungen sind, ihre Strukturen flexibel zu 

gestalten und sich auf ihre Kernkompetenzen zu konzentrieren, um innovative Produkt- und 

Prozessideen schnell umsetzen zu können. Da kaum ein Unternehmen alle erforderlichen 

Kompetenzen und Kapazitäten für die Entwicklung und/oder die Produktion komplexer Produkte 

vorhalten kann, werden unternehmensübergreifende Wertschöpfungsketten gebildet, in 

denen durch die Einbeziehung qualifizierter und spezialisierter Partner Entwicklungszeiten 

verkürzt, Qualität verbessert sowie die Risiken z.B. im Zusammenhang mit der Verwendung 

neuer Technologien oder Methoden auf ein Minimum reduziert. Eindrucksvoll wird diese 

Tendenz belegt durch eine Erhebung des VDA (Verband der Automobilindustrie), nach der in 

der deutschen Automobilindustrie heute im Durchschnitt nur noch 20 Prozent der Entwicklungsleistung 

intern erbracht wird, im Vergleich zu 60 Prozent noch vor 10 Jahren. Das Kooperieren 

in Netzen birgt sowohl Risiken, eröffnet aber auch große Chancen, insbesondere 

auch für Zulieferer. Gleichzeitig wird die Zusammenarbeit von weltweit operierenden Unternehmensteilen 

zunehmend wie zwischen unabhängigen Partnern gestaltet. 

Traditionelle überbetriebliche Wertschöpfungsketten waren bisher meist starr und durch einseitige 

Abhängigkeiten der Zulieferer gekennzeichnet. Derzeit finden hier einschneidende 

Veränderungen statt. Die Auswahl zwischen gleichartigen Angeboten konkurrierender Lieferanten 

ist nur noch bei Standardteilen üblich. Ausgewählt wird der Lieferant, der eine bedarfsgerechte 

Versorgung der Entwicklung und/oder der Produktion des Kunden sicherstellen 

kann und dessen Kompetenzen sich am besten mit den eigenen ergänzen. Auf diese Weise 

entstehen neue Partnerschaften entlang von Wertschöpfungsketten mit dem Ziel, diese insgesamt 

und gemeinsam wesentlich effizienter zu gestalten, anstatt die im jeweiligen Unternehmen 

laufenden Prozesse einzeln zu optimieren. 

Immer komplexer werdende Produkte sowie die stetige Erweiterung der Produktpaletten seitens 

der Herstellerfirmen (OEM „Original Equipment Manufacturer“) führen allerdings dazu, 

dass auch Entwicklungspartner, ob Lieferanten oder Dienstleister, immer komplexere Subsysteme 

bearbeiten. Diese weisen starke Abhängigkeiten untereinander auf, und zu ihrer Entwicklung 

müssen neben herkömmlichen, im wesentlichen geometriebezogenen Produktdaten 

11

Kooperationsassistent zur effizienten Gestaltung überbetrieblicher Produkt- und Prozessentwicklung (KOEFFIZIENT) 

in verstärktem Maß auch komplexe Strukturinformationen in Form von Stücklisten, Varianten 

und Konfigurationen verarbeitet und mehrmals im Entwicklungsprozess zwischen den Partnern 

kommuniziert werden. Damit führt die Notwendigkeit zur immer enger werdenden Zusammenarbeit 

von Partnern, Dienstleistern und Lieferanten bereits während der Produktentwicklung 

nicht nur zu einem überproportional steigenden Kommunikationsbedarf, sondern 

auch zu einer neuen Qualität der Kommunikation. 

Während herkömmliche Beziehungen zwischen Kunden, Entwicklungsdienstleistern und Zulieferern 

bisher meist starr und durch einseitige Abhängigkeiten seitens Dienstleister und Zulieferer 

gekennzeichnet waren, sind heutige Geschäftsbeziehungen flexibel, zunehmend auch 

kurzlebig (z.B. nur für die Dauer eines Entwicklungsprojekts) und einem schnellen Wandel 

unterworfen. Die Fähigkeit zur schnellen und zuverlässigen Integration der beteiligten Entwicklungspartner 

in einen gemeinsamen Entwicklungsprozess entwickelt sich dabei immer 

mehr zu einer strategischen Komponente. Ausgewählt wird nur der als Partner, der sowohl 

über das benötigte technische Know-how verfügt, das sich am besten mit den eigenen Kernkompetenzen 

ergänzt, der aber auch in der Lage ist, den wachsenden unternehmensübergreifenden 

Kommunikationsanforderungen im Entwicklungsprozess quantitativ und qualitativ 

Rechnung zu tragen. 

2 Gegenstand von KOEFFIZIENT 

Heutzutage scheiden KMU als mögliche Partner in größeren Entwicklungsverbünden häufig 

deswegen bereits im Vorfeld aus, da sie oftmals nicht über die geeignete informationstechnische 

Infrastruktur verfügen, um schnell und flexibel auf die Anforderungen der Auftrageber 

in Bezug auf eine unternehmensübergreifende, rechnerunterstützte Produktentwicklung 

reagieren zu können. Aber auch die informationstechnische Kommunikation der Engneering-Informationen 

stellt eine wesentliche Barriere zwischen den Partner in einem Engineering-Netzwerk 

dar, da bei den Unternehmen IT-Systeme (PDM/PLM, CAD, CAE, CAQ, 

ERP, etc.) unterschiedlichster Anbieter und Funktionalitäten im Einsatz sind. Zusätzlich sind 

die eingesetzten Systeme jeweils an unternehmensspezifischen Gegebenheiten angepasst. Ein 

Ansatz, der davon ausgeht, dass die gleichen Systeme bei allen Partnern des Engineering- 

Netzwerks eingesetzt werden, ist aufgrund der vielfältigen Kunden-Lieferanten-Beziehungen 

und der heterogenen Systemlandschaft nicht realistisch. 

Um als Partner, sei es nun als Entwicklungspartner oder aber als Komponenten- oder Teilelieferant 

auftreten zu können, ist es notwendig neben der Optimierung der Projekt- und Prozessorganisation 

die unternehmensübergreifenden, zunehmend rechnerunterstützten Entwicklungsprozesse 

besser zu beherrschen. Zur Überbrückung dieser Barrieren müssen folgende 

Voraussetzungen erfüllt werden: 

• Definition des unternehmensübergreifenden, gemeinsamen Entwicklungsprozesses und 

Abstimmung der Entwicklungsprozesse zwischen den Partnern. Hierzu müssen die 

Schnittstellenprozesse sowie auslösende Ereignisse und Eingangs- und Ausgangsinformationen 

dieser unternehmensübergreifenden Schnittstellenprozesse identifiziert und dokumentiert 

werden. 

• Festlegung der zwischen den Entwicklungspartnern auszutauschenden Informationen und 

deren Abbildung aufeinander. Hierbei ist zu berücksichtigen, dass neben den verschiedenen 

Begriffen und der Bedeutung von Informationswerten immer auch eine Abbildung der 

unterschiedlichen Strukturen notwendig ist, um Informationen er-folgreich zwischen den 

Partnern zu kommunizieren. 

12


• Herstellung der Interoperabilität der Systeme, die im gemeinsamen, unternehmensübergreifenden 

Entwicklungsprozess eingesetzt werden. Um zu erreichen, dass die bei den Partnern 

im Entwicklungsprozess eingesetzten IT-Systeme zusammenarbeiten, sind geeignete Adapter 

notwendig, welche die semantische Kopplung der eingesetzten IT-Systeme ermöglichen. 

Die Schaffung dieser Voraussetzungen ist zeit- und kostenintensiv, erfordert eine fundierte 

Kenntnis der derzeit verfügbaren Informations- und Kommunikationstechnologien (I&K) und 

ist ohne geeignete Werkzeuge nicht möglich. Insbesondere für KMU muss folgendes beherrsch- 

und einsetzbar sein: 

• Die Abstimmung zwischen Entwicklungspartnern bzw. zwischen Herstellern und Zulieferern 

zur Etablierung einer unternehmensübergreifenden Produktentwicklung ist zeitintensiv. 

• Die notwendige Anbindung der IT-Lösung (z.B. Entwicklung von Export- und Importkomponenten, 

Anbindung an die jeweiligen IT-Systeme) beim KMU an die IT-Lösungen 

der Entwicklungspartner zum operativen Betrieb einer rechnerunterstützten, unternehmensübergreifenden 

Produktentwicklung ist aufwendig. 

• Sowohl die Abstimmung zwischen den Beteiligten als auch die Schaffung der technischen 

Voraussetzungen dauert oftmals länger als das eigentliche Projekt. 

• Investitionen für Integrationslösungen bestehender Ansätze sind zu hoch. 

• Die Qualität der Kooperationslösungen ist oft mangelhaft und erschwert bzw. verhindert 

gar die IT-gestützte Produktentwicklung über Unternehmensgrenzen hinweg. 

Zur Verbesserung dieser Situation war ein Ansatz notwendig, der bestehende Konzepte für 

gemeinsame überbetriebliche Produktentwicklungen mit neuen I&K-Technologien verknüpft 

und darauf aufbauend neue, angemessene Methoden und Werkzeuge bereitstellt, die einen geringen 

Komplexitätsgrad aufweisen. 

Gegenstand des Projektes war die Entwicklung eines dynamischen Kooperationsassistenten, 

der Unternehmen einfacher als vorher möglich zur IT-gestützten, unternehmensübergreifenden 

Kommunikation befähigt und damit den Aufbau und die Durchführung überbetrieblicher 

Entwicklungspartnerschaften unterstützt. Damit insbesondere auch kleine und mittlere Unternehmen 

von den entwickelten Lösungen profitieren können, wurde ein besonderer Schwerpunkt 

auf die folgenden Aspekte gelegt: 

• Einfachheit der bereitgestellten Methoden und Werkzeuge. 

• Erhebliche Verkürzung des Abstimmungszeitraums zwischen den Entwicklungspartnern. 

• Nutzung existierender Informations- und Kommunikationslösungen und einfache Einbindung 

existierender Datenbestände. 

• Geringer Aufwand zur Anbindung der IT-Lösungen der Entwicklungspartner. 

• Geringe Investitionskosten für die notwendigen Integrationslösungen im Vergleich zu bestehenden 

Ansätzen. 

• Möglichkeit zur (ggf. parallelen) Nutzung unterschiedlicher Integrationsplattformen in verschiedenen 

Entwicklungsverbünden. 

• Unterstützung von kurzfristigen Entwicklungspartnerschaften und längerfristigen Allianzen. 

13


Der Kooperationsassistent besteht aus einer Komponente für das Daten- und Prozessmapping 

und einer Komponente für das Kooperationsmanagement. Das Datenmapping dient zur Ausführung 

der notwendigen strukturellen Transformationen der Engineering-Daten in eine vom 

jeweiligen Partner verständliche und durch seine Systeme verarbeitbare Form. Das firmenübergreifende 

Zusammenspiel der Engineering-Prozesse wird durch das Prozessmapping geregelt. 

Das Kooperationsmanagement organisiert und verwaltet die Engineering-Daten und 

die Engineering-Transaktionen der Entwicklungspartner entsprechend den Festlegungen des 

unternehmensübergreifenden Entwicklungsprozesses. Zur Erzeugung dieser zwei Komponenten 

und ihrer einfachen Anbindung an die IT-Infrastruktur eines Entwicklungsverbundes werden 

eine Reihe grafisch-interaktiver Komponenten bereitgestellt. Diese erfüllen u.a. die folgenden 

Funktionen: 

• Abstimmung des gemeinsamen Entwicklungsprozesses und Definition der firmenübergreifenden 

Aktivitäten, 

• Abstimmung der auszutauschenden Engineering-Daten und deren Abbildung auf die jeweiligen 

Partnersysteme sowie 

• Sicherstellung der Interoperabilität der Partnersysteme durch die Bereitstellung von Systemadaptern 

zur einfachen Verbindung der im Entwicklungsprozess eingesetzten IT- 

Systeme. 

Um diese Funktionen zu realisieren, wurden neben der Projektleitung und -koordination folgende 

Arbeitspakete definiert: 

• Anwendungsszenarien und Anforderungsermittlung 

• Softwarekonzeption 

• Softwareentwicklung 

• Methodenentwicklung 

• Pilotierung, Evaluierung 

• Anpassung der Software 

• Verbreitung der Ergebnisse 

Die Verwertung der softwarebezogenen Projektergebnisse durch die beteiligten IT-Lösungsanbieter 

wird durch eine gemeinsame Weiterentwicklung der Prototypen und Vermarktung 

einer kommerziellen Lösung durch die PDTec GmbH erfolgen. Bei den Anwendern werden 

die Projektergebnisse vornehmlich dazu benutzt, ihre unter-nehmensübergreifenden Prozessketten 

mit Entwicklungspartnern für einen digitalen Austausch von Produktdaten währen des 

Engineerings zu optimieren. Nach einer Pilotierungsphase sollen bei den Anwendern bereits 

frühzeitig weitere Kunden/Lieferanten in die durch den Kooperationsassistenten gestützte Engineering-Prozesskette 

eingebunden werden. 

3 Projektpartner zur Durchführung des Vorhabens 

Für die inhaltliche Durchführung des Projektes war die PDTec GmbH verantwortlich. Die 

PDTec GmbH. ist Anbieter von Softwareprodukten und Dienstleistungen rund um die Integration 

von Daten, Prozessen und IT-Systemen in der Produktentstehung und entwickelt in enger 

Zusammenarbeit mit ihren Kunden standardbasierte, optimierte Lösungen zur effizienteren 

Gestaltung der Informationsflüsse im Engineering. 

14


In der nachfolgenden Tabelle sind darüber hinaus alle am Verbundprojekt geförderten Industriepartner 

aufgeführt. Neben diesen geförderten Projektpartnern waren noch der VDMA (Verband 

Deutscher Maschinen- und Anlagenbau e.V., Fachverband Software) und die FVA (Forschungsvereinigung 

Antriebstechnik e.V.) als assoziierte Partner in das Forschungsvorhaben 

eingebunden. 

ZF Passau 

GmbH 

ARS NOVA Software GmbH 

Esslingen 

Gebr. Bellmer GmbH 

Maschinenfabrik, Niefern 

Forschungsstelle für Zahnräder 

und Getriebebau, TU 

München 

PDTec GmbH, Karlsruhe 

SLR GmbH, St. Leon-Rot 

EME-SLR, Eging a.See 

Zahnradfabrik Passau GmbH, 

Passau 

4 Ziele, Lösungsansatz und Ergebnisse von KOEFFIZIENT 

Das übergeordnete Ziel von KOEFFIZIENT war die organisatorische und informationstechnische 

Beherrschung von Engineering-Netzwerken zur überbetrieblichen Produktentwicklung. 

Zur Ausgestaltung dieser Engineering-Netzwerke wurden Methoden und Werkzeuge entwickelt, 

die deren Reaktionsgeschwindigkeit und Flexibilität nachhaltig erhöhen. 

Um die Verwertung und den Transfer der Projektergebnisse sicherzustellen, wurde besonderer 

Wert auf die Übertragbarkeit der methodischen Vorgehensweise bei dem Aufbau und dem 

Betrieb der Engineering-Netzwerke durch die Software-Werkzeuge gelegt. 

Zur effizienten Unterstützung dieser Methodik wurde ein Software-Werkzeugkasten zur Erzeugung 

des Kooperationsassistenten entwickelt, mit dem die in den Partnerunternehmen in 

der Produktentwicklung eingesetzten IT-Systeme miteinander gekoppelt werden können. 

Hierzu gehört auch, dass der aktuelle Zustand der partnerübergreifenden Engineering-Daten 

und -Prozesse ermittelt und dargestellt werden kann. 

15


Das Werkzeug erlaubt hierfür den kontrollierten Zugriff auf die relevanten Engineering-Daten 

aller am Prozess beteiligten Partner. Der entwickelte Ansatz berücksichtigt insbesondere, dass 

bei den einzelnen Partnern unterschiedliche IT-Systeme eingesetzt werden, die flexibel und 

ohne Änderungen an den IT-Systemen effizient in das Lösungskonzept eingebunden werden. 

4.1 Lösungsansatz 

Der Kooperationsassistent trägt den o.g. Zielen Rechnung, indem er eine lose informationstechnische 

Kopplung eines KMU an seine verschiedenen Kunden (z.B. OEM oder Systemlieferanten 

von OEM) ermöglicht. Im Gegensatz zu einem engen Integrationsansatz erlaubt dieser 

Ansatz eine von speziellen Kunden weitgehend unabhängige unternehmensübergreifende 

Zusammenarbeit im Engineering mit dem Vorteil von nur einer unternehmensspezifischen 

Benutzungsoberfläche pro Unternehmen. 

Kooperationsassist 

ent 

Zulieferer 

Hersteller 

id 

P 

ref 

A C D 

A B C D 

16 

P 

A C 

Kooperationsmanagement 

id 

Dat en- und 

Prozessmapping 

Dienstleister 

Abbildung 1: Lösungsansatz für den Kooperationsassistent zur Durchführung 

überbetrieblicher Entwicklungspartnerschaften 

Im Rahmen des Projekts wurde ein dynamischer Kooperationsassistent entwickelt (siehe Abbildung 

1), der den Aufbau und die Durchführung überbetrieblicher Entwicklungspartnerschaften 

unterstützt. Wie in der Abbildung dargestellt, besteht der Kooperationsassistent aus 

zwei Kernkomponenten: Daten- und Prozessmapping und Kooperationsmanagement: 

• Das Datenmapping dient zur Ausführung der notwendigen strukturellen Transformationen 

der Engineering-Daten in eine vom jeweiligen Partner verständliche und durch seine Sys-


teme verarbeitbare Form. Das firmenübergreifende Zusammenspiel der Engineering- 

Prozesse wird durch das Prozessmapping geregelt, indem beim Eintreten bestimmter Zustände 

das Partnersystem aktiviert und die notwendigen Engineering-Daten mithilfe des 

Datenmappings bereitgestellt werden. 

• Das Kooperationsmanagement organisiert und verwaltet die Engineering-Daten und die 

Engineering-Transaktionen der Entwicklungspartner. 

• Zur Erzeugung dieser Kernkomponenten und ihrer einfachen Anbindung an die IT- 

Infrastruktur eines Entwicklungsverbundes werden eine Reihe grafisch-interaktiver Komponenten 

bereitgestellt. Diese erfüllen u.a. die folgenden Funktionen: 


Aktivitäten, 

• Abstimmung der auszutauschenden Engineering-Daten und deren Abbildung auf die jeweiligen 




Systeme. 

Der gewählte Ansatz zur Erzeugung der zwei Komponenten ist in der folgenden Abbildung 

dargestellt. 

17


Gemeinsamkeiten 

und 

Deltas 


ent 

Schema 

Extraktor 

Schema 

Vergleicher 

Schema 

Extraktor 

Abbildungsspezifikation 

Metainformation 

PDM- System 1 


PDM- System 2 

grafisch, 

interaktiver 

Mappingmodellierer 

Erzeugung 

Daten- und 


IT-System 1 (z.B. PDM) 

Ereignisse, Kontrollflüsse 

18 

Partner 1 

Partner 2 

IT-System 2 (z.B. ERP) 

gemeinsames 

Datenmodell 

Entwicklungsprozess 

Part ner1 

Prozessmodellierer 


Part ner2 

Datenmodellierer 

Informationsflüsse 

Standards 

(BizTalk, STEP, ...) 

Erzeugung 


Abbildung2: Lösungsansatz zur Erzeugung des Kooperationsassistenten 

gemeinsamer 


Mit diesem Ansatz wird es zukünftig schneller und kostengünstiger als heute allen Entwicklungspartnern 

möglich sein, auf die im gemeinsamen Entwicklungsprozess anfallenden Daten 

der Partner zuzugreifen, zur direkten Weiterentwicklung in eigenen Systemen zu nutzen und 

sie den anderen Partnern wieder zur Verfügung stellen zu können. Hervorzuheben ist, dass 

erst durch die grafisch-interaktiven Komponenten insbesondere kleine und mittlere Unternehmen 

die mit dem Aufbau solcher Integrationslösungen verbundene Komplexität beherrschen 

können. 

4.2 Ergebnisse des Verbundprojekts 

Als Ergebnisse des Projekts sind der Software-Werkzeugkasten zur Erzeugung des dynamischen 

Kooperationsassistenten, zum anderen Spezifikationen, Methodiken und Erfahrungsberichte 

zu nennen. Der Software-Werkzeugkasten zur Erzeugung des dynamischen Kooperationsassistenten 

besteht im Wesentlichen aus den folgenden Komponenten:


• Adaptern zur Extraktion der Datenstrukturen und/oder Nutzdaten von Partnersystemen, 

insbesondere den folgenden PDM/PLM-Systemen: 

� Axalant/EIGNER PLM 

� eMatrix 

� iMAN (TeamCenter Engineering) 

� Metaphase (TeamCenter Enterprise) 

• Modul zum Vergleich von Datenstrukturen: 

� dient der gezielten Ermittlung von Unterschieden von Datenmodellen zwischen unterschiedlichen, 

bei den Kooperationspartnern eingesetzten IT-Systemen einerseits 

und/oder der Feststellung von Veränderungen (Customizations) an dem Datenmodell 

eines IT-Systems bei einem Kooperationspartner. 

• Modul zur grafisch interaktiven Spezifikation von Datenstrukturmappings 

� diese Komponente dient der einfachen, graphisch orientierten Spezifikation von Abbildungen 

zwischen den Datenstrukturen der IT-Systeme der Kooperationspartner 

� Codegenerator auf EXPRESS-X Basis (ISO 10303-14) zu automatischen Erzeugung 

von ausführbaren Mappingspezifikationen (=> Konvertersoftware) 

Weitere Ergebnisse des Verbundforschungsprojektes KOEFFIZIENT umfassen: 

• Spezifikationen zu den Software-Werkzeugen 

• Methodik zum Aufbau von Engineeringprozessketten für KMU und deren Durchführung 

mittels dem Kooperationsassistenten 

• Validierung anhand von ausgewählten Engineeringprozessketten aus den Anwendungsbereichen 

"Antriebstechnik" und "Maschinen- und Anlagenbau" 

• Pilotierung bei den Anwendern, Erfahrungsberichte 

Danksagung 

An dieser Stelle möchten wir dem Bundesministerium für Bildung und Forschung (BMBF) 

sowie dem Projektträger des BMBF für Produktion und Fertigungstechnologien (PFT), Forschungszentrum 

Karlsruhe GmbH, unseren Dank für die Unterstützung des Verbundprojektes 

KOEFFIZIENT zum Ausdruck bringen. 

Ein besonderes Dankeschön gilt Frau Martina Kühnapfel vom Projektträger PFT für die ausgezeichnete 

dreijährige Betreuung des Projektes. 

19


5 KOWIEN 

Kooperatives Wissensmanagement 

in Engineering-Netzwerken (KOWIEN) 

STEPHAN ZELEWSKI 

1 Gegenstand des Verbundprojekts KOWIEN 

1.1 Überblick 

Das Verbundprojekt KOWIEN (Kooperatives Wissensmanagement in Engineering-Netzwerken) 

1) befasst sich mit der Herausforderung, die arbeitsteilige Erfüllung wissensintensiver 

Engineering-Aufgaben in Netzwerken durch computerbasierte Arbeitstechniken zu unterstützen. 

Es handelt sich um einen vielschichtigen Projektgegenstand, dessen Hauptdeterminanten 

im Folgenden kurz thematisiert werden, um den Projektgegenstand inhaltlich einzugrenzen. 

Vertiefte Erläuterungen zu einzelnen Aspekten, die sowohl in der betrieblichen Praxis als 

auch in der universitären Forschung eine besondere Rolle spielen, finden sich im anschließenden 

Kapitel. 

Erstens wird von komplexen Engineering-Aufgaben ausgegangen, welche sowohl die zeitliche 

als auch die fachliche Problemlösungskapazität einzelner wirtschaftlicher Akteure übersteigen. 

Dies erfordert zwecks Aufgabenerfüllung Arbeitsteilung zwischen den Akteuren. Um die 

Arbeitsprozesse der involvierten Akteure zeitlich und fachlich aufeinander abzustimmen und 

zu einer Erfüllung der ursprünglich vorliegenden Gesamtaufgabe zusammenzuführen, müssen 

die Aktivitäten der Akteure bei der Erfüllung ihrer Teilaufgaben koordiniert werden. Für diese 

„generische“ Koordinierungsaufgabe wurden seitens der betriebswirtschaftlichen Organisationstheorie 

vielfältige Koordinierungsansätze entwickelt. 

Im Verbundprojekt KOWIEN erfolgt von vornherein eine Fokussierung auf zwei Aspekte. 

Einerseits wird ausschließlich eine Koordinierung durch Kooperation zwischen teilautonomen 

Akteuren betrachtet. Dadurch scheiden sowohl kompetitive Koordinierungsansätze – z.B. mittels 

(unternehmens-) interner oder externer Märkte – als auch Koordinierungsansätze aufgrund 

hierarchischer Anweisungen aus. Diese Eingrenzung wird in Kürze mit Hinblick auf 

Engineering-Netzwerke inhaltlich gerechtfertigt. Andererseits wird davon ausgegangen, dass 

die Arbeitsteilung zwischen den Akteuren nicht in quantitativer, sondern in qualitativer Hinsicht 

erfolgt. Denn die Bewältigung komplexer Engineering-Aufgaben stellt kein rein quantitatives 

Problem dar, das sich durch die Verteilung inhaltlich gleichartiger Teilaufgaben auf 

eine Vielzahl von Akteuren lösen ließe (mengenmäßige Arbeitsteilung). Vielmehr zeichnet 

sich die Komplexität solcher Engineering-Aufgaben u.a. dadurch aus, dass eine Vielfalt fachlich 

verschiedenartiger Qualifikationen benötigt wird, um die Gesamtaufgabe entsprechend 

1) Das Verbundprojekt KOWIEN wird mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) (Förderkennzeichen 

Hauptband 02 PD 1060) innerhalb des Rahmenkonzepts “Forschung für die Produktion von morgen” 

gefördert und vom Projektträger Produktion und Fertigungstechnologien (PFT), der Forschungszentrum Karlsruhe 

GmbH, betreut. Die Mitglieder des Projektteams danken für die großzügige Unterstützung ihrer Forschungs- und 

Transferarbeiten. Detaillierte Informationen zum Projekt finden sich im Internet unter der URL 

„http://www.kowien.uni-essen.de/“. 

21

Kooperatives Wissensmanagement in Engineering-Netzwerken (KOWIEN) 

den Kundenanforderungen erfüllen zu können (artmäßige Arbeitsteilung). Die Koordinierung 

der arbeitsteiligen Erfüllung einer Engineering-Aufgabe muss sich daher insbesondere auf die 

Dimension der Arbeitsqualifikationen erstrecken, die aus Projektsicht erforderlich und aus 

Akteurssicht tatsächlich vorhanden sind. 

Zweitens wird im Verbundprojekt KOWIEN vorausgesetzt, dass sich die komplexen Engineering-Aufgaben 

grundsätzlich durch ihre hohe Wissensintensität auszeichnen. Ohne in der hier 

gebotenen Kürze das Problem einer Operationalisierung der Wissensintensität von Arbeitsprozessen 

vertiefen zu können, lässt sich an die „Intuition des Alltagsverstands“ appellieren: 

Engineering-Leistungen werden sich in einem Hochlohnland wie Deutschland im internationalen 

Wettbewerb zumeist nur dann als konkurrenzfähig erweisen, wenn ihre Entwickler einen 

der wesentlichen komparativen Vorteile Deutschlands – sein (immer noch) sehr leistungsfähiges 

Aus- und Weiterbildungssystem – nutzen, indem sie einen möglichst hohen Anteil an 

Know-what (Fachkenntnisse) und Know-how (Herstellungs- und Anwendungsfertigkeiten) in 

die Engineering-Leistungen einfließen lassen. 

Die Arbeitsqualifikationen, die zur Erfüllung derart wissensintensiver Engineering-Aufgaben 

erforderlich sind, erstrecken sich daher zu einem großen und – vor allem aus wettbewerblicher 

Sicht – besonders wichtigen Teil auf das Wissen der beteiligten Akteure. Dieses Wissen 

ist besonderer Art. Denn es handelt sich nicht – oder zumindest nur in geringerem Umfang – 

um „akademisches“ Wissen, das um seiner selbst willen und zum Zwecke der Wahrheitserkenntnis 

erworben wird, wie z.B. Know-why (kausales Hintergrundwissen). Vielmehr wird 

zur Erfüllung wissensintensiver Engineering-Aufgaben primär anwendungs- oder verwertungsbezogenes 

Wissen benötigt. Es erstreckt sich vor allem auf die bereits angeführten Wissensformen 

des Know-what und Know-how. Sie werden im Folgenden der Kürze halber unter 

die Formulierung „Kenntnisse und Fertigkeiten“ subsumiert. 

Der Wissensbereich der anwendungsbezogenen Kenntnisse und Fertigkeiten wird im Rahmen 

des betrieblichen Wissensmanagements oftmals unter der Rubrik „Kompetenzen“ behandelt. 

Solche Kompetenzen lassen sich allgemein als handlungsbefähigendes Wissen charakterisieren. 

Dieser Kompetenzbegriff zielt darauf ab, dass die vorgenannten Kenntnisse und Fertigkeiten 

nicht um ihrer selbst willen erworben und angewendet werden. Vielmehr sollen sie die 

Akteure als Wissensträger in die Lage versetzen, in ihren betrieblichen Arbeitszusammenhängen 

so zu handeln, dass wissensintensive (Engineering-) Leistungen produziert werden. Die 

o.a. Dimension der Arbeitsqualifikationen wird für die hier betrachteten wissensintensiven 

Engineering-Leistungen fortan auf die Subdimension der (arbeitsbezogenen) Kompetenzen 

fokussiert. 

Für die Koordinierung der arbeitsteiligen Erfüllung von komplexen, insbesondere wissensintensiven 

Engineering-Aufgaben ist es aufgrund der voranstehenden Erläuterungen vor allem 

erforderlich, diejenigen Kompetenzen zusammenzuführen und aufeinander abzustimmen, die 

als handlungsbefähigendes Wissen zur Aufgabenerfüllung benötigt werden. Daher befasst 

sich das Verbundprojekt KOWIEN vornehmlich mit der Koordinierung von Kompetenzen 2) in 

2) Streng genommen ist die Koordinierung der Anwendung von Kompetenzen in Handlungen gemeint. Denn Koordinierung 

kann sich nur auf der prozessualen Ebene auf aktuelle Handlungen erstrecken. Kompetenzen stellen dagegen als 

handlungsbefähigendes Wissen „nur“ ein Potenzial für solche Handlungen bereit. Sofern diese Unterscheidung zwischen 

der Anwendung von Kompetenzen in Handlungen einerseits und den jeweils betroffenen Kompetenzen andererseits 

in einem Argumentationskontext keine besondere Bedeutung besitzt, wird der Kürze halber schlicht von einer 

„Koordinierung von Kompetenzen“ gesprochen. 

Mit der Koordinierung der (Anwendung von) Kompetenzen ist auch – daraus abgeleitet – eine Koordinierung (der 

Handlungen) der Akteure verknüpft, die als Träger jener Kompetenzen auftreten. Im Verbundprojekt KOWIEN steht 

jedoch nicht die Akteursperspektive, sondern die Sicht auf die zu koordinierenden Kompetenzen im Vordergrund. 

Für diese spezielle Kompetenzperspektive sprechen vor allem zwei Gründe, die inhaltlich miteinander verwoben 

sind. Erstens wird das Problem, die arbeitsteilige Erfüllung wissensintensiver Engineering-Aufgaben zu koordinieren, 

22


arbeitsteiligen Arbeitszusammenhängen. Diese übergeordnete Koordinierungsaufgabe erstreckt 

sich vor allem auf das Management von Wissen über Kompetenzen 3) . Solange aus dem 

jeweils aktuellen Argumentationskontext ersichtlich ist, dass stets das Management von Wissen 

über Kompetenzen der „Metaebene“ des Wissensmanagements 4) gemeint ist, wird im 

Folgenden der Kürze halber auch von „Kompetenzmanagement“ gesprochen. Computerbasierte 

Systeme, die bei der Erfüllung dieser Managementaufgabe behilflich sein sollen, werden 

entsprechend als „Kompetenzmanagementsysteme“ (KMS) bezeichnet 5) . Dennoch sollte 

stets berücksichtigt werden, dass mit dieser verkürzten Redeweise nicht das Management der 

Kompetenzen selbst, sondern „nur“ das Management des Wissens über diese Kompetenzen 

angesprochen wird. 

Die Gesamtaufgabe, Wissen über Kompetenzen zu managen, umfasst im Wesentlichen drei 

Teilaufgaben (Kernaufgaben) 6) : 

• die Identifizierung derjenigen Kompetenzen, die zur Erfüllung von wissensintensiven Engineering-Aufgaben 

erforderlich sind (aufgabenseitige Kompetenzenidentifikation), und 

die Aggregation der zur Aufgabenerfüllung erforderlichen Kompetenzen in einem aufgabenspezifischen 

Kompetenzprofil (aufgabenseitige Profilsynthese); 

• die Identifizierung derjenigen Kompetenzen, über die im aktuellen Zeitpunkt einzelne 

Akteure als Kompetenzträger verfügen (akteursseitige Kompetenzen- und Kompetenzträgeridentifikation), 

und die Aggregation der Kompetenzen eines Akteurs in einem akteursspezifischen 

Kompetenzprofil (akteursseitige Profilsynthese); 

hier so konzeptualisiert, dass der Koordinierungserfolg maßgeblich von der wechselseitigen Abstimmung der jeweils 

eingebrachten Kompetenzen abhängt. Dies bedeutet u.a., dass es für ein Koordinierungsproblem nur darauf ankommt, 

ob benötigte Kompetenzen aktuell vorhanden sind, aber nicht darauf, welche alternativ einsetzbaren Akteure über 

diese Kompetenzen verfügen. Zweitens wird – wie später anhand der Gegenüberstellung von Personalisierungs- und 

Kodifizierungsstrategie noch ausführlicher erläutert wird – von persönlichen Dispositionen der Akteure, wie etwa ihrer 

Motivierung zur Wissensoffenlegung und Wissensteilung, abstrahiert. Aufgrund dieser bewussten, später begründeten 

Abstrahierung von personengebundenen Akteursmerkmalen ist die erstgenannte Maßgeblichkeit der eingebrachten 

Kompetenzen für den Koordinierungserfolg gerechtfertigt. Auf dieser Grundlage werden im Verbundprojekt 

KOWIEN die Träger von Kompetenzen in einer „generalisierten“ Weise als organisatorische „Rollen“ behandelt, die 

von persönlichen Akteursmerkmalen abstrahieren. Die Rolle eines Kompetenzträgers wird nur durch dasjenige handlungsbefähigende 

Wissen definiert, das er zur Erfüllung einer ihm zu übertragenden oder bereits übertragenen Teilaufgabe 

benötigt. 

3) Das Wissen über Kompetenzen stellt streng genommen Metawissen dar. Denn die „gemanagten“ Kompetenzen besitzen 

auf der Objektebene der Leistungserbringung, d.h. auf der Ebene der Erfüllung von Engineering-Aufgaben, bereits 

die Qualität von handlungsbefähigendem Wissen. Daher handelt es sich bei Wissen über Kompetenzen inhaltlich 

um Wissen über handlungsbefähigendes Wissen und somit um Metawissen. Auf diese Besonderheit der hierarchischen 

Schichtung mehrerer Wissensebenen wird im Folgenden nicht gesondert eingegangen, sofern es im jeweils aktuellen 

Argumentationskontext nicht zum präzisen Verständnis erforderlich erscheint. Daher wird das Wissen über 

Kompetenzen der Einfachheit halber auch kurz als „Wissen“ thematisiert – auch wenn es sich streng genommen um 

Metawissen handelt. 

4) Dagegen werden die Engineering-Aufgaben, mit deren Koordinierung sich das Verbundprojekt KOWIEN auseinandersetzt, 

auf der „Objektebene“ der gewöhnlichen inner- oder überbetrieblichen Leistungserstellung erfüllt. 

5) Konzeptionelle Vorstellungen darüber, wie sich die Aufgabe des Kompetenzmanagements erfüllen lässt, werden als 

Kompetenzmanagementkonzepte thematisiert. Die Implementierung solcher Kompetenzmanagementkonzepte mit 

Hilfe der Automatischen Informationsverarbeitung – insbesondere durch Anwendungssoftware – wird unter den Begriff 

der Kompetenzmanagementsysteme subsumiert. 

6) In diesen drei Kernaufgaben kommen die Akteure, die mit ihren Kompetenzen an der arbeitsteiligen Erfüllung wissensintensiver 

Engineering-Aufgaben beteiligt sind (oder beteiligt sein könnten), nur so weit vor, wie sie als Träger 

von Kompetenzen auftreten. Dies betrifft insbesondere Probleme der zeitlichen Verfügbarkeit von Kompetenzträgern, 

wenn derselbe Akteur mit seinen Kompetenzen zur selben Zeit für die Erfüllung von mehreren Engineering- 

Aufgaben benötigt wird. Solche personalen Verfügbarkeitsprobleme spielen in der betrieblichen Praxis vor allem im 

Multi-Projekt-Management eine Rolle. Da im Verbundprojekt KOWIEN jedoch Aspekte der Personaleinsatzplanung 

nicht im Vordergrund des Interesses stehen, wird darauf hier nicht näher eingegangen. 

23


• die Zuordnung von Akteuren mit ihren Kompetenzen zu Engineering-Aufgaben (aufgabenbezogene 

Allokation von Kompetenzträgern) als „Matching“ zwischen den akteursund 

den aufgabenspezifischen Kompetenzprofilen. 

Die drei Kernaufgaben betreffen das Management von Wissen über drei unterschiedliche 

Kompetenzaspekte: Wissen über Kompetenzen im Sinne von handlungsbefähigendem Wissen, 

Wissen über Kompetenzträger und Wissen über Kompetenzprofile. Sofern keine nähere 

Differenzierung zwischen diesen drei Aspekten erforderlich ist, wird im Folgenden vereinfacht 

davon gesprochen, das Management von Kompetenzwissen – oder noch kürzer, wie bereits 

oben eingeführt: das Kompetenzmanagement – zu behandeln. 

Die Sachziele des Kompetenzmanagements bestehen darin, einerseits die benötigten Kompetenzen 

sowie andererseits die verfügbaren Kompetenzen und deren Kompetenzträger möglichst 

vollständig zu identifizieren. Als weiteres Sachziel kommt hinzu, bei der aufgabenbezogenen 

Allokation von Kompetenzträgern eine möglichst hohe Übereinstimmung zwischen 

erforderlichen und verfügbaren Kompetenzen zu erreichen (primäres Allokationsziel). Die Erfüllung 

dieser „outputorientierten“ Sachziele – Outputs sind die Identifikations- bzw. Allokationsleistungen 

– wird aus betriebswirtschaftlicher Perspektive im Allgemeinen als Effektivität 

des Kompetenzmanagements bezeichnet. 

Die Effizienz des Kompetenzmanagements erstreckt sich hingegen auf Formalziele, die eine 

Auswahl zwischen mehreren Entscheidungsalternativen gestatten, wenn sich mehrere Alternativen 

als „effektiv“ erweisen, d.h. die vorgegebenen Sachziele gleich gut erfüllen. Diese Effizienz- 

oder Formalziele betreffen zumeist – in Anlehnung an das allgemeine Prinzip ökonomischer 

Rationalität – das Verhältnis zwischen hervorgebrachten Ergebnissen (Output) und 

hierfür eingesetzten Ressourcen (Input). Demzufolge erweist sich das Kompetenzmanagement 

als besonders effizient, wenn es beispielsweise gelingt, vorgegebene Identifikations- oder Allokationsleistungen 

(als Output) mit besonders geringem Ressourceneinsatz (als Input) zu realisieren. 

Im Vordergrund des Forschungs- und Entwicklungsinteresses des Verbundprojekts KOWIEN 

steht die Effektivität von Kompetenzmanagementkonzepten und ihrer Implementierung mittels 

computerbasierter Kompetenzmanagementsysteme. Auf Effizienzaspekte wird nur am 

Rande eingegangen, weil Bemühungen zur „Optimierung“ des Verhältnisses zwischen Ergebniserzielung 

und hierfür erforderlichem Ressourceneinsatz erst dann anstehen, wenn die Effektivität 

des Kompetenzmanagements aus der Sicht seiner betrieblichen Anwender sichergestellt 

ist. Das Management von Kompetenzwissen leidet jedoch zurzeit noch unter erheblichen 

Effektivitätsmängeln. Darauf wird im nächsten Kapitel näher eingegangen. Daher widmen 

sich die Projektarbeiten primär der Überwindung solcher Effektivitätsmängel – und nicht dem 

Streben nach möglichst hoher Managementeffizienz 7) . 

7) Eine „sekundäre“ Verfolgung von Effizienzzielen liegt beispielsweise vor, wenn bei der aufgabenbezogenen Allokation 

von Kompetenzträgern das (Formal-) Ziel verfolgt wird, bei gleich hoher Übereinstimmung zwischen erforderlichen 

und verfügbaren Kompetenzen solche Zuordnungsalternativen auszuwählen, in denen ein möglichst „qualifikationsgerechter“ 

Einsatz der Kompetenzträger erfolgt. Ein solches qualifikationsbezogenes Ziel kann aus Gründen der 

Mitarbeitermotivation erstrebenswert sein. Allerdings weicht das Ziel des qualifikationsgerechten Mitarbeitereinsatzes 

deutlich vom vorherrschenden Denken ab, Effizienzziele auf Output/Input-Verhältnisse zu beziehen. Denn sowohl 

die Übereinstimmung zwischen erforderlichen und verfügbaren Kompetenzen (übergeordnetes Sachziel) als 

auch das Ausmaß der Qualifikationsgerechtigkeit der Mitarbeiterzuordnung (untergeordnetes Formalziel) beziehen 

sich auf den Output des Managementprozesses, Kompetenzträger zu Engineering-Aufgaben zuzuordnen. Daher werden 

hier Effizienzziele – abweichend von ihrer oftmals üblichen Fokussierung auf Output/Input-Verhältnisse – inhaltlich 

so weit ausgelegt, dass sie sich grundsätzlich mit betriebswirtschaftlichen Formalzielen identifizieren lassen. 

Noch kompliziertere Verhältnisse liegen vor, wenn die oben eingeführte Prämisse einer hierarchischen Unterordnung 

der Formal- unter die Sachziele aufgehoben wird. Stattdessen lässt sich beispielsweise vorstellen, dass in zahlreichen 

Einzelfällen ein Trade-off zwischen dem Sachziel einer möglichst hohen Übereinstimmung zwischen erforderlichen 

24


Neben den oben angeführten drei Kernaufgaben des Kompetenzmanagements lässt sich eine 

Vielzahl von ergänzenden Aufgaben identifizieren, die in der betrieblichen Praxis – unternehmens- 

und situationsabhängig – durchaus eine bedeutsame Rolle spielen können. Dazu 

gehört beispielsweise die Aufgabe, Kompetenzlücken zu identifizieren. Solche Kompetenzlücken 

können zwischen denjenigen Kompetenzen, die für die Erfüllung einer Engineering- 

Aufgabe erforderlich sind, und denjenigen Kompetenzen klaffen, die in einem Unternehmen 

seitens seiner Kompetenzträger aktuell zur Verfügung stehen. Nach der Identifizierung solcher 

Lücken stellt sich für das Kompetenzmanagement das nachgelagerte Problem, wie mit 

den Kompetenzlücken umgegangen werden soll. Aus betriebswirtschaftlicher Perspektive 

handelt es sich hierbei um eine spezielle Ausprägung („Instanz“) aus der Klasse der Make-or- 

Buy-or-Ignore-Probleme 8) : Erstens können die erforderlichen, jedoch aktuell nicht verfügbaren 

Kompetenzen selbst aufgebaut werden (Make-Alternative), beispielsweise durch Qualifi- 

und verfügbaren Kompetenzen einerseits und dem Formalziel eines möglichst qualifikationsgerechten Einsatzes der 

Kompetenzträger andererseits besteht. Dann braucht dieser Trade-off keineswegs zwangsläufig im Sinne der Dominanz 

des Sachziels über das Formalziel aufgelöst zu werden. Vielmehr könnte ebenso eine „Kompromisslösung“ angestrebt 

werden, bei der Sach- und Formalziele mit Zielgewichten, die vom jeweiligen Entscheidungsträger gemäß 

seinen Artenpräferenzen festzulegen wären, in einer verallgemeinerten Ziel- oder Nutzenfunktion zusammengefasst 

werden. Dies wäre z.B. bei Nutzwert- und Scoring-Analysen der Fall. Bei der Verwendung solcher verallgemeinerter 

Ziel- oder Nutzenfunktionen geht die Unterscheidung zwischen Sach- und Formalzielen verloren, weil alle Ziele 

prinzipiell gleichberechtigt behandelt werden, allenfalls mittels unterschiedlicher Zielgewichte hinsichtlich ihrer relativen 

Bedeutungen graduell abgestuft werden können. Von Komplikationen dieser Art wird aber im Folgenden der 

Übersichtlichkeit halber abgesehen. 

8) Die Bezugnahme auf Make-or-Buy-or-Ignore-Probleme stellt eine Vergröberung dar. Zwar reicht sie für die hier verfolgten 

Argumentationszwecke zur Verdeutlichung der grundsätzlichen Alternativen aus. Aber sie vermag bei weitem 

nicht die inhaltliche Fülle betriebswirtschaftlich vorstellbarer Problemvarianten abzudecken. Insbesondere handelt es 

sich bei der Make- und der Buy-Alternative jeweils nur um eine Antipode eines facettenreichen Spektrums unterschiedlicher 

„institutioneller Arrangements“ für die Koordinierung von Transaktionsprozessen. Insbesondere ist an 

Kooperationen zu denken (Cooperate-Alternative), die als „hybride“ Koordinierungsform zwischen der hierarchievermittelten 

Koordinierung unternehmensinterner Leistungserstellungsprozesse (Make-Alternative) und der marktvermittelten 

Koordinierung des Leistungserwerbs von Dritten (Buy-Alternative) angesiedelt sind. Auch solche Kooperationen 

können genutzt werden, um identifizierte Kompetenzlücken zu schließen. Zu diesem Zweck werden Kooperationen 

mit anderen Unternehmen, die über Mitarbeiter mit entsprechenden Kompetenzen verfügen, eingegangen. 

Auf diese Weise wird – zumindest auf den ersten Blick – die erforderliche Kompetenz weder selbst aufgebaut 

noch von Dritten (außerhalb der Kooperation) käuflich erworben. Vielmehr wird diese Kompetenz von den kooperierenden 

Unternehmen gemeinsam genutzt, ohne dass sich die involvierten Unternehmen mittels hierarchischer Anweisungsbeziehungen 

oder marktlicher Austauschbeziehungen koordinieren würden. Stattdessen wird in Kooperationen 

auf Koordinierungsmuster sui generis „jenseits von Hierarchie und Markt“ zurückgegriffen. Es würde jedoch in diesem 

Überblicksbeitrag zu weit führen, diese komplexen Koordinierungsmuster detailliert zu behandeln. Daher wird in 

der o.a. Bezugnahme auf Make-or-Buy-or-Ignore-Probleme der Einfachheit und der Kürze halber darauf verzichtet, 

die Cooperate-Alternative ausdrücklich zu erwähnen. Durch diese Argumentationsverschlankung wird jedoch auf 

keinen Fall verkannt, dass die kooperative Nutzung von Kompetenzen große betriebswirtschaftliche Bedeutung für 

das Kompetenzmanagement in der betrieblichen Praxis erlangen kann. Vgl. dazu beispielsweise die ausführliche und 

theoretisch fundierte Diskussion der drei o.a. Make-, Buy- und Cooperate-Alternativen durch LAMMERS, M.: Make, 

Buy or Share – Combining Resource Based View, Transaction Cost Economics and Production Economies to a Sourcing 

Framework. In: Wirtschaftsinformatik, 46. Jg. (2004), S. 204-212, insbesondere S. 208 ff. (dort wird die Cooperate- 

allerdings abweichend als Share-Alternative thematisiert). 

Darüber hinaus werden alle weiter führenden Aspekte ausgeblendet, wie z.B. der fließende Übergang zwischen der 

Cooperate- und der Make-Alternative. Denn Kooperationen werden des Öfteren in einer strategischen Absicht eingegangen, 

die letztlich doch auf den Aufbau eigener Kompetenzen wie bei der Make-Alternative abzielt. Dabei werden 

die erforderlichen, aber (noch) nicht verfügbaren Kompetenzen zunächst nicht selbst entwickelt, sondern von einem 

Kooperationspartner in einen gemeinsam genutzten Kompetenzenpool eingebracht. Im Verlauf der Kooperationsbeziehung 

lässt das strategisch agierende Unternehmen seine eigenen Mitarbeiter die benötigten Kompetenzen durch 

Nutzung der Kompetenzen des Partners allmählich erlernen („learning by doing“), so dass das Unternehmen am Ende 

eines längeren Lernprozesses die ursprünglich fehlenden Kompetenzen doch noch „selbst“ entwickelt hat. Schließlich 

kann nach erfolgreich abgeschlossenem Kompetenzerwerb auf den ursprünglich benötigten Kooperationspartner verzichtet 

werden – die ursprünglich „partnerschaftlich“ eingegangene Kooperation wird gekündigt. Dieser Aufbau eigener 

Kompetenzen durch „Umarmung“ und „kognitive Enteignung“ von Kooperationspartnern stellt ein ernsthaftes 

betriebswirtschaftliches Problem dar. Dies gilt insbesondere im Kontext Virtueller Unternehmen, weil sie – zumindest 

in ihrer „naiven“ Variante – von vornherein auf zeitlich begrenzte Kooperationen angelegt sind und sich wegen 

der „Virtualisierung“ gemeinsamer Aufbauorganisationen sehr leicht wieder auflösen lassen. 

25


zierungsmaßnahmen der Personalentwicklung. Zweitens ist es möglich, diese Kompetenzen 

von Dritten zu erwerben (Buy-Alternative), z.B. durch Abwerbung entsprechender Kompetenzträger 

aus anderen Unternehmen. Drittens kann auf die Schließung der erkannten Kompetenzlücke 

bewusst verzichtet werden (Ignore-Alternative), weil etwa angenommen wird, dass 

der Auftraggeber einer Engineering-Leistung den partiellen Kompetenzmangel nicht bemerken 

wird. Die letztgenannte Alternative beruht auf der Annahme opportunistischen Verhaltens 

bei Informationsasymmetrie, die vor allem in der ökonomischen Theorie der Prinzipal- 

Agenten-Probleme eine herausragende Rolle spielt. Im Verbundprojekt KOWIEN werden 

solche „Abgründe“ des Kompetenzmanagements, die auch Fragen der Unternehmenskultur 

und -ethik aufwerfen, jedoch nicht weiter vertieft. Stattdessen fokussieren sich die Projektarbeiten 

auf die drei o.a. Kernaufgaben des Kompetenzmanagements. Weiter führende ergänzende 

Aufgaben wurden nur ausnahmsweise und nur in dem Ausmaß gestreift, wie sie bei den 

Partnerunternehmen des Verbundprojekts in deren betrieblicher Praxis von Interesse sind. 

Drittens teilen die Partner des Verbundprojekts KOWIEN die Einschätzung, dass sich komplexe, 

wissensintensive Engineering-Aufgaben am besten – im Sinne der vorgenannten Effektivitäts- 

und Effizienzziele – erfüllen lassen, wenn die Aufgabenerfüllung durch teilautonome 

Akteure erfolgt, die in einem Netzwerk interagieren. Für diese Einschätzung sprechen im Wesentlichen 

zwei Argumente. Einerseits erweist sich die Koordination arbeitsteilig zusammenwirkender 

Akteure über Märkte zumeist als ungeeignet, wenn die zu koordinierenden Teilleistungen 

jeweils eine komplexe, nur schwer durch einige wenige Merkmale beschreibbare 

Struktur aufweisen und sich nur unter erheblichen Schwierigkeiten monetär bewerten lassen. 

Diesen Charakteristika werden wissensintensive Engineering-Aufgaben in der Regel gerecht. 

Andererseits ist von einer Koordination der Akteure über hierarchische Anweisungen innerhalb 

eines Unternehmens ebenso abzuraten, wenn die Qualität der zu koordinierenden Teilleistungen 

in hohem Ausmaß von inhaltlichen Ermessensspielräumen und Eigeninitiativen der 

ausführenden Akteure abhängt. Auch diese letztgenannten Voraussetzungen liegen bei wissensintensiven 

Engineering-Aufgaben im Allgemeinen vor. Aus den voranstehenden Gründen 

eignen sich für die Koordination von Akteuren bei der arbeitsteiligen Erfüllung wissensintensiver 

Engineering-Aufgaben tendenziell am ehesten „hybride“ Koordinationsformen „zwischen 

Markt und Hierarchie“, die in der organisationswissenschaftlichen Literatur zumeist als 

Netzwerk-Organisationen thematisiert werden. 

Von solchen Netzwerk-Organisationen wird im Verbundprojekt KOWIEN grundsätzlich ausgegangen. 

Ihre Akteure handeln „teilautonom“, weil sie einerseits bei ihrer Aufgabenerfüllung 

weit gehend frei von hierarchischen Arbeitsanweisungen bleiben (Autonomieaspekt), jedoch 

andererseits im Interesse der arbeitsteiligen Erfüllung einer Gesamtaufgabe durch die 

Handlungsweisen aller anderen kooperierenden Akteure und das gemeinsam angestrebte 

Handlungsergebnis – die Aufgabenerfüllung – einschränkenden Rahmenbedingungen unterliegen 

(Restriktionsaspekt). Von sekundärer Bedeutung ist, ob solche Netzwerk-Organisationen 

entweder innerhalb eines bestehenden Unternehmens (innerbetriebliche Netzwerke) oder 

aber zwischen mehreren rechtlich selbstständigen Unternehmen (überbetriebliche Netzwerke) 

zustande kommen. Beispiele für innerbetriebliche Netzwerke sind Projektgruppen als häufigste 

Form einer Sekundärorganisation, welche die „dauerhafte“, primäre Aufbauorganisation eines 

Unternehmens temporär, d.h. bis zur Erreichung der Projektziele, überlagert. Konsortien 

und Virtuelle Unternehmen sind hingegen die bekanntesten Vertreter überbetrieblicher Netzwerke. 

Da es für die Forschungs- und Entwicklungsinteressen des Verbundprojekts KOWIEN 

unerheblich ist, ob die betrachteten wissensintensiven Engineering-Aufgaben in entweder inner- 

oder aber überbetrieblichen Netzwerken erfüllt werden, wird die Gesamtheit dieser 

Netzwerk-Organisationen unter den Oberbegriff der Engineering-Netzwerke subsumiert. 

26


Eine vierte wesentliche Einschränkung für den Gegenstandsbereich des Verbundprojekts 

KOWIEN besteht darin, dass eine Fokussierung auf computerbasierte Arbeitstechniken erfolgt. 

Über diesen Fokus lässt sich trefflich streiten. So wird seit Ende der neunziger Jahre in 

der einschlägigen Fachliteratur intensiv darüber debattiert, ob Aufgaben des Wissensmanagements 

besser erfüllt werden könnten, indem die knappen Managementressourcen entweder 

auf Mitarbeiter als Kompetenzträger oder aber auf Automatische Informations- und Wissensverarbeitungssysteme 

9) konzentriert werden. Diese Debatte wird oftmals unter den Etiketten 

„Humankapital- versus Automatisierungsfokus“ oder „Personalisierungs- versus Kodifizierungsstrategie“ 

ausgetragen, in den letzten Jahren beispielsweise inspiriert und prononciert 

vorangetrieben von drei US-amerikanischen „Gurus“ des Wissensmanagements, HANSEN, 

10) 

NOHRIA und TIERNEY . 

Die Schwerpunktsetzung des Verbundprojekts KOWIEN zugunsten computerbasierter Arbeitstechniken 

bedeutet keineswegs, dass die Projektpartner die große Bedeutung des Humankapitals 

für das Wissensmanagement verkennen würden. Stattdessen sahen sie sich nur aufgrund 

von exogenen Randbedingungen – knapper personeller, finanzieller sowie zeitlicher 

Projektressourcen – genötigt, einen der beiden o.a. Aspekte des Wissensmanagements zu bevorzugen, 

um zumindest diesen Aspekt in der gebotenen Breite und Tiefe behandeln zu können. 

Dass diese Vertiefungsentscheidung zugunsten computerbasierter Arbeitstechniken ausfiel, 

beruht letztlich auf den kontingenten Vorgaben des Rahmenkonzepts „Forschung für die 

Produktion von morgen“, innerhalb dessen das Verbundprojekt KOWIEN thematisch angesiedelt 

ist. Darüber hinaus wird vom Universitätspartner des Verbundprojekts der „ganzheitlichen“ 

Charakteristik des Wissensmanagements dadurch Rechnung getragen, dass die Antipode 

zum Computereinsatz – die Fokussierung auf das Humankapital – in einem anderen Projekt 

zum Wissensmanagement ausführlicher und bevorzugt untersucht wird. Es handelt sich 

um das Verbundprojekt MOTIWIDI 11) , das ebenso vom BMBF gefördert wird. Dieses Projekt 

befasst sich speziell mit der Motivation von Akteuren in Dienstleistungs-Netzwerken, einerseits 

ihr Wissen, das zur Erbringung wissensintensiver Dienstleistungen erforderlich ist, gegenüber 

anderen Akteuren im Netzwerk offen zu legen (Wissensteilung durch Wissensoffenlegung), 

und andererseits das Wissen anderer Akteure auch für die eigene Leistungserbringung 

aktiv zu nutzen (Wissensteilung durch Wissenswiederverwendung). Die Projekte MO- 

9) Der ebenso „endlos“ wie „unfruchtbar“ erscheinende Streit über inhaltliche Abgrenzungen zwischen Daten-, Informations- 

und Wissensbegriff, der in zahlreichen Werken zum Wissensmanagement ausgetragen wird, erfährt im Verbundprojekt 

KOWIEN keine Vertiefung. Stattdessen reicht es für die Forschungs- und Entwicklungsziele des Projekts 

vollkommen aus, Informationen und Wissen als synonyme Begriffe zu verwenden (und vom „althergebrachten“ 

Datenbegriff abzusehen). Damit wird keineswegs in Abrede gestellt, dass es für andere, außerhalb des Verbundprojekts 

liegende Erkenntnisziele durchaus relevant sein kann, zwischen Daten, Informationen und Wissen inhaltlich zu 

differenzieren. Allerdings besteht die Gefahr, dass Leser, die von einem speziellen Vorverständnis über Unterscheidungen 

zwischen Informations- und Wissensbegriff ausgehen, die hier vorgelegten Ausführungen zum Verbundprojekt 

KOWIEN missverstehen, weil sie der Ansicht sind, dass die jeweils thematisierten Verarbeitungsfunktionen entweder 

mit ihrem Informations- oder mit ihrem Wissensbegriff nicht kompatibel seien. Um solchen Missverständnissen 

vorzubeugen, wird die Bezeichnung „Automatische Informations- und Wissensverarbeitungssysteme“ gewählt. 

Sie fällt zwar sprachlich etwas „voluminös“ und wegen der synonymen Verwendung von Informations- und Wissensbegriff 

streng genommen auch redundant aus. Dafür bietet sie aber den Vorzug zu signalisieren, dass Rezipienten 

mit unterschiedlichen Vorverständnissen – je nach ihren eigenen begrifflichen Vorlieben – die hier behandelten computerbasierten 

Systeme sowohl als Informations- als auch als Wissensverarbeitungssysteme auffassen können. Wem 

diese Redeweise zu umständlich erscheint, kann der Kürze halber nur von Kompetenzmanagementsystemen sprechen, 

da die hier behandelten computerbasierten Systeme ausschließlich für Aufgaben des Kompetenzmanagements 

konzipiert sind. 

10) Vgl. HANSEN, M.T.; NOHRIA, N.; TIERNEY, T.: What’s Your Strategy for Managing Knowledge? In: Harvard Business 

Review, 1999, No. March - April, S. 106-116; hier: S. 107 ff. 

11) Nähere Informationen zum Verbundprojekt „Motivationseffizienz in wissensintensiven Dienstleistungsnetzwerken“ 

(MOTIWIDI) finden sich im Internet unter der URL „http://www.motiwidi.de“. Vgl. auch die dort angeführten Veröffentlichungen 

über Ergebnisse der Projektarbeiten. 

27


TIWIDI und KOWIEN verhalten sich somit komplementär zueinander und überdecken das 

breite Spektrum eines ganzheitlich verstandenen Wissensmanagements sowohl hinsichtlich 

der Personalisierungs- (Humankapitalfokus) als auch hinsichtlich der Kodifizierungsstrategie 

(Automatisierungsfokus). 

Die fünfte – und letzte – Hauptdeterminante des Gegenstandsbereichs für das Verbundprojekt 

KOWIEN stellt die inhaltliche Reichweite des zentralen Begriffs der Kompetenzträger dar. 

Auf den ersten Blick handelt es sich bei den Kompetenzträgern um die Mitarbeiter eines Engineering-Netzwerks, 

die bei der arbeitsteiligen Erfüllung von Engineering-Aufgaben zusammenwirken. 

Diese „natürlich“ anmutende Sichtweise lag auch den einleitenden Ausführungen 

zugrunde, in denen die relevanten Akteure stets im Sinne von Mitarbeitern thematisiert 

wurden. 

Es besteht jedoch keine inhaltliche Notwendigkeit, eine derart eingeschränkte Sichtweise aufrecht 

zu erhalten. Insbesondere würde sie nur der Personalisierungsstrategie des Wissensmanagements 

gerecht werden, die nicht im Fokus des Verbundprojekts KOWIEN steht. Stattdessen 

konzentriert sich dieses Projekt auf die Kodifizierungsstrategie und somit auf computerbasierte 

Arbeitstechniken. Daher kommen als Kompetenzträger ebenso „maschinelle“ Akteure 

in Betracht, wie z.B. Wissensbanken, Wissensbasierte Systeme 12) und Multi-Agenten- 

Systeme. Wissensbanken und Wissensbasierte Systeme lassen sich unmittelbar als Kompetenzträger 

identifizieren, wenn sie handlungsbefähigendes Wissen (passiv) speichern und – im 

Fall der Wissensbasierten Systeme – auch zur Problemlösung (aktiv) anwenden. Multi- 

Agenten-Systeme umfassen Kompetenzträger als „artifizielle“ Akteure, sofern die einzelnen 

Agenten eines solchen Systems hinreichend „mächtig“ modelliert, also mit handlungsbefähigendem 

Wissen ausgestattet wurden. In einer ersten groben, aber hier völlig ausreichenden 

Annäherung lassen sich die einzelnen Agenten jeweils als eigenständige Wissensbasierte Systeme 

auffassen, die um eine komplexe, ebenso automatisierte Kommunikation und Koordination 

zwischen den Agenten zwecks arbeitsteiliger Kooperation erweitert werden. Um zwischen 

den vorgenannten (und weiteren) Varianten „maschineller“ Akteure nicht im Einzelnen 

differenzieren zu müssen, werden sie hier unter dem Oberbegriff der Automatischen Informations- 

und Wissensverarbeitungssysteme zusammengefasst 13) . Mit dieser Ausweitung von 

Kompetenzträgern auf „maschinelle“, d.h. computerbasierte Akteure dringt das Verbundprojekt 

KOWIEN in die Gestaltungsbereiche von Wirtschaftsinformatik, (Kern-) Informatik und 

Erforschung Künstlicher Intelligenz (KI) vor. Aus diesen Wissenschaftsbereichen werden 

neuere Erkenntnisse übernommen, um die Forschungs- und Entwicklungsarbeiten des Verbundprojekts 

inhaltlich zu befruchten. Dies gilt insbesondere im Hinblick auf Vorgehensmodelle 

und Ontologien, auf die später noch ausführlich zurückgekommen wird. 

12) Wissensbasierte Systeme werden vielfach auch als Expertensysteme thematisiert. Der Verfasser bevorzugt die Bezeichnung 

„Wissensbasierte Systeme“ aus drei Gründen. Erstens wird das personalisierende Präfix „Experten-“ vermieden, 

das vielfach zu irreführenden – oder zumindest problematischen – Assoziationen verleitet. Sie können in der 

hier gebotenen Kürze nicht vertieft werden, so dass nur schlagwortartig auf die Debatte über die starke versus schwache 

„KI-These“ verwiesen sei; vgl. z.B. ZELEWSKI, S.: Searle's Wiederbelebung der starken KI-These – Ein Beitrag 

zur Diskussion des Erkenntnisprogramms der Erforschung Künstlicher Intelligenz (KI). In: Casati, R.; White, G. 

(Hrsg.): Philosophy and the Cognitive Sciences, Papers of the 16th International Wittgenstein Symposium, 15.- 

22.08.1993 in Kirchberg, Beiträge der Österreichischen Ludwig Wittgenstein Gesellschaft (Nr.) 1, Kirchberg 1993, S. 

611-616. Zweitens werden die Schwierigkeiten, eine operationale Definition des Expertenstatus anbieten zu müssen, 

vorn vornherein umgangen. Drittens bringt das Attribut „wissensbasiert“ sehr anschaulich zum Ausdruck, worin die 

Besonderheit der „Informations“-Verarbeitung solcher Systeme liegt. 

13) Sofern die Automatischen Informations- und Wissensverarbeitungssysteme eingesetzt werden, um Wissen über 

Kompetenzen (computerbasiert) zu managen, werden sie auch kurz als Kompetenzmanagementsysteme bezeichnet. 

Diese Bezeichnung wurde schon weiter oben eingeführt. 

28


Über diese dezidiert computerorientierte Ausweitung des zentralen Begriffs der Kompetenzträger 

hinaus wird im Verbundprojekt KOWIEN auch eine organisationale Perspektive auf 

handlungsbefähigendes Wissen eingenommen. Aus dieser letztgenannten Perspektive kommen 

„kollektive“ Kompetenzträger hinzu, deren handlungsbefähigendes Wissen sich weder in 

einzelnen Mitarbeitern („Menschen“) noch in einzelnen Automatischen Informations- und 

Wissensverarbeitungssystemen („Maschinen“) lokalisieren lässt. Vielmehr ist das handlungsbefähigende 

Wissen über Organisationen als Agglomerate von Menschen und Maschinen so 

verteilt („verschmiert“), dass es nur der Organisation als Ganzheit zugeschrieben werden 

kann. Daher wird oftmals auch von „Organisationswissen“, „organisationalem Wissen“ oder 

„organisatorischem Gedächtnis“ gesprochen. Da dieses handlungsbefähigende, an Organisationen 

gebundene Wissen in der betrieblichen Praxis eine große Bedeutung für die Erfüllung 

wissensintensiver Aufgaben erlangen kann 14) , wird es hier – trotz seiner schweren „Greifbarkeit“ 

– in die Reichweite der Forschungs- und Entwicklungsbemühungen des Verbundprojekts 

von vornherein einbezogen. 

Organisationales Wissen kann in Organisationseinheiten auf verschiedenen Organisationsebenen 

angesiedelt sein. Beispielsweise lässt sich organisationales Wissen sowohl auf der Ebene 

einzelner Abteilungen als auch innerhalb eines gesamten Unternehmens identifizieren, in seltenen 

Fällen sogar auch einem Netzwerk aus mehreren rechtlich selbstständigen Unternehmen 

insgesamt zuordnen. Der letztgenannte Fall tritt vor allem in Virtuellen Unternehmen „der 

zweiten Generation“ auf. Sie zeichnen sich dadurch aus, dass die Partnerunternehmen zwar in 

Abhängigkeit von den jeweils übernommenen Aufträgen (Projekten) auftragsspezifische und 

temporäre Partnerkonfigurationen eingehen (wie es schon für Virtuelle Unternehmen „der ersten 

Generation“ typisch ist), aber darüber hinaus ein stabiles und somit langfristig vertrauensstiftendes 

Netzwerk potenzieller Projektpartner darstellen. In solchen stabilen Netzwerken 

kann sich im Zeitverlauf z.B. handlungsbefähigendes Wissen über die zweckmäßige Koordinierung 

mit anderen Partnern desselben Netzwerks herausbilden, das aus betriebswirtschaftlicher 

Perspektive als spezielle Koordinierungs- oder Netzwerkkompetenz zunehmend Beachtung 

findet. 

Der Gegenstandsbereich des Verbundprojekts KOWIEN umfasst aufgrund der voranstehenden 

Erläuterungen einen weit gespannten Bereich potenzieller Kompetenzträger. Als Kompetenzträger 

– und somit als relevante Akteure in Engineering-Netzwerken 15) – kommen einer- 

14) Die große wirtschaftliche Bedeutung organisationalen Wissens manifestiert sich insbesondere in „knowledge assets“ 

von Unternehmen, deren Leistungen jeweils von einem hohen Wissensanteil geprägt sind, der einerseits einen „geldwerten“ 

Kundennutzen stiftet und andererseits von Wettbewerbern nur schwer transferiert, imitiert oder substituiert 

werden kann. In dieser Hinsicht besteht eine enge inhaltliche Verknüpfung zwischen Kompetenzen als handlungsbefähigendem 

Wissen einerseits (das hier in der Variante organisationalen Wissens thematisiert wird) und wirtschaftlichen 

Kernkompetenzen andererseits (die aus der Perspektive des betriebswirtschaftlichen „resource-based view“ eingehender 

behandelt werden). Auf diese Verknüpfung kann in der hier gebotenen Kürze nicht näher eingegangen werden. 

Um Verwechslungen und Überschneidungen mit Kernkompetenzen zu vermeiden, wird im Folgenden nur von 

„Kompetenzen“ und „Kompetenzmanagementsystemen“ die Rede sein, auch wenn inhaltliche Beziehungen zu Kernkompetenzen 

„im Prinzip“ bestehen mögen. 

15) Die Begriffe „Kompetenzträger“ und „Akteur“ stellen streng genommen keine Synonyme dar. Der Akteursbegriff ist 

weit gefasst. Er erstreckt sich auf jede Komponente eines Engineering-Netzwerks, die zu eigenständigen Handlungen 

fähig ist. Dabei ist es unerheblich, ob diese Handlungen (überwiegend) wissensbasiert erfolgen oder nicht. Der Begriff 

des Kompetenzträgers wird dagegen enger gefasst, weil er sich auf Akteure nur insoweit bezieht, wie diese Akteure 

als Träger – oder Inhaber („owner“) – von handlungsbefähigendem Wissen betrachtet werden. Kompetenzträger 

stellen also Akteure dar, die aus einer bestimmten, nämlich wissensbezogenen Perspektive wahrgenommen, beschrieben, 

analysiert oder gestaltet werden. Daher muss zwar jeder Kompetenzträger einen Akteur darstellen; aber die Umkehrung 

trifft nicht zu. Denn Akteure brauchen keine Kompetenzträger zu sein – zumindest im aktuellen Erkenntniskontext 

nicht als solche angesehen zu werden. Beispielsweise werden Akteure, deren Interessen in einem Entgeltungskonflikt 

aufeinander prallen, in dieser Konfliktsituation zwar als handelnde Akteure, aber nicht als Kompetenzträger 

wahrgenommen. Sofern von dieser subtilen Differenzierung zwischen allgemeinem Akteursbegriff von speziellem, 

auf Wissenskontexte eingeschränkten Begriff des Kompetenzträgers abgesehen werden kann, werden im 

29


seits individuelle Akteure in Betracht. Zu ihnen zählen sowohl Mitarbeiter der involvierten 

Unternehmen (personelle oder natürliche Akteure) als auch Automatische Informations- und 

Wissensverarbeitungssysteme (maschinelle oder artifizielle Akteure) 16) . Andererseits kann es 

sich aber auch um kollektive Akteure handeln. Dies ist immer dann der Fall, wenn zur arbeitsteiligen 

Erfüllung einer Engineering-Aufgabe (auch) auf handlungsbefähigendes Wissen zurückgegriffen 

wird, das keinem der individuellen Akteure zugerechnet werden kann, sondern 

einer Organisationseinheit als Ganzheit zukommt. 

1.2 Probleme des computerbasierten 

Wissens- und Kompetenzmanagements aus Unternehmenssicht 

Während in der Vergangenheit die Verbesserung der Ablauforganisation (Business Process 

Reengineering) im Mittelpunkt des organisatorischen Wandels stand, bestimmt im heutigen 

wirtschaftlichen Umfeld vor allem das Wissen von Unternehmen (Corporate Knowledge Base, 

Corporate Memory) diesen Wandel. Auf diesem Unternehmenswissen beruhen oftmals die 

Kernkompetenzen und die daraus folgenden strategischen Wettbewerbsvorteile von produzierenden 

Unternehmen, die im Umfeld einer hochkompetitiven Industrie-, Dienstleistungs- und 

Wissensgesellschaft agieren. Daher muss das Management des organisatorischen Wandels 

(Change Management) in erster Linie als Wissensmanagement verstanden und aktiv gestaltet 

werden. Dieser generellen Anforderung stehen jedoch im Bereich wissensintensiver Engineering-Aufgaben 

einige gravierende Probleme entgegen. 

Seit längerer Zeit stehen Unternehmen vor dem Problem, der zunehmenden Dynamik und 

Turbulenz des Unternehmensumfelds durch flexible, neuerdings sogar als „agil“ bezeichnete 

Organisationsformen Rechnung tragen zu müssen. Im Engineering-Bereich hat sich weit gehend 

die Form der Projektorganisation durchgesetzt. Sie erlaubt es einem Unternehmen, sich 

an die Herausforderungen komplexer und rasch wechselnder Engineering-Aufgaben dadurch 

anzupassen, dass für die Erfüllung einer solchen Aufgabe jeweils ein Projekt definiert wird. 

Dieses Projekt ist ausschließlich auf die Spezifika der zu erfüllenden Aufgabe zugeschnitten 

und endet mit der erfolgreichen – oder auch gescheiterten – Aufgabenerfüllung. 

Aus betriebswirtschaftlicher Sicht wird die Planung und Steuerung solcher Projekte mit Projektmanagementtechniken, 

wie z.B. mit Netzplantechnik und Workflowmanagementsystemen, 

bereits zufrieden stellend beherrscht. Ein zweiter Aspekt des Projektmanagements, die 

Zusammenstellung („Konfiguration“) von Projektteams, wird hingegen nur mangelhaft mit 

praxistauglichen Instrumenten unterstützt. Bei der Konfiguration gilt es, ein Team aus Mitar- 

Folgenden diese beiden Begriffe auch – vereinfacht – synonym verwendet. Darüber hinaus lassen sich die Begriffe 

„Kompetenzträger“ und „Wissensträger“ der Einfachheit halber als Synonyme betrachten. Dieser Sprachgebrauch ist 

zwar insofern nicht präzise, weil Wissensträger Akteure darstellen, die über beliebiges Wissen verfügen, während 

sich Kompetenzträger dadurch auszeichnen, dass sie über handlungsbefähigendes Wissen verfügen. Sofern sich jedoch 

aus dem jeweils aktuellen Argumentationskontext erschließen lässt, dass ausschließlich handlungsbefähigendes 

Wissen gemeint ist, kann von der Nuancierung der Handlungsbefähigung abgesehen werden, so dass Kompetenz- 

und Wissensträger inhaltlich zusammenfallen. 

16) Während Mitarbeiter im Regelfall aufgrund arbeitsvertraglicher Regelungen genau einem Unternehmen zugeordnet 

sind, erstrecken sich Automatische Informations- und Wissensverarbeitungssysteme des Öfteren auch über mehrere 

kooperierende Unternehmen, die sich zu einem Netzwerk zusammengeschlossen haben. Besonders deutlich wird dieser 

computerbasierte Unternehmensverbund beispielsweise bei Supply-Chain- oder Supply-Web-Konzepten. Aber 

die vorgenannte Differenzierung ist nicht trennscharf. Denn in Ausnahmefällen können auch einzelne Mitarbeiter 

gleichzeitig zu mehreren Unternehmen aus einem Netzwerk gehören. Dies ist z.B. der Fall, wenn ein Mitarbeiter 

mehrere Beschäftigungsverhältnisse eingegangen ist (etwa im Rahmen von Teilzeitbeschäftigungen) oder wenn ein 

Mitarbeiter von einem Unternehmen zu einem vereinbarten Anteil seiner Arbeitszeit an ein anderes, kooperierendes 

Unternehmen zwecks gemeinsamer Erfüllung einer Engineering-Aufgabe „ausgeliehen“ wird. 

30


beitern zusammenzustellen, die für die Erfüllung einer anstehenden Engineering-Aufgabe 

bestmöglich qualifiziert sind. Die aufgaben- und somit projektspezifisch erforderlichen Qualifikationen 

erstrecken sich – sofern Kompetenzen als handlungsbefähigendes Wissen betroffen 

sind – sowohl auf konzeptionelles Wissen, das z.B. durch erworbene berufsbezogene oder akademische 

Abschlüsse nachgewiesen sein kann, als auch auf Erfahrungswissen, das bei der 

praktischen Erfüllung ähnlicher Aufgaben in der Vergangenheit erworben wurde. Die Gesamtheit 

dieses benötigten Wissens wird hier als projektspezifisches Know-how bezeichnet 

(projektspezifisches Know-what spielt in der betrieblichen Praxis allenfalls eine untergeordnete 

Rolle und wird daher im Folgenden nicht weiter berücksichtigt). 

Die immanente Flexibilität der Projektorganisation führt dazu, dass mit jeder neuen Engineering-Aufgabe 

ein neues Konfigurationsproblem, streng genommen sogar ein Bündel mehrerer 

voneinander abhängiger Konfigurationsprobleme zu lösen ist: Erstens muss geprüft werden, 

ob ein Unternehmen überhaupt über Mitarbeiter verfügt, deren Kompetenzen für das projektspezifisch 

benötigte Know-how erforderlich sind. Wenn dies der Fall ist, gilt es in kapazitativer 

Hinsicht festzustellen, ob die betroffenen Mitarbeiter tatsächlich zur Verfügung stehen – 

also nicht durch ihre Engagements in anderen Projekten bereits vollständig gebunden sind. 

Drittens muss, wie bereits angedeutet, das Kernproblem gelöst werden, aus den vorhandenen 

und auch aktuell verfügbaren Mitarbeitern für die jeweils anstehende Engineering-Aufgabe 

ein bestmöglich qualifiziertes Projektteam zusammenzustellen. Dies erfordert u.a. auch, einen 

operationalen Maßstab für den bestmöglichen „fit“ zwischen erforderlichen und verfügbaren 

Kompetenzen festzulegen. Die inhaltliche Füllung der Leerformel „bestmöglich“ kann hierbei 

von Projekt zu Projekt variieren und bedarf eines sensiblen Gespürs für die situativen Kontextbedingungen 

jedes einzelnen Projekts. 

Schließlich – und viertens – ist es aus betriebswirtschaftlicher Sicht empfehlenswert, das 

Konfigurationsproblem von vornherein so weit auszulegen, dass neben der Teambildung auch 

die Bereitstellung der erforderlichen Betriebs- und Finanzmittel – z.B. als sachliche Ressourceneinsatzplanung 

bzw. als Projektfinanzierung – erfolgt. Für die wissensintensiven Engineering-Aufgaben, 

die den Hintergrund des hier beantragten Vorhabens bilden, spielt die Bereitstellung 

der Ressource Wissen eine herausragende Rolle. Soweit das projektspezifische 

Know-how nicht von den ausgewählten Mitarbeitern als Wissen „in ihren Köpfen“ mitgebracht 

wird, muss es im Rahmen der Projektkonfiguration durch andere Wissensträger zusätzlich 

bereitgestellt werden. In erster Linie bieten sich hierfür Daten-, Informations- und Wissensbanken 

an, in denen ein Unternehmen insbesondere das Erfahrungswissen („lessons learned“) 

aus früher durchgeführten Projekten explizit dokumentiert und zur Wiederverwendung 

(„knowledge reuse“) in Folgeprojekten vorhält. Aber auch andere Formen der Speicherung 

organisationalen Wissens, wie z.B. konventionelle Handbücher, Organisationsrichtlinien und 

Projektberichte, kommen als Wissensquellen für projektspezifisches Know-how in Betracht. 

Alle vorgenannten Spielarten desjenigen Wissens, das in einem Unternehmen zur Erfüllung 

einer wissensintensiven Engineering-Aufgabe vorhanden ist, müssen im Rahmen des Projektmanagements 

berücksichtigt werden, um das zuvor skizzierte Bündel von Konfigurationsproblemen 

17) zu bearbeiten. Dies entspricht einem „ganzheitlichen“ Ansatz für betriebliches 

Wissensmanagement. 

Das Konfigurationsproblem des Projektmanagements wird in der betrieblichen Praxis oftmals 

dadurch noch komplexer, dass sich mehrere Unternehmen zu einem überbetrieblichen (Engineering-) 

Netzwerk – z.B. einem Virtuellen Unternehmen – zusammenschließen. Anlass eines 

17) Im Folgenden wird der Einfachheit halber von „dem“ Konfigurationsproblem gesprochen, wenn die Differenzierung 

zwischen den vorgenannten Problemvarianten nicht weiter interessiert. 

31


solchen Zusammenschlusses ist die Erfüllung einer Engineering-Aufgabe, die das Leistungsvermögen 

eines einzelnen Unternehmens übersteigen würde. Ein solcher Unternehmensverbund 

existiert im Allgemeinen nur temporär, weil er aufgelöst wird, sobald die gemeinsam 

übernommene Aufgabe erfüllt ist (oder die intendierte Aufgabenerfüllung gescheitert ist). Die 

besondere Komplexität des Konfigurationsproblems für Engineering-Netzwerke resultiert im 

Wesentlichen aus drei Ursachen. 

Erstens unterliegt der Austausch von potenziell wettbewerbsrelevantem Wissen zwischen Unternehmen 

zahlreichen Vorbehalten. Auf diesen Aspekt wird im Verbundprojekt KOWIEN 

nicht näher eingegangen, weil er insbesondere die Motivation zur Wissensoffenlegung und - 

teilung betrifft. Wie bereits oben erläutert wurde, gehören solche Motivationsaspekte des 

Wissensmanagements zur so genannten Personalisierungsstrategie. Sie entspricht nicht der 

hier gewählten Kodifizierungsstrategie des Wissensmanagements, also der Schwerpunktsetzung 

zugunsten computerbasierter Arbeitstechniken. Trotz dieser Ausgrenzung motivationaler 

Aspekte aus dem Fokus des KOWIEN-Projekts wird keineswegs bestritten, dass ihnen in 

der betrieblichen Praxis eine hohe Bedeutung zukommt. Daher werde jene Aspekte, in deren 

Zentrum das Humankapital des Wissensmanagements steht, in einem anderen Verbundprojekt 

unter Beteiligung des Universitätspartners, dem schon zuvor erwähnten Projekt MOTIWIDI, 

ausführlicher behandelt. 

Zweitens muss Wissen über die Kompetenzen der Mitarbeiter fremder Unternehmen in die 

Lösung des Konfigurationsproblems einbezogen werden, obwohl jenes „Fremdwissen“ in der 

Regel weitaus lückenhafter oder weniger zuverlässig zur Verfügung steht als das Wissen über 

die Kompetenzen der eigenen Mitarbeiter. Erschwerend kommt noch hinzu, dass die Kooperationspartner 

bei Virtuellen Unternehmen – vor allem der so genannten „ersten Generation“ 

(s.o.) – durch die immanente Instabilität lediglich temporärer Kooperationen im Zeitablauf 

häufig variieren (können). Daher droht das Wissen über die Kompetenzen der Netzwerkpartner 

schnell zu veralten und muss entsprechend häufig aktualisiert werden. 

Drittens sind in unterschiedlichen Unternehmen oftmals verschiedenartige „Sprachkulturen“ 

oder „Sprachwelten“ – mit differierenden Begriffsbezeichnungen und uneinheitlichen Vorverständnissen 

– gewachsen. Sie können die Kommunikation über das in den Unternehmen 

jeweils vorhandene Wissen und das zur Aufgabenerfüllung benötigte, projektspezifische 

Know-how erheblich behindern. Dennoch verspüren die einzelnen Unternehmen eines Virtuellen 

Unternehmens häufig keine Veranlassung, ihre Sprachkulturen zu vereinheitlichen, weil 

ihrer Ansicht nach der lediglich temporäre Charakter des Unternehmensverbunds derart tief 

greifende Veränderungen nicht rechtfertigt. 

Zusätzlich wird ein professionelles Wissensmanagement in der betrieblichen Praxis oftmals 

durch die unnötige Heterogenität der jeweils eingesetzten Formen der Wissensrepräsentation 

erheblich erschwert 18) : Es werden unterschiedliche Repräsentationssprachen für die Erfassung 

desselben Gegenstandsbereichs nebeneinander verwendet. Dies ist z.B. für Beschaffungsprozesse 

der Fall, wenn sie einerseits für Zwecke der Zertifizierung nach DIN ISO EN 9000 ff. – 

neuerdings nach der aktualisierten Normenfamilie DIN ISO EN 9001:2000 – textuell beschrieben 

werden („Qualitätsmanagement-Handbuch“), andererseits aber für die Einführung 

von Enterprise-Resource-Planning-Systemen wie SAP R/3 mittels ereignisgesteuerter Prozessketten 

semigrafisch modelliert werden. Aufgrund einer solchen Nutzung unterschiedlicher 

Repräsentationsformen und -sprachen können nicht nur unwirtschaftliche Redundanzen ent- 

18) Die Repräsentationsformen lassen sich ebenso unter den Aspekt der Sprachkulturen und -welten subsumieren, da jede 

Form der Wissensrepräsentation durch die jeweils zugrunde gelegte Repräsentationssprache maßgeblich geprägt 

wird. 

32


stehen. Stattdessen drohen infolge der Redundanz bei der Aktualisierung von Objekt- und 

Prozessrepräsentationen sogar Inkonsistenzen, die zu späteren Design- und Anwendungsfehlern 

mit nicht unerheblichem wirtschaftlichen Schadenspotenzial führen können. 

Eine weitere Herausforderung an das betriebliche Wissensmanagement resultiert im Engineering-Bereich 

aus der zunehmenden Wissensintensität der Wertschöpfungsprozesse. Sie manifestiert 

sich in einer hohen Zunahme und großen Veränderlichkeit desjenigen Wissens, das für 

wettbewerbsfähige Engineering-Leistungen eingesetzt werden muss. NONAKA und TAKEUCHI 

haben dies in ihrer Metapher der „Wissensspirale“ plastisch ausgedrückt 19) . Diese Entwicklung 

wird sowohl durch einen progressiv beschleunigten technologischen Wandel, der sich 

beispielsweise in schnelleren Technologiesequenzen und kürzeren Produktlebenszyklen äußert, 

als auch durch eine zunehmende Kundenorientierung und ein breiteres Leistungsspektrum 

auf der Angebotsseite verursacht. Kundenorientierung und Leistungsverbreiterung schlagen 

sich nicht nur auf der Sachgüterebene in der höheren Produktarten- und Variantenvielfalt 

nieder. Vielmehr wächst der Dienstleistungsanteil an „Produkten als komplexen Leistungsbündeln“ 

beständig an. Da die „Produktion“ von Dienstleistungen – zumindest im Engineering-Bereich 

– in der Regel einen besonders hohen Anteil von leistungsspezifischem Knowwhat 

und Know-how erfordert, verstärkt dies den Trend zu anwachsender Wissensintensität 

der Wertschöpfungsprozesse. 

Die Erfüllung wissensintensiver Engineering-Aufgaben wird zusätzlich dadurch erschwert, 

dass ein bedeutsamer – und oftmals wettbewerbsentscheidender – Anteil des projektspezifischen 

Know-hows aus Erfahrungswissen besteht, auf das nicht unmittelbar zugegriffen werden 

kann. Es bildet eine wesentliche Facette derjenigen Kompetenzen eines Wissensträgers 

(z.B. Mitarbeiter und organisationales Gedächtnis), die in der Regel weder umfassend noch 

systematisch dokumentiert sind. In den meisten Fällen liegt dieses Erfahrungswissen sogar 

überhaupt nicht in expliziter Form vor, wie es vor allem in der Form von Dokumenten wie 

Projektberichten oder in der Form von Daten-, Informations- oder Wissensbanken der Fall 

wäre. Stattdessen bleibt das Erfahrungswissen zumeist „in den Köpfen der Mitarbeiter“ eingeschlossen 

oder lässt sich als Organisationswissen nicht direkt „lokalisieren“. Solches Wissen, 

das nicht in unmittelbar explizierter Form vorliegt und sich nur unter großen Mühen – wenn 

überhaupt – explizieren lässt, wird im Allgemeinen als „tazites“ Wissen bezeichnet 20) . 

Aus den vorgenannten Schwierigkeiten resultiert ein erheblicher Mangel an direkt zugreifbarem 

Wissen („Meta-Wissen“) über dasjenige Erfahrungswissen, das in einem Unternehmen 

19) Vgl. NONAKA, I.; TAKEUCHI, H.: The Knowledge-Creating Company – How Japanese Companies Create the Dynamics 

of Innovation, New York - Oxford 1995, S. 57 ff., insbesondere S. 70 ff. 

20) In der Literatur zum Wissensmanagement wird in diesem Zusammenhang auch häufig von implizitem Wissen gesprochen. 

Diese Bezeichnung verleitet jedoch häufig zu Missverständnissen, weil der Begriff „implizites Wissen“ bereits 

in der allgemeinen Logik durch ein vollkommen anderes Vorverständnis geprägt ist: Aus logischer Sicht wird 

unterschieden zwischen einerseits explizitem Wissen, das in Formeln (Aussagen, Sätzen, Axiomen, Theoremen u.ä.) 

unmittelbar „gegeben“ ist, und andererseits implizitem Wissen, das mittels Inferenzregeln aus explizitem Wissen erschlossen 

werden kann. Aus dieser logischen Perspektive enthalten auch alle Dokumente, Daten-, Informations- sowie 

Wissensbanken usw. bereits implizites Wissen, das sich durch die Anwendung von Inferenzregeln auf dieses explizite 

Wissen gewinnen lässt. Auch für Ontologien, die im Rahmen des Verbundprojekts KOWIEN eine große Rolle 

spielen (Näheres dazu später in Kapitel 4.1.4 über die Neuartigkeit der Projektarbeiten), werden solche Inferenzregeln 

angewendet. Hinzu kommt, dass die logische Sichtweise eine inhaltlich klare und präzise Unterscheidung zwischen 

ex- und implizitem Wissen trifft. Dagegen erweist sich die Differenzierung zwischen explizitem und „schwer explizierbarem“ 

Wissen als problematisch, weil zumindest eine dritte Kategorie für Wissen, das zwar (noch) nicht explizit 

vorliegt, sich aber dennoch – z.B. mittels simpler Inferenzregeln – leicht explizieren lässt. In der Wissensmanagement-Literatur 

findet sich für diese nahe liegende Wissensform kein treffendes, geschweige denn etabliertes Attribut. 

Daher wird vom zuvor skizzierten, problematischen Sprachgebrauch für „implizites Wissen“ abgewichen und stattdessen 

„implizit“ im eingangs erläuterten logischen Begriffsverständnis verwendet. Die spezielle Kategorie von Wissen, 

das nicht in unmittelbar explizierter Form vorliegt und sich nur unter großen Mühen – wenn überhaupt – explizieren 

lässt, wird als tazites Wissen bezeichnet. 

33


insgesamt für die Erfüllung wissensintensiver Engineering-Aufgaben zur Verfügung steht. 

Darüber hinaus mangelt es oftmals an Wissen darüber, wie jenes vorhandene Erfahrungswissen 

auf unterschiedliche Wissensträger (Kompetenzträger) im Unternehmen verteilt ist. 

Sowohl das spezielle Konfigurationsproblem des Projektmanagements als auch das allgemeine 

betriebliche Kompetenzmanagement werden durch das Phänomen der Personalfluktuation 

zusätzlich kompliziert. Insbesondere Branchen mit hoher Wissensintensität der Leistungserstellung 

leiden an einer überdurchschnittlich hohen Personalfluktuation. Denn „Knowledge 

Worker“ weisen oftmals eine größere Verwertungsbreite für ihr Know-how (und Know-what) 

auf als Mitarbeiter, die eine „klassische“ Qualifikation mit – vergleichsweise – niedrigerer 

Wissensintensität erworben haben. Dies trifft auch auf den Engineering-Bereich zu. Besonders 

deutlich wird dieses Phänomen bei Unternehmensberatungen. Solche Consulting- 

Unternehmen gehören zum Bereich des Service-Engineerings und leiden unter den höchsten 

Personalfluktuationen aller Branchen. Ihre Mitarbeiter stellen „Knowledge Worker“ par excellence 

dar. 

Durch die Personalfluktuation verändert sich nicht nur ständig das personengebundene Kompetenzenreservoir 

eines Unternehmens. Vielmehr besteht auch auf Seite der Unternehmen ein 

großes Interesse daran, das Erfahrungswissen ihrer Mitarbeiter in Wissensbanken und anderen 

Formen des Organisationswissens explizit zu dokumentieren bzw. im Unternehmen zu verankern, 

um das wichtige, oftmals wettbewerbsentscheidende Erfahrungswissen auf diese Weise 

zu konservieren. Aus diesem Blickwinkel erlangt die Kodifizierungsstrategie, die im voranstehenden 

Kapitel als spezieller Fokus des Verbundprojekts KOWIEN herausgearbeitet wurde, 

für Engineering-Netzwerke, die wissensintensive Leistungen erbringen, eine außerordentliche 

Bedeutung. 

Unternehmensberatungen stellen wegen ihrer sowohl besonders hohen Personalfluktuation als 

auch ihrer besonders großen Wissensintensität der Leistungserstellung einen hochinteressanten 

Anwendungsfall für die Kodifizierungsstrategie des Wissensmanagements dar. Deshalb 

wurde in das Verbundprojekt KOWIEN bewusst ein Service-Engineering-Szenario aufgenommen, 

auch wenn es prima facie erstaunlich erscheinen vermag, Consulting-Dienstleistungen 

als einen Spezialfall von Engineering-Leistungen zu berücksichtigen. 

Darüber hinaus wird die Personalfluktuation in Unternehmen in Zukunft voraussichtlich weiter 

zunehmen, weil Mitarbeiter in ihrem Berufsleben häufiger in unterschiedlichen Unternehmen 

beschäftigt sein werden. Dadurch verändert sich ständig das personengebundene Kompetenzenreservoir 

eines Unternehmens. Außerdem werden den Mitarbeitern im Rahmen „moderner“ 

Organisationsprinzipien wechselnde Aufgaben zugewiesen (Job Rotation). Damit das 

Wissen, das von den Mitarbeitern für eine spezielle Aufgabenstellung erworben wurde, nicht 

mit einem Stellen- oder Unternehmenswechsel verloren geht, ist es zu erfassen, in Wissensbanken 

oder anderen Formen organisationalen Wissens explizit zu dokumentieren und auf 

diese Weise zu konservieren. Insbesondere kommt es darauf an, das erfasste Wissen so zu 

strukturieren, dass es zu einem späteren Zeitpunkt des Wissensbedarfs effektiv zugänglich ist 

und wieder verwendet werden kann („diachronisches“ Wissensmanagement). 

Die Notwendigkeit der Wissensstrukturierung und -dokumentation mittels einer Kodifizierungsstrategie 

verstärkt sich, wenn eine (Engineering-) Aufgabe durch die Kooperation mehrerer 

Akteure zu erfüllen ist („synchronisches“ Wissensmanagement) und diese Akteure – wie 

bereits zuvor erläutert – aus Arbeitsbereichen mit heterogenen Sprachkulturen und Wissenshintergründen 

stammen. Solche Verhältnisse liegen insbesondere dann vor, wenn Aufgaben 

entweder innerhalb eines Unternehmens standortübergreifend – insbesondere in internationalen 

Standortverbünden – erfüllt werden (wie z.B. bei global agierenden Unternehmen der 

Consulting-Branche) oder aber mehrere Unternehmen bei der gemeinschaftlichen Aufgaben- 

34


erfüllung zusammenarbeiten (wie vor allem in strategischen Allianzen, Unternehmensnetzwerken 

und Virtuellen Unternehmen). Die kooperationsrelevante Sprach- und Wissensheterogenität 

kann noch dadurch erschwert werden, dass marktferne Institutionen, wie etwa Forschungseinrichtungen, 

Verbände, Prüfbehörden und staatliche Auftraggeber in die kooperative 

Leistungserstellung einbezogen sind. Sie pflegen oftmals eigenständige Sprachwelten 

(„Beamtendeutsch“) und Wissensstrukturen (ausgerichtet an Usancen der Bürokratie und der 

Jurisprudenz), die sich von den Sprachkulturen und Wissenshintergründen privatwirtschaftlicher 

Unternehmen eklatant unterscheiden. 

Wissensbezogene Repräsentations- und Kommunikationsprobleme erlangen im Engineering- 

Bereich große praktische Bedeutung, weil komplexe Engineering-Aufgaben schon seit langem 

– und mit weiterhin wachsender Tendenz – von temporär verbundenen Unternehmen 

gemeinschaftlich erfüllt werden. Das trifft unabhängig davon zu, ob diese Unternehmenskooperationen 

als „Projektkonsortien“, „Engineering-Netzwerke“, „Virtuelle Unternehmen“ o.ä. 

bezeichnet werden. In der Fachliteratur zum Wissensmanagement, die entweder vornehmlich 

(informations-) technisch oder aber überwiegend organisationswissenschaftlich ausgerichtet 

ist, wird auf solche Repräsentations- und Kommunikationsprobleme jedoch in der Regel überhaupt 

nicht, allenfalls peripher eingegangen. Daher wird für das kooperative Wissensmanagement 

in Engineering-Netzwerken ein Instrumentarium benötigt, das es u.a. gestattet, 

sprachbedingt unterschiedliche Wissensrepräsentationen als solche zu erkennen, hinsichtlich 

ihrer kommunikationserschwerenden (Sprach-) Differenzen zu untersuchen und – nach Möglichkeit 

– tendenziell zu vereinheitlichen. Aufgrund dieses dringenden Bedarfs widmet sich 

das Verbundprojekt KOWIEN den zuvor angedeuteten Komplikationen heterogener Sprachkulturen 

mit besonderem Nachdruck. 

Aus den vorgenannten, vielschichtigen und zum Teil komplex miteinander vernetzten Gründen 

wird deutlich, dass im Engineering-Bereich ein erheblicher Bedarf für ein aktives, auf Effektivität 

und Effizienz ausgerichtetes Wissensmanagement besteht. Ein effektives Wissensmanagement 

liegt vor, wenn die verfolgten Zwecke – wie z.B. die Identifizierung einschlägiger 

Wissensträger für projektspezifisches Know-how – als Output des Wissensmanagements 

tatsächlich erreicht werden. Die Zweckerreichung erfolgt umso effizienter, je geringer der 

hierfür erforderliche Einsatz von Ressourcen (Personal, Sach- und Finanzmittel, Zeit) ist, je 

besser also das Verhältnis zwischen erzielten Ergebnissen (Output) und hier für eingesetzten 

Ressourcen (Input) ausfällt 21) . Im Regelfall lassen sich sowohl die Effektivität als auch die Effizienz 

des Wissensmanagements durch die Nutzung von Software-Werkzeugen („Tools“) 

nachhaltig erhöhen. Daher besteht ein mittelbarer, aber nichtsdestoweniger in der betrieblichen 

Praxis außerordentlich kritischer Bedarf für die computerbasierte Unterstützung von effektivitäts- 

und effizienzfördernden Wissensmanagementtechniken. 

Dieser Bedarf lässt sich speziell im Hinblick auf Projektgeschäft und Projektorganisation, die 

sich im Engineering-Bereich großenteils durchgesetzt haben (s.o.), weiter konkretisieren: Im 

Fall einer externen Projektanfrage – oder alternativ: im Fall der internen Vorbereitung und 

Durchführung eines Projekts – bereitet es oftmals große Schwierigkeiten, diejenigen Kompetenzen 

und Kompetenzträger zu identifizieren, über die ein Unternehmen oder ein Unternehmensverbund 

einerseits verfügt und die andererseits für die Erfüllung einer wissensintensiven 

Engineering-Aufgabe benötigt werden. Daher besteht in der betrieblichen Praxis ein erhebli- 

21) Diese „generische“ Definition von Effektivität und Effizienz des Wissensmanagements steckt nur einen Definitionsrahmen 

ab. Im konkreten Einzelfall muss jeweils spezifiziert werden, wie die Outputs und Inputs konkret zu messen 

sind (Operationalisierung der Maßgrößen) und was unter einem „besseren“ Output/Input-Verhältnis inhaltlich zu verstehen 

ist (Festlegung eines Optimierungskriteriums). 

35


cher Bedarf für computerbasierte Instrumente, mit denen sich die Kompetenzprofile der Kompetenzträger 

eines Unternehmens 22) : 

• systematisch erheben und darstellen (generieren), 

• zeitnah aktualisieren sowie 

• mit den jeweils benötigten Kompetenzen vergleichen 

lassen. Außerdem sollen es die Instrumente gestatten, das explizit dokumentierte Mitarbeiterund 

Organisationswissen so zu strukturieren und zu repräsentieren, dass das dort konservierte 

Erfahrungswissen kompetenzorientiert erschlossen sowie projektbezogen abgerufen werden 

kann. Dabei sollen die Instrumente grundsätzlich in der Lage sein, beliebige Träger expliziten 

Wissens inhaltlich zu erschließen. Dies betrifft sowohl konventionelle schriftliche, d.h. „ausgedruckte“ 

Dokumente, wie z.B. unternehmensinterne „gelbe Seiten“ mit Angaben über Mitarbeiterkompetenzen, 

Projektberichte mit „lessons learned“ sowie Organisations-Handbücher, 

als auch „elektronische“ Dokumente, zu denen insbesondere Internet- und Intranet- 

Dokumente sowie E-Mails gehören. Hinzu kommen des Weiteren stärker strukturierte Daten-, 

Informations- und Wissensbanken, die hier wegen der komplizierten und unfruchtbaren begrifflichen 

Abgrenzungsprobleme nicht näher unterschieden werden. Der Einfachheit halber 

werden im Verbundprojekt KOWIEN alle vorgenannten Träger expliziten Wissens unter den 

Oberbegriff der „Dokumente“ (im weitesten Sinn) subsumiert. 

Zusätzlich wird von der heuristischen Annahme („Dokumenten-These“) ausgegangen, dass 

der größte und wirtschaftlich bedeutsamste Teil des Wissens über die Kompetenzen von Akteuren 

in Engineering-Netzwerken – sofern es für das Management von Engineering- 

Projekten Relevanz besitzt – entweder in solchen Dokumenten unmittelbar explizit repräsentiert 

wird oder aber in ihnen implizit enthalten ist und somit mittels Inferenzregeln erschlossen 

werden kann. Diese Annahme im „Entdeckungszusammenhang“ ist natürlich offen gegenüber 

empirischer Widerlegung. Aber im Verlauf des Projekts KOWIEN ergab sich keine empirische 

Evidenz dafür, dass diese Dokumenten-These in der betrieblichen Praxis nicht zumindest 

tendenziell erfüllt ist. Diese Projekterfahrung rechtfertigt nachträglich die Grundsatzentscheidung, 

sich im Rahmen des Verbundprojekts KOWIEN auf die Kodifizierungsstrategie des 

Wissensmanagements zu fokussieren, d.h. primär computerbasierte Arbeitstechniken – und 

zugehörige Software-Werkzeuge – zur Unterstützung des betrieblichen Wissensmanagements 

zu untersuchen. 

Der Aufgabenbereich des Managements von Kompetenzprofilen erstreckt sich auf die oben 

angeführten Aufgaben des Generierens, Aktualisierens und Vergleichens von Kompetenzprofilen. 

Wird dieser Aufgabenbereich noch um das kompetenzorientierte Strukturieren und Repräsentieren 

von explizitem Wissen über Kompetenzen und ihre Kompetenzträger sowie um 

das inferenzielle Erschließen entsprechenden impliziten Wissens erweitert, so wird vom 

Kompetenzmanagement im weit gefassten Sinne gesprochen 23) . Das Kompetenzmanagement 

(im weit gefassten Sinne) erstreckt sich also stets auf drei zentrale Erkenntnis- und Gestaltungsobjekte: 

Kompetenzen, Kompetenzträger und Kompetenzprofile. Sie werden im Folgen- 

22) Vgl. dazu den konzeptionell sehr ähnlichen, lediglich auf den Bereich Virtueller Unternehmen fokussierten Beitrag 

von BREMER, C.F.; MUNDIM, A.P.F.; MICHILINI, F.V.S.; SIQUEIRA, J.E.M.; ORTEGA, L.M.: New Product Search and 

Development as a Trigger to Competencies Integration in Virtual Enterprises. In: SIEBER, P.; GRIESE, J. (Hrsg.): Organizational 

Virtualness and Electronic Commerce, Proceedings of the 2nd International VoNet-Workshop, 23.- 

24.09.1999 in Zürich, o.O. 1999, S. 213-222. 

23) Auf den präzisierenden Zusatz „im weit gefassten Sinne“ wird im Folgenden verzichtet, wenn sich aus dem jeweils 

aktuellen Argumentationskontext ergibt, dass nicht nur das ausschließliche Management (im engeren Sinne) von 

Kompetenzprofilen gemeint ist, sondern als Erkenntnis- und Gestaltungsobjekte ebenso Kompetenzen und Kompetenzträger 

in Betracht kommen. 

36


den stets gemeinsam adressiert, auch wenn sie – der Einfachheit halber – nicht immer alle drei 

explizit angesprochen werden (sofern keine ausdrücklich anders lautenden Ausgrenzungen 

mindestens eines der vorgenannten Objekte erfolgen). 

Für die vorgenannten Managementaufgaben existieren zwar viel versprechende Ansätze in 

der wissenschaftlichen Forschung. Dies betrifft vor allem Techniken des Wissensmanagements, 

die seit Anfang der achtziger Jahre im Rahmen des Knowledge-Level-Engineerings intensiv 

diskutiert werden. Hierbei handelt es sich insbesondere um Ontologien und – mit geringerem 

Gewicht – um Referenzmodelle. Aber diese Ansätze sind bislang noch nicht in praxistaugliche, 

computerbasierte Instrumente zur Unterstützung des betrieblichen Wissensmanagements 

umgesetzt worden. Stattdessen klafft derzeit auf dem Gebiet der Softwareunterstützung 

für Aufgaben des Wissensmanagements eine gravierende technische Umsetzungslücke: 

Zwar bieten einige wenige Hersteller betrieblicher Anwendungssoftware in jüngster Zeit 

Komponenten an, die Aufgaben des inner- und überbetrieblichen Wissensmanagements unterstützen. 

Detaillierte Analysen dieser Offerten zeigen jedoch, dass es sich in der Regel lediglich 

um Erweiterungen klassischer Datenbank- oder Dokumentenverwaltungstechniken handelt. 

Neuere Erkenntnisse aus dem Bereich des Knowledge-Level-Engineerings finden in solchen 

Softwarekomponenten noch keine zufrieden stellende Berücksichtigung. Die bekannten 

Techniken des Knowledge-Level-Engineerings reichen noch nicht aus, um den Anforderungen 

der betrieblichen Praxis an ein effektives und effizientes Wissensmanagement gerecht zu 

werden. Insbesondere fehlt es an praxistauglichen, also auch von „durchschnittlich qualifizierten“ 

Mitarbeitern anwendbaren Techniken – aufgabenspezifischen Komplexen aus Modellen 

und Methoden – für das systematische, computerbasierte Akquirieren, Strukturieren und Repräsentieren 

von Wissen über Kompetenzen, Kompetenzträger und Kompetenzprofile. 

Um die zuvor erwähnte technische Umsetzungslücke zu schließen, werden insbesondere zwei 

Arten von Instrumenten für das betriebliche Wissensmanagement benötigt. Einerseits bedarf 

es einer systematischen Anleitung, wie bei der Erfüllung der Aufgaben des Managements von 

Kompetenzwissen konkret vorgegangen werden soll. Ein solches Vorgehensmodell, das den 

Anforderungen der betrieblichen Praxis entspricht, existiert zurzeit noch nicht. Andererseits 

besteht ebenso ein erheblicher Bedarf an computerbasierten Arbeitstechniken für die die vorgenannten 

kompetenzbezogenen Managementaufgaben. Für diese Arbeitstechniken sind entsprechende 

Software-Werkzeuge erforderlich, um Kompetenzmanagementsysteme im betrieblichen 

Alltag effektiv und effizient nutzen zu können. 

1.3 Lösungsansätze des Verbundprojekts KOWIEN 

Auch wenn die Notwendigkeit eines effektiven und effizienten Wissensmanagements für die 

Erfüllung wissensintensiver Engineering-Aufgaben evident ist, so leidet seine Verwirklichung 

in der betrieblichen Praxis unter einer Vielzahl von Problemen, die im voranstehenden Kapitel 

skizziert wurden. Dies gilt vor allem im Hinblick auf den Spezialfall des betrieblichen Kompetenzmanagements, 

das für Engineering-Leistungen im Rahmen der projektorientierten Aufgabenerfüllung 

eine herausragende Rolle spielt. Insbesondere mangelt es an praxistauglichen, 

computerbasierten Instrumenten für das Management von Kompetenzwissen. Darunter fallen 

sowohl das „inhaltsbezogene“ Management von Wissen über erforderliche und verfügbare 

Kompetenzen als auch das „akteursbezogene“ Management von Wissen über die jeweils betroffenen 

Kompetenzträger. 

Das Verbundprojekt KOWIEN setzt an dieser Stelle des Mangels an instrumenteller, computerbasierter 

Unterstützung für das betriebliche Kompetenzmanagement an: Durch Transfer 

neuartiger Forschungserkenntnisse aus den Bereichen Wirtschaftsinformatik, (Kern-) Infor- 

37


matik und Künstliche Intelligenz werden praxistaugliche Lösungen für die zuvor skizzierten 

Probleme des Wissens-, insbesondere des Kompetenzmanagements, entwickelt. 

Die Zielgruppe dieser problem- und lösungsfokussierten Entwicklungsarbeiten sind Unternehmen, 

die in einem inner- oder überbetrieblichen Engineering-Netzwerk wissensintensive 

Aufgaben kooperativ erfüllen. Darüber hinaus befasst sich das Verbundprojekt KOWIEN 

primär mit den speziellen Einsatzbedingungen, die für computerbasierte Kompetenzmanagementsysteme 

in kleinen und mittelgroßen Unternehmen (KMU) vorherrschen. Beispielsweise 

wurden nur solche Modelle und Methoden aus dem oben skizzierten Forschungshintergrund 

in die konkreten Entwicklungsarbeiten des Projekts übernommen, die sich von „typischen“ 

Mitarbeitern eines KMU im betrieblichen Alltag auch tatsächlich nutzen lassen. Dies bedeutete 

u.a., entweder von vornherein auf Modelle und Methoden zu verzichten, die nur von Spezialisten 

mit langjähriger fachwissenschaftlicher („akademischer“) Ausbildung verstanden werden 

können. Oder jene Modelle und Methoden wurden so in benutzerfreundliche Anwendungsumgebungen 

eingebettet, dass sie sich von Mitarbeitern eines KMU ohne Schwierigkeiten 

zur Lösung ihrer Alltagsprobleme anwenden lassen. 

Die computerbasierten Instrumente für das Management von Kompetenzwissen, die im Verbundprojekt 

KOWIEN konzipiert, prototypisch implementiert und ausführlich evaluiert wurden, 

umfassen im Wesentlichen – d.h. abgesehen von mehreren Hilfsinstrumenten, die aus der 

Benutzersicht nicht unmittelbar in Erscheinung treten, – drei Komponenten: 

1. ein (computerbasiertes) Vorgehensmodell für die Erstellung und Anwendung ontologiebasierter 

Kompetenzmanagementsysteme, 

2. ein prototypisches Software-Tool („KOWIEN-Prototyp“) für ontologiebasierte Kompetenzmanagementsysteme, 

die das betriebliche Wissensmanagement auf der Basis von Ontologien 

und Kompetenzprofilen unterstützen sollen, sowie 

3. eine E-Learning-Umgebung zur Unterstützung der praktischen Anwendung des Vorgehensmodells 

und des Software-Tools im betrieblichen Alltag von KMU (sie wird im Projektkontext 

als E-Learning-Anwendung bezeichnet 24) ). 

Die Instrumente greifen auf Modelle und Methoden zurück, die für das systematische Akquirieren, 

Strukturieren und Repräsentieren von Wissen auf der Basis von Ontologien und Referenzmodellen 

ausgelegt sind. Von vornherein wurde großer Wert darauf gelegt, generische 

Modelle und Methoden einzusetzen, die von anwendungsspezifischen Besonderheiten abstrahieren 

und infolgedessen einen allgemeingültigen Charakter aufweisen. Dieser generische 

Modell- und Methodencharakter ist erforderlich, um nicht für eine Vielzahl verschiedenartiger 

Anwendungssituationen jeweils idiosynkratische Vorgehensweisen konzipieren zu müssen. 

Solche Spezialmodelle und -methoden wären nicht nur hinsichtlich ihrer Wiederverwendbarkeit 

stark eingeschränkt, da sie sich jeweils auf spezielle situative Kontexte fokussieren. 

Vielmehr wäre auch der Versuch einer computerbasierten Implementierung aufgrund der erwarteten 

geringen Nutzungsbreite erheblichen Verwertungsrisiken ausgesetzt gewesen. Aus 

den vorgenannten Gründen wurden von vornherein nur solche Modelle und Methoden des 

Wissensmanagements eingesetzt, die sowohl für das Vorgehensmodell als auch für das Soft- 

24) Streng genommen handelt es sich um Module des Software-Tools. Außerdem wurde die E-Learning- 

Software von vornherein so konzipiert, dass sie sich modular in unterschiedliche Verwendungskontexte integrieren 

lässt, wie z.B. als Lerneinheit in einen Online-Studiengang auf dem Gebiet der Wirtschaftsinformatik 

oder des Wissensmanagements. Allerdings überwog unter den Projektpartnern die Perspektive, die E- 

Learning-Umgebung als eine spezielle Anwendungssoftware (im Gegensatz z.B. zu Betriebssystem- 

Software oder Middleware) zu betrachten. Daraus resultiert die Bezeichnung als E-Learning-Anwendung. 

38


ware-Werkzeug (einschließlich der E-Learning-Anwendung) generisch ausgelegt, also nicht 

auf spezielle Anwendungssituationen zugeschnitten waren. 

Allerdings hätte das Bekenntnis zugunsten generischer, von speziellen Anwendungssituationen 

abstrahierender Lösungen für Probleme des betrieblichen Wissensmanagements zugleich 

bedeutet, dass im Verbundprojekt KOWIEN nur relativ – d.h. im Vergleich zu anderen 

BMBF-geförderten, anwendungsnahen Projekten – allgemein gehaltene Erkenntnisse hätten 

gesammelt werden können. Dies hätte die Gefahr von zwar allgemeingültigen, aber praxisfernen 

Forschungs- und Entwicklungsarbeiten herauf beschworen. Um dieser Gefahr vorzubeugen, 

wurde ein spezielles Projektdesign gewählt. Es erlaubt, sowohl die allgemeine – „generische“ 

– Ausgestaltung der Modelle und Methoden als auch – anhand ausgewählter Anwendungsszenarien 

– ihre speziellen Ausprägungen für eine breite Palette unterschiedlicher konkreter 

Anwendungsfälle zu untersuchen. Daher erfolgte von vornherein eine Fokussierung 

knapper Personal-, Zeit- und Finanzressourcen auf zwei exemplarische Anwendungsszenarien. 

Ihrer Auswahl lagen vier Kriterien zugrunde: 

• Die Szenarien müssen sich auf die Erfüllung von Engineering-Aufgaben erstrecken. 

• Die Szenarien sollen sich jeweils durch eine hohe Wissensintensität ihrer Wertschöpfungsprozesse 

auszeichnen. 

• Damit die eingangs geschilderte Komplexität und Dynamik des Projektgeschäfts zur Geltung 

kommt, soll eine projektbezogene Organisation der Aufgabenerfüllung dominieren. 

• Es wird ein „ausgewogenes“ Verhältnis zwischen Ähnlichkeit und Verschiedenartigkeit der 

beiden Szenarien angestrebt. Einerseits sollen die Szenarien „hinreichend“ verschiedenartig 

sein, um szenarienspezifische Anpassungserfordernisse („Tailoring“) für die zu entwickelnden 

Instrumente identifizieren zu können. Andererseits sollen sich die Szenarien noch 

so weit ähneln, dass ein wechselseitig befruchtender Erkenntnistransfer zwischen beiden 

Szenarien möglich erscheint. 

Die nachfolgend aufgeführten zwei Anwendungsszenarien, die im Verbundprojekt KOWIEN 

näher untersucht wurden, erfüllen die vier vorgenannten Auswahlkriterien: 

� Das Produkt-Engineering-Szenario konzentriert sich auf Projekte zur personell, räumlich 

und institutionell verteilten Entwicklung komplexer, technologie- und somit auch 

wissensintensiver Produkte (Sachgüter) 25) . Es werden Unternehmen betrachtet, die in einem 

Engineering-Netzwerk auf begrenzte Zeit arbeitsteilig zusammenwirken, um die gemeinsam 

übernommene Entwicklungsaufgabe als „virtuelle Einheit“ zu erfüllen, nach erfolgreicher 

Produktentwicklung den Unternehmensverbund jedoch wieder auflösen, um 

sich neuen Engineering-Aufgaben in neuen Netzwerk-Konfigurationen zuzuwenden. Der 

Schwerpunkt liegt hier auf der Identifizierung und dem Abgleich von Profilen technologischer 

Kompetenzen. Solche Kompetenzprofile brauchen sich nicht nur auf einzelne Mitarbeiter 

oder Mitarbeitergruppen, wie z.B. erfolgreiche Projektteams, als Wissensträger zu 

erstrecken. Vielmehr können sie sich ebenso auf Unternehmensabteilungen oder auch auf 

inner- und außerbetriebliche Wissensquellen, wie z.B. Wissensbanken, beziehen. Die 

Kompetenzprofile spielen in der betrieblichen Praxis sowohl zur Auftragsakquisition im 

25) Grundsätzlich umfasst der ökonomische Produktbegriff (im Sinne von Gütern zur Befriedigung von Bedürfnissen) als 

Oberbegriff sowohl Sachgüter als auch Dienstleistungen. Um im Verbundprojekt KOWIEN jedoch eine praxisnahe 

Diktion zu ermöglichen, werden Sachgüter des Öfteren auch vereinfachend als „Produkte“ angesprochen, so z.B. in 

der Formulierung „Produkt-Engineering“. Wenn dagegen verdeutlicht werden soll, dass es sich bei Produkten nicht 

um Sachgüter handelt, wird ausdrücklich – und synonym – von „Dienstleistungen“, „Serviceleistungen“ oder „Services“ 

gesprochen. 

39


Projektgeschäft als auch zur Erschließung und Bewahrung von kompetenzstiftendem Wissen 

trotz fluktuierenden Personalbestands eine herausragende Rolle. Insbesondere bei wissensintensiven 

Engineering-Leistungen zählt die Verfügbarkeit von aussagekräftigen, verlässlichen 

Kompetenzprofilen oftmals zu einem der wichtigsten strategischen Erfolgsfaktoren 

für Projektakquisition und Projekterfolg. 

� Das Service-Engineering-Szenario ähnelt zwar strukturell dem erstgenannten Szenario, 

überträgt jedoch den Kerngedanken des Managements von Kompetenzwissen aus dem 

Bereich technologieintensiver Sachgüter auf das Gebiet wissensintensiver Serviceleistungen 

26) . Der Wertschöpfungsanteil solcher Serviceleistungen nimmt bei der Herstellung 

technologieintensiver Sachgüter beständig zu. Insbesondere bei Investitionsgütern, deren 

„Hardware“ in anderen Nationen mit deutlichen Kostenvorteilen produziert werden kann, 

stellen die „ergänzenden“ Serviceleistungen für die führenden Industrie- und Dienstleistungsnationen 

ein wesentliches Differenzierungsmerkmal mit oftmals wettbewerbsentscheidender 

Qualität dar 27) . Beispielsweise werden im deutschen Maschinen- und Anlagenbaugeschäft 

vor, während und nach der Nutzungszeit eines Investitionsguts häufig 

dreimal soviel Erlöse mit Serviceleistungen für Beratung, Finanzierung, Projektmanagement, 

Transport, Montage, Inbetriebnahme, Kundenschulung, Wartung, Ersatzteillieferung 

und Entsorgung erzielt wie mit dem Absatz des betroffenen Investitionsguts. Das 

US-amerikanische Unternehmen United Technologies verdient ca. 40% seines Umsatzes 

im Geschäftsbereich Aufzüge mit Wartungs- und Modernisierungs-Service; ähnlich liegen 

die Verhältnisse bei der Aufzugssparte des Ruhrgebiets-Konzerns ThyssenKrupp. Die 

Leipziger IAB Ingenieur und Anlagenbau GmbH hat sich im Rahmen einer Nischenstrategie 

auf die Dienstleistung des „Revamping“, d.h. der Modernisierung und Erweiterung 

bestehender Industrienanlagen ohne Unterbrechung des laufenden Betriebs spezialisiert 

und hierdurch zu alter Wettbewerbsstärke zurückgefunden. Die Beispiele aus der Investitionsgüterindustrie 

ließen sich beliebig vermehren. Darüber hinaus stehen wissensintensive 

Serviceleistungen auch bei global agierenden Unternehmen der Consulting-Branche im 

Zentrum ihrer Wertschöpfungsprozesse. Das persönliche Erfahrungswissen der Consultants 

und die Kenntnisse über ihre jeweiligen Kompetenzen zählen zu den strategischen 

Ressourcen der betroffenen Unternehmen. 

Der Schwerpunkt des Projekts KOWIEN lag auf dem Produkt-Engineering-Szenario. Diese 

Betonung der Herstellung von Sachgütern schlägt sich in der Zusammensetzung des Projektkonsortiums 

nieder (vgl. Abschnitt 4.3). Allerdings wurde das Service-Engineering-Szenario 

als „Kontrapunkt“ bewusst nicht vernachlässigt. Dafür sprachen im Wesentlichen zwei Gründe. 

Erstens war es nur durch den Vergleich zwischen Produkt- und Service-Engineering- 

Szenario möglich, charakteristische Unterschiede des Kompetenzmanagements herauszuarbeiten, 

die zwischen einerseits Sachgüter- und andererseits Dienstleistungsproduktion bestehen. 

Zweitens konnten Erkenntnisse, die nur in einem der beiden Szenarien gewonnen wurden, 

benutzt werden, um das jeweils andere Szenario mit „überraschenden“ oder „ungewöhnlichen“ 

Einsichten zu konfrontieren und zu befruchten. Beispielsweise konnte der Praxispart- 

26) Das Zusammenstellen und Zusammenarbeiten von Projektteams, die innerhalb eines Unternehmens oder in Unternehmensverbünden 

eine innovative Serviceleistung entwickeln sollen, wird maßgeblich von den Profilen der jeweils 

benötigten und/oder vorhandenen Service-Kompetenzen beeinflusst. Hierbei kommt es insbesondere darauf an, die 

Kooperation von Akteuren aus solchen (Service-) Engineering-Netzwerken mit heterogenen Wissenshintergründen 

durch Kommunikation über ihr gemeinsam eingebrachtes Wissen zu koordinieren. 

27) Vgl. beispielsweise die Beiträge in LUCZAK, H. (Hrsg.): Servicemanagement mit System – Erfolgreiche Methoden für 

die Investitionsgüterindustrie, Berlin et al. 1999; sowie KILLINGER, S.: Kernproduktbegleitende Dienstleistungen – 

Dienstleistungen im Leistungsspektrum industrieller Unternehmungen. In: CORSTEN, H.; SCHNEIDER, H. (Hrsg.): 

Wettbewerbsfaktor Dienstleistung, Produktion von Dienstleistungen – Produktion als Dienstleistung, München 1999, 

S. 129-155. 

40


ner aus dem Service-Engineering-Szenario mit seinem ausgefeilten Wissensmanagementsystem 

„BRAIN“, das zur Unterstützung wissensintensiver Beratungsdienstleistungen entwickelt 

worden war, Impulse vermitteln, um das Wissensmanagement der Praxispartner aus dem Produkt-Engineering-Szenario 

inhaltlich fortzuentwickeln. Diese Impulse erstreckten sich beispielsweise 

auf eine tiefe analytische Durchdringung von Kompetenzarten und - 

ausprägungen, die der Praxispartner aus dem Service-Engineering-Szenario bereits geleistet 

hatte und von den Praxispartnern aus dem Produkt-Engineering-Szenario zur Entwicklung ihrer 

eigenen Kompetenzsystematisierungen aufgegriffen werden konnte. Solche „cross impacts“ 

hätten nicht bewirkt werden können, wenn auf Seiten der Praxispartner nicht der Mut 

beständen hätte, Befruchtungen aus dem jeweils anderen „Lager“ von Produkt- oder Service- 

Engineering-Szenario vorbehaltlos zu prüfen und – im positiven Fall – auf das jeweils eigene 

Unternehmen zu übertragen. Nicht nur, aber insbesondere in dieser Hinsicht ist dem BMBF 

und seinem Projektträger Produktion und Fertigungstechnologien (PFT), der Forschungszentrum 

Karlsruhe GmbH, für die Umsicht zu danken, so verschiedenartige Unternehmen wie die 

Produzenten von Sachgütern und Dienstleistungen in einem gemeinsamen, praxisorientierten 

Forschungs- und Entwicklungsprojekt zusammenzuführen und zu stimulieren, wechselseitig 

voneinander zu lernen. 

Die Aufteilung der Projektpartner auf die beiden Anwendungsszenarien konnte allerdings 

nicht trennscharf erfolgen – und war auch so nicht beabsichtigt. Einerseits verfügt der Praxispartner 

aus der servicedominierten Consulting-Branche über einschlägiges industrielles Erfahrungswissen 

und weit reichende Kontakte zu Unternehmen aus der Investitionsgüter produzierenden 

Industrie. Beides wurde im Verbundprojekt KOWIEN zur Wissensakquisition, - 

evaluierung und -verbreitung genutzt. Andererseits verlieren die Unterschiede zwischen Produkt- 

und Service-Engineering durch den zunehmenden Anteil von Serviceleistungen an der 

Herstellung und Vermarktung von Sachgütern – insbesondere Investitionsgütern – zunehmend 

an Bedeutung. Daher eröffnet die gemeinsame Behandlung von Aspekten sowohl aus 

dem Produkt- als auch aus dem Service-Engineering-Bereich die Chance, durch wechselseitigen 

Erkenntnistransfer einen besonderen Beitrag zu leisten, um die Entwicklung von innovativen, 

technologie- und serviceintensiven Produkten mit Instrumenten des Wissensmanagements 

zu unterstützen. 

1.4 Neuartigkeit der Projektarbeiten 

Der innovative Charakter des Verbundprojekts KOWIEN resultiert aus zwei Quellen. Die erste 

erstreckt sich auf einen Leverage-Effekt innerhalb einer modernen Konzeption des Produktionsmanagements. 

Die zweite betrifft den Transfer von Erkenntnissen aus dem Bereich der 

(Kern-) Informatik und der KI-Forschung in betriebswirtschaftliche Anwendungen. 

Der Leverage-Effekt manifestiert sich zunächst darin, das Denkmuster der „ingenieurmäßigen“ 

Produktentwicklung aus dem vertrauten Bereich des Engineerings komplexer, technologieintensiver 

Sachgüter auf die ebenso „ingenieurmäßige“ Entwicklung komplexer Serviceleistungen 

zu übertragen. Dies entspricht einem modernen produktionswirtschaftlichen 

Selbstverständnis, das sich nicht nur mit der Hervorbringung von materiellen Gütern befasst, 

sondern die „Produktion von Dienstleistungen“ gleichrangig untersucht. Die gemeinsame inhaltliche 

Klammer innerhalb des Verbundprojekts KOWIEN bildet die Notwendigkeit, in den 

beiden Bereichen der Sachgüter- und der Dienstleistungsproduktion heterogene Wissensbestände 

mittels Wissens über Kompetenzen, Kompetenzträger und Kompetenzprofile zu managen. 

Dies gilt zumindest in dem Ausmaß, in dem in Produkt- bzw. Service-Engineering- 

41


Netzwerken teilautonome Wertschöpfungspartner zusammenarbeiten, um eine wissensintensive 

Produktionsaufgabe gemeinsam zu erfüllen. 

Zugunsten der Ausdehnung des Gegenstandsbereichs des Verbundprojekts KOWIEN auf das 

Service-Engineering-Szenario spricht, dass in der Betriebswirtschaftslehre seit wenigen Jahren 

zunehmend die Ansicht Verbreitung gewinnt, auch die Entwicklung neuartiger Dienstleistungen 

könne mit der Hilfe von systematischen, ingenieurmäßig angewendeten Methoden effektiv 

unterstützt werden. Hierfür hat sich inzwischen der Terminus technicus „Service Engineering“ 

etabliert 28) . Aus dieser Perspektive hat das Projekt KOWIEN dazu beigetragen, Instrumente, 

die ursprünglich für das Management von Kompetenzwissen im Produkt- 

Engineering-Szenario entwickelt wurden, auf die Erfüllung analoger Managementaufgaben 

im Service-Engineering-Szenario übertragen zu können. Dazu gehört beispielsweise das Vorgehensmodell 

zur Konstruktion und Anwendung einer Kompetenzontologie, das zunächst 

gemeinsam mit einem der Praxispartner aus dem Produkt-Engineering-Szenario erarbeitet 

wurde, sich aber unter relativ geringfügigen Anpassungen auch im Service-Engineering- 

Szenario einsetzen lässt. Auf diese Weise war es möglich, die noch junge betriebswirtschaftliche 

Disziplin des Service Engineerings durch Erkenntnisse aus dem „klassischen“, auf Sachgüter 

fokussierten Produktionsbereich zu bereichern. 

Allerdings erweist sich der produktionswirtschaftliche Leverage-Effekt als bilateral. Denn bei 

genauerer Analyse zeigt sich immer wieder, dass auch serviceorientierte Denk- und Handlungsmuster 

in die Produktion von Sachgütern erfolgreich übertragen werden können. Dazu 

gehört insbesondere, das Bewusstsein von Sachgüter produzierenden Unternehmen dafür zu 

sensibilisieren, dass der Markterfolg ihrer Produkte keineswegs von deren „Hardware“ allein 

bestimmt wird, sondern zu bedeutsamen Anteilen auch von „soft factors“ abhängt. Dazu gehören 

beispielsweise die Bereitschaft der Sachgüterproduzenten, zielgruppengerechte Produktschulungen 

anzubieten, sowie die Bereitschaft, die Benutzerschnittstellen der Produkte 

auf die kognitiven Prädispositionen ihrer potenziellen Benutzer abzustimmen. Im Verbundprojekt 

KOWIEN manifestierte sich dieser „bewusstseinserweiternde“ Effekt der Zusammenarbeit 

mit Dienstleistern auf der Seite der Sachgüter produzierenden Praxispartner vor allem 

in einer Sensibilisierung dafür, ihre eigenen Produkte nicht mehr als reine Sachgüter zu begreifen, 

sondern vielmehr als komplexe Bündel aus Sach- und Dienstleistungen, die erst in ihrer 

Gesamtheit – „ganzheitlich“ – die Probleme ihrer Kunden zu lösen vermögen. Dieses 

problem- und lösungsorientierte, auf die umfassende Befriedigung von Kundenbedürfnissen 

abzielende Produktverständnis ist zurzeit unter Dienstleistungsproduzenten tendenziell stärker 

ausgeprägt als unter „klassischen“ Produzenten von Sachgütern. Daher erweist sich auch der 

inverse Leverage-Effekt, der zu einer Befruchtung der Sachgüterproduktion durch Denkmuster 

aus dem Bereich der Produktion von Dienstleistungen führt, als ein innovativer, z.B. für 

den „klassischen“ Maschinen- und Anlagenbau durchaus noch nicht ausgeschöpfter Denkund 

Handlungsansatz 29) . 

Der zweite Innovationsbereich betrifft den Transfer von Erkenntnissen aus dem Bereich der 

(Kern-) Informatik und der KI-Forschung in betriebswirtschaftliche Anwendungen. Zur operativen 

Umsetzung des Wissensmanagements in Engineering-Netzwerken anhand von Kompe- 

28) Vgl. dazu die Beiträge in BULLINGER, H.-J.; SCHEER, A.W. (Hrsg.): Service Engineering, Berlin et al. 2002. Relativ 

frühzeitig wurde der o.a. Terminus technicus bereits in der Fachzeitschrift „IM – Fachzeitschrift für Information Management 

& Consulting“ verwendet, die diesem Themenbereich im August 1998 eine eigenständige Sonderausgabe 

„Service Engineering“ widmete. 

29) Empirische Untersuchungen weisen für den deutschen Maschinen- und Anlagenbau nach, dass seine Unternehmen 

sich selbst für kundenorientiert halten, während ihre Abnehmer überwiegend eine mangelhafte Kundenorientierung 

beklagen. Vgl. dazu o.V.: Maschinenherstellern fehlt Kundenorientierung – Wettbewerbsdruck ausländischer Anbieter 

/ Studie des VDMA. In: Frankfurter Allgemeine Zeitung, Ausgabe vom 14.04.1997, Nr. 86, S. 17. 

42


tenzprofilen wird auf einen methodischen Ansatz zurückgegriffen, der sowohl im konventionellen 

Engineering-Bereich als auch in der etablierten Betriebswirtschaftslehre innovative 

Qualität besitzt: Für Zwecke des Wissensmanagements wird eine generische Methodik 30) zur 

Konstruktion und Anwendung von Ontologien entwickelt. Anwendungen dieser neuartigen 

Methodik werden im Folgenden kurz als ontologiebasiertes Wissensmanagement bezeichnet. 

Unter einer Ontologie wird – in einer ersten groben, bewusst vereinfachten Annäherung 31) – 

eine formalsprachliche Spezifikation der sprachlichen Ausdrucksmittel für gemeinsam verwendete 

Konzeptualisierungen von Phänomenen der Realität verstanden. Solche Ontologien 

gestatten es, zunächst unstrukturierte, unter Umständen sogar tazite oder nur natürlichsprachlich 

artikulierte Wissensbestände so aufzubereiten, dass die Wissensinhalte nicht nur auf der 

syntaktischen, sondern vor allem auch auf der semantischen Ebene explizit und formalsprachlich 

strukturiert werden. Ontologien unterstützen mittels ihrer expliziten und formalen Semantik 

die computerbasierte Verarbeitung von Wissen und leisten daher einen maßgeblichen Beitrag 

zur allseits angestrebten, Effizienz steigernden Wiederverwendung von Wissen („knowledge 

reuse“). Mit ihrer formalen Semantik stehen Ontologien in unmittelbarem Zusammenhang 

mit den aktuellen Forschungs- und Entwicklungsanstrengungen, ein weltumspannendes 

„Semantic Web“ zu etablieren. Dieses „Semantic Web“ gilt zurzeit als eines der interessantesten 

Innovationsgebiete im Bereich der angewandten Informatik 32) . 

Im Gegensatz zur Wirtschaftsinformatik, in der Ontologien seit wenigen Jahren schon zuweilen 

Beachtung gefunden haben, stellen Ontologien in der Betriebswirtschaftslehre – und noch 

mehr in den Ingenieurwissenschaften – wissenschaftliches Neuland dar. Dies gilt sowohl für 

die Grundlagenforschung als auch für die praxisorientierte Entwicklung betriebswirtschaftlicher 

bzw. ingenieurtechnischer Anwendungssoftware. Daher bewegt sich das Verbundprojekt 

KOWIEN mit der Entwicklung einer Methodik für ontologiebasiertes Wissensmanagement – 

einschließlich eines prototypischen Software-Tools für ontologiebasierte Kompetenzmanagementsysteme 

– auf einem Gebiet mit außerordentlich hohem betriebswirtschaftlichen und 

ingenieurtechnischen Innovationspotenzial. Dieses Innovationspotenzial wurde innerhalb des 

Verbundprojekts KOWIEN in zweifacher Richtung realisiert. 

Einerseits wurde ein Vorgehensmodell für die systematische Konstruktion und Anwendung 

von Ontologien für ontologiebasierte Kompetenzmanagementsysteme entwickelt. Ein solches 

Vorgehensmodell existiert in der einschlägigen Fachliteratur noch nicht, zumindest nicht in 

seiner konkreten Ausgestaltung in Bezug auf das Management von Wissen über Kompetenzen, 

Kompetenzträger und Kompetenzprofile. Darüber hinaus erweisen sich die wenigen 

Vorgehensmodelle, die sich in der Fachliteratur zu Ontologien finden lassen, als sehr abstrakt 

30) Unter einer Methodik wird hier eine Sammlung mehrerer Methoden verstanden, die zur Erfüllung unterschiedlicher 

Teile einer Gesamtaufgabe dienen. 

31) Im Verbundprojekt KOWIEN wird eine präzisere und inhaltlich differenzierte Arbeitsdefinition von Ontologien verwendet, 

die auf den weit verbreiteten Definitionsansatz von GRUBER zurückgeht. Vgl. dazu GRUBER, T.R.: A Translation 

Approach to Portable Ontology Specifications. Knowledge Systems Laboratory Technical Report KSL 92-71, 

Computer Science Department, Stanford University, Revised Version vom April 1993 [Original vom September 

1992], Stanford 1993, Abstract auf S. 1 sowie S. 2 u. 11 (auch erschienen in: Knowledge Acquisition, Vol. 5 (1993), 

No. 2, S. 199-220); vgl. ebenso die darauf aufbauende, jedoch gehaltreichere Definition in ZELEWSKI, S.: Organisierte 

Erfahrung – Wissensmanagement mit Ontologien. In: Essener Unikate, Nr. 18: Wirtschaftsinformatik – Wissensmanagement 

und E-Services, Essen 2002, S. 63-73; hier: S. 66 f. 

32) Die Erforschung und Entwicklung des Semantic Web wird u.a. seitens des BMBF mit beträchtlichen Finanzmitteln 

gefördert; vgl. dazu die jüngst via E-Mail publizierte Meldung im Pressedienst des BMBF (BMBF-Aktuell, Berlin, 

28.06.2004): „BMBF fördert Web-Technik der Zukunft mit 13,7 Millionen Euro“. Dort wird „die Entwicklung einer 

Software, durch die das Web den Inhalt der eingegebenen Sätze versteht“ angekündigt, die im Verbundprojekt 

„SmartWeb“ unter der Federführung des Deutschen Forschungszentrums für Künstliche Intelligenz (DFKI) erfolgen 

soll. 

43


formuliert: Sie erschöpfen sich in relativ allgemein gehaltenen Vorgehensempfehlungen, die 

für die konkrete Anwendung in der betrieblichen Praxis noch nicht ausreichen. Dagegen wurde 

im Verbundprojekt KOWIEN besonderer Wert darauf gelegt, das Vorgehensmodell durch 

die Integration von Werkzeugen für die einzelnen Vorgehenselemente – wie z.B. unterstützende 

Software sowie standardisierte Erfassungs- und Auswertungsformulare – so konkret 

und praxisnah wie möglich zu gestalten. Dieser Möglichkeitsspielraum wird dadurch begrenzt, 

dass es sich – im Interesse des o.a. „knowledge reuse“ – weiterhin um ein generisches, 

d.h. in unterschiedlichen Anwendungssituationen einsetzbares Vorgehensmodell handeln soll. 

Um den inhärenten Konflikt zwischen möglichst hoher Konkretisierung (Praxistauglichkeit) 

einerseits und möglichst hoher Wiederverwendbarkeit (Generizität) andererseits tendenziell 

aufzulösen, wurde auf bewährte Gestaltungsprinzipen der Systemtechnik und Betriebswirtschaftslehre 

zurückgegriffen, die sich unter Schlagworte wie Baukastensysteme, Modularisierung 

und „mass customization“ subsumieren lassen. 

Andererseits wurde ein prototypisches Software-Tool für das ontologiebasierte Management 

von Wissen über Kompetenzen, Kompetenzträger und Kompetenzprofile entwickelt, der so 

genannte „KOWIEN-Prototyp“. Dieser Prototyp stellt einen ersten, noch „vor-kommerziellen“ 

Ansatz für ein ontologiebasiertes Kompetenzmanagementsystem dar. Er soll im Sinne 

einer „Machbarkeitsstudie“ nachweisen, welche Aspekte von ontologiebasierten Kompetenzmanagementsystemen 

mit Instrumenten des softwaretechnischen State-of-the-art derzeit 

unter zwei Restriktionen umgesetzt werden können. Erstens muss sich ein solches Kompetenzmanagementsystem 

in etablierte „Softwarewelten“ integrieren lassen, um seitens potenzieller 

betrieblicher Anwender aus den Blickwinkeln von Interoperabilität und Wirtschaftlichkeit 

akzeptiert werden zu können. Durch diese Anforderung wird der Innovationsgrad der 

Softwarelösungen, die im prototypischen Software-Tool für Probleme des computerbasierten 

Kompetenzmanagements realisiert werden, im Hinblick auf etablierte Softwaresysteme deutlich 

eingeschränkt. Zweitens zeigte sich im Verlauf des Verbundprojekts KOWIEN, dass 

nicht jedes Konzept für ontologiebasierte Kompetenzmanagementsysteme, das zurzeit in 

Hochschulinstituten und anderen „think tanks“ theoretisch erforscht sowie in manchen innovativen 

Spezialunternehmen bereits in erste praktische Anwendungen umgesetzt wird, seitens 

renommierter Softwareproduzenten als praktikabel erachtet wird. Dies gilt insbesondere im 

Hinblick auf prädikatenlogisch dargestellte Inferenzregeln (sowohl objekt- als auch metasprachlicher 

Art) und prädikatenlogisch basierte Theorembeweiser, so genannte „Inferenzmaschinen“. 

Auf die Besonderheiten des Vorgehensmodells für die systematische Konstruktion und Anwendung 

von Ontologien für ontologiebasierte Kompetenzmanagementsysteme und des prototypisches 

Software-Tools für das ontologiebasierte Management von Kompetenzwissen 

wird hier nicht näher eingegangen. Stattdessen wird auf die diesbezüglichen, vertiefenden 

Beiträge in diesem Werk verwiesen. 

44


2 Ziele und Ergebnisse des Verbundprojekts KOWIEN 

2.1 Projektziele 

Die Kernziele des Verbundprojekts KOWIEN lassen sich in zwei Gruppen zusammenfassen: 

die ökonomischen und technologischen Projektziele. 

Aus ökonomischer Perspektive sollen in erster Linie die Effektivität 33) und die Effizienz 34) des 

Managements wissensintensiver Produkt- und Service-Entwicklungsprozesse nachhaltig gesteigert 

werden. Dies schließt – als spezielle Facette des Effektivitätsziels – auch das Ziel ein, 

die Qualität der Entwicklungsresultate zu erhöhen. Als besondere Ausprägung des Effizienzziels 

wird ebenso das Ziel verfolgt, die Zeitdauer von wissensintensiven Entwicklungsprozessen 

– aus Produktsicht die „time to market“ – zu reduzieren. Durch diese simultane Fokussierung 

auf Qualitäts- und Zeitziele soll die Wettbewerbsfähigkeit von Unternehmen, die sich 

vorrangig mit der Erfüllung wissensintensiver Engineering-Aufgaben befassen, nachhaltig 

gestärkt werden. 

Aus der Stärkung der Wettbewerbsfähigkeit resultiert der unmittelbare Praxisbezug des Verbundprojekts. 

Unternehmen in Hochlohnländern wie der Bundesrepublik Deutschland können 

sich im internationalen Wettbewerb oftmals nur noch dadurch behaupten, dass sie schwer imitierbare 

und kaum substituierbare Wettbewerbsvorteile zur Differenzierung gegenüber ihren 

Konkurrenten mit günstigeren Kostenstrukturen nutzen. Zu diesen spezifischen Wettbewerbsvorteilen 

gehört vor allem das hohe Fach- und Prozesswissen der Mitarbeiter (einschließlich 

des ebenso genutzten organisationalen Wissens), das sich in Handlungen zur Realisierung 

wissensintensiver Produktionsverfahren und Produkte manifestiert. Daher werden alle Spielarten 

von handlungsbefähigendem Wissen – oder kurz: Kompetenzen – zu einem der strategischen 

Erfolgsfaktoren im internationalen Wettbewerb. 

33) Ökonomische Effektivitätsziele betreffen jeweils den Output von Prozessen (hier: von wissensintensiven Produkt- 

und Service-Entwicklungsprozessen). Aus dieser Perspektive wird die Prozessgestaltung („das Prozessmanagement“) 

als umso effektiver beurteilt, je stärker der tatsächlich realisierte Output („Ist-Output“) dem jeweils intendierten Output 

(„Soll-Output“) entspricht. Sofern der Soll-Output als implizit bekannt und akzeptiert vorausgesetzt werden kann, 

werden Effektivitätsziele oftmals auch unter die einprägsame Formel „das Richtige tun“ („doing the right things“) 

subsumiert. Dabei entspricht das „Richtige“ implizit dem jeweils vorausgesetzten Soll-Output. Ein typisches Effektivitätsziel 

erstreckt sich auf die Erhöhung der Ist-Qualität von Entwicklungsprozessen in Bezug auf ein Soll- 

Qualitätsniveau, das entweder fest vorgegeben ist oder im Zeitablauf variiert, z.B. in Abhängigkeit vom aktuellen 

Stand der Technik oder den gegenwärtigen Wettbewerbsverhältnissen am Markt. Soll- und Ist-Qualitäten stellen dabei 

messbare Outputs der jeweils beurteilten Entwicklungsprozesse dar. 

34) Ökonomische Effizienzziele betreffen jeweils das Verhältnis zwischen dem Output und dem Input von Prozessen 

(hier: von wissensintensiven Produkt- und Service-Entwicklungsprozessen). Aus dieser Perspektive wird die Prozessgestaltung 

(„das Prozessmanagement“) als umso effizienter beurteilt, je größer das Output/Input-Verhältnis ist. 

Dabei können einerseits Ist-Outputs mit Ist-Inputs oder andererseits Soll-Outputs mit Soll-Inputs miteinander in Relation 

gesetzt werden. Effektivitätsziele werden oftmals auch unter die einprägsame Formel „etwas richtig tun“ („doing 

things right“) subsumiert. Dabei entspricht das Adverb „richtig“ implizit einem Output/Input-Verhältnis, das vom 

Beurteilenden – gemäß seinen Höhenpräferenzen – als „optimal“ im Sinne von „maximal“ (Extremierungsziele), besser 

stellend (Meliorisierungsziele), „zufrieden stellend“ (Satisfizierungsziele) oder ähnlich empfunden wird. Die 

Zeitdauer von Entwicklungsprozessen stellt ein typisches Effizienzziel dar, bei dem der Prozessoutput in der Gestalt 

von angestrebten Entwicklungsresultaten fest vorgegeben ist. Unter der Voraussetzung, dass die angestrebten Entwicklungsresultate 

tatsächlich realisiert werden (ein rein outputorientierter Effektivitätsaspekt), misst die Zeitdauer, 

die bis zur Realisierung der angestrebten Entwicklungsresultate verstreicht, den „temporalen Ressourceneinsatz“, also 

den Input der Entwicklungsprozesse. Die Prozesseffizienz ist bei fest vorgegebenem Prozessoutput umso größer, je 

geringer der Prozessinput – hier also die Entwicklungsdauer – ausfällt. 

45


Allerdings herrscht derzeit noch ein eklatanter Mangel an effektiven und effizienten Instrumenten 

für ein systematisches und zugleich praxistaugliches Wissensmanagement 35) . Die 

zahlreichen „Ratgeber“ zum Thema Wissensmanagement bestätigen diese Lücke eher, als sie 

wissenschaftlich fundiert zu schließen. Denn diese Ratgeber vermitteln lediglich Ad-hoc- 

Ratschläge für angeblich erfolgreiches Wissensmanagement, ohne ein „belastbares Fundament“ 

für die Richtigkeit ihrer Empfehlungen anbieten zu können. Stattdessen berufen sie 

sich in der Regel auf eklektizistische „Erfolgsbeispiele“, die sich in zweifacher Hinsicht als 

höchst fragwürdig erweisen. Einerseits erweisen sich diese Beispiele oftmals einige Jahre später 

als Krisenfälle; als pars pro toto sei auf den Missgriff zahlreicher angeblicher Erfolgsbeispiele 

aus dem vielfach gepriesenen Praxisratgeber „In Search of Excellence“ von PETERS und 

WATERMAN verwiesen 36) . Andererseits leidet die eklektizistische Vorgehensweise darunter, 

dass oftmals eine Fülle von Gegenbeispielen existiert, aber von den Autoren schlicht unterschlagen 

wird, weil sie nicht in das Ad-hoc-Argumentationsmuster zu passen scheint. Aus den 

vorgenannten Gründen besteht auf Unternehmensseite ein erheblicher praktischer Bedarf für 

Instrumente, die das Management wissensintensiver Produktionen systematisch und wissenschaftlich 

fundiert unterstützen. Dies gilt insbesondere für den hier fokussierten Fall der Entwicklung 

wissensintensiver Sachgüter und Dienstleistungen, weil Entwicklungsprozesse von 

vornherein auf die Generierung und Anwendung von Wissen abzielen. 

Aus technologischer 37) Perspektive soll aufgezeigt werden, wie sich Ontologien, die auf die 

kooperative Entwicklung von Sachgütern und Dienstleistungen in Engineering-Netzwerken 

zugeschnitten sind, in der betrieblichen Praxis für Zwecke des Managements von Wissens über 

Kompetenzen, Kompetenzträger und Kompetenzprofile erfolgreich konstruieren und anwenden 

lassen. Hierdurch soll eine technische Umsetzungslücke durch anwendungsnahe Forschungs- 

und Entwicklungsarbeiten geschlossen werden. Diese Umsetzungslücke klafft zwischen 

theoretisch-konzeptionellen Erkenntnissen des Knowledge-Level-Engineerings einerseits 

und ihrer konkreten Anwendung in der betrieblichen Praxis andererseits. Das Knowledge-Level-Engineering 

stellt eine der wichtigsten und zurzeit fruchtbarsten „Schlüsseltechniken“ 

auf dem Gebiet der Erforschung Künstlicher Intelligenz und der (Kern-) Informatik dar. 

Ontologien stellen aus der Perspektive des Knowledge-Level-Engineerings einen der Erfolg 

versprechendsten Ansätze für die Entwicklung computerbasierter Wissensmanagementsysteme 

dar. Sie erfahren seit Beginn der neunziger Jahre vornehmlich in den U.S.A., in 

Kanada sowie in Großbritannien rasch zunehmende Beachtung unter Forschern, haben jedoch 

bislang noch keinen Eingang in praxiserprobte betriebliche Anwendungssoftware gefunden. 

Daher besteht ein wesentliches Anliegen des Verbundprojekts KOWIEN auf dem Gebiet des 

Technologietransfers: Mit dem Vorhaben soll demonstriert werden, wie sich Ontologien aus 

dem Status eines reinen, ehemals anwendungsfernen Forschungsobjekts in konkrete betriebliche 

Anwendungen für computerbasierte Wissens-, insbesondere Kompetenzmanagementsys- 

35) Vgl. dazu die Feststellung „Derzeit fehlen unternehmensweit verfügbare Werkzeuge und Methoden, um das vorhandene 

Erfahrungswissen effizient zu nutzen, bzw. weiterzuentwickeln.“ [Kommasetzung gemäß dem Original] im 

Rahmen des BMBF-Leitprojekts „integrierte Virtuelle Produktentstehung“ (iViP) unter der URL „http://www.ivip. 

de/TeilProjekte/Flyer/Flyer31/Projekt31.htm“ (letzter Zugriff am 13.07.2004). 

36) Vgl. PETERS, T.J.; WATERMAN, R.H.: In Search of Excellence: Lessons from America's Best-Run Companies, New 

York 1982 (Neuausgabe: London: 2004 / deutsche Übersetzung: Auf der Suche nach Spitzenleistungen: was man von 

den bestgeführten US-Unternehmen lernen kann, 10. Aufl., Frankfurt am Main 2004) – sowie die prononcierte Kritik 

an „Belastbarkeit“ solcher „Erfolgsbeispiele“ durch FRESE, E.: Exzellente Unternehmungen – konfuse Theorien. Kritisches 

zur Studie von PETERS und WATERMAN. In: Die Betriebswirtschaft, 45. Jg. (1985), Heft 5, S. 604-605. 

37) Die Attribute „technologisch“ und „technisch“ werden hier der Einfachheit halber synonym verwendet, da sich ihre 

unterschiedslose Verwendung im Sprachgebrauch der betrieblichen Praxis etabliert hat. Mit dem Attribut „technologisch“ 

wird also nicht auf eine „Lehre von den Techniken“ verwiesen, sondern schlicht eine einzelne Technik oder 

eine Gruppe von Techniken referenziert. 

46


teme überführen lassen. Zur Unterstützung dieses Transferprozesses, d.h. zur Konstruktion 

und Anwendung von Ontologien für computerbasierte Kompetenzmanagementsysteme wird 

ein neuartiges Vorgehensmodell entwickelt. Aufgrund der Neuartigkeit der Anwendung von 

Ontologien in der betrieblichen Praxis lässt sich im internationalen Wettbewerb zwischen den 

Anbietern wissensintensiver Produkte (Sachgüter) und Services (Dienstleistungen) ein Innovationsvorsprung 

gegenüber Konkurrenten erzielen. 

Aufgrund der vorgenannten ökonomischen und technologischen Kernziele soll das Verbundprojekt 

KOWIEN innerhalb des Rahmenkonzepts „Forschung für die Produktion von morgen“ 

vom 5. September 2000 vor allem einen Beitrag zum Themenfeld 2.1 „Produktentwicklung 

für die Produktion von morgen“ leisten 38) . Die angestrebten Effektivitäts- und Effizienzsteigerungen 

hinsichtlich des Managements wissensintensiver Produkt- und Service- 

Entwicklungsprozesse referenzieren den Bereich der Produktentwicklung unmittelbar. Dabei 

spielt die Entwicklung zukunftsträchtiger Produkte („für die Produktion von morgen“) auf 

zweifache Weise eine besondere Rolle. Zum einen erfolgt eine Fokussierung auf die Erfüllung 

wissensintensiver Engineering-Aufgaben. Von solchen wissensintensiven Leistungen wird 

vielfach angenommen, dass sie für die zukünftige ökonomische Entwicklung, insbesondere die 

internationale Wettbewerbsfähigkeit hoch entwickelter Industrie- und Dienstleistungsgesellschaften 

eine herausragende Bedeutung besitzen. Etwas überpointiert wird in diesem Zusammenhang 

des Öfteren von einem Übergang zu einer „Wissensgesellschaft“ gesprochen. Zum 

anderen wird im Rahmen des Service-Engineering-Szenarios der Gegenstandsbereich des Projekts 

von vornherein auf den Dienstleistungssektor ausgedehnt, dem in Zukunft weitaus größere 

volkswirtschaftliche Wachstumschancen als dem Sektor der Sachgüterproduktion zugeschrieben 

werden 39) . 

Neben den vorgenannten ökonomischen und technologischen Kernzielen wurde zu Beginn 

des Verbundprojekts KOWIEN ein weiteres Ziel, jedoch mit nachrangiger Gewichtung verfolgt. 

Dieses Nebenziel besaß die Qualität eines technologischen Ziels, das auf eine eng umgrenzte, 

spezielle Frage des Wissensmanagements beschränkt war. Es erstreckte sich auf das 

wechselseitige Verhältnis zwischen zwei Formen der Wissensrepräsentation: den Referenzmodellen 

einerseits und den Ontologien andererseits. Konkret sollte aufgezeigt werden, wie 

sich Wissen, das in Referenzmodellen repräsentiert ist, zur Konstruktion von Ontologien verwenden 

lässt und wie Ontologien in Referenzmodelle zurückübersetzt werden können. Die 

wechselseitige Verknüpfung von Referenzmodellen und Ontologien wurde bislang noch kaum 

untersucht und besitzt daher ebenso innovativen Charakter. Darüber hinaus sind Referenzmodelle 

als Form der Wissensrepräsentation von besonderem Interesse. Betriebswirtschaftliche 

Referenzmodelle haben sich als probates Mittel zur Gestaltung von Organisationsstrukturen 

und Anwendungssoftware herausgestellt. Sie genießen daher in der betrieblichen Praxis bereits 

größere Verbreitung. Insbesondere beim Einsatz von ERP-Systemen kommt Referenz- 

38) Innerhalb des Themenfelds 2.1 „Produktentwicklung für die Produktion von morgen“ betrifft das Verbundprojekt 

KOWIEN in erster Linie die beiden Teilaspekte „Kooperative Produkt- und Prozessentwicklung“ sowie „Wissensmanagement 

zur Produktentwicklung“. Der Bezug zum Wissensmanagement ist offensichtlich, weil ein Instrumentarium 

zur Unterstützung des Managements von Wissen über Kompetenzen, Kompetenzträger und Kompetenzprofile 

für die Erfüllung wissensintensiver Engineering-Aufgaben entwickelt wird. Der Aspekt kooperativer Produkt- und 

Prozessentwicklung kommt dadurch zur Geltung, dass Engineering-Netzwerke betrachtet werden, deren Akteure bei 

der Erfüllung von gemeinsam übernommenen Entwicklungsaufgaben kooperieren. 

39) Vgl. z.B. CORSTEN, H.: Dienstleistungsmanagement, 3. Aufl., München - Wien 1997, S. 12 ff. Vgl. daneben auch das 

Statement von H. GABRIEL zur Übergabe des Berichts des Statistischen Beirats an die Bundesregierung am 

11.08.1999 unter der URL: „http://www.statistik-bund.de/presse/deutsch/pm/p9brstga.htm“: „Das zunehmende Gewicht 

von Dienstleistungstätigkeiten und die Ausweitung des Dienstleistungssektors sind eine Tatsache und nicht erst 

seit heute bekannt. Zukünftige Beschäftigungszuwächse sind vor allem in neuen Dienstleistungsbereichen zu erwarten.“ 

47


modellen eine überragende Bedeutung zu. Aus den vorgenannten Gründen stellen Referenzmodelle 

ein nahezu „ideales“ Ausgangssubstrat für die Akquisition und Strukturierung innersowie 

überbetrieblichen Wissens dar. Sie können als Einstiegspfad für ein ontologiebasiertes 

Wissensmanagement dienen, falls es gelingt, Ontologien mit Referenzmodellen in der zuvor 

angesprochenen Weise zu verzahnen. Daher gilt es z.B. bei der Konstruktion von Ontologien, 

die Wiederverwendbarkeit von bereits vorliegenden Referenzmodellen zu beachten, damit ein 

integriertes Wissensmanagement unterstützt wird, das alle Wissensarten („Ressourcen”) zu 

berücksichtigen vermag, die in einem Unternehmen oder in einem Unternehmensnetzwerk an 

unterschiedlichen Stellen in heterogener Form existieren. 

Der Vorteil von Referenzmodellen, der sich vor allem auf die einfache Nachvollziehbarkeit 

des in ihnen repräsentierten Wissens erstreckt, wird allerdings derzeit zumeist mit Mängeln 

unzureichender Formalisierung „erkauft”. Infolgedessen leiden Referenzmodelle im Allgemeinen 

unter erheblichen Präzisionsdefiziten und können nur rudimentär analytisch ausgewertet 

werden (z.B. im Hinblick auf Konsistenz, Kohärenz und Integrität). Diese Schwächen 

lassen sich beseitigen, wenn es gelingt, Referenzmodelle in Ontologien zu „übersetzen“. Denn 

die durchgängige Formalisierung von Ontologien – sogar auf der semantischen Ausdrucksebene 

– bereichert Referenzmodelle um die wünschenswerte formalsprachliche Präzision und 

Analysierbarkeit. Insofern können Ontologien auch einen wichtigen Beitrag zur Weiterentwicklung 

von Referenzmodellen leisten, die zum etablierten Instrumentarium der Wirtschaftsinformatik 

und Betriebswirtschaftslehre gehören. 

2.2 Projektergebnisse 

Die Durchführung des Verbundprojekts KOWIEN hat im Wesentlichen acht konkrete Ergebnisse 

hervorgebracht. In diesen Ergebnissen manifestiert sich die Erreichung der o.a. Kernziele. 

Darüber hinaus tragen sie auch dazu bei, diejenigen Beiträge zu realisieren, die für das 

Rahmenkonzept „Forschung für die Produktion von morgen“ und sein Themenfeld 2.1 erwartet 

werden und zuvor kurz skizziert wurden. Im Einzelnen handelt es sich um folgende Projektergebnisse: 

� Anforderungskatalog: Für die zwei exemplarisch untersuchten Anwendungsszenarien 

wurden sowohl theoretisch fundierte als auch praxisrelevante Anforderungen an die Wissensakquisition, 

die Wissensstrukturierung und die Wissensrepräsentation erhoben 40) . 

Diese Anforderungen wurden allen weiteren Entwicklungsschritten zugrunde gelegt, um 

nach ihrer Maßgabe anforderungsgerechte Projektergebnisse zu erarbeiten. Darüber hinaus 

dienten sie dazu, um angesichts knapper zeitlicher und personeller Projektressourcen 

Priorisierungen vorzunehmen. Mit Hilfe dieser Priorisierungen wurden diejenigen Teilprozesse 

bei der Erfüllung wissensintensiver Engineering-Aufgaben ausgewählt, die sich 

aus der Sicht der Praxispartner des Verbundprojekts durch eine hohe Wissensintensität 

und einen hohen Unterstützungsbedarf mittels computerbasierter Wissensmanagementtechniken 

auszeichnen. 

40) Vgl. ALAN, Y.: Methoden zur Akquisition von Wissen über Kompetenzen. Projektbericht 2/2002, Institut für Produktion 

und Industrielles Informationsmanagement, Universität Essen, Essen 2002; DITTMANN, L.: Zwecke und Sprachen 

des Wissensmanagements zum Managen von Kompetenzen. Projektbericht 4/2002, Projekt KOWIEN, Institut für 

Produktion und Industrielles Informationsmanagement, Universität Essen, Essen 2002; ALAN, Y.; BÄUMGEN, C.: Anforderungen 

an den KOWIEN-Prototypen. Projektbericht 5/2002, Institut für Produktion und Industrielles Informationsmanagement, 

Universität Essen, Essen 2002; APKE, S.; BÄUMGEN, C.; BREMER, A.; DITTMANN, L.: Anforderungsspezifikation 

für die Entwicklung einer Kompetenz-Ontologie für die Deutsche Montan Technologie GmbH. Projektbericht 

2/2004, Institut für Produktion und Industrielles Informationsmanagement, Universität Duisburg-Essen 

(Campus Essen), Essen 2004. 

48


� Ontologien: Um mittels computerbasierter Wissensmanagementtechniken auf natürlichsprachlich 

formuliertes Wissen zugreifen zu können, wurden mehrere Ontologien entworfen 

und in unterschiedlichen formalen Repräsentationssprachen implementiert 41) . Die Ontologien 

fokussieren sich auf die Domäne des Managements von Wissen über Kompetenzen, 

Kompetenzträger und Kompetenzprofile. Sie bilden somit das formalsprachliche 

Fundament für Kompetenzmanagementsysteme. Im Interesse einer möglichst breiten und 

zugleich tiefen Domänenabdeckung wurde sowohl eine „generische“ KOWIEN-Ontologie 

42) konstruiert, die sich auf den gesamten Bereich des betrieblichen Kompetenzmanagements 

erstreckt, als auch eine unternehmensspezifische Kompetenzontologie 43) gestaltet, 

die in enger Zusammenarbeit zwischen dem Universitäts- und einem der Praxispartner, 

der Essener DMT GmbH, entstand. Neben den Ontologien als unmittelbar „fassbaren“ 

und dokumentierten Ergebnissen der Projektarbeiten führte die intensive Auseinandersetzung 

mit epistemischen und technischen Problemen des Ontologiedesigns zu mehreren 

wissenschaftlich bemerkenswerten Erkenntnissen, die in einer separaten Monografie 

zum Verbundprojekt KOWIEN ausführlicher thematisiert werden 44) . 

� Konzeption für ontologiebasierte Wissens-, insbesondere Kompetenzmanagementsysteme: 

Auf der Basis von Ontologien wurde eine Konzeption für computerbasierte Wissensmanagementsysteme 

entwickelt 45) , die das Management von Wissen über Kompetenzen, 

Kompetenzträger und Kompetenzprofile unterstützen. Hierdurch wurden neuartige 

Entwicklungen auf dem Gebiet des Knowledge-Level-Engineerings für ihre Anwendung 

in der betrieblichen Praxis zugänglich gemacht. Dieser Beitrag zur Schließung der eingangs 

konstatierten technischen Umsetzungslücke verschafft betrieblichen Anwendern 

von computerbasierten Wissensmanagementsystemen Zugang zu einer neuartigen Schlüsseltechnologie, 

die zurzeit vor allem aus der Perspektive des „Semantic Web“ außerordentliche 

Beachtung erlangt. Die Konzeption fokussiert sich zwar inhaltlich auf Kompetenzmanagementsysteme, 

um einen klaren, leicht nachvollziehbaren Anwendungsbezug 

mit unmittelbarem Nutzenpotenzial für die betriebliche Praxis herzustellen. Doch wurde 

die Konzeption so flexibel und erweiterungsoffen ausgestaltet, dass sie sich ohne gravierende 

Schwierigkeiten auf andere Anwendungsbereiche für computerbasierte Wissensmanagementsysteme 

übertragen lässt. Beispielsweise lässt sie sich generell von Softwareproduzenten 

nutzen, die sich auf die Entwicklung ontologiebasierter Wissensmana- 

41) Vgl. z.B. http://www.pim.uni-essen.de/mitarbeiter/aktivitaet.cfm?name=pimyial&aktivitaet=Service. Dort ist eine 

frei zugreifbare Kompetenzontologie dokumentiert, um sie einem kritischen Fachpublikum im Internet zur Diskussion 

zu stellen. Darüber hinaus wurde die Kompetenzontologie in zwei unterschiedlichen Repräsentationssprachen – 

einerseits RDF und andererseits F-Logic – konstruiert. Auf diese Weise lassen sich sprachbedingte Besonderheiten 

der Ontologiekonstruktion identifizieren und kritisch miteinander vergleichen. 

42) Vgl. ALAN, Y.: Konstruktion der KOWIEN-Ontologie. Projektbericht 2/2003, Institut für Produktion und Industrielles 

Informationsmanagement, Universität Duisburg-Essen (Campus Essen), Essen 2003; ALAN, Y.: Modifikation der 

KOWIEN-Ontologie. Projektbericht 5/2003, Institut für Produktion und Industrielles Informationsmanagement, Universität 

Duisburg-Essen (Campus Essen), Essen 2003. 

43) Vgl. APKE, B; DITTMANN, L.: Konstruktion der Kompetenzontologie für die DMT GmbH. Projektbericht 6/2004, Projekt 

KOWIEN, Institut für Produktion und Industrielles Informationsmanagement, Universität Duisburg-Essen 

(Campus Essen), Essen 2004 (in Bearbeitung). 

44) Vgl. ZELEWSKI, S.; ALAN, Y.; ALPARSLAN, A.; DITTMANN, L.; WEICHELT, T. (Hrsg.): Ontologiebasierte Kompetenzmanagementsysteme 

– Grundlagen, Konzepte, Anwendungen. Berlin 2005 (in Vorbereitung). 

45) Vgl. ALAN, Y.: Konstruktion der KOWIEN-Ontologie. Projektbericht 2/2003, Institut für Produktion und Industrielles 

Informationsmanagement, Universität Duisburg-Essen (Campus Essen), Essen 2003; ALAN, Y.: Modifikation der 

KOWIEN-Ontologie. Projektbericht 5/2003, Institut für Produktion und Industrielles Informationsmanagement, Universität 

Duisburg-Essen (Campus Essen), Essen 2003. ALAN, Y.: Ontologiebasierte Wissensräume. Projektbericht 

3/2003, Institut für Produktion und Industrielles Informationsmanagement, Universität Duisburg-Essen (Campus Essen), 

Essen 2003. 

49


gementsysteme konzentrieren. Darüber hinaus erschließt die Konzeption auch Consulting-Unternehmen, 

die auf dem Gebiet des Knowledge Engineerings tätig sind, neue Perspektiven 

für die Reorganisation ihrer Geschäftsprozesse. Dies gilt insbesondere im Hinblick 

auf die Systematisierung, Erschließung und Integritätswahrung 46) ihrer erfolgskritischen 

Ressource, d.h. ihres Beratungswissens. 

� Generisches Vorgehensmodell: Zur praktischen Anwendung des ontologiebasierten 

Kompetenzmanagements wurde ein generisches Vorgehensmodell entwickelt 47) . Es umfasst 

als Kernkomponente allgemein („generisch“) einsetzbare Methoden („Vorgehensweisen“) 

zur systematischen Konstruktion und Anwendung von kompetenzbezogenen 

Ontologien. Unternehmen unterschiedlicher Branchen 48) erhalten hierdurch konkrete Leitlinien 

für die Konzipierung, Realisierung und Nutzung computerbasierter Wissensmanagementsysteme, 

die sich zum Management von Kompetenzwissen eignen. Ein solches 

generisches Vorgehensmodell stand bislang noch nicht zur Verfügung. Stattdessen existierten 

im Bereich des Wissensmanagements nur relativ unverbindliche Vorgehensbeschreibungen, 

die sich aufgrund ihrer geringen Problemangemessenheit und ihrer mangelhaften 

Operationalisierung einer praktischen Umsetzung weit gehend entzogen. 

46) Die Systematisierung des Wissens wird vor allem durch die „taxonomische“ Struktur einer Ontologie geleistet. Diese 

Struktur wird mittels der ontologie-typischen „is a“-Relation für die Teilmengenbeziehung zwischen den Extensionen 

von jeweils zwei Begriffen (oder – hier synonym verwendet – Konzepten) ausgedrückt. Darüber hinaus kommen für 

die Wissenssystematisierung aber auch noch weitere Ausdrucksmittel in Betracht, die in der hier gebotenen Kürze 

nur angedeutet werden können: Beispielsweise lassen sich Synonymie- und Disjunktheits-Relationen benutzen, um 

systematische Beziehungen zwischen Begriffen (Konzepten) bzw. deren Extensionen festzulegen. Darüber hinaus 

bietet sich auch die mereologische Relation („is part of“) zur Wissenssystematisierung an. Allerdings kann sie zu 

Komplikationen besonderer Art führen, da sich die begründete Ansicht vertreten lässt, dass diese Relation streng genommen 

nicht auf der „Klassen-Ebene“ zwischen Begriffen (Konzepten) vermittelt – und somit nicht zu einer Ontologie 

(im hier vertretenen Ontologieverständnis) gehört, sondern auf der „Instanzen-Ebene“ Beziehungen zwischen 

einzelnen realweltlichen Objekten wiedergibt. Auf Subtilitäten dieser Art kann hier jedoch nicht näher eingegangen 

werden, zumal die Kontroverse über den ontologischen Status der mereologischen Relation andauert. Die Erschließung 

impliziten Wissens erfolgt insbesondere durch die speziellen „objektsprachlichen“, auf die jeweils sprachlich 

(re)konstruierte Domäne bezogenen Inferenzregeln einer Ontologie. Sie bilden neben den allgemein verfügbaren, 

„metasprachlichen“ Inferenzregeln der deduktiven Logik, über die „gewöhnliche“ wissensbasierte Systeme schon 

heute verfügen (können), das „inferenzielle Rückgrat“ von Ontologien. Die Integritätswahrung von Wissensbeständen 

erfolgt schließlich mit Hilfe der Integritätsregeln einer Ontologie. Sie dienen dazu, die Zulässigkeit von Wissensrepräsentationen 

sicherzustellen oder notfalls – wenn eine Unzulässigkeit regelgestützt erkannt wurde – zu einem „integren“ 

Wissenszustand zurückzukehren. Integritätsregeln sind vor allem aus Datenbankmanagementsystemen seit 

längerem bekannt. Sie können aber auch bei der Gestaltung anderer komplexer Systeme eine bedeutsame Rolle spielen, 

wie z.B. bei der bei der Gestaltung von Petri-Netzen (zur Modellierung komplexer Systeme). In Petri-Netzen 

können Integritätsregeln auf mehreren Ebenen verwendet werden, wie z.B. als Fakt-Transitionen, die eine enge inhaltliche 

Nähe zu prädikatenlogischen Wissensrepräsentationen aufweisen. 

Vgl. allgemein zu Sprachen für die Wissensrepräsentation DITTMANN, L.: Sprachen zur Repräsentation von Wissen – 

eine untersuchende Darstellung. Projektbericht 3/2002, Institut für Produktion und Industrielles Informationsmanagement, 

Universität Essen, Essen 2002. 

47) Vgl. APKE, S.; DITTMANN, L.: Generisches Vorgehensmodell KOWIEN Version 1.0. Projektbericht 4/2003, Institut 

für Produktion und Industrielles Informationsmanagement, Universität Duisburg-Essen (Campus Essen), Essen 2003; 

ALPARSLAN, A.: Evaluation des KOWIEN-Vorgehensmodells, Projektbericht 1/2004, Institut für Produktion und Industrielles 

Informationsmanagement, Universität Duisburg-Essen (Campus Essen), Essen 2004, S. 9 ff. Vgl. daneben 

auch die Grundlagen in APKE, S.; DITTMANN, L.: Analyse von Vorgehensmodellen aus dem Software, Knowledge 

und Ontologies Engineering. Projektbericht 1/2003, Institut für Produktion und Industrielles Informationsmanagement, 

Universität Duisburg-Essen (Campus Essen), Essen 2003. 

48) Der grundsätzliche Projektansatz, die Erkenntnisse aus den beiden untersuchten Anwendungsszenarien in einem generischen 

Vorgehensmodell für ontologiebasiertes Kompetenzmanagement zu generalisieren, bietet die Gewähr dafür, 

dass die angestrebten Ergebnisse nicht auf einige wenige spezielle Anwendungsfälle beschränkt bleiben. Stattdessen 

wird das generische Vorgehensmodell von vornherein so ausgelegt werden, dass es sich mittels situationsspezifischer 

Anpassungsmaßnahmen (Customizing; vgl. dazu das Ergebnis Nr. 4) für unterschiedliche Anwendungssituationen 

einsetzen lässt. Daher kann es nach entsprechender Adaption durch eine Vielzahl von Unternehmen genutzt 

werden, die selbst nicht an dem Verbundprojekt mitgewirkt haben. Dies schafft ein beträchtliches Potenzial für die 

breite Nachnutzung der Projektergebnisse. 

50


� Customizing-Instrumente: Es wurden Instrumente zur situationsspezifischen Anpassung 

des generischen Vorgehensmodells entwickelt 49) . Sie ermöglichen es, das Vorgehensmodell 

an jene konkrete Anwendungssituation anzupassen, die in einem Unternehmen hinsichtlich 

der Implementierung eines Wissensmanagementsystems tatsächlich vorliegen. 

Als situative Einflussgrößen kommen z.B. die unterschiedlichen Gestaltungszwecke in 

Betracht, die mit einem Wissensmanagementsystem verfolgt werden. Dabei kann es sich 

z.B. um die „schlichte“ Konservierung von erworbenem Erfahrungswissen, um die Beurteilung 

von Mitarbeiterkompetenzen im Rahmen von Personalentgeltung und - 

entwicklung oder auch um die kompetenzorientierte Konfiguration von Projektteams 

handeln. Ebenso gilt es, die Beschreibungssprachen und Repräsentationsformen zu beachten, 

die in den bereits vorhandenen Informations- und Kommunikationssystemen eines 

betrieblichen Anwenders eingesetzt werden. Durch die Berücksichtigung solcher situativer 

Einflussgrößen wird die Individualisierung von Wissensmanagementsystemen unterstützt. 

Wichtig sind diese Erkenntnisse vor allem für Anbieter und Nutzer von computerbasierten 

Wissensmanagementsystemen, um ein kundengerechtes Customizing (Tailoring) 

dieser Systeme vornehmen zu können. 

� Prototypisches Software-Tool: Einer der Projektpartner, ein ausgewiesenes IT- 

Unternehmen mit einschlägigem Entwicklungs-Know-how für Wissensmanagement- 

Software (die Comma Soft AG), hat einen Prototyp für ein ontologiebasiertes Kompetenzmanagementsystem 

entwickelt. Dieses Software-Tool leistet die informationstechnische 

Implementierung der o.a. Konzeption für das ontologiebasierte Management von 

Kompetenzwissen. Auf diese Weise wird die technisch-ökonomische Verwertbarkeit der 

Konzeption auch für Hersteller von computerbasierten Wissensmanagementsystemen 

aufgezeigt. Die anderen Praxispartner haben bereits damit begonnen, den entwickelten 

Prototyp in ihren Unternehmen intensiv zu erproben und hierbei hinsichtlich seiner Praxistauglichkeit 

aus der Perspektive betrieblicher Anwender zu evaluieren. 50) In Abhängigkeit 

von den abschließenden Evaluierungsergebnissen, die am Ende der Projektlaufzeit 

vorliegen sollen, wird der Software-Partner darüber entscheiden, ob er den Prototyp zu 

einer marktreifen, professionellen Wissensmanagement-Software weiterentwickelt. Diese 

Weiterentwicklung müsste insbesondere Instrumente zur situations- und kundengerechten 

Anpassung (vgl. Ergebnis Nr. 4) des ontologiebasierten Kompetenzmanagementsystems 

umfassen. Eine solche potenzielle Weiterentwicklung des Prototyps zur Marktreife liegt 

jedoch außerhalb des Verbundprojekts KOWIEN. Sie gehört in den Bereich der ökonomischen 

Nachnutzung der Projektergebnisse. 

49) Vgl. ALAN, Y.; ALPARSLAN, A.; DITTMANN, L.: Werkzeuge zur Sicherstellung der Adaptibilität des KOWIEN- 

Vorgehensmodells. Projektbericht 6/2003, Institut für Produktion und Industrielles Informationsmanagement, Universität 

Duisburg-Essen (Campus Essen), Essen 2003. 

50) Darüber hinaus ist die KOWIEN-Vorgehensweise in Form „interner Reviews“ mehrfach durch die beteiligten Partner 

evaluiert worden. Vgl. ALAN, Y.: Evaluation der KOWIEN-Zwischenergebnisse. Projektbericht 7/2002, Institut für 

Produktion und Industrielles Informationsmanagement, Universität Essen, Essen 2002. 

51


� E-Learning-Anwendung: Vom Universitätspartner wurde gemeinsam mit den Praxispartnern 

eine E-Learning-Anwendung konzipiert und realisiert 51) . Diese Anwendung 

wurde als selbstständig lauffähige Learnware implementiert, um möglichst vielseitig verwendbar 

zu sein. Als primäres Einsatzgebiet der Learnware schälte sich im Verlauf der 

Projektarbeiten 52) das prototypische Software-Tool heraus. In diesem Verwertungszusammenhang 

dient die E-Learning-Anwendung dazu, Benutzer des Software-Tools mit 

dessen Einsatz als ontologiebasiertes Kompetenzmanagementsystem vertraut zu machen. 

Zielgruppe sind vor allem erstmalige oder lediglich sporadische Benutzer des Software- 

Tools, die über keine ausgeprägten Vorkenntnisse im Bereich des ontologiebasierten 

Kompetenzmanagements verfügen. Daher wurde besonderer Wert darauf gelegt, in der E- 

Learning-Anwendung nicht nur die Funktionalitäten des Software-Tools anschaulich zu 

erläutern. Vielmehr wurden ebenso große Teile des generischen Vorgehensmodells (vgl. 

Ergebnis Nr. 3) einbezogen. Hierdurch sollen den Benutzern des Software-Tools in ihrer 

betrieblichen Alltagsarbeit konkrete Hilfestellungen dabei geboten werden, wie sie kompetenzbezogene 

Ontologien systematisch konstruieren und im Rahmen eines ontologiebasierten 

Kompetenzmanagementsystems zielorientiert anwenden können. In dieser Assistenzfunktion 

dient die E-Learning-Anwendung der beruflichen Weiterbildung. Darüber 

bietet sich die E-Learning-Anwendung ebenso an, um im Rahmen der universitären Aus- 

und Weiterbildung eingesetzt zu werden. Hierfür kommt in erster Linie der Online- 

Studiengang Wirtschaftsinformatik „VAWi“ (Virtuelle Ausbildung Wirtschaftsinformatik) 

in Betracht, der unter Federführung der Universität Duisburg-Essen, Campus Essen, 

gemeinsam mit den Universitäten Bamberg und Erlangen-Nürnberg durchgeführt wird 53) . 

51) Vgl. WEICHELT, T.: Entwicklung einer E-Learning-Anwendung zum kompetenzprofil- und ontologiebasierten Wissensmanagement 

– Modul 1: Grundlagen. Projektbericht 5/2004, Institut für Produktion und Industrielles Informationsmanagement, 

Universität Duisburg-Essen (Campus Essen), Essen 2004; WEICHELT, T.: Entwicklung einer E- 

Learning-Anwendung zum kompetenzprofil- und ontologiebasierten Wissensmanagement – Modul 2: Vorgehensmodell. 

Projektbericht 8/2004, Projekt KOWIEN, Institut für Produktion und Industrielles Informationsmanagement, 

Universität Duisburg-Essen (Campus Essen), Essen 2004 (in Bearbeitung); WEICHELT, T.: Entwicklung einer E- 

Learning-Anwendung zum kompetenzprofil- und ontologiebasierten Wissensmanagement – Modul 3: Prototyp. Projektbericht 

9/2004, Projekt KOWIEN, Institut für Produktion und Industrielles Informationsmanagement, Universität 

Duisburg-Essen (Campus Essen), Essen 2004 (in Bearbeitung). 

52) Dieses Einsatzgebiet der E-Learning-Anwendung war im Rahmenplan für das Verbundprojekt KOWIEN ursprünglich 

nicht vorgesehen. Ausführliche Diskussionen mit dem Softwarepartner und den übrigen Praxispartnern des Verbundprojekts 

ließen jedoch bei allen Projektpartnern die gemeinsame Einsicht reifen, dass die unmittelbare Unterstützung 

der Benutzung des Software-Tools für das Verbundprojekt KOWIEN einen höheren Nutzen verspricht, als es 

im ursprünglich angedachten Fall – der Learnware-Verwendung in einem Online-Studiengang – möglich gewesen 

wäre. Außerdem wurde diese ursprünglich geplante Verwendung der E-Learning-Anwendung keineswegs aufgegeben, 

sondern als Zukunftsoption weiterhin offen gehalten. Darauf wird in Kürze näher eingegangen. 

53) Der Online-Studiengang Wirtschaftsinformatik „VAWi“ bietet einen international anerkannten Master-Abschluss an. 

Dieser Studiengang wurde unter Federführung von Herrn Professor Dr. ADELSBERGER mit internetbasierten und multimedialen 

E-Learning-Techniken realisiert, die von den drei o.a. Universitäten im Rahmen des BMBF-Programms 

„Neue Medien in der Bildung“ entwickelt wurden. Seitens des Verbundprojekts KOWIEN ist beabsichtigt, die bereits 

erstellte E-Learning-Anwendung für den Online-Studiengang Wirtschaftsinformatik als ein Modul über „Methoden 

zur Akquisition und ontologiebasierten Strukturierung betriebswirtschaftlichen Domänenwissens“ zu offerieren. Auf 

diese Weise werden Projektergebnisse einem breiten Forum von Studierenden der Wirtschaftsinformatik an drei 

Hochschulen zugänglich gemacht. Darüber hinaus wird der Online-Studiengang zurzeit als kommerziell verwertbarer 

Weiterbildungsstudiengang in die Weiterbildungsgesellschaft der Universität Duisburg-Essen, die „Ruhr Campus 

Academy (RCA) gGmbH“ eingebracht. Dieser Weiterbildungsstudiengang wird allen Interessierten mit einem ersten 

berufsqualifizierenden Abschluss offen stehen und sich auch an Weiterbildungssuchende aus Unternehmen wenden. 

Dadurch bestünde die Möglichkeit, Resultate des Verbundprojekts KOWIEN – über die Praxispartner des Verbundprojekts 

hinaus – zahlreichen weiteren Unternehmen für die Qualifizierung ihrer Mitarbeiter im Bereich des Wissensmanagements 

zur Verfügung zu stellen. Allerdings setzt diese Nachnutzung der E-Learning-Anwendung über das 

Ende der Projektlaufzeit voraus, dass zusätzliche Finanzquellen erschlossen werden können. Denn die E-Learning- 

Anwendung müsste im Hinblick auf Teilnehmer des VAWi-Online-Studiengangs noch inhaltlich fortentwickelt werden. 

Sie ist bislang speziell auf ihre Zielgruppe im Verbundprojekt KOWIEN – die potenziellen Benutzer des prototypischen 

Software-Tools – zugeschnitten. 

52


Über eine Integration der E-Learning-Anwendung in diesen Online-Studiengang wird aber 

erst in der Nachnutzungsphase des Verbundprojekts KOWIEN entschieden werden 

können, da sich der Studiengang zurzeit in einer Phase der Umstrukturierung befindet. 

� Fallstudie: Für die Erprobung und Evaluierung der Praxistauglichkeit der Wissensmanagementtechniken, 

die im Verbundprojekt KOWIEN (fort)entwickelt und eingesetzt wurden, 

erstellte einer der Praxispartner – ein renommiertes, international ausgewiesenes Beratungsunternehmen, 

die Roland Berger Strategy Consultants GmbH, – gemeinsam mit 

dem Universitätspartner eine Fallstudie 54) . Diese Fallstudie reflektiert einerseits die konkreten 

betrieblichen Anwendungssituationen, die bei den Praxispartnern des Verbundprojekts 

KOWIEN für das Wissensmanagement im betrieblichen Alltag vorherrschen. Andererseits 

wurde sie in der Art einer Harvard Business School (HBS) Case Study verfasst, 

um dem internationalen Anspruch an professionell gestaltete Fallstudien gerecht zu werden. 

Inhaltlich wurde insbesondere der potenzielle Konflikt zwischen Personalisierungsund 

Kodifizierungsstrategie des Wissensmanagements aufgegriffen, der zu Beginn dieses 

Beitrags zwecks inhaltlicher Positionierung des Projektgegenstands kurz skizziert wurde. 

Da sich dieser Konflikt bei allen Praxispartnern des Verbundprojekts als „virulent“ herausstellte 

und auch unter Fachexperten als allgemeines Problem des betrieblichen Wissensmanagements 

erkannt wurde, eignet sich die KOWIEN-Fallstudie ausgezeichnet als 

Schulungsmaterial sowohl für die Projektpartner als auch einen breiten Kreis weiterer Unternehmen 

(in der Nachnutzungsphase des Verbundprojekts). Um eine möglichst große 

„Breitenwirkung“ zu erzielen, wird die KOWIEN-Fallstudie vom Universitätspartner seit 

dem Sommer 2004 im Bereich der regulären universitären Ausbildung eingesetzt. In jedem 

Sommersemester wird an der Universität Duisburg-Essen, Campus Essen, ein spezielles 

Fallstudienseminar ausgerichtet 55) . Es richtet sich insbesondere an Studierende der 

Betriebswirtschaftslehre und der Wirtschaftsinformatik während ihres Hauptstudiums, 

steht aber auch anderen Studiengängen offen, wie z.B. dem Systems Engineering (einer 

Spezialität des Essener Campus), der Volkswirtschaftslehre und den Lehramtsstudiengängen. 

Mit dem Fallstudieneinsatz werden nicht nur Einsichten und Ergebnisse des Verbundprojekts 

KOWIEN in der universitären Ausbildung verbreitet, sondern es erfolgt 

auch ein wichtiger Beitrag zur stärkeren Praxisorientierung universitärer Ausbildung. Bereits 

im ersten Durchlauf des o.a. Fallstudienseminars haben sich die Bearbeiter der Fallstudie 

– es handelte sich ausschließlich um Studierende der Wirtschaftsinformatik – in der 

abschließenden Seminarevaluation sehr positiv über die Praxisnähe und Problemfülle der 

Fallstudie aus dem Verbundprojekt KOWIEN geäußert. 

Die vorgenannten Ergebnisse des Verbundprojekts KOWIEN stellen in ihrer Gesamtheit sicher, 

dass die ökonomischen und technologischen Kernziele des Projekts im ursprünglich angestrebten 

Ausmaß erreicht wurden. 

Im Vordergrund der Zielerreichung steht der Erwerb konzeptioneller Kompetenz für ein ontologie- 

und vorgehensmodellbasiertes Wissensmanagement im Engineering-Bereich, und zwar 

für die Entwicklung von sowohl wissensintensiven Sachgütern (Produkt-Engineering) als 

auch wissensintensiven Dienstleistungen (Service-Engineering). Dieser Kompetenzerwerb 

kommt allen Projektpartnern unmittelbar zugute, um ihre Wettbewerbsfähigkeit – vor allem 

im Bereich des Projektgeschäfts – zu steigern. Die Praxispartner können ihren Kompetenzgewinn 

im Bereich des betrieblichen Wissensmanagements nutzen, um beispielsweise ihre stra- 

54) Vgl. ENGELMANN, K.; ALAN, Y.: KOWIEN Fallstudie – Gebert GmbH. Projektbericht 7/2003, Institut für Produktion 

und Industrielles Informationsmanagement, Universität Duisburg-Essen (Campus Essen), Essen 2003. 

55) Vgl. im Internet die Website zum Fallstudienseminar unter der URL „http://www.pim.uni-essen.de/vorlesungen/ vorlesung.cfm?id=213“ 

und dort speziell die KOWIEN-Fallstudie unter dem Titel „Gebert GmbH“. 

53


tegische Unternehmensplanung durch das Management von Kompetenzwissen im Hinblick 

auf ihre Kernkompetenzen zu schärfen und diese Kernkompetenzen wertschöpfend in die 

Entwicklung innovativer Produkte umzusetzen. Auf diese Weise wird ein wichtiger Beitrag 

zur Verzahnung von Forschungs- und Entwicklungs- sowie Produktionsstrategien geleistet. 

Zugleich zeigt das prototypische Software-Tool die „Machbarkeit“ ontologiebasierter Kompetenzmanagementsysteme 

auf, mit deren Hilfe sich Wissen über die eigenen Kompetenzen, 

Kompetenzträger und Kompetenzprofile systematisch nutzen lässt, um die Qualität von Produktentwicklungsprozessen 

zu erhöhen und zugleich die hierfür erforderlichen Entwicklungszeiten 

zu verringern. 

Darüber hinaus wird das prototypische Software-Tool den Softwarepartner des Verbundprojekts 

KOWIEN in die Lage versetzen, ein marktreifes, professionelles Softwareprodukt für 

computerbasierte Wissensmanagementsysteme zu entwickeln, die sich auf das ontologiebasierte 

Management von Kompetenzwissen fokussieren. Diese Weiterentwicklung kann auf die 

Erkenntnisse zurückgreifen, die innerhalb des Verbundprojekts über Instrumente zur situations- 

und kundengerechten Anpassung von computerbasierten Wissensmanagementsystemen 

gesammelt wurden. Angesichts der Kompetenz des Softwarepartners, internetbasierte Softwareanwendungen 

zu entwickeln und bei Softwarelösungen für unternehmensspezifische 

Problemstellungen zu implementieren, ist davon auszugehen, dass nach einer entsprechenden 

Weiterentwicklung des Prototyps bis zur Marktreife ein konkurrenzfähiges Softwareprodukt 

für computerbasierte Wissensmanagementsysteme vorliegen wird. Die Weiterentwicklung des 

Prototyps zur Marktreife im Anschluss an die Projektdurchführung würde eine bedeutsame 

ökonomische Nachnutzung der Projektergebnisse darstellen und die Standortqualität Deutschlands 

für innovative Softwareentwicklungen stärken. Zugleich könnte der Softwarepartner seine 

Marktposition im Wettbewerb mit anderen nationalen, insbesondere aber auch internationalen 

Konkurrenten durch ein innovatives Produkt (Verwendung von Ontologien, XML usw.) 

ausbauen. Die Defizite und Verbesserungspotenziale derzeitiger Ansätze auf dem Gebiet des 

Wissensmanagements, der hohe Stellenwert des Themas in der Wirtschaft, die führende 

Marktstellung des Softwarepartners im Bereich internetbasierter Wissensmanagement- 

Software sowie konkrete Kundenanfragen weisen auf ein hohes wirtschaftliches Erfolgspotenzial 

für ein solches Produkt hin. 

Für den Praxispartner aus dem Service-Engineering-Szenario bestehen begründete Aussichten, 

ein ontologiebasiertes Kompetenzmanagementsystem zur Verbesserung seiner strategischen 

Wettbewerbsposition im internationalen Wettbewerb mit anderen Beratungsunternehmen 

nutzen zu können. Im Vordergrund der Verwertungsaussichten steht die Möglichkeit, 

Best-practice-Wissen aus bereits durchgeführten eigenen Beratungsprojekten für die Akquisition 

und die Bearbeitung neuer Projekte allen Mitgliedern des Unternehmens zugänglich zu 

machen. Die rasche Identifizierung und Anwendung von unternehmensintern vorhandenem, 

aber nicht direkt zugänglichem Fach- und Erfahrungswissen gilt in der Consulting-Branche 

als einer derjenigen strategischen Erfolgsfaktoren, der schon heute den Wettbewerb nachhaltig 

prägt. 

Die Verwertungsaussichten der drei Praxispartner aus dem Produkt-Engineering-Szenario 

erstrecken sich vor allem darauf, unternehmensintern vorhandene Kompetenzen möglichst 

rasch und möglichst umfassend nutzen zu können. Gemeinsames Ziel dieser kleinen und mittelgroßen 

Unternehmen (KMU) ist es, sich im Wettbewerb gegenüber ihren Konkurrenten vor 

allem durch kompetenzbasierte Qualitäts- und Zeitvorsprünge durchzusetzen. Alle drei Unternehmen 

des Produkt-Engineering-Szenarios sind im Bereich des Maschinen- und Anlagenbaus 

tätig. Sie verfügen über hohe ingenieurtechnische Kompetenzen in vielfältigen Engineering-Bereichen. 

Sowohl für ihr Projektgeschäft als auch für die kundenfokussierte Auftragsproduktion 

ist es typisch, dass die meisten Projekte bzw. Produktserien hoch spezialisiertes 

54


Engineering-Wissen voraussetzen und oftmals den Charakter von auftragsspezifischen Einzelfertigungen 

aufweisen. Daher stellt sich bei neu eintreffenden Projektausschreibungen oder 

Kundenanfragen häufig das Problem herauszufinden, ob die zur Projektbearbeitung bzw. Produktherstellung 

erforderlichen Kompetenzen aus früher erfolgreich durchgeführten Projekten 

bzw. Produktionen – zumindest teilweise – zur Verfügung stehen. Darüber hinaus ist es des 

Öfteren nicht unmittelbar bekannt, bei welchen Mitarbeitern diese Kompetenzen abgerufen 

werden können. Besonders ausgeprägt ist die letztgenannte Schwierigkeit bei einem der Praxispartner 

mit heterogenen Geschäftsfeldern, so dass sich zuweilen bei der Zusammenstellung 

eines Projektteams Wissenslücken hinsichtlich der Kompetenzverteilung im Unternehmen 

hinderlich auswirken. Die drei Partnerunternehmen aus dem Produkt-Engineering-Szenario 

werden die Erkenntnisse aus dem Projekt KOWIEN praktisch verwerten, um ihr alltägliches 

Problem, einerseits verfügbare und andererseits zwecks Projekt- oder Auftragsakquisition und 

-durchführung erforderliche Engineering-Kompetenzen aufeinander abzustimmen, besser als 

in der Vergangenheit zu lösen. Hierdurch soll ihre Position im Wettbewerb um wissensintensive 

Engineering-Projekte nachhaltig gestärkt werden. 

Allerdings ist von einem „ehrlichen“ Bericht über die realisierten Ergebnisse eines Forschungs- 

und Entwicklungsprojekts im Allgemeinen nicht zu erwarten, dass alle intendierten 

Projektergebnisse tatsächlich realisiert wurden. Dies liegt in der „natürlichen“ Ergebnisunsicherheit 

aller F&E-Projekte begründet. Insbesondere zwei Aspekte des Verbundprojekts 

KOWIEN konnten nicht so verwirklicht werden, wie sie ursprünglich geplant waren. 

Erstens gelang es nicht, substanzielle Erkenntnisse hinsichtlich des Nebenziels zu gewinnen, 

wie das wechselseitige Verhältnis zwischen Referenzmodellen einerseits und den Ontologien 

andererseits beschaffen ist. Ursprünglich sollte aufgezeigt werden, wie sich Wissen, das in 

Referenzmodellen repräsentiert ist, zur Konstruktion von Ontologien verwenden lässt und wie 

Ontologien in Referenzmodelle zurückübersetzt werden können. Im Verlauf der konkreten 

Projektarbeit zeigte sich jedoch, dass die einschlägigen Referenzmodelle, die in der Fachliteratur 

zu den beiden KOWIEN-Szenarien angeboten werden, zurzeit (noch) nicht das Ausmaß 

an inhaltlicher Detailliertheit und Präzision erreichen, um bei der Entwicklung eines ontologiebasierten 

Kompetenzmanagementsystems für die betriebliche Praxis konkret eingesetzt 

werden zu können 56) . Diese „frustrierende“ Einsicht in den aktuellen Entwicklungszustand 

von Referenzmodellen stellte sich sowohl für das Produkt- als auch für das Service- 

Engineering-Szenario heraus. Daher mussten im Verbundprojekt KOWIEN die Ontologien 

für Aufgaben des Kompetenzmanagements in den beiden vorgenannten Szenarien von Grund 

auf neu entwickelt werden, ohne auf entsprechende Referenzmodelle zurückgreifen zu können. 

Aus diesem Grund erübrigte sich die Frage, wie sich Wissen, das in Referenzmodellen 

repräsentiert ist, zur Konstruktion von Ontologien verwenden lässt. Die komplementäre Frage, 

wie Ontologien in Referenzmodelle zurückübersetzt werden können, wäre zwar durchaus 

weiterhin von grundsätzlichem Interesse gewesen. Aber der aktuelle Entwicklungszustand 

von Referenzmodellen ließ es wegen ihres Detaillierungs- und Präzisionsmangels aussichtslos 

erscheinen, die Informationsfülle von Ontologien in solche Referenzmodelle zurückübertragen 

zu können – zumindest im Rahmen der knappen zeitlichen und personellen Ressourcen, 

die im Verbundprojekt KOWIEN zur Verfügung standen 57) . Daher wurden diese Ressourcen 

56) Vgl. ALPARSLAN, A.: Wissensanalyse und Wissensstrukturierung. Projektbericht 6/2002, Institut für Produktion und 

Industrielles Informationsmanagement, Universität Essen, Essen 2002, S. 17 ff. 

57) Die „Rückübersetzung“ von Ontologien in Referenzmodelle erübrigt sich allerdings, wenn die ursprünglich (im Projektrahmenplan) 

verfolgte Trennung von Referenzmodellen und Ontologien aufgehoben wird. Zwar lassen sich die 

beiden Konstrukte grob dadurch unterscheiden, dass Referenzmodelle in der Regel nur semi-formalsprachlich (z.B. 

mit Hilfe ausführlicher natürlichsprachlicher Kommentare zu einem formalsprachlichen Referenzmodell-„Kern“) formuliert 

sind sowie keine Inferenz- und Integritätsregeln umfassen (die nur auf vollständig formalisierte sprachliche 

55


in andere, Erfolg versprechendere Entwicklungsarbeiten – wie z.B. die E-Learning-Anwendung 

als Assistenzkomponente des Software-Tools – umgelenkt. 

Zweitens wurde in technologischer Hinsicht eine spezielle Facette des Knowledge-Level- 

Engineerings nicht so weit in die praktische betriebliche Anwendung mit Hilfe des Software- 

Tools umgesetzt, wie dies auf der Basis von Ontologien grundsätzlich möglich gewesen wäre. 

Diese spezielle Facette betrifft die Fähigkeit, implizites Wissen, das in explizit dokumentiertem 

Wissen über Kompetenzen, Kompetenzträger und Kompetenzprofile bereits enthalten ist, 

mittels Inferenzregeln computerbasiert zu erschließen und so in explizites Wissen zu überführen. 

Ontologien bereichern diese Möglichkeit der Wissensexplizierung durch eine besondere 

Art von Inferenzregeln („objektsprachliche“ Inferenzregeln), die weit über die allgemein verfügbaren 

(„metasprachlichen“) Inferenzregeln der deduktiven Logik hinausgehen. Im Verbundprojekt 

KOWIEN wurde eine Vielzahl solcher „objektsprachlichen“ Inferenzregeln (neben 

einer weiteren Regelart, den Integritätsregeln) als Bestandteile von Ontologien für das betriebliche 

Kompetenzmanagement entwickelt und ausführlich analysiert 58) . Dabei stellten sich 

einerseits konzeptionelle Schwierigkeiten heraus, Inferenzregeln innerhalb einer Ontologie so 

zu formulieren, dass sich das mit ihrer Hilfe erschlossene, neue explizite Kompetenzwissen 

mittels (zweistelliger) prädikatenlogischer Formeln als Faktenwissen ausdrücken lässt (Problem 

der dynamischen Faktengenerierung) 59) . Andererseits wurden vom Softwarepartner erhebliche 

Bedenken geäußert, ob sich die Integration einer prädikatenlogisch basierten „Inferenzmaschine“ 

in das Software-Tool, die für die Anwendung der Inferenzregeln zum Zweck 

der Wissensexplizierung erforderlich gewesen wäre, aus den Blickwinkeln der Praktikabilität 

und der kommerziellen Verwertbarkeit rechtfertigen ließe. Aufgrund dieser Bedenken wurde 

vom Softwarepartner anstelle der Implementierung von Inferenzregeln und einer zugehörigen 

„Inferenzmaschine“ ein anderer softwaretechnischer Weg eingeschlagen, der sich so genannter 

„saved queries“ (Diktion der infonea ® -Wissensmanagement-Architektur) bedient. Diese 

Artefakte angewendet werden können). Ontologien zeichnen sich dagegen – zumindest in ihrer „strengen“ Version, 

die innerhalb des KOWIEN-Projekts vertreten wird, – durch eine vollständige formalsprachliche Konstruktion einschließlich 

Inferenz- und Integritätsregeln aus. Wenn von dieser – definitorischen und somit letztlich willkürlichen – 

Unterscheidung zwischen Referenzmodellen und Ontologien abgesehen wird, lässt sich durchaus die Ansicht vertreten, 

dass Ontologien bereits eine spezielle Variante von Referenzmodellen darstellen. Um die „normative Qualität“ 

von Referenzmodellen zu erlangen, brauchen Ontologien „nur“ noch mit dem Anspruch verknüpft zu werden, Leitlinien 

für eine „gute“ oder „zweckmäßige“ Modellierung jeweils vorgegebener Realitätsausschnitte darzustellen. 

Der Verfasser folgt dieser – mit plausiblen Argumenten vertretbaren – Ansicht jedoch aus zwei Gründen nicht. Erstens 

sieht er keinen überzeugenden Grund, auf die o.a. definitorische Differenzierung zwischen Referenzmodellen 

und Ontologien zu verzichten. Zweitens – und dies erscheint dem Verfasser wichtiger – besteht eine subtilere Unterscheidung 

zwischen Referenzmodellen und Ontologien, die bislang in der einschlägigen Fachliteratur noch nicht in 

der gebotenen Deutlichkeit herausgearbeitet wurde: Ontologien stellen nur die sprachlichen Ausdrucksmittel zur Verfügung, 

mittels derer sich wahrgenommene oder vorgestellte Realitätsausschnitte modellieren lassen. Daher können 

Ontologien für die Modellierung einer Vielzahl „möglicher Welten“ (Realitätsausschnitte) herangezogen werden, solange 

sie sich jeweils mit den sprachlichen Mitteln einer Ontologie ausdrücken lassen. Referenzmodelle sollen dagegen 

aufgrund ihres normativen Anspruchs nicht nur die sprachliche Struktur möglicher Realitätsausschnitte erfassen, 

sondern die materielle Struktur von Realitätsausschnitten so wiedergeben, wie sie im Sinne normativer Vorstellungen 

intendiert wird. Beispielsweise sollen Referenzmodelle nicht alle sprachlich ausdrückbaren Geschäftsprozesse in einem 

Realitätsausschnitt umfassen, sondern nur jene Geschäftsprozesse auszeichnen, die im Sinne normativer Vorstellungen 

als „Referenz“ zur Nachahmung oder zum Benchmarking vorzugeben sind. Aus dieser Perspektive lassen sich 

Ontologien nicht „trivial“ in Referenzmodelle (zurück) übersetzen, weil es einer normativen Komponente bedarf, die 

lediglich mögliche und sprachlich ausdrückbare Konstrukte auf intendierte Konstrukte einengt. Diese zusätzliche 

normative Komponente für die „Rückübersetzung“ von Ontologien in Referenzmodelle konnte im Projekt KOWIEN 

nicht mehr erarbeitet werden. 

58) Vgl. HÜGENS, T.: Inferenzregeln des „plausiblen Schließens“ zur Explizierung von implizitem Wissen über Kompetenzen. 

Projektbericht 3/2004, Institut für Produktion und Industrielles Informationsmanagement, Universität Duisburg-Essen 

(Campus Essen), Essen 2004, S. 21 ff. 

59) Vgl. ALAN, Y.: Erweiterung von Ontologien um dynamische Aspekte. Projektbericht 4/2004, Institut für Produktion 

und Industrielles Informationsmanagement, Universität Duisburg-Essen (Campus Essen), Essen 2004. 

56


alternative Implementierung mithilfe eines Inferenzregel- und Inferenzmaschinen-Substituts 

wird im Beitrag des Softwarepartners ausführlicher dargestellt. 

Den beiden vorgenannten Aspekten, die im Rahmen des Verbundprojekts KOWIEN nicht so 

wie ursprünglich geplant realisiert werden konnten, stehen aber auch „überraschende“ Ergebnisse 

gegenüber, die im ursprünglichen Projektrahmenplan nicht vorgesehen waren. Dazu gehörte 

bereits die Neuausrichtung der E-Learning-Anwendung, primär als Assistenzkomponente 

des prototypischen Software-Tools zu dienen. Darauf wurde schon weiter oben eingegangen. 

Darüber hinaus kristallisierte sich für das prototypische Software-Tool ein völlig neuartiger 

Anwendungsbereich heraus, an den zunächst in keiner Weise gedacht worden war. In Gesprächen 

mit der Zentralstelle für Forschungs- und Entwicklungstransfer (FET) der Universität 

Duisburg-Essen, Campus Essen, zeigte sich ein großes Interesse der Universität, das Software-Tool 

zur Darstellung der Forschungs- und Entwicklungskompetenzen von Hochschuldozenten 

im Internet zu nutzen. Auf diese Weise könnte das bisher verwendete „elektronische 

Forschungshandbuch“ der Essener Universität durch eine wesentlich flexiblere und benutzerfreundlichere 

Anwendung des KOWIEN-Software-Tools abgelöst werden. Entsprechende 

Sondierungsgespräche zwischen dem Softwarepartner des Verbundprojekts und dem Leiter 

der Essener Zentralstelle für Forschungs- und Entwicklungstransfer haben bereits stattgefunden. 

In Kürze soll eine erste Demonstrationsversion für diese neuartige Anwendung des KO- 

WIEN-Software-Tools, die mit Kompetenzinformationen von Hochschuldozenten des Essener 

Fachbereichs Wirtschaftswissenschaften gefüllt wurde, im Internet zur Erprobung und kritischen 

Evaluierung zur Verfügung stehen. 

In der Phase der Wissensakquisition für die Entwicklung des KOWIEN-Prototyps stellte sich 

die Frage nach geeigneten Quellen für einschlägiges Praxiswissen über verfügbare und erforderliche 

Kompetenzen. Hierbei zeigte sich, dass die beteiligten Praxispartner oftmals eine 

Reihe von kompetenzorientierten Wissensquellen in ihren eigenen Unternehmen besitzen, 

diese Quellen jedoch in herkömmlichen Kompetenzmanagementsystemen nicht genutzt werden, 

um Wissen über Kompetenzen zu akquirieren. Insbesondere Unternehmen aus dem Maschinen- 

und Anlagenbau müssen heutzutage ein effektives Qualitätsmanagement aufbauen, 

um beispielsweise für Automobilhersteller Aufträge wahrnehmen zu können. Weite Verbreitung 

findet hier die Fehlermöglichkeits- und Einflussanalyse (FMEA). Sie stellt eine Standardtechnik 

des Qualitätsmanagements dar. In FMEA-Anwendungen wird geeigneten (qualifizierten) 

Mitarbeitern die Verantwortlichkeit für Maßnahmen zur Fehlervermeidung übertragen. 

Dieses Wissen über technische Qualifikationen von Mitarbeitern lässt sich nutzen, um 

kompetenzbezogenes Wissen für die Konstruktion von Ontologien und Wissensbasen systematisch 

zu erwerben. Zu diesem Zweck wurde vom Universitätspartner ein prototypisches 

Softwaresystem (OntoFMEA) 60) konzipiert und realisiert, das Wissen aus FMEA-Formblättern 

in eine Ontologie und Wissensbasis transferiert. Dieses „ontologisch“ aufbereitete Wissen 

lässt sich anschließend nutzen, um neue FMEA-Anwendungen zu erstellen. Unter anderem 

kann beispielsweise nach möglichen Fehlern bei bestimmten Bauteilen gesucht werden. 

In einem nächsten Schritt ist es möglich, eine solche FMEA-Ontologie mit bestehenden 

60) Vgl. DITTMANN, L.; RADEMACHER, T.; ZELEWSKI, S.: Performing FMEA Using Ontologies. In: DE KLEER, J.; FORBUS, 

K. D.: 18th International Workshop on Qualitative Reasoning, Proceedings, 02.-04.08.2004 in Evanston, USA, 

Evanston 2004, S. 209-216; DITTMANN, L.; RADEMACHER, T.; ZELEWSKI, S.: Combining Knowledge Management and 

Quality Management Systems. Eingereicht zu: 48th EOQ (European Organization for Quality) Congress, 07.- 

09.09.2004 in Moskau; DITTMANN, L.; ZELEWSKI, S.: Integrating Computer-based Systems of Knowledge and Quality 

Engineering to Manage Skills. Eingereicht zu: 8th International Symposium on Measurement and Quality Control in 

Production (ISMQC) – IMEKO TC14 Measurement of Geometrical Quantities, 12.-15.10.2004 in Erlangen (erscheint 

als VDI-Tagungsband 1860: Measurement and Quality Control in Production, Erlangen 2004). 

57


Kompetenzontologien zu umfassenderen, auch für das betriebliche Qualitätsmanagement geeigneten 

Kompetenzontologien zusammenzuführen. Dieser neuartige Ansatz einschließlich 

seiner prototypischen Implementierung bietet die Chance, die Forschungs- und Praxisfelder 

des Wissens- und Qualitätsmanagements zukünftig enger miteinander zu verknüpfen. So kann 

z.B. die Fehlerdiagnose in komplexen Systemen mit der Ermittlung fachlich kompetenter Ansprechpartner 

verbunden werden. 

Des Weiteren bot sich eine unerwartete Gelegenheit, die Verwertbarkeit von Erkenntnissen 

des Verbundprojekts KOWIEN weit außerhalb der beiden ursprünglich anvisierten Anwendungsszenarien 

zu untersuchen. Durch zusätzliche Fördermittel aus dem InWert-Programm 

des BMBF konnte in Kooperation mit dem INSTI-Netzwerk eine eigenständige Verwertungsstudie 

61) durchgeführt werden. Sie befasste sich mit den Marktperspektiven, Projektergebnisse 

hinsichtlich ontologiebasierter Kompetenzmanagementsysteme auf die Erfüllung von Wissensmanagementaufgaben 

im Gesundheitswesen zu übertragen. In diesem Zusammenhang 

schuldet das Verbundprojekt KOWIEN Herrn Dipl.-Ing. Bernd Risch vom Kölner Institut der 

deutschen Wirtschaft e.V. besonderen Dank, der mit Rat und Tat zur Seite stand, um diese 

Studie über den möglichen Transfer von Projektergebnissen in einen weiteren Bereich des 

Service-Managements zu ermöglichen. 

Schließlich wurde gemeinsam mit der die Projektgruppe Wissensmanagement der Wirtschaftsjunioren 

Essen e.V. das „Praxisforum Wissensmanagement“ als Industriearbeitskreis 

gegründet, der sich eines regen Zuspruches von vornehmlich KMU aus der Region des Ruhrgebiets 

erfreut. Darauf wird im nachstehenden Kapitel aus der Perspektive der Projekt- 

Stakeholder zurückgekommen. 

61) Vgl. ZUG, S.; KLUMPP, M.; KROL, B.: Wissensmanagement im Gesundheitswesen, Arbeitsbericht Nr. 16, Institut für 

Produktion und Industrielles Informationsmanagement, Universität Duisburg-Essen (Campus Essen), Essen 2003. 

58


3 Beteiligte Projektpartner 


Das Verbundprojekt KOWIEN umfasst ein Projektkonsortium, das die Projektarbeiten im engeren 

Sinn leistet und durch Finanzmittel des BMBF großzügig gefördert wurde. Hinzu 

kommen weitere Stakeholder, die in die Verbreitung der Erkenntnisse und Ergebnisse der 

Projektarbeiten einbezogen werden, jedoch nicht an den BMBF-Fördermitteln partizipieren. 

Das Projektkonsortium setzt sich aus fünf Praxispartnern und einem Universitätspartner zusammen. 

Die fünf Praxispartner stehen im Zentrum des Projekts. Die meisten von ihnen gehören 

zum Sektor der kleinen und mittelgroßen Unternehmen (KMU). Drei lassen sich der 

Branche des Maschinen- und Anlagenbaus im weitesten Sinn – bis hin zum internationalen 

Technologie-Dienstleister im Engineering komplexer Industrieprojekte – zuordnen und tragen 

gemeinsam das Produkt-Engineering-Szenario des Verbundprojekts KOWIEN: 

1. die Deutsche Montan Technologie (DMT) GmbH in Essen, 

2. die Karl Schumacher Maschinenbau (KSM) GmbH in Köln und 

3. die TEMA GmbH – Industrial Visiomation in Schwelm. 

Hinzu kommt als vierter Praxispartner ein Unternehmen aus der Consulting-Branche, von 

dem das Service-Engineering-Szenario des Verbundprojekts abgedeckt wird: 

4. die Roland Berger Strategy Consultants GmbH in München & Düsseldorf. 

Schließlich nimmt der fünfte Praxispartner eine Sonderstellung ein, weil er in keines der vorgenannten 

Szenarien eingebunden war, sondern als Softwarepartner für die prototypische 

Implementierung der konzeptionellen Projektarbeiten zur Verfügung stand: 

5. die Comma Soft AG – The Knowledge People in Bonn. 

Der Universitätspartner, das Institut für Produktion und Industrielles Informationsmanagement 

(PIM) der Universität Duisburg-Essen, Campus Essen, trat als federführender Antragsteller 

auf. Er hat während der Projektdurchführung die generelle Koordinierung der Projektarbeiten 

übernommen sowie – gemeinsam mit dem Softwarepartner – den überwiegenden 

Teil der konzeptionellen Forschungs- und Entwicklungsleistungen erbracht. 

Zu den weiteren Stakeholdern, die sich außerhalb des voranstehenden Projektkonsortiums für 

die Verbreitung der Projekterkenntnisse und Projektergebnisse in der betrieblichen Praxis, 

insbesondere bei KMU einsetzen, gehört vor allem die Projektgruppe Wissensmanagement 

der Wirtschaftsjunioren Essen e.V. (der Industrie- und Handelskammer für Essen, Mülheim 

an der Ruhr und Oberhausen zu Essen). Es handelt sich um einen Kreis von Selbstständigen 

und (angehenden) Führungskräften, die sich ehrenamtlich betätigen, um innovative Unternehmen 

im Einzugsbereich der Industrie- und Handelskammer Essen, Mülheim an der Ruhr 

und Oberhausen zu unterstützen. Gemeinsam mit den Wirtschaftsjunioren Essen e.V. hat der 

Universitätspartner – das Institut PIM – im Mai 2003 den Industriearbeitskreis 62) „Praxisfo- 

62) Zunächst wurde versucht, sich zwecks Erfahrungsaustauschs an anderen Industriearbeitskreisen des Projektträgers 

Produktion und Fertigungstechnologien (PFT), der Forschungszentrum Karlsruhe GmbH, zu beteiligen. Hierfür bot 

sich insbesondere der PFT-Industriearbeitskreis „Wissensmanagement in der Praxis: Konzeption, Einführung und 

Controlling von Wissensmanagementsystemen“ an. Die Veranstalter dieses Industriearbeitskreises erklärten jedoch 

dem Universitätspartner auf Anfrage, dass keine Möglichkeit gesehen werde, ihn in den Meinungsaustausch des Arbeitskreises 

einzubeziehen. Daraufhin verzichteten auch die weiteren Partner des Verbundprojekts KOWIEN darauf, 

in diesen Arbeitskreis aufgenommen zu werden. 

59


rum Wissensmanagement“ gegründet 63) . Dieser Industriearbeitskreis stößt auf regen Zuspruch 

unter den KMU der Region. Er tagt in regelmäßigen, zurzeit halbjährlichen Abständen. Die 

Praxispartner des Verbundprojekts KOWIEN nehmen an den Sitzungen des Praxisforums 

Wissensmanagement regelmäßig teil. Dabei nutzen sie die Gelegenheit, sich über ihre Erfahrungen 

hinsichtlich der Entwicklung und Anwendung computerbasierter Wissensmanagementsysteme 

in der betrieblichen Praxis auszutauschen. Der Erfahrungsaustausch betrifft 

nicht nur die Praxispartner des Verbundprojekts KOWIEN untereinander, sondern auch – sogar 

insbesondere – mit anderen Fach- und Führungskräften aus KMU mit ähnlichen Wissensmanagementproblemen. 

Darüber hinaus wurde das Praxisforum Wissensmanagement 

zwischenzeitlich auf ein zweites BMBF-gefördertes Projekt – das eingangs kurz erwähnte 

Verbundprojekt MOTIWIDI – ausgeweitet. Damit dient dieser Industriearbeitskreis „nebenbei“ 

auch dem Erfahrungsaustausch zwischen zwei thematisch eng benachbarten (komplementären) 

Verbundprojekten des BMBF. Seitens des Universitätspartners wurde bereits sichergestellt, 

das Praxisforum Wissensmanagement über die Laufzeit des Verbundprojekts 

KOWIEN hinaus fortzusetzen, um zur Nachhaltigkeit der Projekterfahrungen beizutragen und 

das „Networking“ unter den Mitgliedern des Industriearbeitskreises zu fördern. 

Für die überregionale Verbreitung von Projektergebnissen konnte als weiterer Stakeholder 

die Gemeinschaftsaktion „Multimedia im Maschinenbau“ gewonnen werden, die vom 

VDMA NRW, der IG-Metall-Bezirksleitung NRW und dem Arbeitgeber-Ausschuss Metall 

NRW getragen wird. Am 12. März 2003 erfolgte in diesem praxisnahen Forum ein Beitrag 

zur Transferveranstaltung „Facetten des Wissensmanagements in Maschinenbau-Unter-nehmen 

– Versteckte Potenziale nutzen“ in Krefeld. In diesem Beitrag über „Kooperatives Wissensmanagement 

im Maschinen- und Anlagenbau“ 64) berichteten ein Praxispartner und der 

Universitätspartner gemeinsam über wesentliche Zwischenergebnisse des Verbundprojekts 

KOWIEN und nutzten die Gelegenheit, auf die Entwicklung des Software-Tools für ontologiebasiertes 

Kompetenzmanagement aufmerksam zu machen. 

Darüber hinaus erklärte sich die Zentralstelle für Forschungs- und Entwicklungstransfer 

(FET) der Universität Duisburg-Essen am Campus Essen bereit, die Verbreitung von Ergebnissen 

des Verbundprojekts KOWIEN durch einen Workshop zu fördern, der sich an Wirtschaftsunternehmen 

der Ruhrgebietsregion – vor allem KMU – richtete. Dieser Workshop 

fand am 3. April 2004 mit dem Thema „Computergestütztes Wissensmanagement in Industrie- 

und Dienstleistungsunternehmen“ statt 65) . Sowohl aufgrund seiner praxisnahen Thematik 

als auch wegen seiner Einbettung in die bereits etablierte, mehrjährig durchgeführte Veranstaltungsreihe 

„WirtschaftsForum 10: IuK-Kompetenz im Dialog“, stieß der Workshop auf 

lebhaftes Interesse von KMU der Region. Der Workshop erwies sich als ausgezeichnete Gelegenheit, 

Erwartungen von Praxis und Wissenschaft über computerbasiertes Wissensmanagement 

auszutauschen, und vermittelte auch dem KOWIEN-Team fruchtbare Impulse für die 

Fortsetzung seiner Projektarbeiten. 

63) Nähere Informationen zu diesem Industriearbeitskreis finden sich im Internet unter der URL „http://www.praxisforum-wissensmanagement.de/“. 

Dort kann auch Einsicht in die bereits durchgeführten, praxisorientierten Veranstaltungen 

genommen werden. 

64) Vgl. die Dokumentation der Präsentation im Internet unter der URL „http://www.kowien.uni-essen.de/publikationen/Alan-VDMA_Präsentation.pdf“. 

65) Die Ergebnisse des Workshops sind in einem Tagungsband dokumentiert, dessen Beiträge im Internet unter der URL 

„http://www.kowien.uni-essen.de/publikationen.cfm“ zugänglich sind. Darüber hinaus wurden die Workshop- 

Vorträge auf Video aufgezeichnet und sollten im Internet einer breiteren, über die Ruhrgebietsregion hinaus reichenden 

Öffentlichkeit bekannt gemacht werden. Aufgrund von personellen und zeitlichen Engpässen der Essener Forschungs- 

und Entwicklungstransferstelle hat sich die Veröffentlichung dieser Workshop-Videos im Internet leider 

bislang verzögert. 

60


Des Weiteren haben die Praxis- und der Universitätspartner auf einer größeren Anzahl sowohl 

nationaler als auch internationaler Fachkonferenzen die (Zwischen-) Ergebnisse des Verbundprojekts 

KOWIEN einer interessierten Fachöffentlichkeit vorgestellt. Zu diesen Fachkonferenzen 

zählen u.a. 66) : 

∙ 48th European Organization for Quality Congress (EOQ 04) in Moskau, 

GUS (06.09-10.09. 2004); 

∙ 18th International Workshop on Qualitative Reasoning (QR 04) in Evanston, 

USA (02.08.-04. 08.2004); 

∙ 6th, 7th and 8th World Multiconference on Systemics, Cybernetics and Informatics 

(SCI 2002, SCI 2003, SCI 2004) in Orlando, USA (jeweils August des Jahres) und 

∙ 2. Konferenz Professionelles Wissensmanagement (WM 2003) in Luzern, 

Schweiz (02. 04.-04. 04.2003). 

Schließlich verfassten die Praxis- und der Universitätspartner zahlreiche Veröffentlichungen, 

um die Erkenntnisse und Ergebnisse der Projektarbeiten in der interessierten Öffentlichkeit als 

„globalem Stakeholder“ zu verbreiten. Dazu gehören nicht nur primär wissenschaftlich ausgerichtete 

Publikationen, sondern vor allem auch Beiträge in wirtschaftsnahen Zeitschriften, die 

sich in erster Linie an Fach- und Führungskräfte in KMU richten. Beide Gruppen von Projektpublikationen 

werden in der abschließenden Literaturaufstellung gesondert ausgewiesen. 

3.2 Deutsche Montan Technologie (DMT) GmbH 

Die DMT GmbH 67) wurde 1990 aus den Vorgängerorganisationen Westfälische Berggewerkschaftskasse 

und der Bergbau-Forschung GmbH gegründet und hat sich im Bereich von unabhängigen 

Technologiedienstleistungen im In- und Ausland mit dem Schwerpunkt auf Rohstoff, 

Sicherheit und Infrastruktur spezialisiert. In Zusammenarbeit mit führenden Unternehmen 

erbringt die DMT weltweit in über 70 Ländern hochwertige Systemleistungen. 

Abbildung 1: Die Deutsche Montan Technologie (DMT) GmbH in Essen 

66) Eine vollständige Übersicht über die Projektpräsentationen auf Fachkonferenzen findet sich am Ende des Beitrags. 

67) Weiterführende Informationen finden sich im Internet unter der URL „http://www.dmt.de“. 

61


Das Leistungsspektrum der DMT erstreckt sich vor allem auf folgende Geschäftsfelder: 

• Bergbau Service, 

• Industrie Systeme, 

• Gebäude Sicherheit, 

• Bau Consulting, 

• Exploration & Geosurvey. 

Die DMT GmbH ist aktives Mitglied in 25 in- und ausländischen Fachverbänden, Ausschüssen, 

Gesellschaften und Vereinen. Die Zulassungen der DMT GmbH umfassen 2 behördlich 

anerkannte Fachstellen für Sicherheit, 3 akkreditierte Prüflaboratorien sowie 4 bekannt gegebene 

Prüfstellen. 

Ein Charakteristikum der DMT GmbH ist es, dass sie Engineering-Kompetenzen aus sehr heterogenen 

Geschäftsfeldern in sich vereinigt. Daher bereitet es ihr Schwierigkeiten, bei Ausschreibungen 

von Entwicklungsaufträgen mit inhaltlich stark schwankenden Kompetenzanforderungen 

jederzeit diejenigen Engineering-Kompetenzen zu identifizieren, die im Verbund 

der locker gekoppelten Unternehmensabteilungen aktuell vorhanden sind. Diese Kompetenzen 

müssen zwecks erfolgreicher Auftragsakquisition und -durchführung aufeinander 

abgestimmt werden, um entsprechende Projektteams zusammenzustellen. Deshalb hegt die 

DMT GmbH besonders großes Interesse an einem computerbasierten Wissensmanagementsystem 

für das Management von Kompetenzwissen. 

Den Arbeitsschwerpunkt der DMT GmbH im Verbundprojekt bildet das „Management verteilter 

Wissensressourcen in Engineering-Netzwerken für die Entwicklung technologieintensiver 

Produkte“. Zu den wesentlichen Aufgaben dieses Arbeitsschwerpunkts gehören: 

• die Analyse praktischer Probleme des Wissensmanagements im eigenen Unternehmen, 

• die Formulierung von Anforderungen an ein computerbasiertes Wissensmanagementsystem 

zur Lösung jener Probleme aus der Perspektive betrieblicher Anwender, 

• die Erprobung und Evaluierung der Praxistauglichkeit jener Lösungskonzepte, die vom 

Universitätspartner für das ontologiebasierte Management von Kompetenzen entwickelt 

werden, sowie 

• die Erprobung und Evaluierung der Praxistauglichkeit des prototypischen Software-Tools, 

das vom Softwarepartner als Demonstrationsexemplar für ontologiebasierte Kompetenzmanagementsysteme 

entwickelt wird. 

3.3 Karl Schumacher Maschinenbau (KSM) GmbH 

Die Karl Schumacher Maschinenbau GmbH 68) wurde 1964 gegründet. Das vollkommen unabhängige, 

mittelständisch geprägte Unternehmen expandierte während seiner Entwicklung 

kontinuierlich. Zurzeit werden ca. zwei Dutzend Mitarbeiter bei einer Betriebsgröße von 

ca. 1.300 m 2 beschäftigt. Der ursprünglich regionale Kundenkreis konnte in den letzten Jahren 

international ausgeweitet werden; er erstreckt sich mittlerweile auch auf Staaten wie Großbritannien, 

Frankreich, Spanien, Kanada, GUS (ehemalige Sowjetunion) sowie – neuerdings sogar 

– China. 

68) Weiterführende Informationen finden sich im Internet unter der URL „http://www.ksm-maschinenbau.de“. 

62


Eine breite Produkt-Palette, hohes Technologie- und Qualitätsniveau mit einem Qualitätsmanagementsystem 

nach DIN EN ISO 9001:2000 und ein umfangreiches Kunden-Servicepaket 

sind die wesentlichen Stärken der KSM GmbH. Das Unternehmen entwickelt, konstruiert, fertigt 

und montiert – als typischer Auftragsfertiger – vor allem Sondermaschinen unter Einsatz 

von technologisch anspruchsvollen Maschinenbau- und Steuerungskomponenten mit hohen 

Sicherheits- und Leistungsstandards. Der Einsatz moderner, computerbasierter Planungs-, Organisations- 

und Controllingsysteme sowie eine zeitgemäße Fertigung auf CNC-Werkzeugmaschinen 

versetzen das Unternehmen in Verbindung mit seinem langjährig erworbenen Engineering-Know-how 

in die Lage, Problemlösungen auch zu außergewöhnlichen und sehr 

komplexen Aufgabenstellungen zu liefern. Durch qualitativ und funktionell hochwertige Ausführung 

der Maschinen und Anlagen genießt das Unternehmen in seinem Kundenkreis einen 

hervorragenden Ruf. 

Die derzeitige Betriebsgröße und Unternehmensstruktur der KSM GmbH ermöglichen es, flexibel 

und zeitnah auf individuelle Kundenwünsche einzugehen. In ihrer Fähigkeit zur kundenorientierten 

Produktion auf hohem Technologie- und Qualitätsniveau sieht die KSM 

GmbH einen ihrer wichtigsten Wettbewerbsvorteile. 

Das Leistungsspektrum der KSM GmbH beginnt mit der ersten technischen Analyse des Produkts, 

für das eine Kundenanfrage eingegangen ist. In enger Zusammenarbeit mit dem Kunden 

(„Simultaneous Engineering“) wird eine Lösung für das Kundenproblem entwickelt, die 

sich sowohl an den qualitativen als auch an den wirtschaftlichen Vorstellungen des Kunden 

orientiert. Die Kernkompetenzen im Fertigungs- und Montagebereich liegen auf den Gebieten 

der Hydraulik, der Pneumatik und der Elektrosteuerungssysteme. Darüber hinaus werden 

Montage und Inbetriebnahme der Anlagen beim Kunden durch erfahrene Mitarbeiter angeboten. 

Der Servicebereich umfasst des Weiteren Schulungs- und Trainingsmaßnahmen sowie die 

Lieferung von Ersatzteilen. 

In den vergangenen knapp vier Jahrzehnten wurde eine Vielzahl von Sondermaschinen und 

Anlagen für den Bereich der Montage- und Handhabungstechnik sowie für die Be- und Verarbeitung 

von Großserienteilen erfolgreich entwickelt, konstruiert und gefertigt. Die Lieferungen 

erstreckten sich von der Vorrichtung über die Einzelmaschine bis zur kompletten 

Montagelinie (vgl. die nachfolgende Abbildung 2). 

Kompetenz und Zuverlässigkeit der Mitarbeiter schafften die Grundlage für eine breite Produkt-Palette 

der KSM GmbH. Diese Produktpalette umfasst beispielsweise: 

• vollautomatische verkettete Montage- und Prüflinien für komplexe Pkw-Komponenten, 

wie z.B. für Servolenkungen, Differentialgetriebe, Hinterachsgetriebe, Antriebswellen und 

Schwimmsattelbremsen, 

• Bearbeitungs- und Montagemaschinen – insbesondere Rundtischmaschinen – 

für Massenteile, wie z.B. für Pkw-Scharniere und -Türfeststeller, Motorhalter, 

• Bauteilezuführsysteme für Maschinen, 

• lose verkettete Werkstückträger-Transportsysteme, 

• Montagepressen für komplizierte Pressvorgänge, 

• Schraubmaschinen für Präzisionsverschraubungen, 

• Messmaschinen zum Ausmessen von Großdieselmotoren sowie zur Zylinderkopfund 

Dichtungsmessung, 

• Funktionstest- und Dichtigkeitsprüfungs-Maschinen für Kfz-Wasserpumpen, 

• Montage-, Prüf- und Etikettieranlagen für Stromschienensysteme. 

63


Abbildung 2: Produkte der Karl Schumacher Maschinenbau GmbH 

Die Schwerpunkte des Produktespektrums lagen in den letzten Jahren in der Automobilbranche, 

und zwar sowohl bei den Automobilproduzenten (Ford AG Köln, VW-Werk Shanghai) 

als auch bei deren Zulieferern (z.B. Visteon Deutschland GmbH: Werke Wülfrath und 

Düren, FAW Volkswagen Automotive Co.: Changchun/China, Edscha AG, Kendrion RSL 

Germany GmbH, Kiekert AG, [Klöckner-Humboldt-] Deutz AG, Lucas Automotive GmbH). 

Daneben wurden auch Aufträge aus der Elektro- und der Pharmabranche sowie der Möbelbranche 

akquiriert (z.B. Moeller GmbH, Hettich Holding GmbH & Co. oHG, Madaus AG). 

Aufgrund ihres hohen Umsatzanteils in der Automobilbranche, die von Produzenten und Zulieferern 

mit zum Teil großer Marktmacht geprägt ist, werden durch die KSM GmbH Maßnahmen 

angestrebt, die es ermöglichen, für die Verwertung ihrer Engineering-Kompetenzen 

neue Zukunftsmärkte zu identifizieren und zu erschließen. Daher hegt die KSM GmbH großes 

Interesse daran, sich im Rahmen des Projekts KOWIEN an der Entwicklung des computerbasierten 

Managements von Kompetenzwissen zu beteiligen. 

64


Der Arbeitsschwerpunkt der KSM GmbH im Verbundprojekt betrifft das „Management von 

Kompetenzprofilen für die Entwicklung technologieintensiver Maschinen- und Anlagensysteme 

unter den Randbedingungen hochflexibler Auftragsproduktion“. Zu den wesentlichen 

Aufgaben dieses Arbeitsschwerpunkts gehören: 





Universitätspartner für das ontologiebasierte Management von Kompetenzwissen entwickelt 

werden, sowie 




3.4 TEMA GmbH – Industrial Visiomation 

Die TEMA GmbH 69) ist ein mittelständisch geprägtes Unternehmen. Sie befasst sich seit über 

zehn Jahren mit der Entwicklung und der Produktion opto-elektronischer Komplettlösungen 

für industrielle Anwender. Es handelt sich um einen ausgesprochenen Nischenanbieter mit 

hochgradiger Spezialisierung auf Bildverarbeitungstechniken zur Unterstützung industrieller 

Fertigungsprozesse. Die TEMA GmbH beliefert sämtliche Stufen der Wertschöpfungskette in 

der Stahl- und Kunststoffverarbeitung. Die Anwendungsschwerpunkte ihrer Bildverarbeitungssysteme 

liegen in der prozessoptimierenden Qualitätssicherung und der Materialflusssteuerung. 

Die wesentlichen Kenngrößen zur Charakterisierung der TEMA GmbH lauten: 

• mehr als 10 Jahre Erfahrung, 

• über 100 installierte industrielle Anwendungen, darunter prämierte Systeme, 

• starke Technologieplattform und moderne IT-Infrastruktur, 

• junges motiviertes Team mit erstklassigem akademischen Background, 

• effiziente Projektabwicklung und kurze Entwicklungszeiten auf der Basis von 

Baukasten-Modulen und Bibliotheken. 

Als Marktteilnehmer in einer mittleren Größenordnung befasst sich die TEMA GmbH mit der 

Entwicklung von Anwendungen für die: 

• Oberflächeninspektion, 

• Strukturkontrolle, 

• Vollständigkeitskontrolle, 

• berührungslose Vermessung, 

• Materialflusssteuerung, 

• Lageerkennung und Positionierungssteuerung, 

• Bedruckungskontrolle. 

69) Weiterführende Informationen finden sich im Internet unter der URL „http://www.temavisio.com/“. 

65


Diese Anwendungen sind konzipiert als industrielle, lückenlose Inline-Kontrollen für: 

• bahnförmige Materialien, 

• Stückgüter, 

• Baugruppen, 

• Präzisionsteile, insbesondere im Bereich Automotive, 

• Stanzteile und Ronden, 

• Sonderlösungen. 

Abbildung 3 zeigt einen kleinen Ausschnitt aus der Produktpalette. 

Kontrolle von Deckeln 

(Stückgut) 

Externe 

Datenstation 1 

Bildverarbeitung 

Sortierung von 

Leergutkisten 

(Sonderlösungen) 

Externe 

Datenstation 2 

Kontrolle von Ronden 

(Stanzteile) 

Vermessung von Bauteilen 

(Baugruppen) 

Abbildung 3: Produktpalette der TEMA GmbH 

66 

Kontrolle von 

Metallbahnen 

(bahnförmige Materialien) 

Kontrolle von Felgen 

(Stückgut) 

Industrielle Bildverarbeitung wird in der Industrie in der Regel zur computerbasierten Qualitäts- 

und Prozesskontrolle eingesetzt. Die Haupteinsatzfelder liegen in der metallverarbeitenden 

und kunststoffverarbeitenden Industrie – insbesondere in den Bereichen Vorprodukte/Halbzeug, 

Automotive und Verpackung. In diesen Produktfeldern konnte eine Vielzahl von 

Referenzanlagen (insgesamt weit über 100 Industrieanwendungen) bei namhaften Unternehmen 

im In- und Ausland eingerichtet werden. 

Der Markt der industriellen Bildverarbeitung wird vom VDMA als eindeutiger Wachstumsmarkt 

mit ca. 25 % jährlichem Wachstum eingestuft (siehe die Abbildung 4 auf der folgenden 

Seite). Der nur zum Teil erschlossene Hochtechnologiemarkt ist durch breite Anwendungsmöglichkeiten 

(Qualitätssicherung, Robotik, Materialflusssteuerung, Fertigungsautomatisierung 

u.ä.), eine dynamische technologische Weiterentwicklung und eine fragmentierte Nachfrage 

gekennzeichnet.


Umsatz in 

Mio DM 

1400 

1200 

1000 

800 

600 

400 

200 

0 

1995 1996 1997 1998 1999 2000 2001 

67 

Ja hr VDMA (2000) 

Abbildung 4. Markt der industriellen Bildverarbeitung (Quelle: VDMA) 

Bei den Mitarbeitern der TEMA GmbH handelt es sich im Wesentlichen um Informatiker, 

Physiker und Ingenieure mit mehrjähriger Erfahrung im Bereich der industriellen Bildverarbeitung. 

Der administrative Bereich ist dagegen bewusst eng besetzt. Derzeit beschäftigt die 

TEMA GmbH 15 Mitarbeiter mit dem Schwerpunkt in der Entwicklung. Das Durchschnittsalter 

der Mitarbeiter beträgt knapp 35 Jahre. 

Der Arbeitsschwerpunkt der TEMA GmbH trägt die Bezeichnung „Kompetenzorientiertes 

Multiprojektmanagement zur Entwicklung innovativer industrieller Bildverarbeitungssysteme“. 

Zu den wesentlichen Aufgaben dieses Arbeitsschwerpunkts gehören: 





Universitätspartner für das ontologiebasierte Management von Kompetenzwissen entwickelt 

werden, 




3.5 Roland Berger Strategy Consultants GmbH 

Die Roland Berger Strategy Consultants GmbH 70) , 1967 gegründet, ist eine der weltweit führenden 

Strategieberatungen. Mit 32 Büros in 22 Ländern ist das Unternehmen erfolgreich auf 

dem Weltmarkt aktiv. 1630 Mitarbeiter haben im Jahr 2003 einen Umsatz von über 530 Mio. 

€ erwirtschaftet. Die Strategieberatung ist eine unabhängige Partnerschaft im ausschließlichen 

Eigentum von derzeit mehr als 160 Partnern. 

70) Weiterführende Informationen finden sich im Internet unter der URL „http://www.rolandberger.com“.


Roland Berger berät international führende Industrie- und Dienstleistungsunternehmen sowie 

öffentliche Institutionen. Das Beratungsangebot umfasst alle Fragen der Unternehmensführung 

– von der strategischen Ausrichtung über die Einführung neuer Geschäftsmodelle und - 

prozesse sowie Organisationsstrukturen bis hin zur Informations- und Technologiestrategie. 

Roland Berger ist in globalen Kompetenzzentren organisiert. Die Industrie-Kompetenzzentren 

decken die großen Branchen ab, die funktionalen Kompetenzzentren bieten Know-how zu übergreifenden 

methodischen Fragestellungen. Für jedes Beratungsprojekt wird ein interdisziplinäres 

Team zusammengestellt, das aus Experten mit branchenspezifischem und funktionalem 

Know-how besteht. 

Seit Mitte der 90er Jahre beschäftigt sich Roland Berger mit dem Thema Wissensmanagement 

in zweierlei Hinsicht. Zum einen ist in der wissensintensiven Dienstleistungsbranche „Unternehmensberatung“ 

Wissensmanagement einer der zentralen Kernprozesse des Wertschöpfungsprozesses 

und somit wettbewerbsentscheidend. Zum anderen erstreckt sich das Beratungsangebot 

von Roland Berger u.a. auch auf die Entwicklung und Implementierungsbegleitung 

von klientenspezifischen Wissensmanagement-Konzepten. Hierbei beschränken sich die 

Beratungsleistungen nicht nur auf die Entwicklung eines entsprechenden informationstechnischen 

Infrastruktur-Konzepts, sondern berücksichtigen insbesondere die Strategie, die Organisationsstruktur, 

die Schlüsselprozesse sowie die Kultur des jeweils betroffenen Kundenunternehmens 

(Abbildung 5). 

Schwerpunkt heutiger 

Wissensmanagementaktivitäten?! 

Unternehmensstrategie 

• Datenbanken 

• Suchmaschinen und 

• Incentive Systeme 

Agenten 

• Schnittstellen ERP- 

Systeme 

Technologie 

und Systeme 

Wissensmanagement 

Personal 

und Kultur 

• Organizational Slack 

• Vitality Factors 

• HR-Instrumente 

• Trainings- und 

• Intra-/Inter-/Extranets 

• Workflow- und 

Schulungsprogramme 

Groupwaresysteme Organisa- • Dokumentation von Wissen/ Content Management 

tion und • Übersetzung von implizitem in explizites Wissen 

Prozesse • Schnittstellen zwischen Entwicklung, Produktion, 

Marketing und Vertrieb 

• Aufbaufloworganisation/Hypertextorganisation 

68 

• Leitbild/Vision 

• Score Card 

• Funktionsstrategien 

Abbildung 5: Notwendige Aktivitäten für die erfolgreiche 

Realisierung des Wissensmanagements 

Auslöser für das Interesse von Roland Berger am Projekt KOWIEN ist die Erkenntnis, dass 

das Wissen der Mitarbeiter, der Austausch von Projekterfahrungen zwischen den Mitarbeitern 

sowie die strukturierte und transparente Aufbewahrung von Wissen einer der entscheidenden 

Erfolgsfaktoren in der Beratungsbranche ist. Das Ziel des internen Wissensmanagementprojektes 

„BRAIN“ (Berger Research And Information Network) ist es, eine Plattform zu etablieren, 

die es allen Mitarbeitern weltweit ermöglicht, auf das organisationale Wissen von Roland 

Berger entsprechend ihren individuellen Berechtigungen zuzugreifen. Somit soll einerseits die 

Möglichkeit des Wissensaustauschs gegeben sein, aber andererseits auch dem Anspruch der 

Archivierung des Wissens Genüge geleistet werden. Grundlegendes Gestaltungskriterium für 

das interne Wissensmanagement sind die verschiedenen Informations- oder Wissenssphären, 

in denen sich die Berater während ihrer alltäglichen Arbeit bewegen (Abbildung 6).


Definition von Informationssphären mit unterschiedlichen 

Wertigkeiten für die Arbeit des Consultants 

Internet 

EXTERNE 

INFORMATIONSSPHÄRE 

69 

Brancheninformationen 

Verbände 

ORGANISATORISCHE 


Benchmarks Lessons learned 

Internal 

Online 

Datenbanken 

Publikationen 

CC 

Services 


Who´s Who 

Tools Key Account Mng Vorträge 

Statistiken News 

PROJEKT 


Projekte 

CD-ROMs 

Services 

Internet 

Digest 

Präsentationen 

Memos 

Briefe 

PERSÖNLICHE Tasks 

INFORMATIONS- 

SPHÄRE 

Bücher 

Presse 

Skills 

Firmeninformationen 

Allgemeine/ 

Wirtschaftspresse 

Abbildung 6: Die Informationssphären eines Consultants 

Um den Wissensmanagementprozess möglichst eng an die Kernaktivität der Beratung – die 

Bearbeitung von Projekten – anzubinden, wird dieser Prozess nach dem Prinzip der projektbegleitenden 

Dokumentation organisiert. Von der Anmeldung einer Projektnummer bis zur 

Ablage von Präsentationen, Protokollen und Studien, die im Laufe eines Projekts entstehen, 

werden alle Unterlagen in einem virtuellen Teamraum gesammelt und strukturiert abgelegt. 

Nach Projektabschluss werden die Unterlagen gefiltert und in der unternehmensweiten Knowhow-Datenbank 

„proKNOWLEDGE“ abgelegt (Abbildung 7). 

Ausrichtung des Wissensmanagement an unserer Kernaktivität: 

der Bearbeitung von Projekten 

Prinzip der projektbegleitenden Dokumentation mittels eines virtuellen Teamraums 

Projekt- 

Module 

Berater 

Klienten- 

Materialien 

Eröffnung der 

Projektnummer 

PROJEKT 

Virtueller Teamraum 

Angebote Notizen Präsentationen 

Analysen/ 

Daten- 

Daten 

banken 

Spreadsheets 

Schließung der 

Projektnummer 

"EISY 

Check" 

BRAIN 

proKNOW- 

LEDGE 

Zeit 

• EISY Formulare 

• Präsentationen 

• Angebote 

• etc. 

.bits 

business 

research 

Abbildung 7: Projektbegleitendes Wissensmanagement mittels eines virtuellen Teamraums


Informationstechnisch wird der Wissensmanagementprozess bei Roland Berger im Wesentlichen 

auf Plattformen für datenbank- und internetbezogene Standardsoftware (Oracle, Livelink) 

realisiert. Diese Plattformen werden von einem hauseigenen Applikationsteam für die 

Belange der Berater fortentwickelt und entsprechend angepasst. Alle Anwendungen werden 

weltweit über Internetbrowser bedient (Abbildung 8). 

Einstieg über ein Portal mit verschiedenen Informationsbereichen 

Abbildung 8: Die Internetplattform BRAIN 

Die geplanten Weiterentwicklungen gehen dahin, dass die Ablage von Wissen zeitnäher und 

effizienter erfolgt. Außerdem soll der Zugriff auf einzelne Wissenskomponenten spezifischer 

auf die Bedürfnisse und Berechtigungen einzelner Nutzer zugeschnitten werden. Erstes erfordert 

einen Ansatz, der auf eine Beschleunigung und Effizienzsteigerung des Wissensmanagements 

abzielt. Dies entspricht auch den wesentlichen Zielen des Verbundprojekts KOWIEN. 

Zweites wird bei Roland Berger – außerhalb des Verbundprojekts – durch Mikroportale und 

Agententechnologie realisiert. 

Das professionelle Management von Wissen und Innovationen ist selbstverständlich nicht nur 

für Beratungsunternehmen ein wichtiges Thema. Unternehmen aus allen Industriezweigen 

haben erkannt, dass sie Ansätze und Instrumente bereithalten müssen, um „den Schatz in den 

Köpfen der Mitarbeiter“ im Sinne ihrer Unternehmensziele Wert steigernd einsetzen zu können. 

Um die Nachfrage nach Beratung in diesem Feld kompetent befriedigen zu können, hat 

Roland Berger die „Knowledge and Innovation Community“ – kurz: KIC – ins Leben gerufen. 

Die Community bündelt das im Unternehmen vorhandene Wissen und baut Innovations- 

und Wissensmanagement als Beratungsfeld aus. Erfahrene Berater untersuchen weltweit aktuelle 

Trends und innovative Entwicklungen im Bereich von Innovations- und Wissensmanagement. 

Die Projekterfahrung von Roland Berger reicht in diesem Bereich von der Entwicklung 

unternehmensweiter Wissensmanagementstrategien über die Auswahl von unternehmensspezifischen 

Wissensmanagementinstrumenten bis hin zur Erarbeitung eines Konzepts 

für „Intellectual Property“. Dabei hat Roland Berger nicht nur führende Unternehmen aus 

dem Maschinen- und Anlagenbau unterstützt, sondern auch Unternehmen der Elektroindustrie, 

der Luft- und Raumfahrtindustrie sowie IT-Unternehmen und Banken. 

70


Darüber hinaus fördert Roland Berger den Erfahrungsaustausch mit Hochschulen und Verbänden. 

Durch die Betreuung von Diplomarbeiten und Promotionen zum Thema Innovationsund 

Wissensmanagement unterstützt Roland Berger den kontinuierlichen Austausch zwischen 

Theorie und Praxis. Im Jahr 2001 ist eine gemeinschaftliche Studie mit dem Verband Deutscher 

Maschinen- und Anlagenbau (VDMA), Arbeitsgemeinschaft Großanlagenbau, zum 

Thema „Wissensmanagement im Deutschen Großanlagenbau“ erfolgreich abgeschlossen worden. 

Im Rahmen dieses Projekts wurde eine umfangreiche empirische Studie zum aktuellen 

Stand der Wissensmanagementdiskussion im deutschen Großanlagenbau und zu den Erwartungen 

an einen praxisorientierten Managementansatz durchgeführt. Hinsichtlich des Verbundprojekts 

KOWIEN hat die Gemeinschaftsstudie von Roland Berger und VDMA u.a. zu 

zwei bemerkenswerten Einsichten geführt. 

Erstens bieten Unternehmen des Maschinen- und Anlagenbaus ein interessantes Anwendungsfeld 

für Entwicklungsanstrengungen auf dem Gebiet des Wissensmanagements. Denn es klafft 

eine deutliche Lücke zwischen einerseits der hohen Wissensintensität der Branche und andererseits 

der noch „ausbaufähigen“ Nutzung des innerbetrieblich verfügbaren Wissens. Diese 

Diskrepanz wird von den Befragungsergebnissen veranschaulicht, die in Abbildung 5 wiedergegeben 

sind. Es ist zu erwarten, aus der gemeinsamen Arbeit im Projekt KOWIEN wertvolle 

Einsichten in das computerbasierte Management von Kompetenzwissen zu gewinnen, die in 

der Maschinen- und Anlagenbaubranche auf fruchtbaren Boden fallen würden. Roland Berger 

sieht eine seiner wesentlichen Aufgaben im Rahmen des Projektkonsortiums darin, die Diffusion 

der Projektergebnisse in die betriebliche Praxis – hier vor allem: den Maschinen- und 

Anlagenbau – mittels seiner weit reichenden Industriekontakte nachhaltig zu fördern. 

Der Anlagenbau wird zwar als "wissensintensive Branche" bezeichnet; 

derzeit wird die Ressource Wissen jedoch nur begrenzt genutzt 

WIE KLASSIFIZIEREN SIE DIE WISSENS- 

INTENSITÄT 1) IM ANLAGENBAU? 

0% 

sehr 

schwach 

13% 

19% 

63% 

6% 

gering mittel stark sehr 

stark 

1) Die Wissensintensität wird definiert als die gewichtete Summe der Bedeutung von Patenten, F&E Ausgaben, Anteil der Akademiker an 

der Gesamtbelegschaft, Ausgaben für Informationstechnologie und geschätzte Substituierbarkeit von Erfahrungsträger 

71 

WIE GROß SCHÄTZEN SIE DEN ANTEIL DES DER- 

ZEIT TATSÄCHLICH BENUTZTEN WISSENS EIN? 

19% 

6% 

50% 

19% 

0% 

6% 

0–20% 20–40% 40–60% 60–80% 80–100% k. A. 

%Anteil des derzeit genutzten Wissens 

Abbildung 9: Die Bedeutung der Ressource Wissen im Anlagenbau 

Zweitens bestätigt die Gemeinschaftsstudie von Roland Berger und VDMA, dass für ein Erfolg 

versprechendes Wissensmanagement zwei Wissensquellen mit höchster Priorität zu berücksichtigen 

sind (vgl. Abbildung 10): einerseits implizites Erfahrungswissen, das aus der 

Durchführung von Projekten gewonnen wurde und „in den Köpfen“ der Projektmitarbeiter 

verankert ist, sowie andererseits explizit dokumentiertes Wissen, das in Projektberichten u.ä. 

Unterlagen enthalten ist. Diese beiden Wissensquellen werden auch im hier beschriebenen


Projekt KOWIEN vorrangig behandelt, und zwar in der Gestalt von Kompetenzprofilen, die 

maßgeblich das Erfahrungswissen der betroffenen Mitarbeiter widerspiegeln, bzw. in der 

Form von Web-Dokumenten über Projekterfahrungen. 

Erfolgsrelevantes Wissen im Anlagenbau ist vor allem implizites 

Wissen bzw. dokumentiertes Projektwissen 

WIE SCHÄTZEN SIE DIE BEDEUTUNG DER 

FOLGENDEN IMPLIZITEN WISSENSQUELLEN EIN? 

Projekterfahrung 

Lost Order Analyse 

Best Practice 

Infos über 

potentielle Projekte 

Markt-/Wettb.Infos 

Mitarbeiter- 

Erfahrungen 

3,4 

Überlieferte 

Geschichten 

3,2 

Erfahrungen der 

Kunden 

3,5 

1 2 3 4 

unwichtig sehr wichtig 

Punktwerte als Durchschnitt der Nennungen 

2,5 

3,2 

3,0 

3,9 

3,6 

72 

WIE BEURTEILEN SIE DIE RELEVANZ DER 

FOLGENDEN EXPLIZITEN WISSENSQUELLEN? 

∅ 3,2 ∅ 2,7 

Handbücher 

Vorschriften 

Patente/Lizenzen 

Projektdokumentation 

Expertenverzeichnisse 

Produktdokumentation 

Strategische 

Planung 

Fachliteratur 

2,4 

2,4 

2,4 

2,8 

2,7 

2,7 

3,0 

3,7 

1 2 3 4 

unwichtig sehr wichtig 

Abbildung 10: Erfolgsrelevantes Wissen im Anlagenbau 

Über die zuvor exemplarisch angeführten Detailergebnisse hinaus hat die Gemeinschaftsstudie 

von Roland Berger und VDMA generell gezeigt, dass erfolgreiches Wissensmanagement 

zwar einen kohärenten und umfassenden Ansatz verfolgen muss (Ganzheitlichkeit), die erhofften 

Potenziale jedoch nur über die sinnvolle Priorisierung von Aktivitäten und Maßnahmen 

realisiert werden können (Pragmatismus). Die Gratwanderung zwischen Ganzheitlichkeit 

und Pragmatismus ist ein wesentlicher Bestandteil des branchenspezifischen Beratungsansatzes 

von Roland Berger. 

Der Arbeitsschwerpunkt von Roland Berger im Verbundprojekt trägt die Bezeichnung „Wissensmanagement 

bei weltweit verteilten Akteuren im Projektgeschäft“. Zu den wesentlichen 

Aufgaben dieses Arbeitsschwerpunkts gehören: 

• Anforderungen an ein computerbasiertes Wissensmanagementsystem sollen aus der Perspektive 

betrieblicher Anwender erhoben werden, und zwar nach Möglichkeit im engen 

inhaltlichen Anschluss an die bereits durchgeführte Gemeinschaftsstudie mit dem VDMA. 

• Lösungskonzepte für Probleme des Wissensmanagements und entsprechende Software- 

Werkzeuge, die im Rahmen des Projekts KOWIEN entwickelt werden, sollen im eigenen 

Unternehmen unmittelbar in die Praxis der Unternehmensberatung zur Verbesserung ihrer 

strategischen Wettbewerbsposition eingeführt werden. Dabei stehen die Weiterentwicklung 

der bereits vorhandenen Wissensmanagementkonzeption (BRAIN, proKNOWLED- 

GE) und die Verbesserung der bestehenden Software-Werkzeuge im Vordergrund der Arbeiten. 

Diese Arbeiten erstrecken sich auch auf die Erprobung und Evaluierung der Praxistauglichkeit 

jener Lösungskonzepte, die vom Universitätspartner für das ontologiebasierte 

Management von Kompetenzwissen erarbeitet werden, sowie des prototypischen 

Software-Tools, das vom Softwarepartner als Demonstrationsexemplar für ontologiebasierte 

Kompetenzmanagementsysteme entwickelt wird.


• Insbesondere soll Best-practice-Wissen aus bereits durchgeführten Beratungsprojekten für 

die Akquisition und die Bearbeitung neuer Projekte allen Mitgliedern des eigenen Unternehmens 

zugänglich gemacht werden. Hierdurch wird die rasche Identifizierung und 

Verwertung von unternehmensintern vorhandenem, aber nicht direkt zugänglichem Erfahrungs- 

und Expertenwissen unterstützt. 

• Roland Berger erstellt – wie bereits im Kapitel über die Projektergebnisse dargestellt wurde 

– eine professionelle Fallstudie in der Art einer Harvard Business School Case Study, 

die innerhalb des Service-Engineering-Szenarios angesiedelt ist. Sie verdeutlicht die praktische 

Verwertbarkeit von Konzeptionen und Werkzeugen für das betriebliche Wissensmanagement. 

Schließlich übernimmt Roland Berger die Rolle eines Multiplikators für die Ergebnisse des 

KOWIEN-Projekts. Das Beratungsunternehmen bringt als Promotor für Wissensmanagementprojekte 

in der sachgüter-, insbesondere investitionsgüterproduzierenden Industrie umfangreiche 

Projekterfahrungen und Praxiskontakte in das Vorhaben ein. Dabei besteht die Möglichkeit, 

auf den bisherigen Erkenntnissen und „Lessons Learned“ aufzubauen und diese zu vertiefen. 

3.6 Comma Soft AG – The Knowledge People 

Seit der Gründung im Jahr 1989 hat sich Comma Soft 71) als führendes IT-Consulting-Unternehmen 

in Deutschland etabliert. Seit 1999 Aktiengesellschaft, beschäftigt das Unternehmen 

heute in Bonn und den Geschäftsstellen circa 90 hochqualifizierte Mitarbeiter. Neugier, 

Teamgeist und Ehrgeiz, wenn es um die Entwicklung neuer Lösungen geht – das alles zeichnet 

„The Knowledge People“ aus. Das Portfolio des Unternehmens reicht von High-End-Consulting 

für große IT-Architekturen bis hin zu Lösungen auf dem Gebiet Wissenskommunikation. 

Comma Soft IT-Consulting steht seit Jahren für umfangreiche Erfahrungen und sehr hohe 

Lösungskompetenz in IT-Großprojekten bei Unternehmen, Behörden und Verbänden. Kosteneffizienz, 

Prozessqualität, schlanker IT-Betrieb und Innovation stehen im Fokus der Dienstleistungen. 

Hoch-innovative Lösungen und Komponenten bieten die Competence Center 

Infrastructure Engineering, Directory Services, Systems Management und Collaboration Systems 

u.a. in den folgenden Themengebieten an: IT-Prozess- und Strategieberatung; Client/ 

Server-, Intranet/Internet- und PKI-Architekturen; Desktop Lifecycle Management; Design 

von Messaging-, Workflow- und Portal-lösungen; Identity und Resource Management, Software 

Architekturberatung und Engineering (.NET, J2EE). Es werden intensive und langjährige 

Partnerschaften u.a. mit Microsoft (Gold Certified Partner), SAP (Development und Consulting 

Partner) und Citrix (Silver Partner) gepflegt. 

infonea ® schafft transparente Informationsnetzwerke. In den meisten Unternehmen gibt es eine 

unübersichtliche Zahl von Dateninseln, die jeweils nur Bruchstücke der relevanten Informationen 

bereitstellen, ohne diese miteinander zu verknüpfen. Mit der Wissensmanagement- 

Architektur infonea ® („information network architecture“), auf der auch der KOWIEN- 

Prototyp basiert, bietet die Comma Soft ein Produkt an, mit dem individuelle Lösungen geschaffen 

werden, die die Komplexität der Zusammenhänge aus dem Alltag abbilden und beherrschbar 

machen. Der fortschrittliche Software-Engineering-Ansatz der iterativen Anwen- 

71) Weiterführende Informationen finden sich im Internet unter der URL „http://www.comma-soft.com“. 

73


dungsentwicklung wird von infonea ® optimal unterstützt, da infonea ® -Anwendungen modelliert 

werden und die verschiedenen Modelle schrittweise erweitert werden können. Die Informationsobjektklassen 

und Assoziationen des infonea ® -Objektmodells lassen sich frei definieren, 

so dass sich infonea ® -Lösungen dadurch auszeichnen, dass sie den individuellen Anforderungen 

anspruchsvoller Kunden gerecht werden. Das ontologiebasierte und prozessorientierte 

Kompetenzmanagementsystem, das im Rahmen des KOWIEN-Projekts auf Basis von 

infonea ® entwickelt worden ist, wird inzwischen auch im eigenen Unternehmen eingesetzt, 

um das Vorgehen bei infonea ® -Projekten zu unterstützen. 

Abbildung 11: Beispiel eines einfachen Objektmodells in infonea ® 

Die klare Orientierung der Comma Soft AG am Kundennutzen hat zu Partnerschaften geführt, 

die zum Teil seit über 10 Jahren andauern (Auszug): Deutscher Bundestag, Bundesministerium 

des Innern, Bundesministerium der Finanzen, Dresdner Bank AG, Finanzministerium 

NRW, Landesamt für Datenverarbeitung & Statistik NRW, Bundesverwaltungsamt, Victoria 

Versicherungsgesellschaft, Commerzbank AG, DaimlerChrysler AG, ERGO Versicherungs 

AG, Bankhaus Sal. Oppenheim jr. & Cie. KGaA, AOK, AXA, Stadtsparkasse Köln, Bundesministerium 

für Umwelt, Detecon, Deutsche Krankenversicherung, Post AG, NASPA. 

Die Comma Soft AG ist sehr daran interessiert, über weitere praxistaugliche Vorgehensmodelle 

und Software-Tools für computerbasierte Wissensmanagementsystemen zu verfügen. 

Die Comma Soft AG bringt daher in das Vorhaben ihre einschlägigen Praxiserfahrungen hinsichtlich 

der Konzipierung und Realisierung von kundenspezifischer Anwendungssoftware 

und von Softwarearchitekturen ein. Ihre wesentliche Aufgabe als Softwarepartner des Projektkonsortiums 

besteht darin, auf der Grundlage eines gemeinsam erarbeiteten Fachkonzepts 

ein prototypisches Software-Tool für das Management von Kompetenzwissen zu realisieren. 

Der entsprechende Arbeitsschwerpunkt der Comma Soft AG im Verbundprojekt trägt die Bezeichnung 

„Entwicklung eines Tools zum vorgehensmodell- und ontologiebasierten Wissensmanagement“. 

Ein wesentliches Entwicklungsziel besteht darin, ein skalierbares Software- 

Tool zu schaffen, das sich an die unterschiedlichen Betriebssystem- und Applikationsumgebungen 

sowohl von Großunternehmen als auch von kleinen und mittleren Unternehmen 

(KMU) flexibel anzupassen vermag. 

74


3.7 Institut für Produktion und Industrielles Informationsmanagement 

(PIM) der Universität Duisburg-Essen am Campus Essen 

Das Institut für Produktion und Industrielles Informationsmanagement 72) ist ein universitäres 

Forschungsinstitut. Seine Hauptarbeitsgebiete liegen einerseits im Bereich moderner, computerbasierter 

Produktionskonzepte sowie andererseits im Bereich der Allgemeinen Betriebswirtschaftslehre. 

Im erstgenannten Bereich befasst es sich vor allem mit computerbasierten 

Techniken zur Unterstützung des industriellen Prozess-, Ressourcen-, Informations- und Wissensmanagements 

sowie mit Methoden des Kompetenzen- und Innovationsmanagements. Im 

letztgenannten Bereich werden insbesondere Konzepte des strategischen Managements (z.B. 

des resource-based view), des Performance Measurements (z.B. erweiterte Wirtschaftlichkeitsrechnungen, 

Balanced Scorecards und Technologiewirkungsanalysen) und quantitative 

/ formale Modellierungs- und Entscheidungstechniken (Operations Research, Artificial Intelligence) 

untersucht sowie inhaltlich fortentwickelt. 

Speziell im Hinblick auf das Verbundprojekt KOWIEN besitzt das Institut jahrelange Erfahrungen 

auf dem Gebiet der Erforschung Künstlicher Intelligenz. Hervorzuheben sind vielfältige 

Arbeiten zur betriebswirtschaftlichen Anwendung und Evaluierung von Expertensystemen, 

Wissensbasierten Systemen sowie Multi-Agenten-Systemen. Zur Nutzung von Ontologien als 

Instrument des betrieblichen Wissensmanagements erfolgten mehrere wissenschaftliche Studien, 

die sich in entsprechenden – zum Teil auch internationalen – Konferenzbeiträgen und 

Publikationen niedergeschlagen haben. Einen weiteren Arbeitsschwerpunkt bilden Studien, 

die sich mit der Koordinierung von Unternehmens-Netzwerken mit Hilfe von elektronischen 

Märkten und Multi-Agenten-Systemen beschäftigen. Die Thematik Unternehmens-Netzwerke 

weist enge Bezüge zu den Engineering-Netzwerken auf, die den Gegenstandsbereich des hier 

beantragten Projekts bilden. Ebenso kann auf umfangreiche praktische und theoretische Arbeiten 

im Bereich der Handels- und Industrielogistik sowie bei der Gestaltung überbetrieblicher 

Prozessketten verwiesen werden. Auf dem Gebiet der Informationsmodellierung im Allgemeinen 

und der Referenzmodellierung im Speziellen liegen bei Know-how-Trägern des Instituts 

einschlägige Erfahrungen aus dem Projekt GoM (Grundsätze ordnungsmäßiger Modellierung) 

vor, das seitens des BMBF gefördert wurde. In der Dienstleistungsbranche hat sich 

ein Mitarbeiter des Instituts an Arbeiten zum Service-Engineering beteiligt, die im Rahmen 

des Projekts GiPP (Geschäftsprozessgestaltung mit integrierten Prozess- und Produktmodellen) 

erfolgten. 

Das Institut leistet im Verbundprojekt KOWIEN innerhalb seines Arbeitsschwerpunkts „Wissensmanagement 

für Engineering-Netzwerke mit Techniken des Knowledge-Level- 

Engineerings“ die maßgeblichen konzeptionellen und methodischen Arbeiten innerhalb der 

Bereiche Ontologien, Referenzmodelle und Vorgehensmodelle. Dies schließt insbesondere 

auch den Transfer neuartiger Techniken aus dem Umfeld der Grundlagenforschung ein, die – 

wie etwa auf dem Gebiet des Knowledge-Level-Engineerings – zur Nutzung und Verwertung 

durch die fünf beteiligten Kooperationspartner aus der betrieblichen Praxis erschlossen werden 

sollen. Einen zweiten Schwerpunkt der Arbeiten bildet die Konzipierung von Lösungen 

für Probleme des ontologiebasierten Kompetenzmanagements. Aufbauend auf der gemeinsamen 

Analyse praktischer Probleme zusammen mit den Praxispartnern werden vom Universitätspartner 

grundlegende Lösungskonzepte entwickelt, die anschließend von den kooperierenden 

Unternehmen hinsichtlich ihrer Praxistauglichkeit zu erproben und zu evaluieren sind. 

72) Weiterführende Informationen finden sich im Internet unter der URL „http://www.pim.uni-essen.de/“. Auf 

eine ausführlichere Darstellung der Arbeiten und Erfahrungen des Universitätspartners auf dem Fachgebiet 

des Verbundprojekts KOWIEN wird an dieser Stelle verzichtet, um den Präsentationen der Praxispartner in 

den voranstehenden Abschnitten breiteren Raum gewähren zu können. 

75


Danksagungen 

Alle Teammitglieder des Verbundprojekts KOWIEN – der Universitäts- und die Praxispartner 

– möchten dem Bundesministerium für Bildung und Forschung (BMBF) für die großzügige 

finanzielle Förderung dieses Forschungs- und Entwicklungsprojekts danken, die innerhalb des 

Rahmenkonzepts „Forschung für die Produktion von morgen“ erfolgte (Förderkennzeichen 

Hauptband 02 PD1060). 

Ein ganz besonderer Dank gilt dem Projektträger Produktion und Fertigungstechnologien 

(PFT), der Forschungszentrum Karlsruhe GmbH, der das Verbundprojekt in exzellenter Weise 

mit Rat und Tat betreut hat. Unter den zahlreichen Mitarbeitern des PFT, die oftmals im 

„Hintergrund“ für die effiziente Durchführung der betreuten Projekte sorgen, gebührt ein herausgehobenes 

„Dankeschön“ Frau Martina Kühnapfel, die wie eine „gute Seele“ die Projektarbeiten 

während der dreijährigen Projektlaufzeit mit großem persönlichen Engagement 

begleitete und in manchen „kniffligen“ Situationen wertvolle Anregungen vermittelte. Darüber 

hinaus hat es Frau Kühnapfel gemeinsam mit Herrn Dipl.-Ing. Steinebrunner, dem sich 

das Projektteam ebenso zu großem Dank verpflichtet fühlt, bereits in der frühen Phase der 

Projektbeantragung mit zahlreichen hilfreichen Hinweisen zur Antragsstellung erst ermöglicht, 

dass das KOWIEN-Projekt in die Förderung des BMBF aufgenommen wurde. Da der 

Universitätspartner in unterschiedlichen Projekten Erfahrungen mit mehreren verschiedenen 

Projektträgern des BMBF sammeln durfte, möchte er dem PFT – und hierfür stellvertretend 

Frau Kühnapfel sowie Herrn Dipl.-Ing. Steinebrunner – große Anerkennung für die nicht nur 

jederzeit fachlich hoch kompetente, sondern auch menschlich in immer ausgesprochen angenehmer 

Atmosphäre verlaufene Zusammenarbeit danken. Das PFT setzt mit seiner Kundenorientierung 

und Professionalität Maßstäbe unter den Projektträgern des BMBF! 

Schließlich „lebt“ ein Verbundprojekt von seinen Teammitgliedern. Daher möchte der Verfasser 

dieses Beitrags „last, but not least“ besonders herzlich allen Mitgliedern des KOWIEN- 

Teams für ihre engagierte, ideenreiche und „produktive“ Mitarbeit danken, die oftmals weit 

über das hinaus reichte, was im Rahmen eines Drittmittelprojekts „gewöhnlich“ erwartet werden 

darf. Dazu gehören seitens der Praxispartner vor allem Frau Dipl.-Kff. Schumacher und 

Herr Dipl.-Kfm. Zug von der Karl Schumacher Maschinenbau GmbH, Frau Dipl.-Volksw. 

Bremer und Herr Dr. Sowa von der Deutschen Montan Technologie GmbH, Herr Dr. Meier 

von der TEMA GmbH / Mühlbauer AG, Herr Engelmann von der Roland Berger Strategy 

Consultants GmbH sowie Herr Dipl.-Phys. Hübbers und Herr Dipl.-Inform. Bäumgen von der 

Comma Soft AG. Auf der Seite des Universitätspartners sieht sich der Verfasser insbesondere 

gegenüber seinen wissenschaftlichen Mitarbeitern in der Dankesschuld, die in „unermüdlicher 

Selbstausbeutung“ – auch an tiefen Abendstunden und an langen Wochenenden – weit mehr 

geleistet haben, als jemals von ihnen hätte erwartet werden können: Herrn Dipl.-Kfm. Alan, 

Herrn Dipl.-Kfm. Alparslan, Herrn Dipl.-Ing. Dittmann, Herrn Dipl.-Wirt.-Inf. Weichelt sowie 

als „freie Mitarbeiterin“ auch Frau Dipl.-Wirt.-Inf. Apke möchte der Verfasser in ganz 

besonderer Weise seinen persönlichen Dank für die herausragende wissenschaftliche Mitarbeit 

im Projekt aussprechen, die mittlerweile zu zahlreichen nationalen und internationalen 

Veröffentlichungen zum Projekt KOWIEN geführt hat – und hoffentlich in wenigen Monaten 

auch noch durch mindestens drei exzellente Dissertationen eine „Krönung“ erfahren wird. 

76


Literatur 

Vorbemerkung: Im Folgenden werden wegen der hier gebotenen Kürze überwiegend nur Publikationen 

angeführt, die im Zusammenhang mit dem Verbundprojekt KOWIEN entstanden 

sind. Vertiefende Literaturhinweise finden sich für interessierte Leser in den nachfolgend angeführten 

Projektpublikationen. Darüber hinaus werden in der letzten Rubrik einige wenige 

Publikationen aufgelistet, die im voranstehenden Überblicksbeitrag ausdrücklich referenziert 

wurden. 

a) Monografie zum Verbundprojekt: 

ZELEWSKI, S.; ALAN, Y.; ALPARSLAN, A.; DITTMANN, L.; WEICHELT, T. (Hrsg.): Ontologiebasierte 

Kompetenzmanagementsysteme – Grundlagen, Konzepte, Anwendungen. Berlin 2005 

(Logos-Verlag; in Vorbereitung). 

b) Projektberichte des Verbundprojekts: 

Die Berichte sind – nachstehend in chronologischer Reihenfolge angeführt – jeweils erschienen 

am: Institut für Produktion und Industrielles Informationsmanagement, a) bis Ende 2002: 

Universität Essen – b) ab Anfang 2003: Universität Duisburg-Essen (Campus Essen), Essen 

2001 ff. 

ZELEWSKI, S.: Rahmenplan zum Verbundprojekt KOWIEN. Projektbericht 1/2001. 

ALPARSLAN, A.: Ablauforganisation des Wissensmanagements. Projektbericht 1/2002. 

ALAN, Y.: Methoden zur Akquisition von Wissen über Kompetenzen. Projektbericht 2/2002. 

DITTMANN, L.: Sprachen zur Repräsentation von Wissen – eine untersuchende Darstellung. 

Projektbericht 3/2002. 

DITTMANN, L.: Zwecke und Sprachen des Wissensmanagements zum Managen von Kompetenzen. 

Projektbericht 4/2002. 

ALAN, Y.; BÄUMGEN, C.: Anforderungen an den KOWIEN-Prototypen. Projektbericht 5/2002. 

ALPARSLAN, A.: Wissensanalyse und Wissensstrukturierung. Projektbericht 6/2002. 

ALAN, Y.: Evaluation der KOWIEN-Zwischenergebnisse. Projektbericht 7/2002. 

APKE, S.; DITTMANN, L.: Analyse von Vorgehensmodellen aus dem Software, Knowledge und 

Ontologies Engineering. Projektbericht 1/2003. 

ALAN, Y.: Konstruktion der KOWIEN-Ontologie. Projektbericht 2/2003. 

ALAN, Y.: Ontologiebasierte Wissensräume. Projektbericht 3/2003. 

APKE, S.; DITTMANN, L.: Generisches Vorgehensmodell KOWIEN Version 1.0. Projektbericht 

4/ 2003. 

ALAN, Y.: Modifikation der KOWIEN-Ontologie. Projektbericht 5/2003. 

ALAN, Y.; ALPARSLAN, A.; DITTMANN, L.: Werkzeuge zur Sicherstellung der Adaptibilität des 

KOWIEN-Vorgehensmodells. Projektbericht 6/2003. 

ENGELMANN, K.; ALAN, Y.: KOWIEN Fallstudie – Gebert GmbH. Projektbericht 7/2003. 

DITTMANN, L.: Towards Ontology-based Skills Management. Projektbericht 8/2003. 

ALPARSLAN, A.: Evaluation des KOWIEN-Vorgehensmodells, Projektbericht 1/2004. 

77


APKE, S.; BÄUMGEN, C.; BREMER, A.; DITTMANN, L.: Anforderungsspezifikation für die Entwicklung 

einer Kompetenz-Ontologie für die Deutsche Montan Technologie GmbH. Projektbericht 

2/2004. 

HÜGENS, T.: Inferenzregeln des „plausiblen Schließens“ zur Explizierung von implizitem 

Wissen über Kompetenzen. Projektbericht 3/2004. 

ALAN, Y.: Erweiterung von Ontologien um dynamische Aspekte. Projektbericht 4/2004. 

WEICHELT, T.: Entwicklung einer E-Learning-Anwendung zum kompetenzprofil- und ontologiebasierten 

Wissensmanagement – Modul 1: Grundlagen. Projektbericht 5/2004. 

APKE, S; DITTMANN, L.: Konstruktion der Kompetenzontologie für die DMT GmbH. Projektbericht 

6/2004 (in Bearbeitung). 

DITTMANN, L.: Generisches Vorgehensmodell KOWIEN Version 2.0. Projektbericht 7/2004 

(in Bearbeitung). 


Wissensmanagement – Modul 2: Vorgehensmodell. Projektbericht 8/2004 (in 

Bearbeitung). 


Wissensmanagement – Modul 3: Prototyp. Projektbericht 9/2004 (in Bearbeitung). 

ZELEWSKI, S.: (Vorläufiger) Abschlussbericht zum Verbundprojekt KOWIEN. Projektbericht 

10/2004. 

c) Praxisorientierte Publikationen des Verbundprojekts: 

ALAN, Y.; ALPARSLAN, A.; DITTMANN, L.; ZELEWSKI, S.: Potenziale semantischer Technologien 

für das Wissensmanagement in kleinen und mittelgroßen Unternehmen (KMU). In: 

MEMO – Mensch und Motivation (Online-Zeitschrift der IQM-Europe GmbH – Institut für 

Qualifizierung und Lernmedien, Hamburg) Meldung vom 08.03.2004. 

ALPARSLAN, A.; DITTMANN, L.; ILGEN, A.; ZELEWSKI, S.: Wissensmanagement im Anlagenbau: 

Computergestütztes Management von Wissen über Mitarbeiterkompetenzen. In: Industrie 

Management, 18. Jg. (2002), Nr. 6, S. 45-48. 

APKE, S.: Produkt- und Innovationsbericht zum InWert-Verwertungspraktikum, Institut für 

Produktion und Industrielles Informationsmanagement, Universität Duisburg-Essen (Campus 

Essen), Essen 2003. 

DITTMANN, L.; PETERS, M.L.; ZELEWSKI, S.: Wissenstransfermotivation und ontologiebasierte 

Kompetenzmanagement-Systeme. Eingereicht zu: MEYER, A. (Hrsg.): Jahrbuch der KMU- 

Forschung und -praxis 2005: Informations- und Wissensmanagement in KMU und bei Freiberuflern. 

DITTMANN, L.; PETERS, M.L.; ZELEWSKI, S.: Wissensträger identifizieren und motivieren. In: 

Wissensmanagement – Das Magazin für Führungskräfte, 6. Jg. (2004), Heft 4, S. 51-53. 

DITTMANN, L.; PETERS, M.; ZELEWSKI, S.: Mitarbeitermotivation und Kompetenzmanagementsysteme. 

In: REIMER, U.; ABECKER, A.; STAAB, S.; STUMME, G. (Hrsg.): WM2003: Professionelles 

Wissensmanagement – Erfahrungen und Visionen, Beiträge zur 2. Konferenz, 

02.-04.04.2003 in Luzern, Bonn 2003, S. 9-16. 

78


o.V. (ZELEWSKI, S.): Das BMBF-Projekt KOWIEN. In: MEMO – Mensch und Motivation 

(Online-Zeitschrift der IQM-Europe GmbH – Institut für Qualifizierung und Lernmedien, 

Hamburg), Meldung vom 08.03.2004. 

ZELEWSKI, S. (Hrsg.): Computergestütztes Wissensmanagement in Industrie- und Dienstleistungsunternehmen, 

Tagungsband zum WirtschaftsForum 10 (in der Reihe IuK-Kompetenz im 

Dialog), am 03.04.2003 an der Universität Duisburg-Essen, Campus Essen, Essen 2003. 

ZUG, S.; KLUMPP, M.; KROL, B.: Wissensmanagement im Gesundheitswesen, Arbeitsbericht 

Nr. 16, Institut für Produktion und Industrielles Informationsmanagement, Universität Duisburg-Essen 

(Campus Essen), Essen 2003. 

d) Weitere wissenschaftsorientierte Publikationen zum Themengebiet des Verbundprojekts: 

ALAN, Y.; ZELEWSKI, S.: Ontologiebasierte Wissensräume. In: REIMER, U.; ABECKER, A.; 

STAAB, S.; STUMME, G. (Hrsg.): WM2003: Professionelles Wissensmanagement – Erfahrungen 

und Visionen, Beiträge zur 2. Konferenz, 02.-04.04.2003 in Luzern, Bonn 2003, S. 5-8. 

ALAN, Y.; ZELEWSKI, S.: Ontologiebasierte Wissensräume. In: SURE, Y.; SCHNURR, H.-P. 

(Hrsg.): WOW 2003: Workshop Ontologie-basiertes Wissensmanagement, Proceedings, 02.- 

04.04.2003 in Luzern, CEUR Workshop Proceedings, Vol. 68, Karlsruhe 2003, 6. Beitrag, 

o.S. (S. 1-12). 

ALAN, Y.; ZELEWSKI, S.; SCHÜTTE, R.: Implementation of Knowledge Spaces in Ontologies. 

In: CALLAOS, N.; LESSO, W.; SÁNCHEZ, P.; HANSEN, E. (Hrsg.): The 7th World Multiconference 

on Systemics, Cybernetics and Informatics (SCI 2003), 27.-30.07.2003 in Orlando, 

USA, Proceedings, Vol. VI: Informations Systems, Technologies and Applications: I, Orlando 

2003, S. 183-188. 

ALPARSLAN, A.; DITTMANN, L.: Gütekriterien für ontologiegestützte Kompetenzmanagementsysteme. 

In: HOFMANN, G.R.; ALM, W. (Hrsg.): Management der Mitarbeiter-Expertise in IT- 

Beratungsbetrieben – Grundlagen, Methoden und Werkzeuge, Tagungsband zur MultiKonferenz 

Wirtschaftsinformatik 2002, 09.-11.09.2002, Nürnberg 2002, S. 66-79. 

DITTMANN, L.: Ontology-based Skills Management. Work Report No. 22, Projekt KOWIEN, 

Institut für Produktion und Industrielles Informationsmanagement, Universität Duisburg- 

Essen (Campus Essen), Essen 2004. 

DITTMANN, L.; PENZEL, J.: Platons Gütekriterium für Ontologien. In: FRANK, U. (Hrsg.): Wissenschaftstheorie 

in Ökonomie und Wirtschaftsinformatik. Wiesbaden 2004, S. 457-478. 

DITTMANN, L.; PETERS, M.L.; ZELEWSKI, S.: Motivationale Aspekte beim Einsatz von konventionellen 

und ontologiebasierten Kompetenzmanagementsystemen. In: SURE, Y.; SCHNURR, 

H.-P. (Hrsg.): WOW 2003: Workshop Ontologie-basiertes Wissensmanagement, Proceedings, 

02.-04.04.2003 in Luzern, CEUR Workshop Proceedings, Vol. 68, Karlsruhe 2003, 5. Beitrag, 

o.S. (S. 1-16). 

DITTMANN, L.; RADEMACHER, T.; ZELEWSKI, S.: Performing FMEA Using Ontologies. In: DE 

KLEER, J.; FORBUS, K. D.: 18th International Workshop on Qualitative Reasoning, Proceedings, 

02.-04.08.2004 in Evanston, USA, Evanston 2004, S. 209-216. 

DITTMANN, L.; RADEMACHER, T.; ZELEWSKI, S.: Combining Knowledge Management and 

Quality Management Systems. Eingereicht zu: 48th EOQ (European Organization for Quality) 

Congress, 07.-09.09.2004 in Moskau. 

79


DITTMANN, L.; SCHÜTTE, R.; ZELEWSKI, S.: Darstellende Untersuchung philosophischer Probleme 

mit Ontologien. In: FREYBERG, K.; KLEIN, B.; PETSCHE, H.-J. (Hrsg.): Knowledge Management 

and Philosophy, Proceedings of the WM 2003 Workshop on Knowledge Management 

and Philosophy, 03.-04.04.2003 in Luzern, CEUR Workshop Proceedings, Vol. 85, 

Bonn 2003, 3. Beitrag, o.S. (S. 1-13). 

DITTMANN, L.; ZELEWSKI, S.: Integrating Computer-based Systems of Knowledge and Quality 

Engineering to Manage Skills. Eingereicht zu: 8th International Symposium on Measurement 

and Quality Control in Production (ISMQC) – IMEKO TC14 Measurement of Geometrical 

Quantities, 12.-15.10.2004 in Erlangen (erscheint als VDI-Tagungsband 1860: Measurement 

and Quality Control in Production, Erlangen 2004). 

DITTMANN, L.; ZELEWSKI, S.: Ontology-based Skills Management. In: CALLAOS, N.; LE- 

FEBVRE, V.; HANSEN, E.; DICKOPP, T.; JAW-SIN, S.: The 8th World Multi-conference on Systemics, 

Cybernetics and Informatics (SCI 2004), 18.-21.07.2004 in Orlando, USA, Proceedings, 

Vol. IV: Information Systems, Technologies and Applications I, Orlando 2004, S. 190- 

195. 

PETERS, M.L.; ZELEWSKI, S.: Competence-Based Workplace Assignment Using a Goal Programming 

Approach. In: ZÜLCH, G.; STOWASSER, S.; JAGDEV, H.S. (Hrsg.): Human Aspects in 

Production Management, Proceedings of the IFIP WG 5.7 Working Conference on Human 

Aspects in Production Management – Volume 1, 05.-09.10.2003 in Karlsruhe, Aachen 2003, 

S. 276-282. 

SCHÜTTE, R.; ZELEWSKI, S.: Epistemological Problems in Working with Ontologies. In: 

CALLAOS, N.; PORTER, J.; RISHE, N. (Hrsg.): The 6th World Multiconference on Systemics, 

Cybernetics and Informatics (SCI 2002), 14.-18.07.2002 in Orlando, USA, Proceedings, Vol. 

VII: Information Systems Development II, Orlando 2002, S. 161-167. 

SCHÜTTE, R.; ZELEWSKI, S.: Epistemological Problems in Working with Ontologies, Arbeitsbericht 

Nr. 13, Institut für Produktion und Industrielles Informationsmanagement, Universität 

Essen, Essen 2001. 

SCHÜTTE, R.; ZELEWSKI, S.: Wissenschafts- und erkenntnistheoretische Probleme beim Umgang 

mit Ontologien. In: KÖNIG, W.; WENDT, O. (Hrsg.): Wirtschaftsinformatik und Wissenschaftstheorie 

– Verteilte Theoriebildung, 08.-09.10.1999 in Frankfurt/Main, Frankfurt 1999, 

Beitrag 2, S. 1-19. 

ZELEWSKI, S.: Organisierte Erfahrung – Wissensmanagement mit Ontologien. In: Essener Unikate, 

Nr. 18: Wirtschaftsinformatik – Wissensmanagement und E-Services, Essen 2002, S. 

63-73. 

ZELEWSKI, S.: Wissensmanagement mit Ontologien – eine einführende Darstellung, Arbeitsbericht 

Nr. 15, Institut für Produktion und Industrielles Informationsmanagement, Universität 

Essen, Essen 2002. 

ZELEWSKI, S.: Ontologien – ein Überblick über betriebswirtschaftliche Anwendungsbereiche. 

In: o.V.: Workshop „Forschung in schnellebiger Zeit“, 30.-31.03.2001 in Appenzell, Beitrag 

5. 

ZELEWSKI, S.: Ontologien zur Strukturierung von Domänenwissen – Ein Annäherungsversuch 

aus betriebswirtschaftlicher Perspektive, Arbeitsbericht Nr. 3, Institut für Produktion und Industrielles 

Informationsmanagement, Universität Essen, Essen 1999 (Paper, präsentiert zusammen 

mit SCHÜTTE, R.; SIEDENTOPF, J. am 18.06.1999 in Berlin anlässlich des Workshops 

„Wissen, Wissenschaftstheorie und Wissenschaftsmanagement“ der Kommission Wissenschaftstheorie 

des Verbandes der Hochschullehrer für Betriebswirtschaft e.V.). 

80


ZELEWSKI, S.; FISCHER, K.: Ontologiebasierte Koordination von Anpassungsplanungen in 

Produktions- und Logistiknetzwerken mit Multi-Agenten-Systemen, Arbeitsbericht Nr. 5, Institut 

für Produktion und Industrielles Informationsmanagement, Universität Essen, Essen 

1999 (Positionspapier für: Workshop „Fertigungslogistik“ zur Vorbereitung des DFG- 

Schwerpunktprogramms „Intelligente Softwareagenten und betriebswirtschaftliche Anwendungsszenarien“ 

am 17.08.1999 in Paderborn). 

ZELEWSKI, S.; SCHÜTTE, R.; SIEDENTOPF, J.: Ontologien zur Repräsentation von Domänen. In: 

SCHREYÖGG, G. (Hrsg.): Wissen in Unternehmen - Konzepte, Maßnahmen, Methoden. Tagung 

der Wissenschaftlichen Kommission „Wissenschaftstheorie“ des Verbandes der Hochschullehrer 

für Betriebswirtschaft e.V., 18.-19.06.1999 in Berlin, Berlin 2001, S. 183-221. 

ZELEWSKI, S.; SIEDENTOPF, J.: Ontology-based coordination of planning activities in networks 

of autonomous production facilities using multi-agent systems. In: KIRN, S.; PETSCH, M. 

(Hrsg.): Workshop „Intelligente Softwareagenten und betriebswirtschaftliche Anwendungsszenarien“ 

Technische Universität Ilmenau, Ilmenau 1999, S. 77-84. 

e) Sonstige referenzierte Publikationen: 

BREMER, C.F.; MUNDIM, A.P.F.; MICHILINI, F.V.S.; SIQUEIRA, J.E.M.; ORTEGA, L.M.: New 

Product Search and Development as a Trigger to Competencies Integration in Virtual Enterprises. 

In: SIEBER, P.; GRIESE, J. (Hrsg.): Organizational Virtual ness and Electronic Commerce, 

Proceedings of the 2nd International VoNet-Workshop, 23.-24.09.1999 in Zürich, o.O. 

1999, S. 213-222. 

BULLINGER, H.-J.; SCHEER, A.W. (Hrsg.): Service Engineering, Berlin et al. 2002. 

CORSTEN, H.: Dienstleistungsmanagement, 3. Aufl., München - Wien 1997. 

FRESE, E.: Exzellente Unternehmungen – konfuse Theorien. Kritisches zur Studie von PETERS 

und WATERMAN. In: Die Betriebswirtschaft, 45. Jg. (1985), Heft 5, S. 604-605. 

GRUBER, T.R.: A Translation Approach to Portable Ontology Specifications. Knowledge Systems 

Laboratory Technical Report KSL 92-71, Computer Science Department, Stanford University, 

Revised Version vom April 1993 [Original vom September 1992], Stanford 1993 

(auch erschienen in: Knowledge Acquisition, Vol. 5 (1993), No. 2, S. 199-220). 

HANSEN, M.T.; NOHRIA, N.; TIERNEY, T.: What’s Your Strategy for Managing Knowledge? 

In: Harvard Business Review, 1999, No. March - April, S. 106-116. 

KILLINGER, S.: Kernproduktbegleitende Dienstleistungen – Dienstleistungen im Leistungsspektrum 

industrieller Unternehmungen. In: CORSTEN, H.; SCHNEIDER, H. (Hrsg.): Wettbewerbsfaktor 

Dienstleistung, Produktion von Dienstleistungen – Produktion als Dienstleistung, 

München 1999, S. 129-155. 

LAMMERS, M.: Make, Buy or Share – Combining Resource Based View, Transaction Cost 

Economics and Production Economies to a Sourcing Framework. In: Wirtschaftsinformatik, 

46. Jg. (2004), S. 204-212. 

LUCZAK, H. (Hrsg.): Servicemanagement mit System – Erfolgreiche Methoden für die Investitionsgüterindustrie, 

Berlin et al. 1999. 

NONAKA, I.; TAKEUCHI, H.: The Knowledge-Creating Company – How Japanese Companies 

Create the Dynamics of Innovation, New York - Oxford 1995. 

81


o.V.: Maschinenherstellern fehlt Kundenorientierung – Wettbewerbsdruck ausländischer Anbieter 

/ Studie des VDMA. In: Frankfurter Allgemeine Zeitung, Ausgabe vom 14.04.1997, Nr. 

86, S. 17. 

PETERS, T.J.; WATERMAN, R.H.: In Search of Excellence: Lessons from America's Best-Run 

Companies, New York 1982 (Neuausgabe: London: 2004 / deutsche Übersetzung: Auf der 

Suche nach Spitzenleistungen: was man von den bestgeführten US-Unternehmen lernen kann, 

10. Aufl., Frankfurt am Main 2004). 

ZELEWSKI, S.: Searle's Wiederbelebung der starken KI-These – Ein Beitrag zur Diskussion 

des Erkenntnisprogramms der Erforschung Künstlicher Intelligenz (KI). In: CASATI, R.; WHI- 

TE, G. (Hrsg.): Philosophy and the Cognitive Sciences, Papers of the 16th International Wittgenstein 

Symposium, 15.-22.08.1993 in Kirchberg, Beiträge der Österreichischen Ludwig 

Wittgenstein Gesellschaft (Nr.) 1, Kirchberg 1993, S. 611-616. 

Projektpräsentationen auf Fachkonferenzen 

ALAN, Y.; SCHUMACHER, M.: Kooperatives Wissensmanagement im Maschinen- und Anlagenbau. 

Vortrag im Rahmen der @m-Transferveranstaltung (VDMA-NRW) „Facetten des 

Wissensmanagements in Maschinenbau-Unternehmen“ in Krefeld, Deutschland (12.03.2003). 

ALAN, Y.; ZELEWSKI, S.: Implementation of Knowledge Spaces in Ontologies. 7th World 

Multiconference on Systemics, Cybernetics and Informatics (SCI 2003) in Orlando, USA 

(29.07.2003). 

ALAN, Y.; ZELEWSKI, S.: Ontologiebasierte Wissensräume. 2. Konferenz Professionelles Wissensmanagement 

(WM 2003) in Luzern, Schweiz (04.04.2003). 

ALPARSLAN, A.: Ontologiebasiertes Wissensmanagement – Computergestütztes Management 

von Wissen über Mitarbeiterkompetenzen. Vortrag anlässlich des WirtschaftsForums 10: 

Computergestütztes Wissensmanagement in Industrie- und Dienstleidungsunternehmen in Essen, 

Deutschland (03.04.2003). 

DITTMANN, L.; PENZEL, J.: Platons Gütekriterium für Ontologien. Tagung Wissenschaftstheorie 

in Ökonomie und Wirtschaftsinformatik (WOWI 2003) in Koblenz, Deutschland (06.06. 

2003). 

DITTMANN, L.; RADEMACHER, T.; ZELEWSKI, S.: Combining Knowledge Management and 

Quality Management Systems. 48th European Organization for Quality Congress (EOQ 04) in 

Moskau, GUS (08.09.2004). 

DITTMANN, L.; RADEMACHER, T.; ZELEWSKI, S.: Performing FMEA Using Ontologies. 18th 

International Workshop on Qualitative Reasoning (QR 04) in Evanston, USA (02.08.2004). 

DITTMANN, L.; SCHÜTTE, R.; ZELEWSKI, S: Darstellende Untersuchung philosophischer Probleme 

mit Ontologien. 2. Konferenz Professionelles Wissensmanagement (WM 2003) in Luzern, 

Schweiz (04.04.2003). 

DITTMANN, L.; ZELEWSKI, S.: Integrating Computer-based Systems of Knowledge and Quality 

Engineering to Manage Skills. 8th International Symposium on Measurement and Quality 

Control in Production (ISMQC 04) in Erlangen, Deutschland (13.10.2004). 

DITTMANN, L.; ZELEWSKI, S.: Ontology-based Skills Management, 8th World Multiconference 

on Systemics, Cybernetics and Informatics (SCI 2004) in Orlando, USA (21.07.2004). 

ENGELMANN, K.: Erfahrungen von Roland Berger & Partner – Strategy Consultants mit dem 

Wissensmanagementsystem BRAIN. Vortrag anlässlich des WirtschaftsForums 10: Compu- 

82


tergestütztes Wissensmanagement in Industrie- und Dienstleidungsunternehmen in Essen, 

Deutschland (03.04. 2003). 

PETERS, M. L.; DITTMANN, L.; Zelewski, S: Motivationale Aspekte beim Einsatz von konventionellen 

und ontologiebasierten Kompetenzmanagementsystemen. 2. Konferenz Professionelles 

Wissensmanagement (WM 2003) in Luzern, Schweiz (04.04.2003). 

ZELEWSKI, S.: Computergestütztes Wissensmanagement in Industrie- und Dienstleistungsunternehmen. 

Vortrag anlässlich des WirtschaftsForums 10: Computergestütztes Wissensmanagement 

in Industrie- und Dienstleidungsunternehmen in Essen, Deutschland (03.04.2003). 

Weitere Präsentationen sowie Seminar- und Diplomarbeiten, die im Zusammenhang mit dem 

Verbundprojekt KOWIEN erfolgten, sind im Internet auf der Projekt-Website unter der URL 

„http://www.kowien.uni-essen.de/publikationen.cfm“ dokumentiert. 

83

4 Teil 2 

Teil 2: 

Impulsvorträge 

85


5 simon 

Aspekte der Produktentwicklung im Rahmenkonzept 

„Forschung für die Produktion von morgen“ 

ARNE SIMON 

87

Aspekte der Produktentwicklung im Rahmenkonzept „Forschung für die Produktion von morgen“ 

88


89

Aspekte der Produktentwicklung im Rahmenkonzept „Forschung für die Produktion von morgen“ 

90


6 Tang 

Von Informationstechnik zur Integrationstechnologie 

– am Beispiel der Virtuellen Produktentstehung – 

TRAC TANG 

Zusammenfassung: Dank der rasanten Entwicklung der Leistungsfähigkeit von Informationstechnik 

in den vergangenen Dekaden wird IT heute allgegenwärtig in allen Unternehmensprozessen 

genutzt, um im immer härter werdenden Wettbewerb Vorteile in Veränderungsfähigkeit, Prozesseffizienz 

und -geschwindigkeit zu erzielen. Hierbei eignet sich IT nicht nur als mächtige technologische 

Arbeitsmittel, sondern auch als Basistechnologie, um Organisationen, Prozesse und Informationen 

miteinander zu vernetzen. Prozesse werden durch IT daher nicht nur beschleunigt, 

sondern dadurch auch parallelisiert und synchron ablaufen können. Innovative webbasierte Technologien 

und eine flexible Integrationsarchitektur haben sich als wichtige Bestandteile für die 

Umsetzung einer unternehmensweiten Integrationsstrategie erweisen. 

Am Beispiel der Integration von Anwendungen entlang des virtuellen Produktentstehungsprozesses 

bei Volkswagen wird im vorliegenden Beitrag über die strategischen Konzepte, die realisierten 

Lösungen sowie die künftige Perspektive bezüglich der Vernetzung von heterogenen Prozessen, 

Produktinformationen und Systemen berichtet. 

1 Einleitung 

Die Informationstechnik gehört heute zu den Standardtechnologien in allen Unternehmensprozessen. 

Sie trägt maßgeblich zur Verringerung von Prozesszeiten und -kosten sowie zur 

Erhöhung der Prozessqualität bei. 

Die vielfältige Prozesskomplexität und damit auch komplexen Anforderungen an die IT- 

Lösungen implizieren jedoch immer noch eine Vielzahl von unterschiedlichen Systemen und 

Lösungen entlang der einzelnen Teilprozesse, so z. B. entlang des Produktentstehungsprozesses. 

Diese heterogenen Lösungen müssen informations- und ablauftechnisch prozessdurchgängig 

miteinander vernetzt werden, wenn dadurch eine maximale Wertschöpfung in Form 

von Zeit-, Kosten- und Qualitätsvorteilen für den Prozess erreicht werden soll. Im Virtuellen 

Produktentstehungsprozess erweisen sich 

• eine zukunftsträchtige, auf leistungsfähiger Webtechnologie basierende Integrationsarchitektur 


• ein prozessübergreifendes Konzept von strukturierten Produktinformationen 

als unabdingbare Voraussetzungen für die unternehmensweite Integration von Organisationen, 

Prozessen und Informationen. 

2 Leistungsfähige Integrationsarchitektur 

Im Produktentstehungsprozess (PEP) werden heute vielfältige, isolierte wie auch teilintegrierte 

IT-Lösungen eingesetzt. Durch die fortschreitende Konzentration und Konsolidierung unter 

den IT-Anbietern von PLM-Lösungen sind heute für Teilbereiche des PEP leistungsfähige, 

multidisziplinäre Lösungsfamilien bereits aus einer Hand bzw. auf Basis einer einheitlichen, 

aber meist proprietären Systemarchitektur verfügbar. Daneben werden insbesondere in größe- 

91

Von Informationstechnik zur Integrationstechnologie – am Beispiel der Virtuellen Produktentstehung – 

ren Unternehmen so genannte Legacy-Systeme, deren umfangreichen Daten auf Jahre hinaus 

weiterhin missionskritische Bedeutung haben, noch in großer Anzahl benötigt. 

Da die Integration sowohl von unternehmenseigenen Lösungen als auch von Systemen anderer 

Anbieter, die aufgrund von funktionalen Erfordernissen unumgänglich sind, aus kommerziellen 

Beweggründen von den PLM-Marktführern nicht ausreichend unterstützt wird, ist die 

Konzeption und die Implementierung einer auf Standards basierten und damit von den Lösungsherstellern 

unabhängigen Integrationsarchitektur empfehlenswert. So wurde zum Beispiel 

im vom BMBF geförderte Verbund- und Leitprojekt iViP (Integrierte Virtuelle Produktentstehung) 

[1] eine Referenz-Integrationsarchitektur, die vielfältige Anwendungen und 

Dienste exemplarisch auf einer auf Corba und PDMEnablers basierten Integrationsplattform 

verknüpft, erarbeitet. 

iViP Integrationsarchitektur 

Prozeßmanagement 

P1.1 

Benutzerkommunikation 

P1.2 

iViP - Client 

Plug in ..... Plug in 

anwendungsnahe 

Dienste 

iViP PDM 

Werkzeuge 

P2.1 P2.2/2.3 PC 3 

iViP Werkzeuge 

BMBF-Projektabschlusspräsentation 


Dr. T. Tang, Oktober 2004 

Innov. Gest. 


Validierungs- 


PC 4 PC 5 

92 


Fertigungserprob. 

Integrationsplattform P1.3 

Systemdienste 

Datenbus (CORBA, iViP-Objektschnittstelle, ...) 

Wrapper Wrapper 

Wrapper 

DMU 

CAD 

Externe Werkzeuge 

Volkswagen hat neben einer im Unternehmen konsequent umgesetzten Systemstrategie, den 

Produktentstehungsprozess global in allen Marken und Regionen mit wenigen strategischen 

Systempartnern einheitlich zu unterstützen, ein den eigenen Anforderungen gerechtes, architekturübergreifendes 

Integrationskonzept für die Kollaboration von heterogenen Lösungen 

implementiert. 

Die Engineering-to-Engineering (e2e) – Integrations- und Kommunikationsplattform setzt 

hierbei auf offene und bereits sehr leistungsfähige Technologiestandards wie XML, JA- 

VA/J2EE, SOAP [2]. Damit lassen sich Web Services für einzelne applikationsneutrale Basisfunktionen 

oder Teilaufgaben realisieren und können den Erfordernissen einer integrierten 

Business-Logik entsprechend dynamisch zur Laufzeit genutzt werden. Standard- 

PDM


Systemkonnektoren werden für den Zugriff auf die originären Informationen bereitgestellt 

und helfen damit, Daten- und Applikationsredundanzen zu vermeiden. 

Durch die Verwendung von anbieterneutralen Standards [3] ist gewährleistet, dass 

• die Portabilität auf verschiedenen Software- und Hardware-Plattformen gegeben ist, 

• der Zugriff auf Altdaten und Altsysteme ohne Migration möglich wird, 

• die Nutzung von zentralen Web-Services wie User und Identity Management mit Single 

Sign-On-Fähigkeit Doppelentwicklungen vermeidet und 

• die enormen, Internet-getriebenen technologischen Fortschritte ohne Abhängigkeit von einem 

einzelnen Systemanbieter nutzbar werden. 

JSP 

JSP 

M C 

V 

Thin Client 

Servlet 

M C 

V 

e2e/TC Framework 

Rich Client 

Application Logic 

Integrationsplattform 

e2e/RC OOF 

D+WS/RC OOF 

Business 

Delegation 

Business 

Delegation 

HTTP/ 

SOAP 




Integration Platform 

Services 

Basic Services 

93 

Service 

Service 

Corporate User 

Management 

RDbMS 

Connector 

KVS 

Connector 

SAP 

Connector 

TI-Host 

Connector 

Data 

Sources 

DB2 

ORACLE 

KVS 

TI-Syncro 

Betriebsmittel 

Prozessinformationen 

Das e2e-Technologiekonzept erleichtert und standardisiert die Online-Kommunikation im gesamten 

PEP und darüber hinaus. Es stellt internen und externen Prozesspartnern integrierte 

Produktinformationen auf einfacher Weise und über sehr ressourceneffiziente Web Clients 

zur Verfügung. Bei Volkswagen werden z.B. 

• Versionen von Steuergeräte-Software, die in einem SW-Versionsmanagement-system verwaltet 

werden, über die e2e-Plattform mit den Konstruktionsdaten und den Stücklisteninformationen 

verknüpft und in integrierter Form den nachgelagerten Prozessen in der Produktion 

und im Kundenservice zur Verfügung gestellt, 

• Prozesssteuerungsinstrumente wie das Reifegradspiegel-Online [4] in der e2e-Plattform als 

Ablaufumgebung von wieder verwendbaren Diensten wie Sicherheits- und Autorisierungskomponenten 

sowie Konnektoren zu PDM-/TDM-Systemen unterstützt, 

...


• Fertigungsprozesspläne über die Standard-Konnektoren in der e2e-Plattform mit vielfältigen 

Produkt- und Prozessinformationen wie Stücklisten, CAD-Modellen, Behälterinformationen, 

Hallenlayouts, etc. prozessgerecht verknüpft. 

Andere unternehmensweite Prozesse wie z.B. die Problemabstellung und die Fehlerprävention, 

die vom Kundenservice über die Qualitätssicherung und die Produktion bis zur Produktentstehung 

zurück reichen, können ebenfalls über die e2e-Plattform ohne großen Aufwand 

online auf umfassende und konsistente Produktinformationen zurückgreifen. 

3 Strukturierte Produktinformationen 

Das verbindende und integrierende Element zwischen den Teilprozessen In der Virtuellen 

Produktentstehung sind die Produkt- und Prozessinformationen. Konsistenz, Vollständigkeit 

und Verfügbarkeit dieser Informationen, u.A. durch dokumentierte Übergaben, stellen die 

grundlegenden Voraussetzungen für die Funktionsfähigkeit der virtuellen Arbeitsprozesse dar, 

gleichwohl ist deren Sicherstellung angesichts der Komplexität der Informationen und der 

Prozesse eine enorme Herausforderung. 

Als konzeptionelle Basis für die Integration der Produktinformationen wurde bei Volkswagen 

die TI-CAD Strategie erarbeitet, in der u.A. festgelegt wird: 

• Rollenfestlegung für die Produktinformationen verwaltenden Systeme hinsichtlich Prozessunterstützung, 

Funktionen und Daten 

• Verbindliche Definition von Master-Systemen für alle prozessrelevanten Datenobjekte in 

Form einer System-Datenobjekt-Zuordnung. 

Für jedes prozessrelevante Datenobjekt gibt es ein definierendes Master-System. Das Master- 

System enthält Funktionen zur Bearbeitung der zugeordneten Datenobjekte. Die Bearbeitung 

von logisch gleichen Datenobjekten in mehr als einem System ist nicht zugelassen. Im Ausnahmefall 

muss die System übergreifende Konsistenz der Daten durch standardisierte Mechanismen 

wie Online-Abgleich, Check-In / Check-Out der sogenannten „Datenprozessoren“ mit 

dem Master-System sichergestellt werden. Die lesende Nutzung von Datenobjekten eines 

Master-Systems in anderen Systemen, z.B. mittels Viewer, ist generell möglich. 

Weitere Konsistenz- und Vollständigkeitsprüfungen werden in den Daten erzeugenden Systemen 

vorgenommen. So werden z.B. im neuen SAP-basierten Stücklistensystem von Volkswagen, 

TI-Syncro, umfangreiche Konsistenzprüfungen der sehr komplexen Stücklisteninformationen 

hinsichtlich Zwänge, Verbote und Kombinierbarkeit durchgeführt [5]. 

94


Strukturierte Produktinformationen 

Variante 

Baukasten 

Variante 

Strukturstückliste 




95 

Arbeitsplan, 

Werkstückliste, 

... 

In TI-Syncro werden alle Varianten einer Produktklasse gemeinsam in einer mehrstufigen Variantenstrukturstückliste 

dargestellt. Für Zusammenbauten wie z.B. Komponenten werden sogenannte 

Baukastenstücklisten verwendet, die für eine effiziente Modul- und Gleichteilestrategie 

unabdingbar sind. Auf Basis dieser Produktstrukturen kann über die im vorangegangenen 

Abschnitt beschriebenen e2e-Standard-Konnektoren auf die den Strukturknoten zugeordneten 

Dokumente, die bei Volkswagen im zentralen Konstruktionsdatenverwaltungssystem 

(KVS) entsprechend dem sogenannten Konstruktionsstand, Dokumentenart, etc. verwaltet 

werden, zugriffen werden. 

Auf Basis der konsistenten Produktstruktur ist die produktgerechte Erzeugung und die Integration 

weiterer Produkt- und Prozessinformationen wie Werkstückliste und Arbeitsplan leicht 

möglich. Damit ist auch sichergestellt, 

alle die Produktdaten nutzenden Prozesse in der Produktentstehung und darüber hinaus (z.B. 

Operative Beschaffung, Qualitätssicherung, Disposition, Bedarfsrechnung und Kalkulation) 

über hoch qualitative und logisch geprüfte Produktinformationen verfügen. Als integrationstechnologische 

Plattform kann wiederum die dargelegte e2e-Architektur dienen. 

4 Ausblick 

Die konsequente Weiterentwicklung von IT als Informationstechnik zur Integrationstechnologie 

ist der Schlüssel zur Maximierung des Nutzens beim Einsatz von IT. Die hohen Investitionen 

in Technologie und Prozessumgestaltung werden sich nur rechtfertigen lassen, wenn 

entlang der Unternehmensprozesse die Organisationen, Teilprozesse und Informationen mittels 

IT integrativ miteinander vernetzt werden.


Webtechnologie-basierte Standards haben sich als leistungsfähige Technologie dafür erwiesen, 

die heterogenen Informationen und Lösungen entlang des gesamten Prozesses miteinander 

zu verknüpfen. Solch eine auf offenen Standards basierte Integrationsarchitektur kann als 

Kommunikationsplattform für die Prozesspartner, die im Rahmen der Engineering-to- 

Engineering-Prozesse an der Wertschöpfungskette im Entwicklungs- und Lieferverbund beteiligt 

sind, genutzt werden. Damit erreicht die Integration auch die Prozesspartner außerhalb 

der traditionellen Unternehmensgrenzen. 

Basis der Integration und der Kommunikation in produzierenden Unternehmen sind die produkt- 

und prozessbezogenen Informationen. Eine konsequente Strukturierung der Produktinformationen 

zur Sicherstellung der Vollständigkeit, Konsistenz und Aktualität bildet die Basisvoraussetzung 

für eine erfolgreiche Integration aller produktbezogenen Prozesse im Unternehmen. 

Damit lassen sich auch weitere wettbewerbsdifferenzierende Abläufe schneller und 

sicherer definieren und im Unternehmen implementieren, um die klassische Produktentstehung 

zu einem ganzheitlichen Produktprozess, der alle produktspezifischen Prozesse von der 

Produktdefinition über den Start of Production hinaus bis zur Serienbetreuung und Ende der 

Produktion reicht, weiterzuentwickeln. 

5 Referenzen 

[1] F.-L. Krause, T. Tang, U. Ahle (Hrsg.) 

Leitprojekt ‚Integrierte Virtuelle Produktentstehung’ – Abschlussbericht 

Berlin, 2002 

[2] T. Tang, 

Kollaborative Lösungen auf einer Integrations- und Kommunikationsplattform 

- Basisvoraussetzung für die integrierte virtuelle Produktentstehung - 

Virtual Product Creation / Innovationsforum 2002 

Berlin, 2002 

[3] M. Feltes, L. Lämmer, 

XPDI – Standardisierung von webbasierten PLM-Services für das Collaborative Engineering 

ProduktDaten Journal, Nr. 1 / 2004 

Darmstadt, 2004 

[4] T. Hartmann, K. Biller, A.-E. Exarchou, M. Koesling, M. Kompf, 

Reifegradspiegel-Methodik und Reifegradspiegel-Online 

ProduktDaten Journal, Nr. 1 / 2004 

Darmstadt, 2004 

[5] T. Tang, 

Integrierte Produktinformation für die Produktentstehung 

Virtual Product Creation 2003 

Stuttgart, 2003 

96


6 Schnitzlein 

1 Kurzvorstellung 

Collaborative Engineering bei der ZF Group 

WERNER SCHNITZLEIN 

Die ZF Passau GmbH ist Spezialist für Antriebstechnik mit sehr hohem technischen Anspruch. 

Wir sind Marktführer auf den Segmenten Baumaschinengetriebe und –achsen sowie 

auf dem Sektor der Traktorengetriebe im freien Markt sowie bei Fahrwerkstechnik und Achssystemen 

für Busse in Niederflurtechnologie. Wir decken mit unserer ErgoPowerreihe fast alle 

Baumaschinenbelange ab, bieten stufenlose Traktorengetriebe, Einzelradaufhängungen für 

Busse oder 4-Punkt-Lenker für LKW und vieles mehr. 

Abbildung 1: 

Die ZF Passau GmbH ist eine 100%-Tochter der ZF Friedrichshafen AG und stellt den 

Hauptsitz des Unternehmensbereiches Arbeitsmaschinen-Antriebssysteme und Achssysteme 

dar, der mit einem Umsatz von ca. 1200 Mio Euro und ca. 6700 Mitarbeitern 12 Produktions- 

Standorte weltweit umfasst. 

97


Die ZF tätigt insgesamt einen Umsatz von ca. 8900 Mio. Euro mit ca. 53500 Mitarbeitern und 

verfügt über 119 Produktionsstandorte und 3 Entwicklungszentren in Deutschland und Nordamerika. 

Ein Entwicklungszentrum in China ist im Aufbau. 

2 Kundenanforderungen 

Das Produktspektrum der ZF erstreckt sich von Getrieben und Achsen für Baumaschinen, 

Landmaschinen, NKW, PKW über Lösungen für Fahrwerke und Lenkungen also Produkte für 

alles was auf dem Land fährt. Im maritimen Bereich decken wir ein Spektrum ab, das von 

Pleasure-Boats bis hin zu Antrieben von Fähren oder Rennbooten reicht. Ebenso sind wir mit 

Getrieben im Luftfahrtbereich präsent. 

Abbildung 2: 

Auf Grund des Produktspektrums ist die ZF in 6 Unternehmensbereiche strukturiert, die selbst 

in strategische Geschäftsfelder aufgeteilt sind, die sich auf bestimmte Produkte spezialisiert 

haben. Unsere Kunden sind aber nicht nur an Komponenten oder Einzelprodukten interessiert, 

sondern auch an Systemen, die sich aus einer Kombination unserer Produkte zusammensetzen. 

So bieten wir beispielsweise für Radlader nicht nur Getriebe, sondern auch Achsen und ein 

Driveline-Management an. Telemetriefähige Diagnosesysteme runden das Angebot ab. 

Ein anderes Beispiel stellen Stadtbusse dar, für die wir sowohl angetriebene wie auch nicht 

98


angetriebene Portalachsen anbieten, oder Vorderachsen mit verschiedenen Lenkwinkeln, sowie 

Getriebe und Lenkungen. 

Unsere Kunden, die Fahrzeughersteller als Fahrzeugspezialisten, verlagern bestimmte Aufgaben 

bei der Fahrzeugherstellung, die nicht zum Kerngeschäft des OEM gerechnet werden, wie 

etwa die Antriebstechnik an entsprechende spezialisierte Firmen, z. B. die ZF. 

Ähnlich verfährt die ZF als TIER 1-Supplier und bedient sich z.B. für die Lagertechnik (Kugellager, 

Radlager, etc.) entsprechender Spezialisten. 

Abbildung 3: 

99


Abbildung 4: 

Nachdem wir hohe technologische Ansprüche befriedigen müssen, fußen unsere Geschäfte oft 

auf Entwicklungspartnerschaften mit unseren Kunden, wie etwa im Off-Road-Bereich, Sektor 

Baumaschinen, mit John Deere für Baggerladerreihen, im Automotive-Bereich mit BMW, 

VW, Daimler-Chrysler wie auch mit anderen Kunden. Mehr als 50% unseres Umsatzes verdanken 

wir solchen Systemgeschäften, Tendenz steigend. 

Diese Partnerschaften sind charakterisiert durch intensive Kommunikation und Datenaustausch 

zwischen global agierenden Partnern. Regelmäßige Meetings ohne größere Zeitabstände 

halten in allen Ebenen alle Beteiligte informiert und bieten die Möglichkeit zum schnellen 

Eingreifen. Gemeinsam werden Projektunterlagen, Produktspezifikationen, Konstruktionen 

und Serienanläufe geplant. Inhalte sind konstruktive Elemente wie Bauräume und Festigkeiten, 

aber auch Qualitätselemente, Termine, Kalkulationen, ggf. Materialbezugsquellen, 

selbstverständlich Funktionalitäten und vieles mehr. 

Da bei Systemgeschäften viele Standorte und Entwickler betroffen sind, ist es notwendig, aber 

nicht hinreichend, nur systemtechnisch ein gutes Netzwerk zu haben. 

100


Abbildung 5: 

Wir verfügen weltweit über ein starkes Corporate Network, mit dem wir insbesondere unsere 

Entwickler aber auch alle Standorte technisch zusammengeschlossen haben. Wir legen großen 

Wert auf eine starke Securityinfrastruktur, die wir geschaffen haben. Dies beginnt mit zentralisierten 

Firewalls über die Zeitzonen und setzt sich fort mit zentralisierten Virenabwehrmaßnahmen, 

und der Implementierung eines CERT. 

Neben diesen technischen Rahmenbedingungen, die Voraussetzungen für Collaborative Engineering 

sind, werden zwingend Instrumentarien und Organisationen benötigt, die die Kommunikation 

zwischen den Partnern beschleunigen und unterstützen. Die Realisierung aller 

notwendigen Schnittstellen muss schnell und effizient erfolgen können. 

Collaborative Engineering ist keine verordnete Aktivität, sondern muss in einer Strategie unterstützt 

und entwickelt werden. Grundsätzlich sind 3 Ebenen zu unterscheiden, das Ausrichten 

auf die Kundenbedürfnisse, die Einbindung von Lieferanten und die unternehmensinterne 

Ausrichtung. 

3 Interne Zusammenarbeit 

Bei der internen Ausrichtung erschien es uns wichtig, Vertreter von Fachfunktionen mit geeigneten 

Informatikeinheiten zu verknüpfen. So wurden z. B. schon Mitte der 90er Jahre die 

Informatikeinheiten der ZF, die vordem einzelnen Standorten und Unternehmensbereichen 

zugeordnet waren, in eine ZF Informatik zusammengefasst. Dies geschah in der Form, dass in 

den Leitungsfunktionen der Informatik sowohl weltweite fachliche Verantwortungen für be- 

101


stimmte Informatikgebiete wie etwa Logistik, Engineering oder Ressourcenmanagement und 

– unternehmensbereichsbezogen - weltweite Verantwortung für die gesamte IT, auf jeweils 

gleiche Personen übertragen wurden. Es gelang, diese Organisation so zu gestalten, dass die 

Mitarbeiter in den ursprünglichen Standorten verbleiben konnten, und somit die interne Kundennähe, 

also die Nähe zu den Fachfunktionen, erhalten wurde. 

Abbildung 6: 

Zielsetzung dieser Matrixfunktion ist es, für das Gesamtunternehmen ZF profitable unternehmens- 

und geschäftsfeldübergreifende gemeinsame Abläufe zu finden. Diese sind so in Systemen 

abzubilden, dass alle eingebundenen Unternehmensbereiche und Geschäftsfelder Vorteile 

ziehen. Zu diesem Zweck wurden den Querschnittsfunktionen der Informatik starke Anwendungsvertretungen 

der Fachbereiche zur Seite gestellt. Insbesondere galt dies für die Entwickler, 

die entwicklungsnahen Fertigungsbereiche sowie die Informatikquerschnittsfunktion 

Engineering. Diese Strukturierung wurde durch Teamentwicklungen begleitet, denn das konstruktive 

Leben einer Matrix ist nicht per Order umsetzbar. Nur in auf echte Kooperation ausgerichteten 

Strukturen wird jede profitable Kooperationsmöglichkeit genutzt. 

Als wesentliches Ergebnis wurde eine breit getragene Einigung auf unternehmensübergreifende 

Standardsoftware und Standardabläufe erreicht. Zunächst wurde ein Corporate Software 

House festgelegt und somit definiert, mit welchen Applikationen Anwender unterstützt werden. 

In einem weiteren Schritt wurden die unternehmensübergreifenden Prozesse betrachtet. Insbesondere 

fiel in dem o.g. Team die Entscheidung, nicht nur ein gemeinsames Produktdaten- 

102


management-System im Gesamtunternehmen einzusetzen, sondern die wesentlichen Prozesse 

in diesem System gemeinsam abzubilden und zu nutzen. 

Hierbei handelt es sich um die Verwaltung der Modelle unserer strategischen CAD-Systeme, 

die zentrale Archivierung unseres gesamten Zeichnungsbestandes, die Unterlagenbereitstellung, 

die Verwaltung der Normen, den gesamten Datenaustausch inkl. aller Konvertierungen, 

den gesamten Änderungsprozess und die Security-Policy inkl. aller Zugangsberechtigungen. 

Das Datenmodell basiert auf dem STEP-Datenmodell AP214 . Grundsätzlich ist ZF ein Verfechter 

von neutralen Schnittstellen, wie alle Systemlieferanten. 

Die Inhouse-Nutzung von Online-Meetings und unserer Projektsysteme, um den Projektfortschritt 

zu messen, ist ebenfalls implementiert und wird stark genutzt. Hier darf nicht unerwähnt 

bleiben, dass wir selbstverständlich auch mit externen Partnern, also Partnern, die nicht 

im ZF Net angeschlossen sind, Online-Meetings praktizieren, hierzu aber Provider nutzen. 

Die Inhouse-Lösungen werden dann genutzt, wenn sich alle Teilnehmer innerhalb des ZF-Net 

befinden. 

Selbstverständlich gibt es auch fertigungsnahe Abläufe, die sehr eng mit der Entwicklung abgestimmt 

sein müssen. Hierzu gehört die Betriebsmittelkonstruktion, die Vorrichtungskonstruktion 

und die Verwaltung und Benummerung von Betriebsmitteln und Vorrichtungen. 

Auch für die Abbildung dieser Prozesse wird das gemeinsame Produktdatenmanagement- 

System genutzt. 

Das Benummerungssystem für Werkzeuge, also Bohrer, Schäfte und Kombinationen, etc., ist 

über alle Werke hinweg eindeutig und wird selbstverständlich nicht nur im Produktdatenmanagementsystem 

sondern auch in den Logistiksystemen genutzt. Hier arbeiteten wir im entsprechenden 

DIN-Ausschuß (DIN 4000) mit. 

Die Erfolge der Harmonisierung an sich und die Auswirkungen auf die Logistiksysteme implizieren 

positive Auswirkungen auf die Standardisierung wichtiger übergreifender Prozesse 

auch in Querschnittsfunktionen außerhalb des Engineering, wie z. B. in Materialwirtschaft, 

Einkauf, Montage und Fertigung. 

103


Abbildung 7: 

Der positive Einfluss wird noch verstärkt, wenn wir unser PDM-Teilprojekt „Konzerneinheitliche 

Strukturstückliste“ und einheitlicher Materialstamm zur Gänze umgesetzt haben. Selbstverständlich 

gibt es auch eine Brücke, die die notwendigen Informationen des Produkt-Daten- 

Managementsystems in die SAP-Systeme übersetzt. 

Weltweit haben wir über 6000 PDM-Nutzer angeschlossen. Dies sind wesentlich mehr Nutzer 

als wir Entwickler haben und zeigt, dass das PDM-System weltweit von mehr Fachfunktionen 

als „nur“ den Entwicklern genutzt wird, z.B. von Fertigungsvorbereitungsbereichen aber auch 

von Einkäufern. Wir haben den Grundsatz, dass verbindliche Dokumente nur einmal gespeichert 

werden. Insbesondere Modelle und Zeichnungen sind solche Dokumente. Deswegen 

sorgen wir dafür, dass aus allen Systemen und Prozessen, in denen verbindliche im PDM gespeicherte 

Dokumente benötigt werden, auch ins PDM-System durchgegriffen werden kann. 

Die Wahrung der Security-Policy ist selbstverständlich. Insgesamt erleben wir hier, dass Metcalfe’s 

Law „der Nutzen eines Systems steigt quadratisch mit der Anzahl der Nutzer“ absolut 

richtig ist. Alle notwendigen Informationen sind konsistent im System gespeichert und online 

abrufbar. Im Umkehrschluss wird hierdurch die notwendige Verfügbarkeit des Systems klar 

definiert, nämlich 7x24 h. 

Dieses Produktdatenmanagement ist ZF-weit einheitlich, da es keine unterschiedlichen Steuerungen 

der Entwicklungstätigkeiten in den Werken gibt. Aber Metcalfe’s Law und Standardisierung 

sind nicht die obersten Paradigmen. Die ZF hat z.B. vor zwei Jahren Sachs gekauft. 

Dort gab es auch ein weltweites Produktdatenmanagementsystem. Zu diesem haben wir eine 

gut funktionierende Online-Schnittstelle aufgebaut. Dies war auf Grund der ähnlichen Entwicklungsprozesse 

die wirtschaftlichste Lösung. 

104


Abbildung 8: 

4 Zusammenarbeit mit Zulieferern 

Sicher lassen in einer geeigneten Matrixorganisation Standardisierungen von Systemen und/ 

oder Schnittstellen mit geringsten Widerständen realisieren, wenn, neben der Überzeugung 

der internen Partner, auch die kapitalmässige und rechtliche Hoheit gegeben ist. Dies ist bei 

Kunden und Lieferanten definitiv nicht der Fall. 

Kunden und Lieferanten verfügen über eigene Systeme, eigene Organisationen und eigene 

Kulturen. Deswegen ist es notwendig, auch über Instrumentarien zu verfügen, die es gestatten, 

diese unterschiedlichen Strukturen und Systeme in Einklang zu bringen. Wichtig sind die 

Ergebnisse zur Erreichung der gemeinsamen Projektziele. Nicht Gleichheit, sondern Gleichklang 

ist wichtig. 

Hierin begründet sich die Grundsatzentscheidung der ZF, zusammen mit weiteren Anteilseignern 

- Bosch, Continental, SAP, Siemens, VDO, ZF - den elektronischen Marktplatz Supply- 

On zu gründen. 

Der Marktplatz hat den Fokus, die Prozesse zwischen den Lieferanten und den Anteilseignern 

zu vereinfachen. Begonnen wurde mit den Beschaffungs-und Logistikbereichen. 

Inzwischen ist das Portfolio erweitert um Funktionen der Qualität, des Finanzwesens und des 

Collaborative Engineering. CAD-Conversion, Normenverwaltungen, Zeichnungen können 

gehandelt werden. Project Folders stehen ebenfalls zur Verfügung, Online Meetings könen 

gebucht werden. 

105


Abbildung 9: 

106


Abbildung 10: 

Auch dieser Marktplatz entwickelt sich gut, wie man dem beachtlichen Zuwachs an Marktplatzkunden 

(also unseren Lieferanten) entnehmen kann. Diese Funktionalitäten motivierten 

uns, den Workflow zwischen Giessereien und ZF in dem Projekt KOEFFIZIENT, das uns in einem 

späteren Vortrag vorgestellt wird, über die Anbindung dieses Marktplatzes zu realisieren. 

Wesentlicher Bestandteil dieses Projektes ist es, in einem Vorgang Anfrage und/oder Angebot 

und/oder Bestellung automatisch mit dem zugrunde liegenden technischen Dokumentationen 

(also auch CAD-Modelle) zu verbinden. 

Letztendlich ist es Ziel, spezialisierten Unternehmen die Möglichkeit zu geben, zeitnahe Leistungen 

abzuliefern, damit höhere Reaktionsgeschwindigkeiten für alle zu erreichen und letztendlich 

die Kosten zu senken. 

5 Zusammenarbeit mit den Kunden und Gesamtkonzept 

Kunden haben, wie schon erwähnt, eigene Organisationen, eigene Systeme, eigene Kulturen. 

Oft gibt es kundeneigene Portale. Für diese Prozesse zum Kunden wurde über das Global 

eBusiness Team der ZF zentral ein Ablauf realisiert, der es ermöglicht, die Zugänge der ZF- 

Mitarbeiter zu Kundenportalen transparent und zeitnah zu managen. Es ist in beiderseitigem 

Interesse, dass auf diesen Portalen nur autorisierte Mitarbeiter mit den jeweiligen Portalfunktionen 

arbeiten und diese gegenseitig aktuell gehalten werden. 

Dazu ist erst kürzlich ein neuer europäischer Standard für das Usermanagement auf Internetportalen 

veröffentlicht worden, der unter Federführung der ZF erarbeitet wurde. 

107


Abbildung 11: 

Betrachtet man die Komplexität, die sich für ein Unternehmen wie ZF durch die Vielzahl der 

Portale, ihrer Anwendungen und der betroffenen ZF-Mitarbeiter ergibt, wird schnell klar, dass 

eine starke Koordination und klare Regeln notwendig sind, um den administrativen Aufwand 

auf ein erträgliches Maß zu reduzieren. Dank klarer Abläufe, die auch im ZF PortalManager© 

automatisiert sind, konnte dieses Ziel erreicht werden. 

108


Abbildung 12: 

Alle vorgenannten Aspekte wurden ZF intern zu einem Gesamtkonzept zusammengeführt, das 

insbesondere, aber nicht nur, das Collaborative Engineering unterstützt. Intern verfolgen wir 

Standardisierungsstrategien bzgl. der technischen Infrastruktur, Harmonisierungsstrategienbezogen 

auf die Prozesse, extern arbeiten wir über SupplyOn und/oder mit OEM-Portalen. Ebenso 

engagieren wir uns in Gremien um den neutralen Datenaustausch weiterzubringen 

(STEP, AP214). 

Der Kunde steht bei uns im Vordergrund. Deswegen bieten wir unseren Kunden, neben unseren 

Produkten und Systemen, die gesamten Serviceleistungen unserer internen Prozesse, um 

alle notwendigen Schnittstellen effizient handeln zu können. 

Wir sind de facto nicht nur Produktlieferant, sondern auch Datenlieferant. 

6 Zukunft 

Wir glauben, Kernkompetenz als „Supervisor der Wertschöpfungskette“ ist ein wesentlicher 

Erfolgsfaktor von Unternehmen. Unternehmen verändern sich im Wettbewerb rasend schnell, 

verändern Schwerpunkte und konzentrieren sich auf Kerngeschäfte. Deswegen wird die Vernetzung 

der Unternehmen untereinander stark wachsen, die Bindungen in Prozessen werden 

möglicherweise stärker werden und es wird immer mehr notwendig werden, in Kooperationen 

zu arbeiten. Es gibt meines Wissens nach keinen Automobilhersteller, der die Präsentation 

neuer Modelle der eigenen Marketing-Abteilung überlässt. Eigenentwicklung bzgl. Fahrzeugbeleuchtung 

gibt es nicht. Der Opel Zafira wurde - auf der bestehenden Astra-Plattform- von 

Porsche entwickelt. 

109


Abbildung 13: 

Deswegen ist es notwendig, in Unternehmensnetzwerken und Kooperationen erfolgreich zu 

agieren, die Informationen zu organisieren und Sorge für die Stabilisierung der Beziehungen 

zu tragen. Es werden virtuelle Firmen entlang der gesamten Herstellkette entstehen. Ein Unternehmen 

muss dafür Sorge tragen, dass die starke Bindung zwischen Firmen über die Zusammenarbeit 

in den Prozessen nicht die Bindung im eigenen Unternehmen zu stark aufweicht. 

Es ist nämlich zu vermuten, dass unternehmerische Bindungen sich dahin entwickeln 

werden, wohin die sozialen Bindungen derzeit schon tendieren, nämlich mehr temporäre Liebesbeziehungen 

anstatt dauerhafte Ehe. In der Zusammenarbeit mit Unternehmen ist eine hohe 

persönliche Mobilität der Mitarbeiter notwendig, da zum einen Projekte häufig wechseln, 

zum anderen auch Mitarbeiter zumindest zwischen Projektgruppen wechseln werden. Somit 

ist es notwendig, nicht nur Wissen zu haben, sondern zu wissen, wo Wissen zu finden ist. Der 

Umgang mit den zur Verfügung stehenden Medien wird zunehmend zum Erfolgsfaktor sowohl 

für die Person als auch für das Unternehmen. 

Der Aufwand, um an das benötigte Wissen zu gelangen, wird sehr entscheidend werden. Das 

Informieren über formelle Kanäle ist in der Regel aufwändiger, als einen Experten direkt per 

Telefon, Mail, Online-Meeting oder persönlich zu befragen. Personen und Institutionen werden 

sich als Benutzer eines wissensvermittelnden Systems verstehen. 

Sie werden sich somit die Kanäle aussuchen, über die ihre Informationsbedürfnisse am effektivsten 

befriedigt werden können. 

110


Deswegen wird es entscheidend sein, die Informierungsvorgänge zu rationalisieren und effektiv 

zu gestalten, selbstverständlich unter Wahrung der Intellectual Property. 

111


7 Engelmann 

Wissensmanagement in der Produktentwicklung 

KAI ENGELMANN 

Eine immer weiter voranschreitende Globalisierung verschärft den Wettbewerb weltweit und 

setzt die Industrie und die Dienstleistungsanbieter einem stetig wachsenden Innovationsdruck 

aus. Um den Anschluss an die Konkurrenz nicht zu verlieren, müssen die Produktentwicklungszeiten, 

bei gleichzeitiger Verbesserung der Qualität der angebotenen Produkte, deutlich 

verkürzt werden. Denn nur innovative und gleichzeitig kostengünstige Produkte sind global 

wettbewerbsfähig und ermöglichen es, Vorteile im Wettbewerb zu halten oder gar auszubauen. 

Schnelligkeit in der Produktentwicklung ist somit ein bedeutsamer, wenn nicht gar der entscheidende 

Wettbewerbsfaktor. 

Aus unternehmerischer Perspektive betrachtet ist ein effektiver und effizienter Produktentwicklungsprozess 

langfristig der wichtigste Hebel zur Befriedigung der Forderungen von 

Markt, Eigentümern und Mitarbeitern. In einem Umfeld in dem Kostensenkungsmaßnahmen 

bei den meisten Unternehmen zum größten Teil ausgereizt sind, steigert allein eine höhere Innovationsfähigkeit 

Wachstum und Profitabilität und damit den Unternehmenswert. 

Eine Beschleunigung des Innovationsprozesses lässt sich durch eine systematische Nutzung 

und Vernetzung sämtlicher Ideenpotenziale und Know-how Quellen des Unternehmens erreichen. 

Eine Konsequenz daraus ist, dass das Wissen über das Produkt und seine Entstehung als 

wertvollste Ressource eines Unternehmens stärker und vor allem schneller Anwendung innerhalb 

des Unternehmens während des gesamten Produktlebenszyklus finden muss. Eine effiziente 

und effektive, also zukunftsorientierte, Produktentwicklung berücksichtigt die folgenden 

Faktoren: 

1. Konsequente Ausrichtung auf den Markt 

2. Optimierung von Zeit und Kosten durch integrierte Prozesse (immer den Gesamtprozess 

im Blick) 

3. Zielgerichtete Einbeziehung der Mitarbeiter und ihres spezifischen Wissens (Kompetenz 

und Kreativität) in den Prozess 

4. Einsatz von integrierten, den gesamten Geschäftsprozess unterstützenden, Wissensmanagementsystemen 

Mit Hilfe der Prozessorientierung wird der Informationsfluss entlang des Produktlebenszyklus 

kanalisiert. Der unternehmensinterne Informationsfluss wird zu einem geschlossenen Kreislauf 

integriert und ermöglicht so die Einbeziehung von Erfahrungen aus den Produktlebenszyklen 

vorangegangener Produkte und verbessert so die marktorientierte Entwicklung neuer 

Produkte. Zyklusübergreifend könnten auch noch Informationen extern auf Seiten der Kunden 

abgefragt und in den Prozess integriert werden. 

Die Firma Roland Berger Strategy Consultants, als Unternehmensberatung ein typischer Vertreter 

eines Dienstleistungsunternehmens, hat sich mit dieser Thematik in den letzten Jahren 

intensiv beschäftigt. Ausgangspunkt der Überlegungen war, dass Dienstleistungen genauso 

als Produkte zu betrachten sind wie Sachgüter oder Software und somit entsprechend entwickelt 

und vermarktet werden können. Die Abgrenzung wie aber auch die Ähnlichkeit zum 

Produkt-Engineering zeigt sich in der Dualität von "High Tech" und "High Touch" in der 

113

Wissensmanagement in der Produktentwicklung 

Dienstleistungsentwicklung. "High Tech", gemeint im Sinne von übertragbaren Aktivitäten 

im Bereich der Entwicklung von Vorgehensmodellen und in der Produkt- und Prozessmodellierung. 

"High Touch", gemeint im Sinne einer deutlichen Differenzierung über die Fokussierung 

auf Human-Ressourcen, im Entstehungsprozess, wie aber auch in der Gestaltung von 

Kundenschnittstellen. Dabei ist die Berücksichtigung emotionaler Aspekte in der Entwicklung 

einer Dienstleistung nicht zu vernachlässigen. Grundsätzlich ist jedoch, ganz im Gegensatz 

zum Produkt-Engineering, das Ergebnis eines Beratungsprojektes immer ein immaterielles 

Produkt. 

Die zentralen Leistungen, die in den Beratungsprozess eingehen, sind die individuellen Kompetenzen 

der Mitarbeiter und die organisationalen Kompetenzen des Unternehmens. Diese 

Kompetenzen werden durch ein Beratungsprojekt in Problemlösungen transformiert. Aufgrund 

dieser Besonderheit von Beratungsprojekten sind Kompetenzen die Grundlage für die 

Generierung und Erhaltung von Wettbewerbsvorteilen für ein Beratungsunternehmen. Daher 

besteht Bedarf für Methoden zur Identifikation, Entwicklung, Formalisierung, Speicherung, 

Nutzbarmachung, den Transfer und den Schutz von Wissen. Roland Berger hat diesen Anforderungen 

genüge getan und mit integrierten Management-Tools den gesamten Beratungsprozess 

im Knowledgemanagementsystem BRAIN abgebildet. 

114

Teil 3: 

Erfahrungsberichte aus 

den Verbundprojekten 

GINA, KOEFFIZIENT und KOWIEN 

8 Teil 3 

115


Controlling im Innovationsprozeß der Reifenentwicklung 

– ein Praxisbericht der Continental AG 

9 multhaupt 

MARKO MULTHAUPT 

117

Controlling im Innovationsprozeß der Reifenentwicklung – ein Praxisbericht der Continental AG 

118


119


120


121


122


123


124


125


126


10 decker 

Wie die DESMA Schuhmaschinen GmbH 

ihren Innovationsprozess optimiert hat 

CHRISTIAN DECKER 

Zusammenfassung: Als ein Unternehmen des deutschen Maschinen- und Anlagenbaus sieht sich 

die Firma Klöckner DESMA Schuhmaschinen GmbH mit einem Weltmarkt konfrontiert, auf dem 

stagnierende oder sogar teilweise sinkende Umsätze zu beobachten sind. Aufgrund der Kostenstruktur 

am Standort Deutschland und der nur eingeschränkten Möglichkeiten eines mittelständischen 

Unternehmens zur Verlagerung von arbeitsintensiven Tätigkeiten ins Ausland ist die Firma 

DESMA gezwungen, durch technologisch hervorragende und innovative Produkte komparative 

Kundenvorteile zu erzielen. Dabei müssen die Kundenwünsche hinreichend bekannt sein, um auch 

eine Übererfüllung des Produktes („Overengineering“) zu vermeiden. Im dem vom Bundesministerium 

für Bildung und Forschung geförderten Projekt GINA wurde in enger Kooperation mit der 

TU Braunschweig das Innovationsmanagement analysiert und optimiert. Dieser Beitrag stellt das 

gewählte Vorgehen vor und kann in zwei Teile untergliedert werden. Der erste Teil widmet sich 

der Analysemethodik, der zweite Teil beschreibt die durchgeführten Optimierungsmaßnahmen. 

1 Einleitung 

Der Maschinen- und Anlagenbau gilt als einer der wichtigsten Wirtschaftsbranchen in der 

Bundesrepublik Deutschland. Er beschäftigte im Jahr 2003 885.000 Mitarbeiter, die einen 

Umsatz von ca. 132 Mrd. Euro erwirtschafteten. Der Gewinnanteil am Umsatz ist im Vergleich 

zu anderen Branchen relativ gering; die Umsatzrendite betrug im Jahr 2003 3,4 % 

[Mer03]. Der Maschinen- und Anlagenbau ist ein forschungsintensiver Wirtschaftszweig, der 

ca. 4 Mrd. Euro oder 3,1% des Umsatzes in Forschung und Entwicklung investiert [Gre03]. In 

den letzten Jahren ist allerdings ein Rückgang der F&E-Ausgaben zu beobachten, was mit Finanzierungsengpässen 

und Facharbeitermangel erklärt werden kann [ZEW03]. 

Im Gegensatz zu konsumorientierten Produkten beliefern Unternehmen des Maschinen- und 

Anlagenbaus keinen anonymen Massenmarkt sondern bekannte Einzelkunden mit kundenindividuellen 

Produkten. Da die Binnennachfrage begrenzt ist, sind Unternehmen dieser Branchen 

in der Regel international tätig und bearbeiten den globalen Markt. 

Die Firma Klöckner DESMA Schuhmaschinen GmbH muss sich diesen wirtschaftlichen 

Rahmenbedingungen stellen. Als Hersteller von Schuhmaschinen bedient sie Märkte mit 

stagnierenden oder sogar rückläufigen Umsatzzahlen. Aufgrund der hohen Kostenstrukturen 

am Standort Deutschland hat DESMA in der Vergangenheit Differenzierungsstrategien angewendet 

und entwickelte technologisch hochwertige Produkte, die allerdings nur in Nischenmärkten 

vermarktet werden können. DESMA gilt als Technologieführer in der Branche, was 

aber nur mit ständigem Streben nach Innovationen aufrecht erhalten werden kann. Im Rahmen 

des Projektes GINA war es das Ziel, die Innovationsfähigkeit des Unternehmens zu steigern. 

Dazu sollten im Rahmen einer Schwachstellenanalyse mit Hilfe des im Projekt entwickelten 

Softwarewerkzeuges IMPACT Innovationspotentiale identifiziert werden und in einer anschließenden 

Optimierungsphase die Potentiale erschlossen werden. 

127

Wie die DESMA Schuhmaschinen GmbH ihren Innovationsprozess optimiert hat 

2 Analyse von Innovationsprozessen 

Im Rahmen des Projektes wurde mit dem Softwarewerkzeug ImpACT ein Hilfsmittel für die 

Bewertung und Analyse von Innovationsprozessen geschaffen. Das in Zusammenarbeit mit 

dem mittelständischen Softwareentwickler SBS Softwaresysteme in Braunschweig entwickelte 

Werkzeug systematisiert und unterstützt die Auditierung von Innovationsprozessen und 

stellt Funktionalitäten für die Auditvorbereitung, die Datenerhebung sowie die Auswertung 

der Auditergebnisse zur Verfügung. Zusätzlich zeigt die Software durch die Visualisierung 

der Auditergebnisse Ansatzpunkte für Verbesserungsmaßnahmen auf und unterstützt deren 

Implementierung durch die Bereitstellung von maßnahmenbezogenem Wissen. Die Abbildung 

1 zeigt die bisher mit dem Softwarewerkzeug realisierten sechs Analyseschritte von der 

„Festlegung der Zielsetzung“ bis „Auswertung der Daten“. 

Ergebnisdarstellung 

Ergebnisportfolio 

Wissensspeicher 

Fallbeispiele 

ImpACT 

Referenzprozesse 

VDI- 

Richtlinien 

128 

unternehmensspezifischer 

Innovationsprozess 

1 

2 

3 

4 

5 

6 

7 

Festlegung der 

Zielsetzung 

Anlegen von 

Stammdaten 

Selektion der 

Bewertungskriterien 

Datenerhebung 

(Interviews, 

Dokumentanalyse) 

Eingabe der 

Bewertungsdaten 

Auswertung der 

Daten 

Bereitstellung von 

Wissen zur 

Prozessoptimierung 

Auditor 

konkrete Maßnahmen zur Verbesserung 

des Innovationsprozesses 

Abbildung 1: Ablauf der Bewertung von Innovationsprozessen 

mit Hilfe des Werkzeuges ImpACT


Der erste Analyseschritt umfasst die Festlegung der Zielsetzung der Untersuchung. Insbesondere 

muss festgelegt werden, welche Teilprozesse des Innovationsprozesses in die Untersuchung 

miteinbezogen werden, welche organisatorischen Bereiche des Unternehmens analysiert 

werden und wie die Untersuchung organisatorisch (z.B. Interviewpartner, Dokumentation, 

etc.) durchgeführt werden soll. Der zweite Schritt ist die Ablage von Stammdaten im 

Werkzeug, d.h. die Ablage von Unternehmensstammdaten wie Adresse, Name und Telefonnummer 

der Interviewpartner, aber auch betriebswirtschaftliche und organisatorische Kriterien 

wie Umsatzanteil der Neuprodukte, Gewinn oder Mitarbeiteranzahl im Bereich Forschung 

und Entwicklung. Im nächsten Schritt sind die Bewertungskriterien zu selektieren. Im 

Werkzeug sind 110 Bewertungskriterien in einem hierarchischen Bewertungsmodell abgelegt, 

von denen eine Teilmenge oder auch das gesamte Kriterienmodell für die Analyse verwendet 

werden können. Die Aufnahme von Daten, die für die Bewertung der Ausprägung eines Bewertungskriteriums 

notwendig sind, erfolgt im Rahmen von Interviews und Beobachtungsanalysen. 

Zur Unterstützung werden vom Werkzeug ImpACT Checklisten abhängig von den 

selektierten Bewertungskriterien dynamisch generiert und dem Anwender zur Verfügung gestellt. 

Nach der Datenaufnahme erfolgt die Eingabe der Bewertungsdaten mit Hilfe einer Eingabemaske 

in das System. Die Auswertung und die Darstellung des Ergebnisses werden mit 

Hilfe von Matrix- und Balkendiagrammen durchgeführt und dem Benutzer über ein Auswertungsmodul 

dargestellt. Während die Schritte 1 bis 6 die Analyse von Stärken und Schwächen 

des betrieblichen Innovationsprozesses als Ziel haben, wird im Schritt 7 problem- und schwächenspezifisches 

Lösungswissen in Form von Fallbeispielen, Referenzprozessen und weiterführenden 

Literaturhinweisen wie VDI-Richtlinien bereitgestellt. Die Umsetzung der Unterstützung 

der Analyseschritte erfolgt mit Hilfe einer Internetlösung (www.gina-net.de/impact); 

die Bereitstellung des Lösungswissens wird mit einer MS-Access Datenbank realisiert. 

3 Analyseergebnisse im Innovationsprozess 

Im Rahmen der Analysephase kamen alle 110 Bewertungskriterien zur Anwendung. Das Kriterienmodell 

von IMPACT wurde noch durch DESMA-spezifische Bewertungskriterien ergänzt. 

Die Abbildung 2 zeigt Teile der Ergebnisse mit Hilfe einer Bewertungsmatrix. 

129

Relevanz für das Unternehmen 

4 

2 

Bereich hoher 

Dringlichkeit 


10 

Bereich ohne 

Dringlichkeit 

8 

9 

6 

11 

Bereich mittlerer 

Dringlichkeit 

3 

17 

0 0 2 4 

Ausprägung im Unternehmen 

2 

4 

7 

12 

15 

5 

14 

13,16 

Bereich mittlerer 

Dringlichkeit 

1 

Bereich hoher 

Dringlichkeit 

Abbildung 2: Bewertungsportfolio der Firma DESMA 

130 

1 Mitarbeiterquantität 

2 Mitarbeiterqualität 

3 interne Kommunikation 

4 Kunden/Lieferanteneinbindung 

5 Unternehmensorganisation 

6 Marktkenntnisse 

7 Standardisierung 

8 Innovationscontrolling 

9 Auftragsklärung 

10 Offensives Marketing 

11 Analyse von Chancen 

und Risiken 

12 Innovationsorientiertes 

Managementsystem 

13 Vorhandensein von Innovatorenpersönlichkeiten 

14 Innovationsförderliche 

Unternehmenskultur 

15 Aufbau & Entwicklung von 

Kernkompetenzen 

16 Schützen von Know-How 

und Wissen 

17 Projektmanagement 

Mittels der Bewertungsmatrix wird die Ausprägung eines Bewertungskriteriums, also hier die 

qualitative Bewertung eines Faktors durch einen Auditor, der Relevanz des Bewertungskriteriums 

gegenübergestellt. Die Relevanz entspricht der Gewichtung eines Bewertungsfaktors. 

Aus dieser Gegenüberstellung ergeben sich vier Möglichkeiten: das Bewertungskriterium ist 

ein unwesentliches, ein übererfülltes, ein kritisches oder ein maßgebliches Bewertungskriterium. 

Bei der Entwicklung von Optimierungsmaßnahmen sollten insbesondere die übererfüllten 

und kritischen Bewertungskriterien in den Fokus gestellt werden. Bei übererfüllten Bewertungskriterien 

kann die Schlussfolgerung abgeleitet werden, dass zu viele Ressourcen für diesen 

Faktor verwendet werden. Bei kritischen Bewertungskriterien sind Maßnahmen zu ergreifen, 

um die Ausprägung des Bewertungskriteriums zu verbessern. Für die Firma wurden insbesondere 

die Faktoren Auftragsklärung, offensives Marketing, Marktkenntnisse, interne 

Kommunikation, Innovationscontrolling und Analyse von Chancen und Risiken als kritisch 

bewertet. Auf Basis dieser Ergebnisse und weitere Detailanalysen wurden folgende Optimierungsmaßnahmen 

beschlossen und umgesetzt: 

• Definition eines Produktplanungsprozesses, 

• Verbesserung der Methodenunterstützung im Produktplanungsprozess, insbesondere für 

die Analyse von Chancen und Risiken am Markt sowie 

• Optimierung des Projektcontrolling.


4 Optimierungsmaßnahmen im Innovationsprozess 

4.1 Definition eines Produktplanungsprozesses 

Eine der wichtigsten Verbesserungsmaßnahmen war die Definition eines Produktplanungsprozesses. 

Sowohl in der betriebswirtschaftlichen als auch in der ingenieurswissenschaftlichen 

Literatur stehen Phasenmodelle zur Verfügung, die einen zielgerichteten Ablaufplan für 

die Entwicklung neuer Produkte von der Zielbildung bis zur Kontrolle bereitstellen.[Gau01] 

[Kra97] [Eve03] [VDI2220]. Ebenfalls erfolgt in der Literatur eine ausführliche Diskussion, 

wie der Innovationsprozess durch Instrumente und Methoden unterstützt werden kann. Die 

Abbildung 3 gibt einen Überblick über bestehende Ansätze und strukturiert die Phasenansätze 

dabei am Phasenablauf der strategischen Planung. 

Zielfindung 

strategische 

Analyse 

Strategieformulierung 

Strategieimplementierung 

Strategiekontrolle 

Strategische 

Produktplanung nach 

Gausemeier 

Potentialfindung 

Erfolgspotentiale und 

Handlungsoptionen der 

Zukunft finden 

Produktfindung 

•Produkt- und ggf. 

Dienstleitungsideen 

•Produktanforderungen 

Geschäftsplanung 

•Produkt- und ggf. 

Dienstleitungsideen 

•Produktanforderungen 

Strategiekontrolle 

•strategische Fühaufklärung 

•Umsetzungkontrolle 


VDI 2220 

Analyse 

•Informationen aus Markt 

und Umwelt 

•Informationen aus dem 

Unternehmen 

Produktfindung 

•Suchen und Sammeln von 

Produktideen 

•Ideenselektion 

•Produktdefinition 

ProduktplanungsProduktplanungsProduktplanungsverfolgung 

Produktkontrolle 



131 


Kramer 

Analyse 

•Analyse des Umfeldes, 

des Wettbewerbs, der 

Abnehmer 

•Bewertung von Produkten, 

Märkten 

•strateg. Ausgangslage 

Strategien 

• Strategien vorgeben, 

entwickeln, selektieren und 

durchsetzen 

Produktplanung 

•Suchfelder erschließen 

•Ideensuche 

•Ideenbewertung,-selektion 

•Produktvorschläge 

konzipieren 

Verfolgung/ 

Überwachung 

•Frühwarnsysteme 

•Absatz-, Kosten- und 

Leistungskontrolle der 

einzelnen Produkte 

IRM-Methodik nach 

Eversheim 

Zielbildung 

•Ableitung von 

Innovationszielen und 

Aufgaben 

Zukunftsprognose 

•Ermittlung zukünftiger 

Anforderungen 

•Ermittlung von Chancen und 

Risiken, Stärken und 

Schwächen 

Ideenfindung 

Ideenbewertung 

Ideendetaillierung 

Konzeptbewertung 

Umsetzungsplanung 

•Einordnung von F&E- 

Projekten auf einen Zeitstrahl 

•Ableitung von 

Umsetzungsaktivitäten 

Abbildung 2: Überblick über Phasenansätze zur strategischen Produktplanung 

Auf Basis der Literaturanalyse und mehrerer Workshops mit den Führungskräften wurde ein 

DESMA-spezifischer Produktplanungsprozess definiert und umgesetzt (Abbildung 2). Jedes 

Innovationsprojekt beginnt mit einer Idee, und so ist der Zweck des Ideenfindungsprozess eine 

möglichst hohe Anzahl von Projektideen zu generieren. Aufgrund der hohen Auftragsorientierung 

der Entwicklungsabteilung kann der Anstoss für eine neue Idee sowohl intern aber


auch extern im Rahmen einer der Kundenanfragen erfolgen. Jeder Mitarbeiter ist aufgefordert, 

durch die Entwicklung neuer Ideen die Zukunft des Unternehmens zu sichern; die Verantwortung 

für den Prozess liegt aber bei den Führungskräften. 

Wenn mehrere Ideen gefunden sind, ist die am besten geeignete Idee auszuwählen. Dieses 

setzt einen Bewertungsschritt voraus. Eine Bewertung ist „die Ermittlung und Beurteilung des 

Grades der Erfüllung vorgegebener Zielstellung für ein bestimmtes Bewertungsobjekt, um 

Entscheidungen im Innovationsprozess treffen zu können“ [Ple96]. Ein Bewertungsobjekt 

kann eine Produktidee aber auch ein Entwicklungszwischenergebnis sein. Aufgrund von relativ 

unsicheren Daten empfiehlt es sich, den Bewertungsprozess in mehreren Stufen zu durchlaufen 

[Ges92]. In der ersten Auswahlstufe werden die Ideen auf Mindestbedingungen oder so 

genannten KO-Kriterien überprüft. In der nächsten Auswahlstufe werden die erfolgsversprechendsten 

Ideen ausgesucht. Dafür eignen sich insbesondere qualitative Bewertungsverfahren 

wie die Nutzwertanalyse [Zan70] [Spe01]. Die Definition von Kriterien für die Nutzwertanalyse 

sollte in der Regel vor dem unternehmenspezifischen Kontext erfolgen. Allgemeingültige 

Kirtierenmodelle für den 2. Auswahlschritt finden sich bei [Wie76] [Bur87] [Ple96] [Bro94]. 

Die Firma DESMA verwendet dazu folgende Kriterien. 

Gruppe Bewertungskriterium Erklärung 

Marktsicht Kundennutzen Kann mit dem Projekt ein Nutzen für den Kunden hinsichtlich 

Kosten, Qualität und Effizienz erzielt werden? 

Marktpotential Wie groß ist das Anwendungspotential? Ist die Entwicklung 

für möglichst viele Kunden attraktiv? 

Vorsprung zum Wettbewerb Kann mit der Entwicklung ein deutlicher Vorsprung zum 

Wettbewerb hinsichtlich Kosten, Qualität und Effizienz erzielt 

werden? 

Technologiesicht Kernkompetenz Betrifft die Entwicklung eine Kernkompetenz von DES- 

MA, die auch zukünftig als wichtig angesehen wird? 

Betriebswirtschaftliche Sicht Produktions- und Entwicklungsauslastung 

Technische Machbarkeit Ist die Entwicklung technisch realisierbar? 

Strategiekonformität Passt die Entwicklung zur Innovationsstrategie, die im Strategieprozess 

(DP 1) formuliert wurde? 

132 

Sind die Entwicklung und die Produktion zur Zeit ausreichend 

ausgelastet oder sind noch freie Kapazitäten einzuplanen? 

Entwicklungsaufwand Ist der Entwicklungsaufwand in einem vertretbaren Umfang? 

Return on Invest Kann ein schneller Rückfluss des eingesetzten Kapitals realisiert 

werden? 

Tabelle 1: Bewertungskriterien für Innovationskriterien der Firma DESMA


Sowohl die Durchführung der Bewertung als auch die Entscheidung, ob eine Projektidee in 

ein Entwicklungsprojekt überführt wird, liegt beim Steuerungskomitee. Abgelehnte oder zurückgestellte 

Ideen werden in einem Ideenpool abgespeichert. Auch laufende Entwicklungsprojekte 

sollten in regelmäßigen Abständen einer Bewertung unterzogen werden. 

Kundenauftrag 

auftragsneutrale 

Projektideen 

Strategiefindungsprozess 

(DP 2) 

Strategiekonformität 

Bewertung der 

Projektideen 

abgelehnte oder 

zurück-gestellte 

Ideen 

Ideenpool 

Steuerungs 

-komitee 

Auflassung von 

Projekten 

133 

•SAP-Nr. 

•Projektbudget 

•Projektzeitplan 

Planung des 

Projektes 

Aufgabenklärung 

Steuerung des 

Projektes 

Ideenfindung 

Ideenfindung Ideenbewertung Projektplanung und -durchführung 

Steuerungs 

-komitee 

Funktionsgestaltung 

Konstruktionsprozess 

Abbildung 4: Überblick über den Produktplanungsprozess bei DESMA 

Produktgestaltung 

Zu Beginn eines Entwicklungsprojektes erfolgt die Detailplanung des Projektes. Dazu wird 

zunächst ein verantwortlicher Projektleiter benannt, der eine Zeitplanung mit wichtigen Meilensteinen 

erstellt. Weiterhin werden die Entwicklungskosten geplant (z.B. Arbeitsstunden im 

Konstruktionsbüro, Aufwand des Technikums, externe Dienstleistung). Die Planung wird 

vom Steuerungskomitee abschließend genehmigt und ein Budget für das Entwicklungsprojekt 

in das SAP-System eingestellt. Die Projektsteuerung dient der Überprüfung des Fortschritts 

des Entwicklungsprojektes hinsichtlich der Projektplanung und der Ergreifung von Steuerungsmaßnahmen. 

Dazu sollte der Leiter eines Entwicklungsprojektes zu wichtigen Meilensteinen 

dem Steuerungskomitee den Fortschritt im Entwicklungsprojekt darlegen. Für die Übersicht 

über alle Entwicklungsprojekte wird eine Projektroadmap erstellt, die allen Führungskräften 

im Unternehmen zur Verfügung gestellt wird. 

4.2 Optimierung des Methodeneinsatzes in der Produktplanung 

Die systematische Planung von Produktstrategien ist entscheidend, um den zunehmenden 

Konkurrenzdruck entgegenwirken zu können. Hierbei spielt u.a. die Ermittlung von Anforderungen 

an zukünftige Produkte eine zentrale Rolle, die die Basis für eine Produktstrategie bilden. 

In der industriellen Praxis ist jedoch zu beobachten, dass hierbei kaum strukturiert vorgegangen 

wird, sondern dass vielmehr Entscheidungsprozesse aus dem „Bauch“ heraus stattfinden 

und weniger auf Basis fundierter Analysen. Empirische Untersuchungen haben gezeigt, 

dass in der Praxis multiple Methoden für Produktentwicklungen nur zögerlich einge-


setzt werden, obwohl deren Bedeutung für das Innovationsvermögen bekannt ist [Gau2001]. 

Einerseits wird das methodische, systematische Vorgehen als eine Grundvoraussetzung für 

ein effizientes Erreichen von Zielen anerkannt, andererseits wird in der Praxis kaum davon 

Gebrauch gemacht [Ehr1995]. Außerdem ist zu beobachten, dass Methoden häufig falsch angewendet 

werden, aufgrund fehlender Anwenderkenntnisse bezüglich Zielen, Grenzen und 

Möglichkeiten der Methoden [Zan1999]. 

Eine erfolgreiche Produktplanung versucht die Entwicklungen, Trends und Anforderungen 

der Märkte zu antizipieren. Doch wie kann ein Unternehmen möglichst frühzeitig, effektiv 

und systematisch Marktpotentiale erkennen? Eine zentrale Bedeutung kommt hierbei der Unternehmensanalyse 

zu. Bevor die Entwicklung neuer Produkte angestoßen wird, sollte zuvor 

unternehmensintern untersucht werden, in wieweit mit den bereits etablierten Produkten der 

Markt bedient werden kann. Geeignete Methoden zur Unterstützung dieser Analyse sind z.B. 

Markt-Technologie-Portfolio nach McKinsey, Conjoint-Analyse, Quality Function Deployment 

(QFD) oder das Instrument der strategischen Lückenplanung, mit denen ein unternehmensspezifisches 

Stärken/Schwächen-Profil erstellt werden kann. 

Für die Markt-, Umfeld- und Wettbewerbsanalyse stehen ebenso eine Vielzahl von Methoden 

zur Verfügung, z.B. Produkt-Markt-Matrix nach Ansoff, Marktanteils-Marktwachstums- 

Portfolio der Boston Consulting Group oder das Marktattraktivität-/Wettbewerbsportfolio. 

Darüber hinaus sind in der Literatur zahlreiche Methoden zu finden. Für viele kleine und mittelständische 

Unternehmen stellt sich nun die Frage, welche dieser zuvor genannten Methoden 

sinnvoller Weise eingesetzt werden sollte. Eine erste Orientierungs- und Entscheidungshilfe 

bietet hierbei der im Rahmen des Verbundprojektes GINA entwickelte Methodenbaukasten 

„Methodos“. Es handelt sich hierbei um ein Internetportal (http://user.gina-net.de/main), 

das eine strukturierte Sammlung von Methoden und Hilfsmittel für den gesamten Konstruktionsprozess 

enthält, von der Zukunftsanalyse und Produktplanung bis hin zur Ideengenerierung/-bewertung 

und Umsetzungsplanung. Übergeordnetes Ziel des Methodenbaukastens ist, 

die oben beschriebene Wissenslücke zu schließen und somit das methodische Arbeiten in der 

Praxis zu stimulieren. Der Methodenbaukasten enthält eine strukturierte Sammlung von ca. 80 

Methoden, die praxisgerecht aufbereitet wurden, so dass eine unternehmens- und aufgabenspezifische 

Methodenauswahl möglich ist. Hierzu sind relevante Methodenmerkmale und 

Anwendungsvoraussetzungen aufgeführt, die es Anwendern ermöglicht, eine geeignete Auswahl 

treffen zu können. Für jede Methode sind folgende Angaben abrufbar (vgl. Abbildung 

5): 

• praxisgerechte Kurzbeschreibung zur Methode, 

• Arbeitsschritte zur Durchführung einer Methode, 

• Stärken und Schwächen, 

• Anwendungsbeispiele, 

• Angaben zu Richtlinien (sofern vorhanden) sowie 

• weiterführende Literaturhinweise. 

Weiterhin werden zahlreiche Formblätter, Checklisten sowie einfach zu bedienende Excel- 

Programme bereitgestellt, die bei der Anwendung der Methode unterstützend eingesetzt werden 

können. Diese Hilfsmittel können per Download abgerufen werden und sind benutzungsspezifisch 

erweiter- und anpassbar. 

134


Abbildung 5: Methodenmerkmale zum „Brainstorming“ (Ausschnitt) 

Zu bemerken ist, dass die Methodensammlung keinen Anspruch auf Vollständigkeit erhebt. 

Es wurde bewusst auf die Aufnahme zahlreicher Methoden verzichtet, die sich teilweise nur 

in Nuancen unterscheiden. 

4.3 Optimierung des Projektcontrollings 

Im Hinblick auf eine erfolgreiche Gestaltung des Innovationsprozesses kommt grundsätzlich 

dem Projektcontrolling im Entwicklungsbereich eine herausragende Stellung zu. Die Bedeutung 

des Projektcontrolling im Entwicklungsbereich lässt sich insbesondere dadurch verdeutlichen, 

dass die Kosten für ein Produkt bereits in der Entwicklungsphase größtenteils festgelegt 

werden. Nach Erkenntnissen aus der Praxis werden in dieser Phase bis zu 95% der Gesamtkosten 

des Produktlebenszyklus determiniert. Entsprechend besteht die Notwendigkeit 

alle Projekte im Entwicklungsbereich bezüglich Zeit, Qualität und Kosten zu planen und zu 

kontrollieren. Vor diesem Hintergrund wurde im Rahmen von GINA der Entwicklungsbereich 

der Klöckner Desma Schuhmaschinen GmbH aufbau- und ablauforganisatorisch mit 

dem Ziel analysiert, Verbesserungspotenziale im Entwicklungsbereich zu identifizieren und 

somit letztlich die Effektivität und Effizienz der Entwicklung zu steigern. Grundlage hierfür 

bildeten insbesondere die wissenschaftlichen Erkenntnisse bezüglich eines Projektcontrolling 

in der Forschung und Entwicklung. 

Der Entwicklungsbereich der DESMA gliedert sich in das Technikum sowie in die Entwicklung 

und Konstruktion. Das Technikum entwickelt in erster Linie neue Verfahren zur Sohlenherstellung. 

Darüber hinaus nimmt es eine technische Unterstützungsfunktion gegenüber dem 

135


Vertrieb und Fertigung wahr, womit aufbauorganisatorisch eine Schnittstelle zum Kunden besteht, 

um prinzipiell eine kundenorientierte Entwicklung zu ermöglichen. Dagegen befasst 

sich die Entwicklung und Konstruktion primär mit der Entwicklung von den für die verschiedenen 

Sohlenherstellungsverfahren notwendigen Komponenten und Aggregaten einer 

Schuhmaschine. Neben der Realisierung von kundenbedingten technischen Anpassungen der 

Standardkomponenten und -aggregaten nimmt die Entwicklung und Konstruktion ebenso eine 

Unterstützungsfunktion gegenüber dem Vertrieb wahr, z.B. bei der Klärung der technischen 

Umsetzbarkeit der Kundenwünsche. 

Die kundenbezogene Ausrichtung des gesamten Entwicklungsbereiches zeigt sich auch insbesondere 

daran, dass mehr als 40% der Entwicklungsaktivitäten direkt auf Aufträge von Kunden 

zurückgeführt werden können. Die aus Kundenaufträgen resultierenden Entwicklungsprojekte 

weisen jedoch mehrheitlich im Vergleich zu den selbstangestoßenen Entwicklungsprojekten 

einen geringeren Aufwand in Bezug auf die Mannstunden auf. Bezüglich der Effektivität 

und Effizienz des Projektmanagements muss dieser Tatsache Rechnung getragen werden, 

indem bei der projektbezogenen Planung und Kontrolle der jeweilige potenzielle Projektumfang 

berücksichtigt wird. 

Auf Grundlage der aufbau- und ablauforganisatorischen Analyse des Entwicklungsbereiches 

wurden verschiedene Instrumente zur Planung und Kontrolle von den kunden- und selbstinitiierten 

Entwicklungsprojekten vorgeschlagen. Wegen der unterschiedlichen Projektaufwände 

wurde dabei eine differenziertere instrumentale Ausgestaltung dieser beiden Arten von Entwicklungsprojekten 

angestrebt. 

Bei den kundeninitiierten Entwicklungsprojekten soll aufgrund der meist einfachen Projektstruktur 

sowie der geringen Interdependenzen zwischen den vorzunehmenden Entwicklungsaktivitäten 

auf die Erstellung eines differenzierten Projektstrukturplans und Ablaufplans, 

wenn möglich, verzichtet werden. Vielmehr können diese Projekte mit Hilfe von Standard- 

Netzplänen und -Ablaufplänen zeitlich geplant und kontrolliert werden. Zur zeitlichen Kontrolle 

dieser Projekte kann aber auch eine einfache Terminliste herangezogen werden (Abbildung 

6), deren Vorteile in der schnellen und einfachen Erstellung zu sehen ist. Bei der Planung 

der Kosten sollen für stets wiederkehrende Aufgaben Standardkostensätze ermittelt 

werden, so dass nur für erstmalig anfallende Aufgaben eine Kostenschätzung zu erfolgen hat. 

Die Kontrolle der Kosten erfolgt auf Basis der Gesamtkosten des Projektes, wobei auf detailliertere 

Abweichungsanalysen grundsätzlich verzichtet wird, solange die Gesamtkostenabweichungen 

sich in einem bestimmten Rahmen bewegen. 

136


AP-Nr. AP-Beschreibung 

Termin 

1.1 

1.2 

1.3 

2.1 

2.2 

3.1 

... 

Anlagefragebogen ausgefüllt 

AKT geklärt 

Verfahrensbeschreibung angefertigt 

Schutzgitter nach Kundenwunsch angefertigt 

Kurvenbahn angepasst 

Bedienungsanleitung aus Modulen 

zusammengestellt 

... 

Abbildung 6: Beispiel zum Aufbau einer Terminliste 

137 

12.03.04 

14.03.04 

16.03.04 

25.03.04 

25.03.04 

27.03.04 

Im Gegensatz dazu, ist bei den unternehmensinitiierten Entwicklungsprojekten ein umfangreiches 

Projektcontrolling erforderlich. Auf Grundlage eines Pflichtenheftes ist zunächst ein 

detaillierter Projektstrukturplan zu erstellen, der in Zusammenarbeit mit den einzelnen Fachabteilungen 

bis auf Arbeitspaketebene heruntergebrochen werden muss. Die Arbeitspakete 

bilden dann die Basis für die Kostenschätzung sowie für die Zeitplanung. Bei der Planung 

dieser Entwicklungsprojekte sind insbesondere die Interdependenzen zwischen den einzelnen 

Stellen des Entwicklungsbereiches zu berücksichtigen. Um zeitliche Engpässe zu identifizieren 

ist u.a. ein projektspezifischer Netzplan zu erstellen. Neben der Kostenkontrolle, die auf 

Grundlage einer Projektkostenrechung zu erfolgen hat, ist besonders eine Terminkontrolle 

durchzuführen, damit frühzeitig zeitliche Abweichungen erkannt werden. Zur terminlichen 

Kontrolle eignet sich z.B. die Meilenstein-Trendanalyse, bei der Meilensteine, die ein bestimmtes 

Arbeitsergebnis für einen bestimmten Zeitpunkt beschreiben, für die einzelnen Teilprojekte 

oder für das Gesamtprojekt festgelegt werden (Abbildung 7). 

...

Meilensteintermine 

09.07.04 

02.07.04 

25.06.04 

18.06.04 

11.06.03 

04.06.03 

28.05.03 

21.05.04 

14.05.04 

07.05.04 

30.04.04 

30.04.03 


07.05.03 

14.05.03 

21.05.03 

28.05.03 

Neuplanung 

Berichtszeitpunkte 

04.06.03 

11.06.03 

138 

18.06.03 

25.06.03 

02.07.03 

09.07.03 

Entwicklungsstand der Meilensteine: 

Meilenstein 4: Versuchsdurchführung erfolgreich 

Meilenstein 3: Prototyp gebaut 

Meilenstein 2: Berechnung durchgeführt 

Meilenstein 1: Vorentwurf Fertig 

Abbildung 7: Meilenstein-Trendanalyse (in Anlehnung an [Alb87]) 

Nach Abschluss des unternehmensinitiierten Projektes sind grundsätzlich alle Erfahrungen, 

aufgetretene Schwierigkeiten und deren Ursachen in einer Erfahrungsdatenbank zu erfassen, 

um auf diese Weise eine Verbesserung der Planung und Kontrolle für zukünftige Projekte zu 

erreichen. 

5 Literatur 

[Alb87] 

Alber, I.; Högsdal, B. (1987): Trendanalyse: Projektüberwachung mit Hilfe von Meilensteinund 

Kosten-Trendanalyse, Köln (TÜV Reihnland), 1987 

[Bro92] 

Brockhoff, K.: Forschung und Entwicklung: Planung und Kontrolle, 3 Auflage. Wien: Oldenbourg 

Verlag, 1992. 

[Bur87] 

Burghold, J. A.: Grobselektion von Objektideen mit Checklisten. In: DABEI (Hrsg.): DABEI- 

Handbuch für Erfinder und Unternehmer, 298-301, VDI-Verlag, Düsseldorf, 1987 

[Ehr95] 

Ehrlenspiel, K.: Integrierte Produktentwicklung – Methoden für Prozeßorganisation, Produkterstellung 

und Konstruktion, München, Wien 1995.


[Eve03] 

Eversheim, W. (Hrsg.): Innovationsmanagement für technische Produkte. Springer Verlag, 

Berlin, Heidelberg, New York, 2003. 

[Gau01a] 

Gausemeier, J., Bätzel, D., Möhringer, S.: Methodenkompetenz verbessert Produkt- und Prozeßentwicklung, 

VDI-Z 143 (2001), Nr. 1/2. 

[Gau01b] 

Gausemeier, J; Ebbesmeyer, P.; Kallmeyer, F.: Produktinnovation. Strategische Planung und 

Entwicklung der Produkte von morgen. Carl Hanser Verlag, München u.a., 2001. 

[Ges92] 

Geschka, H., Laudel, G.: Die Konzeptionsphase von Innovationsprojekten - zwischen Intuition 

und Systematik. In: Gemünden, H.G.; Pleschak, F. (Hrsg.): Innovationsmanagement und 

Wettbewerbsfähigkeit, S. 55-72, Gabler Verlag, Wiesbaden, 1992. 

[Gre03] 

Grenzmann, C.; Marquadt, R.: Verhaltende F&E_Entwicklung. In: Wissenschaftsstatistik 

gGmbH im Stifterverband für die Deutschen Wissenschaft: F&E-Info 2/2003, Essen 2003. 

[Kra87] 

Kramer, F. : Innovative Produktpolitik. Strategie - Planung-Entwicklung - Durchsetzung. 

Springer-Verlag, Berlin, Heidelberg, 1987. 

[Mer04] 

MERCER MANAGEMENT CONSULTING: Maschinenbau 2010. Steigerung der Ertragskraft 

durch innovative Geschäftsmodell. www.mercermc.de (11.08.2004) 

[Spe01] 

Specht, D; Behrens, S: Strategische Produktpplanung mittels Roadmapping. Ein Konzept für 

kleine und mittlere Unternehmen. In: Mayer, J.-A.: Innovationsmanagement in kleinen und 

mittleren Unternehmen, S. 93-103, Verlag Franz Vahlen, München, 2001 

[Ple96] 

Pleschak, F.; Sabisch, H.: Innovationsmanagement. Schaäffer-Poeschel Verlag, Stuttgart, 

1996. 

[VDI-Richtlinie 2220] 

VDI-Richtlinie 2220: Produktplanung. Beuth Verlag, Berlin, Mai 1980. 

[Zan99] 

Zanker, W.: Situative Anpassung und Neukombination von Entwicklungsmethoden, Dissertation 

Technische Universität München, Shaker Verlag 1999. 

[ZEW03] 

Zentrum für Europäische Wirtschaftsforschung: Innovationsverhalten der Unternehmen in 

Deutschland. In: BMBF (Hrsg.): Studien zum deutschen Innovationssystem Nr. 15-2004, Berlin 

2003. 

[Zan70] 

Zangenmeister, C.: Nutzwertanalyse in der Systemtechnik, München, 1970. 

139


Produkte verteilt kooperativ entwickeln und produzieren 

11 haslinger 

1 Einleitung 

KARL HASLINGER; MAXIMILIAN REISCHL 

Die ZF Passau GmbH ist ein Unternehmen der ZF-Gruppe. Innerhalb der ZF-Gruppe ist die 

ZF Passau auf Arbeitsmaschinen-Antriebe und Achssysteme spezialisiert. Weltweit werden 

an 11 Produktionsstandorten Produkte hergestellt. In der ZF Passau sind derzeit ca. 6700 Mitarbeiter 

beschäftigt. 

Abbildung 1:Unternehmensstruktur ZF-Konzern 

141


Abbildung 2:Unternehmensbereich A – Produktprogramm 

Die Anforderungen der Kunden, Globalisierung, technischer Fortschritt und leistungsfähige 

Wettbewerber zwingen zu immer neuen Anstrengungen. Dazu sind die Arbeitsprozesse ständig 

zu optimieren. Strategische Schwerpunkte sind hierbei: 

• koordiniertes Zusammenwirken aller Bereiche, 

• offenes Informationsverhalten, das Synergien erzeugt. 

Unterstützt wird dies durch das Schaffen von entsprechenden Prozessen und deren Abbildung 

in Software-Werkzeuge. Hierzu gehören zur Zeit firmeninterne Projekte wie z.B. 

• weltweite Datenreplikation mittels Axalant, 

• Aufbau einer neuen Stückliste mit neutraler Erzeugnisstruktur, 

• Abbildung des Produktentstehungsprozesses entsprechend ISO/ TS 16949 in SAP cProjects 

• dezentraler Datenaustausch per DXM von PROSTEP. 

Da die einzelnen Geschäftsbereiche der ZF-Gruppe mehr und mehr integrierbar sind, müssen 

auch die Schnittstellen zu Kunden und zu Lieferanten verringert werden. Von Seiten der 

Kunden bestehen Aufforderungen und Möglichkeiten, direkt in deren Systeme Daten (Dokumente 

und organisatorische Daten) einzugeben. Es ist aber auch notwendig, dass diese Möglichkeit 

ebenso den Lieferanten zur Verfügung gestellt wird. Hier ist eine Anbindung an ZFinterne 

Werkzeuge notwendig, ohne aber die entsprechenden Sicherheitskriterien zu verletzen. 

Ein erster Schritt in diese Richtung ist das vorliegende Vorhaben, mit dem in Zusammenarbeit 

mit den Beteiligten eine beispielhafte erste Anbindung aufgebaut wird. 

142


Als Zulieferer der Arbeitsmaschinen- und Automobilindustrie ist die ZF Passau GmbH mit 

den gleichen Anforderungen konfrontiert wie die OEM‘s: Verkürzung der Entwicklungszeiten, 

Einbindung der Entwicklungspartner in die Produkt- und Prozessentwicklung, Einstieg in 

das eEngineering, virtuelle Produktbeschreibung. Diesen Anforderungen auf der Engineeringseite 

stellt sich die ZF Passau durch eine durchgängige 3D-Prozesskette von der Konstruktion, 

Simulation, Fertigung bis zur Qualitätskontrolle mit dem Focus, auf Zeichnungen immer 

mehr zu verzichten. Diese Prozesskette ist in das unternehmensinterne PDM- und PPS- 

System einzubinden um Datenredundanz zu vermeiden. Dazu sind Pro/ENGINEER als CAD, 

Axalant als PDM- und SAP als PPS-System die strategischen Software-Werkzeuge. 

Schwerpunkt der letzten Jahre war die Pro/E-Durchdringung voranzutreiben. Dazu wurden 

die Mitarbeiter intensiv ausgebildet und eine für die Produkte der ZF Passau geeignete Konstruktionsmethodik 

erarbeitet, welche auch unseren Entwicklungspartnern vermittelt wurde. 

Ergänzt wurden die Arbeiten durch den Aufbau einer ZF-weiten Umgebung mit Norm- und 

Katalogteilen. 

Um die wachsende Zahl von CAD-Dokumenten verwalten zu können, wurde das PDM- 

System Axalant eingeführt. Anhand von Axalant soll der Produktentstehungsprozess unterstützt 

und dokumentiert werden. Neben der Dokumentenverwaltung wird auch der Materialstamm 

und der Änderungsprozess abgebildet, zukünftig soll auch die Entwicklungsstückliste 

darin abgebildet werden. 

Derzeit fehlt die Einbindung der Entwicklungspartner 

• in eine automatische Aktualisierung unserer Norm- und Katalogteile. 

• in die unternehmensintern mehr und mehr geschlossene Prozesskette, insbesondere an die 

internen Systeme, hier vor allem Axalant. 

Im Rahmen des Verbundprojekts KOEFFIZIENT soll ein neuer Lösungsansatz realisiert und erprobt 

werden. 

2 KOEFFIZIENT 

KOEFFIZIENT ist ein Verbundprojekt innerhalb des Rahmenkonzepts „Forschung für die Produktion 

von morgen“: 

143


Abbildung 3:Partner im Verbundprojekt 

2.1 Ziele der Mitarbeit in KOEFFIZIENT 

Die ZF Passau stellt Achsen und Getriebe für den Einsatz von Arbeitsmaschinen her. Die Innenteile 

der Konstruktionen bestehen hauptsächlich aus Stahl, die Gehäuse aus Guss. Alle 

Gussteile werden gekauft, wobei die Konstruktion im Hause ZF Passau bzw. bei externen 

Konstruktionsbüros erfolgt 

144


Abbildung 4: Vereinfachte Darstellung der Ist-Situation 

Im Rahmen des Projektes soll vor allem die Engineeringkette "Rohteil" betrachtet werden. 

Bei dieser Engineeringkette sind zwei Arten eines Informationsaustausches zu betrachten, 

einmal der Informationsfluss für die Bestellungen und der Informationsfluss der Dokumente 

(Zeichnungen, 3D-Modelle). Bei der Engineeringkette "Rohteil" sind die folgenden Partner 

involviert: 

Externe Konstruktionsbüros: Bei Zuhilfenahme von externen Konstruktionsbüros erhalten 

diese von der internen Konstruktionsabteilung einen Auftrag. Die Konstruktion wird oftmals 

im gleichen CAD-System wie in dem von ZF Passau erstellt. Falls Daten ausgetauscht werden 

müssen, erfolgt dies über eine zentrale Stelle per ISDN, EDI, CDROM, Modem, etc. Diese 

Daten müssen dann im internen PDM-System ausgecheckt bzw. wieder eingecheckt werden. 

Dieser reine Verwaltungsvorgang erfordert viele unterschiedliche Beteiligte, die alle zeitlich 

verfügbar sein müssen. Bei diesem Prozess ist sehr viel Potential zur Effizienzsteigerung enthalten, 

z.B. indem die Konstruktionsbüros direkt mit dem PDM-System der ZF Passau arbeiten. 

Dazu müssten jedoch die organisatorischen, hardwaremäßigen und vor allem sicherheitstechnische 

Voraussetzungen geschaffen werden. 

Gießerei/Gusslieferant: Im Produktentstehungsprozess wurde ein detaillierter Designstatus 

eingeführt, der den Reifegrad eines Produktes während der Konstruktion beschreibt. 

Bereits in einem sehr frühen Stadium wird der spätere Gusslieferanten ausgewählt. Dieser 

kann dann seine Erfahrungen und Kenntnisse mit in die Konstruktion einfließen lassen. Außerdem 

werden anstelle von detaillierten nur noch vereinfachte Zeichnungen mit dem Bestellschreiben 

verschickt. Die genaue Produktbeschreibung ist im 3D-CAD-Modell enthalten, das 

die Basis für die Gussmodellerstellung ist. Die Konstrukteure erzeugen ein 100%-Abbild der 

Nennkontur im CAD-System. Diese CAD-Dokumente werden im PDM-System verwaltet. 

Der Datenversand zum Gießer erfolgt per Datenaustauschantrag durch eine zentrale Stelle. 

Ein Zugriff auf das PDM-System der ZF Passau und somit eine Holmöglichkeit der Daten 

145


durch den Gießer ist nicht gegeben. Neben dieser organisatorischen Verbesserung ist auch 

noch Potential im Konstruktionsprozess vorhanden: 

Der Gießer hat ungleich mehr gusstechnisches Know-how als der Konstrukteur, der aber das 

CAD-Modell komplett beschreiben muss. Hierzu sind also viele Iterationen notwendig. 

Einfacher wäre es, wenn die Konstruktion sich auf den konstruktiven Teil beschränken kann 

und der Gießer in das CAD-Modell die gusstechnischen Informationen (Ausformschrägen, 

spezielle Rundungsradien, ...) einbaut. Dazu fehlen aber zur Zeit noch die Trennstellen und 

Aufgabenverteilungen. Deshalb wird durch dieses Projekt eine Effizienzsteigerung erzielt, indem 

der Informationsautausch zwischen ZF Passau und dem Lieferant verbessert wird. 

Modellbauer: Die Konstruktion und der Einkauf stehen in direktem Kontakt mit dem Gießer. 

Dieser hat aber oft im Modellbauer einen Unterlieferanten, der das Gussmodell erstellt. Auch 

dieser erzeugt mittels NC-Programmierung das Modell. Basis ist auch hier der virtuelle Rohling. 

Für das Gussmodell müssen noch die gusstechnischen Informationen eingebaut werden 

(Speiser, Steiger, Kühlplatten, Schwundmaße, ...). Diese Informationen verändern das CAD- 

Modell. Diese Änderung ist in Verantwortung der Gießerei bzw. des Modellbauers und für ZF 

Passau nicht von primären Interesse. 

Erstbemusterung: Zu einem Auftrag zur Rohteilherstellung gehört die Erstellung eines Erstmusterberichtes 

bzgl. des Rohteils, wieweit das Gussteil von der Nennkontur abweicht. ZF 

Passau beschränkt sich auf eine stichprobenartige Vermessung des Rohteil. Aufgrund der internen 

3D-Prozesskette ist es möglich, dass eine Erstbemusterung ohne Rohteilzeichnung erfolgt, 

da das 3D-CAD-Modell eine 100%-Beschreibung der Sollkontur ist und die zulässigen 

Abweichungen beinhaltet. Mittels einer separaten Messsoftware können die Unterschiede 

zwischen CAD- Modell und Gussrohling erfasst und dokumentiert werden. Immer mehr Gießereien 

verfügen über den gleichen Stand wie ZF Passau. Die Erstmusterberichte werden im 

PDM-System als weiteres Dokument zum entsprechenden Materialstamm verwaltet. 

Berechnungsbüro: Begleitet wird der Konstruktionsprozess durch Simulationen und Berechnungen. 

FE-Berechnungen für die Bauteilfestigkeit werden bis dato ausschließlich intern 

durchgeführt. Simulationen, die den Guss-Herstellprozess darstellen und optimieren könnten, 

sind im Hause ZF nicht angedacht. Ein Ansatzpunkt hierbei ist es, die Simulation der Struktur 

intern durchzuführen, die Simulation des Herstellprozesses dort, wo die Herstellung erfolgt. 

Wichtig hierbei ist, dass die jeweiligen Ergebnisse in den anderen Engineeringprozessen berücksichtigt 

werden. Eine Änderung der Speiser kann z.B. zu einer Änderung der CAD- 

Kontur führen. Ein Radius kann aufgrund der Festigkeit verändert werden müssen und dies 

kann zu einer Änderung im Gussmodell führen. Deshalb ist eine durchgängige, unternehmensübergreifende 

Datenverwaltung äußerst wichtig. 

Zur Zeit gibt es noch keine Anbindung der externen Partner an das PDM- und PPS-System 

der ZF Passau. Dies führt zu vermehrtem Verwaltungsaufwand, der keine Wertschöpfung 

sondern eine Gefahrenquelle für unsichere Prozesse darstellt. Mit der Einführung des PDM- 

Systems unterscheiden wir strikt zwischen Dokument (Zeichnung, 3D-Modell, Berechnungsbericht, 

Erstmusterbericht,...) und Material (Teil, Baugruppe). Ausgetauscht werden zwischen 

ZF Passau und Kunden/Lieferanten bisher hauptsächlich Dokumente. Eine große Vereinfachung 

wäre es, wenn während der gesamten Prozesskette Material- bzw. Teiledaten und die 

dazugehörigen Dokumente ausgetauscht werden können. Somit hätte jedes Glied in der Kette 

Zugriff auf das aktuelle geltende Mastermodell. Hierdurch würde die aufwändige redundante 

Verwaltung der Dokumente bei den einzelnen Beteiligten in der Prozesskette verringert werden. 

Der dynamische Kooperationsassistent soll dabei helfen, die unternehmensübergreifenden 

Engineeringprozesse effizienter und diese im Zusammenspiel mit unseren externen Partner 

beherrschbar zu gestalten. 

146


Hieraus ergibt sich die vereinfachte Darstellung der Soll-Situation: 

Abbildung 5: Vereinfachte Darstellung der Soll-Situation 

2.2 Aktuelles Funktionsmodell und Integrierung von SupplyOn 

Während der Projektlaufzeit von KOEFFIZIENT wurden in der ZF auch die eBusiness Aktivitäten 

verstärkt. Hierbei wurde festgelegt, dass SupplyOn die strategische Plattform des ZF- 

Konzerns ist. Durch eine Beteiligung von SupplyOn an dem Projekt KOEFFIZIENT ergeben 

sich folgende Chancen: 

a. SupplyOn betreibt Lösungen, die bestimmte Teilaspekte des Forschungsprojektes berühren. 

Hierzu gehören eine Software zur Anfrage- und Angebotserstellung, WebEDI mit 

Einzel- und Änderungsbestellung als auch Lösungen zum Dokumenten-Management. Dadurch 

sind die Voraussetzungen gegeben, um im Rahmen der verabschiedeten Projektmeilensteine 

zeitnah ein Pilotprojekt durchführen zu können. 

b. SupplyOn beschäftigt sich seit mehreren Jahren intensiv mit unternehmens-übergreifenden 

Prozessen in den Bereichen Einkauf, Entwicklung und Supply Chain Management. Die 

hierbei aufgebauten umfassenden Erfahrungen können direkt in das Projekt eingebracht 

werden. 

c. SupplyOn wird bereits heute von über 1000 mittelständischen Firmen als Kommunikationsplattform 

genutzt. 

d. Durch SupplyOn kann die pilotierte Softwarelösung als Ergebnis des Forschungsprojekts 

zeitnah und nachhaltig dem industriellen Mittelstand angeboten werden und wird dadurch 

eine starke Verbreitung erfahren. 

Nachfolgend ist das aktuelle Funktionsmodell dargestellt: 

147


Abbildung 6: Aktuelles Funktionsmodell 

Prozess Anfrage / Angebot: 

• Der Einkäufer legt im SAP R/3 eine Anfrage mit der entsprechenden Verteilerliste an. 

• Die Anfrage wird aus SAP R/3 exportiert und nach bestimmten Auswahlkriterien zum 

KOS, der sich in der demilitarisierten Zone der ZF befindet, umgeleitet. 

• KOS: Eine entsprechende Anfrage wird angelegt und die notwendigen Daten importiert. 

Über die Materialstämme werden die zugehörigen CA-Dokumente (inkl. Stammsatz) aus 

Axalant ausgecheckt. Die CA-Dokumente werden aus Axalant ausgecheckt, zum KOS 

transferiert und der Anfrage angefügt. Im KOS wird für die umgeleitete Anfrage der entsprechende 

Link erzeugt und der XML-RFQ ergänzt. Das geänderte XML-File wird über 

den BC (Business Connector) an die DAB transferiert. 

• Auf DAB können bei Bedarf weitere Dokumente angehängt werden (z.B. Projektplan, 

…) 

• Der Lieferant loggt sich bei SupplyOn ein und sieht die Anfragedaten ein. Über den hinzugefügten 

Hyperlink in der Anfrage kann er einen KO Client mit der entsprechenden Anfrage 

öffnen und dadurch auch auf die logisch verknüpften CA-Dokumente zugreifen. 

148


Abbildung 7: Anfrage bei SupplyOn mit dem Link zum KO-Client 

Abbildung 8: KOEFFIZIENT-Client 

• Die Lieferanten geben über die DAB ein Angebot ab. Die ZF kann die Angebote ins SAP 

R/3 importieren. Hierbei wird wieder über den KOS umgeleitet, d.h. die notwendigen Daten 

werden im KOS importiert und zur entsprechenden Anfrage logisch verknüpft. 

Prozess Bestellung: 

• Der Einkäufer legt im R/3 eine Bestellung an (durch Kopie eines der Angebote) 

149


• Die Bestellung wird aus SAP R/3 exportiert und nach bestimmten Auswahlkriterien zum 

KOS umgeleitet, eine logische Verknüpfung zum Angebot wird im KOS hergestellt. 

• KOS: Hier wird eine entsprechende Bestellung erzeugt und die notwendigen Daten importiert. 

Über die Materialstämme werden die zugehörigen CA-Dokumente (inkl. Stammsatz) 

aus Axalant ausgecheckt. Die CA-Dokumente werden aus Axalant ausgecheckt, zum KOS 

transferiert und mit der Bestellung logisch verknüpft. Im KOS wird für die umgeleitete Bestellung 

der entsprechende Link erzeugt und in der EDI Nachricht (iDoc) ergänzt. Das geänderte 

File wird über den ZF EDI Manager an SupplyOn WebEDI transferiert. 

• Der Lieferant loggt sich bei SupplyOn ein und sieht die Einzelbestellung (oder Änderungsbestellung) 

ein, über den hinzugefügten Hyperlink (wird als Text dargestellt) kann er einen 

KO Client mit der entsprechenden Bestellung öffnen und dadurch auch auf die logisch 

verknüpften CA-Dokumente zugreifen. Bei der Bestellung von Engineeringdienstleistungen 

kann der Lieferant die CA-Dokumente modifizierten, im KO-Client speichern und 

zum KO-Server transferieren. Die ZF kann die modifizierten Daten vom KO-Server ins 

PDM-System transferieren. 

3 Resümee 

• Die Projektziele wurden in einem Piloten umgesetzt 

• Vorstellung des Funktionsprototypen in verschiedenen ZF-Konzern-Gremien findet derzeit 

statt 

• Abstimmung mit der Konzernzentrale bezüglich der weiteren Vorgehensweise und weiteren 

Integration ist in Arbeit 

• Durch KOEFFIZIENT kann die Prozesseffizienz und Prozesssicherheit der Produkt- und Prozessentwicklung 

mit unseren Lieferanten gesteigert werden. 

150


Qualitätssicherung durch Kompetenzmanagementsysteme 

4 schumacher 

MARIANNE SCHUMACHER; STEFAN ZUG 

Zusammenfassung: In der Anlagen- und Maschinenbaubranche, insbesondere bei kleinen und 

mittelständischen Unternehmen, vollzieht sich derzeit ein dramatischer Wandel. Der Übergang des 

Industriezeitalters ins Informationszeitalter verlangt von vielen Unternehmen eine vollständige 

Reorganisation der wertschöpfenden Geschäftsprozesse. Eine hohe Innovationsgeschwindigkeit im 

Maschinenbau verlangt von den Herstellern den Einsatz neuer Technologien. Moderne Hydraulik- 

und Pneumatiksysteme sowie Elektronikkomponenten sind aus den heutigen Produkten nicht mehr 

weg zu denken. Zusätzlich werden bei der Entstehung neuer Produkte im Zuge einer stärkeren 

Produktdifferenzierung neue Informationstechnologien aus den Bereichen Mikroelektronik, Softwareentwicklung 

sowie Informations- und Kommunikationstechnik eingesetzt. Neben der globalen 

Produktunterstützung, steigender Produktkomplexität und immer kürzerer Entwicklungszeiten 

steht heute die konsequente Qualitätssicherung der Produkte im Mittelpunkt jedes Unternehmens. 

Bei der Qualitätssicherung in der Anlagen- und Maschinenbaubranche spielt die Identifikation von 

internen Kompetenzträgern für eine kundenorientierte Auftragsabwicklung eine große Rolle. Gerade 

die kleinen und mittelständischen Unternehmen verfügen oft über begrenzte personelle, monetäre 

und technischorganisatorische Ressourcen, um den Marktanforderungen gerecht zu werden. 

73 Diese Komplexitätslücke zwischen den Marktanforderungen und den zur Verfügung stehenden 

Ressourcen wird durch „neue“ Wissensmanagementansätze, hier insbesondere Kompetenzmanagementsysteme 

(KMS) geschlossen, in denen das vorhandene Mitarbeiterwissen und die 

Erfahrungen aus unterschiedlichsten Bereichen gesammelt und gezielt in den Unternehmensprozessen 

genutzt werden. 

1 Kompetenzmanagement als 

Rahmenbedingung der Qualitätssicherung 

Ein Unternehmen, das langfristig und gewinnbringend auf dem Markt agieren will, muss seine 

Kunden durch Qualität der angebotenen Waren und Dienstleistungen überzeugen können. 

Die Karl Schumacher Maschinenbau GmbH (KSM) bezeichnet Qualität als die Fähigkeit, 

vordefinierte und vorausgesetzte Kundenforderungen termingerecht und in der entsprechenden 

Erstklassigkeit zu erfüllen. Die Qualität der konstruierten Maschinen wird nicht nur durch 

den Herstellungsprozess bestimmt. Sie hat eine hohe Bedeutung auf allen Ebenen der Wertschöpfungskette 

von der Erstkontaktierung des Kunden über Auftragsabwicklung bis hin zur 

Auslieferung des Produktes und Kundendienst vor Ort. 

Eine effiziente Qualitätssicherung im Rahmen eines betrieblichen Qualitätsmanagements beinhaltet 

neben der Analyse aller Unternehmensprozesse, zum einen auch ständige Erfassung 

und Förderung der Mitarbeiterqualifikationen und zum anderen die Verbesserung der organisationalen 

Kompetenzen. Ein erfolgreiches Qualitätsmanagement kann den Unternehmen einen 

konzeptionellen Grundstein zur Erzielung komparativer Wettbewerbsvorteile gewährleisten. 

Ein wesentliches Merkmal der Norm ISO 9001 ist die Sicherstellung eines kontinuierlichen 

Verbesserungsprozesses, das bedeutet, dass bestehende Ablaufstrukturen und -anweisungen 

durch interne Audits regelmässig überprüft werden. Die Stärkung der Wettbewerbsposition 

und das Funktionieren der ISO-Norm kann nur dann erreicht werden, wenn alle 

73 Vgl. Hermeier (2000), S. 48, Thomsen (2000), S. 34 ff. 

151


Mitarbeiter in das Konzept einbezogen werden, in dem sie bereit sind, ihr Wissen zu teilen 

und es über Kompetenzmanagementsysteme allen anderen zugänglich zu machen. 74 Durch einen 

über das gesamte Unternehmen verteilten Vernetzungsprozess aller individuellen und organisationalen 

Kompetenzen kann es zu einer kontinuierlichen und effizienteren Verbesserung 

von Abläufen und Prozessen kommen. Diese Verbesserung spiegelt sich wiederum in 

der Wettbewerbsposition des Unternehmens wider. 

Durch den Einsatz von Kompetenzmanagementsystemen bei der Karl Schumacher Maschinenbau 

GmbH soll gewährleistet werden, Informationen der Wissensträger zur Qualitätssicherung 

sowohl strukturiert als auch unstrukturiert suchen zu können. Die Kompetenzmanagementsysteme 

sollen so konstruiert werden, dass die potentiellen Anwender in der Lage sind, 

Know-how und Kenntnisse der Mitarbeiter über die Ablagestruktur der integrierten Daten ohne 

explizite Recherchenvorgänge ausfindig zu machen. 

Abgesehen von dem übergeordneten Zielen, lassen sich auch folgende Unterziele definieren: 

• Reorganisation des vorhandenen Wissens im Unternehmen 

• Relevante Wissensträger identifizieren und in Kompetenzmanagementsystemen abgelegte 

Informationen ausführlich und greifbar machen 

• Archivierung des Wissens, das durch Teilen oder Ausscheiden von Mitarbeitergruppen 

verloren geht 

• Wissenslücken erkennen und schließen 

• Schaffung einer Wissensplattform zum Austausch von horizontalen und vertikalen Informationen 

• Ergänzung und Systematisierung der internen Personalwirtschaft, insbesondere die Maßnahmen 

zu Stellenbesetzung, Mitarbeiterentwicklung und Mitarbeiteranalysen 

Die KSM entwickelt, konstruiert und fertigt Sondermaschinen und Anlagen für die Automobil- 

und Elektrobranche. Auf Grund der hohen Komplexität der Anlagen gehört die Konzentration 

auf Kompetenzmanagement zu den wichtigen Aufgaben der KSM. Die intensive Auseinandersetzung 

der Geschäftsleitung mit Kompetenzmanagement entstand im Folge konkreter 

Problemstellungen im Bereich der Auftragsabwicklung. Die Geschäftsführung erkannte 

rasch, dass unzureichende Kenntnisse über das vorhandene Wissen unserer Mitarbeiter erhebliche 

Indifferenzen verursacht, die dann wiederum zu einem kontinuierlichen Anstieg der 

Kosten geführt hat. 

Des Weiteren haben sich aus den Gesichtspunkten der kundenorientierten Auftragsabwicklung 

innerhalb der einzelnen Geschäftsbereiche folgende Fragestellungen gebildet: 

• Verfügt die KSM über personelle Ressourcen, um die Umsatzziele für das laufende Geschäftsjahr 

zu realisieren? 

• Verfügen die KSM-Mitarbeiter über bestimmte Kompetenzen, um einen Kundenauftrag in 

hoher Qualität, termingerecht und im Rahmen des vorhandenen finanziellen Budgets 

durchführen zu können? 

• Ist die KSM in der Lage, innerhalb kurzer Zeit für die Durchführung von Service-Arbeiten 

an Maschinen, die vor Jahren ausgeliefert wurden, den richtigen Wissensträger zu identifizieren? 

74 Vgl. Ishikawa (1985), S. 24. 

152


• In welcher Weise kann die KSM das interne, zur Verfügung stehende Wissen bestmöglich 

nutzen, um den teuren Zukauf des externen Wissens zu umgehen? 

Alle diese Fragen können in einer Aussage über die Verfügbarkeit von individuellen und organisationalen 

Kompetenzen zu einem bestimmten Zeitpunkt an einem bestimmten Ort zusammengefasst 

werden. Sie signalisieren gleichzeitig den Bedarf nach Instrumenten zur Identifizierung 

und Strukturierung des vorhandenen Wissens im Unternehmen. 

2 Vereinigung der individuellen und organisationalen Kompetenzen 

Der wirtschaftliche Erfolg eines Unternehmens bildet sich in der Kooperationsfähigkeit zwischen 

dem individuellen Wissensträger und dem kollektiven Wissenspotential der gesamten 

Organisation ab. 75 Die Vereinigung der individuellen und organisationalen Kompetenzen vermag 

demzufolge innerhalb einer Organisation den Wissensaustausch, und gleichzeitig die 

Gewährleistung der Qualitätssicherung, zu erleichtern. Die folgende Abbildung verdeutlicht 

die Interdependenzen zwischen den beiden Kompetenzarten, die für die weitere Arbeit als besonderes 

relevant angesehen werden. 

individueller 

Kompetenzträger 

Team 

153 

Unternehmen als 

Organisation 

Netzwerk 

Abbildung 1: Individuelle und organisationale Kompetenzen 76 

2.1 Die Bedeutung der individuellen Kompetenzen 

Kompetenzmanagement als ein Teil des Wissensmanagements beginnt bei einzelnen Mitarbeitern 

auf allen hierarchischen Ebenen eines Unternehmens. Individuelle Kompetenzen sind 

das implizite Wissen einzelner Wissensträger. Der zielgerechte Umgang mit den eigenen 

Kenntnissen und Fertigkeiten ist die Grundplattform für ein gut funktionierendes Wissensmanagement. 

77 Diesbezüglich umfasst bei KSM das Spektrum der individuellen Wissensträger 

alle Mitarbeiter. Sie sind als Angehörige des Unternehmens anzusehen, die zur Beschleunigung 

von Prozessen und zur Weiterentwicklung des gesamten Unternehmens beisteuern. 

75 Vgl. Hinterhuber at al. (1997), S. 47. 

76 Quelle: In Anlehnung an: ebenda. 

77 Vgl. Probst at al. (2000), S. 21.


Al-Laham 78 unterscheidet eine Reihe signifikanter Charakteristika des Wissensträgers bei der 

Repräsentation, dem Erwerb und der Anwendung von Wissen. Das Wissen eines Wissensträgers 

kann nur zum Teil auf eine reine Repräsentation von Informationen zurückgeführt werden. 

Der Bearbeitungsprozess von Informationen bezeichnet Al-Laham als eine Rückkoppelung 

des vorhandenen Wissens eines Wissensträgers. Der individuelle Wissenserwerb wird 

ebenfalls sehr stark vom bereits vorhandenen Wissen beeinflusst. Eine sehr hohe Bedeutung 

der Qualitätssicherung weist die Anwendung des individuellen Wissens auf. Das Anwendungspotential 

des individuellen Wissens wird in der Personalmanagement-Literatur durch 

verschiedene Kompetenzarten unterschieden. Individuelle Kompetenzen werden in die Kompetenzarten: 

Fachkompetenz, Methodenkompetenz und Sozialkompetenz unterteilt. 79 Die 

Fachkompetenz dient der Erreichung des berufsspezifischen Wissens (Fachwissen). Bei der 

Fachkompetenz ist das vorhandene Wissen so stark präsent, dass eine Zusammenarbeit mit 

anderen Wissensträgern nicht zwingend notwendig ist. Auf Grund der extrem heterogenen 

fach- und unternehmensspezifischen Anforderungen an Facharbeiter, Konstruktionsmitarbeiter, 

Ingenieure oder kaufmännische Mitarbeiter der KSM wird der Erfassung dieser Informationen 

eine ganz besondere Sorgfalt gewidmet. Die Methodenkompetenz umfasst im Wesentlichen 

die situations- und fachübergreifende Kenntnisse und Fertigkeiten des einzelnen Wissensträgers. 

Die Sozialkompetenz dient primär der Koordination von Wissensträgern bezüglich 

einer Zusammenarbeit zur Erreichung eines gemeinsamen Ziels. Sie bezieht sich auf den 

Einfluss eines Wissensträgers auf einen anderen Wissensträger und umgekehrt. Die gegenseitige 

Beeinflussung erfordert eine Kommunikation zwischen den Wissensträgern und somit 

kann eine Weiterentwicklung der eigenen Kompetenzen gewährleistet werden. 

Eine klare Darstellung der individuellen Mitarbeiterkompetenzen hilft interne Fehlinterpretationen 

zu vermeiden. Die Transparenz der Mitarbeiterkompetenzen leistet einen positiven 

Beitrag zu einem besseren Verständnis der eigenen Aufgaben und schafft zugleich eine konstruktive 

Leistungsbereitschaft der Mitarbeiter. 

„Das Managen“ der individuellen Kompetenzen ermöglicht der Geschäftsleitung das aktuelle 

Wissen der Wissensträger zu sichern. Bei Bedarf können aus den erfassten Informationen Experten 

und Spezialisten in den jeweiligen Bereichen identifiziert und auf die Kenntnisse und 

Fähigkeiten dieser Personen zurückgegriffen werden. Gleichzeitig ist die Geschäftleitung in 

der Lage, auf Grund der Erfassung der individuellen Kompetenz das entscheidungsrelevante 

Wissen effizient zu bewerten und gegebenenfalls bei Wissenslücken z.B. durch interne oder 

externe Weiterbildungsmaßnahmen entsprechend zu reagieren. Neben dem Zugang zum aktuellen 

Wissen der Mitarbeiter und der Bewertungsmöglichkeit gestattet ein KMS der individuellen 

Kompetenz eine strategische Entwicklung der eigenen Kompetenzen, im Sinne der systematischen 

Weiterentwicklung von Fähigkeiten und Abbau von Wissensdefiziten. 

2.2 Die Bedeutung der organisationalen Kompetenz 

Bei KSM hängt die Realisierung der festgelegten Qualitätsziele nicht nur von den Kompetenzausprägungen 

der einzelnen Wissensträger ab, sondern auch vom kompetenzorientierten 

Management auf der organisationalen Ebene. Organisationale Kompetenzen sind das Resultat 

der Verknüpfung individueller Kompetenzen und haben einen hohen Einfluss auf die Wett- 

78 Vgl. Al-Laham (2003), S. 37 f. 

79 Vgl. ebenda, S. 39. 

154


bewerbskraft eines Unternehmens. 80 In der Wissensmanagement-Literatur wird organisationales 

Wissen häufig mit kollektivem Wissen gleichgesetzt. 81 Die KSM differenziert die organisationalen 

Kompetenzen wie folgt: 

i) Teamwissen (Gruppenwissen) 

Die Verrichtung von Team- oder Projektgruppenarbeiten ist für den Qualitätsstandard und die 

Entwicklung und Nutzung der organisationalen Kompetenzen von sehr großer Bedeutung. 

Auf Grund von Teamarbeiten wird das Wissen unter den Wissensträgern horizontal auf allen 

Unternehmensebenen ausgetauscht. Im Rahmen der Zusammenarbeit innerhalb eines Teams 

können gemeinsame Werte entwickelt und prozessbezogenes Wissen unter den Mitgliedern 

einer Gruppe ausgetauscht werden. Gruppenkompetenz entsteht aus partizipativen oder kollektiven 

Lernprozessen. Das in den Gruppen vorhandene Wissen kann im Gegensatz zu individuellem 

Wissen nicht abhanden kommen, wenn einzelne Gruppenmitglieder aus dem Unternehmen 

ausscheiden. 82 Diesbezüglich werden bei der KSM alle projektbezogene Tätigkeiten 

in mittleren oder kleinen Gruppeneinheiten durchgeführt. Damit wird sichergestellt, dass 

das Wissen für die nächsten Produktgenerationen innerhalb einer Gruppe, Abteilung erhalten 

bleibt. 

ii) Organisationales Wissen 

Organisationales Wissen kennzeichnet sich dadurch, dass es von allen Mitgliedern des Unternehmens 

geteilt wird. Dieses Wissen ist weitgehend vom einzelnen Wissensträger eines Unternehmens 

unabhängig und dient dem Unternehmen zur Aufgabenabwicklung und damit der 

Erreichung seiner strategischen Ziele. 83 Das organisationale Wissen hat zur Aufgabe - neues 

Wissen zu erzeugen, dieses dann innerhalb der Organisation (hier über die gesamte Wertschöpfungskette) 

zu verteilen und in die auftragsbezogenen Prozesse in Bezug auf die Qualitätssicherung 

zu integrieren. 

KSM definiert den Wert des organisationalen Wissens als die Summe aller Kenntnisse und 

Fertigkeiten des einzelnen Wissensträgers in allen Stufen eines auftragsbezogenen Prozesses. 

Angebots- und Bestellprozess 

Im Angebots- und Bestellprozess liegt der Wert des organisationalen Wissens in den Mitarbeitern 

der Verkaufsabteilung. Dazu zählen Kenntnisse und Fertigkeiten über Struktur von 

Märkten, Verhandlungen mit potentiellen Kunden, Strukturierungen der Prozesse von Angebotserstellung 

über Leistungs- und Liefergrenzen bis hin zu externen Lieferantenauswahl. Der 

Prozess der Angebotserstellung verlangt von den Mitarbeitern ein hohes Maß an technischem 

Know How zur Ausarbeitung von Problemlösungen, Kompetenzen im Bereich der Angebotskalkulation 

unter Berücksichtigung aller möglichen Kosten und Aufwendungen. Marktanalysen 

liefern der KSM Informationen über Kompetenzen von Produzenten, Zwischenhändlern 

oder Dienstleistungsbetrieben. Darüber hinaus werden Auskünfte über Qualitätseigenschaften 

der angebotenen Produkte oder Dienstleistungen ermittelt. Die Kompetenz der Wissensträger 

80 Vgl. Doz (1997), S. 55; Probst at al. (2000), S. 71. 

81 Vgl. Al-Laham (2003), S. 39. 

82 Vgl. Güldenberg (1997), S. 194; Hinterhuber at al. (1997), S. 48. 

83 Vgl. Al-Laham (2003), S. 41 f. 

155


über die Ermittlungsverfahren, Genauigkeit und Verlässlichkeit der Informationen spielt eine 

wesentliche Rolle bei der Durchführung der Wirtschaftlichkeitsberechnung oder bei der 

Kombination dieser Daten mit anderen technischen Größen der Ingenieurwissenschaft. Im 

Rahmen des Angebots- und Bestellprozesses werden Leistungs- und Liefergrenzen für den 

Aufraggeber festgelegt. Diese beinhalten sämtliche technische Berechnungen und ISO Norm 

Prüfunterlagen. Die Miterbeiter der Verkaufsabteilung verfügen über Kompetenzen bei der 

Auswahl von geeigneten Unterlieferanten (hier handelt es sich insbesondere um hydraulische, 

pneumatische- und elektrische Baugruppen). Bestellvorgänge von Materialien und anderen 

Anlagenkomponenten erfolgen, wenn nicht anders von Auftraggeber erwünscht, auf der Basis 

des günstigsten, nicht des billigsten Angebots. Diesbezüglich werden von den Mitarbeitern 

Kenntnisse über den aktuellen Stand der Marktentwicklung verlangt. 

Entwicklungs- und Konstruktionsprozess 

Die Miterbeiterkompetenz des Entwicklungs- und Konstruktionsprozesses liegt im Bereich 

der ingenieurmäßigen Entwicklung und Konstruktion von Maschinen. Hier beschränkt sich 

die Kompetenz der Wissensträger nicht nur auf die Erstellung von Zeichnungen, Aufstellungsplänen 

und Ansichten, sondern auf komplette Maschinenkonstruktionen in 3D- 

Datenmodellen und Layouts. Das Maschinenlayout beinhaltet gesamte Planungsprozesse, die 

mit räumlicher Isometrie der verschiedenen Bauteilen und mit der Aufstellung der einzelnen 

Maschinenteile inklusive deren Verkabelung zusammenhängen. 

Fertigungsprozess 

Der Fertigungsprozess richtet sich in erster Linie auf die Kompetenzen der Mitarbeiter im Bereich 

der mechanischen Bearbeitung von Teilen und Maschinenkomponenten. Zur Realisierung 

des Fertigungsprozesses stehen den Mitarbeitern hoch moderne computergestützte 

Dreh-, Fräs- und Schleifmaschinen zur Verfügung. Der Umgang mit dieser Technik führt dazu, 

dass Erfahrungs- und Kontextwissen des einzelnen Wissensträgers als organisationales 

Wissen in der KSM-Philosophie weiter verwendet wird. 

Montage- und Inbetriebnahmeprozess 

Im Montage- und Inbetriebnahmeprozess liegt das organisationale Wissen in den Kenntnissen 

und Fertigkeiten der Wissensträger in erster Linie beim Zusammenbau von einzelnen Maschinenteilkomponenten, 

Montage der Hydraulik-, Pneumatik- und Elektrobauteilen sowie bei 

Durchführung von Tests auf aufwandfreie Funktionalität der hergestellten Maschinen. Des 

Weiteren verfügen die Mitarbeiter über sicherheitstechnische Kenntnisse, die dann bei der 

Montage von Sicherheitseinrichtungen in halbautomatischen Maschinen, z.B. Bewegungsmelder, 

Lichtschranken oder computergestützte Ausschaltvorrichtungen eingesetzt werden. 

Der Montageprozess verlangt von den Wissensträgern außerdem die Kenntnisse und Fertigkeiten 

in Bezug auf die Entwicklung und Einspielung der Steuerungssoftware. 

Kundenservice und Schulung 

Der wirtschaftliche Erfolg eines Unternehmens hängt stark von vielen Indikatoren des Kundenkreises 

ab. Dazu gehören z.B. Kundenbindung, Kundenunterstützung und Kundentreue. 

Entscheidend für eine langfristige Zusammenarbeit ist eine hohe Kundenzufriedenheit. Diesbezüglich 

spiegelt sich die organisationale KSM-Kompetenz in den Maßnahmen zur Kunden- 

156


zufriedenheit wider. Die Wissensträger sind durch ihre Kompetenzen in der Lage den Kunden 

vor Ort Schulungen anzubieten. Hier werden insbesondere Schulungsanweisungen zum ordnungsmäßigen 

Umgang mit gelieferten Maschinen übermittelt. Sie gewährleisten einerseits 

die Übermittlung von Maschinenkenntnissen an den Kunden, und anderseits eine zuverlässige 

und schnelle Unterstützung beim Einsatz und der Anwendung der Maschine. 

Im Rahmen des Kundenservices wird dem Kunden die komplette Dokumentation der hergestellten 

Maschinen übergeben. Die Dokumentation beinhaltet alle für den Betrieb dieser Anlagen 

relevante Unterlagen. Dazu gehören u.a. eine allgemeine Beschreibung der Maschinen, 

sämtliche erstellten Zeichnungen, Pläne und Skizze aller Maschinenteilkomponenten, ein Verzeichnis 

aller extern eingekauften Bauteile sowie eine EG-Konformitätserklärung des Herstellers. 

Kaufmännische Steuerung und Überwachung 

Neben den technischen Kompetenzen der Wissensträger spielen bei der Qualitätssicherung 

die kaufmännischen Steuerungs- und Überwachungsprozesse eine große Rolle. Bei allen diesen 

Prozessen zur Herstellung einer Anlage sind Wirtschaftlichkeits- und Risikoaspekte unter 

Berücksichtigung der gesetzlichen und vertraglichen Vorschriften bezüglich der kaufmännischen 

und technischen Ausführung gegenüberzustellen. Von den kaufmännischen KSM- 

Mitarbeitern werden für alle Aktivitäten im Anlagenbau Wirtschaftlichkeitsberechnungen an 

Hand der statischen und dynamischen Investitionsrechnung durchgeführt, die dann in Kombination 

mit allen anderen kaufmännischen Aufgaben zur Qualitätssicherung und damit zur 

Verbesserung der Wettbewerbsposition führen. 

Die Summe dieser einzelnen Prozesse bildet bei KSM die organisationale Kompetenz (vgl. 

Abbildung 2). 

157

Kundenanfrage 

Angebot, 

Bestellung 


KSM als organisationale Kompetenz 

Kaufmännische Steuerung und Überwachung 

Entwicklung, 

Konstruktion 

Fertigung 

Kundenbegleitung 


158 

Montage, 

Inbetriebnahme 

Kundenservice, 

Schulung 

Abbildung 2: Auftragsbezogene Kompetenzen bei KSM. 84 

Kundenzufriedenheit 

iii) Netzwerkwissen 

Eine weitere Grundlage für eine erfolgreiche Qualitätssicherung und für den Zugang zum 

Wissen ist die Zusammenarbeit der KSM in strategischen Netzwerken mit anderen Partnern 

aus verschiedenen Wirtschaftszweigen. In erster Linie handelt es sich hierbei um Kooperationen 

mit unterschiedlichen Lieferanten. Die KSM arbeitet eng zusammen mit mehr als 300 

Lieferanten aus ingenieur- und kaufmännischorientierten Branchen. Die Kooperationsverträge 

erlauben der KSM die Kompetenzen der einzelnen Partner miteinander zu kombinieren. 

Langjährige Zusammenarbeit mit unseren Lieferanten verringert in einem strategischen 

Netzwerk die Kostenbelastung und den Koordinationsaufwand, der bei einem engen Zeitplan 

der verschiedenen Kundenprojekte von großer Bedeutung ist. 

Ein weiterer Vorteil eines strategischen Netzwerkes ist die kontinuierliche Versorgung mit Informationen. 

Die KSM ist dadurch in der Lage den Stand der technologischen Weiterentwicklung 

der einzelnen Kooperationspartner zu erfahren und gegebenenfalls die neuen Erkenntnisse 

in den Produktionsprozess einzubeziehen. Diese Art der Informationsversorgung hat sich 

besonders positiv auf die Verbreiterung des Leistungsangebots und die Erhöhung der Kundenzahl 

ausgewirkt. Zusammenfassend lassen sich aus kunden- und kompetenzorientierter 

Sicht folgende Nutzenpotentiale eines strategischen Netzwerkes feststellen: 

• Aufbau von internen und externen Kompetenzvorteilen, 

• Integration von neuen informationstechnologischen Prozessen und 

• Erschließung von neuen Märkten und Ressourcen. 

84 Quelle: Eigene Darstellung.


3 Kompetenzmanagement – ein System mit Zukunft 

Wie anfangs erwähnt, bilden Kompetenzmanagementsysteme eine gute Grundlage für eine 

Optimierung der prozessorientierten Qualitätssicherung. Der systematische und konsequente 

Einsatz wissensbasierter Kompetenzmanagementsysteme führt im Laufe der Zeit zu einer 

besseren Nutzung der Ressource „Wissen“. Sie können Widersetzlichkeiten der Wissensträger 

abschwächen und ermöglichen eine frühzeitige Problemerkennung sowie die optimale Anpassung 

an unternehmens- und nutzerspezifische Bedürfnisse. Kompetenzmanagementsysteme 

funktionieren nur, wenn die Systeme den betrieblichen Veränderungen angepasst werden. Die 

neuen Systeme müssen auch berücksichtigen, dass das Management von Kompetenzen ein 

langfristig angelegter Prozess der Unternehmensgestaltung ist. Die Qualitätsorientierung der 

Unternehmen spiegelt sich in den Qualifikationen der Mitarbeiter wider. In vielen Unternehmen 

schlummern kreative Kräfte in den bereits vorhandenen Mitarbeitern. Die Aufgabe der 

Kompetenzmanagementsysteme ist es, mitarbeiterund stellenbezogene Maßnahmen zu erkennen 

und zu erarbeiten, die durch ihren Einsatz das Wissenspotential der Wissensträger 

fördern und erhalten sollen. Durch den Einsatz von Kompetenzmanagementsystemen können 

Unternehmensstrategien mit Personalstrategien eines Unternehmens verbunden werden. Sie 

erhalten detaillierte Angaben darüber, welche Kenntnisse und Fertigkeiten ein Wissensträger 

hat und dadurch ermöglichen sie festzustellen, welches Wissen ein Mitarbeiter zusätzlich benötigt, 

um eine bestimmte Aufgabe im Unternehmen qualitätsorientiert durchführen zu können. 

Wichtiger Aspekt der Funktionsfähigkeit von KMS ist die konstante Pflege dieser Systeme. 

Die Erfassung und Eingabe der Mitarbeiterkompetenzen darf nicht als einmalige Angelegenheit, 

sondern als immer wiederkehrende Aufgabe zur Aktualisierung und Erkennung von 

Kompetenzlücken verstanden werden. Alle Wissensträger, die im Rahmen der Erstellung von 

KMS identifiziert wurden, müssen ihr Wissenspotential so weit wie möglich in das System 

eingeben. Jeder Mitarbeiter, insbesondere die Führungsebene, muss die Möglichkeit besitzen, 

jederzeit Zugriff auf die Daten des Kompetenzmanagementsystems zu haben, die benötigten 

Informationen und Inhalte schnell aufspüren und auftragsbezogen aufbereiten zu können. 

Die Kompetenzerfassung und Speicherung dieser Daten auf elektronischen Medien soll sicherstellen, 

dass alle potenziellen Nutzer dieses Systems unabhängig vom Wissensträger auf 

das gespeicherte Wissen zugreifen und damit verschiedene Aufgaben bewältigen können. Die 

Nutzung des Wissens soll auch gewährleistet werden, wenn ein wichtiger Wissensträger das 

Unternehmen verlässt. Die umfassende Integration von Mitarbeiterkompetenzen in das Managementsystem 

und die Verknüpfung der Daten mit auftragsbezogenen Prozessen ist daher ein 

wesentlicher Meilenstein der Qualitätssicherung. 

Maßnahmen zur Kompetenzerfassung sind auch in allen Entwicklungsphasen mit Barrieren 

und Risiken behaftet. Hierzu gehören z.B. Widerstände in der technischen Umsetzung des 

Vorhabens. Das sind in erster Linie Probleme der Bereitstellung anwenderfreundlicher Software 

zur Wissensrecherche, -dokumentation und -verteilung. Neben den Barrieren der technischen 

Umsetzung spielen die Differenzierungen personeller Art eine wichtige Rolle. Individuelle 

Widerstände können sich in der Motivation der Wissensträger zum Wissenstransfer 

widerspiegeln. 85 Oft herrscht unter den Mitarbeitern das Gefühl, dass das Wissen der Wissensträger 

abgeschöpft werden soll. Dazu kommen Unsicherheiten der Mitarbeiter in Bezug 

der Sicherung des Arbeitsplatzes. Diesbezüglich müssen Maßnahmen getroffen werden, die 

diese Unsicherheiten der Mitarbeiter durch Hilfestellungen und Anreizsysteme beseitigen. 

Ebenfalls müssen Handlungen entwickelt werden, die zu Überwindung von Problemen orga- 

85 Vgl. Zelewski, Peters, Dittmann (2004), S. 52. 

159


nisationaler Art führen. Hier werden insbesondere die Bestimmungen des Betriebsrates in die 

Entwicklung von Kompetenzmanagementsystemen herangezogen. 

4 Literaturverzeichnis 

Al-Laham (2003) 

Al-Laham, A.: Organisationales Wissensmanagement. Eine strategische Perspektive. München 

2003. 

Doz (1997) 

Doz, Y.: Managing core competency for corporate renewal. Towards a managerial theory of 

core competencies. In: Campell, A.; Sommers Luchs, K. (Hrsg.): Core competence based 

strategy. London 1997, S. 53-75. 

Gebert (2001) 

Gebert, H.: Kompetenz-Management - Bewirtschaftung von implizitem Wissen in Unternehmen. 

[Im Internet unter der URL: http://wi.oec.uni-bayreuth.de/doctoral/Beitraege/gebert.pdf, 

Datum des Zugriffs: 14.06.2002]. 

Güldenberg (1997) 

Güldenberg, S.: Wissensmanagement und Wissenscontrolling in lernenden Organisationen. 

Ein systemtheoretischer Ansatz. Wiesbaden 1997. 

Hermeier (2000) 

Hermeier, B.: Management-Kompetenz in kleinen und mittelgroßen Unternehmen (KMU). In: 

Thielemann, F. (Hrsg.): Kompetenzentwicklung im Mittelstand – Das Beispiel Kompetenz- 

Entwicklungs-Center. Essen 2000, S. 48-125. 

Hinterhuber at al. (1997) 

Hinterhuber, H. H. at al.: Kundenzufriedenheit durch Kernkompetenzen. Eigene Potentiale 

erkennen – entwickeln – umsetzten. München, Wien 1997. 

Ishikawa (1985) 

Ishikawa, K.: What is Total Quality Control? The Japanese Way. New York 1985. 

North (1999) 

North, K.: Wissensorientierte Unternehmensführung: Wertschöpfung durch Wissen. Wiesbaden 

1999. 

Probst at al. (2000) 

Probst, G. at al.: Kompetenz-Management. Wie Individuen und Organisationen Kompetenz 

entwickeln. Wiesbaden 2000. 

Thomsen (2000) 

Thomsen, E-H.: Management von Kernkompetenzen. Methodik zur Identifikation und Entwicklung 

von Kernkompetenzen für die erfolgreiche strategische Ausrichtung von Unternehmen. 

In: Lück. W. (Hrsg.): Schriftenreihe Managementorientierte Betriebswirtschaft. Konzepte, 

Strategien, Methoden. Bd. 2, München 2000. 

Zelewski, Peters, Dittmann (2004) 

Zelewski, S.; Peters, M. L.; Dittmann, L.: Wissensträger identifizieren und motivieren. In: 

Wissensmanagement, 4/04, S. 51-53. 

160


5 bäumgen 

Ontologiebasiertes Kompetenzmanagementsystem 

auf Basis von infonea® 

CHRISTOF BÄUMGEN; ROGER HÜBBERS 

1 Aufbau und Pflege einer Kompetenzontologie 

In diesem Tagungsbandbeitrag wird die Funktionsweise des prototypischen Kompetenzmanagementsystems 

beschrieben. Die hier beschriebenen Funktionalitäten des KOWIEN-Prototyps 

können sich bis zum Ende der Implementierungsphase noch ändern, d.h. in diesem Abschnitt 

werden einerseits einige Funktionen beschrieben, die zwar geplant aber zum Zeitpunkt des 

Redaktionsschlusses noch nicht vollständig umgesetzt worden sind. Andererseits werden sich 

aufgrund der iterativen Vorgehensweise und der fortlaufenden Evaluation von Zwischenständen 

sicherlich noch neue Erweiterungswünsche der Anwender ergeben, die bei der Weiterentwicklung 

des KOWIEN-Prototyps bis Ende Oktober 2004 nach Möglichkeit noch berücksichtigt 

werden. Die Vorgehensweise bei der Erstellung des KOWIEN-Prototyps und die 

technologische Basis infonea® wird im entsprechenden Abschnitt des Buches zum KO- 

WIEN-Projekt ausführlich beschrieben. 

Dem Prozess „Kompetenzontologie pflegen“, unter dem hier sowohl der Aufbau als auch die 

Pflege einer Kompetenzontologie verstanden wird, wurde im KOWIEN-Projekt die meiste 

Aufmerksamkeit gewidmet. Das KOWIEN-Vorgehensmodell beschreibt nur, wie man bei der 

Erstellung einer Kompetenzontologie vorgehen kann. Das Vorgehen bei den anderen Prozessen, 

die wie beispielsweise der Prozess „Projektteam bilden“ ebenfalls vom KOWIEN- 

Prototyp unterstützt werden, wird durch das Vorgehensmodell in Übereinstimmung mit dem 

Projektrahmenplan nicht beschrieben. Andererseits können die im Vorgehensmodell beschriebenen 

Arbeitsschritte, die den Aufbau und die Pflege einer Kompetenzontologie betreffen, 

selbstverständlich nicht alle softwaretechnisch unterstützt werden, da beispielsweise das 

Zusammentragen wichtiger Unterlagen und die zwischenmenschliche Kommunikation in 

Form von strukturierten Interviews und Reviews auch Teil des Vorgehens sind. Dieser Abschnitt 

beschreibt also nicht das gesamte Vorgehensmodell, sondern nur, wie der KOWIEN- 

Prototyp den Aufbau und die Pflege einer Kompetenzontologie unterstützt. 

1.1 Erarbeitung einer Taxonomie vor der Inbetriebnahme 

Nach der Definition der Ziele des Kompetenzmanagementsystems und der Identifikation der 

Anwendungsbereiche und der Benutzer sieht das KOWIEN-Vorgehensmodell zunächst die 

Erhebung der Anforderungen an die zu erstellende Ontologie vor. Der nächste Arbeitsschritt 

ist dann die Identifikation der wesentlichen Wissensträger und Dokumente, um mit ihrer Hilfe 

eine erste Begriffssammlung zu erstellen. Die erste Befragung der Wissensträger sollte nicht 

per Software erfolgen, da der zwischenmenschliche Dialog bei diesem Arbeitsschritt eine 

große Rolle spielt. Die dabei und bei der Analyse der wesentlichen Dokumente identifizierten 

Kompetenzbegriffe und Relationen zwischen den Begriffen sollten aber dann direkt in struk- 

161

Ontologiebasiertes Kompetenzmanagementsystem auf Basis von infonea® 

turierter Form elektronisch erfasst werden. Im KOWIEN-Projekt wurde der Ontologie-Editor 

OntoEdit® dafür verwendet. 86 OntoEdit® ermöglicht u.a. den Aufbau einer Begriffshierarchie. 

In einem frühen Stadium der Ontologie-Entwicklung ist die Drag-and-Drop- 

Funktionalität von Vorteil, die es ermöglicht, mit der Maus Änderungen an der Taxonomie 

der Kompetenzbegriffe vorzunehmen. Die Erstellung dieser anfänglichen Taxonomie ist ein 

zeitintensiver Prozess, an dem alle betroffenen Personen und Domänenexperten beteiligt werden 

müssen, damit diese Konzeptionalisierung am Ende einen Konsens darstellt und man von 

einer Kompetenzontologie reden kann. Die Diplomarbeit von Susanne Apke dokumentiert 

ausführlich die Erstellung der Kompetenzontologie für die DMT GmbH. 87 Im Anschluss an 

ihre Arbeit wurde die DMT-Ontologie in den KOWIEN-Prototyp importiert, indem die im 

proprietären OXML-Format von OntoEdit® vorliegende Begriffshierarchie in das XML- 

Datenaustauschformat von infonea® (iCE) transformiert worden ist. 

Neben OntoEdit® gibt es auch noch andere, zum Teil sogar frei erhältliche Software- 

Werkzeuge, mit denen eine anfängliche Begriffshierarchie erstellt werden kann. Eine Freeware, 

die sich dafür sehr gut eignet, ist beispielsweise die Mind Mapping Software FreeMind. 88 

Dieses Programm speichert die hierarchisch strukturierten MindMaps in einem XML-Format 

ab, das sich auch leicht in das infonea® iCE-Format transformieren läßt. Natürlich ist es auch 

möglich, eine Kompetenzontologie vom ersten Begriff an mit dem KOWIEN-Prototyp zu 

erstellen, indem die Begriffe über das Web-Frontend eingegeben und mit den anderen Begriffen 

vernetzt werden. Dabei muss man jedoch bedenken, dass eine Stärke von infonea® darin 

besteht, dass die Anwender mit einem beliebigen halbwegs aktuellen Browser auf die infonea® 

Anwendungen zugreifen können, was zur Folge hat, dass man ohne Drag-and-Drop- 

Funktionalität auskommen muss, da ein reines HTML-Frontend diese Möglichkeit nicht bieten 

kann. Der große Vorteil der webbasierten Architektur des KOWIEN-Prototyps kommt bei 

der kontinuierlichen Erweiterung und Pflege der Kompetenzontologie zum Tragen, denn diese 

ermöglicht es, alle Benutzer des KOWIEN-Prototyps an der Erweiterung der Ontologie zu 

beteiligen und bestimmte Aufgaben der Ontologiepflege (wie z.B. die Suche nach neu aufzunehmenden 

Begriffen) zu dezentralisieren. 

1.2 Kontinuierliche Erweiterung und Pflege im Betrieb 

Nach der Erarbeitung einer anfänglichen Hierarchie von Kompetenzbegriffen und dem Import 

eines Grundstocks an weiteren Inhalten, zu denen auch die Kontaktinformationen der Mitarbeiter 

des Unternehmens gehören, kann das Kompetenzmanagementsystem in Betrieb genommen 

werden. Beim Aufbau und der Pflege von Kompetenzprofilen wird sich aber bestimmt 

herausstellen, dass bestimmte Kompetenzbegriffe in der Ontologie noch fehlen. Dazu 

kommt, dass sich die Kompetenzen, die für die Erreichung der strategischen Ziele des Unternehmens 

von Bedeutung sind, im Laufe der Zeit ändern, so dass die Kompetenzontologie im 

laufenden Betrieb überarbeitet und erweitert werden muss. 

86 OntoEdit® wurde ursprünglich im Rahmen eines BMBF-Projekts entwickelt, an dem die Universität Karlsruhe beteiligt 

war, und wird inzwischen von der ontoprise Gmbh, einem SpinOff der Universität Karlsruhe, vermarktet. Anfang 

2005 wird die Version 2.7 von OntoEdit® durch die Version 1.0 von OntoStudio® abgelöst, einer Neuimplementierung 

auf Basis von Eclipse, die u.a. die Performanzprobleme von OntoEdit® bei der Bearbeitung umfangreicher Ontologien 

beseitigen soll. 

87 siehe APKE (2003). 

88 siehe http://freemind.sourceforge.net/. 

162


Für die konsistente Erweiterung und Pflege der Kompetenzontologie ist im KOWIEN- 

Prototyp die Person verantwortlich, die die Rolle des Ontologie-Administrators übernimmt. 

Diese Rolle ist mit speziellen Rechten ausgestattet und kann sowohl einzelne Begriffe löschen 

und hinzufügen als auch die Beziehungen zwischen den Begriffen verändern, z.B. was die 

hierarchische Begriffsstruktur betrifft. Vorschläge für die Aufnahme eines neuen Kompetenzbegriffs 

können alle Benutzer machen, die Kompetenzaussagen und Erfahrungen eingeben 

können. Wie dies genau funktioniert wird im Unterabschnitt 2.1 beschrieben. Die neu vorgeschlagenen 

Begriffe werden dem Ontologie-Admi-nistrator angezeigt und das System unterstützt 

ihn dabei, diese Begriffe entweder in die Ontologie aufzunehmen und mit den anderen 

Begriffen zu vernetzen oder eine Aufnahme in die Ontologie abzulehnen bzw. die neu vorgeschlagenen 

Begriffe einem bereits in der Ontologie enthaltenen Begriff als Synonym zuzuordnen. 

Wenn größere Änderungen an der hierarchischen Begriffsstruktur vorgenommen werden 

müssen, besteht die Möglichkeit, die Kompetenzontologie aus dem KOWIEN-Prototyp zu 

exportieren, mit einem externen Ontologie-Editor unter Einsatz von Drag-and-Drop- 

Mechanismen zu editieren und danach wieder in den KOWIEN-Prototyp zu importieren. Begriffe, 

die in Zukunft nicht mehr zur Beschreibung von Kompetenzen eingesetzt werden sollen, 

weil es inzwischen einen neuen Begriff für die entsprechende Kompetenz gibt, sollten bei der 

Überarbeitung der Ontologie nicht ganz aus der Ontologie entfernt, sondern dem neuen Begriff 

als Synonym zugeordnet werden, denn dann ist die entsprechende Kompetenz danach sowohl 

unter dem neuen als auch unter dem alten Begriff zu finden. Dies ist möglich, da der 

KOWIEN-Prototyp zwischen Deskriptoren und Nicht-Deskriptoren unterscheidet und neben 

der Hierarchierelation auch die anderen beiden Begriffsrelationen unterstützt (Äquivalenzund 

Assoziationsrelation), die in der Deutschen Industrienorm 1463 zur Erstellung und Weiterentwicklung 

von Thesauri beschrieben werden (s. DIN 1463 (1987)). 

1.3 Berücksichtigung von Integritäts- und Inferenzregeln 

Der KOWIEN-Prototyp beinhaltet eine Reihe von Integritätsregeln, die dafür sorgen, dass 

keine inkonsistenten Inhalte ins System eingegeben werden können. Bei der Eingabe einer Erfahrung 

wird beispielsweise überprüft, ob der eingegebene Beginn der Erfahrung zeitlich vor 

dem eingegebenen Ende der Erfahrung liegt und bei der Eingabe einer Kompetenzaussage 

wird sichergestellt, dass solche Aussagen nur zu Begriffen gemacht werden können, bei denen 

es sich um Kompetenzbegriffe handelt. Desweiteren wurden sowohl Pflichtattribute als auch 

Pflichtassoziationen implementiert. Bei der Eingabe einer Erfahrung muss beispielsweise für 

das Attribut „Erfahrungsart“ auf jeden Fall ein Wert eingegeben werden, weil es sich dabei 

um ein Pflichtattribut handelt, und die Erfahrung muss in Beziehung zu einer Person gesetzt 

werden, weil es sich dabei um eine Pflichtassoziation handelt. Für verschiedene Attribute 

wurde eine Liste von Vorgabewerten definiert, die die Menge der zulässigen Werte für diese 

Attribute auf die Werte der entsprechenden Liste einschränkt. Diese und weitere Integritätsregeln 

sind im infonea® Constraints-Modell für den KOWIEN-Prototyp enthalten und werden 

sowohl bei der Dateneingabe über das Web-Frontend des KOWIEN-Prototyps als auch bei 

Verwendung des 32-Bit-Frontends des generischen infonea® Content Editors ausgewertet 

und überwacht. 

Mit Hilfe der im KOWIEN-Prototyp integrierten Inferenzregeln ist das System dazu in der 

Lage, einfach formulierte Fragen des Benutzers differenziert zu beantworten. Wenn der Benutzer 

beispielsweise nach Personen sucht, die über eine bestimmte Kompetenz verfügen, die 

er vorher aus der Kompetenzontologie ausgewählt oder einfach eingegeben hat, liefert das 

163


System ihm dank der integrierten Inferenzregeln alle Personen zurück, die in irgendeiner Beziehung 

zu dieser Kompetenz stehen, d.h. es werden sowohl die Personen anzeigt, über die es 

eine explizite Kompetenzaussage zu dieser Kompetenz gibt, als auch die Personen, die an einer 

Schulung teilgenommen haben, bei der diese Kompetenz vermittelt werden sollte, und die 

Personen, die bei einem Projekt eine Aufgabe übernommen haben, für deren Erfüllung diese 

Kompetenz erforderlich war. Darüberhinaus werden auch die Beziehungen zwischen den 

Begriffen der Kompetenzontologie berücksichtigt, indem die Suche auf Wunsch hin auf verwandte 

Begriffe ausgeweitet werden kann. Die Ergebnismenge wird dem Benutzer dabei so 

angezeigt, dass er erkennen kann, weshalb eine bestimmte Person vom System gefunden worden 

ist. Weitere Einzelheiten hierzu werden im Abschnitt 3 beschrieben. 

2 Aufbau und Pflege von Kompetenzprofilen 

So wie das Vorhandensein einer Kompetenzontologie die Grundlage für den Aufbau und die 

Pflege von Kompetenzprofilen ist, so ist das Vorhandensein von Kompetenzprofilen die 

Grundlage für geschäftsprozessorientierte Funktionen des KOWIEN-Kompetenzmanagementsystems 

wie beispielsweise für die Unterstützung der Projektarbeit (s. Abschnitt 4). 

Im Buch zum KOWIEN-Projekt wird ausführlich beschrieben, wie die Erfahrungen und 

Kompetenzaussagen modelliert worden sind, aus denen sich ein Kompetenzprofil im Prototyp 

zusammensetzt. 89 Im Folgenden wird beschrieben, wie sich diese Art der Modellierung von 

Kompetenzprofilen auf die Eingabe von Lebensläufen auswirkt und welche Rolle in diesem 

Zusammenhang die Erfassung von Maßnahmen und Projekten spielt. Außerdem wird darauf 

eingegangen, wie durch die Integration der Kompetenzprofilpflege in die Geschäftsprozesse 

dazu beigetragen wird, dass die Kompetenzprofile während der Geschäftstätigkeit laufend aktualisiert 

werden, was die Voraussetzung dafür ist, dass das Kompetenzmanagementsystem 

von den Benutzern konsultiert und akzeptiert wird. 

2.1 Eingabe von Lebensläufen ins System 

Die Mitarbeiter, für die ein Kompetenzprofil erstellt werden soll, müssen im KOWIEN- 

Prototyp zunächst als Person angelegt werden. Dabei können neben Angaben zur Erreichbarkeit 

(Adresse, E-Mail, Telefon- und Faxnummer) auch Angaben zur organisatorischen Einbindung 

in verschiedene Teams gemacht werden. Danach ist zu überlegen, welche Informationen 

das Kompetenzprofil der Mitarbeiter bei Inbetriebnahme des Kompetenzmanagementsystems 

enthalten soll. Eine gute Ausgangsbasis bilden dafür die Lebensläufe der Mitarbeiter, 

die diese für ihre Bewerbung angefertigt haben. Nachdem mit dem Betriebsrat geklärt worden 

ist, welche Informationen aus den Lebensläufen im Kompetenzmanagementsystem gespeichert 

werden und von wem diese Informationen eingesehen werden dürfen, können entweder 

die Personalabteilung oder die verschiedenen Mitarbeiter selbst die Aufgabe übernehmen, die 

entsprechenden Informationen mit Hilfe des Prototyps strukturiert zu erfassen. Der Grundgedanke 

besteht dabei darin, die Lebensläufe in einzelne Kompetenzaussagen und Erfahrungen 

zu zerlegen, um aus diesen atomaren Einheiten Kompetenzprofile zusammenzusetzen, die auf 

vielfältige Art und Weise recherchiert und analysiert werden können. 

89 s. Unterkapitel 2.2 im KOWIEN-Buch zur Konzeption eines ontologiebasierten Kompetenzmanagementsystems. 

164


Ein Lebenslauf enthält Informationen über verschiedene Arten von Erfahrungen. Bei einem 

Bewerber, der sich direkt nach seiner Ausbildung um einen Arbeitsplatz bewirbt, stehen die 

Ausbildungserfahrungen im Vordergrund, von denen es verschiedene Unterarten gibt, die im 

Prototyp in einem sog. hierarchischen Attribut gespeichert werden, für das es eine Liste von 

Vorgabewerten gibt, aus denen der Benutzer auswählen kann (s. Abbildung 1). 

Abbildung 1: Auswahl der Erfahrungsart beim Erfassen einer neuen Erfahrung 

Im Fall eines Hochschulstudiums wählt der Benutzer das Studienfach aus der Kompetenzontologie 

aus und ordnet diesen Kompetenzbegriff der Ausbildungserfahrung zu. Wenn es sich 

bei dem Bewerber um einen Hochschulabsolventen handelt, der auch ein oder zwei Semester 

im Ausland studiert hat, würde man auch eine sog. Auslandserfahrung ins System eingeben 

und diese Erfahrung mit dem entsprechenden Begriff für das Land (z.B. „Frankreich“) verknüpfen. 

Bei Mitarbeitern, die vorher schon in einem anderen Unternehmen gearbeitet haben, 

würde man eine Berufserfahrung erfassen und diese mit den Begriffen verknüpfen, die seine 

frühere Berufstätigkeit charakterisieren. 

Neben der manuellen Eingabe einer einzelnen Erfahrung über ein zweiseitiges Formular, besteht 

auch die Möglichkeit, Informationen über Erfahrungen und Kompetenzen, die in tabellarischer 

Form vorliegen, über das infonea® Datenaustauschformat iCE in den KOWIEN- 

Prototyp zu importieren. Beispiele für transformierbare tabellarische Informationen sind Daten 

aus SAP-Systemen oder Auswertungen von Stundenerfassungssystemen. 

Ein Beispiel für Kompetenzaussagen, die typischerweise in einem Lebenslauf enthalten sind, 

sind die Angaben zu den Sprachkenntnissen. Darüber hinaus werden aber oft auch Aussagen 

zu Fachkompetenzen gemacht. Bei der Eingabe einer Kompetenzaussage erkennt der KO- 

165


WIEN-Prototyp durch die Auswahl des entsprechenden Kompetenzbegriffs (z.B. „Englisch“ 

oder „MS Word 2003“) automatisch, auf Basis welcher Skala die Kompetenzausprägung bewertet 

werden muss und bietet im Formular die entsprechenden Vorgabewerte zur Auswahl 

an. Zur Beurteilung von Sprachkenntnissen kann beispielsweise die Ausprägung „verhandlungssicher“ 

verwendet werden, während die Ausprägung „Experte“ ein möglicher Wert der 

Skala für Fachkompetenzen ist. Welche Werte die verschiedenen Skalen haben ist von Unternehmen 

zu Unternehmen verschieden und es können beispielsweise zur Beurteilung von 

Sprachkenntnissen auch zwei verschiedene Skalen nebeneinander verwendet werden, wenn 

die Umstände es erfordern. 90 

Normalerweise wählt der Benutzer bei der Eingabe einer Erfahrung oder einer Kompetenzaussage 

über eine spezielle Begriffsauswahlseite einen Begriff aus der Kompetenzontologie 

aus. Dabei wird es jedoch auch vorkommen, dass der Benutzer den Begriff, zu dem er eine 

Kompetenzaussage machen möchte oder den er einer Erfahrung zuordnen möchte, nicht in der 

Kompetenzontologie findet, weil diese Kompetenz bei der Erstellung der Kompetenzontologie 

nicht berücksichtigt worden ist. In diesem Fall hat der Benutzer die Möglichkeit, seinen 

neuen Begriff direkt in ein entsprechendes Feld einzugeben und die Eingabe der Erfahrung 

oder Kompetenzaussage abzuschließen. Wie im Unterabschnitt 1.2 beschrieben wurde, hat die 

Person, die die Rolle des Ontologie-Administrators übernommen hat, die Aufgabe, die von 

den Benutzern bei der Erfassung einer Erfahrung oder einer Kompetenzaussage neu eingegebenen 

Begriffe in regelmäßigen Abständen zu überprüfen und zu entscheiden, ob die neuen 

Begriffe als Deskriptor oder als Nicht-Deskriptor in die Ontologie aufgenommen werden sollen. 

91 Begriffe, die als Deskriptor in die Kompetenzontologie aufgenommen werden, können 

u.a. über die Hierarchierelation und die Assoziationsrelation mit anderen Deskriptoren in Beziehung 

gesetzt und bei der Eingabe einer Erfahrung oder einer Kompetenzaussage als Kompetenzbegriff 

benutzt werden. Begriffe, die als Nicht-Deskriptoren in die Kompetenzontologie 

aufgenommen werden, werden über die Äquivalenzrelation einem Deskriptor als Synonym 

zugewiesen, können darüber hinaus aber nicht mit anderen Begriffen in Beziehung gesetzt 

werden. Die Äquivalenzrelation sorgt dafür, dass der entsprechende Deskriptor und die damit 

verbundenen Kompetenzaussagen und Erfahrungen auch dann gefunden werden, wenn der 

Benutzer bei der Suche nicht den Deskriptor, sondern einen der dazu synonymen Nicht- 

Deskriptoren eingibt. 

Wenn beispielsweise ein Benutzer eine Aussage über sich selbst zur Kompetenz „Unified 

Modeling Language“ machen möchte und es diesen Begriff zu diesem Zeitpunkt in der Kompetenzontologie 

noch nicht gibt, dann könnte der Ontologie-Administrator entscheiden, ob er 

diesen neuen Kompetenzbegriff als Deskriptor oder als Nicht-Deskriptor in die Ontologie 

aufnimmt. Wenn er als Des-kriptoren lieber Akronyme (Abkürzungen) als ausgeschriebene 

Bezeichnungen verwendet, dann würde er in diesem Fall den Begriff „UML“ als neuen Deskriptor 

in die Kompetenzontologie aufnehmen und den vom Benutzer vorgeschlagenen Begriff 

„Unified Modeling Language“ als zum Begriff „UML“ synonymen Nicht-Deskriptor akzeptieren. 

Den Deskriptor „UML“ könnte er dabei dem vielleicht schon in der Ontologie enthaltenen 

Begriff „Modellierungssprachen“ unterordnen. Wenn danach jemand mit dem Begriff 

„Unified Modeling Language“ nach Kompetenzträgern sucht, dann wird nicht nur die Person 

gefunden, die diesen Begriff vorgeschlagen und die erste Kompetenzaussage dazu ge- 

90 Die parallele Verwendung zweier verschiedener Skalen zur Beurteilung von Sprachkenntnissen war beispielsweise 

bei der DMT GmbH erforderlich, weil in den einheitlich strukturierten Lebensläufen der DMT-Mitarbeiter, die für 

die Bewerbung um EU-Projekte erstellt worden sind, eine andere Skala verwendet wurde als in der unternehmensweiten 

Datenbank mit Informationen aus Personalgesprächen und Mitarbeiterbefragungen. 

91 Die Begriffe „Deskriptor“ und „Nicht-Deskriptor“ sind geläufige Begriffe im Kontext der Erstellung von Thesauri 

und werden im Dokument DIN 1463 (1987) definiert. 

166


macht hat, sondern auch diejenigen, die im Anschluss daran eine Kompetenzaussage über sich 

selbst zum Begriff „UML“ gemacht haben. 

2.2 Erfassung von Qualifizierungsmaßnahmen und Projekten 

Es ist sinnvoll, sowohl Qualifizierungsmaßnahmen als auch Projekte zentral zu erfassen, um 

bei der Eingabe einer Erfahrung darauf verweisen zu können. Wenn beispielsweise mehrere 

Mitarbeiter an einer Weiterbildungsmaßnahme teilnehmen, sollte sich das danach in ihrem 

Kompetenzprofil widerspiegeln, d.h. zu jedem dieser Mitarbeiter sollte eine Erfahrung der Art 

„Ausbildungserfahrung. Weiterbildung“ eingegeben werden, die mit der zentral eingegebenen 

Qualifizierungsmaßnahme verknüpft wird. Dies hat den Vorteil, dass die Personalabteilung 

die Aufgabe übernehmen kann, alle Weiterbildungsmaßnahmen als Informationsobjekt im 

System anzulegen, zu beschreiben und zu verschlagworten und dass die einzelnen Schulungsteilnehmer 

bei der Eingabe ihrer Weiterbildungserfahrung einfach auf dieses Informationsobjekt 

verweisen können. Bei der Zuordnung von Kompetenzbegriffen zu einer Maßnahme besteht 

die Möglichkeit, zu jeder Kompetenz auch eine Ausprägung anzugeben. Ebenso können 

die Teilnahmevoraussetzungen beschrieben werden. Bei einer Weiterbildung mit dem Titel 

„Crashkurs C# und Visual Studio.NET“ könnte beispielsweise angegeben werden, dass bei 

den Teilnehmern Expertenkenntnisse in C++ und Grundkenntnisse in der Vorgängerversion 

Visual Studio 6 vorhanden sein müssen. Das Ausbildungsziel könnte lauten, Expertenkenntnisse 

in C# und Grundkenntnisse im Umgang mit Visual Studio.NET zu vermitteln. Ein Mitarbeiter 

der Personalabteilung ordnet im Rahmen der zentralen Maßnahmenerfassung einer 

Maßnahme sowohl die entsprechenden Kompetenzbegriffe (inklusive einer Ausprägung) als 

auch die Schulungsteilnehmer zu. Für alle Schulungsteilnehmer legt das System dann automatisch 

eine entsprechende Ausbildungserfahrung 92 an, die mit der Maßnahme verknüpft wird 

und im Anschluß daran von den Teilnehmern editiert und kommentiert werden kann. Wie zu 

einer Ausbildungserfahrung Kompetenzaussagen eingegeben werden können, die den individuellen 

Schulungserfolg eines Teilnehmers beschreiben, wird unter 2.3 (Integration in die Geschäftsprozesse) 

erläutert. 

Projekte werden ebenfalls zentral erfasst und beschrieben, wobei den Projekten die Kompetenzen 

zugeordnet werden, die für ihre Durchführung erforderlich sind. Es gibt zwei Möglichkeiten, 

ein Projekt ins System einzugeben. Zum einen ist es möglich, das Projekt unabhängig 

vom KOWIEN-Geschäftsprozessmodell einzugeben und zu verschlagworten. Zum anderen 

kann es bei seiner Eingabe direkt an das entsprechende Unternehmensmodell gekoppelt 

werden, d.h. bei der Eingabe wird festgelegt, welche Prozesse des Unternehmensmodells bei 

diesem Projekt durchlaufen werden. Ein Vorteil bei dieser Art der Projekteingabe ist, dass 

dem Projekt dadurch automatisch die erforderlichen Kompetenzen zugeordnet werden, da diese 

für die Prozesse des Unternehmensmodells erfasst worden sind. Natürlich bringt die Kopplung 

an das Unternehmensmodell noch weitere Vorteile mit sich, die im folgenden Unterabschnitt 

beschrieben werden. Bei der Zuordnung der Mitarbeiter zu einem Projekt gibt es analog 

dazu auch wieder zwei Möglichkeiten. Entweder man ordnet sie einfach als Projektmitarbeiter 

zu oder man beschreibt genauer, welche Rolle des Unternehmensmodells sie in diesem 

Projekt übernehmen. In beiden Fällen wird für alle Projektmitarbeiter automatisch eine Projekterfahrung 

angelegt, die mit dem entsprechenden Projekt verknüpft wird und im Anschluß 

an das Projekt von den Mitarbeitern editiert und kommentiert werden kann. 

92 Es gibt verschiedene Arten von Qualifizierungsmaßnahmen (z.B. Weiterbildungs- oder Fortbildungsmaßnahmen) und 

analog dazu gibt es auch verschiedene Erfahrungsarten (z.B. Ausbildungserfahrung.Weiterbildung oder Ausbildungserfahrung.Fortbildung). 

167


2.3 Integration in die Geschäftsprozesse 

Eine Integration in die Geschäftsprozesse ist für die Einführung eines Kompetenzmanagementsystems 

erfolgsentscheidend, weil der Wert eines Informationssystems von der Qualität 

der enthaltenen Informationen abhängt und brauchbare Informationen nur dann eingegeben 

und gepflegt werden, wenn der damit verbundene Aufwand gering und der Nutzen auch für 

den erkennbar ist, der sich zusätzlich zur Erledigung seiner Arbeit die Mühe macht, die Informationen 

einzugeben und zu pflegen. Während bestimmte Aufgaben wie die Erstellung einer 

anfänglichen Begriffshierarchie oder die zentrale Erfassung von Maßnahmen und Projekten 

von Mitarbeitern der Personalabteilung oder von den Projektleitern übernommen werden 

können, ist man bei der Pflege der Kompetenzprofile auf die Mitarbeit jedes einzelnen Mitarbeiters 

angewiesen. Daher sollte man sich darum bemühen, die Kompetenzprofilpflege in den 

Arbeitsalltag der Mitarbeiter zu integrieren und sie zu motivieren, durch ihre aktive Mitarbeit 

zu einer hohen Qualität und Aktualität der Datenbasis beizutragen. 

Die Basis für die Integration des KOWIEN-Prototyps in die Geschäftsprozesse eines Unternehmens 

legt das KOWIEN-Geschäftsprozessmodell. Ein wichtiger Schritt ist daher die Erarbeitung 

des Unternehmensmodells mit den unternehmensspezifischen Angaben zu den Geschäftsprozessen. 

Wenn ein solches Unternehmensmodell erarbeitet worden ist, bei dem für 

die Geschäftsprozesse die erforderlichen Kompetenzen und die Funktionen der daran beteiligten 

Rollen erfasst worden sind, dann kann beispielsweise die Projektarbeit eng damit verknüpft 

werden. Am Beispiel der infonea® Projektarbeit läßt sich gut verdeutlichen, wie das 

funktioniert und welche Vorteile damit verbunden sind. Basierend auf dem KOWIEN- 

Referenzmodell wurde eine Abstraktionsebene tiefer zuerst ein Unternehmensmodell für die 

Comma Soft AG erstellt. 93 Eine weitere Abstraktionsebene tiefer wurde basierend auf dem 

Comma Soft Unternehmensmodell das infonea® Projektvorgehen beschrieben, d.h. es wurden 

die Prozesse entsprechend benannt und beschrieben, die bei einem infonea® Projekt durchlaufen 

werden. Dabei wurden die infonea® Prozesse mit den entsprechenden Prozessen des 

Comma Soft Unternehmensmodells in Beziehung gesetzt. Außerdem wurde erfasst, welche 

Rollen es in einem infonea® Projekt gibt und welche Funktionen diese in den verschiedenen 

Prozessen übernehmen. Darüberhinaus wurden den Prozessen erforderliche Kompetenzen, 

Hilfsmittel und Prozessein- und -ausgaben zugeordnet. Ein konkretes infonea® Projekt (wie 

beispielsweise die Erstellung des KOWIEN-Prototyps) kann nun (wie in 2.2 angedeutet worden 

ist) an das infonea® Projektvorgehen gekoppelt werden, indem aus dem infonea® Projektvorgehensmodell 

die Prozesse ausgewählt werden, die in diesem Projekt durchlaufen werden. 

Welche Prozesse das sind, hängt von der Art des infonea® Projekts ab. Bei Machbarkeitsstudien 

gestaltet sich die Prozesskette beispielsweise anders als bei der Erstellung von 

Prototypen oder Pilotsystemen. Basierend auf den Kompetenzprofilen werden den in der Prozesskette 

vorkommenden Rollen konkrete Personen zugeordnet, die in den zu durchlaufenden 

Prozessen die entsprechenden Funktionen übernehmen. Wie der KOWIEN-Prototyp diesen 

Prozess der Projektteambildung unterstützt wird in Abschnitt 4 beschrieben. 

Diese prozessorientierte Organisation und Durchführung von Projekten bringt mehrere Vorteile 

mit sich. Ein Mitarbeiter, der in einem Projekt eine bestimmte Funktion erfüllt, kann auf 

alle Hilfsmittel zugreifen, die den entsprechenden Prozessen auf den darüberliegenden Abstraktionsebenen 

(im geschilderten Beispiel das infonea® Projektvorgehen, das Comma Soft 

Unternehmensmodell und das KOWIEN-Referenzmodell) zugeordnet worden sind. Außerdem 

unterstützt ihn der Prototyp bei der Suche nach Kolleginnen oder Kollegen, die in einem 

anderen Projekt die gleiche Aufgabe übernommen haben, die er jetzt aufgetragen bekommen 

93 Das Konzept der Abstraktionsebenen wird im Buch zum KOWIEN-Projekt beschrieben. 

168


hat, so dass er bei auftretenen Problemen gleich eine ganze Reihe von Ansprechpartnern angezeigt 

bekommt, die er um Hilfe bitten kann. Auf die gleiche Weise kann er später von anderen 

Kollegen gefunden werden, weil sich seine Projektmitarbeit auf sein Kompetenzprofil 

auswirkt (s. 2.2). Die Projekterfahrung, die für alle Projektmitarbeiter automatisch erstellt 

wird, gibt Aufschluss darüber, welche Kompetenzen der entsprechende Mitarbeiter in das 

Projekt eingebracht hat, denn diese Information kann aus dem zugrundeliegenden Prozessmodell 

übernommen werden. Auf diese Weise trägt die Unterstützung der Projektarbeit dazu bei, 

im laufenden Geschäftsbetrieb Wissen über Kompetenzen zu akquirieren. Natürlich hat jeder 

Projektmitarbeiter auch die Möglichkeit, den automatisch für ihn generierten Projekterfahrungen 

weitere Kompetenzbegriffe zuzuordnen, wenn er der Meinung ist, dass er bei der Erledigung 

seiner Projektaufgaben noch mehr Kompetenzen eingebracht hat als die, die den 

Prozessen im Unternehmensmodell als erforderliche Kompetenzen zugeordnet worden sind. 

Wie in Unterabschnitt 2.2 beschrieben wurde, legt das System auch für Mitarbeiter, die an einer 

Qualifizierungsmaßnahme teilgenommen haben, automatisch eine entsprechende Erfahrung 

an, die mit den Kompetenzbegriffen verknüpft wird, mit denen die Maßnahme 

verschlagwortet worden ist. Eine Beurteilung, was die Qualifizierungsmaßnahme den einzelnen 

Teilnehmern gebracht hat, d.h. welche neuen Kompetenzen sie in welcher Ausprägung 

nach der Schulung haben, kann natürlich nicht automatisch erfolgen. 94 Daher fordert das System 

die Teilnehmer im Anschluss an eine Qualifizierungsmaßnahme durch einen entsprechenden 

Link auf ihrer persönlichen Startseite dazu auf, einen Fragebogen auszufüllen, um zu 

den Schulungsthemen Kompetenzaussagen zu machen, bei denen es sich um eine persönliche 

Einschätzung ihres Kenntnisstandes nach der Qualifizierungsmaßnahme handelt. An dieser 

Stelle muss darauf hingewiesen werden, dass es für ein funktionierendes Kompetenzmanagementsystem 

wichtig ist, dass die Mitarbeiter ihre Kompetenzen möglichst zutreffend und ehrlich 

selbst einschätzen. Dies liegt auch im Interesse jedes einzelnen Mitarbeiters, denn wenn 

er sein Licht unter einen Scheffel stellt, werden seine Kompetenzen nicht wahrgenommen und 

berücksichtigt. Wenn er andererseits zu viel von sich behauptet, fällt dies spätestens beim 

nächsten Projekt auf, bei dem er aufgrund seiner Kompetenzaussagen eine Aufgabe zugeteilt 

bekommen hat, der er nicht gewachsen ist. Selbsteinschätzungen stellen auf jeden Fall eine 

verlässlichere Informationsquelle dar als automatische Schlussfolgerungen der folgenden Art: 

„Jeder, der an einer Schulung teilgenommen hat, die Expertenkenntnissen in der Programmiersprache 

C# vermittelt hat, ist danach ein C#-Experte.“. Jemand, der vorher schon Experte 

in C++ war, kann nach der Teilnahme an einem C#-Crashkurs vielleicht von sich behaupten, 

dass er nun auch Expertenkenntnisse in C# hat, aber ein anderer Teilnehmer der gleichen 

Schulung würde danach vielleicht eher sagen, dass er jetzt erweiterte Grundkenntnisse in C# 

hat, weil es schon länger her ist, seitdem er das letzte Mal in C++ programmiert hat, so dass er 

noch mehr Einarbeitungszeit benötigt, bevor er in einem Projekt als C#-Experte eingesetzt 

werden kann. Die Aufforderung des Systems zur Selbsteinschätzung im Anschluss an eine 

Qualifizierungsmaßnahme trägt also dazu bei, die Qualität und die Aktualität der Informationen 

über Kompetenzen zu gewährleisten und ist ein weiteres Beispiel dafür, wie bei der Implementierung 

des KOWIEN-Prototyps versucht wurde, die Kompetenzprofilpflege in die vorhandenen 

Arbeitsabläufe zu integrieren. 

94 Wenn durch eine abschließende Prüfung festgestellt wurde, ob die Teilnahme an der Qualifizierungsmaßnahme für 

die einzelnen Teilnehmer erfolgreich war oder nicht, kann dies natürlich (u.U. zusammen mit einer Wertung und einem 

erlangten Titel) in den generierten Erfahrungen gespeichert werden, aber selbst in diesem Fall kann nicht mit Sicherheit 

automatisch gefolgert werden, welche neuen Kompetenzen die Teilnehmer in welcher Ausprägung nach der 

Schulung haben. 

169


3 Suche nach Kompetenzträgern 

Die Beziehungen zwischen den Personen, Kompetenzaussagen, Erfahrungen, Kompetenzbegriffen, 

Maßnahmen, Projekten, Rollen und Prozessen werden bei richtiger Nutzung des Prototyps 

im Laufe der Zeit immer zahlreicher, so dass ein komplexes Informationsnetzwerk entsteht. 

Da infonea® für den Aufbau, die Analyse und die Navigation komplexer Informationsnetze 

konzipiert wurde, ist die technologische Basis des KOWIEN-Prototyps ideal dafür geeignet, 

diese vielfältigen Informationszusammenhänge eines prozess- und ontologiebasierten 

Kompetenzmanagementsystems transparent zu machen. Die Suche nach Kompetenzträgern 

profitiert von infonea® ebenso wie die Analyse der Kompetenzlücken und die Planung von 

Qualifizierungsmaßnahmen (siehe Abschnitt 5). 

In 1.3 wurde bereits darauf hingewiesen, dass im Prototyp Inferenzregeln dafür eingesetzt 

werden, um bei der Suche nach Kompetenzträgern nicht nur die Personen als Ergebnis zurückzuliefern, 

über die es Kompetenzaussagen zu den gesuchten Kompetenzen gibt, sondern 

auch die Personen, die an einer Schulung teilgenommen haben, bei der diese Kompetenz vermittelt 

werden sollte, und die Personen, die bei einem Projekt eine Aufgabe übernommen haben, 

für deren Erfüllung diese Kompetenz erforderlich war. Da eine explizite Selbsteinschätzung 

nicht den gleichen Stellenwert hat wie die Vermutung, dass jemand eine Kompetenz besitzt, 

weil er an einer Schulung teilgenommen oder bei einem Projekt mitgearbeitet hat, zeigt 

der KOWIEN-Prototyp dem Fragesteller die Ergebnismenge der gefundenen Kompetenzträger 

so an, dass erkennbar ist, warum eine bestimmte Person vom System gefunden worden ist. 

Jeder Benutzer kann dann auf Basis dieser Information und seiner eigenen Auswahlkriterien 

entscheiden, in welcher Reihenfolge er die gefundenen Kompetenzträger ansprechen möchte, 

um sie beispielsweise um Rat zu fragen oder als Mitarbeiter in einem Projekt einzuplanen. 

Die Kompetenzbegriffe, zu denen das System Kompetenzträger sucht, kann der Benutzer dabei 

entweder direkt eintippen und mit logischen Operatoren verknüpfen oder aus der hierarchischen 

Struktur der Kompetenzontologie auswählen. Wenn die Begriffe direkt eingegeben 

werden und einige der eingegebenen Begriffe in der Kompetenzontologie nicht vorkommen, 

dann weist das System den Benutzer darauf hin und bietet ihm verschiedene Optionen zur 

Fortsetzung der Suche an. Die verschiedenen Begriffsrelationen (Hierarchierelation, Assoziationsrelation 

und Äquivalenzrelation) werden benutzt, um die Suche auf verwandte Kompetenzbegriffe 

auszuweiten, wenn zu den gesuchten Kompetenzen zu wenige Kompetenzträger 

gefunden wurden. 

4 Unterstützung der Projektarbeit 

Die Projektarbeit ist das Kerngeschäft der KOWIEN-Praxispartner und in 2.3 wurde bereits 

beschrieben, wie der KOWIEN-Prototyp diesen Kern-Geschäftsprozess unterstützt, indem er 

die Möglichkeit bietet, konkrete Projekte an das KOWIEN-Geschäftsprozessmodell zu koppeln. 

Die folgenden Ergänzungen konzentrieren sich daher auf den Prozess der Projektteambildung. 

Wenn ein Unternehmen mit der Durchführung eines Projekts beauftragt wird, ist der erste 

Schritt nach der Projektakquisition in der Regel die Bestimmung eines Projektleiters. Eine dafür 

geeignete Person muss zum einen über ausreichend Projekterfahrung und über allgemeine 

Projektleiterkompetenzen verfügen, zu denen auch soziale Kompetenzen gehören. Zum anderen 

stellt jedes Projekt auch spezifische fachliche Kompetenzanforderungen an die Projektmitarbeiter 

und an den Projektleiter. Um einen geeigneten Projektleiter zu finden, der beiden 

Kriterien genügt, können die in Abschnitt 3 beschriebenen Möglichkeiten der Suche nach 

Kompetenzträgern genutzt werden. Natürlich sind neben der fachlichen Eignung auch die or- 

170


ganisatorischen Rahmenbedingungen (z.B. die Zeitplanung und der Standort, an dem das Projekt 

durchgeführt werden soll) zu berücksichtigen. Eine integrierte Auslastungs- und Zeitplanung 

war jedoch kein Ziel bei der Erstellung des ontologiebasierten Kompetenzmanagementsystems. 

Wenn ein geeigneter Projektleiter gefunden worden ist, kann er damit beauftragt werden, das 

Projektteam zu bilden, d.h. Mitarbeiter zu suchen, die zusammen mit ihm die Kompetenzanforderungen 

des Projekts erfüllen. Wie in 2.3 beschrieben wurde, sind dafür bei einer Kopplung 

des Projekts an das entsprechende Unternehmensmodell zunächst die Prozesse auszuwählen, 

die im Projekt durchlaufen werden müssen. Aus der ausgewählten Prozesskette ergeben 

sich dann die Rollen, die in diesen Prozessen bestimmte Funktionen erfüllen und von 

konkreten Personen übernommen werden müssen. Das Finden geeigneter Personen ist besonders 

bei der Besetzung der ausführenden und mitwirkenden Rollen wichtig. Die für die Prozesse 

erfassten erforderlichen Kompetenzen sind im Prinzip die Kompetenzen, die eine Person 

haben muss, die in den entsprechenden Prozessen eine ausführende oder eine mitwirkende 

Rolle übernimmt. Daher ist der KOWIEN-Prototyp dazu in der Lage, für die verschiedenen 

Rollen, die in mindestens einem der ausgewählten Prozesse ausführen oder mitarbeiten, jeweils 

eine Reihe von Personen vorzuschlagen, die die Funktionen dieser Rolle übernehmen 

könnten. Zusammen mit der Information, wie oft diese Personen die entsprechende Rolle bereits 

in früheren Projekten übernommen haben, bilden die Vorschläge des Prototyps eine sehr 

gute Entscheidungsgrundlage für den Projektleiter, der letztendlich entscheiden muss, welche 

Person im neuen Projekt welche Rolle zugeteilt bekommt. 

Nachdem die Zuordnung der Personen zu den Rollen erfolgt ist, unterstützt der KOWIEN- 

Prototyp die verschiedenen Projektmitarbeiter, indem er ihnen die Informationen und Hilfsmittel 

zur Verfügung stellt, die sie für die Erledigung ihrer Aufgaben benötigen und indem er 

ihnen hilft, bei auftretenden Problemen geeignete Ansprechpartner zu finden (s. Unterabschnitt 

2.3). 

5 Unterstützung der Unternehmensentwicklung 

Die Prozesse „Kompetenzlücken ermitteln“, „Qualifizierungsmaßnahmen planen“ und „Personal 

rekrutieren“ hängen eng miteinander zusammen und spielen eine wichtige Rolle für die 

Unternehmensentwicklung. Um im harten Wettbewerb bestehen zu können, muss sich jedes 

Unternehmen auf seine Kernkompetenzen konzentrieren und sich darum bemühen, diese weiter 

auszubauen. Da sich Märkte sehr schnell ändern können, muss auch ein Unternehmen 

schnell darauf reagieren, indem die Unternehmensziele den Marktgegebenheiten angepasst 

werden und die für die Erreichung dieser Ziele erforderlichen Kompetenzen entweder durch 

bedarfsorientierte Qualifizierungsmaßnahmen für die Mitarbeiter entwickelt oder durch gezielte 

Neueinstellungen hinzugewonnen werden. Beides setzt voraus, dass die Kompetenzlücken 

bekannt sind, die durch diese Maßnahmen geschlossen werden sollen. 

Die Ermittlung von Kompetenzlücken ist notwendig für die Ermittlung des mittel- bis langfristigen 

Qualifizierungsbedarfs, bei dem es darum geht, die Personalentwicklung an den strategischen 

Unternehmenszielen auszurichten. Wenn sich beispielsweise ein Telekommunikationsunternehmen 

im neuen UMTS-Markt positionieren möchte, dann sollte analysiert werden, 

welche Kompetenzen dafür erforderlich sind, wieviele Experten mit welchen Kenntnissen benötigt 

werden und wieviele Experten bereits im Unternehmen sind, die durch entsprechende 

Qualifizierungsmaßnahmen in einem überschaubaren Zeitrahmen auf die neuen Aufgabenfelder 

vorbereitet werden können. Die Ermittlung von Kompetenzlücken ist aber auch notwendig 

für die Ermittlung des kurzfristigen projektgetriebenen Qualifizierungsbedarfs, der ent- 

171


steht, wenn den Kompetenzanforderungen der akquirierten Projekte nicht genügend Experten 

mit den entsprechenden Kompetenzen gegenüberstehen. In diesem Fall ist es wichtig, durch 

kurzfristigen Know-How-Transfer den bestehenden Engpass zu überbrücken, indem die vorhandenen 

Experten als Multiplikatoren eingesetzt werden. In beiden Fällen hilft der KO- 

WIEN-Prototyp dabei, die im Unternehmen vorhandenen Kompetenzen transparent zu machen 

und Kompetenzlücken aufzudecken. 

In 2.2 wurde beschrieben, wie die Ausbildungsziele und die Teilnahmevoraussetzungen von 

Qualifizierungsmaßnahmen zentral erfasst werden können. Diese detaillierten Informationen 

über Qualifizierungsmaßnahmen sind zusammen mit den Analysemöglichkeiten zur Aufdeckung 

von Kompetenzlücken eine ideale Basis für die Beantwortung der Frage, welche Mitarbeiter 

an welcher Qualifizierungsmaßnahme teilnehmen sollten. Der KOWIEN-Prototyp unterstützt 

jeden einzelnen Mitarbeiter dabei, diese Frage für sich selbst zu beantworten und sich 

aus dem Pool von Qualifizierungsmaßnahmen, die ihm sein Unternehmen anbietet, die Kurse 

herauszusuchen, die für ihn geeignet sind und ihn auf die Ausübung einer angestrebten Jobfunktion 

vorbereiten. Ermöglicht wird die Beantwortung dieser Frage durch die Zuordnung 

von Kompetenzanforderungen zu Jobfunktionen, die Bestandteil der Funktionalität des KO- 

WIEN-Prototyps ist, d.h. neben den sog. Ist-Kompetenz-profilen für Mitarbeiter können mit 

dem KOWIEN-Prototyp auch sog. Soll-Kompetenzprofile für Jobfunktionen gepflegt werden. 

Durch eine spezielle Analysefunktion wird die Planung von Qualifizierungsmaßnahmen unterstützt, 

indem transparent gemacht wird, welche Qualifizierungsmaßnahmen für welche Jobfunktionen 

wichtig sind. Diese Funktionalität ist besonders für Unternehmen interessant, die 

auch selber ausbilden (z.B. im Rahmen von Trainee-Programmen oder einer Corporate University), 

da damit auch die Mitarbeiter, die das Qualifizierungsangebot planen, eine gute Entscheidungsgrundlage 

haben, um die Inhalte und die Häufigkeit der Durchführung von Qualifizierungsmaßnahmen 

bedarfsgerecht festzulegen. 

Wenn in einer bestimmten Unternehmensabteilung ein Personalbedarf offensichtlich wird, 

weil das vorhandene Abteilungspersonal die übertragenen Aufgaben nicht alleine bewältigen 

kann, dann hat der Abteilungsleiter die Möglichkeit, über das KOWIEN-System eine Personalbedarfsmeldung 

einzugeben. Die Personalabteilung kann die abgegebenen Personalbedarfsmeldungen 

mit Hilfe des Kompetenzmanagementsystems analysieren und entsprechende 

Stellenausschreibungen vorbereiten, die zunächst nur unternehmensintern bekannt gemacht 

werden. Wenn sich ein Mitarbeiter einer anderen Abteilung auf eine solche unternehmensinterne 

Stellenausschreibung hin meldet, kann ein Gespräch zwischen diesem Mitarbeiter, dem 

Einsteller der Personalbedarfsmeldung und Vertretern der Personalabteilung vereinbart werden, 

bei dem u.a. mit Hilfe des ontologiebasierten Kompetenzmanagementsystems besprochen 

werden kann, ob sich der interne Bewerber grundsätzlich für die ausgeschriebene Stelle 

eignet und ob es sinnvoll und zeitlich möglich ist, dass er zur Vorbereitung auf seine zukünftigen 

Aufgaben vorher noch an einer Qualifizierungsmaßnahme teilnimmt. Wenn sich kein interner 

Mitarbeiter auf die Stelle bewirbt, wird die Ausschreibung öffentlich gemacht, um zusätzliches 

Personal zu rekrutieren. Die Lebensläufe der eintreffenden Bewerbungen könnten 

dann nach einer Vorauswahl wie in 2.1 beschrieben ins Kompetenzmanagementsystem eingegeben 

werden, um eine Entscheidungsgrundlage für die Einstellungsgespräche zu schaffen. 

Die Visual Search und die Kontext-Navigation von infonea® machen das hier beschriebene 

Kompetenzmanagementsystem auch zu einer Art Cockpit, das es ermöglicht, die Kompetenzen 

des ganzen Unternehmens zu analysieren und die Unternehmensentwicklung durch gezielte 

Kompetenzentwicklung zu steuern. So kann die Personalabteilung mit einer Visual 

Search über alle Kompetenzaussagen und -erfahrungen sofort sehen, wie sich z.B. zu bestimmten 

Fachgebieten die Kompetenzen und Erfahrungen auf Abteilungen und Standorte 

172


verteilen oder wie für eine Auswahl von Abteilungen die Verteilung der Kompetenzen zu einen 

Fachgebiet aussieht. 

Zu guter letzt sei noch erwähnt, dass der KOWIEN-Prototyp neben der Pflege von Personenkompetenzprofilen 

auch die Möglichkeit bietet, Kompetenzprofile für Teams zu erstellen und 

zu pflegen. Teams können durch ihre optimale Zusammenstellung und einer guten Zusammenarbeit, 

die sich in konkreten Projekten bewährt hat, Fähigkeiten für das Unternehmen 

entwickeln, die weit über die Summe der Fähigkeiten der einzelnen Teammitglieder hinausgeht. 

Daher sind neben den Kompetenzen der Mitarbeiter auch die Kompetenzen von Teams 

wichtige Bausteine des Unternehmenswertes, deren Management sich lohnt. Das ontologiebasierte 

und prozessorientierte Kompetenzmanagementsystem, das im Rahmen des KOWIEN- 

Projekts entwickelt worden ist, versetzt die Mitarbeiter in leitenden Funktionen dazu in die 

Lage, die Entwicklung der Unternehmenskompetenzen zielorientiert zu steuern und hilft allen 

Mitarbeitern des Unternehmens, sich beruflich weiterzuentwickeln und die eigenen Kompetenzen 

ins Unternehmen einzubringen. 


APKE (2003) 

Apke, S.: Konstruktion einer Kompetenz-Ontologie, dargestellt am Beispiel der Deutschen 

Montan Technologie GmbH (DMT), Diplomarbeit, Fachbereich Wirtschaftswissenschaften 

der Universität Duisburg-Essen, Essen 2003. 

DIN 1463 (1987) 

Deutsche Industrienorm 1463 zur Erstellung und Weiterentwicklung von Thesauri, 1987. 

173


7 jagusch 

1 Ausgangssituation 

„Methodos“ – ein Methodenbaukasten 

zur effizienten Produktentwicklung 

STEFAN LÖFFLER; BURKHARD JAGUSCH 

Empirische Untersuchungen haben gezeigt, daß in der Praxis multiple Methoden für Produktentwicklungen 

nur zögerlich eingesetzt werden, obwohl deren Bedeutung für das Innovationsvermögen 

bekannt ist. Einerseits wird das methodische, systematische Vorgehen als eine 

Grundvoraussetzung für ein effizientes Erreichen von Zielen anerkannt, andererseits wird in 

der Praxis kaum davon Gebrauch gemacht [Ehr 1995]. 

Eine auf Initiative des Berliner Kreis durchgeführte Untersuchung über die Verbreitung von 

Produktentwicklungsmethoden in der Praxis hat ergeben, daß besonders in den frühen Phasen 

des Entwicklungsprozesses (Klären der Aufgabenstellung, Erarbeiten einer Prinziplösung) 

kaum methodisch gearbeitet wird. Außerdem ist zu beobachten, daß Methoden häufig falsch 

angewendet werden, aufgrund fehlender Anwenderkenntnisse bezüglich Ziele, Grenzen und 

Möglichkeiten von Methoden [Zan 1999]. 

Die Ursachen für den zögerlichen Methodeneinsatz in der Praxis sind vielfältig. Häufig wird 

die Theorielastigkeit und praxisferne, sehr abstrakte und zu allgemeine Methodenbeschreibung 

als ein wesentlicher Ablehnungsgrund genannt. Untersuchen haben gezeigt, daß der erhöhte 

Zeiteinsatz bei der Methodenanwendung bzw. die fehlende Zeit zum Aufbau von Methodenkompetenz 

parallel zum Tagesgeschäft eine weitere wesentliche Barriere darstellt [Gau 

2000]. Zudem ist es angesichts der enormen Methodenvielfalt für potentielle Anwender fast 

unmöglich, den Überblick im „Methodendschungel“ zu behalten. Allein die Fülle an Kreativitätstechniken 

kann sehr schnell zu einer Verwirrung und Desorientierung und schließlich zu 

einer Resignation führen. Auch das umfangreiche Schrifttum zu den jeweiligen Methoden 

kann diesen Umstand kaum entschärfen. 

Ein wesentliches Ziel des Verbundprojektes GINA stellt die Verbreitung und Implementierung 

von Methoden in kleinen und mittelständischen Unternehmen dar, mit denen Innovationsprozesse 

in kooperativen Entwicklungsprojekten erfolgreicher durchgeführt werden können. 

Der Fokus liegt hierbei auf dem Einsatz von Methoden zur Analyse, Gestaltung, Steuerung 

und Bewertung von betrieblichen und überbetrieblichen Entwicklungsvorhaben. Hierzu 

wurde ein Konzept für einen Methodenbaukasten entwickelt und mit Hilfe des Projektpartners 

SBS-Softwaresysteme GmbH programmiertechnisch umgesetzt, der in den folgenden Kapiteln 

vorgestellt wird. 

2 Das Internetportal „Methodos“ 

Es gibt verschiedene Methoden, die das gleiche Ziel verfolgen. So existieren z.B. eine Vielzahl 

von Kreativitätstechniken, die aus vorhandenen Informationen (Eingangsgrößen) Ideen 

(Ausgangsgrößen) generieren. Die Unterschiede dieser Techniken liegen z.B. im für die 

Durchführung erforderlichen Aufwand (zeitlich, finanziell etc.), in notwendigen Qualifizie- 

175

„Methodos“ – ein Methodenbaukasten zur effizienten Produktentwicklung 

rungen der Anwender oder Werkzeuge zur Unterstützung der Methodendurchführung (z.B. 

spezielle Software). 

Eine Hilfestellung zur groben Orientierung bezüglich der vielfach einsetzbaren Methoden bieten 

sog. Methodenbaukästen, die eine strukturierte Sammlung von Methoden enthalten, die 

für bestimmte Arbeitsabschnitte eines Prozesses eingesetzt werden können. Sie enthalten 

mögliche Methoden-Alternativen mit sehr kurz gefaßten Hinweisen auf das Prinzip und eine 

Grobklassifizierung über die Eignung der Methoden innerhalb verschiedener Arbeitsabschnitten. 

Tiefergehende Informationen sind über die angegebenen Literaturhinweise erhältlich. Für 

Entwickler und Konstruktionsingenieure sind zur Durchführung vielfältiger Tätigkeiten von z. 

B. [Pah1997], [VDI2221], [Ehr1995] Methodensammlungen erstellt worden. 

2.1 Beschreibung des Methodenassistenzsystems „Methodos“ 

Das unter dem Arbeitstitel „Methodos“ (Methodos: griech., „der Weg zu einem bestimmten 

Ziel“) entwickelte System hat das übergeordnete Ziel, das methodische, strukturierte Arbeiten 

in der industriellen Praxis zu stimulieren und zu fördern. Für diesen Zweck wurde eine Methodensammlung 

erstellt, die grundlegende Methoden und Werkzeuge enthält, die ein fachungebundenes, 

allgemein anwendbares und methodisch-strukturiertes Vorgehen im Bereich 

komplexer technischer Aufgaben ermöglicht. Die Anwender sollen während des gesamten Innovationsprozesses 

auf eine übersichtliche, gut strukturierte und leicht zu bedienende Methodensammlung 

zugreifen können, in der alle wichtigen Informationen für den Methodeneinsatz 

in der Praxis enthalten sind. Dadurch soll eine effektive, methodische Vorgehensweise bei der 

Entwicklung und Umsetzung von Innovationen unterstützt werden. 

Das Methodenassistenzsystem „Methodos“ ist ein plattformunabhängiges Internetportal, welches 

unter der Adresse http://user.gina-net.de/main zu erreichen ist. Der Zugang ist für kostenfrei 

und ohne Einschränkungen. Das System besteht aus folgenden Grundbausteinen: 

• Methodensammlung zur systematischen Produktentwicklung, 

• Methoden-Auswahlunterstützung, 

• Methoden-Software, die ausgewählte operative Werkzeuge den Anwendern zur Verfügung 

stellt. 

In den folgenden Kapiteln wird näher auf diese Grundfunktionen eingegangen sowie Bedienung 

und Aufbau kurz erläutert. 

2.2 Strukturierte Methodensammlung 

zur Unterstützung des Innovationsprozesses 

„Methodos“ enthält eine Sammlung von ca. 80 Methoden, die im Zuge eines Innovationsprozesses 

Anwendung finden können, beginnend mit einer ersten Analyse der Produktumgebung, 

Generierung von Ideen und Konzepten bis hin zur Produkteinführung. Das System enthält für 

jede Methode folgende Informationen in einer standardisierten, übersichtlichen Darstellung 

bereit (s.a. Abbildung 1): 

• praxisgerechte Kurzbeschreibung, 

• Angaben über Arbeitsschritte zur Durchführung einer Methode, 

• Angaben zu Stärken und Schwächen, 

176


• Anwendungsbeispiele, 

• Angaben zu Richtlinien und Normen, 

• weiterführende Literaturhinweise. 

Mit Hilfe dieser stichpunktartigen Angaben wird der Anwender in die Lage versetzt, sich einen 

ersten groben Überblick über eine Methode zu verschaffen. Sofern gewünscht, besteht die 

Möglichkeit, sämtliche Angaben in einem gesonderten Dokument als Download zu erhalten. 

Abbildung 1: Einträge zur Methode „Brainstorming“ (Ausschnitt) 

Weiterhin werden zahlreiche Formblätter, Checklisten sowie einfach zu bedienende Excel- 

Sheets bereitgestellt, die bei der Anwendung der Methode unterstützend eingesetzt werden 

können. So wurden z.B. für die Bewertungsmethoden „Paarweiser Vergleich“ und „Nutzwertanalyse“ 

Berechnungstabellen erstellt, die die Benutzung erheblich vereinfachen. Diese 

Hilfsmittel sind per Download abrufbar sowie benutzungsspezifisch erweiter- und anpaßbar. 

Anzumerken ist, daß die Methodensammlung keinen Anspruch auf Vollständigkeit erhebt. Es 

wurde bewußt auf die Aufnahme zahlreicher Methoden verzichtet, die sich teilweise nur in 

Nuancen von bereits integrierten Methoden unterscheiden. Allein für das Gebiet der Kreativitätstechniken 

besteht eine große Anzahl an Methoden, die sich bei genauer Betrachtung sehr 

ähneln. So existieren beispielsweise etliche Derivate von Brainwriting-Methoden, die jedoch 

keinen signifikanten Mehrwert im Vergleich zur „Urmethode“ bieten. Diese „Ableger“ wurden 

daher nicht mit ins System aufgenommen. 

177


2.3 Unterstützung des Anwenders bei der Methodenauswahl 

Eine optimale Methodenauswahl zur Durchführung verschiedener Arbeitsschritte erfordert eine 

klare Zielvorstellung des Anwenders bezüglich der durchzuführenden Aufgabenstellung. 

Eine gezielte Suche nach unterstützenden Methoden macht erst dann Sinn, wenn das zu erreichende 

Ziel feststeht. Bei der Gestaltung des Systems wurde besonders auf eine hohe Benutzungsfreundlichkeit 

geachtet. Für die Methodensuche und -auswahl bedeutet das, daß dem 

Anwender eine möglichst praxisnahe und vielfältige Möglichkeit zur Suche angeboten wird. 

Folgende Suchfunktionen werden dabei angeboten: 

• Stichwortsuche, 

• Zugriff mittels eins Methodenindex, 

• Suche nach Tätigkeiten im Entwicklungsprozeß, 

• Methodenauswahl anhand von Methodenklassen/-gruppen. 

Eine rein textuelle Suche, bei der die Datenbank nur nach Stichworten durchsucht und eine 

Liste mit den Suchergebnissen ausgegeben wird, ist lediglich als eine nützliche Zusatzfunktion 

zu betrachten und würde als alleinige Auswahlunterstützung kaum ausreichen. 

Das gleiche gilt für die Suchunterstützung mittels eines Methoden-Index. Diese alphabetische 

Methodenliste eignet sich für Anwender, die gezielt Informationen über eine Methode in Erfahrung 

bringen möchten, für die zumindest der Methodenname bekannt sein muß. Falls jedoch 

ein Anwender Möglichkeiten bzw. Methoden sucht, mit denen z.B. Prognosen oder Szenarien 

erstellt werden können, um mögliche zukünftige Entwicklungen abzubilden, jedoch auf 

diesem Gebiet keinerlei Vorwissen besitzt und kein methodisches Vorgehen zur Lösung der 

Aufgabe anwenden kann, ist diese Selektionsmöglichkeit dementsprechend völlig ungeeignet. 

178


2.3.1 Auswahlunterstützung mit Hilfe strukturierter Methodenklassen 

Eine sinnvolle Suchunterstützung kann bereits durch eine praxisnahe Strukturierung aller im 

System befindlichen Methoden erfolgen. In der Literatur sind vielfältige Vorschläge für eine 

solche Methodenklassifizierung zu finden, z.B. Klassifizierung 

nach dem Anwendungsgebiet, dem Verwendungszweck, 

nach dem allgemeinen Vorgehen 

bei der Problemlösung, nach dem Einsatzzweck, 

nach charakteristischen Merkmalen, nach Tätigkeitsbereichen 

etc. Weiterhin lassen sich Methoden bezüglich 

der Aufgabenstellung und Zielsetzung 

zweckmäßig in Methodenklassen und Methodengruppen 

unterteilen. Methodenklassen können mehrere 

Methodengruppen enthalten, denen wiederum 

Elementarmethoden zugeordnet werden können. 

Dieser Ansatz wurde bei der Umsetzung des Methodensystems 

„Methodos“ angewandt. Problematisch 

bei diesem Ansatz ist, daß keine eindeutige Methodenzuordnung 

möglich ist und eine Methode durchaus 

in mehreren Methodenklassen sinnvoll eingeordnet 

werden kann. Dieser Fall tritt vor allem bei solchen 

Methoden auf, die universell für verschiedenste 

Aufgabenbereiche einsetzbar sind. 

Die Methodenklassen (vgl. Abbildung 2) sind zum 

größten Teil selbsterklärend und ermöglichen dadurch 

ein einfaches Auffinden geeigneter Methoden. 

Zur Unterstützung der Suche und zur ersten Groborientierung 

werden zudem für jede Methodenklasse Abbildung 2: Methodenklassen 

stichpunktartig wesentliche Zielsetzungen angegeben, die mit dem Anwenden der Methoden 

erreicht werden können (vgl. Tabelle 1). 

Die Zielsetzungen sind charakteristisch für eine schwerpunktmäßige Eigenschaft einer Methode. 

Diese Angaben werden in einem separaten Fenster eingeblendet. 

Methodengruppe Zielsetzungen 

Problem erkennen, 

Problembeschreibung 

Situationsanalyse 

Zielsuche, 

Zielfestlegung 

- Aufgabe strukturieren 

- Problem-/Aufgabendefinition 

- Problem-/Ursachenerkennung 

- Aufgabenbeschreibung 

- Ist-Zustand erfassen 

- Untersuchungsschwerpunkte erkennen 

- Zieldefinition 

- Zielvereinbarung 

- Zielvorgabe 

Tabelle 1: Zielsetzungen für die Methodenklasse „Aufgabenformulierung“ 

179


2.3.2 Auswahlunterstützung anhand des Konstruktionsprozesses 

In der Literatur existieren eine Vielzahl von verschiedenen Referenzprozeßketten bzw. Phasenmodelle, 

die den Produktentstehungprozeß abbilden und ein strukturiertes Vorgehen zur 

Lösung von Konstruktionsaufgaben unterstützen, in dem typische Aufgaben mit Hilfe methodischer 

Arbeitsweisen gelöst werden. Prinzipiell gleichen sich die Prozeßmodelle in wesentlichen 

Punkten, nur die Ausgestaltung der Phasen ist je nach behandelter Problemstellung unterschiedlich 

detailliert. Das hier angewendete Modell basiert im Wesentlichen auf [Bra 

2002], [VDI 2221] sowie [VDI 2220]. Bei diesem idealtypischen, abstrakten Phasenmodell 

werden keineswegs alle Phasen in einer fest definierten Reihenfolge durchlaufen bzw. einzelne 

Vorgehensschritte gleich intensiv abgearbeitet. Ziel ist die Zerlegung des Werdegangs einer 

Lösung in überschaubare, zeitlich-logische Teiletappen mit definierten Kontrollpunkten 

zu gliedern. Folgende Phasen werden hierbei unterschieden: 

• Zielbildung, 

• Zukunftsanalyse, 

• Lösungsfindung, 

• Lösungsbewertung, 

• Konzeptbewertung, 

• Umsetzungsplanung. 

Dieses Phasenmodell allein reicht jedoch nicht aus, um den Anwender an geeignete Methoden 

heranzuführen, da es viel zu grob gegliedert ist. Innerhalb jeder Phase sind verschiedene Tätigkeiten 

bzw. Arbeitsschritte zu absolvieren, die allesamt durch das Anwenden verschiedenster 

Methoden unterstützt werden können. Für jede Prozeßphase wurden typische durchzuführende 

Tätigkeiten aufgeführt, die wiederum mit Hilfe verschiedenster Methoden umgesetzt 

werden können. So könnte z.B. innerhalb der Prozeßphase Ideenfindung eine Analyse der 

Aufgabe mit Hilfe der „Funktionsanalyse“, die Generierung und schließlich eine Strukturierung 

der Ideen mit der Methode „Brainstorming“ bzw. mit Hilfe des „Morphologischen Kastens“ 

erfolgen. Generell werden alternativ einsetzbare Methoden mit einer kurzen Beschreibung 

aufgelistet. Letztendlich muß der Anwender selbst entscheiden, welche Methode seinen 

Bedürfnissen am besten entspricht. Für diese Entscheidung stehen ihm Informationen über 

Randbedingungen für den Einsatz der jeweiligen Methoden sowie Angaben zu Stärken und 

Schwächen zur Verfügung. 

2.4 Umgesetzte Softwaretools zur Methodenunterstützung 

Ein wesentliches Ziel von „Methodos“ ist die Möglichkeit des operativen Arbeitens mit einer 

begrenzten Zahl von softwaretechnisch umgesetzten Methoden. In dieser Eigenschaft unterscheidet 

sich das Methodenassistenzsystem „Methodos“ von herkömmlichen Methodensammlungen, 

bei denen nur theoretisches, meist sehr abstraktes Wissen abrufbar ist. Folgende 

Softwarewerkzeuge wurden im Zuge des GINA-Projektes umgesetzt und können direkt aus 

dem „Methodos“-Portal gestartet werden: 

• TRIZ-Tool, 

• Funktionsgrößenmatrix physikalischer Effekte, 

• Konstruktionskatalogsystem „eKat“, 

180


• Audit-Tool „ImpACT“. 

In den folgenden Kapiteln werden die Softwarewerkzeuge kurz erläutert. 

2.4.1 Beschreibung des TRIZ – Tools 

Die Bezeichnung TRIZ steht für das russische Akronym "Theorie des erfinderischen Problemlösen". 

Die Methodik wurde vor ungefähr 50 Jahren von Genrich Saulowitch Altschuller 

in der ehemaligen UdSSR konzipiert. Hinter TRIZ verbirgt sich eine komplexe Problemlösungsmethodik, 

die aus mehreren Werkzeugen besteht und das Überwinden von Denkblockaden 

sowie eine schnelle und gezielte Lösungssuche ermöglichen soll. Detaillierte Ausführungen 

zur dieser Theorie sind der gängigen Literatur [Alt 1984], [Gim 2000] oder [Pan 2001] zu 

entnehmen. 

Altschuller analysierte u.a. zahlreiche Patente und erkannte ein Muster in der Lösung von 

Problemstellungen, welches unabhängig von den betrachteten Industriezweigen war. Häufig 

traten zwei Sachverhalte oder Eigenschaften miteinander in Konflikt, die meist auf ähnliche 

Art und Weise gelöst wurden. Altschuller formulierte 40 innovative Grundprinzipien, auf die 

alle untersuchten Erfindungen zurückzuführen sind. Ferner abstrahierte er jedes Patent auf einen 

grundlegenden Zielkonflikt bzw. Widerspruch, den es zu lösen galt. Ein technischer Widerspruch 

bzw. Konflikt liegt dann vor, wenn durch Verbesserung eines technischen Systemparameters 

sich ein anderer technischer Systemparameter verschlechtert. Beispielsweise soll 

das Gewicht eines Autos reduziert werden, um den Spritverbrauch zu senken, gleichzeitig leidet 

hierunter aber die Stabilität. Zur Beschreibung dieser technischen Widersprüche definiert 

Altschuller 39 technische Parameter, mit denen es möglich ist, die unterschiedlichsten Aufgabenstellung 

auf eine abstrakte Weise zu beschreiben. Diese 39 technischen Parameter wurden 

in einer 39x39-Matrix gegenüber gestellt. Die analysierten Patente wurden daraufhin untersucht, 

welche der 40 innovativen Prinzipe am erfolgreichsten die Widersprüche gelöst haben. 

Das Verknüpfen der Parameter mit den Innovationsprinzipien führte zu der sog. Widerspruchsmatrix 

(s. Abbildung 3). Die in den Kreuzungsfeldern hinterlegten Zahlen stehen für 

die Innovationsprinzipe, die beim Lösen eines Konfliktes bereits in zahlreichen Patenten Anwendung 

gefunden haben. 

181


Abbildung 3: Ausschnitt aus der Widerspruchsmatrix 

Diese Widerspruchsmatrix kann nun zum Auffinden von Lösungen für neue Problemstellungen 

herangezogen werden. Sie unterstützt dabei vor allem die Phase der Konzeptentwicklung, 

in dem sie den Anwender zunächst von der konkreten Problemebene wegführt. Eingefahrene 

Denkmuster können somit überwunden werden. Die vorgeschlagenen Innovationsprinzipe 

sind nur eine Inspirationsquelle und keine „Blaupause“. 

Neben einer Kurzbeschreibung zum Anwenden des Prinzips sind im TRIZ-Tool für jedes Innovationsprinzip 

Detailseiten (s. Abbildung 4) abrufbar, auf denen zahlreiche Praxisbeispiele 

aufgeführt sind, bei denen das vorgeschlagene Prinzip bereits Anwendung gefunden hat. 

182


Abbildung 4: Auszug der Detailseite für das Prinzip „Vorherige Wirkung“ 

Diese Praxisbeispiele sind besonders für solche Anwender gut geeignet, die noch wenig Erfahrung 

mit dem Anwenden der z.T. sehr abstrakten Beschreibung der Innovationsprinzipe 

haben. 

2.4.2 Funktionsgrößenmatrix - Sammlung physikalischer Effekte 

Die Funktionsgrößenmatrix (FGM) ist ein Hilfsmittel zur Generierung von ersten Prinziplösungen. 

Sie unterstützt das Auffinden erster Lösungen für eine gegebene verbale Aufgabenstellung 

unter Zuhilfenahme physikalischer Beziehungen. Funktionsgrößen sind solche Größen, 

die sich während des Funktionsvorgangs verändern (z.B. Kraft, Druck, Moment etc.). 

Dagegen sind Konstruktionsgrößen mit der Konstruktion festgelegt und dienen zur Realisierung 

der Funktion. Eine Matrix (s. Abbildung 5) bietet eine übersichtliche Möglichkeit zur 

gezielten Suche nach physikalischen Gesetzen und Axiomen, die unter dem Sammelbegriff 

„Effekte“ geführt werden, in dem die Funktionsgrößen einmal als Zeile und einmal als Spalte 

aufgetragen werden. Im Kreuzungsfeld zweier Größen ist eine Sammlung physikalischer Beziehungen 

hinterlegt, welche beide Größen miteinander über einen Effekt verknüpft. 

Die in [Rot 1994] aufgeführte Effektsammlung diente als Basis für die Umsetzung der Matrix 

in ein internetbasiertes Werkzeug. Verglichen mit der „Papierversion“ bietet das FGM- 

Werkzeug einige Vorteile in der Anwendung. Die Effektsammlung ist in Form einer Datenbank 

hinterlegt und via Internet plattformunabhängig für Jedermann frei zugänglich. Durch 

einfaches Anklicken der Kreuzungsfelder werden die dazugehörigen physikalischen Effekte 

in einer Tabelle aufgelistet. Zu jedem Effekt existiert zudem eine Detailseite, die den ausgewählten 

Effekt näher beschreibt (s. Abbildung 6). 

183


Abbildung 5: Zugriff auf physikalische Effekte über die Funktionsgrößenmatrix 

184


Abbildung 6: Detailseite für den „Magnus-Effekt“ 

Es besteht nicht zwischen allen aufgeführten Größen eine direkte quantifizierbare Beziehung - 

zu erkennen an den hellblauen und orangen Felder in der Matrix. Für diesen Fall ist es möglich, 

über zwei bzw. drei hintereinandergeschalteten Effekte (sog. Effektketten) eine Beziehung 

zwischen diesen Größen aufzubauen. Soll z.B. eine Beziehung zwischen der Eingangsgröße 

„Impuls pi“ und der Ausgangsgröße „Verschiebung s“ hergestellt werden (d.h. s=f(pi) ), 

so kann dieser Zusammenhang über drei Effektketten mit den Zwischengrößen Kraft, Geschwindigkeit 

und Winkelgeschwindigkeit realisiert werden. Anzumerken ist, daß das FGM- 

Werkzeug nur alle theoretisch denkbaren Effektketten auflistet. Es liefert jedoch keine konkreten 

Lösungen, sondern ist als Ideengeber zu betrachten. Die konkrete Umsetzung liegt allein 

in der Hand des Anwenders. 

2.4.3 Konstruktionskatalogsystems „eKat“ 

Konstruktionskataloge sind unter methodischen Gesichtspunkten erstellte Wissensspeicher, 

die innerhalb eines gewissen Rahmens systematisch gegliedert sind und einen gezielten 

Zugriff auf ihren Inhalt erlauben. Sie bestehen aus einem Gliederungs-, Haupt- und 

Zugriffsteil. Sie dienen der Lösungsanregung oder -übernahme durch systematische Zuordnung 

bekannter Lösungsmerkmale zu den Bedingungen der Aufgabenstellung [Rot 1994]. In 

der Literatur sind zahlreiche Konstruktionskataloge für die unterschiedlichsten Aufgaben zu 

finden. Darüber hinaus existieren Übersichten vorhandener Kataloge, z.B. in [Pah 1997], die 

nach Anwendungsgebieten (z.B. Verbindungen, Führungen, Getriebe etc.) gegliedert sind und 

auf die dementsprechende Literatur verweisen. Sehr häufig tritt jedoch der Fall auf, daß diese 

Quellen nur sehr umständlich zu beschaffen sind. Daher wird häufig auf die Verwendung dieser 

doch sehr ergiebigen Ideenquellen verzichtet. 

185


Das internetbasierte Konstruktionskatalogsystem „eKat“ dient zum Erstellen, Speichern und 

Darstellen von Konstruktionskatalogen und bietet im Vergleich zu herkömmlichen, papierbasierten 

Katalogen den Vorteil eines schnellen, browser- und plattformunabhängigen Zugriffs 

auf bewährte Konstruktionskataloge. Die Editierfunktionen sind nur über einen paßwortgeschützten 

Bereich für Administratoren erreichbar und bleiben für Anwender verborgen. Für 

sie stehen diverse Darstellungsfunktionen zur Verfügung, z.B. Ein-/Ausblenden, Möglichkeit 

einer benutzerspezifischen Strukturierung und Sortierung der Katalogeinträge etc., die ein 

möglichst anwendungsfreundliches Arbeiten mit den Katalogen ermöglicht. 

Der Zugriff auf die jeweiligen Kataloge erfolgt über ein Katalogverzeichnis, das nach Anwendungsgebieten 

(s.o.) gegliedert ist. Die im System hinterlegten Kataloge enthalten u.a. 

physikalische Effekte, Wirkprinzipien, prinzipielle Lösungen für komplexe Aufgabenstellungen, 

Maschinenelemente etc. Neben diesen bekannten Katalogen wurde zudem ein Bionik- 

Konstruktionskatalog erstellt, der bionische Prinzipe (z.B. Leichtbauprinzipe, Speicherprinzipe 

etc.) enthält, die für technische Problemstellungen als Inspirationsquelle herangezogen 

werden und als Ideenquelle fungieren können. 

2.4.4 Audit-Tool ImpACT 

Das Innovationsaudit ist ein Evaluierungsverfahren zur Bewertung des Innovationsmanagements 

in einem Unternehmen. Ziel dieses Verfahrens ist, Schwachstellen im Innovationsmanagement 

zu erkennen (z.B. Schwachstellen in der 

Innovationsstrategie oder Schwachstellen im Ideenfindungsprozeß 

etc.) sowie die Bedeutung der 

identifizierten Schwachstellen zu bewerten. Die 

Basis des Innovationsaudits ist ein qualitatives 

Kriterienmodell, welches umfassend die wichtigsten 

Aspekte im Innovationsmanagement sowie relevante 

Aspekte der Kooperationsfähigkeit im Innovationsprozeß 

beschreibt. Die Durchführung 

des Innovationsaudits liegt bei einem Auditor, der 

im Rahmen einer Datenaufnahme die Relevanz 

und die Ausprägung eines Bewertungskriteriums 

bestimmt. Diese Daten können dabei sowohl von 

einem Mitarbeiter des untersuchten Unternehmens 

als auch von einem externen Berater aufgenommen 

werden. Geeignete Methoden sind die Durchführung 

von strukturierten Interviews sowie die 

Sichtung relevanter Dokumente (z.B. Formulare 

zur Ideenbewertung) und der Informations- und 

Kommunikationsstruktur (z.B. Serverstrukturen). 

Das unter dem Arbeitstitel „ImpACT“ (Innovation 

Management and Process Assessment and Control 

Tool) umgesetzte Softwaretool unterstützt einen 

Auditor bei der vorbereitenden Erstellung von Interviewchecklisten, 

bei der Auswertung der aufgenommen 

Daten sowie der Speicherung von Auditergebnissen. Die rechts stehende Abbildung 

zeigt den idealtypischen Ablauf der Innovationsauditierung. 

186


Für die Vorbereitung eines Audits wählt der Anwender über eine Bildschirmmaske die Kriterien 

aus dem Kriterienmodell aus, die im Rahmen der Unternehmensuntersuchung berücksichtigt 

werden sollen. Dabei wird auch die Option angeboten, durch den Verweis auf Literaturstellen 

oder im System abgelegten Dokumenten weitere Informationen und weiteres Wissen 

zu einem Kriterium abzurufen. 

Wenn die Auswahl abgeschlossen ist, werden durch das Softwarewerkzeug strukturierte Interviewchecklisten 

bereitgestellt, die ausgedruckt werden können. Die unternehmensspezifische 

Bewertung der Kriterien erfolgt durch Interviews, Dokumentenanalyse und weiteren Beobachtungen. 

Nach der Analyse im Unternehmen gibt der Anwender seine kriterienspezifische 

Bewertung über eine Eingabemaske ein. Dabei kann er zwischen 0% (keine Ausprägung 

des Kriteriums feststellbar) und 100% (sehr hohe Ausprägung des Kriteriums feststellbar) 

wählen. Weiterhin ist es möglich, zu jedem Bewertungskriterium zusätzliche Kommentare 

einzugeben. Wenn die Eingabe vollständig abgeschlossen ist, werden durch die Software verschiedene 

Auswertungsoptionen angeboten. 

3 Ergebnistransfer 

Die im Rahmen des Verbundprojektes GINA entwickelten Sofwarekomponenten wurden mit 

modernster Softwaretechnologie und auf Basis einer wissenschaftlich abgesicherten Datenbasis 

entwickelt. Es wurden unspezifische Lösungen entwickelt, die auf weitere Anwendungsbereiche 

und Einsatzszenarien problemlos übertragbar sind. Dadurch ist sowohl technologisch 

als auch inhaltlich sichergestellt, daß ein Transfer der in GINA erarbeiteten Projektergebnisse 

- auch für die Nutzung über die am Verbundvorhaben teilnehmenden Partner hinaus - für weitere 

Zielgruppen und Inhalte gegeben ist. 

Die bei der Entwicklung des GINA-Portals eingesetzte Technologie und Softwarewerkzeuge 

sind dementsprechend universell einsetzbar. Mit dem vorhandenen GINA-Portal ist die Basis 

für ein professionelles Self-Managed-Portal geschaffen, daß mit seiner offenen Architektur 

schnell an unternehmensspezifische Anforderungen anpaßbar ist: Ob nun als Plattform zur 

Unternehmenspräsentation im Internet oder als komplexe angepaßte Unternehmensanwendung 

mit Abbildung kundenspezifischer Geschäftslogik im Intranet oder Extranet. 

Durch die strikte Trennung von Programmlogik und Inhalt kann das Portal im Baukastenprinzip 

um weitere funktionelle Komponenten erweitert und im Bereich der Datenrepräsentation 

einfach an kundenspezifische Gegebenheiten angepaßt werden. 

187



[Alt 1984] 

Altschuller, G.S.: Erfinden – Wege zur Lösung technischer Probleme, VEB Verlag Technik, 

Berlin 1984. 

[Bra 2002] 

Brandenburg, F.: Methodik zur Planung technologischer Produktinnovationen, Dissertation, 

RWTH Aachen, Shaker Verlag, Aachen, 2002. 

[Der 1990] 

Derhake, T.: Methodik für das rechnerunterstützte Erstellen und Anwenden flexibler Konstruktionskataloge, 

Dissertation, Braunschweig, 1990. 

[Ehr 1995] 

Ehrlenspiel, K.: Integrierte Produktentwicklung – Methoden für Prozeßorganisation, Produkterstellung 

und Konstruktion, München, Wien 1995. 

[Gau 2000] 

Gausemeier, J., Lindemann, U., Reinhart G., Wiendahl, H-P.: Kooperatives Produktengineering, 

Paderborn: HNI-Verlagsschriftenreihe Bd. 79, 2000. 

[Gim 2000] 

Gimpel, B., Herb, R., Herb, T.: Ideen finden, Produkte entwickeln mit TRIZ, München, Wien, 

Hanser Verlag 2000. 

[Pah 1997] 

Pahl, G., Beitz, W.: Konstruktionslehre. 4. Aufl., Berlin: Springer-Verlag, 1997. 

[Pan 2001] 

Pannenbäcker, T.: Methodisches Erfinden in Unternehmen, Wiesbaden, Gabler Verlag, 2001. 

[Rot 1994] 

Roth, K.: Konstruieren mit Konstruktionskatalogen, Band I, Konstruktionslehre, Springer- 

Verlag, Berlin Heidelberg New York 1994. 

[Rot 1996] 

Roth, K.: Konstruieren mit Konstruktionskatalogen, Bd. III: Verbindungen und Verschlüsse, 

Lösungsfindung, Berlin: Springer Verlag, 1996. 

[Spe 1994] 

Speckhahn, H.,: Systeme zur flexiblen konfigurierbaren Informationsbereitstellung für die 

Konstruktion, Dissertation, Braunschweig, 1994. 

[VDI 2220] 

VDI-Richtlinie 2220: Produktplanung; Ablauf, Begriffe und Organisation, VDI-Gesellschaft 

Entwicklung Konstruktion Vertrieb, 1980. 

[VDI 2221] 

VDI-Richtlinie 2221: Methodik zum Entwickeln und Konstruieren technischer Systeme und 

Produkte, VDI-Gesellschaft Entwicklung Konstruktion Vertrieb, 1993. 

[Zan 1999] 

Zanker, W.: Situative Anpassung und Neukombination von Entwicklungsmethoden, Dissertation 

Technische Universität München, Shaker Verlag 1999. 

188


5 staub 

Der „Dynamische Kooperationsassistent“: 

IT-gestützte, unternehmensübergreifende 

Kommunikation im Engineering 

GÜNTER STAUB 

Zusammenfassung: Ziel von KOEFFIZIENT ist die Entwicklung eines dynamischen Kooperationsassistenten, 

der Unternehmen einfacher als bisher möglich, zur IT-gestützten, unternehmensübergreifenden 

Kommunikation im Engineering befähigt und damit den Aufbau und die Durchführung 

überbetrieblicher Entwicklungspartnerschaften unterstützt. Damit auch kleine und mittlere 

Unternehmen (KMU) von den entwickelten Lösungen profitieren können, wird bei der Realisierung 

des Kooperationsassistenten auf Einfachheit, Beherrschbarkeit und geringe Investitionskosten 

Wert gelegt. 

1 Ausgangssituation und Handlungsbedarf 

Seit einigen Jahren vollziehen sich grundlegende Veränderungen in den Rahmenbedingungen 

industrieller Produktion. Die heutige Situation ist gekennzeichnet durch global agierende Unternehmen, 

die im Zuge zunehmenden internationalen Wettbewerbs gezwungen sind, ihre 

Strukturen flexibel zu gestalten und sich auf ihre Kernkompetenzen zu konzentrieren, um innovative 

Produkt- und Prozessideen schnell umsetzen zu können. Da kaum ein Unternehmen 

alle erforderlichen Kompetenzen und Kapazitäten für die Entwicklung und/oder die Produktion 

komplexer Produkte vorhalten kann, werden unternehmensübergreifende Wertschöpfungsketten 

gebildet, in denen durch die Einbeziehung qualifizierter und spezialisierter Partner 

Entwicklungszeiten verkürzt, Qualität verbessert sowie die Risiken z.B. im Zusammenhang 

mit der Verwendung neuer Technologien oder Methoden auf ein Minimum reduziert werden. 

Eindrucksvoll wird diese Tendenz belegt durch eine Erhebung des VDA (Verband der Automobilindustrie), 

nach der in der deutschen Automobilindustrie heute im Durchschnitt nur 

noch gut 20 Prozent der Entwicklungsleistung intern erbracht wird, im Vergleich zu 60 Prozent 

noch vor etwas mehr als 10 Jahren. 

Immer komplexer werdende Produkte sowie die stetige Erweiterung der Produktpaletten und - 

varianten seitens der Herstellerfirmen führen allerdings dazu, dass auch Entwicklungspartner, 

ob Lieferanten oder Dienstleister, immer komplexere Subsysteme bearbeiten. Diese weisen 

starke Abhängigkeiten untereinander auf, und zu ihrer Entwicklung müssen neben herkömmlichen, 

im wesentlichen geometriebezogenen Produktdaten in verstärktem Maß auch komplexe 

Strukturinformationen in Form von Stücklisten, Varianten und Konfigurationen verarbeitet 

und mehrmals im Entwicklungsprozess zwischen den Partnern kommuniziert werden. Die 

immer enger werdende Zusammenarbeit von Partnern, Dienstleistern und Lieferanten bereits 

während der Produktentwicklung hat nicht nur einen überproportional steigenden Kommunikationsbedarf 

zur Folge, sondern auch die Forderung nach einer neuen Qualität der Kommunikation 

von digitalen Produktinformationen. Die Fähigkeit zur schnellen und zuverlässigen 

Integration der beteiligten Entwicklungspartner in einen gemeinsamen, unternehmensübergreifenden 

Entwicklungsprozess entwickelt sich dabei immer mehr zu einer strategischen 

Komponente. Ausgewählt wird nur derjenige als Entwicklungspartner, der sowohl über das 

benötigte technische Know-how verfügt, das sich am besten mit den eigenen Kernkom- 

189

Der „Dynamische Kooperationsassistent“: IT-gestützte, unternehmensübergreifende Kommunikation im Engineering 

petenzen ergänzt, der aber auch in der Lage ist, den wachsenden unternehmensübergreifenden 

Kommunikationsanforderungen von digitalen Produktdaten im Entwicklungsprozess quantitativ 

und qualitativ Rechnung zu tragen. 

Heutzutage scheiden KMU in größeren Entwicklungsverbünden als potentielle Partner häufig 

bereits im Vorfeld aus, da diese oftmals nicht über die geeignete informationstechnische Infrastruktur 

verfügen, um schnell und flexibel auf die Anforderungen der Auftrageber in Bezug 

auf eine unternehmensübergreifende, rechnerunterstützte Produktentwicklung reagieren zu 

können. Aber auch die informationstechnische Kommunikation der Engineeringinformationen 

stellt eine wesentliche Barriere zwischen den Partner in einem Engineeringnetzwerk dar, da 

bei den Unternehmen IT-Systeme (PDM, CAD, CAE, CAQ, ERP, etc.) unterschiedlichster 

Anbieter und Funktionalitäten im Einsatz sind. Zusätzlich sind die eingesetzten IT-Systeme 

jeweils an unternehmensspezifischen Gegebenheiten angepasst. Ein Ansatz, der davon ausgeht, 

dass die gleichen IT-Systeme bei allen Partnern eines Engineeringnetzwerks eingesetzt 

werden, wie das bei CAD-Systemen heute noch häufig der Fall ist, ist aufgrund der vielfältigen 

Kunden-Lieferanten-Beziehungen, der nicht geometriebezogenen Produktdaten und der 

heterogenen Systemlandschaft nicht realistisch. 

Um als Partner, sei es nun als enger Entwicklungspartner oder aber als Komponenten- oder 

Teilelieferant auftreten zu können, ist es notwendig neben der Optimierung der Projekt- und 

Prozessorganisation die unternehmensübergreifenden, zunehmend rechnerunterstützten Entwicklungsprozesse 

besser zu beherrschen. Zur Überbrückung dieser Barrieren müssen unter 

anderem folgende Schritte vor dem eigentlichen Start des Entwicklungsprojekts durchgeführt 

werden: 

• Definition des unternehmensübergreifenden, gemeinsamen Entwicklungsprozesses 

und Abstimmung der Entwicklungsprozesse zwischen den Partnern 

Hierzu müssen die Schnittstellenprozesse sowie auslösende Ereignisse und Eingangs- und 

Ausgangsinformationen dieser unternehmensübergreifenden Schnittstellenprozesse identifiziert 

und dokumentiert werden. 

• Festlegung der zwischen den Entwicklungspartnern auszutauschenden Informationen 

und deren Abbildung aufeinander 

Hierbei ist zu berücksichtigen, dass neben den verschiedenen Begriffen und der Bedeutung 

von Informationswerten immer auch eine Abbildung der unterschiedlichen Strukturen 

notwendig ist, um Informationen erfolgreich zwischen den beteiligten Partnern zu kommunizieren. 

• Herstellung der Interoperabilität der Systeme, die im gemeinsamen, unternehmensübergreifenden 

Entwicklungsprozess eingesetzt werden 

Um zu erreichen, dass die bei den Partnern im Entwicklungsprozess eingesetzten IT- 

Systeme zusammenarbeiten, sind geeignete Adapter notwendig, welche die semantische 

Kopplung der eingesetzten IT-Systeme ermöglichen. 

Die Schaffung dieser Voraussetzungen ist zeit- und kostenintensiv, erfordert eine fundierte 

Kenntnis derzeitiger Informations- und Kommunikationstechnologien (I&K) und ist ohne geeignete 

Werkzeuge und entsprechende Erfahrung nicht möglich. Zur Verbesserung dieser Situation 

ist ein neuer Ansatz notwendig, der bestehende Konzepte für gemeinsame überbetriebliche 

Produktentwicklungen mit neuen I&K-Technologien verknüpft und darauf aufbauend 

neue, angemessene Methoden und Werkzeuge bereitstellt, die einen geringen Komplexitätsgrad 

aufweisen und ohne großen personellen Aufwand auch für KMU einsetzbar sind. 

190


2 KOEFFIZIENT im Überblick 

Das übergeordnete Ziel von KOEFFIZIENT ist die organisatorische und informationstechnische 

Beherrschung von Engineeringnetzwerken zur überbetrieblichen Produktentwicklung. Zur 

Ausgestaltung dieser Engineeringnetzwerke werden Methoden und Software-Werkzeuge entwickelt, 

mit denen die in den Partnerunternehmen eingesetzten IT-Systeme miteinander gekoppelt 

werden können. Hierzu gehört auch, dass der aktuelle Zustand der unternehmensübergreifenden 

Engineeringdaten und -Prozesse ermittelt und transparent für alle Beteiligten 

dargestellt werden kann. Der Kooperationsassistent muss hierfür den kontrollierten Zugriff 

auf die relevanten Engineeringdaten aller am Prozess beteiligten Partner ermöglichen. Der 

Ansatz berücksichtigt insbesondere, dass bei den einzelnen Partnern unterschiedliche IT- 

Systeme eingesetzt werden, die flexibel und ohne Änderungen an den IT-Systemen effizient 

in das Lösungskonzept eingebunden werden können. 

Ziel von KOEFFIZIENT ist es, Unternehmen einfacher als heute möglich zur IT-gestützten, 

unternehmensübergreifenden Kommunikation und damit zur zuverlässigen Integration in 

einen gemeinsamen Entwicklungsprozess zu befähigen. Der Kooperationsassistent trägt 

diesem Ziel Rechnung, indem er eine lose informationstechnische Kopplung eines KMU an 

seine Auftraggber (z.B. OEM oder Systemlieferanten von OEM) ermöglicht. Im Gegensatz zu 

einem engen Integrationsansatz erlaubt dieser Ansatz eine von speziellen Kunden weitgehend 

unabhänige unternehmnsübergreifende Zusammenarbeit im Engineering. 

3 Lösungsansatz 


Als Ansatz, der eine Lösung für die eingangs beschriebene Problemstellung wurde im Projekt 

ein dynamischer Kooperationsassistent konzipiert und entwickelt (Abbildung 1), der den 

Aufbau und die Durchführung überbetrieblicher Entwicklungspartnerschaften unterstützt. 

191



ent 

Zulieferer 

Hersteller 

id 

P 

ref 

A C D 

A B C D 

id 

192 

P 

A C 


Dat en- und 


Abbildung 1: Kooperationsassistent zur Durchführung 

überbetrieblicher Entwicklungspartnerschaften 

Dienstleister 

Insbesondere soll der Kooperationsassistent helfen, die Entwicklungspartner sowohl beim 

erstmaligen „Aufsetzen“ der Engineeringprozesskette als auch bei der operativen Durchführung 

des Engineeringprojekts untereinander zu verbinden, unabhängig ob ein Entwicklungspartner 

ein eigenes IT-System für das Engineering im Einsatz hat oder nicht. Eine wesentliche 

Voraussetzung zur Durchführung von digitalen Engineeringprozessen sind interoperable Datenstrukturen, 

definierte Schnittstellen zwischen den Entwicklungsprozessen in den beteiligten 

Unternehmen sowie die Einhaltung von projektspezifischen Vorgaben und Abläufen. Wie 

in Abbildung 1 dargestellt, besteht der Kooperationsassistent aus zwei Kernkomponenten: 

Daten- und Prozessmapping und Kooperationsmanagement: 

• Das Datenmapping dient zur Ausführung der notwendigen strukturellen Transformationen 

der Engineeringdaten in eine vom jeweiligen Partner verständliche und durch seine Systeme 

verarbeitbare Form. Das firmenübergreifende Zusammenspiel der Engineeringprozesse 

wird durch das Prozessmapping geregelt, indem beim Eintreten bestimmter Zustände das 

Partnersystem aktiviert und die notwendigen Engineeringdaten mithilfe des Datenmappings 

bereitgestellt werden. 

• Das Kooperationsmanagement organisiert und verwaltet die Engineeringdaten und die 

Engineeringtransaktionen der Entwicklungspartner. 

Der Ansatz zur Erzeugung und die beteiligten Software-Werkzeuge dieser zwei Komponenten 

sind in Abbildung 2 dargestellt. Des Weiteren werden bzw. wurden, wie im Bild dargestellt, 

eine Reihe weiterer Komponenten (z.B. mehrere Schemaextraktoren zur Extraktion der Metadaten 

der beteiligten IT-Systeme, ein Schemavergleicher zum Vergleich der Metadaten und 

Darstellung ihrer Gemeinsamkeiten und Unterschiede, ein graphisch interaktiver Mappingeditor 

zur einfachen Definition der Abbildung der unterschiedlichen Datenstrukturen ineinander 

sowie Codegeneratoren zur Erzeugung eine ausführbaren Mappingengine) entwickelt. Diese 

Komponenten erfüllen unter anderem die folgenden Funktionen:



Aktivitäten, 

• Abstimmung der auszutauschenden Engineeringdaten und deren Abbildung auf die jeweiligen 




Systeme. 

Gemeinsamkeiten 


Deltas 


ent 

Schema 

Extraktor 

Schema 

Vergleicher 

Schema 

Extraktor 

Abbildungsspezifikation 


PDM- System 1 


PDM- System 2 

grafisch, 

interaktiver 

Mappingmodellierer 

Erzeugung 

Daten- und 


IT-System 1 (z.B. PDM) 

Ereignisse, Kontrollflüsse 

193 

Partner 1 

Partner 2 

IT-System 2 (z.B. ERP) 

gemeinsames 

Datenmodell 


Part ner1 

Prozessmodellierer 


Part ner2 

Datenmodellierer 

Informationsflüsse 

Standards 

(BizTalk, STEP, ...) 

Erzeugung 


Abbildung 2: Lösungsansatz zur Erzeugung des Kooperationsassistenten 

gemeinsamer 


Mit diesem Ansatz wird es zukünftig schneller und kostengünstiger als heute allen Entwicklungspartnern 

möglich sein, auf die im gemeinsamen Entwicklungsprozess anfallenden Daten 

der Partner zuzugreifen, zur direkten Weiterentwicklung in eigenen Systemen zu nutzen und 

sie den anderen Partnern wieder zur Verfügung stellen zu können.


3.2 Realisierung des Kooperationsassistenten 

Im Folgenden ist die Realisierung des Kooperationsassistenten basierend auf einem typischen 

Anwendungsszenarios innerhalb von KOEFFIZIENT beschrieben. 

3.2.1 Betrachtetes Szenario 

An der Abwicklung einer Engineeringdienstleistung, von der initialen Anfrage an potentiell 

mehrere mögliche Engineeringdienstleister, über die Beauftragung und Leistungserbringung 

bzw. Lieferung in Form von digitalen Produktbeschreibungen bis zur deren letztendlichen 

Abnahme durch den Auftraggeber sind jeweils unterschiedliche Abteilungen involviert: 

• Seitens des Auftraggebers ist dies im wesentlichen der Einkauf zu Anfrage und verbindlichen 

Beauftragung der Engineeringdienstleistungen, die Konstruktion zur Bereitstellung 

der notwendigen Informationen und der Abnahme der Engineeringdienstleistung sowie 

oftmals eine Datenaustauschabteilung, deren Aufgabe es ist, die Informationen der Konstruktionsabteilung 

and den Entwicklungspartner zu transferieren bzw. dessen digitale Produktbeschreibung 

entgegenzunehmen und der internen Konstruktionsabteilung in geeigneter 

Form zur Verfügung zu stellen. 

• Seitens des Entwicklungspartners, bei dem es sich in den hier betrachteten Szenarien um 

ein kleineres Ingenieurbüro handelt, ist typischerweise der Vertrieb in die Beantwortung 

der Anfrage sowie in bei der Erstellung des Angebots über die Engineeringdienstleistungen 

involviert. Die Konstruktion des Entwicklungspartners ist üblicherweise bei der Angebotserstellung 

involviert und führt nach der Beauftragung die Engineeringdienstleistung aus 

und liefert diese nach Fertigstellung an den Auftraggeber. 

Um diesem Szenario gerecht zu werden, werden in KOEFFIZIENT die folgenden Engineeringtransaktionen 

unterstützt (Abbildung 3): 

Auftraggeber 

Anfrage 

von Engineeringdienstleistungen 

Angebot 

über Engineeringdienstleistungen 

Auftrag 


Auftragsbestätigung 


Lieferung 


Abnahme 


194 

Auftragnehmer, 

Entwicklungspartner 

Abbildung 3:Überblick über die von KOEFFIZIENT unterstützten Engineeringtransaktionen


• Anfrage 

Der Auftraggeber sendet eine Anfrage über Engineeringdienstleistungen an einen oder 

mehrere potentielle Entwicklungspartner. 

• Angebot 

Ein angefragter potentieller Entwicklungspartner antwortet auf eine zuvor eingegangene 

Anfrage mit einem entsprechenden Angebot. 

• Auftrag 

Nach dem Erhalt der Angebote von den angefragten potentiellen Entwicklungspartnern 

wählt der Auftraggeber das für ihn unter spezifischen Randbedingungen attraktivste Angebot 

aus und vergibt letztendlich einen Auftrag an den Entwicklungspartner über die Engineeringdienstleistungen. 

• Auftragsbestätigung 

Optional kann eine Auftragsbestätigung durch den Entwicklungspartner erfolgen. 

• Lieferung 

Nach Fertigstellung der Engineeringdienstleistungen, ggf. bereits auch zu den im jeweiligen 

Projekt festgelegten Meilensteinen, liefert der Entwicklungspartner die Engineeringdienstleistung 

an den Auftraggeber. 

• Abnahme 

Nach Erhalt der Engineeringdienstleistungen in Form einer digitalen Produktbeschreibung 

werden diese üblicherweise beim Auftraggeber geprüft und die Abnahme (positiv oder negativ) 

an den Entwicklungsdienstleiter übermittelt. Fällt die Abnahme positiv aus, so ist 

das gemeinsame Entwicklungsprojekt im Allgemeinen beendet und die Rechung kann gestellt 

werde. Fällt hingegen die Abnahme negativ aus, so sind entsprechende Nachbesserungen 

seitens des Entwicklungspartners zu leisten und die Verbesserungen erneut zu liefern. 

Zusätzlich ist noch zu beachten, dass im Allgemeinen zu fast beliebigen Zeitpunkten Änderungen 

an Anfragen, Angeboten, Aufträgen und Lieferungen durchgeführt werden können 

und diese natürlich einen Bezug zu den bereits getätigten Anfragen besitzen müssen. Dies 

können z.B. auch Änderungsanfragen zu einer initialen Anfrage noch vor der Erteilung eines 

Auftrags sein. 

Die technischen und kaufmännischen Informationen, die während eines Entwicklungsprojekts 

zwischen den Auftraggeber und Auftragnehmer fließen, werden hierbei oftmals in unterschiedlichen 

IT-Systemen verwaltet und gewartet – die technischen Informationen werden typischerweise 

in PDM-Systemen, die kaufmännischen Informationen hingegen z.B. in ERP- 

Systemen verwaltet. Aufgrund dieser Trennung und der oftmals nicht vorhandenen Integration 

zwischen diesen IT-Systemen ist ein Auseinandertriften der technischen und kaufmännischen 

Informationen vorprogrammiert. Dies liegt neben der ggf. fehlenden Integration der 

ERP- und PDM-Systeme vor allem an den zwei verschiedenen, voneinander getrennten Informationskanälen: 

Während auf den einen nur kaufmännische Informationen von Einkauf 

des Auftraggebers zum Vertrieb des (potentiellen) Entwicklungspartners kommuniziert werden, 

findet auf dem technischen Informationskanal die Kommunikation der Konstruktions- 

oder Entwicklungsabteilungen der Auftraggebers und Auftragnehmers statt. In der Praxis passiert 

es nun relativ häufig, das die beiden Informationskanäle nicht synchronisiert werden und 

daher z.B. Information die über den kaufmännischen Informationskanal gesendet werden und 

sich dabei, z.B. auf Änderungsstände von Teile beziehen, die nicht den aktuellen Änderungszuständen 

in zugrunde liegenden PDM-System entsprechen. So werden z.B. Änderungen an 

den technischen Informationen gar nicht oder zu spät über den kaufmännischen Informations- 

195


kanal mitgeteilt oder kommen nicht am Ziel an. Unnötige/überflüssige Arbeiten auf falscher 

Grundlage und damit im Grunde vermeidbare Kosten sind die Folge. 

3.2.2 Verwendete Standards 

Ziel von KOEFFIZIENT war nicht, neue Standards zu definierten, sondern zur Realisierung der 

beschriebenen Anforderungen und der Szenarien soweit wie möglich auf bestehende Standards 

und Lösungen zurückzugreifen und diese möglichst direkt einzusetzen. 

Um den oben geschilderten Ablauf innerhalb von KOEFFIZIENT mittels dem Kooperationsassistenten 

zu unterstützen, werden zur Repräsentation der Engineeringtransaktionen, welche im 

wesentlichen den kaufmännischen Informationsanteil beinhalten und den Engineeringdaten, 

die den technischen Informationsanteil beinhalten, bereits etablierte Standards genutzt: openTRANS 

wird als Grundlage zur Repräsentation der kaufmanischen Daten, STEP AP214 

(ISO 10303-214) wird direkt zur Repräsentation der Engineeringdaten verwendet. 

openTRANS (www.opentrans.org) ist ein offener, von den Einkäufern von Grossunternehmen 

entwickelter Transaktions-Standard für den automatisierten Austausch von Geschäftsinformationen 

über Internet und elektronische Marktplätze. openTRANS wird vom eBusiness Standardization 

Committee (eBSC) entwickelt, einem starken Industriekonsortium unter technischer 

Leitung von Fraunhofer IAO und Universität Essen mit Unterstützung des BME (Bundesverband 

für Materialwirtschaft, Einkauf und Logistik e.V.). openTRANS wurde erstmals 

zur CeBIT 2001 veröffentlicht und liegt nun in Version 1.0 vor. In dieser Version werden alle 

für den Einkaufsprozess relevanten Geschäftsdokumente zur Verfügung gestellt: Aufforderung 

zur Angebotsabgabe, Angebot, Auftrag, Auftragsänderung, Auftragsbestätigung, Lieferavis, 

Wareneingangsbestätigung, Rechnung. 

STEP (STandard for theExchange ofProduct Data) ist ein internationaler Standard zur digitalen 

Beschreibung physikalischer und funktionaler Merkmale von Produkten. Der Standard ist 

formal bekannt als ISO 10303 "Industrial automation systems and integration Product data representation 

and exchange". An der Entwicklung waren viele Länder beteiligt, u.a. Deutschland, 

England, Frankreich, Italien, Japan, USA. Wesentliche Teile von STEP sind die so genanten 

Anwendungsprotokolle. Das Anwendungsprotokoll ISO 10303-214, kurz AP214 beschreibt 

die Produkt- und Betriebsmitteldaten von Entwicklungsprozessketten in der Automobilindustrie. 

AP214 ist seit Anfang 2001 im Rahmen der ISO 10303 Internationaler Standard 

und deckt unter anderem folgende Informationskomplexe ab: 

• Teile und Betriebsmittel sowie Baugruppen von Teilen und Betriebsmitteln, einschließlich 

Versionierung, Zulieferinformation und deren Eigenschaften, Identifikation von Standardteilen 

• Produktinformations- und Konfigurationsdaten, die sich auf den Produktentwicklungsprozess 

beziehen 

• Verwaltung und Dokumentation der Entwurfs- und Änderungsprozesse 

• alternative Beschreibungen (unterschiedliche Sichten der Bearbeitungsprozesse während 

des Lebenszyklus der Produkte und Betriebsmittel) 

• Organisationsdaten (Verantwortlichkeiten, Freigaben, etc.) 

• mehrere Arten der Geometriebeschreibung (2D, 3D, Wireframe, BREP, CSG, Surface, …) 

• Daten, die sich auf die visuelle Darstellung der Flächen beziehen (Farbe, Linienstärke, 

schattierte Darstellungen) 

196


Die Verbindung zwischen „kaufmännischen“ und „technischen“ Daten, sprich zwischen openTRANS 

und STEP AP214 wird über intelligenten Assoziationsmechanismus realisiert. 

3.2.3 KOEFFIZIENT Architekturansatz 

Der Kooperationsassistent ist nach dem Client-Server-Prinzip realisiert, d.h. die Engineeringdaten 

werden auf Serverseite verwaltet und auf der Clientseite dargestellt. Die Kommunikation 

zwischen Client und Server erfolgt über SOAP auf Basis von XML-Nachrichten (Abbildung 

4). 

Einkauf 

Konstruktion 

Auftraggeber 

ERP/PPS 

CAD/PDM 

Import- und Exportschnittstellen 

zu IT-Systemen 

des Auftraggebers 

• Anfrage 

• Auftrag 

• Abnahme 

KA-Client 

(Auftraggeber) 

SOAP 

SOAP 

KA-Server 

197 

• Angebot 

• Auftragsbest. 

• Lieferung 

Entwicklungspartner 

KA-Client 

(Partner) 

SOAP 

Vorgänge 

e-mail 

Benachrichtigung 

läuft unter Hoheit des Auftraggebers 

Projektverwaltung 

CAD 

Vertrieb 

Engineering 

Import- und 

Exportschnittstellen zu IT- 

Systemen des Partners 

Abbildung 4: Überblick über den Architekturansatz (KA: Kooperationsassistent) 

Der KOEFFIZIENT Server dient dabei der zentralen Speicherung der Geschäftsdokumente und 

läuft im Allgemeinen unter Hoheit des jeweiligen Auftraggebers. Es gibt zwei Arten von KO- 

EFFIZIENT Clients: Der KOEFFIZIENT Administrationsclient läuft nur beim jeweiligen Auftraggeber 

und dient unter anderem der Administration des Zugangs zum KOEFFIZIENT Server. 

Die KOEFFIZIENT Userclients dienen der Anzeige/Modifikation der Geschäftdokumente und 

laufen sowohl beim Auftraggeber sowie bei allen in ein gegebenes Entwicklungsprojekt involvierten 

Partnern. 

Darüber hinaus bieten die KOEFFIZIENT Userclients die folgenden Basisfolder für die Ablage 

der Geschäftsdokumente: 

• Inbox folder (Eingangskorb) 

� beinhaltet alle neuen Geschäftsdokumente, die die von einem Partner bereitgestellt 

wurden 

� beim Auftragnehmer sind dies die Anfragen, Aufträge und Abnahmen des Auftraggebers 

� beim Auftraggeber sind dies die Angebote, Auftragsbestätigungen und Lieferungen 

von Engineeringdienstleistungen des Auftragnehmers.


• Outbox folder (Ausgangskorb) 

� beinhaltet alle an einen Entwicklungspartner verschickten und noch nicht beantworteten 

Geschäftsdokumente 

� beim Auftrageber kann es sich hierbei um Anfragen, Aufträge und Abnahmen handeln 

� beim Auftragnehmer hingegen und Angebote, Auftragsbestätigungen und Lieferungen 


• Draft folder (Entwurfskorb) 

� wie Ausgangskorb, jedoch sind die darin enthaltenen Geschäftsdokumente noch „in 

Arbeit“, also noch nicht an den Entwicklungspartner übermittelt und können daher 

noch geändert werden. 

• Archive folder (Archiv) 

� Nachdem eine positive Abnahme der Engineeringleistungen erfolgt ist, wird der gesamte 

Vorgang (d.h. Anfragen, Angebote, Aufträge, Auftragsbestätigungen, Lieferungen 

und Abnahmen) archiviert, d.h. alle erfolgreich abgeschlossenen Geschäftsvorgänge 

werden in vom System automatisch in diesen Folder verschoben. 

Jeder dieser Basisfolder beinhaltet geschäftsdokumentspezifische Funktionen, die der jeweilige 

Anwender nutzen kann. Zudem werden die Geschäftsdokumente durch den Kooperationsassistent 

miteinander logisch verknüpft (Anfrage ↔ Angebot ↔ Auftrag ↔ Auftragsbestätigung 

↔ Lieferung ↔ Abnahme), so dass der Anwender zu jedem Zeitpunkt eine Historie der 

Geschäftsdokumente besitzt. Dies ist insbesondere dann relevant, wenn es zu einer Änderung 

einer Transaktion kommt, und daher eine neue Version eines Geschäftsdokuments (z.B. Änderungsauftrag) 

kommt. 

Typischerweise ist es nun so, dass eine Anfrage oder ein Auftrag an den Entwicklungspartner 

vom Einkauf des Auftraggebers ausgelöst wird – in Sonderfällen jedoch auch direkt von der 

Entwicklungsabteilung/Konstruktion des Auftraggebers. Im Allgemeinen beziehen sich dabei 

die Informationen in diesen Geschäftsdokumenten auf technische Dokumente (CA- 

Dokumente), die im PDM-System abgelegt sind. Um zum einen die Konsistenz zwischen den 

kaufmännischen und technischen Informationen zu gewährleisten, zum anderen den notwendigen 

Aufwand zum Versenden eines Geschäftsdokuments zu minimieren, erlaubt nun der 

Kooperationsassistent das automatische Auschecken der von Geschäftsdokument aus referenzierten 

CA-Dokumente samt zugehörigen Metainformationen (Status, Bearbeiter, letzte Änderung, 

etc.), und deren Einbettung in das Geschäftsdokument und Ablage auf dem KA-Server. 

Dabei wird für den Empfänger automatisch eine Notfication generiert, so dass dieser automatisch 

über den Eingang eines neuen Geschäftsdokuments informiert wird. 

Darüber hinaus bietet der Kooperationsassistent eine Reihe von Basisservices an: 

• Notification Service 

� erlaubt die automatische Benachrichtigung des jeweiligen Partners über e-mail, sobald 

für ihn ein Geschäftsdokument (Anfrage, Angebot, …) vorliegt 

� die e-mail enthält einen Hyperlink, der direkt zu dem Geschäftsdokument führt 

• Visualization Service 

� erlaubt die Visualisierung von Attachments (z.B. STEP Datei, PDF) in einem eigenen 

Viewer zu einem Geschäftdokument bzw. Positionen in diesem Geschäftsdokument 

• Administration Service 

� für den Auftraggeber gibt es für den Administration Service einen eigen KOEFFIZIENT 

Administrationsclient, der das Anlegen von Partnerunternehmen, Abteilungen und Personen 

sowie die Einrichtung von Projekten/Kostenstellen erlaubt 

198


� der Auftragnehmer besitzt nur eine eingeschränkte Administrationsfunktionalität über 

den KOEFFIZIENT Userclient. Er kann damit lediglich firmeninterne Mitarbeiter zu einem 

Projekt hinzufügen, so dass auch diese auf die jeweiligen Geschäftsdokumente 

zugreifen bzw. diese erstellen können. 

3.3 KOEFFIZIENT Clients 

Das Grundprinzip der KOEFFIZIENT Clients (sowohl Administrations- als auch Userclient) ist 

recht einfach: der KOEFFIZIENT Client meldet sich am Server an, die Authentifizierung und 

Authorisierung erfolgt über Serverfunktionen. Danach kann der Client Daten vom Server 

empfangen und zu diesem senden. Insbesondere können auch serverseitige Funktionen (sog. 

Custom Metzhods) aufgerufen werden, welche die KOEFFIZIENT-spezifische Businesslogik 

realisieren. Der KOEFFIZIENT Administrationsclient dient dem Anlegen und der Wartung 

von Partnerunternehmen, Abteilungen innerhalb dieser Unternehmen und Personen innerhalb 

dieser Abteilungen (Abbildung 5). 

Bild 1: Bildschirmabzug des KOEFFIZIENT Administrationsclients 

Zudem werden durch den KOEFFIZIENT Administrationsclient für jede Person die Berechtigungen 

für Ausführung von Geschäftsvorgängen festgelegt. Zu diesen Berechtigungen gehören 

das Lesen, Erstellen, Bearbeiten, Löschen und Senden von Geschäftsdokumenten. 

Alternativ zum Anlegen können die Daten über Partnerunternehmen, Abteilungen und Personen 

von bestehenden Mastersystemen importiert werden. Bei den in KOEFFIZIENT verwalteten 

Daten handelt es sich nur um die jeweiligen Minimalinformationen: 

• Partnerunternehmen (Organisationen): Name, Lieferentennummer, Status, Kompetenzen 

199


• Abteilungen: Name 

• Personen: Identifikation (durch System vorgegeben), Benutzername, Passwort, Name, 

Vorname, e-Mail, Berechtigungen, (Sprache) 

Zusätzlich können/müssen neben den obigen Informationen noch Projekte/Kostenstellen angelegt 

werden, da entsprechende der in KOEFFIZIENT zugrunde liegenden Philosophie jedes 

Geschäftsdokument bzw. Vorgang eindeutig einem Projekt bzw. einer Kostenstelle zugeordnet 

sein muss. Projekte/Kostenstellen können zur deren Strukturierung gruppiert werden. Auf 

diese Weise lässt sich eine einstufige Hierarchie bilden. An Informationen zu Projekten/Kostenstellen 

werden benötigt: 

• Projekt: Projektnummer, Projektbezeichnung, Beschreibung, Status 

• Projektgruppe: Name 

Sind diese Informationen mittels des Administrationsclients, entweder direkt oder durch Import 

vom jeweiligen Mastersystem verfügbar, können die KOEFFIZIENT Userclients auf Auftraggeber- 

und Auftragnehmerseite von den autorisierten Personen genutzt werden. Die Software 

für den KOEFFIZIENT Userclient, sowohl für den Auftraggeber als auch den Auftragnehmer 

ist identisch. Die Hauptfunktionen des Userclients sind die Erstellung und das 

Versenden sowie die Bearbeitung vom jeweiligen Partner empfangenen Geschäftsdokumente 

(Abbildung 6). 

Je nachdem ob sich nun eine Person des Auftraggebers oder eine Person eines Entwicklungspartners 

einloggt, werden die Basisfolder der Zugehörigkeit der angemeldeten Person entsprechend 

dargestellt. Zusätzlich bietet der KOEFFIZIENT Userclient, falls sich der Ansprechpartner 

des Entwicklungspartners am KOEFFIZIENT Server angemeldet hat, eine eingeschränkte 

Administrationsfunktionalität. Dies ist notwendig, da nur der Ansprechpartner des Entwicklungspartners 

entscheiden kann, welche internen Ressourcen er zur Erstellung der vom Auftraggeber 

gewünschten Dienstleitung (z.B. Erstellung eines Angebots) hinzuziehen möchte. 

Hierzu kann er Abteilungen und Personen aus dem eigenen Unternehmen hinzufügen. 

200


Abbildung 6:Bildschirmabzug des KOEFFIZIENT Userclients 

Zudem kann es noch notwendig sein, zu dem Projekt, auf welches sich die Anfrage vom Auftraggeber 

bezogen hat, eine eigene, interne Projektnummer zu vergeben, da ein Entwicklungspartner 

im Algemeinen für Projekte einen eigenen Nummerkreis in seinem Unternehmen 

pflegt. Die Korrespondenz der eigenen Projektnummer mit der des Senders wird hierbei vom 

System verwaltet. 

Beispiel für den KOEFFIZIENT Visualization Service: SmartPDM Viewer 

Beim Versenden eines Geschäftsdokuments (Anfrage, Angebot, Lieferung, etc.) kann der 

Sender sowohl zu den Kopfdaten als auch zu den einzelnen Positionen Dokumente, z.B. Office 

Dokumente, PDF-Dokumente oder Stücklisten und/oder CAD-Modelle als so genannte 

Attachments hinzufügen. Der Empfänger des Geschäftsdokuments kann daraufhin die Attachments 

sowohl auf seinen lokalen Rechner holen und/oder die Attachments direkt mittels 

eines geeigneten Viewers anzeigen und ggf. bearbeiten (siehe Abbildung 6). In dem nachfolgenden 

Bildschirmabzug (Abbildung 7) ist die exemplarische Anbindung eines Viewers für 

PDM-Metadaten dargestellt. Dieser Viewer zeigt die - hier im STEP AP214 Format codierten 

- PDM-Daten in der Struktur des PDM-Systems des Auftraggebers an. Damit ist eine reibungslose 

Kommunikation der beteiligten Konstrukteure möglich. 

3.4 Verteilung und Installation 

Für die Installation und den Betreib des Kooperationsassistenten ist ein PC mit der folgenden 

Betriebssystem- und Softwareumgebung notwendig 

• Server (nur bei Auftraggeber) 

201


� MS Windows 2000, XP oder Win2003 Server 

� MS .NET Framework SDK 

� MS SQL-Server (eine eingeschränkte Version hiervon ist bereits Bestandteil des MS 

.NET Framework SDK) oder ORACLE 8i, 9i 

• Clients (bei Auftraggeber und Auftragnehmer) 

� MS Windows 98/ME/NT/2000/XP 

� MS .NET Framework 

Obwohl beim Auftraggeber die Clientsoftware prinzipiell auf demselben Rechner wie der 

Server installiert werden kann, sollte jedoch Trennung der Hardware und die getrennte Bereitstellung 

eines durchgeführt werden. 

Abbildung 7: Bildschirmabzug eines integrierten SMART PDM Tools zum 

Lesen und Schreiben von PDM Daten im STEP AP214 Format 

Für das Aufsetzen des Kooperationsassistenten bietet sich die folgende Vorgehensweise an 

(das ggf. notwendige Customizing des Kooperationsassistenten bzgl. Funktionalität, Benutzungsoberfläche 

und Terminologie ist in dieser Beschreibung ist nicht enthalten): Dem Auftraggeber 

wird eine CD auf der alle notwendigen Bestandteile des Servers und der Clients 

enthalten sind zur Verfügung gestellt. 

Zuerst muss der KOEFFIZIENT Server mittels einer automatisierten Installationsroutine installiert 

werden. Im Anschluss wird die Datenbank zur Verwaltung der Geschäftsdokumente angelegt. 

Anschließend werden der Benutzeraccount für den KA-Administrator (nur beim Auftraggeber) 

und die Basisfolderstruktur erstellt und danach das KOEFFIZIENT Datenmodell importiert. 

202


Im zweiten Schritt wir der KOEFFIZIENT Administratorclient beim Auftraggeber mittels eines 

typischen mitgelieferten Setup-Programms installiert. Sobald dies geschehen ist, können nun 

nach dem Start und Login als Administrator die Partnerunternehmen angelegt und die jeweiligen 

Ansprechpartner sowie deren Abteilungen vom Administrator eingegeben beziehungsweise 

von dem jeweiligen Mastersystem (z.B. das unternehmensweite ERP-System) importiert 

werden. Dies gilt auch für die Ansprechpartner im eigenen Unternehmen. Bereits zu diesem 

Zeitpunkt können nun auch Projekte/Kostenstellen angelegt bzw. vom jeweiligen Mastersystem 

(in der Regel das unternehmensweite ERP-System) importiert werden. Anschließend 

verteilt der Administrator nun die Clientsoftware an die (potentiellen) Nutzer im eigenen 

Haus sowie an die Ansprechpartner der Partnerunternehmen. Diese Verteilung kann automatisiert 

durch die Versendung einer E-Mail (ist Bestandteil der bei der Anlage der Personen 

eingegebenen bzw. importierten Minimalinformationen) mit einem Link zum Download der 

Clientsoftware oder durch das explizite Verschicken der Software auf einem Datenträger erfolgen. 

Als dritter Schritt wird dann der KOEFFIZIENT Userclient beim Auftragnehmer installiert, was 

wiederum durch das bereits genannte Setup-Programm erfolgt. Parallel und analog zu der Installation 

der Clientsoftware bei Auftraggeber erfolgt die Installation der Clientsoftware bei 

den Partnerunternehmen. 

Sobald die notwendigen Installationen abgeschlossen sind, können die Transaktionen erfolgen 

- hierzu muss zuerst ein Projekt/Kostenstelle vorhanden sein (durch den Administrator des 

Auftraggebers einzurichten). Der vorgegebene Workflow erfordert eine stringente Abarbeitung 

der Transaktionen: So kann z.B. erst dann ein Angebot erstellt werden, wenn einen entsprechende 

Anfrage eingegangen ist, oder eine Lieferung von digitalen Engineeringleistungen 

kann erst dann erfolgen, wenn ein Auftrag hierzu vorliegt, etc. Diese Regeln sind in dem Kooperationsassistenten 

hinterlegt und beeinflussen entsprechend die Handlungsmöglichkeiten 

der User im Client. 

3.5 Projektergebnisse 

Als Ergebnisse des Projekts sind der Software-Werkzeugkasten zur Erzeugung des dynamischen 

Kooperationsassistenten, zum anderen Spezifikationen, Methodiken und Erfahrungsberichte 

zu nennen. Der Software-Werkzeugkasten zur Erzeugung des dynamischen Kooperationsassistenten 

besteht im Wesentlichen aus den folgenden Komponenten: 

• Adaptern zur Extraktion der Datenstrukturen und/oder Nutzdaten von Partnersystemen, 

insbesondere den folgenden PDM-Systemen: 

� Axalant/EIGNER PLM 

� eMatrix 

� iMAN (TeamCenter Engineering) 

� Metaphase (TeamCenter Enterprise) 

• Modul zum Vergleich von Datenstrukturen: 

� dient der gezielten Ermittlung von Unterschieden von Datenmodellen zwischen unterschiedlichen, 

bei den Kooperationspartnern eingesetzten IT-Systemen einerseits 

und/oder der Feststellung von Veränderungen (Customizations) an dem Datenmodell 

eines IT-Systems bei einem Kooperationspartner. 

• Modul zur grafisch interaktiven Spezifikation von Datenstrukturmappings 

203


� diese Komponente dient der einfachen, graphisch orientierten Spezifikation von Abbildungen 

zwischen den Datenstrukturen der IT-Systeme der Kooperationspartner. 

Weitere Ergebnisse des Verbundforschungsprojektes KOEFFIZIENT umfassen: 

• Spezifikationen zu den Software-Werkzeugen 

• Methodik zum Aufbau von Engineeringprozessketten für KMU und deren Durchführung 

mittels dem Kooperationsassistenten 

• Validierung anhand von ausgewählten Engineeringprozessketten aus den Anwendungsbereichen 

"Antriebstechnik" und "Maschinen- und Anlagenbau" 

• Pilotierung bei den Anwendern, Erfahrungsberichte 

4 Ausblick 

Im Fokus der weiteren Arbeiten bis zum Projektende stehen vor allem die Validierung des 

bisher erarbeiteten Konzepts und der bisher erfolgten Implementierung sowie die anschließende 

Pilotierung bei den Anwendern im Verbundprojekt. Hierzu ist der Kooperationsassistent 

an die IT-Systeme der Partner anzubinden und entsprechend der jeweiligen Anforderungen 

an die unternehmensspezifischen Gegebenheiten und Prozesse anzupassen. 

204


5 kollmar 

KOEFFIZIENT im Maschinen- und Anlagenbau 

PHILLIP KOLLMAR 

Als Teilnehmer im Projekt KOEFFIZIENT wurde bei Firma Gebr. Bellmer GmbH die Prozessintegration 

mit Engineering- Partnern im Sondermaschinen- und Anlagenbau untersucht. 

Die Firma Bellmer ist ein mittelständische Unternehmen im Sondermaschinen- und Anlagenbau. 

Beschäftigt werden knapp 300 Mitarbeiter in der gesamten Wertschöpfungskette, einschließlich 

Fertigung und Montage. Firma Bellmer liefert Sondermaschinen für die Papierund 

Zellstoffindustrie zur Papierherstellung sowie Entwässerungsmaschinen für die 

Schlammentwässerung von industriellen und kommunalen Abwässern sowie Pressen zur 

Fruchtentsaftung im Lebensmittelbereich. Die Anlagen können inklusive Steuerung schlüsselfertig 

geliefert werden. Es handelt sich um individuelle Kundenlösungen, was zu einem hohen 

Engineeringaufwand der Produkte, die auftragsbezogen herstellt werden, führt. Die Durchlaufzeiten 

durchschnittlicher Aufträge liegen zwischen 6 und 15 Monaten. Der Fertigungsschwerpunkt 

liegt im Papiermaschinenbau. Die Kundenmärkte sind weltweit mit einem Exportanteil 

von durchschnittlich 50%. 

Das Produktprogramm wird regelmäßig weiterentwickelt um im Markt bestehen zu können. 

Es wurde auch in den letzten Jahren in die Fertigungstechnologien investiert, da Bellmer am 

Standort Deutschland festhält. Durch einen hohen Ausbildungsanteil gelingt es Bellmer den 

Nachwuchs mit motivierten eigenen Auszubildenden zu gestalten. 

Die Firma Bellmer ist in das laufende Projektvorhaben KOEFFIZIENT im Jahr 2003 während 

des letzten Projektdrittels eingestiegen. Bellmer wurde als Ersatz einer ausgestiegenen Maschinenbaufirma 

in das Projekt integriert. Die bisherigen Teilnehmer kamen mehr aus der 

Groß- und Kleinserienfertigung. Die Ergänzung durch Bellmer sollte mit die Anforderungen 

einer auftragsbezogenen Einzelfertigung in das Projekt mit einbringen. 

Es lag bereits ein Lösungsansatz mit einer Software vor, der auf Funktionalität und Eignung 

validiert wurde. 

Hierzu wurde im Vorfeld eine Analyse der bestehenden Aufbau- und Ablauforganisation vorgenommen. 

Geschäftsprozesse wurden in einem Modell abgebildet und die Umsetzbarkeit 

einzelnen Prozesse mit der Software „Kooperationsassistent“ untersucht. 

Im Bereich Beschaffung von Zulieferteilen sind standardisierte Abläufe mit Datenaustausch 

zwischen Kunde und Lieferant vorhanden. Diese sollen standardisiert und vereinfacht werden. 

Der Softwareprototyp Kooperationsassistent wurde auf Anwendbarkeit auf die Prozessmodelle 

und Umsetzung in der praktischen Anwendung getestet. Hierzu wurden Anwendungsszenarien 

wie beispielsweise Brennteilbeschaffung abgebildet. 

Die Validierung erfolgte unter den Gesichtspunkten Bedienbarkeit, Funktionserfüllung, Sicherheit, 

Performance, Fehlerfeststellung sowie Verbesserungsvorschläge. 

Die Testergebnisse sind dann in die laufende Softwareentwicklung eingeflossen. Die Anforderungen 

für zukünftige Lieferanten- / Kundenbeziehungen mit dem Kooperationsassistenten 

wurden formuliert. 

205


6 meier 

Das Vorgehen zur Konstruktion eines 

ontologiebasierten Kompetenzmanagementsystems 

HANS MEIER 

Zusammenfassung: Das Management von Kompetenzen stellt auch für kleine und mittlere Unternehmen 

speziell in engineeringintensiven Branchen einen wesentlichen Erfolgsfaktor dar. Der 

vorliegende Beitrag befasst sich deshalb mit dem Vorgehen zur Einführung eines rechnergestützten 

Kompetenzmanagementsystems, beginnend mit dem Entscheidungsprozess für ein solches 

System über den Kernprozess der Konstruktion dieses Systems bis hin zu dessen Überführung in 

die Nutzungsphase. Es wird dabei insbesondere der Blickwinkel kleiner und mittlerer Unternehmen 

berücksichtigt und auf projektbegleitende Prozesse wie die Dokumentation und das Projektmanagement 

mit eingegangen. 

1 Einleitung 

Für kleine und mittlere Unternehmen mit einem hohen Engineeringanteil an der Gesamtwertschöpfung 

stellt das Management von Kompetenzen einen erfolgsentscheidenden Faktor dar. 

Die TEMA GmbH beispielsweise, aus deren Blickwinkel dieser Beitrag entstanden ist, erstellt 

mit ca. 25 Mitarbeitern für industrielle Anwendungen bildverarbeitende Inspektionssysteme, 

die überwiegend in schnelllaufenden, hochautomatisierten Produktionssystemen eingesetzt 

werden. In den folgenden Abschnitten soll das Vorgehen für eine Einführung eines rechnergestützten 

Kompetenzmanagementsystems entsprechend der Ergebnisse des Forschungsprojekts 

KOWIEN diskutiert werden. 

2 Kompetenzmanagement in kleinen und mittleren Unternehmen 

Das Umfeld für das Kompetenzmanagement (Abbildung 1) ist geprägt von wissensintensiven 

Geschäftsprozessen, speziell in Unternehmen, die wie die TEMA GmbH durch einen hohen 

Engineeringanteil an der Gesamtwertschöpfung gekennzeichnet sind. Insbesondere wirkt sich 

hier die dominante Rolle des Projektgeschäfts mit einem äußerst geringen Wiederholcharakter 

bei teils sehr komplexen und zugleich erfolgskritischen Detaillösungen aus. Das dabei entstehenden 

Wissen ist in hohem Maße personengebunden, wobei die Projekterfahrungen als Wissensquelle 

zu verstehen sind. Das so entstehende Wissen ist allgemein schwer dokumentier- 

und kommunizierbar. Zudem wird unter Umständen das exklusiv erworbene Wissen durch 

Mitarbeiter als persönliches Kapital verstanden. Hinzu kommt, dass unter den Wissensträgern 

eine verhältnismäßig hohe Fluktuation herrscht. 

Es lässt sich also festhalten, dass ein optimaler Einsatz von Kompetenzen eine große Bedeutung 

für den Unternehmenserfolg hat. Dabei gestaltet sich er Umgang mit Kompetenzen 

schwierig, da das Wissen über die Kompetenzen schwer dokumentier- und kommunizierbar 

ist, da auch bei den Trägern des Wissens über das Wissen Fluktuation eine Rolle spielt und da 

selbstverständlich auch das Wissen über Kompetenzen als persönliches Kapital betrachtet 

werden kann. 

207

Das Vorgehen zur Konstruktion eines ontologiebasierten Kompetenzmanagementsystems 

Wissensintensive 

Wissensintensive 

Geschäftsprozesse 

Geschäftsprozesse 

• Hoher Engineeringanteil 

• Hoher Engineeringanteil 

• Projektgeschäft 

• Projektgeschäft 

• Geringer Wiederholcharakter 

• Geringer Wiederholcharakter 

• Komplexe, erfolgskritische 

• Komplexe, erfolgskritische 

Detaillösungen 

Detaillösungen 

Heute üblich 

in KMU 

Intuitives, 

Intuitives, 

implizites 

implizites 



Große Bedeutung eines optimalen Einsatzes von Kompetenzen 

Große Bedeutung eines optimalen Einsatzes von Kompetenzen 

Erschwerter 

Erschwerter 

Umgang 

Umgang 

mit 

mit 

Kompetenzen 

Kompetenzen 

• Fluktuation der Träger des Wissens über 

• Fluktuation der Träger des Wissens über 

das Wissen der Wissensträger 

das Wissen der Wissensträger 

• Schwer dokumentier- und 

• Schwer dokumentier- und 

kommunizierbares Wissen über Wissen 

kommunizierbares Wissen über Wissen 

• Exklusives Wissen über Wissen als 

• Exklusives Wissen über Wissen als 

„persönliches Kapital“ 

„persönliches Kapital“ 

208 

Personengebundenes 

Personengebundenes 

Wissen 

Wissen 

• Projekterfahrung als Wissensquelle 

• Projekterfahrung als Wissensquelle 

• Schwer dokumentier- und kommunizierbares 

• Schwer dokumentier- und kommunizierbares 

Wissen 

Wissen 

• Exklusives Wissen als „persönliches Kapital“ 

• Exklusives Wissen als „persönliches Kapital“ 

• Fluktuation der Wissensträger 

• Fluktuation der Wissensträger 

Option für die 

Zukunft 

Systematisches, 

Systematisches, 

rechnergestütztes 

rechnergestütztes 



Abbildung 12: Umfeld des Kompetenzmanagements 

in kleinen und mittleren Unternehmen 

In kleinen und mittleren Unternehmen wie auch der TEMA GmbH ist es dabei heute üblich, 

das Kompetenzmanagement ausschließlich implizit durch intuitives, erfahrungsgeleitetes 

Handeln abzubilden. Für die Zukunft besteht aber die Option, auf ein systematisches, rechnergestütztes 

Kompetenzmanagement zu setzen. 

3 Entscheidung zur Einführung eines Kompetenzmanagementsystems 

Wird nun erwägt, ein solches, systematisches, rechnergestütztes Kompetenzmanagementsystem 

einzusetzen, muss zunächst betrachtet werden, welche Defizite bei dem aktuell praktizierten, 

intuitiven Kompetenzmanagement tatsächlich bestehen (Abbildung 2). Hier wären zum 

Beispiel ein suboptimaler Mitarbeitereinsatz, das Brachliegen von vorhandenen Kompetenzen, 

der Fortbestand von Kompetenzlücken, der vollständige Verlust von Kompetenzen und 

Kompetenzwissen durch Mitarbeiterfluktuation sowie die stark subjektive Wahrnehmung von 

Kompetenzen zu nennen. Diese Defizite führen in der Regel zu Folgen wie beispielsweise einem 

erhöhten Personalaufwand, Kostenüberschreitungen im Projektgeschäft, Qualitätsmängeln, 

Imageschäden und unter Umständen sogar zu existenziellen Risiken. Auf der anderen 

Seite lassen sich aus einem systematischen Kompetenzmanagement als Nebeneffekte einige 

zusätzliche Potenziale ableiten, wie zum Beispiel einen bewussteren Umgang mit Kompetenzen, 

einer allgemein verbesserten Dokumentation sowie einer Präzisierung von Begrifflichkeiten.


Intuitives, implizites 

Intuitives, implizites 



Defizite 

Defizite 

• Suboptimaler 

• Suboptimaler 

Mitarbeitereinsatz 

Mitarbeitereinsatz 

• Brachliegen von 

• Brachliegen von 

Kompetenzen 

Kompetenzen 

• Fortbestand von 

• Fortbestand von 

Kompetenzlücken 

Kompetenzlücken 

• Verlust von Kompetenz- 

• Verlust von Kompetenzwissen 

bei Fluktuation 

wissen bei Fluktuation 

• Subjektive Wahrnehmung 

• Subjektive Wahrnehmung 

von Kompetenzen 

von Kompetenzen 

• ... 

• ... 

Vermeidbare 

Vermeidbare 

Folgen 

Folgen 

• Erhöhter Personal 

• Erhöhter Personal 

aufwand 

aufwand 

• Kostenüberschreitungen 

• Kostenüberschreitungen 

• Qualitätsmängel 

• Qualitätsmängel 

• Imageschäden 

• Imageschäden 

• Existenzielle Risiken 

• Existenzielle Risiken 

• ... 

• ... 

Zentrale Frage: 

Zentrale Frage: 

Rechtfertigt die Vermeidung der Defizite und die Nutzung der Potenziale 

Rechtfertigt die Vermeidung der Defizite und die Nutzung der Potenziale 

den Aufwand für die Einführung eines Kompetenzmanagementsystems? 

den Aufwand für die Einführung eines Kompetenzmanagementsystems? 

209 

Systematisches, rechnergestütztes 

Systematisches, rechnergestütztes 



Potenziale 

Potenziale 

aus 

aus 

Nebeneffekten 

Nebeneffekten 

• Bewussterer Umgang 

• Bewussterer Umgang 

• mit Kompetenzen 

• mit Kompetenzen 

• Verbesserte 

• Verbesserte 

Dokumentation 

Dokumentation 

• Präzisierung von 

• Präzisierung von 

Begrifflichkeiten 

Begrifflichkeiten 

• ... 

• ... 

Abbildung 13: Fragestellungen bei der Entscheidung zur Einführung eines 

Kompetenzmanagementsystems. 

Aus der Betrachtung der bestehenden Defizite, der daraus abgeleiteten, vermeidbaren Folgen 

sowie der zusätzlichen Potenziale der Nutzung eines systematischen Kompetenzmanagementsystems 

lässt sich nun die zentrale Frage beantworten, ob die eben genannten Vorteile den 

Aufwand der Einführung eines rechnergestützten Kompetenzmanagementsystems rechtfertigen. 

4 Projektbegleitende Prozesse 

Ist die Entscheidung zugunsten der Einführung eines rechnergestützten Kompetenzmanagementsystems 

gefallen, gilt es, ein entsprechendes Einführungsprojekt aufzusetzen. Neben den 

eigentlichen Kernprozessschritten eines solchen Projekts, die in den folgenden Abschnitten 

genauer beileuchtet werden sollen, ist an dieser Stelle auf die projektbegleitenden Prozesse 

der Dokumentation und des Projektmanagements hinzuweisen (Abbildung 3). Eine sorgfältige 

Dokumentation des Einführungsprojekts ist zum Beispiel deshalb unabdingbar, um die Nachprüfbarkeit 

der Anforderungserfüllung zu garantieren, Entscheidungen des Projektteams 

nachvollziehbar zu halten und somit deren Akzeptanz sicherzustellen und den Einsatz externer 

Dienstleister wie z. B. eines Toolanbieters abzusichern. 

Ein effektives Projektmanagement ist unter Anderem deshalb erforderlich, um eine strikte 

Entscheidungsfindung bei Meilensteinen zu erzwingen sowie die Einhaltung des Zeit- und des 

Kostenrahmens zu gewährleisten.

Anforderungsspezifizierung 


Dokumentation 

Wissensakquisition 

Konzeptualisierung 

Projektmanagement 

Implementierung 

210 

Evaluation 

Sorgfältige Dokumentation notwendig: 

Sorgfältige Dokumentation notwendig: 

• Nachprüfbarkeit der Anforderungserfüllung 

• Nachprüfbarkeit der Anforderungserfüllung 

• Nachvollziehbarkeit von Entscheidungen (Akzeptanz) 

• Nachvollziehbarkeit von Entscheidungen (Akzeptanz) 

• Einsatz externer Dienstleister (Toolanbieter) 

• Einsatz externer Dienstleister (Toolanbieter) 

Effektives Projektmanagement notwendig: 

Effektives Projektmanagement notwendig: 

• Strikte Entscheidungsfindung bei Meilensteinen 

• Strikte Entscheidungsfindung bei Meilensteinen 

• Einhaltung des Zeitrahmens 

• Einhaltung des Zeitrahmens 

• Einhaltung des Kostenrahmens 

• Einhaltung des Kostenrahmens 

Abbildung 14: Projektbegleitende Prozesse bei der Konstruktion eines ontologiebasierten 

Kompetenzmanagementsystems. 

5 Konstruktion des ontologiebasierten 

Kompetenzmanagementsystems 

Im Folgenden sollen die Kernprozessschritte eines Projekts zur Einführung eines rechnergestützten 

Kompetenzmanagementsystems eingehender behandelt werden. 

5.1 Anforderungsspezifizierung 

Zunächst muss zur Einführung eines rechnergestützten Kompetenzmanagementsystems präzise 

der angestrebte Funktionsumfang festgelegt werden (Abbildung 4). Dieser Schritt der Anforderungsspezifizierung 

umfasst die Identifizierung der durch das Kompetenzmanagement 

wesentlich tangierten Geschäftsprozesse, der jeweiligen Anwendungsszenarien in diesen Geschäftsprozessen, 

die dabei involvierten Nutzergruppen sowie die zu diesem Zeitpunkt bereits 

bekannten Quellen des Wissens über Kompetenzen. Die Phase der Anforderungsspezifizierung 

führt dabei nicht lediglich zu einem Anforderungskatalog, sie muss darüber hinaus vielmehr 

in einer greifbaren Vision des geplanten Kompetenzmanagementsystems münden, so 

dass sich die Projektbeteiligten bereits in dieser Phase mit dem künftigen Kompetenzmanagementsystem 

identifizieren können.




– 

– 

Festlegung 

Festlegung 

des 

des 

angestrebten 

angestrebten 

Funktionsumfangs 

Funktionsumfangs 

Vision eines Kompetenzmanagementsystems 

Vision eines Kompetenzmanagementsystems 

211 

Relevante Geschäftsprozesse 

Relevante Geschäftsprozesse 

Anwendungsszenarien 

Anwendungsszenarien 

Nutzergruppen 

Nutzergruppen 

Quellen des Kompetenzwissens 

Quellen des Kompetenzwissens 

Abbildung 15: Festlegung des angestrebten Funktionsumfang im Rahmen der 

Anforderungsspezifizierung. 

5.2 Systementscheidung 

Vollständige Eigenentwicklung? 

Vollständige Eigenentwicklung? 

Notwendige Kompetenzen liegen nicht vor 

Notwendige Kompetenzen liegen nicht vor 

Nutzung bereits geleisteter Arbeiten nicht möglich 

Nutzung bereits geleisteter Arbeiten nicht möglich 

Extrem hoher Aufwand 

Extrem hoher Aufwand 

Kauf eines kommerziellen Systems, welches? 

Kauf eines kommerziellen Systems, welches? 

Unterstützung der angestrebten Szenarien? 

Unterstützung der angestrebten Szenarien? 

Leistungsfähigkeit eines ontologiebasierten Systems? 

Leistungsfähigkeit eines ontologiebasierten Systems? 

Gewünschte Flexibilität? 

Gewünschte Flexibilität? 

Zukauf 

Zukauf 

Systemplattform 

Systemplattform 



Projektunterstützung, 

Projektunterstützung, 

von 

von 

welchem 

welchem 

Anbieter? 

Anbieter? 

Unterstützung durch den Anbieter? 

Unterstützung durch den Anbieter? 

Vorhandensein geeigneter Basisontologien? 

Vorhandensein geeigneter Basisontologien? 

Favorit festgelegt, Aufwand/Nutzen-Verhältnis? 

Favorit festgelegt, Aufwand/Nutzen-Verhältnis? 

Vorhandensein geeigneter Akquisewerkzeuge? 

Vorhandensein geeigneter Akquisewerkzeuge? 

Überzeugende und anpassbare Benutzerschnittstelle? 

Überzeugende und anpassbare Benutzerschnittstelle? 

Einführungsaufwand 

Einführungsaufwand 

Pflegeaufwand 

Pflegeaufwand 

Anwendung 

Anwendung 

Abbildung 16: Systementscheidung bei der Auswahl einer geeigneten Systemplattform. 

Auf Basis der Vision des Kompetenzmanagementsystems muss nun ein Zwischenschritt eingeschaltet 

werden, da in der Regel für kleine oder mittlere Unternehmen schlicht indiskutabel


sein wird, eine Kompetenzmanagementsystem vollständig selbst zu entwickeln, da die dazu 

notwendigen Kompetenzen nicht vorliegen werden, die Nutzung eventuell bereits erledigter 

Arbeiten und Erfahrungen aus anderen, derartigen Einführungsprojekten nicht genutzt werden 

können und darüber hinaus mit einem extrem hohen Aufwand zu rechnen wäre (Abbildung 

5). Es wird also in jedem Fall notwendig sein, ein kommerziell verfügbares System einzusetzen. 

Bei der Suche nach einem solchen System ist zu bewerten, inwieweit die bereits definierten 

Szenarien unterstützt werden können, ob die Leistungsfähigkeit des jeweiligen Systems ausreicht 

und ob es ein hohes Maß an Flexibilität garantiert. Hinsichtlich der Leistungsfähigkeit 

sollte als Messlatte die Leistungsfähigkeit eines ontologiebasierten Systems angelegt werden, 

da von dem System sicher auch erwartet wird, dass es mehr zu leisten vermag, als Kompetenzanfragen 

nur mit vorher exakt zur Frage passend eingegebenen Kompetenzaussagen zu 

beantworten. In der Regel wird es also auf den Zukauf einer kommerziellen Systemplattform 

für ein Kompetenzmanagementsystem hinauslaufen, wobei es von entscheidender Bedeutung 

sein wird, welche Unterstützung der Anbieter bei der Einführung bietet, ob er bereits anwendbare 

– im hier angenommenen Fall einer ontologiebasierten Lösung – Basisontologien bereitstellen 

kann, inwieweit der Anbieter die Wissensakquisition mit Werkzeugen unterstützen 

kann und ob eine überzeugende Benutzerschnittstelle vorhanden ist oder aufgebaut werden 

kann. 

5.3 Wissensakquisition 



- 

- 

Erfassung 

Erfassung 

relevanter 

relevanter 

Informationen 

Informationen 

zur 

zur 

Ontologieerstellung 

Ontologieerstellung 

Identifizierung der Träger von Kompetenzwissen 

Identifizierung der Träger von Kompetenzwissen 

Erfassung der Kompetenzen 

Erfassung der Kompetenzen 

Erfassung von Relationen, Zuordnungen und Ausprägungen 

Erfassung von Relationen, Zuordnungen und Ausprägungen 

Identifizierung von Dokumenten mit Kompetenzwissen 

Identifizierung von Dokumenten mit Kompetenzwissen 

Extraktion einer Basis-Terminologie als Ausgangspunkt 

Extraktion einer Basis-Terminologie als Ausgangspunkt 

Nebeneffekt: Schaffung von Bewusstsein über vorhandene Kompetenzen 

Nebeneffekt: Schaffung von Bewusstsein über vorhandene Kompetenzen 



– 

– 

Modellbildung 

Modellbildung 

auf 

auf 

Basis 

Basis 

von 

von 

Terminologien 

Terminologien 



Begriffsbeziehungen 

Begriffsbeziehungen 

Tendenziell nur wenig strukturiertes Kompetenzwissen 

Tendenziell nur wenig strukturiertes Kompetenzwissen 

Middle-Out-Ansatz beginnend mit Terminologieinseln 

Middle-Out-Ansatz beginnend mit Terminologieinseln 

212 

Erweiterung und Verfeinerung 

Erweiterung und Verfeinerung 

Formulierung von Inferenz- und Integritätsregeln 

Formulierung von Inferenz- und Integritätsregeln 

Abbildung 17: Die Schritte der Wissensakquisition und der Konzeptualisierung. 

...... 

......


Im darauf folgenden Schritt der Wissensakquisition (Abbildung 6) werden dann die relevanten 

Informationen zur Ontologieerstellung erfasst. Detailliert sind hier die Träger des Kompetenzwissens 

zu identifizieren, die relevanten Kompetenzen sowie deren Relationen, Zuordnungen 

und Ausprägungen zu erfassen, Kompetenzwissen enthaltende Dokumente zu identifizieren 

und als Ausgangspunkt für den nächsten Schritt eine Basisterminologie zu extrahieren. 

Es erscheint sinnvoll, sich in diesem Schritt bereits durch Experten des Anbieters der 

Systemplattform unterstützen zu lassen, um insbesondere eine zielgerichtete Arbeit sicherzustellen. 

Als positiver Nebeneffekt ist bereits in diesem Schritt die Schaffung eines geschärften 

Bewusstseins für die vorhandenen Kompetenzen zu erwarten. 

5.4 Konzeptualisierung 

Im folgenden Schritt der Konzeptualisierung (Abbildung 6) steht die Modellbildung auf Basis 

der bereits erfassten Terminologien und Begriffsbeziehungen im Mittelpunkt. Dabei empfiehlt 

es sich, bei der in kleinen und mittleren Unternehmen zu erwartenden, nur schwach ausgeprägten 

Strukturierung des Kompetenzwissens auf einen so genannten „Middle-Out“-Ansatz 

beginnend bei den relevantesten Terminologieinseln zurückzugreifen. Es folgen weitere Erweiterungen 

und Verfeinerungen und schließlich die Formulierung von Inferenz- und Integritätsregeln. 

Da diese Arbeiten ein erhebliches Maß an Erfahrung erfordern, liegt es nahe, hier 

massiv auf die Unterstützung durch den Systemanbieter zurückzugreifen, deshalb soll hier 

auch auf eine detailliertere Abhandlung über diese Teilschritte verzichtet werden. 

5.5 Implementierung 

Auch die Phase der Implementierung (Abbildung 7), also die Umsetzung auf der Systemplattform, 

sollte aus den bereits genannten Gründen überwiegend durch den Systemanbieter erfolgen. 

Sie umfasst unter Anderem die Bildung einer formalen Repräsentation der entwickelten 

Ontologie, die Installation der Systemplattform, die Einbringung der formalen Repräsentation 

in die Systemplattform sowie die Anpassung der Benutzerschnittstelle entsprechend der spezifizierten 

Anwendungsszenarien. 

213


Implementierung – Umsetzung auf der Systemplattform 

Implementierung – Umsetzung auf der Systemplattform 

Evaluierung – Überprüfung der Anforderungserfüllung 

Evaluierung – Überprüfung der Anforderungserfüllung 

5.6 Evaluation 

Bildung einer formalen Repräsentation 

Bildung einer formalen Repräsentation 

214 

„Einbau“ in Systemplattform 

„Einbau“ in Systemplattform 

Anpassung der Benutzerschnittstelle 

Anpassung der Benutzerschnittstelle 

Verifikation der Ontologien 

Verifikation der Ontologien 

Installation der Systemplattform 

Installation der Systemplattform 

...... 

...... 

Validierung der Funktionalität 

Validierung der Funktionalität 

Validierung der Anwenderfreundlichkeit 

Validierung der Anwenderfreundlichkeit 

Abbildung 18: Die Schritte der Implementierung und Evaluierung. 

Als letzter Kernprozessschritt steht abschließend die Evaluation des entwickelten Kompetenzmanagementsystems 

an (Abbildung 7), wobei der Schwerpunkt auf der Überprüfung der 

Anforderungserfüllung liegt. Wichtige Teilschritte hierbei sind die Verifikation der Ontologien, 

die Validierung der geforderten Funktionalität sowie die Bewertung der Anwenderfreundlichkeit. 

Dabei ist es zu empfehlen, diese Evaluation zumindest zunächst im engeren 

Kreis des Projektteams durchzuführen, um eventuelle, gröbere Mängel abstellen zu können 

bevor die späteren Anwender Kontakt mit dem System bekommen. Dadurch bestünde sonst 

die Gefahr, dass die Akzeptanz des Tools durch ohnehin noch zu behebende Fehler bereits 

nachhaltig beschädigt werden könnte. 

...... 

......


6 Überführung in die Nutzungsphase 

Betriebsbereites 

Betriebsbereites 

Kompetenzmanagementsystem 

Kompetenzmanagementsystem 

Zur 

Zur 

Nutzung 

Nutzung 

motivierte 

motivierte 

Mitarbeiter 

Mitarbeiter 

Zur 

Zur 

Nutzung 

Nutzung 

befähigte 

befähigte 

Mitarbeiter 

Mitarbeiter 

Aktive 

Aktive 

Nutzung 

Nutzung 

des 

des 



Kommunikation des Leistungsumfangs 

Kommunikation des Leistungsumfangs 

Darlegung der mitarbeiterspezifischen Vorteile der abfragenden Nutzung 

Darlegung der mitarbeiterspezifischen Vorteile der abfragenden Nutzung 

Darlegung der mitarbeiterspezifischen Vorteile der Kompetenzdatenpflege 

Darlegung der mitarbeiterspezifischen Vorteile der Kompetenzdatenpflege 

Zerstreuung von Nutzungsvorbehalten 

Zerstreuung von Nutzungsvorbehalten 

Mitarbeiterspezifische Schulung 

Mitarbeiterspezifische Schulung 

Berücksichtigung von Feedback 

Berücksichtigung von Feedback 

Konkretisierung der vom Mitarbeiter erwarteten Nutzung 

Konkretisierung der vom Mitarbeiter erwarteten Nutzung 

Abbildung 19: Überführung in die Nutzungsphase. 

Steht nun ein betriebsbereites Kompetenzmanagementsystem zur Verfügung, kann die Überführung 

in die Nutzungsphase erfolgen (Abbildung 8). Dazu ist es von überragender Bedeutung, 

die Mitarbeiter, die als Anwender des Systems in vorgesehen sind, zunächst zur Nutzung 

des Systems zu motivieren. Dazu ist es unter Anderem notwendig, den Leistungsumfang 

des Systems in greifbarer Weise zu Kommunizieren, die mitarbeiterspezifischen Vorteile der 

abfragenden Nutzung sowie der Pflege der Kompetenzdaten plausibel darzulegen sowie deren 

begründete Nutzungsvorbehalte zu zerstreuen. Sind die Mitarbeiter nun zur Nutzung des Systems 

motiviert, so ist eine angemessene Schulung der Mitarbeiter in der Nutzung des Systems 

erforderlich, wobei auch deren Feedback ausreichend berücksichtigt werden muss. Abschließend 

sollte mit den nun zur Nutzung des Kompetenzmanagementsystems befähigten Mitarbeitern 

die von Ihnen erwartete Nutzung konkretisiert und vereinbart werden. 

7 Fazit 

Auch für kleine und mittlere Unternehmen wie beispielsweise die TEMA GmbH ist Kompetenzmanagement 

ein erfolgsentscheidender Faktor. Es liegt daher nahe, unter Berücksichtigung 

bestehender Defizite und möglicher Potenziale die Einführung eines rechnergestützten 

Kompetenzmanagementsystems zu erwägen. Im Falle einer positiven Entscheidung diesbezüglich 

bietet das im Projekt KOWIEN entwickelte und hier erläuterte Vorgehensmodell einen 

geeigneten Leitfaden, wobei neben den Kernprozessschritten die projektbegleitenden 

Prozesse wie die Dokumentation und das Projektmanagement nicht vernachlässigt werden 

dürfen. Darüber hinaus ist zu beachten, dass es speziell für kleine und mittlere Unternehmen 

215


nicht sinnvoll sein kann, ein solches Kompetenzmanagementsystem selbst zu entwickeln und 

solche Unternehmen deshalb schon in einer frühen Projektphase einen geeigneten Anbieter 

einer entsprechenden Systemplattform ausfindig machen und in das Projekt einbeziehen sollten. 

Besonderes Augenmerk ist auch im Rahmen der Überführung in die Nutzungsphase auf 

die Motivierung und Schulung der Anwender und auf die Konkretisierung der erwarteten 

Nutzung zu legen, um schließlich eine aktiven Nutzung des Kompetenzmanagementsystems 

zu erreichen. 

216


Die E-Learning-Anwendung des Projekts KOWIEN 

8 E-Learning-Anwendung 

1 Begriffsabgrenzung 

DIPL.-WIRT-INF. THOMAS WEICHELT 

Ein immer wichtiger werdendes Thema – vor allem vor dem Hintergrund der stattfindenden 

Veränderungen der Arbeitswelt und der damit verbundenen steigenden Anforderungen insbesondere 

auch an die Arbeitnehmer – ist die berufliche Weiterbildung. So wird es in Zukunft 

immer weniger möglich sein, sich auf einmal im Rahmen der Schul- oder Berufsausbildung 

erlangtem Wissen „auszuruhen“, denn dessen Gültigkeit nimmt mit fortschreitender Zeit stetig 

ab. 95) Vielmehr wird für Arbeitnehmer die Bereitschaft und die Fähigkeit zur kontinuierlichen 

Weiterbildung, oft auch als Lifelong Learning 96) bezeichnet, zunehmend elementar. Im 

Zusammenhang mit lebenslangem Lernen gewinnt auch das so genannte Just-In-Time-Lernen 

zunehmend an Bedeutung. Neues Wissen wird demnach nicht „auf Vorrat“ erworben, sondern 

Personen lernen erst bei entsprechendem Bedarf. Eine effektive Möglichkeit dazu stellt E- 

Learning dar. Es ermöglicht den Nutzern zeit- und ortsunabhängiges Lernen sowie das Lernen 

„nach Bedarf“. 

Mit der im Rahmen des Projekts KOWIEN entwickelten E-Learning-Anwendung des Instituts 

PIM wird ein Beitrag geleistet, das komplexe Thema „ontologie- und kompetenzprofilbasiertes 

Wissensmanagement“ einer breiten – sowohl wissenschaftlichen als auch nichtwissenschaftlichen 

– Öffentlichkeit zugänglich zu machen. Zielgruppe sind vor allem die 

Nutzer des Software-Prototyps der Comma Soft AG 97) , aber auch diejenigen, die selbst ein 

ontologiebasiertes Kompetenzmanagementsystem konstruieren wollen. Weiterhin wird mit 

der E-Learning-Anwendung interessierten Arbeitnehmern die Möglichkeit gegeben, sich in 

den genannten Bereichen weiterzubilden oder bereits vorhandene Kenntnisse aufzufrischen. 

Auch wenn sich der Begriff E-Learning großer Beliebtheit erfreut und häufig verwendet wird, 

ist nicht immer eindeutig, was damit genau gemeint ist. So kann beispielsweise das „E“ auf 

ganz verschiedene Arten interpretiert werden: 98) 

• Easy Learning 

• Effective Learning 

• Entertaining Learning 

• Elaborated Learning 

• Electronic Learning 

In den meisten Fällen und auch in den nachfolgenden Betrachtungen wird die letzte Variante 

– also Electronic Learning – gewählt. Dementsprechend wird E-Learning oft als „... Lernen 

95) Vgl. BAUER/PHILIPPI (2001) S. 134 ff. 

96) Vgl. KRETSCHMER (2002) S. 14. 

97) Siehe http://www.comma-soft.com/. 

98) Vgl. DICHANZ/ERNST (2002) S. 46. 

217


mit Hilfe elektronischer Medien ...“ 99) verstanden. Doch auch wenn diese Sichtweise nicht 

falsch ist, greift sie aufgrund ihres sehr allgemeinen Charakters zu weit. Denn wenn alleine 

die Nutzung elektronischer Medien zur Unterstützung von Lernvorgängen ein hinreichendes 

Kriterium für E-Learning wäre, dann müsste z.B. auch die Präsentation von Lerninhalten mittels 

eines Overhead-Projektors konsequenterweise ebenfalls schon dieser Lernform zugerechnet 

werden. Deshalb wird im Folgenden die Reihe der elektronischen Medien auf den Computer 

eingeschränkt, so dass E-Learning als computerunterstütztes Lernen (CUL) verstanden 

werden kann. 100) 

Von besonderer Bedeutung in diesem Zusammenhang ist zudem der Begriff der computerunterstützten 

Lernumgebung (CULU). Damit sind rechnergestützte Systeme gemeint, mit denen 

die Realisierung und Anwendung des CUL erfolgt. 

Eine Ausprägung computerunterstützter Lernumgebungen ist das so genannte Computer- 

Based-Training (CBT), welches auch die derzeit meistgenutzte Form des E-Learnings darstellt. 

Im Vordergrund beim CBT steht der lernerzentrierte Zugang zu Wissen. CBT- 

Programme ermöglichen es dem Anwender, die Lerninhalte zeit- und ortsunabhängig zu nutzen 

und das Lerntempo seinen eigenen Bedürfnissen anzupassen. Die Inhalte sind dabei auf 

einem Datenträger gespeichert, so dass sie offline verwendet und zudem beliebig oft wiederholt 

werden können. CBT war ursprünglich vor allem auf den Bereich so genannter Drill-and- 

Practice-Programme beschränkt. Dieser Programmtyp zeichnet sich durch eine starke Systemsteuerung 

des Lernprozesses ohne wesentliche Einflussmöglichkeiten des Anwenders aus 

und bietet sich vor allem zur Vermittlung von strukturiertem Faktenwissen an. Neben diesen 

Drill-and-Practice-Programmen gehören zum Bereich der CBT-Anwendungen u.a. auch: 101) 

• Tutorielle Programme (Schritt für Schritt-Anleitung) 

• Lernspiele (Wissenserwerb durch Spielhandlungen) 

• Simulationsprogramme (Durchspielen konkreter Anwendungssituationen) 

• Hypermedia-Programme (freies Navigieren durch das Programm). 

Eine besondere Ausprägung des CBT ist das Web-Based-Training (WBT). Entsprechende 

Anwendungen können als eine Weiterentwicklung von CBTs angesehen werden. 102) Bei diesen 

Programmen erfolgt die Distribution der Lerninhalte nicht auf Datenträgern, sondern 

netzbasiert. Dies kann im lokalen Netzwerk, im Extranet oder auch im Internet erfolgen, wobei 

im letzten Fall vor allem das World Wide Web (WWW) genutzt wird. Die Inhalte werden 

– bei Abruf durch den Anwender – über das Netz auf dessen Computer geladen und können 

dort in einem Webbrowser dargestellt und genutzt werden. 

2 Aufbau und Gestaltung der E-Learning-Anwendung 

Die KOWIEN E-Learning-Anwendung wurde in Form einer webbasierten Applikation realisiert. 

103) Im Folgenden steht allerdings nicht die technische Umsetzung im Vordergrund, 

99) DOWNLING/EBERSPÄCHER/PICOT (2003) S. 3. 

100) Vgl. PAWLOWSKI (2001) S. 6. 

101) Vgl. KRETSCHMER (2002) S. 29. 

102) Vgl. LANG/PÄTZOLD (2002) S. 27. 

103) Vgl. Web-Based-Training in Abschnitt 1 . 

218


vielmehr werden der Aufbau sowie inhaltliche Gestaltung der E-Learning-Anwendung betrachtet. 

Bei der Entwicklung der KOWIEN E-Learning-Anwendung wurde insbesondere auf den Aspekt 

des selbst gesteuerten Lernens Wert gelegt. Die Bedeutung dieses Aspekts lässt sich aus 

den Anforderungen des lebenslangen Lernens 104) ableiten, welches die Fähigkeit zum selbst 

gesteuerten Lernen erfordert. 105) Dementsprechend ist die E-Learning-Anwendung auch derart 

gestaltet, dass sie ein exploratives Vorgehen des Anwenders ermöglicht und unterstützt. Dazu 

trägt auch ihr Aufbau, bestehend aus einem Portal und den drei Modulen Grundlagen, Vorgehensmodell 

und Prototyp, bei (siehe Abbildung 1). 

KOWIEN E-Learning-Anwendung 

P 

o 

rr 

tt 

a 

ll 

219 

Modul Modul 1: 1: 

Grundlagen Grundlagen 


Vorgehensmodell 

Vorgehensmodell 


Prototyp Prototyp 

Abbildung 1: Aufbau der KOWIEN E-Learning-Anwendung 

Das Portal dient vor allem dazu, die Anwender über den Aufbau und den Inhalt der KOWIEN 

E-Learning-Anwendung zu informieren. Neben der Erläuterung der technischen Voraussetzungen 

für eine optimale Nutzung werden dabei auch Hinweise zur Bedienung des Systems 

gegeben. Darüber hinaus können die Anwender vom Portal aus mittels entsprechender Links 

die drei einzelnen Module der E-Learning-Anwendung aufrufen. 

104) Vgl. Abschnitt 0. 

105) Vgl. ARNOLD (2001) S. 42.


Das Modul Grundlagen gibt dem Anwender einen Überblick über das Thema "ontologiebasiertes 

Wissensmanagement" zum Zwecke des Managements von Wissen über Kompetenzen. 

Hierbei werden nicht nur die zentralen Begriffe geklärt, sondern auch der Nutzen von Ontologien 

im Rahmen des Wissensmanagements verdeutlicht. 

Im Modul Vorgehensmodell wird erläutert, wie ein ontologiebasiertes Kompetenzmanagementsystem 

erstellt werden kann. Im Wesentlichen werden dabei verschiedene Werkzeuge 

zur Durchführung oder Unterstützung der einzelnen Phasen des Vorgehensmodells vorgestellt. 

Das Modul Prototyp gibt dem Anwender einen Überblick über die Funktionalitäten des prototypischen 

Software-Tools der Comma Soft AG für ein ontologiebasiertes Kompetenzmanagementsystem, 

so dass sich dieser mit den Möglichkeiten der Software vertraut machen und 

sie anschließend selbstständig bedienen kann. 

Bei der Entwicklung einer computerunterstützten Lernumgebung sind insbesondere die Gestaltung 

der Navigation und der Benutzerführung von Relevanz. Dabei hat sich allerdings bislang 

kein existierendes Konzept als eindeutig überlegen gezeigt. Als vorteilhaft erweisen sich 

jedoch die Wahlmöglichkeit zwischen freier Navigation und vorgeschlagenen Lernpfaden 

sowie Standortangaben innerhalb der Lernumgebung zur besseren Orientierung des Anwenders. 

106) Um diesen Aspekten Rechnung zu tragen und um dem Anwender eine übersichtliche 

und einfache Navigation zu ermöglichen, gliedert sich die Benutzeroberfläche der E- 

Learning-Anwendung in drei Funktionsbereiche (siehe Abbildung 2): 

106) Vgl. ARNOLD (2001) S. 123. 

220


Abbildung 2: Benutzeroberfläche der KOWIEN E-Learning-Anwendung 

• Navigationsleiste: Unter Verwendung der Pfeile in der Navigationsleiste im oberen Bildschirmbereich 

kann der vorgegebene Lernpfad eines Moduls durchlaufen werden. Zusätzlich 

zeigt dieser Bildschirmbereich an, in welcher Lerneinheit eines Moduls sich der Anwender 

gerade befindet. 

• Navigationsbaum: Der Navigationsbaum im linken Bildschirmbereich enthält alle Lerneinheiten, 

die in dem Modul zur Verfügung stehen, in einer hierarchischen Baumstruktur. Von 

hier aus können die einzelnen Lerneinheiten direkt aufgerufen werden. 

• Hauptfenster: Das Hauptfenster nimmt den größten Bereich der Benutzeroberfläche ein 

und dient der Anzeige der ausgewählten Lerneinheit. 

Neben der Gestaltung der Benutzeroberfläche ist vor allem die didaktisch sinnvolle Aufbereitung 

und adäquate mediale Umsetzung der Lerninhalte von Bedeutung. Allerdings gibt es 

auch hier kein eindeutig überlegenes Konzept oder allgemein gültige Empfehlungen bezüglich 

des Einsatzes verschiedener Medientypen (Text, Bild, Video, Ton etc.). Festhalten lässt 

sich aber, dass zur Vermittlung von Wissen Texte die wichtigste Grundlage darstellen, denn 

auch in computerunterstützten Lernumgebungen erfolgt der Wissenserwerb zu einem erheblichen 

Teil durch die Beschäftigung mit Texten. 107) Dabei muss allerdings beachten werden, 

107) Vgl. LANG/PÄTZOLD (2002) S. 67. 

221


dass das Lesen von Text am Computer-Bildschirm anstrengender ist und dass ca. 20 bis 30 

Prozent langsamer gelesen wird als auf Papier. 

Weiterhin sollte – sofern möglich – pro Bildschirmseite nur ein einzelner Aspekt eines Themas 

vermittelt werden, während es sich anbietet, einen komplexen Zusammenhang in Bildschirmfolgen 

zu zerlegen. Darüber hinaus sollte auch das Mittel des Scrollens so sparsam wie 

möglich eingesetzt werden, da gescrollter Text langsamer gelesen wird und zudem Probleme 

bei der mentalen Organisation des Inhalts bereitet. 108) 

Um den Anteil von Text in einer computerunterstützten Lernumgebung zu reduzieren, bietet 

sich der Einsatz von bildlichen Darstellungen, wie z.B. Grafiken oder Diagrammen, an. Dies 

ist insbesondere deshalb von Bedeutung, weil bildliche Informationen in der Regel schneller 

aufgenommen und auch leichter erinnert werden als Wörter. Ausgehend von diesen Vorteilen 

darf allerdings nicht der Fehler gemacht werden, alle Informationen einer Lernumgebung in 

einer bildhaften Darstellung vermitteln zu wollen. Vielmehr sollten die Inhalte aus kurzen 

Texten bestehen, die durch grafische Elemente und weiterführende Links aufgelockert werden. 

109) 

Bei der Entwicklung der KOWIEN E-Learning-Anwendung wurden insbesondere folgende 

Aspekte berücksichtigt: 

• viele grafische Elemente: Die drei Module enthalten nicht nur textbasierte Informationen, 

sondern auch vielfältige grafische Elemente. Die Nutzung der Funktionen des Prototyps 

wird zusätzlich durch Demonstrations-Videos veranschaulicht. Weiterhin ist nach Möglichkeit 

jede Bildschirmseite auf die Darstellungsfläche eines handelsüblichen Monitors 

beschränkt, um möglichst wenig zum Scrollen zu veranlassen. Darüber hinaus wird intensiver 

Gebrauch von den immanenten Strukturierungsmöglichkeiten des Mediums (Hypertextstruktur 

mit vielfachen Verlinkungen) gemacht, um so dem intendierten explorativen 

Charakter der Anwendung Rechnung zu tragen. 

• viele Beispiele: Um die meist abstrakten Konzepte dem Anwender zu verdeutlichen, enthalten 

die Module zahlreiche Beispiele. Diese wurden in Zusammenarbeit mit den Praxispartnern 

des KOWIEN-Projekts gewonnen. 

• Literatur und Links: Um Anwendern die Möglichkeit zu geben sich intensiver in die jeweils 

behandelte Thematik einzuarbeiten, enthalten die Module Angaben zu weiterführender 

Literatur sowie zu themenbezogenen Links. 

Die KOWIEN E-Learning-Anwendung ist modular aufgebaut. Jedes der drei Module setzt 

sich aus einzelnen Lerneinheiten zusammen, die wiederum weitere (Unter-)Lerneinheiten 

enthalten können. Die Beschäftigung mit den Modulen kann auf verschiedene Arten erfolgen: 

• Wer sich noch gar nicht mit dem Thema „ontologie- und kompetenzprofilbasiertes Wissensmanagement“ 

befasst hat, kann durch lineares „Blättern“ den Lernpfad eines Moduls 

durchlaufen und so die einzelnen Lerneinheiten nacheinander bearbeiten; 

• Anwender, die bereits über entsprechende Vorkenntnisse verfügen, können mittels des Navigationsbereichs 

gezielt auf die gewünschten Lerneinheiten des jeweiligen Moduls zugreifen. 

Damit wird insbesondere dem Aspekt des selbst gesteuerten Lernens Rechnung getragen; 

108) Vgl. BALLSTAEDT (1997) S. 91. 

109) Vgl. DOWNLING/EBERSPÄCHER/PICOT (2003) S. 96. 

222


• Diejenigen Anwender, die ihren eigenen Kenntnisstand überprüfen oder gezielt Wissenslücken 

schließen möchten, können direkt die Übungsfragen zum Selbsttest zu den einzelnen 

Lerneinheiten aufrufen. 

Die Lerneinheiten sind so gestaltet, dass sie sowohl bei der sequentiellen Betrachtung entlang 

des Lernpfads eines Moduls als auch unabhängig von anderen Lerneinheiten didaktisch sinnvoll 

bearbeitet werden können. Zusammenhänge zwischen oder Verweise auf andere Lerneinheiten 

werden durch Hyperlinks realisiert. 

3 Lernszenario: Ontologien im Rahmen des Wissensmanagements 

Nachfolgend wird anhand eines Lernszenarios zum Modul Grundlagen beschrieben, wie Anwender 

mit der KOWIEN E-Learning-Anwendung arbeiten und lernen können. Das Modul 

Grundlagen dient dazu, den Anwendern einen Überblick über die und grundlegende Informationen 

zur Thematik "ontologiebasiertes Wissensmanagement" zum Zwecke des Managements 

von Wissen über Kompetenzen zu vermitteln. Im Einzelnen enthält es Inhalte zu folgenden 

Themenbereichen: 

• Wissensmanagement 

• Ontologien 

• Kompetenzen/Kompetenzprofile 

• Kompetenzmanagementsysteme 

Ein Anwender, der noch über keine Vorkenntnisse verfügt und der mehr über Ontologien und 

deren Einsatz im Rahmen des Wissensmanagements erfahren möchte, kann durch Anklicken 

von Ontologien die entsprechende Lerneinheit aufrufen (siehe Abbildung 3). 

223


Abbildung 3: Screenshot Modul Grundlagen: 

Inhalte und Lernziele der Lerneinheit Ontologien 

Am Anfang jeder Lerneinheit werden deren Inhalte sowie die damit verfolgten Lernziele vorgestellt. 

Die Lerneinheit Ontologien beginnt mit der Definition dieses Begriffs (siehe Abbildung 

4). 

224


Abbildung 4: Screenshot Modul Grundlagen: Ontologien – Definition 

Anschließend folgt ein Anwendungsbeispiel, in dem gezeigt wird, wie Ontologien zur Lösung 

der praktischen Probleme des Wissensmanagements eingesetzt werden können (siehe Abbildung 

5). 

225


Abbildung 5: Screenshot Modul Grundlagen: Ontologien – Anwendungsbeispiel 

Ist sich der Anwender nicht sicher, welche Probleme dies sind oder möchte er mehr über diese 

Probleme erfahren, so kann er zur entsprechenden Lerneinheit verzweigen. Hier wird u.a. erläutert, 

dass ein wesentlicher Problembereich beim Wissensmanagement die Explikation von 

implizitem Erfahrungswissen und die Identifikation von Wissensträgern ist (siehe Abbildung 

6). 

226


Abbildung 6: Screenshot Modul Grundlagen: 

Wissensmanagement – Praktische Probleme des Wissensmanagements 

Kehrt der Anwender zum Anwendungsbeispiel zurück, so erfährt er, wie es mit Hilfe von Inferenzregeln 

möglich ist, implizites Erfahrungswissen zu explizieren und somit Wissensträger 

zu identifizieren (siehe Abbildung 5). 

Möchte der Anwender nun wissen, was Inferenzregeln genau sind, so gelangt er durch Anklicken 

des entsprechenden Links zur zugehörigen Lerneinheit. In dieser wird erklärt, dass Inferenzregeln 

neben Begriffen, Relationen und Integritätsregeln zu den Bestandteilen von Ontologien 

gehören und es sich dabei um eine logische Formeln handelt, mittels derer implizites 

Wissen expliziert werden kann (siehe Abbildung 7). 

227


Abbildung 7: Screenshot Modul Grundlagen: Ontologien – Bestandteile von Ontologien 

Fährt der Anwender entlang des Lernpfads zur nächsten Lerneinheit fort, so gelangt er zu den 

Repräsentationssprachen für Ontologien. Eine dieser Sprachen ist F-Logic (siehe Abbildung 

8). Der Anwender erfährt etwas über die Herkunft und die einzelnen Ausdrucksmittel der 

Sprache. Zusätzlich wird in dieser Lerneinheit auf die Nutzung von F-Logic im Rahmen des 

Projekts KOWIEN zur formalsprachlichen Repräsentation von Kompetenzen verwiesen. 

Möchte der Anwender mehr Informationen zu diesem Thema erhalten, so kann er durch Anklicken 

des entsprechenden Links zur zugehörigen Lerneinheit verzweigen. 

228


Abbildung 8: Screenshot Modul Grundlagen: Repräsentationssprachen – F-Logic 

Die nächste Lerneinheit entlang des Lernpfads im Bereich Ontologien befasst sich mit Tools 

zur Ontologie-Erstellung. Eines der vorgestellten Tools ist OntoEdit der Ontoprise GmbH 110) . 

In der zugehörigen Lerneinheit erfährt der Anwender mehr über u.a. Modellierungsfähigkeiten 

und -beschränkungen, unterstützte Import- und Export-Formate sowie weitere Eigenschaften 

dieser Software (siehe Abbildung 9). Jede der Lerneinheiten zu den betrachteten Tools 

enthält zudem einen Link auf die Homepage des Herstellers/Anbieters der Software, so dass 

von dort weitere Informationen bezogen werden können. 

110) Siehe http://www.ontoprise.de/. 

229


Abbildung 9: Screenshot Modul Grundlagen: Tools zur Ontologie-Erstellung – OntoEdit 

Hat der Anwender die einzelnen Lerninhalte durchgearbeitet so kann er zur Überprüfung seines 

Lernerfolgs die die zugehörigen Fragen zur Selbstkontrolle aufrufen (siehe Abbildung 10) 

230


Abbildung: 10: Screenshot Modul Grundlagen: Ontologien – Fragen zur Selbstkontrolle 

Möchte er darüber hinaus noch zusätzliche Informationen zum Thema Ontologien erhalten, so 

kann er dies beispielsweise mit den Tipps zu weiterführender Literatur tun (siehe Abbildung 

11). 

231


Abbildung 11: Screenshot Modul Grundlagen: Ontologien – Literaturtipps 

Damit hat der Anwender die Lerneinheit Ontologien erfolgreich abgeschlossen. Nun weiß er 

• was Ontologien sind, 

• welche Bestandteile Ontologien haben, 

• wie Ontologien zur Lösung von praktischen Problemen des Wissensmanagements eingesetzt 

werden können, 

• welche Sprachen zur formalen Repräsentation von Ontologien existieren, 

• welche Software-Tools es zur Erstellung und Bearbeitung von Ontologien gibt und 

• wo weitere Informationen zu einer vertiefenden Betrachtung des Themas verfügbar sind. 


ARNOLD (2001) 

Arnold, P.: Didaktik und Methodik telematischen Lehrens und Lernens: Lernräume – Lernszenarien 

– Lernmedien – State-of-the-Art und Handreichung. Münster et al. 2001. 

BALLSTAEDT (1997) 

Ballstaedt, S. P.: Wissensvermittlung. Die Gestaltung von Lernmaterialien. Weinheim 1997. 

232


BAUER/PHILIPPI (2001) 

Bauer, B.; Philippi, T.: Einstieg ins E-Learning: Die Zukunftschance für beruflichen und privaten 

Erfolg. Nürnberg 2001. 

DICHANZ/ERNST (2002) 

Dichanz, H.; Ernst, A.: E-Learning – begriffliche, psychologische und didaktische Überlegungen. 

In: Scheffer, U.; Hesse, F. W. (Hrsg.): E-Learning: Die Revolution des Lernens gewinnbringend 

einsetzen. Stuttgart 2002, S. 43-66. 

DOWNLING/EBERSPÄCHER/PICOT (2003) 

Downling, M.; Eberspächer, J.; Picot, A.: eLearning in Unternehmen – Neue Wege für Training 

und Weiterbildung. Berlin et al. 2003. 

KRETSCHMER (2002) 

Kretschmer, M.: E-Learning in der Hochschulausbildung: Projektmanagement für ein hochschulübergreifendes 

Partner-Netzwerk. Leutenbach 2002. 

LANG/PÄTZOLD (2002) 

Lang, M.; Pätzold, G.: Multimedia in der Aus- und Weiterbildung: Grundlagen und Fallstudien 

zum netzbasierten Lernen. Köln 2002. 

PAWLOWSKI (2001) 

Pawlowski, J.: Das Essener-Lern-Modell (ELM): Ein Vorgehensmodell zur Entwicklung 

computerunterstützter Lernumgebungen. Dissertation. Essen 2001. 

233


Autoren-, Herausgeber- und Referentenverzeichnis 

5 Autorenverzeichnis 

Dipl.-Kfm. Adem Alparslan 

Wissenschaftlicher Mitarbeiter am Institut für Produktion und Industrielles Informationsmanagement, 

Universität Duisburg-Essen (Campus Essen), Tätigkeitsschwerpunkte: 

strukturalistische Rekonstruktion von Theorien der Allgemeinen Betriebswirtschaftslehre, 

insbesondere der Prinzipal-Agenten-Theorie, sowie die Gestaltung von Ontologien 

und Kompetenzmanagementsystemen, 

Anschrift: Universitätsstraße 9, 45141 Essen, 

E-Mail: Adem.Alparslan@pim.uni-essen.de, 


Dipl.-Inf. Christof Bäumgen 

Mitarbeiter im infonea® Team, Comma Soft AG, Tätigkeitsschwerpunkte: Konzeption 

und Entwicklung von infonea® Anwendungen, Doktorand am Institut für Informatik 

der Universität Bonn, Forschungsschwerpunkte: knowledge acquisition, knowledge representation, 

semantic web technologies, ontology engineering, skill management, 

Anschrift: Pützchens Chaussee 202-204a, 53229 Bonn, 

E-Mail: Christof.Baeumgen@comma-soft.com, 

URL: http://www.comma-soft.com, 

http://www.infonea.com 

Dipl.-Ing. Christian Decker 

Entwicklung und Konstruktion, KLÖCKNER DESMA Schuhmaschinen GmbH, Tätigkeitsschwerpunkte: 

technische Entwicklung des Hauses innerhalb Prozesstechnik sowie 

des Maschinenbaus, 

Anschrift: Desmastr. 3/5, 28832 Achim, 

E-Mail: C.Decker@desma.de, 

URL: http://www.desma.de 

Kai Engelmann 

Roland Berger Strategy Consultants, Coordinator des Bereichs Business Intelligence, 

Staabsfunktionen im Hause Roland Berger im Bereich .bits business research and technology 

services mit den Tätigkeitsschwerpunkten Führungskräfteinformation, Wissensmanagement 

und Research, 

Anschrift: Arabellastrasse 33, 81925 München, 

E-Mail: Kai_Engelmann@de.rolandberger.com, 

URL: http://www.rolandberger.com 

235


Dr.-Ing. Karl Haslinger 

ZF Passau GmbH, Dr. Haslinger ist in ZF Passau für Engineering Services (CAD, CAE, 

PDM, Stücklistenwesen, Produktenstehungsprozess) zuständig, 

Anschrift: Donaustraße 25-71, 94030 Passau, 

E-Mail: Karl.Haslinger@ZF.com 

URL: http://www.zf.com 

Dipl.-Phys. Roger Hübbers 

Director Vision & Development infonea®, Comma Soft AG, 

Anschrift: Pützchens Chaussee 202-204a, 53229 Bonn, 

E-Mail: Roger.Huebbers@comma-soft.com, 

URL: http://www.comma-soft.com, 

http://www.infonea.com 

Burkhard Jagusch 

Geschäftsführung, SBS-Softwaresysteme GmbH, 

Anschrift: Jasperallee 13, 38102 Braunschweig, 

E-Mail: jagusch@sbs-softwaresysteme.de, 

URL: http://www.sbs-softwaresysteme.de 

Dipl.-Ing. Phillip Kollmar 

Geschäftsleitung Gebr. Bellmer GmbH Maschinenfabrik, 

Anschrift: Hauptstr. 37-43, Postfach 13 69, 75220 Niefern-Öschelbronn, 

E-Mail: p.kollmar@bellmer.de, 

URL: http://www.bellmer.de 

Dipl.-Ing. Stefan Löffler 

Institut für Konstruktionstechnik/Konstruktionsmethodik, Technische Universität 

Braunschweig, Projektleiter des Verbundprojektes – Ganzheitliche Innovationsprozesse 

in modularen Unternehmensnetzwerken – (GINA) mit folgenden Tätigkeitsschwerpunkten: 

Methoden und Werkzeuge zur Optimierung unternehmensübergreifender Innovationsprozesse, 

Konzeption von Innovationsprozessen im Unternehmen / Netzwerk, Aufbau 

eines internetbasierten Methodenassistenzsystems (Methodos), 

Anschrift: Langer Kamp 8, 38106 Braunschweig 

E-Mail: loeffler@ikt.tu-bs.de, 

URL: http:// www.ikt.tu-bs.de 

Dr.-Ing. Hans Meier 

TEMA GmbH – Industrial Visiomation, Dr.-Ing. H. Meier ist Leiter des Informationsmanagements 

der zur Mühlbauer AG gehörenden TEMA GmbH und ist zusätzlich im 

Mutterkonzern im Bereich der Steuerungstechnik tätig, 

Anschrift: Werner-von-Siemens-Str. 3, 93426 Roding, 

E-Mail: Hans.Meier@muehlbauer.de, 

URL: http://www.temavisio.com, 

http://www.muehlbauer.de 

236


Dr. Marko Multhaupt 

Controlling, Continental AG, Tätigkeitsschwerpunkte: Gesamtverantwortung für das 

Controlling des Geschäftsbereiches LKW Reifen Europa, 

Anschrift: Büttnerstraße 25, 30165 Hannover 

E-Mail: Marko.Multhaupt@Conti.de, 

URL: http://www.conti.de 

Dipl.-Wirtschafts-Ing.(FH), Dipl.-Ing.(FH) Maximilian Reischl 

ZF Passau GmbH, Tätigkeitsschwerpunkte: Anwenderservice CAD/PDM, Datenaustausch 

CAD, 


E-Mail: Maximilian.Reischl@ZF.com, 


Dr. rer. nat. Werner Schnitzlein 

Leitender Angestellter der ZF Passau GmbH, Tätigkeitsschwerpunkte: Dr. Werner 

Schnitzlein ist verantwortlich für die Informatik des ZF Unternehmensbereiches Arbeitsmaschinen-Antriebstechnik 

und Achssysteme sowie für die Sparte Engineering der 

ZF Informatik, 


E-Mail: Werner.Schnitzlein@ZF.com, 


Dipl.-Kff. Marianne Schumacher 

Geschäftsführende Gesellschafterin (kaufmännischer Bereich) bei der Karl Schumacher 

Maschinenbau GmbH, 

Anschrift: Frankfurter Str. 661, 51145 Köln, 

E-Mail: info@ksm-maschinenbau.de, 

URL: http://www.ksm-maschinenbau.de 

Dr.-Ing. Arne Simon, M.A. 

Referat 512: Produktionssysteme und -technologien, Bundesministerium für Bildung 

und Forschung (BMBF), 

Anschrift: Heinemannstr. 2, 53175 Bonn, 

E-Mail: Arne.Simon@bmbf.bund.de, 

URL: http://www.bmbf.de 

Dr. Günter Staub 

Geschäftsführer der PDTec GmbH, Tätigkeitsschwerpunkte: (neben den Tätigkeiten als 

Geschäftsführer) Akquisition und Durchführung von Projekten im Umfeld von PDM/ 

PLM Integrationslösungen, 

Anschrift: Haid-und-Neu-Str. 7, 76131 Karlsruhe 

E-Mail: Staub@pdtec.de, 

URL: http://www.pdtec.de 

237

Dr.-Ing. Trac Tang 

Volkswagen AG, 

Anschrift: 38436 Wolfsburg, 

E-Mail: Trac.Tang@volkswagen.de, 

URL: http://www.wolkswagen.de 


Dipl.-Wirt.-Inf. Thomas Weichelt 

Wissenschaftlicher Mitarbeiter am Institut für Produktion und Industrielles Informationsmanagement, 

Universität Duisburg-Essen (Campus Essen), Tätigkeitsschwerpunkte: 

Wissensmanagement, Web-basierte Informationssysteme, E-Learning, 


E-Mail: Thomas.Weichelt@pim.uni-essen.de, 


Univ.-Prof. Dr. Stephan Zelewski 

Direktor des Instituts für Produktion und Industrielles Informationsmanagement, Universität 

Duisburg-Essen (Campus Essen), Tätigkeitsschwerpunkte: Produktionstheorie 

und Produktionsmanagement, Künstliche Intelligenz und ihre betriebswirtschaftlichen 

Anwendungen, insbesondere wissensbasierte Systeme und Multi-Agenten-Systeme, 

Operations Research sowie Wissenschaftstheorie, 


E-Mail: Stephan.Zelewski@pim.uni-essen.de, 


Dipl.-Kfm. Stefan Zug 

Projekt- und Qualitätsmanagement, Karl Schumacher Maschinenbau GmbH, 

Anschrift: Frankfurter Str. 661, 51145 Köln, 

E-Mail: info@ksm-maschinenbau.de, 

URL: http://www.ksm-maschinenbau.de 

238

Industrieerprobte Lösungen und Werkzeuge für Produktentwicklung ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?