Enhancing the design transfer process within ENOVIA V6/TVC800550/FULLTEXT01.pdf · Figure 11. The...
47
KTH Enhancing the design transfer process within ENOVIA V6/TVC Dmitry Ponomarev
Transcript of Enhancing the design transfer process within ENOVIA V6/TVC800550/FULLTEXT01.pdf · Figure 11. The...
KTH
Enhancing the design transfer process within
ENOVIA V6/TVC
Dmitry Ponomarev
2
Sammanfattning
Aktuell forskning undersöker befintliga vägar och metoder för att översätta produktrelaterad
designinformation till de uppgifter som krävs för snabb och outtröttlig inrättandet av
tillverkningsprocesser inom två specifika software produkter - ENOVIA V6 och Technia Value
Components (TVC). Studien ser också över de potentiellt möjliga förbättringar för dessa verktyg, som
kan påskynda relevanta affärsprocesser och göra dem mer konfigurerbara och flexibla.
Följande mål har fastställts: 1) Göra en analys av nuvarande kapacitet gällande verktygen ENOVIA och
TVC inom området design av överföring; 2) Genomföra en litteraturstudie av senaste forskningsmaterial
med anknytning till design av överföring; 3) Undersöka nuvarande behov hos företag som använder
programvaran ovan; 4) Föreslå lösningar och motsvarande datamodeller som gör det möjligt att öka den
befintliga funktionaliteten hos ENOVIA/TVC; 5) Genomföra föreslagna förbättringar inom ramen för
TVC.
För att uppnå de beskrivna målen har fallstudie valts som den mest lämpliga forskningsstrategin.
Datainsamlingen gjordes i första hand genom en-till-en semistrukturerade intervjuer men också med
hjälp av fokusgrupper. Fokusgrupperna arrangerades med representanter från företag som använder
ENOVIA V6 med TVC som komplement.
Studien resulterade i en rad förbättringar och allmänna råd som är tänkta att utöka den nuvarande
funktionella kapacitet av TVC och underlätta det bättre stödet för affärsprocesser och aktiviteter som är
kopplade till utformning av överföringen. Samtliga föreslagna förbättringar presenterades (och en del
genomfördes) för Technia AB, som är ägaren av produkten TVC.
3
Abstract
Current research explores the existing ways and methods of translating product-related design
information into the data required for fast and unflagging ramping up of manufacturing processes within
two specific Product Lifecycle Management software products – ENOVIA V6 and Technia Value
Components (TVC). The study also looks over the potentially-feasible improvements for these tools,
which can speed up the relevant business processes and make them more configurable and flexible.
The following goals were set: 1) Perform the analysis of current capabilities of ENOVIA and TVC tools
in the area of design transfer; 2) Carry out a literature study on latest research materials related to design
transfer; 3) Examine present needs of companies utilizing the software above; 4) Propose solutions and
corresponding data models allowing to enhance the existing functionality of ENOVIA/TVC; 5)
Implement suggested enhancements within the framework of TVC.
A case study research strategy was selected as most suitable for achieving the described goals. The data
was collected primarily through the one-to-one semi-structured interviews and focus groups arranged
with the representatives of companies that utilize ENOVIA V6 complemented by TVC.
The study resulted in a set of improvements and general recommendations that are supposed to extend
the present functional capabilities of TVC and to facilitate the better backing of business processes and
activities related to the design transfer. All suggested enhancements were proposed (and some
implemented) to Technia AB, as to the owner of TVC product.
4
Preface
Current thesis work is a result from several case studies initiated by Technia AB. The study completes
author’s education in Production Engineering and Management Master’s program at the Royal Institute
of Technology in Stockholm, Sweden.
First of all, author would like to express his gratitude to Technia AB for an opportunity to perform this
study and especially to his supervisor Benny Helgesson, for his continuous guidance during the whole
project and immense help with organizing case studies.
Author also wants to thank his supervisor from KTH Per Johansson, for his support, criticism, comments
and patience.
Finally, author wants to say special thank to:
Annelie Uvhagen – for her support and help with organizing case studies;
Maria Groth, Jan Thunqvist and Ulf Bergwik – for sharing their ideas and experiences;
Stefan Tärnblom – for his help with organizing interviews;
Prabhu Salimath and Danny Löfgren – for their help with web-developing and trainings;
Tariq Saeed – for IT-support;
Lars Lindberg (KTH) – for most valuable advices and ideas;
Cevat Elik and Jonas Fredriksson (3DS) – for additional information about DS products;
Claes-Göran Andersson (Mölnlycke Health Care), Tommy Olofsson (GE Healthcare), Carl-Olov
Naeslund and Maria Åslund (Toyota Material Handling Sweden AB) – for their openness, hospitality,
cooperation and valuable information provided;
Annika Nordström, Lydia Wällenhoff, Charlotte Brooling and Anna Kalm – for their criticism,
proofreading, ideas, thousand other things and being such a great co-workers!
Huge thanks to all of you who made this work possible and so enjoyable!
Stockholm, Sweden, 15 June 2014
Dmitry Ponomarev
5
Glossary
APQP – Advanced Product Quality Planning – a framework of procedures and techniques used
to develop products;
BOM – Bill of Materials – a list of the raw materials, sub-assemblies, intermediate assemblies,
sub-components, parts and the quantities of each needed to manufacture an end product;
EBL – Engineering Baseline – a complete and non-editable snapshot of an eBOM;
EBOM – Engineering Bill of Materials – a type of bill of materials that describes the product
structure from the design point of view;
ECO – Engineering Change Order – a statement of work that describes required design changes
and defines responsible assignees within organization;
ECP – Engineering Change Process – the process of requesting, determining attainability,
planning, implementing, and evaluating of changes to a system;
ECR – Engineering Change Request – a statement defining a call for design changes of a product;
ERP – Enterprise Resource Planning – business management software used by a company in
order to collect, store and manage data from different business activities;
IP – Intellectual Property – the legally recognized exclusive rights to creations of the mind;
IQ – Installation Qualification – a documented proof that facilities and equipment have been
delivered and installed in accordance with the requirements and statutory safety regulations stipulated
in the design qualification;
MBL – Manufacturing Baseline – a complete and partly-editable snapshot of an eBOM;
MBOM – Manufacturing Bill of Materials – a type of bill of materials that describes the product
structure from the manufacturing point of view;
MES – Manufacturing Execution System – a computerized system that usually intermediates
between ERP systems and a manufacturer's plant floor control equipment;
MPM – Manufacturing Process Management – a collection of technologies and methods used to
define how products are to be manufactured;
NPI – New Product Introduction – the complete process of bringing a new product to market;
6
OEM – Original Equipment Manufacturing – an organization that manufactures products or
components that are purchased by another company and retailed under that purchasing company's brand
name;
OQ – Operational Qualification – a documented result from the test process that evaluates the
correct functioning of a facility or an appliance;
PDM – Product Data Management – a business function responsible for the management and
publication of product data;
pFMEA – Process Failure Mode and Effect Analysis – a systematic technique for failure analysis of
technological processes;
PQ – Performance Qualification – a documented proof that the appliances and systems are
working reproducibly within the entire specified working range and limits;
TVC – Technia Value Components – a framework and a collection of software components
developed by Technia AB and aimed to improve the performance, usability, configurability and
extendibility of ENOVIA V6;
UML – Unified Modeling Language – a general-purpose modeling language in the field of
software engineering, which is designed to provide a standard way to visualize the design of a system;
XML – Extended Markup Language – a markup language that defines a set of rules for encoding
documents in a format that is both human-readable and machine-readable;
7
Contents
Sammanfattning....................................................................................................................................... 2
Abstract ................................................................................................................................................... 3
Preface ..................................................................................................................................................... 4
Glossary ................................................................................................................................................... 5
Table of figures and appendixes .............................................................................................................. 8
Structure of the thesis .............................................................................................................................. 9
Introduction ........................................................................................................................................... 10
Background ....................................................................................................................................... 10
Problem description ........................................................................................................................... 12
Purpose .............................................................................................................................................. 14
Objectives .......................................................................................................................................... 14
Delimitations ..................................................................................................................................... 15
Extended introduction ........................................................................................................................... 15
About Technia AB............................................................................................................................. 15
About ENOVIA V6 and its architecture ........................................................................................... 16
Engineering Central and Engineering Change Process ..................................................................... 17
X-BOM Manufacturing and Manufacturing Change Process ........................................................... 19
About TVC ........................................................................................................................................ 21
About TVC XBOM Manager ............................................................................................................ 22
Methodology ......................................................................................................................................... 24
Pre-study ............................................................................................................................................ 24
Strategy for research .......................................................................................................................... 24
Choosing case studies and data collection methods .......................................................................... 25
Interviews .......................................................................................................................................... 26
Analysis ............................................................................................................................................. 27
Literature review ................................................................................................................................... 27
Scope of literature review .................................................................................................................. 27
General issues and challenges related to design transfer ................................................................... 27
Innovative methodologies and strategies for design transfer in PLM ............................................... 30
Proposed enhancements ........................................................................................................................ 34
MPM business objects in ENOVIA .................................................................................................. 34
Configurable Change Orders ............................................................................................................. 35
Phased release and implementation process ...................................................................................... 37
Preliminary mBOM ........................................................................................................................... 39
Checklists .......................................................................................................................................... 40
Collaboration features ....................................................................................................................... 41
Conclusions and discussion ................................................................................................................... 42
List of references ................................................................................................................................... 45
Appendixes ............................................................................................................................................ 47
8
Table of figures and appendixes
Figure 1. The example of product lifecycle and corresponding product structures .............................. 10
Figure 2. Scope of current Master’s thesis in terms of product’s lifecycle ........................................... 11
Figure 3. Design transfer within a scope of PLM domains ................................................................... 11
Figure 4. The first approach for delivery of MPM functionality ........................................................... 12
Figure 5. The second approach for delivery of MPM functionality ...................................................... 13
Figure 6. Design data is “thrown over-the-wall” to manufacturing and back ....................................... 14
Figure 7. The timeline reflecting the history of Technia AB ................................................................ 15
Figure 8. The simplified architecture of ENOVIA V6 .......................................................................... 16
Figure 9. The example of lifecycle used for ECR ................................................................................. 18
Figure 10. The example of lifecycle used for ECO ............................................................................... 18
Figure 11. The example of an engineering change process based on ECR and ECO ........................... 18
Figure 12. The example of an engineering-initiated change process based on ECO and MCO ........... 20
Figure 13. The overview of dependencies between different components within TVC suite ............... 22
Figure 14. The representation of shadow structure for EBL and MBL ................................................. 23
Figure 15. The structure of XML baselines ........................................................................................... 23
Figure 16. Impact of production breaks on unit cost (Pascoe, 2011) .................................................... 28
Figure 17. Two ways of funding the product development process (Pascoe, 2011) ............................. 28
Figure 18. MPM at the heart of the integration axes (Fortin and Huet, 2007) ...................................... 29
Figure 19. A schematic view of Product Lifecycle Collaboration (Ming et al., 2008) ......................... 30
Figure 20. PLM framework focusing on supplier integration for automotive development (Tang and
Qian, 2008) ............................................................................................................................................ 31
Figure 21. Data exchange in PLM-ERP architecture (Ben Khedher et al., 2011) ................................. 32
Figure 22. Data exchange in PLM-ERP-MES architecture. (Ben Khedher et al., 2011) ...................... 32
Figure 23. Information and knowledge models for design realization (Gunendran and Young, 2010) 33
Figure 24. The proposed reference for setting of manufacturing-related business objects in ENOVIA 35
Figure 25. The example of route in ENOVIA V6 ................................................................................. 36
Figure 26. Configuring of ECR/ECO via predefined questionnaires .................................................... 36
Figure 27. The example of questionnaire prepared for user .................................................................. 37
Figure 28. Conventional process: all parts affected by an ECO cannot be released one-by-one .......... 37
Figure 29. Suggested process: introduction of sub-ECOs ..................................................................... 38
Figure 30. Business logic for creating of sub-ECOs by default ............................................................ 38
Figure 31. The concept of optional preliminary mBOM ....................................................................... 39
Figure 32. The major stages of a change process that require checklists .............................................. 40
Figure 33. The approximate view of proposed notification .................................................................. 42
Appendix 1. Possible contribution of Manufacturing Engineers on different stages of change process
............................................................................................................................................................... 47
9
Structure of the thesis
This paper is divided into five chapters:
1) Introduction. This chapter is aimed to provide the reader with a context of the study, define a
research problem and to set up the purpose, objectives and the scope.
2) Extended introduction. This chapter contains some detailed information which needs to be
explained to the reader before further chapters. It gives a brief description of the research project
provider – Technia AB, including the major milestones in company’s history, information about
customers, products and services. The chapter also provides a brief review on ENOVIA/TVC
and expounds the functionality of existing tools for design transfer within Technia’s portfolio
as well as standard business processes behind them. This section can be skipped if the reader
has basic knowledge of engineering change management and is familiar with the corresponding
products from Dassault Systèmes S.A. (3DS) and Technia AB.
3) Methodology. This chapter presents the strategy chosen for the research and methods used for
data collection and data analysis. The purpose of this section is to make it possible for a reader
to evaluate the scientific level of the study.
4) Literature review. This chapter presents the comprehensive review of scientific papers relevant
to the research problem and other materials that have been published in recent decades.
5) Proposed enhancements. This chapter presents the author’s proposals, synthesized from the
analysis of theoretical and empirical studies.
6) Conclusions and discussion. This chapter provides author’s remarks about future work in the
area of design transfer and related recommendations to Technia AB.
10
Introduction
This chapter will give a short background on the field of study and will set a purpose,
objectives and delimitations of the thesis.
Background
Today’s global production environment becomes more and more competitive. To be able to withstand
the evolving competition manufacturing companies across all industries have to speed up the whole
process of creating new products. It implies to not only develop new products faster, but also to launch
the production for them with minimal time-to-market, required quality and lower cost.
In order to achieve these goals it takes to set up compound processes, which would allow all stakeholders
to handle the vast amount of diverse information in a fast, smooth and controllable way. Since
conventional paper-based document workflows stopped satisfying these needs long ago, the focus of
manufacturers switched to industrial IT tools that provide much better support for various operations
used throughout the enterprise. One of the most widely used tools nowadays is Product Lifecycle
Management (PLM).
There is no single definition on term PLM, although most of the experts agree that it does not refer to
any particular method or software, but rather to an approach of handling information. According to
Sääksvuori and Immonen (2005), PLM is a systematic and controlled concept for managing and
developing products and product related information throughout the product lifecycle, from the initial
idea to the scrap yard. The example of product lifecycle is presented on Figure 1:
Requirements structure
Plan Concept Design Validate Manufacture Maintain
Logicalstructure
Engineering structure
Prototype structure
Mfg. structureMaintenance
structure
As-required As-conceived As-designed As-tested As-built As-supported
Dispose
Disposing structure
As-disposed
Figure 1. The example of product lifecycle and corresponding product structures
Each state in a lifecycle reflects the maturity level of the product and can be associated with a
corresponding product structure. The structure undergoes changes over the lifecycle and might be
represented or supported by different types of data. It’s possible to identify several major domains under
the scope of PLM, corresponding to different types of product-related information:
Product Data Management (PDM)
Product (Project) Portfolio Management (PPM)
Manufacturing Process Management (MPM)
Supply Chain Management (SCP)
Customer Requirements Management (CRM)
Quality Management
Document Management
Regulatory Compliance Management (RCM)
The focus of this paper is bound to the interval of a lifecycle that happens between two states: when the
design of the product is completed and when the product is ready to be launched for a full-scale
production (Figure 2):
11
Design Validate Manufacture
Engineering structure
Proof-of-concept structure
Manufacturing structure
As-designed As-tested As-built
Eng. prototype structure
As-verified
Figure 2. Scope of current Master’s thesis in terms of product’s lifecycle
The main purpose of the process path between these two states is to prepare the whole package of
information required for manufacturing. In order to create the package, it takes to accomplish the
following activities:
Translate engineering product structure (engineering bill of materials – eBOM) to validated
manufacturing structure (manufacturing bill of materials – mBOM)
Translate design specifications into process plans and instructions that would guarantee that the
product is manufactured according to design intent
Define, allocate and qualify appropriate manufacturing resources
Establish and maintain necessary quality control procedures and protocols
The process, that would incorporate all the actions above demands close collaboration between different
business roles within the company. Nowadays, in a global production climate it also might require better
external collaboration with suppliers and contract manufacturers. For the purpose of convenience and in
order to have a single term to operate with, in this paper such process will be designated as design
transfer to manufacturing (or simply design transfer).
As seen from the given description of design transfer, the process mostly deals with two types of
product-related data: engineering (engineering parts, drawings and manufacturing (plants, machines,
tools, fixtures). Therefore, the functionality that can potentially support design transfer has to be
concentrated within PDM and MPM domains of PLM. However, part of the process might also be in
the scope of Quality, Compliance or Supply Chain Management (Figure 3).
RCM&QM
SCM
PDM MPMDesign transfer
Figure 3. Design transfer within a scope of PLM domains
Design transfer takes place either in case of new product introduction (NPI) or when existing product
needs to be changed. Most often the second case can be considered as more complex, since it includes
not only all the activities needed for NPI, but also actions required for evaluation of change impact on
12
related parts, products, production schedules, inventories, field returns, work-in-process parts and other
data. For that reason, in this paper design transfer mostly will be examined as part of Engineering Change
Process (ECP) unless otherwise is noted.
Problem description
PLM software gets used more and more extensively across all industrial domains. World’s leading PLM
vendors create products with a rather similar purpose and functionality but sometimes have different
views on how to deliver them to a customer. The core component of any PLM application available on
the market is PDM. However, for instance, when it comes to a solution for Manufacturing Process
Management, it is possible to identify two major approaches.
The first approach is realized in such products as Aras Innovator (Brown, 2012) and PTC Windchill
(2014c) (by Aras Corporation and PTC Inc. correspondingly). The MPM module there is delivered as
an integral part of PLM application and is mainly focused on working with different product structures,
process plans and work instructions. Digital manufacturing and simulation activities (actual creating of
numerical control (NC) programs, inspection programs for coordinate measurement machines (CMM)
and workflow simulations) are supposed to be performed in a stand-alone 3D Computer Aided
Design/Manufacturing app (Figure 4). Both apps are integrated via the common collaboration platform:
Collaboration platform
3D CAD/CAMapp
Digital Manufacturing module
CMM programs
Machining simulation
NC programs
Factory layout
PLM app
MPM module Work Instructions
mBOMs
Tools
Machines
PDM module Drawings
eBOM
Parts
Related specs
Figure 4. The first approach for delivery of MPM functionality
The second approach is implemented in solutions from Dassault Systèmes (2014a) and Siemens PLM
Software (2014d). These vendors preferred to introduce a separate 3D CAD/CAM application
(DELMIA and Tecnomatix correspondingly), which would incorporate in itself almost all MPM
functionality with a focus on digital manufacturing activities. A limited set of MPM features (e.g. tools
for working with mBOMs), however, is also implemented in interrelated PLM apps (ENOVIA and
Teamcenter) as optional modules. Like in the first approach, both products are closely integrated via a
common platform (Figure 5):
13
PLM app
PDM module
eBOM
Related specs
DrawingsParts
Collaboration platform
3D CAD/CAMapp
MPM functionality Work Instructions
mBOMs
Tools
Machines
Digital Manufacturing functionality
CMM programs
Machining simulation
NC programs
Factory layout
Optional modules with a limited MPM
functionality
Figure 5. The second approach for delivery of MPM functionality
Whatever approach is used, the majority of customers (especially small and medium-sized companies)
still utilize PLM as a tool to work only with the engineering product data and corresponding processes:
product structure management, document management, change management, configuration
management. MPM solutions (as well as other modules apart from PDM), then are used limitedly or not
used at all. There might be various reasons for such strategy, but usually they can be boiled down to the
following:
Most of the software on the market is proprietary and considering the relatively high price it
becomes too big financial burden for a company to buy licenses for MPM apps/modules. It
gets especially critical if required functionality is not concentrated in a single module but
instead is spread across multiple sub-products;
Implementation of MPM solutions might require considerably higher time, efforts and
expenses comparing to implementation of PDM tools;
MPM solutions don’t provide the required functionality or are too complex to handle;
Return on investment (ROI) for MPM apps/modules often is unclear for management and
existing tools seem to be supporting business processes in a satisfactory way.
Due to the reasons above, many companies are forced to find ways for substituting missing functionality
with third-party software, which often is not seamlessly integrated with their PLM apps. As a result, the
data is handled in several stand-alone environments and, therefore, cannot flow smooth, fast, and it is
barely possible to avoid mistakes and misinterpretations of information.
In case of design transfer, this regularly leads to a situation, when engineering data cannot be adequately
conveyed to the shop floor level. At the same time, manufacturing-related intellectual property is not
completely available for designers, which makes it difficult to improve product’s manufacturability. In
extreme cases, collaboration between engineering and manufacturing sites can be described as
“throwing the data over-the-wall” (Figure 6):
14
Product design
Processdesign
Manufacturing
PLM Other software
Produce this! We don’t care how. Change the design first.
Figure 6. Design data is “thrown over-the-wall” to manufacturing and back
The existence of this barrier within design transfer workflow increases the probability of disconnection
between product requirements, design specifications and manufactured outcome. It’s crucial to
prevent such disconnections for any company, especially for those producing highly-sophisticated
products that require unflagging quality (e.g. medical devices or pharmaceuticals).
The specified issue is also relevant for some customers of Technia AB. Clients of Technia use ENOVIA
V6 – PLM software from Dassault Systèmes, but the corresponding MPM software from the same
vendor (DELMIA) is not always used, due to aforementioned reasons. Nowadays, ENOVIA portfolio
itself and complementing tools developed by Technia (TVC) accommodate certain components
intended to facilitate the process of design transfer, but often they also remain unutilized because of
the same reasons. Current Master’s thesis was initiated with an aim to look for possible improvements
of these components, which can lead to their wider implementation in future and to identify potential
customer needs for other tools and functionality missing.
Purpose
Based on the defined problem, the purpose of this Master’s thesis was formulated as follows:
To investigate the possibilities for functional enhancements of existing tools for design transfer
within portfolios of ENOVIA V6 and Technia Value Components;
To identify what new tools and functions might be required by customers of Technia AB.
Objectives
Several objectives have been formulated for this thesis:
To analyze current capabilities of ENOVIA and TVC tools in the area of design transfer;
To perform a literature study on latest research materials related to design transfer;
To analyze needs of existing customers of Technia in the field of design transfer by performing
several case studies (from one to three case studies);
To suggest a data model and a process for best practice of design transfer based on the
information collected;
Implement a proof of concept in ENOVIA and TVC.
15
Delimitations
Current thesis work was performed with a focus on the functionality of ENOVIA V6 (ver. 2013x) and
TVC (ver. 2014.1.2). All information, describing the features and processes of these software products,
refers to the versions above, unless otherwise is noted.
The agreement between author and Technia AB implied that all feasible proposals resulted from this
study, should be implemented by author in ENOVIA V6 or TVC as proofs-of-concept. Since describing
of actual implementation strategy and methods would require expounding of vast amounts of technical
details, in current report these information is completely omitted.
Extended introduction
This chapter provides the reader with a brief description of the research provider –
Technia AB and the software products it offers – ENOVIA V6 and Technia Value
Components. More detailed information is given on tools and corresponding processes
used for design transfer.
About Technia AB
Technia AB is the leading supplier of PLM solutions for creating and managing product information
throughout the entire product lifecycle in the Nordic area (2014e). The company was founded in 1994
by Staffan Hanstorp, Jonas Gejer and Johan Petrini. The timeline representing major milestones in the
history of Technia is showed on Figure 7:
1994
2014
1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013
Figure 7. The timeline reflecting the history of Technia AB
From its start, business of Technia AB is mostly focused on offering software and services that
contribute to effective management of product information through the product lifecycle. Since 1995
Technia AB offers were based on PLM solutions from MatrixOne Inc. In 2006, this software vendor
was acquired by Dassault Systèmes (2006) and its main product – MatrixOne was used to create a new
generation of ENOVIA brand.
16
Technia AB also offers software and services for computer aided design, product configuration,
visualization, integration and portals. The company established partnership agreements with the world-
leading software suppliers in each of these fields. Tecnhia’s customer list includes more than 200
companies from various industrial domains: electronics, life sciences, industrial equipment, apparel,
construction and other (2014e).
Since 2004, Technia has been a part of the Addnode Group (listed at the Nasdaq OMX Nordic List)
(2014e). Currently, Technia has offices in all Nordic countries, Denmark, USA and India with more
than 170 employees in total.
About ENOVIA V6 and its architecture
ENOVIA is a brand name for a set of PLM products developed by Dassault Systèmes, which enable
companies to bring together people, processes, content and systems in order to achieve a compelling
competitive advantage (2014b).
The simplified application architecture of ENOVIA V6 is shown on the Figure 8. The core component
called ENOVIA Live Collaboration Business Process Services (BPS) is intended to provide users with
general capabilities for collaborative and controlled access to data. BPS consists of four following
subcomponents (2014h):
Application Exchange Framework (AEF) – provides the configurable user interface, schema
and features used throughout ENOVIA products, such as search pages, lifecycles, collections
and background jobs;
Common Components – provides such features as Document Management, routes, Issue
Management and company profiles;
Team Central – provides the functionality for subscriptions and such features as workspaces
and folders;
Metrics Module – provides reporting capabilities.
ENOVIA Live Collaboration Business Process Services File
Man
ager
ENOVIA Live Collaboration Server
Application Exchange FrameworkCommon Components
Team CenterMetrics Module
Des
ign
Ce
ntr
al
ENOVIA Collaborative Business Process Apps
Program CentralLibrary Central
Engineering CentralVariant Configuration Central
Requirements CentralX-BOM Manufacturing
…
Figure 8. The simplified architecture of ENOVIA V6
17
On top of the common platform provided by BPS, there is a set of Business Process Applications (BPA).
Each of the applications contains tools aimed to support particular business processes. Some of the
applications are intended to be widely used across all industries and types of companies (usually called
Centrals), while others developed in order to support needs of a particular industry (usually called
Accelerators). Third type of applications (called Experiences) supposes to bring up the extended
functionality for Centrals. Several examples of different types of applications are listed below (2014h):
Program Central – intended to provide a set of capabilities for Project Management (creating,
storage and managing programs, projects and related data);
Variant Configuration Central – aimed to manage the conceptual and commercial aspects of a
product by defining a collection of its configurations based on specific customer needs;
Requirements Central – intended to provide capabilities for Change Proposal Management
(creating and maintaining requirements; describing proposed changes to hardware and software
products);
Suppliers Central – aimed to facilitate the information sharing and quality control between
suppliers and buyers;
Quotation Central – intended to develop and source complex requests for quotes for direct
materials and engineering goods.
The following subchapters will provide more details on two business process applications: Engineering
Central and X-BOM Manufacturing since it is essential for understanding the current capabilities of
ENOVIA V6 in the area of Design Transfer.
Engineering Central and Engineering Change Process
Engineering Central – is the BPA within ENOVIA V6 suite, intended to provide users with capabilities
to manage the engineering change process during the entire product’s lifecycle and to collaborate
through it.
The main capabilities of Engineering Central can be divided into four domains:
Engineering Bill of Material Management:
o Ensuring the existence of a single and stable definition of engineering bill of material
(eBOM) for all development teams in a global environment;
o Providing the ability to compare eBOMs and to edit them: to add, remove, replace,
clone and re-sequence parts in the assembly;
o Generating configurable data packages with the eBOM related data available for
downloading;
Part Management:
o Providing a single enterprise-wide definition of product information and set of tools to
manage it;
o Allowing to define part families and individual types of parts (spare, alternate,
substitute, master, reference, etc.);
Engineering Change Management
o Supporting a seamless process for initial release of parts and associated specifications
for manufacturing;
18
o Supporting the process of subsequent changes to approved parts and specifications at
any point of the lifecycle;
Reporting:
o Generating multi-level eBOM reports, BOM comparison reports, ECR/ECO and other
types of reports.
The primary process designed to control the maturation of products or product changes within PLM lies
within the scope of Engineering Change Management (ECM). In general, Engineering Change
Management can be defined as a process of requesting, evaluating, planning and implementing changes
to the system (Crnkovic et al., 2003). The purpose of ECM is not only to support the processing of
changes but also to provide a full traceability on them. Before describing the way ECM is executed in
ENOVIA Engineering Central, it requires to introduce two item types: Engineering Change Request and
Engineering Change Order.
Engineering Change Request (ECR) – is an announcement asking for changes to the product
(Sääksvuori and Immonen, 2005). An ECR is used to initiate the change process for existing business
objects. It points out on the subject of the change: assemblies, parts, features and related specifications
to be changed. ECR also might contain information about the character of the change; the reason for it
and (optionally) descriptive instructions. The typical lifecycle used for an ECR is shown on Figure 9:
Create Evaluate Review Plan ECO Complete Canceled
Figure 9. The example of lifecycle used for ECR
Engineering Change Order (ECO) – is a work statement for changes required to be implemented
(Sääksvuori and Immonen, 2005). ECOs are used as the primary tool to control the actual design change
implementation process e.g. for assigning design engineers responsible for implementing changes,
reviewing and approving. The typical lifecycle used for an ECO is shown on Figure 10:
Create In Work Review Release Implemented Canceled
Figure 10. The example of lifecycle used for ECO
The whole engineering change process, used within out-of-the-box (OOTB) Engineering Central, is
shown on Figure 11:
Create Evaluate Review Plan ECO
Created
Complete
In Work Review Released Implemented
EBOM EBOM EBOM EBOM
EBOMs EBOMs EBOMs
ECO Lifecycle
ECR Lifecycle
EBOMs
Figure 11. The example of an engineering change process based on ECR and ECO
When a part within company’s product line needs to be revised, an ECR is created, detailing the change
that needs to be made and the organization responsible for a change. The ECR can be initiated by any
stakeholder within the production process: design, manufacturing or quality engineer. Once the ECR
has been prepared, it is submitted for evaluation by change coordinator of the responsible company.
19
Coordinator checks if the change is necessary and explained in sufficient detail, assigns the responsible
design engineer and promotes the ECR for evaluation. Responsible Design Engineer (RDE) gets
notification and then has to assess the potential impact of the requested change on other parts. At this
stage, RDE can modify the list of affected parts and instructions based on specific knowledge of how
the change is likely to be done. When the ECR package is fully assembled, it can be transferred to change
control board or change control chairman for a final review. Once all signatures from competent
reviewers are submitted, the ECR auto-promotes to the “plan ECO” state and system trigger generates
corresponding Engineering Change Order.
The ECR part of the process is optional and in practice is often omitted by organizations using PLM. In
such cases, the starting point for the whole change process is manual creation of an ECO. However, it
does not have a significant effect on subsequent steps of the process, except that some of the ECO’s
attributes and affected objects are not inherited from the ECR and have to be created manually.
After the ECO has been created, Responsible Design Engineer can designate other design engineers as
assignees to work on affected objects. RDE also can set up the appropriate review and approval routes.
As ECO enters the “in work” state, the list of affected parts cannot be changed anymore. Design
engineers and draftsman get notified what objects on the change order they are assigned to work on and
granted with ownership for those objects. When the design work is done, and all affected parts on the
ECO are promoted to “approved” state, the change order is auto-promotes to “in review”. At this point,
the ECO should be reviewed by RDE, in order to ensure that all design specifications have been
developed or changed correctly, and by Responsible Manufacturing Engineer (RME), in order to ensure
that new or revised product design is feasible for production. If the package is acceptable, and all
approvals are received, the ECO is auto-promoted to “release” state. The ECO “implemented” state is
supposed to close the loop of the change process. This state provides verification and visibility that a
change has been implemented on the shop floor, exactly as it was intended by the design site. After the
ECO is implemented, the corresponding ECR is auto-promoted to “complete” state.
X-BOM Manufacturing and Manufacturing Change Process
ENOVIA X-BOM Manufacturing is the module of ENOVIA V6 suite that provides users with the ability
to create, modify and view factory-specific manufacturing bills of materials (mBOMs) that are based on
eBOMs, produced and released from Engineering Central. Therefore, X-BOM Manufacturing cannot be
used as a standalone ENOVIA module since it requires the information from Engineering Central as an
input.
The main capabilities of ENOVIA X-BOM Manufacturing are (2014h):
Managing the information about existing manufacturing facilities associated with the company;
Assigning manufacturing responsibility for individual parts to available manufacturing plants;
Creating and maintaining plant-specific mBOMs;
Managing available manufacturing substitute parts, defined in Engineering Central;
Documenting and controlling the manufacturing change process for released parts through
Manufacturing Change Orders (MCOs) or Manufacturing Engineering Change Orders
(MECOs);
Providing a seamless integration for mBOM export from ENOVIA to world leading ERP
systems (e.g. SAP or Oracle Manufacturing);
20
Generating “where used” reports, eBOM/mBOM comparison and mBOM/mBOM comparison
reports;
Manufacturing Change can occur in the following cases:
Engineering-initiated change takes place when design changes released by an ECO are
automatically transformed into corresponding mBOM;
Manufacturing-initiated change takes place when manufacturing engineers need to change
mBOM in a way that doesn’t violate design engineering intent;
Since this paper is focused on the problem of design transfer, only engineering-initiated change process
will be described. The whole process (without ECR) is shown on Figure 12:
CreateDefine
ComponentsDesign Work Review Released Implemented Canceled
Created Review Released Implemented
EBOM EBOM EBOM EBOM EBOM
MBOMs MBOMs MBOMs
ERP
MCO Lifecycle
ECO Lifecycle
Figure 12. The example of an engineering-initiated change process based on ECO and MCO
Engineering Change Request works the same way as described in the previous chapter. It needs to
mention, however, that X-BOM Manufacturing brings up a new type of it, called Deviation Change
Request (DCR). Comparing to Engineering Change Request, the DCR is plant-specific and allows only
to add or change parts but not to remove them.
When a new ECO is created, the ECO’s originator can select the manufacturing plants where the change
shall be bypassed. If it is not required, by default every change will be applied to all plants approved for
current design organization. Once the ECO is released, the system copies all released engineering
changes to the manufacturing group as new mBOM or mBOM changes. For each manufacturing plant,
the system also creates a separate MCO for implementing these changes. When an MCO is created, a
trigger notifies and assigns it to the person with the active MCO Coordinator role in the affected plant.
MCO coordinator then has to assign manufacturing engineers responsible for the change implementation
(RMEs), as well as set up the list of required approvals and reviews. When all required changes to
mBOM are done, the MCO is reviewed and then might be released. Once the mBOM is released it can
be transferred to ERP system, which means that the new or revised product can now be launched for
production.
ENOVIA X-BOM manufacturing provides much wider set of tools to manage and control mBOMs but
the process of implementation is still rather uncontrolled.
21
About TVC
Technia Value Components (TVC) is a brand name for a set of software tools developed by Technia
AB. The idea to create such product emerged from the observation of multiple Technia’s customers
demanding similar changes to out-of-the-box (OOTB) ENOVIA functionality. These common demands
were analyzed, categorized and based on the experience of over 40 successful PLM implementations
evolved into TVC product. All the tools within TVC are aimed to enhance the performance, usability,
configurability and extensibility of ENOVIA solutions (2014f).
Currently, TVC suite includes the following components:
Structure Browser Component – the most widely-used component, which provides enhanced
capabilities for navigating indented structures and flat lists of business objects. Compared to
ENOVIA out-of-the box functionality for displaying structures, it supports the following
features:
o In-cell editing – browsing and editing object attributes in the same window;
o Advanced multi-column sorting;
o Easy-configurable user tables;
o Drag and drop functionality for building structures;
o Multi-level expand/collapse of structures;
Grid Browser Component – provides the possibility to view different information objects
alongside of each other and to see their respective content in a two-dimensional matrix. Allows
creating dependencies directly from the grid view, using different colors mapped to relationship
types, lifecycle states or attribute values;
Graphic Reporting Component – brings up graphical visualizing abilities to ENOVIA’s business
applications. Provides a framework for creating and configuring charts of different kinds out of
any information in ENOVIA (2014g);
Mobile Access Component – allows to configure a web-based mobile device applications in
order to have access to ENOVIA’s business applications from smart phones and tablets;
Report Generator Component – provides the capability to create standard, formatted reports for
all objects across the breadth of the ENOVIA platform. Reports can be customized with user
content (logos, headers and footers), published and shared in various formats;
Personal Browser Component – makes it possible for users to view and interact with the
information from ENOVIA offline. Personal Browser puts ENOVIA data in a compact, easy-
to-use, portable package which simulates the functionality of the online application, maintaining
security and access rules;
File Manager Component – provide ENOVIA users with the enhanced document management
functionality. Automatically embeds and updates metadata for MS Office documents and allows
making the check in/check out process in fewer steps;
XBOM Manager Component – provides the functionality for creating and managing of
baselines, representing the product structure for a variety of purposes. This tool is mainly used
for creation of manufacturing baselines, which are used as mBOM. A more detailed explanation
of XBOM Manager is given in the next chapter.
The base component within the TVC suite is TVC Core. It provides a framework with a large number
of features and services that are used by the rest of TVC elements. Some of the parts in TVC Core,
however, can be used as stand-alone, without the presence of any other components. The dependencies
within Technia Value Components are shown on Figure 13:
22
XB
OM
Man
age
r
MC
AD
Op
tim
ize
r
EC M
anag
er
Gri
d B
row
ser
Gra
ph
ic R
epo
rtin
g
Rep
ort
Ge
ner
ato
r
Per
son
al B
row
ser
File
Man
ager
Mobile Access
Structure Browser
TVC Core
Figure 13. The overview of dependencies between different components within TVC suite
About TVC XBOM Manager
XBOM Manager is a part of Technia Value Components suite (built upon TVC Structure Browser) that
allows creating and managing multiple structures of a product (mBOMs) called baselines.
Multiple structures are often required when product specifications are released and transferred to
manufacturing site. These structures might look differently depending on:
Manufacturing location;
Prototype build;
Maintenance level.
XBOM manager provides a user interface to reconfigure the eBOM into a series of manufacturing
structures according to their purpose (by default: as-planned, as-delivered, as-maintained and as-built).
There are three types of baselines available in XBOM manager:
Engineering baseline (EBL) – a non-editable snapshot of the eBOM structure. Allows to
document the current state of eBOM before it’s released (e.g. for different prototype builds);
Manufacturing baseline (MBL) – an editable snapshot of the eBOM structure that can be
reconfigured based on a particular plant, assembly sequence or other reason;
XML baseline (XBL) – an editable snapshot of eBOM stored in a light-weighted format.
Engineering and Manufacturing baselines are represented as shadow structures of corresponding eBOM,
as shown on Figure 14. Engineering baselines are non-editable and can be used only to compare different
snapshots of eBOM. In manufacturing baselines objects can be restructured according to the production
intent:
23
Part #01
Part #02
Doc #02
Part #03
Doc #03
Baseline part #01
Baseline part #02
Baseline doc #02
Baseline part #03
Baseline doc #03
Manufacturing Baseline
XBOM configuration of
XBOM configuration of
XBOM configuration of
XBOM configuration of
XBOM configuration of
XBOM configuration of
Figure 14. The representation of shadow structure for EBL and MBL
EBLs and MBLs are represented by shadow structures in ENOVIA, which means that every business
object and every connection in the database are duplicated in order to build-up a structure for EBL and
MBL. XML baselines propose a light-weighted format for keeping information about the structure.
When created, the XML baseline is represented only by one business object, where the structure is stored
in an XML-file that is checked in to the baseline object (Figure 15). XBL structure could be modified.
XML baselines are faster to create, they can be applied to any kind of structures and they allow
performing comparisons.
Part #01
Part #02
Doc #02
Part #03
Doc #03
XML Baseline
<XML>
Figure 15. The structure of XML baselines
24
Methodology
This chapter will describe the preparation steps, strategy and methods used for
collecting and analyzing of information.
Pre-study
In order to get a comprehensive picture on state of the art in the area of design transfer within PLM, the
pre-study task was split in two parts:
Identification of existing functional capabilities able to facilitate the process of Design Transfer
within ENOVIA V6/TVC suite;
An overview of other PLM products from world-leading vendors and their capabilities in the
area of Design transfer.
The study on existing ENOVIA\TVC tools has been conducted mainly through working with software
documentation (user and administrative guides), as well as through practical sessions in a sandbox
environment provided by Technia AB. Author also had the opportunity to participate in several internal
trainings, related to using, configuring and further development of TVC.
Since the most of PLM products on the market are related to commercial software, it was not possible
for the author to explore their functionality in practice or to get access to the official documentation.
The only available source of information was presented by white papers, brochures and other marketing
materials.
Strategy for research
According to Denscombe (2010), a strategy for a small research project has to be determined from the
perspective of suitability, feasibility and ethical considerations. The most suitable strategy can be
defined based on the purpose of study. Since the formulated purpose of the current paper implies solving
a practical problem and providing guidelines for best practice, an action research strategy was
considered to fit the most (Denscombe, 2010).
However, there are some requirements behind the approach of action research, which made it not
feasible in the context of this Master’s thesis. Some of the unsatisfied criteria, derived from the working
definition of Action research (Zuber-Skerritt, 2012), can be listed:
Action research suggests that is has to be practical, in a sense that results of the research should
lead to immediate practical improvements during and after the process. In the case of this paper,
it means that a developed solution of a new process had to be delivered to customers of Technia
AB and tested by them. That was not possible mainly due to the time frames and, the fact that
author lacked knowledge and experience in the area of PLM change implementation;
Action research implicates that practitioners are ready to publish their experience not only to
other members of the research, but also to anyone interested in and concerned about the results
of the project. This requirement could not be satisfied, due to the fact that internal processes
used by customers of Technia AB are confidential to a certain extent, and therefore cannot be
entirely shared to public;
Action research has to be collaborative and participative, which means that the researcher should
not be considered as an outside inquirer, but rather as a co-worker doing research for the benefit
25
of practitioners, concerned with the practical problem. However, current research was initiated
by Technia AB and was acknowledged only as the potential reference for future
implementations. Customers of Technia AB could not get any direct benefits from this project,
but potentially can benefit in future in terms of their further collaboration with Technia.
After the action research strategy was rejected as not feasible, it was decided to scrutinize the suitability
of case study approach. Yin (2003) defines a Case study as an empirical inquiry that investigates a
phenomenon within its real-life context and relies on multiple sources of evidence. Denscombe (2010)
characterizes it as research which is focused on one (or several) instances of a particular phenomenon
with “a view to providing an in-depth account of events, relationships, experiences or processes occuring
in that particular instance”. Applying these working definitions to the purpose and objectives of current
paper, it was concluded by the author that a case study can be considered as a suitable research strategy,
because:
Research is supposed to be based on a naturally occurring situation
Research is supposed to be focused on relationships and processes
Research is supposed to be focused on one or few instances of processes
Choosing case studies and data collection methods
In this report, the case study is examined as a way of handling the Design Transfer process by a specific
company. Denscombe (2010) points out that all case studies have to be chosen based on their relevance
to the practical or theoretical problems being researched. In the case of this research, all the customers
of Technia AB using PLM software for production fit the scope, which makes the list of potential studies
to be of more than 100 positions. However, the choice of specific case studies should also be justified
based on the way the case study will be used or some practical considerations (Denscombe, 2010).
The following companies were chosen for case studies:
GE Healthcare AB – Swedish company operating in the life science domain and producing a
broad range of products and services for improving productivity and safety in healthcare
(chemical products and medical devices). GE Healthcare was chosen as the typical instance of
a company that has build the process for design transfer with using TVC XBOM Manager;
Toyota Material Handling Sweden AB – Swedish company operating in industrial equipment
domain and producing forklift trucks. This case study was chosen as another typical instance
since Toyota MHS is one of the few customers of Technia, facilitating the process of design
transfer with using of ENOVIA X-BOM Management;
Mölnlycke Healthcare AB – Swedish medical device company mainly producing disposable
surgical and wound care products. This case study can be considered as an extreme instance,
because Mölnlycke developed their own processes allowing to manage the process of design
transfer without using any special tools from ENOVIA or TVC.
Author believes that the selection of case studies above satisfies the purpose of this research since it is
represented by a diversity of industrial domains and business solutions used.
The case study strategy provides a researcher with a relatively high freedom to choose the research
methods. In fact, this approach even encourages the use of various data collection methods in order to
capture the complex reality under scrutiny (Denscombe, 2010). One of the most essential and commonly
used sources of case study information is interview (Yin, 2003). Denscombe (2010) emphasizes that as
potential data collection methods, interviews are better exploited when they are used for the exploration
26
of more complex and subtle phenomena, rather than for gathering information on simple and
uncontroversial facts.
Interviews
According to Denscombe (2010), all interviews can be classified as structured, semi-structured or
unstructured. For the purpose of this thesis, it was decided to use semi-structured interviews as most
suitable. This data collection method implies that a researcher prepares a specified list of questions to
be answered, but the order in which these questions are expected to be asked is rather flexible. Semi-
structured interviews for case studies are usually of an open-ended nature (Yin, 2003), when researcher
can ask the respondent to share his or her own ideas and propositions on particular occurrences.
Another classification of interviews suggested by Denscombe (2010), divides them by number of
participants and the way of communication: one-to-one interviews, group interviews and focus groups.
The process of design transfer inevitably requires participation from people with different business roles
and, therefore, initially the form of group interviews was selected as most appropriate. However, due to
practical reasons (mainly because of tight working schedules of interviewees) it was impossible to
arrange them. One-to-one interviews with company representatives were carried out instead. In all three
case studies, the requirement for representatives was to have a solid understanding of business processes
behind the design transfer and experience of PLM implementation in this particular company (from the
customer perspective).
In total three one-to-one semi-structured interviews were carried out. All respondents have not seen the
questions before the interview but were provided with a general description of this study and its purpose.
Each interview lasted from 1 to 2 hours. Two of three interviews were recorded and later on transcribed.
In one case, representative wished not to be recorded, so the author had to take notes by hand.
During the interview period author also got an opportunity to use additional sub-method of collecting
data – working with focus group. Denscombe (2010) defines a focus group as a small group of people,
who are brought together by a researcher in order to explore their thoughts, ideas and perceptions about
a particular topic. At the beginning of the project such type of interview was considered as perspective,
but later on was acknowledged as not feasible to arrange. However, in March 2014 Technia AB came
up with the idea to organize a new event called Technia Life Sciences Customer Advisory Board. The
purpose of this event was to set up a forum for technical representatives from companies using PLM in
life science in order to let them discuss and benchmark contemporary issues and challenges. Technia
AB, in its turn, could obtain the information required to develop its strategy and solutions for customers
from medical device, diagnostics and pharmacy domains.
The event took place on April 8th, 2014 and gathered more than 12 representatives from companies
operating in different countries: Sweden, Denmark, US and Japan. Advisory board was held in the
format of roundtable discussions. Several topics were selected based on the relevance to needs of
customers: Product Variance and Configuration, Quality Management, FDA (Food and Drug
Administration) compliance. Each session was carried out under the supervision of the moderator
assigned among Technia’s representatives. Moderators made a brief introduction to the topic and set up
the questions for discussion. Each session continued for one hour.
One of the topics on the agenda was Design Transfer to Manufacturing. Author of this thesis, was
assigned as a co-moderator for this discussion and made an introduction to the topic. The session
gathered eight participants and lasted for 60 minutes. The whole discussion has been recorded on tape
and later on thoroughly transcribed.
27
Analysis
There are two major approaches used in order to describe, explain and interpret the data collected:
quantitative and qualitative (Denscombe, 2010). Taking into account the purpose of this study, as well
as the strategy and methods adopted, it was decided to use qualitative approach, due to its following
characteristics:
It tends to rather use words or visual images than numbers as the unit of analysis;
It tends to rather be associated with researcher involvement than detachments;
It tends to rather work with a holistic view than with analyzing specific variables;
It’s more suitable for a small-scale rather than for a large-scale study.
The analysis of collected data was performed immediately after each case study. All information
obtained from interviews was categorized according to different aspects of design transfer process. All
information about business processes gathered from the customers of Technia AB was combined into
flowcharts and other graphical materials. Results were discussed with interviewees, in order to verify
them and to eliminate any misinterpretations.
Literature review
This chapter will give an overview on the existing and relevant research papers that have
been published recently .
Scope of literature review
The scope of the literature review was formulated in accordance to the purpose of current study. Since
this thesis aims to uncover the possibilities for improving of existing PLM software in the area of design
transfer, author mainly observed two groups of research materials:
Those describing general issues and challenges related to design transfer;
Those describing innovative methodologies and strategies that can be used in order to facilitate
sharing of manufacturing-related data within PLM and between PLM and other industrial IT
systems;
Manufacturing Process Management functionality was extensively brought to PLM in the middle of
00’s (Fortin and Huet, 2007), so this study was focused mainly on materials published after year 2000.
Some less relevant papers, however, were also observed and examined.
General issues and challenges related to design transfer
Pascoe (2011) notes that the transition phase from product development to pilot or full-scale production
often becomes a time interval where many failures occur. Author points out that careful analysis of
documented causes for such failures showed that most often they happen because management either
fails to recognize certain risks related to design transfer process, or fails to take necessary actions to
mitigate already identified risks. In both cases, the product cannot be manufactured and tested
efficiently, which in turn leads to production breaks due to design and manufacturing changes.
28
Production breaks might result in severe increasing of unit cost. The increase in program cost resulting
from the production break is illustrated as the hatched area on Figure 16:
Un
it c
ost
Quantity
Programme cost increase
Production break
Initial unit cost
Increased unit cost
Figure 16. Impact of production breaks on unit cost (Pascoe, 2011)
Based on this information authors comment that it is crucial to prevent early design authorization
without due care to production. Management should allocate adequate funding aimed at early
development of hardware for design robustness, reliability and manufacturability growth activities.
Quite often such investments are neglected, and it brings up incorrigible financial losses. On Figure 17
the hatched area represents the money that should have been allocated for improving the design from
the manufacturing perspective, but have been lost instead.
Elapsed project time
RD
T&
E co
sts
pe
r an
nu
m
Traditional Spend Profile
Cost Effective
Spend Profile
Figure 17. Two ways of funding the product development process (Pascoe, 2011)
The idea of necessity to involve the manufacturing side on the early stages of product development is
also supported by Teixeira and Bradley (2002), who reviewed the process of design transfer in the
context of medical device production. Authors discussed a number wrong decisions usually taken by
management that result in partial or complete excluding of manufacturing engineers from participating
in design process. Most common cases were illustrated with the examples.
El-Haik and Mekki (2008) along with Justiniano and Gopalaswamy (2003) confirmed that in order to
manage the process of design transfer effectively it takes to establish close working relationships
29
between teams participating in product development: design, manufacturing, service and other
stakeholders. The key to success according to authors is a comprehensive planning that should be
performed on the early stages of product lifecycle. El-Haik and Mekki (2008) suggested using of
advanced product quality planning (APQP) as the framework for such planning activities.
Yin and Tang (2013) made a research on Engineering Change Implementation Planning (ECIP) – the
part of the engineering change process that is intended to develop an appropriate timetable for actions
required during implementation activities (BOM modifications, purchasing orders and consuming
current inventories). ECIP can be considered as another type of planning, which does not directly affects
the process of design transfer, but aims to minimize the cost of change and its impact on production
schedule.
Fortin and Huet (2007) reviewed the strategy for Manufacturing Process Planning (MPM), which is
intended to cover all activities related to manufacturing planning starting from strategic planning of the
product development and ending with the reaching of production stability. According to authors, the
future development of MPM, and hence the evolution of design transfer, exclusively connected with the
developments of digital environments and sophisticated data management technologies such as PLM,
ERP, CAD, CAM, SCM and CRM. Stressing the importance of MPM, researchers consider MPM as
the central element providing the necessary integrations between these systems (Figure 18).
MPM ERPPLM
CRM
CAM
CAD
Engineering Production
Clie
nt
Sup
plie
r
Figure 18. MPM at the heart of the integration axes (Fortin and Huet, 2007)
30
Innovative methodologies and strategies for design transfer in PLM
Ming et al. (2008) reviewed recent academic and industrial researches related to effective collaboration
among designers, suppliers, manufacturers and customers. As the result, authors managed to identify
several primary difficulties, most of the companies encounter within the area of product and process
development:
Traditional Product Data Management (PDM) systems make exchanging engineering data with
suppliers slow, painful and geographically limited;
Imperfect coordination between organizations;
Complex approval processes;
Systems and data incompatibility.
The main reason for these problems, according to Ming et al. (2008) is that traditional industrial
application systems (CAD, CAM, CAPP) are usually separated from company’s mainstream operations.
This leads to the inability for some of the participants, who may have been able to add value to the
design, to influence or even comment on it. When it becomes possible for them to join the process, often
it is either too expensive to implement design changes or changes are not made at all, which routes to
inefficient product design and unsatisfied customer needs. Authors claim that even though modern
industrial software systems (PLM, SCM, ERP, MES, CRM) have been developed to overcome some
aspects of above problems, they still cannot address the needs for collaborative capabilities throughout
the entire product lifecycle in an adequate way.
As the solution Ming et al. (2008) proposed a set of requirements for a new system, called Product
Lifecycle Collaboration (PLC) and provides a conceptual schema of it (Figure 19).
Collaborative Product
Development
Collaborative Component Supply
Collaborative Portfolio
Management
Collaborative Product
Manufacturing
Collaborative Product
Customization
Extended Product Service
Collaboration protocols
Organization A
Product Lifecycle Processes
Organization B
Product LifecycleProcesses
Collaboration Protocol
Information Alignment
Message Alignment
Event Alignment
Method Alignment
Process Alignment
Goal Alignment
Alig
nm
ent
Inte
rfac
eA
lignm
ent In
terface
Stakeholder:Project
Management
Customer:CRM, DCM
Manufacturer:MES, ERP
Supplier:SCM, SRM
Developer:CAD, CAPP, CAM, CAE, PDM, EDM
Figure 19. A schematic view of Product Lifecycle Collaboration (Ming et al., 2008)
31
The idea suggests that different aspects of data management functions are divided among several
domains, which are supposed to be connected via so called collaboration protocols. Protocols provide
various companies with general regulations to facilitate real time collaboration through the entire
lifecycle and include a bunch of layers for collaboration alignment, such as goal, process, event,
message, method and information. Later on authors try to explain the concept of PLC by presenting a
framework and technology for collaborative Process Planning (CAPP) and Computer Aided
Manufacturing (CAM). However, any detailed information on the concept of collaboration protocols is
not provided.
Tang and Qian (2008) investigated the evolution of PLM framework and tools from the perspective of
integration between original equipment manufacturers (OEM) and suppliers in the automotive industry.
Authors refer to contemporary researches in the field of concurrent engineering and supply chain
management, which found that considerable benefits can be achieved if suppliers are involved in product
development processes as early as possible. The reason is that the supplier organizations often have the
greater depth of expertise that can lead to improved product design. The paper is intended to show, that
traditional approach for collaboration when OEM provides supplier with product requirements and
supplier delivers product or service to OEM doesn’t allow companies to stay competitive. Instead, a
new approach is proposed, implying that supplier organizations should be involved into product
development process, to be able to complement the design with their own creativity and innovativeness.
Developing this idea, authors proposed the concept of PLM framework that is focused on supplier
integration for automotive development (shown on Figure 20).
PLM framework
Classical PLM tools
Supplier integration tools
Product Data Management
Process Management
Configuration Management
Project Management
…
Supplier selection
Partnership Management
Information Share
Communication
…
Automotive OEM
Project
Marketing
Idea
Design
Production
…
Pro
du
ct L
ifec
ycle
Supplier & Partners
Response
…
Services
Production
Co-design
BiddingSu
pp
ly a
ctiv
itie
s
Figure 20. PLM framework focusing on supplier integration for automotive development (Tang and Qian, 2008)
The essential element of suggested framework is information sharing between suppliers and OEMs. In
order to facilitate this process, authors propose to classify data into several categories (private, public,
exchangeable and interoperable) and to use a particular interaction method for each category(browsing,
exchanging, quasi-interoperating and interoperating correspondingly). Such approach should allow
decreasing expenditures required for partnership management and coordination.
(El-Jamal, 2008) suggested the methodology for identifying the impact that an engineering change can
have on the manufacturing process in a systems engineering context. However, author did not provide
any details on how manufacturing related business objects are supposed to be stored within PLM and
how exactly they are linked to design data in his study.
32
Ben Khedher et al. (2011) made a research on integration between PLM and Manufacturing Execution
Systems (MES). Authors claimed that currently most of the enterprises, using discrete-manufacturing
processes, deploy the architecture presented by two types of software: ERP and PLM. The typical case
of information exchange between these IT-systems is shown on Figure 21:
PLM
ERPM
BO
Ms
Production status
Plant #2Plant #1
Production status
Invetory status Invetory statusIn
ven
tory
sta
tus
Inve
nto
ry s
tatu
s
Figure 21. Data exchange in PLM-ERP architecture (Ben Khedher et al., 2011)
According to this study, discrete manufacturing in general enables low level of utilization of MES
solutions due to its characteristics. However, evolving of production systems towards increasing
flexibility and need for realistic performance indicators lead to the wider implementation of MES in
particular types of enterprises. The ERP-PLM-MES architecture describing the example of such
implementation is shown on Figure 22:
PLM
ERP
MB
OM
MES
MBOMProcess planOperator instructionsMachine setups
Production status
Plant
Production schedule
Detailed production
status
Figure 22. Data exchange in PLM-ERP-MES architecture. (Ben Khedher et al., 2011)
In the solution proposed by authors, all manufacturing-related data (e.g. bill of processes, machines and
materials) should be stored and managed in PLM. MES controls the transforming of digital product into
a physical one and provides ERP and PLM with the current production status. This allows to generate
critical performance indicators which later on can be used in order to improve future versions of product
information.
(Young et al., 2007) investigated problems related to sharing of information and knowledge in cross-
disciplinary teams within PLM systems. The research highlights that due to historical reasons, PLM
33
systems were traditionally focused on a design perspective and from the manufacturing part of product
lifecycle they at best could provide the association between manufacturing documents and parts.
However, now global business demands more extensive data models, which should be able to identify
specifications for processes, resources, potential methods and best practices for manufacturing. Authors
also mention that a major step forward in the development of PLM would be achieved if functional
requirements for components could be linked to the relevant production views (e.g. casting, heat
treatment, machining). In order to facilitate this concept, it is advised to use heavyweight ontological
approaches such as the Process Specification language (PSL). The results from this study showed that
PSL is rather effective in seizing the semantics of manufacturing processes but provides very limited
support for connecting the parts with resources on the shop floor.
Gunendran and Young (2010) continued developing the concept of organizing connections between
different domains of data: manufacturing best practice knowledge, relationships between its elements
and their relationships to product design data. Authors proposed a design realization system that would
consume the information from three data models as it is shown on Figure 23.
Product model
Library of Manufacturing best practicies
Manufacturing model
Design realization
Manufacturing feedback
Design engineer
Manufacturing engineer
Figure 23. Information and knowledge models for design realization (Gunendran and Young, 2010)
The product model is represented by a database storing such data as geometry, materials and functional
characteristics. Manufacturing model is the storage of manufacturing tools, processes and resources
available within a company. Finally, the library model provides a collection of best manufacturing
practices, describing the way in which existing manufacturing capabilities should be applied. The
combination of these databases is supposed to generate manufacturing feedback for both design and
manufacturing engineers that should allow identifying the most appropriate sequence of operations for
the current design. Such feedback after can be used to make a decision either towards improving
manufacturability of a product or towards reviewing and updating the corresponding best practice.
Authors described all three data models by means of UML (Unified Modeling Language) and
implemented the proof-of-concept in the PLM environment.
34
Proposed enhancements
This chapter presents the proposals synthesized from the theoretical and empirical
studies described in previous chapters.
After thorough analysis of information obtained from the case studies, it became possible to formulate
several major directions for possible enhancements of the design transfer process:
Speeding up the process – making the process of design transfer more streamline, fast and
flexible: eliminating bottlenecks and unnecessary processing;
Ensuring better reliability and correctness – decreasing the probability of failure during the
design transfer;
Increasing the visibility – providing change coordinators and other concerned stakeholders with
a better visibility over the design transfer process.
Several suggestions were proposed in order to improve the existing tools and processes towards the
above directions.
MPM business objects in ENOVIA
As it was described previously, ENOVIA V6 portfolio includes tools to handle some kinds of
manufacturing-related information, like mBOMs or manufacturing plants. However, there are many
business objects on the shop-floor level that are not supported in ENOVIA OOTB e.g. workstations,
process plans, tools, fixtures, work instructions and working skills. From the perspective of Dassault
Systèmes, all these objects are supposed to be handled in DELMIA application.
Companies that don’t use DELMIA in their processes usually keep this kind of intellectual property
outside of PLM at the production sites. As a result, it has an adverse effect on the collaboration between
design and manufacturing: people at the factory get the mBOM from ENOVIA and then must inquire
another system in order to find out what process plans and work instructions they need to change.
Another problem that may arise is impeded traceability: some companies, working in strictly-regulated
industries, like life sciences, get into a situation when their device master and device history records are
scattered across several systems. That might affect the time needed for a drug or medical device to be
approved by an authorized regulator.
In current paper, there was proposed a model, which can be later used as a reference for creating of
ENOVIA business objects, reflecting manufacturing IP (Figure 33):
35
Machinery verification protocols
Operational Qualification
Perfomance Qualification
Installation
Qualification
Process Plan
“Make” part Operation #1 Operation #3 Operation #4Operation #2
Requirements specifications
Functional requirements spec
User requirements spec
Design spec
Workcenter
Function #2
Function #3
Function #1
SkillspFMEA
Machinery service specs
End-item product
mBOM
Related specs
Work Instructions
Manufacturing Quality Plan
Storage requirements
Material handling requirements
Tooling
Fixtures
Tools
NC programs
CMM programs
Figure 24. The proposed reference for setting of manufacturing-related business objects in ENOVIA
Each end-item part and its child “make” parts in the plant-specific mBOM have an associated process
plan, which is comprised of manufacturing operations. A process plan is connected with a manufacturing
quality plan that contains specifications on how the material should be handled and stored between
operations. Manufacturing operation reflects any separate value-adding activity affecting the part on a
shop-floor and is the essential item type connecting other items:
Tools, fixtures and auxiliary rigs;
Process failure mode and effect analysis (pFMEA) protocols;
Special skill requirements (e.g. compulsory certification for a welder);
NC/CMM programs;
Work instructions
Machine equipment required for the manufacturing operation (if it is not a simple bench operation e.g.
assembly or visual inspection) can be represented by a separate item type – workstation. Associated
workstations allow tracing the production output up to the machine it was worked on. In order to ensure
that manufacturing process is performed according to requirements, each machine can be connected
with a set of verification protocols: installation qualifications (IQ), operational qualifications (OQ) and
performance qualifications (PQ). Complex workstations that could perform multiple manufacturing
operations (e.g. 5-axis multi-spindle machining centers) can be split up to separate functional domains.
This approach would allow verifying every function separately instead of performing qualification
analysis of the whole machine.
Configurable Change Orders
As it was mentioned before in this paper, users responsible for coordinating of the engineering or
manufacturing change process have to initiate workflows for transferred data. In ENOVIA V6
workflows are defined within a particular item type called route. Routes are instantiated between states
of business object’s lifecycle and are presented by a set of tasks for various business roles (shown on
Figure 25). If the route is not finished, the object cannot be promoted to the next state.
36
Role: Manufacturing
engineer #3
Action: Approve
Role: Manufacturing
engineer #2
Action: Approve
Role: Manufacturing
engineer #1
Action: Approve
Role: Senior Manufacturing
engineer
Action: Approve
Role: Quality engineer
Action: Comment
Role: Safety engineer
Action: Comment
Start End
Figure 25. The example of route in ENOVIA V6
Some of the case studies revealed the potential issue related to routes. When user initiates the creation
of change order (or change request) he has to select appropriate routes from the list of predefined
templates, based on the type of change, type of associated objects or particular manufacturing site. A
number of different routes used in the company can be relatively high to make it possible for initiator to
choose the wrong workflow. As a result, it can lead to failures in the design transfer process and
unnecessary rework.
In order to prevent potential waste of time and resources, it was proposed to introduce the tool that would
allow choosing the correct routes by filling out the predefined questionnaire. The concept of the
recommended solution is shown on Figure 26:
Route templates
Unconfigured ECR/ECO
Configured ECR/ECO
QuestionnarieQuestionnarie
Change order templates
Figure 26. Configuring of ECR/ECO via predefined questionnaires
The proposed idea suggests introducing of new item type – a questionnaire that consists of a list of
questions. Questions should require simple answers (“yes” or “no”) and can be extended by sub
questions, depending on the given answers (Figure 27).
37
Does the change concerns engineering parts?
Are there any other types of parts affected?
Is it a formal change?
Figure 27. The example of questionnaire prepared for user
When the questionnaire is filled out and submitted by user, the appropriate routes are added to
ECR/ECO. Optionally, provided answers might also be used for fetching the relevant ECR/ECO
template (with predefined attributes) from the database.
Phased release and implementation process
The traditional ECR/ECO process, described in the extended introduction chapter, has a significant
disadvantage. The control over the implementation of the ECO (or MCO) is carried through in two
levels: administrative and executive. On the administrative level a coordinator plans the change,
allocates appropriate human resources and monitors the progress. Execution level supports the actual
change work and peer validation approving. The combination of these two functional groups applied to
change order leads to the situation when all objects affected by the ECO can be released only when the
ECO is released. As a result, design specifications of all parts under the ECO can be available for
production only when all of them have been reviewed (Figure 28):
Release progress: 0%
In Work
Part #1
Part #2
Part #3
Approved
Approved
In Work
Part #3 In Work
Review Released
Part #1
Part #2
Part #3
Released
Released
Released
Part #3 Released
Release progress: 0% Release progress: 100%
Ready for review and
release
Part #1
Part #2
Part #3
Approved
Approved
Approved
Part #3 Approved
Figure 28. Conventional process: all parts affected by an ECO cannot be released one-by-one
With the ECO process, change coordinator can try to even out the planned release date by distributing
the design tasks, according to the complexity of change and the skill level of DEs. However, in some
situations it might become important to release certain parts earlier than others e.g. depending on
different lead times: whether it is a “buy” or “make” part purchasing and material planning may want to
put an order for corresponding parts/materials in advance. Process planning activities for some parts
also might require significantly higher efforts and time than for others, and it is not always possible to
estimate this difference during the ECO planning. Currently, the only way for a change coordinator to
facilitate the issues above is to create a set of separate ECOs related to the same ECR.
In order to resolve this problem, it was proposed to introduce a new item type, tentatively called sub-
ECO, which would take on the executive functions of an ECO. This new item type should be related to
ECO with a “many to one” relationship type and should accommodate all the parts affected by a change
38
order. Affected objects can be split up to different sub-ECOs, which in turn can be released one by one
(Figure 29):
ECO
Part #1
Part #2
Part #3
Part #4
Sub-ECO
Part #3
Part #4
Should have been released yesterday
Can be released later
In Work
In Work
Sub-ECO
Part #1
Part #2
Released
Sub-ECO
Part #1
Part #2
In Work
Mfg.Sub-ECO
M Kit #1
Part #1
In Work
Process plan
Part #2
Process plan
MPart #1
Mfg.Sub-ECO
M Kit #1
Part #1
Implemented
Process plan
Part #2
Process plan
MPart #1
Release progress: 50% Implemenattion progress: 50%Release progress: 0% Implementation progress: 0%
Release progress: 0%
Figure 29. Suggested process: introduction of sub-ECOs
Sub-ECO can be auto-created when affected items are added to an ECO. By default, the number of
generated sub-ECOs could be dependent on a combination of properties of affected parts, such as
responsible design organization, object’s type or policy (Figure 30):
ECO
Part #1
Part #2
Part #3
Part #4
Sub-ECO #1
Responsible: Company 1Type: Hardware partPolicy: Engineering part
Responsible: Company 1Type: Hardware partPolicy: Engineering part
Responsible: Company 2Type: Software partPolicy: Development part
Responsible: Company 2Type: Hardware partPolicy: Development part
Sub-ECO #2
Sub-ECO #3
Figure 30. Business logic for creating of sub-ECOs by default
Introduction of a sub-ECO should not have a serious effect on Engineering Change process, described
previously in this paper. In a conventional process, change coordinator assigns each affected object
under an ECO to a competent design engineer. With a new process change coordinator will distribute
affected objects to different sub-ECOs, each having its own route, list of DEs assigned, list of reviewers
and approvers. Once the ECO is promoted to in “work” state, all assignees can start working on their
sub-ECOs. When a change is done, and sub-ECO is approved by all peers – all affected objects get
released. When all sub-ECOs reach the final state, the corresponding ECO is auto-promoted to the final
state. If, as it was suggested in the previous section, manufacturing-related business objects are managed
within PLM, responsible manufacturing engineers then can easily trace the affected process
specifications and to effectively release them, using another type of sub-ECO (tentatively called
“Manufacturing sub-ECO”).
39
Optionally, change coordinator can be provided with functionality to set up dependencies between
different sub-ECOs. For instance, design engineer assigned to a sub-ECO should not be able to start
working on it until another sub-ECO, related to the same ECO, is completed. This feature could be
useful for streamlining the design process, when affected objects are dependent on each other and
assigned to various responsible organizations.
In general, customers of Technia AB gave a positive feedback on the idea of phased design release and
implementation. However, it was noticed that proposed modification of change process might be
difficult to implement on an enterprise level, because the new approach presumes the situation when
multiple released sub-ECOs (with associated released parts) refers to a single ECO that is not released
yet. Such process behavior can be considered as confusing by people who used to work with the
conventional process for a long time and therefore it might require additional trainings.
Preliminary mBOM
As it was noticed in the literature study, it is crucial to involve the manufacturing site into the process
of design development as early as possible. This involvement implies that manufacturing engineers
should be able to:
Set up requirements for design in order to provide better manufacturability of a product;
Start developing manufacturing plans and procedures before the design is completed;
Start working with the mBOM (split quantities, restructure, etc.) before the design is completed;
Currently, TVC X-BOM Manager allows creating mBOMs at any state during the product lifecycle.
However, at companies using the ENOVIA X-BOM Manufacturing, the mBOM can be created only
when the ECO with the corresponding eBOM gets released. Before this point manufacturing engineers
can only give input (either during the evaluation of an ECR or when an ECO is reviewed) for the design
team but cannot “put their hands” on mBOM (Appendix 1). In order to solve this problem, it was
suggested to introduce a new type of BOM which can facilitate the process of eBOM-mBOM translation.
In this paper, such intermediate bill of materials will be tentatively called “preliminary mBOM."
Preliminary mBOM can be introduced as an optional feature, created when it needs to accelerate the
process of manufacturing planning. User can request the creation of preliminary mBOM from existing
eBOM for an end-item part. Once the preliminary mBOM is created, all following mBOMs will be
generated from it and not from the eBOM (Figure 31).
MBOMPart #1
Kit #1
Part #3
Part #4
Part #6
Part #7
Part #8
MPart #1
Part #8
qty: 15qty: 15
EBOMPart #1
Part #2
Part #3
Part #4
Part #5
Part #6
Part #7
Part #8
qty: 30
Preliminary MBOMPart #1
Kit #1
Part #3
Part #4
Part #6
Part #7
Part #8
Part #8
qty: 15
qty: 15
Figure 31. The concept of optional preliminary mBOM
40
Once the creating of preliminary mBOM is initiated, manufacturing engineer should manually move to
it all parts and assemblies from corresponding eBOM. Once moved, each part is consumed by
preliminary mBOM. If not all the engineering parts were consumed by preliminary mBOM, it cannot
be considered as valid and conventional mBOM cannot be generated from it. The structure of
preliminary mBOM should be updated every time when the new revision of related eBOM is released.
As in conventional mBOM, manufacturing engineers should be able to restructure engineering parts
according to manufacturing intent: split quantities, create assembly kits and phantom parts.
Checklists
People involved in the design transfer process have to take certain actions depending on the type of
change and their business role. These actions are usually well-documented in corresponding work
instructions and well-known by responsible engineers. However, the number of required activities can
be considerably high which makes it complex to remember and follow. As a result, omitted actions can
lead to failure and unnecessary rework.
One of the ways to reduce the probability of failure caused by limits of human memory and advertency
is implementation of checklists. Currently, neither ENOVIA nor TVC functionality does support
working with checklists. In all case studies, checklists were used in practice but only as paper
documents, listing the responsibilities of each business role. It makes it uncomfortable and annoying for
engineers to permanently check themselves up with such document and at some point they can stop
doing that. Also, described process can be considered as not very flexible, when it needs to revise
existing checklists.
In the case of design transfer, the most obvious stage of product’s lifecycle for implementing checklists
is peer approving. It’s possible to highlight at least three major milestones, where customers of Technia
would want to have checklists (Figure 32):
CreateDefine
ComponentsDesign Work Review Released
Created Review Released Implemented
MCO Lifecycle
ECO Lifecycle
Manufacturing Engineer reviews the feasibility of change
Design Engineer reviews the
completeness of design work Senior Manufacturing
Engineer reviews the completeness of
manufacturing work
Figure 32. The major stages of a change process that require checklists
Design engineers have to check that all design actions are taken according to requirements
before an ECO can be promoted for review;
Senior Design engineer has to check that new design specifications are developed or changed
according to design intent. Senior Manufacturing engineer has to check that new product is
feasible for manufacturing. As a result of these checks, an ECO can be released;
Senior Manufacturing engineer has to make sure that all design specifications have been
correctly translated into manufacturing processes and instructions.
Depending on routes assigned for change orders, checklists might be also used by purchasing
department, quality engineers, and other stakeholders.
41
The primary requirement for checklists, from the customer side, is the possibility to apply them to any
workflow initiated within ENOVIA. Creating and configuring of checklists should be done by the same
departments they planned to be used at: Technia’s customers should not contact Technia every time they
need to add new or modify the existing checklist. Therefore, instead of being configurable through XML,
the tool should have its own user interface.
In the proposed solution, checklists should be represented as separate item types associated with task
item type in ENOVIA. Each time user opens a task, the system should bring up the appropriate
checklists, selected depending on user’s business role and type of the task.
Collaboration features
One of the promising ways to speed up the design transfer process is enhanced user collaboration around
ENOVIA data. Currently, all notifications in ENOVIA V6 are distributed by e-mail. For instance, when
change coordinator promotes an ECO to in work state, ownership for affected parts is transferred to
assigned design engineers, and they receive an e-mail that contains a description of the task and part
numbers they have to work with. Part numbers are given either in the format of plain text or hyperlinks.
TVC functionality allows introducing of dynamic links, which, for instance, can bring user to the latest
version of the part.
However, in some cases users with certain business roles can receive dozens of e-mails every day, and
the necessity to switch between e-mail client and ENOVIA can seriously impede their ability to manage
tasks.
In the beginning of 2014 Technia AB introduced a new collaboration feature to TVC Core, which
provides users with the following capabilities:
Initiating discussions between users in context of ENOVIA objects
Real time notifications on discussion events
Support for attachments in discussions
Notification panel to quickly view notification content
Profile page with settings and ability to upload an avatar
Author strongly believes that the framework developed for TVC Collaboration can be modified and later
be used for replacing the conventional e-mail notifications. Any ENOVIA user should get in-app
messages once he or she is provided with ownership for an object or assigned to a task. Such in-app
notifications should contain direct hyperlinks to related business objects. Active tasks should be
available for user in the form of “to do” list and once the task is completed, it should disappear from the
list. The approximate view of such notification is presented on the Figure 33:
42
Figure 33. The approximate view of proposed notification
Conclusions and discussion
The present study has gone some way towards enhancing of functionality of ENOVIA V6 and TVC in
the area of design transfer and resulted into several proposals that were consolidated in Table 1:
Proposed enhancement Expected result
The reference schema for a data model that can
be used to store and manage manufacturing
related data in ENOVIA V6
Better collaboration between
engineering and manufacturing
departments
Faster change implementation due to
faster identification of manufacturing
data affected by change
Opportunity to have consistent device
master and history records
The method for configuring of engineering
change requests and change orders through
predefined questionnaires
Decreasing the probability of failure
caused by human inattentiveness and
lack of knowledge
Modifications to existing engineering change
process, allowing phased design release and
implementation
Faster process planning due to earlier
availability of released parts for
manufacturing engineers
Introducing of preliminary manufacturing bill of
materials to ENOVIA X-BOM Manufacturing Faster process planning due to earlier
availability of eBOM for restructuring
43
Bringing customized checklists to peer-
approving process in ENOVIA and a tool for
their creation and configuring
Faster peer-approving process due to
eliminating of necessity to look for
appropriate checklists
Decreasing the probability of failure
caused by human inattentiveness
Extending the existing collaboration
functionality in TVC Better visibility over active tasks for
ENOVIA users
Table 1. Suggested proposals for improving of ENOVIA V6/TVC functionality
The feasibility of implementation of all proposed solutions has been evaluated and confirmed by Technia
supervisor. The start of actual work on implementation was scheduled on the beginning of June 2014
and by the time when this thesis work will be presented, author expects to deliver the proof-of-concept
of a tool for creating checklists in TVC. The prototypes of other proposals are planned to be delivered
in July-August 2014.
In February 2014, Dassault Systèmes released the new platform for their business applications –
3DEXPERIENCE and the new version of ENOVIA (2014x) based on this platform. Comparing to
previous versions, 2014x brought up a number of significant modifications and new features. One of the
major changes affected the concept of Engineering Change Management, which was reviewed and
replaced with a new one, called Enterprise Change Management. In this new business process,
conventional ECRs and ECOs were replaced with new item types called Change Requests (CR) and
Change Orders (CO) correspondingly. Also, there was introduced an additional object – Change Action
(CA). The way COs and CAs are supposed to be used within Enterprise Change Management are very
similar to the method of phased design release, proposed in this paper. Phased change implementation,
however, is still unavailable in ENOVIA 2014x, but the intention to introduce it was listed in plans of
3DS. Changes brought up by the new version have also affected the ENOVIA X-BOM Manufacturing
module. In 2014x release its name was altered to Manufacturing BOM Management and the major
modification of functionality was the addition of so-called Planning mBOM, which, in fact, represents
the preliminary mBOM also proposed in this paper.
Even though new platform from 3DS and new version of ENOVIA were released two months after the
beginning of current study, access to these products and to the corresponding documentation was
obtained by author only in the end of April 2014, when he started documenting the results. Therefore,
author has to recognize the primacy of 3DS in proposing and implementing of listed functions, but wants
to emphasize that he came to the similar conclusions in his own way independently from 3DS.
One of the most significant findings to emerge from the case studies is that it is barely possible to
formulate any best and universal solution for using PLM for design transfer to manufacturing. Even
though all three companies selected for case studies used the same software (ENOVIA V6), in each case
its functionality was utilized in an entirely different way. Each company had its own history and own
experience of managing manufacturing-related information. This multiplied by the specific conditions
imposed by the sphere and type of production led to the unique combination of existing business
processes and methods of using the same tools. Such business systems honed over a long time are
considered as rather stable and even minor intentions aimed to improve them are regarded by
management with a high degree of caution.
44
However, some implications from this thesis can be formalized as a set of general recommendations or
best practices for developing business processes for design transfer within PLM systems:
Involve the manufacturing organization early in the design process. Project team membership
and active participation by this organization are required for an effective design transfer process.
This is the best way to avoid the “throw it over the wall” approach. In order to maximize the
benefit from the collaboration process both design and manufacturing organizations should be
provided with adequate means of communication and tools allowing them to work in parallel.
Having such tools within PLM should provide fast access to product-related information
(BOMs, design and process specifications, machines) and therefore should ensure the efficient
knowledge transfer from the R&D/engineering to the manufacturing organization and vice
versa.
Store and manage all manufacturing-related data in PLM. Having the direct access to the
information in details describing implemented manufacturing processes allows to straightly
associate this data with design records and therefore to build up the single platform for fast and
effective collaboration between different teams within the enterprise. A good example of such
approach can be presented by linking the design of a machined part with the design of
corresponding tools of fixtures used for its manufacturing.
Provide the suppliers and contract manufacturers with the access to your PLM system.
Manufacturers should ensure that partner organizations have tools to implement their
knowledge and creativity during the product development and therefore to bring additional
value to it. The current level of integration between modern PLM software and other Enterprise
Management systems is mature enough to provide the required degree of information security
for both interacting parties.
Include design transfer in the overall project plan, with adequate time and resources and
clearly identified roles and responsibilities. For companies using PLM as the tool for project
management, all design transfer activities have to be carefully considered in a plan that should
contain such information as cross-functional milestones, deliverables and resources. Neglecting
of such planning or its incorrect implementation brings up additional risks, subsequent costs and
in the end can result into lost customers.
Finally, a number of important limitations need to be considered. First, performed case studies did not
include interviews with all business roles, participating in the design transfer activities e.g.
manufacturing engineers, quality engineers, and change coordinators. Such interviews with people who
routinely work with tools and face with existing processes definitely could enrich this study with their
specific knowledge and feedback. Unfortunately, during thesis work there was no opportunity to arrange
such interviews.
More broadly research is also needed to determine how MPM functionality within PLM can be improved
in the context of interaction with other industrial IT systems apart from ERP (e.g. Manufacturing
Execution Systems). For instance, recent hardware and software developments now allow to run MPM-
related apps (i.e. from the DELMIA portfolio) from tablets and smartphones, which can definitely
revolutionize the way of interaction between the shop-floor and other departments within the enterprise.
Unfortunately, all three companies used for case studies in this thesis work have not implemented such
software yet and therefore had no experience to share with author.
45
List of references
2006. Dassault Systemes Announces Completion of Merger with MatrixOne [Online]. Internet
Business Systems, Inc. Available:
http://www10.edacafe.com/nbc/articles/view_article.php?section=CorpNews&articleid=27021
2 [Accessed 20 April 2014].
2014a. Dassault Systèmes [Online]. Available: http://www.3ds.com/products-
services/delmia/products/all-delmia-products/ [Accessed 18 April 2014].
2014b. Dassault Systèmes [Online]. Available: http://www.3ds.com/products-services/enovia/
[Accessed 15 April 2014].
2014c. PTC Windchill® MPMLink®. PTC Inc.
2014d. Siemens PLM Software [Online]. Available:
http://www.plm.automation.siemens.com/en_us/products/tecnomatix/ [Accessed 18 April
2014].
2014e. Technia [Online]. Available: http://www.technia.com/About-Technia1/About-
Technia/Technia-in-short/Technia-English/ [Accessed 15 April 2014].
2014f. Technia [Online]. Available: http://www.technia.com/products/Technia-value-
components/TVC-Overview/TVC-Overview-/ [Accessed 21 April 2014].
2014g. Technia [Online]. Available: http://www.technia.com/products/Technia-value-
components/Graphic-Reporting-Component/TVC-Graphic-Reporting-Component/ [Accessed
20 April 2014 2014].
2014h. V6R2013x User Guide [Online]. Dassault Systèmes. Available:
http://media.3ds.com/support/documentation/product/V6R2013x/en/English/DSDoc.htm
[Accessed 15 April 2014 2014].
BEN KHEDHER, A., HENRY, S. & BOURAS, A. Integration between MES and Product Lifecycle
Management. Emerging Technologies & Factory Automation (ETFA), 2011 IEEE 16th
Conference on, 2011. IEEE, 1-8.
BROWN, N. 2012. Innovative Manufacturing Applications [Online]. Aras Corp. Available:
http://www.google.se/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved
=0CCUQFjAA&url=http%3A%2F%2Fwww.aras.com%2Fblogs%2FACE-2012-
International%2FSLIDES-Aras-Innovative-PLM-Manufacturing-
Applications.pdf&ei=ptOSU8yIGKXTygPUnILwCg&usg=AFQjCNGVM_uxrow1fOrUKoU
pA95KkkaABQ&sig2=abEThqivSc1oT0Lvshz24w&bvm=bv.68445247,d.bGQ [Accessed 17
April 2014].
CRNKOVIC, I., ASKLUND, U. & DAHLQVIST, A. P. 2003. Implementing and integrating product
data management and software configuration management, Boston ; London, Artech House.
46
DENSCOMBE, M. 2010. The good research guide : for small-scale social research projects,
Maidenhead, McGraw-Hill/Open University Press.
EL-HAIK, B. & MEKKI, K. S. 2008. Medical device design for six sigma : a road map for safety and
effectiveness. Hoboken, N.J. ; Chichester: Wiley-Interscience.
EL-JAMAL, M. H. Requirements Change using Product Lifecycle Management for Manufacturing
Processes in a Systems Engineering Context. 3rd International Conference on Information
and Communication Technologies: From Theory to Applications, 2008. 1-5.
FORTIN, C. & HUET, G. 2007. Manufacturing Process Management: iterative synchronisation of
engineering data with manufacturing realities. International Journal of Product Development,
4, 280-295.
GUNENDRAN, A. G. & YOUNG, R. I. M. 2010. Methods for the capture of manufacture best
practice in product lifecycle management. International Journal of Production Research, 48,
5885-5904.
JUSTINIANO, J. M. & GOPALASWAMY, V. 2003. Practical design control implementation for
medical devices, Boca Raton ; London, Interpharm/CRC.
MING, X., YAN, J., WANG, X., LI, S., LU, W., PENG, Q. & MA, Y. 2008. Collaborative process
planning and manufacturing in product lifecycle management. Computers in Industry, 59,
154-166.
PASCOE, N. 2011. Reliability technology : principles and practice of failure prevention in electronic
systems, Oxford, Wiley-Blackwell.
SÄÄKSVUORI, A. & IMMONEN, A. 2005. Product lifecycle management, Berlin ; London,
Springer.
TANG, D. & QIAN, X. 2008. Product lifecycle management for automotive development focusing on
supplier integration. Computers in Industry, 59, 288-295.
TEIXEIRA, M. B. & BRADLEY, R. 2002. Design controls for the medical device industry, New
York, Marcel Dekker.
YIN, R. K. 2003. Case study research : design and methods, Thousand Oaks, Calif. ; London, SAGE.
YIN, Y. L. & TANG, T. 2013. Research on Manufacturing Engineering Change Implementation
Planning. Advanced Materials Research, 658, 460-463.
YOUNG, R., GUNENDRAN, A., CUTTING-DECELLE, A. & GRUNINGER, M. 2007.
Manufacturing knowledge sharing in PLM: a progression towards the use of heavy weight
ontologies. International Journal of Production Research, 45, 1505-1519.
ZUBER-SKERRITT, O. 2012. Action research for sustainable development in a turbulent world,
Bingley, Emerald.
47
Appendixes
Crea
teEv
alu
ate
Revi
ewPl
an E
CO
Com
plet
e
Impl
emen
ted
EBO
MEB
OM
EBO
MEB
OM
EBO
Ms
EBO
Ms
EBO
Ms
ECO
Lifec
ycle
ECR
Life
cycl
e
Crea
ted
In W
ork
Revi
ewRe
leas
ed
Crea
ted
Revi
ewRe
leas
edIm
plem
ente
d
MCO
Lifec
ycle
EBO
Ms
MBO
Ms
MBO
Ms
MBO
Ms
MBO
Ms
Man
ufact
urin
g E
ngi
neer
Input
Input
Wor
king
with
MBO
M
Appendix 1. Possible contribution of Manufacturing Engineers on different stages of change process
