W H I T E P A P E R

z u k e n . c o m

R e c l a i m i n g e n g i n e e r i n g p r o d u c t i v i t y

5 easy steps to increasing engineering productivity

Z u k e n – T h e P a r t n e r f o r S u c c e s s

Z u k e n – T h e P a r t n e r f o r S u c c e s s

2

and electrical engineering continues to be a concern for us,” or that: “we need to integrate discipline-specific development processes”.

This apparent need for improvement raises the question about what approaches are available to ensure product success, and which of them are best suited to enable electronic and electrical engineers as drivers of innovation.

Companies have three main levers to increase product success:

• The product itself – how it is structured and built with regard to modularity and configurability.

• The product process – how companies work internally and with their suppliers and subcontractors.

• The organization – how specific product development methodology is implemented and anchored in the organizational structure of the enterprise.

These approaches are supported by related IT systems:

• CAD and EDM applications supporting the design of products and the reuse of product modules

• PDM and PLM systems to manage engineering processes and to coordinate and provide data to different engineering disciplines

• ERP or enterprise business systems to support related business processes.

Information technology plays a pivotal role for all three product success levers. However, the new capabilities provided by IT come at the expense of increased complexity. In this way the steadily growing complexity of products, variants, value chains and processes is further aggravated by the dimension of IT complexity brought about by different environments, user and systems interfaces.

In other words: today’s typical approach to managing product complexity is to increase IT complexity.

So far, we have assumed that the additional capabilities provided by the multitude of new IT systems far outweighs the additional workload imposed by the growing complexity of these IT solutions.

But before we go any further, let’s look in detail at the three main levers companies have for increasing product success, and the commonly used strategies for their optimization. We’ll consider organization first, followed by the product process and, finally, the product itself.

IntroductionWe have turned creators into managers, and engineers into administrators. And for good reason! We assumed it was wise to reallocate a small amount of an engineer’s time to administrative tasks, based on the premise that gains would be achieved elsewhere in the process through the benefits of data and process consistency. But it could well be that this was a false assumption.

This White Paper investigates what approaches exist for increasing engineering productivity, and identifies steps that can be taken to find a better balance between engineering management tasks and effective use of engineering development time.

Increasing development successA quick glance at the current situation in product development from an electrical and electronic engineering perspective shows three important indicators:

1. In both the automotive, and machinery and plant sectors, process complexity is growing at a rapid rate. Measured by the number of product variants in the machinery sector, complexity has grown by two-and-a-half times1 since 1997.

2. Product lifecycles continue to shrink: over the last decade, the average product lifecycle shrank by around one quarter².

3. At the same time the share of electronic and electrical engineering in product innovation is rapidly increasing: Measured by the number of patent applications, the sector of electrical machinery and equipment grew by almost 90%. In comparison, the machinery and drive technology sector grew by only 23%³.

While the share of electronic and electrical components (E/E) in today’s products is steadily growing, the degree of integration of these disciplines into the overall product development process (PDP) remains at rather a low level. Although the shift of innovation towards E/E has already taken place on a large scale, the product development process itself continues to be characterized by the methodologies of mechanical engineering.

This is highlighted by a survey⁴ of companies using EDA solutions from a range of providers, including Zuken.

More than half of those questioned commented that: “the missing integration of mechanical

1 Roland Berger: Mastering Product Complexity, 2012.

2 See previous footnote.

3 VDMA Indicators for Research and Innovation in Engineering, March 2016.

4 Survey of companies using EDA solutions from Zuken and other providers, Germany, 2015.

“...the missing integration of mechanical and electrical engineering continues to be a concern for us⁴.

z u k e n . c o m3

Process

If we turn our attention to the operational procedures of product development, the focus naturally goes to the IT systems that are deployed to support engineering processes. In new product development these are typically PDM and PLM systems. It appears that these systems seem to be viewed with increasing scepticism among senior management, as their benefits do not always meet expectations⁶ and, consequently, the relationship between cost and achievable benefits can be unfavourable⁷. As a consequence, the majority of decision-makers are negative about investment in PLM technologies⁸.

Product

Consequently, the key to sustainable success appears to be the product rather than the organization or the process. Incidentally, this corresponds with the self-perception of the European machinery and plant industry: The majority of German machine builders are focused on innovation in the product (62%) rather than on innovation in the process (36%)⁹.

It appears then that engineering productivity provides the most promising approach to securing product success.

Considering the high degree of attention that organization and process have enjoyed with the rise of PLM, it may be concluded that the net available time for engineering activities has been continuously reduced.

Re

cla

imin

g e

ng

ine

er

ing

pr

od

uc

tiv

ity

Three product success levers

Organization

The two primary levers with a direct influence on product success are:

• Larger engineering teams

• Outsourcing engineering tasks to remote subcontractors.

However, practical experience has shown that these apparently obvious approaches frequently produce negative effects on engineering productivity⁵:

• The average engineer’s productivity will decrease with the growth of an engineering team, because internal coordination efforts grow drastically with the number of stakeholders.

• For similar reasons, teams spread across different locations can be up to 20% less productive than teams working in the same location.

We may therefore conclude that increasing the size of engineering teams and adding geographically distributed locations are no guarantee for increasing engineering productivity. Following on from this, it’s clear that organizational measures seem to have only limited potential to enhance engineering success.

⁵ McKinsey on Semiconductors – By the numbers: R&D Productivity in the semiconductor industry (2014).

⁶ “Companies require, no, demand quicker and more substantial ROI” – Source: CIMdata: State of PLM – Conference Proceedings 2014, 2015.

⁷ “Huge effort and expense to get PLM core capabilities up and operating”. Source: CIMdata.

⁸ PLM decision makers were asked by industry analyst CIMdata about the views of their senior management towards PLM. 61% of all decision-makers stated that PLM has not fulfilled expectations.

⁹ VDMA Indicators for Research and Innovation in Engineering, March 2016.

PLM is commonly accepted as an approach to controlling product complexity

“ Today’s typical approach to managing product complexity is to increase IT complexity.

New capabilities through IT

New IT complexity

ECAD & EDM

Product

Make complexity manageable

PDM & PLM

Process

Secure data & processes

PLM & ERP

Organization

Optimize productivity & costs

?

Z u k e n – T h e P a r t n e r f o r S u c c e s s

4

the expense of some degree of engineering productivity is also true in the other direction!

In other words: if we succeeded in reducing the amount of time spent on supporting and time-sink activities by only 5% – from an estimated 55% to 50% – the daily available time for pure engineering tasks would increase from 1 ¾ hours to 2 hours – which would equate to an increase of more than 20%.

An increase in engineering productivity in the region of 20% through the reduction of supporting tasks would definitely appeal to all companies focusing on product innovation!

Summing up: to achieve a substantial increase in productive time, engineers need to curb time sinks by a seemingly achievable 5%.

Eliminating time-sinksProcess support and data management comprise both indispensable supporting efforts such as project and change management, but also time-sinks such as redundant work in the form of data re-entry or waiting time for system responses.

Many of these time-sinks are caused by a multitude of different IT-systems and interfaces, poor response times, as well as inconsistent or ambiguous data.

Focusing on these types of areas should provide sufficient leverage to achieving a reduction of time-sinks by 5%.

The promise that an improvement in the area of process provided better results than improvements in the area of individual productivity was apparently the justification for the transfer of a growing load of process-related tasks to engineers at the expense of their engineering time budget.

According to several surveys, an engineer today spends more than half of their time on activities related to retrieving and providing information. The rest appears to be divided equally among engineering and testing activities. The net engineering time of an average 8-hour work day is therefore somewhere in the region of 1 ¾ hours; just under one quarter of the daily work time10: The engineer seems to have been turned from a creator into an administrator!

In the area of information management and retrieval we can find a whole range of necessary, but non-development efforts – from supporting activities, such as project and change management, down to important but non-productive activities such as duplication, data re-entry, or waiting times for system responses – time-sink activities to be avoided.

Supporting activities and even more so, time-sink activities, cost a high price that shows apparently insufficient return in terms of increased efficiency.

Consequently, we need to find ways to optimize supporting efforts and to minimize time-sink activities.

What is remarkable is that the presumed approach of more process productivity at

Engineers are turning into administrators because supporting and time-sink activities demand a growing amount of time.

How does a product developer spend their time, on average?

Development and testing*:

1:45h4:25h

3:35h

Less than one-quarter on development.

Engineering development*:Retrieving

and providing information*:

22%

45%

55%

10 A Time Study of Scientists & Engineers in the Air Vehicles Directorate, USAF 2010 (numbers rounded up)

“ Engineering productivity provides the most promising approach to securing product success.

z u k e n . c o m5

Federated provision of data management reduces time-sinks.

Re

cla

imin

g e

ng

ine

er

ing

pr

od

uc

tiv

ity

Many interfaces, large integration gapsWith the introduction of CAD systems in the late 1970s product development in mechanical, electronic and electrical engineering experienced an unprecedented boost of productivity. But along with it came incompatible data, unmanageable versions and releases, and, in spite of all technology support, a relatively small degree of data re-use, all contributing to an alarming state of entropy.

As a consequence, inconsistent data and insufficient process support threatened to neutralize the gains of what amounted to a substantial investment. The solution appeared to be at hand by introducing systems that would manage both engineering data as well as engineering processes, such as change management, within one consistent environment.

The approach of managing not only the overall process, but also all related data in a centralized environment brought about IT installations that in spite of substantial integration efforts do not provide the necessary depth of integration. In particular, this is the case in the disciplines of electronic and electrical engineering, as neither the related engineering methodologies nor the required data models are supported. This is because electronic and electrical data models require a much great depth of detail than mechanical engineering to ensure unambiguousness.

As a matter of fact, the capabilities for managing electronic and electrical component libraries is not provided by any of the current PLM market leaders’ environments.

An alternative approachThere is no doubt that an interdisciplinary engineering process requires an interdisciplinary system to manage and control processes across the domains of mechanical, electronic, electrical, fluid and software engineering.

There is however no compelling reason why such a system should also manage all engineering data from all disciplines in a centralized repository.

A pragmatic alternative would be the following hybrid approach:

1. Centralized control of the inter-disciplinary process

2. Federated data management within the authoring environments

This approach promises to provide a twofold advantage: on one hand, the number of required interfaces will be reduced (and with it the effort for implementation and maintenance), and on the other hand the number of user interfaces (and with it, time-sink effort due to redundant data entry) will be substantially reduced.

These monolithic systems that purport to be the “single source of truth” not only take up engineers’ valuable time, but also their growing number of additional applications, interfaces and user interfaces add to the burden.

For the user this means that they frequently need to have up to four different applications running in parallel on their desktop. And every single one comes with its own logic and user interface.

For any head of IT the sheer number of different applications represents a considerable maintenance and support effort. In addition, since hardly any application today is operated in isolation, a corresponding number of interfaces has to be put in place and maintained.

A little earlier, we formulated the following objective: if it were only possible to spend 5% less on support and blind effort, it would amount to a substantial increase in engineering productivity.

Applied to a complex IT landscape, even a minor reduction in the number of different applications would bring us a good deal closer to this objective.

“ …reduce time spent on support and time-sink activities by 5% and daily available time for engineering tasks increases by more than 20%.

Z u k e n – T h e P a r t n e r f o r S u c c e s s

6

For that reason, we at Zuken believe the following approach to be highly promising:

• Interdisciplinary processes should be covered by interdisciplinary systems such as ERP or PLM, in which important revisions or milestones should be documented as snapshots.

• Transactional data such as engineering data that is subject to frequent change and requires detailed insight into the respective data model ought to be kept within their specific disciplines. In total, this would amount to a federated data model.

With this approach, integration efforts with regards to PLM and ERP would be reduced, whereas the degree of integration within the disciplines would be as deep as required.

Consequently, unambiguousness and traceability of data will increase drastically, making local workarounds redundant. As a result, redundant work and waiting times for system responses will further diminish.

While it may be relatively easy and plausible to postulate a similar claim, the question arises, how vendors should support it with their software solutions.

NETWORK.

LEARN.

INNOVATE.

Five IT requirements for engineering productivity

A user-friendly approachAs a matter of principle, every enterprise can implement a similar approach with a limited number of steps:

1. Provide data management capabilities as part of ECAD authoring environments

CAD and domain data management (DDM) will form part of the user interface of the eCAD system with interfaces to PDM running in the background. Data will be managed locally and user tasks that are triggered by an interdisciplinary processes in the PLM environment will appear directly in the eCAD system.

If we managed to eliminate just one single application, we would already have achieved a big step forward. Fewer different user interfaces mean: productivity goes up as response times and redundant tasks are significantly reduced.

2. Manage electrical and electronic data models in their native format

Many companies use existing projects as a template from which they create new designs and variants. Frequently this is done by simply copying and modifying existing projects. However, in this way, there is no linkage between source and copy, so that changes on a components level cannot be consolidated across different variants.

Especially if changes are made in related projects it is important to know in what designs the related components were deployed.

This question can only be answered if a “where-used” analysis on a component level is supported. A prerequisite for such an analysis is a data management environment that is capable of handling information on a component level, which can be provided only by a component level domain data management system, such as Zuken’s DS-2.

In addition to a reduced integration overhead, managing electrical and electronic data in their native format enables detailed where-used analyses on a component level as well, as the management of variants and options, which would require exceptional integration efforts if it was to be implemented in a (mechanically-oriented) PDM-environment.

“ Reverting from a process-centric perspective to the needs of the engineer opens up the chance of addressing growing product and process complexity with engineering productivity, rather than adding additional IT complexity.

z u k e n . c o m7

Re

cla

imin

g e

ng

ine

er

ing

pr

od

uc

tiv

ity

Copyright © Zuken GmbH. 160914

3. Manage material and component libraries within the authoring system

Just like engineering projects, electronic and electrical component libraries are subject to a process in which they are created, maintained, reviewed, released and rolled out to the different engineering locations.

A centralized approach to library management helps to control and reduce the number of individual entries and reduces maintenance efforts, while providing the basis for efficient design re-use. In addition, a library that is consolidated across different operations and locations provides a basis for more favourable buying conditions through economies of scale.

And finally, a centralized approach to managing libraries ensures data consistency across different engineering locations, while data exchange and design-reuse is better supported and manufacturing resources can be flexibly allocated.

4. Integrate and synchronize processes with PLM and ERP but manage data in decentralized repositories

It is the promise of centralized data management systems to provide a unique interface for all applications. It is, in fact, an appealing idea to have to integrate applications into one single environment.

The reality of today’s IT landscapes continues to be fragmented, and in all probability this will not change in the future – not only for technical reasons, but also as a result of mergers and acquisitions of companies with their own legacy environments.

The integration of systems and applications remains a running target, in which the objective of a single source of truth generates a high amount of effort, without providing the required depth of integration.

Federated data management is a valid alternative, because the integration of processes is more manageable than the integration of transactional engineering data. It is, however, a requirement that eCAD systems in turn provide workflow and data management capabilities.

5. Enhance collaboration within the discipline

In a typical distributed process shared development, work is characterized by check-in and check-out routines: While an engineer is working on a project, it will be locked for all others. Meanwhile eCAD-Systems such as Zuken’s E³.series enable more agile ways of working together, as they support several engineers working in parallel on the same project, with all changes visible for the whole team in real time. It is, however, a prerequisite that the eCAD system provides multi-user capabilities and related role and rights models.

SummaryReverting from a process-centric perspective to the needs of the engineer opens up the chance of addressing growing product and process complexity with engineering productivity, rather than adding additional IT complexity.

This approach, however, requires bringing functionality that today is scattered around different systems, into the engineer’s environment – i.e. the CAD system. This is an approach that offers agility and distributed repositories versus the monolithic approach of centralized systems.

About the Author: Thomas Gessner is Business Development Manager for Zuken’s Data Management Solutions. He joined the company in 2013 to manage the market introduction of E3.EDM. Gessner has held similar positions at PTC, BroadVision, Adobe Systems and Interleaf, and has been selling and marketing engineering data management solutions since the mid-1980s.