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.