Das wichtigste Ziel bei der Initialisierung, Definition, Planung und Durchführung von

Produktentwicklungsprojekten ist die Maximierung der Produktqualität bei

gleichzeitiger Minimierung der Kosten und der Produktentwicklungszeiten. Dabei ist

insbesondere die „Time-to-Market“ Zeitspanne für den Erfolg neuer Produkte

entscheidend. Zur Erreichung dieser Ziele haben sich in der Produktentwicklung die

integrierte Produkt- und Prozessgestaltung sowie ein systematisches Vorgehen bei

der Projektplanung u.a. durch die Verwendung von sogenannten Entwicklungs-

systemen als geeignet herausgestellt .

Ein insbesondere in der Automobilentwicklung weit verbreitetes Organisations-

konzept zur Verkürzung der Markteinführungsdauer ist das Concurrent Engineering

(CE). Bei diesem Ansatz werden durch die integrierte und parallelisierte

Durchführung der Aktivitäten zur Produkt- und Prozessgestaltung Anforderungen aus

den der Produktentwicklung nachgelagerten Phasen des Produktlebenszyklus bereits

frühzeitig berücksichtigt und auf diese Weise zeit- und kostenintensive Produkt- und

Prozessänderungen in späten Phasen vermieden. Zur Unterstützung des CE und

dessen Umsetzung wurden mit Bezug auf die Arbeitspersonen verschiedene

Methoden entwickelt, u.a. eine aufgabenorientierte Methode zur prospektiven

Arbeitsgestaltung, eine Methode zur integrierten Arbeitsgestaltung und

Personalplanung, die eine humanorientierte Bewertung des arbeitsorganisatorischen

Produktionssystems im CE-Kontext ermöglicht sowie ein Teameffektivitätsmodell.

Darüber hinaus wurde zur Analyse und Modellierung organisatorischer Aspekte der

Kommunikation und Kooperation in den häufig schwach strukturierten

Produktentwicklungsprozessen die K3-Methode entwickelt.

Die zur Unterstützung des CE und dessen Umsetzung entwickelten Methoden stellen

die für eine Produktentwicklung typischen Iterationsschleifen nicht in den

Vordergrund. Aufgrund der im CE fokussierten Parallelisierung von Aufgaben wird die

Ausführung von Aktivitäten, die zudem informatorisch voneinander abhängig sind, mit

Informationsannahmen begonnen. Wenn sich die Annahmen später als fehlerhaft

oder falsch herausstellen, werden diese und die nachfolgenden Aktivitäten in einer

Iterationsschleife erneut bearbeitet (ungeplante Iterationen). Dies führt zu Nacharbeit

und in der Regel zu einer Verlängerung der Produktentwicklungsdauer, aus der eine

schlechte Planbarkeit resultiert.

Unternehmen planen – bspw. in einem Spiral Development Process – oftmals

bewusst solche Iterationen ein, um die Produktqualität sicherzustellen bzw. zu

erhöhen oder um Innovation während der Produktentwicklung zu ermöglichen. Die

Bearbeitung von Iterationsschleifen in der Automobilindustrie bindet zwischen einem

Drittel und der Hälfte der für das Projekt verfügbaren Entwicklungskapazitäten und

verursacht zwischen 20-50% der Kosten. In der Halbleiterindustrie entfallen laut einer

Studie sogar 13-70% (im Mittel: 33%) der Projektdauer auf die Bearbeitung von

Iterationsschleifen (Osborne 1993; siehe auch Yassine et al. 2002).

Die Gründe für ungeplante Iterationen sind vielfältig:

Falsche Reihenfolge der Vorgänge: Informationen werden zum falschen Zeitpunkt

bereitgestellt,

schlechte Kommunikation: die Informationen werden nicht pünktlich oder passend

übermittelt,

veränderter Input bewirkt eine Veränderung der Annahmen und Daten, die aber

von anderen Aktivitäten zur Informationserstellung genutzt werden,

Irrtum bei versehentlich fehlerhaften Informationen,

nicht erfasste falsche Annahmen, die als gesichert angenommen wurden.

Die Design Structure Matrix (DSM), auch Dependency Structure Matrix genannt,

beschreibt den Zusammenhang der Informationsflüsse sowie weiterer Abhängigkeiten

zwischen einzelnen Aktivitäten in einem Arbeitsprozess. Diese Methode wird

angewendet, um komplexe Zusammenhänge in der Produktentwicklung oder

Projektplanung darzustellen. Durch die matrixbasierte Darstellungsform können alle

Elemente eines Systems hinsichtlich ihrer Abhängigkeit und des Grads der

Abhängigkeit (z.B. mit Hilfe von Zahlen anstelle der dargestellten Punkte) bewertet

werden. Daraus können Aussagen abgeleitet werden, welche Aktivitäten nötig sind,

um eine Aktivität zu starten.

Des Weiteren zeigt die Abbildung der Relationen auf, welche Informationen durch

eine Aktivität erzeugt werden. Durch ein Lesen der Matrix in Spaltenrichtung kann

identifiziert werden, welches Element bzw. welche Elemente von einer Aktivität

beeinflusst werden. Lesen in Zeilenrichtung zeigt, von welchen anderen Elementen

eine Aktivität abhängig ist. Dabei wird grundsätzlich davon ausgegangen, dass die

Aktivitäten in der Reihenfolge in die DSM eingetragen werden, in der sie während der

Prozessdurchführung bearbeitet werden. D.h. die in der Abbildung dargestellten

Aktivitäten werden i.d.R. der Reihe nach beginnend bei Aktivität 1 bearbeitet.

Die DSM ermöglicht es, den Projektablauf zu verbessern, Informationsabhängigkeiten

zu visualisieren und ein gemeinsames Verständnis von Abhängigkeiten zu

entwickeln. Die Methode kann somit einen wesentlichen Beitrag zur

Prozessoptimierung leisten.

Aus den in der Design Structure Matrix dargestellten Informationsabhängigkeiten können

Prozesse abgeleitet werden, die den Projektablauf – bspw. den Ablauf eines

Produktentwicklungsprojekts – visualisieren. Um den Projektablauf angemessen darzustellen,

reicht es allerdings nicht aus, nur die Reihenfolge der Aktivitäten abzubilden. Sondern es

müssen auch die zwischen den Aktivitäten bestehenden informatorischen und technischen

Abhängigkeiten berücksichtigt werden (Eppinger et al. 1994).

Grundsätzlich kann zwischen einer parallelen, einer sequentiellen, einer überlappenden und

einer aufgrund von informatorischen Kopplungen iterativen Bearbeitung von Aktivitäten

unterschieden werden. Angenommen eine Aktivität A stellt eine Konstruktionstätigkeit und eine

Aktivität B die dazugehörige Fertigungsplanung dar. Eine sequentielle Bearbeitung beider

Aktivitäten (erst A, dann B) entspricht dem "throw the design over the wall“-Prinzip; das

Konstruktionsergebnis (z.B. Konstruktionszeichnungen, Stücklisten etc.) steht für die

anschließende Fertigungsplanung vollständig zur Verfügung.

Die teilweise oder vollständige parallele Bearbeitung der Aktivitäten (A und B gleichzeitig) führt

zu einer verkürzten Prozessdauer, da gewöhnlich nacheinander folgende Aktivitäten

gleichzeitig bearbeitet werden. Dabei werden ausreichend vorhandene Ressourcen

vorausgesetzt. Zudem wird vorausgesetzt, dass die parallel zu bearbeitenden Aktivitäten

unabhängig voneinander sind und keine informatorische Kopplung zwischen den Aktivitäten

besteht. Allerdings können diese Annahmen in der unternehmerischen Praxis i.d.R. nur selten

erfüllt werden.

Die gekoppelte Bearbeitung der Aktivitäten (A und B wechselseitig) ist vergleichbar mit der

parallelen Bearbeitung, entspricht aber eher dem Simultaneous bzw. Concurrent Engineering-

Prinzip (Eppinger et al. 1994). Dem Beispiel folgend würde die Aktivität B (Fertigungsplanung)

bearbeitet werden, sobald ein ausreichendes aber nicht vollständiges Ergebnis der Aktivität A

(Konstruktion) vorliegt. Anschließend würden die Aktivitäten A und B parallel bearbeitet

werden, was teilweise zu Mehrarbeit führen würde, da mit einem nicht endgültigen

Informationsstand gearbeitet wird und sich die Ergebnisse beider Aktivitäten fortlaufend ändern

können.

Der in der DSM darstellbare Grad der technischen Informationsabhängigkeit geht im

Flussdiagramm i.d.R. verloren.

Bei der Abbildung von Abhängigkeiten bzw. Vernetzungen zwischen Elementen einer

oder mehrerer Domänen mit Hilfe von Design Structure Matrizen wird zwischen

statischen und dynamischen DSMs sowie Multiple Domain Matrizen unterschieden

(Eppinger und Browning 2012, S. 11).

In statischen DSMs können die Elemente in einer beliebigen Reihenfolge in der DSM

dokumentiert werden. Beispiele sind die Abhängigkeiten zwischen Produktelementen

oder Organisationseinheiten. Die Optimierung, bspw. die optimale Gestaltung der

Aufbauorganisation in Form von Arbeitsgruppen bzw. Teams (siehe Folien 18 ff.),

erfolgt mit Hilfe der Clusteranalyse.

Dynamische DSMs stellen meist Arbeitsabläufe bzw. Prozesse dar, sodass Zeilen

und Spalten einer DSM die Aktivitäten eines Prozesses repräsentieren. Dabei sind

Zeilen und Spalten in einer zeitlichen Reihenfolge angeordnet, d.h. die Bearbeitung

beginnt mit dem Element der ersten Zeile und Spalte. Bei Prozessen werden gemäß

der in der DSM dokumentierten Informationsabhängigkeiten die Aktivitäten

nacheinander bzw. in Iterationsschleifen abgearbeitet. Durch Sequenzierung kann die

Bearbeitungsreihenfolge der Aktivitäten so optimiert werden, dass möglichst wenige

Aktivitäten iterativ zu bearbeiten sind (Browning 2001, S. 293).

In DSMs werden Abhängigkeiten zwischen Elementen einer Domäne abgebildet.

Mehrere DSMs können in einer sog. Multiple Domain Matrizen (MDM)

zusammengefasst bzw. gruppiert werden. Auf diese Weise können Abhängigkeiten

und Vernetzungen zwischen Elementen unterschiedlicher Domänen geschaffen

werden (Eppinger und Browning 2012, S. 12).

Aufgrund ihres flexiblen Einsatzes für die Beschreibung von Abhängigkeiten in Produkten und

Prozessen ist die DSM bereits in vielen unterschiedlichen industriellen Bereichen zu finden.

Nachfolgend werden einige Beispiele für die Anwendung der Prozess- und Produkt-DSM im

industriellen Kontext dargestellt.

So wurden 1993 erstmals mit Hilfe der DSM Entwicklungsprojekte von Halbleitern bei der Intel

Corporation modelliert und analysiert. 1998 wurde ein Ansatz entwickelt, um Projektmanager

bei der Entscheidung zwischen der sequentiellen und parallelen Bearbeitung von

informatorisch gekoppelten Entwicklungsaktivitäten zu unterstützen. Der Ansatz wurde anhand

eines Entwicklungsprojektes von PCs bei Hewlett-Packard verifiziert. Anhand eines

Entwicklungsprojekts bei Nokia wurde 2008 beschrieben, wie die Entwicklungsaufgaben

untergliedert und zwischen global agierenden Entwicklungsteams verteilt werden sollten.

Durch eine DSM-basierte Simulation konnten 2001 die Auswirkungen von

Prozessverbesserungsmaßnahmen auf den Produktentwicklungsprozess aufgezeigt und am

Beispiel der Entwicklung von Gasturbinen bei ABB demonstriert werden können. Zwei Jahre

später wurde ebenfalls durch eine DSM-basierte Simulation die Produktentwicklungsprozesse

zweier Chemieunternehmen analysiert. Die simulationsgestützte Verbesserung des

Planungsablaufs in Architektur- und Bauprojekten wurde bereits 1999 und erneut im Jahr 2008

nachgewiesen. Beim Luft- und Raumfahrtunternehmen Boeing wurde 1998 ein Projekt zur

Entwicklung einer Flugdrohne mit Hilfe der DSM modelliert und verbessert. Eine weitere

Anwendung der DSM im militärischen Bereich erfolgte 2009 in einem Entwicklungsprozess

von komplexen Kriegsschiffen für die US Navy. Für den Schiffbau finden sich weitere

Anwendungsfälle. So wurde zuletzt 2009 die DSM beim Bau von Ölförderschiffen bzw.

Offshore-Plattformen von British Petroleum verwendet. Bei der Planung eines neuen

Produktionsprozesses bei TetraPak Carton Ambient wurden im selben Jahr ein adaptives

DSM-Modell angewendet, um verschiedene Strategien und Prozesspfade zu ermitteln, zu

analysieren und zu evaluieren.

(Gärtner 2011)

Ziel der Clusteranalyse und entsprechenden Clustering-Algorithmen ist die Ermittlung

von Untermengen einer DSM, d.h. von Clustern (bzw. Blöcken) innerhalb der DSM,

deren Elemente eine hohe Anzahl von Abhängigkeiten bzw. Interaktionen zu anderen

Elementen innerhalb desselben Clusters aufweisen bei gleichzeitig geringer Anzahl

von Abhängigkeiten zu Elementen außerhalb ihres Clusters (Maurer 2007).

Dabei kann ein Cluster die Basis zur Ausgestaltung von Modulen bilden. Je nachdem

welches System zugrunde gelegt wird, können diese Module bspw. unterschiedliche

Bauteil-, Komponenten- oder Funktionsgruppen (bei Produkt-DSM, siehe Folie 7)

oder auch einzelne System-, Entwicklungs- oder allgemein Subteams (bei DSM zur

Darstellung der Aufbauorganisation, siehe Folie 7) repräsentieren. Bei optimaler

Clusterbildung wirken sich eine Änderung eines Elementes in der DSM meist nur auf

andere Elemente innerhalb desselben Clusters aus. Selbst die Änderung eines

vollständigen Clusters (z.B. Entfernen des Clusters) hat nur geringe Auswirkungen

auf andere Elemente in der DSM, da die Abhängigkeiten zwischen Elementen

unterschiedlicher Cluster auf ein Minimum reduziert wurden (Maurer 2007).

Im Sinne des Concurrent Engineering können Cluster aufgrund des geringen Maßes

gegenseitiger Abhängigkeit simultan bzw. hochgradig parallel bearbeitet werden

(Pimmler & Eppinger 1994). Die Clusteranalyse bietet sich deshalb auch bei

dynamischen DSM-Typen an, um die Bearbeitungsreihenfolge der Aktivitäten zu

optimieren.

Eine DSM, die lediglich nicht quantifizierte Abhängigkeiten bzw. Interaktionen

zwischen Elementen enthält, d.h. Abhängigkeiten nur mit einem „X“ oder „1“ markiert

werden, nennt man „binäre“ DSM. Bei der Clusteranalyse werden Abhängigkeiten

bzw. Interaktionen entsprechend mit dem Wert 1 berücksichtigt. Der

Abhängigkeitsgrad zwischen Elementen kann folglich nicht differenziert werden

(siehe Beispiel, Folie 17 f.).

Ziel einer Zerlegung ist es, ein System in handhabbare Elemente zu zerlegen, um sie

bezüglich ihrer Funktionen und Schnittstellen beschreiben zu können.

Man bildet zuerst aus einem System verschiedene Subsysteme. Aus diesen werden

die Baugruppen abgeleitet, welche anschließend in Bauteile zerlegt werden können.

Im obigen Beispiel sind die räumlichen Abhängigkeiten einer Fahrzeugklimaanlage

dargestellt. Spalten- und zeilenweise werden die Bauteile einer Klimaanlage

aufgetragen. Anschließend werden die Abhängigkeiten der räumlichen Nähe

dokumentiert. Beispielsweise bläst der Motorlüfter über den Kühler und erhöht damit

die Kühlwirkung. Im Kondensator wird Wasser von der durch Expansion abgekühlten

Luft abgeschieden. Um den Kondensator schneller zu trocknen, wird dieser vom

Motorlüfter angeblasen.

Durch die vorangegangene Zerlegung gewonnenen Bauteile werden beim Clustern

zu Systemmodulen synthetisiert. Ziel ist es, die externen Interaktionen der

Systemmodule zu minimieren und die internen Interaktionen zu maximieren.

Für das Clustering statischer DSM lassen sich viele Algorithmen finden. Hier wird ein

vereinfachter Clustering-Algorithmus nach Idicula (1995), Fernandez (1998) und

Thebeau (2001) vorgestellt. Durch Clustering kann die aufgrund der nötigen

Koordination und Interaktion der Bauteilelemente resultierende Komplexität einer

DSM wesentlich verringert werden. Der Algorithmus verfolgt dabei das Ziel, die

Elemente der DSM derart zu Clustern (Blöcken) zusammenzulegen, dass diese

möglichst wechselseitig unabhängig sind bei gleichzeitig hoher Anzahl interner

Interaktionen. D.h., es wird angestrebt, zusammenhänge Cluster zu bilden, deren

Elemente innerhalb des Clusters viele Interaktionen untereinander aufzeigen,

während zwischen Elementen unterschiedlicher Cluster möglichst wenige oder gar

keine Interaktionen auftreten.

Die grundlegende Funktionsweise des Algorithmus beruht darauf, die Interaktionen

zwischen Elementen quantitativ zu bewerten; jede Interaktion zwischen zwei

Elementen versucht sog. Kosten. Dabei verursachen Interaktionen zwischen

Elementen außerhalb eines Clusters höhere Kosten als Interaktionen zwischen

Elementen innerhalb eines Clusters. Eine Verbesserung der gesamten DSM

entspricht einer Reduzierung der Gesamtkosten. Diese wird erreicht, indem Elemente

derart zu Clustern zusammengelegt werden, dass möglichst viele Interaktionen

zwischen Elementen innerhalb eines Clusters und möglichst wenige Interaktionen

zwischen Elementen außerhalb eines Clusters auftreten.

Der Algorithmus kann durch die Parameter powdep, powbid und powcc feinjustiert

werden. Durch den Parameter powdep wird die Sensitivität unterschiedlicher

Interaktionsgrade beeinflusst. Die Parameter powbid und powcc haben Einfluss auf

die durchschnittliche Clustergröße.

Die genaue Funktionsweise des Algorithmus wird auf der nachfolgenden Folie an

einem Beispiel veranschaulicht.

Der Clustering-Algorithmus nach Idicula (1995), Fernandez (1998) und Thebeau

(2001) lässt sich in sieben Schritte unterteilen, die teilweise iterativ durchgeführt

werden.

Schritt 1: Erfasse die Beziehungen und Abhängigkeiten (Interaktionen) zwischen den

Elementen und dokumentiere sie in einer DSM. Jedes Element bildet

seinen eigenen Cluster.

Schritt 2: Berechne die Kosten für jeden Cluster und die kumulierten Gesamtkosten

für die DSM.

Schritt 3: Wähle zufällig einen Cluster aus.

Schritt 4: Berechne die sog. Angebote aller übrigen Cluster.

Schritt 5: Berechne die Gesamtkosten der DSM unter der Annahme, dass der

ausgewählte Cluster mit dem höchstbietenden Cluster zusammengelegt

wird.

Schritt 6: Lege beide Cluster dauerhaft zusammen, falls die neuen Gesamtkosten

kleiner als die vorherigen Gesamtkosten sind.

Schritt 7: Wiederhole die Schritte 3 bis 6 für eine vorher bestimmte Anzahl an

Durchläufen oder solange, bis über einen bestimmten Zeitraum keine

Verbesserungen erzielt werden können.

Ein weiterer Clustering-Algorithmus von Pimmler & Eppinger (1994) strukturiert die

Zeilen und Spalten einer DSM derart, dass die Interaktionen möglichst nahe an der

Hauptdiagonalen liegen. Auf diese Weise werden analog zum Algorithmus von Idicula

(1995) zusammenhängende Blöcke (Cluster) entlang der Diagonalen gebildet.

Die Ziele beim Clustering:

1. Minimierung der externen Interaktionen.

2. Maximierung der internen Interaktionen.

3. Sehr interaktive Komponenten („Integrative Elemente“, z. B. Datenbusse) sollten

in keinem Cluster vorkommen.

Im obigen Beispiel sind die Interaktionen in einem mit Wasserstoff betriebenen 6-

Zylinder Verbrennungsmotors (Porsche Cayenne) von Arvin Meritor dargestellt. Der

Verbrennungsmotor wird dazu in seine Komponenten zerlegt und die Abhängigkeiten

zwischen diesen in einer mehrdimensionalen DSM dargestellt. Dabei wird zwischen

physikalischen Abhängigkeiten (z.B. zwischen Kurbelwelle und Pleuel),

energetischen Flüssen (z.B. Momente), Materialflüssen (z.B. Öl) und

Informationsflüssen (z.B. Signale) zwischen den Komponenten unterschieden.

In Abhängigkeit der Komplexität des zu entwickelnden Produktes und der damit

verbundenen Prozesse (z.B. bei der Entwicklung eines Motors) ist eine Aufteilung der

Gesamtaufgabe auf mehrere Teams erforderlich. Dabei wird häufig nach dem

Objektprinzip verfahren und die Projektteamstruktur aus der Produktstruktur

abgeleitet. Bei den entstehenden Teams wird zwischen koordinierenden

Systementwicklungsteams (System Teams) und ausführenden

Produktentwicklungsteams (PETs) unterschieden. Koordinierende System Teams

übernehmen die zeitliche Planung der Entwicklungsaktivitäten sowie die kapazitive

und kostenbezogene Koordination der entsprechenden Teilprojekte. Die eigentlichen

Entwicklungsaufgaben, d.h. die Gestaltung von Modulen des Produkts und Teilen des

Produktionsprozesses, werden von ausführenden PETs übernommen.

Bei einem Entwicklungsprojekt, wie beispielsweise der Entwicklung eines neuen

Motors, werden die Projektinhalten von den beteiligten Systementwicklungsteams

bearbeitet. Die Systementwicklungsteams sind in Produktentwicklungsteams

aufgegliedert. Ziel ist es, die Systementwicklungsteams so zusammenzusetzen, dass

intern eine hohe und extern eine niedrige Abhängigkeit zwischen den Informationen

besteht.

Zunächst werden in der DSM die Produktentwicklungsteams gemäß ihrer

Zugehörigkeit zu den Systementwicklungsteams zeilen- und spaltenweise

aufgetragen. Dann wird die Häufigkeit des Informationsaustausches zwischen den

Teams durch die Befragung der beteiligten Ingenieure ermittelt und in der DSM als

Punkt erfasst. Je nach Häufigkeit des Informationsaustauschs ergeben sich die

verschiedenen Abhängigkeiten, dargestellt durch verschieden große Punkte: hoch,

mittel, niedrig. Man erkennt, das viele Produktentwicklungsteams mit anderen PETs

außerhalb des eigenen Systementwicklungsteams interagieren. Ziel ist es nun, die

Produktentwicklungsteams so zu neuen Systementwicklungsteams zu bündeln, dass

die PETs fast nur innerhalb ihrer Systementwicklungsteams kommunizieren.

Die Matrix zeigt die vorgeschlagene Organisationsstruktur nach der Reorganisation.

Durch Clustering wurden die Produktentwicklungsteams (PETs), die häufig

Informationen untereinander austauschen und die zuvor in unterschiedlichen

Systementwicklungsteams verankert waren, in einem neuen Systementwicklungsent-

wicklungsteam zusammengefasst. Dabei kommt es vor, dass einige PETs in zwei

Systementwicklungsteams arbeiten. PETs, die fast mit jedem anderen PET

Informationen austauschen, werden in einem Integrationsteam verankert.

Werden zwei unterschiedliche Abteilungen nach den Interaktionen der von ihnen zu

entwickelnden Elemente befragt, z. B. eine vor- und eine nachgelagerte Abteilung, so

ergeben sich zwar viele Übereinstimmungen, aber auch viele abweichende

Abhängigkeiten. Dies liegt an der unterschiedlichen Wahrnehmung von

Abhängigkeiten. Die DSM hilft, unterschiedliche Sichtweisen in kompakter Form zu

dokumentieren und als Diskussionsgrundlage zur Verfügung zu stellen. Damit wird

verborgenes Wissen erfasst und nutzbar.

Über die bereits dargestellten Möglichkeiten hinaus kann die DSM einen wichtigen Beitrag zur Lösung

der Problemstellung liefern, wie sich Änderungen von Parametern oder die Bildung neuer Varianten auf

ein Produkt, einen Entwicklungsprozess und einen Produktionsprozess auswirken. Dazu sind zunächst

die Abhängigkeiten in den Systemen z.B. Parameter, Produkt, Prozess und Fertigungsanlagen mit Hilfe

von DSM und die Abhängigkeiten zwischen den Systemen mit Hilfe von DMM (siehe Folie 30)

darzustellen. Anschließend sollten die Szenarien mit den Auswirkungen der Änderungen im System und

auf andere Systeme berechnet, die Szenarien analysiert und das bestmögliche Szenario ausgewählt

werden. Dieses Vorgehen kann am Beispiel der Entwicklung eines einfachen manuellen, zweistufigen

Getriebes verdeutlich werden.

Das Getriebe besteht aus sieben Bauteilen: Antriebswelle WA, Abtriebswelle WB, dem Gehäuse G sowie

den Zahnrädern Z1, Z2, Z3 und Z4, wobei Z1 und Z2 durch eine Passfederverbindung auf der Welle WA

und Z3 und Z4 auf der Welle WB fixiert sind. Durch Verschieben der Welle WB kann entweder die

Zahnradpaarung Z1 und Z3 mit dem Übersetzungsverhältnis i13 oder die Zahnradpaarung Z2 und Z4 mit

dem Übersetzungsverhältnis i24 in Eingriff gebracht werden. Die physikalischen Abhängigkeiten

zwischen den Bauteilen sind in einer DSM dargestellt. Aus der DSM wird ersichtlich, dass bei einer

Änderung an der Welle WA ggf. der Innendurchmesser der Zahnräder Z1 und Z2, die Nut in den

Zahnrädern sowie der Bohrungsdurchmesser im Gehäuse angepasst werden müssen. Da die

Abhängigkeiten zwischen den Bauteilen nicht symmetrisch sind, können sich bei einer Änderung am

Zahnrad Z1 der Außendurchmesser der Welle WA, die Passfeder, das Übersetzungsverhältnis i13 und die

Verzahnung an Bauteil Z3 ändern. Neben den physikalischen Abhängigkeiten lassen sich auch die

Drehmomentflüsse im Getriebe mit Hilfe einer DSM darstellen.

Das Drehmoment MZ1 und MZ2 der Zahnräder Z1 und Z2 hängt direkt vom Drehmoment der

Eingangswelle MA ab. Die Drehmomente MZ3 und MZ4 der Zahnräder Z3 und Z4 sind über die

Übersetzungsverhältnisse i13 und i24 mit den Drehmomenten MZ1 und MZ2 verknüpft. Tritt eine Änderung

an den Drehmomenten eines Bauteils des Getriebes auf, können die Auswirkungen auf die

Drehmomente der anderen Bauteile analysiert werden. Im Beispiel verdoppelt sich das

Antriebsdrehmoment MA, das auf die Welle WA wirkt. Durch eine Multiplikation der Momenten-DSM mit

dem Änderungsvektor erhält man die Auswirkungen der Änderung 1. bis n. Grades. Diese zeigen, wie

sich eine Veränderung des Drehmoments von der Eingangswelle WA über die Zahnräder Z1 und Z2 auf

die Zahnräder Z3 und Z4 und von dort auf die Abtriebswelle WB fortsetzt. Die Addition der

Änderungsvektoren zeigt die kumulierte Änderung der Drehmomente.

(Gärtner 2011)

Eine Änderung der Drehmomente hat Auswirkungen auf die physikalische Gestaltung

der Bauteile. Die bestehenden Abhängigkeiten können mit Hilfe einer Produkt-

Momente-DMM erfasst und dargestellt werden. Beispielsweise hat eine Änderung des

Drehmoments MA Auswirkungen auf den Durchmesser dA der Welle WA oder auf die

Werkstoffwahl sowie auf die Passfederverbindung nf1 und nf2.

Durch die Multiplikation der Produkt-Momente-DMM mit dem kumulierten

Änderungsvektor erhält man einen Vektor, der die Änderungen enthält, die zur

Anpassung der Drehmomente an den Bauteilen vorgenommen werden müssen.

Dabei können die Bauteile entweder durch eine Erhöhung des Bauteildurchmessers

bzw. der Bauteilbreite an die höheren Momente angepasst oder ein anderer Werkstoff

gewählt werden.

Änderungen an der physikalischen Gestalt des Produktes haben ggf. einen Einfluss

auf den Entwicklungsprozess, den Produktionsprozess, die verwendeten

Ressourcen, die Arbeitspersonen bzw. CE-Teams usw. Diese Zusammenhänge

könnten ebenfalls in mehreren DSM und DMM in einem durchgängigen Modell

abgebildet werden. Mittels Berechnung und Simulation können anschließend

Szenarien erzeugt werden, in denen die möglichen Auswirkungen auf die Elemente

der Systeme ausgehend von einer Änderung systematisch aufgezeigt werden. Durch

die Quantifizierung der Abhängigkeiten werden die Änderungen nicht nur lokalisiert,

sondern auch ihr Umfang bestimmt. Durch einen Optimierungsansatz kann

anschließend das beste Szenario ausgewählt werden. Dieses Vorgehen kann das

Projekt- und Änderungsmanagement bei der Entwicklung von Produktvarianten und

der Vorhersage des Änderungsumfangs unterstützen, indem erfahrungsbasierte

Methoden durch ingenieurwissenschaftliche Ansätze erweitert werden.

(Gärtner 2011)

Die Sequenzierung einer dynamischen DSM soll am Beispiel des

Entwicklungsprozesses eines Automobils verdeutlicht werden. Ein solcher

Produktentwicklungsprozess beschreibt grundsätzlich die Transformation von

Eingangsinformationen in Ausgangsinformationen, die das Produktdesign und den

Produktionsprozess beschreiben. Die Start- und Endpunkte jedes Prozesses sind

diskrete Zeitpunkte, zu denen die zur Transformation notwendigen Informationen

bereitstehen. Um die Komplexität zu reduzieren und die Ausführung der

problemlösenden Arbeit bei der Produktentwicklung zu ermöglichen, wird ein

Entwicklungsprozess in kleinere voneinander abhängige Aktivitäten aufgeteilt. Die

auszuführenden Aktivitäten erhalten von den ihnen vorgelagerten Aktivitäten

Informationen wie Lastenhefte, Konstruktionszeichnungen, Prototypen etc. und

transformieren diese Informationen in eine bestimmte Form, so dass die

nachfolgenden Aktivitäten diese Informationen weiterverarbeiten können.

(Gärtner 2011)

Die im Beispiel dargestellte Prozess-DSM besteht aus 15 Aktivitäten. Markierungen

unterhalb der Hauptdiagonalen kennzeichnen die Informationsweitergabe an

nachfolgende Aktivitäten. Markierungen oberhalb der Hauptdiagonalen stellen einen

Informationsfluss zu bereits anteilig oder fertig bearbeiteten Aktivitäten dar.

Ausgehend von der Abbildung der Informationsabhängigkeiten in der DSM können

Bearbeitungsstrategien abgeleitet werden. Es kann zwischen einer parallelen, einer

sequentiellen, einer überlappenden und einer aufgrund von informatorischen

Kopplungen iterativen Bearbeitung unterschieden werden. Iterative Bearbeitung bzw.

sog. Iterationen sind eine fundamentale Charakteristik von komplexen

Produktentwicklungsprojekten. Jeder Lösungsprozess eines komplexen Problems

beinhaltet zu einem gewissen Teil Aktivitäten des Ausprobierens, der Suche und der

Neuorientierung. Wird ein Fehler oder eine Annahme als falsch erkannt, wird ein Teil

der Aktivität als iterationsbedingte Nacharbeit im Rahmen einer Iterationsschleife

wiederholt mit dem Ziel, den laufenden Entwicklungsprozess zu verbessern. Besteht

keine Informationsabhängigkeit zwischen zwei Aktivitäten, können diese, falls alle zur

Bearbeitung notwendigen Informationen, Arbeitspersonen bzw. Teams und

Ressourcen zur Verfügung stehen, nebenläufig, d.h. parallel vollzogen werden.

Besteht eine unidirektionale Informationsabhängigkeit zwischen zwei Aktivitäten, wird

die Bearbeitung zunächst mit der informationserzeugenden Aktivität begonnen.

Sobald die notwendigen Informationen für die informationsverarbeitende Aktivität

fertiggestellt sind, wird diese Aktivität gestartet. Werden diese Informationen erst

vollständig mit der Fertigstellung der Aktivität erzeugt, wird die nachfolgende Aktivität

sequentiell bearbeitet.

Aus den in einer Prozess-DSM dokumentierten Informationsabhängigkeiten können

Arbeitsprozesse deduzieren werden (siehe Folie 6). Voraussetzung ist, dass der

Informationsfluss mit dem Kontrollfluss identisch ist und keine Beschränkungen bzgl.

der zur Verfügung stehenden Arbeitspersonen und Ressourcen bestehen.

(Gärtner 2011)

Sequenzierungsalgorithmus nach Gebala & Eppinger (1991)

Schritt 1: Identifiziere eine unabhängige Aktivität, d.h. eine leere Zeile oder Spalte.

Eine leere Zeile wird in der DSM möglichst weit oben eingeordnet. Eine

leere Spalte wird in der DSM möglichst weit unten eingeordnet. Wiederhole

diesen Schritt, bis keine leere Zeile oder Spalte mehr identifiziert werden

kann.

Schritt 2: Identifiziere gekoppelte oder voneinander abhängige Aktivitäten. Fasse die

gekoppelten oder voneinander abhängigen Aktivitäten zu einer aggregierten

Aktivität bzw. zu einem Block zusammen. Für diesen Block wird die

Sequenzierung erneut ausgeführt.

Schritt 3: Wiederhole die Schritte 1 und 2, bis alle Aktivitäten identifiziert und

sequenziert wurden.

Beispiel:

(1) Aktivität F ist (informatorisch) unabhängig von allen anderen Aktivitäten und wird an den

Anfang der DSM eingeordnet.

(2) Von Aktivität E ist keine weitere Aktivität abhängig. Aktivität E wird an das Ende der DSM

eingeordnet.

(3) Die Aktivitäten A und C sind gegenseitig voneinander abhängig und werden iterativ

ausgeführt. A und C werden zu einer aggregierten Aktivität CA zusammengefasst.

(4) Die aggregierte Aktivität CA ist innerhalb des zu sequenzierenden Blocks von allen

anderen Aktivitäten unabhängig und wird an das Ende des Blocks eingeordnet.

(5) Die Aktivitäten B, D und G sind untereinander voneinander abhängig: B hängt von G ab, G

hängt von D ab und D wiederum wird von B beeinflusst.

(6) Mit der zweiten identifizierten Iteration der Aktivitäten B, D und G sind alle Aktivitäten der

DSM sequenziert. Die resultierende DSM ist eine untere Dreiecksmatrix mit möglichst

wenigen Markierungen oberhalb der Diagonalen. Das kennzeichnet einen weitestgehend

vorwärtsgerichtete Prozessfluss mit möglichst wenigen Iterationen.

Die Domain Mapping Matrix (DMM) basiert auf der DSM und stellt eine Erweiterung

dieser hinsichtlich der Verknüpfung von unterschiedlichen Systemen dar. Unter einem

System wird hierbei jede in Form einer DSM abbildbare Architektur, bspw. Produkt,

Organisation, Prozess, Parameter, verstanden. Jedes System mit i Elementen kann

mit einem anderen Typ mit j Elementen in einer DMM (i,j) verknüpft werden. Die DMM

wird verwendet, um den Einfluss eines Systems auf ein anderes System abzubilden.

Synonyme Bezeichnungen sind „Einfluss-Auswirkungsmatrix“ (Cause and Effect

Matrix) oder „Schnittstellenmatrix“ (Interface Structure Matrix).

Beispielsweise ergibt sich die Prozess-Produkt-DMM (n x m) durch die Kombination

der m Bauteile des Produktes mit den n Aktivitäten eines Prozesses in einer Matrix

und der Bestimmung der Abhängigkeiten zwischen diesen. Das Element aij der n x m

Prozess-Produkt DMM beschreibt den Einfluss, den das j-te Elemente der m x m

Produkt Matrix auf das i-te Element der n x n Prozess Matrix besitzt. Der Begriff DMM

wurde durch Danilovic und Börjesson geprägt, die diese verwendeten, um die

Schnittstelle zwischen Produkt und Organisation zu analysieren (Danilovic &

Börjesson 2001).

In der „Periodentafel“ der DSMs und DMMs werden fünf Systeme angeordnet und die

Verknüpfung dieser Systeme dargestellt. Diese Systeme bilden bspw. die Grundlage

für die Darstellung und Analyse der Komplexität und Dynamik sowie von

Unsicherheiten in Produktentwicklungsprojekten. Jeder der in der Periodentafel

abgebildeten DSMs oder DMMs repräsentiert ein entscheidendes Element eines

Produktentwicklungsprojektes. Aufbauend auf dieser Darstellung können zudem

weitere potentielle Abhängigkeiten und Beziehungen in einem Projekt identifiziert und

daraus die Notwendigkeit von Informationsbeziehungen zwischen unterschiedlichen

Systemen abgeleitet werden (Danilovic & Browning 2007).

Unter Änderungsmanagement versteht man standardisierte Prozesse, mit denen

Änderungen an Produkten kontrolliert und dokumentiert werden. In einer

Änderungsanforderung werden meist die zu ändernden oder neu herzustellenden

Produkteigenschaften beschrieben. Des Weiteren werden die betroffene

Produktversion und der Änderungsgrund dokumentiert sowie aus der Änderung

resultierende Kosten (z.B. Personalkosten etc.) und zusätzlicher Zeitaufwand (z.B. für

Konzeption, Entwicklung, Test etc.) abgeschätzt.

Da Änderungsanforderungen meist bestehende Vertragsverhältnisse tangieren,

müssen sie gemeinsam von Auftraggeber und Auftragnehmer in einem kontrollierten

Prozess bewertet, entschieden und freigegeben werden. Mit der DMM lassen sich

Ein- und Rückwirkungen von Änderungsanforderungen präzise analysieren.

In dem Beispiel werden Produktanforderungen von Abteilung 1 definiert. Abteilungen

2 und 3 setzen diese Anforderungen in entsprechende Produktfunktionen um. In der

DMM wird dokumentiert, welche Produktfunktion von einer Produktanforderung

beeinflusst werden. Sollten während des Entwicklungsprozesses

Produktanforderungen geändert werden, können direkte Auswirkungen wie auch

indirekte Folge- und Rückwirkungen einer Produktänderung untersucht werden (siehe

Folien 33 und 34).

In einem Unternehmen des Anlagenbaus für Energieversorgungen werden von der

Abteilung Produktmanagement Anforderungen an das zu entwickelnde Produkt

erstellt. Diese Anforderungen sollen von den Fachabteilungen Leistungselektronik,

mechanische Konstruktion und Regelungstechnik umgesetzt werden. Im obigen

Beispiel ist eine Abhängigkeitsmatrix von Produktanforderungen und Funktionen

dargestellt.

Die Produktanforderungen beeinflussen die Funktionen, die von den Fachabteilungen

zu entwickeln sind, beispielsweise beeinflusst die Forderung „<x kg Gewicht“, die von

der Abteilung Leistungselektronik zu entwickelnden Funktionen „Eingangs-Elkos:

Baugröße“, „Hochsetzsteller Drosseln: Baugröße“ und „Zwischenkreis-Elkos:

Baugröße“. Gleichzeitig kann man erkennen, dass auch die Produktanforderungen

sich gegenseitig beeinflussen.

Aus der Analyse der DSM und der Schnittstellen lassen sich verschiedene

interessante Erkenntnisse ableiten:

Bewusstsein über Auswirkungen der eigenen Änderungen:

Der eigentliche Nutzen dieser Schnittstellenmatrix (die ja vom Experten der

mechanischen Konstruktion definiert wurde) besteht darin, dass sie beim Experten

der Leistungselektronik ein Bewusstsein dafür schafft, wie sich die Ergebnisse seiner

Arbeit auf den Bereich der mechanischen Konstruktion auswirken. Genau dieser

Punkt wurde von den Fachexperten als sehr hilfreich bewertet. Wenn also in der

mechanischen Konstruktion ein Parameter geändert wird, dann wird durch die

Definition der Schnittstellen aufgezeigt, dass im Bereich der Regelungstechnik

weitere Parameter betroffen sind, so dass der andere Fachbereich ebenfalls frühzeitig

zu informieren ist.

Analyse der Aufbauorganisation:

Wird der Bereich der Fachabteilungen betrachtet, so fällt auf, dass jeweils innerhalb

der abteilungsspezifischen DSM mehr Abhängigkeiten bestehen als in den

Schnittstellen zwischen den Abteilungen. Dies verdeutlicht, dass die

organisatorischen Bereiche der Fachabteilungen sehr gut die inhaltlich

zusammenhängenden Arbeitsschritte reflektieren.

Werden allerdings die Schnittstellen zwischen den verschiedenen Parameter-DSMs

und die Schnittstellen zwischen der Anforderungs-DSM und den Parameter-DSMs

betrachtet, dann fällt auf, dass die Abhängigkeitsstrukturen völlig unterschiedlich sind.

Besonders auffällig ist, dass zwischen Produktmanagement und den Fachabteilungen

offenbar mehr Abhängigkeiten bestehen als innerhalb der Fachabteilungen. Diese

inhaltlichen Abhängigkeiten müssten sich eigentlich in einer sehr intensiven

Zusammenarbeit zwischen den Abteilungen Produktmanagement und den einzelnen

Fachabteilungen widerspiegeln.

Gestaltungsreihenfolge und Umfang der Anhängigkeiten:

Bei der detaillierten Analyse der DSM fiel auf, dass in den Bereichen

Leistungselektronik und Regelungstechnik weniger Abhängigkeiten bestehen als im

Bereich „mechanische Konstruktion“ und dass diese Abhängigkeiten bei der

Leistungselektronik und der Regelungstechnik relativ eng um die Diagonale

angeordnet sind, während die Abhängigkeiten im Bereich mechanische Konstruktion

im Durchschnitt weiter von der Diagonalen entfernt sind. Dies deutet darauf hin, dass

bei der Leistungselektronik und der Regelungstechnik die Reihenfolge der Parameter

in etwa mit der Gestaltungsreihenfolge dieser Parameter übereinstimmt und dass nur

Abhängigkeiten zwischen wenigen Parametern bestehen. Bei der mechanischen

Konstruktion ist dagegen zu überlegen, ob die Gestaltungsreihenfolge verändert

werden sollte, so dass einzelne Parameter früher spezifiziert werden können. Eine

Verringerung der Abstände könnte auf diese Weise erreicht werden. Aber auch bei

einer günstigeren Reihenfolge würde sich noch ein relativ großes Cluster an

Abhängigkeiten ergeben. Eine Anforderungsänderung oder eine Änderung von

Produktparametern in diesem Bereich würde somit weiterhin mit einer hohen

Wahrscheinlichkeit einen enormen Änderungsaufwand mit sich bringen, da immer

sehr viele Parameter überprüft und angepasst werden müssen.

Es bleibt daher festzuhalten, dass mit Hilfe einer DSM Änderungen verfolgt werden

können, die sich ergeben, wenn ein Element in der Matrix geändert wird.

Das Beispielsszenario besteht darin, dass die Anforderung 16 im laufenden

Konstruktionsprozess geändert wird. Und zwar soll die Schutzart des Wechselrichter

von IP 54 auf IP 64 geändert werden. Das wurde hier visualisiert, indem das

Diagonalen-Element der Anforderung 16 rot markiert wurde.

Mit der sog. „Schutzart“ wird die Eignung von elektrischen Betriebsmitteln (z.B.

Gehäuse in der Leistungselektronik) für verschiedene Umgebungsbedingungen

quantifiziert. Die „Schutzart“ wird in Ingress Protection Codes (Eindringschutzklasse)

oder kurz: IP-Codes (Schutzklasse) eingeteilt. Der Code setzt sich aus zwei

Kennziffern zusammen, mit denen jeweils der Schutzgrad bezüglich Berührungs- und

Fremdkörper sowie Feuchtigkeit bzw. Wasser beschrieben wird. Mit dem Code IP 54

werden Gehäuse klassifizieren, die sowohl gegen Staub in schädigender Menge,

vollständig gegen Berührungen als auch gegen allseitiges Spritzwasser schützen. Mit

dem Code IP 64 werden Gehäuse klassifizieren, die alle Schutzgrade von Gehäusen

der Klasse IP 54 besitzen und darüber hinaus nicht nur gegen Staub in schädigender

Menge schützen, sondern vollständig staubdicht sind.

Im nächsten Schritt werden alle von dieser Änderung beeinflussten Schnittstellen

ebenfalls rot markiert, d.h. alle Markierungen in Spalte 16. Von allen diesen

Markierungen wird das Lot auf die Diagonale gefällt und die entsprechenden

Diagonalen-Elemente werden ebenfalls rot markiert. Das Resultat dieser Analyse ist,

dass die Änderung von Anforderung 16 sieben wahrscheinliche Auswirkungen hat:

Die Kosten, das Volumen und die Umgebungstemperatur werden wahrscheinlich

beeinflusst. Konkret werden in der Abteilung Mechanische Konstruktion das Volumen

der Wechselrichterwanne beeinflusst sowie das Design der Displayblende. Ebenfalls

in der Abteilung mechanische Konstruktion müssen die Gleichstromstecker

überarbeitet werden und zwar müssen sowohl die Abmaße als auch die zulässige

Spannung angepasst werden.

In einem weiteren Schritt werden nun alle Beeinflussungen zweiten Grades ermittelt und zwar

jeweils auf die gleiche Art und Weise wie soeben eingeführt: Jeweils alle Markierungen in der

Spalte eines rot markierten Elementes werden ebenfalls rot markiert und von diesen

Markierungen wird das Lot auf das Diagonale-Element gefällt.

Das Ergebnis dieser Analyse sieht wie folgt aus:

Es gibt 52 mögliche Auswirkungen und zwar 19 mögliche Auswirkungen auf andere

Anforderungen, 7 mögliche Auswirkungen auf die Parameter der Abteilung

Leistungselektronik, 23 mögliche Auswirkungen auf die Abteilung mechanische Konstruktion

und 3 mögliche Auswirkungen auf die Abteilung Regelungstechnik.

UND: Es existieren 12 mögliche Rückwirkungen von Parameteränderungen auf die

Anforderungen, die nicht in der Abhängigkeitsmatrix hinterlegt sind. Diese Rückwirkungen

können sehr einfach in der transpositionierten QFD identifiziert werden.

Durch diese wird auch deutlich, dass sich mehrere Aus- bzw. Rückwirkungen auf ein Element

beziehen können. Beispielsweise gibt es hier 5 Aus- bzw. Rückwirkungen, die sich auf das

Element Kosten beziehen. Dies bedeutet, dass die Zahl von 52 möglichen Auswirkungen sich

eigentlich in wesentlich weniger Elementen niederschlägt.

Die Analyse verdeutlicht, dass eine einzelne Änderung sehr viele Änderungen zweiten Grades

verursachen kann, die über viele organisatorische Einheiten verteilt auftreten können. Die

daraus resultierende hohe Zahl an Wirkbeziehungen macht es einem Produktmanager oder

einem Entwickler nahezu unmöglich, die daraus resultierenden Auswirkungen zu überblicken

und bei einer Entscheidung korrekt zu berücksichtigen.

Eine matrixbasierte Methode bietet dagegen den Vorteil, die möglichen Änderungen

systematisch zu eruieren und stellt damit eine praktikable Unterstützung bei der

Anforderungsanalyse dar.