See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/261612686

Systematic optimization of the Product Development Process with PLM-ML

Article · April 2013

CITATION READS

1 1,202

4 authors, including:

Jörg W. Fischer
Karlsruhe University of Applied Sciences
20 PUBLICATIONS 110 CITATIONS

SEE PROFILE

All content following this page was uploaded by Jörg W. Fischer on 15 April 2014.

The user has requested enhancement of the downloaded file.

48 PROJECTS

Systematic optimization of the

Product Development Process
with PLM-ML
Prof. Dr. Jörg W. Fischer, Martin Rebel, Bernhard Lammel, Jürgen Gruber

Increasing productivity, driven by the pressure of costs and competition, is a core strategy element of all global
acting companies. Manufacturing companies persecute this goal, beginning from continuous improvement of
their manufacturing processes as far as optimizing global supply chains. The idea of optimization is progressively
applied to the Product Development Process (PDP) and discussed under the term Product Lifecycle Management
(PLM). Contrary to this, PLM projects basically focus on IT implementation. Hereby, the idea of optimization
often becomes lost. One cause is to be seeked in the complexity of the PDP. The PDP can hardly be captured
and optimized with existing modeling methods. Against this background PLM-ML was developed by the
authors as an instrument to easily capture and optimize the PDP. This article explains PLM-ML and exemplifies
how the PDP can be optimized utilizing PLM-ML.

The idea of PDP optimization
Manufacturing companies are facing the
challenge of continuously increaseing
their productivity in order to withstand
the pressure of global competition in the
future. Thereby, they are achieving great
success through optimization of operation
procedures, improvement of organizatio-
nal structure as well as the use of new
manufacturing and production technolo-
gies. Currently the idea of optimization is
increasingly adapted to the PDP as the
awareness of so far unutilized potentials
within the PDP, particularly for its
downstream processes, grows.
These discussions are primarily bound
under the buzzword Product Lifecycle
Management (PLM). Since PLM is tightly
coupled to implementation of IT techno-
logies, PLM is prevalently conducted as
an IT implementation project within IT
departments. Thereby the intrinsic idea
of optimization is oftentimes lost. Appa-
rently one main cause for this is the
distinct focus on information technolo-
gies. Agley a further problem, which
typically gets lost in the fog of the IT
projects and currently drawing insuffi-

Figure 1: A new point of view to understand the Product Development Process (PDP)

ProductDataJournal No. 1 I 2013


cient attention, exists. The PDP is extra-
ordinarily complex. Using existing model-
ing methods, it is nearly impossible to
depict the PDP. Modeling Tools for a
transcend discussion on optimization are
missing as of today. Hence, in the Frame
of the development of Do(PLM)Con
methodology the PLM Modeling Langua-
ge (PLM-ML) was designed as a tool to
enable a discussion on optimization of
the PDP.
A new approach to perceive the
PDP
Genesis of PLM-ML was expert discussions
of PLM architects which aimed to define
“industry best practices” for PLM. In
context of these discussions conducted,
analysis of industrial applications consi-
derable weakness in existing modeling
instrument, such as functional analysis,
process chain representation or IT system
landscape maps, were found. The result-
ing depictions were quickly getting too
complex. Beyond that essential PLM
aspects could not be represented with
existing methods at all.
After some time of intensive discussions
a new view based on a systemic model-
ing element emerged, whose significance
was not recognized sufficiently. To develop
a product, engineers are imagining it and
it's production beforehand. Therefore
they use models. Each domain (e.g.
Requirements Management, mechanical
and mechatronic design, documentation,
etc.) is using their own specific models.
Those models provide ample detailed
Figure 2: (Partial-)Product Model as seed crystals of the processes within PDP
No. 1 I 2013
Figure 3: Aspects of (Partial-)Product Models
aspects of the future product for the
specific application area. Hence each of
those models is a (Partial-)Product Model
(shortly: Partial Model) of the future
product.
Based on those considerations, the
modeling approach shown in Figure 1
was developed. It combines the process
oriented view with the idea of the
systemic modeling element “Partial
Model”. Processes of the PDP are thereby
differentiated in three categories.
Management processes are controlling
the PDP (Figure 1, top). Typically they are
processed with the help of milestone
PROJECTS 49
schedules. The daily operating processes
of the PDP are activated through a mile-
stone of the management process or
they end up by one of its milestones.
They can be subdivided into long-term
stable processes (meaning release and
change processes, see Eigner 2012, p. 21)
and daily engineering processes. Contrary
to daily engineering processes, stable
processes are explicitly defined and
generally controlled by workflows in data
management systems. All daily processes
within PDP produce, utilize, change or
extract information into or from Partial
Models. As a result, Partial Models can
be seen as the seed crystals of the pro-
cesses within PDP (Figure 2).
The benefit of the considerations in Figure
1 and Figure 2 is the accomplished
simplification. Following this approach
the PDP can be analyzed and depicted
through its Partial Models. Since the
number of Partial Models is much less
than the number of processes within the
PDP, their level of detail can far better be
harmonized and additionally they can
easier be localized which is an essential
modeling advantage
Several fundamental characteristics of
Partial Models can be described as follows.
A Partial Model is always an instance of a
Partial Model type. Figure 3 exemplary
shows instances of various Partial Model
types for the product line “Dumper
Truck” (Figure 3, top) and “Digger”
(Figure 3, bottom). Partial Model instances
of the same type often possess commu-
nality, meaning shared usage of compo-
nents with, where required, various
ProductDataJournal
50 PROJECTS
occurrence in context of the specific
product line (Figure 3, shared component
“underbody”). Different Partial Model
types (Example Figure 3, bottom, Model
types of product line “Digger” from left
to right) often contain redundant infor-
mation and similar model elements since
they are a reproduction of the same
entity. A usage in a usage model (e.g.
tire) has an equivalence in the bill of
material model (the for this usage supp-
liable tire with varying profile and specific
rubber composite) and an equivalence in
the virtual prototype. The validity and
significance in those model types is
however diverging (e.g. a CAD model is
not designed for each type of rubber
compound). To consolidate diverging
model types of the same product a com-
parison of the significance of the model
type’s elements is necessary. This leads to
an adaption of semantic and, therefore,
to a change in mode of operation in at
least one of the two model types.
PLM-ML as an instrument for
modeling and optimizing the
PDP
To enable the usage of the previously
outlined theoretical view in practice, the
PLM-ML was developed within the scope
of Do(PLM)Con methodology (Fischer
u.A. 2011). PLM-ML is a semiformal gra-
phical modeling language which enables
analyzing and optimization of company
Figure 4: Life Time & Information Flow diagram “Current State“
ProductDataJournal
individual PDP realizations. It uses the
Partial Model as the central modeling
element. PLM-ML is inspired by value
stream design and especially adopts the
idea of alignment of the PDP to specific
Customer Values as well as the idea of an
easily understandable, less formal graphic
notation technique. Also, the separation
between current state and a future state
to be reached is adopted. Therefore, the
PLM-ML provides several types of dia-
grams, which can be categorized in the
following groups:
n Partial Model Landscape
n Partial Model to Process
n Partial Model Detail
n Partial Model Interaction
With diagrams of the group “Partial
Model Landscape” maps of the relevant
Partial Models of the PDP can be depicted
including their cross linking over a time
axis. Areas with high potential for opti-
mization can be easily located on those
landscape maps. Such areas are then
further detailed with the help of the
diagrams of the other groups. This
approach enables reducing the analyzing
efforts by keeping the focus on the
essential key aspects. The group “Partial
Model to Process” combines the Partial
Model concept with the process view.
The incorporated “Partial Model/Process
Chain” diagram is based on the event-
driven process chain (EPC) (see Keller, G.;
Nüttgens, M.; Scheer 1992, p. 13), but
substitutes the information object used
in EPC with the modeling element “Par-
tial Model”. The groups “Partial Model
Detail” and “Partial Model Interaction”
focus on the Partial Models itself. They
enable for analyzing static structure
(semantics), time behavior (progression)
as well as integration of different Partial
Models.
Optimizing the PDP of a medium
sized machine tool manufacturer
Following the usage of PLM-ML is shown
on the example of a typical tool manu-
facturer. The case is anonymized and
simplified. The company builds machines
with far more than 1000 parts per
machine in single or limited-lot producti-
on. They offer an open variant configura-
tion to their customers, meaning the cus-
tomer can order individual variants which
are then design and produced for the
particular order. In the context of a dis-
cussion of weak points with the company
design and manufacturing teams, two
essential problems were recognized as
essential pains.
The company does not have any
alignment process to keep the CAD and
the BOM-Data synchronized. Thus often
the wrong parts or components are
supplied and provided in prototype and
order production, leading to massive
wastage of time and enormous additional
No. 1 I 2013

costs. A further problem is caused by the
much too long cycle times while proces-
sing orders with high amount of customer
specific development. The main competi-
tors are often able to deliver faster and
therefore important orders are frequently
lost.
The company spends a lot of time trying
to improve this situation. However, they
were trapped in the typical pitfall of iso-
lated optimization without understanding
the whole PDP. To improve this the Life
Time & Information Flow diagram of
PLM-ML was used to analyze the com-
plete company individual PDP on a high
abstraction level (Figure 4 and 5). This
diagram type provides a time-related
general view of interacting Partial
Models in course of the PDP. Rectangles
are representing the relevant Partial
Models. Arrows and lines are depicting
the crosslinking between Partial Models.
The dedicated symbols at the arrows are
furthermore used to characterize the
crosslinks. The time axes document
essential milestones or events of the PDP.
Clouds are used to define out of scope
areas for simplification of the diagram.
The diagram depicted in Figure 4 shows
the analyzed “Current State” of the PDP.
Upon a receipt of an order, a product
engineer arranges the necessary assem-
blies for this specific order based on his
experience. For this he creates a Pre-Pro-
Figure 5: Life Time & Information Flow Diagram “Future State“
No. 1 I 2013
duct-BOM. The fundamental information
for the Pre-Product-BOM he attains from
CAD-Assemblies stored unstructured
within the Team Data Management
(TDM) system (Figure 4, CAD Cluster).
From the TDM-System he extracts the
part information which is enclosed in the
CAD-Assemblies semi-automatically into
Excel files and puts the necessary infor-
mation in the Pre Product BOM (Figure 4,
Pre Product BOM). Necessary customer
specific adaptations are then discussed
with product engineers responsible for
specific CAD-Assembly during meetings
and on the telephone. The results of
these meetings are also documented
by the product engineer within the Pre
Product BOM. Subsequently, the equiva-
lence between CAD and BOM for adap-
ted parts (Figure 4, material master) is
clarified with different ERP specialists by
telephone. Before completion of the
design phase, the product engineer
initiates the creation of the Master Product
BOM (Figure 4, Master Product BOM)
based on the Pre Product BOM.
Areas A & B (Figure 4, circuited) were
identified as substantial origins of the
problems during analysis of the PDP. Area
A affects mechanical design. CAD data is
managed and released within the TDM
system, but there is no differentiation
between research and product compo-
nents. Development at this company
takes place only in scope of orders. To do
PROJECTS 51
this available components of existing
products are copied and then adapted
for the specific new product. The use of
identical modules between different
product lines, so that enhancements of
a component during its lifecycle can be
shared by all products, is not possible.
Since the company suffers enormous
difficulties, arranging and passing on
current working data and collaboration
with suppliers is only possible with tre-
mendous efforts and so is mostly avoided.
Area B is related to interaction between
product engineers and purchasing.
Material master and Pre-Product-BOM
lists are neither linked by it technology
nor semantically associated. Hence, pur-
chasing has no knowledge about the
materials being relevant for development
of new products. Therefore the product
engineer is usually not informed about
changes of the material master. Further-
more, inapplicable components are often
ordered, then having to be amended and
newly ordered. Extended delivery times
and gratuitous additional costs are the
consequences. An attempt to reduce
costs through purchasing strategies
aggravates this situation. This only leads
to further changes of the material master
and in consequence incalculable effects
on orders in development. Figure 5 illus-
trates the enhanced and already success-
fully implemented “Future State”. The
unstructured CAD cluster was substituted
by CAD product structure being calibrated
ProductDataJournal
52 PROJECTS
for each order (Figure 5, CAD structure).
It also replaces the Pre Product BOM.
Furthermore, an explicit partial model for
standard part being synchronized with
the material master was introduced. As a
basis for a research and development
(R&D) process that is decoupled from
order development, a CAD cluster for
R&D components (Figure 5, R&D CAD
model) was installed and connected to
the CAD product structure through so
called “Cross Model Based On Clone”.
Thus modules being adopted from R&D
model into the CAD product structure
are copied, but remain linked to their
origin. So they are decoupled for their
origin and could be developed indepen-
dently but are still able to access their ori-
gin. This enables the share of innovation
of the R&D model to all derived CAD
product models. Organizationally this is
conducted by a “Module Owner”,
responsible for a specific module across
multiple orders. This concept gives the
company the flexibility to develop modules
earlier and independent of customer
orders and to use them in several pro-
ducts.
The quintessence of the new concept is
the implementation of an automated
process between CAD Product Structure,
Master Product BOM and ERP Material.
The CAD Product Structure is defined
as the leading model. Each newly created
CAD model automatically generates a
counterpart in the ERP Material and if
necessary in the Master Product BOM.
Non-synchronous BOM and CAD data
is eliminated for this reason and possi-
bility to automatically generate a
Master Product BOM from the CAD
Product Structure at any time exists.
Realization of this approach demanded
for an adjustment in information
management and hitherto mode of opera-
tion.
The Models were semantically modified
in such an extent that elements of the
CAD Product Structure have distinct
equivalences in each other’s Partial
models (Figure 4, detail 1, Model Type
Alignment). The original functional and
structural semantics of CAD Product
Structure were thereby converted into
logically oriented semantics. To ensure
unambiguousness at any time, relevant
allocation case between models were
carved out and specific solutions were
defined in each case. As an allocation
cases bars shall be mentioned as an
example. Those bars are obstructed in
different lengths. Only actually obstructed
lengths are modeled in the CAD Product
ProductDataJournal
View publication stats
Structure. In the ERP Material only pur-
chasable standard lengths are recorded.
Allowing a distinct assignment between
the parts in the Master-Product-BOM and
the models of the parts within the CAD-
Product-Structure was done through
introducing the possibility to define the
obstructed lengths and additionally the
resulting standard lengths of bars already
within the CAD-Models in the CAD-
Product-Structure. Only with the solutions
for those allocation cases it was possible
to invert the direction of supply from
BOM to CAD driven and also to control
the ERP Material as well as the Master
Product BOM by the CAD Product Struc-
ture. Contrary, it is generally defined
impossible that changes are initiated by
the ERP Master. Beyond that, deriving a
logistically oriented 3D model (not
shown by diagram) which can serve as a
basis for installation and repair by service
employees being on-site with the custo-
mer is made possible by the rearrange-
ment of structure semantics of the CAD
Product Structure to a logical orientation.
Further optimization
Future State shown in Figure 5 is currently
serves as a basis for further optimization.
Therefore, it is now the Current State
that shall be transformed into a new
Future State. Potentials still rest in a more
precise clarification of coactions between
R&D models and CAD Product Structure
(Figure 5, detail 2). Currently models are
functionally held together by one person
and modules are copied with reference
to their origin. An improvement can be
conducted if utilizing the same modules
and context-sensitively adjusting them
succeeds. Above all, considerable possi-
ble savings are identified in even more
consequent usage of modules through
products and product lines. Implementa-
tion requires a more precise analysis of
the product spectrum to define which
information has to be adjusted context-
sensitively in particular products and
which can be kept generic.
Conclusion and Outlook
Evidently the example shows that optimi-
zation of production is different from
optimizing the PDP in principle. Production
optimization generally focuses on cut
down of capacities of human resources,
while optimization of PDP focuses on
intelligent, context- and time-sensitive
crosslinking of information. Optimization
is thereby successful when combining
optimization of information flow between
relevant partial models with clarification
and reorganization of responsibilities of
the created information during their life-
cycle in the PDP.
PLM-ML enables a discussion on optimi-
zation of the PDP. Diagrams of PLM-ML
are independent of future applicable IT
systems, so that a discussion can be con-
ducted neutral to vendors and systems.
In scope of the Do(PLM)Con consulting
approach, PLM-ML can show off yet
another advantage. Since PLM-ML enables
representation not only for a functional
view but also semantics and progression
of relevant information of the PDP, it is
possible to plan implementation of
appropriate PDP IT systems more precisely
and more systematically than ever before
(see Fischer, Brinkmeier 2012). n
References:
Fischer, Jörg W. u.a.: Implementierung domänenintegrie-
render PLM-Lösungen. Do(PLM)Con – ein Ansatz
zur Konzeption und Realisierung domänenintegrie-
render PLM-Lösungen. In: Industrie Management,
Berlin, 27(2011)5, S. 17-21.
Fischer, J.W., Brinkmeier, B.: Do(PLM)Con – Proposal of a
taxonomy for the development of PLM-Architectures.
In: ProductDataJournal, (2012)1, S. 24-28
Eigner, M.: PLM versus PPS: Zukünftige Lösungen für ein
durchgängiges Produkt- und Prozessmanagement,
In: eDM Report; electronic Data Management, Hop-
penstedt Publishing, Darmstadt, (2012) 1, S. 20-23.
Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische
Prozeßmodellierung auf der Grundlage „Ereignis-
gesteuerter Prozeßketten (EPK)“, in: Scheer, A.-W.
(Hrsg.): Veröffentlichungen des Instituts für Wirt-
schaftsinformatik, Heft 89, Saarbrücken 1992.
(http://www.iwi.uni-sb.de/iwi-hefte/heft089.pdf)
Contact
Prof. Dr. Jörg W. Fischer.
Hochschule Karlsruhe
– Technik und Wirtschaft
Fakultät für Maschinenbau
und Mechatronik
Phone: +49 173 3675220
E-Mail: joerg.fischer@hs-karlsruhe.de
Martin Rebel, M. Eng.
Siemens Industry Software
GmbH & Co. KG
Phone: +49 151 42248392
martin.rebel@siemens.com
No. 1 I 2013