IPROD Meeting University Novi Sad 25. – 28.11.2013...

1 KIT – Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu

IPEK – Institut für Produktentwicklung

IPROD Meeting University Novi Sad 25. – 28.11.2013 Teaching process models: „ Integrated Product Engineering Model – iPeM“ Prof. Dr. Ing. Albert Albers / OI Norbert Burkardt, Chief Engineer Education

2

Complexity of Product Engineering Processes

Andreas Braun – Integrated Modelling of Information to Support Product Engineering Processes

objectives and constraints

people processes and activitites

methods and procedure models resources

objects

3

Objects of product development are regularly models

Models in product development

Ident-Nr. 110030

θ1

θ7

θ6

θ4

θ2

θ11

θ9

θ10

θ8

θ5

θ3

θ12

θ13

θ14θ1

θ7

θ6

θ4

θ2

θ11

θ9

θ10

θ8

θ5

θ3

θ12

θ13

θ14

4

Example modeling: FEM-Simulation robot component

Ident-Nr. 110031

Illustration: Exact name of the component? Date/ version? Where assembled? Material? …

Reduction: Simplified geometry? Load conditions? Load application? Boundary condition? Material model? Tolerances? ...

Pragmatism: Purpose of simulation? Strength analysis? Weight reduction? ...

Modeling: Who built the model? When? Origin of the loads? Which preprocessor / Solver / postprocessor?

5

Effective working with models requests knowledge of: What does the model represent? (illustration) Which original characteristics does the model copy and which one not? What is the intention of the model? (pragmatism) How was the model developed? (modeling) Advantages: Common objectiveness / understanding Easy reutilization of knowledge

Compare Stachowiak: „Allgemeine Modelltheorie“,1973

Models

Ident-Nr. 110032

6

Models are necessary to reduce and concretize the complexity of reality

Decisive categories to evaluate reality are not truth and objectivity but consense, usability & practicability. Glasersfeld: Konstruktion der Wirklichkeit und des Begriffs der Objektivität, 1992, S. 30.

Importance of models

Ident-Nr. 110033

Explicit model Original Mental model

7

Models are necessary to reduce and concretize the complexity of reality

Decisive categories to evaluate reality are not truth and objectivity but consense, usability & practicability. von Glasersfeld: Konstruktion der Wirklichkeit und des Begriffs der Objektivität, 1992, S. 30.

Importance of models

Ident-Nr. 110034

Explicit model Original Mental model

Theory of cognition: 3-worlds-model of Popper

World 1 reality

World 2 subjectivity

World 3 objectivity cognition

8

General Model Theory: „All cognition in models or by models and any world encounter needs the medium ‘Model‘.“ Stachowiak: Allgemeine Modelltheorie, 1973, S. 56.

Modeling requires common models:

Models must be well-defined Modeling is ambiguous and partly undefined

The model of modeling is a metamodel e.g. language In a syntax – the grammar – is described how the elements – the vocabulary – have to be used.

Models in product development

Ident-Nr. 110035

9

Communication theory: Linguistically established intersubjectivity precedes any common object and target directed cognition. Habermas: Theorie des kommunikativen Handelns, Band II, 1988, S. 198-202.

Not understanding the system or model is as if blind persons argue about colors. Ropohl: Eine Systemtheorie der Technik, 1979. S. 85.

Requirements on product development: Intersubjective metamodels are needed for targets, operations and objects in product development!

Folgerung Intersubjektivität

Ident-Nr. 110037

10

Goal of product development: Transformation of a vague System of Objectives into a concrete System of Objects with the help of an Operation System

System-technological model of product development

System of Objectives

System of Objects

Operation System

11

The System of Objectives characterizes a quantity of targets and interactions between these targets. Objectives characterize aimed at (intended) target attributes of the object system. The character of objectives can be technical, economical, aesthetical, societal... The specification of the objectives is dynamically growing with the degree of realization of the object system.

System of Objectives

12

System of Objectives: Provision of bakery products that

taste good are healthy are cheap are always fresh are always tasty stay fresh for a long time …

System of Objectives example: bakery

13

The Operation System characterizes elements and their links, with which an system of objects is created, that accomplishes the specified system of objectives. Elements of the Operation System are man, organization, resources, processes, methods and tools.

Operation System

14

Operation System bakery staff ingredients recipes backing machines store, delivery service sales promotion / marketing purchase administration …

Operation System example: bakery

15

Operation System: Employees, engineers, workers R&D activites Design Methods Marketing Sales channels

Operation System other examples

16

The System of Objects represents the realization of the specified system of objectives. Between System of Objectives, Operation system and System of Objects strong interactions exist!

System of Objects

17

System of Objects Various bakery goods

System of Objects example: bakery

18

Mercedes A-class Development costs: approx. 1 billion Euro Overhaul costs after „Elchtest“: approx. 150 million Euro Industrial facilities: approx. 1,5 billion Euro Work places manufactoring: approx. 5000 High responsibility and risks! Development processes need to be planned, designed and supervised/controlled

Why are models of operating systems necessary?

Ident-Nr. 110027

19

Management: Planning and controlling Development: support, planning and design of product development processes Common language: uniform and comprehensive comprehensible description of elements and procedures in product development Intersubjectives understanding Transparency, transfer of knowledge out of past development processes in current or future

Motivation models for operating systems

Ident-Nr. 110028

20

There are two fundamental different views on product development processes!

2 fundamental approaches of PDP modeling

What is the fundamental challenge in developing processes?

Ident-Nr. 110039

Management

Planning Controlling

Developer

Support

PEP

21

What is the fundamental challenge in product development processes?

Ident-Nr. 110044

PDP

Structure Repetition, Rules, Automation, skill profile

Process work

Dynamic part Surprise, principle, person, decision, responsibility

Knowledge work

Management

Planning Controlling

Developer

Support

Both views are important for a good PDP. How can they be improved?

22

Process work

Application of knowledge Good to formalize Good to plan concerning resources and the result Precise approach defineable Performers intelligence only influences the result Demands exact rules

Allows synoptic planning

Process work vs. knowledge work

Ident-Nr. 110043

SOLL- Zustand

Synoptic planning

Planning

Implementation

prog

ress

Current state

Time

Knowledge work

Production of knowledge Limited to formalize Limited to plan concerning resources and the result Only targets defineable Performers intelligence essentially influences the „way“ to the result/process Demands clearance

Demands incremental planning

SOLL- Zustand

Incremental planning P

rogr

ess

Planning

Implementation Planning

Implementation Planning

Implementation

Current state

Time

23

Product development processes should be able to: manage the development project. support the developer within the development process. minimize the risks of product development processes. use experiences in context with learning processes.

and all this without reducing innovative performance.

Conclusion for iPeM

Ident-Nr. 110045

24

various aspects at different levels of abstraction various purposes; no integration has been realized yet integrated overview only „in the head“ of experienced designer/manager need to explicate implicit knowledge

Product Engineering Processes

Philosophies

Approaches Languages

Tools

State of the Art


Hubka and Eder Suh Andreasen Haberfellner …

Pahl and Beitz VDI guidlines MIL standards, DODAF …

IDEF BPMN SysML …

MS Visio DOORS artisan studio …

25

Background: Approaches to Process Modelling


Systems Engineering

socio-economy

industry

business

project

product

26



Systems Engineering VDI guidelines

Anforderungsliste

Klären und Präzisieren der Aufgabenstellung 1

Arbeits-ergebnisse Phasen

Ermitteln von Funktionen und deren Strukturen 2

Suchen nach Lösungsprinzipien und deren Strukturen 3

Gliedern in realisierbare Module 4

Gestalten der maßgebenden Module 5

Gestalten des gesamten Produkts 6

Ausarbeiten der Ausführungs- und Nutzungsangaben 7 Ite

rativ

es V

or- u

nd R

ückw

ärts

sprin

gen

zu A

rbei

tssc

hritt

en

Erfü

llen

und

Anp

asse

n de

r Anf

orde

rung

en

Aufgabe

Weitere Realisierung

Aus

-ar

beite

n E

ntw

erfe

n K

onzi

pier

en

Auf

gabe

kl

ären

Funktions-strukturen

Prinzipielle Lösungen

Modulare Strukturen

Vorentwürfe

Gesamtentwurf

Produkt-dokumentation

27



Problemanalyse

Problemformulierung

Systemsynthese

Systemanalyse

Beurteilung

Entscheidung

System-vorstudie

System-entwicklungen

System-herstellung

System-einführung

System-betrieb

System-wechsel

Lebensphasen des Systems

Systems Engineering VDI guidelines Problem Solving Cycles

28



Stage

1

Stage

2

Stage

3

Stage

4

Stage

5

Stage

1

Stage

2

Stage

3

Stage

4

Stage

5 Produkt

Produkt

Produkt

Strategie,

Projektplan

Anforderungs-

ermittlung Entwicklung Test &

Prototypenbau

Produktion,

Markteinführung

Strategie,

Projektplan

Anforderungs-


Prototypenbau

Produktion,

Markteinführung

Strategie,

Projektplan

Anforderungs-


Prototypenbau

Produktion,

Markteinführung

Idee

Idee

Idee

Gate

2

Gate

3

Gate

4

Gate

5

Gate

5

Stage 1 Stage 2 Stage 3 Stage 4 Stage 5

Gate 2 Gate 3 Gate 4 Gate 1

1. Generation „Supplier to Costumer“

Stage-Gate-Ansatz der 2. Generation

Stage-Gate-Ansatz der 3. Generation

Gate

1

Systems Engineering VDI guidelines Problem Solving Cycles Project Management

note: multiple perspectives i.e. purposes and levels of abstraction • system life cycle • anthropocentric

problem solving

29

objectives

resources

objects

General, balanced structure to provide an overview on

interrelations

Integrated Product Engineering Model (iPeM) Requirements on Engineering Process Models

Maintain constant feedback and communication between designers and management Sequential process models cannot fulfil these requirements

Know-How, tools and methods to support designers in daily problem solving practice

activities

objectives

activities resources

objects

30

activities resources

objects

Activities of Problem Solving

Designers view > Methods and tools

Activities of Product

Engineering

Management view > Structure of active operations

objectives

Integrated Product Engineering Model (iPeM) Integrated view on Engineering Processes

31

Objec-tives Objects

Integrated Product Engineering Model (iPeM)

Operation System System

of Objects

System of

Objectives

Objectives Solutions S P A L T E N

Albers, A.; Braun, A.: A (2011) Generalized Framework to Compass and to Support Complex Product Engineering Processes. International Journal of Product Development, 15(1/2/3), Inderscience, Genèva Albers, A., Braun, A., Muschik, S., (2010), Uniqueness and the Multiple Fractal Character of Product Engineering Processes. 1st International Conference on Modelling and Management of Engineering Processes, Springer, London.


32

Objec-tives

Integrated Product Engineering Model (iPeM)

Objectives

Solution Selection L

Assessment & selection of solutions



33

Integrated Product Engineering Model (iPeM) S

yste

m o

f Obj

ectiv

es

Sys

tem

of O

bjec

ts

Activities of Product Engineering

Project Planning and Controlling

Profile Detection

Idea Detection

Modelling of principle solution and embodiment

Validation

Production System Engineering

Production

Market Launch

Analysis of Utilization

Analyses of Decommission

Activities of Problem Solving S P A L T E N

Phase Model

Time

Today

Operation System


note: systemic approach • structure • hierarchy • function integration of engineering and process work


Sys

tem

of R

esou

rces

34

holistic/comprehensive consideration (iPeM) shared mental model hierarchies, relations* semantic context objectives activities

of product engineering of problem solving

resources objects

* ordering relations (e.g. predecessors), flow relations (e.g. deliverables)

Summary


35

Résumé


Product engineering processes are complex. Integrated modelling of information can help establishing transparency in the system of product engineering. The iPeM makes it possible to explicate implicit knowledge in the respective overall context. Purposive views (reduction of total information) allow supporting product engineering processes.

IPROD Meeting University Novi Sad 25. – 28.11.2013...

Documents

Transcript of IPROD Meeting University Novi Sad 25. – 28.11.2013...