ArticlePDF Available

Abstract and Figures

Successful companies spend many of their resources in the initiation and realisation of innovation projects, which might be successful at the market. Especially in the early phase of these projects, there is a high degree of uncertainty and therefore, product profiles established themselves as methodological support for product developers. However, it is not possible to give developers a straight and always equal process to follow for developing these product profiles. Based on this problem, this contribution investigates context-independent process steps to develop promising product profiles. Thus, this work provides a possible reference process to develop product profiles to support product developers in the early stage of innovation projects. Therefore, 631 process steps of 16 innovation projects were analysed and 100 process steps were derived from literature. Based on an expert workshop, 48 of these process steps were identified as relevant to consider in a context-independent reference process model. In a further empirical Live-Lab study, process patterns were investigated and the usability and relevance of the process steps were evaluated as positive.
Content may be subject to copyright.
Cite this article: Wilmsen, M., Dühr, K., Heimicke, J., Albers, A. (2019) ‘The First Steps Towards Innovation: A
Reference Process for Developing Product Proles’, in Proceedings of the 22nd International Conference on Engineering
Design (ICED19), Delft, The Netherlands, 5-8 August 2019. DOI:10.1017/dsi.2019.173
ICED19
INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN, ICED19
5-8 AUGUST 2019, DELFT, THE NETHERLANDS
ICED19
THE FIRST STEPS TOWARDS INNOVATION: A REFERENCE
PROCESS FOR DEVELOPING PRODUCT PROFILES
Wilmsen, Miriam; Dühr, Katharina; Heimicke, Jonas; Albers, Albert
Karlsruher Institut für Technologie (KIT)
ABSTRACT
Successful companies spend many of their resources in the initiation and realisation of innovation
projects, which might be successful at the market. Especially in the early phase of these projects, there
is a high degree of uncertainty and therefore, product profiles established themselves as methodological
support for product developers. However, it is not possible to give developers a straight and always
equal process to follow for developing these product profiles. Based on this problem, this contribution
investigates context-independent process steps to develop promising product profiles. Thus, this work
provides a possible reference process to develop product profiles to support product developers in the
early stage of innovation projects. Therefore, 631 process steps of 16 innovation projects were analysed
and 100 process steps were derived from literature. Based on an expert workshop, 48 of these process
steps were identified as relevant to consider in a context-independent reference process model. In a
further empirical Live-Lab study, process patterns were investigated and the usability and relevance of
the process steps were evaluated as positive.
Keywords: Design process, Innovation, Process modelling, Product Profile, Early design phases
Contact:
Heimicke, Jonas
Karlsruher Institut für Technologie (KIT)
IPEK - Institut für Produktentwicklung
Germany
jonas.heimicke@kit.edu
1673
ICED19
1 INTRODUCTION
Industrial trends as shorter product lifecycles, emerging technologies and saturated markets toughen
the innovation pressure of mechatronic product engineering companies. Hence, many large companies
try to strengthen the early phase of product engineering projects through introducing methodological
approaches as e.g. design thinking, lean start-up (Schmidt and Paetzold, 2016), as well as implementing
new organizational structures as e.g. an innovation newstream to increase the innovative capabilities of the
company (Lawson and Samson, 2001). Nevertheless, large companies need a systematic support to
identify the most promising ideas in a very early phase of the product engineering process to reduce
uncertainties and to evaluate the economic and technical risk (Gassmann and Bader, 2017). Therefore,
a methodological support is necessary to improve the initiation and discovery of new product
engineering projects. As stated before, there are already different approaches available to support this,
but in many cases, these approaches are very generic and not tangible enough for product developers.
In the past, product profiles were able to establish themselves in order to support product developers in
the initiation and discovery of new product development projects at an early stage. A product profile
considers the intended customer, user and provider benefits, specifies the technical solution space of the
new product generation and makes these aspects accessible for an early validation (Albers et al., 2018). The
development of these product profiles differs from project to project, because every engineering project is
individual and unique (Albers, 2010; Smith and Morrow, 1999). Thus, it is not possible to follow a strict
process to develop promising product profiles in practice. In contrast, it is important to provide
developers a methodological framework to combine their practical experiences with theoretical
background to enable them to develop promising product profiles. Thus, the objective of this
contribution is, to provide product developers a possible reference process, which consists of different
process steps to develop promising product profiles. The developers can use these process steps to
plan their own process considering their project context and their specific boundary conditions.
2 STATE OF THE ART
2.1 Design processes
Although each product development process is unique, recurring elements exist across different
projects (e.g. content recurring elements or time recurring elements) (Smith and Morrow, 1999). In order to
support product development processes appropriately, to avoid development risks or to make processes
robust, a large number of process models were developed that represent product development processes
from different perspectives and with different purposes. These models can be distinguished, for example,
by their degree of abstraction from activities or the supported project level (Wynn and Clarkson, 2018).
In addition to the pursued purpose with a process model, the handling of iterations also influences
the design and use of process models (Wynn and Eckert, 2017). In the field of mechatronic system
development, companies are increasingly implementing agile development processes in their
organisation (Schmidt and Paetzold, 2016), which are replacing the established, plan-driven
approach (Boehm and Turner, 2003). For example, flexible approaches such as Scrum (Schwaber
and Sutherland, 2017) or Design Thinking (Ge and Leifer, 2017) promise companies improved
handling of uncertainties arising in the process (Schmidt and Paetzold, 2016). However,
uncertainties in development processes have existed for a long time (Thomke and Reinertsen, 1998),
and the established agile approaches quickly reach their limits due to their lack of technical
orientation (Heimicke et al., 2018) which means that a process model has to be able to represent
both iterations and classical sequences of activities. The approach of the ASD - Agile Systems
Design (Albers et al., 2018) allows engineering teams to pursue a flexible or sequential approach
depending on the respective development situation. This approach continuously integrates the way
of thinking of the PGE - Product Generation Engineering (Albers et al., 2016a) and thus the
necessary technical knowledge. As a process model, the ASD approach uses the iPeM - integrated
product development model, which is shown in Figure 1 in its two-dimensional view (Albers et al.,
2016b). The iPeM is based on the idea of the Ropohl system triple (1975) and contains all necessary
elements to derive a situation- and demand-dependent, individual product development process.
The transfer of a system of objectives into a system of objects by an operation system is described by
the combination of product engineering activities with problem solving activities. The system of
1674
ICED19
objectives contains all objectives, their reasons, interactions, derived requirements and boundary
conditions for a solution. The system of objects contains all objects generated in the product creation
process (partial solutions, sketches, models, prototypes and finally the product). The operation system
is formed by all resources (employees, infrastructure, capital, etc.), knowledge, methods, processes
and tools necessary for the transformation of the system of objectives into the system of objects. The
product engineering activities consist of the basic activities (project management, validation and
verification, knowledge management and change management) and the specific activities that cover
the complete product life cycle. Each of these activities is modeled as a problem solving process in the
product development process. The problem solving methodology SPALTEN is used, which consists of
the steps situation analysis (S), problem containment (P), detection of alternative solutions (A),
selection of solutions (L), analysis of consequences (T), deciding and implementing (E) and
recapitulation and learning (N). This results in 84 generic situations (activity matrix), which are
supported by different methods. (Albers et al., 2016b)
Figure 1. 2D representation: integrated product engineering model (Albers et al., 2016b)
The chronological sequence of activities in the product development process is depicted in the phase
model of the iPeM (Figure 1 right part). Parallelization, iterations as well as sequences of activities can
be displayed here. The phase model can also be used to document, further develop and use process
knowledge and experience from various projects. Thus, it maps up to three models. The model of the
reference process describes a company-specific, generic process that describes the usual sequences of
activities, methods and processes for developing different products. It is derived on the basis of
various experiences from different projects. The reference process is used during the initiation of a
new development project to derive a TARGET process (a type of project plan) from the reference
process based on the empirical knowledge. The reference process is adapted to the specific
requirements and boundary conditions of the respective development project when deriving the
TARGET process. The TARGET process serves the development team as a time and content
orientation in the development project. The actual course of the project is documented in the
ACTUAL process in the iPeM. This usually rejects the TARGET process due to unforeseeable
circumstances in the development process. The delta resulting from the ACTUAL and TARGET
processes can therefore be used, for example after a development project, to adapt the reference
process if necessary. In this way, process knowledge can be used, reused and further developed over
generations of developed products, enabling the development of mechatronic systems to be
continuously made more robust and efficient. (Albers et al., 2016b)
2.2 Product profiles and the identifying potentials phase to detect market needs
Wynn und Eckert (2017) describe a large number of different iterations in the product development
process, including exploration as Iterating around problem and solution while elaborating them
concurrently. In the understanding that the product development process is a problem solving process (a
problem is characterized by: undesirable initial state, desired final state and barrier, that prevents the
transformation from initial to final state at the moment (Dörner, 1979)), the final product then represents
1675
ICED19
the solution in the sense of exploration. Since products always satisfy a demand situation on the market,
this demand situation represents the problem in the product development process (Albers et al., 2018).
Although the probability of later product success is very high if the product satisfies a real demand on
the market (Cooper and Kleinschmidt, 1987), the identification and anticipation of a really relevant
demand situation on the market is not trivial and a project in the process of product development
characterized by uncertainties. Moreover, the respective demand situation usually lies in the future and is
difficult to anticipate from the present (Chong and Chen, 2010). In order to support product developers
in the process of product development in identifying relevant demand situations, there is a multitude of
practices and methodologies. For example, developers use the persona method to put themselves in the
perspective of potential customers with the associated requirements (Schäfer and Keppler, 2013).
Another established procedure for the continuous validation of the customer value represented by a
product is the creation and validation of a Minimum Viable Product (MVP) (Münch et al., 2013). In
ASD - Agile Systems Design, the product profile represents a model of a number of benefits that makes
the intended provider, customer and user benefits accessible for validation and explicitly specifies the
solution space for the design of a product generation(Albers et al., 2018). An example for a product
profile is given in Figure 2. The product profile is generated in the meta-process of the ASD during the
Identifying Potentials Phase and in the subsequent phases is expanded and adapted with regard to new
findings in addition to the continuous development and advancement of prototypes. During this phase,
development teams follow an iterative approach. The focus lies on the continuous development and
safeguarding of demand situations from the customer, user and provider perspective. In addition, existing
technical systems are examined with regard to their potentials and potential entry points into the markets
are identified, considering competitors. The existing information in the product profile indicates the
further search direction for the developers to complete the profile. It contains a large number of
information clusters with consistent content for the complete description of a future potential demand
situation on the market. This enables developers to align continuously the generated technical solutions
with the product profile (Albers et al., 2018). These solutions are validated in the process against the
product profile, whereby problem and solution are iteratively worked out and concretized in terms of
exploration (Wynn and Eckert, 2017).
Figure 2. Example for product profile (Albers et al., 2018)
Boundary Conditions / Framework
Installation of the new clutch systemmust be possiblein the def ined, existingdesign spaces of the transmissionbell
housing between theengine and the gearbox
Shifting forces and shift qualityas w ellas starting quality and startingper formancemust not beimpaired
No negative effects on powertrainperformance(acceleration, hillclimbing ability, loadcapacity , ...)
Validation of the … through
Custom er profilethrou ghm arketa nalysis andcustomersurvey
Construction ofprototype vehicles and comparis on through NVH assessment to
ensurekeyadvantage
...
Refere nce Products
Engine flywheel
Torsiona lda mpers ofKS
Use Case
The higherrotational irregularitiesof new er engines andthe trend to low
engines peed operationto reduce fuel consumptionlead to noise and
vibrationin the vehicle that will resultin customer complaints and make these
new vehicles olutionsunsalable
Provider Benefit
First to Market
New product with excitement
attributesf or the customer
(vehicle OEM) as it enables new
potentials( efficientengines, low
fuel consumption) in the vehicle
High efficiencynew pricing
3
Customer Benefit User Benefit
Competitive Context
Torsion damper at their
performance limit
Competitive products can not
fulfillthe f unction
...
Demand
New engin es with higher power den sity and low fuel consu mption should be realized in
order to increase please in dri ving through ev en more agile vehicles while at t he same
time reducing f uel consumption
Vehicles with dies el engines (av erage size: 1.6 .. . 2.4 l displacement ) should be introduced
into new vehic le segments in order to realize f uel sav ings as cus tomer benef it
...
Initial Product Description
Integr ationof the engine flywheelinto thede sign spaceof the clutch system
Split into two rotational inertiasto change the vibration system
No increase in the shifting fo rces
No increase in total inert ia
Service life Engine operatinglife
Fitting in previouslygiven design space
Product Profile Claim
We need a system that makes the rotational irregularities caused by the engine at low speed (1000-
2800 rpm) in the powertrain from the perspective of NVH - with a focus on transmission and body
noise reduction -manageable, mak ingt heproduct with the new c ombustion engines acceptab le for
the market.
Vibration reduction allows t heus e of
new engines with better ef ficiencies
and better perf ormance
Function integrat ion in t he given
design space, so that no major
changes in t hepower trains m ust be
done
Big developm ent problem of the
sys tems (new vehicle generations) is
solved
...
New vehic les olutions with improv ed
engine, low fuel cons umption, high
fuel econom y and im proved driv ing
pleasure
Noise / vibrat ion reduction
Comf ort
...
Engine
1676
ICED19
3 NEED FOR RESEARCH, RESEARCH QUESTIONS AND RESEARCH
METHODOLOGY
In literature and practice, there are several approaches to support the initiation and discovery of new
product engineering projects in an early phase. However, these approaches are most often too generic
and need a specific adaptation to the respective development project. This leads to a bigger hurdle that
prevents developers from using a methodological approach to initiate and to discover new product
development projects in an early stage. To overcome this hurdle, this contribution aims to provide a
possible reference process for engineers to develop promising product profiles, while considering
specific boundary conditions. Therefore, this contribution will give an answer to the following
research questions:
How do engineers develop product profiles in practice?
Which process steps are at least relevant to consider for developing product profiles?
Which process patterns can be identified through an analysis of actual processes for developing
product profiles?
As shown in Figure 3, the research methodology is based on DRM - design research methodology
(Blessing and Chakrabarti, 2009) and consists of several empirical studies. For answering the first
research question, empirical process data from 16 engineering projects with four different innovation
challenges was analysed to identify overall 631 process steps which were executed by the different
engineering teams. Although the majority of these process steps overlapped, there were also very
different and context-specific process steps. Through a literature review of theoretical process models,
which have similarities to the development of product profiles, a list of around 100 process steps
resulted. To identify the at least relevant process steps, the 631 empirical process steps of the different
teams were compared with each other and clustered to reduce the total number of process steps.
Furthermore, these empirical process steps were linked to the process steps, which were derived from
theoretical process models out of literature. As it was possible to link nearly every process step based
on the empirical data, with a theory-based process step, these 100 process steps were considered as
plausible regarding the development of product profiles. Through an expert workshop with six design
researchers, who have a broad experience with developing product profiles, the most important,
context-independent 48 process steps were identified. Finally, all 48 process steps were described in
detail and were linked to possible methods to build a possible reference process for developing
product profiles.
Figure 3. Research methodology based on DRM - design research methodology
For answering the last research question regarding the relations between the process steps, two
empirical studies were conducted. Furthermore, these studies were also used to evaluate the usability
of the provided reference process, as well as the importance of the 48 process steps. Firstly, a
laboratory study with 13 engineering students was executed for a first evaluation of the reference
process. The participants were split into four teams and had to develop a promising product profile
within 60 minutes. They were allowed to use the provided 17 process steps to make a small project
plan and to document their ACTUAL process. As the results of the first study were positive, a second,
Descriptive Study I Prescriptive Study I Descriptive Study II
Analysis of empirical
process data from 16
engineering projects
with 4 different innovation
challenges from Live-
Labs concerning the
development of product
profiles
Analysis of theoretical
process models from
literature, which have
similarities to the
development of product
profiles(e.g. iPeM,
UCDP, Design Thinking)
Comparison, clusteringand
linkage of the process steps
631 process steps100 process steps
Expert workshop to rate the
importance of the process steps
Reference process with 48
process steps for developing
product profiles
Descriptionof the process steps
and linkage to possible methods
Laboratory study with 13
engineering students for a first
evaluationof the usability of the
reference process with an
extract of the process steps (17
process steps)
Empirical Live-Lab study with
7 product engineering teams
(38 participants) to evaluate the
process steps within the
reference process and to identify
process patterns through an
analysis of the actual processes
1677
ICED19
Live-Lab study was conducted. A Live-Lab study offers design researchers a validation environment
for design methods, processes and tools, which is close to the real-world application in contrast to a
laboratory study and allows the control of some boundary conditions (Albers et al., 2017). In this case,
the Live-Lab IP - Integrated Product Development was chosen for the evaluation of the reference
process. In IP 18/19, 38 engineering students are working in seven teams to develop innovative
solutions for a mechatronic problem within four months in cooperation with an industrial partner
(Albers et al., 2017). According to the overall process of IP, each team has to develop 3-5 promising
product profiles within the second phase identifying potentialsand had to present these to the
project partner at the milestone. Hence, the reference process to support the development of product
profiles was implemented into the agile project management tool Jira and thus each team was able to
derive their individual project plan for the three sprints which were executed within the identifying
potentials phase. After completing this phase successfully, it was possible to export all the empirical
process data from Jira and the relations between the process steps were evaluated. Additionally, a
short survey was carried out after the Live-Lab study.
4 RELEVANT PROCESS STEPS TO DEVELOP PRODUCT PROFILES
As every engineering process is unique and individual, there are many different ways to develop
promising product profiles. Through the analysis of the empirical data from former innovation projects
from e.g. the Live-Lab IP - Integrated Product Development 2017/18 (Albers et al., 2017), it was
possible to analyse different ACTUAL process models and to visualize these according to the meta-
model iPeM - integrated Product engineering Model. An extract of these different ACTUAL process
models are shown in Figure 4. This visualization shows the number of process steps (tasks) per matrix
field of the iPeM, which have been used by a team to develop promising product profiles. Each team
did use a different number of process steps during the Identifying Potentials Phase, thus the granularity
of the respective process steps differs from team to team.
Figure 4. Different ACTUAL process models from four teams of the Live-Lab IP 17/18 to
develop promising product profiles (located in the meta-model iPeM)
The visualized process steps focus mainly on the product engineering activity detect profiles, what
can be explained through the reference of the process steps to the objective promising product
profiles. Hence, there are additional process steps concerning the remaining product engineering
activities within the Identifying Potentials Phase, which are not considered within this research. An
example for this is the development of videos for presenting the product profiles to the decision
makers at the milestone. These process steps are not visualized in the figure, because these process
steps pay for another objective enabling the committee to make a decision. Thus there are much
more process steps executed within the Identifying Potentials Phase, but only the mentioned above pay
directly for the objective promising product profilesand are in the focus of this research.
Regarding the execution of the problem solving activities S - situation analysis and P - problem
containment, some teams have invested more capacities and others have done only the compulsory
process steps. This can be related to the previous phase of the innovation project, which focuses on a
broad research and deep analysis of all relevant topics and problems. Thus, some of the teams already
conducted the necessary research and others wanted to investigate more, because they identified a lack
of information during the project. Some of the teams did focus very strong on the problem solving
activity A - alternative solutions, what means that they used several creativity methods and research-
Live-Lab IP 17/18
Team 1
Team 4
Team 5
Team 7
Activities of problem solving
Activities of problem solving
Activities of problem solving
Activities of problem solving
1678
ICED19
based methods to generate product profiles. In addition, they also invested more time in revising these
product profiles to increase their maturity. For example, team 5 executed several process steps to
validate and to verify the developed product profiles, through e.g. expert interviews to evaluate the
customer and the provider benefits. At the end of the identifying potentials phase, there was a
milestone (E - deciding and implementing) with the project partner to decide, which product profile
will be processed within the next phase. After the milestone, there was a meeting for recapitulation
and learning (N) with all teams. To summarise the analysed ACTUAL processes, not every team
followed the complete SPALTEN problem solving process for developing product profiles. The
reason for this might be the documentation of the ACTUAL processes by the teams, as they have
executed the complete SPALTEN process but did some steps implicitly, without documenting them
and that they summarized different problem solving steps within one process step. However, it
depends on the specific project objectives and the team itself, how the ACTUAL process is executed
and documented.
In Figure 5, there is a list of the 48 process steps, which are part of the reference process for
developing product profiles. The column Totallists the total of the execution of the respective
process step over the analysed 23 teams. The column % of Teamsshows the relative number of
teams, which executed the process step during their project. For identifying the most important or
most used process steps, the ten process steps with a relatively high number of executions, as well as a
high usage rate over the teams are highlighted in dark grey. Although every product engineering
process is unique, these results show that there might be some process steps, which are relevant for a
larger amount of projects. During the evaluation of the ACTUAL processes of the teams, it was
ascertained, that the process steps concerning the problem solving activity T - analysis of
consequences were described very fuzzy, hence it was not possible to clearly assign them to the listed
process steps. This might be a reason for the lower usability rate of these process steps. For example,
all of the 23 analysed teams executed the process step developing product profiles creativity-based
and overall, this process step was used 58 times. This means, that in average each team executed this
process step at least twice.
Figure 5. List of 48 process steps to develop product profiles with assignment to problem
solving activities (PS), total amount of usage and usability rate overall the 23 teams (TOP
10 process steps are highlighted)
Figure 6 shows the representation of a process step with all necessary information the developer needs
to configure his individual TARGET process. A process step contains some predefined content and
contents that must be filled in by the assigned person during the process. In addition to a general and
short description of the process step, the entry Objectivesclarifies the target by addressing some
short questions. A process step also enables a scalable execution, which offers different possibilities
for execution depending on various factors. These factors include, for example, the type of
collaboration (single work vs. team work), the number of participants, the time required and the
digitalization rate of the method. To make this possible, the entry Scalable Implementationcontains
ID
PS
Process steps All 23 Teams
ID
PS
Process steps All 23 Teams
Total
% of Teams
Total
% of Teams
1 S
Analysing
customer / user groups 43 96%
25
T
Defining
validation objectives 3 13%
2 S
Analysing
future scenarios 18 78%
26
T
Ensuring basic assumptions of business model
522%
3 S
Analysing system in development
38 61%
27
T
Determining payment readiness of customers
626%
4 S
Analysing provider
21 57%
28
T
Testing the usability of the future product
29%
5 S
Analysing
relevant patents 12 48%
29
T
Accomplishing
proof of concept 3 13%
6 S
Analysing reference systems
18 48%
30
P
Deriving requirements to production system
29%
7 P
Deriving customer and user benefits
32 65%
31
A
Identify
recycling or reuse possibilities 4 17%
8 P
Deriving provider benefits
730%
32
A
Describing
product profile claims 16 65%
9 P
Deriving user requirements
730%
33
A
Describing
different benefits 12 52%
10
P
Identifying use cases
16 52%
34
A
Adjusting maturity of different product profiles
12 43%
11
A
Developing
product profiles creativity-based 58 100%
35
A
Visualizing
product profiles 6 26%
12
A
Developing
product profiles research-based 18 57%
36
A
Filling in the product profile scheme
42 57%
13
L
Defining
evaluation method & criteria 16 61%
37
A
Setting up a rough business model
11 43%
14
L
Evaluating
product profiles 27 91%
38
A
Detailing
the business model 2 9%
15
L
Ranking
the product profiles 9 35%
39
A
Calculating
the business case 1 4%
16
L
Comparing different product profiles
17 52%
40
A
Identifying
technical solutions 3 9%
17
L
Combining similar product profiles
11 43%
41
A
Defining functions of product profile
826%
18
L
Selecting TOP [xy] product profiles
21 83%
42
A
Determining
necessary system architecture 4 17%
19
L
Selecting TOP 3 product profiles for final decision
17 70%
43
A
Creating a sketch of the future product
29%
20
L
Selecting
favourite product profile for final decision 6 26%
44
A
Creating CAD model of the product
14%
21
T
Ensuring
technical feasibility 8 30%
45
A
Creating low
-fi demonstrator of the product 2 9%
22
T
Ensuring
customer / user benefits 9 35%
46
A
Creating
functional prototype 1 4%
23
T
Ensuring
provider benefits 6 22%
47
E
Making final decision on the TOP 1 product profile
23 100%
24
T
Defining
relevant product properties for validation 5 22%
48
N
Evaluating the decision on the finial product profile
23 100%
1679
ICED19
various methods and their different execution options. As an example, in the process step Developing
product profiles creativity-basedthe methods Brainstormingand Co-Creation Workshopare
provided. Depending on the factors mentioned, the chosen method can be carried out as a person
alone, in a group paper-based or in a group with the help of supporting collaboration platforms. If a
process step is now selected for implementation in the individual TARGET process, the process step
can be assigned to a predefined phase goal and one or more responsible persons. Additional entries
allow the assignment of the process step to the product engineering and problem solving activities as well
as to the layers of iPeM. This representation of a process step can be easily implemented in current IT tools
for project management, which are mainly used in industry, as e.g. Jira. Therefore, it is easier to implement
this reference process within companies and to support product developers without a large additional effort.
Figure 6. Example for the representation of a process step
5 PROCESS PATTERNS FOR REFERENCE PROCESSES FOR DEVELOPING
PRODUCT PROFILES
Reference processes include beside the process steps itself also the relation of the process steps to each
other, which are called process patterns. Hence, the empirical Live-Lab study in IP 18/19 was used to
identify these process patterns. Through the evaluation of the ACTUAL processes of the seven teams,
it could be measured, in how many cases a specific process step was executed before a respective
other process step. Figure 7 shows an extract of these results.
Figure 7. Extract of the matrix to identify process patterns for reference processes through
analysing ACTUAL processes within the Live-Lab study in IP 18/19
Description: Developing product profiles creativity-based
Description:
Use creativity to gather new impulses for product
profiles based on knowledge, experience and fantasy
and generate a lot of different product profiles.
Objectives:
-A lot of creative and different product profiles
- Thinking out of the box
- Focus on innovation task and boundary conditions
Scalable execution through different methods
simpel medium complex/complicated
Assignee:
M. Mustermann PE Activity:
Detect product profiles PS Activity:
Alternative solutions iPeM Layer:
Product Gn
Method 1:
Brainstorming Method 2:
InnoBandit Method 3:
Co-Creation Workshop
Objective of Phase:
Product Profiles
ID Process steps
11 147 48 14 7 3 18 36 2
Developing product
profiles creativity-based
Analysing
customer /
user
groups
Making final decision on
the TOP 1 product profile
Evaluating the decision on
the finial product profile
Evaluating product
profiles
Deriving customer and
user benefits
Analysing system in
development
Selecting TOP [xy]
product profiles
Filling in the product
profile scheme
Analysing future
scenarios
11
Developing
product profiles creativity-based
67%
100%
100%
100%
100%
57%
100%
100%
71%
1
Analysing
customer / user groups
33%
100%
100%
67%
75%
17%
67%
100%
33%
47
Making final decision on the TOP 1 product profile
100%
48
Evaluating the decision on the finial product profile
14
Evaluating
product profiles 0% 0%
100%
100%
25%
0%
14%
50%
0%
7
Deriving customer and user benefits
0% 0%
100%
100%
25%
0%
25%
33%
0%
3
Analysing
system in development
29%
33%
100%
100%
43%
50%
57%
67%
29%
18
Selecting TOP [
xy] product profiles 0% 0%
100%
100%
43%
50%
14%
83%
14%
36
Filling in the product profile scheme
0% 0%
100%
100%
0% 0% 0% 0% 0%
2
Analysing
future scenarios
29%
17%
100%
100%
43%
50%
14%
43%
67%
1680
ICED19
As shown in Figure 7, it was measured, that for example in 67% of the cases when the process step 11 -
Developing product profiles creativity-based(row) was used, it was executed before the process step 1
- Analysing customer / user groups(column). Through this visualisation, it can be shown, that the
process steps 11 - Developing product profiles creativity-based, 1 - Analysing customer / user
groups, 3 - Analysing system in developmentor 2 - Analysing future scenariostend to be executed
earlier in the process. In contrast, the process steps 47 - Making final decision on the TOP 1 product
profileand 48 - Evaluating the decision on the final product profile are process steps, which are
clearly positioned at the end of this process phase. This can be explained through the boundary
conditions of the project, which provides a fixed milestone and a meeting for recapitulation and learning.
These identified process patterns can help project managers to plan their project based on the reference
process. Through the empirical data, it will be possible to derive a process plan automatically based on
the reference process and the boundary conditions of the project.
In Figure 8 are the evaluation results of a short survey with 38 participants of the Live-Lab IP 18/19
visualized. Overall, the participants were mostly satisfied with the reference process steps. The
participants rated the description of the process steps as well as the suitability for the project as
positive. The participants were less satisfied concerning the usage of the process steps for their project
planning, what might be dependant of the given project management tool, which was a boundary
condition. Additionally, the participants were also less satisfied with the method recommendations,
which can be reasoned through a missing linkage of the process steps to the method database and more
information concerning the specific method selection and adaptation. Overall, the reference process
and the respective process steps show mostly positive results and much potential to support project
managers during the development of product profiles.
Figure 8. Evaluation of the reference process steps in the Live-Lab IP 18/19 (N=38)
6 DISCUSSION AND OUTLOOK
The empirical base for this research are tasks, which were created by the teams themselves and were
documented in an IT tool. All the process steps were categorized based on the available information.
Thus, it is possible, that a few of the 631 process steps were not classified correctly. In addition to that, it
was not possible to use all of these process steps for the reference process, because some of them were
either described too generic or they were too context-specific or they are not stated clear enough. As this
research is based on several empirical Live-Lab studies in a similar context, it will be necessary to
investigate more ACTUAL processes in different contexts as well as directly in industry. However, the
described results are a first base to support product developers in a very early stage of their project to
develop product profiles. Besides a broad analysis of industrial processes within the early phase, it will
be also a next step to identify the relevant context factors, which affect the reference process itself and
the specific TARGET process. Furthermore, it will be relevant to consider the design of an appropriate
user interface for project managers to build a TARGET process based on the identified process steps and
process patterns, to plan and to execute their process. In addition to that, the iPeM - integrated Product
engineering Model (shown in Figure 1) could be extended through the process steps. The identified
process steps can be located within the fields of the activity matrix on the left side, as part of the process
elements, i.e. process steps, methods and tools. Furthermore, the process patterns give an implication for
the relations between the single process steps. Additionally it will be relevant to investigate the relations
between all process elements, as well as the influence of the context-factors.
1681
ICED19
REFERENCES
Albers, A. (2010), “Five Hypotheses about Engineering Processes and their Consequences”, Proceedings of the
TMCE 2010.
Albers, A., Bursac, N., Heimicke, J., Walter, B. and Reiß, N. (2017), “20 years of co-creation using case based
learning. An integrated approach for teaching innovation and research in Product Generation Engineering”,
in Auer, M.E., Guralnick, D. and Uhomoibhi, J. (Eds.), Proceedings of the 20th ICL Conference, Springer,
pp. 636647. https://doi.org/10.1007/978-3-319-73204-6_69
Albers, A., Bursac, N. and Rapp, S. (2016a), “PGE - Product Generation Engineering - Case Study of Dual Mass
Flywheel”, in Marjanović, D., Štorga, M., Pavković, N., Bojčetić, N. and Škec, S. (Eds.), Proceedings of
the DESIGN 2016 14th International Design Conference, pp. 791800.
Albers, A., Heimicke, J., Walter, B., Basedow, G.N., Reiß, N., Heitger, N., Ott, S. and Bursac, N. (2018),
Product Profiles. Modelling customer benefits as a foundation to bring inventions to innovations”,
Procedia CIRP, Vol. 70 No. 1, pp. 253258. https://doi.org/10.1016/j.procir.2018.02.044
Albers, A., Reiss, N., Bursac, N. and Richter, T. (2016b), “iPeM Integrated Product Engineering Model in
Context of Product Generation Engineering”, Procedia CIRP, Vol. 50, pp. 100105.
https://doi.org/10.1016/j.procir.2016.04.168
Blessing, L.T.M. and Chakrabarti, A. (2009), DRM, a design research methodology, Springer, Dordrecht,
London. https://doi.org/10.1007/978-1-84882-587-1_2
Boehm, B. and Turner, R. (2003), “Using risk to balance agile and plan- driven methods”, Computer, Vol. 36
No. 6, pp. 5766. https://doi.org/10.1109/mc.2003.1204376
Chong, Y.T. and Chen, C.-H. (2010), “Customer needs as moving targets of product development: a review”,
The International Journal of Advanced Manufacturing Technology, Vol. 48 No. 1-4, pp. 395406.
https://doi.org/10.1007/s00170-009-2282-6
Cooper, R.G. and Kleinschmidt, E.J. (1987), “Success factors in product innovation”, Industrial Marketing
Management, Vol. 16 No. 3, pp. 215223.
Dörner, D. (1979), Problemlösen als Informationsverarbeitung, Kohlhammer-Standards Psychologie
Studientext, 2. Aufl., Kohlhammer, Stuttgart.
Gassmann, O. and Bader, M.A. (2017), Patentmanagement: Innovationen erfolgreich nutzen und schützen, 4th
ed., Springer Berlin Heidelberg, Berlin, Heidelberg.
Ge, X. and Leifer, L. (2017), “Design Thinking at the Core: Learn New Ways of Thinking and Doing by
Reframing”, in Proceedings of the ASME International Design Engineering Technical Conferences and
Computers and Information in Engineering Conference -- 2017, Cleveland, Ohio, USA, Sunday 6 August
2017, American Society of Mechanical Engineers, New York. https://doi.org/10.1115/detc2017-67172
Heimicke, J., Reiss, N., Albers, A., Walter, B., Breitschuh, J., Knoche, S. and Bursac, N. (2018), Agile
Innovative Impulses in the Product Generation Engineering. Creativity by Intentional Forgetting”,
Proceedings of 5th International Conference on Design Creativity (ICDC 2018), No. 8, 183190.
Lawson, B. and Samson, D. (2001), “Developing Innovation Capability In Organisations: A Dynamic
Capabilities Approach”, International Journal of Innovation Management, Vol. 05 No. 03, pp. 377400.
https://doi.org/10.1142/s1363919601000427
Münch, J., Fagerholm, F., Johnson, P., Pirttilahti, J., Torkkel, J. and Jäarvinen, J. (2013), “Creating Minimum
Viable Products in Industry-Academia Collaborations”, in Mylopoulos, J., Rosemann, M., Valerdi, R. and
Morgan, L. (Eds.), Lean Enterprise Software and Systems: 4th International Conference, LESS 2013,
Galway, Ireland, December 1-4, 2013, Proceedings, Lecture Notes in Business Information Processing,
Vol. 167, Springer Berlin Heidelberg, pp. 137151. https://doi.org/10.1007/978-3-642-44930-7_9
Ropohl, G. (1975), Einführung in die Systemtechnik.: SystemtechnikGrundlagen und Anwendungen, Carl
Hanser Verlag, München.
Schäfer, M. and Keppler, D. (2013), “Modelle der technikorientierten Akzeptanzforschung Überblick und Reflexion
am Beispiel eines Forschungsprojekts zur Implementierung innovativer technischer Energieeffizienz-
Maßnahmen”.
Schmidt, T.S. and Paetzold, K. (2016), “Agilität als Alternative zu traditionellen Standards in der Entwicklung
physischer Produkte: Chancen und Herausforderungen”, DFX 2016: Proceedings of the 27th Symposium
Design for X, pp. 255267.
Schwaber, K. and Sutherland, J. (2017), The Scrum Guide.
Smith, R.P. and Morrow, J.A. (1999), “Product development process modeling”, Design Studies, Vol. 20 No. 3,
pp. 237261.
Thomke, S. and Reinertsen, D. (1998), “Agile Product Development: Managing Development Flexibility in
Uncertain Environments”, California Management Review. https://doi.org/10.2307/41165973
Wynn, D.C. and Clarkson, P.J. (2018), “Process models in design and development”, Research in Engineering
Design, Vol. 29 No. 2, pp. 161202.
Wynn, D.C. and Eckert, C.M. (2017), “Perspectives on iteration in design and development”, Research in
Engineering Design, Vol. 28 No. 2, pp. 153184. https://doi.org/10.1007/s00163-016-0226-3
1682
... In contrast to these generic meta-models, there are company-specific reference processes that describe the usual sequences of process elements, e.g. milestones, activities, methods for developing a new product (Wilmsen et al., 2019b). These reference processes often serve as master processes to derive project-specific TARGET processes that consider the specific requirements and boundary conditions of respective development projects. ...
... These reference processes often serve as master processes to derive project-specific TARGET processes that consider the specific requirements and boundary conditions of respective development projects. The TARGET process serves as a project plan, including all relevant contents and resources for developing a new product (Wilmsen et al., 2019b). The ACTUAL process is the actual course of the development project and can deviate from the TARGET process, due to unforeseen circumstances during the design project (Wilmsen et al., 2019b). ...
... The TARGET process serves as a project plan, including all relevant contents and resources for developing a new product (Wilmsen et al., 2019b). The ACTUAL process is the actual course of the development project and can deviate from the TARGET process, due to unforeseen circumstances during the design project (Wilmsen et al., 2019b). Many companies use reference processes to describe their development processes standardized. ...
Article
Full-text available
A reference process should consider to the needs and behaviours of the process users, as well as all relevant restrictions and boundary conditions within the company and its environment. Therefore, this contribution provides a method to synthesize relevant requirements on reference processes and supports the consideration of these requirements during the design of a new, company-specific reference process based on meta-models. The developed method was used to design a reference process for automotive predevelopment projects and its applicability and usefulness was evaluated successfully.
... Elements which are marked bold are relevant for the planning of the development process. Tool [47] Solution space [16] Engineering generation [14] The elements do not refer exclusively to the overall project, but equally to different subsystems and engineering generations. By designing the development process, activities are modelled in a chronological sequence in the project plan. ...
... The vision reflects the final product. Usually, the actual course of the project deviates from the project plan due to unforeseen events [47]. The resulting delta between the project plan and the actual course of the project can be used retrospectively to evaluate planning stability. ...
Article
Full-text available
Every product development process is unique and individual. Nevertheless, patterns of recurring and similar elements exist in different processes which experience specific characteristics depending on the type of project. In addition to the different objectives that form the basis of a product development process, projects differ primarily in their share of new development and their degree of complexity. In order to deal appropriately with the resulting uncertainty, implementing agile approaches in processes of mechatronic system development is becoming more popular with the aim of making the development project more flexible. However, it must be borne in mind that not every development process requires an agile approach. Although plan-driven approaches have a poor ability to react to changes, they provide clear structure that leads to a common understanding of the process and a clear definition of objectives. Since a development project does not only contain problems that are well-suited for an agile or a sequential approach it is important to adapt the process to the underlying situation and requirements. In sufficiently plannable situations a purely agile approach would entail the loss of structure. On the other hand, a purely sequential approach for highly uncertain problems means that the process has to be adapted frequently in order to react appropriately to changes and newly acquired knowledge. The approach of ASD – Agile Systems design helps developers to implement suitable development procedures at different process levels depending on the degree of planning stability. In this context, this contribution presents a methodology that examines the influence of new development and complexity on different elements and supports developers in process planning by combining flexible and structuring elements to avoid multiple replanning.
... In the approach of ASD -Agile Systems Design according to ALBERS [14], the development of products, the associated validation system and production system is considered integrated. The approach is based on 9 basic principles for the agile development of mechatronic systems [15] under continuous integration of existing product and process knowledge [16,17]. The core of the approach is the provision of selected agile elements and the integration of these elements into the existing structures of manufacturing companies. ...
Article
Full-text available
Manufacturing companies are increasingly integrating agile approaches into their development processes. This is expected to improve customer integration, enhance responsiveness to changes in the development context and ultimately lead to improved process and product quality. However, since agile approaches mostly originate from the culture of software development and have been formulated on the basis of observations of successful software projects, new challenges arise in the application of these approaches in physical systems development. Often the approaches fail due to false expectations or lack of acceptance, which causes agility not to be deeply integrated into the processes. For this reason, this contribution presents an understanding of the current state of acceptance of agile working and the expected and perceived added value of using agile approaches in practice. Based on this understanding, future research will develop a systematic by means of which agile elements can be introduced into development processes in a way that is appropriate to the situation and needs, thereby increasing acceptance and perceived added value. Since it is empirical research, which analyses real-world processes, a survey was chosen as a suitable research method. 235 participants from different branches in the area of physical product development in Germany participated. The results were analyzed using usual statistical methods. An assumption that there are discrepancies between strategic and operational views on agile working could not be confirmed. However, optimization criteria in the area of acceptance of agile approaches were identified. The research contributed to the understanding of the current performance level in the field of agile development of physical systems. The identified potentials in the area of acceptance and perceived added value in agile work can now be measured specifically for each individual application and realized with suitable methods, what contributes to a sustainable integration of agile methods into the development processes.
... This way, the actual project progress can be plotted against the planned project progress and, if necessary, required actions for adapting the project plan can be derived. [11] Findings from the actual-target deviation can result in the adaptation of the reference process. In order to ensure the modelling of product development in the overall organizational context, the iPeM not only models the development of the product but also the associated production and validation system, strategy and other product generations. ...
Article
Full-text available
With the Solar Roof, Tesla offers a roof in which photovoltaic cells are integrated into the tiles. Tesla can generate revenue streams through the development, production and sale of the Solar Roof. The customer of the Solar Roof can protect his building from the weather and at the same time generate revenue through the operation of the solar cells. The example shows that in addition to Tesla’s business model, the customer of the Solar Roof also has a business model. Tesla’s business model can be assigned to the strategic level and represents a focus of current research. The Solar Roof customer’s business model can be assigned to the product level. Business models at the product level have not yet been comprehensively researched. Therefore, this article proposes perspectives into which business models in product development can be divided and how these can be explained and described. For business models in product development, the three perspectives business models for products, business models as part of products and business models as products were proposed. Furthermore, a model was proposed to explain the difference between business models for products and business models as part of products. Moreover, a model for a product with a business model as part of the product was proposed. Additionally, six case studies were used to show how business models as part of products can lead to additional benefits for providers, customers and users. The proposed models can support product developers in systematically developing market differentiating products through a business models as part of the product.
... This way, the actual project progress can be plotted against the planned project progress and, if necessary, required actions for adapting the project plan can be derived. [11] Findings from the actual-target deviation can result in the adaptation of the reference process. In order to ensure the modelling of product development in the overall organizational context, the iPeM not only models the development of the product but also the associated production and validation system, strategy and other product generations. ...
Chapter
Regulations in multiple countries aim at reducing the greenhouse gas emissions of the transport sector. Increased vehicle electrification is an important aspect regarding the reduction of emissions. Besides battery-electric vehicles, fuel cell electric vehicles (FCEV) also offer locally emission-free mobility. FCEV only recently entered the market and experience in development is limited. To overcome new technological challenges induced by the complex interrelations in FCEV drive systems, a methodology for the automated design of fuel cell drive systems is developed. By coupling a multi-objective optimization heuristic with a scalable techno-economic FCEV model, a high-performance validation environment is generated. This new method, implemented in the early stage of product generation engineering, enables developer to identify ideal configurations of FCEV drive systems, satisfying customer demands despite the limited experience available in development and validation.
Conference Paper
Full-text available
The predevelopment of complex products, e.g. in the automotive industry, underlies a high degree of procedural uncertainties. Hence, there are many different process models available in literature and practice to decrease these uncertainties. However, these process models do not support product developers during their predevelopment projects because they are either too generic or too specific. Hence, this contribution investigates different process models from literature and practice, as well as executed predevelopment projects and an expert workshop on a desired predevelopment process for the early stage. As result, 208 process steps that can be used within automotive predevelopment were identified. A further study with 90 practitioners from automotive predevelopment was executed, to examine the influence of project characteristics onto the relevance of specific predevelopment activities. Overall, the results of this contribution can support project managers to create a project-specific process for their predevelopment project.
Article
Full-text available
According to recent studies, early and clearly defined customer’s demands and provider’s demands are necessary elements for the future success of a product. Product profiles within the scope of ASD – Agile Systems Design describe these demands. As product characterizations in the early development phases, product profiles do not anticipate the technical realization of the product, but rather model customer’s benefits and provider’s benefits as use cases, requirements and boundary conditions and thus include value-added product attributes. By this, product profiles represent the interdisciplinary design objective and form the core of the related generation of business models. However, there is a lack of a suitable methodology to systematize the generation of product profiles. There are no approaches that allow the consideration of corresponding reference products in the context of PGE – Product Generation Engineering when generating product profiles. Starting with a retrospective study, more than 100 product profiles and their development in three Live-Labs with industrial participation as well as three industrial innovation projects are analyzed. Based on this a definition of product profiles is derived and a product profile scheme to model profiles is introduced. Furthermore, the different modules as elements of product profiles are explained.
Conference Paper
Full-text available
Innovations-according to their definition-have always guaranteed market success for companies. As a result of a large number of dynamic boundary conditions in the markets, innovation processes are changing as well. Thus, agile development processes are increasingly finding their way into hardware development in order to counteract the high dynamic of the development environment. However, creativity remains an important key to innovation. Nevertheless , there is currently a lack of efficient creativity methods that stimulate innovative impulses purposefully based on the PGE-Product Generation Engineering. This article introduces a creativity method that expands the stimulus imaging method and stimulates innovative impulses in a purposeful manner and optimizes their maturity for downstream processes. The method has been validated in a scientific study in various Live-Labs derived from the ASD-Agile Systems Design.
Chapter
Full-text available
The teaching program IP - Integrated Product Development has been implemented annually with great success for 20 years, which means that this format has gained a high level of acceptance among companies from a wide range of industries. The participating students acquire professional skills in the area of PGE - Product Generation Engineering through the experience of the real development project and by applying activities and methods of product development, combined with a lecture that deals with the most recent cases from the business world. With the aim of bringing the co-creation formats to further student target groups with diverse needs, the format IP was analyzed and a general valid co-creation approach for case-based learning, was characterized by relevant success factors. Based on this, it was possible to transfer the success factors from IP contextual into the breadth (reaching a high number of students) and into the depth (gain of research competences) by means of two further formats.
Conference Paper
Full-text available
The teaching program IP-Integrated Product Development has been implemented annually with great success for 20 years, which means that this format has gained a high level of acceptance among companies from a wide range of industries. The participating students acquire professional skills in the area of PGE-Product Generation Engineering through the experience of the real development project and by applying activities and methods of product development , combined with a lecture that deals with the most recent cases from the business world. With the aim of bringing the co-creation formats to further student target groups with diverse needs, the format IP was analyzed and a general valid co-creation approach for case-based learning, was characterized by relevant success factors. Based on this, it was possible to transfer the success factors from IP contextual into the breadth (reaching a high number of students) and into the depth (gain of research competences) by means of two further formats.
Conference Paper
Full-text available
We present a theoretical framework about how designers learn new ways of thinking and doing named the reframing theory. The theory underlines why some designers’ creative behaviors endure and some not in face of a conflicting social belief system. In this paper, we first describe the problems that designers and educators face when the cultures that designers attach to and the social logics that they invoke to make sense of their practices are constantly changing. Second, we decode the phenomenon and unpack the problems by drawing on an extensive body of research on cognitive processes, learning theories, and social influences. Third, we propose a theoretical framework to denote that the key to develop and maintain enduring creative behaviors is through reconstruction of one’s perceptions. This theory-oriented paper ends by discussing future directions for educators and researchers, with the aim to advance the research and academic discussions about how to improve design ability.
Article
Full-text available
Many models of the design and development process have been published over the years, representing it for different purposes and from different points of view. This article contributes an organising framework that clarifies the topology of the literature on these models and thereby relates the main perspectives that have been developed. The main categories of model are introduced. Their contexts, advantages, and limitations are considered through discussion of selected examples. It is demonstrated that the framework integrates coverage of earlier reviews and as such provides a new perspective on the literature. Finally, key characteristics of design and development process models are discussed considering their applications in practice, and opportunities for further research are suggested. Overall, the article should aid researchers in positioning new models and new modelling approaches in relation to state-of-the-art. It may also be of interest to practitioners and educators seeking an overview of developments in this area.
Conference Paper
Full-text available
Product development becomes increasingly uncertain and dynamic. Under these conditions, traditional approaches such as VDI 2221 and VDI 2206 reach their limits as they are too stiff to handle large numbers of changes efficiently. Agile methods, however, are flexible and embrace changes. In software development, they have been proven very beneficial which is why they belong to the standard procedures there. In the development of physical products, crucial challenges (e.g. building prototypes frequently) exist. Considering that, the paper investigates, if agile methods are serious alternatives to traditional approaches for physical product development, too. It turns out that they are not. Nevertheless, maturing technologies such as 3d printing could potentially serve as a game changer soon.
Article
Any product engineering process is unique, as the objectives within a process are depending on the results that are generated. Based on a review of research in engineering processes and reflexions of many "self conducted" engineering projects this hypothesis evolves and leads to the derivation of a meta model that provides the elements to describe any specific engineering process. The meta model describes the engineering process as a system that consists of an operation system that generates objectives and transforms these objectives into a system of objects. At least one of these objects is a marketable product. The standardized description for product engineering allows a continuous learning form different engineering processes through derivation of reference, implementation and application models.
Chapter
This chapter presents the outline of our methodology and introduces the main stages and concepts. At the end of the chapter, a comparison is made with the few other methodologies that have a similar purpose.