Executive Summary

This chapter deals with the implicit expectations and requirements with respect to Virtual Product Creation solutions by the engineering community, their users and the underlying core foundational principles of engineering. In many realization projects of new PLM functionalities, modified or newly introduced virtual product creation working solutions and associated responsibilities of individual roles and job functions those hidden demands are oftentimes not known, understood and/or not taken seriously into account. This oftentimes leads to unwanted delays, limited progress and a high number of substantial problems in operational digital engineering business.

Quick Reader Orientation and Motivation

The intention of this chapter is:

  • to describe and illustrate principles and expectations of the engineering community with respect to virtual product creation solutions

  • to explain when and why such explicit and implicit expectations can create conflict potentials with typical PLM and virtual product creation (VPC) development, deployment and implementation approaches

  • to provide advice and assistance how to avoid such conflicts

  • to explain strategic and practical advice for modifying engineering principles and behaviors which are in better alignment to Virtual Product Creation innovations.

A rich mix of creative, routine, responsible, collaborative and self-reflecting elements, both with analog and digital engagement styles, characterizes engineering work patterns. As a reward for engineers, a thing, a sketch, a design, a calculation, a model, a mock-up, a test, a prototype etc., get accomplished with the goal to contribute to the next or modified product, production line, technical system for costumers or factories. Engineering is thrilled and committed and wants to get measured by this ultimate rewarding scale.

With this engineering DNA in mind, many product and manufacturing engineers raise the expectations as creators of the technical universe to be best suited to also define, develop and deploy the corresponding engineering tool-sets, methods and test capabilities. This ambition, however, is nowadays difficult to achieve due to specific needs in digital competence that are necessary to build digital engineering tool-sets and applications. Consequently, irritations, implicit expectations and frustrations arise if other experts are assigned and contracted to define, develop and deliver new digital working solutions for engineering communities. In many cases, it is a mix of pride, personal choices and indeed the best engineering knowledge that create mixed feelings of the engineering community about the appropriateness and best fit of digital solutions sets as part of Virtual Product Creation.

In principle, it is beneficial to know which expectations of the Engineering Community exist and what they are driven by. Only then, it will be possible to counteract it appropriately in order to provide IT based virtual product creation methods and tools and to suggest the right data and model mix for it.

The typical innovation situation

Product and Manufacturing Engineering has changed significantly from the mid of the 90ties of last century onwards: rather than typical line engineering progression with routine work contributions to product, machine or product system developments, more and more a stage gate-oriented project engineering approach is meanwhile the norm in day-to-day engineering progression. Consequently, a typical engineer has barely the possibility to use “special time” in order to specify, develop or even experiment with new and better engineering tool sets. In addition, in most of the companies a rather awkward and lengthy process of setting up innovation projects has been established. Generic product, tools or process owners undergo a rigorous review process, typically starting from June up to November of the previous year. The goal is to receive an official approval in January or February of the following year to conduct an 8–10 months prove of concept (POC) type of engineering innovation project with a tangible task to deliver a solid return of investment evidence within one year a maximum of 2 years. Special teams are assigned inside the companies, which are usually not in operational engineering work responsibility. They are supposed to interact closely with outside research institutes, vendors or other IT service providers and with internal key users from the engineering operational teams in order to investigate, demonstrate, explain and conclude with respect to potential future digital engineering solutions.

The operational engineering teams remain in their daily hassle and cannot devote any substance time into future engineering workplace solutions. Occasionally, they are invited to awareness sessions of innovation project outcomes or to hype demonstrations like “agile accelerators”, “co-working boot camps”, “Scrum for all, let’s do it” and similar type of generic solutions frameworks. In only very few cases those operational engineers are rotated out of their daily routine in order to work with substance and foundational reasoning on the new way of digitally assisted and enabled engineering of the future. In terms of their own challenges like.

  • sharply increased product and process complexity,

  • overwhelming day-in-and-out risk mitigation actions as part of increasing intensities of reviews as part of gateway reviews, boot camp crisis engagements or simply direct reporting meetings

  • growing technical uncertainties about fast growing system-of-system interactions of technical systems and growing legislative regulations as well as

  • missing data and information infrastructures and

  • manageable digital model and data working methods to cope with all of the above challenges, the gap even widens with accelerating speed.

Engineers who have served longer than 6–7 years in such an environment remain sceptic about improvements and are even cautious to become members of new engineering improvement initiatives. They rather prefer to stay passive and observe the “innovation arena” from the sideline or from the spectator stand with mixed feeling in terms of behaving silent or in “protesting behind the scenes”. The needed pro-active engagement in order to represent and drive the voice for improved digital engineering solutions has oftentimes no longer a healthy culture in modern enterprises!

This is a severe problem, since creative ideas and technical competence on the one side, but also the hidden demands about implicit expectations of the engineering community no longer or with limited visibility and clarify come to surface for such critical digital transformations in industry.

The author of this book, therefore, wants to present the hidden demands, as he knows them from his own fourteen years of industrial experience as well as from recent and still active research and development projects and consulting engagements with more than 50 companies around the globe.

17.1 Hidden Engineering Demand #1: Intra Company Competence to Drive the Digital Future

Innovation and steering committees are established in industry to reflect on top down type of changes to the existing engineering operating system. By far, it is easier to invite expert groups from the outside to provide innovation impulses and re-engineering ideas rather than to deal with a bottom-up type of approach within the internal engineering community. This, however, is in clear conflict with engineering leaders and experts inside the companies as it is described in “hidden demand #1” in Table 17.1.

Table 17.1 Intra-company competence should be driving the digital future
Full size table

The hidden demand rationale

The specific knowledge of both, the technical expertise within a specific industry branch and its products, services and manufacturing circumstances, and the internal engineering operation principles is definitely a core asset that needs comprehensive consideration for defining future Virtual Product solutions. Engineers, therefore, expect that this basic rule can be seriously considered in the reflection of the as-is-status, the identified areas of improvement and the basic logic for future digital solutions.

The hidden demand conflict potentials

Following this expectation bears a couple of conflicts, both internal the company and with regard to potential partners and experts from outside the company. To find the right approach to balance internal expertise on best professional practices for engineering work with “fresh-eye” or “new innovation know-how” from the outside, the right technical leadership needs to be applied. Otherwise, the risk will be too high that digital opportunities from research and technology offering companies do not find its way into the intra company “new opportunity hitlist of business improvement candidates”. Other risk often kicks-in, if different camps of technical conviction within a company block themselves mutually: neutral advice and new digital solutions opportunities from the outside are not recognized or they are even denied due to this internal fight of the different schools of thoughts.

The approach to mitigate the hidden demand conflicts

The competence of independent technical leadership within the company can help to mitigate such a risk. The set-up of a serious technical career paths in companies, however, is oftentimes difficult and do not resonate with traditional management leadership set-ups. The alternative or additional element of “innovation funnel processes” can help to integrate members of different leadership levels and departments within the future capabilities track within enterprises. Such process can help to invite outside knowledge into the early phases of new digital program definitions, POC (prove of concept) work and within resulting request for proposal rounds. A third approach is to free-up internal SMEs (Subject Matter Experts) part time or as part of short sabbaticals in order to give them the chance to extend and broaden their technical knowledge and technology immersion with partners at Universities, research institutes and technology think tanks.

The resulting need to change engineering principles

The engineering principle of “determine, model, build, test, measure and modify” should be principally remain intact but needs to be expanded and enriched by the following elements of equal relevance:

  • Observe and reflect unknown solutions, regardless whether they are proposed, advised or even advocated by outsiders or insiders

  • Conduct active reasoning about what could be changed and how, rather than concentrating on how to continue best with the existing solution principle by just adding another new or cool technology

  • Pause and interrupt before making a half-baked decision just to follow a stringent time plan driven by an internal—and potentially artificial—innovation project circumstance situation.

17.2 Hidden Engineering Demand #2: Robust and Professional IT Application Integration

Engineers are meanwhile highly frustrated and no longer willing to accept “half-baked” digital applications streams, which make it necessary to enter multiple times data and information inputs manually. Due to oftentimes-overwhelming time commitments to satisfy application and database driven data inputs, engineers are increasingly disappointed about the lack of consistent and single source of truth information authoring within the company IT enterprise architecture.

The hidden demand rationale

Obviously, the increasing levels of Virtual Product Creation execution have been resulting in a high number of different IT applications with individual specific usage purposes as well as diverse sets of data and model generation scenarios. This is the reason for the hidden engineering demand #2 (see Table 17.2).

Table 17.2 Robust and professional IT application integration
Full size table

Hidden engineering demand #2

Consequently, many Engineers and other digital workforce actors feel themselves urged and forced to equalize the isolated data model regime of individual digital applications via manual re-entries in order to guarantee consistent digital engineering workflows. Since traditionally IT departments have limited know how only about underlying engineering processes and task execution, they depend on key users and their determination of use cases to provide at least a minimum level of data flow consistency in between IT applications series.

The following examples show the diverse set of hidden expectations concerning this second type of hidden engineering demand:

  • Users expect a single log-on access to all engineering applications and engineers expect the offering of digital tools with respect to engineering tasks rather than scattered around divers’ sets of IT systems.

  • Engineers expect high service operations times of all digital applications, no matter whether these are locally hosted, network operated or even mainframe based and which types of back-up regimes are entertained.

  • Nobody in a producing industrial company likes jobs of back-office workers such as physically re-entering the same data from one IT application into another one. Such type of work simply represents waste, creates error potentials and provides no valuable work ethics or even professional success. Therefore, the deeper question why such manual (re-)entries remain a “hidden” task within the digital engineering workspace has to be transparently clarified: e.g. IT integrations might be deemed too expensive, might not be possible to be realized in time or simply might not be wanted due to non-strategic IT application integration situations! For such sub-optimal situations, however, RPA (Robotic Process Automation) or DPA (Digital Process Automation) applications are available, which favor Bots (SW-robotics) to carry out such routine type of mapping re-entries across IT applications based on reliable rules according to human knowledge. If this is also not possible then the productivity of highly paid engineers might only be temporarily acceptable since midterm perspectives will cause substantial issues and conflicts.

The hidden demand conflict potentials

Still today, engineers oftentimes remain passive and negative if their digital work environment does not reflect core essential work labor requirements such as smooth data transition, workflow and import/export to other applications. Acting as “human disk jockeys of multiple IT applications” in order to perform official digital engineering workflows constitutes not only troublesome and error prone waste of engineering efficiency but also invokes the feeling of not being valued by the company. Unfortunately, short-term accepted workarounds –as such deficiencies are called in official tech language– usually remain for many months in industrial operations if not years as part of half-finished and never completed virtual product creation architecture solutions. In most of the cases, this deficiency is caused by limited IT project funding and by no end-to-end process thinking in IT vendor solution selection and contracting. Consequently, such situation will lead eventually to work refusal and high frustration of the engineering workforce, limited and risky work results as well as to quality problems of the final products in the market and in operational use.

The approach to mitigate the hidden demand conflicts

It all depends on the integrity and close cooperation between the engineering workforce (supposed to be represented by department leaders and chief engineers), the internal IT organizations and potential digital project leaders. The company culture has to provide an appropriate spirit and work forum for such kind of sensible future work simulation prove outs. If this is not established proactively within the development, deployment and implementation phases of digital transformation projects, there is little hope for disappointments and deep clashes afterwards.

In addition, IT integration does not end with API (Application Programming Interface) offering and opportunities. Rather the correct anticipation of the owner and the usage pattern of data and models are finally decisive to conclude explicit needs and number of formal and informal transactions and information exchange within digital engineering workflows. Therefore, it must be clarified early on, who in the engineering community really represents this decisive part in the solution development. The engineering community in most of the cases remains shy in expressing clear demands due to unclarities about ther own digital knowledge as well as due to fears to request the wrong or non-sufficient data gives and gets. Nevertheless, the engineering community needs to be pushed constantly by digital experts to open up, to engage on digital elements early on and to find agreements and compromises within their own community to represent their clear needs and service requirements consistently with one voice!

The resulting need to change engineering principles

For too long, the engineering community within enterprises remained passive and not interested in taking care about their own future digital work environment. Engineers tend to love their product related work success too much in order to stay open and determined about the changing circumstances of their own digital workspace and of the overall digital enterprise. Unfortunately, in many companies, engineers are meanwhile already used to being represented by Engineering IT groups who are established within Research, Development and Manufacturing divisions to serve as the digital face-off for Engineering due to their deeper IT skill sets. However, this remains critical over time since risks will increase substantially in terms of being too far away from new product technology and collaboration perspectives of the engineering community itself.

By accepting the important role of a driving stakeholder for new digital solutions, the engineering community needs to accept ownership of responsibility for future digital engineering solutions as well. By being part of the definition and development group of such new Virtual Product Creation architectures and solutions, engineers have to associate themselves as driving force behind the new digital solution approach rather than criticizing such commonly developed solutions in hind side as critical customers only! This mindset is unfortunately not yet common in industry and limits digital transformation progress substantially. Management has to become much more determined about it and needs to prepare the engineering community for such new role (compare Chap. 18).

17.3 Hidden Engineering Demand #3: Digital Simplicity and Joy

Dealing with digital tasks usually demands a split in mental working mode. On the one hand, it is necessary to follow a methodological game plan within the individual’s brain in order to understand structure and determine the engineering task execution sequence and to decide profoundly at each decision point of the engineering assignment. On the other hand, much brain capacity is simply needed to follow the right digital methods steps within the broad spectrum of functionality offered within the individual digital engineering IT applications. Therefore, engineers have started to expect better-designed and implemented digital applications, which also suits the desire for application simplicity and joy of interaction (see Table 17.3).

Table 17.3 Digital simplicity and joy
Full size table

The hidden demand rationale

IT tools and supported digital applications are meanwhile accepted mainstream working elements of modern engineering work. Consequently, such digital working environments should best possible support all engineers and other involved working personnel in their personal working ethics and in their highest possible working effectiveness and efficiency. Digital tool interactions, therefore, are meanwhile treated to an increasing degree as potential positive contributions to the daily work satisfaction.

To drive it such way, however, IT tool providers and internal IT organizations need to work seriously on improved task execution based on simple instructions in order to guarantee smooth execution steps as well as to provide a professional level of interaction joy with the application interfaces themselves. Engineers and other users will appreciate such ease and joy in working with the tools, which will result in less cumbersome help desk calls and time delays in digital engineering workflows. For controllers, however, this rationale might not be good enough, since they do expect rather hart facts in (digital) operational cost. Consequently, it will be necessary in many instances to conduct a digital value sequence assessment. This, however, remains a rather unknown digital transformation activity in today’s company digital realities.

Hidden engineering demand #3

The hidden demand conflict potentials

Traditional heavy loaded and function rich interfaces of engineering IT applications without any application of scientific results on information fairness and effectiveness for individual users contribute substantially to error prone work execution and to rather frustrating moments of application usage. Engineers were heavily trained to cope with such information and function offering for a long time since they could derive a certain level of expert knowledge from being able to master such user-unfriendly digital interfaces. Starting from generation Y and more heavily represented in generations Z and Alpha, engineers no longer accept such a heavily disciplined approach of information offering and usage and do demand new type of working joy and associated support assistance levels by their employers and hence also by the company IT applications.

The approach to mitigate the hidden demand conflicts

Companies and IT vendors need to put much more focus on the following aspects:

  • Simple navigation of software functionality—offering of engineering task oriented functionality offering and down-selects (engineers do know and expect similar capabilities as they are also offered by mainstream digital solutions such as smart TV or smartphones)

  • Different degrees of professional usability of IT application functionality—times are over to simply offer “the one serves all” functionality to all

  • Work with analogies to mainstream office and social media applications, e.g. excel type of interfaces for baby boomers and Generation X, Facebook type of interfaces for Generation X and Y, Tik Tok type video instruction interfaces for Generation Z etc.

  • Provide gaming type of rewards by counting of already successfully mastered digital task interactions and by providing extra gadget support opportunities ….

This might sound like a lot of extra IT effort, but it is not really. Why is that? Meanwhile IT applications can be configured much more easily for specific roles and tasks and do not necessarily need re-programming but structures and a professional approach within the engineering departments, themselves. In addition, it is necessary to employ skilled digital engineers and human–machine interacting experts to work closely with the engineering workforce in the engineering departments. The new generation of Engineering Managers seriously need to establish such a competence as core element of digital engineering and of an excellent Virtual Product Creation.

The resulting need to change engineering principles

A lot of engineering knowledge needs to be re-written to make it digitally consumable and executable. For instance, it is still not common or not even considered as part of engineering studies at universities today that machine element type of engineering expertise is provided as part of digital learning infrastructures and basic modeling and simulation environments. Such bottom-up digital learning and task resp. project execution level foundation, however, is needed in order to take such critical basic digital-technical know-how task away from technically limited IT solution vendors. It is time to bring it back to where it belongs: to digital enabled engineers, technical experts, professors and managers who want and need to install such new digital enabled technology competence in engineering and business operations. This would also help tremendously to counteract sympthoms that many engineers still have today, fears or little interest in learning competence in Virtual Product Creation tools and their functionalities on top of all the other engineering knowledge that is needed to do the job.

17.4 Hidden Engineering Demand #4: Personal Assistance to Avoid Failure Intrinsic Work

Engineers received traditionally direct working instructions and support by the superiors. The experienced boss or colleague was able to provide the right level of advice for the next level of engineering task execution. With the excessive use of digital working solutions, this personal advice has increasingly diminished and individual engineers need to use multiple, oftentimes non-aligned hints for engineering work assignments, the right level of digital execution expertise and the organizationally correct process deliveries.

Hence, there exist a gap of personal assistance from the point of view of best digital data flow, appropriate digital engineering workflow and best suited digital modeling and simulation preparation for individual engineering tasks (see Table 17.4).

Table 17.4 Personal assistance to avoid failure intrinsic work
Full size table

The hidden demand rationale

Empowerment and down-delegation from Project and Department Leaders to Engineers and project members do transfer substantial amount of responsibilities and even accountabilities to the engineering work force. Timely accelerated task execution and oftentimes cross-enterprise and cross-regional if not global engineering operations lay another level of stress onto the daily engineering roles, responsibility and duties. At the same time, fast changing new and all-encompassing digital capabilities as part of PLM and Virtual Product Creation environment set-ups push the engineering workforce even further into challenges of failure intrinsic work patterns.

Personal, case-based assistance as know from the analog times of engineering can no longer be provided, hence digital assistance types are required and need to be compiled and offered. In the first twenty years of this century, this type of missing personal assistance created invisible inhibitors for many companies to find acceptance in their own workforce to get to the next possible levels of Virtual Product Creation.

Hidden engineering demand #4

The hidden demand conflict potentials

Engineers often doubt which type of digital progression fits to which level best to the team-based advancing in engineering clarification, work delivery as well product validation, verification and release. Sometimes there exist high demands from the management into the delivery capabilities of the engineering workforce with respect to time, cost and quality, independently of the degree of realized digital engineering excellence, which is oftentimes closely linked to newly set-up Virtual Product Creation processes and solutions.

However, what can no longer be provided in many companies is the appropriate level of personal assistance in order to apply the digital solution element to the type of engineering collaboration, model execution and validation or virtual product verification correctly or at least most meaningfully. Therefore, there exist either very different ideas of how to cope best with such digital situations as part of a team approach or of how to advice each member of such a virtual team to best leverage digital solutions and methods at hand for a given task or collaboration circumstance. Consequences resulting from this are team confusion, unnecessary delays or even development errors and/or super cautious workforce members who no longer carry out proactively their digital engineering tasks but wait reactively for a minimum set of coordination clarification by some “authorities”. Such lack of appropriate personal digital assistance for complex task execution can even lead to company partial stand stills in its engineering progression in development phases where otherwise smooth digital partner interaction would guarantee successful virtual series deliveries and gateways.

Please note the following specific examples for personalized digital assistance to mitigate conflicts of typical failure modes:

  • Simple, robust and high success driven data and information search across data bases and model libraries

  • Specific views on digital tool functionalities to enable and improve engineering task execution in context and according to in-site circumstances

  • Minimization of tedious data management and structuring (incl. data and model configurations) work through personal advisory and butler services (e.g. via bot support); as an example, PLM system should not always ask engineers for technical attributes that are always the same. Why does the PLM system still not recognize that many engineers in the same department conducts authoring of components with the same type/material/supplier origin?

  • Explanation and “semantically” conversion assistance for model and data interpretations from other organizational functions and disciplines ….

The approach to mitigate the hidden demand conflicts

First, such desire for personalized assistance needs a climate of open and transparent digital work execution within the organizational environment, otherwise there will be no room for appreciation of personal actor needs to improve personal and team work advancement! Engineers need to be enabled to seed information, data and model elements for their personal work environment and pattern environment easily. Only if, such capabilities are entertained in companies there will be a chance for collecting a rich set of “supporting engineering intelligence” in digital engineering execution. To which extend, high level engineering rules as introduced in the late 90ties and the early 2000th are still sufficient to provide enough adequate support for today’s highly digitally dispersed work patterns needs to be discussed and investigated in specific digital focus groups within the companies. In any case, the competence of personal digital support needs to be based on a companywide new engineering initiative that gets the right support by IT departments, IT vendors, and digital solution providers. However, such approach is still new for most of the companies and bears a clear sense of ownership within the engineering departments themselves!

The resulting need to change engineering principles

Engineers, themselves need to open up and need to pro-actively invest time and efforts in training its personal digital assistance support tools, bots and avatars as they might have learned from their private live digital assistance gadgets. Management and engineering teams should start building up personalized digital assistance with implicit top-down knowledge on lessons learned as well as different engineering development cases and systems. Digital experts and IT departments should leverage bottom-up data & information syntax rules as well as data analytics patterns.

The right level and type of personal assistance should be started for specific job roles, most cumbersome digital task executions, and most critical digital engineering workflows in order to gain trust and highest return on invest for such new digital capabilities. The digital assistance realization itself should also encompass the findings of the hidden engineering demand #3 “digital simplicity and joy”.

17.5 Hidden Engineering Demand #5: Self-modifiable Personal Digital Working Environments

In history, engineers were used to having a high influence on their own work environment and could, therefore decide directly, which techniques, process steps, tools and methods they needed in order to develop, test and produce new products, build prototypes and complete technical systems for service operations. This situation has been deteriorating systematically for engineers during the age of Virtual Product Creation and as part of the increasing digital engineering. In most of the cases, they no longer have the knowledge and the expertise to decide which information technologies are sufficient for their own engineering tasks and how such digital work elements can be modified to make them a best fit to the anticipated digital modeling, analysis and collaboration working modes (see Table 17.5).

Table 17.5 Self-modifiable personal digital working environments
Full size table

In the beginning of digital computation, only a few advanced thinking and skilled engineers were able to develop new digital solutions by themselves since they needed a high degree of computational and programming skill set based on mathematical and physical laws and solutions. Today, engineers are highly depending on IT & digital solution providers, on IT organizations and software coders to provide to them digital computer solutions that allow for easy configuration of digital applications and data engineering solutions.

The hidden demand rationale

If somebody is responsible to deliver product and technical systems solutions, which have to fulfill many demanding requirements and system capabilities, such individual must have the legitimation and the professional duty to influence the way such deliverables are to be developed and to ensure that those can be validated and verified in specific ways.

It includes the conceptual proof, the overall design layout, detailed design and component solutions, overall system behaviors, system integrations and final test and sign-off. Engineers, therefore, expect to have a direct influence if not to be a decisive authority, on how such activities are carried out, regardless of whether this requires physical or virtual tools and/or testing facilities.

In order to align best to the overall Virtual Proudct Creation environment—an environment that needs to follow requirements from a broad range of stakeholders– engineers should have personal opportunities to accommodate their own digital working environment to carry out their own digital development duties (see above). This includes the choice of a best fitting personal digital tool and data/model environment.

Hidden engineering demand #5

The hidden demand conflict potentials

The more engineering users a company has to support with Virtual Product Creation capabilities, the more stringent the overall IT architecture needs to be. This oftentimes is the argument for “OOTB” (Out of the Box) or “COTS” (Commercially over the shelf) configurations for companies as they are made available by digital solution providers (or PLM vendors) in their offering of engineering applications to their customers. The decisive question, however, is, how flexible such IT architectures can be digitally configured: rather than customization that requires a certain degree of special software code just to make it usable for a costumer, the digital solution configuration allows for flexible bundling of various solution elements within a certain spectrum of independent tool capabilities and virtual desktop arrangements. Due to the sharply evolving digital transformation, it becomes increasingly indispensable in the future, however, to provide a wider range of personalization of digital engineering tools and data/model fidelity building, analytics and fidelities for the individual engineering user in and across specific industry branches.

Today, the following options are principally possible if they are agreed on at an early stage during vendor selection and Virtual Product Creation architecture definition:

  • Virtual desktop arrangements to provide tool icon down-selection, position and look & feel, window size and tiling, background color and desktop theme definitions

  • Configurations of information feeds, alert messages and routing options to receive notifications and inform other users

  • Priority listings of tasks and daily routines, etc.

In the future, a much stronger content rich personalization will become essential and needs to be designed and implemented with deeper modes of engineering data and model knowledge, modeling and simulation schematics as well as situation aware and process mining related intelligences. Please note the following three examples for this upcoming digital personalization service standard of the future:

  • Engineering semantics driven information analysis to screen and present available data sets of competitors, existing simulation data, physical test data and engineering change management related tasks

  • Model based engineering assistance configurations to establish trace links between model artefacts and other data sets based on historic knowledge and or preferred personal engineer’s rationale

  • Personalized bot services to help finalizing virtual series gateway deliveries according to team or process related configurations for BOM (Bill of Material), product structure and CAx model deliverables completeness, communication clarities and “difference picture” documentations.

The approach to mitigate the hidden demand conflicts

Obviously, companies need to start appreciating such personalization requests and demands by their existing and future engineering workforces. Engineers need to start proposing most useful and stringently desired customizable services with the opportunities to aggregate them to similar type of IT operations and data service algorithms. If an alignment becomes possible on such a level, it will be much simpler to arrange and prove out examples in order to assess the opportunities and limitations of existing and future virtual product creation architectures. Each personalized virtual desktop capability and service should pay for the overall effectiveness and efficiency of the individual engineers with respect to his/her own digital work profile. Measuring such effects will provide evidence of trust and will contribute to a self-inducing new digital work policy.

The resulting need to change engineering principles

Engineers and their management should investigate to which degree personalization of digital tools and data/model services delivers personal and/or team efficiencies and working robustness versus risks concerning divergence of no longer compatible engineering interactions and collaboration amongst team members. If the process re-engineering thinking of the 90ties of last century and the early 2000th is applied to the new world of fully digitalized working environments of the 2020th and beyond all engineering methods need an overhaul and a rather natural interpretation capability for each active engineer. Times are over, that engineering approaches can persist for many years or even decades. Constant reviews of team and personal duties and development skills will have to be reflected within personalized digital working environments. The better such new digital asset will be understood and appreciated amongst professionals, the earlier companies, agencies, management and engineers will be able to contribute successfully to the digitalization challenges of the future.

17.6 Hidden Engineering Demand #6: Quick and Continuous Improvement

All digital applications are dependent on a process, which transforms engineering principles, procedures or model/data assumptions into executable algorithms and software code in order to provide the digital processing of engineering value creation.

This process, however, is oftentimes flawed and not straightforward due to the necessary separation of duties between agreements on engineering approach, determinations of digital working modes, functional specification for digital task execution, reductions to specific uses cases as minimum set of software intelligence, design specifications for specific data models and software functions and various degrees of test cases. Such an approach widely differs from the traditional engineering approaches that are based on solid understandings of technical physical effects, physical behavior principles and a wide range of existing technical system solutions based on mechanical, pneumatic, hydraulic or electrical/electronic principles.

Engineers envy the quick implementation routines of software development and hence expect quite naturally that quick and continuous improvement for digital engineering tools are simply possible and should be realized wherever possible.

The hidden demand rationale

Engineers have learned the hard way during the last 30 years that the only development capability left in the new digital world is based on software based digital and analytical toolsets. Since engineers are in most of the cases not capable of building such digital capabilities, tools and toys themselves, they are usually fully dependent on others to provide, correct, improve and further develop such capabilities. This means in consequence, that Engineers meanwhile have become dependent on others in order to carry out pure basics and all advanced type of (digital) engineering.

After one or two decades of a rather devoted attitude towards such situation, the situation has changed towards a more demanding, professional attitude in comparison to the “ordinary” product and technical system world where clear and stringent business relations exist with high demands of product quality and delivery consequences. In natural denial to the very specific circumstances of software and digital application development and to the necessary Enterprise Architecture Integration of IT applications such as Virtual Product Creation solutions into company environments, engineers nowadays do insist on an increased service level with respect to quick and continuous improvements of digital solutions by the responsible development groups (see Table 17.6).

Table 17.6 Quick and continuous improvement
Full size table

Hidden engineering demand #6

The hidden demand conflict potentials

The first conflict potential exists during the customer acceptance testing in terms of new IT application rollouts and deployments. If key users of engineering teams find fundamental and annoying failures of the software or if the logic of the digital approach creates flaws in daily digital engineering or at least in single groups, the implementation might be stopped, delayed or implicitly no longer pursuit. The traditional battle within PLM projects, IT implantation activities and overall Virtual Product Creation business improvement undertakings foresees lengthy and tedious negotiations between companies and their tool providers with respect to bug fixing prioritization. In such cases, their own company or internal digital project teams force engineers to allow a certain degree of annoyance and workaround willingness in order to keep the high priority bug fixing opportunities within a limited size according to the money value that was reserved for such cases during the initial contract agreement. Engineers have no understanding for such opportunistic approach.

The second conflict arises during the actual use of the digital applications in the course of engineering operations. If many help desk calls, user feedback based on questionnaires and other complaints are not really taken seriously into considerations by company and project authorities, engineers start acting negatively and call a crisis. This, however, might cause bigger churn and stress within the entire engineering team and within the development projects where such flawed digital capabilities provide clear inhibitors to deliver quality development results.

The approach to mitigate the hidden demand conflicts

The dilemma usually starts already at the beginning, when the basics of a Virtual Product Creation architecture and solution are assembled. By that time, oftentimes-wrong high level or non-future oriented carry-over assumptions form the basis for the relevant use cases which are then treated as contractual baseline for software application customizations and new developments. Consequently, it becomes essential to involve a higher number of lead engineers and digital competent method engineers into that 2–3 months initial phase for such a digital transformation initiative. It is necessary to get them at least half-time, if not full-time involved, during such phases in order to provide consistency into the bottom line assumption of the digital architectures. Those assumptions serve as base for any next level development work.

After full or partial implementation of new digital capabilities, a group of digital competent and well-respected key engineers should act as conduit between user groups of engineers, IT organizations, project managers of the digital delivery project and/or to the real business owners of such digital capabilities (if they have been identified clearly enough with all duties beforehand!). It is their important responsibility to discuss short-term work-around opportunities and new improved solutions with IT application engineers. They also need to keep the pressure on IT organizations, company stakeholders and digital solutions providers to deliver quick short-term solutions and profound long-term digital solutions. Similarly, such key engineers need to organize, with the help of IT application engineers, the professional level of digital operations with work-around if during such unpleasant project times.

The resulting need to change engineering principles

Engineers need to understand that digitalization is not just a “temporary thing or journey” that will be soon over. On the contrary, it becomes critical for engineers to understand that digitalization remains a constant journey with different episodes and timely phases. Therefore, universities and companies need to invest into such digital skills and transformational developments much more heavily, both with respect to strategic long-term evolutions and to short-term initiatives. Engineers need to engage directly and with all engineering wisdom at various levels on a personal and/or team level such as:

  • Ideation of new digital principles for the future of the company and for the future of products and technical systems,

  • Engagement with digital solutions providers to understand the challenge of developing and delivering appropriate and execution robust IT applications,

  • Reflection of data and model consistencies and richness, which form the base for algorithmic support levels and needs of digital engineering applications,

  • Encouragement to request persistently the right level of professional support for bug fixing, IT application improvements and new ways of digital engineering rather than just following old levels of (traditional) engineering practices.

Efforts will pay back if mechanisms are established to constantly and quickly review, judge, improve, implement and review all IT applications, especially in their interplay to each other!

17.7 Hidden Engineering Demand #7: Flexible Digital Test Beds in Production IT Environments

Virtual Product Creation (VPC) no longer constitutes just a collection of individual tools to create, change and save files and documents in order to describe models for representation, assembly, simulation, control and storage of engineering content and machine & product behaviors. It has been further developed to a digital engineering competence in order to exchange, release, collaborate with, improve and optimize ideas, new designs, technical solutions and full products/systems amongst co-located or dispersed team members and companies (compare Chap. 4, “Virtual Product Creation—what is it?”, and Chap. 6 “The set-up of Virtual Product Creation in Industry”). Thus, Virtual Product Creation is like an active eco-system consisting of many digital technologies, extensive data and model management solutions as well as a high range of different engineering processes, methods and collaboration procedures. Any change in such a VPC eco-system has to be carefully planned, carefully reviewed, simulated, actually tested, finally assessed and judged, and potentially iteratively optimized. In order to do so, it becomes mandatory to provide various test beds and environments to enable professional validation, optimization and verification of Virtual Product Creation architectures, solutions and business operations.

The hidden demand rationale

After having experienced painful implementations and deployments of VPC solutions with many workarounds, flawed software components and process-wise unclear collaboration and working patterns as well as overwhelmed users many companies and PLM project management members became cautious just to rely on unit test and high level key user tests to sign-off new digital solutions for business operations (compare new demand in Table 17.7). In addition, many engineers meanwhile remain passive and none willing any longer to use new digital tool integrations as part of existing or new Virtual Product Creation environments without thorough tests involving key players and key engineering case scenarios (rather than only the potentially associated individual use cases that are expected in today’s agile IT DevOps approachesFootnote 1).

Table 17.7 Flexible digital test beds in production IT environments
Full size table

Unfortunately, PLM and digital solution providers in most of the cases are just treated as IT vendors rather than as VPC partners and cannot directly influence the integration of their own tools and digital method solutions into the overall company IT architectures and infrastructure. Consequently, the pressure has been growing significantly on internal company IT organizations to seriously separate out test beds for intensive end-to-end testing by engineers within live production IT environments. The set-up of professional test beds will benefit implicitly from the growing number of microservicesFootnote 2 of software deliveries based on the Service Oriented Architecture (SOA) approaches. Establishing microservices, however, needs mid to long-term commitments and a new type of skill set within IT organizations independent of special IT innovation or digital transformation projects.

The alternative to entertain separate test labs usually lacks a consistency of getting live production data (or at least a representative frozen snapshot of it) into such separated IT server environments. Furthermore, old traditional approaches exist for those cases, which forces method development experts to manually download certain data and model examples rather than relying on automated snapshot freeze downloads in a professional digital set-up.

Hidden engineering demand #7

The hidden demand conflict potentials

If no agreements can be reached on such strategic important approach for smooth and forthcoming validation of digital solution environments, the following attitudes, mindsets and cause of actions will typically prevail and will cause unnecessary trouble situations:

  • In case of lengthy and late discussions, time is running out to provide help for specific release dates, which puts significant pressure on individuals to sign-off production readiness of digital solutions without any thorough tests.

  • Engineering teams might deny any buy-in to the digital solution suggested for production and can blame easily digital project or improvement authorities for all upcoming issues. This, however, will cause major irritations, churn and stress which will lead to expensive workarounds and higher resource demands to keep timing of the actual product or technical system development program where the new digital solution is supposed to be used!

  • Short and mid-term misalignment between IT organizations and functional engineering and manufacturing areas will be counter-productive and eventually detrimental for mutually trusted digital future initiatives across organizations. Therefore, mutual understandings of needs are to be explained openly and should be appreciated in order to find compromises to reach digital robustness.

  • Engineers are likely to cease from any future digital engagement once they recognized that quality testing is not to be supported seriously by their own company organizations –this, however, might stall any healthy digital transformation projects in the future.

The approach to mitigate the hidden demand conflicts

Such a delicate hidden demand needs to put on the official agenda at an early stage for a comprehensive view on all digital project circumstances. The validation and testing of modified and new digital product and manufacturing engineering solutions as part of Virtual Product Creation needs to be treated as seriously and as important as possible, similarly to any technical product and technical system development in comparison. Hence, the project leaders need to sensitize such hidden demands officially and need to get clear understanding and commitment of all Engineering Leadership behind it.

After having clarified such fundamental requirements within the official project planning and execution line-up, all details of representative test data and test conditions derived from officially reviewed requirements have to be analyzed and elaborated in a close three way engagement between key engineers, key method experts or key users and experts for IT operations and innovations. Only then, it will possible to size the efforts and approaches more easily on how to realize such overall test bed environment within the company, across locations or even with the interplay of suppliers and partners. Costing and budget provision are critical to get a professional set-up ensured. To be on the safe side, approximately ten percent of the overall PLM/innovation budget should be reserved for such set-up and test operations support.

The resulting need to change engineering principles

The biggest change deals with the recognition in Engineering and IT Management that such test bed undertaking is necessary and not just a nice to have item! Accepting thorough engineering principles in ordinary product, production and technical system development projects should be taken as a role model to find and establish the right validation and verification environments as well as for digital engineering innovations and optimizations. Engineers need to open up their personal believes and expert attitudes in order to provide the right support for the determination of testing activities and procedures and must support it as a “mission critical” activity. New digital working approaches for difficult and sensitive engineering tasks require a fundamental and well-thought-through approach of test scenarios: they consist of a new mix out of traditional and world class engineering capabilities combined with forthcoming new digital mechanisms and collaboration patterns based on data, information and model fidelities. Only if such new commitment can be established across functional organizations and within the individual engineering departments, it will be possible to guarantee smooth test, validation and verification as well as operational excellence later on.

17.8 Hidden Engineering Demand #8: True Appreciation for Digital Responsibilities

Changes in values and forms of work appreciation usually take a long time before they are transferred into daily routines and even longer before they are integrated in official job roles & responsibilities and company cultures. Digital transformations and their associated projects and initatives are still today mostly “controller driven” with the clear expectation to serve for a typical business case within a period of amortization (usually within one year, sometimes two years). Mid and long-term transformations of employee skills, core competencies of organizations and teams and associated responsibilities and accountabilities are missing, or at least do not play a vital role in typical two to three year’s assignments of modern management.

The hidden demand rationale

In professional life, engineers might follow their personal calling and enthusiasm for quite a while unless both collide with stringent company rules, regulations and procedures as well as with career relevant personal achievements incentives and needs. For many years, they have received training to cope with specific tool functionalities and process-related development procedures. One important thing, however, has been never addressed (yet): which dedicated responsibilities are transferred to engineers in their job roles with respect to digital data in general, to their timely creation and maintenance and the appropriate storage, management and transferring to others! All digital activities that are usually hidden behind high-level process boards created by business and process consultants are by no means spelled out, valued correctly with respect to their influence to company success or estimated concerning the necessary time involvement (see Table 17.8). Engineers, nowadays, have started to sense this and wonder why companies and management are not capable or are at least shy on this dilemma.

Table 17.8 True appreciation for digital responsibilities
Full size table

In addition, engineers have meanwhile doubts whether digital engineering work capabilities and achievements are well recognized for career opportunities or whether it is simply assumed and treated as a hidden mandatory “must have experience” with no further critical skill potential. It is high time to establish Digitalization Capabilities as technical career boost!

Hidden engineering demand #8

The hidden demand conflict potentials

Engineers ask themselves to which extent it “pays back” to fulfill all implicit expectations of Engineering Management to care personally about all digital assets such as sets of data, information or models, entries in databases or workflow management systems and as part of interactive design and systems reviews. In many cases, there seems to exist a situation in which your immediate boss somehow simply does not know very much about those digital tasks. Why would a great fulfillment of those duties help and motivate you in making good impression on your superiors? In other cases, there does not exist true appreciation for it and it is downplayed by phrases such as “just get this “bloody” thing done and do not make a “big fuss” out of it!

Following such industrial situations, please note one of the following fundamental and brutal wisdoms of today’s digital transformation business:

Nobody (yet) values if you maintain your digital data, model and information sets in good shape in 99% of your daily routines. However, within the 1% range of your work when you might not have completed a specific data entry in a given situation or when you might have done a mistake, then this is noticed at once and you are put on the spot immediately!

Engineers, designers and analysts are increasingly disappointed about these ambiguities and non-acceptable situations and consequently start requiring a clear commitment to digital work, values and achievements by their professional members and management.

The approach to mitigate the hidden demand conflicts

A first necessary step deals with a clear and precise listing of engineering tasks that are officially recognized in the companies’ working regulations, engineering processes and job roles & responsibilities and of the type of digital skills and activities they require. With such a base listing, it is then possible to rank the digital activities and tasks concerning the following value items:

  • Level of skilled digital competence to carry out such a digital activity

  • Urgency of applying such digital skill

  • Degree of mutual intellectual combination of such digital activity with traditional engineering, design and analytical competences and know-how

  • Scarcity of such digital skill competence in the organization

  • Criticality of digital skill competence even as role-model-related for management and future executive positions.

In any case, consistency has to be applied for constant and regular reviews of digital achievements of each employee and engineer. Simple appreciation feedbacks in given situations and pro-active reward types after a series of demonstrated digital competence and duties should be considered, too.

The resulting need to change engineering principles

Principles of valuing engineering delivery, achievements and competence need to be extended to or even consistently shifted towards digital tasks, skills and achievements in order to motivate, support and excel on such new critical competencies! The new generations of Engineers and Engineering Management have to follow-up such important change of values within their personal agendas and career behaviors and life cycles. It also requires, however, a much higher degree of digital commitments by all daily engineering operations and task assignments. It remains doubtful why especially very traditional companies in machinery, vehicle technology and aerospace still consider two old-fashioned classes of digital skill: one, as part of IT plumbing and operations, i.e. far away from traditional engineering, and the second one as auxiliary and/or clerical job of supporting jobs for engineers. The newly recognized sill set of software coders for embedded software as integral functional part of products, machines and production systems has been recognized, too, but this is not associated to engineers. This is at least an oversight or even a wrong perception since technical systems will only benefit from digitalization if engineers are valued and educated in digital competencies of Virtual Product Creations technologies and solutions!

17.9 Hidden Engineering Demand #9: Upfront Simulation of Digital Engineering Collaboration

In today’s business operations, line and project management are based on the principle assumption that either well founded business heuristics or process related planning experience form the basis for successful working environments and working procedures. Since implicit iterations and intense collaboration patterns are part of Virtual Product Creation behaviors, they are not really envisioned and, therefore, not seriously considered (although many process descriptions do flag them out as one of the theoretical situations), see Table 17.9.

Table 17.9 Upfront simulation of digital engineering collaboration
Full size table

The hidden demand rationale

Based on the experience that Virtual Product Creation solutions use quite naturally control loop operation and iterations (compare Chap. 6 and Fig. 6.5) engineers and engineering management have meanwhile understood that a realistic prediction of digital engineering progression does need additional forecast capabilities and not only experience and process assumptions. Engineers have lost their personal estimation capabilities that were traditionally based on localized and mostly analog discussions, reviews and sign-off procedures. Hence, it is difficult for them to cope with the new challenges in the age of high information technology enabled services for digitally documented, modeled and mastered engineering collaboration across departments, sites, countries and regions. This is the reason why they desire and need realistic upfront simulation of digital engineering collaboration. Furthermore, they do not really understand why such Virtual Product Creation behaviors and progression is not professionally offered and established (yet) although much progress was made for the simulation of product and component behaviors already!

Hidden engineering demand #9

The hidden demand conflict potentials

Process re-engineering consultancy and agile working coaches have introduced a series of business process analytic review styles in order to find agreement, conviction and leadership delegation to introduce new business logic and behaviors. Please note just three examples:

  • US driven “mission and control war room set-ups” to provide an effective “military type command steering board environment” to review, assess and determine mission critical steps for changed or new business approaches

  • Japanese driven “stand-up style obeya room set-ups” to link things together, like strategic objectives to metrics, to planned work and to potential problems.

  • California style “business case-oriented design thinking” approaches and associated stand-up style story telling demonstrations to clarify and motivate future team and business directions and capabilities ….

Unfortunately, all of the above approaches end up on a fairly high level where digital progression as part of the digital transformation foundations do not get involved, at all. Senior Management, however, often believes that such approaches will quite naturally lead to find a mission and order for the internal digitalization in companies and might even influence Virtua Product Creation behaviors directly. This however, is a major misapprehension!

Consequently, (Senior) Management has to rely on digital experts to provide their assessments that they cannot factor into the overall business process equation. This is one of the most obvious, but hidden conflicts as part of digital transformation projects and initiatives of today!

The approach to mitigate the hidden demand conflicts

The scientific community has already offered a couple of promising approaches, which did not find their full ways into mainstream process management, Virtual Product Creation workflows and behaviors and engineering factory operations. Please note, as examples, the following three approaches:

  • Business process modeling notations such as BPMN (Business Process Modeling Notation) or EPC (Event driven Process Chains) with associated workflow engines to simulate overall process behaviors

  • System related linked network models such as Petri Net, SADT (Structured Analysis and Design Technique) or SysML (System Modeling Language) to capture technical system or process related dependencies

  • System Dynamics as an overall methodology and mathematical modeling technique to frame, understand, and discuss complex issues and problems as they also might occur in digital collaboration of technical systems development within Virtual Product Creation.

In the past Senior Management and their implicit process owners in companies called in business process re-engineering consultants to analyze business metric oriented organizational behaviors and to drive change via top-down approaches. Unlike this past success model, nowadays companies have to establish core competences in observing and modeling digital process behaviors, digital engineering progression and Virtual Product Creation collaborations in order to transform such measurable data flows and digital collaboration behavior patterns into meaningful models as already indicated above. Similarly, PLM and digital solution providers and digital consultancy agencies should establish deep expertise in such modeling and simulation behaviors in order to justify and explain better their own VPC solution elements for a given company situation and mission.

The resulting need to change engineering principles

As one of the first principles engineers, designers, analysts and all other digital workers need to become ready to measure themselves with the help of tools and scientific guidance how they perform digital tasks. Such measurements are mission critical in order to understand current individual and team working patterns and behaviors. With such voluntary group of individuals—approximately 25–30% statistically representative members of an observation group would be enough to conclude seriously the overall population behavior—digital simulation experts would receive reliable assumptions for their predictive process and VPC control simulation models. The resulting digital value stream mapping can then deliver core advantages for both, Engineering Management and engineering individuals:

  • Predict overall digital team performance, bottlenecks and improvement opportunities

  • Receive advice on changes to personal digital behaviors or to train personal bot or avatar support (see also hidden demand #4).

17.10 Hidden Engineering Demand #10: New Advanced Human Interfaces

If humans need to interact with IT systems, direct visual, tactile and/or auditive user interfaces become essential. Research and science have delivered key evidence that the user performance, which includes elements such as:

  • Task solving time

  • Number of solutions found

  • Degree of natural or intuitive interactions

  • Degree of (information) immersion

  • Learnability

  • Memorability

  • Effectiveness and

  • efficiency.

Depends on the following influence factors:

  • The user itself with the user experience, the cognitive, perceptive and motorized capabilities, the personality as well as personal likes

  • The task itself with its selection, positioning and orientation and

  • The IT system with its capabilities of interaction technology, degree of immersion, visualization and degree of freedom.

Unfortunately, the existing and prevailing doctrine of Virtual Product Creation stakeholders put a lot of burden to the re-definition and representative use case oriented sub-selection of digital tasks (often not oriented towards the engineering thinking) and on awareness resp. training sessions of the final users. Sometimes, users are at least grouped according to role and task categorization. Efforts towards target oriented interacting technologies as well as immersion and special visual analytics are barely considered or seriously implemented as a key capability (see Table 17.10).

Table 17.10 New advanced human interfaces
Full size table

The hidden demand rationale

Modern people experience new type of interface capabilities in private life by interacting with modern technologies and app-oriented software solutions on tablets, smart phones or even voice control gadgets and services like amazon echo/Alexa or google voice/assistant, car OEM interfaces, etc. Meanwhile engineers ask themselves why such sophisticated interfaces are not offered yet and getting qualified for digital engineering type of interactions. Experiencing convenience support and hedonistic fun and joy in interacting with digital tools will become a “must have” characteristic of next generation Virtual Product Creation solutions, too.

Hidden engineering demand #10

The hidden demand conflict potentials

Younger generations such as Y, Z and Alpha generations will no longer be as patient as the former generations in demanding modern, more immersive and intuitive interacting interfaces in a creative technology mix including:

  • Dynamic and interacting viewing analytics,

  • Game oriented self-exploring levels of expertise for a giving subject area,

  • Ubiquous viewing immersion including Virtual & Augmented Reality interfaces and viewing devices and

  • Voice activated and controlled routine services for daily engineering tasks and advisory.

Engineers, in general, will expect and insist on more efforts to provide the latest technology related interaction support for their duties and tasks, not only to receive better guidance and visual comfort for apprehension but also to experience more joy and fun in delivering digital results constantly and with high personal motivation and quality ambitions. Companies are therefore asked to change their attitude towards a much more forthcoming perspective on those engineering satisfaction levels rather than downplaying it constantly via arguments such as IT integration cost burden and difficult support models.

The approach to mitigate the hidden demand conflicts

Meanwhile IT technologies like micro services and widely used WEB services and interface technologies exist to serve better such demands on the technological side. What remains difficult is that Engineering and IT Management in industry as well as PLM and digital solution providers still have difficulties to employ Human Factors Experts and Human Machine specialists. They are indispensable in order to gain more insights to the most effective ways of offering such new interface solutions in combination with the given engineering cases and tasks and the individual user profile characteristics (see explanation of user performance above).

The resulting need to change engineering principles

Digital Engineering tasks can no longer be just treated as mandatory advice activities that simply have to be followed up according to a prescriptive method. Digital Engineering activities (compare Chap. 6) are to be treated as socio-technical efforts that need to factor in joy, interaction success, tool usage satisfaction and openness to provide feedback to digital assistants in order to help others as well. Therefore, it is adviced to start such a journey with Senior and Middle Management since they need to get convinced about such new and important influence factors and technologies. To get them closer acquainted to more advanced digital technologies in order to trigger closer engagements to the ordinary (digital) engineering work will convince them to establish the right skillset for wider developments and implementations.

In summary, the described ten hidden engineering demands in this chapter are critical for the success of next levels of establishing digital competences and work patterns as part of next generation Virtual Product Creation in industry. All stakeholders, Engineers, Engineering Management, IT experts and IT Management of developing and producing companies, Management and Application Engineers and Consultants of digital solution companies need to deal seriously with them. It is not a question of desire, it is a question how quickly and thoroughly those demands can be met in a fruitful and professional manner, not just occasionally but consistently across all digital activities!