Download - Fakultät 06 - Hochschule München

Erstellung eines Konzepts zur Verminderung von Problemen beim
Informationsaustausch in der Produktentwicklung nach Lean Engineering
Prinzipien
Bachelorarbeit
von
FRAYSSINET Dorian
Hochschule München
Fakultät Feinwerk- und Mikrotechnik, Physikalische Technik
Studiengang Deutsch-Französischer Bachelor- / Masterstudiengang
Produktion und Automatisierung (B.Eng. / M.Eng.)
Referent: Prof. Dr.-Ing. A. Schlueter
Korreferent: Prof. Dr.-Ing. S. Linner
Betreuer: Dipl.-Ing. C.Tristl, EADS Cassidian Manching
München 2012

Vorwort
Die vorliegende Bachelorarbeit entstand im Zeitraum von September bis Dezember 2012
in der Firma EADS Cassidian in Manching. Das Thema dieser Arbeit befasst sich mit der
Erstellung eines Konzeptes zur Verminderung von Problemen beim Informationsaustausch
in der Produktentwicklung.
Ich danke Herrn Dipl.-Ing. Deppe für die Möglichkeit, relevante Abteilungen zu besichtigen.
Ich danke Herrn Nuscheler für die Möglichkeit, meine Bachelorarbeit in optimalen
Bedingungen in seiner Abteilung bei CASSIDIAN zu verfassen. Mein ganz spezieller
Dank gilt dabei Herrn Dipl.-Ing. Tristl, der mich als Betreuer bei der Verfassung meiner
Bachelorarbeit und das Lernen der theoretischen Grundlagen unterstützt.
Mein Dank gilt auch für Herrn Prof. Dr.-Ing. Schlueter und Herrn Prof. Dr. Linner für die
wissenschaftliche Betreuung dieser Arbeit.
Am 11. Dezember 2012 Dorian Frayssinet

Abkürzungen:
EDV: Elektronische Datenverarbeitung
IT: Informationstechnik = EDV
LSE: Lean Systems Engineering
M-/E-Eng.: Mechanical-/ Elektronical Engineering
PD: „Product Development“ d.h. Produktentwicklung
S.E: Simultaneous Engineering (Concurrent Engineering wird als Teil des S.E gesehen)
SE: Systems Engineering
Waste: „Waste“ wird für die Verschwendungen nach Lean Manufacturing benutzt.

Inhalt
1 EINLEITUNG .................................................................................................... 8
1.1 Problemstellung .......................................................................................................... 8
1.2 Zielsetzung ................................................................................................................... 8
1.3 Vorstellung der Firma ................................................................................................ 9
1.4 Vorgehen / Aufbau der Arbeit ................................................................................. 10
2 THEORETISCHE GRUNDLAGEN ................................................................. 11
2.1 Flugzeugentwicklungsprozesse ................................................................................ 11
2.1.1 System Denken .................................................................................................... 11
2.1.2 Systems Engineering als Entwicklungsvorgehen ................................................ 15
2.1.2.1 Geschichte .................................................................................................... 15
2.1.2.2 Definition von Systems Engineering ............................................................ 15
2.1.3 Einsatz des V-Modells im Produktentstehungsprozess ....................................... 17
2.2 Lean Engineering ...................................................................................................... 18
2.2.1 Geschichte ........................................................................................................... 18
2.2.2 Die fünf Lean Prinzipien: .................................................................................... 19
2.2.2.1 Kundenwert .................................................................................................. 19
2.2.2.2 Identifizierung des Wertschöpfungsstroms .................................................. 20
2.2.2.3 Flussprinzip .................................................................................................. 21
2.2.2.4 Pull-Prinzip ................................................................................................... 22
2.2.2.5 Das Streben nach Perfektion ......................................................................... 22
2.2.3 Lean Systems Engineering .................................................................................. 22
2.2.4 Six Sigma Methode ............................................................................................. 23
2.2.4.1 Geschichte .................................................................................................... 23
2.2.4.2 DMAIC ......................................................................................................... 23
2.2.5 Simultaneous Engineering ................................................................................... 25
2.2.5.1 Definition ...................................................................................................... 25
2.2.5.2 Problemen/ Risiken ....................................................................................... 26
3 DIE ROLLE DER INFORMATION IN DER PRODUKTENTWICKLUNG ..... 28
3.1 Definition ................................................................................................................... 29
3.2 Typ von Informationen ............................................................................................ 30
3.3 Welche Probleme gibt es beim Informationsaustausch heute? ............................ 30
4 WASTE IN DER PRODUKTENTWICKLUNG ................................................ 32
4.1 Grundlagen ................................................................................................................ 32
4.2 Zehn wastes ................................................................................................................ 34

Verzeichnisse 5
4.2.1 Transport (Störung im Informationstransfer) ...................................................... 34
4.2.2 Bestände ............................................................................................................... 34
4.2.3 Bewegung (Motion) ............................................................................................. 35
4.2.4 Warten ................................................................................................................. 35
4.2.5 Überproduktion .................................................................................................... 35
4.2.6 Overprocessing .................................................................................................... 36
4.2.7 Fehler in Form von Rework ................................................................................. 36
4.2.8 Kommunikationsprobleme von Informationen ................................................... 36
4.2.9 Schlechte Informationsqualität ............................................................................ 37
4.2.10 Mangelnde EDV-Werkzeuge / -Systeme ............................................................ 37
5 KONZEPT ........................................................................................................ 38
5.1 Anforderungen an das Konzept .............................................................................. 38
5.2 Lean Engineering Methode nach DMAIC ............................................................. 39
5.3 Identifizierung des Problemkontexts und Ziele (Define) ...................................... 39
5.4 Methode für die Informationsbeschaffung (Measure) .......................................... 40
5.4.1 Qualitative oder Quantitative Methoden ............................................................. 40
5.4.2 Fragebogen .......................................................................................................... 41
5.4.3 Interview .............................................................................................................. 43
5.5 Ursachen als Identifizierungskriterien der Wastetyps (Analyse) ........................ 44
5.6 Statistische Auswertung (Analyse) .......................................................................... 45
5.7 Value method und lean enablers .............................................................................. 46
5.8 Parametern (Control) ............................................................................................... 48
5.9 Gesamt Konzept ........................................................................................................ 49
6 ANWENDUNG DES KONZEPTS AUF EINE FALLSTUDIE ........................... 52
6.1 Durchführung der Interview und Analyse der Ist-Situation ................................ 52
6.2 Prototypische Anwendung des Konzepts an Hand des Waste "waiting" ........... 53
6.3 Parameter als Kontrollmittel der ermittelten Verbesserungsaktionen ............... 57
6.4 Interpretation der Ergebnisse ................................................................................. 57
7 ZUSAMMENFASSUNG ................................................................................... 58
8 LITERATURVERZEICHNIS ........................................................................... 59
9 ANHANG ......................................................................................................... 64
9.1 Zusammenfassung der Verschwendungen nach der Literatur (Bauch, 2004) ... 64

9.2 Qualitative vs. quantitative Methode ( Miles und Huberman) ............................ 65
9.3 Beziehung zwischen Fragen und wastetypen ......................................................... 66
9.4 Fragebogen ................................................................................................................ 67
9.5 Statistische Auswertung ........................................................................................... 74
9.6 Auswirkungen von Value Methoden auf wastetyp ................................................ 75
9.7 Analyse der Verbesserung nach Variation der Parametern ................................ 76
9.8 Gesamt Konzept ........................................................................................................ 77

Wissenschaftliche Bachelorarbeit 7
Abbildungsverzeichnis
Abbildung 1: Geschäftsbereich von EADS ........................................................................... 9
Abbildung 2: System Denken .............................................................................................. 11
Abbildung 3: Flugzeug System nach Acquipedia (2008) .................................................... 12
Abbildung 4: Die vier Flugzeug Subsystems ...................................................................... 12
Abbildung 5: Anfang des Produktlebenszyklus eines Flugzeugs ........................................ 14
Abbildung 6: Verwendungsbereich des Systems Engineering nach Kossialkoff (2011) .... 16
Abbildung 7: System und Engineering nach Kossialkoff (2011) ........................................ 16
Abbildung 8: Das V-Modell in Anlehnung an Partsch (1998) ............................................ 17
Abbildung 9: Das V-Modell in die Phasen des Produktlebenszyklus ( ISO/IEC 19760) ... 18
Abbildung 10: Lean Produktion und Lean in der Produktentwicklung (Garza L., 1992) ... 19
Abbildung 11: Zeitaufwand in der Produktentwicklung (Oehmen 2010) ........................... 21
Abbildung 12: DMAIC (Paul Bayer, 2008) ........................................................................ 23
Abbildung 13: Simultaneous gegen Sequentiel (Ernst, 2003) ............................................. 25
Abbildung 14: Das magische Dreieck (Ernst, 2003) ........................................................... 26
Abbildung 15: Informationsaustausch up-/ downstream (Thomson, 2010) ........................ 27
Abbildung 16: Phasemodelle (Suss, 2010) .......................................................................... 28
Abbildung 17: Von Daten bis Information (Graebsch, 2005) ............................................. 29
Abbildung 18: Type von Informationen (Graebsch, 2005) ................................................. 30
Abbildung 19: Lean Manufacturing und Lean Engineering (Oppenheim, 2010) ............... 33
Abbildung 20: Zusammenfassung der wastes (Anhang 9.1) nach Bauch (2004) .............. 33
Abbildung 21: Konzeptdarstellung ...................................................................................... 39
Abbildung 22: Qualitative vs. Quantitative Methoden nach Miles (1994) ......................... 41
Abbildung 23: Geschlossene und offene Fragen ( Wacker, 1999) ...................................... 43
Abbildung 24: Von Ursachen nach Wastetyp (nach Bauch) ............................................... 44
Abbildung 25: Beziehungen zwischen Fragen und Wastetypen (Anhang 9.3) ................... 45
Abbildung 26: Statistische Auswertung (Anhang 9.5) ........................................................ 46
Abbildung 27: Auswirkungen von Value Methoden auf wastetyp (Anhang 9.6) ............... 46
Abbildung 28: Value stream enablers INCOSE (2010) ...................................................... 47
Abbildung 29: Simultaneous engineering enablers Laura A. Garza (1992) ........................ 48
Abbildung 30: Parameter in der Produktentwicklungsprozess nach Chase (2000) ............. 48
Abbildung 31: Analyse der Verbesserung nach Variation der Parametern (Anhang 9.7) .. 49
Abbildung 32: Gesamt Konzept (Anhang 9.8) in Anlehnung an Bauch (2004) ................. 51
Abbildung 33: Beziehung Frage zu Waste (erste Auswertung) .......................................... 52
Abbildung 34: Beziehung Frage zu Waste (zweite Auswertung) ....................................... 52
Abbildung 36: Parameter und Value Methode in Abhängigkeit der Wastetypen ............... 54
Abbildung 37: Verbesserungskonzept ................................................................................. 55

1 EINLEITUNG
1.1 Problemstellung
Die aktuelle herrschende Konkurrenz zwingt Unternehmen, sich von den Anderen
abzuheben. Nach dem magischen Dreieck sind Qualität, Kosten und Zeit, die drei wesentlichen
Elemente aus der Sicht der Kunden. Termintreue spielt dabei eine Hauptrolle in der
Kundenzufriedenheit. Wenn ein Unternehmen die Fähigkeit gewinnt, die Erwartungen der
Kunden im gewünschten Zeitraum zu erfüllen, erlangt dieses einen großen Vorsprung. Die
Dauer des Produktentwicklungsprozesses hat eine sehr große Wirkung auf die Termintreue.
Aus diesem Grund hat sich seit mehreren Jahren die Methode von Simultaneous Engineering
entwickelt. Sie besteht darin, die unterschiedlichen Entwicklungsabteilungen
innerhalb eines Produktentwicklungsprozesses zu parallelisieren, um die Entwicklungszeiten
zu verkürzen. Diese Methode hat allerdings Nachteile mit sich gebracht. Mit der Anwendung
von Simultaneous Engineering, steigt die Anzahl der Schnittstellen und des interdisziplinarischen
Kommunikationsbedarfes. Deshalb ist ein Informationsmanagementprozess
nötig. Viele Informationen müssen zwischen den Disziplinen des Prozesses ausgetauscht
werden. Auf der anderen Seite, verursacht dieser Probleme, wie z.B. Iterationen,
die Zeit kosten und Risiken ins Leben rufen können. In der Luftfahrtentwicklung, haben
die Entwicklungsphasen verhältnismäßig lange Produktlebenszyklen (30+ Jahren). Aus
diesem Grund ist es wichtig, besonders in der Luftfahrtentwicklung, auf die Informationsaustauschproblematik
zu achten.
1.2 Zielsetzung
Die Prozessoptimierung ist eine bedeutende Herausforderung um den Erfolg eines
Unternehmens zu garantieren. Für eine effiziente Entwicklung hat sich die Lean Philosophie
von Toyota (Womack and Jones, 1996, p.15) nicht nur im Manufacturing, sondern
auch in der Produktentwicklung durchgesetzt. Hierbei wird nicht mehr von Materialen,
sondern auch von Informationen gesprochen. Obwohl es Unterschiede zwischen Lean Manufacturing
und Lean Engineering gibt, haben beide Ansätze eine ähnliche Vorgehensweise
und Ziele. Die wertschöpfenden Prozesse und Tätigkeiten werden identifiziert und als
Value (Wert) benannt. Die Probleme hingegen werden als Waste (Verschwendung) identifiziert
und sollten vermindert oder am besten beseitigt werden. Luftfahrzeugprodukte sind
komplexe Systeme, die eine adäquate Struktur und Organisation in der Produktentwicklung
brauchen. Aus diesem Grund hat sich das Vorgehen des Systems Engineering entwickelt.
Diese Kombination zwischen Lean Engineering und Systems Engineering zum Lean
System Engineering ist ein aktuelles Thema in der Wissenschaft und Praxis.
Die Zielsetzung dieser Bachelorarbeit ist die Erstellung eines Konzeptes zur Verminderung
der Probleme beim Informationsaustausch zwischen zwei parallel arbeitende
Disziplinen: Systems Engineering (SE) und Mechanikal-/ Elektronikal Engineering (M-/
E-Eng.). Dieses Ziel kann wie folgt zusammengefasst werden:
Analyse von Problemen beim Informationsaustausch zwischen SE und M-/ E-Eng.
zum Zwecke einer Prozessverbesserung in der verteilten parallelen Entwicklung
mit Bezug auf Lean Engineering Methoden
im Rahmen von Informationsaustausch in komplexen Flugzeugentwicklungsprozessen.

Wissenschaftliche Bachelorarbeit 9
1.3 Vorstellung der Firma
„Die European Aeronautic Defence and Space Company (EADS) ist Europas größter Luft-
und Raumfahrt- sowie zweitgrößter Rüstungskonzern. Mit einem Umsatz von 45,75 Milliarden
Euro (Stand: 2010) ist EADS nach Boeing auch das zweitgrößte Luft- und Raumfahrtunternehmen
der Welt. Cassidian ist ein weltweit führender Anbieter von globalen
Sicherheitslösungen und -systemen und bietet Lead Systems-Integrationen sowie mehrwertorientierte
Produkte und Dienstleistungen für Zivil- und Militärkunden auf der ganzen
Welt. EADS ist in vier Geschäftsbereiche verteilt: Airbus, Eurocopter, Cassidian und Astrium“.
(Wikipedia-Q1) (Siehe Bild Abbildung 1)
Abbildung 1: Geschäftsbereich von EADS
„Cassidian tritt für die Sicherheit auf der Welt ein, wie z.B. Sicherheit bei Großveranstaltungen,
Informationssicherheit, Sicherheit kritischer Infrastrukturen und Naturgüter sowie
Grenzsicherheit. 2011 verstärkte das Unternehmen die Bemühungen zur Erhöhung seiner
Präsenz auf außereuropäischen Märkten und arbeitete weiter an der Entwicklung von Produkten
der nächsten Generation. Mittelfristig geht Cassidian davon aus, dass sich mehr als
50 % der gesamten Geschäftstätigkeit außerhalb der traditionellen Stammländer abspielen
wird. Langfristig möchte das Unternehmen den Anteil der Sicherheitslösungen am Umsatz
auf 50 % im Vergleich zu 22 % im Jahr 2010 steigern“. (Homepage)
„In ihrer Ausrichtung zählt die Business Unit Cassidian Air Systems (früher: Military
Air Systems, Geschäftsbereich Militärflugzeuge), die Anteile am Eurofighter-
Programm ebenso dazu wie das Angebot von Verteidigungselektronik und Sicherheits-
Kommunikationssystemen für zivile und militärische Anwendungsbereiche. Der Geschäftsbereich
Dienstleistungen (Business Unit Services) bedient die Nachfrage nach ausgelagerten
Dienstleistungsaufgaben für Militär- und Sicherheitsbereiche. Cassidian erwirtschaftete
2011 mit 20.923 Mitarbeitern einen Umsatz von 5,803 Milliarden Euro (Ebit-
Marge 5,7 %)“. (Quelle: Handelsblatt vom 31. Mai 2012) ( Wikipedia-Q1).

1.4 Vorgehen / Aufbau der Arbeit
Für die Bearbeitung der vorliegenden Bachelorarbeit „Verminderung von Problemen
beim Informationsaustausch zwischen Systems Engineering und Mechanical-/ Elektronical
Engineering. Disziplinen“ wurde als erstes ein theoretischer Rahmen gesetzt, gefolgt
von einem praktischen Teil. Diese Bachelorarbeit ist insgesamt in sieben Hauptkapitel
untergegliedert. Im ersten Kapitel soll an das Thema dieser wissenschaftlichen Arbeit
herangeführt, die Problemstellung und die Zielsetzung aufgezeigt, die Firma vorgestellt
sowie der Aufbau der Arbeit dargestellt werden. Im zweiten Kapitel folgen alle relevanten
theoretischen Grundlagen, die für das Verständnis dieser Bachelorarbeit erforderlich sind.
Themen wie Systems Engineering, Simultaneous Engineering, usw. werden detailliert erklärt.
Das dritte Kapitel beinhaltet die Rolle der Information in der Produktentwicklung.
Insgesamt gibt es strukturierte, halbstrukturierte und nicht strukturierte Informationen. Hier
stellt sich die Frage, wie die Unterschiede zwischen diesen drei Punkten verstanden werden.
Anschließend werden unterschiedliche Probleme in Beziehung mit der Information in
der Produktentwicklung erläutert. Im vierten Kapitel wird geklärt, was unter dem Begriff
“waste in der Produktentwicklung” verstanden werden kann. An dieser Stelle werden die
Grundlagen von waste (Verschwendung) im Lean Engineering nahegelegt. Ferner wird auf
die zehn waste im Rahmen von diesem Konzept eingegangen. Das fünfte Kapitel beinhaltet
eine genauere Beschreibung des Konzeptes. Es werden hierfür, die wesentlichsten
Schritte des Konzeptes zum Thema Probleme von Informationsaustausch und deren Verminderung
beleuchtet. Im sechsten Kapitel folgt die Anwendung des Konzepts. Als erstes
wird auf die methodische Vorgehensweise eingegangen. Im Rahmen der empirischen Untersuchung
wurden Experten oder Konstrukteure interviewt. Ziel der Interviews war es,
professionelle Meinungen zum Thema dieser Bachelorarbeit einzuholen. Diese Experteninterviews
wurden ausgewertet und in Bezug auf die Theorie und die Praxis dieser wissenschaftlichen
Arbeit dargestellt. Abschließend werden in diesem Kapitel die Verbesserungsschritte
nach der statistischen Auswertung detailliert und eine Interpretation der Ergebnisse
gegeben. Das siebte Kapitel bildet den inhaltlichen Abschluss dieser Bachelorarbeit. Zum
Schluss folgt ein Quellen- und Anhangsverzeichnis.

Wissenschaftliche Bachelorarbeit 11
2 THEORETISCHE GRUNDLAGEN
In diesem theoretischen Teil werden die wichtigen Grundlagen zum Verständnis des
dargestellten Konzeptes vorgestellt.
2.1 Flugzeugentwicklungsprozesse
2.1.1 System Denken
Systeme sind dynamische Gesamtheiten. Sie bestehen aus Teilen, die miteinander
verknüpft sind und aufeinander wirken (Roland Seidel, 2001) (siehe Bild 2). Ein System
ermöglicht es, eine Antwort zu einem komplexen Problem zu finden. Dafür müssen zuerst
die Bedürfnisse, Absichten und Ziele des Systems vom Kunden klar definiert werden, die
dem Lieferant dem Anfangs-Punkt des Designprozesses geben. Dadurch, dass die Elemente
verschiedene und komplizierte Beziehungen miteinander haben, ist die Begriffserklärung
von „System“ eingeschränkt. Ein simples Hausgerät, wie z.B. eine Waschmaschine,
kann nicht als kompliziert genug betrachtet werden, um Systems Engineering anwenden zu
können (Kossialkoff, 2011). Ein System ist viel mehr als eine Ansammlung von Hardware
und Software und muss in Bezug auf solche Ressourcen wie Personal, Materialien, Möglichkeiten
und Daten beschrieben werden (MIT Vorlesung, 2007). Eine wichtige Eigenschaft
von Systemen besteht darin, dass sie in Subsystemen fast unbestimmt geteilt werden
können.
Abbildung 2: System Denken
Diese Hierarchie von Systemen, in denen die Systeme auf höchster Ebene wichtig
sind und einen Einfluss auf Systemen der niedrigeren Ebene haben, ist die Weise, auf die
die meisten komplizierten Systeme analysiert werden. So sind z.B. die elementaren Bausteine
für Flugzeugsysteme, die Bestandteile (Pumpen, Klappen, Sensoren, Effektoren,
usw.). Die Entscheidung, wie weit man ein System in Subsysteme zerlegt, hängt von der
Komplexheit des Systems und der Fähigkeit ab, die Funktionen und Schnittstellen als Gan-

zes anzusehen. Das oben beschriebene System-Konzept, kann in der Flugzeugssystemtechnik
verwendet werden (siehe Abb. 3) (Ian Moir, 2004).
Unterschiedliche Flugzeugsysteme
Abbildung 3: Flugzeug System nach Acquipedia (2008)
Ein Flugzeugsystem kann in vier unterschiedliche Subsystemen geteilt werden:
Flugzellen / Struktur
Flugzeug
Zelle / Struktur Fahrzeug System Avionik System Einsatz System
Der Hauptstrukturaspekt
des Flugzeuges:
Rumpf
Flügel
Leitwerk
Aerodynamik
Die Systeme, die dem
Flugzeug ermöglicht
fortzusetzen, sicher überall
in der Mission zu fliegen:
Antrieb
Flugsteuerungen
Hydraulik
Die Systeme, die dem
Flugzeug ermöglicht, seine
betriebliche Rolle zu
erfüllen:
Navigation
Steuerungen & Anzeigen
Kommunikationen
Abbildung 4: Die vier Flugzeug Subsystems
Die Systeme, die dem
Flugzeug ermöglicht, eine
militärische Rolle zu
erfüllen:
Sensoren
Missionscomputerwissen
schaft
Waffen
Die mechanische Struktur eines Flugzeuges nennt sich das Airframe System. Airframe
Systeme können als ein System angesehen werden, da es ein komplexer und integrierter
Satz von Strukturbestandteilen ist, der die Masse von Systemen und Passagieren
unterstützt und zudem Lasten überall in der Struktur erträgt (Ian Moir, 2004).

Wissenschaftliche Bachelorarbeit 13
Flugzeugsysteme
Sie sind eine Mischung von Systemen mit verschiedenen Eigenschaften. Einige
sind schnelllaufende und geschlossene Regelkreise, weitere sind Echtzeitdatenerfassungen
und einige haben Prozesssteuerungsfunktionen wie das Kraftstoffsystem. Was sie gemeinsam
haben ist, dass sie alle die Flugsicherheit betreffen. Denn wenn ein Fehler bei diesen
Systemen auftritt, können das Flugzeug, die Mannschaft oder die Passagiere gefährdet
werden (Ian Moir, 2004).
Beispiel:
Avionik-Systeme
• Kraftstoffsystem
• Antrieb-System
• Das Flugauftanken
• Mannschaft-Flucht
„Avionik-Systeme bezeichnen die Gesamtheit der elektrischen und elektronischen
Geräte an Bord eines Fluggerätes, einschließlich der Fluginstrumente. Ausgenommen hiervon
sind im Sprachgebrauch allerdings Elektronikanwendungen in den Kabinensystemen“
(Wikipedia-Q2).
Mission-Systeme
• Automatisiertes Landesystem
• Wetterradar
• Cockpitstimmenrecorder
• Entfernungs-Messeausrüstung
Militärische Flugzeuge brauchen eine Reihe von Sensoren und Rechner, um bestimmte
Missionen verfolgen zu können (Ian Moir, 2004). Missions-Systeme sind hoch
automatisierte Systeme, die dazu fähig sind eine schnelle Reaktionsantwort auf Drohungen
aus der Luft oder vom Boden zu liefern (Thalesgroup).
Beispiel:
• Angriff oder Kontrolle-Radar
• Waffensysteme
• Elektronischer Kriegssysteme

Entwicklungsphase, unseres Untersuchungsfokus
Konzeptphase
Definitionsphase
Entwicklungsphase
Abbildung 5: Anfang des Produktlebenszyklus eines Flugzeugs
Es ist äußerst wichtig nah mit allen Interessensvertretern während dieser Phase zu
arbeiten. Dadurch können große Veränderungen am Design verhindert werden. Wenn das
Design feststeht, werden die Durchführbarkeit des Zusammenbaus und die funktionellen
Aspekte des Systems, mit Hilfe eines Prototypen geprüft. Sobald das Design vereinbart ist,
findet eine Überprüfungs- und Gültigkeitserklärungsprüfung statt, um zu bestätigen, dass
dies den Spezifizierungen und Ziele des Flugzeuges entsprechen. Wenn ein Test scheitert
oder Ziele nicht erfüllt werden, finden Wiederholungen statt. Diese können allerdings mehrere
Subsysteme betreffen. Wiederholungen können Risiken schaffen und schließlich ein
optimales Design gefährden. Der Überprüfungsprozess hat Beziehungen zu Qualitätsdisziplinen,
um Daten zu sammeln, Zuverlässigkeit zu prüfen und Robustheit zu demonstrieren.
Im Allgemeinen ist die Definitionsphase die primäre Phase. Diese verbindet die Interessen
aller Entwicklungsgruppen und dessen Schnittstellen. Dem Kunden wird für gewöhnlich
die ganze Information konsolidiert, die während der Konzeptphase gesammelt
wurde (siehe Abb. 5), um seinen Anforderungen nachzukommen. Typische Vorgehensweisen
sind:
• Entwicklung des Konzepts mit Hilfe einer festen Definition der Lösung
• Entwicklung der Systemarchitekturen und Anlagenkonfigurationen
• Quantitätsbestimmung von Schlüsselsystemleistungsmaßnahmen wie:
- Masse
- Volumen
- Reihe / Ausdauer
• Gefahr identifizieren und Milderungspläne einführen
• Die Auswahl und Bestätigung der passenden Technologien
Der output dieser Phase findet sich für gewöhnlich in Berichten von Durchführungsbarkeitsstudien,
Leistungsschätzungen oder in betrieblichen Leistungsmodellen wieder.
Wenn das Ergebnis der Konzeptphase erfolgreich ist und das Unternehmen eine Ent-

Wissenschaftliche Bachelorarbeit 15
scheidung getroffen hat, kommt sie zur nächsten Etappe, der Designphase. Diese übernimmt
die Architektur und Schemen des entwickelten Produktes (Ian Moir, 2004).
2.1.2 Systems Engineering als Entwicklungsvorgehen
2.1.2.1 Geschichte
Die Grundsätze von Systems Engineering werden seit dem Bau der Pyramiden und
wahrscheinlich schon weitaus früher genutzt. Die Anerkennung von Systems Engineering
als eine anwendbare Methode wird durch die Auswirkungen des zweiten Weltkrieges und
besonders in den 1950er und 60er deutlich, als das Thema in mehreren Lehrbüchern auftaucht.
Die zweite Weltkrieg bewirkte einen enormen Ansporn, die Technologie zu fördern
um einen militärischen Vorteil zu gewinnen. Die Entwicklung des Kampfflugzeuges, des
militärischen Radars und besonders der Atombombe verlangte eine Revolution in der Anwendung
von Energien, Materialien und Information. Außerdem erforderte die komprimierte
Entwicklungszeit während des Weltkrieges, ein hohes Niveau an Organisation und
Leistungsfähigkeit. Diese wiederum verlangte ein hohes Maß an Technikmanagement,
technischen Koordination und Programmplanung. Jedoch hat eine andere Entwicklung
vielleicht eine größere Auswirkung auf den technologischen Fortschritt gehabt, diese der
Halbleiterbauteile. Diese haben die Entwicklung des "Informationszeitalters" ermöglicht,
indem Netze die Reichweite der Systeme weit über ihre vorherigen Grenzen übertrafen.
Dieser Erfolg lies die Entwicklung des Digitalcomputers und der integrierten Softwaretechnologien
zu, die zunehmend zum Ersatz der menschlichen Kontrolle von Systemen
führte. Die damit verbundene Computerkontrolle vergrößert die Kompliziertheit von Systemen
und ist daher ein wichtiges Thema im Systems Engineering. (Kossialkoff, 2011,
S.5/6).
2.1.2.2 Definition von Systems Engineering
Folgende Definition wurde von der NASA zusammengefasst. SE ist "Eine zwischendisziplinarische
zusammenarbeitende Annäherung, um ein Lebenszyklus Systemlösung
zu entwickeln und nachzuprüfen, so dass die Kundenerwartungen befriedigt und öffentliche
Annehmbarkeit entspricht" (Sextone. 1998).
SE konzentriert sich darauf Kundenbedürfnisse zu definieren und verlangt Funktionalität
früh im Entwicklungszyklus einzuplanen. Die daraus dokumentierten Vorgänge
müssen mit der Designsynthese und der Systemgültigkeitserklärung anschließend verbunden
werden. Während des SE wird der Prozess vielseitig abgedeckt und nimmt Operationen,
Leistung, Test, Herstellung, Kosten, Ausbildung, Unterstützung und Verfügung wahr.
SE integriert alle Disziplinen und Spezialisierungsgruppen, die gemeinsam einen strukturierten
Entwicklungsprozess bilden (INCOSE, 2004).

SE ermöglicht das System von außen zu betrachten (Forschung der Wechselwirkungen
des Systems auf andere und Umgebung) (Kossialkoff, 2011).
Abbildung 6: Verwendungsbereich des Systems Engineering nach Kossialkoff (2011)
Systems Engineering überbrückt die traditionellen Technikdisziplinen (siehe Abb.
6). Die Ungleichheit der Elemente in einem komplexen System verlangt, dass verschiedene
Technikdisziplinen an ihrem Design und ihrer Entwicklung beteiligt werden. In einem System
muss jedes Element mit den anderen Systemelementen in der richtigen Kombination
physisch und funktionell fungieren. So können die verschiedenen Elemente nicht unabhängig
voneinander konstruiert werden, um ein Arbeitssystem zu erzeugen (Kossialkoff,
2011). Eine kurze Zusammenfassung der System Philosophie und des SE-Vorgehens finden
Sie in Abb. 7.
Abbildung 7: System und Engineering nach Kossialkoff (2011)

Wissenschaftliche Bachelorarbeit 17
2.1.3 Einsatz des V-Modells im Produktentstehungsprozess
Das V-Modell ist ein Vorgehensmodell zur Durchführung und Planung von Projekten.
Durch die Vorgabe konkreter, standardisierter Vorgehensweisen, zugehöriger Ergebnisse
und verantwortlichen Rollen erhöht das V-Modell die Projekttransparenz, verbessert
das Management von Projekten und erhöht nachhaltig die Erfolgswahrscheinlichkeit (Küfer,
2004). Daher ist dieses Modell für Systems Engineering anwendbar.
„Das V-Modell ist als Leitfaden zum Planen und Durchführen von Entwicklungsprojekten
unter Berücksichtigung des gesamten Systemlebenszyklus konzipiert. Dabei definiert
es die in einem Projekt zu erstellenden Ergebnisse und beschreibt die konkreten
Vorgehensweisen, mit denen diese Ergebnisse erarbeitet werden. Darüber hinaus legt das
V-Modell die Verantwortlichkeiten jedes Projektbeteiligten fest. Die standardisierten methodischen
Vorgaben des V-Modells ermöglichen, auch komplexe und umfangreiche Projekte
systematisch durchzuführen. Dadurch werden Projekte besser plan- und nachvollziehbar
und erzielen zuverlässiger Ergebnisse von hoher Qualität, was sowohl für den Auftraggeber
als auch für die Auftragnehmer von Vorteil ist. Die Vorgaben des V-Modells
bilden daher eine wesentliche Grundlage für die Verträge zwischen Auftraggebern und
Auftragnehmern. Das V-Modell dient somit als Vertragsgrundlage, Arbeitsanleitung und
Kommunikationsbasis“ (Bundesrepublik Deutschland, 2004). Das Modell kann negative
Auswirkungen, wie z.B. unnötige Produktvielfalt und Bürokratie, sowie unrealistische Rollendefinition
für kleine Projekte haben (Naraku, 2012).
Entwicklungsphase Integrationsphase
Abbildung 8: Das V-Modell in Anlehnung an Partsch (1998)
Die "V’s" stehen für eine Folge von Schritten in einer Projektlebenszyklus-
Entwicklung. Das Modell beschreibt die Tätigkeiten, die durchzuführen sind und die Ergebnisse,
die während der Produktentwicklung erzeugt werden müssen. In der Entwicklungsphase
werden die Voraussetzungen analysiert und das Pflichtenheft erstellt. In der
Integrationsphase werden die Teile zusammengeführt und auf Gültigkeit überprüft. (Wikipedia)
(Siehe Abb. 8). In jeder Phase des Produktlebenzyklus kann man ein V-Modell
anwenden (zum Beispiel in der Entwicklungsphase (siehe Abb. 9).

Abbildung 9: Das V-Modell in die Phasen des Produktlebenszyklus ( ISO/IEC 19760)
2.2 Lean Engineering
2.2.1 Geschichte
Lean Manufacturing wurde zuerst von Toyota durchgeführt, daher der Name
"Toyota Production System" (TPS). TPS war ein Methode, die sich bemühte Verschwendungen
zu beseitigen um nur das zu erzeugen, was der Kunde will. Das Internationale
Kraftfahrzeug-Programm (IMVP) rief das Konzept der Lean Production ins Leben, das
eine radikale Veränderung für die Massenproduktion werden sollte (Womack und J.,
1990). Lean Manufacturing hingegen überschreitet den physischen Fabrikraum. Vieles im
Lean Manufacturing hängt von einem Informationsfluss zwischen dem Hersteller, dem
Kunden und dem Lieferanten ab. Je sichtbarer dieser Informationsfluss ist, desto mehr produziert
der Hersteller was der Kunde wirklich will (Womack und J., 1990).
Allerdings bewegt sich die Lean-Philosophie außerhalb der Grenzen des Manufacturing
(siehe Abb. 10). In der Vergangenheit hatten die Unternehmen mit der Einführung
des Lean-Verfahrens nicht nur Erfolg in der Produktion sondern auch in Gebieten wie Prozesse
und Anlieferung gefunden. Die Vorteile, dem Lean-Prinzip nachzukommen, wurden
sofort anerkannt. Heute gibt es keine Bereiche einer Gesellschaft, in denen der Lean-
Grundsatz in der Praxis nicht umgesetzt werden kann, da Lean keine sichtbaren Grenzen
zeichnet. Lean-Unternehmen "geben [den] Wert für den Kunden an [...]. Dann identifizieren
Sie alle Aktionen die erforderlich sind, um das Produkt vom Konzept bis zum Start zu
bringen. Anschließend entfernen Sie beliebige Aktionen, die keinen Wert schaffen.
Schließlich analysiert das Unternehmen die Ergebnisse und erneuert immer wieder den
Auswertungsprozess" (Womack und J., 1996). Diese Definition verbindet grundsätzlich
die fünf Lean-Prinzipien und ist für alle Unternehmen während ihrer Wertstromanalyse
gültig. Die Lean Aerospace Initiative (LAI) an MIT (Massachusetts Institute of Technology)
hat sich auf das Gutachten von Womack und Jones, namens "Lean Thinking" gestützt.
Sie wiederdefiniert wie ein Lean-Unternehmen aufgebaut ist: "Ein Lean-Unternehmen ist
eine Einheit, die effizient Wert für ihre vielfachen Interessenvertreter schafft, durch die
Implementierung von Lean-Prinzipien und Methoden" (Murman, 2002). Diese Interessenvertreter
müssen alle zusammenarbeiten, um Informationen, Teile und Erfahrungen miteinander
auszutauschen. Der Begriff „Wert“ in der Produktentwicklung ist nach Womack

Wissenschaftliche Bachelorarbeit 19
und J. (1996) so definiert: „A capability provided to a customer at the right time at an appropriate
price, as defined in each case by the customer“.
Abbildung 10: Lean Produktion und Lean in der Produktentwicklung (Garza L., 1992)
2.2.2 Die fünf Lean Prinzipien:
2.2.2.1 Kundenwert
Die genaue Identifikation des Wertes aus Kundensicht ist der erste wichtige Schritt.
Der erste Schritt in der Lean-Philosophie beginnt mit einer gründlichen Analyse und einem
ausführlichen Gespräch mit dem Kunden. Das Analysieren des Wertes in der Produktentwicklung
stellt die Nachforschung nach den Erwartungen des Programms und den technische
Herausforderungen dar. Entscheidungen können nicht getroffen werden, ohne mit den
Beteiligten, die das Ergebnis liefern werden, verbunden zu sein. Wenn die Erwartungen
unrealistisch sind oder von Interessenvertretern nicht geschätzt werden, müssen sie besprochen
und früh im Prozess verhandelt werden (Womack und J., 1996).
Shillito und DeMarle bringen auch eine quantitative Annäherung an die Beschreibung
des Wertes, von dem wird einen zusätzlichen Einblick in die Beziehung zwischen
den Attributen gewinnen können, die den Wert umfassen. Der Wert wird als direkt proportional
zu der Fähigkeit des Produktes die Kundenbedürfnisse zu befriedigen gesehen und
ist umgekehrt proportional zu den Kosten des Produktes oder Dienstes (Shillito, 1992).

In mathematischen Begriffen:
Wo:
N = das Bedürfnis nach dem Produkt oder Dienst
A = die Fähigkeit des Produktes oder Dienstes, den Kunden zu befriedigen
C = die Kosten des Produktes oder Dienstes
f (t) = die Abhängigkeit von der Zeit
Es gibt erfolgreiche Beispiele von Unternehmen (ein sehr eindrucksvolles Beispiel
beschreiben z.B. die Autoren (Womack und J., 1996, S. 241), die den Kundenwert richtig
überarbeitet haben und sehr erfolgreich mit einer verbesserten Definition des Kundenwertes
(über die Toyota Motor Company hinaus) wurden. Aber für viele Unternehmen gestaltet
sich die Umsetzung dieses ersten schlanken Prinzips mehr als schwierig. Mangelnde
Kundenorientierung ist oftmals die Ursache für die auftretenden Probleme bei der Umsetzung
dieses Prinzips. Zusätzlich existieren erhebliche Informationsdefizite in Bezug auf
die Kundenumwelt sowie deren Probleme und die konkreten Kundenwünsche (Pfeifer,
1992, S. 49).
Zum Schluss kann der Wert nur vom Kunden festgelegt werden und ist nur bedeutungsvoll
wenn er in Bezug auf spezifische Produkte mit eigenen Fähigkeiten und zu einem
besonderen Preis definiert wurde (Womack und J., 1996, S. 16).
2.2.2.2 Identifizierung des Wertschöpfungsstroms
Der folgende Schritt in der Lean-Philosophie bezeichnet als der Ist-Wertstrom.
Dies bedeutet die Gesamtheit der verlangten Tätigkeiten zu identifizieren, um das spezifische
Produkt zu erzeugen, unabhängig von seinem Nutzen und seinen Diensten (Womack
und J., 1996, p. 19).
Um Verschwendung sichtbar zu machen ist die Identifikation des Wertstromes
notwendig. Denn sie bilden alle verknüpfte Aufgaben, Knoten der Kontrolle und die miteinander
verbundenen physischen Flüsse ab, die notwendig sind um den Kundenwert zu
identifizieren. Hierfür muss das Unternehmen die gesamten nicht-wertschöpfenden Tätigkeiten
beseitigen, alle notwendigen nicht-wertschöpfenden Tätigkeiten minimieren und die
wertschöpfenden Tätigkeiten optimieren. In der Herstellung wird materiell gearbeitet während
im Entwicklungsbereichsgebiet die Information dominiert. Für dieses Thema ist es
besonders wichtig, den Unterschied zwischen Produktion und Entwicklung zu verstehen.
Der Begriff "Datenfluss" bezieht sich auf die Pakete der Information (Kenntnisse), die
durch verschiedene Aufgaben geschaffen werden und die in andere Aufgaben für die Rezension,
Entscheidung und Integration fließen. (Oppenheim, 2010).
Bei dieser Analyse finden sich in der Regel die folgenden drei Typen von Tätigkeiten
(Hines, 2001, S.28) (siehe Abb. 11) :
• Wertschöpfende Tätigkeit: hierbei handelt es sich um, die für den Kunden entscheidende
Aktivitäten, da für ihn ein Nutzen entsteht, wie z.B. bei der Entwicklung eines neuen
Radars.

Wissenschaftliche Bachelorarbeit 21
• Notwendige aber nicht-wertschöpfende Tätigkeiten: obwohl diese Tätigkeiten keinen
Wert erzeugen und eher Verschwendungen darstellen, können sie nicht sofort und ohne
große Veränderungen aus dem Gesamtsystems eliminiert werden. Grund dafür sind die
momentane Gegebenheiten und die unabdingbaren zur Verfügung stehende Technologien,
wie z.B. eine zusätzliche Qualitätssicherung.
• Nicht-wertschöpfende Tätigkeit: diese Aktivitäten sind reine Verschwendung und sollten
so schnell wie möglich eliminiert werden. Darunter fallen z.B. Doppelbearbeitung,
Wartezeiten und unnötige Transporte.
Abbildung 11: Zeitaufwand in der Produktentwicklung (Oehmen 2010)
2.2.2.3 Flussprinzip
Nachdem der Wertstrom identifiziert worden ist und die Verschwendung beseitigt
worden ist, müssen die restlichen wertschaffenden Schritte fließen. Um einen Fluss zu erreichen
müssen sich die wertschaffenden Schritte unaufhörlich und ohne Unterbrechung
bewegen Um einen Fluss zu optimieren, wird eine maximale Parallelität der Aufgaben bis
zur nahen Kapazität des Unternehmens geplant. Die Erfassung des Wertes und der Programm-Planung
sind die zwei notwendigen Bedingungen für die nachfolgende Lean Ausführung
des Programmes (Oppenheim, 2010).
Geplante Technikwiederholungen sind immer in der Produktentwicklung erforderlich,
aber sie neigen dazu zeitaufwendig zu sein wenn sie sich über Disziplinen (z.B. SE)
erweitern (Murman, 2002). Das Ziel des Flussprinzips besteht in einer neuen Arbeitsvorgang
durch Funktionen, Abteilungen und Gesellschaften, um den Informationsaustausch
fließender zu gestalten. Dies ermöglicht eine Wertschöpfung und bietet eine Antwort für
alle Prozessteilnehmer (Womack und J., 1996, S. 24). Eine erfolgreiche Wiederdefinition
verlangt nicht nur eine Konzentration auf das Zielprodukt sondern auch traditionelle Arbeitsmethoden
und oder Werkzeuge zu überdenken. (Womack und J., 1996, p. 64)

2.2.2.4 Pull-Prinzip
Die Lean-Philosophie beschäftigt sich nicht nur mit der Frage, wie kann das Unternehmen
den Kunden mit seinen Anforderungen zufriedenstellen, sondern auch wie die
Produkte und Dienstleistungen dem Kunden gegenüber zur Verfügung gestellt werden
können. Das Pull-Prinzip beschäftigt sich also nicht nur mit der Wunscherfüllung der Kunden,
sondern auch mit der Möglichkeit, dass das Unternehmen jederzeit dazu bereit sein
kann. Anstatt dem Kunden die Produkte und Dienstleistungen aufzudrängen, werden Letztere
an die Ansprüche und Bedürfnisse der Kunden angeglichen (Oppenheim, 2010).
2.2.2.5 Das Streben nach Perfektion
Das letzte Prinzip in dieser Reihe ist das Streben nach Perfektion. Sie erinnert uns
immer daran, dass es kein Ende in der zunehmenden Anstrengung, Zeit, Raum und Kosten
gibt (Womack und J., 1996, p. 25). Die Belegschaft findet daher immer wieder einen besseren
Weg, den Kundenwert zu kürzen, sobald sie mit ihnen in Kontakt treten.
Die Ingenieurswissenschaft und andere Prozesse müssen unaufhörlich aus endlosen
Wettbewerbsgründen verbessert sein. Dies erlaubt die Fehler, die sich im Informationsfluss
befinden, sichtbar zu machen (Morgan und Liker, 2006). Es ist letzten Endes für Unternehmen
wichtig, die Unterscheidung zwischen Prozess und Produktperfektion zu verstehen
und Mittel entsprechend zur Verfügung zu stellen.
2.2.3 Lean Systems Engineering
SE ist das Nervensystem von Produktentwicklung (PD) und gleichzeitig ein innewohnender
Teil von PD (Hitchens, 2007). Anhand der Erfolge von Toyota in PD und der
Schwierigkeit die Lean-Philosophie in PD anzuwenden, ist es nicht überraschend, dass SE
eine Herausforderung für die Lean-Philosophie geworden ist. Der Zusammenschluss von
Lean und Systems Engineering ist Lean Systems Engineering (LSE) genannt worden (Oppenheim,
2010). SE und Lean haben sich traditionell auf verschiedene Phasen des Produktlebenszyklus
mit ihren jeweiligen Herausforderungen konzentriert. Der traditionelle Bereich
der SE Praxis ist im Allgemeinen die Produktentwicklung während der traditionelle
Bereich der Lean Praxis allgemein die Produktion ist. SE wird auf jene Tätigkeiten traditionell
eingestellt, die zur Produktdefinition (von Voraussetzungen bis ausführliche Spezifizierungen)
den höchstwahrscheinlichen Kundenbedarf erfolgreich decken können. Andererseits,
wird Lean auf jene Tätigkeiten traditionell eingestellt, die die Verwirklichung des
Produktes so einstellen, dass der Kunde mit dem Wert erfolgreich versorgt wird. Durch
den Fokusunterschied im Rahmen der Produktlebenszyklusphasen ist die Betonung von SE
auf der Planung während Lean sich mehr auf die empirisch gesteuerte Handlung konzentriert
(Rebentisch, 2004). Lean Systems Engineering ist das Gebiet von Synergie zwischen
Lean und SE, mit dem Ziel den besten Lebenszykluswert für technisch komplizierte
Systeme mit minimalen Mitteln zu liefern (INCOSE, 2010). Diese Synergie verursachte
nachfolgende Definition von LSE: Lean Systems Engineering ist die Anwendung von
Lean-Prinzipien, -Methoden und -Werkzeugen zur SE, um den sicheren Transfer des Wertes
den Miteigentümern des Systems zu erhöhen (Oppenheim, 2010).

Wissenschaftliche Bachelorarbeit 23
2.2.4 Six Sigma Methode
2.2.4.1 Geschichte
Six Sigma Methode ist ein Qualitätsverwaltungsprogramm, das sich bemüht anhand
einer Reduzierung der Prozess-Fehlern und Schwankungen, die Rentabilität einer Gesellschaft
und die Kundenbefriedigung zu verbessern. Das Programm wurde von Motorola,
Anfang der 1990er Jahre entwickelt um die Qualität der Produkten zu erhöhen (Hutton,
2004, S.9).
2.2.4.2 DMAIC
Abbildung 12: DMAIC (Paul Bayer, 2008)
Nach George (George M. L., 2002), erkannte Motorola, dass es ein Muster zur
Verbesserung gab. Dieses Muster konnte in fünf Phasen der Problemlösung geteilt werden,
die gewöhnlich durch das Akronym DMAIC repräsentiert sind: "Definieren Messen Analysieren
Verbessern Kontrollieren". DMAIC bildet die fünf Hauptphasen von jedem Six
Sigma-Projekten (siehe Abb. 12).
Definitionsphase
Das Ziel dieser Phase ist die Auswertung der Datenerhebung zu untersuchen, um
die Natur und das Ausmaß des Defekts zu charakterisieren (Stephen, 2004). Das Arbeitsteam
sollte in dieser Phase bestimmen, ob die Prozesse neu studiert werden müssen oder
ihre Absichten erhalten werden können. Die Mitarbeiter führen Fähigkeitsstudien durch,
um die Ursachen zu finden, warum einige Prozesse die gewünschten Ergebnisse nicht erfüllen
können. Werkzeuge (wie z.B. Microsoft Excel-Programme) helfen Mitarbeitern im
Reduzieren und Organisieren großer Mengen von Daten und können dadurch ein besseres
Verständnis der Tendenzen und relevanten Faktoren aufzeigen. Durch die genaue Studie

der Daten und die Vertiefung in die Details, kann ein besseres Verständnis des Prozesses
erlangt werden. Somit kann letzten Endes die Identifizierung der Wurzelursache des Projektes
herausgefunden werden (Hutton, 2004).
Datenerhebung
Das Ziel dieser Phase ist Daten anhand des Problems zu sammeln (Stephen, 2004).
Die Datenerhebungsphase identifiziert die Grenzen des Entwicklungsprozesses und hilft
dem Arbeitsteam die Prozessvariablen zu identifizieren. Was von den Mitarbeitern erwartet
wird, ist die Identifizierung und Messung der Variablen die vom Eingang- als auch vom
Ausgangsprozess abgeleitet werden. Die verwendete Datenerhebungsmethoden, um die
Probleme zu identifizieren sind kritisch zu betrachten (Hutton, 2004).
Analyse
Das Ziel dieser Phase ist die Auswertung der Datenerhebung zu untersuchen, um
die Natur und das Ausmaß des Defekts zu charakterisieren (Stephen, 2004). Das Arbeitsteam
sollte in dieser Phase bestimmen, ob die Prozesse neu studiert werden müssen oder
ihre Absichten erhalten werden können. Die Mitarbeiter führen Fähigkeitsstudien durch,
um die Ursachen zu finden, warum einige Prozesse die gewünschten Ergebnisse nicht erfüllen
können. Werkzeuge (wie z.B. Microsoft Excel-Programme) helfen Mitarbeitern im
Reduzieren und Organisieren großer Mengen von Daten und können dadurch ein besseres
Verständnis der Tendenzen und relevanten Faktoren aufzeigen. Durch die genaue Studie
der Daten und die Vertiefung in die Details, kann ein besseres Verständnis des Prozesses
erlangt werden. Somit kann letzten Endes die Identifizierung der Wurzelursache des Projektes
herausgefunden werden (Hutton, 2004).
Verbesserungsphase
Das Ziel dieser Phase ist Defekte in der Qualität als auch in der Geschwindigkeit
der Prozesse zu beseitigen (Stephen, 2004). Projektbeteiligte können gerade am Anfang
frustriert werden da sie sich nicht sofort in einer Verbesserungsphase bewegen. Bei Erlangung
dieser Phase gewinnen die Meisten eine tiefe Anerkennung und Rücksicht für die Six
Sigma Methode. In dieser Phase werden erstmals Ergebnisse verlangt (Hutton, 2004).
Sobald mehrere potenzielle Lösungen identifiziert worden sind, müssen sie geprüft
werden. An diesem Punkt, geht das Arbeitsteam in die analytische Phase um Daten zu
sammeln und zu analysieren. In den meisten Vorkommnissen, können mehr als eine Lösung
zum Problem identifiziert werden. Wenn dies der Fall ist treten Faktoren, wie Kosten,
Zeit der Durchführung sowie wahrscheinliche Vorteile vom Projektleiter in den Vordergrund
(Pande & Holpp, 2002).
Kontrollphase
Das Ziel dieser Phase ist die Erstellung einer Bilanz der herausgefunden Vorteile
der vorherigen Phasen (Stephen, 2004). Das Projektteam muss einen Kontrollplan durchführen,
die die Effizienz des Optimierungsprojektes anhand einer Entwicklung von Parametern
überprüft. Die letzte Aufgabe des betroffenen Projektteams und des Projektmanagements
ist es die langfristigen für das Projekt sichern zu können (Pande & Holpp, 2002),
(Hutton, 2004).

Wissenschaftliche Bachelorarbeit 25
2.2.5 Simultaneous Engineering
2.2.5.1 Definition
Simultaneous Engineering (S.E) (Concurrent Engineering wird in dieser Bachelorarbeit
als Teil des Simultaneous Engineering angesehen) ist der integrierte und zeitparallele
Ansatz von Entwicklungsarbeiten für alle produktentstehungsbeteiligten Unternehmensbereiche.
Die Vorteile des Simultaneous Engineering sind laut Ernst, 2003:
• die Frist von der Produktidee bis zur Markteinführung des Produktes zu verkürzen
• Eine Verkürzung der Entwicklungszeiten durch Parallelisierung der Teilprozesse
Die wachsende Forderung im Innovationsbereich nach einer Verkürzung des Produktionsentwicklungsprozesses
kann jedoch mit der traditionellen Engineerings-Methode
in der Entwicklung nicht erfüllt werden. Bei dieser sequentiellen Vorgehensweise werden
die Phasenergebnis anschließend an die nächste Abteilung weitergegeben. Der Informationsfluss
geht dabei nur in eine Richtung, da keine Möglichkeit des Feedbacks gegeben
wird. Wenn Fehler auftreten, wird es schwierig diese zu entdecken. Fehler werden in der
Regel erst beim Kunden entdeckt und machen teuren Rework notwendig und verlängern
somit die Projektlaufzeit. Im Simultaneous Engineering sind die Beziehungen zwischen
den parallel laufenden Entwicklungsabteilungen stärker ausgeprägt (siehe Abb. 13).
Abbildung 13: Simultaneous gegen Sequentiel (Ernst, 2003)
Bei der Durchführung eines Projektes gibt es drei übergeordnete Faktoren: Zeit,
Kosten und Qualität. Diese Faktoren sind untereinander verknüpft, sodass eine bewusste
Änderung eines Faktors auch die beiden Anderen betrifft. Will man beispielsweise die
Qualität erhöhen, so hat man demnach mit einem Anstieg der Entwicklungszeit und somit
der Kosten zu rechnen. Dieser Sachverhalt ist als das Magische Dreieck bekannt (siehe
Abb. 14), (Max Lill, 2011).

Abbildung 14: Das magische Dreieck (Ernst, 2003)
Simultaneous Engineering hat Auswirkungen auf diese drei Faktoren und kann die
Beziehung zw. ihnen verbessern: die Entwicklungszeit verkürzen, gleichzeitig die Kosten
senken und die Qualität des Produktes erhöhen. Die vermeintlichen Zusammenhänge des
Magischen Dreiecks sollen dabei also aufgehoben werden.
2.2.5.2 Problemen/ Risiken
Simultaneous Engineering bietet nicht nur Vorteile, sondern bringt auch Nachteile
und Risiken mit sich. Die drei wichtigsten Herausforderungen sind:
• Qualifikation:
Sowohl an die Teamleiter als auch an die Mitarbeiter werden hohe Qualifikationsansprüche
gestellt. Teamleiter müssen einen hohen Koordinationsaufwand bewältigen, während
von den Mitarbeitern eine hohe Teamfähigkeit verlangt wird. "Fehlen diese Fähigkeiten, so
droht ein Nebeneinander ohne Integrationseffekte" (Ernst, 2003).
• Menschliche Herausforderungen:
"Durch das hohe Engagement des S.E-Teams können andere Mitarbeiter des Unternehmens
ein Gefühl der "Zweitklassigkeit" entwickeln, dies führt dann wiederum zu Rivalitäten.
So ist es möglich, dass das S.E-Team von anderen Stellen im Unternehmen nicht die
volle Unterstützung erhält" (Ernst, 2003).
• Unsicherheit der Informationen:
Der dritte Punkt ist für diese Studie sehr relevant. Obwohl die Parallelisierung einen direkten
Zeitgewinn, durch einen rechtzeitigen Beginn der Entwicklungsprozesse bringt, ist diese
nicht ohne Nachteile. Die Durchführung von zwei parallel laufenden Tätigkeiten zwingt
Entwickler dazu, noch nicht finale Informationen auszutauschen. Wenn es keine Parallelität
gibt, können Informationen in Ihrer Endform ausgetauscht werden. Wenn eine Abhängigkeit
fehlt, gibt es kein Bedürfnis, Information auszutauschen. Diese nicht optimale Information
ist die direkte Folge der Wechselwirkung zwischen Disziplin, Parallelität und
Abhängigkeit (Terwiesch, 2002).

Wissenschaftliche Bachelorarbeit 27
Je früher ein downstream Prozess (siehe Abb. 15) beginnt, desto höher wird die Gefahr
von zukünftigen Änderungen, besonders wenn das Ergebnis von upstream Aktivitäten
(siehe Abb. 15) schwierig oder unmöglich vorauszusagen sind. In diesem Fall riskiert die
Parallelisierung der Disziplinen zusätzliche technische Anstrengungen in der Form von
Rework. Diese kann bis zu 50 % der Engineeringskapazität verbrauchen. (Clark und
Fujimoto 1991, Soderberg, 1989).
Abbildung 15: Informationsaustausch up-/ downstream (Thomson, 2010)

3 DIE ROLLE DER INFORMATION IN DER PRODUKTENTWICKLUNG
Engineerings-Prozesse verlangen Kreativität und umfassen Tätigkeiten wie Design,
Engineerings-Analysen und Leistungseinschätzungen. In der Entwicklungsphase sind
Ingenieure größtenteils abhängig von der Information sowie Berichte, Zeichnungen, Modell
und Handbücher (Gunendran, 2006), (Costa, 2001). Heutzutage ist ein wirkungsvoller
Gebrauch der Informationen und der Kenntnisse erforderlich, um die Ziele der Organisationen
effizient zu erfüllen (Moran, 1999), (Dietel, 2000), (Chaffey, 2004). Nach Bjork
[2003] ist das Suchen nach gelagerten Digitaldokumenten in einem Firmencomputer weitaus
komplizierter, im Vergleich zur Suche in einer persönlichen Ablage. Die zuverlässige,
gleichmäßige und dauerhafte Verwaltung von Informationen innerhalb einer Gesellschaft
ist entscheidend für die Engineerings-Sektoren, wie am Beispiel der Systemintegration in
Abb. 16 gezeigt. Informationen sind also in den Bereichen des Designs, der Herstellung
und für den Lebenszyklus eines Produktes entscheidend. (Ullman, 2003), (Christian,
1995), (Lowe, 2004).
Abbildung 16: Phasemodelle (Suss, 2010)

Wissenschaftliche Bachelorarbeit 29
3.1 Definition
Gewöhnlich versteht man unter Information, eine Nachricht in Form eines Dokumentes,
Modells oder einer sonstigen hör- oder sichtbaren Kommunikationsform. “[...]
Information is meant to change the way the receiver perceives something, to have impact
on his judgement and behaviour.“ Laut Peter Ducker , Information ist “[...] data endowed
with relevance and purpose.” (Davenport 1998, S. 2). Dies bedeutet, dass eine mögliche
Vorstellung der Information einen Kontext eingebettete Daten sein könnte. Dieser Kontext
stellt den Bezug zum Ziel her. „Er macht die Daten zu Informationen, die eine Bedeutung
haben, die interpretierbar sind, und die Grundlage für Handlungen sein können. Allgemein
werden Daten zu Informationen, wenn ihnen eine Bedeutung zugeteilt wird.“ (Kallmeyer,
2000). Davenport und Prusak definieren fünf verschiedene Möglichkeiten, mit denen aus
organisierten Daten Informationen werden können (Davenport 1998, S. 4).
Alle beginnen mit dem Buchstaben K:
• Kontextualisierung: das Ziel für die Datensammlung wird erkannt.
• Kategorisierung: Teileinheiten werden durch Analyse oder anhand der Schlüsselkomponenten
der Daten erkannt.
• Kalkulation: die Daten wurden mathematisch oder statistisch untersucht.
• Korrektur: Fehler wurden von den Daten entfernt.
• Komprimierung: die Daten wurden in einer knapperen Form zusammengefasst.
Millard (2001, p. 26) verbindet den Fortschritt der Information zu ihrem Fluss und
die Reife der Information durch den Prozess. Sein Modell nimmt an, dass unorganische
Daten organisiert werden müssen, um zu einer Information zu werden (siehe Abb. 17). In
dem unten abgebildeten Schema wird illustriert, wie eine Information zum Fortschritt werden
kann (Millard, 2001, S. 21).
Abbildung 17: Von Daten bis Information (Graebsch, 2005)
Anbei sind einige wichtige Aspekte der Information in (Produktentwicklung) Prozessen
nach Graebsch (2005):
• Information beruht auf Daten.
• Information kann verwendet werden, um Kenntnisse zu erzeugen.
• Um Kenntnisse zu übertragen müssen diese entschlüsselt werden.
• Nicht jeder Typ von Kenntnis kann mit derselben Art und Weise ver- und entschlüsselt
werden. Infolgedessen, hängen Informationsübertragungen gewöhnlich sowohl von expliziten
als auch von impliziten Kenntnissen ab.
• Die Brauchbarkeit der übertragenen Information hängt vom Benutzer, von Prozessen
und von vielen Eigenschaften der Information, sowie von der Informationsqualität ab.

3.2 Typ von Informationen
In der Studie von Gardoni [Gardoni und al. 1999] ordnen sich die Informationen
nach drei Kategorien: strukturiert, halbstrukturiert und nicht strukturiert. Die strukturierten
Informationen sind formalisierte Informationen. Dies bedeutet, dass die Dokumente die sie
enthalten geordnet und formalisiert werden. Die Informationen können rechtzeitig als vollständig,
beständig und gültig betrachtet werden. Die halbstrukturierten Informationen werden
weniger formalisiert, da sie allgemein in weniger strukturierten Dokumenten, wie
Brief oder E-Mail, abgegeben sind. Nicht strukturierte Informationen können nicht formalisiert
werden und sind daher auch nicht beständig. Sie entsprechen mündlichen Informationsaustauschen,
wie z.B. Versammlungen, Telefongespräche oder Aussprachen in den
Gängen einer Abteilung. Es ist also offensichtlich, dass alle Informationen weder dieselbe
Aufmerksamkeit noch dieselbe Verarbeitung erfordern, da manche leichter zu bearbeiten
sind wie Andere.
In Produktentwicklungsprozessen gibt es eine grundlegende Unterscheidung zwischen
Information als noise type, content type oder process type (siehe Abb. 18) (Graebsch,
2005).
• Content type: Informationen beabsichtigen jemanden eine Auskunft über das entwickelte
Produkt zu geben. Allgemeine Beispiele sind Spezifizierungen, Zeichnungen,
Produktverträge, Simulationen, CAD-Modelle und Ähnliches.
• Process type: Informationen beabsichtigen jemanden über den Zusammenhang der
Entwicklung zu informieren. Beispiele sind Listen, Telefonnummern, Ausgaben für
das Produkt, Entwicklungsmittel, Organisationspläne, usw...
• Noise type: Informationen haben keinen Entwicklungszweck, wie z.B. spamhaltige E-
Mails oder persönliche Post.
Abbildung 18: Type von Informationen (Graebsch, 2005)
3.3 Welche Probleme gibt es beim Informationsaustausch heute?
Es gibt heute viele Schwierigkeiten beim Informationsaustausch. Anbei ist ein Einblick
in einige dieser festgestellten Probleme aus der Literatur nach Starck (2011) und
Loch (1998):

Wissenschaftliche Bachelorarbeit 31
Zugriff
Ein kompliziertes Zugriffsmanagement kann die Zugriffsrechte eines Benutzers auf bestimmte
Produktdaten während eines Produktlebenszyklus ändern. Dadurch kann es passieren,
dass ein Benutzer der das Recht hatte sich Produktdaten zu verschaffen und zu modifizieren,
in einer anderen Zeit, keinen Zugang mehr zu diesen Daten bekommt. Und, in einer
bestimmten Zeit, kann eine Person verschiedene Zugriffsrechte auf verschiedene Projekte
und Produkte haben. Der Zugang zu Produktdaten kann weiter durch IT-Sicherheitsaspekte
und Einführungen von neuen Anwendungen erschwert werden.
Archivierung
Viele Produktdaten müssen in der Industrie für einen langen Zeitraum behalten werden.
Kunden können z.B. verlangen, dass Daten für mehrere Jahrzehnte archiviert werden.
Erhältlichkeit
Produktdaten müssen für Benutzer verfügbar sein, wo sie es brauchen und wann sie es
brauchen. Zum Beispiel benötigt ein Flugzeug die Option in jedem Teil der Welt repariert
zu werden. Dessen Information muss also für eine genaue Konfiguration, jederzeit verfügbar
sein.
Vertraulichkeit
Produktdaten sind wertvoll. Viele davon sind vertraulich und sollten von Personen aus
anderen Organisationen, wie Mitbewerber nicht bearbeitet oder gesehen werden.
Austausch
Produktdaten müssen häufig von einem Platz zu einem Anderen umgelagert werden. Diese
Neuordnung kann entweder von einer Person zur einer Anderen vermittelt werden oder
kann zw. zwei Anwendungen (oder Darstellung oder Eigentümer) ausgetauscht werden.
Die Übertragung der Daten kann z.B. durch die Darstellung der Medien verschiedene Wege
einschlagen, wobei die Information der Gefahr unterläuft verändert zu werden. Daher
sind genaue Konvertierungen erforderlich, wenn Produktdaten von einer Darstellung zu
einer Anderen oder mittels eines Mediums übertragen werden. Allerdings sind genaue
Konvertierungen unmöglich, da es immer ein Qualitätsverlust gibt.
Es gibt weitaus mehr Probleme beim Informationsaustausch die hingegen ohne Hilfe von
Lean Engineering unmöglich zu identifizieren und zu studieren sind. Deshalb wurde das
Konzept in dieser Arbeit entwickelt, das eine bessere Identifizierung und Kategorisierung
dieser Problemen ermöglicht.

4 WASTE IN DER PRODUKTENTWICKLUNG
4.1 Grundlagen
Produktentwicklungsprozesse schaffen Werte indem sie Informationen erzeugen.
Da in der Entwicklung komplexer Systeme viele unterschiedliche Disziplinen beteiligt
sind, welche untereinander in verschiedenster Form Information austauschen, können
durch den Informationstransport Verluste (gleichbedeutend mit Verschwendung, bzw.
„Waste“)verursacht werden. Das Lean-Denken bewirkte positive Ergebnisse bezüglich der
Leistungsfähigkeit und der Verminderung der gesamten Bearbeitungszeit (Womack und J.,
1996). Die Übertragung der Lean-Grundsätze auf die Produktentwicklungsprozesse, bewirkte
demnach positive Effekte auf die Prozessleistungsfähigkeit (McManus, 2005), (Oppenheim,
2004), (Murmann, 2002).
In dem Buch "Lean Thinking“ von 1996 erklären die Autoren Womack and Jones,
dass sich die Lean-Produktionsgrundsätze und -Werkzeuge auf das Gebiet der Produktentwicklung
übertragen lassen (siehe Abbildung 19). Das Studieren verschiedener Autoren
beweist, dass sogar Fachmänner in diesem Gebiet nicht dieselben Vorstellungen haben und
sich daher auf verschiedene Aspekte konzentrieren. Diese Annäherung unterliegt der Tatsache,
dass nicht physisches Material wie in der Produktion, sondern Informationen in der
Produktentwicklung betrachtet werden.

Wissenschaftliche Bachelorarbeit 33
Abbildung 19: Lean Manufacturing und Lean Engineering (Oppenheim, 2010)
Durch eine Zusammenfassung unterschiedlicher Theorien der Wastes in der Produktentwicklung
von Oppenheim (2004), Bauch (2004), Kato (2005), McManus (2005), Oehmen
(2010), usw. kann für diese Arbeit eine umfassende und auswertbare Einheit verschiedener
Wastes zusammengestellt werden, die ungefähr 80 Prozent der wichtigsten Probleme umfasst.
Um die Art der Verschwendung (Waste) herauszufinden, müssen diese immer kritisch
im konkreten Projektzusammenhang widergespiegelt und interpretiert werden (Oehmen,
2010). Die Abbildung 20 zeigt, wie Bauch (2004), eine Zusammenfassung der Verschwendungen
in der Produktentwicklung aus verschiedenen Literaturquellen resümiert hat
und welches eine wesentliche Grundlage für die weitere Ausarbeitung des Konzeptes bildet.
Abbildung 20: Zusammenfassung der wastes (Anhang 9.1) nach Bauch (2004)

4.2 Zehn wastes
Zum Thema „waste in der Produktentwicklung“ hat einerseits die Literaturrecherche
und andererseits der Kontext der Themenstellung, die Identifizierung von zehn relevanten
Typen von waste ermöglicht.
4.2.1 Transport (Störung im Informationstransfer)
Der physische Transport der Information im Falle von Dokumentationsgenehmigungen
lässt einen hohen Zeitverbrauch zu. In einer klassifizierten Dokumentenumgebung
gibt es strenge Regeln für die Vorbereitung und das Verpacken solcher Dokumentationen,
die sehr häufig persönlich (von Hand zu Hand) geliefert werden müssen. Dieses Problem
wird deutlich, wenn eine Vielzahl von Genehmigungsverfahren für ein Dokument hintereinander
folgen und diese über mehrere Gebiete verteilt werden müssen. Der Gebrauch von
modernen Technologien kann jedoch ein sichere elektronische Übertragung und sogar
elektronische Genehmigungsverfahren für die Mehrheit der Dokumente sicherstellen. Die
Transportzeit wird so drastisch reduziert, die Genehmigungsverfahren schneller durchgeführt
und somit der Zugang zu den Dokumenten schneller ermöglicht (Christelis, 2012). Im
Allgemeinen richtet sich dieser Typ der Verschwendung nicht nur an die ineffiziente Übertragung
der Information (z.B. Papiere), sondern auch in die unnötige Bewegung der Information
(Datenübertragung, wie z.B. Papiere, Fax, E-Mails und Dateien). Die folgenden
Beispiele sind Unterkategorien der Verschwendung im Transport:
4.2.2 Bestände
• Übermäßiger Datenverkehr
• Ineffektive Kommunikation
• Hand Offs
Während man sich in der Produktion, Lagerungen und Warteschlangen eher auf die
übermäßige und unnötige Verfügbarkeit (Zahl von Materialien und Teilen) bezieht, wird in
der Produktentwicklung beschrieben, dass Informationen in heterogenen IT-Umgebungen
auf Computerlaufwerken und Datenbanken verteilt sind und auf weitere Verarbeitungen
durch funktionelle Abteilung warten.
Ein anderer Aspekt betrifft das Lager oder eher die Datenlagerung in der Produktentwicklung.
Selbst wenn die Lagerung der Information per se nicht teuer ist, wird ihre
ineffiziente Verwaltung ein viel größeres Problem, das einen ganz anderen und überflüssigen
Typus von waste, wie z.B. die Informationssuche schaffen kann. Dieses Problem ist
nicht nur vom Informationssystem abhängig sondern auch vom Engagement der Mitarbeiter,
die eine Auswirkung auf dieses System haben (Mangeln an Systemdisziplin).
Der letzte Punkt, überprüft gelagerte Informationen, die als unnötig oder unbrauchbar
bewertet werden, da sie keine wirklichen neuen Informationen zum Entwicklungsprozess
hinzubringen (Bauch, 2004), (Christelis, 2012). Die folgenden Beispiele sind Unterkategorien
der Bestände:
• Unnötige Prüfung von Informationen
• Übermäßige, unsystematische Datenlagerung

Wissenschaftliche Bachelorarbeit 35
4.2.3 Bewegung (Motion)
Bewegungsverschwendung kann als jede unnötige Bewegung durch einen Mangel
an direktem Zugang (ungenügender Informationssysteme, ungleicher Positionen, ineffizienten
Gebrauches der Ausrüstung, Werkzeuge und Techniken) betrachtet werden. Die
Zeitverschwendung erklärt sich zum Teil auch durch hohen Anteil an Reisezeiten aufgrund
verteilter Standorte (Oehmen, 2010). McManus (2004, p. 51) schließt ebenfalls die
Benutzerbewegungen zwischen Werkzeugen oder Systemen bezüglich des Informationssystems
ein. Die folgenden Beispiele sind Unterkategorien der Bewegung:
4.2.4 Warten
• Mangel am direkten Zugang
• Verteilte Standorte
Warten ist "the idle time due to unavailable information, manpower or computing
resources” (McManus, 2004, S.50). Das Warten der Arbeitskraft kommt vor, wenn unentbehrliche
Informationen nicht verfügbar sind, um bestimmte Aufgaben durchzuführen zu
können. Diese Fehlinformation kann z.B. ein Genehmigungsverfahren einschließen oder
ein Dokument das zur Ausführung der Aufgabe benötigt wird betreffen (Oehmen, 2010).
Fälle wie Genehmigungsverfahren nehmen den größten Teil der Wartezeit, wenn z.B. Mitarbeiter
auf Schreibtischen auf ihre Bearbeitung warten. Wenn der Mensch am Lesen und
an der Genehmigungsverfahren von Dokumenten beteiligt ist, kann nicht viel getan werden,
um den Prozess zu beschleunigen, solange die Beteiligten ihre Prioritäten nicht teilen
oder ihre Zeit effektiv nutzen (Christelis, 2012). Die folgenden Beispiele sind Unterkategorien
des Wartens:
• Information wartet auf ihre Bearbeitung
• Menschen, die auf ihre verfügbare Kapazität (Mensch oder Maschine) warten
4.2.5 Überproduktion
Die Verschwendung der Überproduktion geschieht, wenn redundante oder unnötige
Informationen geliefert werden (Oehmen, 2010). Die Quelle des Problems ist hier das
Dokument selbst. Wenn dem Autor die Weiterverwendung des Dokumentes unbekannt
bleibt, kann es passieren, dass die Empfänger zu viele Informationen bekommen und ihnen
letztendlich die wichtigste Botschaft für Ihre Disziplin (z.B. SE) untergeht (Christelis,
2012). Ein Beispiel der Überproduktion ist der übermäßige Durchsatz der Information
(McManus, 2004, S. 50). Da das Ausmaß der Überproduktion ein direktes Ergebnis der
Qualität des Synchronisationsprozesses ist, müssen nicht nur die Aufgaben in Bezug auf
Zeit sondern auch bezüglich Inhalt, Menge und Ressourcen synchronisiert werden. Die
Synchronisation bezüglich dieser Aspekte ist Teil des Simultaneous Engineering. Die folgenden
Beispiele sind Unterkategorien der Überproduktion:
• Schlechte Synchronisation bezüglich des Inhalts
• Keine zielgerichtete Verbreitung von Informationen
• Redundante Tätigkeiten

4.2.6 Overprocessing
Die vorhergehende Definition der Überproduktion gibt eine gute Basis für weitere
Untersuchungen von nicht wertschöpfenden Tätigkeiten innerhalb der Produktentwicklung.
Das schließt unnötige Produkteigenschaften, unnötige Details und ungenaue Informationen,
übermäßige Transaktionen, den Gebrauch von ungeeigneten Werkzeugen ein, um
die Ergebnisse zu realisieren. Ein anderer Punkt ist in diesem Fall das Management von
übermäßigen Genehmigungsverfahren, welche häufig den Datenfluss verlangsamen. Ein
Beispiel für Overprocessing sind z.B. lange und unverständliche Berichte, die mit einfachen
und wohl durchdachten Diagrammen oder Bildern effektiv illustriert werden können.
Es ist also insgesamt wichtig, dass der Verfasser den Anwendungsbereich der weitere Nutzer
kennt, und seine Texte auf dessen Niveau der Verständlichkeit formuliert und aufstellt.
Überprozessing unterscheidet sich von der Überproduktion, da das Problem nicht die Realisierung
der Dokumente betrifft, sondern deren Auswertung (Christelis, 2012). Die folgenden
Beispiele sind Unterkategorien des Overprocessings:
• Unnötige Details und Genauigkeit
• Übermäßige Genehmigungsverfahren
• Unnötiger Aufwand für die Informationserstellung, um ein gewünschtes Ergebnis
zu erreichen
4.2.7 Fehler in Form von Rework
Das Korrigieren der Information beschäftigt sich mit der Verschwendung. Dies
schließt z.B. die Reparatur, das Überarbeiten der Information, das Ausrangieren von Informationen
(und nachfolgend der ganze Ersatz) und die Inspektion der Informationsgenauigkeit.
Beide, nachgearbeitet als auch ausrangierente Informationen haben dieselben
Ursachen. Der allgemeinste Grund sind fehlerhafte Daten und Information, die sich aus
schlechter Prüfung und Überprüfung ergeben können (Bauch, 2004, S.62). Die Entscheidung,
wann und wie Informationen zu einem bestimmten Niveau nachgearbeitet oder ausrangiert
werden müssen, hängt vom Ausmaß der Mängel ab (Oehmen, 2010). Die folgende
Beispiele sind Unterkategorien der Fehler in Form von Rework:
• Schlechte Prüfung und Überprüfung
• Fehlerhafte Daten und Informationen
4.2.8 Kommunikationsprobleme von Informationen
Die Kommunikation der Information ist sehr wichtig für die Zusammenarbeit in einem
Prozess. Sie ermöglicht eine Transparenz des Prozesses, d.h. auch eine klarere Identifizierung
der Rollen und der Verantwortlichkeiten. Jedoch ist eine wirksame und effiziente
Kommunikation von der höchsten Bedeutung für erfolgreiche PD-Projekte. Die Verschwendung
durch Kommunikationspannen erscheint durch ineffiziente Kommunikation.
Um eine erfolgreiche Kommunikation zu führen sind oftmals mehr Mittel erforderlich (z.B
Datenformat Konvertierung anstatt zu verwenden vereinigte IT Systeme). Eine ineffiziente
Kommunikation erklärt sich ebenfalls durch unnötige Mitteilungen von Informationen
(z.B. Diskussionen in großen Sitzungen, die nur einen Bruchteil der Mitarbeiter betrifft
oder übermäßige Ausschüttung von E-Mails) (Oehmen, 2010). Die folgenden Beispiele
sind Unterkategorien der Kommunikationsprobleme:
• Unklare Verantwortlichkeiten und Rollenverteilung

Wissenschaftliche Bachelorarbeit 37
• Prozess-Barrieren
• Kenntniss-Barrieren
4.2.9 Schlechte Informationsqualität
Dieses waste umfasst alle Probleme von Informationsqualitäten (ungeeignetes
Format, Ungenauigkeit, geringhaltige Sachlichkeit, Verständnisschwierigkeiten, usw.).
4.2.10 Mangelnde EDV-Werkzeuge / -Systeme
Die Entwicklung von neuen Informationstechnologien und Werkzeugen hat neue
Möglichkeiten in der Industrie während der letzten 15 Jahre geöffnet (wie z.B. umfassende
Datenbanken). Allerdings erschufen sich auf der anderen Seite neue Probleme. Der
Hauptgrund für jene Probleme liegt in der großen Vielfalt der vorhandenen EDV-
Bestandteile innerhalb der Informationssysteme. Aus der Sicht von IT-Technologien besteht
die Herausforderung (in der Produktentwicklung) die Ergebnisse des gesamten Systems
in einem einheitlichen Datenmodell abzubilden. Diese Ergebnisse sollen mithilfe von
aktuellen Softwaren brauchbar gemacht werden. Das wird durch neue Entwicklungen bezüglich
Softwarewerkzeuge, Betriebssysteme und Hardware-Systeme erschwert. Außerdem,
verlangt das Simultaneous Engineering eine Übereinstimmung zwischen der unterschiedlichen
IT-Werkzeugen und der Disziplinen. Hierfür werden eine Koordination und
Standardisierung des Datenaustausches benötigt. Die folgenden Beispiele sind Unterkategorien
der mangelnden EDV-Werkzeuge / -Systeme:
• Schlechte Vereinbarkeit
• Schlechte Fähigkeit
• Niedrige Kapazität (Verfügbarkeit)

5 KONZEPT
5.1 Anforderungen an das Konzept
Die Erstellung eines Konzepts ist immer dann sinnvoll, wenn ein Vorhaben oder
eine Idee konkretisiert werden soll. Das Ziel der Bachelorarbeit ist die Erstellung eines
Konzeptes zur Analyse von Problemen beim Informationsaustausch zwischen zwei parallel
verlaufenden Disziplinen. Das Thema der Arbeit lässt sich folgendermaßen zusammenfassen
(Wholin, 2000):
Analyse von Problemen beim Informationsaustausch zwischen SE und M-/E-Eng.
zum Zwecke einer Prozessverbesserung im Simultaneous Engineering
mit Bezug auf Lean Engineering Methoden
im Rahmen von Informationsaustausch in komplexen Flugzeugentwicklungsprozessen.
Am Anfang, ist es wichtig, die Anforderungen des Konzepts zu erstellen. Ein Konzept
muss flexibel sein. Es steht als eine Methode, die man für unterschiedliche Anwendungsfälle
implementieren kann. Dafür muss das Konzept zuerst für unterschiedliche Disziplinen
anwendbar sein. Die Disziplinen im Fokus dieser Studie sind SE und M-/E-Eng. .
Aber das Konzept muss disziplinunabhängig für Abteilungen oder Disziplinen anwendbar
sein (z.B. ebenfalls für Struktur Design).
Das vorliegende Konzept kann in zwei Teile geteilt werden. Ein Teil stellt die Zielgruppe
dar, die dieses Konzept benutzen wird. Den zweiten Teil stellt den Kontext dar, in
dem das Konzept implementiert wird. Wichtig ist die Identifizierung der Zielgruppen und
Ihrer Anforderungen. Wenn man diese Schritte nicht gut macht, kann man nie sicher sein,
dass das Konzept perfekt an die Bedürfnisse der betreffenden Benutzer angepasst ist. Zum
Beispiel, wenn man das Konzept für Experten schreiben will, kann man mehr detaillieren
und technische Begriffe verwenden. Gegenteilig ist es, wenn das Konzept für einen Neuling
oder einen Praktikanten ist, dann muss man mehr generell bleiben.
Zielgruppen: System Engineering Experten, Konstrukteure in Mechanik bzw.
Elektrik Entwicklungsbereichen, Konstrukteure in System Engineering und Experten in
Mechanik bzw. Elektrik Entwicklungsbereichen.
Diese Zielgruppen ermöglichen es, die Fachsprache zu benutzen aber es muss auch
nicht zu detailliert sein, weil es auch für anderen Projekten und Produkte anwendbar sein
muss.
Ausschlag gebend ist eine genaue Detaillierung des Konzepts. Dazu benötigt man
ein Szenario, um den Studienbereich einzugrenzen.
Szenario: Zuerst ist es wichtig daran zu erinnern, dass das Konzept für Produktentwicklungsprozesse
und nicht für den Produktionsbereich anwendbar sein muss. In Bereich
der Produktentwicklung, soll das Konzept für die Nutzung in der Definitionsphase ausgerichtet
sein. Es gibt in dieser Phase einen detaillierte Überblick über das Gesamtsystem,
ohne jedoch zu sehr in die Tiefe (auf Komponenten-Entwicklungsebene) zu gehen. Diese
Gesamtsicht ermöglicht es, auf dem Niveau der Disziplinen zu bleiben und von dort die

Wissenschaftliche Bachelorarbeit 39
Wechselwirkungen zu beobachten. Zum Schluss muss man das Produkt definieren. Im
Rahmen dieser Studie wurden aktuelle Entwicklungsprojekte von CASSIDIAN untersucht.
5.2 Lean Engineering Methode nach DMAIC
Das Konzept zur Beseitigung von Problemen beim Informationsaustausch zwischen
Disziplinen in der Produktentwicklung kann nach den vier nächsten Schritten von der
DMAIC Methode (Define, Measure, Analyse, Improve, Control) geplant werden. In den
nächsten Teilen werden diese unterschiedlichen Schritte und die Implementierung dieser
Methoden in dem Konzept detailliert (Abb. 21).
Fragebogen
1...*
Fragen
Probleme
Problem-Ursachen
Wastetypen
Statistische Auswertung
Value Methoden
Lean Enablers
Parameter
Abbildung 21: Konzeptdarstellung
Parameter
5.3 Identifizierung des Problemkontexts und Ziele (Define)
1...*
1...*
1...*
1...*
1...*
1...*
Dieser Schritt steht als Basis des Konzepts. In diesem Schritt wird das Kundenbedürfnis
genau definiert und dafür die Definition des Problems deutlich und ausgereift dargestellt.
Am Anfang muss der Kontext gut verstanden werden. Dafür müsssen die wichtigste
theoretische Grundlagen in Verbindung mit den Produkten, Bereich und Herausforderungen
gelernt werden. Die Dokumente von Experten zum Thema SE, Simultaneous
Engineering, Lean Engineering oder Produktentwicklungsprozesse ermöglichen es, eine
erforderliche Basis zu bekommen. Wenn die wichtigsten Punkte gut aufgenommen sind,
muss man mit den Kunden (Projektleiter, Chefingenieur, …) das Problem diskutieren und
definieren.
Interview

5.4 Methode für die Informationsbeschaffung (Measure)
Nach der Definitionsphase kommt die Datenerhebungsphase. In diesem Teil wird
die gewählte Forschungsstrategie „Interview“ und die Methode des Fragebogens näher
vorgestellt. Die Auswahl eines Fragebogens mit einer Mischung aus geschlossenen und
offenen Fragen wird begründet und es wird erklärt, warum die erhaltenen Daten quantitativ
und qualitativ ausgewertet werden. Es werden die Überlegungen zur Herstellung des Fragebogens
und zur Auswahl der befragten Personen beschrieben.
Am Anfang muss man eine Methode für die Analyse der IST-Situation wählen.
Diese Methode wird es ermöglichen, viele Informationen über die aktuelle Situation und
die damit verbundenen Herausforderungen zu sammeln. Die endgültige Auswahl ist elementar,
weil die Forschungsmethode dann weitreichende Konsequenzen auf die Ergebnisse,
deren Interpretation und somit auch Auswirkungen auf die Beantwortung der Forschungsfrage
haben wird. Die Erhebung und die Auswertung der Ergebnisse zeigt, ob die
ausgewählten Methoden effektiv waren.
5.4.1 Qualitative oder Quantitative Methoden
Zwei unterschiedliche Datenerhebungsmethoden sind dabei die quantitativen und
die qualitativen Methoden (siehe Abb. 22). In der Quantitativen Forschung geht es darum,
Verhalten in Form von Modellen, Zusammenhängen und zahlenmäßigen Ausprägungen
möglichst genau zu beschreiben und vorhersagbar zu machen (Winter, 2000). Die Auswertung
von einzelnen Fällen sind bei quantitativer Forschungen nicht repräsentativ. Je höher
das Vielzahl an Befragten ist, desto besser ist die Verlässlichkeit der Auswertung (Hoffmann-Riem,
1989).
Objektivität steht als Hauptkriterium der Quantitative Methode. „Innerhalb des
Produktentwicklungsprozesses sind quantitative Methoden immer dann sinnvoll, wenn
mögliche Beurteilungskriterien bekannt sind und ein bekannter Gegenstand quantifiziert
werden soll“ (Winter, 2000). Beispielsweise der Waste in der Produktentwicklung wurde
bereits in verschienen Literaturquellen behandelt (Bauch, 2004), (Oehmen, 2010). Diese
Methoden wurden deshalb, um Objektivität zu gewinnen vollstandardisiert und gut strukturiert
(Hoffmann-Riem, 1989). Die Objektivität der Quantitativen Forschung, die Vielzahl
an Untersuchungseinheiten und die Standardisierung seiner Struktur ermöglichen es, eine
erleichterte Auswertung (z.B. Statistische Auswertung) zu verfassen.
Im Gegensatz dazu spielt die Subjektivität eine große Rolle in der Anwendung der
Qualitativen Methoden. Es wurde nicht eine Generalisierung beschreiben, sondern der Forscher
wird versuchen, den Untersuchungsbereichen zu verstehen. Sie helfen dabei, detaillierte
Verbesserungsvorschläge, zur Erkundung von Ursachen (wie beispielsweise Informationsaustauschprobleme)
zu identifizieren. Aber aufgrund der offenen und sehr individuellen
Antworten ist die Auswertung sowie Interpretation dieser subjektiven Meinungen
schwierig und aufwendig.

Wissenschaftliche Bachelorarbeit 41
Abbildung 22: Qualitative vs. Quantitative Methoden nach Miles (1994)
(größere Darstellung siehe Anhang 9.2)
Nicht eine Methode, sondern eine Kombination von den beiden
Quantitative und qualitative Methoden stehen nicht in Konkurrenz, sondern sind
vielmehr kombinationsfähig (Mayring, 2002). „Das wesentliche Kennzeichen von sogenannten
„Mixed Methods“ Datenerhebungen ist die Entwicklung von Strategien mit dem
Anspruch die Schwächen der einen Methode mit den Stärken der anderen auszubalancieren.
Die Ergänzung einer quantitativen Methode durch eine qualitative Erhebung hat den
Vorteil, dass die quantitativen Ergebnisse vertieft werden können und dass ein gezielterer
Blick auf bestimmte Aspekte dieser Thematik ermöglicht wird“ (Fahlbusch, 2007). Auf
diese Weise werden, wie bereits erwähnt, die Schwächen des einen durch die Stärken des
anderen Verfahrens ergänzt (Gassmann, 2010). Diese Kombination von beiden Methoden
ist im Kontext dieser Arbeit passend. Deshalb wurden Fragebogen (quantitativ Vorgehen)
im Rahmen von Interviews (qualitativ Vorgehen) für die Anwendung im Konzept ausgewählt.
5.4.2 Fragebogen
Der Fragebogen als Quantitative Methode eignet sich besonders gut, um eine Reihe
von Experten oder Konstrukteure über ihrer Sichtweisen, Verbesserungsvorschläge zum
Thema Probleme beim Informationsaustausch in der Produktentwicklung einzuholen. Die
Ergebnisse, die sich aus einer solchen Befragung ergeben, sind von der Gestaltung des
Fragebogens und den Formulierungen der Fragen abhängig (Fahlbusch, 2007). Besonders
wichtig ist, dass die Fragen an die Zielgruppe (Experten / Konstrukteure) der Erhebung
angepasst werden. Die Anonymität des Fragebogens und des Interviews ist wichtig und
erhöht die Möglichkeit Informationen zu kritischen Aspekten zu bekommen. Der Fragebogen
ermöglicht es, in kurzer Zeit eine große Menge an Daten zu sammeln. Die Fragen
wurden klar formuliert und strukturiert, da sonst die Befragten die Fragen falsch verstehen
könnten (Wester, 2006).
Für die Entwicklung des Fragebogens wurden zuerst Fragen gesammelt, die in Bezug
auf die Forschungsfrage des Konzepts interessant erschienen. Dafür ist die Literaturrecherche
wichtig. Dies ermöglicht es, sich vorab einen firmenunabhängigen Überblick
über gängige Probleme zum Thema Informationsaustausch in der Produktentwicklung zu-

sammenzufassen. Wenn man gute Kenntniss der Probleme bekommen hat, kann man Fragen,
zur Identifizierung dieser Probleme mit Hilfe des Fragebogens verfassen. Gleichzeitig
ist darauf zu achten, dass die Fragen verständlich sowie politisch korrekt gestellt wurden
und nicht zu lang sind.
In dem Fragebogen werden Fragen aus den drei Kategorien gestellt: Prozesse,
Werkzeuge und Kommunikation. Diese Kategorisierung ist wichtig, um dadurch den Fragebogen
zu strukturieren und gleichzeitig ähnliche Fragen auszusortieren.
Anschließend erfolgt die Auswahl der Antwortformate, die in einem Fragebogen
verwendet werden können. Es wird unterschieden zwischen geschlossenen Fragen, bei
denen die Antwortmöglichkeiten vorgegeben sind (z. B. sicher/ nicht sicher oder Ursachen
von einer gegebenen Liste ankreuzen) und offenen Fragen, bei denen die Antworten eigenständig
von den Befragten formuliert werden müssen (siehe Abb. 25). Die geschlossene
Fragen haben den Vorteil, dass sie sich leichter auswerten lassen. Man erhält sehr präzise
Antworten zu einem ganz bestimmten Punkt und das Gespräch lässt sich zielgerichtet steuern,
was in der Abschlussphase des Gesprächs gut ist. Der Nachteil ist, dass die Vorgaben
die Antwortmöglichkeiten einschränken. „Die Fragen können sehr einengend und manipulierend
wirken und damit Widerstand provozieren, insbesondere, wenn der Befragten das
Gefühl hat, er kann sich nur zwischen Pest und Cholera entscheiden“ (Giller, 2012). Im
Gegenteil dazu, haben die Befragten mit offenen Fragen mehr Freiheit und können deshalb
Ihre Meinungen detaillieren. Es gibt aber den Nachteile, dass aufgrund der individuellen
Antworten die Auswertung schwieriger und zeitintensiver wird. Sie haben jedoch den Vorteil,
dass sie kurze, individuelle Antworten zulassen (Wacker, 1999). Eine Mischung aus
geschlossenen und offenen Fragen bietet den Vorteil, dass sich der Gesprächspartner freiwillig
führen lässt. Man stellt die Fragen entsprechend dem Typ der Antwort, den man
erwartet und nach den Problemen, die man identifizieren will. Vorteile und Nachteile sehen
Sie auf dem Abb. 23. Zum Beispiel, wenn man die Verlässlichkeit der Information
prüfen will, benutzt man eine geschlossene Frage, weil man eine klare Antwort bekommen
will (sicher/unsicher). Im Gegenteil, wenn man fragt, welche Risiken beim Informationsaustausch
bekannt sind und was die Ursachen sind, erwartet man eine mehr qualitative
Antwort und eine Argumentation mit dem Ansprechpartner. Hierzu bietet sich es an offene
Fragen stellen. Zum Schluss wird der Fragebogen auf Excel abgefasst, so dass man direkt
auf einem Computer antworten kann, was die folgende Auswertung erleicht. Teil des Fragebogens
ist ebenfalls ein SIPOC. Diese SIPOC-Methode von sechs Sigma ermöglicht es,
bevor ein Optimierungsprojekt aufgesetzt wird, alle wichtige Elementen (Lieferanten,
Kunden, Input, Output, ...) eines Prozesses zu identifizieren. Diese Methode liefert den
Input für eine DSM-Matrix, die zur weiteren Analyse von Abhängigkeiten zwischen Entwicklungsprozessen
genützt werden kann. (Eppinger, 2012). (Fragebogen steht im Anhang
9.4)

Wissenschaftliche Bachelorarbeit 43
5.4.3 Interview
Abbildung 23: Geschlossene und offene Fragen ( Wacker, 1999)
In diesem Konzept wird ein halbstrukturiertes Interview gewählt. Bei dieser Vorgehensweise
wird der erstellte Fragebogen, den Forscher als Unterstützung für die Interviews
dienen. An vorher festgelegten Stellen ist es dem Interviewer erlaubt, den Wortlaut
der Fragen zu verändern, Zusatzfragen zu stellen, oder nachzuhaken wenn etwas nicht verstanden
wurde. Der Vorteil dieser Vorgehensweise ist darin zu sehen, dass dem Befragten
ein größerer Antwortspielraum für eigene Formulierungen gegeben wird. Daher geht das
halbstandardisierte Interview mehr in die Tiefe als das standardisierte. Es gibt aber einen
Nachteil. Die Vergleichbarkeit der einzelnen Interviews wird eingeschränkt, weil die Interviews
nicht mehr standardisiert sind. Diese Struktur ist auch zeitaufwendig. Das qualitative
halbstrukturierte Interview ist eine Forschungsmethode, bei der durch verbale Kommunikation
Informationen zu gezielten Themen gesammelt werden können. Der Experte soll
seine Kenntnisse zum Interviewthema äußern.
Im Gegenteil dazu steht der Fragebogen, hier gibt es andere Herausforderungen.
Das Interview verlangt ein direktes Streitgespräch. Deswegen ist es äußerst wichtig eine
Vertrauensbasis zum Ansprechpartner aufzubauen, damit er gelassen und ehrlich antworten
kann. Es ist schwierig diese Vetrauensbasis aufzubauen weil, obwohl die Ergebnisse und
Antworten anonym bleiben, für den Forscher keine Anonymität mehr besteht. Deswegen
ist es wichtig gut zu erklären, warum man das Interview führt, wie die Ergebnisse verarbeiten
werden und, wie die Anonymität des Ansprechspartners gewahrt bleibt. Damit wird das
Risiko, dass er nicht antworten will vermindert und Interaktionsbarrieren abgebaut. Bei der
Durchführung des Interviews sollte es vermieden werden, dass der Fragebogen keine Suggestive
oder Ja-/Nein-Antworten ermöglicht. Außerdem sollten die Fragen klar sowie einfach
formuliert sein. Am Schluss sollte der Befragte die Möglichkeit bekommen das Interview
zu ergänzen und weitere ihm als wichtig erscheinende Punkte anzusprechen. (Fichten/
Wagner u.a. 2005). Im Vergleich zum Fragebogen bestehen die Vorteile des Interviews
in der Möglichkeit eine mehr qualitative Antwort zu bekommen. Durch einen Austausch
von Antworten und Nachfragen sowie Verständnisfragen kann man bestimmte Aspekte
oder wichtige Fragen vertiefen, wodurch detailliertere Informationen gesammelt
werden können. Aus diesem Grund wird das Interview oftmals als ergänzende Forschungsmethode
eingesetzt. Ein Nachteil ist der hohe Arbeits- und Zeitaufwand, den dieses
Verfahren mit sich bringt. (Burkard, 2000, 114). Aus den Erfahrungen der ersten Interviews
wird die Fragestellung im Fragebogen bzw. Interview kontinuierlich verbessert. Es

ermöglicht, den Fragebogen zu prüfen und eventuelle unklare oder unnötige Fragen zu
verbessern oder zu entfernen. Dieser Teil ist auch wichtig, denn wenn der Ansprechpartner
eine Frage nicht gut versteht, wird es die Qualität der Antwort und der tatsächlichen Ergebnisse
vermindern oder er wird sich beengt fühlen.
Die Kombination eines Fragebogens mit einem qualitativen halbstrukturierten Interview
ist explizit an das Konzept dieser Bachelorarbeit angepasst. Durch eine Mischung
aus geschlossenen und offenen Fragen wird der Experte zielgerichtet interviewt. Dabei ist
es wichtig, dass der Forscher auf die Äußerungen des Experten spontan eingeht, indem er
durch vertiefende Fragen die Aussagen aufgreift, Rückfragen stellt oder um ergänzende
Erläuterungen bittet. (Fichten, 2005). Die Durchführung eines Interviews benötigt zwischen
ein und eineinhalb Stunden. Diese Forschungsmethode (Fragebogen + Interview)
ermöglicht es, eine große Anzahl von Problemen der IST-Situation beim Informationsaustausch
zwischen Entwicklungsprozessen zu identifizieren. Im Anschluss kommen die Kategorisierung
und die Identifizierung der Ursachen.
5.5 Ursachen als Identifizierungskriterien der Wastetyps (Analyse)
Abbildung 24: Von Ursachen nach Wastetyp (nach Bauch)
Die Probleme, die mit den Interviews gesammelt wurden, müssen in dieser Phase
analysiert werden. Dafür muss im ersten Schritt die Ursachen dieser Probleme identifiziert
werden und in einem zweiten Schritt, die Probleme mit Hilfe deren Ursachen in Abhängigkeit
von den Wastetyp kategorisiert werden (siehe Abb. 24). Bauch, Oehmen, Graebsch,
Lindemann sind Autoren, die eine Verbindung zwischen den Ursachen eines Problems und
dem Wastetyp ziehen. Mit Hilfe der Literatur kann man bereits einen sehr guten Überblick
zum Thema "Zuordnung Ursachen zu Waste" bekommen.

Wissenschaftliche Bachelorarbeit 45
5.6 Statistische Auswertung (Analyse)
Im weiteren gilt es den am „meisten vorhandenen“ Waste zu identifizieren. Im folgenden
Abschnitt wird das Vorgehen bei der Auswertung der Datenerhebungsmethoden
beschrieben. Die statistische Auswertung der Ergebnisse ist ein wichtiger Schritt für die
anschließende Analyse, weil sie einen guten Blick auf den gegenwärtigen Stand des Prozesses
zeigt und eine Priorisierung der Verbesserungsaktionen vorschlägt. Dafür ist die
Nutzung eines Fragebogens für das Konzept sinnvoll, weil er eine statistische Auswertung
ermöglicht. Jede Ursache eines Problems, das nach der Datenerhebungsmethode identifiziert
wurde, wird einem der 10 Wastetypen zugeordnet. Diese Verbindung zwischen den
Fragen und dem durch die Interviews identifizierten Wastes wird in einer Excel Tabelle
dargestellt (siehe Abb. 25). In dieser wurden ganz links im Blatt alle Fragen stichpunktartig
untereinander angeordnet. Des weiteren gibt es zehn Spalten, eine für jeden Waste
(waiting, overporcessing,…). Das Vorgehen, um eine Verbindung zwischen den Fragen
und dem Waste herzustellen, ist folgendes: Während den Interviews benutzt man die Fragen,
um gezielte Probleme zu identifizieren. Nach den Interviews, benutzt man die Antworten,
um die Ursachen dieser Probleme zu identifizieren. Zum Schluss ermöglichen es
diese Ursachen, den Waste zu ordnen. Jedes Mal, wenn ein Zusammenhang zwischen Ursachen
und Wirkung identifiziert wird, wird dieser durch ankreuzen des Schnittpunktes zwischen Zeile
(Frage) und Spalte (Waste) kenntlich gemacht.
Abbildung 25: Beziehungen zwischen Fragen und Wastetypen (Anhang 9.3)
Wenn man die Tabelle für alle Fragen ausgefüllt hat, wird errechnet, wie viele
Kreuze jeder Waste bekommen hat. Diese Ergebnisse werden in Prozent konvertiert,
so dass sich daraus ableiten lässt, welcher Waste im Prozess am meisten vorhanden
ist (Abb. 26). Für die Auswertung des Fragebogens bietet sich die Darstellung
der Ergebnisse in einer Diagrammform an. Diese Abbildung zeigt ein Beispiel
von einer möglichen Auswertung.

Abbildung 26: Statistische Auswertung (Anhang 9.5)
5.7 Value method und lean enablers
Nach der Statistischen Auswertung muss man die erhaltenen Ergebnisse benutzen,
um Lösungen für die Reduzierung von Problemen beim Informationsaustausch vorzuschlagen.
Es gibt zwei Schritte im Vorgehen zur Optimierung.
Value Methode : sind generelle Methoden (Fünf Lean Prinzipien, Kommunikation,
Standardization, ...), deren Rolle die Verminderung der Auswirkung der Waste auf den
Produktentwicklung Prozessen ist.
Lean Enablers : erklären die unterschiedliche Schritten, die ermöglichen, eine Value
Methode anzuwenden.
Value method
Nach McManus (2005) „Lean Prinzipien stellen eine breite Reihe von Werkzeugen zur
Verfügung, die es zum Ziel haben, den Wert zu vergrößern, wie Standardisierung von Prozessen ,
Flow Prinzip, Pull Prinzip und wirksame Kommunikation. Diese "Werkzeuge" werden Value
Methods (Wertschöpfungsmethoden) genannt. Mehrere Autoren haben die Value Methoden in
der Produktentwicklung (McManus, 2005), (Zhao, 2008), (Hoppemann, 2009 studiert und definiert.
Diese Value Methoden werden entsprechend der Literatur zusammengefasst und mit einem
Waste in Verbindung gebracht. Dafür werden sie in Abhängigkeit Ihrer Wirkungen auf den Waste
dargestellt. Die Value Methoden sind mehr oder weniger geeignet je nach dem Typ von Waste.
Die Abbildung darunter (Abb. 27) zeigt, wie man die Auswirkungen von Value Methoden auf
den Waste mit Hilfe einer Excel Tabelle darstellen kann. Mittels dieser Tabelle kann nach der
Priorisierung des Wastes (mit Hilfe statistischer Auswertung) direkt identifiziert werden, welche
Value Methoden sich für eine Prozessverbesserung eignen. (siehe Abb. 27).
Abbildung 27: Auswirkungen von Value Methoden auf wastetyp (Anhang 9.6)

Wissenschaftliche Bachelorarbeit 47
Lean enablers
Wenn man die relevanten Value Methoden für Verbesserungen im Entwicklungsprozess
identifiziert hat, ist es jedoch nicht offensichtlich, wie eine konkrete Strategie oder
Umsetzung der Methode auf den Prozess auszusehen hat. Dafür muss man einen Schritt
tiefer ins Detail gehen. Jede Value Methode hat unterschiedliche Lean Enablers, die erklären,
wie die betroffene Value Methode anzuwenden ist. Es ist wichtig zu wissen, dass das
Pull Prinzip Waste im Entwicklungsprozess minimieren kann. Aber wie ist das Pull Prinzip
anzubringen? Dies muss mit den Lean Enablers detailliert werden, welche in der Literatur
gefunden werden können. Joseph Oehmen (2012) hat zum Beispiel " The Guide to Lean
enablers for Managing Engineering Programs" geschrieben. In diesem Buch stehen viele
Lean Enablers, und die Problemen, auf die sie antworten. Die Abbildungen 28 und 29 sind
andere Beispielen von der “INCOSE Lean Systems Engineering Working Group” oder
von “Laura A. Garza (1992)”, die auch Lean Enablers für Value Methoden (Set based Engineering
mit Simultaneous engineering / Map the value stream) geben. The International
Council on System Engineering (INCOSE, 2010) ist eine gemeinnützige Organisation, die
gegründet wurde, um interdisziplinäre Grundsätze und Methoden zu entwickeln und zu
verbreiten, die die Entwicklung von erfolgreichen Systemen (Qualität, Kosten, Entwicklungszeit)
ermöglicht.
Diese Experten adressieren ähnliche Problemstellungen im Bereich der interdisziplinären
Produktentwicklung, und Ihre Lean Enablers liefern eine gute Orientierung für die
Anwendung dieses zweiten Schrittes des Konzepts.
Abbildung 28: Value stream enablers INCOSE (2010)

Abbildung 29: Simultaneous engineering enablers Laura A. Garza (1992)
5.8 Parametern (Control)
Während eines Projektes gibt es eine Kontrollphase, in der die Effizienz der Verbesserung
geprüft werden soll. Um die Effizienz einer Methode zu zeigen, muss am Anfang
einen Ansatzpunkt bestimmt werden, bei dem Parameter identifiziert und gemessen
werden können. Dafür muss man wissen, auf welche Parameter (siehe Abb. 30) man eine
Auswirkung erzeugen will und dies auch messen kann.
Abbildung 30: Parameter in der Produktentwicklungsprozess nach Chase (2000)

Wissenschaftliche Bachelorarbeit 49
Es ist viel schwieriger Parameter in verteilten Organisationen mit interdisziplinären
und parallel laufenden Entwicklungsprozessen zu messen als in der Produktion, da sich
mitunter Maßnahmen in der Informationsverarbeitung nicht isoliert betrachtet werden können.
In diesem Konzept wird eine Excel Tabelle (siehe Abb. 31) benutzt, um zu identifizieren,
ob es viele oder keine Verbesserungsmöglichkeiten gibt. Auf der linke Seite, stehen
die unterschiedlichen Tasks (Aufgaben). Jede Information, die zwischen Abteilungen ausgetauscht
wird, ist in der Tabelle dargestellt. Zum Beispiel, wenn eine Information von
Abteilung A nach Abteilung B geschickt werden muss, schreibt man „I AB“. Die Nummer
ist nur nötig, um die Informationen zu unterscheiden. Zum Beispiel wenn zwei Informationen
müssen zwischen Task A und Task B ausgetauscht werden, dann schreibt man I1 AB
und I2 AB. Es gibt ein Feld für jeden Parameter. Mit Hilfe dieses Diagrammes und mittels
einer farbigen Kodierung kann geprüft werden, ob es Verbesserungsmöglichkeiten für den
Informationsaustausch einer Information gibt, in Abhängigkeit von den wichtigsten Parametern.
Nach der Identifizierung des Ansatzpunktes kann man die gewählten Value Methoden
anwenden. Dann kann die Excel Tabelle erneut genutzt werden, um bessere Parameter
als Ziel festzulegen. Die Excel Tabelle des Ansatzpunktes wird während des Verbesserungsprojekts
mit dem Ziel verglichen, so dass man sieht, ob die Value Methode gut für
die Problemstellung des Prozess geeignet ist.
Task und Informationen
Kosten
Zeit
# von Iterationen
Parametern
# von Fehlern
% von variabilität
Task A 0 9
Es gibt viele Verbesserungsmöglichkeiten
I1 AB 0 3
Es gibt Verbesserungsmöglichkeiten
I2 AB 9 3 0
Sehr gute Informationsaustausch
I3 AC 0 0
Task B 3
I1 BD 9 3 0
Task C 9 9 Optimierungspotenzial
I1 CA 0 0 gering
I2 CA 0 0 3 mittler hoch
I3 CB 3 9 sehr hoch
I4 CH 3 9 3 3 0
Task D 3 0
I1 DB 0 3 3
I2 DE
Task E
9 3 0 3
I1 EA 3 3
I2 ED 3 3 3
I3 ED 0
Task F 0 9 0
I1 FB 9
I2 FG 0 0 9 9
I3 FG 0
Task G 9 9
I1 GA 0 3 0
I2 GE 0
Task H 3 0 3 9 0
I1 HB 9
I2 HB 3 3 0
I3 HB 0 3
I4 HE 3 0 3
Abbildung 31: Analyse der Verbesserung nach Variation der Parametern (Anhang 9.7)
5.9 Gesamt Konzept
Dieses Konzept (Abb. 35) stellt eine Methode für die Verminderung der Problemen
beim Informationsaustausch zwischen zwei unterschiedlichen Disziplinen (z.B SE / Struktur)
vor mit Hilfe von Lean Engineering Prinzipien. Zu Beginn steht die Analyse der IST-
Situation, wobei Probleme in Produktentwicklungsabteilungen identifiziert und analysiert
werden. Hierzu kommen zwei Methoden zur Anwendung. Die erste ist die Erstellung eines
Fragebogens und die zweite ist ein Interview. Der Fragebogen muss einige wichtige Eigenschaften
haben. Zuerst muss man die relevanten Zielgruppen identifizieren. Man muss die
Ziele definieren, wofür der Fragebogen erstellt wird. Im Rahmen der vorliegenden Arbeit
werden Experten, Konstrukteure und Projektleitern aus unterschiedlichen Disziplinen und
Entwicklungsabteilungen befragt. Die Identifizierung den Zielgruppen ermöglicht zu wissen,
ob fachspezifisches Vokabular in dem Fragebogen verwendbar ist. Dann wird der For-
Qualität

scher offene und geschlossene Fragen abwechselnd aufeinander folgen lassen. Es ermöglicht
einerseits eine statistische Auswertung durch gezielte Fragen zu bekommen und andererseits
bessere Antworten von den Experten zu bekommen. Zum Schluss muss der Forscher
einen Überblick von den potentiellen Herausforderungen bekommen. Die Fragen
müssen so gestellt sein, dass Sie schnell die Identifizierung eines Problems ermöglichen.
Dafür wurde eine firmen- und branchenunabhängige Literaturrecherche durchgeführt. Der
Fragebogen muss die Identifizierung von allen Problemen beim Informationsaustausch in
der Produktentwicklung der Firma ermöglichen. Wenn man die häufigsten Probleme mit
Hilfe der Literatur identifiziert hat, vermindert man das Risiko, Problemen zu vergessen.
Der Fragebogen wird als Basis für halbstrukturierte Durchführung Interviews eingesetzt.
Diese Mischung von quantitativer und qualitativer Methoden hat viele Vorteile. Zuerst
kann man erklären, wofür die Fragen benützt werden und wie die Antworten verarbeitet
werden. Dann ermöglicht es einerseits eine statistische Auswertung zu entwickeln und andererseits
eine qualitative Diskussion mit den Ansprechpartner zu führen, um besser und
deutlicher, die Ursachen den erhaltenen Problemen zu verstehen. Zum Schluss bekommt
man eine Gewichtung der Probleme für den Ansprechpartner. So können die Probleme
kategorisiert werden. Für die Kategorisierung der Probleme werden die Prinzipien von
Lean Engineering benutzt. Man wird die Lean Philosophie anwenden, durch ein Wahl von
unterschiedlichen Waste (Overprocessing, defects,...) (Womack und J., 1996). Wenn der
Fragebogen verfasst ist und die Identifizierung der Mehrzahl der Probleme ermöglicht,
dann kann man die Interviews verfassen. Die ersten Interviews werden zur Verifizierung
und Verbesserung des Fragebogens genützt. Danach beginnt man die Interviews von einer
repräsentativen Anzahl an Experten, wobei die Anzahl der Interviewpartner von der Studie
abhängt. Nach den Interviews hat man möglicherweise unterschiedliche Probleme für jede
Fragen bekommen. Diese Probleme müssen mit Hilfe des gewählten Wastes nach Lean
Engineering kategorisiert werden. Dafür wird ein Excel Tabelle (Abb. 25) genützt, um die
Verbindung zwischen den Fragen des Fragebogens und den jeweiligen Waste darzustellen.
Aus der Literaturrecherche wurde ermittelt, welche Probleme mit welchen Fragen identifiziert
werden können. Die qualitativen Antworten, sowie die Diskussionen oder die Beispiel
aus der Literatur ermöglichen die Ursachen dieser Probleme zu identifizieren. Deswegen
ist möglich eine Verbindung zwischen Ursachen, Problemen und Fragen auf zu zeigen. Die
Abbildung 32 zeigt die Verbindungen zwischen Ursachen und den Wastetypen. Die Excel
Tabelle zeigt die Verbindung zwischen Waste und Fragen durch die identifizierten Problemen
Ursachen. Für jede Fragen des Fragebogens analysiert man die Antworten. Der Forscher
muss die Ursachen dieser Probleme analysieren oder ableiten. Am Ende der Analysen
kann eine Beziehung zwischen Ursachen mit Wastetypen gezogen werden. Jedes mal,
wenn eine Verbindung zwischen einer Frage und einen Waste mit diesem Verfahren identifiziert
ist, kreuzt man ein Feld in der Tabelle (Abb. 25) an. Wenn die Tabelle ausgefüllt ist,
kann man die Zahl von Kreuzen pro Waste auswerten und die Ergebnissen in Prozent
konvertieren. Mit Hilfe einer Diagrammdarstellung in Excel kann man eine statistische
Auswertung der Ergebnissen bekommen. (Prozent von Verschwendungen in dem Prozess
in Abhängigkeit von dem Wastetyp nach Lean Engineering Prinzipien). Diese Auswertung
ermöglicht die wichtigsten Waste in dem Prozess zu identifizieren und eine auf die Problemursachen
ausgerichtete Verbesserungsmethode zu wählen. Diese Auswertung wird für
jedes Interview erstellt. Aus der Literaturrecherche ist bekannt welche „Value Methoden“
für welchen Wastetypen anzuwenden sind. Die Value Methoden (Pull Prinzip, Kommunikation,
Standardisation,...) sind Methoden, die eine Verminderung der Wastes in dem Prozess
bringen. Sie sind aber zu generell, um unmittelbar als eine Lösung anwendbar zu sein.
Für jede Value Methode, gibt es vielen Lean Enablers. Diese Lean Enablers detaillieren
welche Schritte oder welche Verfahren wichtig sind, um eine Value Methode anzuwenden.
Organisation wie INCOSE oder das Handbuch von Oehmen sind Beispiel aus der Literatur,
in denen man Lean Enablers für die jeweiligen Value Methoden finden kann. Wenn

Wissenschaftliche Bachelorarbeit 51
man eine Value Methode gewählt hat, sucht man in der Literatur, die jeweiligen Lean
Enablers. Diese Lean Enablers werden dann, auf dem Prozess angewendet, um den Waste
zu vermindern und Value zu gewinnen. Dieser Zusammenhang zwischen Ursachen, Wastetypen,
Value Methoden und Lean Enablers ist noch einmal in Abb. 32 explizit zusammengefasst
und stellt den Kern des vorgestellten Konzeptes dar. Aber die effiziente Anwendung
dieser Lean Enablers muss durch Parameter schon während der Umsetzung überwacht
werden. Dafür sind die Parameter (Zahl von Fehlern, Zeit, Kosten, Zahl von Iteration,...)
wichtig. Jede Value Methode hat Parameter auf die sie einen Einfluss ausübt. Diese
Parameter müssen vor, während und nach der Optimierung des Prozess gemessen werden.
Die kann unter Umständen zeit- und kostaufwendig sein, aber es spielt eine Hauptrolle in
der Kontrollphase. So kann man während der Optimierung, die Parameter bevor und nach
der Anwendung der Value Methoden vergleichen.
Incompleteness
Poor relevance,
objectivity,
conciseness
Information
deterioration
during
communication
erroneous or
incomplete
information
Incomplete
content
Frequent
interruptions
Product
feature
inventory
Team members not
colocated
Incompatible software
suites
Poorly designed user
interface
Outdated, obsolete
information
Lack of training
Reformatting
Lack of direct access
Hand-off
Manual data conversion
Unecessary
testing
equipment and
prototypes
excessive
data storage
Information hunting
Insufficient
knowledge
sharing
Difficult to
understand
Complicated retrieval
No learning
from
practice
Incomplete understanding of
stakeholder requirements
Partial information
Motion
Deficient
information quality
Multitasking
Organizationnal
/ Process
barriers
Lack of control
Creation of unecessary
data and information
Inventory
Lack of reviews,
test, verifications
too much information to
sort through
Interruptions in process
Information pushed to
wrong people
DSM
Insufficient
communication channels
Flow
Need for information or knowledge, data
delivered
Unclear or shiftings targets
Defects
pull
lean enablers 1
lean
enablers n Value lean
enablers 2
Miscommunication of
information
No learning of basic
knowledge
Reworking product or processes
Haste
Unclear
responsability
lean enablers 3
Lack of standard for
data conversion
Test then design
redundant tasks
Reinvention, no standard for
the reuse of information
Processing defective information
(undiscovered errors)
Poor synchronization as
regards contents
Working with wrong
level of detail
Overprocessing
standardisation
Ursachen
Decision criteria unclear
Value-Method
communication
Overproduction
Poor
synchronization
as regards time
and capacity
creation of
unecessary data and
information
Overdissemination of
information
Lack of needed
information
unnecessary features
and processes
Transportation
Insuficient IT-tools
/ System
Waiting
Suspect quality
of information
excessive transactions
excessive approvals
unnecessary detail
and accuracy
Waste
Untimely updating
of data basis
Use of inappropriate
tools/methods
innapropriate use of
competency
Delivering info too early
Poorly designed or
executed process to
provide information
Handoffs
Stop and go tasks
Inefficient work environment
Ineffective communication
Security issues
Inefficient use of tools
Excessive data traffic
Lack of direct information access
Information incompatibility
no open information
sharing
poor compatibility, capacity
Late delivery of
information
low capability
Lack of access
Wait times due to
other wastes
Information
waiting for
people
redundant tasks
Strong dependencies
Low performance
Multiple approvals
People waiting for
capacity available
Abbildung 32: Gesamt Konzept (Anhang 9.8) in Anlehnung an Bauch (2004)

6 ANWENDUNG DES KONZEPTS AUF EINE FALLSTUDIE
6.1 Durchführung der Interview und Analyse der Ist-Situation
Das Ziel dieses Teiles ist die Anwendung des Konzepts unter realistischen Bedingungen.
Das Fachkonzept wurde in einem Zeitraum von zwei Monaten im Unternehmen
Cassidian in Manching durchgeführt. Hierbei wurden Konstrukteure und Experten im Bereich
SE und M-/E-Eng. zum Thema „Probleme beim Informationsaustausch“ zwischen
zwei Disziplinen befragt. Die Durchführung einer statistischen Auswertung der Interviews
bietet eine gute Übersicht der Prozessprobleme. Die folgenden drei Abbildungen ergaben
sich aus den Ergebnissen der Interviews (Abb. 33, Abb. 34, Abb. 35).
Abbildung 33: Beziehung Frage zu Waste (erste Auswertung)
Abbildung 34: Beziehung Frage zu Waste (zweite Auswertung)

Wissenschaftliche Bachelorarbeit 53
Abbildung 35: Beziehung Frage zu Waste (dritte Auswertung)
Hier sieht man die Vorteile die sich aus der statistischen Auswertung ergeben. Man
bekommt ein zuverlässiges Bild der Wastes in dem Prozess. Die Tendenz ist dieselbe für
alle drei Fragebögen. "Waiting" ist der Hauptgrund des Werteverlusts im Informationsaustauschsprozess
zwischen den Disziplinen. Anschließend kommt "Motion" und "Miscommunication
of information". Aus diesem Grund adressiert die Arbeit im weiteren Verlauf
den Waste „Waiting“ und zugehörige Value Methoden. . Dieser Waste wird als Beispiel
für die Anwendung des Konzeptes gewählt.
6.2 Prototypische Anwendung des Konzepts an Hand des Waste "waiting"
Die Auswahl der Value Methode zur Prozessverbesserung ist abhängig von verschiedenen
Wastes. Aus folgender Excel-Tabelle gehen drei relevante Value Methoden für
den Waste „Waiting“ hervor. (siehe Abbildung 36). Es handelt sich hierbei um das Pull
Prinzip, das Flow Prinzip und das Simultaneous Engineering. Das Simultaneous Engineering
wird schon seit langer Zeit bei Cassidian angewendet, um die Produktentwicklungsprozesse
zu verkürzen. Diese Methode ist aber auch ein wichtiger Grund für Probleme im
Informationsaustausch (siehe Kapitel "Simultaneous Engineering"). Deswegen werden das
Pull Prinzip und das Flow Prinzip in diesem Konzept angewendet. Die Tabelle (siehe Abb.
36) zeigt welche Parameter für diese Methoden relevant sind (Zeit, Qualität, % der Beständen,
Wartezeit, # von Fehlern). Diese Parameter können in der Excel-Tabelle der Kontrollphase
(siehe Abbildung 31) abgelesen werden. Die betroffenen Tasks (Tätigkeiten) werden
auch mit den ausgetauschten Informationen hinzugefügt.

Suspect quality of
the information
delivering info too
early
Late delivery of
information
Lack of access
Untimely updating of
data bases
Multiple approvals
Poorly designed or
executed process
to provide
information
people waiting for
capacity available
(human or
machine)
Information waiting
for people
Strong
dependencies
Low performance
Wait times due to
other wastes
Waiting
Simultaneous engineering,
management of resources,
pull, flow, communication
Time, quality, % of inventory, % of resource
utility, waiting time, errors
Abbildung 36: Parameter und Value Methode in Abhängigkeit der Wastetypen
Die sogenannten Value Methoden sind aber zu allgemein, um Sie unmittelbar in
den Disziplinen anwenden zu können. Ein Expert oder Konstrukteur kann nur mit dem
Begriff von Pull Prinzip oder Flow Prinzip allein keine Verbesserung in seinem Projekt
erzielen. Hierfür braucht er detaillierteres Wissen über die dazugehörigen Schritte. Lean
Enablers (siehe Kapitel 5.7) werden ausführlich beschreibt, um die Vorgehensweisen der
Anwendungen für die Optimierungsprojekte zu erklären. Die Abbildung (Abb. 37) erklärt
das Verbesserungskonzept und wie die Value Methoden nach INCOSE (2010) hierarchisch
gegliedert sind.

Wissenschaftliche Bachelorarbeit 55
Value Methode
Lean enabler
Subenablers
VALUE
Value Methode
1. Lean Enabler
• Subenabler 1
• Subenabler 2
Abbildung 37: Verbesserungskonzept
Flow-Prinzip nach „ Lean Enablers for Systems Engineering“ (Incose, 2010)
1. Zuerst muss der Kundenbedarf früh und wiederholt während der Durchführung
identifiziert und priorisiert werden:
• Formelle Anforderungsdokumente werden durch mündliche Erläuterungen
der Bedürfnisse ergänzt.
• Wirksame Kommunikationskanäle werden für die Einhaltung der Voraussetzungen
geschaffen (z.B. können Kundenteilnahmen in der Entwicklung
mit eingebunden werden)
• Der Gebrauch von architektonischen Methoden für Systemdarstellungen
(3D integrierte CAD-Tools, Prototypen, Modelle, Simulationen
und Softwaredesignwerkzeuge) kann einen Informationsaustausch mit
Kunden ermöglichen.
• Gebrauch von schnellen Lerntechniken (Prototypen, Tests, Digitalvorzusammenbau,
spiralförmige Entwicklung, Modelle, und Simulation)
2. „Front load architectural design“ und Implementierung:
• Mehrere Konzepte, Architekturen und Designs werden früh erforscht.
• Gebrauch von einer klaren architektonischen Beschreibung der ausgewählten
Lösung, um kommerzielle und ingenieurswissenschaftliche
Strukturen zu planen.

3. Gebrauch von Systems Engineering, um Verantwortung für die Koordination
von PD-Tätigkeiten zu übernehmen:
• Die effiziente Zusammenarbeit zwischen SE und anderen PD Ingenieuren
wird gefördert.
• SE wird benutzt, um alle anderen Ingenieure verschiedener Disziplinen
als Partner und innere Kunden zu betrachten.
4. Gebrauch von effizienter und wirksamer Kommunikation und Koordination:
• Verbessert die Koordination des Informationsflusses (eine der Hauptverantwortung
von Lean-SE).
• Beziehungen werden im gesamten Unternehmen unterhalten um effiziente
Kommunikation und Koordination zwischen den verschiedenen
Abteilungen des Unternehmens und Lieferanten zu erleichtern.
• Gebrauch von häufiger, rechtzeitiger, offener und ehrlicher Kommunikation.
• Alle Erwartungen und Bedürfnisse der Kunden werden deutlich kommuniziert.
5. Programmschritte müssen für alle sichtbar sein:
• Arbeitsfortschritte müssen transparent und leicht zu verstehen sein (einschließlich
des Außenkunden).
• Gebrauch von Visual Controls für die geeigneteste Präsentation in öffentlichen
Räumen (Computerschirme sollten vermieden werden)
• Die Entwicklung eines Systems, das Fehler und Verspätungen entdeckt.
6. Gebrauch von Lean-Werkzeugen:
• Gebrauch von Lean-Werkzeugen, um den Informationsfluss zu fördern
und Hand-Offs (z.B. Standardisierung, Arbeitszellen, Ausbildung, usw.)
zu optimieren.
• Gebrauch von einer minimalen Zahl an Werkzeugen.
• Die Zahl von Änderungen muss verringert und die Aktualisierung der
Daten muss zentral kontrolliert werden, um Informationsprobleme zu
verhindern.
• Die Technologie muss mit dem Entwicklungsprozess abgestimmt sein,
um sich an Entwickler und Prozesse anzupassen.
Pull-Prinzip nach „ Lean Enablers for Systems Engineering“ (Incose, 2010)
7. Wertschöpfende Tasks und Outputs werden verwendet und der Rest wird als
Waste angesehen:
• Um Mitarbeiter auf die Erkennung von inneren Kunden (Empfänger)
sowie Lieferanten (Geber) zu trainieren, werden SIPOC-Modelle (Lieferanten,
Input, Prozess, Output, Kunde) verwendet. Sie ermöglichen
ein besseres Verständnis der Prozesse.
• Der Kontakt zum inneren Kunden sollte während der Aufgabenausführung
erhalten bleiben.

Wissenschaftliche Bachelorarbeit 57
Diese Lean Enablers werden für die Minderung der Wastes "Waiting" in dem Entwicklungsprozess
benutzt.
6.3 Parameter als Kontrollmittel der ermittelten Verbesserungsaktionen
Während der Anwendung dieser Lean Enablers muss die Effizienz ihrer Umsetzung
überprüft werden. Hierfür werden die Parameter, die am Anfang gemessen wurden,
mit den neuen Parametern verglichen. Wenn die Wartezeiten und die Anzahl der Fehler
sinken und die Qualität ansteigt, kann daraus geschlossen werden, dass die Methode für die
Optimierung des Prozesses geeignet war. Diese Value Methoden sind auch für weitere
Wastes geeignet. Aus der Kontrollphase lässt sich schließen, welchen Einfluss (positiv
oder negativ) die Value Methoden auf die anderen Wastes haben können.
6.4 Interpretation der Ergebnisse
Das Ziel war die Erstellung eines Konzepts, zur Verbesserung der Probleme beim
Informationsaustausch in der Produktentwicklung. Im Zeitraum von 2 Monaten wurden
Konstrukteure und Experten im Bereich SE oder M-/E-Eng. im Rahmen dieses Themas
interviewt. Ein fragebogen gestützes Interview sollte während der Durchführung helfen,
die verantwortlichen Faktoren (Wastes) der Probleme beim Informationsaustausch leichter
zu identifizieren. Diese Datenerhebungsmethode ermöglichte statistische Ergebnisse in
Form von Diagrammen zu erlangen. Daraufhin konnten nach jedem Interview ein Diagramm
mit dem entsprechenden Prozentsatz der Waste-Typen erstellt werden. Die Auswertung
ergab den Waste-Typ „Waiting“ als einen der häufigsten Wastes und sollte deshalb
im weiteren Verlauf der Arbeit untersucht werden. Das Konzept wurde daher auf den
Waste „Waiting“ in der Fallstudie angewendet und überprüft. Die Excell-Tabelle (Abb. 36)
ermöglichte es die relevanten Value Methoden, mit Ihren Parametern zu identifizieren. Das
Flow-Prinzip und das Pull-Prinzip wurden für die Optimierung des Prozesses ausgewählt.
Da Value Methoden sehr allgemein sind, muss das Konzept eine detaillierte Anwendung
für diese Value Methoden vorschlagen. Hierfür werden Lean Enablers und Subenablers
ausführlich beschrieben, um Prozessexperten die Anwendung der Value Methoden zu erleichtern.
Abschließend kann gesagt werden, dass das Konzept sein Ziel erfüllt hat, da sie
eine Identifizierung und Kategorisierung der Wastes ermöglichte. Ebenfalls konnten die
Value Methoden, abhängig von ihren Parametern, detailliert gezeigt werden. Zum Schluss
schlug das Konzept eine Initiative für die Anwendung dieser Value Methoden vor und
stellte eine Methode zur Überprüfung der Effizienz der Value Methoden mit Hilfe ihrer
Parameter dar.

7 ZUSAMMENFASSUNG
Heutzutage ist es ausschlaggebend die Produktentwicklungszeiten zu senken. Dies
ermöglicht es der Konkurrenz einen Schritt voraus zu sein und schneller auf Kundenbedürfnisse
zu antworten. Dafür wurden die Produktentwicklungsprozesse mit Hilfe des Simultaneous
Engineering parallelisiert. Diese Methode hat allerdings auch einen komplexen
Informationsaustausch zwischen den Disziplinen und Abteilungen als Nachteil.
Informationsaustauschprobleme haben einen großen Einfluss auf die Effizienz von
Ingenieuren, die im Produktentwicklungsprozess tätig sind. Je mehr Informationsaustauschprobleme
es gibt, desto mehr resultieren längere Produktentwicklungszeiten daraus.
Mögliche Ursachen sind zum Beispiel unnötige Iterationen, Mangel an Kommunikation,
überflüssige Aufgaben, usw. Wenn diese Informationsaustauschprobleme nicht identifiziert
und vermindert werden können, verringert sich die Effizienz des Simultaneous Engineering
auf den Produktentwicklungsprozess. Das Ziel dieser Bachelorarbeit war deshalb
die Konzepterstellung zur Untersuchung von Problemen beim Informationsaustausch zwischen
zwei Disziplinen.
Lean Manufacturing nach Toyota hat sich in der Industrie bewährt. Produktentwicklung
interessiert sich nicht für den Materialtransport, sondern für die Generierung und
Verarbeitung von Information. Aus diesem Grund ist Produktentwicklung eine "informationsgenerierende
Fabrik" (Bauch, 2004). Es war daher am Anfang wichtig, eine deutliche
Definition der Information in der Produktentwicklung festzulegen. Drei verschiedene Typen
von Information wurden daraus abgegrenzt (strukturierte, halb-strukturierte, nicht
strukturierte Information).
Eine Herausforderung dieser Bachelorarbeit war die Anwendung der Lean Philosophie
und insbesondere die Identifizierung der Waste-Kategorien in der Produktentwicklung.
Nach der Literatur existiert eine Beziehung zwischen Waste aus dem Lean Manufacturing
(mit Material) und Waste aus dem Lean Engineering (mit Information). Die Definition
dieser Waste-Kategorien sind allerdings je nach Autoren unterschiedlich und hängen
von Branche und Produkttypen ab. Deshalb wurde zehn Waste-Kategorien wurden für die
Anwendung in diesem Konzeptes zusammengestellt, die eine Kategorisierung der Ursachen
von Informationsaustauschproblemen ermöglichen.
Zur Identifizierung der Ursachen war es zuerst wichtig eine Datenerhebungsmethode
zu wählen, die trotzdem die Auffassung der Experten und Konstrukteure berücksichtigte.
Ein Fragebogen sollte die Durchführung der Interviews erleichtern, da es durch gezielte
Fragen möglich war statistische Ergebnisse und qualitativ hochwertige Antworten zu erhalten
Aus Mangel an wohlfundierten Informationen (Simultaneous Engineering), entstehen
oft Werteverluste in Form eines "Rework", welches zusammen mit der Kommunikation ein
großes Thema in der Verbesserung eines Produktentwicklungsprozesses ist. Grund ist, dass
Konstrukteure oder Experten viel Zeit für Informationssuche aufwenden.. Übererfüllung
von Aufgaben (Overproduction) sind z.B. ebenfalls ein Grund dieser Probleme, da viel
Zeit für nicht erforderliche Informationen vergeudet wird. Nach verschiedenen Interviews
wurden die Ergebnisse mit Hilfe der Waste-Kategorien klassifiziert und in einer Excel-
Tabelle dargestellt. Dabei wurde der Waste "waiting" als wichtigstes Problem identifiziert
und für die Fallstudie verwendet. Das Konzept ermöglicht es, Value Methoden zur Verminderung
der Wastes mit Ihren Parametern zu identifizieren. Um die Anwendung der
Value Methoden besser zu verstehen wurden Lean Enablers und Subenablers detailliert
dargestellt. Mit Hilfe dieses Konzeptes können Prozessexperten ein Vorgehen zur Anwendung
verschiedener Value Methoden bekommen. Da die Parameter bekannt sind, kann
auch kontrolliert werden, ob die angewendete Value Methode einen positiven Effekt auf
die Erfolgsfaktoren (Zeit, Kosten, Qualität) im Prozess haben.

Wissenschaftliche Bachelorarbeit 59
8 LITERATURVERZEICHNIS
ACQUIPEDIA ; Internet URL :
https://dap.dau.mil/acquipedia/Pages/ArticleDetails.aspx?aid=20a138ca-a859-454f-a23a-
16a813478566
BAUCH, Christoph ; 2004, Lean product development : making waste transparent
BAYER, Paul ; 2008
Internet URL : http://www.wandelweb.de/blog/?p=82
BJÖRK ; 2003, Electronic document management in construction - research issues and
results
BUNDESREPUBLIK DEUTSCHLAND ; 2004, V-Modell XT
Internet URL : http://vmodell.iabg.de/index.php?option=com_docman&task=doc_view&gid=14
BURKARD, C. ; EIKENBUSCH, G. ; 2000, Praxishandbuch Evaluation in der Schule.
Berlin: Cornelsen Scriptor
Cassidian Homepage ;
Internet URL : http://www.cassidian.com/de_DE/web/guest/our-organisation
CHAFFEY, D. ; WOOD, S. ; 2004, Business Information Management: Improving Performance
Using Information Systems FT Prentice Hall
CHRISTELIS, L. ; SMIT, A. G. ; 2012, Lean approaches in a knowledge worker environment
CHRISTIAN, A.D. ; SEERING, W.P. ; 1995, A model of information exchange in the design
process
CLARK, Kim B. ; FUJIMOTO, Takahiro ; 1991, Product Development Perfomance :
Strategy, Organization, and Management in the World Auto Industry
COSTA, Carlos A. ; YOUNG, R.I.M ; 2001, Product range models supporting design
knowledge reuse
CRESWELL, John W. ; 1998, Qualitative inquiry and research design
DAVENPORT, Thomas H. ; PRUSAK, Laurence ; 1998, Working knowledge : How organisations
manage what they know
DIETEL, J.E. ; 2000, Improving corporate performance through records audits, information
management journal
EPPINGER, Steven D. ; BROWNING, Tyson R.; 2012, Design Structure Matrix Methods
and Applications
ERNST, Martin ; 2003, Simultaneous Engineering
FAHLBUSCH, Kim ; 2007, Internet URL : http://www.kinderforschung.unioldenburg.de/download/Masterarbeit_Kim_Fahlbusch.pdf
FICHTER, Wolfgang; WAGENER; 2005, Spiegelung in der Praxisreflexion. journal für

lehrerInnenbildung
GARDONI, M ; 1999, Maîtrise de l’information non structurée et capitalisation de savoir
et de savoir-faire en Ingénierie Intégrée. Cas d’étude Aérospatiale, European PHD thesis
INP Grenoble,
GARZA, Laura A. ; 1992, Integrating lean principles in Automotive Product development:
Breaking down Barriers in Culture and Processes
GEORGE, M. L. ; 2002, Lean six sigma : combining six sigma quality with lean speed
GILLER, Conrad; Fragetechnicken: offene und geschlossene Fragen
Internet URL : http://www.columbos-regeln.de/konflikt-undkommunikation/fragetechniken-offene-geschlossene-fragen
GRAEBSCH, M. ; 2005, Information and communication in Lean product development
GUNDRAN, A. G. ; YOUNG, R. I. M. ; 2006, An information and knowledge framework
for multiperspective design and manufacture (2006)
HINES, Peter ; 2001, Value stream management
HITCHINS, Derek ; 2007, Systems engineering : A 21st century systems methodology
HOFFMANN-RIEM, Christa ; 1989, Die Sozialforschung einer interpretativen Soziologie
HORNECKER, Eva ; 2006, Qualitative empirische Methoden ein Überblick
HUTTON, Thomas C. ; 2004, ACE vs. Six Sigma
INCOSE ; 2010, Lean enablers for systems engineering Internet:
http://www.leanssc.org/files/201004/powerpoint/4.22%203.45pm%20Oppenheim%20Lean
EnablersForSystemsEngineering.pdf
INCOSE ; 2004, Systems Engineering Handbook v2a, Version 2a
KALLMEYER, Jürgen ; 2000, Wissensmanagement im Entwicklungsprozess der Flugzeugsysteme
– Grundlagen und Anwendungen
KATO, Jin ; 2005, Development of a process for continuous creation of lean value in
product development organizations
KOSSIAKOFF, A ; SWEET, William N. ; SEYMOUR, Samuel J. ; BIEMER, Steven M. ;
2011, Systems Engineering principles and practice, second edition, John Wiley publication
KÜFER, Inga C. ; 2004, Projektplanung und Anforderungserstellung in einem V-Modell-
Projekt
LAMNEK, Siegfried ; 2005, Qualitative sozialforschung
LILL, Max ; 2011 Internet URL : http://it-wissenschaft.de/333/magisches-dreieck-kostenzeit-oder-qualitat/
LINDEMANN, Udo ; 2012, adaptiv Entwicklungsmethodik

Wissenschaftliche Bachelorarbeit 61
Internet URL : http://www.pe.mw.tum.de/studium/vorlesungen/adaptiv-bionischelosungsprinzipien-fur-gebaudehullen-1/adaptiv_sose12_vo_02_entwicklungsmethodik.pdf
LOCH, Christian; TERWIESCH, Chrisitian; 1998, Product development and concurrent
engineering; INSEAD
LOWE, Alistair ; McMAHON, Chris ; CULLEY, Steeve ; 2004, Characterising the requirements
of engineering information systems
Internet URL : http://www.deepdyve.com/lp/elsevier/characterising-the-requirements-ofengineering-information-systems-pTk3hOaY2v/1
MAYRING, Philipp ; 2002, Qualitative social research
McMANUS ; 2003, Product development value stream mapping manual (PDVSM), LAI
Initiative
McMANUS ; 2004, Product development transition to lean « MIT Lean Aerospace Initiative
»)
McMANUS; HAGGERTY, H. ; MURMANN, A. ; 2005, Lean Engineering: Doing the
Right Thing Right. ... Sciences, CEIAT, Queen's University Belfast
MILLARD, R. L. ; 2001, Value Stream Analysis and Mapping for Product Development
Cambridge, MA: Massachusetts Institute of Technology, Department of Aeronautics
and Astronautics, master thesis
MIT VORLESUNG ; 2007, Introduction to systems engineering
Internet URL : http://www.argospress.com/sample-chapters/EaS_sample-chapter.pdf
MOIR, Ian ; SEABRIDGE, Allan ; 2004, Design and development of aircraft systems, an
introduction
MORAN, N. ; 1999, « Knowledge is the key, whatever your sector », the financial times
MORGAN, James M. ; LIKER, Jeffrey K. ; 2006, The toyota product development system
MUNRO, Roderick ; 2001, Six sigma for the shop floor
MURMAN, E. ; ALLEN, T. ; BOZDOGAN, K. ; CUTCHER-GERSCHENFELF, J. ;
McMANUS, H. ; NICHTINGALE, D. ; REBENTISCH, E. ; SHIELDS, T. ; STAHL, F. ;
WALTON, M.; 2002, Lean Enterprise value: Insights from MIT´s Lean Aerospace Initiative
NARAKU ; 2012
Internet URL : http://www.cobocards.com/pool/en/card/6q5cq0612/online-karteikartenwelche-vor-und-nachteile-besitzt-das-v-modell-/
OEHMEN, Joseph ; REBENTISCH, Eric ; 2010, Waste in Lean product development
OPPENHEIM, Bohdan W. ; MURMAN, Earl M. ; SECOR, Deborah A. ; 2010, Lean enablers
for systems engineering
OPPENHEIM, B. W. ; 2004, Lean Product Development Flow, Systems Engineering,
Vol.7, No.4., 2004, pp 352-376.

PANDE, P ; HOLLP, L. ; 2002, What is six sigma ?
PFEIFFER,Werner ; Weiss, E. ; 1992, Lean management Grundlagen der Führung und
Organisation industrieller Unternehmen
REBENTISCH, Eric ; RHODES, Donna H. ; MURMAN, EARLL ; 2004, Lean systems
engineering : research initiatives in support of new paradigm
Internet URL : http://web.mit.edu/adamross/www/RHODES_CSER04.pdf
ROLAND SEIDEL ; 2001, Lerngruppe Marcopolo, Systems Engineering
Internet URL : http://www.interpolar.ch/Zusammenfassung/SystemsEngineering.pdf
SEIPEL, Christian ; RIEKER, Peter ; 2003, Integrative Sozialforschung. Konzepte und
Methoden der qualitativen und quantitativen empirischen Forschung
SEXTONE, Matt ; 1998 ; Systems Engineerings essentials (in Aerospace), NASA Langley
Research Center
SHILITO, Larry ; DE MARLE, David J ; 1992, Value : its Measurement, Design and
Management
SODERBERG, L. G. ; 1989, Facing up the engineering gap
STARCK, John ; 2011, Product lifecycle management ; 21st Century Paradigm Realisation
2nd edition
STEPHEN, Philipp ; 2004, Application of DMAIC to integrate Lean Manufacturing six
sigma
SUSS, Samuel ; THOMSON, Vince ; 2010, Coordination of complex product development
processes
TERWIESCH, Christian ; LOCH, Christoph H. ; DE MEYER, Arnoud ; 2002, Exchanging
preliminary information in concurrent engineering, alternative coordination strategies
THALES GROUP, Multi-Mission systems
Internet URL : http://www.thalesgroup.com/Portfolio/Defence/Air_Systems_Product_-
_Multi-Mission_System/
THOMSON, Vince ; Grebici, Khadidja ; HISARCIKLILAR, Onur ; 2010, The monitoring
of information transfers to control design progress during product development
ULLMAN, David G. ; 2003, The mechanical design process
WACKER, Alois ; 1999, Vor- und Nachteile offener und geschlossener Fragen
Internet URL : http://www.mab-guide.de/download/offene_fragen.pdf
WESTER, Franz ; SOLTAU, Andreas ; PARADIES, Liane ; 2006, Hilfestellung zur Gestaltung
eines Fragebogens
Internet URL :
http://www.lis.bremen.de/sixcms/media.php/13/Skript%20Fragebogenerstellung.pdf
WHOLIN, Claes ; RUNESON, Per ; HÖST, Martin ; 2000, Experimentation in Software
Engineering: an introduction
WIKIPEDIA-Q1 ; Internet URL : http://de.wikipedia.org/wiki/EADS#Cassidian

Wissenschaftliche Bachelorarbeit 63
WIKIPEDIA-Q2 ; Internet URL : http://de.wikipedia.org/wiki/Avionik
WINTER, Stephanie ; 2000, Qualitative Vs quantitative Methode
WOMACK, James P. ; JONES, Daniel T., 1996, Lean Thinking, Ballast abwerfen, Unternehmensgewinn
steigern
WOMACK, James P. ; JONES, Daniel T. ; ROOS D. ; 1990, The Machine That Changed
the World, Rawson Associates.
WOLF, Sabrina ; 2008, Der Methodenstreit quantitativer und qualitativer Sozialforschung
WU, DD ; KEFAN, X. ; GANG, C. ; PING, G. ; 2010, A risk analysis model in concurrent
engineering product development
ZHAO, Y. ; 2008, High value information in engineering orgnisations. International Journal
of Information Management

9 ANHANG
9.1 Zusammenfassung der Verschwendungen nach der Literatur (Bauch, 2004)
!

Wissenschaftliche Bachelorarbeit 65
9.2 Qualitative vs. quantitative Methode ( Miles und Huberman)
!

9.3 Beziehung zwischen Fragen und wastetypen
Waste (McManus)
Insufficient ITtools/system
Deficient
information
quality
Miscommunication of
Transportation Inventory Motion Waiting Over-production Over-processing Defects information
Prozess / Verantwortlichkeit
Sind Ihnen die für Sie relevanten Prozesse bekannt? Sind für Sie die Prozesse transparent? X
Wie modellisieren Sie Prozesse, wenn Sie mit einer Nachbarabteilung zusammen arbeiten? X X
Welche Prozessschritte sind für die Zusammenarbeit/Synchronisierung mit anderen Abteilungen wichtig?
Welche Prozessschritte haben eine Relation mit anderen Abteilungen?
Wissen Sie mit welchen Leuten Ihr Information austauschen müssen? X X X X X
In welchem Prozessschritt nützen Sie bestehende Informationen (Dokumente / Erfahrungen aus älteren
Projekten) in Ihren Prozessen? Existiert heute bei Ihnen eine Standardisierung für die Wiederverwendung
von Information? X
Wie würden Sie die Qualität der ausgetauschten Informationen beschreiben? ( sehr sicher (verifiziert),
sicher, mittelsicher, nicht sicher) Wie testen Sie heute die Verlässlichkeit Ihrer Informationen? X X X
Wenn Sie ein Problem beim Informationsaustausch mit einer Nachbarnabteilung anderer Disziplin
identifiziert haben, gibt es eine standardisierte Methode, um dieses Problem zu lösen?
In welchem Prozessschritt gibt es einen Verantwortlichen für die Koordinationsverbesserung zwischen
Nachbarnabteilungen? X X X X X X X
In welchem Prozessschritt gibt es für Sie zu viel/ ungeignet/ nicht genug Informationen? X X X X X X
In welchem Prozessschritt muss man oft auf Informationen im Prozess warten? X
Sind für Sie die Prozessschnittstellen Verantwortlichen im Prozess klar? Wenn nein, wo gibt es undefinierte
Rollen oder Verantwortungsprobleme? X
Im welchem Prozessschritt gibt es häufig Verspätung wegen ein Mangel an Informationen? X X X X X X X
Welche Risiken beim Informationsaustausch sind Ihnen bekannt? Was könnte in welchem Prozessschritt
falsch laufen? X X X X
Warum könnte es passieren? X X X X
Denken Sie, dass es eine Möglichkeit gibt, den Aufwand des Informationsaustauschs zwischen Abteilungen
zu reduzieren? X X
Finden Sie Ihre Informationen schnell genug? Haben Sie das Gefühl unnützliche Informationen zu lagern,
die die Auffundbarkeit nützliche Informationen stören? X X X
Ist Ihnen die Auswirkung des Ergebniss Ihre Arbeit auf nachfolgende Prozessschritte bewusst? Sind Ihnen
die Anforderungen Ihre Kunden bekannt? X X X X
Gibt es in dem Prozess unnötige Verzögerungen durch langen Unterschriftendurchlauf? X X X
Werkzeuge
Wenn Sie Informationen austauschen, gibt es manchmal Probleme wegen unterschiedlichen IT-Tools? X X
Hat jede Abteilung Zugriff auf eine gemeinsame Datenverwaltung (z.B. PDM) ? X X X X X
Haben Sie immer das richtige Tool, um auf die für Sie relevanten Informationen zu zugreifen? Welche Tools
nützen Sie um diese Informationen zu bekommen? X X
Nützen Sie ein neutrales Datenformat (z.B. STEP) zum Produktdatenaustausch? X X X

Wissenschaftliche Bachelorarbeit 67
9.4 Fragebogen
Beziehunge (Abteilung)
Task Input Prozess Output Kunde
1. Sind ihnen die für Sie relevanten Prozesse bekannt? Sind für Sie die Prozesse transparent ?
(formell dokumentiert)
pumpe konstruieren
[1] pumpe modell
Spezifikation [1]
CAD-Modell [2]
pumpe
entwickeln
Ja, die Prozesse sind bekannt und transparent
Ja, die Prozesse sind bekannt aber nicht transparent
Nein, die Prozesse sind unbekannt
Bemerkung
2. Wie modellieren Sie Prozesse, wenn Sie mit einer Nachbarabteilung zusammen arbeiten?
Bemerkung Prozess

3. Welche Prozessschritte sind für die Zusammenarbeit/Synchronisierung mit anderen
Abteilungen wichtig? Welche Prozessschritte haben eine Relation (
Informationsaustausch) mit anderen Abteilungen?
Bemerkung
4. Wissen Sie mit welchen Leuten Sie Information austauschen müssen?
Beziehunge (Informationen)
Kommunikati
onskanäle
Output (IT-
Autorensystems) Kunde
Input (Typ von
Daten, IT-
Autorensystems) Prozess
Bemerkung
pumpe konstruieren
[1]
Spezifikation [1]
pumpe konstruieren
[1]
CAD-Modell [2]
5. In welchem Prozessschritt nützen Sie bestehende Informationen (Dokumente / Erfahrungen
aus älteren Projekten) in Ihren Prozessen? Existiert heute bei Ihnen eine Standardisierung für die
Wiederverwendung von Informationen?
Bemerkung

Wissenschaftliche Bachelorarbeit 69
9. In welchem Prozessschritt gibt es für Sie zu viel/ ungeignet/ nicht genug Informationen?
- -
- -
- -
Zu viel
- -
- -
- -
Ungeignet
-
-
-
Nicht genug
Bemerkung
10. In welchem Prozessschritt muss man oft auf Informationen im Prozess warten
(geplant/ungeplant) ( nicht genug detaillierte Information, Mangel an Information, …) ? Was
sind die möglichen Ursachen?
Bemerkung
11. Welche Risiken beim Informationsaustausch sind Ihnen bekannt? Was könnte in
welchem Prozessschritt falsch laufen?
Bemerkung

12. Warum könnte es passieren?
Bemerkung
13. Denken Sie, dass es eine Möglichkeit gibt, den Aufwand des Informationsaustauschs
zwischen Abteilungen zu reduzieren?
Bemerkung
14. Finden Sie Ihre Informationen schnell genug? Haben Sie das Gefühl unnützlicher
Informationen zu lagern, die die Auffindbarkeit nützliche Informationen stören?
Bemerkung
15. Sind Ihnen die Auswirkungen der Ergebnisse Ihrer Arbeit auf nachfolgende
Prozessschritte bewusst (ungefähr in Prozent)? Sind Ihnen die Anforderungen Ihrer
Kunden bekannt?
Bemerkung

Wissenschaftliche Bachelorarbeit 71
3. Nützen Sie ein neutrales Datenformat (z.B. STEP) zum Produktdatenaustausch?
Bemerkung
4. Wurden Sie für die Nützung des Tools geschult (Ist der Umgang mit dem Tool und die
methodische Vorgehensweise klar)?
Bemerkung
5. Ist der Prozess gut automatisiert/ durch Cax-Technologie unterstützt (entspricht hoher
Integrationstiefe)? Warum?
Bemerkung
6. Gibt es bei Ihnen Problemen beim Datenaustausch zwischen die Disziplinen wegen
unterschiedliche IT-tools? Gibt es Problemen mit Datenkonvertierung (unterschiedlichen
Daten Formaten, Modelltypen, Datenvolumen, Qualität, …)?
Bemerkung

Wissenschaftliche Bachelorarbeit 73

9.5 Statistische Auswertung
!

Wissenschaftliche Bachelorarbeit 75
9.6 Auswirkungen von Value Methoden auf wastetyp
Test then design pull communication standardization integration of supplier and customer management of resources accurate content Simultaneous engineering
Transportation
Inventory ●
Motion ● ○
Waiting ○ ● ● ● ●
Over-production ▲ ● ● ● ● ▲ □
Over-processing ▲ ● ● ● ● ● ○
Defects (rework) ● ● ● ▲ ▲ ▲ ○
Generating
defective
information ● ● ■ ● ∆
Unclear
responsability
objectives,
priorities ○ ∆ ● ● ▲ ∆
Poor
synchronization ▲ ● ▲
Lack of resources ○ ■ ● □
Lack of discipline ○ ○ ○ ○ ○ ○
Poor Accuracy ● ● ● ● ●
Poor relevance ■
Poor Objectivity ●
Difficulty of
understanding ▲ ▲
Poor conciseness ▲ ▲
Insufficient
information system □ □ ■ ∆
Innefective
communication ■ ■ ■ ∆ ○
- +
Hohe Wirkung ○ ●
Mittel Wirkung ∆ ▲
Kleine Wirkung □ ■

9.7 Analyse der Verbesserung nach Variation der Parametern

Need for information or knowledge, data
delivered
Incomplete understanding of
stakeholder requirements
Team members not
colocated
Use of inappropriate
tools/methods
Lack of needed
information
Ursachen
Wissenschaftliche Bachelorarbeit 77
9.8 Gesamt Konzept
Unclear or shiftings targets
Partial information
Incompatible software
suites
innapropriate use of
competency
Decision criteria unclear
Reworking product or processes
Lack of reviews,
test, verifications
Handoffs
Poorly designed user
interface
excessive transactions
Haste
Stop and go tasks
excessive approvals
Working with wrong
level of detail
too much information to
sort through
Lack of training
Inefficient work environment
unnecessary detail
and accuracy
Reformatting
Lack of standard for
data conversion
Ineffective communication
Information pushed to
wrong people
Lack of direct access
unnecessary features
and processes
Security issues
Manual data conversion
Inefficient use of tools
Overprocessing
Defects
Information hunting
Excessive data traffic
Motion
Incompleteness
Lack of direct information access
Transportation
Insufficient
knowledge
sharing
pull
Information incompatibility
standardisation
Poor relevance,
objectivity,
conciseness
Waste
lean enablers 1
poor compatibility, capacity
Value-Method
DSM
Deficient
information quality
Insuficient IT-tools
/ System
communication
lean
enablers n Value lean
enablers 2
Information
deterioration
during
communication
low capability
no open information
sharing
lean enablers 3
Flow
Difficult to
understand
erroneous or
incomplete
information
Lack of access
Test then design
Inventory
Late delivery of
information
Waiting
Unecessary
testing
equipment and
prototypes
Wait times due to
other wastes
Overproduction
Miscommunication of
information
Outdated, obsolete
information
Lack of control
Information
waiting for
people
Suspect quality
of information
Creation of unecessary
data and information
Incomplete
content
redundant tasks
Poor
synchronization
as regards time
and capacity
Unclear
responsability
Complicated retrieval
Frequent
interruptions
redundant tasks
Strong dependencies
Untimely updating
of data basis
No learning of basic
knowledge
Multitasking
excessive
data storage
Low performance
creation of
unecessary data and
information
Reinvention, no standard for
the reuse of information
Delivering info too early
Insufficient
communication channels
Multiple approvals
No learning
from
practice
Processing defective information
(undiscovered errors)
Product
feature
inventory
Interruptions in process
People waiting for
capacity available
Poorly designed or
executed process to
provide information
Overdissemination of
information
Poor synchronization as
regards contents
Organizationnal
/ Process
barriers
Hand-off

Erklärung
Hiermit erkläre ich, dass ich die Diplomarbeit selbstständig verfasst, noch nicht anderweitig
für Prüfungszwecke vorgelegt, keine anderen als die angegebenen Quellen oder Hilfsmittel
benützt sowie wörtliche und sinngemäße Zitate als solche gekennzeichnet habe.
Ort, Datum Unterschrift