Download - Fakultät 06 - Hochschule München

fb06.fh.muenchen.de

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

Weitere Magazine dieses Users
Ähnliche Magazine