# What Product Developers Really Need to Know - Capturing the Major Design Elements

Bjørnar Henriksen, Andreas Landmark, Carl Christian Røstad

► To cite this version:

Bjørnar Henriksen, Andreas Landmark, Carl Christian Røstad. What Product Developers Really Need to Know - Capturing the Major Design Elements. IFIP International Conference on Advances in Production Management Systems (APMS), Sep 2019, Austin, TX, United States. pp.447-454, 10.1007/978-3-030-29996-5_52. hal-02460480

HAL Id: hal-02460480

https://inria.hal.science/hal-02460480

Submitted on 30 Jan 2020

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# What product developers really need to know
- Capturing the Major Design Elements

Bjørnar Henriksen¹ Andreas Landmark¹ and Carl Christian Røstad¹

¹ SINTEF Digital, Technology management, 7465 Trondheim, Norway

**Abstract.** Digitalization is no longer about finding data or inputs to different business processes as advances in technology now enables us to capture and/or retrieve all needed data. The challenges lie in the quality of the data, not only in the narrowest technical sense of the term, but also in relation to the extent of what e.g. product developers really need to know in order to support their processes and how this should be presented. In four industrial R&D projects, financed by the Norwegian Research Council and the EU, these challenges have been addressed. In the first project, a traditional approach was chosen. Here overall objectives and use-cases were defined, and the project quickly jumped to what everyonebody (including industrial users and research scientists) believed what the users needed and what could be provided to users from pre-defined data sources. However, it became clear that this did not necessarily match what the users really needed. This is in line with experiences from more traditional process mapping. Through the four R&D projects, a methodology focusing on what the product developer really needs, named "Major Design Elements" was developed, tested and implemented. The approach is to identify the most important design elements, then find what kind of knowledge is required, including relevant analyzes, data and sources. This together with an understanding of the relevant processes form the basis for a Design Dashboard enhancing the product development process.

**Keywords:** Product Development, Fact-based design, Industry 4.0

# 1 Introduction

## 1.1 Challenges in fact-based product development

The product development process has become an even more important competitive element with the greater pressure to meet customer needs faster, with more precision and increased customization to individual needs. Digitalization has accelerated and is an enabler for companies to keep up. However, it is not obvious how companies can achieve the desired effects from this "window of technology".

The Industry 4.0 paradigm, with its high emphasis on data from the manufacturing process itself, has put more and more focus on process and organization. However, manufacturing companies often are not in the front-seat in developing more fact-based
product development processes. This is not necessarily due to lack of technology, but
more a question of knowing how to identify a company's need for data, analytics and
knowledge – and how to put their existing data to good use, i.e. enabling use.

Through a portfolio of R&D-projects including industrial- and R&D-partners we
have tested, developed and described an approach for more fact-based product devel-
opment. In these projects we have experienced the pitfalls of overly focusing on tech-
nology for data capture and analytics (i.e. capturing “facts”) at the expense of the core
tasks in product development and innovation. In this paper we present an approach
developed through these projects. This methodology aims to analyze the need for facts
in core activities in product development in manufacturing companies.

## 1.2 The R&D projects and scientific approach

This paper is based on the research carried out in four R&D projects in medium sized manufacturing companies. A denominator for the projects is the objective of improving product development based on facts. The projects consist of many of the same partners, hence the R&D-work has been fertilized between the projects. One is funded by H2020, while three are co-funded by the Norwegian Research Council (NRC). The action-oriented approach means that the researchers have actively worked out solutions the companies can use and implement – in line with traditional action research methodology.

**LINCOLN** (H2020): 2016-2019, 4 industrial- and 12 R&D-partners. The main objectives are to: (i) develop three types of radically new vessel concepts through simulation model testing, (ii) demonstrate Lean Product/Service Development to the vessel design, (iii) improve ICT tools to support vessels design and operations.

**RIT** (NRC): 2018-2022, 3 industrial- and 3 R&D-partners. The main objective is to develop a Design Dashboard where large data volumes are analyzed/presented together with other types of data according to product requirements in the leisure boat industry.

**RADDIS** (NRC): 2018-2022, 4 industrial- and 2 R&D-partners. The main objective is the reduction of physical work using enabling technologies within visualization, product digital twins and simulation. The project also aims to find more proactive ways to deal with regulations within the marine industry.

**WRAPID** (NRC): 2018-2022, 2 industrial- and 2 R&D-partners. The main objective is to develop solutions for fact-based modularized product design for heavy machinery for agricultural and industrial applications.

# 2 Perspectives on fact-based design

## 2.1 Knowledge and "facts"

Competence, knowledge and facts are terms frequently used when describing high per-
formance organizations. Gunasekaran and Ngai characterize these organizations by: (i)
core competence, networks and cooperation; (ii) process orientation; (iii) free margins;
(iv) learning organizational structures; and (v) knowledge management and information
technology [1]. Product development is a source of new knowledge, but we also need
to reuse existing knowledge for the generation of new ones. This has to be integrated back into the development cycle to match ever increasingly complexity of design.

Knowledge and facts are often used interchangeably. A scientific *fact* is an objective and verifiable observation, in contrast to a *hypothesis* or *theory*, which is intended to explain or interpret facts [2]. In this paper, we see fact quite similar to what Nonaka and Takeuchi terms explicit knowledge, in contrast to tacit knowledge [3].

Applying the notion and theory of knowledge management to engineering activities; Knowledge-based engineering (KBE) is the application of knowledge-based systems technology to the domain of manufacturing design and production. The design process is inherently a knowledge-intensive activity, so a great deal of the emphasis for KBE is on the use of knowledge-based technology originally to support computer-aided design (CAD). KBE can have a wide scope that covers the full range of activities related to Product Lifecycle Management and Multidisciplinary design optimization. The scope of KBE includes design, analysis, manufacturing, and support [4].

## 2.2 The product development process

The product design process is extremely important for the competitiveness of manufacturing companies. It may also one of the most complex process in a company due to the integration of heterogenous, existing, and new knowledge that must transform requirements and constraints into technical solutions. The choices and decisions taken during the design phases impact other steps and processes in product development, production, logistics etc. [5].

Within Lean product development (LPD), knowledge plays an increasingly important role. Design cycles are examples of activities that may provide value or waste, depending on how to look at it. E.g. design process iterations could create valuable knowledge i.e. for variability. However, the specific iteration that can be eliminated without loss of useful knowledge is waste since only information that contributes to reduce risk provides value [8].

According to Rossi, Morgan, and Shook, Lean product development is about creating value through a process that builds on knowledge and learning enabled by an integrated system of people, processes, and technology [6]. The Lean pioneer Allan C. Ward's core thesis is that the very aim of the product development process is to create profitable operational value streams and that the key to doing so predictably, efficiently, and effectively is to create useable knowledge [7]. Kennedy prefers to use designations as 'Knowledge-Based Product Development' and 'Learning-First Product Development' instead of LPD. He suggests that PD must be viewed as a 'world of knowledge', rather than a 'world of tasks' [10]. According to Kennedy the value stream for knowledge represents the flow of useful knowledge across different projects, products and functional areas – which is a characteristic that most enterprises fail to leverage. This can be seen as "Minimising the waste of knowledge", not originally one of the seven "wastes" in lean manufacturing, but highly relevant in PD.

There is a range of more recent methodologies for product development with close links to LPD. Jill Jusko presents some of these concepts gaining greater attention in the manufacturing product development community [9]:

* Agile Development relies on the ability of small teams and teamwork to make changes quickly and promote intimate customer collaboration.
* Knowledge-based Development is characterized by the creation of reusable knowledge through learning cycles. It incorporates set-based design.

* Spiral Development is associated with software development and characterized by multiple iterations of the entire process, unlike staged processes.

The Industry 4.0 concept represents a new paradigm as it takes account of the increased computerization of manufacturing where physical objects are seamlessly integrated into the information network. The main features of Industry 4.0 are [11]:

* Interoperability: cyber-physical systems allow humans and smart factories to connect and communicate with each other.

* Virtualization: a virtual twin of the Smart Factory is created by linking sensor data with virtual plant models and simulation models.

* Decentralization: the ability of cyber-physical systems to make decisions of their own and to produce locally thanks to technologies such as 3d printing.

* Real-Time Capability to collect and analyze data.

* Increasing Service Orientation.

* Modularity: flexible adaptation of smart factories to changing requirements

Industry 4.0 enables a more effective infrastructure in which the design and development activities of a product's life cycle are closely integrated through real-time information and big data. The challenge is to understand how to use this extensive information in order to enhance product value and to improve industrial productivity. Since information must be displayable, reusable and available in real-time, the fourth industrial revolution is already well-aligned with lean thinking [12].

## 2.3 Knowledge requirements - product and process

Even though software development plays an increasing part, product development in manufacturing is normally conducted differently from pure ICT projects. However, as described in the sections above, knowledge and ICT support are becoming more and more important to the product design process. The challenge is then to define what we need, and how to get the knowledge. Generally, the knowledge requirements could be categorized as product- or process knowledge [13]. However, in product design, we will normally need both kinds of knowledge.

The common approach for structuring product knowledge is through Product Models, where one of the most common is the "Functional-Behavior-Structure" [14]. Depending on the product complexity, the knowledge could be distinguished into [5]: (i) Function, (ii) Structure – technical architecture, BOM, (iii) Behavior, (iv) Properties – set of characteristics i.e. material, geometry, technology, etc, (v) Lifecycle. A range of sources and ICT tools such as eBOM, CAD and ERP are used to capture, transfer, analyze and present product knowledge.

The process knowledge is created during the whole lifecycle of a product and is normally based on activity models creating links between products, resources and their characteristics. An activity aggregates several kinds of knowledge such as sequences, functions, rules, states etc. Various types of process mappings, formalized through software tools such as PLM, MPM [15] are common enablers.
# 3 The R&D projects' focus on product design

## 3.1 The companies

The companies from the marine and agricultural industries participating in the R&D-projects presented are medium-sized operating in international markets, facing expectations for continuous product improvements and product launches. They have limited staff-resources dedicated to product development and need to combine development with operational activities. However, the companies share an eagerness bringing new technology into their products and processes.

## 3.2 The design processes

Process analysis is a very common approach for understanding the business and context where new ICT solutions are meant to be implemented and give an improvement in performance, quality etc. Figure 1 illustrates a typical product development model.

<figure><img src="image_2.png" /><figcaption>Fig 1 Product development as an iterative process</figcaption></figure>

The details presented are not important here, but what we see is that the product development in our case companies (Figure 2) are typically very unstructured, with many iterations and diffuse requirements. It is also difficult to identify what facts are integrated in the process and what is really needed for a good product development process.

<figure><img src="image_3.png" /><figcaption>Fig 2 Product development, not a straightforward process in the case companies</figcaption></figure>
The above process analysis gave an overall picture of the product development context and challenges for the companies but did not provide sufficient insight on how to improve the situation. Hence this traditional process analysis approach didn't identify what kind of analyses, data, and ICT solutions are needed to really improve the process.

### 3.3 Identifying the major design elements

Our need for better ways of defining requirements for facts into the product development made us emphasize the product as such, i.e. product data and the core tasks in the design process.

The challenge is to identify what kind of analyses and subsequently data we really need in our (technical) design. What are the major design elements of the product? This approach tunes down "what data is available" and/or "what would be nice to have". For some industries and product/markets, the major design elements (MDE) are well known even though the weight of importance could vary. The leisure boat manufacturing industry is such an example, where the product designers are working on well-defined design elements (Table 1). In this case, the next step is to define what analytics and data we should bring to the design dashboard to improve product design processes.

For other industries and product/markets the MDEs are to some extent inherent, but not necessarily well defined. This was the case for the agricultural machine industry. In our projects a methodology that could identify the MDEs and what facts needed to improve the work on these elements has been developed. This was done through workshops where the people involved in the companies' product development participated together with external industrial experts (facilitators). The company was well prepared before the workshop, so much of the workshop was about classifying and grouping the design elements and discussing examples.

<table><caption>**Table 1.** Major Design Elements (MDE) in the marine- and agricultural cases</caption><thead><tr><th rowspan="2">Boatbuilders</th><th colspan="2">Type of knowledge</th><th rowspan="2">Agriculture equipment</th><th colspan="2">Type of knowledge</th></tr><tr><th>product</th><th>process</th><th>product</th><th>process</th></tr></thead><tbody><tr><td>Hull definition</td><td>x</td><td></td><td>Material properties</td><td>x</td><td></td></tr><tr><td>Hydrostatics</td><td></td><td>x</td><td>Flow in machines</td><td></td><td>x</td></tr><tr><td>Weights</td><td>x</td><td></td><td>Weight and geometry</td><td>x</td><td>x</td></tr><tr><td>Powering</td><td></td><td>x</td><td>Hydraulics capacity</td><td>x</td><td>x</td></tr><tr><td>Stability</td><td>x</td><td>x</td><td>Material input in machine</td><td></td><td>x</td></tr><tr><td>Structure</td><td>x</td><td>x</td><td>Robustness</td><td>x</td><td>x</td></tr><tr><td>Arrangements</td><td>x</td><td></td><td>HSE (Health Security Env.)</td><td></td><td>x</td></tr></tbody></table>

The above table illustrates the MDEs for our cases in different industries. We see that the design elements the product designers are focusing on in the technical product design have similarities. Hence, some of the data might be captured and analyzed using similar hard- and software solutions. However, it is important to respect the specifics of the industries and companies in defining the MDEs and their need for facts.
When the MDEs are grouped and labeled, they have to be described and detailed to a
level where we can see what kind of analyses and the data providing the desired facts
to the designers. To some extent, this is about defining a product design dashboard that
provides facts and also is a gateway for more advanced analyses and data-drilling.

Some of the facts required in a design dashboard for major design elements are al-
ready stored in the company systems, e.g. ERP-, quality- and/or product-embedded sys-
tems. The challenge is to bring data of a correct quality to the dashboard and cre-
ate/make available relevant analytics for designers. This phase is the more technical
part of the projects where solutions are developed. However, this is also where the cost-
/benefit considerations of such a solution comes into force.

3.4 A hint of what data we might have and what we could learn

The focus on MDEs assumes that the customer requirements and the overall process is fact-based and would benefit from lean product design approaches presented in 2.2. A basis for the MDE methodology is to focus on the important tasks and challenges in product design, and not focus on ICT solutions. However, in the latter stages, we see that the discussions are more concrete and fruitful when we could give practical examples of data and analytics. In the agriculture case, data from product embedded sensors were used to give examples related to patterns of use (6, 7 and 8 in Figure 3), hydraulics/chamber pressure, etc. (3 and 5 in Figure 3). For the marine industrial cases, several analytical approaches and visualizations are now being tested and implemented based on real-life captured data from prototype vessels and fleet of vessels available. E.g. hull pressure, which can give important data on MDEs such as structures and powering.

A common experience across these companies is the iterative nature of explorative data analysis and PD requirements-driven data analysis. To develop the product developer's intuition about the value of the data in the organization, it seems necessary to couple "product development"-minded data scientists with "data-minded" product developers. Aided by a methodology it is possible to focus the discussions to avoid becoming overly technical- or overly PD-driven.

4 Conclusion

Today the challenge for manufacturing is more and more about finding smart ways to
use data and knowledge that is available through different systems and devices. In prod-
uct development, we often see different kinds of spiral approaches, where the real need
for facts is often difficult to define. Through different industrial R&D projects, a meth-
odology has been developed and tested, that aid companies to capture and present data
and analytics for the Major Design Elements in product development. This approach
could reduce the time used in product development and improve quality in product and
services. In this way the focus on Major Design Elements could enable companies to
lean and Knowledge Based Product Development.
References

1. Gunasekaran, A. and Ngai, E.W.T.: Knowledge management in 21st century manufacturing. International Journal of Production Research, 45 (11), 2391–2418. (2007)

2. Gower, B.: Scientific Method: A Historical and Philosophical Introduction. Routledge.
ISBN 0-415-12282-1. (1997)

3. Nonaka, I. and Takeuchi, H.: The knowledge-creating company. New York: Oxford University Press. (1995)

4. Prasad, B.: What Distinguishes KBE from Automation. coe.org. Archived from the original on 24 March 2012. Retrieved 3 July (2014).

5. Bricogne, M., Belkadi, F., Bosch-Mauchand, M., and Eynard, B.: Knowledge Based Produc- t and Process Engineering Enabling Design and Manufacturing Integration. In Proceed- ings IFIP WG 5.7 International Conference, APMS 2009 Bordeaux, France Journal 2(5), pp 473-480 (2010).

6. Rossi, M., Morgan, J. and Shook, J. : Lean Product Development. In Netland, T. and Powell, D.J. eds. The Routledge Companion to Lean Management, Productivity Press (2016)

7. Ward, A.C. and Sobek, D.K.: Lean Product and Process Development, 2nd Edition by Allen C. Ward and Durward K. Sobek II. Lean Enterprise Institute, Inc. (2014)

8. Reinertsen, D.G. ‘Lean thinking isn’t so simple’, *Electron Des.*, Vol. 47, No. 19, p.48. (1999)

9. Jusko, J.: https://www.industryweek.com/companies-amp-executives/new-models-product-development2010. Uploaded February 2019

10. Kennedy, M.N.: Learning First Product Development: Understanding Implementation Prin- ciples, Lean PD Seminar and Workshop at IVF, Gothenburg, Sweden. (2008)

11. http://www.europarl.europa.eu/Reg-Data/etudes/STUD/2016/570007/IPOL_STU(2016)570007_EN.pdf Uploaded Feb.2019

12. Cattaneo L., Rossi M., Negri E., Powell D., Terzi S.: Lean Thinking in the Digital Era. In: Ríos J., Bernard A., Bouras A., Foufou S. (eds) Product Lifecycle Management and the In- dustry of the Future. PLM 2017. IFIP Advances in Information and Communication Tech- nology, vol 517. Springer, Cham (2017)

13. Zha, X., Du, H.: Knowledge-intensive collaborative design modelling and support – Part 1: Review, distributed models and framework. Comp. Ind. 57, 39-55 (2006)

14. Gero, J.S., Kannengiesser, U.: The situated function- behavior-structure framework. Design Studies 25(4), 373-391 (2004)

15. Hugo, J., Vliegen, W., Herman, H.: Van Mal: The Structuring of Process Knowledge: Func- tion, Task, Properties and State. Robotics & Computer-Integrated Manufacturing 6(2), 101– 107 (1989)