Download - Ein Beispiel für ein in Teilen zeitweise sehr ...notizen.pdf · Ein Beispiel für ein in Teilen zeitweise sehr problematisches Großprojekt ist die Entwicklung des Airbus A380. Der

Transcript

Ein Beispiel für ein in Teilen zeitweise sehr problematisches Großprojekt ist die

Entwicklung des Airbus A380.

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

Verkehrsflugzeug 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 CAD-

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. Nach

aktuellem Stand (Dezember 2011) wurden bislang insgesamt 243 Maschinen bestellt

und 63 fertige Maschinen ausgeliefert.

Die Abbildung stellt den Verlauf von drei parallel laufenden Projekten A, B und C 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 sowohl für Großunternehmen als auch KMU 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

• Grundlagen dynamischer Design Structure Matrizen (DSM) nochmals kurz

wiederholt und die

• Work Transformation Matrix (WTM) mit ihren Erweiterungen als neuer Ansatz zur

Modellierung von Produktentwicklungsprojekten vorgestellt.

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, um damit den Projektablauf zu planen und zu

steuern. 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. Bei geringer

Verfügbarkeit von Personal oder Einsatzmitteln kann auch eine sequentielle

Bearbeitung erforderlich sein. 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

hoch spezialisiert sind (Strömungsmechanik, Strukturmechanik etc.). 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 Zusatzarbeitsaufwand 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. Hierbei wird eine einheitliche Zeitskala mit bestimmter Zeiteinheit [ZE]

verwendet.

• 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.

Die erste Zeitschicht t = 0 kennzeichnet den Projekt- bzw. Prozessbeginn. Es wird

angenommen, dass zu Beginn jede Aktivität noch vollständig bearbeitet werden

muss. Allerdings können dem Vektor auch nichtnegative Werte kleiner eins

zugewiesen werden. Dadurch können zeitweise oder vollständig parallel zu

bearbeitenden Aktivitäten modelliert werden.

Der Vektor U gibt den kumulierten Arbeitsaufwand 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 Arbeitsaufwände für die

einzelnen Iterationsstufen berechnet.

Konvergiert der kumulierte Arbeitsaufwand für T gegen unendlich (T ), so kann

der Gesamtaufwand der Einzelaktivitäten U nach T Iterationsschritten in Form einer

geschlossenen Lösung auf Basis der Neumann- oder Neumann‘schen Reihe

berechnet werden.

Ein Beispiel für die Konstruktion einer neuen Digitalkamera 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 der Produktentwicklung

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 Zusatzarbeitsaufwand bei allen vier Aktivitäten durch die

Wechselwirkungen 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

Zusatzarbeitsaufwand erreicht, der 1% unterschreitet.

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):

+ + + – – –

bcaddc

ba

)det( MM

bdiafhcegcdhbfgaei

ihg

fed

cba

)det( MM

hg

ed

ba

ihg

fed

cba

hg

ed

ba

ihg

fed

cba

0027,019,0

0)](19,0[027,0

0]2,05,0)()(3,01,03,0)(2,0[1,05,03,02,03,02,0

0)det(

1,02,0

5,0

2,0

1,02,0

0,35,0

0,32,0

!3

!3

!3

!

0

IA

Huberman & Wilkinson (2005) beseitigen durch ein erweitertes Modell 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

Arbeitsaufwandes 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 zwei weiteren Zeitschichten:

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

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

usw.

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

Elemente auf der Hauptdiagonalen stets größer Null sind.

In den Beispielen konvergieren die Projekte, denn der Maximalwert des Betrags der

Eigenwerte ist jeweils kleiner als Eins. Falls ein Projekt divergieren sollte, so würde

der verbleibende Aufwand über alle Grenzen ansteigen (siehe zweites Beispiel auf

nachfolgender Folie). In diesem Fall müssten das Projekt und die Abhängigkeiten

zwischen den Aktivitäten neu konzipiert bzw. umgestaltet werden.

Selbst für den Fall, dass ein Projekt konvergiert, ist theoretisch eine unbegrenzte

Anzahl an Iterationen notwendig, um den Zustand zu erreichen, in dem der

verbleibende Aufwand aller Aktivitäten exakt Null ist. Deshalb wird ein

Abbruchkriterium definiert [0;1], das das Erreichen des Projektabschlusses

anzeigt. Das Projekt gilt als abgeschlossen, wenn für alle Aufgaben der verbleibende

Aufwand kleiner 8 ist.

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

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

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

gegenseitigen Abhängigkeit der Aktivitäten und der damit verbundene verbleibende

Aufwand erst nach ca. 64 Wochen erreicht.

Der Verlauf des Arbeitsaufwands stellt bei der Oszillation für Aufgabe 2 ab Woche 15

natürlich keinen realistischen Verlauf dar, da der verbleibende Aufwand 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, indem eine Zufallsvariable t in

die Zustandsgleichung des Projekts eingefügt wird. Hierdurch werden zeitliche

Fluktuationen des Fortschritts von Aktivitäten im Laufe der Projektdurchführung

abgebildet. Es wird angenommen, dass die Störungen additiv wirken und somit

(multi-)normalverteilt sind. Die Störungen sind jedoch auf lange Sicht

„unsystematisch“ und haben daher für jede Aufgabe im statistischen Mittel den Wert

0. Die Standardabweichungen σ der Zufallswerte für Aufgabe i werden in der

Hauptdiagonalen σii der sog. Kovarianzmatrix C angegeben.

Die Abbildung stellt die Arbeitsaufwände für zwei Aufgaben eines realen

Produktentwicklungsprojekts über einem Zeitraum von 50 Wochen dar. Die

Projektdaten wurden in einem mittelständischen Unternehmen der

elektrotechnischen Industrie erhoben (siehe Folie 7-4). Der reale Projektverlauf und

der auf Basis der stochastischen, erweiterten WTM basierende simulierte

Projektverlauf werden einander gegenüber gestellt. Mit Hilfe einer Monte-Carlo-

Simulation wurden 100 unabhängige Simulationsläufe durchgeführt. Der dabei der

Simulation zugrundeliegende Fehler (Standardabweichung) wird durch 95%

Konfidenzintervalle angezeigt.

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

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

dieser Methodik verdeutlicht wird.

Die Parameter A0 und C wurden auf Basis des Maximum-Likelihood-Prinzips mit Hilfe

der Verfahren von Neumair & Schneider (2001) geschätzt. Dabei werden die

erforderlichen Parameter eines Modells schrittweise nach dem Prinzip der kleinsten

Quadrate berechnet.

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.