Published in: Proceedings of the 9th Annual Symposium of INCOSE, UK, 1999

Modeling of Integrated Product

Development Processes
Herbert Negele†, Ernst Fricke†, Lutz Schrepfer†, Nicole Härtlein+
† +
Institute of Astronautics BMW AG
Technical University of Munich 80788 München
Boltzmannstr. 15, 85748 Garching, Germany Germany
Email: [email protected]

Abstract. The development process has to be process reengineering often meant to identify and
modeled and documented for its reengineering and optimize several different process chains. Often this
continuous improvement. A development process optimization is done separately for each of these
model is the basis for how a system will be designed. chains, as if they were independent of each other.
Due to the special nature of integrated product devel- This corresponds to observations of psychologists:
opment processes, a method for process modeling people tend to think in causal chains, in particular
has to be able to support and easily map the high when they have to tackle complex problems (Dörner,
interconnectivity between processes of different engi- 1989). As a result, interactions and interfaces
neering disciplines over all hierarchies. The domi- between different chains were ignored ending up in a
nant elements in a model of integrated product devel- mediocre (or even poor) overall development
opment processes are the informational relations and process. Reality cannot be described adequately by
flows. isolated, sequential and one-dimensional chains. It
The analysis of models and textual rather resembles a network (process net), with many
documentation of the engineering processes in an interrelated processes and process chains (Negele et
automotive company revealed the special need for al., 1997).
modeling concurrent engineering processes. Existing Applied to the field of product development,
methods didn’t support these needs sufficiently. besides the processes, additional (interrelated)
Therefore, a single method for mapping and aspects have to be taken into account to get a
interconnecting the processes of all different comprehensive view of this system (e.g., customer
engineering disciplines was agreed upon, which and user needs, requirements and goals, products,
describes inputs and outputs (e.g. informational people, resources, organizations). Systematic
objects) for every process. methods and tools can help to manage these complex
The paper describes the reasons for an systems successfully by enabling holistic analysis,
engineering process driven modeling method, the modeling, and examination of relevant elements and
method itself and its application. Also, lessons their interrelationships. Such a method was proposed
learned from this approach are described. as the ZOPH Model, a comprehensive systems
modeling approach that embraces, structuring,
INTRODUCTION modeling, and interrelating information essential for
In today’s companies there is a strong need for product development systems (Negele et al., 1997;
means that enable better documentation, Negele, 1998). It structures all the information rel-
communication, understanding, and learning evant to a given development system by using four
especially with regard to development processes and different system types that form the abbreviation
the inherent process know-how. ZOPH, which is derived from the first characters of
Due to the increased overlapping of the develop- the German terms
ment processes, the amount of information that has • Zielsystem (goal system),
to be exchanged for an effective and work • Objektsystem (product system),
environment has strongly increased, too. In order to • Prozeßsystem (process system), and
reduce development cycle times and costs, the devel- • Handlungssystem (agent system).
opment processes have been reengineered and new Here, we want to focus on the development pro-
organizational concepts and structures were cesses (process system) and how they can be modeled
implemented (e.g., team-oriented organizations with in order to meet the requirements arising from their
Integrated Product Teams, Clark & Fujimoto, 1991). specific characteristics, taking into account a concur-
It was observed in several companies that rent engineering environment with decentrally acting
 Published in: Proceedings of the 9th Annual Symposium of INCOSE, UK, 1999

teams and individuals. Gundrum (1999) shows that a and use it as a basis for improvement.
process system is based on a clear understanding of • Shorter Development Cycles: One main reason
the sequence of activities and of the inter- for process modeling is the achievement of
relationship of the program and process owners, shorter development times. Process models are
timely tailoring and utilization of process assets, and the starting point for process reengineering and
cross-discipline understanding of roles and optimization activities.
responsibilities. better planning and transparency
management
understanding and
MODELING DEVELOPMENT learning
PROCESSES better coordination documentation and
reusability
Why Model Development Processes? First, we have Process Model
to answer the question, why modeling development
processes is necessary and worth the effort. Several
what-if-analyses
points are put forward by Fricke et al. (1998):
• Transparency: A process model helps people to prereq. for audits
get an overview, to understand what part they basis for process shorter (ISO 9000, etc.)
assessment and development
play in the game, and to see who is doing what improvement cycles

and when. This is all the more necessary when

processes are changing very often (e.g., due to Figure 1. Why model Processes?
reengineering efforts). The goals that have to be achieved by process
• Understanding and Learning: A transparent modeling activities are exactly these arguments for
process model supports and communicates under- modeling (development). To describe processes in
standing of complex processes and their inter- the product development context adequately, a better
actions and dependencies within the understanding of the specific characteristics of this
organization. It also provides an excellent kind of processes is necessary.
learning aid for employees that are new or have Characteristics of Development Processes. Today’s
changed jobs. development processes differ significantly from other
• Coordination: In the course of the development, business processes, such as production, logistics, or
many process interfaces (flows of information, supply-chain processes. While these resemble
material, money, etc.) have to be coordinated in sequential process chains that are performed several
content and time. A consistent process model times in a very similar or almost identical way,
promotes better communication (people talk development processes are rather like process nets
about the same things) and allows early planning where processes are highly interconnected, including
of future interactions. feedback-loops and interactions on different
• Better Planning and Management: By enabling hierarchical levels. Process nets are a multi-
transparency and early coordination a modeled dimensional network with many strongly interrelated
process represents a sound basis for detailed processes and process chains.
planning and easier management of the actual Typical characteristics that can be used to
development project. describe development processes are (Negele 1998):
• Documentation and Reusability: Process models creative and innovative, dynamic, interdisciplinary,
are a kind of documentation that can be easily strongly interrelated, strongly parallel, iterative,
reused as a starting point or "building blocks" in communication intensive, anticipatory, planning
subsequent development projects. intensive, uncertain, risky.
• Prerequisites for Audits: In order to achieve Many development activities have an unique and
certification (e.g., compliant with the ISO 9000 intuitive character that is very difficult to capture in
Series of Standards, esp. ISO 9001) a docu- a model. Many decisions have to be made
mented process and evidence that the process is anticipatory and relying on assumptions. Because of
performed as documented are required. A process the newness of many development tasks, acquired
model that is really used by all people involved in information often is tainted with uncertainty.
the development activity can provide both. Usually, development processes are treated as what
• What-if Analyses: A process model can be used we called "sequential" processes. There seems to be a
to conduct what-if analyses to determine the ef- lack of understanding for the different character of
fects of process changes. Moreover, process sim- development processes.
ulation capabilities can be built upon the model.
• Basis for Process Assessment and BOUNDARY CONDITIONS AND SOME
Improvement: Only if you know what you are FUNDAMENTAL QUESTIONS
doing (which can be described in a process In general, two different approaches to process
model), you can assess how good you are doing it modeling can be distinguished: decentral or central
 Published in: Proceedings of the 9th Annual Symposium of INCOSE, UK, 1999

process modeling. This has a strong impact on process modeling were used and generated data were
factors like kind and number of process modelers, interchangeable. Unfortunately, this was not the
information consistency and density and others, as case. Therefore, it became evident that there was a
shown by Fricke et al. (1998). With the central need for a common tool that supports modeling,
approach, typically, some process specialists collect planning, and coordination of processes and their
all relevant information for a top-down structured interactions.
process model. Advantages of this approach are: Several boundary conditions have to be taken
modelers can be specially trained for their job and for into account here. Since the work load of the
supporting tools; they are capable of generating high engineers generally is very high, it is crucial that
sophisticated models (high "information density"); they have an operational need and benefit of
and, since the number of modelers is quite small, the applying such a tool. It has to be very user-friendly
modeled information should be quite consistent and easy to use. Moreover, engineers have to
concerning content and degree of detail. overcome the conviction that everything they are
A fundamentally different approach is to let all doing is unique and therefore can't be modeled. Last,
people involved in development work decentrally on they have to be persuaded that their processes should
the process model. The number of modelers or users be documented for the reasons mentioned above and
of a corresponding process modeling tool can amount that they don't become replaceable by doing so.
to several hundreds of persons, e.g. in the develop- Fricke (1998) describes principles and methods for
ment of an automobile. The advantages of this realizing such an user-centered approach.
approach are: if all people are using the model on a Other important issues were the amount of
regular basis, the information contained is up-to- training necessary, and the serviceability and main-
date; since the modelers know their processes best, tainability of the tools. Also, the visualization
the model is likely to be quite realistic; and the effort capabilities for an adequate representation of the
for updating the process model is limited, because it process net were considered to be fundamental. As
is shared by many individuals and loss of process plans should be used in an ongoing project
information can be avoided. for project scheduling, a data interface to a project
As always, the best alternative is found in a scheduling tool should be possible. This requires that
compromise of both approaches. Since several correspondent information of both methods/tools can
unsuccessful attempts already had been made at the be mapped on each other.
project partner's site, to build up a detailed process
model centrally, a combined top-down and bottom- ANALYSIS OF EXISTING TOOLS
up approach was chosen. A centrally generated and A detailed analysis of tools for modeling business
coordinated master plan and a common, top-down processes revealed that none of the available tools
process model structure provided the basis for the met the requirements derived for modeling
practical integration of the distributed, bottom-up concurrent engineering processes for integrated
modeling efforts. systems (Fricke et al. 1998). This is supported by
Also, for a reengineering project, engineers had Lullies et al. (1998), who state that the most
started to model their processes with a quite simple modeling methods and tools were developed for and
input-process-output (IPO) logic, describing what used in projects whose focus was the reengineering
they are doing (P), what they need to do it (I), and of business processes in preparation for the
what they produce (O). The output of one process introduction of new information systems and were
can be used as input by other processes. These therefore driven by the needs of IT specialists.
output-input relations represent the interactions The requirements for selecting a modeling tool
between processes. This supports the idea of an were based on a simple Input-Process-Output
information-based system development, where the method, enabling a decentral description and
structure of the information flow defines the coordination of processes and their interactions
structure of the development process (Fricke & (flows of information, components,...). Other crucial
Negele 1997, Gartz 1997). aspects, like seamless integration with project
The IPO description was done in ordinary MS planning and scheduling tools, easy operation and
Word forms that everybody could generate. The multi-user and database support, were supported by
problem was that no possibility existed to support the only a few of the analyzed tools.
coordination of output-input links. Also, in daily Altogether, more than 30 commercially
practice, many different methods and tools for available tools which are or could be used for process
process modeling were used (CAD-tools, planning were evaluated. Some tools like Visio, are
spreadsheets, presentation or word processing more or less graphical visualization tools, which
software, project scheduling tools, etc.). The usage of have no possibility to analyze modeled data automa-
different tools for capturing, visualizing, and tically. Other tools are project scheduling tools rather
analyzing process information does not necessarily than process modeling tools. The third group are the
have to be a problem, if a common method for typical business process modeling tools like ARIS,
 Published in: Proceedings of the 9th Annual Symposium of INCOSE, UK, 1999

which were originally designed for IT models

implementation or more sequential processes, like • Links: describe interactions between processes
manufacturing and logistics processes. As no (flow of information, matter, ...) and define
existing tool seemed to satisfy the needs derived from output-input interfaces.
modeling concurrent engineering processes for
A process with its assigned inputs and outputs can be
integrated systems, it is obvious that there seems to
understood as the fundamental building block ("IPO-
be a lack in understanding the special characteristics
element") for the process model. Building blocks are
of these development processes, which might be a
interlinked by connecting outputs and inputs of
hint as to why many reengineering activities of
(usually different) processes. A single output can be
engineering processes in different industries failed
linked to several inputs (e.g. a requirements
(Fricke et al., 1998).
document is needed in several processes).
Therefore, the decision was made to develop a
In order to build a process model that also can
new method and tool based upon the input-process-
be implemented in a computer tool a formal
output approach, that serves the needs derived from
modeling language is needed that is capable of
concurrent, highly-interactive development pro-
representing processes, inputs, outputs, links, and all
cesses. Additionally, close integration with the
necessary additional information. Here, a generic
project scheduling method and tool already in use
modeling language was adapted that had been
should be possible. Next, the graphical user interface
developed for modeling complex
systems at the Institute of
I INPUT P PROCESS O OUTPUT Astronautics at the Technical
University of Munich (Igenbergs
Described by Described by Described by
1993, Walther, 1994, Negele et
al. 1997, Negele 1998).
ATTRIBUTES Specifically, the basic
INPUT-Attributes PROCESS-Attributes OUTPUT-Attributes components of the process
• belongs to process • owner • hierarchy-info • belongs to process modeling language can be
• short term • process chain • costs • short designation
• description • phase • resources (human • description described in more detail by many
• date/point in time • organization & non-human) • date/point in time
• supplier/source • inputs/outputs • goals/objectives • receiver/destination
different attributes (Figure 3).
• coordination/link • short term • roles • coordination/link For example, information on
• classifying features • description • used methods • classifying features
• time before/after start of • duration • infrastructure • time before/after start of
costs, risks, resources, current
process • process type • critical factors process methods and tools, relevant
• level of criticality • affected team • level of criticality
objectives/requirements, type of
Figure 2. Attributes describing IPO-elements process, etc. can be assigned to
should look similar to the format of the word processes, besides normal
documents already in use for process modeling. information like title, description, owner, duration,
and so on. To keep up flexibility and be prepared for
DESCRIPTION OF DEVELOPED changing (user) requirements, the set of attributes
IPO-METHOD can be changed or extended easily at any time.
Basic Components of the IPO-Method. Following Linking Concept. For interlinking processes
the principle already used by many engineers in the temporal dependencies are often used (e.g., in
reengineering efforts mentioned above, and in order network planning methods like CPM or MPM) that
to be able to reuse the information already collected, specify when a subsequent process can start after a
the basic components of the process model are: predecessor. Since there is no information on why
• Processes: describe relevant there is such a dependency or what it stands for, this
tasks and activities of the people interaction at one point in time

involved; events (e.g. mile-

1 O supplier 2 O/I supplier/receiver
stones) are seen as special cases
18 MvS e.g. drawings of ... unidirectional 18 MvS e.g. coordination of ... bidirectional
of processes (no temporal
I receiver O/I supplier/receiver
extension)
• Inputs: represent input objects
interaction over a period of time
necessary to carry out the
process, e.g. documents, data 3 O supplier 4 O sup./rec.
files, software or hardware 18 MvS 15 MvS unidirectional 18 MvS 15 MvS bidirectional
models I receiver I sup./rec.
• Outputs: represent objects that MvS: months before start of serial production
are produced or worked on in
the process, e.g. documents, data Figure 3. Types of process relations
files, software or hardware
 Published in: Proceedings of the 9th Annual Symposium of INCOSE, UK, 1999

concept seems to be not practical for decentrally set up by the most important milestones. The process
modeling product development processes. There is a net itself has a multi-dimensional structure. Three
need for "meaningful" relations representing flows main dimensions are process chain (e.g. chassis,
(especially of information and material) between pro- engine, etc.), organization or role, and development
cesses and interactions between process owners, i.e., phase (see figure 4).
individuals, teams, or other organizational entities.
Therefore, the output-input links
Pseudo-hierarchy/Structure Decomposition
Decomposition
used in the IPO method enable
⇒ structuring criterion is a attribute ⇒⇒ processes
processes areare subordinated
subordinated
involved process owners (who) to
⇒ instances of attribute are hier- ⇒⇒ processes
processes themselves
themselves build build up
up aa
interactively make agreements on archical, e.g. “process chain” hierarchy:
hierarchy: parent–child–relation
parent–child–relation
content (what) and time (when) of ⇒ structure valid for entire process net, ⇒⇒ hierarchyhierarchy only
only valid
valid for
for the
the
their interactions. Inputs do not e.g. not dependent on duration/time ““sphere”
sphere”ofof parent
parent process,
process, e.g.
e.g.
necessarily enter a process at its ⇒ no automated consistency between dependent
dependent on on duration
duration
starting point and outputs can leave a processes of different structure ⇒⇒ consistency
consistency constraints
constraints between
between
levels parent
parent and
and child
child process
process EG-221 Monteur

process before it is finished. That's Processchain 1

EG-221

RHS-Feintuning

2 Monate
Feintuner

Prozeßkette PS E65
RHS in Gesamt fahrzeug-
modell einbauen
2 Monate Prozeßkette PS E65

Vorbereitungsphase
Vorbereitungsphase

why inputs and outputs can be EG-232 Controller EG-232 Monteur EG-232 Tester

assigned to any point in time within Überwachung Systemliefer-

ranten-W eiterentwicklung
2 Monate

Vorleistungsphase
Prozeßkette PS E65
Aufbau der HW beim
Systemlieferanten
2 Monate Prozeßkette PS E65

Vorbereitungsphase
Komponententest /
Systemlieferant
2 Monate Prozeßkette PS E65

Vorbereitungsphase

the process duration (if necessary the EG-232

Bewertung der Ergebnisse

0 Monate
Bewerter

Prozeßkette PS E65
EG-232

Bewertung der Ergebnisse

Bewerter

duration can be adjusted). Additional Decomposition

0 Monate Prozeßkette PS E65
Vorleistungsphase
Vorbereitungsphase

information on problems/objectives of individual EG-232

Bewertung des RHS bzgl.

Externer Komponenten
Bewerter
ED-2

Design anp assen

Designer

0 Monate Prozeßkette PS E65

process Vorleistungsphase
EG-232

Bewertung des RHS bzgl.

Bewerter 0 Monate

Vorleistungsphase
Prozeßkette PS E65

(why), locations (where), means Processchain 3 Processchain 2 Design

0 Monate

Vorleistungsphase
Prozeßkette PS E65

(how), coordination status, etc. can

be assigned to the relations according Figure 5. Multidimensional structure
to specific needs by defining corresponding Hierarchical concepts. A strict hierarchy, as used in
attributes. Moreover, different types of relations can the SADT or IDEF modeling methods, is not helpful
be distinguished, for example with regard to the for process modelling in the product development
duration and the direction of an interaction (figure domain, as processes of different hierarchies are
3). More classifications, e.g. concerning the content interlinked with each other. On the other hand, the
(like certain data or model types), importance, or total renouncement of a hierarchy will result in a
criticality can be added as needed. very confusing process model. Therefore the concept
With this linking concept, effective, decentral of a pseudo-hierarchy was developed (figure 5, left
interface management and process coordination side). In this hierarchical concept the structuring
within and across projects can be supported. Direct criterion is put into an attribute. The instance of the
communication between the involved persons and attribute, in our case the process chains, are
teams will not be replaced by establishing such a hierarchical. This structure is valid for the entire
process model. Rather, the IPO-Method can help to process net, and is not dependent on duration or
easily determine where and when interaction and other factors. The single processes are then hooked
communication is necessary, and assist in planning up to this pseudo hierarchy. This results in an
resulting coordination activities. ordered process map, where all processes can be
time selection: linked directly to each other across all hierarchies.
(phase) •functional integration
•phase III So, it is not a top-down process that is used, where a
•Dep. C
...
modeler defines the interfaces or parent processes
phase III
that are used to exchange information. This supports
a decentral and agile modeling approach.
y
ilit , Additionally, it was required that single teams
sib tion phase II
a
on is )
sp n le
may model their processes more in detail. Therefore
re rga ro ... phase I it is possible to decompose individual processes
(o C
p. B
De p. structure/ (figure 5, right side). In the decomposition, processes
functional
integration
body

...

De p. A processchain
in white
engine
chassis

De are subordinated and build a local hierarchy by

parent-child relations. Local hierarchy means, that it
is only valid for the sphere of one parent process,
Figure 4. Multidimensional structure e.g., dependent on duration. Here, also, consistency
constraints are applied between parent and child
Structuring the Process Model. First, a general processes. But stressing the point, the pseudo-
framework for the process model has to be set up to hierarchy is crucial, as it represents the macro-
assist the process owners in integrating their structure, while the decomposition is only used for
processes in the whole picture. This supports the detailed planning.
transparency and understanding of their part in the By limiting the decomposition on each one`s
whole development effort. The general framework is own processes and using consistency checks, a
 Published in: Proceedings of the 9th Annual Symposium of INCOSE, UK, 1999

controlled co-existing of both

hierarchical concepts is process view schedule view
beneficial. • processes • activities
• parent processes (decomposition) • roll-up activities
PROCESS LIFE CYCLE • inputs and outputs, O/I-links • work agreements
Ideally, the general process of • schedule/dates in MvS • schedule/dates with calendar info
modeling should be as shown in • duration in weeks/months • duration in working days
figure 6. A single use of a • roles • organizational instances
MvS: months before start of serial production

process model would be EG-232 Controller EG-232

Aufbau der HW beim

Monteur EG-232 Tester
Komponententest/
Überwachung Systemliefer- Komponententest / Systemlieferant

unsufficient regarding effort- ranten-W eiterentwicklung Systemlieferanten Systemlieferant

2 Monate Prozeßkette PS E65 2 Monate Prozeßkette PS E65 2 Monate Prozeßkette PS E65 Bewertung der
Vorleistungsphase Vorbereitungsphase Vorbereitungsphase Ergebnisse

benefit ratio. Therefore a EG-232

Bewertung der Ergebnisse

Bewerter
EG-232

Bewertung der Ergebnisse

Bewerter
Design anpassen

generic process model which 0 Monate

Vorleistungsphase
Prozeßkette PS E65
0 Monate

Vorbereitungsphase
Prozeßkette PS E65

Aufbau der HW
beim Lieferanten

serves as a master plan should EG-232

Bewertung des RHS bzgl.

Externer Komponenten
Bewerter

0 Monate Prozeßkette PS E65 Bewertung der Ergebnisse

be the basis for all projects. At Vorleistungsphase EG-232

Bewertung des RHS bzgl.

Design
Bewerter

Bewertung RHS bzgl

0 Monate Prozeßkette PS E65 externer Lieferanten Bewertung RHS

each project start, the generic Vorleistungsphase bzgl Design

process model is tailored to

Figure 7. Different views on same model
project-specific requirements,
defining the project process plan. While running the important to recognize that necessary changes during
project, the processes will be modeled in more detail running the project have to be done and negotiated.
and used as the project schedule. Due to the fact that Integration of Process view and schedule view. As
there is no innovative process without changes, the mentioned above, the process model and the
Roles
scheduling model are based
Organisation project
30-month master plan on the same modeling
Tailoring to project- management,
coordination/ entities in order to easily
project specific requirements detailed planning
synchronization start
project project transfer the planned process
generic schedule map into the scheduling tool
process model process plan
“planned” “planned” start of when running a project.
project
This supports the
operational benefit a user
comparing/ comparison: intermediate states
planned vs actual
gets when modeling the
learning/
improving processes, as he can use
them later in his own
project project
project
project. In figure 7 it is
process end of shown which entities of the
schedule
plan project
“actual” process view are mapped
“actual” time
onto which entities of the
scheduling view.
Figure 6. Process Life Cycle Additionally this supports
project schedule will be subject to on-going changes. the possibility to take a
At the end of the project, the actual (as-done) project process view on an already running project based on
schedule can be used as an actual process plan to the data from the scheduling tool. Finally, there are
compare planned vs. actual process plan. Certainly, just two different views on the same data.
this can also be done with intermediate states of the
Critical modeling aspects. It is obvious that one
project schedule. This helps to learn from each
success factor is to find the right depth and width for
project and continuously improve the generic process
modeling the processes. How detailed should a
model. As it may not be possible in every company,
process map be defined a priori? Also the optimal set
due to the necessary effort, to start with first building
of attributes is still unknown: too few attributes have
a generic process model, this approach can be
a negative impact on process analysis possibilities,
adapted so that the first generic process model is
and too many attributes result in excessive modeling
generated from the last well-run project and its
effort and prevent engineers and managers from
projects schedule.
modeling the processes. This still has to be defined
Another benefit of a project process plan is the
under effort-benefit trades and is further analyzed by
transparency of critical interfaces. The different
Härtlein (1999).
process owners can coordinate their processes in
advance and are alerted by traffic light symbols if APPLICATION IN DAILY PRACTICE
others do not agree on requested inputs or do not
accept planned outputs. This agreement between all To achieve a living process model, continuous
linked process owners should be done before the updating is necessary due to on-going changes. This
project is running and delays get obvious. It is very can only be achieved by a decentral realized data
 Published in: Proceedings of the 9th Annual Symposium of INCOSE, UK, 1999

entry. That means the process owner himself should are using it, it helps to find out where people do not
model his process. This will only happen by giving want to coordinate or commit.
them an operational benefit when modeling their Brief Description of Developed Tool "TIPO". A
own processes. Otherwise the effort for doing so is specification for a SW-tool supporting the IPO
too high and people would refuse to put data into the modeling approach was written. The TIPO prototype
system. That’s why they have to be able to use the was developed by RCOM GmbH, the same company
processes modeled by them also later in their own who developed the scheduling tool already in use, to
project scheduling tool. easily support the different views of process and
schedule view on the same data
not linked Process plans are the
Process owner: linked, under coordination Process owner:
Mr. Jekyll linked, coordinated Mr. Hyde
core element of the tool.
(design) (testing) The graphical user interface
34 MvS 30 MvS 30 MvS 28 MvS
(GUI) design was kept very
I reqs O prelim. I prelim. O concept
catalog
generate
concept concept modifications
similar to the MS Word
P concept P design
38 MvS 29 MvS concept 28 MvS
forms formerly used, being
I concept I verified
methods
O simulation divided into three columns
ideas models

which represent inputs,

I: Input
29 MvS
redesign
28 MvS
P: Process
processes and outputs.
I concept P concept O improved
modifications concept O: Output Additional attributes (e.g.,
MvS: months before start of serial production
duration, responsibility, and
Figure 8: Coordinating concept type) of each process can be
captured and displayed in a
Coordination. The process owners describe their separate detail area. The navigator provides an
processes using the IPO method. This supports them overview of the existing projects, phases, and
in adjusting their differing views regarding content, owners. After selecting one of each item, the
time and other aspects of an input/output. If Mr. according process plan can be opened.
Hyde needs a ‘preliminary concept’ for his process Corresponding to the IPO method, the processes are
‘design concept’ from Mr. Jekyll, then he will interlinked with each other exclusively by output-
formulate in the tool that he is expecting that input input relations. Therefore, a connector supports
by him. This requested input is now put into a list of linking the output of one process as an input to
required inputs. It will be designated with the status another process, and vice versa.
‘not coordinated’ shown by a red traffic light, as it is In addition to the list view, a graphical represen-
a request. Mr. Jekyll can at some point in time check, tation of the process net (boxes and arrows) can be
with a filter, in this list, as to whether there are generated from the captured data.
inputs requested from him, meaning he has to deliver In a multi-user environment, this approach helps
an output. When he finds an input that Mr. Hyde to quickly establish a highly interconnected process
wants from him in the list, he can, using drag and net. This is also the basis for further analyses of de-
drop, connect this requested input to his process, pendencies and future improvements of the develop-
generating it as an output that he will deliver to Mr. ment process.
Hyde. The status is ‘in coordination’, shown by a
yellow traffic light. He can then either accept on the CONCLUSIONS
attributes of this output (contents and point in time of One of the main reasons why engineering processes
delivery) or make a change proposal to Mr. Hyde. have to be modeled and documented are the ongoing
When they finally agree on the contents, the efforts in all industries for reengineering their devel-
output/input will change status to ‘coordinated’, opment processes. Otherwise, a process would be
shown by a green traffic light. This coordination optimized that is not understood, communicated, or
process helps both partners to have the same transparent to the engineers.
understanding of what will be delivered and when. Integrated product development differs signifi-
Also, it supports an analysis of the process net, to cantly from other, sequential business processes.
find out which processes are still not coordinated, or They are rather like process nets, including manifold
better, who may be performing non-value added interrelations, feedback-loops and interaction on
processes by generating outputs that nobody wants as different hierarchy levels.
an input. More important is to analyze where The focus for integrated product development
necessary inputs are requested but nobody agreed to processes has to be on the interfaces, i.e. the
generate. So, this tool helps to understand critical information flow, shifting the view to an
issues early in process planning, and not at that point information-based process modeling.
in the project when somone is desperately waiting for Two different approaches can be distinguished
a delivery. Certainly, if someone does not want to for process modeling: decentral (everyone) and
coordinate, he will not use the tool. But if the others central (specialists). The advantage of a mixed
 Published in: Proceedings of the 9th Annual Symposium of INCOSE, UK, 1999

bottom-up and top-down, but strongly decentral, in der Produktentwicklung. Ph.D. thesis in
approach is, that it enables having a ‘living’ up-to- preparation. München, 1999
date process. To make it work in daily practice, the Igenbergs, E.: Grundlagen der Systemtechnik.
simple, but powerful IPO process modeling method Lecture notes. München, 1993.
and a flexible hierarchical concept was chosen. Lullies, V.; Pastowsky, M.; Grandke, S.:
Every engineer has to have an operational benefit „Geschäftsprozesse optimieren - ohne Diktat der
from modeling his processes, which is supported by Technik.“ Harvard Business Manager, 1998, S.
using these modeled processes later in his project 65-72.
scheduling, as well. Negele, H.; Fricke, E.; Igenbergs, E. (1997): "ZOPH
Still, there seems to be a lack in understanding — A Systemic Approach to the Modeling of
the special characteristics of development processes, Product Development Systems." Proceedings of
which might be a hint as to why many reengineering the 7th International Symposium of INCOSE, 1997
activities of engineering processes in different Negele, H.: Systemtechnische Methodik zur ganz-
industries failed. heitlichen Modellierung am Beispiel der inte-
Further work has to prove the benefit of the grierten Produktentwicklung. Ph.D thesis,
presented approach in a company-wide daily Technische Universität München, Utz Verlag,
practice. Up to now, the method itself was highly 1998
accepted and the presented approach is used in Walther, C.: Systemtechnische Verfahren zur
several small projects. Also, process metrics have to Bestimmung der Zusammenhänge zwischen
be developed to analyze the process maps generated Eigenschaften und Funktionsstrukturen
by the IPO modeling to facilitate further technischer Systeme. Ph.D. thesis, Technische
improvement. Universität München, 1994.

ACKNOWLEDGEMENT BIOGRAPHY
We would like to thank Valerie Gundrum for proof- Herbert Negele is Assistant Professor at the
reading and her very valuable comments. Institute of Astronautics at the Technical University
of Munich. He received his master’s degree in
REFERENCES aerospace engineering in 1993, and his Ph.D. in
Clark, K. B.; Fujimoto, T.: Product Development Systems Engineering in 1998. His research focuses
Performance: Strategy, Organization, and on integrated product and process development, and
Management in the World Auto Industry. modeling and management of complex systems. He
Harvard Business School Press, Boston, Mass., is as founding member of the German Chapter of
1991 INCOSE, being its Vice President in 1997 and 1998.
Dörner, D.: Die Logik des Mißlingens. Rowohlt,
Reinbeck, 1989 Ernst Fricke is Assistant Professor at the Institute of
Fricke, E.: Der Änderungsprozeß als Grundlage Astronautics at the Technical University of Munich.
einer nutzerzentrierten Systementwicklung. He received his master's degree in aerospace
Ph.D. thesis. Technische Universität München, engineering in 1994, and his Ph.D. in Systems
Utz Verlag, 1999. Engineering in early 1999. His research focuses on
Fricke, E.; Negele, H.: „Informationsbasiertes changes during product development, requirements
Systems Engineering zur Erhaltung der Wettbe- management, and the integration of the customer
werbsfähigkeit der Luft- und Raumfahrt- into the entire product development cycle. He is a
industrie.“ Proceedings: Deutscher Luft- und founding member of the German Chapter of
Raumfahrtkongress, München, 1997 INCOSE.
Fricke, E.; Negele, H.; Schrepfer, L.; Dick, A.; Lutz Schrepfer is Manager Professional Services at
Gebhard, B.; Härtlein, N.: „Modeling of the Digital Media Division of TECMATH, a systems
Concurrent Engineering Processes for Integrated company for professional applications in
Systems Development.“ Proceedings of the 17th engineering, business and science. Until the end of
Digital Avionics Systems Conference (17th 1998 he was Research Assistant at the Institute of
DASC) „Electronics in Motion“, IEEE, Astronautics at the Technical University of Munich.
Bellevue, WA, 31 October - 6 November 1998. He received his master's degree in aerospace
Gartz, P.E. (1997): "Commercial Systems Develop- engineering in 1995. His research focused on
ment in a Changed World." IEEE Transactions modeling and simulation of complex systems. He is a
on Aerospace and Electronic Systems, 33, 2, founding member of the German Chapter of
632-636. INCOSE, being its Secretary in 1997 and 1998.
Gundrum, V.. (1999): „Architecture for a Process
Meta-System“. Proceedings of the 9th International Nicole Härtlein is a doctoral student at the Institute
Symposium of INCOSE, 1999. of Astronautics at the Technical University of
Härtlein, N.:Prozeßgestaltung und -Dokumentation Munich and is working on her Ph.D. thesis in
 Published in: Proceedings of the 9th Annual Symposium of INCOSE, UK, 1999

Systems Engineering for BMW, department basic

elements of future vehicle design. She received her
master's degree in mechanical engineering in 1996.
The is member in the working group of knowledge
management at BMW. The focus of her work is on
process design and documentation in product
development. She currently is the Vice President of
the German Chapter of INCOSE.