Ein Beispiel für ein in Teilen fehlgeschlagenes Großprojekt ist die Entwicklung des

Airbus A380.

Der Airbus A380 ist das zur Zeit größte in Serienfertigung produzierte

Passagierflugzeug der Welt. Es handelt sich beim A380 um das erste

Großraumflugzeug mit zwei durchgängigen Passagierdecks, auf denen maximal 853

Passagiere Platz finden. Neben der Erhöhung der Passagierzahlen sollten die

spezifischen Betriebskosten des Flugzeuges pro Kilometer und Person soweit

gesenkt werden, dass der A380 im Vergleich zu anderen Flugzeugen mit um 15%

geringeren Kosten betrieben werden kann. Diese zentrale Forderung stellte die

Entwickler vor neue Herausforderungen. Die Ziele konnten nur durch den Einsatz

fortschrittlicher Werkstoffe und neuartigen Bauweisen erreicht werden. Nach

Unternehmensangaben betrugen die Entwicklungskosten in den acht Jahren

zwischen 2000 und 2007 insgesamt zwölf Milliarden Euro.

Airbus gab am 13. Juni 2006 bekannt, dass die A380-Auslieferungen wegen

Problemen mit der Kabinenelektronik um sechs bis acht Monate verschoben werden

müssten. Die Probleme lagen unter anderem an uneinheitlichen IT-

Entwicklungsumgebungen, die eine umfangreiche Konvertierung der Daten per Hand

erforderte. Am 3. Oktober 2006 gab Airbus bekannt, dass sich die Auslieferung der

ersten Maschinen im Schnitt um ein weiteres Jahr aufgrund von Problemen mit der

Verkabelung verzögern werde. Gemäß dem neuen Auslieferungsplan wurde die erste

Maschine am 15. Oktober 2007 an Singapore Airlines übergeben. 2007 sollte somit

nur eine A380 an einen Kunden übergeben werden, gefolgt von 13 im Jahr 2008 und

25 im Jahr 2009. 2010 sollten 45 Maschinen an die Kunden übergeben werden und

erstmals ein operativer Gewinn bei der A380-Produktion verzeichnet werden.

Die Abbildung stellt den Verlauf mehrerer parallel laufender Projekte in einem KMU

der elektrotechnischen Industrie dar. Die Datenerfassung bei dem betrachteten

Unternehmen erfolgt auf ungewöhnliche Art und Weise: sämtliche Tätigkeiten werden

durch die Mitarbeiter mit einem lückenlosen Selbstaufschreibungsverfahren

dokumentiert. Für jeden Auftrag wird ein Laufzettel erstellt, auf dem die einzelnen

Aufgaben aufgeführt und mit einem Barcode versehen werden. Mittels eines

Barcodescanners buchen die Mitarbeiter Beginn und Ende sämtlicher

Aufgabenbearbeitungen. Werden nicht-projektspezifische Aufgaben bearbeitet, wird

dies gesondert gebucht. Pausen und Fehlzeiten müssen ebenfalls gebucht werden.

Somit kann lückenlos festgestellt werden, wann und wie lange ein Mitarbeiter welche

Aufgaben für welche Entwicklungsprojekte bearbeitet hat und wann diese fertig

gestellt wurden.

Die Daten zeigen, dass eine sehr große Parallelität in der Aufgabenbearbeitung

vorherrscht. So zeigt sich, dass ab einem Fertigstellungsgrad von ca. 40% die

Konzepterstellung von Projekt A zeitweilig unterbrochen wird und zunächst mit der

auf dem bisherigen Konzept beruhenden Schaltplanerstellung für Projekt A begonnen

wird. Ist diese zu ca. 30% abgeschlossen, so fließen die hierbei gesammelten

Erfahrungen in die weitere Konzepterstellung ein; diese wird nun zunächst

weiterbearbeitet. Zusätzlich beginnt der Mitarbeiter mit der Layouterstellung auf Basis

der bisherigen Ergebnisse. Es zeigt sich, dass die Konzepterstellung für Projekt A

immer wieder bearbeitet wird, sie begleitet die gesamte Projektlaufzeit. Neben den

parallel ablaufenden Aufgaben existieren aber auch Vorgänger-Nachfolger-

Beziehungen. So wird die Prototyperstellung von Projekt A erst begonnen, wenn

sowohl die Schaltplanerstellung als auch die Layouterstellung abgeschlossen

wurden, allerdings erfolgt die Konzepterstellung auch hier weiter parallel. Die Struktur

der Projektlandschaft ist also vielfältig und komplex und kann nur mit Hilfe

weiterführender Modellierungsmethoden beschrieben werden.

Die Globalisierung schafft neue Herausforderungen für die Entwicklung neuer

Produkte. Um wettbewerbsfähig zu bleiben, müssen qualitativ hochwertige Produkte

in immer kürzeren Zyklen und zu einem wettbewerbsfähigen Preis auf den Markt

kommen.

Hierdurch entstehen Probleme, die durch ein wirkungsvolles Projektmanagement

behoben werden müssen. Zu diesen Problemen zählen:

• Zeitdruck durch kürzere Entwicklungszyklen

• Kostendruck durch internationale Konkurrenz

• parallele Projektbearbeitung, da sich auslaufende Projekte häufig schon mit neuen

Projekten überlappen

• Einsatz der Mitarbeiter in mehreren Projekten gleichzeitig

• weltweite räumliche Verteilung der Mitarbeiter

• dadurch: Ressourcenkonflikte (Betriebsmittel aber auch Personen)

Da herkömmliche Prozess-Modellierungssprachen das Management solch komplexer

Projekte nur ungenügend unterstützen, sind andere Modellierungsansätze

erforderlich. In dieser Vorlesungseinheit werden die

• Design Structure Matrix (DSM) und die

• Work Transformation Matrix (WTM) mit ihren Erweiterungen als Ansätze zur

Modellierung von Produktentwicklungsprojekten vorgestellt.

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

stellt den Zusammenhang zwischen Informationen einzelner Aktivitäten dar. Diese

Methode wird benutzt, um komplexe Zusammenhänge in der Produktentwicklung

oder Projektplanung darzustellen. In einer Matrix werden alle Elemente eines

Systems auf ihre Abhängigkeit und den Grad der Abhängigkeit (z.B. mit Hilfe von

Zahlen anstelle der dargestellten Punkte) bewertet. Daraus kann abgeleitet werden,

welche Aktivitäten nötig sind, um eine Aktivität starten zu können und zeigt auf,

welche Informationen durch eine Aktivität generiert werden. Durch Lesen in

Spaltenrichtung erkennt man 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. Die DSM ermöglicht es, den Projektablauf zu

verbessern, Informationsabhängigkeiten zu visualisieren, ein gemeinsames

Verständnis von Abhängigkeiten zu entwickeln und kann bei der Prozessoptimierung

unterstützen.

Aus den in der Design Structure Matrix dargestellten Informationsabhängigkeiten

können Prozesse abgeleitet werden, um damit den Projektablauf zu visualisieren.

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

Flussdiagramm verloren.

Im obigen Beispiel hängt Aktivität 1 von keiner weiteren Aktivität ab und ist damit die

Startaktivität. Aktivität 2 benötigt Informationen aus Aktivität 1 und aus Aktivität 5.

Aktivität 3 und Aktivität 4 laufen entweder simultan oder alternativ ab. Darüber wird in

der DSM keine Aussage gemacht. Aktivität 5 benötigt Informationen aus den

Aktivitäten 3, 4 und 6 und wirkt zusammen mit Aktivität 4 auf die Aktivität 6, so dass

Aktivitäten 5 und 6 gekoppelt ablaufen.

Die Abbildung zeigt eine Anwendung der DSM-Methode im Entwicklungsprozess

einer Gasturbinenschaufel der Firma ABB.

Aufgrund der extrem hohen technischen Anforderungen an die Gasturbinenschaufeln

ist deren Entwicklung ein aufwändiger und stark gekoppelter Prozess, der mehrere

Spezialisten aus unterschiedlichen technischen Bereichen einbezieht. Um die

Integration des Prozesses zu erhöhen, wurde bei ABB ein Projekt ins Leben gerufen,

um den Ist-Zustand des Entwicklungsprozesses zu ermitteln und anschließend

Verbesserungsmöglichkeiten zu identifizieren.

Abbildung 1 zeigt den ermittelten Ist-Zustand. In Abbildung 2 wurde der Ist-Zustand in

eine DSM transformiert. Der Hauptprozess wird in die drei Sub-Prozesse

aerodynamic design, mechanical design und verifying mechanical integrity unterteilt.

Grund für diese Unterteilung ist, dass die Aktivitäten in diesen Sub-Prozessen von

Ingenieuren unterschiedlicher Abteilungen ausgeführt werden, deren Aufgabenfelder

denen der Sub-Prozesse ähneln. Die Aktivitäten innerhalb dieser Sub-Prozesse sind

stark gekoppelt.

Einen besonderen Stellenwert nehmen Aktivitäten ein, die gegenseitig von einander

abhängig sind. Nach Abb. 1 ist sowohl ein Informationsfluss von Aktivität A zu

Aktivität B notwendig, als auch ein Informationsfluss von B zu A. Durch diese

gegenseitige Abhängigkeit kommt es zu Iterationen, Aktivitäten müssen also –

zumindest teilweise – erneut bearbeitet werden, da bei der vorherigen Bearbeitung

nicht alle notwendigen Informationen zur Verfügung standen. Diese Iterationen

führen dazu, dass Aktivitäten nach der Bearbeitung einen weiteren

Bearbeitungsaufwand haben, dieser Restbearbeitungsaufwand ist durch die

Darstellung der Aktivitäten-Abhängigkeiten in Form der WTM berechenbar.

Die WTM enthält eine genauere Angabe der Abhängigkeiten der einzelnen

Aktivitäten als die DSM. Die Matrix aus Abbildung 1 ist folgendermaßen zu lesen:

• Auf der Hauptdiagonalen sind die Aktivitätendauern angegeben, die sich ergeben

würden, wenn keine Abhängigkeiten zwischen den Aktivitäten bestehen würden,

also wenn alle Elemente, die sich nicht auf der Hauptdiagonalen befinden Null

betragen.

• Die Fertigstellung von Aktivität A bedingt einen Nachbearbeitungsbedarf für die

Aktivitäten B und C. Aktivität B muss zu 40% (0,4) neu bearbeitet werden, während

für die Bearbeitung der Aktivität C ein Nachbearbeitungsbedarf von 30% (0,3)

besteht.

• Gleichzeitig verursacht aber auch die Bearbeitung von Aktivität B einen

Nachbearbeitungsbedarf für die Aktivitäten A, C und D. So muss Aktivität A zu 20%

erneut bearbeitet werden, Aktivität C zu 10% und Aktivität D zu 20%.

• Auch die Aktivitäten C und D bedingen jeweils einen Nachbearbeitungsbedarf für

alle Aktivitäten, so dass sich ein komplexes Abhängigkeitsgefüge und daraus

abgeleitete Nachbearbeitungsaufwände ergeben.

Der Vektor U gibt den realen Gesamtbearbeitungsaufwand für eine Aktivität (in

Vielfachen der Originaldauer) wieder, der durch die gegenseitige Abhängigkeit der

Aktivitäten resultiert. Er wird durch die Summierung der einzelnen

Bearbeitungsaufwände für die einzelnen Iterationsstufen berechnet.

Ein Beispiel für die Konstruktion einer neuen Kamera veranschaulicht die

Möglichkeiten der WTM. Es wird nur der vollständig abhängige Teil der WTM

betrachtet, da es sich hierbei um den interessanten Teil des Produktdesign handelt.

Durch die gegenseitigen Abhängigkeiten werden Iterationen erzeugt, die für eine

Verlängerung der Projektdauer sorgen und deren Auswirkungen aufgrund der

gegenseitigen Abhängigkeiten nur schwer vorhersagbar sind.

Anhand dieses Beispiels wird deutlich, dass nach der einmaligen Bearbeitung aller

Aktivitäten noch ein großer Restbearbeitungsbedarf bei allen vier Aktivitäten besteht,

insbesondere Aktivität 2 und 3 sind erst zu 10% fertiggestellt. Erst nach ca. 15

Iterationsstufen ist für alle vier Aktivitäten ein Restbearbeitungsaufwand von

näherungsweise 0% erreicht.

Die WTM bietet eine weitere interessante Möglichkeit. So ist mit Hilfe der WTM die

Konvergenz bzw. Divergenz des modellierten Projektverlaufs berechenbar und somit

ein Scheitern des Projekts schon im Vorfeld erkennbar und durch geeignete

Maßnahmen zu verhindern.

Berechnung der Eigenwerte einer 2x2 Matrix:

Berechnung der Eigenwerte einen 3x3 Matrix nach der Regel von Sarrus

(siehe auch http://de.wikipedia.org/wiki/Regel_von_Sarrus):

det( )

a b c

d e f aei bfg cdh ceg afh bdi

g h i

M M

!

!3

!3

!3

det( ) 0

0,2 0,3 0,2 0,3 0,5 0,1 [0,2 ( ) 0,3 0,1 0,3 ( ) ( ) 0,5 0,2] 0

0,027 [0,19 ( )] 0

0,19 0,027 0

A I

det( ) a b

ad bcc d

M M

a b c a b

d e f d e

g h i g h

+ + +

a b c a b

d e f d e

g h i g h

– – –

0,2 0,3 0,2

0,5 0,3 0,5

0,2 0,1 0,2 0,1

Huberman & Wilkinson (2005) beseitigen insbesondere die Annahme, dass alle

Aktivitäten in jeder Stufe vollständig bearbeitet werden, wodurch eine deutlich

realistischere Abbildung erzielt wird.

Die Elemente auf der Hauptdiagonalen der erweiterten WTM sind folgendermaßen zu

interpretieren:

• Nach Ablauf einer Zeiteinheit sind in Aktivität A noch 94% (0,94) des

Bearbeitungsaufwandes der vorherigen Stufe zu investieren, wenn keine

Abhängigkeiten unter den Aktivitäten bestehen, für Aktivität B sind noch 87% zu

investieren.

• Beispiel (a11=0,94; a12=0; a21=0; a22=0,87; Bearbeitungsdauer zum Zeitpunkt 0:

D10=10 Tage; D20=5 Tage):

Nach einer Zeitschicht ergeben sich folgende Bearbeitungsaufwände:

D11=9,40 Tage; D21=4,35 Tage

Nach einer weiteren Zeitschicht:

D12=8,84 Tage; D22=3,78 Tage

D13=8,31 Tage; D23=3,29 Tage

usw.

In diesen Beispielen ist zu beachten, dass im Unterschied zur WTM die Elemente auf

der Hauptdiagonalen nicht mehr gleich Null sind.

Es wird deutlich, welche Auswirkung die gegenseitige Abhängigkeit der Aktivitäten

hat. Während in der linken Abbildung das Stoppkriterium bereits nach ca. 58 Wochen

erreicht wird, wird es in der rechten Abbildung aufgrund der auftretenden

gegenseitigen Abhängigkeit der Aktivitäten und den damit verbundenen

Nachbearbeitungsaufwänden erst nach ca. 64 Wochen erreicht.

Der Verlauf der verbleibenden Arbeit bei der Oszillation stellt natürlich keinen

realistischen Verlauf dar, da die verbleibende Arbeit keine negativen Werte

annehmen kann.

Die WTM und auch die erweiterte WTM sind in der Praxis nicht genau bestimmbar.

So treten in nahezu jedem Projekt unvorhergesehene Störungen auf, die im Vorfeld

nicht zu erkennen und abzuschätzen waren. Diese Störungen lassen sich durch die

Einführung eines stochastischen Faktors integrieren.

Die WTM und auch die erweiterte WTM sind in der Praxis nicht genau bestimmbar.

So treten in nahezu jedem Projekt unvorhergesehene Störungen auf, die im Vorfeld

nicht zu erkennen und abzuschätzen waren. Diese Störungen lassen sich durch die

Einführung eines stochastischen Faktors integrieren.

Für Aufgabe 1 wird deutlich, dass sich der reale Projektverlauf sehr gut mit Hilfe einer

stochastischen, erweiterten WTM beschreiben lässt, wodurch die Praxistauglichkeit

dieser Methodik verdeutlicht wird.

Im obigen Beispiel wird die Design Structure Matrix (DSM) zum Abschätzen der

Dauer des Entwicklungsprozesses eines Fahrzeugsteuergeräts angewandt. In

Entwicklungsprozessen sind die einzelnen Aktivitäten bedingt durch ein Concurrent

Engineering hochgradig verkoppelt, d.h. Aktivitäten werden parallel bearbeitet und

gestartet, ohne dass die für die Bearbeitung der Aktivität notwendigen Informationen

vollständig vorliegen. Dies führt zu einer iterativen Bearbeitung der Aktivitäten. Die

Informationsabhängigkeiten zwischen den Aktivitäten eines Entwicklungsprozesses

und die Iterationen können mit Hilfe der DSM abgebildet werden. Die DSM besteht

dabei aus einer Wahrscheinlichkeitsmatrix, in der die Wahrscheinlichkeiten für

Iterationen, d. h. für die erneute Durchführung einer Aktivität, dargestellt sind, aus

einer Mehrarbeitsmatrix zur Angabe der Nacharbeit einer Aktivität in einer Iteration

und der Veränderung der Wahrscheinlichkeit für Iterationen. Durch eine Monte-Carlo-

Simulation kann aus den Matrizen und der Dauer der einzelnen Aktivitäten die Dauer

eines Entwicklungsprozesses abgeschätzt werden.

Um Produktänderungen in die Simulation mit einfließen zu lassen, müssen sowohl

der Zeitpunkt, der Umfang der einfließenden Änderungen, die Verkopplung der

Bauteile und der Einfluss der Bauteile auf die Aktivitäten abgeschätzt werden. Das

betrachtete Steuergerät beinhaltet fünf Primärfunktionen („A“-„E“), die bei der

Entwicklung aufeinander abgestimmt werden müssen. In einem abgeschlossenen

Entwicklungsprojekt erfolgte nach der Aktivität „Vorbereitung der Applikationsklausur“

eine aus der Baureihe induzierte 30 prozentige Änderung an der Funktion „A“.

Verwendet man diese Information in Form des Änderungsvektors als Input für die

Simulation, erhält man als Ergebnis den Änderungsgrad der zu entwickelnden

Funktionen sowie die Abschätzung der durch die Änderung verlängerten

Prozessdauer und -kosten. Aufgrund der erforderlichen Abstimmung mit den anderen

Funktionen führt die 30 prozentige Änderung zu 3,6% Änderung der Funktion „B“, zu

3,5% Änderungen der Funktion „C“, zu 6,8% Änderungen der Funktion „D“ und zu

3,4% Änderungen der Funktion „F“. Aufgrund dieser Änderungen kommt es zu

Rückwirkungen auf die Funktion „A“, die um insgesamt 32,9% verändert werden

muss. Das Projekt verlängert sich dadurch durchschnittlich um 19 ZE auf insgesamt

140,5 ZE, wodurch die Erfahrungswerte aus den abgeschlossenen Projekten gut

widergespiegelt werden. Die Verlängerung der Projektdauer erhöht zudem die

Kosten um durchschnittlich 19%.

Durch die Produktänderung erhöht sich die Wahrscheinlichkeit für Iterationen im

Projekt, so dass die Streuung der Ergebniswerte im Vergleich zur Simulation ohne

Produktänderung zunimmt. Dies drückt sich in der Erhöhung der Varianz von 40,8

[ZE²] auf 47,7 [ZE²] aus. D.h. Produktänderungen bewirken neben der Verlängerung

der Entwicklungsdauer und Erhöhung der Kosten eine höhere Wahrscheinlichkeit für

zusätzliche Iterationen und damit ein höheres Risiko des Nichteinhaltens von Zeit-

oder Budgetzielen. Dies spricht für eine frühzeitige und detaillierte Festlegung der

Anforderungen, die im Laufe des Projekts nur so wenig und so früh wie möglich

geändert werden sollten.